Tuesday, November 25, 2008
11/25/2008 08:08:00 AM
Has HowStuffWorks lost it?
Todays headline: "How labour scabs work"
While the fact that they do work may upset some more militant members of the union, this seems to be a sad comedown for a site that had always delivered good content.
How stuff works seems to have explained all the cool stuff in the world and is scraping the bottom of the barrel to find new material to justify its daily feeds.
I guess until the new Large Hadron Collider is eventually up and running and we finally understand the deepest secrets of the quantum universe, we'll have to be content with things like "How snot works" and "How toilet paper works" and "How dog poo works"
Oh how the mighty have fallen!
While the fact that they do work may upset some more militant members of the union, this seems to be a sad comedown for a site that had always delivered good content.
How stuff works seems to have explained all the cool stuff in the world and is scraping the bottom of the barrel to find new material to justify its daily feeds.
I guess until the new Large Hadron Collider is eventually up and running and we finally understand the deepest secrets of the quantum universe, we'll have to be content with things like "How snot works" and "How toilet paper works" and "How dog poo works"
Oh how the mighty have fallen!
Friday, October 03, 2008
10/03/2008 04:56:00 PM
Not quite getting it
In a recent stand up meeting regarding an important quarterly release of a large application to which I contribute, a developer explained that certain unit-tests were failing and preventing the build from completing so to ensure all was running correctly, he commented out the offending tests.
You can imagine the hilarity that resulted from that!
You can imagine the hilarity that resulted from that!
Wednesday, September 24, 2008
9/24/2008 11:34:00 PM
Agile Methodists
I have recently been researching the driving forces behind agile methods for a series of educational presentations I am making for a client.
I stumbled upon an image of a group of developers participating in the stand-up meeting which, I seem to recall, was on Kent Beck's site and was struck by the similarity between it and images I have seen in Mormon pamphlets, the ones that are obviously an image treated with a Photoshop style aquarelle post-process, that makes the image look as if it was the work of an impressionist painter.
I was startled to make the association between agile methods and religious fervour but re-reading the agile manifesto, which I always thought of as a sort of Marxist text, I see now is more of an evangelical thing.
Suddenly, the pieces fell into place and I felt a chill run up and down my spine when I realised that the morning meeting where everyone speaks a little about what they did the day previously, what they intended to do today and if they were having difficulty on some level or other, was a definite ringer for a witnessing.
Occasionally, meetings get a more conventionally religious overtone when a charismatic developer decides to expound upon hot theories during the sacrosanct fifteen minutes and extends it to forty five while people shift themselves into more comfortable leaning positions on walls and the backs of chairs.
There may even be a burgeoning market for cardboard cut-out pulpits!
I stumbled upon an image of a group of developers participating in the stand-up meeting which, I seem to recall, was on Kent Beck's site and was struck by the similarity between it and images I have seen in Mormon pamphlets, the ones that are obviously an image treated with a Photoshop style aquarelle post-process, that makes the image look as if it was the work of an impressionist painter.
I was startled to make the association between agile methods and religious fervour but re-reading the agile manifesto, which I always thought of as a sort of Marxist text, I see now is more of an evangelical thing.
Suddenly, the pieces fell into place and I felt a chill run up and down my spine when I realised that the morning meeting where everyone speaks a little about what they did the day previously, what they intended to do today and if they were having difficulty on some level or other, was a definite ringer for a witnessing.
Occasionally, meetings get a more conventionally religious overtone when a charismatic developer decides to expound upon hot theories during the sacrosanct fifteen minutes and extends it to forty five while people shift themselves into more comfortable leaning positions on walls and the backs of chairs.
There may even be a burgeoning market for cardboard cut-out pulpits!
Labels: agile, humor, humour, religion
Wednesday, September 17, 2008
9/17/2008 08:29:00 AM
Is Apple's software quality slipping?
I recently succumbed to the lure of Apple's call when I bought an IPhone, largely because where I work it's difficult to get my mail during the day.
Aside from being locked to their view of the world, a situation that will be rectified very soon when I jailbreak the thing, I was astounded to find that the Apple reputation for thinking of everything and being easy to use falls far short of expectation.
I am a biker and do my daily commute on my Triumph Bonneville so I got a Bluetooth helmet kit and subsequently discovered that the iphone doesn't have an auto-answer function for when the headset is connected. Furthermore, for a touch device not to support handwriting recognition or voice command dialling yet have the processor power to do serious graphics is inadmissible.
I've hadthe thing for a week now and I am getting used to it's little foibles but to be honest, it shouldn't have any!
Posted from my IPhone...
Aside from being locked to their view of the world, a situation that will be rectified very soon when I jailbreak the thing, I was astounded to find that the Apple reputation for thinking of everything and being easy to use falls far short of expectation.
I am a biker and do my daily commute on my Triumph Bonneville so I got a Bluetooth helmet kit and subsequently discovered that the iphone doesn't have an auto-answer function for when the headset is connected. Furthermore, for a touch device not to support handwriting recognition or voice command dialling yet have the processor power to do serious graphics is inadmissible.
I've hadthe thing for a week now and I am getting used to it's little foibles but to be honest, it shouldn't have any!
Posted from my IPhone...
Wednesday, August 27, 2008
8/27/2008 08:10:00 PM
Reflector
I suppose that about fifty million people will have received the mail from Lutz Roeder explaining that he has sold or given the code for Reflector to RedGate software.
Personally, I am "gobsmacked" as they say in the UK that Microsoft hasn't done the right thing and paid Lutz handsomely for this system so that it could be included in Visual Studio as a tool. This isn't the first time I've been similarly gobsmacked at the stupidity of Microsoft when dealing with community projects of this type. The previous grave error on their part was to not buy nDoc for a decent price instead of proposing that P.O.S. Sandcastle as a viable alternative.
It seems to me that when it comes to community, Microsoft seems to have lost touch with what community is about. As a long time advocate of community and peer-to-peer education and assistance I believe strongly that some things used by the community are just too good to let fall into the hands of third-party entities that would exploit them in the wrong way.
I imagine that when Reflector was first seen, there were those in Microsoft that were aghast at the idea that all the source code of the framework became open to anyone who wanted to view it. I also remember it as a wakeup call to companies that had no protection for their own code. Despite this initial reaction, Microsoft never made an effort to obfuscate the system DLL's and now, I don't believe that a single developer on the planet who programs for Windows can get through the day without using Reflector somewhere.
As community projects or run by small entrepreneurs, a self-starter tool of such enormous impact as Reflector, nDoc or even nDepend, present no competition to to Visual Studio and do nothing but enhance it. When taken over by a third party, these tools immediately become looming compettitors that may adversely affect the market and reduce resources when Microsoft suddenly realises that they have to build competing functionality into Visual Studio.
A couple of million bucks is a drop in the ocean for Microsoft. Imagine what they themselves would spend in order to try to create something as universally useful as nDoc, Reflector or nDepend. On the other hand, for them to purchase these tools and add them to the Visual Studio system would be an incredibly useful and sane thing to do. Instead, they allow such important work to fall into the hands of third parties that really are potential competition to them.
Microsoft, Wake up! Look at the communities that you say that you value, use the resources in them to enhance the product, don't allow something like this to happen again! It's just plain idiotic.
Personally, I am "gobsmacked" as they say in the UK that Microsoft hasn't done the right thing and paid Lutz handsomely for this system so that it could be included in Visual Studio as a tool. This isn't the first time I've been similarly gobsmacked at the stupidity of Microsoft when dealing with community projects of this type. The previous grave error on their part was to not buy nDoc for a decent price instead of proposing that P.O.S. Sandcastle as a viable alternative.
It seems to me that when it comes to community, Microsoft seems to have lost touch with what community is about. As a long time advocate of community and peer-to-peer education and assistance I believe strongly that some things used by the community are just too good to let fall into the hands of third-party entities that would exploit them in the wrong way.
I imagine that when Reflector was first seen, there were those in Microsoft that were aghast at the idea that all the source code of the framework became open to anyone who wanted to view it. I also remember it as a wakeup call to companies that had no protection for their own code. Despite this initial reaction, Microsoft never made an effort to obfuscate the system DLL's and now, I don't believe that a single developer on the planet who programs for Windows can get through the day without using Reflector somewhere.
As community projects or run by small entrepreneurs, a self-starter tool of such enormous impact as Reflector, nDoc or even nDepend, present no competition to to Visual Studio and do nothing but enhance it. When taken over by a third party, these tools immediately become looming compettitors that may adversely affect the market and reduce resources when Microsoft suddenly realises that they have to build competing functionality into Visual Studio.
A couple of million bucks is a drop in the ocean for Microsoft. Imagine what they themselves would spend in order to try to create something as universally useful as nDoc, Reflector or nDepend. On the other hand, for them to purchase these tools and add them to the Visual Studio system would be an incredibly useful and sane thing to do. Instead, they allow such important work to fall into the hands of third parties that really are potential competition to them.
Microsoft, Wake up! Look at the communities that you say that you value, use the resources in them to enhance the product, don't allow something like this to happen again! It's just plain idiotic.
Thursday, July 31, 2008
Well, despite my joy in finding a bug it seems that the issue of the overload polymorphism question is moot. Its a choice.
The compiler can choose to ignore the fact that a better parameter match exists and use a lazy evaluation of a method in a derived class. Apparently, this doesn't break the rules of OOP or of polymorphism. It just prevents "brittle base class" syndrome.
Personally, although I can see a certain validity in the arguments of MS gurus like Eric Lippert I still feel as though the wool has been pulled over my eyes somewhat. How I missed such a simple thing as this for the last eight years is a mystery to me. I must be getting old.
Ahh well. I suppose I had better brush up on my VB syntax because despite the fact that the language is verbose and redundant they have a kick-ass compiler that is proven to be better at
loop optimisation and now I discover that it handles an important compiler principle in a logical and intuitive way.
The compiler can choose to ignore the fact that a better parameter match exists and use a lazy evaluation of a method in a derived class. Apparently, this doesn't break the rules of OOP or of polymorphism. It just prevents "brittle base class" syndrome.
Personally, although I can see a certain validity in the arguments of MS gurus like Eric Lippert I still feel as though the wool has been pulled over my eyes somewhat. How I missed such a simple thing as this for the last eight years is a mystery to me. I must be getting old.
Ahh well. I suppose I had better brush up on my VB syntax because despite the fact that the language is verbose and redundant they have a kick-ass compiler that is proven to be better at
loop optimisation and now I discover that it handles an important compiler principle in a logical and intuitive way.
Thursday, July 24, 2008
7/24/2008 07:06:00 PM
Still bugs in the C# compiler.
I have been putting together some simple training for VB6 developers who have had little or no experience with C# or object orientation and I found this lovely bug in the compiler.
Speaking with a friend who works for Microsoft he quickly said it wasn't a bug and gave me a line about explicit casting and method selection in the compiler but I think that the example is really simple and is a clear breach of overloading principles.
I have a base class with a virtual method which contains an integer parameter. In a derived class I include both an override for the original method plus an overload for the same method but this time having a float parameter.
The main function calls the derived class and even when the parameter is cast explicitly to int, the int overload is never called.
This is true in the 2005 and 2008 versions.
To prove a point I wrote the exact equivalent functionality in VB.net and it works as expected.
Here's the code.
Speaking with a friend who works for Microsoft he quickly said it wasn't a bug and gave me a line about explicit casting and method selection in the compiler but I think that the example is really simple and is a clear breach of overloading principles.
I have a base class with a virtual method which contains an integer parameter. In a derived class I include both an override for the original method plus an overload for the same method but this time having a float parameter.
The main function calls the derived class and even when the parameter is cast explicitly to int, the int overload is never called.
This is true in the 2005 and 2008 versions.
To prove a point I wrote the exact equivalent functionality in VB.net and it works as expected.
Here's the code.
class Program
{
static void Main(string[] args)
{
DerivedClass dc = new DerivedClass();
dc.AMethod((int)1);
dc.AMethod(1f);
Console.ReadKey();
}
}
class BaseClass
{
public virtual void AMethod(int i)
{
Console.WriteLine("Base class integer parameter!");
}
}
class DerivedClass : BaseClass
{
public override void AMethod(int i)
{
Console.WriteLine("Derived class integer parameter");
}
public void AMethod(float f)
{
Console.WriteLine("Derived class float parameter");
}
}
