Watching @deadmau5 live stream has made me realize how technology frustrates all of us including rock star dudes. live.deadmau5.com

— Cheston Lee (@Cheston) March 20, 2012

I came across this tweet earlier via my buddy Jacob and it got me thinking.

In life, we can easily fall victim to getting caught up in the moment. The specifics of your job and life can take away from your consciousness of the higher goals that you have. Do you want to change the world? Yes, we all do. But in what way?

For me, I want to make software simpler. One example of what I want to accomplish is the transition to a Macbook that my parents have went through in the past several months. Previously when I would visit, they would have a list of computer problems waiting for me. “The printer driver isn’t working.” “iTunes won’t sync.” “I don’t know where my files are from the camera after I transferred them via USB.” And then I gave them my Macbook. I haven’t heard a peep from them since. It was a seamless transition, and they have had absolutely zero problems and can do more now than they could before. Their lives are now simpler and much more productive.

To me, being able to make regular software simpler can have a profound effect. Nontechnical people will be able to accomplish more quicker using simpler software. This is what I want to do. I want to change the world by adding simplicity and minimalism to an overly complicated world.

Rails exemplifies this in the development of web applications. Steam does this for video games by removing the complexities around it. There are plenty of people with similar values in tons of different areas.

One of the keys to success is having defined your set of values. Things you believe in.

If you take a look at everyone who has been incredibly successful, they have had a specific set of goals and values. They made their decisions based upon these values, and stuck by them no matter what.

Every single president had strong beliefs that were unwavering. Steve Jobs had that. Every really successful company has grown out of a set of values . They weren’t without their enemies, but that comes with the territory.

On the other hand, if you analyze those who aren’t successful, you’ll notice that they have wavering beliefs. They are unsure of themselves which remove the ability for people to stand behind them. You can’t support someone who changes their mind month to month.

Which leads into my next point…

Defining your values makes you a leader

Sometimes people are searching for something to believe in. They’re questioning their beliefs and looking for someone to align themselves with. If you talk about your values, it is easy to attract people with similar values. The best tech companies write tons of blog posts about their values, and this grows a community of similar people. The potential employees with similar values are already exposed, so they know exactly where to go when they are looking for a job.

Knowing exactly what your values are puts you in a unique position. Most people don’t know what theirs are, and it is refreshing to see someone who does. TED Talks always have inspiring speakers. Everyone of them knows what they live for. We are attracted to this because it is inspirational. They are amazing individuals. We want to be like them.

And that’s easy. You’ve just got to become one yourself.

Write down your values

So what things do you believe in? What would values would you never sacrifice? This is important on both a personal and a career level.

Decisions are easy when you have a set of values. Does eating two cookies fit your personal value of a healthy lifestyle? Nope. Done, no arguing with yourself, no second guessing. Does arguing for 3 hours about the company color scheme help achieve your company’s goals? Nope. Look at your values. “We want to give the best customer experience we can.” Well then I guess the exact color of the website doesn’t matter when everyone could be answering customer questions and building the product features out.

Conclusion

It’s easy for things to be blown out of proportion. Stupid problems end up much larger than they should be. Having a set of values allows you to refocus and put them back into perspective. Oh this doesn’t really matter AND we can change it pretty much whenever? Then just pick one and we’ll fix it later if it doesn’t work out. No biggie.

So what are your values?

“Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through.”

-Ira Glass

If you’ve used Capistrano before, you’re familiar with the large error logs. Finding errors is, well, a hassle. You’ve got a whole slew of text, some just saying what command it’s going to execute next, sometimes errors, sometimes just output from Bundler or whatever it’s running.

Wouldn’t it be nice if we could colorize Capistrano?

And you can! Just install the capistrano_colors gem on your local machine and we’ll set it up to run on every capistrano deployment without having to modify your existing deploy scripts.

  gem install capistrano_colors

And next, we add a configuration to your ~/.caprc file:

require 'capistrano_colors'    
 
capistrano_color_matchers = [
  { :match => /command finished/,       :color => :hide,      :prio => 10 },
  { :match => /executing command/,      :color => :blue,      :prio => 10, :attribute => :underscore },
  { :match => /^transaction: commit$/,  :color => :magenta,   :prio => 10, :attribute => :blink },
  { :match => /git/,                    :color => :white,     :prio => 20, :attribute => :reverse },
]
 
colorize( capistrano_color_matchers )

And that’s as simple as it is! When you’re done your output should look something like this:

This a must have if you’re using Capistrano for deployments. Check out the source here: https://github.com/stjernstrom/capistrano_colors

Got any other awesome deployment tips? Share them with me in the comments!

Have you ever known someone who was a talker? They could literally sit there all day and talk about how excited they were about doing something, and yet, at the end of the day nothing had been done. We’ve all done it actually. Some of us to a further extent than others.

We don’t want to be naive going into a new venture. Whether it’s a startup or a relationship, we want to feel like we have a good understanding of what we’re getting into before we make our attempt. In reality, this can set you back a long time. You may never feel confident enough to get started.

Do you know what will make you feel confident enough though? Experience.

If you’re a programmer, you’ll know this feeling. You can see example code that works, but until you actually run it for yourself, you don’t fully realize how it works. Just the simple act of doing allows you to have a much greater understanding, no matter how true the words you read are. Just reading this blog post won’t make you realize how much doing matters. You have to do in order to truly realize this. You’re probably thinking “oh he’s right, I should work harder” but that’s as far as you take it.

If you want to become an entrepreneur, working at fulltime isn’t going to help you. If you want to become a ladies man, you’ve got to start talking to women. If you want to become a doctor, reading about it won’t help you. Whatever it is, sitting at home won’t help you.

Get To Work Son

Remove yourself from the talker pool. From now on it’s either a Hell Yeah! or No. Start doing what you talk about. Finish what you start. Nobody cares about your ideas. Nobody cares about your half finished product. They’ve seen this a thousand times, another guy with another goal who isn’t actually trying that hard.

Deciding on what language to use for a project? What person to talk to? It doesn't matter. Make quick decisions. If you made the wrong one, you’ll be able to tell pretty early on and you can go fix it easy enough. Make the decisions that actually matter.

You can read about a topic forever, but that doesn’t mean you can actually do it.

Know when to stop reading and start doing.

Reading only provides suggestions, you can’t know exactly what to learn until you start doing.

Do you catch yourself doing this too? How do you convince yourself to take action instead?

I know everyone has been writing about this lately, so pardon yet another article on the pile, but this is a serious issue that people need to take into consideration daily.

Since the recent Github fiasco, there has been a lot of talk about security on the web. This was an exceptional response on their part, and something that every single one of us needs to take seriously instead of pointing fingers at people, companies, and frameworks.

Let’s dive into the vulnerability.

Mass Assignment

When you create a form in Rails, you’re effectively mapping form values to a hash:

<%= form_for @post do |f| %>
  <%= f.text_field :title %>
  <%= f.text_area :content %>
 
  <% if current_user.admin? %>
    <%= f.check_box :important %>
  <% end %>
 
  <%= f.submit %>
<% end %>

This hash’s values get assigned to the attributes of the Rails model you’re creating:

Parameters: 
{ 
  "commit"=>"Submit", 
  "post"=>{ 
    "title"=>;"First Post", 
    "content"=>;"This is the content for the first post."
  }
}

We access that in our controller’s create action:

def create
  @post = Post.new params[:post]        # THIS IS THE IMPORTANT LINE
 
  if @post.save
    redirect_to @post, :notice => "Successfully created."
  else
    render :action => :new
  end
end
 
# Update is affected as well
 
def update
  @post = Post.find params[:id]
 
  if @post.update_attributes params[:post]      # ALSO USES THE PARAMS HASH
    redirect_to @post, :notice => "Successfully updated."
  else
    render :action => :edit
  end
end

On line 2 here, the params are passed into the new Post object. That is where the submitted form data is assigned to the model and then saved to the database.

And that’s where the problem lies.

By default, a user can update any attributes. So if you decide to allow users to be “admins”, then removing a field in the form that is for admins only is not good enough. A user can still submit the admin only param without permission.

The solution: attr_accessible

The solution for this is attr_accessible. This method tells your model which attributes can be assigned via hash like in the create action we saw earlier.

Let’s do this by example. Pretend we don’t want people updating the :important attribute on a Post. What do we do?

The first thing, is that we should require attr_accessible be on all of our models. In application.rb, uncomment this line:

config.active_record.whitelist_attributes = true

This no longer allows any of the attributes on any models to be set through mass assignment. That’s good.

Now we have to update the model to allow certain attributes:

class Post < ActiveRecord::Base
  attr_accessible :title, :content
end

When you try to attack the site by sending over a :important attribute, it will simply be ignored now. This is exactly what we want.

Rails will throw an exception in development if a protected attribute is attempted to be set. In production, no exception will be raised, the attribute will juts be ignored. That’s a good start.

What if we want some users to be able to set a protected attribute though?

In our case, let’s say that we want admin users to be able to update the :important attribute. If attr_accessible doesn’t allow us to save :important, then how do we actually set it??

Let’s fix up the controller to allow this for users who are admins. We’ll be using Devise with a boolean :admin column on the user so that is where current_user will be coming from.

Let’s hop back in our controller and fix things up:

def create
  # Remove the insecure item(s) so we don't throw an exception in development
  important = params[:post].delete :important
 
  # Create the new post as normal
  @post = Post.new(params[:post])
 
  # If the user is allowed update this attribute, explicitly set it
  @post.important = important if current_user.admin?
 
  if @post.save
    redirect_to @post, :notice => "Successfully created."
  else
    render :action => :new
  end
end
 
# Update is affected as well
 
def update
  # Strip out the protected params so we don't throw exceptions in development
  important = params[:post].delete :important
 
  # Grab the post as usual
  @post = Post.find(params[:id])
 
  # Set the attributes like we do in create
  @post.attributes = params[:post]
 
  # Explicitly update the important attribute only if the user is an admin
  @post.important = important if current_user.admin?
 
  if @post.save
    redirect_to @post, :notice => "Successfully updated."
  else
    render :action => :edit
  end
end

And this will allow any type of user to update the title and content attributes, but only admins are safely allowed to update the important field.

The important part to take note of here is that we are explicitly setting the protected attributes. We know exactly what we are doing when we want to set those attributes, so this (aside from logic problems) makes updating these attributes protected from mass assignment while still being usable.

Another important benefit of attr_accessible is that any new fields we add to the model are immediately protected. This whitelist approach makes sure that we have to declare fields as “safe” which leads to much fewer security holes when changing this code in the future because it forces you to not be forgetful.

Conclusion

This is certainly a feature that will be updated in the future versions of Rails. The current solutions aren’t exceptionally graceful, so I’m sure that we’ll see some nice improvements soon.

In the mean time, keep with whitelisting attributes, and if have a lot of dynamic attributes that depend on the user roles, check out dynamic attr_accessible on Railscast 237.