Amazon.com Widgets Nick Hodges | A man's got to know his limitations

Flotsam and Jetsam #70

By Nick at November 23, 2012 21:16
Filed Under: Flotsam and Jetsam, Delphi
  • Looks like Bjarne Stroustrup himself will be part of the C++ portion of CodeRage7.  That's quite a coup.
  • LeanTed now has its own URL:  http://www.leanted.com
  • Anyone out there know about TSynEdit?  Which is the "one true version" that I should be using?  I'm using this one:  http://sourceforge.net/apps/mediawiki/synedit/index.php?title=SynEdit_Home_Page but it seems like there are/might be other better/different versions out there.  Anyone have any advice or thoughts on the matter? Also, anyone know about what encoding it uses?  Can I change/set it? I confess I can't seem to figure that out....
  • Delphi is really popular in Brazil, and Roberto Schneiders is a new blogger from that lovely country.  He's written his first post about DataSnap.  Nice.
  • Cloud storage certainly is all the rage. As far as I can tell, I have storage in the following places: DropBox, BitCasa, Google Drive, SkyDrive, Asus Cloud Storage, and Amazon.  And probably some others I can't even remember.  Here's a business idea that I'm sure has already been done because I just thought of it:  Create an app that aggregates all those different chunks of space into a single drive.  That would be cool.
  • Everyone seems worried about Best Buy -- apparently they are all doomed and everything in the face of Amazon -- but I can tell you they didn't look doomed last night at midnight.  I was awake and decided to attend their Black Friday event at my local store, which started at midnight. (I had not intention of, and did not, buy anything...) The place was an absolute mad-house.  There was a *huge* line to get in when I arrive right at 12:00a, and they had a large maze set up in the store to keep people moving in the same direction.  I didn't notice any outrageous deals, but I can tell you that a lot of merchandise was available and a lot of it went out the door.  Plus it was fun -- great people watching.

Blast from the Past: Delphi may be the only choice you have

By Nick at November 22, 2012 10:08
Filed Under: Delphi, Software Development

Yet Another Blast  from the Past, this one from November 23, 2003.  This one is kind of moot now, as well, eh?

As frustrating as it is to us Delphi lovers, Delphi has always been a tough sell in corporate America -- not because Delphi isn't perfectly capable of performing any task that a corporate development team might throw at it, but mainly because many managers and decision makers aren't willing to take the perceived risk of investing in a non-Microsoft development solution. Borland has (rightly perhaps for a while in the past, but certainly not for a few years now) the reputation as being a bit on the edge financially, and so the safe, "nobody ever got fired..." decision has been to buy Microsoft. This will probably continue to be the case for some time, as Microsoft certainly will continue to be the a dominant company in the marketplace for the foreseeable future. However, I think the advent of the .Net Framework as the "platform of the future" and Microsoft's particular strategy for moving people to .Net both provide Borland and Delphi developers with a unique opportunity that actually makes Delphi the only safe development platform for a large number of projects that will be developed over the next few years.

Microsoft clearly wants us all to move to .Net, and frankly, I think we all should be happy to make that move. The .Net platform is really cool and really powerful. It provides a very capable and easily accessed framework (the Framework Class Library, or FCL) that is light-years ahead of the Win32 API. Microsoft actually seems to have finally figured out object-oriented programming. Once the actual framework becomes ubiquitous, or even the basis for the operating system itself , building, managing, and deploying applications will be much easier than it is now. I, for one, am eagerly looking forward to Delphi 8 for the .Net Framework and being able to develop applications with it.

Microsoft clearly wants you to move to the platform as well. They make it totally easy to download and install; every new operating system includes it, and they are on an all-out marketing campaign to raise awareness in the developer community in order to promote its use among software developers. The most interesting thing about all of their actions, though, is that they clearly want to force people to make the jump to .Net by pretty much cutting off existing development paths and by not providing a clear migration path for existing applications. It appears that the idea is to instill a bit of panic in their community of developers -- "Holy cow, we'd better get on this .Net bandwagon, or we are going to be left behind!"

Sadly, that is pretty much the case -- VB and C++ developers who don't migrate to .Net soon will be (are?) pretty much abandoned. Sure, there's "Managed C++", but what serious C++ developer would really want to use this neutered version of the language? VB6 developers are abandoned in the sense that VB.NET is so different from what they have done that it is pretty much a whole new language. Code written for VB6 simply won't compile in .Net. And of course, there were no existing C# projects before .Net was released. Therefore, if you are a Microsoft development shop, and you want to move to .Net, then you are pretty much talking about a complete rewrite of all of your Win32 code no matter what you were using to develop those applications. There simply is no easy migration path to .Net for your existing applications.

And that, of course, begs the question -- "What to do for a new application that needs to run on Win32 today, but that will eventually migrate to .Net sometime in the future?" This isn't an unreasonable question -- shoot, it is probably very common. There are certainly new development projects being started everyday, and .Net looms out on the horizon for all of them. It is also a question that is tough for Microsoft shops to answer. While the .Net Framework is readily available, it is certainly not ubiquitous, and there are plenty of machines out there in the corporate world, small businesses, and homes that can't even handle the .Net Framework and that won't be able to handle it for sometime yet. That means that Win32 may be the only option for new development. However, anyone starting new development today probably will want to be able to migrate that app to the .Net platform in the future. If you choose C++ or VB6 for the Win32 version, there simply is no easy way to migrate that application to .Net. Any Microsoft-based development solution for the Win32 platform today means pretty much a complete re-write for that application when it comes time to migrate it to .Net.

But hey, there is a solution -- a non-Microsoft one -- to this problem: Delphi. Delphi provides a powerful, fully-capable Win32 development platform, and with the VCL for .Net, a much, much smoother migration path for Win32 to .Net. And when you do move to .Net, Delphi 8 for the .Net Framework provides powerful tool that is a first class citizen in the .Net development world. If you are starting a new development project in Win32, and need to be able to move that project to the .Net framework some time in the future, then Delphi is your only real choice. Microsoft-only development organizations quite conspicuously have no similar choice. The VCL is cross-platform -- at least between Win32 and .Net. Applications build in Win32 using Delphi and the VCL should migrate relatively smoothly to the .Net platform today . VCL for .Net exists, and has been available to Delphi 7 owners via the Delphi for .Net Preview since last summer.

Now I am not at all claiming that the migration will be totally seamless -- you may need .Net version of third-party components, and if any of your code calls into the Win32 API directly, you'll need to update that. In addition, not all of the technologies that were in Delphi 7 will make it into Delphi 8, and certainly the presence of garbage collection in the .Net framework may affect the way your code works, but the migration is clearly not a complete rewrite as discussed above. Heck, at this year's Borland Conference, they compiled and ran in Delphi for .Net an application that was originally a demonstration application for Delphi 1 -- a 16-bit development tool! Can't get much more compatible than that.

This fact alone ought to be changing the way that developers and companies view Delphi. Delphi will drastically lower the overall total cost of a project by drastically reducing the time and effort needed to migrate a Win32 application that needs to be built today to the .Net framework tomorrow. Delphi doesn't lock you in to either Win32 or .Net and doesn't force you to move to .Net faster than you or your budget might want you to. Delaying the transition to .Net can also save money, as building applications in Win32 now for existing hardware can extend the life of that hardware rather than accelerating the hardware upgrades to run the .Net Framework.

Smart managers already know that they are stuck in a tough spot and smart Delphi developers will be quick to point out the advantages of using Delphi for new development. So if you have been looking for that silver bullet to convince your managers or your customers to use Delphi as the development tool for that upcoming project, you now have it.

Permalink|No Comments Yet|Login at the right or register with the site to add a comment.

Flotsam and Jetsam #69

By Nick at November 21, 2012 19:42
Filed Under: Flotsam and Jetsam, Delphi
  • I went to Philly Code Camp 2012.2 this past weekend.  It was a valuable use of time.  I learned a lot about Javascript (it has some unusual scoping rules) and ferreting out information about changes in databases (outer joins between old and new data can be revealing....).  In addition, I learned about a really cool add-in for most of the popular text editors called Zen Coding. It's pretty slick.  It makes writing HTML and CSS much easier.  For instance, type this:  html:5>head+body>div and then hit the hotkey for your editor and you get a nice template for an HTML five document, including the <head> and <body> tags, the DOCTYPE entry, and a <div> tag inside the body tag.  You can find out more about the extensive things you can do with it by watching this video, by reading this tutorial, and by looking at this cheat sheet.  Overall, another great code camp.
  • I completely forgot that I, along with Marc Hoffman, had the honor of being on .Net Rocks.  Cool!  It was great to see Carl and Richard at the .Net Rocks tour in Philly a couple of weeks ago.  They are really great, funny, smart guys, and they do a great job making development fun.
  • LeanTed now has basic support for table and crosslinks. The feature set is actually getting close to a 1.0 release.
  • All of the CodeRage 7 talks are online and available for viewing.  You can both download them and watch them on YouTube.  I like the YouTube part.  That's cool.
  • This video on MVVM and Delphi by Malcolm Groves of EMBT Australia is a must watch video.  This is how you should be building your applications from now on.  It's really made possible by Live Bindings.   You don't necessarily have to use the exact MVVM pattern than Malcolm shows here. He notes that an MVC or MVP pattern will do much the same thing, but we all really should be separating our concerns out so that we aren't coupling our code together. 

Blast from the Past: The Gaping Hole of Delphi

By Nick at November 21, 2012 07:56
Filed Under: Delphi, TechBiz

Another Blast from the Past. This one is mostly overtaken by events.  The sale of CodeGear makes the whole thing moot.  But I thought you might enjoy a trip down memory lane.  Things certainly have changed for the better.  This was originally published on January 6, 2006

 

Every situation, properly perceived, becomes an opportunity. ~ Helen Schucman

Yesterday I went on a sales call with two of the Borland sales reps for the region. Before hand, we met at a Dunn Brothers coffee shop to get our ducks in a row, talk about the client, etc. The meeting went well – the Borland guys are very knowledgeable, professional, and clearly know what they are doing and what they are talking about. The client could probably benefit from Borland's tools and hopefully there will be a deal done. I learned a lot about sales from the meeting. (Sales is not my strong point.)

The interesting part of the whole day was the epiphany I had while meeting with the Borland guys at the coffee shop. Sales guys are into revenue generating. They need to maximize the revenue that they get per hour of effort spent in getting revenue. That's their job. That's what Borland wants them to do, they are rewarded financially based on that, so naturally, that is what they do. I don't blame them. Opportunity costs are very real, and they have to choose where to expend their efforts.

If opportunity doesn't knock, build a door. ~ Milton Berle

The big thing I learned from the sales guys is that Delphi isn't even on their radar. They aren't given a commission on Delphi sales. That's frustrating. But here's the thing: even if they were given a commission on Delphi sales, I doubt very much that they'd sell much of it at all. Remember opportunity costs? Opportunity costs drive the salesmen to concentrate on the Fortune 100 to the Fortune 500 crowd, and the sad fact that we Delphi developers need to accept is that the market for Delphi amongst these large companies is very small. Those companies have probably already chosen their tools – either Java or Microsoft or some other open source solution – and while a concerted effort to sell Delphi into that market might work, the opportunity costs are just too high to make the effort worth it for a Borland Sales Representative. Delphi's traction is slim in that arena, but the traction for StarTeam, CaliberRM, and Together is very high. (Remember, it's all about revenue per man hour. Dollars per man-hour selling Delphi is pretty low. Dollars per man-hour for CaliberRM, StarTeam, and Together is pretty high. So, as a result, the Borland sales force doesn't sell Delphi and they do sell the enterprise products. This should not be a surprise.)

Let your hook always be cast; in the pool where you least expect it, there will be a fish. ~ Ovid

When we were at our TeamB conference in November, Boz Elloy basically said the same thing. He told us that “Fortune 100/500 companies don't want Delphi. It's a waste of time for us to try to sell it to them”. (My fellow TeamB'er Dave Nottage blogged about that meeting as well. For the record, Boz explicitly gave us permission to publicly discuss the meeting.) Boz drew a diagram with three levels: the “channel”, SMB, and Fortune 500. He basically said that they only try to sell Borland Core into the Fortune 500. (This is why you won't see Delphi having anything to do with Core. Core is Borland's Java platform, based on Eclipse, with perhaps some .Net mixed in, but only in the form of plug-ins to Visual Studio.Net) For the Small/Medium Business market, they offer Borland Developer Studio and the ALM solution. And the “channel” is sites like Programmer's Paradise that simply sell Delphi for Borland. For Borland, Delphi only really exists in the bottom two arenas. It simply doesn't exist in the highest bracket – but not to a level that would make the effort selling there worth it. (So, if you are a Delphi guy, and you hear stuff about “Borland Core”, just ignore it. I has nothing to do with you. Even though every fiber in your body screams out “Why isn't there anything about Delphi on the 'Core' pages!?!”, resist said temptation and simply let it all roll off your back. Core just isn't your deal. Now, when you hear “ALM”, your ears should definitely perk up, but Core? It's nothing to us Delphi guys. Let it go.)

Now, as I said, all this is very frustrating to a Delphi user. But if you step back for a minute, it makes perfect sense. Sales guys need to generate revenue, and so they spend their time doing that. Double the sales force won't alter this equation. It's purely a strange outcome resulting from the structure of Borland's product line. We Delphi dudes can bitch about this (and Lord knows we will), but the key thing is to get past the bitching, accept reality, and try to figure out a way to deal with this unfortunate situation.

In the middle of difficulty lies opportunity. ~ Albert Einstein

Okay, so I'm past the denial and anger stages (and I encourage all of you to get over the hump into acceptance as well), and ready to move on to trying to figure out what can be done to promote and expand Delphi. Every cloud has a silver lining. For every window that is closed, a door opens somewhere. In the middle of difficulty lies opportunity. (Someone stop me before I break my cliché meter). I really believe that there are any number of effective ways to market and sell Delphi given all of the limitations that we've already talked about.

The first thing to do is to examine the lay of the land. The thing that jumps out at me is this gaping hole that exists in the market. Delphi is sold almost exclusively in the channel. The folks that buy from the channel are, to a large degree, the little guys like us. We buy one, two, five copies for our development shop. If a medium-sized company wants to buy Delphi, they have to go to the channel as well. Unless they run into a Borland Partner that sells product, they won't get any personalized service. Delphi isn't sold into the Fortune 500 companies. But between the real little guys and the real big guys, there is this gaping hole where Delphi is useful and where lots of opportunities lay, but no one appears to be interested in taking advantage of these opportunities. These medium sized companies are ripe for the picking. I presume that many of them have modest development organizations. I presume that many are still evaluating .Net technologies. Many of them are using Visual Basic 6 – a product that has basically been abandoned by Microsoft. They know they need to make a move to newer technologies, but they aren't sure about it all. They aren't pleased with Microsoft, and would be willing to hear about products from a tools vendor that is almost compulsive about backwards compatibility and ensuring that old code can be moved forward. They might be interested in hearing about a company that is continuing to focus on RAD development in the Win32 space.

In addition, I also look out, and I see products flourishing that don't have any corporate backing (Think Ruby, Python, or Perl). These products are known and used, despite not being hawked by professional salesmen. How do they do it? They use the Internet. They use word of mouth. They use “guerilla marketing” techniques that cost very little and can reap large rewards. I see no reason why Delphi can't benefit in the same way.

Opportunities multiply as they are seized. ~ Sun Tzu

Here's an idea. Offer a free copy of Delphi Personal to any Visual Basic developer that will go on his blog and post a picture of himself holding a sign that says “I'm a VB developer and I want to try Delphi,” or witty variations thereon. If there is no Delphi Personal, send them a trial disk and a t-shirt. Something. Have them email their links to Borland so they can be posted on a webpage at www.borland.com. Get some buzz going on the VB community about Delphi – even if some of them get mad. Remind disgruntled VB developers that Borland has always and steadfastly promoted backwards compatibility and will never abandon them. The transition from VB 6 to Delphi isn't all that much harder than the transition from VB6 to VB.NET, so there has to be plenty of sales to be had in this arena. Give away a copy of Delphi Architect to the guy with the coolest, funniest, or most outrageous picture.

How about an affiliate program? If you click on the link in the upper right corner of this blog and buy a copy of FeedDemon, I get a kickback. Hence, I take every opportunity I can think of to mention the fact that if you click on this link and buy FeedDemon, I get a kickback. Good for me, good for FeedDemon. I'm also constantly hawking Amazon products as well. (Heck, I'd be a NetFlix affiliate, but they turned me down!) Now, wouldn't it be cool if we had a similar program for Delphi? Of course it would. You'd put a link on your blog, wouldn't you? Wouldn't you like to make a little cash selling the product that you love so much? Of course you would! Can you think of a reason why Borland shouldn't have such an affiliate program? I sure can't.

Finally, it would be great if, in addition to an affiliate program, it was fairly easy to become a value-added reseller (VAR) for Delphi. As a guy who's company tried to do this, I can tell you that it was really, really difficult to sell Borland products for Borland. We had to front the cash for all purchases, and deal with a maze of bureaucracy to get product delivered to customers. It sure would be nice if we simply had a vendor ID number that we could use to order product for our customers online. It sure would be nice if Borland recognized and knew the consultants that actively want to sell Borland products. It was way, way to hard for us to sell Borland products, and if it is one thing a company ought to do, is make it easy for your fanatical supporters to sell your products.

If a window of opportunity appears, don't pull down the shade. ~ Tom Peters

Delphi has a great opportunity to make a lot of traction in the current market. There is a big transition to .Net going on, and many, many organizations haven't yet made the move. Many, many organizations still want to do Win32 development, and Delphi is really the only path from Win32 to .Net, as well as the only RAD tool still actively supporting Win32. Opportunities are only valuable if they are seized, and as Sun Tzu noted, they multiply when they are seized.

The problem of course, is that Delphi is caught between two worlds. It's stuck somewhere in between the grassroots, individual developer market and the big money, big company enterprise market. Delphi's position inside Borland makes it a bit of a red-headed step child. I think the product needs more autonomy to thrive. (That's why the idea of Delphi being sold and becoming part of a separate company was pretty appealing to me.) Delphi's bright light all too often is left back in the garage, and it needs to be brought out and allowed to illuminate the marketplace. The mistake that Borland makes, I think, is in utterly ignoring this gaping hole. If you go to www.borland.com, the content will vary, but you'll almost always see information about Core and about items of interest to Enterprise-level decision makers. What you won't see is “Small/Medium Businesses Click Here” or something like that. There practically nothing there for them. If Delphi is going to be treated differently than the Core/Java offerings, then there at least ought to be a place on the Borland website where the people that Delphi/BDS/ALM is aimed towards can go and get information. Again, there's that gaping hole. The information may be there, but it isn't utterly obvious how to get to it.

Small opportunities are often the beginning of great enterprises. ~ Demosthenes

If there is one sure thing in the marketplace, it's that gaping holes will be filled with something by someone. Right now, it seems like that gaping hole left by Borland and Delphi is being filled by Visual Studio and Microsoft. Sure, Microsoft has a huge budget to market to these folks, but if ever in the history of free enterprise there was a time when you can go crazy and market a product with little or no cash, it's now. With the advent of the Internet and the shrinking world it creates, all bets are off. The opportunity is out there. What can Borland and the Delphi community do with it?

Blast from the Past: What to do with Kylix

By Nick at November 20, 2012 14:00
Filed Under:

Here's another Blast From the Past, this time about Kylix.  It was originally posted on December 12, 2003.

Sadly, Kylix isn't fairing in the market place as well as Borland would like. Borland never really releases sales figures, but it's pretty safe to say that Kylix hasn't generated as much revenue as Borland would like. (Of course, no product every does, I guess. Who wouldn't want more revenue from any product?) Whether it has or ever will actually pay for its cost of development isn't known. What is known, however, is that Kylix is a pretty cool idea, that it is the most feature rich development tool in the Linux world. Sadly, though, it doesn't seem to sell many copies.

Now, why it doesn't sell probably can be debated, but whether it is because the Linux world doesn't want to pay money for tools and applications, because it is “too buggy”, or because it “is a dead product”, the fact is that it doesn't sell well. But certainly one of the reasons that it doesn't sell is that the applications it builds are perceived as a bit unwieldy. Kylix applications require the Trolltech qt library to be shipped with them. An application built with Kylix actually has to go from Pascal through a layer to a C++ library in order to work. The C++ version has to go C++ to Pascal, back to C++ again. Such a long trip doesn't make for a necessarily clean, easy to build and deploy application. Far be it from me to complain or second guess the design decisions made by the Kylix development team, but this fact is a sticking point for many potential Kylix customers.

Actually, I misspoke. It is GUI applications that have to make these trips. Kylix brings Rapid Application Development to GUI applications and Linux, but Kylix can do a lot more than that. Kylix can build application servers and Apache Dynamic Shared Object (DSO) modules. It can build these without all the hassles of the qt library and the multiple layers of code. In fact, it makes building such applications quick and easy, and it build native code executables an libraries. Kylix's ability to create power server applications is very much an unheralded and under-appreciated feature of the product. And since Linux's strength lies in being a server, there seems to be a disconnect somewhere.

This disconnect is where Kylix might actually be able to reverse its trend and actually make some money. I propose that Borland take Kylix, strip out all of the qt-based GUI features, and sell it as a server building application development tool. Call it ApacheBuilder, or MiddleBuilder, or ServerBuilder, or whatever (it should be clear that you'd be foolish to hire me to name your product). Sell it as a great way to build the applications that Linux users are actually running – server applications.

Linux's major inroads in the marketplace have been as a server, whether it be a database server, a web server, a J2EE server, or any other kind of server. Linux on the desktop remains the dream of many a Linux Distribution seller and Slashdot cowboy, but for now, it is just that, a dream. Microsoft has no intention of letting Linux cut into its desktop market the way it has in the server market, so trying to sell a development tool that builds desktop applications may be a non-starter, but selling and marketing a tool that builds the kinds of applications that Linux users want and need -- now there's a way to make money.

Now I don't know the technical requirements or exactly what work would need to be done to make this happen. Perhaps it would be too much work to make it worthwhile. Perhaps it isn't even possible. But I do think that marketing a tool that has as its main emphasis the building of servers would hit a sweet spot in the Linux community. For instance, Apache is easily the most popular web server on Linux, and Kylix makes it pathetically easy to build powerful, native DSO libraries that run on Apache. How many potential Kylix customers even know or realize this? With the dbExpress database technology and the WebSnap architecture, building dynamic, database driven Apache extensions is quick, easy, and powerful. That feature of Kylix, however, was sort of drowned out by the hype of the RAD, GUI development side of things.

Bottom line: By actually reducing the feature set of Kylix, and by marketing it as a server development tool, Borland might actually be able to turn Kylix into a successful product, and a tool that Linux developers want and need.

Blast from the Past: Embrace and Extend, Borland Style

By Nick at November 19, 2012 16:41
Filed Under:

I've been wanting to find this post on an old hard drive or thumb drive, and then it occurred to me that I can dig it up on the good old Wayback Machine.  The post below was originally written on November 14, 2003, well before I went to Embarcadero. (You can read the original in all its glory, including the original comments on the Wayback Machine)  It was also written before the VS Shell program came about.  In it I wrote about what eventually would eventually come to pass in the form of Embarcadero Prism. 

In digging around on the Wayback Machine, I found quite a few interesting articles I wrote back in the day, and I'll be publishing them here over the next week or two.  It is kind of fun to read all the stuff I wrote when I was younger,  brasher, and more foolish. 

....or, Hoisting Microsoft by Their Own Petard

I've just returned from The 2003 Borland Conference where Borland spent an understandably large amount of time talking about the Microsoft .Net Framework (an precious little about Linux, I noted). Clearly we Delphi developers are standing on the edge of a pretty sharp inflection point, bending pretty radically in the direction of the .Net Framework. Microsoft is moving all of us into the world of managed code, and there doesn't seem to be much we can do about it. But the good news is I don't think we should want them to do anything about it -- .Net is a very, very cool platform, and one that I think we should embrace.

The inflection point doesn't just affect us developers. It actually affects Borland a whole lot more. They are the ones who have to make the tough choices about where to take their products and how to get there once they decide. Right now, all of their .Net plans are in the hands of the .Net Business Unit (formerly called the RAD Business Unit). These guys are responsible for Galileo, the IDE framework that is currently deployed in C#Builder, and will soon be deployed in Delphi 8 for the .Net Framework. Galileo is Borland's next generation IDE that builds on the code base of Delphi/C++Builder, but which clearly is moving into the .Net world.

We got a lot of good looks at Delphi 8 for .Net (hereafter called simply Delphi 8) at Borcon. During the opening keynote, we saw Michael Swindell build an ASP.NET web service, and then consume it with Delphi 8. He also did something many folks appreciated – he compiled an ran the original FishFact.dpr application that shipped with Delphi 1 (yes, Delphi 1 – the 16-bit version). That application compiled and ran just fine in Delphi 8.

But it is the development of Galileo is what provides Borland with it current, very difficult, challenge. As I listened to the Borland folks and talked to developers at Borcon, it became clear that while .Net provides an excellent opportunity for Borland and Delphi, it also makes things difficult for them. For perhaps the first time, Borland is playing catch-up in the IDE arena. Visual Studio.Net has been out for over a year, and the new, improved Version 2.0 is due next summer. While C#Builder offers some advantages in this market, it will almost certainly continue to chase Visual Studio.Net in features and support for future versions of the .Net Framework.

Borland, as we all are aware, has limited resources, and their main competition, Microsoft, has in effect unlimited resources. There is a small but highly skilled group of people developing the DCCIL.EXE compiler, while Microsoft has, literally, hundreds of people working on their compilers. Borland has a lean, mean team of developers working on their IDE, where Microsoft has, again, hundreds. Microsoft's marketing budget for their tools division is likely larger than Borland's yearly revenues. Borland has managed to compete in this environment by providing superior products and technology. However, even the staunchest of Borland groupies will agree that this gap has narrowed, and in some areas, the gap is created by Microsoft's lead.

I pondered all of this during my time in San Jose, and I've come up with a solution – a means for Borland to continue to leverage their technical expertise, to lower their overhead and to increase the return on their R&D dollars. It's not a solution that will seem immediately beneficial to most of you – indeed, I expect that the initial reaction of Delphi developers will be quite negative. Therefore, I ask you to hear me out, to consider what I've said, and weigh my argument before running off to the newsgroups to rant about how I've lost my marbles. I've bounced this idea off of a number of very smart people in the community, including people at Borland, and all of them have said that despite initial appearances, this is not a crazy idea.

First, some bona fides: I am a totally sold-out, completely assimilated Delphi bigot. I love Delphi. I was in on Delphi from the very beginning, I want to code in Delphi for the rest of my life, and I think that anyone who doesn't code in Delphi is crazy. I love Borland. I love using Borland products, I love going to Borland and hanging around the super-smart and super-nice people that work there. My livelihood is directly tied to the success of Delphi and Borland. I am on TeamB and spend interminable hours on the Delphi newsgroups doing what I can to help people use Delphi.

Second, I don't hate Microsoft, but I don't go out of my way to help them out. I like and use Windows almost exclusively, but pretty much don't choose Microsoft products if I don't have to. I buy Quicken, not Money, and I am typing this in OpenOffice, not Microsoft Word (though I confess I have Word on my machine. Who doesn't?). I don't like a lot of the things Microsoft does nor the way they generally do business, but I will defend to the death their right to do with their property what they want.

Thus, having said the above, I hope you believe me when I say that I propose what I do below with the purpose of trying to bring Delphi forward into .Net in the most competitive manner, and in a way that makes Delphi usable and desirable by the whole community of .Net developers and not just existing Delphi developers.

The Idea

Okay, enough said. Here it is – here's my idea that you all have been waiting for with baited breath: Borland should abandon the Galileo IDE, license the Visual Studio.Net IDE via the Visual Studio Industry Partner program, brand it as their own, and enhance it with their own plug-ins, features, and capabilities, including first class support for the Delphi language.

What do you think?

Okay, hey, stop hyperventilating and remember that you promised me that you'd hear me out.

First, let me flesh out the idea in order to be clear about what I mean. Borland would license the Visual Studio.Net framework and build their own version of Visual Studio.Net. They'd put Borland Developer Studio on the caption, they'd put in their own palette, colors, look and feel, etc. They'd add full and complete Delphi support. They'd sell their own, complete product themselves. Note that I am not talking about building a plug-in to Microsoft's Visual Studio.Net, but a full-blown, “Borlandized” version of the product, into which Borland can add their own value-added features. They could sell it for whatever price they think will maximize their profits.

As far as I can tell, this idea is feasible and well within the licensing of the VSIP Premier Program. In fact, there's every reason to believe that Microsoft actually wants and encourages Borland to make this leap, as I'll discuss below.

I think this is a really good idea and I am going to tell you why. Here are the reasons:

In order for people to choose Delphi, the IDE must be compatible

Delphi is a magnificent language, beautifully mixing ease of use, readability, power, and elegance. It's been marvelously managed by the R&D folks at Borland over the years. It's not messy and overdone – it's just right. That being said, though, I think most Delphi fanatics agree that Delphi is a hard sell. Getting organizations to buy into Delphi isn't easy, as C++, VB, and now C# are all easier to buy into, because, as we all know, “no one ever gets fired for buying Microsoft.”

(Don't you find the rapid adoption of C# rather galling? For years we Delphi people were told that Delphi wasn't used because it wasn't popular enough, that it would be too expensive to migrate code to it, etc. Well, C# wasn't popular either, and it's no cheaper to migrate to C# than it is to Delphi. But I suppose no one ever told us this all would make sense. Anyway....)

Galileo is not compatible with Visual Studio.Net. A Galileo project can't be imported as-is by Visual Studio.Net (you have to export it from Galileo first). Plug-ins for Visual Studio.Net don't plug-in to Galileo. Therefore, if a .NET development shop is using Visual Studio.Net, they have very little reason to buy either C#Builder or Delphi 8 for .NET.

However, if Borland's IDE works seamlessly with existing .NET projects, then many of the reasons not to use Delphi go away. Delphi programmers could work side by side with Visual Studio.Net-based organizations. If those organizations have a set of standard plug-ins for the IDE, Delphi developers can use them. The barriers to using Delphi become very short.

Borland can stop worrying about IDE development and start worrying about IDE enhancement

As it stands right now, Borland has to expend a lot of energy to build their own IDE. They have to play catchup with Microsoft in the area of .Net Framework support. The effort required simply to maintain and enhance the IDE infrastructure is effort that can't be spent on enhancing and adding value to the IDE.

If Borland were to leave the IDE infrastructure development to someone else (i.e. Microsoft), they could unleash their estimable R&D team onto the improvement of the IDE. They'd be free to implement all the things they've been wanting to add to the IDE, but can't because they've had to use up precious R&D resources trying to keep up with Microsoft.

To a large degree, the IDE world is becoming commoditized. Borland's PrimeTime IDE and the open source Eclipse project dominate the Java IDE world. Borland recently took the Java-based PrimeTime IDE and used it as the IDE for their new C++ offering. At this point, it would be crazy for any company to try to build a new Java-based IDE.

The same can be said on the .NET platform. Microsoft will always be a step ahead with their IDE, as they can begin working on it with the knowledge of what coming versions of .Net will do. Think of redoing a bathroom. By using the solid plumbing that Microsoft can provide, Borland can put all of their effort into decorating the bathroom instead of just getting by with cheap fixtures. If the plumbing is all complete when you start, you can afford to add beautiful wallpaper, high-quality fixtures, a jacuzzi, and plush carpeting.

With the commoditization of the IDE, the real selling points of an IDE are the unique value-added items that a company can provide, and if it is one thing Borland knows how to do, it is adding value to an IDE. Freed from all the “plumbing”, Borland could add value by making their version of the IDE a showcase for their technologies like Borland Data Providers, Together, StarTeam, CaliberRM, etc. Borland has plenty of things they could do to make their version of the IDE very attractive, and given the proper resources and time to spend on enhancing rather than building, the IDE, they could provide a very compelling .Net development platform that provides support for the whole application lifecycle management process.

The resulting Borland IDE would be totally compatible with Visual Studio.Net

If Borland were to license Visual Studio.Net, then the Borland IDE would be compatible with all the existing Visual Studio.Net plug-ins and enhancements, as well as with existing features like C# and VB.NET. Borland wouldn't have to expend any more effort in building and maintaining a ToolsAPI. They wouldn't have to make the effort to make their ToolsAPI compatible with Microsoft's – compatibility would come for free. Delphi developers would be able to work side-by-side with C# developers. One of the main arguments against buying Borland's tools – that their IDE's don't mingle well with Visual Studio.Net – would instantly be removed.

Microsoft wants them to do it

This part is all pure conjecture on my part, but I think Microsoft wants Borland to do this. First of all, why would they even allow companies to do so via the VSIP program if they didn't want them to do it? The way I read the general information about the Premier level of the program, they actually encourage companies to “license and distribute” Visual Studio.Net.

Second, Microsoft clearly wants Borland to succeed in selling .Net solutions to developers. Without Borland, they have no real competition in the market space, and they are, to say the least, very sensitive about this. By encouraging Borland to develop their own, competitive version of Visual Studio.Net, they encourage .Net development (and not Java development), keep the Department of Justice off their back, and keep everyone happy. It's a win/win situation for them, and not only do I think they'd be happy to have Borland go this route, I'd be willing to bet that they are actually pushing Borland to do it. Borland could use this fact to negotiate a licensing and price deal favorable to Borland's bottom line.

Profits, Profits, Profits

The only reason Borland will do this is if they think they will make more money.

Right now, I am asked all the time – Why should I buy C#Builder? Well, if we were all honest, it is a tough question to answer. If Borland were to do what I am proposing, however, you could honestly answer back “Whynot buy C#Builder? It's totally compatible with Visual Studio.Net, and it has a huge number of enhancements and improvements over what Microsoft supplies. In addition, you can use it to manage your entire application lifecycle, which you can't even come close to doing with Visual Studio.Net. Plus, you can use the marvelous Delphi language if you want, all in the same package.”

Come on, wouldn't you love to have a ready, compelling answer to the “Why should I buy Borland?” question? You know you would.

And of course, if the answer to the question is a good one, then people will buy Borland, and the more that people buy Borland, the more money Borland makes. The math on that is pretty easy.

Borland already sort of has this product out there

Borland already has a rather extensive set of plug-ins for Visual Studio.Net, including Together Edition for Microsoft Visual Studio .NET, as well as Visual Studio.Net plug-ins for CaliberRM and StarTeam. These products require the consumer to buy Microsoft's IDE. Why simply sell these as part of a Borland IDE, which happens to be compatible with existing IDE's already? Don't continue to give your customers a reason to buy the competition's IDE – give them a fully compatible solution that Borland sells them.

Objections

I'm not silly enough to think that you all will simply buy my argument without any objections. So, in an attempt to head you off at the pass, I'll use my years of experience in the Delphi community to list a few of the objections that I know will be forth coming, and address them.

Borland will be giving up control of their bread and butter product.

Yes, in a sense they will. Borland pioneered the concept of the IDE with Turbo Pascal. They have been the leader in IDE enhancement and integration since the beginning. Their reputation for innovation and technical excellence is unmatched, and making this move would be, in a sense, a cop-out.

But in another sense, giving up control may be inevitable; they might not even have a choice. As discussed above, the IDE market is trending towards commoditization. In the Windows/.Net world, this means that the IDE needs to be Visual Studio.Net compatible. Borland's IDE probably never would be compatible, and so it would very likely be marginalized at best. The C++ group gave up the control over their IDE as well, turning to the Java-based PrimeTime IDE, so the move is not unprecedented.

In addition, one could view Borland's bread-and-butter as IDE's, but really it's their ability to build user-friendly, productive IDE's that sells their products, and by not worrying about the guts of the IDE, they can dedicate all their efforts to making the IDE better, leaving the “grunt work,” if you will, to Microsoft. And who wouldn't like to get Microsoft to do all that kind of work for you?

It will end up making Borland's IDE to expensive because they have to pay Microsoft

First, Borland's IDE's are already more expensive. Second, not necessarily.

It totally depends on what kind of deal Borland can negotiate with Microsoft. If, as I said above, Microsoft is quite anxious to get Borland to become a high-level VSI partner, Borland might very well be able to negotiate a very favorable (read 'cheap') deal. Perhaps Borland could use the patents that they own and that Microsoft needs to leverage a good deal. It may very well be that Borland, and not Microsoft, holds the high cards in this deal.

Again, even if Borland can't negotiate a good licensing deal, they still will be creating an IDE that has way more value than Visual Studio.Net, and so a higher price can be justified. Integration with the ALM products like CaliberRM, Together, and StarTeam will alone make any higher price worth it.

Borland's version of Visual Studio.Net will have to be way, way better to get people to buy it

I understand this objection, but I don't think it really bears on the issue at hand, because this is true whether Borland uses the Galileo IDE or the Visual Studio.Net IDE. Either way, Borland has to make their IDE the better deal simply to overcome the inertia that buying Microsoft tools already has. By making themselves compatible with the Visual Studio.Net market, it actually makes it easier to make the value proposition to managers because one of the major hurdles of selling the Galileo IDE is removed.

Borland will never go for it, so why even expend the energy to make the case?

This seems like the hardest objection to get over, but I think it is less of a problem that most would think. Sure, the great, hard, time-consuming work that the R&D team has done on Galileo will pretty much be shelved, and perhaps there will be some resistance inside Borland to that for reasons of pride and because they won't want to throw away the investment.

First, the pride issue. I don't know that this is as big a problem as you might think. While I was at Borcon, I spoke about this idea with a number of Borland people in the .NET Business Unit, and they all were intrigued by it, including the IDE Developers that I talked to. None seems to upset about spending less time developing the IDE infrastructure and more time doing the actual enhancements that they've wanted to do but had to delay because schedules and limited resources held them back. Increasing IDE enhancement time and decreasing IDE nuts and bolts coding time was quite appealing.

Second, the objection that Borland might have about throwing away an investment isn't economically sound. The R&D costs invested in Galileo are sunk – i.e. They can't be recouped no matter what Borland does. The money is spent, and it isn't coming back. The only way Borland can make money is selling the software they've created, and if selling a Visual Studio.Net-based IDE will sell more copies (as I believe it will), then the most profitable route is to do so. Or look at it this way – the R&D time is gone, no matter what Borland sells. At this point, they should sell that which maximizes profits, and selling a Visual Studio.Net product, is, in my opinion, the most profitable way to go. It means more bang for the buck on future R&D expenditures, as much more R&D time can now be spent on enhancement instead of bug fixing and IDE maintenance.

Third, I think it is almost inconceivable that Borland hasn't considered this idea already. As I argued above, I believe that Microsoft has been trying to get them to do it, and if so, this wouldn't be a new idea for them. In addition, my aforementioned conversations with people from Borland gave me reason to believe that my idea wasn't a new one to them. (Let me be clear, they all remained true to whatever NDA's they have and they gave nothing away that they weren't supposed to, but they certainly didn't act like I was talking lunacy). In other words, they may already be taking the idea seriously, and if so, one can't say they'd think it a nutty idea.

Conclusion

Well, there it is – a radical idea to be sure, but one that clearly has merit. I bounced this idea off of a bunch of very smart, very well known people both inside and outside Borland, and not one of them thought my idea outlandish, and everyone outside of Borland thought is was a good idea. (The Borland people were appropriately tight-lipped on the matter, as they should be) All in all, I think it is a sound, reasonable plan that will help push forward the Delphi language, and thus Borland, into the inevitable world of the .Net Framework.

Using LeanPub’s Markdown

By Nick at November 18, 2012 14:53
Filed Under: Delphi, Software Development, TechBiz

I’ve been doing a lot of Markdown lately.  It’s a pretty interesting notion – it’s similar in concept to HTML (a mark”up” language), but Markdown is about 443 times simpler.  Jeff Atwood is a big fan (StackOverflow uses Markdown for formatting questions and answers…) and called out Markdown’s creator, John Gruber, to be a better “parent” to Markdown back in 2009.  Recently, he has called for a standardization of the language, asking Gruber to take the lead in doing so.

Apparently, however, John Gruber, creator of Markdown, wasn’t as, ahem, “supportive” as he could have been.  At first, Jeff didn’t at first get response, but apparently then he did.  But apparently Gruber wasn’t exactly into it, or even that respectful about Jeff’s reasonable request.  I guess he’ll “think about it”.  Gruber clearly is more from Philadelphia than most people from Philadelphia, I guess.  Jeff points out that Gruber created something pretty cool, but then hasn’t exactly been the most benevolent of fathers.  And he’s not asking for anything other than a blessing on what they are doing, really.  Gruber could clearly be a bit cooler about it than he is being.

Markdown is one of those things that can easily become bastardized.  It’s specific purpose is to be human-readable and human-writable.  However, the temptation is quite great to start adding to it, making it not both of those things.  Hence Atwood’s appeal.  I hope Jeff makes something happen in this area, with or without Gruber’s support.

Anyhoo.  I’ve been using Markdown because that is what LeanPub™ uses it to create books.  As I said above, one of the main ideas of Markdown is that it should be both easy to type and easy to read un-rendered.  But that doesn’t mean that we geeks don’t want a tool to create it.   Winking smile.  The most popular editor for Windows appears to be MarkdownPad, which is a nice tool.  There is an early version of a WYSIWYG editor for Markdown called Texts – it looks promising but has a ways to go.  Some folks appear to be using Emacs (yuck!) or other editors only available on the Mac. 

However, LeanPub™ appears to be doing what Atwood is worried about – extending it just a little bit beyond what the standard is.  That’s fine -- they’ve added Tables, and different code tags using Pygment – all of which are not supported by the “normal” editors.  For instance, I’m writing a technical book with lots of code samples, and tools like MarkdownPad can only be so helpful.  As  much as Markdown is meant to be human-writable, it’s a bother to add in manually the tags for Delphi code blocks, for instance.

So pursuant to that, and because I want to make writing my book as easy as possible, I’ve built a Markdown Editor -- I'm calling it LeanTed --  that is designed specifically for LeanPub™ authors.   It implements the LeanPub™ Markdown standard, supports code tagging, and other Markdown stuff that is used by LeanPub™.

It is written in Delphi XE3, as you would expect of me.  The main editor window is a TSynMemo, and it uses the Ribbon controls that ship with Delphi. 

You can get it here.  Please be warned – this is currently a very early version and not fully featured.  I’m using it myself to write my book, but I understand all the quirks.  I’ll be refining it as I use it more, of course. 

Features that I already have on the list to be added include:

  • Implementing LeanPub’s Table support  and CrossLinking -- (The current Table stuff doesn't do anything other than display what would be added....)
  • Associate it with *.md files
  • Notice when the file has changed elsewhere
  • Timed Autosave
  • Synchronize the text and preview modes (anyone have any idea how to control the scrolling on a TWebBrowser control....?)
  • A lot of little details that I’m keeping track of in my TODO list…
  • Anything anyone thinks of that would be a good feature.

I’m releasing it as Freeware, but please feel free to donate to me for the software.  $15 would be niceSmile

In any event, please let me know what you think in the comments, and please remember that this is totally alpha-level software and that you use it entirely at your own risk.  I will, of course, be updating and improving it, incorporating feedback and suggestions. 

Measuring Developer Productivity

By Nick at November 11, 2012 12:19
Filed Under: Delphi, Leadership, Software Development

Introduction

If you go to Google and search for "measuring software developer productivity" you will find a whole lot of nothing. Seriously -- nothing.

Well, okay, not exactly nothing. You'll get a ton of links. But almost all of the links you find will talk about how measuring the productivity of software developers can't be done effectively. Some people will even argue that it shouldn't be attempted at all. Some others will describe techniques to measure developer productivity, that, well, everyone else knows don't really work.

There have been many valiant attempts to measure developer productivity, but all seem to end in less than successful territory. (We all know to laugh at "Lines of Code" as a productivity measure). Virtually any objective measurement you can apply to the software development process can be "gamed" into submission.

There are just too many variables to account for everything that goes into the development process. Measuring any one of them, or even a combination of them, simply cannot begin to capture effectively everything that is involved. You can't pick a surrogate thing to measure, but because of human nature, developers will react in ways that will skew the measurement.

Many studies have been done on this topic, with little to show for it. Every software development manager who has to fill out a developer's evaluation or determine who gets bonuses has struggled with this. Many a leading expert and guru has thought about and researched this thorny topic.

Experts Agree

And not one of the experts has come up with a good idea or method to measure individual productivity. There are plenty of good and effective ideas on measuring team and project productivity, but there is a severe if not complete shortage of ways to measure individual performance and productivity.

For instance, Robert D. Austin wrote an entire book on this subject called Measuring and Managing Performance in Organizations and came to the conclusion that unless you can measure 100% of something -- that is, every aspect of it -- then there is no point in measuring at all. If you attempt to measure less than 100% of the things involved in a given activity, you will get what he refers to as "dysfunction", or what you and I might call gaming the system. And since software development is an incredibly complex and creative endeavor, it's virtually impossible to measure every aspect of it. Often it quite literally involves sitting and staring at a computer screen. How do you measure the productivity of that?

Here's Martin Fowler's conclusion in an article he entitles " CannotMeasureProductivity":

"This is somewhere I think we have to admit to our ignorance."

Neil McAllister of InfoWorld writes in an article entitled " The futility of developer productivity metrics"

"For most other companies, however, it might be best simply to forget about the idea of measuring developer productivity and rely instead on tried and true methods. That's right: A highly effective, productive developer workforce is often the result of high-quality, effective management. Unfortunately, nobody has developed a metric for that yet. Coincidence?"

Joel Spolsky writes:

"It's rather hard to measure programmer productivity; almost any metric you can come up with (lines of debugged code, function points, number of command-line arguments) is trivial to game, and it's very hard to get concrete data on large projects because it's very rare for two programmers to be told to do the same thing."

Steve McConnell, a widely regarded academic, author, and consultant says:

"So while I see the value of measuring individual performance in research settings, I think its difficult to find cases in which the effort is justified on real projects."

Like I said, it's hard to find a leading expert making the case for objective measurements, and easy to find plenty that say you shouldn't even try.

So I don't think that it's a tough leap to agree that there is no objective way to measure productivity in software developers. I know this is controversial, but it seems quite clear to me that software is more art than science, and measuring productivity in art is, well, simply not done. One does not tell Michelangelo that it took him too long to paint the Sistine Chapel because he should have been painting 1.4 square feet per day instead of 1.2. That would be preposterous.

So, What Are We to Do?

Anyone who is charged with managing and leading developers is left in a quandary. We want to be fair, but if everything is subjective, how can we be?

The fact that there is no objective measure of developer productivity doesn't mean you can't measure it. It just means that you have to measure it subjectively . And we do that, don't we. You can look around your shop and just know who the productive developers are. There are probably developers you know that simply crank out good code faster and fix bugs more efficiently than the rest. For ease of discussion, I'll give this developer the name "Jason".

And just how do you know Jason is more productive and more valuable? You just do. You can just tell. You know it when you see it. But if you stop and think about it, Jason has some characteristics that you can figure out and write down.

What I mean is that if you stop and examine Jason and his work, there are things that you can say about him that describe what he is all about. They are subjective, sure, but you can write them down and give an "objective" measure to these subjective things.

A Modest Proposal

So yeah, what I am proposing is a way to measure developer productivity and value via a subjective set of measurements. Think of it as a way to qualify the notion of "you just know that Jason is productive".

Here is the list:

  • Productivity
    • Does the developer get a reasonable amount of work done in a given period of time?
    • Is the developer's velocity on bug fixing sufficient?
  • Engagement
    • Is the developer dedicated to his/her craft?
    • Is the developer committed to delivering software on time?
    • Is the developer dedicated to company success?
  • Attention to Quality
    • To what degree does the developer's code work as designed?
    • Does the developer thoroughly test code and believe it to be correct before checking it in?
    • Do a minimal number of bugs get reported against his/her code?
    • Does the developer write unit tests for all new code?
    • Does the developer follow the Boy Scout Rule and leave a module cleaner than it was before he or she worked on it?
  • Code Base Knowledge and Management
    • To what degree does the developer understand the code base assigned to him/her?
    • Does the developer take responsibility for his/her team's code base, improving it at every opportunity?
  • Adherence to coding guidelines and techniques
    • Does developer's code routinely meet coding standards?
    • Do code reviews reveal a minimum of problems and discrepancies?
    • Does the developer use Dependency Injection to ensure decoupled code?
  • Learning and Skills
    • Is the developer constantly learning and improving his/her skills?
    • Does the developer show a passion for the craft of software development?
  • Personal Responsibility
    • Does the developer first assume that the error lies within his or her code?
    • Does the developer understand that he or she is solely responsible for their code working correctly?
    • Does the developer take pride in their code, ensuring it is clean, tested, easy to read, and easy to maintain?

Again, these seven items are all subjective measurements. All the questions require the evaluator to make subjective judgments. But a good lead/manager is presumably in their position because of their good judgment about such things, and so they should be able to make fair and accurate assessments about Jason's productivity using these "measurements".

Most of the questions ask for a yes or no answer, but all can spark a discussion with management or even the developer being evaluated. You could use these measures on a formal evaluation form. Whatever you do with them, it's probably better than the "just know it when I see it" approach you are probably taking now.

Conclusion

In the end, any evaluation, judgement, or other assessment of the productivity or value of a single developer will be subjective. No one has yet found an objective way to measure individual productivity in our excessively complex profession. But I am saying that it is possible to qualify and make judgments about a specific set of criteria as a small and humble step towards being able to do the thing that our industry has so far found very difficult.

My suggestion is that we accept reality and embrace the subjectivity -- and lack of objectivity -- in measuring developer performance.

How Not to Code #3: Compound ‘with’ Statements

By Nick at November 03, 2012 13:24
Filed Under: Delphi, How Not To Code, Software Development

Seriously, think about this:

  with (Sender as tStringGrid), Canvas do

I’m doing some string grid work, and ran across this code out on the web.  Wow.  It does what I want, but really?  It was code on a page with a date of like 1998, so at least we could say it was before many Delphi developers knew better. But still….. that is just awful. 

Here’s the truly hideous part – if I comment the line out,  the code still compiles!  Yikes!

Fun Code of the Week #6: Primality Checking

By Nick at October 27, 2012 18:02
Filed Under: Delphi, Fun Code

 

I decided to give KhanAcademy a spin, and watched this set of videos:

Level 1: Primality Test

And that let to me writing this code:

function IsPrime(const x: integer): Boolean;
var
  i: integer;
begin
  i := 2;
  repeat
    if X mod i = 0 then
    begin
      Result := False;
      Exit;
    end;
    Inc(i);
  until i > Sqrt(x);
  Result := True;
end;

I know that this can be optimized (which I'll do if I end up watching the next video :-) ), but I don't often write really geeky code like this, so I thought I'd post it so you all can write lots of comments like you always do when I post code. ;-)

UPDATE #1: There was a bug if you passed in a negative number. 

function IsPrime(const x: integer): Boolean;
var
  i: integer;
begin
  if (x <= 2) then
  begin
    Result := False;
    Exit;
  end;
  i := 3;
  repeat
    if X mod i = 0 then
    begin
      Result := False;
      Exit;
    end;
    Inc(i);
  until i > Sqrt(x);
  Result := True;
end;

UPDATE #2:  Took the Sqrt() call out of the loop.

function IsPrime(const x: integer): Boolean;
var
  i: integer;
  Wall: double;
begin
  if (x <= 2) then
  begin
    Result := False;
    Exit;
  end;
  i := 3;
  Wall := Sqrt(x);
  repeat
    if X mod i = 0 then
    begin
      Result := False;
      Exit;
    end;
    Inc(i);
  until i > Wall;
  Result := True;
end;

UPDATE #3:   The learning and optimizing continues!  I updated the code based on more suggestions, but the special case of 2 is irritating me.  I confess I thought a while (I’m not cheating by looking up implementations on Google…) and so I came up with something of a hack.  Also, just for Julian, all the x’s are lowercase now.  Smile with tongue out  Also, I learned/re-learned that 1 is not a prime either, by definition.  Interesting.  Any more optimizations out there?  Is there a “correct” way to handle 2?  The end goal here is to have a really nice, really efficient IsPrime function. 

function IsPrime(const x: integer): Boolean;
var
  i: integer;
  Wall: integer;
begin
  if x = 2 then
  begin
    Result := True;
    Exit;
  end;
  i := 3;
  Result := not ((x < i) or (x mod 2 = 0));
  if not Result then Exit;
  Wall := Trunc(Sqrt(x));
  repeat
    Result := not (X mod i = 0);
    if not Result then Exit;
    Inc(i, 2);
  until i > Wall;
  Result := True;
end;

Flotsam and Jetsam #68

By Nick at October 27, 2012 13:16
Filed Under: Flotsam and Jetsam, Delphi
  • Is it me, or does it seem like there are more Delphi conferences happening in Europe than there has been in the past?
  • I totally get the notion of being on hold to wait for customer service.  I usually put the call on speaker phone and wait that way.  They usually play music and go about my business.  What bugs me, though, is when they break in every ten seconds to say “All our representatives are currently assisting other customers.  Please continue to hold.”  That’s all well and good, but every time they do it, I have to sort of stop what I’m doing and see if it is recording or the real person coming on.  Irritating.
  • Apparently, my man Frank Borland has a blog
  • I was happy to find this interesting, insightful, and marvelously written answer by Danny Thorpe to the question “Why did Borland fail?”.
  • I’m feeling a bit out of it, as I just discovered and joined Quora – and gave my first answer.  I’d never really heard of it before, but found out that many of you folks are already there using it.  Now to think of a question to ask…..
  • I made a few more changes to the website – easily enabled by Less.  I put slightly rounded corners on the little side boxes, as well as a bit of a shadow.  Both are easily adjustable thanks to Less. 
  • I also added a new advertiser – Lake Quincy Media.  They specialize in Developer Tools, so hopefully what you see should be more of interest.

Fun Code of the Week #5

By Nick at October 24, 2012 21:39
Filed Under: Delphi, Fun Code

What is your FizzBuzz solution?  Any comments on mine?

If this is an interview question, what are you looking for?

Here is FizzBuzz in over 150 languages.

For the record, I spent no more than three minutes to write this. :-)

program FizzBuzz;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils;

var
  i: integer;
  WriteNumber: Boolean;

begin
  try
    for i := 1 to 100 do
    begin
      WriteNumber := True;
      if i mod 3 = 0  then
      begin
        Write('Fizz');
        WriteNumber := False;
      end;
      if i mod 5 = 0 then
      begin
        Write('Buzz');
        WriteNumber := False;
      end;
      if WriteNumber then
      begin
        Write(i);
      end;
      WriteLn;
    end;
    Readln;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

Less is More for your CSS

By Nick at October 24, 2012 19:34
Filed Under: Delphi, Software Development, Tech Stuff

As you may have noticed, I made a few changes to the website here at good ol’ nickhodges.com.  I added a column of boxes on the left, with the idea being to make stuff more accessible without so much scrolling.  And, well, yeah, okay, I’ve used that space to add a few more advertisements.

And while I was at it, I cleaned up a few things with the layout and the CSS.  It’s what I did with the CSS that I’d like to talk about today.

The main thing that I did was to start using the CSS pre-processor called Less.  Less allows you to do a lot of things “right” when writing CSS.  The first thing you notice when you start writing CSS is that it is a horrible violator of the DRY principle – Don’t Repeat Yourself – and Less solves a bunch of those problems.  It’s hard to write “clean CSS code”.  Less can help.  Less allows you to:

  • Create a *.less file that is then processed into your CSS file.  You can do this manually with a command line preprocessor, or you can do it on the client-side with Javascript.  Below, I’ll discuss how I pre-processed my *.less file automatically
  • Declare variables for colors and other things.  Say you have a color that you use in a number of different places.  You can declare

         @WidgetBorderColor: green;

    and then everywhere you had to type green, you could put @WidgetBorderColor instead.  Then, if you want to change from green to red, you only have to do it in one place.  That is really nice. 
  • You can also declare mixins – or chunks of CSS code that are commonly used.  For instance, if you have a bunch of places that use  

         {padding: 0px; margin: 0px}

    then you can declare

         .p0m0 {padding: 0px; margin: 0px}

    and use that as an “alias” in your *.less files

       body {
        .m0p0;
        font-family: Verdana;
        font-size: 13px;
        color: @Black;
        background: @White ;
       }

  • You can also use parameters to pass in to your mixins if you want, an other more complex constructs, though none of it is terribly difficult.   The Less page has all the documentation in one place.  The two features above were what I used in an effort not to repeat myself in my CSS.

Once you have your less file set up, you can process it via the command line, or using a GUI compiler tool.  Because Less is written in Javascript, you can use node.js to run it on your local machine.  To do that, you can download the Node Package Manager and then install  Less by simply executing

npm install less

npm is kind of interesting – it’s an online registry, so when you issue the above command, it goes out to a public registry and finds the Less package and simply installs it – there’s nothing for you to install. I guess it is much like Nuget in that regard. 

After that, you can then execute the lessc compiler. 

So the workflow at this point is:

    1. Write CSS and Less code in a *.less file
    2. Compile the *.less file into a *.css file.  (For instance, I use a batch file with:  c:\Code\node_modules\.bin\lessc C:\NickHodges\themes\nick\style.less c:\NickHodges\themes\nick\style.css
    3. Deploy the new CSS file with my site
    4. Repeat as necessary

Step 2 is kind of a bother, though.  You have to shell out to the command line to do the compile.  Who wants to do that if you don’t have to?

Well, I sure don’t.  So I found a cool tool called WinLess which does a nice thing – it automatically compiles your Less code into CSS every time you save your *.less file.

image

It works great – you just point it to your *.less files, and whenever you save changes, it automatically compiles the Less code down to CSS.  That way, your CSS is always up to date, and you just have to worry about your Less code.  Maintaining the CSS file is totally painless.  So now the workflow is:

  1. Update your *.less file as desired
  2. Save
  3. Deploy your *.css file.

That’s a lot easier, eh?

Now what I really want is a tool to find patterns in your CSS and automatically turn them into Less entries.  That would rock.

CSS is powerful and cool, and you can’t create a well-designed website without it.  But as a language, it’s not really very “best coding practices friendly”.  Less makes it much more so.  If you set things up correctly, you can do your styling in Less and forget about CSS altogether.

What do you guys do with your CSS?

Flotsam and Jetsam #67

By Nick at October 20, 2012 09:12
Filed Under: Flotsam and Jetsam, Delphi, Software Development
  • For those of you who still cling to the archaic notion that “Delphi Marketing Sucks”, you should know that I can’t go anywhere on the internet without seeing an add for RAD Studio XE3.  One of the things I appreciate about Google Adsense is that it knows the kinds of ads I want to see and what I am interested.  And it has very astutely determined that I like Delphi.  And Embarcadero marketing has very astutely provided ads to let me know that RAD Studio XE3 exists and that I can buy it.   That’s what marketing is all about.
  • How have I managed to miss this page of cool stuff all these years --  Delphi Inspiration? I’m particularly intrigued by the Delphi pre-processor.
  • Cool Thing Built With Delphi of the Week: dbConstructor
  • A bunch of you have ordered Delphi XE3 from me. I am very grateful. Thanks.  It's a great release -- I'm really enjoying using all the cool new language and RTL features, and I think you should too.

My Take on TypeScript

By Nick at October 17, 2012 21: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?

My Book

A Pithy Quote for You

"If we seek merely swollen, slothful ease and ignoble peace, if we shrink from the hard contests where men must win at the hazard of their lives and risk all that they hold dear, then bolder and stronger peoples will pass us by, and win for themselves the domination of the world."    –  Theodore Roosevelt

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.

Month List