In 2012 Flipkart's supply chain system was re-built as a service oriented architecture with Ruby at its core.
This talk will cover our experiences designing, building and scaling a mission-critical Ruby-based system where data integrity and performance is vital.
Dealing with cross-service transaction integrity
JRuby - the good, bad & ugly
Coordinating gem upgrades across multiple services
Performance tuning to get predictable response times - taming queries, external calls, GC, locks
Monitoring & profiling production systems
Ruby app servers: Trinidad vs Passenger vs Unicorn
Challenges in ramping up teams on Ruby
New runtimes, technologies and languages keep popping up, and there is a need for libraries that work across language, and across runtimes.
This talk will contrast some of the ways to build a native (usually C/C++) extension, and integrate them with your application. We'll look at how to build a native extension, while staying within the paradigm of the language.
We will be covering (in some detail): * Native C extensions using MRI/Rbx APIs (and contrasting it with the python API possibly) * SWIG to automatically generate wrapper code * FFI to build libraries that work across multiple implementations of ruby
The Rails Girls Summer of Code found me as a Ruby enthusiast. A little syntactical knowledge of Ruby took me to the glamour of Rails Girls SoC. Me and my partner, Pallavi Shastry, from Bengaluru, chose to work for diaspora, a privacy-aware decentralized, social network. Before contributing to diaspora, we tried our hands at Rails Girls Rails App Generator. The generator adds comments targeted at Rails Girls students to migrations, routes, controllers, models and views. It omits more advanced things like the respond_to blocks and jason stuff in controllers etc. This project also includes a Jekyll-based website on Github Pages which explains things briefly and gives pointers to guides or other resources. After completing the Rails Girls App Generator project, we dived into diaspora* which did sound more like learning to swim in a big ocean instead of a pool! The diaspora* issues that were assigned to us by our mentor were: 1. Blocking people from the profile page 2. Adopt a pull request 3. Full content in email notification for public posts 4. No content in email notification for limited posts We got 2 pull requests merged into diaspora*. Learnt about the testing workflow, rails internationalization, ActionMailers and a lot more. The open source journey with Rails Girls Summer of Code helped me build my confidence and made me realize that I too have an amazing chance to change the world and make things better and happen! The talk will surely benefit the students who wish to apply for RGSOC next time. The attendees of the conference might get inspired to become coaches for the future Rails Girls. The attendees could also help girls to understand Ruby on Rails technology and help them contribute to open source. Hopefully, there will be more RGSOC participants from India, in future.
Discussion on Programming languages and evolution of Ruby. This will be a unique opportunity to learn how good programmers learn new programming languages and as a Rubyist what we should be doing next to improve ourselves.
Will showcase real-world project code, highlighting custom-written Ruby DSLs that contribute to project success by improving team productivity. Ranging from simple authentication rules to complex social networking capabilities, DSLs can help tackle cross-cutting requirements and domain-specific abstractions. Benefits include faster story development, easier bug fixes, and deeper technical exposure for team members. Will also talk about some gotchas.
Will explain multiple techniques for creating DSLs within a Ruby project, including simple OO code without any metaprogramming, to medium-complexity use of mixins, to advanced usage of metaprogramming.
I love Ruby! But as in any relationship, to love means that you have to accept the "dark side" too! Ruby is human and has a lot of gotchas, tricks, wierdness and sometimes scary features that I plan to highlight. This talk aims to provide the "Ah-ha!" moments when working in Ruby.
This talk is for beginners and experts alike - in fact, I tag slides to mark their level and beginners can choose to tune out of the heavy stuff! My talk shall cover the dark side of the following features of Ruby (in no particular order)
Module inheritance (it exists!)
Cherry picking module methods
procs, blocks and my friend stubby.
==, ===, eql? and equal?
As with most of my talks, humor play an important role and I shall aim to get everyone high on Ruby with a deep dive!
Would you like to do some OCR using Ruby and learn some machine-learning along the way?
In this talk, first up, we'll have a quick demo where an attendee writes down a digit on a sticky note and a Ruby program tries to to recognize it. Then we'll pick it apart, covering:
the basics of machine-learning (and different applications)
brief look into the Math behind supervised learning (classification)
(mostly) hand-rolled code applying this Math
libraries/tools available to Rubyists (and choice of Ruby platforms) including weka, mahout, libsvm, and the Ruby Matrix class :)
ways to dive deeper into ML
Increasingly developers are being pushed to understand the operations world of web application deployments as continuous delivery gains importance in the "new normal" world of agile developer workflows. Configuration management tools like Puppet and Chef are gaining popularity for precisely the same reason, as they allow developers to deal with "infrastructure as code". However, there is also a growing understanding that servers are better off being treated as immutable, to avoid the various complications that arise from constantly evolving/changing configurations. Docker is a tool that allows us to deploy various parts of a server into separate containers and let us save a container state so this can either be published or improved upon. This talk will allow us to understand all these concepts in order to achieve immutable servers and zero-downtime deployments.
You might know of every single code quality & metrics tool in the Ruby ecosystem and what they give you, but do you know:
Which metrics do you currently need?
Do you really need them?
How do you make your team members own them?
Wait, there was a metaphor in the title
While a pharmacist knows about pretty much every medicine out there and what it cures, its really a doctor who figures out what is required given the symptoms of a patient.
Just like the vitals recorded for healthy adults, infants, pregnant women or an accident patient in an ICU changes, your code base needs different metrics in different contexts to help you uncover problems.
Talk take aways
Through a lot of examples, the talk helps:
Identify the current state of your code base
Understand different metrics and what do they tell you about your code base
Drive your team towards continuously fixing problems uncovered by these metrics
An intermediate level talk to understand the inner workings of Ruby Memory Model. Topics covered:
What is a Memory Model and why should I care
Evolution of Ruby Memory Model
What every developer should know about the memory management in Ruby
Having worked on several tech stacks (Java, CLR), where it is critical to understand the underlying Memory Model, I was curious to understand the details about Ruby Memory Management. I will be presenting my learning and experience about improving application performance and keeping a low memory footprint.