DEV Community: Roman Sery

Themeable React Monopoly board

Roman Sery — Thu, 10 Sep 2020 23:35:51 +0000

I’ve been working on a Monopoly game with a customized rule set and more gameplay options for players to try different strategies. I feel the standard rules make the game mostly based on luck.

It’s been a lot of fun so far mostly because it’s different from the stuff I usually work on and I’ve been learning a lot. Specifically React, CSS grid/flex, NodeJS, Express, Socket.IO, and more. I think the biggest challenge is getting the networking code to work right and to deal with slow/lagging connections, disconnects, and so on.

Live Demo

I want to share some early React/CSS code for displaying the game board, you can see it here.

You can also find the full source here

Planned game features

One of the features of the game will allow players to create and save their own themes. Other players will be able to select from a list of existing themes. The demo is NYC-themed and you will be able to create your own by giving custom names to the squares.

Instead of having the player that lands on a square immediately purchase it, there will be a new auction system. There will also be more trading and negotiation possibilities between players including loans and rent forgiveness.

If you’re familiar with RPG video games, there will be some elements of that as well. Similar to collecting $200 when you pass GO, each player will also receive ability points they can put into a variety of categories.

About the code

The GameBoard component renders a set of GameSquare components. Each square is assigned an id that used to lookup configuration data. SquareConfigData configures various properties for each square such as color, position, type, and group.

The components in the squares folder are different display implementations that are used by the different square types.

To change the theme data, just change the names in NyThemeData.

Please dont use client-specific release branches

Roman Sery — Fri, 28 Aug 2020 20:14:05 +0000

Recently there was a debate about using client-specific release branches in an attempt to protect them from change. A little background, the software is used by multiple clients. Each client might have a different release deployed to production and new releases of the software are developed every 2 weeks.

There was an idea about using client-specific releases with the intent of isolating them from change to somehow protect those clients from bugs. Let’s take a look at the two approaches.

All clients use the same release branches – Unidirectional updates

Not having client-specific branches is very nice. Any changes you make in one release branch is merged into all subsequent branches.

So let’s say you make a change in 1.0, it gets merged all the way up to 1.3. If one client is using 1.1 and another 1.3, it doesn’t cause any problems. They will all eventually get all bug fixes/updates.

As long as the direction of updates always flows in one direction you’ll be very happy. You will have very few merge conflicts if all changes are merged in a timely manner.

Client-specific branches – Bidirectional updates

Now let’s look at the mess that’s created with client-specific branches. Let’s say clients FAS and MST use their own branches.

There are three majors problems with this approach because we are introducing bidirectional update flows:

Now the process of making changes to 1.0 involves merging into 1.0.FAS and later, into 1.2.MST. The other scenario is when FAS requests changes, you need to merge 1.0.FAS into 1.0 and then do your regular merging. This causes a lot of extra work and results in more merge conflicts.
As soon as FAS switches to using 1.0.FAS, they will stop receiving all bugfixes/improvements that are applied to 1.0. In the effort to isolate FAS from change, it now exists outside of the standard flow of updates.
Now we are making it very difficult for developers to do refactorings/re-structuring of code because it will be extremely difficult to merge. Suppose a developer has worked on significant re-structuring for 1.2. It was merged into 1.3. However, after a few days of being happy, MST now wants changes. Unfortunately, it’s well behind 1.2 and has stopped receiving all updates. You can make the changes directly to 1.2.MST, but in order to merge those into 1.2 and all subsequent branches will be very difficult if not impossible.

Code improvements matter

Another troubling concept came out of these discussions related to #3 above. It seems some people have the notion that code improvements, whether it’s performance improvements or code structure improvements, don’t matter. Clients don’t see code improvements and usually don’t notice performance improvements, therefore they don’t matter.

This idea is absurd and very dangerous. First of all, the goal of performance improvements is for the client not to notice them. As the number of concurrent users/traffic increases, clients should see no change in performance. The only way to accomplish that is to prioritize regularly looking for bottlenecks and other areas of improvement. Clients will most certainly notice performance degradation.

While it’s true that clients usually don’t see the actual code improvements directly, they experience the many benefits of them. If code improvements are regularly prioritized, they experience less future bugs, greater developer productivity, a software product that is easier to change, and more confidence in implementing new significant features.

So please never make the mistake of thinking client satisfaction and regular prioritized code improvements don’t go hand in hand.

Launching LetsDefinitely.com – A dating website, feedback wanted

Roman Sery — Mon, 03 Aug 2020 12:29:58 +0000

I’m excited to announce the launch of LetsDefinitely.com, a dating site that I have wanted to make for a while now. Its design is closely based on the teachings of someone I respect; dating and relationship expert Corey Wayne.

The core concept of making definite plans, by setting a specific date, time, and place to meet leads to more kept dates and less frustrating situations of being stood up. When two people make definite plans it shows they respect and value each other’s time and are looking forward to seeing each other.

Highlights

Inviting users on dates

When someone catches your interest and you would like to possibly set up a date, you will send them a message along with what you will like to do on the date, where, and when. Don’t worry about scheduling just yet, this is designed to show that you are serious about meeting and not a time-waster. Once the other person responds and is interested you can iron out the details of the exact date and time.

Once you’ve both accepted the date, make every effort to show up. Making definite plans means there is no need for confirmations and no flaky responses.

Messaging before the date

Are you tired of endless messaging that leads nowhere? We still allow a limited number of messages to be exchanged between you two to get to know a bit about the other person before the date. As well as to help you decide if you want the date! Studies have shown that too much virtual communication before a date leads to less fulfilling dates. People present themselves the best in person, so let them do it. Virtual messaging is unnatural and can lead to misunderstandings.

After the date

Should I call after the date? Does she want another date? Does he want to see me again?

These kinds of questions cause unnecessary confusion. After the date, both of you will be asked to give your feedback on a 2nd date. No more guesswork! If you like, you can go into detail, but it isn’t necessary. You can simply indicate if you would like another date.
Tech

If you’re reading this you probably at least have some interest in the code. Backend is written in Java using Spring Boot. I use SendGrid for sending emails and Google Firebase for image storage. I use AWS beanstalk for hosting and a MySQL RDS instance for the database.

The frontend uses Bootstrap, Jquery (gasp), and Thymleaf.

If you’re interested in any specific part of the code or specific features, please comment below.
Feedback

I would welcome any feedback and suggestions you might have for me, so please check it out! Thanks.

Customizing your codebase per customer: Part 2 – Conditions

Roman Sery — Sun, 26 Apr 2020 17:21:25 +0000

In part 1, we discussed using a “SiteConfig” enumeration to easily allow toggling features on or off depending on the needs of the specific customer/client. The enumeration would contain different items usually representing a boolean value for toggling features of the site.

That approach is fine for some purposes but is a bit limited and inflexible when you need more complex variations among customers. It might not just be a matter of toggling features. It’s very likely that for some areas of functionality, their requirements will vary greatly among different customers.

Let’s look at a more flexible solution using Spring framework conditional service classes.

Defining a CustomerType

The first thing we will do is define an enumeration containing all of our customers:

public enum CustomerType {
    FB,
    GOOGLE,
    MSFT
}

Now, using CustomerType, let’s create a helper class that will define customer conditions. A customer condition is used to tell Spring which version of our service class to use depending on the current customer.

public class CustomerConditions {

    public static final class FbCondition implements Condition {
        @Override
        public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
            return isMatch(CustomerType.FB, context);
        }
    };

    public static final class GoogleCondition implements Condition {
        @Override
        public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
            return isMatch(CustomerType.GOOGLE, context);
        }
    };


    private static boolean isMatch(CustomerType customerType, ConditionContext context) {
        Environment env = context.getEnvironment();
        if(env == null) {
            return false;
        }
        String customer = Utils.getCustomer();
        return customerType.name().equals(customer);
    }
}

Creating our service classes

Our service classes will contain all the business logic for our application (in theory!). What we would like to do is have a single class that will contain the default functionality and separate customer-specific classes which can override some or all of the defaults.

SiteFunctions - Our default functionality/logic
FbSiteFunctions - Will contain overrides for one of our wonderful customers Facebook.
GoogleSiteFunctions - Overrides for another great customer, Google.

In this simple example, we will only have a single overridable function that will determine if a user account can be deleted. It will look something like this:

public interface SiteFunctions {
    default boolean canDeleteUserAccounts(User u) {
        //by default only allow deleting user accounts if inactive
        return u != null &amp;&amp; !u.isActive();
    }
}

@Service @Conditional(CustomerConditions.FbCondition.class)
class FbSiteFunctions implements SiteFunctions {
    @Override
    public boolean canDeleteUserAccounts(User u) {
        //FB wants to be able to delete accounts regardless of status
        return u != null;
    }
}

@Service @Conditional(CustomerConditions.GoogleCondition.class)
class GoogleSiteFunctions implements SiteFunctions {
    @Override
    public boolean canDeleteUserAccounts(User u) {
        //Google doesnt want to ever delete user accounts
        return false;
    }
}

Notice in the two highlighted lines, we are using the helper conditions we talked about earlier. When doing dependency injection, this will tell Spring to pick the correct implementation of SiteFunctions depending on the current customer.

How to use in our web app

Now we have everything we need to use this in our web app. Let’s create a simple test page which will be given a User object and determine if it can be deleted. Notice that it doesn’t need to have any awareness for which customer this code is being executed:

public class CustomerTestPage extends WebPage {
    @SpringBean private SiteFunctions siteFunctions;
    public CustomerTestPage() {        
        User u = new User();
        u.setActive(true);
        setMarkup(Markup.of("Can delete user: " + siteFunctions.canDeleteUserAccounts(u)));
    }
}

The key is to always reference our default SiteFunctions interface as opposed to the customer-specific overrides. Spring will take care of making sure the correct implementation is injected via the @SpringBean annotation.

In this case, the above code would return false because our default functionality says that an active user cannot be deleted. However, If we execute this application with the customer JVM parameter set to “FB”, it will return true.

The full source code can be found on GitHub.

Why you should favor composition over inheritance

Roman Sery — Tue, 10 Mar 2020 15:12:11 +0000

Composition has always had some advantages over inheritance. Creating deep inheritance hierarchies leads to brittle/inflexible code when you are trying to make changes deep in the hierarchy.

There have been two key improvements made to interfaces in Java 8 and above, that make the argument for composition even stronger:

Default methods - This allows you to define methods with a default implementation inside of interfaces. Classes that implement the interface can choose to override default methods or keep them as is.
Private/Static methods - In this way, it becomes easier to write default functionality for an interface using private helper methods that should not be exposed as part of the interface.

Let's look at an example where we can use composition along with the new functionality of interfaces.

Building a Human with composition

Let's create a class that will represent a biological human. We can imagine that a human being is composed of many different systems that work together in order for the human to function. There's the skeletal system, cardiovascular system, immune system, nervous system, and so on.

In this oversimplified example, we can think of each system as being an interface. Our human class will implement each of these interfaces:

Great! Now, what if we want to create a new biological organism that shares a lot of traits with humans, but doesn't have a skeletal system? This illustrates the major advantage of composition. We can do this by simply creating a new class that implements only 2 out of the 3 systems:

Using default and private methods

Now we can write a simple skeletal system interface and see how a human might implement it. We will demonstrate private and default interface methods, as well as interface fields:

public interface SkeletalSystem {
    List<Bone> bones = new ArrayList<>();
    List<Joint> joints = new ArrayList<>();

    abstract String getSex();

    default void addBone(Bone b) {
        bones.add(b);
        recalculateJointHealth();
    }

    default void addJoint(Joint j) {
        joints.add(j);
        recalculateJointHealth();
    }

    default int getBoneMass() {
        return bones.stream().map(Bone::getMass).reduce(0, Integer::sum);
    }

    private void recalculateJointHealth() {
        for(Joint j : joints) {
            //... do something
        }
    }

    public class Bone {
        private String name;
        private int mass;

        public Bone(String name, int mass) {
            this.name = name;
            this.mass = mass;
        }

        public int getMass() { return mass; }
        public void setMass(int mass) { this.mass = mass; }

        public String getName() { return name; }
        public void setName(String name) { this.name = name; }
    }

    public class Joint {
        private Bone b1;
        private Bone b2;
        private int strength;

        public Joint(Bone b1, Bone b2, int strength) {
            this.b1 = b1;
            this.b2 = b2;
            this.strength = strength;
        }

        public Bone getB1() { return b1; }
        public void setB1(Bone b1) { this.b1 = b1; }

        public Bone getB2() { return b2; }
        public void setB2(Bone b2) { this.b2 = b2; }

        public int getStrength() { return strength; }
        public void setStrength(int strength) { this.strength = strength; }
    }
}

For brevity, SkeletalSystem is presented as a fully self-contained interface. It defines the Bone and Joint classes and collections for storing them. There are default methods for adding bones and joints, as well as private helper methods.

public class Human implements SkeletalSystem {
    private final String sex;
    private int height;
    private int weight;

    public Human(String sex) {
        this.sex = sex;

        Bone lfemur = new Bone("LFemur", 50);
        Bone lHip = new Bone("lHip", 50);
        addBone(lfemur);
        addBone(lHip);

        addJoint(new Joint(lfemur, lHip, 100));

        System.out.println(getBoneMass());
    }

    public int getHeight() { return height; }
    public void setHeight(int height) { this.height = height; }

    public int getWeight() { return weight; }
    public void setWeight(int weight) { this.weight = weight; }

    @Override
    public String getSex() { return sex; }
}

Our Human class defines it's own data fields and uses the SkeletalSystem to add some bones and joints. We could also create helper methods that could initialize the SkeletalSystem using a standard human bone structure.

Conclusion

I hope this example will help you choose composition over inheritance when it's appropriate. Rember this basic rule when deciding:

Choose inheritance when modeling a "is-a" relationship.
- A senior citizen is a citizen.
- A standing desk is a desk.
Choose composition when modeling a "has-a" relationship.
- A human has a skeletal system, cardiovascular system, etc.
- A car has an engine, a transmission, gas tank, etc.

Creating a release info dashboard

Roman Sery — Thu, 13 Feb 2020 23:03:44 +0000

Hopefully, you are in the position of having an online software product/website with multiple clients. The problem you run into when deploying to multiple clients and environments is keeping track of which release is where. Let’s also assume that you have testing, stage, and production environments for each client; that quickly becomes a headache.

In this post, we look at how to create a simple dashboard for displaying this info. There are three basic steps:

Use the git-commit-id-plugin maven plugin in your project to output the brach and commit information to a file.
Create an HTTP endpoint for retrieving the deployed branch.
Create a page that will invoke these endpoints and display them in a table.

Creating git properties

The first step is to make our project create a file with the git repository info at build time. To accomplish this, we will use the git-commit-id-plugin plugin. Let’s add the plugin in our pom.xml file:

<plugins>
      <plugin>
        <groupId>pl.project13.maven</groupId>
        <artifactId>git-commit-id-plugin</artifactId>
        <version>4.0.0</version>
        <executions>
          <execution>
            <id>get-the-git-infos</id>
            <goals>
              <goal>revision</goal>
            </goals>
            <phase>initialize</phase>
          </execution>
        </executions>
        <configuration>
          <generateGitPropertiesFile>true</generateGitPropertiesFile>
          <generateGitPropertiesFilename>${project.build.outputDirectory}/git.properties</generateGitPropertiesFilename>
          <commitIdGenerationMode>full</commitIdGenerationMode>
          <format>properties</format>
        </configuration>
      </plugin>
</plugins>

When we do a maven build, a file named git.properties will be created that will have all of the information about the branch, build, and last commit info.

Creating the endpoint

The next step is to expose an HTTP endpoint in our application that will use git.properties to return the current git branch. We will use Wicket-rest annotations which is a great library for creating REST endpoints.

public class VersionDetailsEndpoints extends AbstractRestResource<JsonWebSerialDeserial> {
    public VersionDetailsEndpoints() {
        super(new JsonWebSerialDeserial(new JacksonObjectSerialDeserial()));
    }
    @MethodMapping(value = "/")
    public String details() {
        getCurrentWebResponse().addHeader("Access-Control-Allow-Origin", "*");
        return ApplicationDetailsService.getBranch();
    }
}

ApplicationDetailsService is a simple utility class that reads and parses the generated git.properties file from our maven build process. We also set the CORS header to allow invoking this endpoint using Javascript from a different domain as will be necessary for the last step.

We register it in our WebApplication init() method by mounting a resource:

mountResource("/releaseinfo", new ResourceReference("/releaseinfo") {            
    VersionDetailsEndpoints versionDetailsEndpoints = new VersionDetailsEndpoints();
    @Override
    public IResource getResource() {
    Injector.get().inject(versionDetailsEndpoints);
    return versionDetailsEndpoints;
    }
});

Creating the dashboard

Now the fun part! We will use the Javascript fetch API to iterate a map of clients and URL’s, invoking the /releaseinfo endpoint for each and populate a table with the results. The below code will go into the HEAD section of our HTML page:

let urlMap = {};
urlMap["ABC Corp"] = ["test.abc.com", "stage.abc.com", "abc.com"];
urlMap["Oracle"] = ["test.oracle-coderdreams.com", "stage.oracle-coderdreams.com", "oracle-coderdreams.com"];
urlMap["Microsoft"] = ["test.ms.com", "stage.ms.com", "ms-coderdreams.com"];

const clients = Object.keys(urlMap);

$(document).ready(function() {
  clients.forEach(function(client) {
    const clientId = client.replace(/ /g, "_");

    $("#releasesTable").append('<tr id="' + clientId + '"><td>' + client + "</td><td></td><td></td><td></td><td></td></tr>");

    urlMap[client].forEach(function(url, index) {
      if (url.length == 0) {
        return;
      }
      const tdNum = index + 2;
      const fullUrl = "http://" + url + "/releaseinfo";
      getReleaseBranch(fullUrl)
        .then(response => {
          $("#" + clientId + " td:nth-child(" + tdNum + ")").html(response);
        })
        .catch(e => {
          $("#" + clientId + " td:nth-child(" + tdNum + ")").html("ERR");
          $("#" + clientId + " td:nth-child(" + tdNum + ")").addClass("text-danger");
        });
    });
  });
});

async function getReleaseBranch(url) {
  let response = await fetch(url, { cache: "no-store" });
  return await response.json();
}

We need to make sure that the fetch call does not hit the browser cache which is done by passing the “no-store” argument. If we fail to get a response from the endpoint we highlight that in the table as an error.

You can also add other useful info to this dashboard such as database connectivity, the status of some ‘health’ check, number of active users; use your imagination!

The full dashboard code along with the HTML can be found on Github.

Five reasons you should use Apache Wicket

Roman Sery — Mon, 03 Feb 2020 02:16:49 +0000

Apache Wicket is a java-based web development framework. I feel it doesn't get as much attention as it deserves. I've been using Wicket professionally for real-world projects for the past 6 years and love it!

In this post, let's look at five reasons why you should consider using it.

1. Simple state management

The development experience writing Wicket apps is very similar to desktop development. At times you can almost forget about the stateless nature of HTTP. This is because in Wicket the web page and all of it's components (buttons, text fields, etc) are Java objects that maintain their own state. The state of the components gets serialized into the user's session, and deserialized at the appropriate times.

In simpler terms, suppose you have a form with fields that a user would fill out and submit. In a Wicket app, this form, it's fields, and the submit button are all components(Java objects) that are created and added to the web page. When the submit button is clicked:

We automatically have access to the user input, usually as fields of a POJO.
We don't have to connect the HTTP POST request to the GET request.
We also do not need to think about populating the form fields with the submitted values. This is done through Models which are a core Wicket concept.

2. Standard HTML integration

HTML in Wicket doesn't require any special tags unlike some other frameworks. In fact you can take any existing HTML and integrate it with your Wicket app with almost no changes. There is only one attribute that is needed to connect HTML tags to Wicket components: wicket:id Let's look at an example:

<div wicket:id="userName">Roman</div>

add(new Label("userName", getUsername()));

The wicket:id "userName" is used to connect the HTML element with the Wicket component. The Wicket Label component will get the user name and render a div tag. It's okay if this doesn't totally make sense right now. It becomes second nature and intuitive when you start playing around with it.

Wicket components are first-class citizens and can encapsulate their own HTML markup/CSS/JS just like in some popular frameworks such as React. Allowing us to create highly-reusable code.

3. No Javascript needed (mostly)

Okay obviously, you will end up writing JS code at some point. However the AJAX support provided by Wicket means you don't need to write your own JS code for most common tasks. Behind the scenes, Wicket uses JQuery and automatically generates the JS code into the web page.

Let's take a simple example of a page with a dropdown and various other components that depend on the selection of that dropdown. When the selection changes, we need to update these various other components on the page. This actually doesn't require any Javascript code.

This makes Wicket ideal for building complex interfaces with convoluted business logic.

4. Event/messaging system

Wicket events are a way for components and pages to communicate with each other. Using this feature we can create very complex, yet decoupled, component structures. A component can broadcast a message without needing to know who will receive the message. When a component is interested in a particular type of message, it can simply register to be notified when that message is broadcast.

A component might broadcast a critical update event with payload to all other components on the page in this manner:

send(getPage(), Broadcast.BREADTH, new CriticalUpdate(target, payload));

And if some component is interested in receiving CriticalUpdate's, it would register like this:

public void onEvent(IEvent<?> event) {
   if (event.getPayload() instanceof CriticalUpdate) {
      String msg = ((CriticalUpdate)event.getPayload());
      //do something with the msg
   }
}

5. Unit testing

The component/stateful nature of Wicket means that we can write unit tests for the front-end just like we would write them for the service layer, or our data access layer. Wicket provides helpful utilities to make writing unit tests simple.

Let's take an example of a simple scenario that might not be so straight forward to test in other frameworks. We have a web page with a CRUD interface: a table with baby names and delete buttons. A form with a text field and button for adding new rows to the table.

We can write a test that will render the page, simulate a user filling out and submitting the form, ensuring the table is updated correctly, simulate the user pressing the delete button, and so on. This can all be accomplished using pure Java code and JUnit without resorting to Selenium, Puppeteer or similar libraries.

6. Fully open source

Ok I did say five reasons, but here's a bonus: Wicket is fully open source and the code is designed to be easily extendable/customizable. Whenever you run into a scenario where the default behavior or functionality doesn't quite meet your needs, it's as simple as overriding a few methods, or extending a class to make it work exactly as you need!

Conclusion

I hope you've heard enough to give Wicket a try. If you're curious to learn more:

Head over to the official site which contains great documentation
Take a look the example code which provides code for many common web dev scenarios.
Take a look at my blog CoderDreams where I regularly post about Wicket and other web development topics.