Researching mp3 cover art downloaders

So, I have this huge mp3 collection that is mostly missing cover art.  I embarked on a quest to add cover art to each mp3 file, and before long I realized that I need some software to help me with it.  Here I am documenting my findings.


Rooting my Android Phone

In this post I am documenting the process of rooting my Samsung Galaxy Note 4. It should work on the majority of Android phones out there.


Solved: Windows Explorer shows generic thumbnails instead of embedded album art for music (mp3) files

I have a large number of mp3 files, all of them with embedded album art, but when viewing them via  Windows Explorer, I see generic music file icons instead of album art thumbnails.

Generic music icons.  Ugh.

I spent a good couple of hours troubleshooting this problem, so I would like to document the solution for anyone who happens to go through the same pain.


Confucius on naming

"If names be not correct, language is not in accordance with the truth of things."

This is paraphrased as a chinese proverb stating

"The beginning of wisdom is to call things by their proper name."

 From https://en.wikiquote.org/wiki/Confucius


GitHub project: mikenakis-rumination

This project has been retired. The github link does not even work anymore. 
This page only serves historical documentation purposes.

Making plain old java objects aware of their own mutations.

The mikenakis-rumination logo.
Based on original from free-illustrations.gatag.net
Used under CC BY License.


GitHub project: mikenakis-testana

A command-line utility for running only those tests that actually need to run.

The mikenakis-testana logo, profile of a crash test dummy by Mike Nakis
Used under CC BY License.


GitHub project: mikenakis-classdump

A command-line utility for dumping the contents of class files.

The mikenakis-classdump logo.
Based on an image found on the interwebz.


GitHub project: mikenakis-bytecode

A lightweight framework for manipulating JVM bytecode.

The mikenakis-bytecode Logo, an old-fashioned coffee grinder.
by Mike Nakis, based on original work by Gregory Sujkowski from the Noun Project.
Used under CC BY License.


On Coding Style

Since I have a few projects on GitHub, I suppose a word or two are in order, on the subject of coding style.

When I write code within a team of developers, I use the team's coding style.

However, when I write code for myself, I use my very own™ coding style.

In my career I have experimented a lot with coding styles, mostly while working on pet projects at home, but also in workplaces where each developer was free to code in whatever way they pleased, or in workplaces where I was the only developer.

My experimentation has been in the direction of achieving maximum objective clarity and readability, disregarding convention, custom, precedent, and the shock factor: the fact that a particular style element might be alien to most developers out there plays little role in evaluating the objective merit of the element.

So, over the years I have tried many things, once even radically changing my coding style in the middle of a project. (Modern IDEs make it very easy to do so.)  Some of the things I tried I later abandoned, others I permanently adopted.

So, my coding style today is the result of all this experimentation. If it looks strange to you, keep in mind that every single aspect of it has been deliberately chosen to be this way by someone who was not always coding like that, and who one day decided to start coding like that in the firm belief that this way is objectively better. 

In moving on with each of these changes over the years, I had to overcome my own subjective distaste of the unfamiliar, for the benefit of what I considered to be objectively better. 

So, if you decide to judge my coding style, please first ask yourself to what extent you are willing to overcome the same.


GitHub project: mikenakis-agentclaire

This project has been retired. The github link does not even work anymore. 
This page only serves historical documentation purposes.

A Java Agent to end all Java Agents.

The mikenakis-agentclaire logo
based on a piece of clip art found on the interwebz.


Open Source but No License

I have posted some small projects of mine on GitHub, mainly so that prospective employers can appreciate my skills. I am not quite ready to truly open source them, so I published them under "No License".  This means that I remain the exclusive copyright holder of these creative works, and nobody else can use, copy, distribute, or modify them in any way, shape or form. More information here: choosealicense.com - "No License" (https://choosealicense.com/no-permission/).

Pretty much the only thing one can legally do with these creative works is view their source code and admire it.

GitHub says that one can also make a copy of my projects, (called fork in GitHub parlance,) but I am not sure what one would gain from doing that, because you cannot legally do anything with the forked code other than view it and admire it.  Even more information here: Open Source SE - GitHub's “forking right” and “All rights reserved” projects (https://opensource.stackexchange.com/q/1154/10201)

(Okay, if you compile any of my projects and run it once or twice in order to check it out, I promise I will turn a blind eye.)

If you want to do anything more with any of these projects, please contact me.


On JUnit's random order of test method execution

This is a rant about JUnit, or more precisely, a rant about JUnit's inability to execute test methods in natural method order. 

Definition: Natural method order is the order in which methods appear in the source file.

What is the problem?

Up until and including Java 6, when enumerating the methods of a java class, the JVM would yield them in natural order. However, when Java 7 came out, Oracle changed something in the internals of the JVM, and this operation started yielding methods in random order.

Apparently, JUnit was executing methods in the order in which the JVM was yielding them, so as a result of upgrading to Java 7, everybody's tests started running in random order. This caused considerable ruffling of feathers all over the world.

Now, the creators of the Java language are presumably running unit tests just like everyone else, so they probably noticed that their own tests started running in random order before releasing Java 7 to the world, but apparently they did not care.

Luckily, the methods are still being stored in natural order in the class file, they only get garbled as they are being loaded by the class loader, so you can still discover the natural method order if you are willing to get just a little bit messy with bytecode. 

However, that's too much work, and it is especially frustrating since the class loader is in a much better position to correct this problem, but it doesn't.  (The class loader messes up the method order probably because it stores them in a HashMap, which yields its contents in Hash order, which is essentially random. So, fixing the problem would probably have been as simple as using a LinkedHashMap instead of a HashMap.)

People asked the creators of JUnit to provide a solution, but nothing was being done for a long time, allegedly because if You Do Unit Testing Properly™, you should not need to run your tests in any particular order, since there should be no dependencies among them. So, the creators of JUnit are under the incredibly short-sighted impression that if you want your tests to run in a particular order, it must be because you have tests that depend on other tests.

When the creators of JUnit finally did something to address the issue, (it did not take them long, only, oh, until Java 8 came out,) their solution was completely half-baked: the default mode of operation was still random method order, but with the introduction of a special annotation one could coerce JUnit to run test methods either in alphabetic order, (which is nearly useless,) or in some other weird, ill-defined, so-called "fixed" order, which is not alphabetic, nor is it the natural order, but according to them it guarantees that the methods will be executed in the same order from test run to test run. (And is completely useless.) 

So, apparently, the creators of JUnit were willing to do anything except the right thing, and even though JUnit 5 is said to have been re-written from scratch, the exact same problem persists.

Why is this a problem?

Well, let me tell you why running tests in natural method order is important:

We tend to test fundamental features of our software before we test features that depend upon them, so if a fundamental feature fails, we want that to be the very first error that will be reported. (Note: it is the features under test that depend upon each other, not the tests themselves!)

The test of a feature that relies upon a more fundamental feature whose test has already failed might as well be skipped, because it can be expected to fail, but if it does run, reporting that failure before the failure of the more fundamental feature is an act of sabotage against the developer: it is sending us looking for problems in places where there are no problems to be found, and it is making it more difficult to locate the real problem, which usually lies in the test that failed first in the source file.

To give an example, if I am writing a test for my awesome collection class, I will presumably first write a test for the insertion function, and further down I will write a test for the removal function. If the insertion test fails, the removal test does not even need to run, but if it does run, it is completely counter-productive to be shown the results of the removal test before I am shown the results of the insertion test. If the insertion test fails, it is game over. As they say in the far west, there is no point beating a dead horse. How hard is this to understand?

Another very simple, very straightforward, and very important reason for wanting the test methods to be executed in natural order is because seeing the test method names listed in any other order is brainfuck.


Douglas Crockford talking nonsense

Here is Douglas Crockford,
talking patent nonsense about Java and about exceptions,
neither of which he understands, obviously.

Start playing at 27':42''. The insanity lasts until 32':00''.
Enjoy responsibly.


Mike Nakis on Code Craftsmanship

I was once asked what are my favorite means of ensuring the quality of the code that I write. Off the top of my head I could give a few answers, but it occurred to me afterwards that I could of course have said a lot more. I will try to make a list here. I could probably write a book on this.



A short high-tech sci-fi horror story by Mike Nakis
written in the evening of January 25, 2018.

There was a guy who got in a quarrel with his girlfriend, and she kicked him out of her apartment without even throwing his clothes out the window to him. So there he was, naked on the street, not knowing what to do. Out of necessity, he grabbed a tablecloth from a restaurant, draped himself with it, and started to go home, trying to look as if everything was normal and under control.

People saw him walking down the street draped with a tablecloth, and thought that he must be making some sort of fashion statement. Some of them decided to imitate him by also wearing tablecloth, and lo and behold, before you knew it there was a tablecloth-wearing movement that was gaining ground like wildfire.

Imagine that all this happened a long time ago, and you are now living in a society in which a large part of the population is regularly wearing tablecloth. Wearing tablecloth is considered perfectly normal, even by people who do not wear it. A multitude of explanations have been invented after the fact to try and explain why tablecloth is better than conventional clothing, as if wearing tablecloth was invented on purpose, to address specific needs.  They will try to convince you to also wear tablecloth with truly disarming statements like the following:
  • Tablecloth is easy: you don't have to learn how to use complicated buttons and zippers and belts and buckles and what not; just hold it in place with your hand.
  • Tablecloth is simple: it is one size fits all, one shape suits all, no need for designs, no need for cutting and sewing parts together, and the best thing of all? no seam lines!
  • Tablecloth is convenient: when putting it on, you don't have to make your hands fit through sleeves and your legs fit through trousers; you just throw the tablecloth over you, and you are good to go. Want to take it off? no need for complicated motions, just let it fall off of you.
  • Tablecloth is fashionable. Tablecloth is hip. Tablecloth is cool. Who can argue with that?

And that, ladies and gentlemen, was my javascript analogy.


Tablecloth is a source of innovation. Every six months or so, someone comes up with a new pattern for printing on tablecloth, which invariably becomes an instant fashion hit, thus revolutionizing the way we dress.