Author Archives: Johnny To

Rising from the bottom

For the fifth week’s reading, I chose to read the pattern, Be the Worst. It is about facing a problem where your rate of learning has plateaued. As such, a solution is needed and is presented as instead of being in a team where you are at the top. You will have to find a team where you can be at the very bottom. The objective is to work your way up from the bottom, and from that you should be able to learn from those who are better than you. By actively trying to become better than what you were before, you allow yourself to continuously improve. However, there are risks of placing yourself at the lowest. The first is that you could be a negative impact to the team which would mean that you aren’t contributing as much as you should. Second, you might find yourself losing motivation when things do not pan out the way you thought it would. The action provided in this pattern is to rank teams by skill level and find a team that would allow you to work your way up.

What I found interesting about this pattern is that there is no easy way of solving this problem. You have to be willing to improve, willing to learn, and willing to drop your comfortable position to continue chasing the top. After allowing yourself to do that, you need to continue having the motivation and enthusiasm to improve yourself in a team that you know is way more knowledgeable than yourself.

This pattern has made me think about the intended profession in a way that everything will not remain the same forever. As time passes, teams will become more knowledgeable, but every individual will learn at a different pace. If you happen to be a person that progresses faster and becomes better than the team much quicker. You will eventually come to the realization that your learning has plateaued. By planning your road map in conjunction with this pattern, you have a chance of continuing your journey to become a master if that is what you wish. This is what I learned from this pattern.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective – Round One

            A reflection on what I learned form this week’s activities is that everything is easier said then done. We are given a sprint board and should strive to meet the objectives by the end of the sprint. However, it is not surprising there is issues to be accounted for during the first sprint. As expected, the amount of communication outside of class is lacking than when we are interacting with one another during class. In regard to this, the solution is to make sure that everyone is fully aware that our only source of communication, Slack, is important to check every day. As it also affects our course grade due to our attendance with the sprint standups. This is solution is also applicable to any problems regarding communication in the future as it’s simple to address but execution requires effort.

At the start of the sprint, our
backlog started with two items to complete. The first item is summarized to
speaking with other university professors about what information is valuable.
The steps taken to ensure we have contact with the other professor was to join
the appropriate slack channel. In this case, I joined the LibreFoodPantry slack
channel with my respective group members and under the “food-saver” channel.
Our group got information indirectly from another team’s question regarding the
REST API addressed to the other university’s professor. In response, we learned
that they would like to know how long an item can be eaten opposed to its
actual expiration date, and possibly a way of filtering by food categories.
This is the first step but there is a roadblock, even if we know what is needed
from the client, if we don’t have a place to begin then it seems pointless to
know what they need.

            The road
block is what leads to our second item in the sprint backlog, which is to
develop the REST API interface to manipulate a JSON file. From the Department
of Agriculture’s Food Safety and Inspection Service, we are provided a public
JSON file to work with.

The first step is to figure out
where to start, and my approach was to tackle a small issue that was mentioned
beforehand, which is a place to store, and pull the JSON file from. In which, I
spent about an hour looking up information about DigitalOcean and there was a
way of getting 12 months of access to DigitalOcean for free from GitHubs
Student Developer Pack. However, I put this information on the back of my mind
since another member was looking into Heraku.

In response, I chose to get started
on researching about REST API. The first site visited is which
introduced the concepts of REST. Next, since the group unanimously decided to
work with JAVA as the preferred language, I decided to revisit my favorite java
IDE, IntelliJ IDEA. On the JetBrains site, it provided a tutorial to REST API
web services which I read and got introduced to the JAX RS library. Lastly,
after completing that tutorial, I learned that it was not the place to begin
this journey and found the “Building a RESTful Web Service” with spring
tutorial. In conclusion, I’m still working on the spring tutorial and that is
where this sprint ended for me.

What I produced this sprint:


From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Creating your own toys!

For the fourth week’s reading, I chose to read the pattern, Breakable Toys. This pattern focused on the problem where you are introduced into an environment that doesn’t allow you to fail. Even though everyone knows that you are learning from your failures is the best form of learning. There solution is that you create something similar or a private environment where you can create and work around projects that are similar but not replicas of the projects where you work. The goal is to learn from failing in similar projects where you can learn how to work around them and possibly apply concepts learned in the future. An action provided for this pattern is to build a simple wiki while maintaining quality. In effect, you should be able to keep implementing more features by learning and applying them. Concluding this would be, don’t let work constraints prevent you from learning for yourself and take control of what you can learn and apply.

What I found interesting about this pattern would be their example of breakable toys. Which is to re-create known tools to give yourself a deeper understanding about the tool and why it came to be that way. Examples of these are games like Tetris, tic-tac-toe, or other simple software. By being able to successfully recreate such games and software, you can get a feel for the thought process and problems that the first creators may have come across and face long ago. Enabling yourself to have time, experiment, fail, and try again is essential in learning. Another would be the wiki solution, as you may learn much more than expected over a longer period of time.

This pattern has reinforced my current thoughts about my intended profession. I believe that there will be many different environments to face in the future. Some may be welcoming, and some may not be so welcoming. By learning about how to deal with a situation such as this one where failure is not allowed. Being able to adapt quickly and create a workable solution is important in progressing as a person and in the field of software development.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Relationship between Doctors and their computers

What I found interesting about the article on Why Doctors Hate Their Computers is the entire process or evolution of the software. The entire journey the doctors had to go through in order to accommodate the software that has begun to invade their profession. As with many different situations, being able to play around with something new that you haven’t used before is exciting. However, after a period of time has passed, you will notice how the change has affected your life. This is what has happened to the doctors that once praised the new software to hating it. Before software was introduced, all paper-based systems were balanced around human behavior. Such technology did not account for that and focused around efficiency. The downside to this is the difference in efficiency for computers did not translate one to one for efficiency in humans. Which lead to a decrease in efficiency for the lives of doctors world-wide who has come to depend on such systems. Due to this, doctors started hiring more workers in order to reduce the time loss and complications generated from using the software designed to “help” doctors to increase human efficiency again. This process is never ending as it continues to try and find a balance which is indeed interesting.

The reoccurring problem that causes the doctors lives to be harder than easier would be the data entry process. Asking questions and storing the answers require time, and time is limited per patient. By increasing the number of fields that doctors had to fill, reduces the load and helped other jobs elsewhere but reduces the time available to help patients and increased the workload for doctors.

The real customer for the system is not the doctors but those above the doctors who chose to believe that doctors would appreciate the system. By appealing to a certain client and not directly to those who are going to use it will definitely create an issue. However, once the system is in place, the doctors will have no say in whether they want to use the system or not. The amount of money spent on the new system must be used to get their money’s worth.

Also, the lessons from the implementations of this system also apply elsewhere as more and more people are gaining access to computers. As such they become dependent on software that could potentially improve their workflow. These situations are what is needed to continually improve software and tune them as needed to satisfy the customer’s needs. Software and humans are alike, as they are ever evolving and adapting to new situations thrown at them. The article is very relatable to how new software has effected society as a whole today and was a very interesting read.


From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Team Dynamics and Mindset

For the third week’s reading, I chose to read the pattern, Unleash Your Enthusiasm. This pattern is about handling the excitement of being a software developer once you join a team. Joining a team brings responsibilities such as considering how the team functions. The enthusiasm you bring into the team could be accepted or rejected. Depending on what happens, you are required to handle it correctly. For example, being overly enthusiastic could potentially backfire such as making a bad impression in front of a well-established team that is currently low on morale. For teams open to excitement, you can be yourself, as they are accepting of possible ideas and creativity you could bring. This type of environment allows yourself to throw ideas with very little to lose as well. By being a newcomer, it’s said that you are in a unique position of having a fresh perspective for the team. As with any team, improvements and suggestions can be made by all members, as such, your opinion also matters.

What I found interesting about this pattern is the excerpt about a study on the collective mind of aircraft carrier crews. The conclusion of the research was that its healthier for a team to having people of all levels of experience. This is true in a sense that if you have a team of all veterans, it’s very easy to be in a mindset where you could do no wrong. While incorporating members that have less experience, the veterans would benefit from reviewing basic information that they could potentially overlook or forget. As such, new comers do have a unique role as stated earlier in the pattern. Another interesting part of this pattern would be the action it proposes. It seems to be assessing the thought process in rejecting an idea you have before getting opinions from those you are suggesting it to. By surfacing the scrapped idea and presenting it to said person/group, the individual could learn more about their idea and maybe more. Taking risks is apart of life and sometimes proposing ideas aren’t as risky if you benefit from learning from your peers.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Beyond the point of no return?

For the second week of reading, I chose to read the pattern, A Different Road. This is a continuation off of Draw Your Own Map and discusses an issue. The issue is when you have followed your own path as a software developer and hit a road block. This road block is not about whether or not you could become better and rather that of a change in interest. It details the possible outcome of leaving the industry to pursue another interest and what could happen upon returning. There is a chance that the gap from working in different industries could work against you in the end. It is said that some organizations will deem the inactivity from the field as suspicious and will question your return. The risk is big, but it is still important to follow your road map where ever it leads.

What I found useful about this pattern is that it encourages others to follow their hearts or road map that led them up to the decision where they might be leaving the profession. Everyone only has one life, and usually the saying is to do what makes yourself happy. Sometimes, people need a change of pace and it’s important to recognize that. However, I am not surprised that some organizations will question your absence from the profession if you chose to leave for a while. I’m sure many of us who chose to study computer science has realized the type of field we are going to throw ourselves into. Another interesting part of this pattern is about the work experience between two different jobs can sometimes be used effectively. Depending on the context of course, one experience in a separate field may be used to fix or provide a solution to a problem in a different field. This also goes back to the organizations who might disregard any experiences that an individual has that isn’t related to the experience needed to fill the desired position. I feel that the only choice after leaving the long road for a while is to work twice as hard to get back in. Lastly, I do believe there are probably plenty of ways to accomplish that and it’s not a lost cause overall.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Road map of uncertainty

What I found interesting about the introduction chapter would be what it meant to become a software craftsman. It meant going through three different stages, apprentice then journeyman then master. But way before that, there is a heap of values that must be upheld in order to successfully start the process. These values can be summed up to, willingness to learn, succeed, fail, try something new while setting aside past experiences, and so on. Individually, many of these values are strong and correct in its own way. When they are brought together under software craftsman, I can definitely tell how the mindset of a true craftsman should look like. First you start out as an individual that is constantly looking to grow and absorb all the information and techniques from the more experienced members of the community. Then you take that and apply it, in order to constantly improve and grow their portfolio of things they have done. Lastly, they will likely end up a seasoned software developer that can have an impact on the community as a whole while still learning as an apprentice and building their portfolio like a journeyman. This concept is short and sweet but is practical in describing a person that has the commitment and dedication to his/her craft to rise to the top.

The chapter that resonated with me the most would be chapter two from the interactions between the master and the philosopher. The interaction in question would be how the young man would not let the master show him his methods of techniques that he might have already been taught. This creates a picture of how the master and apprentice relationship should not be. As the apprentice should be willing to put aside his past experiences while digesting new methods of the master, he is currently seeking teachings from. As a human being, you are bound to encounter people who are more experienced in a field that interests you. While you might be somewhat experienced or knowledgeable in that field, especially in software, there are always more than one way of accomplishing any task.

Another chapter that resonated with me would be chapter four, accurate self-assessment. The main point can be summarized as never get too comfortable at being successful short term. You must think about the long term, which also taps into chapter three about the long road where you can’t get to become the best at anything overnight. These two chapters can for example describe any sports player, they definitely did not become professionals by being content of what skill level they are at, they must have practiced for many years and constantly seeking improvement to get to their current state. These values are agreeable and applicable to people looking to become better software developers. Overall, I believe the readings reinforce ideas and values that could make anyone successful at any craft they are interested in and not necessarily software developer related but in this context, it will be an extremely useful resource to have.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

No hand holding

For the first week of apprenticeship pattern readings, I chose to read Draw Your Own Map. This pattern focuses on the career path that you chose for yourself based on your future or current employer. It tells a tale of how employers can only lead to a limited amount of career opportunities from your current job status. To work through this system, it is necessary to create a plan or road map for your future endeavors after moving forward from where you currently are. By lining up paths that can be available to you based on your current desires, knowledge, and expertise. It will be easier to find yourself in work that suits yourself the best instead of settling for less. These roadmaps should easily be updated to your current situation whenever you see fit. The overall idea behind this is that no one will be able to tell you how your career will end up, everything is up to you.

What I found interesting were the two short stories provided near the bottom of the pattern which clearly showed how reality will present itself. By providing evidence of how some apprentices feel about their current work experience, realizing what they actually wanted, and making a rather small but big step towards their dream career path is inspiring. It also goes to show that not all companies will have their interests aligned with their employees. Also, the action listed at the bottom is helpful to show that. By mapping out from each job choice and their potential benefits and paths that could open or give an overview of how you will end up later on. By not limiting your choices and have a willingness to redo the diagram until you are satisfied with the end result. There is a big possibility you will find happiness at the very end. Otherwise,  I enjoyed the fact that this pattern is straightforward with budding apprentices like myself. As quoted, “Understand that it’s not up to your employer, your career counselor, or your professors to give you a hand up.” Every decision lies in us, by having a plan, you can reduce the amount of roadblocks you will hit along the way and make more informed choices in your career path.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

New semester, new blogs…

Introductory blog post once again!

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Fuzz Testing


This week’s reading is on fuzz testing. It is defined as an automated technique that is used to uncover errors that will most likely missed by manual inputs. As it is a black-box testing technique, it deals with the execution itself rather than going through the source code. Due to the way the technique works, it will be able to find serious defects and security loopholes in the software it is tested. It’s also stated that the technique is one of the most common method for hackers to find vulnerability in systems. The general steps to fuzz testing is identifying inputs, generating fuzzed data, executing tests using that data into the system, and logging all of its findings to be reviewed. Typical bugs detected by fuzz testing is assertion failures, memory leaks, invalid input, and correctness bugs. It’s very simple but will improve the quality of the software and improve security overall.

I found it interesting that the article mentions that it is a common method for hackers to use fuzzing in order to gain access into a system. However, I am not surprised that they do considering its overarching objective. Knowing that the technique is used by testers to find vulnerabilities in software, it doesn’t hurt for hackers to see if the common vulnerabilities have been accounted for through testing. Another interesting tidbit would be about correctness bugs, as I do not remember being able to test for corrupted databases, poor search results, and etc. using other techniques available. I also agree that fuzz testing alone will not solve all of the security issues. As it will account for invalid inputs, correctness bugs, memory leaks, and assertion failures. There are probably other methods available that are specialized towards handling complex security threats. In other words, fuzz testing will only help identify common vulnerabilities and sometimes help against major ones. Knowing that this method exists for black-box testing, as with other methods available through white-box testing. By using it in conjunction with other effective methods will create a product that is of high quality, secure, and cost-effective. Its similarity coincides mutation testing as it ensures the software is robust. In conclusion, it is fuzz testing is useful for showing presence of bugs in an application but will not guarantee full coverage.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.