Vladimir Batoćanin

PyOpenGL is a standardized bridge between OpenGL and Python. PyGame is a standardized library for making games with Python. In this article, we'll leverage the two and cover some important topics in OpenGL with Python.

Advanced OpenGL in Python with PyGame and PyOpenGL

<h2 id="introduction">Introduction</h2>
Scheduling tasks to be performed at a later date, or repeated in a fixed interval, is a very useful feature. For example, newsletter systems or tasks which process information at a set time-frame rely on being scheduled to run at certain time points.
Since Spring Boot offers several options, we're going to cover and implement all of them.
<h2 id="projectsetup">Project Setup</h2>
As usual, when it comes to building Spring Boot applications, making a skeleton project is easiest with the help of <a rel="nofollow noopener" target="_blank" href="https://start.spring.io/">Spring Initializr</a>. You don't need any additional dependencies to enable scheduling.
To enable scheduling, all we have to do is annotate our main class:
<pre><code class="hljs">@SpringBootApplication
@EnableScheduling
public class SampleScheduleApplication {
 public static void main(String[] args) {
 SpringApplication.run(SampleScheduleApplication.class, args);
 }
}
</code></pre>
The <code>@EnableScheduling</code> annotation allows the Spring container to notice any <code>@Scheduled</code> annotations in Spring-managed beans.
<h3 id="conditionalscheduling">Conditional Scheduling</h3>
There's another way to enable scheduling - by using the <code>@ConditionalOnProperty</code> annotation. It allows us to &quot;switch on&quot; and &quot;switch off&quot; our configuration classes by setting a property in the <code>application.properties</code> class.
To do this, let's make a new class and annotate it with both the <code>@EnableScheduling</code>, <code>@Configuration</code> and <code>@ConditionalOnProperty</code> annotations:
<pre><code class="hljs">@EnableScheduling
@Configuration
@ConditionalOnProperty(name = &quot;spring.enable.scheduling&quot;)
public class ScheduleEnabling {}
</code></pre>
Now, in the <code>application.properties</code> file, let's add our new property and set it to <code>true</code>:
<pre><code class="hljs">spring.enable.scheduling = true
</code></pre>
Just by shifting this variable, we can turn the functionality on and off.
To execute a method on a schedule, you need to annotate it with the <code>@Scheduled</code> annotation. Changing the parameters of the annotation will define if it's at a fixed rate, with a fixed delay, custom intervals, etc.
<h4 id="schedulingwithfixedrateandfixedratestring">Scheduling with fixedRate and fixedRateString</h4>
To schedule a method to execute on a fixed rate, we'll add the adequate parameter to our annotation - <code>@Scheduled(fixedRate)</code>. This parameter accepts integers, expressed in milliseconds. So if you want a rate of 1 second, the rate should be entered as <code>1000</code> since the value is milliseconds.
Alternatively, you can use the <code>@Scheduled(fixedRateString)</code> parameter to externalize the amount by using an environment string variable.
To avoid confusion, we'll go with the <code>fixedRateString</code>, which is essentially a string parameter that specifies the rate, instead of the integer value. It can get a bit tricky trying to make a method recur monthly in milliseconds.
Let's set a variable in the <code>application.properties</code> file:
<pre><code class="hljs">sample.schedule.string = PT2S
</code></pre>
The prefix <code>PT</code> is the ISO-8601 standard for <a rel="nofollow noopener" target="_blank" href="https://en.wikipedia.org/wiki/ISO_8601#Durations">notating durations or periods</a>, and with this, we can call the <code>sample.schedule.string</code> to schedule a method call in 2 seconds.
This also allows us to specify different delays for different profiles in use:
<pre><code class="hljs">@Scheduled(fixedRateString = &quot;${sample.schedule.string}&quot;)
public void scheduleTaskWithFixedRate() throws InterruptedException {
 task1();
 task2();
}

public void task1() throws InterruptedException {
 logger.info(&quot;Task 1 starts&quot; + Thread.currentThread());
 Thread.sleep(1000);
 logger.info(&quot;Task 1 ends&quot; + Thread.currentThread());
}

public void task2() throws InterruptedException {
 logger.info(&quot;Task 2 starts&quot; + Thread.currentThread());
 Thread.sleep(1000);
 logger.info(&quot;Task 2 ends&quot; + Thread.currentThread());
}
</code></pre>
Let's run this piece of code:
<img src="https://stackabuse.s3.amazonaws.com/media/scheduling-spring-boot-tasks-1.PNG" alt="Scheduling with Fixed Rate">
However, we can see a problem here:
<blockquote>
Task 1 starts at 00:01:44 and ends at 00:01:45, as expected. 
Task 2 starts at 00:01:45 and ends at 00:01:46, as expected. 
Task 1 starts at 00:01:46 and ends at 00:01:47.
</blockquote>
Since both <code>task1()</code> and <code>task2()</code> have been executed, you'd expect the method to wait for an additional 2 seconds to run again.
Fixed rate tasks don't wait for the completion of the previous execution, it simply invokes the method at a specific rate. Since it takes 2 seconds to finish methods <code>task1()</code> and <code>task2()</code>, the method is invoked again at the same time these two finish.
This can become a problem in an environment with multiple scheduled tasks in place.
Consider this - <code>task1()</code> takes 1 minute to complete, and <code>task2()</code> takes 5 seconds to complete. Since both of them are running on a single thread, there might be a situation that <code>task1()</code> starts processing and will lock the thread. This won't allow <code>task2()</code> to process even if there is a <code>fixedRate</code> of 5 seconds.
In this scenario, we need to increase the number of threads that are available in our thread pool for scheduling. Spring provides a property that we can manipulate to specify the size: <code>spring.task.scheduling.pool.size</code> - the default value is 1.
We may use fixed rate when a particular task needs to be done repeatedly but each task is independent of the other. Also, be careful not to have heavy tasks without a proper rate, since incompletion may lead to a nasty <code>OutOfMemoryError</code>.
<h4 id="schedulingwithfixeddelayandfixeddelaystring">Scheduling with fixedDelay and fixedDelayString</h4>
A <code>fixedDelay</code> works very similar to a <code>fixedRate</code>. But the difference here is that the fixed delay waits until the completion of the previous execution to start the next one. Imagine a scenario where your function takes 1 second to complete execution and you've given a fixed delay of 2 seconds.
This, in turn, will result in a total of 3 seconds.
In the logs below, you can clearly see that the difference between the two subsequent tasks is 3 seconds. This includes the fixed delay time of 1 second as well as the 2 seconds that we've given as sleep:
<pre><code class="hljs">@Scheduled(fixedDelayString = &quot;${sample.schedule.string}&quot;)
public void scheduleTaskWithFixedDelay() throws InterruptedException {
 task1();
}

public void task1() throws InterruptedException {
 logger.info(&quot;Task 1 starts&quot; + Thread.currentThread());
 Thread.sleep(1000);
 logger.info(&quot;Task 1 ends&quot; + Thread.currentThread());
}
</code></pre>
Let's run this piece of code:
<img src="https://stackabuse.s3.amazonaws.com/media/scheduling-spring-boot-tasks-2.PNG" alt="Scheduling with Fixed Delay">
There's an additional parameter that can be added to scheduled tasks, and that is the <code>initialDelay</code>.
This one doesn't require much explanation as it is used in conjunction with the above two. Initial delay, as the name rightfully suggests, provides the initial delay for the first execution.
If you have a function with an initial delay of 2 seconds and a fixed rate of 1 second, then the first execution will be delayed by 2 seconds and the function will run every 1 second afterward:
<pre><code class="hljs">@Scheduled(initialDelay = 1000, fixedRateString = &quot;${sample.schedule.string}&quot;)
public void scheduleTaskWithInitialDelay() throws InterruptedException {
 task1();
}
</code></pre>
We can also opt to use an <code>initialDelayString</code> that allows us to externalize the delay value.
<h3 id="customtimeintervals">Custom Time Intervals</h3>
Fixed rate and fixed delay are the most commonly used parameters for scheduling and the delay strings allow us to externalize the values and make them configurable.
But till now we've seen only very generic examples for the rates. There might be a situation where we need very specific time intervals. Behold, custom <code>cron</code> expressions.
<h4 id="cronexpressions">Cron Expressions</h4>
Most developers have probably heard about the <a rel="nofollow noopener" target="_blank" href="https://en.wikipedia.org/wiki/Cron">cron</a> utility in Linux. It is a daemon process which runs without the need for user intervention and executes tasks.
The syntax for cron expressions in the <code>cron</code> utility and the syntax for cron expressions for scheduling are mostly similar.
Cron expressions are basically strings that describe the details of the schedule. It provides much more control than the previous 2 methods:
<table class="table table-striped" style="white-space:nowrap; font-size:15px;">
 <tr>
 <th>Name</th>
 <th>Required</th>
 <th>Allowed Values</th>
 <th>Allowed Special Characters</th>
 </tr>
 <tr>
 <td>Seconds</td>
 <td>Yes</td>
 <td>0-59</td>
 <td><code>, - * /</code></td>
 </tr>
 <tr>
 <td>Minutes</td>
 <td>Yes</td>
 <td>0-59</td>
 <td><code>, - * /</code></td>
 </tr>
 <tr>
 <td>Hours</td>
 <td>Yes</td>
 <td>0-23</td>
 <td><code>, - * /</code></td>
 </tr>
 <tr>
 <td>Day of Month</td>
 <td>Yes</td>
 <td>1-31</td>
 <td><code>, - * / L W C</code></td>
 </tr>
 <tr>
 <td>Month</td>
 <td>Yes</td>
 <td>0-11 or JAN-DEC</td>
 <td><code>, - * /</code></td>
 </tr>
 <tr>
 <td>Day of Week</td>
 <td>Yes</td>
 <td>1-7 or SUN-SAT</td>
 <td><code>, - * / L C #</code></td>
 </tr>
 <tr>
 <td>Year</td>
 <td>No</td>
 <td>empty or 1970-2099</td>
 <td><code>, - * /</code></td>
 </tr>
</table>
The table above specifies the required values, allowed values, and special characters for a cron expression.
Cron expressions can be very simple, but also very complex. A clear understanding of the values will make it easier to play around with them.
Except for the year field, all the other fields are mandatory:
<pre><code class="hljs">&lt;second&gt; &lt;minute&gt; &lt;hour&gt; &lt;day-of-month&gt; &lt;month&gt; &lt;day-of-week&gt; &lt;year&gt;
</code></pre>
Example: <code>0 0 12 * * ? 2019</code> – This cron expression fires at 12 PM, every day of the month, for every month, for the year 2019.
For some common values, you can also use the predefined annotations:
<ul>
<li><code>@reboot</code>: Schedule the method for every reboot of the application</li>
<li><code>@yearly</code>/<code>@anually</code>: Schedule the method to run once a year</li>
<li><code>@monthly</code>: Schedule the method to run once a month</li>
<li><code>@weekly</code>: Schedule the method to run once a week</li>
<li><code>@daily</code>/<code>@midnight</code>: Schedule the method to run once a day</li>
<li><code>@hourly</code>: Schedule the method to run once every hour</li>
</ul>
Let's write a code example for this:
<pre><code class="hljs">@Scheduled(cron=&quot;0 0 12 * * ? 2019&quot;)
public void doSomething() {
 // Something
}
</code></pre>
An important thing to note when scheduling are time zones - the bane of every developer who works with time.
You'll likely wish to set the <code>zone</code> flag to a specific region. For an example, we'll run this method at 12PM, every day in 2019, based on Paris' time zone:
<pre><code class="hljs">@Scheduled(cron=&quot;0 0 12 * * ? 2019&quot;, zone=&quot;Europe/Paris&quot;)
public void doSomething() {
 // Something
}
</code></pre>
You can find all of the time zones at the <a rel="nofollow noopener" target="_blank" href="https://docs.oracle.com/cd/B13866_04/webconf.904/b10877/timezone.htm">official Oracle docs</a>.
Of course, you can also externalize cron expressions via the <code>application.properties</code> file:
<pre><code class="hljs">cron.expression= 0 0 12 * * ? 2019
</code></pre>
And then invoke it through:
<pre><code class="hljs">@Scheduled(cron=&quot;${cron.expression}&quot;, zone=&quot;Europe/Paris&quot;)
public void doSomething() {
 // Something
}
</code></pre>
You can also use a site like <a rel="nofollow noopener" target="_blank" href="http://freeformatter.com/cron-expression-generator-quartz.html">FreeFormatter</a> to generate a cron expression by setting the input parameters. This is very helpful for those new to creating cron expressions.
<h3 id="conclusion">Conclusion</h3>
In this article, we've seen how we can schedule tasks with Spring Boot. The biggest advantage of using Spring Boot is the ease with which we can implement scheduling. Not only that, it also offers several options so that we can pick what suits our requirements.
Schedulers are essential components of most applications because they send out time-critical as well as user-specific information as and when needed. Now you know how!

Guest Contributor

Scheduling tasks or repeating them in intervals is often a useful feature. In this article, we'll explore the scheduling capabilities of Spring Boot.

Scheduling Spring Boot Tasks

<h2 id="introduction">Introduction</h2>
In this brief article we'll be going over how to extract information from a POST body in Express.js. The HTTP protocol provides a number of ways to pass information from a client to a server, with POST bodies being the most flexible and most commonly used method to send data via HTTP.
Another way, which is typically used for different use-cases, is to convey information using query strings or URL parameters. For more info, check out how to <a target="_blank" href="/get-query-strings-and-parameters-in-express-js/">get query strings and parameters in Express.js</a>.
For this article I assume you have some experience with Node.js and creating simple <a rel="nofollow noopener" target="_blank" href="http://expressjs.com/">Express.js</a> servers.
<h2 id="sendingpostdatainhttp">Sending POST Data in HTTP</h2>
Data can be sent via an HTTP POST call for many reasons, with some of the most common being via an HTML <code>&lt;form&gt;</code> or an API request. The data can take on a few different forms, with the most common being:
<ul>
<li><code>application/x-www-form-urlencoded</code>: Data in this encoding is formatted like a query string you'd see in a URL, with key-value paris being separated by <code>&amp;</code> characters. For example: <code>foo=bar&amp;abc=123&amp;stack=abuse</code>. This is the default encoding.</li>
<li><code>multipart/form-data</code>: This encoding is typically used for sending files. In short, each key-value is sent in the same request, but different &quot;parts&quot;, which are separated by &quot;boundaries&quot; and include more meta-data.</li>
<li><code>text/plain</code>: This data is just sent as unstructured plain text, and typically is not used.</li>
</ul>
A raw HTTP POST request with the <code>application/x-www-form-urlencoded</code> encoding might look something like this:
<pre><code class="hljs">POST /signup HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 53

username=scott&amp;password=secret&amp;website=stackabuse.com
</code></pre>
<h2 id="extractingpostdata">Extracting POST Data</h2>
Before we can get started accessing POST data right away, we need to properly configure our Express app. This configuration needs to be done since not all web app servers need body parsing, and what body parsing is enabled depends on your application.
To set this up, we'll be using the <a rel="nofollow noopener" target="_blank" href="https://www.npmjs.com/package/body-parser">body-parser</a> package, which can handle many forms of data. This package is a <a rel="nofollow noopener" target="_blank" href="http://expressjs.com/en/guide/writing-middleware.html">middleware</a> that intercepts the raw body and parses it in to a form that your application code can easily use.
<pre><code class="hljs">// index.js
const express = require(&#x27;express&#x27;);
const bodyParser = require(&#x27;body-parser&#x27;);

const app = express();
app.use(bodyParser.urlencoded({ extended: true }));

app.post(&#x27;/post-test&#x27;, (req, res) =&gt; {
 console.log(&#x27;Got body:&#x27;, req.body);
 res.sendStatus(200);
});

app.listen(8080, () =&gt; console.log(`Started server at http://localhost:8080!`));
</code></pre>
Notice how we call <code>app.use(...)</code> before defining our route. The order here matters. This will ensure that the <code>body-parser</code> will run before our route, which ensures that our route can then access the parsed HTTP POST body.
To test this, we'll first start the Express app and then use the <code>curl</code> utility in a different console window:
<pre><code class="hljs">$ curl -d &quot;username=scott&amp;password=secret&amp;website=stackabuse.com&quot; -X POST http://localhost:8080/post-test
OK
</code></pre>
<pre><code class="hljs">$ node index.js
Started server at http://localhost:8080!
Got body: { username: &#x27;scott&#x27;,
 password: &#x27;secret&#x27;,
 website: &#x27;stackabuse.com&#x27; }
</code></pre>
Here you can see that the query string data was parsed in to a JavaScript object that we can easily access.
Another important thing to note is our use of the <code>extended</code> option when calling <code>bodyParser.urlencoded</code>. Using the <code>extended</code> option tells <code>body-parser</code> to use the <code>qs</code> library to parse the URL-encoded data. This allows for things like objects and arrays to be encoded into the URL-encoded format.
And while <code>urlencoded</code> is one of the most commonly used parsers that <code>body-parser</code> provides, you can also use the following:
<ul>
<li><code>.json()</code>: Parses JSON-formatted text for bodies with a <code>Content-Type</code> of <code>application/json</code>.</li>
<li><code>.raw()</code>: Parses HTTP body in to a <code>Buffer</code> for specified custom <code>Content-Type</code>s, although the default accepted <code>Content-Type</code> is <code>application/octet-stream</code>.</li>
<li><code>.text()</code>: Parses HTTP bodies with a <code>Content-Type</code> of <code>text/plain</code>, which returns it as a plain string.</li>
</ul>
Each of these parsers also supports automatic inflation of data encoded with <a rel="nofollow noopener" target="_blank" href="https://en.wikipedia.org/wiki/Gzip">gzip</a> or <a rel="nofollow noopener" target="_blank" href="https://en.wikipedia.org/wiki/DEFLATE">deflate</a>, so compression can still be transparently used without any extra work by your application code.
The great thing about the middleware model and how this package parses data is that you're not stuck to using just one parser. You can enable one or more parsers for your app to ensure that all data types are processed properly:
<pre><code class="hljs">// index.js
const express = require(&#x27;express&#x27;);
const bodyParser = require(&#x27;body-parser&#x27;);

const app = express();
app.use(bodyParser.urlencoded({ extended: true }));
app.use(bodyParser.json());
app.use(bodyParser.raw());

// ...
</code></pre>
So now if we were to send an HTTP POST request with JSON as the body, it will be parsed in to a regular JSON object in the <code>req.body</code> property:
<pre><code class="hljs">POST /post-test HTTP/1.1
Host: localhost:8080
Content-Type: application/json
Content-Length: 69

&#x27;{&quot;username&quot;:&quot;scott&quot;,&quot;password&quot;:&quot;secret&quot;,&quot;website&quot;:&quot;stackabuse.com&quot;}&#x27;
</code></pre>
<pre><code class="hljs">$ node index.js
Started server at http://localhost:8080!
Got body: { username: &#x27;scott&#x27;,
 password: &#x27;secret&#x27;,
 website: &#x27;stackabuse.com&#x27; }
</code></pre>
<h2 id="conclusion">Conclusion</h2>
The most common way to send diverse and large amounts of data via HTTP is to use the POST method. Before we can easily access this data on the server side in Express, we need to use some middleware, like the <code>body-parser</code> package, to parse the data in to a format that we can easily access. Once the data from the raw HTTP request is parsed, it can then be accessed via the <code>body</code> property of the <code>req</code> object.
In this article we explained a bit about the various content types/encodings, how to use the <code>body-parser</code> package and its various options, and how to access the parsed data. If you see any issues or have suggestions, feel free to leave a comment below.

Scott Robinson

In this brief article, we'll explore how to extract information from a POST request body in Express.js and Node.js

Get HTTP POST Body in Express.js

<h2 id="overview">Overview</h2>
In this article, we'll look into <a rel="nofollow noopener" target="_blank" href="https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html">Spring Boot Actuator</a>, which provides built-in production ready endpoints that can be used for monitoring and controlling your application.
Monitoring applications may include something as simple as knowing the Health and Info to some complex data like understanding Traffic and Metrics for our application. For example, how much resources (CPU, RAM, etc.) are being used by the application.
You can choose to interact with actuators either with HTTP endpoints or with JMX beans. In this tutorial, we would be using the HTTP endpoints.
In Spring Boot 1, the actuator could only be used with Spring MVC. But with Spring Boot 2 and the introduction of <a rel="nofollow noopener" target="_blank" href="https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html">WebFlux</a>, its support has been extended and can also be used with the <a rel="nofollow noopener" target="_blank" href="https://eclipse-ee4j.github.io/jersey/">Jersey</a> framework without the need of Spring MVC in the classpath.
<h2 id="springbootactuator">Spring Boot Actuator</h2>
In order to demonstrate the actuator in work, we'll be using a simple Spring REST-based service, running on the default port (<code>8080</code>) with a single endpoint of <code>/hello</code> that returns a String message.
To add actuator, we simply add the dependency to our <code>pom.xml</code> file:
<pre><code class="hljs">&lt;dependency&gt;
 &lt;groupId&gt;org.springframework.boot&lt;/groupId&gt;
 &lt;artifactId&gt;spring-boot-starter-actuator&lt;/artifactId&gt;
 &lt;version&gt;${VERSION}&lt;/version&gt;
&lt;/dependency&gt;
</code></pre>
All the endpoints fall under a common prefix of <code>/actuator</code>. To check, let's navigate our browser to <code>http://localhost:8080/actuator</code>:
<img src="https://stackabuse.s3.amazonaws.com/media/spring-boot-actuator-1.png" alt="spring boot actuator default endpoints">
Note: In Spring Boot 1, all of the actuator endpoints were in the root base path, i.e <code>/</code>, but in Spring Boot 2, all of them are by default grouped under <code>/actuator</code>.
You can change the base path of the actuator endpoints by adding the following properties in the <code>application.properties</code>:
<pre><code class="hljs">management.endpoints.web.base-path=/admin
management.server.port=8090
</code></pre>
Now, all the actuator endpoints will be under the <code>/admin</code> prefix, which makes sense since only an admin should have access to metrics such as these. For this tutorial, we are going to leave it under the default <code>/actuator</code>.
By default, management endpoints are available on the same port as that of your application, but you may choose to expose these on a different HTTP port by setting the <code>management.server.port</code> to an HTTP port of your choice.
We will not be changing it as the default behavior is preferable especially if you are running on the cloud.
<h2 id="actuatorendpoints">Actuator Endpoints</h2>
A full list of available endpoints can be seen in the <a rel="nofollow noopener" target="_blank" href="https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html#production-ready-endpoints">official documentation</a>. You may have noticed that although there are many endpoints available, the result of <code>http://localhost:8080/actuator</code> shows only <code>/health</code> and <code>/info</code>.
Since actuator endpoints contain sensitive information, we have had to explicitly expose each of them, otherwise, we'll only be able to see rudimentary information that's already apparent.
Navigate our browser to <code>http://localhost:8080/actuator/health</code>:
<img src="https://stackabuse.s3.amazonaws.com/media/spring-boot-actuator-2.png" alt="spring boot actuator health">
Now, let us check the <code>/info</code> similarly and you will notice that it returns an empty response.
This is because we have not provided any information about it to Spring. This can be done by adding properties to the <code>info</code> prefix in the <code>application.properties</code>:
<pre><code class="hljs">info.name= Test Spring Service
info.more.detail= This is a demo for Spring Actuator
</code></pre>
<img src="https://stackabuse.s3.amazonaws.com/media/spring-boot-actuator-3.png" alt="spring boot actuator info">
You can structure the JSON key according to your needs.
<h3 id="exposingendpoints">Exposing Endpoints</h3>
In order to expose endpoints, Spring provides 2 properties that we can use individually or in combination:
<ul>
<li><code>management.endpoints.web.exposure.exclude</code>: Used to exclude a list of endpoints that we do not want to expose. The default value for it is empty.</li>
<li><code>management.endpoints.web.exposure.include</code>: Used to include a list of endpoints that we want to expose. The default value for it is <code>info, health</code>. This is why both these endpoints were available by default.</li>
</ul>
Note: <code>exclude</code> takes precedence over <code>include</code>
So, let's tweak the configuration so that we want to expose all of the endpoints except for <code>info</code> and <code>health</code>:
<pre><code class="hljs">management.endpoints.web.exposure.include=*
management.endpoints.web.exposure.exclude=info,health
</code></pre>
Note: If you are using a YAML-based properties file, <code>*</code> has a special meaning and can only be used with quotes:
<pre><code class="hljs">management:
 endpoints:
 web:
 exposure:
 exclude: &quot;*&quot;
</code></pre>
For this tutorial, we will be exposing all of our actuator endpoints. So let's add the following endpoint in our <code>application.properties</code>:
<pre><code class="hljs">management.endpoints.web.exposure.include= *
</code></pre>
Now, let's check the actuator endpoint again by opening <code>http://localhost:8080/actuator</code>:
<img src="https://stackabuse.s3.amazonaws.com/media/spring-boot-actuator-4.png" alt="spring boot actuator all">
<h3 id="enablingendpoints">Enabling Endpoints</h3>
Besides exposing endpoints, we can also enable and disable them. While exposing only regulates whether we can see them or not, enabling regulates whether they exist as a bean in the context of Spring.
By default, all the endpoints are enabled except for one, the <code>shutdown</code> endpoint. You can enable/disable each endpoint by setting the <code>management.endpoint.&lt;id&gt;.enabled</code> property:
<pre><code class="hljs">management.endpoint.shutdown.enabled=true
management.endpoint.beans.enabled=false
</code></pre>
You can also disable all endpoints by setting <code>management.endpoints.enabled-by-default</code> to <code>false</code> and then individually enable the properties you want. For this tutorial, we would be going with the default setting.
Note: Disabling the endpoints will remove them as beans from the context completely and it wouldn't matter if you have exposed them.
<h3 id="cachingsupport">Caching Support</h3>
All the endpoints (that are READ operation and do not take any parameter) have basic caching support as well.
Every endpoint has a property of <code>cache.time-to-live</code> that's automatically generated for you which can be used to specify the cache time:
<pre><code class="hljs">management.endpoint.beans.cache.time-to-live=10s
</code></pre>
<h2 id="securingactuatorendpoints">Securing Actuator Endpoints</h2>
By now, it would have been clear that these endpoints store sensitive information about our application and it would be a good idea to secure them.
To do it we can simply add spring security to our application by adding the <code>spring-boot-starter-security</code> dependency in our <code>pom.xml</code>:
<pre><code class="hljs">&lt;dependency&gt;
 &lt;groupId&gt;org.springframework.boot&lt;/groupId&gt;
 &lt;artifactId&gt;spring-boot-starter-security&lt;/artifactId&gt;
 &lt;version&gt;${VERSION}&lt;/version&gt;
&lt;/dependency&gt;
</code></pre>
By default, just by importing it, all of the endpoints in our application will be secured.
But let's suppose we want our <code>/health</code> endpoint available to all, but the rest of them to be secure. This warrants a custom filter for letting certain users pass and holding back others.
For that we have to add a <code>@Configuration</code> class that extends the <code>WebSecurityConfigurerAdapter</code>, like with any other Spring Boot application that we want to secure with Spring Security.
Then we need to override the <code>.configure()</code> method where we define the security configuration for our application:
<pre><code class="hljs">@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

 @Override
 protected void configure(HttpSecurity http) throws Exception {
 http.csrf().disable()
 .authorizeRequests()
 .requestMatchers(EndpointRequest.to(HealthEndpoint.class)).permitAll()
 .requestMatchers(EndpointRequest.toAnyEndpoint()).authenticated()
 .and()
 .httpBasic();
 }
}
</code></pre>
The above code is self-explanatory, where we allowed any <code>HealthEndpoint</code> to be publicly available, while others require some basic authentication. Also, note that <code>EndpointRequest.to()</code> is a convenience method that automatically takes care of the final URL of your actuator endpoints because you might have changed the base-path of it in your application.
Let's restart again and check the logs:
<img src="https://stackabuse.s3.amazonaws.com/media/spring-boot-actuator-5.png" alt="spring boot actuator security">
Because Spring Security is in the classpath, it automatically creates a username of <code>user</code> and a password that is randomly generated at the start of the application, as shown in the logs.
Let's check the <code>/health</code> endpoint and you will see the output without any authentication box. Now let's try any other endpoint, say <code>/env</code> and you will be asked to authenticate:
<img src="https://stackabuse.s3.amazonaws.com/media/spring-boot-actuator-6.png" alt="spring boot actuator security authenticate">
Enter the username and password and you can see the appropriate response:
<img src="https://stackabuse.s3.amazonaws.com/media/spring-boot-actuator-7.png" alt="spring boot actuator security authenticate env">
If you want to define your own username and password, you can easily do so via the <code>application.properties</code>:
<pre><code class="hljs">spring.security.user.name=user
spring.security.user.password=password
</code></pre>
<h2 id="creatingcustomendpoints">Creating Custom Endpoints</h2>
This can be achieved by adding the <code>@Endpoint</code> and <code>@Component</code> annotation to your class. After that, you can create methods and annotate them with <code>@ReadOperation</code>, <code>@WriteOperation</code>, or <code>@DeleteOperation</code> accordingly. You can, of course, have multiple methods with different operations.
The idea of having multiple operations is to map to different HTTP request methods:
<ul>
<li><code>@ReadOperation</code> maps to HTTP GET</li>
<li><code>@WriteOperation</code> maps to HTTP POST</li>
<li><code>@DeleteOperation</code> maps to HTTP DELETE</li>
</ul>
Let's create a simple custom endpoint:
<pre><code class="hljs">@Component
@Endpoint(id = &quot;details&quot;)
public class DetailsEndpoint {

 @ReadOperation
 public String details() {
 return &quot;My App Details&quot;;
 }
}
</code></pre>
Restart the application and navigate to your browser to <code>http://localhost:8080/actuator/details</code>:
<img src="https://stackabuse.s3.amazonaws.com/media/spring-boot-actuator-8.png" alt="spring boot actuator custom">
<h2 id="conclusion">Conclusion</h2>
Monitoring applications may include something as simple as knowing the Health and Info to some complex data like understanding Traffic and Metrics for our application. For example, how much resources (CPU, RAM, etc.) are being used by the application.
Spring Boot Actuator provides build-in production ready endpoints that can be used for monitoring and controlling your application such as <code>/info</code>, <code>/health</code>, <code>/scheduledTasks</code>, etc.
We can also define our own endpoints to meet certain requirements by simple annotating classes with the <code>@Endpoint</code> annotation.
As always, the code for the examples used in this article can be found on <a rel="nofollow noopener" target="_blank" href="https://github.com/StackAbuse/learning-spring/tree/master/actuator">GitHub</a>.

Dhananjay Singh

In this article, we'll look into Spring Boot Actuator, which provides built-in production ready endpoints used for monitoring and controlling your Spring Boot applications.

Monitoring with Spring Boot Actuator

OpenGL is old and there isn't much literature online to learn from. Understanding the core concepts and how they work is important for everything, and especially when it comes to graphics. In this article, we'll start from the bottom and cover the important topics of OpenGL in Python.

Understanding OpenGL through Python

Darinka Zobenica

Design principles are generalized pieces of advice, used as rules of thumb when making design choices. In this article, we'll be covering the most important design principles related to object-oriented design and implement them in Java.

Object Oriented Design Principles in Java

YAML has recently become quite popular in the development industry. In this article, we'll see how you can use YAML files with a Node.js/JavaScript application by reading and writing to them.

Reading and Writing YAML to a File in Node.js/JavaScript

<h2 id="introduction">Introduction</h2>
Streams are a somewhat advanced concept to understand. So in this article, we will go along with some examples for a better understanding and introduce you to a few concepts along the way.
<h2 id="whatisastream">What is a Stream</h2>
In simple terms, streams are used to read from input or write to output sequentially. Most of the time, streams are used to read or write from a continuous source or a comparably big one.
For example, let's assume that you have to read a large file. If the file size is larger than your free memory space, you cannot read the whole file into the memory in order to process it. You have to read it piece by piece and process each chunk, which may be separated by a line for example.
Another example of a continuous source is network communication - like a chat application where data should be continuously flowing from the sender to the receiver.
<h2 id="streamsinnodejs">Streams in Node.js</h2>
The <code>Stream</code> module is a native module that is shipped by default in Node.js. The <code>Stream</code> is an instance of the <a rel="nofollow noopener" target="_blank" href="https://nodejs.org/docs/latest/api/events.html">EventEmitter</a> class, which handles events asynchronously in Node.js. Due to their superclass, streams are inherently event-based.
There are 4 types of streams in Node.js:
<ul>
<li>Writable: Used to write data sequentially</li>
<li>Readable: Used to read data sequentially</li>
<li>Duplex: Used to both read and write data sequentially</li>
<li>Transform: Where data can be modified when writing or reading. Take compression for an example, with a stream like this you can write compressed data and read decompressed data.</li>
</ul>
Let's take a look at a few examples of streams.
<h2 id="writablestreams">Writable Streams</h2>
First of all, let's create a writable stream and write some data into a file:
<pre><code class="hljs">const fs = require(&#x27;fs&#x27;);
const file = fs.createWriteStream(&#x27;file.txt&#x27;);

file.write(&#x27;hello world&#x27;);
file.end(&#x27;, from streams!&#x27;);
</code></pre>
In this code, we have used the file system module to create a writable stream to a file (<code>file.txt</code>) and write 2 separate chunks to it: <code>hello world</code> and <code>, from streams</code>.
Unlike the <code>fs.writeFile()</code> where we need to write the file content at once, using a stream we can write the content chunk by chunk.
To simulate a continuous input, we could do something along the lines of:
<pre><code class="hljs">const fs = require(&#x27;fs&#x27;);
const file = fs.createWriteStream(&#x27;file.txt&#x27;);

for (let i = 0; i &lt; 10000; i++) {
 file.write(&#x27;Hello world &#x27; + i);
}
file.end();
</code></pre>
This will write <code>Hello world + {i}</code> ten thousand times and then end the stream:
<pre><code class="hljs">Hello world 0
Hello world 1
Hello world 2
Hello world 3
Hello world 4
...
</code></pre>
Please remember to <code>.end()</code> your streams after you're done using them, since the <code>finish</code> event is sent after the <code>.end()</code> method has been called.
This signifies that the stream's body has been flushed into our file.
<h2 id="readablestreams">Readable Streams</h2>
Now let's take a look at another simple example by reading a file using a stream. We can read a file chunk by chunk, instead of reading the full content in to memory, using a readable stream:
<pre><code class="hljs">const fs = require(&#x27;fs&#x27;);

const readableStream = fs.createReadStream(&#x27;./article.md&#x27;, {
 highWaterMark: 10
});

readableStream.on(&#x27;readable&#x27;, () =&gt; {
 process.stdout.write(`[${readableStream.read()}]`);
});

readableStream.on(&#x27;end&#x27;, () =&gt; {
 console.log(&#x27;DONE&#x27;);
});
</code></pre>
Similar to creating a writable stream, we've created a readable stream by calling the <code>.createReadStream()</code> method.
While buffering (segmenting the data into chunks), the size of the buffer depends on the <code>highWaterMark</code> parameter, which is passed to the stream constructor.
The default value of this parameter is 16384 bytes (16kb) so if you don't override the parameter, the stream will read 16kb chunks and pass them to you to process.
Since we are using a small text file it makes more sense to use a small value for our example, so the text will be chucked by 10 characters.
In our example above, we simply printed the chunk of data we received, except with brackets around it so that you can easily see the different chunks. The output of our code looks like this:
<pre><code class="hljs">[### Introd][uction

St][reams are ][a somewhat][ advanced ][concept to][ understan][d. So in t][his articl][e, we will][ go along ][with some ][examples f][or a bette][r understa][nding and ][introduce ][you to a f][ew concept][s along th][e way.

##][# What is ][a Stream

][In simple ]...
</code></pre>
<h2 id="duplexstreams">Duplex Streams</h2>
With both writable and readable streams out of the way, we can jump into an example using duplex streams - which essentially combine both.
We'll be demonstrating them using a simple HTTP server built using Node.js' native <code>http</code> module. The example used here is from the official <a rel="nofollow noopener" target="_blank" href="https://nodejs.org/api/stream.html">Node.js documentation</a>.
Since servers receive requests and then send responses, they're a good example for duplex streams, which handle both - a readable stream will act as a continuous request and a writable stream will act as a response.
First, let's import the HTTP module:
<pre><code class="hljs">const http = require(&#x27;http&#x27;);
</code></pre>
Now let's create a simple HTTP server:
<pre><code class="hljs">const server = http.createServer((req, res) =&gt; {
 // `req` is an http.IncomingMessage, which is a Readable Stream.
 // `res` is an http.ServerResponse, which is a Writable Stream.

 let body = &#x27;&#x27;;

 // Get the data as utf8 strings.
 // If an encoding is not set, Buffer objects will be received.
 req.setEncoding(&#x27;utf8&#x27;);

 // Readable streams emit &#x27;data&#x27; events once a listener is added.
 req.on(&#x27;data&#x27;, (chunk) =&gt; {
 body += chunk;
 });

 // The &#x27;end&#x27; event indicates that the entire body has been received.
 req.on(&#x27;end&#x27;, () =&gt; {
 consol.log(body);

 try {
 // Send &#x27;Hello World&#x27; to the user
 res.write(&#x27;Hello World&#x27;);
 res.end();
 } catch (er) {
 res.statusCode = 400;
 return res.end(`error: ${er.message}`);
 }
 });
});
</code></pre>
The <code>req</code> parameter is a readable stream, which we will process upon receiving as an HTTP request. We'll then send <code>res</code> as a response, which is, again, a simple writable stream.
Then, using the <code>.on()</code> method, we read the body of the request in chunks of 64KB and store it into the <code>body</code>, triggered by the <code>data</code> event.
Please note the use of the <code>setEncoding()</code> method before reading from the stream.
This way, the stream will emit strings and it would emit <code>Buffer</code> objects otherwise. Though, you can also perform that conversation inside the <code>data</code> event callback if you prefer.
The <code>end</code> event is triggered when there is nothing left to read in a readable stream. We will talk about other useful events later in this article.
Now, let's listen to the server:
<pre><code class="hljs">server.listen(1337);
</code></pre>
Hitting <code>http://localhost:1337</code>, you should see a simple <code>Hello World</code> response from the HTTP server.
<h2 id="streampipelines">Stream Pipelines</h2>
Using stream pipes we can directly pipe readable streams to a writable stream without storing the buffer temporarily - so we can save memory space.
Consider a scenario where a user requests a large file from the server and there is no memory space to load it to the memory, or the same file is requested by a thousand different clients. In this case, we cannot read the content of the file to memory and then write it back to the client.
This is where the <code>pipe</code> method is useful, as we'll pipe a readable stream (a request) into a writable stream (a response) and serve it to the user without holding it up in the buffer.
First, let's do this without using streams:
<pre><code class="hljs">const fs = require(&#x27;fs&#x27;);
const server = require(&#x27;http&#x27;).createServer();

server.on(&#x27;request&#x27;, (req, res) =&gt; {
 fs.readFile(&#x27;./video.mkv&#x27;, (err, data) =&gt; {
 if (err) throw err;

 res.end(data);
 });
});

server.listen(1337);
</code></pre>
This method is directly reading the file into the memory using the <code>.readFile()</code> method and sends it to the user.
Open your web browser and go to <code>http://localhost:1337</code>, here's what happening behind the scenes:
<img src="https://stackabuse.s3.amazonaws.com/media/introduction-to-nodejs-streams-1.png" alt="web browser memory usage">
Now, let's serve the video using a stream:
<pre><code class="hljs">const http = require(&#x27;http&#x27;);
const fs = require(&#x27;fs&#x27;);

const server = http.createServer((req, res) =&gt; {
 const src = fs.createReadStream(&#x27;./video.mkv&#x27;);
 src.pipe(res);
});

server.listen(1337);
</code></pre>
In this code, we have created a readable stream to the file and directly pipe it to the HTTP response, so rather than loading it to the memory the input from the HDD disk is directly written into the network without consuming the memory.
Here is the screen-shot of memory usage while sending the file using a stream:
<img src="https://stackabuse.s3.amazonaws.com/media/introduction-to-nodejs-streams-2.png" alt="web browser memory usage with a stream">
As you can see the memory usage is way too low compared to the first method.
<h2 id="usefuleventsinastream">Useful Events in a Stream</h2>
Since the <code>Stream</code> class inherits the <code>EventEmitter</code> class, each stream will have its own type of events that you can subscribe to using the <code>EventEmitter</code>'s <code>on()</code> method. This event will depend on the stream type.
<h3 id="eventsinreadablestreams">Events in Readable Streams</h3>
<ul>
<li><code>data</code>: Emitted when a chunk of data is read from the stream. By default, the chunk will be a <code>Buffer</code> object. If you want to change it you can use the <code>.setEncoding()</code> method.</li>
<li><code>error</code>: Emitted when an error occurs during reading. This may happen if the writable stream is unable to generate data due to some internal failure or when an invalid chunk is pushed to the stream.</li>
<li><code>end</code>: Emitted when there is no more data in the stream.</li>
<li><code>close</code>: Emitted when the stream resource is closed and indicates that no more events will be emitted in the future.</li>
<li><code>readable</code>: Emitted when the data is available in the readable stream to read.</li>
</ul>
<h3 id="eventsinwritablestreams">Events in Writable Streams</h3>
<ul>
<li><code>close</code>: Emitted when the stream resource is closed and indicates that no more events will be emitted in the future.</li>
<li><code>error</code>: Emitted when an error occurs during reading. This may happen if the writable stream is unable to generate data due to some internal failure or when invalid chunk data is pushed to the stream.</li>
<li><code>finish</code>: Emitted when all the data has been flushed from the writable stream.</li>
<li><code>pipe</code>: Emitted when the writable stream is piped to a readable stream.</li>
<li><code>unpipe</code>: Emitted when the writable stream is un-piped from a readable stream.</li>
</ul>
<h2 id="conclusion">Conclusion</h2>
In simple terms, streams are used to read from input or write into output sequentially. Most of the time, streams are used to read or write from a continuous source or a comparably big one.
The Stream module is a native module that is shipped by default in Node.js. The <code>Stream</code> is an instance of the <code>EventEmitter</code> class, which handles events asynchronously in Node.js. Due to their superclass, streams are inherently event-based.
Transformation Streams weren't covered in this article, as they warrant their own article.
The source code of this project is available on <a rel="nofollow noopener" target="_blank" href="https://github.com/jkasun/stack-abuse-nodejs-streams">GitHub</a> as usual. Use this to compare your code if you got stuck along the tutorial.
If you want more information about streams and or advanced knowledge, it's recommended to follow the <a rel="nofollow noopener" target="_blank" href="https://nodejs.org/api/stream.html">official documentation</a> for Streams.

Janith Kasun

Streams represent continuous, sequential data flow, received by a potentially unbounded source. In this article, we'll use writable, readable and duplex streams in Node.js, as well as build a Stream Pipeline.

Introduction to Node.js Streams

Dário Alves

Coroutines are a special type of functions that deliberately yield control over to the caller - but they don't end their context in the process, maintaining it in an idle state.

In this article, we'll dive into Python coroutines.