For this post, I decided to read the pattern “The White Belt”. This pattern talks about the ability of a software developer, and craftsman, to unlearn something and use an entirely different approach to solve a problem in order to maintain the ability to learn. The pattern talks about the idea of getting stuck at what seems to be your peak potential but that this is merely because you aren’t trying something completely new that would force you to try to solve the problem with a new approach.
I agree with the overall premise of this pattern. Personally, I’ve found it incredibly difficult to try to learn new languages without internally trying to write Java in language X. This summer I had an internship where one of my projects was to make a prototype program for a chat bot using Microsoft’s existing AI technology. This meant that I had to veer away from my good friend Java and attempt to use a new language, C#. I honestly don’t remember that much about C# other than that it looks like a lot like Java and I was able to manipulate the code so that it worked. I spent the entirety of the project focused on how it was similar to Java and how to write Java in C# and never even remotely became a master of the language. Granted, it was a short term project (roughly 4-6 weeks and 20-30 hours a week), so mastery was never feasible. The problem is that if I have to work on another C# project at some point in my career, I will have to start over. I never unlearned my Java knowledge to write in C#.
This coming summer, I’ll be starting a position where I will almost exclusively be writing in C++, a language I have never written a line of code in. Before I start the job, I’m giving myself time to learn the basics, but I know that I’ll need guidance along the way from the subject matter experts at this new company. There will most certainly be moments where I am completely dumbfounded about how to solve a particular problem, or what is wrong with my solution. I’ve learned that over the last couple of years of interning, and at those companies I was using a language I thought I was pretty comfortable in (Java).
Being able to put on the white belt and learn from the masters is one of the things you hear about from everyone in almost every field of technical work. I plan to put on my white belt as soon as I walk in the door at my new company.
For this week’s blog post, I decided to find a blog post on a topic that we haven’t explicitly covered in class. I found an article on Agile Testing and my interest in Agile as a whole drew me in. This article is on QASymphony and breaks down what Agile methodology is, some examples of Agile testing, and how to align testing with the Agile delivery process. For the sake of this post, I will assume you’re familiar with the general concept of the Agile methodology for software development, hopefully you understand the general concept of Scrum and Kanban.
One of the interesting testing strategies for Agile development is the Behavior Driven Development tests (BDD). These tests are similar to the Test Driven Development (TDD) style testing systems in traditional waterfall development cycles. They are basically a replacement. Instead of writing unit tests before code is written, the BDD tests are on a much higher level. This is how user stories are written. The development of the code is based on end-user behavior and the tests need to be readable for those who might not be particularly technical as they can often replace requirement documentation. This saves time in the long run as there is no duplication of the process for those who might not be able to read user tests in the traditional TDD style of testing. The best part about BDD testing is that the tests do not necessarily need to be written by technical team members. These can, and are often written with input from business partners, scrum masters, and product owners who might not necessarily be able to contribute when it comes to writing unit tests in the TDD format. This style also allows for testing small snippets of functionality like TDD so that one aspect of TDD that is somewhat Agile remains intact for BDD testing.
After reading through the other testing strategies and how to align testing with the Agile methodology, I realized that I’ve already been working in systems that operate like this at my summer internships. We operated our testing in a format pretty much identical to the concept of BDD where everyone in the team contributed to the different testing obstacles and even came up with test cases that would need to pass by code that was written afterwards. And like the article says, it was common for not all of the tests to pass immediately, and this is part of the concept of “failing fast” that Agile is all about. I am glad I found this article to give me more insight to how businesses around the world, including the ones I interned at, are converting to Agile and utilizing these testing strategies if they haven’t already.
Link to original article: https://www.qasymphony.com/blog/agile-methodology-guide-agile-testing/
Original Post: https://vsavkin.com/writing-angular-2-in-typescript-1fa77c78d8e8
This week I found this article on JavaWorld by Jeff Friesen that is entirely about polymorphism. Polymorphism is a core concept for all software development and a lack of strong understand will lead to weak applications and poorly written code. One can never revisit topics like polymorphism too much. This article discussing the four types of polymorphism, upcasting and late binding, abstraction, downcasting, and runtime type identification (RTTI). The article presents everything in the form of a code example and constantly revisits in the explanation process, which I find incredibly useful.
The first part of the article is an overview of the four types of polymorphism, coercion, overloading, parametric and subtype.. Of these four there are some bits that stuck out more to me than others. For coercion the obvious example is when you pass a subclass type to a method’s superclass parameter. At compilation, the subclass object is treated as the superclass to restrict operation. The simple example that is forgotten is when you perform math operations on different “number” data types like int’s and floats. The compiler converts the int’s to float’s for the same reason as the subclass to superclass object. Another piece in this first section that stood out to me was the overloading type of polymorphism. The obvious example here is overloading methods. In a class, you can have different method signatures for the same method name and each will be called depending on the context. Again, there is a simple example that is overlooked in the operators like “+”. For example, this operator can be used to add int’s, float’s, and concatenate Strings depending on the types of the operands.
The upcasting section uses our favorite example, different types of shapes and is almost entirely written in reference to one line of code, Shape s = new Circle(); This upcasts from Circle to Shape. After this happens, the object has no knowledge about the Circle specific methods and only knows about the superclass, Shape methods. When a shared method (implemented in both Shape & Circle), the object is going to use the Shape implementation as well unless it is clear through context to use Circle’s. Similar to this section that uses superclasses and subclasses, is the section on abstraction. The article uses the Shape and Circle example again but points out that having a draw() method that does something in Shape does not make any sense from a realistic standpoint. Abstraction resolves this, meaning that in an abstract class, there is no way to instantiate a method like draw() for the superclass of Shape. This also means that every abstract superclass needs subclasses to instantiate their behaviors.
These are just a few parts of the article that stood out to me personally. The article as a whole is incredibly useful and worthy of a bookmark by every developer. I will continue to revisit this article if I find myself lacking confidence about the topic of polymorphism in the future!
Original Article: https://www.javaworld.com/article/3033445/learn-java/java-101-polymorphism-in-java.html