RubyC is a European conference devoted to Ruby, Rails and other related technologies. Every year we invite hundreds of Ruby enthusiasts and developers from various programming groups to exchange knowledge, discuss latest news, learn from one another, and generally have a wonderful time together. We gather on the first summer weekend in Kyiv, Ukraine.
Join us this year!
Iryna's coding career began in 9th grade when she participated in her first programming competition - back when Turbo Pascal was still in style. Since then, she has been programming professionally for 10 years, half of that time in Java, and the later half - in Ruby. She has a soft spot for efficient data structures and elegant algorithms. Fun fact: Iryna once won $10,000 in a competition by memorizing a shuffled deck of 52 cards in under 1 minute.
On RubyC, Iryna will talk about the complexity of algorithms - how it's measured, why it matters, and what are some common misconceptions.
JRuby guy. Java Champion and Ruby Hero. Linguistics (natural and computer), music (listening and playing), games (video, board, classical, archaic), beer (all).
In the past ten years, JRuby has come a long way. We created the first JIT for Ruby code and helped the JVM add features for dynamic languages. We've built an ecosystem of libraries that take advantage of JRuby's integration with JVM languages. And we've seen thousands of large-scale JRuby deployments running sites you've probably used. In this talk, we'll see where JRuby is today and how you can use it to build faster, most scalable applications.
Duana Stanley is a software engineer with 10+ years experience in building web applications and APIs in Ruby, Scala and Node.js. She is a big fan of lean/agile, engineering principles, clean code and beginner-friendly environments. Duana is a proud coach and mentor of Rails Girls Summer of Code since 2013.
Making decisions by yourself is hard, let alone with a team. As developers, making good technical decisions in teams is key to our jobs yet we don't explicitly learn how to do that. As someone who has found technical argumentation difficult, I have been thinking about this topic for years: argumentation in teams should not be about winning and losing. I will introduce a framework teams can use to evaluate options and find consensus when making big technical decisions, with an example.
Founder of Skillgrid virtual agency, IT events enthusiast, ruby developer, teacher, Lean Poker facilitator, GitLab developer advocate.
I want to share some techniques I recently learned. They can make your life with Rails much much smoother. In particular: State machine FTW No more Devise please Classic TDD is evil. Cover controllers. You'll be fine. AR-based forms over Form Objects. Minitest, not Rspec Fixtures, not factories. Null objects FTW Stubs over mocks You don't need interactors. It all sounds very counter-intuitive, I know. The more interesting it will be to listen to this talk ;)
Arkency CEO , former Ruby and Rails teacher at the University of Wrocław, “Fearless Refactoring - Rails Controllers” author, Ruby books publisher, wroc_love.rb conference organizer.
Over the years with Ruby and Rails, I've been observing the different styles of writing code on bigger Ruby (mostly Rails) projects. Based on the code I wrote myself and the code we write and see at Arkency I have identified certain phases/styles:
1. Early Rails Way
2. The Rails Way
3. The Next Way (service objects)
5. DDD + Event-driven
6. DDD + Events + CQRS
7. DDD + CQRS + Event Sourcing
8. Functional DDD
I'd like to present the code for each style and discuss benefits and drawbacks. I'm going to summarize with my predictions of the phases which will happen in the next years in our ever growing Ruby community. Ruby is the future!
Software Engineer at GoCardless, a fintech startup based in London. Founder of BA Redemption Finder. Author of Twilio Best Practices. Lover of coffee.
When you’re building an API, things start off simple. But before you know it, there’s lots of logic you want to build abstractions around and reuse - for example authentication, input validation and pagination. This usually means having a long list of callbacks living in your `ApplicationController` using ActionController’s `before_action` magic. This leads to: tangled data dependencies (where callbacks depend on data retrieved by other callbacks and stored in instance variables - the authenticated user, for example) hidden behaviour (all those `except`s and `only`s on your `before_action`s are hard to reason about and separated from your code, usually living in `ApplicationController`!) difficulties with testing (unit testing methods inside a controller is hard!) The middleware pattern can help us to bring sanity to our APIs and make them miles more maintainable. This pattern, used by Elixir’s Phoenix, Node’s Express and even Ruby’s Rack helps us to untangle our data dependencies, make our code much more explicit and easily unit test complex behaviour. We can apply this pattern to our Rails application to move faster and write more maintainable code. In this talk, you’ll learn how to move from convoluted controllers to robust, maintainable and well-tested chains of middleware built using a open-source gem, Coach (https://github.com/gocardless/coach).
Ukrainian programmer and poet with more than fifteen years of programming experience and ten years of Ruby programming. Working at Verbit.ai, mentoring students (including Google Summer of Code-2016-2018, as a mentor for SciRuby organization), developing open source (Ruby Association Grant 2015).
This day, approaches to APIs and communications with remote services are changing rapidly. GraphQL seems to come as a fancier and universal alternative for long-praised REST, while some are still using SOAP, and others are experimenting with binary and strongly typed protocols. In this talk, we'll go through query languages and API standards used by world's most famous open services, like Wikipedia and OpenStreetMap, and see the lessons those large and established projects teach us about their design choices.
Whenever Open-Source meets deep and profound debates about architecting software, and there's free beers involved, Nick must be just around the corner. Say Hi to him, he loves people.
Software - so fragile a thing! Wouldn’t it be great if it’d stop breaking? Changing the approach to software might bring the difference. This talk hopefully gives some answers and sparks by introducing functional programming, new structures, and finally focusing on modelling business processes before hacking away.
CEO at RubyGarage
We will discuss how to solve the following problems and not to fail with your rapidly growing web application: - How to implement features fast. - How to conduct tests fast. - How to scale development. - How to deploy fast. - How to scale app architecture. - How to add more technology stacks. P.S.: Code examples in Ruby
A traveling coach and a software mentor. Author of the "Metaprogramming Ruby" for the Pragmatic Programmers.
It happens to all of us: that weird moment when you realize that your phone or computer just did something impossible. How the heck could an algorithm caption your pictures or understand your movie reviews? Let me show you how, by giving you the technical foundations of Machine Learning.
Authentication in SPA. The old problems in a new shell. Things you should consider when implementing auth.
Ruby is the establishment now. It’s no longer the cool new kid on the block. That’s a good thing. Many Rubyists branch out and take a look at other languages - be it part time or full time. What are similarities between those languages and ruby? Why do Rubyists choose to explore them? What are differences? How does Ruby influence these languages?
This talk will look at these languages, briefly comparing their characteristics with ruby to get a better view of the programming language landscape. Maybe it will even help you find your new favorite side project language?
Software Engineer - passionate about building great products. 9 years with Ruby, 2.5 years with Android. Built loyalty apps used by almost 20% of people in Scandinavia. Interested in UX, psychology, productivity. Loves to drive car on scenic roads.
Battle-tested strategies to help you find balance between building things right and building the right thing. - Does Ruby always mean Rails? - Code in product context - what brings value? - Maintainability vs moving forward - Short-term experiments vs long-term vision - Addressing tech debt
Sergiy is a young programmer from Ukraine with about 10 years of experience. While his primary language is Ruby, he stays open to something new. He had experience with many languages and platforms, such as JS, Elixir, C#, Haskell, Java etc. That wide experience helps him to rationale more about approaches rather languages.
You know all that rules for the good code. TDD, SOLID, DDD, The Clean Architecture, etc. A side-effect-free function is better. Decoupling is better. But, along with pros they come with cons. No wonder there are over-engineering, KISS, YAGNI words. The author was trying to build an application in a team applying known best practices for over one and half years, and… eventually failed. On his own example, he will tell you about practical sides of approaches, pros and cons, common pitfalls and made conclusions.
Our special place, a majestic three-star Premier Hotel RUS is advantageously located right in the centre of Kyiv. The Hotel clambered upon a hill in the very heart of the business and tourist districts of the capital. The famous artery street - Khreshchatyk - is just few steps away. Palats Sportu metro station is located near-by, and the Hotel offers the views of the Olympic Stadium - the main sports arena in Kyiv.
4 Hospitalna str., Kyiv Show on Google Maps
If you have any questions about RubyC, please contact our PR manager Nadia Beregova +380 97 852 86 71, firstname.lastname@example.org