When writing code, it is always important to write as cleanly and efficiently as possible. Code can be sometimes confusing and hard to read to begin with, and writing poor code makes it much harder. We measure the quality of code using design smells. Design smells are different metrics such as rigidity and fragility which measure how poor a certain part of design is.

Yonatan Fedaeli writes in his article “Software Design Smells” that there are seven main design smells: rigidity, fragility, immobility, viscosity, needless complexity, needless repetition, and opacity. These smells exist in all code to a certain extent, but some code has much less smells than others. The goal is to limit each of these smells as much as possible.

Rigidity is software’s inability to change. This makes it very difficult to add new features to a project. An easy way to fix this design smells is by designing each section of software independently of each other since the more interdependence a project has the more rigid it will be.

Fragility is a software’s tendency to break whenever a change is made. This is similar to rigidity, but different in that it is not difficult to make the change but difficult to make the change work. Any small change can totally break the entire project in a very fragile design.

Immobility is a project’s inability to reuse components. When a project is immobile, each piece of the project is so dependent on the rest that is almost impossible to use it in a different context. When writing a large project it is important to reuse code so that you are not wasting time writing the same thing multiple times.

Viscosity is how closely a project follows the original design goal. When a project is very viscous each new feature either preserves a complex design or does not follow the design goal. When a project’s environment is viscous it means that the project exists in a complex work environment. It may be difficult to build or test and you may spend extra time trying to get the project to run.

Needless complexity is when a project is more complex than it needs to be. Software is already complex to begin with, and it is important to write clear code so that people reading it do not need to spend extra time trying to figure out what it does.

Needless repetition is when code is repeated multiple times when it could be abstracted. This is similar to immobility in that code is not reused, but different since this smell focuses on abstraction and how code does not need to be rewritten many times.

Opacity is a project’s inability to be understood by the developer. This is similar to needless complexity in that an opaque project can be needlessly complex, but includes much more than that. Usually an opaque project has a poor initial design which is why it is difficult to understand.

When writing code it is important to write clean, efficient code. Keeping design smells in mind when coding will keep your projects clean and good quality.

From the blog CS@Worcester – Ryan Blog by rtrembley and used with permission of the author. All other rights reserved by the author.

This is the Keynote speaker for day two of Raleigh ISSA’s 2021 Information Security Conference. In my previous post about the Keynote of Day 1 Keynote Speaker I detailed my attachment to the Association and my appreciation for the monthly resource of meetings that I used to attend when I lived in Raleigh. The presentation for Day 2 is a little different in that it’s not themed around Halloween or any comedic points.

The speaker, Armando Seay, is a Co-Founder & Board Member at Maryland Innovation and Security Institute which is an organization that assists clients in finding security solutions and applying them to their IT infrastructure. He begins the presentation discussing the importance of understanding security standards and practices around the world and how young professionals in the IT field get their starts in the US, Ukraine, Israel, and other various countries. He describes his organization as “geographically boundless” due to the fact that they assist clients all over the world.

The importance of being able to work with people around the world is something that I’m finding to be more and more important as I travel around the US from one cultural hub to another. I grew up in Columbia, South Carolina and then I joined the Coast Guard after High School and now I’ve moved to Worcester. Each of these places are full of different demographics and being successful in each of them required working with different people from different backgrounds and finding common ground to build upon. I have friends that were born in Haiti, China, West Africa, Europe, Canada, and they all come from backgrounds that are exceptionally different from my own. Engaging with people from different backgrounds allows one to broaden their perspective and find solutions that they wouldn’t normally find on their own.

Armando goes on to talk about the Academic Partners and what they call their “Partner Ecosystem,” I believe that POGIL team structures kind of works as a microcosm of these in that when groups are switched around we form partnerships that we can maintain and use to better understand our assignments and accomplish goals.

One thing that I found particularly interesting was his discussion about Maritime Attacks, that is to say attacks on the software that ships use to either catalogue their cargo, their navigation, or even their movement. It’s important to be aware of software vulnerabilities and best practices so that we aren’t exposing others to cybersecurity vulnerabilities due to our negligence. Armando closes his presentation discussing Zero-Trust policies and how critical it is to verify any process or user in your network and everything you do before you entrust any security clearance to them.

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

This week, I have a chance to work with JavaScript files of a backend in my homework-5. However, there were many syntax that I had never seen, so I got no sense when I was writing code. Thus, I looked for some resources to satisfy my curiosity and to get a better understanding of JavaScript.

JavaScript Tutorial is one of the resources that I find useful because it provides all the information related to JavaScript. First of all, from the website, I know that JavaScript is one of the most popular programming language of the web. It is used to program the behavior of a web page. Next, according to the website, I can look up and learn more about new syntax or new definitions of JavaScript respecting to my homework 5. For example, the keywords “let” and “const”, Array Iteration, Async/Await appearing in my homework make me question that what they are for and why they are there in the .js files.

However, based on the information from the website I can answer those questions. It said that “let” is used to defined a variable, whereas “const” is used to define a constant variable which cannot be reassigned. Every “let” and “const” variables cannot be redeclared and have block scope. For the Array Iteration, JavaScript has many methods to operate on every item of an array, such as map(), filter(), reduce(), every(), especially forEach() which I have met in my homework. forEach() is used to apply a condition or a function inside the parenthesis to each element of an array. For Async/Await, it said that “async” is used to make a function return a promise, and “await” keyword is only used inside the “async” function. “await” will make a function wait for a promise. So, what is a promise in JavaScript? Promise is a JavaScript object that links producing code and consuming code. The below picture is an example given by the website to explain clearly what producing code and consuming code are.

In conclusion, in my opinion, this website is one of a good resources to help me learn more about JavaScript. It includes all the information that I wanted to know and it also explains clearly every new definition with easily understandable examples. Thanks to this website, I am getting more familiar with JavaScript and get a better understanding of the code given in my homework-5. So, I believe that this website will give me a good foundation to work with my homework-5 or with any .js files.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

blog.ndepend.com/10-reasons-why-you-should-write-tests/

For as long as I have been aware of it, I have been skeptical of the value of software testing. It has always struck me as unnecessary busywork, mostly because that is how writing them for my classes feels (granted, that’s generally how writing code for any class feels in my experience). Either the program works or it doesn’t, right? Why bother writing a test when you could use that time to tighten the ratchet on the code you’d otherwise be testing, or even move on to something else?

In an attempt to broaden my horizons, I sought out some arguments in favor of testing. One idea I found, from Avaneesh Dubey (which he discusses in the above article), is probably the one I personally find the most compelling. He argues that the hallmark of a poorly constructed test case is essentially one that is too narrow in its scope or the functionality that it covers. Proper tests, he argues, must reflect “usage patterns and flows.”

Jumping off of this, I would articulate this slightly differently. I think that proper testing methodology would necessarily force developers to be aware of the boundaries they want to encapsulate between. For example, it would be kind of absurd to write tests to make sure a factory class works correctly, because whether or not you’re even using the factory paradigm is almost certainly too technical for non-technical product managers to care about. My understanding of testing is that it’s primarily a way for this kind of person to make judgments about the development process independently of the actual developers.

When you write software tests, you are, or at least should be, asking yourself questions about the high-level flow of the program – what it’s actually doing in physical reality rather than very tiny implementation details – and that is ultimately where your head should be at all times during the development process, in my opinion.

Though obviously, test writing is an important skill for actual work in the industry, I had no intention of ever writing any tests for my personal projects. Now, I’m not really sure that I’m sold on it for personal use, and I’m still a little skeptical about the efficacy of test-driven development in single person projects, but I think it might be of some use to me. In particular, I hope it can help me make some sense of the WebGL code I’m planning to write for a project in the near future, which is certain to contain many fine technical details that can quickly become a headache if not managed properly.

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

For this week’s blog, I was looking more into API since we covered this in the class to know more about it. Application programming interfaces (API) is a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software. API enables companies to open their applications data and functionality to external third-party developers, business partners, and internal departments within their companies. This allows service and application to communicate with each other and leverage each other’s data and functionality through a documented interface, developers do not need to know about how the API is made because they will simply use the interface to communicate with an application and web services.

How an API works: API stays between an application and web server, acting as an intermediary layer that processes data transfer between systems.  APIs are sometimes thought of as contracts, with documentation that represents an agreement between two parties, if one party sends a remote request structured a particular way, this is how party two’s software will respond.  For example, imagine a medical equipment distribution company. The distribution company could give its customers a could app that lets the hospital’s employee check a certain equipment availability with the distributor. The app could be expensive to build, limited by platform, and require long development times and ongoing maintenance. This has several benefits like it lets the customer access data via an API which helps to check information about their inventory in a single place saving time, The distributor can make changes to its internal systems without impacting customers, with a publicly available API it could result in higher sales for the business.

In short, APIs lets you open up access to your resources while maintaining security and control. How you open access and to who is up to you. There are four main types of API those are Open API, Partner API, Internal API, and Composite API. Open APIs are open-source application programming interfaces you can access with HTTP protocol. Partner API are application programming interfaces exposed to or by strategic business partners. Internal APIs are application programming interfaces that remind hidden from external users. Composite API combine data or service APIs. I used this article because it explains API in an easy way, explains about it giving an example which then makes it’s more clear. And in today’s world innovation is very important as technology is increasing day by day so knowing about API is helpful in the future as it helps in fast innovation.

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

This week, I wanted to solidify my understanding of the concept of REST or RESTful APIs, what they are, and how they work. There is a plethora of information on this topic but I’ll be referring to a blog post by Jamie Juviler and a website on REST API that I found helpful.

Before we get into what REST is, let’s first go over what an API is. API stands for application programming interface, and they provide a way for two applications to communicate. Some key terms include client, resource, and server. A client is a person or program that requests the API, to retrieve information, a resource is any information that can be returned to the customer, and a server is used by the application to receive the requests and maintain the resources that the client is asking for.

REST or RESTful is an acronym for Representational State Transfer and is a term used to describe an API conforming to the principles of REST. REST APIs work by receiving requests and returning all relevant information in a format that is easily interpretable by the client. Clients are also able to modify or add items to the server through a REST API.

Now that we have an understanding of how REST APIs work, let’s go over what makes an API a RESTful API.

There are six guiding principles of REST that an API must follow:

1. Client-Server separation

The REST architecture only allows for the client and server to communicate in a single manner: all interactions are initiated by the client. The client sends a request to the server and the server sends a response back but not vice versa.

2. Uniform Interface

    This principle states that all requests and responses must follow a uniform protocol. The most common language for REST APIs is HTTP. The client uses HTTP to send requests to a target resource. The four basic HTTP requests that can be made are: GET, POST, PUT, and DELETE.

3. Stateless

All calls with a REST API are independent from each other. The server will not remember past requests, meaning that each request must include all information required.

4. Layered System

    There can be additional servers, or layers, between the client and server that can provide security and handle traffic.

5. Cacheable

REST APIs are created with cacheability in mind, when a client revisits a site, cached data is loaded from local storage instead of being fetched from the server.

6. Code on Demand

In some cases, an API can send executable code as a response to a client. This principle is optional.

If an API follows these principles, then it is considered RESTful. These rules still leave room for developers to modify the functionality of their API. This is why REST APIs are preferred due to their flexibility. RESTful APIs offer a lot of benefits that I can hopefully cover in my next blog post. 

What is REST

What is an API?

REST APIs: How They Work and What You Need to Know

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Christian Shadis

Docker, a main focus in my Software Construction, Architecture, and Design course, is an essential tool for the modern developer to be able to completely separate the application being built from the developer’s local machine. Essentially, this allows for all the application’s dependencies and configurations to be packaged with the application and independent of the machine the application is being run on. A Docker container is built from an image, which is basically the ‘blueprint’ of a Docker container. Images are easily-reusable, and many images can be found for use on the Docker Hub. Images can be created from scratch using Dockerfiles, which I previously did not understand. In order to improve my Docker skills and gain the ability to create my own Docker images, I chose to research and write about the structure and use of Dockerfiles.

There are situations in which a developer would want to create their own Docker image – maybe they need a specific version of the Ubuntu operating system, or there are specific modifications that need to be made to that operating system before the application can run. Maybe for an application to be run, many slightly modified versions of the same container must be deployed. The developer can address these scenarios by creating a Dockerfile, which contains all software to be included in the image. Any time the image needs to be used, a container can be created with that image in a single command, preventing the necessity of importing dependencies or changing the machine’s configuration repeatedly.

 In Docker Basics: How to Use Dockerfiles, Jack Wallen first describes the necessity and use cases of Dockerfiles. He then supplies a list of keywords that can be used in a DockerFile, such as CMD, which executes a docker command inside the container, ENV, which is used to set environment variables, and EXPOSE, which is used to publish networking ports in the Docker image. From there, Wallen proceeds to demonstrate the process to create a Dockerfile from scratch in a text editor. Finally, Wallen outlines the process for building the usable image from the Dockerfile. The article concludes with a short section including a second worked example, this time building a Dockerfile for a different operating system.

 Knowing how to create containers using pre-built images from DockerHub is an important first step for a developer to get started with Docker, but the true power of Docker images is realized when the developer has the capability to create a new image with the exact configurations needed. Creating custom images is a skill I expect to use often in my development career, since a large portion of applications in development today use Docker containers.

Reference:

https://thenewstack.io/docker-basics-how-to-use-dockerfiles/

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

On this post I decided I need to catch up on learning javascript for my homework assignments, having no real prior experience I needed more than just the simple basics but rather things I must know to succeed and not be confused. Which lead me to this article below.

https://dev.to/deen_john/resources-to-master-javascript-3d0p

I have honestly not done any web development aside from a brief exposure to html in high school, and while I did get some experience with javascript I didn’t experience enough to retain any memory of it. So this article above has not only the fundamentals in forms of multiple links and tutorials, it also contains a plethora of actual content in the article on each subject that is brought up. Often searching for articles on javascript it would be just a repository of links, but this is structured with other links prior to an example given as well as an explanation.

Right off the bat the type system was interesting to learn about, considering that the types are not actually different but the syntax is quite different as well as coercion being even a thing is interesting. That you could multiply a string and a number and get a number due to implicit conversion.

Another interesting thing I learned is that every value that isn’t a primitive value is an object. So variable1 = 500; is a primitive value so it’s simply just a number value. If it doesn’t contain a primitive value of any kind it will need to be defined as an empty object with {} after the name declaration. There is no item declaration type like int or short or double. There is just var name = (primitive value) or {empty object}.

There was also another interesting thing that I didn’t expect was that null is used as an object and that undefined is generally there to show that a value has been declared and not assigned a value.

I also learned about truthy and falsy, and in specific I was surprised to learn that the Or operator didn’t quite work like I expected. Generally, when using Or there are three conditions I would expect and one I wouldn’t worry about. The first operand is true, the second operand is true, neither operands are true and lastly both operands are true. With the first, second and fourth resulting in a TRUE, I was surprised to learn that javascript only cares if the first operands is “truthy” otherwise it returns the second.

This article helped me a lot and will at least give me a head start and not be confused when I try using Or and expecting a positive result and not just the second operand. It seems unintuitive in some regards but it may just seem that way due to me being so used to the other operators for such a long time.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Microservices seem to be a very popular concept in software design, and it is one I have trouble fully understanding. Because of this, I wanted to spend some time developing my understanding. Chris Richardson’s “Introduction to Microservices” is the first article in a series of seven discussing microservices; it compares microservices architecture to monolithic architecture, and it is where I began looking.

Monolithic architecture typically involves one application at its core built to handle a multitude of tasks. This application may branch out into APIs, adapters, or UIs that allow the application to access objects outside of its scope. This application, along with its more modular pieces, is packaged and deployed as a single monolith.

This approach to software design has some inherent problems. Applications tend to grow in size, scope, and lines of code over time. In a monolithic application, code can easily become too large and too complex to efficiently deal with. The resulting applications are often too complicated for a single developer to understand, which also complicates further development. Larger applications also suffer from longer start-up times. Continuous deployment becomes difficult since the entire project needs to be redeployed. It’s difficult to scale monolithic applications as well as employ new frameworks or languages.

Many of the issues monolithic architecture is prone to can be solved by instead adopting microservices architecture. Microservices architecture involves splitting an application into connected but smaller services. These services are typically dedicated to a single feature or functionality and are usually each run in an individual Docker container or VM.

Using microservices architecture comes with a number of benefits. Splitting a complicated, monolithic application into smaller pieces makes that application significantly less complicated. It becomes easier for individual developers to understand the services, thus making development faster. This also allows a team of developers to focus on a single service. Teams can become more familiar with the service they are working on, and maintenance becomes more manageable. Splitting an application into microservices also makes that application easier to scale.

Despite its benefits, microservices architecture is not without its drawbacks. Splitting an application into microservices can introduce a new complexity. These services need to talk to each other, so a mechanism to send and receive these messages must be put in place. It is also more complicated to test an application that uses microservices. A test class for a monolithic application would only need to start that application, but a test class for a microservices application would have to know which services it needs to work.

I chose this article because I appreciated how thorough the information was. I plan on reading the remaining six articles in Richardson’s series. I had not thought about how connecting microservices together might complicate a project. I will be thinking about the pros and cons of microservices as I continue into my career.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

This week I am going to over a post from the CodeGuru. The post starts by talking about the importance of refactoring, what it is and why we refactor. They define refactoring as the process of restructuring or improving the internal structure of code while keeping the functionality of the code and not changing its external behavior. The article then goes on to talk about when the pros and cons of refactoring and why sometimes it is not best to refactor.

Refactoring code can help prevent bugs but if done improperly, refactoring code can also create bugs in your code so that is why it is important to be careful when refactoring code. In the article, it talks about how it is a good habit to analyze your code before refactoring code. If after analyzing your code, you find that you have to refactor most of your code, they caution you against refactoring the program because you may end up creating more work for yourself. Instead, they recommend that it may be better to start over from scratch. Another practice they implore coders to follow is you should not refactor code if you don’t have the tests or plan to create the tests for that code. This is because, without the tests, you may not have sufficient information about whether or not your code has changed the behavior of the program. Another good practice they recommend is you should wait until you deliver the product and use the time in between tasks to refactor code. Software development can be a very time-sensitive industry so some good practices that we should have as programmers are we should be mindful of the time we have before deadlines and be able to analyze whether a task can reasonably be done in the allotted amount of time. We should also establish clear and achievable goals and refactor code in between tasks and before adding new features to the program so that we can avoid technical debt.

I chose this post to review this week because I think it is a very important topic not just in this class but in programming in general. One of the reasons why I chose this topic, in particular, is because in class we often toss the term around in class, we know what it is and how to do it, but we never really talk about how to do it well or what are some good practices that we should follow. Personally, I have been following some of these practices all along such as gauging my time before deadlines and making objectives along the way, but I also have a really bad habit of deviating from those objectives. There were so many times in my undergraduate career where right before an assignment is due, I ended up refactoring the program from start to finish or redoing the entire assignment from scratch. Now that I know good refactoring habits, I can avoid this in the future.

https://www.codeguru.com/csharp/best-practices-for-code-refactoring/

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.