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.

Hello
blog (mood-status: feeling Good), writing this blog after thanksgiving
dinner and eating well like pretty good with a plate of food alongside
hanging the family. But anyway, on writing about this week-11. To be
truthful here, I writing this because I am falling behind on blogs when
there is nothing to talk about, besides kept being busy with other
courses like HWs and projects, etc. (You get the point. Well, if you are
a student) 

I decided to go on the Syllabus to look at the course topics.

I found the subject of Modeling along with Unified Modeling Language (UML) & C4 Model.

Unified Modeling Language

Large
Companies’ applications that execute core business applications and
keep a company going can more than some code modules. It can structure
in a way that enables:

• scalability
• security 
• robust execution under stressful conditions. 

Their structure is that maintenance programmers can find and fix a bug
that shows up after moving on to other projects. These programs can
design to work perfectly in many areas, and business functionality is
not the only one. A well-designed architecture benefits any program, and
not only the largest ones as singled out. It mentioned large
applications first because the structure deals with complexity, so the
benefits of the network compound as the application size grows large. 

Another use of a structure that enables code reuse was design time.
Ultimately, companies build up models of parts, each unit representing
an implementation stored in code modules. At coding time, the developer
can as promptly import the code module into the application. When
another application needs the same functionality, the designer can
quickly import its module from the library.

The C4 model

The
C4 model made by Simon Brown designates on UML and the 4+1
architectural view model. It breaks down software into smaller units for
modeling. Like the quick methodology, the C4 model requires fast,
efficient sharing and constant updates of software architecture in
software development.

The
C4 model (shown as a map). The Maps can build on a different scale. By
changing scales, like for example; The town map with streets and
buildings. Having the C4 model changes the level of a diagram to
describe software architecture. Using the abstraction-first approach, C4
conducts modeling top-down from system context to lower levels.

• Person (Element) – users or roles of a software system
• Software
  system (topmost level in abstractions) – the value of existing systems
  or systems under development and the interaction between those systems
• Container
  (Element) – the internals of software systems, usually applications or
  solutions for data storage. A different concept to containers in Docker.
  It mainly refers to software that is single deployed.
• Component (Abstraction element) – The containers of modules or a set of interfaces grouped as a functional unit.
• Relations – dependencies or data flow between abstraction elements.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Hello
blog (mood-status: feeling Good), writing this blog after thanksgiving
dinner and eating well like pretty good with a plate of food alongside
hanging the family. But anyway, on writing about this week-11. To be
truthful here, I writing this because I am falling behind on blogs when
there is nothing to talk about, besides kept being busy with other
courses like HWs and projects, etc. (You get the point. Well, if you are
a student) 

I decided to go on the Syllabus to look at the course topics.

I found the subject of Modeling along with Unified Modeling Language (UML) & C4 Model.

Unified Modeling Language

Large
Companies’ applications that execute core business applications and
keep a company going can more than some code modules. It can structure
in a way that enables:

• scalability
• security 
• robust execution under stressful conditions. 

Their structure is that maintenance programmers can find and fix a bug
that shows up after moving on to other projects. These programs can
design to work perfectly in many areas, and business functionality is
not the only one. A well-designed architecture benefits any program, and
not only the largest ones as singled out. It mentioned large
applications first because the structure deals with complexity, so the
benefits of the network compound as the application size grows large. 

Another use of a structure that enables code reuse was design time.
Ultimately, companies build up models of parts, each unit representing
an implementation stored in code modules. At coding time, the developer
can as promptly import the code module into the application. When
another application needs the same functionality, the designer can
quickly import its module from the library.

The C4 model

The
C4 model made by Simon Brown designates on UML and the 4+1
architectural view model. It breaks down software into smaller units for
modeling. Like the quick methodology, the C4 model requires fast,
efficient sharing and constant updates of software architecture in
software development.

The
C4 model (shown as a map). The Maps can build on a different scale. By
changing scales, like for example; The town map with streets and
buildings. Having the C4 model changes the level of a diagram to
describe software architecture. Using the abstraction-first approach, C4
conducts modeling top-down from system context to lower levels.

• Person (Element) – users or roles of a software system
• Software
  system (topmost level in abstractions) – the value of existing systems
  or systems under development and the interaction between those systems
• Container
  (Element) – the internals of software systems, usually applications or
  solutions for data storage. A different concept to containers in Docker.
  It mainly refers to software that is single deployed.
• Component (Abstraction element) – The containers of modules or a set of interfaces grouped as a functional unit.
• Relations – dependencies or data flow between abstraction elements.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.