Here’s a nice tip on how to get rid of a dired
buffer by killing it rather than burying it.
I really like that C-u q in dired kills the whole buffer. #emacs
— Marco Wahl (@marcowahlsoft) February 17, 2015
dired
Buffers Here’s a nice tip on how to get rid of a dired
buffer by killing it rather than burying it.
I really like that C-u q in dired kills the whole buffer. #emacs
— Marco Wahl (@marcowahlsoft) February 17, 2015
Fighting down my urge for a terse binary encoding and embracing s-expressions for network transport is helping a lot with development.
— John Carmack (@ID_AA_Carmack) March 17, 2015
For an wonderful and revealing example of using s-expressions for data interchange, see the paper I discussed in this post from my old blog.
I’ve written before (1, 2, 3, 4) about the insanity that is the open plan office. One would think that it would have withered and died by now but, sadly, it seems as robust as ever. At least the successful tech giants understand how deleterious it is, right? Nope. Facebook’s new office space will include a single giant 10 acre room for all 2,800 of their engineers. I can’t conceive of working in such an environment or why anyone would think it’s a good idea.
Over at Stack Exchange they still believe in private offices but note that the once revolutionary notion that Joel implemented makes them feel sort of old fashioned: like something that Microsoft does. You can read that post to see why it’s so successful for them. It helps explain Fog Creek’s and Stack Exchange’s success.
Now, finally, some tech firms are beginning to notice that the emperor has no clothes. Wildbit is abandoning their open office layout for private offices. Chris Nagele blogs about it and lays out the reasons for the change. It’s a good read so you should take a look. Meanwhile, Matt Blodgett has pictures of some of these open office layouts and proposes a game called “spot the desks.” In every case you see really nice looking offices but when you start looking for the desks, you find they’re all packed together as if a second thought.
Reading the comments to these posts I was a bit surprised to find that even some engineers are buying into the “improves communication” nonsense. Lots of people have all sorts of anecdotes about the virtues of open office spaces but Microsoft and others have done actual research and found that they’re disastrous for worker productivity and health. So much so that they’ve gone to the expense of building out private office for their developers.
Of course, none of this is news. Demarco and Lister knew all this 37 years ago. I was working in a cube farm when I first read it and loaned it to our CEO hoping that things would improve. The only thing that changed is that I no longer had a copy of Peopleware because he never gave it back.
Still, Wildbit and others like them give hope that sanity will eventually prevail. If that happens, I wonder what Zuckerberg will do with that big room.
Update: Just today, I had occasion to reread Paul Graham’s Great Hackers in which he says
After software, the most important tool to a hacker is probably his office. Big companies think the function of office space is to express rank. But hackers use their offices for more than that: they use their office as a place to think in. And if you’re a technology company, their thoughts are your product. So making hackers work in a noisy, distracting environment is like having a paint factory where the air is full of soot.
The cartoon strip Dilbert has a lot to say about cubicles, and with good reason. All the hackers I know despise them. The mere prospect of being interrupted is enough to prevent hackers from working on hard problems. If you want to get real work done in an office with cubicles, you have two options: work at home, or come in early or late or on a weekend, when no one else is there. Don’t companies realize this is a sign that something is broken? An office environment is supposed to be something that helps you work, not something you work despite.
Notice Graham is complaining about cubicles. It would be interesting to read his thoughts on a huge 10-acre room at which developers sit at big tables. The point stands though: as Graham says, if you arrange to have your developers be interrupted continuously, don’t expect good results.
A customer walks into a bar. He asks for a beer made out of wine. The project manager agrees. Both question the bartender's competence.
— Daniel Méndez (@mendezfe) March 22, 2015
I just wrote about implementing abo-abo’s solution for having multiple Info buffers and in particular his using the gcl
Info file as a substitute for the Common Lisp HyperSpec. I really wanted to try that out so I downloaded the tar
file from the link that he provided and installed it in my .emacs.d
directory. Then, as abo-abo explained, I added ~/.emacs.d/info
to the Info-additional-directory-list
variable.
Sadly, it didn’t work. I asked abo-abo for his wisdom on the matter and he suggested that I just push the .emacs.d/info
directory directly onto the Info-directory-list
. I tried that and it didn’t work either. I could get to it with the standalone Info reader by using the -f
option but couldn’t get to it from Emacs.
The problem was that the gcl
file was not being added to the dir
file that serves as the top node for Info. The proper way to do that is to run install-info
. In my case
sudo install-info gcl.info /usr/share/info/dir
Annoyingly, it still didn’t work. It turns out that install-info
extracts data from the Info file you’re installing to update the dir
file. For some reason the gcl.info
file didn’t have the required information. I adapted the information from the sbcl.info
file, added it do gcl.info
, reran install-info
, and everything worked fine. Unless you’re trying to use the gcl.info
that abo-abo linked to, you don’t have to worry about that; just run install-info
.
If you’re trying to install the gcl
file, here is what you need to add to the top of gcl.info
INFO-DIR-SECTION Software development START-INFO-DIR-ENTRY * gcl: (gcl). The GNU Common Lisp compiler END-INFO-DIR-ENTRY
A few months ago, I wrote about mbork’s method for having multiple Info buffers. It was a nice solution but required learning a new key sequence for every Info buffer you wanted a quick link to. Abo-abo liked the method too but he also found that he tended to forget the key sequences.
Abo-abo neatly solved the problem by integrating mbork’s method into a hydra. It’s a neat solution because he invokes the hydra from any Info screen with the single keystroke 【t】. From there, he simply selects the desired Info file from the menu. He can have any number of Info buffers without worrying about remembering a lot of (probably) seldom used key sequences. It’s a nice solution and I’m planning on implementing it on my systems.
Another nice thing that abo-abo pointed out in his post was that the gcl
Info file can serve as an Info-based HyperSpec. He explains how to get the gcl
Info file and install it. If you’re a Common Lisp user, this is very nice. It’s not the HyperSpec, of course, but has the same information. I’m also planning on implementing that and trying it out.
If you use Info or if you’re a Common Lisp user, you should give abo-abo’s post a read.
Speaking of nosy Parkers, the Open Web Alliance is annoyed that HTTP/2 will make it harder for them to spy on you and is lobbying against mandatory encryption in HTTP/2. Sadly, they’ve won the first round.
The Open Web Alliance membership includes many of the big ISPs, tech giants such as Oracle and Intel, and law enforcement such as The Department of Justice and Public Safety Canada. Their rationale for wanting to spy on us is the usual high minded sounding drivel about traffic engineering and thinking about the children.
What they really want, of course, is to harvest and sell our personal information or, in the case of law enforcement, to be able to monitor everything we do in case we have an impure thought. We will, I’m sure, be hearing more reasons why it’s for our own good that corporations and the government be able to spy on us. Dismiss them for the nonsense that they are.
Nava Whiteford over at 41j has a useful list of common Git problems and their solutions. It’s almost like a mini-recipe book. For example, what if you made a mistake in your commit message? Whiteford tells you to use the Git amend command. Or worse, what if you want to get rid of your last commit? Again, Whiteford tells you what to do.
The list is a great resource and should be especially helpful if you are a casual Git user. It’s easy to handle almost everything you need to do with Magit (say) using a very few basic commands. Occasionally, you find yourself in an unfamiliar position that you need to escape from. It doesn’t happen often enough that you become familiar with the solution and that’s when a list like this is irreplaceable.
In keeping with the git recipe book theme, we also have this list of git recipes from Casper Beyer. It fits right in with Whiteford’s list.
Irreal regulars know that I use Org mode for almost all my writing. There are these blog posts, of course, written with Org mode and published with org2blog
but also reports, letters, and pretty much everything else. Org mode is very flexible and can produce HTML or, via LaTeX, PDF1.
Not everybody is convinced, however. RMS famously doubted that Org mode was up to producing Emacs documentation. Others insist that you have to use Word or LaTeX for serious documents.
Katherine Cox-Buday has a nice post that should help put an end to those doubts. She writes specifications for Canonical and uses Org mode to quickly produce very polished documents.
As an example, she starts with a toy specification written in Org mode and shows how its looks when it’s exported to PDF. It’s not bad but with a customized LaTeX document class, the same input produces a beautiful document that looks as if a lot of labor went into its formatting. In truth, the source was just a simple Org document.
Read her post to see both outputs. Perhaps it will give you some ideas for your own documents. More importantly, though, it shows how Org mode with its light-weight markup can produce beautiful documents quickly and easily.
And lots of other formats, of course.
I’m writing this on my MacBook Pro, a small, light-weight laptop that has 16 GB of memory. Nothing I do on it ever runs out of memory. It wasn’t always that way, of course. Bill Gates famously quipped that he couldn’t imagine why anyone would ever need more than 64 KB of ram1. We’re a long way from MS-DOS, of course, but my last laptop had only 2 GB of ram. It seemed like a lot when I got it.
In the old days, even mainframes had limited memory and people writing in C learned how to layout their data structures so that they would use minimal memory. It’s not something that I’ve worried about for some time but once it was second nature to think about such things.
Occasionally, the need to worry about memory comes up even today. Most often it’s a problem for embedded systems programmers but even programs on “normal” machines that deal with huge data sets can have problems. Eric Raymond, esr, ran into that with his cvs-fast-export
program that he wrote to help with his conversion of CVS repositories to Git. When dealing with large repositories, he would routinely run out of memory. By a careful rearranging of his structure definitions, he was able to reduce his memory footprint by 40%
Sadly, knowledge of these techniques is dying out but sometimes they are still necessary. Happily, esr has written a document that explains the methods. They aren’t that hard and if you are a C programmer you should take a look at esr’s writeup and bookmark it for the time that you need it. If you’re writing in something like Python or Ruby, you won’t need the techniques directly but you may still find them useful for furthering your understanding of what’s happening under the covers.
EDIT That should be 640K, of course. Jean-Philippe Paradis wrote me to call the authenticity of the quote into question. Gates denies saying it although anyone familiar with modern PR-speak would hardly find that dispositive. As far as I can tell, the authenticity remains unsettled. It may well be like the story of Mittag-Leffler and why there is no Nobel Prize in Mathematics: too good to question.