PlantUML supports sprites to be used in diagrams.
A sprite is text encoded monochrome graphic we can reference using the syntax <$spriteName>.
The sprite is defined using hexadecimal values.
We can define a set of hexadecimal values to create our sprite, but we can also generate the correct values from for example a PNG image.
We start with a simple example where we create a small triangle using hexadecimal values:
We have a lot of ways to customize our PlantUML diagrams. We can change the colors and we can even set gradients as color. A gradient has two colors and a direction. The direction of the gradient is set by the separator between the two colors. We can use the following separators to set the gradient direction:
/: direction top left to bottom right
\: direction bottom left to top right
|: direction left to right
-: direction top to bottom
An SQL injection attack consists of insertion or "injection" of a malicious data via the SQL query input from the client to the application. In our example project we have a small Spring Boot based blog application. This application exposes an endpoint to fetch blog articles based on the author:
When we call the endpoint, we will receive:
PlantUML has some features that come from the underlying software to create diagrams.
Graphviz is used by PlantUML and we can use Graphviz features in our PlantUML diagrams.
For example we can align multi-line text of labels to be either center (default), left or right aligned using a Graphviz feature.
When we want to text to be center aligned we simply use the new-line character \n.
If we want to have our text left aligned we use \l instead of \n.
And to right align the text we use \r.
In the following example we have three labels that are center, left and right aligned:
From time to time you only want to run one test, one test method, one class or one package from the command-line. Or on the contrary: you want to exclude / ignore one specific test or group of tests during the build cycle. Excluding tests from the build cycle by the command line usually occurs when the following scenarios meet:
A test requires significant amount of resources (time, memory, disk space, etc.)
The run needs to be independent from the IDE (to reenact the Continuous Integration / Continuous Delivery pipeline) as some IDEs load test-dependencies on the compile-time class-path.
You have no or limited ability to change the code-base
This year marks the 10th anniversary of the Fronteers conference , held at Pathé Tuschinski in Amsterdam. A single track conference covering various topics of frontend development. The JDriven delegation this year consists of Patrick Ooteman, Auke Speksnijder and Martijn van der Wijst. Topics are: VR, Animations, Developer tools, Caching, a11y, and WebAssembly. The talks didn’t just cover javascript, CSS and HTML. Also relating subjects like writing better language, tackling imposter syndrome and Japanese culture came by. There even was a separate talk focused on emojis :) We’ll try to summarize the nicest takeaways from the past couple of days.
To start off, Niels Leenheer gives a talk about the importance of when to use and also when not to use progressive enhancement. You can imagine that a video tag can be replaced by an image for devices that don’t support the native video tag. But Youtube without videos, yeah, that won’t work at all. After the audience loudly applaudes to an image of ‘goodbye Internet Explorer’, he emphasises that browser wars are a good thing. When every browser would run on Webkit (or nowadays even Chromium), the need to make browsers better would decrease. Also he said:
IE6 was a good browser
Daring statement! But then when you think about it, at the time it could do awesome things. IE6 became a pain in the ass for developers only later, when modern browsers came around and people were still using IE6. Key takeaway of the talk: think about users, not about browsers.
From time to time you only want to run one test, one test method, one class or one package from the command-line. Or on the contrary: you want to exclude / ignore one specific test or group of tests during the build cycle. Excluding tests from the build cycle by the command line usually occurs when the following scenarios meet:
A test requires significant amount of resources (time, memory, disk space, etc.)
The run needs to be independent from the IDE (reenact the Continuous Integration / Continuous Delivery pipeline) as some IDEs load test-dependencies on the compile-time class-path.
You have no or limited ability to change the code-base
As a developer sooner or later you will encounter bugs, be it small ones or production breaking bugs. Now it is your task to find and fix the bug as soon as possible. In this article I will list the techniques I learned over the course of many years debugging web applications in the hope that it will help you be better and more efficient in bug hunting.
The process start with the actual bug report in a bug tracker. When reading the report, be careful for incomplete information or assumptions made by the reporter. It is easy to forget crucial steps in writing down the bug, so if possible, try to reproduce the bug with the reporter. Sometimes the bug report might contain possible causes to the bug. This happens more often if the reporter has a technical background. Be careful about trusting these assumptions made in the bug report since they are not always based on actual knowledge of the system, and it might create tunnel vision in finding the root cause.
Writing a parameterized specification in Spock is easy.
We need to add the where: block and use data providers to specify different values.
For each set of values from the data providers our specifications is run, so we can test for example very effectively multiple input arguments for a method and the expected outcome.
A data provider can be anything that implements the Iterable interface.
Spock also adds support for a data table.
In the data table we define columns for each variable and in the rows values for each variable.
Since Spock 1.1 we can reuse the value of the variables inside the data provider or data table.
The value of the variable can only be reused in variables that are defined after the variable we want to reuse is defined.
In the following example we have two feature methods, one uses a data provider and one a data table.
The variable sentence is defined after the variable search, so we can use the search variable value in the definition of the sentence variable.
We all know writing tests or specifications with Spock is fun.
We can run our specifications and when one of our assertions in a feature method invalid, the feature method is marked as failed.
If we have more than one assertion in our feature method, only the first assertion that fails is returned as an error.
Any other assertion after a failing assertion are not checked.
To let Spock execute all assertions and return all failing assertions at once we must use the verifyAll method.
We pass a closure with all our assertions to the method.
All assertions will be checked when use the verifyAll and if one or more of the assertions is invalid the feature method will fail.
In the following example specification we have 3 assertions in the feature method check all properties are valid.
We don’t use the verifyAll method in our first example.
When I started using TypeScript for my Angular applications, I was confused about all the different ways with which you could import other modules.
import './polyfills.ts'; import { Component } from '@angular/core'; import HomeComponent from './pages/home/home-page.component'; import * as _ from 'lodash'; import assert = require('assert');
At first, I thought that as a programmer you could choose whether you wanted to use curly braces or not, but I quickly found out that that was not the case.
It all depends on how the module that you are importing is structured.
I have created an overview of the different ways by which a module can be exported, together with their corresponding import syntax.
Most of them are actually plain ECMAScript 2015 (ES6) module syntax that TypeScript uses as well.
The examples are from my solution to the first puzzle of Advent of Code 2016 and can be found on GitHub if you want to play around with imports and exports yourself.
When a module needs to export multiple variables, it can use so-called named exports:
Another way that named exports can be done is by specifying what you want to export at the end of the module:
You can import these modules in two ways. Either you import everything as one object (sometimes called namespace):
Or, you specify all the individual variables that you want to import:
If you specify the variables, you can also import them under a different name:
Writing unit tests for our handlers in Ratpack is easy with RequestFixture.
We invoke the handle method and use a Handler or Chain we want to test as argument.
We can provide extra details on the fixture instance with a second argument, for example adding objects to the registry or setting the request method.
The handle method returns a HandlingResult object.
This object has the method exception that we can use to see if an exception occurred in our code under test.
The method throws a HandlerExceptionNotThrownException if the expected exception doesn’t occur.
In the following example we have two feature methods to check if an exception occurred or not:
