Great developers are on a constant quest for knowledge, and knowledge begins with questions. “Do I need to learn about EventMachine or node.js? Can I use threads? What is so good or bad about threading in Ruby 1.8, Ruby 1.9, JRuby and Rubinius 2.0? What choices do I need to make, how different does my code look, and how do I do testing?”
Dr. Nic Williams has approached many developers with these questions. He even hosted EM RubyConf during RailsConf 2011 in order to gather the brightest minds in the Ruby community. Join Dr. Nic as he shares answers gathered during this recent quest for knowledge.
The process of software maintenance starts just after the very first bits of code have been written. Lets face itâvery few of us enjoy chasing bugs, reading tagliatelle code, finding inconsistencies in how things are built, fixing the same bug in 50 different places due to copy-paste-coding, not feeling confident in our own modifications due to sub-par tests and having none or broken documentation. As a software project grows, and time passes, it is very common for bugs to be harder to find, changes to be harder to make, and new features harder to integrate. Sounds painfully familiar? Don't worry, in this talk we'll explore ways of dealing with these issue before they even become a problem.
Viktor"the legend of"Klang, Director of Engineering at Typesafe, is the former Tech Lead for the Akka project. Personal heroes are, including but not limited toâDoug Lea, Walter Sobchak and Daniel Spiewak.
Once you realise the true enemy of software development is complexity, not waterfalls, you can start rethinking how we write our software. Come learn why modern languages like Scala and Clojure lead to fundamentally better software systems than any of yesterday's tricks.
Have you noticed that in spite of all our oft repeated Best Practices, those bugs don't seem to stop coming back no matter how many tests we write, that pile of technical debt still seems to keep growing no matter how much we refactor, and we keep missing those deadlines no matter how we organise our scrum board?
Perhaps it's time to stop listening to those who shout the loudest and start applying actual reason to the problem for a change. The programming paradigms that served us so well through the 80s and 90s are no longer adequate for developing software in the modern world. Building systems the way we're used to building them always seems to end in the inevitable death march towards exponential complexity.
But once you start asking the right question—"what's causing all this complexity?"—the answers turn out to be obvious. Debugging is only hard when you can't reason about your code. Concurrency is only hard when you can't predict the state of your code. Reusability is only hard when your components aren't naturally composable.
These problems are what the modern generation of functional programming languages—Scala, Erlang, Clojure—have been designed from the ground up to overcome. This is what the really smart people in our field have been up to lately, and it's really time you put down those Post-Its and come let me show you why it's a really, really big deal.
Bodil is a compulsive conference speaker in the fields of functional programming and internets technologies, and is a co-organiser of three annual developer conferences in her home town of Oslo, Norway, mostly because she’s still learning how to stop. She is a prolific contributor to the Free Software community, primarily as a Clojure developer, and has recently taken up designing new programming languages as a hobby. In her spare time, she works as a web developer for Comoyo, which is like Hulu for non-Americans.