MadZak

If you are a web developer you will obviously know that we have some fancy http verbs hanging around in the specification like GET or POST. PUT is a verb that although seldom used, provides a very distinct way of manipulating the URI. Getting down to the semantics, here's the definition of PUT:

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.

So basically a PUT allows us to create or update a specific URI. PUT isn't really utilized in the standard browser web process for some reason, but it has had a resurgence since the Restful movement began. Here is where the nerd fight begins (i'm guilty of having it as well).

POST has been the defacto method for creating since the beginning of time. Maybe not that far back, but as far as this developer remembers on the web. So naturally people kind of default to this method as for creating things. This is great and it should be this way because reading the definition, this is the verb for creating:

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:

It then goes on to describe common functions like posting article to group, appending to a database, sending data for processing, and the final one is this "Annotation of existing resources;" And this is what I believe to be the one vague bullet point that bring up the fight of POST vs PUT. 

So how do we look at it? Technically it's adding to whatever URI you've given it. Some take that to mean it functions exactly like a PUT. I believe it doesn't. Simplifying the verb a bit, we can understand that POST is append and PUT is replace. The key point here is the PUT action is replacing the entire contents of the URI. On the other hand, the POST action is adding to the contents that are already available at the URI.

Lets dive into a simple example of a restful api around file structures:

== POST ==

GET URI: /api/folder/
Folder
  -> dir1
  -> dir2
  -> text.xt 

POST madzak.txt=text to URI: /api/folder/
GET URI: /api/folder/
Folder
  -> dir1
  -> dir2
  -> text.txt
  -> madzak.txt 

POST madzak.txt=text2 to URI: /api/folder/
GET URI: /api/folder/
Folder
  -> dir1
  -> dir2
  -> text.txt
  -> madzak.txt (text)
  -> madzak.txt (text2)

== PUT  ==

GET URI: /api/folder/
Folder
  -> dir1
  -> dir2
  -> text.xt 

PUT madzak.txt=text to URI: /api/folder/
GET URI: /api/folder/
Folder
  -> madzak.txt (text)

PUT madzak.txt=text2 to URI: /api/folder/madzak.txt
GET URI: /api/folder/
Folder
  -> madzak.txt (text2)

This is how I (and i believe other purists) interrupt the implementations of the spec to behave. Notice how in the PUT if I used the same URI as the POST I removed that whole directory structure. This is because it's a replace not an append. Should you want to add the madzak.txt file to the existing structure you'd naturally use a POST because it appends. You could however use a PUT by changing the URI to be /api/folder/madzak.txt, which you see I did in the update PUT request. This says Create or Replace what's at this current URI. Given that madzak.txt doesn't exist, the implementation could create madzak.txt within that folder.

I'll leave you with my final comments on this topic. Just because the industry follow a certain way, doesn't make it correct. If you want to claim you are truly a restful interface, the spec says you should behave this way. If you don't want to follow the spec then make it abundantly clear in the documentation you using different behavior. Although i find it a bit foolish to write more documentation when you could just follow spec and point to what is already written.

HTTP Spec: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

I think you could call what I did for the last three days a binge of sorts. A colleague and I have started to use campfire in an effort to log communications and keep a steady flow of information going between our now hectic (love you family) and un-sync'd work efforts. Given my strong love for desktop clients, or real apps as I like to call them, I naturally went out searching for a linux client.

My searching didn't take long and I landed what was and will be my upcoming addiction called, Snakefire! Every time I see that name i think of the saturday night live skit about riding the snake with will farrel! Anyway this fancy little app was written by a cool gent named Mariano (http://marianoiglesias.com.ar/). He did some very nice work, although it's in QT at least it's python! I'll just wait until the GTK rewrite :)

So after using the application for a little while, I noticed a few things weren't working and also some missing features, or at least i thought they might be features. Given the code base in good shape, it being on Github, and it being python i thought what the hell... let's do it rather than ask for it. After about an hour, which was mostly spent understanding QT and how it works, i whipped up the ability to hide the join and part messages (ANNOYING!). I worked up my pull request and shipped it off to the master repo. As soon as that was done, I began checking my pull request every 15 minutes.

I was like a little boy on christmas day who sent his letter off to santa and kept waking up christmas eve to see if his request was delivered. Needless to say we were on different time schedules and my 15 minute check up went without a response for awhile but i pressed on, checking immediately as I woke up Monday morning.

It was accepted! HOLY SHIT! I got something into an app and I loved it! It was such a rush of accomplishment i could barely contain my excitement. It was from that moment that I became addicted. This same process occurred later that evening when I fixed the alerting system for gnome/xcfe setups and added inactive notification options. Another pull request was submitted and Github was forced to reset every 15 minutes in anticipation of acceptance.

Again I went to bed and woke up to find it accepted again! Man two of em were taken, i was totally making this product better. Obviously i couldn't stop, and i couldn't just add small features in... i wanted something challenging. So what did i begin working on that Tueday? I re-worked the display panel to be a web view so that images would be inline, hooked up drag and drop image uploading and even auto scrolling. I also paved the way to allow us to style up the conversation window to make it purtty. Like I said, Hooked!

So am I done? Hell no, this is great and Mariano is a great remote development work buddy so we aren't going to stop now. We have a lot in store for this little app and I couldn't be any happier to be apart of it. Keep and eye on it, test it, or add some sweet features to it cause it really feels excellent to give back. https://github.com/mariano/snakefire

Today was an interesting day. I was personally really excited about today because it was Node Day! In the morning I heard talks from some very high profile node community folks which was really awesome. Then Ryan the author of node stood up and explained how 0.50 is going live and it'll have the first cut at a new backend which will allow node to work natively in windows. He showed some preliminary numbers about performance (linux vm was still kicking windows ass of course) and all was good. Suddenly the talk turned into what I hate the most... Microsoft.

A great question was asked of Ryan about what is Microsofts involvement with node and why are they so focused on "partnering" with them. This annoucement came out about 3 months ago on how Microsoft really wants to help a node.js port occur. Helping a language onto a platform is fine with me, it's the underpinnings i'm worried about. If you haven't heard windows is also pushing javascript as the new windows 8 language for applications in it's fancy new touch mode. Suddenly the light clicked on and I made the connection

Ryan dodged the question about Microsofts involvement (I hate jQuery because of this as well btw) and one of this corporate buddies jumped in about how they can't really speak for Microsoft and that the partnership will explain itself soon. Basically a corporate answer. The next part is what really sealed the deal. Given IE's horrible support for javascript and web standards alone i'd figure that most people in the talk wouldn't be windows boys (naive i know). Turns out 2/3's were folks FROM Microsoft and even went on to explain how they are all starting to integrate node into windows software.

I feel cheated honestly. Javascript is such a wonderful language with some emmense power but given the recent trademarking over node, the logo redesign (stupid btw), and now this partnership, I do not feel that this language will be cared for like a python is... by the community. Given this new view, I skipped the last half of the node.js day and switched over to advanced vim. BEST DECISION EVER

I'm actually writing this post in vim and using a python function to send it off to my blog (geek cred +1). I learned a crap load and hopefully i can start becoming a new master in the world of vim and drop IDE's forever. I really hate IDE's as well so it's a natural choice back to a plain editor that has so much hacker potential. Day 3 is 100% python focused which will be awesome, looking forward to the Django talks.

After a quick check in and some nice swag (Thanks OSCON!) I've just sat down in my first session of 2 for the day. The first session on my docket for my 2 session day was HTML5 & CSS3: The Good Enough Parts by Estelle Weyl.

I gotta give Estelle some credit, this topic (for most web developers) are over played out and slammed down our throats every second. This means that walking in i knew 70% of the HTML5 and CSS3 stuff, but her session wasn't built to just tell me what was coming, it was also to show which is where the winning began.

Her slides were interactive demos of almost all of the properties and her snow effect created fully by css was super rad. Although some of the javascript stuff suffered the fate of a dead server, the content was still very well explained. Props to making something boring as heck to interesting and for all the one off tips she gave during the presentation.

Up next was a session i was really looking forward to, Advanced Python. I'm not way advanced but given it was presented by a core developer, I was really looking forward to what I would learn.

Holy crap I learned a lot! Everything from bound methods to how the hell unicode and encoding works and why it's not as hard as we all think it is. The number one lesson that took my breath away was that everything in python are dictionaries. Sure i knew that but you don't really KNOW that until he deletes the class abstraction and asks you to re-implement it. Even talking about it gets me going again!

The day was a grand success and very happy with the lessons I picked, Today is my day of Node.js (YES!) so it'll be super awesome as well I hope!

I've recently upgraded to Xubuntu 11.04 and found that my standard way to install Cloud9 IDE just wasn't working. After doing some digging, These steps seem to solve my problems

1. sudo apt-get install libxml2-dev
2. git clone git://github.com/ajaxorg/cloud9.git
3. cd cloud9
4. git submodule update --init --recursive
5. bin/cloud9.sh

I also created a handy function to load it up with a default workspace if none is given:

alias cloud9='node ~/Development/public/cloud9/bin/cloud9.js'
function cloud9(){
    if [ "$1" == "" ]; then
        cloud9 -w ~/Development
    else
        cloud9 -w $1
    fi
} 

It's completely true that when a developer hears the phrase "Code Review" they tend to get a bit nervous. I know because I was that exact developer a few months ago. Although my story and progress through the world of reviewing is a bit unique, mostly thanks to the wonderful peers i'm involved with here at work, the feelings and outcome from the process can surely be felt across the development world. So let's get into my story...

About 4 months ago we began to have bi-weekly code reviews to make sure we are always thinking out our approaches vs just coding. At first, these things were so horrible at times it felt like watching a car crash or being in one! The most traumatizing review was when my code was laughed at and a little bit later, "Wow, this is shit" filled the silence in the room. This is a little overboard and not everyone's experiences will fall the same, but the bottom line is that most developers don't have the stomachs to watch their work get criticized. 

It took me 5 reviews like the one above to realize that "it was just business" and not something personal. I tend to consider myself an artist of code and the product I deliver is my own creation which has my name all over it. Given this approach, which most developers have, we naturally defend the hell out of it. The problem with defending is that you are closing your inputs and assuming you are the only person who could solve such a problem! Any developer will tell you that there are millions of ways to solve a problem, but we don't like to accept that someone else discovered a better way. I believe that the inability to open our minds to the view of other developers is the crux to code reviews and is exactly why they are stress inducers amoung the community.

I can say from personal experience that hardcore reviewing has made my code, and my general approach at newer problems, a millions of times better. Letting go of the "my art and you don't understand me" approach has opened my problem solving ability to many diverse paths. I spend more time now in figuring out what the best approach is than coding. This is mostly because i know if I don't have a good explanation for the choice, it will get eaten alive at the review. I also learned that my peers aren't here to trash code, they are here to make it better.