Yoink!

HTML cheat sheet link from the post window. Popup an ting.

Hype 1 has many users who are nobodies, they don’t post, they probably don’t read, they just don’t care [sob]. Anyway, Mat’s suggestion: a random bollocks password is created for each user and the account is validated when they login for the first time. Alterations include real user being created when the password is changed. Or: an url is sent out, with some random identifation value, when the url is hit it says “user setup complete!” and the process creates an entry in users. All that would really be validated by this process would be the email address, which is a bonus, that way any users who aren’t serious can still be contacted and proselytised to.

Community page wants some kind of grid layout (3 by x, 4 by x), with the playas organised by post count. Kill the graph but keep the numbers. The grid gives me the idea of ID cards, not quite to the point of having photos, but something a bit more useable and exciting than the current page.

Handy feature: when a user logs in put up a one-time message providing a link to the last post from a user, select by day or limit and write in an anchor for jumping.

Well, my new iBook is very sexy indeed. With all the grace and poise of Mac OS X I can’t help but smirk somewhat.

As the h_button script is run every time a button is generated for a page, it should be in charge of maintaining the cache of button images. It outputs the urls and so would need to know about cached versions anyway. The script could check for the existence of an up to date cache item and use it or create it. Cache items should be stored in folders with theme name and button file time. If the time on the file changes then the cache will be thrown away and a new folder created. The new buttons would be rendered into the cache folder as the different pages are accessed.

Additionally, Hype 2 has gotten a lot slower recently with all the extra work going into generating the front page. I suspect that this will be the trend for the coming additions. When all of the functionality documented so far has been completed, a testing and optimisation phase would give me a chance to improve what’s there within the structure of the 0.2 code. It will be difficult to optimise code that has been built as part of a development phase, but I think the only way to do it is to attack the whole system and then to find the slow parts of that with timing. If code is being changed to optimise then it will be changed to speed up the whole system. Speeding up invidual components seperately may lead into a speed decrease overall. Also, testing needs to ensure that the system doesn’t have any wierd infinite loops or long slow thinks in interesting conditions, fixing these kinds of things will need extensive code modification.