Wednesday, May 29, 2013

6 beeps of death!

My old dell laptop that I bought in December, 2009 has finally reached its pathetic end - the laptop beeps 6 times at boot (video card test failure), then sits there like a lump. It looks like there's no easy fix, so it's time to buy a new laptop. Ugh!

The timing is both good and bad. Good - because my last freelance contract ended a couple weeks ago, so I'm between projects right now, and not having a laptop for a few days forces me to disconnect (or borrow the wife's computer to add to the bLog ...). The timing is bad, because Intel's 4th generation Haswell chips aren't due for release until next week (June 4th) at Computex. Apple's WWDC opens June 10, so I need to wait at least one week to order a Haswell Windows laptop or two weeks for a Haswell Mac.

I still haven't decided exactly how I want to spec out the new box. I know I want at least 8GB RAM and a Core-i5 processor - preferably 4th gen. I'd rather have 128 GB SSD (really 256 GB would be great) than a 556 GB disk, and I prefer an ultrabook (no ethernet, firewire, DVD, whatever - just wireless and ports for USB-3 and display) than a traditional laptop. I think I'd rather have a Mac than Windows this time around - especially since people force Apple to monitor its environment impact and labor conditions in China (I'd be surprised if Lenovo or Asus care about that).

I'd also rather spend $1000 than $1500. I'm not sure if I can satisfy all my constraints! Anyway - I'll wait till next week - hopefully some new systems are released at Computex.

Monday, May 27, 2013

ant rules for typescript compile

I extended littleware's ant template with rules to compile typescript (*.ts) files in web projects using this ant-macro posted on stackoverflow. The typescript and yuidoc rules are listed further below.

Littleware's build system just extends netbeans' ant templates with IVY support. Netbeans' ant scripts are designed to support extension hooks that run before and after the different build stages (initialization, compile, package, ...). This is from the comment at the top of a new netbeans project's build.xml file:


    There exist several targets which are by default empty and which can be 
    used for execution of your tasks. These targets are usually executed 
    before and after some main targets. They are: 

      -pre-init:                 called before initialization of project properties 
      -post-init:                called after initialization of project properties 
      -pre-compile:              called before javac compilation 
      -post-compile:             called after javac compilation 
      -pre-compile-single:       called before javac compilation of single file
      -post-compile-single:      called after javac compilation of single file
      -pre-compile-test:         called before javac compilation of JUnit tests
      -post-compile-test:        called after javac compilation of JUnit tests
      -pre-compile-test-single:  called before javac compilation of single JUnit test
      -post-compile-test-single: called after javac compilation of single JUunit test
      -pre-dist:                 called before archive building 
      -post-dist:                called after archive building 
      -post-clean:               called after cleaning build products 
      -pre-run-deploy:           called before deploying
      -post-run-deploy:          called after deploying

...

Anyway - I'm glad for netbeans' extensible ant templates. Littleware's build system could benefit from another rework to better support scala and IVY, but it's good enough for now.

Finally - I also wanted to mention that Ian Obermiller posted on github a typescript brush for Alex Gorbatchev's syntax highlighter. It seems to work great ...

Here are those ant rules I mentioned earlier ...

<target name="config-check">
     <!--
    <available file="${ivy.jar.dir}/littlesettings.xml" property="settings.exists"/>
    -->
    <available file="${ivy.jar.file}" property="ivyjar.exists"/>
    <condition property="skip.download">
        <and>
            <isset property="ivyjar.exists" />
        </and>
    </condition>
    <available file="ivy/test" property="ivy.resolve.test.exists" />
    <available file="ivy/compile" property="ivy.resolve.compile.exists" />

    ...
    
    <condition property="ivy.resolve.exists">
        <and>
            <isset property="ivy.resolve.test.exists" />
            <isset property="ivy.resolve.compile.exists" />
        </and>
    </condition>
    
    <condition property="typescript.ready">
        <and>
            <isset property="build.web.dir" />
            <isset property="typescript.compiler.path" />
            <available file="${typescript.compiler.path}" />
        </and>
    </condition>    
    
    <condition property="ydoc.ready">
        <and>
            <isset property="build.web.dir" />
            <isset property="ydoc.path" />
            <available file="${ydoc.path}" />
        </and>
    </condition>    
    
</target>

<!-- web project stuff -->

<property name="typescript.compiler.path" value="${user.home}/AppData/Roaming/npm/tsc.cmd" />
<property name="ydoc.path" value="${user.home}/Documents/Code/yuidoc/bin/ydoc.bat" />


<target name="ydoc" depends="config-check" if="ydoc.ready" 
    description="run ydoc on build/ js"
    >
  <exec executable="${ydoc.path}">
    <arg value="${build.web.dir}/resources/js/littleware"/>
 </exec>    
</target>

    
<!--
    Recursively read a source directory for TypeScript files, generate a compile list in the
    format needed by the TypeScript compiler adding every parameters it take.
    Thanks Tekool.net:
       http://stackoverflow.com/questions/12799237/how-to-watch-and-compile-all-typescript-sources
-->
<macrodef name="TypeScriptCompileDir">

    <!-- required attribute -->
    <attribute name="src" />

    <!-- optional attributes -->
    <attribute name="out" default="" />
    <attribute name="module" default="" />
    <attribute name="comments" default="" />
    <attribute name="declarations" default="" />
    <attribute name="nolib" default="" />
    <attribute name="target" default="" />

    <sequential>

        <!-- local properties -->
        <local name="out.arg"/>
        <local name="module.arg"/>
        <local name="comments.arg"/>
        <local name="declarations.arg"/>
        <local name="nolib.arg"/>
        <local name="target.arg"/>
        <local name="typescript.file.list"/>
        <local name="tsc.compile.file"/>

        <property name="tsc.compile.file" value="@{src}compile.list" />

        <!-- Optional arguments are not written to compile file when attributes not set -->
        <condition property="out.arg" value="" else='--out "@{out}"'>
            <equals arg1="@{out}" arg2="" />
        </condition>

        <condition property="module.arg" value="" else="--module @{module}">
            <equals arg1="@{module}" arg2="" />
        </condition>

        <condition property="comments.arg" value="" else="--comments">
            <equals arg1="@{comments}" arg2="" />
        </condition>

        <condition property="declarations.arg" value="" else="--declarations">
            <equals arg1="@{declarations}" arg2="" />
        </condition>

        <condition property="nolib.arg" value="" else="--nolib">
            <equals arg1="@{nolib}" arg2="" />
        </condition>

        <!-- Could have been defaulted to ES3 but let the compiler uses its own default is quite better -->
        <condition property="target.arg" value="" else="--target @{target}">
            <equals arg1="@{target}" arg2="" />
        </condition>

        <!-- Recursively read TypeScript source directory and generate a compile list -->
        <pathconvert property="typescript.file.list" dirsep="\" pathsep="${line.separator}">

            <fileset dir="@{src}">
                <include name="**/*.ts" />
                <exclude name="**/*.d.ts" />
            </fileset>

            <!-- In case regexp doesn't work on your computer, comment <mapper /> and uncomment <regexpmapper /> -->
            <mapper type="regexp" from="^(.*)$" to='"\1"' />
            <!--regexpmapper from="^(.*)$" to='"\1"' /-->

        </pathconvert>


        <!-- Write to the file -->
        <echo message="Writing tsc command line arguments to : ${tsc.compile.file}" />
        <echo file="${tsc.compile.file}" message="${typescript.file.list}${line.separator}${out.arg}${line.separator}${module.arg}${line.separator}${comments.arg}${line.separator}${declarations.arg}${line.separator}${nolib.arg}${line.separator}${target.arg}${line.separator}--sourcemap" append="false" />

        <!-- Compile using the generated compile file --> 
        <echo message="Calling ${typescript.compiler.path} with ${tsc.compile.file}" />
        <exec dir="." executable="${typescript.compiler.path}">
            <arg value="@${tsc.compile.file}"/>
        </exec>

        <!-- Finally delete the compile file 
        <echo message="${tsc.compile.file} deleted" />
        <delete file="${tsc.compile.file}" />
        -->

    </sequential>

</macrodef>


<target name="typescript" depends="config-check" if="typescript.ready" 
    description="compile typescript files build/*.ts"
    >
      <TypeScriptCompileDir
          src="${build.web.dir}/resources/js/"
          module="amd"
      />      
      
    <!-- out="${build.web.dir}/resources/js" -->
</target>


<!-- post-compile rule kicks in if build.web.dir netbeans property is defined -->
<target name="-post-compile" depends="ydoc,typescript" if="build.web.dir">
      <copy todir="${build.web.dir}/WEB-INF/lib">
        <fileset dir="ivy/test"/>
      </copy>
</target>

Sunday, May 26, 2013

YUI modules with Typescript

I finally made time this week to play with typescript - a statically typed javascript extension developed at Microsoft. I like Typescript a lot. I prefer working with statically typed code for most applications, and Typescript also improves on javascript's syntax. I also think Typescript's approach to extending javascript while maintaining direct interoperability with existing javascript code (typescript can call javascript code directly, and vice versa) is better than the "rebuild the universe" strategy taken by dart and gwt.

I've enjoyed using yui in the few small javascript modules I've written (tracked in google code), so one of my first typescript tasks was to publish typescript code as a yui module, and to use other yui modules from typescript. I'm new to typescript, so the following explanation may be wrong, but here it goes.

Typescript supports modules via module, export, and import keywords. A typescript module compiles to either an AMD or CommonJS style javascript module depending on a compiler flag (the typescript specification covers all this). So a typescript file like this:


/// <reference path="yui" />
/// <reference path="toyA" />


export module littleware.toy.b {
    
    export import modA = module( "toyA" );

    export class Greeter {
        delegate:modA.littleware.toy.a.Greeter;
    
        constructor(message: string) {
            this.delegate = new modA.littleware.toy.a.Greeter( message );
        }
        greet() {
            return this.delegate.greet();
        }
    }
    
    export function runGreeter( greeter:Greeter ) {
        var button = document.createElement('button');
        button.innerText = "Say Hello";
        button.onclick = function() {
            alert(greeter.greet());
        }
        
        document.body.appendChild(button);
    }

}

Compiles as commonjs like this:


(function (littleware) {
    (function (toy) {
        (function (b) {
            var modA = require("./toyA")
            var Greeter = (function () {
                function Greeter(message) {
                    this.delegate = new modA.littleware.toy.a.Greeter(message);
                }
                Greeter.prototype.greet = function () {
                    return this.delegate.greet();
                };
                return Greeter;
            })();
            b.Greeter = Greeter;            
            function runGreeter(greeter) {
                var button = document.createElement('button');
                button.innerText = "Say Hello";
                button.onclick = function () {
                    alert(greeter.greet());
                };
                document.body.appendChild(button);
            }
            b.runGreeter = runGreeter;
        })(toy.b || (toy.b = {}));
        var b = toy.b;
    })(littleware.toy || (littleware.toy = {}));
    var toy = littleware.toy;
})(exports.littleware || (exports.littleware = {}));
var littleware = exports.littleware;

This is the amd output for the same code:

define(["require", "exports", "toyA"], function(require, exports, __modA__) {
    (function (littleware) {
        (function (toy) {
            (function (b) {
                var modA = __modA__;

                var Greeter = (function () {
                    function Greeter(message) {
                        this.delegate = new modA.littleware.toy.a.Greeter(message);
                    }
                    Greeter.prototype.greet = function () {
                        return this.delegate.greet();
                    };
                    return Greeter;
                })();
                b.Greeter = Greeter;                
                function runGreeter(greeter) {
                    var button = document.createElement('button');
                    button.innerText = "Say Hello";
                    button.onclick = function () {
                        alert(greeter.greet());
                    };
                    document.body.appendChild(button);
                }
                b.runGreeter = runGreeter;
            })(toy.b || (toy.b = {}));
            var b = toy.b;
        })(littleware.toy || (littleware.toy = {}));
        var toy = littleware.toy;
    })(exports.littleware || (exports.littleware = {}));
    var littleware = exports.littleware;
})

The yui module system expects a module to register itself via a call to YUI.add with a closure function that accepts a YUI instance variable "Y" to use as the root of the module namespace. A YUI module for our typescript code could be implemented using the amd definition something like this:


YUI.add('littleware-littleUtil', function(Y) {
    // call the lambda passed as 2nd argument to amd define
    lambda( Y, Y, Y );
}, '0.1.1', { 'requires' : [ 'littleware-toy-a' ] } );

I was able to hack something to incorporate the amd module-definitions output from the typescript compiler into a YUI module system - there are just a few tricks.

The first trick is to introduce our own global define method that connects the amd module definitions with the YUI module system:


function define( argNames, moduleThunk ) {
  var name = null;
  // hacky way to get the YUI module name ...
  try { moduleThunk( null, null ); } catch ( v ) { name = v; }
  YUI.add(name, function(Y) {
    var thunkArgs = [];
    for( var i=0; i < argNames.length; ++i ) {
      thunkArgs.push( Y );
    }
    moduleThunk.apply( Y, thunkArgs );
  }, '0.1.1' );

Second trick - the YUI.add call that registers a module's closure with YUI requires a module name. The hack I came up with is to call into the amd module-definition with null arguments, and add a block of code to the typescript that checks for nulls, and throws a "module name" exception:


declare var exports:Y;

//declare module littleware.toy.a;
if ( null == exports ) {
    // Hook to communicate out to YUI module system a YUI module-name for this typescript file
    throw "littleware-toy-toyB";
}

var Y:Y = exports;

This is a complete hack that exposes the javascript compiler output to the typescript code, but it works. The
var Y:Y = exports;
exposes the YUI instance "Y" to the typescript code. Juan Dopazo posted his node script that generates typescript type-definitions for YUI. I saved the output file he posted as "yui.d.ts", cleaned it up a bit, and included that in my build, so the type-script compiler can perform type-checking on YUI calls. I modified the typescript toy to take advantage of YUI DOM utilities just to verify all this module magic worked:

  var counter = 0;

  export function runGreeter( greeter:Greeter ) {
      var toyNode = Y.one( "div.toy" );
      var messageNode = toyNode.one( "p" );
      var button = document.createElement('button');
      button.innerText = "Say Hello";
      button.onclick = function() {
          messageNode.setHTML( "" + counter + ": " + greeter.greet()  );
          counter += 1;
      }

      toyNode.append(button);
  }

The "YUI.add" module registration includes options for specifying a module's dependencies on other YUI modules, but I prefer to specify that information in the YUI-load configuration that tells YUI which javascript file contains which module. I include that code along with my global "define" amd-hack function in a little bootstrap.js file that I include in the html host file via a <script> tag.

/*
 * Copyright 2011 catdogboy at yahoo.com
 *
 * The contents of this file are subject to the terms of the
 * Lesser GNU General Public License (LGPL) Version 2.1.
 * http://www.gnu.org/licenses/lgpl-2.1.html.
 */

if( window.littleware == undefined ) {
    window.littleware = {};
}

/**
 * littleYUI module, see http://yuiblog.com/blog/2007/06/12/module-pattern/
 * YUI doc comments: http://developer.yahoo.com/yui/yuidoc/
 * YUI extension mechanism: http://developer.yahoo.com/yui/3/yui/#yuiadd
 * Provides convenience method for loading YUI with the littleware extension modules,
 * so client javascript code just invokes:
 *      littleware.littleYUI.bootstrap()... 
 *
 * @module littleware.littleYUI
 * @namespace auburn.library
 */
littleware.littleYUI = (function() {
    
    /**
     * Get the YUI.config groups entry that registers the littleware javascript
     * modules with - YUI( { ..., groups: { littleware: getLittleModules(), ... } )
     * @method getLittleModules
     * @return dictionary ready to add to YUI config's groups dictionary
     */
    var getLittleModules = function() {
        return {
            combine: false,
            base: '/btrack/resources/js/littleware/',
            modules:  { 
                'littleware-littleUtil': {
                    path: "littleUtil.js",
                    requires: [ "array-extras" ]
                },
                'littleware-littleId': {
                    path: "littleId.js",
                    requires: ['anim', 'base', 'node-base', 'node']
                },
                'littleware-littleTree': {
                    path: "littleTree.js",
                    requires: ['anim', 'base', 'node', 'node-base', 'test']
                },
                'littleware-littleMessage': {
                    path: "littleMessage.js",
                    requires: [ 'io-base', 'node', 'node-base', 
                           'littleware-littleUtil', 'test']
                },
                'littleware-feedback-model': {
                    path: "feedback/littleFeedback.js",
                    requires: [ 'node', 'base', 'littleware-littleUtil', 'test']
                },
                'littleware-feedback-view': {
                    path: "feedback/FbWidget.js",
                    requires: [ 'node', 'base', 'littleware-littleUtil', 
                       'littleware-feedback-model', 'test']
                },
                'littleware-toy-toyA': {
                    path: "toy/toyA.js",
                    requires: [ 'node', 'base', 'littleware-littleUtil', 'test']
                },
                'littleware-toy-toyB': {
                    path: "toy/toyB.js",
                    requires: [ 'littleware-toy-toyA']
                }                                                
            }
        }    ;
    };

    
    /**
     * littleYUI - wrapper around YUI3 YUI() method that
     * registers local littleware modules.
     */
    var bootstrap = function () {
        return YUI({
            //lang: 'ko-KR,en-GB,zh-Hant-TW', // languages in order of preference
            //base: '../../build/', // the base path to the YUI install.  Usually not needed because the default is the same base path as the yui.js include file
            //charset: 'utf-8', // specify a charset for inserted nodes, default is utf-8
            //loadOptional: true, // automatically load optional dependencies, default false
            //combine: true, // use the Yahoo! CDN combo service for YUI resources, default is true unless 'base' has been changed
            filter: 'raw', // apply a filter to load the raw or debug version of YUI files
            timeout: 10000, // specify the amount of time to wait for a node to finish loading before aborting
            insertBefore: 'yuiInsertBeforeMe', // The insertion point for new nodes

            // one or more groups of modules which share the same base path and
            // combo service specification.
            groups: {
                // Note, while this is a valid way to load YUI2, 3.1.0 has intrinsic
                // YUI 2 loading built in.  See the examples to learn how to use
                // this feature.
                littleware: getLittleModules()
            }
        });
    };
    return {
        bootstrap: bootstrap,
        getLittleModules: getLittleModules
    };
})();


/**
 * AMB module hook - still needs work ...
 * @param argNames {Array[String]}
 * @param moduleThunk {function(requires,exports,import1, import2, ...)}
 */
function define( argNames, moduleThunk ) {
  var name = null;
  // hacky way to get the YUI module name ...
  try { moduleThunk( null, null ); } catch ( v ) { name = v; }
  YUI.add(name, function(Y) {
    var thunkArgs = [];
    for( var i=0; i < argNames.length; ++i ) {
      thunkArgs.push( Y );
    }
    moduleThunk.apply( Y, thunkArgs );
  }, '0.1.1' );
}

Anyway - that's a typical javascript mess, but it lets me bootstrap a javascript "main" in a new page with code like this:

   littleware.littleYUI.bootstrap().use( 
                'node', 'node-base', 'event', 'test', 'scrollview',
                'littleware-toy-toyB',
                function (Y) {
                    var util = Y.littleware.littleUtil;
                    var log = new util.Logger( "events.html" );
                    
                    log.log( "main() running" );
                    var toy = Y.littleware.toy.b
                    var greeter = new toy.Greeter( "Dude" );
                    toy.runGreeter( greeter );
                }
        );

Hopefully that makes some sense. I pushed the code up to the littleware repo I've been committing to lately. That repo is a mess, but feel free to take a look.

Friday, May 17, 2013

Updating Web-login for Javascript Webapp

I've been coding away for several days on some old web-login logic I had implemented in littleware to work in web applications with JSF-managed UX. I'm updating the code for use in apps where a javascript program manages the user experience. I've been thinking lately about the similarities and differences between the two application architectures.

The first difference between the two designs is in deployment. The old JSF architecture relied on JSF and JSP templates managed by the server, so I would usually bundle up the entire application in a .war file, and deploy it to some glassfish or tomcat or whatever container. The user interacted with the application by clicking links and submitting forms that moved the browser between web pages rendered by the server.

I'm trying to structure the newer code so that most client-side assets (javascript, CSS, hadlebar templates, ...) are served as static files from S3. The user's in-browser interactions with the application trigger events that are handled by javascript event-handlers. The javascript code running in the user's browser can access remote services via cross-origin AJAX requests. There are various CORS servlet filters open sourced online that take care of setting the HTTP response headers that browsers look for; today I grabbed this one posted by some Ebay coders to github - hopefully it works.

In the login code, both the old and new setups rely on a request filter (javax.servlet.Filter) to intercept unauthenticated client requests. The old code would intercept an unauthenticated page-load request, and forward the request on the server to a login page via RequestDispatcher.forward.

The new code intercepts unauthenticated AJAX requests to JSON services, and responds to the javascript client with an HTTP 401 (unauthorized) response, and relies upon the javascript code on the client to initiate a login process that eventually authenticates with the server by submitting credentials to a login AJAX service.

Finally - in the older applications I had the bad habit of tracking session state on the server via beans stashed in container-managed in-memory session. Tracking user data in-memory on a particular server required that a client continued to interact with the same server it began a session with. In-memory session state also made it difficult to partition a server's functionality between different endpoints. In other words - if I had a server that implemented some functionality "ABC", and I later decided that I would like to split the functionality on that server (or server cluster) between separate "A", "B", and "C" servers (or clusters), then it would be hard to do that if the code relied on shared in-memory session state.

Anyway, the new code avoids session state on the server - instead it relies on the client-side javascript code to track session state in most cases, and transient cookies in a few others.

In the end - I get to throw away a bunch of crazy server-side JSF beans and templates, and replace them with javascript modules and REST services.

Saturday, May 04, 2013

scala REPL classpath hack

While writing code I often want to take a quick look at the behavior of some class or module, and might wind up writing a short test program just to verify that some method does what I expect or that I'm obeying some DSL's state machine or whatever. One of the great things about Scala (and groovy, javascript, clojure, ...) is its REPL, which allows me to test little blocks of code without the hassle of compiling a test file.

Unfortunately, Scala's REPL launch scripts (scala.bat, scala.sh) do not provide command-line options for manipulating the REPL's classpath, so the REPL can't see the jars IVY assembles for my project ( javasimon, joda-time, guava, gson, guice, ... ).

Anyway - it's easy to just copy %SCALA_HOME%/bin/scala.bat (or ${SCALA_HOME}/scala if not on Windows - whatever), and modify it, so the REPL runs with the same classpath as your project, and at the same time set the heap size, logging config-file system property, and whatever else is needed. For example, here's the shell.bat launch-script from a project I was playing with recently.

@echo off

if not defined JAVACMD set JAVACMD=java.exe
if defined JAVA_HOME set JAVACMD="%JAVA_HOME%\bin\java.exe"

@rem echo "mojo:  .\runTestCase.bat 2>&1 | out-file output.txt utf8"


%JAVACMD% -Xmx1024m -Xms1024m 
   "-Djava.util.logging.config.file=%~dps0logging.properties"  
   -cp "%SCALA_HOME%\lib\*;%~dps0\lib\*;%~dps0\*;." 
   scala.tools.nsc.MainGenericRunner -usejavacp %*

The "mojo" line is a reminder to me that
bla 2>&1 | out-file output.txt utf8
is the Windows powersell equivalent of
bla > output.txt 2>&1
in bash shell - something like that. I'm terrible in bash, and worse in powershell, but I try to at least be able to send output to a file, grep, and run commands in a loop ... ugh!

Anyway - once the classpath is all set, then it's REPL playtime!

> .\cli\shell.bat
Welcome to Scala version 2.10.1 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_0
9).
Type in expressions to have them evaluated.
Type :help for more information.

scala> import org.joda.{time => jtime}
import org.joda.{time=>jtime}
                                                    ^

scala> val t = jtime.DateTime.parse( jtime.DateTime.now().toString() )
t: org.joda.time.DateTime = 2013-05-03T16:34:48.496-05:00

scala> import com.google.common.{io => gio}
import com.google.common.{io=>gio}


scala> val UTF8 = java.nio.charset.Charset.forName( "UTF-8" )
UTF8: java.nio.charset.Charset = UTF-8

scala> gio.Files.write( jtime.DateTime.now().toString(), 
         new java.io.File( "bla.txt" ), UTF8 )

scala> val t = jtime.DateTime.parse( 
      gio.Files.toString( new java.io.File( "bla.txt" ), UTF8 ) 
    )
t: org.joda.time.DateTime = 2013-05-03T16:37:35.561-05:00

scala>

Saturday, April 20, 2013

511 labor contraction counter app

I coded up a little 511 app to help track the duration and period of labor contractions. Childbirth extends over several hours for most women, so the rule of thumb for a woman trying to decide when to head into the hospital (or whatever) is to wait until after contractions occur every 5 minutes averaging one minute in length for one hour - the "5-1-1" rule.

Anyway - the "5-1-1" rule was news to me when I learned about it watching this goofy video where the expecting parents were tracking contractions on a pad of paper. I thought, "why don't they track the contractions on their smart phone?". Such a genius!

I poked around looking for a 511 app, and didn't find one, so I decided to take it on as a project. After I started a friend mentioned that there is an iPhone app - doh! By then I was already committed to the project. There's one for Android now too - ugh.

Anyway - in addition to demonstrating my complete incompetence in web design, the app allowed me to play around with some "HTML5" tech that is pretty cool. I used YUI - which I like a lot. The app is wired with a manifest, so our poor pregnant woman can pull up the app even when she's offline, and an apple-touch icon, so she can "pin" the app to her start screen as a standalone app.

Unfortunately, I made some newb mistakes too. I designed the app to just maintain its state in memory - assuming that when a user starts having contractions, then she'll pull up the app, use it until she goes into full labor or not, and that's that. I expected a webapp launched from the start-screen would maintain its state if the user switched between apps - the same way a browser tab maintains its state if the user switches tabs. Bad assumption! It turns out that a pinned webapp loses its in-memory state whenever the user switches between apps - at least the iPhone behaves that way. I went back and added code to save and restore the apps state to local cache, but it would have been better if I had designed the code to work that way from the start.

The app could of course benefit from several improvements. First, I currently have the thing wired to save state to local cache after every UX event, because I couldn't figure out how to detect a "user is leaving this page" event, and only save then. I recently found this thread on stackoverflow that describes the "leaving page" event, so I'd like to give that a try.

I'd also like to wire-up the app to somehow auto-suggest that the user pin the app to her home screen, and make that easy to do (it's kind of a hassle in Android Chrome for example). I'm pretty sure some apps do that kind of thing, but it may be more trouble than I'm willing to go through - we'll see.

Anyway - I'm pretty happy with how the project came out - even though the woman I built it for didn't use it, because her water broke (doh!), but the baby came out healthy, so all's well that ends well. The source code is online under my dev-clone of my littleware mercurial repo on google code - mixed in with a bunch of other code I've been playing with. At some point I started making breaking changes to the littleware code, so I forked off to that clone, but still haven't merged back to the main repo - which is stupid, because nobody uses that code but me. Anyway - I need to clean up the repo, and probably setup a clone on github - which is where all the cool kids track code these days, but I'll save that project for another day ...

Tuesday, April 16, 2013

paging s3 listObjects as a scala stream

One of Scala's fun features is its lazy list Stream class. I guess for a Haskell programmer a lazy list is not a big deal, but it's cool for the rest of us java, ruby, python, javascript, C#, ... programmers.

Anyway - I plan to host some web content on S3, so I've been writing some scala code using S3's java API to automate some tasks. One of the patterns S3 employs is to "page" large result sets, and scala streams provide a natural way to load the pages on demand - something like this:

      lazy val s3Listing:Stream[s3.model.ObjectListing] = 
          s3Client.listObjects( 
            new s3.model.ListObjectsRequest( folder.getHost, queryFolderPath, null, "/", null ) 
          ) #:: s3Listing.takeWhile( _.isTruncated ).map( (part) => s3Client.listNextBatchOfObjects( part ) )

Pretty cool, but, unfortunately, Stream has some quirk where its flatMap method can easily overflow the stack. For example - the following code for assembling the directories in a file system explodes:

          lazy val folderStream:Stream[jio.File] = new java.io.File( folder.path.getPath ).getCanonicalFile #:: 
            folderStream.flatMap( (d) => { d.listFiles().filter( (sd) => sd.isDirectory ) } )

We can construct a stream, and avoid calling flatMap with a recursive method that manages its own stack.

          def depthFirst( stack:List[jio.File] ):Stream[jio.File] = {
            stack match {
              case head :: tail => {
                  head #:: depthFirst( tail ++ head.listFiles.filter( _.isDirectory ) )
              }
              case Nil => Stream.empty
            }
          }

          depthFirst( List( root ) )

Saturday, January 05, 2013

Smart Phone, Dumb Person

I joined the community of annoying smartphone people with the purchase of my Motorola Atrix HD Android phone.

I'm very happy with the phone, but I was surprised by the weird world of phone marketing I found when trying to decide which phone I should get. I started my search with a small set of requirements for the phone:

  • Android Jelly Bean
  • AT&T
  • preferably Motorola - just because they're based in my old home state of Illinois. I guess Apple and Motorola are the only American phone manufacturers these days.

Anyway - pretty simple, right ? What I expected to find was some web pages on the Motorola or AT&T web sites with a lineup of Motorola's Android phones something like the Apple Store's iPhone page. The iPhone has a great approach to marketing - there's just one iPhone product line with the flagship iPhone 5, and the older 4s and 4 available at a discount. I expected Motorola might similarly have a couple different phone lines based on size or feature set, and one or two older generations available at a discount. Sadly for Motorola - it turns out Motorola offers separate product lines for each carrier! I just found this page that nicely lays out their product lines, but I somehow didn't stumble upon that page during my phone search, and I was amazed by how many different (but very similar) phones Motorola designed and manufactured. Motorola's phone branding is crazy - RAZR is exclusive to Verizon (Verizon apparently owns the "DROID" brand trademark too from the old days where iPhone was AT&T exclusive), ATRIX is AT&T, Electrify for U.S. Cellular, Sprint gets the Admiral and Photon, Triumph for Virgin Mobile ... I think these are all actually different phones - not just the same no-brand phone with a different carrier logo.

Motorola's per-carrier marketing is just crazy. It's already hard for Motorola to distinguish itself from the other Android handset manufacturers (htc, Sony, Samsung, LG, ...); it's crazy that Motorola has to muddy down its own brand in some misguided strategy by the carriers to differentiate themselves from each other. Nobody switches from Verizon to AT&T (or vice versa) because one has a slightly better Android phone than the other.

Actually - it looks like Samsung might be in the same messed up phone-per-carrier boat. This carrier-branding mess must drive Google crazy. The iPhone was trail blazing in so many little ways that people forget (visual voice mail, apps, ...) - the unified (across carriers) "iPhone" brand was one I never considered.

scala 2.10 netbeans ant fix

I just upgraded the scala install on my laptop from 2.9.x to the latest 2.10.0 release candidate, and was depressed to discover that broke my crazy netbeans derived ant build scripts (ugh!).

> ant clean
Buildfile: C:\Users\pasquini\Documents\Code\littleware\WIP\littleware\webapp\lit
tleId\littleId\build.xml

config-check:

download-ivy:

install-ivy:

resolveIfNecessary:

-pre-init:

-init-private:

BUILD FAILED
C:\Users\pasquini\Documents\Code\littleware\WIP\littleware\webapp\littleId\littl
eId\nbproject\build-impl.xml:50: The following error occurred while executing th
is line:
jar:file:/C:/Program%20Files/Scala/scala-2.10.0-RC5/lib/scala-compiler.jar!/scal
a/tools/ant/antlib.xml:5: taskdef A class needed by class scala.tools.ant.FastSc
alac cannot be found: scala/reflect/internal/settings/MutableSettings$SettingVal
ue
 using the classloader AntClassLoader[C:\Program Files\Scala\scala-2.10.0-RC5\li
b\scala-compiler.jar;C:\Program Files\Scala\scala-2.10.0-RC5\lib\scala-library.j
ar]

Total time: 2 seconds

Fortunately - the fix was easy. Scala 2.10.x pushes some classes that its ant task depends on to a new scala-reflect jar file, so I added that to the classpath in one of the xml blocks in nbproject/build-impl.xml, and I was back in business:

        <property name="scala.compiler" value="${scala.home}/lib/scala-compiler.jar"/>
        <property name="scala.library" value="${scala.home}/lib/scala-library.jar"/>
        <property name="scala.lib" value="${scala.home}/lib"/>
        <taskdef resource="scala/tools/ant/antlib.xml">
            <classpath>
                <pathelement location="${scala.compiler}"/>
                <pathelement location="${scala.library}"/>
                <pathelement location="${scala.lib}/scala-reflect.jar"/>
            </classpath>
        </taskdef>

Anyway - scala 2.10 looks to be a great release. A lot of people are excited about the "macro" system, but I've been working with the new akka actors, and also look forward to playing around with the futures and promises APIs.

Saturday, November 24, 2012

National Dog Show

The National Dog Show was on NBC last night, and was a lot of fun to watch if you're a dog lover like me. It's great to see people with their pets in positive relationships, and having fun together.

Of course it's much better to adopt from a shelter or breed-rescue organization than to pay a breeder or (much worse) pet store for a dog or cat. So many beautiful animals are killed every year for want of a home - it doesn't make sense to pay money to add to the pet population rather than adopt an animal that needs a home. Many shelter dogs are purebreds or close relatives too. Anyway, the Humane Society has a great little article: "The Top 5 Reasons to Adopt".

Saturday, November 17, 2012

R.I.P. Twinkie

The NYTimes had an article the other day reporting the planned liquidation of Hostess under Chapter 7 bankruptcy. Management decided to throw in the towel blaming a a failure to negotiate a contract with one of its workers' unions.

Unfortunately the article did not cover Hostess' history of mismanagement including private equity backed mergers and debt loading (this Forbes article has more detail); so the article's comment stream collected many posts bashing the union.

I know nothing about Hostess or its history, but ignorance has never stopped me from offering an opinion - I'd never say anything otherwise. Here's a copy of the comment I posted to the article:

It looks like Hostess failed, because it failed to develop compelling products. Twinkies and Wonder were once trail-blazing brands. A popular snack can demand large markups, but today people don't want to eat twinkies at any price. Management deserves blame for failing to adapt to a changing market.

Many older companies (Sony, H.P., ...) suffer similar problems in their markets. The company has outlived its visionary founders, and is left to stock holders and M.B.A.s who see the company as a collection of assets to manage for optimal profit rather than a vehicle for realizing the founders' dreams.

Saturday, November 10, 2012

Running Windows 8

A couple weekends ago I took advantage of Microsoft's $40- Windows 8 offer, and have a spanking new operating system running on my workhorse Dell 1557 laptop.

Running W8 is like having a new machine! It's always fun to see what these monster software companies (Microsoft, Google, Apple) can crank out.

The OS does suffer from multiple-personality disorder. The "RT" personality for new full-screen apps is well suited for a touch-tablet user or a user that spends all her time in a single-window application - reading a web page or whatever.

Fortunately - W8 also still has its old "desktop" personality - which is where I spend most of my time when coding - switching between multiple open windows (IDE's, browsers, shells, control panel, ...).

For either environment - if you install Windows 8 on a standard (non-table or non-touch) laptop, then you'll want to become familiar with the new WinKey+ keyboard shortcuts. I was much more comfortable and productive with W8 once I became comfortable with the WinKey+Tab,C,L,R,X,Z shortcuts.

So W8 is a little bit of a Frankenstein with pieces of different creatures stitched together into a monster, but I like it. It's new, looks great, and is a brave first step in a new direction by Microsoft.

Saturday, August 25, 2012

scala companion package

I wrote a scala trait the other day with a "companion package" instead of the usual "companion object". I was pretty happy with how the code came together, so thought I'd write a quick post to my poor neglected bLog.

I often write a scala trait that defines an interface to some tool that manages access to a data repository or manipulates data in some way. I usually define the interface traits to different tools provided by some module "bla" in a "bla.controller" sub-package. I define bla's data model in a "model" sub-package, and classes that simply support a tool's interface in the tool's companion object, so something like this:

package bla
package controller

trait Tool {
    def get( id:String ):model.Data
    def search( query:String ):Tool.SearchResult
    ...
}

object Tool {
    case class SearchResult( query:String, matches:Iterable[model.IndexEntry] ) {}

    object SomeEnum extends Enumeration {
       val A, B, C = Value
    }

    trait Builder {
       var creds:Credentials = null
       def creds( value:Credentials ):this.type = {creds = value; this }
       
       var endPoint:URL = new URL( "http://default.end.point" )
       def endPoint( value:URL ):this.type = { endPoint = value; this }

       ...
       def build():Tool
    }

    /** Factory necessary if not running in IOC container - ugh */
    object Factory extends Supplier[Builder] {
        def get():Builder = internal.SimpleTool.Factory.get()
    }
}

Anyway - that pattern works great most of the time, but the other day I was working on a tool with several supporting types in the companion object, and the Tool.scala file was growing fatter than I like. Fortunately - it turns out we can accomplish the same semantics as a companion object with a companion package like this:

package bla
package controller

trait Tool { ... }

package Tool {
    // ...
    object Factory extends Supplier[Builder] { ... }
}

The companion package approach has the advantage that we can split out some of the types defined in the companion package to their own files, so we could have a bla/DataHelper/Factory.scala like this:

package bla
package controller
package Tool

object Factory extends Supplier[Tool] { ... }

The companion package can define "static" constants in a package object, and we can move the tool-specific implementation classes to its own bla.controller.Tool.internal package rather than the shared bla.controller.internal package.

Finally - changing companion object code to the companion package pattern does not require changes to client code (code that uses Tool) - just a recompile.

Anyway - I like the way things fit together with the companion package pattern.

Wednesday, May 09, 2012

Extra S3 log parameters with AWS Java SDK

Amazon web services' S3 REST API supports custom access log information by adding custom query string parameters beginning with "x-" that S3 ignores but logs. Unfortunately custom query parameters are not directly supported in the AWS Java SDK, so we were planning to drop down to writing HTTP REST code for a recent project that required logging of some custom client-session parameters.

I hate working with HTTP, so I was glad when we figured out a workaround. The trick we came up with was to register a custom RequestHandler with our instance of the SDK's AmazonS3Client. The RequestHandler is an internal class in the API, so it's not included in the API documentation, but you can download the source code to see its simple interface:

/**
 * Interface for addition request handling in clients. A request handler is
 * executed on a request object before it is sent to the client runtime
 * to be executed.
 */
public interface RequestHandler {

    /**
     * Runs any additional processing logic on the specified request (before it
     * is executed by the client runtime).
     *
     * @param request
     *            The low level request being processed.
     */
    public void beforeRequest(Request request);

 /**
  * Runs any additional processing logic on the specified request (after is
  * has been executed by the client runtime).
  *
  * @param request
  *            The low level request being processed.
  * @param response
  *            The response generated from the specified request.
  * @param timingInfo
  *            Timing information on the request's processing.
  */
    public void afterResponse(Request request, Object response, TimingInfo timingInfo);

 /**
  * Runs any additional processing logic on a request after it has failed.
  *
  * @param request
  *            The request that generated an error.
  * @param e
  *            The error that resulted from executing the request.
  */
    public void afterError(Request request, Exception e);

}

So the RequestHandler's beforeRequest method can add parameters to a Request before it is processed by the underlying HTTP engine. The only trick is to determine which parameters to add to a particular Request, but it's easy to extend the SDK's API-level request objects (like S3's GetObjectRequest) with subtypes that add application-specific properties, then check for for those subtypes in the RequestHandler via the getOriginalRequest accessor.

Oracle Google Comments

For some reason I was inspired today to post a comment on the NYTimes Bits bLog's post on the Oracle-Google lawsuit. I thought I didn't make it through the Time's idiot filter, but they actually put my comment online. Crazy. Here it is again:


I think Google got itself into trouble, because rather than simply build on top of java (write code with the java language and libraries), and contribute to the java community; Google decided to "fork" java to make its own language that is nearly identical to java, but with various differences (security model, libraries, bytecode) at a time (pre-openJDK) that java was not open sourced. Often non-UI code (networking, database, ...) written in java can be easily recompiled for Android's "Dalvik" runtime, so Google gained instant access to the java developer community and programming tools; but the two systems are not the same.

There's something slimy about what Google did - forking java for Android without respecting the time and money Sun invested. Sun Micro sued Microsoft years ago when Microsoft released a version of java with incompatibilities to improve java on windows. Google was very careful to never call Android's runtime "java" to avoid the issues Microsoft ran into, but everybody thinks of Android as running java. Google should have just bought Sun Micro when it had the chance ...

Oracle is slimy too for trying to insinuate itself into the Android smart phone and tablet market. Oracle and Sun didn't have the vision of Apple, or the skill to imitate Apple quickly like Google; so now Oracle is trying to sue its way into the market.

Anyway - the best outcome when two corporate monsters fight is that they both get cut up and bleed ... ;-)

Friday, April 13, 2012

Steve Jobs - what a jerk!

I read Isaacson's Steve Jobs biography a couple months ago, and really enjoyed the read. One thing that surprised me - although I guess it's well known - was what an asshole Jobs was. He was just a really mean and selfish guy a lot of the time.

Of course Jobs was an amazing success on many levels, so everyone forgives him for being a jerk, and many argue that his acrimony contributed to his triumphs. On the other hand, many people also espouse the "No Asshole Rule" of management - which also makes sense, but it's ironic that a typical supported of the no asshole rule is an asshole.

Anyway - I think it's healthy to have at least one asshole; otherwise you wind up full of shit.

Tuesday, January 31, 2012

iptables NAT port forward 443 (https) to 8443

I recently wanted to setup port forwarding on an Ubuntu Linux server (AWS EC2) to redirect https traffic (port 443) to a Tomcat server listening for SSL connections on port 8443. I really did not want to learn anything about UFW or iptables - I just wanted to setup the forwarding and get on with my day, so I proceeded to Google away and read man pages and finally figured out the following commands after learning more than I wanted to learn - which was a complete waste, because I'll forget it all anyway:

sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8443

sudo iptables -t nat -A OUTPUT -p tcp --dport 443 -o lo -j REDIRECT --to-port 8443

The first command adds (-A) a rule to iptable's PREROUTING table to redirect incoming packets bound for port 443 over to port 8443. The second rule adds a similar rule to the OUTPUT table that redirects packets outgoing to port 443 on the loopback interface (-o lo).

Of course there's another trick - those rules disappear on reboot unless we save them somewhere. If you're running UFW, then add the rules to /etc/ufw/before.rules. Otherwise one solution is to install the iptables-persistent extension (on Ubunutu: sudo apt-get install iptables-persistent), and save the rules to /etc/iptables/rules.v4.

I hate this sysadmin garbage ...

Wednesday, January 25, 2012

Simple Session Scope with Guice

I've been a big fan of the Guice dependency injection library for a while, but I missed support for session-scoped injection until I figured out a way to achieve the same effect using child injectors. I was inspired by the PicoContainer project that I stumbled upon several months ago. I haven't actually used PicoContainer, but it appears to actually be better thought out than Guice - implementing arbitrary dependency injection scopes and lifecycle management via hierarchies of IOC containers.

I had PicoContainer's hierarchy approach bouncing around in my head when I stumbled up Guice's createChildInjector method - which supports a similar approach to managing object scopes.

Long story short - I introduced the notion of a "SessionModule" that defines session-scoped bindings to littleware's module system in my development repository clone. Littleware's module system also uses OSGi in an unorthodox way to manage the application life cycle. I wish I would have known about PicoContainer earlier - it appears to implement a nice approach for a combined IOC and application life cycle container. At some point I need to take a look at Spring too - to steal ideas if nothing else!

Sunday, January 08, 2012

Youtube to the rescue!

I have this old yellow Kitchenaid blender that has been sitting in the cabinet collecting dust for the past year or so after the rubber coupler that mates the motor base with the pitcher's blade impeller melted when I left hot soup in the pitcher for too long. It was so frustrating to have this appliance with working motor useless from a melted piece of rubber - what a piece of garbage! I tried some ridiculous jerry rigs, tried to remove the part, googled "busted blender", and eventually just stuck the thing in a cabinet disgusted.

Anyway, happy ending, yesterday I was thinking again about the damn blender after watching America's Test Kitchen make some awesome gazpacho - trying to figure out how I could puree without a food processor or blender, when I decided to google "kitchenaid blender coupler" - something like that, and discovered a community of pissed off blender owners and their relief at discovering how to repair the busted rubber coupling! This YouTube video shows how to remove the part, and Amazon sells a replacement.

I'm waiting for my new coupler to arrive in the mail. I can't wait to give the repaired blender a try. It's like I'm getting a new blender for Christmas! I'll probably wind up blending my hand off or something like that now ... blood smoothie!

Thursday, November 24, 2011

Escaping Java classpath wildcard on Windows command line!

I had a ridiculous battle with a set of .bat scripts that I wrote to launch java command line applications on Windows. I'm working on a suite of related little tools that I bundle into a zip file with a bunch of .jar files under a /lib/ folder, and launch scripts under a /bin/ folder that each look something like this:

@echo off

if not defined JAVACMD set JAVACMD=java.exe
if defined JAVA_HOME set JAVACMD="%JAVA_HOME%\bin\java.exe"

%JAVACMD% "-Djava.util.logging.config.file=%~dps0..\config\logging.properties" -cp "%~dps0..\lib\*" run.my.App %*

So I'm trying to use the nifty java classpath * wildcard introduced with java 6, but I had a terrible time with windows insisting on expanding /lib/* in the shell regardless of how I tried to quote or escape the thing! I was driving myself crazy, when I finally got the genious idea to just add a semicolon, so /lib/*; doesn't look like a path to Windows Powershell or CMD (I guess), and the following works:

@echo off

if not defined JAVACMD set JAVACMD=java.exe
if defined JAVA_HOME set JAVACMD="%JAVA_HOME%\bin\java.exe"

%JAVACMD% "-Djava.util.logging.config.file=%~dps0..\config\logging.properties" -cp "%~dps0..\lib\*;" run.my.App %*

What an amazingly stupid waste of time!