Magic Link Interview with Steve Blank

Steve Blank of S.G. Blank Consulting is no newcomer to eDeveloper™. His experience with, and advocacy of the platform, goes back more than 20 years to his introduction to Magic version 3.5 and it’s been his “tool of choice” ever since. But Steve is more than just a user; he’s an active contributor to the system’s capabilities. One example is the DDF Maker Wizard—a utility provided in eDeveloper V10—that lets developers enhance the eDeveloper studio by making their own utilities and wizards.

Magic Link: Tell us a little about your business.

Steve Blank: S.G. Blank Consulting only has one employee—me. I specialize in three different areas. First, I provide training for in-house developers on the latest aspects and features of Magic’s eDeveloper. Second, I speak at conferences and present seminars/classes on different aspects of eDeveloper. Third, I provide custom programming services to a handful of customers who, generally speaking, aren’t big enough to have their own in-house staffs, but who see the benefit of custom applications. It’s in this third area that I spend most of my time. I’ve been working with eDeveloper for about 20 years, since version 3.5, when it became my tool of choice, and I’ve been using it ever since.

ML: What types of training services are you called on to provide?

SB: Most of the companies for which I provide training are small to mid-size businesses with five or fewer developers. They are typically organizations that have developed their entire business system in Magic and, so, have a huge investment in it, and are looking for ways to improve performance or to solve other problems that have arisen as a result of their growth. So I’m usually not training people who are new to eDeveloper, but rather people in companies that have used the product for a long time and are looking for ways to make things better. The areas on which I tend to focus are multi-user concurrency, performance, database design, and data integrity.

ML: Do you typically provide training, then, for the same customers on a repeat basis?

SB: Yes. Often, I will get called in by a company that is experiencing a specific problem and, after helping them to resolve that problem, will then get called back to provide a wider scope of training. For example, a few years back, I received a call from a company in El Salvador that was experiencing increasingly serious locking and performance issues with their eDeveloper application. I went down and, after spending a couple days analyzing their application and database, showed them how to solve their problems and gave them some additional pointers on best practices. Each year since then, they’ve brought me back down for a week to train their development team on what’s new in eDeveloper, and to provide in-depth instruction on topics such as transaction processing and error recovery.

ML: You mentioned that you frequently speak at conferences. What types of things do you speak about?

SB: I tend to address many of the same topics that arise in my consulting and on which I often focus in my training, as well as to explore newer features in eDeveloper such as integrating ActiveX controls and COM objects. I really enjoy attending and presenting at conferences, for a couple of reasons: first, preparing for conferences gives me an excuse to experiment and create demo programs from which I learn something myself; and second, it’s a great way to network and to further my reputation in the business in a way that comes back to me. Plus, it’s just plain fun to meet and talk shop with people literally from all over the world.

ML: What are the kinds of issues that people have with eDeveloper that cause them to contact you?

SB: One of the strengths of eDeveloper is also one of its weaknesses: it’s really, really easy to write complex applications without a lot of formal training. Frankly, one can sit down and crank out some pretty amazing stuff without having any formal training in programming or database design because the tool abstracts the complexities to the point that the developer doesn’t really need to be aware of it. That’s one of its strengths because you can put applications together really quickly. But that also means that it’s very easy for bad habits to creep in. Take database design, for example. A Magic developer isn’t forced to be concerned about the table structures and such things that are underlying; one can just go in there and plunk things down. As a result, a lot of applications tend to have databases that aren’t at all normalized, which is OK when things are small with very few users. But as things grow and the database gets bigger and there are more concurrent users, problems can arise. That’s one example of when I might get called.

ML: What other types of issues do your clients have that you help with?

SB: A client might call up needing new reports or a change in functionality. One of the reasons I like eDeveloper so much is because it’s so much easier and faster to do not only new development, but also this kind of ongoing maintenance. One of the reasons to develop a custom application is so that one can constantly tweak it as one goes along, adding new features and functionality. With eDeveloper, that can happen a lot more quickly, which translates into lower cost (even when the customer is hiring someone like me to do it) than it can in something like Visual Basic. For example, my biggest customer in Massachusetts manufactures and distributes products for the optical industry. For lots of reasons, their software needs to evolve, practically constantly, and I make that happen. I develop a relationship with companies like that such that I’m really just an extension of their staff—almost an employee.

ML: There are some people who, like you, got started with Magic in the early days but then didn’t do much more with it. Why is that?

SB: First, Magic is a small company and suffers from a lack of brand awareness. Not enough people know Magic is out there, but it survives because of those of us who do know it are such zealous adopters that we just can’t see ourselves going anywhere else. More than that however, it often comes down to a political issue in favor of Microsoft. Whoever ever got fired for recommending Microsoft?

ML: Have you been able to observe companies like that?

SB: I knew one company that had developed its entire business system in eDeveloper and had run that way for 12 years, but then dropped it in favor of one of the major ERP vendors. They ended up shooting themselves in the foot. But once those decisions are made, people tend never to go back and revisit them or ask themselves if it turned out to be a good idea. They abandoned a significant investment in one system for another that ended up costing them many times more. But even though Magic has been around almost since the inception of the IBM PC and almost as long as Microsoft, people still ask, “Who’s Magic? Are they going to be around next year? Can we afford to take a chance with them, or should we go with Microsoft?” It’s a shame when a company turns its back on a significant legacy investment that was costing them much less money to maintain and, as a result, giving them a much better return on their investment.

ML: How can Magic go about showing those people what their prior investment in Magic could do for them now?

SB: I see a real opportunity now to speak to people who care about total cost of ownership. There are still people in this world who are willing to look at alternatives and to consider something different from the mainstream. Magic is doing a good job right now by releasing a product like eDeveloper Discovery, and by continuing to add new functionality.

ML: What advice do you have for Magic’s customers—old and new?

SB: Take a look at what Magic has done to improve the product over the years, such as addressing today’s increasing need to consume and serve web services, build and work with composite applications, and integrate with legacy applications and databases. If developers see how fast they can get the job done with eDeveloper and management sees how favorable the TCO is, they should agree that Magic is the answer.

A Little Magic History

I am constantly being asked about Magic's history, about the story of how the amazing technology that we know today evolved. Well, I can only tell you what I know.

Magic Software was founded in 1983 by Mashov Computers. Magic marketed application development tools and application deployment technology in the boom years of the personal computer craze (a boom that one could argue has not yet subsided). The programmers at Magic decided that if the computer was going to be perosnal and easy enough for everyone to use, that writing software was going to have to be a whole lot easier. While there had been some initial experimental attempts out of universities to create RAD -- rapid application development tools. None of them were all that useful because they tended to either be too complex or too restrictive and limited. So the developers at Magic set out to find a paradigm that would deliver full functionality and significantly reduce complexity.

SO there first and easiest decision was what not to do. They decided not to write a new computer programming "language." In fact they avoided traditional computer programming concepts and instead introduced a "table-driven" RAD tool. Today we know about concepts like pseudo-code, but they were really doing a lot of things we talk about in IT today: pseudo-code, services, mashups, etc. before anyone knew what to call them and really before they could be done as elegantly as Magic can do them today. SO they adopted an approach that required no compiling or linking. Because the pre-compiled sturctures could be employed and tested iteratively, the users of this new tool were able to prototype very quickly and start seeing results in minutes rather than weeks or months.

Te rest as they say is history, but let's remind ourselves of what that history includes: five years of victories at the Droege International development competiton, including the final year in which Magic's customers swept every prize at the contest, forcing the organizers to give up. Why continue holding programming competitions if the results are a given, Magic is the best and fastest tool. Ah, if only the market dynamics today were that simple.

Magic has had to try to preserve it ssimple table driven concept despite massive torrents of change in the underlying architecture of the computer. Not only has there been a major shift from text-based DOS environments to newer and arguably improved GUI operating systems, I don't know why I bother to use the plural, we all know I'm talking about Windows. But there was also a major shift from standalone PCs, to networked PCs on a LAN to PCs connected over the Internet -- the "cloud" as we sometimes like to call it. Magic also got a little ambitious too. The world of DOS and Windows in the 1990s was still not where most of the Fortune 2000 companies transacted their IT business. So Magic decided to expand the concept to include VMS, Unix, OS/400 and eventually Linux. The original dos version used Btrieve, these other environments used other databases and ISAM file systems. So the Magic development tool had to be given new "gateways" to deal with these new databases. Magic was able to sell these gateways as seperate products to their customers. Of course that transition to these other environments also meant a difference in architecture for the applications. The original desktop application approach was not a broad enough paradigm for these new distributed architecturess, so Magic's tool added client-server and Internet deployment methodologies. Known today as eDeveloper V10, Magic's development tools can deliver applications over the Internet in a browser-client mode or an HTML merge mode that is similar to PHP in the way it tags the HTML and merges in the results of its processing.

I'll probably have a lot more to say about this topic in the future, but I'd better get back to the topic of migration before anyone complains that I forgot to deliver my promised final chapter on moving your application to eDeveloper V10.

Converting to eDeveloper V10 (the Migration Story continues)

OK, you're probably thinking: I was a convert to the Magic way of developing a long time ago: why do I need to convert? But I'm talking about a more routine kind of conversion here, the conversion utility that automates the move from eDeveloper v9.4 to eDeveloper V10.
Needless to say, (oh don't worry, I know I say needless things all the time anyway), the Conversion Utility feature does not exist in the Discovery version. The discovery version is designed for beginners and beginners only. If you already have a big application, you're not a beginner.

Getting to Know the Conversion Utility

If you've gotten very far into this, you probably already know that eDeveloper V10 provides an Application Conversion utility for converting your eDeveloper V9 application into an eDeveloper V10 project. Please remember that this utility is designed only for full applications written in eDeveloper V9.4sp7 and onwards.So, if you have to do something to get your application to eDeveloper v9.4 sp7 (or later) first, then do that before attempting the conversion utility. Be warned.
As the documentation ably illustrates, you can launch the Application Conversion Utility from the Windows Start menu > (All) Programs > eDeveloper V10.1 > Migration > V9 Migration UI.
After you launch the application conversion utility, aka V9 Migration UI, you will see its Welcome screen. When you click the Next button, the Version 9.4 Applications Screen opens, and this is where the fun begins (OK, not really fun but I am trying to make this different from the documentation in tone and style, is it working?).

Version 9.4 Applications Screen

So you may be wondering, why do I have to add everything one by one? Well, the answer is simply that you may not feel the need to convert all your applications and components, so just choose the ones you truly want ti the new world of eDeveloper V10. (After all, why convert that cool BetaMax Catalog application? So when you convert an application, each application and its component must be added to the Version 9.4 Applications screen by clicking the Add button. If your application has references to a component that has already been converted, you should still add that component to the list at this point. That's right, do it again, you are telling the convert utility to make that component available to this application in the new world of eDeveloper V10. So just do it.
Each time you click the Add button of course, the Conversion Details screen opens and you have some disambiguation to do.

So This is How You Use the Conversion Details Screen

In addition to the how, I'll try to answer the why, without simply saying "because that's the way it is." Basically, the reason for the conversion details screen is for you to communicate your intent. Do you want to convert all of the application or just part of it? Do you want to convert a new component, or has it already been converted and you just want to reference it? These are the kinds of questions you are answering in this screen. So you simply select whether you are converting an application, part of an application, a component, or keeping the reference for a previously-converted component.
For each export file there are four possibilities (the order entered is not important):
Convert an application - The utility converts the entire application to V10 (but not its components, you are adding them separately, remember?).
Convert part of an application – Now it gets a little particular here, because this option cannot be combined with other conversion types in the same process. That doesn'tmean the very next add operation cannot use one of the other selections, it just means that in a single add operation, you are either choosing part of an application, or some combination of the other three options: convert an application, convert a component or keep a component reference. So, all the other options can be added one after another and all of them will be converted in the same conversion run or process. That is why, this option can only be selected if you have not yet selected one of the other options since starting this session of the utility.
You can continue with additional V9 export files using the Add button.

Convert a component - The utility converts the application to V10, and finds all of the references to the MCF or MFF in all of the Component repositories in the conversion list (the first screen). Then, the utility changes their references to the newly created ECF.
Keep reference for previously converted component - The utility points to the references of this component to the previously converted cabinet file. By doing this, we do not have to convert the same application twice. This is useful if we have a component with models, which is used in a number of different applications.
Depending on which option you select, you then fill in the application details and/or project details.
When you convert an application and its components, the utility will take the name of the component (entered in the Component File Name field) and change any reference to that file name in the Composite Resource Repository with the V10 cabinet file (in the V10 Project Name field).
The Cabinet file location field governs where the conversion process creates the cabinet file.

When you click the Next button, the General Settings screen opens.

Salute the General Settings Screen

The General Settings screen has the following settings:
V9.4 Magic.ini File – The Magic.ini file used in the V9.4 application.
Log file directory – A path for the log file directory.
Log Level – This setting has the following options:
• Full – Displays the full log.
• Partial – Displays errors and changes of behavior only.
Convert empty eDeveloper handlers – This property governs whether the Record Prefix, Record Suffix, Task Prefix, and Task Suffix will be converted if they are empty. In previous versions, these built-in handlers were created automatically even if they were empty. These empty handlers are irrelevant in V10. If you select this check box, the empty handlers will be included in the converted application. If this check box is not selected, the empty handlers will be removed.
"SpecialModalToolWindow" – In previous versions, the caption of Modal windows was narrow while in V10 it is a full sized caption. Select this check box if you want the Modal window height to be increased in order to fit the contents.

But as we shall see next, you can also go to directly to the conversion executable file.

Taking Command with the Command Line Conversion

eDeveloper V10 does not support the eDeveloper V9 export file structure, however it does provide a command line conversion utility called v9converter.exe that converts eDeveloper V9.4sp7 export files to a valid V10 application.
The v9converter.exe file is located in the eDeveloper V10 installation directory.
When the export file is executed with no parameters or when you enter /?,the Conversion utility help text will appear on the screen.
When you run the utility, the conversion results are displayed on the screen.
If the conversion process fails, you should verify that the command line syntax is valid and that the application is in a valid version 9 export file format. The utility will create the .edp file in the specified project directory and the project source files in the Source subdirectory.
The conversion log file will be created according to the -LOG parameter. If this parameter is not set, the log file will be created by its default name.

So remember, if you need to migrate only a partial application, you need to use the Command Line Conversion utility.

In the final entry on the migration process to eDeveloper V10, we will take a look at what the conversion utility parameters do, try to explain how application behaviors can be changed in the conversion process, and finally, recap some of the troubleshooting issues related to your conversion. Let's hope this whole approach demystifies a lot of this for those of you who have been wondering, what is really involved? As you can see, it takes about as long to explain it all in detail as it does to perform the actual migration. So much for the blah, blah, blah.