Written by: Robert R. Russell on Friday, July 31, 2020.
I am planning on a video for today’s post. It is processing right now, and that
will take some time. Hopefully, it will be prepared and uploaded before 17:00
tonight.
Written by: Robert R. Russell on Thursday, July 30, 2020.
There will not be a new post today. I have been running into several problems
trying to get a video done for the Friday post. The Saturday post maybe a rant
about getting OBS to record in a better intermediate format than x264.
Written by: Robert R. Russell on Wednesday, July 29, 2020.
I am using Gulp.js or just Gulp for automating the compilation of CSS
stylesheets for the upcoming custom WordPress theme for this blog. In the
process of getting that automation setup, I have concluded that NPM’s extremely
lax requirements for adding a package to their servers have resulted in an
explosion of abandonware.
One of Gulp’s useful advantages over a more traditional solution like make
is its choice to pass virtual files around between stages of the processing
chain. Parts of the Gulp chain can modify the contents of a file and pass on
those modifications without writing them to disk and creating dozens or more
temporary files that require exclusion from git and other tools. The most
constructive use of this ability I have found so far is a tool that can replace
strings in files based on variables I setup.
NPM manages Gulp’s dependencies and plugins. Since creating a new public NPM
package is pretty easy, sharing a plugin you wrote doesn’t take any time.
That all sounds great until you end up trying to use a plugin and find that
no one has updated it for one or two major versions of Gulp. Worse yet is the
situation where some dependency is several versions behind, and either is a
security vulnerability itself or requires another dependency that is.
I don’t have time to maintain a public NPM package. I may fix one or two
outdated plugins I am probably not going to share those fixes on NPM.
Written by: Robert R. Russell on Tuesday, July 28, 2020.
I have been designing websites as a side gig for about a year now. Most of that
design work has been CSS modifications to existing themes. Since January, I have
needed to do more extensive design changes. That work culminated in a
scratch-made WordPress theme designed for people using WordPress as a CMS, not a
blog platform.
During that time, I have begun preferring Gutenburg’s design philosophy over
Elementor’s. Gutenburg does a better job of separating content, and
content-specific layout from the general theme layout than Elementor does.
Gutenburg also seems less opinionated about its block styling than Elementor.
The downside to flexibility is a lack of capability to micromanage the layout. I
don’t see the appeal of complicated website designs that demand pixel alignment
from individual paragraphs or worse letters. I tend towards a utility first
approach. That utility first approach doesn’t mean that I do not appreciate any
artistry. I cannot entirely agree with form over function.
I like the mobile-first approach to design. However, I do get frustrated at the
limitations of mobile devices because they can complicate the implementation of
proper form and function. A navigatable mobile interface for tabular data is one
example.
Written by: Robert R. Russell on Monday, July 27, 2020.
Some backstory
In my post about OpenWRT on x86 hardware, I mentioned that I considered
balenaEtcher’s size to be a negative trait. I also complained in Yarn versus
NPM about the dependency management for Node.js projects.
Both complaints stem from a similar problem, Using a tool without respect for
its constraints.
Constraints?
All tools have constraints. For physical tools like a hammer or saw, they have
to do with how the tools materials, size, and shape affect whether it scratches
a surface on impact or how smooth the cut is. Digital tools like software also
have constraints. C, for example, treats nearly all data structures as merely a
location in memory. This provides excellent flexibility at the ease of creating
memory leaks and buffer overruns.
The creators of a programming language have both a problem domain and several
other constraints to juggle when creating the language. The original problem
domain especially restricts the general utility of the language.
What does that have to do with the examples in the backstory?
All of those programs use the JavaScript programming language. Netscape
originally designed JavaScript to make small dynamic changes to a browser’s
DOM. Combined with a choice for fast iteration, JavaScript ended up without a
robust typing system and little attention to modularity.
You can see the attachment to a browser’s DOM in Electron. The programming
environment that balenaEtcher uses. Two hundred and four megabytes, installed,
for a program whose task is to order a dozen or so command-line tools around.
The failure to update transitive dependencies that I ran into using Yarn is
a side effect of how Yarn deals with JavaScript’s lack of module separation.
The original program I wanted to use didn’t help matters by choosing a broad
semantic range for their dependencies.
Conclusion
Like physical tools, software, including programming languages, has
constraints. Strive to be a polyglot so you can use the appropriate tool for
the job.
Written by: Robert R. Russell on Sunday, July 26, 2020.
Backstory and why
I switched to using OpenWrt as my preferred firmware for SOHO routers 5 or 6
years ago. During that time, I used it on a Linksys WRT 1900AC. However, over
the last few months, I have had to use another WRT 1900AC that is using Linksys’
provided firmware. The Linksys firmware works for necessary routing. It’s
troubleshooting, and firewall management tools leave a lot to be desired,
though.
Due to constraints on the current home/lab network, I can’t reassociate a few
WiFi devices with either OpenWrt on the current WRT 1900AC or replace it
entirely with another WRT 1900AC running OpenWrt.
So restricting the current router to just the WiFi access point role is what I
am limited to doing. The next question is what should replace it in the role of
network router? My three options appear to be:
The other WRT 1900AC running OpenWrt
An old computer running pfSense®
Or the same old computer running OpenWrt
Onto the testing
Right now, I am testing the old computer running OpenWrt option. So far, the
installation was simple. I downloaded the latest version from the OpenWrt
Releases page. For a 64 bit x86 device, the required target is x86/64. I went
with the combined-ext4 image. After downloading the device image, I wrote it
directly to the hard drive I am dedicating to the new router. I installed the
hard drive in the computer and booted it up.
Contrary to the OpenWrt documentation, I could use a keyboard to login to the
local console on the test rig. My biggest complaint so far is the lack of
software installed by default. Most x86 hardware that you would run OpenWrt on
are much more potent than the other devices they support. I expected that Samba
and ReadyMedia formerly MiniDLNA would be installed though disabled by default.
Most SOHO routers you can buy have the option of being a NAS, so OpenWrt not
including the software for that by default in the install image for the most
spacious target they support is a bit odd from my perspective.
Interesting stuff learned during the process
While I prefer Rufus for writing ISO or disk images to USB media, the OpenWRT
documentation recommended using a tool called balenaEtcher. I decided to try it
out. I do like that it validates that the flashing process completed. I also
like that it can handle compressed images directly saving the step of
uncompressing the image before writing it.
What do I not like about balenaEtcher? File size. Rufus will fit on a single
3.5″ High Density or HD floppy disk. balenaEtcher would need 89 floppy disks.
For my younger audience who don’t know what floppy disks are, you can read about
them on
Wikipedia.
The High Density disks have a useable storage capacity of about 1.44 Megabytes.
Written by: Robert R. Russell on Saturday, July 25, 2020.
Over the last few days, I have had to use both Yarn and NPM to attempt to
install two different programs for a couple of home networking experiments. The
dependency packaging of Node projects leaves something to be desired. Problems
with dependency fulfillment become especially apparent when the package manager
pulls in dependencies that are several years out of date for some reason.
I eventually figured out which dependency was causing the problems and that a
non-feature breaking update would solve the problem. Yay, I can get the problem
solved quickly and get back to testing a new networking feature for my home
lab. A yarn update node-gyp upgrade should have solved the problem.
Over 30 minutes of running around in circles trying to get yarn to update a
transitive dependency. A short sequence of
Installing npm-check-updates
running npm-check-updates -u
and npm update
Meant I had node-gyp and several other outdated dependencies updated.
Yarn might be better than NPM for running a built Node package, but it isn’t
the easiest to use when a dependency update is required.