Peter Williams

I love the new Envy Code R font. It’s very clear and easy to read. I had looked at this font in the past and quite liked it. However, I need a somewhat larger font than its native size and previous releases of it did not scale very well. Fortunately, the new version (pr7) seems to scales very nicely.

Here is screen shot of “pretty” Emacs (on Ubuntu) using this beautiful font

“

Resourceful has its initial (0.2) release today.

Resourceful is a sophisticated HTTP client library for Ruby. It will (when it is complete, at least) provide an simple API for fully utilizing the amazing goodness that is HTTP.

It is already tasty, though. The 0.2 release provides

• fully compliant HTTP caching
• a framework for implementing cache managers (memory based cache manager provided)
• fully compliant transparent redirection handling (with hooks for overriding the default behavior)
• plugable HTTP authentication handling (Basic provided)

Introduction

The API is strongly influenced by our successful experiences with REST. Each URI is represented by a Resource object. The Resource objects act as a proxy for the conceptual resource. Resources expose the basic set of HTTP verbs: get, put, post, delete. For example to get a representation of some resource you do this

require 'resourceful'
http = Resourceful::HttpAccessor.new
resp = http.resource('http://rubyforge.org').get
puts resp.body

If you want to post a form you do this

require 'resourceful'
http = Resourceful::HttpAccessor.new
resp = http.resource('http://rubyforge.org').post("name=Peter&hobbies=programming,diy", :content_type => "application/x-www-form-urlencoded")
puts resp.code

All non-2xx responses are either handled transparently (e.g. by following redirects) or the method will raise a UnsuccessfulHttpRequestError.

Conclusion

If you need a decent HTTP library in Ruby come on over and check it out. If you see something you want, or want fixed, feel free to branch the git repo and do it. Paul and I would love some more contributors and will welcome you with open arms.

Every time I hear someone say that Java is “scalable” my initial reaction is to kick the person who said it in the shin.

I have been talking to a lot of people lately about the tools we are using at Gnip. Every time I tell someone that major parts of our system are written in Java the response seems to be, “Oh, for it’s scaling capability?” While I was safely ensconced in the Ruby world I had hope that this malformed meme was dead. It seems that in the wider world it’s not quite dead.

I never actually kick the person, by the way. Instead I just sigh and explain that, no that is not the reason. Scalability cannot be the reason we use Java, because Java does not scale any better, or worse, than any other general purpose language.

There are a variety of different sorts of scalability. The most interesting type of scaling in the context of web applications, like Gnip, is how easily can you increase the number of requests/sec the system can handle. This sort of scalability, or lack thereof, derives pretty much entirely from the architecture of the system. No language will magically make your system be able, or unable, to handle an order of magnitude increase in the number of requests.

The culture¹ of Java actually encourages the development of mediumly, rather than highly, scalable systems. It does this by favoring the use of multi-threading, shared state, vertical scaling and large monolithic components. These techniques do not scale infinitely. Fortunately, Java is fast enough that they can scale to quite significant levels. Even though the culture of Java encourages these less than perfectly scalable techniques you can build highly scalable systems with Java quite readily. You just have to be willing to buck the culture when it is appropriate.

Performance, on the other hand, does derived, to a significant degree, from your language,² and that is why we use Java.