Tell some random guy you met Al Pacino and they'll be like woah.
Tell some random guy you met Sanford Meisner and they'll be like who?
Tell Al Pacino you met Sanford Meisner and he'll be like woah.
Sanford Meisner is an acting teacher, famous to actors and nameless to anyone else.
Martin Fowler is famous to programmers and nameless to anyone else.
David Carson is famous to graphic designers and nameless to anyone else.
Cory Kennedy is famous to Lindsay Lohan, and nameless to anyone else.
Fame might be shrinking.
But the moral of the story is simple: keep your camera on.
Thursday, May 31, 2007
Getting It / Not Getting It (where It == REST)
Peter Szinek says:
It seems to me that there are two types of people in the world: those who don’t get REST (and they think it’s a basic postulate to rocket science explained through quantum theory) and those who get it, and don’t understand the former group (unless they are coming from there, that is).
But it may be more complicated than that, especially if it turns out there's nothing to get:
It seems to me that there are two types of people in the world: those who don’t get REST (and they think it’s a basic postulate to rocket science explained through quantum theory) and those who get it, and don’t understand the former group (unless they are coming from there, that is).
But it may be more complicated than that, especially if it turns out there's nothing to get:
Wednesday, May 30, 2007
How To Get A Much Better Job
I've gone from being an office temp at 19 to making $75/hr. as a programmer. That's called starting low and finishing high. My rate dipped well below $75 after the dot-com bust, but my next contract's going to be more than that. I'm not from the ghetto, but I can claim to have my own classic American rags to riches stories from time to time.
So please, take it from me. This is how you get a better job: you do a better job.
Whatever it is you're given to do, do it quicker and better than anyone thought possible, and use the extra time to do something else which is obviously useful, threatens no-one, and makes people happy.
It's that simple.
A lot of people think being a good employee is about obeying orders.
It's not. Obedience is what you want to give cops if they catch you speeding. Added value is what you want to give employers. And added value isn't just about doing what they tell you better than somebody else would have done it; it's about doing what they tell you better than anyone else would have done it, and then doing something else that your boss or employer or manager or what have you absolutely would have told you to do if they had even thought of it.
There's a great book on this. I highly recommend it:
Free Prize Inside is about added value, in employees, in businesses, and how defining a good way to add value is key to marketing whatever it is you want to market - yourself, your services, your employer, your favorite programming language, anything. For instance, with Seaside, you might come for the continuations, but you stay for the IDE. With Rails, you come for the scaffolding, but you stay for the metaprogramming. With this blog, you come for the business and technology, but you stay for the lolcats.
I suppose you might come for the Rails and stay for the acting, too - at least recently - so, here's another way to look at it. There's a classic improv game called "Yes, And." All you do is take something somebody says to you, agree with it, and add one additional thing.
That's really all there is to adding value. Example: "I need you to build some database code." "Yes, and I also added some unit tests." They key is first you give them the database code, and then you go, by the way, here are some unit tests, they guarantee that my code works and anybody maintaining this code can check any changes against the unit tests and this means my code will run forever and ever and ever. Hooray. And they go, wow, you rock, and you go, uh huh, I do, and then you throw the horns to prove it. And everybody's happy.
I kind of forgot my point, but that's as good an image to end this post on as any.
So please, take it from me. This is how you get a better job: you do a better job.
Whatever it is you're given to do, do it quicker and better than anyone thought possible, and use the extra time to do something else which is obviously useful, threatens no-one, and makes people happy.
It's that simple.
A lot of people think being a good employee is about obeying orders.
It's not. Obedience is what you want to give cops if they catch you speeding. Added value is what you want to give employers. And added value isn't just about doing what they tell you better than somebody else would have done it; it's about doing what they tell you better than anyone else would have done it, and then doing something else that your boss or employer or manager or what have you absolutely would have told you to do if they had even thought of it.
There's a great book on this. I highly recommend it:
Free Prize Inside is about added value, in employees, in businesses, and how defining a good way to add value is key to marketing whatever it is you want to market - yourself, your services, your employer, your favorite programming language, anything. For instance, with Seaside, you might come for the continuations, but you stay for the IDE. With Rails, you come for the scaffolding, but you stay for the metaprogramming. With this blog, you come for the business and technology, but you stay for the lolcats.
I suppose you might come for the Rails and stay for the acting, too - at least recently - so, here's another way to look at it. There's a classic improv game called "Yes, And." All you do is take something somebody says to you, agree with it, and add one additional thing.
That's really all there is to adding value. Example: "I need you to build some database code." "Yes, and I also added some unit tests." They key is first you give them the database code, and then you go, by the way, here are some unit tests, they guarantee that my code works and anybody maintaining this code can check any changes against the unit tests and this means my code will run forever and ever and ever. Hooray. And they go, wow, you rock, and you go, uh huh, I do, and then you throw the horns to prove it. And everybody's happy.
I kind of forgot my point, but that's as good an image to end this post on as any.
Does Seaside Have A Marketing Problem?
Disagreeing with my earlier post, Kurt Schrader says no, Seaside doesn't have a marketing problem. Seaside has a WTF problem.
Smalltalk is, at least in the case of Squeak, a whole different world. You have to unlearn a lot of what you know in order to use it. Editing is different, class creation is different, version control is different. Basically everything you know as a programmer gets thrown out the window.
You can't edit it with vi or emacs; you don't do source control with svn; everything's weird and new.
Kurt says most people never get past this hump. He says the few who do see the light; they return to other languages certain they've glimpsed a new world, a plane beyond. I agree with him there.
But I have to disagree with Kurt's claim that Seaside doesn't have a marketing problem. I don't think anything he said was wrong. I just want a broader use of the term "marketing."
The entire Ruby on Rails phenomenon constitues a powerful and compelling argument that building low barriers to adoption into a system is a very effective marketing move.
I recently tried to get the Rails core team to switch the for loops in the scaffolding templates to iterators, on the grounds that this would encourage new Rails programmers to use iterators instead of repeating their bad old habits with for loops. I failed completely. Josh Susser said that replacing for loops with iterators would set up a barrier to adoption for new Rails programmers, and that was that. The idea didn't fly for a second.
Low barriers to adoption are an explicit strategy in Rails, and part of the reason for its success. This strategy is a marketing strategy. Realistically, if you're doing trivial tasks in Ruby, the difference between a for loop and an iterator is very slight. There is no technological benefit or loss here; it's purely a question of how people feel about it. A PHP programmer sees a for loop, they feel comfortable; they see an iterator, they're puzzled. A tiny difference, but that's the decision the team made. The scaffolding templates use for loops for purposes of marketing. It's a move designed to expand the user base.
Seaside has a marketing problem, because Smalltalk has a marketing problem. It's a marketing problem built into the technology. This is why Avi Bryant's idea of a GemStone Ruby VM offering persistence for Web apps is a good idea. With Ruby you've basically got people programming in Smalltalk already.
Smalltalk is, at least in the case of Squeak, a whole different world. You have to unlearn a lot of what you know in order to use it. Editing is different, class creation is different, version control is different. Basically everything you know as a programmer gets thrown out the window.
You can't edit it with vi or emacs; you don't do source control with svn; everything's weird and new.
Kurt says most people never get past this hump. He says the few who do see the light; they return to other languages certain they've glimpsed a new world, a plane beyond. I agree with him there.
But I have to disagree with Kurt's claim that Seaside doesn't have a marketing problem. I don't think anything he said was wrong. I just want a broader use of the term "marketing."
The entire Ruby on Rails phenomenon constitues a powerful and compelling argument that building low barriers to adoption into a system is a very effective marketing move.
I recently tried to get the Rails core team to switch the for loops in the scaffolding templates to iterators, on the grounds that this would encourage new Rails programmers to use iterators instead of repeating their bad old habits with for loops. I failed completely. Josh Susser said that replacing for loops with iterators would set up a barrier to adoption for new Rails programmers, and that was that. The idea didn't fly for a second.
Low barriers to adoption are an explicit strategy in Rails, and part of the reason for its success. This strategy is a marketing strategy. Realistically, if you're doing trivial tasks in Ruby, the difference between a for loop and an iterator is very slight. There is no technological benefit or loss here; it's purely a question of how people feel about it. A PHP programmer sees a for loop, they feel comfortable; they see an iterator, they're puzzled. A tiny difference, but that's the decision the team made. The scaffolding templates use for loops for purposes of marketing. It's a move designed to expand the user base.
Seaside has a marketing problem, because Smalltalk has a marketing problem. It's a marketing problem built into the technology. This is why Avi Bryant's idea of a GemStone Ruby VM offering persistence for Web apps is a good idea. With Ruby you've basically got people programming in Smalltalk already.
Tuesday, May 29, 2007
How To Make Everything Look Like Python: Part 2
In part one, Perl and Ruby code allowed you to code Perl and Ruby, respectively, while pretending to code Python; now in part two, the Ruby version gets an extraordinary upgrade. Your new Python disguise would fool Python's own mother! Not only does it turn out to be possible to do source filtering in Ruby without any fancy tricks, it turns out to be easy as well, thanks to a trick a Lisper discovered when working to program Ruby as if it were Lisp.
(All of this is of course totally unnecessary, but fun anyway.)
New Blog: Illicit Technology
A team blog with myself and some others, including two former co-workers from Bitscribe.
Monday, May 28, 2007
Rails AntiPattern: if environment == X
Lots of people will do this:
Don't ever do that. Instead, put it in environments/development.rb (or whichever).
if ENV['RAILS_ENV'] == 'development' # or whatever
# do something
end
Don't ever do that. Instead, put it in environments/development.rb (or whichever).
Seaside's "Marketing Problem"
Shh! Don't Digg this post. This is a secret post.
Build something in Seaside. Something as idiotic and simple as a table in HTML. It's fun.
Rails has hit the point where you can make crazy money. Yay Rails. That's awesome. I'm happy for Rails.
But if you play with Seaside, even just for a few hours, you quickly realize that Seaside is to Rails what Rails is to J2EE.
The logo on the shirts at RailsConf was an exponential growth curve. Because Rails has one. Why doesn't Seaside have that kind of adoption curve?
Because Rails runs on Unix servers, and Seaside runs on Squeak VMs. Rails runs on Subversion, and Seaside runs on Monticello. Seaside runs on a dialect of Smalltalk that the industry has already reached an opinion about, and Rails runs on a dialect of Smalltalk which looks more like a cross between Perl and Python.
From one perspective, Seaside has a marketing problem. If your goal is to find a job writing Seaside, then Seaside definitely has a marketing problem. But if your goal is to find a secret weapon, Seaside doesn't have a marketing problem - Rails has a marketing problem. There's nothing secret about that weapon.
I loved Ayn Rand books when I was a teenager; these days I'm embarassed to admit I even read them at all. But there's a scene in Atlas Shrugged where the heroine walks into a diner and finds the greatest composer on the face of the planet working there, flipping burgers. Sometimes Seaside feels like that. How dumb must the tech industry be, overlooking something like this? Is it run by monkeys? What the hell is going on?
Build something in Seaside. Something as idiotic and simple as a table in HTML. It's fun.
Rails has hit the point where you can make crazy money. Yay Rails. That's awesome. I'm happy for Rails.
But if you play with Seaside, even just for a few hours, you quickly realize that Seaside is to Rails what Rails is to J2EE.
The logo on the shirts at RailsConf was an exponential growth curve. Because Rails has one. Why doesn't Seaside have that kind of adoption curve?
Because Rails runs on Unix servers, and Seaside runs on Squeak VMs. Rails runs on Subversion, and Seaside runs on Monticello. Seaside runs on a dialect of Smalltalk that the industry has already reached an opinion about, and Rails runs on a dialect of Smalltalk which looks more like a cross between Perl and Python.
From one perspective, Seaside has a marketing problem. If your goal is to find a job writing Seaside, then Seaside definitely has a marketing problem. But if your goal is to find a secret weapon, Seaside doesn't have a marketing problem - Rails has a marketing problem. There's nothing secret about that weapon.
I loved Ayn Rand books when I was a teenager; these days I'm embarassed to admit I even read them at all. But there's a scene in Atlas Shrugged where the heroine walks into a diner and finds the greatest composer on the face of the planet working there, flipping burgers. Sometimes Seaside feels like that. How dumb must the tech industry be, overlooking something like this? Is it run by monkeys? What the hell is going on?
Sunday, May 27, 2007
Programmer Interviews: Two Warning Signs
I just need to get this off my chest. There are a lot of interviewers who will ask you trivial syntax questions, like, what does ^ mean in Ruby? Some good blog posts have made it common knowledge among better companies that these are basically stupid questions that tell you nothing about what a programmer can actually do, and don't represent vital knowledge anyway, since the answers can be found immediately on Google.
Unfortunately, a lot of companies know that these questions are trivial questions, and they know they're supposed to abandon the practice, but they don't know what they're supposed to do instead, so they just ratchet it up a notch. Instead of asking you questions which are trivial because any idiot could answer them by going on Google, they ask you questions which are trivial because any idiot could answer them by pulling Knuth off the shelf. Questions like, "what is a tree sort? What is it good for?" You can give them credit for having higher standards, because they make the hypothetical idiot go to a more sophisticated source, but they're still asking questions which any idiot could answer with access to the right reference materials. But the ability to locate reference materials isn't an important criterion in hiring programmers; it's an important criterion in hiring librarians.
Algorithm questions are becoming the huge warning sign, to me, that syntax questions were in the past. If you take a job with a company that asks you questions any idiot could answer, sooner or later they're going to put you on a project with some idiot who answered them. It's something to watch out for.
The best way to hire programmers is to read their blogs and look at their code. If you don't read their blogs and look at their code before the interview, you've gotten it backwards. The phone screen should come after the Google screen.
Even though I sometimes post embarassing things on my blog, I'm always happier in an interview when I find out the person I'm talking to has read my blog beforehand. I never talk to anybody without researching their company first, and if you googled the company but they didn't google you, that means that the first thing you find out about a prospective employer is that they're less diligent than you are. That's something to watch out for too.
Unfortunately, a lot of companies know that these questions are trivial questions, and they know they're supposed to abandon the practice, but they don't know what they're supposed to do instead, so they just ratchet it up a notch. Instead of asking you questions which are trivial because any idiot could answer them by going on Google, they ask you questions which are trivial because any idiot could answer them by pulling Knuth off the shelf. Questions like, "what is a tree sort? What is it good for?" You can give them credit for having higher standards, because they make the hypothetical idiot go to a more sophisticated source, but they're still asking questions which any idiot could answer with access to the right reference materials. But the ability to locate reference materials isn't an important criterion in hiring programmers; it's an important criterion in hiring librarians.
Algorithm questions are becoming the huge warning sign, to me, that syntax questions were in the past. If you take a job with a company that asks you questions any idiot could answer, sooner or later they're going to put you on a project with some idiot who answered them. It's something to watch out for.
The best way to hire programmers is to read their blogs and look at their code. If you don't read their blogs and look at their code before the interview, you've gotten it backwards. The phone screen should come after the Google screen.
Even though I sometimes post embarassing things on my blog, I'm always happier in an interview when I find out the person I'm talking to has read my blog beforehand. I never talk to anybody without researching their company first, and if you googled the company but they didn't google you, that means that the first thing you find out about a prospective employer is that they're less diligent than you are. That's something to watch out for too.
Friday, May 25, 2007
Auto-Generate REST Boilerplate Code With make_resourceful
One of the big ironies of Rails is that it went from criticizing J2EE for its "XML situps" to creating reams of ugly boilerplate code for its REST implementation.
2005:
2006:
Turns out there's an awesome solution. I skipped this presentation at RailsConf, due to general hype fatigue - I needed a rest from REST - but it turns out I missed something awesome. Check the slides PDF for a way to get all the benefits of REST without any of the ugly repetition.
2005:
2006:
Turns out there's an awesome solution. I skipped this presentation at RailsConf, due to general hype fatigue - I needed a rest from REST - but it turns out I missed something awesome. Check the slides PDF for a way to get all the benefits of REST without any of the ugly repetition.
Sexism Still A Problem In Tech
From the comments:
given all the discussion on diversity and the issues we've had with sexism and cyber stalking this year, I really don't see how this is funny at all.
If the web community takes a stand against this sort of behaviour, which it clearly did in Kathy Sierra's case, it should be obvious that it's not an accepted form of humour. And hello, it's 2007, not 1977...
Of course there's a pretty compelling argument that Kathy Sierra's stalkers weren't sexually motivated - but instead, just very unpleasant people who need to learn to stop using sex as a weapon - and the really bad news is that those people won. Creating Passionate Users is gone.
Thursday, May 24, 2007
^ Means XOR In Ruby
Saw something I didn't recognize in the Rails source:
unless types.any? ^ block
Turns out it's an exclusive or operator.
unless types.any? ^ block
Turns out it's an exclusive or operator.
{giles-computer:giles} [05-24 21:59] ~
! irb
>> true ^ false
=> true
>> true ^ true
=> false
>> false ^ false
=> false
>> exit
{giles-computer:giles} [05-24 22:00] ~
!
SQL Unnecessary In Haskell's HAppS
Evan Weaver has this idea: SQL is a kludge. It's a weird idea, that SQL isn't necessary in Web apps and doesn't belong in Web apps, but Dave Thomas and Avi Bryant both hinted at it in their RailsConf keynotes, David Heinemeier Hansson basically used it as the base assumption for ActiveRecord, and, according to my roommate Justin, Paul Graham used it as a base assumption as well in the original Lisp version of ViaWeb, his startup which became Yahoo! Stores.
So, I think this idea's a good idea. So I've been telling it to people. Many people who hear this idea look at me like I'm crazy, but the few people I know of who share the idea are all famous and brilliant, except for Evan Weaver, who is merely brilliant.
Just today I found out another place this idea gets taken seriously: HAppS - the Haskell Web app framework (and server), which will hereafter in this blog be referred to as Happs, because come on, you'd have to be deliberately intent on wrecking a good idea with bad marketing if you were seriously considering using the official capitalization. Anyway, Happs does away with the database completely. Not only that, it does away with the Web server as well. The Happs philosophy says a server should be built in.
Happs Web apps compile to binaries, which store serialized state in memory and on the filesystem. State is written to the filesystem first and stored in memory second. This, of course, enables failover. You'd think all that I/O might mess with performance, but the Happs response is interesting:
I am not saying that using HAppS, you could serve all of eBay on a single box. I am saying that your application is likely to be well within the constraints required
The reason they're not saying you could serve eBay from a single box using Happs is because some of the examples on the page indicate that maybe you almost could.
This is all new, I haven't verified it yet, and I've never met a developer who didn't overestimate their code in some respect - it's like meeting a new mother who doesn't think her baby is beautiful - but it looks very, very interesting. If you're into the idea that SQL is a kludge, check out Happs.
So, I think this idea's a good idea. So I've been telling it to people. Many people who hear this idea look at me like I'm crazy, but the few people I know of who share the idea are all famous and brilliant, except for Evan Weaver, who is merely brilliant.
Just today I found out another place this idea gets taken seriously: HAppS - the Haskell Web app framework (and server), which will hereafter in this blog be referred to as Happs, because come on, you'd have to be deliberately intent on wrecking a good idea with bad marketing if you were seriously considering using the official capitalization. Anyway, Happs does away with the database completely. Not only that, it does away with the Web server as well. The Happs philosophy says a server should be built in.
Happs Web apps compile to binaries, which store serialized state in memory and on the filesystem. State is written to the filesystem first and stored in memory second. This, of course, enables failover. You'd think all that I/O might mess with performance, but the Happs response is interesting:
I am not saying that using HAppS, you could serve all of eBay on a single box. I am saying that your application is likely to be well within the constraints required
The reason they're not saying you could serve eBay from a single box using Happs is because some of the examples on the page indicate that maybe you almost could.
This is all new, I haven't verified it yet, and I've never met a developer who didn't overestimate their code in some respect - it's like meeting a new mother who doesn't think her baby is beautiful - but it looks very, very interesting. If you're into the idea that SQL is a kludge, check out Happs.
3 Time Management Tips For Bloggers
I've had blogging get in the way of working, my social life, even sleep. Here are a few things I've learned.
1. Batch your blog reading.
You need to read relevant blogs to make your own blog relevant, but the last thing you want to do is check your RSS reader every five minutes. I used to check my RSS feeds once a day, but my new schedule is once a week. Why is this? First, the longer you wait before putting your two cents in on the controversy of the day, the more likely your post will be interesting, put forth a unique perspective, and approach truly controversial subjects with fairness and calm. Second, staying up to date with blogs is much less important than filtering good content from bad. Good content makes your readers more effective at what they do; bad content is just noise.
2. E-mail before you blog.
I've got a post coming up on a neat Ruby library. I had a whole in-depth conversation about the library with the person who wrote it, and after a while realized it was more than enough for a good post. I've also written posts where the best content came from people who corrected me in the comments, and who I could have gone to for the correct answers in the first place. If you know enough to write an interesting post about something, you also know enough to identify some friends or acquaintances online who know more about it than you do. Check with them for a little tech editing and you'll save them the aggravation of correcting you later on.
A lot of people are scared to look stupid. Don't be. I'll be bragging about my advanced Rails skills and looking stuff up in the Ruby standard library on the same day. Acknowledging your own ignorance means that when you do claim expertise, people know they can trust you. And acknowledging the expertise of others makes them happy.
3. Throw away pointless words.
If you get halfway through a post and realize the idea is tiny, don't blather on filling up empty space. Just make your point and move on.
1. Batch your blog reading.
You need to read relevant blogs to make your own blog relevant, but the last thing you want to do is check your RSS reader every five minutes. I used to check my RSS feeds once a day, but my new schedule is once a week. Why is this? First, the longer you wait before putting your two cents in on the controversy of the day, the more likely your post will be interesting, put forth a unique perspective, and approach truly controversial subjects with fairness and calm. Second, staying up to date with blogs is much less important than filtering good content from bad. Good content makes your readers more effective at what they do; bad content is just noise.
2. E-mail before you blog.
I've got a post coming up on a neat Ruby library. I had a whole in-depth conversation about the library with the person who wrote it, and after a while realized it was more than enough for a good post. I've also written posts where the best content came from people who corrected me in the comments, and who I could have gone to for the correct answers in the first place. If you know enough to write an interesting post about something, you also know enough to identify some friends or acquaintances online who know more about it than you do. Check with them for a little tech editing and you'll save them the aggravation of correcting you later on.
A lot of people are scared to look stupid. Don't be. I'll be bragging about my advanced Rails skills and looking stuff up in the Ruby standard library on the same day. Acknowledging your own ignorance means that when you do claim expertise, people know they can trust you. And acknowledging the expertise of others makes them happy.
3. Throw away pointless words.
If you get halfway through a post and realize the idea is tiny, don't blather on filling up empty space. Just make your point and move on.
Wednesday, May 23, 2007
Tuesday, May 22, 2007
The Four Hour Rails Work Week
Got an interesting e-mail today. Hans Friedrich, like me, develops Web apps in Rails, and he watched the awesome Google Video I linked to recently where Tim Ferriss and Marci Alboher talk about their respective books (both of which are excellent).
Hans is a hard-working Rails developer, putting in long hours and making good money. Although I don't do the big-money/long-hours thing, I've done it in the past. Hans pointed out that the four-hour work week and the hard-working programmer can be very different things, from very different worlds - I'd add that this is especially true in Silicon Valley - and he asked me to connect the dots. Here's a partial quote from my reply:
Those dots are some great dots to connect but I'm still figuring out the answer myself. I think one great way to do it is PeepCode, which Geoffery Grosenbach told me is now his full-time thing. Selling information products for $9 a pop is a great model in terms of scalability and automation. It does require that Geoff keep learning as much as he can about Rails, but if you enjoy learning about Rails, that's just another plus.
Of course, if you're working for a startup, Tim Ferriss' ideas are pretty hard to implement; but if you're running your own consultancy or working for a larger corporation, the book gives you some pretty great options and strategies.
Definitely expect to see more in the future about The Four Hour Work Week and my experiences putting its ideas into practice. Although many of the ideas are new to me, and putting them into practice may take some trial and error, I've been doing the frequent mini-retirements thing since I was 18 or 19, and I absolutely swear by that. A crucial part of enjoying life.
Hans is a hard-working Rails developer, putting in long hours and making good money. Although I don't do the big-money/long-hours thing, I've done it in the past. Hans pointed out that the four-hour work week and the hard-working programmer can be very different things, from very different worlds - I'd add that this is especially true in Silicon Valley - and he asked me to connect the dots. Here's a partial quote from my reply:
Those dots are some great dots to connect but I'm still figuring out the answer myself. I think one great way to do it is PeepCode, which Geoffery Grosenbach told me is now his full-time thing. Selling information products for $9 a pop is a great model in terms of scalability and automation. It does require that Geoff keep learning as much as he can about Rails, but if you enjoy learning about Rails, that's just another plus.
Of course, if you're working for a startup, Tim Ferriss' ideas are pretty hard to implement; but if you're running your own consultancy or working for a larger corporation, the book gives you some pretty great options and strategies.
Definitely expect to see more in the future about The Four Hour Work Week and my experiences putting its ideas into practice. Although many of the ideas are new to me, and putting them into practice may take some trial and error, I've been doing the frequent mini-retirements thing since I was 18 or 19, and I absolutely swear by that. A crucial part of enjoying life.
Geek Marketing: The Key To Making Money As A Programmer
Absurdly good blogger Raganwald points to a Reddit comment on a Bruce Schneier post everyone should read which finally explains a big mystery: everybody "knows" that a good programmer is worth 10 to 1000 times what an average programmer is worth, yet the only way for a programmer to get paid 10 to 1000 times more than average is to start their own business.
Here's the long-story-short of the Schneier article, which explains the economics of the used car market:
[An economist] illustrated his ideas with a used car market. A used car market includes both good cars and lousy ones (lemons). The seller knows which is which, but the buyer can't tell the difference - at least until he's made his purchase. I'll spare you the math, but what ends up happening is that the buyer bases his purchase price on the value of a used car of average quality.
This means that the best cars don't get sold; their prices are too high. Which means that the owners of these best cars don't put their cars on the market. And then this starts spiraling. The removal of the good cars from the market reduces the average price buyers are willing to pay, and then the very good cars no longer sell, and disappear from the market. And then the good cars, and so on until only the lemons are left.
And Reddit user steveblgh says:
This is a great essay, and I just realized that it applies to the IT job market. Here the seller (the applicant) has all the info about himself, while the employer knows nothing. So what happens is that companies expect the average, and pay accordingly. That's why people who are smarter than average shouldn't go on job interviews, because they'll likely to get below what they are worth.
In terms of the economics, steve is dead-on. But I disagree with the normative component - the should - because the cure for this is obvious: blogging and open source. The problem is an information problem. You won't get a price below your value if you've got a reputation. If Jamis Buck goes to a job interview, he'll probably be looking at a good offer. But if a programmer whose code is just as good as Jamis's - or even better - goes into a job interview without any reputation to establish his skill, then yes, that programmer gets priced at the average level, which is to say, below their value.
As I've said before, geeks need marketing.
Unfortunately, you should take my advice with a grain of salt, or in fact a freakishly gigantic saline boulder, because I go on job interviews all the time. I can't stand doing the same thing over and over again - I've lived in seven different places in the last three years - so I never stay at the same company for very long, and I'm happiest when learning something entirely new. In the past the best solution for this has seemed to be working from home in my own consulting business, but constantly looking for the next client takes up a lot of time, so I frequently take short-term contracts, and many short-term contracts I go on result in long-term offers I turn down. (Conversely, every time I take on a long-term job, I end up leaving.)
Anyway, my point here is that I'm kind of unusual. I value variety over security, kind of the same way I value a Lamborghini over a golf kart. Adventure wins over safety every time in my book. I've even walked through gang neighborhoods in gang colors just to see what would happen. I got in a car accident that had me sliding downhill backwards at 80mph, pointed directly at five lanes of oncoming traffic, and I remember it as the most fun I've had in years. Please understand that my methods are not for everybody.
The more common value hierarchy puts security above excitement, and it's pretty obvious to me what I would do if I had more conventional values. The path to success as a programmer is very clear: in addition to studying programming and excelling at it, study marketing and excel at that too. Make sure people know your code, or your ideas, or ideally both. And stay off the job market; only ever even consider job offers if they come from friends.
The reality is, there are great programmers who are underrated, and there are good programmers who are overrated. It's not the code that makes you the money; when it comes time for salary negotiations, it's the rating that matters, whether over-, under-, or accurate. I'm pretty sure no programmer worth the grain of salt with which they take my words would like to hear that, but it's true. Consider: nine times out of ten, a programmer's implementing strategic decisions made above his or her head by some management type who doesn't know a thing about code. Popularity is the only metric by which an uninformed businessperson can evaluate competing technologies, which explains a lot of the bad technology decisons that businesspeople make.
(Although we shouldn't let them off the hook for not finding better metrics.)
As for me, I'll keep going on job interviews, keep blogging like crazy, keep studying acting, keep writing screenplays, keep releasing white label DJ records, and maybe, if I get lucky, I'll start a side business in motion design and release a few Rails plugins. (Don't quote me on that, though.)
Here's the long-story-short of the Schneier article, which explains the economics of the used car market:
[An economist] illustrated his ideas with a used car market. A used car market includes both good cars and lousy ones (lemons). The seller knows which is which, but the buyer can't tell the difference - at least until he's made his purchase. I'll spare you the math, but what ends up happening is that the buyer bases his purchase price on the value of a used car of average quality.
This means that the best cars don't get sold; their prices are too high. Which means that the owners of these best cars don't put their cars on the market. And then this starts spiraling. The removal of the good cars from the market reduces the average price buyers are willing to pay, and then the very good cars no longer sell, and disappear from the market. And then the good cars, and so on until only the lemons are left.
And Reddit user steveblgh says:
This is a great essay, and I just realized that it applies to the IT job market. Here the seller (the applicant) has all the info about himself, while the employer knows nothing. So what happens is that companies expect the average, and pay accordingly. That's why people who are smarter than average shouldn't go on job interviews, because they'll likely to get below what they are worth.
In terms of the economics, steve is dead-on. But I disagree with the normative component - the should - because the cure for this is obvious: blogging and open source. The problem is an information problem. You won't get a price below your value if you've got a reputation. If Jamis Buck goes to a job interview, he'll probably be looking at a good offer. But if a programmer whose code is just as good as Jamis's - or even better - goes into a job interview without any reputation to establish his skill, then yes, that programmer gets priced at the average level, which is to say, below their value.
As I've said before, geeks need marketing.
Unfortunately, you should take my advice with a grain of salt, or in fact a freakishly gigantic saline boulder, because I go on job interviews all the time. I can't stand doing the same thing over and over again - I've lived in seven different places in the last three years - so I never stay at the same company for very long, and I'm happiest when learning something entirely new. In the past the best solution for this has seemed to be working from home in my own consulting business, but constantly looking for the next client takes up a lot of time, so I frequently take short-term contracts, and many short-term contracts I go on result in long-term offers I turn down. (Conversely, every time I take on a long-term job, I end up leaving.)
Anyway, my point here is that I'm kind of unusual. I value variety over security, kind of the same way I value a Lamborghini over a golf kart. Adventure wins over safety every time in my book. I've even walked through gang neighborhoods in gang colors just to see what would happen. I got in a car accident that had me sliding downhill backwards at 80mph, pointed directly at five lanes of oncoming traffic, and I remember it as the most fun I've had in years. Please understand that my methods are not for everybody.
The more common value hierarchy puts security above excitement, and it's pretty obvious to me what I would do if I had more conventional values. The path to success as a programmer is very clear: in addition to studying programming and excelling at it, study marketing and excel at that too. Make sure people know your code, or your ideas, or ideally both. And stay off the job market; only ever even consider job offers if they come from friends.
The reality is, there are great programmers who are underrated, and there are good programmers who are overrated. It's not the code that makes you the money; when it comes time for salary negotiations, it's the rating that matters, whether over-, under-, or accurate. I'm pretty sure no programmer worth the grain of salt with which they take my words would like to hear that, but it's true. Consider: nine times out of ten, a programmer's implementing strategic decisions made above his or her head by some management type who doesn't know a thing about code. Popularity is the only metric by which an uninformed businessperson can evaluate competing technologies, which explains a lot of the bad technology decisons that businesspeople make.
(Although we shouldn't let them off the hook for not finding better metrics.)
As for me, I'll keep going on job interviews, keep blogging like crazy, keep studying acting, keep writing screenplays, keep releasing white label DJ records, and maybe, if I get lucky, I'll start a side business in motion design and release a few Rails plugins. (Don't quote me on that, though.)
Evan Weaver's RailsConf Presentation
In the aftermath of RailsConf, one of the most interesting ideas came from Evan Weaver - later echoed by Dave Thomas.
The idea is that SQL itself is a kludge. I read somewhere that DHH said at RailsConf in 2006 that he uses databases as hashes. Evan Weaver went one step further and said that there are very few Web apps where you don't need a hash instead of a database. His suggestion was that SQL itself is a design mistake.
People use relational databases to provide persistence in Web apps, but they don't do it because databases exist for that purpose. It's a little like using a necktie as a belt when you're late for lunch. The Web came along, and everybody suddenly needed persistent data yesterday. SQL databases existed, so everybody tied them around their waists and ran off to lunch.
Avi Bryant's keynote presented just one alternative to the necktie belt - the object database, handled by a virtual machine. This is a powerful, successful option used in performance-intensive financial applications.
The future of Web apps will probably bring us more options. There will be a lot of apps using SQL for a long time to come, just because "that's how everybody's always done it", but the case for GemStone-style Web app VMs is a strong one. One of the major unifying points among Seaside, Rails, and the entire armada of new Web frameworks released in the past two or three years is that they all minimize the amount of raw SQL you write. Already, the fact that you can write raw SQL is becoming a differentiator for Web developers.
The idea is that SQL itself is a kludge. I read somewhere that DHH said at RailsConf in 2006 that he uses databases as hashes. Evan Weaver went one step further and said that there are very few Web apps where you don't need a hash instead of a database. His suggestion was that SQL itself is a design mistake.
People use relational databases to provide persistence in Web apps, but they don't do it because databases exist for that purpose. It's a little like using a necktie as a belt when you're late for lunch. The Web came along, and everybody suddenly needed persistent data yesterday. SQL databases existed, so everybody tied them around their waists and ran off to lunch.
Avi Bryant's keynote presented just one alternative to the necktie belt - the object database, handled by a virtual machine. This is a powerful, successful option used in performance-intensive financial applications.
The future of Web apps will probably bring us more options. There will be a lot of apps using SQL for a long time to come, just because "that's how everybody's always done it", but the case for GemStone-style Web app VMs is a strong one. One of the major unifying points among Seaside, Rails, and the entire armada of new Web frameworks released in the past two or three years is that they all minimize the amount of raw SQL you write. Already, the fact that you can write raw SQL is becoming a differentiator for Web developers.
Monday, May 21, 2007
Link Roundup: Information And Paranoia
A Brainfuck Compiler For Linux
Avi Bryant's RailsConf Keynote: Ruby Can Become Very Fast, And The Tools To Support It Can Become Incredibly Powerful
Got two comments about this, one of frustration at missing the keynote, one requesting more detail, so, here we go.
Avi basically said:
I'm from the future, I know how this story ends. All the people who are saying you can't implement Ruby on a fast virtual machine are wrong. That machine already exists today, it's called Gemstone, and it could certainly be adapted to Ruby. It runs Smalltalk, and Ruby essentially is Smalltalk. So adapting it to run Ruby is absolutely within the realm of the possible.
He also pointed out that the Strongtalk Smalltalk VM had incredible performance, although Evan Weaver later told me that the Strongtalk VM was never actually finished. The Strongtalk site confirms this, although I get the feeling that they did get most of the heavy lifting out of the way.
Anyway - going back to the summary - Avi was also saying that since Ruby is so similar to Smalltalk, and Smalltalk has unparalleled GUI and IDE support, it's pretty easy to see a future where all these tool vendors and IDE creators really come up with something incredible by simply going back to Smalltalk and mining it for all its lost riches. There was a real Raiders of the Lost Ark vibe to Avi's talk, or a Tomb Raider (the game) vibe, because he knew where to find this stuff, and he knew it could be repurposed, so it really is there, and all we have to do is go and get it. There's very fast VM technology out there which is totally capable of handling Ruby's dynamic features, because it can handle Smalltalk's dynamic features, which are exactly the same features, and it's absolutely possible to build a fully graphical environment for such a language, because that's what Smalltalk is.
He specifically highlighted comments from Tim Bray, who had said that building a competitive VM for Ruby could never really happen, because of specific dynamic features of Ruby. He also got a comment from somebody in the audience who had worked on a Smalltalk VM, and who said that enabling that dynamicity was a hard thing to do. The person was wearing a Powerset T-shirt, so I think it was Josh Susser, but I don't know for sure. It's actually a really interesting question, but there are so many implementations of Smalltalk that I think Avi's point had to have had some strength to it. Now that I think about it, though, I really wish I'd found Josh and asked him about that. I also had been hoping to meet Avi, but couldn't find him after the presentation.
It was a pretty exciting talk; I just wish there had been people from Gemstone there to hear it. There were a lot of cameras and mixing boards at RailsConf, so I think there's a very reasonable chance that the keynotes will become podcasts, including video. Very worth the download if that happens.
Avi basically said:
I'm from the future, I know how this story ends. All the people who are saying you can't implement Ruby on a fast virtual machine are wrong. That machine already exists today, it's called Gemstone, and it could certainly be adapted to Ruby. It runs Smalltalk, and Ruby essentially is Smalltalk. So adapting it to run Ruby is absolutely within the realm of the possible.
He also pointed out that the Strongtalk Smalltalk VM had incredible performance, although Evan Weaver later told me that the Strongtalk VM was never actually finished. The Strongtalk site confirms this, although I get the feeling that they did get most of the heavy lifting out of the way.
Anyway - going back to the summary - Avi was also saying that since Ruby is so similar to Smalltalk, and Smalltalk has unparalleled GUI and IDE support, it's pretty easy to see a future where all these tool vendors and IDE creators really come up with something incredible by simply going back to Smalltalk and mining it for all its lost riches. There was a real Raiders of the Lost Ark vibe to Avi's talk, or a Tomb Raider (the game) vibe, because he knew where to find this stuff, and he knew it could be repurposed, so it really is there, and all we have to do is go and get it. There's very fast VM technology out there which is totally capable of handling Ruby's dynamic features, because it can handle Smalltalk's dynamic features, which are exactly the same features, and it's absolutely possible to build a fully graphical environment for such a language, because that's what Smalltalk is.
He specifically highlighted comments from Tim Bray, who had said that building a competitive VM for Ruby could never really happen, because of specific dynamic features of Ruby. He also got a comment from somebody in the audience who had worked on a Smalltalk VM, and who said that enabling that dynamicity was a hard thing to do. The person was wearing a Powerset T-shirt, so I think it was Josh Susser, but I don't know for sure. It's actually a really interesting question, but there are so many implementations of Smalltalk that I think Avi's point had to have had some strength to it. Now that I think about it, though, I really wish I'd found Josh and asked him about that. I also had been hoping to meet Avi, but couldn't find him after the presentation.
It was a pretty exciting talk; I just wish there had been people from Gemstone there to hear it. There were a lot of cameras and mixing boards at RailsConf, so I think there's a very reasonable chance that the keynotes will become podcasts, including video. Very worth the download if that happens.
How To Make Everything Look Like Python
On the ruby-talk list, someone posted recently that they wanted to use Python indentation in Ruby. It's probably a bit unhealthy to like Python that much.
But the question is an interesting one, so:
Here's Ruby code which allows you to write Ruby as if it were Python. You save your Python/Ruby in a .pyrb file and load it through pyruby.rb, which will then turn it into usable Ruby.
Here's a Perl library which allows you to do the same thing in Perl - but without the .pypl step. Perl has a feature called source filtering, which allows you to alter Perl's syntax from within Perl. Perl's army of wizards have already churned out a ton of filter libraries, which means that the Perl library which allows you to write Perl as if it were Python only takes about 200 lines of code.
The Perl community's starting to look more and more like the Lisp community every day. The combination of incredible power, reclusive wizards, and antisocial Slashdotters gives it the vibe of a lava-filled wasteland dotted with towers where strange men with white beards obsess over unspeakable knowledge. I spoke to someone once who compared programming in Lisp to studying Kabbalah, in that it does strange things to your head. Parts of Perl are like that. Still, source filtering's kind of cool. Unnecessary, but cool.
Update! Ruby version massively improved.
But the question is an interesting one, so:
Here's Ruby code which allows you to write Ruby as if it were Python. You save your Python/Ruby in a .pyrb file and load it through pyruby.rb, which will then turn it into usable Ruby.
Here's a Perl library which allows you to do the same thing in Perl - but without the .pypl step. Perl has a feature called source filtering, which allows you to alter Perl's syntax from within Perl. Perl's army of wizards have already churned out a ton of filter libraries, which means that the Perl library which allows you to write Perl as if it were Python only takes about 200 lines of code.
The Perl community's starting to look more and more like the Lisp community every day. The combination of incredible power, reclusive wizards, and antisocial Slashdotters gives it the vibe of a lava-filled wasteland dotted with towers where strange men with white beards obsess over unspeakable knowledge. I spoke to someone once who compared programming in Lisp to studying Kabbalah, in that it does strange things to your head. Parts of Perl are like that. Still, source filtering's kind of cool. Unnecessary, but cool.
Update! Ruby version massively improved.
Sunday, May 20, 2007
Dude WTF - Rubychicks.com?
Dave Thomas kicks off his RailsConf keynote mocking rubychicks.com, and righteously so. Odd because I had just been thinking Piers Cawley was overreacting, but if anything the problem's bigger and more continuous than I'd thought.
RailsConf Brain Dump
Here are my notes from three conference sessions. Warning - minimal formatting and editing, and any code indentation undoubtedly fux0r3d by Blogger.
GLENN VANDERBURG
def sort_header(field, label=field.titleize)
content_tag(:th, :class => 'sort_header') do
link_to label, :sort => field
end
end
it is actually possible to do Seaside-style coded html rather than messy embedded templates; just build them in the helpers. could you do a components thing from there?
render partial from helper - easy enough
taking html_options (the hash) is pretty easy - just set it as an optional arg in the helper method's def.
inconsistency in built-in helper methods unfortunate - no kidding
generating javascript
filter_select method - is how NOT to do it
explicit tag attribute event handlers avoid
best approach - send it to another function which registers the change request - that way you can have multiple causes and multiple effects and still end up with whatever sequence of causes and effects you want.
rails recipes, recipe #2
learn internals of Rails helpers
use JS objects; put functions there; hack misusing objects as if they were namespaces, but hey.
learn prototype in depth
form builders - instances of TaggedBuilder
what is TaggedBuilder?
enables you to encapsulate patterns/styles of forms in your app
Slides are going to be online
. Be intolerant of messy code in views
. When you put logic in views, build helpers
. Anything more than simple conditionals
. When you see duplication in views, build helpers
. Best way to learn is to do
. Keep languages separate, even in your helpers
. Prefer generating HTML in other helpers, rather than inline
(lots of little classes)
. JS goes in app.js or other helpers
. Pick one existing convention for option transfer and stick to it
. Move them to app_helper if useful many places
. Move them to a plugin if frequently useful
. PEEK BEHIND THE CURTAIN
Read and analyze the helper-building helpers
capture, concat,
observe_field, content_tag, text_field_tag,
link_to_if
...
EZRA ZYGMUNTOWICZ
Mongrel's really an HTTP Server **Library**
Stackable Handlers - like Evan Weaver's Mongrel.Configurator() thing
Use mongrel_cluster for multiple process (Mutex lock)
Lightspeed and Apache proxies
Pen/Pound/etc. proxies
...
DAN WEBB
Peasant's language
Event.onReady / Event.observe - from low pro, but merging into Prototype
Capture standard event responses to functions to make event handlers shorter?
No!
write Prototype to programmatically apply functions (event handlers) to the HTML. much shorter, much faster; downside is potential for browser issues i.e. page loading before JavaScript prepared
Event delegation in case of too many handlers for browser to handle
Use regular script-based handling and attachment first
Inline handling (a onclick="xyz") as method of last resort
Event Bubbling
handler goes in body?
bdoy tag catches all events, events go to event dispatcher or handler
allows you to handle complex situations - would have been good for CYP
Event Bubble-catcher obtains event source (target) from Event.observe
Event B-C can decide based on event source class (in CSS sense)
dan webb winner for best slides, easy, even over DHH
href="#" bad for inline event handlers
why?
use href to pass ARGS to the inline event handler instead
3 official methods
(and 2 unofficial?)
appendChild, insertBefore, replaceChild
one unofficial from IE: innerHTML
from IE?!
used in update() in Prototype
DOM elements surgical but bulky
overburdened, XML-y
**Low Pro's DOM builder - programmatic HTML generation**
DOM = Ninja, innerHTML = Sumo
5th method - the Bastard Son - DOM and innerHTML
use DOM methods to generate HTML and innerHTML to insert
or, more rarely, the other way round
Lightning Script Style
don't use :defaults - 5 HTTP requests, ~134KB
the less JS, the better
Moo FX - smaller can be better
Browser normally only load 2 resources simultaneously (**from the same server**(I think))
JS compression inferior to GZIP
Packer implements zip algorithm in JS
madness
browser auto-decompresses gzip (?)
Faster loops - each() slow - put initialization in the for
that was weird, two vars in the var part, avoid .length
indiscriminate $$() slow on IE
Start with working HTML = get it working normally first - standard
Pro JavaScript Techniques (Dan Web tech editor) - Bulletproof Ajax
DHTML Utopia Modern Web Design (sitepoint?)
GLENN VANDERBURG
def sort_header(field, label=field.titleize)
content_tag(:th, :class => 'sort_header') do
link_to label, :sort => field
end
end
it is actually possible to do Seaside-style coded html rather than messy embedded templates; just build them in the helpers. could you do a components thing from there?
render partial from helper - easy enough
taking html_options (the hash) is pretty easy - just set it as an optional arg in the helper method's def.
inconsistency in built-in helper methods unfortunate - no kidding
generating javascript
filter_select method - is how NOT to do it
explicit tag attribute event handlers avoid
best approach - send it to another function which registers the change request - that way you can have multiple causes and multiple effects and still end up with whatever sequence of causes and effects you want.
rails recipes, recipe #2
learn internals of Rails helpers
use JS objects; put functions there; hack misusing objects as if they were namespaces, but hey.
learn prototype in depth
form builders - instances of TaggedBuilder
what is TaggedBuilder?
enables you to encapsulate patterns/styles of forms in your app
Slides are going to be online
. Be intolerant of messy code in views
. When you put logic in views, build helpers
. Anything more than simple conditionals
. When you see duplication in views, build helpers
. Best way to learn is to do
. Keep languages separate, even in your helpers
. Prefer generating HTML in other helpers, rather than inline
(lots of little classes)
. JS goes in app.js or other helpers
. Pick one existing convention for option transfer and stick to it
. Move them to app_helper if useful many places
. Move them to a plugin if frequently useful
. PEEK BEHIND THE CURTAIN
Read and analyze the helper-building helpers
capture, concat,
observe_field, content_tag, text_field_tag,
link_to_if
...
EZRA ZYGMUNTOWICZ
Mongrel's really an HTTP Server **Library**
Stackable Handlers - like Evan Weaver's Mongrel.Configurator() thing
Use mongrel_cluster for multiple process (Mutex lock)
Lightspeed and Apache proxies
Pen/Pound/etc. proxies
...
DAN WEBB
Peasant's language
Event.onReady / Event.observe - from low pro, but merging into Prototype
Capture standard event responses to functions to make event handlers shorter?
No!
write Prototype to programmatically apply functions (event handlers) to the HTML. much shorter, much faster; downside is potential for browser issues i.e. page loading before JavaScript prepared
Event delegation in case of too many handlers for browser to handle
Use regular script-based handling and attachment first
Inline handling (a onclick="xyz") as method of last resort
Event Bubbling
handler goes in body?
bdoy tag catches all events, events go to event dispatcher or handler
allows you to handle complex situations - would have been good for CYP
Event Bubble-catcher obtains event source (target) from Event.observe
Event B-C can decide based on event source class (in CSS sense)
dan webb winner for best slides, easy, even over DHH
href="#" bad for inline event handlers
why?
use href to pass ARGS to the inline event handler instead
3 official methods
(and 2 unofficial?)
appendChild, insertBefore, replaceChild
one unofficial from IE: innerHTML
from IE?!
used in update() in Prototype
DOM elements surgical but bulky
overburdened, XML-y
**Low Pro's DOM builder - programmatic HTML generation**
DOM = Ninja, innerHTML = Sumo
5th method - the Bastard Son - DOM and innerHTML
use DOM methods to generate HTML and innerHTML to insert
or, more rarely, the other way round
Lightning Script Style
don't use :defaults - 5 HTTP requests, ~134KB
the less JS, the better
Moo FX - smaller can be better
Browser normally only load 2 resources simultaneously (**from the same server**(I think))
JS compression inferior to GZIP
Packer implements zip algorithm in JS
madness
browser auto-decompresses gzip (?)
Faster loops - each() slow - put initialization in the for
that was weird, two vars in the var part, avoid .length
indiscriminate $$() slow on IE
Start with working HTML = get it working normally first - standard
Pro JavaScript Techniques (Dan Web tech editor) - Bulletproof Ajax
DHTML Utopia Modern Web Design (sitepoint?)
RailsConf Downtime Rambling
RailsConf is winding down, and I'm basically set to skedaddle after Dave Thomas' keynote. There was a nice blend of sessions for beginners and for non-beginners as well, and for all the scorn you see on the Web about Java and PHP from the Rails community, there was a much more inclusive vibe on that front than you might expect.
I'm going to write up a little bit about Evan Weaver's presentation soon, possibly some others including Ze Frank's keynote, but for now, there are a couple pretty interesting things going on in blog-land. First there's the discovery of diamonds which indicate the possiblity that a comet crashed into the earth around 12,000 years ago. This is actually very interesting because there's a scientist with specialized knowledge of erosion who insists the erosion on the Sphinx is rainforest erosion, not desert erosion, and this is basically ignored by Egyptologists, since the area the Sphinx is in hasn't been a desert since about 12,000 years ago.
I found this on Bruce Sterling's awesome blog, which also refers to the widely-reported story that Russia may have declared cyberwar on Estonia, in that a period of saber-rattling has been followed by what appears to be a nation-wide DDoS attack on all Estonian servers. Sterling's blog points out something very important, which is that the Russian government has not claimed any responsibility for the attack, which makes it very possible that the attack isn't governmental at all, but rather an instance of political agitation.
Finally, graphic designer David Airey wrote a post about inspiration, which is part of a larger meme. A big realization for me at RailsConf is that Rails is much larger than it's been in the past, and I'm less inspired by Rails itself than I've been in the past; and yet specific parts of it are more inspiring than before. Specifically, the open source and design-centric nature of Rails have both scaled remarkably well. My notes from the conference are filled with ideas, to-do lists, and contributions I want to make to the Rails community. DHH's keynote, a presentation on plugins, and Chad Fowler's search for inspiration are all standouts in the general flow of stuff in this conference which is inspiring me to look beyond just blogging about Rails and making a living from it, to actually doing something useful for my fellow Rails developers.
On the more general subject of inspiration, I want to reiterate something I've noticed time and time again, which is that I hear and read "you should only do this if you're passionate about it" said about programming and acting constantly. I heard that same thing - only do it you're passionate about it - said about graphic design, too, back when I worked in design, and when a friend of mine tried to get me into the idea of working in video games a few years ago, I ran into it there as well. I'd like to go one step further and say that this seems to be a general trend across a fairly wide spectrum of activities. There's no point in an artist who only does art to pay the bills - nothing could be crazier - and there's only slightly more sanity in a graphic designer with the same attitude. In general, I'd say that unless you live in the Third World, or some of the harsher parts of the US that are starting to look like the Third World - if you're fortunate enough to have options about what you do in the first place - then you can almost assume as a given that "only do it you're passionate about it" applies to every possible career. It seems to be true across such a wide range of careers that you might as well assume it's true for every career.
Right now I'm in a RailsConf session on Deploying On Windows. I think the topic is silly, I just came in to feed my laptop some juice. Credit where credit is due, it's sessions like this which create an inclusive vibe; we should encourage every approach to development, really, because although opinionated software is a wonderful thing, judgemental communites are terrible. But for my part, I've always considered Windows inherently harmful to programming skill, for the simple reason that it's hard to be passionate about that. I might be wrong. I don't know. To each his own.
Finally, in a surprising piece of news, Clay Shirky, for possibly the first time ever, has written something you shouldn't read forty times, memorize, and burn into your brain. In fact, he's written something which makes me wonder who kidnapped him and where he currently is. If anybody knows who has kidnapped Clay Shirky and what we have to do to get him back, please contact me immediately. I'll bring my homeslice Hiro Nakamura and my sex-crazed groupie Claire Bennet, and we'll rescue that motherfucker real proper-like.
Update: by the way, if you're wondering what's up with the deranged oversize type, hey, so am I. Blogger's one of the most consistently surprising pieces of consumer freeware I've ever used. Also, I have to admit, Claire Bennet isn't my sex-crazed groupie. My sex-crazed groupie is Claire Bennett. Two Ts. Sorry for the confusion.
Also, the general fatigued tone of this post is due to the collision of consultant hours with conference hours. I also seem to be kind of mean when tired, sorry about that. Finally, the two most exciting parts of the conference for me were when I asked Avi Bryant a couple questions during his keynote and when I tried to get up during the open mike demo sessions to talk about Code Generation In Action, my new favorite Ruby book. I missed the whole signup process, so I didn't get to talk that time, but obviously I'm looking forward to OSCON, where I do get to speak. I'm doing 45 minutes on Seaside and Rails, and RailsConf made my job much easier there by bringing in Avi Bryant to give a keynote. Avi Bryant made my job easier too with the content of his keynote - which was quite remarkable. (I don't know if many people were persuaded, but I sure as hell was.)
I'm going to write up a little bit about Evan Weaver's presentation soon, possibly some others including Ze Frank's keynote, but for now, there are a couple pretty interesting things going on in blog-land. First there's the discovery of diamonds which indicate the possiblity that a comet crashed into the earth around 12,000 years ago. This is actually very interesting because there's a scientist with specialized knowledge of erosion who insists the erosion on the Sphinx is rainforest erosion, not desert erosion, and this is basically ignored by Egyptologists, since the area the Sphinx is in hasn't been a desert since about 12,000 years ago.
I found this on Bruce Sterling's awesome blog, which also refers to the widely-reported story that Russia may have declared cyberwar on Estonia, in that a period of saber-rattling has been followed by what appears to be a nation-wide DDoS attack on all Estonian servers. Sterling's blog points out something very important, which is that the Russian government has not claimed any responsibility for the attack, which makes it very possible that the attack isn't governmental at all, but rather an instance of political agitation.
Finally, graphic designer David Airey wrote a post about inspiration, which is part of a larger meme. A big realization for me at RailsConf is that Rails is much larger than it's been in the past, and I'm less inspired by Rails itself than I've been in the past; and yet specific parts of it are more inspiring than before. Specifically, the open source and design-centric nature of Rails have both scaled remarkably well. My notes from the conference are filled with ideas, to-do lists, and contributions I want to make to the Rails community. DHH's keynote, a presentation on plugins, and Chad Fowler's search for inspiration are all standouts in the general flow of stuff in this conference which is inspiring me to look beyond just blogging about Rails and making a living from it, to actually doing something useful for my fellow Rails developers.
On the more general subject of inspiration, I want to reiterate something I've noticed time and time again, which is that I hear and read "you should only do this if you're passionate about it" said about programming and acting constantly. I heard that same thing - only do it you're passionate about it - said about graphic design, too, back when I worked in design, and when a friend of mine tried to get me into the idea of working in video games a few years ago, I ran into it there as well. I'd like to go one step further and say that this seems to be a general trend across a fairly wide spectrum of activities. There's no point in an artist who only does art to pay the bills - nothing could be crazier - and there's only slightly more sanity in a graphic designer with the same attitude. In general, I'd say that unless you live in the Third World, or some of the harsher parts of the US that are starting to look like the Third World - if you're fortunate enough to have options about what you do in the first place - then you can almost assume as a given that "only do it you're passionate about it" applies to every possible career. It seems to be true across such a wide range of careers that you might as well assume it's true for every career.
Right now I'm in a RailsConf session on Deploying On Windows. I think the topic is silly, I just came in to feed my laptop some juice. Credit where credit is due, it's sessions like this which create an inclusive vibe; we should encourage every approach to development, really, because although opinionated software is a wonderful thing, judgemental communites are terrible. But for my part, I've always considered Windows inherently harmful to programming skill, for the simple reason that it's hard to be passionate about that. I might be wrong. I don't know. To each his own.
Finally, in a surprising piece of news, Clay Shirky, for possibly the first time ever, has written something you shouldn't read forty times, memorize, and burn into your brain. In fact, he's written something which makes me wonder who kidnapped him and where he currently is. If anybody knows who has kidnapped Clay Shirky and what we have to do to get him back, please contact me immediately. I'll bring my homeslice Hiro Nakamura and my sex-crazed groupie Claire Bennet, and we'll rescue that motherfucker real proper-like.
Update: by the way, if you're wondering what's up with the deranged oversize type, hey, so am I. Blogger's one of the most consistently surprising pieces of consumer freeware I've ever used. Also, I have to admit, Claire Bennet isn't my sex-crazed groupie. My sex-crazed groupie is Claire Bennett. Two Ts. Sorry for the confusion.
Also, the general fatigued tone of this post is due to the collision of consultant hours with conference hours. I also seem to be kind of mean when tired, sorry about that. Finally, the two most exciting parts of the conference for me were when I asked Avi Bryant a couple questions during his keynote and when I tried to get up during the open mike demo sessions to talk about Code Generation In Action, my new favorite Ruby book. I missed the whole signup process, so I didn't get to talk that time, but obviously I'm looking forward to OSCON, where I do get to speak. I'm doing 45 minutes on Seaside and Rails, and RailsConf made my job much easier there by bringing in Avi Bryant to give a keynote. Avi Bryant made my job easier too with the content of his keynote - which was quite remarkable. (I don't know if many people were persuaded, but I sure as hell was.)
Saturday, May 19, 2007
Component HTML Generation In Rails?
Friday, May 18, 2007
Why The ruby-talk List Is Awesome
%f{This is sooo cooooold} << "!"
TypeError: can't modify frozen string
TypeError: can't modify frozen string
106 Days To Burning Man
Boing Boing highlights this vehicle:
Took one look and knew where that thing was born.
106 days and counting...
Took one look and knew where that thing was born.
106 days and counting...
Quotes and Notes from DHH's RailsConf 2007 Keynote
"Rails 2 Is Not Going To Be A Unicorn"
"The world of resources is a better, greener place for web development."
Single action which handles three different formats. Not a unicorn because it works today. "All of this stuff will pretty much just work."
./script/generate scaffold person name:string created_at:datetime - That's awesome. You can give the scaffold generator the basic attributes of the model.
format.xml { render :xml => @people } - I'm sold on REST, finally. format.csv is nearly a one-liner also. It automatically assumes the correct return format, so a direct use of Mime::CSV is unnecessary.
Involuntary debugging demo.
"3 years of Ruby on Rails experience." DHH showed a job ad and commented that the headhunters were looking for people who had more Rails experience than he did.
ActiveWebService's death is now finally official. ActiveResource yes, ActiveWebService no. Adios. Rails is not Switzerland; Rails takes sides. SOAP no; REST APIs yes.
Looking for ways to add OpenID and Atom to Rails; these are horses in the race that they want to back but aren't yet doing so. Ajax and Rest are friends; OpenID and Atom are allies.
"Breakpoints are back." Happy about that; jokingly blames "guys in Japan" for fixing the bug breakpoints depended on. ActiveWebService guy's ruby-debugger now gives you breakpointing again. I think that wasn't actually news; I think it's also really called ruby-debug, not ruby-debugger. You can trace it up and down through the call stack in the framework. I think Adam Wiggins' project Gyre already makes use of this to give you a Rails IDE that runs in Rails.
Admits HTTP performance strategy fux0r3d; showed huge list of JS and CSS in use in Highrise. Hopefully this means there's a new directory structure coming to organize JS and CSS properly. all.css and all.js is the solution he's describing.
javascript_include_tag :all, :cache => :true
Not what I was hoping for - seems less flexible than Iowa - but still definitely an improvement.
Solution is a line in a configuration file! specifying a separate asset host.
Huge difference in perceived performance because branching to a separate server eliminates (hardcoded and arbitrary) browser limitations on simultaneous per-server connections.
"It's really hard to figure out how to do object caching well." (Referring to SQL.)
Query cache. Something which scans queries and ? Ah OK. It doesn't bother with object caching because it's hard; it caches identical SQL queries only because identifying them is effortless and cheap. So you get it for free; automatically activated by default. You get it for free. Standard Rails design, really, do the easy thing fast and wait to see if the corner case ever even happens in real life. It's a good practical design principle (this is my commentary, not what DHH said).
Best news so far: ERb files are going to end in .erb. Finally!
I think I knew about that already, though. I'm not sure if I did or not. That's weird.
config/initializers - another Thank God. (I think this was announced on Ryan's "What's New In Rails Edge" around March.)
"Sexy Migrations" - actual slide text. This was announced somewhere recently as well.
Honestly, I hate to sound cynical, but most of the content in this keynote is old news if you read Ryan Daigle's blog. In fact all this "finally" and "thank God" I'm writing, that's where it comes from. I keep thinking he's saying new stuff that's finally happening, he's really just giving an update on what he's been doing in Rails core, which is a pretty reasonable thing to do during a keynote, especially if you've been keeping busy, but yeah, it is mostly old news. Took me a while to realize it, though, the coffee I had this morning was pretty bad. The best in the vicinity that I know of so far is Starbucks. That's a serious fucking problem. I should have brought my espresso machine.
"The MIT Assumption" - slide title. Here's something actually interesting - DHH loves the MIT license. MIT license is autogenerated by default if you build plugins or whatever. There's something funny about that, but it's a very useful thing. DHH's business sense is a huge part of what makes Rails great. Boring keynote compared to Canada On Rails, though. That was a fucking awesome keynote. To be fair, though, if I was reading as many blogs back then as I am today, I might have been less surprised by that one too. It was definitely very popular, and there's definitely a lot of good energy here.
"The world of resources is a better, greener place for web development."
Single action which handles three different formats. Not a unicorn because it works today. "All of this stuff will pretty much just work."
./script/generate scaffold person name:string created_at:datetime - That's awesome. You can give the scaffold generator the basic attributes of the model.
format.xml { render :xml => @people } - I'm sold on REST, finally. format.csv is nearly a one-liner also. It automatically assumes the correct return format, so a direct use of Mime::CSV is unnecessary.
Involuntary debugging demo.
"3 years of Ruby on Rails experience." DHH showed a job ad and commented that the headhunters were looking for people who had more Rails experience than he did.
ActiveWebService's death is now finally official. ActiveResource yes, ActiveWebService no. Adios. Rails is not Switzerland; Rails takes sides. SOAP no; REST APIs yes.
Looking for ways to add OpenID and Atom to Rails; these are horses in the race that they want to back but aren't yet doing so. Ajax and Rest are friends; OpenID and Atom are allies.
"Breakpoints are back." Happy about that; jokingly blames "guys in Japan" for fixing the bug breakpoints depended on. ActiveWebService guy's ruby-debugger now gives you breakpointing again. I think that wasn't actually news; I think it's also really called ruby-debug, not ruby-debugger. You can trace it up and down through the call stack in the framework. I think Adam Wiggins' project Gyre already makes use of this to give you a Rails IDE that runs in Rails.
Admits HTTP performance strategy fux0r3d; showed huge list of JS and CSS in use in Highrise. Hopefully this means there's a new directory structure coming to organize JS and CSS properly. all.css and all.js is the solution he's describing.
javascript_include_tag :all, :cache => :true
Not what I was hoping for - seems less flexible than Iowa - but still definitely an improvement.
Solution is a line in a configuration file! specifying a separate asset host.
Huge difference in perceived performance because branching to a separate server eliminates (hardcoded and arbitrary) browser limitations on simultaneous per-server connections.
"It's really hard to figure out how to do object caching well." (Referring to SQL.)
Query cache. Something which scans queries and ? Ah OK. It doesn't bother with object caching because it's hard; it caches identical SQL queries only because identifying them is effortless and cheap. So you get it for free; automatically activated by default. You get it for free. Standard Rails design, really, do the easy thing fast and wait to see if the corner case ever even happens in real life. It's a good practical design principle (this is my commentary, not what DHH said).
Best news so far: ERb files are going to end in .erb. Finally!
I think I knew about that already, though. I'm not sure if I did or not. That's weird.
config/initializers - another Thank God. (I think this was announced on Ryan's "What's New In Rails Edge" around March.)
"Sexy Migrations" - actual slide text. This was announced somewhere recently as well.
Honestly, I hate to sound cynical, but most of the content in this keynote is old news if you read Ryan Daigle's blog. In fact all this "finally" and "thank God" I'm writing, that's where it comes from. I keep thinking he's saying new stuff that's finally happening, he's really just giving an update on what he's been doing in Rails core, which is a pretty reasonable thing to do during a keynote, especially if you've been keeping busy, but yeah, it is mostly old news. Took me a while to realize it, though, the coffee I had this morning was pretty bad. The best in the vicinity that I know of so far is Starbucks. That's a serious fucking problem. I should have brought my espresso machine.
"The MIT Assumption" - slide title. Here's something actually interesting - DHH loves the MIT license. MIT license is autogenerated by default if you build plugins or whatever. There's something funny about that, but it's a very useful thing. DHH's business sense is a huge part of what makes Rails great. Boring keynote compared to Canada On Rails, though. That was a fucking awesome keynote. To be fair, though, if I was reading as many blogs back then as I am today, I might have been less surprised by that one too. It was definitely very popular, and there's definitely a lot of good energy here.
Panoramic View of Empty RailsConf
Update: 1600 people, according to Chad Fowler's pre-keynote intro.
Breakfast, pre-conference. People are milling around, also, gathering upstairs outside the doors for DHH's keynote. (But I just filmed downstairs.)
Conference schwag includes very tasteful t-shirt and ridiculous globecube from NetBeans (wtf?). Also a teaser flyer from something ThoughtWorks has created called RubyWorks. I admit, I'm intrigued. I threw away most of my schwag but kept the Apollo preview disc, even though I think Apollo is such a gay-ass name they might as well call it Shapely Male Buttocks Web Framework. Hopefully Adobe will have me eating my words in a few hours. Let's find out. Also threw away a job ad flyer. Haven't seen something like that since the dot-com days. Wowza.
Breakfast, pre-conference. People are milling around, also, gathering upstairs outside the doors for DHH's keynote. (But I just filmed downstairs.)
Conference schwag includes very tasteful t-shirt and ridiculous globecube from NetBeans (wtf?). Also a teaser flyer from something ThoughtWorks has created called RubyWorks. I admit, I'm intrigued. I threw away most of my schwag but kept the Apollo preview disc, even though I think Apollo is such a gay-ass name they might as well call it Shapely Male Buttocks Web Framework. Hopefully Adobe will have me eating my words in a few hours. Let's find out. Also threw away a job ad flyer. Haven't seen something like that since the dot-com days. Wowza.
Share In The RailsConf Excitement!
Actually this is a video where I make jokes about the hotel shampoo.
Thursday, May 17, 2007
RailsConf: Got In To Portland
Lovely city with more trees than you can shake a stick at. I miss the LA freeways! DHH gives his keynote tomorrow morning all early-style.
I missed the first RailsConf but went to Canada On Rails, which was actually a couple months before the first RailsConf. Way back in the day - April 2006. I can barely remember it. Life was so different then.
Canada On Rails had about 100 people there, maybe 200 tops. I have a feeling I'm going to see a lot more than 200 people tomorrow morning.
I missed the first RailsConf but went to Canada On Rails, which was actually a couple months before the first RailsConf. Way back in the day - April 2006. I can barely remember it. Life was so different then.
Canada On Rails had about 100 people there, maybe 200 tops. I have a feeling I'm going to see a lot more than 200 people tomorrow morning.
Wednesday, May 16, 2007
Great Article On Excluding Bad Vibes From Online Communities
My own blog got overrun with negativity in the comments recently for no apparent reason. Anyone who's been a part of online communities has seen this kind of thing happen. Cory Doctorow has a great article about it.
Vista Smalltalk?
Either why the lucky stiff is smoking glue, or Microsoft is doing something...
cool?
Weird!
Vista is just part of a much larger architectural change in how Microsoft applications will be written and deployed. The Smalltalk language is ideally suited for the enhanced application connectivity that these new architectures will allow. Vista Smalltalk runs in Internet Explorer 7 as well as on the Windows Vista desktop and is designed to be fully compatible with the .Net framework including future (WPF/E) cross-platform implementations.
cool?
Weird!
Vista is just part of a much larger architectural change in how Microsoft applications will be written and deployed. The Smalltalk language is ideally suited for the enhanced application connectivity that these new architectures will allow. Vista Smalltalk runs in Internet Explorer 7 as well as on the Windows Vista desktop and is designed to be fully compatible with the .Net framework including future (WPF/E) cross-platform implementations.
Shouldn't Conference Schedules Match Programmer Schedules?
I'm stoked for RailsConf but shuddering in terror at the schedule. It starts at 8am and ends at 9:30pm! Wouldn't a conference schedule based on the way programmers actually live start at 2:30pm with a nice continental breakfast and serve dinner at 6am at a local Denny's? It's the one big thing I just don't get about conferences. The only time I have to make my schedule conform to banker's hours is when I attend large gatherings of programmers.
I've never seen a conference schedule which didn't include morning hours. Even the Winter Music Conference has sessions at 9am.
Anyway, rant aside, I'm extremely stoked for this, I think it's going to be lots of fun. Here's a picture of me with a dildo on my head.
I won't be wearing the dildo, but I might be wearing the expression. Say hi.
I've never seen a conference schedule which didn't include morning hours. Even the Winter Music Conference has sessions at 9am.
Anyway, rant aside, I'm extremely stoked for this, I think it's going to be lots of fun. Here's a picture of me with a dildo on my head.
I won't be wearing the dildo, but I might be wearing the expression. Say hi.
Tuesday, May 15, 2007
Code Generation In Action Is AWESOME
Blogged about this book being on the way from Amazon; now it's here.
I just started it and I'm on page 7, but it's very exciting. I'm absolutely going to recommend this book to anybody who wants to use Rails on enterprise-level projects. The criticism that Rails is simplistic for that problem space is easily adressed and overcome with the methods between page 0 and page 7. I'm not even kidding.
(Actually, it's not explicitly addressed - the book predates Rails, and may have significantly influenced its design - but if you see how he addresses enterprise-scale code bulk problems with code generation in a J2EE context, it's pretty easy to map that general strategy to Rails. He uses it to get around J2EE's ORM issues, the bulk and inconvenience of J2EE, and of course that's already handled in Rails with ActiveRecord - but you could just as easily use it to write a program in Ruby to write a Rails app for you. In fact his template-generation techniques are pretty similar to scaffolding, but there's no reason any Rails developer couldn't write their own scaffolding generator, and customize it for a particularly large, complex application, or for Ajax scaffolding rather than plain old vanilla scaffolding.)
Anybody who cares about Rails at all should get this book immediately.
I've always been a fan of code generation, having written Perl & Unix shell scripts to auto-generate Perl & Unix shell scripts since way back in the day, but this is some really awesome shit. It never occurred to me that it should be an architectural strategy.
I wish I had time to back all this enthusiasm up with a substantive review, but I'm going to be lucky if I even get the whole thing read before RailsConf. Long story short, though, anybody who admires Lisp's macros needs to realize that Lisp doesn't have a monopoly on code which writes code. You can write code which writes code in any language which runs on Unix, and if you're not doing that, you're doing things by hand which should be handled programmatically - like, for instance, BUILDING APPLICATIONS.
Seriously, this is a good book. It makes you wonder why in the hell you have to write has_and_belongs_to_many in Rails models and explicitly specify a habtm-style join table in the migrations when the proper approach is obviously to write a script to auto-generate all that boilerplate for you. It's ironic that so many people who love Rails never take the time to emulate its design in their coding practices. If you're building a gigantor-mungus enterprise app in Rails, you should only ever type the words has_and_belongs_to_many once - when you're writing the program that will thereafter do that typing for you. That may sound facile to the average Rails developer, but the average Rails developer works within a relatively small problem space. What about when you're on an enterprise project with 158 different tables? Do you really want to type has_one or belongs_to over 150 times? Do you really want to type out all those :foreign_key parameters by hand? Of course you don't.
This is a COOL book.
I just started it and I'm on page 7, but it's very exciting. I'm absolutely going to recommend this book to anybody who wants to use Rails on enterprise-level projects. The criticism that Rails is simplistic for that problem space is easily adressed and overcome with the methods between page 0 and page 7. I'm not even kidding.
(Actually, it's not explicitly addressed - the book predates Rails, and may have significantly influenced its design - but if you see how he addresses enterprise-scale code bulk problems with code generation in a J2EE context, it's pretty easy to map that general strategy to Rails. He uses it to get around J2EE's ORM issues, the bulk and inconvenience of J2EE, and of course that's already handled in Rails with ActiveRecord - but you could just as easily use it to write a program in Ruby to write a Rails app for you. In fact his template-generation techniques are pretty similar to scaffolding, but there's no reason any Rails developer couldn't write their own scaffolding generator, and customize it for a particularly large, complex application, or for Ajax scaffolding rather than plain old vanilla scaffolding.)
Anybody who cares about Rails at all should get this book immediately.
I've always been a fan of code generation, having written Perl & Unix shell scripts to auto-generate Perl & Unix shell scripts since way back in the day, but this is some really awesome shit. It never occurred to me that it should be an architectural strategy.
I wish I had time to back all this enthusiasm up with a substantive review, but I'm going to be lucky if I even get the whole thing read before RailsConf. Long story short, though, anybody who admires Lisp's macros needs to realize that Lisp doesn't have a monopoly on code which writes code. You can write code which writes code in any language which runs on Unix, and if you're not doing that, you're doing things by hand which should be handled programmatically - like, for instance, BUILDING APPLICATIONS.
Seriously, this is a good book. It makes you wonder why in the hell you have to write has_and_belongs_to_many in Rails models and explicitly specify a habtm-style join table in the migrations when the proper approach is obviously to write a script to auto-generate all that boilerplate for you. It's ironic that so many people who love Rails never take the time to emulate its design in their coding practices. If you're building a gigantor-mungus enterprise app in Rails, you should only ever type the words has_and_belongs_to_many once - when you're writing the program that will thereafter do that typing for you. That may sound facile to the average Rails developer, but the average Rails developer works within a relatively small problem space. What about when you're on an enterprise project with 158 different tables? Do you really want to type has_one or belongs_to over 150 times? Do you really want to type out all those :foreign_key parameters by hand? Of course you don't.
This is a COOL book.
Turning Off E-Mail: Surprisingly Easy
I have to go to SXSW one of these years. The podcasts from 2006 still influence me today, and I'm amazed by the best podcast from 2007 (to my knowledge so far).
It comes from Tim Ferriss - tango champion, kickboxing champion, and author of The Four Hour Workweek, a book I'm eagerly anticipating from Amazon any day now. One of the podcast's most counterintuitive pieces of advice is incredibly easy to implement: only check e-mail twice a day.
Tim suggests setting up an autoresponder with a message along the lines of "I have a new time management system where I only check e-mail twice a day; call me if you need to get in touch immediately." I'm on a ton of different mailing lists, too many to even count, so initiating this exact strategy would have been profoundly antisocial of me, since it would have created reams of spam for all sorts of people. But it was easy enough to just move the message into my signature, and that's what I've done.
To some extent, it hasn't really worked, but the big obstacle isn't people pressuring me to e-mail them right away. I live a pretty mellow life to begin with. The real obstacle is weaning myself off e-mail (and blogs). Thankfully, I stood firm against Twitter, and I don't have a TV, but I'm hooked on all the other forms of information crack, and enforcing my own new time management policy has easily been the hardest part of the whole thing.
Remember, kids, crack kills.
However, after initiating this a couple days ago, maybe even a week ago, I'm starting to feel the effects, and I have to say, it's totally worth it. It feels kind of like when I was 19, and I realized I was watching a lot of TV, so I made myself quit cold turkey. The world got bigger. Not just because I had more time; because I had more concentration. Time without concentration is like scraps of paper easily blown away by the wind. Time with concentration has weight and heft. It's just a feeling, but it's a good feeling.
It comes from Tim Ferriss - tango champion, kickboxing champion, and author of The Four Hour Workweek, a book I'm eagerly anticipating from Amazon any day now. One of the podcast's most counterintuitive pieces of advice is incredibly easy to implement: only check e-mail twice a day.
Tim suggests setting up an autoresponder with a message along the lines of "I have a new time management system where I only check e-mail twice a day; call me if you need to get in touch immediately." I'm on a ton of different mailing lists, too many to even count, so initiating this exact strategy would have been profoundly antisocial of me, since it would have created reams of spam for all sorts of people. But it was easy enough to just move the message into my signature, and that's what I've done.
To some extent, it hasn't really worked, but the big obstacle isn't people pressuring me to e-mail them right away. I live a pretty mellow life to begin with. The real obstacle is weaning myself off e-mail (and blogs). Thankfully, I stood firm against Twitter, and I don't have a TV, but I'm hooked on all the other forms of information crack, and enforcing my own new time management policy has easily been the hardest part of the whole thing.
Remember, kids, crack kills.
However, after initiating this a couple days ago, maybe even a week ago, I'm starting to feel the effects, and I have to say, it's totally worth it. It feels kind of like when I was 19, and I realized I was watching a lot of TV, so I made myself quit cold turkey. The world got bigger. Not just because I had more time; because I had more concentration. Time without concentration is like scraps of paper easily blown away by the wind. Time with concentration has weight and heft. It's just a feeling, but it's a good feeling.
Awesome Book: One Person/Multiple Careers
I'm not Leonardo da Vinci, but I have a lot of interests, and I'm very good at some of them. A lot of programmers who read my blog have e-mailed me to ask how it is I can be a programmer and study acting, or be a programmer and create motion graphics, or be a programmer and create hand-drawn animation, or realistic drawings, or unrealistic drawings, or sci-fi screenplays, etc., etc., etc. How do I keep up on Ruby on Rails and military robotics? The short answer is I like to keep busy. The long answer is another post (which has been in draft mode for about a month).
However, if you want the "long story short" version, if you just want to know how to do this same sort of thing, this kickass book is absolutely the book you want.
I'm drawn to computer programming because it involves solving puzzles and the beautiful abstract understanding of complex things. It's what I spend a lot of my free time reading about. But after a while that work can feel arid, and I get really excited to get back to the theater where I work with people, telling stories, bouncing things around. But rehearsals are all vagueness and uncertainty, with all of these egos. And after a while of that, it becomes compelling to go back to a place where things are clean and simple. With the programming, even though I have collaborators and clients, in the end there's a sense that's just mine. There's something really nice about just solving a problem in my head that doesn't depend on if the paint color works, everyone remembers their lines, and the audiences like it. Basically, if I weren't doing both things, I'd get bored and antsy.
-Dan Milstein, computer programmer/theater director
Literally the first paragraph of the first chapter.
And a few pages in:
"There's a certain culture in programming where managers think they are doing a good job if everyone is working overtime...After being a programmer for ten years I've learned that is sort of a big lie. The most productive team is the one that closes down at five every day and has a clear head in the morning to see their way through problems. It's more like an art form than building a house. If you have a problem with a novel or a play, the solution isn't necessarily to write more pages. Often what you're doing when you're working on a novel or a play is looking for that burst of insight. And you won't get those unless you are fresh and unstressed."
I'm only about 50 pages in, but the book is filled with the stories of fascinating people doing interesting things with their lives, and practical insights from their experience, patterns among them all, which will make it easier and quicker for you to do the same thing, if you choose to.
However, if you want the "long story short" version, if you just want to know how to do this same sort of thing, this kickass book is absolutely the book you want.
I'm drawn to computer programming because it involves solving puzzles and the beautiful abstract understanding of complex things. It's what I spend a lot of my free time reading about. But after a while that work can feel arid, and I get really excited to get back to the theater where I work with people, telling stories, bouncing things around. But rehearsals are all vagueness and uncertainty, with all of these egos. And after a while of that, it becomes compelling to go back to a place where things are clean and simple. With the programming, even though I have collaborators and clients, in the end there's a sense that's just mine. There's something really nice about just solving a problem in my head that doesn't depend on if the paint color works, everyone remembers their lines, and the audiences like it. Basically, if I weren't doing both things, I'd get bored and antsy.
-Dan Milstein, computer programmer/theater director
Literally the first paragraph of the first chapter.
And a few pages in:
"There's a certain culture in programming where managers think they are doing a good job if everyone is working overtime...After being a programmer for ten years I've learned that is sort of a big lie. The most productive team is the one that closes down at five every day and has a clear head in the morning to see their way through problems. It's more like an art form than building a house. If you have a problem with a novel or a play, the solution isn't necessarily to write more pages. Often what you're doing when you're working on a novel or a play is looking for that burst of insight. And you won't get those unless you are fresh and unstressed."
I'm only about 50 pages in, but the book is filled with the stories of fascinating people doing interesting things with their lives, and practical insights from their experience, patterns among them all, which will make it easier and quicker for you to do the same thing, if you choose to.
Monday, May 14, 2007
You Are Not Your Stock Options
A little while back I wrote about Web apps as a form of showbiz:
Programming is looking more and more like acting or screenwriting every day. The entry costs are approaching zero and the value of education is only partial. And certainly the show biz adage that "you're only as good as your latest hit" is true in programming as well. Ask anybody who lost a job to a younger programmer with less brains but trendier skills.
(Available as a podcast here.)
Now Caterina Fake has an awesome podcast where she says that the biggest element in Flickr's success was its timing, and there's statistical research which proves - or at least very strongly suggests - that the same material can hit or miss based on network effects.
What does this mean for Rails programmers?
Rails, of course, is a hit. Rails will be remembered as a huge part of Web 2.0, the preferred language of the second boom; yet it's important to remember that when Rails first appeared on the scene, before it became the colossal bandwagon it now is, it came from one of the only two really successful companies to prosper during the dot-com crash - 37 Signals and Adaptive Path. The huge lesson of both these companies was that it's best to focus on a real business, not on winning a startup lottery, but today, nobody wants to be reminded about that.
Let's assume for the sake of argument that you're downloading the podcast and reading the links - I think they're very worth reading. Ultimately, I just write because I like to write, but I think I'm doing a service by pointing you in these directions. However, I could be doing a disservice instead, if all these links result in a certain amount of depression. One implication is that if Rails had come along at a different time, it wouldn't have been a hit. The idea that such huge differences in the course of your career could be due entirely to luck isn't necessarily uplifting, because luck gets good, and luck gets bad, and that's just how it is. Seems kind of fatalistic, eh?
["They r make fun of me" LOLcat removed per request of upset cat owner]
Well, if Web 2.0 is a lot more like show business than engineering, let's take a moment to look at show business.
There's a neat article in the New York Times about music and social software. Turns out blogs and forums are becoming essential to musicians:
Performing artists these days, particularly new or struggling musicians, are increasingly eager, even desperate, to master the new social rules of Internet fame. They know many young fans aren’t hearing about bands from MTV or magazines anymore; fame can come instead through viral word-of-mouth, when a friend forwards a Web-site address, swaps an MP3, e-mails a link to a fan blog or posts a cellphone concert video on YouTube.
So musicians dive into the fray — posting confessional notes on their blogs, reading their fans’ comments and carefully replying.
By the way, just for perspective, I believe these words are absolutely true. I used to be an underground rave organizer, very minor DJ, and kind of a failed dance music producer, and it's pretty easy to tell if you check out my Myspace page (NSFW!) or download some of my music. Social software's absolutely essential for entertainers. Forums and e-mail lists were the big thing before Myspace, and Myspace is big with musicians and actors. People who I know through the DJ world are obsessed with Myspace, and people I know from acting classes are too. For better or worse, social software has become an essential part of show business.
Anyway, in this article, Jonathan Coulton (of "Code Monkey" fame) reports that a few of his songs are much, much more popular than most, and these are, essentially, his hits. Obviously the sales and popularity threshholds for a Jonathan Coulton hit are orders of magnitude lower than those of a Justin Timberlake hit, but the fact remains, regular songs outnumber hits, and yet fans won by hits sometimes love the regular songs as well, and sometimes become loyal supporters.
It's pretty easy to map this to code, or to Web apps. After all, some of your clients, customers, and employers are going to be your fans, but not necessarily all of them. User base and popularity threshholds for a Giles Bowkett hit have generally been orders of magnitude lower than those of a why the lucky stuff hit, and yet some of my projects have been much, much more popular than others, and people in a company who become my fan because of some project that does unusually well will often want me to work on their other projects too.
Obviously, then, you want to maximize the number of your hits, and yet the statistical research indicates that it is very probably impossible for any one individual to exercise control over what becomes a hit.
Which brings us back to Adaptive Path and 37 Signals. Their strategy for prosperity during the bust: do consistently good work, keep active in the community, and save your money. (Both Jason Fried of 37 Signals and Janice Fraser of Adaptive Path have hammered this point home in podcasts.) Interestingly, it's also Jonathan Coulton's basic strategy for making a living as an independent Web-based musician. It's a strategy designed to leverage the randomness of hits without depending on it.
Compare that strategy with working for a venture capital backed startup.
That's a strategy designed to depend on the randomness of hits.
Another foray back into showbiz. There's a phenomenon here in Los Angeles called pilot season. Pilot season is when all the pilots are filmed; each pilot hopes to become a series on network television. According to one blog I read, agents will send actors out to as many auditions as possible during pilot season, in some cases having one actor go to 12 auditions in the same day. If you don't know anything about auditions, or, for that matter, Los Angeles traffic, let me just summarize: going to 12 auditions in one day is simply insane.
In fact, it's an atypical example, an example of how crazy things get. And agents are not always as unethical as you might think from Hollywood's own portrayals of itself. But agents will send an actor out to an unreasonably large number of auditions because if one actor that an agent represents gets one part in one audition on one pilot and that one pilot happens to become a series, the agent wins big. So if the agent represents 20 different actors, and 19 of them never make any money at all in pilot season, and never book any roles, but one actor wins big, the agent makes more money than if every actor got enough small parts to sustain themselves as working actors.
Does this sound like venture capital?
In a situation like this, both agents and venture capitalists are gamblers. Because hits are incredibly lucrative, yet unpredictable - in the purely technical sense that predicting them is a literal mathematical impossibility due to sensitive dependence on initial conditions - it is better for the gamblers to encourage their actors or their companies to risk everything, even though that risk probably won't pan out, because if just one of those risks does pan out, the money comes back with huge returns that are more than enough to recoup the money that the gambler invested in all the other actors or companies just in case. If every actor or every company plays it safe, they're each individually more likely to stay in business and succeed over the long term - but the gambler won't win any lotteries that way.
The blog post on pilot season says that the smart thing for an actor do at that time is only audition for commercials, movies, stage plays, and ongoing series, and avoid pilots, because all your competition will be out there exhausting themselves gunning for pilots - gambling their careers for their agents instead of making moves which are smart for them.
The implication is that the smart things to do for a programmer during a boom are:
1. Do consistently good work
2. Keep active in the community
3. Save your money
Hopefully that sounds familiar too.
It's a pretty unfortunate political reality that in the world today there are people who are rich enough to treat other people's lives as gambling chips in a gigantor-iffic casino. It's unfortunate for many reasons, but I'm going to limit myself to two here.
First, dramatic income disparity has a statistical correlation with increased mortality among both the poor and the rich. Second, and much more relevant, the people with the money often control, or seem to control, the system. You'd expect the people who control the system to set the system up to perform at its best; but the reality is that the people who control (or seem to control) both systems - both Hollywood and Silicon Valley - have set both systems up for high risk and big winnings. This is why, in music, people like Jonathan Coulton have stepped outside the major-label system, and it's a big reason programmers should consider the VC system with caution, if at all.
My New Policy On Comments
The comments in my blog have been totally out of hand this past week or two. People got very rude to me and to each other.
I got pissed off and just turned off comments completely, but that kind of cripples my blog. The whole point is the dialogue.
Of course the word policy comes from the same root as police, and sadly, my new policy is to police. That is to say, if anything rude comes to my attention in the comments - any kind of rudeness at all - I will delete the comment without explanation. You don't have to agree with me, or with each other, but bad manners of any kind are banned. You can say anything you want, but you have to say it politely.
I got pissed off and just turned off comments completely, but that kind of cripples my blog. The whole point is the dialogue.
Of course the word policy comes from the same root as police, and sadly, my new policy is to police. That is to say, if anything rude comes to my attention in the comments - any kind of rudeness at all - I will delete the comment without explanation. You don't have to agree with me, or with each other, but bad manners of any kind are banned. You can say anything you want, but you have to say it politely.
Sunday, May 13, 2007
acts_as_solr Screencast
Q: Is it kind of ridiculous how anybody who creates a model-relevant Rails plugin names it acts_as_whatever irrespective of whether or not it changes the way the model actually acts?
A: Yes.
Q: Is find_by_solr easily the dumbest example of bad method naming in the Rails world?
A: Almost.
Q: Despite its naming issues, should I seriously consider acts_as_solr as an alternative to acts_as_ferret and Zed Shaw's preference, Hyper Estraier?
A: Very possibly.
The answer really hinges on the engine's performance and stability. I've heard stories of issues with Ferret and seen examples firsthand. Hyper Estraier's got a very strong recommendation behind it but I haven't had any practical experience with it, or spoken personally with anyone who has. I do know that the next time I set up a search engine on a Rails app, I'll try both of these alternatives out before mucking about with Ferret again (sorry Ferret).
The screencast is very good, but it doesn't tell you about Solr's real-world usefulness. The project comes from Apache Lucene, but I prefer to hear real-world war stories (or live through a few) before leaping to any conclusions. For an intro to setup, though, it's great, and more screencasts is a good thing.
Helvetica: The Movie
At one stage in my life typography was the most interesting thing in the world to me. Not so any more; but if you want a little perspective on what typography is, you could do worse than to check out the movie Helvetica. Unfortunately, it's on a very limited tour of the country, and it's already been seen in my neck of the woods, but there are clips online, and they feature some of the best typographers in the world.
Ruby, Rails, Java, and PHP
One thing about Rails which is kind of weird is that it seems to be the place where a lot of Java people and PHP people are meeting each other for the first time.
Even though I came into the Ruby community via Rails, I think I pretty much fit the standard pre-Rails Rubyist profile: eclectic, curious, experienced in multiple languages, etc.
So you've got this sort of initial population of explorers and intellectuals, and then there's this massive influx from two directions at the same time: both from the world of big corporate enterprisey stuff, and from the world of fast and loose page hacking.
It's kind of like an interesting discussion over coffee being suddenly swamped under whole armies of pirates and beauraucrats.
Even though I came into the Ruby community via Rails, I think I pretty much fit the standard pre-Rails Rubyist profile: eclectic, curious, experienced in multiple languages, etc.
So you've got this sort of initial population of explorers and intellectuals, and then there's this massive influx from two directions at the same time: both from the world of big corporate enterprisey stuff, and from the world of fast and loose page hacking.
It's kind of like an interesting discussion over coffee being suddenly swamped under whole armies of pirates and beauraucrats.
Saturday, May 12, 2007
Want To Be A Cyborg?
Go for it.
Scientists have developed plastic blood for use in battlefield transfusions.
Researchers at Sheffield University said their creation could be a huge advantage in war zones.
They say that the artificial blood is light to carry, does not need to be kept cool and can be kept for longer.
The new blood is made up of plastic molecules that have an iron atom at their core, like haemoglobin, that can carry oxygen through the body.
Friday, May 11, 2007
Henry Rollins Net Neutrality Rant
Ran into an old friend online; guy I used to work with at a dot-com. He's now a professional metalhead bass player, and he had this righteous explosion of vitriol on his Myspace:
Not exactly safe for work! ;-)
Not exactly safe for work! ;-)
Rails Developers, Junior and Senior
Toolman Tim broke my heart. In his tumblelog, he posted some code he was very proud of.
I wish I could say this code represented the minimum standard of competency in Rails. Unfortunately that isn't the case. Overriding dynamic finders requires a knowledge of Rails internals and an understanding of Ruby's OOP. That's true. But first, the code isn't as good as Toolman Tim thinks. It has a number of flaws. (Assaf Arkin pointed out these flaws to me.) Second, Tim can justifiably claim to be an above-average Rails developer. But really, understanding Rails internals and Ruby OOP shouldn't be enough to make something above-average work; it should be the bare minimum.
The flaws in Tim's code are a criticism of Tim's code; but the minimums thing is a criticism of the Rails culture.
Rails has a lot of shortcuts. But as Tolkien wrote in the The Fellowship of the Ring, possibly quoting some old folk proverb, short cuts make long delays. Some hackers see building your own framework as a rite of passage; "now I'm really a programmer," you can say. Others never even bother to read Jamis Buck's Under The Hood posts once. I don't know how they do what they do, but I think it involves a lot of cut and paste, and I do know that bad code results from their impatience.
I heard it said that either Jamis or Rick Olson (technoweenie) had said you should never use a plugin you couldn't have written yourself. That's true of Rails as well. The hype and hero worship around Rails gets exasperating sometimes, because Rails is not a complicated piece of code. It's an elegant one. Rails is the Post-It Note.
It's not the electric light bulb. That's the opposite of the Post-It Note. A difficult invention that most people said was impossible. Thomas Edison spent years struggling to make the light bulb happen. It only happened after he had failed hundreds of times, in hundreds of different ways. The Post-It note guy, on the other hand, just put glue on the back of a notecard and bam! He was rich for life.
Let me tell you - that's the way you do it. Money for nothing and your chicks for free.
(Side note: I permanently destroyed my dad's speakers with that song when I was in junior high. That's right, people: I'm taking it back to the old school with this post. Way back. Back to when Rails should have been invented...)
The thing about the Post-It Note is that anybody could have done it. That's why veteran Web developers freak out when they discover Rails. This should have been the standard by 1998. What's really remarkable is that it's such an obvious idea. Nobody ever did it before, but from the moment you discover it, you wonder how you lived without it.
Sometimes a mastery of the elementary is the true sign of genius.
The other thing about the Post-It Note is that it's made of simple parts. So is Rails! Set aside some time to build your own Web framework (like I did, a tiny one for E*Trade in 1998 that was really just a basic CMS) or to thoroughly examine the Rails source (another thing I did which all you young Rails whippersnappers should do too). You'll find building a Web framework involves a lot of work, and that the Rails source is easy to read. That's because the remarkable thing about Rails is not its complexity but its simplicity. The source is really not that complicated, but the task is. If you develop your own Web framework, you'll probably find Rails' elegance much harder to duplicate than its functionality.
Patching dynamic finders in ActiveRecord models is something a Rails programmer can be proud of; yet it really is so easy that it should be considered one of the baseline tests in a Rails job interview. In fact it shouldn't even go in the interview; it should be in the phone screen. Familiarity with Rails' internals should be normal.
Then again, perhaps I'm just underselling my own skills and history. Let me rephrase: these acts of cleverness should be considered bare minima for Rails programmers, and things to aspire to, for PHP-style page hackers. It's understanding the system inside-out that gives you the ability to use it well.
Anyway, let's get back to the code. Here are Assaf's criticisms, copied from an e-mail:
1. lower(email) runs a full table scan as opposed to using the index. That's bad programming in any language.
2. What happens when you call it with:
find_by_email("john@example.com", :conditions=>"true")
3. with_scope is a Rails technique. A Ruby developer, someone who learned the language, not just the framework, would write:
find(:first, { :conditions=>"..." }.merge(options)
Shorter, simpler and a transferrable skill you can use outside of ActiveRecord.
Brief explanations.
1 - When you access the attribute in the DB, you get an index; when you need to modify that attribute with lower(), the DB has to hit every row. That's what the term "full-table scan" means. It's less efficient than hitting the indexes, and in the case of a large data set, so much less efficient it'll kill your performance entirely. It's a very good idea both to understand and to remember how databases work.
2 - The answer to Assaf's question is that conditions gets overwritten instead of added to.
3 - #merge() is a Hash method. It adds new keys to an existing hash based on another existing hash. Unfortunately, it does so destructively. If you have two values defined for the :conditions key in two distinct hashes and you merge them, only one :conditions value will survive the harrowing ordeal. #merge() is Darwinian - it's survival of the fittest in there.
Assaf gave me a great explanation of the problem here:
*opts is a bug, lacking an understanding of how Ruby handles arguments. *opts refers to all other arguments you pass, the vararg equivalent. But when you call:
find_by_email("...", :limit=>5, :order=>"name")
the last two "arguments" (limit and order) are actually keys in a hash that's passed as a single argument. So anything you pass to find_by_email, the original, that falls inside *opts, would be passed to find after the last argument it expects (the hash of options), which should, if implemented correctly, cause find to fail with an error.
If you do {:conditions }.merge(options), then you can override :conditions by passing a new one in options. If you do options.merge(:conditions) then you can't override :conditions, since the last value takes over. But now you can only query by e-mail address, and not, say by combination of e-mail and name ( e.g to ensure a match).
If you want to merge conditions together, that's a bit more tricky, although for the simple case it would be:
(options || {}).merge( :conditions=> (options[:conditions] || {}).merge(:email=>email) )
So the code is actually very troubled. It looks as if it took an entirely wrong turn with its whole strategy. with_scope() shouldn't be used as a workaround for Hash#merge() - with_scope() was created for a specific reason, and it's very useful in the right context. But you should know the standard library well enough that you only ever use with_scope() to do what it's supposed to do.
But if we want to rewrite the code to work, and to be flexible enough to accomodate additional conditions, we end up with an absurd mess.
So how should we fix this code?
The correct way to handle this situation is not by patching a dynamic finder at all. The problem isn't in the retrieval code in the first place. The correct way to handle it is by putting a #downcase() on the e-mail param before that param ever even gets to the database. The indexing problem, the main issue Assaf raised, is so detrimental to performance that putting the fix in the code is an architectural mistake which no amount of code can fix, whether the code is good or bad. That's what Assaf means when he says it's bad programming in any language. That's also why any solution ends up ugly or bug-ridden.
The real problem here is architectural. It's pretty much impossible to solve an architectual mistake with code. The real lesson here is that even the newbie Rails programmer ought to understand architecture, because if you put your code in the wrong place, it won't matter if it's good or bad.
If you've started acquiring data before this ever even occurs to you, don't worry - it's easy to fix. All you do is write a small script which loads up every User, downcases its email attribute, and saves the User. It only takes a few lines of code - possibly even a one-liner - and you can run it from the console. I like to do it by putting DatabaseUpdater objects in /lib and then starting them off from the console with something like DatabaseUpdater.go_go_gadget_database(), but there's a pretty strong argument to be made that the migrations are a more appropriate place for this sort of thing. The cleanest solution in terms of self-documenting code is to create DatabaseUpdater.go_go_gadget_database() in /lib, test it in the console, and then call it from a migration, first on your development DB, and then on your production one.
This approach saves your clients or co-workers so much time that you can get away with the Inspector Gadget reference. In fact, the last time I did something like this, I was cleaning the database, so I named the object ViktorTheCleaner after the character from La Femme Nikita.
By the way, I actually very highly recommend idiosyncratic, story-esque names for things like this. The reason is that they put a face on your code, and that extra dose of personality makes it very easy to remember why things were done a certain way, and when, and by whom. It taps a very powerful part of your brain in a very effective way. Also, because of its superficial frivolity, masking a deeper seriousness, this approach also has the very useful side effect of exposing people within your organization who value professionalism over effectiveness. You need to watch out for those idiots, as they're often self-saboteurs who are dangerous to any project they work on, plus they always listen to bad music and recommend bad restaurants, so it's good to be able to spot them quickly and easily, preferably from a distance.
Anyway, big thanks to Assaf for the analysis, and apologies to Tim for the criticism.
I wish I could say this code represented the minimum standard of competency in Rails. Unfortunately that isn't the case. Overriding dynamic finders requires a knowledge of Rails internals and an understanding of Ruby's OOP. That's true. But first, the code isn't as good as Toolman Tim thinks. It has a number of flaws. (Assaf Arkin pointed out these flaws to me.) Second, Tim can justifiably claim to be an above-average Rails developer. But really, understanding Rails internals and Ruby OOP shouldn't be enough to make something above-average work; it should be the bare minimum.
The flaws in Tim's code are a criticism of Tim's code; but the minimums thing is a criticism of the Rails culture.
Rails has a lot of shortcuts. But as Tolkien wrote in the The Fellowship of the Ring, possibly quoting some old folk proverb, short cuts make long delays. Some hackers see building your own framework as a rite of passage; "now I'm really a programmer," you can say. Others never even bother to read Jamis Buck's Under The Hood posts once. I don't know how they do what they do, but I think it involves a lot of cut and paste, and I do know that bad code results from their impatience.
I heard it said that either Jamis or Rick Olson (technoweenie) had said you should never use a plugin you couldn't have written yourself. That's true of Rails as well. The hype and hero worship around Rails gets exasperating sometimes, because Rails is not a complicated piece of code. It's an elegant one. Rails is the Post-It Note.
It's not the electric light bulb. That's the opposite of the Post-It Note. A difficult invention that most people said was impossible. Thomas Edison spent years struggling to make the light bulb happen. It only happened after he had failed hundreds of times, in hundreds of different ways. The Post-It note guy, on the other hand, just put glue on the back of a notecard and bam! He was rich for life.
Let me tell you - that's the way you do it. Money for nothing and your chicks for free.
(Side note: I permanently destroyed my dad's speakers with that song when I was in junior high. That's right, people: I'm taking it back to the old school with this post. Way back. Back to when Rails should have been invented...)
The thing about the Post-It Note is that anybody could have done it. That's why veteran Web developers freak out when they discover Rails. This should have been the standard by 1998. What's really remarkable is that it's such an obvious idea. Nobody ever did it before, but from the moment you discover it, you wonder how you lived without it.
Sometimes a mastery of the elementary is the true sign of genius.
The other thing about the Post-It Note is that it's made of simple parts. So is Rails! Set aside some time to build your own Web framework (like I did, a tiny one for E*Trade in 1998 that was really just a basic CMS) or to thoroughly examine the Rails source (another thing I did which all you young Rails whippersnappers should do too). You'll find building a Web framework involves a lot of work, and that the Rails source is easy to read. That's because the remarkable thing about Rails is not its complexity but its simplicity. The source is really not that complicated, but the task is. If you develop your own Web framework, you'll probably find Rails' elegance much harder to duplicate than its functionality.
Patching dynamic finders in ActiveRecord models is something a Rails programmer can be proud of; yet it really is so easy that it should be considered one of the baseline tests in a Rails job interview. In fact it shouldn't even go in the interview; it should be in the phone screen. Familiarity with Rails' internals should be normal.
Then again, perhaps I'm just underselling my own skills and history. Let me rephrase: these acts of cleverness should be considered bare minima for Rails programmers, and things to aspire to, for PHP-style page hackers. It's understanding the system inside-out that gives you the ability to use it well.
Anyway, let's get back to the code. Here are Assaf's criticisms, copied from an e-mail:
1. lower(email) runs a full table scan as opposed to using the index. That's bad programming in any language.
2. What happens when you call it with:
find_by_email("john@example.com", :conditions=>"true")
3. with_scope is a Rails technique. A Ruby developer, someone who learned the language, not just the framework, would write:
find(:first, { :conditions=>"..." }.merge(options)
Shorter, simpler and a transferrable skill you can use outside of ActiveRecord.
Brief explanations.
1 - When you access the attribute in the DB, you get an index; when you need to modify that attribute with lower(), the DB has to hit every row. That's what the term "full-table scan" means. It's less efficient than hitting the indexes, and in the case of a large data set, so much less efficient it'll kill your performance entirely. It's a very good idea both to understand and to remember how databases work.
2 - The answer to Assaf's question is that conditions gets overwritten instead of added to.
3 - #merge() is a Hash method. It adds new keys to an existing hash based on another existing hash. Unfortunately, it does so destructively. If you have two values defined for the :conditions key in two distinct hashes and you merge them, only one :conditions value will survive the harrowing ordeal. #merge() is Darwinian - it's survival of the fittest in there.
Assaf gave me a great explanation of the problem here:
*opts is a bug, lacking an understanding of how Ruby handles arguments. *opts refers to all other arguments you pass, the vararg equivalent. But when you call:
find_by_email("...", :limit=>5, :order=>"name")
the last two "arguments" (limit and order) are actually keys in a hash that's passed as a single argument. So anything you pass to find_by_email, the original, that falls inside *opts, would be passed to find after the last argument it expects (the hash of options), which should, if implemented correctly, cause find to fail with an error.
If you do {:conditions }.merge(options), then you can override :conditions by passing a new one in options. If you do options.merge(:conditions) then you can't override :conditions, since the last value takes over. But now you can only query by e-mail address, and not, say by combination of e-mail and name ( e.g to ensure a match).
If you want to merge conditions together, that's a bit more tricky, although for the simple case it would be:
(options || {}).merge( :conditions=> (options[:conditions] || {}).merge(:email=>email) )
So the code is actually very troubled. It looks as if it took an entirely wrong turn with its whole strategy. with_scope() shouldn't be used as a workaround for Hash#merge() - with_scope() was created for a specific reason, and it's very useful in the right context. But you should know the standard library well enough that you only ever use with_scope() to do what it's supposed to do.
But if we want to rewrite the code to work, and to be flexible enough to accomodate additional conditions, we end up with an absurd mess.
So how should we fix this code?
The correct way to handle this situation is not by patching a dynamic finder at all. The problem isn't in the retrieval code in the first place. The correct way to handle it is by putting a #downcase() on the e-mail param before that param ever even gets to the database. The indexing problem, the main issue Assaf raised, is so detrimental to performance that putting the fix in the code is an architectural mistake which no amount of code can fix, whether the code is good or bad. That's what Assaf means when he says it's bad programming in any language. That's also why any solution ends up ugly or bug-ridden.
The real problem here is architectural. It's pretty much impossible to solve an architectual mistake with code. The real lesson here is that even the newbie Rails programmer ought to understand architecture, because if you put your code in the wrong place, it won't matter if it's good or bad.
If you've started acquiring data before this ever even occurs to you, don't worry - it's easy to fix. All you do is write a small script which loads up every User, downcases its email attribute, and saves the User. It only takes a few lines of code - possibly even a one-liner - and you can run it from the console. I like to do it by putting DatabaseUpdater objects in /lib and then starting them off from the console with something like DatabaseUpdater.go_go_gadget_database(), but there's a pretty strong argument to be made that the migrations are a more appropriate place for this sort of thing. The cleanest solution in terms of self-documenting code is to create DatabaseUpdater.go_go_gadget_database() in /lib, test it in the console, and then call it from a migration, first on your development DB, and then on your production one.
This approach saves your clients or co-workers so much time that you can get away with the Inspector Gadget reference. In fact, the last time I did something like this, I was cleaning the database, so I named the object ViktorTheCleaner after the character from La Femme Nikita.
By the way, I actually very highly recommend idiosyncratic, story-esque names for things like this. The reason is that they put a face on your code, and that extra dose of personality makes it very easy to remember why things were done a certain way, and when, and by whom. It taps a very powerful part of your brain in a very effective way. Also, because of its superficial frivolity, masking a deeper seriousness, this approach also has the very useful side effect of exposing people within your organization who value professionalism over effectiveness. You need to watch out for those idiots, as they're often self-saboteurs who are dangerous to any project they work on, plus they always listen to bad music and recommend bad restaurants, so it's good to be able to spot them quickly and easily, preferably from a distance.
Anyway, big thanks to Assaf for the analysis, and apologies to Tim for the criticism.
Thursday, May 10, 2007
Erlectricity: The Erlang-Ruby Bridge
Ruby Inside posted about a very new project, potentially quite awesome. Scott Fleckenstein has created an Erlang-Ruby bridge called Erlectricity. His blog gives the example of posting to Campfire with Erlang via a Ruby Tinder daemon. I'm still a total n00b with Erlang, but it looks to me as if Erlectricity basically resolves the concurrency disparity between the two languages by treating Ruby as a server and Erlang as a client.
This is an interesting project, and I hope there's more to come.
This is an interesting project, and I hope there's more to come.
Wednesday, May 9, 2007
Comments Now Disabled By Default
Comments are now disabled. Sorry! Unlikely to be re-enabled in the future.
Tuesday, May 8, 2007
How To Sell Version Control To Graphic Designers
Have them open their favorite design comp in Photoshop.
Scribble all over it. Invert the colors. Fuck it up beyond recognition.
Press Command-Z.
Say "Subversion Is Undo For Programmers."
Scribble all over it. Invert the colors. Fuck it up beyond recognition.
Press Command-Z.
Say "Subversion Is Undo For Programmers."
"When The Beast Was Born" Tumblecast
Nifty! I think a tumblecast is like a podcast only more rough and tumble. Kind of a Wild West thing, maybe. Anyway, this is a reading by Miles Forrest of my recent post When The Beast Was Born. Good for your iPod while working out. Or while stuck in traffic. Or you might wish to hear Miles' dulcet tones while making out with your love monkey. Then again, you might not. I haven't actually heard it yet, I'm at a client site, but check it out!
Monday, May 7, 2007
Retire Today And Do Everything
Authors Tim Ferriss (4-Hour Workweek) and Marcia Alboher (One Person/Multiple Careers) give an hour-long talk at Google about how to retire immediately or have multiple careers simultaneously.
Code Generation In Action
This 2003 book has a billion bad reviews on Amazon, most complaining about the use of an obscure language called Ruby, and the lack of detail given for the Java implementations of the book's ideas.
In fact, I've only read one positive review ever for this book.
The author spoke about the subject of his book on Google Video, explaining he wanted it to be a pure Ruby book, but couldn't justify the market at the time.
I'm hoping to post my own review soon.
In fact, I've only read one positive review ever for this book.
The author spoke about the subject of his book on Google Video, explaining he wanted it to be a pure Ruby book, but couldn't justify the market at the time.
I'm hoping to post my own review soon.
Sunday, May 6, 2007
404 Should Be method_missing
The number one post on this blog returned by googling my own name is a post where I explain how my favorite bit of Ruby I ever wrote made my Rails controller emulate method_missing. A prominent blogger has privately described to me an amazing bit of code where he emulated method_missing in Java. I think method_missing may be the single best thing about Ruby, and you have to wonder why, when building Web apps, people don't say to themselves, "Look, we should never return a 404 error page. We should catch any 404 and implement it with some equivalent to method_missing."
Really gotta wonder about that.
Really gotta wonder about that.
New Blog: Spec Scripts And Acting Classes
Sometimes my showbiz yadda yadda results in interesting insights for the world of programming. Sometimes, I have showbiz yadda yadda insights that aren't interesting in the context of programming, but I want to post them anyway. I already have two other blogs for random interests, a Blogger one and a Tumblr one, but neither one really works, because my other interests range too widely. It's pretty hard to nail down a demographic that wants to read about robots, sociology, current events, science, motion graphics, advertizing, art, advanced Rails techniques, functional programming, acting schools, and screenwriting. If you think my posts range pretty widely, realize that this blog is my focused blog. My other ones are all over the place. But, my showbiz interests are focused enough to result in a good blog, so I'm putting them in one.
When the yadda yadda results in useful ideas for programmers and people in technology, except them to still show up on this blog as well. If you want to follow it for its own sake, here it is.
When the yadda yadda results in useful ideas for programmers and people in technology, except them to still show up on this blog as well. If you want to follow it for its own sake, here it is.
I Stand Corrected!
Hi,
I read in your SQL article that you had never used pointers in your life, or never needed to. But you also mention that you used Perl. This means you have in fact used pointers and absolutely must in Perl, unless you never used anything as complicated as an array/hash of arrays/hashes.
Larry Wall and co. call their pointers "references", either because they didn't know the difference or because of the bad reputation of pointers. But the fact is, a pointer and a reference both point to a location in memory. The difference between the two is that a pointer makes you "take the address of" a variable to get it and do some kind of casting/"dereferencing" to use the data again, while a reference handles all this for you (even in C++).
This is one of the biggest reasons Perl has such ugly, hard to read/write/teach syntax (how many newbies don't understand how to pass two arrays to a function?). And what is worse, they keep pointers in Perl 6. They just add more magic syntax to try and keep them out of everyone's way.
Thanks,
Jason
This is a good point!
In that case, I've not only used pointers, I've used them extensively, overused them, gone far out of my way to use them, and even found ways to work around their absence in Ruby.
I disagree with the criticism, though. Anonymous references are absolutely the part of Perl I enjoy the most. I find it very limiting when a programming language expects you to name all your variables. It's much nicer when you can write code to name the variables for you.
I read in your SQL article that you had never used pointers in your life, or never needed to. But you also mention that you used Perl. This means you have in fact used pointers and absolutely must in Perl, unless you never used anything as complicated as an array/hash of arrays/hashes.
Larry Wall and co. call their pointers "references", either because they didn't know the difference or because of the bad reputation of pointers. But the fact is, a pointer and a reference both point to a location in memory. The difference between the two is that a pointer makes you "take the address of" a variable to get it and do some kind of casting/"dereferencing" to use the data again, while a reference handles all this for you (even in C++).
This is one of the biggest reasons Perl has such ugly, hard to read/write/teach syntax (how many newbies don't understand how to pass two arrays to a function?). And what is worse, they keep pointers in Perl 6. They just add more magic syntax to try and keep them out of everyone's way.
Thanks,
Jason
This is a good point!
In that case, I've not only used pointers, I've used them extensively, overused them, gone far out of my way to use them, and even found ways to work around their absence in Ruby.
I disagree with the criticism, though. Anonymous references are absolutely the part of Perl I enjoy the most. I find it very limiting when a programming language expects you to name all your variables. It's much nicer when you can write code to name the variables for you.
Thursday, May 3, 2007
Futurism: Gecko Robots And Cops
The frequently-awesome NXTStep Lego Mindstorms NXT blog has not one but two gecko robots. One was built by Carnegie Mellon researchers; the other was built by hobbyists in Italy using the old ("obsolete") Lego Mindstorms RIS kit from the 90s.
The part about cops is scary, so before we go there, let's think about these gecko robots. One is built of cheap commodity parts by nobodies; one is supported by synthetic nanofiber research at one of the top research universities on earth. This is a nice contrast, the high-tech built by amateurs thing, that's always cool. So let's look at something similar - like submarines and helicopters built by Chinese peasants.
It kind of underscores how different China is. In Medieval Europe, a peasant lives in dirt. In modern China, a peasant builds his own helicopter. Weird.
That's kind of uplifting. Kind of happy. Kind of hopeful. Very quirky. Funny and entertaining.
Let's get to the cops.
Here they are, beating women and children at a peaceful demonstration in downtown Los Angeles, which is, for better or worse, one of the world's cultural capitals, and one of the greatest cities of one of the most free and democratic countries on earth. Which country, obviously, did not enjoy its most free and democratic moment yesterday.
Boing Boing has all the details, including a great video roundup; check out this one, which features Fox News reporters getting physically attacked for simply trying to cover a story - very much contradicting their network's stereotype - and this one as well. Long story short, even compared to the WTO riots in Seattle ten years ago, this was crazy. Unlike the Seattle riots, the protestors did nothing. Some of them weren't even protestors; some of the people attacked were pushing carts around and selling hot dogs. Some of them were children under 10.
What does this have to do with gecko robots?
I'm so glad you asked.
Watch movies and TV, read modern fantasy fiction, and you'd be inclined to believe that societies have always had police forces. This isn't the case at all. The police did not exist in European civilizations until the 1800s, when the British invented them, in London.
My secret theory is that they were actually imported from Asia. Or rather, that the English got the idea from colonial experiences in Asia. The Chinese have used standing armies against their own people for thousands and thousands of years, and England at the time had a strong military and colonial presence in China. Indeed, these scenes from downtown LA are less shocking than they should be because we see scenes just like this coming out of China, Indonesia, and Singapore about once a month.
The reason a peasant can build a submarine or a helicopter in China, yet never become something more than a peasant, is because of a powerful, corrupt system that is designed for the express purpose of consolidating money and power in the hands of people who control it. Contrary to Chinese propaganda, Communist China is really not very different from pre-Communist China. It became Communist when a massive peasant revolution put Chairman Mao in control. But the historical pattern in China, for thousands of years, has been one of tyrannical government, which gets away with all kinds of mistreatment until the peasants have had enough. Then they rise up, put their leader on the throne, and life goes back to normal. The system is perpetuated, but different people get control of it.
This is why a Chinese peasant is a peasant. Because he's outside the system which controls money and power. A Chinese peasant smart enough to build a submarine remains a peasant anyway, and builds a petty little peasant submarine. And that is all his genius ever amounts to.
What happens to a Carnegie Mellon researcher smart enough to build a gecko robot? Of course, he or she goes on to do more robotics research, gets paid well, lives in a nice house, and raises fat and happy children.
What happens to an Italian hobbyist smart enough to build a gecko robot?
Does he or she go back to work on Monday like nothing ever happened?
Of course they do.
The thing that makes America different is that here, you might not be back at work on Monday like nothing ever happened. Make something truly brilliant, and you can fire your boss. This is a place where you can start from your garage and end up a gazillionaire.
But the attitude that takes cops and uses them simply as soldiers against innocent people gathered peacefully in a park, that is an attitude which undermines that American greatness. Because if what the cops do has nothing to do with the law, then they're nothing but a weapon for people with influence to use against people without influence. If your relationship with your boss is a purely economic one, you have the power to fire them; if your relationship with your boss is determined by the fact that your boss can use cops against you, and you can't use cops against them, whether they break the law or not, then you don't have that power, and the whole American Dream tanks. It's no longer possible; it goes from dream to daydream, because it rests on economic equality, and equality under the law. Without those things, it just can't happen.
I can't tell you exactly what the future is here, but I would love to see some solid statistical research on police presence as a predictor of economic innovation. I suspect police presence is a strong indicator of wasted innovation - which is to say, innovation which would be useful to everybody but which is never distributed widely. The reality is, if the police were only ever used in the United States to uphold the law, there would be less of them than there are. Every tax dollar that moves out of our pockets to pay the salary of a police officer who doesn't even uphold the law is a dollar that could have launched the next Apple, or a failed attempt at becoming the next Apple. (And failed startups are one of the best centers of research in this country.)
Also: In a way, open source represents a triumph of the amateurs. Amateurs might not rule the world of gecko robots or submarines, but open-source software beats proprietary software almost every time. I don't know exactly how that ties in, but I know it must mean something.
The part about cops is scary, so before we go there, let's think about these gecko robots. One is built of cheap commodity parts by nobodies; one is supported by synthetic nanofiber research at one of the top research universities on earth. This is a nice contrast, the high-tech built by amateurs thing, that's always cool. So let's look at something similar - like submarines and helicopters built by Chinese peasants.
It kind of underscores how different China is. In Medieval Europe, a peasant lives in dirt. In modern China, a peasant builds his own helicopter. Weird.
That's kind of uplifting. Kind of happy. Kind of hopeful. Very quirky. Funny and entertaining.
Let's get to the cops.
Here they are, beating women and children at a peaceful demonstration in downtown Los Angeles, which is, for better or worse, one of the world's cultural capitals, and one of the greatest cities of one of the most free and democratic countries on earth. Which country, obviously, did not enjoy its most free and democratic moment yesterday.
Boing Boing has all the details, including a great video roundup; check out this one, which features Fox News reporters getting physically attacked for simply trying to cover a story - very much contradicting their network's stereotype - and this one as well. Long story short, even compared to the WTO riots in Seattle ten years ago, this was crazy. Unlike the Seattle riots, the protestors did nothing. Some of them weren't even protestors; some of the people attacked were pushing carts around and selling hot dogs. Some of them were children under 10.
What does this have to do with gecko robots?
I'm so glad you asked.
Watch movies and TV, read modern fantasy fiction, and you'd be inclined to believe that societies have always had police forces. This isn't the case at all. The police did not exist in European civilizations until the 1800s, when the British invented them, in London.
My secret theory is that they were actually imported from Asia. Or rather, that the English got the idea from colonial experiences in Asia. The Chinese have used standing armies against their own people for thousands and thousands of years, and England at the time had a strong military and colonial presence in China. Indeed, these scenes from downtown LA are less shocking than they should be because we see scenes just like this coming out of China, Indonesia, and Singapore about once a month.
The reason a peasant can build a submarine or a helicopter in China, yet never become something more than a peasant, is because of a powerful, corrupt system that is designed for the express purpose of consolidating money and power in the hands of people who control it. Contrary to Chinese propaganda, Communist China is really not very different from pre-Communist China. It became Communist when a massive peasant revolution put Chairman Mao in control. But the historical pattern in China, for thousands of years, has been one of tyrannical government, which gets away with all kinds of mistreatment until the peasants have had enough. Then they rise up, put their leader on the throne, and life goes back to normal. The system is perpetuated, but different people get control of it.
This is why a Chinese peasant is a peasant. Because he's outside the system which controls money and power. A Chinese peasant smart enough to build a submarine remains a peasant anyway, and builds a petty little peasant submarine. And that is all his genius ever amounts to.
What happens to a Carnegie Mellon researcher smart enough to build a gecko robot? Of course, he or she goes on to do more robotics research, gets paid well, lives in a nice house, and raises fat and happy children.
What happens to an Italian hobbyist smart enough to build a gecko robot?
Does he or she go back to work on Monday like nothing ever happened?
Of course they do.
The thing that makes America different is that here, you might not be back at work on Monday like nothing ever happened. Make something truly brilliant, and you can fire your boss. This is a place where you can start from your garage and end up a gazillionaire.
But the attitude that takes cops and uses them simply as soldiers against innocent people gathered peacefully in a park, that is an attitude which undermines that American greatness. Because if what the cops do has nothing to do with the law, then they're nothing but a weapon for people with influence to use against people without influence. If your relationship with your boss is a purely economic one, you have the power to fire them; if your relationship with your boss is determined by the fact that your boss can use cops against you, and you can't use cops against them, whether they break the law or not, then you don't have that power, and the whole American Dream tanks. It's no longer possible; it goes from dream to daydream, because it rests on economic equality, and equality under the law. Without those things, it just can't happen.
I can't tell you exactly what the future is here, but I would love to see some solid statistical research on police presence as a predictor of economic innovation. I suspect police presence is a strong indicator of wasted innovation - which is to say, innovation which would be useful to everybody but which is never distributed widely. The reality is, if the police were only ever used in the United States to uphold the law, there would be less of them than there are. Every tax dollar that moves out of our pockets to pay the salary of a police officer who doesn't even uphold the law is a dollar that could have launched the next Apple, or a failed attempt at becoming the next Apple. (And failed startups are one of the best centers of research in this country.)
Also: In a way, open source represents a triumph of the amateurs. Amateurs might not rule the world of gecko robots or submarines, but open-source software beats proprietary software almost every time. I don't know exactly how that ties in, but I know it must mean something.
Wednesday, May 2, 2007
Best Ruby On Rails Books
This is a big Frequently Asked Question, so here's my answer:
1. Agile Web Development with Rails
2. Ruby for Rails
3. The Ruby Way
If you're a newbie, start with 1 and go to 3. If you're an experienced programmer, start with 3 and go to 1.
If you're a newbie, read Ruby for Rails at least three times. If you're an experienced programmer, read the last five chapters at least twice.
I'm assuming, of course, that you want to be good at what you do.
Here's why these are the books that'll get you there.
Agile Web Dev will give you the Rails overview; The Ruby Way will teach you how to program Ruby; Ruby for Rails is where these two things meet. That's why it's in the middle whether you have experience or not. If you're experienced you'll want to understand how to think in Ruby, and how Rails is an extension of that. If you're a newbie you'll want to build something just to build it, and then learn how you should have done it.
Other popular books include Programming Ruby (the pickaxe book), O'Reilly's Ruby Cookbook, and why's Poignant Guide. why's book is insane, but that's a good thing. The Ruby Cookbook is good, but a bit predictable. O'Reilly only issued it after the Rails bandwagon started picking up steam. I think there are a couple other books from O'Reilly as well. They're probably good. O'Reilly has pretty dependable standards of quality, although they have started slipping a bit now and then. Programming Ruby is popular but I wasn't into it. The same authors wrote The Pragmatic Programmer, which is much better. Every programmer should read that.
1. Agile Web Development with Rails
2. Ruby for Rails
3. The Ruby Way
If you're a newbie, start with 1 and go to 3. If you're an experienced programmer, start with 3 and go to 1.
If you're a newbie, read Ruby for Rails at least three times. If you're an experienced programmer, read the last five chapters at least twice.
I'm assuming, of course, that you want to be good at what you do.
Here's why these are the books that'll get you there.
Agile Web Dev will give you the Rails overview; The Ruby Way will teach you how to program Ruby; Ruby for Rails is where these two things meet. That's why it's in the middle whether you have experience or not. If you're experienced you'll want to understand how to think in Ruby, and how Rails is an extension of that. If you're a newbie you'll want to build something just to build it, and then learn how you should have done it.
Other popular books include Programming Ruby (the pickaxe book), O'Reilly's Ruby Cookbook, and why's Poignant Guide. why's book is insane, but that's a good thing. The Ruby Cookbook is good, but a bit predictable. O'Reilly only issued it after the Rails bandwagon started picking up steam. I think there are a couple other books from O'Reilly as well. They're probably good. O'Reilly has pretty dependable standards of quality, although they have started slipping a bit now and then. Programming Ruby is popular but I wasn't into it. The same authors wrote The Pragmatic Programmer, which is much better. Every programmer should read that.
Step Outside Your Own Head
One of my favorite books is James Gleick's Chaos, which tells the story of the (then-)emerging science of chaos math. A major theme in that book is the value of cross-pollination. Many of the big discoveries in chaos math came from people crossing the lines which defined fields of study. For instance, one of the first strange attractors was discovered by a meteorologist. The idea which Chaos puts forward is that research informed by two fields of study inherently leads to thinking which accomodates the possibilities of both fields while accepting the limitations of neither.
The idea is very far from proven, and easily dismissed by the skeptical; yet there's no doubt that studying two things intensely and in depth will lead you to perspectives on both of those things which will never be experienced by somebody who has only ever studied one.
Of course one great example is DHH, creator of Rails.
While legions of geeks admire him worldwide, and many people acknowledge that Rails is a huge marketing success as well as a huge programming success, very few people seem to think of DHH as a businessman per se, and the business component of his degree (a bachelor's in Computer Science and Business Administration) is apparently assumed by geeks in general to have no significance at all. Likewise, as a partner in a small business, rather than the chief overlord of some gigantor-mongous raging corporate megabeast, DHH slips under the business radar as well. Consequently he can make great business decisions, write incisive commentary on business, and still be regarded entirely as a programmer.
My own forays into cross-pollination don't have the stellar success DHH enjoys, but I did learn something interesting last week. I went to see a movie called Fracture, primarily because an acting teacher had seemed excited about it and partly because it was 4:45 and I wanted to avoid rush hour traffic. I looked at it from the perspective of an actor in training and a wannabe screenwriter, and saw some flaws. What's interesting about this is that I had recently seen the same flaws somewhere else - somewhere very different, in fact. I had been to a technical interview, where, when faced with a classic "prove you can think in algorithms" question, I had failed entirely to prove I could think in algorithms, but proved beyond a shadow of a doubt that I could argue about user experience design.
(In my defense, when I got started in this thing, there was initially no real distinction between a programmer and a user experience designer. But when I got started, people were having arguments on Usenet about whether or not the Web would ever be as big as Compuserve. I got started a long time ago, and things have changed since then.)
Anyway, the reason I mention all this is that the flaw I brought up in my argument about UX design was the same flaw I spotted in this movie.
The algorithms question was all about how you would model a hierarchical filesystem in a Rails app, so that a hypothetical user could create folders and subfolders. I argued that the whole thing was a bad idea, because hierarchical filesystems only reflect the mindset of highly organized people who think in terms of hierarchies - in a word, engineers.
My view was that building a system which presumes an engineer's habit of thinking sets up real speed bumps to adoption for normal people, and in the context of a consumer application, this is a real problem. I said instead the system should do away with the entire idea of a filesystem and instead allow for entities to be tagged, and to bear multiple tags if the user wanted.
In fact I think this should be a guiding design principle for all Web applications today. Replace the hierarchical filesystem with tagged search. Google did it for Gmail, and it became a powerful competitive advatnage. Quicksilver does it for OS X, and it works beautifully there as well. In fact Quicksilver is easily the best thing about OS X. As Microsoft's day fades further and further into the past, more and more applications will follow suit. That whole paradigm is over. In the past, showing users the hierarchical organization behind the scenes was useful, or at least something you could get away with doing; but today, ever since Google, it simply insults the value of their time.
However, the paradigm still makes sense to engineers, because we think in terms of the machinery behind the scenes. I use Quicksilver, but I often use it to launch a Unix terminal. Asking you to think in terms of the machinery behind the scenes isn't an insult to the value of your time if you think in those terms anyway. But it's important to realize that most people don't. My objection, essentially, was that the engineers were assuming their users were also engineers. They were stuck inside their own heads.
(By the way, my truculence was met with surprising grace on the part of my interviewer, and I have to credit him for that.)
Anyway - this movie made a very similar mistake. It includes a lot of stuff about the life of lawyers, and unfortunately, speaking as the son of a lawyer, I can tell you that they made a few mistakes in the area of reality. Lawyers do not, in real life, rapidly promote talented underlings, or fire people without serious consideration beforehand. Lawyers also do not have sex with their employees or employers lightly, nor do they casually expose professionally inappropriate relationships to public scrutiny by inviting theirpartners co-conspirators in such professionally inappropriate relationships to Thanksgiving dinner. Lawyers do not give up the law for good and move out of town if a particular case goes badly. Lawyers do not hold their most crucial business meetings during swank rooftop parties. In general, lawyers tend to be cautious people who value propriety and common sense, and who work in offices and courtrooms, with their clothes on.
As implausible as all of this is for a group of lawyers, however, it's not at all implausible behavior for people in Hollywood. In fact it's really what people in Hollywood are notorious for. Sex all over the place. Studio execs getting fired and hired like it's nothing. Everyone holds their most crucial business meetings at parties. And plenty of Hollywood wannabes have packed up for good after a deal went south. Even though it's utterly inaccurate to portray lawyers this way, it's perfectly reasonable to portray screenwriters living this kind of life. It's just utterly insane to imagine regular people living that way. The people who wrote this movie about lawyers were assuming these lawyers were screenwriters too.
It's easy to criticize them, especially when sitting through absurdly implausible scenes in an otherwise believable movie, but given that I've also seen engineers caught in what is ultimately the same mental trap, it's much more useful to consider that everybody does this in some way or another, and that the ability to get past it is a very useful - and very rare - thing.
In Google's case, throwing away the hierarchical filesystem in favor of tagged search created one of Gmail's most overwhelming superiorities. The folders model is a foolish model for e-mail, given the huge volume of e-mail that the average e-mail account will see during its lifespan. A hierarchical filesystem is not a useful way for the casual user to organize thousands of X, for any value of X. It just doesn't match the human brain.
Gmail and Quicksilver owe a lot of their business to this simple insight, and similar opportunities exist. Look hard and you'll find them. But first you have to be able to move outside the boundaries of your own expectations. Step outside your own head.
(Also, Clay Shirky has an excellent podcast where he explains how Yahoo's failure to make a very similar mental leap cost them their business once Google got up and running.)
The idea is very far from proven, and easily dismissed by the skeptical; yet there's no doubt that studying two things intensely and in depth will lead you to perspectives on both of those things which will never be experienced by somebody who has only ever studied one.
Of course one great example is DHH, creator of Rails.
While legions of geeks admire him worldwide, and many people acknowledge that Rails is a huge marketing success as well as a huge programming success, very few people seem to think of DHH as a businessman per se, and the business component of his degree (a bachelor's in Computer Science and Business Administration) is apparently assumed by geeks in general to have no significance at all. Likewise, as a partner in a small business, rather than the chief overlord of some gigantor-mongous raging corporate megabeast, DHH slips under the business radar as well. Consequently he can make great business decisions, write incisive commentary on business, and still be regarded entirely as a programmer.
My own forays into cross-pollination don't have the stellar success DHH enjoys, but I did learn something interesting last week. I went to see a movie called Fracture, primarily because an acting teacher had seemed excited about it and partly because it was 4:45 and I wanted to avoid rush hour traffic. I looked at it from the perspective of an actor in training and a wannabe screenwriter, and saw some flaws. What's interesting about this is that I had recently seen the same flaws somewhere else - somewhere very different, in fact. I had been to a technical interview, where, when faced with a classic "prove you can think in algorithms" question, I had failed entirely to prove I could think in algorithms, but proved beyond a shadow of a doubt that I could argue about user experience design.
(In my defense, when I got started in this thing, there was initially no real distinction between a programmer and a user experience designer. But when I got started, people were having arguments on Usenet about whether or not the Web would ever be as big as Compuserve. I got started a long time ago, and things have changed since then.)
Anyway, the reason I mention all this is that the flaw I brought up in my argument about UX design was the same flaw I spotted in this movie.
The algorithms question was all about how you would model a hierarchical filesystem in a Rails app, so that a hypothetical user could create folders and subfolders. I argued that the whole thing was a bad idea, because hierarchical filesystems only reflect the mindset of highly organized people who think in terms of hierarchies - in a word, engineers.
My view was that building a system which presumes an engineer's habit of thinking sets up real speed bumps to adoption for normal people, and in the context of a consumer application, this is a real problem. I said instead the system should do away with the entire idea of a filesystem and instead allow for entities to be tagged, and to bear multiple tags if the user wanted.
In fact I think this should be a guiding design principle for all Web applications today. Replace the hierarchical filesystem with tagged search. Google did it for Gmail, and it became a powerful competitive advatnage. Quicksilver does it for OS X, and it works beautifully there as well. In fact Quicksilver is easily the best thing about OS X. As Microsoft's day fades further and further into the past, more and more applications will follow suit. That whole paradigm is over. In the past, showing users the hierarchical organization behind the scenes was useful, or at least something you could get away with doing; but today, ever since Google, it simply insults the value of their time.
However, the paradigm still makes sense to engineers, because we think in terms of the machinery behind the scenes. I use Quicksilver, but I often use it to launch a Unix terminal. Asking you to think in terms of the machinery behind the scenes isn't an insult to the value of your time if you think in those terms anyway. But it's important to realize that most people don't. My objection, essentially, was that the engineers were assuming their users were also engineers. They were stuck inside their own heads.
(By the way, my truculence was met with surprising grace on the part of my interviewer, and I have to credit him for that.)
Anyway - this movie made a very similar mistake. It includes a lot of stuff about the life of lawyers, and unfortunately, speaking as the son of a lawyer, I can tell you that they made a few mistakes in the area of reality. Lawyers do not, in real life, rapidly promote talented underlings, or fire people without serious consideration beforehand. Lawyers also do not have sex with their employees or employers lightly, nor do they casually expose professionally inappropriate relationships to public scrutiny by inviting their
As implausible as all of this is for a group of lawyers, however, it's not at all implausible behavior for people in Hollywood. In fact it's really what people in Hollywood are notorious for. Sex all over the place. Studio execs getting fired and hired like it's nothing. Everyone holds their most crucial business meetings at parties. And plenty of Hollywood wannabes have packed up for good after a deal went south. Even though it's utterly inaccurate to portray lawyers this way, it's perfectly reasonable to portray screenwriters living this kind of life. It's just utterly insane to imagine regular people living that way. The people who wrote this movie about lawyers were assuming these lawyers were screenwriters too.
It's easy to criticize them, especially when sitting through absurdly implausible scenes in an otherwise believable movie, but given that I've also seen engineers caught in what is ultimately the same mental trap, it's much more useful to consider that everybody does this in some way or another, and that the ability to get past it is a very useful - and very rare - thing.
In Google's case, throwing away the hierarchical filesystem in favor of tagged search created one of Gmail's most overwhelming superiorities. The folders model is a foolish model for e-mail, given the huge volume of e-mail that the average e-mail account will see during its lifespan. A hierarchical filesystem is not a useful way for the casual user to organize thousands of X, for any value of X. It just doesn't match the human brain.
Gmail and Quicksilver owe a lot of their business to this simple insight, and similar opportunities exist. Look hard and you'll find them. But first you have to be able to move outside the boundaries of your own expectations. Step outside your own head.
(Also, Clay Shirky has an excellent podcast where he explains how Yahoo's failure to make a very similar mental leap cost them their business once Google got up and running.)
Jay Fields Added As RailsConf Speaker
This would be awesome news, except he's sharing a timeslot with Evan Weaver, so one way or another, I have to miss a presentation by one of my favorite Rails bloggers.
I don't know what I'll decide but I'll share the anguish of the decision-making process. Evan Weaver just released Bleak House, and he's a polymath like me - in addition to Ruby, his bio lists Perl, Python, Java, bioinformatics, writing, and graphic design. Jay Fields works for ThoughtWorks, which is a great company with a very strong link to the guy who wrote Refactoring. Not a great company in the sense that Google is a great company; great in the same way that the GFS or machine learning areas of Google are great. His blog has great stuff about mocks and stubs, which he'll be presenting on, as well as what he calls, appropriately enough, the Presenter pattern.
So here I am. I'm a self-taught hax0r who puts a great deal of value on software architecture. Evan's doing a presentation on how to take Rails apart and use it in weird and unexpected ways. Jay's doing a presentation on how to take a particular piece of Rails apart - redefining ActiveRecord::Base.connection to use Mocha and Stubba to achieve greatly superior testing. And anybody who knows what testing really is, in Rails and Agile software in general - a design tool - knows that when you do this, you design better software.
Aargh! Evan's presentation will probably win on the wild-and-wooly-ness of it all, but aargh all the same.
I don't know what I'll decide but I'll share the anguish of the decision-making process. Evan Weaver just released Bleak House, and he's a polymath like me - in addition to Ruby, his bio lists Perl, Python, Java, bioinformatics, writing, and graphic design. Jay Fields works for ThoughtWorks, which is a great company with a very strong link to the guy who wrote Refactoring. Not a great company in the sense that Google is a great company; great in the same way that the GFS or machine learning areas of Google are great. His blog has great stuff about mocks and stubs, which he'll be presenting on, as well as what he calls, appropriately enough, the Presenter pattern.
So here I am. I'm a self-taught hax0r who puts a great deal of value on software architecture. Evan's doing a presentation on how to take Rails apart and use it in weird and unexpected ways. Jay's doing a presentation on how to take a particular piece of Rails apart - redefining ActiveRecord::Base.connection to use Mocha and Stubba to achieve greatly superior testing. And anybody who knows what testing really is, in Rails and Agile software in general - a design tool - knows that when you do this, you design better software.
Aargh! Evan's presentation will probably win on the wild-and-wooly-ness of it all, but aargh all the same.
Tuesday, May 1, 2007
Hey Kevin, Grow A Pair
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Digg is all about user powered content. That, at least, is what it says. But the users are bombing Digg and right now I can't even get a response from the server.
I'm on your Web site. Calling your bluffs.
Update! Kevin grows a pair. Awesome.
Digg is all about user powered content. That, at least, is what it says. But the users are bombing Digg and right now I can't even get a response from the server.
I'm on your Web site. Calling your bluffs.
Update! Kevin grows a pair. Awesome.
Good Thing On Bayes Nets
I want to start a blog called "Coding Horror minus all the stuff about Microsoft." I can't figure out why somebody that smart would ever even bother to think about anything to do with Microsoft. It's kind of like the weird Boing Boing obsession with Disneyland. However, until I get that blog started, I'm filtering Coding Horror for great content so you don't have to. Here's an awesome little post on Bayes nets which links to an awesome bigger post on Bayes nets. (I think I've actually seen it before, but it's definitely worth a read.)
More Bush Administration Law-Breaking
Sorry! Totally zero programming content. Just a case of time-sensitive outrage.
The law that created the Department of Homeland Security prohibited a national identification system. By trying to implement REAL ID, the Department of Homeland Security is breaking the law...
Do something about it before May 8th.
The law that created the Department of Homeland Security prohibited a national identification system. By trying to implement REAL ID, the Department of Homeland Security is breaking the law...
Do something about it before May 8th.
Rails Developers Need Computer Science Too
This is kind of ironic, given that I have no degree in anything myself, but Rails developers with degrees in comp sci have an advantage. The complex stuff is useful much more frequently than people usually realize.
On the ruby-talk mailing list, there have been a couple examples of this which revolved around sets. Sets are a standard mathematical concept taught to children with Venn diagrams.
The first example came when people were trying to do set math with arrays when translating Peter Norvig's short Python spell-checker into Ruby. Translation is cool, but changing from sets to arrays just didn't seem logical to me at all. (To be fair, I don't actually know if it makes a difference in terms of performance.) The second example referenced this blog, where a happy Dr. Strangecode learned to stop worrying and love the standard library.
Wow, am I sounding pompous today. It makes a difference, though. In the long term, shortcuts don't lead to increased readability, increased performance, or increased ease of maintenance, and you want all those things. Also, the Norvig Python spell-checker had to import Python's collections. To use Ruby's Set, you need to require 'set'. So it's not even translation in that instance; it's a nearly literal and exact transliteration. The only explanation for not requiring Set in that case is ignorance of its existence.
It's sad but true; if a Ruby programmer learns the standard library, they've distinguished themselves in the marketplace. They've acquired a powerful competitive advantage. This wasn't true a year ago. It makes Rails' popularity bittersweet.
The good news is, if you want to learn the standard library, there are easy ways to do it. One is to read the docs. Another is Hal Fulton's excellent book The Ruby Way. And the best news of all is that if you were programming Ruby before Rails, that's not just a competitive advantage; at this point it's practically a gold mine.
On the ruby-talk mailing list, there have been a couple examples of this which revolved around sets. Sets are a standard mathematical concept taught to children with Venn diagrams.
The first example came when people were trying to do set math with arrays when translating Peter Norvig's short Python spell-checker into Ruby. Translation is cool, but changing from sets to arrays just didn't seem logical to me at all. (To be fair, I don't actually know if it makes a difference in terms of performance.) The second example referenced this blog, where a happy Dr. Strangecode learned to stop worrying and love the standard library.
Wow, am I sounding pompous today. It makes a difference, though. In the long term, shortcuts don't lead to increased readability, increased performance, or increased ease of maintenance, and you want all those things. Also, the Norvig Python spell-checker had to import Python's collections. To use Ruby's Set, you need to require 'set'. So it's not even translation in that instance; it's a nearly literal and exact transliteration. The only explanation for not requiring Set in that case is ignorance of its existence.
It's sad but true; if a Ruby programmer learns the standard library, they've distinguished themselves in the marketplace. They've acquired a powerful competitive advantage. This wasn't true a year ago. It makes Rails' popularity bittersweet.
The good news is, if you want to learn the standard library, there are easy ways to do it. One is to read the docs. Another is Hal Fulton's excellent book The Ruby Way. And the best news of all is that if you were programming Ruby before Rails, that's not just a competitive advantage; at this point it's practically a gold mine.
Scriptaculous/Prototype Alternatives
UJS
MochiKit
MooTools
Haven't done a great deal of research with any of these, but I can say that MochiKit's shell-like interpreter is mighty nifty.
Update: check the comments for additional options.
MochiKit
MooTools
Haven't done a great deal of research with any of these, but I can say that MochiKit's shell-like interpreter is mighty nifty.
Update: check the comments for additional options.
Subscribe to:
Posts (Atom)
sd.rb
