5 Agile Project Management Techniques You Can Start Using Today

Awesome post from "Joel from Canada" (I did not know that Mark Twain is the grandfather of Agile)!



And #1 is: "Don't call it Agile" - that's what she said :)

And yes, I know that I am slow to catch up.

A story of Google Nexus 4 adventures told in RIM stock prices

Chart may contain liberally interpreted data :)

You have no time

I intended to write a post about an evolution of "cool kids" in IT industry. You know: how they used to be - you could only be observing them from afar because what they did required far more knowledge and training than you had (like being an Olympic champion, voodoo master or writing Assembler-360 voice-recognition systems). And how they are still so far away now, doing what you don't dare, because you are too busy earning money, building your resume or indulging some time-consuming habits like muscle-growing or soap opera watching. 
Inspirational people from Toronto Code Retreat can show you that the other word can exists and cool kids are just around the corner. I am procrastinator and can account for a dozen of "what if" moments every year of my life. And it is OK if you have plenty of time ahead of you. Like if you are 7 years old. Right after that you get too old for this shit, you have no time. We have no time. We should be out there starting and failing new enterprises, being laughed at or patronized at user groups and enjoying every moment working with great people who are capable of amusing us every day.
So get up and do fun stuff. I will follow, I am just a bit tied up at the moment earning money and worrying about my diet.

Building specification-compliant RESTful interface. Part I - WebAPI.

The best thing about the latest Microsoft trends starting with MVC1 is the turn back to the HTTP roots. I came to web development through ASP.NET 1.0 WebForms which successfully shielded me from all these response codes, charsets and headers. With MVC I had to understand how the HTTP actually works (RTFM finally!). WebForms mindset has pretty much locked me out from the cool "third-party" concepts. It is much easier to understand Ajax (not in the form of the UpdatePanel) or Node.js after been exposed to ASP.NET MVC.
But enough of that and let's get to our interface.
For implementation to be HTTP spec-compliant you should supply appropriate header values and status codes to the responses returned from you MVC actions or Node.js methods and throw nice HTTP-compliant exceptions if something went wrong.

Below is representation of API interface tied to HTTP method with a URL sample:

Create a new entity	POST	/myservice/locations
Retrieve entity (by Id)	GET	/myservice/locations/1500
Update an entity	PUT	/myservice/locations/1500
Delete an entity	DELETE	/myservice/locations/1500

The client-side code for both WebAPI and Node.js consumer is the same:

    function Add(json) { 
        $.ajax({ 
            url: API_URL, 
            data: json, 
            cache: false, 
            type: 'POST', 
            contentType: 'application/json; charset=utf-8', 
            statusCode: { 201: function (data) {  model.Sale().Id(data.Id);  }  } 
        }); 
    } 

    function Update(id, json) { 
        $.ajax({ 
            url: API_URL + id, 
            data: json, 
            cache: false, 
            type: 'PUT', 
            contentType: 'application/json; charset=utf-8', 
            success: function () { //success; } 
        }) 
         .fail(  function (xhr, textStatus, err) {  //failure; });       
    } 

    function Delete(id) { 
        $.ajax({ 
            url: API_URL + id, 
            cache: false, 
            type: 'DELETE', 
            contentType: 'application/json; charset=utf-8', 
            statusCode: { 204: function () { //success; }  } 
        }); 
    } 

  Server-side code in WebAPI implementation:

 private static readonly ISaleRepository repo=new SaleRepository(); 

        public IEnumerable<Sale> GetAllSales() { 
            return repo.GetAll(); 
        } 

        public Sale GetSale(int id)  { 
            Sale item = repo.Get(id); 
            if (item==null) { 
                throw new HttpResponseException(new HttpResponseMessage(HttpStatusCode.NotFound)); 
            } 
            return item; 
        } 

        [HttpPost] 
        public HttpResponseMessage CreateSale(Sale item) { 
            item = repo.Add(item); 
            HttpResponseMessage response = Request.CreateResponse(HttpStatusCode.Created, item); 
            string uri = Url.Link("DefaultApi", new {id = item.Id}); 
            response.Headers.Location=new Uri(uri); 
            return response; 
        } 

        [HttpPut] 
        public void UpdateSale(int id, Sale item) { 
            item.Id = id; 
            if (!repo.Update(item)) { 
                throw new HttpResponseException(new HttpResponseMessage(HttpStatusCode.NotFound)); 
            } 
        } 

        [HttpDelete] 
        public HttpResponseMessage DeleteSale(int id) { 
            repo.Remove(id); 
            return new HttpResponseMessage(HttpStatusCode.NoContent); 
        } 

Some additional considerations:

• Note that there is no error-handling logic in the Controller class to make it more readable and reduce the cyclomatic complexity. All burden of the error-handling is offloaded to the Repository class.
• By default the RC release assumes actions to accept GET or POST requests, so for our Update implementation it would throw the error "The requested resource does not support method PUT" unless the appropriate action is decorated with the good old [HttpPut] attribute (it worked differently in Beta version).
• Bear in mind that Json.NET date converter can accept a wide range of date formats but can fail the default JavaScript one, created by new Date() statement - use overridden MediaTypeFormatter for tough cases.
• Mike Stall's post is the best so far I found which in brief format describes WebAPI's intestines.

Next I will be looking into the Node.js implementation, which should be a bit more straightforward.

also check Feed Burner

Expelled: No Intelligence Allowed (metaphorically speaking)

Have you ever seen companies which are in the growing mode and looking for a way to formalize their development process? Usually it is described as "bringing some structure in" - the management realizes that "cowboy coding" ("Agile" they called it) spontaneously adopted from the very beginning now limits their ability to expand.
Unfortunately Agile is often perceived as chaotic and uncontrolled alternative to more disciplined and planned (perceivable) approaches. It could be challenging to convince people that agile team has to adopt very strict rules and rigorously follow them on a daily basis. Enforcing the discipline is every member's duty, while in the more traditional process Project Manager is perceived as a keeper of justice.
With that demand comes another danger for the Agile adaptation: people start feeling threatened - their work (and slack) is exposed and scrutinized. One of XP Toronto presenters said that "if organization (reportedly) went through a change and didn't loose anybody in a process, then nothing has really changed". Sounds rough but seems reasonable. Most threatened are obviously those who hold formal positions of relative power closely working with developers. Take the architect for example. The appointed Architect is constantly challenged to prove his/her knowledge and abilities in order to keep the team's respect. More traditional approaches would allow Architects to barricade in ivory tower and reduce communication to directives. It is Evolution, folks, versus the Intelligent Creation as both theories understand it *.

* N.B. I am in no way taking sides in the actual "Expelled: No Intelligence Allowed" controversy. I have my own interpretation of both theories and keep it to myself.

Coffee Script for the Microsoft Soul

So the CoffeeScript... It looks cool, it sounds cool, it kind of makes sense, it's everything but one - it is impossible to understand how to get started. It literally took me 6 hours before the world has heard my first "Hello". After perfectly designed, scrupulously executed and very visually appealing Knockout.JS tutorials (kudos! kudos!) it was the most bitter disappointment. All resources I went through jumped straight to the code of wicked cleverness and elegance but were missing one tiny small simple thing - to show how the damn CoffeeScript reference syntax should look like in the HTML page!...
I am not that Node.js-inclined yet and  and for long miserable hours I began regretting to belong to an inferior race of .NET developers. Unlikely light shed from IBM: the truly My First Cup of CoffeeScript. At least I've seen some code working.
Now about the tools. At the time I am stuck with Visual Studio 2010 on Windows XP (so no Visual Studio 2012 for me!). "Cool stuff can be done only with cool tools" says I and looks for non-Microsoft alternatives. Unfortunately WebStorm did not work well for me. The code got a proper syntax highlight but that's about it - I couldn't make it compile and community offered me to learn Node.js, command-line tools and Voodoo craft. Thankfully to an  excellent Mindscape plugin Visual Studio 2010 got coffinated without a hitch (did not get highlighting yet). At least now I am finally on the road.

Continuous deployment and stuff - pay attention!

Google's software and especially processes are not under that much scrutiny from the community and it obviously takes its tall. As soon as your code has stepped out of the cradle it is not about how cool and clever it is but rather reliability and what follows. In the long run the process is what counts, and there old dogs like Microsoft beat Google, even if the latter gets away easy where the former is been chewed.
Numerous successes of Google are widely publicized and known. But dude, open seven Chromes, close them all and take a look at your RAM. Or try to engage Google's Account Manager to buy (as in "pay money"!) one of their services. Or build a product which uses one of their Lab API's and then be informed they played with it enough, got tired and shut it down. And they killed Kenny!
Yet another Gmail glitch can speak to the lack of a proper processes in place. The problem is around for almost a week and it is either the product is not that ubiquitous or Google does simply has no capacity to turn around that fast. With the thousands of servers the glitch made its way with all cool tools of the day - Continuous Delivery, Continuous Integration and what-not - sloppy-executed, negligently-tested, poorly-managed.
Hordes of coolest kids can ride their colorful campus on Segways and it does not matter without a good old tiresome pernickety testers and malevolently censorious product managers.

So that's it for!

Twitter! The comprehension of this media of communication eluded me until now. But I finally got what people need it for - accidentally stumbling upon the @KileyCuoco's Twitter (let's say that I was in a process of researching The Big Bang Theory's continuation perspectives). I can see how it could create a feeling of complicity with somebody's life and being a part of some kind of inner

I better go and Tweet this.

Picture courtesy of sustainablejournalism.org