Category Archives: Software Development

Swift Playground Books: 2-Sep-2016

I imagine a lot of the information here is going to go out of date fast, but if you are looking at playground books today, here is where to start.

  1. The WWDC 2016 talk, Introducing Swift Playgrounds, has a lot of technical detail about the .playgroundbook format and how the LiveView proxying works.
  2. The demo for that talk is available on Apple’s dev site, but it’s out of date. I’ve been updating it for each iOS 10 Beta (to track Swift 3). Go to my GitHub to get the fixed Talking to the Live View sample.
  3. The documentation for the .playgroundbook format can be found on the Apple Developer site.
  4. Erica Sadun, who has written the book on Xcode playgrounds did some early investigations of iOS Swift Playgrounds. You might want to read them — here is Part I, Part II, Part III, Part IV,  and Part V.
  5. Ash Furrow made a playground book linter and authoring tool (source). You can use the linter on any .playgroundbook (however you make it), and the authoring tool allows you to specify the parts of the book in a .yaml file, and it puts each piece in the correct file and folder for you in the .playgroundbook package.

Habits 3.0

Back in 2008, I learned Objective-C to make my first “iPhone OS” app, Habits. When it was released, Habits looked like this:

habits-screen

This weekend I finally finished v3.0 and made it free.

As this is a developer site, the more interesting thing to note is that Habits was originally made in the first iPhone supporting version of Xcode (with external Interface Builder) and I have been migrating the project file from version to version since then (using 7.3.1 to make the current build).

Some things that were introduced into Habits for this version:

  1. Swift – all new classes were made in Swift and many existing ones were refactored into Swift
  2. Accessibility – Since NSSpain 2015, I’ve been running my iPhone with triple-Home to get into VoiceOver (suggested by Hermes Pique in this talk). Doing that made me realize (1) what it was like to use Habits without looking at it (2) how easy it was to make it work properly.
  3. fastlane – specifically “deliver” to manage the iTunes record and “frameit” for fancy screenshots
  4. Carthage – there had never been 3rd party libraries in Habits, but I decided that one was worth it this time.
  5. TOCropViewController – A simple framework that does one thing very well – provide a View Controller for cropping images. I use this instead of the built-in iOS one because it supports locked aspect-ratios.

Enjoy!

Test First as a Habit

I am not a TDD zealot (or even really a practitioner), but on The App Guy podcast, Paul Kemp asked me if I had any habits to share as an app developer.  I said:

My app developing habit … is get a new passing unit test every day.  […] that new green dot is my indication that I’ve at least added a little bit to the application.

This is a habit I started in earnest when I took B. J. Fogg’s Tiny Habits course. My tiny habit was to just run the simulator, and the best way I found of doing that was to run the tests through it. Then, writing a new test for whatever functionality I was planning next just seemed to be the perfect way to extend it.

Once I write that first test, I don’t TDD the rest of the way, but I’ve found that first test to be a good way to warm up.

Working with both Xcode 5 and Xcode 4.6.x

You can have both versions of Xcode on a machine simultaneously.

Here’s what I did

  1. I installed Xcode5 normally
  2. I downloaded Xcode 4.6.3 from the Apple developer website and copied that into my Applications folder as Xcode_4_6.app
  3. I downloaded the iPhone/iPad iOS 7.0.2 ipsw’s from the developer website and loaded them into the 4.6.3 Organizer (Devices -> Library -> Software Images).
  4. In order to get Xcode 4.6.3 to see an iOS 7 device, you need to start Xcode 5, load a project so that it connects to the phone, and then exit Xcode 5 and start Xcode 4.6.3,  You periodically need to do this again (probably whenever you restart Xcode, but not every time you plug in the phone)

One annoyance is that both versions share Recent Projects and will automatically open projects that are open in the other one.  It’s usually best to only start one if the other is closed or doesn’t have any projects open.

I also read on StackOverflow that you can get Xcode 5 to create iOS6 apps by making a symbolic link from inside the Xcode 4.6.x app bundle to inside the Xcode 5 app bundle.

3 Tips for Making Sure an Ad Hoc iOS Build Will Work

If you build iOS apps and send the IPA to others to install, there are a few simple checks you can do before you send it that will make sure it will work.

  1. Go into your Build Settings and set the “Validate Built Product” to Yes — that way you won’t be able to build if your provisions are wrong. This is the default for new projects in recent versions of Xcode, but check it to make sure.
  2. Open the IPA that was created. It’s a bundle, so copy and rename the extension to .zip. Then look for the mobileprovision XML file.  You should see the device UDID that you intend to send it to.
  3. Always increase the version # of any build that leaves your machine.  If you don’t do this, iPhone Utility or anything else can decide to offer a cached version instead. If you have a good place in your app to show the version, do it.

If #1 above causes you not to be able to build, then use Apple’s Provisioning Troubleshooting guide.

If the device isn’t listed in the mobileprovision file, then make sure it’s added to the provision in developer.apple.com’s certificate area.  Regenerate it and download it once it’s right.

Even if you are using a system like TestFlight, you should follow these tips. TestFlight can’t make an invalid app work, and it can’t fix an IPA that doesn’t have all of the device UDIDs in it.  All it does is automate over-the-air IPA installs (which is great), but it still operates within the confines of the app distribution system.

No Pixel Left Behind

I’ve been running iOS7 for a few weeks now as I refresh the look of my apps.  Habits is kind of getting there, but I’m trying to internalize the design lessons of iOS7.  Basically, my mantra is, “no pixel left behind”, which means

  1. If I can change the color of a pixel with no loss of semantic meaning, make it the background color
  2. If I can add meaning with space and grouping, do it, and remove more pixels
  3. If I can add meaning with color, do it
  4. It’s ok to have “brand” colors, but use them only when you need contrast

Here are some other lessons

  1. Prefer to reveal more UI rather than navigate
  2. Make gestures feel like they are moving a physical object (e.g. use pan instead of swipe)
  3. Prefer fewer words, but use enough to not be distracting

Habits 2.02 should be ready in a week with these lessons applied.

The 0-Liner

If you want to show off the power of your programming language, nothing works better than a cool one-liner (or even better, a code tweet).

I have to program in a few different languages, of varying degrees of power, and one thing you start to notice is the 0-liners — the code that just doesn’t exist.

An obvious example is how garbage collection (or ARC) gets rid of memory management. Here are a few more examples:

In Objective-C, nil sinks messages. This means that in a lot of cases, you don’t have to check for nil and “the right thing” happens automatically.  If you send nil a message, it’s a no-op, and if you need a return, you get 0 for scalars, nil for objects, 0-filled structs, and undefined for anything else. You still consider the nil case, but you usually don’t need to write any code.

This is a real example of a language completely implementing a design-pattern, in this case Null-Object. You can get similar behavior by using this pattern. Clojure does even better by letting you implement a protocol on nil to provide implementations for its functions called with nil. But, neither of those are 0-liners.

I don’t use F# (or Scala), but my understanding is that when Some/None discriminated unions are used in computation expressions, the computation will end and return None if some part of the expression returns None.  This is a classic 0-liner, if I’m right.

async in C#/F# (and go blocks in clojure’s core.async and go) rewrite sequential looking code to actually be asynchronous with callbacks.  Miguel de Icaza covered this recently in his post, Callbacks as our Generation’s Go To Statement.

Just like in the Go To days, or the days of manual memory management, we are turning into glorified accountants. Check every code path for the proper state to be properly reset, updated, disposed, released.

In this case, only go and clojure are true 0-liners, as you still need the await keyword in C# (and let! etc in F#) to indicate a blocking call.

clojure’s BigInt contagiousness turns your overflow checks into 0-liners. If this is a possibility in your integer algorithms, it’s worse than null checks.

What’s your favorite 0-liner? The nice thing about them is that they don’t use up any of your 140 characters in a tweet.

Habits 2.01 – Start Small

When I announced Habits 2.0, a fellow Western MA Hackathoner, Molly McLeod, reminded me of BJ Fogg and his Tiny Habits method.

Only three things will change behavior in the long term.

Option A. Have an epiphany
Option B. Change your environment (what surrounds you)
Option C. Take baby steps

I had first learned of BJ from Ramit Sethi’s interview with him. The moment I remember most clearly was his method to start to floss. He suggested that you only commit to flossing one tooth each day — if you did that to start and internalized that that was success, you’d start flossing more eventually. I started doing this, and while I’m not a perfect flosser, I do floss most of the time. That convinced me that baby steps were a real thing. If you have any interest in this, sign up for a (free) week-long tiny habits session with BJ.

So, with Habits 2.0 out the door, I am going to plan 2.01, a baby step improvement of 2.0 by just doing a very small amount of work each day on it.  I joined BJ’s tiny habits for this week and he recommends adding a 30-second behavior triggered by something you will definitely do each day. I decided that once I put my dinner plate in the dishwasher, I will sit at my desk and run the Simulator. Then, I will celebrate that as a success (and mark it done in Habits, of course).

I have been doing that for about 6 days, and each day when I run the simulator, I usually test Habits out a little, and write up a Trello card or write a small test.  BJ’s advice is to keep it completely pain-free and small and to not worry about building on the tiny behavior. Still, in this time I have managed to make a bunch of small improvements to Habits, which I look forward to sharing soon.

Apply Jobs-to-be-Done (JTBD) to Recruiting

Jobs-to-be-done (JTBD) is a theory for what causes us to buy things. The quick description is: jobs arise in our lives and then we hire products or services to do them. The key insight is that the job attributes should be used to guide product development, not the customer attributes. Here is Clay Christensen describing the concept if you haven’t heard it before.

This theory was publicly introduced in his book, The Innovator’s Solution, but is being popularized by Bob Moesta and Chris Spiek in Switch Workshops and soon at the Business of Software conference.

I was lucky enough to participate in some training with Bob and Chris, and so I often think of Jobs theory whenever I wonder why people do anything, and recently I’ve been thinking about recruiting (yes, Atalasoft has a job opening for a software developer in our marketing department to help evangelize our products).

Now, when hiring we naturally think of the job we need done, and of course, we are explicit about that when writing the ad, evaluating resumes, interviewing, ultimately hiring someone. The job has hiring criteria and we use it.

But, at the same time, potential applicants also have a job-to-be-done in their lives, and they are judging us with hiring criteria. In this case, we usually fall all apart. We try to write job descriptions that sell ourselves too, but, frankly, I’m not sure they actually address the applicant’s criteria.

In their workshops, Bob and Chris teach how to find out why people switch from one product to another by interviewing people that have done it already. How many of us have interviewed our recent hires to find out why they switched from their old job to ours, how they found out about it, what happened in their lives to cause them to want to switch jobs? If we did that, I think we’d find that we’re advertising in the wrong places, not emphasizing the right strengths, and generally not making the applicants know that we meet their hiring criteria.

I’m sorry to say that I haven’t done this, so I don’t really know what needs to change.

In any case, I’m going to be thinking and posting more about this — hopefully trying it in practice. In the meantime, if you are a web programmer (preferably in .NET or Java), have at least 5 years of experience, and you want to work in a developer tools company’s marketing department, creating technical content (demos, blogs, articles, sample code, tutorials, brochures, etc) to help developers learn more about our products, get in touch with me. At Atalasoft, you’ll work with smart and hard-working colleagues, where we have an enormous amount of respect and trust in each other. Some of the best programmers in Western MA have chosen to work here, and we can’t wait to meet you.