Software is always a mess. You can't avoid this mess, and if hubris goads you into attempting to achieve perfection, you'll just make things worse. Perfection is a distant, dim land on the unreachable horizon. You'll not be going there today.
What you can do, however, is use the techniques of object-oriented design (OOD) to make your messes manageable. OOD is good at messes. It understands their origins, predicts their courses, and foresees their outcomes. It shines a light down the dusty nooks and crannies of your app, showing you what to do and what to avoid.
This talk shows you how to use OOD to create the best kinds of messes, those that let you get software out the door today without regretting your actions tomorrow.
Most developers know enough about refactoring to write code that's pretty good. They create short methods, and classes with one responsibility. They're also familiar with a good handful of refactorings, and the code smells that motivate them.
This talk is about the next level of knowledge: the things advanced developers know that let them turn good code into great. Code that's easy to read and a breeze to change.
The Open-Closed Principle
The types of coupling, and their dangers
Powerful refactorings like the Method Object
The beauty of the Decorator pattern
Testing smells, including Mystery Guest and stubbing the system under test
The stuff from the last halves of Refactoring and Clean Code that you never quite got to :)
These topics will be covered solely by LIVE CODING; no slides. We'll boldly refactor right on stage, and pray the tests stay green. You might even learn some vim tricks as well as an expert user shows you his workflow.
Great developers need to know why they do what they do. Only then can they hope to apply, adapt, and even drop their practices in the context of each situation. Unfortunately, very few developers can clearly articulate why they do (or don't) use test doubles—be they mocks, stubs, fakes, or spies. This talk aims to raise the level of discourse on this topic. By better understanding why we use test doubles, we can write faster, clearer, and more informative test suites; even if it means choosing to never use a stub or mock again!
Many argue "mocks suck," because the resulting test won't be realistic enough to gain any significant confidence that their code works. Others use mocks to control the outer boundary of a test's execution from expensive, hard-to-setup dependencies (e.g. by faking a database or network resource). Others still see mocks as a "setup of last resort", using them to manipulate what would otherwise be an integration test in order to reduce the pain of hard-to-test situations. Finally, some developers use test doubles in place of nearly every dependency in every test, and their reasons are probably the most poorly understood of them all!
This talk will provide a broad-stroke survey of the different ways developers use test doubles, with the goal that we leave with a more sophisticated means of communicating on the topic. The talk will also provide practical guidelines for how adherents of each of these varying philosophies could better use (or avoid) test doubles. Finally—if the audience is kind—I'll share my own opinion on how and why I prefer to use test doubles (and maybe a little on what I learned writing my own test double library, "gimme").
A lot of Ruby developers use Rails for their everyday projects. Often they toy around with front-end themselves or outsource it, ending up tangled in a web of css-all-over-the-place.
Keeping your front-end code clean is hard. Before you know it you're suffering from CSS specificity issu
I hear sometimes that good things come from carrots and sticks, from fear, from doing what you’re told. But what if there's a better way to get the stuff we want? Stuff like money, working software, the geek joy of a solved problem. What if choosing love (and more specifically, curiosity, vulnerability, and kindness) gets us geeks what we want most?
There is a shortage of software developers today. Programs like CodeAcademy, HungryAcademy and DaVinci Coders are looking to help with that shortage. Mike Gehard will lead a panel on learning, what are the strengths are weaknesses of these programs are and how we all can help alleviate the shortage of quality software developers. If you want to be part of the solution, please join us.
For a long time, the de facto way of doing multi-core concurrency was using threads. However, the complexity of manipulating threads and state affected negatively how developers perceive concurrency. Fortunately, languages like Clojure and Erlang implement new paradigms that aim to make concurrency easier.
In this talk, José Valim is going to discuss the role state play in concurrency and introduce different paradigms for multi-core concurrency, like Actors and Software Transactional Memory, explaining their trade-offs and why they matter to us developers.
Assumption 1: Group chat is an great tool for collaboration Assumption 2: With enough code, anything is possible
Proposal: Write code to create a robot helper for you group chat to handle menial, annoying things for humans
You know about lmgtfy.com, ie let me google that for you? What if, every time you had a question about how something works, or where to find something, or what to do, you could simply ask a robot helper? For example:
How can I contact customer X?
Where are the NewRelic graphs for Y?
What's the deal with billing for customer Z?
How many alerts have there been in the last 24 hours?
Should I make an iced latte, or a regular type latte?
Rails Machine has been a distributed team for many years, and group chat (specifically Campfire) is a great tool to work together to get stuff done. In order to serve our customers, we have to interact with a dozen or so SaaS, self-hosted, or self-written applications, many of which are only loosely coupled. Over the past two years, we've been slowly building our robot helper to help navigate those services, to connect the dots, and generally make our lives easier.
During this talk, we'll be exploring the journey from lulz-based robot friends, to (nearly) full fledged robot workers that make their humans equivalents look like chumps. Or at least, look like chumps that can make the robot even smarter.
As Rails applications grow they see a lot of the same problems that any enterprise level software project will see at some point: longer running test suites, more complex code interaction, and a rising requirement to keep "all that stuff" in your head at once.
Rails may have been a framework for single applications in the past, but it nowadays has some features that allow you to tackle bigger projects with more ease. We'll cover Rails code structuring techniques like unbuilt gems and engines that you can use to get faster test suites, cleaner structures, and more flexible apps.
Realtime, rich client applications are extremely popular. This is reflected in a new generation of frameworks like node.js and meteor. That said, the maturity of Rails and Backbone combined with real time services like XMPP or Pushr, still makes it a very compelling backend stack to use, especially when developing cross platform (web, desktop, mobile) applications.
In this talk, I will discuss the foundation and best practices of a Rails/Backbone/Coffeescript real time stack, as we do it at Kicksend.
Whether your official title says it or not, every one of us is a consultant. Whether it is a time and materials contract with an external entity or dealing with the stakeholder within your company, some amount of consulting is required. One of the reasons we each get hired is to bring our expertise and experience to the project at hand. We have to make technical decisions every day and do our part to guide the project towards something that will be successful, both in the short term and down the road.
At Hashrocket, we deal with clients of all levels of technical and business expertise. We need to handle different clients in different ways, depending on their needs, personality, and budget. I want to share with you some of our stories and the different tactics we use to interact with our clients. From this talk, you'll be able to glean some knowledge from our expertise and apply it to the interactions in your daily work life.
Dealing effectively with the consumers of your work has many aspects to it, including knowing how much information to give and in what format, when to stand up for something, when to concede, and who to get involved on your side. In this talk, I'll discuss these and other important topics for successfully guiding your clients along the path to greatness.
Have you ever thought about how much of software engineering involves explaining things? We stick comments in our program to explain why we added X to Y, we type up README files to explain the program, we write proposals to explain why the program should be funded and we spend the afternoon explaining the whole thing to the new guy so that we can move on to something new. A decent explanation can be the difference between success and obscurity: Would there be any Ruby conferences if not for that original 15 minute build-a-blog screencast for Rails?
In this talk Russ Olsen will run through the things that you can do to craft explanations that are clear, engaging and perhaps even a bit funny. Russ will do his best to be clear, engaging and perhaps a bit funny.