Author Archives: jkindl

Sprint 2 Retrospective

During Sprint Two, my main task was troubleshooting an issue with sending data to MongoDB and its connection within Docker. Initially, a teammate had trouble sending the fake data from RabbitMQ to MongoDB. The data was reaching the RabbitMQ queue, but there were problems with the consumer. I suggested that we seed fake data directly into the database so we could work on calculating totals and building the report. When working on that, it soon became clear that the issue was not the consumer but the connection to MongoDB itself. Even with the database running and showing access to an empty database on the browser, we could not add the fake data from the queue. Further attempts to connect to the database did not work. At the end of the sprint, we decided to split the data transfer portion into another subproject for sprint three.

This was the main experience for half of the team, while the others worked on JSDoc, calculating report totals, and developing the frontend. We faced setbacks throughout the sprint but collaborated well and tackled the problem from different angles each week. Unfortunately, the troubleshooting process regarding the MongoDB connection bore no fruit. We misidentified the problem early on, which took some time, but this was mostly due to our inexperience with Docker. When comparing and implementing the guestinfobackend with our backend, I grew consistently confused about what was causing the issue and believed it had something to do with using the docker container we did not understand.

Moving the data transfer portion to a different subproject seemed like the best approach. It will move us around the roadblock we hit and give us an achievable goal for sprint three. Although we could not solve the issue, I still learned a lot about MongoDB, MongoDB Compass, how to seed fake data, the docker-compose, and how Docker can complicate connections between different services.

Our team did not initially understand the extent of the problem, and in hindsight, we should have had all teammates working on the issue earlier. We assumed the roadblock would be resolved quickly, but we should have brought the rest of the team in after week two. Our communication in and out of class has been fine, but while we were stuck on the database, I believe similar roadblocks on the frontend side were being downplayed. Since we are no longer stuck on the database, I will focus on helping with the frontend during sprint three.

Individually, I need to deepen my understanding of Docker containers networking and ports. None of the attempts produced functional or testable changes, and we actively discussed what we tried each week, so it was disheartening not having anything to commit. I was scrapping entire changes and trying different approaches constantly to no avail.

The apprenticeship pattern reflecting my experience for this sprint would be “Learn How You Fail.” This pattern emphasizes analyzing the reason for your failures and not dwelling on them. Understanding what led to the failure, like incorrect conclusions, gaps in knowledge, or missed details, can turn something frustrating into a learning opportunity. I chose this pattern because the sprint was full of failed attempts. Despite researching and testing each week, we could not solve the problem. Initially, it was frustrating, but seeing it as part of the process makes more sense when stuck. Our group talked about our lack of experience in Docker, and it helped us to know what we needed to work on and that I was not the only one confused. If I had read this pattern earlier, I may have worked on the issue with less frustration and more patience.

While I did not make any commits this sprint due to the unresolved database issue, I was consistently involved in troubleshooting the MongoDB connection issue alongside my team, as shown in the weekly reports.

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

What worked best in this sprint was our team’s collaboration and the understanding I gained through independent research. From the get-go, our team had very few issues communicating. We checked in on each other during class and collectively made decisions on the project’s future without any conflict. Everyone seemed committed to their tasks, which allowed us to complete our sprint goals on time.
Throughout the sprint, I encountered many aspects of the project I was unfamiliar with, including RabbitMQ, MongoDB, and Docker. A lot of my time was dedicated to researching, reading blog posts, watching tutorials, and testing to understand how they worked. With the newest Sprint 2 goals involving the production and consumption of data using RabbitMQ and inserting it into MongoDB, I feel more confident handling these tasks.

What did not work well in the sprint were some complications with my operating system and a lack of documentation on GitLab. At the beginning of the sprint, I had trouble opening a port with my Mac, with my solutions working in some moments and not working in others. Eventually, that issue was fixed, but being unable to test during that time hindered my contribution. I worked locally to get things running with my Mac, testing the reporting backend and understanding how everything fits together, but I did not always push that work or create merge requests to show my progress. Much of my effort went into trial and error testing, and sometimes, my work felt redundant. I need to better communicate with the team so I can accomplish tasks more efficiently.

So far, we have been communicating well in class, and there has not been a need for constant checkups on Discord. That could change, and probably should, with the upcoming sprint. We will need to communicate effectively if our tasks end up conflicting. I could communicate better on Discord and will strive to do so in the next sprint. Working around work and school has been difficult, so I should discuss that with my group so we are on the same page.

The pattern from the Apprenticeship Patterns book that aligns well with my experience during Sprint one would be Confronting Your Ignorance. This pattern involves identifying gaps in your knowledge and actively working on them, even if the gaps are from areas people on your team assume you already know. It encourages you to fill these gaps through whatever methods work best for you, including reading, individual projects, or asking for help.
I selected this pattern because I recognized gaps in my knowledge and confronted them so I could contribute to the team effectively. I spent a lot of time getting familiar with RabbitMQ, MongoDB, Docker, and the Reporting System. I leaned on some of my teammates, who felt more comfortable with the tools, asking questions during class. I also did independent research, reading blog posts, tutorials, and documentation. These aspects of the sprint were most relevant to the Confronting Your Ignorance pattern.
I do not believe reading the pattern would have changed my behavior during the sprint. I understood that there would be different levels of expertise in a team, and not knowing something was not a weakness but an opportunity to learn. What’s important is that you take steps to fill the gaps in knowledge, which is what I strived to do during the sprint.

Link to Gitlab:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/commit/37999a7f42ed4eb89d6f7ab2e2a4d530fec3010c

  • Updating the dev container file and fixing the issue where the 10350 port would close unexpectedly.

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

Introduction to Apprenticeship Patterns

            After reading the first chapter of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, my initial reaction was that the motivations and goals for this book were very admirable. The authors do not claim to have a correct path to becoming a successful developer.  Instead, they introduce an approachable and adaptable set of patterns that help you on your path through the stages of apprentice, journeyman, and master. They are establishing a mindset, a foundation for how you can become a better software developer. What made me admire the goals of the book were the implications of others using these patterns. If the community of developers adopts a craftsman mindset, it will improve the accessibility for new developers. More people would be open to learning from each other, sharing techniques, and uplifting the next generation of software developers.

            Since I have only read the first chapter and the introductions to others, my knowledge of the patterns is limited. From what I have read, the lessons you can learn from this book seem philosophical, which is a shift from how I would typically think about success in the software development field. I liked the book’s emphasis on self-reflection and seeing where you currently stand as a developer so you can see your path forward. The book discusses getting rid of pride or contentment in your current abilities so you do not restrict yourself from improving or learning from others. I can see myself and others falling into mediocrity with an incorrect mindset. It reminds me of advice I have heard that aligns with the metaphor of the big fish in a little pond. If you find yourself the biggest fish in the pond, you probably should not be there. Being content with your position will stifle your growth, so the idea is to constantly find yourself a bigger pond.

            The chapter that seems most relevant to me would be Perpetual Learning. The breadth and depth of my knowledge are at an early stage, so I am constantly learning new things to bolster my understanding and improve my skills. I am excited to learn and understand these patterns and hope that more developers will adopt them in the future.

Link to the book: https://learning.oreilly.com/library/view/apprenticeship-patterns/9780596806842/#toc-start

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

UML Diagrams

Unified Modeling Language (UML) is an important tool in software development that helps developers visualize, design, and document the structure of their systems. It allows developers, project managers, and stakeholders to communicate with a medium that is easier to digest and explain. This week, I found a blog that introduces UML diagrams, “What is a UML Diagram?” from Miro. Miro gives an in-depth view of the types, benefits, and when to use UML diagrams.

Early in our course, we discussed and modeled Sequence and Class Diagrams. I chose this resource because of that foundation and because it is a great starting point for beginners. It also explained more diagram types than presented in class.

The blog explains that UML is a standardized modeling language used to visually represent a system’s design in a understandable way. It highlights two main types of diagrams, each with their own subtypes.

  1. Structural Diagrams: These visualize the components in the system and their relationships. Some examples include:
    • Class Diagram: The static structure of a system showing classes, attributes, and relationships.
    • Package Diagram: Shows how packages and their dependencies are organized within the system
    • Deployment Diagram: Shows how software and hardware interact
  2. Behavioral Diagrams: These visualize the system’s behavior over time. It is the dynamic behavior of the system. Some examples include:
    • Activity Diagram: Visualized the flow of activities within a system.
    • Sequence Diagram: Shows how objects interact over time.
    • Use Case Diagram: Shows the functionality of the system from the user’s perspective.

The post then describes the benefits of UML diagrams, such as simplifying complex ideas/code and improving team collaboration. It finishes by explaining the best practices and when to use UML diagrams.

This post helped me shore up my lacking knowledge of UML diagram types. I was unaware of most diagram types discussed, so it was nice to see what they were and how they were properly used. The site also provided a link to a diagram maker with some of the types which could be useful in the future.

The benefits were also insightful. The main takeaway was that the UML diagrams keep everyone on the same page. From the technically inclined to those lacking knowledge, you can communicate the system’s functions effectively. This seems especially true for those working in teams with different specialties. Having a roadmap for the system’s functions with a standard notation that everyone can understand allows the team to work more efficiently. In the future, I will use UML diagrams to keep everyone involved in our projects on the same page so we can collaborate to make our software more effective.

Resource: https://miro.com/diagramming/what-is-a-uml-diagram/#1.-simplifies-complex-ideas-and-systems

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

Backend Development

Backend development is the backbone of any software application. It handles the functionality behind the scenes, supporting interactions between the users and the application or website. The backend manages databases and server-side logic so modern applications remain efficient, scalable, and reliable. Understanding the principles of backend development is essential for developers to create effective software.

For this week’s post, I found a resource discussing key elements of backend development called “Mastering Backend Development” by Dan for Roadmap.sh. Dan introduces a roadmap for becoming an effective backend developer, and in this post, he discusses some of the steps on this roadmap in detail.

Backend development has been a key component of our class. I chose this resource because it is connected to the course, and the roadmap seems accessible to new developers. Having a path for your research and actionable steps to take can help with any knowledge gaps or roadblocks in understanding backend development.

This resource outlines 19 important steps or knowledge necessary for backend development. I have limited the summary to those I found interesting or instructive.

Caching Strategies: Improving the performance by storing copies of frequently requested data, reducing database load, and speeding up responses.

Authentication and Authorization: Ensures only authorized users access the system by implementing security measures.

Architectural Patterns: Picking the correct pattern, like Monolithic or Microservices, helps build scalable and maintainable systems.

Observability and Monitoring: Provide tools to monitor the system’s health, optimize performance, and diagnose issues.

Continuous Learning: Staying up-to-date with technologies, frameworks, and best practices. This ensures developers can adapt to the rapid evolution of backend development.

Some steps seem self-explanatory, but they could provide a good foundation for someone new to backend development. I could see how new developers could choose to prioritize the software’s functionality while forgetting its efficiency, security, and diagnostics. The post also offered plenty of tools to help with each step, like Redis and Memcached for caching strategies and OAuth and JWT for authentication and authorization.

I felt Dan gave an excellent synopsis of the research needed for new developers. Plenty of steps were not readily apparent to me, like cashing or your system’s self-diagnostics. These steps will likely present themselves in development, but for someone with little experience, it gives a good direction for research. This mindset aligns with the last step, continuous learning, and the importance of staying proactive regarding new challenges and technologies. In the future, I will research these backend concepts and stay up to date so I can produce and maintain better backend software.

Resource: https://dev.to/roadmapsh/mastering-backend-development-mpb

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

REST API History and Fundamentals

We have discussed REST APIs in class and are learning to use them with a practical, hands-on approach. This approach is faster for the course and is better for my understanding of the material, but I thought it would be a good idea to learn the history of REST APIs and expand my general knowledge of the subject. I found The Postman Team’s blog post, “What Is a REST API? Examples, Uses, and Challenges,” which discusses the fundamentals of REST APIs, including their history, standards, functionality, uses, benefits, and challenges.

The blog starts by explaining how REST APIs evolved from a simpler alternative to SOAP APIs, becoming the backbone of the modern web. With the advances in the internet during the early 2000s, developers and companies needed to be adaptable, which SOAP API was not the tool for. The post expands on the disadvantages of SOAP APIs and explains why they were less valuable at the time. SOAP APIs were not scalable and too restrictive, making it difficult for developers to innovate. REST APIs, on the other hand, gave companies and developers the flexibility and scalability needed to keep up with the internet as it evolved. Another key feature it had was independence. REST APIs are not tied to a platform or language and have client-server separation. The adaptability and simplicity made REST APIs an obvious choice for companies like eBay and Amazon.

The post also discusses some of the challenges involved with REST APIs. Some include maintaining consistent endpoints, managing multiple versions, and dealing with differing authentication methods. All these issues complicate the development and maintenance of REST APIs which is why there are standards used to mitigate problems in the future.

The blog’s final section showed REST API examples, including Amazon S3, Twitter, Instagram, and Plaid. It explained how each API has its own specialization, like Twitter’s registration process or Amazon’s ability for developers to incorporate AI.

What I found most interesting about the blog post was the timeline for REST APIs’ evolution, the big names that pushed REST APIs forward, and the reasons behind their actions. Major companies we know today, like eBay and Amazon, got ahead of the curve, leading the way for companies like Twitter and Facebook. Learning the reason behind its success and its practical uses was interesting. I will use what I’ve learned to approach future projects with a stronger understanding of REST APIs, ensuring I design scalable, adaptable, and efficient code.

Blog: https://blog.postman.com/rest-api-examples/

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

API Documentation

This week, I decided to discuss Application programming interface (API) documentation. API documentation is essential for developers to understand how to use the API, integrate it into their applications, and fix any issues that arise. The article “How to Write API Documentation: Best Practices and Examples” highlights the importance of API documentation and discusses practical insights into creating a better developer experience.

The article starts with an informative video discussing the API economy, what API documentation is, and how to write it. It also shows some examples. The article moves on to the common issues developers have with APIs, like being too long, too much technical jargon, un-updated, or inaccessible without registration. The author discusses several ways to remedy these issues by emphasizing that good API documentation needs to be user-friendly, clearly explained, and given examples with FAQs or tutorials. One of the strategies presented to accomplish this is called spec-driven development(SDD), where you generate the documentation while developing the API. We are also given several tools to help create and maintain API documentation, like Swagger and Postman.

I chose this article because APIs are discussed and used thoroughly in our course. The appropriate next step was understanding how developers make software accessible to users and, in doing so, become more accustomed to APIs.

Reading this article gave me several strategies to think over and included great explanations for why they are used. I was unaware of strategies like SDD and writing for entry-level users, but they made a lot of sense after reading the article. Creating the documentation after developing API can lead to errors and inconsistent documentation, frustrating developers. Having the documentation evolve with the creation of the API makes more sense. The explanation for writing with entry-level users in mind was great, too. You might think that all software developers understand API documentation, but each developer has their own experiences, specialty, and knowledge. Tailoring the documentation to everyone is impossible, so aiming for clarity at the entry-level will make it understandable for most developers. It is one thing to hear how to improve your documentation, but seeing data on the main features developers want and issues they get frustrated with makes me feel like the strategies will have a greater impact on the users.

In future projects, I plan to use spec-driven development to ensure my API documentation grows with my project, allowing developers to follow along without confusion. I will also aim my documentation at entry-level users so the resource is accessible to most developers.

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

New Class!

Hello! I will be continuing the blog posts pertaining to my course. The class I am currently in is Software Construction, Design and Architecture. CS343_01_FA_2024

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

Security Testing

Like my previous blogs about performance and AI tools, I wanted to discuss another area of software testing that covers a specific development aspect. I chose security testing because while performance and functionality are essential, we must ensure our applications are safe for their users. This blog post, “Security Testing: Types, Tools, and Best Practices,” by Oliver Moradov, will outline various aspects of security testing, its importance, and its methodologies.

Oliver’s blog starts by defining security testing, listing its main goals and principles, and providing an index for many other aspects of security testing. It stresses that security testing is a non-functional testing process that determines the resiliency of software from cyber-attacks and data breaches. Non-functional testing focuses on how the system works rather than if it works. The primary goals are identifying assets, threats, vulnerabilities, and risks and performing remediation. 

The blog then discusses the types of security testing, including penetration testing, application security testing, API security testing, and vulnerability management. It also covers security test cases, and security testing approaches such as black box, white box, and grey box testing. The blog finishes by discussing best practices in security testing, such as shifting security testing left, testing internal interfaces, and automating tests.  

 I felt the distinction between functional and non-functional testing was important to discuss. Knowing how our data or the company’s data is handled is much more important for security than making sure the software functions correctly. It could function perfectly within the development team’s parameters but still fail to protect the company’s and users assets. 

I found it interesting that black box, white box, and grey box testing are applied differently than how they’re typically used in unit testing. The fundamental uses are the same, limiting and granting information, but there is much more to be gained when using this method in security testing. Testing what a malicious hacker could do with limited or abundant details on the software would be critical to protecting our assets. It also highlights the difference between non-functional and functional because developers use box testing to determine how to make errors occur within the system. In contrast, security tests would use the system functionality itself to create a breach in security. 

The sections detailing what security vulnerabilities they look for were enlightening. The authentication, input validation, and application logic sections highlighted what scenarios the security tests may encounter to validate system safety. I’m glad the blog discussed tools for developers to ensure their code can’t be exploited. Overall, this blog gave plenty of rudimentary information on security testing, and I urge those interested to check it out. In the future, I plan on using the tools and testing techniques to ensure that my code is safe for its users and owners. 

Blog: https://brightsec.com/blog/security-testing/

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.

AI and Unit Testing

With artificial intelligence increasing computational power and variability in usage, I wondered what advances were being made with AI. The tedious and repetitive aspect of test-driven development can sometimes leave the development process stagnating, so I was interested in how AI is changing the software testing process. This blog post, AI for Unit Testing: Revolutionizing Developer Productivity, by Philip Riecks, expands on how AI is improving the quality of our code and the productivity of our developers. 

The article highlights AI’s revolutionary steps in software testing and development. It discusses tools like IDE plugins that act as digital coding assistants and surveys from GitLab that show a significant increase in AI usage and demand for AI testing solutions. Philip explains the benefits of AI, which include streamlining test creation, boosting developer productivity, reducing developer fatigue, and many more. The article addresses why developers hate unit testing, highlighting the importance of it despite its tedious nature. It then gives an assortment of those tools with a small explanation of their specialization.

I found this article very enlightening, especially regarding the impressive abilities of AI-driven tools. My first thought when thinking of AI is to fear for developers’ jobs or worry about copyright infringement. It is nice to see that the focus of AI tools based on this article is to help developers by removing tedious tasks and allowing them to focus on improving the code. One of the sections mention AI’s ability to use user stories to generate test cases automatically. This was particularly interesting to me because a big part of behavioral-driven development involves using user scenarios when developing tests. Having AI take the workload off those using the BDD method would significantly increase productivity.

While reading, I still worry about the experience of those who use AI. If AI predicts defect areas, creates tests, and assists you every step of the way, how will that affect your ability to do those tasks? I also wonder if it matters if our abilities are lowered if we always have the tool at our disposal anyway. I imagine it would end up the same way we use calculators. We learn and can do calculations, but use the tool for convenience. Overall, I’m cautiously excited about AI, the stress taken off developers’ shoulders, and the increased time they will receive to focus on enhancing their projects.  

In the future, I will endeavor to learn more about AI, focusing on current and upcoming tools. When I use these tools, I will use them as an assistant and not as a crutch. 

The Article:https://www.diffblue.com/resources/ai-for-unit-testing-revolutionizing-developer-productivity/

From the blog CS@Worcester – KindlCoding by jkindl and used with permission of the author. All other rights reserved by the author.