Yesterday my long time good friend and colleague Richard pinged me with a weird looking web address: www.embarcadero.com

When receiving such an address, there must be a reason... could it have some funny jokes or ahrm... pictures... in it... Richard usually dont send such links to me.. (hmm... I wonder if he keeps those to himself  .....Just kidding ). So it had to have something to do with what we do.

The name itself didnt ring many bells to me... but that can be because I have been living under a stone for a couple of years coding. Anyway.. I clicked it.

While the web page builds up I notice.. hmm... there is a cool tool... and there is another... but what have that to do with me or us?

Then suddenly a text written in relatively small font showed up... Embarcadero have bought CodeGear...  a few secs... WHAATT!!!! Is this April fools day?.. checking the calender... and year... nah... its indeed just any other normal day.

First impression were... a tools company not much different (although slightly bigger I admit) than us, bought CodeGear! How on earth can that happen. The mouse ate the elefant. We are DOOMED!

Well... then it was time to a second go on what exactly was Embarcadero (couldnt they have named it something pronounsable?.. and writable...my fingers are making knots trying to type it ).

Reading over what it was all about, then it shows that Embarcadero is a relatively big company, actually people wise bigger than CodeGear (but they have certainly not being making any fuzz about that in the media Im reading), and whats more important is that Embarcadero is just one of several private companies owned by a huge private investment company. Hence we are suddenly now talking about money backing of proportions that would make Borland have wet dreams in night.

Ok.. money and size isnt an issue anylonger... but what about the longevity of the CG tools? Could it be a shark attack that results in some technologies being digested and put into other tools, while the rest is discarded?

Only the future knows how it fares, but it certainly do look like Embarcaderos and CodeGears toolsets are extremely complimentary with no direct overlap at all, which indicates that there is a true potential for huge synergies between the companies. They have alot of dedicated and knowledgable developers, and we all knows that CodeGear have the same but on other type developer oriented projects.

Embarcaderos have an organization that contains all the relevant functions for running a developer oriented company, while CodeGear probably have been somewhat amputated in the seperation from Borland, and I could imagine that some administrative and marketing functions within CodeGear either were missing or at least severely limited in manpower. In that scenario, those areas would be naturally strengthened by this acquisition.

As Embarcadero have been targeting a very different vertical market than CodeGear, they also have their feets inside some places where CodeGear would never before have had access, specially related to native development (example Java houses and other non typical areas for CG native tools. Visa versa, Embarcadero now ofcourse have easier access to the many dedicated supporters of CG products, and this way will expect increasing sales of their own products. The total market for most people like us.. 3rdparty tools developers, does seem to open up as the market canvas have now been broadened and the exposure of our products potentially made alot more visible in usually non accessible places.

That should bode well for CodeGear customers too. If the market canvas grows, the potential to earn money for vendors targeting that canvas grows and that ensures stability and progress towards CodeGear customers.

My current take on the situation is that, despite the initially surprising selection of buyer, this is probably the best possible outcome one could dream of.

So ... Very welcome Embarcadero!

I think we all will have a great future together. Delphi, JBuilder, C++Builder now have both the code quality and the market canvas and exposure to really make things happen!

(I will try to get used to writing  "Embarcadero".... but boy... CodeGear is easier... will probably have to use the shorthand writing of it... CG vs ET... battle of the galaxians)

I have seen the light.. I have faith!

Kim Madsen
TeamC4D

We had on our newsgroups at news://news.components4developers.com recently a question about if kbmMW can be considered a 'corporate product'.

My answer to that was that in our opinion, yes, but we certainly dont have the marketing muscles of the big ones that are considered 'corporate'. I consider something to be 'Corporate' if the following conditions are fullfilled:

1. It serves a corporate purpose
2. It provides a reasonable ROI
3. It is backed by a stable organization/vendor
4. It has a future
5. It is maintainable
6. It is maintained

Lets take them one at a time:

1) Well.. if it doesnt serve any purpose in corporate sense (eg. a company cant use it for something useful), it isnt corporate.
2) If it is costing an arm and a leg to install or use to serve purpose 1, then it isnt corporate.
3) If its looking like abandonware, or anyway highriscware, then it isnt corporate. A company has to be able to trust that the vendor is around to support it.
4) If the product do not have a future, its not corporate. There is no idea for a company to spend energy on something without a future.
5) If the product is next to impossible to maintain and require too many manhours, its not corporate.
6) If the product is not maintained it means that the product is reaching a status that would kick in point 4. No future. Its not corporate.

In reality I see large corporations use products that they consider corporate, but that typically do not live up to those 6 criterias. Lets look at some examples:

Sun - J2EE: For the most part it doesnt live up to the 2nd and 5th criteria. It is typically difficult to get to perform (why there are lots of highly paid contractors in that area), and its equally difficult to deploy an application server. Some vendors of application servers have made it somewhat easier than others, but the base line is that a scalable, performing production deployment is not easily made.

Sun - JMS: In addition to the difficulties in deploying a production system, thus violating point 5, it also violates 2 as JMS by itself does absolutely nothing. Routing mechanisms, request/response mechanisms, quality of service mechanisms etc. must all be handcoded by each project wanting to implement JMS. There exists frameworks based on JMS that makes this somewhat easier, but that may actually end up in making the maintainability even worse.

Microsoft - VB: The number of VB3-6 applications still running in corporate environments are quite staggering. However it is abandonware, and no longer maintained by MS, hence violating 3, 4 and 6. In addition upgrading in the good old days from one VB version to another usually required rewriting specially the database access code as MS had an idea to reinvent the wheel on a 6 months basis.

Microsoft - .Net: That surely must be corporate, right? Well.. the corporations that based millions of US$ on VB in the good old days should actually have removed the 'Corporate' label of that product, although most havnt. The trackrecord (as in whats the chance your application can be recompiled with the next version) of MS development products except perhaps for Visual C/C++, has not really been something to make corporations feel a good warm fuzzy gut feeling. The amount of US$ spend to rewrite existing applications to move them to the new version or to support the new Vista etc. is simply staggering. People who believed in WinForms being the future also have to count with uncertainty to what amounts of rewrites are needed.

IBM - Visual Age for Java. It was actually a very capable Java development IDE, with some features that made it really unique. After IBM chose to drop VA for Eclipse, developers using VA had no choise but to follow to the new platform, despite that the new IDE didnt contain all the wizard functionality originally found in VA.

IBM - ComponentBroker. IBM's CORBA solution for Java and C++. It was dropped about 4 months after I attended a quite expensive course in the product. Fortunately we the company I worked for at the time didnt get to actually integrate it into something, but if we had, it would have cost serious US$ to replace it with something still maintained and supported. In addition it was cumbersome and errorprone to use it. However it was still considered 'Corporate' all the way until it was dismissed.

In my opinion, the label 'Corporate product' often is a synonym with big, difficult to use, difficult to manage, difficult to deploy, overly expensive software backed by the 3-4 most PR active IT companies.

What is your definition of 'Corporate'?

Kim

During the last several years, our flagship product, kbmMW, have been supporting more and more IDE's and versions, and it has also undergone a facelift in the sense that multiple editions were made available.

kbmMW currently consists of 2 packages (one runtime and one designtime) for each IDE for each edition. Each of those packages consists of one or two files. As kbmMW currently supports 10 different IDE's/variants (D5, D6, D7, D2005 Win32, D2005 .Net, D2006 Win32, D2006 .Net, D2007 Win32, C++ Builder 6, Kylix 3), and there are (or have been) 6 different flavours of kbmMW (OpenSource, Std, Pro, ProPlus, Ent, CodeGear), simple math makes the number of files to update each time a source file is renamed, deleted or added quite staggering. Its currently totalling around 100 files that must be updated!

That was starting to get REALLY boring to do, not to say time consuming and error prone. Automation must be the name of the day!

Hence we had to invest some time in a new product called kbmProject, which essentially is an advanced project file generator using scriptable templates.

In it we define:

• Units - which defines all the units that we know of for kbmMW as a whole. The unit definitions can also include information about forms/datamodules etc.
• Requirements - which define all the possible requirements that we know of for kbmMW as a whole.
• Projects - which we use for defining editions and what subset of the Units definition and Requirements they should contain.
• Templates - which defines the overall layout of the files. The templates can contain scripts and take advantage of variables/parameters defined on a job, project, template group, template, unit and snippet level etc.
• Template groups - which we use for defining groups of templates ... doh...
• Jobs - which is a combination of a Project and a Template Group

In addition we can define:

• Snippets - which essentially are small reusable code/data pieces that can be referenced from within a template
• Conditions - which for example can be used to indicate if a specific unit or requirement should be part of a specific package under some given conditions

When it all has been hooked up correctly, its as simple as clicking a Generate all button and all the relevant package files are generated automatically.

Quite neat!

This is a screenshot of the units pane... notice the raw unpolished look :)... its a good indication for this being a tool for toolers :)

And the following is a screenshot showing the templates and template groups.

As can be seen, the currently selected template simply contains a reference to the snippet BPK_kbmMW_Designtime. It could have contained alot more if needed, but I decided that I preferred the snippets to contain all the info as it would then be easily reusable.

So lets checkout the snippet then....

The snippet can be opened in a fullscreen editor to make it easier to read/edit.

 

Some places in this snippet there are references to either parameters or other snippets. The {%$=...} syntax references a parameter, and the {%$@....} references another snippet that will be inserted at that place.

The parameters can be defined on almost all elements in kbmProject. They are searched in a specific order to for example ensure that the parameter ANAME on the unit level takes precedence over ANAME (if defined) on job level etc.

The following show the scripted snippet SpaceLibsFroBpkPackage.

Anyway this was just to show you some of the extra tools we need to maintain continued development of kbmMW.

Kim/C4D

In quite a departure for us at Components4Developers we have decided to start blogging.  Day to day we constantly talk amongst ourselves about new ideas, techniques and ways to improve our products.  Some of these ideas get into the released code line, some get put into our research basket for a revisit and some get rejected.  Our customers though don’t see this process occurring, well that’s not quite true.  Customers that engage us in consultancy services get to see this first hand as often we are solving big issues for them through elegant additions to our products.

For example, the first internal implementation of the messaging in kbmMW was UDP based.  Why UDP?  - Because a customer commissioned us to extend the middleware to support publish/subscribe distribution of real-time video.

Another customer needed connectivity for PHP, C, C# etc from which came the Spider clients collection.

It is worth mentioning then that if you really need a feature added to any of our products you could always commission us to develop that for you on a shared IP basis.  If we think the feature will be of general benefit to our products then we will include it in the production source and maintain it through its life.  It never hurts to ask

Getting back to the blogs.  Here from time to time we will share with you some of the ideas we have in the works, or things we have noticed across the industry.  Or, we may just have a joke or a moan.

Everyone is invited to join in. We invite our C4D friends who wish to join our bloggers list to let us know and we'll setup an account for you. Those that would simply like to comment on, or syndicate our missives please go ahead.

On another note.  Theses blogs are powered by BlogEngine.net.  Check it out.  It is Open Source and based on ASP.net.  Maybe I'll find a reason to hook it up to a kbmMW application server sometime.

Richard and Kim