One of the things I always want to do with online maps is rotate them – I am used to that with real, physical maps. As physical maps become a lot more clever these days (for example have you seen the zoomable map?) it is time we can do this with the online ones, too.
Whilst Google supports this in the satellite and hybrid maps, the basic ones still can’t be turned. Which is why I took CSS3 transformations (wrapped in a very useful jQuery plugin) and voila – rotating is possible:
James Coglan has ported a Ruby/EventMachine Comet server to offer a new Node.js server on the Bayeux protocol. The project is Faye and you can check out the code on GitHub.
I decided to come up with my own little quiz. I wanted to keep question not very obscure, practical, yet challenging. They would also cover wider range of topics.
There are fourteen questions in all, starting here:
eBooks have gone mainstream, and right now the open ePub format is getting a lot of attention, being the iPad's book format of choice. Often overlooked in gadget-centric media is the fact that ePub is based on web standards, and therefore amenable to being rendered in the browser, sans plugins. Pure Javascript ePub readers are starting to crop up, and Keith Fahlgren has written about several of them:
Just in the last few days, details emerged of two new JavaScript ePub readers, rePublish from Blaine Cook (@blaine) and JSEpub (screenshot) from August Lilleaas (@augustl). These two new readers join @liza’s epubjs, which will be a year old on Tuesday. An improved version of epubjs powers the ePub Zen Garden, which helps “dispel the myth that digital books can’t also be crafted works of visual design.”
All are open source, and as Keith notes in the comments, there's also the commercial BookGlutton project. BookGlutton (which we covered earlier) shows the promise of browser-based eBooks: it lets you embed books as lightbox-powered widgets, and supports annotation.
EPUB consists of three specifications:
Open Publication Structure (OPS) 2.0, contains the formatting of its content.[5]
Open Packaging Format (OPF) 2.0, describes the structure of the .epub file in XML.[6]
OEBPS Container Format (OCF) 1.0, collects all files as a ZIP archive.[7]
Basically, EPUB internally uses XHTML or DTBook (an XML standard provided by the DAISY Consortium) to represent the text and structure of the content document, and a subset of CSS to provide layout and formatting. XML is used to create the document manifest, table of contents, and EPUB metadata. Finally, the files are bundled in a zip file as a packaging format.
In the case of unzipping, Keith points out the inflate library has been around since 1999. One can imagine other applications for zip too; for example, it's often used as a format for bundling code (Java JARs, Python Eggs, Firefox and Chrome extensions), so reliable unzipping makes it possible to build browser-based IDEs and exploration tools against such archives.
It is quite interesting to see how technology moves in circles. With canvas being the new fun toy to play with for creating browser-based games we have to find solutions to fake a 3D environment to be really fast (sure there is Canvas 3D but it is overkill for most games). The trick is to dig into the tricks arsenal of old-school game development on machines full of win like the Commodore 64 or Amiga.
We have been long term fans of Román and the fantastic demos and samples that he puts together, usually involving CSS goodness. We messed up the other week though when we linked to his work on a scrolling coke can. I do these postings as a labor of love, and since Ajaxian isn't my day job, that means that the labor often happens at 2am. In this case I made the rookie mistake of grabbing an iframe to his demo so it would run inline. Román then looked up to see his servers getting pummeled and a bill is associated with that traffic. He quickly rick rolled us (thank you for not going for something much worse ;) and Christian Heilman (who is in Europe along with Román) saw it and kindly switched in an image of the code can effect.
I woke up the next morning to learn about this all and see a post that Román did talking about our hot linking. I immediately responded saying how sorry I am. I aim to highlight the great work that is done, not cause an issue.
Román is a great guy and kindly offered to collaborate and show friendship with Ajaxian (and myself) by putting together more amazing demos to share on the blog. Inline. Not hot-linking. :)
Here they are
These effects are CSS level 1 and 2.1 only. There is no javascript, css3 or whatever, just html and css.
They are all based on the CSS 2D displacement map technique that Román Cortés discovered when he created the infamous CSS Coke Can effect. Since displacement maps are very versatile, Román Cortés wanted to show us more and different applications of these.
This is simple displacement map usage to distort the borders of the prism, with a transparent .png image on top to add the shadows, orange semi-transparent bg and the Ajaxian's "a" logo. The background painting is an original artwork by Román Cortés. Move the area around to see the effect the prism has on the underlying painting.
There some comments in the original code can posting that the spinning direction was unnatural. So, here he did spin as the commenters wanted it. To make it possible, he had to mirror the label texture and adapt the source code.
By using several cylindrical displacement map layers with a growing radius and png transparent textures, it is possible to do voxel surface rotations like this one.
Thanks for Román for being so reasonable, and for creating such fun examples for us all. We hope to go deeper on the implementation of some of these examples in the future.
When I was a part of Mozilla Labs day to day, I always loved the vision and team behind Weave. I kept wanting the implementation to match the vision, but it is a tough problem and it takes time to bake. Well, it is getting there now.
Weave is special because it offers a series of back-end services (more than just sync) that are build with users (and their privacy) in mind, rather than business models. I have talked to a couple of entrepreneurs recently and thought that there ideas could be implemented nicely on top of Weave.
It is still early days, but I am jazzed to see the platform getting opened up. I am hoping to get clients for Safari, Chrome, and IE.... and look forward to a webOS client too :)
Aaron Boodman created Greasemonkey back in the day. He also worked on Gears. And most recently he created Chrome Extensions. I have a funny feeling that folks were pinging him daily "hey, when ya gunna give me Greasemonkey on Chrome" and he just delivered:
One thing that got lost in the commotion of the extensions launch is a feature that is near and dear to my heart: Google Chrome 4 now natively supports Greasemonkey user scripts. Greasemonkey is a Firefox extension I wrote in 2004 that allows developers to customize web pages using simple JavaScript and it was the inspiration for some important parts of our extension system.
Ever since the beginning of the Chromium project, friends and coworkers have been asking me to add support for user scripts in Google Chrome. I'm happy to report that as of the last Google Chrome release, you can install any user script with a single click. So, now you can use emoticons on blogger. Or, you can browse Google Image Search with a fancy lightbox. In fact, there's over 40,000 scripts on userscripts.org alone.
Not all of the scripts will work. The deeper the integration, the less chance of success. We now have user scripts supported in a variety of browsers, and hopefully they get more and more portable.
If browsers could surface the functionality to mainstream users, good things could happen beyond us power users.
A Googler and a Facebooker were in a pub discussing the complexities of building out a rich modern Web application. There are a ton of dependencies, and you need to be proficient in multiple languages and tools (JavaScript, HTML, CSS, SQL/NoSQL, backend languages, build tools, etc).
Well, they may not have been in a pub.... but a deadly duo did get together to try to solve this problem.
All of us on the Asana team have deep backgrounds writing rich web applications at companies like Google and Facebook. We've been continually frustrated by how long it takes to write software, and by a nagging feeling that in some deep sense we've been writing the same code over and over. Even when using the latest and greatest frameworks and disciplines, writing fast, highly interacting web applications involves a lot of accidental complexity:
First you need server code to figure out what data the browser needs. Hopefully you have an ORM layer, but you still need to carefully structure your code to minimize your backend dispatches, and you need to carefully keep that in sync with your front-end code lest you don't fetch enough data or hurt performance by fetching too much. If it's a Web 2.0-style app, you re-implement a ton of that server-side code in JavaScript, once for creating the page and then again as controller code for keeping it up to date and consistent. And when the user changes something, you bottle that up -- typically in a custom over-the-wire format -- and send it as an XHR to the server. The server has to de-serialize it into different data structures in a different language, notify the persistence store, figure out what other clients care about the change, and send them a notification over your Comet pipe, which is handled by yet more JavaScript controller code. Offline support? More code.
This is not a one-off task: it's rote work that adds complexity to every feature that you build in every application. By the time that you are done with all this, the important and novel parts of your application are only around 10% of your code. We wondered whether we could build a programming system in which we just wrote that 10% -- the essential complexity -- and a compiler handled the other 90%.
And this lead them to their solution:
Inspired by incremental computing, we're building Lunascript as a simple way to write modern web applications. Lunascript has a syntax and easy of use reminiscent of JavaScript, but a powerful pure-functional lazily-evaluated semantics historically confined to academic languages.
A Lunascript application specifes a data model and a function from the model to the view or user interface, annotated with handler functions from user inputs to model mutations. From this the Lunascript compiler produces a functioning Web2.0 application -- the client-side JavaScript, the server-side SQL, and everything in between -- complete with real-time bidirectional data synchronization. There's no need to write separate code to help the server figure out which values need to be sent to the client: the server can do this by simulating the UI. Because a LunaScript application only specifies how the UI should look given the current data (rather than how the UI should be updated as changes happen) it's impossible to write a UI that loads correctly but does not stay correct as changes are made.
"What does it look like?" I hear you cry. Time for a hello world, and since Comet is in the mix, that means a chat server:
You will notice the protobufferness at the top, and the fn of less characters, and E4X-like.
To learn more, let's listen in to Dustin as he gives us a walk through the world of LunaScript:
I talked to the guys and asked a few questions which they answered..... what questions do you have for them though? Are you excited about what a higher level abstraction could give you? Or do you like to be close to the metal?
The following post is a reprint from my personal blog. It is editorial in nature and even delves into random politics. I apologise. You can deal with it though :)
Steve Jobs didn't hold back when talking about Google and Adobe. That is great. Life is so much more fun when people speak their mind. I remember hearing a story when Sir Steve was asked why mac keyboards where the way they were. He grabbed a PC keyboard and started to rip out "stupid keys" (print screen, F keys, and the like) and swore a lot.
We love to paint with broad black and white brushes these days don't we? Whenever I hear people talking about Google being "evil" or not.... I sit back and think about how interesting it is that companies become "people", especially in this country.
Corporations are recognized by the law to have rights and responsibilities like actual people.
That may have been a convenient (and often almost genius) abstraction by lawyers, but it is screwed up. It feels like the times when you use inheritence in a way that isn't a ISA relationship, but it does kinda make the code nice. We have all done that, until we learned to favor composition. Corporations ISA Person? No. They are composed of them though.
I have been thinking about this ever since the recently surprise court decision the other day that "allows corporations and unions to pour unprecedented amounts of money into elections."
Lawrence Lessig had some interesting commentary:
The court decision does feel totally wonky to me. Right now, $ has a direct bearing on elections, and allowing multi-nationals (who have the money) to rain it down makes no sense.
Fun aside
My renaissance friend Graham Glass talks about how corporations can be considered a single conscious in his series on "the mind".
The issue with the vast number of corporations is that they are profit driven entities whose charter is to bring financial reward to shareholders. While you could argue that we as a species are driven by the selfish gene, corporations are driven by profits. Duh. Capitalism.
Google is a company. It is driven by this same goal. Now, there are various paths to a particular goal to make profits. Some companies sell things that kill people (weapons, cigarettes, etc). Others offer medical devices. All companies are not equal. Having spent time at Google, I do feel like the place isn't just an evil cult. The people that make up the consciousness were very driven strong willed people that cared about the company mission (universal access to information and all that) more than just the $. Sure some folks are focused on that. Also, although the wool could be placed over your eyes, the guys at the top of the chain have their hearts in the right place. While Larry and Sergey are there, decisions will be made that aren't solely based on profit. They want to create a different kind of legacy and company.
That being said, I think it is quite easy to fall into a trap such as:
If we do something here to block competition, we can make more $ and since we are Good Guys we can do better things with that money!
Google will sometimes do things that could be considered "evil" by some. That is life.
The good news with Google is that their search and ads business deals in a trust economy. It doesn't take much to switch from Google to Bing. Google knows that. Even though they have some HUGE advantages (technical [data centers, talent], brand, etc) the low barrier to change is huge.
Not all corporations are profit driven
I had the huge pleasure of working for Mozilla, which is a mission based corporation. Wow does that make life different. While you have to sustain yourself, it does mean that you think of the world very differently. You would rather go out in a blaze of glory doing something great for the mission, than just slowly die not doing much. Every choice you make .... you think of the mission.
It was interesting to work there knowing that I actually wouldn't want Firefox to be a 90% browser. You can fall into the similar trap as above and think:
We are mission based! If we had that domination we would use it for good!
But, not having that power in one hand is even better. Imagine working somewhere thinking "in my wildest dreams, the market would be shared somewhat evenly with the competition." The Open Web is amazing in that there is NO SINGLE VENDOR. If we are able to keep a decent balance between browsers (and thus the platform as we know it) then we have a balance of powers. Sure, in some ways you can't move as fast as a dictatorship, but there is a reason we don't want dictatorships in our government (even if the trains run on time!)
And, this brings me to the Adobe half of the Steve Jobs equation. Flash isn't dead. HTML5 is slowly going to put a dent into it if we ever get some of the use cases just right (e.g. video), but Adobe has a good penetration and can move at the speed of a dictatorship. The iPhone/iPad combo not shipping Flash will have an interesting dynamic here too, hopefully helping the HTML5 video cause. There is still much more work to be done. Flash and browser plugins have had a long history at forging new paths, and the Web can come in behind them and standardize. May that continue.
I do watch for single-owned platforms such as Flash, Silverlight, or now the Apple platform (even though they do great work on the HTML5 side of the house). I don't want any of those vendors to have too much power. The thought of a Web that required the use of their technology makes me shudder (we have a piece of that with Flash video). Right now I can turn off those plugins and life moves on. Sure I can't Hulu or Netflix, but that will change. I would miss some of the Flash sites that my kids use, but they could even be partially ported over to HTML5 these days.
I don't want to "kill" these other platforms as they offer competition and spur on the industry. I just don't want any one of them to take over. It may seem like the world would be better if we all just used Macs and iPhones and iPads, but would it? Do you think Steve would be a benevolent dictator?
Erm, no.
And thus I find myself torn. I really want to go out and by that iPad....... but when is it "too late". Surely I have a few years right? I can enjoy the shiny new toy? :)
What can you do if you want to enable a fullscreen experience on the Web? You can't. Or, use Flash. Some claim that you shouldn't offer this ability as it is a security liability. Someone can put a fullscreen view that tricks the user into giving it information.
However, as much as I think user security is important, it doesn't seem like we can punt and not do anything because of this. A user agent can do a lot of things to help out.
Some (majority?) of the use cases revolve around full screen video. Eric Carlson has a WebKit checkin that enables that one case. You can webkitEnterFullScreen() on a HTML5 video element and be on your way.
You can see this in action on the SublimeVideo HTML5 player. Play the video in WebKit nightly and alt-click the "full size" arrows.
Video is great, but what about general purpose? What if you could fullscreen any element? Robert O'Callahan threw up a strawman:
Should be convenient for authors to make any element in a page display fullscreen
Should support in-page activation UI for discoverability
Should support changing the layout of the element when you enter/exit fullscreen mode. For example, authors probably want some controls to be fixed size while other content fills the screen.
Should accommodate potential UA security concerns, e.g. by allowing the transition to fullscreen mode to happen asynchronously after the user has confirmed permission
While an element is fullscreen, the UA imposes CSS style "position:fixed; left:0; top:0; right:0; bottom:0" on the element and aligns the viewport of its DOM window with the screen. Only the element and its children are rendered, as a single CSS stacking context.
enterFullscreen always returns immediately. If fullscreen mode is currently supported and permitted, enterFullscreen dispatches a task that a) imposes the fullscreen style, b) fires the beginfullscreen event on the element and c) actually initiates fullscreen display of the element. The UA may asynchronously display confirmation UI and dispatch the task when the user has confirmed (or never).
The enableKeys parameter to enterFullscreen is a hint to the UA that the application would like to be able to receive arbitrary keyboard input. Otherwise the UA is likely to disable alphanumeric keyboard input. If enableKeys is specified, the UA might require more severe confirmation UI.
In principle a UA could support multiple elements in fullscreen mode at the same time (e.g., if the user has multiple screens).
enterFullscreen would throw an exception if fullscreen was definitely not going to happen for this element due to not being supported or currently permitted, or if all screens are already occupied.
Much talking of exact API issues and more security.... but hopefully inertia does it job and we get something.
As part of an upcoming article on geo location I am putting together a few Geo Toys for myself and here is the first one. Addmap.js is a JavaScript that analyses an elements text content, finds geographical locations and links them to Google Maps. It also adds a map preview and a list of the found locations to the element.
See addmap.js in action below - all the content in the green box is generated from the paragraph of text above it. You can try it out for yourself by clicking the screenshot.
Using addmap.js is easy - sign up for a Google Maps Key and provide it as a configuration parameter. Then call the analyse function with the ID of the element to analyse as the parameter:
The Freeciv.net crew has benchmarked a path in their canvas game. It is one data point, and tests more than just Canvas itself because a lot of code is running in the game. Thus, it ends up testing the union of a particular JavaScript path and the rendering of the canvas.
Here are the results:
With Bespin we had slightly different results, and the bulk of the bottleneck was in the blitting of the canvas. Optimizations were made to canvas over the initial phase of Bespin so the various browsers would leap frog each other. Good times :)
