Shonzilla, a pattern-seeking animal

Sun Oct 31

Command-line JavaScript beautifier implemented in JavaScript

Intro

In the the world of web programming where more things gets done in JavaScript, most of this JavaScript is directly available online. An exception is the server-side JavaScript like the one used in node.js or, less commonly known, in a OpenSocial container like Apache Shindig. Unless the license says otherwise, all this JavaScript code is free for anyone to download, fiddle with and fork/hack/improve/refactor.

For different reasons, the code is frequently post-processed in a way making it impossible to read. Enter JavaScript beautifiers. There’s plenty of them. However, they’re all on the web. Have you asked yourself “is there’s no command-line JavaScript beautifier?” so that you can most of the work from hacker’s favorite development environment. If you were looking for CLI JavaScript beautifier and haven’t found one, you came to the right page.

Ingredients

Here’s the DIY guide on how to create your own CLI JavaScript beautifier.

First, you’ll need a command-line JavaScript interpreter. Say Mozilla Rhino, JavaScript interpreter implemented in Java. I’ll assume you already have a working Java installation on your machine. Since Rhino works with any JDK 1.4 or higher, if you have any Java on your machine - you’re surely fine already.

Secondly, JavaScript beautifying itself is implemented in JavaScript just as most of the online JavaScript beautifiers rely on client-side process implemented JavaScipt. This JavaScript piece of the puzzle fits perfectly in the previous one - the JavaScript interpreter. I recommend jsbeautifier.org - JavaScript unpacker and beautifier since it’s the only I’ll use here as an example.

The last piece of the puzzle is a shell script to tie it all together.

DIY guide

Follow this steps to DIY:

Download the latest stable Rhino and unpack it somewhere, e.g. ~/dev/javascript/rhino
Download beautify.js which is referenced from aforementioned jsbeautifier.org then copy it somewhere, e.g. ~/dev/javascript/bin/cli-beautifier.js
Add this at the end of beautify.js (using some additional top-level properties to JavaScript):
// Run the beautifier on the file passed as the first argument. print( j23s_beautify( readFile( arguments[0] )));
Copy-paste the following code in an executable file, e.g. ~/dev/javascript/bin/jsbeautifier.sh:
#!/bin/sh java -cp ~/dev/javascript/rhino/js.jar org.mozilla.javascript.tools.shell.Main ~/dev/web/javascript/bin/cli-beautifier.js $*
(optional) add the folder with jsbeautifier.js to PATH or moving to some folder already there.

Usage

If you have the above script (jsbeautifier.sh) in PATH like I do, you can run it from any folder to format a JavaScript or JSON file by adding the file as the first argument:

jsbeautifier.sh some-minified.js

where you replace some-minified.js with some JavaScript or JSON file that no normal web developer wants to read.

Outro

I see no reason why wouldn’t the same technique repurposed for other JavaScript-based services currently only found online. Some ideas come to mind: JavaScript comressing/uglifying… maybe even running YQL from the command-line.

Note that I haven’t actually tried those nor checked if there are stronger dependencies on the client-side requiring more work to repurpose the JavaScript code from the web browser into Rhino runtime.

Tue Jun 30

Hilarious internet musical… well worth the watch!

Pop quiz: Does it remind you of some people you know? ;-)

[via CollegeHumor]

Sat Apr 25

OpenSocial interoperability with web 2.0 applications

A discussion recently started by Harry Hübner and commented by Christopher Blum in OpenSocial Interest Group I’m moderating over at XING, led me to a conclusion:
Supporting various applications (either web 2.0 or headless server functionality) inside an OpenSocial container can create more traffic (and revenue if they’re commercial) for application’s developers.

(Caveat: the conclusion is currently based on theory alone but sounds perfectly plausible once you read my explanation.)

Here’s my attempt to stand on Christopher’s shoulders and go into more detail. His proposition of “OpenSocial interoperability” by bringing various popular [web 2.0, headless] applications into OpenSocial containers is one of the ways to get more traction and traffic by using OpenSocial, which in turn could improve perceived interoperability.

This kind of interoperability can be best achieved using OpenSocial REST API which enables application’s home server to access selected OpenSocial container functionality. In this case, best-of-breed and widely adopted technologies are used: HTTP protocol for invoking container’s entry points and JSON for encoding data (read or written).

BTW, headless application can be any functionality on some server that runs or can run without a UI. For some examples of headless applications consider a Jabber or IRC server. You can let your imagination run free once you realize that this headless application can also be (almost) any application running in Amazon EC3, Google App Engine and other clouds. I’m wrote “almost” in parenthesis to include only those apps that understand REST, i.e. speak HTTP and understand JSON.

In more detail and related to OpenSocial, the scenario I’m supporting is the following:

using OpenSocial REST API to enable application’s home server read from and write into OpenSocial container to improve integration of application’s core functionality (running on server) by accessing OpenSocial data items like Person objects (e.g. users of XING, Orkut, MySpace, etc.) and AppData objects (which encapsulate all the specific object types relevant to the application’s core functionality). Using Person and AppData objects on home application’s server improves “social-awareness” of that application. Another part of this scenario is:
using OpenSocial Gadget XML and Gadget API to display socially-aware application’s data (accessed inside an OpenSocial gadget

Note that either part of this scenario or both 1. and 2. can be used to improve application’s interoperability.

In using part 1 of this interoperability scenario, the initiative for improving social-awareness of a popular application by using REST API to connect to OpenSocial container is in the hands of the original application’s developers. In the case of open-source application projects, there are less impediments and objective reasons not to connect open-source applications to OpenSocial container and, through it, all the users using the app. This way, data is not only more socially-aware but also more pervasive when part 2 is used.

When using part 2, application data is embedded into a “personalized web panel” running inside OpenSocial container thanks to Gadget XML, Gadget API and different features-specific APIs that are optionally supported by the respective OpenSocial container. The most interesting feature (i.e. OpenSocial JavaScript API namespace) is RPC feature (which stands for remote procedure call) that an OpenSocial container may implement (since it’s an optional API) to provide gadget-to-container, container-to-gadget, and gadget-to-gadget communication.

The final result of this interoperability scenario is better data availability and more convenience to users which can lead to an increased [web 2.0, headless] application’s usage.

The most prominent example of increased usage thanks to implementing OpenSocial (albeit implementing the entire OpenSocial container is more work than previous scenario) is Plaxo Pulse which got an order of magnitude

Fri Mar 20

Great stuff that your Google Chrome browser can do… most experiements won’t look as good or as fat in other web browsers.

Have in mind that everything is implemented in HTML, JavaScript and CSS. :-)

Verdict: this is one great viral marketing campaign!

Thanks to Raša for letting me know about this and bashing Tetris within a web browser as a bleak achievement. ;-)

Fri Sep 5

via www.google.com

Watch this comic explaining in detail features Google Chrome web browser.

Fri Mar 28

Design Coding by Poetic Prophet

Listen to the man rhyme! Yo!

Thu Feb 21

The new web browser Opera Mobile 9.5 looks (and works) great!

On a sidenote, sometimes project managers are not the best people to present their product (at least not to the general public). That guy might be considered cool by geek standards (for what he does) but certainly is not to your neighbour Joe or Jane who’d like to surf the web on their mobiles as well. :-)

What’s particularly interesting is the concept of Opera Widgets among which there are some that will surely keep any Facebook addict relaxed and happy.

In my view, mobile widgets are a very viable solution for small-screened mobile devices. What’s a mobile widget? Well, isn’t that a regular application that can be downloaded from a widget library that can be browsed from your desktop web browser as well.

[via DailyMotion]

Fri Feb 15

Every Web2.0 afficionado should have a look at this: Web Trend Map 2008.

The brilliant people at Information Architects selected nearly 300 of the most influential and successful websites and layered them over the greater Tokyo-area train map. Looks great and it’s a great reference too.

All of you Web2.0 addicts may use this as your del.icio.us 2.0. ;-)

You can download a PDF (A3 format) or check out the clickable online version. Within a week, you will be able to obtain a huge poster (A0 format!) version of it. You can preview its prominent features in detail too.

[via informationarchitects.jp]