Category: Programming

I’ve been working on a tool to resize images, and it’s finally ready (i think) for public usage. I call it RESIZR. It makes use of scriptaculous and the GD library to resize images.
RESIZR – Resize Images Online

technorati tags:image+resizing, photo+resizing, resize+images+online, free+image+resizing+software

Previously, I talked about Validates_uniqueness_of and scope in rails

Well, what happens if you’ve got a case where, say you’re selling widgets, and you’ve got a join model set up with has_many :through relations, and you’re working with the following table:

(we’re listing stores that sell our widgets, and what size and price they sell them for)

Table: saleitems

Columns: widget_id, store_id, size, price

So, now, we want to validate that a widget can be sold at any store, and a widget can be sold many times at one store, but we can only sell a widget-store-size combo once. (You can’t sell a LARGE widget twice at the same store)

I think I was wrong, previously in my understanding. Now, I’ve written some code and see that you do the following:

You add a “validate_on_create” function to your saleitems model, and it looks like this:

def validate_on_create
   if Store.find_by_widget_id_and_size_and_store_id(widget_id, size, store_id)
   errors.add(‘you can’t do that’)

end

Thanks to: Rails Weenie for the answer

technorati tags:ruby+on+rails, validates_uniqueness_of, validates_uniqueness_of+multiple+scope, ruby+on+rails+validates_uniqueness_of+multiple+scope

I’m long term PHP developer, and I’ve recently started using Rails.  No, wait.  I was pretty much a deeply entrenched long term PHP developer, and I’ve recently been converted to the Cult of Rails.  I’ve been writing PHP since 1997, back before it had its very own recursive acronym and was called PHP/FI (Personal Home Page / Form Interpreter).  I’ve used it on many, many projects, and I’ve gotten pretty good at making it do whatever the hell I want it to.  If you’re a programmer, you know this concept.  Once you work with a language enough, it becomes second nature — you don’t have to look things up, and you don’t have to think about the tools, you think about what you’re doing, and that makes you a whole lot more productive.

So, I also keep up with things in this Web 2.0 internet world.  I know how to wield Prototype and Scriptaculous, and Model View Controller (MVC) is nothing new.  There’s lots of fanfare about how Rails “brings everything together” and is “omg so great.”  I took some of it as zealotry and the rest as people new to doing web apps finding a tool that’s better, than, say, ColdFusion. (Note: I hate ColdFusion)  Part of this is because so many designers are doing coding with Ruby on Rails.  So, I’ve been watching from the sides, but I haven’t actually gotten into Rails.  Why?  I’ve written a list.  I think a lot of developers would be served by reading this
list and taking home some of the points.  Anyway, here goes.

Bad Reasons not to use Rails:

1) It’s not PHP or your other alternative favorite language.

This is huge.  There’s just something that feels wrong about having to look up how to print to the screen or write to a file.  It’s been so long since many of us have had to read a manual for anything but, “Oh, what’s the syntax on that command again?” that we’re uncomfortable having to do it again.  This is essentially supreme laziness.  You don’t want to learn something new (Ruby), so you’re going to come up with excuses not to.  Let me tell you something: In this business, you either keep learning new things or you become irrelevant.  Ruby is not a weird language.  You will not have a hard time with it.  Just get a good syntax guide and keep it handy.  I promise you, Ruby is not hard.

2) But I don’t have to learn Ruby, I can just use Symfony, CakePHP, PHP on Trax, or the like.

I tried this, see.  This was my excuse not to learn Ruby — “I’ll just use a Rails Clone,” I told myself.  Well, blearg to that.  I actually tried three of them before trying rails, and let me tell you something: none of them compare.  Whether it’s features or documentation, none of them are really there yet.  These kinds of flexibile MVC/ActiveRecord style frameworks are still in their relative infancy, and Rails in 6 months is going to be 6 months better than it is today.  The other projects are months and months behind Rails, and in 6 months, they may not even be to where Rails is now.  Especially with documentation.  ESPECIALLY WITH DOCUMENTATION.

Rails does not have good documentation.  This means that the other guys’ documentation is horrible, horrible crap.  Also, Rails has several books, which basically gives you somewhere to go when you need help.  There’s no CakePHP book.  There’s no Symfony book.  Developers of other projects: If you want traction, you NEED documentation.  Orders of magnitude better than you have now.  Person considering Rails:  you need documentation.  Seriously, for something as big as this, you can’t just fiddle around, you’re not writing it yourself, and it’s a huge pain in the ass to look under the hood every 10 seconds — if you can even find what you’re looking for.  Rails does a lot of things for you, and you have to know what keywords to type where.  You need docs.  Good ones.  This goes for any big framework system.

3) I tried, and it’s complicated.

We’re starting to get to something resembling real problems, now.  Yes, you’ve tried using Rails, and yes, it CAN be daunting.  You have to do things “The Rails Way” many times, if you want to actually benefit from the framework rather than fight with it.

First and foremost, the biggest thing you have to accept is ActiveRecord.  Basically, for me, this means that I have to think about my database structure a little bit.  You’ll probably have to learn how to use something called join models, and you’ll have to learn about “has many through,” which is how you bend ActiveRecord to do your bidding in many cases.  However, the biggest thing for me was getting away from the notion I had in PHP coding of making one FILE that included other files and could be called directly.  Rails hides all of this from you.  There’s one “entry point” into the system, and everything past that is all “pretty urls that get parsed and sent to code” so to speak.  You’re not writing pages anymore, you’re putting pieces together in a framework to build an application.  After a while, you get used to it, and it really does make you more productive.

4) Frameworks are not flexible.

You’re right.  Frameworks aren’t for everything.  However, if you’re like me, you’ll spend a LOT of time just getting simple CRUD (create, update, delete) going, writing some SQL by hand.  Even if you’re highly motivated and a fast coder, this takes a lot of time.  My point?  Even if you spend some time futzing around with bending Rails to your needs, you’ve got ample time to spare, because you didn’t have to do a lot of repetitive busywork.

Point two is — Rails is pretty damn flexible.  Most of my, “oh, i can’t do that in rails” moments are falling by the wayside.  As I become more familiar with rails, I learn more and what I had presumed were inflexibilities are really just gaps in my knowledge.  In other words, most of the so called inflexibility is more like, “I’d have to write code to do that…” Which is exactly what you’d have to do in any other environment.  It’s just that with rails, you get so used to having everything automated, you are reluctant to actually write any code.  Yes, that sounds horrible, and it’s partly because I’m still learning rails.

You see, with PHP and no frameworks, you’re essentially writing all the code yourself.  This is fine and dandy, and you can do pretty much whatever you want.  However, with rails, you have to do things within the framework.  You have to know where things go, how to add capabilities to the scaffolding that gets built for you.  In most cases, the framework isn’t inflexible, it’s that you have to have knowledge of the framework on top of knowledge of the basics (code, get, put, http, forms, html, etc).  You have to know a bit more, but you get LOTS in return.

So, inflexible? I dont think so.  Rails is still low-level enough to not put TOO much burden on you.  Extending a content management system like drupal could lead you to some inflexibilities.  Rails isn’t a CMS, it’s a framework for building web apps.  This is one time where a framework really isn’t locking you into that much.

5) It’s slow.

This is a problem with ruby on rails.  It’s interpreted.  There’s also another problem with an easy solution.  If you want to use rails with apache, you need to use either fastcgi or fcgid, both of which are kinda like daemons that run rails, keeping things running, so that when a user makes a call on the application, all of rails doesnt need to re-load.  This makes rails LOTS faster.  However, ruby is still an interpreted language, and it’s definitely NOT as fast as PHP + Zend + a good code cache.

This is probably the only good reason to not use Ruby.  However, 90% of your application will probably be just fine, and, if you really need to, you’ll be able to code up your whole app, then rewrite the hotspots in another language in less time than it takes to write the whole thing in PHP.

Additionally, there will probably be a Ruby compiler of some form out for use with rails at some point.  My guess is that at the pace the rails folks operate, we’ll see a ruby compiler out in less than a year.

If you need optimization NOW:

• Optimizing Rails Resource Usage
• Speed Up Ruby on Rails with Memcached

Anyway, one final thought.  I’m not giving up PHP, it’s still very useful.  However, I *have* drunk the rails kool-aid, and it tastes pretty good.

technorati tags:ruby+on+rails, ruby+on+rails+is+bad, rails+flexible, cakephp+symfony+rails, reasons+not+to+use+rails