Monday, March 28, 2011

TechTalk Event: What can you develop in 24 hours?

On April 14th my co-worker Thomas will hold a very promising presentation about Rapid Application Development with modern development tools.
He will present the findings from a daring experiment:
"One application, three platforms, 24 hours: Mission Impossible"
They took an existing ASP.NET MVC 3 application and wanted to find out how much of the given functionality can be re-implemented in 24 hours with the following platforms:

24 show goes carbon neutral
Sounds like an epic battle: Rails vs. LightSwitch? If this does not have the potential for an endless flamewar, I dont know what has?
Everybody is welcome, including zealous Rails fanatics and corporate CTU agents ...
The event will be presented in German.
Date: 13.04.2011
Time: 16:30 - 18:00 Uhr, afterwards Apéro und Fingerfood
Where: Technopark Zürich, Technoparkstrasse 1, 8005 Zürich
Register online, the event is free!

Update 2011-04-24: The presentation is available online on vimeo (in german)

Wednesday, March 23, 2011

Interesting: Continuous Integration vs. Feature Branches

In this interview Martin Fowler advises against using Feature Branches, since it is incompatible with Continuous Integration:

So we very much follow the principles of continuous integration, which is not something you can do at the same time as feature branching.
- Martin Fowler

Fowler advises to use Feature Toggles instead of Feature Branches for the development of features that takes longer than a release cycle or features that the business does not want to have released yet.

I should also point out as well I do advocate using feature toggles for features that take more than a release to implement, but it’s only the second best solution in that case. The best solution is to find a way to release the feature’s capabilities incrementally and usually you can do that and people need encouragement to go down that path. And only when you can’t and absolutely can’t should you use toggles.
- Martin Fowler

Screen shot 2011 02 22 at 10 57 24 PM These are interesting concepts and I wonder if they are equally valid for all kind of projects?
I think this advice is mainly aimed for projects with a compact, dedicated team with clear goals that is aiming at striding forward at a sustainable pace.

In open-source on the other hand, I see a flourishing ecosystem of projects where people are working together in a more loosely coupled way. "Social coding" on GitHub is the best example here, where forking and submitting patches is made ridiculously easy.
Here I see the concept of feature branches as a very sensible concept...

Monday, March 21, 2011

Speaking at the Norwegian Developers Conference 2011

Gaspar and I were invited to the Norwegian Developers Conference.

We will hold two sessions:
  • SpecFlow: Pragmatic BDD for .NET
    (hopefully with a guest appearance by Dale of Mono fame)
  • Building .NET applications with BDD

Thanks to Jonas Fellesø and Jakob Bradford for inviting us!

The agenda of this conference is crazy! It is a great honor to speak among so many masterminds of our industry.

Wednesday, March 16, 2011

Tidbits: Microsoft Platform vs. Startups

315116528_480edcad4d.jpg StackOverflow and TekPub were my prime examples for cool sites based on the Microsoft stack. It seems that I have to look for new examples:

We put a lot of thought into this - MS stack doesn't scale for startups.
- Rob Conery, Founder of TekPub

Stack Overflow was known for their Windows stack, now they are using a lot more Linux machines...

Thursday, March 3, 2011

Continuous Delivery, the next big thing?

The cloud is more than just scale, it is also effortless deployment.
- Scott Hanselman, Hanselminutes 255

Kent Beck is talking about Continuous Delivery in Software Engineering Radio 167:
[In software engineering] the big trend is towards more frequent deployment. And that drives everything else: All the social changes that need to happen, the technical changes that need to happen. The changes in practice, languages, and infrastructure ... If you are deploying 50 times a day [...] the current separation between ops and dev has to go away ... Marketing, sales, business models: everything changes when you are deploying very frequently.

Here are two real world examples of continuos delivery:
First check out, scroll to the bottom of the page. You should see something like:
Screen shot 2011 02 12 at 12 53 31 AM
Wow impressive!
EIS0065G pipelines
Then check out the presentation Continuous Deployment to Production 50 Times a Day on InfoQ.
According to that presentation, the applications at get deployed to productions 50 times a day (with peaks of 100 times a day). They have a sophisticated deployment pipeline with automated self-checking and self-rollback of their different production services.

Want to jump on the bandwagon? Get your copy of Continuous Delivery.

Update 2011-11-13: According to this presentation by Zach Holman GitHub deploys 10-40 times a day.
Related Posts Plugin for WordPress, Blogger...