Amazon.com Widgets Delphi

My Take on TypeScript

By Nick at October 17, 2012 12:43
Filed Under: Delphi, Tech Stuff, Software Development

Microsoft has been keeping the renowned Anders Hjelsberg busy on a new language called TypeScript.  Typescript is an open-source project (using the Apache 2.0 license) that allows you to write a super-set of Javascript that allows for a stronger typing system.  You can watch Anders’ original launch presentation

I’ve said a million times that I’ve said a million times that Javascript is the new Assembler – that Javascript will become the thing that everyone compiles higher level code into.  You’ll write your web apps in a higher order language, and then compile them to Javascript for execution in the browser. 

I refuse to believe that any rational person actually likes to write Javascript, and as it is designed currently, it really isn’t a language for developing the kind of large-scale applications that people seem to be wanting to use it for.  In the deep, dark past, Assembler used to be all there was, and we created higher order solutions that compiled to assembler.  And in the same way, for a while, Javascript was all there is for the browser.  Now, however, we are beginning to see higher order languages being brought to bear to produce Javascript for us. 

If Javascript is the “new Assembler”, then the Browser becomes the “new operating system”.  The cool thing about that is that the “new OS” is ubiquitous.  Just about every computer in the world – computers running Windows, OS X, Linux, Unix, whatever – has a browser that runs Javascript.  That means your application can run on any computer.  That’s a very compelling idea.

You can actually do that today with Delphi using a very cool tool called Smart Mobile Studio.  There is also the Elevate Web Builder tool from Elevate Software.  Both have the same idea – leverage the power of Delphi to produce Javascript-based applications.  Pretty cool, really.

Anders talked to Scott Hanselman about Microsoft’s offering in the “Language to compile down to Javascript” arena in the latest episode of Hanselminutes.  Anders is always a good interview – I love a guy who thinks and speaks as clearly as he does.  (That’s why I always loved a Danny Thorpe presentation.  Danny is pretty quiet and mellow, but his talks were always so clear and well organized – every single word he said was worth listening to – that they were always excellent and enormously educational.  Anders is the same way….) He does a great job discussing the notion behind TypeScript.

Here are some of my thoughts on what Anders said and on TypeScript in general.

  • TypeScript seems to exist for two reasons – to make Javascript “tool-able” and scalable. 
    • First, the type annotations, classes, modules, and other enhancements exist to allow Visual Studio and other IDEs to do things like Code Completion (the RAD Studio term that Anders used in the podcast instead of Intellisense – I loved that.  Smile  ), refactoring, and other language-based features that modern IDE’s do.  Javascript doesn’t provide enough information to let development tools do all the things that we expect, but TypeScript does. 
    • Second, TypeScript is also a way to make Javascript scale. By providing the notion of typed classes and modules, you can create larger, well-organized TypeScript applications which then compile to Javascript.   TypeScript is a language ready to do the heavy lifting that Javascript cannot.
  • Since TypeScript is a super-set of Javascript, it follows that pure Javascript is valid TypeScript.  Anders points out that you can use your existing Javascript as is inside of TypeScript.  The idea, though, is that TypeScript becomes the language you’d use instead of Javascript because of all the tooling support, and because it can be used to build applications via modules (units, for you Delphi folks).    Typescript doesn’t have any runtime or virtual machine – it literally just compiles to Javascript. 
  • You can create an external declaration file to define the types in your *.js file, so that means that existing Javascript libraries like Node.js and jQuery.js can be “typed” and thus used in the TypeScript environment.  I think that is a pretty cool idea – and I’m sure that Microsoft will be delighted if the community follows their lead and “converts” the existing popular libraries.
  • Anders also points out that TypeScript puts a “dial” on the typing level of your code.  Pure Dynamic advocates can leave everything untyped, and the strong-typing zealots can type everything if they want, and the folks who want to type some things and not type others can do that if they want.  That’s a very interesting notion – a language with a variable level of type-safety.

Now one thing to note is that tools like Smart Mobile Studio and Elevate Web Builder offer pretty much all these features as well.  There isn’t any reason that Embarcadero couldn’t make Javascript be something that is output by the Delphi compiler.  Heck, there is even a project out there to get LLVM to produce Javascript.  TypeScript would integrate well into HTML5 Builder. Whatever higher-end language you want to use, it seems pretty clear to me that Javascript will be the thing our compilers will be producing in the not-to-distant future.

Are you going to give TypeScript a look, or are you more interested in the Delphi-to-Javascript solutions?  I’ll probably check out both.  Either way I have to use a different IDE, so I’m guessing I’ll lean towards the Delphi-based solutions.  Plus, I frickin’ hate curly braces.  Winking smile

What do you guys think?

Frank is Back

By Nick at October 12, 2012 09:43
Filed Under: Delphi

This is posted without comment, because I really don’t know what to think or say.

Flotsam and Jetsam #65

By Nick at September 25, 2012 10:14
Filed Under: Flotsam and Jetsam, Delphi
  • Hey, here is something cool.  I am now an Embarcadero Affiliate.  This means that you can buy Delphi XE3 from me.     You can click on that link or any of the banner ads right now, buy, and get a great version of Delphi.  I’d really appreciate it. Definitely.  Go on, you know you want to.  Winking smile
  • The Call for Papers for CodeRage 7 is out.  I will definitely be submitting some presentations.  This year they are actually having two CodeRages, one for Delphi and one for C++Builder.  If you have never done so, but have always wanted to be a speaker, I’d suggest that you submit some presentations.  It’s really cool being a presenter at these events.  I’ve always enjoyed it.
  • One of the unsung heroes of the Delphi community is Uwe Schuster.  Uwe does a lot of things that benefit us all.  Most prominently, he basically wrote and continues to update the Version Insight feature in the IDE.  If you are storing your Delphi code using Subversion, Mercurial,  Git, or Jedi VCSm then you should be using the IDE integration that Uwe has provided.  It’s actually quite amazing.  The Live Blame feature alone is worth it.  But that isn’t all – Uwe has a bunch of really good IDE plugins, including a nice TStringList visualizer, an expert that enhances the Object Inspector, and for those of you who hate the new modeless search feature, a modal search dialog.  So here’s an official F&J ShoutOut to Uwe for all the cool stuff he does.
  • The Jedi VCL Library is now ready for XE3.  I for one am very appreciative of all the great work the Jedi team does for the community.
  • I don’t know if many of you know Joe Hendricks. He’s been a Delphi community member for a long time.  Both he and his wife Heidi have been battling cancer for many years, and his Facebook posts about their progress, adventures, and life were an inspiration to me and many.  Their faith in Jesus was evident throughout everything they did.  Heidi passed away early this week.  I’m saddened at the loss of a woman I never met, but who was in inspiration to me.  And I send my condolences to Joe, who was a fine example of what it means to be a man, a husband, and a Christian.

Flotsam and Jetsam #64

By Nick at September 05, 2012 19:00
Filed Under: Flotsam and Jetsam, Tech Stuff, Delphi
  • Jim McKeeth was kind enough to interview me for the The Podcast at Delphi.org.   It was fun to do. 
  • In a previous Flotsam and Jetsam, I mentioned that I had received as gift an ASUS RT-N16 and loaded it with the TomatoUSB firmware.  So far, it’s been working great – I really like it.  The reason I did it was to be able to have better control over the Quality of Service so that I could install an Ooma Telo  Well I have done so, and am quite pleased. 
    • I paid the $40 to have my number changed over.  It took about ten days, and now I am running the Ooma as my house phone. 
    • I got the Ooma Telo from Amazon for $150 (a special price, apparently, as the price appears to have gone up), and paid $40 for the number transfer.  I have cancelled my phone service from Comcast, saving about $50 a month.  That means that the Ooma Telo will pay for itself in four months, and save me a pretty good chunk of change going forward.  
    • And here’s a fun thing about the Ooma – I can take my home phone with me.  If I say, take a trip to my folks house, I can bring the Ooma, plug it in, plug in a phone, and I have my “house”  phone there wherever I am.  I don’t know why I find that amusing. 
    • One concern I had was the fact that if the power goes out,  my phone goes out.  But that’s true for my Comcast phone as well, though it would take a while for the battery to wear out.  In addition, we live in a development with lots of neighbors, and we have cell phones.  And lots of people are starting to get rid of their house phones all together, so that turns out to be a minor concern for me anyway.
  • Alas – Barry Kelly has moved on from Embarcadero. His contributions to Delphi are many and lasting.  I don’t know if I’ve ever met a smarter person, frankly. He’s also just a very interesting guy generally.  Good luck to you, Barry.
  • I won’t be the first Delphi book on LeanPub.  Currently available is Parallel Programming with OmniThreadLibrary by Primož Gabrijelčič.  (You did catch that I am writing a book, right?)
  • There are some pretty cool goodies that you can get if you buy RAD Studio XE3 right now, including a FireMonkey grid from the excellent folks at TMS Software.  It’s called the RAD XE3 Bonus pack. 

I’m Writing a Book

By Nick at September 03, 2012 08:09
Filed Under: Delphi, General, Software Development, Unit Testing

I’ve decided that my first official act as an Embarcadero MVP will be to write a book.

Here’s some details:

  • You can see the outline and a brief discussion here.
  • I’m writing it on LeanPub.  LeanPub is very cool.  They make it very easy for a guy like me to write a book – that is, a guy who doesn’t really know anything about the process of actually producing a book, as opposed to the content in the book.
    • LeanPub outputs to PDF, MOBI, and ePub formats. 
    • Eventually I’ll probably put the book on Lulu or some other on-demand publisher to allow folks to get physical copies if that is what they prefer.
    • You can view the outline on the LeanPub page
    • The book will contain a lot of content from my blog, but of course I’ll enhance and improve that material.  And there will, of course, be a lot of new material.
    • Many of the topics will include the Delphi Spring Framework, DUnit, ,and other cool new frameworks. 
  • I’ve actually been working on the book for a while, but once I saw LeanPub, I knew that I had to make the move official.
  • You can sign up to find out when the book gets published.  You can also tell me how much you are willing to pay for the book. 
  • LeanPub lets you very easily update and enhance the content.  So I’ll probably publish well before I’m done and then update as I go along.
    • This will allow early buyers (who will likely pay a lower price) to provide feedback.  Sort of like a “beta test” program.
    • It will also let me correct mistakes
    • And of course all purchasers will always have access to the latest and greatest version.
  • I’ll naturally incorporate feedback as much as I can.  Your help will make the book better for everyone.
  • I don’t know yet what I’ll charge and when.  That’s another cool feature of LeanPub – I can experiment with the pricing.  A lot of books on LeanPub have a variable, choose-your-own price models.

So I’m pretty excited.  LeanPub really was the catalyst to finally move ahead and make my idea public. 

So give the book a look, sign up to receive updates, and please feel free to provide feedback – I’m interested in what the community has to say.  As long as you are polite and professional, of course.  Winking smile

On the EULA and the Delphi Community

By Nick at September 02, 2012 13:24
Filed Under: Delphi, Leadership, Personal

I won’t rehash the details of the recent “EULA Incident”.  You can read about it for yourselves in the newsgroups or on various blogs and comments.

I want to talk, instead, about the reaction, response, and behavior of some of the community to the event.

First, I’m well aware that because on the internet no one knows you are a dog, people feel free to behave in ways they never would in person.  I have been as guilty as anyone of this over the years, though I daresay that I like to think that I’ve become self-aware about the issue and been a much  better online citizen over the past few years.  However, being on the internet isn’t an excuse to be rude, offensive, and, well, a jerk.

And frankly, the response to the EULA issue by the Delphi community was shameful.  Seriously.  It wasn’t a rational discussion, it was a witch hunt.  I’ll not weigh in on the issue at all other than to say that I was glad to see Embarcadero respond to the uproar by deciding not to make the change.  And when I expressed that sentiment, I was pretty aggressively attacked for apparently not participating in what I called the “public flogging”.  And then I was aggressively attacked for calling it a public flogging.

And it was a public flogging.  It couldn’t even remotely be described as a professional discussion.  I understand that the proposed but never adopted change would have had a rather profound effect on many people.  But even so, that is simply not an excuse for meanness and vitriol.

Why am I writing this? Well, because I consider David Intersimone one of the finest men I’ve ever known and a good friend.  He is kind, gentle, smart beyond reason, and very, very dedicated to the Delphi community.  And for the Delphi community – whom he has served so well for many, many years – to treat him so badly was, well, very, very painful for me to see.  DavidI didn’t even remotely deserve the treatment he got, and those of you who were so unpleasant to him should be ashamed of yourselves. 

They say “All’s well that ends well”.  The Delphi XE3 EULA controversy apparently is ending well. 

But the Delphi community’s treatment of its longest and dearest friend did not end well at all.

Honored to be an Embarcadero MVP

By Nick at August 26, 2012 05:35
Filed Under: Delphi, General, Personal

I am honored to be included amongst a rather large list of impressive developers as an Embarcadero MVP for Delphi.  The program is still young, and so I’m not entirely sure what it means to be part of it, but whatever it is, I’m honored and pleased to be included, and I’ll do my best to be worthy of that honor. 

There is already a nice perk to the position – the team at DevJet – about whom I can’t say enough nice things  – have given us free versions of all their products forever. That’s a long time!  This is very cool, as I am a big fan of Document Insight, including the new Enterprise version.

I’m looking forward to seeing where this all goes.  So my thanks to all of you and to Embarcadero.

Flotsam and Jetsam #63

By Nick at August 23, 2012 20:38
Filed Under: Delphi, Flotsam and Jetsam

Flotsam and Jetsam #62

By Nick at August 22, 2012 08:36
Filed Under: Flotsam and Jetsam, Software Development, Delphi
  • Okay, so it looks like the release of Delphi XE3 is imminent.  My friend Tim Del Chiaro (the Delphi Insider) has announce the World Tour for the release.  The official page is here.  Tim also mentions something about a new product “HTML5 Builder”.  That sounds interesting.
  • JT, the Product Manager for RAD Studio, has a blog post with more info. I’ve not dabbled much in mobile development yet, so the most interesting part was “by adding memory management features such as automatic reference counting” – that’s very intriguing.  This could add a whole new dimension to the great FreeAndNil debateWinking smile
  • I’m always looking to sell stuff on ebay – so when I put in my new ASUS RT-N16 router, I thought I’d sell the old one.  Apparently, I’m not the only one doing that, as the router that Comcast gave me is worth only about 15 dollars, if that.  They are $40 at Amazon. Oh well.  Winking smile  I was hoping it was worth a bit more.  But hey, $15 is a lot of money, right?
  • I think I’ve said at least 453 times how much I love FinalBuilder.  So I’m always happy to pass along good news about what the folks at VSoft are up to.  Their latest is a very intriguing product called Continua CI, recently released in beta.  It’s a follow on to their FinalBuilder Server product.  I say “follow on” and not “upgrade” because it looks to be something quite a bit different and improved. Robert Love has a good write-up on it as well.    We here at Gateway Ticketing currently use Jenkins in concert with FinalBuilder, but if the licensing for Continua is favorable, it might be something for us to consider.  In any event, I always recommend looking at anything at all from the fine folks at vSoft Technologies.

Cool New Tool: Delphi Code Coverage

By Nick at August 18, 2012 10:27
Filed Under: Delphi, Software Development, Unit Testing

Code Coverage is an interesting topic – Wikipedia defines it as “the degree to which the source code of a program has been tested.”  The idea is that you want to measure what percentage of the lines of code in your application are executed when you run your test suite.  The “perfect” test suite would execute every single line of code in your codebase.  Being able to definitively measure that goes a long way towards validating your testing suite and giving you confidence that your tests are thorough and testing everything that needs to be tested.

So I was really happy to run across the Delphi Code Coverage tool. I was intrigued and interested, so I downloaded it and gave it a look. And I really liked it.  I decided to run it through its paces by checking the code coverage of the unit tests for my THTMLWriter project. It didn’t take me long to figure out how to use it.   It’s written by Christer Fahlgren.  He blogged about it back in 2010.  It has a couple of other committers, and it’s been an active project throughout out 2012

The project includes this note: “The 1.0 release was made possible through the generous support of DevFactory.” I thought that was cool, and so I encourage you to go to their website and check out their services.

Some things to note off the bat:

So what did I do?  Well, first I pulled the source to make sure I had it.  Then, I went ahead and downloaded the RC7 build, which has one file in it:  codecoverage.exe.  I took that file and put it in a folder along my path so I can call it wherever I need it.

Then, I read the nice simple documentation.  I was just testing it out, so I ran everything manually via the IDE just to see how it all worked.  Eventually, you’d want to integrate this into your continuous integration. So here is a quick rundown of what I did and what I found. 

First, I opened up the project options for my THTMLWriter unit test application and told the Linker to create a MAP file for the project when I build it. The tools uses the MAP file to trace all the code paths that the application under test uses.

Next, I looked for the appropriate command  line switches. 

  • I used it –e switch to name the executable that would run. 
  • I used the –m switch to name the *.map file.
  • I used the –u switch to tell the tool what code unit I wanted analyzed.  Note that the switch wants the unit name, not the file name.  You can list as many units as you want after this switch.  Alternatively, you can use the –uf switch to point to a text file that has a list of unit names (one per line) to be examined.  In my case, I’m interested in the code coverage for the uHTMLWriter.pas unit.
  • I used the –html switch to indicate that I wanted the output to be an HTML file.  This would make it easier for me to look at the results in this “by hand” method of running things. 

The resulting command line was as follows:

codecoverage -e HTMLWriterTestAppTests.exe -m HTMLWriterTestAppTests.map -u uHTMLWriter -html

Note that the above command line assumes that the current directory of your command prompt is the directory where the files in question are located.  I actually put the command line in a small batch file in the same directory.

So then I executed the command.  The tool popped up the GUI Runner for DUnit, I pressed the Run button, the tests ran, and when they were done, the tool finished up and produced some output in the form of an HTML file.  (It also provided a FastMM dialog at the end of its run, which took a few seconds to appear).

image

As noted, the result was two HTML files -- one summary file:

image

and a file that shows me the coverage for the uHTMLWriter unit.  That has a header in it that tells me that I have 98% code coverage.  Not bad!

image

But the real fun part is that the file contains a complete listing of the unit, color-coded to indicate which lines were executed (in green) and which weren’t (in purple). So 2% of my code isn’t covered?  So I scanned the file and came across this:

image

Looks like I never wrote a unit test for the OpenLabel method that takes a string parameter.  (I have one for the parameter-less OpenLabel).  Okay, so I went back, wrote a unit test for that one, and re-ran the code coverage tool, and now I have code coverage for that method:

image

 

Nice!  The tool also pointed out that I don’t test that a number of exceptions get properly raised, so I’ll get working on those, too.  I’d like to be able to run the report and have it return 100% for my coverage. 

Overall, this is a nice and powerful tool to help you make sure that your unit tests really are running every line of code in whatever you are unit testing.  It’s another great contribution to the Delphi community.  Thanks, Christer.

Flotsam and Jetsam #61

By Nick at August 11, 2012 06:54
Filed Under: Flotsam and Jetsam, Delphi, Tech Stuff
  • I’ve never been a hardware or network geek, but after I read this post by Jeff Atwood about how easy it was to set up custom firmware on a router a few notches above the “cheap one they basically give you when you sign up for cable internet”, I thought that I might try it some day.  I put the Atwood-recommended Asus RT-N16 on my Amazon wish list, and lo and behold, my parents kindly gave it to me for my birthday in July.  I actually left it sitting on the shelf for a few weeks, unsure if I really wanted to use it until a friend at work told me about Ooma.  Ooma is a phone service that works over your internet connection.  It’s not true VOIP, but similar.  Once you buy the device and get it set up, you basically get free phone service (I guess you pay some taxes or something each month, but only like $4 or something).  The Ooma should save me $50 a month.  Nice.  Anyway, if you have an Ooma, you really need a router that supports Quality of Service so that your phone calls don’t get aced out when your 13 year old starts downloading some huge game or something.  So today, I broke out the router, and used these instructions to flash the firmware on the Asus router, and now I’m up and running with TomatoUSB.  Very cool.   My next step is to buy the Ooma box and get that set up.  I’ll keep you all posted, as I know that you are eager to be updated on every single little thing I do.
  • You know, I just love all the stuff that the folks at DevJet are doing.  First, they are the impetus behind the Delphi Spring Framework, which as far as I am concerned you should treat like part of the Delphi RTL, as well as the really cool tool Documentation Insight.  Now they have release a new product that is the mirror to Documentation Insight – Documentation Generator.   You can pre-order it for 30% off, too.  What does it do?  Well, it takes all those great /// comments/documentation you wrote using Documentation Insight (which, by the way, is bundled with Delphi XE2) and turns it into online content.  For instance, here is the documentation for my HTMLWriter project.  And of course, all the documentation for the Spring4D project is online as well.  Nice.
  • There are some interesting Delphi book projects in the works:
  • Nick’s Opinion of the Week:  I think that if someone wants to open source their software, then they should do so.  And if they don’t want to open source their software, then they shouldn’t. And if you have a different opinion than the author of the software, then you should express it respectfully.  If your “advice” isn’t taken, then you should leave it be.  Just sayin’. 

How Not To Code #2: Don’t Use Boolean Method Parameters

By Nick at August 04, 2012 04:16
Filed Under: Delphi, How Not To Code

Okay, let’s start off with a question.  What do you think this little code snippet does?

begin
  ProcessCustomerInput(False);
end;

Well, I’ll bet your first guess is that it processes customer input.  Good guess!  But what the heck does that False there mean?  It’s a parameter, and presumably it means something is, well, false, or that you don’t want the ProcessCustomerInput to do something, but how can you know?  You can’t.

Using Boolean parameters means that lose information for the reader of your code.  A Boolean parameter communicate nothing about the purpose or meaning of the parameter being passed.  Is False good or bad?  Safe or not safe?  Who knows?  Just as above, you can’t figure out at all what the parameter is supposed to mean or do if all you see is True or False

So if you see that in code, the first thing you’ll probably do is to go to the method declaration, and if the parameter is well named, you might figure out what the parameter does:

procedure ProcessCustomerInput(aKeepDuplicates: Boolean);

So there you go, now you know what the Boolean parameter does – apparently it tells you whether to keep the duplicates or not.  That’s great, but the original coder may not always be so kind and clear.  So if you must use a Boolean parameter, at least make the parameter name descriptive. 

Okay, I take it back – don’t actually ever use a Boolean parameter.  Instead, here’s what I suggest would make for much clearer code:

type
  TKeepDuplicates = (DoKeepTheDuplicates, DoNotKeepTheDuplicates);

procedure ProcessCustomerInput(aKeepDuplicates: TKeepDuplicates);
begin
  ....
end;

and that way you can call

begin
  ProcessCustomerInput(DoNotKeepTheDuplicates);
end;

And then your code is eminently readable and clear without having to look up the method declaration.

In addition, this way of doing things is expandable.  If your business rules change, and a third way of processing customer input appears, your code is ready.  With a Boolean parameter, you are stuck with the two options of True and False.

Easy to read, clear, and ready for the future.  Just like code should be.

Flotsam and Jetsam #60

By Nick at July 24, 2012 09:01
Filed Under: Flotsam and Jetsam, Delphi
  • Hey, Flotsam and Jetsam is back!  It’s been a while.  Sorry.
  • The folks at Helpinator are running a Absolutely Insane FireMonkey Demo contest.  I say you should give it a try.
  • Jason Southwell has an interesting project going over at KickStarterNakeyMonkey.  Cool idea.  I’ve heard about Kickstarter, but never really seen it in action. I love the idea – great way to spread the word about good ideas.  Not all good ideas need $15 million in venture capital.   Perhaps you want to get in on the ground floor of the project?
  • Okay, only like two real items, but we will take what we can get for the first Flotsam and Jetsam in quite a while, eh?

It's That Time Again: Gateway Ticketing Needs Delphi Developers

By Nick at July 02, 2012 07:05
Filed Under: Delphi, General, Software Development

My company, Gateway Ticketing, is hiring again. We are looking for Delphi developers. Actually, having Delphi skills is great, but we are mostly interested in smart people that know what they are doing when developing high-quality software.  We love Delphi and C#, but in the end, those are just languages and we know that it doesn’t ultimately matter what tool you know, but whether you really know how to write clean code.

Here are some reasons why you should consider working for Gateway:

  • We are a great place to work.  I love it here.  That this is a great place to work was so obvious to me that I moved my whole family clear across the country to join this team. 
  • We are serious about being serious about software development.  We aren’t messing around here.  While we have a large legacy code base, we are all about doing the right thing the right way with the right tools.  We insist on unit tests for your code.  We insist that you keep up with the latest innovations in writing code.  We insist that you view coding the same way that Rembrandt viewed painting.  
  • We love Delphi, and we live and  breathe it here.  We are doing cool things like using the Delphi Spring Framework, Dependency Injection, Unit Testing, and other fun stuff.
  • We use C# and ASP.NET for our eCommerce solution and all the cool stuff that goes along with that.
  • We are located in beautiful Boyertown, Pennsylvania.  This a great place to live and raise a family.  We are close to everything (including Philadelphia) but have that great small town feel.  I love living here, and you will too.
  • Our customers are some of the greatest and most fun places on earth.  We sell systems to the largest amusement parks, zoos, water parks, and museums all over the world.  This is a cool industry.  Who doesn’t love a good amusement park?

Okay, look – everyone says they want to hire “rock-star developers”.  Shoot, even we do it.  That’s all well and good, but the bottom line is that we are setting our standards really high.  And if doing that scares people off, well so be it.  We don’t want people who are scared off by high standards.  We want people who are looking for places with high standards.  We expect and demand your very best – anything less and you should find a job writing VB6 code. ;-) We really are creating a world-class place to build software, and we want folks like you to be a part of it.  You are up for that, right?

Relocation assistance is available.

And of course, here are the obligatory caveats.  We are definitely looking for people to live and work here in the Eastern Pennsylvania/Greater Philadelphia area.  Please note: we aren’t currently considering remote workers.  Naturally, you must be eligible to work in the United States. I'm sorry but right now we cannot sponsor H1B visas. :-(  We don’t care where you are from or who your parents were or what color your dog is or anything like that.  We are really only interested in what you can do.  And of course, we want you to know what we can do for you, too.

If that sounds like something good to you, please contact me.

TVirtualInterface: A Truly Dynamic and Even Useful Example

By Nick at June 30, 2012 08:25
Filed Under: Delphi, Software Development, Unit Testing

Introduction

This is the third article in a series about using TVirtualInterface.  The two previous articles are TVirtualInterface: Interfaces without an Implementing Class and TVirtualInterface: Next Steps.

Okay, enough with the not-all-that-useful examples.  I mean, the previous articles were illustrative, but not really “real-world useful”.

The true usefulness of TVirtualInterface occurs when you use it to create code where you have no idea what interface the user of your code is going to try to implement.  All the examples so far have shown only implementing classes where you do know which interface is being used.  The exception so far is the TReportingVirtualInterface example which reports information on any interface you pass to it.  Since we have proven that you can use TVirtualInterface to do something useful, let’s take it a step further.

A practical use of TVirtualInterface is to create a mocking library for unit testing.  I’ve mentioned numerous times the Delphi Mocks Framework by Vince Parrett of FinalBuilder fame.  Another excellent implementation of a mocking framework (as well as a bunch of other very innovative and interesting stuff) is by Stefan Glienke as part of his Delphi Sorcery framework.  Both of these use TVirtualInterface to provide a mock implementation for any interface (though the Delphi Sorcery code implements its own version of TVirtualInterface that works with Delphi XE – very cool).  Both, of course, allow you to pass them any interface, and they’ll happily mock your interface for unit testing purposes.  So why not do an example here of a very simple mocking object that you can actually use if you want?

ISimpleStub

A while back I wrote an article called The Vocabulary of Unit Testing.  In it I described the distinction between a stub and a mock.  I defined a “stub” as “a fake that has no effect on the passing or failing of the test, and that exists purely to allow the test to run.”  So, how about we build a universal stub – a class that can pretend to be any interface you want, and not do anything at all.  That can’t be that tough, can it?

Well, we already have a class that can implement an interface, but we need to find a way for that class to actually be the interface.  If you want a stub, the stub has to actually be the interface type you are trying to stub out, right?

First, since we always code against abstractions, let’s declare an interface:

  ISimpleStub<T> = interface
  ['{6AA7C2F0-E62F-497B-9A77-04D6F369A288}']
    function InterfaceToCall: T;
  end;

And then let’s implement it with a descendent of TVirtualInterfaceEx<T>:

  TSimpleStub<T: IInvokable> = class(TVirtualInterfaceEx<T>, ISimpleStub<T>)
  protected
    procedure DoInvokeImpl(Method: TRttiMethod;  const Args: TArray<TValue>; out Result: TValue); override;
  public
    function InterfaceToCall: T;
  end;

Because TSimpleStub<T> descends from TVirtualInterfaceEx<T>, it can implement any interface you pass to it.  It thus overrides DoInvokeImpl from  TVirtualInterfaceEx<T> as well as implementing InterfaceToCall from ISimpleStub<T>.

First, let’s look at DoInvokeImpl:

procedure TSimpleStub<T>.DoInvokeImpl(Method: TRttiMethod; const Args: TArray<TValue>; out Result: TValue);
begin
  // Since this is a pure stub, don't do anything!
end;

Not much to see here  – it doesn’t do anything.  And for a stub, that is fine.  That’s exactly what stubs are supposed to do – nothing.  We don’t care what happens when the methods get called, you just need to actually be able to call them.

That’s where the InterfaceToCall function comes in.  The class knows about the type of interface being stubbed because we are passing that type in as a parameterized type.  The class itself knows how to implement that interface.  There has to be a way to get an actual reference to that implemented interface, right?  This is where the InterfaceToCall method comes in:

function TSimpleStub<T>.InterfaceToCall: T;
var
  pInfo : PTypeInfo;
begin
  pInfo := TypeInfo(T);
  if QueryInterface(GetTypeData(pInfo).Guid, Result) <> 0 then
  begin
    raise Exception.CreateFmt('Sorry, TSimpleStub<T> is unable to cast %s to its interface ', [string(pInfo.Name)]);
  end;
end;

Since TSimpleStub<T> knows the type that T is, you can call QueryInterface on the type information about T itself to get a reference to the interface in question.  And of course, once you have that, you can pass that reference anywhere you need to stub out the interface – normally as part of unit testing.

So now, you can safely call methods on the stubbed interface.  For instance, given this interface:

IActuallyUseful = interface(IInvokable)
  ['{16F01BF0-961F-4461-AEBE-B1ACB8D3F0F4}']
  procedure SayHello;
  function ReverseString(aString: string): string;
  function Multiply(x, y: integer): integer;
end;

Writeln('Implementing a TSimpleStub');
SimpleStub := TSimpleStub<IActuallyUseful>.Create;
WriteLn('Nothing should appear between this and the next statement');
SimpleStub.InterfaceToCall.SayHello;
SimpleStub.InterfaceToCall.Multiply(4, 4);
SimpleStub.InterfaceToCall.ReverseString('blah');
WriteLn('Nothing should appear between this and the above statement');
WriteLn;

Nothing happens when you call the interface methods, but that’s by design:  stubs should do nothing.  What you can do is call them as part of your unit testing:

begin
  ...
  MyClassUnderTest := TSprocketThatTakesAnIWhatever.Create(SimpleStub.InterfaceToCall)
  ...
end;

TSimpleMock

Okay, so there’s a useful, dynamic way to use TVirtualInterfaceTSimpleStub<T> will work great for a stub that you expect absolutely nothing from.  But sometimes you need a fake interface that does something more than just existing, and when that is the case, you are creating a mock.  In my unit testing definitions article, I defined a mock as “a fake that keeps track of the behavior of the Class Under Test and passes or fails the test based on that behavior.”  Thus, a mock needs to do more than exist like a stub –  it needs to behave in a way that you can define.   So how about we take TSimpleMock<T> and make it do a basic mocking function – responding in a specific way to a specific input.

One of the most common things that a mock interface does is to respond with “this” when passed “that”.  How about we create a simple mock class that lets you define a specific response to a method call?

First, of course, is an interface to code against:

 

  ISimpleMock<T> = interface(ISimpleStub<T>)
  ['{9619542B-A53B-4C0C-B915-45ED140E6479}']
    procedure AddExpectation(aCallName: string; aReturnValue: TValue);
  end;

The interface augments (“inherits from” is not quite right with interfaces) ISimpleStub<T> and adds the AddExpectation method.  This is the method that we’ll use to tell the mock out to respond when and interface method gets called. 

Here’s the implementing class:

  TSimpleMock<T: IInvokable> = class(TSimpleStub<T>, ISimpleMock<T>)
  private
    FActions: TDictionary<string, TValue>;
  protected
    procedure DoInvokeImpl(Method: TRttiMethod;  const Args: TArray<TValue>; out Result: TValue); override;
  public
    constructor Create;
    destructor Destroy; override;
    procedure AddExpectation(aCallName: string; aReturnValue: TValue);
  end;

The first thing to notice is that TSimpleMock<T> inherits  from TSimpleStub<T>, thus enabling it to “be” any interface it wants as our stub was. And of course it also implements the  AddExpection method.  It takes as parameters the name of the method on the interface that you can call, as well as a return value for when that method gets called.  In this way you can define the behavior of the mock class however you want.

This very simple mocking example assumes that you are going to be mocking only function calls as methods on an interface. Within the confines of our simple example, it doesn’t make sense to mock procedures – they basically don’t do anything as far as the simple example is concerned.  Real mock frameworks are able to keep track of whether a procedure is called, how many times it does get called, and other things associated with procedures.  This simple example also doesn’t care what parameters you pass in, it will merely return a value whenever the named method is called.   Remember, this is a simple – but useful in specific situations -- example.  Winking smile 

The implementation of TSimpleMock<T> is pretty, well, simple.  Internally, it uses a TDictionary<TKey, TValue> to keep track of the method calls and the resulting responses that are added via the AddExpectation call.  Here is the implementation of AddExpectation :

procedure TSimpleMock<T>.AddExpectation(const aCallName: string; aReturnValue: TValue);
begin
  FActions.Add(aCallName, aReturnValue);
end;

When you add an expectation, the class keeps track of it.  When you then call that method on the interface, it is able to retrieve the expected return value from the dictionary and return it:

procedure TSimpleMock<T>.DoInvokeImpl(Method: TRttiMethod; const Args: TArray<TValue>; out Result: TValue);
begin
  Result := FActions[Method.Name];
end;

(The obvious shortcoming here is no error handling – you’ll get an exception if you try to call a method on the interface that doesn’t  have an expectation entry.  Another shortcoming is that the parameters passed mean nothing – a real mocking framework would be able to provide specific responses for specific parameter inputs.    I’ll leave correcting this problem as an exercise to the reader.  Smile )

So now, when we exercise this class, it will actually return stuff that you tell it to:

This code:

WriteLn('IActuallyUseful with ISimpleMock');
SimpleMock := TSimpleMock<IActuallyUseful>.Create;
SimpleMock.AddExpectation('Multiply', 99);
SimpleMock.AddExpectation('ReverseString', 'This is actually working');
WriteLn(SimpleMock.InterfaceToCall.Multiply(6, 7));
WriteLn(SimpleMock.InterfaceToCall.ReverseString('This does not matter'));
WriteLn;

has the following output:

image

Note that the responses are not what you think they would be based on the parameters (you think that 6 times 7 would return 42…), but what you told them to be in the AddExpectation call.

Now, you can use ISimpleMock<T> to provide specific feedback for a given method call.  Maybe you have an interface method which returns a Boolean value that you want to test. You can use ISimpleMock<IBooleanMethod> to test what happens when the method returns True as well as when that method returns False

Conclusion

Okay, so there you have it:  A useful implementation of TVirtualInterface.  Though the above examples are really simple, they can actually be used in real world testing – particularly the ISimpleStub<T> implementation. Stubbing is common in unit testing, and even though it is a very basic implementation, it can be used to stub out any interface.

None of this is useful if you know what interface you need and how you are going to implement it.  But there are cases when you don’t know what interface you will need for a particular problem, and you need to be able to flex to whatever interface the situation calls for.  Mocking and stubbing are perfect examples.  That’s a powerful and useful thing to be able to do.  Hopefully this little series has helped you see that.

My Book

A Pithy Quote for You

"No concept is so difficult that it cannot be conquered by the repeated attacks of the ordinary mind"    –  Morrison Hodges, MD (My Dad)

Amazon Gift Cards

General Disclaimer

The views I express here are entirely my own and not necessarily those of any other rational person or organization.  However, I strongly recommend that you agree with pretty much everything I say because, well, I'm right.  Most of the time. Except when I'm not, in which case, you shouldn't agree with me.