For the last month, including the our class’s most recent homework assignment, we have been working on Rest APIs. In the last assignment, we had to construct different Rest API Endpoints. For this blog, I wanted to learn a lot more about Rest APIs and try to master them better. I found a great blog about it all on stackoverflow.blog, and I will attach a link to that blog at the bottom of this post. I definitely recommend checking it out to learn more on this subject like I did. Rest APIs are among some of the most popular available web services that is used to allow clients and browser applications to communicate with a server. These APIs must be designed in a way that keep in mind account security, performance, and easy usability. An important thing for Rest APIs is JSON. Almost all networked technologies can use JSON as it is the standard for transferring data, and it is accepted by Rest APIs for request payloads. A lot of what the blog I read goes over is how to write Rest API Endpoints and coding. It explains the importance of including error handling, filtering, sorting, and nesting resources. It shows even more specifics like how collections should be named using plural nouns rather than verbs. This blog is super great for helping with every single specific when writing these endpoints, even down to the exact code to use for all the different common HTTP errors. It later goes on to explain using cache data to improve performance as well as specifics for versioning APIs. Overall, this blog taught me a lot more about writing these API Endpoints, and the best part is it helped show how it all is done with clear examples of actual code. It even came in helpful during my homework assignment earlier this week. Anyone looking to learn about or brush up on this topic should follow the link to see the blog that I used to research for Rest APIs, and I guarantee it will be extremely educational!

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.

In a previous blog post, I did a little research on UML and ER diagrams, and tried to express how valuable I believe they are in the real world. Today, I plan to dig deeper into the specifics of these diagrams like their formatting and meanings (if one were to look at a finished diagram. There are many specifics for a great UML Class Diagram that help to make it even more useful than simply drawing it out to represent different programs or databases. The example I discussed in my previous post when I referenced this was how the difference between a plus or minus sign before variable names shows how the variable can be public or private (plus being public and minus being private). The next thing I would like to attempt to explain is the importance of how the lines between boxes on the diagram are drawn. Each is specific enough to show exactly what type of relationship is being made between the boxes using arrows, triangles, dashes, strikethroughs, and more. If there is a full line between two boxes then it is a relationship and having a triangle at one or more of the boxes demonstrates that that box or those boxes are providing many things to the relationship. If it has a strikethrough instead, then it is providing one thing (two strikethroughs means one and only one). The boxes can have one-to-one, one-to-many, and many-to-many relationships depending on how the line between them is drawn. These rules apply more toward ER diagrams, but there are many similarities to common UML diagrams. For UML diagrams, we often use open or closed arrows or diamonds at the end of our lines that help indicate the hierarchal relationship between the boxes. Using these symbols, along with changing whether the line is dashed or solid, we can demonstrate inheritance, association, and much more. So we already can see that the format of these diagrams can show more than just the basics, but let me continue to explain even more. Before I continue though, I would like to say that visual-paradigm.com is an extremely useful website that describes all of this even better than I can. I accessed it to help me research these diagrams for two different blog posts now, and I definitely recommend giving it a look. I will leave the link to it at the bottom of this post as usual. Anyways, I want to describe the formatting of the boxes themselves next. This is for UML Class diagrams more than it is for ER diagrams, but it could be applied to both. In general, each box will represent a class in some program (or a table in a SQL database), and they are often separated into three rows. The first row is the name of the class, the second row is for the variables, and the third row is for methods (or functions, operations, etc.). Each variable and method can be public or private as I already discussed, and the methods can include the parameters in the parentheses as well as the return type at the end of the line. There is much more that can be explained, but I would like to end this post by expressing that these diagrams can be made however seems most fit for us. If we do not need to know all of the details of methods and variables, we can simply make our diagram as straight forward as we want by just putting names for the boxes. This is for looking at the diagrams conceptually rather than getting stuck in the details of each class. If we want to show a lot of the class, but not all the nitty-gritty details, we can use the specification approach, which shows details of the classes, but not all. Lastly, if we want our diagram to include all parts of the classes, we can do that as well, and it is called implementation. These are all valuable methods and designs, and it is up to the user to decide what is the best for them.

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/

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.

Fairly earlier in this semester we worked with Unified Modeling Language (UML) and Entity Relationship (ER) diagrams. These tools are both extremely useful in representing databases. I often find that the way these diagrams show databases without coding is similar to how pseudocode shows how a program or method works without explicitly coding. In this way, like pseudocode, these diagrams are perfect for putting together a project before actually programming it like brainstorming. For my final project this semester in a separate class, I had to make a database for an ice hockey program using SQL queries. Before I even started writing queries for that project, I started putting it together in an ER diagram without even thinking about it. This made the actual programming for that project ten times easier. For the purposes of this blog, I decided to dive deeper into studying UML and ER diagrams to try to learn even more about them. I found an awesome article about UML Class Diagrams at visual-paradigm.com that tried to be a tutorial on how they work. I will leave the link to it at the bottom. It backs up my claims that they diagram is used primarily for visualization of projects after, during, and most importantly before they are programmed. It also went over a ton of specifics and formatting for the diagrams that we went over in class this semester like the layout of the tables or boxes and the different arrows that showed relationships in the model database. It gets way more in depth than I plan on being in this blog post like when to use a plus sign instead of a minus sign for variables in the tables (for private and public variables). I definitely recommend checking it out yourself as it taught me a lot, not just now, but at the beginning of the semester itself. Similar to the situation with Docker for me, I found that it was supper awesome that I was able to see that learning these diagrams in class would prove useful in real life. When I used a diagram for my final project in my other class (which was not required), I knew that these were very important tools in the real world. For that reason, I am especially happy that it was one of the topics that we covered this semester.

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/

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.

A large topic that we covered this semester has been Docker. For that reason, I decided to do a bit of outside research on what it does well and how to use it as best as possible. Most of the helpful information that I found for this topic came directly from Docker’s website in the Docker Overview section. I will put the link to that at the end of this post. The website claims that Docker is used mainly for enabling the user to separate their applications from their infrastructure so software can be delivered quickly. This definitely holds true with what we have learned in class and with what we have used Docker for specifically during this semester. It is a free platform that thrives off of helping users develop, ship, and run applications. Its biggest strength is that is shortens the time it takes to go from writing code to running it in a production. Docker containers are indubitably important because they allow many developers to edit and program locally while being able to share their work with others. Containers, to put it simply, are runnable images. Images are templates that have instructions to help build containers and are read-only. A lot of work for docker actually is done in command prompt applications like Git Bash or Terminal. For this class, I used Terminal because I have a MacBook. At first, when using Docker in this class, it was very unclear to me how it all functioned or what the point of using it was. After some time, I began to realize the importance of it as it made connecting programs easy and quick for me. It has come to my attention that the Computer Science department at Worcester State is actually trying to create an entire database for the cafeteria workers with the help of undergraduate students. This was very exciting for me to hear for many reasons. I always am appreciative when I know that what I am learning in school has real life implications and uses, and this motivated me to want to learn it even more. Not to mention, it might be a specific platform that I will need to use in my Capstone for my last semester here before graduating. This blog post has been an extra excuse to take some time to research Docker even more than before and dive deeper into learning what it is for/why we use it rather than simply how to use it. This is not to say that I would not have done more research on Docker outside of class in general (especially with the Capstone next semester), but more to say that this blog is in some way motivating me to get the research done and helping me understand the platform even more by allowing me to discuss my findings. I definitely recommend anyone wondering about Docker to read the information I studied before this blog post by using the link I will put at the bottom. Coming from the Docker website itself, I believe it is a great reference to learn about the free platform and extremely helpful when trying to discover how it works and why we use it.

https://docs.docker.com/get-started/overview/

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.

The Law of Demeter was proposed by Ian Holland in 1987. During the development of a system called Demeter using oriented object programming, Holland and his colleagues realized that the code that fulfilled a series of rules was less coupled. Although it is called The Law of Demeter, it is not really a law, but more of a guideline to help reduce coupling between components. When applying LoD to object orientated design, there is a set of four rules that formalizes the “Tell Don’t Ask” principle;

You may call methods of objects that are:
1. Passed as arguments
2. Created locally
3. Instance variables
4. Globals

A great example of this is:

    class User {
        Account account;
        ...
        double discountedPlanPrice(String discountCode) {
            Coupon coupon = Coupon.create(discountCode);
            return coupon.discount(account.getPlan().getPrice());
        }
   }
   class Account {
       Plan plan;
       ...
   }

Here account.getPlan( ).getPrice( ) violated the LoD. The most obvious fix is to delegate/tell:

    class User {
        Account account;
        ...
        double discountedPlanPrice(String discountCode) {
            // delegate
            return account.discountedPlanPrice(discountCode);
         }
     }
     class Account {
         Plan plan;
         ...
         double discountedPlanPrice(String discountCode) {
             Coupon coupon = Coupon.create(discountCode);
             return coupon.discount(plan.getPrice());
         }
      }

Each function should have a limited amount of knowledge as opposed to knowing about the whole object map so our neighboring objects need to know what we have done in order to depend on them to propagate that message to the correct location. Following this rule is hard, which is why it is called the “Suggestion of Demeter” by many because it is so easy to violate. Following this rule, though, is extremely beneficial because any function that “tells” instead of “asks” is decoupled from the rest of the code around it.

The blog I retrieved this information from was https://hackernoon.com/object-oriented-tricks-2-law-of-demeter-4ecc9becad85. The information was extremely easy to follow and understand. The coding examples given to show the difference between following the LoD and not following it were simple and clear. I also found the explanation of LoD given to be simple and to the point. Going forward with coding, although understanding that following LoD can be hard, I plan to utilize this guideline in order to enhance and simplify all of my future codes.

By following the LoD in future coding endeavors, my code will be easier to test, I can reuse classes more easily, the amount of coupling and dependencies between classes will be reduced, my code will more flexible when I make changes to it and it will be more maintainable.

Information gathered for this blog:
https://medium.com/better-programming/demeters-law-don-t-talk-to-strangers-87bb4af11694
https://hackernoon.com/object-oriented-tricks-2-law-of-demeter-4ecc9becad85
https://en.wikipedia.org/wiki/Law_of_Demeter

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

As I have started to learn some about Javascript, I am very intrigued by the new territory and the strangeness that comes with it, at least for someone like myself, with most of my experience coming from object oriented programming languages like Java and C. As I now know, Javascript is a functional programming language, which has some fundamentally different structures and uses. For this reason, I have started to looked into the usefulness of functional programming, as languages like Javascript and Python are quickly on the rise. I found an article on Xiaoyun Yang’s personal blog entitled Why Functional Programming From A Developer Productivity Perspective which has helped me make some more sense of the intent and uses of functional programming. The article starts with basic info on FP, stating how object oriented programming came to popularity in the 80s with the use of GUIs and how, “it’s easier to program things that use a fixed number of operations for an unlimited number of operation,” but how now, “stateful programming is more of a liability” since, “there is an increasing emphasis on asynchronous, distributed, multi-core and cloud computing.” The article then dives into FP design patterns, which explain its usefulness. The intent is for functions to act as, “pipes for data to travel through,” with Higher Order Functions taking functions as input, and polymorphic function adding to reusability and versatility. The first pattern is the Loop Pattern. The emphasis is on abstraction. In the example, for loops are used for arrays of different types, and the goal is to get rid of the type by, “[parameterizing] the loop action as a function parameter and the initial value as a data parameter.” This provides for the reusability of the function in different contexts. The next pattern is Types. The article compares Scala being type-safe to Javascript. This means, “you can impose the argument type and return type when you first define your function in Scala.” This means for non-type-safe languages like Javascript, the onus is on the programmer to ensure clashing types do not lead to errors. While sometimes type inference in Javascript can be convenient, it can create problems when working with different types. The third pattern is Monads. This means that one can use monads instead of, “hard coding error handlers,” with a monad essentially being a wrapper. There are so many errors to worry about when handling user input, so this is advantageous. The last pattern is Monoid. An example is given for a function to find is any strings in array(s) are not empty. It shows that whatever order the arrays are given to the function, or wherever the unempty string exists, the function still works, preserving associativity and commutativity. Monoid laws help verify correctness. The article finishes by stating that FP promotes reusability and modularity through abstracting functions. This is all new to me and I hope this knowledge helps me soon, as the next language I intend to learn will be a FP language like Javascript or Python. It is essential to keep up with the fast-paced world of computer science.

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.

In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem.^[1][2] Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology.
The term was popularized by Kent Beck on WardsWiki in the late 1990s.^[3] Usage of the term increased after it was featured in the 1999 book Refactoring: Improving the Design of Existing Code by Martin Fowler.^[4] It is also a term used by agile programmers.^[5]
(From Wikipedia, the free encyclopedia)

During her presentation at RailsConf in 2016 called Get a Whiff of This, Sandi Metz talks in depth about code smells, the practical effect of recognizing them and doing refactoring. My reason for choosing this particular source of information was because she gave real life examples and comparisons that helped me to better understand problems within codes that were humorous and I found her explanation of the types of code smells and how to fix them entertaining, easy to understand and very useful. Sandi presented examples of code she herself had written and demonstrated through diagrams and easy to follow steps how to refactor the code to make it neater. At the end of her presentation Sandi gives reference to a static analysis tool called Reek that you can run on your code and it will tell you what to go look at, so you don’t even need to go figure it out yourself.
This presentation really boosted my confidence as a programming student and gave me higher hopes as a future programmer. While watching this presentation video, I learned that most code is a mess, even the best coders can have messy code, and when given difficult or complex code, it can be broken down and easily fixed even if I am not able to understand everything within the given code. Going forward, I will definitely be referring back to this video to help me spot and correct any imperfections within my own code or any code I am given.

The 5 different categories of code smells are:

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.