DEV Community: Adam Roynon

I Wrote a Book - An Introduction to Code

Adam Roynon — Sat, 24 Apr 2021 16:52:50 +0000

I have wrote a book that explains how to program for new developers/programmers by using the Python programming language.
Python was chosen as it is an easy language to pick up and learn for new developers, there is not a huge amount of up front learning cost before you can start writing code.

About the Book

It starts by showing how to install Python, what variables are and how to use them, data structures, control flow techniques, object-orientated programming, etc.
There are plenty of small exercises and code snippets throughout to get you reading and writing code.

Near the end of the book there are bigger exercises (activities) that explain the process of creating bigger projects (a to do list, a simple login system, etc) with step-by-step explanations of the code and 'stretch' goals to challenge the reader further.

Theory/Computer Science

I also cover more theoretical/computer science concepts such as the difference between compilers and interpreters, how programming languages are created, how variables are stored and managed in memory, how different data structures work in memory, and more. These sections are all linked back to how Python works, to give the reader a better understanding of the programming language they have been using and learning.

Disclaimer

the digital/ebook copy is in full colour (unless reading on a b/w kindle). However, the paperback/physical copy is printed in black and white.
This was done to keep the cost down (Amazon charge a lot more for colour printing).
This should a very minimal effect on reading the book. There are little bits that talk about colour (when using the 'turtle' module and when creating GUIs).
This is just about how to change the colour the turtle uses and the colour of the background/foreground of widgets, this is not a major part of the book.
When you write the code out on your own machine you will obviously see all the colours.

Get a Copy

Affiliate Link: https://amzn.to/2QOKU4x
Non-Affiliate Link: https://www.amazon.co.uk/dp/B093CHHF5M
(The affiliate link will give me a bigger royalty/kickback on every sale)

This is the first book I have ever written, so any sales/feedback is very appreciated.
P.S. if you do pick up a paperback/physical copy please feel free to send me a photo of it on Twitter (@acroynon)

Favourite Part of Gamedev?

Adam Roynon — Tue, 20 Apr 2021 11:04:54 +0000

What is your favourite part of creating games?

Music, art, programming, marketing, finishing, promoting, testing, etc.

React Native or Native

Adam Roynon — Fri, 16 Apr 2021 20:20:00 +0000

Simple question: React Native, Flutter, actually native (Java/Swift), or something else?

Dependency Inversion Principle

Adam Roynon — Sat, 11 Apr 2020 08:37:05 +0000

The Dependency Inversion Principle is a component of The SOLID Principles. These principles set out simple rules to follow that allow us to create maintainable and easily extensible codebases. The dependency inversion principle states that any entity should depend on abstractions rather than concrete implementations. This basically means that when you have one class that is dependent on another class it should use polymorphism to depend on an abstracted interface rather than the concrete implementation of the class. This allows you to easily swap out concrete implementations without having to refactor all dependent classes.

The below code snippet shows an interface called 'UserRepository'. We are going to use this interface to create subclasses that handle users in our database. This is a common approach as it allows you to create multiple child classes for different databases or storage mediums. For example, we could have one child for a SQL database and another for an in-memory database.

public interface UserRepository {

  User findUserById(long id);
  boolean createUser(User user);
  boolean deleteUserById(long id);

}

Below we are defining a class called 'UserRepositoryImpl' which implements our interface. I haven't added all the code for the class, as we don't need to see that to understand the dependency inversion principle. So far we have an interface to define our operations and a concrete class for our user repository.

public class UserRepositoryImpl implements UserRepository {
  // Implement methods
}

Now we create a class that interacts with our repository. This class takes our user repository as a parameter in its constructor. As you can see it is using polymorphism to depend on the interface rather than the concrete class. This allows us to replace the implementation (or concrete class) without having to modify the dependency of our UserController class.

public class UserController {

  private UserRepository repository;

  public UserController(UserRepository repository){
    this.repository = repository;
  }

  // More processing and operations

}

This is the basis of the dependency inversion principle. Our class is dependent on an interface rather than a concrete class. However, it is important to note that you do not need to, and shouldn't, use this technique on every class in your codebase. Sometimes it doesn't make sense to use dependency inversion. If our implementation is not ever going to change then using the dependency inversion principle is pointless, as we will never have to switch out the implementation. If we are likely to change the implementation, such as changing the database implementation from SQL to in-memory, then it makes sense to use a dependency inversion approach.

This post was originally published on https://acroynon.com

Interface Segregation Principle

Adam Roynon — Sat, 11 Apr 2020 08:36:59 +0000

The Interface Segregation Principle is a component of The SOLID Principles. The SOLID principles are useful tips and rules to follow when writing software and code to create a maintainable and easily extensible codebase. The interface segregation principle states that any object or class should not be forced to override or implement any method that it does not use or any method that doesn't make sense for its context and purpose.

The below code snippet shows a simple interface called Bird. This interface has two abstract methods, 'walk', and 'fly'. When we implement, or inherit, from this interface we will be forced to override and provide a body to both of these methods. According to the interface segregation principle, we shouldn't implement this interface if it doesn't make sense for the object to override both of these methods.

public interface Bird {

  void walk();
  void fly();

}

Now let's create a subclass from our Bird class. The below class called Pigeon inherits from the Bird class. This means we need to override and implement both the 'walk' and 'fly' methods. This is fine and this makes sense, pigeons can both walk and fly. This doesn't break the interface segregation principle as it makes sense for a pigeon class to implement these two methods, we haven't forced any unexpected or unneeded functionality.

public Pigeon implements Bird {

  @Override
  public void walk(){
    //TODO
  }

  @Override
  public void fly(){
    //TODO
  }

}

Let's look at another example. The below class creates a Dodo class that inherits from the Bird class. This is where we are breaking the interface segregation principle. If you didn't know, a Dodo bird cannot fly. This means, by inheriting from the bird class, we are forcing our Dodo class to implement a method that is doesn't need and that it doesn't make sense for it to have. Often times in large codebases inheritance is used to avoid duplicating code and when the interface segregation principle is broken the method is simply given a '//noop' comment. This stands for 'no operation'. Never use a '//noop' comment.

public Dodo implements Bird {

  @Override
  public void walk(){
    //TODO
  }

  @Override
  public void fly(){
    // noop
  }

}

Instead of using a bird class we can create an interface called 'CanFly', as shown below. This will allow us to inherit this interface on only the classes where it makes sense, and we would also be able to use it on classes that aren't types of birds without confusing our inheritance tree. This is a more abstract way of thinking about objects and classes as we are not assigning names to nouns that exist in the real world (e.g. bird, dodo, pigeon). This is often the reason why beginner developers break the interface segregation principle.

public interface CanFly {

  void fly();

}

This post was originally published on https://acroynon.com

Liskov Substitution Principle

Adam Roynon — Sat, 11 Apr 2020 08:36:54 +0000

The Liskov Substitution Principle is a component of The SOLID Principles which helps you create maintainable and extensible code. This principle states that any class should be able to be substituted for any of its subclasses without any issues. This basically just means that if you have a parent class and a child class you should be able to use the child class in any place where the parent is used without your program blowing up in errors.

The below code snippets shows a very simple piece of code. First, a User object is created called 'john'. We pass the value "John" into the constructor of the class and then print out the value from the 'getName' method to the console. This basic example will effectively set the passed in value to a variable and then print out the variable to the console.

public class Main {

  public static void main(String[] args){
    User john = new User("John");
    System.out.println(john.getName());
  }

}

The code below looks exactly the same to the above code snippet. The only difference here is that we have changed the concrete implementation class to "Person". Other than that the code should function exactly the same. We are assuming in this example that the Person class inherits from the User class, it is a child of the User class. This is a prime example of the Liskov Substitution Principle, the subclass can be used instead of the base class and the code still makes sense and still executes.

public class Main {

  public static void main(String[] args){
    User john = new Person("John");
    System.out.println(john.getName());
  }

}

The Liskov Substitution Principle is a simple principle to understand and a simple concept to understand. It is important to understand that it is a one way track. Any subclass can replace any usage of its base class like shown above. However, the reverse is not true. You cannot replace a usage of a subclass with a base class. Usually, a subclass adds functionality or extends from a base class, therefore, replacing a usage of a subclass with a baseclass does not make sense as the base class does not have the added functionality.

This post was originally published on https://acroynon.com

Open-Closed Principle

Adam Roynon — Sat, 11 Apr 2020 08:36:39 +0000

The Open-Closed Principle is a component of The SOLID Principles. These principles can help you write software that is easy to extend and maintain whilst also avoiding code smells and bad design in your codebase. The open-closed principle states that any object should be open for extension but closed for modification, you should be able to add functionality to an object without having to modify its source code. This probably makes zero sense, as you must modify the code to add functionality. However, these principles are for the object-orientated programming paradigm. Within OOP we can use inheritance to extend the functionality of objects without having to change the base class source code. If you don't understand inheritance or want a refresher please check out this post first - What is Inheritance?

The below code shows a simple class called Person that contains two fields, 'firstname' and 'lastname'. I have ommitted the getters and setters from this code snippet and all other snippets on this post as those are not important in regard to what we will be discussing.

public class Person {

  private String firstName;
  private String lastName;

  // Getters & setters
}

We can maintain the open-closed principle by creating another class and extending it from the Person base class. This allows adding functionality, or additional fields, to the class without having to modify the original base class source code. This makes our base class closed to modification, as we haven't change the code, but open for extension, as we have inherited it's functionality and fields and added to it.

public class Employee extends Person {

  private String jobTitle;
  private long employeeNumber;

  // Getters & setters
}

Let's look at an example that breaks this principle. Below we have another simple class called Shape which has two fields, the width and height. We are going to use this class as our base class, so we won't change it or modify it but we will use inheritance to extend the functionality.

public class Shape {

  private int width;
  private int height;

  // Getters & setters
}

We can now create another class called Rectangle to extend on this behaviour and add a 'getArea' method. This allows us to calculate the area of a rectangle, and we don't have to re-create the 'width' and 'height' fields as we have inherited them from the base class. This keeps in line with the open-closed principle, we haven't broken it yet.

public class Rectangle extends Shape {

  public int getArea(){
    return width * height;
  }

}

If we create another child of the Shape class to handle circles it starts to not make sense. Circles do not have a width and height, they have a radius. We could stay with the width and height fields and still make this work, as we can still work out the area of the circle. However, this starts to make our model more complicated and harder to maintain. To make this new class make sense in our model we would probably have to change our base class to allow the difference in fields. Think about what would happen if we added a Triangle class or a Hexagon class. Could we add them without changing the base class or would we have to change the Shape class for them to make sense? Changing the base class breaks the open-closed principle, as we have now modified our base class.

public class Circle extends Shape {

  public int getArea(){
    // ??
  }

}

The examples shown in this post are very simple examples to convey the open-closed principle in an easy to understand way. It is important to note that sometimes you do have to refactor your code, or your base class, to add functionality. For example, when you are first building your software or your service you will be constantly changing the model and refactoring your code due to bug fixes and adding functionality. This is just a general rule when adding functionality to an existing or more established codebase. To be summarised and put simply, when adding a subclass of any class or interface you shouldn't have to change the parent class or interface.

This post was originally published on https://acroynon.com

Single Responsibility Principle (SRP)

Adam Roynon — Sat, 11 Apr 2020 08:36:25 +0000

The Single Responsibility Principle (SRP) is one of the aspects of The SOLID Principles. It states that every class or object should have one purpose, one responsibility and effectively one reason for existence. This principle is concerned mainly with object-orientated programming but it can and should be thought about at a deeper granularity. Every function or method should have one reason to exist, do one thing and only one. It should do one thing and do that one thing well.

Following the SRP can help you keep your code maintainable, flexible and easy to read. Imagine being able to read your code and understand exactly what it is doing without having to run the code or read every line completely. This will make the code easier to refactor and generally just easier to deal with.

Simple Example

Let's look at very simple to identify an example. It can be quite difficult to identify an entity that is going against the SRP. We start with a simple Square class that holds one field, the side length of the square. There are two methods in this class, the getter, and setter for our one field. It is clear that this class has one responsibility and therefore follows the SRP. It is responsible for holding the one field 'sideLength'.

public class Square {

  private int sideLength;

  public int getSideLength(){
    return sideLength;
  }

  public void setSideLength(int sideLength){
    this.sideLength = sideLength;
  }

}

Now we add a method called 'getArea' that returns the area of the square. We have added additional functionality to our class, so now it can do two things. You may think that this now goes against the SRP as it has two things it is responsible for, the side length and calculating the area. However, if we change the abstraction of our SRP context we can see we are still following the rule. Instead of the class being responsible for looking after one field, it now looks after our "Square" shape and the fields and operations we need for that object. It is responsible for handling Square shapes. It is important to note that each method in our class is responsible for one thing, our "getArea" method doesn't do anything else apart from returning the calculated area.

public class Square {

  private int sideLength;

  public int getSideLength(){
    return sideLength;
  }

  public void setSideLength(int sideLength){
    this.sideLength = sideLength;
  }

  public int getArea(){
    return sideLength * sideLength
  }

}

Now it's time to break the single responsibility principle. We have added a method to our square class called 'isUserAuthenticated' which will check is a user is authenticated with our system. It is clear that this method is out of place, it doesn't belong in this class as it has nothing to do with our Square object. This new method has broken the SRP in the context of our class.

public class Square {

  private int sideLength;

  public int getSideLength(){
    return sideLength;
  }

  public void setSideLength(int sideLength){
    this.sideLength = sideLength;
  }

  public boolean isUserAuthenticated(User user){
    // Do something here
    return false;
  }

}

Real-Life Example

The previous example was pretty obvious when we broke the single responsibility principle. Now let's look at a more real-life scenario that you might deal with in a real codebase or on the job. The below class User shows a bunch of fields that correspond to a user; their username, password, first and last name, date of birth, address, etc. Technically this is following the SRP as it only deals with stuff to do with a user, there is nothing strange or out of context in this class. However, if we look closer and think about what other code might be inside this class we could argue differently.

public class User {

  private String username;
  private String password;
  private String firstName;
  private String lastName;
  private Date dob;
  private String addressFirstLine;
  private String addressSecondLine;
  private String Country;
  private String addressPostcode;
  private String contactNumber;
  private String emailAddress;

  // Getters & Setters
  // + validation

}

We could argue that the address portions of the class are to do with something else, they have a different context. We could move these out into a new class called Address. We could argue the same thing with the contact number and email address fields as they're to do with ContactDetails. These are simple ways we can reduce the scope of our class while still keeping true to the SRP.

With each of these fields, we may have validation, to ensure a strong password or a valid email address. The validation of these fields could be moved to a separate location, as validation is a different responsibility for holding the information. We might also have database code within this class, to save and retrieve Users from our database. This code could also be moved outside of the class. As you can tell the SRP can get very complicated when dealing with real-world examples, but it is important to think about what your class's purpose is and extract any other code. Is it's purpose to hold information about the user, to validate a certain field, to handle database interactions, to handle logging?

Spring AOP

When dealing with logging and security in code it can be hard to follow the Single Responsibility Principle. You need to ensure that an unauthenticated user cannot access this piece of code, so you wrap it in an authentication check. You need to log out to a file when a new database item is created so you throw some logging lines around the code. These sorts of examples go against the SRP as now your code is handling logging as well as security or database interaction.

Fortunately, if we use Spring, which is a framework for the Java programming language, there exists a module called Aspect-Oriented Programming (AOP). I won't be going into detail about how to use AOP or how the below code works, as I'll save that for another time. AOP allows us to extract out these cross-cutting concerns, such as logging or authentication. A cross-cutting concern is basically some piece of code or functionality that appears across a lot of modules or places in the code. Using AOP we are able to extract out these concerns and still follow the SRP.

@Aspect
public class UserAspect {

  private static final Logger LOGGER=LoggerFactory.getLogger(UserAspect.class);

  @Before("execution(public String getPassed())")
  public void getNameAdvice(){
    LOGGER.info("Executing Advice on getPassword()");
  }

  @Before("execution(* com.acroynon.spring.service.*.get*())")
  public void getAllAdvice(){
    LOGGER.info("Service method getter called");
  }

}

This post was originally published on https://acroynon.com

The SOLID Principles

Adam Roynon — Sat, 11 Apr 2020 08:33:42 +0000

The SOLID principles are a set of 5 rules to follow for object-orientated Programming (OOP). These rules or principles can be used to create software that is easy to extend and maintain while avoiding code smells and allowing simple refactoring. Obviously, these 5 principles are not a silver bullet and they won't fix any codebase or make your codebase magic. Even while following these rules you can write code that makes maintenance and refactoring difficult. These rules should act as good things to keep in mind while designing and writing software but they can also be used in conjunction with coding guidelines and other concepts, such as design patterns.

I will be covering all of the 5 principles in this post but I will also be linking to other posts where I explain each principle in more depth with code examples and snippets. If you don't understand OOP or want a refresher I would suggest reading these posts where I explain the basics of OOP before continuing

Classes and Objects

Interfaces and Abstract Classes

Inheritance and Polymorphism

Single Responsibility Principle

The Single Responsibility Principle (SRP) is probably the easiest of the 5 principles to understand. Every class should have one and only one job. This seems simple and most developers will be able to tell you this even if they struggle to follow it. The difficult thing to understand with this principle is that the single responsibility of a class can be very specific or a bit more abstracted. For example, you could have one class whose purpose is to hold the data for a rectangle, it's size and position, but then you could have a more general-purpose for a class where it holds all the data for a rectangle but also handles calculating it's area and perimeter. The second example has multiple jobs it can do, it can calculate it's area or perimeter but it still has a single responsibility - to handle the rectangle. If this same class also handled user sign it no longer has one responsibility and therefore breaks the SRP.

The important thing to remember about the single responsibility principle is that each class should have a single clearly defined purpose for existing and do only one thing. This one thing can be very specific, such as handling a rectangle, or a bit more generic and have multiple operations, such as handling user authentication. This principle can also be extended to a smaller scope, each class should have a single purpose and each method within that class should have a more specific single purpose.

Read more about the Single Responsibility Principle here.

Open-Closed Principle

The Open-Closed principle states that objects should be open for extension but closed for modification. This means that any object should be easy to extend or add functionality too but shouldn't be modified or changed. This principle is quite difficult to understand to begin with, as it doesn't make sense outside of an OOP paradigm. Let's imagine we have a piece of code that handles a particular functionality, we then compile that code so that we cannot change it. We should be able to add functionality to the code, to make it open for extension, without modifying the source code, to make it closed for modification. Obviously outside of OOP, this is impossible as to add functionality we must first change the source code and then recompile the code. However, in OOP you can use the compiled source of a class and inherit from it in a new class - the new class would be a child of the pre-compiled class. Inheriting from a base class allows you to add functionality that the base class doesn't have but also keeps the base class closed from modification. Simply put, when inheriting from a base class you should not have to change or modify the base class.

Read more about the Open-Closed Principle here.

Liskov Substitution Principle

The Liskov Substitution Principle states that any subclass should be able to be replaced in any place where the base class is used. This means that if there is a place in your code where you are using a base class, or any class that has children, then any of its children should be able to be used without the code-breaking or changing. It shouldn't make a difference or create an error or bug if you replace a base class with an implementation of any of its children classes. This principle ensures an inheritance tree that actually follows proper inheritance and enforces you to think about your inheritance hierarchy and don't just extend from a base class to copy functionality.

Read more about the Liskov Substitution Principle here.

Interface Segregation Principle

The Interface Segregation Principle states that a class should not be forced to implement an interface or method that they do not use or that doesn't make sense in that context. It is common to use polymorphism when coding in an OOP context, so you can use generic code on many different concrete implementations. However, this can lead to making a class implement an interface, to allow polymorphism, that doesn't actually make sense. For example, a class that deals with contact information shouldn't implement from a class or interface that deals with a person's wage or hourly rate. Another reason people break the interface segregation principle is because their interfaces have too many methods in them. Let's say you have an interface that forces two methods to be implemented "talk" and "fly" which we use on implementations of different types of birds. However, some birds don't fly, so if you create a class for the Dodo bird you will implement from this interface and then be forced to implement the "fly" method which doesn't make sense in this context. This doesn't mean every interface should just have one method. Breaking your interfaces down into sensibly sized components is a difficult thing and will most likely result in refactoring your codebase later. The Entity Component System design pattern is a good example of the interface segregation principle.

Read more about the Interface Segregation Principle here.

Dependency Inversion Principle

The Dependency Inversion Principle states that any entity should depend on abstractions and not concrete implementations. This means that you should use polymorphism to make your classes depend on interfaces or abstract classes instead of the concrete implementations of your dependencies. This allows you to easily swap out the concrete implementations without having to refactor your base class. This is a useful rule to follow but it can get out of control quite quickly, as you could create an interface for every concrete class in your codebase.

Read more about the Dependency Inversion Principle here.

The SOLID principles are great rules to follow and can keep your codebase easy to maintain, extend, and avoid smells. However, taking any of these principles and running with it can actually make your codebase worse. For example, making your code completely closed to modification will prevent any refactoring or feature changes, making every concrete class depend on interfaces that will result in a huge codebase to manage, etc. It is important to review your codebase and if you can't follow a principle completely that is okay. As with a lot of software-related tips and tricks, treat them as good guidelines not as strict regimes that must be followed completely.

This post was originally published on https://acroynon.com

What is Steganography?

Adam Roynon — Thu, 09 Apr 2020 12:31:53 +0000

Steganography is the process of hiding a message, file, video, or picture within another message, file, video or picture. The key of steganography is that the medium that is used to hide the secret message, such as the image you use to conceal your message, looks completely normal to the untrained eye. This is the main difference between steganography and standard encryption. Any encrypted message looks as though something is hidden or concealed within the encrypted value whereas a message hidden within a seemingly normal picture is a lot harder to spot.

Digital Techniques

Steganography can obviously be used to hide digital information within other digital items. For example, hiding a message within a digital photo or within a video file. There are different techniques that can be used to hide the secret message or information, each with there own pros, cons, and level of difficulty and complexity.

Least Significant Bit (LSB)

The Least Significant Bit steganography technique is the process of manipulating the bits of a digital file to hide a secret message or another file. This is often done with images but can be applied to any digital file. All files are made up of bytes which are in turn made up of 8 bits (one bit is either a 0 or a 1). The LSB technique involves taking the last bit of each byte and changing it to encode a message or file. You translate your message or file into bits and then use the LSB (the last bit, or two last bits, of each byte) of your disguised file to hide your message's or file's bits. For example, if the first three bits of your hidden message are 010 then you could change the first three LSB's of your disguised file to 010 to hide your message.

The reason why LSB is used within steganography is that when changing one bit, especially the bit with the lowest value (the least significant bit) it does not change the disguised file a lot. If you applied this process to a photo, of hiding a message within an image, the appearance of the image would not change a lot, it may become more grainy but it shouldn't look suspicious. This is because you are not changing the value of each byte by a lot.

11010010 = 210
11010011 = 211

Often times a hidden message within an image will either be repeated across the entire image or hidden within a specific section of the image.

If you don't understand how binary works or want to learn more about the process of converting decimal numbers to binary and vice versa then please check out this post - Bits, Bytes, and Binary

Spectrogram

A spectrogram is a way to visualise sound. Spectrograms are essentially graphs of sounds that have an X and a Y-axis which correspond to time and pitch respectively. You can convert any sound or song into a spectrogram and vice versa. Therefore you could create a spectrogram with a message by just drawing/writing your message across the graph. This graph could then be converted into sound, therefore, resulting in your message being hidden within a sound file. Reversing the process would then result in your message being the outcome/result. you could also do the same thing but use an image instead of a message, so you draw an image in the spectrogram graph and then convert that into audio. You might be thinking that a piece of music created from a written out word wouldn't sound very good and that the point of steganography is to hide the message in plain sight. You would be absolutely correct, which is why the 'secret' part of the music is often surrounded by other music that sounds normal or at least doesn't have secret messages. Therefore you have a long piece of music with only a couple of seconds that contain a secret message or image. There are rumors that famous musicians and bands have used spectrogram techniques to hide images and messages within their own songs.

RGB Channels

All digital images are made up of a collection of pixels, each of which is made up of three colour components (red, green, and blue). Every colour is then created by mixing the intensities of these three colours together. For example, mixing red and blue together creates purple. Each one of the three main primary colours, red, green, and blue, are called colour channels. One way to hide a message or image inside another image is to hide it within one of these colour channels. The secret is then revealed by taking the original image and removing the colour channel sections. This would return a single coloured image (either red, green or blue) for each channel. One or more of these single-channel images will contain your secret information, you can hide a different secret message in each of the three channels. When combining all these channels together the resulting image will make no sense and you won't necessarily be able to see the hidden message(s).

Physical Steganography

Steganography does not have to happen with just digital content though. You can apply different approaches to physical mediums to hide messages and information in other-wise inconspicuous items. Think of one of those books that is actually a safe or money box, it looks like a book when it is in a bookshelf but it actually hides your money.

Invisible Ink

The most obvious way to hide messages that most people have seen or used before is invisible ink. You could write a normal-looking letter using a normal pen and then use an invisible ink pen to hide a message within the letter. A normal person would not be able to see the secret message and it would look like a normal letter, but by revealing the invisible ink you could see the hidden message. Invisible ink is resolved either by using a special solution, heat, lemon juice, etc. Invisible ink is probably the easiest and most well-known method of steganography using a physical medium.

Null Cipher

Another very well known traditional steganography method is called a null cipher. A null cipher is a method used to hide a message within a lot of other non-cipher material or text. You could write a big paragraph of text and then hide your secret message in that text. There are many methods to achieve this, you could make every 5th word of the paragraph be a word of your secrete message or to have unusually capitalised letters, or missing letters, etc. Null ciphers are often used within movies and TV series to hide secret messages as they're simple for the viewer to understand without needing much explanation. There have also been stories of null ciphers being used for prisoners to communicate with people outside prison using letters/messages.

Microdots

During World War I and II there was a steganographic approach used by Germany to send hidden messages called microdots. Microdots is the process of taking the secret message and turning each part into different shapes or different sized shapes. Those shapes are then written very small onto the non-suspicious letter. During the war, this process was used to conceal messages into microdots and then hiding them underneath the postage stamps of sent letters. The actual letter wouldn't contain any important information but the microdot message could contain important information such as enemy movements or military plans and updates. This was not the only method used during the war to conceal messages though.

Steganographia

The first recorded use of steganographic techniques was in 1499 by Johannes Trithemius. He was german polymath, cryptographer and much more. He wrote a book called Steganographia in 1499. This book consists of 3 volumes each of which contains different steganographic methods and many hidden messages. The books were designed to look like they were about magic and about how to use spirits to communicate over long distances, which is the medium Johannes used to conceal his messages. He used various techniques in his books to conceal his messages such as null ciphers, hiding messages within data tables, astrological data, etc. The third book is believed to contain hidden communication with Queen Elizabeth I.

That is all I'm going to write about Steganography. I didn't want to write too much as I may want to take each section I've covered and go into more depth in a different post. However, I hope I've given you enough to understand the basics of Steganography its uses and methods, as well as given you some ideas to look into and learn more about it.

This post was originally publish on https://acroynon.com

JavaScript Destructuring Explained

Adam Roynon — Sun, 05 Apr 2020 12:18:11 +0000

The JavaScript destructuring expression is a way to pull specific fields out of objects without having the entire object. This can be used either to just simply rip out values from an object and run checks against them. However, it is probably best used in function parameters, as it allows you to send a configuration object into the function and then only rip out the values you need within the function. This will become clearer with the following examples and I will also show you different ways of using the destructuring expression.

The below example shows a simple usage of the destructuring expression. First, there is an object defined called 'person' with three fields: 'firstname', 'lastname', and 'country'. Then I'm declaring two variables called 'firstname' and 'lastname' and setting their value equal to the person object. Notice the curly brackets in the instantiation of these two variables, this is the destructuring operation. This tells JavaScript to check the 'person' object for a field with the same name and take its value. This then allows you to log out of the two variables from the object as if they were declared globally.

const person = {
  firstname: 'Adam',
  lastname: 'Roynon'
}

let { firstname, lastname } = person

console.log(firstname, lastname);

An important thing you can do with the destructuring expression is use it within function parameters/arguments. The below function destructures a passed-in object to extract the variables 'firstname' and 'lastname'. If we call the function and pass in the same object as before those two variables will be instantiated as if they were passed in as normal arguments and not within an object.

const person = {
  firstname: 'Adam',
  lastname: 'Roynon'
}

function printName({ firstname, lastname}){
  console.log(firstname, lastname);
}

printName(person);

You won't always know the structure of a passed-in object, it may not have the specific fields we want. This is where default values come in, we can set a default value to a field so that if the field doesn't exist within the passed in configuration object then it's default value will be used. The below example shows an object similar to the previous object, but with the 'lastname' field omitted. The destructured arguments to our function have changed, as are now setting a default value of "Roynon" to the 'lastname' field. Because the passed-in object 'person' does not have a field called 'lastname' so the default value is used, otherwise the 'lastname' variable would be initialised with the passed in object's value.

const person = {
  firstname: 'Adam'
}

function printName({ firstname, lastname = "Roynon"}){
  console.log(firstname, lastname);
}

printName(person);

This ability to set default values can be used within any destructuring operation, not just within a function's arguments. The below example shows the same process as the previous example but instead of using a function we are destructuring the object fields into globally scoped variables. The 'lastname' field again has a default value of 'Roynon'.

const person = {
  firstname: 'Adam'
}

let { firstname, lastname = "Roynon" } = person

console.log(firstname, lastname);

Objects in JavaScript are not always a flat structure, they usually have a more hierarchical structure and have nested objects and fields. We can still use destructuring to grab these nested fields and instantiate them into separate variables. The example below shows how to pull the 'country' field out of the nested 'location' object. It is important to note that 'country' will be pulled out as a separate field and it won't be within a 'location' object when destructured, there will be no 'location' object after the destructuring operation, just the three variables 'firstname', 'lastname', and 'country'.

const person = {
  firstname: 'Adam',
  lastname: "Roynon",
  location: {
    country: "United Kingdom"
  }
}

let { firstname, lastname, location: { country } } = person

console.log(firstname, lastname, country);

You can also use different names for the variable once they have been pulled out of the object via destructuring. The below example shows pulling the 'firstname' and 'lastname' fields from the 'person' object. We are then using the colon symbol ':' to assign new names to these two variables. Now the values from the object will be assigned to the variables 'fName' and 'lName' instead of the names from within the object.

const person = {
  firstname: 'Adam',
  lastname: "Roynon"
}

let { firstname: fName, lastname: lName } = person

console.log(fName, lName);

We can also use destructuring on arrays, it doesn't have to be used on an object. The below example shows an array with 3 elements and then using the destructuring operation to assign the names 'red', 'green' and 'blue' to those elements. Notice how we are using square brackets instead of curly brackets when destructuring an array vs an object. The values of the elements within the array will be assigned the three new variables. So the final log statement will print the number '125', '255', and '50'.

const myArr = [125, 255, 50];

let [red, green, blue] = myArr;

console.log(red, green, blue);

You don't have to pull out every element from an array, you can pull out a subset. The below code snippet will pull out the first two elements from the array. So the final statement will print the numbers '1', and '2'.

const myArr = [1, 2, 3];

let [one, two] = myArr;

console.log(one, two);

We can also skip values within an array. Let's say we wanted to pull out the first and last element from the array. We can skip an array element by putting in an extra comma in the destructuring operation. You can skip as many elements as you want with additional commas, and at any position in the array or destructuring operation.

const myArr = [1, 2, 3];

let [one,, three] = myArr;

console.log(one, three)

This post was originally published on https://acroynon.com

JavaScript Spread Operator Explained

Adam Roynon — Tue, 31 Mar 2020 21:39:39 +0000

The JavaScript spread operator is a way to expand an array or list into a concatenable type. This will make more sense after looking at a few examples and code snippets. If you do not understand arrays or lists within JavaScript please read this post first - Arrays and Lists in JavaScript

If we want to combine two arrays in JavaScript we can use the Concat function, which stands for concatenation. This function does not affect the arrays, it returns a new array with the combination of the two arrays. The 'result' variable in the code snippet below will contain an array with the number 1 through 10 inside.

var arr1 = [1, 2, 3, 4, 5];
var arr2 = [6, 7, 8, 9, 10];

var result = arr1.concat(arr2);

We can achieve the same thing by using the spread operator. The spread operator is represented by three dots/periods (...). To concatenate two arrays we first create a new array by using two square brackets, then the first element we use the spread operator on the first array and we do the same with the 2nd element and 2nd array. The spread operator will expand the arrays into there elements. So the 'result' variable will contain the number 1 through 10, as before.

var arr1 = [1, 2, 3, 4, 5];
var arr2 = [6, 7, 8, 9, 10];

var result = [...arr1, ...arr2];

If we didn't use the spread operator, as shown below. The 'result' array would contain two arrays, inside of 10 numbers. The first element would contain an array/list of the number 1 through 5 and the second element will be another list with the number 6 through 10.

var arr1 = [1, 2, 3, 4, 5];
var arr2 = [6, 7, 8, 9, 10];

var result = [arr1, arr2];

You can also combine raw values and a spread operator to create a new array. The below result variable will contains a list of number from -2 to 5. This is because we are adding the raw value -2, -1, and 0 and then concatenating the 'arr1' list using a spread operator.

var arr1 = [1, 2, 3, 4, 5];

var result = [-2, -1, 0, ...arr1];

You can also use array methods, such as the filter function, in combination with the spread operator to create really custom lists. The below 'result' variable will contain a list of number from 3 to 6. Without the spread operator the result variable would contain two arrays instead of a list of just numbers.

var arr1 = [1, 2, 3, 4, 5];
var arr2 = [6, 7, 8, 9, 10];

var result = [...arr1.filter(i => i > 2), ...arr2.filter(i => i < 7)];

This post was originally published on https://acroynon.com