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.

As of March 21st, it’s officially been two years since I decided to relaunch this website. On the opening day there wasn’t any hype and the site had been down for 2 months – and before that, I think I’d only updated twice in the previous two years. Plus, on this new day, all I had up was a message saying I’d be back. I couldn’t post up anything because my previous host had deleted all of my content and my hard drive had just recently crashed, taking with it everything I had saved. Other than being a lesson in routinely backing up files, this gave me a chance to start fresh.

It’s been two years and I think this site is currently as successful as its ever been. I don’t have a community like I used to, but I do have a decent amount of traffic and links coming in. The site, as a whole, currently gets around 2,700 visitors a day. So I feel good that I’ve been able to come back with something that people (hopefully) find useful and/or entertaining. I suppose it’s just a different site now than it used to be. I’m still steering the ship, and I’m still programming, but I’m using different tools and doing different things.

I think the thing I’ve enjoyed the most over the past two years is seeing the stuff I make or post up actually being used. When working in a big company, sometimes you program something up, hand it in, and then move onto your next assignment. You don’t really get to find out the experiences of the end user or what they thought of the program. You don’t know if they struggled to understand what you did or if they loved it. Well, sometimes you find out, but not always.

The cool thing about the web is that anyone can see the stuff you make. And to get feed back one can just google around or look at their referral logs and see where people are coming from. Sometimes this leads to some interesting info about how people are preciviing and using what you have up. Check out these Stumbleupon reviews I found of my 179 Ways to Annoy People chain letter page:

I think a certain number of visitors were thinking it was a real list. I thought it was obviously a joke, but you never really know what people are thinking when they come across your site, so I added in note at the top of the page letting people know it was just a joke list. Though I suppose some of the reviewers might have realized it was a joke and were just plain offended by it, however, calling a joke list “Asshole Training” seems a bit odd. [As a side note: I'm thinking of getting rid of this page entirely, since it doesn't really go with the rest of the site, though maybe I just wont link to it and let its only source of traffic be 3rd party services like search engines and Stumbleupon]

Another interesting observation I was able to make, this time via my stats, was that a decent number of people were going to my Text Ascii Art Generator program and then just exiting via one of the out going links on the About page. This seemed like a rather strange behavior so I changed the program to automatically display the message “Type Something” once the page was loaded. This ended up causing a big increase in the usage of the program. My guess is that people were visiting the app’s main page and then getting confused as to what they were looking at, so they’d just skim the page and click on one of the out going links. It’s stuff like this, as a developer, that I’d never catch unless I had access to usage stats or user feed back.

Anyway, for those of you who’ve decided to follow this site for whatever reason, I thank you for checking in every so often. It definitely is nice to see stuff I make being used and to get feed back on it.

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.

One of the things I thought I had gotten right when I relaunched this site was URL structure. I thought I’d put all of my web apps in one sub-folder, all my programming stuff in another sub-folder, common libraries in another sub-folder, etc. However, since then I’ve realized my URL structure wasn’t that optimal. A lot of the sub-folders just made the URLs longer and the mashing together of words made a lot of the URLs hard to read. Examples:

http://patorjk.com/blogstylometrytool/

http://patorjk.com/colorfader/

http://patorjk.com/keyboardlayoutgenerator/

http://patorjk.com/software/gradientimage/

http://patorjk.com/software/colorpalettegenerator/

http://patorjk.com/typingspeedtest/

So, to pretty things up a bit, I’ve decided to change how I’m structuring URLs. My new rule of thumb will be to separate words with hyphens and to only use sub-folders when absolutely necessary. Since domain names are supposed to be compact, I think it makes sense not to include them in my hyphen rule. The new locations of the tools talked about above are:

http://patorjk.com/blog-stylometry-tool/

http://patorjk.com/text-color-fader/

http://patorjk.com/keyboard-layout-generator/

http://patorjk.com/gradient-image-generator/

http://patorjk.com/color-palette-generator/

http://patorjk.com/typing-speed-test/

This seems like a rather superfluous change, but it was just one of those little things that was bothering me. I don’t plan to move anything else unless I make a major update to it, and all of the old links are 301 re-directed.

The one program I didn’t move was the Text Ascii Art Generator. This is because it has a bunch of links pointing to it and I didn’t want to mess up its standing in the search engines.

As for my current future plans, I hope to improve some of my existing web-apps. Unfortunately I was kind of tight on time this past week (I had to work past 9PM three times, I’ve got a lot to do at work), but I did do some mock-up Ext JS layouts for the Typing Speed Test program. However, after a little bit of thought, I think I’ve decided I’m just going to extend and change the one I currently have written. I hope to have a new version of it out within the next two weeks. After that, I’m going to try and refurbish another one of my apps.

Lastly, if anyone has any problems with accessing programs using the new URL structure (via old links or whatever), please let me know.

This will probably be my last book review for a while. In December I said I wanted to do some more reading up on JavaScript and I think I’ve satisfied that itch. I’ve read 3 and a half books on the topic since then and I think I’ve gained a good amount of knowledge on the language and some of its various frameworks.

This latest book was sent to me by Packt Publishing (in exchange for a review giving my opinion on the book) and covered the Ext JS framework. Its name is Learning Ext JS and its authors are Shea Frederick, Colin Ramsay, and Steve ‘Cutter’ Blades.

Ext JS is a JavaScript framework that’s known for the eye catching user interfaces that it helps you create. It’s geared toward web application development and it was originally written as an extension to the Yahoo User Interface (YUI) library. Unlike many of the other JavaScript frameworks which are offered under permissive licenses, Ext JS is only available via the GPL, a reseller license, or a commerial license.

Learning Ext JS is a good book and I enjoyed reading it. It has a similar set up to the other Packt Publishing book I read on Dojo, however, Shea and company take a little more time to explain things, which results in a longer but better quality book. I especially liked the first few chapters since the examples were easy to follow and involved a little humor. I also liked how a lot of attention was given to grid widgets (two whole chapters). This is an especially useful widget and it’s not usually obvious how to use or set them up.

As for the flow of the book, it starts off by showing you how to get Ext JS up and running and then it walks you through a small, mostly dialog-based application. After the sample app, the book proceeds with chapters that cover a particular area of the framework – Forms, Buttons/Menus/Toolbars, Grids, Layouts, Trees, Windows and Dialogs, Effects, Drag and Drop, and Data. The last two chapters of the book are on extending the framework and on some odds and ends of the framework (like various widgets created by community members).

The book is aimed web application developers who are familiar with HTML but who may not have any experience with JavaScript. However, even though the authors hold your hand through the early chapters and give an explanation of Object-Oriented Programming in one of the later chapters, this book should really only be read by people who are familiar with JavaScript. I can’t see someone without any JavaScript experience being able to tackle a framework like this.

So if you don’t have much experience with JavaScript, I’d probably pick up a book on plain old JavaScript first. However, if you’re interested in a book on Ext JS and have some JavaScript experience, I’d recommend this book. It provides a good introduction to the framework and takes you through many of its different areas.

Also, for those of you interested in a sample chapter, Packt has Chapter 7: Layouts of the book online in pdf format. Personally I think letting a user read the first and second chapter would be much more useful, but a sample chapter is better than no sample chapter.

About a month ago I had an interesting idea for my Text Ascii Art Generator (TAAG) program. Though due to being busy with work and buying a house, I haven’t had time to try it out. However, the idea is applicable to almost any web service, so I thought I’d share it with you all in case someone out there was looking for a nifty way to make some extra money off of a web app or blog without posting a bunch of ads up. I’m aware that too much commercialism can kill a website, however, I think this idea is kind of clever.

The idea originally struck me when I was brainstorming improvement ideas for TAAG. I thought that it might be cool if the user could put their output on a t-shirt. It’d make for a really neat way for someone to show their techiness/geekiness. After deciding I liked the idea, I then wondered if the t-shirt companies had already thought about 3rd party applications creating dynamic designs for them. After some quick googling, I discovered they had.

Both Zazzle and SpreadShirt allow you to dynamically submit designs for t-shirts which you can then sell. CNN even uses SpreadShirt to sell t-shirts of recent headlines. And you’re not limited to just t-shirts, you can put your designs on all sorts of crazy products – mugs, purses, hats, buttons, mouse pads, shoes, postage stamps, posters – the list goes on.

I’m not advocating turning your web apps or blogs into online stores, but if carefully used, this could compliment their output. An online photomosaic program that would let you buy a poster of your output might be kind of cool. And web comics that would let you buy t-shirts of your favorite comics would probably do pretty well, I had a whole bunch of Far Side t-shirts when I was in middle school.

Though as I said at the start of this post, I haven’t done any of this myself yet. I talked briefly to the FIGlet creators and they were cool with the idea, however, since I didn’t create the fonts themselves I’d feel wrong selling products with other people’s artwork on them without their permission / giving them a cut, and since there are over 300 fonts, this creates a rather complicated situation. So I may not even implement this idea (I’m still thinking about it though), but I figured I’d share the general concept, since it appears it could apply nicely in certain situations.

Packt Publishing, the same book publishing company that sent me the Dojo book, has offered me another free book in exchange for a review, this time on the JavaScript framework Ext JS. I don’t consider myself an expert book reviewer, however, it sounded like another a great opportunity/excuse to learn something new, so I took them up on it.

The book is titled Learning Ext JS and is written by Shea Frederick, Steve ‘Cutter’ Blades, and Colin Ramsay. So far I’ve read about 60 pages, and it’s looking like it’s going to be a pretty good book. It’s paced well and the authors seem to have a good sense of humor (they introduce Ext JS message boxes using a character from Office Space), though I still have around 190 pages left, so there’s still a long way to go.

Ext JS doesn’t appear to be too different from other JavaScript frameworks I’ve tried, though its main focus seems to be in creating slick looking web interfaces. It was originally created as an extension to the Yahoo User Interface (YUI) library, however, due to its popularity, it ended up growing into a stand alone JavaScript framework. Since it was developed with YUI in mind, it initially required YUI to be present to do the behind the scenes work. This changed over time, first with adapters being written so other frameworks (like jQuery and Prototype) could be used to do the core functionality, and then later so that Ext JS came as a complete, stand alone product. Though during this last phase they did keep the hooks in so that you could still use an adapter and have another framework to do the behind the scenes work if you wanted.

From what I’ve seen of Ext JS so far, it’s looks pretty impressive. The offical
Feed Reader and Web Desktop sample apps look especially cool. The only negative I can see, which was initially pointed out to me by Sloat, is that license for the library is the GPL. This means that apps you write using it would be under the GPL and you would have to release the code for them under the GPL. You can avoid doing this by purchasing a commercial license, though this would cost you between $289 and $18,699, depending on the license and support options you picked.

Knowing this, I probably wouldn’t write any large applications using Ext JS, unless I planned to purchased a license. However, for most of the stuff I write, I don’t mind the source code being available, so having to use the GPL is annoying but not a deal breaker. This is something you should think about before you decide to use the Ext JS library though, because this license requires that you release your source code under the GPL.

Anyway, hopefully this experience will lead me to learning a couple of new tricks and being able to create some nicer looking apps. Instead of waiting until I finish the book to do any kind of in depth work with the framework, I think I’m going to try and be a little more interactive this time and write stuff as I go. That way I don’t end up ignoring this site.

So I decided to try and build a full blown web app using the various tools Dojo provides. I wanted to try out the feed reading data store, the grid control, some of the form dijits (Dojo widgets), and the tab control. After some thought, I ended up deciding to write an application that would allow you to compare the writing styles of different blogs and see if they had the same author. This idea had been on my “backburner list” since around 2003 when I read an interesting article on the subject called “Bookish Math”.

The field of study that deals with examining artistic works to determine authorship is called Stylometry. The theory is that each of us has a unique and identifiable way of doing something. For writing, many of the newer techniques involve examining the how often we use common words. From “Bookish Math”:

“People’s unconscious use of everyday words comes out with a certain stamp,” says David Holmes, a stylometrist at the College of New Jersey in Ewing. Precisely because writers use these function words without thinking about them, they may offer more reliable fingerprints of a writer’s style than unusual words do.

“Rare words are noticeable words, which someone else might pick up or echo unconsciously,” Burrows says. “It’s much harder for someone to imitate my frequency pattern of ‘but’ and ‘in’.”

The article goes on to talk about how frequency analysis of certain words in the “Federalist Papers” supported the idea that Madison wrote them instead of Hamilton, how an analysis on the 15th Wizard of OZ Book (billed as Frank L. Baum’s last book) revealed that it wasn’t really written by him, and how various other works can be clearly distinguished from an analysis of common words.

Since counting up common words is rather trivial, I decided to see if I could read in some blog feeds, find the frequencies of their common words, and then compare these frequencies to other blogs to see if I could determine authorship. Unfortunately, this rather naive approach didn’t come out as well as I hoped. After the app was tested, none of the numbers seemed to really stand out.

For blogs that should be similar (like this one and my livejournal), I found the common word frequencies to vary somewhat significantly. I only had overlap on around 10-20% of the words, and I wasn’t sure if that was a statistical coincidence. I also used one other person’s professional and personal blog and found similar results. I then tried to do a little original research and implemented the following alogrithm:

• Find the frequencies of the 50 most common words in the blog’s first 1,200 words.
• Find the frequencies of the 50 most common words in the whole document.
• Compare the two lists and dub the words that have similar frequencies “pattern words” – words that the person seems to use with a consistent frequency.
• Compare the “pattern words” in different blogs and see how well they overlap.

That worked a better, but I still couldn’t get completely accurate results. So the algorithm still needs a lot of work. Below you can see a small sampling of the frequency results from this blog vs my old livejournal. A frequency of 1% would mean that word makes up 1% of all of the words that were typed.

As for the Dojo side of things, I ended up really liking the slick look of the dijits. I also liked how I didn’t have to host any of the Dojo files myself, I could simply use the ones posted at the AOL Developer Network.

However, I wasn’t too happy that Dojo caused the page to take 3-4 seconds to load. And the odd sudden change from normal widgets into dijits in front of the user was kind of odd. I’m not sure if there’s a way to avoid that. This might be because I’m using a lot of Dojo tools and the Dojo library is 1.6MB gzipped. Not everything is downloaded, only what you use, but I ended up using quite a few of its tools.

Other issues I ran into were:

• There’s a bug in the grid control that effects IE7 users. The grid text doesn’t appear in IE7 if the div containing the grid has anything other than “left” for the “text-align” style property.
• You can’t create Dojo grids in divs that have their “display” property set to “none”. This bothered me because I originally wanted the grid containing the frequencies to “fade-in” after the user hit the “Process Data!” button.

Despite the short comings of my algorithm and some of app’s bloat, I decided to post it up anyway. You can view it here: Blog Stylometry Tool (note: I commented out the analysis side of things – so all it does is spit back a table of word frequencies)

I’ll most likely end up slimming down on the amount of Dojo that it uses to increase load time. Either that, or I’ll try and figure out a way to defer some of the load time. The majority of the loading time is coming from setting up the grid.

So I’ve finished reading my copy of the book Learning Dojo By Peter Svensson. It was a pretty easy read and contained a lot of good info. Overall it’s a okay book, though there are parts where it seems a little rough around the edges, however, I’ll get to why I think that in a bit.

So what is Dojo? Dojo is a free JavaScript toolkit similar to YUI and jQuery, though it bills itself as being larger in terms of features and functionality than the existing JavaScript toolkits. Visually, the widgets it provides (which Dojo refers to as Dijits) are pretty slick and easy to use. You can see a demo of many of them here (this link is unrelated to the book).

Dojo is for people who know JavaScript and who want to add more gagets to their development tool belt. Even though Dojo offers alternative ways to do certain things (like inheritance and finding elements by their ID), you can’t really use it unless you have a decent understanding of JavaScript. Well, you could, but you wouldn’t get very far.

Learning Dojo appears to be aimed at giving web developers a broad introduction on what Dojo can do. It starts off with a two chapters introducing Dojo and then follows them by having chapters dedicated to a particular area of interest – like Forms, Dijits (what Dojo calls widgets), Layouts, Ajax, etc. The author even provides the Layout chapter online as a preview for the book, it’s located here. That chapter gives a good sampling of what the author’s writing style is like.

Overall I thought the book was decent. It’s not something I’d rave about, but its a solid book and contained a lot of info and examples. I feel like it gave a nice introduction to what Dojo is and how it could be used in the real world. I found the chapter on “Data, Trees, and Grids” useful. I had been wondering about easy ways to do grids and to read RSS feeds (the book didn’t discuss RSS feed reading, but it mentioned a library that could do it), so I was pleasantly surprised to come across this info.

My only criticisms of the book were some formatting, editing and spelling issues I ran into. Around 5% of the code examples had indentation issues. The tabs would be aligned incorrectly in certain parts of the example. I’m guessing its because a mixture of space and tab characters were used. However, I don’t know, and these examples were still readable. This was mostly just an annoyance. Also, at the very end of Chapter Two, the “JSON” section had 3 small examples where the code was not printed correctly and it was unreadable. This was upsetting, though it was the only place where I encountered this.

Anyway, if you’re looking for a book on Dojo, Learning Dojo, while rough around the edges, does provide a decent introduction and contains some handy examples.

Also, like I mentioned in a previous post, I was sent this book for free by the publisher with the only condition being that I write a review of what I thought. I don’t get any money if you buy it.

And lastly, if you want to play around with Dojo, you can download it for free at their website.

The end of 2008 is approaching. It’s been a good year for this site. I’ve learned a bunch of new things, and the site grew significantly in its content and daily traffic.

Right now I’m enjoying the holiday, so I don’t have any new content to add, however, I figured I’d post up my patorjk.com-Related Goals for 2009:

• Get good at JavaScript. It’s been a while since I’ve felt like I was really good at a particular language. At work, I was referred to as a “language person” by my boss several times since I seemed to be able to dive into any language they threw at me. Versatility is good, but sometimes I feel like I spread myself too thin. I could possibly get really good at Tcl, since I do a decent amount of Tcl programming at work, however, Tcl isn’t that fun of a language and it doesn’t easily do the things I would want to do (I could rant on and on about the pros and cons of Tcl, but I’ll spare you all).
• Learn jQuery. Right now I’m learning Dojo, but I’d also like to learn jQuery, since I know my company uses and it appears to be the most popular JavaScript framework. Being familar with a couple of these frameworks is probably a good thing too.
• Develop More Web Apps. I only released 4 total this year (not including ones that were re-done). This is well under the number I wanted to release. In the future I hope to release one a month, however, I don’t want to set myself up with an impossible goal, so I’ll just say I want to make more.
• Read At Least 4 Programming Books. I’m going to leave 2008 having read 2 completely and 4 part way through. Books can be a great motivator and a good source of learning.
• Join A Programming Community. I wasn’t able to relaunch the patorjk.com forums this year, however, I do still miss the community of the old forums.
• Write A WordPress Plug-In. WordPress is the name of the blogging software I use. I’ve played around with it a bit, but I haven’t really tried writing my own plug-in.
• Release Some Programming Examples. It’s been too long since I released one.

It’s 3:30AM right now, so there may be a few I’m missing, but I think those sum up my mind set right now. Professionally I think I’d like to get back into .NET programming (I miss VB, but for a hobby, I want to stay focused on something, and right now I’m more into web programming than I am into Desktop apps). However, I have no idea what I’ll be doing this next year or even how much I’ll be able to say about it.

2009 year should also be a big year for me personally. Right now I’m looking for a house with my girl friend, so I’m really excited about that. Also, my awful case of tinnitus (constant ringing in the ears) has gone down by about 75%-90% thanks to my switching toothpastes from one that contained Potassium Nitrate to one that didn’t (sensitive toothpastes typically have Potassium Nitrate), and I think it may go completely away. If you know anyone with tinnitus, be sure to pass on this bit of info.

Anyway, I hope you all are having a happy and safe holiday and I hope you keep checking back in!

A few days after I posted my previous entry on the JavaScript books I was reading, I got an email from a book publishing company asking if I was interested in a free review copy of their latest JavaScript book. I was a little skeptical at first, however, after a brief chat, the only string attached was that I write blog entry on what I thought of the book. This seemed like a fair deal, so I decided to take them up on it.

Since I’m getting something for free, I figured the honest thing to do would be to open about it so people don’t think my opinions are biased, since I do tend to gush about stuff I like (YUI, Google Alerts, etc.). When I don’t like something, I usually just don’t write about it. However, if this book ends up sucking, I will be brutally honest about how much it sucks. Though based strictly on chapter 1, the book appears as if it will be a pretty decent read.

Anyway, the topic of the book is The Dojo Toolkit. Dojo is a free open source JavaScript library that provides a number of widgets and utilities, much like jQuery and YUI. Right now I’m unsure of how it compares to these other frameworks, but it looks very promising based on what I’ve seen so far from various Dojo websites. The charting package looked particularly interesting.

Hopefully I’ll learn a lot of cool stuff about Dojo. I wont pretend to be a JavaScript expert, so the review I’ll write will most likely be in the same style as my last review – though probably a bit more thorough. For those of you who are curious, the book is called “Learning Dojo” (that’s the book’s actual website, this is not a sponsored link and I don’t get anything if you buy the book – not that you shouldn’t buy it, I just want to be clear since that page is mostly about buying the book).

After I finish this new book I’m going to get back to my JavaScript Design Patterns book (which it’s really good so far – though I’d only recommend it to hardcore JavaScript developers). And after that I’m going to get back to writing stuff for this site. Hopefully all of this reading will pay off with some nicer apps, tutorials, and programming examples.

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.

I figured I’d announce that I’ve decided to scale back the ads on this web site. Something about putting ads on this blog has always felt a little odd to me. The extra revenue is nice, but I’m not sure its actually worth the commercialization ads bring.

There are still two ads on the site, the Google Custom Search box on this blog’s sidebar, and an ad on the Text Ascii Art Generator (TAAG). The search box is actually functionally useful and the ad on TAAG will still allow a little bit of change to trickle into the site. I don’t plan on adding any more ads until I need to upgrade hosting services.

Part of me wanted to justify my decision with the idea that “ads turn away visitors”, so I decided to make a chart pitting TAAG (which has an ad) and against the VB Array Tutorial (which doesn’t have any ads). Surprisingly, it appears that the ad on on TAAG didn’t have a noticeable negative impact on the number of visitors it received:

This might be like comparing apples to oranges, since both pages probably appeal to a different group of people. However, TAAG’s ad was added in April, so if it bothered visitors I’d expect its growth to go down after April, but instead it seems to have continued on with the normal growth of this site (the spike in June is due to it being popular on StumbleUpon for a few days). This doesn’t change my opinion on removing ads from the blog, I still feel they add an unwanted commercial element to a personal outlet, however, I figured I’d post up this chart for those of you interested in how ads may/may not effect site growth.