Draconis Software Blog

When I purchased an iPhone 3G (upgrading from the first gen), I also purchased the companion MobileMe service, and I’ve been giving it a test run since.  At the time, I was hoping for a replacement to Google’s Gmail, but unfortunately, it’s not quite there yet.  I thought I’d take a few minutes to offer some tips to the MobileMe Email team, as well as start a discussion on email services in general.

(Read the article)

Since Apple launched the App Store for iPhone OS 2.0, I’ve been keeping my eyes out for what might be the next killer app for the iPhone.  I’ve often thought the iPhone would be a game-changer in the mobile environment, allowing people to think of their phones in a new way.  These mobile devices are no longer simply a phone with added-on Internet access, but a complete communications and personal computer system.  With games and other non-communication-oriented apps the iPhone has achieved much towards this end, but there’s one additional category that has the potential to be a game changer in an unexpected way: internet radio.

The Pandora and AOL Radio apps are designed to allow you to stream radio to your iPhone or iPod Touch.  The introduction of fast 3G Internet access on the iPhone represents a significant threat to satellite radio and, to a lesser extent, terrestrial radio.  Consider the implications.  A user has an iPhone that’s the same size as an iPod (or a Sirius Stiletto) that can stream radio while in the car, walking down the street, or inside a building.  The iPhone can hop onto WiFi networks (same with the iPod Touch) or use 3G.  Even Edge connectivity allows for decent streaming.  All that adds up to great wireless access - as good as, or better than, satellite technology, since 3G and Edge connections work indoors whereas satellite doesn’t.

Accessibility aside, the real advantage is the phenomenal flexibility streaming radio provides.  Take Pandora for example.  It’s a streaming radio program for the iPhone that creates a customized radio station matched exactly to your tastes.  But even the simple ability to skip over songs you don’t like, a basic feature of Pandora, is inherently absent from any pre-programmed content station.  Such a simple feature goes a long way to improving your listening experience, and it’s almost embarrassing in the age of TiVo to not be able to skip over content you don’t find interesting.

With greater accessibility and significantly greater flexibility, streaming Internet radio will become one of the biggest threats to satellite radio over the next few years and will become a killer app for the iPhone.  Cell technology is getting better at providing high-speed Internet access, and already there are a number of very good streaming services that match listener’s tastes to music.  As the iPhone becomes increasingly popular among consumers and access speeds increase, satellite will suffer.  Satellite’s only hope to stay competitive is to offer enough exclusive content that listeners won’t be able to part ways with satellite radio without missing their favorite programs, but even that strategy is tenuous at best - it will only be so long before the content creators themselves decide to head for the greener pastures that Internet streaming radio provides.

Just a quick note about our new site design (if you haven’t noticed already).  We’ve put a lot of effort into redeveloping our site, hopefully conveying a fun, bright feel.  The main change, though, is what’s no longer visible: our network monitoring system RSP.  As a company, we’re moving in a different direction and have decided to make our site focus on our consulting efforts.

The Draconis Software website has gone through many different iterations over the years, and I’m particularly happy with the direction it’s going in.  As time goes on, we’ve worked hard to simplify our web presence, putting up only the most interesting and necessary information about our company and what we’re up to.  This has been one of the principal tenets of the web 2.0 design movement, and we’ve certainly practiced this with our clients.

But, enough about our thoughts on the site: we’d much rather hear what you think!  What do you like/not like about the new design?

There are many times during a project where I use the svn log command in order to see what has changed and to get a feel for the pace of development. It's also great when you're dealing with clients; you're only one command away from telling an inquisitive client exactly who did what task and when they did them. However, svn log is missing one important feature -- the ability to filter by a particular username. When I asked in #svn on freenode, they suggested I use the --xml option and parse the resulting output.

The following is what I came up with. It's a ruby script that uses the delightful Hpricot gem to parse the xml. It takes one argument, the subversion username that you wish to retrieve the logs for. I hope that it's useful for someone else! You can curl it from http://pastie.textmate.org/197763.txt if that makes it easier, too.

We strongly believe in using the right tool for the job.  While we currently think of Rails as the de facto choice when it comes to writing webapps, we'll always consider other options, such as one of the many other Ruby web frameworks, or going with another language such as Python.

Lately I've been looking for a chance to play with Grails.  Briefly, for those who aren't familiar, Grails is a web framework that uses the Groovy language - an agile, dynamic language designed for the Java Platform.  Grails was meant to use some of the main tenets of Rails (convention over configuration, "Don't Repeat Yourself", et al) while using Java web technologies like Spring and Hibernate.

Fortunately, I was finally able to find a chance to play around with Grails - as a simple way of "porting" an existing Java web application to a dynamic language and framework.  My reasons were the following, which I'd imagine are true for many other Grails developers:

1. The ability to include straight Java code in the project meant being able to re-use existing code, especially if it was not directly related to the webapp.  For example, I was able to take a terse image generation function and drop it right into the project.
2. Having the framework based on Spring, Hibernate, Acegi and Sitemesh meant there were fewer conceptual changes moving from the old code-base.  Working on the code I often felt that I was maintaining the original ideas while reducing the inherent verbosity of Java.
3. The previous point applies to the interface code as well - the views in Grails use GSP, which is very similar to JSP and made porting the views almost trivial.
4. Moving from another Java framework to Grails requires less of a "sell".  A Grails project packages as a WAR file no different from any Java project.  It will have all the positives (and negatives) of a Java app.

So, having used Grails a for a while now, how does it stack up to Rails?  Here a few of the things I enjoyed about Grails:

• The GSP tags have the power of JSPs, along with a few features that make them simpler.  They've also added some tags that don't have equivalents in JSP, and are quite nice.  In particular, I liked using the "sortableColumn" tag, which generates columns in tables that handling sorting.  This is something I would like to use in Rails.
• Grails does not currently use migrations (schemas are generated from field declarations in model objects), and while for some projects this could be an issue, it made development that much faster to add a few fields and have the database automatically be updated.
• By default Grails uses a messages.properties file that contains message codes like validation errors and other generic error messages.  In some ways it's nice having all these messages in one place. Also, the validation errors use a default message per constraint type, which can then be overridden.

 As well as some caveats (I won't go so far as to say "problems"):

• Grails uses some different terminology than Rails.  Models are "domain classes", validations are "constraints", and so on.  Not much of an issue, but it may take some getting used to.
• The form helpers in views are not as sophisticated as Rails.  Less boilerplate code is generated for you, and more thought has to be put in to maintaining states and values of form elements.

Of course, there's nothing that Grails does that couldn't be done in Rails with a bit of extra code or a plugin, and I'd imagine for the most part this is true for Grails as well, so it's really more about simplicity and core conventions.  I'm still working on the port, so I'll be sure add updates as I get more experience.

Update: There are some great suggestions in the comments as well.

There's a lot going on in the world of Rails these days.  This is great for developers, but sometimes it can be difficult to keep up with all latest happenings in the community.  In addition to changes in Ruby 1.9 and Edge Rails, there's a constant stream of news with regards to well-known Rails projects, emerging plugins and development/coding strategies.

Below are a few resources I use to stay up-to-date without experiencing information overload:

1. RubyFlow.com - This relatively new site is a great way to quickly see daily Rails news.  It was built by Peter Cooper (author of Beginning Ruby and the blog Ruby Inside).  Anyone from the community can post links on the site, or comment on posts.  I find myself visiting here multiple times per day to get a quick sense of what's happening and to make sure I haven't missed any important news.
2. GitHub - In addition to being a public git repository, GitHub has become a developer social network of sorts.  By following projects that interest you (including Rails itself), you end up with a single place to view all the commits that have happened on your projects.
3. Twitter - For the twitter users out there, there are a few options.  First, there's a user called rornews that you can follow, which posts links to Rails blog and job postings across the web.  You can also follow a number of members of the Rails community who are on twitter, including Obie Fernandez, Geoffrey Grosenbach, Ryan Bates, and why the lucky stiff (side note: anyone is welcome to follow me on twitter as well!).  Finally, you can consider using the tracking feature on twitter to follow "rails" or "ruby on rails".  This will give you a lot of updates, but if you're willing to sift through it you'll probably learn about news almost as soon as it happens.
4. Shared Feeds - I really like shared feeds (also called link blogs) as a way to see the best content filtered through a trusted source.  A few feeds to check out include Obie Fernandez, Geoffrey Grosenbach, and what appears to be "Matz" himself.  Or rather than following a single person, you try tracking searches for "rails" on FriendFeed or RSSmeme.
5. Blog Suggestions - There are a whole bunch of great Rails blogs out there, but if I had to choose the top 3 they would be the official Ruby on Rails blog, The Rails Way, and Ryan's Scraps (I find the "What's New in Edge Rails" posts to be invaluable).

If anyone has any other suggestions, please post them in the comments!

Just like Ryan, I've been in the process of moving to Gmail to handle all my email, now that they provide IMAP access. In no particular order, here are some notes and thoughts on the process of setting up Gmail IMAP with Apple's Mail.app:

1. Rather than restate all the steps I took, I'll link to this post that I found useful. In particular, configuring Gmail's Drafts, Junk, Trash and Sent folders to match those in Mail is nice.
2. The way Gmail implements IMAP wasn't very intuitive to me and took some getting used to. For example, deleting a message from a mailbox doesn't really delete it, it just removes that label (or at least that's how it's supposed to work; more on that later). I found this page helpful in getting used to how IMAP functions match Gmail actions.
3. I know this has probably been discussed ad nauseum, but I wish Gmail would loose the "labels" concept and move to "folders". While I've eventually gotten used to it within Gmail, the problem is only made worse with IMAP. For example, if a message has two labels, you'll see it in two folders, which means it'll show as two unread messages.
4. I figured as long as I was setting all this up, I'd use Gmail to backup all my old messages, as described by Ryan. This meant copying over my old mbox files, importing them to Mail, and moving them into the appropriate folders in Gmail. It's definitely a slow process, but you can view the progress from the Activity window (under Window -> Activity). There were a few times when the moving failed: I believe it was due to cases where messages had very large bodies. Although it failed partway through, I was able to start over without having any duplicate messages, so it looks like Gmail is smart enough not to add an exact duplicate.
5. To help speed the process a bit, I'd recommend turning off caching while doing any importing or moving of messages. This is done under "Keep messages for offline viewing" in the Advanced tab of the Gmail Account preferences. Once everything is set how you like it, you can turn cacheing back on. For a large number of messages the caching process can also take a while.
6. It took me a while to find a setup for my outgoing messages that works for me. In the past, I've had my email client set to automatically BCC myself on any emails I send. This way my messages get categorized properly, and my emails will be in the same mailbox as the rest of a thread. With Gmail, my sent messages were getting put into the Sent Mail folder in Gmail, which means I never got a chance to filter them into any labels. BCCing myself didn't help, since Gmail already had a copy of the message in Sent Items. What I've done now is to remove Gmail's Sent folder as Mail's Sent mailbox, which means the only copy that Gmail receives is the one that gets BCCed, which means I can have it filtered however I like. Update: Turns out I was wrong on this.  Any email sent through Gmail's SMTP will be added to "Sent Mail", so BCCing won't help.
7. An unfortunate annoyance with Gmail IMAP is that unless you have a message filtered to automatically archive (in Gmail context this means moving it to "All Mail"), it'll show up twice in Mail: once in the Inbox, and once in "All Mail". So far I haven't found a way to avoid this.
8. The filters in Gmail are rather basic and limited, especially compared to Mail. For example, I don't think there's any way to match messages whose subjects start with a string, instead of just containing the string.
9. Rather than set up a complex set of filters for all the email I get, I got an idea from Ryan to only create filters for less important messages, like automated log messages. Anything important will to go my inbox, and then I can choose how to label it or to delete it. This also has the benefit that on my iPhone, I can just check my Inbox and have important new emails in one place.
10. Although Google Help says that deleting a message will just remove its label, it won't necessarily work this way in Mail. Although deleting a message will remove the label (or if it's in the Inbox, archive it), moving it to the Trash will actually put it in the Trash, which puts it in line for deletion. I think you could prevent this by not having Mail's Trash mailbox be Gmail's Trash, but the whole "deleting a message to remove the label" feature isn't something I really need to use.
11. I love the new Todos in Mail, but getting them working in Gmail also required some changes. From what I can tell, you can have Mail store the Todos locally or on Gmail (although there doesn't seem to be a simple Preferences change for this). If it's on the server, each Todo is stored as an email, and if you want to specify a Calendar for an item, it means defining a new set of Calendars in iCal. If you store the items on the server, each corresponding message shows up in a nice human readable format, but unfortunately on the iPhone all you see is a Mime attachment. Hopefully in the future Apple will provide a simple way to access Todos on the iPhone.
12. Reading back on these notes, I see how complicated Gmail IMAP can be! I don't think it's quite ready for average users yet. That said, it's nice to know that 1) I now have all my email accounts coming to one place, 2) my old emails are backed up online, and 3) I can access all my email from my computer, my phone, or a browser.

One of the things I had been meaning to do for some time was to switch all of my email over to my Gmail account. The idea is simple: I have a lot of different email accounts, and it’d be great to keep them all in one place, backed up, and always accessible. So, setting up Gmail to access each of my different email accounts (well, five of the most important, and the rest just forward to my gmail address) was trivial. The hard part, however, was getting all my previous messages into Gmail.

Here’s a quick overview of how to get all of your old emails into Gmail as painlessly as possible (and one way that preserves dates!).

(Read the article)

Comments (12)

I just came across an article from the Wall Street Journal about Google’s plan to offer consumers a service to store their personal data files.  I’m pretty excited about this, and so should you, for several reasons.

First, mass data storage is getting cheaper and cheaper, but to really push prices down, it takes the economies of scale a company like Google or Amazon can get by combining thousands of users’ storage needs into a single service.  Providing a service like this will decrease the total cost per gigabyte to even lower levels, which theoretically could make it cheaper to sign up and pay for a service like this than to go out and buy a hard drive.

Second, Google usually does services right (not always, but usually).  It looks like they have an eye towards consumers, rather than businesses (like Amazon’s S3 service), which will, hopefully, mean good integration with your desktop.  I sincerely hope to see a tightly integrated OS setup where users can treat their Google storage service as “just another hard drive” on their computer.  I’d really rather not see some cumbersome client software you have to download, but rather a network share on your computer.

Third, and most important (to me at least), is the freedom from worrying about backups, redundancy, and scaling.  More and more, I’m watching movies and TV shows on my computer or home entertainment system via iTunes and similar services, and my storage requirements are expanding rapidly.  There will be a time in the very near future where I’ll need a terabyte or multiple terabytes to store my movies and TV shows for access, rather than as DVDs.  And I’m not alone: many people are doing just this, as everything becomes digitized and always available.

Anyway, it’s all still very early to get too excited about this service, but I really hope Google does this one right.  Keep it simple, no client software, cross-platform, and as cheap as possible is the way to win consumers here; and I know that now - and in the future - people’s storage requirements are just going to increase.

Sorry for the lack of posts lately - we've been pretty busy. We hired another software developer, and we've been working to expand our consulting business a bit. Unfortunately, the blog suffers for this, but it's not for a lack of interesting stuff! Over the last few days, we've had the fortunate experience to work with memcache and a number of other performance-related tools to help fine-tune a very large PHP codebase.

In addition, we've been putting efforts into invotrak (our invoice-tracking tool) along with other projects we're pretty excited about. We should have some details on at least one new site being launched soon, so stay tuned!