Archive for the ‘Web Programming’ Category

One too many Tiers

Wednesday, January 12th, 2011

Something has been nagging me lately about the three tier architecture–quite simply, it has too many tiers. If you subscribe to the full three tier architecture, you have an application that, at the end of the day, looks like this:

Yet, if you are using that architecture, you are almost certainly using it with an object oriented programming language–and if both things are true, there is a problem. It’s nature may not be immediately obvious, but it is there nonetheless: this flavor of the n-tier architecture defeats the entire point of object oriented programming.

To review, one of the upside of object orientation is that data and the operations performed on it are encapsulated into a single structure. When so-called business rules (operations, really) are split into ancillary classes (the BL classes), encapsulation is broken. In effect, we are using object oriented techniques to implement procedural programming with dumb C-style structs.

The true value in the multitiered architecture is actually far simpler than this birthday-cake methodology that has been faithfully copied into so many projects: keep presentation and logic separate. Any good methodology gets this much right (like MVC).

In conclusion, the remedy is simple: if you have or are building an application with a multitiered architecture, make your code base cleaner and more intuitive by merging the BO and BL layers.

ZenCart–how NOT to do Upgrades

Friday, November 26th, 2010

I am currently upgrading ZenCart. Why and where are not important. Suffice it to say, the more time I’ve spent with ZenCart, the more I realize that, open source or not, the project manages to do everything wrong.

It all started when I looked at the upgrade instructions. We were upgrading from version 1.3.8 to 1.3.9h. The essence of the instructions is to put a copy of your current install (with template modifications and all) in one directory, an unmodified version of your original install in another, and a fresh install of the new version in a third. Then, you do a diff of the installed version versus the unmodified version of the same version and manually copy your changes into the new directory. Finally, you run the automated database upgrade.

That is way to much work, especially when you consider the fact that those instructions are what you do for minor upgrades.

The process should be very simple. Backup the current setup, unpack the new files, and run the database upgrade script.

A large part of the reason this is the fact that Zen Cart also does templating wrong. Rather than stashing all of the files somewhere simple (/includes/templates/TEMPLATE, using their organization scheme), they are scattered across the entire install in the form of little overrides. Keeping track of the changes made to an install is unpleasant to begin with (source control helps, but it does not make it at all clear which files of the overly-many .php files are original and which are modifications).

When you also add the horrific security bugs that existed in the 1.3.8 line, you get an ecommerce system that I would definitely advise against using.

Regarding ORMs

Tuesday, August 10th, 2010

I cannot say that I have extensive experience with ORMs. After a recent bout or two with them, I found that there was something about them that nagged at me. Tonight, I realized what that something was. ORMs exist as a middle layer between an object oriented programming language and an entity-relational database. ORM advocates refer to what they do as solving the issue of “impedance mismatch”[1].

Herein lies the rub. ORM advocates are not solving the problem wrong, but they are solving the wrong problem altogether. They have, correctly, noted that an ER database is not an object store. However, they write the ORM as a large hack so that one can treat an ER database as an object store. They would do far better to write or use an object store–something actually designed to have a 1-1 correspondence between a “record” and an instance of a class.

There has been quite a stir lately with the rising of “NoSQL” solutions. These are, I think, little more than the old object-oriented databases coming back from the dead. While most are key-value stores and there fore not strictly speaking object-oriented, it is not hard to realize that most adapt themselves more readily to use as object stores. I think that this is where the future is heading for ORMs. In due time, the developers who today write and use ORMs will move their work over to document oriented NoSQL like databases, as these are faster (I would argue inherently, since you are not wasting time copying excess data back and forth and all about) and easier still than the ORM layer itself.

This leads to the obvious question: will a convergence of the NoSQL camp and ORMs result in the death of relational databases? I do not think so. ER databases are not bad because they are not object stores. They have their own advantages and I think they will be with us far into the future. The model has not survived forty years on account of having a poor foundation. ORMs, however, I think we can do without. Rather than solving an impedance mismatch, they are a crutch to use the wrong tool for the wrong job.

References

  1. http://www.agiledata.org/essays/impedanceMismatch.html

et tu, WordPress?

Tuesday, March 23rd, 2010

I’ve been playing with some code to handle WordPress exports (I’m planning to consolidate and retool this site–I don’t like the schizophrenic 2 sites within a site mentality that it has right now) and one thing is clear: WordPress has some issues. A nice platform, by and large, but the export, running the latest stable version, produces invalid XML. The database coalition is UTF-8 and there are characters in the dump that are valid UTF-8, but invalid XML. Moreover, the URLs are not properly escaped, so the anchors in URLs make the parser throw invalid charref errors.

Most of the offending posts are, of course, spam from before I got some good captcha software running (thanks, Zach). These are duly marked as such in the markup and would, of course, have been excluded from any of the later processing–except that I am having to spend time hacking around the broken markup just to get to that point.

Oh, well. Such is life.

More Thoughts on CMSes

Tuesday, March 2nd, 2010

I have written previously on some of the CMS that I have used. What I have yet to see in any of them, be it open source or closed, written in any language that you care to name, is the CMS that I want. This rant is my view of what a CMS should be.

All websites have a simple structure, whether we are talking about a chaotic mega-entity like Wikipedia, or a little personal home page. I should be able to lay out, in arbitrary depth, my website. Moreover, I should be able to do this in a declarative way. No hacking. Just, let me arrange my data. Websites will remain largely hierarchical (show me one that isn’t) just by the nature of things. Our file systems are hierarchical. You enter a website at a predefined point (though Google and bookmarking allow us to jump to more random places in the tree) and move on from there. This is not going to change any time soon.

Do not make me use a JavaScript WYSYWIG. I appreciate that they exist and I have used them. But I would rather compose my content as text files, thank you very much. Markdown, Asciidoc and company are far superior composition formats.

A website may fill any number of functions. Blog. Collection of pages. Wiki. These can change at a moment’s notice. I want to be able to compose these functions as I see fit. Drupal, Joomla, & friends are miserable in this regard. Their ecosystems have ecosystems. Rather than building small and beautiful, allowing the user to compose the results, we get tangled jungles within jungles.

Templating should be simple. I’ll lay it out, you fill it out. Most CMSes make far too much distinction between different kinds of blocks and content. I don’t want to care. At all.

All of this should be malleable at a moments notice.

A SOAP interface for handling that text-based content would be nice.

In short, it just shouldn’t be this convoluted.

jqGrid Frustrations

Thursday, February 18th, 2010

I just got a jqGrid (not my first, I might add) put together that took way too much time. While I am going to go back and add some features now, I was struggling to get the blasted thing to do the easiest task in the world: show some data. That’s it. No paging. No searching. Nothing fancy, just show the data.

  1. $(document).ready(function() {
  2.     $('#grid').jqGrid({
  3.         url: 'my_callback.php',
  4.         datatype: 'json',
  5.         colNames: ['col0', 'col1', 'col2', 'col3', 'col4', 'col5'],
  6.         colModel: [
  7.             {name: 'id', index: 'id', width: 50},
  8.             {name: 'foo', index: 'foo', width: 200},
  9.             {name: 'baz', index: 'baz', width: 100},                                        
  10.             {name: 'quuz', index: 'quuz', width: 150},                                            
  11.             {name: 'bar', index: 'bar', width:150},                                        
  12.             {name: 'schnoodle', index: 'schnoodle', width: 150}
  13.             ],
  14.         mtype: 'GET',
  15.         rowNum: 20,,
  16.         viewrecords: true,                                                                              
  17.         imgpath: '../javascript/themes/basic/images',                                                  
  18.         caption: 'My Caption',
  19.         });
  20. });

Where, of course, a few of those items have been anonymized. As vanilla a set up as you could ask for. I agonized over the JSON data, making sure it matched the default JSON reader (which, I might add, I used last time I used this component). Finally, trial, error, and Google prevailed. This is the code that worked:

  1. $(document).ready(function() {
  2.     $('#grid').jqGrid({
  3.         url: 'my_callback.php',
  4.         datatype: 'json',
  5.         dataType: 'json',
  6.         colNames: ['col0', 'col1', 'col2', 'col3', 'col4', 'col5'],
  7.         colModel: [
  8.             {name: 'id', index: 'id', width: 50},
  9.             {name: 'foo', index: 'foo', width: 200},
  10.             {name: 'baz', index: 'baz', width: 100},                                        
  11.             {name: 'quuz', index: 'quuz', width: 150},                                            
  12.             {name: 'bar', index: 'bar', width:150},                                        
  13.             {name: 'schnoodle', index: 'schnoodle', width: 150}
  14.             ],
  15.         mtype: 'GET',
  16.         rowNum: 20,,
  17.         viewrecords: true,                                                                              
  18.         imgpath: '../javascript/themes/basic/images',                                                  
  19.         caption: 'My Caption',
  20.         });
  21. });

See the difference? That’s right. There is a datatype entry and a dataType entry. Mind you, when I took either of these away, the grid broke in some way. Leave them both, it is fine. A quick grep of the code shows that, predictably, after this angst, parts of the code use datatype and other parts use dataType. JavaScript is case sensitive, so it matters. Now, the version of jqGrid in the code base is not the newest, but at v. 3.2.4 it should have been pretty stable. No doubt an upgrade would fix this (all right, after this I do have some doubt), but I am ticked. How could no one have noticed this after 3 versions? It’s not like I downloaded version 0.01. Or was running an SVN bleeding edge edition. It failed on an exceptionally simple example. jqGrid is a nice component, over all, but far, far too brittle.

PS – the link that put me on the right trail is here: http://stackoverflow.com/questions/259435/jqgrid-with-json-data-renders-table-as-empty.

Unixing away from phpMyAdmin

Tuesday, December 8th, 2009

Here at the ol’ job, we use MySQL (something that I have blogged about before) and, naturally, have phpMyAdmin installed. I seldom use it as I prefer a a nice, CLI interface. It does provide a few amenities that have log me in even when I don’t strictly speaking need it. Some of these are the editing feature (yes, I am lazy enough that sometimes I would rather not sit down and write out an UPDATE query), the printing (which is much nicer than out-of-the-box lp or lpr on *nix machines), and dumping stuff to CSV or Excel (which is nice for one-off reports that I occasionally have to run).

The last couple of days, while working on some reconciliation type reports that get a little involved, I decided to take advantage of the Unix philosophy (a tool for every job, do one thing and do it well, etc.) and make my life quicker and easier from the MySQL command line. So, here is a look at the various tweaks I’ve made.

The first thing to look at is paging. The client doesn’t do any out of the box. After jacking off with a handful of pagers (less, more, most, and w3m) I decided on w3m for reasons that will soon become fairly clear. To make mysql page, simply run the command:

pager w3m

or more, less, most, etc. Whatever command you want to be the pager. This setting can be made permanent

Next up, we have printing. This is why I chose w3m. less and most provided no way that I could see to pass the piped-in text off to a printer. If some pager coniusseur would care to correct me on this score, I am all ears.

Set:

keymap C-p SAVE_SCREEN “| a2ps -r test.txt -1 -r -f 7pts”
keymap q EXIT
keymap C-p SAVE_SCREEN "| a2ps -1 -r -f 7pts"
keymap q EXIT

The second item maps q to exit without confirmation. Out of the box, w3m always prompts. I hate being prompted. Remove at your liking. The first line maps the sequence Control + P to a SAVE_SCREEN command (which is used to dump pages to files) and then pipes it to a2ps. You can look up the options for a2ps, but the end result is that, since no output file was specified, a2ps prettifies the text handed it and sends it off to the printer.

Finally, we have that little problem of dumping to Excel. We do not have to dump straight to .xls or .xlsx format. CSV will do, despite being a poor format in general. MySQL can do this part natively by running a query like so:

select * from foo
into outfile 'someplace.csv'
fields terminated by ',' lines terminated by '\n';

This is nice, but, speaking for myself, I usually review the results before dumping them out, just to be sure it looks roughly the way I want or expect. Another good way to do this, is to simply put the query into a file and run it like this:

mysql -uuser database < query.sql

When in noninteractive mode, the mysql client outputs the records in a tab delimited format. Piping this through sed and into a text file will create a simplistic CSV or opening it in tab-delimited form with a spreadsheet app (like Excel or OpenOffice Calc) will allow it to be exported to a more friendly format.

What is the Point of this?

Sunday, November 8th, 2009

I recently stumbled across some articles on WS-BPEL. BPEL stands for Business Process Execution Language. At first this caught my attention because, well, it sounded like some potentially slick DSL that would help describe business rules and execute them. Slapped in front of a good domain-specific API, something like this could help slash development time. Of course, such things are usually little more than pipe dreams, but today’s pipe dream is tomorrow’s brave new world. So, it is always better to keep an eye on things.

Perhaps the first tip off that this had nothing new to offer is that BSPEL is based on XML. Seriously, how can much good come from XML? Even the few times where the end result is cool (like WSDL and SOAP), a better interchange format could have been chosen. Imagine, for example, a YAML or JSON based web services platform? With wider support that would just rock. But I digress.

Here is a tutorial of sports on WS-BPEL. When you get past the buzz words and the fancy terminology, you have an XML based scripting language to tie basic web services together. Pretty disappointing. After looking at the examples, I do not see any way that this wins out over using Java, C#, or PHP. It is quite a stretch to refer to what this thing does as having anything to do with “business processes”. Even an IBM reference on the subject just shows a few simple control mechanisms joined up with the ability to call web services.

So, if you have seen this used in the wild to an efficacy above and beyond typical programming or scripting languages, please drop me a line or a comment—because this looks like buzzword tag soup.

What Web Programming Gets Right

Tuesday, September 8th, 2009

There are a lot of things in the wonderful and wacky world of web programming that are simply wrong, browser specific hacks being the biggest by far. One thing it gets right compared to the majority of the desktop programming world is that setting up a GUI is declarative. Most .NET, Java, and C++ GUI libraries are procedural when it comes to setting up a UI. True, they usually use OOP techniques, but setting up a UI is a long string of statements that say, in effect, “create this widget, with properties X, Y, Z, A, C, and D and put it here”. There are some things in place to try and take the pain out, but this is what is happening. For example, if you look at the code that the .NET form editor creates, you find stuff just like this. Don’t even get me started on Java’s Swing framework. WPF is a move towards a declarative way to do GUIs as is Glade, but these make up a comparably small amount of GUI code in the wild. For the most part, GUIs are still done in a highly procedural way. Programmers who come solely from a Java/C++/C# background (hereafter, referred to as the “Java way”) accept this as more or less the way things must be done. This is because the Java way is only pseudo OOP in the first place and the meat of the work is done procedurally. The heavy lifting does not happen, ala Smalltalk, through signals propagating through a web of classes, but through a series of instructions in a method.

However, the functional tradition (which includes languages that are less hard core than Haskell) does not view the world this way. Instead, in functional languages you seek, as much as possible, to be declarative in your code. This brings me to the greatest irony of all: despite having the best facilities to represent user interfaces, functional languages have few libraries for GUI work and are seldom used for this purpose.

HTML has the right idea, and should show the way. <button type=”button” onclick=”foo();”> is exactly how all GUIs should work. Hopefully, in the future, we will see more tools that declare GUIs instead of construct them.

The Days of the Cybersquatter are Limited

Wednesday, August 26th, 2009

Run any number of searches for domain names and you will find most of the truly good ones taken. This is a minor irritant when a legitimate organization or person of some kind is using it. What is annoying are the boatloads of domains that have been claimed by some person or organization who does nothing but put a page of banner ads for them–then attempts to sell said domain for copious quantities of cash. In short, these entities, known as cybersquatters, claim any domain name that they think someone might possibly want in hopes of cashing in big. Over time, I have heard various ideas for dealing with cybersquatters, most of which involve some regulatory agency (usually ICANN) stepping in. The US has already put some laws into place to help combat this. Really, ICANN, the US, India, and whoever else may take an interest in this should just forget it. The market will work this out and it has already begun to.

The economics of cybersquatting rely on the given domain name being so important that some other person or entity feels they have no choice but to pay an exorbitant sum to acquire or reacquire the domain. This motivation is dying and with it will die the profits, real or imagined, that can be obtained through cybersquatting. For established businesses the motivation is, rightfully, a powerful one. People expect that if they go to ibm.com it will take them to the website of International Business Machines. It is simply too big a company to expect otherwise. Most of these establishments have already acquired the domains they wanted or needed. IBM will not likely lose a domain name any time soon. Even if there were once some large sums made, the big dogs are done playing this game. New businesses by and large cannot afford (or are unwilling to afford) the purchase of a squatted domain. Instead, the choice of business name is made alongside the search for a domain name. If a suitable domain cannot be had, people are moving towards choosing another name rather than pay what amounts to protection money. Squatters are, no doubt, are still attracted to this little get rich quick scheme  because money really has been made that way in the past. Those profits are dwindling and will continue to dwindle until only a few foolish people continue to attempt it. In that day, cybersquatting will be all but dead–without the help of any bumbling, meddling regulatory agency.