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

So I built a dummy Rails-plugin gem...

rails plugin new foo --skip-bundle -O --full

and filled in my .gemspec as below, including the line

s.add_dependency "rails-assets-sugar"

and added

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