Hello, blog (mood-status: relax and focus), writing this blog after coming home from a work trip and finishing it the last week of classes, studying on exams, and submitting assignments. But anyway, on writing about this week-13. I am writing this as my final blog for the year 2021. I decided to go on the Syllabus once again to look at the course topics. Then I choose the subject of the Framework.

A framework is a platform that provides a foundation for developing software applications. It uses shared resources (libraries, image files, and reference documents) puts them together in one package. The resources can modify that package to suit the project’s specific needs. With a framework, the developer can add or replace features to give new functionality to the application. A working program that Framework can selectively modify by adding code.

What are the different types of frameworks?

The programming languages that many frameworks available from each use to solve different problems that come up in software development for Many industries can use it.

Back-End Web Frameworks

Back-end web frameworks are the multiple used programming frameworks. Web frameworks help developers in making web applications and active websites. These frameworks completely changed how web development is done, speeding up the entire software development process by automating everyday tasks for web developers, like providing database access, session management, and page templates. Instead of building websites using HTML, JavaScript, and CSS, back-end frameworks use programming languages to interact with a database to generate content. The work is hosted on a server, consequently the back-end portion.

Front-End Frameworks

Back-end frameworks are loaded on a server and executed in a user’s browser. It allows web developers to design what the users see on the website, manage requests, define file structures, and style its components. As Framework, It gives web developers a base to develop while controlling the final output. 

Why should you use a framework?

Frameworks help reduce time wasted in developing software. It provides a general working system that the user set for a specific application by extending the code. All the lower-level details have been added already. Frameworks allow the developer to save more time to write code specific to the project, not dealing with the Framework’s workaday, redundant functions. Also, It made the code clean and easily adjustable by following the coding convention of the Framework. Finally, frameworks help develop the project quickly, reducing programming time and costs.

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: relax and focus), writing this blog after coming home from a work trip and finishing it the last week of classes, studying on exams, and submitting assignments. But anyway, on writing about this week-13. I am writing this as my final blog for the year 2021. I decided to go on the Syllabus once again to look at the course topics. Then I choose the subject of the Framework.

A framework is a platform that provides a foundation for developing software applications. It uses shared resources (libraries, image files, and reference documents) puts them together in one package. The resources can modify that package to suit the project’s specific needs. With a framework, the developer can add or replace features to give new functionality to the application. A working program that Framework can selectively modify by adding code.

What are the different types of frameworks?

The programming languages that many frameworks available from each use to solve different problems that come up in software development for Many industries can use it.

Back-End Web Frameworks

Back-end web frameworks are the multiple used programming frameworks. Web frameworks help developers in making web applications and active websites. These frameworks completely changed how web development is done, speeding up the entire software development process by automating everyday tasks for web developers, like providing database access, session management, and page templates. Instead of building websites using HTML, JavaScript, and CSS, back-end frameworks use programming languages to interact with a database to generate content. The work is hosted on a server, consequently the back-end portion.

Front-End Frameworks

Back-end frameworks are loaded on a server and executed in a user’s browser. It allows web developers to design what the users see on the website, manage requests, define file structures, and style its components. As Framework, It gives web developers a base to develop while controlling the final output. 

Why should you use a framework?

Frameworks help reduce time wasted in developing software. It provides a general working system that the user set for a specific application by extending the code. All the lower-level details have been added already. Frameworks allow the developer to save more time to write code specific to the project, not dealing with the Framework’s workaday, redundant functions. Also, It made the code clean and easily adjustable by following the coding convention of the Framework. Finally, frameworks help develop the project quickly, reducing programming time and costs.

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.

Christian Shadis

Over the past month, my Software Construction, Architecture, and Design course has shifted gears into a sort of crash-course for full-stack web development, as I mentioned in the last blog post. We have focused primarily on the backend, creating RESTapi endpoints in the api.yaml file, along with implementing those endpoints in Javascript. In the final two weeks of class, we are transitioning into implementing a front end using Vue.js. In the process of switching contexts, my understanding of the difference between a frontend and backend became a bit obfuscated.

In Frontend vs Backend, Maximilian Schwarzmüller first declares that the common refrain that each web app is built from a frontend and a backend. He then begins to describe the differences between them. In short, the difference between the frontend and backend of a web app is that the frontend refers to the content displayed in the browser, while the backend refers to the portion of the program which runs on a server. He gives the helpful example of Amazon – it consists of a frontend (the catalog, shopping cart, and other visual elements of the webpage) and a backend (all data/database management). He is careful to specify that the difference does not lie only in where data is stored, because there are non-database aspects of a backend as well, such as file system interaction or input validation. He also lists several skills and programming languages that a programmer may need in order to build the frontend (HTML, CSS,  Javascript, Vue.js / React.js / Angular) and the backend (Node.js, PHP, Python).

One area of confusion for me was understanding exactly how the frontend and backend communicated with each other – via HTTP requests. We had discussed and implemented HTTP requests in class, but I thought the communication occurring was between the backend and the database. In fact, the user performs some action on the frontend, resulting in an HTTP request being sent to the backend (and by extension, the database).

Knowing how to code both the frontend and backend of a web app is vital to become a web developer, but it is also important to be able to differentiate between them, and to understand why they are considered separate components of an app. I plan to work on developing the full stack of a web application from scratch, and the information from this article will enable me to begin development with a stronger understanding of how to build the frontend and backend properly to communicate with each other.

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

Throughout the last couple of weeks, we have been working with MongoDB in our exploration of web application development. After hours of scrolling through MongoDB documentation to figure out how to do assignments and learning about how to use this particular service, I thought it would be important to learn a little bit more about NoSQL databases and why they are being used more and more frequently in software development circles. To this end, I found an article by MongoDB about NoSQL databases and thought it would be the perfect introduction to the topic.

The article starts with a basic explanation of the differences between relational databases and NoSQL, that it stores information in a non-relational format, thus providing more flexibility with schemas, faster query times, ease of use, and horizontal scaling that is not present in traditional database design. It then goes into the different types of NoSQL databases, those being document, key-value, wide column, and graph databases, giving brief explanations of those. MongoDB is a document database, holding all information in a JSON format. The article goes deeper into the differences between NoSQL and relational databases, showing an example of the two. In general, the main reason to use NoSQL databases, in my opinion, is the flexibility they have. There is no need to split up data that has no reason to be split up. All data for a single object can be stored within that object, without having to relate it to a completely different table. It takes out a lot of unnecessary complexity within the schema and to that end can speed up the time it takes to access data. The article then clears up misconceptions about NoSQL databases and provides a tutorial example on how they can be used.

After reading about the differences, and having worked with both SQL databases and MongoDB, I much prefer the flexibility of NoSQL database design over that of SQL, and the performance increase is an added bonus as well. I don’t know why anyone would stick with a slower, more rigid database structure unless their application absolutely needed it. Not to mention the fact that SQL has always had issues, and is far more vulnerable to security risks (thinking about SQL injection, which doesn’t seem like it would be as much of a problem here). This gave me a lot more appreciation for the usefulness of a NoSQL database design as a whole and aided in my understanding of what they are. In the future, unless I have to, I would much prefer to work with a NoSQL database over a relational one, and given the trends of web app development, I think a lot of others are thinking the same thing.

Source: https://www.mongodb.com/nosql-explained

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

With front-end development being one of the last topics we cover for this semester, I decided to take a deeper look into things that can be built using the frameworks we’ve utilized. Vue.js for example is a framework that can be used to develop a front-end application. One type of front-end application that many of us are very familiar with is a Single Page Application(SPA). An SPA is an application that displays all of its information, well, on a single page. It sounds like a lot but only the requested and necessary information is usually displayed on the page at one time. 

For example, most email service providers have been developed using SPA styled programming. If you’re like me, you have a ton of unread emails that you are just too lazy to go through and delete. All of these messages can span over the course of a few “pages”. As you click through the pages, you can see how quickly the response is while sifting through them. Although this design gives you the impression that you are navigating through many different pages, the browser is just updating the very same page that you navigated to.

While some of this implementation is back-end stuff, Vue can help make this possible with the use of components, that’s all it really is. Instead of having to use hundreds of unmaintainable lines of javascript to add functionality to an application, Vue makes it really simple and easy to maintain your code with Don’t Repeat Yourself (DRY) standards. It starts with a root component to get the Vue framework into your code. From there everything else is just a series of components to get everything working. 

Components come in two different flavors. Global components, as the name might suggest, are registered and usable everywhere within the application. Local components are only usable wherever they are registered. To register a component as global you would need to use the Vue.component method. Registering a component locally would require that you make it a part of the “props” of an element. Figuring out when to use a component globally or locally calls for careful consideration when making your application. 

There are other great front-end developing frameworks like React.js and Angular.js. Along with Vue, these three are very popular in terms of leading frameworks that developers like to use in the present day.

My sources I used for this post:

https://vuejs.org/v2/guide/components.html

Understand VueJS in 5 minutes

Global & Local Components

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

As time goes on and I have learned more about JavaScript and its use in the back-end and front-end. I have found many surprises about JavaScript compared to other programming languages. The more I interact with it, the deeper I get to know the language and the framework inside. This article is to point out some of the odds about JavaScript.
Semicolon (;)
Java requires a semicolon at the end of every single statement, in case we don’t put a semicolon at the end the compiler would give us errors. Unlike Java, JavaScript does not have a compiler hence if we, unfortunately, missed out on semicolon, there’s not going to be any warning, but it might result in breaking our code or it would simply refuse to work. That is because of JavaScript’s automatic semicolon insertion rule. The rule states that a valid program ends with a (;) if it does not end with a (;) then JavaScript will automatically insert a (;). Therefore, it will not ask us to insert a semicolon.
Strict Equality (===)
Java has two types of Equality; one is single equality (=) means it’s used for numbers and the other is double equality (==) which is used for String. Move on to JavaScript, it has 3 types of equality. Two are similar to Java but there is also another one, it’s called Strict Equality (===). The Strict Equality checks if the data types are the same and if it is not, it returns false. Complicated, isn’t it?
Let and Const
It would be best not to use “var” to declare variable because it is not block-scoped and allows for mutation. Being block-scoped means a variable does not pass its boundaries, unlike var that does not respect borders. Professional users advise newbies to use “let” or “const” to declare the variable. Usually, developers would use “let” unless they don’t want that variable to change then they would use “const”. On the other hand, Java gives users a variety of variable declarations such as int (Integer), String, double (2.9), or boolean (true or false). So, simple but not simple at all.
Fixing Errors
About fixing errors, since JavaScript does not have a compiler, therefore, it’s harder to fix errors unless we type something that is absolutely not making any sense. The only way to fix the error is to run the code on localhost and figure it out from there. However there’s a fix for that, it’s ESLint. This extension uses command lines to tell us where the problem lies but also could fix the errors if we run.
Now we have learned some JavaScript quirks and there are many more that we should spend more time to look. But JavaScript still dominates the market despite all things above and is one of the most popular languages in 2021 and undoubtedly 2022. So, deal with it.

https://rofiatolusanya.medium.com/javascript-quirks-84d2d8ac4f41

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

DRY and YAGNI are two acronyms used to describe best practices when it comes to coding. DRY stands for “Don’t Repeat Yourself” while YAGNI stands for “You Ain’t Gonna Need It”. These two acronyms or best practices complement each other very well. They both aim to make code cleaner, simpler, and free of coding smells such as needless complexity and needless repetitions. These are coding smells that every developer should avoid. So, what do they actually mean?

DRY or “Don’t Repeat Yourself”, is a best practice revolving around repetition in code. When it comes to code, quality is always better than quantity. Why have hundreds of lines of code when you could have a dozen lines that do the same thing? Having duplicated code or duplicated logic is a waste. Not only will you waste time and effort, in the beginning, adding the unnecessary code, but you will also waste further time and effort maintaining and extending the code in the future. Repetition in code can be caused by a variety of reasons mostly from either poor programming habits, like copy and pasting code without really understanding how it works, or from a poor understanding of coding knowledge in general, but specifically, a poor understanding of encapsulation. Regardless of the cause, needless repetition should be avoided as much as possible and repetitive code should be eliminated by refactoring wherever possible.

YAGNI is an acronym that stands for “You Ain’t Gonna Need It”. YAGNI is a coding best practice that stems from the principles of Extreme Programming or XP. YAGNI revolves around the idea of avoiding the writing of unnecessary code that is based on foresight rather than need. Martin Fowler describes YAGNI as “a statement that some capability we presume our software needs in the future should not be built now because “you aren’t gonna need it”. In other words, software developers should always implement features when they need them and never when they just foresee the need for them. There are several reasons why YAGNI exists. One very good reason is that it maximizes the amount of unnecessary work that is left undone. This is excellent because it improves the productivity of software developers, and it maintains the simplicity of products. Simplicity is especially important because implementing new features is quite expensive. It takes a significant amount of time, money, and resources to add the features and to maintain them. Features that are not necessary can be very costly. To avoid wasting resources on unnecessary features, apply the YAGNI principle and don’t implement features unless you need them now.

https://deviq.com/principles/yagni

https://deviq.com/principles/dont-repeat-yourself

https://martinfowler.com/bliki/Yagni.html

From the blog CS@Worcester – Fadi Akram by Fadi Akram and used with permission of the author. All other rights reserved by the author.

               Within the modern world of computing, the creation of intuitive front-end systems is essential in the pursuit of user friendliness. Front Ends are what make a program, or website accessible to most people. Databases use front-ends to allow users to search or browse their contents in a format that is easily accessible and usually provides tools related to searching said database. Complex programs can utilize front ends to abstract the complex inner workings of said program and boil them down to a simple screen that guides the user and tells them what to do.

               With this in mind, it is important to consider that a front end must also be clear in its design. A well thought out front end will make it even easier for a user to understand what the front is created to accomplish. Oftentimes these types of jobs are handled by dedicated designers, especially since languages such as CSS, HTML and Javascript, while in a basic sense are similar to writing code in C++, or Java, however they usually have much less depth to them as these front end languages usually serve only to request data from the backend and return a response.

               What we have here then is a classic situation of design philosophies vs engineering philosophies. One seeking to appeal to as many people as possible and the other focusing on functionality first and foremost. Often design and practicality can be at odds with each other as some designs might be impractical or vice versa with some engineering decisions being unappealing. This is where one who works in front-end development can bridge the gap between the two philosophies.

To that end we can look at a website such as Thea Food Pantry which was shown in recent activities pertaining to front end design and implementation. It is a simple program but does its job well while offering a fairly user friendly experience. A list of items and a button with a prompt next to it to allow a user to add items. The page is easy to read but is functionally sound.

               When designing software, there are two goals in mind when a user visits your site. It must be appealing and easy to navigate as well as quick to guide potential customers to a desired product. To be an effective front end designer, it is imperative to understand how to structure the website to be both practical for seamless backend integration and visually appealing to the user in a way that emphasizes what is most important to them. The breadth of knowledge afforded by understanding front end design and implementation gives an important viewpoint for software development and how the average user might view your web application.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Resource Link: https://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design#single-responsibility-principle

For this blog post, I wanted to delve into what the SOLID principles are and how they apply to object oriented programming. SOLID is an acronym for the 5 object oriented design principles. They are the single-responsibility principle, the open-closed principle, the Liskov substitution principle, the interface segregation principle, and the dependency inversion principle. The reason these principles are important, and why they’re important to use is that they help to maintain good coding practices and help to avoid code smells. This is essential in large projects, as code smells and bad design could increase development time, make refactoring harder, and make development harder for teams if other team members couldn’t understand the code.

The first principle of SOLID is the Single-Responsibility Principle. It states that a class should have only one reason to change, and that it should have only one job. This means that a class should only have code related to its function, and not extraneous code that should be elsewhere that’s unrelated to the class’s intended purpose. This helps to keep classes simple and easy to understand. If a class contained logic unrelated to its purpose, then it would make the intended purpose of the class confusing.

The second principle of SOLID is the Open-Closed Principle. It states that a class should be open for extension but closed for modification. This means that a class should be designed in such a way that if a modification to that class is needed, it can instead be extended by a different class, and then that class could be modified while maintain the functionality of the original class. The also helps the make each class have its own specific purpose. If instead of creating a new class, a single class was modified every time a modification was needed, then the class would get messy very fast, making it hard to read and hard to understand its functionality.

Next, the Liskov Substitution principle states that every subclass that extends another class should be substitutable for the parent class. This means that for example, if there was a shape class, and then a square class extended the shape class, then the square class should be able to be used in place of the shape class.

Then, the Interface Segregation Principle states that classes shouldn’t be forced to use an interface which has functionality that it has no use for. This means that if an interface has some functionality that doesn’t apply to everything, then a class shouldn’t use that interface if it won’t be using that functionality. Instead, interfaces should be very broad, making them applicable for many different purposes.

Finally, the Dependency Inversion Principle states that functionality should depend upon abstractions, not concrete methods. This means that if you have a class that must perform some functionality, and it shouldn’t depend on an exact implementation, then the class must be design in such a way that it applies to all implementations, based off abstractions.

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