Following this link will bring you to the apprenticeship pattern called “Expose Your Ignorance”: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch02s05.html

I really enjoyed this apprenticeship pattern because I have always been a strong believer in asking questions. That is what this pattern is about. Asking questions to people who have more experience, sharing the ideas you have and telling them when you do not completely understand.  I also enjoy the emphasis on exhibiting learning ability. I think that the most important part of working is improving yourself and never limiting yourself to the information you might learn.  Being open minded is important to learning. You always have to be looking for another way to solve a problem and work around obstacles. Without proactively learning you will fall behind in no time.

One thing in the pattern that really made me think about my process of learning was the paragraph that starts with “Expertise is a by-product of the long road we’re all on, but it is not the destination.” I never really thought about it that way. I always thought that expertise was my goal, but it doesn’t have to be. Going deeper into the passage, I think what they’re trying to say is that expertise is something earned int he process of learning. As long as you are capable of learning well, expertise will come to you in time naturally in something that is required or interests you.

One thing that I thought about while reading this pattern was “what about those people who hate questions?” In my opinion, I think that someone who gets irritated by (good) questions are close minded and don’t have much to offer. While they might have expertise they probably don’t have the skill to relay their information and therefore get frustrated.  Unfortunately, sometimes those are the only people you have for guidance and you may need to look elsewhere for extra help. Of course this pattern doesn’t take into account the person who you are asking question to and I didn’t expect it to, but it is something to think about.

This pattern has opened my eyes to the true learning process. Both parties learn from someone asking questions, so don’t be afraid to Expose Your Ignorance. I know I will be exposing my ignorance more!

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

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.