Author Archives: Adam Jacher

Sprint 3 Retrospective

Gitlab Descriptions

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/inventorybackend/-/commit/96464eb852632dc728f438b7f4c0165831091a80 – Changed the modal pop-up to better match our visual identity guidelines.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/inventorybackend/-/commit/93a04bbdc54647d56d91fe797d7b3fea86c42236 – Changed the inventory table layout to accommodate for smaller screen sizes by adding a slider to view the entire length of the table.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/inventorybackend/-/commit/d81fe66a0adf27aff2dd29f7ba3713be9b9aa09d – Added buttons to navigate between the scanner and inventory pages to not make it necessary to go to the home page first.

Sprint Reflection

This was our last sprint, and I think that during this sprint a lot of my previous qualms were addressed and fixed. One thing I had said before was that I thought our communication was lacking in certain areas and that since we were working in pairs, the rest of the group was mostly in the dark about what we were working on, but I felt an increase in transparency this sprint. It felt like more of a team effort which I think was in big part because we were finally finishing up working for the semester so everything that we were working on individually was coming together. Working on the final presentation also helped with this as we felt everyone needed to be on the same page to be able to deliver a presentation that showed off our project well.

This leads to what I don’t think went as well, which was that it didn’t feel like as much progress was being made toward the project this sprint, at least in comparison to previous sprints. This was probably due to our presentation preparation, as well as a focus on cleaning up already implemented features rather than starting new ones. We knew since this was our last sprint that it was the time to wrap up what we were working on, which is probably why it felt like not much was getting done, but in reality I think what we actually did was just as important. 

I can’t think of any major improvements to make to the team to get it to function better, as we worked just as well as I think we could have. It was a pleasure working with this team and I think that these reflections in past sprints helped us come to a point where those points of improvement were answered and made us become an efficient team. As an individual though, I do think that I could have done more, which again circles back to the point of not feeling like too much was done. Looking back at what we’ve done though, I am happy with our progress, seeing as we started the semester with a blank slate and now we have a functioning scanner/database app. It’s just a personal feeling that more could have been done, but I think it’s true that there is always room for improvement. And I also think it’s good for me to have that mindset, but for this project specifically I’m not disappointed with my performance.

Apprenticeship Pattern

The apprenticeship pattern that stuck out to me for this sprint was the “walking the long road” pattern. It’s an important one that comes with mastering a discipline, the mindset that you are never really done learning, that there is always more knowledge to be had, always more challenges to overcome. This being our last sprint makes this pattern important, because we just spent months working on a project, emulating a real scrum team, but it doesn’t mean we are anywhere near mastery. Just because the semester is over and we completed this chapter doesn’t mean we are done, in fact I’d say we are at the very beginning of our journey still.

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 Best Java Testing Framework: JUnit

Summary of the Source

The blog post introduces JUnit as a unit testing framework designed for the Java programming language, explaining its evolution, core features, and significance. It outlines the primary components of JUnit, such as test cases, test suites, annotations (like @Test, @Before, and @After), and assertions. The guide also discusses test driven development (TDD) and how JUnit supports this methodology by encouraging developers to write tests before writing the actual implementation.

Additional features covered include mocking with Mockito and how to structure test cases for better readability and maintainability. Overall, the article serves as both an introduction and a deeper dive for those wanting to use JUnit effectively in real world software projects.

Reason For Selecting This Blog

I chose this blog post because it well written, and in only a roughly 10 minute read, covers everything there is to know about JUnit, at least as a foundation for starting out with it. It goes over what it is, why its used, and even its history, before diving into how to set the environment up to use it, the shows examples of test cases using JUnit. I think its an overall great resource for any developer who is interested in testing using Java as it covers all the bases.

Personal Reflection

I was introduced to JUnit in university, and learning it there was really helpful towards understanding how testing code works in general. I also liked JUnit especially because it seems very easy to understand and write, where only a couple lines of code could write a test case for your code. Assertions are especially useful as that’s the end result of the test, and with JUnit it’s very simple. One line of AssertEquals tests the expected vs the actual, that’s all it takes to test the correct output. I also see how this framework would be preferred when doing test driven development as each test is separated into different cases denoted by the @Test annotation. This makes it easy to make specific tests for each feature as development continues. I haven’t tried any other testing frameworks but now that I have used JUnit I think it won’t be as confusing to understand a different framework, but since I like how JUnit works I’ll compare the others to it like it’s the gold standard for testing frameworks.

Conclusion

Knowing about JUnit is imperative if you plan on testing code in Java. It has everything that a testing framework could want by making it easy to write, handle multiple test cases, and including assertions. I know that if I ever use Java in the future to test code, I will use JUnit because of how powerful, reliable,  and simple it is.

Citation:
 HeadSpin. (n.d.). JUnit: A Complete Guide. https://www.headspin.io/blog/junit-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.

Code Reviews and Their Importance in Keeping Maintainable Code

Summary of the Blog

The article emphasizes that code reviews are not just about finding mistakes but are primarily about improving code quality, spreading knowledge across the team, and building better, more maintainable software.

  • Code reviews help maintain consistent coding standards across a project.
  • They foster team learning, as developers can see different approaches to solving problems.
  • Good code reviews catch potential bugs and architectural flaws early, preventing costly fixes later.
  • Reviews create a sense of shared ownership over the codebase, leading to more sustainable, long-term development.

He also stresses that code reviews should be approached positively, focusing on collaboration rather than criticism. The goal is to help, not to criticize harshly, and reviewers should offer suggestions rather than simply pointing out what’s wrong.

Why I Chose This Resource

I chose this blog because it reads as someone who actually has been through the experience of not doing them and realizing the hard way why they exist and are used regularly. It’s a resource that goes through the whole process of code reviews, but the added element of feeling that the person writing it actually understands why the thing they are explaining is useful makes it feel a lot more credible. It also just makes it easier and more interesting to read in my opinion.

Personal Reflection

Messy codebases can lead to immense technical debt over time, and code reviews are the solution. Of course it would be great to simply adhere to the rules and standards set by the group to avoid the sloppiness in the first place, but the code reviews are necessary to ensure that if there is messy code it doesn’t make it into the production branch, like a last defense. The steps laid out in the blog create a healthy environment to improve the code being reviewed, while also being respectful in the manner it is done. The checklist of standards to go over during the review makes sense and is the base of keeping everything “correct”, but it pleasantly surprised me when they mentioned the correct way to communicate the changes. Most people wouldn’t think about how they mention the changes found, but this blog states the correct way, even showing examples, which takes into account respect for the developer as well as being descriptive / informative with the comment. 

Conclusion

This blog made me understand why code reviews are important. Before reading I thought similarly to the author that code reviews are a waste of time and just some bureaucratic process, but now I see that the time spent on making all of the code cohesive and adhere to coding standards actually saves a lot of time in the long run from fixing bugs and reading sloppy code. 

Citation

Kravcenko, V. (n.d.). The Importance of Code Reviews. Retrieved from https://vadimkravcenko.com/shorts/code-reviews/

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 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.