Today, we are really excited to be able to announce a big personal change. Ben and I are joining forces, full time, for the first time. What are we doing? We are joining Mozilla to create a new group with the charter to create developer tools for the Open Web.
Mozilla is placing a big bet, not only on us, but in the developer tools space.
Why are we doing this? Ben and I are passionate about a couple of things: compelling software and developers. In various roles in the past, we have built tools that attempt to make developers productive. We are huge advocates for the Open Web, yet we feel that tools are lacking on our collective platform. We want to help make a difference.
As we ramp up this new group, we will be looking at the problem and seeing where it makes sense to step in. We are going to be experimenting, and thinking about how to make developers lives better in different ways, so we aren’t expecting to see traditional tools come out of this group. Also, we don’t want to do this alone. We want to involve the entire community which is one reason that we are so excited to kick off this work at Mozilla. We believe that we have a unique opportunity to put developers first. We can build these tools in the open, with total transparency; the Mozilla way.
We respect the work being done by other vendors, and very much want to work together. We can’t wait to reach out early-on in the process, involving companies that believe in the Open Web like we do. Together we can drastically improve productivity, allowing developers to build compelling user experiences.
We are just getting started. As soon as we come up with some ideas, we will be sharing then with you and asking for community participation in various forms. You, the Ajaxian community, have been phenomenal over the years, and we can’t wait to do more together.
ZK 3.5, the latest version of the server-side Ajax framework, is out with a raft of new features. Three of those features really stand out for me:
Comet server push
Customization of look and feel
Performance monitoring
Server push via polling has been available in ZK for a while, and Comet in the ZK “Enterprise Edition,” but now it is available to everyone. And it is pretty easy to use: “The implementation of server push is transparent to developers. ZK chooses which implementation to use according to the edition of ZK automatically, but it is configurable.”
Customization of look and feel has gotten much easier. ZK has followed the example of a number of other frameworks in styling its widgets with predictably named CSS styles. Changing the look and feel of an application is now as easy as changing the ZK widget style sheet. Styles can further be overridden on a widget instance-by-instance basis.
Performance monitoring is perhaps the most exciting new feature. Client-side tools such as YSlow can guide optimization efforts and give you point in time performance snapshots. But critical applications need to be monitored and tracked end to end over their lifespan. With ZK 3.5, you now have the plumbing to instrument your application to capture five data points for each request:
T1, the time browser sends a request to server
T2, the time server receives a request
T3, the time server sends a request to browser
T4, the time browser receives a request from server
T5, the time the browser finishes processing a request
Internet Explorer 8 Beta 2 was released today. There are several cool UI enhancements that this beta brings to the table that I won't cover in this post, but you can learn more about them on the IEBlog. Instead, I want to talk about how beta 2 affects IE's relationship to web standards.
Also known as 'Dynamic Properties', CSS expressions are a proprietary extension to CSS with a high performance cost. As of Internet Explorer 8 Beta 2, CSS expressions are not supported in IE8 standards mode. They are still supported in IE7 Strict mode and Quirks mode for backward compatibility.
In case you don't know, CSS expressions were actual bits of JavaScript that you could run from CSS rules; this was commonly used to simulate the CSS max-width property for IE:
IE 8 beta 2 also now supports alternate style sheets:
Internet Explorer 8 now supports alternative style sheets as specified by HTML4 and CSS2.1. The alternative styles that are defined by the Web page author is available through the Style menu under the Page menu. The styles are also available through the Style menu under the View menu. The No Style option on either menu can be used to disable all authors styling.
In terms of the Known Issues with IE 8 Beta 2, the first is related to Ajax bookmarking and back button support and using window.location.hash to do cross-domain communication:
Internet Explorer 8 create entries in the travel log and back button for each instance of window.location.hash that is set. This is part of the behavior for Internet Explorer 8 AJAX Navigation. If you use this technique to communicate between documents, we recommend that you switch to the Internet Explorer 8 Cross Document Messaging feature that is based on Section 6.4 of the HTML 5.0 specification.
Finally, there are some issues with the onload event for IE's XDomainRequest object that helps with cross-domain communication:
The onload event may not fire reliably. We recommend you use the onprogress events which continues to fire as the data is received.
Unfortunately this is it for this release. You can see the full Beta 2 release notes, or download it yourself.
The XSS Filter operates as an IE8 component with visibility into all requests / responses flowing through the browser. When the filter discovers likely XSS in a cross-site request, it identifies and neuters the attack if it is replayed in the server’s response. Users are not presented with questions they are unable to answer – IE simply blocks the malicious script from executing.
Hi folks, this is my first guest blog post here on Ajaxian. It's great to join the team.
Gears, the open source browser plugin that teaches web browsers new tricks, has pushed out a new 0.4 release.
Andrei Popescu from the Gears team lets us in on some of the nifty new features:
We have added a new Geolocation API, which allows you to build applications that can do new and exciting things based on your users' location. You can query Gears for the user's current location using the getCurrentPosition() method or you can ask Gears to notify you every time the location changes, using the watchPosition() method. Of course, we take privacy issues very seriously, which is why we have a special permission dialog that allows users to decide which Web sites should have access to their location information. If you want to learn more about how the Geolocation API works, please see the Google Code blog post.
In addition, Gears now makes uploading large and multiple files on the web much easier, giving you the primitives to roll a resumable uploader, which means hopefully we can see custom desktop uploaders go away soon. In addition, Gears 0.4 introduces a new thing called Blobs:
Another cool new feature is the Blob API. Unlike strings, blobs let you reference arbitrary binary data — a first for JavaScript! Therefore, blobs can more naturally represent things like files and images, and they can be passed around efficiently. We have updated several existing APIs to work with blobs, such as WorkerPool sendMessage() and HttpRequest send(). And that's not all! We have also extended the Desktop API with a new method, openFiles(), which allows users to select multiple files of a particular content type, and then returns them as blobs for easy uploading or worker processing.
As a final note, Gears is continuing to push new features and experiments like the Geolocation API into the standards process:
Finally, an update on how we are doing on Web standards: in line with our earlier promises, the Geolocation API is a W3C Editor's draft and its current design is a result of open collaboration with many other people and organizations. We plan to continue to drive this standardization effort, as well as work with the community on new Web standards.
I decided to give the new Gears 0.4 APIs a roll to illustrate how powerful they are when put together, mashing them up to create a sample application. In addition, I needed a server-side implementation, so I created a Python server-side that runs on Google App Engine. This mashup is named Upload Movie Tool (not the most creative name, I know ;)
This demo allows you to select multiple movies, and then upload them in a resumable way with feedback using the Gears Blob and File System API. We also use the Geolocation API to figure out what your location is for tagging the video, and the Google App Engine to store everything on the back-end.
I put together a screencast where I run through the application. There is a bonus if you make it all the way to the end, with videos showing Dion and I using the new slide that was installed last week in the Google San Francisco office!
Flickr, Viddler, Qik, Pownce and Revision3 are the first services to support oEmbed, an easy way to allow embeding media from a certain URL in a third party site.
oEmbed is a format for allowing an embedded representation of a URL on third party sites. The simple API allows a website to display embedded content (such as photos or videos) when a user posts a link to that resource, without having to parse the resource directly.
This means that if you for example find a nice photo on flickr, you can take the URL and easily turn it into embed-able data:
I start with an aside; This must be the most un-Adobe website I have ever seen. Below is the entire website for the Open Screen Project:
As the site says, the details are in the press release which says:
The Open Screen Project is working to enable a consistent runtime environment -- taking advantage of Adobe Flash Player and, in the future, Adobe AIR -- that will remove barriers for developers and designers as they publish content and applications across desktops and devices, including phones, mobile Internet devices (MIDs), and set top boxes. The Open Screen Project will address potential technology fragmentation by enabling the runtime technology to be updated seamlessly over the air on mobile devices. The consistent runtime environment is intended to provide optimal performance across a variety of operating systems and devices, and ultimately provide the best experience to consumers.
The cool part of all of this, is the fact that the old restrictions on the SWF and FLV specifications are now in the past. The restrictions used to say that if you read the SWF spec, you couldn't build something that would run SWF files. So, could build an editor, a tool, but not a runtime in anyway.
This has just changed by:
Removing restrictions on use of the SWF and FLV/F4V specifications
Publishing the device porting layer APIs for Adobe Flash Player
Publishing the Adobe Flash Cast protocol and the AMF protocol for robust data services
Removing licensing fees - making next major releases of Adobe Flash Player and Adobe AIR for devices free
With news of OpenJDK coming at JavaOne next week, we will see changes with the most deployed runtimes out there. Just the beginning of the path towards an open source Flash.
I keep thinking of the JVM playing FLV/SWF, and the Flash player grokking .class files!
An easy to use and significantly improved Dojo API Viewer with some seriously great features, including the ability to easily find the original definition of a method that is “mixed-inâ€
Major improvements to Dijit infrastructure and widgets
All around Dijit theme improvements including the CSS structure for themes, refinements to the Tundra theme, re-introduction of the Soria theme, and the newly added Nihilo theme
DTL, the Django Template Language, is now available for use in widgets with dojox.dtl
Many improvements to the build system including CSS optimization, multiple-versions of the Dojo Toolkit co-existing in the same document, and other great tools for optimizing performance
What is next for Dojo 1.2?
On to 1.2, where the focus will be on continuing to refine Dijit, the Dojo Grid, Dojo Charting, a better approach to DojoX, and much much more.
Developers can customize and write their own applications by using the integrated scripting language Lua Server Pages, which is based on the super fast scripting language Lua. The server includes its own integrated database engine, thus making it possible to create configuration less database powered applications such as the CMS. The server also includes the Bindows Ajax framework.
The integrated scripting language Lua Server Pages (LSP) is similar to how ASP and PHP works. BarracudaDrive LSP applications are deployed as standard ZIP files. The ZIP files, which are in the "applications" sub directory are loaded and mounted as read only file systems by the web server. The server can also load "non deployed" applications. The "non deployed" Lua Server Pages (LSP) are compiled on demand just like PHP and ASP pages are compiled.
Aptana took over the RadRails open source project a few months back, and now have fully integrated it with Aptana Studio with the RadRails 1.0 release.
RadRails 1.0 runs as a plug-in to Aptana Studio. So in addition to all the Ruby on Rails IDE goodies and the integrated Rails shell command-line console, developers get the great HTML, CSS, DOM, JavaScript and Ajax features in Aptana Studio, which can run stand alone or within Eclipse to that all your other Eclipse tools can be right there as well.
The new version has a slew of new and enhanced functionality such as:
Rails 2.0 support
JRuby support
Bundled auto-installing gems for rails development
A Ruby profiler for Pro users
An RDoc preview view
Extended RHTML/ERb color preferences
Code completion for ActiveRecord model fields and finders
Code completion suggesting method call arguments
Significant expansion of code warnings and analysis, including syntax changes from Ruby 1.8 to 1.9
While this is not strictly Ajax or JavaScript related, it is noteworthy to point out that Sitepoint just released a HTML reference that is quite handy to have around if you wonder if what you are building is really HTML or just tagsoup.
Good HTML references are really hard to come by, either they are just listings, like W3schools.com or terribly outdated. Sitepoint have done quite a good job in listing all the HTML elements and categorizing them into different use cases. There is also a list of deprecated elements and attributes to avoid (which could be considered dangerous to still bring up as some of them are too handy to simply add to solve an issue) and a Microformats primer.
We know for a fact that other portals/article sites are working on similar projects and consider it a really good way of flushing old and outdated tutorials on things as simple but important as markup out of the search engine result pages.
The reference also gives a legend of browser support, something that so so far was only available on the German SelfHTML reference.
Yahoo's Tom Coates today finally released FireEagle at ETech 2008. Seeing Tom in the office for quite a while getting everything ready makes me very happy to announce that it is out and invite you to come along and sign up for the beta to start testing and - even more importantly - developing applications for it. This is FireEagle:
Fire Eagle is an open location services platform offering web, mobile, and desktop developers a simple way to build new location-based applications while also ensuring that consumers have complete control over their data, including how, when and where their location is made available. Want to easily make your site responsive to a user's location? Or, maybe you've found a way to capture someone's location and you want to find cool apps to plug it into? By doing the heavy lifting and connecting you to a community of geo-developers, Fire Eagle makes it easier to build location-aware services.
Once you got in you'll be able to download development kits in several languages including PHP, Python, Ruby and of course JavaScript. All the API calls are REST and the API authentication is handled via OAuth. The output format is either XML or JSON. The code is licensed with BSD and you can even contribute to the FireEagle source at a code repository.
The available API calls are:
user
Returns the location of a specific user in a location hierarchy format.
recent
Returns a list of users of the application who have updated their location within the given amount of time.
within
Takes a Place ID or a WoE ID and returns a list of users using your application who are within the bounding box of that location.
update
Sets a user's current location using using a Place ID hash or a set of location parameters. If the user provides a location unconfirmed with lookup method then Fire Eagle makes a best guess as to the user's location and updates.
lookup
Disambiguates potential values for update. Results from lookup can be passed to update to ensure that Fire Eagle will understand how to parse the location parameter.
The uses for a service like this are endless. From sensible search applications that show you places of interest nearby your current location up to real-life games of high-tech hide and seek everything is possible.
Topic: Q&A relating to Jonathan's development work with Adobe AIR, and questions regarding JavaScript, frameworks (PHP or JavaScript), or about freelancing.
This is definitely a good opportunity to pick the brain of one of the top professionals around.
After recently installing Snitter, I have to say I've become a bit of a fanboy of Jonathan Snook. The guy just produces some good stuff. So when I saw that he announced a new AIR application, I had to get it installed and checked out.
While Snoto (ya know, Snook, Snitter, Snoto) isn't as polished as Snitter, it's not meant to be. Jonathan has released this as a foundation for those that want to understand how to build AIR applications.
The goal of this is not to create a Flickr client that "does it all". It was put together as a reference application for anybody interested in learning more about Adobe AIR. Snoto has been released under a Creative Commons license, so it's available for you to take and extend how you wish. The link to the source code is included at the bottom of the Snoto page.
This is a great help to many developers as interest in Adobe AIR has skyrocketed since the release of AIR v1.0. MooTools developers should be especially pleased with the fact that Snoto was built using the MooTools JavaScript library, specifically because of the ease with which AIR applications can be developed without jumping through hoops. While other JS libs are now updated to work with AIR's security model, MooTools was the first to be compatible even during the beta process.
Again, the biggest benefit is to those that want to learn about working with the AIR API:
From the AIR API, I haven't gone hogwild but rather kept it simple. You can see use of nativeWindow, context menu and EncryptedLocalStore.
Having access to Webkit made styling the interface very straightforward. Like Snitter, it's a combination of background images, PNG images, and some CSS3/border-radius to round things out.
The Snoto page has been setup with an AIR install badge which should make it easy to check it out.
The Pownce team has been working hard to get their API up to speed and have gotten the API to a point where some cool applications can be built from it. Yesterday, they announced v2.0 of the Pownce API:
We’re sorry it took so long for us to release a complete API. We’ve taken great care to provide the best experience for developers and we hope the wait was worth it. Going forward, we’ll be working hard to keep Pownce the best social messaging application out there.
Well worth the wait, new features include:
Ability to post notes
Ability to post messages, links, files, events and replies
Ability to fetch lists of private and friends-only notes.
Integration of OAuth token-based web authentication.
This should open the doors for building new custom Pownce clients and applications similar to what's been done with Twitter.
In addition, the Pownce team has created a new application directory to showcase applications built by developers.
, Announcements
