Category Archives: Week 9

Sustainable Motivations – Apprenticeship Pattern

What this apprenticeship dives deep into is that along your journey of becoming a software craftsman, there will be many times you face trials and tribulations. There will be instances where you are burdened with working on a complex project and forced to solve problems you have no idea where to even start. I am sure most of us on our journeys have faced this pressure and this feeling of whether this is all worth doing or whether we are cut out for it. However, this pattern says that we need to have clear and strong motivations when these trials come to our front door. Many people have different motivations as well as altering goals and ambitions. We are all developing software and programming for various reasons as clearly defining these things help us moving forward. We wouldn’t have made it this far if it wasn’t for some motivation that kept us going.

I think this chapter is very relevant for all of us who are trying to become software engineers and architects, and to understand that this journey isn’t just some smooth sailing. There will be times where everything feels easy and you feel lucky to even be in these circumstances. However, there will be other times that bring either the best or worst out of us when we face hard problems related to programming which can mess with us mentally. As a result of this pressure, we need to keep our road and ambition clear on where we want to be heading. Our journey is unique but to keep the journey going we need some strong interior purpose and motivation to pick up our head and keep moving forward on those days when we feel like there is no purpose for doing this. It is at these times, our mind is fogged up with the current problem and not on the bigger picture as to why we are doing all this in the first place. To clear up that fog we need sustainable motivations to be our anchor and help us get through and keep the boat moving. Overall, software architects will need to develop the mindset of believing in themselves and know they are doing what is right for them if they have a clear vision.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Building A Reading List

Photo by Skylar Kang on Pexels.com

There is more information available today than ever before, largely thanks to the advent of the internet and the ease with which that information can now be accessed as a result. Because of this increase in available information, the choices can often seem daunting when attempting to choose any source in particular. Especially when searching out books to look into regarding a specific topic, the sheer variety and number of options on even very niche topics makes it hard to make a decision on any one of them to study from.

Concerning the problem I just described, the pattern discussed in section 6 of of Apprenticeship Patterns, Reading List, outlines a useful technique for organizing the seemingly endless collection of books and reading which accumulates when studying a topic. The general idea is to keep a literal reading list, with all of the books (or other sources) you plan to read, reference, or look into recorded for the future. While the text seems to approach this from the context of physical books, I see no reason why this wouldn’t apply to any sort of reference, manual, or other self-educational materials in practice.

Additionally, the authors of Apprenticeship Patterns recommend maintaining the list as a priority queue, in that more important books or references will be studied first, before continuing down the list in order of importance. This seems like a good idea as it makes it easier to prioritize learning things in a more efficient order; subjects or topics which are less important would naturally proceed to rank lower and lower on the list and might eventually be removed if they stay towards the bottom for too long.

This process of removing dead-ends and passed topics of interest would keep the reading list relevant in the long term and help to maintain cohesion (it seems likely that irrelevant topics or sources would naturally begin to rank lower on the list, organically moving them out of the list over time).

Very probably in the near future, I will begin my own reading list, keeping track of prospective sources of information and reference which I feel will be interesting or useful to study. Considering the relative ease of implementing this pattern (keep a list), I would say that it is an easy way to optimize learning or research regarding any topic, but in the context of software development it seems even more relevant still. As there are oftentimes many disparate syntax manuals, tutorials, and textbooks to learn from which could benefit from the concrete organization afforded by a reading list.

Text Referenced: Apprenticeship Patterns, Guidance for the Aspiring Software Craftsman (https://learning.oreilly.com/library/view/Apprenticeship+Patterns/9780596806842/ch06.html#reading_list)

From the blog CS@Worcester – CodeRoad by toomeymatt1515 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog Post #7

For my second to last apprenticeship pattern blog post review, I would like to talk about simply because of how close it hits to home with me is the pattern entitled “Draw Your Own Map” in the textbook readings. This pattern is based on the fact that throughout the lives of software developers, there will be many times in which jobs or opportunities will not quite fit what they are capable of or are even interested in doing. The main issue brought up in this chapter was that none of the career paths provided to young software developers are often fitting for them. The reason that I chose to review this specific pattern is because I believe it relates to me very deeply as I am worried that whatever direction I end up taking after college may not be right for me. I already have many different options and directions that I could take from here and the opportunities are almost more daunting than exciting at this point. I am worried I will make the wrong choice early on. The book tried to solve this problem by basically saying that I choose my own destiny. “Identify a logical but ambitious next step for your career. Understand that it’s not up to your employer, your career counselor, or your professors to give you a hand up.” Sometimes the guidance of others is not what is needed even if it is with good intentions, because more often than not, I should know what I like best. The book also explains that no matter what direction I want to choose, it is important for me to make sure to take the first step. Without the first step, the dominos will not start falling and there will be no momentum toward my goals. If others (such as employers) try choosing a path that is not right for me, I must reflect and make the decision to stay on the course that I personally see best fitting for me. Obviously, when working, I should complete my roles and not give up, but in the end, it is not wrong for me to change direction and even switch career opportunities for my own betterment if I feel I need to.

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Find Mentors

            The “Find Mentors” learning pattern from the Apprenticeship Patterns book is one that I definitely should have focused on earlier. This pattern is focused on find more experienced developers around you early and leveraging their knowledge and practice to take steps forward in your apprenticeship. Keeping with the master craftsman and apprentice theme, no apprentice will learn as effectively without someone to help them along their way and point out the unknown unknowns. The pattern recommends reaching out early and often. The only downside is rejection, which is easy to get over, especially if it is followed by acceptance at some point.

            In my computer science journey, I need to take this message to heart. Oftentimes, I try to do most of my learning on my own. I know I can have a kind of unorthodox way of teaching myself things, so I usually try to stick to myself when learning. I do quite often leverage the help/advice of peers though. Most of the people I’ve become closer with in the WSU computer science program I have worked closely with and either have some knowledge to gain from them or have some to share. While I realize working with peers is great, I definitely have fallen short on the front of getting help from those who are leagues ahead of me, like my professors. Looking back, I definitely should have attended more office hours and been in closer contact with my professors and advisors. That’s a goal I have for grad school, especially since I hope to be working as a research assistant, so this would be perfect.

            As the pattern mentions, it is difficult to get over the awkwardness of asking someone to mentor you. I’m not really sure how or who to reach out to in a professional setting, and I’m also not sure of what I would be looking for from a mentor. Although mentoring in school is great, it would probably be quite different than mentoring in a workplace. This is something I should look further into. Who can I reach out to as a mentor and what should I be looking to gain from them? If I can get the answers to questions like these, I think I would feel more comfortable filling the apprentice role.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Reflect As You Work

The “Reflect As You Work” pattern in Apprenticeship Patterns has much to do with developing a methodical and concrete approach to introspection within one’s software development career on both a macro and micro level. On the micro level, Hoover and Oshineye make the recommendation to consider your day-to-day practices when programming and to take notes on the practices of more senior team members to see what makes them so effective. On a macro level they describe what amounts to a hotwash or after-action review of the operation (to borrow government idioms) but caveat that a certain level of trust by management is necessary for the approach detailed and that may not always be the case.

One of the exercises in this Apprenticeship Pattern I finally found to have immediate utility in my life is accounting for the things that I do or do not do adequately in regards to programming. The exercise as described by the authors:

“If there is something particularly painful or pleasant about your current work, ask yourself how it got that way, and if things are negative, how can they be improved? The goal is to extract the maximum amount of educational value from every experience by taking it apart and putting it back together in new and interesting ways.”

Like many of the Apprenticeship Patterns and the exercises contained within them, much of the immediate implementation is lost due to the apprenticeship patterns pre-supposing that the reader is currently writing a meaningful amount of code to have established a personal pattern. Despite that fact, I’m able to use this exercise to dissect my personal habits prior to entering college which were things such as poor commenting, not adopting to the bracketing style of the language, not using tests, not using git, and CI/CD. What was pleasant about my past work was my consistent use of the Microsoft Visual Studio IDE to debug and step through my programs. Unfortunately, I’ve been able to write substantially less code since I made the choice to return to college but look forward to using the exercises that I learned about in this apprenticeship pattern to maximize the value in learning from my mistakes.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

What is a REST API?

This week we began to discuss REST APIs. While it was explained in class, the concept kind of went over my head so I wanted to look more into what they are. While looking around I found a helpful article from sitepoint.com

The author explains it with an analogy. A REST API is a way for two systems to communicate over HTTP. This is like when you get car insurance. The insurance agency must get data from the government, credit agencies, banks and other systems.

He goes on to give an example of a REST API that just shows a bad joke.

He also talks about the other data communication standards like CORPA and SOAP. They are much stricter than REST which is not a standard but a set of constraints that must be satisfied for an API to be RESTful.

The next section discussed was something we covered in class, requests and responses. He also includes an example for the reader to try at home.

REST APIs also have some challenges associated with them. One is that there are multiple endpoints that can be used to fetch the same data like:

  • /user/123
  • /user/id/123
  • /user/?id=123

This can make is hard to be consistent on a large project with many developers.

It is also important to keep your application secure and a REST API provides another level that needs to be secured.

The author ends with additional articles and links to learn more about REST APIs.

A lot of what this article covered was also covered in class, specifically the part about requests and responses. I feel like what we discussed in class was clearer and more made more sense. This is probably because we were talking about it and could ask questions if necessary.

What was useful from this article was the REST API example. I did try the example myself and it worked with no issues, though this is to be expected as it was just copying and pasting the code. I would have liked if there were more explanation, but this was a simple example so not much more could be said.

The author here assumes that the reader is familiar with JavaScript. I am new to JavaScript, but this example was simple enough that I could understand what was going on. I don’t anticipate us doing an example this simple in class, but it was helpful, nonetheless.

https://www.sitepoint.com/developers-rest-api/

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

JavaScript/Node.js

This week on my CS Journey, I want to look more into JavaScript and how it is used in docker. Although we did a few activities on JavaScript, I was still confused so I decided to read and research more into it. JavaScript is a text-based programming language used both on the client-side and server-side which is mainly for the web. Many of the websites use JavaScript on all browsers making JavaScript the most-deployed programming language in history. The name JavaScript is quote misleading due to the resemblance of java programming language however, JavaScript is completely different from the Java programming language. Both Java and JavaScript are written, assembled and executed differently, and each has dramatic differences when it comes to what it can do. JavaScript is mainly used for: Adding interactive behavior to web pages like Change the color of a button when the mouse hovers over it, displaying animations, creating web and mobile apps, Game development, and  building web servers.

Now let’s get into Node.js which is what is used in docker. Over the decade Node.js has enabled JavaScript programming outside of web browsers, which has a dramatic success of Node means that JavaScript is now also the most-used programming language among software developers. Node.js is an open-source, cross-platform runtime environment for developing server-side and networking applications. Node.js applications are written in JavaScript and can be run within the Node.js runtime or any other operating systems. some of the features I learned from the blog is that, Node.js  can be  Asynchronous and Event-Driven meaning that All APIs of the Node.js library are asynchronous, it essentially means a Node.js based server never waits for an API to return data. It can be very fast since it is being built on the Google Chrome’s V8 JavaScript Engine, Node.js library is very fast in code execution, and lastly, No Buffering- Node.js applications never buffer any data. These applications simply output the data in chunks. 

The diagram below also helped to understand the concept well.

I highly recommend that everyone read the assigned book on JavaScript because it is very helpful in terms of understanding the concepts and the book covers a wide variety of interesting topics. Also, I suggest that everyone follow this tutorial it is an example that shows how to get a Node.js application into a Docker container. The guide also helps to understand basics of how a Node.js application is structured.

Here is the tutorial: https://www.digitalocean.com/community/tutorials/how-to-build-a-node-js-application-with-docker-quickstart

Sources : https://learning.oreilly.com/library/view/javascript-the-definitive/9781491952016/ch16.html

https://www.tutorialspoint.com/nodejs/nodejs_introduction.htm

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

RESTful API Basics

            As we start our learning for our final project in our class, we have started to learn about and work with RESTful API architecture style (REST API), so I have started some research and done further learning myself. I found a great article from by Margaret Rouse with an wide view of the application program interface, called RESTful API. She breaks down what it is, how it works, its uses, its constraints, challenges, and some background information. REST uses the HTTP requests of GET, PUT, POST, and DELETE for data use and access. This API is based on representational state transfer, which is what the acronym stands for. It works by, “[Breaking] down a transaction to create a series of small modules. Each module addresses an underlying part of the transaction.” Commands are used to obtain resources, and resource’s states is called a resource representation. As previously mentioned, the commands are: GET to retrieve a resource, PUT to modify/updated a resource, POST to create a resource, and DELETE to remove a resource. The idea is for users to access networked components with stateless calls, no information being retained by the REST services. This statelessness makes REST “useful in cloud applications.” They are scalable and can be “redeployed if something fails.” It is very useful for efficient internet usage and is very compatible for distributed environments, and is used by the likes of Amazon, Google, LinkedIn, and Twitter. With cloud and microservices growing in popularity and usage, REST is sure to grow alongside. REST adheres strictly to 6 key concepts. There must be a uniform interface under a single URL. It must be client-server based, dividing request-gathering concerns on the client and data access, workload management, and security on the server. There must be stateless operations, as mentioned previously. Any state information must be managed on the client. Caching is essential for resources unless “explicitly indicated that caching is not possible. It must be a layered system, like a hierarchy to the architecture. There must be code on demand, meaning that “a server will send back static representations of resources,” or “when necessary, servers can send executable code to the client.” Sticking to these requirements can be difficult, which presents the challenges of endpoint consistency, response time and data size, defining paths and locations, security, authentication, request scope, testing, and error handling. Since REST is useful for the aforementioned reasons, this is worthwhile and understandable though. I expect to use this information in my final project, which should be dealing in a REST API, so this will be very useful to me in the near future. It is very interesting and exciting, and is growing to the top of the computer science world.

Source: https://searchapparchitecture.techtarget.com/definition/RESTful-API

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

A Strange Way to Use Get Requests

Strap in because this post is going to get very anecdotal.

Backstory

I have a history of running Minecraft servers for my friends and I. A few years ago, I learned how to port-forward a locally hosted server and use it to play on. While it’s not the most secure thing in the world technically, it works really well and it’s produced a lot of fun. For whatever reason, I was thinking about it again recently.

When I’m out of school, that’s usually when we play. I’ve slowly been learning more and more. I’m currently at the point where I can make intermediate datapacks for the game and use shell/bash/batch scripts to run the server. Over the summer for instance I created a shell script to run the server, back it up, and reload it if it crashes.

There’s still one major problem with my servers, however. I need to manually turn on one of my computers and run it. Then that computer has to stay on until I want the server off. It might waste power if no one is using it (also increasing the risk of the world becoming corrupted) and it’s just slowly going to wear out my hardware.

Recently, I remembered that I had two old laptops. Unfortunately, the newer one didn’t have a power cord. So I broke my way in and took out the ram, hard drive, and wifi card. Then I swapped those components into the other laptop. Lastly, I installed Lubuntu onto it. It works surprisingly well. I then set up NoMachine so I can remote into the machine without having it in front of me. The BIOS supports wake on LAN so I took a few hours to get that working. Now, I can leave that laptop plugged in next to my router and send a signal over the internet to wake it up. While the router blocks the magic packet required on ports 7 and 9, a simple port forward allows wake on LAN to work from anywhere. I would definitely not recommend that for most scenarios, but until I find myself the victim of attacks on my router, I think I’ll take my chances.

Now, my goal has been to create programs that run all the time that laptop is running to be able to receive requests to launch Minecraft servers. I’ll work out a script later for handling crashes and such, as well as a datapack for automatically stopping the server when no one has been online in 30 minutes or so. So I started work on a node server.

Node.js

While I am learning about node in my CS-343 course, I have already taken the Web Developer Bootcamp by Colt Steele on Udemy and I highly recommend it. This is the basis of my server so far:

const express = require("express");
const app = express();

const server = 
app.listen(process.env.PORT, process.env.IP, function() {
     console.log("The server has started.");
});

var minecraft_server1_on = false;

app.get("/minecraft/server1/start", function(req, res) {
     res.send("Turning on the server…\n");
     minecraft_server1_on = true;
});

app.get("/minecraft/server1/ping", function(req, res) {
     res.send(minecraft_server1_on);
});

app.get("/minecraft/server1/declare_off", function(req, res) {
     res.send("The server is off.\n");
     minecraft_server1_on = false;
});

app.get("/exit", function(req, res) {
     res.send("Exiting…\n");
     server.close();
});

app.get("*", function(req, res) {
     res.send("The server is running.\n");
});

Now, I’m certain that I’m making mistakes and doing things in a strange way. It definitely is not in a state I would use for anything other than a private server, and even then I’m still working on it.

Here’s the important parts. It’s an express app with a few get routes. I’m running this server from a bash script using nohup so that it can simply run in the background while the pc runs. However, I want to be able to stop the server from another bash script without using process ID’s so I don’t risk closing the wrong thing. While I was considering my options, I thought of something really interesting. I can use the curl command to perform a basic get request in a bash script. So I created a route /exit that when requested, it shuts down the server.

It’s incredibly simple and there are definitely ways around it, but I never even thought of using get requests in this way. There is information in the requesting of a web page, excluding the normal stuff. Just the fact that a request occurred can be useful. What this means is I can check if the server is running by pinging most routes. I can also both send and receive boolean data without any real complexity. Once again, I’m sure this violates some design principle. However, for something like this that is meant to be mostly casual and private, why should I need to set up proper post routes and databases when I can use this.

My method of turning on a Minecraft server now; I store the state in a variable in the node server. This is fine because when this server stops, all other servers should have stopped so I don’t need a database. Then, by pinging certain routes, I can turn a Minecraft server on, check if it’s on, and declare that I have turned it off somewhere else. The node server can maintain the state of Minecraft servers (I can possibly run multiple on different ports) as well as handle inside and outside tracking.

Keep in mind again, I’m looking for the easiest way I know how to make this work right now, not the best way to do it. So from here, I had no idea how to make the node server actually start a Minecraft server. I know how to run one from a bash command though. So I created a C++ program that will also run all the time. It can periodically check the status of the node server. For instance, if I send a request to the node server to turn on a Minecraft server, the C++ program can detect that change by running system("curl http://localhost:PORT/minecraft/server1/ping"); Once again, I’m using a UNIX command in C++ rather than using a wrapper library for curl because it was an easier solution for me. The node server can then return true or false. In fact, the C++ server won’t directly run the command. It will run a bash script that runs the command and stores output into a file. C++ can then read the file and get the result.

I’m currently still in the process of making this work. After this, I’ll make another node server hosted on Heroku that has a nice front end to allow myself and other people to request the laptop to wake on LAN, and then directly interact with those local node server. I may even make a Discord bot to allow people to simply message in chat to request the server to turn on.

Conclusion

Once again, I do not recommend anyone actually does this the way I have. However, the whole point of coding is to make a computer do what you want it to. If you can hide the get requests behind authorization (which I will probably do) as well as fix any other issues, this could be useful. It’s not even specifically about using get requests in this way. Abstract out and realize that it’s possible to do something in a way you never thought of, and it’s possible to use something in a way you never have. Consider what you know and explore what’s possible. Figure out whether or not it’s a good practice based on what problems you run into. I think that’s one of the best ways to learn and if you can find a functional example to fixate on, the way I have, you can find yourself learning new things incredibly quickly.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Models

https://www.lucidchart.com/blog/types-of-UML-diagrams

https://c4model.com/

For this week we’ll be covering modeling which is an important aspect in not only software design, but also design in general. Modeling is a very simple concept; it is when one creates a visual representation of a project, program, or whatever someone is working on. It is a visual tool used to streamline and simplify the process of development. In software design, there are two specific types of models which are called UML and C4 diagrams. UML, which stands for Unified Modeling Language, is used to give a visual representation to the architecture, design, and implementation of a software system. For example, a software system by a group of interconnected boxes which symbolize each class in that system. A class is represented in UML as a box which is separated into three sections which hold the name of the class, its attributes, and its operations. C4 meanwhile is used to give a visual representation to the architecture at different levels of detail. For example, a software system is represented by an interconnected group of boxes symbolizing each element of that system. As one zooms closer, each element breaks down into smaller parts that make up of that component. This process spans four levels from the system context level, to the container level, to the component, to the code or UML level. The key difference between C4 and UML diagrams is that C4 uses the general framework of UML to visualize a software system at greater scales.

The general importance of these models is that before creating software, you have to form a plan. If one were to skip this step, they would likely run into multiple problems like forgetting to implement a part of the software, making a mistake that isn’t noticed until much later, or having no clear direction in development. Often times when these mistakes are made, developers would have to devote time to correct them when they could have created a model allowing them to develop more of the software in a shorter amount of time. Models can also be useful with how they can make peer review easier. If a developer wants a peer’s feedback on the general structure of their work, they can give them an easy to understand model rather than the code for the classes that make up an entire software system. Models are a very simple but also very important aspect to software development which is also the main reason why I chose to write about this topic.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.