I'm also working on something like the ToneMatrix or Tenori-on (Flash and actual devices, respectively) in pure HTML/JS. It works too, but the sounds aren't exactly designed to be great together (it's currently working on a C scale) and so if you're careful, you can get some decent sound but otherwise, it'll hurt your ears.
John Gunther has released GChart 2.5, a client-side library that adds a new canvas-rendering option for sharper, better looking, alpha-transparent, pie, line, and area charts.
John told us:
Canvas-rendering corrects GChart's most serious visual quality limitations (including the most often mentioned problem by its users: the banded-filled pie slice).
Coupled with its existing feature set and ease of GWT integration, the canvas-rendering option makes GChart an excellent choice for those who want to add basic charts to a GWT application without a lot of fuss.
To access these features, you'll need to plug an external canvas library into GChart (GWTCanvas in the gwt-incubator is reccommended) as described in detail in the setCanvasFactory method.
With the external canvas in place, the next step is to tell GChart you want a curve to be "continuously filled" by invoking setFillSpacing(0).
With each such continuously filled curve, GChart automatically exploits your external canvas library to improved the quality and speed of that curve's rendering. Specifically, banded-filled pie slices become solid filled, dotted connecting lines become continuously connected, and (the biggest stretch) bar charts become area charts. See the setFillSpacing method's javadocs for a detailed description of how each existing symbol type implements this new "continuously-filled", canvas-powered, rendering option.
Note that GChart's previous HTML-only rendering is still available, and is the default rendering mode if you don't bother to plug in an external canvas.
Paul Baukaus linked to jsescape, a little form that shows escaping and unescaping across a number of encodings.
Andrea Giammarchi had his own post on encodings in a different way.... as he talked about en-code which you can check out in action here on the page that lets you do simple encodings, especially for source code, in short order.
As preparation for an upcoming tech talk about Placemaker I thought it would be good to take a bit of the pain out of the geolocation service by making an interface for it. Placemaker works the following way: you post some content or a URL to it, it goes through the content or gets the content from the URL and analyzes it. It then finds geographical locations in the text and disambiguates them (for example to skip names like "Jack London" and not consider it the city London). Finally you get it back as XML.
The annoying thing is that Placemaker only support POST request and does not have a JSON output - for now. GeoMaker allows non-developers to enter some text or a URL, filter the results (using YUI datatable) to remove false positives (no system is perfect) and get the embed code for a Yahoo Map or a list of microformatted locations as copy+paste. See the screencast to get the end user experience:
Of course, every time you build something like that, red-blooded developers will ask for an API to do the same thing (and pointing them to Placemaker wasn't enough). So here it is:
http://icant.co.uk/geomaker/api.php takes two parameters: url of the web document to load and output which could be map, kml, microformats, csv, or json (with callback for JSON-P). Using this you can analyze a url in JavaScript and get the data back as an array:
Modernizr is a new library that detects various HTML5 and CSS3 features and lets you know so you can use them:
Writing conditional CSS with Modernizr
Now, once your page loads, Modernizr will run and go through all of its tests. It will automatically add all the classes to the <body> element of the page, and these classes will be along the lines of body.feature or body.no-feature, with the former indicating that the current browser supports that specific feature and the latter indicating that the browser does not support the feature.
Additionally, it will create a new JavaScript object in the global scope, called Modernizr. This object will contain properties for each of the features that Modernizr detects for, and their value will be set to TRUE or FALSE depending on the browser's support for it.
What you can do from this point on is write pseudo-IF/ELSE statements in your CSS. Let's look at an example from the Modernizr.com site itself:
In the above example, we're doing an "IF" condition in CSS: IF the browser supports both CSS gradients, THEN apply this background property to the #main element (instead of the original background property).
Writing conditional JavaScript with Modernizr
When leveraging Modernizr in your JavaScript, it's as straight-forward as it can be to do IF-conditions based on what the browser currently supports:
We are seeing a growth in these kinds of tools and shims to get HTML5 features into developers hands. Another great site to help is the new HTML5 Doctor.
It is great to feel the good vibes at Mozilla HQ today as we launch Firefox 3.5! It is always an interesting ride to see a browser develop, and realize how complex and large the work is.
Congrats to the browser developers out there who are working hard to make the Web better. With final versions of Firefox 3.5, Safari 4, and Chrome 2 out in the wild.... things are picking up nicely.
The Firefox 3.5 release is exciting for me because it really benefits the developers. We get Open Video, @font-face, cross site XHR, Geo Location APIs, CSS Media Queries, Native JSON, Offline support, Web Workers, and so much more.
And, the world keeps moving. I have seen some very cool things in the nightly tree, and look forward to beign around as the team works on the next great Firefox.
Watch the downloads come in with this cool download tracker that uses Canvas and SVG, all thanks to Justin Scott. The stats so far show that if the current rate trends hold we will beat the Firefox 3.0 download day, which is a surprise to all.
Sean Martell has created a nice wallpaper and persona to commemorate!
Kyle Simpson has developed LABjs, a library that lets you define your JavaScript file dependencies, and then loads them as efficiently as possible.
Kyle told us:
This project is a simple little tool (1.6k compressed!) for being able to load javascript files dynamically. It's like a lot of similar projects where the goal is to improve the speed of page load by allowing scripts to load in parallel. The thing it does slightly differently than most others like it is it allows you to "block", which is to say, load one or more scripts in parallel, then wait for them to finish, before going on to something else, like loading more scripts.
What I wanted was a pattern where I could load scripts in parallel, just like with script tags, but also block and wait if there was an explicit ordering dependency that required it.
What most loaders fail to do well is let you define "dependencies" simply based on loading order. With regular script tags, the browser blocks for you, so you can make sure for instance that jquery.js loads before jqueryui.js. But imagine you've got 3 scripts that can download in parallel (not dependent on each other), and then two more that need to wait for those 3 to load. You can't do that with script tags, and you also can't do that very easily with a lot of the script loaders/frameworks that I've found.
Most of them rely on intrusive concepts to do "dependency" management. For instance, each child script has to "signal" (callback) that it's done loading, to the parent page. Or the parent script and child scripts have to explicitly declare dependencies using some framework or conventions. Also, some other loader libraries rely on attaching a single load callback handler for EACH script. This makes it awkward or difficult to wait for several to load at a time, before proceeding, since you as the author have to keep track of what has loaded yourself.
jsLAB lets you load pretty much any script file, whether you control it or not, with no intrusion or convention for dependencies, other than the order and blocking that you define. It keeps track of what you've asked for and what has downloaded, only loads a unique script filename once, and lets you only define your handler once for a set of scripts that will load together in parallel. The API style (with chaining) makes is very easy to convert a set of script tags in your page into code to load them, without having to worry that race conditions will cause issues for scripts loading in the wrong order if there are implicit dependencies involved.
In the above example, "jquery.ui.js" and "myplugin.jquery.js" can load in parallel because there's no dependencies, but they will wait for "jquery.js" to load first, since they depend on it, and then "initpage.js" will wait for all of them to load before it runs, to it makes sure all code it will call is in place, similar to a $document.ready(...) concept.
The page link above also shows a few other variations on the .script(...) signature. For instance, you don't have to do a single script() call for each file (though I think it makes thing more readable). You can pass as many scripts singularly as parameters to one script() call. You can also pass an array of scripts, and it will loop through them and load them in the same way. Lastly, you can pass in an object instead of string, and the object literal can contain "src", "type", and "language" specifications, if you want to override the defaults of "text/javascript" and "Javascript", for some reason.
Summer is right around the corner - so before you make any vacation plans here's one quick action item to cross off your to-do list: Register now to lock in exclusive $300 savings for The Ajax Experience conference, September 14-16 in Boston, MA.
It's only been two weeks since we announced open registration for The Ajax Experience with the promise of additional sessions being added to the web site over the next few weeks. And while a number of your peers have already applied and taken advantage of the $300 early-bird discount (which expires at the end of next month), we've already added more sessions to our agenda, including:
The speakers and attendees at The Ajax Experience are working with the most advanced technologies today, building Ajax and rich Web front ends, as well as figuring out new ways to make response time still faster. And if security, performance, and SOA are important to you, you've come to the right place.
Your $300 discount expires the end of July - register now
If you have any questions about registration, traveling to Boston or bringing a team, please contact your Delegate Relations Manager, Jackie Anderson at janderson@techtarget.com or 781-657-1380. She's more than happy to assist you.
Developers tend to tease MySpace for its look, but the insiders are incredibly impressed by some of the engineering behind the scenes (e.g. their internal monitoring tools are said to be second to none).
They have surprised us again with their new tool MSFast which is "a browser plugin that help developers to improve their code performance by capturing and measuring possible bottlenecks on their web pages."
The IE 8 tools are getting better, but in general no one has been able to touch Firebug (and the new WebKit Inspector improvements) but this tool is actually plugin for IE! It captures a lot:
Measure the CPU hit and memory footprint of your pages as they render on the client’s browser
Review screen shots of the page while it renders
Review the rendered HTML on each point of the page’s lifecycle
Measure and show estimates of the time it takes to render each section of the page in different connection speeds
Validate the content of your page against a set of proven “best practice” rules of web development
Review downloaded files and show download time estimation on different bandwidths
That is some impressive data, and great to be able to test on IE where it has been SO hard to do so in the past.
What's new in scripty2? It is a complete rewrite, and comes packaged in three parts:
scripty2 core contains the main namespace and an area for extensions to be added. It also contains helpers and the like.
scripty2 fx: The scripty2 effects framework provides for time-based transformations of DOM elements and arbitrary JavaScript objects. This is at the core of scripty2 and presents a refinement of the visual effects framework of script.aculo.us 1.X.
scripty2 ui currently has one submodule: Utility functions for CSS parsing, color normalization and tweening.
We are doing more and more on the client, requiring nice programming models to do cool effects. Great to see one of the granddaddies of them all get a new coat.
We’ve spent a lot of time in this release cycle refining the core elements of YUI 3 — YUI, Node, and Event — to ensure that we have the right API going forward. Performance is improved, and we’ve refined our module/submodule structure. In some cases we’ve added significant new features, including intrinsic support for event delegation in the Event package; however, the focus is on moving the base library to production quality.
Several YUI 2.x components make their YUI 3 debut in this release:
DataSource: YUI’s data abstraction layer provides a standard interface into data sets, regardless of the data’s origin (local, XHR, XSS, etc.) and format (JSON, XML, CSV, etc.);
ImageLoader: ImageLoader allows you to defer the loading of images that aren’t in the viewport when the page paints, throttling bandwidth usage and improving performance;
History: The History component gives you control of the brower’s back button within the context of a single-page web application;
StyleSheet: StyleSheet makes it easy to create and modify CSS rules on the fly, allowing you to dynamically style page elements with fewer repaints.
As part of the more granular packaging in the new codeline, we’ve created separate YUI 3 modules to house functionality that in YUI 2 was bundled with other components. Cache, DataType and DataSchema debut in this release; each of these used to be a part of DataSource.
To keep up to date, check out the roadmap and dashboard that the team keeps up to date.
We have been sandboxing JavaScript in iframes for a long time. The Web Worker API has the nice property that it doesn't have access to objects like document and the like, and just runs code that you can pass over to it.
With this, Elijah Grey has created an experimental jsandbox API that gives you an eval function that you pass in some code, and optionally input data, callback for results, and an onerror callback.
The WebKit Open Source Project provides a JavaScript test Suite dubbed SunSpider. According to the description on the SunSpider home page, “this benchmark tests the core JavaScript language only, not the DOM or other browser APIs. It is designed to compare different versions of the same browser, and different browsers to each other.” We at Medialets have found it to be one of the best attempts to measure real world JavaScript performance in a balanced and statistically sound way.
Medialets ran the SunSpider test suite in the following environments:
Safari 4.0.1 on a 2.0 GHz Intel Core 2 Duo White MacBook.
The MacBook results were used as a baseline for relative comparisons.
Mobile Safari on the iPhone 3G with iPhone OS v2.2.1
Mobile Safari on the iPhone 3G with iPhone OS v3.0
Mobile Safari on the iPhone 3GS with iPhone OS v3.0
The “Browser” app on the T-Mobile G1 with Android OS v1.5 (Cupcake)
The “Web” app on the Palm Pre with Web OS v1.0.2
Each device was fully restored and rebooted immediately before running the test suite. Every attempt was made to assure that no atypical background tasks were executing while the tests were running. The SunSpider tests automatically run five times sequentially and the mean average from all five tests are reported. Network speed and latency have no effect on the results of the test.
We all know to beware of benchmarks, but it does show off how powerful these devices are getting!
