Author Archives: jelbirt

CS448 Sprint 1 – Retrospective

This past Tuesday 2/27/2024 marked the conclusion of Sprint 1 for CS448 – Capstone. My team worked generally well together and we managed to complete all of our assigned tasks as well as some extra we added during the Sprint.

During this Sprint, I was involved in addressing a few different tasks and issues:

Issue spent most time on – “Create General and Pipeline” https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/10. This issue was in the “General” (#gitlab-profile) repository and consisted of three separate parts: 

  1. Moving settings from configuration files set up for integration with Dev Containers to .gitpod.yml extensions for GitPod integration.
  2. Refactoring the ‘commands’ folder to ‘bin’ to keep up with industry standard file naming. This includes updating script paths and .gitlab-ci.yaml environment variables to refer to bin.
  3. Adding the AlexJS linter to pipelines as well as the bin/lint.sh test script file.

Also, as a part of this issue I also implemented some minor typo and similar fixes so that all linters pass for a successful integration pipeline. Originally, these were three separate issues that were combined during the Sprint.

Issue #2 – “Familiarize ourselves with GuestInfoFrontend to Understand What Goes into CheckoutGuestFrontend”

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/37. This issue included all team members and was intended to prepare each of us for Sprint 2, during which we intend on tackling some front-end Epics/issues in CheckoutGuestFrontend. So, I reviewed the GuestInfoFrontend repository structure and began to strategize a possible plan of action for building out CheckoutGuestFrontend.

As mentioned, my Team added additional tasks to our Sprint Backlog during the sprint as we found we would have extra time leftover after completing our original tasks. We chose to take on “Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages” for the Documentation and General repositories as we had already set up the settings and thereby familiarity with these repos. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/issues/10

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/12

I created our new issues; we were able to complete the task for the Documentation repo as it was relatively simple in terms of not needing to make many changes/add linters, and make some progress in the General repo but pushed the issue into Sprint 2.

Reflecting back on the sprint, there were a few things that come to mind which worked really well – as a team we scheduled out our tasks well between standups and managed to have full attendance at each. Also, when we needed to add tasks we elected to stay within the repositories we had already been working in and were somewhat familiar with, which was a good choice as switching would have likely wasted time getting familiar with the new repo, as well as wasted time for another team who would have needed to become familiar with ours. 

However, we struggled somewhat with getting used to navigating the GitLab issue board, merges, child issues etc. and sometimes it felt like some team members were in different places where a solution may not have been fully communicated to all teammates. As a team, I feel we can improve on some of our internal communication and do a better job planning out our sprints and creating something of a road map, especially as we prepare for Sprint 2 which is considerably longer than the first. Personally, I think I can improve my time management and also be a bit more involved in the process of planning out our next Sprint and creating issues with relevant descriptions and linking to organize our tasks and get a better feel of how to use GitLab to its maximum potential.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Stay in the Trenches Individual Apprenticeship Pattern

This week I continued to read about Individual Apprenticeship Patterns for CS448 – Capstone and focused on the “Stay in the Trenches” pattern. This pattern emphasizes the importance of gaining continuous hands-on, practical experience in the craftsman’s chosen field(s) at all levels, even as they may advance within a company. It can be common as software developers move up to transition to more managerial roles focusing on handling teams and deadlines rather than hands-on coding.

However, doing so will inevitably and quickly result in deterioration of the craftsman’s coding skills. Instead of getting too caught up in theoretical knowledge or managerial roles early (or at any point) in a developer’s career, developers should ‘stay in the trenches’ and continue working on practical/coding problems to keep developing and advancing skills and expertise. By immersing ourselves in the actual work, we’ll learn from the day to day experiences and continue to grow in ways that upper level managers often cannot. 

Often, I’ve heard of upper level software managers spending most of their time on coordination, time/schedule management and strategy/design planning – from a craftsman’s standpoint, only code project strategy and design planning are particularly applicable. While it surely is far more abstract and long-term or larger in scale, developers who are working hands-on with code are still managing and accomplishing tasks and exercising their code strategy and design skills. So when considering that hands-on coders will also further several other skills related to their craft, these managerial roles seem like a clear downgrade in terms of job quality and day to day activities even if it comes with a pay increase.

This brings up the final major point of this pattern, which really stuck out to me – identifying other avenues and ways for craftsmen to advance within their company/career and be rewarded for high-quality performance. Some practical examples could include a simple pay increase, more involvement in internal strategy meetings/decisions, job-title shift/improvement, etc. There’s no clear or definite answer here, but individuals in this position are probably in good standing as the company is looking to reward them, and they should communicate and work with company management to find incentives and reward mechanisms that align with the goals of both parties. If not however, this pattern stresses the importance of staying on the craftsman’s path and considering advancement positions at other companies that are more flexible.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Interesting Features of JUnit 5

Since beginning to work with code in CS443 – Software Quality Assurance and Testing, we’ve used JUnit framework for designing and running our test cases. So I decided to search for a blog post discussing some interesting features that I may not have come across yet, but could be useful and landed upon Exploring the Exciting New Features of JUnit 5. This post is from December 2023, so it should be relatively up-to-date and I recall a conversation with Dr. Wurst at one point where he briefly mentioned considering switching to a newer version of JUnit for some attractive features – hopefully we can delve into some of these.

Several feature additions come with JUnit 5 and specifically version 5.4. One that immediately stood out to me was support for more/new annotations and assertions like @Nested. We’ve looked at some basic annotations like @BeforeEach and @AfterAll in class but the idea of nesting tests is newer – however it makes perfect sense from a practical perspective. Depending on the outcome of an initial test, testers may want to run further tests on one branch or two different tests depending on which branch is followed. Proper annotating likely helps the compiler recognize the nested nature of the tests preceded and manage potentially complex webs of nested tests most efficiently.

There’s also improvements to the assertEquals() functions and overall flexibility through enhancements to API and insertion features for handling Lambda functions. This goes hand in hand with a new feature of JUnit 5 – the ability for tests to be dynamically generated during test runtime and implemented (if needed) using a Factory class/method. Last semester in Software Construction Design and Architecture, we learned about the Factory architecture and methodology so it was cool to see it applied to enhance features in professional software. 

Another cool feature of JUnit 5 which represents a considerable change from JUnit 4 is the transition to a modular structure, meaning there is a separate test runner and classes which operate independently from the main program. I could imagine that this separation isolates any issues that may arise during testing and protect the main program, while also preventing any unintended interactions with the main from interacting with properly designed tests.

JUnit 5 offers some major features and enhancements over the previous versions with the ability to tag and implement nested tests, improved Lambda function support and Factory method for dynamic test creation and implementation. Considering these, I can see how JUnit could be effective for designing automated test runs. I’m looking forward to implementing more of these features in our class and homework activities for CS443, and trying some extra tests and methods that I read about in this.

Source: 

https://blog.machinet.net/post/exploring-the-exciting-new-features-of-j-unit-5

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Indiv. Apprenticeship Pattern: “Expose Your Ignorance”

Between sprint tasks, I continued reading Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye for Software Capstone course this week, focusing on the “Expose Your Ignorance” strategy. In professional environments, software developers are often expected to have a deep understanding of the various tools and technologies they work with, but it’s common to encounter unfamiliar domains/situations.

This strategy approaches these situations by being transparent with employers/teammates about their learning process rather than pretending to already know unfamiliar content – even if the individual is able to self-teach the content to be able to follow through. In reality, they will need to learn the new technologies/skills regardless, and transparency on this allows employers and peers to also see your learning skills and personal growth over the course of a project. 

In doing so, software developers are approaching their situation from an honest angle which is far better for building professional relationships and management expectation. In a manager role, I would much rather hear 

‘well, this API is new to me but I’m making headway in learning and implementing it. I hit an obstacle, which may delay me.’

Over an employee claiming they are an expert and then failing to deliver on time.

As a part of this, the text also differentiates between an “expert” and a “craftsman”.  While experts focus on mastering specific platforms or domains, craftsmen are driven to continually learn and adapt by broadening their knowledge base. Naturally, the craftsman can’t become a master in every topic, but master craftsmen have developed in-depth knowledge of a few separate areas of technology throughout their career and ‘apprenticeship’. So, while they may not be the absolute expert on any given topic, they will have the skills to learn, adapt and overcome challenges involving almost anything.

I appreciated this differentiation and definition of what it means to be a craftsman. Earlier this week, I had a conversation with Professor Meunier in CS497 where he described similar concepts as they relate to graduates and job applicants. As an interviewer, he/others understand that graduates will not have deep knowledge in several areas yet but looks for a wide breadth of concepts/tools we’re at least familiar with and at least one area in which we have a deep knowledge. This could be visualized as a “T” shape – wide topped with one deep portion, but master craftsmen develop a knowledge structure more like an “M”, with a wide breadth of topics and a few with deep knowledge.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

TestProject Tutorial Conclusion – Advanced API Testing and Scheduling

We return again this week looking at the online TestProject blog tutorial focusing on the final two chapters 5 and 6 focusing on Advanced API Testing Automation and Scheduling API Automation Flows and CI/CD Execution respectively. In class, we’ve been working with JUnit integrated with VSCode so it’s been interesting seeing a very different User Interface in TestProject.

Chapter 5 looks at “Advanced” API Testing Automation, which primarily looks at more complex interactions and tests involving JSON objects and schemas. It also goes into some other more complicated calls and tests such as formatting URL-encoded requests, reading and using predefined user data sets and tests involving dynamic parameters. This chapter references public NASA API and tools; a key component that stuck out to me was the error report file generation that’s shown which easily identifies and organizes issues. Compared to previous chapters, I found this one to be less relatable and applicable to the things we’re doing in class, but I still learned a lot and was intrigued by the methodologies for test situations with multiple JSON paths to one target.

Chapter 6 focuses on the scheduling aspect of testing automation in TestProject and interactions with CI/CD/CMD pipelines. As always, there are an abundance of screenshots and images to walk readers through an example test set-up – beginning with the interface for scheduling tests and TestProject’s system of creating and assigning ‘jobs’. Tests are aggregated into jobs (typically as a bundle) which can then be executed as a one-time event or assigned a recurrence time frame. The interface to do so is clear and intuitive and reminds me a lot of CS383 – Cloud Computing where we are working on modules in AWS Academy learning about Amazon Web Services. AWS uses a similar interface and logical structure for assigning roles, jobs, permissions and many other facets making it intuitive for me to follow this TestProject tutorial. This chapter also discusses testing within a Docker container, which we used to implement for Dr. Wurst’s assignments but have recently switched to GitPod.

With this reading, we conclude the TestProject tutorial I originally found at the beginning of this semester. There’s been a lot of really valuable material and examples within these tutorials, particularly in chapters 1-4 as they focus on beginner concepts and I’ve just been getting started with learning about software testing and quality assurance. Probably most interesting and encouraging from this set of tutorials was how frequently concepts came up from other courses like Database Design and Cloud Computing. Software that interacts with those areas must be tested too so it’s important to know how to work my way around them and see visual examples of tests being designed and executed. In conclusion – TestProject seems like a great platform with many features, particularly an intuitive scheduling component, however JUnit’s interface remains my current favorite.

Sources:

Tutorial Intro: https://blog.testproject.io/2020/11/10/automating-end-to-end-api-testing-flows/

Chapter 5: https://blog.testproject.io/2020/11/10/advanced-api-test-automation-and-validation-flows/

Chapter 6: https://blog.testproject.io/2020/11/10/scheduling-api-automation-flows-and-ci-cd-execution/

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

TestProject – API Test Automation with Databases and Shell/File Interactions

This week, I continued reading through the TestProject Tutorial blog I began last week moving onto Chapters 3 and 4, which focused on API Test Automation involving database communications, shell commands, and local file interactions.

The Chapter 3 tutorial focusing on database implementation provides examples of testing connections and querying common types of databases, including Oracle Database, Teradata Database, and MySQL Database using TestProject’s Database Addons. It walks through a specific example of testing a connection to an Oracle Database, showing the successful establishment of the connection. This is taken a step further with an example showing the steps of creating a new table with data extracted from an API request, then setting up and performing an HTTP GET request extracting JSON paths and data from the API response and creating a dynamic query into an Oracle Database Table. I found this portion to be particularly valuable as these tasks seem highly applicable and like common requests of a software dev./analyst, like I plan to be after graduating in May.

Chapter 4 focuses on API test automation flows that incorporate a combination of Shell Commands and/or Local File interactions. As an example demonstration, it shows the steps to access a web page and extract the text using CMD shell commands in conjunction with a GET request, then writing the web page contents to the text file. These functionalities can also be easily implemented using SSH commands, which is also demonstrated. Finally, it goes into how to create and edit/interact with .csv files as a part of the test automation workflow, which can be used for test results and report generation (amongst others).

After going through four of the six chapters in this TestProject tutorial, I can confidently say that it’s a valuable resource and reference in learning about software testing and specifically automation, even if I never end up using the platform. I have been finding the examples to be extremely helpful in demonstrating how to actually use the software and perform some simple real-world tasks, breaking it down into individual test steps. While CS courses commonly include some form of tutorial or demonstration exercise, I personally find that they are often simplified to such a degree that the examples are “unusable”, in that no professional in a real situation would encounter and deal with such a simple task. However, these examples go into more complex applications, such as the earlier example using a combination of commands to extract text from a website, create a new file and write to it. Also, the examples within these tutorials tend to cover a variety of platforms/methods depending on the topic (i.e. a variety of popular databases) maximizing the likelihood for the content to be useful to readers. I’m looking forward to finishing out the last two chapters soon!

Sources:
Tutorial Intro: https://blog.testproject.io/2020/11/10/automating-end-to-end-api-testing-flows/
Chapter 3: https://blog.testproject.io/2020/11/10/api-test-automation-flows-combined-with-database-flows/
Chapter 4: https://blog.testproject.io/2020/11/10/api-test-automation-with-combination-of-shell-commands-and-local-files/

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Indiv. Apprenticeship Pattern : The White Belt

In CS448, we’ve begun independently reading Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye and looking deeper into the patterns discussed in the first six chapters. The first Apprenticeship Pattern I focused on was the first described in Chapter 2 – the “White Belt”. This pattern suggests taking a beginner’s mindset with an emphasis on humility and open-mindedness when learning new things or otherwise addressing professional development. 

This pattern’s Context statement grabbed my attention because it felt very relatable as a senior with a strong understanding of Java who is looking at delving deeper into other languages like C++ and JavaScript. While I have a solid grasp on Java and general programming concepts, I have a lot to learn and really at a beginner level in other languages as I need to relearn basics like proper syntax as well as other concepts like memory management. To this point, one aspect of the White Belt pattern involves admitting ignorance – there’s much more than I don’t even know I don’t know yet. But, I also find this to be encouraging – I also don’t know how much I can possibly learn and gain professionally by taking this perspective in picking up skills.

Another concept that’s brought up and discussed with the White Belt pattern is the notion that particularly when learning and strengthening new skills, it is going to take more time to do tasks that would otherwise be simple to us in our first language – but that is okay and to be expected. This can be a point of frustration for me personally, so it was nice to see this acknowledged and helpful as I can address these tasks in a more patient headspace prepared for slower speed. Furthermore, the long-term benefit to struggling through this slow period usually pays off – the authors eloquently put it as “losing some productivity in the short term in order to take a leap forward once you master the new approach.”

Embracing humility, admitting ignorance, and actively seeking to understand challenges are key components of this pattern that I also try to live life by. So, the “White Belt” individual apprenticeship pattern was very insightful and impactful to read about and a great introductory pattern to more soon to come. It seems most applicable to situations where I/my team will be learning or enhancing skills, particularly when working with others and in environments with more experience to learn from. As a soon-to-be graduate, I look forward to keeping this pattern in mind as I enter the professional field.

Sources:
Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Apprenticeship in Software Development

If you’re like me, you probably dislike doing reading for school and find it to be pretty tedious, usually resulting in a drab writing exercise afterwards. So, reading through the first chapter and then the introductions to the following chapters in our textbook Apprenticeship Patterns – Guidance for the Aspiring Software Craftsman seemed like it would be similarly boring/tedious, but I found the writing to be engaging and discuss relevant topics with relatable analogies. 

The first chapter was primarily an introduction, and I found its discussion of what Apprenticeship is and means in modern society versus how it was implemented in Medieval times where the term originates. One point brought up is that modern “apprenticeships”, or positions with a similar title are more similar to what I think of as an internship, and may involve a lot of training but it mostly involves learning how to use a system/software rather than learning how it actually works behind the scenes or even how to improve it. 

By the same token, the author’s discussion of Medieval apprenticeship and how it correlates to modern situations resonated with me – particularly the division into the three main classes of Apprentice, Journeyman, and Master. Looking back, at the beginning of my Computer Science degree I was certainly a green apprentice and came in with an open mind and I was very fortunate to have family members who are undoubtedly masters to help teach me as their apprentice. Thinking about these individuals, they ARE in fact always learning more and new things and in their own way delving into their own areas of interest to try things which may have never been done before. But, as I approach graduation I feel myself starting to have more tendencies and qualities of a Journeyman as described. With early-career C.S. trends commonly involving a few different companies or departments, it’s easy to see more correlation there to the Journeyman, who travels sharing knowledge with others while also learning from them and improving their repertoire.

In reading the introductions to chapters 2-6, I found them to be quick, engaging and informative – exactly my type of reading. The chapter 3 introduction about Taking the Long Road resonated with me the most and left me with a lot to think about. Many times I’ve found myself feeling like the individual in the example, both inspired/excited by the sheer power and intellect of some other around me and discouraged/terrified of how far ahead of me they clearly appear to be. However, as the text discusses we are all traveling on the same general road as developers and Computer Science professionals, some have just been traveling on it longer, faster, and/or in different directions than us. It’s largely about the journey that gets you to your destination, which we will inevitably achieve as long as we refuse to give up.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

An Intro to TestProject as an Automated Testing Tool

Classes restarted last week, and during the first week I found myself reading and writing a lot of introductory blog posts about upcoming semester course topics. As part of my setup tasks for CS-443 Software QA and Testing, I read about one of the most popular manual API Testing tools Postman and saw reference to TestProject, an automated testing tool from the same company Tricentis. So, I decided to do some further reading into TestProject as I understood the basics of manual testing, but had not seen automated testing in action yet. To do so, I found a blog post on the Tricentis site containing an overview tutorial of API testing and how platforms like Postman and TestProject can be valuable.

The post begins by discussing the value in API Testing and mentions the utility of Postman, but also brings up some of the limitations that are commonly encountered such as test automation, scheduling, and end-to-end test reporting. Intro TestProject → This testing platform offers solutions for end-to-end API testing by providing an environment to not only test API’s, manually but also to automate API-based test flows, schedule and run them periodically, and generate execution reports without the need for third party tools or writing any code.

The blog also contains a six chapter tutorial on using TestProject, so I delved into Chapter 1 – Basic API Test Automation. This emphasizes the platform’s ability to handle a wide variety of input sources like HTML, Databases, and more, then showing the application GUI and taking the reader through how to add ‘test steps’ in TestProject to set up automated testing for a GET HTTP request using NASA’s public APIs including search parameters and discussion on Dynamic Endpoint URLs (and implementing them) amongst others. Chapter 2 offers another brief tutorial discussing the value of scheduling automated tests with image steps (guide) to doing so with interactions to Android and iOS systems.

From these introductory chapters, I was able to get a basic idea of how to use TestProject to design calls, execute tests and access result reports. The other chapters in this TestProject tutorial cover more advanced API testing and validation flows, shell commands, scheduling API automation and more. As an introduction to Quality Assurance Testing and the course in general, this chapter was intriguing and valuable to get an idea of what an automated software testing tool looks like and how to use it in a basic sense. Stay tuned to read more about these other chapters and other topics in software quality assurance and testing and other exciting computer science related topics!

Sources:
General TP Post: https://blog.testproject.io/2020/11/10/automating-end-to-end-api-testing-flows/

Chapter 1: https://blog.testproject.io/2020/11/10/basic-api-test-automation/Chapter 2: https://blog.testproject.io/2020/11/10/api-test-automation-flows-combined-with-mobile-functional-test/

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

An Intro to LibreFoodPantry and Thea’s Pantry

In reviewing the information about LibreFoodPantry at their website as preparation for work in the Software Development Capstone, one particular point that I found interesting and surprising – but enlightening was a portion of the Mission statement. Through its Free Open Source Software and other features, LFP aims to convey to our communities and the world as a whole that computing can be used for social good. I had not thought about the project from this perspective, but it is an interesting and exciting value proposition and completely valid – computing could likely be used in many other instances for social good.

In exploring the subsystems in the repository for Thea’s Pantry and specifically the Documentation section, I was most drawn to the Developer repository, containing documentation that will be most relevant to developers working on the project – such as myself and my teammates. All of these contain valuable information about various components of the system/subsystems like the overall architecture, guidelines for Conventional Commits, and more. Furthermore, I have been interested in picking up Documentation writing as a skill and get some experience with it, so this is an area where I may be able to do so and assist Dr. Wurst in filling out the Developer Documentation. I’m looking forward to getting hands-on experience and making progress in improving the Thea’s Pantry systems this semester!

LibreFoodPantry site: https://librefoodpantry.org.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.