Forem: IT Minds

Legacy code: Why it happens and how to handle it

Christoffer Bjerge — Wed, 01 Mar 2023 14:33:22 +0000

Legacy or just old?

Ask five developers for a definition of legacy code, and you’ll get six different answers. We all have different opinions on what constitutes legacy code, but most can agree on this: it's old code still in use, and it's hard to work with.

We could spend a lot more time trying to define it, but smarter people than me have done that more eloquently than I could, so I'll link some good articles at the end for further reading. They also go into more depth than me, so I recommend checking them out after this.

However you want to define it, we all know it when we see it, and nobody likes working on legacy code.

Why does code become legacy?

So.. If everyone can recognize it, and nobody likes working on it, why does it happen? Well, a few things: feature bloat, tech debt, time and lack of testing are the main culprits. So, taking them one at a time...

Time

This is kind of the big one of the group that often leads directly or indirectly to the other points. Legacy code is also old code which could mean a few things in my experience:

Current fundamentals like Entity Framework or web frameworks were maybe not available or widely adopted at the time, which resulted in custom-made or outdated/deprecated solutions we have to adapt to and basically learn from scratch.
The original developers were likely used to working in a totally different paradigm which means it can look either odd or illogical to our modern sensibilities.
Inertia - The longer a product is in use the harder it becomes to make meaningfully large changes, making it easier to focus on things in the short-term like:

Just one more feature

When a product is successful for many years, it will inevitably gain more and more features along the road because features drive sales/profits/etc.
This means that the older the product, the more stacked (bloated) with features it might become. This is great in the short term because each feature makes the product more marketable, but if not planned correctly this will make the codebase more and more unmanageable.

Tech debt

Another thing that will often happen over time is tech debt. The reality of creating any kind of product is the need to drive sales which means features like I mentioned above, but this and tight deadlines will often mean neglecting what doesn't directly drive sales: maintenance.
On a vehicle, this means changing the oil, checking the tires or the like, but for a codebase this means refactoring, updating to newer versions, actually going back over the quick fixes and to-dos that will accumulate over time and so on. All of these things don't affect profitability in a noticeable way in the short term, but in the long run it is what makes a codebase become unmaintainable and eventually legacy.

Lack of tests

We know we should all write more and better tests (check out this article on writing good tests by one of my colleagues), but often it's something we'll postpone for some other day. When lack of testing becomes a year's long worth of lack, it can be hard to know what breaks when we have to make changes to the code.

So.. How do we handle it?

I am by no means an expert in this subject, but I will give my two cents on what I have experienced to be effective and necessary when working with legacy code and especially when you're coming in from outside as a consultant or new hire.

Long or short term

My perspective is going to be influenced by my position as a consultant and is therefore on a limited scope and timeframe, but if a codebase has reached the legacy stage, it will usually be necessary in the long term to eventually rewrite it using best practices from scratch.

Communication and estimation

Working on legacy code is difficult, but one of the things I have found most difficult when working on legacy code is estimation which is sometimes more of an art than a science - and with legacy code it is always more challenging.
The answer to this is cliché for a reason: communication. Be open and up front about your estimates, and don't be afraid to readjust when you run into problems.

Leave it better than you found it

When adding functionality to a class that is already 8000 lines long and when the if-statement is already nested several levels beyond what is comfortable, it's tempting to think oh well, what's another few lines.
But, that's just making the problem slightly worse for next time / the next developer. You should always try to leave it slightly better than you found it - if there isn't enough time to do a proper refactor of the class/whatever you're working in, you should at least not make it worse.

Code style

This may mostly be relevant for developers in a consultant role like myself, but I'm including it still because I think it's important.
When working on - and especially adding to - legacy code, it's tempting to rewrite older code completely in a much more efficient style. And I'm not saying you shouldn't do this, but I think it's very important to keep in mind who else will be working on the code. What I mean is that you should be looking for a good middle ground between something you can be proud of doing and something that isn't too foreign to developers used to working in older code.
You can either try to document and comment your code in such a sufficient manner that the next developer knows how to handle your code, or you can try to adapt to the existing code style. This again comes down to the above point of communication: Talk to your lead/fellow developers etc., and figure out the best solution.

In the end, it doesn't matter how clever your improvements are, as they are useless if the next developer to look at it won't know what they're looking at. Like making a speech, you have to know your audience and adjust your choice of words accordingly.

To sum up

Legacy status is almost inevitable for any product over time unless it is actively avoided and planned for.
Communication is key - legacy is difficult to work with and estimating tasks for legacy doubly so. Make sure to communicate any problems, questions or ideas you have along the way.
Don't take the easy way out - try to leave it better than you found it, otherwise you're just making the problem worse for the next person.
The code you add or change will have to be understood and expanded upon by other developers - adjust accordingly.

Below are a few good articles both defining legacy code and going more in depth with handling legacy code - among other things the best ways to implement testing.

Is Lottie a Hottie? Going Through the Basics of the Great Tiny Animation Format that is Lottie-files

Carsten Eliasen — Wed, 01 Jun 2022 09:08:35 +0000

Vectorized animations and 3.000 times smaller than a GIF? That sounds almost utopian. However, the Lottie-file (or, simply a Lottie) is a reality, and for me as a UX Designer, it allows me to create custom animations that can easily be implemented in code.

In this blogpost, I am going to explore which building blocks we can use in order to build a bridge between UX and development. Lottie-files might be only one example of a such building block, but all bricks are important when building a strong foundation. Moreover, although I am writing about this subject as a designer, it is equally as relevant for developers.

So, what is Lottie?

Lottie is a JSON-based format that makes it easy for me as a designer to export my custom animations without losing any quality, while maintaining full scalability.
It makes animations easy to implement, and nice-to-have elements like these could easily become need-to-have in the future as it adds dynamic and gamification aspects, which might not only enhance User Experience, but also Developer Experience as well.

What do developers think of Lottie?

Seeing as I am not a developer myself, I thought it wise to ask one of my friends, who is a Tech Lead at IT Minds, what he thinks of Lottie as he has worked with it on an internal project.

In general, he's a big fan of Lottie, among other things, because it's easy to work with both as a developer and as a designer. The only downside is the bundle size:

"It's easy for both developer and designer, but it comes at the expense of bundle size and performance. So it works best when you are working with more complex animations"

So, how easy is it?

Luckily for this blog post, I have a great deal of friends at IT Minds. As a trial run, I asked one of our software developers, Stefan, to give it a go at implementing a Lottie-animation in a React environment. This is what he said about the experience:

"As someone who had not worked with Lotties before, it was a very easy and straight-forward process to implement them in a new or existing project. The Lottie-React library had fine tools for using and customizing the Lotties for specific scenarios and interactions."

Is it easy for a UX designer to make the animations?

Some of the questions I have been asked from my developer-colleagues revolves around whether it is easy for me to make these animations. The truth is that you need some experience in Adobe Illustrator and Aftereffects, but apart from that it really is quite easy.
These are the 'simple' steps you have to go through, when making an animation:

1) Design an icon, such as the one below, in Illustrator
2) Import it into Aftereffects, and create the animation
3) Export the animation as a JSON-file, by using a plugin called Bodymovin

Below you can see an example of a gif of an animation I have made on the basis of these steps. You can see the Lottie-file right here

Is Lottie a Hottie?

My conclusion is yes! I have not yet talked to anyone who can see any major downsides. Easy implementable animations makes the design – and development experience - better even if they only constitute one of the many bricks on the bridge between design and development.

A Beginner's Guide to Penetration Testing (Part 2)

Hjalte Abelskov — Wed, 04 May 2022 11:23:20 +0000

Hey everyone! I’m back at it with another blogpost about information-security or, more specifically, penetration testing.

This blogpost constitutes the second part in my series on penetration testing. If you are not familiar with penetration testing in general, I highly recommend checking out my first post above where I go over penetration testing methodology and show you some tools that can be useful when enumerating a target.

To finish off this mini series on penetration testing, my blogpost today will go over a target from HackTheBox. To be more precise, we'll be looking at one of their retired boxes named Blocky.

For those of you who are new to HackTheBox, think of it as a big hacking playground with lots of targets varying in difficulty. For every target out there, you need to first gain a foothold and then escalate your privileges.

Two .txt files exist on the target, and your goal is to submit the contents of both. The first .txt file is named user.txt, and submitting that will prove to HackTheBox that you’ve achieved foothold. The second .txt file is named root.txt (even on Windows), and submitting that will prove to HackTheBox that you’ve achieved escalated privileges, a.k.a root privileges (Administrator for Windows).

The foothold flag is usually the hardest to obtain, or at least the one that requires the most steps, since it requires combing through lots of information about the services running on the server. I have intentionally not included some of the dead ends I ran into while doing this box.

Step 1: Foothold

We are given the following IP-address: 10.10.10.37
First thing I did was to run an nmap scan to see which services are running on the target. I specified -sV for versions and -p- for all ports. -oN tells nmap to output in “nmap format” to the specified file.

Here we see ftp, ssh, http and a minecraft server.
Let’s go ahead and visit the website.

It looks like a blog of some sort. Some might recognize that it resembles the standard Twenty Seventeen Wordpress theme. To find out more, I started a subdirectory-scan with Gobuster while continuing to explore the site manually. Here, I specified -u for url and -w for wordlist.

Looking at the source code, network traffic, etc. did not yield anything particularly useful, but eventually my Gobuster scan finished and showed me the following information:

Aha! Here, we see a bunch of sites with 403 (Forbidden) and some 301s (Redirects/Hits).
Also, we see /phpmyadmin and /plugins as well as some wordpress sites.
We can navigate to phpmyadmin and try some default credentials, such as root:root, admin:admin, root:admin etc.
We don’t get a hit, and since we don’t know any users, we are unable to progress much further in this direction right now.

However, there is a great tool for Wordpress sites called wpscan. It automatically looks through posts, authors, themes, assets etc. to spot anything vulnerable or out of the ordinary.

By running a command such as wpscan --url http://10.10.10.37/ --enumerate u, we find a user named notch.

Meanwhile, if we visit /plugins we see two .jar files.

I downloaded the first one, BlockyCore.jar, and unzipped it to find a BlockyCore.class file. Using a Java decompiler, I was able to read the contents.

Looks like we found some credentials!
We now have two users: root and notch.
Going back to the website, we can visit the /phpmyadmin endpoint and try logging in.

It worked! We now have access to phpMyAdmin and can view the underlying database.

Usually, when gaining access to admin panels, you want to look for ways to upload files, read credentials, update permissions and such. Since phpmyadmin is using SQL, we can query the database and such. We can try uploading a webshell, which would allow us to execute commands on the server. The following command takes an input and writes it to /phpmyadmin/cmd.php (assuming the folder exists under /var/www/).

SELECT "<?php if($_GET['cmd']) {system($_GET['cmd']);} ?>" INTO OUTFILE '/var/www/phpMyAdmin/cmd.php
We are denied access though. But it was worth a shot.

So far so good…

Okay, so where are we with all the gathered information? Well, we have obtained two usernames and a password from diving into port 80. We were able to log into phpmyadmin but unable to run any SQL queries from there.

However, a common scenario when dealing with lazy developers is the reuse of passwords. Don’t do this, people. Get a password manager and generate a new unique password every time, please.
Anyhow, once we get credentials, it is usually a good idea to look for other services where we could try those credentials as well.

Let’s remind ourselves what the other services were:
Our nmap scan showed us that the services running were ftp, ssh, http and minecraft.

We try using the notch username with the password from before on the ftp server and manage to successfully log in.
Here, we see the user.txt file. We can use the “get” command to download files over ftp.

And we are rewarded with our first flag! Foothold achieved!

Step 2: Privilege Escalation

With the SAME notch credentials used for FTP, I was also able to SSH into the box.

One of the first things to enumerate, when looking to escalate privileges on a system, is which rights you have as a user. Are you able to run some commands with elevated privileges?
An easy way to see this on Linux is to run sudo -l which will list all your sudo rights.
Here, we see that we may run (ALL: ALL) ALL. This means we can run any command as the superuser.

This makes for a very easy win with sudo su root. Enter the credentials for notch and bam! We’re root.
We can see the root.txt file, readable by our user.

And that is both of the proofs we need to submit to gain full points on the box!

Were you able to follow along and understand everything that happened there?
Let’s quickly recap the steps we took:

We scanned the site with nmap
On port 80, we found a website and performed a subdirectory-listing scan with Gobuster
We saw Wordpress files and used wpscan to find a user named notch
In the /plugins folder, we found a .jar file with some credentials
We tried reusing the credentials on the other services (foothold)
We were able to SSH into the box
With sudo -l we listed our privileges and saw that we could run any command as root
We switched to root user with the sudo su root command which gave us root flag

Alright, that wraps up my second post and this series on penetration testing!
This post was a bit longer and a bit more technical than the first post, but translating theoretical knowledge into practical usage is often what helps you truly understand something new.
I hope you learned something from this mini series on penetration testing - or at least enjoyed the reading :-) Feel free to post your questions below!

A Beginner's Guide to Penetration Testing (Part 1)

Hjalte Abelskov — Thu, 21 Apr 2022 11:52:13 +0000

Disclaimer:

Before we start, I feel the need to write a short disclaimer: remember that these are real hacking tools that should never be used without a formal agreement in place between the parties involved. These posts are meant to be a teaser with the goal of giving you, the reader, a sense of what penetration testing is and what to be aware of when building your applications.

What is a pentest?

A pentest is essentially a simulated cyberattack on a computer system with the purpose of evaluating the security of the system. A pentest can be whitebox, meaning that the attacker has access to background and system information, or blackbox, meaning that the attacker has little or no information about the system.

Why do we pentest?

The UK National Cyber Security Center describes pentesting as

A method for gaining assurance in the security of an IT system by attempting to breach some or all of that system’s security, using the same tools and techniques as an adversary might

Let me start by going over some quick glossary to ensure that we are all on the same page:

Target: A target is typically a single IP address, but could also be a range of IP addresses.
Port: A communication endpoint for the computer, numbered between 0-65535. Ports can be either:
- OPEN (If you send a SYN, you get back a SYN/ACK)
- UNFILTERED (The special ACK scan, used for mapping firewall rule sets, can sometimes return RST. This means that the port is accessible, but we can’t determine if it is open or closed).
- FILTERED (Target is behind some sort of firewall and packets get dropped / no response)
- CLOSED (When you send a SYN, it responds back with a RST).
CVE: Short for “Common Vulnerabilities and Exposures”. This is a method of indexing and referencing publicly known software vulnerabilities. There are roughly between 15,000 - 20,000 new CVEs reported each year.

Phases of a pentest

You should know that there are 5 phases to professional pentesting, namely

Planning
Scanning
Gaining Access
Persistent Access
Reporting

In this post, however, I want to focus mainly on phase 2 and 3 since that's where the exciting stuff happens.

2. Scanning

When we scan a target, we are looking for information about which operating system and software might be running on the computer. Scanning for open ports tells us how the target can be interacted with, which often lets us infer a lot of information about the target. This is typically done with a tool called nmap.

A scan could look like the following:

Here we see two open ports, namely port 22 (ssh) and port 80 (http). This indicates that the target is probably hosting one or more websites and has SSH access enabled for remote configuration. We can see it is running OpenSSH 7.4 and the website is Apache httpd 2.4.25. From this information alone, we may start looking for well-known vulnerabilities, also known as CVEs. Mitre has a CVE database (https://cve.mitre.org/) we can look in. A website such as https://www.exploit-db.com/ even goes as far as to provide working code exploits for a lot of known CVEs.

On a different scan we might find a Domain Controller in an Active Directory which would be indicated by ports 53 (dns), 88 (kerberos), 135 (msrpc), 139 (netbios-ssn), 389 (ldap), 445 (file replication service), 464 (kerberos password change), 3268 and 3269 (ldap) being open.

Remember: Scanning the target and enumerating the attack vectors that come to mind is an iterative process and should be done continuously throughout the pentest.

After our initial port scan, we might do more scans depending on what we find. In order to be as effective as possible, and to gather as much information as possible, pentesters are often running multiple scans simultaneously on a target. There are hundreds of tools out there for every service imaginable. Some of the tools worth mentioning are wpscan (https://wpscan.com/wordpress-security-scanner) for Wordpress sites or sqlmap (https://sqlmap.org/) for automatic SQL injection. For a more extensive list of tools check out https://0xcybery.github.io/ehtk/ or https://github.com/enaqx/awesome-pentest

3. Gaining access

This step will vary a lot based on the results of the second phase, but let’s assume a very common case: we see a website on port 80/443.
First, we want to identify which technologies are being used. For this, there are several tools, but we can also poke at it manually.

We could try to..

Read the source code
See if we get a hit on a well-known endpoint such as /wp-content/ for Wordpress, /user/login/ for Drupal, or /manager/html for Tomcat.
Inspect the server responses and look for technologies used. This will sometimes also yield version numbers which makes it easy to look for existing exploits.

If we’re lazy we can use tools such as Nikto, WhatWeb, BuiltWith or Wappalyzer that will analyze which technologies are being used by the website for us.

We can also use tools such as Gobuster to scan websites for subpages.
Gobuster has a ton of features, but we will be using the url parameter and provide it with a wordlist of words to search for. Operating systems such as Kali Linux or ParrotOS come pre-installed with wordlists, but there are plenty of useful wordlists on Github we can use - check out https://github.com/danielmiessler/SecLists. An example of this could be:
Gobuster -u https://site-we-want-to-scan/ -w /path/to/wordlist -t threads -o gobuster_scan_from_website_root

An output could look something like this:

If our wordlist is well-chosen, we now have a good overview of the site, and we can continue our attack based on what we find. As mentioned earlier, enumeration is a continuous process.

With this new information, we could try a gobuster scan on https://site-we-want-to-scan/images, https://site-we-want-to-scan/uploads or https://site-we-want-to-scan/assets to gain more information about which artifacts exist on the site.

Well, this wraps up my first post on penetration testing!
Thank you for reading!
In the next post, I will get more hands-on as I walk you through how I hacked a target from the famous website HackTheBox.

Improve Your Deep Learning Models with Image Augmentation

Tord Kvifte — Wed, 06 Apr 2022 06:17:55 +0000

Computer vision with deep convolutional neural networks has seen a boom during recent years, and it is now applied in everything from computer-aided medical diagnosis to Unmanned Aerial Vehicles, Augmented Reality and visual search engines. Despite the amazing capabilities of modern deep learning techniques, certain challenges remain, such as getting enough data. One of the remedies is data augmentation. In this blog post, I will briefly explain a handful of data augmentation techniques in image recognition and show some examples of how to easily implement these with the Albumentations library.

Data Augmentation - What is it good for?

One major issue is that the performance of deep learning models is highly dependent on the amount of data available for training. Lack of data can result in overfitting of our model, and since relevant, good-quality data can be difficult and/or expensive to obtain, we need to squeeze out every drop of nectar from the data we have on hand. Data augmentation has proven to be particularly useful in this regard.

When we perform data augmentation, we create manipulated versions of the images in our training dataset so that we end up with many altered versions of the same images. By doing this, we achieve two things:

We increase the amount of samples in our training data.
By exposing the model to images with a higher variety of features, it gets forced to ignore non-relevant features, making it generalize better.

Disclaimer: Choose and use image augmentation techniques with care. Some methods may not be applicable to your use case. Wrong use and overuse can harm the performance of the model.

Albumentations

There are many good options when it comes to tools and libraries for implementing data augmentation into our deep learning pipeline. You could for instance do your own augmentations using NumPy or Pillow. Some of the most popular dedicated libraries for image augmentation include Albumentations, imgaug, and Augmentor. Both TensorFlow and PyTorch even come with their own packages dedicated to image augmentation.

Dedicated libraries for image augmentation provide many advantages that makes our lives easier. For one, they allow us to declare our data augmentation pipeline in a single place for use through a unified interface. In Albumentations, this interface is available as A.Compose() which lets us define the augmentation pipeline with the list of augmentations we want to use:

import albumentations as A
import cv2

# Load image
im = cv2.imread("your_image_path.png")

# Define augmentation pipeline
transform = A.Compose([
    '''
        List of augmentation methods.
    '''
])

To get an image with the augmentations applied to it, we can simply run transformed = transform(im) with the image as input.

Image augmentation libraries also make it easy to apply the same augmentations on an input image and the respective mask when working with image segmentation tasks. In addition, libraries allow for simple control of the probabilities and magnitudes for each of our transformations. For instance, if we want rotation to be applied 50% of the time, with a maximum of 45 degrees, we can write it as A.Rotate(limit=45, p=0.5).

Albumentations, which I will use for the examples in this post, supports 60 different image augmentations while also allowing us to add other augmentations to the pipeline. They also boast with the highest performance in terms of speed among the most popular augmentation libraries. A simple pip install albumentations and we are ready to go!

Defining an augmentation pipeline

The Compose class lets us define the augmentation pipeline with the list of augmentations we want to use. Calling Compose returns a function that applies the image augmentation.

import albumentations as A
import cv2

# Load image
im = cv2.imread("your_image_path.png")

# Define augmentation pipeline
transform = A.Compose([
    '''
        List of augmentation methods.
    '''
])

# Apply augmentations
transformed = transform(im)

Affine transformations

Affine transformations involve geometric transformations to images such as translation, rotation, scaling (zoom) and shearing. ShiftScaleRotate lets us apply several affine transformations and adjust their respective magnitudes:

# Load image
im = cv2.imread("robin.png")

# Define augmentation pipeline
transform = A.Compose([
    A.ShiftScaleRotate(shift_limit=0.0625, 
                       scale_limit=0.1, 
                       rotate_limit=45, 
                       p=0.5), 
])

# Apply augmentations
transformed = transform(im)

Noise

There are a lot of ways we can inject different types of noise into an image, including blur, gaussian noise, shuffling of channels in a color image, changes in brightness, colors, contrast, and the list goes on. Below is just a few examples, but Albumentations allows many more.

# Load image
im = cv2.imread("robin.png")

# Define augmentation pipeline
transform = A.Compose([
    A.ColorJitter(brightness=0.3, contrast=0.3, saturation=0.2, hue=0.2,p=0.5),
    A.MotionBlur(blur_limit=33, p=0.1),
    A.GaussNoise(var_limit=(0, 255), p=0.1)
])

# Apply augmentations
transformed = transform(im)

Dropout transformations

We can remove part of the information in an image using dropout transformations. This includes, but is not limited to, replacing regions of the image with zero or random values and removing a channel if it is a color image.

# Load image
im = cv2.imread("robin.png")

# Define augmentation pipeline
transform = A.Compose([
    A.CoarseDropout(max_holes=6, max_height=32, max_width=32, p=0.1),
    A.ChannelDropout(p=0.05)
])

# Apply augmentations
transformed = transform(im)

Other Spatial Distortions

Another cool way to augment an image is to use different distortion techniques for altering the shapes portrayed in the image. I added a grid to the illustrations to better visualize the augmentations.

# Load image
im = cv2.imread("robin.png")

# Define augmentation pipeline
transform = A.Compose([
    A.GridDistortion(num_steps=5, distort_limit=0.1, p=0.1),
    A.OpticalDistortion(distort_limit=0.2, shift_limit=0.05, p=0.1)
])

# Apply augmentations
transformed = transform(im)

Finally, gathering all the augmentations from this blog post into an augmentation pipeline would look something like this:

transform = A.Compose([
    A.ShiftScaleRotate(shift_limit=0.0625, scale_limit=0.1, rotate_limit=45, p=0.5), 
    A.ColorJitter(brightness=0.3, contrast=0.3, saturation=0.2, hue=0.2,p=0.5),
    A.MotionBlur(blur_limit=33, p=0.1),
    A.GaussNoise(var_limit=(0, 255), p=0.1),
    A.CoarseDropout(max_holes=6, max_height=32, max_width=32, p=0.1),
    A.ChannelDropout(p=0.05),
    A.GridDistortion(num_steps=5, distort_limit=0.1, p=0.1),
    A.OpticalDistortion(distort_limit=0.2, shift_limit=0.05, p=0.1)
])

Time to try it yourself!

Hopefully, you now have a basic understanding of what data augmentation is and how we can create augmentation pipelines for use in training deep learning models. There are of course a lot more augmentations that could be useful beyond the examples in this blog post, many of which are available in Albumentations. This means, it is time for you to try it out yourself. Experiment with different methods and see how they impact the performance of your models!

Further reading:
If you want to dig deeper into image augmentation techniques or look at more examples with Albumentations, I recommend to start here:

A Beginner's Guide to Mobile Development in React Native with Expo

Anders Aaen Springborg — Wed, 23 Mar 2022 15:34:06 +0000

Intro

This is a guide getting you through setting up a React Native project. However, this guide won't go in details with React, so if you're new to React, I recommend you to check out this getting started with react guide.

Here is a link for what your code should look like, when you are done.

React Native and Expo

React Native is a framework for writing cross-platform native apps.

Expo is a set of tools and services built around React Native and native platforms that help you develop, build and deploy iOS and Android apps from the same JavaScript/TypeScript codebase. The alternative would be to build each app in xCode and Android studio, which is very cumbersome.

Installation

Prerequisites

You need to have node and npm installed, and yarn is optional, but recommended.

Then we have to install Expo, through npm:

# Install the command line tools
npm install --global expo-cli

Now, we're ready to make a project. If you installed yarn, write:

expo init first-app

or with npm

expo init first-app --npm

From here, you will be prompted with a few options for your project. I recommend choosing a managed workflow as this enables us to release the app in Expo, without an Apple developer account for iOS. I chose the template "blank (typescript)", as can be seen in the picture below. If you're new, you could also use the "tab" template. This has built-in navigation.

You now have a project. In your terminal, you can navigate to the project's directory with 'cd first-app'. Your project structure should look like this:

Now, you can run the project by writing:

yarn start

npm run start

And it will look something like this:

You can either press w, to see your app in your browser, or you can scan the QR code which redirects you to download an app called Expo go. This allows you to view the app while you develop it, which is something I would recommend.

You now have a running app in React Native. In the next section, we are going to look at how native APIs work.

Native APIs

As we choose a "managed workflow", we're building everything with Expo. This comes with some limitations. If you need a native API which isn't on the list of supported APIs (there is 100+ native APIs), you can switch to a bare workflow in which you can write your own native code.
Below is a comparison between a managed and bare workflow:

Implementing native APIs

As an example, let's make a page that shows our battery percentage and GPS location.

Let's start with a battery component. We install it with:

expo install expo-battery

First off, we'll work on showing the battery percentage. We need the API 'getPowerStateAsync'. We'll call when a component mount, and voilá - we have the phone's battery percentage:

const [battery, setBattery] = useState<number>(0);

  useEffect(() => {
    Battery.getBatteryLevelAsync().then(b => setBattery(b));
  }, []);

We can show it in our view like this:

return (
    <View style={styles.container}>
      <Text>Battery {(battery * 100).toFixed(0)}%</Text>
      <StatusBar style="auto" backgroundColor={"black"}/>
    </View>
  );

Now, let's make a component that looks at the power mode of a phone. Imagine that you have a power-hungry feature which you want to disable when in low power mode (like animation).
We can get the power state from the same API, like this:

const [lowPoweredState, setLowPoweredState] = useState<boolean | null>(null);

  useEffect(() => {
    Battery.getPowerStateAsync().then(bs => setLowPoweredState(bs.lowPowerMode));
  }, [])

We can now carry out some conditional rendering, based on the power state:

  if (lowPoweredState === null) return <Text>Getting info from your phone...</Text>;
  return (
    <Text>Battery state: {lowPoweredState ?
      "i am a static text replacement" :
      "I AM A POWER HUNGRY ANIMATION"}
   </Text>);

To stay up to date, when the phone changed from a low powered state to a normal one, we can add a listener in useEffects like this:

const batteryModeSubscriber = Battery.addLowPowerModeListener(b => setLowPoweredState(b.lowPowerMode))
return () => batteryModeSubscriber.remove();

Our app will now always render based on the power state.

Publishing our app

Normally, you think of publishing an app to App Store and Google Play store. In order to do this, you need an Apple developer account(100$ yearly subscription) or a Google Play developer account(25$ one time fee) account. You can read more about building and releasing your app here.

You're an app developer

You have now started on your first React Native app in Expo. This is the same tool which is used for creating apps like Facebook, Instagram, Coinbase, shopify, Tesla, Uber Eats and many more. You can read more on Expo here: https://docs.expo.dev/ or check out an open source app here: https://github.com/withspectrum/spectrum
and checkout an enterprise boilerplate here: https://github.com/infinitered/ignite

Writing Good Tests (Part 2) - What Makes a Test Good

MichaelFack1 — Mon, 14 Mar 2022 12:05:38 +0000

In the previous post, I ranted about what not to do when writing tests and how to detect a bad test. In this post, I'm going to attempt to provide some pointers as to how you go about writing good tests.

What makes a test good?

Just like good code is a bit hard to pin down, so is a good test, but you will not be in any doubt when you read a good test, especially if it fails as it achieves its purpose - it will tell you exactly what went wrong and what needs fixing!

Let us demonstrate this by having a look at a failure. Consider our first example Test1. If it fails, you will be presented with text similar to "UnitTest1.Test1 failed: false != true". "This is true" said the tautalog. Instead consider the following test:

public readonly CmsService subject;
public readonly Mock<ICmsReadRepository> readRepoMock;
public readonly Mock<ICmsWriteRepository> writeRepoMock;

public CmsServiceUnitTest()
{
    writeRepoMock = new Mock<ICmsWriteRepository>();
    readRepoMock = new Mock<ICmsReadRepository>();
    subject = new CmsService(Mock.Of<ILogger<CmsService>>(), readRepoMock.Object, writeRepoMock.Object);
}
...
const string InvalidKeyDuoInvalidChar = "An invalid key e><ample";
...
[Fact]
public async Task ReadSectionAsync_InvalidCharKey_ThrowsInvalidCharException()
{
    // Arrange
    DefaultSetup();
    // Act
    var taskExpectedToThrow = subject.ReadSectionAsync(InvalidKeyDuoInvalidChar);
    // Assert
    await Assert.ThrowsAsync<InvalidCharException>(() =>  taskExpectedToThrow);
}
...

And the following message

This tells you that an InvalidCharException was expected from the CmsService when calling ReadSectionAsync, with a key containing an invalid char. Now, in this case, a few things could have gone wrong. Perhaps we no longer indicate failure to read with exceptions anymore but use the optional pattern instead, or perhaps we forgot to validate the key. I happen to know that we did not switch to the optional pattern which means the latter is true. Whoopsie.

All of this, I was able to infer from the test case, thus saving me tons of time I could have wasted Bughunting.

Furthermore, with a nice test coverage % and the most important and most common features under test, I can rest easy at night knowing my software is functional and not just a stinking heap of-. And, I also save time not manually testing which is time well spent in my opinion.

The purpose of a test

Without getting too metatheoretical, I would like to briefly discuss what "the purpose" of a test is, explicitly.

Say, I have a CMS service I want to test. I have some assumptions with respect to its functionality: It should be safe, practical and efficient. Moreover, say, that to be safe, it shouldn't allow all characters but only a specific subset of characters. Now I want to assert that my CmsService doesn't accept any of the illegal characters. Therefore, I write a unit test of which the purpose is to verify this. It initially fails, but after the introduction of a guard-clause, the test passes and I believe everything is good. The next day, I want to demonstrate this new behavior to my team, and I open the webpage utilizing the service to update the entries. You input an illegal character, press save and ... It saves!
You dive in to the database to discover a strange sequence of letters prefixed with an &. Somewhere there was a mismatch between the purpose of the test and the actual test.

This is obviously a very constructed example, but my point is that the test did not fulfill its purpose. A more appropriate test to write when verifying that the system does not accept invalid characters in its frontend is a frontend test, or perhaps a system test. Had I written a frontend test, I might have discovered that some middleware translates user input into safe strings that cannot be utilized in injection attacks. Had I written a system test, I might have discovered that the underlying CMS API has protection. It would have been more appropriate to write a unit test when asserting unit behavior, such as "I expect the CmsService to call the CmsApiClient when GetSectionAsync is called".

Conclusion

In the first post we discussed that if a test is not informative and exact, simple, timely and repeatable, then it's a bad test. In this post, we expanded on the concept of a test being good by discussing what a test needs to do; achieve its purpose of validating an assertion that we make about how some part of, or the whole, system works.

We also determined that this can only be done when we know what the assertion is and create a test based on this. In particular, we want the type of the test to match the layer of abstraction. If only there was some literature on the different kinds tests types paradigms that exist...

Remark

If you have any questions, disagree with anything, or if you would like something added to this blog post - leave a comment!

References

My personal experience,
https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-best-practices
https://martinfowler.com/bliki/GivenWhenThen.html
https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29 (Clean Code by Robert C. Martin summary)
https://docs.microsoft.com/en-us/aspnet/core/test/integration-tests?view=aspnetcore-6.0

Writing Good Tests (Part 1) - What Makes a Test Bad

MichaelFack1 — Thu, 03 Mar 2022 10:51:23 +0000

Unless you're some kind of demi-god, I believe you too have tried writing some new fresh code that didn't execute as you expected at first. Perhaps you forgot a guard-clause, some underlying dependency didn't behave as anticipated or, for some other reason, a bug was introduced to your precious code. What is more important (at least with regards to this blog post) is that you discovered this by compiling the code, running the software and seeing it fail.

In this blogpost, I hope to indoctrinate you into believing in the higher powers; automated testing!

Don't just write tests

Let me know if you've ever been in this situation before; you've just opened your favorite IDE to work on a large (and old) project, you see the infamous area of the project aptly named "Tests", and you shudder a little bit?

I have, and I can tell you why I shuddered - I knew I was the one delegated the tasks of fixing tests that did not succeed anymore. I was the designated Bughunter (trademark pending), and I knew a bug could take days to resolve, even for my more experienced coworkers who had been working on the project for years.

You know why? The tests were bad!

What makes a test bad?

Just like a bowl of cereal, a lot of things can make a test bad, and it is not always clear why a test has gone bad. However, once you've had a spoonful of it - you know!

In this short series, I am first going to supply you with a non-exhaustive list of things to check for when suspecting a test of being bad, and then later on in the series, I will discuss how to write good tests.

I just happened to have a CmsService lying around which implements a Read/Write access string mapping in a database and that I need to test, so, below I'll use it as an example of how NOT to write a test.

Try to spot a few things you find obscene in the following .NET code segment.



public class UnitTest1
{
    [Theory]
    [MemberData(nameof(TestData))]
    public async Task Test1(List<Tuple<int, CmsDbEntry>> entries, string expected, bool boolResult)
    {
        var repoMock = new Mock<ICmsWriteRepository>();
        var dbContextMock = new Mock<CmsDbContext>();
        var repo = new CmsRepository(null, dbContextMock.Object);
        var service = new CmsService(new LoggerFactory().CreateLogger<CmsService>(), repo, repoMock.Object);
        var entriesMock = new Mock<DbSet<CmsDbEntry>>();
        foreach (var (key, entry) in entries)
        {
            entriesMock.Setup(m => m.FindAsync(key)).ReturnsAsync(entry);
        }
        dbContextMock.Setup(m => m.Entries).Returns(entriesMock.Object);
        var result = await service.ReadSectionAsync("some arbitrary constant");
        Assert.Equal(result, expected, ignoreCase: true);
        if (boolResult) {
            repoMock.Setup(m => m.WriteAsync("some arbitrary constant", "Content")).ReturnsAsync(boolResult);
            var boolResult0 = await service.WriteSectionAsync("some arbitrary constant", "Content");
            Assert.Equal(boolResult, boolResult0);
        }
    }

    public object[][] TestData = new object[][]
    {
       ...
    };
}

Here's a few things I like to pay attention to:

Is the test readable?

At a quick glance, the test should convey what is being tested. If it fails to convey what is being tested, at best, it becomes harder to update as the target code changes, at worst, it can sabotage development as it misleads the developer.

If you cannot discern what a test tests, how can you know if it is correct? A test which you cannot tell whether is correct or not because you cannot discern its purpose or meaning adds no value. You are better off without it.

Is the test well named?

A well-named test might convey the entire purpose of a test, much like how a well-named method conveys its functionality.

Formatting test names in a consistent way helps conveying purpose. Additionally, in conjunction with other tests, well-named tests can actually help you pinpoint exactly where you should look for bugs.

I personally use the {method}_{condition}_{result}. ```c#

public class CmsServiceUnitTests {
[Fact]
public async Task ReadSectionAsync_ValidKeyOfExistingEntry_ReturnsEntry() {
...
}
}

- Other naming conventions also exist - I can recommend the [{Given}\_{When}\_{Then}](https://martinfowler.com/bliki/GivenWhenThen.html) format since user stories can be formulated in this format as well.
```c#


public class CmsServiceUnitTests {
  [Fact]
  public async Task GivenValidKeyEntryPairInDb_WhenFetchingEntryOfTheKey_ThenEntryIsReturned() {
    ...
  }
}

Does it test more than one thing?

A test that tests more than one thing at a time can be difficult to derive meaning from and becomes less useful with respect to pinpointing where a bug lives in the code.

One thing does not mean one field or just one value, but rather the resulting state. A rule of thumb: primitive fields and such can be checked together as a way of validating the state of an object, but do make sure to add more informative messages when you have more than one assertion in a test.

With the {method}_{condition}_{result} naming convention, this is given: ```c#

[Fact]
public async Task ReadSectionAsync_ValidKeyOfExistingEntry_ReturnsEntry() {
var expected = dbKeyEntryPair.Entry;
...
var actual = await service.ReadSectionAsync(validKey);
...
Assert.Equal(expected, actual);
}


### Is it well arranged?
A well-arranged test does not configure some state, execute some code, configure some more, execute some more, assert something and keep on mixing these things. In the abstract, a test that does one thing, and one thing only, validates that the code under testing from some configured state performs some execution, returns something expected and finds rest in some expected state.
- Microsoft advice adding the three A's as code comments:
```c#


[Fact]
public async Task {TestName}(){
  // Arrange
  {Configuration}
  // Act
  var actual = {subject}.{Method}({args});
  // Assert
  {Assertion(s)}
}

There is some disagreement out there in the Great Ether with regards to where one should put shared static configuration, such as the initialization of the test subject(s) and mocks as well as common configuration of the subject(s) and mocks. It is my opinion that initialization can occur in the constructor of the test class and that this will be the same for all tests in a test class. Configuring the subject(s) and mocks thus belongs to the configuration step of each test, as they likely vary. ```c#

public class CmsServiceUnitTests {
public Mock writeRepoMock;
public Mock readRepoMock;
public CmsService subject;

public CmsServiceUnitTests() {
readRepoMock = new Mock();
writeRepoMock = new Mock();
subject = new CmsService(Mock.Of>(), readRepoMock.Object, writeRepoMock.Object)
}

const string validKey = {key of valid format};
const string entry = {content of entry};

[Fact]
public async Task ReadSectionAsync_ValidKeyOfEntry_ReturnsEntry() {
// Arrange
readRepoMock.Setup(m => m.ReadAsync(validKey)).ReturnsAsync(entry);
var expected = entry;
// Act
var actual = subject.ReadSectionAsync(validKey);
// Assert
Assert.Equal(expected, actual);
}
}


### Does logic occur?
A great way to detect whether a test only does one thing or not is to check whether it contains logic, such as a `switch`-, an `if`- or a `for`-statement. These statements make the test a lot less readable seeing as the state of the subject and the input at the time of method calling becomes something computed, rather than something set (which can simply be read).
- I must admit that I sin with respect to this when compressing testcases - sometimes I find it easier to write a lot of testcases using one parameterized test, where some of the arguments inform the testcase to configure in a particular way, instead of splitting up the testcases into multiple separate parameterized tests. However, just because something is easy doesn't mean you should do it!

### Is it a typical test?
Here _typical_ refers to whether or not the test follows some sacred dogma allowing it to be categorized easily into some preconceived type, such as End-to-end integration tests, unit tests, or simply tests that fit in to the overall test strategy.

If the test does not neatly fit into a category, consider refactoring it in such a way that it does. A way to do this could potentially be to clone the test if it resides within a canyon of two or more categories, in order to ensure that each category gets its own version of the test.

### Does it follow Clean Code Principles?
In spite of popular belief, test code is actually also code and should in general receive the same care you provide to any other code. There's great benefits to this, such as readability, reusability and flexibility.
- To demonstrate this, consider a test class containing a large number of tests where the subject has some internal state that may vary. While one state can be considered both an initial and valid, all other states can abstractly be thought of as mutations of this first state. We can use this sort of thinking when coding our tests. In each test following `// arrange`, we use the method `Setup();`. Each test then deviates from this initial state by mutating it, perhaps with a `SetSubjectDependency(s => s.{dep}, null)` in a test validating how the subject handles internal nullreferences.

### Is the test independent?
Tests which share state and space with other tests are at risk of experiencing bugs themselves because the timing of execution of the tests may affect their correctness. This should be avoided by instantiating dependent objects for each test.
- If you want to increase readability of a test by reducing bloat by moving some variables to the class scope or similar, or perhaps refactoring away some magic constants, make sure they are immutable in the outer scope. If this is not an option, consider not moving it to the outer scope. Otherwise, you are vulnerable to undesirable behavior in your tests.

### Is the test timely (relatively)?
A test that is never run is a bad test as it adds no value. A tests that motivates the developer not to run it, perhaps because it takes a lot of time to set up or it just runs slowly, **is a bad test**.
  - A test is a slow test, seen relatively to how often you'd like to run it. If a test suite is run once a month, because the code it touches is very static, or the suite is overly thorough relatively to everyday development, it is acceptable that it takes longer to run. Test suites that are expected to run on a daily basis, perhaps even hourly basis, should be quick, though! Otherwise, you will end up getting more coffee than is healthy for you, with all those coffee breaks.

### Is the test repeatable?
A test which has stochastic behavior, such as being real-time dependent, using pseudo-randomness generators or threading timing are inherently bad tests because a pass does not guarantee anything (a false positive), and a failure can be hard to reproduce.

Believe me! In my more inexperienced days, I once spent two days trying to reproduce a test failure which turned out to only occur when the clock on the machine had gone past 19:00.

These qualities makes the test unreliable. To fix this, you fix the uncertainties. Mock the problematic dependencies, in relation to which you might possibly need to introduce wrappers, in order to gain control over what they return. In that way, the test result becomes reliable, although the result is less general and more specific - but do not fool yourself! This was already the case, now we just know the specifics.

- This also implies that you should not use a PRG or the clock by yourself to setup or run your tests!
- Sometimes, it cannot be avoided to have uncertainty in your tests, for instance if you are integration testing in conjunction with some third party code. In that case, there are some strategies concerning how to avoid false positives, such as repeating the code x times, but you should be aware that there are not absolutes in the realm of probabilistic.

## What makes a test good?
Having uncovered what makes a test bad, the next logical step is to explore how to identify a good test. Rather than letting this blogpost go on forever, I'll let you ponder upon the matter until the release of the second half of this short series on testing, wherein I'll elaborate further on testing and how to spot good tests - so watch out for part 2! 

# Conclusion
To sum up this blogpost, however, we've now compiled a list of things to check for when you suspect a test of being bad and need to identity what needs to be changed.

In case you already forgot, here's a shorter version:
1. Know what you are testing.
2. Name the test accordingly.
3. Test one thing at a time.
4. Arrange your tests.
5. Make your test readable.
6. Make your test simple.
7. Make your test timely.
8. Make your test independent.
9. Make your test repeatable.

... and if the test is without purpose, get rid of it.

## Remark
If there is anything you wonder about, disagree with or would like added to this blog post - leave a comment!
## References
My personal experience,
https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-best-practices
https://martinfowler.com/bliki/GivenWhenThen.html
https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29 (Clean Code by Robert C. Martin summary)
https://docs.microsoft.com/en-us/aspnet/core/test/integration-tests?view=aspnetcore-6.0

9 quick tips for keeping development velocity high within a software development team

Peter Øvergård Clausen — Mon, 21 Feb 2022 12:23:32 +0000

Throughout the 2 years and 7 months I've been a software development consultant at IT Minds, I've been at three different companies. This has provided me with insight into developing software when working in teams, and I would therefore like to share these following 9 tips for keeping development velocity high within a team.

Consider trying them out in your development team, and let us know in the comments what you think about our tips, and whether you have any tips that you would add to the list. 😊

1 - Refactor often to keep software quality high and technical debt low

It is unavoidable to gain technical debt as features grow and requirements change, hence dealing with technical debt before it slows you down is important. A well refactored codebase is more prepared for change and new features. Developers and project managers alike should prioritize refactoring as it keeps the software clean and prepared for change.

2 - Rely on external libraries

Rather than developing own libraries from scratch, and having to document and maintain these, one should rather spend a day researching whether there’s an existing external library that solves the problem at hand. Less time will be spent on maintaining the library, less time will be spent on documenting the library, and team members will have a place to read and learn about the library rather than having to ask the person who made it. There is no reason to reinvent the wheel, unless the wheel is your product.

3 - Have a shared Wiki for team documentation

When a new team member joins a development team, a lot of time and confusion can be saved if the new team member has access to documentation which allows them to gain knowledge on how to set up the system locally as well as on the choices that have been made thus far. Furthermore, a wiki helps knowledge sharing within the team, making it easier for team members to help each other out.

4 - Plan ahead, at least one sprint in advance

Always knowing where the product is headed, keeps the motor running. Sometimes a feature is implemented faster than expected, and moving on to the next feature can be quick. Likewise, if something takes longer than expected, you can assess the priority and know which other features are postponed.

5 - Prioritize what’s essential, and avoid frequent scope changes

Make it clear which feature requests are need-to-have and which are nice-to-have, and always have tasks in the sprint prioritized on what is most important. Seek to break down large tasks into smaller subtasks, and try to estimate how long they’ll take. In this way, the team will know which tasks are heavy and highly prioritized and which tasks should be focused on within the sprint, while the project manager can monitor progress.

6 - Divide responsibilities among team members, but also allow team members to help each other across responsibilities

Letting a team member work on other team members' responsibilities speeds up development and knowledge sharing. Instead of two team members having to coordinate tightly, smaller adjustments to the backend could be carried out by a frontend developer and subsequently reviewed by backend developers as a pull request. If the implementation needs adjustment, backend developers can help out. The same goes for backend developers making small changes in the frontend. For smaller software products, it may be the case that everyone can work with everything, but for larger software products it becomes infeasible for one person to know and work on everything. For this reason, my advice is to divide responsibilities, but also to let the team members help each other out across responsibilities.

7 - Invest in your teammates

You may have a lot on your plate right now, but it’s never a bad idea to help out a teammate and share your knowledge of the codebase and technologies used. You may not get as much work done at first when your teammate starts, but sharing your responsibilities and knowledge will greatly improve development velocity when your teammate is up to speed, and it’ll lift some weight off your shoulders. The faster that can happen, the faster you’ll get the benefit of your teammate. Also, I’m sure your manager understands that you’re spending time onboarding and investing time in your teammate.

8 - Automate as much as possible

Build, Test, and Release pipelines makes sure that the software is in a consistent state and that new features can quickly be tried out by the product owner in the DEV environment. Implementing scripts to do mundane common tasks can also save a lot of time.

9 - Conduct Engineering meetings

I was at a company as a consultant that conducted a one-hour Engineering meeting every Friday. Developers could submit topics throughout the week to be discussed at the engineering meeting. We pointed out parts of the product that needed refactoring, discussed problems and solutions, and introduced new libraries that could help us tremendously. The meetings also helped with knowledge sharing and improved team members' joy for the project and team spirit. Also, a lot of cross-team-communication could be done efficiently within this hour. I highly recommend these meetings.

Summary

We have explained the following 9 tips for keeping software velocity high within a team:

Refactor often to keep software quality high and technical debt low
Rely on external libraries
Have a shared Wiki for team documentation
Plan ahead, at least one sprint in advance
Prioritize what’s essential, and avoid frequent scope changes
Divide responsibilities among team members, but also allow team members to help each other across responsibilities
Invest in your teammates
Automate as much as possible
Conduct Engineering meetings

Let us know in the comments if you have any additional tips for keeping development velocity high within a team - or simply if you have tried out any of our tips within your team, and whether it was a success or not. 😊

Injecting dependencies into your game development

Søren Bach Nielsen — Thu, 17 Feb 2022 08:12:33 +0000

Coming from a game development background as a game play programmer and transitioning into more of a traditional software developer path, certain things are the same. You use many of the same languages, programming paradigms and even the same IDE’s. But there are, of course, also plenty of things that are different. These can depend on many factors, such as project size, what type of project you’re developing and so on.

One of these things is the Dependency Injection (DI) technique and Inversion of Control (IoC) containers.
Through my, for now, somewhat short experience as a traditional software developer, I’ve noticed that this is probably the most prevalent set of design patterns and handy techniques I’ve gotten the most use out of.

So, naturally, that made me wonder. How come this isn't more widespread in the game development scene?

Well, it should come as no surprise that there are of course also DI frameworks for popular game engines and frameworks.
In this post we’ll be taking a look at the dependency injection framework called Extenject for the Unity game engine.

Why even bother with Dependency Injection and IoC containers?

Many of you may already know what DI and IoC containers are, as well as what kind of benefits they can bring to the project, but in case you don't, I’ll briefly give you an overview of the topics and how they can improve your architecture.

DI is the act of moving the responsibility of fulfilling the class's dependencies and construction of these dependencies to somewhere else in the application.
And this is where the IoC container comes in. Its job is to automatically provide these dependencies where needed which is done by setting up all the correct bindings in the container.

The biggest benefit Dependency Injection and IoC containers is the loosely coupled architecture you achieve by using it. Classes no longer tightly depend on other class implementations and are not in control of how they obtain that dependency, or of how they should populate that dependency’s dependencies.

Moreover, the architecture allows you to automatically lean towards the Single Responsibility Principle which ensures that each class only focuses on its own responsibilities rather than worrying about other things, such as achieving the correct dependencies.

Finally, the architecture helps you create a bigger picture of the dependency of your applications as well as of how they are all wired up in the IoC container. And with that, it also makes it easier to exchange concrete implementations of such dependencies.

TutorialsTeacher has a great DI and IoC explanation focused on the .NET framework if you feel like reading a more in-depth explanation of this topic.

The .NET way

So, to give a proper introduction to Extenject, I thought we should start out with a really simple example containing what many of you are probably most familiar with. In this case, I’ll use a simple .NET Core Web API.

In this example, we see the IoC container in a .NET Core project where we're telling it to hook up the ISomeService interface as a SomeServiceImplementation class wherever it’s needed. The SomeServiceImplementation is then injected as a singleton. There are other ways to inject your dependencies, but that is beyond the scope of this post.

And now the great thing is that we can simply inject this ISomeService interface into our classes where needed, and we don’t need to worry about where to get that dependency from or about what type of concrete implementation is needed. The IoC container takes care of all that for us.

That’s neat! So let’s now take a look at how Extenject does this and how the process is a little bit different with Unity.

The Extenject way

In order to get started with Extenject, you first have to download the latest package. I recommend downloading it from the official github repository since the one on the Unity Asset Store isn't updated as frequently.

In Extenject, you set up your bindings through what is called Installers which basically constitutes your IoC container. These installers are linked up with a Context; a context defines the scope of where your bindings are set up. For instance, it's possible to have bindings that are only defined for certain scenes with a Scene Context, but there’s also a Project Context which sets up your bindings for the whole lifecycle of your project.

There are also different types of installers based on the types of bindings you want to set up. In our example, we will be using a Mono Installer on a Scene Context.

You can create a Scene Context by right-clicking in your hierarchy and navigating to Zenject -> Scene Context.

Here, we take a look at our Installer which basically does the same as our .NET example, i.e. creating the ISomeService with the concrete class SomeServiceImplementation as a singleton.

Extenject has a ton of different ways to set up your bindings, and I recommend you to check out their documentation for more info on that. They support many Unity specific bindings which will definitely come in handy for your projects.

Extenject also supports multiple different ways of injecting your dependencies into your classes. From the official documentation, they are the following:

Constructor injection
Method injection
Property injection
Field injection

Those of you familiar with Unity might be wondering “Constructor injection with Monobehaviours? How?” - and you would be right to think that.
What the documentation is referring to is constructor injection through normal C# classes.

Since MonoBehaviours can’t really have constructors, we have to use other ways of injecting our dependencies. They can still be injected through either field, property or method injection, where method injection is the preferred way.

Here, we see a basic example of MonoBehaviour that injects their dependency through a method. My personal preference is to have a method at the top called Construct and use that with the [Inject] attribute to simulate a constructor. It also gives a fast and easy overview of which kind of dependencies this object needs.

Final thoughts

DI and IoC containers are great! And if you’re like me, you might have had the thought “I’ll need to start using this in every Unity project from now on!”. However, I’m not sure that would be the right way to look at it. Different tools, for different problems.

Extenject is a really good and powerful tool. It comes with a lot more than what I have shown in this post (it even has built-in support for memory pools). But, this also means it comes with some overhead, and it can also get a bit hairy to set up all your bindings correctly.

It also depends on whether you’re working alone or with a team. Some considerations might be whether the entire team understands the ins and outs DI frameworks, and whether you have time/money to invest into onboarding people in the way your architecture for the project is set up.

All these things need to be considered before you just start throwing Extenject into every one of your projects.

But I hope this post has shown you yet another tool that you can add to your toolbelt.

Thank you for reading!

Speeding Up Development with Figma-to-code through Plasmic

Sebastian Bove Wagner — Fri, 04 Feb 2022 09:34:12 +0000

Visual web development software and no-code solutions for building static webpages are not exactly new inventions. While no-code has many pros - especially for people or companies with simple requirements and low budgets - it can also be very limiting, and it often doesn't fit well into the development of a complex dynamic site, especially if development has already begun.

Many of the older no-code solutions are also not very performant nor expensive.

There are newer no-code tools which are more performant and are able to work more seamlessly with classic web development and hosting (webflow.com for example), but if you're reliant on a lot of custom or legacy code, or want to integrate no-code into your own dev-ops environment, Plasmic might be a solution. And a fast one at that.

What is Plasmic?

Plasmic is a no-code, collaborative visual builder for the web.

You can build pages or components and either let Plasmic host them (which is great for quick changes, or for letting an admin change Landing pages etc.), or generate REACTJS code.

With the latter approach, Plasmic is free to use and easy to integrate into a pre-existing project.

On top of that, Plasmic has created and maintains the Figma-to-Code plugin, which can greatly speed up the development of components.

A micro example

In the following simple example, a "designer" has requested the development of this simple page as an extension to a large, pre-existing project.

The page consists of a couple of SVG files, some text and some buttons.

With the Figma-to-Code plugin, you can copy and paste the entire page into Plasmic.

More practically, you can copy and paste both of the components into their own Plasmic components.

From here, it's possible to make variants of each component; these variants can be interaction variants, such as Hover, Press etc.

And now, to my favorite part.

By pressing the publish button in the top right, you can connect the project to a github project (or other git projects) and automatically generate the components - ready for use.

It's even possible to trigger other CI-CD pipelines to automate deployment or testing.

The generated view components will be put in a components/plasmic folder, and in the components folder you will find newly generated "skeleton" components that you can use to add any wanted functionality into.

Voilá

Things to be mindful of

The entire process, from Figma to code, can take minutes, or seconds, if there are no large adjustments needed.

Many Figma projects created by designers are not necessarily that easy to import.

Masked components are buggy, and it isn't easy to make good, responsive flexbox designs if the designer doesn't use auto-layout or just manually enters padding per component.

I also have to mention that Plasmic is not the only visual component creator tool, but the addition of the collaboration tools and deployment make it a powerful tool for fast development of visual components.

Resources:

plasmic
Figma-to-Code

Learn Next.js by creating a static HTML webpage

Fridtjof Nystrøm — Thu, 13 Jan 2022 09:45:10 +0000

React is great! With React, it's easy to create reusable components. It easily integrates with TypeScript, it can be used for mobile development - and it has a big community.

In this post, we will create a simple website using the React framework Next.js and export the website as a static HTML webpage ready to be deployed anywhere.

👋🏼 Next.js

Next.js is a framework on top of React that enables server-side rendering and static website generation. It comes with a lot of useful features, such as Image Optimization and SEO-friendly routing. We won't go into much detail on these topics, but you may want to check out Next.js' documentation if you find these topics interesting.

Let's create our first Next.js app

Let's head right in and initialize the project using create-next-app. Open your terminal and create a Next environment using the command below:

npx create-next-app@latest --typescript

Type in your project name, and watch the magic happen. To start the application in development mode, enter the project folder and run:

cd my-app && npm run dev

You should now be able to visit http://localhost:3000 to see the website.

The project structure

Open the folder belonging to the project, and look at the folders in the root of the project. It should look something like this:

- /node_modules
- /pages
  - /api
  - index.js
- styles

The pages folder

The pages folder equals to the routes of your webpage. http://localhost:3000 redirects to /pages/index.tsx. To create a new route, create a new file in the pages folder. For example, a /pages/about.tsx file would create the route http://localhost:3000/about.

index.tsx

Let's simplify the front page a little bit. Open index.tsx, and replace the file content with the code below:

import type { NextPage } from 'next'
import Head from 'next/head'
import Link from 'next/link'
import styles from '../styles/Home.module.css'

const Home: NextPage = () => {
  return (
    <div className={styles.container}>
      <Head>
        <title>Home</title>
        <meta name="description" content="My own personal static html page" />
        <link rel="icon" href="/favicon.ico" />
      </Head>

      <main className={styles.main}>
        <h1 className={styles.title}>
          Welcome to index.tsx!
        </h1>
        <p>This is a static HTML website built with React & Next.js </p>
        <div className={styles.grid}>

          <Link href="/people/me">
            <a className={styles.card}>
              <h2>About me</h2>
              <p>Click here to navigate to people/me.</p>
            </a>
          </Link>

          <a href="https://nextjs.org/learn" className={styles.card}>
            <h2>Learn &rarr;</h2>
            <p>Learn more about Next.js!</p>
          </a>

        </div>
      </main>
    </div>
  )
}

export default Home

Navigate to http://localhost:3000. The page should look something like this:

There is a Link to people/me. The Link component takes care of page routing within the website. Right now, the link redirects to a 404 page. That's because the people/me page is missing from the application. Let's go ahead and create that file.

People/me

Paste the following code into pages/people/me.tsx. Feel free to change anything, for example the name.

import type { NextPage } from 'next'
import Head from 'next/head';
import Link from 'next/link';
import styles from '../../styles/Home.module.css'

const Me: NextPage = () => {
    return (
        <div className={styles.container}>
            <Head>
                <title>People - Me</title>
                <meta name="description" content="Page about me" />
                <link rel="icon" href="/favicon.ico" />
            </Head>

            <main className={styles.main}>
                <h1>
                    Hello, my name is Fridtjof! 👋🏼
                </h1>
                <p>
                    Nice to meet you!
                </p>
                <Link href="/" >
                    <a className={styles.card}> 
                        Navigate to the frontpage
                    </a>
                </Link>
            </main>
        </div>
    )
}

export default Me

Enter http://localhost:3000/people/me, and watch your website render. With this two-paged masterpiece finished, it is now time to share your masterpiece with the world. It's time to build!

Create the static HTML

Before you can deploy your website as a static website, it must be built and exported. To do so, change the build script in package.json to also export the project.

"build": "next build && next export"

Make sure that you've saved your latest changes, then run:

npm run build

When the script is done, a new folder named out will appear within the project. To deploy the code, copy the content of the out folder to any web hotel or bucket, just as you would with any static HTML website.

Congratulations! You now have your very own static website, created with React components that you can deploy anywhere. Note that this post only touches the surface of Next.js. To use Next.js for a simple page like the one we built is totally overkill, but it is a nice introduction. In a future post, we will look further into the advantages of using Next.js.