I love tooling. #eslint has been ubiquitous for so long, the standard and the
standard. But OSS is evolve or die, and sometimes both.
The upgrade path between eslint 8 -> 9 is rocky enough that it simply doesn't
look worth the squeeze, to me. For a new project, the choice is obvious (9), but
I've had little success using the migration tools.
Given the scope of linting configuration, I'm probably better off declaring
linter bankruptcy and simply starting over. Yeah, that's it, this is make-work.
You know what you like. Grab some other chili adjacent ingredients. Probably
a white onion for dicing. Tomato paste. You have chili powder at home, yeah?
Shredded cheese. Crushed tomatoes or diced, even sauce? No sauce, but get a can
anyways. Garlic... A red pepper. So strange that they lock the laundry detergent
up now. There's not many people here, this time of night. Get followed around by
3 security guards, conspicuous in their plate carriers.
Allons-y, and mise en place. This is quick chili.
Brown the meat. Freestyle a bit. Various powders and spices.
Tomato paste, into the stew.
Etc. This isn't a soup. Use the too-expensive salt to season.
Forget to prepare the cornbread. This is less-than-quick chili now.
I've been wondering why my fly machines weren't auto-suspending after I added
#sentry to a project. From the logs, I could see / was being requested every
second... Smells like a bot.
So I added more logging to catch the user-agent from request headers, and was
surprised to see the following:
I guess #sentry has a new feature (beta) that does a healthcheck on URLs that
have thrown exceptions. I need to read the docs more closely, but a GET every
second seems a bit excessive. To disable it, I just revised my robots.txt:
I've been looking for an #elixirredux-alike (primarly the event-bus stuff),
and have found that Phoenix.PubSub paired with a GenServer and a Task
supervisor seems to get the job done.
I did chase a few different constructions, like using Task.start with
callbacks, but found that GenServer doesn't have a predicable state when
callbacks are executed.
The following is scratched out, as there's opportunity to make it a bit more
generic, like sending messages back to the original caller, etc.
objective: Schedule async work that can crash.
defmoduleMyApp.DispatcherdouseGenServer@topic"MY_TOPIC"defstart_link(_)doGenServer.start_link(__MODULE__,%{},name: __MODULE__)enddefinit(state \\%{})do# subscribe to events emitted elsewherePhoenix.PubSub.subscribe(MyApp.PubSub,@topic)# Start a Task.SupervisorTask.Supervisor.start_link(name:MyApp.Dispatcher.TaskSupervisor){:ok, state}end# handle messages sent from dispatched tasksdefhandle_info({:DOWN, _ref,:process, pid, _reason}, state)do
next =Map.delete(state, pid)# broadcast that a task is completePubSub.broadcast(MyApp.PubSub,@topic,{:tasks?, next}){:noreply, next}enddefhandle_info({_event,%{id: _id}}= msg, state)do
task =Task.Supervisor.async_nolink(MyApp.Dispatcher.TaskSupervisor,fn-># doing something async. It may or may not crash# For instance, maybe this does a database writeend){:noreply,Map.put(state, task.pid, task)}enddefhandle_info(_, state)do{:noreply, state}endend
I've been fiddling with content extraction using
@mozilla/readability. As a
data-source, what better candidate than this very-here website, so I made some
revisions.
The basic question is "what components must my webpage have in order to trigger
reader mode". Surely, this is standardized.
Well... extremely no, it seems. Having done some reading, the best I've come up
with is that adding schema attributes won't hurt anything, but the ways in
which browser reader modes parse content is highly eccentric. For instance, the
following qualifies for reader mode using Firefox, but @mozilla/readability
fails to extract a publishedTime.
<articleitemscopeitemtype="https://schema.org/Article"><h1class="post-title"itemprop="headline">Reader modes are insane</h1><timedatetime="2024-10-25"itemprop="datePublished">
2024-10-25
</time><sectionclass="post-content"itemprop="articleBody"><p>...</p></section></article>