This is the first post continuing my exploration of web browsers outside of Firefox and Google Chrome. You can read the introduction here.

Running Vivaldi for the first time.

For the first browser I wanted to check out on Windows, I decided to check out Vivaldi. My thought process is that I’m most likely to end up with Brave, so better to save that one for last. But as I went through the first-run process in Vivaldi and saw the nice polish the browser seems to have, it really started tugging on me, saying, “Are you sure you wouldn’t want to just stay with Vivaldi?” For this first post, I’d like to cover the first-run process and then a little video poking around the interface. This’ll be followed up in a while with any impressions I’ve come away from my usage of Vivaldi on Windows.

It’s been a while since I last considered web browsers. I wrote this post in 2008 about which browsers I was using. And in 2011 I wrote this post about KDE Browsers. So that’s at least 9 years since I wrote about browsers. What is my current situation?

Well, on Linux I bounced back and forth between Firefox and Chrome, depending on which one was getting better performance. At this point, for what I do, Firefox is the winner for me. I use it on my laptop and desktop and it gets things done without getting in my way. I don’t necessarily have the most modern GUI setup because it tends to keep your GUI settings as you upgrade. This is what it looks like:

Stella’s Project

Because last week was busy with house projects, this week I continued the ocean/water-themed programming from the Raspberry Pi Foundation. The first project was a game I made with Stella (her first computer game creation), a boat race in Scratch. While we mostly stuck to the tutorial, we did partake in the challenges, including adding a shark and figuring how to have background music (which Stella chose on her own). That turned out to be really tough as my attempts to figure out how to use the loops led to stuttering. Eventually I figured it out and you can see what I did, the rest of the code, and how the game plays by watching the video below:

Scratch

Starting off with this code from the Raspberry Pi foundation, Sam made his first ever video game. I then modified it so the shark would close his mouth when he eats the fish and added a sound at the end when a score of 5 was reached. Here’s a video of Sam playing his game:

https://youtu.be/mWh-5psvDls

Python

For Python I continued to work on writing unit tests for my Extra Life Donation Tracker. Doing so helped me find a few bugs and a few functions that I was able to combine to reduce the code complexity. Overall, this has been a very productive phase for the project, even if it has been very frustrating figuring out how to mock out certain functions like those reaching out to the net or those writing to disk. Depending on what I can do with some help that someone offered me on reddit, I will either go back to the extralife_io.py file to try and finish that one up or I may declare unit testing completed for now and tackle that later when I’ve learned even more about how Python works and how to test it.

I’ve mostly been working on version 5.0 of my Extra Life Donation Tracker. Since I adopted the Semantic Versioning principle for the project, an API change means a major version change. I’ve been taking everything I’ve learned about Python programming from 2019 and 2020 and tried to make my code both more Pythonic and more sophisticated. I’m also trying to move towards 100% code coverage. That is to say, I’m looking to try and make sure every line of code is covered by a test. While 100% test coverage doesn’t guarantee perfect code (after all, the test itself could be flawed or I might not be considering corner cases), striving for it usually has a few benefits:

I don’t know how long I intend to keep doing this, but I decided I wanted to document my programming as I went along. So yesterday I worked on Scratch and here’s today’s entry.

Ruby

A while ago I got a bunch of kids’ programming books in a Humble Bundle. I tried showing Ruby to my oldest, but I did it one year too soon (she wasn’t yet reading as well as she is today and couldn’t type as well as she can today) so for now she’s not into programming. But I was curious to see how it was presented since the book uses a story to present it (quite different from the Python book in the same bundle). Went through chapter 2 today and, so far, it seems that Ruby is pretty readable like Python is. That said, I’m not sure puts makes more sense than print, but maybe if I delve into the history of Ruby, I’ll understand why it’s puts? The author of this book uses snake case for variable names. I wonder if that’s because it’s the Ruby standard to use snake case instead of camel case or just to make it easier for the kids following along. I *did* really like the built in next and pred methods on numbers. Definitely more readable than a var++ or var = var + 1. Or rather, if you don’t have decades of programming experience (as I do), I think it’s just a faster bit of cognition to see var.next and understand it vs the older ways of doing the same thing.

First of all, if you’re a Linux user and would like an offline version of Scratch 3, you can get it from https://scratux.org/. They make binaries for a few Linux distros plus an AppImage which works on any of them. On the Raspberry Pi Blog I saw that this week was about making art on the computer. So Stella and I went through the tutorial for making flowers in Scratch. Here’s what the code blocks looked like:

Last year when I went to Red Hat Summit, I saw a lot of use of Satellite. I’d tried the 5.x series’ upstream Spacewalk and it didn’t quite work out for me. But this time I would try it out, gosh darnit! I mean, with the Katello plugin it would even include Pulp, which I’d been interested in trying out before because it could cache RPMs during an upgrade. So I’ve been messing with it here and there. However,I don’t use Puppet scripts (it’s like Chef or Ansible in principle) and I don’t have the need to provision new machines or VMs (especially when that’s already pretty easy with Cockpit and/or Virt-Manager). It’s already easier and works more consistently for me to keep track of whether my computers are up to date (and update them if not) with Cockpit. The RPM caching part of it was neat, but recently it stopped working consistently. Upgrades are VERY fragile and messing up on installing a plugin could bork the whole system. Also the necessary files - puppet, katello-agent, etc were always behind in providing packages for Fedora. Turns out it was a bunch of extra work and frustration just to keep track of my computers - and I was already doing that in Dokuwiki.

Because I have this VM registered to Katello (Foreman plugin) to receive updates (basically as a way of both keeping track of the computers and VMs on my network and also to have a GUI to pulp for caching RPMs), I had to deal with Katello-Agent. The latest RPM in the official Foreman/Katello repos is unfortunately for Fedora 29. That version of Fedora has been out of maintenance for a long time. Maybe Foreman (upstream for Satellite) is just used by most of their customers for RHEL sites that don’t have any Fedora nodes? So I did find this copr that provides updated versions: https://copr.fedorainfracloud.org/coprs/slaanesh/system-management/

When it came to new dishes, April was all about bread. First, I made a no-knead bread with America’s Test Kitchen’s recipe.

Almost No-Knead Bread

It came out OK. I actually tried it again the following day to try and get a darker crust. The funny thing is that this is one of the easiest breads to make and yet it’s the one I’ve had the worst results with. The crumb wasn’t as open as it was supposed to be and for all the time it took to proof it was pretty meh.