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.

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.

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.

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:

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.

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.