Articles tagged “development”
Sunday, 11 May, 2014 —
development
improvement
For some background on what’s going on here, see the first tool sharpening post
In the last couple of weeks, I’ve made the following adjustments to my developer environment + closely related computing set-up:
- Created an initial MiddleMan template to make aggregating my tool sharpening changes easier. I expect this will make it easier to prep tool sharpening blog posts on a regular basis I can go back and review.
- Tuned my work email rule filtering so most automated/generated messages bypass my in box to their final destination
- I then use two Smart Folders, one called “New” and the other “Recent” to see unread messages and recent messages regardless of read status
- Added an OmniFocus perspective called “Recent Additions” based on a Merlin Mann suggestion on a past Back to Work episode. I keep my iPad with me and update OmniFocus during my team’s daily standup and this perspective is a good help to find and further process entries I make when I get back to my desk
- Added Solarized theme for BBEdit
- Built a BBEdit text filter in Ruby that takes a column of numbers and adds them
- Created an initial BBEdit Package for the text filter and posted it to GitHub.
- Installed Editor Actions for BBEdit
- Created an “Exploration” BBEdit project so I have a workspace for one-off investigations
- Created an “Exploration” Tmuxinator profile so I have a workspace for one-off investigations
- I also made a lot of OmniFocus entries regarding additional BBEdit text filters, shell environment improvements and Text Expander shortcuts to add
Looking over the list, I’m pretty happy. I’m still integrating a few of these changes as habit. A few of these items may not end-up sticking. The key improvement I’d like from here is improving my consistency. The schedule of my work day has shifted around some, so it’s not quite as feasible to pull an desired improvement off the stack for implementation. To that end, I am going to attempt to pull an improvement to implement at the end of the day when everything is winding down. That way, I’m quite likely to have a small accomplishment to bridge into the next work day with.
Saturday, 3 May, 2014 —
practice
development
podcasts
I have a roughly 20 to 25 minute commute five days a week from our house in North Raleigh to NC State’s Centennial Campus. Most days, I use the drive time to listen to a podcast.
I have two must listen podcasts every week:
There are two other, more technical, podcasts that I also listen to and cycle in every couple of weeks:
I have about 3 1/3 to 4 hours of otherwise lost time each week driving. I use that time to listen to these podcasts for two related reasons.
First, I do not have a better time to listen to these podcasts, largely because of how my sense of time and focus work. All four of these podcasts demand my full attention. I could not be successful in listening to these podcasts and trying to program or read attentively. I use music in those instances. I can, however, focus well on the task of driving, and pay attention to the podcast fairly well.
Second, all four of these podcasts feature smart people in their respective crafts thinking out loud. I, in turn, find myself thinking as a result and drive time is time I am not otherwise trying to focus creative attention elsewhere.
Each of these four podcasts is worth a post of it’s own, which will come in due time. I am, however, capped at these four. There are weeks that I can listen to only one full and part of another episode, depending on episode length. There are weeks where I really need to listen to music for a day or two. While there are many other great podcasts around that I would love to also listen to, I listen to these four at most because that’s as much as I can stay reasonably close to caught up with given how much time I’m willing to spend on it.
This is one of my established daily practices.
Tuesday, 29 April, 2014 —
development
improvement
Back in the fall, Ben Orenstein of thoughtbot was on the Ruby Rogues podcast and talked about sharpening tools. Making his vim profile better, interacting with his desktop better. In some way, he’s making his life as a developer better, every day.
He said:
I’m a huge believer in the power of habits. I think the things you can manage to make yourself do regularly can have incredible results. And so, a few years ago, I’d say five years ago, I decided to get kind of serious about making my environment really excellent and improving my efficiency that way. And so, I got in this habit of spending the first ten or 15 minutes of my day on tool sharpening. And so, what I started was I started a little text file that I would add to during the day. So, when I was doing something that felt inefficient or felt like whenever I had that inkling, “There must be a better way of doing this,” I’d add it to the list. And then I’d pull one of them off in the morning.
And so, I started most mornings by just doing something simple like making an alias for a command I use in the shell a lot. Or something like, I finally need to research how the Vim expression register works and go do some diving on a readme or something like that. And I thought of it as sort of slowly sanding down the rough edges of my environment. So, anything that kind of like irked me, I would try to spend a little time on every morning. And what I found was not very long of this, I was noticeably faster at the things I needed to do every day. And it was starting to have a huge impact on my productivity. And so, I started talking about that.
Five years of daily tool sharpening or tool making seems like it would lead to some transformative changes in work habits and flow. To that end, I’ve spent some time recently attempting to make some adjustments to my own environments. I’ll enumerate some of them:
- Read up on homebrew services
- Adjusted my tmuxinator set-up
- Added a profile for a Tech Week project
- Added tmuxinator invocation shortcut
- Installed the Silver Searcher
- Set-up ctags in a project as an experiment
- Installed + purchased Dash
- Repaired tools + resources links on my tools page
- Installed MsgFiler
- Created a clipping to insert an Emacs-style counterpart comment in BBEdit source files
- Found a Safari extension that can normalize the size of Safari windows
- Installed Total Terminal for a keyboard shortcut available terminal window I can use for one-off commands.
- Updated BBEdit prefs to use Dash for “Find in Reference”
This isn’t an exhaustive list of what I’ve done since my curiosity was piqued by what Orenstein was describing. I wanted to share the list to inspire someone else to try out the practice and prompt myself to reestablish the habit.
I plan to revisit this with new entries occasionally.
Saturday, 8 September, 2012 —
git
development
Last week at work, I was trying to diagnose apparent trouble with a Git repository. Whenever the infrequently updated repository was cloned, we would end up in a different branch than our devel branch. Not knowing if there was a problem in the remote bare repository, I dug around refs/heads and HEAD on both the remote repository and in a fresh local clone. Not seeing any apparent trouble, I Googled.
I came across the following mailing list post that explained my trouble:
… the git protocol does not expose which branch HEAD points to, only
which commit. So if two branches point to the same commit, git just takes
the first branch and points the local HEAD to that.
How we ended up in that situation is like this:
- Starting with an existing repository, create a branch off of master or whatever other branch you treat as your default HEAD
- NB: We use devel as a historical artifact
- Publish the new branch to the remote origin
- Clone the repository somewhere else and examine the new clone. There’s a good chance the new repo will be using the new branch instead of master
I created a GitHub repository to demonstrate (although there’s no guarantee you’ll get the new branch on clone).
1
2
3
4
5
6
7
| $ git clone https://github.com/base10/branch-head-examples
(add files)
$ git push
$ git branch feature
$ git push -u origin feature
|
Now, I’m going to look at a fresh clone:
1
2
3
| $ git clone git://github.com/base10/branch-head-examples.git clone-example
$ ls clone-example/.git/refs/heads
master
|
So, I didn’t get feature. If however, in your clone, you saw this …
1
2
| $ ls clone-example/.git/refs/heads
feature
|
… you would just need to do this:
1
2
3
4
| $ cd clone-example
$ git checkout master
Branch feature set up to track remote branch master from origin.
Switched to a new branch 'master'
|
Now, diff the refs/heads files:
1
2
| $ diff .git/refs/heads/master .git/refs/heads/feature
$
|
Getting an unexpected branch from a repository in this state isn’t harmful. It is a little disconcerting if you’re looking at a repository you established, but don’t work with frequently. I suspect this case is more likely to come up under the following circumstances:
- You don’t have a master branch at all (which might be true if you’ve converted a Subversion repository) or master is a dead branch
- You have a mainline of development and create a release branch from the mainline of development
- The repository, with all branches, is pushed
- The repository is later cloned, with no further changes.
Saturday, 8 September, 2012 —
development
utilities
I occasionally have a metric mumbleton of browser windows and tabs open, particularly if I’m digging into a research topic. In the past, if I’ve needed to close out windows or tabs, but have wanted to keep the context, I’ve gone to each tab individually and saved the URL to a file.
In the last week, I found myself with about five windows and 45 tabs, so my typical approach strikes me as insufficiently lazy. So, I was going to find or write something to handle the task for me. My initial Google research didn’t turn up the sort of AppleScripts I fully expected to exist. So, it looked like I was going to be writing AppleScript myself.
I found some code in a similar area and I reached my typical wall with AppleScript. At some point, I should actually solve a problem with AppleScript, but instead, I used the rb-appscript gem and wrote a Ruby script that interacted with the Safari AppleScript dictionary, based on a concept I saw in a StackOverflow post.
Here it is:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| #!/usr/bin/env ruby
require 'appscript'
require 'yaml'
include Appscript
safari = app 'Safari'
url_list = safari.windows.tabs.URL.get
url_list.flatten!
dt = DateTime.now
date_format = dt.strftime("%F_%H%M")
list_path = "#{ENV['HOME']}/saved_urls_#{date_format}.yml"
File.open(list_path, "w") do |f|
f.puts(url_list.to_yaml)
end
|
This is also available as a syntax-highlighted GitHub Gist.
It’s nothing magic, but just the sort of simple utility that solves a small problem for me.