Category Archives: Software Development

Swift 2.0 and ReactiveCocoa 4

When I set out to learn ReactiveCocoa I couldn’t find any guides that quickly got me setup and working with the latest version and Swift 2.0. So, after a bit of experimentation and trial and error, I’ve found a way to get things working with the 4.0 alpha 1 version of ReactiveCocoa and Swift 2.0 with Xcode 7. This has been cobbled together with my poking around in the source of ReactiveCocoa (v4 is available here) and going through their examples. If you’ve played with the RAC examples before then this should look somewhat familiar. All this app does is create a SignalProducer on a text field and make a network request to a server to pull down what was typed into the field and display this on the screen. It’s not meant to be a complete “best practices” guide about ReactiveCocoa but rather simple environment setup instructions. My code is available on GitHub but this guide should provide the nuts and bolts of what an average user needs to get started. Here we go.

First, create a new Single Page iOS application in Xcode 7. Once this has been created, add a Cartfile to the root directory that contains just the single line:

Now, ensure that you’re using the Swift 2.0 version of ‘swiftc’ as the 2.1 version can cause problems. To change it follow this explanation. Once you’ve done this run the Carthage update command as follows:

This should now build your appropriate Framework files. Head into the Finder and drag the Frameworks into your Xcode project. Be sure to add them to the Embedded Binaries portion of the app configuration. It should look like so:

Screen Shot 2015-10-01 at 6.51.09 AM

With iOS 9 it now disallows all communications to any insecure (ie HTTP) endpoints unless explicitly told to whitelist some or all sites. This is easy enough to fix with the NSAppTransportSecurity  key in Info.plist. Add this key as a dictionary then add the key NSAllowsArbitraryLoads  to this dictionary as a boolean set to YES.

Next, place a UITextField  and UILabel  on the main screen in Storyboard and wire them to the textField  and nameLabel  properties in the ViewController.swift file. Test by compiling and fix any AutoLayout or compiler errors.

Finally, since this app is hitting the network looking for a JSON response we need a server to do that. I quickly made a Node.js server that will work for our needs. To use this make sure you have Node.js installed and save the following source in a file named server.js . Using a terminal, navigate to where you saved it and run npm install express  (express is the only node module dependency). Finally, ensure nothing else is using port 8001 and start the server with node server.js . Here’s the code:

Once the server is up and running your iOS app should be able to communicate with it! This is a very simple example of using ReactiveCocoa but there were enough pitfalls when trying to use the latest version that I thought I’d write this up. Again, all iOS source is available on my GitHub account. Please send any questions in!

Xcode Server Slack Integration

After spending a day last week struggling to get a working integration of Xcode Server and Slack (the popular messaging platform) I finally have arrived upon a reliable solution. What started out as a long bash script (and sed, and cut, and tr) that eventually called a Python program, is now just a Python program run by the Xcode ‘Trigger Script’ functionality. Read on for how I did it.

Working with a client on an iOS app we wanted to keep everyone aware of the project’s progress and the current state of all tests, both server and iOS. So, our team added the client as a Slack single-channel guest and got to work integrating our server-side Strider Continuous Integration server and Xcode Server.

Not knowing any better I dove into the output of the Xcode Build located in /Library/Developer/XcodeServer/IntegrationAssets and poked around. I found the file buildService.log which contained build output detailing everything I needed to know about the build, looking like this:

Which, I immediately thought, “I know, I’ll tackle it with bash and sed!”. So I got to work writing a script to parse these entries and ultimately distribute them out to our Slack channel so everyone can see progress as we go along. Here’s the bash script I wrote:

This seemed to work! But, however, proved problematic as I discovered (only after I’d written the script!) that there lies a chicken-and-egg problem with when Xcode will execute a script versus when it’s all done packaging up the buildService.log files. The pattern that Xcode follows is: run the project tests, run the post-process script, then build the buildService.log files. So, the script above was running on a previous build, not the most current one.

I poked around a bit more but ultimately couldn’t come up with a solution of how to solve this. So, I searched around on Twitter and found @mjmoriarity, a wonderfully helpful Apple engineer who pointed me towards my ultimate solution of using Xcode’s set environment variables. Using these, my script was now reduced to a handful of lines and is wonderfully reliable:

Peripheral Intimidation

Driving from Seattle to Portland with some regularity gives me a chance to stop (and go, and stop) and think for a bit. As with every car drive I begin to mull over what’s been on my mind recently – usually development-related issues. The last drive I stumbled across a comparison that helps explain a distraction I’d been experiencing recently in my work. The analogy? Software and semi’s.

Being a part of any development community means being exposed every day to amazing work done by amazing people. Continuously seeing all the cool things people are doing it’s hard not to draw comparisons to your own work. The feelings of inadequacy and Impostor Syndrome, unless carefully monitored and controlled, are inevitable and intense. Because the names of the people creating these apps all seem to blend together after a while, it feels like one single, impressive, superhuman coding all these apps, sites, and documenting every step of the way. Someone more talented, thoughtful, creative, and with more perseverance than you could ever dream of. In essence, a hulking semi of app-creating power rocketing down the information superhighway (see what I did there).

It’s natural to feel small compared to these semi’s. In fact, it’s probably healthy as it pushes us to continue to sharpen our saws and elevate our skills.

But it’s so critical to remember that each cool thing being churned out of this great internet machine was created by regular people. People who found a niche, pounded hard at it, and after many failures and false starts arrived at something close to the final product.

Mike Lee, a developer I’ve long respected for his talent and design skills, was recently interviewed and outed that he’s a just regular guy, not superhuman. If you haven’t yet seen it (or listened to the MP3) it’s well worth your time. One of the smartest guys running in Mac/iOS development circles is an ordinary dude. It doesn’t get much more inspiring than that.

So, just as you continue to suck it up and drive down freeways past the hulking semis, development should continue as well.

It’s Harder Than Ever To Learn To Program

Despite the seemingly endless amount of resources dedicated to learning programming (Kahn Academy, MIT Open Courseware, Stanford’s free classes, etc.) available to people these days, it seems as though it’s harder than ever to learn to program. Now, it’s not because of a lack of resources (obviously); rather it’s because of what a new user can produce with these resources.

Someone coming of age in the 1980s when home computing was just starting to take off would find that not only was everything about a computer new and novel, but everything they did appeared to be at the forefront of computing. Every second of interaction was unknown, exciting, and precious. As a perfect example, you used to have to type in programs on the old Apple machines because disks to store the programs weren’t common/cheap enough. Want to find out what a certain instruction does or modify it to make it do something different? Go ahead, you’re the one typing it in.

Everything a user did felt like they were stretching the boundaries of the machine. Without the internet there was no bar to compare yourself to, only your friends and the cool things they did with their computers. Everything seemed new and as if they were the first person alive to come up with such a cool way of doing things. This, then as it is today, is incredibly addictive. During this time, doing one cool thing with a computer made a user fiend to do more. Inevitably, the user becomes so enthralled with the machine that they put in their 10,000 hours and poof, become masters of the machine.

Contrast this with today. Kids are growing up having smartphones, tablets, and laptops at ever younger ages, and are being exposed to beautiful, wonderful programs that can do so many cool things. Curious and interested, they may sign up for a programming class or read a tutorial online. What’s the first thing they’re taught? “Look, you can make the screen show this horribly antiquated and awkward string of words, ‘Hello, World!’. Isn’t that amazing?!” This kind of stuff wouldn’t even impress my 2 year-old niece, let alone someone who has access to the flash-bang-whiz 99c attractions of the world’s app stores. Even the most inexperienced engineers can build a fun, useful catapult just a short time into learning the material while building something as conceptually simple as a photo-sharing site takes years and years of practice and hard work.

Now, I’m not advocating for the exclusive use of higher-level languages when teaching a person to program or that humanity is doomed because we’ve advanced the state of computing so far that nobody will want to approach it ever again. I think that what really propels people to continue to learn and mature their skills is what drives most creative people: a desire to build, explore, and understand things regardless of the external sex-appeal what they’re currently working on. I know it’s the primary motivator behind my learning and growing. Mostly, it’s just interesting to note the differences between the environments of learning to program 30 years ago to starting to program now.

Windows Batch Scripts

Ever edited batch scripts on Windows (.bat files) that modify folder hierarchies and the changes don’t seem to take, no matter how correct they look? Well, chance are, they are correct and it’s Windows being lazy. I’ve found that anytime I try to delete a file with the command ‘del /rd /s [folder]’ and it fails, a good restart (yes a full machine restart, in 2011) is all that’s needed. I’ve no idea why this happens or if there’s a cleaner way to force it to delete but luckily virtual machine restarts are quick and settings save rather easily.

Basketball Codes (ooweeoooh) Part 1 (of a billion)

Growing up playing organized (and often unorganized) basketball allowed me the chance to learn many lessons I otherwise wouldn’t have had the chance to. Looking back I see many similarities between playing basketball and writing code. This (hopefully recurring) series will attempt to tease out insights to be gained and applied to the professional world of software development.

One of the most lasting lessons that one of my coaches was fond to give us speeches about was along the lines of, “You may not be the most talented out there. You may not have the best jumpshots or be able to jump the highest. But you will be the most prepared and the most conditioned.”

I can’t attest to have learned this lesson immediately but it was reinforced time and again throughout high school and college. Not one time could I lay claim to being the smartest person in any of my classes but I always tried to work the hardest. Even now I’m far from being the most talented developer on our team but I try to remember these talks I had with my basketball coach. I’ve found working hard to be the only attribute in a person that even comes close to being an indicator of success.

Play good ball, write clean code, work hard at both.