Author Archives: rydercsblog

Sprint Retrospective #2

During our second sprint we were still focused on learning about the tools we will be using as we have not yet received actual work to do for AMPATH. There were two things that I focused on: testing with Karma and Protractor and the Angular Tour of Heroes tutorial.

Karma and Protractor are the two testing tools that we will be using for this project. Karma is used to write unit tests while Protractor is used for end-to-end testing. My teammate Ryan put together a very useful Google Doc that includes all of the basic information about these two tools including how they work, how to use them, and helpful links to learn more. This is the main resource I used because it includes pretty much everything I wanted to know about Karma and Protractor.

The following link provides a good overview of what Karma is and how it works: http://karma-runner.github.io/3.0/intro/how-it-works.html

Karma works by creating a web server that executes source code against test code. The test results are examined and displayed through the command line so the developer can see which tests and browsers passed or failed. Karma looks like it will be an incredibly useful tool for unit testing our code.

Protractor also uses a web server to run browsers that will test the code. It simulates user interaction with Angular applications in order to test system dependencies. The following link is a good tutorial that helped me get familiarized with Protractor and learn the basics of how it works:

http://www.protractortest.org/#/tutorial

Other than learning about these two testing tools, I also started doing the Angular Tour of Heroes tutorial in order to re-familiarize myself with Angular. I have previously done this tutorial in Software Construction, Design, and Architecture. However, I wanted to go through it again to make sure that I remembered the specifics of Angular and Typescript. Even though I haven’t gotten incredibly far in the tutorial, much of the information is coming back to me. I think the Tour of Heroes is one of the best coding tutorials I’ve ever used. Everything is explained clearly, there are links for more complex topics that come up, and all of the code you should have is displayed at the end. There are also summaries at the end of each section that review everything that was learned. I’m glad that I started doing this tutorial because I now feel more prepared and also eager to start actually coding.

Overall our second sprint was still all about preparation. While I do wish we could have started working on something during this sprint, it’s good that we have had plenty of time to learn about the tools we will be using so we aren’t caught off guard when we have to actually produce code. During this sprint I learned a lot about testing with Karma and Protractor and relearned information about Angular. I’m excited for the next sprint as it looks like AMPATH has finally sent us information on the work that we will be doing.

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

Apprenticeship Patterns – Kindred Spirits

The Kindred Spirits apprenticeship pattern is about how you need to keep in contact with people who are on the same path as you in order to continue learning and growing your passion. This is important because you may find yourself working in an organization that does not encourage software craftsmanship and does not provide mentors for you to follow. Working with a community provides an environment for exploration and learning that is not as intimidating as working with a mentor. However, when you are working with a community you must continue to think for yourself and not just blindly follow along with what everybody else is doing.

I thought that this pattern was very useful because keeping in contact with peers is one of the most important things that you can do if you want to stay passionate about software craftsmanship. I’m sure that many people find themselves in jobs where they are programming very boring things and start to forget whey they had a passion for software in the first place. If you are in contact with similar people, you can learn about and explore new ideas in a relaxed environment. This will allow you to continue growing and nurturing your passion even though you may be stuck in a job that is stagnant and uninteresting.

I enjoyed reading the two examples about people who followed this pattern because they showed how people were actually able to connect with each other and keep in contact to become kindred spirits. I also think that the recommended action of listing all communities that you could potentially join and going to each is a good idea. There are probably many communities around me that I may be interested in but have never discovered simply because I haven’t sought them out. Reading this pattern has definitely inspired me to find communities to join because now I realize how important it is to be in touch with other people in the field, especially after graduating college. Overall I think that this pattern is very useful and I don’t disagree with anything that was written.

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

Why Doctors Hate Their Computers

I thought that the article Why Doctors Hate Their Computers was incredibly interesting and eye-opening. Working in the software development industry, it is easy to think that software can easily replace many systems that are in use across a wide variety of industries. But as this article shows, complex software systems are not always a perfect solution. For example, the Epic electronic medical record system ended up creating more work for doctors because the software made the note-taking process longer and more redundant. While the system did increase patient benefits, those working in the medical field faced negative consequences that created more work, stifled innovation, and decreased face-to-face interaction with patients.

I thought that the most interesting part of this article was the idea that adaptation requires mutation and selection. The pre-computer systems of medical practice were all mutation and no selection, while computerization is all selection and no mutation. This analogy is a very succinct way of describing the advantages and disadvantages of using software systems. I think that software development companies and those in the medical field should work closer together to develop systems that are more customizable and less restrictive on doctors.

I think that the real customer for the system is the hospital administration. While the system did lead to better treatment for patients, which is obviously a good thing, it came at a large cost for the actual doctors. The system was developed mainly with input from the administration, so the focus was on decreasing costs and improving patient outcomes while the opinions of the doctors was ignored. I think that they should have worked more closely with doctors because they are the ones who actually have to use the software every day.

The lessons from the implementation of the Epic system apply everywhere. When developing any type of software, one of the most important goals should be usability. If a software program is not intuitive and easy to use, rather than being a powerful tool it becomes more of a burden. It is always relevant to take input from the actual people who will be using the software while it is being developed. As seen with the Epic system, if this is not done implementation of the software can have opposite of the desired outcomes.

Reading this article reinforced the idea that usability should be a primary goal when developing software. It is important to have other people use the software you are developing and take input from them. I think this article was very well-written. The author backed up his points well and I don’t disagree with anything in the reading. Overall I’m glad I read this article as it offered an interesting perspective and was both informative and entertaining to read.

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

Apprenticeship Patterns – Draw Your Own Map

Draw Your Own Map is a pattern that discusses how you must forge your own path in terms of your career and not let yourself be boxed in by your employer. This pattern is relevant for everybody who wishes to advance their career as there is only a limited set of career paths that any employer can offer. It is not up to anybody but yourself to decide what the next step in your career should be. When you figure out you want your next step to be, you should visualize the smaller steps that you need to take to get there. Taking the first step will help propel you to achieve your goals. If you discover that your vision for your future is not compatible with your current employer, you should start looking for other opportunities. Draw Your Own Map is all about not getting stuck in one place that doesn’t provide for career advancement.

I think that this is a very useful pattern to follow. It is common for people to grow comfortable in a certain role which makes them unwilling to look for other opportunities. It is also unlikely that any company will provide you the exact path that you want your career to follow. It’s important to remember that your employer is not invested in you advancing the exact way you want to. Even though you may work for a particular company for a long period of time and feel like you should have some level of loyalty, it is better to examine other opportunities when your company’s ideas for you are not aligning with your own. This is the only way to truly draw your own map.

I thought that the two example stories given were interesting to read through. Reading real life examples helps to drive home the point of the pattern and shows that this type of thing is not uncommon. It was also interesting to learn about two actual career paths that have been taken by people in the industry. Overall I think that this pattern is applicable to everybody and is important to remember for people beginning their careers.

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

Apprenticeship Patterns – Confront Your Ignorance

Confront Your Ignorance discusses how to begin mastering gaps in your skillset that are relevant to your daily work. It is important to fill these gaps in whichever ways work best for you. For example, some people like to read introductory material until they have a good understanding of the basics, while others like to dive right in and learn by breaking things. Working with peers who are trying to learn the same skills will help you make better progress. Once you have a decent understanding, you must decide whether it’s more useful to dig deeper or start filling other gaps in your knowledge. There can also be negative side effects created by this pattern. If you implement an extremely complex system just to learn how to do it you can burden your coworkers and introduce unnecessary costs. It is also important to not let your education get in the way of delivering a product. A software craftsman must be willing to put the wider interests of the community before personal benefit.

I think that this pattern is very relevant because everybody eventually runs into ideas or techniques that they know nothing about while everyone around them seems to have them mastered. Knowing how to pick which skills are worth learning and being able to learn effectively are important traits required for success. Being able to confront your ignorance is something that everybody (especially software developers) should be comfortable doing.

While I agree with everything written in this pattern, I don’t think there is anything exceptionally thought-provoking about it. It’s basically another way of saying that you should continue learning throughout your career. I believe that this is an important thing to do, but there was nothing written in this pattern that will change the way I work or think about the profession. Overall I think that the content in Confront Your Ignorance is agreeable but I did not take away any new ideas by reading it. I do look forward to reading some of the other patterns that were linked in this one as they seem like they have related ideas that expand on what was written about in this pattern.

 

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

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

After reading the first chapter of Apprenticeship Patterns I feel that this is the perfect book to read for somebody just beginning their path as a software developer. There seem to be a lot of interesting ideas in this book that would help promote continuous learning and improvement for the craft. The authors use the phrase software craftsmanship to refer to a community united and defined by common values. These values include:

  • having a growth mindset
  • a desire to be pragmatic
  • the belief that sharing information is better than hoarding it
  • a willingness to experiment and be proven wrong
  • a commitment to inclusiveness

I feel that these are values that should be followed in all areas of life. It is important to always be trying to improve and learn new things. These values apply especially well to the field of software development because it is always changing and there will never be a shortage of new things to learn. Software development is also a field that depends on a community that is willing to share ideas and resources. It is almost impossible to write anything useful without importing code that was written by others, and the free exchange of knowledge within the community is what allows people to improve and innovate.

I thought that the ideas on what it means to be an apprentice, journeyman, and master were very thought-provoking. The definitions are focused on how each stage involves personal growth and contributing to the craft. I think that these roles make a lot of sense and promote the values that the authors discussed. I agree that following these values will help bring success to individuals and the industry as a whole.

I think that chapters 2-6 all sound interesting and useful based off the introductions. The chapter that I most want to read is Chapter 5: Perpetual Learning. I was grabbed by the C.S. Lewis quote at the beginning, which helps convince the reader that they have to actually want to learn in order to continuously learn throughout their life. I also like the line “Apprentices are thirsty for opportunities to replace their ignorance with skill.” The more you learn the more you realize how much you don’t know, which makes it exciting when that ignorance starts to be replaced with knowledge. I agree with the authors that learning is a perpetual activity, so I think that this chapter will be very useful.

Overall, Apprenticeship Patterns seems like it will be an extremely valuable read. It is interesting how the book focuses not on technical details, but on the ways in which a beginner software developer can begin their journey towards becoming a master. It also seems like many ideas in this book can be applied to numerous facets of life, not just programming. I look forward to continuing to read and learn from this book.

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

CS 448 Introductory Post

This is my introductory post for CS 448-02.

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

Mutation Testing

https://www.softwaretestinghelp.com/what-is-mutation-testing/

This blog post explains mutation testing with a simple example. Mutation testing is a fault-based testing technique. Variations of a software program are subjected to the test data set to determine the effectiveness of the test set in isolating deviations. The example that this post uses involves a hospital site that lets new users register. The input to the program is the age of the patient. If the age is greater than 14, a general physician is assigned as their main doctor. The example data set for the tester is 14, 15, 0, and 13. The goal is to check if this data set is adequate to identify all possible problems with the code. To achieve this with mutation testing, variations of the program (mutants) must be created. A mutant is nothing more than a deviation that contains a self-seeded fault. Example mutation operators are:

  • Arithmetic operator replacement
  • Logical connector replacement
  • Statement removal
  • Relational operator replacement
  • Absolute value insertion

Once all the mutants are created they are subjected to the test data set. If the data set kills all mutants, it is effective. If it does not, more or better test data should be used. Each value in the data set does not need to kill all mutants, but all the values combined should kill all mutants.

Some mutants are not useful at all. Mutants to avoid include:

  • Syntactically incorrect mutants
  • Mutants that do the exact same thing as the original program
  • Mutants that can be killed by any data set

The number of mutants can be extremely large, even for a small program. Because of this, a subset of mutants is normally used and the mutants are commonly chosen at random. If there are some mutants alive at the end of the test, it is either an invalid mutant or the data set was inadequate. Mutation testing is a structural, white-box and unit testing method.

This was a useful post because it explained mutation testing with an example that was easy to understand. It also covered all of the important information to know about this testing method. After reading this I feel like I have a much better understanding of what mutation testing is and why it’s used.

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

Fakes, Mocks, and Stubs

https://blog.pragmatists.com/test-doubles-fakes-mocks-and-stubs-1a7491dfa3da

A test double is a generic term used for objects that look and behave like their production equivalents, but are actually simplified. Test doubles are used to reduce complexity and verify code independently from the rest of the system. There are many different types of test doubles, and misunderstanding or mixing them will make fragile tests. This blog post discusses three different variations of testing doubles: fakes, stubs, and mocks.

Fakes are objects that have working implementations different from production ones. An example is using an in-memory data repository instead of accessing a database. The benefit of this is that integration tests can be carried out without performing the time-consuming process of starting up and requesting information from a database.

A stub is an object that holds predefined data and answers calls during tests with this data. Stubs are used when we don’t want to involve objects that would answer with real data. For example, if there is an object that needs to get data from a database to respond to a method call, a stub can be defined with the data that should be returned instead of using the real object. Stubs are preferred for methods that return some result and do not change the state of the system because it allows verification of a method’s return value.

Mocks are used for methods that change the system state but don’t return any value. Mock objects register the calls that they receive. Assertions are used in testing to verify that all expected actions were performed. Mocks are commonly used when we don’t want to invoke production code or when there is no easy way to verify that the intended code was executed.

This blog was a good overview of the differences between fakes, mocks, and stubs. Reading this helped to solidify what I learned in class and gave me a better understanding of when each test double would be used. I especially liked the images and code examples used as they made the idea behind each one easy to understand. Overall this was a well-written and useful blog post that gave me a deeper understanding of material learned in class.

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

IoT Testing Types

https://testfort.com/blog/iot-testing-types-best-practices-through-reliable-testing-strategies

This blog post is about testing types and best practices for IoT devices. The market for these devices is growing at a fast rate and is continually changing. However, IoT testing is difficult because it requires a large base of physical equipment and knowledge about smart devices, IoT systems, and IoT test environments. Proven IoT testing approaches include compatability, security, beta, usability, and performance testing types.

Compatibility Testing

Compatibility testing should be a priority because IoT applications are run on innovative types of devices. This type of testing is necessary to protect software from vulnerabilities and system failures. An IoT testing team should have a well-equipped testing laboratory or take advantage of cloud environments.

Security Testing

It is important to test the security of IoT applications. There are three levels of testing:

  • IoT device testing – makes sure that devices are protected from breaches related to APIs, authentication, updates, and setting configurations
  • Network testing – protects the application from attacks on the network layer
  • System testing – ensures that user data is protected from leakage and hacking

Usability Testing

Usability testing ensures that software is easy to use and intuitive. IoT testers need to make sure that an application is perceptive and configurable.

Performance Testing

Performance testing is used to test an application’s speed within an environment with large data loads. Testers can use cloud platforms to simulate large loads and generate non-standard scenarios to see how an application performs.

Beta Testing

Beta testing involves the development of realistic scenarios for IoT testing. Discovering failures and usability issues during beta testing helps increase the chances of a successful product release.

Overall I thought this blog post was interesting as I have never really thought about the special considerations for testing IoT applications. While I think this post did a good job explaining why testing IoT software is difficult, it could have benefited from being more specific. The author does not go into much detail as to how these testing strategies are uniquely used by IoT software. It serves more as a general overview for the goals of these testing methods. Regardless, after reading this blog I am interested in learning more about IoT software development and testing.

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