For now, this site serves as a combination of a blog and wiki, allowing me to share reference information that might be useful to others, with some opinionated commentary mixed in.
I have a strong preference for tools that are lightweight and have as few dependencies as possible. I prefer functionality over design. In my opinion, too much effort (unsuccessfully) goes into making things look nice, and too little effort goes into providing the most convenient and correct functionality. Projects that start with good intentions balloon into frankenprojects because it feels good to say, "It can do that."
My philosophy is that a major new feature means it has become a new project. Go ahead and rewrite the code. You can still maintain the old version, under a different name, but if you don't want to rewrite code and implement a major redesign, then you probably shouldn't be adding the new feature. If you're not willing to break compatibility with the old version, you probably shouldn't add the new feature.
Don't use Git just because everyone else does. Git is way too complicated for small software projects, the vast majority of which have little in common with Linux kernel development by thousands of anonymous developers. Fossil comes with an integrated wiki, bug tracker, and web server.
I prefer Skeleton to Bootstrap both because it's faster and because Bootstrap is a complicated behemoth. If I'm running Twitter, I'll use Bootstrap, but for now I'll stick with something easy. You can find a list of small CSS frameworks here
This is the reference compiler for the D programming language. You get the speed of C but loads of additional features. In my case, I use it because it is so easy to interoperate with C libraries and to call it from other languages. Oh, and I love that it's got a garbage collector (it can be disabled if you want, but for most of us that's not relevant).
One area where I disagree with the community is the use of Dub. I'm sure it's wonderful for big projects. I don't like it. I don't think a small program should require a configuration file. Dub is tightly integrated with Git (currently all official D packages have to be in a Git repo). The end result is that there is a feeling that it's okay to add more files, more directories, and more dependencies. Integration with Git means new users bump into terms like "Git submodules". To be honest, if your goal is to recruit new programmers to a language, the last thing you want to do is require advanced Git knowledge. In my opinion Dub will drive away new users because it imposes an astonishing learning curve.
A better approach is to have one or a few large files and compile using a command like
dmd program.d dep1.d dep2.d
. I will never win that argument though. Dub has an almost religious following in the community. The good news is that you don't have to use it, and I don't.
Discussion of The Awk Programming Language on Hacker News
. Links to a free PDF of the book.