Opinions on Opinionated Software
David Heinemeier Hansson is the creator of Rails and a partner at 37signals. He'll soon be moving from Copenhagen to Chicago as he leaves his place of birth to join the company headquarters.
LJ: For our readers who are unfamiliar with Ruby and Rails, can you give us a short description of what they are and what makes them different from other development environments?
DH: Ruby is a dynamic and object-oriented programming language created in 1995 by Yukihiro Matsumoto. It has been described as a cross between Smalltalk and Perl, but I don't think that juxtaposition does it justice. Ruby is, more than anything else, a language for writing beautiful code that makes programmers happy.
Rails, then, is an attempt to mold the beauty and productiveness of Ruby into a solution for Web applications. We've sought to adhere to the same core principle that guided the development of Ruby: make the programmer happy!
This might all sound mighty fluffy, but only until you recognize that the single-most important factor in programmer productivity is motivation. And, happy programmers are certainly motivated programmers. Thus, if you optimize for happiness, you're optimizing for motivation, which ultimately leads to an optimization for productivity.
LJ: What is Rails? Why was it developed?
DH: Rails is an extraction from a solution to a real problem. It's not a science project. It's not something clever men sat down and designed in the highest of ivory towers. It's simply the generic pieces that were left after I tried to use Ruby to create Basecamp—the Web-based project management system from 37signals.
That means it's a very pragmatic, very targeted framework with a strong sense of direction. You might not share its vision, but it undeniably has one. I like to call that opinionated software. And Rails sure has a lot of opinions.
From one point of view, it could be said to be the collection of opinions I have about how Web applications should be constructed. Surely you can use Ruby on Rails without sharing all my opinions on how to create Web applications, but the more opinions you share, the less work is put upon you.
And, these opinions are surprisingly simple. They aim to give most people most of what they want, most of the time. It's a strong disagreement with the conventional wisdom that everything should be configurable, that the framework should be impartial and objective. In my mind, that's the same as saying that everything should be equally hard.
LJ: I've been reading about Active Record and the ORM (Object-Relational Mapping) capabilitites (or how the application interfaces with databases) that are available using Ruby on Rails. Can you comment on this?
DH: Active Record has, by many, been called the crown of Rails. Its core mission is to make relational data mesh seamlessly with an object-oriented domain model. And to do so with a minimum of explicit configuration.
So, you'll have a Person class that's automatically mapped to a people table (notice the cases and pluralization that Rails automatically figures out). This Person class will then have a first_name method if the people table has a first_name column. So, we're using reflection and conventions to escape the XML situps that plague frameworks of the old world.
Although the lack of explicit configuration scores high points with the Enterprise crowd used to Hibernate, EJBs and other Java frameworks, it's the mere notion of ORM that wins big with the PHP/.NET crowd. Active Record relieves you from the vast majority of all SQL writing. It's automatically constructed on the fly. No more three-line INSERTs, no more repetitive, tedious UPDATEs. The only SQL left is the bottleneck-clearing work where actual brainpower is involved on how to make this query go really fast.
LJ: For many of our readers to adopt Ruby and Rails (or convince their management to let them), they need real success stories. Where has Ruby and Rails been used to build scalable, production applications?
DH: Ruby on Rails has been a huge hit inside a lot of organizations. We have some 400 people signed up as working either partially or completely in a Rails-related job. So, like an iceberg, the bulk of the action happens below the surface.
But, we do have a good number of public success stories too. My own company, 37signals, has four widely popular applications used by hundreds of thousands to manage their projects (Basecamp), their personal life (Backpack), their to-do lists (Ta-Da List) and their collaborative writing (Writeboard). That suite has been the number-one poster child for Ruby on Rails and has helped win over a lot of doubters.
But 37signals is by no means the only small team doing big things with Ruby on Rails. The Robot Co-op has a suite of social networks that includes 43things, 43places and 43people. Together, these networks push more than two and a half million dynamic page views a day across their three-machine setup.
Odeo is running Ruby on Rails to power its podcasting portal in front of thousands of subscribers. Evan Williams created Blogger and knows a thing or two about running a huge, public site. He's at the wheel at Odeo.
Strongspace is just one of several Rails applications in the making from TextDrive. They provide gigabytes of secure hosting in the sky. It's a really cool and smooth site by the same guys that carry the title of being the official Rails hosting firm.
And, that's just a small taste. We have major applications in everything from e-commerce to productivity to content—you name it. There are very few kinds of Web applications left that Rails hasn't been used to create.
LJ: By the way, I've been a Backpack user for a while and I love it. Was it completely developed using Rails?
DH: Backpack is indeed 100% Ruby on Rails. When it launched, it was a mere 2,000 lines of code.
LJ: Java had been around for a while before it really penetrated the enterprise. It took the development of J2EE for it to establish itself as a true “enterprise development platform”. The addition of transactional management, flexible deployment strategies and so on seemed required for it to mature into that role. Could you see Ruby and Rails eventually following a similar path, or do you think its role will be something different?
DH: We have a wide enterprise audience that uses Rails simply because it gets the job done, faster. I think we've seen the peak of Java in the enterprise. I'm sensing an understanding that while Java and the J2EE gang certainly has its uses in legacy integration, huge distributed setups that require two-phase commits and so on, it's way overkill for the majority of applications created in the enterprise.
Dave Thomas from the Pragmatic Programmers recently expressed this as “cracking nuts with a sledgehammer”. Yes, a few special jobs do need sledgehammers. But you don't need to use it [a sledgehammer] for all the other jobs that need to get done.
That's why having a company standard on something like Java and J2EE seems so nonsensical. Why would you use the heaviest and slowest machinery to solve the 80% of the business that would rather have its valuable software two, three, five or ten times faster? Or, whatever the multiplier is in your environment. So, keep the big guns in store for that last 20% that actually requires it.
LJ: Is there anything else you think is important to tell our readers about Ruby and Rails?
DH: Give it a try! We've fought hard to make Ruby on Rails the easiest Web-application framework to try out. Get Ruby, get RubyGems (the apt-get of Ruby libraries), gem install rails, rails my_application, and you have your application skeleton running and ready to produce.
It's hard to relay in words just how fast and easy it is to get started. So, I would invite your readers to check out the 15-minute video on the Rails Web site where we build a complete, if simple, blogging engine.
Resources for this article: /article/9015.
-- Kevin Bedell Editor in Chief, Linux Journal "Imagination is more important than knowledge" - Albert Einstein http://www.kbedell.com
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide