Category Archives: Blog-4

FRONT/BACK ENDs

The blog entry “Front-End vs. Back-End Explained by Waiting Tables at a Restaurant” breaks down the differences between front-end and back-end development in a straightforward, humorous, and visually appealing manner using an everyday scenario. The front-end is likened by the author to a waiter in a restaurant, who deals directly with customers and is in charge of communication, presentation, and ensuring that they receive what they want. The back end is compared to the kitchen, where the actual cuisine is prepared by the chefs (or servers, databases, and business logic). Although the kitchen is not visible to patrons, the restaurant cannot operate without it. The article also describes how APIs function similarly to a menu, outlining exactly what can be requested and how the restaurant would react. For novice engineers, this example helps make difficult technical concepts more understandable.

I picked this article because it directly relates to the concepts we have been covering in class, the transition from monoliths to client-server and ultimately microservices. We witnessed firsthand how the front-end and back-end communicate through well-defined paths in our Microservices Architecture exercise. For example, the StaffBrowser or AdminBrowser interfaces with the GuestInfoBackend, InventoryBackend, or ReportingBackend. Each backend service mimics the kitchen/waiter structure outlined in the article by processing data and returning results to the browser. The article’s description of how requests go through the system is consistent with even the API endpoints we looked at, such as CheckInGuestFrontend or the Express.js servers that power each system. Knowing this example made it easier to understand why our class project is divided into several components and why there needs to be exact communication between them.

As I thought about the post, I saw how crucial it is that both front-end and back-end engineers comprehend their responsibilities and the connections between the systems. Separating responsibilities makes systems easier to maintain, scale, and debug, as we discovered when we compared the monolith versus microservices models in class. The essay reinforced the point by demonstrating how, similar to a restaurant, uncertainty at the front-end or back-end results in delayed service, mistakes, and disgruntled customers, in this case, users. I was also reminded of the importance of APIs. We were effectively looking at the menu that specifies exactly what the front-end can request and how the server will reply when we examined the OpenAPI definitions and backend endpoints in our code. I want to use this example going forward whenever I create or work with APIs. It will be easier for me to organize cleaner services and interact with coworkers if I know what belongs in the “kitchen” and what belongs in the dining room. I want to focus more on how front-end requests move through the various back-end systems and how each service does its function on its own as we continue to work with microservices.

Front End v. Back End Explained by Waiting Tables At A Restaurant

From the blog CS@Worcester – A Bostonians Blogs by Abdulhafeedh Sotunbo and used with permission of the author. All other rights reserved by the author.

Teamwork and Project Management

https://www.geeksforgeeks.org/software-engineering/software-engineering-software-project-management-spm/

When learning about the entire software building process and an Agile framework, we learned about a better and more efficient way of developing a project as a team. The overarching theme for having a well maintained project that stays its course is having a good software project management system in place. It is important because software is intangible, making it difficult to visualize progress or quality without strict oversight.This article from GeeksforGeeks discusses Software Project Management, a discipline within software engineering focused on planning, implementing, monitoring, and controlling software projects. The goal is to deliver high-quality software on time and within budget by effectively managing resources, risks, and changes.

The practice encompasses several critical aspects, starting with detailed planning to outline scope and resources, followed by the active leading of diverse technical teams. Managers must oversee execution through rigorous time and budget management while also handling maintenance to address defects early. To achieve this, project management employs specialized management strategies, including risk management to minimize threats, conflict management to resolve team disputes, and change management to handle shifting goals. It also involves technical controls like configuration management to track code versions and release management to oversee deployments. Some drawbacks are touched on being that the process can add complexity and significant communication overhead especially with large teams. 

I think it’s important to understand the different aspects of project management and what goes into creating a project as a team.Working as a team is critical in software engineering because modern projects are often too complex and massive for any single individual to handle efficiently. By dividing tasks, teams can work in parallel, allowing features to be built, tested, and deployed simultaneously which significantly speeds up the development process. Beyond just speed, teamwork improves code quality through practices like peer reviews and pair programming, where “multiple eyes” on the code help catch errors that a solitary developer might miss. It can be easy as a student to think that getting in this field will mean sitting behind a desk and working on your own aspect of a project, however, working within a team and adhering to the group structure and work flow management can be a shock to people new to not just the software field but to the workforce in general. When working in a large team it can be easy to stray from the  goal or specifications without strict planning and oversight. Software project management provides the necessary framework to navigate this, ensuring that unique client requirements are met precisely rather than relying on assumptions. 

From the blog Anna The Dev by Adrianna Frazier and used with permission of the author. All other rights reserved by the author.

The Magic Behind Frameworks

https://aws.amazon.com/what-is/framework

When learning about backend and front end architecture, we got to explore the use of frameworks. A framework is a set of reusable software components like libraries, APIs, tools, that help developers build applications more efficiently; they are the structural “skeleton” of a project. Instead of writing everything from scratch, you build on top of a framework’s building blocks and standardized patterns, letting you focus on the unique parts of your application rather than reinventing foundational pieces. This semester was my first real exposure to using a framework and I decided to explore what exactly it was and how to best use one in future projects. To build on my base level knowledge, I came across this article found on the Amazon Web Services site. 

The article explains how using a framework has several advantages like having better code quality. Since the programmer reuses parts that are typically well tested, the code is more efficient and easier to maintain. Also, having less duplication in code decreases certain code smell and leads to faster development. Having a framework can also aid in better collaborations especially when using the same architecture patterns. I remember thinking of a framework as a library, however this article explains that the difference is that frameworks define the structure and flow of your application, controlling how and when things happen, whereas libraries are just a set of helper functions you can call when needed. 

Frameworks are not just one size fits all. As an aspiring web developer, I will need to know how to utilize web development specific frameworks. For example, frameworks such as Angular, VueJS, and Bootstrap are all common frameworks that are utilized by the top tech companies. Frameworks are extremely useful in web development because they give developers a structured, efficient way to build websites and web applications without starting from scratch. A framework provides prewritten components, templates, and patterns for common tasks like routing, handling requests, managing databases, rendering pages, and securing user data. Many web frameworks include built-in security protections, performance optimizations, and ways to organize files so the project scales as it grows. There are, however, benefits to learning more than one framework especially if it helps with more full stack development. Choosing the right one for your project depends on the requirements. In the future I will need to analyze the scalability, the ecosystems or available libraries, longevity, and speed of development for my project.

From the blog Anna The Dev by Adrianna Frazier and used with permission of the author. All other rights reserved by the author.

Testing with Mockito

During class, we have been doing many testing methods including Junit 5 and for the past two weeks we have been using Mockito, so for today’s blog, I want to focus more on the framework and testing with Mockito. Before we get started let us talk about what is mocking. Mocking is a process of developing the objects that act as the mock or clone of the real objects. In another word, mocking is a technique where mock objects are used instead of real objects. The purpose is to isolate and focus on the code being tested. Mock uses objects such as Fakes, Stubs, and mocks. A fake object has working implementation but takes shortcuts which makes them not suitable for production. Stub object usually does not respond to anything outside that is programmed in for the test. Mocks are objects that are preprogrammed with expectations which form a specification of the call that is called to receive.

Now let us move on to what Mockito is, Mockito is a java based mocking framework that internally uses the Java Reflection API to generate mock objects for a specific interface. Mock objects as I explained previously are used as dummy objects. The main purpose of using the Mockito framework is to simplify the development by using mocking external dependencies and use them in the test code. Few benefits of Mockito include writing beautiful tests with a clean & simple API, it creates mock objects using annotations like for example @Mock, and In Mockito, there is no requirement for writing your mock objects. The first link I have provided gives a lot of detailed examples of Mockito. It has helped me to learn the framework fully. I highly recommend to check it out and follow the example.

https://www.vogella.com/tutorials/Mockito/article.html

https://site.mockito.org/

https://www.javatpoint.com/mockito

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

The difference between Stubs and Mocks

A mock is an object that can set an expected value, which will verify that the desired action has occurred. The stub is the object that you pass to the code under test. You can set expectations on it to work in specific ways, but those expectations are never verified. The stub’s properties will automatically behave as standard properties, and you cannot set expectations on them.

If you want to verify the code’s behavior under test, a simulation with appropriate expectations is used and validated. If you’re going to pass only values that might need to work somehow but are not the focus of the test, you can use stubs.

Important note: Stubs will never cause a test to fail. 

I believe the most significant difference is that you have written the stub with predetermined behavior. Thus, you will have a class that implements the dependencies that you have disguised for testing purposes (most likely an abstract class or interface), and a class will handle the method only through the response that is set. They don’t do anything fancy, and you’ve already written stub code for them outside of testing.

Simulations are expectations that stubs must set during testing. The simulation is not set up in a predetermined way, so you have the code to perform the simulation in your tests. The mockery is determined at run time because the code that sets expectations must be run before they do anything.

The difference between stubs and stubs

Tests written with simulation usually follow a test pattern of initialize-> set expectations -> exercise -> verify. The pre-written stub will be followed by an initialize-> exercise-> verify.

Similarities between stubs and stubs

The purpose of both is to remove all dependencies from testing a class or function so that your tests are more focused and straightforward when trying to prove it.

The most crucial difference between Stubs and Mocks is their intention. Explain this in the WHY stub and WHY simulation below

Suppose I’m writing test code for the Mac Twitter client’s public timeline controller

Here is the sample code for the test：

twitter_api.stub(:public_timeline).and_return(public_timeline_array)

client_ui.should_receive(:insert_timeline_above).with(public_timeline_array)

controller.refresh_public_timeline

Stub: The network connection to the Twitter API is very slow, which makes my tests slow. We knew it would return the timeline, so we made a stub that simulated the HTTP Twitter API so that our test could sprint, even if I were offline.


Mock: We haven’t written any UI methods yet, and I’m not sure what we need to register for UI objects. We wanted to write test code to see how my controller would work with UI objects.

In short, there is a difference between Mock and Stub objects, and RhinoMocks recognize that they allow us to write tests that better illustrate their purpose. The mock object is used to define the expectation that, in this case, I want to call the method A () with such an argument. Record and verify this expectation with ridicule. On the other hand, Stubs have a different purpose: they do not record or validate expectations but rather allow us to “replace” the behavior and state of “fake” objects to take advantage of test scenarios.

https://martinfowler.com/articles/mocksArentStubs.html

View at Medium.com

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

The difference between Stubs and Mocks

A mock is an object that can set an expected value, which will verify that the desired action has occurred. The stub is the object that you pass to the code under test. You can set expectations on it to work in specific ways, but those expectations are never verified. The stub’s properties will automatically behave as standard properties, and you cannot set expectations on them.

If you want to verify the code’s behavior under test, a simulation with appropriate expectations is used and validated. If you’re going to pass only values that might need to work somehow but are not the focus of the test, you can use stubs.

Important note: Stubs will never cause a test to fail. 

I believe the most significant difference is that you have written the stub with predetermined behavior. Thus, you will have a class that implements the dependencies that you have disguised for testing purposes (most likely an abstract class or interface), and a class will handle the method only through the response that is set. They don’t do anything fancy, and you’ve already written stub code for them outside of testing.

Simulations are expectations that stubs must set during testing. The simulation is not set up in a predetermined way, so you have the code to perform the simulation in your tests. The mockery is determined at run time because the code that sets expectations must be run before they do anything.

The difference between stubs and stubs

Tests written with simulation usually follow a test pattern of initialize-> set expectations -> exercise -> verify. The pre-written stub will be followed by an initialize-> exercise-> verify.

Similarities between stubs and stubs

The purpose of both is to remove all dependencies from testing a class or function so that your tests are more focused and straightforward when trying to prove it.

The most crucial difference between Stubs and Mocks is their intention. Explain this in the WHY stub and WHY simulation below

Suppose I’m writing test code for the Mac Twitter client’s public timeline controller

Here is the sample code for the test：

twitter_api.stub(:public_timeline).and_return(public_timeline_array)

client_ui.should_receive(:insert_timeline_above).with(public_timeline_array)

controller.refresh_public_timeline

Stub: The network connection to the Twitter API is very slow, which makes my tests slow. We knew it would return the timeline, so we made a stub that simulated the HTTP Twitter API so that our test could sprint, even if I were offline.


Mock: We haven’t written any UI methods yet, and I’m not sure what we need to register for UI objects. We wanted to write test code to see how my controller would work with UI objects.

In short, there is a difference between Mock and Stub objects, and RhinoMocks recognize that they allow us to write tests that better illustrate their purpose. The mock object is used to define the expectation that, in this case, I want to call the method A () with such an argument. Record and verify this expectation with ridicule. On the other hand, Stubs have a different purpose: they do not record or validate expectations but rather allow us to “replace” the behavior and state of “fake” objects to take advantage of test scenarios.

https://martinfowler.com/articles/mocksArentStubs.html

View at Medium.com

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

The Long Road

 When working on an open-source project, get in the habit of downloading the latest version of the code (preferably from their source control system) so you can review its history and track future developments. Take a look at the structure of the codebase and think about why the code is organized the way it is. Take a look at the way developers organize their code modules to see if it makes sense, and compare it to the way they might have used it. Try to refactor the code to understand why its coders made the decisions they did, and think about what the code would look like if you were the one coding it. Not only will it give you a better understanding of the projects; Also make sure you can build those projects. If you’ve found a better way to do something, you’re ready to contribute code to the project. Inevitably, as you go through the code, you’ll come across decisions you completely disagree with. Ask yourself if the developers of the project might know something you don’t or vice versa. Consider the possibility that this is a legacy design that needs to be refactored; And consider whether making a toy implementation for the relevant feature would help clarify the issue.

You end up with a toolbox filled with all sorts of quirks that you’ve collected from other people’s code. This will hone your ability to solve small problems more quickly and quickly. You’ll be able to tackle problems that others think are impossible to solve because they don’t have access to your toolbox. Take a look at the code for the Git distributed source control system written by Linus Torvalds, or any code written by Daniel J. Bernstein (known as DJB). Programmers like Linus and DJB occasionally make use of data structures and algorithms that most of us have never even heard of. They’re not magicians — they’ve just spent their time building bigger and better toolboxes than most people. The great thing about open source is that you can look at their toolbox and make their tools your own. One of the problems in software development is the lack of teachers. But thanks to the proliferation of open-source projects on sites such as SourceForge. Net and GitHub, you can learn from relatively representative code examples from the world’s programmer community.

In ODS, Bill Gates says: “The most subtle test of programming ability is giving the programmer about 30 pages of code and seeing how quickly he can read through it and understand it.” He realized something very important. People who quickly learn directly from the source code will soon become better programmers because their teachers are the lines of code written by every programmer in the world. The best way to learn patterns, idioms, and best practices is to read the open-source. Look at how other people to code. It’s a great way to stay relevant, and it’s free. — Chris Wanstrath at Ruby 2008 [

Pick an open-source project with deep algorithms, such as Subversion, Git, or Mercurial source control system. Browse through the project’s source code and jot down any algorithms, data structures, and design ideas that seem novel to you. Then write a blog post describing the structure of the project and highlighting the new ideas you’ve learned. Can you find a situation in your daily work where the same idea can be applied?

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

The Long Road

 When working on an open-source project, get in the habit of downloading the latest version of the code (preferably from their source control system) so you can review its history and track future developments. Take a look at the structure of the codebase and think about why the code is organized the way it is. Take a look at the way developers organize their code modules to see if it makes sense, and compare it to the way they might have used it. Try to refactor the code to understand why its coders made the decisions they did, and think about what the code would look like if you were the one coding it. Not only will it give you a better understanding of the projects; Also make sure you can build those projects. If you’ve found a better way to do something, you’re ready to contribute code to the project. Inevitably, as you go through the code, you’ll come across decisions you completely disagree with. Ask yourself if the developers of the project might know something you don’t or vice versa. Consider the possibility that this is a legacy design that needs to be refactored; And consider whether making a toy implementation for the relevant feature would help clarify the issue.

You end up with a toolbox filled with all sorts of quirks that you’ve collected from other people’s code. This will hone your ability to solve small problems more quickly and quickly. You’ll be able to tackle problems that others think are impossible to solve because they don’t have access to your toolbox. Take a look at the code for the Git distributed source control system written by Linus Torvalds, or any code written by Daniel J. Bernstein (known as DJB). Programmers like Linus and DJB occasionally make use of data structures and algorithms that most of us have never even heard of. They’re not magicians — they’ve just spent their time building bigger and better toolboxes than most people. The great thing about open source is that you can look at their toolbox and make their tools your own. One of the problems in software development is the lack of teachers. But thanks to the proliferation of open-source projects on sites such as SourceForge. Net and GitHub, you can learn from relatively representative code examples from the world’s programmer community.

In ODS, Bill Gates says: “The most subtle test of programming ability is giving the programmer about 30 pages of code and seeing how quickly he can read through it and understand it.” He realized something very important. People who quickly learn directly from the source code will soon become better programmers because their teachers are the lines of code written by every programmer in the world. The best way to learn patterns, idioms, and best practices is to read the open-source. Look at how other people to code. It’s a great way to stay relevant, and it’s free. — Chris Wanstrath at Ruby 2008 [

Pick an open-source project with deep algorithms, such as Subversion, Git, or Mercurial source control system. Browse through the project’s source code and jot down any algorithms, data structures, and design ideas that seem novel to you. Then write a blog post describing the structure of the project and highlighting the new ideas you’ve learned. Can you find a situation in your daily work where the same idea can be applied?

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.