Author Archives: Adam Jacher

Sprint 1 Retrospective

Gitlab Descriptions

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/addbarcodefrontend : created addBarcodeFrontend under our teams project to work on the scanner page.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/addbarcodefrontend/-/commit/64bc3d4f720e6e8a69bafa709276beff820f719b : I added the scanner onto the frontend page, using a vue library to make it look good.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/addbarcodefrontend/-/commit/200cac8ad4de849c3647b1223d9bc6f7075b8da2: I fixed the layout to how it ended up looking by the end of the sprint, as well as working on some other issues like fixing camera mirroring, and also added logos to the page.

Team Reflection

As this project is the first time I have worked in a team adopting the scrum methodology, I was a little hesitant at first as to how well we would work together, with possible conflicting problems that would only lead to decreased productivity, but the way that it has turned out isn’t like that at all. An important part of the lack of disagreements comes from our collective trust in each other to produce the outcome that we envisioned from the issue that they were assigned. Our issue allowed us to split our team into smaller teams, focusing on separate issues which would eventually connect to fulfill our team’s original project goal. This delegation of tasks to each subteam has allowed us to focus on our own tasks, while also checking in with each other to see how the rest are doing. This frees us of the burden of trying to work over each other to accomplish one thing which I believe would lead to inefficiencies and conflicting ideas. This subteam workflow allows us to dedicate our time and effort to one topic while checking in on the other topics to stay updated and give feedback. 

Although I just mentioned that the subteam system allows us to check in on each other and give feedback, this is somewhat untrue or at the very least an idealized version of what we are practicing. I do feel that I am working well in my subteam, and with my partner we are efficiently approaching our goal, however when it comes time to check in on the other teams, I feel as though I don’t get enough of an idea of the inner workings of what they’re doing to give good, constructive feedback. The same goes for my teammates giving me feedback. I think that is the tradeoff with this system though because it entrusts you with knowing what you’re doing, and I don’t think it’s as detrimental as it could be because each subteam at least has a partner that does give detailed feedback, sacrificing quantity for quality.

Apprenticeship Pattern

The perpetual learning pattern assumes there is always more knowledge to be known and your journey as a learner is never truly over. I selected this pattern because I think the pursuit of knowledge is important to sustain a continued expansion of knowledge and innovation, as well as satisfying a person’s internal sense of accomplishment and fulfillment. The point that this book tries to make about being a software apprentice is that you can become a master within your lifetime, but that doesn’t mean you stop learning. This pattern fits into the sprint because there was never a time I really felt like I fully understood a concept to a point where there wasn’t anything else I could learn by further investigating it or digging deeper. Even in established technologies or languages like HTML or CSS, there are a lot of things that many people may not know and working with it so much means I am more comfortable with it, but it doesn’t mean I am anywhere near mastering it, following this pattern of perpetual learning.

If I had thought of this pattern before the sprint started I would have gone into it more open-minded, knowing that anything I encountered would be surface level and that if I really wanted to I could go down a rabbit hole for each new thing I learned. There’s so much information out there that is almost impossible to get to, especially for me in the time of one sprint. I think to improve as an individual in future sprints, I could go out of my way to learn as much as I can so I can understand what I’m working on as best I can.

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Reflection

I actually found the apprenticeship reading really interesting. The first thing that really caught my attention and still sticks with me even after reading is the story of Dave and his journey through apprenticeship. I related to it because in the story his age is stated throughout the years, but it starts when he’s 25. It seems young, but I struggle with the fear that I am behind in life and I am only 20. Dave being five years older than I am now at the beginning of his journey shows that it’s never too late, especially for me. I think this fear comes from an increasingly competitive world where everyone seems like they already know what they want to do, and if you aren’t already successful by the time you leave university, you’re behind the curve. I don’t think it is actually true, but it can be easy to compare to others, often the successful ones which fuels the paranoia. Either way, hearing about Dave’s story helped me put into perspective how each person’s life is different and there is no golden path to follow for success. This story was a good introduction to the rest of the reading. 

Overall, the first chapter really changed the way I see software development as a practice. The quote “We can take the time needed to nurture apprentice developers because we are faced with the problem of abundance, rather than scarcity….Today we have more developers than needed, but we have a shortage of good developers.” makes a lot of sense to me and also illustrates the way that this discipline has devolved into an easy way to live a comfortable life with good pay. I don’t blame anyone for deciding to work in tech for these reasons, but I think it does dilute the way that software development is viewed. Even reading this chapter has changed the way I think about software development. The way that they laid this out as being something that one dedicates their life to, how there really isn’t an end, only progressive growth, made me think of it less of a job, and more of a person’s purpose. This is something akin to medicine, where the knowledge we have today is not all the knowledge there is to have, and there won’t be an end even in our lifetimes. For some of us, technology like computers has been around our whole lives, but relatively speaking all of this is new in history. People devote their lives to this and it will continue to evolve and change, and all we can do is become competent enough to help it evolve. I understand it now. My journey is long and arguably hasn’t even really started but I do want to become a master in my lifetime.

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

Software Quality Assurance and Testing Introduction

This is my introduction blog for my computer science class Software Quality Assurance and Testing. Four times over the semester I will choose a topic relating to this class and create a blog post detailing what I learned on that topic from a source that I find, usually another blog. I’m excited to learn as much as I can about topics in this area and post them here.

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

WSU Food Pantry Introductions

LibreFoodPantry

One thing I found interesting and surprising from the LibreFoodPantry website was the open source license that the pantry chose for contributors. 

I chose to write about this because last fall we had learned about software licenses, including what they are and examples of different ones, and it’s interesting to actually see what a real open source project chose to distribute under. Just looking at the license can tell how the authors intend for their software to be used and distributed, and because LibreFoodPantry chose the creative commons license, it tells us that they want this software to be open and shared freely, under that condition that the derivative works also follow the same conditions.

Thea’s Food Pantry

Simply by clicking on the link to the Thea’s Pantry gitlab page, I could tell that it was very organized and structured in a way to easily navigate, which is very useful and surprised me in a good way.

Since I am going to be using this gitlab page for the whole semester, I really appreciate that it is organized the way it is. Everything is labeled correctly and under the proper subgroups. Each subgroup also has a brief but detailed description about what is stored in it, making it easier to find the correct file quicker. All of these features make life a lot easier when navigating through this gitlab page. I couldn’t imagine trying to work on the same project with an unorganized mess of a gitlab page. It’s really something that I think gets taken for granted when it’s present but extremely noticeable when it’s lacking.

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

The Modern Standard for Collaboration: Version Control

Introduction

Version control is important for modern software development, enabling teams to collaborate effectively, manage changes, and maintain code quality. The blog post “Version Control Best Practices” by Tobias Günther offers 10 tips on how to use version control systems (VCS) like Git more efficiently.

Summary

The blog outlines essential best practices for working with version control systems, focusing on enhancing productivity and reducing errors. There were ten points but here are the top 5 most important in my opinion:

  1. Use Branches: Branches allow developers to isolate changes, experiment, and test without impacting the main codebase.
  2. Commit Often: Regularly committing small changes ensures incremental progress and simplifies debugging.
  3. Write Good Commit Messages: Clear, detailed commit messages help team members understand the context and purpose of changes.
  4. Go Beyond the Basics: Developers should invest time in learning advanced Git features like interactive rebases and cherry-picking to enhance their workflows.
  5. Don’t Commit Half-Done Work: Each commit should represent a complete, functional unit to maintain repository stability and clarity.

Why I Chose This Blog

I chose this blog because version control is a fundamental skill for software development, yet its nuances are often overlooked in coursework. While I’ve used Git for assignments, I realized that my approach lacked the deeper understanding laid out in this blog.

Reflection

There was a big emphasis on commits, which makes sense as commits are an integral part of version control and most of the tips talked about in the blog are practices that I do regularly, such as writing good commit messages. I don’t think it’s particularly hard to understand these standards for version control, and once you know them it’s just the norm to follow them.

Branching was something that I hadn’t known about prior to learning about it in class, but it makes sense to separate each new feature into its own area to work on instead of putting everything in main. This “tip” is really just a necessary way to stay organized and keep the repository and its pull requests in order.

Going beyond the basic features of git like committing and pushing is also a great tip, because although you could navigate git with only the basics, learning the more advanced features like rebasing can help greatly in certain situation where you’d be happy you know how to do it.

Future Application

There were some takeaways from this blog that I could incorporate into my own workflow. I think that I should commit more often than I do. I tend to forget to commit and only do so when I stop working but by then there could be a few features that are all crammed into one big commit. 

Citation

Version Control Best Practices by Tobias Günther

https://www.git-tower.com/blog/version-control-best-practices/#8-agree-on-a-workflow

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

An Efficient Way to Work: Software Frameworks

Intro

Frameworks play a pivotal role in streamlining software workflow. The blog post “Top 50+ Software Development Frameworks“ by Trung Tran provides an insightful overview of the purpose, types, and benefits of frameworks, making it an excellent resource for anyone involved in the software development world.

Summary of Source

The blog explains the concept of software development frameworks as pre-built tools and libraries that provide a structure for developing applications. It highlights the following key points:

  1. What is a Software Development Framework: A framework is a pre-designed structure of reusable components and tools that streamlines the software development process.
  2. Advantages of Using a Software Framework: Frameworks enhance efficiency, improve code quality, simplify maintenance, and enable faster development cycles.
  3. Disadvantages of Using a Software Framework: Potential drawbacks include steep learning curves, limited customization, and dependency on the framework’s updates and support.
  4. How to Choose a Suitable Development Framework: Developers should consider project requirements, scalability, compatibility, and their team’s expertise when selecting a framework.
  5. 50+ Popular Software Development Frameworks: The blog lists widely used frameworks like Angular, React, Django, Spring, and Flutter, categorizing them based on application types.

Reason For Choosing This Source

As someone learning to build efficient and maintainable software, understanding frameworks is fundamental. This resource breaks down everything needed to know about frameworks before jumping into using them, even listing the top 50 is really useful to see for any project anyone may do.

Reflection

Prior to this blog I didn’t really have a strong understanding of what a framework for software development was. I had heard of popular ones like ruby on rails or spring for java, but I wasn’t sure what it really meant. Reading through this blog, I now feel I have a solid grasp on what they are, and how to choose one. On the topic of choosing one, there aren’t any that are one size fits all that will always be the perfect one to use, and it more depends on the project being worked on and the team behind it. I know frameworks are popular so I hadn’t considered some the disadvantages listed in the blog like the limited customization, where it might feel like you have less control of what your program does because you’re using this outline and can’t mold it as much as you may want to. A lot of times those disadvantages are overshadowed by the positives which is why they’re so often used.

Future Application

I’ve learned that frameworks are a really powerful tool that save a lot of time and help create efficient work, so I’ll make sure to study which framework is best for me to use in the future when working on projects. This blog post also helped me understand the limitations of them so I also know what to look out for in terms of drawbacks for whichever framework I might use.

Citation

Top 50+ Software Development Frameworks by Trung Tran https://www.orientsoftware.com/blog/software-development-frameworks/

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

The Human Aspect of Software Efficiency: Managing Your Software Team

Intro

Managing a team effectively is essential for delivering high-quality projects on time. A mismanaged team can lead to needless loss of productivity, whether it’s because of confusion between the team, or wasting time on useless tasks. This blog by Ben Brigden delves into strategies and practices that help teams collaborate efficiently, maintain focus, and deliver exceptional results.

Summary of the Source

The blog explores 9 tips of managing software development teams, but these are the main 5 I think stood out:

  1. Clearly Define Goals and Expectations: Outlining precise objectives ensures everyone on the team is aligned and working toward the same outcomes.
  2. Understand the Expertise of Your Team: Recognizing each team member’s strengths and specialties allows managers to delegate tasks effectively and maximize productivity.
  3. Protect Your Team from Busy Work: Shielding developers from unnecessary tasks helps them focus on meaningful, high-impact work.
  4. Emphasize Autonomy and Self-Reliance: Encouraging team members to take ownership of their tasks fosters independence and builds trust.
  5. Measure Performance and Strive for Continuous Improvement: Using performance metrics and retrospectives ensures progress and helps refine team processes.

Why I Chose This Blog

This Blog is a good resource that goes over the top points about working in a software team effectively. It talks about all of the aspects of being in a software team that someone might want to know to better understand their role.

Reflection of the Content

The blog emphasized that team success hinges on communication and collaboration. One point that stood out was the importance of defining goals and expectations clearly. This is probably the most important thing in a software team. Without goals the developers become aimless and don’t know what to do or how what they are doing fits into an overarching plan. This is why agile development and scrum in particular is effective, as it sets clear goals within a certain time frame, with a definition of done, so everyone is on the same page of what needs to be done and what it means for their task to be completed.

The emphasis on autonomy is probably underrated in team environments, because I think people see the word team and assume that everyone has to know what everyone else is doing. Being trusted with your own work probably has a physiological effect on productivity as well, where when someone is given responsibility, they are probably more likely to live up to their potential as opposed to if they are being babied.

Future Application

This blog has helped me better understand the ways a team should function to maximize its potential, and seeing as I plan to work in the tech industry, I think it’s valuable to know this to help myself and my future team work to our potential.

Citation

9 tips to manage your software development team (no coding required) by Ben Brigden

https://www.teamwork.com/blog/software-development-team-management/.

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

The Backend Communication Necessity: REST APIs

Introduction

APIs are the most important piece of communication between software applications. REST APIs, in particular, have emerged as the standard for building web services due to their simplicity and scalability. This blog by John Au-Yeung explores best practices for efficient REST APIs, a topic that is essential for modern software development.

Summary Of The Source

  1. Accept and Respond with JSON: JSON is the standard format for APIs due to its readability and compatibility with most programming languages.
  2. Use Nouns Instead of Verbs in Endpoint Paths: Resources should be represented as nouns in endpoint paths, such as /users or /orders, for clarity and consistency.
  3. Handle Errors Gracefully and Return Standard Error Codes: APIs should provide clear error messages and use appropriate status codes, like 404 for not found or 500 for server errors.
  4. Maintain Good Security Practices: Implement authentication methods such as OAuth, encrypt sensitive data, and use rate limiting to prevent abuse.
  5. Versioning Our APIs: Proper versioning, such as including the version in the URL (/v1/users), allows APIs to evolve without disrupting existing integrations.

Why I Chose This Blog

I selected this blog because REST APIs are integral to modern software development, and understanding their design is essential for building scalable and maintainable systems. The blog provides a good understanding of REST APIs for developers at all levels.

Reflection On The Blog

The blog went over the standards when designing REST APIs. One aspect that resonated with me was the emphasis on clarity and simplicity in API structure. For instance, using nouns like /users instead of verbs like /getUsers for endpoint paths. Another valuable takeaway was the focus on error handling and standard status codes. Before reading this, I hadn’t fully appreciated how critical it is to provide meaningful error responses to help developers debug issues. I now recognize how returning clear messages and consistent codes can improve the user experience and reduce confusion for developers. The section on API versioning was also particularly insightful, as I hadn’t previously considered how unversioned APIs could lead to breaking changes when updates are made. This made me realize the importance of planning for future iterations during the initial API design process.

Future Application

By adopting JSON as the default format and carefully designing resource-based endpoints, I aim to create APIs that are in line with all that standards laid out in this blog. I will also make sure to maintain good security practices, such as implementing authentication. Additionally, I will incorporate API versioning to ensure compatibility with older clients as updates are introduced.

Citation

Best practices for REST API design by John Au-Yeung

https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

The Most Useful Tool In a Developers Toolkit: Development Environments

Intro

Choosing a development environment to use is a decision that can be made based on feeling, or by taking the time to think out each choice and analyze which best fits your needs. Either way the environment that a developer uses is what is super important as it’s where all code is made in any project, making it the tool that every developer spends the most time using. It’s a personal choice and this blog by Matthew LeRay goes over everything you need to know about developer environments.

Summary of Source

This blog encompasses all that is needed to know about developer environments, including their purpose, importance, and what IDE’s are with some examples. The main sections are:

  1. Definition and Purpose: A structured setup of tools and processes that enhances software creation by automating tasks, supporting debugging, and ensuring consistency with production.
  2. Types of Development Environments: Explains the purpose and distinct roles of development, testing, staging, and production environments.
  3. Integrated Development Environment (IDE): The evolution of IDE’s and what they offer such as speed/efficiency and customizable features.
  4. Setting up a Development Environment: Goes through the steps of configuring your environment, from choosing the IDE, to configuring it and using tools like build automation.

The Reason I Chose This Source

For any new programmer, looking for an IDE to use can be confusing because of the lack of knowledge about what they even are, mixed with the daunting task of choosing one to learn and use. I chose this blog because it bridges that gap of being a new programmer having no idea what a developer environment even is, to choosing and setting up their IDE. It’s a very reader friendly resource, that even some experienced developers could learn from.

A Reflection of IDE’s

I personally use Visual Studio Code for the majority of what I program, but have used IntelliJ as well. I chose my IDE more based on appearance and general word of mouth, which is why I gravitated towards VS code, as it’s arguably the most popular and user-friendly IDE. I do like IntelliJ as it feels good to use, and although a drawback to others might be it’s a java only IDE, I only use java so that isn’t a problem for me. VS code also has a great variety of personalization options because of the extensions tab in the IDE. Extensions are great for not only appearance but also functional improvements. I think extensions are a big reason VS code is so popular, as well as its ability to support many languages, not restricting it to one the same way IntelliJ does. An IDE encompasses a ton of different tools a developer uses, so picking one that fits your needs is important. Becoming comfortable and familiar with the IDE you use is more important than switching to the “best” IDE for a developer based on some abstract metrics that others believe is the most important thing to have in an IDE.

My Future IDE Plans

I think I will continue to use VS code for now, but I can see myself trying out more technical and not-so user friendly IDE’s like Vim in the future. There really isn’t a need to switch it up if it’s working and honestly I don’t think it should be switched often. I will also probably utilize IntelliJ more as I do think it’s the best IDE for java which is the language I use most often.

Citation

Understanding Modern Development Environments: A Complete Guide by Matthew LeRay

Understanding Modern Development Environments: A Complete Guide

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

The Hidden Backbone of Software Development: Software Documentation

Intro

In software development, documentation often takes a backseat to coding, testing, and deploying. However, software documentation is the backbone of more easily maintainable, scalable, and collaborative projects. This blog post by David Oragui gives useful information on why documentation is essential and how it supports both developers and end-users throughout the software lifecycle.

Summary of Source

The blog post explores the role of software documentation and offers practical advice on creating and maintaining it effectively. The main sections are:

  1. What is Software Documentation?: A definition and explanation of how it serves as a guide for developers, users, and stakeholders, providing clarity on a system’s functionality and usage.
  2. Types of Documentation: A breakdown of key categories, including user documentation, developer guides, technical documentation, and process documentation.
  3. Best Practices for Writing Documentation: Practical tips, such as structuring content logically, using plain language, and keeping documentation up-to-date.
  4. Using Software Documentation Tools: The different type of documentation tools and the reasons to consider them including automation, collaboration, and accessibility

Why I Chose This Blog

I selected this blog because it is a concise resource that explores all there is to know about documentation, making it a great guide to refer back to when needed. In my coursework, the focus has largely been on coding, but I’ve noticed that a lack of proper documentation can make even the best-written software hard to use and maintain. This blog stood out for its clear and actionable advice, which is especially valuable as I create projects and prepare for internships.

Reflection

The blog’s structured approach to explaining software documentation makes it great as an introductory resource. One section that particularly stood out was the breakdown of the different documentation types. It clarified the different audiences for documentation end-users, developers, and stakeholders, and how each requires tailored content. For example, user documentation should be simple and accessible, while developer guides need to be more technical and detail-oriented.

This difference in target audiences was an eye-opener, even though it does seem obvious when it’s said. There’s no reason to have documentation about technical details that an end-user will see because they won’t understand it or even need to. Whenever I thought about software documentation before, it was just a one size fits all document that explained the technical details of the software.

Another valuable takeaway was the emphasis on keeping documentation up to date. It made me consider the consequences of never updating documentation and having incorrect information that could end up causing a lot of trouble. When the point of documentation is to make it easier for all parties to understand a project, outdated docs would contribute to the very problem it’s trying to solve.

Future Application

Moving forward, I plan to apply these best practices to my projects. I will make sure to make different documentation resources for different target audiences, also making sure to update the docs every time a change is made to make sure there is no confusion with outdated information. Software Documentation simply makes the whole process of understanding and maintaining code a lot easier so there is really no downside to adding quality documentation to a project.

Citation

Software Documentation Best Practices [With Examples] by David Oragui

https://helpjuice.com/blog/software-documentation

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.