vim-rails is enabled only if config/environment.rb is present in the Rails working directory.

At work, we have an engine based working directory that does not contain this file (as there’s an embedded application within the engine.)

To enable vim-rails, I need to do:

echo "load ::File.expand_path('../../embedded-app/config/environment.rb',__FILE__)" >> config/environment.rb
mkdir -p .git/info
echo "config/environment.rb" >> .git/info/exclude

Within the repo to enable vim-rails support.

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.

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. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don’t get fancy. (Even if n does get big, use Rule 2 first.)

Rule 4. Fancy algorithms are buggier than simple ones, and they’re much harder to implement. Use simple algorithms as well as simple data structures.

Rule 5. Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

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.)

OpenSSH Client Configuration

Below is Mozilla’s Modern SSH client configuration recommendation:

# Ensure KnownHosts are unreadable if leaked - it is otherwise easier to know which hosts your keys have access to.
HashKnownHosts yes
# Host keys the client accepts - order here is honored by OpenSSH
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

Note these are the “modern” recommendations which assumes the services you are connecting to have been updated recently. I’ve noticed I’ve had to modify these for services like Github with:

KexAlgorithms diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1

OpenSSH Key Generation

ED25519 is recommended for all new keys, but not all services support it. For those services we need to fall back to RSA. Using Mozilla’s SSH key generation guidelines, I created a keygen script that defaults to ED25519:

#! /bin/bash
#
# Generate a new ED25519 or RSA SSH key using Mozilla's
# (https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Key_generation)
# recommendations.
#
# Usage: keygen {service_name} [ed25519|rsa]
#
# Defaults to the more secure ED25519.
#

set -e
set -u

service=$1
type=${2:-ed}

case $type in
    ed*)
        ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_${service}_$(date +%Y-%m-%d) -C "Key for ${service}"
        ;;

    rsa)
        ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_${service}_$(date +%Y-%m-%d) -C "Key for ${service}"
        ;;

    *)
        echo "Usage: keygen {service_name} [ed25519|rsa]"
        exit 1
        ;;
esac

Now you’ll need to send your new key to the remote server. For example:

ssh-copy-id -i ~/.ssh/id_ed25519_wormbytes_2017-12-08 robert@server.wormbytes.ca

Finally update your ~/.ssh/config and modify your IdentityFile to reference the key that was generated. Something like:

IdentityFile ~/.ssh/id_ed25519_wormbytes_2017-12-08

Conclusion

My recommendation is to review your SSH keys and configuration once a year. While the above configuration is the recommendation today (December 2017) it might not be the recommendation next year. Be sure to check back with Mozilla to see if anything needs to be updated.

Back in August I rebuilt the site using Jekyll and Minimal Mistakes for the theme. This worked great for a few months, but even a small site was taking too long to generate (10-15 seconds!)

While 15 seconds per build isn’t much, it was just enough friction to make updating not fun. That’s when I remembered that Julia Evan’s had posted her experience switching to Hugo. A zero second build time was very attractive!

Unlike her, it took me longer than four hours to migrate my site to Hugo! I had used a bunch of helpers provided by Minimal Mistakes that I had to either replace or rebuild. Plus, I had also written a couple of my own custom Jekyll plugins which were converted to Hugo shortcodes.

Migrating to Hugo

Like Julia I started with:

1. run hugo import jekyll
2. import a random theme

Getting to this point took no time and a hugo run to build the entire site took 150ms! Milliseconds! Awesome!

Then I hit the hard part. :(

Rebuilding the Existing Theme

I had spent a lot of time before settling on Minimal Mistakes as my Jekyll theme. It’s a great design with lots of functionality (some of which I even used.)

Rather than trying to port the underlying Jekyll templates, layouts, etc. I did what Julia did and copied the generated HTML and assets into the layouts directory of the new site and started digging into the Hugo documentation: while extensive, it’s not exactly user-friendly.

It took me three days of intermittent hacking to ensure all the content was present, with the right URLs, and with all the old Minimal Mistakes helpers removed and my custom plugins written as Hugo shortcodes. (Lots of NeoVim editing to replace the old markup.)

Once the HTML looked right, the last step was to update my workflow scripts.

Gotchas

Parsing dates.

Hugo has the .Format function to parse dates into human readable strings. What I didn’t grasp is that the reference format is very specific. If you don’t format the string using the exact times mentioned in the documentation your rendered dates are all messed up!

Success!

With everything in place I can now publish to the site with way less overhead and friction. Effectively, I go from saving the post to publishing to the Internet in under a second!

The only way it could be better is if I didn’t have to do the pesky writing as well!

Update

Still using Hugo, but switched out Minimal Mistakes for a theme I found online and then customized to suit my preferences!

As a remote worker in a rural community, I’ve found it difficult to find other technology workers in the area. After speaking with Brett, we decided to start the Norfolk Techies Slack group.

If you’re a technology worker in the Norfolk County area please contact Brett or myself for an invitation link.

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.
• Question assumptions constantly.
• Think long term. Slow down, it goes faster.
• Care about your code.
• Cheap, fast, right — pick two.
• Conclusion: Be curious. Learn as much as you can, all the time.

Jim Bird writes:

Using run-time flags like this isn’t a new idea, certainly not invented at Flickr or Facebook. Using flags and conditional statements to offer different experiences to different users or to turn on code incrementally is something that many people have been practicing for a long time. And doing this in mainline code to avoid branching is in many ways a step back to the way that people built software 20+ years ago when we didn’t have reliable and easy to use code management systems.

1. Never say: “Do as I say, don’t do as I do”
2. Create An Environment Of Play
3. Manage What They Consume
4. Interrupt Negative Self-Talk
5. Actively Remind them to be Grateful
6. Make Rigid Routine Days Mandatory
7. Encouraging Curiosity and Asking Questions
8. Encourage Independence From Diaper Years
9. Never Teach Them Ugly Ideas About Money
10. Let Them Have A J.O.B.
11. Answer Their Questions With A Question
12. Pour On The Hugs and Kisses

Bruno Filippone writes:

One of the easiest tricks to ensure your software will live longer is avoiding to write code tightly coupled to libraries and frameworks. Reducing the number of dependencies of your codebase is always a no-brainer. Making sure the majority of the code you write does not rely on a gazillion third-party libraries should be a priority.