Author Archives: Adam Jacher

Sprint 2 Retrospective

Gitlab Descriptions

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/addbarcodefrontend/-/commit/6999f8a611a955be33526c2e6f712240f69ab5c4 – Cleaned the project folders and files to remove any unnecessary files and clean up the directory paths, also changed the docker files to run the website locally.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/addbarcodefrontend/-/commit/08d0b14fc04493a29242fd458a1bcf05992dd603 – modified the layout of the website to be responsive to smaller screen sizes and added the WSU logo.
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/inventorybackend/-/commit/9b6d6d0d68e0387f1214410f56702fce3b84f3a8 – copied the work from the addBarcodeFrontend over to the inventoryBackend project to connect to our backend.

Sprint Reflection

We all worked well this sprint to put together a nearly finished product. I am confident that by the end of sprint 3 our product will be ready to be used, but likely could use improvements still. Each of us has been diligently working on our assigned issues and bringing them together to make it all work. Our team started this project from scratch unlike most other groups and I feel proud of the progress we have managed to reach in this short time, even considering the fact that we decided to add on to the initial task that was given to us.

I don’t think that our communication was as good or as effective as it should have been. There was a large sense of abstraction between each team member and their work, where changes were being made and there was progress toward a better functioning product, but the details of who was doing what were somewhat lost I feel. It seemed as though we each knew what we were supposed to do and just did it, but I felt lost when I was asked about my teammates’ roles. Another thing I think could be improved is the actual codebase. Looking at it now is confusing and although it does work, it doesn’t meet any of the design principles that make code efficient to read and manage. 

Speaking on the things I thought could be improved, the communication heading into the last sprint should be better as we’re rolling out final changes. This is the time to let our teammates know of any problems we’re facing and the changes we’re making to solidify our project before we leave. This also leads into my point of refactoring and documenting. As I said previously, I think that the code is confusing and doesn’t follow design principles so I think we could improve the clarity by refactoring wherever possible and also making comments where necessary to describe how something works.

In relation to the lack of design principles, I learned about them in the software design class and fell into the trap of making code that works now, but isn’t optimized for future use. This is a basic mistake that I knew about but still regrettably made. It’s very easy to make code that works now but won’t be easy to read or modify later. This is a problem I’ve realized I have made and I’m glad I made this mistake now because I can learn from it and hopefully avoid it in the future by being mindful about my development and taking the extra time to be careful with my software design.

Apprenticeship Pattern

The “construct your curriculum” apprenticeship pattern was relevant to me during this sprint. It basically states that your path to mastery won’t be laid out for you, and you are going to have to be the one in charge of what and how you learn. I feel this pattern was reflected this sprint with the lack of guidance that was given to us. This forced us to lay out our own road to learning what we needed in order to complete the task we were given. Having known about this pattern during the sprint I would have seeked out more sources and probably learned more because I would understand that my learning starts and ends with me so if I am unhappy with my level of knowledge, then it’s on me to improve that.

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.

Test-Driven Development: An efficient development process

Summary Of The Source

  1. The process of TDD: There are three main steps to the TDD process, including the “red phase”, where a test is written but expected to fail. The green phase where code is written, enough to make the test pass. Finally the refactoring phase that aims to improve the code in functionality and in design metrics.
  2. Benefits of TDD for software teams: TDD is an implementation of agile development, since there is constant feedback on the tests and the code being written for them. This makes it so that the teams are regularly communicating and on the same page for fulfilling the requirements. Other benefits as well such as lower long-term costs, documentation, etc.
  3. Best practices for TDD: Organize correctly, making sure that naming conventions specify which function is being tested. Create tests that are simple and target only one aspect to assess, this makes it easier to pinpoint failure in the code. 

Why I Chose This Resource

I chose this blog post in particular because it is very easy to read for someone who is new to this process, providing all the necessary information needed to really understand what it is and its benefits without too much technical jargon. 

Personal Reflection

I have learned in the past about the waterfall development process vs the agile process, and that agile was pretty much just better, both in terms of time and resources spent. This blog made me realize that TDD falls under the agile framework and that makes the development more responsive to change along the way. It personally seemed silly to me at first that the test would be written first, testing seemingly nothing and only being there to cause confusion, but now I understand that it acts as more of a set of restrictions that keep the code produced working correctly, kind of like a mold that the code has to fit to work. This approach actually seems very intuitive because of the constant feedback and the way the functionality is built around something that is tested to work. To me, there don’t really seem to be any glaring downsides to this form of development unless the team decides against it and has a more comfortable development process, which for them would work better. It’s a simple strategy but it seems very clean in its workflow and deployment. 

Future Application

After learning more about this process, I would like to work in an environment where this is practiced. It seems very intuitive and efficient and utilizing it would help me get a better personal feel for it. Developing around tests probably seems confining, but I think it does produce more correctly working code than the other way around.

Citation


 CircleCI. (2020, August 11). What is test-driven development? Retrieved from https://circleci.com/blog/test-driven-development-tdd/

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.

Understanding Static and Dynamic Testing in Software Development

Intro

Software testing is an essential part of the development lifecycle, ensuring that applications function correctly and efficiently. The blog post “Static Testing vs. Dynamic Testing” by TatvaSoft provides an insightful comparison and description of these two fundamental testing approaches.

Summary Of The Source

The blog post explains the key differences between static and dynamic testing, their benefits, and when to use each approach:

  1. What is Static Testing? This type of testing is performed without executing the code. It involves reviewing documents and conducting code inspections to detect errors early in the development process.
  2. What is Dynamic Testing? Unlike static testing, dynamic testing requires running the code to identify issues related to performance, security, and functionality. It involves techniques such as unit testing, integration testing, and system testing.
  3. Advantages of Static Testing: Helps detect issues early, reduces debugging costs, and ensures adherence to coding standards.
  4. Advantages of Dynamic Testing: Identifies runtime errors, ensures the software behaves as expected in real-world scenarios, and validates functional correctness.
  5. When to Use Each Method? Static testing is best used in the early stages of development to catch errors before execution, while dynamic testing is crucial before deployment to validate real-world performance.

Why I Chose This Blog

I chose this blog because it breaks down the question of static vs dynamic testing really well. It has clear sections that serve their purpose of answering the important details, such as what they are, their benefits and disadvantages, and even comparing them. It’s a great blog to check out for anyone new to this by keeping it clear and understandable. 

Reflection

The blog reinforced how skipping dynamic testing can lead to undetected runtime issues, which can be costly and damaging after release. One key takeaway for me is the necessity of balancing both testing methods. Relying solely on static testing may overlook execution-related issues, while dynamic testing alone can result in avoidable errors slipping into the later stages of development. A collection of both is needed or at least most optimal, but practicing good static testing early makes it so that the dynamic testing which comes later is less prone to errors.

Future Application

I think in the future, when going about testing software, I will definitely keep in mind these two methodologies and probably incorporate them both as I think static testing is very valuable to prevent any errors or bugs before running but dynamic is really useful to actually see the end functionality as you’re testing. It’s an important topic to know as correct testing methodologies and practices keep code clean and working properly.

Citation

TatvaSoft. (2022, November). Static Testing vs. Dynamic Testing. Retrieved from https://www.tatvasoft.com/outsourcing/2022/11/static-testing-vs-dynamic-testing.html.

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.

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.