Category Archives: Week 4

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.

You Ain’t Gonna Need It

Hi everyone and welcome to the week 4 of the coding journey blog. For this week’s post I will be talking about a principle called YAGNI which is an abbreviation for you ain’t gonna need it. Now this may seem like a simple topic, but it is very important concept that often gets overlooked in the early stages of programming.

You ain’t gonna need it is one of the key principles to extreme programming and the XP co-founder has states that you should always implement things when you actually need them, never when you just foresee that you need them. The basic concept behind this principle is to do the simplest amount of work that would also get the program to work. The goal is to cut down drastically on unnecessary work, and as a result of this there will be higher productivity rates as well as a more simple to understand code. Efficiency is key when it comes to programming. A software can have many lines of code and functions, but this will be an issue if there are much simpler ways to implement those same functions with a lot less work. The process will take a lot longer with more features and down the line make it much more difficult to maintain.

There are a lot of problems that can occur if you try to implement a feature early when it is not necessary at the moment. There are three things that could happen which include having the wrong feature, having the right feature but it is built wrong or the most ideal option is having the right feature that is built right. Now with these results of the features there is also the outcome of costs. The different costs include cost of building, cost of delay, cost of carry and cost of repair. The cost of building is all the effort spent on analyzing, programming and testing a feature. The cost of delay is the lost opportunity to build and release another feature now. The cost of carry is the complexity added by the feature to code, which makes the software harder to modify and debug. The cost of repair is the effort spent on modifying a feature because it is not exactly what you need now. Now these concepts are the input and output as they go hand in hand. If you make the wrong feature then you have to pay the cost of building, carry and delay. If you make the right feature but it’s built wrong then you have to pay cost of repair, carry and delay. Now with the best option if you make the right feature and it is built right then you just pay cost of carry and delay.

In my personal case, I plan to follow the YAGNI principle in all my future projects because it help simplify projects and saves time. It improves my productivity and prevents unnecessary work and problems.

Check out these additional resources: https://medium.com/better-programming/yagni-you-aint-gonna-need-it-f9a178cd8e1

YAGNI

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.

Thoughts on YAGNI

The link at the very bottom is an article focusing on a design philosophy YAGNI which is one of the topics we’re supposed to cover in class, though we haven’t gotten to it yet as of my writing this. The name is an acronym of “You Ain’t Gonna Need It” which is basically means if the situation doesn’t immediately call for something to be done, then don’t bother with it. The acronym’s meaning is also the main reason why I chose to write about this topic; it sounded funny to me. The article goes on to describe four “costs” that YAGNI mitigates. The first is the cost of build which is the time and effort spent on analyzing, programming, and testing something. The second is cost of delay which is the cost of pushing back other priorities in order to work on what is deemed more important. The third is cost of carry, the complexity that something brings to software and how that modifying and debugging more difficult. And the last is cost of repair which is self-explanatory. By only working on what is immediately important, the chances of wasting time or changing the program are reduced significantly.

What I find interesting about YAGNI is that in a way, it’s telling people to wing it. The biggest reason for that is because in everyday life, sometimes plans change because of unforeseen circumstances. Let’s take for example someone meticulously planning out a program while taking multiple scenarios into consideration and designing different components to compensate. But it later turns out that many of these scenarios are either unlikely or are taken care of by other things outside of the program that this person didn’t even know about. That in turn causes cost of carry because of all the components complicating the core program, cost of build from the time and effort wasted on designing and implementing these components. These are a lot of headaches that are solved by just being lazy and that’s kind of funny to me.

Something else I noticed is that YAGNI is a really simple design philosophy, to the point where it isn’t strictly constrained to software design. Another example I’ll bring up is how when I was younger, I would waste time writing essays by agonizing over small minute details. And a piece of advice I would often get is to write out my first draft no matter how horrible and worry about fixing the details when the time comes. That isn’t to say that drafting out an outline isn’t important; this applies both to essay writing and software design. The truth is that there should be a balance between YAGNI and other design principles which the article does acknowledge even though it does downplay it.

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

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

Dig Deeper

This pattern form “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye is probably the scariest thing I read in this book so far. It describes how in order to be a good “craftsman” in software development one should be able to dig deeper into the knowledge about the problems they are working on. It shows you how one must try and be able to find more information about things in order not to be just a person who puts some code together and is what the book calls “programming by coincidence”.

This is a very interesting and intriguing pattern in my opinion but at the same time makes me feel as one of the people who just happened to code but do not know what they are talking about. It might just be my own feeling at the moment but nevertheless it is there. In my professional work I have always worked on very custom project and not very often things were reused which lead, at least in my case, to constantly only gaining surface knowledge of certain subjects. It is not easy to admit that I am probably not as knowledgeable as some of my colleagues, but I think this pattern is showing me how I might be able to fix this problem.

I am very much in agreement with what this pattern is describing, and in my own opinion a living example, even though I am constantly reading some new materials about my chosen field I still feel it is not enough and I should dig deeper to be able to stand out . Knowledge about a subject is always precious but just like the pattern describes if it is not deep enough it will not be really useful, and it might become a problem later on. One thing I definitely understand from this pattern and I like to think that I’m doing right is reading of the documentation and specifications, even though it might not be enough I think that this at least is somewhat redeeming for me.

This pattern is also somewhat problematic for reasons that sometimes getting more knowledge about subject is just plain boring and monotone, I know it sounds as an excuse, but I never heard about anybody excited to read some standards and specifications. Yes, it has to be done and it should be, but it is definitely not enjoyable.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.