Forem: Dylan Maccora

Valuable functional programming basics every developer should know

Dylan Maccora — Sun, 05 Sep 2021 15:44:38 +0000

For a long time there was an idealistic divide between functional and object oriented programming and this was manifested in the languages that came through. In the current landscape however you are spoilt for choice with languages and this divide is closing with a lot of the most popular languages available taking the best aspects of both paradigms. Kotlin is a great example of this where it is initially based on the JVM and follows OO principles with classes, etc but also introduces a lot of functional principles such as first class functions and the scary monad (I am no expert in this but there are a lot of easy to understand properties that you can make use of). Another example is Rust where it cannot easily be classified as either paradigm but uses functional elements such as using the Result type to promote functions always return a result, as well as object oriented notions such as the dot notation of functions on a type.

Monad Concepts

Monad is a term used a lot in functional programming and especially in the vast theory behind it. I did not wish to delve into such theory here but rather the useful functions that become available because we can treat some objects as a monad. Of particular interest is working with collections or streams of elements. The main reason I personally find these incredibly powerful is that they provide a common language for which we can describe the intention of common functions that can be combined together to achieve our end result. A lot of these functions you can use in place of a for loop so next time you are looking at iterating over a collection with a for loop consider if one of the following constructs are what you need.

`map`

The map function is a transformation of each element from type X to type Y. Depending on the language you are using this may modify the elements in place or create a new collection of the mapped values (in true functional style).

An easy example is say I have a collection of blog posts and I want to obtain the titles of all these, we can achieve this by:

val blogPosts: Collection<BlogPost> = listOf(BlogPost(title = "post 1"),
                                             BlogPost(title = "post 2"))
val blogPostTitles: Collection<String> = blogPosts.map { it.title } // ["post 1", "post 2"]
// Without the syntactic sugar
// val blogPostTitles: Collection<String> = blogPosts.map { post -> post.title }

Let's break this example down a bit to what is happening here. The map
function takes a function as a parameter which we will call our transform
function. This function maps the input type to some other type (this can the
same as the input type). The map function then iterates through the input list
and creates a new list applying this function to each element.

`flatMap`

The flatMap function is actually a combination of the above map function and the flatten function (not covered in this post). The flatten function takes a container of containers type and flattens it to just a container type.
This is quite abstract so lets take a simple example. Say you have a List<List<String>> and you want a List<String>, this in the broad sense what the flatten function does. In this example the container is the List type.

Knowing this it is quite simple to describe the flatMap function although it may still be difficult to wrap your head around in actual applications. The flatMap function will apply the transformation specified to the element in the
container and then flatten it. This is typically required when the transformation function returns the same type as the initial type.

As an example say we have a type that represents the books a customer has read and we want to print all of the books a group of customers have read (we are not concerned about duplicates). Such data may be present as:

data class BookCustomer(val booksRead: List<String>)

val bookCustomers: List<BookCustomer> = ...

The end type we are wanting is a List<String> containing all the book titles. Let us first try this without flatMap to aide in seeing when to consider using it.

val bookCustomers: List<BookCustomer> = ...

val booksRead: MutableList<String> = mutableListOf()

for (customer: BookCustomer in bookCustomers) {
  val booksTitles: List<String> = customer.booksRead
  booksRead.addAll(booksTitles)
}

The key thing that using these functional paradigms provides is built in immutability. In the above example we are needing to create a mutable list to get the result. We will see in the below version this is not required.

val bookCustomers: List<BookCustomer> = ...

val bookRead: List<String> = bookCustomers.flatMap { it.booksRead }

The transformation we are performing is mapping the BookCustomer to the list of book titles they have read, then the flatten part of flatMap handles to reduction of the list of lists into a single list. This leads us into the next section on reduce which is the general pattern of flatten.

`reduce` or `fold`

The reduce and fold functions are more general functions to reduce a container, typically a collection, to a singular value. A simple example we can explore is reducing a collection of integers to their sum.

Firstly, the difference between the two functions is primarily in the arguments that the functions take. The function signatures are below to make it simple to reference.

fun <T, R> Iterable<T>.fold(
    initial: R,
    operation: (acc: R, T) -> R
): R

fun <T, R> Iterable<T>.reduce(
    operation: (acc: R, T) -> R
): R

The primary difference between the two functions is that one takes the initial value of the resulting type and one does not. It instead uses the first value as the initial value. This subtle difference results in the reduce function requiring a non-empty collection to work on whereas fold can work on an empty list and just return the initial value.

A simple example to show how these functions work is by implementing a summation function that operates on a collection of integers.

fun sumReduce(input: Iterable<Int>): Int {
  input.reduce { acc, cur -> acc + cur }
}


fun sumFold(input: Iterable<Int>): Int {
  input.fold(0) { acc, cur -> acc + cur }
}

The interesting element of these is the closure passed of the form (acc: R, cur: T) -> R. This function is essentially and accumulation function that combines the elements of the collection to the final result. It takes two arguments:

acc which is the current accumulated result up to the current element
cur which is the current element

Putting this in action:

val numbers = listOf(1, 2, 3, 4, 5)

val sum: Int = sumFold(numbers)

The accumulation function is applied to each element and then the accumulated value is updated and passed along. Stepping through the above example would look like this:

Note this is for fold, if using reduce the first row would be omitted as there is no initial value

`acc`	`cur`	Accumulation function result
0	1	1
1	2	3
3	3	6
6	4	10
10	5	15

More use cases

The power of these functions is how flexible they are, any accumulator function can be provided allowing you to work with any type. If you were inclined you could spend more time studying functional programming and see how this is the basis of a lot of incredibly power combinator functions. For example we can create flatMap using reduce and map. Since this is typically handled in the standard library we will look at a more likely scenario to find in a project.

The example we will go through is that of some validation framework which leverages the following:

interface Validation {
  fun validate(input: Input): ValidationResult
}

enum class ValidationResult {
  VALID, INVALID
}

Imagine we have a collection of validators and we wish to implement some functionality that requires that all validators to run on the Input object and it returns VALID if all validators return VALID otherwise if even one returns INVALID it returns INVALID. The reduce function can do exactly this as we can evaluate all the validators and then reduce them to a single result.

val validators: List<Validation> = ...
val input: Input = ...

val result: ValidationResult = validators
                                  .reduce { acc, cur -> if(acc == ValidationResult.VALID) it.validate(input) else ValidationResult.INVALID }

`filter`

The filter function is another helpful function to work with collections which filters the collection based on a provided predicate. If the term predicate is new, it is simply a function that takes an input object and returns a boolean.

Using another book example let's assume we have the below data type for a book and we want to obtain the list of all books we read, this can be done as below:

data class Book(val title: String, val read: Boolean)

val books: List<Book> = ...

val booksRead: List<Book> = books.filter { it.read }

Not quite must knows

The above functions and types are extremely valuable in most modern languages. The below types are useful to know but depending on your language choice you may not actually use it but understanding the concept is valuable regardless as it can still have a positive impact on the way you write your code.

Option/Maybe Type

It is common to have to represent the possibility of some data not being present. Commonly in languages this is represented by some null value but in pure functional programming this is actually represented by a type possibly
called Option (such as in Rust) or Maybe (such as in Haskell). The core of this type is to be able to reflect the absence of a value in the type system. This can also be achieved with languages still supporting null such as Kotlin as it surfaces the nullability to the type level.

Having a container type to represent the absence of a value allows the client of the data to act on it safely without needing to check whether the data is present or not, which is something unable to be achieved with a basic null value alone.

let data = Some(2)
let no_data = None
let result_some = data.map(|x| x + 3) // Some(5)
let result_none = no_data.map(|x| + 3) // None

Result/Either Type

In an OO landscape it is typical to handle errors through exception handling. Pure functional languages require this to be represented in the type system, which is quite a powerful model. This is again named differently depending on the language but it is a container type that has two possible representations. If it is called Either then this will have a Left and Right type, this is more generic than the Result type as you are able to represent any arbitrary
type that is a union of two possible types. A more focused point is the Result type used in Rust to represent explicitly an error as it does not have exceptions. The two types of this union are Ok and Err (for error).

Again this notion of a type may not be largely applicable in the OO domain but it does promote you to think of handling errors and state in a different manner and representing this in the type system. This concept can easily be implemented
in Kotlin using sealed classes and does not need to just be used for error handling but can be used to create any container class that a client can act on. Again the goal here is having the container class allows the client to work with
the data irrespective of the underlying state.

Deploying your first Micronaut application to Heroku

Dylan Maccora — Sat, 11 Jul 2020 21:27:55 +0000

Micronaut is a great JVM framework I was recently introduced to. It has been designed with the intention to fit into the modern day micro-service and serverless architecture with its big selling point being compile time dependency injection. If you have ever used something like Spring Boot you will know what a difference this will make to start up times. However this post is about deploying these apps to Heroku. Once I have had some more experience in the framework I will write another post about making an application with it. In lieu of that, I would really recommend giving it a try and reach out if you have any blockers.

For this post I am assuming you are familiar with Heroku as I won't go in depth about setting it up. However that is the beauty of this service is they make it really simple to get started which is great for hobby projects.

Creating the Application

Creating the app is very simple as with many frameworks. Micronaut provide a CLI tool and a guide for creating your first application using this. Again I won't go more in depth into this but it is very important to follow this guide otherwise your experience may differ and likely be more difficult.

The important part of using the CLI tool is that is generates the base project and along with that is provides the Dockerfile that can be used to build a deployed image. It is a very simple Dockerfile but just highlights the focus on simplicity in the modern environments provided by Micronaut.

First Attempt to deploy to Heroku

My first attempt as the naming of this sections forebodes was not all that successful and led to a few weird issues. Let's start at the beginning.

Choosing Heroku as the service to manage my deployments was primarily driven by simplicity. To deploy my first app was as simple as git push heroku master (after some minimal set up of course). This application should be no different I thought, it is a Gradle application and Heroku natively supports with this a Gradle build pack. Unfortunately not quite so, they know how to support Spring applications but if none is detected you are in charge of telling the build pack how to build your application. Which is a good choice and again is made simple by enforcing a convention.

If Heroku does not how to build your application you define a stage Gradle task

Of course I am not the first person to deploy a non-Spring application to Heroku so there is a simple guide. For a Micronaut application the only required part however is defining the stage task and its dependencies.

task stage(dependsOn: ['build', 'clean'])
build.mustRunAfter clean

That was pretty simple!

Now if you were anything like me and just want to get your application out there you would try to deploy this shortly after. In doing this I started to find where most of my issues lay. After the deployment I attempted to check the health endpoint and was receiving a fat nothing, my first thoughts were, 'Does it know how to run my application?'

Defining the Procfile

For those unfamiliar with Heroku, they have a notion of a Procfile which defines which commands to run to start your application(s). Akin to that you would write for a build pipeline.

First thing I thought here is I know I was able to run my application through Gradle using the run command so let's first try that.

web: ./gradlew run

Immediately I deployed again and tested the health endpoint. Same result...

Finding the Error

It turned out the error was staring me in the face the whole time in the deployment logs that I clearly do not pay the required attention to. When you perform the git deployment you don't actually get all the logs of the container you will need to use heroku logs --tail to get these, and they are incredibly useful!

Littered throughout the logs I had occurrences of Error R14 (Memory quota exceeded). Not only that, it did not only appear during the execution of the application but actually when trying to build the application!

Now of course I could purchase the plan providing me with more memory but this was a hobby project. Further that is almost always the cheat's way out as there is probably something better you can do before just upping allocated resources.

The reason for this issue I can only assume is because of the manner in which Micronaut builds your application. A lot of the heavy lifting is done during compile time giving you super fast start up times. However I was now pushing all this load onto the Heroku containers for which I had limited resources for.

Getting the Application Deployed

After realising I would need to perform the staging on my local machine I started looking at different methods of deploying to Heroku. As it turns out they provide you access to a container registry for which you can push images and then release them for your application.

The process to deploy a container is as follows:

Define your deployable image
Build the artifacts needed for the image and consequently build the deployable image
Push the deployable image to the registry
Release the image to the deployed environment

This process is made extremely simple by Micronaut and Heroku! I was able to script it in 3 lines!

./gradlew stage
heroku container:push web
heroku container:release web

These define the last 3 steps of the process above but where is our image definition? It is the Dockerfile that Micronaut generated for us on the first build!

FROM openjdk:8u171-alpine3.7
RUN apk --no-cache add curl
COPY build/libs/*-all.jar myapp-kt.jar
CMD java ${JAVA_OPTS} -jar myapp-kt.jar

All this Dockerfile does is simply copy the built artifact from the stage task (which is combined into a single JAR ending in -all).

Finally we just need to update the Procfile as we do not need to build anything anymore, but rather just need to simply execute the JAR. Of course be aware there is a version appended.

web: java -jar build/libs/myapp-kt-0.1-all.jar

Once you have updated the Procfile, deploy to Heroku again and you should find your application up and running!

Summary

To recap what we managed to achieve. We built our Micronaut application following the provided guide. Then utilizing what was provided from the template built a deployable Docker image which could then deploy to Heroku!

Speed up your Gitlab pipelines to Heroku

Dylan Maccora — Sat, 11 Jul 2020 21:24:25 +0000

Arguably one of the best things one can have for their project is a robust continuous delivery
pipeline. Being able to know that once you commit and push your code there is infrastructure in
place to ensure your change is correct and subsequently deployed is one the things I personally
truly enjoy in software. So when I had some spare time I started tinkering with one of my side
projects in getting it set up and deployed to Heroku. My project is hosted at Gitlab which have
their own integrated CI service and is deployed to Heroku a platform as a service (PaaS) provider
which manages a lot of the deployment infrastructure for me, perfect for a side project.

For this project I had set up the following stages:

Definitely a little more involved than most of my side projects but hopefully it actually closer
represents would you would typically encounter for production services in the industry.

The application I had was a Kotlin web server application built with Gradle and deployed to
Heroku using a very versatile deployment tool dpl. All of this definitely worked and did what it
needed to however it took around 17 minutes and there are always things we can improve!

Using a cache

Gitlab CI runners are declaratively defined and based on Docker containers. Each job executed in
the pipeline you will get an entirely fresh environment which is great to provide a reproducible
environment but this does require the environment to be recreated every time. In the case of Gradle
and the Gradle wrapper this means that on each stage of the pipeline that was using a Gradle task it
would need to download the distribution.

To avoid needing to download this at each job we can simply add in a cache in our pipeline. This
cache is saved at the end of each job and restored at the start, so it does come with its own cost
but compared to downloading Gradle and all project dependencies it is minor. To achieve this for my
Gradle project I simply changed the directory for where Gradle saved the dependencies and told
Gitlab CI to cache it, with a lot of help from this StackOverflow question.

before_script:
  - export GRADLE_USER_HOME=`pwd`/.gradle

cache:
  paths:
    - .gradle/wrapper
    - .gradle/caches

Do note that with this configuration your cache will be persisted and restored across all jobs
(assuming you have not placed this in a single job already) so if not all stages require this cache
we could adjust this to shave off some extra time but for now it will do just fine.

Deploying with Docker to Heroku directly

The change that gave me the biggest improvement was by converting my deployment from using the dpl
tool to using the container registry Heroku provides.

The speed of deployment is less attributed to the dpl tool and more towards how Heroku defaults its
deployments. If you look across all of the Heroku website it shows how simple it is to perform
deployments with git. This is definitely a positive for simplicity of deployment but in doing so it
means that each deployment needs to be built from source each time. Using the registry we are able
to create an immutable, deployable Docker image that we can reuse at each stage of deployment.

First thing you will require is that your application builds to a Docker image, which I will not
delve into here (maybe another post). My application was actually already being deployed through
Docker with dpl by using the heroku.yml file, so my Docker image was ready to go.

With a deployable Docker image ready the next step is to add a build and publish step to our
pipeline. For those not familiar with publishing Docker images, you can consider Docker images akin
to a release of a library/dependency. These are published to some central registry with a specific
identifier and version, the same is done for Docker images. We can publish a specific application
and version to a registry, here it is hosted by Heroku others include ECR (AWS) or of course
DockerHub, which is then fetched and deployed. Coming back now let's add this build and publish
step to our pipeline, firstly lets define some variables:

variables:
  CONTAINER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
  PREPROD_APP_NAME: my-pre-prod-app
  PROD_APP_NAME: my-prod-app

These variables will simply make it easy to reference the identifier given to our container image
using some variables that Gitlab will populate for us as well as the names of
our Heroku applications. With these in place we can now create a build step, I have added this to my
test stage so the tests and build can run in parallel.

build:
  image: docker:19.03.1
  services:
    - docker:19.03.1-dind
  stage: test
  variables:
    HEROKU_PREPROD_IMAGE: registry.heroku.com/${PREPROD_APP_NAME}/web
    HEROKU_PROD_IMAGE: registry.heroku.com/${PROD_APP_NAME}/web
  script:
    - docker login --username=_ --password=$HEROKU_API_KEY registry.heroku.com
    - docker build -t $CONTAINER_TEST_IMAGE .
    - docker tag $CONTAINER_TEST_IMAGE $HEROKU_PREPROD_IMAGE
    - docker push $HEROKU_PREPROD_IMAGE
    - docker tag $CONTAINER_TEST_IMAGE $HEROKU_PROD_IMAGE
    - docker push $HEROKU_PROD_IMAGE

The above follows from the example provided in the Gitlab documentation with
some tweaks to target the Heroku container registry instead of the Gitlab one. In Heroku each
application has its own container registry, since each stage is its own application we need to push
the built image to both registries.

The one new variable here is the HEROKU_API_KEY which I have injected into the pipeline. This is
the API token that is generated by Heroku to allow access to the API, this can be accessed in your
Heroku account settings.

With the image built and pushed to the Heroku container repository we can now move onto the final
stage which is the actual deployment to Heroku.

preprod:
  stage: preprod
  script:
    - apt-get update -qy
    - apt-get install -y curl bash
    - curl https://cli-assets.heroku.com/install.sh | sh
    - heroku container:release -a ${PREPROD_APP_NAME} web
  only:
    - master

The only way to perform the deployment is through the Heroku CLI therefore the first step here
(after obtaining dependencies) is to download the CLI. We can then simply perform the
container:release operation which will deploy the most recent version of our built application
from the container registry. The same step can be done for the production stage by simply changing
the app name variable.

Using this technique over dpl the deployment time went down from around 5 minutes to around 1.5
minutes for each deployment! Reducing this deployment time is extremely valuable to allow for the
ability to roll forward with continuous deployment pipelines, as well as a great excuse to learn
something new!

Completed file

The completed pipeline file looks something like this:

stages:
  - test
  - preprod
  - integration_test
  - prod

before_script:
  - export GRADLE_USER_HOME=`pwd`/.gradle

cache:
  paths:
    - .gradle/wrapper
    - .gradle/caches

variables:
  CONTAINER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
  PREPROD_APP_NAME: my-pre-prod-app
  PROD_APP_NAME: my-prod-app

build:
  image: docker:19.03.1
  services:
    - docker:19.03.1-dind
  stage: test
  variables:
    HEROKU_PREPROD_IMAGE: registry.heroku.com/${PREPROD_APP_NAME}/web
    HEROKU_PROD_IMAGE: registry.heroku.com/${PROD_APP_NAME}/web
  script:
    - docker login --username=_ --password=$HEROKU_API_KEY registry.heroku.com
    - docker build -t $CONTAINER_TEST_IMAGE .
    - docker tag $CONTAINER_TEST_IMAGE $HEROKU_PREPROD_IMAGE
    - docker push $HEROKU_PREPROD_IMAGE
    - docker tag $CONTAINER_TEST_IMAGE $HEROKU_PROD_IMAGE
    - docker push $HEROKU_PROD_IMAGE

test:
  stage: test
  # Test step...

preprod:
  stage: preprod
  script:
    - apt-get update -qy
    - apt-get install -y curl bash
    - curl https://cli-assets.heroku.com/install.sh | sh
    - heroku container:release -a ${PREPROD_APP_NAME} web
  only:
    - master

integration:
  stage: "integration_test"
  # Integration step...

production:
  stage: prod
  script:
    - apt-get update -qy
    - apt-get install -y curl bash
    - curl https://cli-assets.heroku.com/install.sh | sh
    - heroku container:release -a ${PROD_APP_NAME} web

How was I so wrong about CI and what I learnt about CD

Dylan Maccora — Sat, 11 Jul 2020 20:56:35 +0000

My knowledge of Continuous Integration (CI) and Continuous Delivery (CD) had so far only been developed from discussions with colleges and my own assumptions on the topic. Only recently had I decided that I should actually put this knowledge to the test and started doing some reading. To my surprise I was well off...

Continuous Integration

First off I started looking into CI, you know the build machines and stuff yeah? Nope. Continuous Integration is exactly as its name describes, continuously integrating your code. For some unknown reason to me I had understood CI as the build pipeline getting kicked off every time someone makes a commit to the repository. In a way this isn't ridiculously off as this pipeline provides the means for CI but is not it itself. After watching a talk by Martin Fowler he described CI in such a raw, upfront manner that it has really stuck with me. I paraphrase but he states something along the lines of;

If you can answer yes to the following 3 questions, then indeed you **are* practicing continuous integration:*

Are all engineers pushing to trunk/master on a daily basis?
Does every commit run a solid suite of tests giving confidence the commit works?
When the build is broken, is it typically fixed in under 10 minutes?

This is pretty far from a build pipeline tool right?

So what we are saying here is that CI is the practice of continually integrating developer's code in the repository, daily. That is, there is no never ending feature branches and no 'sub-master' branch that we all merge into before we go to our actual master, nope. Everything needs to be integrated and on the master branch. Period. I have definitely witnessed teams not practicing CI and seeing how things can gradually diverge over time and then when finally ready, bringing them all back together becomes feature work in of itself!

Next up, we are saying, cool you are all integrating but does the software still do what it is meant to? The easiest way to get peace of mind for this is a solid suite of tests. Now we are all well familiar with unit tests but through my readings I was introduced to so many different types of tests, all of which play a different role in building our confidence in our software. If you are interested in looking further into it have a read of this article by Atlassian. So what we really want here is a suite of tests, not only unit tests, that is kicked off every time some one delivers and definitely every time some on commits to the master branch.

The final question is directed more at the culture developed, than the actual practice. I feel that it is depicting the importance of the master branch. The notion of, if it fails, you drop everything and get that baby back to green! To achieve this there has to be a culture shift, as well as confidence in your build pipeline. The last thing you want is developers not thinking twice about a failed build because 'everyone knows this test is flaky'. If it is flaky and you can do something about it, fix that up, regain some confidence in your pipeline and get that pipeline to a strong green.

Continuous Delivery vs Continuous Deployment

The two CD's were a lot newer to my vocabulary than the wrongly understood CI, so I approached these with less of a tainted mind. Again Martin Fowler covered these topics in his talk. There is so much to talk about regarding these topics and it is really fascinating if you get the chance to read further into them but here I just wanted to look at what exactly is the difference?

Firstly I want to say that I am by no means an expert in regards to these but just want to share what I thought was a really simple explanation on differentiating the two. Both of these notions revolve around very similar concepts and both have similar end goals. They are looking at being able to get quality software out the door in an automated, reproducible manner, and of course, quickly. One of the biggest pre-requisites is to have an automated pipeline, script where you can, define your pipeline in source code, get everything moving with as little human interaction as possible! Once this is done we can look into getting the software into environments of closer parity to the production environment than our local development machine, again ideally in an automated manner. This is all so we can gain confidence that the release will work as well as be certain that it is done in the same manner every time.

So at this point we haven't really said much about what is the actual difference between delivery and deployment. Well that is because up until now there kind of isn't much of a difference. However when we get to the final stage delivering the software into production that is where it differs. Continuous Delivery is having the ability to deliver the current master at any given moment, Continuous Deployment is actually doing just that for every commit. You can see how the two can be easily confused, further how continuous delivery is sort of a requirement for continuous deployment.

Actually implementing these practices can have some unexpected side effects as I have seen. Applying only continuous delivery, teams had no problem practicing continuous integration as they had their master branch raring and ready, but only deployed when it was required. Whereas those practicing continuous deployment actually gravitated away from the continuous integration definition given earlier as they started having these sub-master branches so that they could be confident in their software before it was delivered to production. However I am sure this all depends on the scenario and what your team has in place, I am certainly not saying continuous deployment is bad as I am sure the big tech companies have definitely made this work well for them. Give it a go and see what works best for your team.

Why you no longer need feature branches

Dylan Maccora — Sat, 04 Jul 2020 21:50:28 +0000

The core of what software engineers do is add new and improved features to a service or application. We add a feature the customer requested or address some technical debt. Some of these features can take hours to complete whilst others weeks. All the while you are part of a whole team working on numerous features at once, so the question comes how do merge all these features together once they are ready?

Feature Branches

One such option is to use feature branches, of the popular workflow Gitflow, where a new branch is forked off the main branch and all feature development completed on this branch. The branch is then merged back on when the feature is completed. The benefit here is the isolation from the main branch so it is not disturbed with a half complete feature. It also means that as each feature is completed the merge request only needs to focus on the feature being merged and is independent from any other features that are being worked on in parallel.

There are some points of concern here. If you are the lucky or unlucky one, your choice, working on the larger feature then you are constantly needing to merge changes from the main branch as each new smaller feature, bug fix, or any work is committed. This adds a fair bit of churn to this workflow as the developer on this larger feature will be going back and forth between solving merge conflicts and implementing the feature.

This then extends the time it takes for the feature to be completed, leading to the second concern that we end up having long lived feature branches and we start to lose continuous integration. The longer a feature branch lives the more it diverges and the greater the risk of the merge. One way we can definitely improve this is the feature definition process to make these as small as possible but that is separate from the point of this article.

Enter Feature Toggles

As continuous delivery has become a more prevalent concept other solutions have developed working on getting these features out as quickly as possible. What this has resulted in is the notion of feature toggles.

Feature toggles at its simplest can be thought of as a switch. It is either off or on. This switch controls whether or not the feature is off or on in our application. Feature toggles have greater functionality than this but let's explore the benefits before we delve into those.

A major benefit with feature toggles is its enabling of main branch development, continuous integration just got a whole lot easier. How do we do this? When we start work on our new feature first thing we do is create a feature toggle and wrap our changes in a conditional on the state of the toggle.

if (featureToggleService.isLaunched("NEW_HEADER") {
    addHeader(document)
}

By doing this it means that we can implement the feature over several commits but since the feature toggle is off in production our new feature code isn't activate in production. This also means that the changes become smaller meaning those merge conflicts should be less and less.

The biggest benefit is the separation of feature work completion and feature launch. With the feature branch model it wouldn't be unheard of to block the deployment to production or block the merge to the main branch until business, product, or testing team are ready for the launch. This can lead to several problematic circumstances, we have a big bang deployment to production containing a lot of changes so if something does go wrong it is harder to pinpoint the exact issue, or in the case the branch isn't merged the developers have to keep this feature branch up to date well after the feature work has been completed. Feature toggles on the other hand allow us to push our code out to production even when it is incomplete. Once the work is completed we can then hand control over to the interested team who is able to be responsible for launching that feature by simply flicking the switch. Decoupling the code completion to the feature launch entirely.

Another element is the safety lever feature toggles provide. In the feature branch model we need to revert all commits and push it through the pipeline if an issues was found. For the feature toggle it is yet again a simple flick of the switch. Not only is there less time and risk in this "roll back" but it can also be controlled by anyone responsible for the feature and not just the engineering team.

Other functionalities of feature toggles

Hopefully I have been able to show the benefit of feature toggles however the above is not the only benefits we get.

Feature toggles can typically be dialed up progressively, meaning we are able to test it on a smaller audience to see if all goes well prior to everyone getting the change. An example being we could give the new feature to 10% of the customer base, then after an hour move to 50%, etc. Giving even more confidence when launching these features.

We can also usually override the controls for a feature toggle. That is if the testing team want to test the change for a certain test customer or the UX team want to test how actual customers interact with the change this can be done without affecting all customers.

Depending on which feature toggle service you use there may be even more options available, or you might find your company already has one you can improve.

Some Feature Toggle Services

Below are a few of the feature toggle services I have heard of:

There are plenty more just have a search for "feature toggle service", it is also sometimes called "feature flag"

Object construction validation in Kotlin

Dylan Maccora — Thu, 02 Jul 2020 03:01:10 +0000

Recently I was working with a bit of code where we had written validation logic in the constructor. This was simply validating that the input received from an API call matched what we required. We are currently migrating some of the code across from Java to Kotlin and whilst most of the time this is a straightforward process this validation one wasn't so smooth.

Let's say you have a FullName class that requires both a first and last name that cannot be empty. We might have a class something like the following:

public class FullName {
  private final String firstName;
  private final String lastName;

  public FullName(final String firstName, final String lastName) {
    if (StringUtils.isBlank(firstName) || StringUtils.isBlank(lastName)) {
      throw new InvalidDataException("Names must not be blank");
    }
    this.firstName = firstName;
    this.lastName = lastName;
  }
  // getters...
}

We want to move this across to a new FullName Kotlin class instead, below are some of the options we managed create. Each have different styles and benefits so it is up to you which you prefer.

For these examples I am assuming that firstName and lastName didn't have to add a null check. If this is not the case for you simply change the type to a nullable type and perform the check using safe calls or similar. Do this so that you do not get an exception throw from the standard library which is essentially a null pointer exception.

Using an `init` block

class FullName(firstName: String, lastName: String) {
    val firstName: String
    val lastName: String
    init {
        if (firstName.isBlank() || lastName.isBlank()) {
            throw RuntimeException("Name cannot be blank")
        }
        this.firstName = firstName
        this.lastName = lastName
    }
}

Try this in the playground

Pros

This has the same interface as the previous Java class so all calling code should fit nicely

Cons

We haven't been able to convert to a data class where it may have been similar to one in Java. This is because a data class requires a public field being present in the primary constructor. This can easily be overcome by using your IDE to generate the equals/hashcode and toString functions you may have wanted.

Use a static constructor

Using static constructors is a recommended practice as per Effective Java, so one alternative is to put the validation logic into such a function so the class becomes simple. In our above I believe it was done in the way above to match the Spring MVC convention.

data class FullName private constructor(val firstName: String, val lastName: String) {

    companion object {
        fun of(firstName: String, lastName: String): FullName {
            if(firstName.isBlank() || lastName.isBlank()) {
                throw RuntimeException("Name cannot be blank")
            }
            return FullName(firstName, lastName)
        }
    }
}

Try this in the playground

Pros

We are now able to use the data class
The class itself doesn't have a 'smart' constructor
We are able to make all construction through the static method using private constructor

Cons

We have now changed the signature of the class for the callers of the existing class

Using `Invoke` to get both

I have not been able to test how this works with Java interoperability but this option will give you the best of the above two solutions.

data class FullName private constructor(val firstName: String, val lastName: String) {

    companion object {
        operator fun invoke(firstName: String, lastName: String): FullName {
            if(firstName.isBlank() || lastName.isBlank()) {
                throw RuntimeException("Name cannot be blank")
            }
            return FullName(firstName, lastName)
        }
    }
}

Try this in the playground

Exploring how to use the Law of Demeter

Dylan Maccora — Sun, 28 Jun 2020 23:21:42 +0000

First and foremost I should define exactly what the Law of Demeter is. The Law of Demeter is a design principle of object orientated software, which is also known as the principle of least knowledge. The essence of the principle is that your code should only know about the classes it is directly dealing with and should not be overreaching into classes that those classes know. As with all design principles this is quite intellectual and is difficult to translate to the code we write day to day. Personally I try and find concrete patterns for these that I can use to check if I am either infringing or obeying the principle. The Law of Demeter has a pretty easy check if you are disobeying it:

If you see a chain of calls (several dots) on a single line you are most likely violating the Law of Demeter

A concrete example of this is something like

boolean isGmailAccount = account.getProfile()
                                .getEmail()
                                .endsWith("gmail.com");

As you can see here our code has access to some Account class but this class also knows the internals of the Account class that is used to determine if it is a Gmail account. Checking against our rule you can easily see it violates the rule as there are 3 dots for chained calls and 2 of those are accessing different classes.

I want to make a quick note here that as per every rule there are exemptions. The key part of the above code is the call chain is accessing different underlying classes. This means that our code goes from only knowing about the Account class to now also knowing about the Profile and Email class. Said differently it means that our code is now coupled to the Profile and Email class and even their implementation. An example where there is a call chain but no extended class access is easily seen when using combinators on Streams in Java

List<MovieTitle> movieTitles = movies.stream()
                                     .filter(Objects::notNull)
                                     .map(Movie::getTitle)
                                     .collect(toList());

Example

I am going to do a quick example where we work for a bank and we want to send an email to a customer about our new deal if that customer has a checking account with the bank.

This diagram is intentionally limited to not distract from the key elements.

These class all seem like we can represent these as plain data objects, they contain some values and we just create a whole bunch of getters. This was exactly my typical approach as I thought "I don't need my data classes to be very smart". So then to implement our requirement above we may need to write some code like this:

public void sendPromoEmail(Customer customer) {
  boolean shouldSendPromoEmail = customer.getAccounts()
                                         .stream()
                                         .filter(x -> x.getType() == AccountType.CHECKING)
                                         .findFirst()
                                         .isPresent();
  if (shouldSendPromoEmail) {
    // Build promo message ...
    emailService.sendEmail(customer.getEmail(), promoMessage);
  }
}

This definitely does seem to do the job and we meet the requirements but if you look carefully this function doesn't quite satisfy the Law of Demeter. This function only knows about (or is coupled with) the Customer class. However because we choose to model our data with simple getters we need our function to know what is inside a Customer. This function is now coupled with how the Customer models the Accounts it has and is also coupled with the representation of the AccountType of Account. This coupling is quite subtle and will typically go unnoticed, I am not even needing to import the Account class for this to work!

The root of the problem here is that we chose to use dumb data classes that simply store data. I am not saying these don't work in all cases but I would urge you to consider if by doing so you end up in the same situation we are in here.

To remove this unneeded coupling we will need the data classes to now tell us more about themselves rather than us ask about it.

First thing we could do is change the Account class to tell us if it is a checking account.

class Account {
  private final AccountType type;
  // ...
  public boolean isCheckingAccount() {
    return type == AccountType.CHECKING;
  }
}

Then our function becomes:

public void sendPromoEmail(Customer customer) {
  boolean shouldSendPromoEmail = customer.getAccounts()
                                         .stream()
                                         .filter(Account::isCheckingAccount)
                                         .findFirst()
                                         .isPresent();
  if (shouldSendPromoEmail) {
    // Build promo message ...
    emailService.sendEmail(customer.getEmail(), promoMessage);
  }
}

Trust me I know this looks odd and what about all the other account types, does that mean we need to expand the Account interface for all of this? We may, but only if we ever use them of course. This encapsulation is a trade off as everything is. By creating this method the AccountType can be encapsulated withing the Account class, which means if we were ever change the representation or interface it would now only be the Account class we need to update. We don't need to go back to our sendPromoEmail function or any others that may be doing the same!

We have now removed the coupling with the AccountType and the next to remove is the Account. To do this we will follow the same pattern but one up the chain. We now want the Customer class to tell us if it has a checking account rather than us ask for its internals.

class Customer {
  private final List<Account> accounts;
  // ...
  public boolean hasCheckingAccount() {
    return accounts.stream()
                   .filter(Account::isCheckingAccount)
                   .findFirst()
                   .isPresent();
  }
}

Then our function becomes:

public void sendPromoEmail(Customer customer) {
  boolean shouldSendPromoEmail = customer.hasCheckingAccount();
  if (shouldSendPromoEmail) {
    // Build promo message ...
    emailService.sendEmail(customer.getEmail(), promoMessage);
  }
}

There we have it, we have removed the Account coupling in our function and it only knows about the Customer class and its interface. Now any changes to the Account class never reach this method and can ideally all be handled in the Customer class.

Intro to TDD Basics

Dylan Maccora — Sun, 28 Jun 2020 22:36:11 +0000

TDD is definitely quite the polarizing topic in my experience, whilst not everyone may agree with it I believe it is always valuable to understand it and develop your own opinion on it.

TDD stands for Test Driven Development and was made made popular by Kent Beck. It is an option of development process that we as software engineers can consider. A wispy way to describe it that instead of the typical practice of writing tests after production code your write it up front. I don't know about you but when I was first introduced to this I thought it was pretty crazy. Let's explore it a little further are there is more to it than simply writing your tests first.

The TDD Cycle

A core part of TDD is the TDD cycle. This is a fairly simple cycle and it dictates the exact development cycle one should take when implementing TDD.

Write test - Write code - Refactor

The scope of this cycle is to whatever you define your unit of test. In the object orientated world this will typically match to your class and your unit tests for said class. Let's delve into each of these steps before heading into an example.

This cycle is also known as the Red-Green-Green cycle representing the state of the tests at each stage.

Write Test

First and foremost, you write a test for the behavior that you expect of the class. Most importantly you expect this to be a failing test. Here of course remember that a compilation error is also a failing test. This test just needs to describe one piece of functionality and fail so that we can implement it and make it pass in the next stage of the cycle.

Write Code

Now that we have a failing test that describes a piece of functionality we implement that functionality. The interesting part here, and where most people struggle to adopt TDD is that your implementation should be as minimal as possible. That is, your implementation should only make your tests pass and nothing more. The purpose of this is to drive implementation details to be as simple as possible, attempting to remove as much unintentional complexity as possible. It is very common at the end of this step to be looking at your code and not being very impressed, but stick with it because we will get there.

This stage is complete once we have an implementation that makes all existing, and new tests being written green (or passing).

Refactor

This is the time where we look at our code and we can make it something that we are proud of. Apply all the refactoring tools from your toolbox but make sure after every refactor you run all your tests and they all stay green. There is not much more to it, there may various different changes to make but it will all depend on the situation.

Once we have completed this step and all our tests are green now would be a good time to commit (small and often). Then we start the cycle again by adding in a new test and continue.

Give It a Try

There is whole lot more that we can delve into for TDD practices and reasons as to why it is good but this post is simply to give an introduction to the topic. We will try give a better understanding with a basic example of a much loved Fizz Buzz program.

To give a quick recap of the problem so you don't have to search it up, the Fizz Buzz problem is given a number and returns fizz if it is divisible by 3 and buzz if it is divisible by 5. If it is both we return fizz buzz, otherwise return the number.

The example I will show is written in Kotlin for something a little different and we will only look on the function level, just for those looking for the constructor that never was. Also I won't be using any fancy test framework just good old fashioned JUnit.

Let's write our first test then, when we give our function 1 we expect it to return 1.

@Test
fun `when 1 should return 1`() {
    assertEquals("1", fizzBuzz(1)) // Compilation error
}

First and foremost this test will have a compilation error which is indeed a failing test because we do not have the function yet written. Whilst this is not a good example, the compilation error step is important because it allows us to consider the API that we want to define. This is because the Fizz Buzz problem has a clear input and output but you can imagine when you create a new class you can use this as a chance to consider API options.

Now we move into the write code phase. First thing we do is get it compiling and passing.

fun fizzBuzz(num: Int): String {
    return "1"
}

This is exactly the time when you need to fight the urge to try and over complicate this as this perfectly matches the requirements of the cycle. The tests we have written pass and that is that. Since we don't have much code here, there isn't much to refactor so let's commit and move to our next step.

@Test
fun `when 2 should return 2`() {
    assertEquals("2", fizzBuzz(2))
}

Moving back to the implementation stage we see it starts get a bit weird but we follow the TDD rules of only implementing enough to satisfy the tests to pass.

fun fizzBuzz(num: Int): String {
    return if (num == 1) "1"
    else "2"
}

Now we can refactor this a little here, keeping the tests green and then commit again before we start writing our next test.

fun fizzBuzz(num: Int): String {
    return num.toString()
}

Now we encounter a different case, so let's write a test for it.

@Test
fun `when 3 should return fizz`() {
    assertEquals("fizz", fizzBuzz(3))
}

Back to the implementation step we go!

fun fizzBuzz(num: Int): String {
    return if (num == 3) "fizz"
    else num.toString()
}

Again you can clearly say, hey this won't consider all other cases! Yet again we are only considering making the current tests pass. However you may start to see that this could possibly take a lot longer than the traditional method of implement followed by test, which is definitely a common argument against TDD and in this case it definitely shows.

In my opinion that is because the speed of TDD here can be improved by defining tests based on expected behavior, rather than for this case just incrementing the input (particularly since not all of our problems will take a simple integer). So let's do exactly that, let's consider the case where it is divisible by 5.

@Test
fun `when 5 should return buzz`() {
    assertEquals("buzz", fizzBuzz(5))
}

Hopefully you can see this test will obviously be failing so let's make it pass.

fun fizzBuzz(num: Int): String {
    return if (num == 3) "fizz"
    else if (num == 5) "buzz"
    else num.toString()
}

We are almost there we have a few more behaviors we want to check, these are:

A number divisible by 3 but not 3
A number divisible by 5 but not 5
A number divisible by both 3 and 5

So let's quickly iterate through these as hopefully by now you have the basic idea. For brevity I will collapse all the tests into a single code block but these would have been added and then implemented one at a time. The implementation blocks I will separate though to make it clear.

@Test
fun `when num is divisible by 3 should return fizz`() {
    assertEquals("fizz", fizzBuzz(9))
}

@Test
fun `when num is divisible by 5 should return buzz`() {
    assertEquals("buzz", fizzBuzz(10))
}

@Test
fun `when num is divisible by 3 and 5 should return fizzbuzz`() {
    assertEquals("fizzbuzz", fizzBuzz(15))
}

Now to the implementation. After testing for divisible by 3.

fun fizzBuzz(num: Int): String {
    return if (num % 3) "fizz"
    else if (num == 5) "buzz"
    else num.toString()
}

Divisible by 5.

fun fizzBuzz(num: Int): String {
    return if (num % 3) "fizz"
    else if (num % 5) "buzz"
    else num.toString()
}

Divisible by both 3 and 5.

fun fizzBuzz(num: Int): String {
    return if (num % 3 && num % 5) "fizzbuzz"
    else if (num % 3) "fizz"
    else if (num % 5) "buzz"
    else num.toString()
}

Now of course you can then refactor this however best suits your needs (I would prefer braces here, maybe consider using a when statement, etc). Then there you have it, we have just implemented fizz buzz by TDD.

Isn't this a bit much?

As I mentioned before one of the biggest deterrents I have heard around is that this procedure can be so strict and slow down development cycle. Honestly this is definitely true at first but of course you are learning something entirely new, you don't expect to be incredibly effective in a brand new programming language when you first start, so why expect much different when learning a new process?

TDD is a new mindset as well as process so it definitely does take time. To top it off it does some with some very strict rules making you think just joined the military! This is exactly why for me personally I haven't been able to integrate the explicit procedure in my working process, however I still believe there is a lot of value to TDD.

For me personally I really like the aspect of having to think of the behavior upfront rather than implementation, which is always a great thing to be focusing on in testing. However sometimes I need to play around with API ideas and test out some possible implementations which may or may not work. This is where I have found TDD a bit harder to utilize.

Overall there are some great takeaways from TDD and it is up to you how much or little you buy into it and use it.

Wrapping it up

Something I hope you take away from this introduction of TDD is that it is a process with more to it than just writing some tests upfront. There is a nice little cycle (Test-Implement-Refactor) to guide you through the whole process which has some great goals. It allows you to think about the behavior of your system rather than its implementation, making it easier to test and maintain. By only implementing enough to get it to pass it provides a framework to reduce incidental complexity. As well as always providing you a chance to look and consider any refactoring once each cycle, which is much better than having to perform it at a larger scale.

We don't really need those setters

Dylan Maccora — Sun, 24 May 2020 20:22:46 +0000

Mutability in terms of software usually will describe the ability to change the internal state of an object once it has been created. Many main design decisions on frameworks and conventions favored having mutable objects and didn't really touch on the concept of immutability. The clearest example of this is the POJO concept in Java, or more specifically the notion of getters and setters.

The Notion of Getters and Setters

I will take a short tangent for those not familiar but if you are please skip ahead.

In a typical Java object you will encapsulate fields by making them private and unable to be directly accessed. The access to these internal fields are usually protected by getters and setters, which simply get the current value and update the field respectively. A basic example for getting and setting the name of a person can be seen below.

public class Person {
    private String name;

    public String getName() {
        return name;
    }

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

Why the Change of Mind?

So if we made all these decisions in languages and frameworks that are now so popular why should I even need to know this? Well this may be a little bleak but in software just because something is popular unfortunately does not mean it is good or right. I would almost argue that it is very hard to find something good in software because designs can be so subjective and things simply move so fast that we can suddenly do things that we couldn't do when our first decisions were made.

My favorite comparison is comparing older languages to more modern languages. A simple example is Java vs Kotlin. Whilst these both live in a similar realm of the language space I don't believe you can justly compare them as they both came from different times when we knew different things. Java is much older than Kotlin, which was a language specifically designed to bake in all the Java best practices into a language. The fact that we can make an entirely new language with the goal to simply enforce best practices is a clear sign that as an industry we discover new and better things arguably daily.

Immutability is now part of the language

In this example one of the things that Kotlin has added that Java didn't have (at least when Kotlin first came out) was the notion of immutability. In Java (and many other languages of the time) the notion of immutability is not as evident. It has the final keyword to enforce variables are set only once but it is an extra keyword always needed to be added and certainly not what you learn in most beginner courses. Whereas more modern languages have introduced separate keywords for a mutable and immutable variable. This makes the thought about this variable's mutability far more apparent.

Let us take a really basic example of getting a result back from a method invocation. In Java I can simply make the types line up and we are good to go. I can almost forget about the mutability question because it isn't required at all. In fact this happens a lot for me so I have actions performed on save to add the final keywords for me.

String result = myObject.invoke();

But if I want it immutable I need to remember my final keyword:

final String result = myObject.invoke();

Whereas in Kotlin, thanks to advances in what we can achieve within the compiler the notion of making the types line up is not as important and the developer's responsibility is to choose the correct keyword to define the mutability of the result.

If the result is to be immutable

val result = myObject.invoke()

If the result is to be mutable

var result = myObject.invoke()

As you can see from this example, the notion of immutability has become more prevalent in the developers decisions. To the point where the compiler can tell you that the mutable variable you made could actually be mutable.

Mutability can bite

So we have explored how the notion of mutability is now brought closer to front in terms of our development, but still have not answered why? The answer is pretty simple, making everything mutable and not addressing that upfront led to a large cognitive load for developers and with that bugs will follow. The issue is embedded in the fact that it lead to objects having vast amounts of way of changing state. The more possible states an object could be in the harder it is to reason with and that is what happened.

An immutable object is one that is set at construction and has no way in which it is able to change afterwards. Of course this does come with a few issues you need to keep track of and I will discuss those later. The main point I want to express here is that mutability can cause difficult to manage code and we should be aware of our decision to use mutable or immutable objects.

Converting to Immutable Objects

So we have hinted at why you might want to try immutability but how can you do it? Every language has its own way to manage immutability and the extent to which you can achieve immutability. We will stick with Java for the time being. Let's return to the person example before but make it a little more interesting. Let's say the person has a name and a phone number and we want to make it a basic immutable object. It would look something like this:

public final class Person {
    private final String name;
    private final String phoneNumber;

    public Person(String name, String phoneNumber) {
        this.name = name;
        this.phoneNumber = phoneNumber;
    }

    public String getName() {
        return name;
    }

    public String getPhoneNumber() {
        return phoneNumber;
    }
}

The key points to note:

Whilst not exactly data immutable, having the final class means that the class is immutable and cannot be extended
private final variables ensure they are set once and only available within the class scope
There are no setters, only getters

Not Everything is Perfectly Immutable

Whilst the above example is the closest we can get to perfect immutable in Java there are some things to consider with these, since Java as a language chose mutability as the default.

One of the biggest confusions is that following those steps above is all you need for it to be immutable but let us consider an extension on the example. Let's say that this person object now needs to cater for multiple phone numbers and my naive implementation is to do this by using a list.
Perhaps it could look something like the following:

public final class Person {
    private final String name;
    private final List<String> phoneNumbers;

    public Person(String name, List<String> phoneNumbers) {
        this.name = name;
        this.phoneNumbers = phoneNumbers;
    }

    public String getName() {
        return name;
    }

    public List<String> getPhoneNumbers() {
        return phoneNumbers;
    }
}

Now this looks pretty good, all our data is only set once and we only have getters. The problem here is that a List is not an immutable object whereas it just so happened in our earlier example String was. Let's delve a little deeper into how immutability breaks here.

The client code for the above Person class could look something like this:

List<String> numbers = person.getPhoneNumbers();
numbers.add("555444333");

Despite the poor choice of example phone number there is also something else concerning here, the client is modifying the list of phone numbers. Now sure enough because the Person class returns the reference to their internal field this is going to modify the state of the original person object.

Let's have a look at what I mean by that (the comments on the right show the value printed)

Person person = new Person("Frank", new ArrayList<>());

System.out.println(person.getPhoneNumbers().size()); // 0

List<String> numbers = person.getPhoneNumbers();
numbers.add("555444333");

System.out.println(person.getPhoneNumbers().size()); // 1

So even without any setters we can see that we have still actually written an interface that allows mutability, but we really want this to be an immutable object so how can we do this? Unfortunately this does involve a little bit of work in Java but certainly does give us the immutability benefits so if it is what you are working for then definitely the cost is worth it.

The general practice is you need to return the value not the reference. For a list this is by making a copy of the list and returning that.

Warning: Making a shallow copy may not always be enough, if the contained object is not immutable then a deep copy is necessary.

Things to be aware of with Immutability

Nothing is a silver bullet and immutability certainly has some caveats to be aware of, here are a few obvious ones:

If the type returned from the getters is not immutable itself, then your class has just become mutable. (Refer to above section)
Java does support reflection so people can get fancy with this.
A lot of frameworks have been built based on mutability so can be difficult to integrate
Can create many copies of objects which can be costly

The last one is particularly important and one of the main reasons immutability wasn't popular earlier. Having pure immutable objects means that you need different copies for every possible value which can consume a lot of your memory resources. Obviously we have a lot more memory we can use nowadays but that does not mean we can disregard this limitation. When making objects immutable consider this, particularly when needing to perform deep copies as these are certainly not free.

Benefits of Immutable Objects

Finally, why am I writing about this, why tell people to aim for immutability where possible? Quite simply it makes me think less. In our profession as counter intuitive as that may sound I find it is a big influencer because there will always be other difficult things wanting your attention.

If you have immutable objects you do not need to worry about shared state and who is modifying what. This particularly becomes useful in concurrency. You can share as many immutable objects between thread as you want and you won't have to worry about landing in a corrupt state because you cannot modify the state of the object but only create a new one.

For the simplicity it has added to my development I would definitely recommend choosing immutable as your standard and then consciously making the decision to make your classes mutable. This has even become a standard for programming languages themselves, Rust is an example of such a language.

Regardless of if you agree or not on the value of immutability, I urge you to at least consider the mutability facet of a class when you are designing and not let it be an after thought because the language you develop in doesn't accentuate it.

Why would I even use dependency injection?

Dylan Maccora — Mon, 18 May 2020 02:54:17 +0000

I was inspired to write this post and hopefully a little series on some of these key concepts of
software as I was asked "Why would I need to use dependency injection?". This brought me back to
when I was first learning these industry staples that you never get taught learning computer
science. Due to this I was hoping to write a little series around my learning experiences and
understanding of these concepts because I have always found the more perspectives you get the easier
it is to form your own understanding. This is the first one for the series so let's see how far we
can go.

What is Dependency Injection?

Alright now that the little preamble is over with lets start out like any good problem solver and
define the What of the problem. According to our good friends at Wikipedia we define dependency
injection as:

In software engineering, dependency injection is a technique whereby one object supplies the
dependencies of another object.

Wikipedia

So this is pretty good and correct, assuming you understand the concept to begin with. So let's try
break it down a bit.

I first learnt this with Java, so one simple trick to think of dependency injection is moving all of
the new keywords out of your classes. Now this is a pretty dumb thing to say because something
obviously has to instantiate your classes and that is entirely correct but the point of dependency
injection is to create that separation between where your classes and their dependencies are
instantiated and where you write the fun problem solving logic. So the concept of dependency
injection is being able to give your classes their dependencies rather than you class
instantiating its own dependencies. A term you will hear a lot around this topic is Inversion of
Control (IOC). You are now giving control of what your classes dependencies are to a class higher up
the chain.

Don't worry there is a lot of writing here and my description is arguably confusing in itself but I
will clarify this with some examples soon! So stick with me!

How do I use Dependency Injection?

There are a lot of fancy frameworks that you can use for dependency injection, no matter what
language you develop in. However I have no intention of showing how to use those frameworks because
if you want to learn you should practice it on the bare metal. I always enjoy getting my hands dirty
with this (as much as they can typing on a keyboard) because I find that to be the best way to
understand, making the mistakes and finding the answers.

Saying that let's get onto our example. Since I am not feeling incredibly creative today I am going
to take the classic shopping cart example. Our task is to make a shopping cart class that will allow
our customers to buy some items. The code below is one possible way of doing this (although please
don't use this to implement an actual shopping cart).

public class ShoppingCart {
    private CreditCard creditCard;
    private LineItems items;

    public ShoppingCart(long creditCardNumber, List<Product> products) {
        creditCard = new CreditCard(creditCardNumber);
        items = new LineItems(products);
    }

    public void placeOrder() {
        creditCard.charge(items.total());
    }
}

So as you can see this shopping cart implementation needs to have a CreditCard to charge and some
LineItems to define how much to charge. Therefore it is pretty easy to see that the dependencies of
ShoppingCart are CreditCard and LineItems. A pretty easy way to see this in Java is they will
be fields of the class, you really only define a field if you need to use it perform some tasks.

However there are new keywords here so you can see the dependencies are not injected into
ShoppingCart, rather ShoppingCart knows exactly how to create its dependencies. It knows it
needs a credit card number and a list of products. In fact this is exactly why dependency
injection is important because it means your class does not need to know how to create its
dependencies but only how to use its dependencies. Instead of providing the parameters to
construct the dependencies we should have instead provided the dependencies themselves and
constructed those elsewhere, perhaps like this:

public class ShoppingCart {
    private CreditCard creditCard;
    private LineItems items;

    public ShoppingCart(CreditCard creditCard, LineItems items) {
        this.creditCard = creditCard;
        this.items = items;
    }

    public void placeOrder() {
        creditCard.charge(items.total());
    }
}

So we can now create it elsewhere

public class Factory {
    public ShoppingCart shoppingCart(long creditCardNumber, List<Product> products) {
        return new ShoppingCart(new CreditCard(creditCardNumber), new LineItems(products));
    }
}

Now we have separated our creation code from our domain logic code. In doing this it has provided us
dependency injection as you can see our ShoppingCart no longer has any new keywords!

Why Dependency Injection?

The most obvious question now is, "Why would I do that? That looks like more code!". This is indeed
correct we do have more code but the number of lines you have written is never a sole indicator of
the quality of the code. Instead what you should be looking at is "Has this made it easier for me to
change the code as requirements change?" or "Is this code easily testable?". Making our code use
dependency injection has allowed us to say yes on both of those fronts.

Changing with Requirements or Design

The biggest achievement we have made is we are now able to develop to an interface. That is,
ShoppingCart doesn't need to know anything about how CreditCard or LineItems work under the
hood, or if they are even concrete classes. All it needs to know is that it can call charge and
total on them respectively. Therefore if we only supported one type of credit card and we needed
to add another one, so long as it implements charge for the CreditCard interface our
ShoppingCart need not change.

In a different direction, if the design of LineItems were to change and it needed something
different to construct itself, our ShoppingCart is now unaffected. The only place it needs to
change is where we create it.

Testability

Something else that dependency injection has aided with is making tests easier to write. If we had
of kept it the old way, testing ShoppingCart would be near impossible without needing to charge an
actual credit card. To avoid this we would need to use reflection to inject a mock and capture all
the interactions, doable but more complicated than it need be. Now we can simply make a test double
that looks like a CreditCard and then capture the interactions on that.

Finishing Up

Hopefully through this very basic example you can see how you can use dependency injection in your
current work as well as how it is helpful. As with a lot of these practices it is hard to see the
benefit in the small scale but once your system grows and the number of moving parts increases its
value becomes apparent.

Forem: Dylan Maccora

Valuable functional programming basics every developer should know

Monad Concepts

map

flatMap

reduce or fold

More use cases

filter

Not quite must knows

Option/Maybe Type

Result/Either Type

Deploying your first Micronaut application to Heroku

Creating the Application

First Attempt to deploy to Heroku

Defining the Procfile

Finding the Error

Getting the Application Deployed

Summary

Speed up your Gitlab pipelines to Heroku

Using a cache

Deploying with Docker to Heroku directly

Completed file

How was I so wrong about CI and what I learnt about CD

Continuous Integration

Continuous Delivery vs Continuous Deployment

Why you no longer need feature branches

Feature Branches

Enter Feature Toggles

Other functionalities of feature toggles

Some Feature Toggle Services

Object construction validation in Kotlin

Using an init block

Pros

Cons

Use a static constructor

Pros

Cons

Using Invoke to get both

Exploring how to use the Law of Demeter

Example

Intro to TDD Basics

The TDD Cycle

Write Test

Write Code

Refactor

Give It a Try

Isn't this a bit much?

Wrapping it up

We don't really need those setters

The Notion of Getters and Setters

Why the Change of Mind?

Immutability is now part of the language

Mutability can bite

Converting to Immutable Objects

Not Everything is Perfectly Immutable

Things to be aware of with Immutability

Benefits of Immutable Objects

Why would I even use dependency injection?

What is Dependency Injection?

How do I use Dependency Injection?

Why Dependency Injection?

Changing with Requirements or Design

Testability

Finishing Up

`map`

`flatMap`

`reduce` or `fold`

`filter`

Using an `init` block

Using `Invoke` to get both