When I flew into Portland for RailsConf I walked down to Dante's to get some pizza and beer right after checking into my hotel. When I walked into the mostly empty early evening bar I noticed a spotlight on a mannequin holding a hula hoop. While waiting for my pizza slice I realized it wasn't a mannequin, it was a semi nude model surround by a handful of artists with sketch pads. Turned out that they were selling pads and pencils at the door for $5. Since I had a few hours to kill and had never tried figure drawing before I decided to give it a shot.
The first one is really crappy, but after 90 minutes (and a few beers) I think I showed a lot of improvement. Yes, still not good, but come on, look at that first one! I think that's they key with people who are good sketchers: it's not that there is necessarily some natural talent that one either has or doesn't have, it's that they do it all the time and just get better and better at it.
By the way, those are feathers on her pasties, not tassels (some folks I showed these to were confused by that).
The news has broken that Pivotal Labs has taken on the task of fixing Twitter's notorious performance problems, or as the VentureBeat article described it "Twitter brings in big guns from Pivotal Labs to help rebuild its troubled infrastructure". I think this is a smart move for Twitter. During my two years at Pivotal I was constantly impressed by the level of engineering excellence exhibited there. It was by far the smartest group of software engineers I had ever worked with and the highest quality of code I've ever had a hand in producing. I truly believe they are the best Ruby on Rails shop you can find anywhere. That's why now that I've left Pivotal to lead the engineering effort of a web startup, I'm back at Pivotal as a client. I know where to go for excellence, and apparently so does Twitter. I'm really looking forward to seeing this team crush the Twitter issue.
Note, depiction is not necessarily the actual Twitter team at Pivotal, but they are some of my favorite Big Guns there :)
[dav:~] $ history | awk '{a[$2]++}END{for(i in a){print a[i] " " i}}' | sort -rn | head
128 ruby
75 cd
57 ls
35 rm
25 sudo
13 rake
10 vi
10 ssh
9 ping
8 cat
This weeks project is a portion of a larger project. I mentioned before the site Scooping Argentina and the short videos they make explaining Buenos Aires slang to English speakers. For example: Berreta:
My project this week is my first script for doing something similar. You can imagine what next weeks project is going to be. Please leave suggestions for other Northern California slang that should be covered! I've registered the domain Slangsh0t.com and will build a site that can host a series of these in various languages. More on that later as well.
(japanese)
Hello. This is _______________ of Slangsh0t.
Californians have their own slang dialect that is not used elsewhere in the United States. Scooping Californa is here to equate you with the words of the natives.
Today we are going to learn about the word, hella.
Hel la
Hella means 'very', or 'extremely'. It is an intensifier word, primarily used to modify an adjective.
For example:
(english)
That dog is hella filthy, I think it rolled in mud.
(japanese)
or That dog is hella filthy, I think it rolled in mud.
Exaggerated pronunciation can be used to intensify the intensifier:
(english)
That dog is HELLa filthy. I think it rolled in its own feces.
(japanese)
That dog is HELLa filthy. I think it rolled in its own feces
Hella has a diminished version: hecka. This version is primarily used by children who would get in trouble for saying hella.
(english)
That dog is hecka dirty, mom. I think she rolled in the dirt.
(japanese)
That dog is hecka dirty, mom. I think she rolled in the dirt.
I'm ___________. Thank you for watching Slangsh0t Japanese.
Wired has posted an article about MySpace offering an opt-in sharing of four key portions of your MySpace account with other web sites. It was inevitable that some big site would come to their senses and do this. I'm just surprised it wasn't Facebook. As I said years ago:
I've long ranted about how Friendster blew an incredible opportunity to become the social network maintainers of the entire globe. Despite being a crappy application, they were in a position to become the center of everything if they opened up their database of connections to external application developers. Countless applications (both desktop and web-based) would have been tapped into that system and presumably sharing profits with the Friendster corporation. Having a Friendster account would have been as basic as having an email account.
Now MySpace, despite being a crappy website, are in a position to become the center of everything.
Well this week is a fairly intangible project in a way. I didn't really do anything specific, but I'm going to count my participation in Camp Tipsy, a "schmamping" trip organized by Chicken John. We camped at a lake off of I-5 in Northern California and floated a lot of weird things. In a small way I helped build the floating bar out of plywood, foam and driftwood. There were two giant clam shells carved out of foam that were used in a photoshoot and someone rescued from a one-way trip to the dump. There were four pedal boats painted with the Ritual Roasters logo. There was a working fire-heated hot tub on a tiny raft. I shot a bunch of video of the building of the bar and it's inaugural voyage. The whole thing was stupid and wonderful and I can't wait to do it again. Next time I want to build a vessel. I'd love to do a floating catapult or trebuchet but I'll settle for a swing set perhaps. Mie has more photos and description on her blog. Here's my Camp Tipsy flickr set.
Inaugural Launch of the Camp Tipsy Bar from Dav Yaginuma on Vimeo.
We got a new Continuous Integration box from Pivotal Labs yesterday and I ran into some weird MySQL time based issues when trying to get our tests to pass on it. It turned out that the CI box was running MySQL v 3.0.38, but all of our dev boxen were running v 3.0.45. Here's some difference between these two versions:
v.45 will happily take a clause of the format SELECT * FROM a_table WHERE end_date < '07-12-31' while v.38 isn't so happy with it. In this case, I have to hand it to v.38, because that date was in YY-MM-DD format which is about the most retarded date format I've seen in production code. I changed the Date#to_mysql method to use YYYY-MM-DD format and all was well.
The second issue was more odd. In v.45 if you compare a date column value with a time, the date is treated as a time value set to 00:00:00 of the day for the comparison. In other words, if the value in the date column is 2006-07-05 and you compare that with '2006-07-05 00:00:00' they are equal. Not so in v.38:
mysql> create table delme ( a date );
Query OK, 0 rows affected (0.03 sec)
mysql> insert into delme (a) values ('2006-07-05');
Query OK, 1 row affected (0.01 sec)
mysql> select * from delme where a < '2006-07-05';
Empty set (0.00 sec)
mysql> select * from delme where a < '2006-07-05 00:00:00';
+------------+
| a |
+------------+
| 2006-07-05 |
+------------+
1 row in set (0.00 sec)
I found out that the production box is running v3.0.51 so we've now upgraded all of our workstations and deployment/testing machines to that.
One of the first things I needed to have done at my new job was to convert the application from the Ruby on Rails 1.2.6 to the latest 2.x version. This wasn't the first time I've upgraded a 1.x app to Rails 2, but it's the first time with a significantly complex application. Some issues we ran into:
The dreaded "Expected X to define Y" error message. This message can come from a few places in the rails code, and it is a usually useless message that obscures the real problem. In this case I added a rescue clause around an internal require statement in active_support/dependencies.rb and reported the true culprit: a model definition was bombing out when trying to require acts_as_list. Many of the acts_as components of ActiveSupport were pulled out to plugins in Rails 2. So the solution was to script/install acts_as_list.
The rake deprecated task is handy, but it just does a context-free grep of the source code and warns about code that isn't problematic, like complaining about @session_key with "@session is deprecated, use session instead". Still it's a helpful place to start. It didn't catch everything of course. It was fine spotting the deprecated render_partial calls, but it didn't complain about render_text for example.
We had a number of problems in tests that had been dependent on the fact that in Rails 1 fixtures loaded into models didn't set the timestamps. In other words, unless you specified a created_at or updated_at in the YAML file you got NULL for those columns in the database. In Rails 2 apparently that's no longer true. It sets the timestamps on all fixtures. A quick workaround for this that worked for us was to clear the fixtures before tests that were dependent on only certain records having timestamps. The tests and fixtures will need to be fixed eventually.
Behavior change in the radio_button_tag. Rails 2 added this:
def radio_button_tag(name, value, checked = false, options = {})
[...]
pretty_name = name.to_s.gsub(/\[/, "_").gsub(/\]/, "")
[...]
end
Which changed the ids on several of our input tags to something arbitrarily prettier but unexpected by the application.
Associations on models were screwy. From script/console:
>> g.game_category NoMethodError: undefined method `game_category' for # from /Library/Ruby/Gems/1.8/gems/activerecord-2.0.1/lib/active_record/attribute_methods.rb:205:in `method_missing' from (irb):2 >> g.game_category_id => 1 >> class << g >> belongs_to :game_category >> end => nil >> g.game_category => #This was annoying. I dug back into the active_support/dependencies.rb and started puts-ing around with the code that does the loading. I found that the Game constant was being defined when the Migrator class was being loaded. It turns out that a migration was defining Game in order to cheaply access some ActiveRecord methods, but not bothering to declare the associations. I could have added the association in the migration, and I thought for a moment of changing the AutomaticMigration code to clear any constants it loaded when it was finished, but decided the safer and quicker appproach is to just rename the class in the migration and use set_table_name to point it at the games table. This goes along with my general notion that using ActiveRecords in migrations is a bad idea.
As I've mentioned before, the Coachella web site helpfully provides one or two tracks for most of the 100+ artists at the festival so you can hear samples of the bands you don't know to help determine if you want to go see them or not. They even have a scheduler page where you can select the bands you want to see and hide the ones you know you don't. The user experience is poor though. While listening to the provided tracks you can't easily make note of which ones you like or not, and there is no real link between the schedule page and the listening page. Plus in the end, how are they going to handle it when you select two artists scheduled at different stages at the same time?
My project for this week is a remix of the coachella web site to help make the exploration experience little better: Coachella Explorer. Here you can listen to the tracks from the official website, but as you listen you can also rate each artist on a scale of 1-5. When the official schedule is released, the site will be able to take your ratings and calculate a schedule for you. If there is a conflict it can perhaps be resolved by the relative rating you gave between bands in the same time slot.
This took a bit longer than I thought to complete. Partly because TextDrive sucks (I don't feel like going into details on this now - too annoyed), and partly because I never have time to work on these things anymore it seems. There are certainly features that would make it nicer, from little things like Netflix-like stars for rating instead of a select drop down to major features like sharing your picks with your friends and then producing an optimized schedule that keeps you at the same shows as much as possible. Maybe next year. As it is, the festival is less than a week away and probably no one is going to use this thing except me. Which is probably for the best since I was forced to host it on my decade+ old linux server that's slow as a turtle dragging a cinderblock. Any significant traffic would likely slaughter the server.
By the way, I call it a remix because all of the media (music and images) are still being served from the Coachella web site. I'm just sort of putting a new interface on top of it.
I need to hire some Rails developers at Lumos Labs, so I decided to write a spec for the position:
http://sfbay.craigslist.org/sfc/eng/646385102.html
require File.dirname(__FILE__) + '/../spec_helper'
describe Developer do
before(:each) do
@developer = Developer.new(ideal_developer_qualities_ hash)
end
it "should test drive" do
@developer.should be_test_driven
end
it "should know rails 2.x" do
@developer.experience.should include(:rails2)
end
it "should know REST patterns" do
@developer.experience.should include(:rest)
end
it "should use selenium" do
@developer.experience.should include(:selenium)
end
it "should use capistrano" do
@developer.experience.should include(:capistrano)
end
it "should receive competitive compensation" do
@developer.should respond_to(:competitive_compensation)
end
it "should like brains" do
@developer.should be_familiar_with('www.lumosity.com')
end
end
I know the 'it' thing seems a bit odd, that's just how rspec works. I could have created a new dsl but then he_or_she looked dumb too. I was tempted to add an "it puts the lotion in the basket" but figured that would be just a tad too creepy for a job listing.
While on Chicken John's bus trip to Death Valley, I participated in a couple of exquisite corpses. From wikipedia: "a method by which a collection of words or images are collectively assembled." Kind of fun. Can you guess which parts I did of these three-part doodles?
