Back in the day when there were few to no ISPs in Houston (where I grew up), I used to have an account on cypher.com. Cypher ran a Santa Cruz Operation System V machine, and it was there I cut my Unix teeth.
I would run - inside of GNU screen, of course to account for dropped connections - tin (Usenet News), elm (email), and keep a Terminal open for screwing around in Unix.
It was there that I learned some of the applications that I use in my occupation to this very day. This was the afternoon preluding the twilight of the Internet’s golden age.
For many years I have been an emacs editor user and have scoffed (loudly, with spittle) in the general direction of vi users.
Well this weekend whilst on call I took the opportunity to learn the vim editor. ‘vi’ was my first unix editor (as it is for most people) and I’m now in a position to appreciate vim’s elegance and approach. It’s not emacs, but it’s not a hunk of junk.
In the unix / linux world ( and thus, by extension the Mac OS X universe as well ) there is much to-do made about the choice of text editors.
Why Does It Matter Much of the configuration of these various systems is centered around the generation / manipulation of text-based configuration files.
For example, if you’re on windows and you want to change your timezone you must go to Start Button / Control Panel / Time and Date / Timezone. On Unix / Linux / Mac OSX you simply edit a text file, change the word from PST to CDT ( or what have you ) save the file and you’re done.
Anyone who has known me long enough has likely heard me extol the virtues of Unix or Unix-like operating systems. Largely, their eyes go gooey and I can feel the thought rattling in their head: But can I use Word on it?
[Neal Stephenson][1] writes an excellent explanation about how using unix is
I’ve long known about the technique of SSH Tunneling, but have always considered that a bit of security work that I never needed to do.
This is ignorant.
It’s that same voice that says “screw flossing” or “parking neatly between the lines”. It’s only through willful ignorance or a choice to ignore other data that you would choose not to do this, especially if you hop from public access point to point as I tend to do.
Most internet applications make use of sending their data on a given port. HTTP ( aka what browsers use to transmit data ) operates on port 80, SMTP ( used to send mail out from a non-web client ) uses port 25 outbound, POP and IMAP are used for mail client inbound ( ports 110 and 143, respectively ).
When you work in the UNIX / CLI-environment a simple fact of your work environment is that you simply must have a high-powered text editor to edit configuration files, write code, or write email in a non-GUI mail tool. You have your choice of consumer-targeted editors (pico), but the two that battle for the power user demographic are vi and emacs.
I’m conversant in both and have even written an encomium to the power of emacs on this very site. But I should like to dwell on an interesting aspect of the vi/emacs approaches to doing things.
I had occasion to reflect on vi/emacs as writing tools when I was giving my exceedingly patient girlfriend a bit of a demo of how to use vi ( being knee-deep in drupal, it is something she’s considering needing to know more about ).
It took me forever to get into SCM and I’m really loving Subversion.
…but now there’s git by non other than The Finnish Father of Linux himself. And boy, the world is crazy for it. And github, a place for sharing ideas is certainly in the running to get all sorts of kudos as the greatest addition to the programming world since sliced bread.
I heard about this at Golden Gate Ruby Conf this past year from Ron Evans (@deadprogram). It’s a low-power, low cost computer that can be used for lightweight media centers or “learn to program” desktops.
I love the idea of these little machines lurking about the house doing all sorts of automated stuff for us behind our back. While it’s clearly underpowered to do advanced photo editing, most of our requirements for household computing (yet)
You know this guy?
grep needle haystack |grep special_needle
or his inverted cousin:
grep needle haystack |grep -v unspecial_needle
These are common staples of searching through text files.
You should stop using them. Now.
You can do much better by writing more consice regular expressions and using ack or one of its relatives (ack-grep, or rak).
The primary virtue of these commands is that they use the Perl regular expression engine. Most programmers with experience in any of the major scripting languages will find this more comfortable than grep’s use of the GNU regex syntax.
I recently encountered a need to search through many files based on a complex regular expression that required lookahead and lookbehind asserions.
Introduction For the last year I have been teaching passionate beginners about programming at DevBootCamp. In this time I have come to realize that one of my primary tasks as teacher is to process the patterns and idioms of the computer and of programming languages (as I have experienced them) and rareify them into metaphors that my students can grasp experientially and/or emotionally. Having found an emotional or experiential connection to the rareified metaphor, they are able to condense it back into the universe of text-on-screen where I show the praxis of the metaphor.
The primary advantage to this approach, as I see it, is that even if the praxis of “what to type” or “what is the computer doing” is unclear, having a series of metaphors whereiwth to communicate or reason about the praxis greatly faciliates understanding.
vim has a strange way of working with data from xargs. To make vim happy, you need xargs to send the output into a TTY before handing it to vim. Per the xargs man page:
-o Reopen stdin as /dev/tty in the child process before executing the command. This is useful if you want xargs to run an interactive application. Extract file names based on STDOUT and then throw them to vim via xargs
$ grep -o '\[C.*)' https://t.co/KdKaLY85cm |sed 's/.*(\(.*\))/\1/' |xargs -o vim
This is one of the most valuable graphics ever created. It explains how to move across words, sentences, breaks, etc. on the prompt command line.
https://clementc.github.io/blog/2018/01/25/moving_cli/
Recently I was practicing building an implementation of a binary search tree
(BST), an important data structure often discussed in interviews, in
JavaScript. While iterating, I found the ability to draw pretty pictures
(“directed graphs”) of the structure helpful. This became even more important
when the data collection got big or when the operation got complex e.g. deletion
of an interior node with re-homing of “orphans”.
In this post, I’ll show how to get started with visualizing complex structures
with directed graphs. At the end of this post, you’ll see how I created a BST
from a shuffled Array
of Integer
s and displayed its structure as an image
file using Graphviz. While we’ll be working with a BST, this technique is
helpful for many data structures, and the odd diagram needed to communicate
with your team. Along the way, we’ll see how the approach we’re taking aligns
with “The Unix Philosophy.”
With this knowledge, instead of inspecting a BST like this with console.log()
:
{
root: Node {
value: 33,
left: Node { value: 3, left: null, right: null },
right: Node { value: 72, left: null, right: null }
}
}
we can look at:
That seems easier to reason about to me!
In a previous post, I demonstrated how we can create simple text-based files
that represent directed graphs and feed them to dot
, a program that can
create directed graphs as PNG or PDF output. We wanted to add this capability
so that the “thinking” of the binary search tree (BST) was visible in a way
that helps us learn more about this important data structure.
I’ve cleaned up the ideas in that post and have shared them as a repository.
The branch 01-add-graphviz-printer
has code and tests (npm test
) to do what
was described in the previous post. Emit the dot
source file by running npm -s run dev
(-s
prevents NPM output from going into our dot
source file and
messing it up).
At the end of my previous post, however, I teased that it’d be really great
to be able to visualize the logic behind a BST node deletion operation. By
extending the code on 01-add-graphviz-printer
, I was able to demonstrate what
deletion of a BST node looks like.
Here’s a preview:
After the jump I show the code that made this possible.