For the last few months I’ve been working on a fairly large-sized web application for work. The application is mostly Flex-based, so I’m working on back-end components, which are accessed via FluorineFx (an ActionScript-.NET connector). The site also needs to integrate with Ektron, a somewhat perilous enterprise-level CMS, because a lot of the company’s web-facing data is already stored their and they want to reuse as much as possible. The site is a completely new version of a much less-ambitious site designed for the same purpose, driven by a 400mb Access database.
So, as part of our deployment setup, our projects consist of:
- 3 projects that encompass most of the site’s actual functionality. One is for Ektron integration, one is for control development, and one is for the service implementations.
- 1 tool that imports data from the old site.
- 1 tool that imports localization data from Ektron.
- 1 tool that creates Ektron Smart Forms in order to create that localization data.
- 1 tool that encrypts member passwords (because until that’s done we can’t see the old members database).
- 1 tool that both backs up Ektron staging data and also restores that data to a clean environment.
- A team test project.
- A test harness for other parts of the system.
- Oh yeah, the web site.
I generally find myself on this approach whenever I’m working on a large system. Importing data from SMF? Write a tool. Need to transform something into an XML format your site understands? Write a tool.
For me, the hardest part about getting tooling correct is making sure that I’m not wasting time when I’m designing one. For instance, smart forms in Ektron are a cool idea, at least in concept. I’ve found them somewhat difficult to use, but it’s still a cool idea for a CMS. Our client wants to use Ektron to store localization data, but right now all I have are the dictionaries of English text in a Flex ActionScript file. Here’s our process:
- Grep the text out of the ActionScript dictionaries into a .CSV file.
- Using Sebastien Lorien’s CSV reader, read each dictionary in one at a time.
- Create a .xml file corresponding to the Ektron smart form exported file format.
- Manually import or update each corresponding Ektron smart form.
When this eventually goes to the client (or to a new staging database for ourselves), we’ll run a tool on our database in “backup mode,” which will back up all of the smart forms, as well as the corresponding content rows, into a binary file. Then we’ll run the tool on the new database in “restore mode,” which will update all of the content to the latest versions.
What does this allow us to do?
- QA content on the test site and be confident that it’s going to be represented on the production site. Because entering content into Ektron in this manner isn’t particularly easy, we don’t feel comfortable that we could do it with no errors. By automating the process, we can be reasonably confident that we’ll eliminate typos.
- Avoid repeated input time. It might have cost me the same amount of time to write the backup/restore tool as it would have taken to just do it by hand. However, I was fairly confident (and correct) that I’d have to do it more than once. We get the added bonus of being able to deliver the tool to the client, who will also have to run it in their production environment.
I love writing tools. It makes everyone’s lives easier, and that’s never, ever bad.
I recently went to my cousin's birthday party (he turned 6), and since he's apparently become a huge Star Wars fan (read: played LEGO Star Wars and loves shooting off C-3PO's leg), my parents decided to get him a couple small Star Wars LEGO toys that were designed for that age group. They're small - maybe 30 pieces or so - but they're still pretty neat, and I can't help but be amazed at how the pieces still come together to form the whole. I was a LEGO and K'nex fanatic when I was younger, but I don't think I really played around with them since I was 14 or so - ever since I left Illinois. So when I was asked to help my cousin put them together, my first reaction was, "Hey, I don't do that anymore." But as I got started, I was drawn in - even on the little 30-piece landspeeder.
And so, I recently made one of the biggest entirely-vanity buys since I've moved into my new place:
The "Ultimate Collector's Edition" Imperial Star Destroyer. I couldn't bring myself to invest the full $500 in the Millenium Falcon, but I thought that the price wasn't too insane, a paltry 3104 pieces wasn't too daunting, and that I would have enough fun putting together the monstrous 37" set. The instruction book is about the thickness of my high school year books, and I'm disappointed but not entirely surprised that they didn't include the hyperdrive units as part of the set. I guess I'm on my own for making it actually fly.
I took the pieces out and set them on my dining room table, and as I analyze the rather daunting task ahead, I realized that, really, it's like my every day job. And the first page of the book seemed to confirm it:
Everything is done in components. We have a frame, then a wing, then another wing. The bridge. All of these go together with little regard for how the rest of the ship is built. Just like we build software. We try to solve a problem, but we try to make sure that our components can be used or adapted to solve another problem as well.
So maybe all of my formative years building with those LEGO sets weren't for nought. Maybe they were setting the stage for software development even then, tuning my problem-solving skills, making me think of things as tasks to be decomposed until the smallest task can be approached. Who's to say?
Sadly, my software development experience doesn't have a way for me to estimate time to build this bad boy. But at least my motivation's there!
Update: Check out the building marathon!