Draconis Software Blog

Just a quick note to let you know about the new invotrak.com blog, launching today. If you’re not already aware, we launched a new online invoice-tracking service recently, which helps freelancers and small-businesses keep track of the invoices they send to clients. The service is free, and we’ve seen quite a few people join up.

The blog is to keep much of the invotrak-related content in one place (without cluttering up this blog). It’ll have invotrak-related news (new features, notices, etc), as well as original content we think is of interest to users. If you’re interested in freelancing/entrepreneurship/etc, you may find the invotrak blog interesting.

Just like every other techie in the world, we recently got our hands on some iPhones.  And, as software developers, our first thoughts were: what can we write for this thing?  Well, as everyone else has already pointed out, you’re pretty much limited to writing web apps for the iPhone only, but this doesn’t impact us as much: we’re doing web apps exclusively at the moment anyway!  I’ve been looking into creating an invotrak app for the iPhone recently, and believe I should have something available in the near future.

Craig Hunter has a good article up on his site that discusses some of the limitations of creating applications for the iPhone, though his standpoint is coming as a traditional Mac developer (and he makes great points: it doesn’t make any sense for a user to connect to a web app to input to-do list items):

Business aspects aside, the main issue I see as a traditional developer is that iPhone web app development is still very limited. Outside of some viewport settings, a couple special link types (really only the “tel:” link is new), and some new “-webkit” style attributes, there is little about making iPhone-specific web apps that differs from generic web apps. And that’s possibly the most disappointing aspect of all from my standpoint. Apple’s announcement states that “developers can create Web 2.0 applications which look and behave just like the applications built into iPhone”, but that’s not the case.

I believe there’s a lot that can still be done with the tools we’re given, and I look forward to Apple creating more tools in the future.

Comments (1)

A friend alerted me to an article he put together recently regarding deployments in a custom build environment.  It’s intriguing, as my own software company has a similarly-setup system.  The idea is to keep logs of deployments on a MediaWiki-powered internal wiki automatically, allowing developers to see what repository revision was rolled out, the build version number, along with other salient information.

For our internal processes, we wanted to keep a running list of the code release version (such as “0.9.1″), the SVN repository revision that was deployed, the timestamp Capistrano used as the folder name in the Releases directory, and a more human-readable date and time of deployment. The first field, the release version, is an arbitrary string given by the person making the deployment; Capistrano prompts the deployer for this string as the first step in the deployment. The repository revision and release timestamp are both provided by Capistrano, and the human-readable date is provided by Media Wiki.

Some additional coolness: automatically linking to BugZilla bug numbers whenever they’re referenced in the commit messages, and automatically creating “readme” files containing commit messages for each new build.  Check out the article here.

FaceReviews.com looks at the common traits in successful Facebook applications: Branding, Engaging, Viral, Useful, and Smart (or BEVUS, admittedly not the best acronym ever devised).  Although they’re looking at Facebook apps in particular, these traits more broadly apply to successful web applications in general.

I think some of these characteristics are sometimes looked at as being more than others. For example, being “viral” is considered an important part of bringing a steady flow of new visitors to a site. However, equally important in my mind is filling a real need for the user, and doing it in an intelligent way.

I also think these points nicely show the melding of the big picture ideas with the smaller, more technical details. Specifically, “branding” and “engaging” apply to the general concept of a site, but shouldn’t come at the expense of how the site handles the design and interface of the smaller details (the “useful” and “smart” aspects).

This is a programming quickie, but can be one of those gotchas if you don’t know what to look for. As I mentioned recently, I had to temporarily switch back to the Windows side of things when my MacBook died, and in doing, had to learn new tools for getting my work done. One of those tools was to replace Cyberduck, which I used to open a remote connection (via SFTP) to edit files live. Well, I was recently working on a Ruby on Rails project, and I noticed a strange side effect: whenever I would edit a file (a view, controller, etc), and hit reload in my browser, I never noticed the change. It could be the simplest or most complex, but it never seemed to appear unless I restarted Mongrel.

Turns out the problem was actually quite simple: WinSCP, the replacement I was using for Cyberduck, was set to preserve timestamps on files by default. Mongrel checks timestamps of files to determine whether to reload them live (in development mode, mind you, where I wasn’t doing any caching), and these timestamps need to be changed by WinSCP in order to show up to Mongrel.

To fix the problem, just click the Preferences icon in WinSCP, click the Transfer selection on the left, then uncheck the “Preserve timestamp” option under Common options. This should now update timetamps correctly and your changes should appear to Mongrel. Enjoy.