From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.
Types of Testing
There was an article I found the other day that took a different approach on types of testing. The article is from ITpro, a site based out of the United Kingdom (http://www.itpro.co.uk/software-development/29994/types-of-software-testing). The author breaks down nine different types of testing. The article doesn’t try to state that the types are exclusive and that you should pick one or two and use those types. Instead it just breaks down the different types, the different times they are carried out, and who carries out these tests. Some are performed by the software testers during development and some are performed by the user to test different aspects. For example alpha testing is performed by the software tester before release to search for all possible issues and errors. Whereas beta testing is performed by the user in a deployed environment. It can be as controlled and closed off to as group of a desired size in order to test for real time failures. The control group is to ensure that it is not widely deployed across an environment and causing business failures. Beta testing is similar to acceptance testing which is performed by the customer to ensure the product meets all requirements and expectations set by the user and the developer. There is also a type of testing called security testing. This type is performed by a special team outside of the standard testing team and usually performed by security consultants. It is usually done to find out if there are flaws in the software that can allow it to gain access to computers or networks that it shouldn’t be able to and could cause damage to these networks. Another specialized type is stress testing. This is performed to push the software to its limits and usually beyond the normal operation that the standard user will put it through. This is used and needed to get a clearer picture of what your software can do and what the limits are. The one type that stood out to me the most and struck my interest was smoke testing. This is done when a new build is sent to the testing team. Simple tests are performed to find out if it crashes the program indicating bigger issues. It makes sense to do, before digging deep into tests to just run quick simple tests to see if it can even pass that stage. It just never occurred to me to make sure to do this step first before fully jumping into alpha testing. I think that reviewing the different types of tests every once in a while to remember that there is a full spectrum of testing and how important the testing process is to software development.
From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.
A SOLID Foundation
https://softwaredelivered.wordpress.com/2013/06/03/way-to-patterns-even-more-solid/
Linked above is the article I used for this week’s professional development blog post.
This week, in a continued effort to improve my fundamentals with Object orientated programming, I reviewed the five principles of SOLID. In doing so, I found a popular resource. The reason I chose this one for review though is that it cover’s every principle. And, each principle comes with examples in code and explanations of how the principles should be applied to programming.
Having all of the SOLID principles explained in a single place was attractive because I had no exposer to them before this class. This also means that nearly all the information within the web page was new to me.
Similar to the principles of GRASP, SOLID is fundamental to designing and writing code. It’s five principles (Single-Responsibility principle, Open-Closed principle, Liskov substitution principle, interface segregation principle, and Dependency Inversion principle) all contribute to making code much easier to refactor. Adhering to these principles means the subsequent software will be easier to maintain and extend. This is vital because all software I produce will need to be refactored. Both before and after it’s “finished.” So, for both my sake, and any other developer, it’s worth making sure I’ve understood these principles well. After reviewing and learning what each principle was, again just like GRASP, I was able to see how my past projects have embodied these principles. In fact, many times I was working with towards achieving these principles with my projects or working with them in mind without knowing they had a pneumonic device. In fact, many of the mottos of Object Orientated design are expressed in SOLID. Take the first principle of SOLID, Single-Responsibility. Simply put, it means any class or module should be only concerned with a singe part of the program’s functionality and that the functionality should be encapsulated. This immediately reminds me of “encapsulate what varies.” Adhering to this principle makes the code a lot friendlier to refactoring since a class would only be concerned with a single function or behavior.
Just like the first, all of the principles are the foundations to good code practices and many common design patterns. With this being the case, I can see that this is a subject I know in my sleep.
From the blog CS@Worcester – W.I.P. (Something catchy) by aguillardcsblog and used with permission of the author. All other rights reserved by the author.
How much time to spent during Code Reviews
Last week, I wrote my blog on Code Reviews. This week I am writing about how much time we should be spending during Code Reviews. I found an interesting article titled “Don’t Waste Time on Code Reviews” on DZone written by Jim Bird.
According to the article, research shows that reviewers find far more maintainability issues than defects (a ratio of 75:25) and spend more time on code clarity and understandability problems than correctness issues. There are a few reasons for this. Finding bugs in code is hard. Finding bugs in someone else’s code is even harder. In many cases, reviewers don’t know enough to find material bugs or offer meaningful insight on how to solve problems. Or they don’t have time to do a good job. So they cherry pick easy code clarity issues like poor naming or formatting inconsistencies. But even experienced and serious reviewers can get caught up in what at first seem to be minor issues about naming or formatting, because they need to understand the code before they can find bugs, and code that is unnecessarily hard to read gets in the way and distracts them from more important issues.
Code reviews add to the cost of development, and if you don’t do them right they can destroy productivity and alienate the team. But they are also an important way to find bugs and for developers to help each other to write better code. So do them right. Don’t waste time on meetings and moderators and paper work. Do reviews early and often. Keep the feedback loops as tight as possible. Ask everyone to take reviews seriously – developers and reviewers. No rubber stamping, or letting each other off of the hook. Make reviews simple, but not sloppy. Ask the reviewers to focus on what really matters: correctness issues, and things that make the code harder to understand and harder to maintain. Don’t waste time arguing about formatting or style. Make sure that you always review high risk code and high risk changes. Get the best people available to do the job – when it comes to reviewers, quality is much more important than quantity. Remember that code reviews are only one part of a quality program. Instead of asking more people to review code, you will get more value by putting time into design reviews or writing better testing tools or better tests. A code review is a terrible thing to waste.
I would say that the title was somewhat misleading though. I wish the title was less misleading, though – it’s easy to read as “Don’t do code reviews,” which isn’t what the post was saying. I think the title was either poorly worded or it was written that way intentionally as click bait. I think a better title would have been “Don’t Waste Time During Code Reviews”. I was spending lots of time reviewing code that a static code review tools can do. Form now, I would rather use tools like FindBugs and PMD which uses static analysis to look for bugs.
Source: https://dzone.com/articles/dont-waste-time-code-reviews
From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.
Encapsulation, More Than Data Hiding.
For my last blog, I revisited the important concept of polymorphism. For this post, I decided to revisit another important concept, encapsulation. I wanted to find a similarly formatted article/blog post to the one I found for polymorphism, but wanted to get a different perspective from a different resource. I wanted a source that still mixes in code examples,
Let’s start with the definition of encapsulation. Encapsulation is the ability to package data and related behaviors, in an object. This also includes the access permissions for the behaviors within the object. Encapsulation is often used a synonym for data hiding, but it’s important to acknowledge that while encapsulation includes data hiding, this isn’t all that encapsulation is. Everyone thinks of encapsulation as the concept of public versus private variable types. The concept of encapsulation does include this concept, but this is only one area that relates to encapsulation. When creating a new class, encapsulation should be a top priority. This is because with encapsulation, maintainability is drastically increased.
To further explain that encapsulation is not only data hiding, the article uses a classic coding example, an animal class. The class contains several attributes (name, type, height, color) and behaviors (hunt, run, mate, getName). Encapsulation is more than just making sure the attributes are private, it is about bundling the attributes and the related behaviors within one class. We could have the hunt, run, mate, and getName behaviors all in separate classes theoretically, but this would just be poor design. The article also notes that encapsulation is not about getters and setters. While these behaviors are related to the attributes, the authors wanted to make sure readers didn’t confuse encapsulation with this concept. Encapsulation does include getters and setters, but they are not the focus, instead we should focus on the behaviors that return a different value depending on the attribute, instead of just returning the attribute or setting a new value for the attribute.
To explain how I would use this in the future, why not explain how I would expand upon the code example used in the article? This code example in the article only includes hunt, run, mate, and getName for behaviors. If we wanted to add a speak functionality to our animal, we would use encapsulation. This might mean adding a new private variable, but also would include adding a new method that depends on an attribute or several. This behavior and additional attribute(s) would be added to our animal class to encapsulate the data and behaviors, and ensure the best maintainability for our codebase.
I found this article to be simple but powerful. It’s easy to forget that encapsulation is more than data hiding. Encapsulation is one of the major concepts of object oriented programming and complete understanding is necessary for success. I’m sure I’ll get interview questions regarding this topic in the future.
The original article: https://javapapers.com/core-java/java-encapsulation/
From the blog CS@Worcester – Learning Software Development by Stephen Burke and used with permission of the author. All other rights reserved by the author.
11/27/2017 — blog post 10 CS443
https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/
The last two blog posts on code review have discussed about suggestions for improvements, its overall advantages, and a general overview of what exactly it is, this weeks blog post on code review will focus on the statistics. In general, the post lists 11 proven practices based on experiments and surveys from experienced software developers that has helped team members improve code review abilities. Why is this important? Suggestions from experienced developers are based on experiences, but this post crunches up the numbers in case studies to demonstrate its effectiveness and to suggests 11 proven practices based on the statistics. This is why I chose this article this week in order to emphasize the importance of code reviews.
In my opinion, this article is one of the best I have seen so far for providing suggestions for code reviews and crunching out the numbers as well. As introduced, the suggestions from this post were compiled from code review studies and collections of lessons learned from over 6000 programmers from over 100 companies. The main issue with code review as suggested in the article is efficiency that is reviews often are too long to be practical. The conclusions from the article were from 2500 code reviews, 50 programmers and 3.2 lines of code at Cisco Systems. The study tracked the production teams with members in Bangalore, Budapest, and San Jose for 10 months.
The first suggestion is to review fewer than 200-400 lines of code at a time. The cisco code review study revealed that the optimal range for finding defects is 200-400 lines of code at a time. After that, the ability to find defects decreases. The statistics is that if 10 defects existed, it is likely that the team will find 7 to 9 of them. What is interesting is the graph shown in figure 1 of the defect density against the number of lines of code under review. According to the graph as the number of lines of code under review increases beyond 200, the defect density drops off considerably. So, the optimal effectiveness is from 200-400.
The second suggestion is to aim for inspection rates that are fewer than 300-500 LOC per hour. The inspection rate measures how fast the team is able to review codes. According to figure 2, the effectiveness of inspection falls off when more than 500 lines of codes are under review. Finally, the last interesting point is to never review code for more than 90 minutes. The article suggests that developers take enough time for a proper, slow review, but no more than 90 minutes. It is generally known from many case studies that code reviews after 60 minutes just diminishes in productivity, effort and concentration. Most reviewers simply gets tired and stop finding additional defects. Some will probably not be able to review more than 300-600 lines of codes before their performance drops. So, the rates of finding bugs deteriorates after 60 minutes. Overall, code reviews should not last more than 90 minutes.
I chose this article because the suggestions were too good to pass up a blog post. I find the first 3 suggestions to be helpful to keep in mind when code reviewing as effort always diminishes with time.
From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.
Approaching Complex Code
So for this week, I have decided to read “Code Smells: Too Many Problems” from the Jet Brains and Intellij Idea blog. The reason I have chosen this blog is because while I have my experience of parsing codes, I do need another way to approach complexity. It will help in figuring out the simplest step to take first when there is complexity in coding and not be overwhelmed by it.
This blog post basically goes over three approaches that is figuring out how to tackle complex code. Each of the approaches have their pros and cons. The first approach is simple but effective to do and that is break down the method into smaller sessions. While it might help for methods with multi responsibilities, it does not make some other smells more approachable to work with. However, it also does help in determining when is the right time to refactor. Second approach is to work on one smell at a time. It is a variety of steps that the author has showed to get this point for the series of code smells. This is the less risky and easier to reason approach that gives simpler code. The third approach is to step back and try to model the problem. Instead of looking at individual smells or individual lines of code, this approach introduces new domain objects to model what is happening in the code. It encourages a bit of redesign and may lead to new classes that can help with other areas of code, but be aware that it will have the same problems as the other two approaches if not used carefully.
Based on the contents of this blog, I would say this was a pleasant read on getting started in tackling complex code. The author was able to show how the approaches work with a sample code and addressed the drawbacks from it. It was easy to understand and has the What I did to getting started is to write down one method at a time and try to refactor it based on the design it has been used on. Sometimes I would try to write down comments if I do need to have a clear reminder of what I’m trying to do while refactoring.
What I learned from this blog is that if breaking down the methods and refactoring happens to lead to an inconvenient end, then perhaps undoing a few steps back is not a bad idea. The idea I have gotten from this blog is that all the tests should pass, and commits should be small, but very frequent. This helps in making sure that it is easy to stay back and not having to be in a place that can lead to a complete halt. For future practice, I shall try to use the rule of three that will help in determining if a method is needed to be broken down into smaller pieces.
Link to the blog: https://blog.jetbrains.com/idea/2017/09/code-smells-too-many-problems/
From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.
Video Game Career Tips
I love video games and the prospect of making a career out of them has always been a dream that I believed too good to be true. However, the game industry has been on the rise for decades and increasingly proves to be a real career choice with the added benefit that even a small team can produce something that stands out. With this dream in mind, I’ve read the following article on how to get started in the game industry with advice and interviews from current game developers.
The first question asked to the panel is “What is the best way to start making game?” To which many emphasized the importance of learning the basics of coding. While some game development tools allow you to get started with little coding knowledge, its unavoidable that you eventually learn a programming language or two, C++ is recommended specifically. Game developments tools such as unity, RPG maker, and game maker studio help significantly with transferable concepts of what goes into making a game.
Another question was “If someone is looking to set up a small studio themselves – what advice would you give them?” A few panelists strongly advised not starting a studio early on and that a better choice would be getting experience in an already established studio before gaining the confidence to branch off on your own. However, if you were to start a studio you absolutely need a great programmer as well as an artist. Also it is very important that you have a team member who knows the business of the industry. Byron Atkinson-Jones shares that “the making of the game, that’s actually the easiest part. Managing things like business finances, making sure you can all eat regularly, marketing, PR, legal stuff, QA and selling the game once it’s done are the hardest.”
The next question asked was “Are there any key skills that people should have or things they should know that aren’t obvious or aren’t taught on design/coding courses?” To which many of the panelists stressed the importance of communication within a team. Learning to be a nice person while being open to criticism for the sake of the project are invaluable traits that cannot be taught in schools. You could be very skilled and experienced but if you don’t get along with group members and refuse to communicate effectively, your project will suffer greatly.
The last question ill go over in this post is “Is a degree in computer games programming or design a necessity?” The short answer from most of the panelists is no, you can go a long way with passion and devotion to video games as long as you have the portfolio to back it up. Aj Grand-Scrutton expresses that “a degree is effectively gravy compared to an actual portfolio” emphasizing that real experience dominates over just having a degree.
From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.
Re: Angular, TypeScript and Final Project
My teammate and I are currently working on a Blackjack card game, which we will present to our class during finals week. I’ve spent the last few weeks trying to become more familiar with Angular and TypeScript for this project, and I believe I am starting to make some good progress. For instance, I have figured out how to build a card deck, shuffle it, and display images of these cards to the user.
There is a great online instructor named Mosh Hamedani with a series of tutorial videos for both Angular and TypeScript. I’ve already watched several of his videos and found them extremely useful and informative. The instructor has a personal blog as well. I would like to discuss one of his blog entries in particular, entitled Angular 4 in 20 minutes.
First, a disclaimer. I certainly did not learn Angular in 20 minutes, but Mosh’s insight and clear explanations are helping me understand Angular and TypeScript concepts more than any other tutorial I’ve tried so far.
Mosh’s blog entry is a synopsis of one of his free tutorial videos, which is approximately two hours long. I’ve watched the entire video twice already and I believe it is definitely worthwhile to anyone who is trying to learn Angular and TypeScript. Here are a few important points that Mosh brings up in his video synopsis:
He explains that Angular is a framework for building applications in HTML, CSS and TypeScript/JavaScript. He also answers the question of why a developer would want to use Angular rather than other alternative methods. I have to agree with Mosh here that learning TypeScript with the Angular Framework seems a whole lot easier than, as he puts it, “vanilla JavaScript.” I believe this is due to the “IntelliSense” offered within Angular and TypeScript which is currently unavailable in JavaScript alone. When comparing TypeScript code side by side with JavaScript, in my opinion, the former is much easier to understand than the latter.
Mosh also goes through a step-by-step process on how to install everything needed to run the Angular framework, including how to create a new application project from the terminal. Next, he uses MS Visual Studio to go through the project layout and explains every single file that was created, including their functions and purposes. He then demonstrates how to generate new components within the project and how to connect them with the main application module.
The free video posted in Mosh’s synopsis blog entry is part of a 30+ hour long Udemy course video compilation that typically costs at least $200. Fortunately, there is a great “Black Friday” sale going on where I was able to purchase this entire course for just ten dollars. I feel I am making great progress in learning Angular and TypeScript; I honestly believe it would have not been possible without his videos and blogs. I am certain I will continue to reference Mosh’s insightful blog entries and tutorial videos, and apply what I’ve learned from him during my professional career.
From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.
#7_343
From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.