Videos provided by Scottish Ruby Conf via their Vimeo Channel.
One day I found a note on my desk at home. I had no memory of writing it, but the handwriting was unmistakably mine. “I HAVE NO IDEA WHAT I’M DOING”, it said.
The note took me by surprise, but I couldn’t fault its accuracy.
In this talk I’ll confirm that I have no idea what I’m doing, and explain why that’s not necessarily a bad thing. I’ll touch on evolutionary biology, the impostor syndrome, the Dunning–Kruger effect, test-driven development, material exploration, beavers, judo and Douglas Adams. By the end I hope to have convinced you that wilful ignorance is a vital ingredient of human creativity, and therefore of programmer creativity, because a programmer is a type of human.
State machines are everywhere. In fact the theoretical basis of our universe, quantum physics, consists of microscopic quantum state machines. These particles find themselves in discrete quantum states and can change state only in certain ways via uninterruptible transitions known as quantum leaps. Voila a perfect state machine.
State machines control the phone call between you and your mother to ensure that you get connected when both of you pick up the phone at exactly the same time.
State machines are paramount in the development of robust hypermedia API’s. The messages drive the application state (machine).
In general the state machine helps to simplify the logic to ensure your program responds appropriately in whatever order you throw events at it.
In this talk we will explore the powerful features of hierarchical state machines and look at how you can use them to accomplish simplexity in your programs.
Simplexity: complexity wrapped in something simple.
Rails is a mixture of design patterns, practices, and magic. In this talk, we’ll explore how Rails embraces ideas from other frameworks and projects.
Active Record was born of Martin Fowler. MVC was the brainchild of Trygve Reenskaug. Rails 3 completely absorbed the Merb project, gaining modularity and extensibility that it previously lacked.
We all learn by standing on the shoulders of giants, even Rails. By understanding the inception of design patterns, we are more likely to be able to create ideas of our own. This helps us to not only grow in our own ability, but to help others improve as well.
You don’t get upset or angry for no reason. Somebody says or does something, and your reaction is instinctive, immediate.
You feel angry.
You can’t control what other people say or do, but you can learn to control how you react when they do things that you don’t like.
Non-violent communication gives you a model to understand where your anger comes from, and a means to communicate with people in a way that is respectful, compassionate, and free of aggression. Even when you’re feeling angry.
In this age of Twitter dramas, it’s a tool I wish more people were aware of.
You can’t go to a Ruby conference lately without someone banging on about concurrency and thread safety. You’re a smart Rubyist, but… you don’t get it. You understand the basic idea, you nod along, but once they get into the jargon, what does it all mean? How does it apply to you, and what is it, exactly? This talk will answer those questions, by engaging in a basic primer on concurrency in Ruby, a discussion of actual examples of how it works, and provide you with answers that will leave you nodding in agreement, rather than nodding off.
A tour of my favourite engineering mega-structures.
We rubyists historically haven’t been in the habit of thinking about concurrency but the reality is that our thread-unsafe code often works by sheer luck. There are different implementations of Ruby with their own semantics that can unearth challenging and unexpected concurrency bugs in our code. We have to become more accustomed to writing threadsafe code in order to anticipate these potential surprises, especially in light of the rise in popularity of JRuby.
I will discuss approaches to writing threadsafe code in this talk, with a specific focus on performance considerations and testing. We’ll look at some basic concurrency concepts, describe methods for handling shared mutable data, and touch on the subtleties of some concurrency primitives. Hair-raising, real-world bugs will be used throughout the presentation to illustrate specific concurrency issues and techniques for solving them.
Software projects rarely fail for technical reasons. The icky, gooey human aspects of our teams and organizations regularly present structural obstacles around which a solution simply can’t be programmed.
“Office politics” deserves much of the derision it receives, but every virtuous person who opts out of it effectively forfeits the organization’s future to others—potentially to folks who would use their power malevolently.
Developers tend to have several disadvantages when it comes to this arena, but they can be mitigated with greater awareness and can ultimately be overcome with intelligence and leverage.
In this talk we’ll discuss how to gain awareness of the human systems that govern organizations and—through the use of examples and illustrations—we’ll highlight the individual virtues necessary for successfully having an impact on your organization’s future that’s larger than yourself.
“Should I become a manager? Do I want to be a manager?” Experienced engineers are often confronted by this important decision at some point in their careers.
Your organisation believes you have the right qualities for the job, but is it really the right choice for you and your team? Now that you have the experience and the domain knowledge, is management the next, natural step in your career path? Is it the right way upwards? Is it a permanent decision?
I’ve twice faced this dilemma during my career. The first time I didn’t feel it was the right move for me, but the second time I very consciously accepted. In this talk I will cover the reasoning behind these decisions, the lessons and pitfalls that I’ve discovered transitioning from a lead engineer to an engineering management role, and what it might mean for my future.
Understanding of CRuby source code has profound effects on every Ruby developer. In my talk, I will show you how to build Ruby from source. I will explain how to install and configure your new Ruby build on Mac and Linux. I will walk you through CRuby source code and introduce you to a few of the most important CRuby files. I will show you how to hack CRuby and modify some of the fundament Ruby classes in C. I will demonstrate how to write complete Ruby classes in C. Finally, I will show you that CRuby code can run 100 times faster than Ruby code. I hope that this talk will inspire you to learn more about CRuby and hack it on your own.
With software developers in high demand and placing a higher focus on quality of life, it becomes necessary for teams to not only allow but to embrace remote working. Members of remote teams are able to work from a venue of their choosing, with little to no time wasted on commuting. Managers of remote teams no longer have to hire from a pool only consisting of people who have the same taste in geography as them.
Remote working offers great deal of flexibility for teams but can take discipline and practice to make it work for your team. In this talk, you’ll learn about patterns, practices, and pitfalls of remote working. Examples will be shared of successful remote teams, and what works for them, as well as some examples of teams that failed at remote working, and what we can learn from them.
Find out whats involved in running a local Code Club for primary age school kids. We will cover lessons learned in getting kids switched onto programming and making. How to extend the Code Club curriculum with simple robotics projects based on the Raspberry Pi and Arduino. Using a Makey Makey to create a banana keyboard. See the games and robot developed by the boys and girls at the local Code Club that I run.
As developers, most of our time is spent on computers and electronic devices; but sometimes good old-fashioned pen and paper is the best way to explore and develop our ideas. Sketchnoting combines hand-drawn elements and text to enhance focus, improve memory, and visualize important concepts. The practice of sketchnoting is not about the ability to draw—it’s about the ability to listen. This talk will cover tools and techniques to visually capture ideas, how to approach the mental multitasking required to sketch during technical talks and meetings, and why “I can’t draw” is an artificial barrier to embracing creativity in your notes.
Object-oriented programmers can have a dogmatic approach to language patterns. Whether it is analyzing, debating or criticizing various implementations, the passion for patterns emerges from the need to both communicate intent and categorize code. The patterns do more than define code, they describe it. So, what happens when we lose objects? When state fades away? When paradigms shift far more than a change in languages?
In steps Elixir. With syntax similar to Ruby but firmly grounded in the functional paradigm, it represents an easy transition for Rubyist into functional programming. But what about the beloved patterns? It turns out that understanding how functional languages implement some of the common object-oriented patterns can demystify this new paradigm. Plus learning new functional patterns can provide new solutions to old problems.
Have you ever run into that problem you are trying to solve, that is tangential to your core business? It’s easy to run off, look for a gem, and use it.
What is harder, is when that gem … isn’t quite right. Maybe you should look for an alternative. Maybe you should fix the gem. Or if your problem is different enough, you can fork the gem
Or maybe you should just stop wasting so much time looking for the “easy” solution, and just DO THE WORK.
As 2014 will be remembered as the year of the Java Renaissance, I thought it might be fitting to take a look at graph database technologies. Learn what they are good at and see how to integrate them within your ruby web applications. We will have plenty of code samples and use cases and you will leave this session with a very useful item to hang on your tool belt.
Sometimes you are tasked with building great things by yourself or in a small team. Bootstrapped start-ups don’t always have the budget for a dedicated Uxer to help you design the best apps, software or websites. So how do design great things without a Uxer?
This is not a definitive guide or to even to be used instead of getting professional UX help but it will get you started developing the right way and stop you making classic mistakes.Before you even consider touching your dev environment I will show you how to “Start with one idea”, “Think like a user” and set out your user journeys. From this solid foundation I will show you how to wireframe your logic and build it as rough a prototype as you can manage. We then consider how to evaluate and iterate on your designs and what tools you can use. Finally, I outline the importance of never being afraid to scrap anything which doesn’t work. All without a single line of code being written.
I love Ruby! But as in any relationship, to love means that you (often) have to accept the “dark side” too! Ruby is human in nature and has a lot of gotchas, tricks, wierdness and sometimes scary features that I plan to highlight. This talk aims to provide the “Ah-ha!” moments when working in Ruby.
This talk is for beginners and experts alike – in fact, I tag slides to mark their level and beginners can choose to tune out of the heavy stuff! My talk shall cover the dark side of the following features of Ruby (in no particular order)
Module inheritance! (huh?)
Curried Procs for the hungry
Cherry picking module methods
Object id wierdness
procs, blocks and our friend stabby.
==, ===, eql? and equal?
As with most of my talks, humor plays an important role and I shall aim to get everyone high on Ruby with a deep dive!
Graham investigates common techniques for working with processors that feature lossy, non-random access storage; aggressive pre-emptive context switching; and a wide library of fuzzy pattern-based logic and illogic functions.
We want to produce reliable, functioning software… but we often don’t. The cliched cry of “but it works on my machine” demonstrates the myopia that most web developers (including me) suffer from: we spend almost all of our time working with a development environment. This leads us to think of production as “like development, with people using it”. Then, when things go wrong, we think “oh, I see now, production is like development except this one thing that went wrong”. This is exactly the opposite of the mindset we need. Production is fundamentally different from development, and it’s important to keep that in mind. This talk discusses some of those fundamental differences, including load balancing, metrics, data store reliability, and network partitions. Don’t get stuck rebuilding your servers at 3AM because you went with the option that was easiest during development!