In our modern society videogames have become a

In our modern society videogames have become a ubiquitous piece software that many use as a form of entertainment. They are on everything from dedicated home consoles and PCs to handheld devices and most prominently, smartphones. Videogames as software can range from extremely simple text based games to complex 3 dimensional environments with intelligent AI systems controlling events throughout the game.

Game development can be a great exercise for any upcoming software engineer to practice their skills. A single person is capable of creating a game as was the case originally with the popular game Minecraft. Minecraft, as many may already know is a open world that is famous for its randomly generated terrain and complete freedom in destroying and building in the world around you. In this simple game there is AI controlling the in game monsters, physics that dictate how you jump, fall, and swim. A dataset of different types of blocks that make up the game, and a world generator that utilizes different rules to create a landscape that is random yet results in a world that is cohesive and believable.

In contrast to the random generation and world state tracking done in Minecraft, other games such as portal specialize in their ability to create believable physics as well as their signature reality bending portals. The game allows you to seamlessly move through portals and stand anywhere in between and also involves physics of items and liquids dropping and moving in a believable way. Physics is an important part of the game and can prove difficult in itself to design from a software perspective.

Aside from these however, games can be as simple as a 2 dimensional platformer that only needs to consider at a basic level the act of moving left or right and jumping, or even a turn based game that needs only consider strict choices that are given to the player to interact with the game world. Game development, just like any good software has a development cycle and will go through a development, alpha, beta, and release cycle where the software will take shape and become a finished product over time. As the game becomes more complex, bugs and other problems may arise that must be dealt with and code optimization and organization becomes important. It can involve multiple people and repository management as projects become more and more complex, too complex even for just one person to deal with. Often the gamification of a task can make it more enjoyable and rewarding to practice so why not apply this to software. If it interests you it can be a great way to practice your skills and even discover new practices that can help in other programs you create.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

               Within the modern world of computing, the creation of intuitive front-end systems is essential in the pursuit of user friendliness. Front Ends are what make a program, or website accessible to most people. Databases use front-ends to allow users to search or browse their contents in a format that is easily accessible and usually provides tools related to searching said database. Complex programs can utilize front ends to abstract the complex inner workings of said program and boil them down to a simple screen that guides the user and tells them what to do.

               With this in mind, it is important to consider that a front end must also be clear in its design. A well thought out front end will make it even easier for a user to understand what the front is created to accomplish. Oftentimes these types of jobs are handled by dedicated designers, especially since languages such as CSS, HTML and Javascript, while in a basic sense are similar to writing code in C++, or Java, however they usually have much less depth to them as these front end languages usually serve only to request data from the backend and return a response.

               What we have here then is a classic situation of design philosophies vs engineering philosophies. One seeking to appeal to as many people as possible and the other focusing on functionality first and foremost. Often design and practicality can be at odds with each other as some designs might be impractical or vice versa with some engineering decisions being unappealing. This is where one who works in front-end development can bridge the gap between the two philosophies.

To that end we can look at a website such as Thea Food Pantry which was shown in recent activities pertaining to front end design and implementation. It is a simple program but does its job well while offering a fairly user friendly experience. A list of items and a button with a prompt next to it to allow a user to add items. The page is easy to read but is functionally sound.

               When designing software, there are two goals in mind when a user visits your site. It must be appealing and easy to navigate as well as quick to guide potential customers to a desired product. To be an effective front end designer, it is imperative to understand how to structure the website to be both practical for seamless backend integration and visually appealing to the user in a way that emphasizes what is most important to them. The breadth of knowledge afforded by understanding front end design and implementation gives an important viewpoint for software development and how the average user might view your web application.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Last week we took a look at API Design and discussed the importance of keeping an API as simple as possible. (Learn more about last week’s post here: https://georgechyoghlycs343.wordpress.com/2021/10/28/api-creation-why-simple-is-better/)

This week we will take a look at how this simplicity should be applied not only to APIs but to all programs regardless of purpose or language. As programs become more and more complex it only gets harder to properly keep track of every facet of said program. Having to remember every method and class separately can quickly become a grueling task that eats away at the time, productivity and morale of a software developer.

Within this video the speaker, a professor John Ousterhout, gives their take on software design and what kind of mindset to take when designing your software. One of the major topics of this seminar is the idea of ‘Deep Classes’ which returns to the basic idea of abstraction. Ousterhout bring into focus the issues of ‘Shallow Classes’ which are small classes or methods that provide very little functionality. An example of this is shown below:

private void addNullValueForAttribute(String attribute){
data.put(attribute, null);
}

As Ousterhout states, this is a method that requires a full; understanding of the functionality and does very little to hide information (https://youtu.be/bmSAYlu0NcY?t=918). This method is essentially adding complexity with no benefit which is a net loss in the world of software. With this example in mind, Ousterhout states the biggest mistake people make in software design, “too many, too small, too shallow classes”. They attribute this to what many have been told throughout their career which is to keep methods small. This is problematic because it can actually increase complexity of a program as every class and method adds small amounts of functionality. 

This is especially true in things like the Java Class Library which has many small classes and methods with small functionality. To read a file Java requires you to create three separate classes to give the file input, buffering, and object input. In contrast Ousterhout brings up that UNIX has all of this wrapped into one object that being the UNIX file system which takes care of all other processes such as disk space management in the background.

So why does this matter in the end? The main point to get across is that abstraction is just so important in modern software development. UNIX abstracted its file systems which allows developers to spend little time worrying about file I/O implementation to allow for greater systems to be built. If something is used as often as File I/O, then it is worth it to create an all encompassing class/method for it. As long as classes are well organized there is no reason they cannot be large and have a lot of functionality.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Whenever you interact with a program it is usually done through an API. Every website you visit, most programs you use, even your own operating system uses APIs to communicate with application. APIs are very prominent in modern computing and are essential to establishing the connection between programs and users alike.

Seeing as every programmer will interact with an API at some point or another, it is important to understand their place and how to create a good API should you need to do so. It is important to realize that characteristics such as being easy to work with, complete, and concise must be met when creating an API. Doing so can result in many gains not just in the finished product, but in other aspects of coding projects. Keshav Vasudevan put it, good API design can lead to “improved developer experience, faster documentation, and higher adoption for your API.

As the author puts it, an API must be extremely simple to use while achieving its goals. To that end Vasudevan has outlined key aspects of API design that one should take into account when creating an API. Much of it comes down to proper organization and the use of consistency to avoid confusion while utilizing the API. Small changes such as keeping URLs short and simple along with setting up resource functionality with HTTP methods can make the process much easier. Methods such as GET, POST, PUT, PATCH, AND DELETE are commonly used in these APIs along with many other methods commonly used in HTTP.

Along with proper organization while building the API, it is just as important to ensure that it is not indecipherable by others. A problem that often occurs with developers and product owners is that the developers might the meaning of a feature and implement incorrect functionality. Developers should check that all GET commands needed are implemented and have an example where one can expect a specific output on a successful run. It is important to give and receive feedback for the developers due to the disconnect that can occur between the target audience of a program and the developers creating it.

An example of the GET response as follows:

responses:
200:
description: Successfully returned information about users
schema:
type: array
items:
type: object
properties:
username:
type: “string”
example: “kesh92”
created_time:
type: “dateTime”
example: “2010-01-12T05:23:19+0000”

Once all this is done, it is important to remember that complexity should be handled ‘elegantly’ as Vasudevan puts it. This entails that there are likely large amounts of different data and information that must be accessed. A lot of these are common and it makes no sense from an efficiency standpoint to create a resource for each piece of data, therefore it is important to keep the ability of resources broad. You should keep the retrieval process simple, down to a query and parameters when searching or using a resource. Overall the API must be as user friendly as possible to ensure that it works well with future users who don’t know the API like you.

Bibliography

Vasudevan, Keshav. “Best Practices in API Design.” SmartBear.com, https://swagger.io/blog/api-design/api-design-best-practices/.

https://swagger.io/blog/api-design/api-design-best-practices/

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

For the longest time Java has been an Object Oriented programming language first and foremost however it was never purely Object Oriented in its design. There exists some objects which are immutable and cannot be changed under any circumstances. String is an example of this and works by having a new object instance created whenever changes need to be made rather than altering the object itself. This is a hallmark of Functional Programming and part of the greater trend of java being pushed to be more akin to Functional Programming languages such as C.

This is something that Ian Darwin reviewed in his Java Magazine article going over the changes Java has seen over time. In this article he asks the question “Why is Java making so many things immutable?”. Put simply the answer is a matter of security and performance with immutable objects being more resilient to attacks and better for performance. Darwin provides examples with the String object which has been immutable since the very beginning. Along with this the Date and time API  has been moved to an immutable package since Java 8.

In the early days of Java there existed Java beans which Darwin describes in the article by the original spec which states: “A Java Bean is a reusable software component tat can be manipulated visually in a builder tool”. What does this mean? It means that Java Beans are more or less Java objects with a set of requirements to be classified as such. There include having set and get methods, expecting to be serialized and implementing the Serializable Java package, and it must provide support for design-time customization. The main takeaway is that these were always mutable and ever since then Java has moved away from this as its language has overtaken servers and enterprises alike.

Why has Java attempted to move to a Functional Programming paradigm? In today’s world many businesses and enterprises utilize Java on a large scale and in general and any way to gain more security or performance in a programming language will do a lot for a language as ubiquitous as Java. The creators understood the need for security with the String class as it has been immutable from the start. We can see below an example thread by Ian Darwin that could take advantage of and break Java’s entire security model if Strings could be modified.

Good Thread: Open File xyz.
InputStream Constructor; call security manager.
Security manager – Read file xyz – Permission is OK.
Bad Thread wakes up at just this moment.
Changes file name string from ‘xyz’ to ‘/etc/passwd’
Yields the CPU
Good Thread
InputStream Constructor: pass /etc/passwd to operating system open syscall
Bad Thread examines memory buffer for useful information to steal

Beyond the security benefits that these immutable objects pose there is also a matter of being able to increase performance of Java. Java is constantly being improved and as it’s performance increases it has become apparent that it is faster to create new objects than it is to modify the properties of old ones. Java lacks the ability to use pointers like C and because of this any extra baggage that can be removed to free up resources helps in a language like Java. If you compare Java at release and Java today, you can see that a myriad of new immutable APIs are scattered across the language as it has grown and evolved. This will likely continue so long as Java is a dominant language in the programming field.

Bibliography

Darwin, Ian. “Why Is Java Making so Many Things Immutable?” Blogs.oracle.com, https://blogs.oracle.com/javamagazine/post/java-immutable-objects-strings-date-time-records.

https://blogs.oracle.com/javamagazine/post/java-immutable-objects-strings-date-time-records

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

               When working with a Java program, one of the strongest tools to ensure it is functioning is Junit testing. Junit testing makes it easy to take a glance and see if all properties of your code are functioning correctly. Despite this however, at the end of the day, the product must be able to seamlessly accept and output data in a usable form. Therefore it is important to understand how to use temporary test files when using Junit.

              Andrew Binstock’s post fits in with regards to the currently assigned homework which sees us utilizing test classes and modifying them as the code is refactored. These tests allow us to ensure that the written code is working properly. To build upon this idea the post linked below presents the idea of Junit testing with temporary files to read and write to. Within this post is sample code which creates temporary files in and out of Junit testing.

Below we can see a snippet of code from the original blog post which shows temporary files being used in a Junit test. (Andrew Binstock)

import org.junit.jupiter.api.*;
import org.junit.jupiter.api.io.TempDir;

import java.io.*;
import java.nio.file.InvalidPathException;
import java.nio.file.Path;

import static org.junit.jupiter.api.Assertions.*;

public class TempFilesJUnit5Test {

Path path1, path2;
File file1, file2;

/* This directory and the files created in it will be deleted after
* tests are run, even in the event of failures or exceptions.
*/
@TempDir
Path tempDir;

/* executed before every test: create two temporary files */
@BeforeEach
public void setUp() {
try {
path1 = tempDir.resolve( “testfile1.txt” );
path2 = tempDir.resolve( “testfile2.txt” );
}
catch( InvalidPathException ipe ) {
System.err.println(
“error creating temporary test file in ” +
this.getClass().getSimpleName() );
}

file1 = path1.toFile();
file2 = path2.toFile();
}

               Within the second homework assignment we can see that Junit tests are used to ensure that the different classes of ducks and working properly and that the data output is correct. Some of the Junit tests scan the output file and compares it against the expected output. While this is useful to ensure the code works, it is also important to consider that not everyone will want their output confined to the terminal. This program could very easily be modified to output to a text file for data collection purposes. Testing this with Junit would allow the creator to ensure that data is being retained properly before running the program in a real case scenario.

Testing with temporary files was previously an underutilized method of testing due to older hardware being much slower and older drives using spinning magnetic disks rather than modern solid state storage. In the post we see the author discuss this dated policy and encourage the use of test files to create a more thorough testing method. Some might want their output in a text file or as an output to a front end for a website. Junit tests with temporary file allow you to test for this functionality as these temporary files can be created, read from, written to, and are all deleted at the end of testing to keep drive space free from clutter.

Bibliography:

Binstock, A. (n.d.). Working and unit testing with temporary files in Java. Blogs.oracle.com. Retrieved October 11, 2021, from https://blogs.oracle.com/javamagazine/post/working-and-unit-testing-with-temporary-files-in-java.

Working and unit testing with temporary files in Java (oracle.com)

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.