Important caveat: it's technically impossible to provide the same kind of device integration that an iPod/iPhone car or speaker system provides; audio, video, track and playlist control, viewing track information on the car system, etc. Those are things that Apple's 30-pin docking adapter all have built in, which is why it is so compelling and revolutionary. A micro USB connector can only really charge and sync a device, it doesn't not have the connections to do all that fancy integration.

I wish there wasn't this caveat. However, if you're willing to accept the compromise that Android integration cannot match what Apple provides, but want to at least get something out of that iPod/iPhone speaker or other docking system, there's a way.

Apple's dock connector (the 30-pin plug on the bottom of the iPhone, iPod, and iPad) provides many functions. Most Android phones include two jacks; a micro USB connector for charging and syncing, and a standard 1/8" (2.5mm) audio jack for standard headphones. The pins for these two connectors on Android phones can be isolated on the 30-pin connector and provided for

CableJive's dockBoss+ adapter cable does exactly this, it lets you plug a smart little adapter onto your iPod or iPhone speaker dock or car system, and provides a micro USB and audio cable so you can charge your Android phone and listen to audio, both through your docking system.

It's not the ultimate solution, but until Apple decides to open up their proprietary communication system (never going to happen), getting micro USB and audio to connect an Android phone to your iPhone, iPod, or iPad dock at least keeps your phone charged and the music playing.

Rails doesn't come with a built-in ability to connect to multiple databases, but there are lots of folks who have tackled it. Ryan Tomayko's post Rails and Scaling with Multiple Databases (written way back in 2007) is a good indicator that there are folks doing serious business with rails and multiple databases, and has some good links to other sources.

I was looking at writing something myself, but in digging around came across Octopus a few times and realized it does exactly what we need, data sharding with the ability to programmatically select databases in controllers and models, as well as good migration handling.

For the application we'll have a master database which centralizes account, user and session information with a pointer to the appropriate data shard. Once a user request has been authenticated, the actual application data gets pulled off of one of the shards they've been assigned to. The master database has a simple schema for user, account, and session information, the schema on the shards is significantly more complex, but the same on each shard.

Octopus documentation is there, but not extensive. Through some trial and error I found that the following shard.yml configuration file was what I needed (the Octopus documentation doesn't spell out how to use shard groups in a rails environment, but it makes sense once you get it working). The master shard for the environment is defined in database.yml.

octopus:
  environments:
    - development
    - test
    - production
  development:
        data_shards:
            data_1:
                adapter: postgresql
                database: dev_data_1
                username: something
                password: cryptic
                template: template0
            data_2:
                adapter: postgresql
                database: dev_data_2
                username: something
                password: cryptic
                template: template0
...

It's obviously paramount that the models know where to connect for their data. When a user authenticates I invoke ActiveRecord::Base.establish_connection() to connect to the shard so it's the default data source everywhere in the application for that request. Requests that need to interact with the master database are handled in the controller:

  around_filter :select_shard
  def select_shard(&block)
    Octopus.using(:master, &block)
  end

The other important piece of this is migrations. Octopus works well for our needs here. When a migration is written it either needs to update a single master database or be applied to all data shards. This is where shard groups come in. To apply a migration to all shards we specify the group with using_group() method, and the migration then runs for each shard in the specified group.

class CreateInventoryEvents < ActiveRecord::Migration
  using_group(:data_shards)
  ...
end

Pretty slick, happy with Octopus from a functionality perspective. Not sure about scalability and the overhead to move requests between database connections, will dig more into that next.

Etsy releases software 25 times a day with 75 engineers. They emphasize constant progress with a radical decentralization. It shouldn't work, but they are built on trust. There is one button that folks can press (after some fanfare) that pushes code up to production

They've had developers push code on their first day, they've had board members deploy code.

Chad contrasts industrial revolution assembly line times with how Etsy works. Etsy highly prioritizes letting the developers be human, having lunches together, having offices that are full of creative, fun stuff. Dogs have deployed code by guiding a paw to pressing the button.

Releases are done with a self-managed push queue, developers put their names in a queue kept track of in an IRC topic. When the first person in line pushes and is clear he/she notifies the next in line.

Remember, your team is your community. Help people finish things and see their progress.

Optimize your teams for the happiness of people.

Great ideas about software engineering and how it compares to classical engineering disciplines (civil, structural, industrial, mechanical, electrical, traffic, etc). Compares the definition and process of structural engineering to software engineering.

Is software engineering or craftsmanship? In software, the documentation that is required by other disciplines is actually the artifact that gets built in software engineering. Classical engineers diagram, plan, document, model and then take those and build the artifact. Software engineers diagram, plan, document, and model as a part of building the actual artifact. Also interesting, software is changing the way classical engineering works, a lot of software being used in the planning process to understand how the actual artifact

We are designers and builders. Software has to be the solution and describe the solution.

Programs must be written for people to read and only incindentally for machines to execute. Harold Abelson and Gerald Jay Sussman

We are engineers and craftsmen.

Nick suggests that Semantic Versioning is the best methodology. Read more at http://semver.org/

The idea is:

1.2.3 (major.minor.patch)

major versions - for major releases where there may be some backward incompatible changes
minor versions - for minor changes, no API or other changes that make it incompatible with previous versions
patch version - for fixes, improving stability

I walked into the park at 6:30pm, left just under 6 hours later at 12:10am. Although I went by myself, I made a bunch of friends with the Orioles fans in the Picnic Perch (food isn't fancy, but a nice thing to have all-you-can-eat at your fingertips).

It was supposed to rain, and we saw a little lightning in the distance. It misted up a little, but not a drop of rain.

Favorite thought: be nervouse or your aren't trying hard enough.

Aaron says the right way to go at a new idea is to make decisions that make you nervous, all the time. This means you are pushing forward.

Advice that makes me feel better about some of the crazy stuff I've faced as the leader at a growing company. And excited to try some new stuff.

So I embarked on setting things up to run my Rails app right on my MacBook Pro. Yea, the thing that 99% of the rest of the Rails community has been doing for years.

I figured everything except PostgreSQL is either already on the laptop or is nicely grouped together in the my Rails application in git. So I installed Postgres from their OS X Postgres install page.

Checked my git repo out on OS X, ran the "bundle install" and got:
Installing pg (0.11.0) with native extensions /Library/Ruby/Site/1.8/rubygems/installer.rb:533:in `build_extensions': ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby extconf.rb
checking for pg_config... yes
Using config values from /Library/PostgreSQL/8.3/bin/pg_config
checking for libpq-fe.h... yes
checking for libpq/libpq-fs.h... yes
checking for PQconnectdb() in -lpq... no
checking for PQconnectdb() in -llibpq... no
checking for PQconnectdb() in -lms/libpq... no
Can't find the PostgreSQL client library (libpq)
*** extconf.rb failed ***


Obviously a failure. The Gemfile includes "gem 'pg'", which works fine up on the Linux servers but apparently doesn't do so well on OS X.

A lot of digging and reading, followed by a lot more digging and reading.

The first solution...when compiling pg, the gem needs to have an environment variable set:
env ARCHFLAGS="-arch i386" bundle install --path /Users/mike/inventory/vendor


No problem running the bundler, but when you actually try to use the database:
bash$ rake
rake aborted!
dlopen(/Users/mike/inventory/vendor/ruby/1.8/gems/pg-0.11.0/lib/pg_ext.bundle, 9): no suitable image found. Did find:
/Users/mike/inventory/vendor/ruby/1.8/gems/pg-0.11.0/lib/pg_ext.bundle: mach-o, but wrong architecture - /Users/mike/inventory/vendor/ruby/1.8/gems/pg-0.11.0/lib/pg_ext.bundle
/Users/mike/inventory/Rakefile:4


Tons more reading and digging, trying lots of suggestions.

Finally I stumbled into something that made a lot of sense. A post on the rails forum suggests that Ruby and PostgreSQL are compiled for different architectures and the gem pg connector isn't going to work unless Ruby and Postgres are on the same page.

I got an updated Ruby using MacPorts, same error. I got an updated PostgreSQL from MacPorts and attempted to run "bundle install" as standard.

Failed.

Then I went back to including the architecture-specific command:
env ARCHFLAGS="-arch x86_64" bundle install --path /Users/mike/inventory/vendor


Works, and I'm able to run "rake db" commands.

Everything else looks like it's in place, am running the Rails app in my browser at localhost:3000 and have TextMate loaded up with my project files.

Much, much, much better.

Bundler exists to make running your app consistent, repeatable, and guaranteed. Bundler doesn't let you use a gem unless it's in the Gemfile. Gemfile.lock keeps track of which version of the gem is running.

To publish the app. A very simple way is to tell Heroku or EngineYard to do it, they build right from your Gemfile and deploy.

To do it yourself. Make sure gems are installed within the app, not as the root user: bundle install --path app/vendor

Bundler provides a --frozen mode that makes sure that all of the Gemfile entries match up with the Gemfile.lock. This is a good thing to have in place on production.

For production: bundle install --deployment (turns on --path and --frozen)

For bundling to send to a server that has no outbound internet access: bundle path (not advised unless the only option, because requires downloading a ton of binary data from version control)

Rational, problems it solves, syntax, best practices.

What is Sass? Syntactically Awesome StyleSheets, a stylesheet generator. CSS is 14 years old, selectors, properties, and values. Web developers need to support many browsers, many output types. CSS 3 will have 33 new selectors, 120 new properties, new @rules, but no new syntax. CSS was created for designers who wouldn't have to do any abstraction.

The reality is that most stylesheets are written by programmers.

Sass comes from real world experience, brings software development methodologies to stylesheets. Brings variables, mixins, inheritance, transformations, loops, and more to CSS.

CSS has many problems. Sass has some cool stuff to address them:

- Variables: define at the top of the file and then include the variable in the stylesheet
- Color transformations is awesome: define one color and then a bunch of variations of that color to get a
- @import directive lets you pull in files, build smaller CSS sheets and then only include what you need
- nested selectors let you simplify definition of selectors

As the session winds down I added "gem 'haml'" to my Rails 3 Gemfile and did a "bundle install" to start using this now.

Jamis Buck started the idea of fat models. Originally when rails was getting going tons of stuff was going into the views, then folks started stuffing everything into the controller. 80-100 line methods. The call to action was to move logic down into the model with well described method names.

Beautiful views are HTML. Views should be data access, a little bit of looping.

Controller actions should be 8 lines.

Most of the logic should go into the model. But fat models aren't enough. A model should be like a bento box, little pieces of art, structured division. The model layer is where we get to do real programming. But models don't have to get totally stuffed full of junk.

Let's look at the presenter and presenter pattern. The formal definition of a presenter is a decorator, takes in an object and adds some new options. Jeff likes to think of a presenter as more than just adding a new option or two but to add significant simplification to the app.

Helpers are stupid, a big mess.

[I'm going to have to grab the slides from this, a lot of good food for thought and practical advice.]

After the DHH presentation. Yes, folks are excited for Rails 3.1.

The better title is Rails Best Opinions. This is a lab, so we listen to a presentation and see some slides and then get on our computers and implement the ideas in code.

A few things that caught my eye, as time permitted to jot down.

• Use scopes and default scope in the model to simplify controller logic, use a lambda for scoping where variables need to be re-evaluated.


• Use unscoped to override default scope.


• Envy Labs are coding things now where instance variables are always defined in the action (not in some helper method or down in another method where they aren't visible).


• Envy Labs are also parameters should not be used outside of the action, pass parameters to functions as arguments.


• Nested attributes simplifies code quite a bit.


• Use app presenters, not for HTML but bringing together a bunch of objects.


• use ActiveSupport::Memoizable for storing values to be retrieved more than one time.


• use responds_to() and responds_with() to simplify responding to different data formats.


• Add indexes, use something like new relic to see where there are performance issues in the app.


• Protect attributes with attr_accessible.


• use database defaults instead of in the code.


• Implement proper use of callbacks (after_create).


• Use rails date helpers.


• Improve validation with validate method for ActiveRecord::Base object, create class ActiveRecord::EachValidator to automatically run validation across many objects.


• Add errors to model with self.errors.add.


• Use db/seeds.db to put data in database, not in your migration scripts.


• Use the bullet gem, a great tool to tell you where your queries are N+1.


• When using the pluralize function, but be sure it scales to get the count of items.


• Use counter_cache technique to reduce queries when checking counts of related records.

For me, having worked heavily in Rails for the past month, the labs were a prefect stretch. Understandable, but challenging to work through the exercises.

Things I learned that I didn't know about Rails:

• When you do a lookup of an object you can call Object.save at any point and it will save the object back to the database with any changed values. I've always used Object.update_attributes


• Object.attributes method accepts a hash to update multiple values.


• You can reference a Rails value with object[:field] or object.field. The latter is more common in the Rails community.


• Rails typical thinking is to put validation in the model, not in the database.


• Rails 3 has different syntax for validation, you set the validation in the ActiveRecord::Base subclass with.


• When saving to the database that has the relationships set up in the model, you can pass in the object (not just the object_id) to the new/create method and it will find the id to store in the database.


• .erb files stand for Embedded Ruby


• Rails first checks the public folder for a match to the URL and then goes to the routes file.


• Show "no results found" by checking Object.all.empty?

One thing that has emerged as a critical component; having database records timestamped with more granularity than seconds. The solution was more involved than I would have guessed. Figured I'd log the steps since it took many hours of research and engineering effort.

1) Search for how to store microseconds in MySQL. Not possible in a traditional datetime or timestamp field. Explore all of the workarounds, none of which are ideal for the application. Realize there's no good current solution and a lot of folks have been begging since 2005 for someone at MySQL to fix so little hope it will come. See MySQL bug repot here.

2) Swallow hard and enter less familiar territory of installing and getting PostgreSQL running with the app. Lots of reading about PostgreSQL setup, configuration, and administration. Get roles set up, connected with the command-line tool, and get Rails talking to PostgreSQL.

3) Repopulate data from data sources (easier for me than the various MySQL -> Postgres transfer instructions I'd looked at)

4) Put code into Rails app to insert datetime with microseconds (this may get finessed):
...
datetime = DateTime.now
microseconds = Time.now.usec
params[:event][:datetime] = "#{datetime.to_s(:db)}.#{microseconds}"
@event = Event.new(params[:event])
...


5) Back to building functionality I was originally attempting without microseconds but was failing.

That was about two days of work, compressed into one day and a long night.

Although I've used Postgres a little bit before, I know MySQL extremely well and am comfortable in any situation that one comes across with that database (replication, disk failure, query performance, I've done it all). Postgres is a new frontier. I'm quickly becoming comfortable using it and the \ commands but know there's a lot more to be learned before I'm confortable running a production app on it.

I guess the title of this post could also be "Switching from MySQL to PostgreSQL to get DateTime records with Microseconds."