Deserialization
Friday, March 28, 2008 — 01:58
I CAN HAZ NUMBER?!
Tuesday, January 01, 2008 — 17:33
I don’t want to write much. Here’s the scoop.
Prototype.js doesn’t have a properly working isNumber check. Here’s the correct one.
Object.isNumber = function(object)
{
return (((typeof object) == 'number') && (!isNaN(object)));
}
Difference should be obvious.
(In retrospect, I guess it depends on what your definition of “number” is. In my opinion, when you’re programming, if you can’t add it to another number, it’s not a useful number.)
Rude Interjections
Sunday, December 16, 2007 — 17:22
A recent Twitter exchange.
Me: FUCK OFF YOU FUCKING PAPERCLIP!!
Austin: “Microsoft Office 2008 brings new clarity to your Office Assistant Experience”.
Me: “Microsoft Office 2008 brings”… —bloop— “It looks like you’re writing a letter!”
And now for something completely different.
An emergency meeting of the Taco Widgets Ninja Council has revealed that there may or may not be anything interesting that I may or may not be able to talk about
In other news, it’s been a very long time since I’ve written here. There’s a reason for that. See paragraph directly above.
JS Arrays Suck
Monday, October 08, 2007 — 22:01
It’s always bugged me that you can’t insert objects or remove objects from arrays in Javascript. I’ve always pined for Objective-C’s insertObject:atIndex:. Which is why I wrote the equivalent.
Array.prototype.insertObjectAtIndex(object, index)
{
return this.splice(index, 0, object);
}
Array.prototype.removeObjectAtIndex(index)
{
return this.splice(index, 1);
}(Sometimes, I wish I could just end posts without writing something witty.)
Widget Preferences
Saturday, July 21, 2007 — 17:16
Anyone who has programmed widgets knows that it can be a pain to implement preferences. You have to:
- Load the preference value, taking care to check for a null value.
- If it’s null, set the default value.
- Create the necessary DOM elements through HTML.
- Set the appropriate value on said DOM elements based on the preference value.
- Monitor the DOM elements for changes so you can update the preference value.
You get the idea. Wouldn’t it be nice if you could just instantiate a class to do the work for you, much like you do with the AppleGlassButton. If you’re saying “Golly gee, Galen, that’d be great!”, keep reading. (But first stop watching those 50’s films.)
Over the past few weeks, I’ve been working (intermittently) on a chunk of code to do just that. It’s all part of a larger chunk of code that will go into an even larger chunk of code which is our next big widget. I decided that it just wouldn’t be fair if I didn’t offer it to all my faithful readers too (all 4 of them).
Here’s the JavaScript: widg_prefs.js.
And, here’s a demo widget that uses these preference types: draft.zip.
If the demo widget doesn’t quite explain it for you, there’s some documentation at the top of widg_prefs.js. These classes require prototype and script.aculo.us.
Now, before you go and plop this into your next big widget, take a look at the demo widget. You see those three examples? Two of them are commented out. (Only one works at a time. You can tell how much time I spent on this demo.) That constitutes the entirety of the testing done. I’m not kidding.
As I use these classes in our next big widget I’m sure that I’ll find and (hopefully) fix bugs in them. I’ll put up the revised version when that widget comes out. Until then if you use these classes and find a bug, feel free to tell me all about it: galen dot winey at tacowidgets dot com.
The fine print: Use this at your own risk, free of charge. Credit to me and/or Taco Widgets would be nice. Don’t sue me.
800×600
Monday, March 26, 2007 — 18:12
Whenever I do web development, I always make sure that the sites that I build will look good on an 800×600 screen. I know that almost no one has that size screen anymore, but I still think its a good thing to check.
But how do I check this, you ask? Good question. Well, I use a bookmarklet that makes a new window with the current contents at 800×600.
javascript:void(window.open(window.location,'800x600','location=yes,status=yes,menubar=%20yes,scrollbars=yes,resizable=yes,width=800,height=600'))Just a nice little piece of code to put into the bookmark bar for use when making web sites.
if (me > you) …
Wednesday, March 14, 2007 — 19:47
Very excellent:
The Programmer Hierarchy (PDF link)
Programmers always have to feel superior to other programmers. Via Daring Fireball
Spinner
Monday, December 18, 2006 — 03:47
Recently, I’ve been toying around with creating a spinner animation in JavaScript. I wanted it to run asynchronously and allow it to start and stop. What I ended up with was a JavaScript class that could string 12 images together in an animation. It also handles the preloading and the starting and stopping.
I only have a couple of complaints about it. One is that if you run it, then leave it for a while, then run it again, it will be slower in loading the images the first time around. (This could just be because my computer doesn’t have a lot or RAM. But I guess that still qualifies as a complaint.)
Also, the images don’t scale down very well. If you were to shrink them to, say 16px by 16px, they would look terrible. I guess you’ll have to change them if you want to shrink it.
Here’s an archive complete with a JavaScript class for the Spinner, an HTML file for the demo, and 12 PNGs for each of the spinner images. spinner.zip
Enjoy.
Real Code
Friday, December 08, 2006 — 23:26
If you’ve ever watched any movies with computer code in them, you’re probably familiar with the idea that all code is green text on black, moving rapidly, and beeping.
Reality: No. Just no. I uploaded a picture of some of the code in MadLibs. It may not be readable to most people, but it isn’t “Hollywood” code.
Here’s a great article about What code DOESN’T do in real life (that it does in the movies).
Buffering Dynamic HTML
Wednesday, November 15, 2006 — 04:45
Fair warning: This post will have extremely nerdy content. But you probably could’ve guessed that from the title.
Story time. On our latest widget, we have to display a significant amount of HTML that has been generated by JavaScript. By “significant amount”, I mean 275 plus lines of information that was generated and displayed by JavaScript. I know that 275 doesn’t sound like much when there’s a computer doing it, but it seemed to be slowing stuff down.
To display the information I was “printing” I would print it directly from a loop with the data. The solution I came up with was to try to buffer the information.
— Start technical description —
To display something on the screen is often much slower than generating the information you want to display. The process of buffering allows you to generate the content and print it to an intermediate “buffer”, then print it to a screen all at once. The idea is that it’s much faster to print more information once than it is to print small bits lots of times. Wikipedia has more information of buffers.
— More technical description —
When I say “printing” I’m kinda lying. JavaScript and HTML don’t exactly have the low-level console-type printing that C has (printf() anyone?). Ok. Lying again. There is write(), but it doesn’t really work well for any purposes beyond very simple printing. JavaScript uses a property called .innerHTML. Ok. Moving on.
— End technical description —
Now, I had always assumed that buffering wasn’t really necessary when printing HTML code to the document. I thought that the data that’s being printed is so small that there isn’t really any need. However this changes as you add loads of information.
This is what was happening in our new widget. I didn’t think that buffering would change much, but when you’re talking 10-second cold-starts something has to be done. So, what I decided to do was set up a very-imformal experiment to test the effectiveness of buffering in a situation such as this. Here’s our situation:
- Printing out hundreds of lines of stuff through a loop.
- These lines have links.
- These lines also have dynamic content. I.e. content that is different for each iteration of the loop.
Based on these criteria, I created a test to see how well buffering works. I wrote a JavaScript function to run through printing 500 lines directly, and one to do it through buffering.
The results I got were pretty surprising. The un-buffered version took anywhere from 3 to 10 seconds to complete its task. The buffered version did it almost instantaneously.
Here’s the test files: the un-buffered version and the buffered one. Try it for yourself. (Disclaimer: only tested in WebKit. Gecko might do something completely different performance-wise.)