Been having some problems with my iMac upstairs. I’m pretty sure the hard drive is failing (again), although hopefully it’s just bad sectors. But, with hard drive prices currently still in the stratosphere, I decided to try one more last trick to see if I can save myself some money. That is, the old Windows trick: fdisk, format, reinstall. Or, well, the Mac Equivalent - Disk Utility, reinstall.

About a year ago, a bought a Drobo. I’ve been meaning to write a review of the Drobo and maybe now I will (the short of it is, I had some growing pains with it, but now that I’ve figured out its quirks, it seems to work well). One of the reasons I bought the Drobo as to use a shared Time Machine backup store for all the Macs in the house.

So, I thought, in addition to trying to save my Mac, now would be a great time to test my fancy Time Machine backup system. And, unfortunately, since Time Machine really isn’t meant to work with unsupported network volumes, it does require some gymnastics to get it to work. Even worse, it isn’t a very well documented procedure. But, ultimately, I was able to figure it out; I’ll post what I did hoping that maybe it will save someone some time and headache.

1. First step is to format and reinstall as you normally would. If you are on/installing Lion, you may be presented with an option to reinstall from a backup as part of the install process. Don’t do this. Reinstall Lion as if you were performing a fresh install.

2. When the installation is complete and you get to the Lion post-install setup screens, you will (eventually) reach a screen asking you to create a user account. Create your original user account (same username) as in your backup.

3. Once you’re out of setup, go to System Preferences, then Users. Create a new administrative level user (I called mine “foo”). Be sure this is an admin-level user.

4. Log out and log into the account you just created.

5. Turn on unsupported Time Machine volumes. Open up a Terminal window and enter:

defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

1. Now, open up a finder window and navigate to your Drobo or other device and to whatever network share you have your Time Machine backups stored on. Mount it.

2. Now, inside the share, mount the .sparsebundle that is your restore image (it should be the machine name). If you open it, you should be able to see a folder called “Backups.backupdb” in it.

3. Next, fire up the Migration Assistant.

4. Select “From another Mac, PC, Time Machine backup, or other disk.” Hit continue.

5. Select “From a Time Machine backup or other disk.” Hit continue.

6. It may take a second, but, eventually, you should see a drive image and the name of your old hard drive (usually “Macintosh HD”) appear. Click continue.

7. It may take awhile for it to parse the image. My backup image was about 350gb, and it took about 20 minutes to parse out all the information. Select what you do or don’t want and click continue.

8. You should be presented with a dialog stating that a username on the system is the same as one in the backup. Select “Replace…” Click continue.

9. Wait. It will take awhile. It took about 5 hours for me to do a complete restore from a backup on the Drobo to my iMac.

And that’s it. Once it finished and you reboot, your Mac should be just as it was during the last backup.

Over the weekend, I was having some hard drive issues. While I think I fixed the issues, I’ve been keeping a close eye on my console (Console.app) to look for any hints that the issues are more major than those that can be repaired by Disk Utility.

However, while watching my console, I noticed something: there are a LOT of spammy Mac apps out there!

Most Mac/Objective-C developers are aware of the NSLog() function, which, while in an Xcode environment, outputs data to the Xcode console. It’s usually one of the first things a new developer learns about and it’s very useful for debugging. What many developers may not realize is that NSLog() continues to output data to the system logs even when the app is not being run from within Xcode. As a result, the console fills up with messages that don’t mean a whole lot to people looking at the console.

Now, I don’t want to come across as saying you should never use NSLog() outside of Xcode. There are times when outputting debug data to the console is fine. But some of the things I see are people echoing objects into the log or short text strings that are obviously method names. These aren’t helpful to people looking at the console and, arguably, aren’t helpful to a developer once an app is in the wild. Once your app is in the wild, data in the logs should indicate error conditions in your app.

NSLog() is fine for debugging in Xcode, but you should be careful to remove them when you’re done. A good question I ask myself before leaving an NSLog() in place is, “if a user filed a support request with this data, would it help me fix their problem?” Most of the time, the answer is no.

So before releasing an app, do a quick search in your project for all uses of NSLog() and evaluate whether they are really needed.

Among the many sites I follow for programming discussion is /r/PHP on reddit. While most of the discussion is more user-based than I would like - things like frameworks, use of PHP-based software packages and the like are usually discussed more often than actual programming - there are occasionally a few gems worth chiming in on. But it never fails that, at least once a week, I see the headline “How do I become a PHP developer,” or “What do I need to know to be a PHP developer?”

My answer is simple: don’t. Just stop.

Don’t be a “PHP Developer.” Don’t be a “Java Developer.” Don’t be a “Ruby Developer.” In fact, don’t be any kind of developer that depends solely on a single language.

Languages come and go. Ten years ago I would bet the majority of web programming was still done in Perl. Fifteen years ago the web was still widely misunderstood and Java was promising that we would only have to write code once to run on any computer. Twenty years ago you found C, FORTRAN and COBOL on mainframes.

Every few years a new language comes around and everybody moves to it. Sometimes they stay around, and sometimes they don’t. C has been around for many years and is just as valid now as it was twenty years ago. Even if you’re programming in C++ or Objective-C (both of whose roots go back further than you probably realize), you still need to understand the fundamentals of the C language. Will we still be using Clojure in 20 years? How about Coffeescript? Who knows. Maybe. Maybe not.

My point is, don’t chain yourself to a single language. If you do that, you will be forever behind the curve.

A good developer should be able to work independent of his/her tools, should be always willing to learn new and exciting things, and should be able to apply lessons learned in past development independent of the language they are working in. A good developer should be able to come up to speed quickly on a new language. And while it is true that every developer will probably always have a preferred language and a language they’re best at, we as developers should always place the craft of software development ahead of specialization in a single language, and we should be willing to use the best tool for the job independent of our linguistic preferences.

While PHP is my primary language (and what pays the bills), I am not a PHP developer. I am a software developer who works in PHP among many other languages. It should always be the goal of every developer to remain at the forefront of our craft. That means not chaining ourselves to PHP, Ruby, JavaScript, Java, Scala, Python, or any other language.

A couple of days ago, I upgraded to the most recent version of Netbeans - 7.1.1. I had been running a 7.1-DEV nightly from back in 2011 and just hadn’t bothered to upgrade yet. The first thing I noticed is that this version of Netbeans introduced a “feature” that allows you to zoom in or out of text. This is accomplished by, on the Mac, holding down the Command key and scrolling on the trackpad.

The problem with this is that it is very easy to trigger accidentally - to the point where I was doing it multiple times a day. Even more irritating, there was no indication as to what the zoom level was or easy way to revert to normal view. If you trigger it accidentally, you just have to kinda zoom back out until you find a setting somewhat similar to the rest of your tabs.

Fortunately, someone on the nbusers mailing list mentioned how to solve this problem, so I want to post it here in case anyone else gets as lost and frustrated as I was.

1. Open the preferences page. On the Mac, you would go Netbeans Menu -> Preferences.

2. Go to Keymaps.

3. Search for “zoom”.

4. Remove the bindings for “Zoom Text In” and “Zoom Text Out.” Double click on the Shortcut and hit backspace twice.

While this blog will still have my occasional musings about life in dot-com and software development, there’s a lot of other stuff I’d like to talk about that really doesn’t fit under that label. Carpentry? Home improvement? Relationships? I need a place to put a lot of that stuff. Well, me and my wife will be (re-)launching a new blog documenting our life. So if you’re interested in us at a more personal level, feel free to check out the new blog.

www.robandsarah.org

This article and the accompanying discussion on Hacker News really got me to thinking tonight. I’m not going to say much about the post itself other than that I agree with Dan’s sentiments. I don’t know who in their right mind would address a guest at a professional conference using the term “sexy.” But it did get me to think a little bit more about professionalism, professional behavior and how it relates to software development.

We as developers, and especially those of us in the Internet world, are used to a certain level of what would be traditionally considered non-professional behavior when it comes to the workplace. Most obviously, there’s the dress - T-shirts, jeans or shorts (depending on your climate) and sandals are common dress. Many companies’ offices are outfitted with lots of things you would not find in a traditional office - ping-pong tables, beer kegs, beanbag chairs. It’s all very collegiate. We tend to have very little patience for those who “don’t get it” - every developer has probably at one point labeled a user a PEBKAC. And then there’s the language - I think developers might be second only to sailors in finding creative ways to swear.

Essentially, we get to be big kids. It’s a pretty sweet gig!

I think a lot of this is because we, as developers, value one thing above all else: the ability to deliver. As I think about it, I can remember working with some brilliant people - and some of them had absolutely no social skills and no idea that some of their behaviors were not just unprofessional, but outright disgusting. If you can ship quality, it doesn’t matter if you wear a suit and tie every day or you wear a threadbare T-shirt and haven’t shaved since Nirvana first hit the radio. To us as fellow developers, what you produce is what matters above all else.

As one comment said:

The programming world is so used to breaking the norms, revolutionizing industries, and wearing T-shirts and sneakers to work that we forget, sometimes, that some aspects of “professionalism” actually do serve a purpose.

While these things may be “okay” in our culture - the culture of dot-com, the culture of software developers - to outsiders, we are baffling, uncouth, at times rude and definitely unprofessional. Now, if you’re working in a startup, you’re probably around only a few other people who are like minded and are part of the culture and won’t think anything of strange behavior as long as you ship. My last job was with a startup that was 4 months old when I joined the team and was still very small. I remember hearing a story about someone in the company who, during a long night of coding in a small office, just got up, took his pants off, sat back down and started coding again. This may be kind of an extreme example, but this general kind of behavior is considered the norm for developers, especially in Internet startups.

But, there comes a time when we have to drop - or at least tone down - the unprofessional behavior and actually start taking business seriously. I’m not exactly sure what that point is, but it’s probably about the time that people who are not part of “the culture” become involved. Marketing, sales, business development, management, accounting, and other more traditional business fields are not part of our culture and they don’t get our ways. Once these people become involved, and definitely once/if they outnumber the developers, we must begin to accept the fact that we have to modify our ways a little bit.

The thing is, we criticize them as being “stiff,” “squares,” “boring,” “demanding,” “not getting it,” and the like. We begrudgingly work on tasks for them, the whole time complaining to our coworkers in our culture about what we have to do for marketing, or accounting or whatever and how they just don’t see the big picture. But we are unwilling to meet them even half way when it comes to working in a professional environment. I don’t know if they’re trying to understand us, but are we even trying to understand them?

Over the last couple of weeks, I’ve been trying to raise the bar for myself a little bit when it comes to being professional. No more T-shirts and jeans or taking shoes off. I’ve tried to stick to “business casual” dress, although it’s tended to be a bit closer to the casual side (I still wear sneakers and my shirt is almost always untucked). But I’ve worn collared, button down shirts and khakis - something that would have been unthinkable a year ago. I’m actually even thinking about wearing a tie occasionally. I’ve been trying to tone down the language and start thinking respectfully about each task regardless of it’s interest factor.

I guess what I’m trying to get to in my admittedly rambling diatribe is that professionalism starts with respect: respect for ourselves, respect for our craft, respect for our employers, respect for our coworkers whether they are developers or not, and respect for our peers. We need to begin to have more respect for what we do as a craft and profession, and more respect for the people we encounter every day. We should always strive to treat everyone we encounter with the respect they deserve at the very least as fellow human beings. That means not referring to users that break our software as idiots and not referring to women presenting at conferences as sexy.

Another small update to the Mac Oil Price Widget has been released. This fixes a small bug that resulted in the negative symbol continuing to be visible. Not really necessary because the widget itself says “Up” or “Down.”

You can download it over on it’s page.

I’ve created a new repository on my GitHub account where I can commit some of the little scripts I’ve written for use on my server. The first one I’ve committed is gitcreate, a small script that automates the creation and bootstrapping of git repositories.

I realized that, when I was creating a new repo on my server, I do the same things over and over. Create the repo, then add in some frameworks for whatever little thing I’m playing with at the time. Well, gitcreate can do all that for you. Create the repo and bootstrap in things like the most recent versions of CodeIgniter, jQuery, and Bootstrap. That way, when you clone the repo to start working, you’re already ready to start coding.

Like most of my stuff, it’s licensed under the New BSD License.

A small update to the Mac Oil Price Widget has been released. This fixes a couple of bugs that would cause all prices to be displayed as positive and for the percentage of change to not be accurate.

You can download it over on it’s page.

Because I’ve encountered this problem twice, I’m going to do a little write-up about it. As much for me as for the next person who encounters this problem. In a very un-Apple way, this process is very poorly documented and very un-intuitive from a user-developer standpoint. Everything that’s here, I’ve culled from Googling about aimlessly and finding on Stack Overflow.

**Symptom: **You create a new app in Xcode with no changes and launch it. It launches just fine. You then go to the target summary settings and click “Enable Entitlements” and have an iCloud key/value store and or containers. Now you launch it and nothing happens. Nothing appears, but Xcode still thinks the app is running.

**What’s Happening: **To understand what is happening, you have to go have a look in the Console application (note, the actual system Console.app, not the debug console in Xcode). Open that up and select “All Messages”. Look for something that looks like this:

1/28/12 7:49:03.945 PM taskgated: killed <your app ID>[pid 43838] because its use of the com.apple.developer.ubiquity-container-identifiers entitlement is not allowed

What’s happening is that taskgated is killing your app because it’s not properly signed to use iCloud. And for some reason that is not entirely clear to me, the app being killed is not at all reported back to Xcode - Xcode thinks the app is running. So you just sit there waiting for something to happen with no clue that this sinister lurking background process has killed your app.

How to fix it:

There are two ways you can go from here to fix this. The first and easiest, if you are just turning on entitlements and aren’t intending to use iCloud, you can just remove the iCloud Key/Value Store and iCloud containers from the target summary. After doing this, it should work.

But, if you are making an iCloud-enabled app, there’s a long list of things you need to do. First, understand that you need to be a paid member of Apple Developer Program.

1. Log into ADC. Go to the Mac Dev Center, and the Developer Certificate Utility.

2. Create an App ID by going to App IDs and clicking the Create App ID button in the upper right.

3. Enter the name of your app and the bundle identifier. It usually looks something like “com.company.app”. Click Continue. Your app ID should be entered.

4. Click the App ID you just entered, then click “Enable for iCloud.” Click save.

5. Next, go to Certificates. If you haven’t created any certificates yet, click “Create Certificate” in the upper right and follow the directions. Note, you need both a development and an application certificate.

6. Next, go to Systems. Be sure you’ve added your Mac (and, for good measure, any others you’ll use for development).

7. Finally, go to Profiles.

1. Click Create Profile in the upper right.

2. Select "Development Provisioning Profile"

3. Give it a name.

4. Select the app you created in step 3.

5. Select the certificate you want to use.

6. Select the systems you want to use (I did all).

7. Click "Generate" It may take a few seconds, then it will give you a download.

8. Open the downloaded profile. It will open in the "profiles" preference pane (which doesn't seem to appear until you try to install a profile). Click install.

1. Now, in Xcode:

1. Go to Window > Organizer.

2. Select "Devices" on the top, and "Provisioning Profiles" on the left.

3. At the bottom, select "Automatic Device Provisioning" at the bottom, and click "Refresh". If you've never done this before, you'll need to log in with your ADC username and password.

4. Give it a second, it should pull in your profiles.

5. Go to your project, select your app target and select "Build Settings." Scroll down to "Code Signing." You may need to go to "All" from "Basic" in the predicate selector.

6. Under Code Signing Identity, select the dev profile you just created. Note: don't use the wildcard one - it doesn't seem to work.

Whew. Now, if everything went as planned (and you sacrificed a goat to Tim Cook and Tim found your sacrifice pleasing) you should be able to launch your app with no errors.

But help! I got a weird failure on build!

If you get a failure on build that looks like this:

Command /usr/bin/codesign failed with exit code 1

Then it is possible that your developer certificate is set to “Always Trust” in Keychain. It needs to be set to “System defaults” for reasons that escape me entirely.

Note, this may not be entirely accurate and may even be cargo-cultish. But I’ve encountered this “issue” twice now (once in December, and once now) so I decided to write down my steps so that, in a few months when this befuddles me again, I’ll know where to look for the answer.