jdickey

I have been carrying this Rakefile around between projects, that uses another file which reopens the FlogTask class and adds an attr_accessor to it, which the task definition in the Rakefile then uses.

This works but, as you can readily tell, it's less than ideal. In particular, the Rakefile defines multiple tasks which are the same for each project; the only change is usually the Flog threshold value.

What I want to be able to do is:

1. Subclass a tool's standard Rake task (e.g., FlogTask). The subclass' #initialize method would then set up our standard settings as is presently done in the Rakefile;
2. Define namespaced Rake tasks (in, e.g., lib/tasks/custom_flog.rake) that use those subclasses rather than the tool's standard Rake task; reducing boilerplate and possibility of copy/paste errors;
3. Have those tasks be available in

jdickey

Keybase proof

I hereby claim:

• I am jdickey on github.
• I am jdickey (https://keybase.io/jdickey) on keybase.
• I have a public key ASBzQWcz4Bj0gWNuazgGZ98ft-_q9QcHUlWtbv0oThnDjwo

To claim this, I am signing this object:

jdickey

# Run this inside Pry or irb and let it find a randomisation seed that will
# cause your tests to fail. This assumes that you're running tests for a single
# test file, which you pass in as the argument to `run_tests`.
#
# Why don't we collect a whole bunch of failing seeds? You'll need to run this
# each time you make a material change to the code being run by the tests, or to
# the tests themselves; with that in mind, take one step at a time.
#
# A quick hack, but feedback appreciated.

jdickey

#!/bin/bash
alias rerake='bin/rake clean test rubocop reek && bin/rake flay && bin/rake flog | head -5 && say "All "; say "Done."'

jdickey

#!/bin/bash

# This is a fork of https://gist.github.com/mcemce/a6ee9b4ab07df9972883 with
# additional variable-based configuration and status hand-holding added by
# myself (@jdickey). Thanks to @mcemce for helping me out of a jam.

# Docker VM name. 'dev' is a recommended name for a development VM; you'll want
# to name a production VM something else.
OUR_DOCKER_VM=dev
echo "Docker will install a machine named $OUR_DOCKER_VM within VMware."

jdickey

This is simple Markdown, but it has a GFM code block immediately below, and was coded by @jdickey:

class Foo < Bar
  attr_reader :foo
  
  def initialize(foo:)
    @foo = foo
 self

jdickey

Test content

A test of various parsers' ability to deal with Markdown content

This is a sample paragraph with both italic and bold styling. It should be pretty easy. Is this still the first paragraph?

Here comes a list:

1. First item
2. Second item.

jdickey

Style/ClassAndModuleChildren:
  Enabled: false

Style/TrailingBlankLines:
  Enabled: false

jdickey

Tim and team,

This should be pretty straightforward, but here goes. We use module namespaces and nested classes (too?) extensively in our project, but very rarely make direct use of inheritance. One place we do is illustrated by the following two files.

Prolog::Core::User::Validators::Name::Whitespace is a class that, obviously, defines a protocol to check for impermissible whitespace in a string. It has two methods, #invalid_spacing? and #reason, that must be overridden by subclasses that implement the protocol. Such a class is Prolog::Core::User::Validators::Name::TrailingWs; it implements only those two methods, which are declared private as documentation that they'll never be called ordinarily by outside code.

jdickey

Wednesday 30 December 2015 14:37 SGT (GMT+8)

This is to serve notice that my GPG (GNU Privacy Guard) key has changed with effect from today, Wednesday 30 December 2015, following my (revised) standard protocol for key expiration. My new key will remain valid until 30 June 2016. I recommend that other users of GNU Privacy Guard enact such policies and keep revocation certificates for their current keys in offline storage, such as on a thumb drive that is labelled and physically secured separately from your system.

My old key will continue to work for use in sending me secured messages until it expires tomorrow, Thursday 31 December 2015 (and for verifying previously-signed messages thereafter); however, you should be using the new key. To anyone who has signed my old key, I’d greatly appreciate your signing the new one (after satisfying yourself of its provenance and legitimacy, of course).

This message is signed by

1. my expiring key, with fingerprint 43B1 A1CF 6F33 D9D5 FAF8 37A4 4667 D23E 9A81 3C42,