What is Assert or Assertion?

By its definition Assert:

• state categorically
• affirm: to declare or affirm solemnly and formally as true
• insist: assert to be true
• In Computing (wiki): “an assert is a predicate (i.e., a true–false statement) placed in a program to indicate that the developer thinks that the predicate is always true at that place”

In general, using assert in the code proven to be useful in many situations because it “checks for a condition and outputs the call stack if the condition is false” and it could help to debug some strange situations in the code.

Assert is your friend

This method is for programmers to use. But what happen often when something is convenient, it started to be used excessively. Why it is happening?

Let’s look at the declaration of Assert in C# (3.x). There are two versions of the Assert(): Debug.Assert() and Trace.Assert(), both in System.Diagnostics namespace.

// Checks for a condition and outputs the call stack
// if the condition is false

[ConditionalAttribute("TRACE")]
public static void Assert(bool condition)

[ConditionalAttribute("TRACE")]
public static void Assert(bool condition, string message)

[ConditionalAttribute("DEBUG")]
public static void Assert(bool condition)

[ConditionalAttribute("DEBUG")]
public static void Assert(bool condition, string message)

As we can see from above code, Assert is to be used for Testing and Debugging and therefore should not be used as a way to present any information to the end-user.

Helping yourself

As useful as it seems, even then Assert infrastructure may not be used to full extend. In the sample declarations above we can see that logic can be invoked with and without providing any additional information.
Imagine how useful is a message “Project raised an Assert in line X” compare to “Project raised an Assert with the Message in line X”.
First option gives you idea where something failed, where second actually tells you what went wrongand where. Let’s use power of the tool-set and provide ourselves with useful information.

Assert is NOT for an end-user

I was asked recently (this seems to be a ongoing discussion) – “Why a programmer should not be using asserts as a regular approach in code conditions validation even when it comes to a production code?”

By default, Assert would show a message box with some information and the current Call Stack. This information, while being helpful to the developer, would not tell much to the user.

With custom TraceListener introduced, message can be hidden from the user and information could be stored, but it is not how it should be used by definition.

If information is expected to be presented to the user in any form, it could be achieved in a form not an exceptional, intended for debugging, situation, but by using regular methods: message box, application log, Windows event log, etc.
Even in the case of component development it is desired to use exceptions (raise/throw) to “bubble” proper message to the error handling layer.

The throw statement is used to signal the occurrence of an anomalous situation (exception) during the program execution.

Assert is a conditional logic

Last, final and probably major concern here is that in Release environment Debug and even Trace functionality would be disabled and therefore, any code/logic which depend on Assert() would be suppressed and all the nice validations became worthless (see declaration above)… and Access Violation errors starting pop up unexpectedly.

The post Assert is your friend… not an end-user’s appeared first on Dragonsoft Technology View.

Being somewhat unique in methods declaration for the classes, Delphi requires you to have proper method parameters declaration, but:

1. You do not have to have any default values for the parameters being propagated into implementation section for the method.
2. And you do not have to have any parameters being specified in implementation section at all.
3. If your class implements an interface, then while order and type of parameters remain unchanged for the interface method implemented, compiler would not not even detect it.
4. When declaring the method and then using code complete feature of the IDE, stub generated would have all parameters but no default values.
5. Declaration of the parameters could be “optimized” by changing the way they are grouped if they are of the same type. And sync is not enforced between declaration and implementation.

Convenient. Nice. Easy.

Again, it is convenient since it does not force you to propagate your changes between two if you are to change your default values.

Is default value good or evil?

Well, Microsoft saying it is specific to an implementation of the language (C#) and suggests to use overloads instead. Yes, it can be done, but defaults were introduced for a reason. And, in fact, some compilers, even Delphi, would be confused with overloaded declaration if there is a slight chance of mixing two.

Back in 2005, dflat wrote:

Disadvantage:
1. A bit tedious to call, because even if you don’t put any actual parameters, you have to write down all the types.

Advantages:
1. Unlike C++ default params, this allows all combinations
2. No signature conflict or ambiguity. The whole signature is matched when calling a method with default parameters, because type must be specified if the parameter is missing.
3. No run-time overhead, because everything can be determined at compile time.

Feasibility. I don’t think it’s difficult to implement (in later version of  C#) because:
1. No additional key word is introduced. “default” is already a key word in C#
2. No ambiguity. It doesn’t conflict with any existing C# language semantics

I may sound old fashioned, but I prefer propagate declaration of the method into implementation, because:

1. if for any reason you have to move things around the code, it is convenient to be able grab implemtation of the methoid and easily reusing it in declaration of another class.
2. while reading the code, be able to see exact calling contract for the function you are investigating without a need to jump between declaration and implemtation.
3. also having it in sync, force you to review the code when any default values are changed and if you are using something like XMLDoc/JavaDoc/PasDoc, compiler will force you review your method documentation.

Yes, it “breaks” a “Dry code” principle. But it is not more of “dryness” with that approach then not having any parameters in implemtation section of the method. And while it “polutes” the code, it adds more self-documenting and readability to it.

What are yours points “for” and “against” default parameters and use of them?

The post Delphi, methods and default values. Convenience or contract enforcement? appeared first on Dragonsoft Technology View.

Note. Even though we are talking about Delphi here, it is really could be applied to any development environment.

Let look at the problem closer.

Problem

You have development environment with over dozen of development stations. You have similar development environment: versions of development tools used, locations, components. How to do easy update/upgrade in this environment and keep it up-to-date?

Solutions

1. Virtualization

My vote goes for virtualization – choose from VMWare, Microsoft VirtualPC or other solutions.
Then create base image which everyone would share, change your settings that anything which is user specific goes to his/her local drive instead of virtual image space. Yes, you would have to have some sort of unification, but it is true for any development environment nowadays.

If you go with Server editions of such products then it could be even easier since some of them could allow you maintain your own sessions without affecting main image.

Then make it through your virtual environment has a priority over your hardware so if you are in the development mode you would not really suffer penalty of virtualization. With new versions of Windows coming, I think it would become common and internally supported by default. For now you would have to do some maintenance.

2. “Virtualization”

The same name, but a way to achieve it is different. Instead of virtualizing a whole Windows environment, you do that for your Delphi environment only.

What does Delphi environment consists of?

• Delphi installation. We have to assume that everyone is on the same version. Best to have it in the same location, but it is not really necessary.
• Project source code. If you use any change management system, then you most likely already have everything in one place, and in the same folder structure. Projects are open from similar locations and exe/dcu files created in the same designated areas.
• Components, wizards. That could be a problem and this is where you really put “virtualization” in place.

Let’s think about it for a second. What does Delphi have to have to properly use custom components?

BPL, DCP, DCU, DFM/RES files location! IDE really does not care where code was compiled, but rather that components are properly registered and place to find all required files.

Keeping that in mind, let’s create proper infrastructure:

1. Put everything in your source control system and have it in the same places on all machines. You could have BPL/DCP in the same folder with DCU files or in different locations. Also folder with DCU files should include all necessary DFM/RES files.
2. In Delphi, add your new location for DCU to “Library Path” in IDE options, and your BPL/DCP location to “BPL/DCP output directory“.
3. Do not add source location to a “Browsing path“, you do not want THIS shared code to be recompiled on individual machines. It will also prevent some “strange” errors when DCUs start to “walk around”.
4. Then install all necessary Design time packages and you done.

How would upgrade process work?

Now it is easy. On your master computer update components, recompile if necessary, then check them into your source control system. Then, when necessary, before launching Delphi IDE your developers would get latest form depository, which will update all components and proper DCU/BPL/DCP.

It is rare when new components has to be reinstalled in Delphi since file/BPL structure is usually remain the same. Even when such maintenance is required it can be accomplished with simple .REG file deployed and applied to all machines. But it is rare situation.

Result – you now have fully maintainable, distributed development infrastructure.

Conclusion

Both scenario are result of my own experience in resolving an issue of handling workgroup environment and have been used in real life.

The post Was: Delphi in the workgroup appeared first on Dragonsoft Technology View.

Good news

For people who worried about future experience with installation of the Delphi 2009 – it is fast (or faster, since it is always comes to personal opinion). I have done several “fresh” installs, along with “on-top” installations. It did took me less then I spend downloading it over my 3Mb connection. Keep in mind a size and compare it to Visual Studio installation time and it start to look very good.

Not to be along with that statement there is other people’s opinion – Holger Flick posted last Saturday about his experience.

History

For many years, Delphi installation was created and maintained using InstallShield product line. It was based on it and IS Express edition was included in distribution for developers to use it. I am not sure how many people have actually used it, but it was there and it was free. Back in 2006

Newly formed CodeGear(TM) chooses InstallAware for delivering the newest versions of Delphi®, Delphi® for .NET, C++ Builder®, and C# Builder® tools. InstallAware Express is now bundled with CodeGear’s developer products as the installer tool of choice.

Let’s look at the possible reasons:

“Using InstallAware’s MSIcode, we have drastically reduced the need for creating custom plug-ins,” says Allen Bauer, Chief Scientist at CodeGear. “Our InstallAware setup dynamically defines the features and files to be installed. Instead of building, maintaining, and shipping separate installers for all the languages, IDEs, and product editions that we offer, we are now able to build and deliver a single install image. This has dramatically reduced our integration workload along with reducing our costs.”

“Electronic software delivery (ESD) will be playing a larger role in the way we deliver our products going forward. InstallAware will be powering our new ESD functionality in the Delphi and C++Builder products,” adds Michael Swindell, Vice President of Products at CodeGear. “We will be able to increase Internet delivery flexibility and performance providing customers with instant access to features based on electronic software purchases. Our goal is to make the user experience for both trial evaluations and electronic purchases as simple and flexible as possible. We evaluated a variety of installation and delivery technologies and InstallAware had the right features, performance, and technology for our requirements.”

Reality check

After initial release everyone had “suffer consequences”. Setup was much slower, updates could take substantial time to be applied. As a result, there was up until recently big “roar” to “toss” IA and return to “good old days”.

Alternatives

Aside from choosing to use batch file/XCOPY setup mode (can you imagine that this is still preferred way to deploy ASP applications?) let’s look at the alternatives for InstallAware (MSI).

• InstallShield: recently acquired by Acresso. This is a target – “If your software targets Windows, InstallShield® is your solution.” – MSI. Long history with Borland/CodeGear and marketing/pricing/features may played the role in the decision of looking elsewhere for new deployment solutions.
• InstallAnywhere – just to mention here and it is a product from the same company. In general it may be better positioned since supports not just Windows bit other platforms as well. Not a mainstream product for some time, but what could happen is that it will eventually merge with InstallShield taking best from both. At the time (2006) probably was not even considered to be a choice.
• Wise installation Studio by Symantec – again Windows platform. – MSI and WinInstall. Product line had struggled for many years, was very non-trivial in maintenance and even though it did have potential, uncertainty of it existence at the time may played the role of not going with it.
• InnoSetup – great product, native to Pascal/Delphi developers with its Pascal-like scripting language. But even though it is a great product, it may luck of some Enterprise features CodeGear was looking at the time highlighted above. Would it be faster? For sure. Would it lock the deployment to some of the “legacy” ways of doing so? Most likely. – WinInstall

Choice

Some of you will disagree with me on the need of standard ways of deployment, ability to automatically be certified for any future versions of Windows (Vista certification at the moment), common UI elements and interfaces… But reality is that it is that it is needed. User/System administrator/Company should be comfortable and familiar with the product deployment strategies and be able to do the same “that those other setups can do”. InstallAware gives just that. Yes, there is some hype in the air as it is with any product on the market, and yes there is a learning curve. Mind though, learning curve here more related to MSI technology itself, then to InstallAware implementation. Team has to have knowledge, desire, and  budget to properly implement requirements regardless of the platform they are using.

It my strong believe that what we have seen over last few years was a story how higher management decisions affect development rather then technology problems. Yes, I could be wrong, but after over a decade working with different deployment solutions, I think that we are in no worse situation with InstallAware then with any other product. With new management direction at CodeGear it may change, but improvements shown in latest installations for Delphi 2009 beta may finally let story rest in peace.

Update (Aug 28, 2008)

Last night I have had a chance to compare RAD Studio 2007 setup speed and RAD Studio 2009 speed once again. Impressive. 1 : 10 ratio. RAD Studio 2009 installs much faster.

The post Delphi 2009 beta: Installation improvements appeared first on Dragonsoft Technology View.

CodeGear joined Embarcadero and finally is free to do what they suppose to do for many years now – develop the software for developers and not some few of many tools for IT management (there would be no problem there in general until development tools line start to degrade).

CodeGear extends the Borland legacy, but not in the way it was done last 8 years since the era of Inprise ALM movement.

Back in 2000, Dale L. Fuller, then president and CEO of Borland, said about going back to the roots and renaming from Inprise to Borland:

“The Borland name has always been synonymous with superior technology,” “We recognize the influence the Borland name has on customers, and we know this decision will strengthen our identification within our target markets.  The Borland name symbolizes a new start for the company, which has proven itself over the past eighteen months with two consecutive quarters of profitability.  As we continue our turnaround, the name change signifies our renewed commitment to customers, stockholders, employees and analysts.  Borland has always been well known for its ability to simplify complex technologies and the new name signals a return to the commitment to deliver superior technology that helps speed and ease the software development lifecycle.”

Promiss which never had a chance to be furfilled. “Software development lifecycle” took over the “developers, developers, developers” (Microsoft (c), this guy can motivate) moto which we used to associate Borland’s name with. It took long 10 years to fully realize potentials of the development tools market.

Now with CodeGear finally free form “Inprise” legacy (it is sad that we have lost good old name “Borland” in “Delphi”, but may be it is for the best.) we all looking forward to see a comeback of Delphi development platform, both as a language and as IDE, to get back its rightful place among modern development platforms.

We have a great tool which just need to return to the day light.

Do you want to know more about a new version? Read what people are saying about a new version, codename Tiburón. If you are not currently using it, give it a try. See what Delphi name was about for years.

The post From Inprise to Tiburón. Fall and rise of development tools. appeared first on Dragonsoft Technology View.

Did you notice that word “Tiburón” is in Unicode?

Let’s come back in time December 2002 – Delphi VCL Controls for Win32 should support unicode – 4.89 rating, 359 votes. One of first from the dozens of QC reports asking to add Unicode into Delphi. Do not tell me it is not important for many people.

Is it too little too late? Could as well be, but it is better to finally have it and enjoy a feature which is now mandatory for any major development platform.

Keep in mind that Delphi (itself) was already “unicoded” storing string resources and source code as Unicode for some few versions. Full VCL/RTL conversion had never received much of the attention from upper management allowing Dev team actually work on the feature. Everything was about ALM those days. This time around it is different. Today Unicode one of the features which are critical for Delphi survival.

Yes, for many years we have learned how to deal with no support for Unicode in Delphi, but it is way around things, and not a solution. How many times was I asked – “why Delphi, being a modern language, still does not support Unicode?”. Well, I have had no reasonable answer.

Let look at the feature in question. Would it be important for US or even EU markets?

Yes, if you write an application which is used outside of your company’s building.
No, if you are running a home-only applications.

Let’s not go into discussion of dancing around the issue instead of solving the problem. Delphi applications do not exist by themselves, there are plenty of 3rd party API, data, code you need to interact and if they are in Unicode and your code cannot be native to the data, then you will encounter many things which you otherwise would not see in your “home” environment. Windows NT, XP, Vista has Unicode support. Being a programmer means one has to follow the main stream, not go against it. Otherwise you look as a white crow.

Now let’s come back to Tiburón. As a component vendor and Delphi programmer for many years, I would worry about such drastic change and impact it might have. But after having “converted” my code to have Unicode support by simply opening my projects in a new Delphi and recompiling gives me an assurance that work is done well by the CodeGear team.

Yes, let’s not idealize the situation, some modifications could be required, especially when Windows API functions are used. But even in this case, you most likely would get informed about the problem on the time of the compile, since you would be asked to adjust a few places in your code to use your string resources as Wide or ANSI strings specifically. Otherwise, your code would just run.

Did it worth the time and resources and is it a major thing for the release? YES. Remember it is a lot of work to make sure that everything is converted properly and working considering that there is a lot of dependencies between VCL code and underlying Windows API.

PS. And do not forget that Tiburón is not only about Unicode. Read all information about it as CG team is talking about new features.

The post Tiburón: Why Unicode IS important appeared first on Dragonsoft Technology View.

Did you miss some of the posts? Check the list below for most comprehensive list of posts about upcomming Tiburon release.

• by David I
  • Tiburon’s LoadFromFile and SaveToFile for Unicode characters
  • Unicode database support in Tiburon for Delphi and C++
  • Tiburon/C++Builder – soon with live UML modeling
  • Boost support in Tiburon C++Builder 2009
  • Tiburon – new language features for Delphi 2009
• by Nick Hodges
  • Here Comes Tiburon
  • Don’t Get Caught with Boxes – introduction to Unicode support
  • New Language Construct for Exit
  • Tiburon Screenshot
• by Allen Bauer
  • Tiburón – String Theory
• from Chris Bensen’s Tiburón Sneak Peek
  • Tiburón Sneak Peek: Registered Type Libraries
  • Tiburon Sneak Peek: Com Wizards
  • Tiburon Sneak Peek: Tool Palette
  • Tiburon Sneak Peek: C++builder Modeling
  • Tiburón Sneak Peek: New Component Wizard
  • Tiburón Sneak Peek: Import Component Wizard
  • Tiburón Sneak Peek: COM
  • Tiburón Sneak Peek: Debugger
  • Tiburón Sneak Peek: Project Options
• by Anders Ohlsson
  • Some new and enhanced components coming in Tiburon
  • TDUG Tiburon Preview
• by Andreano Lanusse
  • Tiburon – Anonymous Methods
  • Tiburon – more about DataSnap
  • Tiburon – Building strings with TStringBuilder
• by Steve Shaughnessy
  • Tiburon DataSnap enhancements
• by Daniel Magin
  • Tiburon: VCL DB Unicode Application with InterBase 2007
• by Seppy Bloom
  • Tiburón Preview
  • Tiburón Preview: TButtonedEdit
• by Chris Hesik
  • Tiburon Preview: Vista Wait Chain Traversal
• by Marco Cantu
  • Delphi Unicode Experiments Video

The post So it began: Tiburón in the news – July 25, 2008 appeared first on Dragonsoft Technology View.

It has been officially reconfirmed, logos present on the page are allowed to be used as affiliation logos but with one exception:

Please note that some of the 3rd party logos no longer can be used since “Borland” is present.

The post Delphi logos – going forward appeared first on Dragonsoft Technology View.

What makes Vista so “unfriendly” for developers?

As it had happened before, it is a new guidelines and requirements.

It was true with Windows 3.x, then Windows 95, NT, and 2000/XP. Nothing is so different now – a new UI, the new user experience. As a result, the new approach in development is required.

Microsoft pushes this new requirements through all possible channels and one of them, a primary for developers, is Windows Vista Developer Center.

Developers could find many references and tips there, helping them with existing and new software to become “comfortable” in Vista environment.

A very first item is “Why Develop for Windows Vista” – a summary of what we, as developers, need to look for…

As for Delphi, we should not forget now famous Creating Windows Vista Ready Applications with Delphi (second editions) by Nathanial Woolls.

Yet there is much more has to be taken into account, so visiting WVDC would be appropriate.

The post Developing for Windows Vista appeared first on Dragonsoft Technology View.

No surprise, but it is very easy and feature was in Windows for a few versions already – it is called “compatibility mode”.

For Delphi being around for long time, developer might find some issues running old versions of the IDE on Vista: security restrictions, debug mode, even look-and-feel. Whatever reason you do not like Vista affecting your development environment, there is very easy way to go around it.

From this article at HowToGeek:

Windows Vista, like any new operating system, will have problems running some older versions of applications. This is especially true in Vista, considering all the changes. Thankfully there is a compatibility mode that can be easily set per application.

To configure the compatibility mode for an application, just locate the installation directory and right click on the .exe, selecting Properties from the menu.

You can choose to run the program in Windows XP compatibility mode, or even all the way back to Windows 95 compatibility.

Probably the most useful setting to start off with would be to disable the visual themes and desktop composition, if you can’t get things working. You’ll have to play around with it, but most likely you can get your application working this way.

If you are willing to take more drastic approach, this Dr.Bob’s article might be of help to you.

Enjoy.

The post Tip: Delphi on Vista to work in XP mode appeared first on Dragonsoft Technology View.