REST vs SOAP

For the Advanced Analysis and Design course at my university I have to compare REST with SOAP. My first reaction as I heard this was WTF. How is it possible to compare a strictly defined protocol with an approach idea like REST. I don't know if my professor doesn't understand the concepts of both or if this is the realization he wants us to get. For the people that don't know the difference here a little rundown. SOAP stands for Simple Object Access Protocol and was initially designed to call functions/methods on remote machines (basically RPC shredded through the XML buzzword machine) whereas REST stands for Representational State Transfer and describes how the resources in the internet can be arranged and talk to each other. Mainly described by the example of http. Of course you can use both methods to get data from some source (Amazon for example) but the general ideas are so fundamentally different that a real thorough comparison is not possible. Sometimes I do wonder. If you would only read http://en.wikipedia.org/wiki/SOAP and http://en.wikipedia.org/wiki/Representational_State_Transfer you would understand my point. That simple.

Flamewar commence:

How much money can I make with my domain

I just had a look at http://www.thenetinfo.com and that tells me that my domain is worth:

Ribalba.de Estimated Worth $88 USD

Wtf. Who would give me that money. Really. And all the other sites I tried it just doesn't give you any info at all. Ahh wait

Stallman.org Estimated Worth $5.8 Thousand USD

and

Microsoft.org Estimated Worth $292 USD

So really who would belive such a thing?

The problem with google analytic when you run your own server

On my website www.ribalba.de I run google analytic which lets me see how many people look at my website where they come from and what they are looking for. Not that it really matters but I am just interested in why people would want to read about me. Assuming I should only be interesting for about 50 (+/-) people in the World. But I also run some analyzers on my web server log files and it turns out that the main thing my server is doing is serving files I have outside of my wiki (which I use for my site) they are files that I just have in folders and that can be accessed through directory listing turned on. But these are never accounted for in analytics. So if I direct my browser to http://www.ribalba.de it will be saved in analytics but when I goto http://www.ribalba.de/geek it does not. So in some respect analytics is giving me a wrong picture. Further image downloads from my server are not displayed. So not really useful as you are forgetting a huge junk of data and so your analysis of your site is bound to be wrong.

wrong start data => wrong conclusion

Maybe Google should offer a method by which I can upload the log-files after logrotate has run and so the file is not used anymore. So always take with a grain of salt what google is trying to tell you.

libnice for CentOS

Some guy on the CentOS mailing list needed libnice so I built it. It can be downloaded from:

http://www.ribalba.de/geek/port/

The source package is in the src folder and the builds in the respective directories.

I hope this helped some poor sole :)

Just for your inforamtion:

GLib ICE implementation

libnice is an implementation of the IETF's draft Interactive Connectivity
Establishment standard (ICE). ICE is useful for applications that want to
establish peer-to-peer UDP data streams. It automates the process of traversing
NATs and provides security against some attacks. Existing standards that use
ICE include the Session Initiation Protocol (SIP) and Jingle, XMPP extension
for audio/video calls.

Why being nice pays off

I have lived in London for little more than a month now. My daily routine includes getting the tube to Uni and on the way I pick up my morning reading normally a Financial Times, a Guardian and a bottle of water. I do this pretty much every morning. So I spend quite a lot of money for this if you take it time 365. At my tube station I can choose between two news-agents that sell papers. As I am coming from the right I naturally always went into that one. And I never though much about it. It is owned by a family (it seams) and the people that work there are not rude but they are not friendly and helpful. After going there for a month they still didn't know what I was getting. In the morning when I am quite grumpy the last thing I really want is someone to be grumpy back at me. But I just accepted it and continued buying my stuff there. Four days ago I came from the left so I thought why not try the other shop. And what a difference, I was greeted really friendly and I had a little chat with the guy behind the counter. The next day I went to the left one agin and the same guy was friendly again. Now after just four days he already knows what time I normally go to university and of course the papers I buy. It never occurred to me that in a world where prices are pretty much fixed friendliness is one of the last selling points. Location might be important too, but these two shops only differ in the staff. They have the same stock and same prices and pretty much the same location. So the reason I choose the left one is because I am treated in a friendly way and people remember me. This might sounds stupid but I bet you have all done it. If someone treated you in an unfriendly manner you would say to yourself "I am not coming back" and if someone knew your face after entering a shop three times you felt sympatric with that guy.

So what can we learn out of this for IT. In the IT ecosystem prices are quite fixed too and location is becoming even more irrelevant. So maybe friendliness is a major point. Maybe your costumer will chose you the next time because you remembered him, like I take the little hassle of walking one minute more every morning just to be treated nicely. If you are a freelancer this is really important, in my opinion, as at the end of the day you are not much more than the news agent competing at a train station. Just you are competing with 100000 other shops and not one.