wish I could get hold of a chain of named_scopes without performing any query (which means it can’t be dynamically composed) #activerecord

My team has currently been performing some refactorings on our Rails app and one of our goals is to move complex find queries into more composable/meaningful/maintainable named scopes. Contrary to my expectations, when you call a named scope, Active Record performs a find(:all) query implicitly as you finish your statement:

In our particular case, we didn’t even need the proxy object, but just a hash representation of the composed query parameters. We’re using ActiveRecord::Extensions (ar-extensions) to perform some UNION queries to aggregate results, and it expects a list of hashes that represent each query. It would be nice if I could grab the hash from my named scopes without performing the query…

The documentation points to a proxy_options method that you can use to test your named scope, but it didn’t solve my problem, since it only returns the hash for the last scope in your chain:

This is not a perfect solution, but saved me the trouble of performing the merge myself. I hope the Rails 3 solution addresses these issues and that this post saves me some time digging through ActiveRecord source code if I need this before then :)

Since last December, my friend Ivan Sanchez invited me to help him organize a Coding Dojo in London, at Skills Matter. We’ve only had a few sessions so far, but it’s been great fun going to regular Dojo sessions again, since I left Brazil 1 year ago. In the last session, I did a prepared Kata in Ruby, using RSpec and Ivan did a great job of summarizing some of the lessons learned in his blog.

Our next session will be next Thursday, February 12th and you have to subscribe on the Skills Matter website if you want to attend. To join our discussions of which problems to tackle, which languages to use, join our mailing list. We’re also publishing the source code from the sessions on Github, and some of the sessions are being published as podcasts/videos on the Skills Matter website. I hope to see some of you on Thursday!

The new version of Synthesis 0.2.1 was just released and the great news is that my experimental work with visualizations was integrated into the master branch! Just sudo gem update synthesis to grab the latest version.

Why Visualizations?

“…reducing the volume and increasing the value of test code by connecting the dots.”

As George pointed out in his first post about Synthesis, it helps you to connect the dots of your tests, to increase your confidence in the system. I like to think of it as a mock coverage tool. When you use a mock in your test, you’re explicitly stating what interaction you expect to happen. How do you really know that the actual object will behave as you expect? You probably need a unit test around it to guarantee it does what it should. Synthesis helps you connect those dots, breaking your build when a mocked expectation is not met in the “real world”.

By using it in a real project, I noticed that the textual output was getting quite verbose. While coding, I was usually only interested in the failure expectations, but when I stopped to look at the whole output, I noticed there were a lot of interesting information hidden in there. If only I could have a better representation of that information…. that’s exactly what software visualization is all about! I had to dig into Synthesis internals to understand how to hook a different report formatter, but the end result ended up being quite good:

Generating Visualizations

To generate such a visualization, first make sure you have sexp_processor installed (sudo gem install sexp_processor) you need to configure your Synthesis rake task to use the dot formatter:

This will create a synthesis.dot file that can be used to generate a Graphviz image. You can download and install Graphviz for your prefered platform (there’s even a Mac OS X version), but all you need is the command line dot tool to generate your visualization. Just execute:

dot -Tpng-o synthesis.png synthesis.dot

This will create a synthesis.png image file that will show your tested expectations in green, and untested expectations in red. You can generate other output files by changing the -T option (try ps, pdf for a higher quality). There are still a lot of things to improve in the formatter and any feedback is welcome, but it proved to show some interesting information in my last project, as you can depict in the following picture (notice that the app is mainly composed of 2 subsystems that don’t share dependencies):

Tip: Running Synthesis with Rails

Recently, when trying to use Synthesis in a Rails project, I had some problems that took me a while to figure out. As always, the solution was quite small, so I thought it would be nice to share it with everyone. To run Synthesis on a Rails project, make sure you add the following lines to your Synthesis rake task:

Synthesis::Task.newdo|t| RAILS_ENV = "test"Rake::Task['environment'].invoke# This may make your build slower. Use only if needed t.pattern = 'test/**/*_test.rb'end

Give Synthesis a try in your project and let us know how it goes. You might be disappointed in the beginning about how many expectations you’re not testing, but even if not all of them really require a test, it is still a very valuable information to have. Let me know if you have any issues with the dot formatter as well, as I’m sure there are a lot of kinks to be sorted out. Feedback is always welcome!

I’m back from a 2 week “conference season” in Brazil and Argentina, but before I share my experiences on those conferences, I want to talk about my first session at the São Paulo Coding Dojo since I left in February. It was very unusual and pleasant for different reasons: first of all, George had arrived in Brazil for Rails Summit Latin America and I took him to the session; second, it was held at one of the participant’s house, instead of the usual venue at the University of São Paulo (which made it possible to add a taste of fresh baked pizzas to the retrospective); third, we decided to try out a different session format called, in lack of a better name, ÜberDojo which I will try to describe in this post. Hugo has already explained how they came up with the new format in his blog.

In an ÜberDojo, the setup is different than a regular session: there are more than one laptop and no projector. The number of laptops may vary depending on the number of participants, but we were 14 and decided to have 4 pairs, so 4 laptops were available. We laid out the laptops in 2 tables and chose 2 different problems to be solved in 2 different languages. We would go with Python and Ruby, but George argued in favour of having different programming paradigms to enrich the discussions, so we ended up coding in Ruby and Haskell. The problems we chose were already familiar to most of the participants since the goal of the session was to try out the new format rather than solving a difficult problem or learning a new language: Minesweeper and Bank OCR were the chosen problems.

The dynamics of the session are similar to a Randori session, but with multiple pairs coding at the same time. We used a fixed timebox of 7 minutes to switch the pairs (when the round is over, the driver leaves the pair, the observer becomes pilot, and a new observer joins from the audience). The big difference in this format is that it’s impossible for everyone to follow the same train of thought, and there’s always more people than seats available so there’s a lot more chatting happening. When a new member joins the pair, it’s very likely that he will have almost no previous experience with the code being developed (similar to a real-life environment?), so everyone can exercise their ability to read and write readable code. In the original idea, people who were not coding were not supposed to follow what the other pairs were doing, but we ended up helping other pairs with less knowledge on the languages and/or environment. I have to admit I sometimes tried to stick around one of the pair stations because the approach to the solution and the discussions were getting interesting :-)

At the end we held our usual retrospective with food (a lot of pizza) and everyone seemed to have enjoyed the session. I particularly felt the energy and the innovation happening and was very excited with the results. We coded for more than 1:30 hours and it was very hard for me to leave the code unfinished. Although it was a lot of fun, I think for this kind of session to be successful, the participants need to be familiar with a Dojo session and its dynamics (TDD and Pair Programming in particular). Hugo was also a very good moderator, using a pairing matrix to keep track of who was pairing with who, to keep at least one experienced member on each pair, and to put different people in different pairs at each round. The code from that session is available at GitHub.

I see some benefits to trying out this type of session. Solving the same problems in different languages (and paradigms) made it possible to have a rich discussion at the end. For example: when solving the Bank OCR problem in Haskell, pattern matching made it easy to make progress on the first steps, while the Ruby version was getting stuck with a lot of nested if/else statements. Another benefit of this type of session is that you can cope with programmers in different levels of experience. In a traditional Dojo session, you always go as fast as your least experienced participant. In this session, you have different streams of development happening at the same time, so a faster pair can make more progress on their turn. Finally, I think this environment is much more similar to what you might encounter in “real-life”: you develop code for others to read and you have to understand what others were doing while you were absent.

I hope you try out this format in your Dojo and share your experiences. What other types of session are you trying out in your local Dojos? Would you have a better name for this new session format? Leave your comments!

The main reason I went to the conference was to present my experience report on Wednesday about running a Coding Dojo in São Paulo since last year with my friends: Hugo and Mariana. I just made the slides available for download, as well as the published paper. Feel free to comment and send questions and comments about our unanswered questions.

The overall feedback we got from the 30 minutes presentation was very good and we decided to do a Live Dojo at the Open Jam in the next available slot. Besides me, Hugo, and Mariana, Emmanuel and Arnaud from the Paris Dojo showed up, Ivan Sanchez from the Floripa Dojo as well, and other people joined us during the session.

We did a Randori session solving the Blocks Problem in Ruby/RSpec, switching pairs every 7 minutes. Although we didn’t finish the problem, it generated some interesting discussions about exposing the internal state vs. a representation of the state to the tests, and how valuable it is to introduce a data structure that you don’t need now but will soon need.

The problem generated some interest and, on the following day, Arnaud had scheduled a slot on the Opem Jam, and we decided to tackle the problem again, but this time in Haskell. Dan and Liz were also there and it was really cool to see the same problem from a different perspective. We discussed how some features of a functional language forces you to think in a different way (I still don’t quite understand Monads, by the way) :-)

Another interesting learning point was: In our paper, we discussed a whole topic about issues with people pairing in different environments (operating system, keyboard layout, shortcut keys, IDEs, …) at every meeting. At the Open Jam, Dan proposed that we used a local Mercurial repository to share the progress on development (pushing at each TDD step for the next pair to continue working on the problem). This allowed him to work on his Mac with a Dvorak layout, while we were using Emacs on a Linux laptop. The other benefit of this approach is that it allows people to experience how Continuous Integration works in practice, committing as often as possible, whenever it makes sense to do so. Good stuff!