Xcode 12 from Mac App Store: disc space requirements

I’ve just tried to update Xcode 11.6 to 12.0. Usually (until previous versions), such an operation required ~25 GB of free space on disc. Nah, I’ve just confirmed by trial and error: version 12 requires ~40 GB instead. dd-dev-zero-ed*, of course.

(Note: I didn’t do an in-place update since I just couldn’t free up more than about 33 GB; eventually I decided to move Xcode 11 app itself to a SD card – to ensure I’d still have that, just in case, although I had done a full Time Machine backup before, anyway – and this way I could start the Xcode 12 download from scratch instead.)

---

Folders to clean:
Library/Developer/Xcode/DerivedData, *OS Device Support, CoreSimulator/Caches/dyld

Remove undeeded/reset simulators:
xcrun simctl delete unavailable
xcrun simctl erase all

Move the previous version of Xcode (for backup purposes) from the Applications folder to a SD card/USB drive to avoid an in-place update.

* Purge space:
dd if=/dev/zero of=/Users/[username]/temp.dat bs=1m
rm temp.dat

access_token unavailable?

This call returns null for you (so your app cannot use Microsoft Graph APIs)?

await HttpContext.GetTokenAsync(“access_token”);

… and you’ve tried already most of the things found on StackOverflow?

options.ResponseType = OpenIdConnectResponseType.IdTokenToken;
options.SaveTokens = true;

Maybe you’ve just missed to check Access tokens option on your Azure Active Directory‘s app registration (under Authentication)?

Also, make sure you clear cookies in your browser before you try again if you have checked “staying connected” upon logging on to your app (e.g. with a test account.) The cookie needs to be regenerated to contain the newly enabled access_token info.

Of course – if you are OK with the implicit grant…

Otherwise – for ASP .NET Core, at least – simply go with this .NET Core 3.1 sample app for accessing the Graph API in better way. (You might just need to update some localhost:port values from the tutorial; I don’t insist, you’ll manage it.)

There, you might reach into a different issue – the token may be declared not found, .e.g. if your Web server is restarted (a thing that may happen a lot during development):

ServiceException(new Error { Code = “TokenNotFound”, Message = “User not found in token cache. Maybe the server was restarted.” })

To solve this too, you can simply use try in your Controller‘s action methods and call for a new authentication Challenge in its catch block:

try { … }
catch (ServiceException ex) {
  if (e.Error?.Code == “TokenNotFound”)
    return Challenge(OpenIdConnectDefaults.AuthenticationScheme);
  throw;
}

 

Safe Swift array using Dictionary

Ever wanted to get array elements by index in a safe way, i.e. to retrieve nil in case of index out of bounds rather than having the app crashed? You might have reached into solutions that involved collection extensions like this.

(Sure, the idea below only addresses the get operation, but for many use cases, and especially if your array isn’t huge and the performance penalty is small or very small, I think it’s just easier – and more elegant – to do it by creating a simple dictionary out of your array instead.)

Assuming you have a collection named array, map its values to keys defined by zero-based indexes like this:

let safeArray = Dictionary(uniqueKeysWithValues: zip(0..., array))

Then you can safely get elements from the “array” (i.e. dictionary) using random indexes, as you would expect:

let value = safeArray[index] ?? defaultValue;

Enjoy!

SHA*Managed + FIPS = hate 💔

Fotografie de Life Of Pix pe Pexels.com

If you write .NET software that cryptographically validates signatures, e.g. you verify a customer’s license at runtime, be aware of issues when the check runs on US government-certified FIPS-enabled computers.

Chances are that you run Sha256Managed algorithm for computing a hash to compare it to that of your customer’s resource. (Or Sha1Managed. Or another *Managed, whatever.)

And it worked well for you. In most cases. Or until a specific customer.

The issue is that these (actually pretty fast) algorithms are not supported on FIPS-enabled Windows machines. Specifically, they will throw runtime exceptions whenever they would be called if this [DWORD] registry key is set to 1 on the target machine (try it yourself):
HKLM\System\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy\Enabled.

(See also Microsoft’s 2014 recommendation against enabling FIPS blindly, but this won’t help if your customers are, regardless, still forced into their FIPS-enabled environments.)

To solve the issue, however, you may simply use another algorithm – even that documentation doesn’t clearly state it – use Sha256Cng (or Sha1Cng) instead.

While a bit slower, your check will be performed successfully now. And if in doubt regarding the performance issue, you can also try with the managed algorithm first, and use CNG version just in [exceptional] case; that’s it.

Funny one – but it doesn’t crash

Would you expect this SwiftUI code to crash or otherwise fail to run?

struct ContentView: View {
    var body: some View {
        NavigationView {
            NavigationLink(destination: ContentView()) {
                Text("Show another")
            }.navigationBarTitle("Recursive navigation")
        }
    }
}

Nope, body property for the new ContentView is not called until navigation occurs, so it runs as um… expected? 🙂

Small SwiftUI annoyances

Some (maybe minor) things that I’ve observed while learning SwiftUI and doing some hands on testing:

• When you present a set of unrelated items in a Picker (i.e. without ForEach) or a set of random tab items in a TabView (in similar conditions) you need to tag() them with integer values if you want selection by index to work. (With ForEach you don’t need to – it seems it does it internally?)
• When you create a Button you need to pass its action as the first argument of the initializer, and the content as a last closure. But when you create an Alert.Button the Text is expected as the first argument, and the action as a final closure.
• Corner radius on border modifier is now obsolete. So you are forced to use overlay instead:
  .overlay(RoundedRectangle(cornerRadius: 10).stroke(Color.gray))
  Or, if you need a custom background too, this will become an ugly dinosaur with repeating constant:
  .background(Color.yellow)
  .overlay(RoundedRectangle(cornerRadius: 10).stroke(Color.gray))
  .cornerRadius(10) // cut background too
  Oh my.
• scaleEffect modifier will resize the view but layout won’t be affected, i.e. it might be displayed on top of (or behind) other views. The behavior is the same as for offset but there the “effect” is somehow expected…
• A VStack, HStack, etc. can only contain 10 views added manually into SwiftUI code; you need to use Group to allow more (but that’s OK most of the times).

But there are a lot of good things, too, which I won’t mention since they are everywhere in SwiftUI blog posts, recently. Except for one that I really liked to find out it exists: the .constant binding – very good for prototyping.

Books do make a difference

Fotografie de Pixabay pe Pexels.com

You can start coding with any programming language or on top of any framework either with or without reading tech books on those topics. But depending on the selection, your dev experience might vary so much:

• Go directly hands on with the technology and it will be very fun, but you’ll soon run into miscellaneous, yet possibly very big problems; you’ll then need to stop and read at least the relevant docs, and you might end up with refactoring everything or restarting from scratch (possibly even more than once!)

I did so in my early years as a programmer. By learning just a few of the Basic keywords I was able to do a lot of things. But of course, without knowing about AND and OR I ended up writing subsequent IFs and other ugly code to fulfill even the minimal requirements. (But I must admit, I was just a kid and hadn’t even seen a programming reference book by then.)

• Read a Get started guide or follow a tutorial first and while it’s going to be boring now and then or here and there, you’ll eventually use less time refactoring and finish your work sooner, overall; sometimes big issues will still arise anyway, being caused by the fundamental differences between the way you thought things work and the way they actually do, forcing you to find ugly workarounds or refactor your code big time again; if you’re lucky enough, however, or if your application is not too complex itself, you might get away with this approach, though.

I used to follow this path since Pascal, up to Windows Forms and even tried it with WPF. It goes well, as long as the framework isn’t tricky enough to either decrease performance if you’re using it in a wrong way (like I did first with WPF) or if it’s simply not intuitive enough (at least in some of its parts).

• Read an advanced, detailed book on the topic (after going through Get started reference too) and although this would indeed take some precious start-up time, it will serve you the best on the long term: knowing more about the core of your platform will lead you through complex development tasks without pushing you into unexpected performance issues, and knowing some about all the available APIs that it offers will get you very good overall awareness; you’ll know where and what to search for whenever you need something done, you’ll know what wheels to avoid reinventing, and you’ll know many important things about the approaches and components that you can use or reuse in your project.

After more than 25 years since my first line of code, I highly recommend this way, myself. For macOS and iOS development I followed this route directly (I’m actually still on the road with it), and I am sure it was the best decision I could make for the times ahead. It’s so important to know what to use and when, or at least where and what to search for when you need it! Especially since often the underlying software is just not working the way one intuitively believes it should. (And this is true for all platforms in some of their areas or in certain conditions.)

Moreover, I must note that during the years I’ve found that although I absolutely love coding and that I couldn’t live without computers, reading a good tech book can also bring a lot of joy and happiness too. 🙂

(By the way, I prefer paperback books now, despite Kindle’s advantages: I just feel like and don’t regret it; and apparently, other people are on the same track too.)

Waterfallish isn’t [always] foolish!

Your first goal is an MVP – minimum viable product [not Microsoft’s most valuable professional.] You define a few features and envision a few screens. Sure, without going into any details. And you go with scrum from the beginning. You’re agile, yeah, right!?

During the first sprints you come up with a simple architecture, supporting one or two features and one or two types of screens, just enough for you to be able to start the real development.

The next few sprints you’re working on similar features and improve the initial ones. For some time, everything is still fine.

Then a completely different type of screen or some very complex requirement details arise for either existing or for newly discussed features and they are not fully supported by your original software design.

You have now a lot of work already done and changing the design completely would require a lot of (logically acceptable, from the agile perspective) refactoring.

In theory, it’s indeed still fine: you shouldn’t prepare anything until it’s really needed. However, the redesign would now require at least two sprints to finish, and your customer is not going to “buy it.” Or even if they did, won’t cha wish your girlfriend you had known about those important requirements beforehand, to incorporate them into your otherwise brilliant initial design?

But it’s too late at this point, so what are you going to do?

You [are forced to] find shortcuts and workarounds to solve the issues… and keep the client happy and the product still “on track.”

And yes, everything moves on. For another while. Until emergencies appear again. Until (eventually) everything becomes a mess. Be sure it will, either sooner or later.

Sprints are still green maybe, but the software is redder and redder.

Maybe you will finish the MVP before the deadline, but hey, could you still maintain that code for much longer without a full refresh afterwards? (Remember: v1 is not supposed to be the last one!)

Don’t do this. Don’t scrum without a reason. Waterfall instead whenever you feel it’s better! Sometimes details must be decided before you actually start coding anything!

Or everything can be a waste of time.

Indexing for IndexOf

Today, a short one. But it gave me some not-so-short trouble recently.

Do you happen to use or inherit Collection or any of its subclasses (e.g. ObservableCollection)? Make sure you don’t call its IndexOf method too much. As indicated on Microsoft docs, that is an O(n) operation, and it is therefore fast only if the collection is small.

A workaround that can highly improve the application’s performance in certain situations may be storing and maintaining the collection index values within the item objects themselves. With certain assumptions, though:

• the collection rarely changes and it’s OK if it takes slightly larger setup and update time spans;
• the collection would never need to hold null values;
• item objects cannot be part of multiple collection instances at the same time;
• items for which you need to call IndexOf are surely in the collection at the time of asking the question.

Some code is available here, with an extract below:

public class Item
{
    internal int Index { get; set; } = -1;
    public object Content { get; set; }
}

public class ItemCollection : ObservableCollection
{
    public new int IndexOf(Item item)
    {
        return item.Index;
    }

    protected override void OnCollectionChanged(NotifyCollectionChangedEventArgs e)
    {
        base.OnCollectionChanged(e);

        switch (e.Action)
        {
            case NotifyCollectionChangedAction.Add:
            {
                SetManagedItems(e.NewStartingIndex, e.NewItems);
                break;
            }
            case NotifyCollectionChangedAction.Remove:
            {
                RemoveManagedItems(e.OldStartingIndex, e.OldItems);
                break;
            }
            case NotifyCollectionChangedAction.Reset:
            case NotifyCollectionChangedAction.Move:
            case NotifyCollectionChangedAction.Replace:
            {
                SetManagedItems(0, this);
                break;
            }
        }
    }

    private void SetManagedItems(int index, IList items)
    {
        foreach (Item item in items)
            item.Index = index++;
        for (var i = index; i < Count; i++)
            this[i].Index = i;
    }

    private void RemoveManagedItems(int index, IList items)
    {
        var removedCount = items.Count;
        for (var i = index; i < Count; i++)
            this[i].Index -= removedCount;
    }
}

 

Scrum and the city

The Scrum guides proudly state:

• Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
• Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
• Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Organizations trying to enforce this to a team might not realize, however, that people may simply choose to accept sharing the team blame (e.g. in case of possibly missing a deadline for a release) rather than accepting to do things they are not specialized for (e.g. a person who usually writes code may not sign in to define test cases if she is not used to it, even when the sprint’s timeline would be in red.)

This could easily happen when individuals think that such contribution might eventually jeopardize the overall quality of the deliverables that their team produces.

Some people might say that these members are just “not committed enough” (from the utopian point of view), but in my opinion the former ones would then just be fully blind, similar to the way communists were in the 20th century trying to make anybody work for everybody else; without a proper degree of pragmatism, people would easily miss the fact that productivity only flourishes upon specialization (and liberalism.)

The “nonconformist” developers mentioned above may actually be “too” committed to the product instead – so much that they’d rather screw Scrum entirely than deliver lower quality software to their customers; and I’d argue they have all the rights in the world to do so – what would users want: green sprints or, better, good products?…

Update: As readers mentioned to me there is a side story for this as well: very specialized tier teams or individuals that (just kinda) work together are not good either; backend and UI, for example, should be developed in tandem by a single team (or a single developer), and never provided by separate groups upon formal requests.

This one is an older issue that many organizations still face, but the full stack development trends (together with keeping teams small) are partially or at least conceptually solving this – that’s why in this article I originally insisted on the enforced Scrum toxicity alone – it’s a more recent issue, based on a more actual trend. (Note also that in my opinion Scrum itself, just like many other methodologies, may be good enough for specific projects if the teams consensually auto-select and auto-apply it themselves.)