Author Archives: Johnny To

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

Source: https://www.guru99.com/fuzz-testing.html

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.

Mutation Testing

Source: https://www.guru99.com/mutation-testing.html

This week’s reading is on mutation testing. It is stated to be a technique that changes certain statements in the source code to see if the test cases are able to find the errors. The overarching objective of mutation testing is accessing the quality or robustness of the test cases. These mutations are generally placed in several categories, operand replacement, expression modification, and statement modification. For operand replacement, an example would be simply replacing a variable in an if-statement with a constant. For expression modification, an example would be to replace a less than or equal to operator to a greater than or equal to operator. Lastly, for statement modification, an example would be simplify deleting lines of code, adding code, or modifying data types in the program. This type of testing allows the testers to uncover errors that would have remained undetected. By comprehensively testing the tests, it will provide a large amount of code coverage of the source code. It is a very useful white-box testing technique.

I found that the article provides great depth on mutation testing, steps on how the technique works, advantages, disadvantages, and provide examples. This serves as a great refresher to the activity done in class. Before that, I would have never thought about a software technique that provides such coverage to the tests already created. I can agree with the article that it is powerful tool that brings adequate amount of error detection. It will improve code quality and early bug detection will save costs later on in development if they are caught early using mutation testing. What I found most interesting about mutation testing in general is the mutation score. It is defined as the percentage of killed mutants with the total number of mutants. By observing the percentage of killed mutants, we can see if the test cases are effective against the mutations. Unlike other white-box testing techniques, it is a very unique way of effectively testing tests for their techniques. This is similar to the black-box testing technique fuzzing, where it creatively creates unexpected creative inputs for software to uncover bugs that would have otherwise been missed. In conclusion, this exhaustive technique is very useful for comprehensively testing a program and is very effective.

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.

Path or No Path!

Source: http://www.professionalqa.com/path-testing

This week’s reading is about Path Testing. It is said that a vital part of software engineering, is to ensure that proper tests are provided such that errors or issues that exist within a software product will be resolved before it could turn into a potential costly threat to the product. By turning to path testing, it will help evaluate and verify structural components of the product to ensure the quality meets the standards. This is done by checking every possible executable path in the software product or application. Simply put, another structural testing method when provided with the source code. By this method, many techniques are available, for example, control flow charts, basis path testing, and decision to decision path testing. These types of testing include its fair share of advantages and disadvantages. However, path testing is considered a vital part of unit testing and will likely improve the functionality and quality of the product.

What I found thought-provoking about the content is the section on the significance of Path. By providing an understanding what the term “path” means will certainly break down the importance of this test. Knowing that path is likely describing a programs execution path, from initialization to termination. As a white-box testing technique, we can be sure that the tests cover a large portion of the source code. But it’s also useful that they acknowledge the problems that can be found while doing path testing. These errors are either caused by processes being out of order or code that has yet to be refactored. For example, leftover code from a previous revision or variables being initialized in places where they should not be. Utilizing path testing will reveal these error paths and will greatly improve the quality of the code-base. Also, I agree that path testing like most white-box testing techniques will require individuals who know the code-base well enough to contribute to these types of tests. Which also includes another downside where it will not catch other issues that can be found through black-box testing. This article allows me to reinforce what I had learned in class about Path Testing and DD-Path Testing.

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.