We've just decided that I will be visiting the Microsoft PDC. That is, if there are any tickets, hotels and flights still available :-
I'm sure I will have a peep at the place where Prism will be available. Since I am always on the look out for new technology, and looking for opportunities to move our software to the .Net platform, I will definitely want to have a look at Codegear's product in that market. I really hope to get my hands on a trial version and/or have a close look to see why I would choose for Prism and not for C#.
Also, I'm pretty interested in Windows 7. So, that I will give that a close look too (and maybe even try our software on it).
If any of you want to schedule a meeting or demo of our Sevensteps Studio product or any other Sevensteps software product, please let me know and we'll schedule a meeting. I'm always on the look out for new business partners to setup a new product. If you want to get first hand knowledge about what our software can do for you, this might be a right time.
Cu in LA.
Bye,
Bart
Wednesday, October 15, 2008
Thursday, September 25, 2008
DevExpress releases beta for controls supporting D2009
Well, I just got that email that I was waiting for. DevExpress has its first (beta) release out supporting D2009. I now have placed my order for D2009. I hope everything works out as smooth as you read out elsewhere. And it looks like I can finally get my feet wet with regards to the anonymous methods, so I will know better what I’m talking and complaining about.
When I’ve set everything up I will definitely publish my experiences…
Bye,
Bart
Wednesday, September 24, 2008
Proof of the concept is in the eating...
Marco published a little example of anonymous methods. I already commented about it on his blog, but to me this is the very proof of the uglyness of anonymous methods.
To me the beauty in object oriented languages is the ability to create easy readable code if you take care of your object design and naming conventions. If you have a sound object model and you choose the names of properties and methods wisely, your code will be very easy to read and to understand. If you keep you code logic simple and short (I very much favor methods and functions that have a very limited amount of code in them) no one will have trouble reading (and if necessary maintaining) your code.
Marco's example, to me, proofs that anonymous methods are terrible. One has to read his little piece of code a couple of times to see what's going on and still it would probably need a bit of documentation. Or, maybe it's me, and only I have to read his code a couple of times.
In my book the anonymous methods will remain very much what their name suggests: not very well known.
Bye,
Bart
To me the beauty in object oriented languages is the ability to create easy readable code if you take care of your object design and naming conventions. If you have a sound object model and you choose the names of properties and methods wisely, your code will be very easy to read and to understand. If you keep you code logic simple and short (I very much favor methods and functions that have a very limited amount of code in them) no one will have trouble reading (and if necessary maintaining) your code.
Marco's example, to me, proofs that anonymous methods are terrible. One has to read his little piece of code a couple of times to see what's going on and still it would probably need a bit of documentation. Or, maybe it's me, and only I have to read his code a couple of times.
In my book the anonymous methods will remain very much what their name suggests: not very well known.
Bye,
Bart
Saturday, September 06, 2008
AutomatedQA know their support
Some time ago I reported serious problems that prevented me from compiling my projects using AutomatedBuildStudio from Automated QA. I already had some support emails going back and forth but the solutions was nowhere near.
So, I decided to switch to FinalBuilder and installed the trial version. That was a good experience and it got me going with my projects in a half a day.
I still was in contact with AutomatedQA though and they asked an opportunity to try to solve the problem. I gave them the length of the trial period of FinalBuilder (which is a month). To make a long story short: I ended up letting an AutomatedQA programmer take over my developers computer (using the ever excellent TeamViewer) and after an hour or so fiddling with configuration files, temporary files during the build, et cetera, they concluded to have found an offending compiler setting generating during the build process.
They promissed a solution by the next day and they delivered that. Compiling my projects works fine again.
That makes me happy for a couple of things:
1) Apparently the problems of a single use does mean a thing to AutomatedQA. They could have said: sorry we lost you, but there's nothing we can do. They didn't do that and really digged in.
2) I discovered a problem with FinalBuilder and Wise v6 in creating installer packages. After a compilation of the Wise package from Finaler Builder, the Wise project is damaged and from that point on unusable. I had to compiling my packages 'by hand' which was pretty unconvenient. I'm sure I would have found some sort of automated build process if I had to stick with FinalBuilder, but it wasn't as problem free as I first thought.
Most important of all, I can still use my original build scripts, which are pretty advanced and saved me a lot of time in the past and now probably will do in the future.
Just to let you know and to do justice to the support team of AutomatedQA. It just tells me again that having great support pays off in the end to both parties.
Bye,
Bart
So, I decided to switch to FinalBuilder and installed the trial version. That was a good experience and it got me going with my projects in a half a day.
I still was in contact with AutomatedQA though and they asked an opportunity to try to solve the problem. I gave them the length of the trial period of FinalBuilder (which is a month). To make a long story short: I ended up letting an AutomatedQA programmer take over my developers computer (using the ever excellent TeamViewer) and after an hour or so fiddling with configuration files, temporary files during the build, et cetera, they concluded to have found an offending compiler setting generating during the build process.
They promissed a solution by the next day and they delivered that. Compiling my projects works fine again.
That makes me happy for a couple of things:
1) Apparently the problems of a single use does mean a thing to AutomatedQA. They could have said: sorry we lost you, but there's nothing we can do. They didn't do that and really digged in.
2) I discovered a problem with FinalBuilder and Wise v6 in creating installer packages. After a compilation of the Wise package from Finaler Builder, the Wise project is damaged and from that point on unusable. I had to compiling my packages 'by hand' which was pretty unconvenient. I'm sure I would have found some sort of automated build process if I had to stick with FinalBuilder, but it wasn't as problem free as I first thought.
Most important of all, I can still use my original build scripts, which are pretty advanced and saved me a lot of time in the past and now probably will do in the future.
Just to let you know and to do justice to the support team of AutomatedQA. It just tells me again that having great support pays off in the end to both parties.
Bye,
Bart
Friday, August 29, 2008
To further on all the non(sense) news about Tiburon...
I may be too sceptical, under too much work stress, or maybe I'm catching some flew or the other. But really, is the news about the handling of a password character worth the bits over the internet? (oops, now I've done it myself).
See: http://glooscapsoftware.blogspot.com/2008/08/delphi-2009-passwordchar.html
Come on everybody out there. I love to read about generics and implementation (problems) with the Unicode stuff. I even find the reports about the installation time more worthwhile than this.
It's probably me... Lunch time is over: back to business!
Bye,
Bart
See: http://glooscapsoftware.blogspot.com/2008/08/delphi-2009-passwordchar.html
Come on everybody out there. I love to read about generics and implementation (problems) with the Unicode stuff. I even find the reports about the installation time more worthwhile than this.
It's probably me... Lunch time is over: back to business!
Bye,
Bart
Wednesday, August 27, 2008
So, installation time is shorter. Who cares????
I've now seen a couple of blogs about the improved install speed of the new Delphi version. It may be me, but I really don't get it why people get so enthousiastic about that. Who cares if your installation takes 10, 20 or 60 minutes? It's something that you (should) do only once in a long while and then you're done with that. I much rather see 10% improvement in compile speed than 1000% improvement in installation time.
Am I crazy or what? Let's state it once again and never mention it after this:
installation time of Delphi 2009 has improved!
(now, back to work...)
Bye,
Bart
Am I crazy or what? Let's state it once again and never mention it after this:
installation time of Delphi 2009 has improved!
(now, back to work...)
Bye,
Bart
Tuesday, August 26, 2008
Would you buy Delphi 2009?
Now the new version is in the open I found me talking to myself yesterday (...) about when and why I should buy the new version. I am curious enough to want to get my hands on it, but really haven't found an argument for upgrading yet. The new features in the language are not the ones that will solve all my remaining whishes for my software. I am using DevExpress components and not using ribbon toolbars (yet), so there's not a lot of new things in the VCL for me.
I do want unicode though, badly, so that is a good reason. But I'm using the DevExpress components so I need to wait for those to be 2009-ready. So, I have decided to wait for them to come with a unicode compatible release of their components before buying 2009. Since everybody says that implementing unicode with 2009 is so easy, it shouldn't take long, but I'm not really sure about that to be honest. We'll see...
What about you? Can you control yourself and find a decent reason to upgrade? Or are you susceptible for the hype-like messages about 2009 and find you running to the shop already?
Bye,
Bart
I do want unicode though, badly, so that is a good reason. But I'm using the DevExpress components so I need to wait for those to be 2009-ready. So, I have decided to wait for them to come with a unicode compatible release of their components before buying 2009. Since everybody says that implementing unicode with 2009 is so easy, it shouldn't take long, but I'm not really sure about that to be honest. We'll see...
What about you? Can you control yourself and find a decent reason to upgrade? Or are you susceptible for the hype-like messages about 2009 and find you running to the shop already?
Bye,
Bart
Monday, August 11, 2008
Exceptions, return value checking, pre- and postconditions
I never actually worked with Eiffel but when I first heard about it (that is some decades ago, really...) there is one concept that I remembered for the whole of my professional career and I adhered as a 'coding principle' in my own code. I'm talking about the concept of pre- and postconditions.
As I remember it in Eiffel you can write your method/function/procedure (whatever it's called) and define some conditions that must be met before and at the end of that. E.g. you could define a precondition for a function that will ensure that a passed parameter is larger than zero. For the remainder of your code you can assume that the passed parameter IS larger than zero.
Now, whenever I write a function/method I do the same. E.g. if I do a typecast somewhere in my code, I try to check for the correctness of the object that is typecast as soon as possible in my code. Something like this (from the top of my head, forgive me typos, simplicity of the examples and such):
procedure Foo(const aControl: TWinControl);
begin
// Beginning of preconditions
if not Assigned(aControl) then exit;
if not (aControl is TEdit) then exit;
// End of preconditions
// You can now safely execute the code below
TEdit(aControl).Text := 'foo';
end;
The above works fine if there actually is something that you can check at the beginning of the code. But, what if you cannot, until right before you start to use an object? Like below:
procedure Foo();
var
aControl: TEdit;
begin
(**
A Whole Bunch of Code Here
**)
aControl := MyFunctionSomeWhereThatReturnsTEdit();
if (not Assigned(aControl)) then exit;
if (not (aControl is TEdit)) then exit;
aControl.Text := 'foo';
end;
In this case you would add your check just below the aControl := line. And if you have a lot of those, your code can become complex and hard to read. And you would end up with a lot of not so interesting code which in the end doesn't really matter to your program.
Now, until now I used assertions for this type of checking, mainly because you can turn those off easily using a compiler switch.
aControl := MyFunctionSomeWhereThatReturnsTEdit();
Assert(Assigned(aControl));
Assert(aControl is TEdit);
But, of course, this doesn't work if the 'failing conditions' might be ligitimate circumstances in your code. So, for those types of checks I used the if..then constructions from the first example.
But, I am now thinking that I'd better use exceptions for this. Currenlty I only use exceptions for 'error circumstances' and never really used them as a way to signal pre- and postconditions. It would go like this:
procedure Foo();
var
aControl: TEdit;
begin
try
(**
A Whole Bunch of Code Here
**)
aControl := MyFunctionSomeWhereThatReturnsTEdit();
aControl.Text := 'foo';
except
on E: MyConditionException do
begin
// This will be an exception raised from within MyFunctionSomeWhereThatReturnsTEdit
end;
on E: Exception do // There probably are seperate exceptions for nil and class type mismatch exceptions, but this will do for the example
begin
// Something else should be done.
end;
end;
end;
This will work (and I think I will give it a go in some small program to see if it works our for my style of programming), but I'd much rather see the concept of pre- and postconditions introduced in Delphi.
What do you think? If..Then constructions at the beginning? Exceptions? Push Embarcadero for pre-/postconditions? Something else?
Please let me know; I'm really curious.
Bye,
Bart
As I remember it in Eiffel you can write your method/function/procedure (whatever it's called) and define some conditions that must be met before and at the end of that. E.g. you could define a precondition for a function that will ensure that a passed parameter is larger than zero. For the remainder of your code you can assume that the passed parameter IS larger than zero.
Now, whenever I write a function/method I do the same. E.g. if I do a typecast somewhere in my code, I try to check for the correctness of the object that is typecast as soon as possible in my code. Something like this (from the top of my head, forgive me typos, simplicity of the examples and such):
procedure Foo(const aControl: TWinControl);
begin
// Beginning of preconditions
if not Assigned(aControl) then exit;
if not (aControl is TEdit) then exit;
// End of preconditions
// You can now safely execute the code below
TEdit(aControl).Text := 'foo';
end;
The above works fine if there actually is something that you can check at the beginning of the code. But, what if you cannot, until right before you start to use an object? Like below:
procedure Foo();
var
aControl: TEdit;
begin
(**
A Whole Bunch of Code Here
**)
aControl := MyFunctionSomeWhereThatReturnsTEdit();
if (not Assigned(aControl)) then exit;
if (not (aControl is TEdit)) then exit;
aControl.Text := 'foo';
end;
In this case you would add your check just below the aControl := line. And if you have a lot of those, your code can become complex and hard to read. And you would end up with a lot of not so interesting code which in the end doesn't really matter to your program.
Now, until now I used assertions for this type of checking, mainly because you can turn those off easily using a compiler switch.
aControl := MyFunctionSomeWhereThatReturnsTEdit();
Assert(Assigned(aControl));
Assert(aControl is TEdit);
But, of course, this doesn't work if the 'failing conditions' might be ligitimate circumstances in your code. So, for those types of checks I used the if..then constructions from the first example.
But, I am now thinking that I'd better use exceptions for this. Currenlty I only use exceptions for 'error circumstances' and never really used them as a way to signal pre- and postconditions. It would go like this:
procedure Foo();
var
aControl: TEdit;
begin
try
(**
A Whole Bunch of Code Here
**)
aControl := MyFunctionSomeWhereThatReturnsTEdit();
aControl.Text := 'foo';
except
on E: MyConditionException do
begin
// This will be an exception raised from within MyFunctionSomeWhereThatReturnsTEdit
end;
on E: Exception do // There probably are seperate exceptions for nil and class type mismatch exceptions, but this will do for the example
begin
// Something else should be done.
end;
end;
end;
This will work (and I think I will give it a go in some small program to see if it works our for my style of programming), but I'd much rather see the concept of pre- and postconditions introduced in Delphi.
What do you think? If..Then constructions at the beginning? Exceptions? Push Embarcadero for pre-/postconditions? Something else?
Please let me know; I'm really curious.
Bye,
Bart
Thursday, August 07, 2008
FinalBuilder it is...
As reported yesterday I was experiencing problems with AutomatedBuildStudio. With a little pain in my heart, but in the end with great relief I can tell you that I decided to switch to FinalBuilder.
The pain is caused by the memory of some great experiences with ABS. So I feel a little sad to leave them. But, to my joy I was up and running (for the project that gave me problems for the last week) in about 10 minutes (really!) time with FinalBuilder. I can't tell yet if it's quicker/better/easier to use than ABS, but the fact is that I now have an automated build script for one of my main products in just a couple of minutes time. With almost all the things in there that I want (I will have to tweak it here and there to do some script based automated things).
So, yes, it's a joy to say: I'm in the FinalBuilder camp too.
Thanks to everyone responding to my previous post about this. It really helped to make the decision to move over.
Bye,
Bart
The pain is caused by the memory of some great experiences with ABS. So I feel a little sad to leave them. But, to my joy I was up and running (for the project that gave me problems for the last week) in about 10 minutes (really!) time with FinalBuilder. I can't tell yet if it's quicker/better/easier to use than ABS, but the fact is that I now have an automated build script for one of my main products in just a couple of minutes time. With almost all the things in there that I want (I will have to tweak it here and there to do some script based automated things).
So, yes, it's a joy to say: I'm in the FinalBuilder camp too.
Thanks to everyone responding to my previous post about this. It really helped to make the decision to move over.
Bye,
Bart
Wednesday, August 06, 2008
Thinking about switching from Automated Build Studio to FinalBuilder
Some time ago I purchased an update to Automated Build Studio. I whish I never did. I was pretty happy with the previous version, but encountered a problem (or wanted a feature - can't remember) that was solved/available in the new version only. Since I was very happy in the past I never thought twice about purchasing the update.
From the word go I ran into problems. I got access violations and had problems with search paths that were used when compiling Delphi software. It took me some intensive emaling with the support department before I got our most important projects compiling again. The access violations still happen intermittedly and a solution was never provided.
Now, I started using a new component pack some time ago (VideoLabs) and the problems with the search paths were back again. Things compile fine using the IDE or from the command line, but using AutomatedBuildStudio I get some unexplainable errors. I emailed support a couple of time, but they all seem to be on holiday: I can't get a reply.
So, I'm thinking about switching to another tool. Even though I have created a workaround (calling a batch file compiling the projects, using another tool to update the version numbers of my software), I don't want that as a permanent solution on my build system.
I found quite a lot of praize about FinalBuilder. It seems pretty affordable too (maybe there's even a competetive upgrade prize available if I ask).
What's your experience? What build systems can you recommend?
Thanks for letting me know.
Bye,
Bart
From the word go I ran into problems. I got access violations and had problems with search paths that were used when compiling Delphi software. It took me some intensive emaling with the support department before I got our most important projects compiling again. The access violations still happen intermittedly and a solution was never provided.
Now, I started using a new component pack some time ago (VideoLabs) and the problems with the search paths were back again. Things compile fine using the IDE or from the command line, but using AutomatedBuildStudio I get some unexplainable errors. I emailed support a couple of time, but they all seem to be on holiday: I can't get a reply.
So, I'm thinking about switching to another tool. Even though I have created a workaround (calling a batch file compiling the projects, using another tool to update the version numbers of my software), I don't want that as a permanent solution on my build system.
I found quite a lot of praize about FinalBuilder. It seems pretty affordable too (maybe there's even a competetive upgrade prize available if I ask).
What's your experience? What build systems can you recommend?
Thanks for letting me know.
Bye,
Bart
Monday, August 04, 2008
I now get anonymous methods: but I really dislike them already...
The example below was taken from Andreano Lanusse's blog on anonymous methods.
After examining this example for a couple of minutes (yes, really it took me that long...) and looking at the other example in his blog, I think I've made my mind up. I detest anonymous methods already. IMHO (of course as always), I can only conclude that using anonymous methods make your code less readable (to me at least) and don't add any real value to the language. Still, I haven't found examples or explanations that help me to get into the anonymous camp. Even Craig Stuntz's doesn't help me get there.
After examining this example for a couple of minutes (yes, really it took me that long...) and looking at the other example in his blog, I think I've made my mind up. I detest anonymous methods already. IMHO (of course as always), I can only conclude that using anonymous methods make your code less readable (to me at least) and don't add any real value to the language. Still, I haven't found examples or explanations that help me to get into the anonymous camp. Even Craig Stuntz's doesn't help me get there.
I also realize that there is one principle that I live by that renders some of the 'advantages' of anonymous methods useless. Sure, using anonymous methods can help you to limit the amount of 'real' code in a method and thus make it a bit more easy to overview. Or, at least, that's one of the reasons give to use anonymous methods.
However, this 'advantage' is only of use if you write really long methods and functions. The more code you have, the sooner you will find yourself repeating things and the quicker an anonymous method can help you reduce your code. But, if I look at my own coding style, I try to make small methods and functions, archieving only a couple of things in it. That hardly ever takes more than 10-20 lines of code per method. If you are writing longer code, chances are that you better start that refactoring utility and split your code up. Most of times that will make your code better reusable and easier to maintain.
As for Craig's argument of being able to do things that a designer of a framework didn't think of: I think you are working against the principles in that framework or the framework simply is not well designed. But, that's maybe another personal style of programming. If I use somebody else's framework, I try to use it as intended. Maybe the 'hacking' you are talking about becomes a bit easier, but I for one are against hacking.
The last sentence reminds me: due to some technical problems, you might have missed my posting on why a developer wants to be a CIO (or not). If you are border tonight, you might want to have a peek.
Bye,
Bart
Saturday, August 02, 2008
Why would developers want to become a CIO?
I found these articles today:
5 Reasons why a developer would want to become a CIO
and
8 Reasons why a developer would never want to become a CIO
They are about reasons why a developer might want to or might not change his position for a position as a CIO.
Now, I'm going to discard all the financial arguments. I'm not interested in money, at least not to the level that it will make me decide in favor of or against a job. Maybe it's because I'm Dutch and not American, I don't know. But I couldn't look at myself in the mirror if I would take a job just for the money. I would deny a job if they wouldn't pay what I'm worth though, but I think that's another matter. Bottom line: money couldn't get me into a job, but could keep me out of it.
Now, for the other reasons that a developer would want to be a CIO (only 2 of the 5 arguments remain after removing the financial reasons...) #2 is bullocks. It tells us that you want to be king of the company because you will have power over the people. To me, that's not a reason to be the king. I want to have the power over the faith of the software, not the people. I want to be able to tell which directions we need to take with the software. That's the real beauty of being king, not that you can tell people they need to fill in form A,B, or C.
Reason #5 (you get tired of solving the bugs) is bollocks too. Every programmer knows solving bugs is part of the job and you want to improve your software each day to give your customers a better product and toe get you less bugs on your todo list. If you are solving bugs each and every day and nothing but bugs, you're a bad programmer and you won't survive the business. If you have to do that because you're the bug solving programmer, you probably are just starting (solving bugs is a great way to learn the software and learn programming) and chances are you're not CIO material yet.
So, a nice article that draws some attention but, IMHO of course, full of nonsens.
As for the other article: the 8 reasons why you DON'T want to be the CIO, it's much the same.
Reason #1: we live to write code. True, but I guess that CIOs that have a developer background still continue to write code, or at least will research (new) code developments. You will be the senior in the company (after all, you started as a developer) and chances are there will be some hungry young dogs trying to learn from you. You won't leave your code: you only get to pick the nice pieces to be involved in.
Reason #2: seeing the fruits of your labor. Being a CIO for once you can make the decisions that you think are good for the software and the company. If you have sound ideas, the company will improve with your leadership and you will see the best measurable results possible: an increase in turnover. The results of a days work as a programmer is a nice piece of code that makes it through the unit test cleanly. The results as a CIO will show in the daily sales of licenses and positive customer feedback. I'd rather have the latter.
Reason #3: being able to speak Java/C/et cetera is a must for a CIO. That's the only way you won't get fooled by the developers that tell you that something isn't possible (anything is!). But, sure, you need to be able to express yourself as a human too, but I require that from my programmers too! If you can't talk Dutch (or English :-)) you would have a hard time surviving in my company. It's not a CIO-only requirement: it's a human's requirement to be able to express yourself.
Reason #4: there probably are a couple of people that want to be remembered for their hacking capabilities. But, again IMHO, hacking is stupid. If you are such a good programmer that you can do some facinating stuff, apply your abilities to do some good and useful work. It's a waste to spend your talents at stuff that gets people mad. You can do a lot better in making people happy.
Reason #5: sucking up to other people with jobs beginning with C's. What nonsense. If you are a good CIO, you will be taken as an equal amongst those C's. If you're not, you're not in a technology company and/or you're no good. If you find yourself sucking up the whole time you probably did it before (and you might even have gotten the C-job for it), but you won't make it.
Reason #6: the reference in the article to point #1 is a good one, because the same counter arguments apply. As the CIO you for once get to pick the directions and you will be able to do some real innovation that has an impact in the company. As a developer you will find you write just a bit more clever code that nobody will see. You'll take pride in that, but it will only matter to yourself.
Reason #7: not liking Powerpoint. If so, use something else: easy. Use video, music, exotic dansers. You're the guy with the 'C': pick your own tools. Now you can!
And for reason #8: that will all change, once YOU are the CIO. All the other developers will think: thank god, we now DO HAVE somebody that has a clue.
Again, Just My 2Cents Worth.
Bye,
Bart
5 Reasons why a developer would want to become a CIO
and
8 Reasons why a developer would never want to become a CIO
They are about reasons why a developer might want to or might not change his position for a position as a CIO.
Now, I'm going to discard all the financial arguments. I'm not interested in money, at least not to the level that it will make me decide in favor of or against a job. Maybe it's because I'm Dutch and not American, I don't know. But I couldn't look at myself in the mirror if I would take a job just for the money. I would deny a job if they wouldn't pay what I'm worth though, but I think that's another matter. Bottom line: money couldn't get me into a job, but could keep me out of it.
Now, for the other reasons that a developer would want to be a CIO (only 2 of the 5 arguments remain after removing the financial reasons...) #2 is bullocks. It tells us that you want to be king of the company because you will have power over the people. To me, that's not a reason to be the king. I want to have the power over the faith of the software, not the people. I want to be able to tell which directions we need to take with the software. That's the real beauty of being king, not that you can tell people they need to fill in form A,B, or C.
Reason #5 (you get tired of solving the bugs) is bollocks too. Every programmer knows solving bugs is part of the job and you want to improve your software each day to give your customers a better product and toe get you less bugs on your todo list. If you are solving bugs each and every day and nothing but bugs, you're a bad programmer and you won't survive the business. If you have to do that because you're the bug solving programmer, you probably are just starting (solving bugs is a great way to learn the software and learn programming) and chances are you're not CIO material yet.
So, a nice article that draws some attention but, IMHO of course, full of nonsens.
As for the other article: the 8 reasons why you DON'T want to be the CIO, it's much the same.
Reason #1: we live to write code. True, but I guess that CIOs that have a developer background still continue to write code, or at least will research (new) code developments. You will be the senior in the company (after all, you started as a developer) and chances are there will be some hungry young dogs trying to learn from you. You won't leave your code: you only get to pick the nice pieces to be involved in.
Reason #2: seeing the fruits of your labor. Being a CIO for once you can make the decisions that you think are good for the software and the company. If you have sound ideas, the company will improve with your leadership and you will see the best measurable results possible: an increase in turnover. The results of a days work as a programmer is a nice piece of code that makes it through the unit test cleanly. The results as a CIO will show in the daily sales of licenses and positive customer feedback. I'd rather have the latter.
Reason #3: being able to speak Java/C/et cetera is a must for a CIO. That's the only way you won't get fooled by the developers that tell you that something isn't possible (anything is!). But, sure, you need to be able to express yourself as a human too, but I require that from my programmers too! If you can't talk Dutch (or English :-)) you would have a hard time surviving in my company. It's not a CIO-only requirement: it's a human's requirement to be able to express yourself.
Reason #4: there probably are a couple of people that want to be remembered for their hacking capabilities. But, again IMHO, hacking is stupid. If you are such a good programmer that you can do some facinating stuff, apply your abilities to do some good and useful work. It's a waste to spend your talents at stuff that gets people mad. You can do a lot better in making people happy.
Reason #5: sucking up to other people with jobs beginning with C's. What nonsense. If you are a good CIO, you will be taken as an equal amongst those C's. If you're not, you're not in a technology company and/or you're no good. If you find yourself sucking up the whole time you probably did it before (and you might even have gotten the C-job for it), but you won't make it.
Reason #6: the reference in the article to point #1 is a good one, because the same counter arguments apply. As the CIO you for once get to pick the directions and you will be able to do some real innovation that has an impact in the company. As a developer you will find you write just a bit more clever code that nobody will see. You'll take pride in that, but it will only matter to yourself.
Reason #7: not liking Powerpoint. If so, use something else: easy. Use video, music, exotic dansers. You're the guy with the 'C': pick your own tools. Now you can!
And for reason #8: that will all change, once YOU are the CIO. All the other developers will think: thank god, we now DO HAVE somebody that has a clue.
Again, Just My 2Cents Worth.
Bye,
Bart
Friday, August 01, 2008
I don't get anonymous methods...
Today I watched a presentation by Adreano Lanusse and David I on Tiburon. Nothing really new was shown from the things we already know. Luckily there were a couple of exceptions showing up as my installation does from time to time :-) And I now know that showing recorded videos using Microsoft Live Meeting is not a very good idea. The upload speed of the host was just not good enough. The rest of the presentation was pretty good to watch.
During the presentation we could ask questions and mine was: what's up with anonymous methods?
We've probably all seen the example of anonymous methods shown at http://blogs.codegear.com/davidi/2008/07/23/38915.
I just don't get why you want to use anonymous methods and I'm afraid Adreano and David were not able to explain it to me.
Why wouldn't you use a private class method? Or an local procedure? I really tried but I can't think of a situation where you want to use an anonymous method.
Who can explain this to my satisfaction? Why would I be happy with those???
Bye,
Bart
During the presentation we could ask questions and mine was: what's up with anonymous methods?
We've probably all seen the example of anonymous methods shown at http://blogs.codegear.com/davidi/2008/07/23/38915.
I just don't get why you want to use anonymous methods and I'm afraid Adreano and David were not able to explain it to me.
Why wouldn't you use a private class method? Or an local procedure? I really tried but I can't think of a situation where you want to use an anonymous method.
Who can explain this to my satisfaction? Why would I be happy with those???
Bye,
Bart
What are those prizes in the race - (part of) part 3
You might be wondering what's keeping part 3 of the reviews on the prizes in the race. To be honest: I started looking at RemObjects' DataAbstract but business has kept me from looking at the software properly. It's not your daily component pack that your can write a quick review about. It's a proper software framework that needs a good looking at before coming up with an impression. So, please bear with me, the review will come, but it may take me a bit of time.
Bye,
Bart
Impressions from the webcast by Embarcadero
Yesterday I attended (half of) a webcast by Embarcadero presenting their products. Everytime I attend such a webcast I am amazed that it actually works. LiveMeeting (and all their competitors for that matter) really work and help to do a presentation from a distance.
But, the presentation itself gave me some strange feelings. I must tell you that I am probably not in the target group of Embarcadero of their ' original' products. I only have one database to maintain (the one that is used by Sevensteps' software) and that is not a complex one at all. That's also why I only saw half of the presentation: I realized that I probably won't use their products and will look at the Tiburon presentation later today. That's more my cup of tea.
There's another thing that I noticed in the presentation: the user interfaces that I saw were terrible! I saw an enormous amount of cluttered screens, about a trillion buttons in toolbars, 'old fashioned' icons and very complex dialogs. There was one tabbed dialog that had about 20 pages with numerous controls on each page. There were also wizards that help you do some complex work, but the wizards themselves were very complex and did not have a clear and clean design.
I probably understand were that's coming from. From what I saw the software can do a lot of complex tasks for you and you can pick from a large range of database (formats) to choose from. That probably is the reason why the user interface is so complex: there is a lot to do on a lot of database formats.
If I were to redesign the user interface I would start with one option screen where you can pick the database formats that your are interested in. Probably there's only one or two formats that you will be working on (in that session). Based on that choice I guess you can lose half of the buttons, options and windows
Also, in a dialog or wizard, when an page is not available due to previously made decisions: hide the page, don't just make it disabled. It will clean up the windows a lot and will make the software a bit easier to use. There was a wizard with a couple of tabbed pages which only had one active page of the 10 available. That's not a good design. If you only have one page available: lose the tab. There is no point in showing the other, disabled tabs.
That's just my 2 cents worth for now. I only hope that we get better user interfaces in Tiburon...
Bye,
Bart
Wednesday, July 30, 2008
And the winner is: Werewolf
The results are final. Werewolf, our superfast, late entry, has just won the race by a couple of votes from Jan Wicher. Werewolf, Jan and third place Tom Glenn will pick their prizes from the prizes made available by our sponsors.
First and second prizes were won with Delphi programs. Third place Tom Glenn made a fine contribution using C#.
Congratulations to them and thanks a lot to the contenders that didn't win a prize. To me, it was a lot of fun to be involved in this, albeit not as a contender. Who know, this might become an anual event. I will keep the website alive for the next year or so.
Bye for now,
Bart
First and second prizes were won with Delphi programs. Third place Tom Glenn made a fine contribution using C#.
Congratulations to them and thanks a lot to the contenders that didn't win a prize. To me, it was a lot of fun to be involved in this, albeit not as a contender. Who know, this might become an anual event. I will keep the website alive for the next year or so.
Bye for now,
Bart
Monday, July 28, 2008
Two days of voting left...
It is becoming a very tight race. There are three contenders for first place and the are only seperated by a couple of cotes. If you want to be the deciding vote, go to the site now and pick your winner.
Bye,
Bart
Bye,
Bart
Friday, July 25, 2008
Races within the race
Now the voting has started for the winner of the Darwin Race of Languages the favorites are seperating from the pack. Two contenders are battling it out for the first two places and two others are fighting for third place. As you may know, there are three prizes to win, so there will be a couple of disappointments I'm afraid.
You can still have your say about the entries and make a difference for the contenders, so go the the website, try the published programs and vote the winner. The published programs are all well worth looking at and you might even find them usefull. I know I have one of them as a startup utility installed already - I will tell you which when the race is over :-)
Bye,
Bart
You can still have your say about the entries and make a difference for the contenders, so go the the website, try the published programs and vote the winner. The published programs are all well worth looking at and you might even find them usefull. I know I have one of them as a startup utility installed already - I will tell you which when the race is over :-)
Bye,
Bart
Wednesday, July 23, 2008
You can now vote for the winner of the race...
The results are in and you can now vote the winner in the Darwin Race of Languages competition. Seven of the participants entered a solution to one of the three problems and I think they are all worth examining. There are some very usefull utilities to be found there.
Go to the website and check out what the participants did and how they did it. On 30 July the winners to the competition will be announced and prizes will be handed over.
Bye,
Bart
Go to the website and check out what the participants did and how they did it. On 30 July the winners to the competition will be announced and prizes will be handed over.
Bye,
Bart
Monday, July 21, 2008
Hans Starborg submits his entry
As time is running out for the race - there is only one day of programming left - Hans Starborg has published his results. All the results must be in by the end of tomorrow. From Wednesday on the audience can vote for the winners in the race. If you like you can already check some of the entries out.
Bye,
Bart
Bye,
Bart
Subscribe to:
Posts (Atom)
Posts
