The problem with this machine is that it only outputs 1920p to a 4K monitor with Ubuntu, which is pretty annoying. According to the Dell Inspiron 13-5379 spec the connector is HDMI 1.4a, which should support 4K. However, only HDMI 2.0 supports 4K with 60FPS, HDMI 1.4a only supports 4K with 25 or 30 FPS. My Inspiron employs Intel i7-8550U which should support 4K at 60FPS.

Previous article mentioned four of the most important yet most basic resources to monitor for the health of your JVM, but also of your system:

If your server-side JVM app chokes up when serving 20 concurrent users, then there is something very wrong. Luckily, it’s usually very easy to find out the initial hint as to where the problem may lie.

When you need to use Push with your Vaadin app, you generally have two choices: Long Polling and Web Sockets. Which one to use?

This happens to me every now and then. I’m developing a Vaadin app, then I switch to another one and suddenly the Vaadin session expires immediately, or Vaadin complains that the cookies are disabled. What does this bug mean and how can we work around that?

Karaf is an OSGi container rather than a WAR container. Hence it is not as easy to deploy your WAR into Karaf as opposed to, say, Tomcat. You basically have three options:

• Split your WAR into separate jars, add OSGi descriptors to all of those so that Karaf recognizes them as OSGi bundles, then plug your servlets into Karaf’s pax-web something. That’s a lot of work.
• Repackage your WAR as JAR with JARs, add OSGi descriptor so that Karaf recognizes that as a big bundle, then plug your servlets into Karaf’s Pax-Web. That’s still a lot of work.
• Use WAR Deployer and just copy your WAR to the deploy/ folder. Ta-daa! This is the easiest way of deploying WAR to Karaf, the one that doesn’t require you to add OSGi manifests to your WAR and/or tackle the XML bundle configurations. Let’s go.

The Vaadin-on-Kotlin framework contained the support for feeding the outcome of a SQL query to the Vaadin Grid for the long time. However, since VoK is based on Kotlin, Java developers probably avoided this solution and looked for a Java-based example. Well, here it is:

While I don’t recommend using Spring because of simplicity reasons, there are valid reasons to have Spring support. For example when building UI for an already existing Spring-based backend, or when gradually converting a legacy application to VoK.

I’d like to write something positive, but I can’t - my experiences with CouchBase had been highly negative. I’d even dare to say it’s an unfinished piece of junk; if you need to setup a syncing platform from your Android app, avoid CouchBase like a plague.

Creating Vaadin UIs from Java code has the following disadvantages:

Proper building construction is to have a proper design which includes all latest state-of-the-art components and follow all safety precautions. The building won’t collapse and it will be great. If you however use this approach with software, you will fail.

The client-side in Vaadin 10 is completely different than the one in Vaadin 8 and the layouting manager from Vaadin 8 is completely gone. Vaadin 10 layouting is therefore something completely different to Vaadin 8 layouting. Naturally, it is something completely different to Android layouting. Here we will focus on layouting completely configured from server-side, and not from a CSS file.

There are lots of Android SDK sucks and android development is a pain rants indicating that development on Android is a horrible experience. Instead of repeating the same thing over and over again, I’ll try to sum up why I will definitely prefer Vaadin-based PWA for my next project over Android SDK:

In the previous blog post we’ve used self-signed certificate with Docker Tomcat. However, in order to have a properly protected web site, we need to use a proper set of certificates. We’ll use the Let’s Encrypt authority to obtain the keys at no cost.

It is possible to use pem-style certificates with Tomcat Docker image, without any need to store them first into the Java keystore. This is excellent since not only it is easier to generate self-signed certificate with the openssl command, this can also be used with certificates produced by Let’s Encrypt.

I have to admit upfront that my brain is somehow incompatible with JPA. Every time I try to use JPA, I will somehow wind up fighting weird issues, be it LazyInitializationException with Hibernate, or weird sequence generator preallocation issues with EclipseLink. I don’t know what to use merge() for; I lack the mean to reattach a bean and overwrite its values from the database. I don’t want to bore you to death with all of the nitty-gritty details; all the reasons are summed in Issue #3 Remove JPA. I think that the number 1 reason of why JPA is incompatible with me is that

I’m sure that Thomas Kriebernegg, the CEO of App Radar will be happy to persuade you that you can make a living by selling Android Apps. He needs to - his way of making a living is to sell services to Android devs so he better make sure there are lots of Android devs; discouraging devs from becoming Android devs would be a financial suicide. But why not trying out your luck? After all, Flappy Birds was making $50,000 a day in ads; Clash of Clans makes millions of dollars. Let me tell you a fucking secret: you are not going to be the author of Flappy Birds and Clash of Clans, and let me tell you why.

Teamcity is quite a nice continuous integration server from Jetbrains. The set up is not that easy though since you typically need to install the TeamCity server itself, and at least one agent which will perform the building itself.

When Kotlin 1.1 brought in Coroutines, at first I wasn’t impressed. I thought coroutines to be just a bit more lightweight threads: a lighter version of the OS threads we already have, perhaps easier on memory and a bit lighter on the CPU. Of course, this alone can actually make a ground-breaking difference: for example, Docker is just a light version of a VM, but it’s quite a difference. It’s just that I failed to see the consequences of this ground-breaking difference; also, performance-wise in Vaadin apps, it seems that there is little need to switch away from threads (read Are Threads Obsolete With Vaadin Apps? for more info).

Let me start by saying that threading model (or, rather, single thread model) provides the most simplistic programming paradigm - the imperative synchronous sequential programming. It is easy to see what the code is doing, it is easy to debug, and it is easy to reason about (unless you throw in dynamic proxies, injected interfaces with runtime implementation lookup strategy and other “goodies” of the DI) - that’s why having such paradigm is generally desirable. Of course that holds only when you have one thread. Adding threads with no defined communication restrictions overthrows this simplicity and creates the most complex programming paradigm.

Nicolas Frankel put some of my feelings into an excellent article Is Object-Oriented Programming compatible with an enteprise context?. During the development of Aedict Online (still as a Java-based JavaEE/JPA app back then, now it’s Vaadin-on-Kotlin-based), when trying to find rows from JPA+DB I often tried to find the necessary functionality on the JPA entity itself. Wouldn’t it be great if, upon user’s log in, we could find the user and verify his password using the following code?

It is indeed possible to write Vaadin 10 Flow apps in Kotlin. Here are a couple of resources to get you started:

Traditionally, the testing of a web portal is done from the browser, by a tool which typically using Selenium under the hood. This type of testing is closest to the user experience - it tests the web page itself. Unfortunately, it has several major drawbacks:

In his blog about comparing Kotlin and Java features, Simon was IMHO too kind. Creating a prototype of some app in Kotlin, then converting the code painfully to Java (simply because Java is company’s lingua franca) and watching it inflate and obfuscate itself is quite an eye-opening experience.

So you have built your first awesome VoK app - congratulations! You will probably want to launch it outside of your IDE, or even deploy it somewhere on the interwebz. Just pick up any virtual server provider with your favourite Linux distribution.

Obsolete as in Cobol - used widely, but on a descendant trajectory. Let’s ask a very simple question:

Or what-if-a-fucking-meteor-falls-down-and-swaps-1s-and-0s

Once a project leaves the rapid development phase and enters the calm waters of maintanenance mode, the programming paradigm changes. Fancy hyped frameworks favored by project creators no longer play important role. What matters most now is the code readability and understandability. The code is already written - now it is going to be read, understood and fixed. After all, that’s usually what happens to the code - it is written once but read by many. This is true both for open-source, but also for closed-source: people in the team come and go, and new team members need to read the code, to familiarize themselves with it.

You have your superdevmode development environment up and running. All is peachy and world is unicorns until you figure out that some pesky bug is only reproducible on a cell phone. Bam. What now?

When trying to fix some browser-side issue in Vaadin built-in components, it is often useful to modify those component sources while your app is running. This way, you can modify e.g. VButton.java, refresh your browser with F5 and immediately see the changes done in Vaadin Button. This blogpost describes how to configure Intellij to do just that.

When doing mobile development with Vaadin, you often develop the app on your dev machine and view the page on a tablet or a phone. Yet, entering your dev machine IP into the phone browser may be tedious and error-prone. There is a way though, to enter an URL to your phone. Via a camera, as a QR Code.

Let’s discuss the most useful cases for the extension methods. First use-case: extension methods allow to apply themselves only selectively. For example, the following method only applies to a list of Person:

Now if there was some way to get rid of that pesky em -> which needs to be written every time one calls the db {} function. If only there was a way we could tell a block to “know” some variables implicitly… Maybe we could throw those “variables” into a class and tell the block to run as some kind of an extension method in that class? That could work - extension methods have direct access to the receiver object methods and variables. Remember our findAll() method?

I’ll get to the forms right away. But first, I want to talk extension methods. They are immensely helpful in adding functionality to objects. Note that Kotlin is not a dynamic language - the methods will not really be added to target classes, it is just a syntactic sugar. Quite delicious, though. So, EntityManager misses the findAll method - let’s fix that. Open the DB.kt file and add this to the end:

Let’s add some database to our hello-world. I’ll use the pure-Java embedded database called H2 which will run as a part of our application, so there is no need for you to install any database engine. Open the pom.xml file and add the following lines at the end of the dependencies element:

Kotlin provides some very interesting language features which are immensely helpful when writing Vaadin apps. Let us start from scratch, building necessary functionality as we progress. The result of this exercise will be a Kotlin-based simple web app, built with Gradle, using Hibernate+JPA o store entities into the database. I will not use Spring nor JavaEE here - the whole thing will run in a pure Servlet environment like Tomcat or Jetty. The complete exercise may take some 60 minutes. I will be using Intellij IDEA Community which you can download for free here: Download IDEA. When installing, just press the “Skip remaining” button to install Intellij with the default settings.

When one tries to migrate her project to a newer version of a framework, it usually helps if the transition is smooth and the original code works without any modifications. This way, you can convert the code to the new API gradually, and never encounter this OMG-shit-doesn’t-compile-everybody-blocked period for a long time.

If you ever used Selenium (or TestBench, which is based on Selenium), you know the pain of configuring the testing browser driver: