evanculver.com

Announcing TellOnTheBoss.com

Premise

We’ve all seen it or been a part of it before: your superiors at work are just not seeing the big picture and you just want to tell them what you really think. Whether it be a critical business opportunity, terrible personal habits that the rest of the office takes offense to, or in an extreme case, that the entire workplace thinks they’re a joke–there’s really no denying that it’s sometimes a very hard thing to get across.

All of that truth should come out, but how? That’s where TellOnTheBoss.com comes in. TOTB is grossly simplified way for employees to leave feedback for their bosses, past or present and most importantly, anonymously. The goal of the site is for employees to have an outlet to say the things they would normally withhold. Hopefully, it can help the leaders out there become better at what they do.

Background

This idea came to me after being in a similar situation and not knowing what to do to get my point across. It eventually boiled over into a weekend project which is now what you see at TellOnTheBoss.com.

Please let me know what you think–It’s still very much a work in progress.

Upstart Notes

I think I’m going to try to keep my notes about Upstart here in the hopes that it may save some others time in the future.

Where scripts should live:

/etc/init

Failed to connect to socket:

status: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory

Run commands as root (duhh):
sudo [start|stop|restart] SERVICE

Information regarding all the stanzas:

http://upstart.ubuntu.com/wiki/Stanzas

Tags: administration, ubuntu, upstart

Notes on Upgrading Django

I recently pushed a bunch of code to my staging server for various projects after upgrading to Django 1.2.4, and things got a little frustrating, so I figured I’d share. So, obviously, I had upgraded in my local dev environment, tests pass and, to be completely honest, these are pretty small sites that I had assumed made little use of things that were backwards incompatible. Which, as it turns out, I was correct in assuming, but I was getting errors like:


[Fri Jan 07 20:56:54 2011] [error] [client 192.168.2.102] Traceback (most recent call last):
[Fri Jan 07 20:56:54 2011] [error] [client 192.168.2.102] File "/usr/lib/pymodules/python2.6/django/core/handlers/wsgi.py", line 230, in __call__
[Fri Jan 07 20:56:54 2011] [error] [client 192.168.2.102] self.load_middleware()
[Fri Jan 07 20:56:54 2011] [error] [client 192.168.2.102] File "/usr/lib/pymodules/python2.6/django/core/handlers/base.py", line 42, in load_middleware
[Fri Jan 07 20:56:54 2011] [error] [client 192.168.2.102] raise exceptions.ImproperlyConfigured, 'Error importing middleware %s: "%s"' % (mw_module, e)
[Fri Jan 07 20:56:54 2011] [error] [client 192.168.2.102] ImproperlyConfigured: Error importing middleware django.middleware.csrf: "No module named csrf"
[Sat Jan 08 14:37:28 2011] [error] [client 192.168.2.102] mod_wsgi (pid=22250): Exception occurred processing WSGI script '/var/www/myproject/myproject/wsgi/app.py'.


It was obvious that by requiring a new feature (in this case CSRF), my app was parking because it was using an older version of Django.

Long story short, make sure that all previous versions of Django are gone before you re-install. Because I was a n00b when I set up my staging server, my Django install wasn’t sandboxed via a virtualenv and so I had artifacts of it in my PYTHONPATH which my apps were using. For me, I even found pieces in /usr/lib/pymodules/python2.6 on Ubuntu 10.04, weird considering global packages are usually installed in /usr/local/lib/python2.6/dist-packages. One way to get to the bottom of it all, is to grab your entire PYTHONPATH:


python -c 'import sys; print sys.path'


And make sure that Django is no where to be found before re-installing. Once I got all this cleared up, I went ahead and created virtualenvs for each of my projects so this wouldn’t happen again and so that I could isolate problems more effectively.

I guess this is just another little tidbit of being relatively new to python/django administration.

It’s all obvious in the end.

Hope this helps.

Tags: django, python

jQuery $.live() Equivalent in YUI 3

It’s been a while since I’ve posted and since I started at Yahoo! so I figured I’d give a little love to the new toys I’ve had the pleasure of playing with as of late. Clearly, we’re using YUI here at Yahoo! and because of that I’d had to adjust my thinking on a few goto front-end techniques that I relied on jQuery for. I hope to post more on these adjustments I’ve had to make, but we’ll see.

Aside from general patterns involving YUI loader, a major jQuery feature I realized that I had come to rely on is jQuery’s $.live() method.

Let’s say I have some markup like:


<div id="wrap">
    <span id="button">Click Me!</span>
</div>


That’s being dynamically inserted into the DOM.

I got pretty used to doing something like:


$("#id").live("click", function() {
    // do stuff
}


Super handy, but not exactly the best performance-wise. If you read the jQuery documentation (or even the jQuery source), you’ll soon find out that what’s going on behind the scenes is an implied event delegation to the root of the DOM. But, not to get too far off topic, there’s a lot of overhead that comes at the expense of this convenience.

YUI provides the same sort of functionality, albeit in a more explicit fashion via the Event delegate() method. I personally like the design decision that was made by the YUI team considering the performance hits that can be involved with using jQuery’s live method incorrectly, but to be completely fair, you can’t really mind the cleanliness of jQuery’s API. Anyways, you can always read the YUI 3 Event docs, but the above simply becomes:


YUI().use('node', 'node-event-delegate', function(Y) {
    Y.one('#wrap').delegate('click', function(e) {
        // do stuff
    }, '#id');
});


I really like the cleanliness of jQuery, but sometimes, you gotta make a little lemonade outta the lemons you were given, even if they’re a little bit rounder and less yellow than the ones you’ve seen before.

There are definitely some caveats in the jQuery way of doing things as well as in YUI, but I feel like it’s a whole lot harder to screw it up in YUI.

Now, go try it yourself.

Tags: code, delegate, event-delegation, javascript, jquery, live, yui

A New Start

The last year has been a fun one. I moved to California and began working as an engineer at Mahalo.com. A huge opportunity! During this last year, I’ve had the luxury of working with a series of great engineers as well as some of the most interesting new technologies in the web space. We were lucky enough to solve really interesting problems in scalability and efficiency and were able to constantly push out new products and features, almost on a bi-weekly basis.

It was a very exciting time in my life, and now, an even more exciting time exists.

I was recently given an opportunity to work with another great bunch of developers and right here in Santa Monica, barely a mile away from where I live. It is an opportunity I couldn’t pass up. It has been made pretty clear from the various news outlets that my exit from Mahalo wasn’t on the best of terms, but I’d like to come out and say, that although it was a little rough, I wish all the best for Mahalo and it’s staff and I can’t thank them enough for such a great opportunity and learning experience. I will miss all the good times we had there, even if they were being had at 3am when product launch had gone awry. You guys are great.

But, I’m excited to be joining Yahoo! where I’ll be working mainly on Yahoo! Sports as a front end engineer. I’m pretty pumped to take on a role centered around UI engineering at a major internet company that just happens to own the largest sports site in the world. Here, I will hope to help inspire inovation, learn as much as possible from those around me, and build as many beautiful UIs as humanly possible.

I’m feeling pretty darn lucky right about now.

Cheers.

Tags: career, new-beginning, opportunity, personal

More Node.js + Comet Tomfoolery

I know there have been quite a few people out there that have messed around with node and comet already, but I figured I’d give it a go perhaps if only to familiarize myself more with the awesomeness that is node.js. I was originally inspired by this post on Ajaxian, so you’ll notice that I too am basing this off of Faye’s implementation of the Bayeux protocol for publish/subscribe. Only real difference is that in my example, messages are passed to the client via stdin.

Here’s the code: http://github.com/eculver/node_comet

I also read in a few other places where people were using fs.watchFile or node’s process.createChildProcess to create a public activity log of sorts. Maybe I’m just a nerd, but it would be kind of cool to go to a high-trafficked site and see some of the server log data (origin, user-agent, etc) in real-time. Something to that effect.

Tags: comet, faye, node.js

Filtering Special Characters Injected by Microsoft Word

I have been having trouble with users pasting content directly from M$ Word into admin fields, so I set out to create some sort of filter that replaces these little terds with something more HTML friendly. Here’s what I came up with, efficiency aside:

http://gist.github.com/370004

Please fork and enhance if you find more of these evil demon characters anywhere.

I guess it should also be noted that this can be called from any model save method on fields that you wish to filter.

UPDATE:

Just use SmartyPants: http://pypi.python.org/pypi/smartypants/

Tags: django, microsoft, microsoft-word, python, special-characters, string-filtering

curl-ca-bundle Macports Checksum Woes

Just got done pulling my hair out over some pretty stupid MacPorts problems, but eventually got things working again, so I figured I would share. My problem started with trying to upgrade curl to support SSL so that I could do git over http yadda yadda yadda. Little did I know that I could have just upgraded curl in the first place, but this serves to address another point. I’ll spare all the lame details, but in essence I got to a point where I was trying to re-install git-core but curl-ca-bundle, a dependency, was failing with this:

$ sudo port install curl-ca-bundle
---> Computing dependencies for curl-ca-bundle
---> Verifying checksum(s) for curl-ca-bundle
Error: Checksum (md5) mismatch for certdata-1.58.txt
Error: Checksum (sha1) mismatch for certdata-1.58.txt
Error: Checksum (rmd160) mismatch for certdata-1.58.txt
Error: Target org.macports.checksum returned: Unable to verify file checksums
Error: Status 1 encountered during processing.
Before reporting a bug, first run the command again with the -d flag to get complete output.

After some googling around, I found the bug and saw that it had been fixed. Great, the fix is only available in trunk. Ok so I’m thinking, I’ll just pull down trunk a build and run it. Why not I like to live dangerously:

Installing MacPorts from Subversion

Nope, that didn’t work either:

$ sudo ./configure --enable-readline
...
checking for existence of /usr/lib/tclConfig.sh... loading
checking for Tcl public headers... /usr/include
checking for tclsh... /opt/local/bin//tclsh
checking for Tcl package directory... /opt/local/lib/tcl8.5
checking whether tclsh was compiled with threads... no
configure: error: tcl wasn't compiled with threads enabled

Not really getting anywhere now am I. Dammit. But after scratching my head for a few minutes, I said, wait… this is all over a few lousy checksums? C’mon…So, in looking at the actual commit from the bug, I saw that it was just an updated Portfile and lightbulbs went off. All I had to do was copy the updated Portfile to my ports tree and port should see the updated checksums:

# cd to curl-ca-bundle
cd /opt/local/var/macports/sources/rsync.macports.org/release/ports/net/curl-ca-bundle

# install package that depends on curl-ca-bundle, in my case, git-core
sudo port install git-core

Seems like if I can’t install git-core, a pretty common package, then a lot of people are probably having this same problem. Hope this helps, I was at a loss for quite a while.

Beer-thirty!

Tags: checksums, curl-ca-bundle, hacks, macports, nerdery, ports

Tab-Complete SSH Logins

A smart guy named Dave Hull (@davehull) shared this piece of bash magic with me a while back and I have relied on it ever since because it’s just that handy. It’s a bit of a stretch to say that typing out “ssh” every time is that annoying, but when you can tab-complete hostnames to login, pure bliss ensues. Ok, so to do this we just need one magical little bash script:

#!/bin/sh
ssh $(basename $0) $*

I usually name this “ssh-to”. Doesn’t really matter though. What matters is how you link it up. But first, make sure this is somewhere in your PATH, like ~/bin and also make sure it’s executable:

mv ssh-to ~/bin
chmod +x ~/bin/ssh-to

Last step is just symlinking to a hostname:

cd ~/bin
ln -s ssh-to some.host.com


And that’s it. You should be able to type “some.<tab>” and the hostname will be tab-completed. Super handy if you’re like me and login to the same hosts frequently.

Tags: bash, handy, ssh, tab-complete

Simple Fix for python-memcached MemcachedKeyLengthError and MemcachedKeyCharacterError

Here at work, we recently ripped out cmemcache and replaced it with the more apache+mod_wsgi friendly python-memcached, only to be innundated with a bunch of these:

MemcachedKeyCharacterError: Control characters not allowed

as well as these:

MemcachedKeyLengthError: Key length is > 250


The good news was that we knew it was definitely related to our new memcache library that Django was falling back on, but the bad news was that we didn’t want to go through all of our code and filter/hash our keys for every call to cache.get() or cache.set(). My simple solution was to write a set of overrides to the default Django memcached backend. I went ahead and gist’d it if anyone is interested:

http://gist.github.com/349692

This solution truncates and filters the keys as opposed to hashing them like some would suggest. I believe either method should work fine for the most part, hashing offering a far lesser chance of key collisions, but I was a little scared to start hashing keys after reading how it bit Reddit in the ass:

http://www.royans.net/arch/reddit-learning-from-mistakes/

This seems to work well at alleviating our python-memcached woes since our keys should be safely unique after truncating. One thing to note though, that took me for a sec (because I was referring to Django trunk) is that `set_many` and `delete_many` are added in Django 1.2, so they will not work unless using 1.2 or unless your backend already implements them. All others methods should work though.

Cheers.

Tags: caching, django, django1.2, memcached, MemcachedKeyCharacterError, MemcachedKeyLengthError, python-memcached