Inspired by Kendra Little’s recent post My Git CLI Cheat Sheet, I decided to do a little write-up about how I use git on my computers.
The Shell First off, I don’t use git without some serious shell customizations. I like to be able to the local git status just by pressing enter in the shell when I’m being super lazy.
On macOS and Linux I use the ZSH shell with the powerlevel10k theme.
Not all processor architectures support the division operation. What if you’re writing software for one of these CPUs and you need to support arbitrary division? We’re in luck: we can perform the same operations that the CPU would perform.
I make use of emacs - my ability to customize the editor has made it easier for me to be productive. Switching between windows has always been a bit annoying in emacs. After reading Managing Emacs windows, I figured that I would give the ace-window library a try to see if it could solve my problems. After downloading ace-window and dropping the file in my .emacs, I was ready to go.
Chrome has a reputation for being incredibly unstable on Linux. It’s been rock solid for me on other platforms, but on Linux (Arch, Ubuntu 14.04 LTS, and Ubuntu 14.10), I run into the “sad tab” multiple times a day. Since I use Chrome as a mail client, music player, word processor, calendar, and television, it’d be nice if it worked once in a while. Where a reasonable person would switch over to Firefox, I started digging to determine the cause.
What’s the point of an average, anyway? Common knowledge (the 1967 Children’s World Book Encyclopedia) states that an average has something to do with an arithmetic mean and/or a “central tendency”. I’m pretty sure that a “central tendency” is a sly sexual reference, so we’ll go back over to mathematics being mean.
What’s an Average? An average is the sum of all numbers in a sequence divided by the count of all numbers in a sequence.
The email started with “Your AWS account is compromised”. That’s the kind of thing that makes you stop whatever you’re doing and sit bolt upright. Amazon Web Services emailed me because one of my secret account keys had been posted to a publicly accessible web page - in this case, it was a github repository under my account. It seems that I had accidentally committed my AWS access keys to a git repository hosted on github.
Let’s say you’ve gone and contributed to a project that’s hosted on GitHub. The usual way to do this is to fork the repository, make some changes on a branch in your own repository, and then send a pull requestback to the original author. What if you need to change something after you’ve submitted a pull request? I ran into this situation the other day after submitting a pull request to the basho_docs repository - there were some clarifications needed to the C# Taste of Riak.
I’m not referring to sensible naming conventions like “table names are always [singular|plural]” or “method names should be short but descriptive.” Those naming conventions are fine. They’re safe. They protect us from the stupidity of future generations of us (or at least uncaffeinated versions of ourselves). Poisonous naming conventions are the naming conventions that assume something about the physical implementation of a thing. When you name an attribute DCreatedAt because it’s a date, or objAppointment because it’s an object, or even when you name a table t_Users or tbl_Permissions, you’re poisoning the world.
These aren’t all of my goals, to be sure, but I thought that it’d be a good idea to get some of them out in public and start sharing a bit more.
Be More Personal I want to be more personal on this blog. Historically, I haven’t injected a lot of my personal details into my writing. I did it a few times last year when I talked about a bit of personal history and again when I talked about leaving the PASS Board of Directors.
