by Zach Holman
We tuck a lot of features away on github.com.
Sometimes the UI just hasn't been fleshed out. Or we have bigger plans in mind for the feature in the future. Or it just hasn't been finished yet. But we still want to give you the flexibility of using that feature today.
The same can be said about Git. If you've ever looked at the manpages, there's feature after feature and option after option in its binaries. Part of the strength of Git and GitHub is having access to those features when you need them, and getting them out of your way when you don't.
This talk covers both Git and GitHub: different tricks I've picked up after two years at GitHub, helpful advice on common gripes I've seen in support tickets and tweets, and just general nifty things that make you a faster, more capable technologist
What does really happen when we call a method? How do the different Ruby implementations actually figure out what code to execute? What plumbing is going on under the hood to get a speedy dispatch? In this talk we will have a look at the internals of the the major Ruby implementations, focusing on their dispatch. From look-up tables and call site caches, to inlining and what on earth is invokedynamic? Fear not, all will be explained!
There’s nothing more frustrating for a developer than spending months creating an application and then having it fail because of performance issues. That’s why integrating application performance management into each step of the development lifecycle is critical to your application’s success. Of course, easy-to-use tools for performance management are rare, and often prohibitively expensive. Not to mention that they don’t reflect actual user behavior. In order for APM solutions to succeed in the Ruby community, they must be affordable, easy to use, require no scripting; and easily integrate into the development process – be it a PaaS system such as Heroku or some other delivery system. From idea formation to final delivery, Rubyists must know their product is working every step of the way.
by Corey Haines
Mocks, Stubs and other test doubles are a common and convenient scapegoat when talking about fragile test suites. But test doubles can be useful guides, highlighting design issues and in our application. By treating them as companions, we can find our way to long-term maintainable designs and effective test suites.
We'll look at specific, common complaints about test doubles and show how these are indications of design issues. Listening to these pains in our tests can be a great way to move from using our tests as verification to seeing our test suite as a design tool.
Coming out of this talk, you'll have a better appreciation for the techniques of isolation testing in effective test-driven design.
8th–9th October 2012