trial and stderr

This is my main workflow when using git.

(master)$ git pull
(master)$ git checkout -b my-feature
# make changes
(my-feature)$ git add [changed files]
(my-feature)$ git commit
# repeat the above as needed
(my-feature)$ git fetch origin
(my-feature)$ git rebase origin/master  # try --interactive some time, it's fun
(my-feature)$ git push [origin|upstream|fork] my-feature
# open a PR
# make some fixes
(my-feature)$ git add [changed files]
(my-feature)$ git commit
(my-feature)$ git push [origin|upstream|fork] my-feature
# uh-oh, need to resolve conflicts with master!
(my-feature)$ git fetch
(my-feature)$ git rebase origin/master --interactive
# fix conflicts
(my-feature)$ git rebase --continue
(my-feature)$ git push [origin|upstream|fork] my-feature --force  # never force master
# ok, my PR's merged, all done with that branch!
(my-feature)$ git checkout master
(master)$ git pull
# and we begin again

I've regularly been seeing help threads from people who somehow wind up hundreds of commits "ahead" of master. I don't know how you get git into such a mess, but hopefully the workflow above helps more people avoid it.

Something or other has lead me to reading a lot about bad abstractions lately, including a famous article where Sandi Metz writes

duplication is far cheaper than the wrong abstraction

I want to add that it's not just a matter of choosing between two cognizable options. It's that all programmers chronically underestimate the difficulty of inventing new abstractions. We need to take that into account in deciding whether to take the leap in the first place.

I want to reframe the idea of "factoring out common code" and "avoiding copy-pasting." Every time you do one of these simple-sounding things, you are actually inventing an abstraction. You are engaging in the most intellectually demanding act of software engineering. It involves balancing the predicted cognitive load which exists outside, via, and inside your abstraction. It requires you to predict the future about business requirements and code that is yet to be written. On top of all that, it is a test of your mastery of technical jargon, of grammatical norms in programming, and of the English language itself.

Naming has been compared in difficulty to cache invalidation, and yet I don't seem to be surrounded by half-baked attempts at cache implementations.

When Kent C. Dodds says to Avoid Hasty Abstractions, remember that he is a famous expert programmer. "Not hasty" for him sets a pretty high bar for you and me.

This is something that Browsersync does  (among probably a lot of other things).

Install with

npm i -g browser-sync

Serve the contents of the current directory with

browser-sync start -s --https

No setup required. See the docs for other features. You probably want the --cors flag.

Here's my attempt at the most compact description of Javascript module systems on the internet:

ES6 (aka ES Harmony)

import a from 'b'
export c

CommonJS

var a = require(‘b’)
exports = c

CommonJS is synchronous, and supports one file per module.

NodeJS is a CommonJS variant

var a = require(‘b’)
modules.exports = c

AMD

define(['a', 'b'], function(a, b) { return c })

AMD supports multiple files per module.

RequireJS is a loader that implements AMD and loads plain JS files as modules

If you've tried to make formulas in Google Sheets using the ISBLANK() function, you probably have noticed its wildly unintuitive behavior: it does not consider "" as blank. No, that's not two visible quotation marks – that's the presence of the string delimiter. So cells with the contents (omitting the initial " used to display the formulas)

resolve to

Despite this somehow charmingly condescending attempt to explain, you're correct in identifying this behavior as wrong. It's the wrong thing to do; it's bad design.

To mitigate this problem, use EQ(LEN(A1), 0), which does what you expect.

I think the best piece of advice I could give to someone considering doing an R project of more than twenty lines of code is the following:

Don't. Use Python with Pandas.

I have many beefs with R, but the main one is the type system. It is nearly impossible to predict what most functions will do based on their type. This is largely due to the fact that everything is a vector, so it's ambiguous whether a function operates on a whole vector or on each of its elements.

Also, the vector might accidentally be a factor, which behaves differently from a normal vector. Casting from a factor to a numeric vector, like much of the language, does the least intuitive imaginable thing.

All of the more complex structures are extremely wiley. Data frames behave in absurd ways. They were badly designed. The whole language was badly designed. That's why tidyverse was invented, with tibbles as a nice replacement for data frames. But few functions outside the tidyverse document their behavior when run on tibbles, and very often you'll get a data frame out the other end.

The debugger is awful; breakpoints cannot be set from sourced files. The typing difficulties make this especially egregious.

There is no namespacing; you must invent it yourself.

Even the basic types behave in absurd ways:

> "111" > 27
[1] FALSE

In short, even once you have a good grasp on the syntax and some of the usual operations, it is incredibly difficult to predict what any given R statement will actually do. It's like solving a puzzle in the dark: you will know when you have the right piece exactly when it snaps into place.

If you've used GNOME extensions for more than a few months, you've probably realized that they can easily send your desktop into a hellish crash-on-login loop that can only be remedied by dropping to a root shell.

This is obviously insane and awful, but is also wholly predictable. GNOME is written in JavaScript, and the official GNOME extension "mechanism" is that arbitrary JavaScript is allowed to mess with your GNOME environment. When an update introduces an incompatibility and something goes wrong, GNOME crashes. It's like a handful of mechanics are continuously making modifications to your car without talking to each other, and there are no seat belts.

I got tired of GNOME crashing every other day, so I disabled extensions. The thing I really missed, though, was an always-visible system resources monitor. Turns out there's a nice way to get one!

The answer is a minimalistic terminal emulator called Tilda. Here's the bottom-left corner of my screen.

I'll walk you through setting this up.

Install Tilda and htop (or whatever you'd like to run in your widget) and open preferences. Go to the "Title and Command" tab, tick "Run a custom command...," and enter htop for the "Custom Command."

Configure htop by hitting F2 (if you like what I have going, you can use my htoprc).

Once you get it right, go back to the Tilda preferences, go to "Appearance" and get it to appear at the size and position that you like.

Then from the GNOME launcher, launch "Startup Applications" and add a startup program with command tilda.

There you have it!