From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

https://dojo.ministryoftesting.com/dojo/lessons/testing-for-developers

This is the first time I’ve heard the ministry for testing’s super tester bros and from the Mario themed intro, I already appreciate the pure nerd culture of this podcast. They open the conversation with a discussion about a malware app, a clone of WhatsApp that tricked people into downloading spyware. This is a common problem, most searches bring up some kind of harmful software further down the results.

The conversation continues into various avenues revolving around security, particularly regarding a recent flaw in Apple’s sign in program. For a short period of time, anybody could sign in without credentials by clicking “Sign In” enough times with a blank username and password. This simple-to-use security breach is unexpected for a company as big as apple, since this is a type of problem could be avoided by better testing and coding.

At the 19:30 mark, they brought in two developers to talk about how they work with testers. Although the target in a dynamic software development environment is to release the product in working order as quickly as possible, they both express that there is a lot more value in collaboration over rushing. The quality of the end project doesn’t depend solely on the tester or the developer alone. Having a tester by the developer to share insight and do some “peer testing” will also help the developer understand how the further processes work, so he may be able to design around them. This will help save time in a project, since the developer wants the code to pass, or at least not fail, on the first few attempts after handing it to the tester.

Towards the end of the podcast, the hosts shared stories about encounters in their career. A typo was detected on the front page of a company that one of the hosts worked at. At the time, this error was given a low priority score since it didn’t actively change or effect the working order of the website, however, he reflected on how many people saw that typo and immediately disregarded the website as worthy of doing business with. In that way, this small error was in fact very high priority and greatly changed the effectiveness of the website to bring in customers in a way that had nothing to do with its true functionality.

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

http://news.mit.edu/2018/model-helps-robots-navigate-like-humans-1004

A paper describing a model where researchers combined a planning algorithm with a neural network that learns to recognize paths that lead to the best outcome, then use that knowledge to guide a robot through an enviroment.  The researchers demonstrate their model in two settings, navigating through rooms that have traps and narrow passageways or navigating through a room without any collisions. This learns by being shown a few examples of similar eviroments and then bases its actions on that. For example, if it recognizes a door it will know to exit through it based on the learned examples all exiting through a door. This model combines older, more common methods with this new look at machine learning. The planner creates a search tree while the neural network mirrors each step and makes a prediction based on probabilities for possible actions to take. If the network has high confidence of success it will act on it, otherwise it will fall back on exploring the enviroment like the tradititional method. One application for this model is autonomous cars where there are multiple agents all operating at the same time in the same space. For autonomous cars intersections and especially roundabouts are extremly challenging since there are numerous cars moving around a circle going in and out all at once. Results indicate that this model of machine learning can learn enough behavior based on previous experience to be able to navigate something as that challenging. In addition, they only needed a few examples of very few cars in a roundabout to be successful.

I find this article to be interesting since autonomous cars are going to be extremely popular in the future. This model is another advancement toward getting self driving cars even more independent to the point of something from a sci-fi movie. In addition to that, having something to efficiently navigate a room is important for other applications such as assisting somone that is blind. Something like this could give someone who has to rely someone else more independance if all they need to do is wear some glasses that tell them where objects in the room are located and how to navigate around them.

From the blog CS-443 – Timothy Montague Blog by Timothy Montague and used with permission of the author. All other rights reserved by the author.

In this Apprenticeship pattern “Emptying the Cup: The Deep End”, it explains on how you as a developer can further your development skills by taking on challenges that may or may not involve risks. Even though there may not be risks that can affect your career as a software developer, it may cause you to fail the challenge or objective you are trying to accomplish. Of course in any industry of work that you may wish to advance or climb the ladder in, you have to tackle on bigger tasks to show that you have the skills and mindset to be in a bigger and better position than the one you are currently in. However, failure can result in the process. The Apprenticeship pattern “The Deep End”, highlights that failure is normal when taking on challenges.

“This has risks. If you get it wrong and end up over your head you could drown. Thankfully there are many places in IT where you can take risks without destroying your career if you fail. Risks are opportunities seen through the half-shut eyes of fear. This doesn’t mean lying on your resume to get a job you can’t do, nor does it mean tackling challenges without adequate preparation. Instead, it means taking that promotion or foreign assignment when it’s offered, even if the very real possibility of failure is staring you in the face. Being prepared to fail and recovering from that failure opens doors that the timid will never see.”

Drowning in this context means failure and I completely agree with this idea because as an individual, I learn best by failing and making mistakes. At times, I can be scared to fail but I know deep down it is the best way for me to learn. This pattern also reminded me that feeling fear is okay when you I think failure is staring me right in the face because the after effects of failure is more of a gain for me when taking on a challenge than being successful on a smaller, simple task. After I fail a challenge, I reevaluate what I did wrong so I can approach it differently the next time I take that same challenge head on. This concept of taking on “The Deep End” isn’t only important in Software Development but it can be applied in any workplace.

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.

The “Record What You Learn” pattern suggests keeping a record of the lessons you’re learning during your apprenticeship in the form of a journal, a blog, or a wiki, so that you don’t have to figure something out more than once. You can also keep two records, a public version and a private version. This enables you to find other people interested in the same topics and get outside feedback, but also be honest with yourself about your progress if there are things you want to write down but would feel too embarrassed to post. The writers also advise you to go back and read what you’ve recorded periodically, so you don’t write stuff down and then forget it, rendering this pattern useless.

The action the writers suggest to start implementing this pattern is what we’ve been doing for this class this whole time: write down your thoughts about Apprenticeship Patterns and ideas it has inspired. I’ve found that in any situation, writing down what I’m learning does help to process the information. During my painful Data Structures course, I took notes from the book just to summarize the concepts and make them stick in my head. Additionally, it’s common wisdom that the best way to learn something is to teach it. If you’re making a public record, you’ll get part of the benefit of teaching it by having to put what you’ve learned into words easy for someone ignorant of the subject to understand.

I like the idea of having both a private and a public record, because I would feel hesitant to broadcast what I was learning if I was still unsure of my knowledge of it. I also like the idea of creating a breakable toy to store the lessons, because then the process of recording what you’ve learned will itself be a learning experience.

If in the future I find myself making the same mistakes over and over, I’ll know that it means I’m not writing down or reviewing what I’ve learned often enough. The time investment is worth it, because it’d waste a lot more time running into problems I’ve already solved and having to relearn their 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.

The Breakable Toys pattern addresses the issue of learning by making mistakes in an environment where failure is not an option.  This can mean that learning substantially more difficult.  The solution that they propose is to build yourself an environment in which failure is allowed to happen.  The apprentice does this by creating a pet project (even if it’s reinventing the wheel) and just trying things until something works or something sticks.

This pattern really resonates with me and the way I learn.  I can’t just pick things up by reading code or manuals, or copying premade solutions.  I need to get my hands dirty and build things.  Sometimes I’ll “sketch out” programs first by building a skeleton of files I know I want and adjusting as I go.  Sometimes I implement the core of code and let the rest of the program grow around it.  Neither approach is necessarily suitable for a professional environment where expectations may be high, but it helps me learn.

I also think that the Breakable Toys pattern can be applied in a more limited way to a more pressured setting.  While you might not be able to just declare failure when tasked with writing a section of code, you could take a couple of runs at it if the logic or the language involved are unfamiliar.  The main difference between this and Breakable Toys (maybe this is Partially-Breakable Toys?  Scratchable Toys?) is that you still need to deliver a working end-product in reasonable time.  The toy can’t be the whole assignment or program, but maybe it can be part of it.  This approach, however, doesn’t have the longevity implied by the authors.

I really appreciate that this pattern is in the book.  Playing with problems, writing code, failing, and then finding ways to do what I want to do is how I learn things.  It’s also a big part of what I love about software development.  Reading about something like the way I prefer to learn in a book like this makes me feel validated about my learning methods, like I’m on the right track.

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

This week I read the apprenticeship pattern “Confront Your Ignorance”, I chose this one because I thought it would be very relevant to me due to the fact that I am in a new role where many things are new to me. This pattern suggests that you do exactly what the name says, come face to face with the things that you do not know. Thus far, I think that this is one of the most valuable pattern mostly because nowadays, since the industry is constantly changing if you are not actively trying to fill in the gaps in your knowledge you WILL fall behind.

To relate this to my own personal work experience, I am currently trying to fill in the Spring gap in my knowledge. I have in a sense been “lucky” for a while since I have been able to avoid any tasks involving those tools, but my team uses Spring so much that my luck will eventually run out. If I do not confront my ignorance when it comes to Spring, then when I am assigned a task involving it I will harm my team. The other great benefit to this pattern is that, if applied, will make you an invaluable member of your team, nowadays there are so many technologies and components to learn that it is almost impossible to know them all so if you are constantly trying to learn more of them, then your value is constantly increasing.

Though this all sounds good on paper, in the real world I don’t think this pattern is applied because it is intimidating. We are comfortable with what we know, and we don’t like being thrown into a situation where everything is new, never-mind doing that intentionally! Also, I think another major hindrance is time, often times you are working on a major project that is taking up nearly all of your time making it difficult to find the time needed to learn something new. A solution that this pattern provides is starting small, you don’t have to do a very deep dive, you can start with an overview and simply learning the basics and that is what is the most promising for me. By learning the basic of Spring in the spare time that I do have, it will massively decrease my ramp-up time when I have to use it. In conclusion this is a very useful pattern that I will 100% try to apply in my software career.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – BenLag's Blog by benlagblog and used with permission of the author. All other rights reserved by the author.