Oct
04
2008
1
comments

New Garden Gnome At Code Genome

What do you call someone who works at Code Genome?

Garden Gnomes

That’s right, a garden gnome. (Apparently, some British dude had trouble saying the name of our company.)

It is with great pleasure that I announce that a new gnome has joined the team: Pierre Olivier Martel. PO is our first rails garden gnome guru-to-be. Welcome aboard PO!

Written by jfcouture in: Rails |
Sep
17
2008
0
comments

Code Genome Plan For World Conquest: We’re Looking For Ruby On Rails Developers

(company name) Code Genome, based in (city name) Montreal, the world leading (whatever it is you do) Ruby On Rails consulting firm, is looking to hire (position name) a Ruby On Rails developer for its (adjective) star team.

(Mad Libs are are the ultimate tool to create a job posting.)

Ruby on Rails Guru

We are looking for a Ruby on Rails guru. You have a couple of projects under your belt (a black one). Everything you ever wrote ended up in a plugin. You’re just that good. You should be the one writing this job description and telling us what a real Rails guru is all about.

Ruby on Rails Refugee

We are looking for a Ruby on Rails refugee. You have a couple of years of experience in web development in Java or .Net. One night, you built a small project in Rails, wanting to know what the hype was all about. It was love at first sight. Now, you loathe your day-time job and all the unnecessary complexity involved. It’s time for a change.

Ruby on Rails Guru-to-be

We are looking for a Ruby on Rails guru-to-be. You have built at least one small project in your spare time using Rails and fell in love. You are now aspiring to have an international career as the next rock star of ruby development. But you need someone to give you a chance.

For more information, visit http://jobs.codegenome.com

One more thing. The best part of this job is that you get to work with me, the only ruby witch doctor in Montreal. Oh, and if you feel guru is overused, you get to call yourself whatever you want: ninja, kung fu master, sith lord, drunken monkey cowboy of hell, papa smurf, or the ultimate, zombie ninja pirate. Nothing beats a zombie ninja pirate.

Written by jfcouture in: Rails, Ruby |
Apr
02
2008
2
comments

Rails Moving To Git: How To Really Understand And Master Git

It appears that Rails will switch to git real soon. Nice! However, it means confusion for developers used to svn. You might find a few tips on this blog to help you get started, but right now I want to give you the secret to git mastery:

You need to think in terms of how you want to modify your graph. My what you say?!? A git repository is a directed acyclic graph of commits (the nodes). Huh?? Read this article: Git for Computer Scientists. Do not continue reading before you understand that article. Everything falls into place when you understand that all git commands manipulate these four basic structures: blobs, trees, commits and tags.

From now on, before typing a git command in the shell, try to picture in your head how you want your repository to look after the command. Your best friend is gitk for visualization (use the –all option to see all branches). Run it before and after each command you do with git. Here is what you should be thinking when using these commands:

  • git commit: I am creating a new node in my graph, linked to the current node.
  • git branch branch_name: I am tagging a node with a name.
  • git merge: I am creating a new node that will link two parents nodes, one for each branch I am merging (could be more than two).
  • git fetch remote_repos: I am adding all the nodes from a distant repository to my graph.
  • git push: I am sending all the nodes I created to a distant repository.
  • git pull: I want to fetch all remote nodes AND merge.

Once you think like this, “advanced” git stuff becomes trivial. For example, this morning one coworker realized that his last three commits actually belonged to a branch. Try to visualize the solution. When you think about it, nothing has to change about the actual graph, just which nodes the tag (the branch name) needs to point at. So you just create a branch where you are, on the last commit, and then you can use the reset command to move back the other branch to the correct commit.

That’s the core of git. There are maybe two other things to worry about when using git. The first is the index, which is sort of a staging area where you prepare your commits. The other thing is the way git configuration works and the way it names and references branches (and the special reference HEAD) and remote repositories. Check out the git user manual.

Written by jfcouture in: Rails, git |
Dec
09
2007
3
comments

80% of Rails Developers To Switch To Git Before Christmas ‘08: How To Get Ahead And Start Now

Rails developers will switch to Git because just like Rails is ten times better than any java( or .Net) framework, git is ten times better than subversion.

I will be presenting git at the next Montreal On Rails. You may want to wait for my presentation to switch to git, but that means going a whole month without benefitting from git’s awesomeness. So here are a couple of links to get you started:

That should be enough to get you started. Make sure you listen to Linus’ talk. It’s one hour long, but it’s definitely worth it.

Written by jfcouture in: Rails, git |
Dec
06
2007
3
comments

Montreal On Rails, Deployment Edition

Deployment, deployment, deployment. Ok not three, but just two awesome presentations on deployment.

Carl Mercier, Rails Deployment Option

Carl compared the different hosting solutions available for Rails. You want to avoid shared hosting and start with a Virtual Private Server(VPS) so you get enough RAM to run a couple of mongrels. Carl has had good experiences with Slicehost. A dedicated server is the next step if you need more power, but you might want to skip it and go directly to the next option.

Amazon EC2. The game changer. Take all the advantages of server virtualization and add on demand power when you need to scale. Check out EC2 on Rails. It contains a complete image already setup for rails. Also check out Rightscale. They have a nice dashboard to help you manage your instances.

Mehdi Adda, Setting Up Your Server

Mehdi showed how to setup mongrel+nginx+seesaw+monit. Mongrel acts as the app server. Nginx is a lightweight and fast web server. Seesaw allows you to restart your mongrel cluster with no down time and always only one version of your app running. Monit supervises your processes and can kill them if they have a problem, restart them if they crash or send you a warning email if you’re running out of disk space.

Check out Mehdi’s slides. They are very thorough on the steps to setup each part. You can get the slides on the Montreal On Rails website.

Next edition

The next is scheduled for the middle of January. I’m wondering if people would be interested in a presentation on git. It is not strictly rails related, but should be of interest to all rails developer. I’ve been using it for almost three months and it rocks. In fact, I’m going to make a prediction: 80% of all rails developer will switch to git before the end of 2008.

Written by jfcouture in: Rails, montreal, social |
Nov
22
2007
0
comments

Metaprogramming Javascript For Dummies

Dan Webb has very very interesting presentation called Metaprogramming Javascript. I think it’s the most simple and understandable explanation of how the diffferent javascript frameworks extend javascript. It takes five minutes to go through and you gain a better appreciation of javascript’s simplicity and power.

Here is another presentation to put your new knowledge to test that builds a small DSL for working with forms that allows for something like this: show(”province-field”).when(”country”).is(”Canada”).

Written by jfcouture in: Rails, javascript |
Nov
07
2007
0
comments

Montreal On Rails, 4th Edition Report

Yet another great Montreal On Rails last night, again at the Standout Jobs office.

JRuby on and off Rails, by Mathieu Martin

JRuby is an interesting project in many regards. Whether you already have a huge investments in Java, need one of its many libraries, want a faster VM (not for long), prefer to write a performance sensitive part of your app in Java over C, JRuby has something for you.

It can be tough to follow the development of JRuby and Mathieu did a great job of bringing everyone up to speed on the current state of JRuby and where it’s going. I learned that even C libraries will soon be usable (they just need a small wrapper.)

There remains some small compatibility issues between JRuby and the official ruby, so you need to test your app to see if everything is working for you.

The only thing that bugs me is when I hear that deployment is easier. I don’t think copying a war file is easier than running cap deploy. Yes you have to make your cap recipe and configure your server, but I hear that this is still easier than installing something like Tomcat.

acts_as_state_machine, Alain Pilon

acts_as_state_machine is a great little plugin that more people should know about. Finite state machines are very useful to model lots of thing. The plugin provides a way to define states, events that change the state and actions when that happens. FSM are simple to understand and simple to verify their correctness.

Comatose, Sylvain Carle

Comatose is another nifty plugin that gives you basic Content Management System(CMS) functionality (create, edit pages and history of modifications). Sylvain Carle explained how to use it and how easily they integrated it for the Praized Media website and in another of their projects in two days.

Written by jfcouture in: Rails, montreal, social |
Oct
24
2007
0
comments

The Presenter Pattern For Rails

The problem:

Having logic in your view is bad. Putting some in the helpers can help. Some methods can be put on the model. Sometimes, your view involves a couple of models, the helpers get bigger, you’re not sure on which model to put a method as it needs data on a few of the associations. The view is getting ugly, you have to go through pages of helper methods to find things. You’re feeling dirty.

The solution:

Move all the methods related to one of the view to a class (the presenter). Create it in the controller by passing it all the objects it needs to manipulate. Change your view to only call methods on your @presenter.

Implementation:

You will probably want to have access to the ActionView::Helpers::* in your presenter so it can useful to declare a base presenter class you will inherit from like this:

class Presenter
  include ActionView::Helpers::TagHelper
  include ActionView::Helpers::FormHelper
  include ActionView::Helpers::FormTagHelper
  include ActionView::Helpers::FormOptionsHelper
  include ActionView::Helpers::DateHelper
  include ActionView::Helpers::JavascriptHelper
  include ActionView::Helpers::AssetTagHelper

  def intialize(controller)
    @controller = controller
  end
end

Some helpers need the @controller to do their magic.

Success stories:

I’ve used this approach two times now. Last time, I had a view that showed deeply nested data (parent => children => children => children). There were a bunch a checkboxes that needed to be all checked/unchecked at the same time depending on which element was clicked. Putting all the methods required to generate the checkboxes with ids and class and restoring that from the params in case of an error was ugly. However, that ugliness was nicely sealed in a class that prevented infection of the rest of the code.

Further links:

Warning:

The approach I described here may not fit the original presenter pattern as described in those other links. What’s important here is, if your view is getting ugly, hard to test, you have too many helpers, or the code is starting to smell, you can move stuff to a new class. This may seem evident, but I sometimes feel people using rails forget that you can do stuff “outside” of the way rails normally structure a project. Also note that the presenter pattern is definitely not something you need for every project.

Written by jfcouture in: Rails, Software Engineering |
Oct
03
2007
1
comments

Montreal On Rails 3rd Edition Report

Last night’s Montreal on Rails was once again a fun event with three great presentations. Standout Jobs hosted the event in their new offices (quite nice btw).

Gary Haran on Prototype

Gary gave a very interesting tutorial on the basics of using the Prototype javascript framework. I learned quite a few things. Prototype’s doc seems to have really improved in the last year and I should probably learn it, instead of living in fear of writing javascript. Someone mentioned that prototype modifies directly some standard classes and can break other libraries. It’s something you should be aware of.

I would like to see a followup to this presentation, with more advanced prototype stuff and a how to properly write a class.

Francois Beausoleil on Piston

Francois is the author of Piston and presented it in a very succinct way. It’s a tool to help you manage your svn:externals (you probably have a few in your plugin directory). I like it: simple tool that solves a very real problem (breaking your deployment because a remote repository is down).

James Golick on make_resourceful and shoulda

James presented two useful plugins. make_resourceful is like dynamic scaffold for restful controllers on crack. It has a whole bunch of callbacks and things to override to easily customize parts of the controller. shoulda provides lots of test helpers, helpers for validation, model association and restful controllers. That last one is a really nice complement to make_resourceful.

Conclusion

Montreal on Rails is a great initiative. It’s great for the presentation, the networking and it’s gonna help the raise the level of expertise of everyone involved. I heard lots of people talking how they started using things they heard about in past presentations. There’s so many plugin out there today (there’s almost too many) that every edition should have a 15 mins presentation where someone presents 2-3 plugins. See you all next time!

Written by jfcouture in: Rails, montreal, social |
Sep
25
2007
1
comments

The M in Rails’ MVC: Domain Driven Design

One of the best books I’ve read about design is Domain Driven Design: Tackling Complexity in the Heart of Software, by Eric Evans. InfoQ has a small ebook called Domain Driven Design Quickly that provides a nice summary of the book. It was a good refresher for me as I read DDD about three years ago.

So What is Domain Driven Design? Read the link to have a good overview. Here are the two most important points:

  • Focus on modeling the domain and domain logic of your application.
  • Build a “Ubiquitous Language” that is used by all the team (from domain experts to analysts to developpers).

The most interesting part of the book for me was the patterns presented as the basic building blocks of a model-driven design: Layered Architecture, Entities, Value Objects, Services, Modules, Aggregates, Factories, Repositories. These are all very simple but fundamental patterns in software development. These are types of objects that are present in all designs. Understanding the difference between a value object and an entity is crucial and can help simplify a design.

The book also discusses the importance of iterative design, the importance of incorporating back what you learned about the domain in the model as you iterate and how to preserve the integrity of the model. There is a good discussion of ways of separating the model as the team gets bigger.

The value of this book for a Rails developer

Ever heard about skinny controller, fat model? This is THE book about building a rich model.

However, it really depends on the type of application you’re building. Most Rails application are mostly concerned about CRUD operations without too much logic behind. You won’t get out much from this book.

But if you’re working on a business app with a lot of business logic, then this is a must-read.

The ebook also has a small interview with the author. He highlights the expressiveness of ruby and mentions that DSLs are probably the next big step in Domain Driven Design.

Written by jfcouture in: Agile, Book, Rails, Ruby, Software Engineering |

Powered by WordPress | Aeros Theme | TheBuckmaker.com WordPress Themes