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 mp3 [played by Mike Springer].)
In the previous post I mentioned the epub format in passing, saying it also had issues. However, I didn't bother to qualify that, nor did I give an epub sample.
When I went back to create the sample, I discovered that the 1.5 release of Adobe Digital Editions no longer worked with the epubs generated by our toolchain (and, by no longer worked, I mean looped-burning-up-CPU-until-crashing no longer worked—DE is a remarkably fragile piece of software.)
Anyway, I fixed that up (and, in the process, discovered that while id="fig:one" should be perfectly valid xhtml, epubcheck and DE both say not. Sigh).
So, here's the complete list of the versions of that sample chapter.
In .mobi format (which is suitable for the Kindle—just copy it to your Kindle's documents folder). You'll want to right-click and "Save As" to download this link.
In .epub format (which I've only tested in DE). Again, you'll want to right-click and "Save As" to download this link.
epub is clearly better than mobi for formatting, but still has issues. But, I thought I'd post them all here for comparison purposes.
About once a week, we get a request from a reader to have our books available in a format that can be read on an eBook reader (typically, nowadays, the Amazon Kindle).
In fact, we've had a prototype form of that capability for a while now, but we've always held back. Frankly, we didn't think the devices worked well with our kind of content. Basically, the .mobi format used by the Kindle is optimized for books that contain just galleys of text with the occasional heading. Throw in tables, monospaced code listings, sidebars and the like, and things start to get messy. The .epub format (used, for example, by Adobe Digital Editions) is slightly more capable, but it also has issues.
Last week, I reopened the can of worms and tried a quick hack. Rather than render code as text, I now create individual graphics files for each code listing, and embed those in the file eBook. The result is a lot better, but still has some drawbacks:
the code doesn't scale when you scale the font size of the body text
the code gets chopped off a the right margin
code listings can't be longer than a page
the fonts are not as readable as they would have been as text, as we don't get the pixel-level control you get with native fonts.
However. even if the display code problem is (kinda) fixed, we still can't have code fonts (or any other font) inside paragraphs. And we have issues with sidebars and tables.
So, here's the question. Given all these limitations, should we go ahead and publish eBook formats alongside our PDF formats? (If we did, a single purchase would get you access to all formats.) To help you decide, here's an (unedited) chapter from Stripes: ...and Java web development is fun again:
In .mobi format (which is suitable for the Kindle—just copy it to your Kindle's documents folder). You'll want to right-click and "Save As" to download this link.
If you don't have access to a Kindle, I put some screenshots down below. The last 3 show what code listings look like.
So... what do you think. Is this workable? Should we make these available, even though they're not very good, or should we wait for a later generation of eBook that's closer to the capabilities we need? Comments are open... :)
Cheers
Dave
Sample Kindle pages—click each for a full size version.
So, it's been a week. The iPhone 3G was released, and the iPhone 2.0 software upgrade shipped. We can now all write applications that will run on what is undeniably a cool platform. You can even download the iPhone SDK for free.
We love Apple stuff. Andy and I both run Macs as our main machines (at last count, I have 8 Macs in my home). When the App Store was announced, we were keen to spread the word. We have a new book on iPhone software development. We have a brand new section in Bill Dudney's Core Animation book. And Mike Clark has a set of screencasts on how to write code for the little fella.
And we can't show you any of them.
Why? Because in order to get the iPhone SDK, you have to agree to the terms and conditions—you know, that standard box of legalese that you skip over before pressing I AGREE. Except, in this case, the legalese has some unfortunate consequences. For example, it says:
3. Confidentiality. As a Registered iPhone Developer, you may be receiving information from Apple. You agree that all information disclosed by Apple to you that relates to Apple's products, designs, business plans, business opportunities, finances, research, development, know-how, personnel, or third-party confidential information, will be considered and referred to collectively as "Confidential Information." ..... You agree not to disclose, publish, or disseminate any Confidential Information to anyone other than to other Registered iPhone Developers who are employees and contractors working for the same entity as you and then only to the extent that Apple does not otherwise prohibit such disclosure in this Agreement. Except for your authorized purposes as a Registered iPhone Developer, you agree not to use Confidential Information in any way, including, without limitation, for your own or any third party's benefit without the prior written approval of an authorized representative of Apple in each instance.
Then, later on, it says
10. Use Of Apple Trademarks, Logos, etc. You agree to follow Apple's Guidelines For Using Apple Trademarks and Copyrights as published on Apple's website at www.apple.com/legal/guidelinesfor3rdparties.html and as may be modified from time to time. You agree not to use the marks "Apple," the Apple Logo, "iPhone," "iPod touch" or any other marks belonging or licensed to Apple in any way except as expressly authorized in writing by Apple in each instance.
So, to write a book about the iPhone SDK, you have to download it. In order to download it, you have to accept the agreement. And the agreement says that the download will contain confidential information that you can't pass on to third parties. That makes it hard to publish the book. And, if that wasn't enough, it also appears that you can't even use the word "iPhone" (for example, in a book title).
We'd hoped these restrictions would be lifted at the announcement of the 3G. They weren't. We'd hoped they'd be lifted when the 2.0 software shipped last week. They weren't. We'd heard rumors they'd be lifted on July 14th. They weren't. And, what's worse, we can't pin down anyone who'll tell us just what is going on.
We're not the only people in this particular boat. Manning, for example, has an iPhone development book. They've published the part on doing web-based iPhone development (using the iPhone as a browser), but they're having to hold back the SDK-related material.
So, here's where you can help. If you work for Apple, and have any ideas on who we can contact to find out what's going on, we'd really appreciate knowing. We'll keep your personal information confidential. Just drop me an e-mail at dave@pragprog.com.
