August 7, 2010
There is a pretty new feature on Wikia that’s a lot of fun: Achievements. I’m going to turn them on now since I keep seeing them on the test wikis and being jealous that I can’t play too ;).
Basically, if you do certain things you get badges – edit a certain number of times, upload images, there is even a track of Achievements for how many days in a row you edit. Achievements show up on your user-page and there’s a Leaderboard to see what other cool badges other LyricWikians are earning. It’s fun! 🙂 However, if for some reason you don’t like them, you can go to your Preferences page (‘Misc’ tab) and turn them off for yourself.
Achievements have the ability to have the icons and names customized per-wiki, so we’ll probably get on that pretty soon to make them more LyricWiki-ish.
Hope you enjoy the Achievements!
September 25, 2008
So far, LyricWiki has been running pretty well with the new server (our 5th server, named “Cochise“) set up with the rest of them. I’ve moved the API completely to that server which takes a good deal of the stress off of the site itself.
The site has been pretty fast since the new server has been up. However, there have been occasional slow-patches, and looking at the CPU usage on the main webserver for the site – it’s definitely still not “calm”.
So here’s a fun surprise: today I ordered another server! 😀
For the first time in a looong time, we can hopefully stay ahead of demand instead of suffering for a couple of weeks until it’s unbearable and we’re forced to upgrade.
W00t! This is an uplifting blogpost… lots of surprises! Anyway: the second surprise is that starting in October, I’m going to be decreasing the time I spend at my day-job by 40% so I’ll only be in the office 3 days per week. That’ll give me two whole days more each week where I can work on Motive Force products like LyricWiki. This should help things become much more stable very quickly.
Well, that was an abnormally enjoyable post for this blog – which usually just announces outages! The site still isn’t totally upgraded (because the weekend ended before I could make all of the extensions work), so I have to run back to that. I took snapshots of a bunch of performance stats before and after, so I’ll post those sometime soon.
Thanks for your patience during those past few weeks. Hopefully we’re in a whole new era for the site!
July 27, 2008
Finally you can have your watchlist stream you content when the pages you are interested in have been updated!
Thanks to a new extension by Teknomunk, you can now enable the rss feed at http://lyricwiki.org/Special:WatchlistFeed.
Since this is a really great feature to have in any wiki, Teknomunk plans to make this extension public so that all MediaWikis can use this feature (it is very commonly requested). Thanks Teknomunk! 🙂
March 30, 2008
I’m proud to announce a long-overdue feature: implied redirects.
Implied redirects make it so that the site can often understand what you’re looking for even if it is misspelled or we don’t have a redirect page for the specific song. For example, we have a redirect from the band name “Of A Revolution” to their preferred form “O.A.R.“. However, if someone comes to the site, we do not have a redirect from “Of A Revolution:Crazy Game Of Poker” to the correct page: “O.A.R.:Crazy Game Of Poker“. With the new implied-redirects extension, the site will automatically figure out what you meant and display the correct page. To see it in action, go to “Of A Revolution:Crazy Game Of Poker“.
Implied redirects have been active in the API for quite some time, but didn’t work on the site until tonight.
March 29, 2008
LyricWiki is now in Wikipedia’s inter-wiki map.
To decrypt that for most users: now if you want to create a link from a wikipedia page to a LyricWiki page, all you have to do is enter [[lyricwiki:Page Name]] on the page and it will make the link for you.
Here is an example of what you could put in the wikipedia page for the band Tool which would link to the lyrics on LyricWiki:
Pretty easy, huh? The “Tool lyrics” part is just the text that you want to have show up as the link. When you think a wikipedia article would benefit from linking to a LyricWiki page, feel free to throw one of those inter-wiki links in there.
January 7, 2007
At the board meeting today, we decided on a February 26th launch date for Pedlr.
I can’t get much more into what Pedlr is (yet), but as it relates to LyricWiki, it is a site which will contain LyricWiki and add on a TON of other features (which won’t interfere with the LyricWiki part). The best part is that since it will have a decent business-model, it will be able to pull the server-expense of LyricWiki which takes a lot of bandwidth/space/cpu-power to handle its traffic.
Earlier I mentioned that I would be making some improvements to the SOAP webservice. I thought I should take a minute to recap what was done today (developers may be interested?).
- Speed – Ignored the common format (artsist=””, song=”Track ##”) automatically before checking the database.
- Accuracy – Added an additional test so that songs with trailing parentheses get checked for versions without the parentheses. For example, if you did a getSong for (“Disturbed”, “Want (Remix)”), since there is no remix, the webservice would figure out that you actually wanted Want by Disturbed.
- Accuracy – Re-enabled the artist-redirect trick (which was too slow the old way). For example if you did getSong(“Prodigy”, “Action Radar”), the ws detects that there is no page by that name, however “Prodigy” redirects to “The Prodigy” and there IS a page for getSong(“The Prodigy”, “Action Radar”).
- Speed -Replaced the MediaWiki code to check if an article exists. That code was written for a different purpose (using an article Title several times on a single page), so it does a whole bunch of extra initialization that wasn’t needed. I just wrote a simple query to replace it and added caching of that single-byte result so that checks for the same title (during the same page load) have no additional database-query overhead.
- Speed – In the list of most common failed SOAP requests, I added 2-hour caching of the results so that users can go to the page as frequently as needed without running that fairly expensive query each time.
- Speed – Took out the double-logging of SOAP requests. For statistics, hits to the server are logged. Hits to the SOAP are logged. Now the hits to the SOAP are not added to the main statistics (which was resulting in double the amount of queries).
The only improvement I would have liked to have made, but decided against was the automatic removal of commonly failed requests after the first time they are successfully found. This was a great suggestion by admin Teknomunk, but I couldn’t figure out a way to do it without slowing down the whole system by issuing an extra query every time there was a successful SOAP request (which is currently about 40% of the SOAP requests). This extra query would be unneeded in the vast majority of cases (only helps for the first time a previous-failure is requested successfully). On the flipside, this is fairly needed so that the site can be self-sufficient (right now it requires me to manually remove entries from the table when I see they’ve been fixed… and a site shouldn’t ever be held up waiting for a single person), so I’m still thinking of a way that it could be done efficiently.