Doing the 1st massive re-factor of someone else’s code in a few years. Very draining but there is a light ahead, hopefully not a train.
New personal project also means a streak on github longer than 5 days for the 1st time if not ever.
Also love the opportunity to be using fave db, PostgreSQL, again, even if it’s only a personal project.
Sometimes I hate docker, other times, love it. Case of the latter, so much easier to set up db’s for development with docker.
Digging into WebSockets, using support in Sails.js. Very nice. Fits in well with this React front end.
Finally starting to work on a side project, the idea for which has been stewing for a while.
(I first shared this essay in a recent podcast.)
An online acquaintance, Reg, made my day a while back by posting this tweet:
I was glad to see that I am still having a positive impact. When I started to think about it some more, though, I wondered just how much lately I had been living up to my saying. Especially when it comes to this site and podcast, I didn’t feel like I was doing a good job. Up until recently, for the better part of a year, posts and episodes had been few and far between.
Sure, there are reasons for that. I have written a few posts discussing them. Despite those reasons I had intentionally been keeping at my pastimes even if it didn’t show. I kept going to my guitar lessons every Sunday and practicing almost every day. I tried to keep writing although with less success. I started baking and re-dedicated myself to brewing. I undertook an experiment in podcasting that worked out so well, it has helped me re-invigorate the show I have been making for over a decade.
I didn’t think about it that way at the time, but the deliberate choice to make myself pursue my hobbies was a hack. I worried that in the face of stress, I would shut down. I didn’t want my world to be solely defined by my difficulties and my struggle to cope. Several other intentional choices or practices snapped into the same focus. I was delighted to realize I could be living up to one of my ideals even though I had not been giving myself the conscious credit for doing so.
My choice felt hacky in another way. Not all hacks are elegant even if they are effective. Early on I am not sure I really enjoyed or held much enthusiasm for my pastimes. Forcing myself to work at my various hobbies helped on one level. I felt a sense of accomplishment. I had things to talk about with co-workers, acquaintances and friends that were about something other than my family’s travails. But joy? Until lately, not really.
The silver lining of a bad hack is it contains the seed of the next hack, the dissatisfaction that prompts a re-think and overhaul that hopefully leads to something better to take its place. Only in the last few weeks have I realized how bad this hack was, namely how the lack of joy was affecting me. It sapped my desire to work on anything truly creative or hard, like writing. As much as I felt like I was coping I didn’t feel like I was really getting all that much better at truly getting above the stresses in my life.
There was one exception to my pursuits feeling rote or forced, brewing. It almost didn’t end up being a cause for joy. My friendship with my long time brewing partner ended last year. That could have been cause to give up, to close that chapter of my life and move on. I wasn’t brewing as often as I had even two years earlier. The bottling dates on the beers in my cellar showed the time between each brew getting farther apart. That bothered me, not having home brew on hand as often as I wanted to share or enjoy it. I already had the motivation to start brewing more frequently. I just needed to figure out how to do that on my own, with or without the assistance of anyone else.
At the end of last year with this thought in mind I researched upgrades to my equipment and my process. Before, I needed at least one willing volunteer to help me complete a batch. I still planned to invite friends to the new brew days. Whether anyone showed up or not, I wanted to be able to make a beer. I saw the invitations as an opportunity both to re-connect with old friends and to nourish sustaining friendships. I changed those parts of the process that used to rely on help from other people to use new equipment instead. I added two additional vessels to my rig so I would not be as rushed preparing pots for each step. Instead of lifting gallons of boiling and near boiling liquid, I now use a pump to get the beer where I need it at each stage. Now I can keep the process going on my own. I can teach and share my craft if that’s what my friends wanted, or just be social. More than anything else, including friends always has been more of a social benefit for me.
Finding the motivation to podcast again was much harder. I enjoy making a podcast but I enjoy it very differently than the way I enjoy brewing and the end result of making a beer. Both require similar amounts of effort, at least mentally. The reward I get from a podcast is more abstract. Sipping on a fresh beer is both its own immediate reward and encouragement for me to start working on the next beer. A new podcast episode doesn’t provide me with the same feedback loop. Finding the motivation for the next episode isn’t any easier for having completed the last episode.
About six months back, several old friends resuscitated their podcasts. I was inspired by hearing their voices again, especially their stories about why they returned. I had already freed myself of the obligation of a regular schedule. I recorded spontaneous episodes for this podcast when I had a topic in mind, either as a fully written out essay or just an idea I wanted to talk about off the cuff. Those decisions did not result in me producing more episodes. The longer format still felt like a burden even though I still feel it is best suited for the topics I pursue here. I didn’t want to try yet another change, a shorter format, only to have that fail. I was not, am not, done with this site or this podcast but needed a way to experiment more freely to figure out what I wanted or needed to do next.
I used to have another, more free form podcast. That ended over a year ago but I didn’t feel like I was done with the topics I had started to explore there, mostly centered around travel, food, and drink. I realized I had an opportunity to create something new. I took the things that inspired me from my friends’ shows and combined them with the things I thought I could manage in a new project. I didn’t want to saddle myself with a lot of writing and preparation. A much shorter format, five minutes, felt like a better choice for speaking about some topic on the fly. Keeping a list of topics and just working through each in turn was about all the planning I wanted to do. I used the new show to try to simplify the recording, editing and production process too so that I had less reason not to get a show out.
So far, the Audio Diary of a Peculiar Character has been an outstanding success. I have not missed a week in six months. If anything, keeping myself to only five minutes has been the only challenge. It would be very easy for me to allow the core segment to creep up by a minute, then another, until shows reached ten and twenty minutes. I have had some more involved stories to tell. To keep them to the strictly self enforced limit, I did some planning, breaking them into a series of back to back episodes. On any given weekend, I sit down to record one or two new segments. When I am ready to post an episode, everything is pretty much cut and paste. I routinely, though not always, have a queue of two or three shows ready to go. Having a safety net, more than anything, has reduced the amount of stress I feel about producing a new weekly show.
About two months ago, I finally decided to put what I had learned on the new show into practice to help bring back a more regular schedule for The Command Line. I re-recorded and edited a lot of the canned bits to make them easier to just drop in with a single, freshly recorded segment at the core of each episode. I had been meaning to do this for a long time but the practice with the new show finally removed my last excuse. The only remaining challenge was the content. I wasn’t getting any better at writing on a regular basis for the shows that featured an essay. Then it occurred to me that the way I read my tech news every day might be similar enough to the rolling list of topics in the new show that it would be worth bringing back the news shows.
The Command Line has been and continues to be about how I keep learning about the world of tech. The news shows were always a large part of that but I used to think they were too labor intensive. I used to prepare them by writing out as much if not more notes than a typical essay. In retrospect, it is no wonder they were feeling like more of a drag than they were worth. Even though I stopped writing up such detailed thoughts on what I was reading, I was still reading. I was still sharing those stories, straight out of my feed reader.
Quite some time ago I switched readers, to tiny tiny rss. Since the switch, I have continued to refine and simplify how I use this tool to keep my daily reading manageable. Instead of compiling daily and weekly link dumps on my blog like I used to do I can now just link to a feed of stories I re-publish out of my reader. Unlike Google’s now defunct Reader, tt-rss has lots of capabilities designed for sharing stories. I can annotate stories with my thoughts as part of that. I like shifting the sharing down to the individual story rather than compilations. Social sharing feels more natural at this scale. The comment I add into the feed works well as a comment when I share to Google+, Facebook or Twitter.
What my current reading habits boil down to is that I have a list of the stories I’ve read, felt were worth sharing, and a quick comment to point out what I found interesting. This list is perfect for a re-vitalized news cast. I can just talk through each story in turn until I am either done with them or hit the twenty minute mark. I don’t have to do a lot of preparation in advance, I already did as much as I need on a daily basis throughout the week. So far, I think this is working well. The feedback on this new approach has been very positive.
Even though I have brought the podcast back to life with a refresh on the news format, I am still working on my writing. I don’t have any hard won lessons to share on that, at least not yet. This essay, alone, has taken me weeks and weeks to draft. I struggle with what I think is probably the simplest, best advice I’ve heard–just write. If it were that easy in practice, everyone would be writing constantly. I am still thinking about what I can learn from the other hacks I’ve discussed here. For me, tooling and work flow matter. Having a process set up about which I get a little excited helps tip the scales towards doing rather than not doing.
Despite how long it took me to get from starting this essay to sharing it with you, I do feel like I continue to make progress. Much of how I currently go about my professional life and my passions is just the latest in an ongoing series of hacks. Not everything I come up with is so interesting or involved that I feel it is worth sharing. Some days I come up with tweaks, changes and tricks too small and numerous to relate. On a good day, I can’t help but smile about the latest way, big or small, I’ve found to keep hacking my world. Feeding that joy is the most important hack of all for me.
This time, I share an essay on how I realized I have been living up to my motto more than I thought. You can read a text version of this essay, too.
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
Not sure how I ended up at work so late, except for that old “one more compile” thing, or in this case, one more test run.
For some reason, I decided to step back from any integrated development environments at work and just use my preferred power editor of choice, vim. If you are unfamiliar, an IDE is a very powerful tool, like an assistant constantly at your elbow to remind you of how to code better, how to use libraries, and kick off any number of tasks like builds, deploys, and debugging. Early in my career, I resisted them, feeling that I should be able to be productive with a loose collection of individual tools. I finally caved when I read Martin Fowler’s “Refactoring” and realized that the one thing the IDEs at the time could do that my much beloved power editor plus command line could not was tear through a project’s code base, transforming the code smartly, based on an actual understanding of how source files fit together. The alternative was to use tools like sed, grep and awk to essentially do global search and replaces across many, many files. To do so, you had to explicitly write out what you wanted changed, character by character. In an IDE, you could select a menu option–extract method, introduce parameter, rename class, etc.–and provide very lightweight input like new names and new locations, depending on how you are re-factoring the code.
As much as I have been using IDEs for the past handful of years, part of me still felt they were a little intellectually lazy. I’ll be the first to admit that feeling is fairly irrational but that is how I have felt. I guess that a quiet part of me feels I should be skilled enough and deeply embedded in the languages, tools and projects I use to make the loose collection of tools approach work, strengthening my abilities as a coder as I work by being much more actively in the mix of those tools. Sort of how I feel about having a manual transmission on my car rather than an automatic. Except the clutch is n-th dimensional and I have to use all five fingers of my right hand, plus a few toes of the corresponding foot, to manipulate the stick through the gear changes.
I have to say, I am enjoying engaging deeply with my power editor of choice. Even though I took a break from coding professionally at my last job for about two years, I still used vim for any and all of my text writing and editing needs. Since the last time I used vim for coding on a regular basis, the biggest difference is how much more mature and robust the plugin ecosystem has become. While I still supplement vim’s incredibly powerful and efficient text manipulating capability with tools to search, check and build code, and more, a lot of very passionate folks have written some very nice glue code to allow those tools to be invoked from within vim and to interact with the way the edtior thinks about text and files.
I have been sharing some updates as I noodle around with my vim set up, focused on the editor’s main configuration file, .vimrc. In response to one of those posts, a friend, Jed, asked if I’d write a post about the plugins I use. I am more than happy to comply. If you are curious, you can read along at the github repo I created to house and share my hacking on my .vimrc. I have tried to comment the various files I use to explain my thought process and pay forward the many, many tricks I have found in recent days to make working with vim that much more pleasant than it is already.
First and foremost, there are at least a few ways now to automatically install and manage plugins, a capability that was sorely lacking even a few years back. Of those tools, I use vundle. I like it because it only requires a one time manual install then self manages updates of itself as well as plugins. It provides a really nice set of commands within vim, and in editor help explaining them, to search, install and clean up unneeded plugins. My main .vimrc simply sources a supplemental file, vundle.vim, that both interacts with vundle and itemizes my current raft of plugins.
I have a bunch of language specific plugins, I’ll forego discussing those, for now. The other, more general plugins are both more likely to be of interest to any random reader and contribute the most value, and joy, to my use of vim on a daily basis.
The first plugin I’ll recommend is airline. I have long had a custom status line in vim, one I configure to be always present. It showed a few useful things but projects like airline and powerline improve on this massively and make it possible to have a very slick looking set up. I use the patched powerline fonts, explained and linked to in the airline docs, to gild the lily that is the info rich display of this plugin. The readme at airline’s github project is its own best sales pitch, I encourage you to give it a read. I like it even more for being a vim native re-write of the original powerline plugin. It demonstrates just how incredibly powerful vim’s own scripting environment has become.
Another backbone of my toolset is exuberant ctags. This is a unix program that digests source code for any number of languages and builds a database of tags. That database allows a programmer to quickly jump around a code base, from reference to declaration. vim has long supported integration with ctags so that if you have an appropriate database built and accessible, jumping to a function declaration is only a hot key away. If my aging memory is right, this support predates most if not all of the current popular IDEs. I use the plugin easytags which allows vim to continuously refresh my ctags databases as I work. I pair that with the plugin Tagbar which allows me to open a split frame that uses ctags to present a code structure aware outline view of any source file on which I am working. Further, Tagbar integrates with airline, enriching my status line with more contextual info about where I am within any particular segment of code.
I use two plugins from github user scrooloose, NERDTree and Syntastic. The first brings in a file explorer that is way more powerful and easy to use than the already pretty nice explorer built into vim. The second integrates any number of standalone programming language syntax checkers, like jshint and Java Checkstyle. That integration allows me to jump around my sources, seeing where I have slightly junky code I might want to clean up or an actual break I definitely need to fix well before it hits a compiler or a deployed application.
I just added a tool called fugitive. Mostly I pulled it in to see my current working git branch in airline. It supports invoking git, the whole hawg of distributed version control tools, from within vim but I have barely scratched the surface of that. I am still creeping towards the deep end of git at present, at present trying to use more interactive adds to selectively commit not just whole files I’ve changed, but collections of fragments of files that are related, separating them from other changes in those same files I want to save for a subsequent commit, for a separate reason. Being able to use vim to select those chunks to build up more smartly commit sets is intensely appealing while still slightly daunting.
Up to this point, if you are a coder, you may be thinking that all these plugins do is approach but not quite compete with a modern IDE. I wouldn’t necessarily disagree, as I said, these plugins just make existing tools easier to keep at the periphery of where I exert the vast majority of my focus every day. I have such deeply ingrained muscle memory for vim that I can create and change text far more effortless with it than even the best editor offered by the best IDE. I have tried “vim” bindings in some IDEs and even an abomination that yokes vim directly to Eclipse but all they have done is remind me of what I love about vim.
There is one last plugin that I feel is the most compelling response to the refactoring support available in packages like Eclipse and IntelliJ. For geeks of a certain age, tools like grep and sed are equal parts comfortable and frustrating. They are so responsive to sifting through masses of files yet so demanding in the exactitude of their use. A few years back, a colleague introduced me to a kinder, gentler alternative specifically for coders, ack. ack combines the expression power of grep with a better understanding of the peculiarities of source code and programming language syntax.
ack.vim brings that useful and useable code searching into vim. In this case, search is only half the picture. vim supports macros, not in the sense of scripting or snippet expansion, but the ability to record and play back key strokes. Everything vim does can be invoked without taking your hands off the keyboard. I feel this is vim’s best, most under appreciated feature. Imagine searching for some repetitive fixture in your code you feel must change, something thorny enough to require ack to confidently spot all instances of it. Now, couple that, through this plugin, with the ability to repeatedly and correctly apply that transform, not just something superficial, but a complex interaction with every single occurrence you unearth. Using vim, ack and ack.vim may not be as simple as picking from a few menu options but it also isn’t anywhere near as constrained. I’ve used macros to work over related sections of text, multiple lines together, not just a line or two around a simple declaration.
I’ve only been applying this latest deliberateness to my use of vim for a few weeks. My hope and fear is that there is so much more to explore. Hope in that I already feel I have finally found a combination and integration of tools capable of giving any IDE a run for its money. Fear in that these waters run very deep indeed and my ability to plumb them is only so great.