https://www.codingblocks.net/?powerpress_pinw=2994-podcast

This week I listened to the CodingBlocks Podcast Episode 67 titled “Object Oriented Mistakes.” Over about two hours the three hosts, Allen, Michael, and Joe discuss common mistakes and various programming problems that are easy to run into. I chose to listen to and write about this podcast because all of the programming I’ve done so far has been object oriented, so this was an easy opportunity for me to learn.

I picked up on one example they used early on while talking about the concept of BaseBean. BaseBean is when a class is implemented without falling under the category of “is a” for the parent. The example was if you were creating a car class including physics based attributes such as speed and weight, then creating a bullet class that inherits from it. This saves time in the short term since a bullet has attributes like speed and weight as well, however, a bullet is not a car and therefore you can easily run into problems later. Say you now wanted to put a new attribute into a car, like seat belts which no bullet should ever have yet it is inherited anyway. This can also be confusing for other developers looking at your code, assuming that bullet is some type of weird new very very small fast car for ant people. A good work around this common mistake is to only inherit things that fall under the “is a” category for the parent.

Next the hosts talked about how it is common to wrongly call the super method. Having to call super means that there is something in the parent class that is meant to be changed by its children. A common inefficiency occurs when a programmer sees they must remember to always change some common inherited method from the super class. Quoted by Martin Fowler, “Whenever you have to remember to do something every time, that’s a sign of a bad API.” This can be fixed by implementing template methods with the concept of the Hollywood principle, “Don’t call me, ill call you.”

So what I’ve learned from this podcast is in the future, I will remember specific common errors like these and know how to solve them. There are many other topics the hosts of CodingBlocks talk about in this episode, so i suggest you go listen to it if you want to hear more. Their content is interesting, their personalities are likable, and they have plenty of episodes to choose from with more continuously coming out.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

The blog post this is written about can be found here.

This blog post by a software engineer working at Facebook outlines several anti-patterns, including examples, why they’re bad, how to avoid them, and why it’s difficult to avoid them. I chose it to read because of the obvious connection to the course material, my continuing desire to avoid bad practices, and the fascinating connections the blogger makes to the cognitive biases that explain why we fall into these traps.

Some of the anti-patterns are time-wasters, like bikeshedding and analysis paralysis. Bikeshedding is described as the tendency to spend a disproportionate amount of time debating unimportant details. The blogger suggests flipping a coin or voting when you notice this problem arising. You can resolve to revisit the decision at a time when it’s more relevant, as long as you get the decision over with quickly and move onto more important ones.

Analysis paralysis is analyzing so much that it impedes progress. The blogger suggests that this anti-pattern crops up due to information bias and validity bias. Information bias is defined as the belief that you can make better decisions the more information you have, regardless of whether the information is relevant to the decision. Validity bias is overestimating how accurately you can predict an outcome based on a set of information, even if that information is unreliable or outdated. These can lead us to the belief that more analysis will be useful, even when it won’t. His solution to this anti-pattern is more iterations of code. If you go ahead and try something, you can see actual outcomes and modify your code accordingly, instead of endlessly speculating about outcomes.

I also took note of several class-related anti-patterns. These include the god class, a class that knows about and/or controls too many classes; fear of adding classes, the avoidance of adding classes due to a misconception that they will make designs more complicated; and the poltergeist class, a useless class that ought to be eliminated. The solutions for the first two seem to contradict the solution to the last one, but taking all three into account leads to a clear picture of how to properly use classes.

For the fear of adding classes, the blogger gives a useful example of a tangled ball of yarn to represent too few classes. Adding classes can instinctively feel like adding complexity, but simplifying your design with additional classes is akin to separating the yarn into individual strands. Similarly, the god class can be broken up according to the single-responsibility principle, giving classes only one clearly-defined responsibility. Poltergeist classes lack a clear responsibility; they often only call other classes or add a layer of abstraction that isn’t actually necessary. When you create a new class, you should make sure it actually has a valuable role and simplifies the design.

Hopefully, having read this, I will be able to recognize these anti-patterns in the future and apply their relevant solutions.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Today I read an article on coding-geek.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.

Source: http://coding-geek.com/how-does-a-hashmap-work-in-java/

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

In this blog post, Marcus Biel gives his thoughts on clean code, what that is, how to implement, estimate, and accurately design good software that does exactly what it should and nothing more. What is clean code? The author writes,

“It’s the idea that your code should be precise and as close to perfect as possible. If you have more code than you need, it shouldn’t be there.”

This concept relates to YAGNI (you ain’t gunna need it), and is an essential part of having clean and readable code. Adding features that might be needed later is a good way to bloat your code and run into bugs. Clean code requires time to fully understand the problem, this is sometimes tough when working in an environment where you are being pushed by those who don’t understand what goes into software design. Sometimes you will be asked to meet deadlines that will make you rush, in turn you can end up with poorly written code. The language and wording in code is also very important, using variables and names that are clear and make sense help others read and understand what is going on in your code. I selected this resource because having clean code is a huge part of being a good programmer, along with tips on clean code, the author has tips on designing code by running tests first, working with co-workers and clients to understand what features are most important, and what features are not beneficial.

“To me, being a software craftsman is about having a focused attitude and about taking responsibility for your code, your job, and your time. So, from beginning discussions to end results, your one focus should be on maintaining your own high standards and creating the best possible product for your client.” – Marcus Biel

This post had a good amount of information and insight on clean code, and being a good developer in general. Important aspects from the post I think are being clear when naming variables, methods, and classes, leaving out code that is not needed (YAGNI), and making accurate timelines for projects. Rushing to write code before you fully understand the problem can lead to more problems down the road. I expect to use concepts of clean code in my professional career, I believe it’s very important to make a good product that will benefit you, your company, or your client.

The post Clean Code Principles appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

We’ve discussed quite a few different testing techniques, so I would like to offer some personal reflection on what we’ve learned so far. Udemy has a great blog highlighting many of these techniques; it is entitled Test Design Techniques You Need to Know. I will summarize some points from Udemy’s blog which I feel directly relate to what we’ve discussed in class so far.

Udemy begins by explaining the concept and importance of Software Testing, which I feel is an intricate part of Software Development itself.  As we’ve learned in class, we test our software to ensure the quality and integrity of our products. We want to be able to detect and fix any flaws in our products before they reach the consumer.

Udemy classifies testing techniques as a whole into two general categories: black-box and white-box. We’ve learned in class that we do not need access to the actual code to perform black-box testing of a product. In contrast, we ought to have access to the program’s internal structure and/or source code to perform testing techniques in the white-box category.

Many of the techniques we’ve discussed in class seem to fall within the black-box testing category, so I will focus primarily on that category. Udemy lists some techniques of black-box testing, three of which sound very familiar due to what we’ve done in class:

• Boundary value analysis: This is where we test the lower and upper limits of possible inputs. After finishing a class project and reading thoroughly about this technique, I feel that if our code is going to fail, there is a significant chance in finding these errors somewhere close to the minimum, nominal, maximum range.
• Decision table testing: Udemy describes this as evaluating conditions of our code within a table, where every decision correlates with a relation, predicate or variable. The blog cites this technique as “providing great confidence in the test cases.” I tend to agree with this statement because as we’ve learned in class, decision tables are good at analyzing complex logical relationships within our projects.
• Equivalence class partitioning: We use this technique to partition a complete set into subsets, and test each of these “equivalence classes.” Since we’re partitioning the sets, I believe this technique can be used as an efficient way of reducing the total number of needed tests as a whole.

Udemy concludes by explaining that a decision test design technique is the best way to obtain absolute logical coverage. I would like to learn more about this topic; perhaps we will be discussing it in class soon. The blog also emphasizes that we ought to use boundary value analysis and equivalence partitioning to cover a wide range of inputs.

After reading Udemy’s blog, I am convinced that all of the summarized techniques are used everyday in Software Development as a whole. Thus I am confident I will be using many (if not all) of these techniques in 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.

https://www.toptal.com/freelance/why-design-documents-matter

This week I read on why writing a software design document matters. This blog goes through the steps of what is needed in a design document. The program idea could start with a call or Skype meeting between the programmer and the client, with the client telling the programmer what he wants in the programmer. The programmer is then left to create the program once and outline is created, and meets up with the client one last time when the program is finished to make sure it is what he wants. Chris Fox, the author of the blog entry, goes through each of the steps with a brief summary and a picture or diagram of what each of the steps would look like. The specification of a software design document show that the design goal of the project is going to be. This is created by the developer and the client on what is needed to be done and how the program or in this case application should work. The interface is the framework of the application. This is also the most problematic trying to get it to look perfect to what the client wants. Functionality how the application works and what it is supposed to do. Milestone, what the application is supposed to do once finish. The blog also gives examples of outlines for the document which features all of the steps. The outline should include the goals of the program, the function of the program, the users’ interface, and its milestone.  The author’s example of a UI description that he used was for an app used on an iPhone. The description included a navigation bar that controlled the app and where to go to different locations of the app, and a table of a layout of what will appear on the screen of the phone, including images and texts. Steps may change overtime as the application is being designed and programmed. The author gives us these steps and what to do as an example of a free lancer with one client.

This was another interesting blog. This blog showed another reason why we need a design map or outline for any programming. The diagrams show how the steps for the outline works, whether it is written on paper or typed up on the computer, both show the outline for the program and how it is expected to run for the user. Not only does this design work for programming site, it also works with programming applications. This shows that you need a design outline or diagram before creating any kind of program. This blog gives another method for designing a program. I would probably create an outline of what the program needs to do and how it should run, create a UML diagram for it then try to create the program itself.

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

After the last post my mind has been on the future of software testing, but after a week or so it’s taken a bit of a journey and now I’m wondering about my future in software testing. And as it usually does when I think of the future, negativity is on the forefront. Which is why potential pitfalls are something I’m really interested in. So wonderfully, I found a helpful post on Awesome Testing listing possible software testing traps and describing them. The ‘traps’ in this case are mistaken implementations or uses of software testing that lead to very unfortunate results, based on the authors own experiences and what he has read or discussed with others.

It is incredibly interesting seeing the ways companies mistakenly attempt to optimize use of testers. Rating them on the amount of bugs found or incentivizing them to find as many bugs as possible only were issues that seem obviously awful to me, but I have hindsight on my side. A good amount of the traps were something I didn’t consider, issues with not having developers do any testing themselves. By leaving only testers as the ones to run tests and do quality assurance, it led to developers using testers being turned into scapegoats for issues or testers becoming a commodity that is moved around too often to do their job correctly.

Trap number three shows the human side of the process, to me at least. If testers make bad tests and have to constantly fix them, or the tests offer very little information due to their issues, then developers become disillusioned with them. It becomes safer and more likely for the tests to become more and more ignored. Software testing is not just finding bugs in programming, it must do so reliably and in a way that aims for improvement. Developers and testers are also not as  clear cut as one would think. Or they shouldn’t be, at least.

I feel much more confident now knowing many of the issues that one can accidentally fall into in the process of software creation and testing, and how to possibly avoid them. I also found the idea of testing not simply being about finding bugs, but just a part of a greater system working towards an end goal of a wonderful software product insightful. It is incredibly useful to understand the full Software Engineering Life-Cycle no matter where your job lands on it.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

This week I have decided to read about “Design Smells” from Bartek’s Coding Blog. So, while   this blog is rather short, the reason why I have chosen this one in particular is because recently in my studies, my biggest question that how do people figure out the errors of a design without testing or even refactoring. I want to understand the logical thinking in recognizing the errors that point to a wrong design.

This blog post basically goes over seven hints of design smells that points to places that the code is not going as intended. These seven hints are rigidity, fragility, immobility, viscosity, needlessly complexity, needlessly complexity, and opacity.  For rigidity and fragility, they point to the belief of a simple change will fix everything but other unexpected things can happen and the code can fall into pieces. Immobility and viscosity, on the other hand, point to “moving” and using codes to be improving the design but preserving it while implementing new features might be difficult. Needlessly complexity and repetition are easy to understand. They point to implementing something complex and copy and paste that is not needed at all. As for the last hint, Opacity, points to making a code clear and easy to understand.

So, based on the blog post with the insights I find behind it, I would say this was a simple but interesting blog to read. The author explained each of the seven hints with a simple take of every day programming work while giving the literal term along with it. From my experience in finding something wrong in a design, it’s usually testing which takes a considerable amount of time depending on how much writing there is into it. If there are unrelated errors occurring within testing, then it would be where I will try to figure out which part of it is the source of the problem and then try to debug it as much as possible.

From this blog about design smells, what I learned is that to avoid conflicted attention described by the hints, there should be consideration always in preserving the original design codes. The ideas that I have been taught is while it might be inconsistent to use the codes like that, there is no need to be “afraid” in both using general codes for future reference and bending the original design a little to improve the programming process. Learning the ideas from this blog shows me that for future practice, I should try to find features implemented in designs and trace down codes that give a complexity on the urge of repeating itself. That way, I can try to get the simple thinking of identifying problems without having to recreating codes like that. With this knowledge, I hope to assist others with great analyzing and fix codes better than I used to.

-Dennis Tran

Link to blog: http://www.bfilipek.com/2012/11/design-smells.html

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.