Just a quick note to let you all know that I'm still alive. =) They charge something like $50/hour for the Internet on the cruise ship, so I've been avoiding it needless to say! (I'm at a post office now where they let you play online for 30 minutes for free.)
Anyhow.... There's a lot of messages waiting for me, and you'll still have to wait a few more days before I an reply to them all. I haven't even looked at the message board. Yikes!
To make a long story short, I've 'thru-hiked' Bermuda. Adventures coming soon! (Assuming Wassa hasn't been telling you tall tales already, of course. *nodding* Trust nothing he says. *more nodding*)
Friday, June 27, 2008
Just a quick note to let you all know that I'm still alive. =) They charge something like $50/hour for the Internet on the cruise ship, so I've been avoiding it needless to say! (I'm at a post office now where they let you play online for 30 minutes for free.)
Thursday, June 19, 2008
This afternoon, I uploaded a new minor feature to Atlas Quest--notes. Not to get confused with tracker notes, though, which I'm actually thinking about getting rid of in the long run. AQ mail, message boards, box comments, tracker notes.... so many things to keep track of, eh? Well, now you can create what I call box notes. It's a little space where you can attach your own, personal note with a given box. It's for you to see, and only you. What you use it for is up to you. I image a lot of people will use it to record solutions for mystery boxes, or perhaps write directions to the park if they aren't included with the clue already, or maybe cut and paste a description of a tree or bush that's referred to in the clue that you aren't familiar with. Maybe you'll make notes on your own boxes, to remember what maintenance needs to be done with them. Doesn't really matter--it's essentially a private notebook attached to every letterbox listed on Atlas Quest.
When you view or print clues, any notes you've written for the box will be included. I figure if it was important enough to leave a note on a box, you probably want that note with you when it's time to find the box.
On a totally different matter, have you ever tried to Google your own name? I did, and not surprisingly, a page about me comes up. Not a shocking development, to be sure. On a lark, however, about a month ago, I set up a Google to notify me whenever my name is used in an article that shows up in Google News. I don't get much press with my name in it, but let's see what it turns up. And wow, am I one busy guy! =)
Keep in mind, I once did a directory search for "Ryan Carpenter" just to see how many listings show up. There are over 300 of us known to be running around this country--thus, the reason I have not been able to buy ryancarpenter.com as a domain name. Even at Intel, I shared a name with another Ryan Carpenter and we'd often get each other's e-mails when someone tried to contact one of us but didn't know which was the "right" Ryan Carpenter.
So while I don't get much press, some of my namesakes do. =) Apparently, I'm a baseball player--a pitcher, if I understand it correctly. And just today, I found out, I'm getting married to one Megan Smith on August 9th. (Sorry, Amanda--I had NO idea--trust me!) And wouldn't it be hilarious if she gets a Google Alert for anything that shows up with her name, and she ends up reading this blog post?
I kind of enjoy seeing what my name twins are up to, so I keep the Google Alerts coming. =)
Posted by Ryan at 7:00 PM
Sunday, June 15, 2008
For those of you night owls out there, you probably saw my "there's an update in progress" message plastered on Atlas Quest for the last 1 1/2 hours or so and are itching to find out what all has changed.
You can look long and hard for changes, but you won't come up with much. A handful of minor bug fixes. I tweaked some CSS stuff (if you had set the emotion buttons to be hidden from your own CSS page, you'll need to update that. Just set display to none for anything with the class name "emotions".)
The one tweak where you can see Prototype in action and the slick stuff it can do--those emotion buttons on the message boards. If you click on one of them, instead of doing a complete page refresh like AQ used to do, it now submits your vote "behind the scenes" and updates the page without a full-page reload. It's very slick, and very cool. (And the reason I tweaked some of the CSS code that was used to hide such buttons.)
I worked on that feature most of the day yesterday. Not much to look at, eh? =) I've spent the last several days working on getting Prototype integrated throughout AQ, and nearly a full day working on those silly little buttons so it didn't cause a full-page refresh.
I'm still learning Prototype and all of its amazing powers, so you'll likely notice other minor changes like those buttons in the near future. I have a number of ideas about how I can use Prototype to make existing features a little bit slicker, a little bit more convenient. It shouldn't require my taking down Atlas Quest for hours to upload such changes anymore now that the base has been laid down.
Prototype, I might add, does not support all browsers, so I'll try to be careful to make sure no essential features depend on it. The oldest browsers it'll worth with are: Firefox 2.0, IE 6, Safari 2.0, Opera 9.25--so if you're using something older than those, you'll probably want to upgrade for the full effect. I figure that's less than 1% of the people on AQ, however, perhaps significantly less.
I tested the changes on Firefox, IE 6 and 7, Safari, and Netscape and all worked well. I wasn't able to test with Opera since I was running version 9.0 on one machine and version 7.x on this machine. I'll need to download a more recent version to test with, but in theory, it should still work fine as long as you have at least version 9.25.
There weren't any notes about what versions of Netscape are supported, but it did work correctly in my fairly old version. *shrug* No promises with that browser, but newer versions definitely do seem to work. =)
Dial-up folks will likely notice that the first page they access on Atlas Quest may take a few seconds longer to download than before. That Prototype file is about 120K in size, but your browser should cache it and subsequent pages should continue loading as quickly as before. That first page, though, you'll definitely notice a slight decrease in download times. Most broadband folks probably will be hard pressed to notice an extra lag.
So that's what's going on. =) Sorry the site was down for as long as it was tonight--I ran into unexpected difficulties with my FTP client and had some trouble getting the changes uploaded. I'm not expecting this update to cause lots of stuff to break like the last update, but it is possible a few things broke along the way. Just let me know if you discover any and I'll fix it up as quickly as possible.
*yawn* Time for me to get some shut eye now. Happy trails!
Posted by Ryan at 12:42 AM
Friday, June 13, 2008
Most of you reading this probably don't know much about databases. You've probably heard the word before, but it's a method us computer programmers use to store large quantities of data in an organized manner that can be looked up quickly. Information about you is probably located in thousands of databases around the world. You can't do anything without it showing up in a database somewhere. I consider it one of the most essential pieces of software that runs Atlas Quest, second perhaps to the operating system itself.
The website is just a pretty interface into the murky depths of the database. Oh, yes, there are some pages that don't require the use of the database, such as the tutorials, but that's not the reason most people come back day after day. No, you keep coming back because of the message boards, letterbox clues, and AQ mail. All of those data-driven features are heavily dependent on the database. Without the database, Atlas Quest would be an empty shell--it's heart, the database, missing.
It's rather remarkable, but my appreciation for databases didn't really take root until after I got my first programming job at TrueLink when we used a relatively simple database for storing account information in our projects. That's when it first hit me that any worth-while application is going to require the use of a database. I studied for a computer science degree for four years and even took a database class, and at the end of the class, I was left wondering, "So why did I waste my time taking this class?"
Looking back, it's astounding to think I thought a database class was a waste of time. Frankly, the class was a waste of time if it couldn't answer such an important and easy question. Oh, if I was able to teach that class today, I'd make sure every student who finished that course knew that it would likely be the most important class of their entire college career--because it should be!
At TrueLink, I first learned how to use a database. Basically, I learned everything that I should have learned in my database class! The stuff I did with them was pretty simple, but it was a huge eye opener for me.
Later, I moved on to bigger and better things, and started working at Intel. Early on, I started working with some code that interacted with--of course, a database. It was also fairly simple as far as databases go, but I was absolutely stunned to find out that I knew more about them than anyone else in my group! Now I did not consider myself an expert on matters of the database, but I knew what a foreign key constraint was and that you could tell the database to enforce them. What's a foreign key constraint, you ask? Glad you asked. =)
First, you have to realize that a decent database keeps track of data in what are called tables. It segregates various types of data into distinct pieces, such as member data (trail name, e-mail address, password, etc.) or data about letterboxes (box name, type, attributes, etc.).
Computers find numbers easy to work with, so pretty much everything on Atlas Quest gets assigned a number. There was a recent discussion about member IDs on the message boards, which sometimes shows up at the end of a URL as gMemberId=x where x is the number assigned to the person in question. My ID number is 1. And there's a table in the database that keeps track of all the information related to a specific member, such as my trail name, password, e-mail address, etc. The ID numbers are convenient to work with, so I can tell the database, "Give me all the information you have about member #1," and it tells me all the information it has about me.
Even thought letterboxes have their own table in the database and members have another table in the database, there is a relationship between the two. (Thus, you might hear the term relational database.) Members create letterboxes, and Atlas Quest needs to keep track of who carved the stamp, authored the clue, planted the box, owns the box, listed the box, and who all needs to be contacted when the letterbox is recorded as found. So there's a lot of data in the letterbox table that points to individual members in the member table using their ID numbers.
Creating a foreign key constraint is a way of telling the database that if you create a link from one table to another--in this case, from the letterboxing table to the member table--it MUST be to a valid ID number. It makes no sense that a letterbox was listed by member number 1,343,233 because there is no member with that number. If I set up a foreign key constraint and try to tell the database to link to an invalid number, it'll reject the request and tell me I screwed up. =)
Anyhow, I was absolutely stunned when I found out that none of my co-workers knew what a foreign key constraint was. It's elementary stuff for working with databases. You should be flunked from Databases 101 if you don't know what a foreign key constraint is after the first week of class. It's that basic.
And I was absolutely stunned when I realized that I was the resident database expert in my group, because I didn't feel like an expert at all. My co-workers had created convoluted pieces of code that would first double-check that a certain ID number existed somewhere before using it in another table of the database (if they remembered), and code that they could run periodically to make sure the numbers didn't get into an inconsistent state. They wrote hundreds of lines of code that did this sort of thing, and by specifying a foreign key constraint--one line of text--on the database, the database would have done all that work for them faster and more reliably.
Fortunately, the database we worked with was a simple, straight-forward database with minimal amounts of information, and I had no trouble using my "expertise" to fix up some obvious problems and amazed everyone with my smarts and ingenuity, but I knew the truth--I was an expert only because nobody else knew anything about databases. =)
If anyone reading this is planning to get into the computer science industry, seriously, learn everything you can about databases. You WILL work with them, and you'll be absolutely invaluable if you know them inside and out.
Ironically, Atlas Quest does not use foreign key constraints. It bothers me a little, but it's because the site runs with MySQL 5.0 which does not support foreign key constraints. (At least not the with the table types I'm using.) They have a release candidate for MySQL 5.1 out already, and that new version should be released soon and I'm looking very forward to it since it will support foreign key constraints and I'm anxious to start using them. =) One of the checks AQ runs each night is to search the database for foreign key constraints that have been violated and to clean up the mess. Once foreign key constraints are supported at the database level, those checks will be a thing of the past.
But I digress....
When I first had the thought to create a city-centered search engine for letterboxes, I knew I'd have to learn a whole heck of a lot about databases that I didn't know. My original data source for locations included information on about three million locations. When I narrowed it down to just cities and towns, there were still over half a million locations listed--far larger than anything I had worked with before.
Additionally, the queries--a word that means to look up data from the database--would be far more complex. Usually I just searched using an ID number, and told the database to return all the data associated with it. "Give me everything about member #1." This is fast, quick, and easy, because those numbers are indexed, much like the pages of a phone book. It's not like I have to search through every member checking their numbers until I stumbled onto the right number. They're all in a specific order and therefore quick and easy for the database to find.
That kind of index does not work when you ask the database, "Give me all towns within 10 miles of Seattle, WA." But searching randomly through more than a half-million towns for all matches is incredibly slow.
I developed a couple of tricks to optimize the searches--precalculating some data, bounding the results, yadda, yadda, yadda--and eventually got something to work that was extremely fast, which is still the same code that's largely being used today. I've since added additional optimizations and tweaked various things, but the principles being used are largely unchanged.
And when I finally got that working, it was the first time in my life I really felt like I was an expert at databases. When AQ 1.0 finally hit the web, the starting size of the database was about 70 megs of data (almost all of it data about locations), and all the data used was sorted into 12 tables.
It was the largest database I'd ever worked with or designed, and using the longest most complicated queries I'd ever had to construct. In this particular case, the queries were created on the fly as well, to support all the different search options people may want to use.
The Atlas Quest of today now has over 100 tables. The new tracker system I implemented put it over the century mark, and there are now 102 tables keeping track of all the happenings on the website. The size of the database, of this this morning, is 836 megabytes--more than 10 times larger than when I first started the website, and it's still growing as an enormous clip.
I've had to learn additional ways to keep the database running fast. I'm still learning new tricks to use and traps to avoid. There's a way to check how a database will process a query which is often useful for determining why a particular query is running slow (or not), for instance, and I was having trouble late last year with some message board queries running unacceptably slow whenever someone looked at really old messages.
So I tested the queries to find out where the queries were going wrong, and tried a couple of variations of the queries to see if that would give better results, and I was left with the results that I could optimize a query to run get results fast if it's a newer post, or optimize it for older posts, but there didn't seem to be any query that could retrieve data fast regardless of whether the post was new or old. That was a problem.
Then it hit me. Why don't I send the query to the database to examine before I actually run it? I was checking these queries manually to estimate which queries were most efficient so I could put in the ONE that would run the best, but why not automate the process so I could basically give several queries to the database, then have it pick the version that would get the best results.
And presto--it worked wonderfully! That's what happens when you read any message on the message boards now--it'll actually run one of two different queries depending on which one will run the most efficiently. They should both return the same results, but each one does so in a slightly different manner.
It's a clever solution to a perplexing problem I had, and it was a rather thrilling idea to me since I've never heard of anyone else who's done this sort of thing. I'm not naive enough to think that I'm the first person to ever think of this, but I don't know of anyone else who's done it before. It's not something you'll learn in a Databases 101 course, or even an advanced database course. In all my reading about databases, I've never found a source to suggest such an intriguing solution.
I still consider myself an expert on databases, but admittedly, there are still facets about it that I don't know much about such as replication. (When the database becomes too big to fit on a single server, it needs to be distributed among several servers that work together. Even at 836 megabytes, the AQ database is still puny in the grand scheme of things, so it's on a single server. If I ever need to split it among more than one server, however, that's when replication comes into play.) And even newer versions of databases have new features and quirks I must learn. (Foreign key constraints are what I'm most looking forward to in this next version coming up, and I'll have to tweak the existing code to start relying on it.)
But wow, there are now more than 100 tables that make up the Atlas Quest database. I hope the next hundred go just as smoothly! =)
Posted by Ryan at 11:02 AM
Monday, June 09, 2008
I woke up, bright and early this morning, knowing I'd have a long day of fixing bugs on Atlas Quest. The first thing I did, before I even turned on the computer, was to pour myself a bowl of granola cereal, sprinkle some blueberries on it, drown them in milk, and eat. My brain, I knew, needed sustenance, and heaven forbid, it might be a long time before I could fix all the problems I knew would be awaiting me.
After breakfast, I turned on the computer to survey the damage. Immediately, a big, red button that said "View Errors" popped up. It's the first thing I see when I log into Atlas Quest and it has recorded errors. It's bright red, it's ugly, and it gets my attention. =) I did note dozens of new messages were posted to the main AQ message board and help boards--never a good sign. Only two new messages to the webmaster board--perhaps bug reports. Perhaps it was just Wassa heckling me. I couldn't be sure until I read that board, however. And I had about a dozen AQ mails in my inbox. But all that could wait. First thing's first--the errors Atlas Quest itself recorded.
I like to work on these errors first for a couple of reasons. One, when Atlas Quest can detect and record an error, it also records exactly what page someone was viewing at the time, who was viewing it, the precise error that was recorded, and when it happened. It's usually very quick and easy for me to diagnose and fix these errors with all that detailed information. And by the time I've gotten through them, usually it's fixed a good number of the error reports you humans have posted or e-mailed me with. =)
Then I started working my way through the main Atlas Quest board, looking into problems, fixing more bugs. There were a lot of questions as well, but I put most of those aside to reply to later--bugs first. Must fix things that are broken, then I'll get around to replying to people.
After getting through that message board, I hit the help board. Then I went through my AQ mail, then back to the message boards to check those two posts on the webmaster board (alas, just bug report and no heckling from wassa this time around), and finally to the postal and LTC boards since I figured with the substantial update to the trackers, there would be an unusually large amount of questions and problems reported there. I usually don't follow those boards.
And of course, once I made it through all those bug reports, I went through it all over again, since by the time I went through all that, Atlas Quest had recorded more bugs, more posts were made to the various boards, and additional AQ mails were sent to me. I had to go through several iterations.
It's now 7:00 in the afternoon--normally, I'd consider 7:00 evening, but it's still too light outside for me to think of it as anything about afternoon. I did take off about a half hour for lunch, and sure enough, by the time I got back on Atlas Quest, more bugs had been found and recorded.
Which is great--you people are awesome at finding bugs for me. =) Most companies will spend millions of dollars to pay people just to look for bugs in software. At Intel, we called them "quality assurance" or just QA for short. Interestingly, most developers didn't much like the QA department because--get this--they'd find bugs in the programs we would develop! Hello? That's their job!
I always got along well with the folks from QA, and I'll tell you why. I don't really like finding bugs. It's a tedious, boring process, and if some other schmuck from QA wanted to do that for me--by all means, I was happy to let them. =) It's like a game--I'd try to create code that they couldn't find problems with.
Of course, I always lost that game. Software is a tricky thing to develop and get right, and the folks in QA would always find problems. Sometimes, I'd find the strange bugs they did find rather impressive.
There's one instance in particular I remember. Our group had developed a Windows application, and you could bring up a "Save as...." dialog box in two different ways. The first was to use the menubar and pick "Save as...." from the drop down list. The second was by pressing Ctrl-A.
QA discovered that if you opened the dialog box in one manner, the title of the dialog box read "Save as...." while if you opened it the other way, the title of the dialog box read "Save as..." -- can you see the difference? One had four periods after the words, while the other only had three. It was strange behavior because they were supposed to be the exact same dialog box. Why were they showing up with different titles?
Now as far as bugs go, it was ridiculously unimportant. It was strange, however, and not expected, so QA went ahead and recorded it as a "cosmetic bug." And when I heard about the bug, I was astounded. How the heck did they FIND that?! Talk about attention to detail. I probably would have never noticed that problem in a hundred years. I was impressed with their powers of observation, and out of sheer curiosity, I wandered over to the guy who submitted the bug and asked him, "How'd you do it? How'd you find such a tiny, microscopic bug?"
His answer: Mostly just dumb luck. =) He was playing around with things, opening and closing windows, over and over again, and just happened to notice the discrepancy in the number of periods used. He wasn't even looking for anything in specific--just eyeballing stuff to make sure it looked right to him.
One of my immediate co-workers, who shall rename anonymous since he wrote this particular section of code, was furious. "Why are they wasting our time with such stupid little bugs?!"
It's true--the bug was not a deal breaker by any stretch of the imagination. It's unlikely any clients would ever notice such a thing. The way I saw it, however, was perhaps--just perhaps--it was a symptom of a much bigger problem we don't know about. The proverbial iceberg, and we're just seeing the part that's above water. I wanted to know why this was happening, although given its purely cosmetic nature, I wasn't going to expend a great deal of energy to solve the problem. I'd just take a quick look at the code for five minutes and if I didn't find the problem, I'd go on to more important issues.
I did find the problem--a strange line of code that read something to this effect:
if the dialog box was opened using the menubar
set the title to "Save As...."
set the title to "Save As..."
That's it. So I took out the if/else statement and set the title to a consistent value regardless of how the box was opened. I suspect the code somehow ended up in that bizarre state due to a bunch of copying and pasting--this particular person that developed the code was notorious for lots of copying and pasting--and probably wherever he copied it from there was a reason to set the title differently. I don't really know, and then in his quest just to get the code off his desk, changed the titles without actually reading the code and accidentally used an inconsistent number of periods.
So I fixed the problem, and felt a bit better knowing that it wasn't a symptom of a larger issue under the surface.
What's all this have to do with Atlas Quest? Nothing, really, but it's an interesting story, don't you think? =) Of all the bug reports I've gotten over the years, that's the one that amuses me the most because I can't imagine one person in a million would notice that sort of thing. But all the same, finding bugs is terribly boring.
And on Atlas Quest, this is essentially a one-man operation. I could have spent a month testing all the new code I created for these trackers, but you guys probably found more bugs in the first 12 hours after I uploaded it than I could do on my own in a month. That essentially makes you all my QA department, and you're amazing at what you do. If you're looking for a job, you might consider applying for a the QA department. (But note, most developers will generally hate the job you do. I'm still astounded how most developers seem to seriously dislike anyone associated with QA.)
And even better, I think a lot of you even LIKE trying to find bugs on Atlas Quest. =) It's like a game for you--who can be the first to identify a problem.
Yesterday, I told Amanda that I was planning on the big update late last night, and she was thrilled about being able to list a Nancy Drew LTC or something--I don't even know what she was planning. She was disappointed when she realized I wouldn't be uploading the changes until 11:00 at night since she would have to leave for work before then and wouldn't be around first thing to add her tracker.
"You don't want to list your tracker the first day," I told her, "because it's gonna break. Let others find all the bugs for you, then it'll be working smoothly by the time you get back." =)
She nodded, agreeing that it's probably best not to be first, but she seemed a bit disappointed that she couldn't put herself on the front lines, sort of speak.
But to make a long story short.... thank you all for all the amazing work you've done finding bugs. Some of you seem to apologize whenever you find a problem, perhaps afraid that you're being a bother, but I depend a great deal on your powers of observation and testing to help me find bugs, and I appreciate the help more than you can imagine. =)
So thank you, for every one of those bug reports, no matter how small or insignificant it may seem.
Posted by Ryan at 6:53 PM
Sunday, June 08, 2008
For those of you up late Sunday night, you might have noticed I took Atlas Quest down for a little over a half hour to upload some updates for the site. It's a major update, but not really.....
The main thing I updated were trackers, and for those of you who aren't into doing postals, LTCs, and other spinoffs from letterboxing--you can pretty much ignore it all. =) For those of those who ARE into them--you'll notice some pretty big changes. I gave trackers their own space under the 'Letterboxes' menubar option. Trackers aren't letterboxes, obviously. Heck, they aren't even actual objects. It's a conceptual thing to keep track of boxes and people and their relationships, but I couldn't think of a better place to put it. I had considered adding another menubar option specifically for trackers, but that seemed like overkill. At least for now.
But I digress.... if you go to the tracker page, you'll see at least two prominent columns. The first one will list any "active" trackers you're in. What's an active tracker? Glad you asked! =) You'll notice that for each tracker you participate in, you can set your status in the tracker to either active, waiting, or completed. Active means that you have something you need to do with the tracker. If it's an LTC, it might mean you need to create a bunch of cards and get them mailed off. If it's a postal, it might mean you need to create a postal or are in a ring and need to forward boxes on.
Waiting means just that--you still have a place to play in the tracker, but you're generally waiting on something that's out of your control. You might be waiting for the start date. You might be waiting for a single letterbox and are number 20 on the list to receive it. You have a long wait, and you don't want it cluttering up the search results. Then there's completed--you're done with your part in the tracker. This lets you get rid of such trackers from your search results without actually having to drop yourself from a tracker or wait for it to become retired.
The other major column on the main trackers page is a list of upcoming trackers that are open, have room, and about to start. If you want to get in and get started quickly, check out that list. Only available trackers are listed, and they are sorted in order based on their start dates.
Trackers now have their own special search page which lets you search based on availability (the tracker must be open, with open spots available, and hasn't started yet), as well as specify what type of tracker to return (all trackers, postal trackers, LTC trackers, other trackers, or boxing buddies), and your status in the tracker (active, waiting, completed, or all of the above). You should be able to get quite specific searches with these new search options. =)
The main focus has been postal trackers and LTC trackers since there's been a bit of a feud going on between the two sides. Trust me, I've heard the complaints. ;o)
I also added support for "other" trackers--which, naturally, support "other" boxes. I threw that in so the next time someone invents a new type of box and start listing them as others, then they'll also have access to a tracker that can track them. I don't know of any particular use for that type right now, but I'm sure it'll come in handy at some point.
Then there's support for boxing buddies. For a long time, I wondered about how to support those. Listing it as a type of box made no sense since it's not a box at all, but I loathed the idea of creating an account just so the boxing buddy can record finds. I rather suspect a lot of people would prefer these pseudo people not logging finds on their boxes (which includes myself, I might add). Then it hit me. It's a bunch of people (with buddy in tow) finding a bunch of boxes, and there needs to be some way to track such going ons. Hello? That's what trackers do! =) So, thus, boxing buddies are now officially supported in the form of trackers.
Now the interesting thing with these trackers, since each type is segregated in the code base, I can make tweaks to each of them based on their specific properties. For instance, postal boxes show that chart of people and boxes and who's recorded finds on what. That chart doesn't really make sense for other types of trackers, however, and therefore you won't find it with other tracker types. But! If you are in an LTC swap (for instance), you'll find a new "Record Finds" button that allows you to record the finds of all LTCs registered with the tracker. The boxing buddy tracker has a separate "add box" list.
And finally, trackers now support what I call "notes." I know a lot of Yahoo Groups were created for specific trackers just so people in that tracker had a place to swap information. It's kind of like a primitive message board for each tracker that only people in the tracker can post to. I'm not sure how the use of this particular feature will evolve, but it might be interesting to watch. =) The main tracker page will show the most recent notes posted to any of the trackers you're in, but nobody will see that at first since there are no notes and therefore no notes to show you.
There's a few other tweaks I've made to the trackers, but those are the major ones you should be aware of. I'll let you find the rest on your own time. =)
Next up..... Premium members will see a new link in the upper-right corner of the page whenever they do a search on traditional letterboxes. It says KML, and I'll bet most of you have no idea what that means. No to worry, neither do I. =) Well, I know what it means, but rather I don't know what it stands for off the top of my head. But that doesn't matter. What does matter is that it's the format that Google Earth uses to read in lots of interesting data. If you have Google Earth installed, click that KML link and open the resulting file with it. It'll plot the first hundred results of your search in the program. It's really pretty cool. =) It seems that Google Maps recently included an option to import KML files as well, but I haven't played with that use of it as of yet.
For those of you who box with friends, you can now hide the plants and finds of your friends' logbook in your own searches. Keep in mind, however, this will only work if your friend does not have their finds hidden from public view. (Their plants will still be hidden, since those are always public anyhow.) You can do this neat little trick from the Advanced Search page. Type in your friend's trail name and click the "Hide Plants & Finds" button and presto! A search returning boxes that neither of you have found or planted. (Assuming, of course, you haven't forgotten to check the boxes to hide your own plants and finds!)
And that, I think, pretty much covers the new stuff--or at least the major stuff worth noting. As always, an eagle eye will likely find spelling mistakes mysteriously fixed, the buttons on My Page now used text that's 90% of normal size, and other miscellaneous details, but they're generally things you don't need to worry about.
Posted by Ryan at 11:42 PM
Thursday, June 05, 2008
It seems that a number of people are confused about my explanation of the "default blue" theme. Several people e-mailed me to say they picked that theme so they can see the themes change whenever I change them.
When you create an account on Atlas Quest, the default theme is none. No specific theme is selected, and therefore you'll see whatever happens to be up on Atlas Quest. Over 11,000 accounts use this theme, which doesn't surprise me at all for two reasons: one, it's the default, and two, most people seem to enjoy seeing the changing themes.
It is possible, however, to explicitly choose the default blue theme, which will force Atlas Quest to always show you that theme, no matter what. If you select the default blue theme, that is all you will ever see. The theme will never change. That's the one that 131 people have selected.
I guess calling it default blue is confusing for people. I called it that since it's the normal theme when no specialized themes are being used. It was the first one I created, it had a bluish look to it, and it's the one Atlas Quest default to when there is no other appropriate theme to display, so I called it default blue. I imagined, back then, I'd someday create other major color variations. A default purple, perhaps, or a default yellow, but that never ended up happening. And now I have so many ideas for other themes I'd like to create, I can't imagine I'll ever get around to other generic default themes.
So, to reduce the confusion, I plan to change the name of default blue. The default in default blue is Atlas Quest's default theme. The default for most of YOU, however, is "no theme."
So I'm going to start calling the "no theme" theme as just simply "default" and the name for default blue will be.... (fill in the blank here!)
Posted by Ryan at 9:41 AM
Wednesday, June 04, 2008
Atlas Quest, as most of you reading this blog probably know, cycles through various themes. There's the main, default theme, with the road map across the banner at the top of each page. (Just in case you were wondering, that section is in Ohio, the southwestern section if I remember correctly, but the map I copied it from was actually paper from a craft store and it's not entirely accurate, which I'm assuming is for copyright reasons.)
The current theme is an underwater theme that I simply call "Ocean." I didn't have a holiday in mind when I created it, but based on the chatter from the message boards, it seems to be quite a popular one! Which is cool, because it's one of my favorite themes as well. I was just giddy about it when I finished.
Then I got to wondering.... what ARE the most popular themes on Atlas Quest? So I did a quick search of the Atlas Quest database and picked out some interesting numbers based on what members have set their preferences to.
And the winner is... the default blue theme, with 131 members selecting that as the theme to see.
Admittedly, those are probably votes for "I hate themes and stop showing them to me!" Which is fine--that's why you have the option after all. =)
A total of 59 different themes are being used by members on Atlas Quest, and here are the top ten most popular ones:
Old World: 92
Solar Eclipse: 59
Mother's Day: 36
Lunar Eclipse: 32
The thing that surprises me most about the ocean theme is that it's not even a choice on the theme preferences page (as of yet!) You all had to type in that link into the space for the CSS URL manually. I know a lot of you prefer the one-click buttons that most other themes have. I suspect once I get the Next Big Update done (with the ocean theme explicitly supported), even more people will pick it. And when the ocean theme runs its course and the next theme goes up, a lot of people will want the ocean theme to come back. I think those ocean counts are going to go up quite a bit within the next week or so.
The most popular non-AQ theme is http://www.geocities.com/pugnasties/SillyWalk.css -- not sure if it has an "official" name or not, though. Nine people are using that theme.
Just behind it, I noticed was the "no buttons" theme that hides the emotion buttons on the message boards. Eight people have chosen not to see buttons.
Also interesting, I think, I've found six people who chose to link to locations on Atlas Quest that are not valid CSS links. If you do that, you'll just see the default theme--not harm done--but it's odd that people would point their themes to boxes and other invalid locations. Perhaps I'll fix that for you folks someday, but I'm lazy so I probably won't. =)
Sorry, wassa, only two people kept your WassaQuest theme up, and I bet at least one of them is you. ;o)
Hope you enjoyed this backroom tour of themes. If you have a favorite theme, remember you can see them at any time by adjusting your preferences. Click on the Preferences link under the My Page menubar option, then choose Themes as the the page to update.
And if you're waiting for the ocean theme to be included in the official AQ list of themes--the Next Big Update, it will be there. *nodding*
Posted by Ryan at 5:57 PM