Review: Charles Proxy – Useful development tool; ugly interface

Posted on August 29, 2010 by Scott Gruby

During the testing of one of my projects, our QA folks mentioned a tool called Charles Proxy that they used to throttle the connection speed down to 3G speed as some issues can only be reproduced on slow connections. I pretty much ignored the product as I wasn’t assigned any bugs related to this. A few weeks later, I was assigned a bug dealing with 3G. As I really didn’t want to try to reproduce the issue on a device over 3G (the iPhone simulator makes it easy to reproduce issues, but as Apple points out, there is nothing like testing on a real device), I downloaded Charles Proxy and gave it a whirl. Unfortunately the limitations in the demo quickly required me to cough up the $50. As much as I was reluctant to cough up the money for an app that doesn’t look like a Mac app, it has already paid for itself.

Throttling down the connection speed seems to be one of the small features of Charles Proxy. It is a full tool for analyzing web traffic. When developing iPhone applications that talk to web services (which is pretty much everything these days), being able to look at the packets, headers, responses, XML results, and JSON results. In addition, it gives timing results for the requests so that I can see where slowdowns exist.

I’ve used it to determine that a client’s server was slow (they reported poor performance), that a different client’s web server wasn’t doing compression on text/plain files, and to see where I made incorrect requests to the server.

The major downside of the software is that the interface doesn’t look like a Mac app. As I’ve written before, I really dislike apps on the Mac that don’t look like Mac apps. Cross platform apps just aren’t my cup of tea.

 

Pros

  • Extremely useful for iPhone app development involving web services.
  • Lots of information about web requests; requests, responses, headers, etc.
  • Easy setup; it auto-configures the Mac proxy settings when it starts and changes it back when it quits.
  • Ability to throttle down the connection speed.
  • Lots of settings.

Cons

  • Ugly Mac interface.
  • A bit costly. (Maybe not for a developer tool.)

Summary

If you’re developing iPhone (or even Mac apps) that involve web services, Charles Proxy is an absolute necessity. If you ignore the ugly interface (I’m not talking about the layout, just the interface elements don’t look very Mac like), the app works well and gets the job done. It could be prettier, but the tool is extremely useful.

Posted in Main | Tagged , | Leave a comment

Review: PixelSkin HD Case for iPhone 4

Posted on August 25, 2010 by Scott Gruby

Today I received the PixelSkin HD case for my iPhone 4 through the Apple case program. I had been using a $0.99 case I purchased off eBay and was relatively happen with it. It’s really hard to review a case as it does so little, so I’ll mostly compare it to the $0.99 cases I bought off eBay.

First off, this is a hard plastic case (the one I was using was rubberized). This makes the phone feel more solid and it has a slight lip that may prevent the phone from being scratched if I put it face down on a surface. Second, the case is pretty tight fighting and doesn’t add much bulk to the phone. Next, the fancy pattern on the back definitely helps with gripping it as the plastic as a little slippery. Finally, the case is rigid enough that the small piece of plastic on the bottom connecting the sides near the dock connector doesn’t feel flimsy.

When I started looking for cases, I thought that since all the cases are made in China anyway, what was the difference between one off eBay direct from China and a name brand. Well, there are plenty of differences and the PixelSkin HD case feels like a solid case. If I didn’t get the case for free, however, I wouldn’t have known there was a difference (not that $20 is a lot of money to spend on a case, but cheaper seemed better).

Pros

  • Solid feel
  • Pattern on back makes it easier to grip
  • May offer some protection to the iPhone

Cons

  • On/off button feels hard to press

Summary

If you didn’t already receive your free iPhone 4 case from Apple, this could be a good case. I’d goto the Apple Store and give it a try. Cases are very personal and some like this type of plastic while others like rubbery cases. Some people just are too upscale for plastic cases and go for leather or some other material; in that case, this is definitely not for you.

Posted in Main | Tagged | Leave a comment

The art of billing

Posted on August 23, 2010 by Scott Gruby

It seems like such a simple task for a contractor; bill for the hours you worked. In my profession and how my brain operates, defining “work” is not easy. My brain doesn’t have an on/off switch so at the end of the day, if I was working on something, even if I walk away from the computer, I may still be thinking about it. Same goes for when I run, especially if I’m working on a hard problem.

Tonight as I was giving my son a bath, I realized that code that I had written today (based on other code in the project) could potentially crash in some race conditions. Do I bill the client for only the time that I’m typing? Do I bill the client for 24 hours a day just to make things easy? What is considered work and what isn’t? I don’t really have the answers to those questions; I look at things on a case by case basis. I’ve been doing contract work for a long time now and so far no one has ever questioned by time as I’m very honest and provide a detailed invoice with all of my hours and tasks recorded.

The next part of billing that doesn’t seem clear cut is during the day when I am at my computer, when do I start and stop billing? Do I round to the nearest 15 minutes? Do I bill for every minute? I’ve seen invoices from some contractors that recorded time down to the minute and even one with a fraction of a minute. Do they sit there with a timer and start and stop every time they read and email message? If they get a phone call, do they start billing when they see the caller ID? These just are far too extreme for me. I do reasonable billing and round my billing.

Finally, one area that I still haven’t figured out the best practices is handling interruptions and emergencies. If I get interrupted to work on something else (email, phone call, or instant message), it can take time for me to get back into the thought I had before I got interrupted. Best case it takes me few minutes, worst case, it can take me hours. Who do I bill for this? Do I bill the client that interrupted me or the project  was working on before the interruption? I don’t have a clue.

Luckily all these billing issues are minor and as long as I’m honest and ethical, no one has a problem with my billing practices. It also doesn’t hurt that I get the job done!

Posted in Main | Tagged | 1 Comment

Review: On The Job – Time Tracking for the Mac

Posted on August 23, 2010 by Scott Gruby

Before I became self-employed again. I looked for a time tracking application. I tried one on the iPad which was a complete waste of money. So, I decided to go back to time tracking on my Mac. At least I could evaluate the programs before buying. Over the years, I never found a program that I liked and eventually wrote my own little app. For various reasons, I was tracking time outside of QuickBooks (which I was using for account for my family’s LLC) and always ended up recording time and then generating invoices in QuickBooks. At that time, I didn’t need an app that also did invoicing, so finding a simple app was difficult. Now that things are different and I wanted to do invoicing in the time tracking app, finding the right tool became easier.

One evening I sat down and downloaded something like 10 Mac time tracking applications and gave each one a quick evaluation. I was willing to spend up to about $50, so that gave me a lot of choices. I settled on a program called On The Job. The interface is very utilitarian and Mac like, but its ability to create very professional looking invoices makes it a huge time saver for me.

You create clients and then jobs for the clients. Like many good Mac applications, you can organize things however you want. I created folders under each client for year, month and project (some clients have multiple projects that need to be tracked separately). I also created folders for the invoices (I do 1 invoice per client no matter how many projects). It allows you to round your time to the nearest 15 minutes (and a few other options). So far none of my clients has had issues with the way the invoices come out; I had one minor issue that I alerted the developer about and he said he might consider it for the future. The feature is that I work on the same task over many days and I’d like to just be able to record the task, start and stop the timer, and when the invoice is generated, have it create separate line items for each day. Say I work on bugs for 3 days straight, in the main view, I’d like to see Hours: 24, Start Date Monday, End Date Wednesday, but on the invoice have 3 lines.

The template editor for customizing invoices is very flexible and easy to use. I created a template, made a few tweaks and now I just crank out invoices every month with a few clicks. It also has this slick idle timer so if I start the timer and then walk away, when I come back, it asks me if I want to subtract my idle time.

Pros

  • Idle timer acts as a reminder when you forget to turn off the timer.
  • Flexible invoicing.
  • Ability to organize client and projects in pretty much any way you want.
  • Easily handle multiple clients with different rates.
  • Can setup rounding separately for each client.

Cons

  • Timer button from menubar is kind of useless for me due to my hierarchy of client, year, month, project. (At least the part to select a task.)
  • Timing Sessions aren’t that useful to me as it lumps all the sessions for 1 task into 1 line item on the invoice; if it separated it out, it would work better for me.

Summary

On The Job is almost perfect for me. I’ve been using it every work day for the last 3 months and other than a few nits here and there, the app works flawlessly and is out of the way. I have it running just about all the time and it definitely works better (for me) than any other solution I’ve found. I know that other people have more complex time tracking and invoicing needs, but On The Job was well worth the $39 I spent on it.

Posted in Main | Tagged , | Leave a comment

Three months of self employment

Posted on August 22, 2010 by Scott Gruby

It’s now been 3 months since I left my job and became self employed. As I wrote after my first month of being self employed, things are still going quite well. I really like my projects and even though I was recently put on a rush project, I like being able to show something for what I do every day. It should have been no surprise to me that enjoying work affects my whole life, but it is quite easy to forget it as I’ve been wrapped up in my work for my entire career.

While I wasn’t on the wrong track with my life, I now feel that things are going much better with me having time to relax. My side projects are kind of in a limbo state at the moment and will be winding down in the next few months. I’ve decided to not take on side projects for awhile which will be a huge change for me as I’ve had side projects going on (for the most part) since I left college 15 years ago.

I don’t claim to be a life coach or a motivational speaker, so take whatever I say with a grain of salt. I’m quite pleased with how things have worked out for me and am I’m going to do my best to keep on the same track and push work a little down in my priority list (work a full work week, but don’t work like a mad man).

Posted in Main | Tagged | Leave a comment

Review: Syma S107 RC Helicopter

Posted on August 22, 2010 by Scott Gruby

As a child, I had RC (radio controlled) cars a few times and enjoyed playing with them. However, they ate batteries like no tomorrow and since they weren’t rechargeable, play time was quite short. Years later, the battery technology has gotten a lot better and rechargeable batteries are in almost everything. As an adult, I’ve owned an RC Hummer and an RC hovercraft, but have never owned a helicopter. I’ve always been fascinating with them; however, I never made the leap into owning one.

Last week I was looking for something on the Internet and came across an advertisement for a company that sells RC helicopters. After a little research, I found a very beginner helicopter, the Syma S107, for about $30. I decided to give it a try knowing that it was a toy and I didn’t expect a whole lot from it given that some helicopters I saw cost significantly more.

Once I received the helicopter, I plugged it into USB and charged it for 45 minutes or so. My first few tries were not very good and had hard or crash landings. The blades are quite durable and seemed to handle my poor flying (however, I did order some additional main blades and tail blades off eBay).

Flying a helicopter is definitely not like driving an RC car; once you take your finger off the throttle, it immediately falls to the ground and crashes. Also, hovering isn’t as easy as just making it lift off the ground and leaving it there. You have to continuously adjust it to keep it in one place. I’m now 3 days into it and am starting to make progress at controlling it. My office is quite large and allows me some room to fly, but I keep hitting my desk chair (yes, I should move) or the base of my punching bag.

This little helicopter has definitely piqued my interest in RC helicopters and I’ll be going to a hobby store later this week to start drooling (I’m looking at the Blade mCX2).

I’ve been searching for a hobby for years; my hobby has always been writing software. However, I’m not really sure I can consider my work a hobby! I’m excited enough, that this little helicopter may have opened my eyes to something I didn’t know could be fun.

Pros

  • Inexpensive
  • Durable main blades
  • Durable body and landing skids (haven’t broken then, yet)
  • Easy to charge with USB
  • Replacement parts are cheap and readily available on eBay

Cons

  • Infrared remote; you basically can’t fly it outside and fluorescent lights could interfere with control.
  • Short flight time
  • Manual is poorly translated from Chinese
  • A little difficult to master
  • A lot of drift even with no wind; this could be all RC helicopters, but from what I’ve read, the better ones are easier to hover in place
  • Tail rotor is easily broken (it comes with a spare, but I’m already using it)

Summary

For $30, this is definitely a fun toy. However, I wouldn’t consider it a child’s toy as it isn’t easy to control. My 3 year old son drives my RC truck, but I wouldn’t consider handing him the controls to the helicopter. If you’ve never flown an RC helicopter before, don’t expect to be flying perfectly on the first flight. It will take some time to learn the controls and master flight.

The biggest downside I can see to this is that after the first taste of flight, you’ll want to get something better!

Posted in Main | Tagged , | Leave a comment

Developing iPhone applications with teams

Posted on August 13, 2010 by Scott Gruby

In my last post, I identified a number of areas that make developing iPhone applications with teams problematic and sometimes difficult. In this post, I’m going to present some of my ideas on how to make it easier.

  • Use source control. While this may seem obvious to most developers, there are certain aspects of development that people aren’t putting under source control. This includes, mobile provisioning files, certificates, and private keys. I’ll expand on these items later.
  • Give all developers the team agent credentials. Teams should designate one member to deal with provisioning (add devices and generate mobile provisioning files), but there may be a time when another developer needs to do it (someone is sick or has gone home for the day). This can be a security risk, but until Apple allows admin users in the provisioning portal to do everything that an admin user can do, this is absolutely necessary.
  • Each developer should create a separate developer certificate. While the developers should have team agent credentials, each developer should have his/her own account associated with the team. This will allow the developer to create a certificate and install the development builds on a device. I wrote about the process of generating multiple certificates with one private key which is important for developers working on multiple projects.
  • Check the distribution private key and certificate into source control. One of the steps in distributing an application either via AdHoc or AppStore is to create a certificate signing request for the company, upload it to the provisioning portal and then generate a certificate. After this has been done, the certificate and private key (exported as a .p12 file) should be checked into source control so that all developers can install the key and potentially generate AdHoc or AppStore builds.
  • Create a build script. Use bash or another shell to create a script that checks out the source code and builds the app. For extra credit, have the build script generate a .ipa file to easily distribute the app and then zip it up along with the mobile provisioning file. In addition, I have my scripts zip up the app and the dSYM file and place it in the source tree (I only checkin the AppStore builds as we generally have a lot of AdHoc releases). This allows any developer to analyze the dSYM file in case of a crash. My scripts name the output files using the svn revision and a timestamp to keep things straight. Lately I’ve modified my scripts to allow a developer to specify the trunk, a specific revision, or a specific tag. In theory, anyone can generate a build with no special knowledge.
  • Be careful with source control. This isn’t specific to iPhone development and applies equally as well for other types of development. When I start work each day or after a break in the day, I try to remember to update my source code. In addition, I always make sure I checkin my code at the end of the day. In addition, I check in groups of files at a time and avoid doing huge checkins as the more files I touch, the more chance of having a conflict with another developer’s changes. I use Versions for a visual Subversion tool. This makes it easy to see what files I’ve changed and then before I check in my changes, I diff the files to see everything that I’m checking in. I have Versions setup to use Changes to make it easier to compare the files. It does take more time to checkin my changes, but this gives me an additional opportunity to review my changes. If I try to submit and there is a conflict, I carefully review the conflicts.
  • Use instant messaging. I’ve been working from home for 11 years now, so I’ve been remote on just about every project I’ve done. I use instant messaging with other developers, our QA, and my project manager. While sometimes it is easier to call, a quick instant message is very valuable in collabarating. It allows be to bounce ideas off other developers and get more information on bugs from QA.

These are just some of my ideas; I’m sure I’ll have more and I’m sure not everyone will agree with them. My hope is that these ideas will help me work better on teams.

Feel free to comment and leave your own ideas for team development.

Posted in Main | Tagged | Leave a comment

iPhone Development and teams

Posted on August 13, 2010 by Scott Gruby

Since I’ve been self employed again, I’ve been working on 3 iPhone development projects. On 2 of the projects, I’m the lone developer (at the moment), with a QA resource and a project manager. On the 3rd project, at its peak, we had 5 developers, 7 or 8 QA folks, and a project manager. This last project has made it painfully obvious to me (more so than the other 2), that Apple has designed iPhone development around the loan developer that has no formal QA.

Why do I say this? Well, for a number of reasons. First off, the whole provisioning thing is quite problematic for a team. The concept that only the team agent can do AdHoc and AppStore provisioning is not realistic. The Team Agent has typically been someone that is the CTO of a company or someone else that is not involved in the project on a day to day basis. We have to pass around the agent credentials in order to do provisioning (admin privileges are not enough).

Second, Xcode’s Build and Archive is not maintainable for a team. If one person does the build, another person on the team may have to examine the crash logs and therefore need the dSYM file in the archive that is built. The archive needs to be checked into source control, but Xcode hides it somewhere else.

Third, with Build and Archive in preparation for deploying as either AdHoc or AppStore, the developer is building the app from his local source tree. Almost all projects that I work on are built using a build script so that the builds are done from source control in order to have a reproducible build. Building an app from the local source tree is quite dangerous as a developer may have forgotten to check in a file and then the next person comes along may not be able to build the app.

Fourth, Xcode’s managed provisioning isn’t all that helpful. It generates a completely wildcard provisioning file which I’m not really sure how it affects different apps when there are different app IDs. In addition, most of the devices that are provisioned aren’t on developer machines, but are QA devices and other devices.

Fifth, the 100 device limit for AdHoc provisioning may sound like a lot, but if you have a team with 5 developers, each with 3 or 4 devices (iPhone 4, iPhone 3GS running 3.1.3, and iPad), and then have 7-8 QA folks with 3 devices each, you can see that the devices get eaten up quite quickly. This isn’t even considering all the devices a client may want to use for testing. I understand that Apple doesn’t want people using AdHoc provisioning to get around the AppStore, but here is a case where we’re doing the right thing and could run into issues.

Sixth, Xcode’s ability to deploy an application to the AppStore is another area where it is problematic for the team. This requires that one of the developers does the submission. In theory, QA should do the upload once the build has been approved. The way around this, of course, is to use the Application Loader to handle it. However, the Application Loader application is half baked and very much geared to only working on one project. You have to go back through the setup wizard to change accounts (I’ve done uploads for 3 different projects).

While it is true that probably 95% of iPhone development is done by single developers, some of the top applications are done in teams and I think the teams are still trying to figure out the best way to handle development.

In my next post, I’ll outline some of my ideas/practices for effectively working in teams on iPhone development.

Posted in Main | Tagged | Leave a comment

Abstract Photo

Posted on August 8, 2010 by Scott Gruby

My son loves playing with our camera and takes lots of pictures. Most of the pictures are blurry and we delete them. However, sometimes he takes a picture that looks pretty good. He was playing in my office a few months ago and took a picture of the mouse pad (a funky HP one; it was the largest one I could find with a smooth surface).

Click on the picture on the left to see a larger version.

Posted in Main | Tagged , | Leave a comment

Open source is not always the answer

Posted on August 8, 2010 by Scott Gruby

I’ve been a huge fan of open source software for years and have contributed back to a few projects including the Palm OS Emulator and pilot-link. I’ve used a number of open source projects in my own applications and, of course, follow the license for attribution (I don’t touch GPL code). Years ago when I was a lot greener, I used open source thinking that it must be perfect and treated the code at black boxes. This bit me on at least one project where we had to fix the code for years due to assumptions by the developer.

Now that I have more years under my belt and have done some of my own open source, I take a different view of open source. When I incorporate open source into my projects (with a few exceptions such as Sparkle that has been thoroughly tested), I closely examine the code and make sure I understand it. This takes time, but makes it less likely that I’ll get bitten. I’ve seen a number of projects where developers find open source, shove it in an app, and call it a day without understanding what it does. I found one piece of code that completely went against what Apple has said to do in determining if a feature exists on a device; in another application, I found extremely complex networking code that may have been unnecessary (networking code is hard and the more complex it is, the harder it is to debug).

The main thing to realize with open source is that it was written by humans that can make mistakes and do! I have a large collection of open source code on my machine for reference (someday I’ll catalog all that I’ve found) and use it to save time. I’m not saying that developers should reinvent the wheel for every piece of code, but they should be cautious when shoving code in their applications.

Posted in Main | Tagged | Leave a comment