Blog #5: Database Design

As I near graduation, many of my courses become more specialized towards my actual major and concentration. This semester, I have been enrolled in two computer science classes that, despite being very different, have help emphasize each other with their abstract similarities. Software Construction, Design, and Architecture repeatedly proved the value and worth of Database Design and Applications time and time again. The same could be easily claimed with the roles reversed. The reason I want to share this in my blog is not to say they are similar classes, but to express how important it is to me that my courses relate. If a class I take relates to something I do in real life or something I want to do later in life, it is easier for me to put effort into getting the most out of the class as I possibly can. Furthermore, I have already stated in previous posts that knowing that something I am learning is usable in real life is very motivating, while not being sure if I will ever use the information I study can be the opposite. So why does this all relate back to my two separate courses in this semester? It is because both classes are for different concentrations of my major but still share conceptual similarities. I chose to be a software development student which relates to Software Construction, Design, and Architecture directly, while Database Design and Applications is geared more toward Big Data Analytics. Seeing the similarities between these two classes helped show me that what I am studying is very worth it and can be used regularly in my life. I was able to use what I learned in one class directly on something I would practice in the other… at similar time periods in the semester no less. I definitely believe that this was somewhat intentional by my school to have classes like these be on similar timeframes, and I am glad to say that it does actually motivate me a bit and validates the concepts in each course. I do not have a source or link for this post, but I did feel like sharing this because of how adamant I am about this being a great and useful tactic of teaching/learning.

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

The must knows of Architectural patterns (12/10/2020)

When thinking about going into the job market for a computer scientist there is a common theme. This includes big enterprises needing systems or designed to be produced in order to benefit you and their operations. Although before even starting this we need to understand Software architecture. An architectural pattern, in general, is considered to be a reusable solution to a commonly occurring problem. within the Architectural pattern, we tend to see a total of 10 different patterns that make up the basic framework. One of these simple frameworks is a layered pattern. this pattern can be used to structure programs that will be decomposed into groups of sub-categories. with this particular pattern, we see it being used in desktop applications and E-commerce web applications. the second pattern we see is a client-server pattern which is made up of a server and multiple clients. This will allow server components which will allow assisting multiple clients among a broad range of devices.  you will be able to find this pattern most frequently in Emails, documents, sharing, and banking. The third pattern that mostly relates to a big data analyst would be the master-slave pattern. The master-slave pattern is able to distribute the work among identical slave components, which will ultimately compute the final results from the results which then gets fed to the slaves to return. this is mainly used in datasets and databases in replication. the database is usually considered an authoritative source and usually synchronized between the databases of slaves and masters.  In inorder for this to work correctly we need to have them connected to a bus in a computer system in a sense of branches where we see that the master usually has 3 slave nodes. The 4th design pattern we usually see is the Pipe filter pattern. A pipe filter pattern can be used to structure systems that produce and process a stream of data. Each of the said processes is enclosed within the filter component, which allows the data to be processed through pipes. you can think of these pipes to be as a buffer so the data can be synchronized in the dataset if new data arrives. As well you may think of the architectural pattern as a pattern which recurring a solution to a recurring problem. in most cases, you are able to figure out which classes we have as well as how they will interact with each other to see how they will be implemented in a sequence of systems. usually, an Architectural pattern has the most impact in regard to the code which will then impact the whole application usually horizontally or vertically. 

From the blog Nicholas Dudo by and used with permission of the author. All other rights reserved by the author.

Why are software Frame Works important (12/10/2020)

 As we continue to live out life on earth we as people have to go through trials and tribulations that build from the very basic of things. We also tend to take inventions that have been long in the tooth and retool or re event them. When looking at a software Framework you can consider it to be the same idea or concept. A software framework is considered to be a platform used as a foundation in order to develop different sorts of applications. As well when it comes to software frameworks we are allowed to have a structure or the base program to develop specific programs without having to start from scratch. There two different types of frameworks, opinionated and unopinionated. An opinionated framework is considered to be more of an enforced approach in the sense that the developer is allowed to choose the application structure while the users are able to enforce conventions in regard to the framework itself. while on the other hand, we have an unopinionated framework which is considered to be less strict and considered to be flexible for other less experienced developers to use. Unopinionated is considered to be more simplistic in the sense of not having to have a prescribed method to solve problems while still having flexible tools that could be used to solve problems in a variety of ways. With a framework, you’re allowed a model, view, and controller. A model for a framework is the application for the data. in specific, this focuses on the web application is dealing with a user, video, picture, or comment. The view of a framework on the other hand is considered to be the user interface. You can consider it to be like the computer screen where whenever you make a change the screen will always show the updates or changes that have been made. Then the final piece is the controller where it handles the input such as clicks or different browser inputs. In a sense, you’re allowed to think of a framework as a house where it’s the foundation of the house. frameworks allow you to establish a sense of order to the code when you allow it to give it an application. They can be highly customizable to developers because in the sense it is Skelton code where then you can fill in whatever you want to make the program work for your needs in particular. another piece of the puzzle is that it allows you to integrate libraries which allows having a useful methodology from different sites. 

From the blog Nicholas Dudo by and used with permission of the author. All other rights reserved by the author.

Finding the Pattern in AntiPatterns

For this week, I will be discussing about anti-patterns. I chose to talk about anti-patterns because it relates to one of the topics on our course syllabus, and it seems like it would be good for me to connect and refresh concepts learned in the previous blog posts to anti-patterns; for many of the design patterns and software concepts learned are used to prevent anti-patterns.

To supplement my knowledge on this topic, I watched two youtube videos and read one article on anti-patterns. The first video I watched was a very short video about a developer who introduces the concept, anti-patterns. In the video, he connects anti-patterns to code-smells and basically says that code-smells serve to indicate potential/likely problems in your code, which are the anti-patterns. The second video I chose was lengthier and was by the infamous ‘techlead’, where he satirically talks about his favorite anti-patterns he has seen in his work experience. Although satirical, I was able to decipher why anti-patterns are important to catch and also was able to learn some anti-patterns from his talk. The third source, the article served to list more formal definition and examples of anti-patterns. The article referred anti-patterns as “… a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences”. The article also listed examples of anti-patterns that were similar to the ones discussed in the techlead video.

I chose these three sources in that particular order because the intro video helped me better understand the general picture of anti-patterns, whereas the satirical anti-pattern video and the formal anti-pattern article helped to give more depth and understanding of anti-patterns. The satirical anti-pattern video also included real-world examples from an experienced developer which were helpful as well.

From all three sources I was able to consolidate a better understanding of anti-patterns and can see how they connect to previous material learned in my college courses. An important argument that caught me in the techleads videos was the importance of preventing/catching anti-patterns. He explains that antipatterns are dangerous because they are often irreversible and extraordinary hard to refactor once they are embedded into the architecture or code-base, and over time the damage accrues. In addition the anti-pattern article explains that anti-patterns are important to catch early because it may become a bad habit which will repeat itself. Many of the anti-patterns noted both in the anti-pattern video and article, pointed out common code-smells which appeared to be unnecessary-complexity and obscurity; which exemplifies the need for simple and readable code. This is also a common theme noted in the previous blog posts as well. One of the anti-patterns that I can relate to is the over-usage of refactoring, which is explained as bad because it slows-down readability of code during a code-review; yet it is taught extensively in some CS institutions. Overall, this topic made me realize the importance of learning proper usage of software design techniques and concepts in order to prevent anti-patterns in our code.

Sources linked below

https://www.javacodegeeks.com/2011/10/programming-antipatterns.html

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

REST API Design

Hello everyone and welcome to week 14 of the coding journey blog. In this week’s post I will be talking about REST API and it is an important topic when it comes to the web. REST API stands for representational state transfer and the main purpose of is that is is designed to take advantage of existing protocols. REST has the option to be used on practically any protocol, the main advantage it takes is over HTTP which is used for Web APIs. The main benefit for REST API design is that software developers don’t need to use any additional software or make downloads to take advantage of the protocols. It has a lot of versatility as it allows you to build an API that accustoms your vision and as well as the needs of any clients. There are six key constraints to REST API design that people need to be aware of when deciding to use the API and if it fits your needs. These constraints include client-server, stateless, cache, uniform interface, layered system and code on demand.

The constraint on client server revolves around the idea that the client and the server need to be independent of each other and need to be separate. In essence, developers should be able to make changes to their applications without impacting the data structure or the database design of the server. This goes vice-versa as the developer should also be able to make changes to the data structure or database design server without effecting the application for the client. Next constraint is that REST APIs are stateless and so calls should be independent of one another and that it contains enough data required to complete itself with no errors. It should not rely on data that is stored in the server and should do with the data it is provided in the call. Next constraint is that a REST API should be designed to allow the storage of cacheable data. Essentially, the response needs to indicate that the data can be stored up to certain time limit or in real time it should not be cached by the client.

Uniform interface is the next constraint and it should allow independent upgrades of the application without having the application’s services attached to the API layer itself. This is essential to separate client from sever. A layered system, which is another constraint, is a system composed layers as each layers serves a different purpose or function. This design principle is important in most software as different layers of architecture allows an application that is more scalable. The last constraint is code on demand which allows for code to be transmitted through the API to use within the application. It creates an evolving application that doesn’t only depend on the structure of its own code. Overall, REST APIs are important for web projects and I will certainly use them going forward.

For more information on the topic:

https://www.mulesoft.com/resources/api/what-is-rest-api-design#:~:text=REST%20or%20RESTful%20API%20design,when%20used%20for%20Web%20APIs.&text=REST%20API%20Design%20was%20defined,in%20his%202000%20doctorate%20dissertation.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

MongoDB in Five Minutes

This week I wanted to look more into MongoDB. I found an introduction video titled “MongoDB in 5 Minutes with Eliot Horowitz” from MongoDB’s YouTube channel to do so. I wanted to learn more about MongoDB because we have been using it a lot in class, but I do not yet have a clear idea of what it is and how it works. I have already taken a relational database course, so I have a clear mental image of what an SQL database is and how it is organized. I know MongoDB is not a relational database but that is the extent of my knowledge.

They start by describing relational databases as excel sheets on steroids, which is a pretty close comparison. They then use an example of a patient record keeping system for a doctor’s office. A patient information table might need multiple phone numbers and addresses, and these columns would end up being mostly empty in a relational database. We might also have the patient’s information spread over many tables, adding complexity. When this database is used in in application it makes the application inefficient and hard to maintain.

MongoDB uses documents and each document can be different. Not all the documents in this case would have to have the same number of phone numbers or addresses. They don’t need the same number of columns like records in a relational database table.

This video is very short and was also created by MongoDB. It is not surprising that they only show one use case where MongoDB is better than relational databases. If relational databases are Excel then MongoDB is kind of like Microsoft Word. It is important to remember that relational databases enforce things like integrity that MongoDB doesn’t, making it better in certain situations. Using multiple tables also isn’t too much of a problem; that is what joins are for. I can definitely see the advantages of using MongoDB now though. The idea of documents is so simple and it is easy to grasp compared to relational databases. This provides a good start to look more into MongoDB. I may have needed this knowledge for the final project, though we won’t have one anymore. I will definitely be using MongoDB in the future though as it is just becoming more and more popular.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Learning JavaScript

As my interest in learning Javascript grows, I have started to try and strategize how I should go about learning it. I have heard of several JavaScript frameworks, so I was wondering if I should start with one like Angular, Vue, Ember, or something, and in my research I found a blog post by Francois-Xavier P. Darveau with a very telling title: Yes, You Should Learn Vanilla JavaScript Before Fancy JS Frameworks. This is a post which details why Darveau believes that learning vanilla JavaScript is so important. He starts with a short story of his time in college in which he started to learn Node.js for a project and rather than quickly find libraries and do some Stack Overflow style copy/pasting to get the project working, he dove in and tried to do everything himself. Although it was time-consuming and arduous and was not exactly optimal, he had learned far more behind the scenes than he would have otherwise. He emphasizes that learning all the shortcuts from frameworks and libraries without knowing the how’s or why’s is more akin to pretending than real knowledge. He then explains the meaning of vanilla JavaScript, if not inferred before, as “plain JS without any additional libraries.” He notes that, of course, frameworks and libraries can be extremely useful and time-saving, a lack of vanilla JS knowledge can leave one helpless if something goes wrong or the field collectively decides to hop over to the next new best framework. Some framework pros and cons are detailed as well. Pros: abstracting hard code, shipping code faster and increasing development velocity, and focusing on an app’s value instead of its implementation. Cons: When work scales up and apps become more complex or multiple teams are working on multiple apps, there will no doubt be times when a deep JS understanding is needed to get everything to go smoothly. If a vanilla JS foundation is strong, the only thing changing when getting into a new framework will be mainly syntax. The speed at which new useful frameworks come out is faster than one can master them on their own, but with a vanilla JS understanding, you can already be a step ahead. He then provides plenty of resources for how to learn JS and where it can be studied. I found this very useful as I hope to learn much more JS soon. I have just done some work with Node.JS in order to implement a new REST API endpoint and I hope to get down JS as it becomes increasingly prominent in the CS world. I am also doing an independent study related to mathematical modeling and linear algebra using MATLAB in the upcoming semester, so maybe there will be an opportunity there to apply my JS knowledge.

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

What is software architecture design?

I. Concept of system architecture

By Edward Crawley, Bruce Cameron, And Daniel Selva co-authored SYSTEM ARCHITECTURE: Strategy and Product Development for Complex Systems. In the book, the word “system” is defined in this way: a system is a set of entities and their relationships, whose functions are greater than the sum of their respective functions.

In other words, the function has to be 1+1>2, which is called emergence. For example, a pile of bricks and wood cannot provide shelter from the wind and rain, but they can form a warm house. The function of the house is greater than the sum of the functions of the pile of materials, so the house is a system.

Now that you know what a system is, let’s look at what a system architecture does:

1) Determine the form and function of the system. To put it bluntly, it’s analyzing requirements.

2) Determine the entities, forms, and functions of the entities in the system. It’s dividing up the system. To accomplish this task, the book proposes some points of attention: identifying potential entities, focusing on important entities, abstracting entities, and defining the boundaries of the system and the environment in which the system resides.

3) Determine the relationship between entities. This includes identifying relationships between internal entities and entities located at boundaries and defining the form and function of those relationships. That is to define internal and external interfaces.

4) Forecast emergence. The prediction of final function realization, performance realization, and also the prediction of system failure, is the emergence of non-expectations.

II. The book also explains the architect’s function from another perspective:

1) Disambiguation. That is, the architecture is designed so that you don’t have a vague understanding of the requirements.

2) Define the system concept. Put forward the overall solution, define the key terms in the system, define the key measurement criteria.

3) Design decomposition. The key to breaking down the system into entities and the relationships between entities is to control the complexity of the system and not overscale it.

It can be seen that the system architecture is a step between the requirements and the implementation, which not only analyzes the requirements but also proposes a feasible implementation scheme.

The system architecture is suitable for a team composed of one or a few people because many people will lead to insufficient integrity of thinking. If multiple people work together, the best form is also to divide up the hierarchy, with a hierarchy of units to be completed by a single person. This requires a high level of knowledge, synthesis, analysis, and imagination on the part of the architect.

Sources:

Click to access Preface.pdf

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

What is software architecture design?

I. Concept of system architecture

By Edward Crawley, Bruce Cameron, And Daniel Selva co-authored SYSTEM ARCHITECTURE: Strategy and Product Development for Complex Systems. In the book, the word “system” is defined in this way: a system is a set of entities and their relationships, whose functions are greater than the sum of their respective functions.

In other words, the function has to be 1+1>2, which is called emergence. For example, a pile of bricks and wood cannot provide shelter from the wind and rain, but they can form a warm house. The function of the house is greater than the sum of the functions of the pile of materials, so the house is a system.

Now that you know what a system is, let’s look at what a system architecture does:

1) Determine the form and function of the system. To put it bluntly, it’s analyzing requirements.

2) Determine the entities, forms, and functions of the entities in the system. It’s dividing up the system. To accomplish this task, the book proposes some points of attention: identifying potential entities, focusing on important entities, abstracting entities, and defining the boundaries of the system and the environment in which the system resides.

3) Determine the relationship between entities. This includes identifying relationships between internal entities and entities located at boundaries and defining the form and function of those relationships. That is to define internal and external interfaces.

4) Forecast emergence. The prediction of final function realization, performance realization, and also the prediction of system failure, is the emergence of non-expectations.

II. The book also explains the architect’s function from another perspective:

1) Disambiguation. That is, the architecture is designed so that you don’t have a vague understanding of the requirements.

2) Define the system concept. Put forward the overall solution, define the key terms in the system, define the key measurement criteria.

3) Design decomposition. The key to breaking down the system into entities and the relationships between entities is to control the complexity of the system and not overscale it.

It can be seen that the system architecture is a step between the requirements and the implementation, which not only analyzes the requirements but also proposes a feasible implementation scheme.

The system architecture is suitable for a team composed of one or a few people because many people will lead to insufficient integrity of thinking. If multiple people work together, the best form is also to divide up the hierarchy, with a hierarchy of units to be completed by a single person. This requires a high level of knowledge, synthesis, analysis, and imagination on the part of the architect.

Sources:

Click to access Preface.pdf

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

What is software architecture design?

I. Concept of system architecture

By Edward Crawley, Bruce Cameron, And Daniel Selva co-authored SYSTEM ARCHITECTURE: Strategy and Product Development for Complex Systems. In the book, the word “system” is defined in this way: a system is a set of entities and their relationships, whose functions are greater than the sum of their respective functions.

In other words, the function has to be 1+1>2, which is called emergence. For example, a pile of bricks and wood cannot provide shelter from the wind and rain, but they can form a warm house. The function of the house is greater than the sum of the functions of the pile of materials, so the house is a system.

Now that you know what a system is, let’s look at what a system architecture does:

1) Determine the form and function of the system. To put it bluntly, it’s analyzing requirements.

2) Determine the entities, forms, and functions of the entities in the system. It’s dividing up the system. To accomplish this task, the book proposes some points of attention: identifying potential entities, focusing on important entities, abstracting entities, and defining the boundaries of the system and the environment in which the system resides.

3) Determine the relationship between entities. This includes identifying relationships between internal entities and entities located at boundaries and defining the form and function of those relationships. That is to define internal and external interfaces.

4) Forecast emergence. The prediction of final function realization, performance realization, and also the prediction of system failure, is the emergence of non-expectations.

II. The book also explains the architect’s function from another perspective:

1) Disambiguation. That is, the architecture is designed so that you don’t have a vague understanding of the requirements.

2) Define the system concept. Put forward the overall solution, define the key terms in the system, define the key measurement criteria.

3) Design decomposition. The key to breaking down the system into entities and the relationships between entities is to control the complexity of the system and not overscale it.

It can be seen that the system architecture is a step between the requirements and the implementation, which not only analyzes the requirements but also proposes a feasible implementation scheme.

The system architecture is suitable for a team composed of one or a few people because many people will lead to insufficient integrity of thinking. If multiple people work together, the best form is also to divide up the hierarchy, with a hierarchy of units to be completed by a single person. This requires a high level of knowledge, synthesis, analysis, and imagination on the part of the architect.

Sources:

Click to access Preface.pdf

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