Caching Completed
At last. Caching has been carefully designed, developed and deployed and is properly running under a cron every 2 hours. I realized that while checking for already cached entries, it is not necessary to compare the data for altered ones as it doesn’t have any purpose (yet) on how we display the cached data. We do not yet have purposeful features that will alert of modified entries during the past week. So only new ones are added.
The ‘Latest Updated’ feature of the site is now running smoothly, except for some entry body text character encoding problems. I will be working on it every now and then to fix it and other tweakings, such as truncation should end with the end of a word not between one. The displayed times are in RFC 2822 formatted date in GMT.
2 Comments »
RSS feed for comments on this post. TrackBack URI
How many entries are cached, and how many are displayed? Also, how many words from each post is displayed? How did you you (and the team) come up with these?
Sorry I couldn’t disclose those information. So here it is. The number of entries cached is not displayed in the ‘Latest Updated’ page, but I will be updating it. The number of entries displayed is the number of entries cached.
The caching process truncates the content of each entry to 310 characters. I think we should change it to grab ‘n’ number of words instead of characters since it will be more elegant that way and it will fix the problem with truncating in the middle of an ending word.
How we came up with these? We thought them of as the basic requirements for a system like this. displaying the necessary information just to keep it up to date. A database that provides static information won’t be very useful unless it implements a dynamic feature that will render it’s usage valuable.
So here it is. The system is now feature complete. We can call this version 1.0 beta since there are (and will be) a couple of bugs every here and there.