Branden Tanga, the guy that gave me the idea for this race, just entered the race AND he will enter a Delphi program watching CPU load and temperatures.
Now, that's bravery for you. In my book he gets extra points just for entering.
So, come on everybody out there. We all (including me) were a bit harsh on him and told him that he should use the tool first, was completely false in some departments and do some real work before criticizing our favorite tool.
He picked up the challenge! How about you??????
Go to http://www.darwinraceoflanguages.com/ and read all about it. To enter, just drop me an email at bart.roozendaal@sevensteps.nl
Bye,
Bart
Saturday, July 05, 2008
Thursday, July 03, 2008
Three languages are now represented...
But, we need more than one programmer per language :- . So, are there any more programmers that want to join the race? You still have 5 days to register at http://www.darwinraceoflanguages.com/.
Bye,
Bart
Bye,
Bart
Labels:
Delphi
Wednesday, July 02, 2008
The first participants in the race
The first two participants in the race (DarwinRaceOfLanguages.com) have entered: one Delphi guy and one Mac guy. We need (a lot) more to make it a true race. So, go on, go to the website and see how to enter this race.
There's also a suggestion by one of the participants that applications suitable for portableapps.com can get extra points. I think that's a very good suggestion.
If you think I should twist this or that rule, or maybe add another problem to the list to pick from, don't hesitate to let me know. The rules are still open for debate until 8 July when the race starts.
Bye,
Bart
There's also a suggestion by one of the participants that applications suitable for portableapps.com can get extra points. I think that's a very good suggestion.
If you think I should twist this or that rule, or maybe add another problem to the list to pick from, don't hesitate to let me know. The rules are still open for debate until 8 July when the race starts.
Bye,
Bart
Labels:
Delphi
Tuesday, July 01, 2008
The Darwin Race of Languages is on...
The race is on. A couple of hours later than I promised (sorry, I've got work to do also :-)) I put up the website and you can now officially enter the race.
Please point to http://www.darwinraceoflanguages.com for more information on what to do. If nobody enters the race, I get to keep the prizes! There were over 50 people that said they would enter the race: let's see how many of you will!
Please comment to this posting if you have any remarks about the problems to pick from, the rules, the schedule or otherwise. It's an open competition, but after 8 July the rules cannot change.
Good luck everybody!
Bye,
Bart
Please point to http://www.darwinraceoflanguages.com for more information on what to do. If nobody enters the race, I get to keep the prizes! There were over 50 people that said they would enter the race: let's see how many of you will!
Please comment to this posting if you have any remarks about the problems to pick from, the rules, the schedule or otherwise. It's an open competition, but after 8 July the rules cannot change.
Good luck everybody!
Bye,
Bart
Labels:
Delphi
Sunday, June 29, 2008
The Darwin Race of Languages - Part 4
Another sponsor has volunteered to give away a prize. RemObjects will give away a copy for Data Abstract. The winner gets to pick which version, .NET or Delphi.
Tomorrow will be the launch of the website with the rules of engagement, so keep your eyes on http://www.darwinraceoflanguages.com/
Bye,
Bart
Tomorrow will be the launch of the website with the rules of engagement, so keep your eyes on http://www.darwinraceoflanguages.com/
Bye,
Bart
Labels:
Delphi
Friday, June 27, 2008
The Darwin Race of Languages - part 3
The first sponsor has offered to come up with a price. GurockSoftware will kindly offer a license to SmartInspect as a prize for the race. I'm in contact with a couple of other companies out there. If you are a company that has products suitable for Delphi as well as/or for Visual Studio or any of the other IDEs out there, this might be a good time to have some cheap publicity.
To reassure any of the companies that are thinking of sponsoring: this is not a bashing contest. It's about getting and sharing real life experiences writing software. Taking away the basing of a product just because you think it's bad, is just exactly what started this little contest. Any bashing through comments or otherwise won't get published on the website.
So, if you are still thinking about it, maybe this little notice will help :-)
Bye,
Bart
To reassure any of the companies that are thinking of sponsoring: this is not a bashing contest. It's about getting and sharing real life experiences writing software. Taking away the basing of a product just because you think it's bad, is just exactly what started this little contest. Any bashing through comments or otherwise won't get published on the website.
So, if you are still thinking about it, maybe this little notice will help :-)
Bye,
Bart
Labels:
Delphi
The Darwin Race of Languages - Part 2
So, the race is on :-) If within 24 hours more than 20 people think they will enter the race, there's no holding back.
There will be a little web site next week on http://www.darwinraceoflanguages.com/. I will need a bit of time to work things out and put them up there, but it's already work in progress.
There are a couple of things that you can help me with:
There will be a little web site next week on http://www.darwinraceoflanguages.com/. I will need a bit of time to work things out and put them up there, but it's already work in progress.
There are a couple of things that you can help me with:
- Find C#, C++, Java or other programmers to enter the race. A race is not a race without different horses, is it? Spread the word amongst news groups, friends, colleagues, et cetera.
- Help me pick a tool or program to build. I'm currently thinking of offering three subjects to pick from. I have the following suggestions:
- A GUI for a Firebird compression tool
- A tool to convert code on the clipboard to html for using it in a blog posting
- (we need more!)
- Bug your boss to supply us with prices to give away. If you're the boss: handover those goodies :-). A small gesture is fine: it's all about honor anyway.
- Go to http://www.dzone.com/links/the_darwin_race_of_languages.html and promote that up the ladder so more people in the developers community get a notice of this.
The plan so far
- 1 July: launch of the web site for the race. There will be some explanation on the race, what the purpose is, how to enter, et cetera. It will be a democratic race: there will be a voting system to pick a winner.
- 8 July: entry closes. The race begins. There will a short 2 week sprint in which you can spend as much time as you want to and can afford to. You don't necessarily need to enter a full working program; it's more about how the language and the tool helped or hindered you in your work - you will need to write something about that.
- 22 July: the race closes and the results will be published. Extra points will be awarded to people that documented their experiences during work. The voting begins.
- 29 July: the voting completes and the winner gets the price (whatever it will be...)
Plans of course can be changed, and the format of the race is much open for debate. So, please send in your remarks.
Bye,
Bart
Labels:
Delphi
Thursday, June 26, 2008
The darwin race of languages
Update: the race is on
It's funny how fanatical people (including me) can get when we are talking about the IDEs that we favor. If someone comes up with some (partly false) statements about out beloved (...) Delphi, we all (including me) jump up and start making a case for our pet. I don't think the guy was expecting that many comments after his posting. I can almost see him scratching his head :-)
Now, I think that's a very good thing. My post about dying Delphi programmers was intended to stir up some things and in the end I might have found a (couple of) new programmer(s). Besides all the public comments I have had hundreds of reactions in my email box. So, I can concluded, the Delphi programmers are still fighting to come out of top of the Darwin race of languages.
Now, I was thinking. There already must be a developer contest out there to compare Delphi to other languages. I couldn't find one though (but that might be because it's still early days yet :-))
How about setting one up? Let's find a small program (if in the end it is also usefull, all the better) and let's see what the results are when developing it with, let's say, Delphi and C#.
Now, before all the comments come in :-) I know that we would probably only compare the capabilities of the programmer, not the language. And, choosing C# would probably mean choosing .Net. If we would use Delphi for Win32 that means a comlpetely different platform. But, nevertheless, I think it would be fun to see what would happen.
So, please send in your suggestions for a small, but usefull program that could be the subject for this. It could be something like my all time favorite Stickies, but anything goes really.
If you think this is a fun thing to do, I will try to arrange for this and maybe even find some sponsors for prices to award.
Bye,
Bart
It's funny how fanatical people (including me) can get when we are talking about the IDEs that we favor. If someone comes up with some (partly false) statements about out beloved (...) Delphi, we all (including me) jump up and start making a case for our pet. I don't think the guy was expecting that many comments after his posting. I can almost see him scratching his head :-)
Now, I think that's a very good thing. My post about dying Delphi programmers was intended to stir up some things and in the end I might have found a (couple of) new programmer(s). Besides all the public comments I have had hundreds of reactions in my email box. So, I can concluded, the Delphi programmers are still fighting to come out of top of the Darwin race of languages.
Now, I was thinking. There already must be a developer contest out there to compare Delphi to other languages. I couldn't find one though (but that might be because it's still early days yet :-))
How about setting one up? Let's find a small program (if in the end it is also usefull, all the better) and let's see what the results are when developing it with, let's say, Delphi and C#.
Now, before all the comments come in :-) I know that we would probably only compare the capabilities of the programmer, not the language. And, choosing C# would probably mean choosing .Net. If we would use Delphi for Win32 that means a comlpetely different platform. But, nevertheless, I think it would be fun to see what would happen.
So, please send in your suggestions for a small, but usefull program that could be the subject for this. It could be something like my all time favorite Stickies, but anything goes really.
If you think this is a fun thing to do, I will try to arrange for this and maybe even find some sponsors for prices to award.
Bye,
Bart
Labels:
Delphi
Wednesday, June 25, 2008
Delphi's Play Of The Day
Nothing to do with Delphi, but this is my Play Of The Day
Come on guys, don't say you saw this one coming!
Correction: I didn't see it coming. As commented, this is a staged (I won't call it a fake) video. But, IMHO, that makes it twice as funny :-)
Labels:
Delphi
Creating an always on top web browser window
For one of the publications in the LearningGuide Manager we needed an 'always on top'-browser window with some information in it. The Learning Guides provide support information to end users. This information needs to stay on top while working on other software.
A normal browser window isn't suitable because you cannot make that always on top. In the past all kinds of hacks and workarounds were available, but tabbed browsing, increased security and the like make it impossible to do something from within the broser (I think ... if you think otherwise, please let me know).
The publications are HTML based and must run on every browser possible. In the past we used OCX-es to implement such features but with the increase in diversity of browsers another solution was needed, since there are only a few (...) browser that support OCX-es.
Here's what we did (I think it's kind of neat). We created a small application that is deployed on the client systems. This application does a lot of things, but also has a TIdHTTPServer which listens at the localhost of the client. It listens for special urls which can do special things.
One the commands is to open an always on top window which has a TWebBrowser component in it and will serve a passed url. E.g. an url like http://localhost/cgi-bin/show?http://www.google.com will popup an always on top window with the google website in it. There's a whole range of commands that can do special things - one's only limited to the imagination of the day.
Of course there are some measures to prevent abuse of this method (which I won't disclose here...) and in the end we have a platform and browser indepent solution to do all kinds of special things next to simply serve HTML files to the end user.
Bye,
Bart
A normal browser window isn't suitable because you cannot make that always on top. In the past all kinds of hacks and workarounds were available, but tabbed browsing, increased security and the like make it impossible to do something from within the broser (I think ... if you think otherwise, please let me know).
The publications are HTML based and must run on every browser possible. In the past we used OCX-es to implement such features but with the increase in diversity of browsers another solution was needed, since there are only a few (...) browser that support OCX-es.
Here's what we did (I think it's kind of neat). We created a small application that is deployed on the client systems. This application does a lot of things, but also has a TIdHTTPServer which listens at the localhost of the client. It listens for special urls which can do special things.
One the commands is to open an always on top window which has a TWebBrowser component in it and will serve a passed url. E.g. an url like http://localhost/cgi-bin/show?http://www.google.com will popup an always on top window with the google website in it. There's a whole range of commands that can do special things - one's only limited to the imagination of the day.
Of course there are some measures to prevent abuse of this method (which I won't disclose here...) and in the end we have a platform and browser indepent solution to do all kinds of special things next to simply serve HTML files to the end user.
Bye,
Bart
Labels:
Delphi
Saturday, June 21, 2008
Are Delphi programmers a dying breed?
For some time now we are looking for new Delphi programmers in our company and were unsuccessful in finding any Dutch programmers. We hardly had any response to advertisements and posting on job sites.
Of course, when you start doing that, you are approached by outsourcing companies. One of those contacted me 'at the right time' and we did a small trial project (not in Delphi though) to see what is involved when outsourcing software. The results were mixed (speed was low and quality was ... well poor). The price is right though, so that makes one hesitate. But, I found with this particular company - as well as with other outsourcing companies that approachedme - that they all could offer Delphi programmers, but "would start looking for one once the project goes through". None of the companies that approached me had any inhouse Delphi programmers.
So, adding that up, no local Delphi programmers are available, and no outsourcing company (that I know off) have inhouse Delphi programmers.
We are seriously considering switching to C#/.NET although programmers in that field don't come by the dozens either :- But at least, there are some outsourcing companies out there that say that they can deliver good C# programmers.
It kind of feels to me like the days when I still was a Cobol programmer. That breed almost died, and of course as a contractor that made sure you got a good price for your work :-).
Will the Delphi programmers go the same way? What do you think?
And hey, while we're at it, if you know any affordable outsourcing company with inhouse Delphi programmers, please let me know.
Bye,
Bart
Of course, when you start doing that, you are approached by outsourcing companies. One of those contacted me 'at the right time' and we did a small trial project (not in Delphi though) to see what is involved when outsourcing software. The results were mixed (speed was low and quality was ... well poor). The price is right though, so that makes one hesitate. But, I found with this particular company - as well as with other outsourcing companies that approachedme - that they all could offer Delphi programmers, but "would start looking for one once the project goes through". None of the companies that approached me had any inhouse Delphi programmers.
So, adding that up, no local Delphi programmers are available, and no outsourcing company (that I know off) have inhouse Delphi programmers.
We are seriously considering switching to C#/.NET although programmers in that field don't come by the dozens either :- But at least, there are some outsourcing companies out there that say that they can deliver good C# programmers.
It kind of feels to me like the days when I still was a Cobol programmer. That breed almost died, and of course as a contractor that made sure you got a good price for your work :-).
Will the Delphi programmers go the same way? What do you think?
And hey, while we're at it, if you know any affordable outsourcing company with inhouse Delphi programmers, please let me know.
Bye,
Bart
Labels:
Delphi
Thursday, June 12, 2008
SHFileOperation / Vista and oh boy ...
Yesterday I reported problems using SHFileOperation on Vista in a multi threading application. I experienced problems overwriting files when running Vista. The problems didn't occur running XP or Windows 2003 server.
For starters: it has nothing to do with multi threading applications - that was a false assessment on my part. I should stop working so late :-(
Comments from other programmers made me look again and create a small program that demonstrated the problem. I could not reproduce it using the small demo. So what gives?
It turned out the problems were cause by the specification of the file paths. The program I'm working on synchronizes folders, having the source on the web or on a local file system.
It turned out I was feeding paths using a '/' as a folder delimiter instead of a '\'. XP and Windows 2003 don't have a problem with that, Vista does...
In this case, changing the forward slashes to backslashes solved the problem. Still, kind of weird, but a smaller problem than SHFileOperation not being thread safe.
Bye,
Bart
For starters: it has nothing to do with multi threading applications - that was a false assessment on my part. I should stop working so late :-(
Comments from other programmers made me look again and create a small program that demonstrated the problem. I could not reproduce it using the small demo. So what gives?
It turned out the problems were cause by the specification of the file paths. The program I'm working on synchronizes folders, having the source on the web or on a local file system.
It turned out I was feeding paths using a '/' as a folder delimiter instead of a '\'. XP and Windows 2003 don't have a problem with that, Vista does...
In this case, changing the forward slashes to backslashes solved the problem. Still, kind of weird, but a smaller problem than SHFileOperation not being thread safe.
Bye,
Bart
Labels:
Delphi
Wednesday, June 11, 2008
SHFileOperation not thread safe under Vista
I found the 'cause' of the problems with the SHFileOperation function in Vista I reported earlier. It turns out that this function is not thread safe under Vista. It works fine with earlier operating systems when used in a multi threading application.
For now, the problem in my situation was (somewhat) easy to fix. I now execute the ShFileOperation in the main thread (using Synchronize) and that solved the problem with the utilities that I was working on. I can imagine that for larger application a bit more work would be involved. But maybe this little piece of information helps others.
I will implement the IFileOperation interface for Vista later on, but for now it can wait...
Bye,
Bart
For now, the problem in my situation was (somewhat) easy to fix. I now execute the ShFileOperation in the main thread (using Synchronize) and that solved the problem with the utilities that I was working on. I can imagine that for larger application a bit more work would be involved. But maybe this little piece of information helps others.
I will implement the IFileOperation interface for Vista later on, but for now it can wait...
Bye,
Bart
Labels:
Delphi
IFileOperation replaces SHFileOperation on Vista
Today I got some reports from users that part of our file handling functions gave irregular results. On my development machine (a Windows 2003 Server) all was well and I could not replicate the problems.
After some digging into these issues I found a couple of postings (this one in de MSDN amongst others) about a new interface (IFileOperation) in Vista that replaces the SHFileOperation function.
Now, most of my code works just fine, but I have some specific problems with overwriting files that already exist. Some get overwritten, others don't. I suspect the SHFileOperation functions that (apparently) are still availble under Vista aren't quite backwards compatible.
Luckily I have created some wrapper functions in my code around the SHFileOperation functions, so it will be fairly easy to implement the IFileOperation method of Vista. But, being under pressure as always, this wasn't what I was waiting for right now :-o.
If I encounter any special issues I will let you know.
Bye,
Bart
After some digging into these issues I found a couple of postings (this one in de MSDN amongst others) about a new interface (IFileOperation) in Vista that replaces the SHFileOperation function.
Now, most of my code works just fine, but I have some specific problems with overwriting files that already exist. Some get overwritten, others don't. I suspect the SHFileOperation functions that (apparently) are still availble under Vista aren't quite backwards compatible.
Luckily I have created some wrapper functions in my code around the SHFileOperation functions, so it will be fairly easy to implement the IFileOperation method of Vista. But, being under pressure as always, this wasn't what I was waiting for right now :-o.
If I encounter any special issues I will let you know.
Bye,
Bart
Labels:
Delphi
Thursday, May 29, 2008
I'll better my life as a designer, promised...
As you may read on my blogs I sometimes write for pdalive.com about using my smartphone and evaluating software on it. My last post was about Windows Mobile 6.1 on my TYTN II. Although the update was minor (from 6.0 to 6.1 is a small step after all), there is something in this update that made me realize something important about creating updates of my own software.
There is a couple of things in WM 6.0 that I always did wrong. E.g. when I want to lock my phone, I press and hold the red 'hang up' button. This locks the device so I can't make an accidental call to someone (something that happened quite a lot before I made a habbit of locking my phone). But, when you lock the phone, it locks with the current application in front. Most of the times I want the home screen active before I lock it. So, I made a habbit of activating the home screen before I locked the device. Frequently this means unlocking the phone, activating the home screen, and lock the phone again. But, I also want the first page of the HTC pluging (which displays a clock) active. So, most of the times, I unlock the phone yet another time, activate the first page on the HTC plugin before locking it finally.
Besides all the 'major' improvements in the WM 6.1 update, this is something that either Microsoft or HTC now does for me. Whenever you press and hold the read 'hang up' button, the home screen is made the active application and the first page of the HTC plugin is selected before locking the device. Apparently, other users found themselves performing the same procedure as I did in WM 6.0.
Now, what's all this got to do with my life as a designer? Well, I realized that I was very please to find such a small improvement in a new release of the software. It's not something a sales person can use to sell additional licenses with, but it is a change that makes the life of a uses just that tiny bit better.
I want to add more of such things to the releases of our own software. I want my users to get the same pleased feeling about our software when they start using a new release. I want them constantly thinking: hey, that's great! Simply because a little function or feature just does it's job a bit better.
From a commercial point of view it might be much better to have big new features in your release (like support flow charts in our upcoming main release version 6). But, and that is the promise, I will make sure that version 6.1 will have a big focus on all those little things that can make you go oooh. I think in the end, that will pay off, even from a commercial point of view.
Bye,
Bart
There is a couple of things in WM 6.0 that I always did wrong. E.g. when I want to lock my phone, I press and hold the red 'hang up' button. This locks the device so I can't make an accidental call to someone (something that happened quite a lot before I made a habbit of locking my phone). But, when you lock the phone, it locks with the current application in front. Most of the times I want the home screen active before I lock it. So, I made a habbit of activating the home screen before I locked the device. Frequently this means unlocking the phone, activating the home screen, and lock the phone again. But, I also want the first page of the HTC pluging (which displays a clock) active. So, most of the times, I unlock the phone yet another time, activate the first page on the HTC plugin before locking it finally.
Besides all the 'major' improvements in the WM 6.1 update, this is something that either Microsoft or HTC now does for me. Whenever you press and hold the read 'hang up' button, the home screen is made the active application and the first page of the HTC plugin is selected before locking the device. Apparently, other users found themselves performing the same procedure as I did in WM 6.0.
Now, what's all this got to do with my life as a designer? Well, I realized that I was very please to find such a small improvement in a new release of the software. It's not something a sales person can use to sell additional licenses with, but it is a change that makes the life of a uses just that tiny bit better.
I want to add more of such things to the releases of our own software. I want my users to get the same pleased feeling about our software when they start using a new release. I want them constantly thinking: hey, that's great! Simply because a little function or feature just does it's job a bit better.
From a commercial point of view it might be much better to have big new features in your release (like support flow charts in our upcoming main release version 6). But, and that is the promise, I will make sure that version 6.1 will have a big focus on all those little things that can make you go oooh. I think in the end, that will pay off, even from a commercial point of view.
Bye,
Bart
Friday, May 23, 2008
TYTN II Rom update: go for it
I couldn't hold myself. Yesterday some sites (I saw it first on the Dutch site www.allaboutphones.nl) reported the leaking of the offical to be ROM update for my HTC TYTN II. This update should include Windows Mobile 6.1 and - reportedly - speed improvements of the display drivers.
Of course I am also reading the forums of the XDA developers (http://forum.xda-developers.com/) where a lot of work is done on 'custom' ROMs. WM 6.1 is out there for quite some time now. But, since I am still in the warranty period of my HTC TYTN II, I never decided to install a ROM-update, although I was longing for it very much.
But I believed the posters yesterday, telling us that the leaked updates are the offical ones. The story is that they are leaked to have some 'cheap' evaluation with expert users by HTC. Fine by me. So this time I jumped in and installed this update and am now running on WM 6.1 on my TYTN II.
SO, what is it like? I can only say: great! The phone responds much faster, feels a lot quicker. It boots quicker and I get the feeling that the phone has come to life. I never found it that bad, despite my agreement with things stated at www.htcclassaction.org). But having the WM 6.1 update installed I can relate to the frustration of the guys behind htcclassaction.org even more. IMHO it's a disgrace that HTC has sold me a phone for a lot of money that could perform a lot better, simply by installing the right drivers.
Now, I also understand that the improvements are only partial of what the chips are capable of. I'm keeping an even closer eye now on all those hacker sites. I want more of these improvements, absolutely. My call to HTC: make these improvements even better en implement them for all phones. You will gain a lot of respect if you do and customer satisfaction leads to increase in sales in the end. To read my opinion on how great customer support helps sales, please read my blog item on that. I was seriously considering the upcoming iPhone 3G, but this improvement will make me wait a while. At least until WM 7 is out... I hope Microsoft will deliver something that is stunning. It needs to I'm afraid :-)
That's that on the speed improvement. Now, what about WM 6.1. Of course a lot is already said on that subject. Most find the improvements minor. You can't disagree with that, but I think threaded sms, zooming in IE and the overall speed improvement is very valuable. I was getting hooked on Opera mini, but the zooming in IE makes me doubt that a bit. So, here's another call to HTC: make Opera 9.5 mobile available on *all* your phones, not just the Diamond. It will hook your customers to your products even more. Most of us buy a new phone every 6 - 24 months and chances that being a HTC improve vastly if the customer is satisfied.
So, if you're not a hero, wait for the official ROM update, but get it as soon as it's there. It is very much worthwhile. If you are a hero, go get it now.
Google for RUU_Kaiser_HTC_WWE_3.28.405.0_radio_sign_25.83.40.02_1.65.16.25_Ship and you'll find the English update.
Google for RUU_Kaiser_HTC_NLD_3.29.404.0_radio_sign_25.83.40.02_1.65.16.25_Ship and you'll find the Dutch update.
I'm only so sorry for everyone that doesn't get this update on their HTC phone...
Bye,
Bart
Of course I am also reading the forums of the XDA developers (http://forum.xda-developers.com/) where a lot of work is done on 'custom' ROMs. WM 6.1 is out there for quite some time now. But, since I am still in the warranty period of my HTC TYTN II, I never decided to install a ROM-update, although I was longing for it very much.
But I believed the posters yesterday, telling us that the leaked updates are the offical ones. The story is that they are leaked to have some 'cheap' evaluation with expert users by HTC. Fine by me. So this time I jumped in and installed this update and am now running on WM 6.1 on my TYTN II.
SO, what is it like? I can only say: great! The phone responds much faster, feels a lot quicker. It boots quicker and I get the feeling that the phone has come to life. I never found it that bad, despite my agreement with things stated at www.htcclassaction.org). But having the WM 6.1 update installed I can relate to the frustration of the guys behind htcclassaction.org even more. IMHO it's a disgrace that HTC has sold me a phone for a lot of money that could perform a lot better, simply by installing the right drivers.
Now, I also understand that the improvements are only partial of what the chips are capable of. I'm keeping an even closer eye now on all those hacker sites. I want more of these improvements, absolutely. My call to HTC: make these improvements even better en implement them for all phones. You will gain a lot of respect if you do and customer satisfaction leads to increase in sales in the end. To read my opinion on how great customer support helps sales, please read my blog item on that. I was seriously considering the upcoming iPhone 3G, but this improvement will make me wait a while. At least until WM 7 is out... I hope Microsoft will deliver something that is stunning. It needs to I'm afraid :-)
That's that on the speed improvement. Now, what about WM 6.1. Of course a lot is already said on that subject. Most find the improvements minor. You can't disagree with that, but I think threaded sms, zooming in IE and the overall speed improvement is very valuable. I was getting hooked on Opera mini, but the zooming in IE makes me doubt that a bit. So, here's another call to HTC: make Opera 9.5 mobile available on *all* your phones, not just the Diamond. It will hook your customers to your products even more. Most of us buy a new phone every 6 - 24 months and chances that being a HTC improve vastly if the customer is satisfied.
So, if you're not a hero, wait for the official ROM update, but get it as soon as it's there. It is very much worthwhile. If you are a hero, go get it now.
Google for RUU_Kaiser_HTC_WWE_3.28.405.0_radio_sign_25.83.40.02_1.65.16.25_Ship and you'll find the English update.
Google for RUU_Kaiser_HTC_NLD_3.29.404.0_radio_sign_25.83.40.02_1.65.16.25_Ship and you'll find the Dutch update.
I'm only so sorry for everyone that doesn't get this update on their HTC phone...
Bye,
Bart
Labels:
pdalive
Wednesday, May 14, 2008
Windows Ultimate Extras is a sham... I agree
Today I finished installing Windows Vista Ultimate edition. My machine was ready for a fresh install, something I do about once a year. Since we have a partnership with Microsoft I decided to install the Ultimate edition. Who doesn't want that anyway? I want everything in the Ultimate edition if that's available :-)
When I finished installing this version I went looking for all the extras that I remembered that were promised by Microsoft. I only found the poker game. The DreamScene did't want to start when I had two monitors connected to my portable. After disconnecting the external monitor I enjoyed the videos on the desktop for at least a minute or so. Then I realized that M$ was asking a ton of money for, well, just a handfull of useless things. Yes, more fun, but not for longer than a minute or so. Not worth the money at all. Although I am very MS-minded, I was very disappointed with what MS calls the Ultimate. I found this nice looking website which I wouldn't have otherwise, so there is something good in all this :-)
Btw, I had some problems installing update 2 of the BDS 2006 I am using, but found this article that solved the problem. I had to read it three times to realize I had to start the command box as an Administrator, but I'm up and running now.
When I finished installing this version I went looking for all the extras that I remembered that were promised by Microsoft. I only found the poker game. The DreamScene did't want to start when I had two monitors connected to my portable. After disconnecting the external monitor I enjoyed the videos on the desktop for at least a minute or so. Then I realized that M$ was asking a ton of money for, well, just a handfull of useless things. Yes, more fun, but not for longer than a minute or so. Not worth the money at all. Although I am very MS-minded, I was very disappointed with what MS calls the Ultimate. I found this nice looking website which I wouldn't have otherwise, so there is something good in all this :-)
Btw, I had some problems installing update 2 of the BDS 2006 I am using, but found this article that solved the problem. I had to read it three times to realize I had to start the command box as an Administrator, but I'm up and running now.
Friday, May 09, 2008
Embarcadero: you'd better keep Delphi/Win32!
The storm of postings has died out (a bit), so let's give my two cents worth. First of all: I'm only thinking about Delphi for Win32 here. I'm not particularly interested in the other CodeGear products I'm afraid. So I won't bother you with my comments about those.
All the postings on the aquisition are quite positive about the future of the products, Delphi for Win32 not excluded from that. I'm not so sure though. A take over/merger like this inevitably will lead to a refocus of the future of products and services. Embarcadero will probably take this opportunity to save and extend profitable products and cut those that are not. Now is the time to do so: everybody (employees / customers / partners) will be open for that and will understand such moves. It's common sense, right?
If the above thought is true: what are the chances for Delphi/Win32? Somewhere along the line the following discussion will come up:
(boss/financial manager/commercial manager): Ok, we've cut the number of products. What do we do?
(A): Let's drop Delphi/Win32
(B,C,D..Z): NO! We can't! There are too many developers and products out there.
(A): Well, let them move to Delphi/.NET!
(B,C): That's a thought. Yeah, why not. I never had a problem with that...
(D,E,F..Z): But, that's a completely different way of working for them...
(A,B,C): They probably will have to anyway in the future and most of them won't mind.
(D,E,F,G): That's right, I never had but positive effects since I changed.
(H,I,...Z): But, what about the Tiburon? Didn't we just update the roadmap for that?
(A,B,...Y): If they want Unicode and stuff: let them use .Net. It's the future. And of course, they can always keep using Delphi2007.
(Z): Why doesn't anybody ever listen to me?
I would really hate it if this happens, but - to be open and frank - I could relate to such a thought. Cut the (large) number of products and focus on the ones that have the real future. It would give me an immediate problem (well, not that immediate, there's always Delphi2007, right?) but I would understand it, really.
But, I don't think I would switch to Delphi.Net to be honest. I think C#/.Net would really come into the picture in that case. Give the problems I have to find good Delphi developers (if you know a good Dutch Delphi developer send him/her to me now!) I would really consider leaving Delphi.
Others might go that line too. So, Embarcadero: you'd better keep Delphi/Win32!
All the postings on the aquisition are quite positive about the future of the products, Delphi for Win32 not excluded from that. I'm not so sure though. A take over/merger like this inevitably will lead to a refocus of the future of products and services. Embarcadero will probably take this opportunity to save and extend profitable products and cut those that are not. Now is the time to do so: everybody (employees / customers / partners) will be open for that and will understand such moves. It's common sense, right?
If the above thought is true: what are the chances for Delphi/Win32? Somewhere along the line the following discussion will come up:
(boss/financial manager/commercial manager): Ok, we've cut the number of products. What do we do?
(A): Let's drop Delphi/Win32
(B,C,D..Z): NO! We can't! There are too many developers and products out there.
(A): Well, let them move to Delphi/.NET!
(B,C): That's a thought. Yeah, why not. I never had a problem with that...
(D,E,F..Z): But, that's a completely different way of working for them...
(A,B,C): They probably will have to anyway in the future and most of them won't mind.
(D,E,F,G): That's right, I never had but positive effects since I changed.
(H,I,...Z): But, what about the Tiburon? Didn't we just update the roadmap for that?
(A,B,...Y): If they want Unicode and stuff: let them use .Net. It's the future. And of course, they can always keep using Delphi2007.
(Z): Why doesn't anybody ever listen to me?
I would really hate it if this happens, but - to be open and frank - I could relate to such a thought. Cut the (large) number of products and focus on the ones that have the real future. It would give me an immediate problem (well, not that immediate, there's always Delphi2007, right?) but I would understand it, really.
But, I don't think I would switch to Delphi.Net to be honest. I think C#/.Net would really come into the picture in that case. Give the problems I have to find good Delphi developers (if you know a good Dutch Delphi developer send him/her to me now!) I would really consider leaving Delphi.
Others might go that line too. So, Embarcadero: you'd better keep Delphi/Win32!
Labels:
Delphi,
Embarcadero
Monday, April 28, 2008
Folders kept in use
Some time ago I noticed that a couple of small (conversion) programs of mine showed some strange effect. Folders that were used were kept in use. If, even after closing down the program, I tried to delete the folders, Windows told me they were in use.
I looked high and low for this, but in the end found the cause of it all. I didn't close a Find in the folders. Putting a try..finally in the code did the trick. This guaranteed closing the Find, no matter what. So, if you experience that folders are kept in use, go look for this one.
Bye,
Bart
I looked high and low for this, but in the end found the cause of it all. I didn't close a Find in the folders. Putting a try..finally in the code did the trick. This guaranteed closing the Find, no matter what. So, if you experience that folders are kept in use, go look for this one.
procedure foo;
var
sr: TSearchRec;
ok: boolean;
begin
ok := (FindFirst('*.*', faAnyFile, sr)=0);
try
while ok do
begin
goDoSomething();
ok := (FindNext(sr)=0);
end;
finally
FindClose(sr);
end;
end;
Bye,
Bart
Tuesday, April 22, 2008
The top 10 tools every (Delphi) programmer needs
This week I was at a client site to talk about our ways of developing software. Our client uses Delphi for developing their software too and are contemplating using DevExpress' components for their next generation software.
I was stunned to find that (until now) they only use Delphi. That's it. No other support tools or component libraries (apart from the Virtual Tree List).
That meeting inspired me to list the tools I think are absolutely necessary or at least very helpfull in developing (Delphi) software.
1) A professional component library.
As you may have guessed DevExpress is my top one favorite. I hardly need any other components to implement a professional user interface. There is *no* way you can get better results for the amount of money you need to spend on the library. I would always recommend the VCL subscription. It will set you back $500-$1000 every year but you will get a ton of components for that.
There are a couple of alternatives that you might want to look into. I'm sure that I will get some recommendations in the comments on this post :-) Let the list grow...
2) A logging tool / component
Of course you can use OutputDebugString to print debug statements or you can write your own logging tool. But there are a couple of professional libraries out there that already have done that for you (and more than you probably think of at first) and that are extremely usefull.
My favorite is Raize's CodeSite, but SmartInspect is very good also. Again, I'm sure there are others out there.
3) An exception catcher
I don't know another word for this type of tool, but I'm using two actually. Madexcept (which is my favorite, and only $25 for a commercial license) and EurekaLog. It will help you explain exceptions, especially when your software is already in the wild out there.
4) A bug administration tool
There are a couple, but my favorite is FogBugz. It's reasonably priced and does the job very well. It also has a simple but very effectie planning and time tracking feature. It will handle registering the status of issues, mailing to clients, handling received mail, et cetera. Excellent stuff.
5) Version control system
Now, I was perplexed to find that the client I visited didn't use a version control system. I couldn't think of a workable environment without it. We are using Visual SVN Server and Turtoise as a client. Even if you are in a single developer environment you should take the time to set this up. Don't let the costs scare you: it's free...
6) Creating setups
Every piece of software should be delivered in a setup. There's a couple of free (and not so free) tools out there, but we are using Wise for Windows. That's a bit old actually, but does the job very well.
7) Build tools
Now, eventually you have to deliver your software. You can build your software and assemble and distribute the setup by hand, but invest some time in setting up a professional build tool. Once you got the right scripts set up, delivering your software is a snap. We use Automated Build Studio. I actually wrote a testimonial on that which you can find on their website. Good support too.
8) Debugging tools
I don't use many other debuggers from the one in Delphi, but if you need some special things (like profiling the performance of your application), you might want to look elsewhere. We are using AQTime but I don't need it that much to be true. It's only at special occasions that I start that.
9) Unit testers
Every other month or so I tell myself I have to develop some unit tests. I never get to it, but writing this piece makes me a firm believer in unit tests again. I will, honestly, setup some unit tests.... Really, you should do it to.
10) Documentation
Now, here's a bit of plugging our software. How could I ever use anything else but our software for that? Google does it, SAP does it, Microsoft does it, so I'd better use it myself too :-)
If you want more information on what our products can do to your documentation (not only as a technical documenation tool, but for a great variety of documentation needs), please don't hesitate to contact me.
That's my list. What do you have to add, strike or comment?
Bye,
Bart
I was stunned to find that (until now) they only use Delphi. That's it. No other support tools or component libraries (apart from the Virtual Tree List).
That meeting inspired me to list the tools I think are absolutely necessary or at least very helpfull in developing (Delphi) software.
1) A professional component library.
As you may have guessed DevExpress is my top one favorite. I hardly need any other components to implement a professional user interface. There is *no* way you can get better results for the amount of money you need to spend on the library. I would always recommend the VCL subscription. It will set you back $500-$1000 every year but you will get a ton of components for that.
There are a couple of alternatives that you might want to look into. I'm sure that I will get some recommendations in the comments on this post :-) Let the list grow...
2) A logging tool / component
Of course you can use OutputDebugString to print debug statements or you can write your own logging tool. But there are a couple of professional libraries out there that already have done that for you (and more than you probably think of at first) and that are extremely usefull.
My favorite is Raize's CodeSite, but SmartInspect is very good also. Again, I'm sure there are others out there.
3) An exception catcher
I don't know another word for this type of tool, but I'm using two actually. Madexcept (which is my favorite, and only $25 for a commercial license) and EurekaLog. It will help you explain exceptions, especially when your software is already in the wild out there.
4) A bug administration tool
There are a couple, but my favorite is FogBugz. It's reasonably priced and does the job very well. It also has a simple but very effectie planning and time tracking feature. It will handle registering the status of issues, mailing to clients, handling received mail, et cetera. Excellent stuff.
5) Version control system
Now, I was perplexed to find that the client I visited didn't use a version control system. I couldn't think of a workable environment without it. We are using Visual SVN Server and Turtoise as a client. Even if you are in a single developer environment you should take the time to set this up. Don't let the costs scare you: it's free...
6) Creating setups
Every piece of software should be delivered in a setup. There's a couple of free (and not so free) tools out there, but we are using Wise for Windows. That's a bit old actually, but does the job very well.
7) Build tools
Now, eventually you have to deliver your software. You can build your software and assemble and distribute the setup by hand, but invest some time in setting up a professional build tool. Once you got the right scripts set up, delivering your software is a snap. We use Automated Build Studio. I actually wrote a testimonial on that which you can find on their website. Good support too.
8) Debugging tools
I don't use many other debuggers from the one in Delphi, but if you need some special things (like profiling the performance of your application), you might want to look elsewhere. We are using AQTime but I don't need it that much to be true. It's only at special occasions that I start that.
9) Unit testers
Every other month or so I tell myself I have to develop some unit tests. I never get to it, but writing this piece makes me a firm believer in unit tests again. I will, honestly, setup some unit tests.... Really, you should do it to.
10) Documentation
Now, here's a bit of plugging our software. How could I ever use anything else but our software for that? Google does it, SAP does it, Microsoft does it, so I'd better use it myself too :-)
If you want more information on what our products can do to your documentation (not only as a technical documenation tool, but for a great variety of documentation needs), please don't hesitate to contact me.
That's my list. What do you have to add, strike or comment?
Bye,
Bart
Subscribe to:
Posts (Atom)