Naming Docker container images

  • Post category:dockerJava

This is something I’ve needed to get off my chest; I really and truly don’t understand the logic behind the scheme of Docker container image names. The first time I tried to grasp it, I got mentally stuck, because it feels to me it blatant ignores any convention. At the moment it is a matter of accepting that this it how it works, but my neurotic side keeps protesting every time I tag an image. Let me explain the beef I have, and then maybe someone can enlighten me.

(N.B. I’m using “docker” in this post, but I actually am using “podman”. But their APIs are identical, so because docker is better known, I’m typing “docker” in this post.)

When you create a new image using the “docker build” command, the newly created image is uniquely identified by a hash, something in the line of 21df6af2a82e0135661ce18a621112450992914e1fcfc0edb285c332318e3e23. This id is totally impossible to convey to other people, so Docker has the possibility to add tags to images. A typical build command looks like

$ docker build --tag my-tag .

This is will use the Dockerfile (Containerfile for podman) to generate an image and add it to the local registry. You can see this by executing a list command:

$ docker images

REPOSITORY        TAG             IMAGE ID      CREATED         SIZE
localhost/my-tag  latest          99bd5445f871  22 minutes ago  280 MB

Wait! What? What is the localhost doing there? And latest?

(more…)

Continue ReadingNaming Docker container images

The default verb

  • Post category:JavaOOP

Naming things in coding is always something of great debate, and important to give appropriate consideration, because it greatly influences readability. And readability -as we all know- is the second most important aspect of source code, the most important one being that it should work of course 🙂

There are competing naming styles; camelcase starting with or without a capital, underscores, all caps, etc. But I do not want to get into that, to each his own. Or her own. Personally I prefer the Java style, with the difference in naming between classes (CamelCase) and methods (camelCase), so I’m going to use that for the examples here.

What I would like to talk about is the concept of a “default verb”. As a rule of thumb class names are nouns; they’re a Factory, or a Singleton, or Person. And methods perform actions on classes, so their name should start with a verb; getName, createInstance, build, walk, …, they do something.

(more…)

Continue ReadingThe default verb

The YAML threshold

  • Post category:JavaXMLYAML

I’m not using YAML a lot. If I need an easy-to-read configuration file, I’m using TECL, but usually XML serves me fine. It is a one-stop-shop for a lot of stuff; anything not code usually can be done nicely with XML. And its verbosity is not really a problem with the current bandwidths, unless you need to send a lot of data. And it is easy enough to read for a human.

(more…)

Continue ReadingThe YAML threshold

Time travel 101

  • Post category:icalJava

Suppose you take 2:30 AM at some random day in the year, and add 366 times one day to it, when do you end up? Yes… 367 times if it’s a leap year, wise guys. But still, when do you end up?

Calendar cal = new GregorianCalendar(2020, 11-1, 1, 2, 30);
cal.setTimeZone(TimeZone.getTimeZone("Europe/Rome"));
ZonedDateTime zdt = ZonedDateTime.of(2020, 11, 1, 2, 30, 00, 00, ZoneId.of("Europe/Rome"));
for (int i = 0; i < 366; i++) {
	System.out.println(cal.toInstant() + "   " + zdt);
			
	cal.add(Calendar.DATE, 1);
	zdt = zdt.plusDays(1);
}

Take a guess before reading on!

(more…)

Continue ReadingTime travel 101

The correcting case of the closed-off cloud

That title sounds like one from a boy’s book, a Tintin (Kuifje) or Spike and Suzy (Suske en Wiske) comic, but this blog is about Tesla, cloud computing, and hexagons.

In the middle of September 2020 Tesla suddenly blocked all network traffic originating from any of the major cloud providers, like Amazon, Google and Microsoft. A number of of third party Tesla apps were suddenly in big problems because of this, including my TeslaTasks. A lot of developers had to scram to work around that unexpected situation.

(more…)

Continue ReadingThe correcting case of the closed-off cloud

TECL

People have complaints about configuration languages all the time; properties are too simple, XML is too verbose, JSON doesn’t allow comments, YAML is only suited for small configuration files, TOML’s tables are a bit weird (IMHO). So how about we throw all the good aspects onto a heap and see what comes out of it? And with only one task in mind: configuration. (Just like JSON is intended for datatransfer, hence it does not support comments.) Therefor I’m introducing TECL, the Totally Encompassing Configuration Language. But the name is open for suggestions. 😀

The goals are:

  • Simple, like properties, but supporting a hierarchy
  • Compact, like JSON, but allowing comments
  • Formal hierarchy, unlike YAML’s indentation based one
  • Schema support
  • Conditions
  • Multi line strings
  • Tables
(more…)

Continue ReadingTECL

Scheduling things on a Tesla using Azure pt. 5; parsing the action

We’re down to the last piece of the puzzel; calendars are examined in a regular interval, we can tell the cars what to do, but those two need to be connected.

It is very practical to quickly see in a calendar what will be happening, and the summary field of an appointment is rendered in any view, so that is the best field to use. Other fields like description are often only visible in a detail view. Below is how I’ve currently setup my Tesla this February (which is winter).

My car goes into a security cam mode every night between 2 and 6 am, by activating sentry mode at home. And I’m making sure the doors are locked and the sun roof is closed. I could also schedule charging at that time, but I want my car to be fully charged ASAP. At weekdays I’m preconditioning the car early in the morning, which means heating up the battery and the cabine. We have a lame winter this year, so that suffices to remove any ice on the windows, but if it were really cold I’d put in “defrost”. You can see that my current schedule takes me to a different project on Tuesdays, with less driving time, so I can leave later.

(more…)

Continue ReadingScheduling things on a Tesla using Azure pt. 5; parsing the action

Scheduling things on a Tesla using Azure pt. 3; the Tesla API

In the previous post we took a look at how the initial just-for-my-own-car implementation was refactored into a version that supported many cars using a database instead of hardcoded values. It also showed that the LogicApp based implementation lost its merrits, and everything was moved into Java code. In this part we’ll take a look at the Tesla API that is used to make the car do things.

(more…)

Continue ReadingScheduling things on a Tesla using Azure pt. 3; the Tesla API

Scheduling things on a Tesla using Azure pt. 2; from one to many

  • Post category:azureJava

Some time has passed since my previous post about fixing the issue that a Tesla does not allow scheduling preconditioning (de-icing) the car prior to a drive in the winter. The original post used an Azure Logic app as its core.

AzureLogic

What you see above is a Logic app for my car only; the first step “When an event starts” is linked to a Tesla calendar in my personal Google Calendar. The “StartHVAC” and “EndHVAC” call out to serverless functions that hardcoded contain the data for my personal car. And the emails go to a hardcoded email address of mine. Totally not reusable, but working.

After publishing that post, people started to ask if they could use the same functionality as well. Ahm, I did just say it was not reusable, didn’t I? But being a good friend, I ventured out and rewrote the whole thing to support multiple calendars and cars.

(more…)

Continue ReadingScheduling things on a Tesla using Azure pt. 2; from one to many

Post Java 8 upgrade; ignoring the module

  • Post category:JavaJPMS

Java 9 introduced a major change in the way Java programs are written, because of the Java Platform Module System (JPMS). And that is not something you can ‘skip’ by moving to a higher Java version; upgrading your software to any version after Java 8 means you have to deal with JPMS.

That is the reason a lot of companies are still stuck at Java 8, but at some point in the future they and everyone else will need to upgrade. Java 11 is the first Long Term Support (LTS) version of Java, and that seems to be the version of choice for a lot of migrations.

Upgrading my open source project, JFXtras, to Java 9 a few years back was a breeze. I have had more problems with the build tool (Gradle) than with the modularization of the code. But that is because the code is fairly new and already modularized using Gradle (Maven) artifacts. But in the last weeks I’ve tried to upgrade a 15+ years old custom made ERP system to Java 11… That turned out not to be a breeze.

(more…)

Continue ReadingPost Java 8 upgrade; ignoring the module