While there are lot of hidden gotchas in C++, there are also many useful features that have evolved from all sorts of poorly defined behavior and hacked-on additions that have become useful tools in my box with doing day-to-day work.

This post aims to explore a few of the ones I could remember off of the top of my head from looking at my game engine project, [Ona](https://github.com/Kayomn/Ona), and explore how and why they can be helpful in reducing code duplication, avoiding slowdowns, and producing code that needs to do less at run-time.

# Beyond Pimpl

In my experience, I have never found the very rigid examples of the "pimpl" design pattern useful. My issues with pimpl sit with how it adds a lot of unnecessary run-time overhead to excuse poor support for hiding implementation details. That withstanding, it is possible to get a lot more mileage out of this design pattern by ignoring the most common examples of its application.

```cpp
class External {
	class Internal;

	Internal * internal;

	public:
	External();

	~External();
};
```

The most common application of Pimp is to wrap a dynamic allocation - which itself may sometimes be wrapped in either a `std::unique_ptr` or `std::shared_ptr` rather than a regular C pointer. Evidently, this disregards the hard run-time needs of the application for the sake of hiding some data.

Usage of a Pimpl-like pattern became very necessary for a recent project I was working on, which was implementing a document object model-like structure for browsing configuration data.

```cpp
class ConfigEnvironment final : public Object {
	struct Value;

	HashTable<String, Value> globals;

	public:
	// ...
};
```

`Value` contains a lot of data and a lot of member functions. Were these exposed in the header, it would not just make it harder for readers to parse, but also the compiler itself.

However, by happenstance, I discovered that my implementation of `HashMap` does not need to care about the size or layout of `Value` at this stage of compilation, so it is perfectly happy to accept an incomplete type as one of its type arguments.

```cpp
struct ConfigEnvironment::Value {
	enum class Type {
		Object,
		Boolean,
		Integer,
		Floating,
		String,
		Vector2,
		Vector3,
		Vector4,
		Array,
	};

	enum { UserdataSize = (64 - sizeof(Type)), };

	Type type;

	uint8_t userdata[UserdataSize];
};
```

Within the implementation file, the actual layout of the struct is defined for the compiler to see when compiling this file but never anywhere else.

No performance is lost here by using Pimpl over defining `Value` in the header, and a lot of implementation details have been hidden from public view, saving potential time in the future when parsing the header.

The example of this version of Pimpl in action can be found [here](https://github.com/Kayomn/Ona/blob/2c6e39326a1f38b1472476b8dc1bc6a351fb1311/engine.hpp#L174) and [here](https://github.com/Kayomn/Ona/blob/2c6e39326a1f38b1472476b8dc1bc6a351fb1311/engine/script.cpp#L4).

# Stateful Lambdas

Lambdas are a very useful feature that was introduced in the C++11 standard revision. While the most popular use of lambdas is as arguments to other functions, they also have a lot of use as local functions.

```cpp
void doThing() {
	char const * message = "Hello, world\n";

	auto doThingALot = [message](int iterations) {
		for (uint64_t j = 0; j < iterations; i += 1) {
			printf("%s", message);
		}
	};

	for (uint64_t i = 0; i < 100; i += i) {
		doThingALot(i);
	}
}
```

Similar to [C# local functions](https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/local-functions), these functors are able to capture the local scope and perform repetitive tasks, reducing repeated code while still retaining all the compiler optimizations of regular C++ functions.

In fact, a lot of useful techniques can arise from lambdas that capture the local scope, with one of which being *stateful lambdas*. Stateful lambdas are a practice I employed recently in the development of a lexer I wrote.

```cpp
auto eatToken = [&, i = (size_t)0]() mutable -> Token {
	// ...
}
```

The declaration of `i = (size_t)0` is creating a scoped variable of type `size_t` within the `eatToken` functor. By default, `i` is not mutable, erasing any potential use for this feature beyond some extra automatic scoping. Luckily, C++ is a language that allows any data to have its `const`-ness broken at any time with the use of `mutable`.

```cpp
auto eatToken = [&, i = (size_t)0]() mutable -> Token {
	i += 1;

	// ...

	return Token{/** ... */}
}
```

Now, the `eatToken` functor is free to change the value of `i` as much as it likes whenever it is called. Each new invocation will retain the state of `i` from the last, without needing to rely on hacky solutions like global data.

In the lexer, this was leveraged to create an `eatToken` function that would lazily tokenize a string of data and spit out each new token that was found as a `Token` type. Once the end of the string was reached, only end-of-file tokens were produced to mark the terminating state for the parser loop.

For readers that are not familiar with the problems surrounding lexing text, this meant that it was no longer necessary to keep a full in-memory representation of all lexed tokens.

```csharp
Token EatToken(string text)
{
	var i = 0;

	// ...

	while (i < text.Length)
	{
		i += 1;

		yield return new Token(/** ... */);
	}
}
```

> *Example of `eatToken` in C#*

```js
function* eatToken(text) {
	let i = 0;

	// ...

	while (i < text.length) {
		i += 1;

		yield {
			tokenType: TokenType.eof,
			tokenText: "",
		};
	}
}
```

> *Example of `eatToken` in ECMAScript*

```py
def eat_token(text: str) -> Generator[dict, None, None]:
	i = 0

	# ...

	while (i < len(text)):
		i += 1

		yield {
			"token_type": TokenType.EOF,
			"token_text": "",
		}
```

> *Example of `eatToken` in Python*

Languages like C#, ECMAScript, and Python feature very similar concepts with nicer-looking APIs, but falter in implementation as they all rely on dynamic allocations to work, while mutable functors do not have this problem.

The implementation of `eatToken`, as well as the full lexer and parser source code, can be found [here](https://github.com/Kayomn/Ona/blob/2c6e39326a1f38b1472476b8dc1bc6a351fb1311/engine/script.cpp#L157).

# Small Buffer Optimization

New C++ users who are familiar with programming may be inclined to always reach for `new` whenever they need a buffer of memory that cannot be reasoned about at compile time. While C++ may resemble more managed languages like C# and Java, its dynamic memory model does anything but - because there is not one.

C++ is more than happy to grab memory from the operating system directly by the page and then split it into smaller chunks as needed, albeit at a relatively high cost. Languages like C#, Go, and Java all use managed pools of commonly used memory chunks pre-allocated by the run-time to speed up their allocation abilities.

Short of implementing a custom memory pool and allocation library, there is not an easy way of creating relatively cheap dynamic memory allocations right now. Despite that, C++ can do something that many managed languages cannot: allocate on the stack.

```cpp
struct String {
	private:
	enum { StaticBufferSize = 24, };

	uint32_t size;

	uint32_t length;

	union {
		uint8_t * dynamic;

		uint8_t static_[StaticBufferSize];
	} buffer;

	public:
	// ...
};
```

Many examples of C++ software that I have written in the past feature standard library-adjacent code that exists with the sole purpose of facilitating optimizations for small amounts of data. These small buffers are used up until the limits are exceeded by the spatial needs of the data itself.

```cpp
template<typename Type, size_t InlineMax> class InlineArray final : public Object, public Array<Type> {
	size_t length;

	union {
		Type * dynamic;

		Type static_[InlineMax];
	} buffer;

	public:
	// ...
}
```

Further control over what these "limits" are can be given to the user of the library directly via template parameters, which accept a value specifying the maximum size for the small buffer.

The implementation of the above small-buffer optimized `String` struct can be found [here](https://github.com/Kayomn/Ona/blob/2c6e39326a1f38b1472476b8dc1bc6a351fb1311/common.hpp#L219).

# Fixed Array Arguments

Sometimes you just want to be able to accept an array as an argument. I had this crop up when implementing a static array wrapper called `FixedArray`.

A hypothetical C++ programmer's first thought my be to reach for `std::initializer_list` or use a templated function, but if the maximum size of the array is known, it turns out doing it is fairly trivial and can be template-free.

```cpp
template<typename Type, size_t Len> class FixedArray final : public Object, public Array<Type> {
	Type buffer[Len];

	public:
	// ...

	FixedArray(Type (&values)[Len]) {
		for (size_t i = 0; i < Len; i += 1) {
			this->buffer[i] = values[i];
		}
	}

	FixedArray(Type (&&values)[Len]) {
		for (size_t i = 0; i < Len; i += 1) {
			this->buffer[i] = std::move(values[i]);
		}
	}
}
```

In the above example, two overloads of the constructor are defined, with one being optimized for perfect forwarding and the other being designed for indirect bit copying.

```cpp
static FixedArray<Vector4, 6> const quadVertices = {{
	Vector4{1.f, 1.f, 1.f, 1.f},
	Vector4{1.f, 0.f, 1.f, 0.f},
	Vector4{0.f, 1.f, 0.f, 1.f},
	Vector4{1.f, 0.f, 1.f, 0.f},
	Vector4{0.f, 0.f, 0.f, 0.f},
	Vector4{0.f, 1.f, 0.f, 1.f}
}};
```

This allows code that wants to act like a regular array, act like an array with minimal to no run-time overhead associated.

The implementation and usage of `FixedArray` can be found [here](https://github.com/Kayomn/Ona/blob/2c6e39326a1f38b1472476b8dc1bc6a351fb1311/common.hpp#L771) and [here](https://github.com/Kayomn/Ona/blob/2c6e39326a1f38b1472476b8dc1bc6a351fb1311/engine/opengl.cpp#L9) respectively.

# Conclusion
There is a lot that can be done with C++. Some it is good, some of it is terrible, some of it is even worse than terrible. Despite this, I still find it to be the most versatile tool that exists for systems-level programming, and a lot of these features go a long way to demonstrate why that is.


While there's a lot of hidden gotchas in C++, there's also many useful features that have evolved from all sorts of poorly defined behaviour that have become useful tools in my box with doing day-to-day work.

Some Useful C++ Tricks

If you're anything like me then I feel sorry for your plants, you buy them with great intention of keeping good care of them, then suddenly a week has gone by and you have forgotten to water them... Rather than taking the sensible option and just, you know, watering them, I decided that this would be a fun project for my Raspberry Pi that has recently been collecting dust. To spice things up a little bit I decided to challenge myself to write all of the code required to build this in [Dictu](https://dictu-lang.com/). For those not in the know, Dictu is a programming language created by yours truly. Before I started with the project, I had a few requirements that I wanted to meet for this to be considered a successful project by myself:
1. For it to actually work correctly...
2. For all (if not most) of the code to be written in Dictu
3. For it to only water when soil levels reach a certain "dryness" rather than on a schedule
4. For it to monitor water levels and notify me when they are low
5. Everything to be encased in a semi-presentable format

# GPIO 
Before setting off and ordering a load of parts for the Raspberry Pi, I wanted to make sure that I could actually work with the RPi GPIO pins via Dictu, which involved creating a GPIO library of sorts. This (luckily) turned out to be a lot simpler than I had first thought, it boils down to reading and writing to files depending on the desired action. With help from already written things, such as [this node library](https://github.com/JamesBarwell/rpi-gpio.js) and [this shell snippet](https://elinux.org/RPi_GPIO_Code_Samples#Shell),  I managed to create a very simple library that deals with exactly what I want. Before I get into the Dictu library, I thought it's best to explain a little about how the GPIO pins are controlled via the filesystem - if you're not interested in this part, feel free to skip to the next section.

All GPIO files are located within the `/sys/class/gpio` directory, in here is where we can `export` and `unexport` pins. `export`-ing a pin is essentially "activating" a pin on the RPi board, and this needs to be done before we can do anything with the pin. You export a pin by writing a pin number to the `export` file (note pin numbers here are BCM numbers and not physical pin numbers). Once the pin has been exported it will create a new directory with the name `gpio<num>` where `<num>` is the pin number which has just been exported along with other files within the new directory. For example, if we export pin 17 then it will create a new directory `gpio17` with the following structure:
```
gpio17  
-- active_low 
+-- device -> ../../../gpiochip0 
+-- direction 
+-- edge 
+-- power 
| +-- autosuspend_delay_ms 
| +-- control 
| +-- runtime_active_time 
| +-- runtime_status 
| \\-- runtime_suspended_time 
+-- subsystem -> ../../../../../../../class/gpio 
+-- uevent 
\\-- value 
```

After exporting a pin we next need to set its `direction`, since pins can be used for both input and output we need to tell the pin which it is we want to do, so for example, if we want to read data from a sensor we need to set the direction of the pin to `in` however, if we want the pin to act as a power output, e.g to power an LED, we need to set the direction to `out`. This is simply done by writing either `in` or `out` to the `direction` file. The next file we need to use is `value`. Similar to direction, how we interact with it is based upon whether our pin has been setup for reading or writing (in or out). If our pin is in an input state then we will read the `value` file, and based on the input from the external circuit, it will either read 1 (high) or 0 (low). Similarly, if we are in an output state, we use 1 (high) and 0 (low) however, we write these values to the `value` file instead of reading. There are obviously other files within the `gpio17` directory, but they were unnecessary for this project. Finally, once you are done with the pin we need to `unexport` it to clean the pin up. Just like exporting you write the pin number to the `unexport` file.

## Dictu GPIO
```js
import Path; 

class GPIO { 
    var PATH = "/sys/class/gpio"; 
    var ACTIVE_PINS = {}; 
    
    /** 
    * pin: BCM pin number 
    * direction: in or out 
    */ 
    static setup(pin, direction) { 
        if (pin < 0 or pin > 40) { 
            return Error("Invalid pin number, must be between 0-40"); 
        } 
    
        pin = pin.toString(); 
    
        if (!["in", "out"].contains(direction)) { 
            return Error("Pin direction must be in or out"); 
        } 
    
        var pinObject = Pin(pin, direction); 
        GPIO.ACTIVE_PINS[pin] = pinObject; 
    
        return Success(pinObject); 
    } 
    
    cleanAll() { 
        GPIO.ACTIVE_PINS.keys().forEach(def (key) => { 
            const pin = GPIO.ACTIVE_PINS[key]; 
            pin.cleanup(); 
        }); 
    } 
} 
    
class Pin { 
    var PATH = "/sys/class/gpio"; 
    
    init(private pin, private direction) { 
        this.unExport(); 
        this.export(); 
        
        while (!System.access("{}/gpio{}/value".format(Pin.PATH, this.pin), System.R_OK | System.W_OK).success()) { 
            System.sleep(0.01); 
        } 
        
        this.setDirection(); 
    } 
        
    read() { 
        var content = ""; 
        
        with("{}/gpio{}/value".format(Pin.PATH, this.pin), "r") { 
            content = file.read().strip(); 
        } 
        
        return content; 
    } 
    
    write(value) { 
        const allowedValues = { 
            true: "1", 
            false: "0" 
        }; 
        
        const writeValue = allowedValues.get(value, nil); 
        
        if (writeValue == nil) { 
            return Error("Invalid write value"); 
        } 
        
        with("{}/gpio{}/value".format(Pin.PATH, this.pin), "w") { 
            file.write(writeValue); 
        } 
        
        return Success(nil); 
    } 
    
    cleanup() { 
        this.unExport(); 
    } 
    
    private export() { 
        if (!Path.exists("{}/gpio{}".format(Pin.PATH, this.pin))) { 
            with("{}/export".format(Pin.PATH), "w") { 
                file.write(this.pin); 
            } 
        } 
    } 
    
    private unExport() { 
        if (Path.exists("{}/gpio{}".format(Pin.PATH, this.pin))) { 
            with("{}/unexport".format(Pin.PATH), "w") { 
                file.write(this.pin); 
            } 
        } 
    } 
    
    private setDirection() { 
        with("{}/gpio{}/direction".format(Pin.PATH, this.pin), "w") { 
            file.write(this.direction); 
        } 
    } 
}  
```

This is essentially the entire GPIO library used, written in Dictu. There could definitely be improvements made to it, however, I kept it incredibly simple for this project. Once I had this written I tested it using a breadboard along with an LDR (Light Dependent Resistor) I had lying around, and it worked great!

# Parts
Once I had a functioning GPIO library I was happy to get my wallet out and order the parts required to create this. I used [The Pi Hut](https://thepihut.com/) to order my parts and they were great (no this isn't a sponsored post).

## Parts List
- [Immersible Pump & WaterTube](https://thepihut.com/products/immersible-pump-watertube?variant=27740797585)
- [Soil Moisture Sensor](https://thepihut.com/products/soil-moisture-sensor?variant=20063171805246)
- [Relay](https://thepihut.com/products/gravity-relay-module-v3-1?variant=27740618897)
- [Ultrasonic Distance Sensor](https://thepihut.com/products/ultrasonic-distance-sensor-hcsr04?variant=1054704288)
- [Ultimate Resistor Kit](https://thepihut.com/products/ultimate-resistor-kit?variant=36476117073)
- [12V Power Supply](https://thepihut.com/products/arduino-universal-power-supply-12v-2a-high-voltage?variant=20063055773758)
- [Power Switch](https://thepihut.com/products/in-line-power-switch-for-2-1mm-barrel-jack?variant=27739226065)

**Total: £43.49**

Most of the parts in the list are fairly self-explanatory however I will explain about a couple of the parts in a little more depth.

### Ultrasonic Sensor
The ultrasonic sensor is effectively two speakers and a receiver, it pumps out a sound wave which bounces off an object and is caught by the receiver. This is useful to us because we can time how long it takes for the sound wave to bounce and come back and work out how far its travelled - this means we can work out whether or not we need to fill the "tank" up with water.

#### More Detail
Sound waves travel at 343m/s at sea level through air and if you remember back to your days of Physics lessons you may remember that `speed = distance / time`. We know the speed the sound wave is travelling, we are monitoring how long it takes and we are attempting to find the distance the sound wave has travelled, so with a bit of rearranging we end up with `distance = speed * time`. We however are not done there, this would give us the total distance travelled by the sound wave, which is 2 times to big (since it's hitting the water container and bouncing back), so we end up with `distance = speed * time / 2`.

### Relay
A relay is a fancy electronically operated switch. We need a relay here since our pump is working on 12V and the RPi works at 3.3V (also 5V pins), this means we will need a completely separate circuit setup, however it still needs to be controllable by the Pi.

![An image explaining the different parts of a relay](/article-assets/automatic-watering-system-with-a-raspberry-pi/relay.jpg)

A relay works by using an electromagnet to either open or close a circuit depending upon whether or not a voltage is being supplied to the signal pin and how the circuit is setup on the opposite side of the relay. If the circuit is setup via "Common" and "Normally Closed" this means the circuit is closed (not active) when there is no current being passed to the signal pin, however if it was setup so that it uses "Common" and "Normally Open" the circuit would default to open (active) when there is no current being passed to the signal pin. In our case we only ever want the pump to be active when we turn on the GPIO pin (signal pin) so in this scenario the "Normally Closed" option is chosen.

### Case
One of my requirements is that it is in a presentable format, in theory I will be using this system on 3 bonsai trees that I have growing and ideally I don't want an absolute mess around the trees, since you know, you don't want to have to gouge your eyes out. To do this I created my own case with a 3D printer. It is essentially in 3 different parts, the water container at the bottom holding the submersible pump and obviously water, the middle section which holds the Raspberry Pi and related electronics and then finally the lid. To design the different sections I used AutoCAD, which luckily for me, provides free access to students (again not a plug), otherwise you're looking at thousands for a license - which isn't really what I was looking to pay for a hobby experiment. Anyways... after a lot of pretending to measure things, and some trial and error, I ended up with these 3 designs:

#### Water Container
![An image showcasing the water container in Autodesk AutoCAD](/article-assets/automatic-watering-system-with-a-raspberry-pi/autodesk-watering-container.jpg)

#### Main Section
![An image showcasing the main section in Autodesk AutoCAD](/article-assets/automatic-watering-system-with-a-raspberry-pi/autodesk-watering-main.jpg)

#### Lid
![An image showcasing the lid in Autodesk AutoCAD](/article-assets/automatic-watering-system-with-a-raspberry-pi/autodesk-watering-lid.jpg)

And then it was finally time to print!

# Printing
A couple of failed attempts and a few days, I eventually reached a stage where I could begin placing components within the printed design!
![An image showcasing the 3D printed case](/article-assets/automatic-watering-system-with-a-raspberry-pi/3d-printed-case.jpg)

**Note: I did cheat here and use a breadboard and jumper cables, sorry.**

# Writing The Project Code
I was now at a stage where I had a proof-of-concept GPIO library written, and a container for the electronics; it was finally time to write the actual project code and finish this!

## Getting Soil Moisture Level
The first thing tackled was hooking up the soil moisture level sensor. Since the Raspberry Pi deals with digital inputs, this sensor will give off either a high reading or a low reading depending upon whether or not the soil is dry (configurable via a potentiometer).

```js
/**  
 * Get the soil moisture level. 
 * - 1 means the level is dry 
 * - 0 means the level is wet 
 */ 
def getSoilLevel() { 
    const pin = gpio.setup(17, "in").unwrap(); 
    const level = pin.read(); 
    pin.cleanup(); 
    return level; 
} 
```

The above code is hopefully fairly self-explanatory, we essentially get input from the sensor which is either "dry" or "wet".

## Measuring The Water Level
The main container sits atop of the water container, this allows us to measure the distance of a sound wave from the main section to the bottom of the water container telling us how much water is left in the container. The slight caveat here is that sound actually travels much faster in water than it does in air, which means it slightly throws off the distance measurement since we are using the constant at which it travels in air (343m/s). This in theory however should not make a difference, because it will give us a lower reading rather than higher, so we can just cater for this.

```js
/**  
 * Get the amount of water in the container. 
 * Printed container is ~3.7cm deep, this means if we hit 3 centimeters 
 * it needs refilling. 
 */ 
def getWaterLevel() { 
    const trigPin = gpio.setup(23, "out").unwrap(); 
    const echoPin = gpio.setup(24, "in").unwrap(); 
    
    trigPin.write(false).unwrap(); 
    
    // Settle sensor after reset 
    System.sleep(2); 
    trigPin.write(true); 
    System.sleep(0.00001); 
    trigPin.write(false); 
    
    var pulseStart = System.time(); 
    
    while (echoPin.read() == "0" and System.time() - pulseStart < 5) {} 
    
    var start = System.time(); 
    
    pulseStart = System.time(); 
    
    while (echoPin.read() == "1" and System.time() - pulseStart < 5) {} 
    
    var end = System.time(); 
    const pulseDuration = end - start; 
    
    /** 
    * Speed of sound at sea level is 343m/s 
    * Formula is speed = distance / time, however our formula is 
    * speed = distance / (time / 2), since we only care about the speed 
    * from the distance of the sensor to the object (not back again). 
    * 
    * 34300 = distance / (time / 2) 
    * 17150 = distance / time 
    * distance = 17150 * time 
    * 
    * Note: Speed of sound in water is faster, but that doesn't matter 
    * much in this case since it'll reduce the "distance", and we're 
    * checking for an empty container. 
    */ 
    
    const distance = pulseDuration * 17150; 
    
    trigPin.cleanup();
    echoPin.cleanup(); 
    
    return distance; 
} 
```

## Activating The Pump
Once we receive the signal that the soil is dry and the container is not empty, we then want to turn on the pump.

```js
/**  
 * Activate the water pump 
 */
def runPump() { 
    const pin = gpio.setup(18, "out").unwrap(); 
    
    print("Running Pump!!!"); 
    // Turn pump on 
    pin.write(true).unwrap(); 
    
    const startTime = System.time(); 
    // Wait until the sensor measures wet soil OR 5 seconds has passed 
    while (getSoilLevel() == "1" and System.time() - startTime < 5) { 
        System.sleep(0.1); 
    } 
    // Turn pump off 
    pin.write(false).unwrap(); 
    pin.cleanup();
}  
```

The script will run until the soil is wet OR until 5 seconds has passed. The 5 seconds is more of a failsafe incase anything goes wrong with the sensor and the pump is never switched off.

## Running
```js
/** 
 * Entrypoint 
 */ 
def monitor() { 
    const waterLevel = getWaterLevel(); 
    print("Water level {}".format(waterLevel)); 
    // Water is empty 
    if (waterLevel >= 3.7) { 
        print("Water empty!!"); 
        return; 
    } 
    // Water is getting low 
    if (waterLevel >= 3) { 
        sendNotification(); 
    } 
    const soilLevel = getSoilLevel(); 
    print("Soil level {}".format(soilLevel)); 
    if (soilLevel == "1") { 
        runPump(); 
    }
} 
```

Putting this all together we have our entry point, our "main" function if you will. The water container printed currently can has a depth of around 3.7cm, so we send a notification when we have around 3cm of distance because at this point the water level is getting low. The notification sent is an SMS message via [Twilio SMS API](https://www.twilio.com/docs/sms/api).

# Round Up
This was a really interesting project to make, I'm sure there are things that can be improved, or additional things that could be added however I'm currently at a stage where I'm happy with the project. Looking back I managed to hit those 5 requirements I'd set out to meet which, honestly, is not what I was expecting.

![An image showcasing the final product](/article-assets/automatic-watering-system-with-a-raspberry-pi/final-product.jpg)


Creating an automatic watering system with Raspberry Pi and the twist of using Dictu.

Automatic Watering System With A Raspberry Pi


A common problem which I face when using the Firebase Emulator with the Node.js debugger is that my debugger stops running when I am done, but the Firestore Emulator does not stop running. In this article I will explain how you can get around this issue.

Originally, to get around this I would go into my `firebase.json` configuration file like it suggests and would temporarily change the port. However, this method is not very efficient as you could run into the same issue over and over again. Luckily, there is an easy fix to this problem.

Using the `lsof` command you can list all open files and processes on a Unix-based system. Upon running this command you will find that you are presented with a long list, thankfully we can filter this down by just listing open files and processes on a specific port. In our case, the Firestore Emulators run on port `2255`, so we can run `lsof -i :2255` which should return a similar response to this:

```
COMMAND PID USER 
java 7254 my.user 
```

This shows us that `java` is running for `my.user` on process ID `7254` (your `PID` and `USER` values will be different). We can then take this information and run kill `7254` (replacing `7254` with your process ID) to kill the Firestore Emulators. This means that you will then be able to start the Firestore Emulators on the same port as before.

# TLDR
1. Run `lsof -i :2255`
2. Find the `PID` of java
3. Run `kill <the PID of java>`

I hope you find this trick useful, I know that it's certainly helped me out multiple times!


A common problem which I face when using the Firebase Emulator with the Node.js debugger is that my debugger stops running when I am done, but the Firestore Emulator does not stop running.

How To Kill The Firestore Emulator


Coming to the end of your University experience is an exciting but scary time. The joy and sensation of completing your graduation is rewarding, but then comes the time to go into the big bad world.
The obvious first thought is applying anywhere and everywhere. Whilst this is true, the importance of reading the advertised job description is just as important, as this allows you to see what the company requires and what the job entails. This ranges for various language skills along with personal experience. Rather than going through recruitment agencies, researching and applying with the company direct makes you stand out more compared to other candidates.
A common sight that you will see is that a large number of companies will require previous commercial experience, meaning on the graduate scale, we are overlooked by many. To counter this, keyword search is useful with the terms Graduate or Junior to ensure that the jobs which appear match these criteria or are close to that term. But don't let this stop you from applying to the companies that do require experience, as you'll never get the opportunity if you don't apply.
In my recent job search, I started applying whilst I had another 3-4 month left at University. This meant that in that time I had a few interviews and despite the rejection of the offer, I still gained the experience of what to expect in an interview. I had around 5 interviews, not being successful in 4 of them until I was offered a position from my final interview.

# How To Prep For Interview
When applying to companies, it's always important to attach a portfolio of your work, along with your CV. This allows the company to inspect your knowledge based on your code: having live examples of projects is also greatly beneficial. At the end of my last interview, the developer gave me a quiz to test my knowledge and then asked for my GitHub link so that she could "be nosy and look at my work" which showed some level of interest in me as a developer.

# The Interview
With the recent pandemic, half of my interviews were online; but this doesn't mean you can stay casual! Even at the comfort of your own home, dress to impress, well at least upper body, as I wore a smart jacket and shirt then had shorts on. Before joining the meeting, triple-check that everything is working, i.e. webcam and microphone - don't make a bad impression by not checking beforehand.

For my interviews which were face to face, I dressed to impress (this time including my lower body) and ensured I was prepared, arriving early to my meeting. There's nothing saying you aren't allowed to take notes or even help yourself to stand out. Have information about yourself ready to discuss, a copy of your own CV as well as information about the company you are applying for, or at least conduct research into the company before going and preparing questions to ask your interviewer.

**Remember:** You want to be leaving that interview confident and satisfied with your performance, even if you don't get the job in the end because someone was more qualified. Just be satisfied that you gave it your all and that you can be proud of that stage.

To summarize:
- Prepare and research the company before attending the interview
- Have questions ready to ask, quality is better than quantity
- Dress smart and look the part
- Be confident and ensure you sell yourself
- Don't be hard on yourself if you feel like you aren't getting anywhere, we all feel the same

I hope this helps you and good luck with a career in development!


Coming to the end of your University experience is an exciting but scary time. The joy and sensation of completing your graduation is rewarding, but then comes the time to go into the big bad world.

How I Got A Job After University During The Pandemic


When I was probably 9 or 10 (for reference, I'm 21), I remember playing Minecraft with my dad on our Xbox. I was a bright kid, and loved toying with redstone, so our world was filled with the random redstone projects I'd started, and very few I'd finished. I can still remember my dad asking me one simple question:
> Why don't you ever finish the projects you start?

I didn't have a good answer. I did make it my mission to complete the project I was working on then (a waterslide with levers at the bottom and top, using an XNOR gate so no matter which lever I flipped, the state would change), and I did. This was the first time I remember taking notice of my habit to do things halfway. It wasn't out of an inability to do the tasks; I just had (and have) so many ideas that I lose direction, and try to do all of them.

This is frustrating for a lot of reasons, especially when it comes to my professional development. My GitHub is littered with half finished projects that are set to private, and a few that are public as a way to motivate myself to continue working on them. I have a research paper on climate change sitting unfinished on my computer, and a Medium post in my drafts with a less academic version of the same content.

In my life as a young adult, I came to find out I have ADHD. This made a lot of sense and cleared things up, but I was still left with the feeling of not knowing how to maintain dedication to my projects without jumping around. So, how can we mitigate the negative effects of ADHD while capitalising on the strengths it gives? This is a question that I sat on for a while, and I don't think that there is a one-size-fits-all solution. However, there are definitely some tips that have worked for me as well as for many other adults (and kids/teens) with and without ADHD.

# Find Methods That Help You Focus
I know this seems silly, and the title is a bit. But I promise I'm gonna go more in-depth than just this. The first tip is to experiment. You won't get anywhere by blindly following lists and hoping they work. You need to experiment with various methods and use what works for you; what works for you might not work for everyone else. When I would ask my dad for advice on staying on task, he always had the same answer: \"discipline\". My father served nearly 23 years in the military, he had a strong sense of self-discipline and the ability to execute a defined task. After getting out of the Air Force, he got back into long-distance running, now running Ultra-Marathons, 100 mile races, and more. I obviously didn't have this same sense of discipline, and that wouldn't work for me.

Discipline is important still, but solely relying on self-discipline wasn't going to get me anywhere, I needed more than that. I'm a big fan of the Pomodoro technique. With this technique, you create a small cycle of work and rest, with a big rest after four iterations of the cycle. I personally do 25 minutes of work, 5 minutes of rest. After 4 iterations of this (2 hours), I take a 30 minute break where I typically do yoga, eat a meal, or even just watch YouTube. Knowing that I have a break after only 25 minutes helps to keep me working on my task. Additionally, the app I use for tracking this ticks like a clock, which serves to remind me to stay on task.

Another tip my dad gave, which I now live by, is to make lists. Relying on your memory to get stuff done might work, but it's also draining. Every time you complete a task, you have to spend the mental effort figuring out the tasks you have for yourself, and prioritise those tasks. This wears you out, and contributes to a concept called decision fatigue. Making decisions is tiring, mentally. If you make a todo list at the start of your day and give each item a priority, you can help eliminate this. You decide what's important once, and then you can just reference that throughout the day. You don't need to complete everything on your list, just something. Plus, it feels really satisfying to check items off your list. One of the things I found most useful is to reward yourself. Everyone's rewards will be different, but positive reinforcement is the best way to encourage a habit. One thing I find really important is to predetermine your rewards. Going back the todo list's concept of decision fatigue, trying to decide what to reward yourself with can make the act of rewarding yourself feel like a chore sometimes. When you take the time at the start of your day to consider your potential rewards, and maybe even assign them to each task, you eliminate the need to make a choice, you can just accept the reward and use your breaks as you see fit.

---

I still don't complete every task I do. But now, I get a lot more done than I used to. I'm able to motivate myself to keep working on something, even when it no longer has my interest, as long as I have a clearly defined goal to push me to work on it. I've also found a healthier work-life balance, and don't spend all my time either working, doing schoolwork, or trying to finish my portfolio website. I find time to relax, play videogames, and spend time with friends. Finding a system that works for me has helped me to become a happier, kinder, and more successful person, and it can do the same for you. It's not as tough as you might think, and you'll see the rewards pretty quickly.


Many people struggle with seeing a task through to completion. It can be really tough to find productivity methods that work for you, so the key takeaway is to try a few different ones out.

On Completion


One of the most frustrating things you will face as a developer is merge conflicts; however, sometimes there is no avoiding them. While merge conflicts aren't necessarily difficult to solve within your own code, they can be tricky if they occur in a pre-generated file like `package-lock.json` or `yarn.lock`. Thankfully, solving a merge conflict in one of these files is a lot simpler than it looks.

The first thing to do when you run into a merge conflict within `package-lock.json` or `yarn.lock` is to make sure you do not have any merge conflicts within your `package.json`. If you do have one, make sure to resolve it first - simply keep in the list of packages the ones you want to keep and remove any you do not.

Next, replace the contents of the `package-lock.json` or `yarn.lock` file with the contents of the file on the branch you are merging in from (for example, the `main` or `master` branch). This should mean that there are no changes if you went to merge from this point.

Finally, rerun `npm i` or `yarn` to install the missing dependencies. This will add or remove any dependencies you've changed in the `package.json` updating the `package-lock.json` or `yarn.lock` in the process. Your merge conflict will now be sorted!


One of the most frustrating things you'll come across as a developer is conflicts, what makes them even worse is when they are in programatically generated lock files.

Articles

Latest Articles

Some Useful C++ Tricks

Automatic Watering System With A Raspberry Pi

How To Kill The Firestore Emulator

How I Got A Job After University During The Pandemic

On Completion

How To Solve Conflicts In Package/Yarn Lock Files