Creating and persisting business objects using Spring Boot is amazingly easy. Assume you create an API for simple CRUD methods and want to create an entity based on data entered by your frontend users. In the old times, you would probably populate several POST fields in a key-value style and create your business object manually from those fields.
Spring Boot offers an easier solution. As long as your internal data model equals the frontend’s data model, you can use the @Valid On @RequestBody Controller Method Arguments to automatically create the object from a JSON-serialized request and execute the necessary validation logic.
Imagine you work on an application on a development server for several months until it is time to deploy it to a production system for the first time. Chances are, there are several necessary configuration tasks just waiting to be forgotten: firewall permissions, specific software libraries, file permissions and so on.
Ansible offers a reproducible and automatable way to take care of these configurational changes for you – and the beauty is: it does not depend on a specific Linux flavour and it works both for single-machine deployments and distributed systems.
If you were never wondering why your application exits with an HTTP error until you have noticed that the cache folder did not have the correct permissions, stop reading; if you have never forgotten which libraries you had to apt-get install before the Makefile finally completed without errors, this is not the guide for you. Otherwise, see how a simple 50 line yml file can take care of your deployment challenges.
Performance testing a REST API reveals its runtime behaviour under stress and can be an early indicator of QoS violations in production. Apache JMeter offers a GUI mode where such load tests can be created and their results be analyzed easily.
Installing JMeter is very simple once you have Java installed on your machine (there are numerous tutorials to install Java, so I won’t go into detail here).
Once you can run the following command, you can continue with JMeter:
java -version
Download JMeter from this link (select the ZIP archive) and unpack it. In the extracted folder, go to bin/ and execute jmeter.sh (on Linux) or jmeter.bat (on Windows). You should be greeted by the following GUI:
Create a Simple Load Test
We’ll add a Thread Group which represents a group of artificial users interacting with your API. In the left panel, right click on “Test Plan” and select “Add -> Threads (Users) -> Thread Group”:
Enter the following parameters on the right panel under “Thread Properties”:
The number of threads determines how many simulated users should connect to your REST API simultaneously. The ramp-up period defines how long JMeter waits before the next request is started.
For example, if we have 64 users and a ramp-up period of 100 seconds, JMeter would add a delay of 100 / 64 seconds between each user’s first request.
Define the Invoked Action
You now have to instruct JMeter on which action should be performed by the simulated users. First, we define the base URL. Right click on the Thread Group and select “Add -> Config Element -> HTTP Request Defaults”.
For my Rust application, I use the following settings:
The default protocol is HTTP and I use localhost:8000 since this is the default port for a Rocket web application.
Next, define which specific endpoint should be used by adding an HTTP Request via “Add -> Sampler -> HTTP Request”:
And enter the following settings:
Notice that protocol and server name / port are left blank because they were set by the HTTP defaults earlier.
In my example, I’m using a GET request on the endpoint /<count> which controls how many FizzBuzz iterations are computed. By changing this number, the computational load per request can be modified. For example, /5000 means that FizzBuzz is computed for the numbers 1 to 5000.
Generating a Response Time Graph
Since we want to monitor how our API performs, the response time graph is an illustrative way of showing the average response time per request. Add it by right clicking the Thread Group and selecting “Add -> Listener -> Response Time Graph”.
The resulting graph will display how long on average it takes for an API call to produce a result.
Run the Test
Although the GUI is not a reliable way to execute tests and the command-line interface should be used instead, you can quickly verify that your test is working correctly by selecting the play button ().
Before starting the test, make sure your API is running and accepting HTTP requests. For Rust and Rocket, you can either run the application with cargo run or compile it and run the resulting binary with cargo build --release and ./target/release/fizzbuzz.exe.
After pressing the play button to start your test, you can track how many connections have been opened on the upper right corner of the interface (14 of 64 users in this example):
While the test is running, the Rust console window is showing a large number of incoming connections when using cargo run:
Interpreting the Response Time Graph
During and after the test, you can have a look at the response time graph by selecting “Response Time Graph” in the panel on the left and “Display graph” in the panel on the right.
In this example, you can easily see that the average response time for 64 parallel users is about 1.3 seconds on my absolutely non-competitive hardware (after the ramp-up period where increasingly more users are added).
Keep in mind that there are many factors contributing to the fact that this number won’t match your real response time in production, including:
the fact that both JMeter and the API run on the same hardware and have almost no network latency
the execution of JMeter itself consumes a certain part of the hardware resources
in a production environment, a web server such as nginx would be used in front of the API
performance optimizations such as caching would be applied
However, a quick measurement such as this can be more than enough when you just want to verify that you can support a given order of magnitude of parallel requests in production.
Learn How to Create a FizzBuzz Implementation in Rust
FizzBuzz is a classical software developer interview question with the simple goal of writing an application that outputs “Fizz” for numbers divisible by 3, “Buzz” for numbers divisible by 5 and “FizzBuzz” for numbers matching both cases.
In this article, I will show you how to implement FizzBuzz using the Rust programming language and the Rocket framework.
Start by using Rust nightly and setting up a new Rust project using cargo:
rustup default nightly
cargo new fizzbuzz --bin
cd fizzbuzz
rustup update && cargo update
Edit Caro.toml and add the following dependency for Rocket:
Imagine someone watching all your daily activities from hundreds of meters in the distance. While walls can protect you from spy glasses and interested neighbours looking out of their windows, they are no obstacle for electromagnetic radiation. WiFi networks in particular often build the backbone of our homes’ communication infrastructure: when you come home, your phone connects to your WiFi; when you turn on your video gaming console, it connects to your WiFi; when you leave, the WiFi connection to your phone is removed.
There are ways to measure such WiFi activities which require nothing but some cheap pieces of hardware, the right software tools and a little bit of network knowledge. In this post series, I want to investigate this topic, present state of the art tools and ways to set them up and give advice on what can be done to protect against the described invasions of your privacy.
Part 1 explains how to install Kismet – the swiss army knife for network monitoring.
Easily share your code with the PHP community by contributing your library as a composer package: This article will show you how to publish your code on GitLab and as a package on packagist.org.
Writing Your PHP Code
Publishing open source code has never been easier. Using PHP’s package manager composer, thousands of freely available packages are only one composer require away.
Believe it or not, but there exists an npm package named “is-odd” with over 700,000 weekly downloads. Its sole purpose is to “compute” whether a number is even or odd. For this tutorial, we will replicate this essential functionality as a PHP package.
Recently, I needed to extract all email addresses from a document for further processing. While I ended up writing my own regular expression, in the beginning I wanted to search for a public web service for this task. Appearantly, there exist lots of such services. However, I could not find one that works without transmitting the entered plain text to some shady server where I have no control over the sent data. This is unacceptable since email addresses are almost always sensible data points.
Out of frustration, I decided to set up such a service myself. I used this opportunity to get my feet wet with Vue.js and GitLab Pages (as described in a previous blog post).
In case you wonder about the absence of buttons: Vue.js is able to process the entered input directly and immediately outputs the results as you type – which quite frankly is absolutely amazing. I did in fact test the performance of this feature with a few thousand paragraphs of “Lorem Ipsum” and correct results were generated in a few seconds.
As you can verify using Firefox’s network monitoring tool, the entered data is not sent to any web service; instead, Vue.js processes it as you type and extracts all strings that match my regular expression (please report if I missed some edge cases. Initially, I forgot about the + character that is used for example by Gmail).
Naturally, I also set up a Letsencrypt SSL certificate which also worked flawlessly using GitLab Pages.
Setting up this service was a fun way for getting to know Vue.js and I’m already looking forward to creating more similar ones in the future.
This article describes how to setup a continuous integration pipeline in GitLab for your Vue.js app. Learn how to automate your deployment to GitLab pages in a few easy steps.
GitLab pages is a great way to host simple web applications and is easy to integrate into GitLab’s continous integration (CI) pipeline.
In this article, I’ll show how to set up a simple development environment for working with Spring Boot inside a VirtualBox Ubuntu Server. You will learn how to
configure port forwarding for interacting with the development server
set up shared folders for using an IDE on your client to edit code on the server
build and execute the application using maven
Let’s get started!
Prerequisites
You need:
VirtualBox installed on your host (i.e., your desktop or laptop)
A virtual machine with your favorite Linux server already installed (for this article, I will use Ubuntu Server 18.04 from https://www.osboxes.org/ubuntu-server/)
Your favorite IDE (e.g., IntelliJ or Eclipse) or text editor (e.g., Atom or VSCode) already installed
While there are many great tutorials to integrate Java and Python applications into Kafka, PHP is often left out. However, by offering scalability, high performance and high availability, Kafka is a very promising data infrastructure for combining legacy applications (such as PHP monoliths) with modern microservices.
This article shows you how to setup a Kafka-PHP development environment from scratch using Docker and how to send your first message from a PHP application to a Kafka topic.
Architecture Overview
For this simple scenario, we will create three Docker containers: one running the zookeeper, one broker and one for the PHP message producer (call that one “PHP Worker”).
When everything is up and running, we want the PHP worker to be able to send messages to a Kafka topic by connecting to the Broker.
).
