v1.3.2
Liquid Documentation
Behind the scenes, Conductor leverages extensive use of Liquid Templates. Liquid by itself does very little without further customization in the form of Drops and Filters. Keeping track of these Drops and Filters can be an onerous task, not to mention the fact that they should be automatically tested. These tests are loosely of the form “Here is the input, now verify the output.” What I have done is harnessed these tests to automatically generate liquid documentation for all Filters and Drops. The documentation is intended for someone that is willing to get in and get dirty, it most definitely won’t win any pretty or “easily digestible” awards (though I must say, Erik did a great job of making the end result look clean).
The wonderful part of the documentation is that during our source control checkin if the system detects a change in a filter or drop, all of the liquid documentation is regenerated. Take a peak here.
Liquid error: private method `sub' called for nil:NilClass
This is for our designers and honestly it’s for me as well; you can ask that the item’s excerpt automatically include the “Read More” link. You can review the documentation here.
Page Caching
Pages have always been built on the fly and returned as needed. Now, once a page is built and served to the requester, the contents of the page are stored; From that point on Apache can retrieve and serve the page. This ultimately bypasses the Rails server and leads to quicker response times. It should be noted that if anything on the site changes, the entire site’s cache is destroyed. Likewise at the last stroke of midnight, the cache is also destroyed. This is a good thing. Besides, the cache will be restored as the page’s are accessed.
Other changes
We updated the News and Events controller to handle years before 1901. Instead of returning a 500 HTTP status error, they now return a 404 HTTP status.
In addition, we modified the global robots.txt to disallow /news/archives and /news/categories thus preventing a single story from indexing 3 or more times.
v1.3.3
I noticed that logging into Conductor appeared to take a bit of time. As it turns out, multiple connections were being created during one authentication attempt. This was removed, and will see an even better tweak in v1.3.7.
v1.3.4
Auto-Version Incrementation via Production Deploy
This one has me giddy. Now, when we deploy a change for Conductor, our system automatically tags our source control repository, and prompts for the new version number.
Other Changes, part 2
Updated the News and Events controller to handle years after 2039. Instead of returning a 500 HTTP status error, they now return a 404 HTTP status.
v1.3.5
Latest News and News feeds omit private category items
Now, if you categorize a news item in a non-public category, it will not show up in the news feed nor in the latest_news liquid drops. Note, if a news item has two categories, and one is public and the other not public, then the news item will be in the news feed.
Other Changes
To err is human, and I proved my humanity on this one. I was tweaking excerpts and introduced a bug into the wild. It was found rather quickly, and patched and deployed quickly as well. In addition, with the advent of caching in v1.3.2, we needed to make sure that when a template was changed that the cache was destroyed as well.
v1.3.6
Hot on the trail of v1.3.5 came v1.3.6; Version 1.3.6 added a database index to restore the rendering speed of each Conductor site’s news list (i.e. http://newsinfo.nd.edu/news). The slowness came was a result of altering the news listing to omit news articles that had one or more categories all of which were non-public. This is a case where my local environment did not have the same volume of data as the live environment; Thus the difference between an indexed table and non-indexed table was barely noticeable.
What this has helped me think about is a need for benchmark tests to see how scenario 1 compares against scenario 2. In this case how does the site respond with the changes from 1.3.4 to 1.3.5 to 1.3.6. With these benchmark scenarios, I would’ve been able see that something just wasn’t right with the changes in 1.3.5.
v1.not.really.conductor.but.related.to.it
Last week, Erik quietly upgraded the version of Ruby that Conductor uses. There are some performance improvements; Equally important the upgrade paves the way for further enhancements.
Going Forward
In the future, we will be adding a performance test suite so we can measure and see the impact of our changes. Already, as a result of a simple benchmark test, I can tell you that v1.3.7 will see a ~20% decrease in authentication time (that’s a good thing) versus the v1.3.6 authentication. The performance test suite will allow us to see the impact of caching news and events, which is also on the list. We are presently testing an upgrade to Conductor’s underlying Rails framework, so perhaps v1.3.7 or maybe a bit later. All of this is very exciting as look at how we can best serve those who’s Internet presence is powered by Conductor.
— Jeremy
