Ever found you’ve accidentally entered too many
gits in your terminal and wondered if there’s a solution to it? I quite often type
gitthen go away and come back, then type a full
git statusafter it. This leads to a lovely (annoying) error out the box:
$ git git status git: 'git' is not a git command. See 'git --help'.
What a git.
My initial thought was overriding the
gitbinary in my
$PATHand having it strip any leading arguments that match
git, so we end up running just the
git statusat the end of the arguments. An easier way is to just use
alias.*functionality to expand the first argument being
gitto a shell command.
git config --global alias.git '!exec git'
Which adds the following git config to your
[alias] git = !exec git
And then you’ll find you can
git gitto your heart’s content
$ git sha cc9c642663c0b63fba3964297c13ce9b61209313 $ git git sha cc9c642663c0b63fba3964297c13ce9b61209313 $ git git git git git git git git git git git git git git git git git git git git git git git git git git sha cc9c642663c0b63fba3964297c13ce9b61209313
git shais an alias for
git rev-parse HEAD.)
See what other git alias’ I have in my
~/.gitconfig, and laugh at all the typo corrections I have in there. (Yes, git provides autocorrection if you enable it, but I’m used to these typos working!)
gitback to doing useful things!
I often get asked about why I use Vim as my primary editor, there is no particular reason for this, except that I ended up learning it when I moved over to Linux full time many years ago. I ended up liking it because I could edit my small source files on my quad-core machine without needing to wait forever for the file to open.
Sure Vim isn’t a bad editor, it’s highly extensible, it’s easy to shell out to the, err well shell, its everywhere so when you ssh into some obscure server you can just type vim (or vi) and you’re good to go…
This was a talk I gave at an internal R&D conference my last week at Workiva. I got a lot of positive feedback on the talk, so I figured I would share it with a wider audience. Be warned: it’s long. Feel free to read each section separately, though they largely tie together.
Why do you work where you work? For many in tech, the answer is probably culture. When you tell a friend about your job, the culture is probably the first thing you describe. It’s culture that can be a company’s biggest asset—and its biggest downfall. But what is it?
Culture isn’t a list of values or a mission statement. It’s not a casual dress code or a beer fridge. Culture is what you reward and what you don’t. More importantly, it’s what you reward and what you punish. That’s an important distinction to make because when you don’t punish behavior that’s inconsistent with your culture, you send a message: you don’t care about it…
It’s inevitable these days: we will see an article proclaiming the demise of Ruby on Rails every once in a while. It’s the easiest click bait, like this one from TNW.Now, you may say “another Ruby fanboy.” That’s fair, but a terrible argument, as it’s a poor and common argumentum ad hominem. And on the subject of fallacies, the click-bait article above is wrong exactly because it falls for a blatantly Post hoc ergo propter hoc fallacy plus some more confirmation bias which we are all guilty of falling for all the time.
I’m not saying that the author wrote fallacies on purpose. Unfortunately, it’s just too easy to fall for fallacies. Especially when everybody has an intrinsic desire to confirm one’s biases. Even trying to be careful, I end up doing that as well…
Software engineers go crazy for the most ridiculous things. We like to think that we’re hyper-rational, but when we have to choose a technology, we end up in a kind of frenzy — bouncing from one person’s Hacker News comment to another’s blog post until, in a stupor, we float helplessly toward the brightest light and lay prone in front of it, oblivious to what we were looking for in the first place.
This is not how rational people make decisions, but it is how software engineers decide to use MapReduce…
As an engineer for the U.S. Digital Service, Marianne Bellotti has encountered vintage mainframes that are still being used in production — sometimes even powering web apps. Last month she entertained a San Francisco audience with tales about some of them, in a talk called “7074 says Hello World,” at Joyent’s “Systems We Love” conference.
Created under the Obama administration, The U.S. Digital Service was designed as a start-up-styled consultancy to help government agencies modernize their IT operations, drawing engineering talent from Google, Facebook and other web-scale companies.
Or, as President Obama put it last March, it’s “a SWAT team — a world-class technology office.”
So it was fascinating to hear Bellotti tell stories about some of the older gear still running, and the sometimes unusual ways it was paired with more contemporary technology…
Together with a friend I recently built Dropshare Cloud. We offer online storage for the file and screenshot sharing app Dropshare for macOS/iOS. After trying out Django for getting started (we both had some experience using Django) I decided to rewrite the codebase in Rails. My past experience developing in Rails made the process quick — and boring…
TempleOS is somewhat of a legend in the operating system community. Its sole author, Terry A. Davis, has spent the past 12 years attempting to create a new operating from scratch. Terry explains that God has instructed him to construct a temple, a 640×480 covenant of perfection. Unfortunately Terry also suffers from schizophrenia, and has a tendency to appear on various programming forums with a burst of strange, paranoid, and often racist comments. He is frequently banned from most forums…
Ruby is an amazing language with a lot of interesting details that you may not have seen before…
Here’s a minor mystery:echo •
That last character is U+2022. Select that line with the mouse, right-click, and select Copy to copy it to the clipboard. Now go to a command prompt and paste it and hit Enter.
You’d expect a • to be printed, but instead you get a beep. What happened?
Original question from Quora:
Programmers in our startup usually put 8 hours and go home. I keep reading stories about 80+ hour weeks. How do you make them work longer hours? Do we have to pay overtime? We gave few of them some equity, but it doesn’t seem to work.
I’m going to tell you a secret, so please listen closely.
No programmers really work 60-80 hours a week, especially in a 5 day span. That is a 12-16 hour day, 5 days a week.
I promise you that any company that has programmers “working” that many hours is really only getting 2-4 hours of real work out of them each day. The rest of the time will be filled with pointless meetings, a fair amount of web browsing, and then a whole lot of looking busy…