Picking the right abstractions can be very hard. Understanding object design helps us evaluate tradeoffs, but where do you get the raw ideas to evaluate?
A group of developers attempted to rewrite a registration system for the 3rd time, and it turned out amazingly well because of some creative thinking. We'll focus on several concrete practices that can help to spark the creative process and give you new ideas the next time you have to do some design.
Ruby’s standard library is full of little-known... well, gems of interesting code – which might not be needed on a daily basis, but are super useful when required. From `continuation` and `etc` to `tsort` and `weakref`, learning about them means not only they might save you one day, but also make you a better developer (even if by researching the question ‘why on Earth would anyone package such a thing?’ Come and learn about the libraries you’re already using!
Most developers focus on increasing their technical knowledge. However, there are many aspects to working as a professional developer besides coding proficiency. If you have interests or experience in other fields, you can pull in even those non-technical skills (like building relationships, project management) and immediately increase your impact on a project or team. When you mentor someone, you can help them play to their strengths and ramp up more quickly as a result.
Have you tried BDD and given up? Thought it was too much trouble for too little reward? Didn't quite work for you? Fear not, you're not the only one. Many of us have been there, done it and got the 'not really my thing' t-shirt. But here's what I learned: it's not BDD, it's us! BDD works really well, but it has to be applied properly, following certain guidelines and avoiding specific errors.
During this talk we'll demonstrate the best way to start our BDD journey by defining our system, discovering our Features and writing them correctly, identifying best practices, detecting common traps and pitfalls and learning how to avoid them.
A couple of years ago, when I set out to really understand Unix from a developer's perspective, I found one invaluable resource for my Unix studies: the source code of the Unicorn web server. When I first encountered Unicorn, it seemed like magic to me: just by sending different signals to the server I could control important runtime settings. Unicorn allows me to scale the number of worker processes simply by sending a signal. Reloading configuration files and reopening log files is possible by sending signals. It even allows me to hot reload code once deployed. Again, all I need to do is send it a signal. But how does it do all that? Magic? This talk answers exactly this question.
We'll take a look at small snippets of the Unicorn source code and see that it isn't magic, but plain old Unix: forking, signal handling, pipes (even self-pipes), pre-spawning, master-worker architecture, file descriptor handling, system calls, the classic socket/bind/listen/accept sequence, Unix sockets, PID files and a lot more. There is even `eval`, but I'll keep quiet about that, I promise.
Unicorn is full of Unix. By studying its code we do not only learn how one of the most important pieces of Ruby infrastructure works, but also how Unix systems work. The talk will provide you with a foundation for programming in the Unix environment and show you how to leverage the powers of Unix.
Fluffmuffin, peppercorn, gilligan — those are just a few of our users' plaintext passwords. I have 80,000 more, and it only took me 87 seconds to gather them from our customer database in a white-hat attack. In Act I of this talk, we'll cover the history of secure password storage, examine the hack, and mitigate the threat. Act II will address the difficulties of working on libraries with complicated external dependencies (like bcrypt-ruby, of which I'm now a maintainer). In Act III, we'll celebrate the power of global collaboration via OSS.
In this talk you'll learn how to structure your application to reuse as much code as possible.
In this talk we'll look at Rails view performance and implementation. We'll see how it currently works, and how it has changed. The process of changing and refactoring the code, including code inspection tools will be discussed so that applications outside of the Rails world can take advantage of the presented techniques. We will also discuss how to take care of cats, and which emoji is best.
Natural Language Processing (NLP) is the art and science of making sense of user-generated data. It is a combination of state-of-the-art computer science techniques and linguistics.
Being able to analyze plain text data allows us to gain a lot of insights. Popular NLP tasks are text summarization, keyword extraction or automatic extraction of the author's opinion from a text. In the age of social media, only NLP provides solutions to analyze what users are really care about. Companies such as Google or Facebook invest millions in NLP solutions to harvest information from all the data they have been gathering over the years.
In this talk, I will present you a real-world NLP problem. We will discuss this problem from both the linguistic and the computer science perspective. Throughout the talk, we will develop a processing pipeline to efficiently solve this problem in an automated fashion. An NLP pipeline usually consists of multiple components, each solving one aspect of the problem and presenting its own challenges. Among other things, you will learn how to tackle the following essential NLP problems using JRuby and OpenNLP: sentence segmentation, tokenization, part-of-speech tagging, and named entity recognition.
They're everywhere. They're on the leaf that falls from the tree straight on your head. They're on the building you pass everyday morning. They're on the socks you wear today and in the code you write. Patterns.
Design patterns are defined as general, reused solutions to recurring design problems. The term, coming from architecture, appeared in software development 20 years ago and since then has been one of the most controversial topics among programmers. Are software design patterns really general and can be reused in various programs? Or are they just solutions with limited scope and don't deserve all the buzz they get?
Let's have a short trip through the software design patterns we use, the one we don't need anymore and the ones we wish had never been used - all with a pinch of object orientation and a dram of dynamism.
I'm terrified that some day, someone will find out I'm not actually a good software developer. I was just faking it all along. I don't really belong here, among all these competent people. These are dangerous thoughts that will hinder creativity, confidence and lead to missed opportunities. Many people in many fields deal with impostor syndrome, but it's especially harmful to the software development community. This is a personal account of dealing with impostor syndrome as a software developer, a guide for dealing with it in development teams and a challenge to everybody else to have the courage to be awesome.
Ruby isn't exactly know for being a functional programming language, but neither is it known for not being a functional programming language. With lambdas, blocks, and Matz himself citing LISP as a major influence, there is very little stopping us from writing code in a functional style.
We'll cut straight through the smugness and jargon that typefies functional programming literature, and go straight to the essence. What does it mean to program "functionally", and what does it buy us. What patterns and techniques can we incorporate to write more flexible, maintainable code, and what are the caveats Rubyists specifically need to look out for.
This talk will take you on a journey – from the days of the Easter Islands in the southeastern Pacific Ocean around 700CE, over the mid-15th century in England to Mars, rain forests and coral reefs of our days. On our way, we'll think about the relevance of Open Source Software technology-wise, see why the software we build is a hybrid and which impact this hybridism has on what we build and how. We'll think about Open Source Software's core values, and find out in which terms aiming for diversity (regarding gender, skills, ethnicities and ideas / backgrounds), user-centered approaches, democracy, decentralization and language will be core values when we're building the future of Open Source.
This talk aims to encourage everyone of us to broaden our horizons when it comes to how far we can go collectively with all our Open Source projects when we're thinking about the future, - and it will show how widening our communities, aiming for diversity, sustainability and attracting new contributours to our projects will enable us to make this future a bright and great one together.