Category Archives: CS@Worcester

Boundary Value Testing

For this week’s blog post, I wanted to cover a topic that we covered earlier this semester, boundary value testing. I found an article on seemingly my go to site for articles for this blog, guru99. The article has several sections including a brief definition on what boundary testing is, as well as a definition of what equivalent class partitioning is and the relationship between the two. There are also a couple of examples and an analysis section that explains why we should use equivalence and boundary testing.

The article describes boundary testing as “the process of testing between extreme ends of boundaries between partitions of the input values.” These extreme values include the lower and upper bounds, or the minimum and maximum acceptable values for a given variable. For boundary testing, you need more than just the minimum and maximum values though. For the actual testing, you need a value that is just above the minimum, a nominal value that lies somewhere in the middle of the range, and a value that is just below the maximum value.

Equivalent class partitioning is explained by the article as “a black box technique (code is not visible to tester) which can be applied to all levels of testing.” It also states that when using equivalent class partitioning, “you divide the set of test condition into a partition that can be considered the same”.  This may sound a bit confusing but it is actually pretty simple. The article uses an example of a ticket system where values 1-10 are the only acceptable values and values 11-99 are invalid. You could break up this set of numbers into two different equivalent class partitions and then returning back to our boundary testing concept, we would test values like 0, 1, 5, 9, and 10.

The best part about boundary testing is that because it is a form of black box testing, you do not need to see how the actual code works. You only need to know the specifications for the valid and invalid numbers. Another reason to use boundary testing is that it eliminates the need for testing every value and thus, minimizes the tests needed. I have and will continue to utilize this testing strategy throughout my software engineering career.

Link to original article: https://www.guru99.com/equivalence-partitioning-boundary-value-analysis.html

 

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Uh Oh! Spaghetti Code!

Hello, once again my fellow readers! I am sorry to report that this will be my last blog post for this semester and in turn this class. Continuing with my trend of Antipatterns today I will talk about a delicious Antipattern, Spaghetti Code.

SPaghetti code is the Antipattern that everyone first falls into when learning how to code a new language, learning a new coding tool, or learning how to code in general. Spaghetti code is the Antipattern representing code that has very little software structure. As a result, this leaves the code with a lack of clarity or direction, even to the original developer. This is the classic moment where you uncover code from some time ago, sit down, look at it, and go, “What was I even trying to do here?”

It can be quite easy to identify Spaghetti Code. Simply look for methods being very process oriented. Object implementation will also dictate flox execution. You will see minimal relationships between objects. You will see a very predictable pattern of object use.

Spaghetti Code can result in many consequences. Spaghetti code results in a program with diminishing returns. If Spaghetti code is mined, only part of the code will even be suitable for reusable if any of the code is reusable at all. As well, maintaining the code will result in being much more wasteful and a diminishing return as well. It will be more practical and less wasteful if a new solution is developed. Spaghetti code is so detrimental, it can even remove the benefits of object-oriented design.

To fix Spaghetti Code, you can refactor your code. Refactoring code is a natural and excellent way to maintain your code and is a wonderful way to increase performance. Code refactoring first must achieve a sufficient structure. Then, performance critical code must be identified and then structure compromises must be implemented as to enhance performance. Of course, the best way to get rid of Spaghetti Code is to prevent it in the first place.

As I was reading this, I knew that this is something that I could apply this almost immediately. In my next semester, I will have to work in a team and build off of an existing program. This Antipattern will stay with me and I definitely will see how I can work refactoring into the process to ensure that no Spaghetti code will remain. I have a sneaking suspicion that refactoring will be an idea that if implemented, will be able to squash many different Antipatterns that show up or are already lurking.

Well folks, this going to be my last blog entry for this semester. Thanks for reading and learning along with me (or watching me read). Until next time, have a wonderful day!

 

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Software Engineer Qualification

I am writing in response to the blog post at https://www.shiftedup.com/2015/05/07/five-programming-problems-every-software-engineer-should-be-able-to-solve-in-less-than-1-hour titled “Five programming problems every Software Engineer should be able to solve in less than 1 hour”.

This blog post shares a story about a history of people who apply for the position of a software engineer and claim some loosely related skills without actually having any chance of understanding or performing the job. The frustration of the author is expressed, and the author lists five programming tasks to disqualify any supposed “software developer” who would not be able to complete them in under an hour. I attempted them myself and they only took five minutes.

I am not sure what motivation people have to apply for a job that they are in no way capable of performing, but the author of this blog post seems to be fed up with how common it is. Supposedly, though, people who do not know what programming is are attempting to become software engineers.

I think that the list of five programming problems and the time constraint of one hour is a generous filter to sort out all of the people who have never written a program in any language ever before. It certainly would not be enough to qualify for the position of a software engineer, but that is not what the problems are meant to indicate upon fulfillment, it is simply what they are meant to reject upon failure. Somebody who claims to be a “developer” and fails to accomplish these simple tasks should revisit their resume.

The problems themselves are very basic. Find the sum of some numbers using loops or recursion, combine elements in two arrays, calculate Fibonacci numbers, and the last two problems are more peculiar but still simple demonstrations of basic problem solving. It should be evident in much less than an hour whether a person is capable of solving them, and any experienced software engineer should only need ten minutes.

The blog post acknowledges some feedback about the last two problems that are a bit less conventional than the others, but I think that the ability to solve unconventional problems is important, and I think anyone who writes code in something besides a markup language or an object notation could solve them.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Test Plan

In this blog, we are talking about test plan. Test plan is one such important testing deliverable offered during the release of the product. A software product, once developed and tested completely, is prepared for its release, during which various documents, reports, screenshots, etc. are also delivered to the client and other stakeholders of the project. Known as deliverables, these documents and reports are an integral part of software development life cycle (SDLC), in my last blog, as they necessary information related to the product to the concerned individual.

Test plan encompasses all the activities performed during the testing process. A test plan document offers all the necessary and relevant information to the developers, business managers, as well as the customers. There are different types of test plan:

  • Level specific test plans: These include Unit test plan, Integration test plan and system test plan.
  • Type specific test plan: these include plans for major parameters like performance testing plan.
  • Master test plan: This is one single big plan combining all the other plans to be carried out on the software product.

Test Plan Template, the testing team or the test management team ensures that it follows a set template, which allows them to log all the necessary details about the testing process in the document. There are fixed set of parameters such as test items, testing approach, pass/fail criteria, approvals … there are all defined by the standard IEEE 829.

Creating a test plan by following guidelines, to make sure to create test plan accurately. It is important for them to consider few guidelines, which can assist them in recording all the necessary information in the document with precision. Create a concise test plan, with all the necessary information. The information provided should not be redundant and superfluous. While preparing a test plan it is necessary for the team members to be specific and precise. Create points, list, and tables wherever necessary, to increase the readability of the document. Review the document constantly before it is released with the product. Update the test plan with all the recent changes and modifications.
We know to make sure the test is in good quality, we need to know what we are looking for in testing. A testing plan would help us, a well written test plan ensures that all the aspects of the software are covered and tested. This combine with a check list would make further ensure the accuracy of out test.

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

Crunch-a-Time me Captain (I just took a class on Design Patterns and Just Read That They are Wrong)

If that title scared you, I am sorry. This is the second post I am writing in a span of a couple hours and decided that this topic would prove to be a very interesting one to cover. While the post Rethinking Design Patterns by Jeff Atwood very openly claims that design patterns often cause unnecessary complexity and have turned much of today’s programming army into a mindless army of Gang of Four missionaries I believe it is a very delicate balance of both sides of the argument that is the solution.

In the post Atwood lays out the definitions (yes definitions!) of design pattern in order to get rid of any confusion about what he is referring to. There are two definitions because he is talking about the patterns created by the gang of four in order to solve typical solutions and also the general idea of designing a template for a solution one is faced with based on the circumstances. He also writes about the book that directly inspired the gang of four bible. This book is called “A pattern Language”, and is a direct inspiration for the design pattern book that succeeded it. This book outlines general ideas for solving problems rather than giving the reader templates to solve general problems. While the difference in these may be subtle, the latter cause anyone implementing an idea to have less of an understanding of the implementation and whether the chosen pattern is the best way to solve the problem at hand.

I feel as though the teachings I have received about design patterns has greatly influenced my understanding of coming up with solutions to problems. Before taking this class almost every program leading up to it was extremely complicated while solving relatively simple problems. Many of my programs were one trick ponies that if implementation had to be added would be in need of an almost total rewrite. After learning about design patterns I have the proper tools to increase how modular my programs are which is a huge step in the right direction. I feel like there are many cases where the gang of four design patterns are applicable and can be very efficient but for problems that don’t require a pattern it is important that we as programmers can recognize this and implement a simpler design to avoid useless complexity.

I will definitely be reading A Pattern Language soon because it seems like many of the ideas laid out in that book are extremely helpful in situations where I am tasked to program something that I can’t think of a design for. Thank you for coming to my Ted Talk.

From the blog CS@Worcester – Dummies for Programming by John Pacheco and used with permission of the author. All other rights reserved by the author.

Hashmaps Blog 2

Today I read an article on baeldung.com about HashMaps. I have used HashMaps before in Data Structures as well as Unix systems and have found them to be a very resourceful way to store and retrieve data. Most developers know about HashMaps but don’t completely understand how they work, in todays blog we will be cover HashMaps in JAVA.

HashMaps have an inner class called an Entry Class which holds the key, values and will return a value at the end. Two important main methods in the class are put() and get(). put() associates the specified value with the specified key in the map, it checks if the key given is null or not. If the given key is null, it will be stored in the zero position. The next internal part of the put method is that it fits the values inside of the limits of the array. The get() method is very similar to the put method but instead of storing, it returns a value. Get() gets the hashcode of the main object and finds the location of it in the array. If the right value is discovered, then it returns the value but if it cannot find it then it returns null. Put() and get() are two major internal parts of HashMaps and looking back at some of my old projects with HashMaps I now fully understand what is going on internally when I execute the program. I will use HashMaps more frequently in my projects now and I hope that after reading this you will be able to understand HashMaps better and will be able to give them a shot.

https://www.baeldung.com/java-hashmap

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

White Box Testing Blog 2

Welcome back to Dcanton’s blog. This week I’m going to be talking about  a blog posted on Apiumhub, a tech hub that specializes in software architecture. The blog talks about the benefits of unit testing. The author starts by giving the goal of unit testing which is to segregate each part of the program and test that the individual parts are working correctly. He then continues to list why it is beneficial. One of the benefits is that it improves the design of the program, it makes you think about if your code is well defined and if it reflects what the outcome is supposed to be. Another benefit of unit testing is that reduces cost long term, since bugs are found earlier in the process, they won’t be as costly and much easier to fix than later in the process.

I chose this blog to discuss this week because it has a lot of information on how effective unit testing is. Since there are other ways of test such as black box testing and grey box testing, this gave me a good understanding of it and the benefits that come from using this method. One thing I learned is that white box is tested by tester while others are tested by developers. Thank you, Dcanton blog will be back next week with another blog

 

https://apiumhub.com/tech-blog-barcelona/top-benefits-of-unit-testing/

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

An Update on this Blog and also Cleaning Up House

I would like to preface this blog by saying that I am very sorry for the lack of content on here. Life can be overwhelming and this blog was put on the back burner throughout the semester. This being said I am excited to give my opinions on some really interesting content that I have been reading about.

The blog post I decided to write about for my blog post is aptly named “Clean, high quality code: a guide on how to become a better programmer”. I decided to research this topic a bit because while I feel like I have a good grasp on the technical side of programming I have trouble keeping my programs neat. This issue becomes very apparent when you decide to update a program you haven’t looked at in a month or so and it is complete nonsense that is almost impossible to parse no matter how much time you look at it. This problem is exponentially larger when others have to collaborate on projects with me and find it difficult to contribute to the giant ball of garbage I have artfully crafted with my keyboard. I long for the day where every aspect of my programs shine like a well polished stone and I am proud to add projects I have created to my resume.

The blog starts off with asking the very appropriate question “what is clean code?”. To which it replies with an image that genuinely made me laugh out loud. It illustrates that code can be measured in how many “WTFs” can be heard from others reading the code. While this is hilarious it also lies very much in truth. The less confusion others have while reading your programs the cleaner it is. The first half of the post is mainly outlining why clean code is good and why bad code is bad. It explains it extremely well using metaphors such as “leave the campsite cleaner than you left it.” After the post goes into detail giving tips as to how one should name variables and functions. Many of the ideas in the blog I have never given any thought to like naming functions verbs and naming variables nouns. While this is extremely intuitive I can guarantee that I have done the contrary which resulted in the use of functions being lost in translation. Interestingly enough the blog claims that having functions that are so clear in their intent that comments are unnecessary is how one achieves code nirvana.

Overall I’d recommend this to anyone who hasn’t taken the time to lay some base guidelines while they are writing programs. All of the information given in the post is very useful.

Image result for hoarder
Visual representation of my code before reading the blog

From the blog CS@Worcester – Dummies for Programming by John Pacheco and used with permission of the author. All other rights reserved by the author.

I Know Halloween Was A Couple Months Ago But…

Hello, again my friendly neighboorhood readers!

This week I have been again been reading up on those crazy Antipatterns I discovered week. As you can probably tell by the title, the Antipattern I am writing about this week is a Halloween themed Antipattern. I know it’s a little late but today’s Antipattern is the Poltergeist.

A Poltergeist is a class that has a limited role to play or limited responsibilities in a system. This practice adds unnecessary abstraction and their short life cycle means more wasted resources. Poltergeists normally appear to initiate some other action of a class that has a more permanent status. A Poltergeist is easily identifiable as they will typically bear the “_manager” or “_controller” title in their name. The main three disastrous effects of the Poltergeist Antipattern is a waste of resources every time they are called, they utilize redundant navigation paths, and the clutter the object model, getting in the way of proper object-oriented design. If a Poltergeist Antipattern is left alone it can result in such occurrences as transient associations, stateless classes, redundant navigation paths, short duration, temporary classes, and objects, and single operation classes. Some typical causes that lead to a Poltergeist Antipattern manifesting are a lack of object-oriented architecture, using the incorrect tool for the job, and of course, a specific disaster such as management incompetence.

Now how do we fix this Poltergeist problem? Well, they gotta go. Of course, once the Poltergeists are gone, the functionality they had must be replaced with an adjustment to the architecture. Another solution is to utilize the 80% solution that we discussed in the post discussing the Blob Antipattern.

Now, I do not know about you reader, but I believe that this is definitely an Antipattern that every programmer falls prey too, especially when they are beginning. I can think of many programs that I have many over the years that have had at least one Poltergeist stalking around in them. This does make me rethink how I will program in the future. While the programs I may write now do not need any real optimization, in the future, optimization is going to be a required skill for me.

Well, that is it for today readers. Have a good week until next time!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

The top 5 software architecture patterns: How to make the right choice

We learned about Model-View-Controller in class but there are more software architecture patterns, there are different layer is useful for different design. This blog is based on the book Software Architecture Patterns, by Mark Richards, Boston-based software architect who’s been more than 30 years about how data should flow through software. The author made top 5 software architecture patterns, which show how to choose them.

Layered (n-tier) architecture, this architecture arranged so the data enters the top layer and works its way down each layer until it reaches the bottom, which is usually a database. This is where the Model-View-Controller (MVC) structure, as we know, is the standard software development approach offered by most of the popular web frameworks, is clearly a layered architecture. Best use for: New applications that need to be built quickly, enterprise or business applications that need to mirror traditional IT departments and processes and applications requiring strict maintainability and testability standards.

Event-driven architecture helps manage this by building a central unit that accepts all data and then delegates it to the separate modules that handle the type. This architecture is easily adaptable to complex, often chaotic environments, scale easily and easily extendable when new event types appear. This type of architecture best for asynchronous systems with asynchronous data flow, applications where the individual data blocks interact with only a few of the many modules.

Microkernel architecture, the basic routines for displaying a file and editing it are part of the microkernel. The solution is to push some basic tasks—like asking for a name or checking on payment—into the microkernel. Good use for this architecture is the applications with a clear division between basic routines and higher order rules and the applications with a fixed set of core routines and a dynamic set of rules that must be updated frequently.

Microservices architecture, the goal is to create a number of different tiny programs and then create a new little program every time someone wants to add a new feature. It’s used mainly when the different tasks are easily separated. In many cases, different tasks can require different amounts of processing and may vary in use. Best use for this is websites with small components, rapidly developing new businesses and web applications.

This is interesting architecture layers type, it is important to know and compare to real life application. I hope we more type to know more about the architecture, specially about website.

Link

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