Archive for February, 2011

Solution to SASL error while joining IRC from a tethered mobile device: *** Notice — You need to identify via SASL to use this server

Posted on February 25th, 2011 in irc, ssh | 4 Comments »

Update: Apparently this has been fixed in the next Desktop and Mobile version of Colloquy. I found someone linking to this very article in the support ticket. If you want a fixed version now you must build from source, or else just wait until the new version is released and follow the steps below.

I use Colloquy on the Mac to connect to the company IRC channel on freenode. IRC is such an old technology but I find its pretty great for daily company communication. Also when a few people are working on a project together, they can just create a passworded room for quick intercommunication. The only thing it lacks from my previous employer’s method of using Skype rooms is proper logging / history for when you’re not logged in. Still, I generally dig it’s simplicity and people can email if you’re not around. Additionally, I gain the benefit of joining the #emacs or #html5 (etc) channel when I need to solve a quick problem.

During my daily Caltrain commute from SF to Palo Alto, I generally join the chatroom through a tethered iPhone 4. This used to be effortless but in the past two days I’ve been blocked by this strange error:

NICK krunkosaurus
USER krunkosaurus 0 * Anonymous User
NOTICE * *** Looking up your hostname...
NOTICE * *** Checking Ident
NOTICE * *** Couldn't look up your hostname
NOTICE * *** No Ident response
433: * krunkosaurus Nickname is already in use.
NICK krunkosaurus_
NOTICE krunkosaurus_ *** Notice -- You need to identify via SASL to use this server
ERROR Closing Link: (SASL access only)

I did some Googling, and it’s as if Colloquoy thinks I’m going through a TOR server or the like. Googling more I found this tweet where a guy was having the same error on a tethered T-mobile (I’m on AT&T). A member of Colloquy told him to try using an SSH tunnel. (Turns out the real issue seems to be that the IRC clients are trying to connect to your mobile carrier instead of the IRC server – it happens to me on all IRC clients including Adium.)

Anyways, the fastest solution for me was creating a SOCKS proxy via Adium (Colloquy doesn’t have built-in SOCKS support but you can apparently just do regular port forwarding). You do need SSH access to a remote server in either case. The steps are as follows:

1) Open up terminal and type: ssh -vD 6667
2) Open up Adium and go to File > Add Account > IRC
3) Fill in handle and chatroom details
4) In the Proxy tab, checkmark “Connect using proxy” and specify SOCKS5.
5) Server is “localhost”. Port is: 6667.

You should now be able to connect.

Tip: Don’t save this with autoconnect unless you’re always mobile. Instead save this as your “mobile” Adium account which you can switch to from your regular account when you are tethering.

Android web development: Solution for failed ajax calls

Posted on February 23rd, 2011 in android | No Comments »

A port of an iOS game with web views wasn’t working fully on Android devices. I spent a full day debugging this, looking at everything from cross-client / domain issues, bad caching, to other client-related code differences – it’a all webkit right, it shouldn’t be too hard? Something one quickly learns is that web development in Android is 10x harder / slower than iOS since it takes more effort to close apps outright and, most importantly, there isn’t a direct way to set a web proxy (so no HTTP debugging outside of the 1992-era approach of tailing logs on your server.)

Google is aware of this lack of proxy issue as apparent by the bug logged back in 2008 with a few hundred angry comments (and more being added each week). In the meantime Android is quickly becoming the new IE for me.

Anyways, the problem ended up being resolved by commenting out these two lower level ajax settings. iOS works without them, too.

/* self.xhr.setRequestHeader("Content-length", params.length); */
 /* self.xhr.setRequestHeader("Connection", "close"); */

Emacs: changing magit’s default diff colors

Posted on February 22nd, 2011 in emacs | 6 Comments »

Magit is an awesome and relatively easy to use git repository manager for Emacs. I was all about Tig (command line git repo manager) until I discovered this beauty and now happily stay inside of emacs throughout my daily development. It’s default diff colors are bad enough to make you run away from open-source as fast as you can, though. Here’s how to improve it so that it’s the standard red and green like every other diff tool:

;; change magit diff colors
(eval-after-load 'magit
     (set-face-foreground 'magit-diff-add "green3")
     (set-face-foreground 'magit-diff-del "red3")
     (when (not window-system)
       (set-face-background 'magit-item-highlight "black"))))

Notes on installing emacs from source on Centos

Posted on February 18th, 2011 in emacs | No Comments »

tar -xvzf emacs-23.2.tar.gz
cd emacs*.gz

if you get the error: “configure: error: You seem to be running X, but no X development libraries”

yum install gtk2-devel

sudo yum install libXpm-devel.i386 giflib-devel.i386 libtiff-devel.i386 libjpeg-devel.i386

or try:

sudo apt-get install libgtk2.0-dev libtiff4-dev libgif-dev libjpeg62-dev libpng12-dev libxpm-dev

The iPhone’s one fatal flaw: undependable alarm bug

Posted on February 17th, 2011 in Uncategorized | No Comments »

I sit here, waiting for the 10:07am Caltrain cursing my iPhone for a bug I wish was more well published. It’s something that’s bit me a few times in the past with older iPhones and happens when an unconfirmed popup alert will prevent all alarms from going off – this can be a text message alert, battery-low alert, etc. Today it was a Facebook comment alert that just so happen to popup before my morning alarm. Now I’m late for work. I only have myself to blame (I do set multiple alarm sources but one is the radio). Man is this annoying.