Professionalism and respect: raising the bar for developers (and myself)

By · Published · business, ramblings

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.



gitcreate

By · Published · git, linux, php

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.



The Right Way to Create an iCloud-enabled Mac App in Xcode

By · Published · apple, objective-c, xcode, mac, osx

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.
  8. 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.


What An Awesome Future We Live In

By · Published · ramblings

Sometimes it's easy to forget what an amazing modern world we live in. Even if I think back just 10 years ago, it blows my mind how much has changed. Just in technology, even.

In 2002:

  1. Nokia was the largest cellphone manufacturer. Their top selling model that year was the Nokia 6100. I actually had one of these as a loaner phone once. At the time I was carrying this more modest model - a Qualcomm QCP-2700, complete with green screen.

  2. Tablets as we know them today didn't exist. Oh sure there were primitive early tablets - Palm Pilots and the Newton come to mind. But they had as much in common with today's tablets as a horse does with a Ferrari.

  3. HP was the leading computer manufacturer that year - following their purchase of Compaq. The same HP that almost sold it's computer division late last year.

  4. Facebook and Twitter didn't exist, and the best site on the web for tech news was still Slashdot. Wikipedia had just opened the year before and was still seriously lacking content.

  5. Mac OS X 10.1 was released that year, and I spent all summer lusting over the Titanium Powerbook G4 with it's PowerPC processor running at a blazing 800 megahertz and a huge 40gb drive.

  6. If you wanted to read a book, you bought a paper book. e-Book readers, while the existed, were clunky and difficult to use, and titles were mostly restricted to technical publications. Nothing like the Kindle, Nook, iPad and other readers.

  7. Using the Internet on a mobile device, if it was available at all, was extremely limited. Remember WAP? I remember being amazed in college that I could use my phone to check the scores of other games while I was at an Auburn game.

  8. Wanted to find your way around? You had a map or directions. GPSs as we know them today didn't exist, and certainly weren't integrated into phones.

Contrast that to today. The phone in my pocket is more powerful, has more storage, than that laptop I spent a whole summer lusting over, and can be used to surf the web just as well as any computer. The tablet I carry with me has access to a whole library of books, can connect wirelessly to the Internet almost anywhere, and can be held with as single hand. If I ever get lost, I can pull up a map on my phone that pinpoints my location to within a few yards of my area, and can give me turn by turn voice directions to get where I'm going.

Facebook and Twitter connect millions of people together. I can even connect to the Internet on my laptop _in an airplane at 35,000 feet! _Downstairs, I have a 60" widescreen TV that's 1.5" thick and weighs so little that I could mount it on the wall.

Every time I hear people complaining about how things suck, I'm reminded of this video. Because everything really is amazing right now. We are living in an amazing futuristic world full of fascinating advancements that are are happening all the time. And what is most amazing of all is how quickly we got here. The world of tech between now and 10 years ago are so different.

What will the world of 10 years from now be like?


Mac Oil Price Widget, Version 2.0 released

By · Published · apple, dashboard widgets, dashcode, mac, osx

After a far longer wait than was intended, the Mac Oil Price Widget version 2.0 has been released.

It was completely rewritten – like, I didn’t even look at the old code – and uses Bloomberg Energy as it’s information source. The display was also simplified – I really didn’t care about the chart in the old version, so the new version prominently displays the price and how much it’s changed.

Download Here!


dystill 0.2.1 released

By · Published · dystill, e-mail, python

Just a little announcement about a maintenance release to dystill. 0.2.1 has been released, which brings with it a couple of bugfixes for issues I ran into recently. First, it will now optionally try to create new maildirs when they don't exist (this is configurable in the config file). There's also some more error checking to hopefully prevent crazy behavior.

As always, the source is on github.


PHP, methods, functions, and the global scope

By · Published · php

It's funny. Even after nearly 10 years with the language, there are still little gotchas that sometimes get me. I ran across one today.

Say you have two objects, and the look like this:

<?php
class ObjA {
    public static function test() {
        global $test;
        var_dump($test);
    }
}

class ObjB {
    public static function test() {
        $test = 1;
        ObjA::test();
    }
}

ObjB::test();
?>

It doesn't work. You get NULL.

Say I were to do something like this:

<?php 
class ObjB {
 public static function test() {
     $test = 1;
     global $test;
     var_dump($test);
 }
}

ObjB::test();
?>

You also get NULL. And this:

<?php 
function a() {
    $test = 1;
    b();
}

function b() {
    global $test;
    var_dump($test);
}

a();
?>

Also fails.

The reason is that the global scope on PHP is just that: global. Any time you're in a function or method, you're in a local scope and all local scopes are independent of each other. So you can't global in something from one local scope to another. Variables are either global or local.

That much I get and makes sense (and is in the documentation). What threw me for a loop was that PHP won't copy something into the global scope from a local scope that is already defined *and will happily overwrite your local scope with a null value from the global scope if one doesn't exist in the global scope, *in the process of creating the variable in the global scope. If you want a variable in the local scope to be global, you have to declare it as global before you write a value to it.

Or, to put it another way:

<?php 
class ObjA {
    public static function test() {
        global $test;
        var_dump($test);
    }
}

class ObjB {
    public static function test() {
        global $test;
        $test = 1;
        ObjA::test();
    }
}

ObjB::test();
?>

Works beautifully.


App Store Entitlements, and the Crippling of an App

By · Published · apple, objective-c, xcode, mac, osx

A few months ago, I decided I wanted to try exploring the Mac App Store ecosystem as a developer. I've been writing little Objective-C apps for myself for awhile, and I decided I wanted to see what it was like from the other side.

So I wrote this little app called Airplane Setting. It was a stupid simple little app that made it easy to turn off your radios with a single action. I wrote the app and paid my $99 admission fee. And after a month of back and fourth with Apple and a couple of rejections for what I consider to be dubious reasons as best (especially seeing as how I could point out existing apps in the store that broke the "rule" they said my app was breaking, but whatever, their store, their rules...), my little App was finally approved for sale. It did moderately well, passing 1,000 downloads with virtually no advertising from me.

I had big dreams for this little app. Plugins, global hotkey support, localization, Applescript support, and more potential functionality. But all that was dashed by "Entitlements" and Apple's requirement that all apps must be sandboxed.

Look, in theory, the idea of sandboxing an app is not bad. The problem here is Apple's all-or-nothing approach to sandboxing. The selection of entitlements are just so limited as to be nearly useless for anyone creating a unique, new or complex app - especially one that requires hardware access. Your choice is either to sandbox your app, choosing from the available selection of entitlements, or not sandbox it and not be in the Mac App Store at all starting in March. There's no reason to only provide such a limited subset of functionality that a developer must choose from. Would it not be better to provide us a wider set of entitlements and allow us to justify our reasons for needing them when we submit our app?

The reason Apple gives for requiring sandboxing is to prevent "rogue apps" from destabilizing the system. But when you consider that the App Store itself is curated, this requirement makes even less sense. If Apple is curating the store, how does a "rogue app" end up in the App Store?

I'm a huge Apple fanboy. I have almost all Apple hardware in my house, from my iMac to my Macbook Pros, to my iPad and iPhone and my wife's iPod Touch. I had AppleTVs before they were cool (and there's one on every one of my TVs now). I love Apple. But as an developer ... I [expletive] hate Apple for this "innovation" that crippled my once-promising little app.

So, at this point, my options are:

  1. Leave Airplane Setting in the App Store. Doing so will mean no further updates so I'll likely cease development.

  2. Remove Airplane Setting from the App Store and start distributing it exclusively from the website.

My original intent with Airplane Setting was to explore what it was like to be an App Store developer. I guess ... now I know what it's like to be an App Store developer, and living in constant fear of Apple as a sword of damocles hanging over your head.