Wednesday, June 4, 2014

I officially hate hate hate the WITH statement.

This hilariously awful piece of code is from FooBars (fobar.pas), the name of the vendor has been removed so I can feel better about placing it up here to be openly criticized:

procedure TfooBarPainter.BarDrawMarkArrow(ABarControl: TfooBarControl;
  DC: HDC; MarkR: TRect);
var
  P: array[1..3] of TPoint;
  AColor: COLORREF;
begin
  with MarkR, P[1] do
  begin
    P[1] := Point((Left + Right - MarkSizeArrowX) div 2,
      (Top + Bottom - MarkSizeArrowY) div 2 + (Top + Bottom - MarkSizeArrowY) mod 2);
    P[2] := Point(X + MarkSizeArrowX - 1, Y);
    P[3] := Point(X + MarkSizeArrowX div 2, Y + MarkSizeArrowY - 1);
  end;
  // more code here.
end;

So sometimes I have used WITH in my code.  But when I read code like the one above, I want to throw up a bit.

I'm a bit shocked at how ugly and unreadable a "WITH a,b" makes the code above, and how my brain just about short-circuits when I spot one of the expressions on the outside of the with clause, inside it as well.

I'm a bit puzzled how anyone thought that it was worth writing code like this.

With foot, gun do
begin
   point(gun,foot);
   fire();
end.

When you make a feature possible in a language it can never ever be removed, it would seem.  But maybe it would be nice if use of With could become a compiler warning (optionally turned on) so that those who don't want it in their code can have some compiler help in finding them and rooting them out.  In the case above,  the code is from a very well known component developer.   I think the above extremely ugly, and suspect that judicious use of temporary variables referring to objects is a very inexpensive and readable way of writing code.

But I wonder, since WITH is ancient history for most of us, we've all long since stopped using it, if there are other unreadable areas in our code.  I think there are:


  •  Every USES statement with more than some X number of  items becomes an unreadable mess.   Have you ever tried organizing your uses clauses into sections? I find that the advent of unit namespace prefixes on unit names (WinApi.Windows) combined with grouping units by their unit namespace prefixes, really increased the sense of order in my applications.   A disorganized unordered list of 30 units is unreadable and inscrutable, but a uses clause organized into RTL, VCL, ThirdParty, the MyApp units, becomes instantly clearer.
  •  Every class with 100 or more methods in it becomes completely opaque and very hard to reason about.   Restricting method visibility (no unnecessarily public methods, no unnecessarily protected methods), helps a lot.
  • I find reintroduce, and overloaded methods add a lot to the mental noise and confusion in my head, and when I can, I like to get rid of them.
Any other things you wish to banish from your own personal Delphi coding standards?


Wednesday, April 9, 2014

XP Support ended Yesterday : What changes?

For many people nothing changes, the day Microsoft says they won't patch XP anymore.  However, if some major virus spreads like wildfire throughout the remaining XP system population on the internet, you can be Microsoft will release a "free" out of band patch for that vulnerability. It would be impossible for them not to.

For some people, and for some industries, XP really is dead.  My employer works in the healthcare market.  I believe that to operate a Windows XP machine in a healthcare setting, whether in a hospital, or a private clinic, would be tantamount to malpractice.  In the USA, and in Canada, there are laws about the steps you need to take to protect the privacy of your information.  You can not patch XP yourself, and you have no promises from Microsoft to ever patch any vulnerabilities in XP.  So, use of XP in a professional setting, especially in healthcare, would be, in my view, irresponsible at the least, and perhaps a violation of the law, in your country, if your laws protect patient privacy and hold those who fail to act responsibly to protect patients.  I am not saying anything bad WILL happen, but that something bad COULD happen, and it would be irresponsible for you to pretend that it couldn't.

XP really was a great operating system.  It was the first version of Windows that I really grew to like. The funny thing is that I can't stand operating on it any more.  I find it incredibly quirky and broken. I never liked Vista, and I loved Windows 7.  I know some people will think I'm crazy but I actually LIKE Windows 8.1 now. There are still some stupid things about it. The start "screen" and "metro" are stupid, and I hate them, but aside from the glaring stupidity of the metro crap,  Windows 8.1 is a pretty decent operating system.  I use it all day every day at work, and I like it.  I like client Hyper-V.  I like the responsiveness and overall speed of the system. When 8.1 Update 1 brings back a reasonable facsimile of the Windows 7 era start menu (non-full screen), I think many people will at last be willing to switch up from Windows 7.

As a Delphi developer,  I'm not sad to see XP go away.  It was a fantastic piece of technology in 2002, but like the machines that it ran in 2002, it belongs in a museum, not as a primary operating system on your home or work computer.  

XP introduced the desktop and home user to a fully Unicode compliant API, but true global Unicode features and functionality required installing a separate language pack for far-east language support.  XP introduced a fairly robust protected mode kernel, but ran your video drivers in ring zero, meaning that video card bugs would blue screen your system.   XP was actually really crappy, by comparison to windows 7, and in my opinion, windows 8.1 is just a tuned up kernel revision on windows 7, with a rather shabby new start menu, and a lame-duck "app store".   But below that lame layer, beats the heart of a pretty good operating system.   I find building apps in a modern Delphi version (XE5) on Windows 8.1 is pretty nice.  I like making my apps look like they belong on a modern computer in 2014.  Here are a few things I think need to die along with Windows XP:

- 16 x 16 toolbar icons.  This was a sensible choice when your laptop screen was 640x480. No more.

- Flat gray everywhere.  Give the clBtnFace look a rest, okay?

- Those stock bitmaps that shipped with Delphi 3.  Invest in some real art and icons, okay?

I suggest you celebrate the death of XP by moving your apps beyond that ancient classic windows look and feel, and into the 21st century.  XP is dead, long live Windows.

How are you all feeling about XP? Nostalgic? Still in love? Glad to see it go?  Planning to go down with the ship?



Wednesday, February 19, 2014

Interrupting Programmers (comic)

What happens to the "velocity" of a team that gets interrupted?  It's not hard to figure out.
Minimizing interruptions maximizes the work by a non-blocked programmer. Of course, a blocked programmer sometimes doesn't unblock herself/himself.   So there are no silver bullet solutions. Leaving people to flail for months, is no good. But neither is bugging them every five minutes.  

But if you are the sort of person who emails someone then walks over to their desk to tell them that you emailed them, then you need to read this even more than most people.

I found this over here, it's by Jason Heeris, and is licensed with a CC-type license.



Friday, February 14, 2014

Happy Nineteenth Birthday, Delphi!

Next year on this day Delphi will be 20 years old (Feb 14, 2015).   Time to think about what to do for the big Delphi is 20 birthday bash.

This year, Delphi is of legal drinking age in my home area (Ontario, Canada).  So tonight I will have a beer in honor of Delphi's 19th birthday. Just one. I'm a pretty moderate kind of guy.

Happy Birthday Delphi.  May the next 19 years be as highly productive, and as much fun, as the first 19.

Apparently Jacob over at Two-Desk Software is having a special in honor of Delphi's birthday. If you're interested in Castalia, go check out the special.
 





Saturday, January 18, 2014

The Best Programming Books on my Bookshelf. None are language specific.


I was one of the many people crying out for More Delphi Books, and I am glad to see that recently we have seen new books from Nick Hodges, and from others.  Today I'd like to cover the top five non-language-specific general books on programming that I think every developer should read.


1.  The Pragmatic Programmer - Andrew Hunt, David Thomas

This collection of snippets of advice is how I came to call myself a "Pragmatic" programmer.  I believe there are good principles in the "Agile" movement, but I hesitate to call myself "Agile".   I believe the practices in "Scrum" and "XP" can be done, and done well.  When I'm part of a team that takes those principles to heart and follows them, I'm happy to follow along too, when it works. But I don't take those monikers for myself, because I see "pragmatic" as the over-arching principle I follow. I do what works, and when it doesn't work, I change it up.  This book is chock full of fantastic advice. Some of the "get out there on the Internet and discover new stuff" sounds dated, as the last edition I have of this was updated around 2000, but the principles are timeless.   Incidentally my "change it up when it doesn't work" dictum is probably original to XP, and was borrowed by Scrum, and then by agile, so we're all cribbing from XP.  Nevertheless, of all the books I have read, there is no book that expresses more about how developers who do great work, and do it with reasonable efficiency work, in my opinion than this book.*



2. Clean Code - Robert C. Martin

Nobody, I mean nobody has written a book that cuts to the heart of modern professional Best Practices than Uncle Bob. Nobody.  Uncle Bob first hit my radar when he passionately and carefully expounded the principles of object oriented programming with the SOLID mnemonic. This book goes on to explain what it means to be a real software professional.  Yes, you have to unit test. But there's more.


3. Working Effectively with Legacy Code - Michael Feathers

How do I unit test that giant ball of mud that I can't rewrite?  This book answers that, and many other burning questions. I have not read any other book that gave me more hope that you can dig out of the holes of technical debt left for you to solve, than this book. Fine, now that you understand the benefits of cohesion and the single-responsibility-principle, the dangers of coupling, and the necessity of proving that your code works by writing code that proves the assertions you wish to believe about your code.  Now, how do you work with the code that you have right now, that does not now, and may not ever meet your ideals about Clean Code? This book can help.

4. The Mythical Man Month (and other essays) by Fred Brooks

No better book about the work that programmers do, the way we run software projects, and the sad blindness to historical lessons learned that seems to occur in our field, has ever been written than this book.   It contains a series of essays, each as good as the last.  Fred Brooks is my mentor, my hero, and my model of a software engineer, a craftsperson, a pragmatic programmer, a technical communicator, and an innovator in computing.   A must read.


5. The Secrets of Consulting by Gerald M Weinberg

This is a book about giving and receiving advice.  It is not pointed out nearly enough how much of a senior developer, or architect, or team leader's role consists in giving and receiving advice. Whether it is to someone who is your boss, or to someone you are being paid only temporarily (as in the title, Consulting), you are going to be better off if you read this book, and understand the lessons inside it.   This book tells you how to give your advice in a way that will be listened to.   If you want to be an effective technical communicator you must know how to deal with people, not just with machines. This book is a must-read for that reason.

What are your favorite programming books that don't cover any language, library, or specific tool, but rather cover the practice of being a programmer?

______

* I should point out that I haven't read Extreme Programming Explained, by Kent Beck, but I hear a lot of people say the same thing about the XP book. I did read the Agile Software Development With Scrum book, and was underwhelmed.    I do, however, agree with all the practices it mentions, but I feel that Agile often becomes, as Fred Brooks would call it, a "Silver Bullet", something we hope will save us.



Wednesday, January 1, 2014

Zombie Apocalypse Survival Toolkit Part 37: The Self Contained Software Environment

The following is an example of my weird sense of humor.  If you don't get it, or you aren't interested in Gedankenexperimentmy regular Delphi-themed blog content will resume tomorrow. 

Imagine you knew three weeks, or three months ahead of time, that there was going to be a major Zombie Apocalypse, or something else that would basically take the internet offline for the rest of your (possibly short) life.  Imagine, furthermore, that after some months you are able to get your basic human needs taken care of, such as a place to live, clean air, clean water, food, plumbing, electricity, and get back to life at, say, a 1950s level.   You still have your computer, but it's disconnected from the internet, and it's unlikely that anything like the internet will re-emerge in  less than, say 20 years.  You wish to be a computer guy, but you now find that the world in which you might do some computing requires you to be a bit of a rugged individualist. 

Windows is a non-starter in my self-contained post-disaster scenario.   For example, one fine day, due to some glitch in Windows activation, all your Microsoft windows operating systems cease to boot.  You don't have the source code to Windows, and you can't fix it yourself.  You are now out of the computing business.   Fine, you say, the world's over, I don't care.  But wait, it's not over...


I sometimes think about this idea of having a "self contained programming environment".   It basically has the following attributes:

1.  I have the source code to the whole thing, from the metal upwards.

2.  I can boot it up to a command prompt (live CD or Usb stick) or a full graphical desktop, without any installation, on any PC-compatible.   I can also do an operating system install onto a new system, after such a boot-up, either using an automated installer, or by hand, if necessary.

3.  I can repair anything that goes wrong with it, because it's constructed according to rational principles, and because I'm a smart person.


So let's think about how you would build this.  I can think of a number of ways to build it.    I thought about Linux but most of the Linux distributions are not designed in a way that makes them easy to use in my post-apocalyptic world.  Debian and Ubuntu have apt-build for source code rebuilding, including an apt-build world capability.   Some Source-Based Linuxes out there are pretty powerful, but I find them hard to use, there's stuff like Arch Linux, and Gentoo.

Personally, I think FreeBSD,  and DragonFly BSD have a lot to recommend them for my "zombie apocalypse" deployment scenario.  These systems are uniquely suited to my Zombie Apocalypse scenario, because they are far simpler to deploy, modify, understand and thus, repair than any Linux system, and the "ports" tree for them is much smaller, and represents a natural curated set of "stuff you would want on a desert island".    Remember that when they break you can no longer google any error messages.  A simpler system, with fewer lines of code, that is functional, will be easier to maintain than one that is larger.    The BSD kernel for example is several orders of magnitude simpler to understand than the Linux kernel.   The BSD user space layout is much simpler than the Linux distribution's layout, closer to classical Unix systems practices, and has a certain Zen to it that you have to experience to understand.

If you had a large amount of disk space to reserve for a Debian Network Mirror, say one terabyte,
and you could figure out how to keep it all working, and free of bit-rot, you could probably keep a Debian system going on your local area network.    By comparison, a complete mirror of FreeBSD or DragonFly BSD, because it contains a lot less software, would be much smaller and more portable.  It contains a lot higher percentage of the stuff you might wish you had (compilers, and such) and a lot less of the end-user stuff.  So, if you wanted to say, have a reasonable set of open source games, then I would go with Linux,  but if you wanted a more general purpose Hacking system, in the classic and noble Unix meaning of the term Hacker, not a cracker, but a wizard of software, then I would go with the BSD variants.

That zen of BSD thing makes it fun to plan with. For example, FreeBSD, and DragonFly BSD have this cool thing called the "ports tree", which is basically the ancient Unix Hacker way of getting software onto a Unix system.  Originally they used CVS (that ancient version control tool), but FreeBSD has switched to Subversion, and DragonFly BSD has switched to Git.    Because of Git's DVCS capabilities, I think it's ideal for a self-replicating deploy scenario that I think we would need while rebuilding after the zombie apocalypse.

Anyways, if the recent ice storm has you thinking about being a Survivalist, and your weird mind also wanders towards "Software Survivalism", check out Dragonfly BSD.   One USB portable drive of about 1 TB in size, and you've got a pretty amazing "self contained software survival kit" for PC compatible hardware.   Batteries included.  And source code too.  

Now if you'll excuse me, I'm off to plan a bit more about the water, the food, and the electricity parts of my survival plan.  Those might be a bit harder to figure out than the software side of my plans.
Also, I think I need a USB Geiger Counter, in case of Radioactive Zombie Apocalypse.

Tuesday, December 24, 2013

Merry Christmas to all.

Merry Christmas everyone. Here are some fun things for you to play with over the Christmas break.  Remember to put your laptop down and just hang out with those family people.

Some Toys to play with:
First, a list of interesting free stuff, a present from Scott Hanselman.

Some Delphi Specific Fun Things:

Apologies if you've seen these before, but hopefully these will be new to some of you.



  • The Itinerant Developer blogged about a Firemonkey Container for VCL forms in July, I missed it then, if you did too, check it out. Pretty cool. 
  • Nick Hodge's awesome new book mentions Delphi-Mocks by Vincent Parrett.    I'm playing with this right now, to increase my unit-testing powers. If you never read Vincent's intro post about it, this is a good read, even though it's been a year. I get the idea that lots of people still haven't seen the need for this yet, which means they aren't testing enough.
  • If you still haven't downloaded it, you owe it to yourself to go get Andreas Hausladen's latest IDE Fix Pack for your Delphi/RAD Studio.  Thanks Andreas for building such a great add-on. I use it and swear by it, for Delphi XE2, XE4, and XE5 which are the versions I have active coding duties in right now.

Update:  Wow, great link at The Old New Thing to James Micken's blog.  Worth reading everything that Raymond Chen has linked to there.  Every serious Delphi (or Win32 C/C++) developer should read Raymond Chen's blog, The Old New Thing.  But you all are already reading it, right? I especially love the first link, about systems programming, called "The Night Watch".