Sunday, April 14, 2019

App::WRT v5.0.0

It’s been almost a year, so I’m putting together a release of wrt, the site generator I use for p1k3:

v5.0.0 abandons the idea of running persistently under FastCGI, handles character encoding more gracefully for Atom feeds, adds wrt ls and wrt config commands for listing entries and dumping configuration values, refactors a bunch of the logic for finding and displaying entries, and fixes a slew of minor bugs. It should be substantially more performant, though as a tradeoff it uses more memory.

Here’s (I think) the full changelog since the last time I pushed this thing to CPAN:

v5.0.0 2019-04-14

  - Add bin/wrt-ls for listing entries in current archive
  - Add bin/wrt-config for displaying configuration info
  - Allow header tags with attributes
  - Minor documentation cleanup
  - Bump XML::Atom::SimpleFeed to 0.900; remove wrt-fcgi
  - Concatenation instead of variable interpolation in HTML::tag()
  - Remove hardcoded "public" from renderer directory path copying
  - Remove unused feed_url param from wrt-init and example dir
  - Remove an extraneous JSON->convert_blessed(1) call
  - WRT::entry(): fix glitch with contents list for binfile_expr matches
  - Correctly encode feed output - see https://p1k3.com/2018/5/28/
  - Add App::WRT::Util::file_get_contents();
  - Optionally cache included files in-memory
  - Add EntryStore, a class for wrapping various methods for finding entry lists
  - Refactor display()
  - Use Carp for errors
  - Remove old LaTeX markup stuff
  - Add this Changes file

v5.0.0-alpha 2018-04-19

  - Use 5 most recent entries for home page instead of latest month
  - Remove accessor methods for instance variables / configuration
  - Give absolute paths to imgsize() so it chills out on Cwd::getcwd() calls
  - Remove local_path(), recent_month(), month_before, and feed_print_latest()
  - Stop using a() in entry_markup()
  - Cache get_date_entries_by_depth() results
  - Swap out state vars for stashing things on $self in get_all_source_files()
  - Add get_date_entries_by_depth()
  - Tweak link_bar() behavior to retain link for current page

Actually, looking at some of this, I think my history of version numbers vs. Git tags vs. releases is… Less than accurate. In future I’m going to just increment the semver patch version for every commit and release to CPAN routinely.

cpan, perl, semver, technical, wrt :: p1k3 / 2019 / 4 / 14

Saturday, March 30, 2019

skipping over already-visible workspaces in xmonad

I recently went back to a two-monitor setup on my work system (an Intel NUC I bought back in November). For the most part this has been a big improvement, and xmonad handles multi-screen layouts just as well as I remembered. Each screen displays a workspace, and they can be switched independently.

I have had one nagging complaint: I have a bunch of pre-configured workspaces and tend to cycle through with them with the arrow keys. When I switched to a workspace that was already displayed on the other screen, it’d swap onto the current screen. This seems like a pretty minor thing, but in practice it tends to add confusion - I might, for example, have a page of notes up on one display and be trying to quickly navigate on the other display for items from mail, code, IRC, etc., to summarize in the notes. If that workspace jumps around, it’s easier to lose track of what I’m doing.

I wondered if it was possible to “lock” a workspace to a specific display. I still don’t know the answer to that question, but skimming the docs for XMonad.Actions.CycleWS I found an alternative that mostly solves my problem.

Originally I had the following keybindings in my xmonad.hs:

  ("M-<Right>", nextWS)
, ("M-<Left>", prevWS)

These have been replaced with:

  ("M-<Left>", moveTo Prev HiddenWS)
, ("M-<Right>", moveTo Next HiddenWS)

In practice this means that the workspace cycling for mod-Left and mod-Right will skip over any already-visible workspaces, leaving them in place on the other display. There are other possibilities, including the next/previous empty workspace, but this is pretty close to what I was looking for.

notes, technical, xmonad :: p1k3 / 2019 / 3 / 30

Thursday, March 14, 2019

Every time I declare tab bankruptcy and close the 15 to 25 things I have open in a web browser, I suspect I’m losing state I will later regret being unable to retrieve.

That generalizes, I suppose. I have this sense that a lot of what we do in software is something like writing code before the use of version control systems became a norm.

All kinds of relationships and structures remain implicit, undescribed, and impossible to model because they live purely in ephemeral application state. The best we have in a lot of cases is fragile browser history, notification backlogs in e-mail, or logs accumulated on other people’s computers for purposes directly hostile to our interests.

technical, version-control :: p1k3 / 2019 / 3 / 14

Sunday, March 3, 2019

notes on notes

First of all, I wrote up some notes on my current note-taking process.

❂

I started to do this the other day as a regular, dated p1k3 entry, but it got sort of long and I found myself wanting to do it as a standalone document that I could update over time. It seemed like a table of contents would be nice, but that’s not something that wrt supports, so I decided to see how hard it would be to add based on the hacky rendering script I wrote for userland.

That turned out to be a hassle to do well for various reasons, so I turned to Pandoc, which supports generating a table of contents out of the box.

There’s a Perl wrapper for the pandoc binary, so I first tried using that to add a simple <pandoc>…</pandoc> pseudo-tag to wrt’s markup processing the way I’ve done for Textile, Markdown, and other things in the past. It turns out that in order to get a table of contents out of Pandoc while still generating an HTML fragment (rather than a complete document), you have to write a custom template file. It also turns out that if you want to automatically put self-links next to headers, you need to write a custom filter to transform Pandoc’s abstract syntax tree.

I gave up on modifying wrt to handle this and switched to writing a small Makefile, a filter.py, and a template to generate HTML for inclusion by wrt. You can see the results here or on my gitea instance. I kind of hate the outcome and I’m not sure I’ll do anything this way again, but I definitely learned some stuff about Pandoc. I suppose this might be a useful example for someone.

notes, pandoc, technical, wrt :: p1k3 / 2019 / 3 / 3

Saturday, February 16, 2019

NOAA weather data

Resources discussed in this post:

This post is just about using public weather data to display a temperature in my windowing environment, but at some point I’d like to use it as a jumping off point for more deeply exploring the available data. It’s really cool how much of this stuff is available as simple text files and the like. Your tax dollars at work, but in a good way.

✪

I use xmonad for window management, and along with it a simple status bar called xmobar.

xmobar offers some monitoring plugins that display various bits of system status and other things. One of them is a weather plugin that can grab temperature and other values from NOAA-supplied weather data. I’ve been using the temperature from a METAR site at Denver International Airport, code KDEN, but I wondered if there was something closer to home available.

I always have the vague sense that there’s a ton of public weather data like this out there, but I don’t have a very good mental map of where it lives and I usually wind up fumbling around until I hit a directory full of text files on some FTP site. The docs for xmobar also aren’t very clear on what the station codes actually reference.

Some notes follow for the next time I’m thinking about this.

✴

xmobar’s weather plugin (source on GitHub) uses decoded METAR station data, available in text files from tgftp.nws.noaa.gov. The path to the site is, at this writing, hardcoded in the plugin.

METAR itself (“Meteorological Aerodrome Reports”) is evidently a standard that’s been around since 1968 in some form. The data looks something like this:

$ curl --silent https://tgftp.nws.noaa.gov/data/observations/metar/stations/KDEN.TXT
2019/02/16 21:48
KDEN 162148Z 36016G27KT 1 1/2SM -SN BKN022 OVC026 M02/M05 A2952 RMK AO2 PK WND 36027/2142 WSHFT 2118 SNB2057 P0000

And NOAA also offers decoded versions, which is what xmobar is parsing:

$ curl --silent https://tgftp.nws.noaa.gov/data/observations/metar/decoded/KDEN.TXT
DENVER INTERNATIONAL AIRPORT, CO, United States (KDEN) 39-52N 104-40W 1640M
Feb 16, 2019 - 04:48 PM EST / 2019.02.16 2148 UTC
Wind: from the N (360 degrees) at 18 MPH (16 KT) gusting to 31 MPH (27 KT):0
Visibility: 1 1/2 mile(s):0
Sky conditions: overcast
Weather: light snow
Precipitation last hour: A trace
Temperature: 28 F (-2 C)
Windchill: 15 F (-9 C):1
Dew Point: 23 F (-5 C)
Relative Humidity: 79%
Pressure (altimeter): 29.52 in. Hg (999 hPa)
ob: KDEN 162148Z 36016G27KT 1 1/2SM -SN BKN022 OVC026 M02/M05 A2952 RMK AO2 PK WND 36027/2142 WSHFT 2118 SNB2057 P0000
cycle: 22

In Debian, you can install a package called weather-util which makes for easy searching of the data. Here’s a station at the airport in Longmont:

$ weather KLMO
Searching via station...
[caching result Vance Brand Airport, US]
Current conditions at <UNKNOWN>
Last updated Feb 16, 2019 - 04:35 PM EST / 2019.02.16 2135 UTC
   Temperature: 36.0 F (2.2 C)
   Relative Humidity: 70%
   Wind: from the E (100 degrees) at 3 MPH (3 KT)
   Sky conditions: partly cloudy

Finally, I couldn’t figure out why I was just getting the string “Updating…” instead of a temperature after swapping in KLMO for KDEN, then I realized that you also need to change the station name in the template. Here are the changes I made to my .xmobarrc while writing this post. They also include a tweak to display sky conditions and a slightly different date format.

bpb-kit, data, noaa, technical, warelogging, weather, xmobar, xmonad :: p1k3 / 2019 / 2 / 16