Tomasz Pewiński's blog

Testing redux action sequences

2017-12-09T01:00:00+01:00

Testing the features implemented with redux (actions, reducers) is conceptually quite easy. This is due to redux’ simplicity. Actions are plain objects, and reducers are pure functions that accept everything they need as arguments. There’s no need to mock the external world.

On the other hand, a lot of small unit tests are required to fully test an impact of every action and state transition. That could deter from writing them in the first place.

I think that we developers should harness redux’ simplicity to write better tests. I want to share two approaches I use for more complete redux coverage, especially when dealing with action sequences.

Setup

Let’s have an obligatory counter reducer as an example. The possible actions should be incrementing and decrementing the counter.

// Constants
const INCREMENT = "counter/INCREMENT";
const DECREMENT = "counter/DECREMENT";

// Action creators
const increment = () => ({ type: INCREMENT });
const decrement = () => ({ type: DECREMENT });

// Reducer
const initialState = { count: 0 };
function counter(state = initialState, action) {
  switch(action.type) {
    case INCREMENT:
      return { ...state, count: state.count + 1 };
    case DECREMENT:
      return { ...state, count: state.count - 1 };
    default:
      return state;
  }
}

The most basic tests of this reducer would have a simple structure: given an initial state and an action, the resulting state should be equal to the expected state:

const initialState = { count: 3 };
const action = increment();
const expectedState = { count: 4 };

expect(counter(initialState, action)).toEqual(expectedState);

Tests of this kind are very useful, but they quickly become repetitive and too numerous, because we only test one state / action at a time.

So, here are a few more ways that we can test a sequence of actions.

Reducing a sequence of actions to single state

One kind of a useful reducer test is the one that asserts what the state is after a sequence of actions has been processed (for example, incrementing twice and decrementing once).

Here’s what it may look like: it defines an initial state and invokes the reducer with intermediate states and every action in turn. At the end, it assert that the state is correct.

const initialState = { count: 0 };
const state1 = counter(initialState, increment());
const state2 = counter(state1, increment());
const state3 = counter(state2, decrement());
expect(state3).toEqual({ count: 1 });

Notice the explicit variables for the intermediate states. This approach gets very tedious when testing long sequences of actions.

Luckily, we can rewrite that test using the Array.prototype.reduce function. This function iterates over an array, passing an accumulator variable (the state) and array item (an action) to another function. This function would be our counter reducer. The reducer naming in redux is no coincidence, as it’s directly inspired by Array.prototype.reduce!

const initialState = { count: 0 };
const actions = [increment(), increment(), decrement()];
const expectedState = { count: 1 };

expect(actions.reduce(counter, initialState)).toEqual(expectedState);

The intermediate variables are gone and the test looks much cleaner, as well as is more extendable for longer action sequences.

Bonus point 1: if the Array.prototype.reduce version is not readable enough, I recommend creating a small helper function, e.g. reduceState.

// testHelpers.js
function reduceState(reducer, initialState, actions) {
  return actions.reduce(reducer, initialState);
}

// counter.test.js
expect(reduceState(counter, initialState, actions)).toEqual(expectedState);

If you’re using the excellent functional utility library Ramda, its reduce function does exactly that as well:

import R from "ramda";

const reduceState = R.reduce;

Bonus point 2: so far the examples haven’t imported the redux library code at all. But, we can also rewrite the previous test by instantiating the store with our small reducer. This is a bit more verbose, but could be useful as well.

import { createStore } from "redux";

const initialState = { count: 0 };
const store = createStore(counter, initialState);
store.dispatch(increment());
store.dispatch(increment());
store.dispatch(decrement());
expect(store.getState()).toEqual({ count: 1 });

Accumulating state while reducing

Another type of test is also concerned with a sequence of actions, but it asserts correct state at every step, not only at the end. This way we can have more granular expectations about how the state changes.

const initialState = { count: 0 };
const state1 = counter(initialState, increment());
expect(state1).toEqual({ count: 1 });
const state2 = counter(state1, increment());
expect(state2).toEqual({ count: 2 });
const state3 = counter(state2, decrement());
expect(state3).toEqual({ count: 1 });

There’s a way of making this test more succinct; however, it requires a small helper, not present in the core language like Array.prototype.reduce. This helper will accept a reducer, initial state and array of actions, and return an array of states, beginning from the initial, through intemediate, and ending in the final state.

Let’s call it accumulateState:

function accumulateState(reducer, initialState, actions) {
  const result = [initialState];
  actions.forEach((action) => {
    const currentState = result[result.length - 1];
    const nextState = reducer(currentState, action);
    result.push(nextState);
  });
  return result;
}

Using the helper method, the test looks like this:

const initialState = { count: 0 };
const actions = [increment(), increment(), decrement()];
const expectedStates = [{ count: 0 }, { count: 1 }, { count: 2 }, { count: 1 }];

expect(accumulateState(counter, initialState, actions)).toEqual(expectedStates);

Bonus point 1: this approach works great with jest and snapshot testing. The expected states array can be conveniently captured as a snapshot:

const initialState = { count: 0 };
const actions = [increment(), increment(), decrement()];
expect(accumulateState(counter, initialState, actions)).toMatchSnapshot();

Bonus point 2: if you’re using Ramda, there’s no need to implement a helper - Ramda already has a function that has this exact behaviour. It’s called scan.

import R from "ramda";

const accumulateState = R.scan;

Bonus point 3: analogously, the store version would look like this:

import { createStore } from "redux";

const initialState = { count: 0 };
const store = createStore(counter, initialState);
store.dispatch(increment());
expect(store.getState()).toEqual({ count: 1 });
store.dispatch(increment());
expect(store.getState()).toEqual({ count: 2 });
store.dispatch(decrement());
expect(store.getState()).toEqual({ count: 1 });

Summary

In this article, I introduced two little utility functions for testing redux reducers: reduceState and accumulateState. These fuctions should aid in testing long sequences of actions. For me, these tests also feel more concrete: we’re testing how the state changes during the entire interaction, not only one transition at a time.

A word of clarification: in my examples, I used the action creators (increment, decrement) instead of plain object actions. This way, the reducer and action creators are tested “together” in a single test. I think that’s fine; in fact, it gives me more confidence that the two will work together correctly in a real application. I tend not to write unit tests for action creators alone (unless they contain some tricky logic, but that’s very rare).

I hope these techniques are useful. What other approaches do you use in your tests? Let me know in the comments!

Tracking asynchronous operations with redux

2017-09-09T02:00:00+02:00

A frequent complaint against redux is the amount of code needed to achieve seemingly simple things. Which gets worse when those simple things are also common, leading to lots and lots of similar code. This is often dubbed boilerplate, and posed to be obviously bad (after all, Don’t Repeat Yourself is the law, right?).

Not necessarily so (I think DRY is a very overrated principle, but that’s a thought for another post). One thing the boilerplate is useful for is identifying patterns. If there’s a lot of identical code in multiple places in the codebase (not two, not three, ideally four or more), that’s a strong indicator we’re missing an abstraction.

There’s a particular use case for abstractions in redux apps - happens very often, feels repetitive, and could use a better solution.

That use case is: performing AJAX requests.

(note: if all your app really does is simple data fetching - You might not need redux)

Requirements

Let’s identify what are the requirements of a feature that fetches a list of widgets.

The redux state needs to know:

Whether the widgets are loading or not
Whether the widgets have been loaded successfully or not
Error details if the request has failed
The widget data itself

A common way to implement this feature with redux (using best practices for action creators etc) involves writing:

3 action types (WIDGETS_REQUEST, WIDGETS_SUCCESS, WIDGETS_FAILURE)
3 action creators (widgetsRequest, widgetsSuccess, widgetsFailure)
A reducer that sets the appropriate fields in the state
A thunk dispatching the actions and performing the ajax request itself

It might look like this:

const WIDGETS_REQUEST = 'WIDGETS_REQUEST';
const WIDGETS_SUCCESS = 'WIDGETS_SUCCESS';
const WIDGETS_FAILURE = 'WIDGETS_FAILURE';

function widgetsRequest() {
  return {
    type: WIDGETS_REQUEST
  };
}

function widgetsSuccess(widgets) {
  return {
    type: WIDGETS_SUCCESS,
    payload: { widgets }
  };
}

function widgetsFailure(error) {
  return {
    type: WIDGETS_FAILURE,
    payload: { error }
  };
}

const initialState = {
  widgets: [],
  isLoading: false,
  isLoaded: false,
  error: null,
};

function reducer(state = initialState, action) {
  switch (action.type) {
    case WIDGETS_REQUEST:
      return {
        ...initialState,
        isLoading: true,
      }
    case WIDGETS_SUCCESS:
      return {
        ...initialState,
        isLoaded: true,
        widgets: action.payload.widgets,
      }
    case WIDGETS_FAILURE:
      return {
        ...initialState,
        error: action.payload.error,
      }
    default:
      return state;
  }
}

function fetchWidgetsThunk() {
  return function(dispatch) {
    dispatch(widgetsRequest());
    fetch('/widgets.json')
      .then(response => response.json())
      .then(
        (response) => dispatch(widgetsSuccess(response.widgets)),
        (error) => dispatch(widgetsFailure(error.message)),
      );
  }
}

For the sake of simplicity, the example assumes we’re not storing our widgets in a normalized state shape (which is recommended), and instead just keep them in a list.

Even so, it’s quite a lot of code… If we’re not using the ducks pattern, it’s also spread across multiple files / directories. And don’t forget the tests for it!

The biggest overhead is in implementing the reducer that tracks the request state (isLoading, isLoaded, error fields). Let’s see if we can find an abstraction here.

Operations

We can think of fetching the widgets as an asynchronous operation. There are three possible actions (start, success, failure) that might change its state. The state changes are defined as follows:

start action makes the operation pending
success action makes the operation finished (not pending) and successful
failure action makes the operation finished and not successful - with optional error details

The reducer and actions behave in the same way for every operation.

Now that the functionality is defined and isolated, we can abstract it away. Imagine a createOperation function that accepts a string (unique operation name) and returns an object with action types, action creators and a reducer, already wired up to work together:

const operation = createOperation('NAME');

const { START, SUCCESS, FAILURE } = operation.actionTypes;
const { start, success, failure } = operation.actionCreators;
const { reducer, initialState } = operation;
/*
initialState = {
  pending: false,
  success: false,
  failure: false,
  errors: null
}
*/

In this state shape, isFetching and isFetched are renamed to more fitting pending and success boolean fields. Also, the failure boolean is separate from optional errors details.

When the actions start, success and failure are dispatched to the store, the generated reducer causes a state update (setting the appropriate boolean fields and error details). We also export initialState (useful for tests) and action types (so other reducers can react to the actions, for example by saving data somewhere else in the state).

const pendingState = reducer(initialState, start());
// { pending: true, success: false, failure: false, errors: null }
const successState = reducer(pendingState, success({ payloadExample: [] }));
// { pending: false, success: true, failure: false, errors: null }
const failureState = reducer(pendingState, failure('An error'));
// { pending: false, success: false, failure: true, errors: 'An error' }

With the createOperation function, the widgets feature now looks like this:

import { combineReducers } from 'redux';

const fetchOperation = createOperation('FETCH_WIDGETS');

function widgetsReducer(state = [], action) {
  switch (action.type) {
    case fetchOperation.actionTypes.SUCCESS:
      return action.payload;
    default:
      return state;
  }
}

const reducer = combineReducers({
  widgets: widgetsReducer,
  status: fetchOperation.reducer
});

function fetchWidgetsThunk() {
  return function(dispatch) {
    const { start, success, failure } = fetchOperation.actionCreators;
    dispatch(start());
    fetch('/widgets.json')
      .then(response => response.json())
      .then(
        (response) => dispatch(success(response.widgets)),
        (error) => dispatch(failure(error.message))
      );
  }
}

This is much shorter! The mundane details of tracking the pending / successful / error states are abstracted away by the fetchOperation, and stored in a separate slice of state (in this case, status).

Summary

There are a multitude of existing ways to handle AJAX requests with redux. However, they still require implementing the same reducer logic over and over again.

Using the operation abstraction has following benefits:

Reduces the amount of redux code / test code written for tracking the request status. This decreases the possibility of bugs.
Decouples data state (widget attributes) from meta-data state (are widgets loading?).
Can be used with thunks, sagas, custom middlewares, or any other method for handling async effects. Simply use the generated action creators!
Does not depend on anything other than the existing redux abstractions.
By exporting action types, other reducers can react to single operation state changes as well.
Can be used to track any kind of asynchronous operation, not limited to fetching and updating data via AJAX.

To me, this solution shows the beauty of redux: it is simple and powerful. Because redux is so unopinionated, and uses plain objects and functions (no magic), it can sometimes feel verbose. But developers are able to create and compose elegant abstractions on top of it.

Speaking of which, implementing the createOperation function is left as an excercise to the reader. You can treat it as a programming koan to sharpen your skills. If you’re interested, my implementation is available below:

See the code

function createOperation(name) {
  const START = `${name}/START`;
  const SUCCESS = `${name}/SUCCESS`;
  const FAILURE = `${name}/FAILURE`;

  const start = (payload) => ({ type: START, payload });
  const success = (payload) => ({ type: SUCCESS, payload });
  const failure = (payload) => ({ type: FAILURE, payload });

  const initialState = {
    pending: false,
    success: false,
    failure: false,
    errors: null
  };

  const reducer = (state = initialState, action) => {
    switch(action.type) {
      case START:
        return { ...initialState, pending: true };
      case SUCCESS:
        return { ...initialState, success: true };
      case FAILURE:
        return { ...initialState, failure: true, errors: action.payload };
      default:
        return state;
    }
  };

  const actionCreators = { start, success, failure };
  const actionTypes = { START, SUCCESS, FAILURE };

  return { actionCreators, actionTypes, initialState, reducer };
}

Scalar Conf 2014

2014-04-09T20:10:00+02:00

Last week I had the pleasure to attend Scalar conference in Warsaw, Poland. This was my first conference specifically related to scala. Heck, even my first conference at which java isn’t used as a negative word :) So I thought I’d share my thoughts about it.

I’ve been playing with scala for some time (mostly Play! Framework and Akka), and was curious how the community looks like and what it has to say. I had a chance to meet scala folks from all around the Europe. They use the language for many different purposes. Overall, the conference was a great learning experience for me (I haven’t got time to stay at the party though, which is a shame).

Here are highlights from my favourite talks:

database access with slick - Stefan Zeiger

Stefan introduced slick, which is a library for accessing relational databases in scala. What’s great about it, it allows you to write code that feels like operating on a regular collection, yet talks to the database. Check out the samples here.

Stefan also talked about what’s the future for slick. It’s going to be the default db driver in future versions of play, which I think is great (the current anorm requires you to type SQL by hand, and it’s not really great productivity-wise, especially for beginners like me :))

simple, fast & agile rest with spray.io - Adam Warski

Adam showed how spray.io can be used to quickly create REST api’s, by (successfully!) live-coding on stage. I was really impressed, because when I tried using spray (maybe a year ago), I felt like groping in the dark. Spray definitely improved since then, and it seems like a great way to build web services. I especially liked the directive mechanism - how different functions combine to form an endpoint, passing immutable request model around (you could have a directive that accepts GET requests, another one that reacts only to specific path and third one acting as authentication layer). Adam covered testing the service too.

It probably wouldn’t fit in the timeslot, but I wish he mentioned how to integrate spray with akka for exposing your actor systems on the web (btw, spray will become a part of akka project in the future).

doing crazy algebra with scala types - Jon Pretty

Jon had ‘crazy’ in his talk title, and he delivered. Building up on small set of assumption (for example, a tuple (X, Y) is represented by multiplication, 2 represents a Boolean etc.), Jon formulated some interesting problems, and then solved them using mathematics and humour :) For example, he represented a List and binary Tree with arithmetic operations. Later on he even differentiated a List (a result of this operation was one-hole context, a list without its focus element). It definitely was one of the most entertaining and refreshing talks at scalar.

There were more interesting talks (Grzegorz Kubiak has demonstrated akka cluster of raspberry-pi’s, Mateusz Fedoryszak, Michal Oniszczuk and their quest to find the essence of academia using spark for example) but those three are definitely my favourites.

Last but not least, it should be noted that the conference was organized really smoothly. The talks were just the right size, often breaks allowed for discussions, and lunch was delicious. And that’s despite the fact that’s scalar’s first edition - bravo to the organizers! I’m definitely looking forward to attending next year :)

By the way, and if you’re interested, check out my scala projects on github:

music-match, a music recommendation engine
instapuzzle, multiplayer jigsaw puzzle solving game

Coffeescript's existential operator

2013-08-24T14:43:00+02:00

Love it or hate it, coffeescript does make your front-end javascript code more concise. And one of its great features is existential operator, which helps to remove most of null and undefined checks. Let’s see how it works:

In its basic form, it’s pretty self-explainatory.

if variable?
  # do something

if (typeof variable !== "undefined" && variable !== null) {
  // do something
}

You can chain these checks for deep object lookup:

object?.property?.subproperty?

But there’s more. Run a function only if it’s defined:

object.function?()

if (typeof object.property === "function") {
  object.property();
}

Or lookup an array ony if it’s defined: (this one does not check if property is an array though)

object.property?[1]

var _ref;
if ((_ref = object.property) != null) {
  _ref[1];
}

Existential operator can be used in assignment:

object.property ?= 'value'

if (object.property == null) {
  object.property = 'value';
}

It only assigns when property is not defined. It’s especially handy for boolean variables - let’s compare this to ||= operator:

# ||= operator
variable = false
variable ||= 'value'
variable # => 'value'

# ?= operator
variable2 = false
variable2 ?= 'value'
variable2 # => false

Instant http server with python

2013-07-02T22:18:00+02:00

Here’s an extremely useful one-liner that I’ve been using for ages. It starts a http server with the root in current directory, using python which is most likely already installed on your machine if you’re using Linux or OSX.

python -m SimpleHTTPServer

If you go to http://localhost:8000 you’ll see index.html if it’s present in current directory.

You can also boot up the server on any other port like this:

python -m SimpleHTTPServer 8888

It’s useful for development, for example of Single Page Applications. Enjoy :)

EDIT:

There’s how to do it in ruby:

ruby -run -e httpd -- -p 8000 .

Ironically I always used python one even though I use ruby far more often :)

Curl crash course

2012-10-27T02:00:00+02:00

Debugging web services is a common task for web developer. Sometimes you want to have more control on the request you’re making - hitting reload in your browser might not be enough. That’s where curl comes in.

If you’re a web-dev you heard of it for sure, but maybe didn’t have time to read a lengthy man page and learn how to use it in day-to-day development. In this article I’ll show most useful ways of using curl.

If you’re running a linux distribution, curl is available through your system’s package manager.

Basic usage

It’s as simple as curl your-url. By default a body of HTTP response will be printed to stdout.

curl http://pewniak747.info

Adding -v is very useful - it lets you see whole HTTP request & response, and debug information:

curl -v http://pewniak747.info

* About to connect() to pewniak747.info port 80 (#0)
*   Trying 74.117.156.115... connected
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu)
> Host: pewniak747.info
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx/1.1.4
< Date: Sat, 27 Oct 2012 19:09:07 GMT
< Content-Type: text/html
< Content-Length: 5178
< Last-Modified: Sat, 27 Oct 2012 13:30:31 GMT
< Connection: keep-alive
< Accept-Ranges: bytes

Advanced usage

Changing HTTP method (default is GET)

curl -X PUT http://api.example.com/endpoint

Query parameters:

curl http://api.example.com/endpoint?param=value

Sending data in request body (with Content-Type: application/x-www-form-urlencoded header):

curl -d 'param=value' -d 'param2=other_value' http://api.example.com/endpoint

(Note that adding -X POST is not necessary - curl automatically assumes a POST)

To simulate a Content-Type: multipart/form-data (form submitted by browser) use -F instead of -d.

curl -F 'param=value' -F 'param2=other_value' http://api.example.com/endpoint

Sending a file in the form:

curl -F 'photo=@/path/to/file' http://api.example.com/endpoint

Adding headers:

curl -H "Authorization: b97e1222abe974191dfc65c8e2b2eb6b" http://api.example.com/endpoint

Sending a cookie:

curl -b "session_id=4337a82f37c7218e41931b9bcc60c943" http://api.example.com/endpoint

Fetching headers only (using HTTP HEAD method - can be handy if response body is long):

curl -I http://api.example.com/endpoint

Debugging JSON

I recommend to install colorful_json gem - piping curl to cjson will nicely format the output:

curl https://api.flattr.com/rest/v2/users/smgt/things | cjson

[
  {
    "type": "thing",
    "resource": "https://api.flattr.com/rest/v2/things/958860",
    "link": "https://flattr.com/thing/958860",
    "id": 958860
  }
]
...

That’s all! I hope you learned useful ways of using curl to debug web services. Do you know other useful curl tricks, or use other tools to aid HTTP debugging? Let me know in the comments!

Using xargs, sed and pipes

2012-09-17T02:00:00+02:00

Problem

Upon migrating my blog to new engine, I had to rename bunch of article files.

As is: source/2012/09/17/Using-xargs-and-sed.markdown

Should be: source/2012-09-17-using-xargs-and-sed.markdown

So basically to move files from nested directories into source directory, downcasing and adding a prefix of year-month-day.

Solution

Combination of find, xargs, tr and sed:

find source/20??/**/*.markdown |
xargs -n1 sh -c 'echo $0 && echo $0 | tr "[:upper:]" "[:lower:]" | sed -e s/\\//-/g -e s/^source-/source\\//' |
xargs -n2 mv

In the first line, we list all article files, using wildcards.

Then we’re piping the output to xargs with -n1 switch, and a command. This will invoke the command for every (-n1) line passing it as argument. The trick is, command to invoke is actually a new shell process with its own instructions passed after -c switch!

In the subshell, we first print the original path ($0, because it was the argumant passed to the shell). Then the path is processed:

tr "[:upper:]" "[:lower:]" converts it to lower-case letters
we’re using sed with two -e switches:
- s/\\//-/g - replaces every occurence of / for -. I had to use \\/ because it is interpolated to string, being an argument to sh -c command.
- s/^source-/source\\// - restore first slash after source
no more pipes so processed path is printed to stdout.

Now we have multiple lines of paths, original, then processed and so on:

source/2012/09/17/Using-xargs-and-sed.markdown
source/2012-09-17-using-xargs-and-sed.markdown
source/2012/08/04/Checker-gem-for-ruby-rails-development.markdown
source/2012-08-04-checker-gem-for-ruby-rails-development.markdown

Piping that to xargs -n2 mv will invoke mv passing consecutive pairs of lines, which is just what we wanted!

mv source/2012/09/17/Using-xargs-and-sed.markdown source/2012-09-17-using-xargs-and-sed.markdown

Have a better / more obvious solution? Let me know in the comments. Meanwhile, <3 UNIX.

Checker gem for Ruby & Rails development

2012-08-04T02:00:00+02:00

Recently, I had a chance to contribute to a nice ruby gem called Checker. As the name suggests, It’s an utility for checking source files.

What’s cool about it is that it’ll check files you’re committing via git for errors or unwanted phrases, and will halt the commit if the check fails. No more typos & syntax errors in your repository!

It currently supports:

ruby syntax
haml & sass
checking for binding.pry occurences
javascript & coffeescript lint
yaml parsing

So it’s perfect kit for day-to-day Rails development.

Installing is dead-simple via rubygems:

gem install checker

And using is even simpler. Just say checker to process staged git files:

[ RUBY ]
[ HAML ]
[ PRY ]
Checking source/2012/08/04/Checker-gem-for-ruby-rails-development.markdown... pry -> OK,  remote_pry -> OK
[ COFFEESCRIPT ]
[ JAVASCRIPT ]
[ SASS ]
[ YAML ]

It’s convinient to add checker to .git/hooks/pre-commit . That way every single commit will be processed before saving.

For some modules to work you may need to install additional executables. See the gem README for more info. I hope you find it useful!

Pivotal Tracker git post-receive hook

2012-04-10T02:00:00+02:00

Github’s webhooks feature is great, hovewer many people still like to self-host their git repositories. I’m one of them, and I also like Pivotal Tracker as project management tool. So I wrote this simple git hook to automatically hook up my commits to stories in Pivotal. You will need ruby & nokogiri gem for this.

GitHub Gist

To get it to work on your remote repo:

git clone git://gist.github.com/2352380.git /tmp
mv /tmp/post-receive-pivotal $YOUR_GIT_REPO/.git/hooks/post-receive

(alternatively you can keep it in .git/hooks/post-receive-pivotal and make original post-receive run it)

chmod +x $YOUR_GIT_REPO/.git/hooks/post-receive
git config pivotal.token [YOUR_PIVOTAL_TOKEN]

Now you can do commit messages like “[finishes #123456] bugfix” and after you push comments will be added to your pivotal story.

Find directories size

2011-04-12T02:00:00+02:00

A nice one-liner that I use. Outputs subdirectories of current directory along with their size (in megabytes), sorted increasingly.

du -m --max-depth=1 | sort -n -

Drop it in your $PATH, chmod +x and enjoy!

Hooking autospec to GNOME notifications

2010-03-28T01:00:00+01:00

I was using rspec to automate my tests, while writing snippet-gem. I strongly recommend this great tool!

The problem was i had to look at the terminal all the time to check if my tests have passed. I found a nice way to hook it to GNOME notifications. It looks like this:

To achieve this, create a new file in your home directory, called .autotest, and fill in this code:

#!/bin/ruby
require 'redgreen'
require 'autotest/timestamp'

module Autotest::GnomeNotify
  def self.notify title, msg, img
    system "notify-send '#{title}' '#{msg}' -i #{img} -t 3000"
  end
  Autotest.add_hook :ran_command do |at|
    image_root = "~/.autotest_images"
    results = [at.results].flatten.join("\n")
    results.gsub!(/\\e\[\d+m/,'')
    output = results.slice(/(\d+)\sexamples?,\s(\d+)\sfailures?/)
    puts output.inspect
    if output
      if $~[2].to_i > 0
        notify "FAIL", "#{output}", "#{image_root}/fail.png"
      else
        notify "Pass", "#{output}", "#{image_root}/pass.png"
      end
    end
  end
end

You should also install a redgreen gem:

$ gem install redgreen

In .autotest_images/ directory paste some icons for fail.png and pass.png. Iconspedia is my favourite source of icons.

Now you can enjoy running autospec with system notifications!

Found here

Navigate trough browser tabs with mouse

2010-01-26T01:00:00+01:00

Introduction

I got a wireless media-tech Syndic@tor mouse for xmas:) As you can see it has two extra buttons on the side, conveniently located under thumb. I was thinking how to use these cool buttons effectively.

At first I used them to switch to next/previous desktop on my GNOME environment. But I didn’t need it that much. Then I got an idea - switching tabs in firefox!

I created two simple scripts that send signals of keys being pressed. Ctrl+Tab is a shortcut for next tab, Ctrl+Shift+Tab for previous (it works on all popular browsers). Then I connected these scripts to mouse buttons, like shortcuts.

Prepare

We’ll need a xsendkeycode program. I assume you don’t have it on your linux desktop, so download it form repositories.

$ sudo apt-get install xsendkeycode

Write scripts

Create these two scripts in a safe place:

#!/bin/bash

# ff_nexttab.sh

xsendkeycode 37 1
xsendkeycode 23 1
xsendkeycode 23 0
xsendkeycode 37 0

#!/bin/bash

# ff_prevtab.sh

xsendkeycode 37 1
xsendkeycode 50 1
xsendkeycode 23 1
xsendkeycode 23 0
xsendkeycode 50 0
xsendkeycode 37 0

Xsendkeycode sends key-pressed or key-released signal. 37 means LCtrl, 23 is Tab ans 50 RShift. 1 means press, 0 release. Can you see your browser’s shortcuts now?

Make both scripts executable!

$ chmod +x ff_nexttab.sh
$ chmod +x ff_prevtab.sh

Connect

Connecting scripts to mouse keys differs on various environments. I use GNOME with Compiz.

So, open up CompizConfig and navigate to “General -> Commands”. In fields 1 and 2 type absolute paths to your scripts, ie.

/home/pewniak747/Scripts/ff_nexttab.sh

Then, go to tab “mouse shortcuts” and set fields 1 and 2 to your mouse buttons. In my case these are buttons 8 and 9.

Voila! Enjoy surfing the internet with mouse in your hands!

Adding rss feed in Jekyll

2010-01-24T01:00:00+01:00

Recently I wanted to add an rss feed to my Jekyll-based blog. Unfortunately there is no support for this. Quite strange…

I ended up with creating simple feed.xml to be processed with Jekyll. Once you create it, there’s no need of updating when posting.

---
layout: putsomerandomstringhere
---
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>put your blog's title here</title>
    <description>put your blog's description here</description>
    <link>http://yoururl.com</link>
    {% for post in site.posts %}
      <item>
        <title>{{ post.title }}</title>
        <description>{{ post.content | xml_escape }}</description>
        <link>http://yoururl.com{{ post.url }}</link>
      </item>
    {% endfor %}
  </channel>
</rss>

Strange layout prevents from ignoring page by Jekyll, and xml_escape prepares post content to be displayed in rss feed.

References: http://www.rss-specifications.com/creating-rss-feeds.htm

Jekyll basics tutorial

2009-12-22T01:00:00+01:00

Introduction

This tutorial will be about a great tool I found couple weeks ago, called Jekyll.

Jekyll is a “blog-aware, static site generator”. What does it mean? Well, basically it generates complete static html site based on your templates. It’s great for small, informative webpages or minimalistic, yet powerful blogs. It runs this one too:)

Imagine you are creating a simple web page for a client. Nothing fancy, just plain HTML + CSS, some sub-pages containing informations about the company, products, contact info, etc. Normally you’ll create many HTML files, each one containing the same headers and other stuff, over and over. You’ll probably make many mistakes:(.

But there’s more convenient way to do this. Jekyll to the rescue!

Installation

Jekyll installation is easy-as-pie through rubygems.

$ sudo gem install jekyll

You’ll probably need to install rubygems first. And Ruby itself, if you already don’t got it. Shame on you!

Once Jekyll has been installed, lets go to our working directory and create some stuff.

Directory structure

To work with Jekyll you need to create following directories and files:

_config.yml - this file will contain all configuration for Jekyll to run. Leave it empty for now.
_layouts - this will contain all, well, layouts:) We’ll get to it in a while.
_includes

Layouts

Layouts are the files used on the top of rendering new page. They’ll basically contain DOCTYPE, <head> and such stuff.

Go on and create your first layout in _layouts dir, called “main.html”. Put in this code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
  <head>
    <title>My page</title>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8" />
    <meta http-equiv="content-language" content="en" />
  </head>
  <body>
    {% assign content_tag = '{{ content }}' %}{{ content_tag }}
  </body>
 </html>

Notice the strange “ {{ contenttag }} ” statement? That’s the _liquid tag : Liquid is a templating language which Jekyll uses. We’ll be seeing such tags quite often in the future.

So what does it do? All contents rendered will be placed instead of this tag. So basically Layout is the static part of your site (eg. header, logo, navigation), while content changes depending on what sub-site is user visiting.

Pages

Let’s go on and create our first page. That will be probably index.html. But see how it differs from ordinary index.html:

---
layout: main
title: Home page
---

<h1 class="color1">Welcome to my site.</h1>
<p>My name is Tomasz 'pewinak747' Pewinski blablabla...</p>

Pretty short, huh? We don’t need to write all unnesessary boring DOCTYPES, <body>s etc, it all will be inserted instead of {{ content_tag }} by Jekyll magic.

YAML front matter (’–––’) is our spell. See how we told Jekyll to use main layout to render this page?

Showtime!

Time to see Jekyll in action! But first, open _config.yml that I mentioned before and insert following lines:

server: true
auto: true

The first one fires up a simple server, so we can see changes by pointing the browser to localhost:4000

Second command invokes automatic Jekyll update when any of project files was changed, preventing us from running Jekyll all the time manually.

Once you saved the _config.yml, navigate to your working directory and execute Jekyll:

& cd path/to/project
& jekyll

(If you dislike editing config files you could use:)

$ jekyll --server --auto

Point your browser to localhost and see the page source. index.html has been merged with main.html to produce full-equipped standalone index.html, which lives in just created _site directory. Magic!

Let’s see some more. Go back to your layout and edit <title> tag:

<title>{% assign title_tag='{{ page.title }}' %}{{ title_tag }}</title>

Refresh, and parameter ‘title’ specified in YAML front matter in index.html will be placed instead of this tag. You can pass any parameter and display it that way.

Conclusion

With this tutorial you will be able to create simple web pages. In future tutorails I’ll show some advanced Jekyll features eg. posts, embeded ruby code or includes. See you soon!