Posts by author:
Note: These instructions are for Mac OS 10.4. I don’t know if they’ll work with Leopard.
Installing git is easy, just compile from the source. Git svn is harder to install because it is a bunch of perl scripts that needs the svn perl bindings (it comes with git btw). Here are the steps I recommend to make sure everything works.
First, we’ll install git using Macports. This will take care of installing all the required perl libraries:
$ sudo port install git-core +svn
However, macports installs a slightly old version of git. So I suggest downloading the latest and compiling from source.
$ sudo make install # Note: watch out for the way your PATH is setup # to make sure you are using this new git version # instead of the macports version $ git --version
Now if you try to run git svn, you might get an error about it not finding SVN/Core.pm. That means your version of subversion does not include the perl bindings (which is the standard if you installed svn with macports). I suggest you install subversion from this package that includes the language bindings. Now you need to add this to your ~/.profile:
export PERL5LIB=/usr/local/lib/svn-perl
Everything should work. Now it’s time to import your svn repositories and enjoy git.
Popularity: 29% [?]
I’ve been using git for three months now and it has had zero impact on my team. They weren’t even aware I was using it for the first few weeks. That means, you can start using it now, for your personal development, without having to convince anybody.
Git comes with a svn wrapper. You can import your svn repository to a local git repository. You then get all the advantages of git: easy branching/merging, offline operation(very useful if you work with a laptop), etc.
$ git svn clone http://path/to/svn -T trunk -t tags -b branches
This command will import all the revisions from svn and create branches in your git repository (one for trunk, and one for all your branches). You will be on a branch master (linked to trunk) and can start working. You commit normally to your repository.
When you are ready to send your changes back to svn:
$ git svn rebase # (equivalent to svn update) $ git svn dcommit # (equivalent to svn commit)
Rebase works by reverting your changes, getting the latest revisions from svn, and then reapplying your changes. You resolve any conflicts (if there any). The last command then pushes your changes to svn for your team to enjoy.
Those are the three commands you need to know to use git with svn.
Caveats
Svn:externals are not supported. I suggest you use piston to handle them.
Check out the git svn docs for a few more things to watch out for.
Conclusion
Now that your team has seen you using git successfully for weeks, it will be much easier to get them to switch!
Popularity: 20% [?]
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:
- Linus Torvalds presentation on git at Google: You NEED to listen to this talk to change the way you look at source control and understand why git rocks so much. Linus is great and funny in this talk. Warning: he will call you stupid.
- Peepcode screencast on git: Peepcode rules and this screencast will show you how to use git. It costs 9$, but if you were at the last Montreal on Rails, you should have a special code to get one screencast for free.
- Using Git to Manage and Deploy your Rails Apps: Here’s another screencast that will walk you through setting up a new rails project using git, setting up a git server and then deploying with capistrano (capistrano 2.1 supports git for deployment).
- Setting up a new Rails app with Git and Setting up a new remote git repository: two excellent and detailed walkthrough.
- Why distributed version control: Very good explanation of the advantages of git.
- Using Git for core development and Using GIT for Rails Development: Two other very good tutorials.
- Git tutorial and git svn tutorial, two tutorials from the official site.
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.
Popularity: 28% [?]
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”).
Popularity: 11% [?]
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
endSome 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:
- Jay Fields Thoughts: RailsConf Europe 07: Presenter Links
- Simple Presenters
- Model View Presenter Pattern
- Jay Fields Thoughts: Rails: Rise, Fall, and Potential Rebirth of the Presenter Pattern
- Giles Bowkett: My Version Of Rails Presenters
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.
Popularity: 13% [?]
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.
Popularity: 31% [?]
