Last week we published Getting Started With Ruby On Rails, the first part of our Ruby On Rails introduction. We explained basic ideas behind Ruby and presented concepts and essential components of the language. In this article you’ll learn more about Rails, you will learn how to get Ruby on Rails running on your computer, and get an overview of the basic functionality of Rails and demonstrate how Rails’ main parts work together.

I assume you’re already familiar with some other form of Web development, whether PHP, Python, Perl or Java, and relational databases like MySQL. First, we’ll introduce Rails and Ruby and the basic ideas behind both. I’ll teach you just enough Ruby so that you understand the code samples. I’ll tell you how to get Ruby on Rails running on your computer, and I’ll give you an overview of the basic functionality of Rails and demonstrate how Rails’ main parts work together.

After reading these parts, you should have an idea of whether Rails is for you. If you get the feeling that it is, I’ll point you to some good tutorials on the Web that you can use to learn Rails. I’ll also provide a lot of further reading recommendations so you can dig as deep into the topic as you like.

You may want to take a look at the following related posts:

• Getting Started With Ruby On Rails: Part 1
• 10 Useful Tips For Ruby On Rails Developers

Get Rolling

To get your feet wet with Rails, it’s best to simply install it on your own machine and start playing around. This requires just a few steps.

On Windows do the following:

1. Install Ruby 1.8.6 using the one-click installer from www.ruby-lang.org. Make sure to select “Enable Rubygems” during installation. It’s probably a good idea to install ruby as admin.
2. Update Rubygems. Rubygems is Ruby’s package management system, and Rails needs a newer version than the one that ships with the installer. To do this, execute gem update --system in the console as admin. Next, you’ll need to add the GitHub gem server to Rubygems with gem sources -a http://gems.github.com
3. Install Rails and its dependencies with gem install rails and gem install mysql. (You can use other databases, but MySQL is the easiest to set up.)
4. Install the MySQL Database from mysql.com. If you’ve done Web development before, you probably already have it on your machine.
5. Create a Rails application. Enter rails -d mysql . “Appname” will be the name of the sub-directory your app is created in.
6. Go into the created application’s directory and execute ruby script/server. Point your browser to localhost:3000. You should see the Rails welcome page. Follow its instructions.

To edit Ruby code, you can use any text editor. If you just have to have a fancy IDE, try NetBeans. I recommend Notepad++, a great, lightweight freeware editor.

On a Mac, you’re lucky. Mac OS 10.5 comes with Ruby, Rails and SqLite3. You just need to update your packages by issuing a few commands:

sudo gem install rubygems-update
sudo update_rubygems

gem install rails
gem install mongrel

If you need more detailed help on installing Rails on 10.4 Tiger, check out the tutorial on the Rails wiki or in this blog post. Now you can create your app with rails .

On Linux, the installation depends on your distribution.

A Bird’s Eye View Of Rails’ Inner Workings

This is the part I find missing in most other tutorials about any topic. I want to present an overview of the most important components of Ruby on Rails to help you understand how they work together to process requests. I will be more detailed in the controller section because that’s the most important one, and if I left things out there I wouldn’t be able to paint the whole picture.

Controller

When the request hits your server running the Rails app, the first component handling it is the ActionController.

The ActionController and all of its parts correspond to the controller-part of the MVC stack. Before actually handling the request, the ActionController inspects it to determine which of the controllers in your application is responsible for the request.

These lookups are called routes and are defined in config/routes.rb. If you take a look in that file, you’ll see lines similar to these:

ActionController::Routing::Routes.draw do |map|
  map.resources :users
  map.connect ':controller/:action/:id'
end

The details of route definition could fill an article of their own. If you’re interested in its precise workings, take a look at the ActionController::Routing documentation in the Rails API.

Simplified, two kind of routes appear here. The last one is the traditional style of defining routes. These are formed like simple regular expressions, with the :foo part being a placeholder.

If a request’s URL matches one of these expressions, its parts are mapped to the placeholders. These are then examined to determine the correct controller, the action within the controller and further parameters like id (id always contains the id of the object that the client wants to work with). For example, a URL like /foo/bar/123 would be mapped to the FooController; the bar action and the value of params[:id] would be 123.

The first line is a shortcut to create a large number of those routes in one sweep. Routes created this way adhere to the REST principles. Again, this is a topic large enough to warrant its own article. For the sake of this introduction, let me just illustrate the effect of map.resources :users as an example. If you put such a line in your routes.rb you’re telling Rails that you want users to be a resource. That means seven routes are installed that all point to the UserController.
These seven routes match not only against the URL of the request but also the HTTP method. The mappings are:

GET      /users            # will point to the index action
GET      /users/new        # will point to the new action
POST     /users            # will point to the create action
GET      /users/:id        # will point to the show action
GET      /users/:id/edit   # will point to the edit action
PUT      /users/:id        # will point to the update action
DELETE   /users/:id        # will point to the destroy action

All of these actions of the UserController are expected to behave in certain ways.

• The index action should display a list of all existing users.
• The new action should display a form for the creation of a new user that is submitted to /users via POST.
• The create action should take the form’s input and create a new user in the database.
• The show action should display the user with the corresponding id.
• The edit action should display a form for editing the user. The form should submit to /users/:id/ via PUT.
• The update action receives the form data and updates the user in the database.
• The destroy action deletes the user from the database.

Because PUT and DELETE aren’t supported by all browsers, forms that are supposed to use these methods submit via POST and tell the server their intended method via a hidden form field named _method.

Once controller, action and parameters are determined, the action can be called. But before that actually happens, Rails inspects the filter chain for the action to see if there are any filters to be executed before the action runs. Such filters are incredibly useful for things like user authentication. To ensure that only logged-in users of your application can access certain actions, you would define a filter that checks the session for valid credentials. Such a filter could look like this:

class UserController < ApplicationController

  # Require valid login to access the update action
  before_filter(:require_login, :only => :update)

  # Lots of actions defined here
  # ...
  # ...

private

  def require_login
    render(:text => "Unauthorized", :status => 401) unless session[:user_valid]
  end

end

Let’s analyze this example line by line. The UserController inherits from the ApplicationController. All of your controllers should. The ApplicationController can then contain code that should be shared among all the controllers in your application. You could, for example, put the require_login filter in there to require a valid log-in for all your controllers.

The next line declares a before filter. By making the declaration using the symbol :require_login, you’re telling Rails to use the require_login method as a filter. This alone would apply the filter to all actions
in the UserController. The additional parameter :only => :update tells Rails to use the filter only when the client wants to access the update action. In a real controller, this line would be followed by the definitions of all the actions your controller contains. In this example, they’re omitted for brevity.

The keyword private marks all the methods defined afterward as private to the UserController. This implies that they can’t be used as actions. We don’t want require_login to be used as an action, so we’re putting it here.

Require_login checks if the field :user_valid in the session is present. This is, of course, a pretty drastic simplification of a real authentication scheme, but it’s sufficient for the sake of illustrating filters. Unless a user is logged in, the filter renders a simple error message.

Now, here’s a detail you need to know to understand this. Rails works through all the filters applying to an action and only aborts request processing for three reasons:

1. A filter raises an Error.
2. A filter returns false.
3. A filter renders somethings or redirects.

So, this single line is all that is needed to protect our sensitive actions against malicious clients. Again, I’m simplifying this a bit. To make an application really secure, you will of course need a little bit more code to properly maintain session state. To find out more about filters, read the ActionController::Filters::ClassMethods documentation in the Rails API.

Let’s see how Rails continues with the processing of the request.

After the client’s request has passed all filters, the action finally executes. Let’s run with our example from the filters section and assume the client wants to execute the update action after editing the user in a from provided by the edit action. Both actions could be defined like this:

def edit
  @user = User.find(params[:id])
end

def update
  @user = User.find(params[:id])
  if @user.update_attributes(params[:user])
    redirect_to users_url
  else
    render :action => :edit
  end
end

Let’s work through this line by line again. First, note that actions are defined as simple parameter-less methods on the controller. Their input and output is realized a little differently from what you’d expect from a method. Actions retrieve all the information they need to process the request from their controller through a few accessors, mainly params and session. There are more (cookies, request), but they’re not used nearly as often as these two, and I don’t want to complicate matters more than is necessary here.

The params method returns all the parameters of a request. These usually result from its querystrings or the postbody, but can also be created from JSON or XML data structures. Through routes, parts of the URL can also become parameters. This is where the :id parameter in the example is read from. If the client requests /users/123/edit/ and we have a route definition map.resources :users, then 123 becomes the :id parameter for the edit action, because the route definition generates (among others) a route that looks like this:

map.route '/users/:id/edit',
          :controller => 'users',
          :action     => 'edit',
          :method     => :get

For output, an action basically has two options. It can either redirect the user or render a template. The templates for a Rails application are organized the same way the controllers are. They reside in app/templates//.html.erb, and if no output is specified in the action, Rails renders the template belonging to that action by default. That’s why you don’t see any output code in the edit action. The only line in edit pulls the user we want to edit out of the database and puts it into an instance variable of the controller to make it available to the template.

The update action begins with the same statement, again fetching the user form the database. In its next step, the user’s attributes are updated with the data that the action received from the client-side form. The update returns true on success. In this case, the client is redirected to the list of users.

This redirection deserves closer inspection. The redirect_to command takes a URL, but instead of hard-coding these URLs (/users in this case), it is conventional to use URL helpers like users_url. The helpers are generated automatically by the route or resource definitions.

If updating the user’s attributes does not succeed, two things happen inside the update_attributes call. First the user’s errors property will be filled with details on why the update didn’t succeed, and the call will return false instead of true. As a result, the client is not redirected; instead, render is called, with :action => :edit as its parameter. This tells render to render the template belonging to the edit action of the current controller.

Why not redirect to the edit action, you may ask? We could do that, but we’d lose all the edits we made to the user and lose information on the errors that occurred. When the edit-template is rendered instead during the processing of the update action, the user that failed to update is still in memory with all its pending edits and the errors. We can use this data in the template to pre-fill the form with the values we just entered (but didn’t save to the database) and provide information to the client on what went wrong.

There’s one last important thing to note here about render and redirect_to. It is not apparent from these examples, but calling render or redirect_to does not stop the processing of the action. These are both just methods and not special control flow statements. So, when render is called, the template isn’t rendered yet; rather, the controller renders the template after the action has processed. Any statements following a render are still executed.

Model

The second important part of MVC in Rails is the Model. Its role is played by the ActiveRecord module, an implementation of the pattern of the same name. ActiveRecord::Base functions as a base class for the models in your application. If you derive your models from this class, you’ll have them automatically linked to tables in your database and can very easily load, edit, save, create, delete or list them. Mappings between the structure and behavior of your models and the tables in the database are fully automated mostly, provided that you adhere to a few rules in the design of your tables. The general principles are:

1. Your table name is the pluralized, underscored variant of your classname. So, a class User would be mapped to the table users.CookieRecipe would be mapped to cookie_recipes.
2. Your table needs to have its primary key on an integer column called id with the auto increment property.
3. Associations to other tables are stored in columns that are named after them. If you want to store posts belonging to a user, the posts table would need a user_id column

If you have a table and class that are connected via their name, like users and User, any column in the table is available on the model as a property. If you want to create a User, you’d just instantiate an object in Rails:

u = User.new

Then you can begin setting its properties:

u.name = "Michael"
u.age  = 35

You could also provide these settings upon creation:

u = User.new(:name => "Michael", :age => 35)

To store the new user in the database, tell it to save:

u.save

You can find records in a lot of ways:

u = User.find(123)               # finds the user with id 123
u = User.find(:all)              # returns an array containing all users
u = User.find_by_name("Michael") # a "magic" finder

I don’t want to go into the details of all of these options. You can find them all in the ActiveRecord::Base module documentation in the Rails API. I’d rather introduce two important features of ActiveRecord: associations and validations.

I have already mentioned associations briefly and given an example of posts belonging to users. How would you actually implement that? Well, as mentioned, you first put a user_id column in the posts table to link the two tables. Then you need to make your models aware of the link (unfortunately, it doesn’t do that automatically). But don’t worry, you only need two lines of code for that:

class User < ActiveRecord::Base
  has_many :posts
end

class Post < ActiveRecord::Base
  belongs_to :user
end

That’s it. These two lines make helpers available in both models that allow for navigating the models. Given a post, you could access its user via post.user or get all posts of a user by saying user.posts.

Validations are constraints that you can define in your model to ensure that the model is only saved to the database if those constraints are met. Rails provides a lot of predefined validations that ensure that a property isn’t empty, is within a certain numeric range or matches a regular expression. But you can basically use anything you can write down in code as a validation. Say you want to ensure that your posts have titles not longer than 100 characters and that the post body is always present. You would extend your Post class like this:

class Post < ActiveRecord::Base
  belongs_to :user

  validates_presence_of :body
  validates_length_of   :title, :maximum => 100
end

A call to the save method on a post that doesn’t comply with these restrictions will return false, and the post will not be saved to the database. You can then examine the post’s errors object by accessing post.errors and communicate to the users what went wrong. The Rails-provided validations all come with descriptive error messages that you could retrieve with post.errors.full_messages, for example.

ActiveRecord has a lot more depth and functionality than presented here. Even complex models and their relations can be handled pretty comfortably. But presenting all this exceeds the scope of this article. The API doesn’t help much if you want to explore all these possibilities; so, to get a deeper introduction, I recommend the Rails Envy ActiveRecord tutorial.

View

We’re almost at the end of our overview. The last missing part is MVC’s V, the View. All the components related to this are aggregated under the ActionView module. At the core of Rails’ views are the ERB templates, but they are backed by a large library of helpers that can be used to generate forms, URLs, sub-templates and other little tools that can make your life easier.

In the controller example, I talked about how the render method is used to render a template. An action that doesn’t explicitly render or redirect automatically renders its corresponding template in app/templates//.html.erb. The file extension .erb stands for “Embedded Ruby,” and that’s what the templates are: HTML files that are dynamically filled with content through the use of special script tags that contain Ruby code. These special tags work very similar to the ones PHP uses. Let’s take a look at an example:

  
    
  
  
    
Post: <%= h @post.title %>
    
Written on <%= @post.date %>

    

      <%= h @post.content %>
    

    <% if @post.user.posts.count > 1 %>
      
Other posts by <%= @post.user.name %>:
      

        <% @post.user.posts.each do |post| %>
          
<%= h post.title %>
        <% end %>
      
    <% end %>
  

Tags beginning with <%= evaluate the expression they contain and insert them into the document. The little h you see sometimes is a helper function provided by ActionView that escapes characters that are not valid HTML. You should always use this if you’re displaying user-entered content to prevent cross-site scripting attacks.

Below the postcontent div, you can see another type of erb tag, without the equals sign. This means that its content is executed but not inserted into the document. We’re opening a conditional statement here. Everything between the if and the end will only be executed if the current post’s user has other posts. This affects both Ruby and HTML code.

The next tag is also pretty interesting and different from the ones used before. We’re combining the power of Ruby blocks here with ERB to iterate over a user’s posts. The each method executes its block for each of the members of a collection and makes the current member available to the block. I’ve called the block’s parameter post here, so we can refer to the current post under this name within the block. In ERB, you can put HTML within blocks just as if it were code.

You’ll notice that I’m using two instance variables in this template, @pagetitle and @post. They are the main means of passing data from the controller to the template. Instance variables that exist in the controller can also be accessed in the template. It’s that simple.

From the content of the page, you can see that we’re probably rendering the show action of a post’s resource here. The controller action to feed this template with data could look like this:

def show
  @post = Post.find(params[:id)
end

The @pagetitle could be the result of a before filter:

before_filter :set_title
def set_title
  @pagetitle = "Showing Post #{params[:id]}"
end

Rails’ templates can harness the full power of the Ruby language and have access to the full stack right down to the models. This power can easily be misused to put controller logic or model operations into the templates. But you’re only hurting yourself (and your colleagues) if you do that. You should only put code in the templates that is directly related to displaying data.

As with ActiveRecord, this only scratches the surface of what’s possible with ActionView. Three of the most useful features not introduced here are:

• Layouts that can be nested so that you don’t have to repeat identical structures in your templates over and over.
• Partials, small template snippets that can be used to render collections and inserted into other templates
• Generation of JSON and XML to create Web services, AJAX interfaces and RSS feeds.

To go deeper into the topic, check out the Layouts and Rendering in Rails guide on Rails Guides.

Learning From Rails

Rails takes Ruby’s aim of increasing programmer productivity and happiness and applies it to Web frameworks. Its debut was a truly revelatory experience because it showed developers that that power doesn’t have to come with the clumsiness that other frameworks exhibited at the time.

Today, the ideas of Rails can be found in many imitators in other languages, but if you’re not tied to any one of them, Ruby on Rails is definitely worth checking out. You’ll rediscover the fun in programming, and even if you don’t stick with Rails, you definitely won’t regret the learning experience.

The greatest thing about Rails, however, is how it can change your perception of programming in general once you understand its design and the reasons behind it.

First, simply using Ruby — a language that’s quite different from ones you’ve used before, yet similar enough not to be totally alienating — opens up your mind to new ways of thinking and new ways of perceiving programming languages. You’ll suddenly begin to question things you’ve taken for granted. You’ll frown at first on the prospect of opening up and redefining core classes at runtime, but once you’ve done it and seen that your program still runs and looks nicer than before, you’ll appreciate the flexibility and also become a more responsible programmer. You’ll curse every semicolon and every empty pair of braces that other languages force upon you.

For many programmers, Ruby even paved the way to radically different territory, namely functional programming. Ruby is an imperative language, but its treatment of code blocks as objects equal to Strings, Numbers or any other class and its support of closures will slowly prepare your mind for languages like Lisp, Haskell and OCaml, where passing around functions is the predominant way of writing programs. You’ll have a much broader palette of solutions for the problems you’re tackling each day, and those problems will stop looking like all nails.

Rails very much builds upon these wisdoms and makes much use of meta-programming (class rewriting) and functional programming principles. In this way, Rails becomes more than a framework, and becomes rather a domain-specific language for writing Web applications. The exploitation of Ruby’s dynamic features enables a brevity in Rails’ API that does not obscure your code’s intention. After using Rails for a while, you’ll start to develop your own programs in this way.

Rails encourages strict separation of code between your models, controllers and views. Once you’ve written an app in this straightjacket, you’ll begin to see its tremendous benefits. You will develop a sharper eye for the correct location of code. Things you’ve put in your controllers in the past will take their place in the models, and your design will become more fluent, cleaner and more flexible, especially if you let Rails encourage you to thoroughly test your app.

Even if your flirtation with Rails doesn’t turn into a long-term relationship, you’ll gain invaluable experiences that will improve your style in whatever you develop in future.

Further resources

In the hope that your interest has now been piqued and you have an idea of what to expect, I’d like to point you to some resources that will really teach you how to write Web application in Rails.

Further, I’ll point you to some important sources of news, because despite its maturity, Rails is moving at blazing speeds. Don’t misunderstand me: you won’t have to study new features each week to keep up with programming in Rails, but by monitoring the right news sources, you’ll learn invaluable tips and tricks that you won’t find in the tutorials.

First of all, there are books. The advantage of computer books is that they’re usually comprehensive and professionally edited. The disadvantage is that most of them are outdated by the day they hit the shelves. So, the only books you should really bother reading are the ones that are just out. Fortunately, the standard Rails manual, “Agile Web Development with Rails” is just receiving the finishing touches for its third edition, which will cover the most recent changes in the framework. It’s good for beginners and doesn’t go very deep, but that’s okay. If you want to go deep, you can just read blog articles about the subjects you’re interested in after you’re done with the book.

To learn Ruby, you could try Programming Ruby (the “Pickaxe”), the guide written by the Pragmatic Programmers that first brought Ruby to the west. Its first edition is even free and can be found at ruby-doc.org alongside the official Ruby API. The second (and upcoming third) edition is definitely worth the money, though, especially for its chapter about the inner details of Ruby’s object and method dispatch system.

People who don’t like the Pickaxe usually recommend Hal Fulton’s “The Ruby Way,” which teaches the language in a more task-oriented way.

If you’re just entering the world of Rails, you’ll also have access to what will probably be a pretty awesome library of documentation (if it isn’t already!). A few months ago, the Rails team launched an effort to provide comprehensive, up-to-date and free information about everything Rails at Rails Guides.

If you’ve taken your first steps, you should subscribe to the official Ruby on Rails blog, mainly for important announcements and its “This Week in Rails” feature, which provides a very convenient overview of the development of Rails.

If you want to keep in touch with the greater Rails eco-system, you should subscribe to the Rails Envy podcast. These guys will point you to nice plug-ins, tips, tricks and important blog posts every week.

You could, of course, just read those blogs yourself, but beware: Rails has a lot going on in it, and I prefer to have the information predigested in some form. However, if you’d like something to chew on during those boring hours at work, check out these blogs:

• Ryan’s Scraps
• has_many :through
• Robby on Rails
• Jamis Buck’s blog
• caboose
• Ilya Grigorik’s blog
• On Rails
• nano RAILS
• Railscasts

Should you get stuck in your adventures, Googling often helps because most of the problems that beginners experience are similar, and for almost any hurdle you may encounter, somebody somewhere has already written a blog post about it. If this is not the case with your problem, ask for help on the Ruby on Rails mailing list or the Ruby mailing list. The people in the Ruby community are usually very friendly and helpful.

Related posts

You may want to take a look at the following related posts:

• Getting Started With Ruby On Rails: Part 1
• 10 Useful Tips For Ruby On Rails Developers

About the Author

Jan Varwig is a programming language enthusiast, currently writing his CS diploma thesis about server-side JavaScript, and a software developer with 10 years of experience working for 9elements and as an independent freelancer. His blog and CV can be found at jan.varwig.org.

(al)

© Jan Varwig for Smashing Magazine, 2009. | Permalink | 7 comments | Add to del.icio.us | Digg this | Stumble on StumbleUpon! | Tweet it! | Submit to Reddit | Forum Smashing Magazine
Post tags: coding, introduction, programmings, rails, ruby

The Smashing Book project is coming along. At the end of February we announced our most interesting (and important) project for 2009: “The Smashing Book,” a smashingly written, beautifully designed and professionally printed book. The book’s title will be “The Smashing Book”; it will be a paperback; and the price is fixed, as is the release date, which is early September 2009.

We asked for your opinion about what the topics of the book should be, your wishes and ideas, and we were completely overwhelmed with the huge amount of great ideas and suggestions in our Smashing Book Forum. We express sincere gratitude to all those who helped us and discussed various ideas in the forum.

We took some time to go through all the suggestions and ideas, analyze them, find common interests and determine what you expect from the book and how it should look to meet your expectations. And now it’s time to get a little bit more concrete in the second round of our project.

Special Awards For Active Participants

Of course, we also came up with some exclusive, special awards for the active participants of the Smashing Book Forum. However, we don’t want to lay all our cards on the table — the special prize is not a free book copy, not a third-party gift: it is directly related to the book. The awards will be unique and are not for sale.

Here are the winners so far (or their forum nicknames at least): GeoEgo, mloclam, Furmi, ajcates, noirfatom, mWalk, fluxerj, mediocre, Norbert, mads, vladgidea, John, earthwormjim, rostek. Thank you for your participation, folks! We appreciate it! You’ll get the exclusive awards when the book goes into print.

Making the users’ wishes and interests the core focus of a new project is quite an old yet successful strategy. We don’t want to publish the book for us; we want to publish it for our readers and the whole design community. The book is supposed to become our common book. Unfortunately, not everyone understood the idea behind this project. That’s why we would like to explicitly point out that the articles for the book will be written by writers of Smashing Magazine. All authors and graphic artists who contribute to the book will be paid by Smashing Magazine.

The details of the book layout will be determined as we learn more about the content of the book. You can discuss book layout suggestions in this forum thread.

Topics Of The Book

We have carefully read through all comments in the magazine and the forum and tried to figure out which are the most popular ideas and most desired topics. It wasn’t easy, because users had different opinions about the same topics, so we sometimes had to find compromises.

Our readers clearly pointed out that they did not want a “general” book that would go through the boring basics of Web design as can be easily found on the Web. The book should not be a “beginner’s” handbook but instead should be written so that it remains useful and informative for at least a couple of years. Specifically, you would like a book of principal guidelines, filled with exciting practical examples and concrete ideas and suggestions. You want it, you got it! The book, then, will cover at least the following seven topics:

1. Behind The Curtains: The Smashing Magazine Story
2. Prototyping & wireframing
3. Typography guide
4. Color theory and practical examples (guide)
5. Usability
6. Performance Optimization for websites
7. Business and freelancing guide, starting your own business

Of course, this isn’t everything. Many more topics can be covered in the book, and you can decide what those are. Please vote in the poll below!

Vote now and please spread the word!

What Won’t Be In The Book?

Unfortunately, the book will not contain a CD or DVD. All links and files will be made available online. The book will also not contain tutorials for specific applications — otherwise, it would become outdated very quickly.

What Will The Book Look Like? Stay Tuned.

Thank you for your participation, folks! And please feel free to let us know your ideas, thoughts and suggestions in the comments to this post!

You can decide on the book cover design next week. We have picked out the six most interesting book cover designs among a number of drafts suggested in the forum. And now we would like you to tell us which cover you like best. We think every design shown below is appropriate for the Smashing Book. However, which do you think would makes the book look really smashing? Please stay tuned.

© Smashing Editorial for Smashing Magazine, 2009. | Permalink | 34 comments | Add to del.icio.us | Digg this | Stumble on StumbleUpon! | Tweet it! | Submit to Reddit | Forum Smashing Magazine
Post tags: book, Events, smashing

For years, Apple has had a huge impact on designers and graphic artists across the globe. The simplicity and sharpness of the Aqua interface in Mac OS X strongly influenced the way new products were being presented and designed. It’s not only the design of products that makes Apple’s products different, it’s also their appearance on the Web and in print.

No other company has managed to come up with such a crisp and brilliant style of presenting its recent designs as a new breakthrough innovation that will change our lives for a long time. Apple has found an extremely effective way to deliver its message to a wide audience, and Apple’s look and feel has played a major role in shaping that way.

In this post, we present a collection of beautiful Apple-inspired Adobe Photoshop tutorials. We collected them not because we are religiously in love with Apple, but because you may find these tutorials useful; for instance, if you are developing a new Mac or iPhone application or designing a concept for a new product. In these cases, you may want to consider Apple’s Human Interface Guidelines and our Designer’s Guide To Icon Design For Mac OS X. Please feel free to suggest further tutorials in the comments to this post.

Mac Photoshop Tutorials

MacBook Air
In this 20-step tutorial, you’ll learn how to create a MacBook Air.

Creating a Vector-Style MacBook from Scratch
A long tutorial on making a MacBook Pro in Photoshop using shapes and different blending techniques.

Create a Slick Black iMac
What would a black iMac look like? Being a Photoshopper, you can see for yourself.

Creating the Apple Mouse
Simple and elegant: the Apple mouse. Create the mouse in Adobe Photoshop.

iPhone

Apple iPhone Mobile Phone Design
Design the modern mobile phone using these easy-to-follow steps.

Create an Apple iPhone from Scratch
It is very fashionable to have an iPhone. Make your own in Photoshop.

iPhone-Style Icon Tutorial
Apple has posted some guidelines for making Web applications. Learn how to make an iPhone icon.

How to Create an iPod Touch
The easiest way to create an iPod Touch.

Create an iPod Touch
This tutorial shows you how to create an iPod Touch from scratch in Photoshop using no source images.

iPhone Tutorial
This tutorial describes in detail how to create the shapes, apply the effects, and make your own iPhone in Adobe Photoshop.

iPhone GUI PSD
A Photoshop file that has a fairly comprehensive library of elements, all fully editable. More iPhone GUI source files: iPhone UI Vector Elements (Illustrator) and iPhone PSD Vector Kit (Photoshop).

Designing for the iPhone: Resources
Here are some resources to get you going with your iPhone design project.

iCons and the Web

Create the Glass-Shelf Dock in Leopard OS
In the new MAC OS X Leopard operating system, the application bar has a new sleek look. This tutorial shows you how to create the glass-shelf dock used in the OS.

Apple Leopard Text Effects
The Apple operating system’s GUI for Leopard shows an “inset” effect for text, along with a new chrome finish for windows.

Design the iTunes Icon
This tutorial shows you how to create the iTunes icon.

iTune Icon
Use various blending modes and techniques to replicate the iTune icon.

Mac Theme
How the masters at Apple may have created the old Mac theme.

Jaguar Style Folder
In this tutorial, you will learn how to cover an object in a jaguar fur pattern.

iPod

iPod Shuffle from Scratch
In this tutorial, you will learn how to create the Apple iPod Shuffle by using an original image as a reference.

Apple Remote
In this tutorial, you will learn how to make a shiny Apple remote.

Realistic iPod
Learn how to create a realistic fourth-generation iPod.

iPod in Photoshop
The black version of the iPod.

Make an iPod Classic
Learn how to create an iPod Classic with the same technique used to make an iPod Nano.

Creating an Apple iPod
Save yourself some money and create an iPod-style image in Photoshop.

Logo and Wallpaper

Green Apple Design
Learn in this tutorial how to create Apple-esque wallpaper.

Apple Wallpaper
Learn how to design an Apple desktop theme in this tutorial.

Apple’s Brushed Aluminum
Create a brushed aluminum texture similar to that of Apple’s products.

Mac - Colorful Design
Learn in this tutorial how to design wallpaper with the Mac logo.

Lighting Effect
Learn how to create that effect we saw on the screen at Macworld San Francisco.

Feed your iPhone
Learn everything from creating the liquid to blending the iPhone apps.

60 Most Beautiful Apple Wallpapers
Showcase of 60 most beautiful Apple-related wallpapers, including the Apple logo, the Mac OS X, time machine, iPods and more.

Video Tutorials

How to Make iPhone Icons
A five-minute tutorial on how to make icons like the ones displayed on iPhones and iPod Touches.

iPhone
A video tutorial on how to create an iPhone.

iPod Ad Effect
Learn in this video tutorial how to make an iPod ad effect.

Coldplay/Apple Commercial
This is a tutorial on how to make the new Apple/Coldplay commercial in Adobe Photoshop.

iMac
Create the new iMac completely in Photoshop.

Apple TV Background
Learn how to make an Apple TV-style background.

Creating the iTunes Icon
Create the iTunes iPhone icon in Photoshop.

Mac Advertisement

Create an iPhone Advertisement
Learn how to create an iPhone advertisement similar to this Nano ad with dripping paint.

iPod-Style Brushes
We’ve all seen the iPod commercials: trendy and just about cliché by now. Here is a great way to simulate the silhouette style with a brush.

Grunge iPod Design
Learn the basics of creating a grunge iPod design in this tutorial covering vector drawing and brushing techniques in Photoshop.

I See iPod People
It is easy to simulate the iPod ads. The first thing you’ll need is an image of someone you can extract from the background without too much work.

Design a Coldplay/Apple-Inspired Portrait
Simulate the beautiful effect shown in the latest Coldplay/Apple ad.

Creating an Apple-Style Advert
A simple tutorial that shows how to make an Apple-style advert. It uses only a couple of effects. The source pack is included here if you want all the material.

Make Your Own iPod-Style Photo
The Apple iPod commercials on TV: crazy silhouetted people dancing around with white iPod’s. Learn how to create your own crazy ad.

Attack of the iPod People
Another silhouette-style ad tutorial, with the somewhat-semi-official iPod poster palette of colors.

(al)

© Dirk Metzmacher for Smashing Magazine, 2009. | Permalink | 56 comments | Add to del.icio.us | Digg this | Stumble on StumbleUpon! | Tweet it! | Submit to Reddit | Forum Smashing Magazine
Post tags: apple, photohop, Tutorials