Thank you for listening to my presentation and joining the pair programming session. I hope everyone enjoyed.
I just shared the slide I used for my presentation on https://speakerdeck.com/naohiro_t/fast-json-api-how-fast-is-it-really
If you have any questions regarding my presentation, pair programming session or Scout, please reach out to me ;)
Thanks to everyone who joined the event! I'd love to hear any feedback you had about it, good or bad. In particular, I'm interested in what people thought of the format. Did having both a presentation and pair programing section work for you? Any other ideas you have to improve future events would also be most welcome.
It was fun!
Some people had problems setting up their environment. Ideally, projects should have the minimum amount of dependencies. For instance, using SQLite instead of Postgres. Also, the Ruby version should not be fixed in the Gemfile, so anyone with a reasonably recent version of Ruby can use the project without having to spend 15 minutes in the `rbenv install`...
Maybe using an online service, such as Cloud 9 would help?
I think the format can work. But maybe this time the task ended up not lending itself too well to pair programming. And you know I am a big fan.
There is the setup issue than Daniel mentioned. Less and lighter dependencies would help, but even better: have the Github repo ready in advance, and ask participants to clone, bundle, and make sure the specs pass before attending the event. This way we can hit the ground running when the pairing starts.
More than that though, I think the original task, "Work to improve the performance of the application", would have been very pair-worthy, and a great showcase of the use of Scout in development (which is awesome! Scout people, you need to publicize this aspect of Scout more!).
Unfortunately, for us, the task ended up being just "Migrate from JBuilder to Fast JSON API", which by itself was a tall order to complete in 1 hour. So we had zero time to look at performance or Scout, which should have been the focus of this session. There was a lot of documentation reading involved. It is usually OK to just look up a thing or two during pair programming. But everyone reading at their own pace and wanting to follow different reading paths, pair-reading quickly stops working. So when there is a lot of research or reading involved (like when discovering a new gem or serialization format), I would break up the pair, work solo in parallel to both build slightly different (and complementary) knowledge, then reconvene later to continue the pairing.
So, I think it the format can work, but the material needs a bit more preparation and focus. Let's try it again!
Great suggestions Daniel and Yves-Eric! I like the idea of minimizing the dependencies and then having the participants clone the repo in advance, as it should work for most people without introducing possible new complexity through a virtualization solution like Docker.
I'll talk with Scout about how we can reuse the sample app they've built for another event, this time just focusing on performance issues that can be solved within Rails itself (e.g. n+1 queries, caching, memory bloat, inefficient algorithms, etc). Would it be a good idea to start the event with a presentation about common Rails performance issues, or should we just let the participants dive in (with perhaps some documentation about common performance issues)?
