I’ve recently had the opportunity to work with ANTLR to create a DSL, and I’ve liked the overall experience so much that I’ve started using it for parsing just about anything, especially for my metaprogramming needs, and decided to write a series of articles to explain how it can be used to create DSLs.

In the first article we’ll discuss the motivations behind creating a DSL, what our options are regarding the implementation, and how ANTLR can be used to declare a grammar and parse some inputs with it.

In later articles we’ll create an actual DSL, execute and evaluate inputs, and even write a web-based code editor with full support for parsing and verifying code written in our language.

For this we’ll be using Microsoft’s Monaco Editor so it’ll also double as a potential VS Code extension because VS Code is based on Monaco as well.

But first things first, let’s see why we might need a DSL in the first place.

Note: You can find all of the examples listed in this article on my GitHub repo: ygunayer/antlr4-examples

In our previous example we’ve explored the basics of Erlang, and built simple, but concurrent and stateful apps for demonstration. With the basics in place, it’s time to move on to the actual stuff that makes Erlang such an excellent language for building fault-tolerant apps for distributed networks.

In this article, we’ll go over topics like distributed Erlang (aka node-to-node communication), fault tolerance via Erlang/OTP, and code distribution and releases via rebar3, which will allow us to write production-ready apps.

As mentioned in my introductory article to the actor model, the programming language Erlang implements the actor model as its core functionality, so anyone who’s got exposed to Akka is bound to have heard about it, and quite possibly they’ve become interested with it.

While I certainly was interested, that interest has only recently grown into the “oh boy I’ve got to try this right now” levels. Now that I’m this hyped, and we’re waiting for Scala 3 anyway, it’s the perfect time to play around with Erlang.

So in this article, we’ll go over a quick introduction to Erlang, and in subsequent articles we’ll rewrite our bastra game from the previous article in Erlang, with exactly the same functionality.

If you’re interested in learning more (much, much more) about Erlang, just check out the incredible book Learn You Some Erlang for Great Good! either in printed or online form.

In previous articles we’ve talked about how we can implement a simple game using actors, and how we can use Akka’s remoting functions to build actor networks, so it’s time we put the pieces together and create a multiplayer game.

The game we’ll implement is called pişti or bastra, a card game that can be played with 2 to 4 people, and is pretty popular among people of all ages due to its simplicity.

At the start, each player is dealt 4 cards, and 4 other cards are placed in the middle of the table (also called the board), with one of them open. To ensure fairness, any jacks that are dealt on the board stack is randomly replaced with another from the deck so the players can get them later. On each turn, a player plays a card from their hand and places it on the board. If the card that is played is a jack, or if it matches the one on top of the board stack, the player collects the board (also called fishing) and earns points. If not, the card is left on the stack and the turn passes over to the next player. If the player runs out of cards they’re dealt 4 more, and the game lasts until all cards are played out. Once they are, whoever has the highest score wins the game.

In the previous article we’ve implemented a standalone guessing game, but actors are built for much more complex problems such as concurrent communication over a network. A turn-based multiplayer game such as a card or tile game is the perfect example for that use case, and that’s what we’d like to achieve eventually. But first, we need to figure out how to allow actors to communicate with each other over a networking layer, and possibly with a high enough level of abstraction so that we can model our business rules without having to think about any low-level stuff.

Thankfully, Akka does this abstraction so well that the whole process is almost entirely transparent. Let’s see how!

Now that the basics of the actor model is out of the way (thanks to the previous article), it’s time to make something with it! We’ll begin by creating an Akka project from scratch, and then move on to implementing a number guessing game based on actors, which will give us an easy start in modeling actor-based systems.

The rule of the game is quite simple; it’ll pick a random integer between 1 and 100, and user will try to guess it. Each time the user provides a guess, the game with reply with a message that tells the player whether or not they matched. All interaction will be through the console, so no unnecessary complication there.

Note: I won’t go into any details about the model nor Akka’s implementation of it, so if you’re ever in need of assistance, feel free to use the previous article as a reference.

By the time I took the Principles of Reactive Programming course on Coursera last spring, I was already a fan of Scala and concurrent programming, so it was no big surprise that I fell in love with the actor model the moment I heard about it during the course. I’ve been wanting to write about it ever since, but have only recently had the time to actually do it.

Let this be the first in a series of articles where I explore the actor model; what it is, how it works, where it can help, and how some of its use-cases may be implemented. I’ll first describe what the actor model is and how Akka implements it, then move on to simple examples like hot-or-cold games, and finally end up in client/server applications such as multiplayer card or tile games.

Disclaimer: This post assumes that you’re at least somewhat familiar with Scala.

Functional programming has been on the rise for quite some time now, and rightly so. Many non-functional programming languages had long adopted at least some amount of functional programming principles, and while Java had been lagging behind, it’s finally jumped on the bandwagon with the latest version, Java 8.

Functional programming is closer to mathematics than other programming paradigms such as procedural or object-oriented programming, so as one gains more and more experience on one of them, it gets more difficult for them to grasp the functional programming concepts. Even though I had a C/C++ background using function pointers, and a lot of Javascript experience using callbacks and methods such as Array.map(), I had a hard time understanding LINQ in C#. In that sense, it’s perfectly understandable for me that most Java programmers, even seasoned ones, are shying away from lambdas and streams and prefer to stick to good old lists and for loops in their daily usage.

In the light of that observation, I decided to write this article to help programmers establish a ground on what these “strange” facilities are. I will be explaining what streams and lambda expressions are, and which functional operations are executed and what does it mean to be executed lazily. Hopefully, this article will be helpful to both newcoming Java 8 programmers, and C# programmers who are not familiar with the LINQ API.

In the previous article we made a very simple app that sent updates to clients in real-time, and in this article, we’ll build on that example and make a slightly more complicated app; a private messaging app.

In the first example messages were broadcast to all client, but this time we’ll authenticate users with Spring Security and target them specifically by using STOMP’s user-specific methods. We’ll also use a message queue (namely, Apache ActiveMQ, which must be installed on your computer) to temporarily store messages before sending them out. And as for the transport between the queue and our message dispatchers, we’ll use Apache Camel.

We live in the age of digitized social interaction. As demonstrated by the countless gameplay video streams of games over 20 years old, we feel the need to socialize with even the most static digital content. Now, everything is collaborative, en masse and in real-time, so web apps need to be able to handle this concurrent and user-scoped data in an elegant fashion in order to survive.

The traditional approach to handing out clients data in real-time (or quasi-real-time) was to make clients poll the server at regular intervals. This could be achieved by a simple polling (say, every 5 seconds), or long-polling (same as the other, but with longer-lasting sockets and late responses), but now there are new kids in town. The new approach to this situation is to let the server push the data using a publish/subscribe mechanism, rather than the client pulling them in, and technologies like Comet, WebSocket, Server-Sent Events were created for this exact purpose.

This article will demonstrate a simple guestbook app that uses the WebSocket method, and will feature Spring Boot and STOMP on the server side, and SockJS and stomp.js on the client side.