First of all,Wish you a very happy new year! 
Another year down! I will admit, more of the day to day use posts for SMB developers have been lacking , but I hope to pick that ball back up and start again real soon. Here are some my New Year resolutions for this blog:
Here is the “no-fluff-just-stuff” posts of 2008:
Nowadays, you pick up any developer and ask on what they are working on and you will get resonating answer of web development. But hardly half or even less than that knows which version of protocol “web” is running on! [DON'T GOOGLE! (I had did that ) if you do not know, its HTTP 1.1] this also indicates how far the original designers of the protocol had achieved their goal of abstraction and laying out good protocol.
HTTP means Hypertext Transfer Protocol. The name itself sums up the web into it. Web is all about Hypertext [linked text] and data transfer from to and fro in its basic sense. We had gone further with HTTP, adding tons of things.
For any web developer/programmer, three things hold most prominent importance apart from his/her dev platform/language and these are the basic pillars of web. These are namely,
1. HTTP Protocol
2. Web Server(IIS, Apache, JBoss etc)
3. Web Clients(mostly Browsers like Internet Explorer, Firefox, Safari)
So understanding these basics is of prime importance. In this post, I am going to only focus on HTTP and limiting my scope to what fraction of knowledge that is essential (read assumed to have) for every web developer.
HTTP can be thought of as a communication system. Somebody calls up (Request) and somebody replies (Response) and yes the acknowledgments.
This basic nature of HTTP itself defines the existence of two types of programs that we had seen on the above list.
The program which calls up the fellow program at the other end is termed as web server and the programs which replies back is termed as web client.
These programs had mutually decided how to talk and via which language. This is our beloved and long standing man, HTTP.HTTP basically does not hold up the info with it about previous requests and its use. This is called “state”. I had talked to many developers who talks about HTTP being stateless protocol but they, surprisingly, unable to explain what it means.
This stateless nature of HTTP passes the worry of maintaining state to its both end programs that is web servers and browsers and here concept of state management takes its birth and becomes necessity of any server side platform. We will see the state management in detail in following posts.
Now, coming back to HTTP world, the talk between web server and browsers happen through commands. You must be well aware of GET and POST but there are also more to them.
Wikipedia has good explanation for all of these commands. You can refer to it here.
Now, we’ll see most interesting part of HTTP which is related to most of the developers i.e. error codes that HTTP provides.
You must be familiar with 403,404 numbers and those yuck ugly pages shown to your face by your browsers. (To those who are into browser development, why can’t you put those system-error pages to some nicely formatted pages which are meant for HUMANS, everybody is not geek 
) .Anyway, have you ever thought about what it means and why those numbers are given in such fashion. Well, for that we need to delve deeper to history of HTTP. I am not adding yet another story to this post but if you are interested you can read the whole story about error codes especially of Room No. 404 at this site.
Now I want to conclude this post stating the meanings behind codes that are transferred to browsers.
1XX=Informational codes
2XX=Request Success Codes
3XX=Request redirection Codes
4XX=Client Error Codes
5XX =Web Server Error Codes
Hail! How I can I forget this? If we are talking about Web and HTTP then we always have to take one name. Yeah, Tim Burner Lee who is regarded as “The Father of Internet” or what we call as web. You can visit his homepage here.
Recommended Read:
1. World Wide Web consortium
2. RFC 2616
http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html
3. Wikipedia
http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol
4. Room 404
http://www.room404.com/page.php?pg=homepage
5. HTTP Pipe lining
http://www.mozilla.org/projects/netlib/http/pipelining-faq.html
Just realized that this is going to be my 50th post! It’s kind of a milestone for me. So, I thought to write a good post on this occasion but wait a minute! Rather than posting some serious ga-ga, the craziness bug bites me and here I am just celebrating this with YouTube!!
Many people in corporate world think that You-tube is not for programmers, developers or who that are involved in software. Since, Software development is serious, but what they miss is techie people also love to enjoy their craftsmanship and off course, they do it in their own style. In fact, some companies go to the extent that they block the YouTube. I know there are some, hiding between us and because of them, their unprofessionalism, everybody had to lose the good value that is coming out of YouTube and other social sites.
I usually surf YouTube for some good stuff like Google Tech Talks as well as Google Developer days as well as Thought works events like this.
Apart from all that stuff, I also enjoy code-monkey variations that are created by so many people out there. Today, also on this celebration here I am presenting the Programmers song, Hope you will enjoy these as you enjoyed reading out my blog.
also enjoy damn crazy variation from Roy from PDC
After this celebration, am going to put future direction of this blog.
1. Changing the direction from to-fro writing to much disciplined and focused writing.
2. Now onwards, you can expect more technical day to day stuff like web development, programming problems, tips and tricks, tools and some insights.
3. More posts about solving the problems of SME/SMB developers.
4. More posts about how to optimize operations function in SMB.
I think this agenda will keep busy for another milestone.
I know that there is a long way to go and this is just a humble beginning…but we have to believe, CHANGE CAN HAPPEN.
So, stay tuned
Code comments are for those who either can not read the code or whose code can not be read.
-Lalit.
Quality is never an accident;it is always a result of high intention,sincere efforts,intelligent direction & skillful execution,it represents the wise choice amongst many other options.
“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away” – Antoine de Saint-Exupery.
Engineering Factories, manufacturing plants had always fascinated me since childhood. In my childhood, I had made several visits to the thermal power plant where my father works. The plant is open to families of people who are related to plant on the festival of Dushehara every year. I am still having very fond memories of those days. In my engineering years, I also had visited the Bosch plant which is near to our place.
Both plants are strikingly similar in many respects. They had some sort of control rooms through which they manages manufacturing process or power generation turbines. There were huge charts and flowcharts with Pressure, temperature instructions are noted. Off course they are complex and go beyond this li’l boy’s imagination…but my father still try to explain me what it means..how water is boiled and coal-ash is carried through big pipes on that charts…for me I just think how could these pipelines cross each other in such a good manner! ) New Employees while on training refers to those charts and afterwards they get used to it. Seasoned employees don’t have to look at them, but these old fellows also think that these charts are useful for them when plant management had to do some maintenance or install some new machinery.
In IT, in our company, we too make kind of flowcharts which are I think a little less complex than those found in engineering factories/plants. These flowcharts are treated as process definitions.People are expected to follow these while doing their day to day work to gain efficiency.
In general, we still find some trouble with them. They still are not our part of day to day life. As a process leader and most importantly as a constant observer and improver when I enquire about people involved in projects or with friends from other organizations, I found that they know that processes exists but on an average, organizations had failed to gain from processes than management’s expectations.
Organizations had constantly failed to make an impact on the way of working with their people;more on people who are smart or intelligent than a average employee. There are several reasons and other factors are related with it and I am not going to discuss the reasons here rather we will discuss about what can be done as a part of the solution.
I think though, Flowcharts serve as single reference point. Merely process flowcharts will not serve the purpose of committing to the following of process in each and every single day.[This is what we expected when we say "Institutionalization of process"].
MAKE PROCESSES VERY VISIBLE TO EMPLOYEES EVERY SINGLE DAY.THEY MUST SEE THEM EVERYDAY.
This may be keep these process definitions/flowcharts at the entrance of companies’ labs or notice boards or even put it as wallpapers of individual member’s desktops or at the front of individual employee.
Second most important thing where most of the organizations fail is conveying the importance of processes to their employees.
They just know since their successive bosses had made compulsion so they need to follow orders.
COMPULSION IS PROBLEMATIC WAY, since it gives false illusion that problem is solved or things are in order as per required.
People, should be shown advantages of following processes subtly, not just stating that “if you follow the process you will get the advantage.”
QA team can play a bigger role in all this. They should not act as a police [Now they ask WHY this document is not there? Rather they could have said with project example that look this document/practice of keeping the document had saved the team this issues or this rework etc.] ,but as a mentor, as a coach.
Saying that they [project teams] do not follow is not the way.
“You cannot change the whole world. Easier way is you have to change yourself.”
The Point here, I want to make is “Know your customers well”. See, project team members are organization’s internal customer. They must see their benefits into whatever you tell them to do.
People should get to know and understand the thought process that had gone behind creating the process definitions.
Most current process making mechanisms capture the end-results and not the enjoyable journey!
So from my stand point, we should add the intent of making such end result to process documents. [This can be very simple, just ask "Why?" at each process step and verify entire process. This way you can validate the process.]
If your process could satisfactorily answer the questions then chances are more for, it will be followed by the people.
1. Why my project team members should follow the ‘xyz’ process?
[I am not expecting the answers like its good to follow,you will get advantages. It should be concrete like you can save 40 man-hours by this. Or something like you will not face client saying that you need to do this requirement change NOW.I know this is kind of steep demand but if you want to buy your team members,its a must have.]
2. How could project get the benefits of it?
3. Process has overheads. How you have designed your process so that it had minimum documents/overheads.
[Answers could be something like...You create class diagram with visual studio. The same solution can be shown as design document. No need to create a separate document. Since project team always can create class diagrams with visual studio less than a minute.]
This is very much contradiction to current way of committing to process. People who are doing QA or involved in SEPG sends mail to respective stakeholders/project team members. [Sending a mail is NOT A COMMUNICATION..Sometimes old ways still had much more effect than e-way.Go and talk to your customers..as simple as that or participate in water cooler talks].Then we conduct training [Reading flowchart boxes is not training?]
IMHO, problem is importance and advantage is not communicated to team members and there everything start falling against the management expectation.
