/*
asciimo.js – written by Marak Squires
saved from the internet @ http://patorjk.com/software/taag/

i had to do unholy things to make the original code work, seriously.
check the commit logs on github and you’ll see how much “code” i had to delete and refactor.
what’s left isnt really acceptable, but it does work.

let’s clean this up and get a more comprehensive font database!

— Marak
*/

So that’s the header comment to a new open source project called asciimo. Though I’ve never heard of the project, it’s actually composed of the inner workings of my Text Ascii Art Generator (TAAG) web app. I’ve never heard of Marak Squires either, and I don’t particularly like his snarky comments about his difficultly in stealing of my work.

I’ve had stuff taken from this site. Sometimes it’s makes me smile, other times it makes me shake my head. This makes me shake my head. TAAG was the project I used to return to JavaScript. It was written with JavaScript knowledge I remembered from the late nineties. It was a project I did for fun. Hell, I didn’t even know what AJAX was when I first released it. Underneath it ain’t so pretty, but it’s mine and not some jerk’s ticket to getting a lot of attention for themselves.

I should probably be angrier, but I’m actually mostly just disappointed that someone did this. This is lazy and selfish. I develop all sorts of random stuff, and I do it for fun. If I see a concept I like, I’ll try and make my own version, I don’t take someone else’s. When I see something like this, it’s upsetting. Is it for some quick attention? So they can state that they’ve started X number of open source projects on their resume?

I was initially told of this project through email (thank you Jan), though I later found Marak’s self promotion on reddit (edit: screen capture from saved html file – he deleted some of his comments). His response to my comments was that because I didn’t explicitly put a copyright notice in my code that he could use it however he wanted (which I’m pretty sure isn’t true). He tried to say he did it for altruistic reasons, but FIGlet itself is open source, and there are already PHP modules available for people looking to use it in the browser (here and here).

Maybe in another universe we could have had some kind of cool collaboration, but at least in this one, Marak doesn’t seem like the type of person I’d want to collaborate with. He comes off as abrasive, self-centered and thoughtless. It’s a shame he has to use the ideas and work of others to promote himself.

Follow Up: Aftermath

I have a beta version of my quiz app ready, you can check it out at one of the following links:

• Quiz Guide – Same page shown a few entries ago, except this time the link to the Tcl/Tk quiz works.
• Tcl/Tk Quiz – My first programming quiz for the PK app. I still plan on adding more questions, though I felt it was important to get a beta version out.

Right now all I have ready is a Tcl/Tk quiz. I’m guessing 90% of the people who read this will have no idea what Tcl/Tk is, but it’s a fun little scripting language that pops up in a lot of different places. Even if you aren’t familiar with it, the quiz will give you a feel for what the others will look like. I’ve set things up so that the quizzes themselves are JSON files, and are read in and generated on the fly by a single PHP page. The URL is set up to look like a directory, but it gets rewritten and pointed towards the PHP page (which will currently display the Tcl quiz no matter what, even if the quiz directory isn’t tcl-tk-basics).

The quiz engine is currently set up to track multiple variables, with one variable acting as the “correctness” value to determine if a question is right or wrong. However, using a correctness variable can be turned off. The ability to track more than one variable allows the quiz to track different types of answers and to measure more than one thing. At the end of the quiz you’re presented with a table showing how you did in the various areas the quiz measured. Tracking multiple variables is how I imagine those online-dating site quizzes to work (the ones that will tell you about your personality, etc). I figured I’d keep my app as flexible as possible in case I wanted to do more creative things with it (though I have no plans to get into the online dating site world, I just want a flexible app).

Right now there’s only one type of question (multiple choice), though I hope to add more in the future. You also don’t lose points for incorrect answers. I’m still not sure if I want to add that ability in.

Also, while searching for icons to use in this program I found some pretty good resources, so I figured I’d share them here:

• Developpers Icons by Sekkyumu – 105 free icons that you can do anything with.
• Icon Finder – An icon search engine.

If you have any suggestions for the quiz app please let me know. I don’t think I’ve wasted as much time on any other app fretting about things that people probably wont care about. The app was actually partially re-written a couple times this past month. There’s was an ExtJS version, a version that used HTML tag generation instead of createElement (I’m still not sure what’s best), and lots of stuff I kept taking out and putting back in. However, I figured it was best to post a version up before I got old and gray.

In the back of my mind I had been thinking about putting up some programming quizzes, similar to the ones I used to have on Visual Basic and C++. I was also thinking that it might be cool to have a quiz engine where users could create their own quizzes.

I’m not at that point yet, but this past weekend I decided to take the opportunity to try and learn ExtJS better and put together an interface for the app. You can see an image of the interface to the right or click here to see it in action. It’s pretty basic, but has all the functionality I think I’ll need for now.

The layout is broken into 3 sections. The top section is the header, to the left you can select quiz categories and get book recommendations, and on the right you get a list of quizzes. Hopefully the “Related Reading” panel doesn’t seem too commercial, as it was actually kind of fun to put together. I didn’t want to set myself up for having to write dozens of quizzes, so right now the interface only lists 3 quizzes (which I’ll hopefully have available soon).

Right now I’m in limbo about how complex I want this project to be. I’m not sure if I want users to be able to have accounts, and I’m not sure what data I’d want to store in a database. I’m also wondering if quizzes should be static html pages after they’re created. I’ll figure something out though.

Working with ExtJS was actually a lot of fun, and their online API documentation is fantastic. The library also seems to load rather quickly too. When I worked with Dojo, I was alarmed at the time the page took to load and how it looked while it loaded. I’m still a little bummed about the licensing for ExtJS, but I can live with certain things being GPL’d.

After reading up a on HTML5’s canvas element, I decided to re-tool the game I was working on to work inside of a canvas element. This was because the canvas element provides some great drawing functionality. You can resize, rotate, crop, position and alter the pixels of images you use on the canvas.

The game is still not done, however, I’ve uploaded another demo that shows the space ship and its main bad guy. You can use the arrow keys for movement and the “s” key to shoot. I changed the shoot key from the Space Bar to “s” because Opera was giving me issues when the Space Bar was pressed while the canvas had the focus.

Also, unlike last time, the game works best in FireFox, and basically sucks in everything else. Opera and Chrome can run the demo, but the frame rate is painfully slow. Since IE doesn’t support the canvas element yet, I’m using the JavaScript library Explorer Canvas to emulate it. Though you have to be using IE8 and be in “Quirks Mode” for it to work – and even then, the game is unplayably slow. Since the canvas element is part of the new standard, and one of its hyped uses is for creating games, I’m assuming / hoping that its performance is going to improve over the next couple of months in these browsers. However, since the canvas element is so cool, I’m still going to finish this game off even if it only works in FireFox.

For those of you interested in using the canvas element, Mozilla has a really good tutorial on it here, and there are some neat canvas game-themed tutorials here.

Lastly, and on a completely different note, I’ve written an update to the Is Someone Pretending To Be You Online? post I made a year ago. The update is at the bottom of the post and basically says the problem was due to a database error (which was a relief). I didn’t do an update right away since I didn’t want to embarrass the site owner.

“What would be something neat to do in JavaScript?” – I kept asking myself that on Saturday. My fiance was away for the weekend and I was just kind of hanging out at home with the dog. Eventually I ended up thinking about possibly trying to do a side scroller game, like Mario Bros or Commander Keen, but since I had never written one before, I wasn’t sure. Finally, I came to the conclusion that it might be wiser to go for something a little easier first, and decided it might be cool to port my old “Intergalactic Odyssey” space ship game to JavaScript.

My goals here were to just see how feasible it would be to create an action game with moving sprites. I didn’t get very far, but I was able to create a space ship that could fly around and shoot lasers. I was able to get the graphics by decompiling my old SWF Flash file (I’ve long lost the source to the game). Also, the space ship artwork was done by fitz. I originally found the space ship via Google Images, though I did ask before I used it.

So far the main issue I’ve run into is that IE and FireFox aren’t reliable for smooth game play. The demo works best in Google’s Chrome and Opera’s Opera web browser. Though at this point I haven’t added any collision detection in, or any bad guys in, so there’s still a ways to go before I know if I’ll have a playable game.

One thing I didn’t realize when I started was that I could rotate images. I googled for a little bit and didn’t come up with anything, so I wound up creating images for each of the different rotations of the space ship. Though now that I’ve read up on it a little more, image rotation can apparently be done with the Canvas object in FF, Opera and Chrome, and with filters in IE. I suppose I’ll find out later which method is faster.

Lastly, the key capturing events are a little frustrating, since JavaScript doesn’t appear to remember when someone is holding the Up-arrow down if another key is pressed while its down. I’m still trying to figure out if there’s a way to get around this.

If you have any tips/suggestions, feel free to let me know.

You can now create custom keyboard layouts and compare them against other layouts in the Keyboard Layout Analyzer. Below is a screen capture of the tab interface for the new feature.

Layouts 1-5 can now be configured any way you want them. So you can create your own layout and see how it stacks up against the more well known layouts, or you can make modifications to the existing ones and see how well your changes do.

Hopefully the interface is pretty straight forward. Clicking keys causes them to change places, and you can remember layouts you created with the use of the “Layout ID”.

I’ll be wrapping up my updates for this app pretty soon. I’m not sure what my next project will be, but I have a couple of ideas I’m considering.

I’ve added a new feature into the Keyboard Layout Analyzer that will let you know the distance your fingers travel while racing across different keyboard layouts. It’s interesting not only because it lets you know how far your fingers are crawling, but because it lets you test out one of Dvorak’s claims on why his layout was better than the QWERTY layout:

Dvorak estimated that the fingers of an average typist in his day traveled between 12 and 20 miles on a qwerty keyboard; the same text on a Dvorak keyboard would require only about one mile of travel.

Sources: [1] [2] [3] [4]

Below I have the results of several pieces of text I analyzed. The QWERTY, Dvorak, and Colemak layouts are compared against each other. The distance shown for each is just an estimate, but it appears as if the idea of typing 20 miles in a day is a little excessive. Also, the Dvorak layout only seems to give you a 40%-45% improvement over the QWERTY layout when it comes to the distance you type.

George Orwell’s 1984 book, Chapter 1:

QWERTY – 0.5629 miles
Dvorak (Simplified) – 0.3107 miles
Colemak – 0.2935 miles

Christopher Nolan’s The Dark Knight Movie Script:

QWERTY – 3.0929 miles
Dvorak (Simplified) – 1.8838 miles
Colemak – 1.8497 miles

Jared Diamond’s The Curse of Qwerty article:

QWERTY – 0.3852 miles
Dvorak (Simplified) – 0.2173 miles
Colemak – 0.1938 miles

Steve Yegge’s Pinocchio Problem blog post:

QWERTY 0.7167 miles
Dvorak (Simplified) 0.4115 miles
Colemak 0.3619 miles

My Previous Post:

QWERTY – 0.0412 miles
Dvorak (Simplified) – 0.0233 miles
Colemak – 0.0211 miles

The algorithm for determining the distances is still being tweaked at the moment, so the distances may change in the future, however, it wont be dramatic. The biggest thing I have left to do is to factor in the pressing of the “shift” keys when an upper case letter is typed.

To the left you can see a diagram showing how the distance between two keys is calculated. The center coordinate of each key is known, so the Pythagorean theorem (c² = a² + b²) is used to calculate the distance between keys. The horizontal distance between the center of two letter keys that are next to each other is said to be 1.9 cm [reference]. This is 40 pixels in my set up. Therefore, I calculate the distance in pixels, and then convert it to meters by dividing by 40 and then multiplying by 0.019. I’m probably currently doing way more calculations than I should be doing, and that will be optimized later, but for now this is how its currently working.

If you’re skeptical about the distances you get back from the program, you can also try Colemack.com’s Layout Comparison Tool, which also produces estimates on typing distances. They’ll be slightly different from what I display, but they’ll be within the same ballpark. As an aside, somehow I missed seeing that app until recently, but at least our programs have their divergences.

Let me know if you have any issues with the distance calculator. Also, I’ll hopefully have some more updates to the Keyboard Layout Analyzer coming within the next week or two.

I’ve uploaded a new version of my Keyboard Layout Analyzer. You can see a full screen capture of the output page below. The new version has a layout similar to the one I discussed in my last post, and has a different chart set up, as well as a hand full of other small new features.

This new version is essentially a complete re-write of the old version. I had been making mental notes of features I thought would make the program a lot more useful, and after thinking about how I’d implement these new features, I realized I’d be better off just re-writing the application instead of modifying the old one.

This re-write was also a way for me to “pay down” my “technical debt” (I think I like that term), as I was able to more efficiently implement certain things to make them a lot more flexible. When I write stuff for fun, a lot of the time I just go with the first or second implementation I think of and then get to work. This re-write will probably serve as a good lesson learned, since the re-write was a little more painful than I expected. Only one of the new features that I thought up is in the program right now (the new chart set up), I didn’t have time to get to the rest of them, though I hope to implement them in the next couple of weeks.

Here’s an overview of what’s in this version:

• Updated interface.
• Able to view charts of different layouts all at once.
• Able to select what pieces of information you want to factor into the charts.
• Addition of the Capewell and Arensito (Simplified) layouts. However, this set up isn’t final. These layouts will still be in the next version, but the options will be a little different.
• “Personal Layout” factored into the statistics.
• A layout recommendation is made based on what you typed.

This new implementation also consists of 26% fewer lines of code.

This new version was tested out in Firefox 3.0 and 3.5, Chrome, and IE8. Unfortunately, the new IE8 messed up my install of IE6Eolas, so I’m not sure how the app works in IE6 or IE7. Oh, and I hate to rehash the cliché of bashing IE, but IE8 is actually a lot slower than IE6 and IE7 when it comes to executing JavaScript. Enough so that I was actually a little dismayed. I had been hearing mostly positive things about IE8, but I just didn’t see anything that I thought was that impressive.

Anyway, if you have any suggestions for the Keyboard Layout Analyzer or find any bugs in it let me know.

Coming up with a good looking, easy-to-use design is hard. Sometimes I feel like I spend more time trying to design an application’s layout than I do programming its back end, and most of the time the resulting layout isn’t that impressive. I think I’m just better at creating functionality than I am at making something that looks pretty. However, no one’s going to look at something if it looks like crap, and people tend to give applications more of a fair shake if they look nice, so I think the time I spend trying to become a better designer is worth it.

Recently I’ve taken to trying to improve the look of my Typing Speed Test. Below you can see the initial design, a design I put up last month, and the most recent design, which I put up this past weekend.

I made the initial design with the idea of keeping things as simple as possible, however, in retrospect, the page looks kind of unbalanced and the big yellow explanation box at the top kind of comes off as a little bit of an eye sore. The second layout was made with the aim of being a bit more stylish. I got ride of the yellow explanation box, threw in some small gifs, added a keyboard reference, and put in a header bar to make it seem a little less plain.

The third, and current layout, was made with the aim of trying to make something that, in my mind, looked good. I don’t think I quiet accomplished that, but I think I came up with something better than what I had. The interface seems cleaner and more balanced, and I like the additional color at the top of the page. The only thing I’m not sure I like are the header images, they seem a little cheesy. So I’ll probably keep tweaking the layout. My goal is to come up with something I can re-use on future (and existing) applications.

I can’t remember a time when I was so exhausted. I’ve moved into my new townhouse, though it still feels like there’s a ton of stuff to do for it. I also got engaged recently, and even though the date is a year away it seems like there is a lot to do for it. I’ve also been working 50-55 hour weeks at work the past few weeks, usually leaving work around 10pm. That last one isn’t too bad, since I’m getting overtime and I know people who’ve done much worse (I have a friend who told me he once did a 27 hour a day). However, it’s all left me a little worn out. However, I’ve still kept this site in my thoughts.

One behind the scenes thing I decided to look into was web app versioning. Sometimes I want to make a small update a program like Text Ascii Art Generator (TAAG), where I might need to change 3 or 4 files, yet if the user has certain files cached, the mish-mash of certain new and old files could cause the program not to work. There may be some obvious way of doing versioning that I’m just not aware of, but its something that’s bugged me for a while. I had been getting around this issue by naming the files I wanted to update something different (ex: font-settings-v1.htm became font-settings-v2.htm, etc), however, this seemed a rather messy way of doing it.

Recently I decided to put the whole app except for its index.htm file under a directory representing its version, and having the index.htm point to the sub-directories under the latest version. So the apps contents would be placed in a structure like this:

patorjk.com/software/taag/1.0.0/pages/ – Pages for the app
patorjk.com/software/taag/1.0.0/css/ – CSS files
patorjk.com/software/taag/1.0.0/scripts/ – Scripts
patorjk.com/software/taag/ – Where the index.htm file would go

This is nice because it allows me to go back in time if I screw something up. For example, if I decided I didn’t like version 1.0.1 of the app, I could go back to version 1.0.0 by just changing the index.htm file. This method also prevents any kind of awkward file combination due to cached files. However, it’s down sides are that I have to upload a whole new version of the app every time I update and I need to make sure users aren’t linking to or bookmarking pages underneath the version sub-folder. The app has to be set up so that the version folder is invisible – everything has to happen through the page at the base directory. This is so search engines wont index every single little version of the app.

So far this system seems to work pretty well, however, if anyone has any suggestions let me know.

In the weeks to come…

I imagine my free time to be kind of scarce for a while, but I have some ideas I want to work on, so updates will keep coming, but probably in a more sporadic manner.

Last time I said I had two more major features that I wanted to add into my Typing Speed Test. That number has since ballooned quiet bit and now I’m not really sure when I’ll be done with it.

The biggest change you’ll notice today is that the input text is now in a 3-line format that scrolls once you’ve typed to the end of the second line. I like this change a lot sense I think it allows for a more simple user experience.

Another reason I like it is that it allowed me to find my first undocumented (for the most part) bug in IE (well, the first one that I’ve taken the time to examine). It appears IE has issues with returning the correct offsetTop position of span tags in certain situations. I’ve set up a test page here that’ll show you different offsetTop values when you use IE as opposed to other browsers. This guy had similar issues, though he couldn’t reproduce his problem via a test case. Luckily for me, his offsetTop span solution also worked for what I was doing (just set the span’s position property to relative).

Since the input text can now be scrolled in a smaller area, I’ve also added in some additional test time options. You can now run the test for up to 5 minutes or up to 1000 words. I will warn you though, typing the 1000 word version of the test more than twice in a row will leave you kind of sore.

A lot of the other changes I made were under the hood changes. To decrease loading time, I’m now using the YUI Get Utility for certain script files. This utility allows developers to grab script and css files at run time and integrate them into their code. Right now I’m using it to grab unloaded script files that contain functions that return input text for the typing test. I figured that most users aren’t going to try every possible test input, so there’s no reason to load them all each time. It doesn’t improve loading time a whole lot right now, but it’ll keep the loading time from growing once I start adding lots of different test inputs.

I’ve made a bunch of other minor changes and fixes, but I wont bore you with all the little details (unless you want me to). If you find any problems in this new version please let me know.

I’ve updated my Typing Speed Test with a new feature that lets you see how fast you typed each key on the keyboard. Once you finish the test, you’re presented with a visualization of the keyboard where the keys that were typed faster are more red and the keys that were typed slower are less red. Keys that are completely white were not typed at all and grey keys aren’t factored into the calculations. To see stats about an individual key, all you have to do is mouse over the key you’re interested in. Below you can see a screen capture of the feature.

Let me know if you see any problems. I still have two major features I want to add into this app before I move onto my next project.

EDIT March 26, 2009: I’ve updated the visualization. Blue now represents key that were typed slowly and red represents keys that were typed quickly.

Some big updates were made to my Typing Speed Test. I’ve spent the last two weeks brainstorming and implementing ideas I thought would make it more useful. Once I found I could easily capture the speed at which the keys were typed I realized that this also meant I could deduce how fast each finger was moving.

However, to be able to accommodate Dvorak and Colemak users, I had to make the user’s keyboard layout one of the configuration items. I also realized that not everyone types according to the standard fingering positions, including myself. I noticed this back when I was learning the Dvorak layout. My right pinky kept getting really sore. When I switched back to the QWERTY layout, I noticed that the only keys I used my Right Pinky for were the “Enter” key and the “Right Shift” key. To accommodate the people who deviate from the norm, I also made it so users could manually set which fingers they used for each key.

Allowing users to change the normal Finger-to-Key mapping lead to some hard user interface decisions. What I ended up creating was a keyboard map where the user changed a key’s mapping by clicking it one or more times. When it’s clicked, its mapping goes to the next finger in the legend. I initially had a design that used radio buttons, but I didn’t like all of the back and forth movement it caused with the mouse. I’m still not sure I have the best design, but for now I think what I have works fine. Below you can see an picture of the user interface. The keys are set with the finger positions I typically use.

Once you finish the test you’ll now be presented with stats on how well you typed and stats on how fast your individual fingers were. To make the test more blog friendly, I also decided to present the user with the HTML code for the output tables. Below you can see two of my tables from a run I did.

Typing Stats Words Per Minute (WPM): 76 Characters Per Minute (CPM): 378 Words Correct: 32 Words Incorrect: 0 Fastest Finger: Left Pinky Slowest Finger: Left Ring Keyboard Layout: QWERTY Test Duration: 30 Seconds

Stats From PAT or JK’s Typing Speed Test

Average Finger Response Time Left Pinky: 119 milliseconds Left Ring: 228 milliseconds Left Middle: 158 milliseconds Left Index: 206 milliseconds Right Index: 135 milliseconds Right Middle: 128 milliseconds Right Ring: 188 milliseconds Right Pinky: N/A Thumb(s): 100 milliseconds

Stats From PAT or JK’s Typing Speed Test

I should note that the finger speeds are based on all of the key presses you make and not just on the ones that lead to correct words. Also, FireFox seemed to be able to detect Backspace key presses while IE did not.

I still have a bunch more ideas that I want to add in, but I haven’t gotten to them yet (like the hot spot visualization I mentioned in my last post).

If you find any errors or bugs let me know. You can post them in the comment section of this post.

I’ve just updated my Typing Speed Test. I basically just implemented the changes that people suggested to me. These included:

• Allowing the user to type real sentences, for example, stuff from books.
• Adding more text input options.
• Cutting the default time down from 60 seconds to 30 seconds.
• Not having the text scroll as the user types and letting the user see all of the text they will have to type.
• Highlighting of the correct, incorrect, and the current word in the box displaying the text that needs to be typed.
• Providing obvious instructions on what to do.

I was unsure about how to display the instructions, so I just put a yellow information box at the top of the page. The only other thing I could think of was to start the app with a Ext JS-style message box, but I figured that would get really old after a while. Also, the spacing at the bottom of the page is kind of weird because I wanted the tab sizes to be static. I’m not sure if that’s the best design idea, so that may change.

For the next release, I’m thinking about adding in more stats on how fast the user types. Maybe giving them info on what keys they typed fastest via a visualization or some bar charts. A line graph showing their progress over time might also be cool. However, JavaScript may not be fast enough to let me do this. While beta testing today I noticed that sometimes I almost got ahead of the app, and keeping lots of extra stats may slow things down too much, I’ll have to see though.

Thank you to those of you who gave me suggestions. I think the test is much, much better now.

If anyone has any more suggestions or finds any problems please let me know!

Oh, and one last news worthy item, I also updated the About page on this blog with some more info and pictures.

Shortly after finishing the beta version of my Typing Speed Test I started to feel like my knowledge of Javascript had some holes in it, especially in the event handling area. It’d been a long time since I’d read a book on Javascript, so I figured I’d pick one up one to help fill in the holes in what I knew.

I looked around a little bit before selecting “ppk on Javascript”. I chose this book after reading some of the author’s online articles. They were easy to read and contained a lot of interesting tidbits. I don’t want to turn this entry into a book review, so I’ll just say I enjoyed the book and would recommend it. However, the book admittedly doesn’t cover certain topics like OOP in Javascript. Though even with its omissions, it still ended up covering a lot of ground. The major things I took away from the book were:

• Event Bubbling vs Event Capturing – I feel bad I didn’t know about this. It answers the question: If an element and one of its ancestors have an event handler for the same event, which one fires first?
• location.href vs location.replace – It’s best to use “replace”. This is because replace doesn’t create a new history entry in the visitor’s browser. This is a good thing, since you don’t want to make a user’s back button useless.
• The navigator.userAgent string has an amusing story behind why its value is so convoluted.
• getElementsByTagName – I didn’t know about this DOM function. It looks like it could be really useful though.
• DOM Tree Text Nodes – When you create an HTML document, the text between tags and the text inside of a particular tag become text nodes. IE doesn’t support empty text nodes while other browsers do, this appears to make modifying the DOM tree a pain.

There were other things too, but those are what stick out in my head while I type this. I’m really glad I read that book. It reminded me of how useful programming books are (I had gotten too use to just Googling whatever I didn’t know).

Right now I’m a little more than 50 pages into “Pro Javascript Design Patterns”, which covers design patterns and OOP in Javascript. So far it’s really good. I had been meaning to read up on design patterns for a while so I’m pretty excited about this new book. I’m averaging almost 20 pages a night, so I should finish up pretty quickly. Once I finish, I’m going to get back to creating content for this site. I may make some posts in the meantime, but I figured I’d give you all a heads up as to what I was doing so you didn’t think I had forgotten about this site.