Switched to Colemak

As the title reads, I have switched to the Colemak keyboard layout
on all of my devices. I switched mainly due to wanting to help
alleviate some of the strain that I feel in my hands after a long
day coding. I chose Colemak over Dvorak mainly due the similarity
that Colemak and Qwerty have – I assumed that this would help the
transition go more smoothly.

I decided to switch cold-turkey as I thought that doing a part
time switch would be less than ideal since I spend most of my day
in front of a computer. Today is day two and I can already see
improvment from yesterday. According to ‘gtypist’ my typing has
gone from 180 WPM with 98% accuracy using Qwerty to 25 WPM with
85% accuracy using Colemak. Clearly there is a ton of room for

Other Notes
I have also noticed that due to my slowed speed, I am being much
more thoughtful of what I say. Maybe this trend of thinking before
speaking will remain once my speed gets back to a reasonable rate.

Moving On to Other Projects

A week ago today, I gave my notice at Barracuda Networks where I
have been employed for the last seventeen months; My last day
hacking on Copy.com[0] will be this Friday. I am leaving Copy for one
reason: The role that I had there was not one that would keep me
happy, feeling fulfilled, and be constantly forcing me to improve my
craft. Hacking on Copy has been a by-and-large positive experience.

In my tenure there I honed my skills and learned how
to operate in a corporate environment (something that I had never
experienced before). I really do think that Copy is a great
product and the people working on it are incredible – I see big
things in Copy’s future and I am kind of sad that I will miss out
on experiencing them firsthand. When I started working on the Copy
web app, it was very very barebones. I helped flesh out its
initial feature set, and then worked on implementing new features
and participated in the team growing and growing. I think that I
was number seven-ish on the Copy team, and am leaving a team of twenty
nine not counting myself. The Copy account that I created on my
first day has a user id in the tens of thousands (lots of early
test accounts I guess) and now Copy has over two million active
I will miss my Copy coworkers, and I wish them well. I plan on
focusing on getting the projects in my idea list implemented, so
look for those to appear on Github[1] and/or my personal site[2].

To the Copy folks that may end up seeing this, I have only this to
So long, and thanks for all the fish.

[0] https://copy.com
[1] https://github.com/zachwick
[2] https://zachwick.com

Emoji Support in Jabber.el

I use Emacs for almost everything on my computers from text editing,
email, IRC, Jabber/XMPP, to web browsing. With regard to IRC and
Jabber/XMPP, I tend to converse with quite a few people who like
to use Emoji. If you can’t get these people to use their command
of the written word to get their point across, here is a little
hack to get jabber.el, an Emacs Jabber/XMPP client to display
Emoji correctly.

Assuming that you have jabber.el installed and configured to
connect to your Jabber/XMPP server(s) of choice, it is pretty
straight forward.
First, install the Symbola TTF font on your machine. On my
Parabola GNU/Linux box, I do that with `pacman -S
symbola-ttf`. Then inside of Emacs, do `M-x customize-group` and
enter `jabber-chat` as the group name.
Next, locate the “Jabber Chat Text Foreign” section. This section
deals with the font-face to use for text that other’s send you. In
that section, simply change to “Font Family” option to
`Symbola`. Then make sure to apply and/or save your new

Using the Configuration
Your Emacs should now display all incoming chat text using the
Symbola font face and render Emoji correctly without any
additional tweaking. This is a quick and dirty hack to get Emoji
support, but if you can bear having two different fonts in the
same chat buffer, then this may be just what you are looking for.

Kudos to T. Hunter and his post[0] for his initial insight into using
Symbola for Emoji support.

[0] http://thomashunter.name/blog/enable-emoji-fonts-on-debian-ubuntu-mint-linux/

Development is Art

Just as a painter paints because he enjoys the act of applying
brush to canvas in order to create a reality out of an abstract
idea, I code because I enjoy the act of putting fingers to
keyboard to make a reality out of an abstract idea. Painters don’t
paint because it is incredibly profitable, and I don’t code for
just a paycheck. The money that I make from coding ensures that I
am able practice the art of coding my own abstract ideas instead
of someone elses.

A day job as a developer will never make me happy nor make me feel
fulfilled; Only the ability to hack on my own projects can do
that. For this reason and this reason alone, I view all
development jobs as the same and compare on the sole criterion of
how much they enable my outside hacking. David Cronenberg once
said “The desire to be loved is really death when it comes to
art.” I think that the same sentiment applies to development; If I
only code for what someone else wants, then I have died as a
hacker and have lost that part of my being forever.

I am a hacker. I am an artist. I use electrons, pixels, and
switches to transform the beauty of the baud into a physical
reality for my own enjoyment. I derive pleasure from making bits
cross wires and pixels blink on screens. I experience pain from
tedium and monotony. I don’t write code – I write art.

My Dream Workplace Culture

My dream workplace culture would have following properties, listed
below in no particular order:

1. Employees are encouraged to use any system/config/setup that
they want
2. Nobody ever has set work hours
3. Nobody ever has any set work place
4. Every employee is salaried
5. Any meeting lasting longer than 15 min must be scheduled at
least a day in advance
6. If a meeting follows the pub/sub model, it should be an email
instead of a meeting
7. All development happens in the open
8. Every employee has 1 day per week to work on anything that
they want
9. Each employee must respond to at least one support case per
week (if that many cases exist)
10. Every employee has the responsibility to be at least
somewhat familiar with the company strategy and product
roadmap(s) at at least a high level
11. Every employee has the right to be a part of the decision
making process perternaing to the company/product
12. The only information that an employee is not privy to is
their coworkers’ salaries

1. Employees are encouraged to use any system/config/setup
that they want

Here I mean that I want every employee to constantly be tweaking
their work environment to make them “better” at their job –
whatever that job may be. For developers, this culture property
probably means that they are encouraged to use any text editor,
web browser, development tool, or operating system that they so
choose. With regard to non-developer employees, this point
probably means that they are encouraged to use whatever email
client, software, phone, etc. is going to make them better.

The main point is that I want all employees to be enabled to
constantly evaluate how they are doing their job and try
to optimize their performance for whatever metric makes sense
based on their role.

2. Nobody ever has set work hours

What I mean here is that I recognize that people have different
schedules and different times at which they are most
productive. Personally, I am most productive from 05:00 – 11:00
and then from about 18:00 – 20:30; For other people, this schedule
is when they are least productive.
The main point is that I want employees to be able to work when
they are going to be most productive and not feel like they must
work from 09:00 to 17:00.

3. Nobody ever has any set work place
The point here is very similar to point 2 above – I recognize that
there are times when working in solitude at home is going to make
a person the most productive and there are times when working from
a coffee shop is going to be the most beneficial. There are also
times when being in an office next to your coworker is going to be
the best place to really crank out some work. I want the company
to recognize and encourage all employees to be proactive about
choosing the place that is going to be the best for them to work
in. Personally, I happen to love hacking on code sitting outside
on the grass in the sunshine.

4. Every employee is salaried

I don’t ever want an employee to think, “it is 17:00, time to head
home and quit thinking about this problem.” nor do I ever want any
employee to work longer just to make more money while being less
efficient. I think that salaries encourage people to be productive
however they personally can. Also, with wanting point 2 where no
employee has set working hours, paying an hourly wage would
require massive amounts of paperwork and process.

5. Any meeting lasting longer than 15 minutes must be scheduled
at least a day in advance

This is partly a corollary of points 2 and 3, and partly a
standalone point. With every employee working whenever and
wherever they are going to be the most productive, meetings that
require synchronicity must be scheduled in advance. Additionally,
some people (myself included) like to run through a mental plan of
how their next few days are going to go, and being knowledgable of
all of the requirements on my time is essential for that process.

6. If a meeting follows the pub/sub model, it should be an
email instead of a meeting

There is nothing worse than a meeting in which one person is just
pumping information out to the rest of the attendees with no
needed response. I call this the pub/sub meeting model – as in the
publishing/subscribing model for syndication and event
handling. These kinds of meeting are a huge drag on people’s
attention, energy, focus, everything, and are better suited by the
speaker sending the information in an email. Meetings are only
neccessary when discussion is required.

7. All development happens in the open

This point may only apply to developers and their ilk, but I think
that it is very important that developers be allowed to see, and
contribute to any code that the company uses. This allows
(potentially) more eyes to review code, and it allows developers
to take a brief diversion and work on something possibly entirely
different than they normally would. The advantages to this are at
least twofold; This helps prevent developers getting bored with
their work, and it encourages developers to always be learning new
things instead of having their skillset stagnate.

8. Every employee has 1 day per week to work on anything that
they want

A corollary to point 7, is that every employee has 1 day per week
in which they are encouraged to work on anything that they so
desire. This side project could be related to their job, or it
could be practicing basket weaving. The rationale for this point
is the same as the rationale for point 7 – preventing boredom and
skillset stagnation.

9. Each employee must respond to at least one support case
per week (if that many cases exist)

I think that is important for every employee to realize what the
end users’ pain points are in the products. Having this
information readily available makes it easier for employees to
make executive decisions and make the products more
user-friendly. It is also always extremely eye-opening to
see how exactly customers are using what you made. Often
times it seems like customers always find a cool way to abuse the
product into working in some unintended manner.

10. Every employee has the responsibility to be at least
somewhat familiar with the company strategy and product
roadmap(s) at at least a high level

This builds on point 9 above, if every employee is empowered to
make the products better, they should know where the company has
decided to make the product end up.

11. Every employee has the right to be a part of the decision
making process pertaining to the company/product vision/roadmap(s)

Since employees are required to have a rough idea of the company
vision and product roadmap(s), they should also have input into
what those visions are. Employees also have firsthand knowledge of
how customers are using, and how customers are abusing, the
products because they are seeing support cases come in. This
knowledge is information that is required in the product planning process.

12. The only information that an employee is not privy to is
their coworkers’ salaries

Based on all of the points above, employees are going to have a
high degree of knowledge about the company. Employees are also
going to be used to being able to improve any aspect of the
company, which has a prerequisite of knowledge. That knowledge
should be made available to all employees. It would be incredibly
heartening to see real data on the company when things are going
well and really eye-opening to see that same data in a
downturn. That being so, the only information that an employee
should be able to see is what their coworkers’ salaries are. While
this information would be interesting, knowledge of it would
create a heirarchy which might work to stop employees from being
as proactive as they otherwise would be. Employees may start
thinking, “that person makes more than me, so their input must be
more valuable” which is false thinking and will lead to demoralization.

There are probably some definite drawbacks to these points. I can
see that some people would might not see the value in paying
employees to spend one day a week working on something that may
have no direct benefit to the company. I can see how in a very
large organization, point 11 might result in a “too many chiefs,
not enough indians” kind of situation. I can see that points 2 and
3, under which no employee has set hours or location to work in,
might result in inefficiencies.

I think that the first drawback of paid side project time is
sufficiently addressed in the rational for that point above. As
for how to avoid the “too many chiefs, not enough indians”
situation, I am not sure of a solution. Assuredly, not every
employee is going to want to be a part of every decision making
process, so maybe this situation is self-fixing. As for employees
who have no set work hours or place becoming lazy and inefficient,
I think that the proper solution is to be clear from the onset
that any employee who routinely fails to meet the expectations of
them will be let go. This has the effect of ensuring that
employees who can keep themselves on task, and are proactive about
self-improvement remain and thrive, while those that cannot are
not a drain on company resources.

When I had my wife proof-read this, she asked me “So are you
unhappy with where you work?”. The answer to that is a resounding
“no!”. I rather enjoy my current job and the culture there has a
majority of my points in it.
Would I quit this current awesome job to work somewhere that has
all of my points as part of its culture? The answer is that I
don’t know, and it would require some thinking.
When I have my own company someday, or am a very early employee at
a company again, am I going to try and get these points to be part
of the culture there? Of course I am going to.
I am of the firm belief that while I may get paid in exchange for
slinging code around, it is always my responsiblity to improve how
I and my coworkers do that slinging.

PyOhio 2013

Two weeks ago I attended PyOhio 2013 – It was freaking awesome! I
had high hopes for PyOhio as the last conference that I attended
was LibrePlanet (which was also fantastic), and PyOhio did not
fail to deliver.

In addition to listening to some really cool talks, I got to give
a (hopefully cool) talk on what I work on all day – Copy.com. The
talks that were presented were on a wide array of Python-centric
topics and ranged from “novice” to “expert” in subject
The people at PyOhio were just as interesting as the talks. I met
one guy from LightSide, who is doing text analysis on student’s
papers. I met another guy who is a developer on Firefox for
Android and picked his brain on porting GNU Icecat to
Android. There was another guy that I met who works for Canonical
on one of their webapps – It was great to trade “war stories” and
talk shop.

My talk on a Python FUSE layer for Copy.com went rather well, and
for interested people, there is a video posted at PyVideo[0] and

I will definitely be going to PyOhio 2014, and will even try to
come up with an exciting Python project to talk about.

[0] http://pyvideo.org/video/2271/python-fuse
[1] https://www.youtube.com/watch?v=DpvdOuTzOU0

Using GNU/Linux == Assembling Your Own Ammunition

The reasons that I use GNU/Linux (and only software that is free as in
freedom on my personal machines) are probably much different than the
reasons that you do. I use GNU/Linux and FOSS software because I
believe that you don’t truly own a piece of technology until you
understand how it works, and have the freedom to do whatever you wish
with that technology. Also, I really really really really like the
fine-grained control over how each piece of my technology operates.

I recently had the epiphany that I pack/assemble my own ammunition for
my guns (cue crazy gun-totting American comments) for the same
reason. I am forced to understand the mechanics of how my guns
function (which is pretty straight-forward) and I am given
fine-grained (pun intended) control over how the gun will function
each and every time that I use/fire it.

Upon having this epiphany, I starting thinking about other apects of
my life where my beliefs in/about Free Software are applicable. The
results were quite numerous:
– I prefer to work on my own car rather than having somebody else do it
– I love cooking by taking an existing recipe and adapting it
– Almost every mechanical thing that I own I have repaired instead of replaced
– I grow most of my own vegetables
– I brew my own beer
And whats more is that I take pleasure in doing these things – which
is more important that any other benefit. If fiddling, tweaking,
breaking, and fixing aren’t in your bag of skills and desires, that is
fine. I am not advocating that everybody _needs_ to free software, or
pack their own ammunition, or brew their own beer, or grow their own
veggies. I am simply advocating the opinion that if you can’t fix it
and then repair it, then no matter what you think, that technology
owns you completely.


Google Glass Seems Awesome, But…

Google Glass is awesome technology – there is no doubt about that;
And wearable computing is probably going to be the next big
thing. So why the “but” in the title then, since I have already
admitted that Glass is awesome? The “but” is that Google Glass is
going to play a big part in making people complacent with being
constantly recorded by the average citizen. Google Glass might not
be the catalyst for this complacency, but Glass is definitely the
first major chip in the mortar.

Consider cell phones; When cell phones first became popular, they
were for placing/receiving calls and texts – nothing more. Now,
cell phones have become a social crutch to a vast majority of the
population. There are people who go through withdrawal when
without their cell phone for a few hours. I cannot
remember the last time that I had a conversation with somebody
during which they did not look at (or fuss with) their cell
phone. We even go so far as to laud this behaviour. Take for
instance the new Facebook Home commercials. These ads are based on
the premise that people want to escape reality into their phones,
at the exspense of meaningful human interaction.

My point here about cell phones is that they started as an
innocent and extremely ambitious idea to help people communicate
better/easier, and now they have become the mechanism by which we
prevent meaningful human interaction.

With Google Glass, I fear that a similar process with take
place. Glass is going to start out as helping many people in many
meaningful ways. But then it is going to turn into something
sinister; If Glass becomes as popular as other Google products, in
a year or two, it will not be unreasonable to have close to half
of the people that you interact with on a regular basis be wearing
Glass. Consider that this means that 50% of the people that you
see throughout the day can record any thing that you do or say,
and you would have no visual clues that you are being

That snide comment about your boss – recorded.
That personal call made from work – recorded.
Speeding in your car, even just a little bit – recorded.
That embarrassing purchase at the store – recorded.
Your morning jog past that creepy guy’s house – recorded.
Your daily routine – recorded.
That extra 15minutes that you where away at lunch – recorded.

With Glass, and the technologies that proceed from it, every
little detail of you existence will be recorded. There is no
question about it. It is safe to assume that there will be at
least one person recording you at any given instant.

This is a terrifying reality; Who needs the stationary telescreens
from “Nineteen Eighty-Four” when there are mobile telescreens
mounted on the faces of a majority of the population?

How to Install GNU Icecat on Debian Wheezy

Icecat is the GNU project version of Mozilla Firefox. The main
advantage of Icecat over Firefox, and the major difference between
the two, is that Icecat codebase and ecosystem is entirely free
software while Firefox is not. Firefox reccomends non-free plugins
and add-ons, and Icecat only reccomends and distributes free

Installing Icecat
You can get the source for Icecat
from Savannah[0] and built in the usual manner.
If building from source isn’t quite your thing, the GNUzilla team
also provides built tarballs that you can easily download,
un-archive, and run. The latest version of Icecat can be
from GNU FTP[1] (make sure to get the 32bit or 64bit version,
whichever is right for your system).

You should then untar the archive

tar -xzvf path/to/archive

and then move the resulting directory to somewhere in your $PATH. On
my system, I moved the icecat-17.0.1 directory to /usr/local/bin
by executing

sudo mv icecat-17.0.1 /usr/local/bin

You will then need to `cd` to /usr/local/bin and create an
executable symlink the icecat executable.

sudo ln -s icecat-17.0.1 ./icecat

If you now execute

which icecat

the path to this newly created symlink should be printed to your
terminal. You now have a fully installed and useable Icecat on your

Adding Icecat to the Debian Alternatives System
The Debian Alternatives system allows for user configurable
‘default’ applications to use for specific functions. Using the
Alternatives system, you can easily configure which program your
system uses as an editor, a mail client, a web browser, etc. In
order to set Icecat as the browser that all links will open in,
you must add it to the Alternatives system. By executing

sudo update-alternatives –install /usr/bin/icecat x-www-browser /usr/local/bin/icecat 90

Icecat will be added the Alternatives system and set to the
highest priority. Now, all links will open in Icecat.

[0] https://savannah.gnu.org/projects/gnuzilla/
[1] http://ftp.gnu.org/gnu/gnuzilla/17.0/

LibrePlanet 2013

Towards the end of March, I attended LibrePlanet 2013 in Boston,
MA. This was a weekend conference put on by the Free Software
Foundation that was all about free software and bringing together
members of the various free software communities. It was a
fantastic weekend! I attended a few talks, and a workshop/install
party, and learned a whole bunch.

Thursday evening, I met some people for dinner that I had only
ever know from IRC. Little did I realize that this was going to
the be the case all weekend!

Friday morning I explored Cambridge, Harvard’s campus, and MIT’s
campus. Then after a quick lunch, I took the T downtown to work
out of the Free Software Foundation’s office. While it was kind of
strange to putz away on my day job work from a place that would
frown on what I do for my day job, it went very well, and I met
even more people in person that I had only known from IRC.

Friday evening there was a meet-and-greet at the FSF office, where
once again, meeting IRC people in the flesh was the order of the

Saturday began the “actual” conference, and I walked to the
Harvard Science Center with much enthusiasm. After a breakfast and
some quick conversations, it was off to the talks and workshops!

One of the talks that I attended was on the recently passed MA
Right-to-Repair law. The talk was generally about the free
software that may (or may not be) in cars, and how recent
legislation is driving more people towards free software.

Another talk that I attended was on IceCat and LibreJS. IceCat is
a GNU project that is a web browser based off of Mozilla Firefox
with all of the Mozilla branded stripped out, and added privacy
features. LibreJS is a Firefox/Icecat/Iceweasel plugin that allows
users to avoid the “javascript trap” of running non-free
javascript on thier machines. These two projects are near and dear
to me as I hack on them, but it was very nice to meet my
collaborators in person.

I also attended a talk by Stefano Zacchiroli, the current Debian
Project Leader, about what the Debian Project is doing to become a
Free Software Foundation endorsed distro. This talk, and some of
the discussion afterwards were the catalyst that made me change
from my beloved Arch GNU/Linux to Debian GNU/Linux on my main

Then of course there were the Free Software Awards, preceeded by a
talk from rms (Richard M. Stallman, Founder of the GNU Project and
FSF). The talk was what I expected, and the awards were given to
deserving projects.

I also went to the workshop/install party for Replicant and
Coreboot. Replicant is an Android fork that has of the non-free
parts taken out, as well as all of the Google specific parts. The
end result is a cell phone that runs on (mostly) free
software. There are still some non-free firmware bits, but that is
almost unavoidable. The second part of this install party
pertained to Coreboot. Coreboot is a BIOS replacement that is
entirely free software. While my machine is not able to run
Coreboot, it was pretty cool to talk with one of the developers of
Coreboot and learn more about how BIOS’s actually work.

In the end, LibrePlanet 2013 was a great experience. I learned a
whole lot about various free software projects and free software
in general. I will definitely be going back next year.