Oh dear. The chattering classes are at it, talking about how the Twitter folks are dissing Ruby by announcing the replacement of some Ruby code with Scala code.
Please stop.
At the kinds of volumes that Twitter handles (and with what I assume is a somewhat scary growth curve), Twitter needs to improve concurrency—it needs an environment/language with low memory overhead, incredible performance, and super-efficient threading. I don't know if Scala fits that particular bill, but I know that current Ruby implementations don't. It isn't what Ruby's intended to be. So the move away is just sound thinking. (I suspect it also took some courage.) I applaud Alex and the team for this.
Instead of defending Ruby when it's clearly not an appropriate solution, let's think about things the other way around.
The good folks at Twitter started off with Ruby because they wanted to get something running quickly, and they wanted to experiment. And Ruby gave them that. And, what's more, Ruby saw them through at least two rounds of phenomenal growth. Could they have done it in another language? Sure. But I suspect Ruby, despite the occasional headache, helped them get where they are now.
And now they've reached the status of world-wide wunderkind, it's time to move on.
I for one wish them luck. I look forward to the day when our online store reaches the kind of size where we have to move away from Rails. I'll tweet the fact with a tear in my eye, while my yacht sails me off to the sunset.
Over lunch at Scotland on Rails, Jim, Chad, and I got talking about the way you use desc to document tasks in rake.
desc"Remove intermediate files and other work products" task :cleanup do ... end
This has always been an interesting feature of rake—the idea that you have a kind of temporal coupling between one method call and the next. It works well, but somehow it's always struck me as a little obtrusive.
So, during the afternoon, I hacked up a quick change to rake that looks for a single-line comment on the line prior to all task, file, etc directives, and uses that as the task description. With this version of rake, you can write
# Remove intermediate files and other work products task :cleanup do
... end
The comment becomes the description of the task, because it occurs before the task directive with no intervening blank line. desc still works, and if both desc and a comment are present, the desc takes priority. It's purely a matter of taste, but I personally find the comment form more natural.
You can get this patched version fromhttp://github.com/pragdavespc/rake/tree/master. I've passed the patch on to Jim, so if you like the idea, let him know and maybe he'll roll it into the next rake release.
Last week we completed our largest direct shippment, as we sent out the preorders for Agille Web Development with Rails, Third Edition. We had tons of books delivered, and bought tens of thousands of dollars of shipping supplies and postage, but despite the volume everything went well (apart from the inevitable paper cuts). I even learned where the big boys go to the Post Office (which turns out to be a pretty impressive facility right next to DFW airport).
So I thought I'd share just a couple of statistics. Domestically, we shipped books to every state except North Dakota. Internationally we shipped to three US bases, and a total of 55 different countries (from Angola to Vietnam). Sometimes I close my eyes and think of the trajectories of all those books spreading out from Raleigh and Dallas—it's a cool picture.
So, if you bought a Rails book from us: thank you! It's been an interesting year (way longer than would would have liked, but that's the joy of working with a rapidly changing technology). We hope you enjoy the result. And, remember, we now have eBook formats available for your Kindle, iPhone, and so on.
I'm getting close to wrapping up the new PickAxe. One of the last things I need is an example of symetric coroutines for the standard library section on the Fiber class.
I have lots of asymetric examples, but I'm struggling to come up with something decent for symetric coroutines (which use transfer to pass control between themselves.) I've coded up Conway's line squeezer, but it works better using asymetric coroutines. I've tried to come up with puzzles that are best solved with symetric coroutines, but without luck. I've coded up a simple blackjack game, but again it works better with asymetric coroutines. Although, for fun, here's the dealer, which shows some of the new Ruby 1.9 array methods:
But, I'm still stuck. So... can any of you clever folk come up with something compelling that uses less that 35 lines of code?
I love doing the Pragmatic Studios. Nicole, Mike, and Chad are all good friends, and that creates a really relaxed and fun atmosphere for what could otherwise be a pretty intense three days.
The next studio is in Denver at the end of January, and I'm really looking forward to it—living in Texas, I relish being able to see mountains and snow. I just wish I was a skier so I could have an excuse to take an extra day or two to head on up to a resort.
If you are planning on going, though, don't put it off—early registration (a $300 savings) ends in a week.
There's one bad side to the studios, though. Mike put together a video showing what studios are like. Notice anything? Food. Lots of it. Scarily good food. Must resist. Must…
I decided a while back to publish the music I'm writing, if nothing else as a way of keeping myself honest. So, here's a little piece of fluff I wrote just to play with time signatures—alternating 5/8 and 6/8 has a nice drive to it.
But, I have a problem: I can't actually perform any of the pieces I write, so I'm somewhat at the mercy of the good will of others (notably my teacher) to record them for me. And Christmas is a busy season for my teacher, so I don't yet have a recording of this piece.
Because this piece is so simple, Sibelius' built-in playback sounds OK, so that's what I'm posting. But if anyone fancies recording this, or taking it and turning it into something cool (as Chris Morris did with my previous piece) please send me a link and I'll add it here.
Like the rest of our publishing business, I like to keep our covers simply and easy. But now I realize that these covers fail to capture the true epic nature of our books. Joey deVilla posted some reworkings of book covers last year, but I only came across them today. I'm inspired...
The strange thing is: I'm not sure where he got hold of the image. After we posed for the picture, DHH and I thought better of it. We thought we had destroyed all the copies...
All Ruby programmers regularly encounter the mystical error “syntax error, unexpected $end, expecting keyword_end.” We know what it means: we left off an end somewhere in the code. As Ruby compiled our source, it keeps track of nesting, and when it reached the end of file ($end), it was expecting to see one more end keyword, and none was there.
So, we trundle back through the source, and after a while discover we'd deleted just one too many lines during that last edit.
Ruby 1.9 makes that easier. For example, here's a source file:
class Example def meth1 if Time.now.hours > 12 puts "Afternoon" end def meth2 # ... end end
Run it through Ruby 1.9, and you'll get the same old error message:
There's a sound that no presenter wants to hear, and that's dead silence. And that's what greeted me when I made the suggestion in my RubyConf keynote that the community should fork the Ruby language. I think by the end of the talk, though, most people were convinced.
Am I anti Ruby? no.
Am I suggesting Matz is doing a bad job? Not in the least.
But I do think the complexity of the current language inhibits experimentation with language features. Want to implement parallel Ruby? If you do it with the current syntax and semantics, you'll be struggling with the integration of global variables, the non-threadsafe nature of require, continuations, and so on, and so on. So before starting these kinds of experimental projects, I'm saying we should fork the language. Produce variants that let us focus in on the aspects under test. Make the new language a rich-enough subset that you can do useful work with it. Then let people play with it. Maybe the ideas are stellar, in which case we can all talk about integrating the changes back into the mainline language. And maybe the idea didn't pan out, in which case we can quietly forget it, and we've done no damage to the language itself.
A mutation is an altered fork of the original. And mutations are essential to the diversity and strength of a genetic line over time. Let's not be afraid to create Ruby mutants and let them compete.
During our sale, we had one particular request that came in and wedged the application: every time it hit, the mongrel process size zoomed steadily up to 500Mb, so we had to kill it. But finding out which request was doing this was tricky. The log files didn't help—with the amount of traffic we were getting, it was a small needle and a large haystack.
Eventually, we found the culprit. But it would have been a lot easier if I'd thought of this hack on Friday, and not after the sale ended.
If you put this into your application controller:
before_filter :set_process_name_from_request
def set_process_name_from_request
$0 = request.path[0,16]
end
after_filter :unset_process_name_from_request
def unset_process_name_from_request
$0 = request.path[0,15] + "*"
end
then Ruby will set the cmd field in your process control block to the first 16 characters of the request path. You can then use top to see what request is being handled by each mongrel.
Once the request has been handled, an asterisk sign is appended, so you can see the last URL when a mongrel becomes idle.
If your version of top doesn't show the short command by default, use the c keyboard command to see it.
This is probably common knowledge, but I thought it was cool.
The path to a stable Ruby 1.9 has been long. Almost a year ago, 1.9.0 was released. This turned out to have been less than stable. The core library has grown by many hundreds of methods since then. And, probably more significantly, people have started using 1.9 for real, and they've discovered rough edges that needed to be fixed. In particular, the multinationalization support, which is incredibly ambitious, turned out to be hard to use for library writers. James Edward Gray II was probably the first to bump into this as he updated his FasterCSV library (now part of core Ruby) to handle any encoding supported by Ruby. His problems lead to a lot of discussion, and eventually to an entirely new concept inside the interpreter. And as a result, the core team have decided to slip the release of 1.9.1 by at least a month while they investigate other encoding-related issues lurking in the libraries.
In the meantime, a 1.9.1 preview has been released. Details are here.
If you are the maintainer for any publiclyavailable Ruby code (be it a Gem, an application, or whatever) I strongly urge you to download this preview. You'll be doing the community a great service in two ways. First, the various incompatibilities between 1.9 and 1.8 mean that there's a chance that your code may not work without some tweaks. Making those changes now will help others using your code. As importantly, by using 1.9.1 for real, with real code, you'll potentially discover other rough edges. Reporting these back through ruby-core or RedMine will help the Ruby developers further hone the interpreter.
Now, all this delay leaves me with a problem. The new 1.9-specific PickAxe is now content complete. Some people have been waiting for it for 10 months. And I have to decide: should I hold on for the official 1.9.1 release (which will be, at the earliest, at the end of January 2009) or should I send it to the printers? Let me know what you think.
I've reorganized the regular expression content in the new Programming Ruby, and added some cool new advanced examples. This one's fairly straightforward, but I love the fact that I can now start refactoring my more complex patterns, removing duplication.
The stuff below is an extract from the unedited update. It'll appear in the next beta. It follows a discussion of named groups, \k and related stuff.
There’s a trick which allows us to write subroutines inside regular expressions. Recall that we can invoke a named group using \g<name>, and we define the group using (?<name>...). Normally, the definition of the group is itself matched as part of executing the pattern. However, if you add the suffix {0} to the group, it means “zero matches of this group,” so the group is not executed when first encountered.
sentence = %r{
(?<subject> cat | dog | gerbil ){0}
(?<verb> eats | drinks| generates ){0}
(?<object> water | bones | PDFs ){0}
(?<adjective> big | small | smelly ){0}
(?<opt_adj> (\g<adjective>\s)? ){0}
The\s\g<opt_adj>\g<subject>\s\g<verb>\s\g<opt_adj>\g<object>
}x
md = sentence.match("The cat drinks water")
puts "The subject is #{md[:subject]} and the verb is #{md[:verb]}"
md = sentence.match("The big dog eats smelly bones")
puts "The adjective in the second sentence is #{md[:adjective]}"
sentence =~ "The gerbil generates big PDFs"
puts "And the object in the last is #{$~[:object]}"
produces:
The subject is cat and the verb is drinks
The adjective in the second sentence is smelly
And the object in the last is PDFs
We've heard back from Apple. We've double checked with the authors. And the iPhone book is in beta.
After a rocky start, I have to say we've had nothing but help and support from folks in Apple. And eventually the senior management listened to the community and did the right thing. Thanks to our friends in Apple for their help, and thanks to everyone for your support and patience.
Enjoy the book. And write some killer iPhone apps.
A great huzzah! was heard through the land. Apple today announced that they will be lifting the NDA on the iPhone SDK. This is incredibly good news, as it means that, once lifted, developers will be able to talk with each other about the iPhone. And, among those developers are those that have created iPhone content for our Core Animation and iPhone SDK Development Books, a screencast series on iPhone development, and a brand new Pragmatic Studio on iPhone Development. All of these have been sitting here, waiting to get released.
So, all day I've been getting calls and e-mails saying “The NDA is lifted. Where are the books?” The answer is simple: right now the NDA hasn't been lifted. Apple have announced that they will be dropping it, and that a new developer agreement will be sent out within "a week or so." Our developers are still apparently bound by the existing NDA.
So, I spoke with someone senior at Apple this morning, and I'm waiting to hear back. In effect, the NDA is dead. But I need to protect our authors, so we can't release any iPhone content until we hear back that they're out of danger.
I'll blog here when I know more. We'll also send out an e-mail to our announcement mailing list and RSS feed.
I've always wanted to get into Cocoa programming. I like the look and feel of a good Cocoa app, and folks I respect tell me that it's a wonderful environment. But, to be honest, I've always been somewhat put off by the way that Cocoa programming is tightly coupled to Xcode and Interface Builder. I've never really liked IDEs, simply because in the past they've felt like they're in my way.
So then Daniel Steinberg twisted my arm and got me to edit his new book, which introduces Cocoa programming to people who are already programmers in some other OO language. Trying to be a good editor, I gritted my teeth are fired up Xcode and started to follow along with his tutorial chapters. And, somewhat to my surprise, I had a working (if minimal) web browser up and running in a few minutes. I added buttons, and later a progress bar, and it all just worked. So now I've changed my opinion. Cocoa is a really well thought out framework, but the tight integration with Xcode and IB make it very, very sweet. I'm looking for an excuse to spend some serious time writing a decent-sized app with it.
In the meantime, if you're like me, and want to dip a toe into Cocoa development, I'd recommend his Cocoa Programming: A Quick-Start Guide for Developers. If you're more of a hands-on learner, the good news is that Daniel and Bill Dudney will also be running a great 3-day Cocoa Studio at the end of October. It's in the amazing Inverness facility in Denver (which I'm at right now, teaching a Rails Studio with Chad).
Currying is the ability to take a function that accepts n parameters and generate from it one of more functions with some parameter values already filled in. In RUby 1.9, you create a curry-able proc by calling the curry method on it. If you subsequently call this curried proc with fewer parameters than it expects, it will not execute. Instead, it returns a new proc with those parameters already bound.
Let's look at a trivial example. Here's a proc that simply adds two values:
plus = lambda {|a,b| a + b}
puts plus[1,2]
I'm using the [ ] syntax to invoke the proc with arguments, in this case 1 and 2. The code will print 3.
Now let's have some fun.
curried_plus = plus.curry
# create two procs based on plus, but with the first parameter
# already set to a value
plus_two = curried_plus[2]
plus_ten = curried_plus[10]
puts plus_two[3]
puts plus_ten[3]
On line 1, I create a curried version of the plus proc. I then call it twice, but both times I only pass it one parameter. This means it cannot execute the body. Instead, each time it returns a new proc which is like the original, but which has the first parameter preset to either 2 or 10. In the last two lines, I call these two new procs, supplying the missing parameter. This means they can execute normally, and the code outputs 5 and 13.
You can have a lot of fun with currying, but that's not why we're here today.
Over the weekend, Matz added a new method to the Proc class. You can now use Proc#=== as an alias for Proc.call. So, why on earth would you want to do that? Well, remember that === is used to match terms in a case statement. Over of the AimRed blog, they noted that this feature could be used to make the matching in case statements actually execute code. In their example, they manually added the === method to class Proc
class Proc
def ===( *parameters )
self.call( *parameters )
end
end
Then you can write something like
sunday = lambda{ |time| time.wday == 0 }
monday = lambda{ |time| time.wday == 1 }
# and so on...
case Time.now
when sunday
puts "Day of rest"
when monday
puts "work"
# ...
end
See how that works? As Ruby executes the case statement, it looks at each of the parameters of the when clauses in turn. For each, it invokes its === method, passing that method the original case discriminator (Time.now in this example). But with the new === method in class Proc, this will now execute the proc, passing it Time.now as a parameter.
While updating the PickAxe, I noticed that Matz liked this so much that it is now part of 1.9. And it means we can combine this trick with currying to write some fun code:
is_weekday = lambda {|day_of_week, time| time.wday == day_of_week}.curry
sunday = is_weekday[0]
monday = is_weekday[1]
tuesday = is_weekday[2]
wednesday = is_weekday[3]
thursday = is_weekday[4]
friday = is_weekday[5]
saturday = is_weekday[6]
case Time.now
when sunday
puts "Day of rest"
when monday, tuesday, wednesday, thursday, friday
puts "Work"
when saturday
puts "chores"
end
Is this incredibly efficient? Not really :) But it opens up quite an interesting set of possibilities.
Programming is a creative activity. And, like most creative people, programmers occasionally succumb to writer's block. You'll sit there, spinning your wheels, trying random stuff, and knowing that you're not really getting anywhere.
I've been experiencing this feeling now in a different sphere. I've been taking music lessons for some months now, and recently blogged my first composition (or, at least, the first I was prepared to let out into the wild).
Flush with success, I launched into my next piece. I envisaged it being a set of three pieces set in a run-down dance studio. (Don't ask why, it just seemed to fit the mood.) The first section was 5/4 and fairly upbeat. The second section was 3/4, and was deliberately clumsy (I saw partners who couldn't quite get it together), and the last section was 4/4, and knitted things together.
At least that was the vision. I spent weeks on this thing. I had some great themes. But I just couldn't see my way through to the end. Every lesson I'd come in with some changes, and by the end I'd argue myself out of them.
Now I've been coaching developers for a while now. And I know what to suggest when some programmer reaches this kind of state. But for some reason it didn't occur to me to apply the same advice to myself. It took my teacher to say “stop working on this for a while, and go do something fun.” He gave me an assignment. Choose a simple melody and arrange it. Come back with it finished the next week.
In the end, it was great fun. It only took an hour or so, and it totally cleared my mind. I came back triumphantly the next week with something actually finished, and it felt good.
And then, I found I could get back to the more complex piece. In fact, the first time I sat down to it, I was having so much fun I went of in a totally different direction, and I'm now trying something kind of wild. More on that later...
So, if you're finding yourself blocked—if you're going around in circles, or if everything you do you end up throwing away—STOP. Go do something else. Something simple. Something fun. Clear your mind, and remember what it is to enjoy your work.
(And, if you're interested, the fluff piece that cleared my logjam is an arrangement of Shenandoah: transcript and below, played by Mike Springer.)
(Update: Chris Morris took this piece of fluff and turned it into something amazing. I think there are about three notes of mine in there somewhere...)
