Category Archives: Coding

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.

Don’t Spend So Much Time Coding Cleanly!

There comes a point in every developer’s career where they transition from “make it work” to “oh my God I need to make this look decent”. Initially, our goal is to create a functional Hello World program. However, as we develop, we slowly begin to learn proper code styles and naming conventions. After reading enough Stack Overflow Forums, we start to become self aware of how our code looks and we begin to focus on code aesthetics. While there’s merit in that, we often focus on the wrong things.

This video does a great job of explaining just that: there isn’t really any such thing as clean code. Now, that isn’t to say that there aren’t wrong ways to code. I’m sure we can all name plenty. That being said, the main point is that we shouldn’t spend our time trying to code perfectly the first time.

The best way to code is to do so as well as we can without spending too much time overly focused on getting everything right the first time. If you know you have the opportunity to do something right or cut corners, do it right. However, if you’ve spent 10 minutes trying to name a variable, give it some placeholder name and worry about it later. The first priority is functionality. Later on, you can review and refactor your code.

The main goal of refactoring is readability. In a compiled language especially, there is only so much efficiency the programmer can add. Compilers do a remarkable job of optimizing code by themselves, so your main goal should be readability. Make sure that other developers, as well as your future self, can read and understand your code. Add comments where necessary, but aim for self-commenting code. If your code is its own comment, that helps save space.

In conclusion, focus on simple and readable code. Don’t waste your time doing something that can simply refactored later, within reason. With that being said, try to do things right the first time if it’s obvious how to do it right.

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.

Adapter Design Pattern

I’ve always found Derek Banas’ channel really useful. In late middle school, I started watching his tutorials for how to code. So it’s really interesting to go back and watch his videos, to say the least.

I feel like the adapter design pattern is something that shouldn’t really need to be used. Don’t get me wrong, it’s very useful. Like real adapters, however, the problem itself shouldn’t really exist. That’s especially true with code; it seems as though adapters become required when interfaces aren’t abstracted well enough. In his video, for example, he has an EnemyAttacker interface that represents some kind of enemy. However, the methods are very specific and presume certain characteristics about the attacker. We then need to use an adapter to get around that specificity. It seems to me that writing the interface more generally to begin with would be more ideal. But given that it’s a bad idea to modify old working code, an adapter is a great solution.

In principle, an adapter does exactly what you expect it to: it adapts code. It takes one “interface” and connects it to another “interface”. That’s the colloquial interface as opposed to a coding specific interface. We use adapters every day. The best example is a phone charger. It converts (or adapts) 120V AC power to a low DC voltage. It also adapts the physical plug into USB type-c. All of the functionality is hidden inside of the charger and from the perspective of a user, it’s literally plug and play.

An adapter in code acts the same. I honestly like the example he gave so if you want to see an example of actual code, check out his video. Conceptually, one description of an adapter is the following: We have two interfaces A and B that have many differences, but are conceptually similar. We can create an adapter so we can use any A as a B, or vice versa. It’s okay because of their similarity (or perhaps they need not even be similar!). Really, it’s an incredibly basic pattern so the specifics aren’t that important.

Fundamentally, an adapter is just code that allows other code to operate together. Again, I think the best way to conceptualize it is through the imagery of any real life adapters. However, it should ideally not be necessary in scenarios such as the one from the video. Abstraction, within reason of course, should be prioritized ahead of time.

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.

Introductory Post for CS-343

Welcome! First I would like to point out that all posts for this course should all be placed in roughly the same categories. However, they all will be tagged with CS-343. This should make them easy to find.

These posts will be centered around me searching for online materials other people have posted that relate to the core topics of CS-343. I will then be sharing them, interpreting them, etc. It will be a collection of information primarily useful to the following topics (as taken from the course syllabus):

  • Design Principles
    • Object Oriented Programming
    • SOLID
    • DRY
    • YAGNI
    • GRASP
    • “Encapsulate what varies.”
    • “Program to an interface, not an implementation.”
    • “Favor composition over inheritance.”
    • “Strive for loosely couples designs between objects that interact”
    • Principle of Least Knowledge
    • Inversion of Control
  • Design Patterns
    • Creational
    • Structural
    • Behavioral
    • Concurrency
  • Refactoring
  • Smells
    • Code Smells
    • Design Smells
  • Software Architectures
    • Architectural Patterns
    • Architectural Styles
  • REST API Design
  • Software Frameworks
  • Documentation
  • Modeling
    • Unified Modeling Language
    • C4 Model
  • Anti-Patterns
  • Implementation of Web Systems
    • Front End
    • Back End
    • Data Persistence Layer

Hopefully, these posts provide you with many resources to help you learn these topics for the first time or to help you recall them after a long time has passed! I wish you the best of luck in whatever you’re hoping to achieve!

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.

WSU x AMPATH || Sprint Retrospective 6

Sams ShipsHey guys, it’s a weird feeling to be wrapping up my last semester in my undergraduate career in computer science (and sociology). For this final installment of my AMPATH sprint series, I will just go over the general overview of what went on for my team.

Most of our updates went onto our PowerPoint presentation, which is going to be presented on May 15th, 2019. My team and I are looking forward to presenting the overall process of our group’s learning and working process, the many lessons we learned, our advice for future students, the work we tried to implement, and various other technical aspects of our project.

We decided that on top of the search bar work, it is also a priority to organize the git repository so it can be better organized and an open work environment for other classes. I think this is important especially when new people come in and cannot efficiently locate and access the files they need. As someone who was once new to an organization that had a lot of different projects and files to sort through, I believe that this is very considerate of the team to go with this.

With some limitations my team had to face, we worked around it to determine how we should move forward. The end result is pretty much a search bar that is attached to the toolbar. It cannot currently be live tested due to there being no backend but it can definitely be done in the future under certain circumstances.

It was interesting being able to observe how much planning you can start with but still end up having to take detours, starting new paths completely, or sometimes even needing to take U-turns.

I thought it would be important to pull some of the advice for future students from our PowerPoint and include them in this wrap-up:

  • Point out and address problems with technology right away because others around you might have the same problem(s) so you can solve them collectively
  • Do all team implementations in a separate component based on what you will be working on
  • Merge your work constantly to the master branch so each team can have the updated changes

A pattern I am noticing in a lot of teams or group projects is that not everything is going to work out in ways that you expected or were hoping for but you learn to move as a shifting team to make progress and continue growth.

Overall, I’d say I learned an important life lesson from this: if I am to contribute extra time on top of my technology career in the future to work on side projects, it will be a challenge to allocate time if it is a group initiative. I also learned that even when we try to communicate everything there is still more room for miscommunication, so there may be no such thing as over-communicating. I am happy to say that we always tried our best to move forward in all ways!

 

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

Find Mentors || S.S. 10

Sams Ships (13)In this final installment of my individual apprenticeship patterns, I think an important one to write about would be Find Mentors. To summarize the main point of this one, I would say that it encourages people to observe their role and their surroundings to see where they can find the most value from learning or use their resources. It encourages you to look at things from one level back instead of blindly jumping into something right away.

Personally, I have been in a role where I had to figure out a lot of things that could have just been taught to me. I quickly learned that I would be able to ask other junior developers how they managed to learn things on their own and it helped me a lot. If other junior developers were not available, then I would work my way up to people who had the most recent on-boarding experience and hope that they could recall the process I was currently going through. For the most part, that worked out well!

Thanks to this pattern, I thought it was useful to think about and remind ourselves that even though our mentors will know a lot more about us, they still do not know everything. They are still continuing to learn as much as we are in their own careers.

I thought I should update this blog to throw in a little hidden announcement if anyone actually reads these that I will be learning at a company with about 100 peers going through the same thing. This makes me feel a lot more confident knowing that I will have a designated support system around me and have mentors around.

Overall, I agreed with the pattern. This is because I can testify with my personal experiences how useful it was to be able to utilize my resources including being able to ask mentors questions or just find my own. A common question I had for my interviewers was, “Will I have a mentor or support system along the way throughout my career progression?” Personally, it is important for me to have a designated place to go for support because it just takes one more worry away about having to ask somebody a question.

It is now time to conclude my individual apprenticeship pattern series! I hope you have at least learned one thing from it because I have learned so many things.

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

Draw Your Own Map || S.S. 9

csseries281829For my second-to-last individual apprenticeship pattern, I have decided to go with something a little more relevant to my current situation–relating to starting my career post-graduation.

The Draw Your Own Map pattern caught my attention right away with “we might come across situations or colleagues or people in the society who will try to prove that programming will become an unsustainable activity as time passes by.” Throughout my job search process, I asked questions and requested advice from all different kinds of people across different fields (and especially within computer science) on how they knew what job they wanted to start with when given opportunities.

In the end, I must choose what I think is best for me in terms of what I’m looking for. I’ve finally came up with a list and that includes:

  • Having solid mentorship
  • Proper training (no room for imposter syndrome)
  • A company that tries to stay on top of new technology
  • Work-life balance that allows me to continue doing all the things I love to do outside of work and travel often

The Draw Your Own map pattern is very encouraging, reminding us that we have options elsewhere if we feel that our current company is hindering our learning and personal growth. I found that this pattern was interesting because I part of my decision-making process was “what if I am ____ amount of time into my first career and realize that I do not like what I am doing?” How would I move on out of that role to figure out what I may like better in terms of my day-to-day tasks?

The activity to list three jobs that I could do following my next was was really helpful to visualize future career possibilities. I know that we can always learn on the job and at new jobs but it is also important to build up your skills that can be transferred in the first place.

The pattern has helped me feel more confident in the decision I made to start out in software engineering. I will build up my skills starting here and then more onward from there!

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

Craft Over Art || S.S. 8

Sams Ships (10)As we have a few weeks left in the semester, I wanted to discuss the more creative apprenticeship patterns. This time I’m going to describe Craft Over Art, which is basically when a solution to a client’s problem can be solved with something that could work…or we could take it and go above and beyond. It’s being more innovative than just settling for a solution just to have something.

I found that the pattern is interesting because it emphasized the importance of how the things built for customers can still be beautiful but must always be useful. If it strays away from being useful, then it no longer counts as the craft.

I also found it to be thought-provoking because it brought up how people are truly in charge of how a problem gets solved. No one can force you to code something a certain way if they do not know a way to solve it on their own, which is why your role exists in the first place.

The pattern has caused me to change the way I think about my intended profession because your work can still reflect you in terms of creativity. As a person, I think I am more on the creative side and incorporating more ideas into creating something for people sounds pretty cool. If I had to follow a super rigorous structure, I may feel limited in what I can do to produce work that makes me happier.

The one thing I have to disagree with in the pattern is the part where it mentions that someone is suddenly no longer “part of the craft” if they deviate a little further. Who sets these boundaries? I do not want people to feel like they are not “enough” to be considered a real craftsman or whichever term it is referred it as just because they were being extra.

Overall, I appreciated the action section which encouraged people to reflect on what projects they worked on or situations they may have found themselves in where they chose creativity over usefulness. At the moments where I have personally done so, I had felt more proud of my work, because I knew it was uniquely mine.

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

Sustainable Motivations || S.S. 7

Sams Ships (9)From recent conversations with friends and professionals I’ve had genuine one-on-one discussions with, a common concern people have is whether they will continue to actually enjoy what they do. Today I’m going to discuss the Sustainable Motivations apprenticeship pattern. This pattern pretty much goes over scenarios people may run into throughout their careers in technology. There will be great days where people may be amazed that they are getting paid to create things and there will be rough days where people may be doubting if it is the right profession for them at all.

The points brought up remind me of a recent article from the New York Times titled Wealthy, Successful, and Miserable. What happens when the new-ness of what started as an exciting role to join in a company wears off and you are left off with unsettled feelings? It is up to individuals to keep going until they find what they love again or shift what they are doing a little to stimulate something new.

I like how the pattern encourages people to come up with a list of things that motivate them. It then tells them to reflect on what those things means or if there is a noticeable pattern from the things they have chosen. Having a list like this around to remind people of what they are working for is a reassuring way to keep them going. It reminds me of a post on LinkedIn I saw where someone kept a sticky note on their monitor screen that just had a number like “-$237.25” because it was to remind them of how much they had in their bank account when they started their job.

The pattern has caused me to think about the way I intend to work as someone who constantly likes to change things up or is not afraid of change. I do not disagree with anything in the patterns as it tells us to keep pushing and persevering by thinking about The Long Road, which is another apprenticeship pattern.

Overall, I think people interested in this pattern should read the NYT article I linked as well because it gives insight on the difference it makes when people do something that makes their work feel more meaningful.

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

WSU x AMPATH || Sprint 2 Retrospective

Sams Ships (8).pngFor my second sprint retrospective, there is something I would like to reflect on in terms of a change to my first sprint conclusion. It turns out my build environment was not completely set up properly so I had spent some time with assistance from my teammates on configuring that. I would like to note that I have a MacBook so that made things a little different to work our way around figuring out what to change or test out. A very helpful link was from a question someone asked on Stack Overflow. Through the process of not being able to install angular-cli on my mac, it led me to installing nvm, where there was another series of instructions to follow through Github.

It is very relieving whenever we get stuck on something and are able to find similar scenarios from people around the world who have run into the same roadblock and they share advice on how to work around it. Thanks to their input, I was able to resolve my terminal errors and/or warnings that resulted from trying to build something. It also helped me try and see if I could assist any of my other teammates who were running into errors as well even on Windows. I would definitely continue using the internet as a resource when I get stuck on mac-specific issues. The same thing happens when an installation that is only available in .exe files is required, I must find a mac-appropriate version.

However, if I were to proceed any differently; I would have double-or-triple-checked what is necessary to move forward. If someone else were to follow these steps; I would highly recommend checking out the links I provided above when I was unable to install angular-cli on my mac.

So far, we have been hit with some New England weather™ which shows how we were able to keep moving and working despite a roadblock that we could not control. It is very relieving to know we are now all on the same page and are working on moving forward together to contribute to the AMPATH system from now until the end of the semester. Who knew something could be more relieving than finally seeing the login screen after the ng command and going to the localhost url.

A big update is we got some more information on the AMPATH x WSU collab right around the end of this sprint so I am looking forward to exploring that with my team. It will allow us to analyze what has been given to us and decide where to move forward with the project.

Overall this past sprint included a lot more learning and collaborating with my team. I’m excited to begin watching the walk-through videos that Greg uploaded of the wire-frames. They look like they are broken down well and all of them are combined into a playlist so I would say we are going to be learning a lot more. Stay tuned for the Sprint 3 retrospective!

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