The rest of the pictures are in my Occupy Wall St. Flickr Set.

Setting stacktrace.log

Open up grails-app/conf/Config.groovy. If you haven’t edited it at all there should be a commented out block called appenders. Uncomment that and set it to the following:

appenders {
    console name:'stdout', layout:pattern(conversionPattern: '%c{2} %m%n')
    file name: 'stacktrace', file: "/var/log/tomcat6/stacktrace.log"
}

By default Grails tries to create a stacktrace.log file in the directory it is executed in, which is won’t have permission to do unless you’ve overridden the permissions (not recommended). Here an appender named stacktrace is defined and mapped to a file in a directory that it will be able to write to.

Setting up H2

Grails now uses H2 for it’s in-memory and default database. If you’ve kept H2 around in production as a file based db then you need to put that in another location it can actually access.

Open up grails-app/conf/DataSource.groovy. In your environments.production.dataSource block set the url property like so:

url = "jdbc:h2:file:/usr/local/grailsdb;MVCC=TRUE"

You can change the path or name to whatever you like, point is it isn’t left as the default which means it will try to create it in a directory it won’t have permission to use.

Why HTTPS?

I believe in offering more options to users. HTTPS uses Transport Layer Security to provide end-to-end encryption for all content served from my server off of the domain. Anyone who wishes to practice web anonymity can do so. How much use this will be is questionable, as I don’t have any personalized content, no cookies, no login, nothing persisted on my server unique to users. When (and if) I role out anything that requires a login HTTPS will always be an option. Privacy is not a liberty I believe should be denied, especially when it’s so damn easy to set up a security certificate and add that to Apache.1

Spot-on.Brilliant observations by Sir Ken Robinson. You might have seen this before.

Source: 52tiger

I couldn’t agree more.

—Stephen Fry on A Bit of Fry and Laurie

Sounds grand, why not join in?

First, I’m not a dedicated resource like Wikipedia or a well known ecosystem like Reddit or Tumblr. The impact would have been small and hindered more than helped raise awareness for the issues at hand. The small amount of traffic I do get is highly focused towards technology-aware people. They already know about SOPA and don’t need additional encouragement from me to contact their representatives and raise an issue.

Second, I believe that something needs to change the net. Be it SOPA, PIPA, or some new unknown that comes out of a government. I was secretly hoping that the Great Firewall of China would bring about some redundancy and distributed nature to the web but it hasn’t. The same root name server system administered by the same ICANN committee structured according to the same 1987 RFC specification (1035) is in place and well-oiled. The machine is still running vulnerably and no one gets it.

Lets look at a case study of two companies both built around the same idea of peer-to-peer file sharing. Napster used a centralized system to manage all the peers and connections between peers. BitTorrent used a distributed protocol that employed decentralized trackers to manage peers and allowed the peers to make connections between themselves. The tracker never sees one byte of content and the torrent information itself can be shared between trackers to gain more users.

The story of Napster’s rise and fall is well documented. It is responsible for spawning networks like Gnutella, eDonkey, and clients such as LimeWire1. These networks still exist, but their quality is dubious at best and a criminal honeypot at worst.

BitTorrent has gone on to prosper with advances like distributed hash tables and encryption. [In]famous trackers like ThePirateBay.org still live on in safe harbor countries having loose IP laws. The protocol itself has even found value outside of piracy as a method to deliver high-volume files easily using methods like HTTP Seeding to augment the peer sharing aspect.

Taking charge of your own environment is not a crime. It’s like creating your own postal system. It will take some work to get a common language but the end result is a stable system that is virtually immune to attacks on the system as a whole because you have many flexible pieces working together. There are no weak links.

The future is distributed. It is not built on global awareness of all systems at all times. It accounts for failures and downtime. It allows people to remix and distribute not according to who came first but who is the best. This system is not easily susceptible to external fuckary. It’s a network that peers with reluctance rather than openly to everyone.

The service starts off with a simple concept. If this then that. It’s simplicity is rivaled only by something like iA Writer. There are no other configurable options outside what is offered in this and that.

Channels

The this and that concepts are implemented by way of channels. Here is what I’ve connected to so far:

• Date & Time
• Email
• Feed
• Flickr
• Foursquare
• Instagram
• Phone Call
• SMS
• Tumblr
• Twitter
• Weather

Every channel offers unique triggers and actions. Triggers are this. They are monitored when you create a task. Actions are that. They are executed with a specific trigger. You can create multiple tasks to emulate multiple actions performed on a trigger.

Tasks

Tasks simply combine a trigger and an action to perform when that trigger happens. You can enable or disable tasks with a simple click. All tasks are created through the same if this then that fashion. First you select the channel you would like to pick a trigger from. Then you define a channel you would like to pick an action from. The simple user flow is great.

Recipes

Recipes are tasks that can be setup and shared with friends or found publicly. The service simply substitutes your channel information in and starts you off with the recipe for a task. All of this is customizable as well. I started with the Archive my tweets to Google Calendar recipe and switched the Google Calendar channel to email so I can back them up all my tweets through email.

Feature Wishlist

1. Allow multiple accounts per channel. Currently you can only have a single account on any channel at any time. This means that to connect two Twitter accounts I need to create another ifttt account. Not a huge hassle, but switching is annoying especially if you want to make use of separate accounts on other services like Gmail.

2. Expand this to include multiple channel filters. Something like if 8:00AM EST and Rain predicted then SMS alert. It’s often ambiguous about when the action will trigger and more importantly how often. Say I create a trigger to tweet something when the forecast for tomorrow dips below freezing1. What if the forecast fluctuates during the day? Will 30F to 35F to 28F produce two tweets at 30F and 28F? Allow things like this to be time constrained would be great, but chaining the triggers together would be the ideal solution.

3. The corollary of #2 is to expand that to include multiple actions. This would create more of a rule style setup. If [conditions] then [actions].

4. Add more custom channels. Allow developers to make HTTP calls or call a trigger remotely. I would love to link my server’s to ifttt so I get custom SMS or email alerts.

I’ve only been using ifttt for a few hours and already I’ve created five tasks. The service is simple. It’s easy for anyone to go in and create their own ifttt’s. I can’t wait to see what they do next.

That’s a busy year.

Basic Usage

At it’s core dux is a flexible container that accepts drop in functionality that can be executed from a common command line interface. Adding new commands or extending others is straight forward and simple. This is a very different mindset from build oriented tools like jake or ant. These tools focus on files, directories, and processing. dux is a simple command line utility that wraps logging and option parsing so it can be extended by other commands.

Let’s start off with a very simple example of how to use dux.

var dux = require('dux');

dux.commands.add('say', function () {
    dux.logger.info('Saying ' + this.args.join(' '));
});

dux.start();

Executing this command is as simple as throwing it at as an argument.

$ node example.js say Hello World!
info:     Welcome to Dux
info:     It works if it ends with Dux ok
info:     Executing command path say Hello World!
info:     Saying Hello World!
info:     Dux ok

You can add a shebang to the top of the file and give it executable permissions to clean up the execution.

$ ./example.js say Hello World!
info:     Welcome to Dux
info:     It works if it ends with Dux ok
info:     Executing command path say Hello World!
info:     Saying Hello World!
info:     Dux ok

Influence

I took a lot of influence from jitsu and npm. The stylized cli logging and exit conditions are especially useful when writing an application. This repackaging allows anyone to build their own npm or jitsu style tool, without the overhead of logging and command usage.