So there I was, looking at some other websites out there (because I think my site design sucks. Thanks, me). One of the things that virtually no blogs do is promote specific content. In other words, highlight content that is most popular over a certain time frame. So I was thinking to myself, how would I do that? One option would be to have a database table that could record each click. That, however, is boring and requires changes to my DB schema (evil!). What I want to do is take my most popular pages of the last week and highlight them at the top of the web site.

Working with an off-the-shelf shopping cart usually requires a little bit of patience. Scaling an e-commerce site does have its share of problems. There is a LOT of interactivity that needs to be implemented. This can be things along the lines of generating targeted ads, sending email or charging a credit card.

One of the problems with doing asynchronous execution is that it can be actually quite difficult to test those asynchronous jobs. In this video I describe how to implement a testable queuing system.

With the web being what it is today there can be a lot of times when you want to aggregate data from many different sources and bring them together in a single page. I have not done much of that on my site simply because that means that I then need to learn a bunch of different API's. However, since Youtube is the #2 search engine I figured that it might not be a bad idea to aggregate some of my YouTube content on my page automatically. I don't necessarily want to do a blog post about each individual video I post, but I wanted there to be some place where I could just list them out.

In our previous installment we looked at setting our backend up so it could automatically retrieve the bit.ly URL for a given URL and store it as part of the data for a given instance of a Content model. What we're going to do this time is take a look at the front end components.

Sometimes I find that doing things backwards can actually make things a little more clear. That way you can see the end result and then, as you work backwards, see how all the pieces work together.

Well another week, another set of changes. There are 4 primary changes that I've made to the site since last week. They are, in no particular order

Email subscriptions The addition of comments. A Twitter-based rating widget Related links

Related Links

Over here there is a good article on sharing page feedback on Twitter. I'll end up doing something similar but in a different manner. A little while I posted an article (Do you queue?) on how you could use the Zend Server Job Queue to run individual tasks. Well you can do the same thing here. I've made a few changes since that article, namely that Zend_Application is passed in both to execute() and to run() so I could easily retrieve application settings. Don't know why I didn't think of that earlier. Oh well.

There has been a lot of talk over the past several years about the difference between performance and scalability. Never mind that the difference between the two will probably not really affect most developers. Never mind that the "difference between performance and scalability" argument is often used when someone's code performs poorly and their best argument is "Yeah, but my code scales". Yeah, sure it does.