Emacs Net Utilities

I came across a post by mulander over at My Opera about his journey to Emacs. I found it interesting because it closely paralleled my experience: a long time Vim user moves to Emacs to get Slime. When I did that, I just jumped in and switched to Emacs cold turkey. Mulander, however, started using it “part-time” for specific tasks such as Slime and SQL-oracle mode. Over time he kept discovering new ways to make his work flow more efficient with Emacs. His post has a list of some of the applications that he replaced with Emacs. Be sure to take a look; it’s a worthwhile read.

One of the things I learned about from mulander’s post was the Emacs net utilities. This includes support for (the diagnostic output of) network utility programs such as ping, traceroute, netstat, nslookup, dig, arp, ifconfig and route. It also has native support for finger and whois as well as the ability to connect to a given HOST/PORT. I really love this. I often find myself wanting to ping some other host, check my network configuration with ifconfig, or run a whois. My normal way of doing this is to bring up a terminal and enter the appropriate command. Now I don’t even have to leave Emacs. If I want to check if I’m connected to the outside world, I just type 【Meta+xping and then some external site when prompted1.

The only Emacs documentation I could find for the network utilities is the net-utils.el file. I asked Google and found this nice post from Mickey. Again, I really like this functionality. It’s one more reason to never leave Emacs while I’m working. You can probably find everything you need from Mickey’s post so be sure to take a look at it.

Footnotes:

1 If your system keeps pinging until stopped you will want to set ping-program-options to send only a few pings. You can do that with the configuration facility or by adding

(setq ping-program-options '("-c" "4"))

to your .emacs or init.el file.

Posted in General | Tagged | 2 Comments

How To Really Quit

Brian Zwahr over at Dev and Such shares a very useful tip. Very often you’re in some buffer such as *HELP* and type 【q】 to quit the buffer. This, however, merely buries the buffer. Most often you want to get rid of it entirely. It turns out there’s a way to do that: instead of 【q】, type 【z】. That will delete the buffer entirely.

Sadly, this doesn’t work with Info, which is where I most often want to delete the buffer because they tend to be large. Even so, this is a very useful thing to know.

Posted in General | Tagged | Leave a comment

An Interview with François-René (Faré) Rideau

Vsevolod Dyomkin over at Lisp, the Universe and Everything has posted another in his series of interviews with Lisp luminaries. This time it’s with François-René (Faré) Rideau one of the key developers at ITA and an author of the Google Common Lisp Style Guide that I wrote about recently.

Rideau talks about life at ITA before the acquisition. What he has to say will be familiar to many of us. He also talks about his work on ASDF 2 and how he came to work on it. All in all, it’s an interesting interview and worth a read by all Lispers.

Posted in General | Tagged , | Leave a comment

Storing Passwords Securely

I’ve written several posts about securely storing passwords (this one for instance). Here’s a video from Stormpath featuring their CTO Les Hazlewood that covers the same material for those who prefer a visual presentation.

Hazlewood covers various levels of password storage security from storing passwords in plain text, to systems such as bcrypt, to encrypting the bcrypt output and distributing the results to several different servers. If you want to know how to store passwords correctly, this is an excellent video and well worth a half hour of your time.

Posted in General | Tagged | Leave a comment

Emacs Movies

How did I miss this? Noufal Ibrahim is producing a series of videos on using Emacs. The plan calls for four sections:

  1. Basics
  2. Applicaations
  3. Programming
  4. Elisp

So far, he finished Section 1 with a total of 10 videos. To give you an idea of what he’s covering, here’s a list of the videos in Section 1:

  1. Terminology
  2. Navigation
  3. Editing
  4. The Region
  5. Buffers
  6. Registers and Bookmarks
  7. Minor Modes
  8. Customisation: Part 1
  9. Customisation: Part 2
  10. Keyboard Macros

I’ve watched 1–6 and 10 so far and have been impressed. Ibrahim covered many of the Emacs tricks that I’ve posted about in this blog and a couple of things I didn’t know. The longest video I’ve watched was #4 and that was about 20 minutes. The others are shorter so it’s easy to do one or two a day when you need a short break. They’re well done so it’s worth the time. Ibrahim is also producing a book to go along with the videos but he gave up trying to keep them in sync so the book is lagging behind the videos.

I’ve enjoyed the videos and learned a couple of new things so you should go on over and take a look.

Posted in General | Tagged | 1 Comment

Some Tool Tips

As long time readers know, I am always looking for ways to make my work flow more nearly frictionless. This mainly involves adapting my existing tools (especially Emacs) and adopting new tools. I recently came across a couple of posts that address these. Since they seem generally useful, I thought they were worth sharing.

The first, 10 Tools, Tips,and Tricks to Hack Your Workflow, by Dann Berg looks at 10 tools that he uses to make his day more efficient. These range from Credit Karma—used to track your credit rating—to the excellent (Mac OS X based) Quicksilver. I already use a couple of tools from his list and am planning to check out a couple of others. This is a reasonably short post that gives reasons for his recommendations. The post is well worth a look; you may find something you’ll find useful.

The second post, 9 Enhancements to Shell and Vim Productivity, by Daniel Miessler addresses ways of adapting tools you may already have or replacing one tool with a similar, superior one. Obviously Miessler is a Vim user so the righteous will skip over those tips (although Vim users are apt to find them useful) but he has some good ideas. Again, this post is worth a read

Posted in General | Leave a comment

mu4e

DJCB over at EMACS-FU is announcing the release of Version 0.9.9 of mu4e, his Emacs-based email client. It looks good enough that I am tempted to give up the native Mac email client1. It has dynamic folders that will move messages to different folders depending on context. You can write Elisp functions to control that context so it’s very flexible.

A related feature is refiling that will automatically store received messages based on context. Usually you would want this based on the sender’s email address but, like dynamic folders, it’s configurable by writing Elisp code so should handle special requirements easily.

The most significant feature for me is the encryption/signing functionality. DJCB says that it’s still a little rough but rough is better than none at all which, as the footnote explains, is the predicament that OS X 10.8 users find themselves in.

Head on over to EMACS-FU and take a look at the new features (or see the NEWS file) for mu4e. It looks like an excellent application.

Footnotes:

1 Especially since the GPGmail plugin that supports encryption and signing doesn’t work with Mountain Lion. That has stopped me from upgrading while I wait for the fix.

Posted in General | Tagged | 1 Comment

Comment Spam

Patrick Lambert over at Dendory Blog has a really nice solution to comment spam. He noticed that he never receives any comment spam and decided to investigate why. It turns out that his immunity is an artifact of the way he handles comment submission on his two blogs.

Spam bots work by reading the HTML for the comment section, capturing the variable names for fields, and then sending the data to whatever blogging engine the site uses. Lambert’s sites post comments by calling a Javascript function that internally renames the variables. That means that the spam bots are using the wrong variable names when they try to send the data directly.

Head on over to Lambert’s post for the details. If you’re writing your own processing code this is a technique worth knowing about. If you can write in PHP, perhaps you could even modify a WordPress site although that would introduce a maintenance problem. We could, I suppose, ask the WordPress folks to do something similar but as soon as the practice became widespread we’d see the scum spammers adapt.

Posted in General | Tagged | Leave a comment

The Google Common Lisp Style Guide

Google has made their Common Lisp Style Guide—presumably from ITA—available to the public. As with any style guide, almost everyone will find something to disagree with but by and large it appears to be a very reasonable compendium of best practices. One of the things I like about the guide is that it gives a rationale for each of the rules. That makes the guide feel more like “best practices” than a diktat from the suits.

ITA, of course, is the canonical example of a commercially successful company that used Lisp to solve a large, complicated problem so their take on best practices deserves the respectful attention of all Lispers. If you write in CL, you should take a look at this guide; it’s got lots a useful ideas.

Posted in Programming | Tagged , | 1 Comment

Motown

Matthew Beale has a really interesting post over at madhatted.com that concerns lessons we can learn from Motown. The “we” in question is the software development community. The post is interesting on its own terms but what really struck me was the story of how Motown worked. Those of us of a certain age are very aware of Motown. They were the record label for groups such as the Supremes, The Four Tops, The Jackson 5, and many, many others. Motown had the highest hits to released singles ratio in history. They had 30 #1 hits during the 1960’s.

For most people that’s ancient history yet as Beale notes they have something to tell us. Here’s how Motown managed to crank out all those hits:

  • Each writing/producing team was required to write 5 new songs a day.
  • At the end of the week, each team presented their 5 best songs to the other teams.
  • Each team got to record their 2 best songs of the week.
  • Each recorded tune was mixed, usually about 15 times by different people.
  • Each mix was turned into a record.
  • The quality control department listened to each record and picked the “A” side that was released and promoted.

This process was so efficient that The Four Tops hit It’s the Same Old Song took just 24 hours to go from writing to release to DJs. That’s really astounding. When was the last time you were able to get anything through the pipeline in 24 hours?

Be sure to read Beale’s post to find out more about the Motown process and what it can tell us about our own processes. Even if you’re not a software developer, you’ll enjoy learning about how Motown managed to turn itself into a hit machine.

Posted in General | 1 Comment