2009-09-27 16:21:31
The Game Search and Software Groups listing pages have also been made DS/PSP-friendly. Note that for purposes of these updates the links given use plain garaph.info, so if you follow them you'll need to add in the ds. or psp. subdomain yourself to see the differences.

Also, the Software Groups listing page overwent a slight makeover. Other than correcting a misplaced tag, it hadn't been touched since I started thsi site up. The change isn't exactly drastic, but since the software group descriptions are rarely actually used, I demoted them from having their own column to being small and italicized under the group name where applicable.

2009-09-27 13:14:45
Garaph is now more friendly for users of low resolution devices. Check out ds.garaph.info or psp.garaph.info to see versions slightly reshuffled to look nice on their web browsers. Not everything on the site has been changed, but since what has include the main page, individual software pages, group pages, and weekly overviews, it's not exactly lacking stuff to browse.

2009-09-25 14:51:19
More behind-the-scenes stuff to keep cached files from overstaying their welcome. I developed a weekly cleaning script. If I run it after the regular hardware/software info for a week is finalized, it will make a list of cached items that are: the weekly overview page, the individual software pages of games with new numbers this week, all the software group pages those games are associated with, every game line graph that seems to use those games or groups, and all the pie/bar/line graphs that directly reference the week. It then deletes them, so the next time someone accesses them they'll be sure to be generated with fresh data.

This solution does catch some false positives, and some that would include data from the new week but don't directly reference it by name will be missed and so will survive until the regular cache age limit. However, by taking out a vast majority of what should go and a small minority of what shouldn't, it seems like a pretty good working solution.

2009-09-22 13:59:13
So now software group and weekly overview pages use the cache.

Beyond this I'm not sure how far to bother. If it cached search results, how often would the same searches be done, that would make saving the results the first time worthwhile? There are some very generic types of things that might be referenced frequently, though it would help if I made a page linking to such things. Things like "All PS3 software by release date" or "All DS software in order of total sales" at least might get referenced a bit. A lot might not, but I guess as long as it doesn't harm anything and the obsolete files can easily be cleared away, there's not much reason not to go ahead.

2009-09-21 14:22:35
So everything should be pretty much back to normal.

I think all the important files are set up to handle double-slash URLs now, so the "forum friendly" format should work as it did before, even if things are a bit different behind the scenes.

Images cache, which I think should greatly alleviate what was I believe the biggest pressure. I considered some other things that would make individual images less a processor strain, but since I think caching should do the trick I only made one change: standardizing default line graph sizes to 500x300. Larger ones can still be made from the generators, but that's what you'll get if you don't specify a size, and what shows up on things like the individual software pages.

Speaking of the individual software pages, they're the first non-images to use caching. Viewing HTML tables tends to be less taxing than making an image of it, and they're not going to be called up as often since you can't just put them in the middle of a forum post, but it's still a good idea. If you look at the bottom of the page, it will tell you whether what you're looking at is newly generated and saved into the cache, or from what day/time the version you're looking at is from.

Caching usually works by defining an age the cached version has to be before it needs replaced, but with the nature of the data in Garaph that's not always a perfect solution. Most things need to be updated once a week at maximum, and sometimes only when the page format itself has changed because there's not been any new sales information about a game for the last seven years. For now I've set them to last eight days, and plan to manually wipe the files after inputting new software data so everything gets a chance to be generated anew when next someone visits. In the future I'll try to come up with something a bit nicer. If I run it after entering software data for the week of 2009-09-07, it will know it only needs to get rid of the old versions of pages for software who got updates the week of 2009-09-07. At that point the allowable cache time for anything that isn't automatically deleted could be greatly increased and you'd never see the difference.

Group pages and week pages are the next obvious targets--I've just run out of time for today.

2009-09-11 22:12:01
You may have noticed Garaph has recently run into a couple technical difficulties. Both hosting-related, though they can't shoulder all the blame.

First is that my account was using more RAM/CPU than a regular user should. While I've got other sites, they're pretty static--so I'm pretty sure it's Garaph's generated images to blame. To return from account suspended status I've temporarily turned off the images. I think caching can alleviate most or much of the problem, so I'll be toying with that and slowly switching things back. However, since I don't have direct access to data about what sort of resources I'm using it will be a bit hard to tell whether things are still going too far before getting suspended again.

The second problem is one of slashes. With a recent update in web server software, everything with multiple slashes started being treated as if it just had one slash... which is KIND of a problem for the "forum-friendly" style link this site has allowed for over a year. Excess slashes is usually the sort of thing people are trying to get rid of, though, and it didn't seem there was a very easy fix to get things back to the way they were. HOWEVER, I figured out a workaround that is in some ways even better.

It used to be that Garaph would detect URLs with double slashes, forward them to an interpreter, and that interpreter would forward you to the correct page with all the necessary ? and & and = and [] characters where you'd expect them. While that initial detection can't take place, it's still possible for the scripts of this page to tell what the actual URL typed/linked was, as opposed to just what file loaded. In this way the pages can still tell when double slashes have happened and do what's necessary--it just needs to be added to the top of the relevant pages.

How can it be even better, though? Well, it used to be that if you went to softwareindividual.php//gid/2038, for instance, you'd end up with the URL in your browser showing softwareindividual.php?gid=2038. Now that it can just read the data without any redirecting, there's no need for that URL to change, and things can be more consistent. While more complicated things (like the lines when they return) will probably still use something more like the old method, it's a step up for simpler ones. Right now individual software pages and weeks have the new method going on.