Entries tagged with ‘RubyOnRails’:
Ruby on Rails from a C# Perspective
Well… So, it looks like I bought into the hype. I’ve now completed rewriting this weblog from C#/ASPNET to Ruby on Rails.
It’s kinda funny, I guess, that I spend time writing, (and rewriting, and rewriting, and rewriting) this weblog when I never actually write in the damn thing. So it goes.
I reckon it’s become an interesting project for me these days, and a good practical exercise when working with a new language or a new environment. And, since I’ve written the damn thing at least half a dozen times now, I’ve learned a lot about what it means to build an effective administration UI, what it means to keep the data in the DB portable (because I assure you that in a couple of months I’ll be looking at rewriting this in smalltalk, python, or lisp), and how helpful it is to fully separate your logic from your presentation.
Anyway… back to the subject at hand: some of my perspective as a C#/ASPNET developer on Ruby on Rails, and how porting this blog to ROR went. There’s a number of things about ROR that I really like, so let’s let the glass be half-full, and start there.
- Ruby is an incredibly “clever” language. There’s a lot of little stuff that (once you get the hang of) you think: “Well doggone, that’s pretty clever…” Before starting with rails, I actually tried to dig into the Ruby language itself. This document I found to be both well written, and pretty useful.
- After about a week, I found Ruby syntax becomes incredibly automatic (albeit still very weird). There have been a number of times where I’d think to myself, “That can’t be the right syntax…” but, I’d save the document, try it, and sure enough, it would be right.
- The Rails framework is also quite clever. It does a great job of cramming MVC down your throat and making you really keep your code tidy.
- Obviously, the extremely demo-able scaffolding is very smart, but there’s a lot of other really smart stuff, like generating XML documents programmatically with rxml. I’m sure many of the features of the framework could be built in C#, but it’s very nice to get them for free.
- I’ve found myself really liking the way the ActiveController “method-as-page” metaphor works. It organizes your code in a very different way than a traditional ASPNET web application, and is pretty cool.
- The built-in webserver for development (mongral on my macbook) is awesome. The VS 2005 built-in development still server has quite a few bugs, and the goddamned thing still does not want you to run your web application at “/”.
- And not to be a broken record, but the rake tool—especially when using it for database migrations is really clever. I’m looking forward to diving in a little deeper here, because it feels like I’ve only scratched the surface.
- Another small thing: the Rails’ built in logging, is also nice. I’m tired of always having to BYO logging to my ASPNET web applications.
Now, after all that praise, let’s talk about what doesn’t work well from my perspective…
- Probably the biggest issue I have is that I miss my IDE. VisualStudio, even with all it’s lumps and warts, I still think is a fine IDE. For Rails development, I’ve been using TextMate and, while it’s a fine editor, I really miss all the goodies of IntelliSense™, tab-completion, class browsing, and inline debugging.
- Speaking of debugging… From what I’ve read, it’s fairly lame in rails. I say read, because with my macbook I currently get “Breakpoints are not currently working with Ruby 1.8.5”. Right… That makes it just about useless.
- The ruby language (which I just praised above) I have to admit, I’m really not a fan of.
- You can use parenthesis, but you don’t have to.
- You can use curly brackets, but you don’t have to.
- You can use line breaks, but you don’t have to.
- And whitespace formatting is all over the map.
Powerful? Sure. But damned confusing when you’re trying to read it. C# might not be the best language in the world, but it really does lend itself to reading well. Having VS also enforce basic formatting rules, helps keep things consistent, too. - Documentation, documentation, documentation. Both the Ruby documentation and the ROR docs are pretty pitiful. Say what you want about .NET, but the MSDN documentation is pretty damned good. One of the things that drives me crazy in the Rails API is for many methods there's just an “options={}” as one of the args, but no mention what so ever as to what these mythical options may be.
- Although I think I need to give it another shot, I wasn’t very impressed with RDoc. Again, VS and it’s Xml Comments setup seems much more practical, easy to generate, and infinitely more readable.
- Did I mention how much I miss IntelliSense™? I really, really do.
All in all, it's been an interesting experiment. I’m not sure I’d ever choose ROR for a “real” development project (I still have lots of questions about fcgi, and some of the more “backendy” things that rails does) but for building internal tools, or (like this case) a simple blog, it seems pretty slick.
I imagine I’ll tinker on modifying this weblog app a bit more, and then try and rebuild one other side projects in rails—an online photo album
Tagging with Rails
So, for shits and giggles I decided to build (or really—just hook up) some basic tagging functionality this morning to this site. I was supposed to be doing “real work” but was having a little trouble getting motivated… This made for a fine distraction.
Now, I say “hook up”, because that’s just about all there is to it. You don’t actually have to do much of anything. I decided to use the built-in rails tagging plugin and, once it was installed, I made a slight tweak to the database for the new tables, made a slight tweak to the entries controller, and then, boom… you got “tags”1.
I find it shockingly simple that once it’s setup, you simply call object.tag_with(tags) to set tags on an object, and then object.tag_list to retrieve them.
In fact, it’s so simple, that I actually don’t quite trust it—and I’m finding myself reaching this state more and more, the longer I tinker with rails. Many things are just so easy, that I immediately distrust them, and end up spending a bunch of time diving into the source and dissecting them to see just what in the hell is going on.
Maybe I’m just finally getting too old and cynical. You damned kids keep your rails off my lawn.
1And for the record, I’m not convinced “tags” are any great metaphor either… Stupid web 2.0.
Human Readable URLs
I’ve been thinking a lot recently about human readable URLs. In the event that you’ve been living under a rock for the last 7 years or so, human readable URLs are where you setup your web application to have URLs that look more like
http://distinctpixel.org/entries/view/2007/05/pure_love_wines_layer_cake
vs. something more machine readable like:
http://distinctpixel.org/index.aspx?mode=view&entryId=301
There’s an older article by AdaptivePath article that does a fine job explaining it in some detail, but, in a nutshell: readable URL’s are better for SEO, usability, and helping stop global warming.
I’ve really struggled with good URL formatting for a long time. Since my background is ColdFusion/ASP/.NET, most of the web applications I’ve built have run in Windows hosting environments. And, since there’s no built-in URL rewriting in IIS that makes doing this quite a bit more difficult1.
In the past, I’ve written solutions using ASP.NET where I would use a 404 page that would parse the original request, and route based on that. Unfortunately, this method resulted in at least 2 or 3 HTTP 302 redirects (since I that’s what Response.Redirect() does) So while you could use readable URLs, once the requested was completed you’d end up at an ugly old URL.
Readable URLs with Rails
Well, now that I’m playing with rails, I’ll have to admit that I’m completely tickled that “out of the box” it comes with a readable URL setup, even if it does put the emphasis on the model’s (somewhat unfriendly) ID.
In an effort to extend it some, I’ve recently made some additional changes to this blog engine where it uses the date and title in the URL as opposed to just the ID.
My initial plan was to make a DB migration that just churned through all the entries and created a new URL column with a copy of the title. Obviously, we’d need to put a unique constraint on it, and there would need to be manipulation done to the titles to make them so they work (remove spaces, slashes, periods, question marks, etc).
All said and done, an entry with the title “This is a test” would get “/entries/year/month/this_is_a_test” for it’s URL. Great!
Except for one hitch.
Looking through the DB, it became clear very quickly that I tend use a lot of high ASCII characters in my titles (stupid mac).
Ok. No big deal. We’ll just zap any character in the title that isn’t A-Z, a-z, or 0-9. In fact, when writing a wine review last night I’ve noticed that this is exactly what Cork’d has started doing—just escaping any “wacky” chars to underscores. Problem solved, right?
Well. Kind of.
Being the old cranky guy that I am, seeing something like Ch_teauneuf_du_Pape in the URL really bothered me. Where’s the damned a? I suppose you could rewrite various characters without their accents, but suddenly that becomes a really long list of rules—circumflex alone has 21 possible characters (Â, â, Ê, ê, Î… etc.)
So, for now, I’ve decided to make it a manual process. New entries going forward will have edited friendly URLs, but older entries (this goddamn blog dates back to 2001) will continue to use the ID.
Anyway, like I said, it’s something I’ve been thinking abut lately.
1 There are handful of IIS filters out now that allow you to do rewriting, but a) Loosely documented 3rd party ISAPI filters make me nervous, and b) unless you’re on a dedicated windows box, you’re outta luck.
Rails: paying for convenience.
So I’ve been tinkering for the last couple of days with adding a commenting feature to this blog. One of the things that I’m really starting to notice with rails (and perhaps this is terribly obvious) is that while a lot of stuff is really great, you sure do pay for convenience.
Having gone through the Agile Web Development with Rails book as an intro to rails, I had been working based on some of the patterns discussed there. It’s quite possible that I’m the idiot in this situation, but all the same, it’s a bit frustrating. For example in building comments, there are comments, which belong to entries. There’s also a commenter, which belongs to each comment—a simple enough set of relationships.
However as I’m building this, it appears that rails is going SQL crazy. First, it’s making the initial SELECT query to get the entry… that’s fine. And then another query to get the comments for that entry… also fine. But after that, rails decides to make an additional SELECT * query for each comment’s commenter (that's a mouthful).
I sure would have hoped that by using the has_many and belongs_to statements in the models, rails would have been smart enough to have seen this should be a join. Being the rails newbie that I am, I don’t seem to see any real way of making rails do that (outside of writing my own SQL—which isn’t not writing the point of using rails?).
I’ve finally decided to wrap a little of my own logic around it and specifically work with the commenter_id field in the comments table to avoid the extra SELECT statements which (frankly) seems like a bit of a hack.
Let me say flat out: I am no DBA or rails guru. So, maybe none of this really matters since the queries are small (I’ve always played by the rule of thumb to make your DB queries as efficient as possible, and count for as much as possible)…
Maybe the answer is that you can solve all of this by caching, so don’t worry about what kind of SQL rails is using…
And, then again, maybe I’m the idiot who’s missing something really obvious.
barclay loftus