Blogs

View all Blogs >>

In the Spotlight - Jason Harwig

Jason Harwig

Senior Software Engineer at Near Infinity

Jason Harwig full-time job is a senior software engineer at Near Infinity Corporation, an enterprise software development and consulting services company headquartered in Reston, Virginia. In his spare time he runs Pine Point Software LLC, writing Mac OS X applications in Cocoa/Objective-C.

His interests include Cocoa, JavaScript, OpenGL and user-interface design.

























Jason Harwig


Jason Harwig's complete blog can be found at: http://www.nearinfinity.com/blogs/page/jharwig

Thursday, June 5, 2008

I was reading a blog entry at Web Reflection that outlined some obscure solutions to common JavaScript patterns.

I thought that entry was interesting, but I'm not sure I'd use them because of code readability and maintenance. It did get me thinking of some other ways to obscure simple tasks.

a better ternary?

Have a co-worker that thinks ternary expressions are ugly? Offer them this alternative:

  var saveFunc = isNew ? insert : update;

  // becomes...

  var saveFunc = [update, insert][+isNew];

Looks a little crazy, huh? It works because a '+' or '-' before a boolean converts the boolean to a one or zero depending on its truthiness. The one or zero is accessing that element of the array. They'll be begging for ternary after that.

I think I might actually use that that syntax in situations where I need to add one depending on a boolean:

  var version = x + (+shouldIncrement);

  var version = x + (-shouldNotIncrement);

throw out parseInt

Converting a string to a number is often done with parseInt. There are some gotchas that many people fall into in that the second parameter to parseInt is not required, but should be. For instance:

  var x = parseInt("08");
  // x is 0, because it assumes octal (base 8)
  var x = parseInt("08", 10); // force base 10
  // x is 8

  // an alternative
  var x = +"08";
  // x is 8

  // Negation works also
  var x = -"08";
  // x is -8

Use them wisely, or preferably never.


Thursday, April 10, 2008

Of the trinity of web technologies, CSS is by far the worst at this stage. It's a language that begs for more power.

Wouldn't it be cool if you could do this?

@variables {
  NEAR_INFINITY_ORANGE: #C96522;
}

div.header {
  background-color: var(NEAR_INFINITY_ORANGE);
}

or do property transitions like this:

div {
  opacity: 0;
  transition: opacity 1s linear;
}

div:hover {
  opacity: 1;
}

or do transformations on elements?

#downloadLink {
  transform: rotate(10deg)
}

... well it's coming, and in some cases already here. The last two are already working in Safari 3.1 and there is a spec for CSS variables.

Hopefully we are past those days where a spec is released, but no one could use it until 5 years later. Ajax took ~6 years for crying out loud.

twitter: jharwig


Wednesday, January 23, 2008

The web community has been buzzing about the new Ajax server, Jaxer, from Aptana. If you haven't heard see John's, or Dion's Ajaxian posts about it.

Now, overall, I am really excited about the future in this project. The problem I had is all their examples use synchronous XMLHttpRequests. We already know why this is unfriendly to users.

Here is a shortened example from Aptana:

Here the call to getName() must return the name, so it runs synchronously. Jaxer provides a getNameAsync() method that accepts a callback (and uses an async XMLHttpRequest call) but it's hidden deep in a technical FAQ page.

Obviously the synchronous code reads better, but until JavaScript has some kind of continuation support to make async calls look synchronous, [functionName]Async should be the only -- or at least default -- means of server communication. Otherwise all Jaxer apps will seem perceivably slow to users, not to mention preventing all other browser windows from responding while requests are active.


Saturday, December 1, 2007

I gave a JavaScript security talk last month, and one of the topics was HTML filtering. I gave examples of how MySpace tried to filter executable code, while still allowing HTML tags for formatting. MySpace, of course, failed to foresee every attack vector, and the Samy worm was born.

HTML filtering was never recommended because it was so difficult to get right, and with no proven libraries, trying to build a solution would almost certainly contain security holes. Thanks to Arshan Dabirsiaghi we finally have something to use. He has created the OWASP AntiSamy project to easily sanitize HTML input. AntiSamy is currently implemented as a Java 1.5 compatible library, but there are plans to support other platforms.

Here's a sample usage...

AntiSamy sanitizer = new AntiSamy();
CleanResults results = sanitizer.scan(request.getParameter("html"));
String html = results.getCleanHTML();
if (!results.getErrorMessages().isEmpty()) {
    log.warn("Input contains errors");
}

Thursday, November 8, 2007

I spoke at the Reston, VA No Fluff Just Stuff conference again this past weekend. The talk was on JavaScript security covering topics including:

  • Cross-site scripting (XSS)
  • Cross-site-request forgery (CSRF)
  • JSON Hi-jacking
  • JavaScript portscanning
  • JavaScript and CSS History "Go Fish"

Here are the slides...