Monday, December 26, 2005

mac conversion #2

Checklist to get my Ruby and Rails apps up and running on the new mac:

  • Need Ruby 1.8.2. Done. ruby comes pre-installed on Mac OSX 10.4. There are some who recommend reloading from source, but for now I'm going with the installed version.
  • Install Rails. There is an installation package out there for Mac called Locomotive. This installs Rails, lighttpd with fastCGI, and SQLite. Locomotive is definitely a quickstart approach to getting rails going. Check out this blog entry for a broader explanation.
  • Install mysql and create local database. Load with initial data set.
  • Install the Mac Developer xcode package. This includes gcc, make, cvs, and a bunch of other stuff.
  • Need an editor environment. I have been using Arachno's Ruby IDE in windows (does better syntax hightlighting among other things than Eclipse) but doesn't currently have a Mac port. So after some research I decided to use TextMate . This has been highly recommended for developing in ruby for the Mac and is the defacto editor for the Locomotive env, so will try it out.
  • set up the VPN. To create a VPN connection go to applications - Internet Connect
  • Download existing code from cvs or subversion server
  • go to work!

Saturday, December 24, 2005

mac conversion #1

I just opened my new PowerBook G4 1.67 Ghz 1GB mem, 100GB HD, OSX ...

This is one righteous machine. From it's aluminum case to high res screen, the fit and finish on this product (as Mac zealots will attest) is second to none. I have been a Unix geek cloaked in Windows skin for many years now. Having recently become a Ruby convert and a conversation with Chad Fowler got me re-thinking about why I have been stuck in the Windows mud for so long.

After booting up and filling in the few screens of config information (I like the rotating entry form boxes, very cool), I was up and running in about 5 minutes, on my wireless network and downloading updates.

I am planning to document my conversion right here in the ol' blog, trials, successes, and foibles all.

First things I'm missing are:
  • No start bar. I'll have to get used to a new way of navigating and creating shortcuts to my favorite applications.
  • No right button. I like the pop-up menus available with the right mouse click. I use it often (for instance to pull the image link off the Apple site from above) and will have to figure out its analog on the Mac.
  • The rich edit field. Is missing in Safari, so am coding this up in html by hand. I will probably download Firefox because I miss my Firefox extensions as well.
Cool things:
  • The Dashboard. With a click I can pull up an assortment of tools, sticky notes, etc. Very useful.
  • The terminal. Yes! Thankfully, I'm back in unix land.
I haven't had time to explore much else given that it's Christmas Eve, but thank you Santa for saving me from the blue screen of death :)

happy holidays!

Tuesday, December 20, 2005

funny quote on web 2.0


"Not believe in Web 2.0! You might as well not believe in fairies! You might get your papa to hire Tim O'Reilly to come over to your house and explain Web 2.0 to you, but even if Tim O'Reilly showed up and you didn't understand what the heck he was talking about, what would that prove? So what if nobody can actually explain Web 2.0 without using techno babble and business buzzwords? That is no sign that there is no Web 2.0. The most real things in the world are those that neither children nor men can see -- and that's why they develop buzzwords. Did you ever see fairies dancing on the lawn? Of course not, but that's no proof that they are not there. Nobody can conceive or imagine all the wonders there are unseen and unseeable in the world."

-- Rex Hammock explains the mystery behind the elusive concept of Web 2.0 to a young reader

Sunday, December 18, 2005

the next round

We're currently raising another round of funding and have decided to pursue the angel route in order to keep dilution down. Once we get significant customer traction we will either raise a strategic or VC round of capital. In the meantime, I've put my car up for sale to contribute to this round. It's a sweet car, but I've got to do it...

Here's the link:

Thursday, December 15, 2005

Shared Nothing Architecture and Short Lived Processes

WARNNG - This post may offend fans of megalithic application servers

After having worked in the Java environment for the past several years and watching Enterprise Java Beans destroy whatever simplicity existed in the Java world, I was ready to explore new development environs with Collective Intellect. Further spurring this curiousity were the thoughts penned by Paul Graham in his enlightening book, Hackers and Painters. Paul is a big fan of Lisp and spends a few chapters talking about the elegance of the language and economy of expression required to implement powerful concepts. While Lisp is all of those things, it does seem to lack a large ecosystem of open source libraries ready made to bake into your current project. I ended up settling on Ruby and Ruby on Rails to implement our burgeoning ideas and business requirements. I will speak to the long and short comings of Ruby/Rails in a future post.

What I wanted to discuss on this post is Shared Nothing Architecture (SNA), coupled with Short Lived Processes (SLP). Shared Nothing Architecture is a concept made popular by the folks at google and is defined in Wikipedia as:

A shared nothing architecture is a distributed database architecture without a single point of failure. The term "shared nothing" is by imitation of other terms such as "shared disk", "shared network" and so on.

A typical shared nothing system would have duplicated disks, processors, power supplies, and networks. To make the system truly resilient, it should also have these systems split between different physical sites, and have multiple sources of electrical power and network connections to the outside world through physically diverse paths.

The advantage of SNA is that it greatly simplifies application construction as well as increasing the scalability and reliability of applications. I would argue that you don't even need to go so far as creating a distributed database and in some cases don't even require a database at all. Certainly having a distributed database creates a more resilient infrastructure, but if you don't have the time or resource pool to put a distributed database in place, you can still take advantage of SNA with a bit less resiliency at lower cost but still have a warm failover capability.

The implementation that we have at Collective Intellect uses a single mySQL database running on an industrial strength box with RAID 5. We have several other boxes that process information. They all point to this database box and file server to recover the context for the processing that they perform. One of these boxes also contains a hot nightly backup of all of the information in the database, so if the database box dies and the RAID file system completely fails, we can warm failover to the next box. We can do this because we also have an information architecture that will allow us to roll data forward (with a little pain) from the point at which the last backup was run.

This architecture allows us to write independent, specialized applications that each process a small chunk of our processing operation. This is a vast change from using a monolithic application server based architecture. Application server architectures require all applications to run inside of the architecture and manage state for all of those applications as part of that framework. One typical example of this is Enterprise Java Beans. These frameworks tend to carry a lot of baggage which results in two rather severe implications to your app.

  1. Bringing up an entire application server infrastructure requires very large memory and load time overhead vs. a non application server based app.
  2. All applications reside inside the application server. This means they are long lived and have a fairly large chance of becoming more and more intertwined with either legacy code or code that is meant to support other apps (i.e. spaghetti)
In our shared nothing architecture our apps can be short lived and only carry the code required by the app. Freeing applications from the application server means that these apps can be short lived. We have a number of small specialized Ruby applications that automatically get launched when work exists for them to do. This allows all components of the system to do what they were designed to do.

  • The database stores data state used by the applications
  • The operating system controls the sharing of hardware resources (network, disk, cpu, memory) as opposed to the application server controlling the sharing of these resources as a proxy or replacement of the OS.
  • The application processes implement the specific features required by the business model

Saturday, December 10, 2005


In one of the recent episodes of the apprentice one of the candidates was heard bad mouthing the leader on the task to other team members. Donald rightly pointed out that this kind of behavior is destructive to the cohesion and productivity of the team. This kind of talk, even from someone who is ill respected on the team will undermine the leadership and cause decisions to be second guessed.

People are inherently positive or negative by nature. The positive person will most likely propose solutions instead of harping on problems. Hire the positive person and dispense with the problems that come with having negative people. Make it clear to everyone that you deeply value their opinions, encourage problem solving, and keep an open door policy.

pull your banner ads until google does a better job