Category Archives: CS443

Dynamic Programming

Summary

In the article Exploring Dynamic Programming, Ross Rhodes goes over three examples of dynamic programming in increasing difficulty: nth Fibonacci Number, Traversing a Matrix, and Matrix Chain Multiplication. These are problems that have straightforward but very inefficient approaches that can be solved via dynamic programming techniques such as memoization, which is an optimization technique that stores the results of expensive function calls and returns the cached result when the same inputs occur again. For example, in the case of calculating the nth Fibonacci Number for multiple different values for “n”, rather than performing those calculations again you can instead store already calculated values.

Although the three examples provided are each examples of dynamic programming, they each have moderately different approaches to solving their respective problems. As Rhodes says at the end of the blog post, these examples only scrape the surface of what dynamic programming can be used for.

Reaction to Content

I chose this topic for this week’s blog post because it was something I hadn’t been exposed to significantly. While I’ve known of the technique and its applications, I hadn’t used it for anything other than a similar application of the Fibonacci example provided. The other two examples provided are notably more complicated and helped to provide provide more insight into what situations dynamic programming can be used to solve.

Overall, while I think this article was useful for understanding dynamic programming, I think the best way to understand it is to solve problems using these techniques and to come up with your own solutions for them. That way you can really internalize these concepts and you can spot when you’ve run into a problem in which dynamic programming could be used. Just reading through these examples alone and trying to follow through the thought process won’t necessarily be enough when you have to solve a unique problem on your own.

I think this topic is definitely something that should be understood, as even if you somehow never ran into a real-world situation that dynamic programming would be useful for, understanding it will only make you a better programmer. And if nothing else, it’s likely to come up at some point in an interview.

Source: https://blog.scottlogic.com/2018/01/30/exploring-dynamic-programming.html

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Machine Learning vs. Deep Learning

Summary

In the article Machine Learning vs. Deep Learning Explained, Bartek Ciszewski explains the difference between Machine Learning (ML) and Deep Learning (DL). He gives a quick overview these two terms are and also talks about the broader field of Artificial Intelligence (AI). He also gives examples of what machine learning and deep learning can be used for as well as providing real world examples of DL, such as Google’s Go playing program, which is capable of inventing its own moves.

Reaction to Content

I chose this topic because it was an interesting topic that I had looked into in the past but haven’t really done much research on yet. This article in particular was mainly useful as a refresher, providing a basic overview of the difference between machine learning and deep learning. Some of the real-world examples that he brought up (AlphaGo, self-driving cars, early automatic cancer detection, etc.) are definitely things that I think would be interesting topics to read about in order to get a deeper understanding of how deep learning works.

Overall, this article didn’t change how I thought about this subject. For those who haven’t seen these concepts before I think this article would be a useful place to start. The examples he provided for machine learning algorithms are helpful for understanding what it could be used for, but it seems like it’s very difficult to provide a simple example of what a deep learning algorithm could be used for due to how complex of a topic it is. As Ciszewski stated in his summary, neural networks are usually “black boxes,” so even the people who created the deep learning algorithms don’t entirely understand how the machine is able to do what it is being designed to do.

This video How Machines Learn, by CGP Grey, is another useful resource that helped me understand the topics discussed in the article better, by providing more use cases for them as well as giving a visualized high level overview of how these algorithms work.

I think in order to truly understand how deep learning works, I’ll have to look into example algorithms and go from there.

Source: https://www.netguru.co/blog/machine-learning-vs.-deep-learning-explained

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Test Driven Development

Summary

In the article Introduction to Test Driven Development (TDD), Scott Wambler talks about what Test Driven Development (TDD) is, as well as many other topics related to it such as traditional testing, documentation, test-driven database development, and scaling TDD via Agile Model-Driven Development (AMDD). He also goes over why you would want to use TDD as well as some of the myths and misconceptions that people may have about it.

A basic description of TDD is that it is a development technique where you must first write a test that fails before you write new functional code.

A simple formula that Wambler included to help understand TDD is as follows:

TDD = Refactoring + Test-First Development (TFD)

Here’s a quick overview of TFD which he provided:

Reaction to Content

I chose to search for articles of this topic because I wanted to really understand how to properly perform test-driven development. For what project that I decide to work on next, I wanted to be able to follow an effective process so as to improve and avoid writing “spaghetti code”. I imagine there are other development methods that may be better suited for what I want to do, but this is one of the ones that I hadn’t had a great understanding of until reading this article. Hopefully I’ll be able to properly use this method to write clean, well-documented code in the future.

While I knew of TDD before reading this article, I never really took the time to actually learn how to do it. I think that this article was very useful in helping me understand what TDD is and what are the advantages of using it, but while I believe that I understand it conceptually, I’ll probably need to look up examples, maybe follow a tutorial to make sure that I don’t do it wrong and end up building bad habits.

One of the things in the article that I had some trouble understanding was when he referred to tests used in developer TDD as “developer tests” and that they were inaccurately referred to as unit tests. I think that he may be referring to unit tests as a section of tests included in developer tests as a whole, but I’m not completely sure.

Source: http://agiledata.org/essays/tdd.html

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Writing Great Unit Tests

In the blog post Writing Great Unit Tests: Best and Worst Practices, Steve Sanderson talks about the best and worst practices when writing unit tests. He goes over the true purpose of unit tests (each examining a unit of your code separately and as a whole cohesively working together to provide value that is more complex and subtle than the sum of its independently tested parts, not for finding bugs), as well as the purpose of integration tests (automate the entire system to detect regressions). At the end of his post, he also gives several useful tips for writing great unit tests, such as making each test orthogonal, or independent, to all other tests.

The reason I chose to talk about this blog post is because I think it’s definitely something that’s commonly overlooked by developers. As Sanderson said at the beginning of his post, “Even if you’re a brilliant coder with decades of experience, your existing knowledge and habits won’t automatically lead you to write good unit tests.” For people looking to get into software development, I think it’s important to learn how to write great unit tests early on so as to avoid having to clean up a self-inflicted mess in the future.

I found it interesting when he described the difference between unit tests and integration tests, as well as the problems that bad unit tests can cause. This image found in his post is useful for visualizing this:

image

The last section in which he gives practical advise for writing great unit tests is also something that I think will be useful in the future, although I think the formatting may have been messed up.

One thing that I have a hard time not necessarily agreeing with but understanding is how he said that unit testing isn’t for finding bugs. I think that, for example, if you were to make a change to the way a function performs its task (perhaps to optimize the code) while not trying to affect the end result, one of your unit tests failing because of this could be classified as “finding a bug.”

Source: http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Fakes, Mocks, and Stubs in Unit Testing

In the blog post Test Doubles — Fakes, Mocks and Stubs., Michał Lipski describes and implements three different types of test doubles: fake, stub, and mock, and the situations in which you would need to use them in your unit testing. He also provides useful examples for each of the three terms.

Here’s a useful image found in his blog that helps to understand the differences between the three:

Fake – object that has a working implementation, but not the same implementation as the ones in production. Usually they take some shortcuts are are simplified versions of the production code. This is useful because you’re able to do integration test of services without starting up a database or performing time consuming requests.

Stub – object that holds predefined data and uses it to answer calls during tests. This is useful when we can’t or don’t want to involve objects that would answer with real data or have undesirable side effects.

Mock – object that registers calls as they are received. This is useful when we don’t want to invoke production code or when there is no easy way to verify that the intended code was executed.

The reason I chose this blog post in particular is because the first time I was exposed to stub functions was earlier in my internship while working on unit tests, and at the time I didn’t have a great understanding of what their purpose was. I was recently reminded of them last week during lecture, so I decided that it’d be a useful topic to read about. At the time I wasn’t aware that there were different types of test doubles, so I found that the examples found in Lipski’s blog are really helpful in understanding the key differences between them, as they share many similarities and are likely to get mixed up. According to Lipski, misunderstanding and mixing test doubles implementations may influence test design and increase fragility of tests, standing in our way to seamless refactoring. So I think that this blog may be a useful resource if you were trying to write clean unit tests.

Source: Test Doubles — Fakes, Mocks and Stubs.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

CS-443 Introduction

This is my introductory blog post for CS-443 Software Quality Assurance & Test.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

The Software Craftsman Ch. 7 and Ch. 8

Chapter seven, entitled “Technical Practices,” covers the topics of ideal programming practices and why they should be utilized in the field.  Of course by best practices I’m speaking of TDD, CI, paired programming, etc.  These are the topics that have been covered at length in The Clean Coder and my related blogs.  I found it interesting that Mancuso has a separate section for refactoring outside of TDD.  For those who are unaware, refactoring is a step within test driven development.  Therefore, if TDD has been utilized, then there is no need to explicitly describe refactoring.

Chapter eight, entitled “The Long Road,” is an interesting chapter about career choices. We all know that money is a motivating factor when making career choices, but taking money out of the equation leaves you with the following three factors:

Autonomy: It is when we are in control of what we do, how we do it, and when we do it. That should always be the case in a true Agile context.

Mastery: It is when we are constantly learning and evolving—becoming bet- ter professionals and better human beings.

Purpose: It is when we feel that our job is important and we are contributing to make things better—instead of just doing what we are told without under- standing why.

Once we get a grasp on where we want our careers to go, and what factors motivate us, it is easier to find the right jobs.  This doesn’t just happen, it requires a lot of work and effort in order to “craft” our careers.  Mancuso thinks it is important to differentiate between a career and a career within a company.  Your career is more important than a career within a company.  I think that your career and your career within a company are equally as important, and should more often than not align, but then again I have not worked in the field.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

The Software Craftsman Ch. 5 and Ch. 6

I was speaking with one of my professors today about Sandro Mancuso’s The Software Craftsman and was expressing my preference of this book to Robert C. Martin’s The Clean Coder.  I may have deluded myself into believing that Mancuso uses less anecdotes than Martin in his writings.  I am not infallible.  Mancuso does use an exorbitant amount of anecdotes in his book.

Chapter five is called “Heroes, Goodwill, and Professionalism” and after reading the chapter I’m still not sure I understand what the title means.  Goodwill does not even appear in the chapter.  This chapter reminds me of parts of a few chapters from The Clean Coder especially the chapter on “How to Say ‘No.’”  I’m not going to recap previous blogs so if you are interested in Professionalism I invite you to read my series of blogs on The Clean Coder as that is the theme of that book.

Chapter six is called “Working Software” and it is a pretty simple chapter.  Essentially the main idea behind this chapter is that if code is going to be used for any extended period of time, it must be written properly.  “Working software is not enough.”  Rushing through the process and skipping steps is going to cost you time later, so it is in your best interest to take your time.  Mancuso also describes how to address legacy code.  He points out that nobody likes working with legacy code, but a change in attitude can make a world of difference.  Isn’t that true of everything though?

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Sprint 6 – Learning Reflection

Sprint 6 marks the final sprint of our semester.  Our goal was to complete APTS-254 issue by the end the sprint.  The rest of our group ran into roadblocks and joined us in our endeavor.  We also hit roadblocks and needed more clarification.  Even though we found where in the code we needed to add the case, we weren’t positive about what the established reminders were doing.  So we determined that the only way we would be able to figure out exactly how these reminders worked was to recreate the scenarios in which they would appear.  Unfortunately, we were unable ETL server to work on our computers so we were essentially taking shots in the dark.

With all of this uncertainty, and the delayed response time from the people at Ampath, it was virtually impossible to accomplish anything of any substance.  In the end we were unable to complete our goal of finishing APTS-254, which means that we were only able to complete one issue this semester.  Perhaps I set lofty goals for our team, or maybe we underperformed, but one thing is for sure.  I can’t wait to spend way more time developing my own Angular 2 project.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Sprint 5 – Learning Reflection

Sprint 5 began with our solution to NGPOC-185 was pulled into Ampath.  We also started work on some new issues we assigned ourselves from JIRA.  In accordance with what we decided last week we picked two issues, one for each group of three.  Our group picked APTS-254 which was described as “User are requesting when a patient switches to 2nd Line the Viral Load Pop-up reminder should not pop until the patient has used the 2nd Line Regimen for 6 months.”  Just as we did with NGPOC-185, we decided the best course of action was to attempt to recreate the issue and then find where in the code the issue was located.  Neither individually nor as a group could the issue be recreated so we determined that we needed additional clarification on the issue.  I wrote a message to Ampath, but it took awhile to get a response, delaying our progress.  Before the sprint ended, we did get a response.  Apparently the issue was located in the ETL Rest Server, which we did not have before.  They directed us to the repository, but even with this new information we were unable to recreate the issue.  We will continue to work on this issue next sprint.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.