The most popular entry I've written at Near Infinity has been the JavaScript Particle Engine. It had limitations because I used transparent images and only made one color -- black. I recreated the fire demo for a talk -- Advanced Web Graphics with Canvas -- that I gave at the Rich Web Experience. I'll post the slides, sample code, and some more demos in upcoming entries.
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.
Wouldn't it be cool if you could do this?
@variables {
NEAR_INFINITY_ORANGE: #C96522;
}
div.header {
background-color: var(NEAR_INFINITY_ORANGE);
}
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.
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");
}
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"
This is a short tip that I found useful for testing complex JavaScript objects using crosscheck. For more information on crosscheck see my article on JavaScript Unit Testing with Crosscheck.
Testing instance methods can be a pain if the functions use instance variables and the object is heavyweight. In my case the constructor did a lot with the DOM that I didn't want to mock. Instead of invoking the function through an instance of an object, I called it statically.
Here we are, a couple years since Ajax was coined, JavaScript has become a language that people actually respect. The code being written now is better than ever before. Object-orientation, name-spacing, object detection, and correct scoping are prevalent now. The libraries available (prototype, jquery, yui, dojo) are very well written. What is the next step to improve code quality? If you want my opinion, it's Testing. Otherwise, here's the door. :)
Starting a backup routine is hard. I wanted a backup solution that did the following:
- Runs automatically every night
- Backup OS X resource forks correctly
- Maintain creation/modification times for backup files
- Make checkpointed-incremental backups
It seems that Encytemedia was successful in their "Call for Prototype Documentation" blog posted in the old year.
The site lives at prototypejs.org and should help new and experienced users alike master the popular JavaScript library.
Features
- API of all extended and new objects with examples
- Tips/Tutorials section that includes how prototype works
- Easy method for users to contribute
Good work guys!
Looks like Joe Hewitt has been busy.
Firebug now has it's own site at getfirebug.com. The new site shows the features for Firebug 1.0 which seem like a giant leap in functionality from the current 0.4.1. My favorites look to be the new profiler and the network activity view (shown right).
The catch? According to Hewitt's blog, it might not be free. I know I would pay $15-$25, what about you?
Javascript particle Engine
I was at the No Fluff Just Stuff Software Symposium in Reston, VA this past weekend and had some time in between sessions to work on something. As most of the people I work with know, I rarely code things that might actually be useful to someone in my spare time. So, I had no reason to attempt to rationalize the use for a particle engine in Javascript.
I think I've written a particle engine in almost every language I've used for an extended period of time. This includes python, java, objective-c, and c. What's surprising is that it has taken me this long to write a particle engine in the language I probably spend the most time coding in -- Javascript.
By the way, this is probably the worst particle engine ever created (TM), but it is written in Javascript, so give me a break. It doesn't support colors yet as I couldn't think of an efficient way to change the color of a png. I've only tested it in Firefox and Safari because I'm on a Powerbook. It's also pretty slow, in that it can handle only a dozen or so particles.
Here's an interesting bug in Internet Explorer I ran across today:
When using window.location to go to a named anchor inside of an iframe, using a String object versus a string primitive produces different results.Okay, it's pretty hard to explain, let's look at a demo. We need two source html files, a main outer page, and a page for the iframe.
the waiting game
No matter what apple says about Java development on the Mac, I always hated the waiting game before I could use some new Java API. First, it was Java 5 Tiger, which because apple ports it themselves to the platform, lagged considerably behind the Sun release. Then, it was Java3D and the JAI API. Even now, the Java3D API on OSX is at 1.3. I'm just glad that the JOGL and Java3d folks found a way to bypass Apple's porting process this time with Java3D 1.5.
Java3D is currently at 1.4.0 stable and has a 1.5 dev version out. The key to all of this is that the 1.5 branch includes the ability to use JOGL to bind the Java3D API to the native OpenGL implementation. What does this provide? Well, since JOGL is already ported to OSX, we can install Java3D 1.5 and JOGL and upgrade our outdated Java3D!
The problem..
If I had been allocated one Firefox extension to use, without hesitation it would be Joe Hewitt's Firebug. But, eventually, I have to test my code in IE (and Safari1), and need to debug some DOM or css scripting. Many times I would use the url field to execute Javascript in the page using this method...
javascript:function(){ /* some code */ }()
Wrapping the code in a function will prevent variable name collisions. The problem is that this method can get messy and time consuming when trying to inspect elements nested deep within the DOM.
