This week’s blog topic was chosen simply because I had zero knowledge of the term/topic. Jake Holy’s blog on Stochastic and Property-Based Testing blog covers the uses of each testing and effective tools used to implement each. Stochastic testing refers to the testing method that uses random inputs to test the behavior of the program. Rather than using predetermined inputs for test cases, stochastic utilizes various inputs to find unexpected bugs in the program. The main purpose of stochastic testing is to uncover errors through unorthodox methods. This method offers a wide testing coverage by testing all possible scenarios that might go unnoticed with traditional testing.

Property based testing refers to the method of testing by describing what the software should do rather than creating distinct test cases. Initially, testers establish properties that describes what the code should always do. This method of testing utilizes tools that automatically generate test cases to test these properties. After generating these cases, random inputs are utilized to ensure the properties are followed. The benefit of this testing method is testers are only required to declare the properties the code must follow. Instead of manually creating test cases and risking the possibility of missing a test case, these cases are generated for them. Property based testing guarantees effective test coverage. Additionally, this form of testing allows testers to focus on the abstraction and behavior of their code, allowing for a more robust product.

The blog goes in-depth with various testing tools, for example, a testing library created for the Haskell programming language called QuickCheck, which allows developers to write properties for their code which is automatically generated into test cases. QuickCheck has become a very popular tool to use for testing due to its automation, which is why it has been ported to other programming languages like Python and Scala.

The second tool that the blog mentions is Stimulant for Clojure. Similar to QuickCheck, Stimulant allows developers to define properties and it automatically generates test cases to test your program.

One thing that is mentioned in both testing libraries is shrinking. Shrinking refers to the method of finding the smallest input of a failing case, allowing developers to precisely pinpoint areas in the program that is causing the test case to fail. It is crucial that developers know their program has failed a test case, but it is even more crucial that they know why, so they can effectively fix the problem.

Blog: https://blog.jakubholy.net/2013/06/28/brief-intro-into-randomstochasticprobabilistic-testing/

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.

  This week I chose a blog post that covers the difference between black box and white box testing. In general, testing a program is a vital pillar in producing reliable software to customers. Testing helps uncover and mitigate defects in programs. Blackbox testing refers to the testing technique where the tester has zero knowledge of how the internal source code works. This technique involves the tester executing the code and analyzing the behavior and functionality. The reason why this practice is referred to as “black box testing” is because you can’t see in the box, similar to the tester not having access to the code. The benefit of black box testing is anyone can be a tester. Since the tester does not need knowledge of the internal code, there is not limit to who can be a tester. Non-programmers can execute the code and verify the results. A major disadvantage of this testing is the inability to pin point what caused the error. Since the tester has zero access to the internals, the only thing they know is the program doesn’t function as intended.

  White box testing, also referred to as clear box testing, is a testing method that involves having access to the internal workings of the code while testing it. This testing method requires the tester to have prior knowledge about programming to analyze the source code. White box testing focuses on the internal logic, code structure, and execution paths. This method of testing allows testers to pin point where the program failed, unlike black box. White box testing excels in scenarios where the accuracy and function of the program is crucial, because developers can easily debug. The main disadvantage to white box testing is it can be time consuming, since testers have to first understand the code’s intended function and analyze each line.

  This information is very useful to know when we cover and simulate each type of testing method in class. It’s crucial to know the disadvantages and advantages to a testing technique before deciding the most suitable one. For example, if you’re testing the user experience of a website, white box testing wouldn’t be the best option because the user isn’t going to access your websites source code. Black box testing would be the most effective technique because it focuses on the functionality of the website. Both of these testing techniques help developers and organizations deliver software that is reliable, meets user expectations, and complies with industry standards and regulations.

Blog Post: https://www.bairesdev.com/blog/black-box-vs-white-box-testing/

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.

  This last blog post I decided to revisit an important topic in class: Agile Project Management. This topic initially piqued my interest due to my lack of prior knowledge about how crucial project management can affect the product of a project. The blog post I chose highlights the Agile Manifesto and the twelve key principles to Agile. In addition, the post discusses the benefits of having a project management, for example, structured project management plans remove the fear of making a bad decision when a problem arises. Agile in particular helps improve collaboration and productivity between parties, in turn, producing a better/more refined final product.

  You might ask yourself, “These benefits sound great, but you haven’t told us how to implement Agile”, luckily this blog post dives into various tools that make project management easier. The first tool, Workast, provides features that let you create tasks for the team, set due dates, assign tasks to certain people, and even host meetings through Slack. Similar to lists in GitLab, Workast allows team members to group tasks into lists and move them according to its completion status. This tool is a great way to visualize project progression and productivity. The second tool mentioned is Trello, similarly, Trello allows teams to create to-do tasks and post them on a timeline. Lastly, we have a program called ClickUp which allows users to select a scrum workflow style. Managing sprints, tracking sprint progress, and creating daily scrum boards are just some of the features ClickUp offers.

  One thing that is the most important is having a place to manage your sprints. Having easy access to information like total estimation of the sprint and spillover tasks are crucial to analyzing project progression. After researching the three tools that the blog mentions, I believe ClickUp gears more towards an agile/scrum workflow.

  After reading the blog post, I’m curious to learn about other types of project management techniques and guides. It is no doubt that Agile is an effective approach to optimize project production, however, the Agile methodology does come with its disadvantages: poor long-term planning, dependency on the customer, greater demand on development team. Because the Agile methodology is flexible with its timelines, it’s difficult to predict when a project will be finished. Agile also utilizes feedback from the customer to ensure a product is beneficial to a customer. Team members are expected to meet daily at the same time, putting pressure on developers to stick to one schedule despite a having a duties that are constantly changing.

  Blog Post: https://www.workast.com/blog/guide-to-agile-project-management/

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.

This week’s blog post I decided to research more about linting for non-inclusive language. The medium I selected is a blog post by Michael Bachand, an engineer at Airbnb. “Building an Inclusive Codebase” dives into the techniques engineers at Airbnb are taking to make their work environment more inclusive for everyone. In order to create a more inclusive platform, the development team must also be inclusive. To start, the team has increased the diversity in their teams to accommodate every demographic. Bachand emphasizes that building a diverse team will help empower both Airbnb’s hosts and guests. Inclusivity goes beyond forming a diverse team however.

The team at Airbnb discovered an issue with non-inclusive language in their codebase. After working with employees affected by these terms, the team presented a proposal to the Chief Technology Officer of Airbnb and got the approval to refactor the code to be more inclusive. Michael Bachand stresses that “acknowledgement and resourcing from the highest levels of management legitimized this effort”. The support from management and the CTO prioritizing the task produced a healthier working culture across all teams.

Airbnb’s development team broke down this problem into two key parts: preventing the use of this language and eliminating the existing language. One essential tool that was utilized was the woke linter which checked each pole request for non-inclusive terminology and suggested alternative terms to promote belonging. The team now had a proper tool to use, however, they didn’t send the tool to every developer immediately. The team took a unique approach by slowly distributing the tool to expert developers. These developers decided which directories the linter should access and which should be excluded.

Before our in-class activity on this topic, I never thought about how my sentences might unintentionally offend or upset someone. This topic has opened my eyes to how crucial having a linter tool is. Many of these non-inclusive terms sound offensive without the right context which is why every developer should utilize a linter of sort. Reflecting on the problem addressed by Airbnb, having the support from the CTO is reassuring to know that your work is valued by the company. I believe all companies should strive to create a sense of belonging in their work environment, no matter how big or small. I can confidently say that the information I learned today will stick with me for the rest of my career.

Blog Post: https://medium.com/airbnb-engineering/building-an-inclusive-codebase-bbaa2315e5b8

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.

This week’s topic I decided to choose a blog post about the writing of clean code to correlate with what we’ve been learning in class. The blog post, published by Jacob On Software, details how the writer has been reading Clean Code by Robert Martin. This handbook identifies the significance of writing clean code, as well as, how to properly write readable and professional code. Jacob On Software takes a unique and effective approach to teach readers; refactoring one of his old projects. Jacob states in his blog post that during this project, he was forced to learn how to create a full stack web application in just three weeks, resulting in him rushing and writing not so clean code. The blog post highlights that other contributors working on his project will have strenuous time trying to decipher his messy code, hindering the development process and evolution of the software.

Looking at an image of the his code, we can see that the name of his functions are descriptive of what they accomplish, however the functions themselves have too many lines of code, which is a crucial aspect detailed in the Clean Code book. Having functions that are thousands of lines long makes it a nightmare to understand what the function is doing. Clean Code emphasizes that functions should be small and straight to the point. Jacob fixes his code by splitting up the function into smaller functions. Additionally, Martin’s Clean Code stresses that a function should do one thing. Previously, Jacob’s function was performing multiple operations like holding data and updating it. These operations were split up into their own functions, allowing others to instantly understand the purpose of these functions.

Further into the blog, Jacob talks about the formatting of his code. The more lines a file has, the harder it is to understand. Users only have a limited amount code that will fit on their screen at once. If the developer has to constantly scroll up and down through hundreds of lines just to understand your code, you are not writing clean code. The same can be said horizontally, lines in your code should not be extending off to the right of the screen.

I chose this topic because after looking at the examples of bad code and good code in class, I admit that most of my code that I’ve written in other classes would be considered bad code. Non-descriptive variable/function names and multiple operations in functions have definitely been a weakness in my code. It’s crucial to write clean code as software developer working in a team so other team members can easily understand your code. I plan to use this information as a guideline on how to write more descriptive and readable code in the future.

Blog Post: https://medium.com/codex/reading-clean-code-week-2-643641e4dc28

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.

This podcast by All The Code discusses the use of GitHub and GitLab APIs for managing software development projects. The host of the podcast conveyed his disdain for GitHub’s API when he was involved in a project that utilized GitHub to share images and video links. Users had to request access to the repository in order to access the content, which the speaker did not like. He emphasized that requesting access on GitHub isn’t user friendly to someone who isn’t experienced with the site. When the hosts talked about GitLab, they described the platform as “amazing” and its ability to do “wonderful stuff”. Additionally, The speakers compared both GitHub and GitLab’s documentation and found GitLab to be the all around better platform documentation wise. Lastly, the podcast hosts argue that GitHub is ideal for large companies as GitLab is suited for smaller companies/teams. I chose this specific podcast because I have worked with both GitHub and GitLab in this class and can’t seem to prefer one over the other. I will say that I was more comfortable with traversing GitHub compared to GitLab. Although GitLab is considered to be easier to navigate, I often find myself struggling to access projects and repositories in different groups within GitLab. I’m hoping as time comes, I will get more comfortable with navigating the platform. This podcast has changed my view on GitLab, knowing that GitLab is more user friendly with documentation is extremely important to consider when choosing which platform to use mainly. Of course, companies will expect their teams to use the same platform to prevent any conversion issues. Having solid documentation in your software development projects is vital so new developers/users can easily understand the project and its goal. Going forward with this information, I will experiment with the various features GitLab has to offer regarding documentation. For example, GitLab has a feature called GitLab Flavored Markdown (GLFM) which gives you the ability to render certain text with a style. GitLab Flavored Markdown allows you the change the color of text, add emojis, create detailed lists, and more.

Selected Podcast: https://www.youtube.com/watch?v=LsRZiWPPiEQ&ab_channel=AllTheCode

From the blog CS@Worcester – Computer Science Through a Junior by Winston Luu and used with permission of the author. All other rights reserved by the author.