Rob Reynolds - The Fervent Coder : Agile, Development

AppHarbor - Azure Done Right AKA Heroku for .NET

Rob Reynolds — Wed, 16 Feb 2011 12:49:23 GMT

Easy and Instant deployments and instant scale for .NET?

Awhile back a few of us were looking at Ruby Gems as the answer to package management for .NET. The gems platform supported the concept of DLLs as packages although some changes would have needed to happen to have long term use for the entire community. From that we formed a partnership with some folks at Microsoft to make v2 into something that would meet wider adoption across the community, which people now call NuGet. So now we have the concept of package management. What comes next?

Heroku

Instant deployments and instant scaling. Stupid simple API. This is Heroku. It doesn’t sound like much, but when you think of how fast you can go from an idea to having someone else tinker with it, you can start to see its power. In literally seconds you can be looking at your rails application deployed and online. Then when you are ready to scale, you can do that. This is power. Some may call this “cloud-computing” or PaaS (Platform as a Service).

I first ran into Heroku back in July when I met Nick of RubyGems.org. At the time there was no alternative in the .NET-o-sphere. I don’t count Windows Azure, mostly because it is not simple and I don’t believe there is a free version. Heroku itself would not lend itself well to .NET due to the nature of platforms and each language’s specific needs (solution stack). So I tucked the idea in the back of my head and moved on.

AppHarbor Enters The Scene

I’m not sure when I first heard about AppHarbor as a possible .NET version of Heroku. It may have been in November, but I didn’t actually try it until January. I was instantly hooked. AppHarbor is awesome! It still has a ways to go to be considered Heroku for .NET, but it already has a growing community. I created a video series (at the bottom of this post) that really highlights how fast you can get a product onto the web and really shows the power and simplicity of AppHarbor.

Deploying is as simple as a git/hg push to appharbor. From there they build your code, run any unit tests you have and deploy it if everything succeeds. The screen on the right shows a simple and elegant UI to getting things done.

The folks at AppHarbor graciously gave me a limited number of invites to hand out. If you are itching to try AppHarbor then navigate to: https://appharbor.com/account/new?inviteCode=ferventcoder

After playing with it, send feedback if you want more features. Go vote up two features I want that will make it more like Heroku.

Disclaimer: I am in no way affiliated with AppHarbor and have not received any funds or favors from anyone at AppHarbor. I just think it is awesome and I want others to know about it.

From Zero To Deployed in 15 Minutes (Or Less)

Now I have a challenge for you. I created a video series showing how fast I could go from nothing to a deployed application. It could have been from Zero to Deployed in Less than 5 minutes, but I wanted to show you the tools a little more and give you an opportunity to beat my time.

And that’s the challenge. Beat my time and show it in a video response. The video series is below (at least one of the videos has to be watched on YouTube). The person with the best time by March 15th @ 11:59PM CST will receive a prize.

Ground rules:

.NET Application with a valid database connection
Start from Zero
Deployed with AppHarbor or an alternative
A timer displayed in the video that runs during the entire process
Video response published on YouTube or acceptable alternative
Video(s) must be published by March 15th at 11:59PM CST.
Either post the link here as a comment or on YouTube as a response (also by 11:59PM CST March 15th)

From Zero To Deployed In 15 Minutes (Or Less) Part 1

From Zero To Deployed In 15 Minutes (Or Less) Part 2

From Zero To Deployed In 15 Minutes (Or Less) Part 3

Herding Code Talks About Nu

Rob Reynolds — Fri, 27 Aug 2010 06:22:58 GMT

Dru and I were recently featured on Herding Code Podcast. In the podcast we talk about everything from package management in general to Nubular (Nu) to other package management systems (OpenWrap, Bricks, and Horn, although horn was/is slightly different) to the possibility of Microsoft releasing a package management system. It was a good time and I enjoyed doing the podcast, but the herding code guys start recording at an insane 10:30 PM! I have no idea how I made it through the whole thing and was still able to talk afterwards.

Some highlights:

There is a lot of talk in the beginning about package management in general.
Basically, I say the word “basically” way too much.
For the first 16 minutes I think I was teetering on sleep, it was 10:30PM after all. Then after that I start to wake up and sound more articulate.
Big shouts out to all the people in the community that have really been stepping up, and huge shout outs to Nick Quaranto (@qrush), Bil Simser (@bsimser) and Michael Carter (@kiliman).
40:16 – Discussion about what we would do if Microsoft released a package management system
49:34 - “It’s spelled with an N U” - Dru Pimps Nu in the “Pimp Your Code” section of the podcast
Going OT (off topic) 53:11 - “We junk punch audit” - Mentions for RoundhousE and what problems it solves.
55:13 - “At the end of the day it is what it is as long as you bring your A game” - Basically Rehashed and Remixed.

Check out the herding code podcast and notes for more. I didn’t keep track of certain times for interesting bits in the beginning of the podcast, but Ben Griswold does an excellent job on the notes from the podcast.

http://herdingcode.com/?p=272

Do Story Points Relate to Complexity or Time? Response

Rob Reynolds — Fri, 09 Jul 2010 02:24:57 GMT

I was recently pointed to an InfoQ article titled Do Story Points Relate to Complexity or Time? It mentions that some teams estimate by a matter of complexity versus how long in effort something will take. Mike Cohn, who wrote the original post It’s Effort, Not Complexity, makes some very good points into how people should estimate based on how much time a story will take to finish versus another story. Relative effort, not complexity. The argument here is that complexity should not matter if two stories take the same amount of time to complete.

I thought Mike and the article illustrate some very important points. Effort is different than complexity. The InfoQ story mentions:

Dentist - In a BOX!

Mike gave an interesting example where he compares the two backlog items of licking 1000 stamps and performing a simple brain surgery. According to Mike, despite their vast difference in complexity, they should still be given the same story points because they would take the same amount of time.

I am humbly reminded of the humorous video on the right (Dentist – In A BOX!) when presented with this idea of performing brain surgery. The other part of the story that was great talked about story points being a function of effort, risk and uncertainty (link back to Mike’s original comment):

Perhaps the way to say that is that points are a function of effort, risk and uncertainty, or SP = f(E, R, U). (Call one of those complexity if you want; it’s not important.) The idea is that points are an estimate of the effort involved. Risk, uncertainty, complexity, doubt and other things people have mentioned here can be incorporated BUT only to the extent they affect the expected effort. If something is complex but that complexity will not affect the time to implement the feature, that complexity should not affect the estimate—that was my point with the lists of numbers to be multiplied or added.

I do want to point out what Mike mentioned in one of his other comments:

Thinking of points as a function of Effort, Complexity and Doubt is fine. In my reply above to John I just combined Complexity and Doubt into one thing: Uncertainty.

Points are a measure of how long it will take (effort). How long it will take can be affected by other things and those can influence our estimate. The key is to remember and understand that it is always about time–no client ever cares how hard we had to think, only how long it took.

“No client ever cares about how hard we had to think,only how long it took.” What I believe I am hearing is that Mike is not discounting that there is effort in understanding. Thinking, research, and learning time is still effort, and I think a lot of people miss this important point when they talk about effort. The example provided was a doctor versus a boy on the two tasks. What happens if they are the same person and that person is not a doctor? What if it’s you?! In my mind, that makes a better determination of what developers face when estimating a simple problem versus a complex one.

Let’s explore this idea in more detail. What all goes into the effort required to lick 1000 stamps versus perform brain surgery if you had to do them? Sure the effort of actually performing the task is roughly the same, but the effort to learn how to lick a stamp is significantly less than the effort required to learn how to perform brain surgery. And that I believe more accurately represents what we as developers go through.

To further illustrate, where I work, we also take stories and estimate tasks from those stories. With that I have started including ramp up time as part of the effort for my team as developers. A problem could take 15 minutes for me to code. But it might take me 2 hours to understand what it is that needs to be done. That is not a 15 minute task. That is a 2 hour and 15 minute task. And the effort involved was 2 hours and 15 minutes.

Thoughts?