With this article I want to start a series of ‘code reading’ posts. I love to read source code, especialy good one. And I think it is important for you as a programmer to read others code. You can pick up some tricks or find a better way to structure code or even find new constructions you weren’t aware of. Also checkout code reading series: ARailsDemo, Code Safari
Retrospectiva as it says on the site “open-source project management tool, intended to assist the collaborative aspect of work carried out by agile software development teams” by Dimitrij Denissenko. It came under my radar a long time ago and just recently I had opportunity to read across project.
I like a structure of the code and especially extension bindings. It’s very rails 2.x-ish and very clean. Everything has it’s own place.
As a good rails app, Retrospectiva have it’s core functionality under /lib directory. The interesting thing in environment.rb is how it get activated:
Core doesn’t get loaded if rails environment is called via rake task. Appears that there is 2 global variables that allow you do define whether you are in rake or rails environment in your code $gems_rake_task, $rails_rake_task!
How are yours db/seeds.rb file looks like? Usually I used to put ordinary Rails code there.
Althouth it can and need to be represented as a module! Remember Good coders code, great reuse. Retrospectiva does follow this rule in db/seeds.rb:
It is great to have CHANGELOG file in your project, but it’s usually a pain to see what changed recently from the last version. Why don’t let ruby and git do this job for you? script/changelog.rb contain a ruby script that does the trick. You just need to write a good commit messages.
Another great script for app installation script/remove/retrospectiva_installer.rb
For integration with git, Retrospectiva using self written module that you could easily pick up at vendor/plugins/tiny-git.
I wan’t aware of this feature of RSpec before. With share_as and it_should_behave_like you can describe general behaviour of an object and then mix it to your current spec. It’s like module/include/extend for specs.
Shared example group(RSpec docs)
Specifying mixins with shared example groups in RSpec-2
Keeps either the entire current flash or a specific flash entry available for the next action. ApiDock
A trick for 99% of your projects
Well thats all for today.
Comments