Technology for Humans - Home

Startup Camp This Week

2008-07-07T14:00:00Z

I’m really excited to be heading to Startup Camp toward the end of this week. This is a gathering of folks from seven startups, plus a dozen or so startup veterans, investors, and advisors, to talk about making our ventures successful. I feel really fortunate that my startup, Collective Knowledge Works, was chosen from the more than 80 companies that submitted applications.

At the beginning of Startup Camp, each company gives a lightning talk describing itself. The format is like the Ignite events: 20 slides, which are automatically advanced every 20 seconds, giving you about seven minutes total. It’s a demanding and inspiring format.

I started with an edit of my standard pitch but decided that there really was no point in having word slides at this speed. Spurred on by the book “Back of the Napkin,” I’ve been creating illustrations to anchor each slide. It’s a little daunting how easy it is to spend two hours on a slide that’s going to be shown for 20 seconds, but it’s a great discipline for really clarifying your thinking and figuring out what your main points are and how best to communicate them.

Another great thing about Startup Camp is that getting into it also grants admission to O’Reilly’s Foo Camp, which immediately follows it. Foo Camp invitations are highly coveted, thanks to the incredible collection of people that it gathers and the wonderfully free-form way the even unfolds.

Coping with the Information Flood

2008-07-05T16:13:00Z

Many years ago, when I was writing Microprocessor Report, I read dozens of magazines a week and sifted through hundreds of printed, mailed press releases each month. It was chronically overwhelming. It’s amazing how the web has eliminated that whole world of keeping up with paper.

Of course, the electronic information flood is now far larger than the paper flood ever was. Fortunately, we have better tools for dealing with it. But I’ve found it non-trivial to find a way to use those tools that really works for me.

A couple years ago, I decided to get serious about reading the blogosphere, and I accumulated a long list of interesting feeds. This quickly became untenable, however; opening your feed reader to find 10,000 new posts is downright depressing, and leads to a quick exit. And with plenty of email every day, it was all too easy never to even get to the feed reader, especially knowing that once I went there, the flood would be overwhelming.

I started having the feeds from a few key sources emailed to me instead, and I found that this prodded me to actually read those. This approach worked for a while, until I found that I was missing too much stuff from feeds that weren’t being emailed to me, and that the emails were becoming tiresome. Among other issues, a feed reader is a much better interface to a list of posts than is an email message with a string of posts in it.

In the past few weeks, I’ve switched my approach again. I created a category in my feed reader called “Top”, and moved into that category the two-dozen or so feeds I care the most about. I stopped all feeds being emailed to me, so now I’m drawn to the feed reader each morning, as the feeds I’ve become accustomed to reading aren’t in my mail any more. And I create a sort of “feed amnesty,” setting all messages in all feeds to “read,” so I could track just the new stuff from now on.

So far, this is working really well. I at least skim all of my top feeds almost every day, and I find I can keep up with them pretty easily. And if I find myself with a little more time for news reading, I’ll dive into one of the other feed categories, with feeds that didn’t make the “top” cut. Feeds like engadget, which is interesting but not critical for me and has dozens of new posts in a typical day, I have given up on reading.

For me, a big part of this is accepting that there’s just no way I’m going to keep up with as much stuff as I’d like. What has helped me a lot is to make the decision up front—here’s what I’m going to keep up with, and here’s what I’ll keep in my feed reader but not expect to read regularly.

I also find it helpful to be ruthless about what subjects I’m going to track, and which I’m not. My top interests vary with time, but whatever they are at the moment, I try to just ignore most everything else. It’s narrowing, in a way, but for me it’s been the only way to keep up with those things that seem most important.

As for watching the Twitter stream—I have to admit I’m mostly not doing it. That’s another blog post, but for me, most of the time, getting short, frequent updates from lots of people just feels like too much information.

How do you deal with the information firehose?

Our Newest Family Member

2008-07-02T03:10:00Z

Meet Sapphire, our new kitten. Is there anything better than a kitten?

iPhone Will Cost Verizon My Business

2008-07-01T05:33:00Z

I’ve been with Verizon for a long time, since it was called something else I don’t remember any more (GTE?). In the early days, they were the only company with even half-decent service out in the country where I live. We now have four phones on a family plan.

When the iPhone came out last year, I was intrigued, but not enough to change mobile carriers. I got an iPod Touch instead, and the LG Voyager phone from Verizon.

Although the iPod Touch and the LG Voyager share many capabilities, the contrast between the two devices is striking. Six months use of the two of them has left me eager to abandon the Voyager.

Sadly, the Voyager is riddled with bad design decisions. Just a few of them:

The Voyager opens up to reveal a real Qwerty keyboard, which might be nice if I sent many mobile messages. The email client is so poor, however, that I don’t do much messaging on the phone.
The web browser is painful to use. It’s so inferior to the iPod Touch’s browser that it’s hard to put into words.
The only way to turn on the speakerphone is to open the phone to put it into “full keyboard” mode. This is often clumsy.
Furthermore, the full keyboard is poorly thought out for use as part of a phone. You have to use shift to get to # or *!
The web browser is clunky, and the small internal screen is further crippled for web browsing by having the top and bottom lines of the display permanently devoted to status functions.
The touch screen scrolling is awkward and hard to use.

The iPod Touch, while it obviously is not a phone, is vastly superior to the Voyager as a web browser and email device, and, for that matter, as a calendar, contact list, calculator, and note pad. The emergence of third-party iPhone apps will dramatically widen the iPhone’s lead; the Voyager is a proprietary platform with weak software support. (It’s a great bonus that the iPhone eliminates the need for an iPod as a separate device, but this isn’t the driving attraction for me.)

So when the new iPhone comes out next week, Verizon will lose me as a customer. (Just me personally, alas, as it will take some time before my family switches.) It’s an expensive and painful decision for me. But the iPhone is just so superior to anything that Verizon has to offer that I can’t take it any more.

It’s the first time in nearly 20 years of owning cell phones of all stripes that the availability of a device has overwhelmed the ease of sticking with my provider.

It took a decade longer than we all hoped back in the 90’s, but the mobile web is finally coming into its own. With some of the power in the mobile world shifting to Apple and perhaps to Google, I hope we’ll see a gradual end to the omnipotence of the mobile carriers, which have, in many ways, been a force against innovation. They just can’t seem to get out of their own way when it comes to making phones a platform.

It’s time for big changes in the mobile industry.

A Business Update

2008-05-29T18:39:00Z

It’s been a while since I’ve posted to this blog, so I thought it was time for an update.

Anyone who has been involved in a startup knows how all-consuming that can be. We also have a blog over at BuildingWebApps.com, and I’ve been writing a bit both for that blog and for the core of the site. But most of what has been consuming my time is crafting a business around the technology we’ve been developing.

Christopher Haupt and I founded Collective Knowledge Works, Inc. last fall, and our first venture was to launch BuildingWebApps, a resource site for Ruby on Rails developers. We also started the Learning Rails free online course, which began with podcasts and has evolved into a series of screencasts, in which we build a Rails application step by step. It’s been tremendously popular, with several thousand people following the course. It’s a lot of fun teaching this way, and seeing how much value people get from it.

We considered building a business around serving the web application developer community, but we’ve decided to keep this as a side project, rather than the core of our business, because we want to build something that we believe we can scale into a more significant company.

In thinking about the application we built to create the BuildingWebApps site, we realized that it has a much broader potential use: building a resource site on any topic. We think of it as the next generation beyond blogs and content management systems. We’ll offer this as a hosted service, enabling anyone to build a site like BuildingWebApps, on any topic.

The next question was which customers to focus on. We found that, as a horizontal technology platform, it was hard to explain to people, and hard to come up with a focused marketing strategy. Some customer groups we looked at include:

Infopreneurs: people building web-based information businesses
Passionates: individuals or organizations who are passionate about a topic and want a platform for communicating their knowledge and engaging the community
Businesses: businesses for which educating their customers and prospects is important

After lots of analysis, we’ve decided to focus our initial product on the last of these categories: in particular, on small businesses. There’s a lot of customer pain here that we can address, and a lot of value that we can provide. Most small business sites are awful, if the business has a site at all. The model of going to a local web developer and building a site from scratch is expensive and painful, and almost always results in a largely static site with no community features.

We’re going to provide a platform to make it easy for small businesses to create powerful sites that engage their customer community and become valued information resources that attract new customers. There’s lots of pieces of this that go beyond what we’ve done at BuildingWebApps, and which we’re not quite ready to talk about.

We may also have versions of the platform for the other two customer categories, and they may be the source of significant long-term growth, but they won’t be our initial focus.

We’ve raised a little more angel financing to take this to the next level, and we’ll be launching the product in the fall. There’s a teaser at the embryonic Collective Knowledge Works site. If you’d like to be notified when we have the private beta ready, please enter your email address there.

It’s been a fascinating process getting to this point. It’s been a year and a half since I left Adobe and gave myself the flexibility to pursue various interests and see what bubbles up. A lot of threads have come together now, and I’m really excited about where we’re heading.

Going to South by Southwest?

2008-03-04T23:08:00Z

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.

Last Chance for February Rails Seminar

2008-02-13T01:27:00Z

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.

Ruby on Rails Resource Site Launched

2008-01-08T01:54:00Z

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!

The Rails Way: The second must-have Rails book

2007-12-13T04:39:00Z

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.

Celebrating a Year of Freedom

2007-12-02T07:22:00Z

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.

Ruby on Rails QuickStart Seminar Launched

2007-11-30T23:47:00Z

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.

Learning Rails Podcast Launched

2007-11-28T06:13:00Z

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.

BoatingSF's 15 minutes of fame

2007-11-28T05:57:00Z

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:

Tracking the Cosco Busan

2007-11-11T02:48:00Z

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.

Tips from the Advanced Rails Studio

2007-11-05T20:36:00Z

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.