Feeds:
Posts
Comments

Archive for November, 2006

While I’ve used many windows-based hex editors over the years, I never needed to do it from a Linux environment before, and so I wanted to see if there was a way to do it with a tool that would be included in most default distros. Some brief searching turned up this method with vi, and it’s too handy to keep to myself:

-bash-3.00$ vi test.bin

:%!xxd -enter hexedit mode-

-make any necessary edits-

:%!xxd -r -exit hexedit mode-

:wq -save and quit-

Read Full Post »

I’ve been generally interested in both Ruby and Rails since hearing Dave Thomas speak about them at a conference a year ago, but never really had the time to sit down and focus on them, so apart from skimming through the pickaxe book I can’t say that I’ve done much.  A small part of that was the effort in setting up the development environment — getting an IDE, setting up Ruby, Rails, a web server, a database to have Rails and Ruby talked to, etc.

Deciding to pick it up again, I’m very happy to see that things have become much easier with the creation of a couple of new tools: RadRails and InstantRails. RadRails is a repackaging of the Eclipse IDE, the Ruby Development Tools (RDT), and a Rails-specific plugin, all in one convenient archive — just download, unzip, and run.  Because it uses Eclipse, it’s also easy to include other plugins for source control such as CVS or Subversion. It does require that you already have Java, Ruby, and Rails installed.  Java you’ll have to get from Sun, but as for Ruby and Rails (and much more)… use InstantRails!

InstantRails is a collection of several tools designed to help you get a Rails-based solution up and running as quickly as possible.  It includes Ruby, Rails, Apache, and MySQL — so you have your web server, database, and language to develop with. Like RadRails, the installation doesn’t require any environment changes — you can have it installed and running a sample app literally in seconds. Conveniently, it’s been recently updated to integrate well with RadRails. The only drawback I’ve found so far is that it is Windows-specific — not a problem for me as I usually develop in Windows, but if you’re a Linux- or Mac-ist that may be a dealbreaker. Curt Hibbs and Bill Walton have put together a tutorial showing how to get started with InstantRails — notable in that it doesn’t use the Apache server included with InstantRails but instead uses the built-in WEBrick server.

Between these two tools I was able to get started much more quickly than my first time around, when I had to put all the pieces together myself.  Given that I have a finite amount of time for playing around with new tools and languages, it’s very nice to be able to get quickly past the initial configuration details and focus on trying Ruby and Rails — and I hope it encourages others to do the same!

Read Full Post »

Having been generally interested in space exploration for many years, when a friend of mine suggested a road trip to go to the X-Prize Cup, how could I turn it down? Six of us went and had a blast at the competition itself talking to the various groups and watching the competitions going on, including Armadillo‘s heartbreaking third try at the Lunar Lander Challenge.  Even after the failures, though, the guys with Armadillo were very approachable and willing to chat about what worked, what didn’t, and how they had gotten this far.  While I think next year they’ll definitely nail at least the first level challenge and quite possibly the second, they’ll more than likely have some serious competition (they were the only ones trying this year).

One of the things that I found really interesting about Armadillo’s approach is how they’ve adapted several of the principles of Agile software development to building a rocket vehicle — their development process is characterized by multiple short iterations, heavily emphasizes testing, and focuses on a process where in each iteration you attempt to get some piece of incremental functionality working before moving on to the next. In a software project, these would be unit and integration tests and would result in working applications… here, it’s static engine firings and tethered test flights, and it’s more than likely to result in the first winner of the Lunar Lander challenge.
So why hasn’t this been done before, and how did they accomplish in months and hundreds of thousands what took NASA years and millions?
I think it’s entirely due to the cost of change.  A critical way in which software development differs from most traditional forms of engineering is the cost of revising your design.  No structural engineer would consider completely revising what the framework of a building looks like when it was halfway done, but this is something that often happens (for better or worse)  in software projects.  The whole concept of agility and refactoring is enabled by the fact that the cost of implementing a change can be as low as recompiling and re-running the test suite — and agile methodologies take advantage of that to “embrace change”, and believe that by slowly developing the design as you build, instead of attempting to get everything right up-front (before you’ve even started developing), that you can take advantage of lessons learned along the way.

The problem in adapting agile methodologies to traditional engineering is that in most cases you can’t afford to take your half-built building, tear it down, and rebuild it in a new manner. It’s just too expensive, both in terms of materials and in time.  With smaller projects, however, ones that are cheaper and take less time, you can afford to do this — as any shade-tree mechanic or Sunday carpenter knows, sometimes you get halfway into a project and realize there’s a better way.  When NASA built Gemini and Apollo, everything was hugely expensive.  Many if not most parts were being custom-developed and some of the materials were either completely new
or being used in completely new ways (although not Velco, that’d been invented shortly after WW2). The cost of changing the design was huge.  Team Armadillo, on the other hand, can take advantage of the huge advances in miniaturization and cost that have been made in the past 40 years. Many of their items are either low-cost and home-built, or are simple off-the-shelf parts (like the ‘brain’ of the system, a commercially-available PC104 board running Linux). The fact that they can quickly and cheaply replace parts when they break, or can even redesign (to a certain degree) entire systems means that their cost of change is low.

With a low cost of change, agile practices become practical, and I believe that being able to take advantage of that tight feedback loop — Try, Test, Fix — had a lot to do with Armadillo’s success so far. And, after all, I want them and others to succeed — they’re getting me closer to my vacation on the moon!

Read Full Post »

X-Prize Pics

For those interested, I took my camera along on the trip and got some pretty great pictures. Here are the flickr sets:

X-Prize Cup 2006

X-Prize Cup 2006

As you can see, it was a beautiful day. We also went to the nearby missile museum:

White Sands National Missile Range Museum

And finished it off with a quick trip over to the White Sands National Monument and the Cloudcroft area.

White Sands National Monument & Cloudcroft

Read Full Post »