A global .gitignore

A small tip that I've come across recently: It is possible to have a global .gitignore file that applies to every Git repository on your machine.

Start by making a .gitignore file in your home directory, with the files you want to ignore, and place in your home directory:

# ~/.gitignore

.vimrc.local
*.swp

.idea
.DS_Store

Then, tell Git to use this file as global .gitignore by running in your shell:

git config --global core.excludesfile ~/.gitignore

You can also take inspiration from my own global .gitignore file. Enjoy!

What is Code

I love how simple and clear this explanation of code and programming is and wish I could have read it when I first started.
This particular part seems obvious in retrospect, but would have helped grasped coding earlier than I did:

A programming language has at least two jobs, then. It needs to wrap up lots of algorithms so they can be reused. Then you don’t need to go looking for a square-root algorithm (or a genius programmer) every time you need a square root. And it has to make it easy for programmers to wrap up new algorithms and routines into functions for reuse.

Paul Ford, What is Code

State

There’s no intrinsic idea of state from this perspective. There’s just a change in an input resulting in a new output. State might be an implementation detail with how the app handles its inputs, but it’s not necessary. It’s not intrinsic to the idea.

Most problems worth solving have some intrinsic state. State can be essential. But that’s not how we treat it. We solve everything with state. Because we treat all the inputs to our app as different things—a touch event here, a web response there—we can’t combine them in any meaningful way. We can’t transform them uniformly. And so our only tool for dealing with all these different things is state. When our only tool is state, every problem looks like a stateful nail.

State is bad. State introduces complexity. And worse, it introduces complexity that grows more than linearly with the size of our app. We’re in the habit of constantly introducing more state into our app. New feature? New state. New complexity. New bugs.

But happily this perspective of our app’s output as a function of its inputs over time gives us a new tool: functional reactive programming. Functional reactive programming (FRP) is a paradigm built around the idea of time-varying values produced by time-varying functions.

Josh Abernathy, Input and Output

The Programmer's Dream (A Ramble)

We spend a good deal of our time working on code we didn’t write for software we didn’t create, much of which we believe is horribly written (or, at least, could be done much better). We dream of a chance to start fresh, working from scratch on a brand new piece of software that will eventually become something someone else has to work on and believes is horribly written.

— Nick Bradbury, The Programmer's Dream (A Ramble)

Code of Ages

In war, as George Orwell had it, the winners write the history books. In tech, the winning companies are writing the programming languages.

— Scott Rosenberg, Code of Ages