This has been moved to this GitHub repo.
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-Markdown 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).
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
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)
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
-----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 |
# 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 |
Consider the following:
module Foo
def a
puts "Foo#a"
end
def b(*args, **opts)
puts "Foo#b, args=#{args.inspect}\topts=#{opts.inspect}"
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
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