For this weeks Blog Post I will be looking into the pattern known as “Study the Classics” where one is but to study the classics. The context behind this one is that you are self-taught or valued skill training over theory. The problem that would arise from this could be experienced people collaborating with you are constantly referencing concepts that they have assumed you read. But since you are value practice over theory you may have skipped over this reading/research. This will of course cause some problems, perhaps nothing serious but will lead to some confusion between the two parties. A solution to this is go back and study the classics if you will. If you were to pick up a book and think how old or out of date this book is, then you are probably reading the wrong kind of book. Successful apprentices will tend to focus on long lived books (classics) and use the internet or through practice to see how the information has evolved exactly. A classic they give in the excerpt is “The Psychology of Computer Programming” while this is “dated” wit h its punch cards and room sized computer parts the book was non the less relevant with is wisdom. Classics portray vital information to keep you heading in the right direction down on the Long Road, another apprenticeship pattern. By just focusing on classics you may take it to far and abandon more pragmatic knowledge and information that would enable you to improve your day to day craftsmanship. A simple remedy to this is to just mix the classics with modern, pragmatic books and/ or articles to your reading list. A way for this to act is simply pick up the oldest book in your pile. Or if you are looking through another developers book, take not of the oldest books and ask them why they still own them, sparking a conversation relevant to its wisdom it gave. Overall this is something I see myself doing down the road.

 

For this week’s blogpost I will be looking at yet another design pattern called the Prototype Design Pattern. Creating objects can take a lot of time and can be an expensive affair so in order to save time and money we can dive into cloning to solve this problem. You would want to use this pattern when the cost of the object to complex or expensive. After all, the clones in Star Wars were made to be cheap and expendable ultimately, the same goes for the idea behind the cloning pattern. Trying to keep the number of classes at a minimum is also a great time to use this object. Another big reason to use this pattern is when the client is creating objects that are required which are very similar to already existing objects, hence cloning. Essentially what this pattern allows you to do is make new instances by creating copies of existing instances. The result is a cloned object which is different from the original object, causing the state of the original to be the same as the clone right after the time of cloning. Therefore each object may undergo some state change, modifying the objects to perform different things after this is easily done. The structure of this pattern comes when the prototype class declares an interface for cloning itself by implementing the clone able interface and using the clone() method. Concrete Prototype then implements the clone method for cloning itself. After this the client class creates a new object asking the prototype to clone itself rather than using a new keyword. You need to instantiate the original class A(the class you are cloning) before using it. Then the client requests the prototype class for a new object of the same type as class A. This patterns great for scenarios where multiple profiles need to be created. In turn we can store the data in a single call and cache it in the session for further processing. Another more prominent example of cloning would perhaps be in the form of a bank account. Where you would want to make a copy of the object that holds your account information, perform transactions on it and then replace the original object with a modified one (a clone). The blog then goes on to list some more interesting points of the design pattern as well as some benefits and drawbacks. One of the drawbacks of the pattern is that classes with circular references to other classes cannot really be cloned. But a benefit of this pattern is that client can reduce subclassing with this immensely. All and all this pattern seems like something I would use actually quite often.

 

For this weeks blog post I found an interesting blog that listed 6 user testing methods that may seem unusual to others. User testing is a very important part of any good software project, it reveals any bugs you may have skimmed over or glitches for that matter because of this you can make a cleaner product. Using a prototyping tool to user test with interactives wireframes and high-fidelity prototypes you will know exactly how users interact with your app before the real thing is even built. If you were to publish something, then change it later it’ll be much more expensive to change the finished product than a product. The site goes on to mention computer-based testing software but goes on to say human testing is much better considering you are making something for humans to consume/use. The first method they list is participatory design, this essentially is when end users are involved from the very early stages of the design process, working together with you or the design team to define the product you make. Instead of the you are imagining yourself in the shoes of the user, you put the user in the shoes of designers. The second testing method they list is something bit unusual, Drunk people. This may not be the best but what they list is a pretty interesting idea. The testing method involves you testing you own wireframes. Interactive prototypes such as wireframes and more are the way to go when it comes to testing, these prototypes will help you introduce user testing throughout the various stages of development helping you along the way. The next testing method they list is Triading, which is essentially you trying to get the user to compare and evaluate 3 different alternatives without you influencing them with your questioning. The 5^th method they go on to explain involves the users creating their own user tests. Here they referenced a Ted talk by Luis Von Ahn describing massive scale online based collaboration. The final testing method they mention is product reaction cards which is almost as simple as it sounds. Essentially the user gets exposed to the piece of software then given cards with adjectives written on it where they are asked to describe the software using 3 – 5 of the cards. This is a super simple and helpful user based testing method that I like a lot actually. All in all this blog post was very interesting with all the simple user based testing methods anyone could conduct.

 

https://www.justinmind.com/blog/user-testing-6-methods-you-hadnt-thought-of/