| Legacy code woes |
|
Saturday, July 1st, 2017 23:42:28 GMT |
| Programming |
I've been feeling so overwhelmed lately by my Puppy Linux Setup Kit, my messy neglected websites, and Astroblahhh Desktop. Overwhelmed and stuck.
Actually, I've felt that way for years, which is probably part of why I've procrastinated so much about continuing to work on these projects at all.
I hadn't realized that even much better, wiser, more experienced programmers than me can have immense trouble with this kind of project if they make the kinds of mistakes I've been making, such as trying to change too many things at once, not doing test-driven development (TDD), and overly optimistically attempting "big-bang rewrites".
How to Improve a Legacy Codebase
Those articles and their advice look very wise to me, not that I would know. But I'm guessing that doing even just some of what is suggested might go far better for me than doing what I've been doing.
In many ways, I unintentionally designed things naively and poorly at the outset. I didn't document things well enough, and I took such long breaks from working on my own code that by the time I returned to it, I had forgotten a ton of details.
And for many years, I didn't even know what test-driven development (TDD) was. I finally tried it in 2015 or 2016 and liked it, but, quite unwisely, I still usually haven't gone to the trouble lately, and I probably ought to learn more about it so I can be more sure I'm doing it right.
And mostly, it was actually surprisingly much easier than I expected, by the time I finally got around to really trying to do it instead of just daydreaming about it.
Every day, or probably almost every hour I use a computer at all, I rely on something or other I built, like Navig, Ramize-Physave, termwin, or something I modified, like my modified version of VUE: Visual Understanding Environment.
And even though my Puppy Linux Setup Kit has a ton of room for improvement and additional convenience, at least it still is much faster and more convenient than manually trying to do everything my setup kit already does automatically.
The idea of releasing more of my work more frequently definitely appeals to me a lot. I've felt so guilty about not creating and/or releasing way more useful (or otherwise beneficial) stuff into the world already. And many people think sharing in-progress work publicly and frequently can result in much better software.
Preparing things for publication definitely encourages me to do a better job than I tend to do with things I don't expect to release anytime soon (if ever). Not that I don't still make numerous dumb mistakes either way, but I think maybe I make fewer dumb mistakes when I create something with publication in mind.
I sure wish I could do a perfect job on everything all the time, but, I've learned that I better not insist too stubbornly on perfection or I'll never get anything done.
That happened because I finally learned more about how to use Git and GitHub, so I've been sharing my work more frequently by releasing it on GitHub. Currently, that's much easier than uploading files to my own websites.
In retrospect, I maybe shouldn't have even announced Salty XML Transformer, because it's such a chore even for me to install, because I haven't made even my own not-yet-released Puppy Linux Setup Kit fully up to date yet.
I probably shouldn't encourage people to use the old legacy versions of my setup kit. Certainly not yet. At some point I'm going to try to release many of my old-style setup kit scripts that I made since the last release in Feb. 2015 - but even I'm trying to get away from being stuck using any old-style version anymore, even my current best not-yet-released version.
I sure wish I could somehow gradually create a smooth transition from the old-style setup kit to the new-style setup kit I'm still trying to design and build. Or some kind of clever hybrid of the two.
In any case, please don't expect dazzling results soon, or maybe not for a very long time, and sorry I have been so incapable thus far of doing far more.
And I still don't feel up to trying to sift through whatever gigantic backlog of mostly spam (and perhaps some real emails) I might have gotten in the past several years, but, hopefully I'll get around to that someday. Sorry for being so unreachable.
And hopefully someday I'll figure out how to delete the literally hundreds of thousands of spam messages there are in the Non24.Com Forum without deleting any of the few non-spam messages, and also how to truly block new spam messages so the same thing doesn't happen again.
But, recently, reading some articles about working on legacy code made me feel better and less worried that maybe I'm just not really cut out to be a programmer.
Here are a couple of those articles:
April 25, 2012 from DanLimerick.wordpress.com
May 30, 2017 from JacquesMattheij.com
Even though (as far as I know) I'm the only person who ever worked on my Puppy Linux Setup Kit, Astroblahhh Desktop, and other languishing projects of mine, these projects have all been through the entire lifecycle mentioned in that first article, and have long been stuck in the last phase.
I'm quite frustrated that I haven't gotten much more done by now, but, I probably shouldn't be too hard on myself. If I were really a hopelessly bad programmer:
So, I'm definitely not even close to totally giving up on programming forever (though I feel very intimidated by the idea of trying to make a serious career out of it). But I think I need to be a lot more cautious and less naively optimistic than I was in the past.
Fortunately, already, without even knowing it (at first), I seem to have been moving away from the "cathedral" model of free/libre software development, "in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers", toward the "bazaar" model, "in which the code is developed over the Internet in view of the public".
So, currently, this is the place to look for my absolute newest updates to whatever software projects:
Not much of what I've been adding lately has seemed notable enough (or easy to install or interesting or useful enough) for me to announce in new blog posts, so, I mostly haven't mentioned them here.
By the way, I recently found out that ever since sometime in July 2016, the latest released version of the Puppy Linux Setup Kit (v1.1) was far less functional than I thought, because unfortunately, some of the files the old setup kit optionally tries to download are no longer available. Many went missing simply because I neglected to log into my Dropbox account for over a year, so my Dropbox account was automatically deleted in July 2016. Sorry for any inconvenience!
Anyway, even though I'm quite tired of struggling with all these tedious legacy projects, I probably am not close to giving up yet. Or even if I do turn my attention to other things for a while, I'll probably return to them eventually.
▲ Top ▼ Bottom △ TOC ↓ Down Up ↑
| How to make YouTube HTML5 audio work with Lighthouse 64 Puppy Linux 6.02 Beta 2 and a Sewell USB Sound Box |
|
Monday, July 31st, 2017 08:40:30 GMT |
| Puppy Linux |
I finally found a way to make YouTube's HTML5 player play audio while I'm using my Sewell USB Sound Box with Lighthouse 64 Puppy Linux 6.02 Beta.
Previously, I simply used the YouTube Flash Video Player web browser add-on instead of struggling to make the HTML5 player work. But, that add-on recently stopped working for me in the Pale Moon web browser. I tried upgrading Pale Moon, but that didn't fix the audio either.
But luckily, after a few days, I stumbled across this helpful forum thread. Post #10 contained all the info I needed. Thanks to all the authors of that thread!
Here's what I did:
/etc/asound.conf in a text editor. (You might want to make a backup copy of the asound.conf file in case anything goes wrong.)
/etc/asound.conf with the settings from the above-mentioned Post #10:
▲ Top ▼ Bottom △ TOC ↓ Down Up ↑
| How to compile Pale Moon 27.4.1 from source code in Lighthouse 64 Puppy Linux 6.02 Beta 2 |
|
Monday, July 31st, 2017 11:35:28 GMT |
| Puppy Linux |
Several days ago, after less than an hour of trying, I successfully compiled my favorite web browser, Pale Moon, from source code, in Lighthouse 64 Puppy Linux 6.02 Beta 2!
The reason I did that was because I thought upgrading my web browser might solve my issues with YouTube's HTML5 player not playing audio. (I was mistaken, but, I finally found a solution!)
And when I tried to simply download the latest precompiled version of Pale Moon for Linux, 27.4.0, it wouldn't run on my system because of this error. (Which also happened with at least one older version many months ago):
So, my only remaining option was to try to build Pale Moon from source code.
Happily, it was a lot easier to build than I thought it might be. That was the first time I ever attempted to build a web browser from source code, and I was prepared to spend hours on it if I had to.
But, to my own surprise, it only took me about 45 minutes to figure out, thanks to various helpful web pages. And it will hopefully take much less time in the future, now that I've written this blog post, which even I will be able to refer to someday when I've forgotten most of the below details.
And I was only able to build it there - a location inside my Puppy Linux RAM disk - because my current computer has a huge amount of RAM - 32 GB, which gives me a 16 GB Puppy Linux RAM disk.
So far, I wasn't able to figure out how to make the ./mach command build Pale Moon someplace other than
If you need a copy of the DevX SFS file, you can get it from here:
So, I downloaded autoconf-2.13.tar.gz from here:
make
new2dir make install
I put "new2dir make install" instead of "make install" because I wanted to make Puppy Linux .pet and .sfs installer files for Autoconf 2.13, so I hopefully wouldn't have to repeat this process again.
That file's size is about 230 MB.
If you don't have as much RAM as I do, you might want to unzip that folder to someplace on a physical disk.
I copied and pasted the example .mozconfig file from the official instructions for how to build Pale Moon in Linux: https://developer.palemoon.org/Developer_Guide:Build_Instructions/Pale_Moon/Linux
But, I found I couldn't use exactly that, because the build got interrupted because I didn't have PulseAudio. And I much preferred to avoid installing PulseAudio because of its association with the infamous systemd.
Here's my final .mozconfig file, which you should place inside the "Pale-Moon-27.4_RelBranch" folder before the next step:
As I mentioned before, I don't know how to do that yet - sorry.
So, the rest of these instructions will simply assume you have enough RAM, as I did.
Then, I just had to wait a while - 801 seconds, or 13.35 minutes. However, I was using a pretty good 2.8 GHz computer with 8 cores. So it might take more or less time depending on what you're using.
Surprisingly, this Mac Pro can run Lighthouse 64 Puppy Linux 6.02 Beta 2, which makes it tremendously nicer for me to use than Mac OS X Lion does.
This was much faster to finish than the build, and resulted in a tarchive quite similar to the official precompiled Pale Moon tarchives.
That tarchive was in the folder
In my system, by default, my Pale Moon profile is located at:
To back it up, I close Pale Moon, and wait a little while to try to make sure Pale Moon is finished writing any files to that folder.
Then I zip the folder, and put the zip file somewhere on a physical disk.
I assume backing up the folder simply by copying the folder to a physical disk might also work, though I haven't tried that lately.
That will launch Pale Moon 27.4.1 with your usual old Pale Moon profile, so, you hopefully won't have to reinstall your add-ons and other customizations from scratch.
I upgraded from Pale Moon 26.2.2, and so far, I haven't noticed any problems with any of my old add-ons or anything else, though I haven't checked thoroughly.
And while you're there, you can add a lot of other handy search engines.
./palemoon: /lib/libc.so.6: version `GLIBC_2.17' not found (required by ./palemoon)
Since the build process was a bit more complicated than just ./configure; make; make install, and I thought I might need to know how to do it again someday, and that others might like to know too, I decided to document it.
However, the below instructions will probably have to be modified if you don't have enough RAM, because the final /home/root/pmbuild folder on my system ended up being over 3 GB, or 3264 M, to be more exact.
/home/root/pmbuild. I'm guessing the best place to look for answers would be the official Pale Moon forum.
I also haven't tried these instructions in any other Puppy Linux, nor any other GNU/Linux. So, I don't know what changes might need to be made for other Puppies or GNU/Linuxes.
./configure
mv /usr/bin/autoconf /usr/bin/autoconf269
ln /usr/local/bin/autoconf /usr/local/bin/autoconf213
Fortunately, this forum thread gave me a clue of how stop Pale Moon from trying to use PulseAudio.
./mach build
I'm actually using a used Mac Pro from 2008, which looks like a giant cheese grater. :-) And I actually like it a lot, even though I usually prefer to avoid Apple products.
The ./mach build command resulted in a large folder at /home/root/pmbuild/. I forgot to check its size before running the next step, but after the next step, it ended up being over 3 GB! 3264 M, to be more exact.
./mach package/home/root/pmbuild/dist/ and named "palemoon-27.4.1.linux-x86_64.tar.bz2".
/root/.moonchild productions
I'm very happy with my Pale Moon upgrade so far. It is noticeably faster than the old version I contentedly used for probably over a year, Pale Moon 26.2.2.
| CATcerto |
|
Monday, July 31st, 2017 13:09:03 GMT |
| Music |
CATcerto. ORIGINAL PERFORMANCE.
by Mindaugas Piečaitis and Nora the Piano Cat.
You might also like to visit CATcerto.com.