Simple Software|Haider Sabri’s guide to painless coding.

Seems like a really cool way to build a very customized RSS feed. Check out Yahoo! Pipes. There is also a need video that shows how easy it is to set up a pipe.

Found this on my boss’s blog. Thought it’d be useful to anyone reading.

http://sixrevisions.com/tools/20_web_development_tools/

Although it is fun and dandy to do all development, deployments, and testing locally on our development boxes or, even better, within a VM on our dev boxes, all of us know that eventually when our proof of concept becomes a real-life project where we collaborate with other team members, show off the betas to clients, and prepare for production launch, we need to venture off into source control land, dev servers and stage builds.

Those of us who have used CruiseControl.NET know how lovely it is to just check-in your code and see it appear on the dev or stage server in minutes. We also know how embarrassing it is to break the build. This process is known as Continuous Integration. The famous Martin Fowler has written a bit about Continuous Integration. I recommend those who are interested to read that article.

Recently I’ve decided to try a Continuous Integration approach using Team Foundation Server 2008. Since our source control environment is entirely TFS, it would make sense that the integration process could come directly out of the source control system we use.

Assuming you have a TFS server setup to handle builds, the process is pretty easy. For details on setting up the build server itself, please refer to Managing Builds with Team Foundation Build. Another assumption is that your TFS service has access to the servers and paths you are trying to deploy to.

9 Simple steps to TFS continuous integration

1. 1. Go to TeamExplorer. Go to your TFS project. Right click on Builds and click “New Build Definition”
   2. Under the General tab, you’ll name your Build Definition (e.g. FooBuilder).
   3. Under Workspace, you will define the source code that you want to build.
   4. Under Project File, you select a spot within TFS to store your build script. This is important as we would like to modify this build script later on to make deployments automated. We’ll name it TFSBuild.proj for now.
   5. Under Retention Policy, you can configure how long you would like your builds to be stored based on their success level.
   6. Under Build Defaults, you need to set up your build agent. Typically this would be done for you by your TFS admin. If not, you’ll need to create a new build agent, set the computer name of the build server. You’ll also need to set the working directory. Something like C:\Builds\$(BuildDefinitionPath)would due. You also want to set the Agent Status to “Enabled”.
   7. Under the Trigger tab, you can set how you will like your builds to work. If you want a build to occur every time code is checked in, select “Build each check-in”.  You want to be careful how this is setup, especially if there is a large team where people may check-in un-tested code.
   8. At this point the automatic build part should be in place. To integrate deployments into your automation, you need to checkout and open up that TFSBuild.proj file we spoke about in step 4.
   9. At the bottom of the script, add this MSBuild command and check in the file:

<Target Name=”AfterDropBuild”> <Exec Command=”xcopy /y /e “$(BinariesRoot)\Release\_PublishedWebsites\[INSERT_PROJECT_FOLDER_NAME]” “\\[INSERT_UNC_TO_DEPLOYMENT_FOLDER]“”/> </Target>

XCopy basically copies all the output files made by your build script to the appropriate folder.  The great thing here is only the files necessary to run the application will be deployed. Your .cs, .csproj, etc. files wont go to your deployment environment.

After you check-in the TFSBuild.proj file, you should have automated builds and deployments ready to go when you check-in your code, or if you queue up builds yourself. Good luck.

I had the pleasure of attending my first MIX conference last week. I never thought that at my first time at the conference, I’d actually be a presenter. I remember the first time i went to a different Microsoft conference, PDC, where I attended the presentations of renown technologists and wondered if I’d ever be up on stage. Well, i had the honor of being invited to present due to my roll on the MySpace Developer Platform REST API.
I was first approached by the REST API Manager/Visionary, Paul Walker, in mid-January about the prospects of co-presenting at MIX with him. Without hesitation, i accepted but had no clue what he wanted to present, and when we would find the time to prepare for the presentation. After all, we were in the middle of the release of MDP, and i was about to have a baby. Nevertheless, the opportunity was too great to pass up. It was mid-February and Paul wasn’t even sure he wanted to present. In the end, I was able to talk him into it, but a day later my wife went into labor and i left the earth’s orbit for at least 10 days..,
Well, to make the long story short, I found out that I’m going to be the only presenter, and the MySpace team wouldn’t be able to make it. Nervous as i was, i began to doubt whether to go through with it or not; i hadn’t seen the slides until the day i flew out to vegas, all the WCF guys were expecting a large MySpace presence, and I’m was just getting back into orbit. Anyhow, I eventually decided to go through with it, and Aaron Sloman, CEO of speakTECH (and my current employer) came to the rescue to help with the opening of the presentation. After no sleep, frantic demo development, and pathetic practice sessions, the 3 pm deadline approached. We were pulling out slides, adding new ones, and just hoping that our prod environment for the demo would not send back a cryptic error just by visiting the default page. Up on stage, Aaron and I looked at the MySpace API tool we were supposed to demo, and it was failing to return the request. So we had to improvise.
Aaron had a great opener. At the very first MIX in 2005, Aaron presented Vista gadgets using MySpace photos. In the audience someone shouted, "open up your API." A few years later, Aaron was back at MIX announcing that MySpace API, albeit only 6 months after development started on it.

I then took over with the technical stuff. I spoke about the principles of REST, and how an API using RESTful services made sense to us. Then I jumped into how WCF actually implements RESTful services. I genuinely believe our API is the first of its kind. That is, its the first fully RESTful service built upon WCF. We actually started development with WCF 3.5 beta 2 out in August. The bits we needed for our API were not RTM until December, when we already reached critical milestones in the API development. Add to that the total absence of documentation, we were able to impress the internal WCF team with what strides we were able to take WCF to. Some of the cool features created were custom channels that could be turned off and on real easily. These channels would effectively intercept messages high in the call stack to do specific functions on incoming requests. Our demo showed off two custom channels: OAuth and HighLowREST.
The OAuth channel provides a layer of authentication checking per the newly adopted OAuth standard that is currently being flaunted on the web.
The HighLowREST channel is a bit more complicated. For those familiar with REST, they know that HttpMethods are the vehicle of all requests, and that PUT and DELETE are two valid Http methods. Many clients out there, however, do not support PUT and DELETE calls simply because they haven’t had common usage for the past decade or so. In order to bridge those "Low-REST" clients into our "High-REST" service which supports PUTs and DELETEs, we had to add a custom channel to make the service agnostic to that complexity. More details in the video though :).

We also added cool http-like exception handling. You can now throw a ResourceNotFoundException or a BadRequestException anywhere in the code, and it will transform to the appropriate http status code on the reply (i.e. 404, 403).
I am definitely leaving out much more of what we did in our demo, but the good news is that we made it available for people to download. The theme adopted by some of the MySpace guys on the presentation was a RESTful Chess API where you can PUT chess moves, and GET game moves, etc.. Get the source code here.

The video for the session is also available online at visitmix.com, or you can just get it directly through here. 

All in all, the presentation went well thanks to all the help and effort that went into it. The WCF evangelist Vittorio Bertocci was more than helpful and patient with us. He also blogged about it on his site.