terrbear.org

ruby! food! kids! … and other fun from terry heath
RSS icon Email icon Home icon
  • RIP Jim Heath aka Dad

    Posted on June 27th, 2012 terry No comments

    So that sucks. He died on June 14th. I’m keeping most information relevant to his death on ripjim.terrbear.org. So this is really just to help people find it in case they visit the wrong site.

  • My First iOS App: A Retrospective

    Posted on May 22nd, 2012 terry No comments

    I followed the advice in the 4 hour workweek blog about creating my own app. On 10May12, I had my idea. I designed it over the next two days, and on the second day also posted job specs to some freelancing sites. Today it was published! You can view it here: Green Light Timeout.

    So, overall, a pretty quick turnaround. There’s a ton of stuff that I learned from this, though, so my next app should be better / cheaper / faster / etc.

    Research

    The app I wanted would be a timeout app for parents to show their kids their progress through timeout. A continuing source of frustration throughout this process, I used different devices at different points in time.

    When I was looking for competing apps, I looked on the iPad. I didn’t limit searches to apps only made for the iPad, but if you search on the app store using an iPad, it shows those apps first, which biased my research.

    As such, I didn’t have as good an understanding of what apps were already out there, what they did well, what they didn’t, and how I could make mine better. Fortunately (if I may say so, not so humbly), my app’s simpler than the ones I found, so I got a little lucky.

    Design

    I used the Blueprint app for the iPad to design the application. It’s fantastic, and I think made the spec I provided to the developer significantly more coherent and manageable. The questions the developer asked weren’t trivial or meant to clarify obvious functionality, and I give most of that credit to Blueprint.

    That said, since I’ve never done any iOS development before, I didn’t realize that a lot of things that Blueprint made easy (say, gradient buttons), aren’t apparently as easy to drag & drop in XCode. So there was a little bit of a delay in development where the developer was waiting for me to provide the right assets for the app (button backgrounds, the stoplight, etc).

    As far as technical specs, I think the more (useful) information you can provide, the more time you’ll end up saving. I wanted charting in my app. There’s a great, free library out there called core-plot, but if I hadn’t told the developer about it, I’m not sure he would have found it, and would have either spent time finding a library that does what I mocked up, or would have tried to write one himself, which would have been painful (both for him and for my wallet).

    Hiring

    Hiring a developer wasn’t as fun as I thought it would be, and I’m naturally impatient, which made things worse. First off, don’t rush to hire someone. In the whole scheme of things, a few days isn’t a big deal, and wasting a decent amount of money on a shitty developer hurts more than waiting through the weekend.
    I posted jobs to Freelancer and oDesk, and the oDesk responses I got were more impressive, though there were fewer of them (I think I had 3 oDesk applicants and 9 Freelancer applicants).

    You’re going to get a lot of bullshit submitted to you. You’ll also get a lot of recruiters/software shops, which aren’t necessarily bad, but it takes longer to figure out if you’re working with anyone competent that way.

    I asked a coding question in my job posting, and the first email I received that included an answer got me really excited. I wanted to rush back from lunch and talk to him. Then, when I actually opened the full message (Freelancer didn’t send the entire contents of the message to me), it was dead wrong. Not even “oh I could excuse it by …” wrong — totally, absolutely, unacceptably wrong.

    If you’re not a developer, ask one you know for a simple “FizzBuzz” style question. Then either find a way to vet the answers yourself or ask the developer to do it – if someone can’t code something that should take 30 seconds when they have all the time in the world (remember, they’re applying to *your* job), you don’t want to pay them.

    Development

    Once development started, the turnaround time was fantastic. I had apps packaged and sent to me daily.

    This wasn’t how I wanted to work, however. I tried to get the developer to use GitHub, because it has a lot of handy built in project management stuff (wikis, issue tracking, file repository, *git*) and I could review code changes that way.

    On the job posting, I said experience with git is a must, but I didn’t interview on that point. As such… he never learned how to use git. A lot of developers will have experience with Subversion, and GitHub provides a Subversion interface to their repositories, so instead of fighting with the next developer I hire, I’ll probably just show them the svn hookup and get what I want with little friction.

    I entered issues into the GitHub issue tracker and showed the developer how to use them, and that worked really well. Using GitHub’s milestones, I was able to figure out what needed to be done before we could release, and kept things on target. If you haven’t opened bugs before or worked with an issue tracking system, Joel Spolsky has one of the best articles on bug tracking out there.

    Overall, it took the guy 38 hours to code the app. It was longer than I’d hoped, but I realized towards the end that my expectations weren’t realistic.

    oDesk provides some pretty cool management tools when you’re working with developers. It takes screenshots of their desktop periodically for any time they want to bill you, which is great, since I could look to make sure I wasn’t funding someone else’s development. I saw the guy used Facebook and applied to other posts, but it didn’t bother me since the majority of the pictures show development on my app.

    Testing

    When I was testing the app, I used the simulator almost exclusively. It takes nice screenshots, it’s fast, easy to get running, etc.

    It turns out this was a huge mistake. The iOS simulator doesn’t (or at least I didn’t have it set up correctly) have power saving settings. Remember, my app is for showing kids their progress in timeout. My son is almost 5, so that’s 5 minutes, but the phone’s screen turned off after 1 minute. Now he couldn’t see the stoplight, and the app pauses if you leave the screen, so timeout stopped.

    I didn’t find this bug until after I’d ended the contract on oDesk, and I didn’t want to spend another $15 to fix it, so I found the right methods to call and did it myself. So, there, I coded 2 lines in the app.

    But the important lesson here is to use your app for at least a day on the device you’re planning to use it on. There’s no point submitting something super buggy to the app store; either you’ll get lucky and it’ll get rejected, or you won’t and it’ll get reamed by user ratings.

    Conclusion

    Overall, this was a blast. I really liked designing the app, working with another developer (I try not to spend too much of my off hours coding), figuring out how to make things look nice and feel usable and keep things under budget (if I’d spent over $1000 getting this built, I’m pretty sure it would have been my last – turned out it was about $600, so not bad at all).

    I’m not sure it’ll make money, but it was an invaluable learning experience. I’ll do it again. Feel free to go buy it and give it a nice rating :)

  • Bug-prone if statements

    Posted on December 6th, 2011 terry No comments

    I think I’ve seen more bugs from multi-expression if statements than anything else, especially once they’re combined with either an ‘else’ or if they’re used with an ‘unless’ instead of an ‘if’.

    I can’t tell you in <2seconds what conditions result in which codepaths. Whenever I come across code that looks like that, it gets changed into something a lot easier to read, even if it’s more verbose.

  • Commenting out code…

    Posted on November 18th, 2011 terry No comments

    Is a ghetto form of source control. Just delete it. It’s why you’re using /git|svn|hg|bz|cvs|evs/.

  • Searching playlists on Spotify

    Posted on November 16th, 2011 terry No comments

    It’s CTRL/Apple+F, in case you were wondering (I’d been for a few weeks).

  • Finger-detecting buttons

    Posted on November 15th, 2011 terry No comments

    We’ve a TV and a monitor that are both impossible to turn off in the dark because you can’t feel any buttons. The surface is entirely smooth, and by the time you find the power button you’ve already changed the input and enabled SAP.

    Easy fix: put a dot of glue by the button, near the edge of the device. Then you rub your finger along the side and when you feel a slight texture change, go 90° and bam, device is off.

    The glue also works wonders for chatty kids.

  • I need a way to enter a negative seed into Pandora

    Posted on November 15th, 2011 terry No comments

    Never play Coldplay. No, really.

  • Love:

    Posted on November 10th, 2011 terry No comments

    Firefox 8. Way less memory usage. Fast. Pretty. Firebug.

  • “You have to let people bring *something* for Thanksgiving”

    Posted on November 8th, 2011 terry No comments

    No I don’t.

  • When you can’t ctrl+c

    Posted on November 7th, 2011 terry No comments

    Not sure why CTRL+C sometimes doesn’t respond, but CTRL+Z almost always responds immediately. If you’re too lazy to look up the process you just suspended, you can do this: kill -9 %1

    And bang, it’s dead.