Category Archives: CS448

Libre Food Pantry

The title of this blog post is also the name of the project I will be working on this semester in SC-448 together with my group The BZ PJ’s. It is a rather interesting project that will have us design and create an interface to a food pantry that will allow other to take food with them.

What is really interesting to me is the learning aspect. The learning about agile development and FOSSism, both of which will be a great practice for my future career in the Computer Science field. Especially the Agile Development practice will be something I’m looking forward to as it has become the standard of the industry and the more I and other know about it and are comfortable doing the better.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Beginning of THE END

Like the title says this will be the blog for my final semester of my Computer Science Major at Worcester State University. Let’s hope it will be as fun as the rest of them. This time we will be working in groups on LibreFoodPantry.

From the blog #CS@Worcester – Pawel’s CS Experience by Pawel Stypulkowski and used with permission of the author. All other rights reserved by the author.

Refamiliarizing Myself with LibreFoodPantry

After reviewing the various links posted on the main LibreFoodPantry website I think the most interesting item to me was the “What’s New” page. I really like the concept of this page and as someone who has been following the project for the past couple of months primarily through Discord notifications, I think it is extremely useful to have a page on the main website that highlights important changes in plain text versus a bot posting GitLab events through Discord. I am a bit surprised there isn’t more on this page yet, given the many new changes to the organization of projects I saw yesterday in the first CS-448 class. I also wonder how this page is different from the announcements channel in the Discord server.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Beginning CS-448

This week is the beginning of the spring 2020 semester and the last course of the software development concentration, CS-448. I am excited to finally be working as a developer on one of the LibreFoodPantry projects and can’t wait to get started!

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Sweep the Floor

For my last apprenticeship pattern blog post, I felt that the pattern Sweep the Floor was appropriate given where I currently am at in my career, given that I hope to be starting in the very near future. This pattern refers to the scenario in which you’re a new apprentice on a project or a new member of a team and you’re not sure what your place is in the team, so you want to contribute and earn the team’s trust. The solution to this is to volunteer for simple, necessary tasks that no one else wants to do and to make sure to do a great job with them. Of course, you want to make sure that you don’t end up only doing menial tasks that no one else wants to do and that you’re given more challenging assignments after proving yourself “worthy”.

As I said earlier, this pattern is probably one of the most applicable to me at the moment, because once I start I can see myself in almost the exact same scenario as described in the pattern. I always figured that most junior level roles start with you being assigned simple tasks like one-liner bug fixes to help you get acquainted with the code base, but I hadn’t considered that it would be a good idea to take on tasks like literally sweeping the floor in order to build confidence as a member of the team. Of course, I don’t entirely agree with consistently taking on tasks that aren’t relevant to what you want to work towards, but there’s merit in doing menial labor when you happen upon it. As long as you make sure to let it be known that you want to be challenged and not just be comfortable standing still working as the team’s gopher.

Overall, I would say that it’s very likely that I’ll end up using this pattern in the very near future, so hopefully I remember to avoid the negative consequences of applying it. In fact, I wouldn’t be surprised if this pattern would be useful for me anytime I happen to enter a new team, not just my first one.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Sprint 6 Retrospective

For the last sprint of the semester, I spent most of my time working on my part for our groups final presentation. There was one minor bug fix that I made involving an incorrect mapping for one of the product endpoints found from a user reported issue, but otherwise the rest of my time was spent on the presentation. This bug in particular could have easily been avoided if the project contained tests for each of the endpoints maybe by using a mock database. If, for example, we had a test that tested what would be an expected successful response, then the test would have failed for the given endpoint because it gave a 404 not found response instead.

For the presentation, since my task was separate from the main project for the food pantry, my section felt like it was a short, stand-alone presentation contained in a longer one. Looking back on what I did for the project, I definitely feel like it wasn’t too complicated and if I needed to do something similar now it wouldn’t take me nearly as long.

That being said, I think there are several major things that I should take away from this project. First of all, although the resources that I followed through were helpful in its creation, I wish that I had started from the ground up to understand how everything actually worked. It’s very easy to get something to do what you want from making minor changes to resources you’ve already found, but being able to actually understand how everything is working together and also being able to explain it well are much harder and take time. Another big takeaway is to make sure to have good tests and to make sure everything is still working properly by running through those tests after making any changes. The fact that the bug with the typo in one of the get mappings exists is proof that I hadn’t properly tested the code to make sure that everything was still working as intended when I pushed my code and created a pull request. I was very fortunate to have run into this issue at the end of the project because if I hadn’t then I might have gone on to make the same mistake in the future.

If anyone happens to work on the project in the future, the first thing they should definitely do is implement the automated semantic versioning that I neglected to do myself. It’ll save them a lot of headache if they make any changes because they won’t have to remember to update the version in multiple locations. Without a doubt, when I saw that issue, it was clear that it was poorly designed. There’s no reason for the current version of the project to be hard coded in multiple locations. Actually, when I pushed the changes for the endpoint bug fix, I ended up forgetting to update the version number and the pull request had already been merged, so definitely fix that first.

Link to project GitHub repository:
https://github.com/LibreFoodPantry/FoodKeeper-API

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Nurture Your Passion

The apprenticeship pattern Nurture Your Passion refers to the problem in which you feel the environment in which you work in is stifling your passion for the craft. Depending on which aspect of work you feel is doing this there may be different solutions for everyone. For example, if you’re in a situation of constant project death marches that are sapping your time and energy, then you need to set clear boundaries and protect your passion. Whether that means to decline working “culturally pressured” overtime to avoid burning out or not would likely depend on how much you feel these death marches are affecting you.

As someone who hasn’t had much if any experience in the industry, this pattern definitely worries me a little. I’ve heard similar horror stories about project death marches from game developers working in the games industry. People who were filled with passion for their craft entering an industry that commonly abuses that passion with forced overtime until they burn out. Then, once you finish the project you’re working on, you’re laid off in an effort to cut costs by reducing headcount because you’re no longer needed, not because you’ve done anything wrong.

Obviously this isn’t the case with every company and the software development industry likely has many differences when compared to the games industry, but they do bear many similarities as well. This problem can be avoided by finding the right company that offers what you’re looking for, whether that be working overtime on something you believe in and enjoy, or somewhere that offers you good work-life balance. I’m always a little bit worried getting stuck in a situation with poor work-life balance because I’m not sure I would be confident enough to put my foot down, so I’ll have to remember in the future that I should focus on what’s best for me because I’m sure most companies wouldn’t think twice to cut costs whenever they can.

Overall, I agree with what the pattern’s saying and hopefully I’ll remember to nurture my passion even if it means getting passed over for promotions or having to find somewhere else to work.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Find Mentors

The apprenticeship pattern Find Mentors refers to the problem in which you feel like you require help and guidance because you’re not sure where the path is taking you and you feel unprepared for what’s to come. The solution to this is to reach out to other craftsmen who are ahead of you and to try your best to learn from them.

This pattern in particular was interesting to me because I feel as though I’m at or nearing a point in which I would benefit greatly from mentorship. Of course, no matter how far along the path you are, there’s always something to gain from mentorship. People who just graduated or recently graduated, I feel, are more likely to have that feeling of being unsure of what they should be doing. These are the people who need help and guidance the most in order to push them along the path. Even though it would be ideal for apprentices to find mentors, it’s definitely not as simple as it sounds. I’m certain that some people who are in need of mentorship don’t feel as though they know anyone who they feel comfortable asking to be a mentor to them. One of the most interesting parts of the section is that, even if you feel intimidated about reaching out to someone to ask for an apprenticeship, the risk of being rejected or considered strange by a potential mentor is relatively low, while the potential payoff is huge. So, if you find someone that you’re really interested in learning from, you should definitely reach out to them as there’s so much to gain.

I don’t feel like the pattern really changed the way that I think about Software Engineering, but I think my biggest takeaway from this is the make sure to not be too intimidated to reach out for mentorship. Had I not read this pattern I’m certain that I would have felt that way for a long time, so hopefully in the future I power through. I think it would be a good idea to seek out opportunities to find potential mentors in the future.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Sprint 5 Retrospective Blog

For this week’s sprint, I’ve spent most of the time looking into a way to automatically increment the version number (based on semantic versioning) every time we make changes. Currently there is a reference to the version number in 4 different places: The Procfile used by Heroku, the build.gradle file, the Java configuration file for Swagger, and the README Markdown file. To do this, I’ve been looking at different Gradle plugins that could do this automatically. There seem to be many different options available, but there doesn’t seem to be one that completely fits what I’m trying to do. I think that the fact that some of these files simply have the version number hard coded in is causing this issue. It would be simpler if the version number was located in one place (maybe a version.properties file) where all of the other files simply reference that file to do what they need to do with the version number.

While it’s not exactly an high priority task, given that there doesn’t seem to be many more changes needed to be made to the project at the time, it’s important to automate the version incrementation now in case the project needs to be updated in the future. It’s definitely not a good idea to keep it the way it is, as having the change the version number in multiple locations could potentially break something if one of them is forgotten. For example, we already ran into an issue where Heroku couldn’t find the jar file created because the version number hadn’t been updated in the gradle.build file but it had been in the Procfile. This caused the jar file that was created to have the wrong name, so Heroku couldn’t find it.

Also, another thing that I want to start looking into is to add unit tests using JUnit, as it’s something that I’ve neglected to do but definitely want to get done before the semester ends. That would include some basic unit tests for each class to make sure their methods are working properly but also some Spring Boot specific tests. For example, I should be able to create tests for each endpoint to confirm that they’re working properly, perhaps using some of the techniques learned from previous coursework such as mocks. Spring Boot appears to have a wide variety of auto-configured annotations that could potentially be useful for creating these tests. For example, the annotation “@RestClientTest” disables full automatic configuration and instead only applies the configuration that is relevant to REST client tests. This ensures that Jackson and GSON support is auto-configured.

In conclusion, I’m hoping to finish up with the automatic versioning as well as added necessary tests to the project by the end of the last sprint and before the presentation. I definitely don’t want to leave the project without adding any tests as that’s bad practice. In any future projects I’ll need to make sure not to neglect creating useful tests but I also want to avoid creating useless tests that were made just to have tests in the project.

Sources:
https://www.baeldung.com/spring-boot-testing
https://www.baeldung.com/restclienttest-in-spring-boot
https://github.com/davideas/GrabVer

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Expand Your Bandwidth

The apprenticeship pattern of “Expand Your Bandwidth” refers to the situation in which you’ve picked up a basic set of skills, however your understanding of software development is still narrow and only focused on the low-level details of what you’ve been working on. In this situation, you’ve only been taking in a relatively small amount of information gradually, but sometimes you need to take in a large amount of information and efficiently absorb it. So in this case, “Expand Your Bandwidth” means to be able to do just that.

I can see how this pattern is really important and would be immensely helpful to master, but being able to take in more information than you’re used to and at the same time efficiently absorb it, understand it, retain it, and apply it is a tall task. No doubt that mastering this early on in your career will be a massive boon.

This pattern includes some useful examples of where you could seek out new knowledge and experiences. For example, signing up for Google Reader or any other blog aggregator and subscribing to software development blogs that interest you is definitely a good idea to learn about a variety of topics from multiple perspectives. If nothing else, this is something that I certainly plan on taking away from this post. Rather than wasting my time on websites like Reddit, I think it’s in my best interest to spend that time reading something more productive. I also think subscribing to a moderately high-traffic online mailing list and trying to answer people’s questions is a good idea as well (maybe something like stackoverflow).

Overall, I’d say that this pattern made me understand a little better about how an apprentice will have to take in much more information than they’re used to taking and also be able to process and retain it, while at the same time not getting overwhelmed by it. Of course there are times in which you should stop focusing on expanding your bandwidth and come back to the craft, so it should only be used as a means to an end.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.