The rules for hacking the terminals are:

• You get 4 tries, after which you can never try again
• If you exit before the 4 tries are up, your available tries reset to 4, but so does the puzzle
• For each word you pick, you will be told how many matching letters you got
• That count is how many matching letters there are in the SAME position of the correct word

Originally, I was going to write it in Python. That way I could potentially execute it from anywhere I could install the Python interpreter and it would give me a reason to dive in to Python. Then I decided I wanted it done quick, and in an even more portable way; as a raw HTML page. So, I decided to write my version in Javascript, and here it is!

I used the one over at mediumexposure.com as a benchmark and honed mine down a bit (I didn’t catch that last rule when I was playing the game, which is why I could never figure the puzzles out). I will admit, mine isn’t as smart as his since it doesn’t take past guesses and matches into account, only the most recent guess and the remaining list of possible words. So, there’s a chance mine won’t guess correctly in the 4 attempts, but in the handful of tests I ran, I always managed to get it.

Now, I know what you might be thinking. “Hey, this is just another online file, how is this portable? How can I run it from my machine?!” Simple, save the html file to your computer and open it locally. All of the magic happens in the Javascript code (which I commented so you can follow along), which will run from your machine without the need for any extrernal processing or server. Go ahead, give it a spin and be sure let me know what you think in the comments. It’s a work in progress, so when I make it smarter, I’ll update the file and post again. Enjoy!

About a year ago, Aaron tipped me off to the magic of Javascript toolkits, specifically Dojo. For a while, I was a proponent of it, opting to use it exclusively to drive an internal application that I had written from the ground up at work. It’s an extremely powerful toolkit which has been steadily adding more functionality as it ages to that point that it’s arguably the most powerful toolkit on the market. Unfortunately, I’ve also found it to be one of the most poorly documented toolkits available as well, which I’m sure was due in part to my lackluster understanding of some of the more advanced Javascript concepts. Still, looking at some of the more advanced Dojo examples I’ve seen from Aaron and other sources online, most of the syntax escapes me completely, even as I continue to learn more and more about Javascript.

At the time I started using it, I was working with version 0.4.1, and as anyone with some Dojo experience can attest, it’s a far cry from where the 0.9 and and later branches ended up. I’ve since upgraded to 0.4.3, but porting everything over to the 1.0 branch would have taken about as much time as moving over to a completely different library. The 0.9+ branches also officially did not support Safari 2, which was a huge problem considering we’re an all-Mac shop. It also meant that production-side adaptation was pretty much out of the question as it’s a safe assumption that the majority of people using any software are drastically behind on their updates, if they ever even choose to perform them. For a company that makes most of its money by sales through the website, we just can’t afford to exclude and entire sector of people like that.

With all that in mind, I decided I’d poke around and see what else was out there as a possible Dojo replacement. A couple months ago, Aaron tipped me off to MooTools, which seemed like a nice mix of Prototype and the Scriptaculous animation library that was built on top of it. I had passed it on to my boss as something to check out but it was kind of left at that, though I did plan to learn it on my own time.

About a month after that, we hired a new designer at work, mostly so my boss could focus more on PHP and MySQL code and not just the design of both the site and various ads (which had become a full-time job). During his first week there, the new guy happened to stumble across the MooTools library on his own and suggested that we use some of the animations in the library to spruce up the site a little, though he knew absolutely nothing about Javascript. Of course, being the resident Javascript guru in the office, I was asked to look into what it would take to make it work.

I had spent a little time the previous week sifting through the APIs and docs of various other toolkits and libraries to try and narrow them down into a proper replacement for my aging Dojo code. I had actually planned to start making use of the Ext toolkit since it was a good compromise for Dojo; the code and feature set were very similar and their API and documentation was much easier to follow than that of Dojo. But, it wasn’t enough for me to consider introducing yet another Javascript library into the code base, and it made no guarantee about working with Safari 2.

Of the two other programmers in the office, one had been using jQuery for about as long as I had been using Dojo while the other had just started to implement MooTools into another piece of software he had written from the ground up. Since those two were already in out code base, they scored extra points and earned my attention over some of the other libraries.

Since MooTools was called for in the case of this particular animation, I spent a little time reading through the API and the Mootorial and picking apart some of the demos available on the MooTools site. To my surprise, it started to make sense very quickly; their API is extremely well put together (with a few fringe exceptions), I found the code and syntax very easy to comprehend, and best of all, I managed to get the animation working in only a few hours having never worked with the library in the past.

I then proceeded to port all of my Dojo code to MooTools, and in about two days time I was done. I even added some snappy fading and scrolling animations to the system with gave it a really nice polish. It all loads significantly faster to boot! I took another day and a half and added some drag-and-drop functionality that I had been planning since very early on in the project, something I still don’t even know how to approach with Dojo but made quick work of with MooTools, even adding heavy modifications to meet my specific needs. I’ve also learned a ton more about Javascript, written my own MooTools menu class from scratch (mostly as a learning experience) and rolled out some cool new things to our production website. I’ve drunk the milk and now I’m hooked. I can’t imagine ever working with raw Javascript again to be honest.

But, MooTools isn’t for everyone. It’s meant to be more of a core library that you extend and use to build your applications quickly. It also has one very significant downside; like Prototype, it extends the base Javascript prototype, meaning it could break existing code you have. It’s probably rare that it would (I haven’t run into it personally), but it’s a consideration. It also doesn’t play well with other libraries and toolkits as a result.

The point of this long-winded post is simply that I have become a huge MooTools fan, and if you have a project that would benefit from a well-documented, cross-browser library with some really easy animations and extremely useful functionality, you may too. Check it out, I think it’ll be worth your time.

One note I want to make is that I wrote this before MooTools 1.2 was released. For the record, I love the changes that were made; it’s much faster, there are a lot of cool tweaks that make it easier to use and it adds a lot of very useful new methods. That said, I think their new documentation page and demos page are just terrible! In addition, they’ve completely disabled their forums in favor of Google Groups, which means any old discussions and examples now only live in Google’s cache despite them coming up in their search very often. Those of you look for 1.11 docs and demos, see here and here, respectively.

While I was working with the design, I realized that I needed to send over my old bit of code that opened links in new windows. As anyone trying to make valid XHML pages can tell you, the target attribute is no longer valid, so if you want pages to open in a new window and you still want your design to validate properly, you have to do a little scripting. I actually found this script a couple years ago to make MediaWiki links open in new windows and it’s served me quite well ever since.

function makeExternal() {
        //make sure the function works
        if (! document.getElementsByTagName) { return; }
        var myRegExp = new RegExp("ext","i");
        var anchors = document.getElementsByTagName("a");
        for (var i=0; i
You run the function at page load and selected links will now open in a new window. To make a link work this way, you add rel="ext" to the anchor tag, which is still valid because rel is a valid attribute. What's nice is this also sets up a relation between your page and the link; ext being short for external. The script parses all anchors for that rel attribute and if it finds ext in value, it appends the class 'external' and sets the target attribute of the link to '_blank'. It's a little hacky, but it works like a charm and any browser with a DOM that supports getElementsByTagName.
Note that you don't have to append any class name if you don't want to. I like that I can make the links indicate that they will be opening in a new window by using a little icon as you can see on this site. I like the icon MediaWiki uses a lot, but the way it uses (indicating that it's an external link) doesn't make as much sense as using it to show that a new window will open. That's my take anyway.
This isn't the only way to achieve this result, and Google will provide you with a million other ways, but this is what works for me. Just thought I'd share.
]]>
			http://joefleming.net/2007/12/16/valid-xhtml-and-opening-links-in-new-windows/feed/
		0