Tonight, I received a spam mail sent to A.BCD.HelloWorld@gmail.com and intrigued how it could arrive in the in box of ABCD.HelloWorld@Gmail.com my proper GMail account.
BTW, the above e-mail addresses are fictitious containing only structural information, like the presence or absence of a . to illustrate how GMail mishandling e-mail addresses.
So I did some experiments. I sent an e-mail from my hotmail account to A.BCD.HelloWorld@gmail.com and lo and behold, it arrived in ABCD.HelloWorld@gmail.com.
I did that with several other GMail accounts some with no '.' in the address and I could add as many '.' as I like and they were obediently sent to the address without '.'.
I took my other GMail account like this OneBrownFox@gmail.com and sent e-mail to O.n.e.B.r.o.w.n.F.o.x@gmail.com and without failing it ended up in OneBrownFox@gmail.com.
In other words, GMail tries to guess e-mail addresses and that kind of dangerous practices can increase the SPAM mail you receive. In E-Mail format, the '.' is significant. That is OneBrownFox@gmail.com and One.BrownFox@gmail.com are two distinct e-mail addresses with distinct inboxes. But in the eyes of GMail, they are not.
So far GMail is the only e-mail service that seems to mishandle e-mail address in this manner.
A site devoted to discussing techniques that promote quality and ethical practices in software development.
Sunday, October 24, 2010
Monday, October 4, 2010
Management never learns
Let's wind the clock back to year 2000, not long after the Y2K had been vindicated as hoax of the millennium, I was working as a senior software developer in a software company called Mincom that has a product called LinkOne in its product suite. At that time I was not associated with this business unit but was being enticed to join it to redevelop to exploit component technology.
Suddenly, the lead developer resigned and next the product manager. The tide continued and eventually the whole team resigned en masse, include the clerical assistant. Leaving behind was a pile of undocumented C/C++ Win32 SDK code. Business Units in Mincom were, and to a large extend still is, very disjointed groups with very little cross pollination of knowledge. In the mean time, the product had a large users base world wide and they obviously weren't happy being left with an unsupported product after heavy investment in entrusting their data to this product. It is not like swapping Microsoft Word with OpenOffice.
The management at that time speedily mounted a rescue mission, which I called Rescue ver 1, to deal with this product. I was one of the two senior engineers ordered in to take charge to rebuild the team and to take control of the product. At that time, Mincom had the luxury in terms of availability of resources to mount an effective rescue mission and the process went smoothly even though it took a long time for the team to get on top of it.
It was not exactly clear what spooked the team so badly that they resigned en masse but one rumor had it that they did not like the management initiative and the pasture was greener outside. Consultative process and listening to staff/developers were not the forte of the company and still is not. Hence this rumor has credence.
Now fast forward to post GFC era in 2008, which by then I have parted company with this business unit for over 4 years, the company used the GFC as an excuse to begin shedding staff giving rounds of redundancy. LinkOne was not treated any differently even though it was pulling in a respectable income for the company.
Once again, people in this team gradually left the company either through redundancy, disenchantment or simply tossed it in before the ship sank. By 2010, the team, including the key architect who transformed the product from a Win32 product to a respectable .Net product, suffered a bout of anorexia reducing the number down to 1 person with a manager! To this observer, it is a case of Deja Vu.
The remaining person was a product support engineer and obviously they desperatly need a 'team'. While keeping the news quiet from their customers trying to prevent the riotous reaction of the first episode, the company tried to mount a rescue, Rescue ver 2, albeit a vain attempt given the company was now depleted of resources; they had easily more managers than developers. It could only mount a vain mission using time-shared resources. The ineffectiveness of this management style has been well documented by DeMarco. Having worked in this product and knowing what resources remained in the organisation, the future looks bleak not only in terms of supporting the product but to enhance it. It is in precarious position because they cannot afford to lose any more.
Perhaps it is their desire to wind up this product without telling the users by natural attrition.
Once again, Management could have stemmed the loss of unquantifiable resource if they are more consultative and treat their staff with respect. There are other well-known cases of people doing the right thing for ending up being sacked when the company is not exactly flushed with resources. Truly a last act of desperate death throe.
When we mounted the ver 1 rescue, we had the luxury of a pool of resources and knowledgeable long term users to guide us and to show us how the product was supposed to perform. Not anymore. All those knowledge has gone out of the window. The only consolation they now have is this team that left was keen methodologists leaving them with a product source code in a much better shape than when I inherited in ver 1 rescue. I wonder how long this will last before it degenerates into a mess as management presses the poor soul to rush out the fix as his time-slice is over spent.
From this vantage point and from my personal involvement, it is a case of management never learns and never knows how to manage. I am wondering if the loss can be translated into an entry in their profit and loss statement, will their board of directors or share holders still take such a quiet sheepish position.
Suddenly, the lead developer resigned and next the product manager. The tide continued and eventually the whole team resigned en masse, include the clerical assistant. Leaving behind was a pile of undocumented C/C++ Win32 SDK code. Business Units in Mincom were, and to a large extend still is, very disjointed groups with very little cross pollination of knowledge. In the mean time, the product had a large users base world wide and they obviously weren't happy being left with an unsupported product after heavy investment in entrusting their data to this product. It is not like swapping Microsoft Word with OpenOffice.
The management at that time speedily mounted a rescue mission, which I called Rescue ver 1, to deal with this product. I was one of the two senior engineers ordered in to take charge to rebuild the team and to take control of the product. At that time, Mincom had the luxury in terms of availability of resources to mount an effective rescue mission and the process went smoothly even though it took a long time for the team to get on top of it.
It was not exactly clear what spooked the team so badly that they resigned en masse but one rumor had it that they did not like the management initiative and the pasture was greener outside. Consultative process and listening to staff/developers were not the forte of the company and still is not. Hence this rumor has credence.
Now fast forward to post GFC era in 2008, which by then I have parted company with this business unit for over 4 years, the company used the GFC as an excuse to begin shedding staff giving rounds of redundancy. LinkOne was not treated any differently even though it was pulling in a respectable income for the company.
Once again, people in this team gradually left the company either through redundancy, disenchantment or simply tossed it in before the ship sank. By 2010, the team, including the key architect who transformed the product from a Win32 product to a respectable .Net product, suffered a bout of anorexia reducing the number down to 1 person with a manager! To this observer, it is a case of Deja Vu.
The remaining person was a product support engineer and obviously they desperatly need a 'team'. While keeping the news quiet from their customers trying to prevent the riotous reaction of the first episode, the company tried to mount a rescue, Rescue ver 2, albeit a vain attempt given the company was now depleted of resources; they had easily more managers than developers. It could only mount a vain mission using time-shared resources. The ineffectiveness of this management style has been well documented by DeMarco. Having worked in this product and knowing what resources remained in the organisation, the future looks bleak not only in terms of supporting the product but to enhance it. It is in precarious position because they cannot afford to lose any more.
Perhaps it is their desire to wind up this product without telling the users by natural attrition.
Once again, Management could have stemmed the loss of unquantifiable resource if they are more consultative and treat their staff with respect. There are other well-known cases of people doing the right thing for ending up being sacked when the company is not exactly flushed with resources. Truly a last act of desperate death throe.
When we mounted the ver 1 rescue, we had the luxury of a pool of resources and knowledgeable long term users to guide us and to show us how the product was supposed to perform. Not anymore. All those knowledge has gone out of the window. The only consolation they now have is this team that left was keen methodologists leaving them with a product source code in a much better shape than when I inherited in ver 1 rescue. I wonder how long this will last before it degenerates into a mess as management presses the poor soul to rush out the fix as his time-slice is over spent.
From this vantage point and from my personal involvement, it is a case of management never learns and never knows how to manage. I am wondering if the loss can be translated into an entry in their profit and loss statement, will their board of directors or share holders still take such a quiet sheepish position.
Saturday, October 2, 2010
Wonder which tablet is underachievers
The quality of technical reporting on the Internet has sunk with each passage of time, particularly on analyzing product like a Tablet computers. In addition to the previous one, another just surfaced by Dan Ackerman making unsubstantiated statements that
Sure the current crop of touch sensitive device has gesture to open, zoom, flick or rotate object. Windows 7 touch sensitive netbook and Tablets have that functionality in addition to use stylus to write. That kind of gimmicky stuff is nothing new but is a good bait for technical bloggers or reporters.
"these Windows tablets have not been very good. Some are slate-style devices, others are convertible laptops with swiveling screens--but all have been underachievers, to put it mildly."
He fails to define what criteria he uses to call them underachievers. In fact, the current crop of so-called Tablets are nothing more than the same kind used in check-out counters or information kiosk and should be termed as touch sensitive device.It cannot write like Windows Tablet that stores the scribbles as searchable ink. It cannot write and convert to text as you write. It relies on a touch senstive keyboard, which has been found even in good old PDA, and in an integral part of Tablet Windows. In fact Tablet Windows has 2 touch sensitive keyboards - one fixed one and another floating one. The current crop of non-Windows touch sensitive devices cannot provide the user with the ability to annotate, scribble and mark up any documents.
Windows applications run without modification on tablets; my Firefox can use the tablet input and my Thunderbird, with GeckoTIP, works flawlessly. It offers developers ability to develop ink-aware applications that you can scribble on say a PDF or Word documents just like you can do to a printed document.
Sure the current crop of touch sensitive device has gesture to open, zoom, flick or rotate object. Windows 7 touch sensitive netbook and Tablets have that functionality in addition to use stylus to write. That kind of gimmicky stuff is nothing new but is a good bait for technical bloggers or reporters.
The only thing working against the current crop of Windows Tablet is the price. For a properly functioning tablet supporting stylus, it is a lot more expensive than touch sensitive only device. Until the screen cost can be reduced further, this handicap will continue to exist. No amount of software can overcome that.
As a long term Windows Tablet user, and is still using one to compose this blog, I have found the current crop of touch sensitive devices, like iPad, Dell Streak, even Windows touch sensitive netbook, lacking. The ability to write/scribble notes or to annotate pre-prepared document in a meeting or presentation provides a dimension these touch sensitive devices cannot meet.
The convertible type, degraded by Dan through his obvious lack of usage over a period of time - the one with a hardware keyboard - are the most versatile of the lots. While one can write, with some practice, comfortably a reasonably long document using the stylus, often time the keyboard can give you that much more speed and precision. Of course the current crop of touch sensitive devices like iPad are not composing devices for "business-oriented" operations and are more a presentation device, more like a large size iPod Touch. As a result, there is no need for a keyboard with feedback. In a convertible or hybrid kind the keyboard complement the stylus.
So who is lacking and underachieving - show me how to annotate a PDF on iPad or running something like Excel, Photoshop or other productivity suite on iPad like devices.