Planet Ruby

Ola Bini: ThoughtWorks comes to Sweden

Ola Bini — 2008-05-16T23:00:35+00:00

I few months back I blogged about the possibility that ThoughtWorks would come to Sweden. Well, this is now reality. I have the extreme honor to be a part of this initiative together with Marcus Ahnve (who blogged about it here). If you read that blog you will know that Marcus will head the Swedish operation. I am immensely happy about having him as my new colleague and also boss. =)

People might ask what my role in this new office will be. That's a valid question. My main goal is to stay out of trouble - and trying my very best to not scare potential customers away. Marcus is extremely capable and will handle all challenges, which means that I'll do my best to bask in the glory of opening an new office. I might also have a hand in any billable work we do, and help out with recruitment and possibly even (shudder) marketing.

Not sure if you catched the meaning in that last sentence, but let me spell two points out. We will be selling work in Sweden from day one. I will be one of the consultants sold and that means that if you have an Ruby or JRuby work you want to start up, this might be an excellent time to call your local ThoughtWorks office... =)

The recruitment point is simply this. We plan on accumulating the best people we can find - as we aim to do in every country we enter. If you feel like you could fit this bill, mail me and we can talk.

It's important to note that this operation will initially be very low profile. Don't expect center folds in DN's Economy pages. We will work mostly with word-of-mouth. So if you hear of someone that might need our help, don't hesitate to mention our name. And even though we are low profile, we will still have the resources of the whole company to draw on. A 1000 ThoughtWorkers. That feels rather good, and it should feel even better for any prospective clients.

One thing I have been a bit worried about is my commitment to JRuby, and other open source projects. I assure everyone I'll do my best to live up to these commitments. Sleep be damned!

These are exciting times. I for one is looking forward to it very much. Me and Marcus will officially start on this from June this year. Get in touch if you have any questions. It's my name separated with dots at gmail, or obini at the official thoughtworks domain.

Dave Thomas: Our take on presenting code

2008-05-16T22:58:21+00:00

Back in March, Jim Weirich posted some notes on a clever technique for getting code into Keynote presentations. It struck a chord with me, because I've been suffering the same problem for a long time now. Eventually, the pain of putting together the Studio content with Mike Clark and Chad Fowler drove me to find a solution. (The pain wasn't working with Mike and Chad—it was creating and keeping up to date many hundreds of slides, most of which contained code.)

The solution we went with was based on the way we do code in the Bookshelf books. Rather than embedding the code in the slides, we write regular old programs. Then, in the slide material, we reference the source file (and optionally say which section of that source file), and the appropriate code gets dragged into the slide, syntax highlighted, and hyperlinked back to our editor. Here's how it works.

Create Your Material

We've given up using Keynote and Powerpoint. They're a pain with version control, and they make it easy to fall into the eye-candy trap, favoring glitz over content. Instead, we create our material is plain text files using Textile markup. Typically we use one file per major topic, and the use an index file to bring all these individual files together into a single overall presentation/

Within the material, we can include material from external files using the :code directive.

Here's the source for an individual slide:

h1. const_missing
Correctly handles nested modules
:code code/meta/const_missing.rb

and here's what appears on the screen:

The code gets inserted onto the slide and is syntax highlighted. The blue text below the box shows the file name (so attendees can find it in their collateral material). It's also a txmt: hyperlink—click it and the file opens in Textmate, so we can edit and run it.

Using Parts of a Source File

You often just want to show part of a larger source file. We do that by including START:tag and END:tag comments in the original source. (This works in any language, and not just Ruby source). In the slide markup, you indicate the part(s) you want to include in square brackets after the file name:

h1. method_missing

:code code/meta/my_ostruct.rb[impl class=code-small]

This says to look at the source file code/meta/my_ostruct.rb and only include on the slide the stuff between START:impl and comments. We'll also display it using the CSS class code-small.

The ability to include parts of code is invaluable when you're doing a sequence of slides that builds a solution: you can show each part of a source file in turn.

Building the Presentation

The toolchain that takes all this is remarkably simple, because most of the work is done for us. We use a simple Ruby script that takes our original slides, embeds the source code from external files, and then runs Textile to produce an HTML version. We then add a header to that HTML that drags in two incredibly useful Javascript libraries.

For the presentation itself, we use Eric Meyer's S5 system. It gives us nice looking slides, simple to use navigation, and lets us present in our own browsers or (potentially) on our students'.

For the syntax highlighting of code, we use SyntaxHighlighter. This clever piece of code doesn;t require you to mark up the code elements inthe HTML. Instead you just flag your <pre> blocks with an appropriate class and it does the parsing and highlighting in the browser. It means that really large decks can be a little slow to load (but the still beat Keynote on elaspsed time), but it also means your HTML is really clean.

Finally, we have a Rake task that lets us built the whole presentation or just individual chapters.

The whole thing took about 4 hours to get working, and probably another 4 hours on and off to tweak it based on experience. The code's not really in a state that can be released (so please don't ask), but it wouldn't take much to produce something you could do the same with.

It Actually Works in Practice!

So far, we've done two studios using this stuff (Advanced Ruby and Erlang), and I've used it in a number of conference presentations. I wouldn't switch back to regular presentation software for any code-based talk. (I'll still use Keynote for non-code slides, though.)

A Few More Slides

Here's the source:

h1. initialize_copy

Container wrappers such a OStruct have a potential problem

:code code/meta/my_ostruct_problem.rb[class=code-small]

h1. initialize_copy
:code code/meta/my_ostruct_ic.rb[impl class=code-small]

h1. const_missing
* Module method whenever undefined constant references in that module
** (Module is a module, and acts as a global place for @const_missing@)
* Mostly used to autoload classes
* Not as easy as it looks (Rails' @dependencies.rb@ is 500 lines long)

h1. const_missing
:code code/meta/const_missing_autoload.rb[class=code-small]

And here are the resulting slides:

Ola Bini: Dynamically created methods in Ruby

Ola Bini — 2008-05-15T15:45:00+00:00

There seems to be some confusion with regards to dynamically defining methods in Ruby. I thought I'd take a look at the three available methods for doing this and just quickly note why you'd use one method in favor of another.

Let's begin by a quick enumeration of the available ways of defining a method after the fact:

Using a def
Using define_method
Using def inside of an eval

There are several things to consider when you dynamically define a method in Ruby. Most importantly you need to consider performance, memory leaks and lexical closure. So, the first, and simplest way of defining a method after the fact is def. You can do a def basically anywhere, but it needs to be qualified if you're not immediately in the context of a module-like object. So say that you want to create a method that returns a lazily initialized value, you can do it like this:

class Obj
  def something
   puts "calling simple"
    @abc = 3*42
    def something
     puts "calling memoized"
     @abc
    end
   something
  end
end

o = Obj.new
o.something
o.something
o.something

As you can see, we can use the def keyword inside of any context. Something that bites most Ruby programmers at least once - and more than once if they used to be Scheme programmers - is that the second def of "something" will not do a lexically scoped definition inside the scope of the first "something" method. Instead it will define a "something" method on the metaclass of the currently executing self. This means that in the example of the local variable "o", the first call to "something" will first calculate the value and then define a new "something" method on the metaclass of the "o" local variable. This pattern can be highly useful.

Another variation is quite common. In this case you define a new method on a specific object, without that object being the self. The syntax is simple:

def o.something
 puts "singleton method"
end

This is deceptively simple, but also powerful. It will define a new method on the metaclass of the "o" local variable, constant, or result of method call. You can use the same syntax for defining class methods:

def String.something
 puts "also singleton method"
end

And in fact, this does exactly the same thing, since String is an instance of the Class class, this will define a method "something" on the metaclass of the String object. There are two other idioms you will see. The first one:

class << o
  def something
   puts "another singleton method"
  end
end

does exactly the same thing as

def o.something
 puts "another singleton method"
end

This idiom is generally preferred in two cases - first, when defining on the metaclass of self. In this case, using this syntax makes what is happening much more explicit. The other common usage of this idiom is when you're defining more than one singleton method. In that case this syntax provide a nice grouping.

The final way of defining methods with def is using module_eval. The main difference here is that module_eval allows you to define new instance methods for a module like object:

String.module_eval do
  def something
   puts "instance method something"
  end
end

"foo".something

This syntax is more or less equivalent to using the module or class keyword, but the difference is that you can send in a block which gives you some more flexibility. For example, say that you want to define the same method on three different classes. The idiomatic way of doing it would be to define a new module and include that in all the classes. But another alternative would be doing it like this:

block = proc do
  def something
   puts "Shared something definition"
  end
end

String.module_eval &block
Hash.module_eval &block
Binding.module_eval &block

The method class_eval is an alias for module_eval - it does exactly the same thing.

OK, so now you know when the def method can be used. Some important notes about it to remember is this: def does _not_ use any enclosing scope. The method defined by def will not be a lexical closure, which means that you can only use instance variables from the enclosing running environment, and even those will be the instance variables of the object executing the method, not the object defining the method. My main rule is this: use def whenever you can. If you don't need lexical closures or a dynamically defined name, def should be your default option. The reason: performance. All the other versions are much harder - and in some cases impossible - for the runtimes to improve. In JRuby, using def instead of define_method will give you a large performance boost. The difference isn't that large with MRI, but that is because MRI doesn't really optimize the performance of general def either, so you get bad performance for both.

Use def unless you can't.

The next version is define_method. It's just a regular method that takes a block that defines that implementation of the method. There are some drawbacks to using define_method - the largest is probably that the defined method can't use blocks, although this is fixed in 1.9. Define_method gives you two important benefits, though. You can use a name that you only know at runtime, and since the method definition is a block this means that it's a closure. That means you can do something like this:

class Obj
def something
  puts "calling simple"
  abc = 3*42
  (class <<self; self; end).send :define_method, :something do
    puts "calling memoized"
    abc
  end
  something
end
end

o = Obj.new
o.something
o.something
o.something

OK, let this code sample sink in for a while. It's actually several things rolled into one. They are all necessary though. First, note that abc is no longer an instance variable. It's instead a local variable to the first "something" method. Secondly, the funky looking thing (class

class Obj
def something
  puts "calling simple"
  abc = 3*42
  class << self
    define_method :something do
      puts "calling memoized"
      abc
    end
  end
  something
end
end

o = Obj.new
o.something
o.something
o.something

Well, it's a good thought. The problem is that it won't work. See, there are a few keywords in Ruby that kills lexical closure. The class, module and def keywords are the most obvious ones. So, the reference to abc inside of the define_method block will actually not be a lexical closure to the abc defined outside, but instead actually cause a runtime error since there is no such local variable in scope. This means that using define_method in this way is a bit cumbersome in places, but there are situations where you really need it.

The second feature of define_method is less interesting - it allows you to have any name for the method you define, including something random you come up with at runtime. This can be useful too, of course.

Let's summarize. The method define_method is a private method so it's a bit problematic to call, but it allows you to define methods that are real closures, thus providing some needed functionality. You can use whatever name you want for the method, but this shouldn't be the deciding reason to use it.

There are two problems with define_method. The first one is performance. It's extremely hard to generally optimize the performance of invocation of a define_method method. Specifically, define_method invocations will usually be a bit slower than activating a block, since define_method also needs to change the self for the block in question. Since it's a closure it is harder to optimize for other reasons too, namely we can never be exactly sure about what local variables are referred to inside of the block. We can of course guess and hope and do optimistic improvements based on that, but you can never get define_method invocations are fast as invoking a regular Ruby method.

Since the block sent to define_method is a closure, it means it might be a potential memory leak, as I documented in an older blog post. It's important to note that most Ruby implementations keep around the original self of the block definition, as well as the lexical context, even though the original self is never accessible inside the block, and thus shouldn't be part of the closed environment. Basically, this means that methods defined with define_method could potentially leak much more than you'd expect.

The final way of defining a method dynamically in Ruby is using def or define_method inside of an eval. There are actually interesting reasons for doing both. In the first case, doing a def inside of an eval allows you to dynamically determine the name of the method, it allows you to insert any code before or after the actual functioning code, and most importantly, defining a method with def inside of eval will usually have all the same performance characteristics as a regular def method. This applies for invocation of the method, not definition of it. Obviously eval is slower than just using def directly. The reason that def inside of an eval can be made fast is that at runtime it will be represented in exactly the same way as a regular def-method. There is no real difference as far as the Ruby runtime sees it. In fact, if you want to, you can model the whole Ruby file as running inside of an eval. Not much difference there. In particular, JRuby will JIT compile the method if it's defined like that. And actually, this is exactly how Rails handles potentially slow code that needs to be dynamically defined. Take a look at the rendering of compiled views in ActionPack, or the route recognition. Both of these places uses this trick, for good reasons.

The other one I haven't actually seen, and to be fair I just made it up. =) That's using define_method inside of an eval. The one thing you would gain from doing such a thing is that you have perfect control over the closure inside of the method defined. That means you could do something like this:

class BinderCreator
 def get
   abc = 123
   binding
 end
end

eval(<<EV, BinderCreator.new.get)
  Object.send :define_method, :something do
   abc
 end
EV

In this code we create a new method "something" on Object. This method is actually a closure, but it's an extremely controller closure since we create a specific binding where we want it, and then use that binding as the context in which the define_method runs. That means we can return the value of abc from inside of the block. This solution will have the same performance problems as regular define_method methods, but it will let you control how much you close over at least.

So what's the lesson? Defining methods can be complicated in Ruby, and you absolutely need to know when to use which one of these variations. Try to avoid define_method unless you absolutely have to, and remember that def is available in more places than you might think.

Ola Bini: A New Hope: Polyglotism

Ola Bini — 2008-05-15T15:33:56+00:00

OK, so this isn't necessarily anything new, but I had to go with the running joke of the two blog posts this post is more or less a follow up to. If you haven't already read them, go read Yegge's Dynamic Languages Strikes Back, and Beust's Return Of The Statically Typed Languages.

So let's see. Distilled, Steve thinks that static languages have reached the ceiling for what's possible to do, and that dynamic languages offer more flexibility and power without actually sacrificing performance and maintainability. He backs this up with several research papers that point to very interesting runtime performance improvement techniques that really can help dynamic languages perform exceptionally well.

On the other hand Cedric believes that Scala is bad because of implicits and pattern matching, that it's common sense to not allow people to use the languages they like, that tools for dynamic languages will never be as good as the ones for static ones, that Java generics isn't really a problem, that dynamic language performance will improve but that this doesn't matter, that static languages really hasn't failed at all and that Java is still the best language of choice, and will continue to be for a long time.

Now, these two bloggers obviously have different opinions, and it's really hard to actually see which parts are facts and which are opinions. So let me try to sort out some facts first:

Dynamic language have been around for a long time. As long as statically typed languages in fact. Lisp was the first one.

There have been extremely efficient dynamic language implementations. Some of the Common Lisp implementations are on par with C performance, and Strongtalk also achieved incredible numbers. As several commenters have noted, Strongtalks performance did not come from the optional type tags.

All dynamic languages in large use today are not even on the same map with regards to performance. There are several approaches to fixing these, but we can't know how well they will work out in practice.

Java's type system is not very strong, and not very static, as these definitions go. From a type theoretic stand point Java does not offer neither static type safety nor any complete guarantees.

There is a good reason for these holes in Java. In particular, Java was created to give lots of hints to the compiler so the compiler can catch errors where the programmer is insoncistent. This is one of the reasons that you very often find yourself writing the same type name twice, including the type name arguments (generics). If the programmer makes a mistake at one side, the compiler will be able to catch this error very easily. It is a redundancy in the syntax that makes Java programs very verbose, but helps against certain kinds of mistakes.

Really strong type systems like those Haskell and OCaML use provide extremely strong compile time guarantees. This means that if the compiler accepts your program, you will never see any runtime errors from the type system. This allows these compilers to generate very efficient code, because they know more about the state of the application at most points in time, compared to the compiler for Java, which knows some things, but not nearly as much as Haskell or OCaML.

The downside of really strong type systems is that they disallow some extremely common expressions - these are things you intuitively can imagine, but it can't be expressed within the constraints of such a type system. One solution to these problems is to add higher kinds, but these have a tendency to create more complexity and also suffer from some of the same problems.

So, we have three categories of languages here. The strongly statically checked ones, like Haskell. The weakly statically checked ones, like Java. And the dynamically checked ones, like Ruby. The way I look at these, they are good at very different things. They don't even compete in the same leagues. And comparing them is not really a valid point of reasoning. The one thing that I am totally sure if is that we need better tools. And the most important tool in my book is the language. It's interesting, many Java programmers talk so much about tools, but they never seem to think about their language as a tool. For me, the language is what shapes my thinking, and thus it's definitely much more important than which editor I'm using.

I think Cedric have a point in that dynamic language tool support will never be as good as those for statically typed languages - at least not when you're defining "good" to be the things that current Java tools are good at. Steve thinks that the tools will be just as good, but different. I'm not sure. To a degree I know that no tool can ever be completely safe and complete, as long as the language include things like external configuration, reflection and so on. There is no way to include all dynamic aspects of Java, but using the common mainstream parts of the language will give you most of these. As always this is a tradeoff. You might get better IDE support for Java right now, but you will be able to express things in Ruby that you just can't express in Java because the abstractions will become too large.

This is the point where I'm going to do a copout. These discussions are good, to the degree that we are working on improving our languages (our tools). But there is a fuzzy line in these discussions, where you end up comparing apples and oranges. These languages are all useful, for different things. A good programmer uses his common sense to provide the best value possible. That includes choosing the best language for the job. If Ruby allows you to provide functionality 5 times faster than the equivalent functionality with Java, you need to think about whether this is acceptable or not. On the one hand, Java has IDEs that make maintainability easier, but with the Ruby codebase you will end up maintaining a fifth of the size of the Java code base. Is that trade off acceptable? In some cases yes, in some cases no.

In many cases the best solution is a hybrid one. There is a reason that Google allows more than one language (C++, Java, Python and JavaScript). This is because the languages are good at different things. They have different characteristics, and you can get a synergistic effect by combining them. A polyglot system can be greater than the sum of it's parts.

I guess that's the message of this post. Compare languages, understand your most important tools. Have several different tools for different tasks, and understand the failings of your current tools. Reason about these failings in comparison to the tasks they should do well, instead of just comparing languages to languages.

Be good polyglot programmers. The world will not have a new big language again, and you need to rewire your head to work in this environment.

Ola Bini: Would Type Inference help Java

Ola Bini — 2008-05-15T15:32:34+00:00

My former colleague Lars Westergren recently posted a blog (here) about type inferencing, posing the question whether type inference would actually be good for Java, and if it would provide any benefits outside of just "less typing".

In short: no. Type inferencing would probably not do much more than save you some typing. But how much typing it would save you could definitely vary depending on the type of type inference you added. The one version I would probably prefer is just a very simple hack to avoid writing out the generic type arguments. One simple way of doing that would be to allow an equals sign inside of the angle brackets. In that case you could do this:

List<=>      l  = new ArrayList<String>();
List<String> l2 = new ArrayList<=>();

Of course, you can do it on more complicated expressions:

List<Set<Map<Class<?>, List<String>>>> l = new ArrayList<=>();

This would save us some real pain in the definition of genericized types, and it wouldn't strip away much stuff you need for readability. In the above examples it would just strip away one duplication, and you don't need that duplication to read it correctly. The one case where it might be a little bit harder to read would be if you defined a variable and assigned it somewhere else. In that case the definition would need to carry the type information, so the instantiation would use the => syntax. I think that would be an acceptable price to reduce the verbosity of Java generics.

Another kind of generics that would be somewhat useful is the kind added to C#, which is only local to a scope. That means there will be no type inferencing of member variables, method parameters or return values. Of course, that's the crux of Lars question, since this kind of type inference potentially removes ALL type information in the current text, since you can do:

var x = someValue.DoSomething();

At this point there is no easy way for you to know what the type of x actually is. Reading it like this, it looks a bit frightening if you're used to Java type tags, but in fact this is not what you would see. In most cases you have a small method - maybe 5-15 lines of code, where x is being used in some way or another. In many cases you will see methods called on x, or x used as argument to method calls. Both of these usages gives you clues about what it might be, but in fact you don't always need to know what type it is. You just need to know what you can do with it. And that's exactly what Java interfaces represent. So for example, do you know what class you get back from Collections.synchronizedMap()? No, and you shouldn't need to know. What you do know is that it's something that implements Map, and the documentation says that it is synchronized, but that is it. The only thing you know about it is that you can use it as a map.

So in practice, the kind of type inference C# adds is actually quite useful, clean, and doesn't cause too much trouble - especially if you have one of those fancy ideas that do method completion... =)

From another angle, there are some things that type inference could possible do, but that you will never see in Java. For example, say that you assign a variable to something, and later you assign that variable to some other value. If these two values are distinct types that doesn't overlap in the inheritence chain, you will usually get an error. But if you have an advanced type system, it will do unification for you. The basic versions will just find the most common supertype (the disjunction), but you can also imagine the compiler injecting a new type into your program that is the union of the two types in use. This will provide something similar to duck typing while still retaining some static type safety. If your type system allows multiple inheritence, the synthetic union type might even be a subclass of both the types in question.

So yeah. The long answer is that you can actually do some funky stuff with type inference that doesn't immediately translate to less typing. Although less typing and better abstractions is what programming languages are all about, right? Otherwise assembler provides everything we want.

Jim Weirich: Test Driven Studio in June 2008

2008-05-15T13:30:58+00:00

Joe O’Brien and I will be leading another Test Driven Studio in Denver, June 9-11.

Testing, Colorado, June … What’s not to like?

About 8 years ago I come upon a technique that radically changed the way I developed code. I was reading Martin Fowler’s “Refactoring” book and came across this paragraph:

“Whenever I do refactoring, the first step is always the same. I need to build a solid set of tests for that section of code. The test are essential because even though I follow refactorings structured to avoid most of the opportunities for introducing bugs, I’m still human and still make mistakes. Thus I need solid tests.” —Martin Fowler

Chapter 4 of “Refactoring” was my first introduction to JUnit and got me interested in “Test First Design” (what we now tend to call “Test Driven Development”). Although I wrote good code before, the onfidence I had in my code took a dramatic leap forward after I started adopting TDD practices.

On June 9 through 11, Joe O’Brien and I will have the pleasure of leading the next Pragmatic Programmer’s Test-Driven Development with Rails Studio. in Denver. We will have an opportunity to share with you some of our experiences in using TDD with Ruby and Rails.

There are still seats available, so its not too late to sign up. More information is available here.

Dave Thomas: Silly Useful shoulda trick

2008-05-15T04:52:39+00:00

Playing with the shoulda testing framework, I came across a small but useful trick. Because the tests are written inside closures, local class variables are available inside should blocks. They're only evaluated once, so they don't take the place of setup blocks, but they are a nice way of storing test-wide values. Somehow, I like the look of this better than using instance variables or constants—the tests seem to be more uniform and balanced.

/* Stylesheet generated from TextMate theme * * Slush & Poppies * * */ pre.textmate-source { margin: 0; padding: 0 0 0 2px; font-family: Monaco, monospace; font-size: 11px; line-height: 1.3em; word-wrap: break-word; white-space: pre; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -o-pre-wrap; } pre.textmate-source.slush_poppies { color: #000000; background-color: #F1F1F1; } pre.textmate-source .linenum { width: 75px; padding: 0.1em 1em 0.2em 0; color: #888; background-color: #eee; } pre.textmate-source.slush_poppies span { padding-top: 0.2em; padding-bottom: 0.1em; } pre.textmate-source.slush_poppies ::selection { background-color: #B0B0FF; } /* Comment */ pre.textmate-source.slush_poppies .comment { color: #406040; } /* String */ pre.textmate-source.slush_poppies .string { color: #C03030; } /* Number */ pre.textmate-source.slush_poppies .constant_numeric { color: #0080A0; } /* OCaml floating-point constants */ pre.textmate-source.slush_poppies .source_ocaml .constant_numeric_floating-point { text-decoration: underline; } /* Character constants */ pre.textmate-source.slush_poppies .constant_character { color: #800000; } /* Built-in constant */ pre.textmate-source.slush_poppies .constant_language { } /* User-defined constant */ pre.textmate-source.slush_poppies .constant_character, pre.textmate-source.slush_poppies .constant_other { } /* Variable */ pre.textmate-source.slush_poppies .variable_parameter, pre.textmate-source.slush_poppies .variable_other { } /* Keyword */ pre.textmate-source.slush_poppies .keyword { color: #2060A0; } /* Operators */ pre.textmate-source.slush_poppies .keyword_operator { color: #2060A0; } /* OCaml prefix f-p operators */ pre.textmate-source.slush_poppies .source_ocaml .keyword_operator_symbol_prefix_floating-point { text-decoration: underline; } /* OCaml infix f-p operators */ pre.textmate-source.slush_poppies .source_ocaml .keyword_operator_symbol_infix_floating-point { text-decoration: underline; } /* Module Keyword */ pre.textmate-source.slush_poppies .entity_name_module, pre.textmate-source.slush_poppies . .support_other_module { color: #0080FF; } /* Storage types */ pre.textmate-source.slush_poppies .storage_type { color: #A08000; } /* Storage */ pre.textmate-source.slush_poppies .storage { color: #008080; } /* Variant types */ pre.textmate-source.slush_poppies .entity_name_class_variant { color: #C08060; } /* Directives */ pre.textmate-source.slush_poppies .keyword_other_directive { font-weight: bold; } /* Line-number directives */ pre.textmate-source.slush_poppies .source_ocaml .keyword_other_directive_line-number { } /* Inherited class */ pre.textmate-source.slush_poppies .entity_other_inherited-class { } /* Function name */ pre.textmate-source.slush_poppies .entity_name_function { color: #800000; } /* Type name */ pre.textmate-source.slush_poppies .storage_type_user-defined { color: #800080; } /* Class type name */ pre.textmate-source.slush_poppies .entity_name_type_class_type { color: #8000C0; } /* Function argument */ pre.textmate-source.slush_poppies .variable_parameter { } /* Tag name */ pre.textmate-source.slush_poppies .entity_name_tag { } /* Tag attribute */ pre.textmate-source.slush_poppies .entity_other_attribute-name { } /* Library function */ pre.textmate-source.slush_poppies .support_function { } /* Library constant */ pre.textmate-source.slush_poppies .support_constant { } /* Library class/type */ pre.textmate-source.slush_poppies .support_type, pre.textmate-source.slush_poppies .support_class { } /* Library variable */ pre.textmate-source.slush_poppies .support_variable { } /* Invalid */ pre.textmate-source.slush_poppies .invalid { }

require 'test/unit'
require 'shoulda'
require 'date' 

require 'csv_to_html/age_calculator'

class AgeCalculatorTest < Test::Unit::TestCase
                                  
  birth = Date.parse("2003-05-02")

  should "be year difference if now later in year than birth" do
    now = Date.parse("2008-06-15")
    assert_equal 5, AgeCalculator.age_given_dates(now, birth)
  end

  should "be year difference if now later in month than birth" do
    now = Date.parse("2008-06-15")
    assert_equal 5, AgeCalculator.age_given_dates(now, birth)
  end
         
  should "be year difference minus 1 if now earlier in year than birth" do
    now = Date.parse("2008-04-15")
    assert_equal 4, AgeCalculator.age_given_dates(now, birth)
  end

  should "be year difference minus 1 if now earlier in month than birth" do
    now = Date.parse("2008-05-01")
    assert_equal 4, AgeCalculator.age_given_dates(now, birth)
  end

end

err.the_blog: Who Needs an API?

PJ — 2008-05-15T02:19:29+00:00

GitHub is a pretty fun site to work on, I’m not gonna lie. On more than one occasion, we thought it would be pretty cool to setup a service allowing public projects to receive donations.

Sounds like an Itch

Pledgie being the venerable service it is, I decided one night it couldn’t possibly be that hard to integrate it with GitHub. It’s a pretty standard Rails site with some simple forms to make the magic happen (eg. setup a donation page).

They don’t have an API (yet), but in this day and age, you really don’t need one if you procure the proper tools.

Enter Mechanize. You can do all I’m about to describe with just Net::HTTP, but seriously, who wants to do that?

Start Scratching

Step 0: Drive girlfriend to airport, buy a case of Anchor Steam, and turn off the Xbox.

Step 1: Sign up for a Pledgie account, cause GitHub’s a regular user after all.

Step 2: Write the interface on GitHub to accept the user’s Paypal address.

Step 3: Figure out the form fields I should be filling out to login and create a new pledge on Pledgie.

Step 4: Write the Mechanize code:

def pledgify(email)
  agent = WWW::Mechanize.new
  page  = agent.get('http://pledgie.org/accounts/login')
  form  = page.forms[1]
  form['account[login]']    = GitHub::PledgieUser
  form['account[password]'] = GitHub::PledgiePass
  page  = agent.submit(form)

  link  = page.links.text(/Create A Campaign/)
  page  = agent.click(link)
  form  = page.forms[1]
  form['campaign[title]']        = "FooBarz" 
  form['campaign[paypal]']       = email
  form['campaign[description]']  = "The best project evar!" 
  form['campaign[end_date(1i)]'] = 10.years.from_now.year.to_s
  page = agent.submit(form, form.buttons.last)
  update_attribute(:pledgie, page.uri.to_s[/\d+/])
end

Step 5: Take the pledgie attribute we just grabbed and put a cool badge in their repository’s detail box.

Step 6: Watch the millions pour in for GitHub’s hard-working open source committers.

The obvious caveat here is that it relies on Pledgie not drastically changing the structure of its HTML, but it’s incredibly satisfying to throw something together like this in such a short amount of time.

PS. If you’re on GitHub and wondering how you missed the original announcement, the post is here: http://github.com/blog/57-getting-paid-the-open-source-way

Jamis Buck: Dealing with project overload

Jamis — 2008-05-14T20:39:43+00:00

I’ve got my plate full of projects that need attention, and the stress has been getting to me. Everybody has different ways of dealing with stress, but I think mine is the least effective: ignoring things doesn’t make them go away.

So, I’m taking a more active approach. Starting immediately, I’m going to be spending one hour, every day, six days a week, clearing away the backlog of projects. I’ll post a comment each day to keep myself honest—if I don’t leave a comment, you may assume I did not do any work that day!

Here is a list of what I’ll be working on, more or less in order of priority:

Capistrano 2.2.0. This will primarily be a maintenance release, and mostly requires that the patches that are pending be tested and applied. It will also update the Net::SSH and Net::SFTP gem dependencies so that they explicitly exclude any 2.0 versions of those gems.
Net::SFTP 1.1.1. This is a super minor release with no new features. All it will do is update the gem dependency on Net::SFTP such that it won’t try to load Net::SSH v2.
Net::SSH v2, Net::SFTP v2, Net::SCP v1. These will be released simultaneously. They are an 80% rewrite of the original code (and yeah, rewrites are evil, but sometimes they are necessary). The API has changed, and scripts written against the existing API will almost certainly be broken by the upgrade, so make sure you are depending on version 1.x.
Capistrano 2.3.0. This is another maintenance release, which simply modifies Capistrano to work with the new Net::SSH and Net::SFTP versions. (Possibly Net::SCP, too, not sure about that yet).
SQLite3/Ruby 1.2.2. A maintenance release. Haven’t seen a release on this for a long, long time. No new features planned, but lots of bug fixes are pending.

I’m not even going to try and give an ETA on these. Just know that I’m working through them, an hour a day, and that progress is finally being made. I’ll post what I worked on in the comments to this thread, for those who want to follow along.

Charles Oliver Nutter: The Great JRuby Japanese Tour

Charles Oliver Nutter — 2008-05-14T19:37:35+00:00

Yes, friends, it's time one again for a JRuby tour. This trip, we're localizing to the islands of Japan. Do I have any Japanese readers out there?

Here's our route for this trip...it's going to be a crazy ten days:

View Larger Map

June 19: Tsukuba, Ruby Kaigi

Tom Enebo and I will be presenting JRuby at the Ruby Kaigi 2008 in Tsukuba this year, as well as meeting up with other Ruby implementers making the trip and communing with the locals. The Kaigi was great last year...lots of fun, great company, and an excellent community. We're both really excited about it. JRuby has come a long way, so we'll be doing a whirlwind tour of performance, Rails, GUI support, and finishing off with something special. It should be a great conference again this year.

June 23: Matsue, Lecture at Shimane University, Meetup with Matz and Locals

We were invited to present JRuby at Shimane University, as part of a lecture series they're doing on Ruby. And since Matz is based on Matsue, we'll certainly meet up with him to talk a bit offline...I expect he'll be pulled many directions at the Kaigi.

June 24: Fukuoka, Ruby Business Commons

Tom did a keynote last year for the Ruby Business Commons, a group of Rubyists proactively trying to bring Ruby to the business community. I suspect we'll deliver another talk or just meet up with them and see how things have progressed in the past year. At any rate, Tom enjoyed the trip to Fukuoka, so I'm looking forward to this.

June 25-27: Tokyo, meetup with local partners, universities, Rubyists?

Whenever Tom and I travel to Japan or meet up with Japanese associates, we put ourselves entirely in the hands of Sun Japan, and specifically our excellent friend and guide Takashi Shitamichi. So far, the Tokyo leg of our trip has a few embedded question marks, but I'm sure Shitamichi-san will be able to fill our days from dawn until dusk with events. Hopefully we'll have a little time to take a breath and poke around Tokyo again, but either way it will be a great end to the tour.

Spreading the Word

I'd really like to jam in as much Ruby and JRuby meetups, discussions, and talks as possible on this trip, so feel free to reblog (and perhaps translate) this entry, contact me, Tom, and Takashi directly...especially if you know of any good events while we're in Tokyo. And if you're press, Takashi can certainly hook you up if there's time in the tour (for emails...use firstname.lastname@sun.com).

JRuby is ready for the Japanese Ruby community, and we're coming to town to help send it off!

Tom Copeland: mod_rails and Capistrano

2008-05-14T17:37:01+00:00

Here's the Capistrano code I've been using with mod_rails:

namespace :deploy do
  desc "Restarting mod_rails with restart.txt"
  task :restart, :roles => :app, :except => { :no_release => true } do
    run "touch #{current_path}/tmp/restart.txt"
  end

  [:start, :stop].each do |t|
    desc "#{t} task is a no-op with mod_rails"
    task t, :roles => :app do ; end
  end
end

I think that's all there is to it... as far as I can tell, start and stop don't make much sense in a mod_rails context. I suppose you could use them to disable the app altogether somehow, although that kind of relates to this issue about maintenance.html.

Credit for the restart task goes to Jim Neath; the change I made was just to put it in the deploy namespace. Works either way, though.

Dave Thomas: Test-Driven Rails Studio

2008-05-14T15:54:08+00:00

I have a blast teaching at the Pragmatic Studios.. Mike and Nicole run excellent courses, the format is incredible, and the students enthusiastic. I love presenting with two or three other instructors—it keeps the energy level high, and I always manage to learn a lot from them.

Which is why it's a shame I won't be able to be at two of the upcoming Studios, Advanced Rails in Denver on June 12–14 and Test-Driven Development with Rails on June 9–11. I'm doubly bummed because the latter is taught by Jim Weirich and Joe O'Brien, both old friends from the Ruby community. I've never heard Joe teach, but I've often sat and admired Jim as he takes some complex subject and reduces in to its basics in the most incredibly entertaining ways. If you're in to Rails, and want to take your testing to the next level, I believe there are still some seats available. And if you do get there, tell 'em I said hi! I'm jealous.

Tom Copeland: mod_rails for your staging environment

2008-05-14T15:10:37+00:00

This is more of a twitter than a proper blog entry, but if you're using mod_rails for an environment other than production, don't forget to set RailsEnv staging or whatever your environment name is in your Apache configuration file.

Jamis Buck: More preview releases from the Net::SSH family

Jamis — 2008-05-14T14:30:19+00:00

I’ve got lots of code to share with you all today:

Net::SSH 2.0 Preview Release #3

Not very many external changes, but channels now have an on_open_failure callback that you can employ to be told when a channel could not be opened.

channel = ssh.open_channel do |ch|
  # ...
end

channel.on_open_failure do |ch, code, reason|
  puts "could not open channel because #{reason.inspect} #{code}"
end

This change was necessary to make port forwarding a bit more reliable for Net::SSH::Gateway (see below).

Also, individual Net::SSH sessions may contain their own custom properties, much as Net::SSH channel objects do, which can be quite handy when you need to keep some state associated with the session.

ssh[:key] = "value"

This change (and several other internal refactorings) was necessary for the correct working of the Net::SSH::Multi library (see below).

To get the preview release #3 (version 1.99.2):

gem install --source http://gems.jamisbuck.org net-ssh

You can follow development via GitHub:

http://github.com/jamis/net-ssh/tree/master

Net::SFTP 2.0 Preview Release #2

All that was added in this preview release was custom properties on Upload instances:

123	uploader = sftp.upload("local.file", "remote.file")uploader[:failed] = false# ...

This was necessary to get Capistrano file transfers to work with Net::SFTP 2.0.

To get the preview release #2 (version 1.99.1):

gem install --source http://gems.jamisbuck.org net-sftp

You can follow development via GitHub:

http://github.com/jamis/net-sftp/tree/master

Net::SSH::Gateway 1.0 Preview Release #1

Net::SSH::Gateway is (in essence) the extraction of the gateway code from Capistrano into its own library. It lets you tunnel SSH connections through some “gateway” server to servers that would be otherwise inaccessible.

require 'net/ssh/gateway'

gateway = Net::SSH::Gateway.new('gateway.host', 'username')
gateway.ssh('remote.host', 'user') do |ssh|
  # ...
end

You can also use it as a general facilitator for forwarding connections over a local port, when you don’t care what port is to be used—you just want to connect to a remote server.

123	gateway.open('remote.host', 80) do \|port\| Net::HTTP.get_print '127.0.0.1', '/path', portend

The current thinking is that the next release of Capistrano will ditch its own gateway implementation in favor of Net::SSH::Gateway. To get this first preview release (version 0.99.0):

gem install --source http://gems.jamisbuck.org net-ssh-gateway

You can follow development via GitHub:

http://github.com/jamis/net-ssh-gateway/tree/master

Net::SSH::Multi 1.0 Preview Release #1

Net::SSH::Multi is the guts of Capistrano, extracted into a library of their own. It allows you to define and categorize servers, and then execute commands in parallel on them, or on subsets of them, using an interface similar, if not identical, to that of Net::SSH::Connection::Session and Channel.

Eventually, Capistrano will be refactored to take advantage of Net::SSH::Multi, but doing so will require some significant changes to Capistrano’s innards, and would almost certainly break many third-party libraries. Thus, you won’t see Capistrano on Net::SSH::Multi until Capistrano 3.0 or so (which will not be the next release of Capistrano). However, you can use Net::SSH::Multi to implement most of Capistrano’s functionality in whatever form you like. Want Capistrano-in-a-rakefile? Have at it!

require 'net/ssh/multi'

Net::SSH::Multi.start do |session|
  session.use 'jamis@somewhere.com'
  session.use 'jamis@elsewhere.com'

  session.exec 'hostname'
  session.loop
end

Grab the first preview release (version 0.99.0):

gem install --source http://gems.jamisbuck.org net-ssh-multi

You can follow development via GitHub:

http://github.com/jamis/net-ssh-multi/tree/master

For all of these libraries I’ve tried to make the rdoc and ri documentation as informative as possible, so please refer to those to get started. If those aren’t helpful enough, let me know what could make them more useful!

Charles Oliver Nutter: RubySpec: Bringing Ruby Test Suites Together

Charles Oliver Nutter — 2008-05-14T01:08:07+00:00

Hooray! The RubySpec Project, a collection of runnable specifications for Ruby 1.8.6ish behavior, has graduated into its own domain. Finally there's a lively, fast-moving, independent project to create a Ruby specification and test kit. And it's already well on its way.

Better documentation on how to pull the specs, update them, and use them for your own Ruby implementation (you do have a Ruby implementation, don't you?) are still being ironed out, but the repository is already available at the RubySpec github address, so you can pull them and start reading and running them. Also see the MSpec github for a lightweight (lighter than RSpec) tool to run the specs with.

But this post is not just about the the RubySpec project...Brian Ford is putting together an official announcement for that as we speak. This post is a call to action.

JRuby currently encompasses something like 6 separate test suites:

Our old JRuby test suite using "minirunit", a small runit clone no longer in wide use (the camelCase.rb tests at that URL)
Ryan Davis and Eric Hodel's "BFTS" suite, a narrow but deep set of tests for a few core classes
Our newer set of JRuby tests using test/unit (the underscore_case.rb tests at that URL)
MRI's own set of tests, from the Ruby 1.8 repository (link is to our somewhat out-of-date copy)
A test/unit port of the Rubicon test suite, originally written by Dave Thomas while writing the Pickaxe books
The ruby_test test suite, a suite of tests created by Daniel Berger for his projects (link is to our out-of-date copy)

We don't want to run these tests forever...we would rather just run the RubySpec. So this is where we need help.

Much of these tests are already encompassed in the RubySpec specs. BFTS, for example, focuses only on a very few core classes, which have been heavily covered in RubySpec. In many cases, these test suites even overlap each other, meaning that our 3 minute test run could probably be a lot shorter. If we could just replace our test suite with the RubySpec (modulo JRuby-specific bits like Java integration), we'd be very happy.

But we can't afford to do that unless we know we're not throwing away good tests. The RubySpec is a work in progress, and there are always going to be gaps. It would be folly to throw away our tests without consideration. So that's where you come in.

We need to start at A and work our way through Z, porting over any test cases that aren't covered in the RubySpec.

I started the process tonight, adding a number of missing cases from our test_array.rb script and deleting everything I ported and everything that was already covered. It took perhaps an hour to go through, and it was of a reasonable size. Many other scripts will be much smaller, some will be larger.

The benefits extend far, far beyond JRuby of course. By adding missing test cases, we're going to ensure that all new implementations have a complete spec to go on. We're going to make sure there aren't a lot of incompatibilities you users have to deal with. And we're going to show all those other languages (who are still laughing at our lack of a spec) that we can do this in our own Ruby way.

So what are you waiting for? Contact Brian Ford and get access to the specs (perhaps after paying a one-patch toll)...have a look at the JRuby test repository...pick a file, and start comparing. Tell your friends, email your favorite Ruby list, blog and reblog this effort. The time is now to pull together all the disparate suites into one. RubySpec is ready!

Phil Hagelberg: in which light is shed upon some previously unexplored frontiers

Phil Hagelberg — 2008-05-13T23:31:01+00:00

So I've been working on modularizing a big project at work. The REST API for this one project needs to be used in multiple places, so I've taken it out of the Rails app and spun it off into its own server using Rack. Rack is a library that abstracts away the gory details of HTTP and gives you a nice object-oriented wrapper for it, allowing you to plug it into multiple different backends. It's great for accelerating development on your simple lightweight services that wouldn't otherwise justify a Merb or Rails application. Ezra gives a good explanation of why you might be interested in Rack.

Anyhow, I was able to put this together fairly quickly by hooking up libxml, ActiveRecord, and Rack. (If I were doing it again I'd use faster-builder, which I found out about a few hours after I started the project, but whatever.) But this particular project must be able to support ridiculously large XML responses that could be larger than 4GB. On a 32-bit machine this is... well... problematic. The solution, of course, is to stream the response back to the client as it's generated so it doesn't have to all be in memory at once.

Unfortunately the only Ruby support for HTTP streaming I was able to find by searching the web is about streaming static files. I was getting pretty discouraged until Ezra mentioned that Merb bundles a patched version of Rack that allows streaming of programmatic content.

Sure enough, Merb's changes to Rack do the trick:

require 'rubygems'
require 'rack/response'
require 'rack/handler/mongrel'

# Launches an HTTP server on http://localhost:9999/N that streams its own code N times
Rack::Handler::Mongrel.run(Proc.new do |env|
                             [200, {}, Proc.new do |response|
                                response.send_status_no_connection_close('')
                                response.send_header
                                env['PATH_INFO'][/(\d+)/].to_i.times do
                                  response.write File.read(__FILE__) + '\n'; sleep 1
                                end
                                response.write '\r\n\r\n'
                              end]
                           end, :Port => 9999)

I check the streaming with curl; if it's properly streamed the % Received will climb slowly instead of jumping at once to 100:

$ curl http://localhost:9999/7 > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  5310    0  5310    0     0    755      0 --:--:--  0:00:07 --:--:--   796

It's not clear to me why this functionality isn't in the standard Rack distribution. Merb seems to be Rack's biggest user, so the fact that they have to bundle their own patched version seemes quite odd. Anyway, if you need HTTP streaming outside Merb, you can use my version of Rack. I haven't been able to get the gem served by Github; unreproducible remote problems in the gem build process are very opaque and give no feedback. Will look into this later.

I'm going to try to get the changes into the mainline rack, but if Merb hasn't been able to get it accepted this may not actually happen. The meat of the patch is three lines, but I've got a bunch of other stuff that allows the project to actually build as a gem; the source as I found it was not in a working state. (Who knew there were people out there who haven't yet discovered hoe?)

Much thanks to Ezra for the fix. I was starting to lose hope that I'd even be able to even pull this off without resorting to low-level Mongrel invocations. Even though the fix is available in Merb, it's not really very clear how to use it, so I thought this post would save other people from going through the same crazy hoops I had to.

Chris Neukirchen: Off to Potsdam: Attending S3

Christian Neukirchen — 2008-05-13T17:08:04+00:00

Tomorrow I take the train to Potsdam to attend the Workshop on Self-sustaining Systems (S3), which means I get the chance of meeting rpg and many other people that worked on Lisp, Self and related cool stuff in real life.

The stuff I’m working on got not finished by far, but maybe I can write down enough on the train to explain it to interested parties.

If you want to hook up, don’t hesitate to contact me. I’m there until Saturday morning.

Anarchaia and chris blogs will resume publishing Sunday, May 18.

NP: Manu Chao—Politik Kills

Jim Weirich: Presenting Code ... An Update

2008-05-13T12:14:40+00:00

I received some feedback on the ‘Presenting Code’ post from yesterday.

Presenting Code … An Update

I got lots of feedback on the “Presenting Code” post. In addition to Cédric Beust’s initial comments, the following people had something to say on the topic:

John Wilger asked on Twitter why I didn’t use “file:” (rather than “http:” and a local web server). Unfortunately, Keynote will not do a web view from a “file:” style URL.

Luke Kanies reports that he does something similar. He uses Vim (rather than Ruby + the Syntax gem) to generate the highlighted HTML. He also adds:

In general, this method works out great, but the one thing I would say is that you should always uncheck “automatic update”. Otherwise, you’ll find that it tries to update 10 seconds before your presentation starts and your web server isn’t available.

Ok, that’s good advice. BTW, I would be very interested in a script (AppleScript or Ruby+OSA) that would iterate over the pages in a Keynote presentation and refresh all the WebViews. Any takers?

James Edward Gray II and Mike Clark mentioned the HTML output bundle. James gives the following details:

Select Bundles → TextMate → Create HTML From Document (or Create HTML From Document With Line Numbers, if you prefer)
Preview the document in TextMate with Window ⇢ Show Web Preview
Highlight and Edit → Copy the content you want from the HTML window
Switch to Keynote and Edit → Paste

Mike (who credits Bruce Williams as his source for this tip) also provided a video.

Couple of items on the above:

When creating the HTML from the document, convert the whole document. Once in Web Preview mode you can cut and paste only what you want.
Choose a TextMate theme with a background that matches the background in your presenetation to get the best effect for your colors.

Dr. Nic also mentions a “Copy as RTF” TextMate bundle. (I’m not sure if this is the same as James and Mike’s hint above or something different).

Finally, Chris Nelson confirms (via Twitter): “AFAIK there is no equivalent of web views in OpenOffice :(“