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.

Resource Link: http://www.kamilgrzybek.com/design/grasp-explained/

For this blog post I wanted to explore the GRASP principles. GRASP is an acronym for 9 principles that apply to object oriented design in programming, and it stands for General Responsibility Assignment Software Patterns. The 9 principles are: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Indirection, Polymorphism, Pure Fabrication, and Protected Variations.

First, the Information Expert principle states that an object should have all the functionality and logic that pertains to it. For example, if a class has a list of objects, then it should also have all the logic for functions that pertain to that list, such as adding items, removing items, etc.

 Next, the Creator principle states that an object should be created within the scope where it’s used. This means that if a certain class A relies on another class B to function, and B is unique to A, then B should be created within class A.

Next, the Controller principle states that the first object behind the front end UI layer should control the backend operations. This helps to separate the front end functionality from the backend functionality.

Next, the Low Coupling principle states that objects should be designed in such a way to where they can be isolated and reused without changing many other components. This helps to avoid rewriting code that could be useful in multiple places, instead making it generic so that it can fit into many different applications.

Next, the High Cohesion principle states that objects should only contain data and functionality that pertains to their function. This helps to avoid overloading a class with extraneous information and logic that isn’t necessary and should be abstracted or put into another class.

Next, the Indirection principle states that instead of directly coupling two objects, an intermediary object should be used between the two to handle the coupling. This helps to avoid a direct dependence relationship between two objects, instead having them both rely on an in between class that handles the relationship, so that change can be localized to that one class.

Next, the Polymorphism principle states that objects should be generalized so that they can handle support for different object types. For example, an animal class would have functions that pertain to all animals, and then subclasses could have functions that are more specific to certain kinds of animals.

Next, the Pure Fabrication principle states that shared functionality between classes should be placed within a separate class rather than in a class that it only roughly fits into. This helps to abstract functionality that could be repeated among many classes, instead putting it into a single shared class.

Finally, the Protected Variations principle states that systems that are likely to change should be protected as to not affected other systems. This helps to avoid breaking systems that other systems rely on, instead making sure that systems which other systems have a dependence on are protected and not susceptible to change.

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

Front end and back end development get thrown around a lot, but I never really understood the difference. Therefore, I decided to do some research and figure out what front end development and back end development are, and what the difference between them is.

Let’s start with front end development. Front end development, also known client side development, deals with the user interface. The user interface, or UI for short, is what the user gets to see and interact with. Front end developers are responsible for designing and creating the user experience elements in a program. Front end developers may find themselves using technologies like Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript to implement features such as buttons, menus, pages, and so on. The goal of front end development is to create attractive, simple, and easy to follow interfaces for users. However, achieving this goal can get quite complicated due to a major challenge. This major challenge is the sheer amount of variance in devices. Not all devices are the same. There are devices that are big and small, fast and slow, and new and old. Guaranteeing a consistent experience across all devices and platforms is a very difficult task but is an essential one. This gets further complicated with the rapidly evolving technologies, standards, and practices.

Now, back end development, as you might have guessed is the complement of the front end development. If front end development deals with things that the user can’t see then back end development deals with things that a user cannot see. Back end development, also known as server side development, deals with servers that provide data on request, the applications which channel those requests, and the databases which organize the information. Back end developers might find themselves using databases such as IBM DB2, MySQL, and NoSQL as well as a bunch of programming languages and frameworks such as Java, Python, and C++. The goal of back end development is to design and create applications that can accurately locate and deliver data to the front end as smoothly as possible.

While developers usually just specialize in either front end development or back end development, sometimes employers need developers who are proficient on both ends. This is known as full stack development, and these highly specialized developers are known as full stack developers. Their job is to use their deep knowledge to suggest ways to make the development process more efficient.

https://www.conceptatech.com/blog/difference-front-end-back-end-development

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

In class, we’ve been using vue.js. Vue.js seems to have many similarities to React, so I thought it would be informative to briefly discuss how to implement React components. Vue.js seems to also use components, so I thought it would be helpful to explain a common concept that seems to exist between the two.

I open visual studio code, and open the terminal. To create a react app, I typed the following commands:

• npx create-react-app reactapp
• cd reactapp
• npm start

After React finished installing, I changed my App.js to this:

This component’s render() function will display the content on the webpage using JSX¹. There is currently nothing but an empty screen. Instead of writing everything inside a component, we should segregate the information into separate components, that would then be called in this central component.

For this example, we’ll create a webpage with four parts: a header, a navbar, a side pane, and a main pane. Each component will contain its own js file. Since we’re making a very simple web page, the header will be a simply designed bar. I created a blue bar in Paint, and I imported it using CSS. The header will contain a title, and compose the top of the web page.

Below the header should be the navigation bar. For the sake of example, the navbar here will just display the formatted text on it. The navbar would in practice function as a transition between web pages.

Next is the side pane. This side component on a website could function as a way to automate section traversal, as is done on a wikipedia page. If the main section has a title such as “Lorem Ipsum”, it would list “Lorem Ipsum” with the ability for a user to highlight and click on it. Like the navbar, we’ll only create a very simple display.

The final component is the main component. This component will be where we put our text. I created a title called “Lorem Ipsum”, with some body text.

We now need to add our components into our previous App.js file. The top will contain the header and the navbar, and the body will contain the side pane and the main pane.

Finally, we need to create the CSS. For my design, I am using this inside of the App.css file, which is then imported into App.js.

For our product, we get this (the bottom part was cut in the screenshot for space):

While it’s not winning any awards, it’s a draft of a simple website design. This illustrates how components work together, in a library like React, and I hope this helps with understanding vue.js too.

Link:

1. https://www.youtube.com/watch?v=w7ejDZ8SWv8 (For discussing how components and JSX work, so I could make this guide!)
2. https://reactjs.org/tutorial/tutorial.html (ditto)

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