Friday, April 20, 2018
Hey! I added a light and a dark theme to the page. You can click the bubble next to my name to toggle them. Isn't that awesome!?
In the coming weeks, I plan to blog about some of my projects (don't get too excited, they're mostly small, fun things). Stay tuned.
Thursday, March 1, 2018
- Dan Terminus - Automated Refrains(album)
- John Frusciante - The Empyrian(album)
- Jesus Lizard - Goat(album)
- Melvins - Houdini(album)
- Kyuss - Welcome to Sky Valley(album)
Wednesday, February 28, 2018
I've been thinking about abstraction a lot recently. Mainly in the context of computer programming, but I view life in a holistic manner so maybe these thoughts apply in other areas.
Generally, an abstraction is made to hide complexity. You might want to build a class that can be reused many times. This is generally seen as a good thing. Abstract all the things - it wouldn't do for us to be rewriting the same code over and over again!
The problem that I seem to be encountering quite a lot though, is when the abstraction tries to do too many things. Maybe there are a lot of similar use cases that resemble each other enough to want to cram them all into one abstraction. It appears like this is a tempatation for a lot of developers, but I feel like it's the wrong way to go. I often times find myself reverse-engineering these abstractions (classes, components, etc) in order to account for new business logic, new customer requests, or new use-cases that just don't fit in the context of the abstraction. It can be quite painful.
In the interest of self-presevervation, I've unlearned a few things. Sometimes, a little bit of boilerplate is a better option. Sometimes, sacrificing two extra lines of code that could be eliminated by an abstraction, for the sake of clarity (and posterity) is a worthy tradeoff. Rather than making my code as reuseable as possible, I now strive to make it as clear and understandable as possible, approaching abstraction cautiously and only implementing new abstractions after I'm certain they're required. A hidden benefit of this approach is that I find myself gaining a much deeper knowlede of the problem at hand before I even attempt to shoehorn it into a class somewhere. This makes my solutions neater and more elegant by the time I'm ready to produce them.
In a nutshell, it's not wrong to be cautious when planning your abstractions (classes, components, etc). It's much easier to implement a new abstraction and switch to using it in your code, than it is to crawl your code and unravel a bad or poorly thought out abstraction and remove it.
Thursday, October 19, 2017
- Mastodon - Cold Dark Place(EP)
- Tom Petty - Don't Come Around Here No More
- Tom Petty - Runnin' Down a Dream
- ZZ Top - Gimme All Your Love
- Godflesh - Streetcleaner(LP)
- Baroness - Purple(LP)
- Jesus and Mary Chain - Darklands(LP)
- Isis - Oceanic(LP)
- Devin Townsend Project - Transcendance(LP)