Yesterday was National Black Cat Appreciation Day! Black cats have a low rate of adoption because of superstition. I’ve also heard it claimed this is because they don’t stand out as well in photographs–but we all know how silly and irrational humans can be (even more so than cats), so I believe it’s because of human foibles and not technical difficulties.
In honor of this day and to highlight the plight of poor, unadopted black cats everwhere, here is my Haiku Deck about Clifton, our silly black cat.
Also: NEVER DECLAW A CAT! If you do I will find you, take your cat from you and give him/her to a human who loves and protects animals instead of one who mutilates them.
Dr. Strangecat – Created with Haiku Deck, presentation software that inspires
I must take a moment to recant some comments I made over a year ago about CocoaPods in a post about OCMock. The first time I came across CocoaPods I thought it was pretty awesome, but then reality set in. I had problems getting my project configured. It would sometimes crash with cryptic errors (and still does if you have syntax issues). I had trouble getting it to work with our continuous integration system. Then a developer I have much respect for told me to just use Git submodules–it does what CocoaPods tries to do the “right way” I was informed.
Fast forward a year and I have changed my tune. Git submodules is a reasonable solution to the problem of integrating other projects–but that’s not the primary problem that CocoaPods solves. The real power of CocoaPods is having a searchable repository of open source frameworks at your fingertips. In addition, with Git submodules there is usually a messy bit of configuration to do in order to get the framework integrated–and if you decide you don’t want to use it, additionally messy work to remove it.
CocoaPods makes it simple to find and include thousands of open source frameworks into your project. It does the heavy lifting of dealing with dependencies and integrating into your project. It works with Xcode’s Bots and Jenkins. You can even configure it to use a private repository which contains your own frameworks that are not to be distributed to the public.
What’s even cooler? It makes it drop-dead simple to create and distribute a framework for iOS or Mac.
The only thing you need to do is evaluate the quality of the code you’re using. There’s a lot of stuff out there and not all of it is great. Buyer beware (the linked article is about Ruby Gems, but applies to all open source code).
Writing unit tests is important. Without unit tests, how do you know that your software still works when someone makes a change? Sure, you can deploy a small army of manual testers to double-check that it still “works.” But maybe the change you made has subtle effects in disparate parts of your code–are your testers going to cover everything?
The best way to have confidence that your code is functioning properly is to build and maintain a suite of unit tests. There are entire books written about this topic (for iOS developers I like Test-Drive iOS Development by Graham Lee), but the most recent issue of objc.io covers just this very topic and is a great place to start if you’ve never written tests in Objective C.
Matthew Morey on the Ray Wenderlich website has written a great post on his top 10 CoreData tools to help make one’s life easier. I’ve written a bunch of code to manage CoreData stacks, make fetch requests, ingest JSON in to CoreData and serialize back into JSON… some of these tools are a big time saver.
One thing I would note though: the author’s own framework (MDMCoreData) looks helpful–but I wouldn’t initialize it on the main thread, as it could take a long time if there is a migration required. You wouldn’t want your app to become unresponsive and get killed with everyone’s favorite
Here’s a Haiku Deck that shows how I use Trello for Software Development.
Trello For Software Development – Created with Haiku Deck, presentation software that inspires
If you are an Objective-C developer, rejoice! You can now have AppleDoc-style documents built right in to your project with Xcode 5! All you need to do is add special comments in your headers and Xcode will automagically suck those comments right into its docs!
For example, if I format my function declaration like so:
/** A cool method to do some nifty stuff! @param foo a useful parameter @param bar another useful parameter @return the result of mashing foo and bar together */ - (id)niftyMethodWithFoo: (Foo *) foo andBar: (Bar *) bar;
Then when I option-click on that method name from anywhere in my source code I get a quick view of the help:
Our friends at NSHipster have a great article on how to format your comments to generate awesome AppleDocs, so I won’t bore you with that here. There is a lot more you can do that just document functions, so I encourage you to read all about it and start adding AppleDoc comments to your code!
As an iOS developer dealing with old devices is a thorny problem. Progress in iOS marches ever onward and eventually a new version comes out which drops support for older devices. You are then faced with a choice: keep supporting that older OS and your established customers who are unable to upgrade, or abandon them.
Apple has come up with a new feature for users on older versions of iOS which allows them to download the last compatible version of your app. This is good news for users and potentially a headache for developers.
I always try to support the older OS as long as possible. If there’s a new OS feature I’d like to take advantage of it’s usually possible to do so–and make it so that feature is simply unavailable for users on an older OS version. But at some point there is a fundamental new feature you want to support that requires an architecture change to your code and means dropping that old OS.
When it does finally come time to abandon support for an OS version I always try to make sure there is one final version of my app that has a number of bug fixes and improvements that will leave these people happy until such time as they get a new device that can support the latest OS. This version of the app goes up in the app store and in the “What’s New” metadata I’ll highlight that the update is the last version to support whichever OS version is being dropped. I’ll leave this version in place for several weeks to a month–which should be ample time for my users to update.
Still, some stragglers who are lazy about updating their device might not get around to it, or some new customer with an older device might hear about my app and want to try it. Apple’s new system is going to help them out by letting them download and use my app. Hooray! This is good news for them and for me.
The one main gotcha is if that last version is a doozy–perhaps because of some nasty bugs I never got around to fixing. Undoubtedly there will be developers in this camp and some people who are unhappy with Apple’s latest move. I think this just highlights the importance of doing that final maintenance release before you drop support for an OS.
Kyle Richter (co-founder of Empirical Development) points out some additional considerations with Apple’s new service. I agree there are some pitfalls, but on balance I still think this is a win for users–as long as developers are careful to put out a high-quality final version before dropping support for an older OS version.
I’ve started using this awesome presentation software called Haiku Deck. They make it easy to creat beautiful, professional slide shows to tell a story or pitch an idea. I was inspired to tell the world about black cats, and a particularly silly one that is dear to me.
Dr. Strangecat – Created with Haiku Deck, presentation software that inspires