I did a little experimenting with Node.js back when it initially hit mainstream. I thought it was pretty neat, but haven’t really touched it since considering I didn’t have any upcoming projects that would see major gains using it, didn’t have time for the learning curve, and, honesty, wasn’t sure if Node would stand the test of time.
Fast forward a year later and Node and it’s community has grown a lot. Now that I’m messing around with UglifyJS, it’s about time to get down to learning the roots—I know that even though UglifyJS is written in Node doesn’t necessarily mean that one needs to know it to use this utility, but I’m the kind of guy that needs to know everything (like what is Ugly’s relation to CommonJS) and now’s the best time to continue my exploration than ever.
As a starter, Jan Van Ryswyck of elegantcode.com wrote a series of articles on his experience of learning Node, starting from the basics of why use it and what are it’s benefits. Though it’s geared towards Window’s users, it’s still a pretty good read. He goes into the details of the event-driven model of Node (familiar to just about every JS developer), compares it to the traditional thread model, discusses Node’s growing community and open-source plugins, how to debug a Node application, and so on. Here’s a link containing the various chapters: Taking Baby Steps with NodeJS the Towering Inferno.
After setting up a make / jsmin build system for concatenating and minifying CSS files I looked around to see what’s the best compresser to do the same with JS these days and it looks like it’s a toss-up between Google Closure Compiler and UglifyJS.
I’ve heard from two different developers about problems caused by Google Closure compiler: one edge-case where it incorrectly rewrote some JS, and the other about having to write your JS a certain way for maximum efficiency. After reading up on UglifyJS here and seeing how both jQuery and Zepto are now using Uglify (jQuery moving from GCC to Uglify 3 months ago), I think I’ll give UglifyJS a try and let you know how it goes. The readme file that comes with Ugly is in both html and org formats. I’m liking it already…
I finally got my copy of Learning Gnu Emacs back from a friend. I thought I had finished it but there’s a few chapter’s in there that I actually haven’t read.
Something new I learned (and I’m always learning something new despite two-years of near daily use) is the -u flag which allows you to run another user’s .emacs file on a shared system.
While this is great for it’s intended purpose (for example on a shared dev box at work or while pair-programming on a coworker’s machine) I find it also rocks when you need to su to root. Instead of momentarily putting up with plain old vanilla emacs you can load up your personal settings. It’s like going to a friends house and bringing your old lazy boy and direct tv with you (not that I own a TV). Awesome sauce.
Update: If you’re compiling the latest 23.3 version of Emacs with the GCC from XCode 4, you’re probably getting errors. Follow these steps. Better yet, if you already had a newer version of command line Emacs and Lion gave you a 2007 version, edit your /etc/path so your /usr/local/bin in on top and all should be good again.
Update 02/20/12: The curl URL was invalid on this now, so I went and updated it.
curl -O http://ftp.gnu.org/gnu/emacs/emacs-23.4.tar.gz // 45.5MB
tar -xvzf emacs-23.4.tar.gz
// see if it works with src/emacs -Q
sudo make install
// replace cur vers of emacs
sudo mv /usr/bin/emacs /usr/bin/emacs.bk
sudo cp /usr/local/bin/emacs /usr/bin/emacs
If you want the X version of emacs – the one with the ugly square UI, don’t use the
-without-x flag. I’d recommend just using Carbon Emacs in that case, though. If you do compile with X you may run into some errors. You either need to install those missing packages are disable inline-image support with
-with-jpeg=no --with-png=no --with-gif=no --with-tiff=no. For those writing Obj-c I heard
--with-ns flag is cool.
Enter Weinre. Weinre is a beta project written in Java that allows you to have a remote Webkit inspector-style debugging console on your desktop that can communicate with your mobile device. You can send alerts, do full console logging—even inspect the remote DOM tree. It’s in beta and occasionally a little buggy but totally useable.
To use it, run the java server on your local machine and add a single script tag to your project. You can also just download the Mac executable here. The full documentation is here – (its not very straightforward so post here if you have questions.)
At work, we use Charles to redirect production apps to our local dev server. My local server.properties file looks like this:
~/.weinre]$ cat server.properties
Thanks goes to coworker Jim for being the first Guinea Pig to try it out.