Author Archives: joshuafife

Sprint 2 Retrospective

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/merge_requests/14

This is my merge request for my finished task of writing documentation on how to implement and use nodemon for faster, more efficient development.

For Sprint 2, what worked well for me as an individual was being able to use the other pieces of documentation as a reference, and also being able to utilize Markdown’s formatting to give the documentation a clear and understandable look. I had also kept track of my process of installing nodemon with a Google Doc file, which made it immensely easier to retrace my steps and know what worked and what didn’t. Although it was my first time writing documentation, I didn’t feel lost at any points, and I was able to create a set of instructions I felt confident in and proud of.

As a team, we stayed very organized throughout the entire Sprint, keeping track of issues and merge requests as they were posted. Most merge requests were either discussed in-class or over Discord, which helped the other team members understand the changes being made. I feel like we really gelled well as a team, and morale was high, which enabled everyone to feel comfortable with bringing up issues or asking for help. Everyone has been great at completing their fair share of work, both when it comes to the project itself and the Sprint Review presentations. 

On an individual level, what didn’t work well was I felt as if I became distracted at times during class, when I could have been more focused on completing my work. This is something I am actively working on being better at. I could be a bit more productive in-class sometimes, but this is not to say I never get anything done. I also felt as if I wasn’t completely sure about how the documentation should be written, or if the instructions I wrote would be applicable to everyone. This is something I think is okay at this point, but it was a bit of a back-and-forth struggle when it came to making certain decisions.

On a team level, there was not much that did not work well. We’ve improved our communication from last Sprint, and we are getting issues done and merge requests out at a steady pace. I think something we might need to clear ourselves up on are certain issues regarding visuals, but otherwise I think we are in a good spot.

To improve as a team, we should ask either Professor Wurst, the client, or the Visual Identity Team some clarifying questions about our issues (what the visuals of the webpages are supposed to look like, for example). I think we could clean up our Issue Board a bit as well, as it seems a little cluttered with old Issues.

To improve as an individual, I should definitely try and focus a bit more during class. Productivity would increase, and hopefully I could get more done with the time we have left. I could do better in arriving to class on time, as the last couple of classes I was running late and had to search for parking for a long time. 

For this Sprint, not many of the Apprenticeship Patterns apply to me, so I’ve decided to go with “ Rubbing Elbows”. This describes a situation where one feels there are better techniques to the craft that are escaping them. This may not be exactly true, but it seems to be based on the apprentice’s experience and emotions about what they’re working on. It stems from stagnated learning, which can lead to one feeling inferior about their implementation.

I selected this pattern because while I was writing the documentation for implementing nodemon, I felt as if I was overcomplicating the whole process and that there was an easier way to accomplish the same goal. I felt that, realistically, installing nodemon shouldn’t have been too difficult, and that I was using an inferior way to implement it. It relates to my experience during this Sprint because I was feeling inadequate about my work being the “right” approach to implement nodemon.

If I had read the pattern before/during the Sprint, I would have asked another team member to work with me on installing nodemon to see if it was truly as convoluted as I was making it. The other developer might come up with a different solution, which would be a good perspective to have.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/60

This is my merge request for my finished task of implementing nodemon into InventoryBackend in order for developers to utilize hot-reloading and for the correct port to be added for the database.

For Sprint 1, what worked well for me as an individual was my experience with nodemon itself, and being able to incorporate that experience to get a head start on the issue. Although it took me longer than expected to complete the implementation, having some background knowledge allowed me to be more confident in the changes I was making. The familiarity of the subject gave me some peace-of-mind.  

As a team, what worked well for us was our communication skills and being supportive and helpful of each other during class time. We kept ourselves organized with our issues and our Issue Board, which allowed for a clearer understanding of the tasks at hand. Our in-class environment as a team was very open and transparent with our problems and what we’re working on. Our communication from within Discord improved over the course of the Sprint, and we were able to keep each other up to date whenever we ran into a problem, made a merge request, or needed a question answered. 

On an individual level, what didn’t work well was my silence at the beginning of the Sprint. I struggled with incorporating and fixing nodemon, but I wasn’t asking for help early enough. Once I did ask for help, I was able to make great progress thanks to the assistance of my teammates and Professor Wurst. As one of my teammates had noted, if I had asked for help sooner, I might have been able to finish my issue faster. 

On a team level, we did lack in communication here and there, such as a lack of response on Discord, or others not being included or involved as much as they could have been. The Issue Board was too vague from the beginning, which made it hard to choose our issues and perhaps led us to bite off more than we could chew.

To improve as a team, we should be narrowing down our Issues and specify them more clearly, so that our Issue Board and plan for the next Sprint is more refined and achievable. I think we should also start to do stand-ups at the beginning of each meeting to inform the team of what we’ve been working on and the status of our progress. Also, although this applies to mostly me, I think asking for help whenever we’re stuck would be a great improvement. 

To improve as an individual, I, as previously mentioned, should speak up when I am struggling to try and get assistance from my teammates. It’s always good to have alternate perspectives and fresh viewpoints, so someone else may see a problem or solution that I wasn’t seeing. I could do a better job at keeping up with my teammates’ work, as I sometimes don’t confidently, fully know what they’re currently working on. 

Although there are a few Apprenticeship Patterns that would apply to me, I’ve chosen to discuss “Retreat into Competence”. This pattern describes a situation where you are beginning to realize how much you don’t understand about the work you’re doing, what you’re expected to do, or even the work going on around you. It eventually becomes too overwhelming, and to fix it, you revisit your “comfort zone”; you involve yourself in your area of expertise to gain confidence back and to take a quick break. 

I selected this pattern because I often feel weighed-down by an overwhelming sense of ignorance from all of the languages, frameworks, and other factors of programming that I do not understand. It makes me lose confidence in my ability to code, as it emphasizes my weaknesses. In terms of this Sprint, although I chose an issue that I had a little bit of experience with, the roadblocks I hit made me realize how much I didn’t fully understand about nodemon and especially docker-compose files, connecting to databases, images, and the like. Finding my ignorance in these areas reduced my confidence in my ability to program and get this issue solved. 

If I had read the pattern before or during the Sprint, I would have stepped back, worked on something utilizing my strengths, and gained my confidence back. It’s good to remind yourself of what you’re capable of.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

After reading the first chapter and the introductions of chapters 2-6 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye, I really enjoyed the message it had to offer. I often find myself stuck in a rut almost, feeling like I’m so far behind yet feeling like I can’t move forward. This is mainly in reference to my software skills and capabilities, but reading how one utilizes an apprentice-esque role and transitions into a journeyman and then a master was quite helpful.

I found Dave’s story to be quite interesting. It details him attempting to learn a programming language on his own early on, and then growing frustrated and quitting. It wasn’t until he gained mentors who recommended him specific books on programming that kick-started his brain into gear, and working with these new languages really stuck. Another large piece of his journey was creating and working with a breakable toy in the new language, so being able to play with and experiment on a project using a new language is very important to the learning process.

The reading has definitely made me change the way I approach the learning process and becoming a better programmer. It can be tough to stay focused, as the goalposts seem to always be moving. But knowing that you’re making progress and continuing to advance your learning is what can help keep you going. A lot of the chapters introductions provided great insight on how to improve oneself. Being willing to “empty your cup” a little by getting rid of bad habits in order to learn something new, understanding that the mountain you’re climbing keeps getting higher and higher as learning never stops, and more. 

I don’t disagree with much in the reading. It did emphasize the importance that books have to learning despite the vastness of information on the internet, and while I agree, I find that good, physical books can be difficult to find in some ways. Either it is too expensive, or it is not at your local library, etc. Sometimes these books that you do find can be very outdated as well (which tend to be most books I find at the library), however that is not to say there isn’t outdated or misguided information on the internet today. Although I haven’t had much luck or experience with software development related books, this reading has inspired me to continue to search for the one that fits my need.

The chapters most relevant to me are chapters 3 and 5, “Walking the Long Road” and “Perpetual Learning”, respectively. With chapter 3, I often find myself stagnant in my learning, but when I see the rate at which others are learning and growing, it inspires me to take charge again. As for chapter 5, it’s all about me finding the learning method best suited for me, and finding and experimenting with my strengths and weaknesses.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Exploring LibreFoodPantry and Thea’s Food Pantry

After reading about LibreFoodPantry, I found the 16 FOSSisms on the Values page quite useful. A few of them stood out to me, such as “Ask Forgiveness, Not Permission”, which helps encourage students to make changes even if they might be incorrect. These changes, along with their feedback, can provide valuable lessons and experience to the students, and any mistakes can be easily undone. Another FOSS value that stood out was “Begin with the Finishing Touches”, which essentially means that students should start their contributions off with small bug fixes and the like to give them a sense of productive contribution. If they start off too grand, then they might become discouraged and unlikely to be productive. I chose to write about these FOSSisms because they’re helpful and encouraging “rules” for a open-source newcomer to follow, as it can help introduce someone to the space and give them an idea on how to navigate the ethics of open-source.

One thing from Thea’s Pantry I found very useful was the User Stories in the Documentation. These are stories of how the user would interact with the software, which gives a guide to how the software might be designed. I chose to write about this because having step-by-step instructions on how a user or administrator would interact with the software makes it less complicated for developers to understand how the software should work. Figuring out the user interface and design flow first is much easier than trying to code and create the design flow as you go.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

What is Vue and Why is it Popular?

Link to blog: https://medium.com/js-dojo/how-is-vue-js-making-the-javascript-world-a-better-place-b3dc39ba4fe7

It’s the end of the semester, and the last thing we covered in class was a bit of front-end structure and how things work. Of course, there’s your HTML and CSS, and I understood that. But we were using Vue in our examples, and I got curious. I’ve heard of Vue before but never used it, so I was interested in its purpose. Such curiosity led me to Fotis Adamakis’ blog post How is Vue.js making the Javascript world a better place. We’ll be discussing the contents of this article today.

Adamakis’ blog post is quite in-depth compared to past articles we have covered. He believes Vue is quite beginner-friendly, as learning how it works and beginning to write code could only take a couple of days to a week (as long as you have some knowledge of Javascript, HTML, and CSS). Adamakis dives into some interesting parts about Javascript frameworks and how Vue approaches them.

Routing can be a potential challenge when it comes to tasks such as custom scroll behavior, nested route view mapping, and more. Vue has its own Router, and it configures the routes before any components are rendered. 

Vue’s approach to the architecture of a site supports component-building. To be more efficient, it includes single-file components. This is a beneficial feature of Vue, as it can contain HTML, CSS, and Javascript all in a single file. Adamakis also mentions Vue’s high satisfaction rating, with the majority of developers wanting to use it again! 

Adamakis mentions that Vue is great for testing too, as it has built-in support for Mocha and Jest unit testing or end-to-end testing with Cypress or Nightwatch. 

Adamakis concludes by stating that he feels Vue has combined all great parts of other Javascript frameworks into one, being easy to use with great documentation.

I selected this resource because it educates me more on why Vue is so popular and what it does well. It also has example videos to highlight the reasons and is well-written and easy to understand.

I found this to be a solid article for learning more about Vue and why it’s preferred. I also learned how Vue’s state management works. It’s interesting that with Vue, you can incorporate HTML, CSS, and Javascript into a single file. Perhaps it’s beneficial for the simplicity or organization of different web pages/parts of a page? Having all of the pieces of a component on one file is probably quite helpful. I hope to apply this to new web pages I might try and build (I would like to get more into building websites!).

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Pros and Cons of Java REST API Frameworks

Link to blog: https://dzone.com/articles/java-rest-api-frameworks-1

In class, we’ve been covering REST APIs and how to use certain call methods such as GET, POST, PUT, and DELETE. Before class, I had heard of REST APIs but never had any understanding of what they were, or how to interact with them. I figured I would dive deeper into other Java REST APIs. The article Java REST API Frameworks by Farith Jose Heras García lists some REST APIs along with their advantages and disadvantages.

García begins with a simple introduction to Java REST APIs and what they do, specifically how they enable communication between applications and other software, and make the passing of data easier. Each API on the list includes pros and cons, and then a CRUD (create, read, update, and delete) example using the API. 

First on the list is the wildly popular Spring Boot. According to García, some of the benefits of Spring Boot are that it is easy to use and set up, has a lot of built-in support, and has a large library of plugins and modules. The cons are that beginners might struggle to understand it, and it might be too much for smaller projects and better for larger projects instead.

Second on the list is Jersey. Jersey is simple, ideal for microservices, and also has a decent-sized library. However, García considers it slow and difficult to debug.

Third on the list is Play Framework. It’s lightweight and flexible, high performance, and also offers a library of plugins. It’s updated and designed for modern Java applications, as it works with Java 8 and Scala. Unfortunately, it has a tough learning curve and debugging can be a challenge.

The final on the list is Vert.x. It is lightweight, flexible, and has high-performance, and also supports JavaScript. The cons are that it is difficult to debug and might be hard to understand for a first-time user.

I selected this resource because it is an article that is a good reference for an updated list of Java REST APIs currently in use. It gets the point across for each item, whilst being a short enough read to be a good refresher for those unfamiliar with the information. It’s mainly beneficial for choosing which REST API to use with your project or application.

I found this to be a solid article for learning a little bit about Java REST APIs and how to choose them. For example, I did not know that Spring Boot is too heavy for smaller applications. The formatting was simple, and it’s pretty interesting to see the frameworks in action with the CRUD code examples García provided. Choosing the right REST API framework for your project’s needs is very important since many factors can go into such a decision (size, libraries, and easy learning curve). I hope to apply this to projects of my own and perhaps jobs where REST APIs are needed.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Uncovering Other Types of Software Architecture

Link to blog: https://dzone.com/articles/top-10-software-architecture-patterns-to-follow

Recently, we have covered a few different types of software architecture, namely Monolith, Client-Server, and Microservices. While these each have their respective use-cases, I wanted to explore more possibilities for the architecture of a software. Because of this, I have found the Top 10 Software Architecture Patterns to Follow in 2024 by Lucas Lagone. 

Lagone establishes a format to his top ten list by describing the overview, benefits, and use-case for each item. His number 1 software architecture pattern is layered architecture. According to Lagone, layered architecture (or the N-tier architecture), divides the software into several layers each responsible for their own functionalities (Lagone). This type of architecture encourages modularity, allowing for independent development of different layers of the software,  and can be utilized for a variety of types of applications (Lagone).

Lagone continues his list, discussing the rest of the architectures below:

  • Serverless Architecture
  • Hexagonal Architecture
  • Event Sourcing
  • Model-View-Controller
  • Microservices Architecture (covered!)
  • Service-Oriented Architecture
  • Event-Driven Architecture
  • Repository Pattern
  • Reactive Architecture

Lastly, Lagone writes about how one can choose the right architecture for their needs, and what factors come into play. Some of these factors include the complexity of the problem domain, the project’s requirements and goals, the scalability of the project, security, team expertise, etc. (Lagone). 

I selected this resource because it is a recently written (November 2023) article that is a good reference for an updated list of software architectures currently in use. It’s a great resource that clearly gets the point across for each item in the top 10, whilst being a short enough read to be a good refresher for those unfamiliar with the information. 

Personally, I found this to be the perfect article for me to quickly learn more software architecture patterns. It doesn’t go too deep into the software jargon and terminology that only an experienced professional would know, yet it still talks to you in a way that assumes you are an educated yet learning individual. I really liked the formatting of the top 10 list, as it gave organization, purpose, and distinction to each of the items. I learned many other types of architecture, and specifically what to consider when selecting a software architecture pattern for your project/team. This is probably the most important part, as choosing an incompatible pattern for your needs could set you back even further than you were before. I hope to apply this to future jobs where I can contribute to the selection of an architecture based on this knowledge.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

UML Diagrams: Use-Case, Activity, and Deployment

Link to blog: https://developer.ibm.com/articles/an-introduction-to-uml/

To start off the new semester and new course, we’ve been learning, discussing, and practicing with UML diagrams, or Unified Modeling Language diagrams. These diagrams are great ways for software developers and companies to visualize the structure of programs, large or small. There are many different types of diagrams, and we’ve mainly covered Class Diagrams and Sequence diagrams. 

Although I am unsure about the popularity and usage of UML diagrams in professional environments, I believe they can be beneficial to the organization and cleanliness of a team’s code, for it is to be written after it has already been structured and designed. The article I chose today is one by Donald Bell on IBM, and it discusses a few types of UML diagrams with some background information on each.

Bell introduces a new topic to the audience as well as anyone should: with some background information. He states the creation of UML was to model computer applications and ensure that anyone who understands UML diagrams can efficiently, accurately, and productively contribute to the project. 

The first UML diagram covered is the Use-Case diagram. Such diagrams are utilized to help readers understand the interaction between the program and its users. There can be many Use-Case diagrams for one program, but they are more so used to highlight the essentials. Bell describes how to create this type of diagram so that it is easy to understand.

The second UML diagram covered is the Activity Diagram, which shows “the procedural flow of control between two or more class objects while processing an activity” (Bell). Bell believes the best-case scenario for this type of diagram is for more business-oriented visualizations, such as how a company wants to operate at a higher level. These types of diagrams are not as technical as other diagrams which makes it easier to understand for non-programmers (Bell).

The last UML diagram Bell covers is the Deployment Diagram, which shows the physical representation of a software system. This would mean user computers, databases, websites, etc.

I selected this article because it covers a few UML diagrams that we haven’t discussed in class, and it is important for software developers to have some UML proficiency.  This would be a beneficial skill to have at a new job, so you might understand the codebase faster. IBM is also a very credible company in the software industry which is why I chose an article from their website.

The content of the resource was presented in an understandable way for someone with a little bit of software knowledge. I enjoyed learning about the background of UML and its creation, along with the three types of UML diagrams that were listed and described. I hope to use such knowledge at a new job that may use UML diagrams so I could provide more productivity in a shorter time rather than taking too much time trying to understand the codebase.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

CS-343 Introduction

Welcome back to my blog for this semester! My name is Josh, and I will be discussing Software Development topics related to the construction, design, and other elements of software. Hope you enjoy!

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

The Importance of Security Testing

Link to blog: https://www.computer.org/publications/tech-news/trends/application-security-testing

The whole semester we have been exploring various ways of testing code, namely styles that ensure the code works as it should. However, there is another aspect of testing we have not discussed yet; security testing. 

It is of the utmost importance to ensure that your software, database, website, etc. is safe from hackers and leaks. Security testing would help just that: making sure your system is unbreakable, or at the very least mostly protected from vulnerabilities and flaws. I think it is important to learn about this aspect of testing, which is how I came across Adam Stead’s article What is Security Testing? How to Check The Security Strength of Your Application.

Stead stresses the importance of security in software and also lists some important security testing techniques, such as vulnerability testing, black box testing, penetration testing, and more. There are many benefits of security testing besides identifying vulnerabilities. Some examples listed by Stead include protecting sensitive data, enhancing customer trust, and cost-effectiveness. Data leaks have been pretty common as of the past several years and it is a huge deal for those companies to lose their customers’ trust and their own reputation. With increased security comes increased trust, which is beneficial to both the business and the customer. 

Stead mentions some security testing best practices, and reinforces the idea of starting early and prioritizing risks. Security testing early on in development can help prevent flaws in your code, and you should continue to test throughout production. Prioritizing risks ensures that your important flaws don’t go unnoticed, and you fix your biggest holes before fixing the smaller ones.

Stead ends the article by discussing some attributes of effective security testing (thoroughness, continuity, scalability, etc.) and stresses the importance of checking the security strength of your software regularly.

I selected this article because this is a topic we have not discussed much in class even though it is still a very important part of software testing. This article emphasizes the key elements of security testing and how important it is to include it as a part of your testing regime.

The content of the resource was very informative and understandable for someone who already has a bit of understanding of software testing. An interesting thing I learned was about fax online, which is a method that businesses use to securely send documents. I did somewhat enjoy the article, it was informative, however I wish it included some examples of certain testing types. I expect to apply my newfound security knowledge to future jobs and software practices.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.