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.

For this week’s blog post I have found an article on REST API Design. REST or RESTful API design (Representational State Transfer) is designed to use and take advantage of existing protocols. Even though REST API can be used for almost any protocol, normally you will see this design in HTTP web APIs. This design was defined by Dr. Roy Fielding and became notable due to its layer of flexibility. REST can use and execute multiple types of calls, due to the data not being tied to any methods or resources. For your API to be considered “RESTful”, it will need to follow each of the six key constraints. The first thing that it will need is a Client-Server. This is the idea of separating the client and the server from each other and makes it so work can be done independently from each other. For example, I should be able to work on my server without it effecting the mobile client. Secondly your API will need to be stateless. MuleSoft, the company where the article is from, says on stateless API, “REST APIs are stateless, meaning that calls can be made independently of one another, and each call contains all of the data necessary to complete itself successfully. A REST API should not rely on data being stored on the server or sessions to determine what to do with a call, but rather solely rely on the data that is provided in that call itself.” (MuleSoft). For example, I should be able to grab and orders information from an order database by calling its order ID rather than all the information itself due to the APIs design. The third thing that it will need is cache. Cache in computing, is a piece of hardware or software that will store data for future use. For example, an autofill password you would use on Google Chrome. For your API to be truly RESTful it will need to have a way to store cacheable data. This will strongly help your API due to less interaction with it and you will be able to retrieve data quickly for your clients. The fourth thing you will need a Uniform interface. This means having an interface that is not coupled with the API layer. This allows the client to easily navigate the API without knowing the backend. The fifth concept for RESTful API is a layered system. According to MuleSoft, they say on Layered System, “As the name implies, a layered system is a system comprised of layers, with each layer having a specific functionality and responsibility” (MuleSoft). Lastly you will need to be able to code on demand. The concept for this idea is that Code on Demand will allow code or applets to be transmitted via the API. This concept is not widely used due to API being coded in multiple different languages and has been raising security questions.

https://www.mulesoft.com/resources/api/what-is-rest-api-design

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

This week I took a look at the pattern “Reading List”. According to this pattern, you should keep a list of books that you intend to read. By making a list of the books you have read and the are going to read, you give yourself an easy way to reflect on your own patterns of studying. As you read you will probably come across more books in the references or bibliography sections. You can add those books to your list as well. Your reading list should also be somewhere online and publicly available. Others may benefit from it or you may benefit from their suggestions.

Despite always being assigned at least one book for every CS course I have taken, I have never (at least until now) considered really using a book to learn about programming or computer science. It seems like a no-brainer to use the internet for anything computer related. Modern search engines allow you to ask extremely specific questions and get almost exactly what you are looking for. Maybe this is because as a student I always know what I need to learn.

As the author points out, it is hard to know where you need to go next or what you need to learn next. I am a student, so I always have a professor who provides a curriculum to follow and assignments to complete. I always know what I need to learn. This is all going to change now because I am graduating in a few weeks. I will have to take the initiative to set my own course of study if I want to improve as a programmer. Without any direction I should probably turn to books.

It is probably time I start reading more books about software development, especially if that is the field I am going to go into. Reading the “Apprenticeship Patterns” book has made me realize books do have a lot to offer aspiring programmers. They are a good way of forcing material in front of you. Because books are restricted by their physical form, authors have to put a lot of material in the book to make it worthwhile. You don’t have to figure out what to learn next; books are carefully curated sections of study, at least textbooks are. It’s about time I start my own reading list too, starting with all the books I neglected to read in the past few years.

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

For this week’s blog post, I read the section “Learn How You Fail” from chapter five of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The quote beginning of the section is what stood out to me the most. It says, “Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change.” The section talked about how sooner or later you may face failures but the right thing to do is push forward at the boundaries and learn to overlook the mistakes you have faced. In our field, we face many failures but that is not holding us back to accomplish the goals we have set for ourselves. The author mainly talked about becoming conscious of the things that trip you but allow yourself the choice of working to fix the problems that are cutting the losses.

One of the most important things to do when you face failure is to accept it and investment of time and effort to make a small improvement. Allow yourself some time and the “goal is to gain self-knowledge about the patterns, conditions, habits, and behaviors that lead you to failure.” I liked the example the author provided regarding Ade. Ade keeps a set of private wikis listing all his current skill set and limitations, this enables him to pick challenges to push outwards and to stop wasting effort on the wrong things which can lead to failures. This is a great example of something that I need to do for myself. Especially keeping a diary or a blog is helpful as I mentioned in the previous blog post that talked about the “Record What You Learn” apprenticeship pattern. This pattern was very true to me. Leaning from failures is important and you cannot excel at everything but accepting these limitations and learning from the failures or mistakes forces you to acknowledge them and focus on improving them so you do not make the same mistakes again.

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

This apprenticeship pattern might be one of the most important ones in the book because it is something that can be applied to any aspect of life, especially for software development. You need to practice your craft and work on improving it by practicing it each and every day or at least the times when you can in an environment without interruptions or deadlines to help you focus. Software architects need to make mistakes to learn and they need to practice in order to learn. The mindset for this type of approach is to always be ready to perform and be as prepared as you can. If you don’t take action on what you need to know, then you will just be stagnant and stuck in the same place. The pattern doesn’t only talk about practice to improve, but talks about practicing in the best way. You need to try and practice in the best way possible by getting periodic feedback or getting more analysis on your mistakes. Practice will be come permanent in the wrong if you don’t constantly focus on way to improve the way you practice to learn in a more efficient way. This is why it says to practice in a relaxed environment so when you make mistakes you are comfortable with making mistakes and not burdened by it.

I think the biggest takeaway and thing I would add to this pattern is that the only way to learn is by doing and not focusing immensely on theoretical. Anyone can learn the theoretic aspect of software in a short period of time, but there takes more effort and practice to learn the practical aspect since you learn by doing. If someone were to learn all the rules and basics of a sport, but not practice actually playing the sport, then they will not be good at the sport. This is very similar to developing software, since you need to learn the theoretical aspect, but in order to be good you need to keep on practicing and learning. It is essential to always be prepared and up to date with how to learn and the most efficient way to learn a specific software. Overall, the end goal is improvement and to learn to adapt and adjust as time goes on for the most out of your software journey.

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.

The section “Familiar Tools”, found in chapter six in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye focuses on the tools a craftsman uses. Focusing and familiarizing oneself with a particular set of tools will help increase productivity since there won’t be any need to go over the functions or specifics of said tools. This also allows one to more accurately know how long a task will take using these sets of tools. However, overreliance on one set is discouraged as there will likely be other tools that are either better suited to a particular task or are an outright upgrade. There are also situations where one will have to either choose your familiar tools and personal efficiency or less familiar tools and the overall team’s efficiency. Regardless, familiar toolsets will become obsolete and have to be replaced over the course of a software developer’s career.

The concept of having to swap familiar toolsets overtime is something I’m experiencing in real time despite my relatively small experience. For example, the first program that I used to develop and edit code in was BlueJ. It’s a fairly simple IDE that focuses entirely on the Java language and is mainly used for educational purposes. I got comfortable with it pretty quickly but then I had to learn C language which lead me to switch to Code::Blocks if I’m remembering correctly. The IDE I’ve been using for over a year now is IntelliJ which I mainly use to code in Java. I used all these different IDEs over the course of around three to four years and in the case where IntelliJ becomes obsolete or I need to code in a different language, like Python for example, I’d have to change IDEs again. This process is going to repeat again and again for as long as I use IDEs; though it doesn’t mean that I lose out sticking with one IDE for a period of time. Like the book states, I’ll be saving a significant amount of time coding in Java since I’m already familiar with IntelliJ and I’ll also have a frame of reference when estimating how long a task will take to get done.

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

            The learning pattern “Record What You Learn” from the Apprenticeship Patterns book is mostly self-explanatory from the title. The main concern of someone who gains a lot of knowledge quickly, such as a new software developer, or, in my case, a software development student, is retaining that knowledge. The chapter describes some good ways to track this learning, like with a wiki or a blog (hey!). Having to relearn or continuously practice concepts or bits of skill is time consuming and wasteful, especially if you don’t have something to quickly reference. This is a solution to that problem.

            Recording and retaining my learning has definitely been a problem in the past, although I’m trying to get better at it. At the start of my sophomore year, I realized I had forgotten a solid chunk of the programming skills that I had learned at the end of my freshman year. I had to work a lot over that summer, so I didn’t have a ton of time to practice these skills through personal projects or places like LeetCode. Getting back into the swing of things, especially as difficulty was ramping up, was a struggle. Luckily, I haven’t hit a patch like that since, but there have been plenty of times that I found smaller, but still useful concepts, escaping me.

            Some things in this department might be like remembering some concepts, but forgetting the implementation, or even just one key part of implementation. This is exactly where a wiki/blog would be super useful. I find I usually follow my own train of thought best, as I assume is the same for everyone, so having something to reference in my own writing, in a way that I find is useful in understanding a topic, is best as well. Just in recent memory, I had some trouble trying to remember how to create a custom comparator for two objects. I had just done it last week, at which point I had to look it up. It was excusable the first time, but just a pain the second time. So, even after a week, I still face these troubles. I definitely need to get better as recording my learning, so this learning pattern is a great point of emphasis for me.

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.