Unnecessary Regular Expressions

18 September, 2012 § 13 Comments

Regular expressions are powerful. They are the jackhammer for all chiseling purposes. In some situations they work great, but often they are either overkill or computationally unreasonable.

Regular expressions introduce a state-machine that is hard to optimize for each case.

Here are a couple regular expressions that I’ve seen within code that was replaced with easier-to-read and faster code.

s.replace(/[^.]*/g, “”).length

This regular expression removes all non-period characters in a string. It then queries for the length of the new string. This effectively just gets the number of periods in the string.

A much simpler approach, and also faster, would be to walk through the string and just count each instance of the period character.

var i, l = s.length, count = 0;
for (i = 0; i < l; i++) {
  if (s[i] == '.')

s.replace(/\s+$/, “”)

This regular expression removes all whitespace at the end of the string. A much simpler approach would be to use the trim() function. There also exists non-standard functions trimRight() and trimLeft() that can be used to only remove whitespace from a specified side of the string.

Testing it out

If you’d like to see the performance differences for yourself, you can run the character counting and string trimming benchmarks on JSPerf.

Applying Fitts’ Law to Commonly Used Buttons

11 July, 2011 § 14 Comments

In a previous post, I covered my work on improving the usability of the Back button in Firefox. Starting with Firefox 8, clicking on the area between the edge of the window and the Back button will fire a Back-navigation event.

The idea behind a change like this comes from Fitts’ Law. From Wikipedia, Fitts’ Law “predicts that the time required to rapidly move to a target area is a function of the distance to the target and the size of the target.”

All operating systems that I have used stop users from moving the mouse off the screen (outside of the virtual desktop space). This means that if a user hurriedly moves their mouse across the screen, it will stop on the pixel that borders the edge. By adding an action to this area, the area becomes a very easy to hit target for users.

Clickable area of the Close and Start buttons is shown in this graphic.Taking advantage of this feature is not unique to Firefox. There are many individual parts of the Windows user interface that exhibit this same usability trick.

  1. When a window is maximized, the Close button is positioned in the top-right corner of the desktop. Visually, there is four pixels of padding between the button and the right edge of the screen. However, clicking in the padding will still close the window.
  2. The Start button is located in the bottom-left corner of the screen. There is eight pixels of padding between the button and the left edge of the screen. Clicking in this padding will launch the Start menu.
  3. Windows 7 introduced a button in the bottom right of the screen that is used to show the desktop. There is no padding between the button and the edge of the screen.

I was not part of the decisions to place these button in these positions, however I strongly believe that Fitts’ Law played a role in their location.

These are just a few of the many ways that Fitts’ Law can be found in user interface design. See if you can find others that I didn’t mention :)

Performance Improvements of Screencast.com

23 May, 2011 § 1 Comment

The latest Screencast.com release included a couple speed improvements that were quietly included.

URL improvements

The first improvement was one requested by Kyle Mulka, of Twilk, during a visit to TechSmith. Kyle mentioned that he wished the Screencast.com short URLs would stay short after the web page was accessed. He mentioned that a lot of users like to copy and paste the URL from the address bar and use it in tweets.

I spent a bit of time researching what we would have to change to fix this issue, and in a couple of days we had the changes implemented.

This change also brings about a nice speed improvement to the loading of pages on Screencast.com. Previously, when a piece of content was visited, the server would reply with an HTTP Status Code 302 - Found. This causes the browser to then load the page at the redirected location. This little bit of communication takes time, and with our new change we have removed this initial hurdle.

Here is a graphic showing the change in loading times:

With this improvement, we have increased the speed of viewing your Screencast.com content by 4.1% on average. If you are viewing your content from outside of North America, you can expect an even larger speedup.

Reduced page size

The second improvement that was added to Screencast.com was a new library layout. Much care has been taken to reduce the filesize of the webpages, to the point where loading up my library using the Library (beta) only uses 1/4 of the bytes yet sends more data. The Library (beta) also makes 11 less network requests than the current library. This means that your Screencast.com library is now more accessible under tighter network conditions such as 3G.

Static vs. Dynamic Scoping

3 May, 2011 § 12 Comments

Have you ever heard of dynamic scoping? Most of us have worked in environments where static scoping is all we have, and probably for good reason.

One of the first things people think about when they hear the words “dynamic scoping” is dynamic memory, which is not at all what dynamic scoping is. Dynamic scoping could also be thought of as context-specific scoping.

C, C++, C#, and JavaScript all use static scoping, whereas Perl and Logo allow dynamic scoping though their local keyword.

Here’s an example to compare the two:

Static scoping Dynamic scoping
const int b = 5;
int foo()
   int a = b + 5;
   return a;

int bar()
   int b = 2;
   return foo();

int main()
   foo(); // returns 10
   bar(); // returns 10
   return 0;
const int b = 5;
int foo()
   int a = b + 5;
   return a;

int bar()
   int b = 2;
   return foo();

int main()
   foo(); // returns 10
   bar(); // returns 7
   return 0;

Dynamic scoping means that when a symbol is referenced, the compiler/interpreter will walk up the symbol-table stack to find the correct instance of the variable to use. This can be a cool tool to use when writing software, but also a huge source of errors if it is used accidentally.

JavaScript: The Good Parts presentation

4 April, 2011 § 1 Comment

Last week I gave a presentation at Michigan State University to a group of students who have a passion for web development. Many of them are experienced with HTML and CSS, but are just getting introduced to JavaScript.

This talk covers some of Douglas Crockford’s “JavaScript: The Good Parts” book.

Douglas has also posted his slidedeck online if you would like some more information. I removed some of his slides from my talk due to its introductory nature.

One of the students in the audience asked for more resources about JavaScript. During the presentation I recommended W3Schools, but after further thinking I realized there are just too many poor recommendations and incorrect statements on W3Schools website. I found a good list of places to grab resources from on w3fools.com:

I wanted to follow up with resource that your members can get more information. This list is from w3fools.com:

JavaScript at MSU

28 March, 2011 § Leave a comment

This coming Thursday I’ll be giving a talk at the monthly MSU Student Web Authoring Team meeting.

A JavaScript Workshop
Thursday, March 31st
317 Bessey Hall, Michigan State University

I’ll be covering the JavaScript language and its interactions with the DOM from a beginners to intermediate perspective. This will be a hands-on workshop style with a short presentation at the beginning.

Bring your laptop and a good spirit and hopefully you’ll walk away with some new knowledge and appreciation for JavaScript.

I will try to record the presentation portion and make that available here on my blog for those that are unable to attend.

Updated on 4/4/2011: I have uploaded a video of the presentation for your viewing pleasure.

XSS Prevention in GMail

28 February, 2011 § Leave a comment

Many popular web applications use JSON as their data interchange format. The format is very compact, easy for humans to read, and is based on a subset of JavaScript.

I’ll start by showing an example. Consider a website that wants its clients to query the server for the most recent 3 public messages. The client may send a GET query to the following address: https://mail.google.com/recent_messages/

The response can be written as follows:

var messages = [
   {"user": "foo", "m": "I like turtles", "t": 123423550},
   {"user": "bar", "m": "Turtle power!", "t": 1234543245},
   {"user": "baz", "m": "Cowabunga dude", "t": 1234567643}

When mail.google.com requests this JSON feed, it could then run eval() on the source code. Afterwards, it will have a messages object in global scope that it can reference.

This could work out good for GMail, but it can also allow other websites to make the same call. Modern web browsers will not allow asynchronous HTTP requests to cross domain boundaries, so it is easy to think that this is safe. However if the location is added as the src attribute of a script tag, then the browsers will load the content.

To work around this, GMail adds while(1); to the beginning of the JSON response.

When requesting JavaScript through a script tag’s src attribute, the DOM does not give access to modifying the content of the response. This keeps the while(1); present. If a client tries to eval() this JSON request, their browser will simply hang.

Pretty interesting, huh? There still are workarounds that can defeat this, such as setting up a server-side proxy that will make the request and strip the while(1).

If you’re looking for more details, Adobe Labs has a page on their website that covers Preventing the Execution of Unauthorized Script in JSON.

Where Am I?

You are currently browsing the Research category at JAWS.


Get every new post delivered to your Inbox.

Join 998 other followers