Category Archives: Ruby

Java Open Source Ruby Software Engineering The Business The Innerweb

QCon San Francisco 2010 Redux

So, I just got back from QCon SF 2010 last night.  All in all, a very good conference.  Rather than write up any kind of extensive summary, I’ll offer up my rapid digest of the major themes from the sessions I attended.  Without further ado, here it is in outline form:

  1. Dealing with data at large scale
    1. OLTP
      1. Those who can get away with it are using systems that have more flexible consistency models than traditional RDBMS (CAP theorem trade-offs)
        1. Most using some form of eventual consistency
        2. Many sites implementing their own Read-Your-Own-Writes consistency on top of more general storage systems
        3. These systems must deal with data growth (partitioning data across nodes)
        4. Must deal with hot spots (redistributing / caching hot data across many nodes)
        5. Must deal with multiple data centers (some are simply punting on this)
      2. Twitter and Facebook both built their own key-value stores on top of MySql, Memcache
        • Twitter’s solution seemed a little cleaner, Facebook’s a little more crusty
      3. Amazon S3: also key value store with own caching, replication, consistency models
        • This one had the most sophisticated seeming solution for dealing with hot spots
    2. OLAP
      1. Lots of people using Hadoop to crunch offline data
        1. Good tools for workflow of jobs, dependency management, monitoring are essential
        2. Quantcast found that EC2 was not adequate for their needs in terms of throughput compared to an owned, highly-tuned cluster, though it has improved over time
          • still good to have on hand for surge capability
    3. Operating on the public cloud
      1. Increased demand for monitoring — and most monitoring tools not built for cloud instances that wink in and out of existence
      2. Increased demand for fault-tolerance — latency can vary more widely, hardware failures happen out of your control
      3. Increased demand for sophisticated deployment automation
      4. Motivation is that you want to use a cloud, not build one
        1. Capacity planning is difficult when you’re in a huge growth scenario
        2. Leverage the staffing and expertise of the public cloud companies (Amazon, Gigaspaces, etc)
        3. Data center is a large, inflexible capital commitment
      5. Traditional CDNs are still necessary and useful for low-latency, high bandwidth media delivery
      6. PCI compliant storage in the cloud is not a solved problem
    4. Serious interest in alternative languages, both on and off the JVM
      1. There are lots of serious choices available in this sphere (scala, jruby, javascript -> node.js, erlang, clojure)
      2. Lots of enthusiasm for JVM, less enthusiasm for oracle’s ability or intention to be good stewards of it
    5. Though there were many very good sessions, especially in the Architectures You Always Wondered About track, in terms of sheer rock-star appeal these two presentations appeared to be the standouts that had everyone talking:
      1. LMAX – How to do over 100k concurrent transactions per second at less than 1ms latency
      2. Node.js
Ruby Software Engineering

First Impressions of Ruby

I’ve been reading my way through The Ruby Programming Language by David Flanagan and Yukihiro Matsumoto over the last couple of weeks (very well-written, by the way) and having read up through Chapter 7, I’m about at the point now where I’m ready to do something useful with the language.  I figure now is a good time to jot down a few quick first impressions of Ruby before I get comfortable enough with the language that all of its idiosyncrasies vanish into familiarity.

First, the negative side:

  • I’m skeptical of the value of optional parentheses in method invocation.  I see how being able to omit parentheses in a call to a setter method makes it look more like straight assignment, and that’s pretty cool.  But other than that, I see nothing clearer or cleaner about “o.do_something a, b” than, “o.do_something(a, b)”.  Given the numerous situations in which confusion can arise with the rules about when parentheses can and can’t be omitted, I think it’s highly debatable whether optional parentheses are a plus.
  • Method aliasing.  I have not gone through the chapter on meta-programming yet, which is where I think the real justification for method aliasing comes from.  However, in regular-old-programming land, having multiple aliases for methods sucks.  The claim is that it makes the language more expressive because you can define a name for a method that fits the use case better.  An example is the Range class’ include? method which also has the alias member?.  To me, a method that needs aliasing is a method that wasn’t properly named in the first place.  It’s also just more complexity than necessary.
  • “do” and “end” as the conventional block-delimiters for large blocks.  Ugh.  I guess Matz must have been an avid shell-scripter.  To me, this is just bad usability.  The C family of languages (and Perl!) got it right with { and }.  There’s a symmetry there that mirrors their logical function, they are commonly used as delimiters for a set in mathematical notation, and what is a block but a set of statements or expressions? Plus, the construct of a block is something you will be typing over and over and over.  Why do we have to type a total of five characters to delimit it?  “do” and “end” doesn’t really flow nicely, and it doesn’t even come close to mimicking any sort of natural language expression.  I don’t see where it adds any clarity.   Sigh.  However, I’ve come to like Python’s rather individual use of significant whitespace, so perhaps I’ll come to like this as well.
  • Constants that are not enforced as constant.  We have a name for this where I come from: global variables.

On the positive side:

  • I like the use of $, @, and @@ prefixes on variable names to indicate global, instance and class scope.
  • The ability to pass arbitrary blocks to methods is an interesting approach to functional programming.
  • The little I’ve seen of Ruby’s reflection abilities looks like they enable you to do more than Java’s reflection API with fewer lines of code. That may be dangerous, but it certainly looks like fun.
  • Modules!  Yay!  I’m sick of writing utility-style classes with static methods in Java and then playing tricks to keep people from instantiating them.

I will try to write a follow-up after I’ve used the language a bit more.  I’m sure I’ll disabuse myself of some of my criticisms along the way.