Notion of Self

I was on my merry way through the Agile Development with Rails book, following the example... then I hit a snag.

The goal of Chapter 11 is to create a User model object with an encrypted password, and the means to authenticate users.

The functional objective was clear enough. The User class featured a special password= assignment operator, designed to set accept a plain text password, and behind the scenes convert and save as an encrypted hash.

Also the User class features a 'static-like' method that authenticates a user by name/password.

The implementation was not familiar to my novice ruby eye. It had strange 'self' keywords in curious spots. I initially thought it must be like 'this' in Javascript, but it was used in different situations that I didn't understand.

These were:

A) In private methods.

B) In method declarations, which seemed to function like Java static methods.

The book did not elaborate beyond stating "Without the self, Ruby would have thought we were assigning to a local variable, and our code would have no effect."

Now, I don't fault the authors for my confusion. This is a book on Rails, not a Ruby primer. Rather than gloss over this point, I decided to search for details on 'self'.

The best explanation I found for the self keyword, elaborated on how ruby invokes a method call on an object:

"Method calling" in Ruby is accomplished through a message-sending mechanism. So


some_object.some_method(args)


is a shorthand for


some_object.send(:some_method, args)


Within a method, 'self' refers to the object that has been 'sent' to the method. So it is somewhat like the this object in Javascript!

So... a private methods in a class like:


def create_new_salt
self.salt = self.object_id.to_s + rand.to_s
end


A public instance-level method often makes use of an internal, private method. By referring to self in the private method, it can alter the calling object without an explicit reference.

Now not exactly intuitive from that definition, is the following method declaration:


def self.method(var)
...
end


This seems strange at first. But think about it this way: the methods marked with self can only be invoked by the owning object instance. Its like a static method in that way.

Agile Development with Rails

I am diligently working through the iterative-based example in "Agile Development with Rails" by Dave Thomas and David Heinemeier Hansson.

Thus far, I like the book's style and approach. I'm only on page 131, and this is the 2nd edition (covering Rails 1.2), but I really like it so far and would recommend it.

I wish they had chosen a different application from the "classic online store with order cart" example, but I guess its the new Hello World!

Vis a Vis Rails,

I love generating model objects and controllers using the scripts.

Also the URL dispatch by convention is pure joy. At first glance, this seems to encourage and result in RESTful-looking URLs.

I am probably most impressed with the whole framework around DB migrations. DB design and ORM mapping is such a fundamental part of the classic MVC app, I love that this process is integrated into the framework. It somehow keeps you thinking in Ruby and I avoid the sinking "Now its time to to write SQL" feeling I get when messing with the object/data model.

What I didn't like at first:

At first, I wasn't sold on Embedded Ruby in the views.


<% %>
<%= %>


I was a fan in Java MVC of keeping JSPs pure, utilizing taglibs wherever possible and using the standard JSTL religiously. "Is there no analogue for Tags?"

Then I thought about it in Rails context.

1) Ruby is a great language, and its already interpreted. In a sense, it isn't nearly as hacky as embedding Java in JSPs. And part of the point of Rails is to let you use Ruby BECAUSE of its expressive power.

2) The view feels like a part of the controller instance. Probably in ways I don't understand yet, the view is much closer to the Controller than in J2EE frameworks. It appears you actually call controller functions in the view and you access instance variables like you are still in it.

3) Helpers seem to take the place of tags... and they seem to be controller specific. Easy to write, if they are the answer for keeping it DRY without clunky formalities... I am buying in to that one.

It occurs to me now that MAYBE... JSPs, Taglibs, JSTL, EL Expressions were not necessary parts of the J2EE framework... or at least they wouldn't have been necessary if Java had the powers and flexibility of Ruby.

What I still don't like:

X) I just finished the AJAX chapter, I am not convinced (yet) that .rjs templates are a good thing. I guess I don't understand them enough, but it seems as though there is unnecessary complexity in hiding prototype, scriptaculous, and other DOM functions behind Ruby libraries. I definitely am willing to suspend judgement on it for now.

Y) I did appreciate the ease in which you can make the use Ruby to define and make the XHR call from the view (using form_remote_tag), but I am still a bit gunshy of server-side code that writes JS. Its seems to me that in most applications developers will want more control of the JS and DOM to use existing or 3rd-party libraries, etc.

Z) I don't see render(:partial => ...) as an elegant solution. On the other hand, maybe they are just keeping it simple (as opposed to creating some heavyweight formality like Tiles, etc.)

Overall, a successful first foray on Rails. I think I am going to press on with the example, fighting the urge to hack out the next Web 3.0 sensation with my new Rails skills.

PS. I am using RubyMine IDE from JetBrains on Mac OS X and loving it. I am currently an IntelliJ user, so perhaps this has colored my perspective but it has been error free and easy to use so far.

Teaching an Old Dog New Tricks

Back in grad school (in the nineties, wow!) I remember my first exposure to the revelation of Java. To a C/C++ programmer it was a godsend, promising a pointer-free, garbage collected future where everything (almost) is an object, and fantastic virtual machine code would live everywhere (client and server!!!). Write once, run anywhere, the sky was the limit.

Well, more than a decade has passed now. I've had some great times with my old Object-Oriented pal, and he's been good to me. I've made a good living, enjoyed my trade, and worked with some great people along the way.

Admittedly, I can't say that I have fully mastered Java, I can say that after building scores of Applets, Servlets, Struts and Spring apps, Concurrent Systems, I have grown weary of its charms and annoyed with its foibles.

I feel like I've overstayed my welcome in the J2EE world. It's comfy and familiar, but not satisfying. Its time to shake things up, time to go back to school so to speak.

The good news is, I am not weary of programming in the least. In fact, the prospect of learning the new and emerging languages and styles now in vogue, is exciting and invigorating.

But I am feeling quite behind the times! I have decided that the only way to rid myself of this uneasy feeling of being a "Legacy Programmer"... is to dive in and see if I can still swim.

Now to the problem of what to tackle first.

I am feeling pretty hemmed in by Java's OO/Imperative constraints, and was surprised to find myself really enjoying programming in JavaScript on some recent AJAX projects.

Nowadays, in places I would have happily applied one of the trusty GoF patterns before, code was screaming for first-class functions and closures.

I feel the best thing for me to do to get the flavor of the new-style and lose my old way of thinking, is to learn a multi-paradigm language.

There are many choices, each with their merits, applications, and loyal followings.

I have narrowed it down to three: Ruby, Python, and Scala, but I am having trouble choosing from there.

Ruby is easy to use, learn, and pretty popular out there. Rails apps are everywhere, and from what I have seen so far, I like it a lot.

Python is very widely used, powerful, expressive, and pretty much in a dead heat with Ruby on all fronts.

Both languages have a great MVC framework, and both are commercially viable.

However, in my current job, it is unlikely I will be able to apply either to the real world problems I face, which is ultimately where you learn the most.

Scala on the other hand, compiles to Java bytecode, uses the familiar Java syntax, its even runs integrated with existing Java code.

I think I want to learn all three, and against my better judgment, am going to attempt to learn them concurrently.

I have a decent Ruby book, so I am going to give that a try first.