I sort of got away from this mentality and it made making a single blog post a slog.

I am quite impressed by David Walsh’s blog in this regard. Although, David is an amazing programmer who writes awesome posts, he doesn’t go through such a detailed thought process when he has to write something. He often writes nifty tricks and How-To posts that have helped me countless no of times and yet, there are still very few blogs that might be doing the same thing.

Hoping to get back there.

Brian Kernighan and Dennis Ritchie in their classic The C Programming Language wrote that the biggest hurdle in starting beginning learning a programming language is to write a program to print the ‘Hello World’ on the screen, the rest is relatively easy. This is because it requires mastering the mechanics of writing a program : writing it somewhere, running it and seeing where the output went.

This quote from an excellent introductory tutorial on quartz composer perfectly encapsulates my relationship with programming and stumbling blocks that have at times kept me pursuing it more than I did.

There are a lot of ways that this simple idea could/should be applied to efforts to recruit people/children/women/minorities/low income folks/etc. into programming. I know from my personal experience that seemingly small barriers can prevent otherwise qualified folks from doing something they...

I will try to keep this short so that I can get this post out.

TL;DR

CAShapeLayer is a canvas upon which you can draw CGPath. It’s bounds, and position must be set manually.
The easiest way to do that is

    CGPathGetBoundingBox(path);
    layer.frame = layer.bounds;

If the lineWidth property is non-zero, the bounds should be adjusted to contain the entire path plus the additional width of the stroke.

Longer Version

It turns out that I had really misunderstood CAShapeLayers and had mostly misunderstood some key issues about the bounds property of CALayer/UIView.

In most regards, the misunderstandings are so basic and fundamental, that I am embarrassed to share them, but on the other hand, I would have loved a “talk to me like I’m stupid” explanation of both of these topics. But still, pretty embarrassed.

Discovery of My First Mistake

CAShapeLayers are a nice way to draw a...

If using primitive types, Core Data presents dates as NSTimeInterval instead of NSDate. I sort of knew this. No problem.

When setting value for this property – MUST use timeIntervalSinceReferenceDate.

I did not know this.

As I am reading more about swift and what people are doing with it, I do love seeing some of the ways that it can bring conciseness, particularly with custom operators. Two recent examples that inspired this post are the Runes functional operators by Gordon Fontenot and this post on binding views to object values by Srđan Rašić (that I like is similar to the approach that I was trying to take with my binding library, described poorly in this post). But I am also really concerned about all the expected operator abuse, operator overload abuse, etc. I am also really concerned about the opacity that results from excessive concision. Having used CoffeeScript for a while at work, I can see the strengths and weaknesses of concision.

The runes example is a great example of the operators being a great way to replace the burden of parentheses and syntactical restrictions that repeated...

Work developments have prevented me from doing a lot of iOs, so as things are heating up with Swift and functional programming, my main involvement is reading. But I was reading this post by Andrew Bancroft on using Swift functions to replace C macros in your code, and I noticed that the author used an Int-typed function to replace a macro, which is fine, but misses the flexibility of a macro.

Based on all my reading, I immediately thought of generics. It seemed like it should be super easy to replace

func squareNumber(n: Int) -> Int {
    return n * n
}

With

func squareNumber<T>(n: T) -> T {
    return n * n
}

But, of course it wasn’t. Basically, I had forgotten/didn’t realize that when you have a generic type, you need to tell the compiler how your type is going to behave with various operators. I struggled with this for a bit, finally stumbling across this post by Nate Cook...

I have a half-written post sitting on my computer about my frustration regarding the conversation regarding functional programming and to a lesser degree regarding Swift. It was initially prompted by a conversation between Gordon Fontenot’s on this (?) Episode of Build Phase. The short version of my post is that in one breath Gordon acknowledges that despite his excitement about functional programming that it is indeed hard, but in the next seem dismissive of the complaints of non-functional programmers regarding functional programming (“it is just as intuitive as imperative programming! It’s just different!”). I was super-excited that he was talking about this, but super frustrated with where he ended up.

So, instead of getting around to writing the post, I just let time pass and let Gordon do all the heavy lifting on addressing these issues better.

First, he wrote a phenomenally...

I have basically decided not to work on Swift this year with any serious focus. I think that there is so much fluidity within the Apple community regarding how to do Swift well, that I am personally going to be best served by waiting a year. [^1]

That said, there are a few things that will simultaneously make me a better programmer and probably get me closer to ready for Swift. In particular, really understanding blocks (i.e. closures) and also moving towards functional patterns in my code. With regards to blocks, I certainly “understand” them, but I think building my intuition around the idea of passing blocks of code is still a work in progress. I was additionally inspired by this nice post by [Khanlou][8Patterns] that does a great job quickly walking through a variety of design patterns that help with ViewController bloat.

So, I fiddled around with building a view-model class based...

As is often the case, I needed to arrange a few round buttons evenly across a view, and wanted to set the width and spacing in a nice way. It occurred to me that though it is oversold, the golden ratio is at least a reasonable place to start. So I first set up the problem as so:

1. The spacing + buttonWidth = 1.618*buttonWidth.
2. the edge to Button Spacing is equal to the button to button spacing.

in other words:

So, I derived this with some algebra…

buttonWidth = viewWidth/(1.303*numberOfButtons + 0.3083)
sp = 0.3083*w

For a 320 point wide view, that leads to the following table of values:

Drawing this with round buttons looks like this, which to my eyes and testing, seem like a good implementation with regards to Fitt’s Law

Later in the day, I got a phone...

I know that I should stop talking about objective-C. sorry.

It is interesting to see how coming into the Objective-C language in the last couple of years blinds you to some of the more traditional uses of the language. In particular the dot-syntax hides the underlying message passing model of objective-C. It is of course fully equivalent, but it is also compiler checked, which makes it easy to forget that @properties are merely getter/setter methods. Of course, we all learn that they are equivalent, but without the practice of coding without dot-syntax, it is easy to forget the implications.

I have been thinking about this recently, because I was contributing to an open-source project on github, and the coding in it was done almost entirely in braces-only syntax. It was an excellent exercise to stick with that entirely in my contributions. It was revealing to be constantly reminded...