How many applications do we install monthly?
A bit, most people will say. Yes. Quite a bit, in my case.
And how many times does it happen to you to have to click Next for a long time?
Yes... me too, obviously.
Setups are darn boring.
They're boring because in most cases we just want to get the thing installed and don't care about the slightest details. Over 20 yrs of setups around the world and nobody seems to get this
very simple thing: the most of the time people don't care about customizations.
That's the problem. What's so wrong about having a simple message box asking at startup:
"do you want to do any modification to the setup?" If you answer yes, then the plain
setup windows will follow, otherwise it will JUST INSTALL THE THING!
Then, if you like it, you can always remove it and re-install and be picky and modify each small detail about it. But that's afterwards.
Other thing: most of the time, setup programs ask a variety of questions which, in principle, should be asked at the first run. Please stop that. It's awful.
It's just a time consuming step that makes people lose their time.
Yes, eventually you'll have to answer those questions, but at least give an option.
Ask: "Do you want to preconfigure the program?". If I answer yes, then go on.
Otherwise, please do refrain from obliging me to configure on the spot.
I might have other things to do and be unwilling to leave the computer opened.
Now, after all this, what is a setup in my opinion? A setup is a set of steps that
prepare your application to be started and operated flawlessly.
Example: when you install the Operating System, in my opinion, driver installs are not part of the configuration, but of setup, because they enable the computer user to "use" the OS to its uppermost extent. License acceptance, for example, should be part of configuration.
Registering an OCX is part of setup, but having registry keys containing other things shouldn't be part of setup( well, registry shouldn't really exist in the very first place, but that's another story... ).
Please, let all of us cooperate to get back to setup sanity.
Cheers,
Andrew
Sunday, December 12, 2004
Sunday, October 24, 2004
Few considerations on the current and future Delphi and Borland
Recap of the situation
Delphi 2005 is due out around November this year. Fine. It'll contain, according to several Borlanders, three different personalities to work with. Fine. There'll be Pro, Ent and Architect editions. Not really fine. Why isn't it fine? After all, Delphi is mainly used from professionals and for learning there's Lazarus. That's not really fine for several reasons that I'm going to list:- Lazarus and Delphi are different products with different goals and different user base
- Delphi is light years ahead of Lazarus, for historical reasons and for funding reasons
- Delphi has a technology allowing new components to be installed/uninstalled seamlessly in the environment. With Lazarus, each time you want to add one or more components to the IDE you've got to recompile it.
This is true only till some extent, because I don't think the problem lies on the "personal" side of the product, but on the professional side.
Let me explain.
When I have a look at the Pro feature matrix column, I always feel there's something missing.
Just an example: MIDAS wasn't available to the Pro users. Unfortunately the current feature matrix for D2005 is a bit confusing and I'm unable to say if there's now or not.
ASP.NET controls are not available to Pro users. It just seems like Borland leaves us on the edge of the canyon, always waiting for us to jump. That's not a nice feeling.
That's what makes, in my opinion, impossible for Borland to make a Personal edition.
While the new enhancemets are really most welcome, it's probably missing on Borland side the "feeling" for the small shops and single developers. They dind't probably learn a lesson from "Integrating the Enterprise", did you, Borland?
What really beats me off here is understanding what is so wrong with professional users and,
more importantly, how would you define a professional or an enterprise user.
It's very easy these days to do webservices, for example, with RemObjects. Now, if I make a webservice, am I a professional or an enterprise customer? Standing from Delphi editions point of view, I'm an Enterprise customer :-) but I maybe am just a pro under the "pocket" point of view. I agree that some things are just pointless in "Pro" editions, for example the ECO model.
Another example that perfectly shows the situation: I'm a developer with a LAN at home.
Now, I want to target Interbase Server, I can't. That's because the Pro version comes only with Interbase Desktop. Thus, I can't access - for example - from other computers in my home lan my Interbase server because of that. And if I want to make a test I have to do it on my machine, which inherently leads me to choose Firebird because I can target it freely using the whole potential of my LAN. Why then wonder that Borland revenues come less from Delphi and Delphi-related stuff and more from other things? Another example? Ok.
You have to be a software house to become a Borland Technology Partner. Why is this wrong? Simple: because only BTPs can make a request to be included in the Companion CD shipping with Delphi. Thus, I'll obtain not even a chance to try and let my freeware or shareware stuff be
visible. Since there's no way to get onto the companion CD if you don't have financial resources to do so, then you won't likely upload stuff to CodeCentral unless you're really interested in giving away for free some of your works. That's, imho, probably one of the reasons this is wrong. Plus, you're entitled to leave a message for Borland when you upload something, but you never get a response back. At least, I never received one and I uploaded 4 things. I put always the same message. Is there anyone reading those messages? I strongly doubt it. Not to speak about the "Get Published" section on BDN. If you want to be able to publish, you have to FAX the agreement. LOL that's plain crazy, come on! I live in Italy, faxing to USA is an intercontinental call. That's what has been mainly stopping me from writing anything for BDN, and I would have a few things to say. I'm still using Delphi 6 and I'm plain happy with it. Oh yes, I'd love to be able to play with Kylix shipping with D7, but I can't, because the contability raises an EFinanceException when I press the "Buy" button :-)
Ok, that's all for now.
See ya later!
Andrew
Thursday, August 26, 2004
Components aren't always a good thing
Many Delphi programmers build applications through alot of components.
While this may be good on some cases( try doing DevExpress things without
using components :-) ) other times plain classes will do just well.
The reason many programmers don't use classes is that they relate OOP to
components wich - imho - is incorrect.
Classes can be very useful for run-time tasks where you need extensibility and polymorphism.
Encapsulation just comes in the bundle, if you do proper OOP.
Let's see an example: say you have to make a program that process text commands.
You could do it in this way:
Type
TCommandProcessor = class
protected
procedure ProcessCommand( S : String );
public
procedure LoadCommandsFromStream( S : TStream );
procedure LoadCommandsFromFile( const FileName : String );
end;
Then go on implementing it this way, with your ProcessCommand method getting *HUGE* and
unmantainable when time goes by. Now let's have a look at a, imho, better design:
Type
IMyCommandSource = interface
function GetNextCommand : String;
end;
TCommandBase = class
protected
procedure InternalProcessCommand( ACommand : String );virtual;abstract;
public
constructor Create;virtual;
procedure ProcessCommand( ACommand : String );
end;
TCommandClass = class of TCommandBase;
This acts as a base class for all commands. The Create constructor is
marked virtual( please do remember to call "Inherited Create" at some point in it ), so
that you can do there all of your command-wide initializations.
Using a protected method to make the actual process is senseful because that way you
won't need to change public methods when changing internal implementation.
We also defined an ICommandSource interface, this way *anything* implementing that
will be able to be passed along as a parameter when we'll use the interface.
Now we can create a list of commands:
Type
TCommandItem = class
public
property Name : String;
property CommandClass : TCommandClass;
end;
TCommandList = class
private
FList : TObjectList;
public
procedure AfterConstruction;override;
destructor Destroy;override;
procedure AddCommand( Name : String;ACommand : TCommandClass );overload;
procedure AddCommand( AnItem : TCommandItem );overload;
property Item[ Index : Integer ] : TCommandItem;
property CommandByName[ Index : Integer ] : TCommandClass;
end;
Now, you might want to make this a singleton, to share the same instance throughout
your program. Using CommandByName you can write something like this:
var Cmd : TCommandBase;
begin
Cmd := MyCommandList.CommandByName[ 'MyWeirdCommand' ].Create;
end;
Quite handful, uh?
Now you can build your command processor, using ICommandSource to get your
next command and then splitting the whole thing using a delimited string list.
Since Delimiter and DelimitedText only work for D6+ as far as I can recall, then you
might be well served using the CommaText property and have comma separated
commands.
The first string in your list will usually be the command, during processing you'll be
able to set relevant properties and be well.
Using a solid class-oriented architecture will save you big time when you'll be
adding new commands.
Needless to say, you may want to add your own event handlers, so that your
program can react to specific things happened or going to happen.
This wasn't a complete program on purpouse, just because I wanted to throw some
hints about paths you may want to explore.
It's up to you.
Cheers
While this may be good on some cases( try doing DevExpress things without
using components :-) ) other times plain classes will do just well.
The reason many programmers don't use classes is that they relate OOP to
components wich - imho - is incorrect.
Classes can be very useful for run-time tasks where you need extensibility and polymorphism.
Encapsulation just comes in the bundle, if you do proper OOP.
Let's see an example: say you have to make a program that process text commands.
You could do it in this way:
Type
TCommandProcessor = class
protected
procedure ProcessCommand( S : String );
public
procedure LoadCommandsFromStream( S : TStream );
procedure LoadCommandsFromFile( const FileName : String );
end;
Then go on implementing it this way, with your ProcessCommand method getting *HUGE* and
unmantainable when time goes by. Now let's have a look at a, imho, better design:
Type
IMyCommandSource = interface
function GetNextCommand : String;
end;
TCommandBase = class
protected
procedure InternalProcessCommand( ACommand : String );virtual;abstract;
public
constructor Create;virtual;
procedure ProcessCommand( ACommand : String );
end;
TCommandClass = class of TCommandBase;
This acts as a base class for all commands. The Create constructor is
marked virtual( please do remember to call "Inherited Create" at some point in it ), so
that you can do there all of your command-wide initializations.
Using a protected method to make the actual process is senseful because that way you
won't need to change public methods when changing internal implementation.
We also defined an ICommandSource interface, this way *anything* implementing that
will be able to be passed along as a parameter when we'll use the interface.
Now we can create a list of commands:
Type
TCommandItem = class
public
property Name : String;
property CommandClass : TCommandClass;
end;
TCommandList = class
private
FList : TObjectList;
public
procedure AfterConstruction;override;
destructor Destroy;override;
procedure AddCommand( Name : String;ACommand : TCommandClass );overload;
procedure AddCommand( AnItem : TCommandItem );overload;
property Item[ Index : Integer ] : TCommandItem;
property CommandByName[ Index : Integer ] : TCommandClass;
end;
Now, you might want to make this a singleton, to share the same instance throughout
your program. Using CommandByName you can write something like this:
var Cmd : TCommandBase;
begin
Cmd := MyCommandList.CommandByName[ 'MyWeirdCommand' ].Create;
end;
Quite handful, uh?
Now you can build your command processor, using ICommandSource to get your
next command and then splitting the whole thing using a delimited string list.
Since Delimiter and DelimitedText only work for D6+ as far as I can recall, then you
might be well served using the CommaText property and have comma separated
commands.
The first string in your list will usually be the command, during processing you'll be
able to set relevant properties and be well.
Using a solid class-oriented architecture will save you big time when you'll be
adding new commands.
Needless to say, you may want to add your own event handlers, so that your
program can react to specific things happened or going to happen.
This wasn't a complete program on purpouse, just because I wanted to throw some
hints about paths you may want to explore.
It's up to you.
Cheers
Wednesday, August 25, 2004
Support Borland Developer Network
John Kaster on his blog asked us for more cooperation if we want to see BDN
improving. This sounds like a fair request to me: if we contribute stuff, rate articles, etc, that's a very good way to make BDN stats improve to the point it could gather more and more attention.
I am a long time Borland customer( back to TP6 ) and I can only be happy to see BDN get more funds and be shaken to rebirth in a new life.
Thus, you're strongly encouraged to rate articles, submit new stuff to CodeCentral and the like:
your voice won't go unheard!
John, keep up the good work!
Andrew
improving. This sounds like a fair request to me: if we contribute stuff, rate articles, etc, that's a very good way to make BDN stats improve to the point it could gather more and more attention.
I am a long time Borland customer( back to TP6 ) and I can only be happy to see BDN get more funds and be shaken to rebirth in a new life.
Thus, you're strongly encouraged to rate articles, submit new stuff to CodeCentral and the like:
your voice won't go unheard!
John, keep up the good work!
Andrew
Small tip to detect if MS Word is installed on the PC
This piece of code was written for an Italian newsgroup, but I feel like sharing it here.
The basic working is simple:
- It detects if a .doc extension is registered
- If there's any, it goes checking which program is associated with it
- If the program is different from word.exe then it returns false
- Otherwise returns true
Here is the code:
preferably implementation one( to avoid unnecessary noise in the interface part )
Cheers
The basic working is simple:
- It detects if a .doc extension is registered
- If there's any, it goes checking which program is associated with it
- If the program is different from word.exe then it returns false
- Otherwise returns true
Here is the code:
procedure TForm1.Button1Click(Sender: TObject);Obviously, you'll have to include the Registry unit in one of your uses clauses,
var Reg : TRegistry;
KeyToOpen : String;
Value : String;
begin
Reg := TRegistry.Create;
Reg.RootKey := HKEY_CLASSES_ROOT;
if Reg.OpenKeyReadOnly( '.doc' ) then
begin
KeyToOpen := Reg.ReadString( '' );
Reg.CloseKey;
if Reg.OpenKeyReadOnly( KeyToOpen+'\shell\open\command' ) then
begin
Value := Reg.ReadString( '' );
if Pos( 'word.exe',Value ) > 0 then
ShowMessage( 'Word is installed' )
else
ShowMessage( 'Word isn't installed' );
end;
end
else begin
ShowMessage( 'Word isn't installed' );
end;
end;
preferably implementation one( to avoid unnecessary noise in the interface part )
Cheers
Why you shouldn't be using MSXML parser
I already went through this topic in the Borland Forums, but I thought I would
replicate my feelings again on this topic.
The very first good reason to avoid it is that it's not native.
While this may not seem a compelling reason at a first sight, just think it means
that you'll have to either ship MSXML with your program, or let the users download it,
neither of which seems appealing to me, as long as you have several native ones which
will compile straight into your exe.
Another good reason is compatibility. What is it going to happen if Microsoft messes it up
changing the interfaces? Wouldn't be the first time, wouldn't supposedly be the last one.
There's also another extremely valuable reason: what happens if some day an exploit gets
found which will allow an attacker to make something to your PC?
MS reputation in regard to exploits isn't brilliant to say the least and this is a true
concern for me.
If you thought I was finished... well you were wrong :-)
MSXML behaves disaccording to the standard sometimes, allowing malformed XML
files to load correctly. Yes, I'm not joking. This happens mainly with charachters out of
standard( there're quite a few of them which aren't defined ) and that MSXML will
accept silently.
To get an idea of what I'm talking about, have a look at this.
Another issue: cross platform development. If you use MSXML alone you may
have a really hard time making a Linux version out of it. The issue can be
greatly mitigated the exact moment you start using TXMLDocument component tho.
Nope, I'm not finished yet, there's some more things to say :-)
With the advent of dotNET , COM will get discarded, and using a COM based parser
doesn't look the best choice as to now.
Ok, now I have finished :-)
Cheers
replicate my feelings again on this topic.
The very first good reason to avoid it is that it's not native.
While this may not seem a compelling reason at a first sight, just think it means
that you'll have to either ship MSXML with your program, or let the users download it,
neither of which seems appealing to me, as long as you have several native ones which
will compile straight into your exe.
Another good reason is compatibility. What is it going to happen if Microsoft messes it up
changing the interfaces? Wouldn't be the first time, wouldn't supposedly be the last one.
There's also another extremely valuable reason: what happens if some day an exploit gets
found which will allow an attacker to make something to your PC?
MS reputation in regard to exploits isn't brilliant to say the least and this is a true
concern for me.
If you thought I was finished... well you were wrong :-)
MSXML behaves disaccording to the standard sometimes, allowing malformed XML
files to load correctly. Yes, I'm not joking. This happens mainly with charachters out of
standard( there're quite a few of them which aren't defined ) and that MSXML will
accept silently.
To get an idea of what I'm talking about, have a look at this.
Another issue: cross platform development. If you use MSXML alone you may
have a really hard time making a Linux version out of it. The issue can be
greatly mitigated the exact moment you start using TXMLDocument component tho.
Nope, I'm not finished yet, there's some more things to say :-)
With the advent of dotNET , COM will get discarded, and using a COM based parser
doesn't look the best choice as to now.
Ok, now I have finished :-)
Cheers
Indy, ICS or Synapse?
This is a common question hanging around the various Delphi groups in the world.
I don't think to have the definitive answer, but I just want to point out a few things about
them: try using TIdHTTP to download files subject to redirection. You'll see that it ain't that
easy.
ICS, instead, does the job extremely well and reliably.
Though, Indy is a full blown component set and that's obvious that the larger a project
grows, the higher is the chance to find something not really working as expected.
Plus, most of the bugs you can find in Indy are likely to be there for slightly "exotic"
situations, that means on plain standard ones it behaves well enough( at least for me ).
Now, ICS is less "flooded" with protocols/tools/whatalike, so that may be an issue, especially if
someone isn't really into socket programming. I've been told, though, that things are changing.
I have no reasons as to now to beleive this isn't true.
Synapses is not a set of components, but a set of classes. This has several advantages and
drawbacks. First of all, its footprint is *way* smaller than ICS or Indy. Thus, if this is an
issue, you may very well want to give it a try.
Since it's not component based, adding event handlers isn't exactly a chill, especially if we're
talking of *many* events.
It lacks the richness of Indy and I think its classes are extremely useful particularly under two
circumstances:
1) RAW Api programs
2) DLLs
In the above scenarios, I think Synapses is close to unbeatable.
Now, what to choose? It really depends on you, I guess.
I mostly use Indy, but I'll be posting on Synapses as soon as I'll have some time to
delve through it thoroughlly and have a couple of projects done with it.
Thus, I'll keep you posted on this.
I don't think to have the definitive answer, but I just want to point out a few things about
them: try using TIdHTTP to download files subject to redirection. You'll see that it ain't that
easy.
ICS, instead, does the job extremely well and reliably.
Though, Indy is a full blown component set and that's obvious that the larger a project
grows, the higher is the chance to find something not really working as expected.
Plus, most of the bugs you can find in Indy are likely to be there for slightly "exotic"
situations, that means on plain standard ones it behaves well enough( at least for me ).
Now, ICS is less "flooded" with protocols/tools/whatalike, so that may be an issue, especially if
someone isn't really into socket programming. I've been told, though, that things are changing.
I have no reasons as to now to beleive this isn't true.
Synapses is not a set of components, but a set of classes. This has several advantages and
drawbacks. First of all, its footprint is *way* smaller than ICS or Indy. Thus, if this is an
issue, you may very well want to give it a try.
Since it's not component based, adding event handlers isn't exactly a chill, especially if we're
talking of *many* events.
It lacks the richness of Indy and I think its classes are extremely useful particularly under two
circumstances:
1) RAW Api programs
2) DLLs
In the above scenarios, I think Synapses is close to unbeatable.
Now, what to choose? It really depends on you, I guess.
I mostly use Indy, but I'll be posting on Synapses as soon as I'll have some time to
delve through it thoroughlly and have a couple of projects done with it.
Thus, I'll keep you posted on this.
Tuesday, August 24, 2004
Borland, win32, dotNET and Delphi
Let's take a few steps back and have kind of a bigger picture down hands.
During last years, Borland has gone through several turn-arounds.
First was born Kylix and then D7 and eventually D8. Meanwhile, a few Borlanders went
over to Microsoft. While it surely was a deal of a lost to let them go for Borland, yet this
made a carrieer shift possible for others. The very first name that comes to mind is
Danny Thorpe, now Chief Scientist.
There's been quite of a movement lately in the Delphi community, since a noticeable
slice of customers showed their disappointment for what D8 didn't deliver.
Not only that, but some of them also perceived the new IDE as slow( which hasn't ever
been the case before, even with a lot of components installed ).
Right in these days, there's been alot of noise from Delphians about what Borland
should do to get back the slice of developers who have migrated or are migrating to
Visual Studio back.
Imho, the problem doesn't really is in what Borland should do, but what it can actually do to
improve the situation. It surely can't( though it's been proposed ) open source some of its
products due to the eventual loss of IP.
It can't even give out Delphi for free, or change its internal roadmap to satisfy a few developers.
Surely, Borland can show commitment to its developers and do it in several ways:
1) Give us a knockout D9( which should include Kylix 3 ) showing Win32 isn't a dead end for them. Anybody presumably has a very different and subjective view about what a knockout D9 should be. I'll expand on this later.
2) Send out more frequent updates - this can be done relatively cheap by setting up
public betas which can be downloaded and installed at clients' PCs.
3) Involving us with more programming contests, more challenges and/or by providing
superior services of some kind. These should be included in Delphi price for, say, one
month or two and then renewable through a subscription fee.
4) Funding BDN more aggressively and making Delphi help files more accurate and
much better worded.
5) Organize more chats with the Delphi R&D Team, so that they can get direct feedback from
users.
6) Improve QualityCentral
7) Allow single developers to submit components/software for inclusion in the Companion CD.
There could also be a "voting" system for this, so that BTPs get included automatically,
while single developers would need to get votes to be included.
8) Allow for public surveys, enable a few of them at once, and make the results
available for the community.
These were just a few offhand ideas that could help in making things better for us.
As to the aforementioned "knockout D9", this is my whish list:
01) Include my CDS Creator as a design time tool(, ok this isn't compelling )
02) Stabilizing and documenting the OpenTools API
03) Providing a real "make" tool, with possibility to generate HTML documentation on the
fly( this would later allow for easier integration into CHM help files or whatever is the
hype at the moment ) even at the build time.
04) Include a menu item to access Borland Forums and easily publish content on BDN
( which actually is a quite long-taking deal )
05) Restructure dataset classes to fully support interfaces
06) Enhance support for DLLs/Packages to be switched from one to another easily
07) Enhance support for forms, so that they can be made persistent in different
formats than DFM( which can still remain the preferred format for design
time stuff )
08) Enhance the new component wizard( didn't change since D3 I guess )
09) Add an item in the Help menu to detect actual Delphi version and listing all the
installed updates( it could be shown in a memo box so it can be cut&paste around )
10) Improve to-do lists( you can definitely do better than that, come on... )
11) Quality Central client in the Tools menu
12) XSLT expression builder( would help alot )
13) Fix the damned library path issue
14) Add a CodeCentral menu to manage your submissions( even with a very basic VCS to
keep track of changes in them )
15) Enhance WebBroker( how about the one webmodule issue? )
16) Make WebSnap use easier
17) Add a few classes to ease use of Design Patterns in Delphi( Singleton, MVP, MVC, etc )
Yes, I know my whishlist is huge :-)
You may be wondering why I didn't mention dotNET stuff in my whish list.
That's because I think that dotNET isn't just about at the development stage
"they" would like us to see it at.
For example: did you know that dotNET applications get JIT-ted everytime they're
started? Yes, every time they're started. So - say - if I have to run an application
that has a hell lot of plug-ins, each time I do it it'll be JIT-ted.
Another thing: did you know that each time an assembly gets loaded, it's not
shared with the other instances running the same assembly version?
Right, if you have - for any reason - to start two applications which share an
assembly, you'll have TWO copies of it in memory. At least, that's what I've been
understanding after a talk with some Italian MVPs.
Here is the big question: Is dotNET worthwhile?
The answer may seem a boolean one( yes/no ) but in fact we refer to "dotNET"
while we should be addressing each and every different aspect of it on its own.
That's because dotNET is an extremely complex platform, made up of different
frameworks and concepts behind them.
I've been playing with C# a bit now, and I can say I don't really like it too much.
Resembles too much C++ syntax( which isn't good ) and it's always like you're
going to use printf again.
My main real problem with dotNET is that( as most times ) MS behaves in opposite
directions: on one side, it standardizes C# and alot of dotNET concepts through
ECMA, on the other MS keeps filing patents of any kind and then, here you are, it
encourages the use of OpenSource stuff regarding dotNET.
I don't know you, but I for one would like to be able at any time to say what's
going on and not be surprised the moment later with a contradictory move.
It always seems the pacts with MS are never clear, and this sheds a dark light on
every "good thing" coming from that side and that's one of my main reasons( a part from
being a passionate Delphi developer ) to not go for the Visual Studio route.
I''m not going to scrutinize dotNET in detail here, mainly because these are my
impressions after a very short time playing with it.
Last, a couple of considerations about D8: Borland had basically no choice other than
letting it out soon, whatever the bugs where. After all, we all know the "even release"
problem since TP days don't we?
Though now, it's time for "when it's ready" answer back. We want our Borland back.
Cheers,
Andrew
During last years, Borland has gone through several turn-arounds.
First was born Kylix and then D7 and eventually D8. Meanwhile, a few Borlanders went
over to Microsoft. While it surely was a deal of a lost to let them go for Borland, yet this
made a carrieer shift possible for others. The very first name that comes to mind is
Danny Thorpe, now Chief Scientist.
There's been quite of a movement lately in the Delphi community, since a noticeable
slice of customers showed their disappointment for what D8 didn't deliver.
Not only that, but some of them also perceived the new IDE as slow( which hasn't ever
been the case before, even with a lot of components installed ).
Right in these days, there's been alot of noise from Delphians about what Borland
should do to get back the slice of developers who have migrated or are migrating to
Visual Studio back.
Imho, the problem doesn't really is in what Borland should do, but what it can actually do to
improve the situation. It surely can't( though it's been proposed ) open source some of its
products due to the eventual loss of IP.
It can't even give out Delphi for free, or change its internal roadmap to satisfy a few developers.
Surely, Borland can show commitment to its developers and do it in several ways:
1) Give us a knockout D9( which should include Kylix 3 ) showing Win32 isn't a dead end for them. Anybody presumably has a very different and subjective view about what a knockout D9 should be. I'll expand on this later.
2) Send out more frequent updates - this can be done relatively cheap by setting up
public betas which can be downloaded and installed at clients' PCs.
3) Involving us with more programming contests, more challenges and/or by providing
superior services of some kind. These should be included in Delphi price for, say, one
month or two and then renewable through a subscription fee.
4) Funding BDN more aggressively and making Delphi help files more accurate and
much better worded.
5) Organize more chats with the Delphi R&D Team, so that they can get direct feedback from
users.
6) Improve QualityCentral
7) Allow single developers to submit components/software for inclusion in the Companion CD.
There could also be a "voting" system for this, so that BTPs get included automatically,
while single developers would need to get votes to be included.
8) Allow for public surveys, enable a few of them at once, and make the results
available for the community.
These were just a few offhand ideas that could help in making things better for us.
As to the aforementioned "knockout D9", this is my whish list:
01) Include my CDS Creator as a design time tool(
02) Stabilizing and documenting the OpenTools API
03) Providing a real "make" tool, with possibility to generate HTML documentation on the
fly( this would later allow for easier integration into CHM help files or whatever is the
hype at the moment ) even at the build time.
04) Include a menu item to access Borland Forums and easily publish content on BDN
( which actually is a quite long-taking deal )
05) Restructure dataset classes to fully support interfaces
06) Enhance support for DLLs/Packages to be switched from one to another easily
07) Enhance support for forms, so that they can be made persistent in different
formats than DFM( which can still remain the preferred format for design
time stuff )
08) Enhance the new component wizard( didn't change since D3 I guess )
09) Add an item in the Help menu to detect actual Delphi version and listing all the
installed updates( it could be shown in a memo box so it can be cut&paste around )
10) Improve to-do lists( you can definitely do better than that, come on... )
11) Quality Central client in the Tools menu
12) XSLT expression builder( would help alot )
13) Fix the damned library path issue
14) Add a CodeCentral menu to manage your submissions( even with a very basic VCS to
keep track of changes in them )
15) Enhance WebBroker( how about the one webmodule issue? )
16) Make WebSnap use easier
17) Add a few classes to ease use of Design Patterns in Delphi( Singleton, MVP, MVC, etc )
Yes, I know my whishlist is huge :-)
You may be wondering why I didn't mention dotNET stuff in my whish list.
That's because I think that dotNET isn't just about at the development stage
"they" would like us to see it at.
For example: did you know that dotNET applications get JIT-ted everytime they're
started? Yes, every time they're started. So - say - if I have to run an application
that has a hell lot of plug-ins, each time I do it it'll be JIT-ted.
Another thing: did you know that each time an assembly gets loaded, it's not
shared with the other instances running the same assembly version?
Right, if you have - for any reason - to start two applications which share an
assembly, you'll have TWO copies of it in memory. At least, that's what I've been
understanding after a talk with some Italian MVPs.
Here is the big question: Is dotNET worthwhile?
The answer may seem a boolean one( yes/no ) but in fact we refer to "dotNET"
while we should be addressing each and every different aspect of it on its own.
That's because dotNET is an extremely complex platform, made up of different
frameworks and concepts behind them.
I've been playing with C# a bit now, and I can say I don't really like it too much.
Resembles too much C++ syntax( which isn't good
going to use printf again.
My main real problem with dotNET is that( as most times ) MS behaves in opposite
directions: on one side, it standardizes C# and alot of dotNET concepts through
ECMA, on the other MS keeps filing patents of any kind and then, here you are, it
encourages the use of OpenSource stuff regarding dotNET.
I don't know you, but I for one would like to be able at any time to say what's
going on and not be surprised the moment later with a contradictory move.
It always seems the pacts with MS are never clear, and this sheds a dark light on
every "good thing" coming from that side and that's one of my main reasons( a part from
being a passionate Delphi developer ) to not go for the Visual Studio route.
I''m not going to scrutinize dotNET in detail here, mainly because these are my
impressions after a very short time playing with it.
Last, a couple of considerations about D8: Borland had basically no choice other than
letting it out soon, whatever the bugs where. After all, we all know the "even release"
problem since TP days don't we?
Though now, it's time for "when it's ready" answer back. We want our Borland back.
Cheers,
Andrew
First Post
Hello!
Finally, here I am blogging :-)
Ok, I'm a bit unsure about wether I should be doing this, anyway here I am ;-)
Er... well I guess the best thing is to introduce myself: I'm a 27 yo Italian, Delphi programmer and now exploring the dotNET side.
What will you see here? Whatever passes through my brain and I feel like sharing.
Why would you want to read my blog? I don't know, but if you do and post comments I
definitely don't mind :-)
See you on this page, and hope you enjoy it!
Andrew
Finally, here I am blogging :-)
Ok, I'm a bit unsure about wether I should be doing this, anyway here I am ;-)
Er... well I guess the best thing is to introduce myself: I'm a 27 yo Italian, Delphi programmer and now exploring the dotNET side.
What will you see here? Whatever passes through my brain and I feel like sharing.
Why would you want to read my blog? I don't know, but if you do and post comments I
definitely don't mind :-)
See you on this page, and hope you enjoy it!
Andrew
Subscribe to:
Comments (Atom)