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

Please use Maven!

  • Post category:Javajfxtras

Before 2004 the defacto standard build tool for Java applications was ANT. It was a step up from the make-based way of building Java software; it featured standard tasks, like compile and jar, that you needed in most projects. It was a first attempt to make building java applications more declarative.

But as time moved on, and projects become ever more complex, so did the ANT scripts. You ended up with scripts calling scripts, calling scripts, calling scripts, … And soon building an application was just as complex as the average nuclear fission paper. Not even mentioning trying to assemble the right versions of all the dependencies into the libs folder.

(more…)

Continue ReadingPlease use Maven!

TDD; an exercise in frustration

Recently I read an article about How to TDD a List Implementation in Java and it suddenly reminded me of an experience a colleague made me go through a few years back. At that time the company I was working for had a big piece of software with almost no automated tests, and they (of course) had stability issues. So I was an advocate of starting to write automated tests; by developers, by testers, unit tests, UI tests, the works, in an attempt to get the software stable.

After a year of hard work solely focused on bug fixing and writing tests, it finally started to pay off. (Yes, that is what it takes; the company decided to not release any new features for a whole year, but in the end it paid off big time. Major growth in market share, because clients took notice. But it took guts to choose that path.)

Testing had become common practice by then and at one point a colleague came up to me and asked me what I though about Test Driven Development (TDD). I said that it didn’t feel right, so he asked me if I wanted to give it a try.

Well… Of course!

(more…)

Continue ReadingTDD; an exercise in frustration

I have an idea; let’s write automated tests!

In the previous post I wrote about a lecture I did in Utrecht. It was about that companies decide that they “should be doing automated tests”, but are unaware of what that really means. Often the idea is triggered because it becomes apparent that even though a lot of money is spent on (manual) testing and testers, the quality of the releases does not really increase, and automated testing is seen as the answer. Which it is, at least partially.

In my lecture I stressed that automated testing is more than just rolling out JUnit. Automated testing involves careful consideration on what and when to test; a good testing landscape consists of several types of test, from unit tests, to integration tests and UI tests. And more importantly those should be in the correct ratio’s, ideally resulting in the famous testing pyramid (and hopefully not the dreaded testing cone).

testingpyramid

(more…)

Continue ReadingI have an idea; let’s write automated tests!

The occasional speaker

The JavaOne has ended and it was both under- and overwhelming. But on a more personal note I was not satisfied with how my talk went. Being an occasional speaker, I naturally am a bit nervous at the beginning, but somewhere along the line that usually goes away. This means I get into ‘the zone’, and feel inspired by the subject I am talking about.

However, this was not the case during my talk at the JavaOne; it kept dragging a bit, never gaining the momentum I’m used to. And I have been wondering about the reason; I’ve done the talk more often, so it is not that I don’t know what to tell on a given slide. It just didn’t… Take off.

So different from yesterday, when I was in Utrecht, giving a talk about automated testing. The setting there was… Cozy. Informal. I wasn’t even really nervous at the beginning, even though it was the first time I did the lecture, and I wasn’t sure if I had enough slides, or too many. Certainly the deck was way less pruned and polished than the JavaOne’s, but it took mere seconds to get into the groove.

Keylane

(more…)

Continue ReadingThe occasional speaker