Category Archives: Week 4

          YAGNI

YAGNI has two different meanings: You Ain’t Gonna Need It or in other words, You Aren’t Gonna Need It. YAGNI has appeared differently as the main principle that has been used in the extreme program. This principle stated in a different interpretation is:

“Always implement things when you really need them, never when you just anticipate that you might need them.”

The reasons why this principle exists are various. As a start, it makes it possible to maximize the amount of unnecessary work that remains unfinished. This is a very good way to improve the productivity of the developer, but also the simplicity of the product. One thing to keep in mind, these features are very expensive, both for development and maintenance. It is also important for users, so that they have the opportunity to learn, but also to navigate around. But those features seemingly are not necessary, in fact, they are a very large source of waste.

 Yagni Advantages

Here are some reasons why YAGNI should be used:

-Save time in the same amount of money (saving time and money is equal), and this is the main factor but also the most important

-gives you the opportunity to use a much easier code, good but most importantly “thoughtless”

-makes available the deadlines

-ensures that the client is happy with the very frequent but also obvious changes that are in line with the specifications

-code has better quality, notice this from the fact that many developers focus on just one even smaller task they may be doing (tasks which are more important at the moment)

last but not least, that code has the property to be more extensible.

Yagni design principle

We will not need this program much. Extreme Programming (XP) says that a programmer should not add the functionality he has until it is considered necessary. So YAGNI translates differently – You will not need it. Extreme software is generally used in the Agile software development process. According to this principle, we should not add any functionality until the moment when it is deemed necessary, in other words, to write the code which we need in the current situation.

YAGNI in Agile/XP

Many people may remember that this principle is called “stupid” and that the requirements it has should be prepared even better. But those people who work in the slightly more advanced methodology or, as they say, “agile” should take into account the possible changes that the client’s requirements may have. For this reason, the subsequent tasks in most cases depend on the results of the current status of this project, but that over time this result may change.

If at the same time we develop many features that “maybe needed” as a start, we lose not only the time but also the effort that has been needed to complete it. There are also cases when we waste the time we spend refactoring or fixing them as these interventions may be redundant.

In general, developers should never rely on different assumptions because they are likely to prove that they are not worthy and capable of the effort and time a programmer needs.

Refereces:

https://www.plutora.com/blog/you-aint-gonna-need-it-yagni

https://jasonmccreary.me/articles/practicing-yagni/

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

Improve Your Code with Design Patterns

This week, I wanted to learn more about the design patterns we discussed in class. After completing the homework, I saw how each of the design patterns we had used could be stacked on top of each other to make more efficient programs and find solutions to common programming problems. So naturally, I decided to seek out a comprehensive list of the Gang of Four design patterns to learn more about them. While looking into this, I found a blog post by Madhura Oak entitled Design Patterns – Revisiting Gang of Four that seemed to fit the bill.

In this post, Oak explains how the “Gang of Four” came up with a list of design patterns that solve common issues within programming, and laid out these patterns so they could be used in any language, and could help software designers write maintainable and easily readable code. In this, he explains the SOLID principles by Robert Martin, and uses these 5 design principles to help explain the usefulness of each pattern. The author also breaks down the 23 Gang of Four design patterns into categories depending on how they are used and gives examples of their use, which helps put into context why we would use these patterns in the first place.

After reading about all 23 of the design patterns, and having used both the singleton and factory patterns in the homework, I feel like I have a far deeper understanding of how these patterns can be used to create more efficient and readable code. They provide a framework for so many different types of abstraction, showing ways to structure your class hierarchies to improve your ability to modify, extend, and test code without having to slog through massive classes that are full of specific use-case scenarios. Using encapsulation and inheritance in the way they are used in these design patterns, code can become so much easier to document, test, and build upon. It becomes so much cleaner and more readable.

So far in class, we have only looked at what Oak classified as “creational” design patterns, as they mainly have to do with the creation and encapsulation of objects. However both “behavioral” and “structural” design patterns are also listed here, to help bring the same principles to the structure and behavior of the programs. Mixing these together within the full structure of a project would provide great benefit to the maintainability of code in the future, one of the most important parts of software design.

Overall, this blog post was a good introduction to design patterns and the principles that they help to achieve. In the future, I hope to use these patterns to help design code that is far more abstracted, and hopefully far easier to follow than code I’ve written in the past. I really like how easily followed the patterns are, and the way the post is organized makes it easy to find what you are looking for. If you are interested in further reading about more design patterns, I would highly recommend looking through this post, at least for a general outline of what they do and how they work.

Source:

https://madhuraoakblog.wordpress.com/2017/03/01/design-patterns-revisiting-gang-of-four/

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.

Self-Directed Professional Development Post #4

For this week’s blog post, I’ve decided to watch a video titled, “Object Oriented Design Tutorial: Creating a UML Design from Scratch” by Derek Banas. The reason I picked this video is because 1. it directly relates to one of our course topics, “Modeling: Unified Modeling Language (UML)” and 2. because it teaches a methodical process to creating UML diagrams. This video is actually part of a series titled, “Object Oriented Design” and in the next video Derek shows how to create code from the UML design he’s created. Since I will likely be making more UML diagrams in my educational/professional life, I figured it would be good to further develop this skill.

One of the first things Derek mentions in this video is that he will be showing both the analysis and design stages for this process. The program that Derek is tasked to create for this video is a coin flipping program for two individuals. One player selects heads or tails, the other player gets assigned the other coin side, and the winner and loser is selected. Derek starts this process with something called a Use Case Description. For this description, Derek has a basic text editor open with the following categories: description, triggers, actors, preconditions, goals, not available, and steps of execution. Derek goes through each of these categories and writes in the relevant information for the program he needs to create:

  1. The description describes what happens in the program.
  2. Triggers mention how the program/game starts.
  3. Actors include the two players, the coin, and coin game.  
  4. Preconditions lists the things that need to be true for this program to run (i.e. 2 players are available, a coin is available).
  5. Goals list the outcome of the program (i.e. one player wins and the other loses).
  6. Not available references potential invalid inputs and extensions on how to make the program better in the future.
  7. Steps of execution describes what the program will do in a numbered list (each number represents a specific task).

Although this was only one part of the 30 minute tutorial, this was still an extremely useful process for me to observe Derek do. I learned how important it is to critically think about what you want your program to do before you jump into programming. I am definitely guilty of trying to jump into coding sometimes but I can see how cleaner and clearer code can be written by thinking and mapping things out in advance.

The thing I’m happiest about from this blog entry is finding this series and Derek’s YouTube channel. He has multiple tutorials on his channel that I can see myself learning a lot from. His videos are educational and thorough (many of them are 20-30 minutes long). As I continue growing as a programmer, I will definitely be referencing him to learn more useful information, techniques, and procedures.

Tutorial link: https://www.youtube.com/watch?v=fJW65Wo7IHI&list=PLGLfVvz_LVvS5P7khyR4xDp7T9lCk9PgE&index=3

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

Path Testing

For the fourth assignment in the Software Quality Assur&Test class we had to create a program graphs and a DD-Path graph. We had worked during class time in different activities that covered this assignment so I would say I really enjoyed working in this assignment. We had to complete three parts each with a different level of difficulty, but I did only basic and intermediate. I learned to understand more of the way how to create the graphs and what you need to place in the graph and what not.

We have given a java code and I have to create the Program Graph for the play () method. In a Graph, we have a set of nodes (a.k.a vertices) and these nodes relate to each other with the help of some edges. The nodes or vertices are used to store data and this data can be used further. To build the graph is easy but complicated at the same time. All the 27 lines of the code are represented with 27 nodes and some of the nodes have more than one line.

A graph is a data structure that consists of the following two components: 
1. A finite set of vertices also called as nodes. 
2. A finite set of ordered pair of the form (u, v) called as edge. In a Connected Graph, from each node, there is a path to all the other nodes i.e., from each node, you can access all the other nodes of the graph. But in a Disconnected Graph, you can’t access all the nodes from a particular node. Our graph is a combined one.

After finishing the graph, I had to Create the DD-Path Graph for the play () method given above and include the table translating from Program Graph nodes (from your graph above), with the corresponding DD-Path node labeled with a letter. The most difficult part is done in the first part so creating the DD-path and the table it didn’t took me a long time to translate it to what was required. Overall, it was fun assignment and I really enjoyed.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Concrete Skills

For this week I choose to talk about the concrete skills pattern. I want to start it with a question that made an impression in me when I was reading it. The concrete skills you possess are your answer to the question: “If we hire you today, what can you do on Monday morning that will benefit us?” The point is that you will often require hiring managers to take a leap of faith in choosing you. Concrete skills (which are ideally discrete enough that you can bring toy implementations to an interview) allow you to meet them halfway.

Having knowledge is not the same as having the skill and practical ability to apply that knowledge. I believe that because I feel the pressure of it in the software class that I’m right now. Me and my classmates are working in a project that require from us to learn some new tools that we need to use. In the first month of it most of time I have read a lot about these tools and how they work but I cannot compare it with the knowledge that I will learn when I start to apply it. I always tell myself that practicing makes you perfect. That’s how you earn a concrete skill.

If you are not sure what concrete skills, you need in the book there is a suggestion for it. Collect the CVs of people whose skills you respect. You can either ask them for a copy or download the CVs from their websites. For each person, identify five discrete skills noted on the CV, and determine which of these skills would be immediately useful on the kind of team you want to join. Put together a plan and a toy project that will demonstrate that you have acquired these skills. Implement the plan. It is a good advice.

The last thing that I want to add is that is important to not get lost in the sea of knowledge. I speak from my experience. I have done that and is not the way to learn a skill.  Focus on one thing at the time. It is easy to want to know everything, but you would end up not learning anything.

References: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch01.html, Concrete Skills

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Sweep The Floor

This post will be about the “Sweep The Floor” apprenticeship pattern from the book, Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. This pattern is about finding your place on your team, contributing to the teams work to earn their trust and respect, and growing as a developer. The pattern suggests taking on the undesirable peripheral tasks when joining a new team/project. This will help you learn more about the project, development as a whole, and will keep you away from the core of the project. These tasks are often overlooked in education so this can help you fill in the gaps of education while working on something low risk. This does not mean lack in quality though. keep good quality, as bad quality on these portions of the project can become troublesome later on.

There are some problems with this pattern mentioned by the authors that I agree with. One is that you may become the guy who they use to do such dirty work, lacking in opportunity to work on more challenging tasks. Another problem is that you may become intimidated by anything that isn’t the easy yet boring work. Although you learn from this work, there becomes a point where you start to plateau from lack of challenge. The authors solution for these problems are to advocate for yourself and look for every opportunity where you can show them you are capable of contributing to higher tier work. Showing them enthusiasm and skill should make them realize that you are ready and capable to move on to more skillful tasks.

I found this useful because everyone has this starting point where they’re at their first job in a profession and need to gain the trust of their team members. Showing them that you are there to contribute can go a long way and nothing shows that better than when you do the tasks that no one wants to do. Although I already had an idea of this, the book really gave me a solid idea of what to expect to do at my first job as a developer and how to get my team to welcome me.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog Post #2

The second apprenticeship pattern from the textbook that I would like to discuss is the one described as “Unleashing your Enthusiasm.” For the most part, the book is trying to say that some students learning software development are not up to speed with knowing all they need to know yet but have great enthusiasm towards the subject. This often times holds them back in succeeding and learning primarily because of others with countering attributes. Many people have more knowledge of software development but much less enthusiasm toward it, and these people sometimes will hinder the success of the less knowledgable enthusiastic learners. The book primarily describes examples of this hindering with the different members of groups having less enthusiasm and not appreciating the ideas of the others. Groups in software development tend to think normally and about finishing their sprints and nothing else. The extra enthusiasm and ideas from the member of the team is often seen as just an annoyance to the other members when they are in a rush to finish their work. The book describes ways of getting around this by talking to people you trust about your ideas and edging them to give their feedback. Suppressing your enthusiasm and ideas is the worst thing you can do because you could have small amounts of knowledge and lose your enthusiasm entirely. Do not let your possibly great ideas go never proposed. It is your job to energize your team and not let them fall into the lapse of simply doing the work to do it.

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.

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

While there were certainly many important concepts presented in the first chapter of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman and the subsequent chapter introductions, I felt that the increasing level of conceptual involvement made the earliest sections far more fruitful in regards to spurring introspection. It cannot be overstated how well the logical flow of concept presentation is and how the breakdown into sections (Context, Problem, Solution, and Action) allows the reader to take the somewhat abstract elegant concepts and ground them in personal and actionable terms.

An example of how this played out: as I read the introduction to Chapter 2 – Emptying the Cup – I found myself having just digested a well-crafted opening but somewhat hazy about how the previous material would be of substantial use to me. To my pleasant surprise the authors had anticipated this and conveniently delivered me a whole section titled, “Context”. The section read:

“You are just starting out and have only a shallow understanding of how one or two programming languages.”

Indeed, it was so! The “Problem” section then provided what occupational or educational stumbling block I may be facing, followed by a tremendous helping of sagely advice to overcome the aforementioned problem, peppered with technical examples and some relatable anecdotes from the authors themselves. It concluded with a section appropriately titled. “Action,” which provided the hard-hitting actionable steps that, deep down, every person facing a self-improvement regimen knows will create an amount of existential friction surpassed only by its constructive value. Due to all of the above I found myself absolutely loving this book and can imagine it becoming a staple source of wisdom and motivation to come.

Speaking of existential friction, my favorite quote from the assigned reading was actually not in the assigned content but rather the “Audience” section before it. The quote reads, “[E]ven people with a decade or more of experience—particularly those who may be struggling to navigate their careers—will find inspiration and perspective to counter the siren call of promotion to management,” spoke to me because at my last job I spent many a night fighting with inept management only to open my phone on my lunch break and gaze in despair at my Quora feed littered with horror stories of talented principal engineers being given the axe because they had become too expensive to employ, wondering if they should have relinquished their craft and made the jump to management instead. For full disclosure this not some Marxist indictment of the labor aristocracy; I have been both the employee and the manager in my life and may one day find myself on the managerial side of the coin because I genuinely do believe that I am a strong mediator and leader. But the introverted tinkerer within me grasps firmly at any notion that it is possible to succeed largely based on the merit of my toiling and not the bureaucracy of corporate telephone; if this book is to be believed then it seems the inner tinkerer may have a leg to stand on.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

UNIFIED MODELING LANGUAGE(UML)

Since we have been using and seeing a lot of UML diagrams in class and in previous assignments, I decided to look for some resources on UML diagrams to broaden my knowledge and understanding. I finally settled on this resource because it gives simplified tutorials on UML diagrams making it easy to understand especially for beginners. Each part is broken down into various topics and subtopics. Page gives useful resources on UML as well.

This resource gives a clear and simplified definition of UML diagram. It has various topics that explains the roles of UML diagrams and goals of UML in Object Oriented Design. It explains the building blocks of UML diagrams which are Things, Relationship and Diagrams. It gives detailed explanations about nine kinds of UML diagrams or format uml diagrams, the three types of UML modeling and UML notations. It also gives sample examples of UML diagrams when explaining some concepts which makes it easy to understand when reading. Page also talks about the 2 broad categories-Structured and Behavioral with each divided into subcategories

In this tutorial, I learned that UML diagram is not a programming language and relates to Object Oriented Design. Initially I thought it was only a pictorial language to build software system, but this page makes it clear that it uses non-software systems as well. UML diagrams are also made for different users, not just developers to understand a software and non-software system. I must say that through UML diagrams in class, I was able to really understand the way a program is structured as well as relationships between the classes, interfaces etc. even before looking at the codes.

In the architecture part of the tutorial, I learned about the roles that UML diagrams plays in different perspectives of a system. These are the design, implementation, process, and deployment. Looking at these perspectives, all the diagrams that I have seen support this. These diagrams make clear of classes, interfaces etc., assembled in a physical state giving an idea about the flow a system/program has. Another important thing that I learned is that UML diagrams helps support the representation of physical nodes of a system that forms the hardware.

I learned that UML notations are very important to make a model that is very meaningful and is something that should be emphasized from the beginning. Some of these notations are Class, Object, Interface, Collaborations, Actor Notations, among others. I learned that the only difference between the Class and Object notations is that name is underlined in Object notations but has same structure and components as the Class Notation. I got confused when I saw a diagram of Active Class Notation as it looked similar to Class notation but I learned that the differences is that Active Class has solid borders and are used to describe concurrent behavior of a system.

I hope others find this source useful

https://www.tutorialspoint.com/uml/uml_standard_diagrams.htm

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

Simple Factory Pattern

Last week I gave you a small introduction in design pattern and explained their benefits in codes. Today I want to talk about one of this design patterns. The Factory Pattern. The reason why I choose this pattern is because I had to use it in one of my projects in java. The Simple Factory is not actually a Design Pattern; it is more of a programming idiom. But it is commonly used, so we will give it a Headfirst Pattern Honorable Mention. Just because Simple Factory is not a REAL pattern does not mean we should not check out how it is put together.

So, what is a simple factory pattern? The Factory Method Pattern defines an interface for creating an object but let us subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. As with every factory, the Factory Method Pattern gives us a way to encapsulate the instantiations of concrete types. As in the official definition, you will often hear developers say that the Factory Method lets subclasses decide which class to instantiate. They say “decide” not because the pattern allows subclasses themselves to decide at runtime, but because the creator class is written without knowledge of the actual products that will be created, which is decided purely by the choice of the subclass that is used.

When to use the Factory Design Pattern in Java?

Static Factory methods are common in frameworks where library code needs to create objects of types which may be sub classed by applications using the framework.        

Some or all concrete products can be created in multiple ways, or we want to leave open the option that in the future there may be new ways to create the concrete product.

Factory method is used when Products do not need to know how they are created.

We can use factory pattern where we have to create an object of any one of sub-classes depending on the data provided

There are a lot of examples about the Factory Design online. A lot of website gives a good explanation. I decided to choose the Headfirst Design Patterns by Elisabeth Robson; Kathy Sierra; Bert Bates; Eric Freeman. The chapter four shows talk about this pattern and shows a very good explanation and an example also. Another website that it helped me to understand it better was javarevisited. Again, it explains it with details and examples how it works.

https://javarevisited.blogspot.com/2011/12/factory-design-pattern-java-example.html#:~:text=Factory%20design%20pattern%20is%20used,just%20change%20in%20one%20class.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.