Category Archives: #CS

Facade Design Pattern

This week on my CS Journey, I want to talk about the design patterns, Especially the Facade design pattern. In class, we also learned about other designs which are helpful. However, I wanted to focus on the Facade design pattern. To start of Facade is a structural design pattern that adds an interface to an existing system to hide its complexities. In other words, it provides a simple interface that can be used to manipulate more complex logic behind the scenes, that are hidden from the main user. According to the Gang of Four, the Facade pattern intends to “Provide a unified interface to a set of interfaces in a subsystem” From the blog I used it provided a diagram that I think is helpful to understand the design pattern. In the diagram, we can see that Facade is acting as an interface for the complex Subsystems that are hidden from the main clients. 



Now let’s take a look at a real-life example. A good example that I found was When a computer starts up, it involves the work of CPU, memory, hard drive, and other subsystems. To make it easy to use for users we can add a Facade that wraps the complexity of the task and provide one simple interface instead. This applies to the Facade design pattern because it hides the complexities of the system and provides an easy interface to the users. 

 

One of the liabilities is that a Facade might provide limited functionality in comparison to working with the subsystem directly. Does not prevent applications from using subsystems classes if they need to. Also, it can increase the number of wrapper classes. Another liability is that Facade can perform way too many tasks. One of the benefits is that it reduces compilation dependencies is vital in large software systems. Overall, The Facade design pattern is helpful when dealing with the complex system because It enables us to use the complex system much more easily.

 

There are a lot of examples, diagrams, and Java Codes, readings and a link to a GitHub resource that are provided in the blog I used. I would suggest you to take a look at the website because it goes into further detail about the facade design pattern, including various examples using diagrams and also this reference contains a lot of information that is broken down into easy steps which are user friendly.

 

Source : https://www.baeldung.com/java-facade-pattern

















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

S.O.L.I.D Principles

 This week on my CS Journey, I want to talk about the SOLID design principles. I am sure that you have heard the term many times, however, let us look at the principles in detail. The reason I picked this topic is as a Computer science major student we write many programs and having a strong principle will enable us to write effective object-oriented code. 

To start of SOLID is an acronym where each letter represents a software design principle. 

S – for Single Responsibility Principle

O – for Open/Closed Principle

L – for Liskov Substitution Principle

I – for Interface Segregation Principle

D – for Dependency Inversion Principle

 

Each principle overlaps here and there. The Single Responsibility Principle states that in a well-designed application, each class should have only one single responsibility. essentially meaning a class should only have one job. I think this is a very good concept to use because when you are working with complex programs and the class has more than one responsibility it will become a nightmare. The open-closed principle states that classes should be open for extension but closed for modification. For example, I learned that if you want to add a new feature to your program you should do it by extending it rather than modifying it which minimizes the risk of failures. Next, the Liskov Substitution Principle which explains that an object of a superclass can be replaced with objects of its subclasses without causing problems to the application. This means that a child class should never change the characteristics of its parent class.

 

The  Interface Segregation Principle is the fourth SOLID design principle that states no clients should not be forced to depend on methods they don’t use.  In other words, interfaces shouldn’t include too many functionalities since the interfaces are difficult to maintain and change over time, so it is best to avoid. Lastly, the Dependency Inversion Principle states that the High-level modules or classes should not depend on low-level modules/classes and both should depend upon abstractions because a change in one class can break another class which is very risky.

 

Overall, the blog I read talked about each principle in detail using various examples such as UML diagrams, Java programs, and other diagrams that helped me to understand each concept. I learned a lot from the blog, and I think that these concepts are all key to writing a good solid code. In the future, I will be using the principles to write effective object-oriented code. 

 

 

Here is the blog I Used:

https://raygun.com/blog/solid-design-principles/

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

CS 343 First Post

Welcome to Haoru’s Blog

Hello Everyone! This is my first post for 343.

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

CS 343 First Post

 Hello Everyone! This is my first post for 343. I’m excited and looking forward to this semester. Lets stay Focused!

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

CS-343 First Post

Hello again! This is my first post for 343. Equally excited for this class as the other. Excelsior!

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

The Liberated Pixel Cup! – Dev Blog 2

It’s been a slow start, but hopefully things will start to move a bit faster. I am on vacation for the week and I have managed to get some work done.

I spent several days trying to figure out the best way to represent Actors on the world maps where the player can walk around. The Actors walk one tile at a time, fitting to the grid, rather than having “free” movement where Actors can move by any increment. It is much easier to implement free movement (which is what I’ve done in the past) than tile movement. I re-wrote the code that handles all of this several times before I found an implementation that was clean and functional enough.

In this screenshot there are several randomly spawned Actors that have walked to random places on the map. They do this by using the A* pathfinding algorithm I talked about in the previous post. There is an Action class that actually performs the walking animation. This Action is smart enough to re-route upon collision with another Actor.

The player can touch/click on a map tile to walk a path to it. For desktop users or certain Android devices, the D-pad can also be used to move the player around on a tile-by-tile basis.

I have also started work on an interaction and dialog system. In the screenshot, the text box shown is a result of the player interacting with the sign on the building. Right now the text box only displays one string of text, multiple strings and maybe even branching dialog paths still need to be done. Item chests are on the to-do list as well. Hopefully I can get them done soon.

From the blog David Thompson » WSU CS by davexunit and used with permission of the author. All other rights reserved by the author.

The Liberated Pixel Cup! – Dev Blog 1

Image

The time is finally upon us. The art portion of the Liberated Pixel Cup has reached its deadline, which means that the programming portion of the contest has begun! The competition is a month long in which us code monkeys need to use the art assets that were generated to make the best possible game that we can. Since this pixel cup is “liberated”, all of the source code will be available under the GPLv3.

I am working with someone that I only through IRC (#liberatedpixelcup on Freenode) with the nickname of fr33mind. We will be making a Pokemon inspired game where you control monsters to use in combat. The actual gameplay details will get fleshed out more as the competition goes forward.

We are using libGDX to make the game. LibGDX is a fantastic Java library that allows us to write a game that runs on the desktop (GNU/Linux, Mac, Windows) and on Android devices with very little platform specific code.

Above is a screenshot of my experiments with libGDX. Here you see a path of ghosts that was generated by my implementation of the A* pathfinding algorithm. It took a long time to wrap my head around it but it is a crucial element to the game considering that users will move across the map not only with arrow keys, but by touching/clicking areas on the map (my Android phone has no D-pad). This makes decent pathfinding a must have so I wanted to try to get it out of the way early. The code performs well on the desktop but for some reason takes about 3 seconds to run on my Android phone, which is a serious problem. My choice of data structures or too much memory allocation could be the problem and I need to investigate who the culprit is. I’m using a PriorityQueue and a HashMap to maintain lists, and a Pool (in libGDX) to minimize memory allocation, yet the problem persists.

I’m going to try to keep this development blog going over the course of the month with screenshot updates. Let’s see if I can manage to actually do that.

UPDATE:
Turns out the performance problem was because of how I was drawing the path on screen and NOT the algorithm itself. I have since abstracted away the things that are dependent upon a specific tile map implementation and have a rather generic set of classes to use for pathfinding.

From the blog David Thompson » WSU CS by davexunit and used with permission of the author. All other rights reserved by the author.

Final blog post and all is well it seems

The semester is over and this is basically my last blog post for now, but im actually thinking of keeping this blog and beginning to use it for things that i find interesting.

 

Basically the euca2ools group presentation seemed to have gone pretty well and everything worked while giving it(which is awesome). Considering the amount of problems that we have been running into coming up to this day we were very excited that everything worked.

John in our group was actually able to upload a CentOS image and get it running on our cloud the previous day of the presentations, and then on the day of the presentations we were able to get a third image up and running with no Walrus errors and SSH into that instance. Dhimitri and I were kind of surprised to say the least cause the day before Walrus was giving us the 403 Forbidden error, so it seemed to have fixed itself….

 

Walrus may have just had a hiccup and that restarting it that day may have solved the issue we were having. Dhimitri also managed to get up a new node running which you could see with the euca-describe-availabilityzones command. All in all, it seemed that the Euca2ools wiki worked out for the best and seemed that a lot of people were able to follow a lot of the steps to use for themselves. This was a really fun and interesting project to work on despite a lot of the issues that kept happening on our way but i think it was for the best cause many of us gained a lot of experience and a lot of understanding of the whole Cloud computing and what it is.

From the blog armindoa » WSU CS by mindoftw and used with permission of the author. All other rights reserved by the author.

Couple of weird oddities..

Leading down to the couple of weeks of the semester and beginning to finish up/wrap everything that we have done up to present, we ran into a couple of issues.

Dhimitri and I were in the same Euca2ools group for the presentations so we were working together through the weekend on what we were going to present and go through as a demo during the presentation. As he was working on a script, i was going through and testing our cloud by uploading a different image and kernel and trying to get more instances up and running, and also deleting images from the cloud.

 

The first issue that we ran into was a problem with getting a new instance up and running. At first i thought it was cause i did not bundle the kernel and image together correctly, so i tried it over and over again until i though it was perfect. The image that i used was the same image as the one that was currently running, so when it was not working we knew we had a bit of a problem. From what the NC log told us we were getting some type of 403 forbidden error and seemed to be stopping us from running instances.

A second issue that occurred, was after uploading quite a few images, kernels, and ram-disks the amount of images on the cloud was kind of cluttered so i wanted to delete some of them. When running the command to delete these images however they were not being removed. We would de-register them and delete but they were not being removed. They stayed on the cloud and listed as de-registered so we restarted the services and still nothing the images appeared back on the cloud as normal.

From the blog armindoa » WSU CS by mindoftw and used with permission of the author. All other rights reserved by the author.

Success at running images!

Towards the final weeks of the semester we actually managed to put together a cloud that was basically running. I say basically running because there still seems to be a few bugs here and there that causes some issues every once in a while.

In the week that we managed to finally get an image up and running Dave actually had decided to reinstall eucalyptus on our cloud with the packages that Eucalyptus team had end up putting together halfway through the semester. During class he actually managed to quickly install all of the packages and set everything up, while long and I managed to package and image with a kernel that was working on the ECC cloud, and we actually managed to get it running.

This was a success at running an image and all seemed well but there was still some work to be done, we could run one image but when we tried to run more it was not allowing us to due to not enough resources and seemed not to be assigning IP’s correctly. So there must have been a problem with the network configuration, Mike was tasked with flattening the network and after some tweeks that Dave did to the networking configuration on the cloud all seemed much better.

We were able to get multiple instances up in the long run and the troubleshooting that Dhimitri and I have been doing seemed to help locating where some potential problems were by going through the nclog file.

From the blog armindoa » WSU CS by mindoftw and used with permission of the author. All other rights reserved by the author.