I was looking at my old development projects recently when I noticed that all of them predate 2005. In 2005, I started work at ePublishing as a Perl developer. In the past 17 years I’ve been:
a Ruby and Rails developer VP of Software Engineering Chief Software Architect In all that time, I’ve written hundreds of thousands of lines of code (maybe more than a million), but it’s locked away.
Blog Posts
In a recent twitch stream, Gary Bernhardt showed a bit of behind-the-scenes in how he prepares his development environment for recording a screencast.
One of the tools he showed in passing was gem_home by Hal Brodigan.
gem_home is a simple script that manipulates Ruby’s GEM_HOME and GEM_PATH environmental variables in order to keep separate ruby gem locations.
By using gem_home, there is no longer a requirement to prefix all ruby commands with bundle exec.
SSH is the backbone to how I’m able to work remotely.
Periodically, it’s important to review both my SSH config settings and
regenerate my SSH keys.
From my perspective, Mozilla has put together the best recommendations for
both server and client configurations. For now, I’m concentrating on the
client configuration (within ~/.ssh/config and my SSH keys.)
Spiro Sideris writes:
To write understandable code, always ask the question of who your audience is. What level of experience do they have? What are the prerequisites they should know before reading this function? There are even differences in the semantics between programming languages, so knowing the best practices, and the language coding style, will ensure you are writing readable code for developers in that language.
Writing Code Like a Mathematical Proof
Rule 1. You can’t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you’ve proven that’s where the bottleneck is.
Rule 2. Measure. Don’t tune for speed until you’ve measured, and even then don’t unless one part of the code overwhelms the rest.
Rule 3. Fancy algorithms are slow when n is small, and n is usually small.
Sam Schillace writes:
I was talking with the engineering team at Box about what I’ve learned along this journey, and what came out of that conversation were my personal engineering principals. These aren’t rules or engineering guidelines. They’re simply the principles that I pay attention to when I write and operate code.
These include:
Be paranoid. Don’t lie to the computer. Keep it simple. First rule of optimizing: don’t. Don’t just fix the bug; fix all possibility of it ever happening again.