Living the startup life in Atlanta, GA.

It’s often difficult to explain the complexities of building software to those who are more used to traditional manufacturing or development processes. Cranking out code just does not relate to building 1000 widgets. Therefore, we’re normally pretty hard pressed to find a way to communicate why projects seemingly always end up being over-budget and late.

This weekend’s experience with a garage door opener leads me to believe that the most applicable comparison is a home improvement project. This was supposed to be relatively simple project. I had a chain-drive opener that went bad, and a new one sitting in a box. Really, this should have involved 4 nuts. But of course, since the openers were from different manufacturers, nothing was compatible. Instead of just having to replace the drive, we replaced the rails, chain, mounting hardware, and the little warning system. Obviously, since I hadn’t planned on a massive overhaul of the system, I ended up having to make multiple trips to Lowes. Eventually, I ended up with a working door, but one that took 3x long and ended up costing a bit more than I planned. Sound familiar?

The real comparison is that like with software development, home improvment projects normally deal with areas of non-expertise. I’ve never installed a garage-door opener before. If I had, I would have done a lot of things differently, probably from the point where I bought the door. Software’s the same way. I have a good amount of experience writing software, but that’s like having a good amount of experience using a screw-driver and a drill. I know how to use the language, I know a lot about the other available libraries, but I’ve never applied them in that manner before. That’s where the real excitement and the challenge lies. Often, what seems simple on the surface opens a rabit-hole. Some times, things are as easy as they seem. You just never know how it’ll turn out until it’s done.

So the next time you’re boss asks what took so long, as them what happened on their last DIY project. It’ll be a good starting point to gain a common understanding.

Not to long ago I got really sick of the variable white space between the content and the side bar. My CSS isn’t the best and my first attempted at a two column layout with divs was to use percentage widths to keep the columns separate. This looked pretty ugly, since the side bar should be a fixed width. There isn’t much benefit for it to be resizable.

I switch the layout to abosolutely position the right column and then added a large margin to the right of the left column to keep the content clear of the sidebar. The positioning CSS now looks like:

#content {
min-width: 370px;
margin-right: 270px;
position: relative;
float: left;
}

#sidebar {
width: 270px;
position: absolute;
right: 15px;
margin: 25px 0px 2px 3px;
}


This had the unintended effect of covering up the content when the screen was abnormally small, such as when I view the site with the Mylo. The site was rendered unreadable. The solution for this took a lot longer than I would have liked, but was pretty simple little bit of JavaScript:


/****************************************
* Script to re-float a column when the
* browser window becomes too small
****************************************/

The javascript is pretty simple. All it does is register listeners for page load and window resize. Then it changes the appropriate style properties to drop the side bar below the content on small screens. The "$('variableName')" syntax is a nice shorthad for getElementById provided by the Prototype Javascript Library. To try out how it works, just make your browser window really narrow then wide again. The side bar will drop down and pop back up appropriately.

One of the neat things about my new Mylo is the fact that it has a real HTML browser, but the fact that I can view normal web pages is a double-edged sword.  A lot of sites have checks to see if you are browsing with a small screen WAP browser.  These checks will fail if you browse the site with the Mylo’s browser.

One notable example of this is the Horde Project.  Horde allows you to redirect directly to the mobile mail client MIMP if it detects a WAP browser.  Of course, when using the Mylo, this check fails.

My rather kludgy solution to this problem is run another version of Horde that only contains the MIMP plugin. For the most part, this is just a repeat of the standard MIMP installation instructions.  If you already have Horde installed, this should only take a few minutes.  After getting MIMP installed, you will still find yourself redirected to the main horde index.  To get horde to redirect to the inbox after a successul login, you’ll have to add a line like:

Redirect permanent /mobile/index.php https://vijedi.net/mobile/mimp

to your Apache config.

The big drawback to this approach is that you lose access to the administration functions.  However, I have yet to find a better solution.

In a recent blog post, I talked about getting an small internet capable device. As this post’s title suggests, I decided to buy the Sony Mylo. Obviously, this decision was somewhat difficult, only partially because Sony is evil. The bigger problem was that convergance really hasn’t happened yet for small devices. Sure it would be cool to have a multi-facted, swiss-army knife portable gaget. But we have that device, it’s called a laptop. Getting any smaller and cheaper requires you to give up something (or buy more than one device).

The end result is that I bought the mylo knowing that there would be problems and annoyances. This has been true to some extent. However, what I didn’t expect was just how useful the device is. Last weekend, I attended the Atlanta Java Symposium (aka No Fluff, Just Stuff). The mylo performed admirably. I was able to jump on wireless networks with ease. Even the encrypted networks at home and at the office are are breeze to use. One potential drawback is that it does not support WPA2 Enterprise. However, since nowhere I go uses that level of security, this hasn’t been a problem for me.

The screen is plenty big enough for web browsing. The mylo runs an embedded version of Opera, and is therefore a real html web browser, meaning you can visit all of your favorite sites. The only drawback is that many sites don’t render well on a 320×240 screen. Some of the best sites are the low image version of BBC news. Many sites can be made quite enjoyable to view using the “fit to screen” function of Opera, or by viewing the printed version. One example of a site that completely sucks on this thing is Slashdot, which refuses to become compact.

Another extremely useful feature is the ability to save a site to the Mylo’s flash memory. This has been handy in saving directions for short day trips. I’d rather have a small compact device than a few sheets of paper that always seem to get stepped on.

The mylo does not have an email client, however, this problem was quickly rectified by installing the mobile version of the Horde Project’s email client.

Along with a web browser, the Mylo uses Skype, Gtalk, and Yahoo! for communication. Skype and Gtalk work wonderfully. It takes a while to adjust to the keyboard, but after that, typing speed is decent. I think I’m much faster on it than I would be with grafitti. The sound quality with Skype is extremely good, though I don’t really skype much yet. Yahoo’s client doesn’t seem to be as good as Gtalk’s, and there’s no AIM. These aren’t deal breakers for me, since most of the people I know are hard-core Google fans.

The Mylo also includes support for playing MP3′s and Mpeg4 movies. However, I haven’t actually used these features yet.

At $350 (plus tax) it’s a bit pricey. It’s the price of a used laptop on ebay. A few hundred more could get you a new laptop without the software restrictions. However, the mylo is much smaller, can be used the whole day without a recharge, and can do most of what you would want to do at a hotspot. That alone made it worth it for me.

Despite the philosphies of Google, I still like agile development methods. I’ve seen the pitfalls of “we’re not releasing until perfect,” and the significant negative impact it has on developer morale. It’s rather comforting to know that something is getting released at the end of 30 days. Which isn’t to say that I buy into all the mumbo-jumbo that daily meetings way to early in the morning and mandatory pair programming make me more productive. Clueless management is clueless managment regardless of the methodologies they employ.

Unfortunately, most developement management techniques get defenestrated when dealing with a new open source project that might only get a few hours of attention a week. To me, the most sensible approach is to borrow the idea of iterations and estimation from agile technologies. Logically, it makes a lot of sense to have groups of feature sets laid out into prioritized buckets. The estimation helps because having an idea of how long something might take makes it easier to schedule time in a somewhat busy life. This organization also makes it trivial to scale the project beyond a single developer. The key technology to make this possible is an issue tracker. And there’s the rub.

There seems to be a darth of decent, easy to use issue trackers powerful enough to meet the needs of a new open source project. I defined the requirements as easy to setup, support multiple projects, and it must be customizable enough to put things into prioritized buckets. For this kind of work, I prefer priority levels instead of distict priorities, simply because I might not have the time to work on the most important thing. This is how I felt the projects I looked at compared:

1. Jira:
   I think Atlassian’s Jira is far and away the best issue tracker that I’ve ever used. There might be better ones out there, but I have yet to see them. Jira is immensly customizable, the interface is relatively intuitive and streamlined, and it has many built in reports that allow the project manager to track how the development team is doing. The use of some features is greatly diminished when the project manager is the development team. I have minimal experience with Jira for administration or setup, so I can’t comment on that. For the day to day and project managment needs, I don’t think it can be beat. Adding a new issue is easy and simple to understand. Feature’s like bulk change streamline the process of organizing issues into iterations.

   Given a choice, I’d use Jira for my personal projects as well. However, in order to get the version for open-source, you must have an established code base. So far I have rails scaffolding, so that option is out. Buying it outright is also impractical, since the base version costs $1200. Therefore, I started to look elsewhere.

2. Xplanner
   Xplanner is an issue tracker designed for people using XP and related agile methodologies. Xplanner was easy to set up, and the feature list on the front page claimed that the product could do all I needed. However, everything I tried, beyond creating a new issue, failed the five minute test. I couldn’t figure out how to add things to buckets, create reports or move around the interface. I guess I’m not an eXtreme enough programmer.
3. Bugzilla
   I was told by many people I trust not to even go there.
4. Scarab
   The same group that put out Subversion have created an issue tracker called Scarab. Like XPlanner, Scarab failed most 5 minute tests. However, unlike XPlanner, after 5 minutes at least I felt like I had gotten somewhere. Eventually I was able to figure out how to customize it for my needs, as well as create some reports. On the whole, I feel it has the most Jira-like interface, and once it’s been set up, the workflow for getting things done isn’t too bad. It’s far from ideal, but I’ve decided to stick with it for now.
5. Honorable Mention:
   Trac is a nice looking python based issue tracker. However, since I don’t know python and how to get it running under Apache, I decided to pass for this round.