Self-Directed Professional Development Post #3

For this week’s blog post, I’ve decided to learn more about API documentation. I found a YouTube video titled, “Get an overview of the Java API documentation and how to use it” in order to do this. The reason I picked this topic is because as I create and design programs/software, I will likely be referencing Java API documentation. Therefore it is important that I understand and know how to navigate this information. 

One of the first things this tutorial taught me is that the documentation I will be using will be under Java SE and not Java JDK. The speaker of this tutorial, Steve Perry, did not go too in depth into what Java JDK is so I ended up doing some additional research to learn more about JDK. JDK stands for Java Development Kit and it is a platform released  by Oracle Corporation to develop Java applications. Although this may seem like a trivial thing to learn, I appreciated learning more Java/programming jargon.

After explaining that the different classes in API documentation are grouped by modules, Steve selects the java.base module to walk through because of how commonly used it is. In modules, there are packages which are a group of related classes. The first package Steve introduces and reviews is the java.lang, which contains classes that are fundamental to the Java language. He explains that each package starts out with a description of the package, followed by its interface, classes, enumerations, exceptions, and errors. Steve also refers to the documentation of this particular class as a javadoc which is something I’ve heard before but now know exactly what it refers to. 

Steve then selects the String class, again, because of how commonly used it is. We then learn how to access String’s constructors and methods. Steve shows us how clicking on a method gives you more details, such as a method’s description, parameters, return values, etc. The last useful bit of information I learned from this video was how to access the information for classes if I don’t know what module or package they may be in. I can do this by using the index or clicking on the top left section titled, “All Classes” in order to do so.

Overall, I considered this to be a very worthwhile use of my time because API documentation is something I often get redirected to when I have a question about a particular class I’m using. However, since API documentation contains so much information, I often get overwhelmed and lost in all the classes and information available for a particular class. Because of this blog post and this tutorial, I was able to learn the organizational scheme for API documentation in a way that I will remember. Although it may seem like a small step, it’s a step that makes me a little more confident as a java programmer.

Tutorial link: https://www.youtube.com/watch?v=ULEOb8wLa_k

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

What is an API?

From my other posts, I mentioned APIs quite a few times. But what exactly are they? API’s also known as Application Programming Interface, is a software that allows different applications to connect to each other. Some examples that we see all the time could be when you’re sending a message on a social media platform, using a program, or just checking things on your phone. Doing any of these activities, you’re using an API.

An API works to communication data to different applications. When one is using an application, the application would connect to the internet and send data over to a server. Once the data is retrieved from the server, it then gets interpreted and will perform the necessary actions to send the data back to the application. From here the application will take the data it received and interpret and present the data requested in a way it is readable. This is what an API do. Not only does APIs act like a way for different applications to send and retrieve data, but it also acts like a layer of security. When using any type of application, your phone’s data is never fully exposed to a server its retrieving data from, same goes for the server. This is because instead of sharing every bit of information, only small packets of information are being shared or what is ‘necessary’.

A more in depth example I found while researching this topic is to imagine you’re sitting at a t able in a restaurant with a menu to order from. In the restaurant, the kitchen is a part of the system that will make your order. However how the kitchen is missing the details for what you ordered. In order to receive the order, they must communicate with the server. This is the API. The server communicates to the kitchen with your order in order to make it for you. This is basically what an API does. It connects two applications, so they can connect with each other and deliver the data.

The reason why I chose to write about API is because we will be learning it in class. Not only that but from my previous posts, I have talked about my interest in becoming a full stacked developer. This means I will have to proficient knowledge in both front and backend development. API is used in both. APIs are important to know because it will help me when I decided to create my own application as well, so it is very crucial I know how API’s work.

A post I would recommend to read about API is:
https://www.mulesoft.com/resources/api/what-is-an-api.
Not only does it describe what APIs do, but gives examples and has other links that teaches you more about APIs.

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

Analyzing Code Smells

This week, the topic that I wanted to focus on was design smells. I wasn’t confident in my own knowledge of what exactly design smells were or how to implement that knowledge into my designing of code. So I found a blog post by Sandor Dargo, in which he reviews the book Refactoring for Software Design Smells. Dargo’s blog has a background in software-design related book reviews, so it seemed like a good place to learn a little more about what design smells were.

The review covers a lot of the fundamentals of design smells, much like what we did in class, although it focuses more on what design smells affects within software design, such as understandability and reliability. I really liked this way of thinking about design smells, as simply learning them felt a lot more abstract to me, but showing what it affects and how it can harm the design of software makes it a little bit more understandable, to me at least. The first half of the post talks about the concept of technical debt, and the later half is more on the design smells. Obviously these both impact each other, but I liked his breakdown of technical debt as being similar to taking out a loan to get something done that needs to be done, but if you don’t keep up with that debt you will get further and further into debt until you fail. I think it is a very good analogy to technical debt, and aided in my understanding of the topic as a whole. The final part of the post focuses on common issues that are caused by design smells and how these seemingly insignificant things can make your code less and less usable over time.

I found this review to be extremely useful in my understanding of what design smells are and why code refactoring is so important. The most important aspect of this post to me was the discussion on technical debt. It is such an important aspect of software design to consider, as is allows us to make quick-and-dirty solutions when we need to, but also tells us how important it is to go back and change the code before it gets out of hand. We must design code in a way to make it as easy to use as possible, and easy to build on in the future. If we are able to properly document our code, allow for reusability within the system, and make use of abstraction and encapsulation to make code as simple to follow as possible, we can create an environment that can significantly increase not just our own workflow, but the workflow of any collaborators, or anyone who needs to make use of our code. It is our job as designers to make sure that as time goes on, our code gets easier to work with, especially as complexity increases to meet the demands of our clients.

Source:

https://www.sandordargo.com/blog/2021/01/30/refactoring-for-software-design-smells

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

UML Diagrams

Diagrams are usually a good way to convey an idea. There is an intrinsic human ability to understand abstract instructions in this form. It is not surprising that in designing software we would look for a way to express it as such. UML diagrams are not only helpful as a [mockup]blue_print in designing but also as format to present the main idea in a more straight-forward way to non-tech assets.

I find it interesting the idea of facilitating the introduction of a concept to a non-tech asset (perhaps because most of the time I just want to understand it better myself). I should really explain what I mean by a non-tech asset, this term could be used somewhere else for a different purpose –if you do so know a better word for my definition, please leave a message. I think of non-tech assets as a broad spectrum of individuals that may be involved directly or indirectly to the end-product. There also may be closer relations amongst different expertise that makes part of a certain project alien to a particular group –also tech aware but not omniscient. This is my philosophical attempt at saying some people need to understand how something works not necessarily why it works –this tie well with obfuscation I believe.

So, by the definition given above and by the readings this week it becomes clearer that there is a choice to be made in UML diagrams –should it be all-expressive or partially-expressive? I believe that most tend to stay at the partially-expressive end, which is best because it uses obfuscation to increase clarity. I know this sounds counter to obfuscation but think, a lot of information about something you don’t understand, or care, does not necessarily make things clear. It does the opposite; it muddies the intention; it hides the meaning by overloading the target. Now that we cover this, let’s move to decision making and end with standardization.     

Throughout the last classes (school class) we have been discussing how to optimize code by looking at UML diagrams. The information on the diagram provided us with the information necessary to see the problems accrued by the code’s configuration. So, it is safe to say that there is a minimum amount of information that needs to be in a diagram in order to be fully helpful. It is also a safe bet to say that a lot of the implementations that don’t affect the relationship amongst the classes (not school classes) is too much information. I think that if we code clean (no pun intended) the implementation speaks for itself and it doesn’t need diagram representation, which should only be necessary when we look at many classes interacting.

At the reading we were presented with a very interesting standardization problem. From what I saw there are a lot of ways to use UML for a variety of subjects. There was a discussion about a public (tech public) uproar from a previous attempt to standardize. I think the complexity lies in how many ways these diagrams are used. Maybe software developers would benefit from such standardization but who am I to say. As far as I know if I had to work with a team, I would like them to produce diagrams that follow a particular set of rules instead of looking at a jungle of too much and too little. Fowler says it best in this quote “… there is no hard-and-fast correspondence between the UML and code, yet there is a similarity. Within a project team, team conventions will lead to a closer correspondence” (Fowler, 2004).

References

Fowler, M., 2004. UML distilled Pearson Education, inc.

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

Software product development common mistakes to avoid

Software developers play a critical role in creating to deploying an application, the amount of works and effort that they have to put in is tremendous. Therefore, mistakes are inevitable. According to Hackernoon, a well-known blog for developers, there are seven pitfalls that developers should limit during the development and the solutions.

Planning fallacy (Time creep)
Time is essential while creating a product. Developers want to ship their applications on time and also not taking too much time to develop. The managers want them to meet the deadline without hitting any barriers. The best way to prevent time-consuming as the deadline loomed is to have the best time management. By doing so, we avoid running out of time at the end of the developing cycle and deploy the product on time.

Insufficient budget

Budgets, like time creep, can easily be overloaded if they are not kept in check. Time itself will exceed the cost since time is money. However, We don’t talk enough about this issue and it’s hard to find a good approach to solve the problem. Hence, limiting the time of development and the delays would eventually lead to narrow the cost of production.

Conflicting Communication

Since the pandemic started, we all feel like human interacting and communication have gotten less appreciated. We spent countless hours on video call conferences, did not have face-to-face interactions, and made the connection between us felt apart. As developers, we spend the entire day on laptops, and previously we already get so little human communication unless when we discuss the problem with our team. Pandemic widened that gap between developers and led to miscommunication between each team member. Working remotely makes it harder to express our ideas and thoughts to our team members. As the perception is not demonstrating enough, this might lead to communication breakdown and ultimately causes conflict among team members.

Security

Security has always been a big deal in this industry and especially to developers. Security vulnerability always exists. It’s part of software developer life. Software is among one of the most important things when it comes to secure user’s data. Billions of users have been affected by massive data breaches each year, showing that even big companies can sometimes make mistakes in developing the product. All we can do to minimize the risk of data breaches is to ensure the credibility of that software. By testing as often as developers could, they help cut back that possibility.

Many of the things in this blog is what I think is consequential to developers. More topics need to be covered, but personally, time, money, and security are needed to deserve more attention than the rest while developing a product in the Computer Science industry or in any other industry.

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

cs@worcester – Dream to Reality 2021-09-26 23:53:59

What are UML Class Diagrams

Foremost, UML diagrams

UML stands for Unified Modeling Language and was invented by Grady Booch, Ivar Jacobson, and James Rumbaugh in 1995 while working at Rational Software. We create UML diagrams to help us comprehend the system more clearly and simply. A single diagram does not represent all aspects of the system. UML defines various kinds of diagrams to cover most of the aspects of a system. UML diagram has two categories of diagrams, Structural Diagrams and Behavioral Diagram. Inside Structural Diagrams, there is Class diagram, Object diagram, Component diagram, and Deployment diagram.

UML class diagrams

Class diagrams are the most common diagrams used in UML. Classes, interfaces, relationships, and collaboration are all represented in class diagrams. The features and activities of a class, as well as the system’s restrictions, are depicted in a class diagram. Class diagrams are often used in the design of object-oriented systems since they are the only UML diagrams that can be directly mapped with object-oriented languages.

What is Class?

A Class is an object’s blueprint. Objects and classes are inextricably linked. We can’t discuss one without discussing the other. And, because we utilize classes to generate objects, the entire objective of Object-Oriented Design is not about objects, but about classes. As a result, while a class describes what an object will be, it is not the object itself. Classes, on the other hand, specify the types of things, whereas objects are useable instances of classes. Each Object was constructed using the same blueprints and so has the same components (properties and methods). An object is a member of a class and has states and behaviors, according to the standard definition.

Examples

An example can be such as there is a base class as an animal dog and we create an instance like Bobby, which is a dog. A dog has properties such as color, eye color, height, weight. And the method example for a dog can be such as a dog can jump, can sit, can eat. And for the object which is Bobby, Bobby has property value. Bobby is a yellow color, he has brown color eye; he is 17 inches tall, and he weights 24 pounds. For the methods Bobby can jump, he can sit, can eat as well.

Why UML class diagrams?

I chose this topic because UML diagrams have always made it easier for me to understand the topic/code. It helps me figure out which classes are inherited from which, which classes are abstract, and so on. For example, a class may override a method, but with the UML diagram/markdown preview, I can easily tell where the original method was created and why I have override that method. Also, since our 1st assignment is about markdown preview and UML diagrams, why not. So far, these two websites have helped me gain a better understanding of UML diagrams. https://www.tutorialspoint.com/uml/uml_standard_diagrams.htm https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

But what really is API?

API, absolutely not the IPA’s beers (unless there really is the API beer) that Petr Gazarov, a software developer with more than 3600 followers on medium, mentioned in his blog, is an acronym of Application Programming Interface. Hmm, you might have heard about it but what it really is?

When we type the URL, for example, facebook.com, we send the request to Facebook’s remote server, which is a remotely located computer, and that computer, which is a server, processes the request through an API to display the webpage. From that instance, Gazarov defined that “An API isn’t the same as the remote server–rather it is the part of the server that receives, requires and sends responses.”

One example is the Object–Oriented Design, code is organized into objects, which will later be used to interact with one another. From my own experience, the first time I was aware of using the API was in the Data Structure class, the Oracle API provides specifications for the JVM Platform, Standard Edition, and the instructions on how to use those methods are documented. I was working with Stack in Java and I want to look at the object at the top of this stack without removing it, I will use peek() instead of pop() as instructed from the API documentation to request relevant operations. The Stack is the object designed by Oracle and the peek() function is a public method in that object, and a set of public methods and properties is an API. Web Server API is similar, the idea is to receive requests and responses.

The difference is the format of the request and response, in my case, it was simply just a function with a small operation, in other cases, different APIs provide flexible responses with tons of uses. One thing I learned from his blog is that to render the whole web page, the browser expects a response in HTML containing presentational code, Google Calendar’s API call would return the JSON formatted data.

Another experience that I’ve got when I was working with my friend in a web project is creating the backend of this project, which is developing the GET, POST, PUT, DELETE functions to respond to his request for his frontend application. The role of this API is to return the data, formatted in JSON, which is stored in Firebase database to the person working in the frontend in order to design the graphical user interface.

In short, Gazarov concluded” any piece of software that can be distinctly separated from its environment, can be an “A” in API, and will probably also have some sort of API”. Since this blog consolidates my understanding about API, I hope you will also find it useful.

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

SOLID

Solid principles are divided into five different parts of programming and a design that addresses objects. Robert Cecil Martin or also known as “Uncle Bob”, was the one who introduced this type of anchoring or principle also called SOLID. This is one of the principles, where each letter represents a method which is represented by three letters, and which basically has a principle. When we work with software, which has a poorly managed management mode, we are dealing with a code that can become rigid, a fragile mode, and this makes this software difficult to use. When the code is rigid we are dealing with a code that is difficult to modify, it is difficult to change the way it currently works, or even more difficult to add any other features.

·  Single Responsibility Principle (SRP)

·  Open-Closed Principle (OCP)

·  Liskov Substitution Principle (LSP)

·  Interface Segregation Principle (ISP)

·  Dependency Inversion Principle (DIP)

Single Responsibility Prinnciple

The Principle of Sole Responsibility (SRP) at its core for a class not to change, there should be no more than one reason. And this results in every different class having to work with one method. However, each member in the class is related has a direct connection to what is called the primary function of the class. Unlike the example where a class has multiple responsibilities within it, in this method the possibility that it needs to be changed increases even more. And from all of this, we have an increased risk of presenting flaws whenever a class starts to modify. But by focusing only on one responsibility, this risk is even more limited.

Open-Closed Principle (OCP)

The Open / Closed Principle (OCP) means that classes for extension should generally be open, but for modification they should be closed. “Open for extension” aims to open the creation of our classrooms in order to add new functionality, while new requirements are generated. “Closed for modification” means not modifying a class after we have developed it, as it should never be modified, except to correct defects. These two parts of the principle seem to be contradictory to each other. However, if we structure our classes and their dependencies well, we can add functionality without having to reduce the existing source code.

Liskov Substitution Principle (LSP)

The Liskov Substitution Principle (LSP) can be formed in a variety of ways. LSP is applicable to inheritance hierarchies. He emphasizes that we need to create as many of our classes as possible, so that client dependencies are replaced with subclasses without the client being aware of this change. For this reason, all subclasses are based on functioning in the same way as the basic classes they have. Subclasses do not have to apply only the methods and properties that the class bases have so that they are the true type of behavior. But they must also be consistent with her behavior. And this requires compliance with some basic rules.

Interface Segregation Principle (ISP)

There are some classes that have public interfaces and that are not cohesive. The principle of interface sharing (ISP) explains that clients are not tasked with dependent on interfaces that are not usable by them.

– The first rule is the existence of contradictions between the parameters of the methods that the base class has and that of the compliance in the subclasses.

– The other rule is for preconditions and unconditional. The other LSP considers invariant.

-The other rule is to limit history.

– The last rule of LSP states that a subclass should not throw exceptions that are not thrown from the other base class.

Dependency Inversion Principle (DIP)

(DIP) indicates that high-level modules should not be dependent on low-level modules. Both should be dependent on abstraction. These abstractions should not depend on the details, but these should depend on the abstractions. The idea is that high and low-level modules have, categorizes classes hierarchically. High-level classes or modules are those that deal with much larger groups of their functionality.

References

https://www.jrebel.com/blog/solid-principles-in-java

https://www.geeksforgeeks.org/solid-principle-in-programming-understand-with-real-life-examples/

https://www.educative.io/edpresso/what-are-the-solid-principles-in-java

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

What is Backend Development?

Backend development is the server side of a website. This is everything that the users of the webpage do not see. Backend is mainly focused on databases, APIs, and Servers. In order to help the website, communicate the data being used, programmers who are backend develops write code in order to store data from the webpage into databases. The code written can be read, updated and deleted from the database.

An example of this is when you create an account on amazon. When you click ‘Create Account’ is takes all the information you just submitted, processes that data and stores it into a database. Amazon now have the details you shared into their database. However, you didn’t see it happen because it happened behind the scenes. This is what happens in the backend of the webpage. This is just the beginning of the backend.

Since we mentioned backend developers, lets go into depth on what they do. Backend developers are responsible for building the structure of a software application. Unlike frontend developers who mostly uses only three tools such as HTML, CSS, and JavaScript. Backend developers uses various tools such server-side languages, databases, and servers. Some server-side languages could be Java, Ruby, NodeJS, and .NET. These languages are what most backend developers use to create codes that help the backend of the website work. Databases and servers that are used could be MYSQL, Oracle and SQL server. Databases and servers are where the data from the websites get stored, such as addresses, emails, and any other kind of useful information for the customer or what the website may have. To become a decent backend developer, the skills you must have knowledge of programming languages, and how to use databases, servers, and APIs.

The reason why I chose to write about backend development is because I have an interest in it. I eventually want to become a full stack developer and that means I will have to know both front end and back development. As technology gets more advance, there will be more need for individuals who process such skills. Not only that but I plan take my skills further and someday develop my own websites and other useful applications.

A blog I found that I would recommend is: https://www.interviewbit.com/blog/backend-developer-skills/. This website contains a lot of useful information on backend development for those who are interested in where they should start and understand what it takes on becoming a backend developer.

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

Docker and It’s Components

I chose this article because it explains in detail the components of docker and how they each are applied in different phases of software development. I believe this will help unfamiliar students learn more about the components of docker beyond that of a general understanding. Given that we are already using docker in this course, I imagine we will be using it for future projects as well. A deeper understanding of this platform would be highly beneficial.

The docker service is made up of several components. A container is like a stripped-down virtual machine where programs can be run in isolation. A Docker image is what defines what will make up a container and contains the directions for how and what will run. For example, a MySQL Docker image would contain the instructions for running an instance of MySQL server and exposing the necessary ports. What runs the docker image is called the Docker Engine and is responsible for virtualizing the container on the host machine. The last major component is docker-compose, which allows one to configure storage, network, and interaction between Docker image containers. The purpose of docker is to allow pre-configured containers to run exactly the same wherever docker is installed. Because all containers are identical to the image they are created on, multiple containers can be run to quickly scale to meet performance demands.

I have used docker in the past on multiple occasions, the last being for my database design final project building a full-stack web application. To see how docker is used in a full-stack application, you can review the source code here gitlab.com/mjared94/todo-app inside the server directory. In the app, we used docker to streamline team development and simplify the backend services in use. The application required a database and a way to manage the database during development. Rather than installing the software individually on each of our computers, we used docker to quickly launch the services identically on each machine. This can be done using docker-compose, which allows you to outline how you want your containers to interact with each other as mentioned above.

Our web server was run directly from the terminal relying on the docker services. In production, we could have also containerized our web server to run in conjunction with the other containers. Doing so would have enabled anyone with docker to run our todo application, along with the required backend services, without any prior configuration. Containerizing our application would also make deployment seamless because our pre-configured container could be launched on virtually any web host. After reading this article and understanding the docker components in more detail, I will be better able to use them in the future. 

Blog resource link: https://www.infoworld.com/article/3204171/what-is-docker-the-spark-for-the-container-revolution.html

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