Browse Source

#circuitpython2019

Brennen Bearnes 3 months ago
parent
commit
70b3edd10a

+ 6
- 1
README.md View File

@@ -31,7 +31,12 @@ be available unless they've been copied to the current clone of the
31 31
 repository.)
32 32
 
33 33
 `includes/` is for things that are reused in entries or templates with the
34
-`<include>` tag.
34
+`<include>` tag.  At this writing, it contains `shortlinks.md`, which is a set
35
+of links for use in Markdown.  The idea is that if a link changes or
36
+disappears, it can easily be edited or replaced with a local page.  All of the
37
+enclosed links begin with `sl-` for easy grepping in future.  (I have not made
38
+much use of this idea, and may not, but I have not yet ruled it out
39
+completely.)
35 40
 
36 41
 `topics/` contains vimwiki pages which are used to describe various topics
37 42
 covered in the entries; these are combined with an automatically rendered

+ 3
- 1
archives/2007/10/9/index View File

@@ -2,7 +2,7 @@
2 2
 
3 3
 <markdown>
4 4
 I just started working part-time at
5
-[Sparkfun Electronics](https://www.sparkfun.com/).  It is by far the most SFnal
5
+[Sparkfun Electronics][sl-sfe].  It is by far the most SFnal
6 6
 work environment I have had (in the Robert Heinlein Engineering Story sense),
7 7
 although my responsibilities are in the relatively mundane fields of web
8 8
 applications and busted-ass workstations.
@@ -13,4 +13,6 @@ bucks burning a hole in your pocket and feel deeply averse to profit, perhaps
13 13
 you should contact me about a unique opportunity to underwrite the physical
14 14
 plant of a moderately anarchic educational facility, practically guaranteed in
15 15
 future years to become a Boulder County institution.
16
+
17
+<include>includes/shortlinks.md</include>
16 18
 </markdown>

+ 2
- 2
archives/2015/2/1/index View File

@@ -8,7 +8,7 @@ Background reading for this post:
8 8
 * [Why filesystems have loose coupling and your protocol doesn't][tef]
9 9
 * [The Evolution of the Unix Time-sharing System][dmr]
10 10
 
11
-A couple of months ago, I went from working on [one big software project][sfe]
11
+A couple of months ago, I went from working on [one big software project][sl-sfe]
12 12
 to working on a series of smaller, limited-scope projects.  Of course a lot
13 13
 changes when you do that.  One of the things I've really been noticing is that
14 14
 I'm not using relational databases for much right now, and probably haven't
@@ -111,10 +111,10 @@ transparent to the network and to the broader ecosystem of tools.  What would
111 111
 it actually take?
112 112
 
113 113
 [tef]: http://programmingisterrible.com/post/67568917018/why-filesystems-have-loose-coupling-and-your
114
-[sfe]: https://www.sparkfun.com/
115 114
 [dmr]: http://cm.bell-labs.com/cm/cs/who/dmr/hist.html
116 115
 [fucked]: http://howfuckedismydatabase.com/mysql/
117 116
 [alsofucked]: http://howfuckedismydatabase.com/nosql/
118 117
 [pipe]: /userland-book/index.html#standard-IO
118
+<include>includes/shortlinks.md</include>
119 119
 </markdown>
120 120
 

+ 1
- 1
archives/2018/10/7/index View File

@@ -19,7 +19,7 @@ pass the contents of a buffer through an external program like so:
19 19
 
20 20
 I wrote `filter-exec`, the first of these, as a quick and dirty way to include
21 21
 shell commands and their output when writing documentation (like
22
-[userland][userland] or DigitalOcean tutorials) in Markdown.  Markdown parsers
22
+[userland][sl-userland] or DigitalOcean tutorials) in Markdown.  Markdown parsers
23 23
 tend to ignore HTML comments, so I used comments to mark the start and end of a
24 24
 block, and `$` to mimic a command prompt, followed by the command string:
25 25
 

+ 1
- 1
archives/2018/2/10/index View File

@@ -15,7 +15,7 @@ render-all` and `wrt display`.  It should now work to specify a separate
15 15
 configuration file.
16 16
 
17 17
 (I worked on this today because I wanted to be able to generate a preview
18
-version of the site that I could navigate in [Lynx][lynx], and in order to do
18
+version of the site that I could navigate in [Lynx][sl-lynx], and in order to do
19 19
 that it was easiest to write a separate configuration file.)
20 20
 
21 21
 [nov]: /2017/11/18/

+ 3
- 3
archives/2018/4/9/index View File

@@ -4,7 +4,7 @@
4 4
 
5 5
 <markdown>
6 6
 I should have been doing other things, but I spent a couple of hours over the
7
-weekend making [wrt][wrt-gh], the static site generator I use for p1k3.com, a
7
+weekend making [wrt][sl-wrt-gh], the static site generator I use for p1k3.com, a
8 8
 bit more capable.
9 9
 
10 10
 I decided I wanted to make the feed wrt generates ([like this one](/feed))
@@ -128,8 +128,8 @@ experience, such as it is, at whatever age I've reached.
128 128
 
129 129
 Everyone should have a few long-term projects, however small and unremarkable.
130 130
 
131
-- [App::WRT on CPAN][wrt-cpan]
132
-- [wrt on GitHub][wrt-gh]
131
+- [App::WRT on CPAN][sl-wrt-cpan]
132
+- [wrt on code.p1k3.com][sl-wrt-p1k3]
133 133
 
134 134
 [schwartz]: https://en.wikipedia.org/wiki/Schwartzian_transform
135 135
 <include>includes/shortlinks.md</include>

+ 251
- 0
archives/2019/1/20/index View File

@@ -0,0 +1,251 @@
1
+<h1>Sunday, January 20</h1>
2
+
3
+<h2>#CircuitPython2019</h2>
4
+
5
+<markdown>
6
+I've been spending a decent chunk of my paid time in recent months on the
7
+[CircuitPython][sl-circuitpython] ecosystem, doing things like testing libraries
8
+against [Adafruit-Blinka][blinka], a shim that mimics CircuitPython's core modules on
9
+Linux systems.
10
+
11
+(For background:  CircuitPython is a fork of [MicroPython][micropython] aimed
12
+at educational users, beginner hobbyists, etc., with full-time development
13
+staff sponsored by Adafruit.)
14
+
15
+The community's been [asked to write some stuff about hopes for the language in
16
+2019][cpy2019]:
17
+
18
+> As 2018 comes to a close we like to reflect on how the year went and set goals
19
+> for 2019. In the last two years (2017, 2018) this has been a blog post by me
20
+> (Scott aka tannewt). For 2019, we’d like to do it a bit differently. This time
21
+> we’d like everyone in the CircuitPython community to contribute by posting
22
+> their thoughts to some public place on the Internet.
23
+
24
+I guess I'll start with some reflections on my experience in 2018 and then list
25
+some thoughts about where things are headed.  None of this should be taken too
26
+seriously --- my role on this one is that of a low-level software bureaucrat,
27
+and it's an extremely safe bet I don't know what I'm talking about.
28
+
29
+## reflection 0: python could be worse
30
+
31
+Python and I have always been sort of an uncomfortable fit.  I've used it here
32
+and there --- Ansible stuff for configuring web servers, one-offs like a
33
+[static HTML image gallery generator][galleryhtml-p1k3] --- but I've never
34
+warmed up to it much.  I never got over the whitespace thing, and the claims of
35
+"executable pseudocode" that hover around the language strike me as more than a
36
+little exaggerated.  Anyhow, I have shell and Perl for small-time utility
37
+scripting, and the large projects I've worked on have mostly been PHP.  So for
38
+one reason and another, until recently I'd probably written more lines of, say,
39
+QBasic or vimscript than I had Python.
40
+
41
+Still and all, I'm well past the point in my working life where I'm capable of
42
+feeling anything like love for most software.  Grudging toleration is about the
43
+best I manage these days.  And it's clear that Python has a set of virtues in
44
+the space it occupies.
45
+
46
+The syntax _is_ for the most part easy to grasp, modulo the brittleness of
47
+indentation and a few other infelicities.  The built-in collection types
48
+(lists, dicts, tuples, sets) aren't as easy for a beginner to use as something
49
+like PHP's swiss-army-knife of an array type, but they're also much less
50
+conceptually muddled.  The language seems to encourage a straightforward
51
+procedural style with some light object orientation on top.  Even if this isn't
52
+exactly considered _cool_, there are far worse ways to program.
53
+
54
+In fact, Python's aesthetics are often relentlessly un-hip, which is probably a
55
+useful bulwark against the violently unmaintainable cleverness that infests so
56
+many language cultures in 2019.
57
+
58
+Packaging isn't a lot of fun to figure out, but it basically works once you get
59
+the right boilerplate in place.  PyPI is a mess, but as other language-specific
60
+package managers & repositories have shown us repeatedly, it could be
61
+substantially worse.
62
+
63
+I think most of my _substantive_ ongoing concerns with Python are around the
64
+way bugs seem to proliferate on type boundaries, the tendency of code to spew
65
+exceptions all over the landscape in conditions the developer didn't quite
66
+anticipate, and the swampy nightmare that is the ongoing 2-to-3 version
67
+transition.  (Some of these are mitigated to an extent by the smallness of most
68
+CircuitPython codebases, and the 2-to-3 problem is sidestepped by way of aiming
69
+only for Python 3 compatibility.)
70
+
71
+Very broadly speaking, Python's problems are mostly in classes of problems
72
+shared by that family of dynamic, garbage-collected interpreted languages that
73
+came to prominence in the 90s and early 2000s: Perl, Python, PHP, Ruby, etc.
74
+By the same token, Python shares many of the positive qualities of its
75
+relatives.  There's a vast set of undertakings that are essentially painless in
76
+these languages and excruciating in an environment like C / C++ / Arduino.
77
+
78
+All of this to say:  I was initially skeptical, but it seems like a Python is a
79
+reasonable thing to build a hardware development ecosystem around.
80
+
81
+## reflection 0a: the workflow is pretty good
82
+
83
+Plug in a board, get a USB drive you can drop code onto and a REPL you can
84
+access over serial.
85
+
86
+Ten years ago this would have blown my mind, and in 2019 it still feels like
87
+kind of a revelation.  In most ways, it's a vast improvement over the
88
+ergonomics of the Arduino-style compile-upload-debug cycle.  If you mess around
89
+with hardware and haven't tried this, it's worth playing with.
90
+
91
+## reflection 1: the hardware isn't quite there yet
92
+
93
+...but it's real close.  At this point, I've written CircuitPython code for:
94
+
95
+  - ATSAMD21E18 Cortex M0 boards (48 MHz, 32KB RAM):
96
+    - [Gemma M0][gemma-m0]
97
+  - ATSAMD21G18 Cortex M0 boards (48 MHz, 32KB RAM):
98
+    - [CircuitPlayground Express][cpx]
99
+    - [Feather M0 Express][feather-m0]
100
+    - [Hallowing M0 Express][hallowing]
101
+    - [Feather M0 RFM95 LoRa Radio][feather-radio]
102
+  - ATSAMD51J19 Cortex M4 boards (120 MHz, 192KB RAM):
103
+    - [Feather M4 Express][feather-m4]
104
+    - [Metro M4 Express][metro-m4]
105
+  - Various and sundry iterations of the Raspberry Pi
106
+
107
+Of these, it feels like the SAMD21 boards just don't have enough RAM to do much
108
+that would require more than one driver library.  For instance, I recently
109
+offered to build my dad a remote thermometer for his pump house.  The Feather
110
+M0 LoRa boards seem like they should be ideal for this, since all I need to do
111
+is read a temperature sensor on one board, transmit it, and display the
112
+temperature on the other end.  I just couldn't seem to get the headroom to
113
+import, let alone use, both [Adafruit_CircuitPython_RFM9x][adafruit-rfm9x] and
114
+a driver for any of the several displays I tried.  Ultimately I gave up on
115
+CircuitPython for the project, and plan to complete it in Arduino / C++ with
116
+the [RadioHead][radiohead] library instead.
117
+
118
+I had similar experiences when working up the [Glitter Positioning
119
+System][glitterpos] and an as-yet undocumented USB [pedal-input
120
+project][sl-snakeswitch].  In those cases, I wound up switching to the Feather
121
+M4 Express, and the contrast is dramatic.  The SAMD51 feels like a Real
122
+Computer for this use case, with enough memory to easily handle a LoRa radio,
123
+GPS unit, [LSM9DS1 9-DOF][lsm9ds1], and an RGB LED ring for display output all
124
+at once.
125
+
126
+At the low end of the available hardware, you can glimpse the platform's
127
+possibilities and do some basic projects, but there's a good chance you'll be
128
+frustrated trying to go anyhere beyond that.  At the higher end, it's eminently
129
+possible to do real work.
130
+
131
+## reflection 2: this could be pretty important on linux systems
132
+
133
+This brings me to the Raspberry Pi, where (strictly speaking) CircuitPython
134
+doesn't run, but the project as a whole has quite a bit to offer.
135
+[Adafruit-Blinka][blinka] is a shim that aims to provide most of the core
136
+CircuitPython modules on some common small-board computers with GPIO pins,
137
+which means that CircuitPython drivers and helper libraries can be used from
138
+regular CPython 3.x.  At heart, it's a collection of hacks, but this
139
+nevertheless feels like a game changer for a certain class of hardware projects
140
+on small Linux systems.  It's trivial to use a lot of this stuff, and that in
141
+turn opens up a ton of connections to the rest of the stuff you can do with a
142
+high-level language in a Linux environment.
143
+
144
+At a time when it's nearly impossible for most users to exercise any control
145
+over most of the computing hardware in their lives, this sort of thing feels
146
+like at least a small step in the right direction.
147
+
148
+## reflection 3: the community stuff is well-handled, except...
149
+
150
+Having a code of conduct, doing most development work in the open, welcoming
151
+beginners, involving the user community in code review, etc.:  In general I
152
+think this is a commendably well-managed software project, and plenty of FOSS
153
+efforts could learn something from the overall tone it takes.
154
+
155
+On the negative side, I actively dislike Discord with its CPU-eating
156
+Slack-but-for-gamers vibe, and I continue wishing that GitHub were not eating
157
+all public-facing software development, but I recognize the accessibility these
158
+platforms afford and acknowledge that my side of these questions is presently
159
+in a state of utter defeat, so I won't spill any more virtual ink on the
160
+subject in this context.
161
+
162
+## thoughts / hopes for 2019 and points beyond
163
+
164
+Ok, so some notes on stuff I hope to see improve on the scale of about a year:
165
+
166
+  - **Stability**: Things are much better than when I first tried
167
+    CircuitPython, but there are still glitches to reckon with.
168
+    Occasionally a board will have to be power-cycled to get code to run
169
+    correctly.  Connecting to the REPL over serial sometimes hangs mysteriously
170
+    or prints a bunch of garbage.  Things (unsurprisingly) get downright wacky
171
+    when you run out of memory.  The USB mass storage stuff exhibits some
172
+    unpredictable behavior---writes sometimes fail without much observable
173
+    rhyme or reason.  I'm sure all of this will get better; this is in many
174
+    ways still a young project.  Still, there's a lot of usability to be gained
175
+    just by making the whole thing a couple of notches less flaky.
176
+
177
+  - **Asynchronous processing / multitasking / parallelism / event handling**:
178
+    I have no idea what shape it should take, but people keep wanting _some_
179
+    kind of paradigm for handling asynchronous events in something closer to
180
+    realtime, and I don't think they're wrong to want it.  It's remarkable what
181
+    you can accomplish just by polling inputs in a tight loop, but sooner or
182
+    later you want something better.  Smarter people than me hash some of this
183
+    out in [this GitHub issue](https://github.com/adafruit/circuitpython/issues/1380).
184
+
185
+  - **CPython compatibility**: This is an explicit goal of the project, so I
186
+    don't think there's much danger of it getting lost in the shuffle.  I do
187
+    think it'll improve things the closer it gets to 100%.
188
+
189
+  - **Linux platforms**:  Right now, the Raspberry Pi is still more or less the
190
+    only first-class citizen in terms of Adafruit-Blinka support.  It'd be great to
191
+    see a couple of other stable, widely available platforms added to that
192
+    list.
193
+
194
+  - **Library management**: The experience of installing modules for use on the
195
+    Raspberry Pi is, perhaps oddly, a lot less painful than installing them on
196
+    CircuitPython boards, since you can just use `pip3`.  It'd be interesting
197
+    if there was a nice clean way to use PyPI for dropping libraries into place
198
+    on the CIRCUITPY drive or in a project directory.  (Maybe this is handled
199
+    by tools like [Mu][mu]?  I should know, but I don't because I keep just
200
+    using Vim.)
201
+
202
+  - **Security and privacy**: The way things are going, there are eventually
203
+    going to be a _lot_ of network-exposed microcontrollers running some Python
204
+    variant.  _Some_ of the people responsible for those systems will be
205
+    experienced software professionals, which means that they'll do as well on
206
+    this front as software professionals usually do (i.e., _completely
207
+    terrible_, but many of them will know that security is a consideration and
208
+    when they use the tech to violate your privacy they'll usually be doing it
209
+    on purpose).
210
+
211
+    I'm not, however, convinced that the rest of CircuitPython's target
212
+    demographic is equipped to reason about these problems at all.  As embedded
213
+    systems continue getting smaller, more powerful, and more ubiquitous, this
214
+    is going to matter more and more.  The organizations and projects teaching
215
+    people how to put computers in everything need to start thinking a lot
216
+    harder about how dangerous it is to put computers in everything, and
217
+    communicating that danger to the people they teach.  I'm not sure what form
218
+    that takes with CircuitPython, but I know that it should be on people's
219
+    radar as the platform expands to more devices that handle wifi, bluetooth,
220
+    LoRa, etc.  Particularly given the security track record of web projects
221
+    built on similar languages.
222
+
223
+  - **Community involvement**: Right now, this is an Adafruit joint, through
224
+    and through.  That's fine as far as it goes, but it'll be interesting to
225
+    see whether it ever truly makes the transition to something that a bunch of
226
+    different orgs and individuals outside of the Adafruit bubble are involved
227
+    in.  I think that'd be a good thing, but there's an inherent tension
228
+    between the kind of tight control that's built this project according to a
229
+    well-defined plan and the diversified set of inputs that give projects like
230
+    this a life of their own well beyond the interests of a particular company.
231
+
232
+Anyhow.  That's probably enough rambling for one post.  To reiterate, I
233
+probably don't know what I'm talking about.
234
+
235
+[adafruit-rfm9x]: https://github.com/adafruit/Adafruit_CircuitPython_RFM9x
236
+[ansible]: https://www.ansible.com/
237
+[blinka]: https://pypi.org/project/Adafruit-Blinka/
238
+[cpx]: https://learn.adafruit.com/adafruit-circuit-playground-express
239
+[cpy2019]: https://blog.adafruit.com/2018/12/17/what-do-you-want-from-circuitpython-in-2019-circuitpython2019-circuitpython/
240
+[feather-m0]: https://learn.adafruit.com/adafruit-feather-m0-express-designed-for-circuit-python-circuitpython
241
+[feather-m4]: https://learn.adafruit.com/adafruit-feather-m4-express-atsamd51
242
+[feather-radio]: https://learn.adafruit.com/adafruit-feather-m0-radio-with-lora-radio-module
243
+[gemma-m0]: https://learn.adafruit.com/adafruit-gemma-m0
244
+[hallowing]: https://learn.adafruit.com/adafruit-hallowing
245
+[lsm9ds1]: https://learn.adafruit.com/adafruit-lsm9ds1-accelerometer-plus-gyro-plus-magnetometer-9-dof-breakout/overview
246
+[metro-m4]: https://learn.adafruit.com/adafruit-metro-m4-express-featuring-atsamd51
247
+[micropython]: https://micropython.org/
248
+[mu]: https://codewith.mu/
249
+[radiohead]: http://www.airspayce.com/mikem/arduino/RadioHead/
250
+<include>includes/shortlinks.md</include>
251
+</markdown>

+ 0
- 0
archives/2019/1/20/tag-adafruit.prop View File


+ 0
- 0
archives/2019/1/20/tag-circuitpython.prop View File


+ 0
- 0
archives/2019/1/20/tag-glitter-positioning-system.prop View File


+ 0
- 0
archives/2019/1/20/tag-hardware.prop View File


+ 0
- 0
archives/2019/1/20/tag-python.prop View File


+ 0
- 0
archives/2019/1/20/tag-technical.prop View File


+ 6
- 0
archives/topics/adafruit View File

@@ -2,6 +2,12 @@
2 2
 <table class="tags">
3 3
   <tr>
4 4
     <th>
5
+      <a href="/2019/1/20">2019/1/20</a>
6
+    </th>
7
+    <td>#CircuitPython2019 - reflection 0: python could be worse - reflection 0a: the workflow is pretty good - reflection 1: the hardware isn’t quite there yet - reflection 2: this could be pretty important on linux systems - reflection 3: the community stuff is well-handled, except… - thoughts / hopes for 2019 and points beyond</td>
8
+  </tr>
9
+  <tr>
10
+    <th>
5 11
       <a href="/2018/12/3">2018/12/3</a>
6 12
     </th>
7 13
     <td>platform detection with linux on single-board computers</td>

+ 6
- 0
archives/topics/circuitpython View File

@@ -2,6 +2,12 @@
2 2
 <table class="tags">
3 3
   <tr>
4 4
     <th>
5
+      <a href="/2019/1/20">2019/1/20</a>
6
+    </th>
7
+    <td>#CircuitPython2019 - reflection 0: python could be worse - reflection 0a: the workflow is pretty good - reflection 1: the hardware isn’t quite there yet - reflection 2: this could be pretty important on linux systems - reflection 3: the community stuff is well-handled, except… - thoughts / hopes for 2019 and points beyond</td>
8
+  </tr>
9
+  <tr>
10
+    <th>
5 11
       <a href="/2018/10/4">2018/10/4</a>
6 12
     </th>
7 13
     <td>, a project for Burning Man 2018.</td>

+ 6
- 0
archives/topics/glitter-positioning-system View File

@@ -2,6 +2,12 @@
2 2
 <table class="tags">
3 3
   <tr>
4 4
     <th>
5
+      <a href="/2019/1/20">2019/1/20</a>
6
+    </th>
7
+    <td>#CircuitPython2019 - reflection 0: python could be worse - reflection 0a: the workflow is pretty good - reflection 1: the hardware isn’t quite there yet - reflection 2: this could be pretty important on linux systems - reflection 3: the community stuff is well-handled, except… - thoughts / hopes for 2019 and points beyond</td>
8
+  </tr>
9
+  <tr>
10
+    <th>
5 11
       <a href="/2018/10/4">2018/10/4</a>
6 12
     </th>
7 13
     <td>, a project for Burning Man 2018.</td>

+ 6
- 0
archives/topics/hardware View File

@@ -2,6 +2,12 @@
2 2
 <table class="tags">
3 3
   <tr>
4 4
     <th>
5
+      <a href="/2019/1/20">2019/1/20</a>
6
+    </th>
7
+    <td>#CircuitPython2019 - reflection 0: python could be worse - reflection 0a: the workflow is pretty good - reflection 1: the hardware isn’t quite there yet - reflection 2: this could be pretty important on linux systems - reflection 3: the community stuff is well-handled, except… - thoughts / hopes for 2019 and points beyond</td>
8
+  </tr>
9
+  <tr>
10
+    <th>
5 11
       <a href="/2018/12/3">2018/12/3</a>
6 12
     </th>
7 13
     <td>platform detection with linux on single-board computers</td>

+ 6
- 0
archives/topics/python View File

@@ -2,6 +2,12 @@
2 2
 <table class="tags">
3 3
   <tr>
4 4
     <th>
5
+      <a href="/2019/1/20">2019/1/20</a>
6
+    </th>
7
+    <td>#CircuitPython2019 - reflection 0: python could be worse - reflection 0a: the workflow is pretty good - reflection 1: the hardware isn’t quite there yet - reflection 2: this could be pretty important on linux systems - reflection 3: the community stuff is well-handled, except… - thoughts / hopes for 2019 and points beyond</td>
8
+  </tr>
9
+  <tr>
10
+    <th>
5 11
       <a href="/2016/8/14">2016/8/14</a>
6 12
     </th>
7 13
     <td>verizon i hate you / r.i.p. flickr</td>

+ 6
- 0
archives/topics/technical View File

@@ -21,6 +21,12 @@ I publish code to [code.p1k3.com](https://code.p1k3.com/).
21 21
 <table class="tags">
22 22
   <tr>
23 23
     <th>
24
+      <a href="/2019/1/20">2019/1/20</a>
25
+    </th>
26
+    <td>#CircuitPython2019 - reflection 0: python could be worse - reflection 0a: the workflow is pretty good - reflection 1: the hardware isn’t quite there yet - reflection 2: this could be pretty important on linux systems - reflection 3: the community stuff is well-handled, except… - thoughts / hopes for 2019 and points beyond</td>
27
+  </tr>
28
+  <tr>
29
+    <th>
24 30
       <a href="/2019/1/2">2019/1/2</a>
25 31
     </th>
26 32
     <td>feed discovery in firefox, redux</td>

+ 25
- 19
includes/shortlinks.md View File

@@ -1,19 +1,25 @@
1
-[acg]: http://alangrow.com/blog/
2
-[agpl]: https://www.gnu.org/licenses/agpl-3.0.en.html
3
-[privacy-badger]: https://www.eff.org/privacybadger
4
-[ceu]: https://www.ceu.edu/
5
-[commandlog-gh]: https://github.com/brennen/commandlog
6
-[wrt-cpan]: https://metacpan.org/release/App-WRT
7
-[wrt-gh]: https://github.com/brennen/wrt
8
-[cpan]: https://www.cpan.org/
9
-[galleryhtml-gh]: https://github.com/brennen/galleryhtml
10
-[hcn]: http://www.hcn.org/
11
-[lynx]: http://lynx.invisible-island.net/
12
-[mastodon.social]: https://mastodon.social/
13
-[orgmode]: http://orgmode.org/
14
-[sfe]: https://www.sparkfun.com/
15
-[stilldavid]: https://stilldavid.com/
16
-[tarpit]: https://en.wikipedia.org/wiki/Turing_tarpit
17
-[thcipriani-gh]:  https://github.com/thcipriani/
18
-[thcipriani]:  https://tylercipriani.com/
19
-[userland]: https://p1k3.com/userland-book/
1
+[sl-acg]: http://alangrow.com/blog/
2
+[sl-adafruit]: https://www.adafruit.com/
3
+[sl-agpl]: https://www.gnu.org/licenses/agpl-3.0.en.html
4
+[sl-ceu]: https://www.ceu.edu/
5
+[sl-circuitpython]: https://circuitpython.readthedocs.io/
6
+[sl-commandlog-gh]: https://github.com/brennen/commandlog
7
+[sl-cpan]: https://www.cpan.org/
8
+[sl-galleryhtml-gh]: https://github.com/brennen/galleryhtml
9
+[sl-galleryhtml-p1k3]: https://code.p1k3.com/gitea/brennen/galleryhtml
10
+[sl-glitterpos]: /2018/10/4/
11
+[sl-hcn]: http://www.hcn.org/
12
+[sl-lynx]: http://lynx.invisible-island.net/
13
+[sl-mastodon.social]: https://mastodon.social/
14
+[sl-orgmode]: http://orgmode.org/
15
+[sl-privacy-badger]: https://www.eff.org/privacybadger
16
+[sl-sfe]: https://www.sparkfun.com/
17
+[sl-stilldavid]: https://stilldavid.com/
18
+[sl-tarpit]: https://en.wikipedia.org/wiki/Turing_tarpit
19
+[sl-thcipriani-gh]:  https://github.com/thcipriani/
20
+[sl-thcipriani]:  https://tylercipriani.com/
21
+[sl-userland]: https://p1k3.com/userland-book/
22
+[sl-wrt-cpan]: https://metacpan.org/release/App-WRT
23
+[sl-wrt-gh]: https://github.com/brennen/wrt
24
+[sl-wrt-p1k3]: https://code.p1k3.com/gitea/brennen/wrt
25
+[sl-snakeswitch]: https://code.p1k3.com/gitea/brennen/snakeswitch

Loading…
Cancel
Save