Halogen Labs

At the last RUM meeting, there was a fairly lengthy discussion between Dan and Ben about good ways to get Ruby and Rails in the door at the larger companies — the UHCs, the Allinas, and the Wells Fargos of the world.

One of the arguments that you could use is the cost/productivity angle. Essentially, you can argue that your projects can get done faster, quicker and cheaper. A counter-argument was that the BigCo’s won’t buy into it unless it fits their technology stack (e.g. deploying Rails in a container).

I think there’s some other underlying causes for why BigCo’s aren’t able/willing to just switch, and here’s a braindump of some of the reasons. Keep in mind that there are always exceptions to the case, and that these are more stereotypes than anything, but I think it tends to be correct:

BigCo’s:

• Bureaucratic
• Top-Down decisions
• Committees
• Standards
• Structure
• Hard to take risks
• Monolithic
• Reactive
• “Lowest Common Denominator” Factor

LittleCo’s:

• Democratic
• Bottom-Up decisions
• Acting w/o meetings
• May dabble
• Flat
• Easier to take risks
• Diverse
• Bleeding Edge
• Best of Breed

So what’s the messsage I got from this? IMO, BigCo’s make their decisions partly based on prior experience other companies have had with the same thing. I would guess that PHP got popular in the LittleCo’s, where you might have had a couple geeks looking for a better way to build apps compared to Perl CGI. Dead simple integration with the most popular web server made it ubiquitous. And what do you know, places like Yahoo end up using PHP and publicizing it, thus making it “legitimate” for the BigCo’s to use.

If you want to get Ruby (and thus Rails) in the door at the BigCo’s, you need to work on getting them in the door at the LittleCo’s. But then, this issue comes into play ;)

I knew stuff in JSF was a lot of work, but I didn’t realize you could get so complicated just to produce a <div>.

I agree, it is a lot of work, just using html is easier. But it is a good example to show what’s involved in created a minimal jsf component.

If a minimal component is this complicated, I don’t want to be wading into the JSF pool any time soon.

An interesting article regarding how the famous THX sound was created:

“The score consists of a C program of about 20,000 lines of code. The output of this program is not the sound itself, but is the sequence of parameters that drives the oscillators on the ASP. That 20,000 lines of code produce about 250,000 lines of statements of the form “set frequency of oscillator X to Y Hertz”.

Well, I hacked for a solid day, and I managed to integrate PostGIS, Rails/ActiveRecord, and sprinkled a little AJAX + JSON, and baked in some Google Map API, and here’s the result:

(click on the thumbnail for detail)

The end result is a scrollable Google Map that loads cartographic data from PostGIS based on the bounds that the map window is centered over. The end result is also very slow at the extremes :)

My next TODO involves changing how the shapes are simplified when the map is zoomed way in or out, and possibly just showing an entire state if the map is zoomed out far enough. I might also work on only loading line segments instead of the entire county outline if it’s warranted. There’s no point in loading an entire high-res county if we’re zoomed in on a little corner, is there?

Safari is slow, BTW.