Heroku Has Launched

Well, just a very short time after I started using Heroku, they went commercial. Yes, after their very successful beta period, where apparently 24,999 web sites other than mine were already hosting, Heroku is now offering a paid version of their service. I had a sneak peak at the pricing a few days ahead of time, but I was not able to talk. And despite my intentions of blogging this right away, the other demands on my time have kept me occupied till just now.

Heroku is mimicking the successful "freemium" pricing plan of other services, but brings it into the Ruby web application hosting space, within some pretty generous limitations. Yes, exactly. Heroku still allows you to get started with their service at no charge at all. Wow. I do not know of any free web hosting service that does not at minimum plaster your site with hideous ads. Let alone quality Ruby hosting. Let alone Ruby powered cloud computing.

As your traffic needs increase, or database storage needs, they have a variety of pricing tiers. Thanks to a slick AJAXified pricing tool, the complexity of so many pricing options is somewhat mitigated. Plus it's fun to play with.

The evolution of most startups seems to track really well with Heroku's overall business strategy: as a customer becomes larger and more successful, their increased traffic and database needs will cause them to start paying Heroku. If your venture does not really go anywhere, it is not really taking up much in the way of resources anyhow. This aligns Heroku nicely with the needs of their customers, instead of pitting them against them trying to extract revenues too early in the growth curve.

Despite a few growing pains, they have had pretty decent uptime on my app so far. Even with my new app Thumbfight getting a few sudden traffic bursts, as well as having a major reliance on Twitter for back-end processing (more about Thumbfight in an upcoming post).

Heroku is a work in progress, but so is most everything else on the entire Internet. Heroku provides an amazingly easy and insanely cheap way to jumpstart your Ruby-based web application hosting and deployment, while still getting some real expertise. As long as you can work within their current technical limitations, for a Ruby-powered startup, I think Heroku is a great way to go.

Project Flying Robot: Getting RAD With The ATMega328

I have been wanting to upgrade the hardware used in our Dorkboards for flying_robot, from the ATMega168, to the newer better faster ATMega328. More memory, and a faster UART for serial communications with the XBee modems in the same pinout = easy win. Thanks to a quick shipping turnaround from @adafruit I got them in before the weekend, so I could play a little bit today.

The first step was to upgrade my hard-working Arduino Diecimila to a 328. I now have it working great with Ruby Arduino Development (RAD), but since RAD was really setup for Arduino 12, I had to make a couple changes. Here is what I did:

1. D/l and install Arduino 15 (brave, I know, since that is the latest release, and many people run one version down from the latest)
2. Change my hardware.yml entry

mcu: atmega328p

3. Change my software.yml entry

arduino_root: /Applications/arduino-0015

4. Lastly, since the ATMega328 bootloader runs at a faster rate, I had to tweak the RAD code itself to support it. The file "/vendors/rad/generators/makefile/makefile.erb" is the template used to create the makefile that compiles and uploads the code to the Arduino. Line 77 in that file controls the baud rate, which needs to be set like this for the '328:

UPLOAD_RATE = 57600

Once I had done this, I was easily and quickly able to recompile/re-upload the latest flying_robot code to my test board. Yeah! Hopefully tomorrow I can upgrade Rogue 1 and try a flight at the new, higher communication speed.

Heroku, Why Haven't I Been Using You Till Now?

Last night, I finally got around to deploying something on Heroku, an interesting service founded by my formerly LA-based Ruby programming chums Adam Wiggins, James Lindenbaum, and Orion Henry. I had played with their previous incarnation of the service, now known as "Heroku Garden" but only recently have I gotten to know a little bit more about the incredible offering they have evolved into.

Basically, the Heroku crew have addressed the question "how can I deploy my Ruby on Rails, Sinatra, or other Rack-based web application into a dynamic cloud of servers with ridiculous ease?" They have done this with an ingenious architecture that takes advantage of Amazon's EC2 to provide their internal infrastructure. This allows Heroku to concentrate on their most important core value proposition, of a simple way to take your Ruby code and just push it into the cloud.

Notice I said "push". Heroku requires that you use git for source control of your application. You are using git for everything now, right? If not, git with it! Sorry, could not resist that. Anyhow, by simply adding a remote master to your existing git repo that points to Heroku, along with a few Ruby gems that they provide, you can deploy your app just by pushing your current branch to the Heroku master.

Doing this, causes your app to get packaged up into "slug". Once you have an active slug, it will be be deployed to a "dyno" within the Heruku grid, which is what a virtual node within their architecture is called. As your app requires more resources, the slug can be deployed to more dynos within "less than 2 seconds for most apps". That is way faster than starting up a new Amazon EC2 instance yourself, and having this extra layer has a number of other interesting benefits as well.

Heroku has a quick start guide, which pretty much runs down what you need to do. I had found a slightly more simplified quickstart here. I already had an existing Sinatra-based app that I wanted to test on Heroku, so here were my steps:

1. Install heroku gem

sudo gem install heroku

2. Setup Heroku account info, and upload public key

heroku keys:add 

This will prompt you for your Heroku account info. If you have not created one yet, better jump over to http://heroku.com/signup and create one

3. Create Heroku app from my existing app
I just changed so my current directory was the app I wanted to add to Heroku, then entered:

heroku create myappname

This creates the new app on Heroku, and creates a remote branch so you can deploy just by pushing the code.

4. Deploy my code

git push heroku master

That's it! If you have a really simple app, with no database access, you are done. What, you are deploying a Ruby on Rails app and need a database setup? OK, then...

5. Run database migrations

heroku rake db:migrate

NOW, you are fully deployed and running on Heroku. Unless you are not. I still had a minor problem with my app. I was writing my log file into "logs/production.log" but Heroku does not normally allow write access to disk. The two exceptions to this are the "tmp" directory and "log" directory (notice singular). They do provide an easy way to view your most recent log entries, by typing

heroku logs

which is how I figured out my problem with the log directory.

So, here is my total time required to deploy this app on Heroku:
- Reading quickstart = 3 minutes
- Installing gem and entering account info = 2 minutes
- Making my app a Heroku app = 1 minute
- Deploying my app for the first time to Heroku = 2 minutes
- Figuring out what I had done wrong from the Heroku documentation = 10 minutes
TOTAL = 18 minutes

Here were my bonus steps:
- Reading Heroku docs on using a custom domain with Heroku = 1 minute
- Realize I need to rename my app using Heroku command line = 1 minute
- Rename my app using Heroku command line = 1 minute
- Setting my DNS settings to point to Heroku = 5 minutes
- Telling Heroku about my custom domain = 1 minute
TOTAL = 9 minutes

So there you have it... a fully deployed app, living in the Heroku grid and consequently the Amazon EC2 cloud, in less than 30 minutes, having never used their tools before, including troubleshooting a minor configuration problem. That may seem unfair... and it is. That is exactly the kind of unfair I like on my side!

Much credit should go to the Heroku team for creating something extremely cool and functional. Important details are still not available, like pricing etc., but at least for now Heroku, is a great way to easily get your app up into the cloud within literally minutes.

What is the future for Heroku? Funded by Y Combinator, they have been quietly working away, and now with Sinatra team leads Blake Mizerany and Ryan Tomayko onboard as well, I think we will be hearing a lot from this exciting little company.

LARubyConf 2009 - Jim Weirich - "The Grand Unified Thoery of Software Development

As the 2009 Los Angeles Ruby Conference (LARubyConf) drew to a close, our keynote speaker Jim Weirich took the podium. I have seen Jim speak several times, and he is both intelligent, as well as down to earth, which is a rare combination indeed.

The subject of his keynote would be anything but down to earth. In fact, it would have to be one of the most ambitious talks I have ever seen at a Ruby conference. Only Jim could have pulled it off as he did, with both humor and insight.

One thing Jim does is have to conduct Tech Interviews. One question he always asks is "What do you look for in a good design?" Most people's answer: "UMMMMMM..."

Then Jim seemingly shifted themes abruptly, to physics. Specifically, subatomic particles.

It is known that particles that are charged the same repulse each other. Furthermore, every time you change electric field, there is a changing magnetic field at 90 degree angle.

James Clerk Maxwell
Maxwell discovered 4 equations that describe relation between electrical and magnetic fields. By describing these two entirely separate forces, combines into single force. Maxwell's work probably greatest contribution to science.

Then, along came Ernest Rutherford's famous electron experiment. The one where electrons were supposed to evenly deflect onto a screen, but instead occasionally would deflect wildly. As a result, we now know that matter was mostly open space.

There are four known forces
- electromagnetic
- gravity
- strong nuclear
- weak nuclear

The search for the "Unified Field Theory" in physics is a search for a single explanation that accommodates all four forces.

This is very much like the search for a single explanation for software design.

Some Commonly Accepted Software Design Principles
- SOLID
- Law of Demeter
- DRY
- Small Methods
- Design by Contract

Lots of ideas about how to write software, but no grand unified theory.

"The Grand Unified Theory of Software Development"

Composite/Structured Design
- Glenford J Meyers - 1978

Coupling & Cohesion - from best to worst
- no coupling
- data coupling - local data, simple
- stamp coupling - local data, structured
- control coupling
- external coupling - global data, simple
- common coupling - global data, structured
- content coupling - when you reach inside of modules and mess with them from outside

control coupling
- method has flag parameter
- flag control which algorithm to use

Symptoms
- word OR in description

Example:

Array.instance_methods(true)

and

Array.instance_methods(false)

Which one lists only private methods?

Another example, Rails does this:

Customer.find(:all)

vs.

Customer.find(:first)

Myers' classification were OK, however failed to extend well to objects and dynamic languages

Meilir Page-Jones's book "What Every Programmer Should Know About Object-Oriented Design" has 3 sections, two of which are not too useful, but the third is very interesting. It talks about the idea of Connascence in software design.

Connascence - when two things are born and grow up together
Two pieces of code share Connascence when a change in one module requires a corresponding change in the other.

CoN - Connascence of Name
- when code linked by name
- can also apply to databases
- class name is NOT, but parameters are

Locality Matters
- if you have things grouped together, there is stronger connascence.
- as dist increase, you reduce connect between them

Connescence of Position
- when the order of the params matters

Low/high degree of CoP

When you encounter CoP it is better to transform it to CoN

Degree Matters

CoP in test data example

  User.find(:first)

CoM - Connescence of Meaning
- when two bits of code have to agree on the meaning of data

When you encounter CoM it is better to transform it to CoN

Contranesence is when things have to change opposite to each other
- for example, collision of class names in two different modules
- solution is to use namespaces

Another Example?
- do not monkeypatch unless you have to, and if so use namespaces

Connascence of Algorithm
- Two methods that do different things, but that are bound together by algorithm. For example, two different bits of code in two different languages that have to talk to each other. JavaScript client, Ruby server is good example.

CoA -> CoN
- also known as DRY

CoT - Connascence of Timing
- for example, a race condition

Summary
- Connascence is the 'quark' of software design
- Not really any tools to analyze code
- Seems like there is a relation between connascence and design patterns

Wow! Jim had taken us all the way from subatomic particles, to a start towards a unified theory of software design, and tied it all together nicely. And made it fun! It was a tremendous cap on an excellent conference, and we all had really appreciated Jim's contribution.

LARubyConf 2009 - Blake Mizerany - "Sinatra: the Ultimate Rack Citizen"

I was very happy when the next presenter at the Los Angeles Ruby Conference 2009 (LARubyConf) was Blake Mizerany, creator of the very cool Ruby micro-framework Sinatra. As long-time readers of this blog know, I am very into Sinatra.

There has been an incredible amount of work going into Sinatra lately, so I was very interested to catch up on what the team has been up to.

What is Sinatra? A Ruby Domain Specific Language (DSL) Mapping REST to simple actions

Why?
- small
- fast
- great rack and ruby citizen
- strong focus on HTTP
- HTTP caching helpers built in before it was cool
- content negotiation
- no boilerplate
- dead simple config when the default are not enough
- smart configuration
- DOCS- sinatrarb.com
- extending is easy
- rack is the only dependency
- very low WTF to LOC ratio (jeremy mcnally's rubyfringe talk)

when?
- a few controllers models and views
- starting any web application
- you need reusable apps and/or middleware and/or resources
- you need speed

who?
- heroku
- github
- taps
- integrity

sinatra in your gems
- a mini-github for offline repo browsing
- a local plugin and play wiki
- memcached utilization graphs
- config reusable github hook

Example: NotTwitter

As classic Sinatra

set :username,
  Proc.new { fail "yo"}
  
get '/' do
  ...
end

Change

  require 'sinatra'

to

  require 'sinatra/base'

But I want to deploy to Passenger or Heroku! No problem.

./bin/install-not-twitter
Copy example config.ru to cwd
Copy .gems file

.ru is a standard Rack config file.

.gems is a Heruku configuaration file that will handle any needed Ruby gems installations

  git init && git add .
  git commit
  heroku craete
  git push heku  aster
  heroku 

3 Awesome Features in Sinatra
pass - I cannot handle this request, try the next route
forward - sinatra as middle ware... done my job, let the next app take over... pop in front of rails metal
use - Sinatra loves rack so much, we made sure not to hide it


Resources
http://sinatrarb.com
http://github.com/rack/rack
http://github.com/rack/rack-contrib
http://github.com/rtomayko/rack-cache

If you are doing everything with Rails, you are probably using too much for the job. Sinatra is simple, fast, and extensible. I am using it in two production applications right now, along with Rails. Sinatra handles parts of the application better than how Rails does, so that is how I roll.

Especially with the ever increasing momentum behind Rack, Sinatra is a good bet for getting things done. Combined with Rails Metal, and you really have it all.

LARubyConf 2009 - Danny Blitz - "Herding Tigers: Software Development and the Art of War"

I had no idea what I was about to experience at Los Angeles Ruby Conference 2009 (LARubyConf) when Danny Blitz took the podium as the next presenter. I had seen him hanging out with his distinctive pompadour, tattoos, and leather jacket. He is a big guy, and hard to miss. But he had been pretty quiet till then, which was about to change radically.

Herding Cats is a term commonly used when describing the management of software teams. But when Danny Blitz says cats, he means big cats aka tigers. So who is this guy? He has done TONS of stuff, from DOD to Dell, to the DARPA autonomous vehicle challenge. Very cool stuff.

Get Agility?

"A good plan violently executed now is better than a perfect plan executed next week" - Patton

Q. Why is software so difficult?
A. We don't want to face the truth

Q. Why don't we want to face the truth?
A. We're afraid

Q. What are we afraid of?
A. We're afraid we do not know anything about end result

Q. How can we deal with this?
A. Admit the truth

A tiger team is a small self improving team.

What can you expect from a tiger team?
Their first project was scheduled to take 5 weeks - took 5 days

TIGERS ARE A TEAM!

QA is part of tiger team

Tigers show leadership

Tigers self-improve

Almost no meetings on a tiger team

QA and test automation are the tip of the spear

QA should be there from very beginning

Shared psychology and intelligence

Winning, boldness, excellence

Not afraid of the dark

Who is on team?
- all staff needed to deliver product
- leader, 4 devs, 1 automation engineer, 1 Q, product staff m,ember
- in addition, architecture, system admins, any other support staff

why warfare?
- business is battle

There are two kinds of warfare: attrition and maneuver

Attrition warefare
- traditional, tactical
- clashing head-on

Maneuver warfare
- internet space
- rapid modern violent
- unexpected movements

Speed
- it is a competitive weapon
- undeniable advantage in business

Speed mitigates risk
- not a guarantee
- damage is contained by quickly compensating

Speed improves the team

Speed adds to job satisfaction

Speed allows agile to function properly
- max iteration length (usually 30 days)

Speed builds credibility
- shows a lot of work in short order

Cows and tigers
- cow is bigger, but who wins?

Disease: using agile terms to describe non-agile project

Corporate animal kingdom
- Tiger
cautious, calculating, looks to win

- Cow
herding
not known to be original
afraid of risk

- Bear
big, usually mellow
awesome battle skills
live and let live attitude

- Leopard
truly wild
will attack at any time

- Elephant
huge and tough
invincible
best to avoid battle

- Hyena
scavenger
steals food
evil

"Tiger teams are like Hell's Programmers" - Danny Blitz

Leadership
this is what makes or breaks
faith
love
hope
success belongs to the team
failure belongs to the leader
buck stops here
fearlessness
listener and learner
protector
outside influences
internally too
team members themselves

US marine management techniques
- manage by end state and intent
- reward failure
- demand to be questoned
- glorify the lower levels of organization

Politeness and professionalism
- that or poison

Agile is not a methodology, it is a mindset, it is inevitable

Danny says he is working on the book called "Herding Tigers". He has also started a blog at herdingtigers.com. All I can say is, he is a very dynamic and exciting speaker. Everyone was captivated, myself included. I'm still not sure how I took these notes.

Rock on, Danny!

LARubyConf 2009 - Jeremy Evans - "Sequel"

The next session at the 2009 Los Angeles Ruby Conference (LARubyConf) was Jeremy Evans presenting Sequel, which is a very powerful database toolkit for Ruby.

Ruby originally had adapters for each database. The problem was that each was very database specific. This was a problem due to both SQL differences, as well as API differences.

no behavior

1997 - ruby-postgres was first created.

2000 - DBI

2004 - Active Record
Although AR made things easier, it had strong opinions. These opinions did not always map perfectly to any particular database.

2007 - Sequel

Completely DB independent API.

Example is concatanating strings, which requires a completely different syntax in each flavor of SQL database.

Concise

Optional Behavior

Opinions?

Ruby should be like clay in a child's hands - Matz

Sequel advantages:
- Simple - as possible but no simpler
- Flexible - opinions, not dogma
- Powerful
- Lightweight - 1/2 memory usage as active record
- Well maintained
- Easy to Contribute
- Easy to Understand
- More Fun

Show me the *** code!

require 'seq'
DB = Sequal.sqlite('larun')
DB[:attendees].count
# => 1

DB[:attendees].first
# => {:name ='', :address =>}

Transactions

DB.trans do
  DB[:entry],insert(:account_id => 1)

  ...

end

SQL Loggers

DB.loggers << Logger.new($stdout)

Each DB has its own connection pool

DB[:table].all # or .each

.update(:column => 'value)

.delete

DB[:table] # this is a dataset... like query cursor

Sequel is a functional API, where object methods return copies of themselves.

.select - while columns
.filter
.order

This means you can easily chain function calls, like jQuery. Awesome!

Sequel represents its internal objects using SQL's own internal representations

Sequel has 'core' and 'model'

class Attendee < Sequel::Model
  many_to_one
  one_to_many
  
  
end

Hooks & Validations - got 'em

Sequel it built entirely out of plugins. That sounds interesting, but experience with DataMapper has shown me that too many plugins may not be a good thing. However, I do not have any direct experience with Sequel yet, so this may be a non-issue.

13 - # of database adapters that Sequel supports today

Database graphing

Everything was going so well up to this point. However, Jeremy then tried to do his demo on Windows, just to show that if you are one of the poor souls using Windows, it can still work for you. He failed to account for the quirkiness of conference display adapters, and what that can do to a machine. Oh well, no demo.

That said, I was really impressed by what I heard about Sequel. I think I will have to try it out on something, just to see how it does.

LARubyConf 2009 - Aaron Patterson - "Journey Thru A Pointy Forest, or You Suck At XML"

The second presentation of the day at Los Angeles Ruby Conference 2009 (LARubyConf) was Aaron Patterson, XML maniac. I had a run at hardcore XML/XSL a few years back, and it has been a while since I walked the razor's edge of the angle bracket. But Aaron is not just an aficionado, he is genuinely obsessed. Given that he is the maintainer of the Nokogiri and Mechanize gems, this makes me happy.

He covered four areas related to XML:
- XML Processing
- HTML Processing
- Data Extraction
- HTML Correction

The XML Processing section was as thorough a synopsis of XML as one could possible fit into just a few minutes. He went over the four main XML processing styles:
- SAX
- Push
- Pull
- DOM

SAX parsers are fast, and low on memory use. However, searching is hard, doc handlers are verbose, and programmer expense high.

Push Parsing works the same as SAX, the difference is the programmer controls document IO. Has low memory use, fast, fine control over IO.

Pull Parsers are handed XML, and yield a node object. They work like cursors, moving thru the document, so you only get one chance to process data without starting over from the beginning again.

DOM Interface is what most programmers are familiar with. Given XML, they build an in-memory tree. They can then be easily searched using XPath. DOM parsers provide easy data extraction, are programmer friendly, but have high memory use, and you pay a serious speed penalty.

HTML Processing is just like XML parsing, but it limited to the HTML DOM.

Data Extraction in XML can be done two different ways:
- CSS selectors
- XPath queries

XPath basics:

  //foo <!-- start at absolute root -->
  .//foo <!-- start a relative root -->
  //foo[@bar] <!-- has bar attribute -->
  //foo[@bar = 'baz'] <!-- has bar attribute with a value of 'baz' -->

Here is an example of a problem for parsers that support either CSS and XPath selector as parameter, like Hpricot:

p[b]

The problem is that it is both valid XPath AND CSS. Nokugiri has separate methods for searching CSS or Xpath, so as to avoid this problem.

XML Namespaces use URL's to remain globally unique, to avoid collisions between XML formats taht are different, but use the same node name. Here is an important point: XML Namespaces are as important as tag names.

HTML Correction is taking some invalid HTML, and "fixing" it. For example, making sure that all tags are properly nested.

Aaron wrote a tool called tree_diff, that compares XML trees, cause "they are interesting". With this tool he was able to process many HTML files with multiple HTML correctors/parsers, then compare the results to see if they matched. In many cases, they did not!

Fonts are hard
Attributes are harder

29% of the time it works all of the time

Seems like after all that, I will never use anything but Nokogiri for XML parsing again!

LARubyConf 2009 - Dan Yoder - "Resource Oriented Architectures and Why It Matters"

Lead-off man Dan Yoder started off the day's proceedings at the Los Angeles Ruby Conference (LARubyConf) 2009, with a presentation on Ruby Waves called "Resource Oriented Architectures and Why It Matters". Despite not getting the same attention that some Ruby frameworks have, the Waves team has been tirelessly working on it. According to Dan, the foundation of Waves has gotten pretty solid. Waves adds a lot of support for things over and above just handling http requests. So what is Waves really? It is a layer on top of Rack for defining application frameworks.

The next thing beyond MVC is to help developers write more rest compliant apps.

But do the constraints in REST really buy anything? Actually, yes.

One nice thing about internet-based development, is that the existing infrastructure is already there like proxies, load balancers etc.

But why does it work? At the heart are the constraints.

The web is NOT MVC
- so why do we use it so often for web apps
- piggybacking off of the web browser

Example of busting out of the browser - RSS feeds from blogs and podcasts

OAuth SMART Proxies

Video Search
- edge caching

Resource Oriented Architecture (ROA) is just distributed objects, loosely based on Roy Fielding's definition

ROA solves an old problem, that there have been many attempts at solving previously with CORBA, COM, etc. But this time will be different.

Learning From Past Mistakes
- be platform neutral
- be wire neutral (any protocol)
- define meta-object protocols
- good performance, use edge and client caching
- allow layered architectures

Waves and ROA

Rich DSL for HTTP Requests

on (:get, ['location'],
  :query => {:lat => /\d{4}/, :long => /\d{4}/},
  :accept => [:json, :xml])

But it is still Ruby!

The One File Waves App
- influenced by Sinatra
- not quite as clean as Sinatra

Roadmap

A Resource DSL Example

class Blog
  include Waves::Resource::Server
  
  resource :list, :expires => 3.days, ['blogs'] do
    get { model.find_all}
  end
  
  ...
  
  schema :element, ['schema', 'blog', '2009-03'] do
    attributes :title, String, :descriptions => String
    link :entries, :list => Story
  end
  
  ...
end

What's with that "schema" block? This example also defines the RDF schema for the resource to provide machine-discoverability. That is one very cool aspect of ROA that I personally have not seen addressed much within the Ruby community.

Waves is really coming along, and I am planning to explore it a bit in the coming weeks. For more info, go check out http://rubywaves.com

LARubyConf 2009 Was A Big Success

Yesterday was the first ever Los Angeles Ruby Conference. Despite being located a bit out of the way, down in Tustin, the venue was actually completely amazing. Called the Marconi Automotive Museum, the place was like "Robin Master's garage" quipped one attendee, being that it was FULL of Ferrari's and other highly valuable and hot sports cars.

Thanks to the tireless efforts of Coby Randquist and JR Fent, along with a host of others, this first conference was a tremendous success. There was an incredible lineup of speakers, with something for everyone. All of us who attended were really impressed by the quality of the event. There was even one guy who came all the way from Boston (this is great time of year to visit California from the east coast, people). After a short introduction, the program was off and running.

The sessions were:

Dan Yoder - "Resource Oriented Architectures and Why It Matters"
Aaron Patterson - "Journey Thru A Pointy Forest, or You Suck At XML"
Jeremy Evans - "Sequel"
Danny Blitz - "Herding Tigers - Software Development and the Art of War"
Wolfram Arnold - "Scaling 'most popular' lists: a plugin solution"
Blake Mizerany - "Sinatra: The Ultimate Rack Citizen"
Michael Fairchild & Ari Lerner - "Poolparty.rb"
Bill Lapcevic - "Managing Ruby on Rails for High Performance"
Ron Evans & Damen Evans - "Flying Robot: Unmanned Aerial Vehicles using Ruby and Arduino"
John Barnette & Aaron Patterson - "Johnson"
Pradeep Elankumaran - "Fast and Scalable Front/Back-end Services using Ruby, Rails, and XMPP"
Brendan Lim - "Mobilize Your Rails Application"
Adam Blum - "Rhodes Framework for Mobile Client Development"
Jim Weirich - Keynote speech - "The Grand Unified Theory of Software Development"

I took copious notes, and so I will be posting separately for each session, to avoid a massive blob post. The sessions were quite excellent, our demo of flying_robot was really well received, and Jim Weirich's keynote was by turns funny and thought provoking.

Thank you to everyone who participated by organizing, presenting, and/or attending LARubyConf. The 110 or so people there really appreciated it! I had a great time, learned a lot, met some great new people, and got to see some old friends. I really look forward to the next one!

The Twitter 1-2-3 Rule

I just had a small realization: there is a perfect ratio for Twitter use. Wait, before you laugh and hit the back button, hear me out on the following idea.

There is an emergent trend in optimal Twitter use:

If you have X followers,
You should have 2X people that YOU follow
And have made 3X updates

Get it? Twitter 1-2-3. Nice simple rule...

Here is what is means if these ratios are out of whack:

• Less then 2X people that you follow = who do you think you are, Shaq?


• More than 2X people that you follow = perhaps you should do something besides Twitter?


• Less then 3X updates = why are so many people following you?


• More than 3x updates = you really like to listen to yourself, don't you?

Let's Celebrate The Female Side Of Tech

It is Ada Lovelace Day today, and to support the women in technology, bloggers all over the world are celebrating the female side of tech. What do I mean? You may not know it from the throngs of hairy guys at tech events, but not only are there women in tech, they have done a lot to make YOUR life easier. Let's review a couple current ladies of technology that have been rocking my world.

First of all, no mention of modern geek tech can even begin without another Ladyada, aka Limor Fried. As the proprietor of Adafruit, she has done a lot to make physical computing with Arduino and other cool hardware a lot more accessible for novices, as well as helping out pros when they are stuck. As as engineer and MIT alumni, she is a great leader in the electronics community. We could not have made the progress we have on the flying_robot project, without her great hardware and helpful blogging.

Another female developer I know is Andrea O.K. Wright. Andrea is a very serious Rubyist, and did a really great talk on Ruby in gaming that I attended a while back. She was even kind enough to remember to send me a couple links to some of the tech she had mentioned in the presentation.

We smelly guys have to be be a bit more welcoming to the women of tech. Why? Not even for any of the standard reasons related to social progressivism. Simply enough, we all need all the help we can get, and not encouraging women to explore their interests in technology, is like losing 50% of the potential advancement we could be collectively making.

'Nuff Said!

Project Flying Robot: I Believe I Can Fly

At long last, after many obstacles to be surmounted, yesterday we achieved liftoff. The blimp prototype "Rogue 1" of our flying_robot project to create a platform for Ruby Arduino Development powered Unmanned Aerial Vehicles has achieved an important milestone.

After our third complete rewiring of the main circuit board, two burned out Pololu micro serial motor controllers, some time reviewing the schematics of the Blimpduino project, and too many revisions to the basic software to list here, we had finally gotten everything ready for what would hopefully be a successful flight test.

There were some major limitations to this test, which was mostly intended to verify proper functioning and integration of the hardware. Happening inside my brother's small apartment, we would not be able to really do much flying. Also, we were going to measure our maximum payload capacity, but not really planning on balancing the blimp to achieve a proper neutral buoyancy.

The final assembly took place, we did a quick flight check, and you can see for yourself the results in this poorly shot and edited, but somehow still amusing video.

Now, this thing is really starting to take off!

Come Fly With Us At Los Angeles RubyConf 2009

Yes, the rumors are true, our talk for LARubyConf was accepted. If you want to see the first ever public live demonstration of flying_robot, the real thing, actually flying around and such, come check it out live and direct at the first Los Angeles Ruby Conference on April 4.

I do yet not know exactly what our demo will include, but from what we have been doing so far in the lab, you won't want to miss this one. Unless what you get to witness is massive fail. Either way, it will be spectacular.

Not to mention, there are some really excellent presentations happening. Actually useful stuff you might put into daily practice. We're talking shining beacons of the Ruby community like Jim Weirich, Jeremy Evans, Aaron Patterson, Daniel Philpott, Dan Yoder, my boys Ari Lerner & Michael Fairchild, and many, many more. So if you have not registered yet, get with it!

Click here RIGHT NOW and register for LARubyConf. Do it!

Project Flying Robot: Better To Burn Out Than Fade Away?

We had made incredible strides forward in our construction of "Rogue 1" our autonomous blimp that we are building as the first implementation of flying_robot, our Arduino-framework for Unmanned Aerial Vehicles based on top of Ruby Arduino Development (RAD). We are also heavily influenced by the cool Blimpduino project. We were finally ready for a live test... or so we thought. We inflated our envelope, and my brother attached the gondola that he has been carefully constructing.

We had already done some testing of the software/hardware, so we were heady with our previous successes. "Let 'er rip," said Damen. Next thing you know, the blimp was careening about, as the motors pulsed wildly out of control, then stopped abruptly. "That is not a good sign from an electric motor controller, " said my brother glumly.

We peeled the gondola off the envelope, and disassembled the components that had been connected so carefully, and yet not carefully enough. Multimeter in hand, Damen carefully traced each connection looking for power as I entered the commands into the serial interface.

Finally, after a few moments we looked at each other. There was one more test... we rewired everything properly, but using the spare Pololu Micro Dual Serial Controller and a breadboard. I entered the commands and the motors powered up. Now there was only one conclusion: we had fried our costly little Pololu.

Ouch! After spending a while on post-mortem analysis of our dead little bird, Damen muttered something about power. "Huh?" I looked up from debugging the Arduino code for the differential thrust calculations.

"Power. We need less power."

"Less power? I thought the specs said that controller was rated for more than our LiPo battery and more?"

"Specs lie."

I had to acknowledge the simple truth of that statement, especially given the obviously dead chip. With a lot more knowledge about our bimps power requirements, learned the hard way, Damen began planning the third iteration of our main board wiring, with a new extra power regulator. And an external kill switch.

Project Flying Robot: By Your Command

Our flying_robot project for Unmanned Aerial Vehicles has been underway for a few weeks now. Much soldering, and playing around with cool Arduino tricks has been taking place. You can read more here, here, here, and here if you need to catch up.

One aspect that I have mentioned several times, but not gotten into much detail about, is our protocol for communicating with the UAV from the ground station. It is amazing to me, but there is still no dominant digital protocol for controlling UAV's. Many people are this using analog radio controllers, with some kind of sideband channel for autopilot commands.

There are a few characteristics that seem essential to me for a proper ground control system design:

• A nice way to send control stick commands from a "virtual r/c" that can be used with any UAV


• Consistent way to send autopilot commands


• A way to be able to read the instruments remotely, and display them as part of your "control surface"

Another observation I have, is that there is every current Arduino UAV project has an entirely different code base. There also does not seem to be any practical way for these projects to share much, even though they are all targeting the same microcontroller.

Certain characteristics seem essential for developing on-board UAV system programming, but are lacking in any of the projects I was able to find:

• A nice, modular way to put together the pieces you need in software that match the hardware configuration for that particular vehicle


• A high-level domain specific language (DSL) to specify the UAV's behavior, and not just programming in C++ or assembly language


• A consistent programming interface that corresponds to the protocol used by various ground controllers

With all of these design criteria in mind, I have been implementing the flying_robot command parser and interface. Here is an example of the minimum code required to create a UAV using the current implementation:



As you can tell, there is not all that much to it. The base for a UAV in 34 lines of code.

The most current code for the actual "Rogue 1" LTA vehicle is being committed to http://github.com/deadprogrammer/flying_robot_rogue_one/tree/master if you want to follow along with our progress.

Next post, we test the main thrusters and vectoring controllers, and nearly start a fire...

Playing With Hoops, or Every Step You Take

I do not often pay full attention to Giles Bowkett. That is the flip side of being the provocateur that he is, some people will occasionally tune out. However, when anyone plays the Steve Krug card, I am compelled to take a look.

Yesterday, Giles posted a dead-on point about user registration, called "I Don't Care About Your Hoops". When you compare the success of simplicity, as in the Google and Apple examples, to what we all tend to fall into, I hope you are as embarrassed as I was. Time for some self-examination.

I was ready to hack down the user signup process to size. Here are my new rules:

• 4 or more registration steps = FAIL


• 3 registration steps = A long shot, but you might make it


• 2 registration steps = At the top of the key, worth taking a shot, but no sure thing


• 1 registration step = A free throw, you should easily sink it


• 0 registration steps = Slamdunk ala Michael Jordan. Ain't no stopping us now.

Project Flying Robot: The Flying Dorkboard

As we proceeded along with our flying_robot project, one thing became abundantly clear: weight matters. The Arduino Diecimilla that we had been using up to this point, although a fine package for beginners, was just not going to make it when it came time to weigh in. Yes, there is the Arduino Nano, but it is not a cheap device. Also, it has a few options that were not important to us, like the integrated USB, since we planned on only using XBee based communication with the blimp.

I had been doing some research, and have learned a lot more about this whole Arduino ecosystem. There is incredible work being done by people like ladyada, and many others too numerous to list here. There are many variations on the Arduino, like the Boarduino, Sanguino, and so many others.

However, one option in particular caught my attention, called the Dorkboard. This thing is small, I mean tiny. Especially considering that it does not use the surface mount version of the ATMega microcontroller. And it has almost nothing on the board itself. You need to provide both power, and an interface to communicate with it, in our case, using the XBee modems.

This highly stripped down, minimalist approach was exactly what we had been looking for! Cheap, simple, light, and having everything that one needs from any Arduino/Freeduino platform. I ordered a few of the kits, and they were shipped from Wulfden just a few days later.

Once they came in, my brother was eager to get right into one. I dropped off the package, and he had soldered up one, plus the power supply, in less then an hour. We had the USB-BUB interface, so we just plugged it in. Once we had all the cable pinout correct, and we had downloaded the "hello, LED" code from RAD, we were watching it flash under our command.

The brain of our flying robot was ready! Now we needed a way to communicate with it, and update its code, all wirelessly. The next step, would be building an XBee breakout board, and doing some XBee hardware/firmware hacking...

RailsConf 2009 Program Is Looking Juicy

I just noticed that there are already a whole bunch of the approved presentations for RailsConf 2009 on up the web site here.

It is looking really good already, go check it out. If you are into Ruby on Rails, you really should be going... I am!

Project Flying Robot: A Compass, Two Motors, And A Servo

Last weekend was a fantastic hardware/software jam session with my brother Damen, working on our autonomous Ruby Arduino Development (RAD) powered blimp. Lots of little pieces had been coming in the mail, my brother had been soldering, and I had been programming away. Both of us were eager to start putting it all together.

The first item of business was getting our bearings. We had acquired from Sparkfun a very cool HMC6352 digital compass module. Based on the Honeywell chip, this tiny but powerful breakout board is a very easy device to use with Arduino, thanks to supporting the i2c protocol, also known as "two-wire interface" or TWI. No one had created a RAD plugin yet for this device, so I had whipped one together a couple days earlier using some Arduino code I found online, combining with the techniques used in some of the examples in RAD. Now, finally I would get a chance to see if it would work.

We plugged in the unit to our handy breadboarding setup, downloaded the code to the Arduino via USB cable, and viola! Amazingly, it worked perfectly the first time... we were able to obtain the heading, and turning around the unit resulted in the compass data updating correctly. Naturally, we started to get a little excited.

Of course, things would get a little bit trickier with our next item for integration: the Pololu Micro Dual Serial Controller. The pricey but useful Pololu chip allows for extremely simple serial command of 2 DC motors. Why would we want to do this, when we already have the Arduino itself? The ease of commanding a separate device that handles monitoring and setting the motor speeds, allows us to focus on the important parts of our application: integrating it all together. Plus, there is only so much processing power available in the ATMega microcontroller, so offloading that part of the work to the separate Pololu microcontroller frees up our Arduino to process more sensor inputs, and also do other interesting things we have planned.

Since the Pololu is a serial device, we used the Arduino's AFSoftSerial library to communicate with it. The soft serial library allows you to use any 2 of the Arduino's digital pins as a serial interface. Support is already in RAD for this library. With some more Google searching, and some assistance from the Pololu forums, I had written another RAD plugin. A few moments for Damen to wire things up, and we were ready for our test. We had only wired up one motor, and we had used the Arduino's own power to power both the Pololu's logic chip, as well as the motor. That would turn out to not be a very good idea.

The Pololu works by sending it simple serial commands. You tell it which of the two motors, which direction, and what speed to set it to. We fired things up set our motor to "forward speed 10" and it started to move. Glorious! So, overwhelmed with enthusiasm, we decided to try "20". Much to our surprise, setting the speed to 20 caused the motor to stop entirely. Say what? We looked at each other blankly.

You simply cannot power both the Arduino, and the motors, from the same power, unless you do some additional circuitry to provide both the higher voltage that the motors want, along with the 5V that the Arduino desires. Once we had thought about it for a few moments, it seemed obvious. We switched the motor supply to a separate battery, and the motor performed at 20. "Let's try full power", I said, and with a nod from my brother, I boosted the power to maximum. "Hey!" we both exclaimed at once a second later, as Damen grabbed for the now flying motor, which was trying it's best to lift the breadboard up by its power leads, and I frantically typed the commands that would shut down the motor. I wish we had THAT on video!

We then decided to keep going, and integrate our servo. The servo is used to change the vector of the thrust motors, a design that is also used by the Blimpduino. Unlike the main thrusters, we are just using the Arduino itself to control the servo motor, using one of the digital pins. It is really easy to use the servo library to move a servo to a particular position. In this case, no new plugin for RAD was required, cause others have already figured it all our for us. Which is nice.

We made the same mistake of connecting our servo to the same battery as the Arduino itself, due to the fact that the servo wanted the same voltage. By this point in the day, the poor thing just didn't have the force left in it. This caused the very odd side effect of resetting the Arduino itself when the servo would be ordered to move. We only realized that was what it was, once we tried getting power from the USB port. We had been testing using our wireless XBee modems. Once the power problem was solved, the servo did exactly what we told it.

It was a tremendous session, and we were now very satisfied that this project was, ahem, going to fly.