With CS 343’s final presentation tomorrow, this will be the last post for this project. (Unless I choose to keep playing around with it later) The work on this project has really helped me learn HTML, CSS, and TS.
The newest feature I added to my Pokedex SPA was having the background colors linked to the selected pokemon’s typing.
This took a bit a time, figuring out how to dynamically link the HTML background color to the TS pokemon data. I eventually found the use of angular’s [ngStyle] to be very useful. This method injects a JSON object with CSS properties defined in it. With it, I simply used a method in the TS to grab the pokemon’s typing and return a created JSON object with the CSS property ‘background’ with either a solid color for single typing or a gradient for dual typing.
This project was a lot of fun and I’ve learned a lot. I am tentatively looking forward to tomorrow’s presentations.
Yesterday was my final class meeting for CS-443. In it, I was briefly introduced to the concept of Software Quality Assurance (SQA). The presentation on it was mostly focused on Capability Maturity Model Integration (CMMI), which is one set of standards that is often used in SQA to ensure that an organization is capable of developing software well. While I received plenty of information on CMMI from the presentation, I felt that I did not gain a great understanding of SQA in general. For this reason, I decided I would do my own research into SQA to help me prepare for the final exam tomorrow.
I eventually came across this article from softwaretestinghelp.com which I think provides a fantastic introduction to SQA. The article starts of by defining SQA as “a process which assures that all software engineering processes, methods, activities and work items are monitored and comply against the defined standards.” This definition has helped me understand exactly what SQA is much better than the class presentation, which focused on CMMI. In fact, the article’s explanation has clarified to me that SQA can use any set of standards as defined by the organization, and that CMMI is only one possible example of these standards.
While the article emphasizes that SQA is a much broader concept than I previously thought, it also lists several activities and techniques that are generally used in SQA regardless of the selected set of standards. Some of the activities listed include having multiple testing strategies, measuring change impact, and maintaining records and reports. These techniques have all been discussed either in CS-443 or in other classes that I have taken, and seeing them listed here has helped me better understand exactly what happens when SQA is used during a software’s development. The article also discusses several techniques used to enforce SQA during a development process. The main technique that is used is auditing, which involves regular inspection of the products of development to make sure they follow the standards. Other techniques discussed in the article include code inspection, design inspection, and static analysis, all of which I have also been exposed to previously.
This article has made it clear to me that SQA is not simply the enforcement of CMMI, but a much broader concept that can enforce any set of standards using a variety of techniques. Reading this article has helped me better understand what SQA is and what it looks like to use it during development, and I definitely recommend it to anyone who is also having trouble understanding SQA.
A great article I read today goes over the importance of creating the correct kinds of tests for software. In this article, the author thoroughly explains the importance of testing the “behavior” of software versus “implementation details” and how not “every single class” needs to be tested. I think the author does a great job with both an easy to understand narrative and tons of example code that illustrate the importance of testing that software performs to specification versus testing how the code is written. The example code given in the article goes further with linking to an entire GitHub repository for the example code (which elaborates beyond what is shown in the article) which I really appreciate as it lets me see exactly how this concept aligns with a complete program. The most interesting part of this article for me was in the author’s explanation of how refactoring code can cause tests that are written (incorrectly) to a specific implementation to fail. I think it is important to see this point that putting in extra effort in developing software but on the wrong things can actually do more harm than good further down the line. Especially as the author points out if you were to further refactor the code and change how it works (even return types as the author demonstrates!), this causes bad tests to fail, which only creates even more work. I never really thought of how refactoring could create more work in a testing scenario before reading this, but I like how refactoring further helps the overall program by exposing the appearance of useless tests. One other part of the article I really enjoyed was the side narrative the author gave while working through his example of how the steps they took followed TDD (test-driven development). This is also something I wanted to learn more about, and this article also provides a good example of TDD by explaining how certain practices taken in the code example adhere to the rules of this methodology.
Overall, I think this article covered an important topic well, and serves as a great reminder at the end of our testing course to make sure we are testing the right things in our software and that we are not creating too many, and useless tests that only hinder our efforts and not help us. I will certainly keep this article in mind when writing future tests to ensure I’m not wasting my time by creating the wrong kinds of tests or making sure every line is tested in a program.
Last Thursday in CS-443, I was introduced to Mutation Testing. This is a testing method which uses tools to embed faults into a project’s code before running its tests. The idea behind it is that, if the tests are written well, then they should fail when mutations are introduced. The in-class activity introduced Mutation Testing by having us clone a Java project and running the PIT tool to test the project with mutations. While the activity effectively demonstrated how to use PIT, I felt that it did not give me a complete understanding of Mutation Testing in general. This was mainly due to some confusion I had while trying to figure out how to run PIT. For this reason, I decided to research Mutation Testing on my own to help improve my understanding of it. I eventually came across an article from softwaretestinghelp.com that I think provides a great introduction to Mutation Testing.
The article demonstrates Mutation Testing with an extremely simple pseudocode example consisting of a single if statement. The example has five different types of mutations applied to it (called ‘Mutation Operators’) which demonstrate how adding mutations can alter the results of tests. Some of these mutation operators, like relational and arithmetic operator replacement, were demonstrated by the class activity. Others, like statement removal and absolute value insertion, were completely new to me. This taught me that there is a much wider variety of mutation operators than the activity demonstrated.
I also found that the article made it easier to understand how the mutations affected the results of the tests. In this article, the results of the Mutation Test are listed in a table with each column representing a different mutation made to the example code. This makes it possible to see exactly which test values either kill the mutants or cause them to survive. It also makes it easier to notice syntactically incorrect, equivalent, and trivial mutants, which the article mentions should be avoided. I disliked how the Mutation Test results were reported by PIT as a generic list of mutations with vague information describing why they survived or were killed. Having the results in the article be presented in a table and being able to refer back to the actual mutated code made it much easier to understand the results of the Mutation Tests. Compared to the in-class activity on PIT, this article uses a much simpler example to demonstrate mutations and presents the results of its Mutation Tests in a much clearer way. This has helped me better understand the fundamentals of Mutation Testing, and I think I will be able to use tools like PIT more effectively as a result.
Throughout this semester we have learned about how to create tests in a mostly “manual” way, today I want to explore an article that serves as an introduction and overall guide to automation testing. I especially wanted to learn about this topic since it has repeatedly come up in other articles I’ve read on this website.
Overall, I found the content of this article to be great and I think it thoroughly covers every aspect I can think of, and acts as a great beginner’s guide to this topic of automation testing. The author methodically covers everything on automation testing from the benefits of switching, to figuring out which areas of your testing should be automated.
Looking at the section of this article that lists the different areas automation testing can help is particularly interesting to me as most of the types of testing here I am unfamiliar with (and aren’t covered by our testing course) but would like to know more about. This includes areas such as regression testing, which I just learned about, and performance testing. From this article it seems that automation testing seems to help particularly with cross-browser testing. This made me think about how different web browsers are tested which is something I have only done by manually checking that the application functions properly by going through the program as a user. In retrospective it makes sense that some automated tool can make this much easier and I would like to see how this works more.
I think one of the most important points the author makes (and states many times) is “do not aim for a 100% automation”, which makes sense as the author explains how it is not necessarily feasible or beneficial to have all of your tests automated. Furthering this point, the other interesting part of this article is how the author explains that manually testing is better for certain aspects of software. After reading these reasons, I completely agree with the author that certain areas such as testing the actual user experience of a program makes more sense to test manually instead of automating. Another aspect I really like about this article that I like is that the author continues throughout the article to focus on the practicality of automating testing from a business standpoint and takes into account the amount of investment and return on investment that can be gained by automated testing.
This article has certainly made me more interested in testing automation and I would like to see how tools implement this, especially in areas the article says can really benefit from this such as regression or browser testing.
An algorithm is a set of rules to be followed in order to solve mathematical problems in numerous steps that usually involve repetition of an operation. Sometimes algorithm problems do not show up at the beginning of a project. As Steven S. Skiena states, different programmers find them out as subproblems, which appear to be … Continue reading Read Constantly→
The pattern “Craft over Art” is the idea of choosing the craft of programming and making thing functional. Rather than choosing art of programming and making the program look beautiful but not so functional for the customer. Even though you may find an opportunity taking your customer problem and making something nice that will impress your coworkers, it is best that you put the customer needs before your own selfish wants or needs. When it comes to dealing with customer your goal should always be choosing creating a functional valuable product, rather than something else that only advance your own self interest. When dealing with customers it is more important to choose the craft of software development rather than feeding that desire to creating something beautiful, yet not truly functional or deliverable in the real world. This pattern is not telling you that things can’t be beautiful it more saying that whatever you build for your customer must be functional and useful, therefore you must be willing to sacrifice beauty over utility. “The more useful a piece of software, the more important it is that the software be high quality. But quality takes time. You will have to work toward a suitable level of quality by repeatedly making trade-offs between beauty and utility.”
My Reaction
This pattern helps you understand the impotence of building “Craft over Art” because it reminds you that creating something useless yet beautiful is not craftsmanship. I agree with this idea because crating a useful software program far more important than a beautiful non-functional one. I found this pattern to be interesting but also useful and thought-provoking. This pattern has definitely changed the way I think about my profession and the way I think, the reason being is that I should always be willing to sacrifice beauty before sacrificing usefulness.
Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.
I haven’t written a blog post for MINIX3 in some time (sorry Professor), and I figured that it would probably be wise to wrap up what I managed to complete this semester after I managed to get past all the stress I was feeling.
About halfway through the semester I started meeting weekly with my professor in order to discuss ways to approach my project. He knew I was pretty darn stressed about it, but was also pleased with how much I had learned about MINIX3 and Operating Systems in general. When we started meeting, I hadn’t done any actual programming in the scheduler, and I was still fuzzy on how the whole scheduler worked as one unit. I had also not realized this at the time, but the scheduling algorithm in the official MINIX3 Book was an older version. It doesn’t reflect the design found in this report, which describes the current scheduling algorithm (found in versions 3.3.0 and newer, I believe). This was adding to the confusion in how to approach the system, because I was getting my information on the implementation of the scheduler from both sources.
I’ve talked about this a bit in my previous blogs, but I figured I’d recap in this one now that I have a better understanding of the system. In the official MINIX3 book, the scheduler is still built into the Kernel. This meant that any scheduling changes that were to be implemented involved editing kernel code, which could end up being pretty complex in the event of errors, etc. What the scheduling report outlines is the move of the scheduler into the user mode level of MINIX’s layered design system. There still is a small default scheduler that had to be implemented, but the main scheduling policy is implemented within the user mode scheduler.
Let’s talk scheduling policies. Both the kernel-level and the user-level schedulers implement a Round Robin scheduling algorithm by default. As outlined in the report, the easiest policies to implement with the user mode scheduler are round robin, priority, staircase, and some other queue-based policies. Whilst I was googling information about implementing priority-based algorithms, I found this wonderful project done by a GitHub user named Akshita Mittel. It includes a few test files and the changes necessary to make to some of MINIX3’s files in order to implement different algorithms. It is very similar to the project I had intended on doing, so whilst I did not copy it directly (licensing and copyright issues and whatnot), I did use it as a resource for implementing my own project.
Since I wanted to deviate my project slightly from the resources I found online, instead of just implementing more than one scheduling policy, I elected to compare the default scheduling policy with a priority scheduling algorithm, and vary the number of queues by +- 25%. This left me with 3 variations of the default Round Robin policy — one with 12 queues, one with the standard 16 queues, and one with 20 queues. It also left me with 3 variants of a scheduler using a priority algorithm, again with 12, 16, and 20 queues. My goal was to run the same test across each of these 6 variations and see if there was some notable runtime difference.
Before I go into the test, I figured I’d explain the difference between Round Robin and Priority style scheduling. Round Robin policies assign each process within the priority queues a time slice, called quantum. As processes run out of quantum, they’re moved to a higher (the higher the number, the lower the priority) priority queue. In MINIX3, after a certain number of ticks, the queues are rebalanced. This means that all processes who have had their priority changed get that priority reset. The difference between round robin and priority scheduling algorithms is fairly simple — round robin policies aim to be fair, which is why they implement queue feedback. Priority policies are designed without fairness in mind. You might want some processes to always have the highest priority. Therefore, it simply disables process feedback from happening. Processes don’t move around between queues. A diagram of the structure of the priority queues are shown below.
Based on an image from Operating Systems: Design and Implementation by Andrew S. Tanenbaum
The test I used was based on Akshita’s that I found on GitHub. The test program would log system time, do some work with a process, then log the system time again, and find the difference between the start and end times. I found the average running time for 100 tests for each of the variations. The results are displayed below.
As you can see, there wasn’t much consistency across the tests. I’m sure that, before I even ran the tests, I could have reasonably come to the conclusion that there wouldn’t have been much of a difference in run times given my particular approach. The test I ran was mostly CPU bound as opposed to I/O bound, which very well could have made a difference. I think CPU bound tests could have made a bigger impact if I had implemented a different policy than priority. On top of designing a better test for what I was doing in particular, I think that theoretically the number of queues within a round robin scheduler wouldn’t make much of a difference unless the processes existed within them for a very long period of time. Also, I think that the number of queues within a priority scheduler wouldn’t make a significant difference either, since processes tend to live where are they spawned. Aside from the crowding of the queues, I don’t see it having a large impact on the overall runtime. Therefore, I think that the results I got make sense.
I’m not upset that my small “research project” didn’t yield great results. The point of this independent study was for me to better understand operating systems, as I felt as though I was seriously lacking in that area. While I know there’s still a tremendous amount of knowledge to be gained in OS’s, I’m happy with the work I did this semester and feel far more confident when discussing OS concepts in general. It was a very stressful project at first, but now that I’ve wrapped it up, I think it was absolutely worth it. Hands-on operating system practice is a great way to go about learning the subject. In fact, this independent study has sparked quite a bit of interest in systems programming for me, and I’m looking forward to continue learning about it in the future!
(Side-note, this is my last school-related blogpost. At first, I felt extremely uncomfortable writing these things. Now, I think it’s something I’d like to do once a week, or at least regularly. I appreciate my professor requiring us to start these blogs — writing is something I never really saw myself doing enjoying, and after doing it for a couple of semesters now, I get it. Who would’ve guessed that recording what you learn is both both enjoyable and rewarding. Thanks, Professor Wurst!)
Today we will once again be continuing our journey into software apprenticeship patterns. From last week, we will continue on to the next pattern, Expose Your Ignorance.
This pattern is all about once you have gotten yourself onto a team where you can learn more from your fellow teammates, presumably in a job. The problem is that well… you are ignorant. You need to deliver and you have a lack of knowledge in whatever language or technology you need to be able to deliver.
The offered solution is fairly simple, ask questions and don’t be afraid to show that you are ignorant in a particular subject. You should recognize that it is human to want to appear competent and not appearing competent is not a bad thing. It is all part of the learning process. As a software craftsman, you need to know many different subjects and technologies. The pattern suggests that people who are uncomfortable with the learning process of appearing ignorant become experts instead. They seek out expertise in one particular field and never venture too far from it. Experts are important but the journey of a software craftsman is much longer and requires a broader scope of knowledge. You become an expert in one or several subjects along the way but that is not the ultimate goal. For a software craftsman, one of the most important skills is the ability to learn. To solve this problem the pattern suggests writing down a small list of thing you don’t really understand about your work and posting it in public view.
This pattern I find interesting. What I found most interesting was the distinction made between the software craftsman and the expert. The pattern admits that a software craftsman will likely become an expert in a few subjects but that is not the ultimate goal. The goal is not explained in the pattern (I’m sure it is explained at the beginning but I have forgotten it at time of writing) but the difference between the expert and the craftsman is that the expertise is not the goal. A craftsman goes further than becoming an expert and goes on to craft with the expertise of many under his belt where the expert gains expertise and then rests on his laurels. I do also appreciate the part where it states that by admitting ignorance it will increase your reputation greater than “fake it until you make it” will.
That’s it, for now, my fellow readers. Until next time!
For my last apprenticeship pattern blog post, I felt that the pattern Sweep the Floor was appropriate given where I currently am at in my career, given that I hope to be starting in the very near future. This pattern refers to the scenario in which you’re a new apprentice on a project or a new member of a team and you’re not sure what your place is in the team, so you want to contribute and earn the team’s trust. The solution to this is to volunteer for simple, necessary tasks that no one else wants to do and to make sure to do a great job with them. Of course, you want to make sure that you don’t end up only doing menial tasks that no one else wants to do and that you’re given more challenging assignments after proving yourself “worthy”.
As I said earlier, this pattern is probably one of the most applicable to me at the moment, because once I start I can see myself in almost the exact same scenario as described in the pattern. I always figured that most junior level roles start with you being assigned simple tasks like one-liner bug fixes to help you get acquainted with the code base, but I hadn’t considered that it would be a good idea to take on tasks like literally sweeping the floor in order to build confidence as a member of the team. Of course, I don’t entirely agree with consistently taking on tasks that aren’t relevant to what you want to work towards, but there’s merit in doing menial labor when you happen upon it. As long as you make sure to let it be known that you want to be challenged and not just be comfortable standing still working as the team’s gopher.
Overall, I would say that it’s very likely that I’ll end up using this pattern in the very near future, so hopefully I remember to avoid the negative consequences of applying it. In fact, I wouldn’t be surprised if this pattern would be useful for me anytime I happen to enter a new team, not just my first one.
