Author Archives: Griffin Butler

Software Development Capstone, Final Sprint Review

For my final apprenticeship pattern, I wanted to find one with a message that I could take with me into my future work with software development that would continue to help me improve after my academic career has ended, as well as even years into a professional career. Chapter 5’s Expand your Bandwidth touches on this topic, and explains how one can expand their knowledge beyond the context of what is needed in a specific project or job.

With regards to experience and knowledge, the two common pitfalls a developer can find themselves in are having only an understanding of the tools needed for their specific role, and only possessing a surface level understanding of the knowledge they have. Personally, I believe that these two problems have the same root cause; when you only concern yourself with what you need to know for your work, your knowledge stagnates and you exclude yourself from experiences that would improve your craftsmanship.

The book places emphasis on the value of the desire to go further and learn more in unique and unfamiliar ways. The common examples of attending professional development and technical conferences and events, as well as using online courses and videos about new topics, are present. However, the idea of looking through forums and mailing lists to find other people’s problems and replicating them to solve them, was a new one for me. Of course I’ve used sites like StackOverflow before, so I knew that this was something one could do, but I hadn’t realized the value it had in improving my own knowledge.

Expand your Bandwidth begins with a quote from Jim Highsmith, author of Agile Software Development Ecosystems:

“Learning about what we don’t know is often more important than doing things we already know how to do.”

A great way to summarize the value of going the extra mile to learn more, and a message I want to keep in my mind for my future in software development.

In our final sprint, I focused on the integration between the database containing the visit info and the backend code we’ve developed to generate the report. This meant refactoring the backend code to accept and parse data from RabbitMQ, as well as handling the connection itself. The connection between RabbitMQ and the backend has been causing issues, and needs further debugging work before it can be deployed.

Reflecting on the sprint as a whole, I’m not completely satisfied with my own work. The original plan had been to develop testing for the backend code during the sprint, which I spent two weeks working on before deciding the connection between the database and backend was more critical to the functionality of the project, and needed priority. Compounded with the problems that arose during development and debugging, I wasn’t able to finish the work within the duration of the sprint. I believe choosing at first to work on testing was a mistake on my part, and that poor planning contributed to not meeting the goals my team had set. However, I also believe that the work that was done on the backend code was productive and is very close to completion. For future work, I want to improve my planning and time management by allotting myself some time during the sprint planning as extra time, in case a feature or issue ends up taking longer than anticipated. This way, I will be able to afford setbacks such as those that occurred this sprint.

Link to updated most recent commit

From the blog Griffin Butler Computer Science Blog by Griffin Butler and used with permission of the author. All other rights reserved by the author.

Write Code that’s Readable. Please.

Let’s talk about something that affects programmers at all levels, on all codebases and projects: readability. Specifically, the balance between code that is fast and resource efficient and code that is easily understood and maintained.

First, readability. It’s a given that any code produced and delivered in any professional capacity is almost certainly not being written by a single developer. Therefore, good developers will write code that others will be able to understand and pick up what the intended behavior of the code is. Commenting, appropriate use of whitespace and indentation, and effective developer documentation can make code easy to work with, for anyone.

Here’s an example of two Python code snippets that both return the summation of a given array, but are structured quite differently:

Code 1:

# Returns summation of given array of numbers

def sum_numbers_readable(nums):
   total = 0    # Initalize starting total
   for num in nums:   # Sum all numbers in array nums
      total += num
   return total   # Return sum

print(sum_numbers_readable([1, 2, 3, 4]))

Code 2:

def sum_numbers_fast(nums):
   return sum(nums)
print(sum_numbers_fast([1, 2, 3, 4]))

See the difference? Both pieces of code do the same thing and achieve the same output. Code 1, however, contains comments describing the intended behavior of the function and the expected parameter type, as well as step-by-step what each line of code does in the function. Blank lines and proper use of whitespace also divide the code into relevant sections. Code 2, on the other hand, has no comments added, poor use of whitespace (or as poor as Python would allow), and uses the sum() function from Python’s native library. While the intended behavior of this function is pretty clear, this may not always be the case.

Take a more extreme example, just for the fun of it: go write or refactor some piece of Java code to be all on the same line. It’ll compile and run fine. But then go ask someone else to take the time to review your code, and see what their reaction is.

On the other hand, we have code efficiency and speed, generally measured in runtime or operations per second. Comparing our two code snippets using a tool like perfpy.com to see performance, and we find that the second, less readable code executes faster with a higher operations per second. (931 nanoseconds vs. 981 nanoseconds and 1.07 op/sec vs. 1.02 op/sec. Not a huge difference at all, but this scales with program complexity).

This gives us some perspective on the balance between performance and readability/maintainability. It also helps to keep in mind that performance and readability are both relative.

Looking back at our two Python snippets, most developers with experience would opt for the second design style. It’s faster, but also easily readable provided that you understand how Python methods work. However, people just learning programming would probably opt for the more cumbersome but readable first design. With regards to performance, the difference in runtime could be a nonissue or it could be a catastrophic slowdown. It depends entirely on the scope of the product and the needs of the development team.

As a final rule of thumb, the best developers will balance readability and efficiency as best they can, while above all else remaining consistent with their style. When looking at possible code optimizations, consider how the balance between readability and performance could shift. The phase “good enough” tends to have a negative connotation, but if your code is readable enough that other team members can work on it, and fast enough that it satisfies the product requirements, “good enough” is perfect.

Refrences:
Lazarev-Zubov, Nikita. “Code Readability vs. Performance: Shipbook Blog.” Shipbook Blog RSS, 16 June 2022, blog.shipbook.io/code-readability-vs-performance.

From the blog Griffin Butler Computer Science Blog by Griffin Butler and used with permission of the author. All other rights reserved by the author.

Software Development Capstone: Sprint 2 Review

When choosing an apprenticeship patten to write about for this sprint, Chapter 4’s Rubbing Elbows stuck out almost immediately. The problem raised by the authors is one for those who prefer to work independently when writing and developing software. The agency to decide which direction to approach a task, coupled with the efficiency of being the only decision maker, is appealing, and developers can absolutely be successful working this way.

The downside is, those who work alone cannot draw on the experience and knowledge of others, and place a hard limit on their productivity. Additionally, there are so many micro-techniques that can sometimes only be learned through partnership; small strategies that on their own are insignificant but accumulate over time into a much stronger knowledge-base.

The balance between independent and team focused development is something that I would like to continue to work at. Over the past sprint, I believe I did a better job of communicating progress on my issues and problems I needed help with. That said, I could always be better. I would like to place more focus on making myself available to my team mates for assistance with issues. Partially due to the desire to be productive and deliver a successful product, but also due to the ideas outlined in the Rubbing Elbows pattern. I’ve found over the past sprint that an area I’d like to improve in is the more practical knowledge that I would normally pick up working in groups and communicating with my team.

Some tasks I accomplished during the sprint:

  1. Completed JSDoc Environment setup: Our backend code now uses JSDoc compatible tags in comment lines, which is used to auto-generate developer documentation. Link
  2. buildReport outputs correct report totals with headers: the buildReport class in our reporting system backend correctly formats report headers and calculates correct tallies for visit info. Link

For the final sprint, I plan on finalizing the buildReport backend code and designing tests to be ran on the function. The final component is the connection between the backend code and the database, which I also will be working on with my team. Because we are now in the final sprint, my main overall goal is to finish developing the project as far along as time allows before making sure the environment is prepared for future work.

From the blog Griffin Butler Computer Science Blog by Griffin Butler and used with permission of the author. All other rights reserved by the author.

Software Development Capstone Sprint 1 Review

After the completion of our first sprint, I believe our team performed very well. There were no issues left in the sprint backlog at the conclusion of the sprint, and, equally important, our understanding of how the Thea’s Pantry reporting system needs to work has grown significantly.

The divide and conquer approach taken worked well for us. Splitting up the issues gave us more flexibility in how we would approach our particular task. For me personally, I was able to do my research and development at a faster pace as opposed to having multiple people working on the same file. On the other hand, our team meetings were extremely useful for getting feedback and help with development issues. Having more sets of eyes to look at a problem often times got issues resolved quickly. The team dynamic in programming and software development, in my experience, is usually a balance between avoiding a “too many cooks in the kitchen” situation and making sure the team is communicating and engaged with each other. I believe our team balanced this reasonably well.

That said, I believe we should work to improve our inter-team communication. Having a good sense of what other members are working on is important if we’re going to continue to divide issue assignments. This is something I should work on specifically too. I want to avoid the habit of staying head-down in my laptop working, and do a better job of communicating on the status of what I’m doing, especially when working on my own.

My main focus for development was writing the code to create a properly-titled .csv report file to be sent and downloaded onto the user machine when the API call is executed. Here are links and descriptions on specific things I accomplished this past sprint:

  1. getReport API Endpoint – Developed and tested RestAPI endpoint to retrieve report file.
  2. buildReport Function – JavaScript function to build the report itself from RabbitMQ data. Currently, this generates a blank .csv file with the proper title with relevant dates of the report.
  3. JSDoc API Documentation – Began setup and use of JSDoc, a markup language for JavaScript to generate developer documentation.
  4. JSDoc Deployment Shell Script – Shell script to aid in building documentation files.

From the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave H. Hoover and Adewale Oshineye, the section regarding protecting one’s passion for software craftsmanship stuck out to me. Getting tired or frustrated when writing code is more or less inevitable; being able to separate those feelings from the field as a whole is key. The book mentions the idea of “Drawing Your Own Map”, a strategy for mitigating burnout. The core idea is setting limits for yourself can be as important as setting your goals. One can define the boundaries in which they allow themselves to work within, as even with short-term consequences (the book mentions missed raises and unhappy coworkers as examples), walking The Long Road rewards pace and longevity, not speed. I firmly agree with the statement made by the authors; quality craftsmanship does not come from short, intense periods of work followed by burnout, but by maintaining a steady pace forward across a decades-long career.

From the blog Griffin Butler Computer Science Blog by Griffin Butler and used with permission of the author. All other rights reserved by the author.

The Key Pillars of API Testing

Application Program Interfaces (APIs) provide the framework for how pieces of software communicate with each other, as well as the user. Therefore, proper API testing is key in delivering a reliable product. In a blog for Medium.com, Andrey Enin says that around 3/4 of product functionality involves designing the API correctly. He also lists some of what he considers to be the core ideology behind how these tests are designed and conducted.

Firstly, an API, or any program, must be tested to ensure it works properly. Functionality testing involves sending requests to the API and comparing the results with the intended specifications. End-to-end tests are useful in this case; multiple calls are chained together, often across multiple APIs, to replicate the end user experience in order to bring bugs to the surface.

Performance testing is another point. Measuring how the software and API perform in high use cases or under high traffic loads improves stability by identifying issues in a controlled environment. That is, better to break it now, rather than after delivering the product. Compatibility testing falls under a similar umbrella. Differing and often “unexpected” requests are sent to the API to test how the program responds. While performance testing can involve stress-testing and compatibility testing often involves testing the API in different environments, the philosophy is the same: better for it to break now, when fixes are easier to implement as opposed to post-release.

In a similar thread is error testing. Quality software will be able to handle errors without suffering catastrophic failure. With API testing, this generally comprises of sending intentionally incorrect or malformed requests to ensure the interface returns the relevant error responses.

Testing the usability of the API is somewhat different, in that it refers to the developer experience when working with the interface. Some of the examples listed in the aforementioned Medium.com post include adhering to OpenAPI specifications, uniform naming conventions, and making sure documentation is comprehensive and unambiguous. The unique perspective of focusing on the end user experience helps create developer-friendly interfaces that are popular and remain relevant in the industry.

Finally, security testing involves checking to make sure the API carries data securely and is protected from unauthorized or malicious use. Transmitting data over HTTPS is a common method of protecting sensitive information, and is generally considered standard for most web traffic. Testing the interface’s authentication methods for vulnerabilities protects against outside access to the same sensitive information as well as preventing unauthorized use of the interface.

As a final note, it’s helpful to consider these testing approaches as a foundation for a standard of quality assurance, as opposed to a check list to follow. Specific tests may address multiple different parts, and different approaches may take importance over others. Considering each different aspect of API testing over the course of the development cycle, outside of the testing environment, helps ensure the quality of the final product.

References:

Enin, Andrey. “Field Notes in API Testing, Part 1: Areas of Focus.” Medium.Com, Medium, 25 Jan. 2025, adequatica.medium.com/field-notes-in-api-testing-part-1-areas-of-focus-46b516ccacf4#4439.

From the blog Griffin Butler Computer Science Blog by Griffin Butler and used with permission of the author. All other rights reserved by the author.

Reflections on Apprenticeship Patterns

While reading parts of the book “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye, there were a couple points that stood out to me when reading and comparing to my own experiences and knowledge.

An important point brought up by the book in the first chapter is how understanding the logic behind why things are done allows people to adapt to unfamiliar problems. Knowing the “spirit of the rule” allows for people to create new rules as needed. This is a point I personally feel strongly about. Knowing what to do is, really, only an issue of understanding instructions. Having a knowledge of the reasoning behind different practices allows you to apply that understanding to other problems.

Programming is a great example of this. It’s easy enough to follow a guide on writing code to follow some specific function, however, good developers will put effort into understanding how the code works, and will be able to replicate what they know later, or apply it to different situations. Someone who only knows the specific steps to writing the code doesn’t understand how it works, and most likely won’t be able to apply their experience outside of that specific use-case.

Another interesting point that I personally hadn’t considered was that apprenticeship in software development is much better approached as a mindset, rather than a formal form of schooling. The book describes that newcomers will have to “create their own opportunities for learning” in the working environments they find themselves in. I’ve understood that it’s important to have a desire to learn more than what may be expected, but the perspective of creating your own learning experiences, outside of more standardized curriculums but within the same environment was interesting.

This point also carries over into the beginning of chapter 3, where one of the authors describes how after connecting with other Perl developers, he was impressed not just by their knowledge, but by the speed at which they were still learning. Symbolically, the stacks of certificates and qualifications would become buried under book printouts and notes; the desire to learn more taking precedence over hard skills and qualifications that one can accumulate.

Both points culminate in the idea that being a great developer doesn’t mean having countless certifications or even being able to write code well. This is a good foundation, and great software developers usually fall into this category, but what makes them great is the understanding that there is more to learn and the desire to expand their knowledge and experience that sets them apart from the pack.

References:

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns Guidance for the Aspiring Software Craftsman Dave H. Hoover Aut; Adewale Oshineye Aut. O’Reilly, 2014.

From the blog Griffin Butler Computer Science Blog by Griffin Butler and used with permission of the author. All other rights reserved by the author.

Software Quality Assurance Blog: Introduction

Hello internet! This will be my blog for my CS-443 Software Quality Assurance and Testing class. I’ll be writing about things that I find interesting in the world of software testing, and I look forward to writing my first entry.

From the blog Griffin Butler Computer Science Blog by Griffin Butler and used with permission of the author. All other rights reserved by the author.

How DevOps can Fill in the Gaps Left by Agile Development

During the early 2000s, just as the dot-com bubble began to finally burst, a group of software development engineers came up with a new methodology for designing software. Previously, development teams used the waterfall development concept, in which each stage of development had to be completed in its entirety before moving on. While this process had worked well in fields such as mechanical engineering, the fluidity of the world of software development made this rigid structure inefficient.

The new process they came up with was known as Agile Software Development. This new methodology focused heavily on the idea that over the course of the development cycle, requirements are likely to change, unexpected bugs may cause issues, and functional code should be made frequently. This allowed for greater flexibility during development, as well as increasing collaboration between customers and shareholders with developers. This proved to be much more efficient and successful than waterfall development, and thus has become the industry standard.

However, Agile Development did not include the operations portion of a product’s life cycle. The operations teams are tasked with maintaining the infrastructure on which the product runs on, as well as deployment and management of the product. A lack of communication between the development and operations departments in the Agile structure could lead to operations teams being tasked with managing a product they have no insight into how it was developed.

This lack of transparency is addressed in a new method of development, known as DevOps. DevOps is designed to extend the principles of Agile Development to include both development and operations teams, allowing for both groups to communicate on how to design a product that works well for either party. To achieve this, DevOps often uses the CALMS framework; culture, automation, lean, measurement, and sharing.

Culture refers to the change in general mindset for teams. The idea is to shift towards a culture in which development and operations teams work together to increase efficiency. Automation of testing and development can increase quality of work and throughput of teams. Lean refers to the idea that failure is a key component to an experimentation, which is helpful in creating new and effective code. Measure ensures that test results are recorded and progress can be monitored and assessed. Finally, sharing refers to how collaboration and communication are essential components to DevOps.

While DevOps is still a new framework, it’s likely that it will be implemented in more and more development teams and companies. DevOps builds on existing principles laid down by Agile Development, while addressing the lack of transparency between development and operations. Because this is less of a radical shift in methodology and more of a modification of existing practices, it is likely DevOps will continue to grow and develop, just as Agile did 20 years ago.

Works Cited

Atlassian. “Agile vs DevOps.” Atlassian, http://www.atlassian.com/devops/what-is-devops/agile-vs-devops.

From the blog Butler Software Construction, Design, and Architecture by Griffin Butler and used with permission of the author. All other rights reserved by the author.

Moneyball 2.0: How Machine Learning is Revolutionizing the Sports Industry

As I’ve discussed in previous blogs, the explosion of artificial intelligence in recent years has begun to revolutionize multiple aspects of life. The first things to come to mind, like self-driving cars, usually follow the pattern of taking a job that is normally performed by humans and automating it. There are tangible reasons for this; most people aren’t too interested in performing labor, so these are usually the first things that go to the drawing board for how AI can be implemented to ease human work. But what about something entirely based on entertainment and leisure?

The world of sports, obvious or not, is dominated by numbers and math. For every team of outstanding professional athletes, there is an equally outstanding scouting team, charged with finding the next big star. Or maybe a team uses analytics to find strengths and weaknesses in their opponents, as well as themselves. In more recent years, sports broadcasting companies have begun to integrate more statistics in their presentations.

While these jobs have always been possible, the implementation of machine learning into the process has caused the field to take leaps and bounds. For example, the NFL has partnered with Amazon to use their AWS Cloud Computing platform to deliver score outcome predictions, as well as more intricate stats, such as real-time pass completion probabilities. The utilization of services like AWS SageMaker has powered these “next-gen” stats and offers fans a different look at the game.

From a team management perspective, these new tools aid in keeping coaches and players informed about critical decisions. Imagine the position of a head athletic trainer. You have a player with an injury history who is scheduled to play in the upcoming game. Should you clear the player for the game, and risk an injury? Or do you sit the player, and risk a loss? These tough choices, while still difficult and heavily scrutinized, are now made easier with machine learning. The entire history of the player; injuries, performance stats, disciplinary records, can all be analyzed by AI to help coaches make an informed decision. Of course, these choices aren’t always correct, and hindsight is always crystal clear when looking at these mistakes. But with better number crunching, those mistakes are few and far between.

Finally, the use of machine learning in the role of officiating these sports has begun to emerge, with a healthy dose of controversy. Major League Baseball has experimented with using AI to track balls and strikes in addition to a human umpire. While this remains a hotly debated topic, and the jury is still out on whether or not these are changes that will catch on, sports continues to be transformed by machine learning, which may continue to revolutionize how we view the game.

Works Cited

“NFL next Gen Stats Powered by AWS – Stat That.” Amazon Web Services, Inc., aws.amazon.com/sports/nfl/.

Peranzo, Pete. “How Artificial Intelligence Is Transforming the Sports Industry?” Imaginovation | Top Web & Mobile App Development Company Raleigh, 23 Aug. 2022, imaginovation.net/blog/ai-in-sports-industry/.

From the blog Butler Software Construction, Design, and Architecture by Griffin Butler and used with permission of the author. All other rights reserved by the author.

What is an API, and why have they become so controversial?

In February of 2023, controversy struck when new Twitter owner Elon Musk announced that developers using the previously-free Twitter API would now be required to pay for its use. The cheapest package was announced to be $42,000 per month for access to 50 million tweets, which unsurprisingly has driven off an enormous amount of researchers and developers who can no longer afford to use the tool. In April of the same year, Reddit.com also announced that their API would no longer be free, charging $12,000 per 50 million requests. This decision too was met with intense criticism, as developers of multiple third-party apps were forced to shut down their services due to the cost.

Rather than trying to weigh in on this debate, let’s look at what an API is, why they are so essential for many of these third-party developers, and why they have quickly become unaffordable.

Firstly, an Application Programming Interface, or API, is an agreed-upon set of protocols that allow for the transfer of data between applications. It functions as an intermediary between systems, allowing for companies to open their application’s data to other pieces of software. This works by providing the framework for the external system to request specific data (known as a “call”), and receive the requested info (the “response”). Let’s look at Reddit for an example.

The Reddit API allows for third-party apps to request and receive data such as posts, comments, videos, etc. to be used on their own application. The app RedReader, for example, pulls information from Reddit and displays it in a way that is more accessibility-friendly than the normal site. To do this, the app must make calls for data to be sent from Reddit servers, which it uses to update its own app.

Here lies the debate regarding paid vs. free APIs; they provide the valuable ability to integrate proprietary software with external applications, the controversy surrounds how valuable this ability actually is. On one side, an API should ideally be profitable for the company designing it to offset the cost of development and to monetize the use of the company’s data. On the other hand, the trend of extremely high prices set by platforms such as Twitter and Reddit have kicked out many smaller development teams, especially those who use the data for non-commercial work. In an interview with Wired, Kenneth Joseph, an assistant professor at the University of Buffalo, explained that his work of analyzing how people use Twitter has effectively been ended by the eye-watering costs of use.

The correct answer to the question of how valuable an API is can often depend entirely on which side of the argument you’re on: company executives will state that the use of their data is something that cannot be provided for free, while developers and researches are adamant that such extreme pricing has made their use unaffordable. In the future, as the amount of available data continues to grow, this debate is surely to come around again.

Works Cited

Binder, Matt. “Twitter’s API Keeps Breaking, Even for Developers Paying $42,000.” Mashable, 29 June 2023, mashable.com/article/twitter-api-elon-musk-developer-issues-apps.

IBM. “What Is an Application Programming Interface (API) | IBM.” Www.ibm.com, 2023, http://www.ibm.com/topics/api.

Red Hat. “What Is an API?” Redhat, 2 June 2022, http://www.redhat.com/en/topics/api/what-are-application-programming-interfaces.

Roach, Jacob. “Why Everyone Is Freaking out about the Reddit API Right Now.” Digital Trends, 14 June 2023, http://www.digitaltrends.com/computing/reddit-api-changes-explained/.

Stokel-Walker, Chris. “Twitter’s $42,000-Per-Month API Prices out Nearly Everyone.” Wired, 10 Mar. 2023, http://www.wired.com/story/twitter-data-api-prices-out-nearly-everyone/.

From the blog Butler Software Construction, Design, and Architecture by Griffin Butler and used with permission of the author. All other rights reserved by the author.