This past weekend I attended the Silicon Valley incarnation of the Happy Hour global DART hackathon. On Friday night, there was a short presentation, pitches, and team formation. After dropping off one of my teammates at the Caltrain station, I was itching to code something in Dart as a ramp-up to the large amount of coding I knew I'd be doing on Saturday. I decided to port Stats.js to Dart.

Stat.js is a performance monitor that allows you to determine the frame rate and number of milliseconds it takes to render your scenes. It's a great tool to have when you are creating animations with Canvas2D or WebGL. Stats.dart is a more Dart-y version. It was completed in a couple hours on Friday night and Saturday morning thanks to Dart's familiarity.

To use it, instantiate a Stats object by calling new Stats() somewhere in your code and call the update() function in your render loop.

Below we can see screencaps of the FPS and MS calculations

As this was a quick hack, I will probably be continually cleaning up some things.

Github: https://github.com/jwill/stats.dart

There are some things I have seen in my developer life that have totally bewildered me. Some of these things were jarring just because of their newness, others never lost their feeling of being a bad idea. Whenever.js is one of the latter. Whenever.js, surprisingly not a testing framework, takes Behaviorial Driven Development (BDD) out of the testing realm and brings it into development.

Instead of writing simply JavaScript code, you get to write conditions, linking code, AND JavaScript code. Below is a behavior that does nothing by itself but describes the conditions under which you should change the text on a button.

    whenever('Click Me!').is('clicked').then('Change the text to "Clicked!"')

Next you have to link from the behavior to HTML elements. The following snippet links 'Click Me!' with an anchor tag decorated with a click-me class.

    whenever.definitions.add({
      'Click Me!': 'a.click-me'
    })

Finally, you need to define the action that will be taken, in this case changing text on a button.

    whenever.actions.add({
      'Change the text to "Clicked!"': function(){
        $(this).text("Clicked!")
      }
    })

Whenever.js is interesting in the respect that it can allow designers and product people who don't code to take a more direct role in UX. It could work well with small applications, I think it quickly loses its luster on a big application. The 9 lines of code listed above can be summed up in a one-linerr

    $('#a.clickme').click( function() {
        $('#a.clickme').text('Clicked!')
    });

I like the idea of whenever.js as a cool architectural project but couldn't recommend using it in anything but demoware.

Unsatistied by the ramp-up time and extra libraries needed to run my todo.txt lately+ add-on posted in the last blog post, I decided to write a CoffeeScript version for Node.js. I thought it would avoid the ramp-up needed for groovyclient and be faster to boot.

One of the good things about building on top of Node is that you have alot of libraries to draw upon. A quick Google search surfaced a libraries to parse and manipulate dates in a way similar to Groovy and another to produce colored console text, moment and colors reqpectively. Both of the aforementioned are available as npm packages. To run our script, we need to install the dependencies along with our todotxt-coffee package.

    npm install moment
    npm install colors
    npm install todotxt-coffee

We can see that much of the heavy lifting is done by the CoffeeScript library and most of the logic below is determining what and how to print it. colors decorates strings with a properties for a base set of colors and styling(underline, bold, italic, etc) but you can create your own as well.

   printTask = (d,r) ->
        console.log d.format('YYYY-MM-DD').green + r.yellow

    printTasks = () ->
        if project is undefined
            for task in todos.list
                date = moment(task.date().toString().trim())
                restOfLine = task.raw().substr(12)

                printTask(date, restOfLine) if startDate <= date
        else
                tasks = todos.byProject(project)
                for t in tasks
                    date = moment(t.date().toString().trim())
                    restOfLine = t.raw().substr(12)
                    printTask(date, restOfLine) if startDate <= date

This and my other add-ons live here

You may have read my posts about todo.txt (here and here) and know how much I like it. I was a little unhappy with the ramp-up time when running it in Groovy and wanted to see if I could get it faster. Also, though Groovy can be a crucial tool for Java developers, generally devs are more likely to have Node.js installed. It's the new hotness you know.

So I set about creating a CoffeeScript library for use with Node. This library closely tracks to todo.txt-gem in terms of features though it does change the function names to camel-case. When I'm less lazy, the following will find itself into a proper README file.

Installation

    npm install todotxt-coffee

Loading Tasks

    {TodoList} = require ('todotxt-coffee')

    # Instantiate list of Tasks
    tasks = new TodoList(["(A) stop +p +c", "@c @b blah +c"])

    # Load tasks from done file
    tasks = new TodoList("/Users/jwilliams/Dropbox/todo/done.txt")

Querying Individual Tasks

    task.contexts()     # => ['@context1', '@context2'] 
    task.date()             # => 'YYYY-MM-DD'
    task.priority()     # => "(A)"
    task.projects()     # => ['+project', '+project2']
    task.raw()              # => "Full text of task"

Querying Todo Lists

    tasks.byContext('@context')
    tasks.byPriority("A")
    tasks.byProject('+project')

It's on Github here.

Enjoy.

Even though I've only been using Todo.txt for a couple days, I've fallen in love with it enought to figure out how to write an add-on. Because it uses a lightly formatted text file, if you have a good grasp of String manipulation and File I/O, you are off to the races.

One of the add-ons that I installed with Todo is lately. It gives you a listing of the tasks you have completed in a certain threshold. I loved the add-on but my list is a combination of my work and personal tasks. I wanted a way to be able to grab the tasks for a specific project (mainly because my team has daily standups). So I decided to build an addon in Groovy.

Making Todo.txt invoke Groovy

The snippet below shows the code for the bash script that will execute our Groovy file. I took the lately script file and adding another argument to specify the project.

    #!/bin/bash

    action=$1
    flag=$2
    project=$3
    shift

    [ "$action" = "usage" ] && {
        echo "  Recently comlpeted tasks:"
        echo "    lately+"
        echo "      generates a list of completed tasks during the last 7 days."
        echo "      Optional argument (integer) overrides number of days."
        echo "      Optional argument (String) project name."
        echo ""
        exit
    }

    [ "$action" = "lately+" ] && {
             groovy ~/.todo.actions.d/lately+.groovy "$TODO_DIR" $flag $project
    }

The lately+ Groovy script runs by parsing the argument list and then working through the done.txt file line by line to see if the completed task falls in the threshold or is from the specified project.

Colored Text with JANSI

The JANSI project allows you to use Java to print colored text and use console effects like blinking and bolding. As opposed to having to bundle a jar I used @Grab to automagically download the dependency.

    @Grapes(
        @Grab(group='org.fusesource.jansi', module='jansi', version='1.8')
    )

JANSI works well inside print and println. You print text by grabbing a static Ansi instance, setting foreground/text (fg) colors and printing text with a. You can reset to default console colors by calling reset. The following snippet prints the date in green and the task description in yellow.

    println ansi().fg(GREEN).a(date).fg(YELLOW).a(" "+restOfLine).reset()

After I got a basic script working, I started to benchmark it. Whereas the old lately command runs in 0.044-0.069 secs, the Groovy version took between 2.078s for a warm JVM and 5.918s for a cold JVM. For a command that would be run once a day, this isn't totally awful but it's not fun. So I set out see if I could get it faster.

Speeding Groovy with GroovyServ

GroovyServ is a library that runs a Groovy server in the background with a fully loaded JVM. Its groovyclient keyword is a drop-in replacement for groovy. With GroovyServ, I was able to get the run time down to 0.274s to 0.338s. You do get a hit for initial startup of the JVM but that can't be avoided if you want to use Groovy. GroovyServ pipes your content to the server and back so you lose all of the formatting from JANSI, which is a bummer. Speed doesn't come at no cost.

Full lately+.groovy file

    #!/usr/bin/env groovy
    @Grapes(
        @Grab(group='org.fusesource.jansi', module='jansi', version='1.8')
    )
    import org.fusesource.jansi.AnsiConsole
    import static org.fusesource.jansi.Ansi.*
    import static org.fusesource.jansi.Ansi.Color.*
    /*
            Enhancement of the Lately add-on
            Adds the ability to specify a project

            Arguments:
            1. TODO_DIR
            2. Number of days (optional, default is 7)
            3. Project name (optional)
    */
    def dir, days, project

    dir = this.args[0]
    //Optional
    if (this.args.size() > 1)
        days = this.args[1]
    else days = 7
    if (this.args.size() > 2)
        project = this.args[2]

    // Get Done file
    def file = new File(dir+File.separator+"done.txt")

    def today = new Date().clearTime()
    def startDate = today - new Integer(days)

    AnsiConsole.systemInstall()
    println()
    print(ansi().fg(RED).a("Closed tasks since ${startDate.format('yyyy-MM-dd')}"))
    if (project != null) 
        print( ansi().a(" for Project: ${project}").reset())
    print "\n\n"

    file.eachLine {
        def line = it
        // Get date portion
        def date = line.substring(2,12)
        def restOfLine = line - 'x ' - date
        def d = Date.parse('yyyy-MM-dd', date)

        if (startDate <= d && project == null)
            println ansi().fg(GREEN).a(date).fg(YELLOW).a(" "+restOfLine).reset()
        if (startDate <= d && project != null && line.contains(project))
            println ansi().fg(GREEN).a(date).fg(YELLOW).a(" "+restOfLine).reset()
    }

    AnsiConsole.systemUninstall()

If you want to install lately+, just drop the two files (lately+ is the name of the bash script) into your ~/.todo.actions.d directory and provided you have Groovy on your path, you're off to the races.

One of the default settings in Ratpack is that it starts applications on port 5000. It's easy enough to override this but on several occasions I deployed several Ratpack apps in the same container and have one or more fail to deploy because the port was already in use.

A solution to this annoyance is to have Ratpack dynamically select a port instead of defaulting to 5000 as shown in the snippet below:

    def findOpenPort = {
        def port = new ServerSocket(0)
        def portNum = port.getLocalPort()
        port.setReuseAddress(true)
        port.close()
        return portNum
    }

Passing a zero to ServerSocket tells it to dynamically pick an open port. Once the port is opened, we grab the port number, tell Java that we want to immediately reuse the port without a timeout, and close the port.

Listed below is full example file. The first few lines download Ratpack and its dependencies from MavenCentral.

    @Grapes([
        @Grab(group='org.slf4j', module='slf4j-simple', version='1.6.4'),
        @Grab(group='com.augusttechgroup', module='ratpack-core', version='0.5')
    ])
    import java.net.ServerSocket
    import com.bleedingwolf.ratpack.*

    def findOpenPort = {
        def port = new ServerSocket(0)
        def portNum = port.getLocalPort()
        port.setReuseAddress(true)
        port.close()
        return portNum
    }

    def port = findOpenPort()

    def app = Ratpack.app {
        set 'port', port

        get("/") {
            request.toString()
        }
    }
    println "App loaded on port ${port}"
    RatpackServlet.serve(app)

Before the last week, my most recent task management system was a hodge-podge of Google Calendar events, notes written in a notebook, and QuickNote notes. Date sensitive things that were in QuickNote often were late as well as tasks when a good amount of details had those details overlooked when in Google Calendar.

About a week ago, I happened upon a task management system called Todo.txt. Having been familiar with its creator Gina Tripani, I had heard of the system but had never tried it. It seemed a little too simple to be able to work. Deep into a several month long "vi is my IDE" renaissance, I decided to give it a try.

Todo.txt uses a minialist command-line interface to manage your tasks. I can have my tasklist anywhere I am but most importantly I can reprioritize things, and mark them as done(something that my franken-system couldn't do well).

Need to get a list of tasks? Type,

todo.sh ls 

Need to create a task? Just type

todo.sh a "Task Description" 

Need to mark a task as done, type

todo.sh do [task number] 

This is only scratching the surface of its feature set. You can also categorize tasks into project (+ProjectName), add contexts(@whatever), or assign priorities with the pri command. Added features come from its add-ons. The file format is simple enough that I was able to make an add-on in a couple hours. If your programming language can do text manipulation and can be called from bash, you can use it for a add-on.

Since my switch, I've been able to better stay on task and have increased my productivity. I love it Todo.txt and can't see myself using anything else.

Hat tip by Jonathan Beri who just made his own circle management post.

At first, when you try to organize your circles I felt like I was (possibly inappropriately) judging people. But after realizing that only you can see your circles, I didn't feel so bad and saw it as a powerful tool to help me consume content.

The only overarching rule I have is to not put people in too many circles and stick to what I believe is their strongest characteristic or aspect in which I will interact with them the most. With the exception of a couple circles, I post mostly public and I use circles as a way to remember who the person is and context (I suck at remembering names but am great at faces).

Without further ado, here's my list with the common ones (Friends, Family, Colleagues, Acquiantences) omitted:

• StartupBus

  • Peeps Mostly participants from my year of StartupBus. It's here mostly to keep track of their new ventures.

• Peeps I met at confs

  • This is where I put people who may or may not work in an area related to my work. This is where I keep them until I interact with them enough to justify another circle. It's also where they stay if they don't post often on Google+.

• Eckerd

  • When you go to a really tiny college that is smaller than some high schools, you really bond together. If I found out you went to my alma mater, it's almost guaranteed that you'll be in this circle.

• Groovy Peeps

  • People that work with the Groovy programming language. Most fall into my Met in Real Life circle but I'm too lazy to move them over.

• Gaming

  • HTML5, Android, and iOS gaming peeps are filed here.

• Following

  • Strictly for brands, journalists, and (Internet) famous people

• Googlers & Xooglers

  • Googlers that work in my interest/work areas or that I've personally worked or broken bread with.

• Interesting People / Cool People

  • I have no idea where to put you but I like your content.

• Hidden

• Met in Hangouts

  • Met in Hangouts is my defacto water cooler circle. I have hung out with these people for literally hundreds of hours. Any goofy content that might be too crude for public gets shared here.

• Met in Real Life

  • Thanks to HIRLs, most of my Met in Hangouts circle is here too. About half of my Googler circle could be here to but I'm too lazy to copy them over.

• French

  • All the Francophones

• Fitbitters

  • People with Fitbits and post fitness stuff

About a month ago, there were a couple of posts about making an autocomplete solution using tries. Inspired by it as an interesting engineering problem I decided to use the Python code from this post and create a solution with Groovy and Ratpack for a hack day at work.

A trie or prefix tree is a tree structure that generally stores string data. In the figure below, we can see a basic example of a trie that stores airport codes. Typing the characters in a node will return the children. For example, in the figure below, if I type the letter b, it should return BOI, BOS, and BWI but if I type "BO", it should return BOS and BOI.

For a seasoned developer, porting Python code to idiomatic Groovy is a breeze and I'll leave you to check out the zipped source or the original article which explains the insertion and lookup code very well.

Instead I'm going to focus on the steps needed to run it in Ratpack.

In my application class, I used JSON data from http://airports.pidgets.com/v1/ to setup my tries. I used a lightweight JSON parser/serializer called yajjl but feel free to drop in your preferred library or use org.json which is bundled with Ratpack.

root = new Trie(null,null)

def parser = new JsonParser()
def text = new File('worldairports.json').getText()
def airports = parser.parseArray(text)
airports.each {
    if (it.type.equals('Railway Stations'))
        if (it.name.equals(""))
            it.name =  it.city+", "+it.state+" Rail"
    def name =  it.name
    def location =  it.city+", "+it.state+", "+it.country
    def code = it.code
    root.insert(name.toLowerCase(), 
        [displayName:name, location:location, code:code])
}
//codes
airports.each {
    if (it.type.equals('Airports')) {
        def location =  it.city+","+it.state+","+it.country
        root.insert(it.code.toLowerCase(), [displayName:it.name,code:it.code, location:location])
    }
}

One of the initial constraints of this project is that it had to work with the YUI widgets we were using. Yes. YUI. I know.

The only endpoint I have to define is the endpoint that YUI hits asking for a list of autocomplete suggestions. It takes in a query string and returns a JSON list of objects.

post("/autoCompleteLocation") {
    def x = root.autocomplete(params.query)
    def list = []
    for (i in x) {
        list.add([
            value:i.extraData["displayName"], 
            text:i.extraData["displayName"]+", "+i.extraData["location"]
        ])
    }
    serializer.serialize(list)          
}

Including the code for the tries that I merely translated from Python to Groovy, it's only 132 lines of code. With minor tweaks, it could work with a JQuery autocomplete widget or be expanded to offer "Did you mean ...?"-style suggestions too.