20 Reasons Why Every Web Designer Needs to Learn Rails [ROR Network]

 

20Reasons

She told me her husband was being downsized. He was 52 years old, been with the company for twenty. He was a COBOL man. Nothing but a COBOL man his entire career. But the company needed more than a COBOL man. So they let him go.

That is a true story. It’s about ten years old. But it’s not an uncommon story, especially in today’s rapidly-changing tech environment and somewhat dismal economy.

In fact, you probably know somebody that’s been let go or overlooked because of a lack in a certain skill set. The only difference is that you don’t have to wait until your early fifties to get downsized.

Today that can happen at 30. Even 25.

Enter Ruby on Rails

Typically the guy or gal with the most developing tools under their belt wins. It leads to the sweetest projects. The most perks. The best salary.

This is where Ruby on Rails (RoR)—and learning the framework—comes in. If you’ve been building websites for long you have no doubt heard about RoR. It’s a full-stack framework that covers both front and back end design. It’s at the heart of sites like Twitter43Things and Basecamp. Major Brands like Amazon and eBay even have RoR projects. And in the hands of a versatile developer RoR is a potent tool. Let me show you how.

1. Stalled Career

I don’t care how old you are. An old dog can learn new tricks. An old dog NEEDS to learn new tricks if he wants to stay current, marketable and in demand.

If your current job has hit a snag and you find yourself bored (and maybe even threatened with a layoff), then taking the time to learn Ruby on Rails may be just the thing you need to put a jolt back into your step. And give your boss something to think about.

2. Tired of Other People Getting Hired

Don’t you hate it—going through the interview process only to find out that someone else was picked instead of you? It could’ve been for a promotion at your current job or at a new company.

What’s worse is when you are job hunting and you stumble across dozens of opportunities (regarding the demand for Ruby developers, see no. 16)—but you aren’t qualified for because they want RoR experience and you don’t have it. That’s not a good feeling.

3. Bored

If you are like me, then you are unapologetically curious, incorrigibly creative and easily bored. This probably also means you are super-duper smart, hyper competitive and a sucker for a good challenge.

Learning Ruby on Rails just might be what you need right now. And why not—it’s a heck of an effective way to kill time.

4. Get More Things Done

The language (Ruby) on the framework (Rails) means that you can accomplish more with less, better structured code. Since code can be re-used changes are easy, making iteration and experimentation painless. Learning Ruby on Rails will help you knock out that killer idea listyou’ve been sitting on for months.

5. Eliminate Lame Tasks

Rails is built on Ruby, the dynamic and object-oriented language. This means that you can better use your time. For instance, RoR will handle all database communications, provide a template system for handling page sections and layouts, process Ajax updates and a wide set of plugins that make feature implementing easy. In other words, RoR takes care of the boring stuff while you can focus on the cool.

6. Building a Complex Website

Building a website is probably the most common scenario in which you would use RoR. However, you could also use PHP. Why use one over the other? The argument goes like this: if you are just adding simple functionality to a basic, straightforward website, then use PHP. On the other hand, if you are building a complex website or app that involves a database then you’ll want to use Rails.

7. Plan on Building More Websites in the Future

Learning a new language and tool takes time and effort. So if you think that you might be able to use Ruby on a single project—and don’t think you will have to use it again—it’s probably not worth the effort.

However, if you plan on continuing to build complex websites and applications then the investment in learning Ruby on Rails is probably worth it.

8. Serve a Particular Market

Some developers like to work in a particular market. So they build a set of specialized skills that suits that market. This will lead them to usually being hired by designers who don’t have expertise in a set of skills like RoR. This means you won’t be working for clients. You will be hired for your particular skill set by an agency.
The other scenario is that you work directly for the client. They don’t care whether you use PHP or Ruby. They just want you to build them a website that will do X, Y and Z. It’s your job to figure out how to effectively do that, so knowing both PHP and Ruby is a must.

9. Join a Great Community

Even though RoR is a relatively new framework, it has certainly built up a robust community full of nice people who want to help you learn. These communities are where best practices are shared, reinforced and even questioned. You will feel comfortable asking just about any question.

The Rails Community is one of the main reasons to learn Rails.

10. Collaborate with Other Developers

Just like web designers have universal standards they have to obey, reliable Photoshop workflows and proven CSS tricks, the same is true for Ruby on Rails. The way apps are built are getting more uniform as the Ruby community continues to grow, so working and collaborating with other developers is way easier than it was before.

11. Learn to Code

Maybe you don’t know how to code at all. You could be a writer who is bored (see no. 3) and wants a hobby. Or you could be an entrepreneur who’s got an idea for a new web app and you want to see if the thing has any legs to run on.

Thus, you want to learn how to code.

Now, you don’t need any programming experience to learn Ruby. However, much of what you learn about Ruby will be lost on you if you don’t. It’s sort of like knowing the answer to an arithmetic problem—but not knowing how you got the answer.

12. Become a Better Coder

More than likely, though, you are a coder. A good one. But you want to become better. Well, learning Ruby is one way you can do that.

However…

People can argue until their faces are blue about which skill sets are the best: PHP, Java, Python or Ruby. But at the end of the day I think they would all agree that what really counts when it comes to being a better coder is to have an understanding of multiple server-side languages, whether it is Python, Java, Ruby or all of the above. The more the merry because doors will open for you where they might be otherwise shut.

13. You Already Know PHP

I know some passionate RoRs who will say hands down that you do not want to learn RoR until you’ve got a handle on PHP. This doesn’t mean you have to master PHP. All you need is just a basic understanding of how to get a few things done in PHP.

But if you already know PHP, then the transition to using RoR is seamless. See, the nice thing about RoR is that you don’t have to code from scratch every time you need something done. That’s what an effective framework does. But it still helps if you know what’s going on at a lower level. So, if you are a PHP pro, then I recommend you jump on RoR right away. You’ll learn it pretty quickly.

14. Express Your Ideas through a Computer

Famed Ruby evangelist _Why wrote in his book _Why’s Poignant Guide to Ruby, “I’ve noticed that many experienced users of Ruby seem to be clear thinkers and objective. In contrast to: heavily biased and coarse.”

Like many programming languages, Ruby will teach you how to express your ideas and stories through a computer. The language is like a tool that allows you to link your mind to the real world. In fact, you may discover that Ruby is a fantastic language that lines up with your own mental model of the world. In other words, if you struggle getting your thoughts out of your head, then Ruby just might be the right tool for you.

15. Build Your Personal Brand

There’s a reasons there is a demand for Ruby on Rails developers: it’s the fastest and most efficient way to build apps for the web. And big brands to brand-new startups are tapping RoR developers to get that speed and agility.

And get this: that demand is likely to continue. So learning to build sites with Rails is a valuable step in your web development career.

16. Won’t Be Using WordPress and Co.

PHP is the programming language for Drupal, Joomla, Magento and WordPress. So if you want to develop for those, you will need PHP. Not Ruby.

However, some suggest their future is uncertain. So, if you are in it for the long haul and want to progress with the web, go with a more progressive skill set like RoR. Again, it is probably help for you to learn PHP first if you don’t know that language already.

17. Stay Current with Web Changes

I think it’s become clear by its popularity that Ruby is where the web is headed. Scratch that. Ruby is where the web is now. And that demand is only going to continue.

There are so many things that make Ruby popular. Console tools like irb allow you to test any code at any time—before adding it to a file. Huge in terms of efficiency and accuracy, as is the fact that you can unit test, which provides huge productivity boosts. Just like PHP had its heyday, RoR is having it’s now.

18. Re-Use Software Down the Road

One of the stellar beauties of RoR is that you can use and re-use software for different projects. This is what RoR creator David Heinemeier Hansson (37signals) had in mind as he built their flagship product Basecamp.

During the development he took the apps underpinnings and created building blocks for future use. He made the framework extensible, expandable, and multi-purpose. Think plug-and-play.

He then shared the software with the open source market where the framework was improved and extended. Nearly ten years later it is now a solid and reliable software development platform that’s powering some of the most popular and powerful sites out there.

19. You Know Ruby (the Language)

Learning Ruby (the language) before Rails (the framework) is a wise move because it helps the developer to understand what is going on under the hood. Sure, the framework can do all the heavy lifting when it comes to building a web app, but it helps to understand how and why.

20. Learn the Better Language

That’s a loaded statement, so let me explain. As I mentioned above, there really is no “better language.” What there is are advantages and disadvantages.

For example, Ruby is a lot easier to read. One familiar comparison I’ve heard thrown around a lot is that Vanilla JavaScript is to jQuery what PHP is to Ruby. Ruby, like jQuery, is concise and logical. They both make sense and are easy to learn.

PHP, like Vanilla JavaScript, is a little long-winded and complex enough to cause your brain to hurt when you are trying to learn them. But PHP is way easier to learn than Vanilla Javascript, and Ruby is even easier still.

Conclusion

No doubt learning a major new skill set is no easy task. It takes time and sweat and discipline. You can’t take such an effort lightly. But if you do decide to take the plunge it will be worth it.

Not only can RoR provide you with a vast array of benefits like cutting through the headaches of web application development, but, more importantly, it can help you become that software developer that everybody wants. And who doesn’t want that?

Can you share any other reasons why web developers should learn Ruby on Rails? Any reasons why they shouldn’t? Would love to hear your thoughts.

 

10 Favorite Things About the Ruby Language[ROR NETWORK]

I work with Ruby every single day, and over time have come to really enjoy using it. Here’s a list of some specific things that I really like about Ruby. Some of them are obvious, and some are shared with other languages. The purpose is to share things I like about Ruby, not to compare and contrast with any specific language.

1. Dynamic Typing

There are very good things about statically typed languages, such as compile-time verifiability and IDE support. However, in my experience, dynamic typing really helps get projects bootstrapped and smooths along changes, especially in the early to middle stages of a project.

I’m very happy that I don’t need to create a formal interface for my new objects to implement simply to enable me to easily swap out that class for another later on.

2. Duck Typing

This is effectively just an extension of Dynamic Typing. In Ruby, methods that expect to be able to operate on String objects don’t do checks for is_a?(String). They check whether the object respond_to?(:to_str) and then calls to_str on the Object if it does. Similarly, objects that represent Paths in Ruby can implement a to_path method to provide the path representation.

In Rails, we use this technique for objects that have “model” characteristics by expecting them to respond_to?(:to_model). This allows us to support any object in relevant contexts, provided those objects can supply us with a “model” representation of themselves.

3. Awesome Modules

Ruby provides a language feature similar to “traits” in Scala, Squeak, and Perl. Effectively, Ruby modules allow the dynamic addition of new elements of the class hierarchy at runtime. The use of super is dynamically evaluated at runtime to take into consideration any modules that might have been added, making it easy to extend functionality on a superclass as many times as desired, without being forced to decide where super will land at class declaration time.

Additionally, Ruby modules provide the lifecycle hooks append_features and included, which make it possible to use modules robustly to isolate extensions from one another and to dynamically extend classes on the basis of feature inclusion.

4. Class Bodies Aren’t Special

In Ruby, class bodies aren’t a special context. They’re simply a context where self points at the class object. If you’ve used Rails, you’ve probably seen code like this:

class Comment < ActiveRecord::Basevalidates_presence_of :post_idend

It may look like validates_presence_of is a language feature, but it’s actually a method being called on Comment that is provided by ActiveRecord::Base.

That method can execute arbitrary code, also in the context of the class, including creating new methods, executing other pieces of code, or updating a class instance variable. Unlike Java annotations, which must be run at compile-time, Ruby class bodies can take runtime information into consideration, such as dynamically supplied options or the results of evaluating other code.

5. String Eval

This is likely a heresy. I’m not referring to arbitrary runtime String eval here, but rather String eval that is used to create methods early in the boot process of a Ruby application.

This can make it possible to take Ruby-defined structures, like Rails routes or AOP-definitions, and compile them into Ruby methods. Of course, it is possible to implement these things as add-ons to other languages, but Ruby makes it possible to implement these sorts of things in pure Ruby. It is, to a large degree, a self-hosting language.

6. Blocks and Lambdas

I’ve said this a few times and I’ll repeat myself: I don’t consider languages without anonymous lambdas to be powerful enough for me to use day-to-day. These constructs are actually extremely common, and found in languages as diverse as Ruby, JavaScript, Scala, Clojure, and of course Lisp.

They make it possible to implement block-scoped constructs that look like language features. The most common example usage is for File operations. In languages without lambdas, users are forced to use an inline “ensure” block every in the same lexical scope that they originally opened the file in, to ensure that the resource is closed.

In Java:

static void run(String in)throws FileNotFoundException {File input = new File(in);

String line; Scanner reader = null;

try {

reader = new Scanner(input);

while(reader.hasNextLine()) {

System.out.println(reader.nextLine());

}

} finally { reader.close(); }

}

Among other things, the Java version needs to wrap the creation of the Scanner in a try block so it can be guaranteed to be closed. In contrast, the Ruby version:

def run(input)File.open(input, “r”) do |f|

  1. each_line {|line| puts line }

end

end

Because of the existence of blocks, it is possible to abstract away the need to close the File in a single location, minimizing programmer error and reducing duplication.

7. Combo Attack: Self-Hosting Language

The combination of several of the above features produce real-life examples of ways that we can “extend” the Ruby language in Rails. Consider the following:

  respond_to do |format|if @user.saveflash[:notice] = ‘User was successfully created.’

format.html { redirect_to(@user) }

format.xml { render :xml => @user, :status =>ted, :location => @user }

else

format.html { render :action => “new” }

format.xml { render :xml => @user.errors, :status => :unprocessable_entity }

end

end

In this case, we’re able to seamlessly mix methods (respond_to) with normal Ruby code (ifand else) to produce a new block-scoped construct. Ruby’s semantics for blocks allow us toreturn or yield from inside the block, further blending the boundaries of the code-block and language constructs like if or while.

In Rails 3, we introduced:

class PeopleController < ApplicationControllerrespond_to :html, :xml, :json 

def index

@people = Person.find(:all)

respond_with(@people)

end

end

Here, respond_to is provided at the class-level. It tells Rails that respond_with (in index) should accept HTML, XML, or JSON as response formats. If the user asked for a different format, we automatically return a 406 error (Not Acceptable).

If you dig in a bit deeper, you can see that the respond_to method is defined as:

def respond_to(*mimes)options = mimes.extract_options! 

only_actions   = Array(options.delete(:only))

except_actions = Array(options.delete(:except))

 

  1. each do |mime|

mime = mime.to_sym

mimes_for_respond_to[mime]          = {}

mimes_for_respond_to[mime][:only]   = only_actions   unless only_actions.empty?

mimes_for_respond_to[mime][:except] = except_actions unless except_actions.empty?

end

end

This method is defined on the ActionController::MimeResponds::ClassMethods module, which is pulled into ActionController::Base. Additionally, mimes_for_respond_to is defined usingclass_inheritable_reader in the included lifecycle hook for the module. The class_inheritable_reader method (macro?) uses class_eval to add methods onto the class in question to emulate the built-in attr_accessor functionality.

Understanding all of the details isn’t important. What’s important is that using the Ruby features we described above, it’s possible to create layers of abstraction that can appear to add features to the Ruby language.

A developer looking at ActionController::MimeResponds need not understand howclass_inheritable_reader works–he just needs to understand the basic functionality. And a developer looking at the API documentation need not understand how the class-levelrespond_to is implemented–she just needs to understand the provided functionality. With that said, peeling back each layer leads to simple abstractions that build on other abstractions. There’s no need to peel back the whole curtain at once.

8. Nice Literals

I often forget about this when programming in Ruby, only to crash back down to earth when using a language with fewer, less expressive literals.

Ruby has literals for just about everything:

  • Strings: single-line, double-line, interpolated
  • Numbers: binary, octal, decimal, hex
  • Null: nil
  • Boolean: true, false
  • Arrays: [1,2], %w(each word is element)
  • Hashes: {key => value} and in Ruby 1.9 {key: value}
  • Regular expressions: /hello/, %r{hello/path}, %r{hello#{interpolated}}
  • Symbols: :name and :”weird string”
  • Block: { block literal }

And I think I’m missing some. While it may seem academic, good, readable literals can increase the programmer’s ability to write short but extremely expressive code. It’s of course possible to achieve the same sorts of things as you can with literal Hashes by instantiating a new Hash object and pushing the keys and values on one at a time, but it reduces their utility as method parameters, for instance.

The terseness of the Hash literal has allowed Ruby programmers to effectively add a limited keyword argument feature to the language without having to get approval by the language designers. Yet another small example of self-hosting.

9. Everything is an Object, and All Code is Executed and Has a self

I showed this to some degree earlier, but a lot of the reason that Class bodies work the way they do is a consequence of the unfailing object orientation of the Ruby language. Inside of a class body, Ruby is simply executing code with a self pointing at the class. Additionally, nothing is special about the class context; it is possible to evaluate code in a class’ context from any location. Consider:

module Utildef self.evaluate(klass)

  1. class_eval do

def hello

puts “#{self} says Hello!”

end

end

end

end

 

class PersonName < String

  1. evaluate(self)

end

This is exactly equivalent to:

class PersonName < Stringdef helloputs “#{self} says Hello!”

end

end

By removing the artificial boundaries between code in different locations, Ruby reduces the conceptual overhead of creating abstractions. And this is the result of a strong, consistent object model.

One more example on this topic. This idiom is quite common in Ruby: possibly_nil && possibly_nil.method_name. Since nil is just an object in Ruby, sending it a message it does not understand will result in a NoMethodError. Some developers suggested the following syntax: possibly_nil.try(:method_name). This can be implemented in Ruby as follows:

class Objectalias_method :try, :__send__end

 

class NilClass

def try

nil

end

end

Essentially, this adds the method try to every Object. When the Object is nil, try simply returns nil. When the object is not nil, try just calls the method in question.

Using targeted application of Ruby’s open classes, combined with the fact that everything in Ruby, including nil, is an object, we were able to create a new Ruby feature. Again, this isn’t such a big deal, but it’s another case where the right choices in the language can allow us to create useful abstractions.

10. Rack

I’m going to cheat a little bit since Rack isn’t part of the Ruby language, but it does demonstrate some useful things about it. First of all, the Rack library only hit 1.0 earlier this year, and already every single Ruby web framework is Rack compliant. If you use a Ruby framework, you can be guaranteed that it uses Rack, and any standard Rack middleware will work.

This was all done without any backward compatibility sacrifices, a tribute to the flexibility of the Ruby language.

Rack itself also leverages Ruby features to do its work. The Rack API looks like this:

Rack::Builder.new douse Some::Middleware, paramuse Some::Other::Middleware

run Application

end

In this brief code snippet, a number of things are at work. First, a block is passed to Rack::Builder. Second, that block is evaluated in the context of a new instance of Rack::Builder, which gives it access to the use and run methods. Third, the parameter passed to use and run is a class literal, which in Ruby is a simple object. This allows Rack to callpassed_in_middleware.new(app, param), where new is just a method call on the Class object Some::Middleware.

And in case you think the code to implement that would be heinous, here it is:

class Rack::Builderdef initialize(&block)@ins = []

instance_eval(&block) if block_given?

end

 

def use(middleware, *args, &block)

@ins << lambda { |app| middleware.new(app, *args, &block) }

end

 

def run(app)

@ins << app #lambda { |nothing| app }

end

end

This is all that’s needed to implement the code I showed above the creates a new Rack application. Instantiating the middleware chain is a simple affair as well:

def to_appinner_app = @ins.last@ins[0…1].reverse_each { |app| inner_app = app.call(inner_app) }

inner_app

end

 

def call(env)

  1. call(env)

end

First, we take the last element from the chain, which is our endpoint. We then loop over the remaining elements in reverse, instantiating each middleware with the next element in the chain, and return the resulting object.

Finally, we define a call method on the Builder, which is required by the Rack specifically, that calls to_app and passes the environment through, kicking off the chain.