February Meetup 2014hosted by Tobias Pfeiffer by Votum (www.votum.de), 06.02.2014 at 19:30
Let's meet to hear about Ruby and related technologies!
There are several approaches to managing external frontend libraries with the Rails asset pipeline. The talk would first go through the most popular (vendoring, _-rails gems, bower) and show a relatively new one: Rails Assets.
Rails Assets automatically converts bower packages into rubygems, and serves them in a bundler compatible way.
This can also be shortened into a lightning talk.
How do you find your first open source project and what you might want to know before starting to work on issues. I recently started contributing to open source projects and want to encourage others to do so as well.
During the development of our internal hadoop reporting engine we encounter with the need of an easy to deal with scheduler, so we ask for help to our beloved Ruby friends. In this talk we aim to show, and discuss, how easy is to create a simple hadoop scheduler thanks to JRuby, Sinatra, Neo4j and some other gems.
Time (aprox): 20 minutes -/+ 5 minutes for questions.
- Written and directed by: Pere Urbon-Bayes and Achim Friedland.
- Producers: Belectric IT Solution Gmbh.
- Ruby as The programing language.
- JRuby as The virtual machine.
- Sinatra as The web framework.
- Hadoop as The data processing framework.
- PIG as The scripting language.
- Design effects:
- Apache PDFBox as The PDF craftsman.
- JFreeChart as The Charting director. ---
Theoretically, testing is pretty easy. Prepare some data, perform some operations on it, check the result. This description often doesn't paint the full picture. For instance, how do you test:
- Deploy scripts, like a bunch of tasks you've built on top of capistrano?
- Networking code: sockets, asynchronous streams?
- Inter-process communication?
I don't have easy testing solutions for the above. There are options, but I think we can agree there's a category of programming problems that can be tricky to test. And I think it's common that, when faced with such problems, we're strongly inclined to avoid testing altogether.
So is it okay to skip tests in these cases? Or should we put effort into testing every little thing, even if it takes weeks to set up and ends up breaking randomly?
I'm going to give my thoughts on the matter, taking examples from spork, and from some of my own projects, like a Vimscript test runner and a tool that runs a rails command with music in the background. I'll also demonstrate how Vim plugins can be tested with rspec. These projects need more work than just setting up data and performing method calls, but once you've built a good toolkit, the specs flow quite nicely. Whether you should invest the time and energy is a question I'll try to address.