I read a blog post at Three Rivers Institute that lead me to the following presentation.
The presentation is about startups and search engine optimization. How to drive visitors to your website.
Dharmesh discusses how to adapt your webpage to generate visitors, also promoting his hubspot seo grader.
Now this got me thinking of a project I’ve been working on. It’s a highly dynamic JavaScript based page, hosted on Google AppEngine. (currently not in a state I’d like to show it off since its still lacking the basic features).
The page is being designed with a few ideas in mind:
- All dynamic data i served to the page through REST
- All static pages are served with long expiration, most content is static
- The main page never reloads, instead JavaScript does AJAX to update the content
- The JavaScript is designed using SOLID design principles
- The JavaScript is tested
- Back and forwards buttons still work
- Marketing Content is served using Google Sites, to reduce bandwidth but especially to shorten roundtrips when working with Marketing material
Now the idea here is to give a similar feeling as to what GMail feels like. A common trend, in web application development I think. However, after watching the presentation the following thought occurred to me. The GMail application needs to be found by search-engines.
Google has a signup page with content that is searchable, but the main JavaScript client is not designed to be found by Search Engines.
I want my page to be found by search engines, and this means that there are a few of the basic Ideas behind the page that I need to reconsider. Especially the following:
- The main page never reloads, instead JavaScript does AJAX to update the content
- Meaning that the page looks “empty” to search engine crawlers since all content is loaded using JavaScript
- Marketing Content is served using Google Sites, to reduce bandwidth but especially to shorten roundtrips when working with Marketing material
- Right now this is implemented using IFrames, which probably cause trouble for search-engines (yeah yeah, I know frames suck especially IFrames… but there were some cross site issues I didn’t want to fix right now),
I need some of my content pages to be searchable, but not the AJAX-driven application in it self. So now I have to rethink some of my decisions which were made from a pure coding view-point, to adapt to marketing viewpoints (and search engine algorithms so its not all bad).
Today was the first day after my vacation, at work. Most of the time is spent on planning and discussions how we’re going to move forward with the product. But I did manage to get some code in place.
During the discussions we also figured out a way to deliver some value to our customers in a minor feature. The initial idea was to create an excel spreadsheet that could fetch the data needed from our REST service, to create a report. This isn’t what were doing.
Instead were allowing printing on some new entities in the domain, extending our printing feature to be able to produce the desired output. This was roughly one hours work for me, as the printing feature was built just for this type of extension. Along with a change-set I had I could also add the ability to print entities by right-clicking on the anywhere in the application.
Now the extension points working in a design is one thing. But the design of this particular feature caused quite a bit of commotion in the days it was implemented (It touched on breaking DRY, since the presentation models for printing were closely similar to the entities). So it’s comforting to see that the design is holding up even as the feature grows.
More and more sites are doing it. Keeping their state in the address bar of the browser, enabling AJAX driven dynamic html pages to use the back and forward buttons between javascript driven views. The most common website that uses this functionality, that I know of, is GMail. If you look at the address bar in GMail when in an message you can see that they added a bookmark hash (#) specifying which message to show. The updated address bar allows the application to keep state in the browser history.
I started working on a solution for this on my own, at the time I couldn’t find any JQuery plug-ins with the desired functionality. Now however there are several. In order to reduce the amount of specific code in my own application I tried out three.
JQuery History, JQuery hashchange and JQuery address .
JQuery address
After looking at JQuery address I can honestly say that it has the best fail-safe of the three I looked at. It uses full page post backs as a fallback. I haven’t been able to get it to work without reloading the entire page. So for that reason I cannot use the plug-in myself.
JQuery hashchange
This is my favourite. I has a nice and clean interface and does only what you tell it to do. However I couldn’t get it to work on Internet explorer 6. Which is also one of the reasons why I’m looking at the plug-ins to begin with.
JQuery History
JQuery history is actually the plug-in that led me to the others. I came in contact with another Mor.ph user who used it on his site. As far as I can tell from the usage of this it needs to interact with the link’s on the page in order to work properly. Catching the click events on the links. This is also a problem for me. I’d prefer just to update the bookmark hash.
Now while I couldn’t use any of these plug-ins I just wanted to give a shout out to people looking for them. They are there. A few things to think about, that I found out. Is that your page needs to be designed for this type of behaviour. If you use any of the plug-ins then your page will most likely be couple to that design. It’s also much easier to add this type of behaviour for the page in the beginning than appending it to already existing Ajax pages. These are my experiences with it.
I also lack a word for the technique of keeping your state in the address-bar.
We had a problem in RemoteX applications, not a big one, but an old structure that had to be refactored. Our open method only accepted URIs as arguments. This forced most of our commands that create new entities, to first save an empty new version of the entity to make it accessible by using a URI for it.
This in turn caused unnecessary round trips to the data access layer, but also caused problems with potentially empty data.
So this Wednesday this code died. In the old implementation; the general OpenView command accepted a URI. Now it can both take a URI but also an actual object.
To allow this I had to change the targeted end-point urls to activate a class instead of a delegate, as it was before. This has two great benefits.
- By using classes I open up for taking advantage of Castle for setting up the different code for opening. Previously all the setup was made in one big wiring class, resulting in excessive class coupling CA warnings on that class.
- Each class that opens an entity view conforms to SRP. It has one purpose, to open a view for a specific entity.
As I implemented the ViewOpener I noticed that all the delegates for opening entities had one thing in common. The first thing they did was to open the entity from the data storage.
By breaking out this behaviour into an abstract base class I could reduce the amount of code, simply by having the base class fetch the entity and then let the more specific view opener setup the UI.
This resulted in the structure illustrated below.
ViewOpener structure
So what are the insights of this refactoring?
Having delegates for a specified behaviour is a code smell. By having simple short classes with a single behaviour instead, we make code easier to refactor. Its easier to simply add another simple class to the Castle wire up, than it is to implement the same behaviour in a large complex class that handles all UI setup.
I had an idea today while working with a performance issue on the REST-service of RemoteX Applications.
In theory having a performance counter with the average execution time of SQL-queries over time. Will allow monitoring of system wide average cost for queries in the system.
That means that overtime its possible to track the changes of the execution times as they grow or shrink during normal production environment conditions. The cost for calculating the average could be relatively cheap to calculate compared to the round trip to the servers, and also the calculation could be threaded of to a different thread, so as not to disturb the worker thread that handles the request to the web server to begin with.
The idea is to examine the changes of the average query time over time, to see if performance of data access is changed between version upgrades, or hardware upgrades for that matter. There are some performance counters built into MSSql that can give data that is somewhat like this. However most of the require heavy load to see any performance upgrade or downgrade. This instead logs an average of the actual execution time for the application.
A benefit with this is that the performance is individual per application, but the actual code or counter could be reused between different applications.
