irssi-email-mentions is an irssi plugin which mails you when somebody mentions you.


I love using IRC. I use it to chat with geeks around the world and with fellow devs at Arkency.

My setup is pretty typical - Irssi running under screen on VPS. This way I’m connected 24/7 so all conversations are logged and anyone can leave me a message.

However this approach has one drawback. I don’t receive a notification when I’m away from the keyboard for a while and somebody mentions me.

Hipchat has solved this issue pretty well. They detect if you’re away and if so they send you an mail saying that someone wants to talk with you.

Of course I badly needed this feature in my irssi. There were some solutions like irssi-notify-io but none of them fit into my requirements. So I rolled out my own irssi plugin.

How does it work?

You’re mailed when somebody mentions you (or when your nick appears in the message)

  <bob> mlomnicki: are you there?

You’re mailed when a message is send to everyone on the channel

  <bob> all: what's your favourite IRC client?

You’re mailed when somebody sends you a private message

  <bob> /query mlomnicki
  <bob> mlomnicki: It was a damn good party yesteday!

The code is available on github (warning: written in Perl).

When does it send a notification?

Of course it would be annoying if you were mailed everytime somebody mentions you. You may be focused on the conversation so there is no need to send any notifications. The plugins gives you some time to respond. By default it’s 2 minutes but you can adjust it to you needs. Check README. If you don’t respond within 2 minutes it assumes you’re away and mails you. In fact, you don’t have to respond. It’s enough if you switch to Irssi and press any key.


This works for me. If you have any ideas how to make this plugin better don’t be shy and leave me a comment or report an issue on github.

Filed under: irc

As a backend developer I used to treat JavaScript as a toy language. Frontend programming was just a little addition. The “Real Work” was done on backend.

It has changed. Mainly thanks to Single-Page-Applications. Nowadays JavaScript and CoffeeScript are one of the most important languages. Frontend programming is as important as backend.

Recently I’ve dived into frontend and I don’t regret it at all. CoffeeScript and Gameboxed Engine are the most brillant things since Rails. While I enjoy CoffeeScript it still relies on JavaScript types. And it is a pain.

Adding arrays

  [1,2,3] + [3] => "1,2,33"

Here comes the type-casting. While all JavaScript developers will explain why a string is the result of the addition of two arrays this behaviour is simply ridiculous. Even raising an exception is better choice than returning a string. The newest ECMAScript provides a lot of interesting features although it doesn’t address this simple issue. Is it expected behaviour? Definitely not. Should it be fixed? Definitely yes.

At least there is a sane solution.

  [1,2,3].concat([3]) => [1,2,3,3]

Subtracting arrays

  [1,2,3] - [3] => NaN

Funny thing. Adding arrays returns a string. Subtracting them returns NaN. Again, JavaScript devs will explain why. Maybe even try to convince you that it’s perfectly fine behaviour. It’s not.

Is there a function to subtract arrays? Sorry, but no. You either have to implement your own or use underscore.js, sugar.js or something similar.

Let’s take a look at underscore.js

  _.difference([1,2,3], [3]) => [1,2]

Not bad. However it looks worse if you try to chain more methods.

  _.first(_.difference([1,2,3], [3])) => 1

Sugar.js looks better:

  [1,2,3].subtract([3]).first() => 1

However sugar.js does monkey patching on the native types which may be considered harmful. Couldn’t it just be added as a core feature?

Y2K problem

  new Date().getYear() => 112

Why the result is 112? ECMAscript specification states Date#getYear returns current year minus 1900.

  2012 - 1900 => 112

It was fine until 2000. Currently, twelve years after millenium, this method should be either fixed or removed.

Surprisingly only IE fixed it. All other browsers still come with that bug.

Solution? Use Date#getFullYear. Or moment.js.

  new Date().getFullYear() => 2012

Hash and object as a key

  class Point
    constructor: (@x, @y) ->

  pointA = new Point(0, 0)
  pointB = new Point(100, 200)
  hash = {}
  hash[pointA] = 10
  hash[pointB] = 50

hash[pointA] should return 10, shouldn’t it?

  hash[pointA] => 50

Why 50? Let’s inspect the hash.

  Object.keys(hash) => ["[object Object]"]

The keys are always converted to strings. Under the hood JavaScript calls pointA.toString() and pointB.toString() which in both cases returns “[object Object]”. You would overwrite Point#toString to return unique indentifier. However it doesn’t seem to be correct semantically.

jQuery map vs each

This quirk has nothing to do with JavaScript itself. However it reveals interesting inconsistency. array, callback(element, index) )

The callback gets element as a first argument and index as second.

What about jQuery.each?

    jQuery.each( array, function(index, element) )

For some reason arguments are reversed - index is first, element is second.


A new language. Syntax like in CoffeeScript. Standard library like in Ruby. All existing libraries, plugins and components can still be used without modification. Possible?

Filed under: javascript

Are class methods evil?

Nick Sutterer who is honorable citizen of my city published a post Are class methods evil? It’s really worth reading as he mentions couple of important aspects of Object Oriented approach and how they are used by Rails community.

Nick mentions my tweet

I’m more and more against using class methods. It often leads to procedural-like programming.

Why class methods?

I often hear “Why to create an object when I can just call a class method?”. The reasoning behind that is quite obvious:

  • 1) shorter code
  • 2) less objects = less GC
  • 3) stateless behavior and no need to initialization

1) and 2) are completely valid arguments. However in my opinion these arguments shouldn’t impose the architecture. My main objection is assumption that given behavior is stateless thus doesn’t need to be encapsulated in object.

Stateless vs Stateful

  • Class methods are executed in context of their arguments
  • Instance methods, in addition to arguments, are executed in context of state of the object

Of course there are more differences but from my point of view that one is quite significant.

Using class methods means we can’t keep a state thus the state must be passed in method arguments. If some module is designed around class methods we deal with procedural-like programming passing arguments from one method to another.

Naturally the state may be kept in class variables but it’s introducing a global state which as Nick remarks should be abandoned.

Not a real world example but I think it shows the difference.

Procedural-like version

  class CssProcessor

    def self.process(code)

    def self.minify(code)
      AwesomeMinifier.minify(code, :type => :cs)

    def self.bust_cache(code)
      AwesomeMinifier.bust_cache(code, :type => :css)



Object oriented version

  class CssProcessor

    def initialize(code)
      @minifier =, :type => :css)

    def process

    def minify

    def bust_cache


  processor ="some_css_code")

Initialization process and keeping a state isn’t useless even in such a simple example. At the first sight it may seem awkward to use an object when class method can be used more easily. Although it’s often a trap. The bigger codebase the more time needed to maintain a procedural code.

I prefer to think in object oriented manner from the ground up. It is like MVC a bit harder at the beginning but it quickly starts to pay for itself.


In his article Nick shows some examples of ActiveRecord usage. It is hard to avoid class methods due to ActiveRecord design but Andrzej Krzywda showed how to deal with it. I recommend reading his article.


Everything is an object

Rubyists like to emphasize that in their favorite programming language everything is an object. It’s not like C++ or JAVA which are “not fully object oriented”. But that fact is often forgotten and misunderstood. I think utility methods are a great example.

Is someting wrong with that code?

  Math.sin(2) * Math::PI

In that case we don’t use the fact the number 2 is an object in Ruby. It’s used like a primitive. This is how we do it in C++.

  2.sin * Math::PI

Of course Fixnum doesn’t have sin method. But we can extend Fixnum to provide it. Monkey patching Fixnum is harmful but there are plenty of other options

  • singleton object methods
  • DCI
  • monkey patch Fixnum with refinements (Ruby 2.0)

When using ActiveSupport it’s quite obvious to do


instead of


so why not to spread object approach over more parts of the codebase?

Filed under: programming and ruby