Painless localhost demos

Quick demo?  Easier than heroku?  Look at @ngrok.

I have periodically needed something that lets me painlessly set up a demo from my laptop that I could just email a link to anyone on the internet.

I guess that ngrok.com would be a pretty valuable target to pwn.  Maybe it wouldn't be too hard to install on my own host.

Thanks to @lmonson for retweeting about @ngrok.

xcl: X Clipboard Helper

As a pragmatic command-line user, I just found a new way to easily interact with the clipboard.

Yes, yes, I knew about 'xclip' before now -- but it was just way too hard to use because it made me type (and remember) lots of options for simple clipboard operations.

Introducing 'xcl', a simple, helpful wrapper around 'xclip':

This uses a little-known trick from bash (really from the 'test' or '[' builtin), which allows me to detect whether a file descriptor is attached to a live terminal.

Hope this is helpful to you.

X Clipboard Cleaner

Ever copy/paste from a web page and have the web page's style mess up the document you are pasting into?

That's pretty common for me.

Chrome/Firefox both preserve HTML style when copying text to the clipboard, and the following are common targets:

• email
• HTML-enabled editor widget
• word processor document

My old process was:

1. copy text/link from web page
2. open up a text editor
3. paste inside the text editor
4. copy the same text again, this time without the style
5. paste into the target location

I finally got sick of doing this manually all the time, so I wrote a script and put it in my app launcher bar.

Here is a gist with a script you can download:

Using dot from graphviz

The whole graphviz package is an amazingly useful piece of software.  Especially the dot program.

I've watched other people hand-craft Visio documents that go out of date really fast.

I've also watched developers try to use design tools for high-level sketch kind of diagrams and get bogged down with superfluous code-sync features.

When I want to illustrate a point, just plain old boxes and arrows work wonders.  Especially when I can commit the source and be able to tweak it afterwards.

I've found that dot meets and exceeds the my common use goals.  I would guess that 80% of the time, the diagram communicates what I want to say without any tweaking at all.  About 15% of the time, it takes some layout/shape/font/color tweaking to get the message across in a clear & direct manner.  About 5% of the time, I have to output the graph as SVG and load it into Inkscape for further slight tweaking.

Here are some especially helpful links:

• official site
• gallery of examples, also 
• up-to-date language reference, and other documentation
• outdated, but very well-organized Users Guide
• dot-functions.sh

The last piece of software is intended as a helper for invoking dot quickly from the command line as part of a REPL authoring flow.

To use dot-functions.sh, first download it.  The script defines a bash function that can be used from a bash CLI.  Source it into the current shell by doing: source dot-functions.sh, followed by dot somefile.dot.


Here is the source of dot-functions.sh:

Another very helpful article was written on this topic by Diomidis Spinellis.  Now that I think about it, there is another very helpful article about how to get a hand-written sketch into digital form.

Lazy Developer plus No Slack equals Funding Guilt

I have enough hubris to consider myself a lazy software developer. I also work in an organization where there is not a lot of slack. Overall, I consider myself very blessed to be a part of the software group in which I work. There are many intangible rewards that I receive personally by working on the projects I'm assigned to work on.

Most of what I wanted to say in this article has already been said, so I'll spare you the effort if you're already well-read in this area.

However, the lazy developer / no slack combination often produces an interesting set of emotions within me. In particular, I repeatedly feel a certain ugly kind of frustration.

Here is my shot at defining this certain kind of frustration:

Funding Guilt: n. The feeling of having a sense that you could solve the problem at hand in a better way and more conveniently by inventing a solution to a more general problem, but being in a position where the investment in that more general solution is not specifically funded by the person paying for the specific assignment and might be more costly in the short term.

A lazy developer's answer to this is often to ignore the context and solve the more general problem anyway, with an eye toward paring the problem down to its core and avoiding gold-plating.

I remember working with a very smart developer who told me he kept an open critical bug as cover for getting real work done. If asked what he was spending his time on, he would point to his efforts to solve the critical bug. He would make enough progress on the bug over a period of time that people would continue to leave him alone, because they really wanted the bug fixed as soon as possible. But he devoted a significant amount of his time each day toward his real work. And when that bug got fixed, he'd pick up another serious bug that looked like it could be of use. Maybe this approach could be called "Bug Cover".

Although that approach to avoiding funding guilt is deceptive at its core, it worked for him. I'd prefer a way to avoid funding guilt that was more above board.

And perhaps funding guilt only appears in hyper-responsible people, of which I am one.

For those of us who feel it, acknowledgment of this emotion sometimes helps create a sense of understanding and perspective in ourselves and others, including possibly sponsors of our work. It is important to be able to forgive oneself for funding guilt if solving the more general problem is really the right thing to do. But this is not a resolution to the core question. How can funding guilt be avoided as a matter of course?

Maybe it's a matter of choosing very carefully which projects you work on, or at least aborting unfruitful projects very quickly.

Maybe the proper response to expressed funding guilt is at the core of the art of great software management. Perhaps great managers are those who can create the sense of slack that is needed to allow developers to get their juices flowing and create great stuff.

Even if it does involve a little cover.

P.S. FWIW, many of the ideas in this post come from having read and digested the following:

• Pragmatic Thinking & Learning (personal learning)
• Driving Technical Change (organizational rollout affordances)
• Mythical Man-month (multi-pass thinking)
• using Git on a daily basis (multi-pass thinking)
• Pay to Learn when playing the game of software (optimizing for learning)
• Sooner Not Faster (optimizing for learning)
• Reductionist Agile Manifesto (paring things down to the core)