Idel-IRC Release

I have released my Idel IRC client for free on the Chrome Web Store, and simultaneously released the source code on GitHub.

There is still plenty that needs to be done to it, but it should already be usable to many in its current form already.

I plan to fix up any remaining bugs, implement a few new features, and eventually turn it into a learning resource for those interested in AngularJS and using it to build cool apps.

As I'm also pushing to a personal remote along with GitHub, I've put a small script on GitHub that makes pushing to multiple remotes as simple as git mpush origin,github master.

Comment on this post.

Idel IRC Client

I made an IRC client. In fact for the past few months I've been doing a lot of client-side work using AngularJS.

I can't possibly praise AngularJS enough; this HTML and JavaScript framework from Google has completely changed the way that I write for the web. It's great for developing rich, responsive interfaces, and has a fantastic community (#AngularJS on Freenode). Best of all, it's perfect for writing large testable and maintainable JavaScript apps.

As a daily user of IRC, I've built a ton of bots, and frequently bounce between clients (currently using hexchat through znc ). I don't have any spectacular needs in a client though, so I decided that this would be a cool opportunity to build my own using 100% client-side web technology.


Being evil with narrow-to-region-indirect

Following up on my last post, here is how you can define a custom operator for evil-mode (which is where the true power of Vim comes into play).

It is trivially easy to set this up using evil-define-operator. Here is the code:

(evil-define-operator evil-narrow-indirect (beg end type)
  "Indirectly narrow the region from BEG to END."
  (interactive "<R>")
  (narrow-to-region-indirect beg end))

Now all that is left is to bind it to a key! I'm using "m":

(define-key evil-normal-state-map "m" 'evil-narrow-indirect)
(define-key evil-visual-state-map "m" 'evil-narrow-indirect)

Eval all of this, and now we have everything in place to say "mit" or "mi}", etc.

Comment on this post.

Narrow-to-region-indirect for Emacs

I'm once again an Emacs convert. I used Emacs a fair bit back in 2011 as my main editor (when vimpulse was a viable alternative to native Vim and I forced Emacs upon myself for as long as I could), I even wrote a few posts about extending it. But eventually I gave it up as it was starting to feel sluggish with everything I was throwing at it (looking back, it was more than likely just a bad minor-mode or two).

However in the time I've been away from Emacs I feel as though the eco-system has really modernized. We now have emacs-starter-kit and prelude to get you up and running quickly with sane defaults, we have package.el since Emacs 24, along with MELPA as a maintained repository of elisp packages, and even a set of decent color themes! And of course I can't leave out evil (the extensible vi layer) which I could not do without.


Litc, a Literate-style Program Compiler

CoffeeScript v1.5.0 was released a few days ago. One of the new features touted in this release was the addition of "Literate CoffeeScript". This was an additional mode in the compiler that allows it to process files ending with .litcoffee that contain both Markdown and CoffeeScript together to form a literate program.

Literate programming, introduced by Donald Knuth, is a technique of writing programs in the natural order and style that you would use if you were to verbally describe the way a program works. Literate programming is designed to break the order of source code required by traditional compilers. It can be fun to build programs in this way by simply starting a document with a description and a list of headers for each feature.

I thought it was really cool to see this in CoffeeScript, but it made me wonder why exactly this needed to be a CoffeeScript extension and not another tool available for any language. So I wrote a small utility to do exactly that.

There are several utilities out there already for assisting with literate programming, however I have a crazy case of Not Invented Here so I decided it would be fun to write my own take on the idea.


Hello, Leap World!

By now, most people that keep up to date with tech news will have heard about the small $70USD 3D motion sensing controller by Leap Motion (make sure to see the demo if you haven't already) that is claiming to open up some incredible possibilities for the future of computer input.

In a nutshell, the Leap is a device similar to Microsoft's Kinect; it uses a pair of infrared cameras and some clever math to build a point cloud and detect hands + fingers + tools inside of this point cloud and return information about these using a simple API. Though where the Leap really excels is in speed and accuracy. This thing is fast, in my brief test on an i7 CPU and USB3 connection I was seeing between 2-5ms of latency, which is perfect for an input device and quite a feat considering the accuracy, which is right down to the millimeter level.


WacomWebPlugin PKGBUILD

After a short stint of hacking on WacomWebPlugin I've tagged the repository as v0.1 and released my first ever PKGBUILD for ArchLinux. If you have a Wacom device on Linux then go and try it out!

Since the last update:

  • Device id is no longer hardcoded.
  • The eraser device is now also used.
  • No more phantom presses since we use the proximity events to change the pen type.

All in all the plugin is feeling a lot more stable than before.

Comment on this post.

WacomWebPlugin Updated

Nine months ago, I published WacomWebPlugin , a project aiming to implement the Wacom Tablet Plugin API on the Linux OS where the official browser plugin isn't available. The plugin allows websites to make use of tablet features such as pressure-sensitivity. The most well known user of this API is DeviantART's Muro web app.

My initial proof-of-concept was hacked together using the FireBreath framework, which makes it easy to implement cross-platform and cross-browser plugins. I was able to get enough of a plugin working to allow basic pressure-sensitive drawing on Muro. However, the code was crap and was full of repetition and global state. I published it nonetheless.

Over the last couple of days I've had some interest from a curious Githubber wanting to port his notetaking program (hoodle ) to the web, so I've decided to revive and rewrite the project. After updating my copy of FireBreath and being unable to compile the plugin without some modifications, I realised that I don't really need the large FireBreath dependency after all (the plugin will likely only ever target Linux).


HashTWM Updates

For the first time in.. a while, I have had a sudden inclination to do some updates to HashTWM . So far I've mostly just done some cleanups and code style changes, but one major feature that I've just added is the ability to whitelist a few window classes and have HashTWM only tile those windows, as opposed to all (or blacklisting). I believe this was a feature suggested to me a while ago that I had misinterpreted (durr). Oh well it is finally done and is very useful :)

Just in time for the end of the world.

What's Next.

I have conceived many pet projects with the goal of replacing HashTWM in the long run, but I think that the best chance that HashTWM has is for me to port features from those prototypes back into the mainline.

The major features I will be wanting to add are:

  • A scripting language of some kind, at least as a way of enabling more powerful configuration. Leaning towards a Scheme (maybe Chicken).
  • More powerful keybindings (and even chaining) using a keyhook (from HackWM ).
  • Some kind of remote, for external displays/control. This should keep it nice and light while allowing you to see tags, and other useful info.

Hopefully as my Windows laptop gets more use in the coming months I will be able to contribute more time to HashTWM. Thanks to everyone that has been following the project and still has an interest :)

Happy Holidays!

Comment on this post.

"Monkey Patching" in Ruby

I don't use a whole lot of Ruby in my day to day work, but it is a language that is very quickly growing on me for several reasons.

As I further integrate jekyll into my website pipeline, I'm finding more of a need to extend it with plugins, no surprises there. One particular plugin that I was previously using is jekyll-assets . I have since moved over to jekyll-asset-pipeline as it better serves my needs, but this article remains.

Jekyll-assets provides a sprockets based asset pipeline, closely mirroring the pipeline present in Rails. The asset pipeline allows me to quickly concatenate and process multiple JavaScript and CSS files into single output bundles; reducing the amount of requests made when loading a page, and thereby improving load time. I also use it to build CoffeeScript and SASS stylesheets.

What is Monkey Patching?

Monkey patching refers to the ability to modify existing code at runtime and outside of regular means (ie. editing the original source). This can be useful as a way to add often-needed functions to a basic type, and in the case of Ruby where everything is an object, this can even include adding methods to numbers themselves (which are of the FixNum class), for example: