Why I Keep Choosing Delphi

Turbo PascalEarly on I learned Turbo Pascal, which was a huge step up from the Basic and Batch File programming I cut my teeth on. When Delphi came along I thought it was brilliant and fell in love immediately. I had no interest in learning other programming languages or tools. Delphi did it all, and that was great. I found myself plenty of work and enough to keep my interest.

C++BuilderI was naturally curious about other programming languages, but mostly from an academic point of view. I took a night school class in Assembly. I had a smattering of C & C++. Looked at some Ruby (back before it was hip), Java, JavaScript, etc. Eventually I found myself troubleshoot laser printers, which ran a combination of C/C++/COM all on a Linux platform for a few years.

C#From there I went back to full time Delphi programming, but the new company I was working for bought into the “there aren’t enough Delphi developers” myth and decided to move to C# & WinForms.We immediately were able to hire some more C# developers, but as we got to know them we found out they had a background in Delphi development, but they bought into the “there are no Delphi jobs” myth and rebranded themselves as C# developers. In the end the project took 4 times longer than it should have, despite having more developers. We really should have stuck with Delphi.

Ruby

I moved to a new job doing Delphi development full time, and then that company bought into the C# & Silverlight are the future. Since I had C# experience I started working on the new Silverlight front end. The backend and the desktop app remained in Delphi (with a little C++).

JavaScript

From there I ended up really branching out. I did a lot more work with C#, Xamarin, Java, JavaScript, Objective-C, and Oxygene (known as Delphi Prism at the time). There was still some Delphi mixed in too. I taught a few class and workshops on Android development. I learned to appreciate some of the benefits, strengths and qualities of each. I found things about all of them I liked (less so about Objective-C).

It was at this point I could see that most developer skills work across languages, tools and platform. There is value in knowing and using multiple languages. The basic tenants of each language influences the way you do things in other languages in a positive way helping you to look at problems in a different way. There are some projects, platforms and problems that are best suited to certain programming languages. For example, if you are working with the web, you need to know at least some JavaScript, HTML & CSS (the latter two not being programming languages), even if you are using some sort of abstraction layer.

Delphi HelmetThroughout all of this, I still found myself choosing to Delphi for personal projects. Occasionally I’d try personal projects in other tools and languages as a way to get to know them, but I still found Delphi to be a better solution for most general purpose projects. One of the defining characteristics of Delphi for why I keep coming back to it, is that it makes the common tasks really, really easy, while keeping the rest simple and possible.

So many “rapid prototyping” tools that make the common tasks as easy as Delphi does, makes anything beyond the “ideal” scenario hard or impossible. While other general purpose tools don’t do anything to optimize common scenarios, often times making these simple tasks more complicated than they need to be.

Now with multi-platform development Delphi is more important than ever. The approach Delphi and FireMonkey provides makes it quick and easy to do the most common tasks, while also keeping all the platform APIs and features within reach.

Delphi really invented the 3rd party component market as far as I am concerned. When it shipped all the source code for the VCL and included a robust OpenTools API and component model it made it even easier for others to build, share and reuse code. All the technology partners are a huge part of why I choose Delphi.

Delphi also has a huge commitment to the code we as developers develop. I attend a lot of general software developer groups, and it is common to hear developers complaining about how they just finished porting their code to one release only to have it all break again because a new release of their non-Delphi programming language or framework just came out. Sure, it isn’t perfect, and sometimes there are incompatibilities or breaking changes from version to version, but on comparison Delphi is so much better at this than any other language or platform out there that I have seen.

I started out choose Delphi because it was what I knew. Now I choose Delphi because it gets the job done. The fact it is faster for development is nice, but only part of the equation. I used to have a hat that said “Delphi does it all, especially Windows” and that is more true than ever today.

So why do you Choose Delphi? Share your reasons in the comments or on your blog #WhyIChooseDelphi

Posted in FireMonkey, MVP, News, VCL | 8 Comments

Getting Technical with Cary Jensen and FireDAC (Episode 74)

In this episode of the Podcast @ Delphi.org we talk with Cary Jensen about his new book Delphi in Depth: FireDAC and the upcoming Delphi Developer Days which Cary puts on with Dr. Bob Swart. Nick Hodges, our co-host, was a previous host of Delphi Developer Days with Cary, and I’ve made a number of appearances there as well. They are highly recommended.

Cary’s new 558 page Delphi in Depth book tackles everyone’s favorite multi-platform database access framework: FireDAC. Cary gives it his unique treatment that only he can deliver. He gives special emphasis to all the configuration options available with FireDAC that can help you gain even more performance.

Delphi in Depth: FireDAC by Cary Jensen

For this year’s Delphi Developer Days, Cary and Dr. Bob are doing things a little differently. They are doing a special workshop focused on database development. You are encouraged to bring your laptop and follow along while you learn from the masters!

Just in case you missed it, Cary also put on a webinar on FireDAC recently that I recommend you check out.

Posted in Audio podCast, FireDAC, podcast | Leave a comment

Creating a Bootable USB Drive on macOS from an ISO

Creating a bootable USB drive from an ISO is pretty easy on Windows, but you end up going to the terminal on macOS. Not a big deal if you remember all the commands. Since it seems like I’m frequently installing something (Linux, Windows 10, etc.) on a different I thought I would make a quick blog post listing the steps for next time.

  • First convert the ISO into a disk image for macOS.
  • Then rename it to .img
  • Use diskutil to find the target USB drive
  • Unmount the USB drive and write the img file
  • Eject the USB drive
hdiutil convert -format UDRW -o targetfile.dmg sourcefile.iso
mv targetfile.dmg targetfile.img
diskutil list
diskutil unmountDisk /dev/disk4
sudo dd if=Desktop/targetfile.img of=/dev/rdisk4 bs=1m
diskutil eject /dev/disk4

I usually get an error from macOS when I’m done about not being able to read the USB disk. It is also fairly quick too.

Posted in Tools | Leave a comment

4 Years at Embarcadero Technologies

This week I am celebrating my 4 year anniversary at Embarcadero Technologies. Time has flown by and a lot has happened. Mostly a lot of good milestones. One of my favorite things is experimenting with developing on new devices, so I thought I would list some the new platforms and devices I’ve developed for with Delphi since joining Embarcadero.

  • Android support was released shortly after I joined Embarcadero. This was and is a huge deal. I think when Embarcadero started down the path to add mobile support iOS was much bigger than Android, but now that has decidedly tipped. iOS is still very popular, but Android is the more popular platform, especially for line of business type development.
  • Google Glass is just an Android platform, but the fact it worked out of the box with Delphi is a pretty big deal. I still have my Glass and use them from time to time. If I had prescription lenses or didn’t need my regular glasses I would probably wear them more. I am a big fan of wearable technology and the Android platform.
  • Android Wear is another Android device, but still great to work with and develop for. This just worked with Delphi. I’ve tried with a few different Android watches, but different manufactures, round and square displays, and they all worked great. Despite the much lower power on Android Wear devices Delphi apps still performed great thanks to the native compiled binaries.
  • Amazon Fire TV, FireTV Stick, Ooya, and other Android set top boxes all just worked with Delphi’s Android support. I even made a simple game to play to play with them. Sometimes when I see these new devices I wonder if it will require some effort to make it work, but typically it just works.
  • Emotiv EPOC EEG Headset is a Brain-Computer Interface that reads your thoughts and interfaces them directly to the computer. I toured a number of software developer conferences, including some keynotes, with my Delphi developed thought controlled Parrot AR Drone.
  • Bluetooth Heart Rate Monitors, Scales, etc. the scale was extra of fun because it didn’t have a GATT standard, so David and I spelunked it to get it to work. Found out the measurement was in some unusual metric measurement like decagrams, and had the high bit and low bit used to indicate something else.
  • Linux is the newest official platform to be added. Out of the box it is Linux server, but thanks to FMXLinux by KSDev you can build Linux GUI applications on it as well. Again it officially supports Redhat and Ubuntu, but most other common Linux distributions are reported as working as well.
  • Beacons are a cool new technology that provide proximity information, and thanks the triangulation between multiple Beacons you can do indoor location as well. The BeaconFence technology make it all even easier to work with too.
  • Raspberry Pi3, Beaglebone Black, and other Single Board Computers were fun to work with. Since they have ARM CPUs it is simple a matter of loading Android on and they work like a charm. Sometimes installing Android was the most challenging part.
  • Arduino isn’t a target directly for running a Delphi app on it, but when I used Boian Mitov’s amazing Visuino and then his Communication Lab components it is really easy to build an app on the Arduino and then talk to it from an app running on Delphi.
  • Latte Panda is an Intel + Windows 10 based SBC with an embedded Arduino chip. This is like the best of both worlds when it comes to SBC projects. It is a full fledged Windows 10 computer, but you can dual boot Linux (which I did). In theory you could install and run Delphi on it, but I wouldn’t recommend it. I did install Visuino though, and it could talk to the embedded Arduino just fine. A real thing of beauty.
  • REST Services aren’t really a device, but a lot of devices expose their data via REST Services. The built in REST Client Library and the new RAD Server REST Server solutions make it really easy to talk to pretty much any REST Server you encounter.
  • Chrome OS is Google’s entry into the OS market running on Chromebooks, which are halfway between a tablet and a laptop. Google recently started rolling out Android support on the latest Chromebooks, so I picked up Samsung Chromebook Pro and sure enough, Delphi Android apps work great on it. While I was in there poking around I discovered Chrome OS is running on Linux at the core, and since the Samsung Chromebook Pro has an Intel CPU I decided to try targeting it from Linux support, and it worked too. Now I am thinking this might be my new favorite laptop!

That is a lot of new devices and platforms in four years. And I know I didn’t get all of them (like the Chromecast, the Kinect, Philips Hue Lights, etc.) Just take a look at our supported IoT Device list. I am looking forward to what the next 4 years holds in store for Delphi, C++Builder and RAD Studio.

What is your favorite new platform for Delphi? Or maybe you are a big fan of the fact we now have the free Starter edition?

Posted in News | 3 Comments

Exceptionally Bad Exception Abuse

Nick Hodges' Coding In DelphiI was reading Nick HodgesCoding in Delphi again last night (insomnia). In chapter 1 on Exception Handling he opens talking about how not to use exceptions. It got me thinking about some of the atrocious exception usage I’ve seen. I thought I would share a few examples beyond the usual exception sins.

The Try / Except / Raise / Free Pattern

The documentation on the Try / Except pattern says that all the code after the Except block gets ran because the exception is handled. Additionally you can call Raise during the handler to send the exception further up the call stack.

I had just started a new job and was sitting with one of the senior developers to fix some bugs and get to know the codebase. He was creating a local object and so needed to free it. This is the pattern he used:

sl := TStringList.Create;
try
  // using sl
except
  raise;
end;
sl.Free;

I looked at the code for a minute quizzically, and then asked why he did that. He explained that everything after the except always gets ran, so he can be sure the memory is freed, but still let the exception bubble up to the global exception handler so it is logged. I told him that I was pretty sure calling raise in the except block prevented the code after the block from being ran. He assured me he had been writing code like this for a long time, and it always works.

I thought about it a bit more and then suggested we test the code. So we made a little test application with a message after the except block, and forced it to raise an exception, and sure enough, the message didn’t show. (Always test your theories and patterns with test code!)

There was a look of panic on his face. He’d been using this pattern for years, and it was all over multiple codebases. He claimed that the documentation must be wrong or it changed in a recent update, but I tried to assure him that is was clear and always worked that way, he just misunderstood.

Log ’em All and Let Support Sort ’em Out

This was using an early version of C# and WinForms.NET in Visual Studio. I took over a project and was having a hard time tracking down some odd behavior. Some code just wasn’t being ran, and there was no error messages. This was a project that was really, really early in the development process, and my first large scale project in C#, and I was getting really frustrated.

I finally discovered that an exception was being raised, but it was never showing up as an error. Even if the debugger was attached there was no exception message. The program just kept on running as if nothing happened, but the operation aborts. I started to question .NET’s ability to handle exceptions.

I dug and dug and finally figured out that the previous developer had setup a global exception handling and logging system that captured all the exceptions and logged them into the eventual support database with a detailed call stack. IIRC WinForms apps close automatically if there is an unhandled exception, so having an exception handler is a good idea, but silently logging them seems questionable. And then since there was an exception logging system in place the developer set the project options to have the debugger ignore all exceptions.

The result is an app running completely silent of exceptions, even while developing, but at least support will have a lot of debug information. I talked to the original developer, and he thought it was a brilliant idea, and said it is the first thing he does in all his projects. He just looks in the support database to see if things are working. His logic being users don’t want to see error messages. Not sure how hiding all the error messages is a good idea, especially hiding them from the developer during development.

Exceptions as Robust Return Objects

I was maintaining some code where a previous developer built this system where custom Exception were used to return a complex type system. He built this impressive hierarchy of exception classes, and then only certain types of exceptions were handled at different levels, where the data was needed. So instead of methods returning a result, or modifying a passed value, they all just raised different exceptions, with the properties set to different values.

There are really two issues here in my opinion. The first is raising and handling exceptions is rather expensive. A better option would have been to just create plain old objects (or even interfaced objects) and return them as results. You can still examine their types and decide when to handle them. You would just need to be aware of managing the object lifecycle (the automatic lifecycle handling was his justification for using exceptions).

The second issue is this was just one subsystem of a larger project. It was only this subsystem that used this bizarre data management system. So when you were fixing a bug here there was a mental tax of wrapping your brain around the different architecture. As soon as you figure it all out, fix the bug, and move on to other code you go back to the normal way of thinking. Again paying the mental tax of forgetting the atrocity you just witnessed.

I really believe that in a large project there should be some consistency in how the pieces are architected unless there is a compelling reason to do things different in one subsystem. That makes it easier for developers to work in different parts of the system.

So what are the craziest abuses of exceptions and exception handling you’ve seen?

By the way, Nick has a new book out on Dependency Injection in Delphi. You should pick up a copy.Nick Hodges' Dependency Injection In Delphi

Posted in Architecture, Funny | 11 Comments

The April 2017 Tokyo Hotfix Works with the new Xcode & iOS

Apple pushed out a new Xcode and iOS this week with WWDC. Naturally I updated and tried it. Xcode version 8.3.3 (8E3004b) and iOS version 10.3.2 (14F89). I’m running 10.2 Tokyo with the April 2017 Hotfix and it all worked as expected. I deployed to my iPad and the iPhone simulator (I don’t have an iPhone anymore, upgrade to a Pixel XL!)

Are you running Toyko 10.2 with the April 2017 Hotfix? There are updates coming too. Check out the roadmap to see what is planned for 10.2.1 & 10.2.2. Great new features and a lot of fixes too!

Posted in iOS, News | 5 Comments

Simple Mobile FireDAC App

The DocWiki has a great mobile tutorial on building a mobile To Do app with FireDAC and SQLite. I find I usually build it a little differently though, so I thought I would share my code here.

Go ahead and lay the UI out the same, and put down most of the same FireDAC components, with the visual LiveBindings. I love how it uses the LiveBindings wizard to create the data source. What I change is the code in the event handlers, but what you don’t need is the Insert and Delete FDQuery components. While that code all works, it uses an older model that doesn’t take full advantage of the amazing features of FireDAC.

So your form will look something like this . . .

FireDAC-ToDo-1

Add an implementation uses clause

uses FMX.DialogService.Async, IOUtils;

And then your addButtonClick event handler will look like this . . .

procedure TForm42.addButtonClick(Sender: TObject);
begin
  TDialogServiceAsync.InputQuery('New item',['Name'], [''],
  procedure (const AResult: TModalResult;
             const AValues: array of string)
  begin
    if (AResult = mrOK) and (Length(AValues) > 0) and
       (Length(Trim(AValues[0])) > 0) then
    begin
      FDQuery1.InsertRecord([AValues[0]]);
    end;
    UpdateDeleteButton;
  end);
end;

You’ll notice a few changes. First of all, I used an anonymous method for the async callback. Also, instead of using an entirely different insert query, I just call InsertRecord on the existing FDQuery1, passing in the value. For simple tables like this one this is so much easier. This really simplified the code in my opinion. Also instead of spreading the code to update the Delete button’s visibility all over the place I used a procedure called UpdateDeleteButton. Here is the rest of the code with a few comments.

procedure TForm42.deleteButtonClick(Sender: TObject);
begin 
  // Again we use the built in Delete method instead of a separate
  //   Delete query. This just deletes the currently active record.
  FDQuery1.Delete;
  UpdateDeleteButton;
end;

procedure TForm42.FDConnection1AfterConnect(Sender: TObject);
begin
  // This makes sure our table exists, just in case the data file
  //   no longer exists. Makes the app more resilient. 
  FDQueryCreateTable.ExecSQL;
  // And let's not assume anything about that Delete button status
  UpdateDeleteButton;
end;

procedure TForm42.FDConnection1BeforeConnect(Sender: TObject);
begin
  // We don't need to use a compiler directive here, but that does
  //   mean our database file is in our documents folder, which 
  //   doesn't make as much since for a desktop.
  {$if DEFINED(iOS) or DEFINED(ANDROID)} 
  FDConnection1.Params.Values['Database'] := 
    TPath.Combine(TPath.GetDocumentsPath, 'todolist.sdb');  
  {$ENDIF} 
end;

procedure TForm42.ListView1Click(Sender: TObject);
begin
  UpdateDeleteButton;
end;

procedure TForm42.UpdateDeleteButton;
begin
  deleteButton.Visible := ListView1.Selected <> nil;
end;

The beauty of calling the FDQueryCreateTable.ExecSQL is that you don’t need to deploy an empty database file. It just creates an empty one the first time it runs.

So what do you think, is this simpler? What would you do differently?

Posted in FireDAC | 4 Comments

Get Bit Episode with Holger Flick

Holger FlickNick and Jim talk with MVP Holger Flick of Korfmann Air Technology and Flix Engineering fame about smart textiles, the different software development disciplines and the future of technology. Holger also reminds everyone to see him and others at the Delphi Code Camp in Germany.

Posted in Audio podCast, MVP, podcast | Leave a comment

Rapid Prototyping Mobile Projects with Arduino and Open Hardware

These are the slides from my Mobile Dev and Test session on Rapid Prototyping Mobile Projects with Arduino and Open Hardware in San Diego. I’ll update later with links and more resources.

slides download (v0.9)

SlideShare

Visuino Links

Posted in News | Leave a comment

Some Great Women of Programming

It frequently puzzles me that programming seems to be dominated by men when the founders of programming and many of the greatest programmers were women. I read an article that this may be contributed to by early home computers being advertised as game systems for boys, which tipped the scales temporarily.

Here are a few amazing women who pioneered the computer programing field.

Ada LovelaceLady Ada Lovelace (1815 – 1852) Invented the idea of programming. Her father Lord Byron was known for his poetry. Lovelace was a poet of mathematics.

[The Analytical Engine] might act upon other things besides number, were objects found whose mutual fundamental relations could be expressed by those of the abstract science of operations, and which should be also susceptible of adaptations to the action of the operating notation and mechanism of the engine…Supposing, for instance, that the fundamental relations of pitched sounds in the science of harmony and of musical composition were susceptible of such expression and adaptations, the engine might compose elaborate and scientific pieces of music of any degree of complexity or extent. –As quoted by Menabrea, Luigi (1842).

Grace Hopper“Amazing” Grace Murray Hopper (1906 – 1992) invented the idea of human readable programming languages, then created COBOL. She achieved the rank of Rear Admiral in the US Navy, then had a Missile Destroyer and Cray Supercomputer named after her. The term debugging was attributed to her discovering a moth in a computer at one point. She carried around a nanosecond worth of wire to help people understand the relation between size and speed of computers.

Humans are allergic to change. They love to say, “We’ve always done it this way.” I try to fight that. That’s why I have a clock on my wall that runs counter-clockwise.

Adele Goldstine (1920 – 1964) wrote the complete technical description for ENIAC, the first electronic digital computer. And the original programmers for ENIAC were also all women: Kay McNulty, Betty Jennings, Betty Snyder, Marlyn Meltzer, Fran Bilas, and Ruth Lichterman.Betty Jean Jennigs & Fran Bilas, ENIAC Programmers

Jean E. Sammet (1928 – ) developed the FORMAC programming language, a variation of FORTRAN.

Marissa Mayer (1975 – ) employee #20 at Google, and the first female engineer. Later went on to run Yahoo.

My daughters have as much, if not more, interest in computer programming than my boys. I hope we will continue to see more amazing women in computer programming!

Posted in News | 2 Comments