DEV Community: Johannes Zillmann

CSS main page layout with resizing and scroll overflow sections

Johannes Zillmann — Tue, 12 Sep 2023 01:56:04 +0000

Here is a picture of the layout I want:

┌─────────┬───────────────────────┐
│ Sidebar │ Editor                │
│         │                       │
│         │                       │
│       ◄─┼─►                 ▲   │
│         │                   │   │
│         ├───────────────────┼───┤
│         │ Preview           │   │
│         │                   ▼   │
│         │  Table                │
│         │  <overflow-scroll>    │
│         │                       │
└─────────┴───────────────────────┘

The whole page should not be scrollable (more like a desktop app, 100vw +100vh).
The Sidebar should be vertically resizable
The Editor should be horizontally resizable
The Preview should take up the rest of the space. Overflow should be managed via vertically + horizontally scrolling.

Initial Problem

I was using flex box instruction here and there. While that worked in general for putting things where I want them to be, ultimately it lead to parts of the table being rendered outside of the visible and reachable area.

Naively I thought the browser knows what space is left for the table (because of 100vw +100vh on html) but that isn't true.

So i implemented the same layout in css grid and flex box (but this time a wholesome flex box which wraps the entire screen vertically and horizontally).

Flexbox approach

The code is in Svelte+Tailwind. Didn't take the time to unwind that further.

<script lang="ts">
  import Resizer from './Resizer.svelte';

  let sidebarWidth = 256;
  let topHeight = 312;
</script>

<svelte:head>
    <script src="https://cdn.tailwindcss.com"></script>
</svelte:head>

<div class="wrapper">
  <!-- SIDEBAR -->
  <aside id="sidebar p-2" aria-label="Sidebar" class="sidebar p-2" style:--sidebar-width={sidebarWidth}>
    <span class="font-bold text-xl">Sidebar:</span>
    <span>
      Lorem ipsum!
    </span>
  </aside>

  <!-- SIDEBAR/MAIN DIVIDER -->
  <div class="shrink-0 px-1">
    <Resizer
      size={sidebarWidth}
      min={128}
      max={512}
      orientation="vertical"
      onResize={(newSize) => (sidebarWidth = newSize)}
      onResizeEnd={() => {}}
    />
  </div>

  <!-- MAIN -->
  <div id="main" class="main">
    <!-- TOP -->
    <div id="top p-2 bg-green-100" class="mainTop" style:--top-height={topHeight}>
      <span class="font-bold text-xl">Top:</span>
      Lorem ipsum?
    </div>

    <!-- TOP/BOTTOM DIVIDER -->
    <div class="shrink-0 py-2">
      <Resizer
        size={topHeight}
        min={64}
        max={5120}
        orientation="horizontal"
        onResize={(newSize) => (topHeight = newSize)}
        onResizeEnd={() => {}}
      />
    </div>

    <!-- BOTTOM -->
    <div id="Bottom" class="mainBottom">
      <span class="font-bold text-xl">Bottom:</span>
      Lorem ipsum.
    </div>
  </div>
</div>

<style>
  :global(.html) {
    height: 100vh;
    width: 100vw;
  }
  .wrapper {
    height: 100%;
    width: 100%;
    display: flex;
  }

  .sidebar {
    width: calc(var(--sidebar-width) * 1px);
    overflow: scroll;
    flex-shrink: 0;
    border: 1px solid yellow;
  }

  .main {
    display: flex;
    flex-direction: column; 
    min-width: 0;
  }

  .mainTop {
    height: calc(var(--top-height) * 1px);
    overflow: scroll;
    border: 1px solid yellow;
  }

  .mainBottom {
    flex: 1 1 0%;
    overflow: scroll;
    border: 1px solid yellow;
  }
</style>

Play around with it at https://svelte.dev/repl/674dcfad17aa4b628e5c2fef4fda100f?version=4.2.0

CSS Grid approach

The code is in Svelte+Tailwind. Didn't take the time to unwind that further.

<script lang="ts">
  import Resizer from './Resizer.svelte';

  let sidebarWidth = 256;
  let topHeight = 312;
</script>

<svelte:head>
    <script src="https://cdn.tailwindcss.com"></script>
</svelte:head>

<div class="wrapper">
  <!-- SIDEBAR -->
  <aside id="sidebar" aria-label="Sidebar" class="sidebar p-2" style:--sidebar-width={sidebarWidth}>
    <span class="font-bold text-xl">Sidebar:</span>
    <span>
      Lorem ipsum!
    </span>
  </aside>

  <!-- SIDEBAR/MAIN DIVIDER -->
  <div style="grid-area: sidebarResizer;">
    <Resizer
      size={sidebarWidth}
      min={128}
      max={512}
      orientation="vertical"
      onResize={(newSize) => (sidebarWidth = newSize)}
      onResizeEnd={() => {}}
    />
  </div>

  <!-- TOP -->
  <div id="top" class="mainTop p-2" style:--top-height={topHeight}>
    <span class="font-bold text-xl">Top:</span>
    Lorem ipsum?
  </div>

  <!-- TOP/BOTTOM DIVIDER -->
  <div class="" style="grid-area: mainResizer;">
    <Resizer
      size={topHeight}
      min={128}
      max={640}
      orientation="horizontal"
      onResize={(newSize) => (topHeight = newSize)}
      onResizeEnd={() => {}}
    />
  </div>

  <!-- BOTTOM -->
  <div id="Bottom" class="mainBottom p-2">
    <span class="font-bold text-xl">Bottom:</span>
    Lorem ipsum.
  </div>
</div>

<style>
  .wrapper {
    display: grid;
    grid-template-columns: auto auto 1fr;
    grid-template-areas:
      'sidebar sidebarResizer mainTop'
      'sidebar sidebarResizer mainResizer'
      'sidebar sidebarResizer mainBottom';
    gap: 5px;
    height: 100vh;
    width: 100vw;
  }

  .sidebar {
    grid-area: sidebar;
    width: calc(var(--sidebar-width) * 1px);
    overflow: scroll;
    border: 1px solid yellow;
  }

  .mainTop {
    grid-area: mainTop;
    height: calc(var(--top-height) * 1px);
    overflow: scroll;
    border: 1px solid yellow;
  }
  .mainBottom {
    grid-area: mainBottom;
    overflow: scroll;
    border: 1px solid yellow;
  }
</style>

Play around with it at https://svelte.dev/repl/ed4679d507c04c34a512db05cf6de601?version=4.2.0

Conclusions

Think the grid variant is far more comprehensible.
Flexbox is cluttered with not so obvious tricks to make it work
(try removing min-width: 0 or some of the flex: 1 1 0% statements).

Hope there is something for somebody in here! 🙏

Fullstack with Svelte & tRPC

Johannes Zillmann — Tue, 22 Nov 2022 02:01:18 +0000

Usually I just do backend-less Svelte apps. This time around I tried to go full stack in javascript/typescript.

I started with Svelte-Kit but then decided for Svelte - with a typical Vite build on the frontend - and Fastify + tRPC on the backend.

The project

Find the project at https://github.com/jzillmann/svelte-trpc-skeleton. It's just a skeleton project with minimal setup (mono repo, NPM workspaces) and a cookie based login.

I spare to list the individual setup steps since there is nothing sophisticated here. If you need those OR if you like video tutorial have a look at https://www.youtube.com/watch?v=Lam0cYOEst8. I found it excellent and it's basically the same setup just with different technologies.

Why not Svelte-Kit

Svelte is one of a few frameworks I dare to say I love. So going with Svelte-Kit was an obvious choice for me.
Why I left that path ?

The application I want to build is well suited for SPA (single page application). So I gain very little from SSR (server side rendering) and the build in routing.
While Svelte-Kit's page endpoints are properly typed (typescript), the shadow/server endpoints are not yet and those are the ones I would use most heavily. (see https://github.com/sveltejs/kit/issues/647 for progress on this)
With the Fastify/tRPC stack I can make use of more of the existing HTTP features like
- Using web-sockets (Svelte-Kit is not there yet: https://github.com/sveltejs/kit/issues/1491)
- Cancelling of HTTP requests (see https://www.reddit.com/r/SvelteKit/comments/yjdx13/detect_aborted_request_on_the_server/)
Overall it seems like the chosen stack is a little more lightweight and easier to grasp then getting familiar with Svelte-Kit.

Final Words

Since I didn't do much beyond the project setup, final judgment is not here yet, but I feel excited about it!

Also, there are things the skeleton could be improved upon... like:

testing setup
unified typescript setup
unified formatting/linting setup
real production settings
etc...

It's not my priority to do these things, but feel free to contribute if you feel like it!

Chasing a hundred rabits at a time — A dev week

Johannes Zillmann — Sun, 13 Dec 2020 21:15:43 +0000

Chasing a hundred rabits at a time — A dev week

I wish i was that guy who is enjoying the doing more then the achieving. If i were, last week would have been a great adventure with many surprising turns… truly enjoyable. But i’m not, and thus last week felt particular annoying.

If you are into developing software you probably know those days:

You start with a well defined task.
You are well motivated. Already, you have it even solved — at least in your head.
You start touching the system and things go downhill from there. You are finding one flaw after another and — if you’re not stepping back at the right time — you’re trying to solve 10 things at the same time while being pressured by not proceeding with your initial task. Not very sustainable for your brain on the long run as i perceive it.

Last week was like that for me. Every single day. Quite unusual since i haven’t had these things for a longer time and i never had them strong like that. Thus i feel the urge to write things down and recapture the story.

Context

At my company we work on a system which sits between your data warehouses and your intelligence tools (Spotlight). Kind of a unified access layer to your data in this regard.

For the past couple of weeks i was working on a benchmark suite. How is the performance of the system with a particular cluster size and a particular configuration, when the data sits in S3, when the data sits in Snowflake, when … you get it…

The Task

Integrate Redshift into our TPC-H benchmark suite

Data in the scale factors 1, 10 and 100 was already on S3.
Benchmark infrastructure was ready and running for a couple of other source system.
All there left to do, was to setup the tables in Redshift and do little coding and configuration work on the benchmark setup side of things.

The Slow Start

I know we already had an Redshift cluster up and possibly even the TPC-H data was on it. Thus my first step was to discover what’s there.

That wasn’t wild, but it already started to annoy me a bit:

With almost 10 different AWS accounts the company runs and 4 to 5 different regions in use, find you’re way through the web-console world. Good luck… But with colleagues who know, not a big deal.
What ? You found the cluster, you have the credentials but it won’t tell you the existing databases unless you name one ? 🤦

Things going downhill — the web-service and data generation battle

The data is already on S3, i’ve now fully control over the Redshift database, i found blogs describing how to setup TPC-H on Redshift (DDL’s included), so what could possibly go wrong ?

Action — Problem sequence getting the data setup in Redshift

If that would have been all

As pictured in the flow graph above, getting the data in the right shape into Redshift was a longer journey than expected. I’ve didn’t even include all the details, like the EC2 machine is was using had only 2 disk, each of approximate 93 GB of free space(The benchmark data in one format was 100GB, with the biggest file 70 GB), wich required quite a bit of chunking the data generation and upload work. However, once i had this done, problems didn’t stop to flow:

The benchmark suite started to fail on setting things up
Did current changes in the communication protocol didn’t make it into the benchmark project ? No exactly… the deployed version was just mismatched with the client library.
How did i find out ? Just deployed a current dev version…
Just comes with a litlle sarcasm here. Turned out that the old way of deploying custom versions was broken. The new way didn’t work with the particular AWS account i was using. Thanks to extraordinary devops support we got things running after 5 iterations.

And just on my last weekday (Thursday for me), when things started to settle down (but i still had a couple of verifications on my list) i got a call. Hey we need you for that other urgent thing… 😤

Could i’ve done better ?

For sure i could have shortened the cycles here and there, like trying to generate the data on my laptop had no thinking attached to it at all. But even if i did all things perfectly, it still would have felt like the universe conspired against me and it wouldn’t have been considerably faster.

Final Words

Often the final judgement just depends on the perspective. There are quite some positive things that did happen on the way:

I’ve strengthened my bash script skills to make the steps reproducible.
I’ve learned a bit of S3 ACL syntax on the way.
I discovered that our existing data was flawed.
Technically, I understood it all ;)

But i guess the major thing i put on my wishlist for next year is… that i be more of that guy who enjoys a surprising challenging journey!

JS/TS Managing alternative implementations with RollupJS

Johannes Zillmann — Sun, 24 May 2020 18:01:17 +0000

Short post about a trivial thing to do. I’m in the JS/Electron world. I just decided I want to package my app for Electron but for a regular Browser as well. Why ?

A) I can do a demo version of the app on the web!
B) I can use Cypress for testing it!

Will see how far this goes, but currently i’m using only two Electron/Desktop features that can be easily mimicked in an browser environment:

Reading and Writing app config => ElectronStore / Local Storage
Reading and Writing files => Node FS API / Local Storage

Basic Structure

Simple. Lets just focus on the app config.

I defined a common ‘interface’ (AppConfig)
One implementation wrapping ElectronStore (ElectronAppConfig)
A second implementation wrapping the local storage (LocalAppConfig).

Most Naive Approach

I just kept all 3 classes under /src with a factory method:

export function createAppConfig(appConfigSchema) {
  if (__electronEnv__) {
    const ElectronStore = require('electron-store'); 
    return new ElelectronAppConfig(new ElectronStore({schema:appConfigSchem}));
  } else {
    const defaults = Object
      .keys(appConfigSchema)
      .reduce((o, key) => ({...o, [key]: appConfigSchema[key]['default'] }),{});
    return new LocalAppConfig(window.localStorage, defaults);
  }
}

Then in the rollup.config.js i’m using the plugin-replace to steer the __electronEnv__ variable:

import replace from '@rollup/plugin-replace';

const electronEnv = !!process.env.ELECTRON;

plugins: [
  replace({__electronEnv__: electronEnv}),
]

And finally i enrich my NPM electron tasks with then env variable in the package.json:

"electron": "ELECTRON=true run-s build pure-electron",

That’s it for the naive approach. It’s working most of the times (sometimes there is a hiccup with a require not found error, but a rebuild usually solves it).

Anyway, the purist in me, wanted a clearer structure and also the inline require statements seemed odd.

Moving to a more satisfactory approach

Have another folder next to /src, let’s called it /includes with three sub-folders:

api : AppConfig, …
electron : index.js (contain factory methods for all electron implementations), ElectronAppConfig, …
browser : index.js (contain factory methods for all browser implementations), LocalAppConfig, …

Now use plugin-alias to alias the index.js of the desired implementation at build time in rollup.config.js:

import alias from '@rollup/plugin-alias';
const electronEnv = !!process.env.ELECTRON;
const storagePackage = electronEnv ? 'electron' : 'browser';

plugins: [
  alias({
    entries: [
      { find: 'storage', replacement: `./includes/${storagePackage}/index.js` }
    ]
  })
]

And access the implementation in your main code:

import { createAppConfig } from 'storage';

const appConfig = createAppConfig(appConfigSchema);

Easy. Not too much gain here, but some clearer structure!

And now in Typescript…

Once i moved to the approach above, i thought ‘Ok, lets try typescript’. Cause that’s an obvious thing to do if you’re talking about interfaces and implementations, right ?

I failed using the exact same approach but luckily the typescript path-mapping came to rescue:

Here is the rollup.config.js part:

import typescript from '@rollup/plugin-typescript';

plugins: [
 typescript({ target: 'es6', baseUrl: './', paths: { storage: [`./includes/${storagePackage}/index.js`] } })
]

Imports work the same as in the previous approach!

Final Words

Not sure if i delivered on the promise of shortness, but finding the second/third approaches took me longer than expected and drove me almost nuts. Part i blame on my inexperience in the JS world, part is that the search space for such a problem seems heavily convoluted. That said, there might be a couple of alternatives worth investigating:

Dynamic Modules: https://medium.com/@leonardobrunolima/javascript-tips-dynamically-importing-es-modules-with-import-f0093dbba8e1
Multiple packages (with individual dependencies) managed with… lets say Lerna…

If you have any feedback or inspiration, let me know!

Getting started with Electron and Svelte

Johannes Zillmann — Mon, 14 Oct 2019 19:44:32 +0000

Short tutorial setting up a blank but working Electron app with Svelte.

There are some project templates for exactly this purpose out there. Each one had some sweets but also some oddities (like producing ton’s of warnings in Electron’s dev console). So i massaged and combined them and came up with what i’m describing here!

Setting up Node & Svelte

Create or navigate into your empty project folder and execute the following commands in your terminal:

npx degit sveltejs/template
npm install

This should create the package.json and a Rollup configuration with basic Svelte.

A little cleanup to be made… If you have a look at the package.json you will see sirv-cli as only production dependency. You won’t need this for Electron, so move it to dev:

npm install sirv-cli --save-dev

Relativize all of your links inside the public/index.html for usage through Electron. One example:

<script defer src='/build/bundle.js'></script>

becomes

<script defer src='build/bundle.js'></script>

Svelte is ready to go! Test it out by executing

npm run dev

and open http://localhost:5000. You should see a Hello World printed!

Setting up Electron

Install Electron (plus npm-run-all & cross-env) as a dev dependency:

npm install --save-dev --verbose electron 
npm install --save-dev npm-run-all
npm install --save-dev cross-env

Create the electron main script - i will call it electron.js — under src/

Now edit your package.json and

Add following line under the existing version line:

"main": "./src/electron.js",

Add 2 commands to the scripts section:

"electron": "run-s build pure-electron",
"pure-electron": "electron ."

Electron app is ready to go! Test it by executing:

npm run electron

Live Reload for Electron

You are now able to build and run the Electron app. In order to have a live reload (updating the app when you change your CSS/JavaScript files) do the following.

Install the Chokidar library which helps with file watching:

npm install chokidar --save-dev

Edit src/electron.js and add the following code to the createWindow() function under the instantiation of the mainWindow variable:

let watcher;
if (process.env.NODE_ENV === 'development') {
 watcher = require('chokidar').watch(path.join(__dirname, '../public/build'), { ignoreInitial: true });
 watcher.on('change', () => {
 mainWindow.reload();
 });
}

Also close the watcher in the existing mainWindow.on(‘closed’…

if (watcher) {
 watcher.close();
}

Now add these commands to your package.json:

"electron-dev": "run-p dev pure-electron-dev",
"pure-electron-dev": "cross-env NODE_ENV=development electron ."

Live reload ready to go! Test it by executing

npm run electron-dev

and e.g. adding another exclamation mark to the headline inside of src/App.svelte!

Bundling a distribution (OS X)

In order to build a distribution, you have a couple of options. Most common are Electron Packager (Electrons default bundler) and Electron Builder. Both come with their own ways of configuring a distribution, so don’t mix them up. I will show how to build a minimal OS-X bundle with Electron Builder.

Install the package:

npm install electron-builder --save-dev

Create a electron-builder.yml file in the root of your project:

appId: "my.app.id"

# Package app code into a asar archive. Set to false to debug issues.
asar: true

# Mac OS configuration
mac:
 icon: "public/icons/my_app.icns"
 category: "public.app-category.utilities"

Add this command to package.json:

"dist-darwin": "run-s build pure-dist-darwin"
"pure-dist-darwin": "electron-builder --dir --mac --config electron-builder.yml"

Thats it! If you are on Mac, you should now be able to execute

npm run dist-darwin
open dist/mac/svelte-app.app

In the quickstart guide you’ll find out how to customize the most basic things , e.g:

Change the app name through changing the name in the package.json.
Change the window title through changing the title in public/index.html.

Setting up app icons (OS X)

By default the app will use the electron icon. You can customize this easily, once you have a icon image and know how to produce the required artifacts from it. Here is how i did it:

Used Gravit Designer to create an image.
Exported the image as PNG.
Used Icon Generator to generate the icons from the PNG
Renamed the generated icon folder from AppIcon.appiconset to AppIcon.iconset (so iconutil can work with it)
Execute on terminal:

iconutil -c icns AppIcon.iconset

Moved the AppIcon.iconset to what is configured in the electron-builder.yml.

In case you think you did everything correctly but still see the standard Electron icon… Try the following:

touch dist/mac/template-electron-svelte.app
touch dist/mac/template-electron-svelte.app/Contents/Info.plist

Final Words

This is just a starter. For Electron functionality refer to it’s excellent guide: https://electronjs.org/docs. To build and publish releases see https://www.electron.build/.

Find the complete code under https://github.com/jzillmann/template-electron-svelte. The commits are structured similar to this article!

Hope this helped you as much as if it would have helped me! Let me know if you have any simplifications or recommendations on that!

Impressions on Svelte from a non pro

Johannes Zillmann — Thu, 03 Oct 2019 17:14:29 +0000

Impressions on Svelte (non pro)

I guess i’m vulnerable to the new shiny thing syndrome. I wasn’t looking for any kind of web framework (as usual), as i was clicking Svelte is the most beautiful web framework I’ve ever seen (as usual).

Background

Building the backends, frontend development seemed pretty chaotic to me for a long time. React paved the way. First time i felt comfortable structuring JavaScript.

With many available component libraries, it was easy enough to get my first web apps (https://pdf2md.morethan.io, https://jmh.morethan.io) up and running even though my knowledge of JavaScript, HTML and CSS was lacking.

Fast forward to Svelte

Documentation of Svelte is pretty good. It has a neat tutorial, a simple but helpful API documentation and a examples section (which is more or less an replication of the tutorial).

Getting started is really simple. Bootstrap a running hello world app up with these 3 commands:

npx degit sveltejs/template
npm install
npm run dev

To get into Svelte, I decided to build a simple numerology calculator for names (Nanuca). I found it pretty straight forward to get up to speed, and looking back at the API documentation after the first evening, i was amazed that there isn’t so much stuff to learn anyway.

Impressions and thoughts

Easy to start, cushy learning curve.
Less concepts to master, less boilerplate then React.
It forced me to learn more CSS and JS basics (which was a good thing to me at this point in time)
— React has an amazing ecosystem. Lots of predefined components available. You don’t have to master HTML/CSS to build something great.
— Every once in a while however i run into a simple problem which took annoyingly long to solve without that basic knowledge.
Even something fairly complex like animations and transitions are pretty simple to master.
There is a out-of-the-box store implementation which takes some time to get used to, but probably less then the Redux and co thing.
With so many amazing component-based frameworks out there, it seems beneficial to build JavaScript libraries which are not tight to one framework in particular.

Simply said… i’m just enjoying working in Svelte. It’s simple, it’s powerful, it never stepped in my way so far! So this time, i’m pretty happy i fell pray to Svelte is the most beautiful web framework I’ve ever seen.

There is probably a lot of more to say about what Svelte is and how it works… but i leave that to the masters of JavaScript. This small writeup might be a good starting point for going into the theoretical background.

Find the code of the example project here: [https://nanuca.morethan.io]

Benchmarking Infrastructure for the JVM

Johannes Zillmann — Sat, 03 Feb 2018 08:15:15 +0000

When performance is measured, performance improves. When performance is measured and reported, the rate of improvement accelerates. — Thomas Monson

There is a tool called JMH which is one of the JVM’s best friend when it comes to performance tracking and analysis. In this post, i…

Describe the pieces of infrastructure i developed around JMH and how you can use those for your own endeavors…
Tell the long story of the Why... ;)

How and Why — Chapter I

A few years ago - working at Datameer, a big data platform - some customers were concerned about performance. “Why is this and that job taking only five hours in Hive but eight in Datameer ?” Kind of that in different shades. So a small team set out to investigate & solve the complaints before they could turn into a problem. First thing they did, was to craft a benchmark suite which run data processing jobs on Hadoop with Hive and with Datameer. With that, they were able to compare both products, figure out how to improve Datameer and we could finally cope with the customer’s expectation in terms of performance.

A few month later, i was asking “Hey where is our performance suite running? And where can i see the report ?”. The response was like “Well, you’ve to prepare an environment, then trigger the benchmarks manually and then you can find the performance number printed to the logs!”.

“Phew, if that suite doesn’t run regularly and if it doesn’t alarm or cheer anyone with some fancy graphs… that thing will rotten soon…”. Maybe i was just thinking, maybe i articulated my concern in more polite terms. Anyhow…

I can’t prove that proper reporting and automation would have saved the life of this piece of infrastructure, but eventually it lay dead for a while and got removed from the codebase years after.

How and Why — Chapter II

Two years back - still working at Datameer - we started to develop a new major feature. The feature’s main feature was about performance. It didn’t really brought new functionality to the table, but through it’s mere speed, it should enable new use cases.

This time i was more involved and, building on the former experience, i had these thoughts:

If performance is that much crucial, we have to measure the de-facto state of each feature and track losses and gains with each step of development.
I want good reporting & proper automation!!

Pretty obvious... There should be proper software out there i thought…

It didn’t took me long until i figured that JMH is kind of the de-facto tool used by most (and more & more) people, to realize micro benchmarks on the JVM. While JMH’s strength lies surely in micro benchmarking, i found it for good use in “integration benchmarking” as well. The pluggable profilers it can run are pretty cool too. They help to find explanations for the seen performance, such as object allocation, JIT work, etc...

But in terms of presenting the benchmark results… most of the tooling around JMH lacked what i was wishing for. Gradle plugins were there, but only for mere execution. The existing Jenkins plugins were of great help, but missed depth. A online visualizer did exist… but it was pretty good in hiding and i didn’t find it at that time. And the printout / the result file JMH does at the end of a execution… well its pretty good if you work on a small set of benchmarks, but once you grow your suite… good luck keeping your vision!

Thats why i set out and developed my own set of tools…

JMH Visualizer — Online Visualizer

Starting with a gradle plugin generating html and javascript based on the benchmark results, i soon figured out that this won’t scale and developing a regular webapp with standard tools will bring me much farther much sooner.

So here it is, a mostly javascript app, the JMH visualizer: http://jmh.morethan.io.

Code is at https://github.com/jzillmann/jmh-visualizer. Assuming you know how to execute JMH benchmarks, you can instruct JMH to output JSON instead of CSV (e.g. java -jar benchmarks.jar -rf json). Simply upload the produced JSON at the JMH Visualizer page and you will get a graphical representation of the json like this:

one benchmark run

Execute the benchmarks a second time and upload both of the JSON files and you will get a compare view:

two benchmark runs

Upload three or more JSON files and you get a line chart:

three or more benchmark runs

Here a few additional points to the online visualizer:

It’s online, but your data stays offline (once the hmtl and javascript is loaded, you can safely disconnect from the internet and start using the visualizer)
You usually write your benchmarks in a class. JMH Visualizer does bundle the benchmarks from one class into one chart usually.
It tries to make use of most of the provided data, so additionally to the score it visualizes, it give insights into the score-error, iteration result s and secondary metrics like ·gc.alloc.rate.norm.

Loading your reports from Gists or external URL’s

If you have posted your benchmark results (in JSON form) anywhere in the web, you can now reference them (instead of uploading). JMH Visualizer understands those 4 paramters: source, sources, gist, gists:

This is especially helpful if you want to share your results with others, e.g. in an issue tracker!

Gradle JMH Report

Once the online visualizer was build, it was straightforward to put it inside a Gradle plugin which then could produce a local report for executed benchmarks. You find it here: https://plugins.gradle.org/plugin/io.morethan.jmhreport with a getting-started guide included in https://github.com/jzillmann/gradle-jmh-report.

Note: This plugin only generates a visual report based on a benchmark result. It does NOT execute your benchmark suite for you (I’ve written about how to setup execution in JMH with Gradle — From Easy to Simple).

Jenkins Plugin

Finally… automation… Hooked up the online visualizer in a Jenkins plugin as well: https://plugins.jenkins.io/jmh-report

This allows to run your benchmarks suite regularily and figure out regressions or improvements easily (even in a big suite).

Above and Beyond

JMH is quite a beast. Writing meaningful benchmarks isn’t as easy as writing good unit tests (and even that is challenging at times). Understanding the inner mechanics of the JVM is often necessary to understand some of the “awkwardnesses” of JMH and to avoid the common pitfalls which are inherent when it comes to micro benchmarking.

I found that visualizing the data JMH produces helped me a great deal to understand JMH and to write acceptable benchmarks. I would love to build on that. It’s probably easy to analyze the benchmarks and yield warnings or tips to the user (like “This benchmark has a high variation, try…”) and by thus helping other JMH starters... However, due lack of free time, respectively due abundance of idea’s creating software for a better world… i’m not sure how much i’m going to drive this stack forward… So participation is appreciated, contact me through https://github.com/jzillmann/jmh-visualizer/issues !!

Also, you might be interested in a list of other JMH tools i put together.

JMH with Gradle — From Easy to Simple

Johannes Zillmann — Thu, 20 Oct 2016 22:22:54 +0000

JMH is a Java harness for building, running, and analyzing nano/micro/milli/macro benchmarks written in Java and other languages targeting the JVM.

Gradle is my current build tool of choice.

This post tells how to setup JMH in gradle.

Starting with the simple approach. Just include and use this plugin: https://github.com/melix/jmh-gradle-plugin.

I used it quite a while and it worked out of the box for smaller projects. On medium sized ones i run into some problems, but could resolve them by making use of its configurations (like zip64 = true ). For a larger project with a complex dependency setup however, i run into some additional classpath problems.

So i took a step back, looked what the project was doing, also cast a glance at http://gvsmirnov.ru/blog/tech/2014/03/10/keeping-your-benchmarks-separate.html and figured… it’s not as complex… and can be even less complex… E.g. i don’t see why i need that shadow jar stuff!

Step by Step

Common practice is to have the JMH benchmarks separated, like instead of putting them e.g. in src/test/java , put them into src/jmh/java. Do that in gradle by adding another source-set:

sourceSets { 
  jmh 
}

In case your benchmarks using classes from your tests, do it like that:

sourceSets { 
    jmh { 
        compileClasspath += sourceSets.test.runtimeClasspath 
        runtimeClasspath += sourceSets.test.runtimeClasspath 
        } 
}

Next you wanna setup the dependencies for that new source-set called jmh. So everything your benchmarks depend on, which is usually the project itself (with all its dependencies) and the JMH jars:

dependencies { 
    jmhCompile project 
    jmhCompile 'org.openjdk.jmh:jmh-core:1.18' 
    jmhAnnotationProcessor 'org.openjdk.jmh:jmh-generator-annprocess:1.18' 
}

Note: jmhCompile is bound to the jmh source-set definition. You can choose the source-set name freely. If you call it e.g. benchmark , use benchmarkCompile in the dependencies section!

Anyone still using Eclipse ? This piece helps to set it up correctly:

eclipse { 
    classpath { 
        plusConfigurations.add(configurations.jmhCompile) 
        defaultOutputDir = file('build/classes-jmh-ide') 
    } 
}

The final piece is about the execution of the benchmark. In its simplest version it looks like that:

task jmh(type: JavaExec, description: 'Executing JMH benchmarks') { 
    classpath = sourceSets.jmh.runtimeClasspath 
    main = 'org.openjdk.jmh.Main' 
}

But almost certainly you wanna enhance that version, making some of JMH’s parameter, parameter of the Gradle task. E.g. the regex to select the Benchmarks + writing the result to a JSON file:

task jmh(type: JavaExec, description: 'Executing JMH benchmarks') { 
    classpath = sourceSets.jmh.runtimeClasspath 
    main = 'org.openjdk.jmh.Main' 

    def include = project.properties.get('include', ''); 
    def format = project.properties.get('format', 'json'); 
    def resultFile = file("build/reports/jmh/result.${format}") 
    resultFile.parentFile.mkdirs() 

    args include 
    args '-rf', format 
    args '-rff', resultFile 
}

Voila, now you can run your benchmarks with:

gw jmh2 -Pinclude=“.\*MyBenchmark.\*”

Note: There are probably still more parameters you wanna pass through… see the below complete version for some more i found useful.

Complete version

Putting everything together and adding some sugar and spice (jmhHelp task, more parameters, etc..) leaves us with that:

Closing Story

Few month back i discovered another Gradle plugin — think it was about annotation processing — and told my dear friend and colleague Mascha about it. I was enthusiastic, he was like ’yeah, i would check what the plugin is doing really, i’m preferring to do simple things on my own lately’.

I virtually raised my eyebrows in a way he couldn’t see it (i like re-using things), but didn’t confront.

Now weeks later, i figured he is right! This time… ;)

Final Words

I hope you enjoyed the post! Let me know if you think it’s worth making this a plugin… ;)

Actually, there seems to be a plugin doing the JMH integration in a similar way: https://github.com/blackboard/jmh-gradle-plugin. Checked it out, i haven’t!

DEV Community: Johannes Zillmann

CSS main page layout with resizing and scroll overflow sections

Initial Problem

Flexbox approach

CSS Grid approach

Conclusions

Fullstack with Svelte & tRPC

The project

Why not Svelte-Kit

Final Words

Chasing a hundred rabits at a time — A dev week

Chasing a hundred rabits at a time — A dev week

Context

The Task

The Slow Start

Things going downhill — the web-service and data generation battle

If that would have been all

Could i’ve done better ?

Final Words

JS/TS Managing alternative implementations with RollupJS

Basic Structure

Most Naive Approach

Moving to a more satisfactory approach

And now in Typescript…

Final Words

Getting started with Electron and Svelte

Setting up Node & Svelte

Setting up Electron

Live Reload for Electron

Bundling a distribution (OS X)

Setting up app icons (OS X)

Final Words

Impressions on Svelte from a non pro

Impressions on Svelte (non pro)

Background

Fast forward to Svelte

Impressions and thoughts

More

Benchmarking Infrastructure for the JVM

How and Why — Chapter I

How and Why — Chapter II

JMH Visualizer — Online Visualizer

Loading your reports from Gists or external URL’s

Gradle JMH Report

Jenkins Plugin

Above and Beyond

JMH with Gradle — From Easy to Simple

Step by Step

Complete version

Closing Story

Final Words