It was 20 years ago this month that I graduated from college and got my first professional programming job. It has me reminiscing about what the computer programming profession was like before the Internet.
As an iOS software developer, I am often asked whether "we" (a team I'm working with, or someone I'm advising) should avoid using Objective-C and instead use a higher-level or easier-to-learn programming language. In general, my answer is "No". The rest of this post explains why.
My iOS applications use property list (plist) files to specify configuration parameters and other stuff. I was trying to do some comparison and merging of these plists, but was tripped up because the keys were in different order in different files.
So I whipped up a little Python script to sort the keys in the plists and write them in a canonical format. If you would be interested in such a thing, it's as easy as this:
I read a lot of science fiction (SF) in my adolescent and teenage years, but I got bored with it in college, and stopped reading it. Actually, I didn't get bored, I got annoyed with it. At the time, I couldn't describe exactly what it was that was annoying me, but I felt that each SF novel I read was following a formula that had stopped entertaining me, and that SF had become a waste of my time.
In the past few years, I've started reading SF again. I've read new stories by new authors, and tried to catch up on some of the SF classics I should have read back in the 80's. A friend loaned me his copy of Robert Heinlein's The Moon is a Harsh Mistress. I looked forward to reading it, as I had heard it was one of the best SF novels ever written.
I hated it. This novel reminded me of everything that made me stop reading science fiction.
Lots of smart people do enjoy this book, so I spent some time thinking about what they see in it, and what it is that I find so repulsive.
Mac OS X provides a pretty nice data-binding technology for developers, called Cocoa bindings. Unfortunately, the Cocoa bindings mechanism is not available to iOS developers, so iOS developers have to spend a lot of time writing code to keep user-interface elements and data in sync.
However, while Cocoa Bindings is not available on iOS, the underlying key-value coding (KVC) and key-value observing (KVO) mechanisms are, so it is straightforward to implement your own poor man's data-binding mechanism and eliminate some of the drudgery.
I'm not the only one to try this. Here are a few similar projects I found on GitHub:
Xcode's Interface Builder is a pretty good user-interface layout tool, especially for simple situations. However, it is not the best tool for every job. Sometimes you have to write code to dynamically create user interface elements or to move them around as the view is resized.
When you do this, you find that iOS doesn't help you much beyond some rudimentary autoresizing options. While iOS 5 does provide some autolayout features, they are limited, and they don't help at all if you need to support earlier versions of iOS.
I also couldn't find any third-party implementations. I found a few posts and samples for making a grid-like
UITableView, but I wanted a way to lay out things in a grid in a plain-old
So I decided to write my own grid-layout thingees for iOS.
I learned to touch-type over 30 years ago, on an IBM Selectric typewriter. I'm a fast and accurate typist, compared to most programmers. I've always considered typing to be a basic skill that all programmers should take seriously. What goes on in your head is more important than how fast you can type, but the more efficient you are in getting your thoughts into the computer, the better you are going to be at your job.
I've been dismayed at one "feature" of my MacBook: to prevent accidental triggering of the Caps Lock key by incompetent typists, Apple makes it necessary to hold down the Caps Lock key for an extra fraction of a second. If you just tap it quickly, it does nothing. See http://support.apple.com/kb/HT1192 for Apple's explanation. They have also baked this behavior into some of their keyboards: see http://support.apple.com/kb/TS1578.
While I'm sure that many people welcome this feature, I do not. I type quickly and confidently, and my fingers hit the Caps Lock key at the appropriate times without me consciously thinking about it. I hit and release it so quickly that my MacBook ignores it. So when I type "UNIX is awesome!", "Party in the USA!" or "New York, NY", I see "unix is awesome!", "Party in the usa!" or "New York, ny" on the screen.
There is no easy way to disable this feature. When I complain, most people respond "Big deal. We hardly ever use Caps Lock." Well, I do. I've been using it for 30 years, and it has always worked fine. Until Apple decided It Should Just Not Work.
So, I looked into what I could do.
Here's another programming-language cheatsheet. It's been a couple of years since I've done any Python programming, and now I'm taking the online CS373: Programming a Robotic Car course, which uses Python for quizzes and homework assignments, so I have to get back up to speed.
As always, this is the information I've found useful in reacquainting myself with a programming language. It may not help you at all.
If I had my druthers, I'd spend all my time developing mobile apps. I've always been fascinated with pocket-sized computers, and have owned many through the years. Unfortunately, for most of my life such devices have been little more than toys, and so I've had to focus my expertise on writing code for "real computers".
This is true even now, during the explosion of smartphone and tablet usage. I'm one of those dinosaurs who knows how to use C, C++, MFC, ATL, CORBA, UNIX, and other ancient magic, so there are sometimes a few months of old-school development between mobile-development gigs. I write iOS stuff for fun, so I keep those skills sharp, but Android is something I touch only when I'm being paid to do so. Thus, I have to find a way to quickly get back up to speed when the Android work does come.
This is my little refresher for when I arrive back in Android-land. It may not help you at all.
When determining why some damned thing in my .NET programs is taking so damned long, it is useful to be able to look at the elapsed time for various sections of code. The straightforward way to do this is to create an instance of
System.Diagnostics.Stopwatch, start it, do the thing, then stop the
Stopwatch and print out the elapsed time.
But it gets tedious to keep adding those
var stopwatch = new Stopwatch(); stopwatch.Start(); and
stopwatch.Stop(); Print(stopwatch.ElapsedMilliseconds); lines all over the place, and it also makes the code less readable, so I made a little class to simplify things.