How to make stop-motion video in an easy way with your child with no special technology

All kids, and some adults, like to watch cartoons. When I was a kid I wanted to make my own cartoons, however it wasn't an easy thing to do, and you needed professional equipment to make them. Kids today are in much better situation compared to how it was for me when I was a kid. Technology which is at our fingertips today can allow anyone to create almost anything that they can imagine.

Let us take a look at how we can easily make a stop-motion video with our child.

Why Stop-motion movie?

Let me first explain why I think that stop-motion is the right choice. We can use whatever we have already laying around the house, some toys or similar, so we don't need to create characters, also for creating scenery we can again use things that we already have at home. So far very easy, right :)

Proper usage of HTTP Status Codes with API's

One error that I see over and over again with API's is improper usage of HTTP status codes. When it come to web sites, most people understand most common status codes 200, 404 and 500, however lot of people are not 100% sure how to translate HTTP status codes to API world, also which other status codes to use and when.

It came from the Web sites

Part of confusion is natural and expected, since HTTP status codes were originally created with web sites in mind and not API's. Beside this there is fair number of them. Huge part of the end users, and engineers also, haven't seen most of them or encountered them in day to day. Due to all of this, I usually see three most common wrong patterns in usage of HTTP status codes.

• Usage of just few of them (200, 404 and 500)
• Inconsistent usage of HTTP status codes
• Usage of wrong status codes for response

If only tool you have is a hammer, then everything is a nail

If we are aware of existence of only 200, 404 and 500 status codes, then it is given that we will only use them. I would suggest everyone to go from time to time, to the list of all HTTP status codes and read it. Especially when we want to implement some behavior and check which HTTP status code make most sense for that type of response/behavior of our API. By doing this we will enrich our knowledge, which is always a good thing, and also build better products, also always a good thing.

Production Driven Development a.k.a. Delivery Driven Development sure way to achive great results

Motivation for defining Production/Delivery Driven Development is lack of focus on most important part of software development in all other DD's, in my mind. Most important thing is delivering value to end customers, which is achieved by reaching production with our software. Most DDs have this as a side goal, while it always have to be primary goal of any software development.

There are 4 rules in Production/Delivery Driven Development

• Rule 0 - deliver to production as fast as possible
• Rule 1 - quality matters from user point of view
• Rule 2 - iterate as often as possible
• Rule 3 - tailored approach

Let us look now look at this rules in more details.

Rule 0 - we must reach production as fast as possible, deliver value as fast as possible

One thing, that is unfortunately overlooked over and over again is, that most important thing is delivering value to end users by reaching production.

Writing better unit tests in less time with Junit Parameters

Most of people understand the importance and benefits of unit tests and why you should have them in projects you work on. Also, most of people don't like to write unit tests in projects they work on. TDD people are on other side of specter of course, but from my experience they are minority in IT industry.

When it comes to me, well I am with most people :-). I know why having unit tests is good, and how it will improving quality of code and projects. I know why you should invest in them, however I am not super happy to write unit tests, that isn't the thing that keep me wake at night. I prefer much more to create cool software and solve complex problems, then writing unit tests. That is why I am always on lookout on things that can help me in getting more and better unit tests, with less work from my side ,since in the end you should have unit tests in your projects.

One of those things that can help you to write better unit test with less time spent is Junit Params.

Protocol Buffers basic stuff you need to know

Protocol Buffers is binary protocol, it was developed in Google and made publicly available. First publicly available version was Protocol Buffers version 2. Most recent implementation at the time of writing this article is Protocol Buffers version 3. Version 1 was never publicly available.

Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data. Protocol buffers currently support generated code in Java, Python, Objective-C, C++, C#, JS and more. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages.

Reasons to look at Protocol Buffers

You might ask yourself why would I even look at or consider Protocol buffers, so let us take a look at few reason.

Size of Data

Fact that Protobuf is binary protocol gives it some very nice characteristics. By default it's throughput is much higher compared to textual protocols, for example JSON and XML. This shouldn’t come as a surprise. However, difference in throughput between protocol buffers and JSON, for example, can be made smaller by compressing data when sent using textual protocols, and some other tricks can be used. If this things are done Protocol buffers will still be better in throughput, but not with so large margin, so my suggestion would be to always do it in case you are using textual formats for transfering data.

CPU load

Another important thing that need to be taken into account is how CPU intensive is marshaling and unmarshaling of data. Textual protocols will be much more CPU intensive by default, and this isn't easily addressed, as for example difference in throughput.

Why beeing right person for the job, doesn't mean that you will get it

Let us get the facts right first

• Being the right person for the job doesn't mean that you will get it
• Being great developer doesn't mean that you will ace the Interview
• Being great developer doesn't mean that you will be great as Interviewer/Recruiter
• If you are not hired, it doesn't mean that it wasn't mistake
• If you are hired, it doesn't mean that it wasn't mistake
• Interview shouldn't be personal and is not always representation of who you are or what you know/don't know.

Motivation

As everyone else, as soon as I entered the professional scene, getting paid for work, I encountered interviews. I was interviewed on multiple occasions. I passed some interviews, failed others. I accepted some job offers, declined others. I am guessing that everyone has similar experiences.

Since 2010, I got involved in other side of an interview process. Instead of being interviewed, I did interviews. I did interviews in many companies, for all kind of positions, and I did all parts of interviewing process over the time. I interviewed a large number of people from all over the world, and I spend much more time in "driving seat" instead of being interviewed.

How to Docker-ise your Java application with Maven plugin

There are two maven plugins that you can use, in order to add your Java Applicatoin into Docker in an easy way.

First plugin that you can use is docker-maven-plugin from Fabric8

• https://dmp.fabric8.io/

Second is docker-maven-plugin from Spotify

• https://github.com/spotify/docker-maven-plugin

Let me show you how to do it by using Fabric8 plugin.

Update pom.xml

Just add configuration like this into your pom.xml, in build part, plugins.

<plugin>
    <groupId>io.fabric8</groupId>
    <artifactId>docker-maven-plugin</artifactId>
    <version>0.20.1</version>
    <configuration>
        <images>
            <image>
                <name>${project.name}:${project.version}</name>
                <build>
                    <from>openjdk:9</from>
                    <assembly>
                        <descriptorRef>artifact</descriptorRef>
                    </assembly>
                    <ports>
                        <port>8080</port>
                    </ports>
                    <cmd>java -jar maven/${project.name}-${project.version}.jar</cmd>
                </build>
                <run>
                    <ports>
                        <port>8080:8080</port>
                    </ports>
                </run>
            </image>
        </images>
    </configuration>
</plugin>

How to put Java application behind Apache HTTP server

In the "old days" it was very common thing to put Apache HTTP server in front of your Java application server, or Java application it self.

Reason behind it was very simple, caching could be added in easy way, also load balancing could be added, and on top of this static content could be served by Apache HTTP while all other requests could be served by Java application.

Although this setup isn't new, I still encounter it on regular basis, and see that a lot of people still have issues of how to set this up.

Gentle intro to GraphQL in Java World

A lot of people think that GraphQL is for Front End and JavaScript only, that it doesn’t have the place with Backend technologies like Java, but is that really the case.

Also very often GraphQL is compared to REST, but is this comparison justified one or not?

First, let me start by answering the most important question of them all. What is GraphQL?

If you check official website you will see something like this

“GraphQL is a query language for your API, and a server-side runtime for executing queries by using a type system you define for your data. GraphQL isn’t tied to any specific database or storage engine and is instead backed by your existing code and data.”

What actually it should say is

GraphQL is a specification, nothing more and nothing less.

This is an important thing to remember, since we as developers will be working with implementations of GraphQL. Some of the implementations have implemented more or less of things from GraphQL specification. There are implementations in many languages like JavaScript, Java, PHP, Go and others. There are new implementations being made every day in different languages and in existing ones.