Rodrigo Jardim

Information & Communications Technology

Cloud Docker Cloud Computing on the Azure Platform Cloud Computing ruby Kubernetes Cloud & Infrastructure agile Agile Methodologies

Porto Alegre, Rio Grande do Sul, Brazil

Rodrigo Jardim

Lead Developer at Brightwire - I work to help developers to use the best tools for each job so they can solve hard problems, with less bugs and have more free time.

Worked with software development since 1997, and today works to help developers to use the best tools for each job so they can solve hard problems, with less bugs and have more free time.

Works with Ruby since 2008, published a Rails book in 2009.

Works remotely mainly with Rails for a NYC company for the last 5 years.

  sobrecodigo.com (blog)
  brightwire.com (company)
  smarterworks.com (Company Website)

Current sessions

Put Git to work: increase the quality of your Rails project

Too bad Git is underused inside Rails projects… Using Git for Version Control only leaves out many cool benefits, and makes developers work more than necessary. Being a “lazy” developer, I started customizing Git to deploy Rails apps in a similar way to what is done at Heroku. Easy, fast reliable deployments is an achievable dream with this model. This presentation will show how Git hooks can be used to automate tasks, compile assets, start deployments, run tests, validate commits, and more, without taking up developer’s time. The strategies presented were implemented and are in constant use at Brightwire Inc, Hewlett-Packard R&D Labs, GetNet and FindWorks. In those companies, we have removed manual steps, reduced deploy errors, and saved hundreds of hours from developers, that can now focus on improving the software. My dream is that developers everywhere will learn those techniques, and we can all enjoy better projects.


How to free your app from Cloud Lock-in with Docker and Kubernetes

Nowadays it is important to be able to deploy the same codebase to any cloud provider or to many at the same time, and usually this requires specific cloud server configuration for each deploy.

Learning how to configure your app to run on docker, and how to describe the application dependencies and environment using kubernetes is one of the keys to have complete cloud independence.

In this presentation we’ll see some of the problems you can find, how to solve them, what you can’t do while running your app in a container and how to workaround these limitations, and how to deploy the same configuration to multiple cloud providers.

We’ll comment what each provider supports, and the difference between the services.

And we’ll also comment when you should embrace the lock-in and choose your preferred provider.

After this talk you’ll be able to:

- deploy your application to almost any cloud provider
- identify the strong and week points of each according to our easy of deployment metrics
- work around problems of containerized applications
- decide when to embrace cloud lock-in
- sell to your boss the idea of having a cloud independent infrastructure with laid out problems and benefits of this approach.


How cucumber and BDD helped recovering a legacy no tests app into a fully tested working app

Once upon a time, there was a company and I started working there, and what I found was a working system without any tests that we (I) needed to improve and change without breaking anything. And everybody was afraid of changing anything because it could break a completely different thing. And it was decided to leverage my BDD experience to start documenting the system inner works with user stories that could be validates with the users Then cucumber came for the rescue and the user stories became automated tests And to keep using the same tool, we have user stories of how small (unit test size) parts of the system works and how backend systems works also This way non technical users can validate what is being tested and what is being developed in the company But most important, non technical users had a key role in adding tests to the legacy system helping to understand when a new test was breaking if the test was the problem or if that was a bug in the legacy system because they could read the tests. From there we just needed to configure a continuous integration system and be confident that the new developments would not break anything important.

And this is the experience I want to present, with a step by step of what we did and how the non technical users are involved in the application testing.


Data Science in Ruby? Is it possible? Is it Fast? Should we use it?

In this talk we'll review the state of the tools for data science in Ruby!

Python is the "crown jewel" of the data science languages today, but many of us work mostly with Ruby for the business applications, and it is important to use the best tool for each job.

So we'll analyse gems and groups of gems available in Ruby for Data Science

* their performance
* features available
* is ruby is being used for data science at all?
* Should we use it? and when?
* what are the alternatives?

And after this talk you'll have enough information to choose the toolset to use for your next data science project, or event to "add some data science" to your existing project.


Using docker-compose to replicate the application production environment for your tests

One of the worst things a developer can say to anyone is “it works on my machine”, everyone feels bad about this.

And most of the times, this happens because the developer tested the application with the “services” installed in the development machine, and those services had manual configurations, different versions, different addresses, lots of small things that can make the application fail in production.

Using docker-container can help solve this creating one isolated environment where the version of all softwares can be the exact same as production, with the same addresses, environment variables, and test the application as close as possible to the real environment.

After this talk, everyone will learn:

* how to package a simple application with docker
* how to configure the “production” environment for the automated tests
* how to speed up the test execution
* how to run tests in parallel without changing any of the test code
* how to use the same configuration to deploy the complete environment to SWARM if that is your deployment choice