I decided to read “Record What You Learn” for this week’s post. This one is pretty self explanatory, record what you learn. The pattern says to do just this, and explains that this is a way to review key learnings throughout your journey of software development craftsmanship. The pattern also notes that it is important to not let your writings become a graveyard for what you have learned. By this, they mean that you should consistently go back and review what you’ve written in the past to possibly amend the posts, or to find links to other notes you have written.
I agree that this is a very valuable “study” technique and it works for all facets of learning. The most difficult part of this, is that this is a very time intensive way to remember everything. As you learn more, the bigger the library of written lessons gets. This mean that every time you learn something, that review session gets longer. I think that this means that it is important to acknowledge that you simply will have to relearn things from time to time, but documenting what you’ve learned for higher level topics, is a great way to save time in the future.
While I do see how this could be difficult for an individual who is learning vastly different and often irrelevant topics when compared to each other, this is definitely something that can be used as part of a company project wiki. Large companies are constantly hiring new personnel who have to play catch-up to learn a code base as well as the coding styles of their peers. Having some sort of blog or wiki for the project could help these new-hires get acquainted with how the company functions and how to solve problems that are specific to the particular stack and business logic that the company is utilizing.
I do not know if I see myself personally following this advice, because this is not really my learning style. I tend to learn something by repetition instead of documenting what I’m doing. However, I do recommend that anyone who learns well via methods like flash cards, studying notes, etc, give this method of learning a try. It could be quite useful to someone who succeeds` when applying these learning methods.
For this particular post, I was in the mood to cover something that we haven’t specifically covered in the class, stress testing. I found a post on guru99.com that covers stress testing as a whole. The article covers aspects including the need for stress testing, as well as different types of implementations of stress testing. I particularly enjoyed this post because it covers a broad realm of topics within this particular area of testing, while being easily understandable for someone who may have no familiarity with the concept whatsoever.
Stress testing is often associated with websites, and mobile applications that may experience abnormal traffic surges during some predictable times and sometimes completely unpredictable times. Stress testing ensures that a system works properly under intense traffic, as well as displays possible warning messages to alert the appropriate people that the system is under stress. The post points out that the main end goal of stress testing is to ensure that the system recovers properly after failure.
A few different means of stress testing are, application stress testing, systemic stress testing, and exploratory stress testing. Application stress testing is pretty self explanatory, this test basically looks to find any bottlenecks in the application that may be vulnerable under stress. Systemic stress testing tests multiple systems on the same server to find bottlenecks of data blocking between applications. Exploratory stress testing tests for some possible edge cases that are probably unlikely to ever occur, but should still be tested for. The post gives examples of a large number of users logging in at the same time and when a particularly large amount of data is inserted into the database at once.
I knew that this kind of testing had to exist because of my experience with certain applications. Years ago, when a new Call of Duty game would come out, it was often unplayable for the first day or two, due to the network system being completely offline or simply unstable. Now, presumingly they have figured out their stress testing as the service does not go offline on release and hasn’t for several years. Personally, I don’t know if I will particularly be involved with stress testing in my career but the exposure to this area of testing cannot hurt. I do recommend that people take a look at this post on guru99.
Here is a link to the original post: https://www.guru99.com/stress-testing-tutorial.html