I’ll be at SXSW from Friday afternoon through Tuesday, and would love to get together with any of my readers who are going to be there. Give me a call at 888.670.6793 ext 2, which will forward to my cell phone, or send me an email through the BuildingWebApps contact form. I’m not much of a Twitterer, but I’ll try to post occasional updates about where I’ll be during the conference, so you can also follow me on Twitter as mzslater.

The RailsQuickStart seminar that my colleague Christopher Haupt and I will be presenting in San Francisco next week is filling up fast, so if you’ve been thinking of attending, now is the time to sign up. The seminar is February 20 and 21 at Fort Mason in San Francisco.

We have a packed two days planned, divided into lecture sections in which we’ll explain how Rails works, live coding sections in which we’ll build a complete application step-by-step, and lab sections in which attendees will extend the sample application. Everyone will also get a one-month hosting account, courtesy of Joyent, and before they leave the seminar their app will deployed. We’re including customized Capistrano scripts and and a subversion setup.

If you’ve been wanting to learn Ruby on Rails, or if you’ve been playing with it but have struggled to climb the learning curve, this is your chance to move into high gear.

After several months of development, we have finally taken the wraps off the BuildingWebApps site!

Note: I won’t be publishing any more Ruby on Rails or web development articles on this blog. This will be more of a personal blog, with everything related to web technology going on the new site. To continue receiving the Rails articles that I and my colleagues will be writing (and we have plans for lots more articles than I’ve been able to publish here), please subscribe to the BuildingWebApps articles feed.

You can also subscribe to the BuildingWebApps blog, where I’ll be writing about the process of building the site and the business.

State of the site

BuildingWebApps.com is still very much a work in progress, but we’ve gone ahead and opened it up so we can get feedback. Please take a look and let me know what you think.

We worked with Josh Woodlander and Ethan Allen at Raspberry Media on the visual and interaction design, and I think they did a fantastic job. It was a joy to work with people who have such a strong sense of graphic design and who think deeply about the challenges of effectively presenting lots of information. And Ethan is a wizard at making all the browsers behave reasonably. (Any oddities you see are probably the result of my modifications.) If you’re looking for a team to take on a significant web design project, I highly recommend them.

My goal is to build this site into a valuable resource for the Ruby on Rails community, and for people who want to learn Ruby on Rails. Over time, we’ll increase our coverage of other web-related technology as well.

The site includes both original articles and an annotated, organized set of links to hundreds of other resources around the web. We’re in the early phases of building up the content, so I realize that it will seem a little thin in places (and if you’ve read the Rails-related articles on this blog, some of it will seem very familiar). But there’s lots of great stuff to come.

I’m really interested in feedback on the usability of the site. You can also submit suggestions on the site to help us build up the content.

How is this a business?

In case you’re curious about the business model: we plan to make all the core content free indefinitely. At some point, we’ll add some premium content that will require membership or a one-time payment. We’ll probably have advertising. And we’re offering seminars.

Longer term, we believe that the application we’re building to power this site will be applicable to many other knowledge domains and communities. Blogs and wikis are all the rage, but they both have huge limitations that we believe our platform will overcome.

Don’t forget to change channels

Once again, please note that I won’t be publishing any more Ruby on Rails or web development articles on this blog. I will continue this blog to write about a variety of topics beyond web development, so please keep your subscription here if you’re interested in my random thoughts. But if you subscribed to this blog primarily for web development information, it’s time to move on:

• To continue receiving the web development articles that I and my colleagues will be writing, subscribe to the BuildingWebApps articles feed.

• To read about the evolving business of which BuildingWebApps is a part, subscribe to the BuildingWebApps blog.

Thanks!

A little more than a year ago, there really was only one Rails book: Agile Web Development with Rails, by Dave Thomas, David Heinemeier Hansson, and friends. Since then, about a dozen Rails books have come out. None of them, however, has replaced this seminal book as the best general resource for Rails developers.

This is not to say that there have not been some excellent books. Some do a better job at providing a gentle entry for beginners, others focus on specific areas, and many provide interesting example applications. But they are mostly tutorials, rather than references.

The Rails Way (Addison-Wesley Professional Ruby Series)

The Rails Way changes this. It is a better Rails reference than the Agile book, both because it provides more depth and because it is current with Rails 2.0. For the first time, there is a second book that is indispensable for any serious Rails developer.

The Rails Way is not a good book for someone new to Rails; there is no introductory overview, no Ruby tutorial, and no sample application. But as a reference, it is unmatched. It is very readable, despite being a reference work, because author Obie Fernandez has insights to share in almost every section. In skimming through the book, I found details in almost every section that I never quite understood before, which the books explains with sparkling clarity.

Even though it is intended primarily as a reference, The Rails Way is an outstanding tutorial for anyone who understands the basics of Rails and wants to dig deeper (and has a few days to spend reading). In this regard, it is true to its namesake book, Hal Fulton’s The Ruby Way, which holds a similar place in the Ruby world.

The Rails Way’s coverage is both deeper and broader than any other Rails book, in covering the Rails framework and associated plugins, tools, and attitudes. It weighs in at 850 pages, about 10% longer than the Agile book—and a third of the Agile book is the tutorial introduction and sample application.

If you’re working with Rails on anything but the most casual basis, you shouldn’t work without this book nearby.

One year ago today I embarked on my current adventure, leaving Adobe after five years there and two years creating the startup they acquired, Fotiva. At the time I left Adobe, I had only the fuzziest idea of what I was going to do, but I knew it would be related to the web, and I was pretty sure it would be connected to Ruby on Rails. And that it has turned out to be.

I’m as busy as I’ve ever been, and my income in the past year is the lowest it has been in more than 25 years. But I’m having a great time, and I have a good feeling about where things are headed. I thought I’d take the excuse of this one-year anniversary to look back on my decision to leave Adobe, and catch my readers up on my business thinking.

Looking back on Adobe

I’ve not written much about my experiences at Adobe, in part because I want to avoid any possible appearance of breaking confidentiality agreements, and also because I wanted to gain some perspective first.

Looking back on my five years at Adobe, there’s a lot that I’m grateful for. I learned a tremendous amount about digital imaging and the PC software business, and about life inside a big company. I met a lot of great people, was able to immerse myself in digital photography, and had the opportunity to lead a research team and do technology licensing with the power of a big player behind me. The team I helped build for Fotiva continues on, in large part, as Adobe’s Santa Rosa office, and I’m pleased to have had some small role in growing the software business in the North Bay. And the product that started life at Fotiva has an enduring role as the organizer in Photoshop Elements.

In a strange way, though, I’m most grateful to Adobe for being so thoroughly dysfunctional when it comes to enabling innovation that it drove me out. As someone with a entrepreneurial heart, I found Adobe stifling. If I had been able to accomplish a bit more at Adobe, I might still be there, and then I would have missed out on so much.

To a large degree, the challenges I faced finding happiness at Adobe would be there in any businesses at that scale. But not entirely. Many of the other entrepreneurial folks I met at Adobe, who tried valiantly to build new products and services, have also left. They’re at an assortment of small companies, but also at Google, and Yahoo, and Apple.

One of Adobe’s biggest weaknesses, in my view, is the distance between top management and the people who have passion for innovative new product ideas. It is exhausting, and usually dispiriting in the end, pushing ideas up through a chain that, at it’s pinnacle, doesn’t seem very interested.

The difficulties I had getting new concepts to market at Adobe, especially when they were web-related, are symptomatic of top management’s resistance to exploring new concepts in the marketplace. Adobe doesn’t like to accept the risk of new markets in return for a role (and learning opportunity) as an early player. Perhaps at Adobe’s scale their approach of waiting until market opportunities are clear, and then buying their way in as needed, makes sense. But it did not make for a satisfying place for me to work.

My evolving Ruby on Rails business plan

When I left Adobe, I had done a little Rails development, and read a lot about it, and I felt strongly that it was going to be a big deal. I spent the majority of this year building custom Rails sites for small businesses, and set up Topaz Web Solutions LLC as the home for that work. I enjoyed it, and some of it is ongoing, but my focus has now shifted to Collective Knowledge Works, Inc., the company I cofounded this fall with my partner Christopher Haupt.

I spent quite a while looking for ways to build a business around delivering Rails-based solutions to other small businesses. I continue to believe there is a great opportunity in this domain, but the sales and support challenges are significant.

Collective Knowledge Works grew out of an idea I had to create a portal for Ruby on Rails developers. We’re now deep into doing just that: you can sign up for the beta list at BuildingWebApps.com. Within a couple weeks, we’ll be letting in beta testers, and early next year it will be public. I can’t wait to show it off, and I think it’s going to be a great resource for the Rails community. After eight years away from the editorial, publishing, and training business, I’m glad to be back in it.

Initially, we don’t expect BuildingWebApps.com to generate much revenue directly. Our first revenue stream will be from the Ruby on Rails QuickStart Seminar that we’ll be presenting in February in San Francisco. Later, we believe we can create revenue from the site itself in various ways.

Christopher and I have just launched the Learning Rails podcast, which has been an adventure of its own.

There’s a bigger plan in the background, too. All the technology we’re building for BuildingWebApps.com can be used for any knowledge domain. After we’ve had time to build out this first site, we’re going to develop additional knowledge domains, and enable others to host their own knowledge domains. That’s why we named the company Collective Knowledge Works.

It’s great to be back in this early business-building phase. And it’s wonderful not to have to try to sell new ideas up through multiple layers of management, but simply to decide what to do, and then do it.

During the dozen or so years I ran the Microprocessor Forum conference, I presented hundreds of seminars on microprocessors and PC technology. I enjoy teaching, and I’ve missed this aspect of that business.

Since I’ve been working with Ruby on Rails, I’ve been thinking about how it could be made easier for people to learn. I believe there are vast numbers of web designers and developers who would find Rails a very useful tool, and who could improve their productivity—and their satisfaction with what they’re producing and the process of producing it.

One thing led to another, and on February 20 and 21, my colleague Christopher Haupt and I will be presenting our first Ruby on Rails QuickStart seminar in San Francisco.

We’ve designed the seminar for web designers and developers with only minimal programming experience. We’re providing a pre-built site, which we’ll walk through during the seminar, that attendees can use as the basis of their own sites. We’re also very close to a deal with a hosting provider to offer free hosting for a month, so we can help attendees get their sites deployed before the seminar is over. We’ll provide each attendee with the NetBeans IDE, deployment scripts, and everything else they need to immediately build and deploy Ruby on Rails web sites.

I’m really looking forward to the seminar and hope some of my readers can join me there.

The early registration price of $695 is good until December 20. There’s details at the BuildingWebApps.com site.

Today I began my podcasting career with the publication of the first episode of Learning Rails. It’s been a lot of fun pulling this together—and a lot more work than I anticipated. I’m looking forward to recording future episodes when I’m not learning the audio software and assembling the web pages and the RSS feed infrastructure at the same time.

If you have any interest in learning more about Ruby on Rails, check out the first episode: Why You Should Learn Ruby on Rails. I’d really appreciate any feedback, which you can leave as a comment on this post. And if you like the podcast, please give it a Digg, post a link on your favorite social bookmarking site, or mention it in your blog.

I wrote a post about my goals for the podcast and some of the tools I used over on the BuildingWebApps blog.

I wrote my previous post, Tracking the Cosco Busan, just after I published the animation of the ship’s track as it hit the Bay Bridge. At that point, the site was already doing more than twice its usual volume just with the increased general interest in the Bay, and in current ship positions.

Over the next few days, as half a dozen major news articles mentioned my Track of the Cosco Busan animation, the site’s traffic spiked to an all-time high.

The peak day was more than 120,000 page views, which is about what the site does in a typical month.

I was pleased to find that the VPS this site runs on seemed to have enough headroom to handle the load reasonably well. I stored an alternate version of the flash movie and its data files on S3, which provided an alternative for visitors who experienced load problems.

It was also nice to see my AdSense earnings skyrocket, however briefly. Click-through rates fell to about 50% of normal, but since traffic was 30 times normal, the short-term increase was sizable. If there was this kind of interest in ship tracks ever day my boating site could be a full-time job…

Here’s some links to news articles that reference my animation of the accident:

• Marin IJ
• San Jose Mercury News
• San Francisco Chronicle
• Oakland Tribune

As you probably know, on Wednesday morning a 908-foot cargo ship, the Cosco Busan, ran into one of the San Francisco Bay Bridge towers, creating the worst oil spill in more than a decade in San Francisco Bay.

There’s all sorts of questions being raised about the speed of response. In time, I suspect we’ll learn a lot. For now, speculation on just how quickly the response was mustered, whether it could have been done more quickly, and what caused any delays is just that—speculation.

Even more puzzling is how this could happen to begin with. There’s a huge opening between the bridge towers—this is not a tight fit, even for a huge cargo ship.

It just so happens that one of my sites, BoatingSF.com, tracks ship movements on the bay. Anyone who looked at my real-time ship tracking page within an hour of the accident could have seen an instant replay of the ship’s track. And it should have been reasonably simple for me to access the historical data.

My perfect storm of server data ugliness

This data comes from two AIS receivers I operate, which receive VHF signals that all commercial ships are required to send that encode their position, speed, destination, name, and dimensions. These reports, which arrive at the rate of a few per minute, are streamed up to my server, where I decode them with some custom PHP code (this predates my involvement with Ruby and Rails) and stuff them into a database. Every five minutes, a cron job extracts a summary from the database and generates an XML file. The web page has a Flash movie that reads this XML file to control the animation.

Unfortunately, for performance reasons, I don’t keep decoded position information that’s more than one hour old. I’m going to rearchitect the solution to make this possible, but when I designed this almost two years ago, it was all I could do to get it working, and other projects got in the way of further optimization.

I do archive the raw AIS data stream, so I can go back and process it later to get at historical data. Several private and government agencies have used this data for various kinds of analysis projects. Until recently, I stored this raw stream in the database.

A couple weeks ago, something went wrong, and my simplistic scheme began to torment me. My simple database configuration on an old VPS account didn’t deal well with tens of millions of records.

I had the system set up to send me an email when a database failure occurred—and I started getting 100,000 such emails a day!

There’s another article to be written here, but suffice it to say that you shouldn’t do this (and I don’t any more)—write the errors to a log file, use logrotate or somesuch to keep the files from getting too big, and then use something like logwatch to warn you when the logs have errors in them.

The fix creates a new problem

In my hurry to stop the mail deluge, I changed the code to put the raw AIS stream into a log file instead of into the database. And in the rush, I forgot that the raw AIS data lacks a built-in time stamp. So when I went to dig out the data that would show the Cosco Busan accident, I found that I had no timestamps for any of the position reports! This meant I couldn’t just look for 8:30 am Wednesday but had to analyze ship movements to find the accident.

I also had to write new code to pull the reports from the log file, decode them, and stuff them into the database for further analysis. And I wanted a different zoom region for the display, which took additional work.

About 12 hours later, I had an animation of the accident completed. It doesn’t show actual time, since I didn’t have any timestamps to work with, but it animates on the assumption that the pace of ship reports is roughly constant (which it should be).

I had expected that the ship would have been heading for the space between the towers, and veered a bit off course. The reality is that the ship was going nearly parallel to the bridge, until it turned sharply and headed straight for the center tower! And there was a tug following closely behind. Unless there was a catastrophic steering failure, which seems unlikely given that the ship continued on under apparently good control, there’s some people with a lot of explaining to do.

Next up: a new architecture

This debacle (my server’s, not the ship’s) has spurred me to begin thinking about a new architecture for the system. I want to be able to pull any past window of time, and zoom in on any region, without custom programming.

Perhaps I’ll move it over to Ruby while I’m at it. One of the reasons it too me so long to create the Cosco Busan animation is that it had been almost a year since I had touched the PHP code, and it is an ugly thing! It is hard to remember to put semicolons at the end of every line, and empty parentheses after function calls that take no arguments, and so forth, now that I’m accustomed to a language that doesn’t have such requirements.

Making it even more complex is the convoluted Flash code that creates the animation, which requires dealing in yet another language and the vagaries of the Flash timeline interface. I’m not sure I see a way out of having the Flash code, but at least I can get rid of the PHP.

A few weeks ago I attended the Advanced Rails Studio, taught by Mike Clark and Chad Fowler. (Dave Thomas would normally be there as well, but he broke his arm and was unable to attend.) Mike and Chad are deeply knowledgeable and are natural teachers, making for an enjoyable and productive three days. I highly recommend this course to anyone who has been building Rails sites for a little while and wants to take their skills to the next level. It will be offered again in spring 2008; you can sign up on their site to be notified.

Inevitably, some of the material was review of things I already knew, but there were still plenty of things I didn’t know, or didn’t understand well, before the seminar. Perhaps the most valuable part was getting opinions and perspective from experienced Rails developers—not just the instructors, but other attendees as well.

Here’s a random selection of tips I wrote in my notes. These are probably not all intelligible from these brief descriptions, but they provide a flavor of the kinds of information I gleaned.

• Use a “test rig” file to generate standard CRUD tests.
• Use helper methods in tests and in views to keep your code at a consistent level of abstraction.
• Consider test/spec, which provides a BDD (behavior-driven development) layer on top of test/unit. Mike and Chad prefer this to rspec.
• Consider using simple Ruby hashes instead of fixtures. Mike has abandoned fixtures almost entirely.
• If you’re using the default resource scaffold, which allows xml access to models, override to_xml in the model so you can use the :except option to keep sensitive fields from getting included.
• Don’t bother with small RJS files; just put the RJS code in the controller.
• All the respond_to code and XML handling in the scaffold resource controller is not necessarily a good thing. Mike doesn’t use respond_to unless he knows he’ll be providing API access. It adds noise to your code, can be a security hole, and just isn’t needed if you aren’t supporting an API.
• If you accept credit cards, be sure not to store them in your database. VISA’s rules are hard to comply with, and penalties for non-conformance are high. Use a solution that allows you to immediately pass the credit card to the gateway, or even better, post the form with the credit card info directly to the gateway. Braintree Payment Solutions allows you to do recurring payments without storing credit cards by returning a token that you can use for future charges.
• make_resourceful plugin automates creation of CRUD actions for a resource.
• In most cases, has_many :through is a better solution than has_and_belongs_to_many. One time the habtm approach makes sense is for tagging.
• You can define methods on an association proxy. In the model, e.g., has_many :visits do <define custom find here> end.
• ferret is a port of the lucene search engine, whereas solr uses the original Java source, so it is more current—but it does require that you run a Java app server for the engine.
• If almost all of a page can be cached, but a little part like the login name cannot, cache the entire page and then use JavaScript to replace that section of the page after it loads.
• Disable sessions for controllers or actions within a controller where they aren’t needed.
• To decode the contents of a session: Marshal.load(File.read(“tmp/sessions/filename”)).
• use pp (pretty print) to print out an object in more readable form (much nicer than p(object) or object.inspect).
• simply_helpful is rolled into Rails 2.0. The plugin is now in the legacy folder. If you use this in your 1.2.x apps they’ll have a smooth path to 2.0.

And there’s more, but that gives you the idea…

I’ll be writing up many of these items in detail for www.BuildingWebApps.com once we get that launched.

For the past several months, the majority of my time has gone into a web application for a startup called Accreditation Helper. The marketing site went live today, and next week the product will be shown publicly for the first time at the Medtrade show in Orlando.

This web app forms the heart of the business for Accreditation Helper, which assists Home Medical Equipment companies …

See the full article on my Topaz Web Solutions LCC blog.

I’ve continue to use NetBeans for my Rails development work, and while I’m still generally happy with it, I’ve found the daily builds since the M10 milestone release to be problematic. Most serious for me were frequent Java exceptions occurring when doing the simplest of editing in RHTML files. In many builds, this bug rendered the editor virtually unusable. Many weeks went by with no improvement in this. I ended up reverting to the M10 release and deciding to ignore the daily builds.

A few days ago, Sun released the NetBeans 6 Beta 1 version, and these problems have significantly improved. One nice improvement is that there is now a Ruby-specific version that is only 19M, vs. 172M for the full package, and it also starts much more quickly.

As I write this post, however, I’m waiting to see if NetBeans comes back to life after freezing in an RHTML edit session. The Windows Task Manager shows java.exe sitting at 50% CPU for 10 minutes, NetBeans is completely unresponsive, and I’m about to give up and kill the application. This sort of thing is to be expected in beta software, but make no mistake, this is not production quality code.

I encountered one other very frustrating problem that has a simple solution. The current release of the JDK, 1.6 update 2, has a very serious bug on Windows XP that causes it to be extremely slow opening files in many situations. I found that File > Open in NetBeans hung for literally 5-10 minutes, and then suddenly would come back to life as if nothing was wrong.

It turns out that the solution is to simply uninstall update 2. JDK 1.6 update 1 does not have this problem. And disable the automatic Java updates, so you don’t get Update 2 foisted upon you.

I find it hard to understand why Sun has let this problem go uncorrected, and why there is no conspicuous mention of it anywhere in Sun’s documentation for the release. A little searching of the Java bug lists reveals that JFileChooser has been, in one user’s words, “an open wound” since at least 2004. The problems in 1.6 u2 first started in 1.4, or earlier; got better in 1.6 u1; and go worse again in 1.6 u2. (See, for example, http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5050516.)

One gets the feeling that Sun just doesn’t care about Windows, which may be true, but is a very shortsighted viewpoint if they care about widespread use of applications like NetBeans. (And I believe any Java Windows app would be similarly affected.)

There’s a lot to like in NetBeans, and I’m keeping my fingers crossed that when the production release comes later this year, the quality will be a lot better.

When I started this blog almost a year ago, I really wasn’t sure what I’d be writing about. As it happened, it ended up being much more technical than I had envisioned, and focusing a great deal on building and deploying Ruby on Rails applications.

I haven’t written nearly as much as I would like about Rails, in part because this blog felt like not quite the right place for it—I want something with a richer information architecture.

In the past year, I’ve collected a huge list of links to useful blogs, valuable references, ebooks, mailing lists, conferences, and other resources. There’s a tremendous amount of information available on the web, and it’s hard to imagine learning all this technology without the web as a resource. But this information is widely scattered, and while a google search will sometimes lead you quickly to the best resource to answer a given question, often it takes quite a bit of sleuthing. Rails itself makes it relatively easy to build an application to organize and present all this information—a curious sort of virtuous circle.

In the past few months, I’ve been working with my colleague Chris Haupt on just such an application: BuildingWebApps.com. The BuildingWebApps.com main site is currently in a limited private beta, but you can visit the site now and sign up to receive an invitation when we’re ready to accept more beta users.

We’ve begun a BuildingWebApps Blog, which explains a little more about what we’re doing, and will chronicle the development of the site. If you’re interested in Ruby on Rails or web applications in general, please visit the new blog and sign up for its feed.

With all the “how to build an application in Rails” books that have come out this year, do we need more? Yes!

RailsSpace: Building a Social Networking Website with Ruby on Rails (Addison-Wesley Professional Ruby Series)

RailsSpace is a well-written, insightful introduction to Rails that uses the creation of a simple social networking application to tell the story. It’s not a reference book, and it may move too quickly for absolute beginners. But for more experienced readers who are new to Rails, or for Rails developers with some experience who are looking to learn a few new tricks and pick up some best practices, this is a great book. The step-by-step creation of the social network application (and thankfully not another shopping cart) provides a cohesive structure and creates natural opportunities to introduce a wide variety of topics.

Author Michael Hartl was previously a physics instructor at Caltech, and his teaching experience shows. The book progresses naturally, explaining just enough as it goes along to keep the reader oriented without too many diversions. This is a real challenge in an introductory Rails book, since there’s a lot of pieces you need to understand to some degree before it all makes sense. Coauthor Aurelius Prochazka is a very experienced web developer, and this too shows through. The book is full of insights and best practices that make it more than just an introductory text, and also make it an enjoyable read.

Although the book only scratches the surface of many advanced Rails topics and doesn’t go too far into Rest or Ajax, it covers well a number of topics that are often neglected in introductory books. Testing is addressed nicely; the book doesn’t use a test-driven development (TDD) approach, which interferes with learning the basics of Rails, but it does show how to test each feature after it is built. It also has a good section on searching, covering both the use of Ferret and the creation of searches using multiple, specific model fields.

There’s a companion web site, built using the code from the book, at which you can browse the source code. You can also download a sample chapter, RESTful Blogs.

Experienced Rails developers may want to wait for two very promising books due out later this year: Mike Clark and Chad Fowler’s Advanced Rails Recipes, and Obie Fernandez’s The Rails Way.

It’s been awfully quiet here on the blog the past month or so… but that’s only because life here in the physical world has been busy, busy, busy.

I’ve been spending most of my time on a large Rails application for a start-up client. In another few weeks, I’ll be able to tell you about it.

I’ve also been formalizing my web development business as Topaz Web Solutions LCC. I’ve been operating as a sole proprietor until now, and it was time to pick a name and create a better legal structure. (The Topaz name, incidentally, has no particular significance; I was just looking for something short, memorable, and not already used, and came upon this after starting with Ruby.) I’m booked up through October, but would be glad to hear about any projects that could start after that.

I’ve also been hard at work on a resource site for web application developers, and I’ll be telling you about that soon.