Code Generators are Not Evil

Recently I had someone ask me “I want to learn to make web sites. Tell, me honestly, if I buy your product, won’t it make me lazy?” I thought that was an interesting question. I combed the web and found several articles about how “real web coders” should not use code generators and that by using a code generator you will never develop the skills of a “real web developer”. I can appreciate some of the comments made in these blogs. But what strikes me as ironic is that these articles are reminiscent, of arguments made 30 years about the “evils” of high level programming languages such as COBOL and BASIC. I remember the arguments that if developers did not understand the assembly code generated, they were not really knowing what they were doing, and that some sort of evil end would come to the software developed by these “ignorant” coders using high level tools. Who could possibly create software when you were completely out of touch about what they were really doing at a binary level.

Well, I openly admit that using high level tools may produce code that is less efficient as hand coding every line, carefully scrutinizing every function and operation. But let’s step back and take a lesson from history of technology. First, things first… there was no “dooms day.” Programs written by “ignorant” programmers using high level programming languages, worked. What’s more, nobody codes in assembler any more, except in very niche applications. What is true is that high level programming languages empowered more people to produce more helpful software that has been successfully adopted by millions of users around the globe. How many programs do we use today were developed using assembler? “Very Few” is the answer.

History shows us that advancement in tools that help deliver the software that people want are not “evil.” Nor is it true that the people using these tools are “ignorant”. I would argue that the people using empowering tools may be “ignorant” about the technical details of what is happening under the covers, BUT they are actually “enlightened” individuals knowing more about the end product. Making technology more usable empowers people with knowledge about the final “solution” to become more involved in producing the solution. Moreover, people using these tools are able to focus more about the “what” the applications should do over the “how” to do it. The end result is better solutions, faster. There is no evil in this. And just because I don’t know how to repair my car, does not mean that I cannot use it to do some very productive things… like getting to work. Software tools are getting more advanced, and like our cars, we can use them to reach our “software destinations” without all being certified mechanics.

I personally grew up on code generators, in the 80’s “case tools” were all the rage. I leaned to design better systems, by worrying less about the “how to build” and more about the “what to build”. I learned that, as a project manager, I could get more productivity from my team, in less time and to higher quality standards by using automated coding tools. I learned that most of the programmers where happier to concentrate on the desired business goals of the project than on the correct syntax for a particular line of code. And to acknowledge the “dooms sayers” that, yes, you cannot escape the technology and that performance still needs to be considered. But that said, it less of an issue than they would like to make it to be. By producing the solution faster, and testing it earlier, you can identify the performance bottlenecks and call in the hard-core techies to “save us all” as needed. But what I found is that, in reality, the performance issues may only be relevant in 15% of an application. The other 85% can operate happily as is. Either there is no performance issue to begin with, or that this particular part of the system is used only by a few users, or that used so infrequently that it is not worth the investment to make it high performance.

Now I’ll share with you the answer I gave to the question “will it make me lazy”. My answer is “No, it will make you productive.” Why would we think it is “lazy” to not do things the hard way? To me, if you are achieving your goals, faster that’s hardly the definition of lazy. For a non-technical user to undertake the task of making a website is hardly lazy. For a professional web developer to not waste time hand coding pages that can be generated out-of-the-box is not lazy. To direct your energy in to value added features rather than debugging code is not lazy. Using the right tools for the job is “smart” not lazy.

If your objective is to learn to code, then a code generator is not going to prevent that from happening. Only you will prevent yourself from learning. Back to my car analogy, just because I can drive my car does not prevent me from learning to be a mechanic. In fact, true story, as a teen I learned all the basics of car mechanics from a small book and my old car. I spent a lot of time learning by doing, starting small, with fixing hoses to eventually rebuilding much of the engine and brake system. Having a car to tinker with did not impede my learning, it helped me learn. Likewise having a code generator to tinker with can actually be a learning aid. By enabling features, studying the code generated you can learn in an interactive, “by example” manner. In the same way that I worked my way “up” in my car mechanic skills; you can work your way up the technical learning curve as you have the need and inclination. But the great part is you can still have your working web site while you are learning.

With the introduction of dbQwikSite Developer Edition, I would say that using dbQwikSite code generator as a learning aid is even more practical than ever before. Developer Edition let’s you insert your own custom code into the generated code. So, you can “tinker” with your pages with ease. You can see how things are working in the code and add your own code to make your pages do more, adding features without having to be an expert. You can learn to code one-line-at-a-time while dbQwikSite fills in all the gaps. And, of course, if you are an expert in JavaScript or Server Side scripting you can make your generated pages do things only you can dream of.

To all the authors of all the blogs I read about “real programmers”, I offer the following counter points.
1) It is not every do-it-yourself web builder’s objective to become a coding guru
2) Understanding code is important but not more important than understanding the web site functionality that you are building.
3) If you bill or are paid by the hour, it would be professionally “negligent” to insist to hand code every single web page when there are tools available to enhance your productivity.
4) Coding is a means to an end, not an end into itself.
5) Don’t sweat it, “real programmers” are still needed, for all the “cool creative” stuff. Let the code generators do all the “boring repetitive” stuff.

Google Checkout++ new in dbQwikSite 5.2.3.0

Today we released dbQwikSite 5.2.3.0. This release concentrates on enhancing payment gateway support. There are two major payment gateway enhancement offered in this release. The first is the addition of support for Google Checkout and the second is the ability to add your own payment gateways to dbQwikSite.

Those who know Google Checkout, likely know that there are two flavors of checkout; a single charge checkout and a multi-item checkout. The good news is that dbQwikSite support both flavors. If you just want to bill the bottom line, then the single item checkout is what you want. If you want to have an itemized billing then the multi-item checkout is just the ticket.

When it comes to native payment gateway support, the list now includes: PayPal, Google Checkout, Authorize.net, World Pay, SecPay, and VCS. However that is only the beginning, now you can add your own payment gateway support to dbQwikSite. Under the covers, we have added a payment gateway plug-in architecture, which means that not only TheDevShop, but also you, can add new payment gateways without the need for programming. So, virtually any payment gateway can be supported by dbQwikSite.

Adding a new payment gateway involves defining XML and XSL files. There are basically 2 steps, define the user input needed during design this is done using an XML document, and define an XSL that transforms saved dbQwikSite model into a web script. To create payment gateways you likely need some proficiently in XML Style Sheets. The great part is that these gateway plug-ins not project specific, that means that they can be shared amongst users. There is no “compiling” or “updating” involved, just drop the XML/XSL in the right folder and “presto” a new payment gateway. If you do happen to delve into creating a payment gateway plug-in and want to share it, just send the files to support and we will add them to the plug-in download page. Other users, I am sure, will be most appreciative. Documentation on how to create payment gateway plug-ins can be found on the dbQwikSite download page http://www.dbqwiksite.com/download.html in the “Other Downloads” section.

On other news, many people are asking about Developer Edition. It is definitely still on the product road map. The release has been delayed as we decided to do some serious R & D into two areas: “proper” .net support and Web 2.0 support. As that effort winds down we turn our attention back to developer edition. We have just set up our first beta tester and we are starting to move forward on the development of Developer Edition. An later this year, you should see some great stuff as a result of our R & D being incorporated into the product.

2008 New Year Message from TheDevShop

2007 has come and gone, a good year all and all. We did a few interesting outsource projects and we managed to release major upgrades to all of the dbQwik Family products. dbQwikSite took second price in the national software industry awards. TheDevShop was named “Finalist” in Red Herring’s Asia’s Top 100 most promising privately help IT companies. We couldn’t have done it without our dedicated staff and our customers. As I bid farewell to 2007, I do so offering a “super-duper-mega-humongous” THANK YOU to employees of TheDevShop Ltd. and to our Customers who not only support us financially, but serve as a source of inspiration as well.

Now TheDevShop enters 2008, a bright new year with a bright new plans and dreams. What coming in 2008? Some may have noticed that TheDevShop planned releases of dbQwikSite for Q4 2007 did not materialize, and things got very quite in the marketing and communications. What happened is that we were given an opportunity to work on a large scale social networking, web 2.0, dot Net project. I saw a huge synergy in the project and the dbQwikSite product road map. So we put R&D on hold in exchange for some heavy duty hands on experience into the technologies that we want to incorporate into dbQwikSite and dbQwikEdit. While this resulted in the delay of dbQwikSite releases, it also means that we are well positioned now to incorporate all the knowledge gained in our latest project into the tool. The new result should be a new dbQwikSite in 2008 which will be a major leap forward into the world of web 2.0. dbQwikSite will be doing all the cool stuff in AJAX and .net producing Rich Internet Applications (RIAs) in the blink of an eye.

dbQwikEdit is also on the road map for some major changes in 2008, with stronger support for XML being our primary target. Look for a hybrid database / XML tool, marrying the two technologies. Expect to see XPath and XQuery support in 2008.

dbQwikReport is due for a reunion in 2008. dbQwikReport began as a spinoff of dbQwikSite to provide users with a simple way to create reports on web hosted databases using standard scripting technology. dbQwikReport has received a lot of interest from the community. There seems to be a real demand for a simple, light weight reporting solution for hosted databases. In 2008 we hope to migrate the reporting features of dbQwikReport back into the dbQwikSite framework. This should result in some major improvements in terms of user interface and flexibility.

2008 holds a lot of promise for our users, who will see the advent of the next generation of the dbQwik family of tools on your desktops. For us at TDS it is a very exciting and ambitious plan. We are committed to develop the best tools possible to support technology trends. And always in the spirit of “dbQwik” we will be packing high-tech knowhow into simple to use, affordable software.

Be sure to subscribe to this blog to be informed of the latest developments from TheDevShop.

dbQwikEdit SQL Tool Prices Slashed

dbQwikEdit, TheDevShop's multi-database data manager has just gotten cheaper with Pro version selling for only $39.95 USD. That's an incredible price, the competition can't even come close, neither in price or functionality. I did a quick survey on the Internet, most competing products are priced between $69 to $250 USD. That makes dbQwikEdit the best value in town.

For those who are not familiar with dbQwikEdit, it is an SQL tool and visual query builder. It works with most databases so you don't need to buy and learn a different took for every database you use. Like all the dbQwik family of tools, dbQwikEdit does not require that you have advanced programming and technical knowledge to use the tool productively. But if you happen to be a database SQL guru, the tool has no problems supporting the demands of power users.

You can find more information and a free trial edition on the web http://www.dbqwikedit.com/

dbQwikEdit 3.4.0.0 Adds Office 2007

Today we release dbQwikEdit 3.4.0.0. In this release, we add a few new features that some users have been looking for as well as the regular set of bug fixes to known issues.
The two highlights of this release is a reworked connection wizard and Office 2007 support.
Building ADO connection strings easier than ever using the new connection wizard. That said, sometimes easy just doesn’t go far enough. Our power users have been demanding more control over their connection strings. The new connection wizard opens the door to entering connection strings manually.

The other major update is the addition of Office 2007 support. What does “office 2007 support” mean? It means that dbQwikEdit can now work comfortably with MS Office new “x” file formats. When using MS Access you work with accdb office 2007 formats in addition to the classic mbd files. MS Excel xsl and xslx file types are both supported in this release of dbQwikEdit.

If you are not a MS Office user yet, there are still a slew of bug fixes that make upgrading worthwhile. We clean up some exceptions and fixed some irritating bugs. Some of these bugs include: inability to modify primary keys in some cases, adding fields sometimes missed the “not null” option, specifying lengths of MS Access text fields at times was missing and a few minor tweaks to the data grid.

Existing version 3 users can get the latest release by running live update from the help menu, new users or users of older version can get more information about available upgrades at www.dbQwikEdit.com