12/19/2024

At the start of the semester, we were introduced to Design patterns. These techniques include anything from completely restarting a project to erasing redundancy such as repetition of code. Our biggest focus was to use overrides ONLY where needed and it was our job to figure that out because there were certain methods that did need to be overridden.

We worked on a Duck Simulator that has methods for each duck itself, but some ducks needed functions to be overridden were as some didn’t need them for example a decoy duck does not fly. Whereas a mallard duck does therefore there is no need to override a function for that decoy duck. This design pattern is very easy to overuse specially for people not introduced to these types of problems.

The interesting part of this homework was also using the previously covered topic of UML diagrams. This homework though was more about reading and understanding but the main point was to transfer it to Java code. This was a nice intertwining moment because it makes it easier in the future to understand not just the UML but also the design patterns taught.

We created two different interfaces for the Duck Simulator which one was a Quack() and the other was Fly(). These made it so we as the developer do not have to keep overriding. Hence, we end up with a bit more files, but it saves us the trouble in the future if we needed to edit let’s say the decoy duck to fly. Now we are able to go into one file and edit without having affected any other files. Which in larger systems can become a big issue because now the developer has to go into every single file that uses said method which waste time and can be missed if multiple people are working on it at the same time.

We also learned about the singleton method which just retrieves a single instance of an object and if it is not there then it creates it does not use multiple of the same object. There is one down side I read about in the source and it was about unit testing. The source talks about many unit testing frameworks that rely on inheritance when producing a mock object which is a problem because the singleton class is private, and static methods cannot be overridden. Overall, it is still applicable, and we used it in the intermediate part of the design patterns homework to learn how it worked better to always only have one instance of a method.

Source: Design Patterns in Java

From the blog CS@Worcester – Cinnamon Codes by CinnamonCodes and used with permission of the author. All other rights reserved by the author.

12/18/2024

At the beginning of the semester, we started to work with UML diagrams. We talked about the different types of diagrams and how each is written in plantuml. We started with UML class diagrams which show each files relationship to one another. It also shows the multiplicities which is important to know when, for example making an appointment. For example, only one person can have multiple appointments, but not multiple people can have the same appointment.

We also learned about Sequence UML diagrams which look different but have the same idea behind them. This type of diagram shows the method and its parameters in a sequence, hence the name. It shows how each class will be used whereas the class UML diagram just shows what the method name is and what the parameters for that specified method are as well.

The sequence UML shows the overall order of things whereas the class UML shows the general method and parameters that will be used. Both diagrams could be used on their own but help a lot more to be organized when used together. UML is very important to be able to visualize code without having to read over every single line trying to understand it all. It helps especially if working in larger groups for everyone to understand. There is another type of diagram that we didn’t talk about but is used a lot which is” use case diagram”. This diagram shows functional requirements, for example someone shops and the diagram show the possible actions the user can make. Such as view items or purchase more, but then behind those actions are more possible actions that can be taken like checkout or just cancel purchase. There is also activity diagrams that need to fill in a condition whether the use input the number in the right format or not. If the user did not then it throws an error, but this is all a visual representation of what the code is supposed to look like and be as well.

 UML diagrams have taught me to be organized in my own coding projects with visualizing my functions and the parameters I will be using. It also organizes file management when using the class UML diagram along with showing multiplicities. Even using other UML diagrams that can organize different parts of the same code and show how it will be used for example combining the class and sequence UML diagrams is a great way to use both for not just visualization but also organizing it all for a final product.

Source: Unified Modeling Language (UML) Diagrams – GeeksforGeeks

From the blog CS@Worcester – Cinnamon Codes by CinnamonCodes and used with permission of the author. All other rights reserved by the author.

11/23/2024

In class this week we continued to learn about REST APIs, but this week we dove deeper into the source code. We went over the javascript files in the source code, and we also looked at the .yaml files.

We took a deeper look into the path endpoints in each endpoint file while looking at what each method asked for. Such that getGuest() for example had to make a request and also get a response. This method actually utilizes the “body” as a parameter to return a response. Whereas getOne() uses “param”, this is because when the endpoint needs a specific parameter to search, alter or even delete it will utilize wsuID as a parameter. Whereas the getGuest() retrieves all the guest which are stored in an array which will mean using “param” as our request will not work because we are not searching for one specific wsuID, but we want all the wsuID’s to be returned hence why “body” is used when sending a request.

We also learned how the mount-endpoint file did not need to be altered due to it just handling each endpoint the same. The endpoints only needed to be changed or added onto the endpoints path instead of the lib path. This is because they are handled the same way, but each do different things, hence why just adding a file to the endpoint path will be the best thing to do and nothing else would need to get done since the endpoint-mount already accesses the endpoint directory.

Also reading the article below showed me how the tags must be limited to those allowed by the JSON schema ruleset. It also shows how paths work in a sense such as /guest/{wsuID} which we also went over in class. If a wrong letter is entered it will return an error code either 400 or 404 depending on what the user’s input is. There is also for every method whether it is GET or CREATE endpoints each endpoint will have a wait method to check with the database if the wsuID is already in the database or not and if it is not then it will create it. Every endpoint also needs a method and a path then the body of the object, but it needs to be written in a try catch statement. This is very important due to feedback purposes for testing and such that if the server is down the user will get a 500 code or if everything is working well and the user inputted the correct information the code would be 200 or 201 depending on the method called. Each response code should return a message as well as what the error is for it to be identifiable. This is needed for each endpoint regardless of the case.

Source: OpenAPI Specification – Version 3.1.0 | Swagger

From the blog CS@Worcester – Cinnamon Codes by CinnamonCodes and used with permission of the author. All other rights reserved by the author.

11/16/2024

REST is a crucial topic in APIs in which I just began to learn about this semester. Before this, I had never heard of REST API so I assumed it would be a challenging concept to grasp since I had no prior knowledge regarding this style.

This text dives into the definition, explanation, and exploration of what REST is, how it is used, and how we can get the most out of it in certain services. The text highlights the importance and nuances of REST API’s while still idolizing their importance of implementation.

Initially, during classes I found the material hard to grasp since I had no idea as to what Rest was and how it worked. However, everything began to make more sense when we started working with the hands-on assignments involving actual API calls.

I learned that with certain API calls you are able to retrieve, post, edit or delete information from the backend. These important methods are called HTTP methods which play a key role in manipulation, addition, or removal of information.

A couple key concepts that I learned based off of the reading are that REST APIs are cacheable, which are essential for improving performance and managing network traffic due to its cache technique. The reading also gives insights into how API’S are considered a layered system, in which it allows you to add proxies and gateways. These are very important concepts to keep a mental note on for the future as working in a frontend environment, especially when accessing backend data.

I expect to use these resources for building websites or even mobile applications, ideally when scalability and flexibility play an important role on what I am working on. I also learned that Resp API’s work alongside Node.Js and Express.Js. Node.Js is a back-end JavaScript runtime environment, while Express.Js is a web application framework for Node.Js. This relatively new information to me, due to my experience only using C++, Java, and Python for specific applications.

Rest API’s can be tested by integrating parameters and seeing how the output compares to the expected output, while also ensuring the correct error codes are being returned for methods like GET, POST, and others. The text also mentioned endpoints, and while I grasp the basic understanding, there is still more to learn in order to increase my confidence with this REST APIs Overall, I expect to use this knowledge and information in future jobs, as per my interest in software development, and in my personal projects. Additionally, I learned a bit more about swagger, which was introduced in class to demonstrate the GET, PUT, DELETE, and POST methods of the Rest API.

Source: The REST API Handbook – How to Build, Test, Consume, and Document REST APIs

From the blog CS@Worcester – Cinnamon Codes by CinnamonCodes and used with permission of the author. All other rights reserved by the author.