- thy should never waste time in reading about code
- thy should always respect your IDE and carry it all the time with you (in a USB key)
- thy should always find a non-existing requirement in mind and code for it
- thy should never write a comment
- thy should show your karate in all obfuscating syntax
- thy should show no interest in algorithm and its implications
- thy should always be shy away from mathematics
- thy should never test your code extensively; those who do are weak
- thy should write in abbreviation it will communicate more in less characters
- thy should use GOTO always
Wednesday, February 22, 2012
Thursday, February 16, 2012
REST web services will stay. It is a bad thing to predict future of technology. But I am ready to bet on this one. REST will stay. It will stay because of multiple reasons, and today I am going to give you mine.
- REST is simple. You can create a RESTful web service easily. I mean very, very easily. Actually you have been doing it all along if you are in web development. Every page in a web site is an example of REST web services (hold your concern a bit more), the only difference is your client is a web browser.
- REST is succinct. You can do almost everything in REST. If you cannot do something in REST chances are you do not know how to do it yet. It’s succinctness is so powerful that you can do some great magic.
- REST is easy to learn. If you know web development you know rest. If you need to expose your database to the web – you just need to provide a URL (with all query string and HTTP headers). Whatever is running in the background for your web server (or app server) can return the data using JSON or XML. That’s it.
- REST is scalable. If the dang thing supported the Internet to scale to what it is today – it can scale your web site also. Even if you have more data than Wikipedia.
- REST teaches you a lot more than anything else. With other web service standards – you are limited with the framework you are working with. But not with REST. It does not impose you anything – no configuration, no heavy tricks, no non-sense. Follow the conventions and you are there with your service. As it does not have any heavy stuff so it push you to think in simple terms and help you build a system which easy to maintain and consume.
- REST service is ready to be consumed anywhere. I mean as long as your server is reachable. So you need no fancy pant client library to work with.
- REST will stay – you can wash your SOAP away. If you are not with REST of us and with some other stuff. Think about the future where everyone will have a handheld try to access your service. They will have different architecture and software stack which you do not know. You will have to serve data to all of them and your SOAP will wash away.
That’s all I had in my mind. What do you think?