Thursday, May 31, 2007

Microfame

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.

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:

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.


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.

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

Quizzing On Syntax: Maybe A Good Idea After All

Whoops.

On the same site, an excellent screencast about ruby-debug.

Rails AntiPattern: if environment == X

Lots of people will do this:

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?

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.

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.

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.

{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] ~
!

All RailsConf Presentations Available For Download

Nice!

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.

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.

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.

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.)

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.

Monday, May 21, 2007

Link Roundup: Information And Paranoia

Knowledge is a strange thing.



Watch the skies, because the skies are watching you.

But don't let them see you seeing them.



Remember what happens to people who make waves.

A Brainfuck Compiler For Linux

Brainfuck is a deliberately difficult programming language, like Malbolge and Unlambda.

Compilers range from 240 to 171 bytes in size.

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.

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.

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?)

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.)

The L in DSL

This is not a domain specific language. It is, rather, domain specific language.

Friday, May 18, 2007

Why The ruby-talk List Is Awesome

%f{This is sooo cooooold} << "!"

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...

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.

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.

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.

Working Prosthetic Robot Arm

Demand For Books On Ruby

Gibberish Rails Localization/I18n Plugin

Looks awesome.

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.

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.

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.

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.