Videos provided by Rubyfuza Conference via their YouTube Channel
Software development has gone through many upheavals and downhills to what it is currently. Still, it remains an impressive creation that is changing the lifestyles of many. Africa, on the other side, has a history that is yet to fully captivate many of its own people. So what could "software development" and "Africa" be doing in the same phrase?
Being passionate about code and enjoying a love-hate relationship with my continent, I will share how these words resonate with me. I will discuss some of the achievements and also challenges of developing software in Africa, my fears and hopes too. Let's have a conversation on what these words mean for us; software development and Africa put together.
This talk is about paring and it is not about why you should pair. It is about how to pair effectively when someone is not sat right next to you.
I have been doing TDD for several years and of late, I have been left with the feeling that I am missing some key part of the value that it supposed to offer. This talk will cover some (not enough time for all) of the n00b mistakes I have made in the past, and I will try and present a TDD strategy that works for me and may help inform improvements in the way others approach their tests.
The 'Get Shit Done' philosophy embraced at most startups, sometimes leads to bad, ugly, stinking code (its not your fault, you din't have enough time :) ).
So what do we do now? We wear our gas masks, grab the refactoring cheat sheet, and get hands down dirty into the shittiest code we have written, and we clean it up. We keep cleaning till it smells of jasmines.
And we come out with battle scars on our faces and a sense of accomplishment in our hearts.
Programming languages exist to allow programmers to make sense of complex real-world problems. What real world scenarios lend themselves to modelling by objects, and which to functions?
The first time I met objects was in Turbo Pascal in about 1990. I was completely baffled. I eventually got comfortable with objects in c++, and had that turned on its head by Smalltalk. Then Java objects came along and made me write too much code. Ruby was a breath of fresh air, but it took me 8 years before I really grokked the object model in Ruby. Lately with all the interest in functional languages, I've been glimpsing some overlaps between functions and objects.
I'm still not sure if CLOS is a good idea though.
Accompanied by real-world code examples in Ruby, naturally.
In this talk I will run through some of the things I've learned while working in this environment and hopefully it will give developers a bit of insight into our design/development relationships and process and how we use Rails as a design tool.
We'll take a whirlwind tour through Clojure - the rapidly rising functional language on the JVM - and Datomic, a novel take on immutable databases. We'll see how the notion of immutability makes life as a working programmer a lot easier in Clojure, and in Datomic, how it becomes possible to query the past, query against what-if databases, query across databases, and more.
Persistent data structures are being imported from the FP world.
What makes persistent data structures particularly interesting is that they cannot be modified in the traditional sense. These structures can model a timeline of changes quite naturally since every "change" creates a new "copy".
"Functional Reactive Programming" is another old/new idea. FRP has a time centric viewpoint.
In this talk Danie will explain why persistent data structures are good and specifically why they are good for (the) UI.
While most parts of Rails have been thoroughly overhauled during the past few years, one part has stubbornly refused improvement. The view layer is still by default using ERB to transform your app's objects into HTML. Though HAML has gained a lot of traction, it is not a fundamental shift away from ERB, but rather a preference for putting HTML in your Ruby rather than the other way around.
While trying to solve a seemingly unrelated problem we discovered a design that suddenly enabled us to move past the limitations of ERB. Though different only in subtle ways, it struck just the right balance between integration with Rails and separation of concerns. We called it Curly.
I will show how we use the same old OO techniques that you already know to clean up our views, making them less prone to bugs, more readable, and more reusable.
I'll also show how a seemingly small change of our conceptual model enabled us to add advanced behavior to our view layer without ending with an unmaintainable mess.
Curly is open source and available at http://github.com/zendesk/curly
We should all be artists in our craft, but there is a balance between expressiveness and performance. This talk is about finding that balance and producing beautiful code that doesn't sacrifice syntax for speed. I'll explore real world examples of code and mold them into something far more expressive. During the process we'll take a look at how common design patterns are applied to larger applications and examine the repercussions.
Ruby gives us a lot of freedom when expressing code and draws features from various paradigms, but it's an object oriented language at heart. In this session we'll go back to first principles of object oriented programming and see how applying object inheritance, polymorphism and a bit of discipline can translate into an understandable and maintainable codebase.
This talk will focus more on the delivery aspects of sending lots of email while including some basic configuration for Linux, Rails, & Postfix.
How to send lots of email and not look like spam.
What You Don't Know About Sending Email
Most People Who Send Lots of Email, are Sending Spam.
Make Sure You're not Sending Spam
Make Sure the Gatekeepers you're Sending to Know Who You Are
Make Sure You're Using the Right Tools for the Job
Gather Feedback From the People You are Sending to, and Act on it
How to comfortably forget most of what I said here (except for the not sending spam part)