Exploring Active Record 266
An anonymous reader writes "Everyone knows that no programming language is a perfect fit for every job. This article launches a 'new series by Bruce Tate that looks at ways other languages solve major problems and what those solutions mean to Java developers. He first explores Active Record, the persistence engine behind Ruby on Rails.'"
Comment removed (Score:5, Insightful)
Re:Anyone else Railed-out? (Score:2, Insightful)
TBH It just sounds like you don't know what you are doing.
Re:Uhhh.... (Score:2, Insightful)
I program in raw machine code. It's a perfect fit for every job, every time!
How's client-side web page scripting working out for you?
Re:Anyone else Railed-out? (Score:3, Insightful)
Re:Anyone else Railed-out? (Score:4, Insightful)
One thing I like about ActiveRecord is that it is database agnostic. If I need to, I can move my app from MySQL to Postgres to Oracle with very little effort. The other thing I like is that it provides a clean separation between data storage and business logic. Database programmers seem to hate that approach because it shifts the center of gravity away from the database and toward the web app. This is great for maintainability of application code, but I don't know how well it works for sharing data among multiple apps. I don't know if anyone has gotten ActiveRecord models to support the same level of integration as you can get with multiple apps running off of one database - I think there needs to be more work done to enable that, but I expect to see that work done fairly soon.
The other cool thing about ActiveRecord is the use of metaprogramming, as discussed in the FA. I don't think we'll ever see a Java persistence layer that is as functional and easy to use as ActiveRecord, because the kind of metaprogramming tricks that Ruby enables are so much harder to do in Java.
Re:Anyone else Railed-out? (Score:3, Insightful)
Furthermore, Rails promotes good coding and design habits. While you may not agree with Model-View-Controller (not sure why, but that's a personal choice I guess), at least Rails imposes some design pattern on the developer. Without this, an inexperienced developer will be able to write completely unmaintainable code.
Re:Anyone else Railed-out? (Score:3, Insightful)
A background of incompetence? Funnily enough when I picked up PHP, your disaster scenario was what most people seem to do without thinking about it. In my case, the MVC components are, respectively, PostgreSQL, HTML templates and PHP.
If your original system was designed with MVC in mind, moving it to Rails should have been easy.
I think you'll find that most Rails developers hold that it's much easier, cleaner and safer to start a project with Rails in hand, rather than graft Rails onto a pre-existing database.
What if you forget a single function call at the beginning of one of those pages? Do you suddenly allow objects to be populated with rogue data? Rails has things like filters that make sure certain methods get executed before all actions in a given controller.
Error checking and testing suites aren't impossible for a C developer to comprehend, you know.
Re:Anyone else Railed-out? (Score:2, Insightful)
That's all well and good, for a subset of database functionality. ActiveRecord reminds me of wxWidgets - smoke and mirrors, bloat and lowest common denominator functionality. But don't get me wrong, for a great many jobs it's adequate and there for the taking.
The other thing I like is that it provides a clean separation between data storage and business logic.
That's really just a matter of the intelligence/discipline of the developer. Inexperience can mitigate the benefits of any technology, and believe me I've seen code to prove it.
Re:Anyone else Railed-out? (Score:2, Insightful)
If you wanted to, you could turn your HTML templates into RHTML (Ruby HTML). If you PHP really was just acting as a controller, it should be easy to re-write that in Rails, as it uses the same design pattern. As far as custom SQL, it's easy to keep that in Rails (although it's not really the "Rails way"); you can execute arbitrary SQL statements just like in PHP.
Ultimately, I think we all code in what we're comfortable with. To many programmers, Rails fits their mind well because of the MVC pattern used, and in general the way Rails handles everything.
However, I still think custom frameworks are the root of all evil for anything but the smallest projects. Do you, a single developer, really have the guts to say that your framework is better than something that has been developed by a core team of 15 over about 2 years? Do you really think that your framework is that great, that you're willing to have to train someone else to use it, when you could just leverage the work of the community? Creating a custom framework is, in all but the most obscure cases, a supreme act of selfishness.
Next think you know...you'll be rewriting everying. You, the uber code, know best! Heck, we can write it all in C! Just rewrite all the good stuff that you take for granted in PHP. Why use PHP's session handling when you can roll your own? Oh, right, there's a whole slew of security issues there and you're likely to fuck up some small detail and open up some nasty hole where one user can get to another's session. Etc, ad nauseam.
Re:Still looking for an IDE (Score:1, Insightful)
language matters a great deal (Score:5, Insightful)
The differences between C++, C#, and VisualBasic are far deeper than syntactic. C#, for example, guarantees fault isolation, while C++ does not. C# has full reflection, while C++ does not. Programmer productivity in different languages can be orders of magnitude different.
Of course, most working programmers have the same superficial view of programming languages as you do and will make the same glib and ill-informed analogies to natural languages that you did. That's why people keep choosing C and C++, believing the differences to other languages to be merely syntactic, and then producing code that crashes, silently mangles data, and has gaping security holes.
Fortunately, the herd mentality is driving even people who don't know what they are doing away from C/C++. Even your own company bills itself as a
Re:language matters a great deal (Score:3, Insightful)
Re:Anyone else Railed-out? (Score:5, Insightful)
I'm an 'SQL' guy myself and I'm not convinced by ORM tools - or at least the way they're being hyped as a solution for having to understand the DB (Newsflash : SQL is supposed to be an abstract query language so that the developer doesn't need to understand the DB - and look how that worked - answer : Mostly it does, but when it goes wrong you're dealing with a black box). I also think that the view of many Java (and Ruby) developers that a DB provides 'persistence' is wrong. It's a failure to understand relational theory - which at least, unlike most object modelling techniques, has a firm mathematical foundation. It's also a failure to use the tools provided to you (and when Bruce Tate complains about Java productivity, this tendency of Java developers might be part of the problem - it's 'not invented here' syndrome).
You could have used Ruby rather than PHP (a comparison I'd like to see) and I also think that there is much to be said for the MVC structure compared to shoving everything into each page.
It feels a bit clunky in the current paradigm (pages generated on the server and refreshed to the client, client events sent to server) but it works very well as a design, and I can see it becoming more important again as browser apps support more dynamic features - getting back more towards a client-server architecture with the model on the server, view on the client. (Or more likely a local model for performance and some form of background syncing).
Re:Anyone else Railed-out? (Score:5, Insightful)
Inexperience and ignorance. And it sounds as if it applies to you and to this situation. I don't see how you can rant against "bloated" technologies you never bothered to learn. Without that knowledge, you don't understand everything that's happening behind the scenes and, since that scares you, you stick with the subset of the developmentatl universe you do know, no matter how appropriate, or inappropriate, it may be to the problem at hand.
I strongly suspect that once you've moved on to other victims, the next developer the guy hires will take one look at your carefully-crafted optimum solution, shudder, and then rewrite the whole thing.
Re:Anyone else Railed-out? (Score:5, Insightful)
So... you basically wrote the application (minus the controller), and then started thinking about using a different platform? Is it any surprise that you didn't want to switch over to Rails (disclaimer: I'm not a Rails guy. In fact, I work for the competition [djangoproject.com])?
OK. It's not like somebody's holding a gun to your head and saying you have to use a framework. Personally, I see a lot of use cases where a framework makes development a lot simpler and easier to manage, because so much of the tedious overhead of web-app development has already been done for you. Think of the framework in terms of an operating system you're programming for: rather than writing all your own device drivers, routines for drawing stuff on the screen, accepting keyboard/mouse input, etc., you've let someone else solve those problems and you're just using the provided APIs to hook up the logic that's unique to your application. And with a framework, rather than write database drivers, routines for accepting and routing input, etc., you've let someone else solve those problems and you're just using the provided APIs to hook up the logic that's unique to your application. Using a web framework is no different, really, than using any other shared library.
As for all the cruft you complain about, when was the last time you used every single bit of functionality provided by a shared library you linked a C application against? Or is it only bad to draw in automagical functions you won't use when the application isn't being compiled? ;)
Re:Now, more buzzword-friendly? (Score:3, Insightful)
Article: "here is a link to an interesting review of (insert technology here)".
Random guru: "That's nothing! I wrote something similar myself 6 years ago using perl/punchcards/blood from my own hand!"
Elitist Java developer: "Hahaha! You amateurs! How does your pathetic toy deal with redundant HA database clusters in a real-time mission-critical enterprise environment with a 5-nines uptime guarantee? Come back when you've grown up!!"
And so on. Personally, I'm a big fan of Ruby on Rails. I'm rather bored of seeing it compared to Java, a language I have never used. I moved to RoR from PHP, and let me tell you, its like a breath of fresh air. Yes, I could develop the exact same websites using PHP, but it involves writing a lot more code. Aren't computers supposed to do mundane work for us? Why make life difficult for yourself - I'm interested in results, not in worrying about whether I've escaped my SQL queries correctly using some function I had to write myself because PHP can't even do that properly.
Bottom line - RoR means better sites with less work. And that means more time to concentrate on making sites better for users, which is really what its all about.
Now, if he could apply the same wisdom to SQL, etc (Score:3, Insightful)
My favourite (Score:3, Insightful)
"Hahaha! You amateurs! How does your pathetic toy deal with redundant HA database clusters in a real-time mission-critical enterprise environment with a 5-nines uptime guarantee? Come back when you've grown up!!"
Rails is scalable, but not in an interesting fashion at all. You want more processing power, you run more instances. Where's the fun in that? I love it in Java land, where creating something scalable inevitably means exciting things like building a single JVM that runs on multiple machines, or wrapping things in five layers of EJB so that they can work across multiple machines.
Re:Anyone else Railed-out? (Score:2, Insightful)
I think Ruby and Rails are about the right ideas for our current and near future environment -- cheap cpu's, tight schedules, evolving web standards, clueless users, heterogeneous client hardware (browsers and pda's) and ever faster networks.
And, by the way, the current Ruby implementation is not quite as mature as the current Perl or even Java implementations. This will change. The sweet spot for using Rails isn't today, it's the next 5 years or so. So now would be a good time to get the experience.
Not to knock PHP, it lets just anybody put together a dynamic web site without having to know too much. It's a straightforward system ideal for power users who don't want to be computer scientists but who need to build out their ideas. I have a neighbor who's expertise is in marketing and home products who is building his own product line with PHP. Ruby would be beyond him. Who knows, he might just strike it rich with PHP.
Re:Anyone else Railed-out? (Score:2, Insightful)
Re:Anyone else Railed-out? (Score:3, Insightful)
This is an unfortunate side-effect of working in a pre-1.0 environment, regardless of what it was. I believe the current plan is to not break any APIs until 2.0 hits (and maintain the 1.x branch for security updates once 2.0 hits)
As for the methods they create behind your back, let's just call it what it is: Self Modifying Code. How the heck am I supposed to debug code that doesn't exist at design time?!?
Firstly, it's not self modifying code, it's metaprogramming. Self-modifying code changes during runtime. Metaprogramming (and all the class-method shortcuts you have available for ActiveRecord and ActionController subclasses) writes code for you, just like C preprocessor macros, but once it's loaded it's done. As far as debugging, I've been working in rails since July last year, and haven't needed a debugger once. Break your methods into small bitesize chunks, and write a decent test suite alongside - If something's wrong, small methods make it easier to isolate, and your tests will tell you exactly what the problem is.
But I feel that Rails' implementation of MVC is simplistic and naive. Also, despite all the hype, they haven't solved any NEW problems in web app development.
That's entirely true. Rails doesn't solve any new problems. It's just an MVC. What's special about it is that it gets out of your way with a minimum of fuss, allowing you to spend more time solving your problems, rather than getting the framework to do what you want.
For example, when is somebody going to tackle:
1. standardized, cross-app, cross language/framework logins
4. built in support for session sharing across multiple servers (with the session data kept in the DB, not in memory
Point 1 is being worked on as a plugin to rails, but I'm not sure I'm entirely sold on the idea. Point 4 is already done in rails, you can set one config variable (commented out in environment.rb in a default rails install) and use either your existing app database or an instance of memcached on another server.
I'm not sure what you're getting at with 3 (I would assume that should be the job of a load-balancer or the database itself), and I'm not sure I want to see 2 at all...
Re:Anyone else Railed-out? (Score:3, Insightful)
Re:Anyone else Railed-out? (Score:2, Insightful)
Use of a framework requires zero time to comprehend if you are familiar with it. I was mainly thinking of extending the codebase, though. The bigger the codebase, the worse a handrolled framework gets. I currently work on a large perl web app with a handrolled framework, and even trivial things like adding a couple pages are just a kick in the dick. Major changes are hell.
I had to add some code to track items added and removed from the cart a year and a half ago. This took me over a month because I had to:
- Insert code before and after every change to the cart. Logically, I should add this in one place - the model's add, remove, and modify item methods. Oops, SQL might modify shit behind my back without hitting the object model, so that's out.
- Store the carts's previous state to make sure I didn't double-report changes. There's no session to store anything in the app's framework, so I had to use cookies. This lead me to find out that headers had already been sent by the time I had tried to set the cookie. OOPS. Guess I need to write an output caching layer. Then I had to track through massive amounts of handrolled framework to find every piece of code that was bypassing my cache by calling print() instead of $context->print(). Then I had to alter them to take a context. Then I had to set the context for every single template used by the cart, because half the templates didn't share common init code. Output caching should be handled out of the box.
This isn't exactly challenging stuff as far as programming goes.
No, not when you've set the bar so low that "it works" is your justification. I don't want things to work, I want them to work beautifully, scale, extend easily, and get rid of all the Repetitious Shit like "select total from orders where order_id='1234'" by replacing it with Good Shit like order = Orders.find('1234').
It still amazes me just how much code people write for web apps these days.
Because you are insane. The web is just an interface; the backend can do anything and often does.
most of the mental effort went into the database and associated triggers/functions, and practically all the scripts do is make SQL queries presentable.
That's because you've pushed your business logic into the DB, which makes baby Jesus cry.
I'm still wondering about the C rewrite as well. I'd love to know how your app became CPU-bound before it became IO bound. The Rails solution to this would be to start template caching, not rewriting everything in C.
Re:In a comparison, Ruby suffers for one big reaso (Score:5, Insightful)
Re:In a comparison, Ruby suffers for one big reaso (Score:3, Insightful)
Okay, I won't, but can you tell me why I would need more than 16 bits to store a single character ? Why the hell do we need so many characters in the world ? Are there so many ways to say "Hello" that we need millions of characters to communicate with our neighbors ? I'm not saying everyone should speak english (I'm french myself), but eventually the various dialects will condense into more portable languages.
Of course. For example, we don't need to runic characters in real life, however if you wanted to write a textbook on Anglo-Saxon linguistics, you'd be up shit creek if those characters weren't in there. Same goes for any given language.
That's the real trick, isn't it? (Score:3, Insightful)
You're right, that the language itself is not the only thing that matters. Extra libraries to work with makes life much more pleasant.
But what's under the hood of that do_something_with_file_data? In this fairly trivial example, there's not much difference between a do_something_with_file_data in C versus Perl.
Nice code examples deleted 'cause of /. stupid lameness filters inserting random spaces, even when I had spaces nearby. GRRRR! Suffice to say both were functionally equivalent and of about the same length: about 8 lines for reasonably readable code that output reasonable, though not strictly standards-compliant, HTML.
For more complicated web work, however, I would still maintain that there are better languages than C (and Perl for that matter) to be doing the work. I'm not for a moment suggesting that I can replace what would take me a year in C with a day's work in Python (excepting the library issues), but I think that the so-called "scripting languages" are faster to develop many types of applications even without the library advantages they have.
Execution speed arguments are less a function of the language itself than a function of those environments the languages themselves typically operate in. There are python, perl and Java compilers and I'm sure somebody has made a C interpreter for some strange reason. Most applications do not need to be as efficient as possible by virtue of the fact that a lot of them sit in an idle state most of the time anyway. There are notable exceptions (scientific computing, games, etc.), but there you're going to be writing as close to the hardware as you dare and maybe even C is too much of a luxury and you'll have to write assembly.
I agree that a language choice, given appropriate and featurewise compatible libraries existing for the task at hand, isn't usually going to make a many orders of magnitude difference in development speed. I do still contend however that appropriate languages to the task at hand can save you a decent slice of project time. My gut instinct would be to say the average would be around 20 to 30. Not massive, but noticeable on the bottom line. Sometimes that choice will even be C. And some things still need the raw power of C. Not bagging on C at all, here! It was the fifth language* I learned, after TRS-80 Extended Color Basic, 6809 Assembly IBM 360 Assembly, and Pascal. Of those five, it's the only one I still use at all, much less remember, and I still love hacking on it.
I will concede that my gut is not (perhaps) as accurate as a study, but my only point was to say I will still trust my experience over a random stranger on Slashdot waving "studies" around without any reference to what they're referring to.
*- FORTH was sixth. I've forgotten it, too.