jdickey

This has been moved to this GitHub repo.

jdickey

This document is background information for a series of projects I am currently (as of early 2020) working on. I am making it public in an attempt to solicit useful comments and advice on the ideas documented here; to the best of my knowledge and belief, it contains no information proprietary to either my present employer nor any other commercial, non-BSD-license-using organisation.

Markdown makes a far better standard document format for hand-editable content than HTML. Previous forays into HTML-to-Mark­down conversion several years ago were frustrating due to the immaturity of both the available Markdown spec(s) and of the tools then available to do the conversion (notably, now-ancient versions of Pandoc).

Converting with Pandoc

Pandoc is a highly capable document converter. It can convert from dozens of formats, to dozens of formats.

Note that there is a maintained Ruby

jdickey

Not meaning to throw shade on Wisper 2.0.0; it's a very mature, reliable, widely-used Pub/Sub system. It's not the fastest, though; benchmarking it against against RocketMan 0.1.1 and dry-events 0.2.0 gives the following results:

Results:

$ ./benchmarks.rb
Rehearsal -------------------------------------------------
RocketMan       0.150000   0.010000   0.160000 (  0.163206)
Wisper          2.330000   0.350000   2.680000 (  2.994349)
Dry::Events 1   1.490000   0.290000   1.780000 (  1.788510)

jdickey

tl;dr: Once again, being in a hurry will always slow you down. After forty years in this craft, the next counterexample I see will be the very first.

(See the bottom for an update.)

The reason that our token wasn't preserved from the ResetPassword::New action to the ResetPassword::Create action appears to be tied to the inconsistency with which that token is accessed throughout its journey.

Here's a URL fragment showing how the reset-password link might appear in an email sent to a Member:

https://conversagence.com/reset_password/new?token=YWZrbnRIbHBOeWVybU14ZVR6djBSN0F4

jdickey

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Sunday 30 December 2018 20:50 SGT (GMT+8)

This is to serve notice that my GPG (GNU Privacy Guard) key has changed with
effect from today, Sunday 30 December 2018, following my (revised) standard
protocol for key expiration. My new key will expire on 31 December 2019. 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

jdickey

# ENV['TZ'] needs to be set for Time#ctime to work properly. Adjust as needed.
ENV['TZ'] = 'Asia/Singapore'


def deps_for(name)
  version = Gem.latest_version_for(name)
  dep = Gem::Dependency.new name, version
  deps = Array(Gem.latest_spec_for(name.to_s).dependencies)
  deps = [dep] + deps.reject { |gem| gem.type == :development }
  deps.flatten.sort

jdickey

Consider the following:

module Foo
  def a
    puts "Foo#a"
  end

  def b(*args, **opts)
 puts "Foo#b, args=#{args.inspect}\topts=#{opts.inspect}"

jdickey

We fixed the problem, in a highly unexpected way. Below is the text (excluding static-analysis report boilerplate) of the commit we've just pushed to our project repo. Thanks for the helpful comments from all, particularly /u/nyekks on Reddit.

Fix the Selenium prob that wasn't a Selenium prob

It's been a long road, getting from there to here...

We'd been chasing our tail for days, never mind how many, trying to figure out why our Selenium JavaScript tests were apparently breaking Docker. Eventually, we posted pleas for help on Reddit, StackOverFlow, and Gitter; all variations of (and referencing) this Gist.

Turns out the problem wasn't (wholly) with Selenium, Capybara, Docker, and/or the interaction between the three. @mitpaladin eventually discovered a randomisation seed (15474) that, when specified via a TESTOPTS environment variable passed to Rake in `script

jdickey

After copying these from repo to repo for lo! these many projects, I decided to create a Single Source of Truth for project labels going forward.

These are an expansion of and, in a couple of cases, a slight modification of, the standard labels that GitHub creates for each new repo (and they themselves update from time to time). Particularly, I

• draw a distinction between a feature (new functionality not previously extant in a project) and an enhancement to an existing feature; and
• include a non-empty Description for each label. GitHub have recently changed their project defaults to do this, but older projects don't have that, even for "standard" labels;
• add generic tooling and vendor labels, as well as labels for docker and hanami as examples of tool-specific labels used in multiple projects. If a new project will never use Hanami or Docker, then I may not add the label to that project, and I may then add other, appropriate, tool-specific labels instead (e.g., for react in a

jdickey

Interactors, Action Classes, and Errors; Oh, My!

Contents

• Contents
• Why Are We Here?
• Hanami Controller-Action Parameter Data Validation
• New Kids on the Block: Interactors
• Error Data
• #call Me Only If You're Valid