DEV Community: Kristijan Kanalaš

Modernizing Emails: Innovations for Efficient Handling in Distributed Systems

Kristijan Kanalaš — Tue, 16 Jul 2024 22:29:58 +0000

Since the beginning of digital businesses, one of the main channels of communication between the business and a client was, and still is, email. Email is a technology that is over 50 years old, and that's one of the reasons for the wide variety of mail clients that render HTML differently from each other — Outlook, I'm looking at you here 👀

Aside from that problem, there is one more: how do we handle sending emails in big distributed systems?!

So... Here is how we modernized emails

As is customary nowadays for distributed systems, especially for microservices, we are using a message broker (in our case, RabbitMQ). The message broker handles the communication between multiple applications that want to send an email and an email service that is responsible for rendering and scheduling the email. Here is an example of a message that is being passed through the message broker:

{
    "toEmail": "to@example.com",
    "subject": "Test Subject",
    "templateName": "test",
    "templateData": {
        "name": "test"
    },
    "priority": 200,
    "attachments": [
        {
            "path": "/test/path/file.pdf",
            "filename": "original_filename.pdf"
        },
        {
            "path": "/test/path/file2.pdf"
        }
    ],
    "fromEmail": "from@example.com",
    "fromName": "From Name",
    "replyToName": "Reply-to Name",
    "replyToEmail": "replyto@example.com",
    "toName": "To Name",
    "cc": [
        "cc1@example.com",
        "cc2@example.com"
    ],
    "bcc": [
        "bcc1@example.com",
        "bcc2@example.com"
    ],
    "headers": {
        "X-TEST-HEADER": "Test Value"
    },
   "locale": "en",
   "transportType": "external"
}

To enable rapid integration and keep the above message standardized between applications we made an SDK that contains configuration and DTOs.

Aside from the email properties you likely recognized in the message, you can see emailTemplate and emailData. These two properties allow us to control which template in the email service will be rendered and with what data it will be rendered.

The email service is built with Symfony and its templating engine, Twig. Templates are written in MJML markup, an email framework that helps us address the first problem we mentioned. Twig allows us to pass the data to the MJML template without breaking the MJML structure. After the data is rendered, we send the result to a small MJML service that converts the MJML markup to HTML. Here is an example of a template:

{% extends 'mail/layout/main.mjml.twig' %}

{% block header %}
    {% include "mail/common/header.mjml.twig" %}
{% endblock %}

{% block content %}
    <mj-section>
        <mj-column>
            <mj-text font-weight="300" font-size="24px">
                {% if name is defined %}
                    {{ 'greeting'|trans }} {{ name }}
                {% endif %}
            </mj-text>

            <mj-spacer height="16px" />

            <mj-text font-weight="700" font-size="24px">
                {{ 'intro'|trans }}
            </mj-text>
        </mj-column>
    </mj-section>

    <!-- Main text -->
    <mj-section>
        <mj-column>
            <mj-text>
                {{ 'dataLabel'|trans }} <strong>{{ data }}</strong>
            </mj-text>
            <mj-text>

            </mj-text>
        </mj-column>
    </mj-section>
{% endblock %}

{% block contact %}
    {% include "mail/common/contact.mjml.twig" %}
{% endblock %}

{% block footer %}
    {% include "mail/common/footer.mjml.twig" %}
{% endblock %}

We extend a layout that has defined blocks and fill those blocks with either common reusable parts or new type of content.

After the email is rendered, all that is left is to send it to a transport system, and voilà, we have an email that is beautifully rendered in most common email clients.

Conclusion

Five years ago, we were constantly struggling with synchronizing our layouts across multiple applications, styling emails, and dealing with them randomly breaking in different email clients. But having had this system in place for the last five years, creating emails has become not only manageable but actually kind of fun. We've turned a major headache into a streamlined process, and it's rewarding to see our emails looking great in every inbox — even Outlook 😄

If you'd like to support me writing feel free to buy me a cup of coffee.

Gitlab CI/CD for npm packages

Kristijan Kanalaš — Wed, 21 Jul 2021 14:56:37 +0000

A couple of weeks ago the IT team in my company talked about having repositories for the packages we make for our PHP applications so we can switch to a more natural use of composer. We left the meeting with ideas but not with a concrete solution nor a promise to research this topic.
Few days ago I needed to make a javascript package, after creating a repository on our gitlab I noticed an option for Packages & Registries. As it blew my mind that such an option exists I decided to research it a little and use it for this javascript package if possible.
Here is what I learned in the process.

Options

Gitlab offers a few registries you can work with: Composer, Conan, Maven, NPM, NuGet, PyPi. I have only tried out the NPM registry, but others should also be easy to work with.

Publishing an NPM package to registry

This was actually my first time making an NPM package. So I would like to recommend this post Step by Step building and publishing an NPM typescript package to the first timers like me. It was very easy to understand and no steps were missed.

First of all in your package.json you should scope your project cause Gitlab requires packages to be scoped.
For example:



{
  "name": "@scope/example-package-name",
  "version": "1.0.0"
}

After we have this setup, if we use a .npmrc file or npm config set registry we can tell npm where we want it to publish our package. Looks something like this:



//gitlab.example.com/api/v4/projects/${PROJECT_ID}/packages/npm/:_authToken=${GITLAB_DEPLOY_TOKEN}

If the repository is set to internal or private you need to use a Gitlab deploy token. On how to get one, you can read at Deploy tokens documentation.

After running npm publish you should be able to see your package in the registry of your repository.

And you should be able to see a version 1.0.0 that says it was pushed manually.

CI/CD

To make our life and the life of our colleagues better we can make good use of the gitlabs CI/CD system here.
We can use .gitlab-ci.yml configuration that looks like this:



stages:
  - build
  - test
  - publish

build:
  stage: build
  only:
    - tags
  cache:
    key: build-cache
    paths:
      - node_modules/
      - lib/
      - .npmrc
    policy: push
  script:
    - echo "//gitlab.example.com/api/v4/projects/${CI_PROJECT_ID}/packages/npm/:_authToken=${CI_JOB_TOKEN}">.npmrc
    - docker run -v $(pwd):/app -v /home:/home -w="/app" -u="$(id -u):$(id -g)" -e HOME node:14 npm install
    - docker run -v $(pwd):/app -v /home:/home -w="/app" -u="$(id -u):$(id -g)" -e HOME node:14 npm run build
test:
  stage: test
  only:
    - tags
  cache:
    key: build-cache
    paths:
      - node_modules/
      - lib/
      - .npmrc
    policy: pull
  script:
    - docker run -v $(pwd):/app -v /home:/home -w="/app" -u="$(id -u):$(id -g)" -e HOME node:14 npm run test
lint:
  stage: test
  only:
    - tags
  cache:
    key: build-cache
    paths:
      - node_modules/
      - lib/
      - .npmrc
    policy: pull
  script:
    - docker run -v $(pwd):/app -v /home:/home -w="/app" -u="$(id -u):$(id -g)" -e HOME node:14 npm run lint

publish:
  stage: publish
  only:
    - tags
  cache:
    key: build-cache
    paths:
      - node_modules/
      - lib/
      - .npmrc
    policy: pull
  script:
    - docker run -v $(pwd):/app -v /home:/home -w="/app" -u="$(id -u):$(id -g)" -e HOME node:14 npm version --no-git-tag-version ${CI_COMMIT_TAG}
    - docker run -v $(pwd):/app -v /home:/home -w="/app" -u="$(id -u):$(id -g)" -e HOME node:14 npm publish

Notable points:

In build stage we make a .npmrc file that contains the path of the registry made by using the CI environment variables
All the stages run only on tags, a special way to tell the CI/CD system to only activate when you tag the code in your repository
We build a cache for node_modules, lib and .npmrc as such we limit the number of scripts we need to run after the build step
Only the build step makes the cache others only use it, it is defined by push/pull policy
In publish stage we use a npm version --no-git-tag-version ${CI_COMMIT_TAG} command. npm version is a noisy command that tags and commits code if it detects a directory being a git repository so that's why we use --no-git-tag-version here. As the stage was triggered by us tagging the code, we have the ${CI_COMMIT_TAG} environment variable available to use for package versioning. After that we just publish the package.

Note
I didn't have a gitlab runner that was setup to use docker normally nor did I have node and npm installed on the machine so I had to use docker run commands like shown. So... not the most elegant way of doing it.

The end result is this:

Now the developers don't have to run any scripts locally, just to commit to the repository and tag the code.

If you'd like to support me writing feel free to buy me a cup of coffee.

Why you shouldn't cascade functionality

Kristijan Kanalaš — Sat, 28 Nov 2020 02:55:27 +0000

Don't do it! I'm serious, it will come back and bite you in the ass. 😆

So here is what I did

I was working on a microservice that should extract images that have faces in them from PDF files. I used Symfony and as such I made a few services that were responsible for their part of the job. For example, ImageExtractionService or FaceDetectionService.
I was pretty proud of the finished project, using some open source services to detect faces in pictures and choosing what program to use to extract images from PDF files, that I forgot to think ahead about code reusability and overall code quality.

The problem

I cascaded the functionality between the services. It looked something like this:

//ImageExtractionService
$this->faceDetactionService->detect()

//FaceDetectionService
function detect() {
    //some code
    $this->imageService->process()
}

//ImageService
function process() {
    //some code
    $this->cleanupService->cleanUp()
}

Chaining it like this you end up making unwanted connections, for example if I was only interested in what FaceDetectionService "saw" I couldn't obtain that data because it doesn't return that data instead it immediately tries to process the image.

How did it come to bite me in the ass?

Well, few days after the feature went to production I noticed a need for a service debug option. But because my code is chained and needs a link to download a PDF and needs a link where to upload the images I just couldn't make a local debug unless I truly separated the services.

So... Don't do it! Don't chain the functionality of separate services.

If you'd like to support me writing future posts feel free to buy me a cup of coffee.

How can competitions help you improve your skills

Kristijan Kanalaš — Fri, 03 Jul 2020 17:28:04 +0000

A quick note before we begin:
I started writing this post long before 2020 was a thing. So even tho in this post I talk a lot about offline competitions, at this time I highly recommend online competitions. If you do enter an offline competition, please be sure to keep social distancing and to follow your country's guidelines regarding the current situation.

Every software developer was a beginner once, some people at a very young age, some people at an age of 50.
It doesn't matter how old you are, if you are self-taught or computer science student, healthy competition can boost your developer skills. If you'd like to broaden your knowledge, gain experience or make sure that programming is for you, read on.

About competitions

There are many types of competitions, the ones that I enjoy being a part of are offline 24 hours team hackathons. As you can see by that elaborate wording there are different kinds of competitions:

Offline or online
Variable duration, spanning from 2 hours to a month
Team or solo
Different types and themes

How can you get into competitions

In my case I got familiar with programming competitions trough college. I had a few passionate professors that started working with local companies to organize competitions. I know that not everybody can find themselves in such a situation and that's why I want to tell you how you can find some on your own.

Research companies you like

Many of the bigger companies in your environment know how important for recruiting, developing talent and employer branding competitions are. So you can research a few companies you like and find out if they hold any competitions. One of many examples is Ericsson Programming Championship.

Join your local IT community

Joining your local IT community will have multiple benefits for you and one of the benefits is learning about events happening near you. Last year my local IT community center organized the first ever open hackathon in my town. Even some of my professors were participants (I must say the experience was very weird for me because I was one of the mentors at the time 😆).

Follow IT blogs

If your country has a website that is specialized in general IT news in your region, follow it right now. You can learn a lot from them and also learn about interesting events happening.
Following DEV.to can also inform you a lot as DEV.to promotes a lot of IT events. At the moment of writing this post it's hacktoberfest so I bet if you take a look at the events on the hactoberfest page you could find some upcoming competitions you can join.

What you need before entering a competition

If I had to say what is the number one thing you need it would be courage. You need courage to do something that's completely outside of your comfort zone but believe me it's worth it. It doesn't matter how old you are, what experience you have there is a competition out there for you.
Skill is needed but it is definitely not a deal breaker. Lets say, if you are interested in web technologies, knowing HTML, CSS and a little bit of JavaScript you could enter a competition that's more focused on the idea and you need to code up just a semi working prototype.

The benefits

Boosting self-confidence - expending your skill set and discovering what you are capable of doing in stressful situations really boosts your self-confidence.
Developing your programming skills - you can choose a technology you never have time to work on and try to master it in the allotted time. Or you can challenge yourself to go above and beyond with the technologies you already know.
Communication - If you are a part of the team you will have a lot of opportunities to better your soft skills. You will have to resolve potential conflicts which you can learn valuable lessons from.
Time and task management skills - You will have to decide who will do what on your team and to estimate how long each task will take, that way you become more efficient. You should also be prepared to cover for each other because any day can be the day when you write the code but nothing works, believe me happens a lot during competitions.
Making friends - meeting and socializing is as important in IT industry as it's in any other.
Job offers - Most of the time competitions are not just for the sake of competitions, there are always companies around that are ready to scout any potential candidates. The company I work for now got to know me from participating in their competition.
The reward - Usually there is a reward for the top three teams and who doesn't like free stuff on top of already rewarding experience.

Conclusion

I've learned a lot trough my experiences competing and as we all know there is always a lot more to learn, so I can't wait for the opportunity to form a team with my friends and participate again. What are you waiting for?

Hi 👋
Thanks for reading the post. I'm slowly getting back into writing, if you'd like to support me writing future posts feel free to buy me a cup of coffee.

I wrote a PHPStorm plugin

Kristijan Kanalaš — Fri, 26 Jul 2019 12:36:50 +0000

There is a high chance you were once so upset at your IDE for not having a feature you need, that you thought of writing a plugin for it. Most of us end up never doing it and finishing the job without the said plugin. The same happened to me.
I had an idea for a PHPStorm plugin for months but never finding time to write it. Until I had to do the same boring routine one too many times.
So I wrote a PHPStorm plugin.

The problem

When you have a class that has getters and setters in some (rare) cases you will need to write something like this:



$car = new Car();
$car->setMake('Audi');
$car->setModel('A6');

With some auto-complete features that InteliJ platform provides I can finish this pretty quickly. But what if a class has a dozen of getters or setters you need to call?

The idea

The idea was simple a developer places the caret on the $car variable and by pressing a shortcut, generate all the getters or setters (depending on the shortcut) for the given object.

Writing the plugin

I was really nervous cause I haven't touched java since my school days but I made a decision to just do it.

Prerequisites

PHPStorm - contains php-openapi.jar and php.jar
InteliJ IDEA Community Edition

Setup

I've followed a setup written by the people at Jetbrains, Setting-up environment for PhpStorm plugin development. If you are going to follow this setup make sure that when you are configuring the SDK you add php-openapi.jar and php.jar like so
don't make the same mistake as me by not seeing the warning to not set those in Libraries.

Debugger setup

By default InteliJ will setup and run another instance of InteliJ when you click on the debug button. It works really good, but I was developing a plugin for PHPStorm, not for InteliJ. I've searched far and wide for a debugger setup if you are developing a PHPStorm plugin and I couldn't find any. So I had to discover how to do it on my own.
You can go to the edit debug configurations like so in the JRE field navigate to the path of your PHPStorm and voila, now it works. Easier than I thought it would be.

Coding

I must say I found it hard to do anything, documentation is pretty scarce and I forgot a lot of java rules and syntax.
Unfortunately I couldn't find a way to tap in the power of PHPStorm and to ask it; what it knows about a certain variable. The only choice I had left is to use PSI and try to figure out where is the declaration of the variable and what type it is. After a few hours of trial and error I have succeeded in that.



    static void generateMethods(AnActionEvent event, String typeOfMethod) {
        final Project project = event.getData(PlatformDataKeys.PROJECT);
        final Editor editor = event.getData(PlatformDataKeys.EDITOR);
        if (editor != null) {
            final CaretModel caret = editor.getCaretModel();
            PsiFile file = event.getData(LangDataKeys.PSI_FILE);
            if (file != null) {
                PsiElement selectedElement = file.findElementAt(caret.getOffset());
                if (selectedElement != null && selectedElement.getParent().getReference() != null) {
                    PsiElement variableDeclaration = selectedElement.getParent().getReference().resolve();                        
                    if (variableDeclaration != null) {
                        PsiElement assignmentExpression = variableDeclaration.getContext();
                        if (assignmentExpression != null) {
                            final Collection<PsiElement> selectedElementClass = new SmartList<>();
                            assignmentExpression.accept(new PsiRecursiveElementVisitor() {
                                @Override
                                public void visitElement(PsiElement element) {
                                    if (element instanceof ClassReferenceImpl) {
                                        if (element.getReference() != null) {
                                            selectedElementClass.add(element.getReference().resolve());
                                        }
                                    }
                                    super.visitElement(element);
                                }
                            });
                        }
                    }
                }
            }
        }
    }

Believe me, I'm not proud of this code and I am looking forward to rewriting it soon.

Now the only thing left was to get the getters and setters of the instantiated class and add the calls to the editor. I managed to get the methods of a class without any issues. I expected the writing to the editor to be the easiest task of them all and boy was I wrong. Again I had to spend a few hours to figure out how to do it and this is the best I could come up with



Document document = editor.getDocument();
boolean firstMethodGeneration = true;
for(PsiElement initClass:selectedElementClass) {
    PhpClassImpl phpClass=(PhpClassImpl)initClass;
    for(Method method:phpClass.getMethods()) {
        String methodName=method.getName();

        // If method name has "set" on position 0 add it to editor
        if(methodName.indexOf(typeOfMethod)==0) {
            boolean FirstSetter=firstMethodGeneration;
            WriteCommandAction.runWriteCommandAction(project,()->{
                if(FirstSetter){
                    caret.moveToOffset(caret.getVisualLineEnd());
                    document.insertString(caret.getOffset(),"\n");
                }
                caret.moveToOffset(caret.getVisualLineEnd());
                document.insertString(caret.getOffset(),selectedElement.getText()
                +"->"+methodName+"();\n");
            });
        }
        firstMethodGeneration=false;
    }
}

Final result

In the end I got a very limited plugin that can generate setters or getters only for the variables instantiated in the same file. It can't determine variable type from a function return or more advanced stuff like that. Having said that I'm still very happy how it turned out and I'm planning to make it more powerful in the future and add more features to the plugin.

If you want to see more of the plugin feel free to visit the GitHub repository.

KristijanKanalas / PHPCodeGeneratorPlus

PhpStorm plugin that let's you generate even more PHP code

PHP code generator +

PhpStorm plugin that lets you generate even more PHP code.

Plugin provides the following features:

Generates calls for the setters of the declared variable (Shift +Ctrl + NUMPAD1)
Generates calls for the getters of the declared variable (Shift +Ctrl + NUMPAD2)

Key	Value
Plugin Url	https://plugins.jetbrains.com/plugin/12590-php-code-generator-
ID	PHPCodeGenerator+

Install

Install the plugin by going to Settings -> Plugins -> Marketplace and then search for PHP code generator

Usage

By placing your caret at an initialized variable and pressing ALT + Insert a PhpStorm code generator menu will popup you can then choose Get getters or Get setters option. Actions also have shortcuts Shift + Ctrl + NUMPAD1 and Shift + Ctrl + NUMPAD2.

Authors

Kristijan Kanalaš (kanalaskristijan@gmail.com)

View on GitHub

From Monolith to Microservices in One Year

Kristijan Kanalaš — Thu, 18 Jul 2019 10:56:59 +0000

So, there I am a year ago, living a carefree life working on a legacy monolith — a codebase written in CodeIgniter 2. Not the best framework in the world, but it did the job, at least on the surface. We had a lot of hacky code, after years and years of making things work for our clients in as little time as possible. Having said that, I think you understand that first sentence was a joke.

After some changes to our business strategy — and a lot of convincing — the IT department got a green light for a no-deadline, full rewrite of our Applicant Tracking System (ATS) — only a part of our monolith, but a big part for sure.

Problems

After adding a new feature, it goes into the manual testing phase. Once it's greenlit, you deploy it to production — but what often happens is you miss a testing scenario, and you end up with lots of bugs in production.
This problem is tightly connected to the previous one: If you have an older codebase, its foundation starts to slowly break down, so adding new code on top of it ends up relying on other code. With that kind of codebase, sometimes you end up breaking code that should be totally irrelevant to what you're currently writing.
When you have 11 people working on the same codebase day in, day out, without any safeties in place whatsoever, problems are bound to arise.

Known solutions

Automated tests — Even if you don't cover every possible scenario, automated tests — in addition to manual testing — give you a pretty good solution to our "bugs in production" problem. One of the biggest benefits of automated tests is that they let you freely upgrade your dependencies . If you have even partial coverage, when you do a "composer update" and run your tests, you can instantly see if a change in a dependency is breaking your code.
Splitting a giant codebase into smaller ones (i.e. microservices). With microservices, you can battle the "old code" problem on two fronts: On the one hand, they allow you to just leave your code sitting there without having it bother anything else, and on the other hand, if you do want to do a rewrite, microservices make it easier by letting you rewrite small parts of your codebase at a time. For example, in our legacy app we use an ancient version of TCPDF, which is one of the things preventing us from migrating it to a recent version of PHP. With microservices, we can put TCPDF inside a container with the specific PHP version it needs, and it's no longer an issue for the rest of the codebase.
One of the best solutions we found for our problem was splitting the codebase between our teams, and doing regular code reviews inside those teams. This way, the whole team knows the code they are working on, and we avoid any potential problems by using merge requests.

How we did it

For the first time ever, we got to do a project of this without having any sort of concrete deadline (Did you think I was kidding when I said that earlier?); even so, we couldn't just rewrite everything remotely related to the ATS, even if we wanted to — so, we decided to settle for rewriting only the parts that communicate with our ATS (in addition to the ATS itself, of course). The first microservice we made was the one that manages our job ads — we call it the job server. This was my first Symfony project; given that, and some of the other problems we found ourselves dealing with later on, I think you'll understand why I had to rewrite that microservice 3 times in the course of this project. And so we arrive at one of the first pieces of advice I can give: don't be afraid of rewriting something you just finished rewriting. Even if you have experience, it's unlikely that you'll get everything right the first time around.

SDKs FTW

If you take a look at the arrow between "ATS" and "Job server," the way it's drawn right now makes it look like they're communicating directly. We knew that the ATS wasn't going to be the only service communicating with the job server. Very early on, we discovered the need for SDKs. There is no better way of communicating with a service other than a service having its SDK. The way we went about this , though, is questionable…

Sidenote: What we refer to as "SDKs" are light, reusable libraries that make it easy to communicate with a specific service. We find these particularly useful because (nearly) all of our backend code is written in one language (PHP), so a service that has an SDK can be easily integrated into any other service.

One day, we found a package called DoctrineRestDriver. Immediately, we were like "OMG, this is awesome." We could make an SDK that gives you an EntityManager and lets you use Doctrine like you're talking directly to a database, even though it actually talks to the job server!

We were so amazed that we immediately went ahead with implementing this package into the Job SDK.

Later in the project, we discovered that it doesn't cover all of our use cases, and also that it's hard to maintain code that uses it. DoctrineRestDriver itself wasn't maintained either, so we had to fork it and spend some long hours digging into and changing the core of the library to make it work for our use case. At the time, we were in too deep to turn back, so we had to continue development with the SDK as-is. The advice I can give on this part of the process is: Don't look for the cheap way out when building SDKs. All the other SDKs we made later on were made with a different approach — Simple, descriptive methods that make a simple HTTP request; basically just thin wrappers around an HTTP client. More code, but far easier to maintain in the long run.

Tests

Up until this point, we'd been working towards splitting our codebase into smaller chunks, and we were doing a pretty good job of it, too; but who was going to test all this when it was done? At the point where the project looked like the diagram above, we had zero tests. (Okay, we actually did have some tests, but I'm not proud of them. Before doing any real research into testing, I started writing tests for the job server. What happened was that, while trying to write what I thought were unit tests, I accidentally wrote integration tests. When I realized what I'd done, I decided to watch some tutorials on how to properly write unit tests. PHPUnit: Testing with a bite from SymfonyCasts is a course that particularly helped me understand testing better.)

After а lot of effort, when all was said and done, we had about 200 tests across all of our microservices. It's still not a lot, all things considered, but we're hoping to gradually increase that number as we go along.

Present Day

After one year, ~50,000 lines of code, and ~2,600 commits, a team of 3 developers — consisting of a senior full stack developer and two medior backend developers — ended up with 18 services. Today, the system powering our ATS looks something like this:

Just imagine having this picture in your head before going to production for the first time. Add to that the inexperience we all had with this technology, and I think you can understand how anxious I was about the prospect of deploying all of this to production. When it came down to it, minor issues aside, we were all surprised by how smoothly the deployment actually went. Today, working in a system like this is amazing, and I wouldn't trade it for anything.

We learned a lot over this past year, and this post contains only a tidbit of the knowledge we came out of this project with. If I'm being honest, probably every microservice in the image above deserves a post of its own, and my team and I are very eager to share all of that knowledge — so, consider this post to be only the first of many.

That's all, folks. I can't wait to hear all your thoughts on this!

About me

Hi, I'm Kristijan! Traveling enthusiast, full time food and beer lover, and occasional software developer. When I'm not planning my next trip to Japan or watching anime, I work at poslovi.infostud.com, a part of Infostud group.