Archive for September, 2013

Latest EMBT Offer

Tuesday, September 24th, 2013

I just received an email offer from EMBT to upgrade to XE5 for Android development with a generous 10% off.  The email contained a “Shop online at https://store.embarcadero.com and use coupon code SPECIAL10 at checkout.” near the bottom, so just for giggles I clicked on the link.  It takes you to the cleverbridge e-commerce site with a link to open the homepage.  Not even a mention of Embarcadero.

The interesting thing is that the Buy OnLine link also in the same email does work, although it takes you to a general sales page where you again have to click on a Buy Now product link before selecting the product edition and adding it to your cart.  Then of course you have to click on the checkbox to enable an input field where you can manually key in the special code.

I guess customers who want that 10% off have a 50/50 shot….and if you get past that obstacle, for 10% off you should have to jump through at least a few hoops ;-)

AnyDAC Acquisition Concerns Apparently Justified

Wednesday, September 18th, 2013

I just stumbled upon this on DelphiFeeds. Apparently when I posted my concerns about the AnyDAC acquisition back in February I wasn’t too far off the mark.

It appears that one “product” or “add on” is being used to coerce customers to buy additional upgrades. This kind of vendor lock in strategy IMO is despicable, and is going to cause a long term loss of Delphi developers. If recent blog posts are any indication, even the most positive bloggers are joining the ‘nay sayers’ to let EMBT know they are not a fan of their recent marketing decisions.

At today’s pricing, it’s far from a Fire sale (get it? FireMonkey, FireDAC…:) )

Geolocation for XE5 not Working?

Wednesday, September 11th, 2013

I just checked to see if the XE5 World Tour had been expanded to include any cities on the west coast of Canada and they have!  Apparently my previous post has gone unaddressed, even though I pointed out on August 23rd that the XE5 World Tour map was blatantly wrong and misleading, it remains uncorrected.  Toronto and Montreal apparently have been moved to British Columbia.  I thought it might be because no one reads this blog, but even the EMBT VP of Developer Relations commented on this post!  Whats a few thousand miles anyway….

Toronto and Montreal moved to BC

Toronto and Montreal moved to BC

XE5 “Special” Upgrade a Bargain?

Wednesday, September 11th, 2013

I just checked out the pricing for the XE5 “special” (from XE4) upgrade for Delphi XE5 Professional. It’s a whopping $499 CAD where the “regular” upgrade (Delphi 2010-XE3) is $549 CAD. Considering the XE5 Fix List does not seem to be published yet (Google can’t find it and there are no links in EMBT’s targeted email announcement), it’s a little hard to understand why the XE3 to XE4 upgrade was only $49 where the XE4 to XE5 upgrade is $499 when in both cases the focus appears to be on mobile development, which you do not get with the upgrade.

I called EMBT sales and spoke to Tina. When asked she directed me to the Whats New page and when pressed said she would have to get back to me with the fix list.

What I can infer from the Whats New page is that developers not buying the mobile pack will get a new time picker control, search filtering for TListView, a REST Client Library, REST Debugger tool, expanded FireDAC support for local databases in the Professional edition “…and more” (whatever that means).

So if you’re looking for bug fixes, you might want to wait until the fix list is published before upgrading to see how “special” the upgrade is…

This also begs the question why QC cannot be used to find all the QC items fixed in the latest release. Of course you would at least need a build #.

Addendum:

Tina just emailed me a link to the XE5 Fix List I am pleased to see QC #115925 is fixed as I submitted fixed code to TeeChart for that issue ;-).

There are some 272 bug fixes in the list with some startling regressions including “Dataset closing doesn’t free fields”, “Exception in FMX180.bpl when resizing a Form”,”F4 key will hang IDE”, “Delphi XE4 Update 1 Crash when I add a TDatamodule”,”TSpinEdit will cause access violation in x64 Application”.  Lots of the fixes are for FireMonkey and Android, so a desktop developer who doesn’t buy the Mobile kit doesn’t seem to get that much for $499 IMHO.  Certainly the infamous “Out of Memory” when compiling large projects, especially project groups is certainly not fixed.

As Tim mentions in his latest post, XE4 is only about 6 months old, so users buying two upgrades for the year would be looking at potentially $1000 CAD if the XE5 price is any indication of what the future holds for XE6.  At that price the yearly subscription for Oxygene at $599 for a cross upgrade looks mighty appealing…

Don’t forget that REMObjects Oxygene not only supports .NET, and Mono (including 64 bit OS/X apps), but you can freely download the Oxygene compiler for build servers.  Last time I checked, you don’t even get the command line compiler with the Delphi trial which can make installing your components to try to upgrade applications a real royal pain!  AFAIK the Delphi OS/X compiler only supports 32 bit EXEs despite OS/X being 64 bit since 2007.  Obviously the focus is on mobile platforms and not the desktop where Delphi is strongest.

BTW, when RemObjects released Oxygene 6.1 right on their Whats New page there is a link to the complete change log.  Heck you can even look at previous release changes to get a complete list of all changes from your version to the current one.  No need to google it, or call customer service.  Truly a different customer experience…

EMBT Looking for Staff

Friday, September 6th, 2013

EMBT has numerous postings for positions if you are interested in applying.  There are jobs in the US, Romainia and Spain.  They are even looking for a Senior VP of Marketing.  If you’re going to apply make sure to read this first.

Developers Shouldn’t run Around with their heads cut off

Wednesday, September 4th, 2013

Developers shouldn’t run around with their heads cut off but in my experience they most certainly will at some point, trying to fix bugs, if they don’t write their programs to be headless.  A good way to write a headless application is to write, you probably guessed it, Unit Tests!

From personal experience, I know that if you don’t write your code to be testable, it’s extremely hard to make it so at a later date.  If anything, your unit tests become more like integration tests.  The same holds true, that if you write your code for one UI, business logic tends to creep into your forms, making it more difficult to support a UI on a different platform at a later date.  It also makes testing through the UI mandatory, and it’s very difficult to thoroughly test code through the UI as it evolves.  Using an ORM helps separate business logic from UI, but it’s not a silver bullet.  I think the best approach is to use a framework like MVVM in concert with an ORM.  Unit Testing IMHO is the next best solution.  It’s a good way to make sure your code is headless as well as uncoupled from other dependancies and forces you to think about coding it in a more defensive manner so it will withstand the constant regression testing.

At some point, if you aren’t actively making payments,  your technical debt will force you to re-write your software,  and without unit tests much of the requirements for the code, and those hard won bug fixes will be lost because developers don’t write documentation (at least good docs).  So while you think you’re new code may smell as fresh as a daisy, compared to the old stuff, it will essentially be a large and unproven undertaking.  Unit tests are payments against technical debt, allowing you to change the software to meet evolving requirements with minimal breakage.

I recently had to update some unit tests that I wrote after another developer refactored the class under test.  Apparently, despite my request that he update the tests, he failed to see the value in doing so.  What I discovered was that he had introduced a bug which would have remained undiscovered for some time, had I not updated the tests.  Prior to that, the unit tests for that single class had proven their value several times, having once created a new test to prevent a bug found in production, and catching breakage in previous refactoring efforts.  That was on a single class!  I can only imagine what life would be like if there was 80% test coverage.

If you don’t use unit testing I would encourage you to invest the time to learn how to write unit tests, and to actually do so.  Don’t learn it’s value like I have - from the school of hard knocks…