Tag Archives: Quarter-3

CS343-01: Third Quarter Blog

Software Constr – Blog Three

APIs are something we come across a lot, especially the openapi.yaml file we look at for the Microservices Activities in class. So, I wanted to make a note for myself on what APIs are, the benefits, and the different types.

Firstly, what is an API? API stands for Application Programming Interface and it’s a mechanism that helps two software components communicate by the use of definitions and protocols. “For example, the weather bureau’s software system contains daily weather data. The weather app on your phone “talks” to this system via APIs and shows you daily weather updates on your phone.” And there are four different ways an API works: SOAP, RPC, Websocket, and REST.

The SOAP API is short for Simple Object Access Protocol API and it works with the client and server exchanging messages and other the use of XML. Remote Procedure Calls, RPC, APIs has the client complete a procedure on the server in which the said server would send back an output. Websocket APIs use JSON objects to pass the data being used and supports a two-way communication between the client apps and the server.

REST API is one we had just worked with in class and had homework on. It’s the most popular since it’s flexible and has the client send a request as data to the server which starts to use internal functions to return outputs back to the client. REST stands for Representational State Transfer that defines functions such as GET, PUT, DELETE, etc., all of which we have seen in the openapi.yaml file.

The REST API has four main benefits: integration, innovation, expansion, and ease of maintenance. Integration is used to increase development speed since the functionalities won’t have to be made from scratch because of the fact that APIs are used to integrate new applications with existing software systems.

Innovation is where industries can change with new arrivals of apps entirely since they can make changes without having to rewrite the entire code at the API level. “Businesses need to respond quickly and support the rapid deployment of innovative services.”

Expansion is something where it’s a unique chance for businesses to meet the needs of their customers across so many different platforms. “For example, maps API allows map information integration via websites, Android,iOS, etc. Any business can give similar access to their internal databases by using free or paid APIs.”

And finally, ease of maintenance. REST APIs act as a sort of gateway between systems. They each make changes internally so that the API isn’t impacted and in response? “Any future code changes by one party do not impact the other party.”

Source: https://aws.amazon.com/what-is/api/

, ,

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.

CS348-01: Quarter Three

Software Process Management – Blog Three

In class, we’ve been learning about clean code and heard the name “Uncle Bob” multiple times. Because of this, I was trying to learn more about him and what else I could from clean code. Which led me to the SOLID Design Principles.

To start, Uncle Bob is a man named Robert Cecil Martin who had been born on December 5, 1952, according to Wikipedia and many other sites I had looked at. He is an American software engineer, instructor, and author – most recognized for promoting many software design principles and for being an author and signatory of the influential Agile Manifesto. He authored many books, articles including being the editor-in-chief of a C++ Report magazine, and was the first chairman of the Agile Alliance. He actually was self taught and joined the software industry at the age of seventeen. “Martin is a proponent of software craftsmanship, agile software development, and test-driven development. He is credited with introducing the collection of object-oriented programming (OOP) design principles that came to be known as SOLID.”

What is SOLID? Well, it’s an acronym for the five different object oriented design principles that Robert C. “Uncle Bob” Martin had created. In this acronym, there lies the Single Responsibility Principle, Open-Closed Principle or OCP, Liskov Substitution Principle, Interface Segregation Principle, and finally Dependency Inversion Principle.

One of the principles, the Open-Closed Principle, was something that I remember learning in class, even having to refer to it for a question in an activity we did. Modules, classes, and functions should be open to extensions, but closed for modifications. The rest however? Those were new and at first glance, my immediate thought was to Google it.

According to Wikipedia, the Dependency Inversion Principle or DIP is “a specific methodology for loosely coupled software modules. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details.”

The Liskov Substitution Principle in the source says that “if class A is a subtype of class B, then we should be able to replace B with A without disrupting the behavior of our program.” It was actually initially introduced by a woman named Barbara Liskov in 1987 where it was based on sustainability so that nothing would break.

Barbara Liskov is an American computer scientist who was a pioneer contributor to many programming languages and distributed computing. Some of her most notable work includes “the introduction of abstract data types and the accompanying principle of data abstraction, along with the Liskov Substitution Principle, which applies these ideas of object-oriented programming, subtyping, and inheritance.”

Source: https://medium.com/@lavishj77/solid-design-principles-dd3c0afe7e97, https://en.wikipedia.org/wiki/Robert_C._Martin, and https://en.wikipedia.org/wiki/Barbara_Liskov

, ,

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.

More on Clean Code

For this quarter’s blog, I decided to research more into the book Clean Code by Robert C. Martin and found a blog discussing the good, the bad, and the ugly regarding the book. I chose this article because we have spent the last few classes working through POGILs related to the book. The author writes about how Clean Code has had its positive and negative impact on software development. For new programmers, the author highlights useful practices that are good for new software developers, such as good naming techniques, not repeating your code, and having functions only do one thing. On the other side, the author describes how the age of the book and its dated techniques can be considered obsolete. Clean Code was written over twenty years ago and is heavily focused on Java programming and outdated extensions that “[limit] the applicability for modern programming practices.” Another criticism by the author is that applying the rules of the book all the time can result in harmful code, such as excessive abstraction and code that is harder to maintain over time. The author argues that programmers should learn when these rules should be broken and apply them on a case by case basis.

This article was certainly helpful to give a further opinion on Clean Code and its subject matter. After going through the Clean Code POGILs in class, I had learned many things that I was not previously taught about programming. They were helpful to correct some bad practices that I was guilty of, such as commenting in place of poorly written code. However, some topics, such as the levels of abstraction or how to use classes and methods properly were initially confusing to me. It seems like the author also expresses similar frustrations in regard to these things. The author of the article describes any of the things from the book can be described in one phrase: “it depends.” Overall though, I felt it necessary to dive deeper into Clean Code for my own benefit. Even though I do not plan on pursuing a career in software development, many of these rules and structures can be applied to other disciplines within computer science and information related fields. When the time comes for me to work on a personal project or something needed for my career, I feel better equipped to handle such a task knowing what I know now. Even if some of the advice is dated, most of it can still be applied and result in better software development.

Original blog post: https://gerlacdt.github.io/blog/posts/clean_code/

, ,

From the blog CS@Worcester – zach goddard by Zach Goddard and used with permission of the author. All other rights reserved by the author.

Importance of version control in the process of development

An infographic illustrating version control processes in Git, showcasing key operations like fork, merge, and pull request.

As a software developer version control you will undoubtedly run into version control of any projects which you are working on. Eventually a developer will have to fix bugs or add a feature to a product. In order to learn more about version control there is no better website to learn from than Github.

What is Version Control?

Illustration of distributed version control system showing interactions between developers and the main repository.

Github gives an amazing allegory: Imagine you’re a violinist in a 100-piece orchestra, but you and the other musicians can’t see the conductor or hear one another. Instead of synchronized instruments playing music, the result is just noise.

Version control is a tool used to prevent this noise from happening. It helps streamline development, keep track of any changes, and allow for upscaling of projects.

Version Control tool factors

Version control may not be necessary depending on the scale of your project, however most of the time it is useful to have it set up. Some of the factors of deciding to use version control include:

  • Scalability: Large projects with many developers and files benefit from VC
  • Ease of Use: User friendly UI helps manage learning curves and adoption.
  • Collaboration features: Supporting multiple contributors and communication between them.
  • Integration with existing tools: Using tools everyone already has access to.
  • Supports branching: Ability for developers to work on different parts of development benefits a project greatly.

Common Version Control pplications

  • Git: Git is an open-source distributed version control tool preferred by developers for its speed, flexibility, and because contributors can work on the same codebase simultaneously.
  • Subversion (SVN): Subversion is a centralized version control tool used by enterprise teams and is known for its speed and scalability.
  • Azure DevOps Server: Previously known as Microsoft Team Foundation Server (TFS), Azure DevOps Server is a set of modern development services, a centralized version control, and reporting system hosted on-premises.
  • Mercurial: Like Git in scalability and flexibility, Mercurial is a distributed version control system.
  • Perforce: Used in large-scale software development projects, Perforce is a centralized version control system valued for its simplicity and ease of use.

Final thoughts

Every developer has at one point heard of Git, and without a doubt it may be one of the best developer tool ever invented. I have prior experience using version control but this research was an important refresher to learn from. If you wish to learn directly from Github you can read the article this blog was inspired by here.

, ,

From the blog CS@Worcester – Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

Refactoring your program

Sometimes when a program undergoes consistent updates it can get messy, in cases like this it can be useful to refactor it. I’ve had a few experienced cleaning a program however I have never refactored an entire program. The developers over at refactoring guru luckily have a website dedicated to this subject.

An illustrated depiction of a programming refactoring process, highlighting the importance of clean code.

Purpose for refactoring

When you refactor a program you are fighting something they call technical debt and create clean code. With clean code comes a few benefits including:

  • Obvious for other programmers
  • Doesn’t contain duplicate code
  • Minimal number of classes and other moving parts
  • Passing of all tests
  • Easier and cheaper to maintain

What is technical debt?

“Technical debt” as a metaphor was originally suggested by Ward Cunningham using bank loans as an example.

You can make purchases faster If you get a loan from a bank however now on top of principal you have interest. and with time you can rack up so much interest that the amount of interest exceeds your total income, making full repayment impossible.

The same concept can be applied to code. Speeding up without testing new features will gradually slow your progress.

Some causes of technical debt include:

  • Business pressure
  • Lack of understanding the consequence
  • Failing to combat the strict coherence of components
  • Lack of tests, documentation, communication.
  • Long-term simultaneous development in several branches
  • Delayed refactoring
  • Incompetence

So when should one refactor?

Refactoring guru comes up with a few instances on when to refactor.

  • Rule of three:
    • When doing something for the first time, just get it done.
    • When doing something similar for the second time, cringe at having to repeat but do the same thing anyway.
    • When doing something for the third time, start refactoring.
  • Adding a feature:
    • If you have to deal with someone else’s dirty code, try refactoring it first; Easier for future features.
  • Fixing a bug:
    • Clean the code and errors will discover themselves
  • Code reviews:
    • Last chance to tidy up the code
    • Best to perform these reviews in pair with an author

We know when, but how?

Refactoring is done via a series of small changes, each making the existing code slightly better while leaving the program in working order.

Here is a checklist on refactoring done the right way:

  • The code is cleaner
  • There should not be new functionality
  • All existing tests pass

Final Thoughts:

Overall, I found this website on refactoring to be really informative and would recommend refactoring guru as a starting point. The most important thing that I got out of this is that developers should always try to write clean code or clean code as its undergoing development. Unfortunately sometimes software development can be very time containing and its not always possible which is why refactoring is important.

, ,

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.