Acropolis { Website Management Software }

I read an interesting post yesterday on ReadWriteWeb which discusses a report compiled by Dan Zarrella on “Link Attraction Factors: Getting Dugg and Going Viral.” As we are working on our own viral campaign for Strollers Direct, and plan to work on making it to the first page of digg next week, I found it very interesting. Complete with charts and solid statistical data, this report talks about the various factors that contribute to the number of inbound links generated for stories that make it to Digg’s home page. Because, afterall, what good is fame if it only lasts 15 minutes?

The entire report can be found here but I thought it would be worthwhile to compile what I believe to be his ultimate conclusions, narrowed to the “Top 3″ (respectively) for each area of analysis.

Best Containers: Technology, World & Business, Science
Best Categories: Travel & Places, Programming, Arts & Culture
Best Days to Submit: Wednesday, Thursday, Tuesday
Best Days to Get On Home Page: Monday, Thursday, Wednesday
Best Key Words: “Top 10″,”Pics”,”iPhone”
Best Times to Submit: 5am, 6am, 3am
Best Times to Make it on Home Page: 7am, 9am, 11am

It seems then that the early bird diggs up the most worms. The one point I am scratching my head on the most though is what day of the week to submit on. Apparently Wednesday is the best, but if the goal is to be on the home page on Monday, how exactly does that work? And Sunday is apparently one of the worst days to submit.

Well probably I will go ahead and submit our story on Monday at 5am and hope for the best.

Travis and I worked until about 10pm last night completing our goals for AqueduX.  That was the end of an approximately 14 hour day for each of us.  This morning I woke up at 5:00am to put some finishing touches on our demo, only to find several bugs that had passed noticed.  I didn’t even have time to grab a cup of coffee until past 7:00, which is when Spencer came to pick me up for our drive to New Orleans.

I am certainly glad of one thing–the demo passed and we demonstrated all four of our objectives without a single bug raising its antennae.  Our four goals were as follows:

1. To be able to edit/update a row (row of an HTML table, corresponding to the row of a database table.)
2. To be able to edit/update an element of a SELECT list.
3. To be able to move items between two associated elements.
4. To be able to move between pages and execute a simple key term search.

I believe that our presentation was good, although I think it may have come across as overly complex or technical.  Part of this is due to the fact that we were up against the wire until the last moment, and I was still fixing bugs when I should have been filling out index cards.  But the other part of this is simply that the nature of our project is technical.

However we did manage to talk with a couple of folks afterwords who seem to have some interest in continuing to work with us on AqueduX as an open source project.

So, if you were present at the presentation, or if you read about it online, and are interested in working with us to further (or just want to know more!) please let us know.  Also, we are hoping to be able to post a screencast in the next couple of days.

This is just a quick update to let everyone know that you can now follow this blog, and our progress on Acropolis on Twitter.  Our Twitter user name is acropoliswms, so if your a Twitter bug, head on over to the site, and begin following us.

Last week’s breakthrough has quickly escalated, in our minds if not yet in reality, to a open-source project that may very well contribute to closing the gap between desktop and Web-based applications.  Drawing upon our love of historical allusion, we are naming the project Aquedux, which tentatively stands for Automagic QUEries Dynamically Using AJAX.  Aquedux is essentially a collection of CakePHP extensions and helpers, and a javascript library written in JQuery.  These components interact with one another through the use of symmetrical naming conventions, allowing us to easily build fully AJAX driven applications that “flow” naturally from one element to the next, and back again.  The first application we built using this design pattern is literally a delight to experience.  Sometimes I just sit there for fifteen minutes, updating, editing and deleting records and watching everything fade in and out like magic.  The best part is that the code required to tie it all together couldn’t be simpler, and adding new functionalities to the application often takes no more work than adding a link.

Travis, Spencer and I will be traveling to New Orleans next weekend for BarCamp, a “geek-out” for open source developers.  We hope to find others who will be interested in the work we have done so far, or at least get some feedback on how we might improve.  Regardless, it will be a great experience to brainstorm with other developers and possibly learn more about what other programmers in southern Louisiana are up to.

So stay posted as we plan to provide continuous updates about our experience at BarCampNOLA, February 16-17th.

The Roman Aqueducts were the arteries of the empire. The legions may have defended, conquered, and expanded, but any history buff will tell you that the aqueducts were the arteries of the empire that nourished and sustained its life.

The architecture of the aqueducts was simple, beautiful and powerful. Designed to be primarily subterranean, with some channels as long as 60 miles, the aqueducts were extremely efficient at what they did. Many of the ducts had a very precise gradient of 34 cm per km. At a length of 31 miles, an aqueduct’s height would only vary by 17m. These designs allowed the natural laws of physics to transport millions of gallons of water every day throughout the empire.

When being forced above ground, the ducts combined efficency with architectural beauty to provide some of the greatest wonders the world has ever seen, but with the fall of the empire, it would take civilizations over a millennium to achieve luxuries that were common to citizens of the empire.

So why am I talking about ancient architecture on a blog devoted to designing e-commerce software? Mainly because the cycle of software development is very similar to the cycle used in architecture and construction. Even software design patterns are based upon architectural pattern concepts. So …

Aaron and I are currently working on a library of jQuery functions that will be able to integrate seamlessly with cakePHP applications. Following strict naming conventions, and simple design patterns that we are establishing, we feel that our small library will continue to grow and allow anyone the ability to enhance and extend interface design that will be as functional and beautiful as the great Roman Aqueducts.

In essence, old world architecture patterns meet new world software development and the result will be rich internet applications that are beautiful, intuitive, and maintainable. So stay tuned, as we continue to update our progress on Acropolis and Aquadux, and if you have intrest in using Acropolis as your e-commerce platform, or helping us develop Aquadux as an open-source project, then get in touch with us!

David Hofstadter’s law of programming:

It always takes longer than you expect, even when you take into account Hofstadter’s law.

This was in one of the closing chapters of Dreaming in Code, which I just finished last night.  I read the quote over and over again, and just thought it was wonderful, because it describes exactly my dilemma with estimating how long it will take to complete virtually any programming project.

I come up with a number, and I know–from past experience–that it will certainly take longer than that.  So I double it, or maybe triple it.  And, wouldn’t you know it?  It still takes longer than that.

I only wish sometimes I could go back to the days when I didn’t know that things always take longer than I think, and they only took about twice the time I expected.

I have a confession to make.  A while back I wrote about some good progress Travis and I made on Acropolis.  Well, the truth is we weren’t working on Acropolis, exactly.  We were actually working on another project for a different client– however we have been building this other application with a mind towards the exact structure we expect Acropolis to have.

We haven’t been able to spend any real time on the new version of Acropolis itself, but everything we do now, we do it with Acropolis in mind.

Despite my objections, I have been forced to make modifications on the old version of Acropolis (considering it is in daily use over here) and even though I am writing in straight PHP5, my experience with CakePHP has influenced me greatly.  Before, whenever working on one “module” of software, I would generally start with one main script that would load whenever someone accessed the page.  Then I would throw in a javascript file that would contain all my JQuery controls.  And then I would have several small scripts that would be called by AJAX requests, updating this or that element of the page.  The problem always was twofold: 1) I would get lost in my structure (or lack thereof) and 2) I found I was constantly repeating myself.  I would write one element in HTML, and then repeat the same element in one of the smaller scripts, or even insert a duplicate into the DOM using javascript.  All this to give the “appearance” of seamlessness, but beneath the surface it was anything but.

This time my approach was different.  I was working on Product Options.  I started off by creating a separate file that contained my class, which was called “Option.”  The class began with a constructor function that checked the Querystring for default variables.  The class then contained several functions, such as “existing options”, “add,” “remove,” “edit,” which contained both the mySQL queries and the corresponding HTML for the functions.  In the first script then, product-0ptions.php, I included this file and then called the appropriate functions throughout the code.  Whereas before I would build a select list for the existing options, I simply called the function as so: $option->existing_options();

Whenever a change was made, the ajax request would call the very same file, except the parameters were passed in the querystring.  The most important of which was “action.”  So, to update my existing optiosn, after say, one was added or removed, I would call this url:

product-options-class.php?action=existing_options&product_ID=4&manufaturer_ID=7

The include file would then use an eval() statement to call the requested function and return the correct HTML.  In other words, the exact function that first generated the HTML was the same one used to generate the updated HTML once the change was made.  You can’t imagine how much easier this has made my life.

I know examples would be really helpful right now, but of course, due to Hofstadter’s law, I simply don’t have the time.

More to come!

I mentioned in a previous post that I have been reading a book called Dreaming in Code, which chronicles the attempt by a team of programmers and designers to hammer out a Personal Information Management software (PIM) that will compete with the big boys - namely Outlook/Exchange.  I am about 4/5ths completed with the book, but it is already clear to me the project doesn’t really pan out–not only because I had never heard of their software, Chandler, before I started reading this book, but also because I’ve already read about three years of it and it seems like they are still only making baby steps.

Now it has been seven years and there is still no version 1.0.  While one may point to various flaws in their design process, or the decision to build their application in a desktop, rather than web-based environement (understandable if you understand that the project began a couple of years before GMail came out) but one could also oversimplify the whole issue by saying they simply underestimated the project.  They did not meet their self-imposed deadline, and therefore did not stay within budget.

I think any programmer can relate to that.  I know I can, after spending all day yesterday trying to complete a project I figured only had about two hours left.  I was to implement a nifty one-page checkout on one of our client’s sites, Cajun Grocer, like I had done with Acropolis (as can be seen on Strollers Direct.)  Spencer and our client alike were convinced it was a “cut-and-paste” job.  After all, I had already done it on one platform, how hard could it possibly be to move it to another?

To anyone out there who is not a programmer, but manages programmers: There is no such thing as cut-and-paste.  Unless two systems are exactly identical, they should be presumed to be absolutely different.  I may be exaggerating slightly, but not as much as you think.  In some cases the apparent similarity of two systems can actually create more havoc than if they were nothing alike, because you would not enter the project with any (wrong) preconceived notions.  You would assume nothing, therefore you could understand clearly the task that lay ahead.

So basically  yesterday can be summed up as follows: It works, it breaks, it works, it breaks, it works, it breaks…

And I still don’t feel like we are anywhere near actually getting back to work on the refactoring of Acropolis.

Best of luck, OSAF!  May something come of your efforts yet.  May something come of all of our efforts.

Not much has been done on Acropolis the past couple of days and I am not sure much more will be done in the next few.  Clients have been eating up my time lately with one-page checkouts, image galleries, site transfers, proposals, and God-knows what else.  I began last week feeling determined to get these all out of the way, so that I can then address the final remaining issues on Strollers Direct, so that I can then fully immerse myself in building out Acropolis.  Right now however, it still feels a long way off.

So anyway, as I am continuing to have dreams about programming, I thought this comic was apropos.  Enjoy.

Yesterday, in extreme programming style, Travis and I worked as a team to lay out a lot of the structural framework of Acropolis. If the marriage of JQuery and CakePHP is our goal, we may not be at an official engagement yet, but the courtship has currently begun. A design pattern I had been working out in my head and sketching down on blank sheets of printer paper several 3 a.m.’s over the last few weeks has now begun to emerge in living form.

The goal is for the page to never have to reload. Why? Because that is how desktop applications work. It is what your average person is used to. It is what “real” software feels like. In order to facilitate this we have to create our own form of organization, our own pattern, so that we don’t confuse ourselves in a mess of “spaghetti-code,” where JQuery functions are intermittently and inconsistently interacting with server-side scripting. I have been down that road a few times by now, and after a certain point, if you don’t have a solid organizational scheme to keep everything in its place, you begin to repeat yourself. This means more code to maintain, more to remember, and more that has to be changed whenever you add a new feature. This is no good. Now Cake takes care of a lot of this, and if you’re content to work with the prototype libraries it comes “out of the box” with, then you’re good. But if you’re like me and you just can’t tear yourself away from the vast potentialities available in JQuery, you have to forge your own path.

(Incidently, the two CakePHP JQuery “helpers” out there don’t seem to really fit the bill. One just helps you with your naming conventions, and the other is, well, not quite as “helpful” as JQuery tends to be on its own.)

But the standard naming conventions and organization of CakePHP just begs to be taken advantage of. It is so hard to write about this in the abstract, so let me just try to hit on a few key points. Hopefully I can elaborate upon these points as we go.

Partial Layouts + AJAX = Never Having to Repeat Yourself.

Small sections of your code that may need to be updated on-the-fly can be stored in “elements.” For our products module, then, we created a “row” element. When we list our products in a table, one product per row, we make use of this row element to format the data in the view. Each row in the HTML (<tr>) is connected to the actual “row” in the database by giving the HTML row an id parameter that corresponds with the Product.id. Whenever the information in that row (database) changes, the row (HTML) is updated via JQuery by calling a function in the controller that calls the same element (row.ctp) used to generate the row in the first place. (I feel like I could have said that in 1/4 the number of words but oh well.)

Predictable naming schemes mean one JQuery function can serve many functions.  Kind of like a crossing guard for code.

We constructed our own pattern for “actions” that can be used across modules (e.g. Products, Cateogories, Orders, etc.). We again made use of parameters inherent in HTML. For example, we use a link to fire the action to edit a product row. The code looks something like this:

<a href=”/products/edit/1″ class=”action” id=”Product/products/edit/1″>test</a>

What this basically means is that, first off, if your user is not using javascript the link will work normally, taking the user to /products/edit/1 where he/she can edit product with an id of 1.

If your user’s browser does use javascript, however, then JQuery takes over and things get very exciting. JQuery, upon document load, binds a click event to all elements with a class of “action.” When an action is clicked, JQuery takes the id of the clicked element and splits it up by ‘/’ and loads it into an array data[]. At this point it has all the information it needs.

var modelName = data[0];
var controllerName = data[1];
var actionName = data[2];
var actionId = data[3];

Now we are able to build an AJAX request to pull up a form and place it in a lightbox or whatever. In our case we chose to simply hide the table and then, after save, get rid of the form and re-display the table. Before we do that, however, we are able to update the row that has changed, which is easy, because we have the id of the row to be changed, and row.ctp is easily accessible in our elements directory. All we really need is a small function in the controller that delivers up the HTML of the one row based upon the supplied id.

I am sure it is difficult to picture, so I hope we will soon be able to post a link to a demo. But the result is a very fluid, and lightning-fast user experience that feels much more like “real” software than most people are used to experiencing in a browser. But what makes me excited is how squeaky clean and extensible this structure is. We have a few kinks to work out but once thats done our work will mostly involve customizing forms and the layout.

More to come soon…

I just have to keep telling myself that.

Programming, as life, has its ups and downs.  Today was most certainly filled with more downs than ups.  I am used to programs I write breaking for no reason, even though they were working fine yesterday.  I am used to neverending swarms of bugs.  I am used to poring over a problem for a straight hour only to realize I just spelled something wrong.  But I can generally take all this in stride because at least I never question my own competence.  Well, today–or more accurately, tonight, that confidence I usually take for granted has been slipping from me.

We are building Acropolis on CakePHP, as I have probably mentioned.  Now, although I have been using PHP for almost two years now, Cake is quite a bit different.  And it is even more different from PHP4, which is what I have mostly used, than PHP5, which I have only recently begun to tinker with.  The difference is between procedural verses object oriented programming (remember Alan Kay from my previous post) and perhaps one day I’ll feel like trying to explain the differences between the two approaches, but for now, take my word for it: the differences are huge.

Well, so I stayed a bit later at work today to try and hammer out one of the issues Travis was having trouble with.  Namely, we want to be able to list a table of information–say, products.  We want to be able to click on a product and get a dialog box, or “light box,” with fields for the product we want to edit.  We then want to be able to save the form, and then instantly update the information in the row we just updated, without the page ever reloading.

I know how to do this, alright?  I just haven’t done it in CakePHP before and I don’t want to just plow through it.  I want to work carefully within the beautiful structure Cake provides.  I don’t want to do it the way I have done before, which is to write out the table, and then when the update is made, execute a tiny script via AJAX that outputs the HTML for that row, and then do a replace.  Because the fact that the code for the row’s rendering would then be in two places, rather than one, just means more to keep up with and more hassle when I want to make changes.  And its just not elegant.

Well, I went to the #cakePHP chatroom for help, and I knew this was a big mistake.  Because as far as I can tell, there is a minimum level of competence you are required to have unless you expect to be ridiculed.  Of course I knew this, but I thought I was competent enough to ask a question like this.  But, I was wrong.  I am not sure if anyone ever really understood my question, since the only real answer I got was “Javascript.”  I was also told quite a lot of other things I already knew, and then your usual RTFM.  Well, ok.  I guess the truth is that I should have gone to the manual first, but I still don’t understand why the atmosphere in those chatrooms tends to be so hostile.  We are all at different places, alright?  And I still have to recall that one of the friendliest responses I ever got in the #jquery IRC channel, which I used to frequent on a daily basis, was on my first day using the library and the assistance was offered by none other than John Resig himself (the guy who invented JQuery.)  So I think that just goes to show you that a sign of greatness is not giving in to the urge to make others feel smaller.

I made some progress on this task, but I’m still pretty stumped right now and I know I’m just not in the right frame of mind just now.  Give me first thing in the morning and a cup of coffee and I’ll probably have it all worked out in less than half an hour.

Gone to get a beer…