People will have to be aware whether they are logged into Google or not. Many of us do use one of the Google services, so we are logged in, but we are not aware when we use its search. It made no difference till now. So, if you do end up modifying the results, make you sure you are logged for your future sessions. Also, would this affect Google Custom Search as well?

You also have to be more careful when you send links for search queries around. One of your receivers might end up seeing his/her modified results instead of what you wanted to show.

Having said this I feel that this is a positive development. It will be interesting to see if this additional power to the user gets abused, and very interesting to see if it will clash Google itself.

I was pretty much a two-finger typist when I started my professional programming career. Productivity through typing was a non-issue. However, it did become a pain when I had to work on a Unisys A Series machine programming in Algol. What was the difference? Not the platform or the language, it was the tools. The IDEs provide features like intellisense that compensate for lack of typing skills. Or so I thought!

After learning touch typing, I realized that smooth typing only helped me program smoother. I have also started to remember more, and rely lesser and lesser on intellisense. I was faster with touch typing than with tools which helped me type. I now like my good old vim, as a clutter-free and fast environment on multiple platforms, to program. As Jeff says, I now spend lesser time in expressing my thoughts into code.

However, I have met those who use their IDEs and such tools so efficiently that typing is not necessary for them. I do not know if they will be more productive with touch typing. Afterall it is not that helpful when you type two alphabets, wait for a second and then use tab to type the word. And then again, typing a programming language is a lot different than typing a natural language, which is where the touch typing is geared at. And you guessed right, unlike Jeff or me, they do not think there is much common in programming and writing.

Though I think touch typing helps me program better, I cannot say the same for you. It will depend on your personal inclination as a programmer. The point is about speed and productivity.

How do I convince these sites that I do use Firefox? It gets called something else because of some stupid reasons, but it is really Firefox and nothing else. Every time I visit hotmail or orkut or some site which thinks that it is doing something so special that it needs to warn users about their browsers, these messages that make a mockery of my setup.

I can blame Mozilla for enforcing the trademark issues, or the Linux distribution I use to not comply with Mozilla’s trademark issues, or these sites for ignoring this issue altogether and pestering the user. Whoever gets blamed, the big loss here is for open source. I know the reasons, and I know the hacks, but the average Joe doesn’t. Not only do messages like these confuse the user, they also pose open source as another legal hell, as worse as the proprietary world.

I am the wrong person to interpret the legal language and understand reasons behind it, but I know for sure that if we want to promote open source to the common man issues like these should be avoided. At least recompilation of the source code should not inflect such penalties on the user. One of the solutions I can think of is to consider Firefox as a family of these browsers. User-agent is used to not only identify the browser but to also make assumptions about its capabilities. So use a common user-agent string, which need not be Firefox, across these browsers and use the official and unofficial branding everywhere else. We need Firefox Inside!

But I am sure better solutions can be found and users can be relieved of this pain. Else, more such forks from more such open source applications will only drive the common man away from open source.

However, whatever I have seen yet, I think the most popular mistake, and the least realized one, is that a lot of teams are not skilled enough to execute agile projects. The principles of agile development call for a skillset, and most of which is not about programming. The team should be able to:

• continuously converse with and update the client during development
• consider and scope out changes as the business needs change
• plan out an iteration so that we are always staring at a working piece of software at its end
• prioritize the requirements and identify their dependencies so that they know where to start
• use tools like version control system, and information sharing and collaboration tools
• trust the team members, as the agility of development is extracted by eliminating a lot of overhead
• self-organizing team members, as the agile methodologies do not talk about task management
• adapt to change, whether it is in requirements or environments
• quickly and efficiently communicate with each other

Unfortunately these qualities are not looked at when the team is picked. Even if the team fairs well on a technical scale, the agile methodlogy will fail if the above attributes are missing. Not to say that programming skillset is trivial, but usually the non-programming skillset gets overlooked and the root cause for failures.

Bash supports two editing modes, vi and emacs (which is the default) equally well. So you have to do something more to use the vi editing mode, and that something more is put the following in your .bashrc file.

set -o vi

However, unlike vi, it is by default in the insert mode. However, do not get discouraged, you can use the Esc key to go in the command mode and use the vi key bindings for moving around. It is god-sent when I work with long commands. Additionally, the commands j and k will let you move through the command history. And, here comes the best part, you can use the command v to launch the editor and edit the command in there. I have this habit of concatenating commands in one single line, and before I know it gets unmanageable on the command line. Nothing like being able to seamlessly edit with my favourite editor.

There is a nice cheat sheet available if you are interested in using this. If you are a vi or vim user, this can ease your life a lot.

ORM do have their benefits, but they bring in possible problems as well that we need to be aware of.

• One of the trends I have noticed is that because ORM tools can generate SQL, the team does not include one. Designing the SQL schema and its queries is as important as programming for any application. In some cases it might be more significant. However, this activity gets completely omitted and SQL schema is designed solely on the basis of object model design. The DB schema does not get an independent look. Some years later, when the DB gets highlighted as a bottleneck, the same project managers start a frantic search for a DB consultant.
• ORM, that is supposed to remove the impedance mismatch between the object and relational world, and that cannot be simple to understand. However, ease is considered to be a feature, and we, the programmers, do not give enough time to understand them. This leads to a patchy approach towards using them, and hence the DB schema and queries. Often, refactoring the code to use the ORM in right way leads to changes in schema and queries, which again requires skills of a DB expert.
• ORMs nowadays allow us to execute raw SQL statements as well. It is to be used whenever the ORM API falls insufficient for the our data manipulation. However, this has become an escape route for many. Instead of trying to learn the ORM API, they bypass the ORM altogether by using these everywhere. This also leads to an abuse of other patterns like MVC. You see raw SQL statements being executed in the controllers, reducing models to dumb classes with just getters and setters.
• Though ORMs are evolving, one table per class or one class per table syndrome is still popular. In relational model, one-to-many or many-to-many relationships between two entities typically involves three tables. One for each entity, and one more which represents the relationship. Unfortunately, many ORMs treat this relationship as an entity causing confusion. The confusion increases when one wants to have a many relationship with self. In such cases ORMs highlight the impedance mismatch instead of minimizing it.
• I feel that any programmer who is dealing with an ORM has to understand the relational model being developed. I do not think ORMs are there to shield the programmer from DBs, they are there to help you extend your object modelling in to the relational domain. Though SQL syntax is not a must to work, understanding the underlying concepts of transactions and referential integrity cannot be skipped. Unfortunately, this is not popular with programmers. One side-effect of this also that sometimes ORMs get pitched against some DB capabilities like stored procedures.

Data is one of the most important pieces of our solutions. And so is data modelling and data integrity. I am sure that ORMs were introduced to further this cause and make it easier for us to focus on data. Unfortunately they seem to be doing the exact opposite, not because of themselves, but because of us, the programmers.

The problem is that symbols used elsewhere for namespace separator already play a role in PHP. But would > or | or # cause problems? \ reminds more of a file system than a namespace system, I feel it does not gel with OOP. Speaking of which, I wonder if it would have been better if PHP had not gone the OOP way. It is specialized for the Web, and maybe it should have followed a different paradigm which was Web specific as well. Does web programming really need namespaces and namespace separator?

I remembered an old conversation with a friend, who said “Open source is Government of geeks, by geeks, for geeks!” Open source is geekland, and professionals are not invited! Now I think it is quite understandable why anyone with this perception will want to avoid open source at all costs. It also explains why most of the questions regarding open source sound as if the earthlings are asking about Martian life. Even the reactions start with disbelief and end with rejection.

The talk of source code, wikis, debates, patches, open contributions is so much against the corporate and proprietary culture. I don’t think anyone can deny the discomfort. And I am sure it is extremely difficult to ask them to imagine themselves in this geekland and see the benefits.

Except, if they try using open source as a user, instead of software professionals or a consultants, and realize its benefits. If you are about reject open source for a client, it might be worthwhile to start using an open source project for personal work and rethink about it. The benefits of open source are for the user, not for the business involved in it. The businesses get benefits because of benefits to the users.

Open source inherently starts with scratching a personal itch, see yourself as a user or solve personal needs. If you look at it as a third-party person, you will see it only as a blackbox. Once you start using it, you will perhaps see that it is neither about geeks nor about developers, it is about users.

It is great that Google is also trying to combine OAuth and OpenID to offer an identification + authentication system. However, there is a twist to the tale in this case. It has introduced some non-OpenID steps in the workflow for using Google ID to login to other services that support OpenID. Would this mean that the services would have to do something more than supporting the open standard to play along with Google? If so, I hope that Google intends to use its findings and further develop the OpenID standard, instead of coming up with its own unique implementation.

OpenID is already being harmed because the likes of Yahoo! and Google want to hide it from the end user citing usability and simplicity reasons. I wonder if it would be better if they try to educate the user instead of playing to the Baby duck syndrome. Interesting time ahead, especially since these big players can either leverage OpenID and make it accessible to the common man or they can kill it by wrapping their own proprietary systems around it.