Archive for April, 2006

OwlManAtt.com Moves (Again)

For hopefully the last time, OwlManAtt.com has moved to new hardware. This machine has generiously been given a home by John Hirbour.

Ramblings About Ruby on Rails

I pretty much spent all of Friday night, Saturday, and Sunday doing Ruby on Rails-related stuff. Finishing the Agile Web Development book, reading Why’s (Poignant) Guide to Ruby, and writing actual code.

First and foremost, let me say hot damn, the Ruby scripting language is elegant. I still do not comprehend all of it (but I’ve got most of it down thanks to Why!), but really. Damn.

@some_fucking_array.each { |input| print "#{input}\n" }

Or…

@user.user_preference.display_name = 'owlMANatt'
if @user.valid?
@user.save

PHP just ain’t got shit on that.

The guide I mentioned above, Why’s, is worth reading even if you don’t want to learn Ruby, by the way. It’s just that good.

Now, I said that I was writing code. What for, you may ask? A new project? Another half-hearted attempt at doing something?

Yup.

I’m hacking together a pet game (I know, I’m Mr. Unpredictable) with Ruby on Rails. I’m calling it freePets for now, in a parody of the never-quite-started-but-still-fucking-impressive freeCritters. The site will include numerous jabs at Eurleif for his lack of progress despite having been working on freeCritters for something to the order of three fucking years. As a bonus, freePets will be done before freeCritters.

I spent some of yesterday and all of today working on the register screen. Why did it take so long if Ruby on Rails rocks so much? I’m just a tool, that’s all. I’m getting the hang of this Ruby thing, so I should start humming along shortly.

But, I did not *only* write a register script, oh no! I wrote a wonderful unit test to automate the process of testing my register script. It was quick and easy to do, which is why we all love Rails so much!

I did learn about one serious limitation to Rails, however. Rails does not support compound keys. At all. No account number & UUID as a key for me. =(

Initial Thoughs on Ruby on Rails

As mentioned in my last post, I’ve been reading a book about Ruby on Rails. This book, Agile Web Development with Rails, consists of two major sections. In the first, a demo application (a shopping cart) is written. In the second, you get an excellent look through most major features and concepts in the Rails framework. The book also includes a (breif) primer to the Ruby language.

Rails is an interesting beast. It forces the design pattern of MVC down your throat. This, however, is not a bad thing. It allows Rails to make a bunch of assumptions about how your application is going to work. Based on these assumptions, Rails picks lots of sensible defaults. And Rails is all about defaults. Defaults save you time.

So, now, lets ponder the model. The model is the data your application deals with. Normally, this data is stored in a database (Rails supports MySQL, Postgres, Oracle, and more). But, since Ruby is an object oriented language, it would make sense for us to translate the model from a relational database into objects.

This is where Rails’ concept of models comes in. When you start a project, rails generates a lot of files with code stubs for you. In our project/app/models folder, we’ll find a bunch of classes that link together database tables. We can also find things that tell the model what to accept and what not to accept as valid input for a field. Rails even has a number of hooks that allow us to insert our own code to be run before or after a database operation (like, we can add a method to automagically log something every time we save an object).

Rails uses a kickass package called ActiveRecord (not to be confused with Microsoft’s LDAP implementation, ActiveDirectory) to interact with relational databases. Not only does it do all of the cool stuff from above, but it also generates methods for updating/selecting/saving/inserting, has built-in SQL sanetization, and lots of other cool features. You can read more about it in the Ruby on Rails API documentation.

Next up, we have the concept of controllers. Controllers are where a lot of where our application logic resides. Their job is to actually do it. They change the application’s state, find appropriate database records, and generally take care of business. They can then hand off what data they’ve gathered to the view, but more on that in a bit.

Controllers, like models, are also just more classes. One can invoke a controller by going to something like ‘example.org/myapp/controller_name’. Rails would look for a class called ControllerName in app/controllers/controller_name.rb.

Notice how the class name changed from what we specified in the URI to what it looked for. This is something Rails does a lot. The idea behind Ruby on Rails is that you can express ideas cleanly in something that looks human-readable. As such, Rails guesses at things that look nice, so you don’t have to specify them. ActiveRecord also does this by playing with the pluralization of the model to find the approprite database table. For example, if the model was called ‘Book’, the table it would look for is ‘books’.

Yes, I know. That sounds like a really, really bad idea. I agree with you, one hundred and ten percent. I have the feeling that I am going to be burned by Rails when I start developing in it because someone had the bright idea to teach their development framework the English language. This is my single biggest complaint with Rails (keeping in mind that I haven’t done much with it yet, having only read a book on it).

Finally, the view. Rails has two templating systems, rhtml and rxml. They’re pretty self-descriptive; rhtml is for HTML, and rxml is for XML. Rxml was covered very breifly, but it looks nifty for generating feeds. Rhtml was discussed much more completely. It offers all of the features of the Ruby programming language, making it incredibly flexible. Additionally, the book demonstrated how one could add a new templating system to Rails. It was not very hard.

Ruby also supports writing little modules that you can drop in and out, along with creating ‘helpers’. I’m not sure of their practical usefulness just yet.

There is a little Rails features that really makes Rails shine. When one generates form elements using the built-in form helpers, Rails can automagically highlight fields that have invalid input in them, with almost no work on the part of the developer. That’s really cool!

All in all, Ruby on Rails looks like it’ll be interesting. It seems easy. Agile Web Development with Rails was a great read. In fact, it was the first book of its class that I was able to read cover-to-cover in just a few days. I strongly advise it to anyone who is interested in developing under Rails.

POST vs. GET

I know, I know, I’m such a fucking nerd. This is from an e-mail I just sent, and felt like sharing with even more people:

I learned something about the way the intarweb is supposed to work from the Rails book. Being an intarweb standards dork, I thought it was interesting and decided to share Yet Another Unadhered To W3C Usage Recommendation(tm). It also explains why browsers give you that popup when you try to refresh a POST request.

You see, we’ve got out two HTTP request methods, GET and POST. They each have a very specific usage, but nobody pays any attention to that whatsoever, despite the useage recommandation for them being so old that it was in the HTML 2 spec.

Simply put, GET is used to retrieve data, and POST is to cause a change in your application’s state (for example, causing an action).

If you recall when Google released is Web Accelerator, everyone wambulanced about it clicking all of the links and accidentally deleting content or what have you when an administrative user was using the software. That wasn’t Google’s fault, though; developers had just ignored the standard. The web accelerator pre-fetched GETs (hyperlinks), and not POSTS (forms, etc.).

For more info, see some random Finnish university’s website.

You are all now enlightened!

Allah & Lady of Guadalupe Send Cease and Desist

New Haven, Conn. (OwlManAtt.com) — In a startaling turn of events, the legal counsels for Islamic diety Allah and Mexican icon Our Lady of Guadalupe delivered a cease and desist letter to Nicholas Evans, a small-time blogger and computer enthusiast living in Connecticut, ordering an immediate end to the unholy unions between hummus and tortillas that have recently popped up in the blogger’s cooking.

“The entire idea of these so called ‘holy entities’ telling me what ingredients I can and cannot combine is insane. I don’t know what the fuck they’re smoking, but I sure as hell want to know where I can buy some,” stated Evans during a press conference. “All I fucking did is put some Fantastic! Original Hummus on my tortillas with the red beans. After you fry that up, it’s good eatin’.”

The letter was delievered after Muslim neighbors smelled the hummas and inquired as to what Evans was cooking. Outraged by the hybrid Middle Eastern-Mexican burrito, they immediately fell to their knees in prayer to notify Allah.

Evans’ lawyers have pledged to fight it out with Allah and the Lady of Guadalupe if it comes down to a court battle, but “[we] are hoping to avoid anything drastic.”

Spokesmen for the Muslim God and manifestation of the Virgin Mary were unavailable for comment.