Videos provided by Railsberry via their Vimeo Channel
"When we look at the current state of web applications, the most common answer on how to speed up an application is to use some sort of message queue to move processing in the background.
Message queues have rightfully been around for a long time, more than thirty years by now. Yet they still pose an interesting question for us as developers when it comes to using them. They commonly add multiple layers of complexity to an application, each of his in one way or the other, evolves around the message queue.
While we're trying to work around this by moving the workload into our database rather than a separate queue, the issues remain the same, they may even become worse. The database is the message queue, and the message queue is a database.
This talk is a whirlwind tour of message queues, looking at the common patterns they're being used for, the complexities they add, and how applications need to evolve to deal with queues in a resilient fashion."
In the Mac developer universe, there's a lot of talk about the Terminal. But why stop there? Native GUI interfaces are super useful - not just for designers with zsh-o-phobia, but for everybody. Let's see how Ruby can help.
Sleep: we all do it. It's easy, and yet - as most of us experience every morning - it's somehow really hard too. It's also very relevant: as thinkers, creators, and problem solvers - people whose fundamental job it is to use our heads - how our brains work is a subject of huge importance. This is a scientific tour through recent scientific research (with references, of course) on the effects and causes of sleep restriction. Sleeping even six hours a night produces measurable cognitive impairment in most people; it gets worse as you sleep less, to the point where some parts of your brain are constantly functioning like they hadn’t slept in days. Who'd want to code, let alone live, like that? Things get even more interesting when you examine why it's so hard to get a full night of sleep - how our internal clocks and their adjustment mechanisms often in conflict with society's timetables. So many of us end up in a state of "social jet lag": missing sleep every night as if we'd traveled a timezone or more by plane that day, constantly tired and never sure why. We spend countless hours optimizing our development environments to get maximum efficiency. Shouldn’t we treat our most important tool - our brains - the same way?
Alan Turing set out to find the answer to the question: "Can machines think?". Thinking, that's easy! Even my dishwasher can do that (it's a really smart dishwasher). How about we try something harder and push into a new area of AI: "Can machines be creative?". We will put forward a new Creative Machine test and thats were you all get to participate (participation mandatory). Can you distinguish between a machine's creative attempts and a humans? Along our journey down the path of discovering a new generation of artists, born through Ruby, we will look into the heart of each machine-artist. Examining different algorithms/techniques and their effectiveness at exhibiting creativeness. Also how slowly killing a neural network lead to some of the greatest progress in creative machines.
Over the last two years, I've traveled the world to pair with expert designers and developers on short projects to learn their day to day secrets and understand their philosophies. I've condensed this to 35 minutes of tricks, insights, opinions, and old-fashioned rants from Aaron Patterson, Corey Haines, Ryan Singer (37signals), Kyle Neath (GitHub), Neven Mrgan (Panic), Zed Shaw, Gary Bernhardt (Destroy All Software), and others.
The best software developers are also great teachers. They can effectively teach customers how to use their products and teach other developers how to use their APIs. However, there are many different teaching techniques and there is no way you're going to be able to use them all (nor should you).
In this talk we'll go through several classroom teaching techniques, discuss how they've attempted to go online, and then take a guided tour through 8 different startups who are innovating in the education space, each focusing on different areas.
Your tests failed. Again. And they didn't just fail, they failed you. There was no bug. There was no regression. You changed something trivial - an implementation detail - and your app still works but your tests are broken. They don't have your back. What purpose do they serve?
In this talk we'll evaluate the unit tests from an open source codebase. We will cover the roles a test plays in the lifecycle of a project, and explore guidelines that let us assess their worth, and determine which tests should live, which must die, and which are missing
Of course you can create great web applications using Ruby and one of its well known frameworks like rails or sinatra or padrino. Ruby can be either a very effective language to be used to create security tool and to make security tests. In this talk we will make a walk-through of some tests you can make to assess a web application for its security level using ruby gems or oneliners.
The Post-PC revolution is already here. Finding new natural interfaces, using your customers data for intelligence and a ubiquitous approach are key. In this talk we'll tell you how to take advantage of the opportunity, how to use it to your strength and how it all affects our work.
Go is a general-purpose language that bridges the gap between efficient statically typed languages and productive dynamic language. But it’s not just the language that makes Go special – Go has broad and consistent standard libraries and powerful but simple tools.
This talk gives a brief introduction to Go, followed by a tour of a real programs that demonstrate the power, scope, and simplicity of the Go programming environment.
Keavy is part of the internal tools team at Github. She will give an insight into some of the internal tools used at Github, and discuss the importance of building and using software that enables and supports your team, whether onsite or distributed, to be more productive, informed, motivated and happy.
This mid 80’s declaration from the fashion industry has become synonymous with radical shifts in the norm of any field. Agile provided such a radical shift for traditional waterfall processes. Yet as Agile has matured, it is redefining itself at a pace that rivals the whims of the fashion industry.
This presentation presents not only the (somewhat obvious) shifts from waterfall to Agile, but the second and third generation of shifts within the Agile community itself. Basics such as automated unit tests are falling away (“Deployment is the new unit test”).
The overall message is to continue to question practices, and strive to understand the reasons behind a practice so that you know when it is safe to discard.
"Do you use Merkle trees? How about hash rings? Vector clocks? How many message patterns do you know? In this increasingly decentralized world, a firm grasp of the pantheon of data structures and patterns used to manage decentralized systems is no longer a luxury, it's a necessity. You may never implement a pipeline, but chances are, you already use them."
You probably know that the population of the African Elephant is on the decrease due to demand for ivory. But if you ever wanted to find out how much ivory exactly is being traded and by which countries, you’d need to come straight to UNEP-WCMC in Cambridge, the maintainers of over 30 years worth of endangered species’ taxonomy, legislation and trade data. Join in to find out how we go about making this data available worlwide and how some PostgreSQL magic comes into play.
The dreams of developers working on monolithic Rails applications are frequently filled with sugar plums and service-oriented architectures--but like any kind of software design, SOA can easily become a tangled mess. Many of the same principles that guide our software design can guide our architecture design. We apply SOLID principles to applications to keep them loosely coupled, we design interfaces so we can send logical messages to our domain objects. We hide our databases behind abstractions because how we access our data shouldn't matter to how we consume it. Rarely, though, do we see the same practices applied to our services and APIs, leaving us with tightly coupled and difficult to extend service-oriented architectures. If you are facing the monorail to SOA challenge, consider looking at your services as objects and your APIs as messages. Service-oriented applications are complex, and the best way to fend off complexity is though object-oriented design.