Codegram Blog

This week's talks: "BDD best practices and antipatterns" and "Brew your own coffee...script"

2012-03-12T10:43:34Z

Check out this week's internal talk slides at Codegram:

BDD best practices and antipatterns: Oriol Gual goes through some best practices that every BDD adopter should consider, and what anti-patterns should be avoided.
Brew your own coffee...script: Txus shows us how to build a simple transcompiler (like CoffeeScript) in Ruby.

This week's talks: "Encoding messages in a noiseless channel" and "HTTP authentication methods"

2012-02-27T10:57:55Z

Check out this week's internal talk slides at Codegram:

Encoding messages in a noiseless channel: Marc Riera explained to us how to construct an optimal, unique message encoding using the Huffman algorithm.
HTTP authentication methods: Josep Jaume walked us among several http authentication methods, explaining some of their vulnerabilities.

Linting the hell out of your Ruby classes with Pelusa

2012-02-14T16:12:55Z

As you might know, yesterday morning we had Monday talks at the office! Oriol talked about Object Oriented Nirvana, inspired by an old post about how to improve Object Oriented skills by using certain constraints while you're coding.

Then I got immediately interested on how to automate this, and knowing how easy is dealing with the Rubinius' Abstract Syntax Tree, I decided to give it a try and develop a tool that statically analyzes Ruby code to gain insights from it.

But what does it mean "statical analysis"? It means that this tool won't run any of your code at all, it just inspects it like you would as a developer, by looking at it. Since code is nothing more than nodes inside nodes, you can easily identify certain patterns that you consider wrong or desirable (for example, having else clauses in ifs, nesting blocks, or just using the word "foo" in actual programs). By traversing the AST, you can analyze parts of the code that don't fit your particular style or code quality requirements (actually with a little more work you could programmatically change those parts, i.e. automatic refactoring). I find this really cool!

The tool I've been working for the last couple of days is something along these lines (excluding, for now, the automatic refactoring part).

Introducing Pelusa - a Ruby Lint to improve your OO skills

Pelusa (which is Spanish for the word lint) is a static analysis tool and framework to inspect your code style and notify you about possible red flags or missing best practices. Above all pelusa doesn't run your code -- it just analyzes it syntactically to gain superficial insights about it, and raise red flags when needed.

Although Pelusa needs Rubinius to run, due to how easy it is to work with a Ruby AST with it, it doesn't mean that you have to run your application or Ruby code on Rubinius. Since it's a static analysis tool, pelusa doesn't care what your code runs on, it just looks at it and tells you stuff.

If you're curious, it looks like this (running on it's own code base, oh inception):

Find the default lint checks too Taliban for your tastes?

These are just guides, so you're free to fork the project and add/remove lints as you like. The fact that I've started with those doesn't mean that any of us thinks these are the true and only practices of Object Orientation, it's just a set of constraints that are fun to follow to achieve a mindset shift in the long run, or just to explore new styles.

One of the next features will be easy composability of lints, so you can remove those you don't like and add custom ones that fit your team's style or quality standards :)

Pelusa as a static analysis framework

With Pelusa, writing your own lints becomes very easy. Check out some of the default lints under the lib/pelusa/lint/ directory in the Github repo. Rolling your own style has never been easier!

Conclusion

My point by doing this was mainly exploring static analysis with Ruby, since I've never done it before, but also proving a point: good development tools are not only for statically typed languages! With a little imagination we can leverage our skills to make life better, or at least more interesting, for Ruby developers as well.

What do you think? Would you use this kind of tooling in your everyday job?

This week's talks: "Creating basic Chrome extensions" and "Object Oriented Nirvana"

2012-02-13T10:46:44Z

Check out this week's internal talk slides at Codegram:

Basic Chrome Extensions: Marc Divins introduced us to the creation of some extensions. Warning: Intense trolling ahead!
Object Oriented Nirvana: Oriol Gual refactored some of our Spinach codebase by applying some Object Orientation's best practices taken from The ThoughtWorks Anthology

Introducing Monday Talks at Codegram

2012-02-06T12:16:29Z

We've been noticing an increasing knowledge specialization ever since we doubled our team earlier last year, going from the 3 cofounders to a team of 6 people. This is a natural process, but sharing knowledge has become a bit trickier. As a company we sell knowledge, thus it's our most valuable asset — and sharing it among the team (and outside it) is crucial to increase our value.

Although we do have a set of common places to share knowledge (from an internal Google Groups site to various link-sharing tools), achieving the same level of specialization in all the fields is a hard task.

Given this, we had an idea: why don't we prepare weekly talks about software and computer science in general, and expose them to our peers every Monday? So we did this: Monday Talks is about sharing knowledge with your peers, improving your public speaking skills, and most importantly — having fun while doing it!

We've set up a site where we publicly upload the slides for our talks.

Also, if you want us to give an extended version of any of this talks at your company or university, with more examples, bibliography and Q&A, contact us :)

This week's talks

Josep Jaume: Heroku Buildpacks: Heroku for everything
Txus: Building a VM in Ruby