by Jon Skeet
Have you ever come up with some code which works, but you would never, ever try to include in a production codebase? Something that is elegant in its own right, but at the same time makes you want to destroy your keyboard with a soldering iron, just in case you get tempted to do it again? If the answer is "no," what have you been doing with your life? Some of the most fun I've had is twisting features in C# to achieve things they were really never designed for. I've always come out of it with a better understanding of my favourite language. I'll talk about ways of thinking about languages in a different way. Going far beyond the boundaries of sanity can help you develop a taste for what is elegant and production-worthy in a language, as well as giving you insight into those occasions where it doesn't behave as you expect.
Using a “combinator” approach to create internal Domain Specific Languages (DSLs) is something that has been popular in Haskell and the ML family of programming languages for quite some time. Much has been written about it in academic circles, yet this approach to creating DSLs has yet to become popular in main stream industrial programming. Now that F#, a member of the ML family of programming languages, is available out of the box in Visual Studio 2010, this means that these techniques are now much more accessible to programmers working in industry.
Large enterprises can be slow to adopt new technology, even when it's clearly the right thing to do. When they get around to making changes to their toolsets, they can easily get carried away with the cool-factor, and adopt them without the rigor needed to make sure they perform the job properly, which often ends up with the tool being blamed for issues it's not directly responsible for. This presentation looks at the journey a major European mobile provider took, from its relational roots, through the understanding and selling of the benefits of NOSQL alternatives, to the selection and development of a strategic system in MongoDB. We will show how the idea took shape, how well NOSQL and agile practices came together, and how the concept gathered the right kind of enterprise momentum. We will also talk about the development approach, using TDD and CI, and the resulting RESTful architecture that was ultimately deployed into production. Finally we will cover the team values that brought mutual benefits by interacting with the open source community around MongoDB and how this approach has wider implications for companies looking to compete with more progressive internet businesses.
by Daniel Chaffiol
Rather than explaining one more time why a DVCS (Git or Mercurial) rocks, or how it works, this presentation will focus on the practical challenges of introducing a *distributed* VCS in an environment where authentication and authorization are very *centralized*. After all the buzz around those tools, this is a "back to reality" presentation on the right questions to be aware of, before blindly deploying a DVCS in a large IT department. See http://stackoverflow.com/questio... for a summary.
by Tom Wright
Learn about sensory substitution devices and the specific design problems involved with their development.
by Dan Haywood
You need to build a new system, and because its functionality will be reused by other systems, you decide to adopt a RESTful approach. But because you also need to deliver some business value, you then start to use that API... In this talk Dan reviews a years' worth of developing and consuming a RESTful API developed with strict TDD and agile principles. We debate HATEOAS vs templated URLs, what sort of media types to expose, how we tested the app. We also discuss whether and how to hide the domain model, not to mention whether the domain model we ended up with was actually any good. But we punt into the long grass the question of how to document the RESTful API. And then, we wonder if said API really is RESTful, and if it is isn't, whether that mattered. What would it take to make it truly RESTful, what would it be worth the cost? And, we consider what is it within REST that makes it hard to get it right first time around. Drawing on his experience of domain-driven design, Dan then proposes an alternative approach, adopting a DDD style first and then looking to expose the domain classes via a generalized RESTful API. What are the objections to doing this, and do they hold up? What are the benefits, what are the compromises, can, indeed, such a generalized API, in fact, be specified? And if it can, might it be a way to build RESTful systems in the future?
The finalists of the Code Ken Side Projects competition will have 10 minutes each to present their projects. After which time the audience will decide on the project winner. Find out more about the competition.
by Richard Marr
Working with the modern web increasingly means working with asynchronous behaviour and real-time data, but it doesn't have to be hard. This session will introduce Node.js and show a few of the tools you can use to create your own real-time apps.
Over the last 3 years at LMAX we've been building a high performance financial exchange. A task that has brought a lot of interesting challenges. Our most interesting discovery is that the software industry is rife with mythology and folklore when it comes to performance. In an effort to bring back science and rational thought to software development, this talk will attempt to dispel the common myths that we have encountered. It will be a deep dive into a number of areas of software development including distributed systems, concurrency and parallelism, I/O, algorithms, garbage collection, and memory efficiency.