The white belt as an apprenticeship pattern is what it sounds like. You are at the beginning of your journey and have a deep understanding of your first language. The problem arises when you are struggling to learn new material and it is harder to piece things together than when you started learning your first programming language. The author relates the solution back to Star Wars quoting Yoda, “You must unlearn what you have learned”. By doing so, this accelerates the learning process because you don’t try to relate things back to your current language but instead connect neurons together when trying to understand the new concepts you are learning.

I agree with the many things the author taught in this apprenticeship pattern. That too is how I learn new tools and technologies on my own but on the other hand, I always try to relate it back to my strongest, most knowledgeable language, and see if there are similar concepts and if there are ways to carry out a task more efficiently.

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

This post is connected to my previous post, “The Long Road”. What happen if we were following our dream road, the road we versioned in long-term. But there a limited subset of all possible career paths. You don’t know if this road is longer fit you. You are looking for a path of your own. There are many difficult come with change a path, you are putting your career and your future on new line. But you also don’t know your limit of possibilities.

“A Different Road”, when the road that you draw is leads you away from the main road. You found the new opportunity with new reward, something that you are attract to. But this mean you have to take a turn away from your craft. There is also all the worry of life responsibility, specially family. This will make our choose much more difficult. In this pattern, they suggest despite this risk, don’t be afraid to do something different with your life. I am agreed with taking change and do with what you love. But the situations are different with everyone. It is hard to tell them what to do.

We will have this situation to our life, the people to support around us also are the big factor. We surround by people with different opinions. It is important to listen to who truly support us and with different point of view. They able to help us to feel confident to take that step. The true supporter is the one who stay with you no matter what and will tell you their honest opinions. Although I always thinking about this subject. This pattern tells from another point of views, talk to people with different job. Ask them what they love about it and compare that to the things you love about software development. Go with whatever you see yourself in.

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

This week I read through Kindred Spirits from Chapter 2. This pattern is reflects on the stage of life of an apprentice who feels like they might not fit in entirely well with a company’s culture, perhaps because they have different interests or a different level of enthusiasm. Perhaps your organization is not very tight-knit and you’d prefer it to be. The solution is to make sure you reach out to meet those who are like you, and that you actively stay involved in what those people are doing. Read books, remember names, and attend meet-ups. Even getting coffee from time to time and discussing ideas can help immensely when your work life isn’t feeling satisfactory. You may even find yourself in a spot where you are offered a position to work alongside those kindred spirits who are just like you.

I found this pattern pretty interesting because, due to graduation coming up, I personally have been pretty concerned about finding a work environment that I really enjoy — as I’m sure everyone is from time to time. I know that I’m someone who seeks to get involved in the places I spend my time, and that if I join a company it is important to me that I’m not coming into work, getting things done, and then leaving. I want to find coworkers that I connect with, work that I can get invested in, and people who are enthusiastic and encouraging. From what I’ve heard and from what the chapter suggests, organizations that a truly encouraging are often few and far between. It may not even be the entire company, it could just be that those you who associate with on a day to day basis are not quite as enthusiastic about your work as you are. As a result, I really enjoyed the tips that this pattern suggested. Make sure you remember those who are similar to you and who have shared goals in mind, and that you keep those people as close as possible.

It’s important to keep track of who you meet, who inspires you, who knows what you know and is passionate about what you’re passionate about. Make lists of communities and try to get involved in them. One thing I’d like to do personally is to attend some software conferences — I know there are plenty and I know many are not outrageously expensive, so it’d be a really great way to meet people and make connections. It’s important to keep those you you mesh well with close to you, as those people will provide you with opportunity and friendship like no others.

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

A lot of the times in the office, people can get easily frustrated with their tech. This article talks about how there seems to be some sort of disconnect between the technologies and the doctors. To start off, when a software is developed for a certain field, there are certain expectations and requirements that should be met depending on what the service is for. if you are delivering a software for a food business, you should expect it to handle some sort of client interaction along with employee interaction. This also can translate to mass scales where more and more people are using it. When a lot of people are using the same software, there should be a type of initiative to make it simple yet effective to use. If the software that is being developed for a specific purpose isn’t developed correctly or with those things in mind, it can sometimes be detrimental to that business’s practices. In this case, it was a matter of updating a lot of records and technology to keep the systems “relevant”.

In the case of a hospital system, the records are computerized and the new system that was being put in place would be able to handle a lot more. This is the reason why the upgrade was good. The new system would be able to deliver a single platform for recording and communicating medical observations, sending prescriptions to a patient’s pharmacy, ordering tests and scans, viewing results, scheduling surgery, and sending insurance bills. However, with these new systems seem to come a lot of overhead for the people using it. There were quite a few tensions that actually made it more difficult for doctors to get their jobs done. One of these tensions was between the doctors and administrative staff. Often times they disagree on what should and should not be included in the software. Sometimes the staff said adding certain procedures would be more time consuming. Certain fields that doctors didn’t have to fill out before were now being required due to administration simply telling them that they had to be done.

I feel as though the real customer in this situation seems to be the administration. Whenever a new system is implanted, hospitals often have to schedule less appointments just to accommodate for training of the new system. This puts, not only the patients, but doctors and other faculty way behind. From the article, it states that in the first five weeks of a new 1.6 billion dollar system upgrade, there were about twenty-seven thousand help desk tickets were just simple how to questions about the system. The lessons from this implementation don’t only apply to the Electronic Medical Records systems, but other systems dealing with these same mass software upgrades for facilities similar to hospitals. This reading has changed the way I think about the topic because although upgrading something to make it current, doesn’t always necessarily mean it won’t add additional overhead. I agree with the fact that upgrading systems can be important, especially when dealing with thousands of medical records because you want to keep things secure. But at the same time it is important to understand that there should be more efficient ways of training with these software to make them more accessible and understandable for the people using them.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

The next apprenticeship pattern I took on was Draw Your Own Map. The premise is simple: you are the only person who can choose the paths you go down and which roads you travel. You should not leave yourself to the mercy of your situation and those around you to determine the course your future will take. Is is a definitely a pattern of self-determination.

The Draw Your Own Map pattern is absolutely useful. I have always been a person who has difficulty relying on others. Although I acknowledge this as a weakness in most ways, one way it has strengthened me is I usually don’t find myself depending on others for approval or assistance. If I want to do something with my life, or make some future plans, the only person I ask is myself. This independence and selfishness is important, in my opinion. There is only every going to be one person looking out for your best interests: you, and so therefore it is your sole responsibility to map out your future and make the decisions that will lead to your happiness.

Despite this, I do think there are limits to the pattern, even when applied to careers. For example, although your position in a company might not be immediately satisfying, with time there is potential to move throughout the company to a position that is better for your skills and abilities. There are some paths you can only get to by travelling on a bumpy, gravel road first. It’s not optimistic, or ideal, but the text definitely glossed over these potential scenarios where you prioritize long term gains over short term happiness.

Overall, Draw Your Own Map is not an interesting or a surprising apprenticeship pattern, but it is a hugely useful one and one I feel I’ve already been using to make college-related decisions for a long time anyways. Basically, only you can make the choices that will lead your life to happiness, nobody else will do it for it. Just as long as you are making ethical choices that don’t tread on anybody else’s map.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

GivenWhenThen

Blogger Martin Fowler in his self titled blog describes a template for organizing unit tests, called “Given, When, Then”. This concept is perhaps a rephrasing of what we discussed in class, the four phase test, or “Setup, Exercise, Verify, (teardown)”. The idea is to structure our test cases in a logical, easy to understand process.

Fowler describes the idea as “essential to breaking down writing a scenario (or test) into three sections”. Given a specification, any situation we need to test for can be broken down into these three steps. The first section is “given”, or the “setup”. During this phase of the test, we would create variables and set up the preconditions to a test. Fowler uses a scenario of trading stock to illustrate his point. “Given” a certain amount of stock to invest (precondition) move on to the next phase.

The next step in the model is the “when” phase. During this phase of testing, we are choosing the behavior of a function to be tested. In Fowler’s stock trading example, this translates to “Given: x amount of stock to sell- When: I want to sell y stock”.  This phase essentially defines the behavior of the test we are writing.

Last but not least, the “then” phase is all about putting the first two cases together and verifying them. Following Fowler’s stock example, the “then” phase is represented as “Given: x amount of stock to sell – When: I want to sell y stock – Then: I should have x-y stock”. This phase is where you verify the expected behavior to the actual behavior of the program.

Personally I find this model particularly helpful, in the sense that it provides a useful narrative for breaking down testing situations. To me the “given-when-then” model seems more intuitive than “arrange, act, assert” or “Setup, exercise, verify”. While all three models definitely describe the same process, I think that this model is the most clear. In any case, breaking down test scenarios into discrete parts like this is integral to creating clear, easy to understand tests.

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

Greetings reader!

The nature of this blog is to give a short summary over a topic that is essential in the Computer Science field: Mutation Testing. This blog will share my analysis of Tutorial’sPoint’s: Simply Easy Learning- Mutation Testing Tutorial.  I will be expressing my reaction to the content by sharing what I find useful and interesting and displaying if I have any concerns or disagreements. Without any further introduction, let’s begin.

First, let’s start with defining what mutation testing is. Mutation testing is a testing technique that uses the structure of the code to conduct the testing process. It is simply the rewriting of code in small ways in order to take out the excessiveness in the code. This wordiness may cause failures in the software if it is not altered. It is very sneaky because it can pass through the testing process’ unnoticed.

There are three types of mutation testing: value, decision, and statement mutations. Value mutations are efforts to change the values to display errors in the programs. The change of the value is usually to either a very large value or a very small value. It is found that the most common strategy to combat this is to change the constants. Decision mutations are when the code is changed to check for errors in the design. Ways to fix these errors are by changing the arithmetic operators to find the failures or by altering the relational and logical operators. Statement mutations are when changes are done to the statements by deleting or rewriting the line.

Mutation testing is based on two theorems. The first is the competent programmer theorem. This theorem explains that most software errors made by experienced programmers are due to small syntax errors. The second theory is called the coupling effect. The coupling effect says that simple errors can couple to form other faults.

All in all, mutation testing is a fairly simple technique that is used when testing code. Sometimes errors or faults can be hidden when making tests that will cause the source code to fail. Mutation testing is the process of altering these subtle errors in efforts to run the code.  This topic is extremely important to this field because it gives us a deeper understanding of our errors, which helps greatly when correcting “bad” code.

Source: Tutorial’sPoint’s: Simply Easy Learning- Mutation Testing Tutorial

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

Using the Simple Factory design pattern is a lot like making cheesecake

Software developer Sihui Huang, writing for the blog freeCodeCamp, explains the simple factory design pattern in terms that most people can appreciate – cheesecake.

Huang walks us through the basic steps in a simple factory for creating cheesecake. Starting with a number of his favorite types, he creates a makeCheeseCake() method which calls cheesecake.makeCrust, cheesecake.AddLayers, etc. The makeCheeseCake() method uses the type of cheesecake as a parameter, and calls the the steps to creating a cheesecake that all different types have in common. No matter what kind of cheesecake you are making, you still need to make the crust. So the makeCheeseCake() method is only concerned about the steps required in making any kind of cheesecake, it doesn’t care about what flavor the particular instance is. Huang describes this concept, as we have in class, as encapsulating what varies.

So Huang goes on to create a cheesecake factory class that handles all the different classes of cheesecake we can possibly create, and returns the appropriate cheesecake type by a createCheeseCake() method inside the factory class. The trick is that when you call the makeCheeseCake(), a new cheeseCakeFactory object is created, and uses the createCheeseCake method to determine what type the cheesecake is. So now the MakeCheeseCake() method does not need to know at all about what kind of cheesecake it is creating.

By separating the parts of a program that stay the same from those that vary, we can simplify adding and modifying different types of an object (in this case cheesecake) by adding a new class and adding to the cheeseCakeFactory class. No code has to be rewritten to accommodate for changes and removals of types of cheesecake.

Personally I enjoy Huang’s analogy to elaborate on the simple factory design pattern. Being able to separate varying parts of a program from parts that never change makes our code more understandable, coherent, and easy to modify. And the idea that a “factory” can handle the details of initializing different types of objects instead of having separate implementations for every object type is good design, and I think the cheesecake factory example is a good metaphor for encapsulation

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

For this week’s blog post, I chose this blog by Lucie Saunois. It talks about the differences between Black box, Grey box, and White box testing for software or applications.

Black Box Testing

Black box testing reviews only the functionalities of an application. Testers do not really know the internal structure of the application. Testers typically have a “user” profile. This method aims at checking if the final stage of the application works like its supposed to. Common things the tester would look for in a Black box testing are missing or incorrect functions, interface, performance, program initialization, and external database access errors. To do this test, each different user has their own scenario to test, and all functionalities must be tested.

White Box Testing

White box testing reviews the functionalities of an application as well as its internal structure.  All of the internal components of the application are tested through the source code. Testers have a “developer” profile and not a “user” profile unlike in Black box testing. White box testers need to have competence in programming since they need to understand the source code. It is mostly done in the developing stage of the application. Therefore, it allows them to test the data flow and the handling of exceptions and errors. Scenarios for this test are created by the testers based on the source code. Testers only check if the code produces the expected results.

Gray Box Testing

Gray box testing is a compilation of both Black and White box testing. Gray box testing tests both the functionalities and the function of an application. In this test, the testers know the functionalities and also the internal structure of the application, however, they do not have access to the source code.

This blog explaining the differences between each kind of testing is really easy to follow. The way they were describe was easy to understand. She also wrote about their benefits and drawbacks of each method of testing. I really find her examples interesting towards the end of the blog where she uses an analogy by comparing it to testing a car system. I think finding blogs like these would help anyone understand the different testing methods out there, it is simple but very informative.

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

Ever since I picked up my first Java book and read through it, one thing always stuck in my mind when it came to writing any program and that is to not repeat yourself when you don’t have to. Leonardo Brito wrote an interesting piece, “Don’t obsess over code DRYness”, and he gave a few good points on why we shouldn’t try to make our code as complex as we can. He starts off by saying that we, as humans, are good at pattern recognition but sometimes we over-do it. He uses the example codes below:
____________________________________________________________________________
# Example 1
class Car
include Checkups

def maintenance_10k
check_break_fluid
check_battery_terminals
check_engine_oil
end

def maintenance_30k
check_break_fluid
check_battery_terminals
check_engine_oil
check_spare_wheel
end

def maintenance_50k
check_break_fluid
check_battery_terminals
check_engine_oil
check_spare_wheel
check_gearbox
end
end
____________________________________________________________________________
# Example 2
class Car
include Checkups

def maintenance_10k
basic_maintenance
end

def maintenance_30k
basic_maintenance
check_spare_wheel
end

def maintenance_50k
basic_maintenance
check_spare_wheel
check_gearbox
end

private

def basic_maintenance
check_break_fluid
check_battery_terminals
check_engine_oil
end
end
____________________________________________________________________________
After DRYing the code we see that it produces a new method called basic_maintenance while the original maintenance method conveys exactly what the method is expected to do. He then added a change such that we no longer need to check the break fluid on the 10 thousand miles checkup, so now we must remove the method check_break_fluid from basic maintenance and only add it to the upper maintenance methods. What he was trying to illustrate is that although one set of code was easier to read and follow, a simple change could have us altering out code in more ways than we’d like.

Brito talks about the trade off between some duplication over the wrong abstraction because overly DRYing your code could result in more confusion than simply repeating SOME code which is where he introduced another concept: DAMP – descriptive and meaningful phrases. The purpose of these two terminologies is to guide is to write better code and not going to any extremes.

I found that the concept of over DRYing your code interesting because I never thought about it that way and that there was a such thing. I’ve heard of DRY but never DAMP so I found that amusing how they’re opposite from each other. Looking back at my projects I feel as though I stand somewhere in between both concepts. I try to not over-do simplifying yet at the same time I make sure I apply DRY when necessary. I agree with what the author said about repeating sometimes to make it easier on yourself in the end.

Thank you for the read!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.