diff --git a/_includes/header.html b/_includes/header.html
index 8fe4140..0530770 100644
--- a/_includes/header.html
+++ b/_includes/header.html
@@ -1,15 +1,13 @@
-{% case page.url %}
-{% when '/' %}
-{% assign home = "active" %}
+{% assign home = " " %}
{% assign articles = " " %}
{% assign about = " " %}
-{% when '/articles' %}
-{% assign home = " " %}
+
+{% case page.url %}
+{% when '/index.html' %}
+{% assign home = "active" %}
+{% when '/articles.html', '/archive.html' %}
{% assign articles = "active" %}
-{% assign about = " " %}
-{% when '/about' %}
-{% assign home = " " %}
-{% assign articles = " " %}
+{% when '/about.html' %}
{% assign about = "active" %}
{% endcase %}
diff --git a/_posts/2011-01-24-new-site.markdown b/_posts/2011-01-24-new-site.markdown
index a7d8d56..64b9e4c 100644
--- a/_posts/2011-01-24-new-site.markdown
+++ b/_posts/2011-01-24-new-site.markdown
@@ -2,27 +2,29 @@
title: New site
description: Why I chose to design and deploy a new website with jekyll on github
keywords: lucapette, site, github, jekyll
+category: writing
layout: articles
---
Hi everyone,
-Finally, I have a new site. For months I've been thinking about the idea of building a new one. I was searching for a new way of handling my semi-static content and I think I've found a system I really like.
+Finally, I have a new site. For months I've been thinking about the idea of
+building a new one. I was searching for a new way of handling my semi-static
+content and I found a system I really like.
The content of the site is generated by [jekyll](http://jekyllrb.com) and the site itself is hosted by [github](http://pages.github.com):
- [jekyll](http://jekyllrb.com)
- I like it. It is simple and light and has all the features I need for
- my site. It is well-designed and it is simple to use. Jekyll has a
- super lightweight configuration and you can create a site within
- minutes.
+ I like it. It is simple and light and has all the features I need for my
+ site. It is well-designed and it is simple to use. Jekyll has a lightweight
+ configuration and you can create a site within minutes.
- [github](http://pages.github.com)
- I really like the work done by the github guys and I really like git.
- I use it for all my project, I use it even at work (I say *even*
- because I work in Italy, you know). So the idea of pushing a commit on
- a git repository and having my changes published on my site
- immediately is something I find wonderful.
+ I really like the work done by the github folks and I really like git. I use
+ it for all my project, I use it even at work (I say *even* because I work in
+ Italy, you know). So the idea of pushing a commit on a git repository and
+ having my changes published on my site immediately is something I find
+ wonderful.
I like my new creation (especially considering my web design limits) and I hope it will help me to post more often.
diff --git a/_posts/2011-02-11-a-review-of-ruby-best-practices.markdown b/_posts/2011-02-11-a-review-of-ruby-best-practices.markdown
index e713d75..da1cfd1 100644
--- a/_posts/2011-02-11-a-review-of-ruby-best-practices.markdown
+++ b/_posts/2011-02-11-a-review-of-ruby-best-practices.markdown
@@ -2,124 +2,116 @@
title: A review of Ruby Best Practices
description: A review of Ruby Best Practices by Gregory Brown. Published by O'Reilly in June 2009
keywords: ruby best practices, book, review, Gregory Brown
+category: reading
layout: articles
---
Introduction
------------
-[Ruby Best Practices](http://rubybestpractices.com/) is the latest book
-of a Ruby-related series I have read in the past weeks. In this period,
-I’m focusing myself on learning real Ruby, I mean there is a big
-difference between *using Ruby to write code* and *coding in Ruby to
-solve problems*. I think I’m on the right path to master Ruby and a big
-part of my recent improvements derives from reading books. In the
-following weeks I’m going to review all the Ruby-related books I have
-recently read as a way to give back to the community and as a way to
-wrap-up what I learnt.
-
-
+[Ruby Best Practices](http://rubybestpractices.com/) is the latest book of a
+Ruby-related series I have read in the past weeks. In this period, I’m
+focusing myself on learning real Ruby, I mean there is a big difference
+between *using Ruby to write code* and *coding in Ruby to solve problems*. I
+think I’m on the right path to master Ruby and a big part of my recent
+improvements derives from reading books. In the following weeks I’m going to
+review all the Ruby-related books I have recently read as a way to give back
+to the community and as a way to wrap-up what I learnt.
+
The book
--------
-Ruby Best Practices is well-organized and it covers many interesting
-aspects of the Ruby programming world. I think the main aim of the book
-was to offer an optimal introduction into how a problem can be *well*
-solved and how Ruby should be used to solve it. In my opinion, the book
-is well-written and the aim is respected throughout most chapters. One
-of the most interesting aspects of this book is the complete
-independence of the topics covered in the chapters, in fact you could
-simply read only the ones that interest you and I consider it a good
-point.
+Ruby Best Practices is well-organized and it covers many interesting aspects
+of the Ruby programming world. I think the main aim of the book was to offer
+an optimal introduction into how a problem can be *well* solved and how Ruby
+should be used to solve it. In my opinion, the book is well-written and the
+aim is respected throughout most chapters. One of the most interesting aspects
+of this book is the complete independence of the topics covered in the
+chapters, in fact you could simply read only the ones that interest you and I
+consider it a good point.
My consideration grouped by chapter:
- **Driving Code Through Test**
The first chapter is one of my favourites. Unfortunately, I work in a
- country where there is no culture about tests. I really liked the
- examples presented, this chapter helped me to understand better how to
- write fine tests.
+ country where there is no culture about tests. I really liked the examples
+ presented, this chapter helped me to understand better how to write fine
+ tests.
- **Designing Beautiful APIs**
- The concepts behind the topics covered in this chapter deserve more than
- a chapter. This aspect of programming can be very important especially
- while using Ruby, when you are new to it you often feel you are using it
- without understanding its true beauty. You write Ruby code but you don’t
- speak Ruby yet. Then, you need something that puts you on the right path
- to speak this wonderful language. This chapter can help you to enter the
- path because it is full of great advice about how APIs can be written.
- The examples about *parameters* is the most interesting part of the
- chapter.
+ The concepts behind the topics covered in this chapter deserve more than a
+ chapter. This aspect of programming can be very important especially while
+ using Ruby, when you are new to it you often feel you are using it without
+ understanding its true beauty. You write Ruby code but you don’t speak Ruby
+ yet. Then, you need something that puts you on the right path to speak this
+ wonderful language. This chapter can help you to enter the path because it
+ is full of great advice about how APIs can be written. The examples about
+ *parameters* is the most interesting part of the chapter.
- **Mastering The Dynamic Toolkit**
- This is the most difficult chapter to read but, in spite of that, it is
- one of the most interesting parts of the book. Surely it is one of those
- you shouldn’t miss. If you are relatively new to Ruby you’ll enjoy it
- because Gregory Brown covers the *“meta”* side of Ruby in it. In my
- opinion, *this* is the most notable aspect of Ruby that makes it
- wonderful.
+ This is the most difficult chapter to read but, in spite of that, it is one
+ of the most interesting parts of the book. Surely it is one of those you
+ shouldn’t miss. If you are relatively new to Ruby you’ll enjoy it because
+ Gregory Brown covers the *“meta”* side of Ruby in it. In my opinion, *this*
+ is the most notable aspect of Ruby that makes it wonderful.
- **Text Processing File Management**
- I have to be honest, I didn’t like this chapter. I don’t get the point
- of it. Maybe it’s a problem of mine, I don’t know, but after two
- wonderful chapters I started reading this one with great expectations
- for the topic I really like, and I got a bit disappointed when I found
- out I didn’t like the chapter.
+ I have to be honest, I didn’t like this chapter. I don’t get the point of
+ it. Maybe it’s my problem, I don’t know, but after two wonderful chapters I
+ started reading this one with great expectations for the topic I really
+ like, and I got a bit disappointed when I found out I didn’t like the
+ chapter.
- **Functional Programming Techniques**
- Generally speaking, functional programming is not a simple programming
- topic out there but this book covers it in a very nice way and offers to
- the reader many interesting examples and pieces of code about this
- techniques.
+ Generally speaking, functional programming is not a simple programming topic
+ out there but this book covers it in a very nice way and offers to the
+ reader many interesting examples and pieces of code about this techniques.
- **When Things Go Wrong**
- Yes, I know that a book about best practices must contain a chapter
- about debugging and I agree with that. However, I think it is not so a
- Ruby-related topic, It’s a more general topic that deserves even more
- than a chapter in a book. That’s why I wouldn’t expect to find it in a
- Ruby book, just saying:) By the way, I read this chapter and it’s worth
- reading because you can find good advice anyway.
+ Yes, I know that a book about best practices must contain a chapter about
+ debugging and I agree with that. However, I think it is not so a
+ Ruby-related topic, It’s a more general topic that deserves even more than a
+ chapter in a book. That’s why I wouldn’t expect to find it in a Ruby book,
+ just saying:) By the way, I read this chapter and it’s worth reading because
+ you can find good advice anyway.
- **Reducing Cultural Barriers**
- I have to be honest here too. For the most part I didn’t read this
- chapter. I have to read too many books in my life so I tend to read only
- things I really care about. Thus, I can’t express a complete opinion
- about this chapter but surely you should read it if you care about the
- specific topic.
+ I have to be honest here too. For the most part I didn’t read this chapter.
+ I have to read too many books in my life so I tend to read only things I
+ really care about. Thus, I can’t express a complete opinion about this
+ chapter but surely you should read it if you care about the specific topic.
- **Skillful Project Maintenance**
- The idea behind this chapter is a good one. It is a bit unusual to read
- why a real project like [haml](http://haml-lang.com/) can be considered
+ The idea behind this chapter is a good one. It is a bit unusual to read why
+ a real project like [haml](http://haml-lang.com/) can be considered
maintainable. This chapter will enlighten you on generally badly covered
aspects of the reason behind a good project. You should read it.\
- Furthermore, the book comes with three nice appendixes and I really
- liked the first one. It is about writing backward-compatible code and I
- have to say that I didn’t know much about this particular problem. This
- appendix helped me a lot. I found the other two appendixes less
- interesting but still very enjoyable if you care about the topics
- covered.
+ Furthermore, the book comes with three nice appendixes and I really liked
+ the first one. It is about writing backward-compatible code and I have to
+ say that I didn’t know much about this particular problem. This appendix
+ helped me a lot. I found the other two appendixes less interesting but still
+ very enjoyable if you care about the topics covered.
What I liked most
-----------------
-I have a general good opinion of this book. It has several good aspects
-and above all it offers a very good approach to Ruby programming and to
-problem solving. While reading the book I found out nice things about
-Ruby and Ruby libraries and this is the aspect of the book I enjoyed a
-lot.
+I have a general good opinion of this book. It has several good aspects and
+above all it offers a very good approach to Ruby programming and to problem
+solving. While reading the book I found out nice things about Ruby and Ruby
+libraries and this is the aspect of the book I enjoyed a lot.
What I disliked most
--------------------
-There are a few aspects I disliked in the book. If I have to be critic
-about it I would say it covers aspects of programming that I consider
-neither Ruby-related nor “Best Practices” but, obviously, it is just an
-opinion. However, you **should read** it if you care about Ruby.
+There are a few aspects I disliked in the book. If I have to be critic about
+it I would say it covers aspects of programming that I consider neither
+Ruby-related nor “Best Practices” but, obviously, it is just an opinion.
+However, you **should read** it if you care about Ruby.
diff --git a/_posts/2011-02-16-vim-for-rails-developers-what-you-cant-miss.markdown b/_posts/2011-02-16-vim-for-rails-developers-what-you-cant-miss.markdown
index f2096fa..c5fe5ce 100644
--- a/_posts/2011-02-16-vim-for-rails-developers-what-you-cant-miss.markdown
+++ b/_posts/2011-02-16-vim-for-rails-developers-what-you-cant-miss.markdown
@@ -2,8 +2,10 @@
title: "Vim for rails developers: what you can't miss"
description: my first article of the series "vim for rails developer". I will use the article as an index for the series
keywords: vim, rails,rails.vim, NERDTree, FuzzyFinderTextMate, codepath
+category: vim
layout: articles
---
+
Vim is my editor of choice and Rails is my framework. I think many of us have
the same taste and I want to share with you my experiences while using both.
I'm going to write a series of posts regarding this topic. I start with _what
diff --git a/_posts/2011-02-24-a-review-of-metaprogramming-ruby.markdown b/_posts/2011-02-24-a-review-of-metaprogramming-ruby.markdown
index c0c2b72..94bd5b1 100644
--- a/_posts/2011-02-24-a-review-of-metaprogramming-ruby.markdown
+++ b/_posts/2011-02-24-a-review-of-metaprogramming-ruby.markdown
@@ -1,7 +1,8 @@
---
title: A review of Metaprogramming Ruby
-description: A review of Metaprogramming Ruby by Paolo Perrotta. Published by The Pragmatic Bookshelf in 2010
+description: Published by The Pragmatic Bookshelf in 2010
keywords: metaprogramming ruby, book, review, Paolo Perrotta
+category: reading
layout: articles
---
diff --git a/_posts/2011-03-08-why-you-should-spend-some-time-configuring-irb.markdown b/_posts/2011-03-08-why-you-should-spend-some-time-configuring-irb.markdown
index 5046292..4cdbd40 100644
--- a/_posts/2011-03-08-why-you-should-spend-some-time-configuring-irb.markdown
+++ b/_posts/2011-03-08-why-you-should-spend-some-time-configuring-irb.markdown
@@ -2,6 +2,7 @@
title: Why you should spend some time configuring irb
description: Why you should spend some time configuring IRB.
keywords: ruby, irb, console
+category: ruby
layout: articles
---
diff --git a/_posts/2011-03-10-vim-for-rails-developers-a-screencast-review.markdown b/_posts/2011-03-10-vim-for-rails-developers-a-screencast-review.markdown
index b2ce453..5c68c3c 100644
--- a/_posts/2011-03-10-vim-for-rails-developers-a-screencast-review.markdown
+++ b/_posts/2011-03-10-vim-for-rails-developers-a-screencast-review.markdown
@@ -2,11 +2,12 @@
title: "Vim for rails developers: a screencast review"
description: a review of a screencast by Ben Orenstein
keywords: vim, rails, screencast
+category: vim
layout: articles
---
I have recently published my first
-[article](http://lucapette.com/vim/rails/vim-for-rails-developers-what-you-cant-miss/)
+[article](/vim-for-rails-developers-what-you-cant-miss/)
of this series. It got a very nice feedback and I am very glad about that, it
encourages me to keep it on. As part of the feedback I got a very nice email
from [Ben Orenstein](http://codeulate.com/). He was so kind to send me a copy
@@ -20,11 +21,11 @@ work is definitely worth spreading.
## The screencast
The screencast has a good recording quality and Ben speak a very clear
-language (it does count for non-native speakers you know :)). So I think you
+English (it does count for non-native speakers you know :)). So I think you
should be able to follow all the part of it without problems. Furthermore, the
screencast is neither long nor short, the length is just perfect.
-### Introduction
+### Introduction
The screencast starts with a short and nice introduction. It shows you how
to improve your typing skills, Ben gives you nice suggestions on resources
diff --git a/_posts/2011-03-18-improving-irb-history.markdown b/_posts/2011-03-18-improving-irb-history.markdown
index 820458b..ed1bfd1 100644
--- a/_posts/2011-03-18-improving-irb-history.markdown
+++ b/_posts/2011-03-18-improving-irb-history.markdown
@@ -2,11 +2,12 @@
title: Improving IRB history
description: Improving IRB history. Some ways to improve your interaction with IRB history
keywords: ruby, irb, console
+category: ruby
layout: articles
---
I’ve started to consider irb
-[configurations](http://lucapette.com/irb/why-you-should-spend-some-time-configuring-irb/)
+[configurations](/why-you-should-spend-some-time-configuring-irb/)
as a way to improve my productivity. Following this path I’ve got some nice
stuff in my [irbrc](https://github.com/lucapette/dotfiles/blob/master/irbrc).
In the last days I was thinking about how to make irb history more similar to
diff --git a/_posts/2011-03-31-vim-for-rails-developers-indenting-code.markdown b/_posts/2011-03-31-vim-for-rails-developers-indenting-code.markdown
index 93cf366..09a0569 100644
--- a/_posts/2011-03-31-vim-for-rails-developers-indenting-code.markdown
+++ b/_posts/2011-03-31-vim-for-rails-developers-indenting-code.markdown
@@ -2,6 +2,7 @@
title: "Vim for rails developers: indenting code"
description: How you can indent your code preserving the cursor position with a Vim mapping
keywords: vim, rails, indenting code, tip, map, mapping
+category: vim
layout: articles
---
diff --git a/_posts/2011-04-29-getting-nice-bash-aliases-with-ruby.markdown b/_posts/2011-04-29-getting-nice-bash-aliases-with-ruby.markdown
deleted file mode 100644
index eaa3337..0000000
--- a/_posts/2011-04-29-getting-nice-bash-aliases-with-ruby.markdown
+++ /dev/null
@@ -1,52 +0,0 @@
----
-title: Getting nice bash aliases with Ruby
-description: Getting some bash cd aliases with Ruby
-keywords: ruby, bash, alias, aliases
-layout: articles
----
-I like shortcuts a lot. I like aliases and I like all the stuff that makes me
-more productive. Even if we are talking about a couple of characters to change
-a directory in the terminal. So I am one of those people that stores all their
-code in one directory, precisely in `$HOME/code`. And I found it a bit annoying
-to type something like:
-
-{% highlight bash %}
-cd[ENTER]
-cd c[TAB] --> cd code[ENTER]
-cd my-awesome-project[ENTER]
-{% endhighlight %}
-
-when I wanted to reach a project of mine. It was annoying because I had to do
-it many times in a day even to reach the same directory. So I though it would
-be nice to get some dynamic aliases to reach my projects with something like
-the following:
-
-{% highlight bash %}
-my-awe[TAB] --> my-awesome-project[ENTER]
-{% endhighlight %}
-
-It would have been a small boost in my productivity. So I tried to do it with
-Bash scripting but, since I am not a bash
-[hero](http://twitter.com/#!/wayneeseguin), I wasn’t successful. So I switched
-to Ruby and I came up with the following script:
-
-{% highlight ruby %}
-#!/usr/bin/ruby
-
-Dir["#{File.expand_path("~/code")}/*"].each do |file|
- if File.directory?(file)
- cmd=File.basename(file)
- puts "alias #{cmd}=\"cd #{file}\"" if `which #{cmd}`.length == 0
- end
-end
-{% endhighlight %}
-
-To my mind it is quite self-explanatory. And in my bashrc I put the following:
-
-{% highlight bash %}
-$HOME/.bash/code_dirs.rb > $HOME/.bash/codedirs
-source $HOME/.bash/codedirs
-{% endhighlight %}
-
-This simply redirects the output of the above-mentioned Ruby script in a file
-sourced in the current bash shell. It just works fine for me.
diff --git a/_posts/2011-05-06-a-review-of-the-rails-3-way.markdown b/_posts/2011-05-06-a-review-of-the-rails-3-way.markdown
index 7ac40e2..ad7072a 100644
--- a/_posts/2011-05-06-a-review-of-the-rails-3-way.markdown
+++ b/_posts/2011-05-06-a-review-of-the-rails-3-way.markdown
@@ -1,7 +1,8 @@
---
title: A review of The Rails 3 way
-description: A review of The Rails 3 way by Obie Fernandez. Published by Addison Wesley in Dicember 2010
+description: Published by Addison Wesley in Dicember 2010
keywords: the rails 3 way, book, review, Obie Fernandez
+category: reading
layout: articles
---
diff --git a/_posts/2011-05-24-vim-for-rails-developers-recursive-macros-and-ack.markdown b/_posts/2011-05-24-vim-for-rails-developers-recursive-macros-and-ack.markdown
index e77fb2e..0c19cc5 100644
--- a/_posts/2011-05-24-vim-for-rails-developers-recursive-macros-and-ack.markdown
+++ b/_posts/2011-05-24-vim-for-rails-developers-recursive-macros-and-ack.markdown
@@ -2,6 +2,7 @@
title: 'Vim for Rails developers: Recursive macros and Ack.vim'
description: 'How to use vim macros and ack.vim to get done repetitive tasks'
keywords: vim, rails, recursive macros, macro, ack, ack.vim
+category: vim
layout: articles
---
diff --git a/_posts/2011-08-29-multiple-files-upload-with-carrierwave-and-nested_form.markdown b/_posts/2011-08-29-multiple-files-upload-with-carrierwave-and-nested_form.markdown
index 9d2d433..28f33c1 100644
--- a/_posts/2011-08-29-multiple-files-upload-with-carrierwave-and-nested_form.markdown
+++ b/_posts/2011-08-29-multiple-files-upload-with-carrierwave-and-nested_form.markdown
@@ -2,6 +2,7 @@
title: Multiple files upload with carrierwave and nested_form
description: Multiple Attachments with carrierwave and nested_form
keywords: rails, carrierwave, nested_form, attachments
+category: rails
layout: articles
---
diff --git a/_posts/2011-09-01-a-review-of-the-rspec-book.markdown b/_posts/2011-09-01-a-review-of-the-rspec-book.markdown
index 6cfe218..11c52ee 100644
--- a/_posts/2011-09-01-a-review-of-the-rspec-book.markdown
+++ b/_posts/2011-09-01-a-review-of-the-rspec-book.markdown
@@ -1,7 +1,8 @@
---
title: A review of The RSpec Book
-description: A review of The RSpec Book by David Chelimsky. Published by The Pragmatic Programmer in Dicember 2010
+description: Published by The Pragmatic Programmer in Dicember 2010
keywords: the rspec book, ruby, book review, David Chelimsky, tdd, bdd, cucumber
+category: reading
layout: articles
---
@@ -10,8 +11,8 @@ As usual, my considerations grouped by chapter:
### Introduction
The book starts with an introduction to the reasons behind BDD. It’s a cool
-introduction, small and clear. It’s very useful if these topics are a closed
-book for you. To cut a long story short, if you want a spectacular and small
+introduction, short and clear. It’s very useful if these topics are a closed
+book for you. To cut a long story short, if you need a spectacular and short
introduction to BDD/TDD reasons watch [this](http://vimeo.com/23061155) by
[Corey Haines](http://coreyhaines.com/).
diff --git a/_posts/2011-09-05-pry-everywhere.markdown b/_posts/2011-09-05-pry-everywhere.markdown
index da11923..b5227e5 100644
--- a/_posts/2011-09-05-pry-everywhere.markdown
+++ b/_posts/2011-09-05-pry-everywhere.markdown
@@ -2,6 +2,7 @@
title: Pry Everywhere
description: "Pry is an IRB alternative. I'll show here a quick way to replace pry everywhere"
keywords: pry, rails, irb, ruby
+category: ruby
layout: articles
---
diff --git a/_posts/2011-10-07-a-review-of-crafting-rails-applications.markdown b/_posts/2011-10-07-a-review-of-crafting-rails-applications.markdown
index 48a9bd9..ebba0a8 100644
--- a/_posts/2011-10-07-a-review-of-crafting-rails-applications.markdown
+++ b/_posts/2011-10-07-a-review-of-crafting-rails-applications.markdown
@@ -2,6 +2,7 @@
title: A review of Crafting Rails Applications
description: A review of Crafting Rails Applications by José Valim. Published by The Pragmatic Programmer in March 2011
keywords: a review of Crafting Rails Applications, ruby, book review, rails, enginex, José Valim
+category: reading
layout: articles
---
As usual, my considerations grouped by chapter:
diff --git a/_posts/2011-11-17-vim-for-rails-developers-lazy-modern-configuration.markdown b/_posts/2011-11-17-vim-for-rails-developers-lazy-modern-configuration.markdown
index c07df92..fd3a861 100644
--- a/_posts/2011-11-17-vim-for-rails-developers-lazy-modern-configuration.markdown
+++ b/_posts/2011-11-17-vim-for-rails-developers-lazy-modern-configuration.markdown
@@ -2,40 +2,95 @@
title: "Vim for Rails developers: Lazy modern configuration"
description: How I think you should deal with configuring Vim
keywords: vim, rails, configuration, pathogen.vim
+category: vim
layout: articles
---
-Vim is very customizable, it has thousands of plugins suitable for everyone's needs. Each of us uses some of them. Furthermore, it has a good number of files you can use to configure some aspects of the editor and it would be very nice to keep all this stuff under a version control system. But, before I try to do my best to explain what I mean with lazy modern configuration, I would like to say some words about Vim distro. In short: **Do not use a vim distro**. This is the most important thing to consider about configuring vim. So I'll repeat it: **Do not use a Vim distro**. I prefer to sound unpopular but it's not the Vim way. If you need an Editor that makes things for you, go look for something else. Vim is just the opposite, Vim is the perfect editor that leaves you the possibility of making things the way you prefer. With a Vim distro, you'll never master Vim or at least you'll reduce the chances to learn how Vim really works. I'm not totally against distro, they can inspire you. It's like code reading for configurations: know them, get inspired by them but choose your own way. I'm not saying you should start from scratch. If you're using a Vim distro at the moment you could do the following exercise. Think about what you really use all the time inside the Vim editor that is given by a plugin. The odds are you'll come up with three or four plugins at the moment and a number of mappings. So you could grab those plugins and start from there.
-
-After my little battle against distros, what does *lazy modern* configuration mean? Or, at least, what do I mean?
+Vim is very customizable, it has thousands of plugins suitable for everyone's
+needs. Each of us uses some of them. Furthermore, it has a good number of
+files you can use to configure some aspects of the editor and it would be very
+nice to keep all this stuff under a version control system. But, before I try
+to do my best to explain what I mean with lazy modern configuration, I would
+like to say some words about Vim distro. In short: **Do not use a vim
+distro**. This is the most important thing to consider about configuring vim.
+So I'll repeat it: **Do not use a Vim distro**. I prefer to sound unpopular
+but it's not the Vim way. If you need an Editor that makes things for you, go
+look for something else. Vim is just the opposite, Vim is the perfect editor
+that leaves you the possibility of making things the way you prefer. With a
+Vim distro, you'll never master Vim or at least you'll reduce the chances to
+learn how Vim really works. I'm not totally against distro, they can inspire
+you. It's like code reading for configurations: know them, get inspired by
+them but choose your own way. I'm not saying you should start from scratch. If
+you're using a Vim distro at the moment you could do the following exercise.
+Think about what you really use all the time inside the Vim editor that is
+given by a plugin. The odds are you'll come up with three or four plugins at
+the moment and a number of mappings. So you could grab those plugins and start
+from there.
+
+After my little battle against distros, what does *lazy modern* configuration
+mean? Or, at least, what do I mean?
Modern
------
-Programmers are [lazy](http://c2.com/cgi/wiki?LazinessImpatienceHubris). And it's a good thing. Being lazy can help you become a better programmer. If you're lazy, you will write programs that do stuff for you. Regarding Vim, you want a modern way of automatic handling your vim configuration for tasks like new installations and plugins updating. So modern means "do not copy and paste files over configurations directories, do not try to update plugins by hand". It's 2011 and we need a good way of managing all this stuff. As many of you already imagined, I deliberately steal the modern adjective from a good nice [article](http://tammersaleh.com/posts/the-modern-vim-config-with-pathogen).
+Programmers are [lazy](http://c2.com/cgi/wiki?LazinessImpatienceHubris). And
+it's a good thing. Being lazy can help you become a better programmer. If
+you're lazy, you will write programs that do stuff for you. Regarding Vim, you
+want a modern way of automatic handling your vim configuration for tasks like
+new installations and plugins updating. So modern means "do not copy and paste
+files over configurations directories, do not try to update plugins by hand".
+It's 2011 and we need a good way of managing all this stuff. As many of you
+already imagined, I deliberately steal the modern adjective from a good nice
+[article](http://tammersaleh.com/posts/the-modern-vim-config-with-pathogen).
Lazy
----
-Spend your time configuring something only and only when you really need it. Highly configurable tools could be a double-edged sword, and Vim is the most incredible tool I've ever used from this point of view. While hanging around the web you meet nice mappings, nice plugins, nice stuff and you get excited about suddenly using them. Please simply don't. When I run into new plugins or mappings and find them useful, I bookmark them and go ahead. Then, while working in Vim, it comes to my mind I could use that bookmarked stuff. Now you're thinking that I put that new wonderful thing into my configuration. Actually I don't, I do my best to resist. And I make this process happen many times. Only when I get really tired of desiring that particular thing in my workflow, I eventually go find it and put it into Vim.
-I can assure you this process will work very well for various reasons:
-
-- You really understand what your configuration lacks when you run into the same need many times in a row. That's the main point.
+Spend your time configuring something only and only when you really need it.
+Highly configurable tools could be a double-edged sword, and Vim is the most
+incredible tool I've ever used from this point of view. While hanging around
+the web you meet nice mappings, nice plugins, nice stuff and you get excited
+about suddenly using them. Please simply don't. When I run into new plugins or
+mappings and find them useful, I bookmark them and go ahead. Then, while
+working in Vim, it comes to my mind I could use that bookmarked stuff. Now
+you're thinking that I put that new wonderful thing into my configuration.
+Actually I don't, I do my best to resist. And I make this process happen many
+times. Only when I get really tired of desiring that particular thing in my
+workflow, I eventually go find it and put it into Vim. I can assure you this
+process will work very well for various reasons:
+
+- You really understand what your configuration lacks when you run into the
+ same need many times in a row. That's the main point.
- You don't make your configuration dirty.
- You use only what you need.
- *Perfection is attained, not when no more can be added, but when no more can be removed.* said [someone](http://en.wikiquote.org/wiki/Antoine_de_Saint-Exup%C3%A9ry).
+ *Perfection is attained, not when no more can be added, but when no more
+ can be removed.* said
+ [someone](http://en.wikiquote.org/wiki/Antoine_de_Saint-Exup%C3%A9ry).
Taking care of plugins
----------------------
-Now, if you want to obtain a real lazy modern configuration you have to do at least the following things:
+Now, if you want to obtain a real lazy modern configuration you have to do at
+least the following things:
- Choose a plugin manager
- Put your vim directory under a version control system
- Make the vim directory update process easy
- Make the plugins update process easy
-Now you could choose the plugin manager you prefer, there are many of them. But I strongly recommend you to use [pathogen.vim](http://www.vim.org/scripts/script.php?script_id=2332). [Tpope](http://tpo.pe/) wrote it, and it should be enough to use it. No, seriously, I've played a bit with other solutions but I still prefer pathogen. Citing the README: "Manage your 'runtimepath' with ease. In practical terms, pathogen.vim makes it super easy to install plugins and runtime files in their own private directories." And this is the reason why I really love pathogen. You simply have to put a plugin in the bundle directory in order to use it. This makes it very easy to test plugins too, I do it all the time. It is very easy to setup and it's so awesome you can even bundle the plugin itself. If you don't use it and you want to give it a try consider using the following steps:
+Now you could choose the plugin manager you prefer, there are many of them.
+But I strongly recommend you to use
+[pathogen.vim](http://www.vim.org/scripts/script.php?script_id=2332).
+[Tpope](http://tpo.pe/) wrote it, and it should be enough to use it. No,
+seriously, I've played a bit with other solutions but I still prefer pathogen.
+Citing the README: "Manage your 'runtimepath' with ease. In practical terms,
+pathogen.vim makes it super easy to install plugins and runtime files in their
+own private directories." And this is the reason why I really love pathogen.
+You simply have to put a plugin in the bundle directory in order to use it.
+This makes it very easy to test plugins too, I do it all the time. It is very
+easy to setup and it's so awesome you can even bundle the plugin itself. If
+you don't use it and you want to give it a try consider using the following
+steps:
- Create the .vim/bundle directory
- Put pathogen.vim there
@@ -46,7 +101,25 @@ Now you could choose the plugin manager you prefer, there are many of them. But
call pathogen#helptags()
{% endhighlight %}
-Now, you could move all your plugins in the bundle directory. They should keep working fine. This is a good starting point to make your configuration modern and clean but it still lacks the lazy part. You can't update your plugins easily. And in my point of view, *easily* should mean maximum one command to update plugins. So, once again, you can achieve such a result in many ways, but you should go straight with git. Git is widely used in our (as a note: our means rails+vim users) world and the odds are you will find the plugin you want to add on github. Actually, there is even a [http://vim-scripts.org/](http://vim-scripts.org/) project. It's *sweet*. Another great reason to adopt pathogen.vim is the natural integration with [git submodules](http://book.git-scm.com/5_submodules.html). With submodules and pathogen.vim you can get a lazy modern vim configuration. Now, I want to say just a couple of words about my way of using this stuff to make more clear what I mean with *easily*. I added to the pile of tools just another one. I'm a Rubyist, not a Ruby Hero but an ordinary Rubyist. So, for me, solving a boring task with files and the shell means *Use Rake*. So I used Rake but you could use a bash script or whatever else. The real point is focusing on the two above mentioned steps. When I want to update my vim configuration directory I type:
+Now, you could move all your plugins in the bundle directory. They should keep
+working fine. This is a good starting point to make your configuration modern
+and clean but it still lacks the lazy part. You can't update your plugins
+easily. And in my point of view, *easily* should mean maximum one command to
+update plugins. So, once again, you can achieve such a result in many ways,
+but you should go straight with git. Git is widely used in our (as a note: our
+means rails+vim users) world and the odds are you will find the plugin you
+want to add on github. Actually, there is even a
+[http://vim-scripts.org/](http://vim-scripts.org/) project. It's *sweet*.
+Another great reason to adopt pathogen.vim is the natural integration with
+[git submodules](http://book.git-scm.com/5_submodules.html). With submodules
+and pathogen.vim you can get a lazy modern vim configuration. Now, I want to
+say just a couple of words about my way of using this stuff to make more clear
+what I mean with *easily*. I added to the pile of tools just another one. I'm
+a Rubyist, not a Ruby Hero but an ordinary Rubyist. So, for me, solving a
+boring task with files and the shell means *Use Rake*. So I used Rake but you
+could use a bash script or whatever else. The real point is focusing on the
+two above mentioned steps. When I want to update my vim configuration
+directory I type:
{% highlight sh %}
rake
@@ -58,20 +131,43 @@ and when I want to update my plugins I type:
rake update_bundles
{% endhighlight %}
-Just a command per step but please be careful. I tell you once again: you don't have use my rake tasks or someone else's solution. Do what you prefer, use the tools you like but make it easy. With an easy process it will be simple to add and remove things from Vim. **You'll never find the right configuration**, you will change your coding habits, your needs will change as well. You'll learn a new language or give up using another one. So, you need a simple process to take care of this ever-changing status because you don't have to waste too much time configuring your editor.
+Just a command per step but please be careful. I tell you once again: you
+don't have use my rake tasks or someone else's solution. Do what you prefer,
+use the tools you like but make it easy. With an easy process it will be
+simple to add and remove things from Vim. **You'll never find the right
+configuration**, you will change your coding habits, your needs will change as
+well. You'll learn a new language or give up using another one. So, you need a
+simple process to take care of this ever-changing status because you don't
+have to waste too much time configuring your editor.
Runtime directories and files
-----------------------------
-We've just talked about a big part of the problem. But there is another thing to consider. Your own configuration consists basically of two things: the plugins you use and all the rest. We took care of the plugins, now we have to think about the rest. That means your vimrc and all your files in the other Vim runtime directories. Now before we talk about how to keep your files clean, we need to spend sometime talking about vim runtime directories. Every time you run Vim, it searches in a number of directories in order to load default and custom preferences. This process is described briefly in [runtimepath](http://vimdoc.sourceforge.net/htmldoc/options.html#'runtimepath'). Now, you have to know what some of these directories are if you want to keep things clean:
+We've just talked about a big part of the problem. But there is another thing
+to consider. Your own configuration consists basically of two things: the
+plugins you use and all the rest. We took care of the plugins, now we have to
+think about the rest. That means your vimrc and all your files in the other
+Vim runtime directories. Now before we talk about how to keep your files
+clean, we need to spend sometime talking about vim runtime directories. Every
+time you run Vim, it searches in a number of directories in order to load
+default and custom preferences. This process is described briefly in
+[runtimepath](http://vimdoc.sourceforge.net/htmldoc/options.html#'runtimepath').
+Now, you have to know what some of these directories are if you want to keep
+things clean:
- after
- The after directory is a very important one. You can use it to override system settings, it has the same structure of the entire vim configuration directory (itself excluded).
+ The after directory is a very important one. You can use it to override
+ system settings, it has the same structure of the entire vim configuration
+ directory (itself excluded).
- autoload
- This directory is a bit underused and poorly known. The nice thing is that it works exactly how a rubyist imagines it to work. You can put in this directory all the functions you want to call with a particular mapping or functions without problems. The nice thing is that these functions will be only loaded the first time you call them.
+ This directory is a bit underused and poorly known. The nice thing is that
+ it works exactly how a rubyist imagines it to work. You can put in this
+ directory all the functions you want to call with a particular mapping or
+ functions without problems. The nice thing is that these functions will be
+ only loaded the first time you call them.
- colors
@@ -79,15 +175,24 @@ We've just talked about a big part of the problem. But there is another thing to
- compiler
- The files you put here won't be loaded by Vim at startup but you can use them with the [compiler](http://vimdoc.sourceforge.net/htmldoc/quickfix.html#:compiler) command in order to set the errorformat and the make options.
+ The files you put here won't be loaded by Vim at startup but you can use
+ them with the
+ [compiler](http://vimdoc.sourceforge.net/htmldoc/quickfix.html#:compiler)
+ command in order to set the errorformat and the make options.
- ftplugin
- The files in this dir follow the simple convention based on the filetype of the buffer you are opening with Vim. So if you put here a file called ruby.vim, it will be loaded only when you open a Ruby file.
+ The files in this dir follow the simple convention based on the filetype of
+ the buffer you are opening with Vim. So if you put here a file called
+ ruby.vim, it will be loaded only when you open a Ruby file.
- ftdetect
- This directory follows the same convention of ftplugin but serves a different purpose. You can use this dir to detect filetypes when a particular condition is met. See [docs](http://vimdoc.sourceforge.net/htmldoc/filetype.html#ftdetect) for a good example.
+ This directory follows the same convention of ftplugin but serves a
+ different purpose. You can use this dir to detect filetypes when a
+ particular condition is met. See
+ [docs](http://vimdoc.sourceforge.net/htmldoc/filetype.html#ftdetect) for a
+ good example.
- plugin
@@ -107,20 +212,37 @@ Now you have some information to clean your vim directory and you can focus on *
- Organize your general mappings
- I've used a dir with some files in it, each file groups a number of mappings according to its own name. It will help you to focus on what you really need and what you currently have.
+ I've used a dir with some files in it, each file groups a number of
+ mappings according to its own name. It will help you to focus on what you
+ really need and what you currently have.
-- Put your filetype based files in the after/ftplugin directory and use the [buffer](http://vimdoc.sourceforge.net/htmldoc/map.html#:map-) argument for mappings, it's an important feature and you should spend some time to understand it. Maybe a bit poorly known. Thus, you won't mess Vim configuration for those files.
+- Put your filetype based files in the after/ftplugin directory and use the
+ [buffer](http://vimdoc.sourceforge.net/htmldoc/map.html#:map-)
+ argument for mappings, it's an important feature and you should spend some
+ time to understand it. Maybe a bit poorly known. Thus, you won't mess Vim
+ configuration for those files.
- Order personal settings and group your plugin settings in your vimrc
- Use the criteria you find more logic for your setting. But keep them ordered. When you change something, you'll know where to go. Grouping your settings by plugin is a good idea too.
+ Use the criteria you find more logic for your setting. But keep them
+ ordered. When you change something, you'll know where to go. Grouping your
+ settings by plugin is a good idea too.
- Comment your settings
- I'm writing about it because I would force myself to do it too. It's important even for obvious things. If you have your vim directory on a public service like github or bitbucket, you're being kind to other people.
+ I'm writing about it because I would force myself to do it too. It's
+ important even for obvious things. If you have your vim directory on a
+ public service like github or bitbucket, you're being kind to other
+ people.
OK but why?
-----------
-I know all this configuration stuff might seem a bit paranoid but I think I have a strong point to support my ideas: You won't stop learning about Vim. I mean unless you're a [Vim](http://tpo.pe/) [Hero](http://stevelosh.com/). You're are going to learn a thing a day with your editor if you choose Vim. So a lazy modern configuration sure can help you to stay focused on what you are doing. Whatever it is learning Vim itself, writing code, blogging or something else.
+I know all this configuration stuff might seem a bit paranoid but I think I
+have a strong point to support my ideas: You won't stop learning about Vim. I
+mean unless you're a [Vim](http://tpo.pe/) [genious](http://stevelosh.com/).
+You're are going to learn a thing a day with your editor if you choose Vim. So
+a lazy modern configuration sure can help you to stay focused on what you are
+doing. Whatever it is learning Vim itself, writing code, blogging or something
+else.
diff --git a/_posts/2011-11-22-twitter-bootstrap-on-rails.markdown b/_posts/2011-11-22-twitter-bootstrap-on-rails.markdown
index 02a06c1..a034647 100644
--- a/_posts/2011-11-22-twitter-bootstrap-on-rails.markdown
+++ b/_posts/2011-11-22-twitter-bootstrap-on-rails.markdown
@@ -2,12 +2,29 @@
title: Twitter Bootstrap on Rails
description: How you can easily integrate the twitter bootstrap framework and Ruby on Rails
keywords: rails, twitter bootstrap, simple_form, show_for
+category: rails
layout: articles
---
-In the past weeks I saw a lot of interest for the [twitter bootstrap](http://twitter.github.com/bootstrap/) framework, and for good reasons. If you're not familiar with it, go straight to the site. I guess you'll like it. As for me I'm very enthusiastic about it because I'm neither a design guru nor a good one. So having a framework that gives nice results in such a little time is like watching a small dream come true. Now, as I said, I witnessed a lot of interest for the framework in Rails community, I also read a couple of good articles about how to play with the framework and the shiny new asset pipeline we recently got. But I have found little information on the aspect I find most interesting about this framework and the Rails community. It works great with the Rails ecosystem. So here I am to write down a couple of things I learnt while integrating twitter bootstrap into my recent projects.
-
-First of all, I focused a little on a simple layout that I've used as the base of some projects. I've just adopted an [example](http://twitter.github.com/bootstrap/examples/container-app.html) from the site and modified the application layout of a fresh new rails 3.1.1 app in the following way:
+In the past weeks I saw a lot of interest for the [twitter
+bootstrap](http://twitter.github.com/bootstrap/) framework, and for good
+reasons. If you're not familiar with it, go straight to the site. I guess
+you'll like it. As for me I'm very enthusiastic about it because I'm neither a
+design guru nor a good one. So having a framework that gives nice results in
+such a little time is like watching a small dream come true. Now, as I said, I
+witnessed a lot of interest for the framework in Rails community, I also read
+a couple of good articles about how to play with the framework and the shiny
+new asset pipeline we recently got. But I have found little information on the
+aspect I find most interesting about this framework and the Rails community.
+It works great with the Rails ecosystem. So here I am to write down a couple
+of things I learnt while integrating twitter bootstrap into my recent
+projects.
+
+First of all, I focused a little on a simple layout that I've used as the base
+of some projects. I've just adopted an
+[example](http://twitter.github.com/bootstrap/examples/container-app.html)
+from the site and modified the application layout of a fresh new rails 3.1.1
+app in the following way:
{% highlight erb %}
@@ -48,7 +65,8 @@ First of all, I focused a little on a simple layout that I've used as the base o