CAT | Rant
This post is my rant on how to make QCon a better conference or any developer conference for that matter. I’ve attended it for my first time in 2012 and was expecting a great deal since it’s probably the best there is with opening keynotes from people like Martin Fowler.
Quality Over Quantity
In my eyes it’s much better to have 1 day worth of talks with exclusive speakers than three days with lots of very average content with average presenters. QCon had 3 days, 7 parallel lanes and 6 presentations in each one of them. That’s 18 presentations in total for one visitor to see. Or over a hundred presentations in total. However it seems to me from following twitter that only ~10 of them were very well accepted. Some were so good that there was not even a spot to stand.
This leads me to suggest that the conference should be more strict who can attend these massive conferences. I would suggest that it only accepts speakers who have spoken in smaller conferences at least 5 times. There could be selective early bird invites to review the talks before they get accepted. Maybe you could get a discount if you agree to do so. The author would obviously have to make a recording of his talk.
Talk Titles Descriptions
So many times I have felt fooled and lured by a catchy title just to try to stay awake during the talk. I guess there’s nothing wrong to have a catchy title. However I would suggest that each accepted speaker has an introductory video on who he is and what he’s going to speak about. That way you can get a feel of a person before you go see him. Also if the above suggestions have been followed then links to his previous speeches in video should be included so viewers could review how good the speaker is.
Another great addition would be to mark how advanced the talk is. Just add a simple tag: introduction, advanced, expert. However I would argue that QCon should not have any introductions to topics like NoSQL.
Hack Fest Anyone?
My colleague suggested a somewhat crazy idea. To organize a hackfest so that people could do some coding together, solve some challenges, get to know each other, compete, get EXCITED. Have you seen the movie Social Network where devs were competing for a job at facebook and had to hack a linux box while drinking vodka shots during the challenge. Something in that direction maybe?
A conference for everyone
This is an experimental thought also suggested by my colleague. There’s a pattern that developers love talks which talk about organizational changes. It’s weird but they applaud more the talks on how to have a great team, great processes rather than a new tool. However when they go back to their organization it’s very difficult to apply these ideas at your workplace because most of the time you’ll be met with outright scepticism and denial. What if your product managers, your QA’s, your sysadmins and maybe even your CEO would find it worthwhile to go to such a conference. How awesome would it have been if all these different roles could haven seen the Github talk together with you? Or would you be interested to hear from CEO’s who were developers once and how they became who they are and what they’ve learned along the way.
Always organise giveaways at the end of the conference in one big go rather than at random times during the conference. This will keep people from going home and staying in the main hall, getting a few beers, maybe meeting someone and it will also make it more convenient for the visitors.
Don’t kill the messenger
This whole rant might make me sound like an ungrateful bastard but it’s not like that. I do appreciate people trying and doing what they do. The QCon that is right now is still infinitely better than no QCon at all. However as everything else it can be even greater.
I was attending the conference for the first time and wanted to share my top list of talks. There might have been other good ones but I didn’t get a chance to see them therefore can’t comment on them. All of these talks will be released on InfoQ in the next 6 months for your viewing.
#1 Lock-free Algorithms for Ultimate Performance
This has to be my favourite talk. These guys know they’re hardware well. They showed how it’s possible to create lock free algorithms which run in nanoseconds if you apply some mechanical sympathy to your code.
#2 Decisions, decisions
A really entertaining, insightful and somewhat shocking talk. Not an unusual talk by Dan North in anyway. He talks about decisions (obviously) and that each one of them is a trade-off. Sometimes we forget to weigh these trade-off’s.
#3 How GitHub Works
A great talk and visually beautiful as well. Even has some singing in it! Zach is a wonderful presenter and explains how github does what it does so well. Their approach is very unusual and alien from the one we see in the corporate world yet it works so well.
#4 Developers Have a Mental Disorder
by Greg Young Talk This guy does not need slides!
A non technical talk by a very technical person. It was Greg’s comeback to the QCon stage and a great one. He delivers a speech on many of the disorders developers carry with them in their work. The best one so far being: solving problems no one has.
#5 Concurrent Programming Using The Disruptor
It would be enough to say this talk was delivered by a beautiful lady packed with a room of geeks but it deserves more praise. It’s a quite technical talk on an innovative and great piece of software or rather a framework: The Disruptor a concurrent programming framework. If you’e unfamiliar with it or even more so unfamiliar with concurrent programming you might find it interesting.
Special Mention – Scalable Internet Architectures
Haven’t attended this one myself but have heard that it was great. Managed to only see a few minutes of it where the author said: “Don’t be a fucking idiot!”. This sentence alone makes a talk good.
Recently I’ve attended the PHPUK 2012 conference where I went to see a talk “To a thousand servers and beyond: scaling a massive PHP application” by Nikolay Bachiyski. The talk itself was more about how wordpress.com scales to serve it’s massive load but what got me interested to write this blog post is how wordpress.com does deployments.
There are two parts about WordPress. One is the blog that you can download and host on your own servers. The other is where you can create an account on wordpress.com and set up a blog on their own servers. These two are developed and released separately. What we’ve found out from the talk is that about 50 developers have access to wordpress.com codebase and can make changes and they do about 100 commits to trunk a day.
Now the interesting part is that every commit to trunk is an actual deployment to the live platform. And it’s super crazy fast. It takes 8 seconds for them to deploy WordPress.com to 3 datacenters. Note 100 commits equates to 100 deploys a day. And they don’t have a QA team, a testable environment or a stage environment. Crazy if you ask me but apparently it works for them. They serve hundreds of billions of pageviews and manage to keep the platform stable.
When asked Nikolay explained that it’s a much better strategy for them than going into 2 weeks of merging nightmares where all new changes are merged into a stable branch. I think that merge nightmares is as extreme as ninja deployments from trunk. I do believe in a balanced approach and think we’ve managed to achieve it at AOL with our own projects.
A Different Approach
We use an internally made tool which tracks on top of SVN all the changes made to different branches and allows to easily move those changesets from one branch to another. With every project repository we have three branches: trunk, testable and stable. Once a developer wants to make a new commit he would commit with a comment like this: “#123 > comment message” and this will assign a commit to a specific ticket number in our ticket system and do the commit. If a dev needs to make 10 commits he would do all of them against the same ticket number. Once he’s done he uses the internal tool to mark the set of changesets he made as resolved.
This is where the QA’s can now take all of those changesets and try and merge them into a testable branch when they feel they’re ready to test. They again do it via our internal tool. The smart thing here is that the tool detects all possible conflicts by dry running the merge and warning you which tickets conflict with which tickets. 95% of the time if conflicts happen is because people try to merge newer changesets first rather than merging older changesets first. Even then a lot of times it’s possible to merge ingnoring the conflict which does not cause any trouble later on.
We try to maintain discipline and push things in the order they were developed. Still conflicts do happen. It’s unavoidable. But for that we have a separate tole: a release manager. Who is responsible for solving these merge conflicts and usually they’re very minor, they quickly catch a dev responsible for the changeset and work it out. The release manager is also the guy who controls what goes into stable and then deploys to live with a click of a button.
Before we had this tool we lived in the nightmare merge world. But no more. We’re actually managing to deliver continuously deploying few times a day. It also allows our QA’s to have a controlled environment with only the changes they want. Yes it takes an extra role but that’s a minor cost for us considering the other two extremes. I believe this is a much more balanced approach that can and does make both the business owners happy and the developers less suicidal.
p.s The tool described is developed by one of our developers and last time I checked he seriously considered to make it opensource but want’s to polish it a bit further first.
There’s a lot of confusion over pair programming. It’s been widely known for a long time and there are a lot of famous companies such as ThoughtWorks actively using pair programming but on the other side there are still a lot of people not knowing what exactly pair programming is, how it works, what are it’s benefits and downsides. The greatest resource on the matter so far that I’ve read is Stuart Wray’s paper for the January 2010 edition of IEEE Software Magazine entitled “How Pair Programming Really Works“. I really enjoyed reading this article because of it’s scientific approach to the problem.
The main benefits of pair programming are these:
- Communication. While developers explain software problems to each other they often suddenly experience enlightenment and find the solution they were looking for.
- Noticing details. Experiments prove that focused people can miss an elephant in the room. Pair programming partners are usually very helpful to notice various details. For example noticing typos in the code.
- Following code standards. Developers tend to follow best practices more when they work in pairs.
- Expertise judgement. Working with another person in pair is one of the best ways to judge expertise and productivity.
The downside of pair programming is that developers get burnt out. On one hand it forces developers to keep working instead of reading blogs and emails, but after a while developers might get mentally tired and become counter productive. It’s important to allow developers to have some “slack time” if they need to and do some work solo.
ThoughtWorks made a great presentation on how they use pair programming on one of their projects. I highly recommend watching it.
Lost Art of Simplicity by Josh Holmes was the keynote talk at the PHP UK 2010 conference. I found it to be an interesting talk with lots of good advice. While listening to Josh I was able to identify myself in the past participating in all the common software development pitfalls. I would like to share what I consider to be at least some of the most important points from the talk:
- Work with your users. Focus on them and their exact needs. As developers we often tend to forget that actual users will be using our systems. We should stop and think is what we’re doing going to fulfill the actual needs of our users.
- When deciding which tools to use for a particular problem or a project always carefully weigh all the benefits and downsides to pick the best tools for the job. If for example most of your company’s software is written in PHP and is using MySQL doesn’t necessarily mean that you should keep doing so. It might be that another language such as Python or another type of a data store such as CouchDB might be a better choice for your next project. Developers also like to play with new shiny experimental toys but it doesn’t mean that it’s the best idea for your company to use it for a particular problem.
- Do the simplest thing possible. As Albert Einstein once said “Things should be made as simple as possible, but not any simpler”. “Cleverness” might not always be a good solution. Complexity involves more moving parts and more possibilities for things to fail. As developers we tend to think about possible future developments. While it is good to do so it is also important not to over do it. While it may be reasonable to believe that a different caching mechanism might be used for a project that you work on it’s less likely that another database vendor will be used in the future.
- Invented here syndrome. It is very likely that any problem you will have will be already solved by many other people before you. If instead of inventing your own solution to the problem you can use someone else’s tools by all means do so. Not every tool might do exactly what you need, not every tool might seem trustworthy enough but there’s no excuse for not trying to find the best available tools.
If you are interested to learn more take a look at Josh’s blog where presentation slides and a full transcript is available.
This is my summary of PHPNW09 conference that I was lucky to attend. This was my first real conference and I was blown away. Talks that I enjoyed most are the keynote about the uncertainty principle, Lorna’s talk about the Joel Test and Rob Alen’s talk about project management. It was also very interesting to hear about the state of the PHP project and it’s internal development teams. Did you know that PHP has only about 100 active developers of whom only ~10 are core developers?
The event itself was perfectly organised. I don’t have a single complaint. Timings were perfect and don’t get me started about the food. It was delicious!
I also had an epic opportunity to see how Microsoft fails to demo their flowchart software which was highly amusing. Though I feel highly thankful to these guys because they were the major sponsors of the event not to mention their help on PHP windows builds.
In the evening we were invited to a SUN sponsored bar where I had an opportunity to meet and chat with really interesting people. Met a PHP star Derick Rethans, had a really great conversation with the event’s organizer Jeremy Coates and even met people from my own homeland.
Finally came to my senses to update the blog’s appearance and add more readability. Hopefully new content will follow. As much as I enjoy writing every time it’s a struggle to start.
To not make this post a shallow rant if you are interested in domain driven design check out Greg Young. I believe he has some very interesting insights towards domain driven design. Honestly I think he’s a software prodigy. I especially enjoyed few of his talks:
I’ve been using Windows as a development platform for more than three years now. Couldn’t say I find it always productive, but I also wouldn’t say that it is very troublesome.
I have been a Linux user for a few years quite a while ago. Tried debian, redhat, slackware and gentoo. Went through the pleasures of compiling kernels, trying to enable the right audio drivers, not being able to make my ATI video card work, experimenting with Wine, going through a guide to setup hibernation, trying to set the right opacity for my terminal screen. I would dare to say Linux systems were still in dark ages. It was challenging to get everything right and have all the shizzle that Windows users had by default. At some point I just couldn’t be bothered anymore and started using Windows again.. Next, Next, Finish.
And Windows is great. Up to a point. First you get all the default stuff taken care of like for example enabling a printer over network, plugging in a new USB device, setting up hardware drivers, sharing files. Setting up a development environment is as easy as downloading Xampp, an editor of your choice and you can start whipping some source code. And Cygwing helps a lot by delivering a lot of every day use tools to a Windows based platform.
Until you hit the rocks. For example a famous Xdebug PHP extension has problems working with Windows Vista and will often crash PHP processes. Extensions like ffmpeg-php are not maintained on Windows and are only available on Linux and it makes matters worse when you for some reason can’t do without them. Or for example good luck developing Drizzle on windows and building it using Cygwin, when some networking library just won’t compile. Suddenly you realize that your whole career is built on top of opensource tools which most of them were built and are maintained on Linux systems.
That is why I’ve decided to give Linux another go. I have selected Ubuntu Jaunty 9.04 to carry on my experiments. Here follows my list of pros and cons of using Ubuntu as a development platform.
I’ll start with cons:
- The latest version of PHP is 5.3.0. Ubuntu package management system offers 5.2.6. I found this a bit dissapointing. I really don’t want to be bothered to compile PHP or to search for 3rd party packages. I understand the philosophy behind this, but it still saddens me as a developer. Especially when PHP 5.3.0 builds are available on Windows as next, next, finish packages.
- Same goes for Eclipse IDE. Not only there were no packages for Eclipse 3.5 but I had to download Eclipse myself, find out which other dependent packages are required (like Java runtime) and then follow someone’s guide to make it work by passing magic parameters to the launcher.
- My favorite broswer Chrome is not available on Linux. There is ofcourse Chromium which still has problems with Flash and Printers.
- Trying to set up dual screens was a bit troublesome. Ubuntu couldn’t identify the best native resolution for my external display and I had to find out how to add the resolution myself. Not to mention about setting which display is primary and what is the location of the other display compared to primary one. It’s still a complete mistery to me.
- Configuring apache. Don’t get me started. How to start apache? Where’s the main config file? Oh it’s different from Windows! How to enable mod rewrite? How to add a virtual host? Had to learn about the a2* utilities familly to solve my problems. It’s easy when you know how they work and that they exists, but if you don’t …
- When my laptop suspends and recovers it has problems accessing samba network shares. Still not solved.
- What is the shortcut to go to Desktop? What is the shortcut to logout? Was hoping it would be the same as on Windows. It’s not. Though it’s not a big issue.
- Ubuntu has no nice default screensavers (joking)
Enough with the bashing. The pros:
- Superior speed. Starts a lot faster that Windows. Especially if compared to my Lenovo laptop which comes with a lot of preinstalled crap applications which I didn’t want in the first place.
- Lot’s of problems solved. Audio, USB, printers, network sharing, video playing just works.
- Amazing package management solution. Whatever you need, just search and install. And you are sure the packages are clean from viruses (hopefuly)
- All opensource tools are available. When a package is not available it’s possible to find a 3rd party build or build it yourself. Helps a lot when you need that one magic extension.
- A lot more easy to set up a development environment than it was before. I have never installed phpmyadmin that easy.
- Virtualization is easier than ever. You can even have windows applications running along with Linux ones.
- Some applications are more well built. Like Skype for example allows me to disable contact request spam notifications. Which is a huge problem on Windows nowdays.
- Completely FREE.
- Looks nice! Has lovely eye-candies! The Cube!
So far that’s my experience. I’ll keep using Ubuntu at work seeing how it goes. My main wish for Ubuntu is for it to be 3 times more faster than it already is. Just like Chrome.. All in all I must say Linux desktop has advanced a lot further than expected by me. I would highly recommend it for schools, universities and home users who don’t play games.