A JavaScript and Web Application Blog by Matt Snider

It's Been Great, Thanks!

Sun, 05 Jul 2015 05:25:32 +0000

So long and thanks for all the fish, or as my Google colleagues would say, there will always be TowerFall. After eight years of running a web development blog, I᾿m finally accepting that I no longer have the time nor daily immersion with the subject matter to write meaningful articles. With my work on Android at Google, I am drifting farther and farther from actual web development, and think you᾿ll be better informed by other sources. As long as people are reading, I᾿ll continue to leave the blog up and respond to comments, but I won᾿t be contributing new articles. For those who want to stay up-to-date with the latest information, I recommend the https://cooperpress.com/ weekly emails. In the future, as I start new endeavours (or update existing ones), I᾿ll update the site to include them. And who knows, maybe one day, I᾿ll have the expertise and the desire to write again. Thanks to every one of you readers for exploring web development with me over the years.

For Fun - Script to Rotate Wallpaper in Background

Thu, 04 Jun 2015 05:19:26 +0000

This is a fun little script that I wrote to rotate the wallpaper on my linux (ubuntu) machine. While not strictly on topic, you can use this as a template for your own scripts, such as those that monitor for file changes.

How do it…

We need two files, one to periodically rotate the wallpaper and the other to start the rotating script in the background and exit. But first, setup a directory to put your wallpaper pictures in:

mkdir -p ~/Pictures/wallpaper

Here is the background script to change the wallpaper periodically (put in a file named rotateWallpaper):

#!/bin/sh

WALLPAPER_DIR=~/Pictures/wallpaper

while true
do
    image=`ls $WALLPAPER_DIR | shuf -n 1`
    echo "Changing to image $image"
    gsettings set org.gnome.desktop.background picture-uri "file://$WALLPAPER_DIR/$image"
    sleep 60
done

This is the wrapper script to run rotateWallpaper in the background (put in a file named launchWallpaper):

#!/bin/bash

if [ ! -f /tmp/rotateWallpaper.pid ]; then
  PROGRAM=/usr/local/google/home/msnider/bin/rotateWallpaper.sh
  echo $PROGRAM > /tmp/rotateWallpaper.error
  nohup $PROGRAM 2>/tmp/rotateWallpaper.error 1>/dev/null &
  PID=$!
  echo $PID > /tmp/rotateWallpaper.pid
fi

exit 0

Make sure both files have execute permission for the current user:

chmod u+x ~/bin/rotateWallpaper
chmod u+x ~/bin/launchWallpaper

Then call launchWallpaper from someplace that loads when your machine starts up. I add the following to my bash .profile:

#...
~/bin/launchWallpaper
#...

How it works…

There are a lot of ways to launch a script on startup (do a quick google search), but I choose to use my bash profile, because I always open a terminal on my machines. The launchWallpaper script will be called each time a new bash profile is started (such as opening a new terminal window), so the script needs to keep track if it is already started. For that reason the process ID of rotateWallpaper is stored as /tmp/rotateWallpaper.pid. The first thing launchWallpaper does is check for the existence of the PID, only continuing if it doesn’t exist yet. This file will be automatically deleted when the machine is rebooted. Manually delete it if you terminate the PID and want to restart the script. The launcher script then executes rotateWallpaper, sending errors to /tmp/rotateWallpaper.error (also cleared on reboot) and standard output to /dev/null. The rotateWallpaper is launched using nohup, so it keeps running if terminal is closed, and using (&) to put it in the background. The $! command is used to fetch the PID of the last run script and stored as /tmp/rotateWallpaper.pid. Lastly, launchWallpaper exits without an error, so that whatever calls it is not blocked. The rotateWallpaper script runs indefinitely with a sleep (specified in seconds) between each execution. To find an image the code lists every file in the wallpaper directory and randomly chooses one (don’t put anything else in that directory or errors will ensue). The gsettings is a gnome command that switches the wallpaper from the command line and is available on ubuntu. Unfortunately, the gsettings and shuf commands don’t work on OSX, and none of this will work on windows. If you have similar scripts for other environments, please post in the comment section ^_^

There’s more…

Not interested in a script to rotate you’re wallpaper, but still want to learn something from this article. Well, there are a couple of good take aways. First, having a wrapper script to fetch and store the PID of a long-running script is very useful and something that unix processes have been doing forever. Second, by starting the rotateWallpaper script is the background and exiting without error from the wrapper script, we’ve successful put the long-running script in the background until reboot or it is manually killed. Together these two techniques can be used to start servers, run monitoring scripts, and many other useful tools.

Things Web Application Monitoring Can Pick Up From Casino Security

Mon, 18 May 2015 06:20:03 +0000

Security exists in order to protect the important things. While network security is constantly being upgraded in order to fend off attackers, it could actually learn a lesson or two from the surveillance of a casino floor. Web-based security, especially for pay-to-play sites, uses multiple layers of protection. Betfair, currently the biggest Internet betting exchange, is one of the providers that use a 2-step authentication, intrusion detection systems, and other methods of security in order to solidly protect their customers. Unfortunately, sometimes, not even the strongest protections for sites are enough to prevent hackers from gaining illegal access and that is because of how threats are currently being handled by programmers. The difference between web applications security and casino surveillance is this: when there’s suspicious activity, web applications tend to shut down ENTIRELY until programmers can identify the extent of the damage or the data that have been compromised. Casinos, on the other hand, handle the situation differently. Instead of the management shutting down the entire casino, it tries to contain the threat quietly in order to not upset or disturb its other patrons. If casinos operated similarly with web applications, its popularity would immediately decline and would probably be out of business soon. When a site is hacked and reported by the global media, people tend to stay away from it even if the site has been restored to normal. Response to threats is what web applications could primarily learn from casino surveillance. The problem is that data gathered by most web servers today isn’t enough for conducting incident responses. Most of the time, request and response procedures are excluded from logging, which is kind of similar to a broken communication between a host and a server. The paper written by Gunnar Peterson titled How to do Application Logging Right, is a nice manual that can be followed in order to overhaul the common procedure in gathering data by web servers today. To start improving the data gathering, web apps can act like casino cameras, which record all the data and store them for later use in case disputes happen. If there are any problems, casino management can simply review the tapes to help them identify the problem and culprit(s). In web application security monitoring, data gathering can be done through alert systems like AppSensor and then backed up with full audit logging. When someone deviates from the norm (like when someone is suspected of card counting at the blackjack tables or when someone inserts an unusual card in slot machines), the casino management looks at the surveillance camera closely and zooms in on the suspect. This is similar to web app firewalls that have automated profiling and security procedures for the expected web app behavior. So instead of completely shutting down operations, what web app security can initially do is increase the audit logging and mark suspects while recording the traffic. Web security shouldn’t only focus on completely eliminating threat without knowing what’s going on first. Hacks come in different forms and it’s better to have a closer inspection first on what they’re all about in order to have an idea how to counter them. It can be very dangerous to keep the enemy at bay without knowing what their plans are.

Simplifying Google Play Games API

Mon, 04 May 2015 07:47:38 +0000

Previously we covered Using Google Play Games on the Web and how Google Play Games services^[3] can be used for web games^[1]. There was a lot of interest on that article, mostly about providing UI components, which is a project that I have started, when I am not working on the refactor of Gaming Engine - Snake Demo v2. However, before building a UI, the API needed to be cleaned up, making the authentication easier and chainable callbacks without needing function nesting. The whole framework will be available on github^[2] as I work on it, but for starters lets explore version 0.1, The API Improvements.

How do it…

From Using Google Play Games on the Web we setup a page with the necessary meta tag variables and a login button:

<meta name="google-signin-clientid" content="YOUR_CLIENT_ID_HERE" />
<meta name="google-signin-cookiepolicy" content="single_host_origin" />
<meta name="google-signin-approvalprompt" content="auto" />
<meta name="google-signin-callback" content="YOUR_JS_CALLBACK_FUNCTION" />
<meta name="google-signin-scope" content="https://www.googleapis.com/auth/games" />

<span id="signinButton"><span class="g-signin"></span></span>

And then add in the following JavaScript from the github project^[2]:

<script src="{PATH_TO_JS}/underscore.js"></script>
<script src="{PATH_TO_JS}/api.js"></script>
<!-- This is dumb, but the callback function must be directly attached to window. -->
<script>YOUR_JS_CALLBACK_FUNCTION = GoogleGamesApi.authCallback;</script>
<script src="https://apis.google.com/js/client:platform.js"></script>

Using the following method to wait for authentication:

GoogleGamesApi.runWhenAuthenticated(function(oApi) {
  // Your code here.
}

Now methods on the API can be called to fetch data:

GoogleGamesApi.runWhenAuthenticated(function(oApi) {
  oApi.leaderboards.list(function(oResponse) {
    // Do something with the response.
  });
  oApi.quests.list(function(oResponse) {
    // Do something with the response.
  });
}

Or dependant requests can be chained on each other:

GoogleGamesApi.runWhenAuthenticated(function(oApi) {
  var oAchievementInstanceMap = {};
  var oPlayer;
  oApi.players.get(function(oResponse) {
    oPlayer = oResponse;
  }, {playerId: 'me'})
      .achievements.definitions(function(oResponse) {
        _.each(oResponse.items, function(oAchievementDefinition) {
          oAchievementInstanceMap[oAchievementDefinition.id] =
              oAchievementDefinition;
        });
      }).achievements.instances(function(oResponse) {
        _.each(oResponse.items, function(oAchievementInstance) {
          var oAchievementDefinition = oAchievementInstanceMap[oAchievementInstance.id];
          console.log('You have ' + oAchievementInstance.achievementState
              + ' the achievement ' + oAchievementDefinition.name);
        });
      }, {playerId: 'me'});
});

How it works…

The API is still a little rough, but I am pretty happy with how much easier it is to use than the original. The only part of the API that I am not happy with is integrating the authentication callback function with Google. Since the Google API requires the auth callback be attached directly to window and not another object on window (you cannot use GoogleGamesApi.authCallback directly). Consequently, GoogleGamesApi.authCallback must be set to a globally available variable and that global variable set to the google-signin-callback meta. When the user authenticates, Google will automatically call GoogleGamesApi.authCallback and it will handle authentication. Calling any of the APIs when not authenticated will throw an GoogleGamesApi.ApiUnauthenticatedException error. The GoogleGamesApi.runWhenAuthenticated should be passed a callback function, which will execute as soon as the API authenticates or immediately when already authenticated. The callback will be passed a single argument, the GoogleGamesApi object for ease of use, instead of forcing the developer to call the global variable (GoogleGamesApi). Inside the GoogleGamesApi.runWhenAuthenticated callback all API calls are available on oApi or GoogleGamesApi. These are the same object, so they can be used interchangeable, but be consistent. Calls to the API simply execute the underlying Google Play Games API. At the time of this writing, the first argument of all methods is the callback function (to pass the response into) and the second argument is an optional object for passing required/optional arguments to the Games API (these are defined on the API website^[3]). I point this out, because while this makes most sense now, I may change the API signature if it something else makes more sense after more adoption, so check the github documentation. If a required parameter is not included, the underlying Games APIs will throw an exception. Using the GoogleGamesApi object will make all API calls asynchronous, each returning as soon as the data is available. However, each API call also returns a new instance of itself, which can be chained (as shown in the last example). When chaining methods they use a promise-like system, waiting for the call to complete (and the callback executed), before running the next API call. This is useful when you have data in a dependant API call that references something from another API call (usually object definitions and instances, or a player object). This is one of the main failings of the Games API.

There’s more…

This is just the groundwork for building an Android inspired web UI. There is a lot to build still, and improvements to be added to the API layer. Some things that I expect to add soon are better authentication error handling (at least documenting a good auth recovery pattern), additions to the promise layer (such as a fail function), and possibly better caching. For the latter, the API currently leverages the browser URL caching, but there is probably room for an in memory map or a local storage technology. Anyway, there is loads more to come, but I wanted to start the project and share it with the community.

References

Using EMCAScript 6 Today

Sun, 12 Apr 2015 02:16:39 +0000

I have been avoiding writing about ECMAScript 6 (E6)^[6] for the past couple of years. This is mostly because the standard was not finalized, and consequently most browsers/engines were implementing different and often unstable versions of the various new features. With the E6 spec stabilizing almost a year ago now^[1] and the final release date scheduled sometime later this year^[1], I expected most browsers/engines would have implemented much of it, with bake time to work out the bugs. However, it has become obvious that I was overly optimistic^[2]. Nevertheless, E6 is coming and it’s time to start introducing some of the more supported features by beginning a series dedicated to the ECMAScript 6 features. For starters, lets discuss the state of the web and how to begin using E6 today.

How do it…

Most of the browsers have already begun to support some of the new features. In IE 11 and the technical preview, many E6 features are available without doing anything special. In Chrome, some changes like new syntax are widely available, but others like new bindings require that the block of code be in strict mode. And in FireFox, some features are broadly available, while others require a special script tag declaration. For the broadest support across all browsers, use the following:

<script type="application/javascript;version=1.7">// or version=1.8
(function() {
"use strict";
// Your code here
}());
</script>

Unfortunately, Safari is lagging behind the other browsers in supporting new E6 features. Additionally, Node.js only supports a limited features set. Consequently, an industry of precompiler/transpilers has sprung up to support E6 features in an E5 world^[3]. I have had some limited experience with the BabelJs^[5] compiler for writing E6 and converting it to E5 on the web. For server-side JavaScript, EchoJs^[4] comes highly recommended instead of using straight Node.js. When not using a precompiler, it is best to check out a compatibility table^[2] to make sure the target feature is available in your desired environments. Generally, developers should avoid using E6 features without a precompiler, but braver developers, who forge ahead anyway, are limited to a few syntax and binding changes.

In Summary…

Frankly, before doing some research I expected far more browser support by now, and am rather disappointed in the state of E6, both on and off the web. Without using a precompiler, iOS and Safari users will not be able to use websites driven with E6 technologies, so a developer would need to have E6 and E5 version of their JavaScript and switch the loaded script on availability of E6 features. This is rather undesirable, as maintaining two separate code bases for the same features is wasteful a engineering effort. Let me know about your experiences with ECMAScript 6 and its transpilers.