Videos provided by wroc_love.rb via their YouTube Channel
Do you work on projects managed in a way that is easiest for managers or customers? Focused around their priorities without taking developers needs into account? Can we strive to achieve work and project environment that would be friendly for programmers so that they enjoy working in our company and don't think about leaving it?
The first part of this talk is intended to demonstrate techniques for managing IT projects in a developer friendly way. So that developers can avoid feeling of burden and disconnection from the rest of the team. So that they can improve their skills and grow up in new areas, without stagnating in doing the same repetitious tasks and working on fenced areas of code. And so that they can be always sure that they are working on the most important task right now and avoid confusion.
It will be based on guidelines that we established at Arkency throughout years of working remotely. You can apply them to your project slowly and every one of them will help you improve some of the previously mentioned aspects. Together they make tremendous difference and let people enjoy a lot of benefits that a programming job can offer. They create a programmer friendly environment in which they can feel comfortable and productive. After all, IT teams mostly consists of programmers, so the project should be optimized for their efficiency and happiness. But it also creates a nice set of rules that makes the communication between customers, product owners and developers easier.
But that's not all. Agile provides great opportunity for people to step forward and become leaders. But do you and your company know how to let people enter the path of leadership? How to empower the developers so they can introduce changes that make them more effective? The second part of the talk will show how developers can play the role of project managers. Your company might not become second Valve or Github but you can certainly benefit from applying changes leading towards more flat organization structure. By delegating at least some of the classic project manager actives such as meeting with clients, prioritizing tasks and extracting stories to programmers, they are given a chance to understand the business side of the project more deeply and to collaborate directly with the customer. With the technical and business knowledge, programmers can become true leaders for the projects, capable of independently handling issues and delivering the results, without the need for much supervision.
This is the story about www.myphoner.com. It started as an idea almost 4 years ago and has been implemented without launch a couple of times, lived in the shadows of bigger ambitions, only to finally come to life as a pet project, starting to see it's first revenue.
The talk is also about an whole hearted entrepreneur, trying to find his way about life. The adventures of running 3-4 startups at the same time and the ups and downs in life.
The speaker is a wonderful storyteller with a glimpse in the eye and a warmth and love about his passion. He knows when to dramatize and when to underplay his points, and his story is entertaining and thoughtful at the same time.
What have critical value for developers? The soft skills. That's what make you unique, well-paid and not replaceable. Wozniak had great technical skills but it was nothing without Job's great soft skills. You have to have both Steves inside you if you want be successful and happy developer. It you don't want to be just another brick in the wall.
15 minutes apps with rails - where this will take you? Let's rant the 'easy application development with Rails' and show how fast can you go wrong. The "15 minutes legacy rails application".
Or: Why mutation testing is as a game changer for unit tests. The pros of a solid unit test suite are well understood and accepted in the ruby community.
The problem: How to define solid? Traditional metrics like line-coverage, branch-coverage and even statement-coverage can be misleading. Having a statement executed once does not mean all edge cases are specified and bug-free!
Automated tools can be used to identify uncovered edge cases that will introduce bugs into your program. Mutation testing brings fuzzing to the implementation level. Unlike input fuzzing it modifies the implementation to check if the test suite can detect a huge set of automatically introduced behaviour changes.
This talk will elaborate the history of testing and the metrics that are used to define coverage. And how such metrics can and have misguided development direction. It will also show examples of projects that heavily adopted mutation testing. Especially the long term effects and how the (mutation)-metrics driven approach improved developer happiness and code stability. Showing what kind of actual bugs where caught and how code became naturally streamlined. Lastly the current and future limits of existing mutation testing tools will be presented. The idea is to create the "MUST HAVE"-Feeling in the audience. Finally, you can prove that you have good tests! Do not miss it!
This talk is about something important in the community. The Ruby community is missing something fundamentally important. We don't know how to architect applications. We've grown accustomed to using frameworks for everything and we've lost our way. We no longer talk about making applications, we speak about applications built in frameworks. Example: Oh hey man, did you hear NewApp123 is built in Rails? I take offense to that. The application is not built in Rails, it's built in Ruby than Rails is used to put it online. This mentality is prevalent in the community. It's damaging and encourages technical debt. This talk is about changing everything.
The Ruby community embraced testing early, with many developers switching full-time to test-driven development (and, more importantly, test-driven design); discovering the domain of a given problem and the mechanics required to make objects interact painlessly by implementing a system from outside in are oftentimes eye-opening experiences.
Whether you like to write well-isolated (and fast!) unit tests or need to implement the outside of a system without having the inside nits-and-bolts in place beforehand there's a plethora of stubbing and mocking libraries to choose from. Unfortunately, heavy mocking and stubbing comes with a cost: even with the most well-tested-in-isolation objects you can't really say anything about their proper wirings without some integration and end-to-end tests -- and writing the former is often not a very enjoyable experience.
This talk covers a new player on the Ruby testing scene: Bogus, a library for stubbing, mocking and spying that goes the extra mile and verifies whether your fakes have any connection with reality -- whether the faked methods exist on the actual object, whether they take the right number of arguments and even whether tests for a given class verify the behaviour that the class's fakes pretend to have.
With Bogus quite a few of the famously derided integration tests come for free; a change to a method's name or its signature will make all of the related fakes complain, and all the missing pieces of a system written from outside in will present themselves ready to be implemented.
Migrating a technology stack to a new language is rarely a simple task. It's getting even more challenging when what is changed is not only the language but the whole paradigm. This talk covers a story of stylefruits, where we've been gradually replacing a Ruby-based technology stack serving five million monthly visitors with Clojure. What are the costs and benefits of such a transition? How to make the migration gradual and painless? How to make Ruby and Clojure work with each other on the way? How easy is it to switch from a dynamic, object-oriented language to a functional one based on immutability and laziness? These are just some takeaways from this straight-from-the-trenches report.
We are used to write our rails application with ActiveRecord and store in the database the
current state of our entities. This kind of storage is not lossless as we might think, we completely miss the story that took the entities in the current state. That's way new architectures are becoming popular, these architectures don't store the state of the models but their deltas. During this session we will give a look at the Event Driven architectures, what problems they solve and how can be implemented in ruby and rails applications.
It's easy to believe that we have all of the tools we need to solve
problems - that all problems should yield nicely to Object-Oriented
and Functional Programming. But there are forgotten paradigms with
unfamiliar tools that allow us to solve problems very concise elegant
ways. In this talk, Michael will outline the facilities available in
the APL-derived programming languages and demonstrate a gem that
brings their power to Ruby
I'm dreaming about a ruby ecosystem that consists of plenty of awesome, kick-ass, small, focused, well-written, nicely documented, composable libraries. Micro-libraries. I want those libraries to work on all major ruby implementations. I want those libraries to use as little magic and monkey-patching as possible. I want to be able to compose bigger frameworks using those libraries. In this talk I will tell you WHY I want all those things and HOW we could achieve that.
User input contains a lot of potential complexity. A simple CRUD form can turn into an unmaintainable mess when we introduce accepts_nested_attributes_for to deal with associations, validating first this model then that one, manually adding validation errors, and finally saving
the whole thing.
What if we could use good old object oriented design principles to make forms a pleasure to deal with? Form objects give us a much simpler way to build any sort of form we want that is straight forward to build, test, and maintain.
We will build a complicated form using the default Rails helpers, and then we'll rebuild it with a form object and let the audience decide which method they prefer.
Participants: Michael Feathers, Adam Hawkins, Andrzej Krzywda
Some people say that Ruby is dying. Bullshit! I'd say it's more alive than ever.
Ruby used to be a language associated scripting and web backends. Now, thanks to RubyMotion we can write desktop and mobile apps. While Opal allows us to execute Ruby in a browser. With these tools we can finally write cross-platform Ruby applications.
After this talk you'll know how and you'll be eager to try it yourself.
Rails was born in 2004, the time of the "Ajax revolution". With the help of a little bit of prototype, scriptaculous and RJS, Rails made its mark in part because it facilitated creating beautiful and highly interactive web user interfaces in no time at all.