Sprint #2 Retrospective Blog Post

The second sprint of the semester started a bit rough for me with my surgery, but I was able to get most (if not all) of my work done throughout the weeks we worked. I was able to help a lot with creating the cards and giving them descriptions at the start, and then the first week or so of the sprint I was very busy. After this initial period, I was able to catch up on my work and get a lot done. I was primarily in charge of getting an updated example of our front end based on an old one that was provided to us from previous years. For this, I used google forms, but in the end I had to take screen shots of all my work and upload those in case the forms document that I created got deleted or lost. This will be helpful for our team and for any students working on this project in the future. There is still a bit of work I need to do on this example to make it perfect for what we want, but this has been added as a small task for me to complete in the next sprint. Overall, our entire team did very well getting a lot done, and although I did not get the backend coding assigned to me, I was able to lend my insight and some advice and code to my teammates. This sprint was a lot different than our previous sprint primarily because it had less to do with learning how to use cards and work in a sprint and had more to do with getting real work done to further our progress on this project. I presume that the next sprint will be even more important, and we will have a lot of hard work to do to try to complete all or most of our cards. Some things that worked well this sprint were our team’s hard work ethic for getting everything done and our ability to communicate well and let each other know what needs to get done and what we need help with. For this sprint, we actually added a member because of the IAmSystem team splitting up after the first sprint. This was not a problem at all and in fact was more helpful because we were able to get even more cards completed over the couple of weeks we had to work. If I were to change anything or expect anything more from the next print, it would be that I personally will be able to get a lot more work done earlier in the sprint without having a surgery as a distraction. I am excited to see how far we can get on this project by the conclusion of this semester, and hopefully we will be able to get a nice looking and working project by the end. This whole experience has been great for me so far for learning how to work in groups for sprints, and I know that after college I will run into many projects where I have to work like this.

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Erockwood Post #1

In my operating systems class, we are learning about all of the important roles the operating system has in a computer. There are many managers that the operating system itself manages to keep everything running as smoothly as possible. One thing I am most interested in when thinking about operating systems is concurrency and multithreading. Most tasks are done serially, which is to say one at a time. This worked well back in the day when most computers had only one or two cores. Nowadays, however, CPUs usually have 4+ cores, and if all tasks an operating system does are serial, then 3/4 of the CPUs resources are not being utilized. This is where concurrency / parallelism / multithreading comes into play. With them, we allow programs/tasks to run simultaneously, using more than one CPU core, to do more work in less time.

The only problem with this is trying to write the programs/tasks to take advantage of more cores. I know when I first tried to create and run a simple C program that would use more than one core, it was very confusing on trying to have everything be worked on by a separate thread. Eventually, after some trial and error, I got it working, and it slowly started to make sense on how to write this type of program. In doing some very simple calculations like I was trying to do in my example program, there is not much performance to be gained from multithreading the program, but in much bigger programs with bigger calculations to be done, there is definitely some time that can be saved by multithreading the process.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

Learn How You Fail

Failing is unavoidable and it happens to everyone at some point. In reality, anyone who has never failed at anything has either stopped challenging themselves or learnt to ignore their own mistakes.

Your skills are progressing but you are still failing and have some remaining weaknesses. So instead of drowning in a sea of self-pity over previous failures, develop some self-awareness of your own patterns, habits, behaviors, and other factors that play a role in causing you to fail. When you are aware of yourself and the things that mess you up, you give yourself the option of either trying to solve the issues or cut your losses. You cannot succeed in all, and recognizing your shortcomings is critical because it allows you to actively recognize distractions and concentrate on your goals.

Accept that there will be certain stuff you aren’t very good at.

Once you learn to accept your failures you can set realistic limitations on your goals.

Often times I get irritated by the fact I keep failing, but if I accept it, my failures become learning opportunities. I can then seek out guidance and learn new skills from someone who knows more about code than I do. It is hard, honest work to admit your shortcomings and it will take a lot of failures, but I am confident that eventually, it will all be worth the frustration.

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/6

(Read over/review UpdateGuestInfo for frontend): In the comments, there is detail on how to frontend will function for a guest info update. In case of a new guest or old guest, the ID will be entered first and then the guest will be accessed if they exist.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/community/-/issues/35

(Implement components/schemas to be used in backend endpoints): Updates were made to the OpenAPI.yaml file. These included new responses, corrections to schemas, and corrections to endpoints.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/backend/-/issues/2

(Implement API for backend endpoints in Node): The title is self-explanatory here; I implemented the GET route while David implemented the PUT route, as well as updating all the example files to fit GuestInfoSystem rather than items for InventorySystem. My chages occurred in endpoints.js and guest.js

As far as our timing within the sprint, we did much better this time than last time. We made use of due dates and stuck to them, even if refactoring was necessary afterwards. Our goal was getting working backend code up and shared with the group. From here, everyone was able to be on the same page in a timely manner. We also made better use of communication within GitLab, mainly in the cards and via merge requests. This way, even if Alex, Tim, or Cam was not working on the backend, they would still be able to see the code and understand how it functioned.

            We still have some significant improvements to be made as a team, though. Even though everything was made more public through cards and merges during this sprint, getting everyone on the same page insofar as how the project as a whole was functioning seemed to be lacking at times. This definitely slows down progress as there was separation between the backend development (what I was mainly contributing to with a great, great deal of contributions from David) and EventSystem and KeyCloak development. I’m still not sure if everyone is grasping how deployment of the system is working with Docker. We still need to be communicating and collaborating more than we are currently, as well as asking more questions if everyone is not in synch. This leads to some ambiguity on division of labor as well. We tend to be working linearly (with some people waiting to work on their part) instead of in parallel. This is where communication needs to be better, as well as planning.

            As a team, we should be communicating better during our time in class. I think I had the assumption that everyone was on the same page when no questions were being asked, which I don’t think was necessarily the case. This would help the pace at which we worked for sure. There is little progress to be made without a thorough understanding of the system. Coming up on our last sprint, there is no time to waste. I would hope no one feels uncomfortable asking questions though; as Apprenticeship Patterns states, expose your ignorance. And perhaps it’s just a lack of articulation in our cards. We have been better in using our cards, but I’m sure they could still benefit from more detail.

            I think I should be better in organizing with members from other teams, especially for the frontend. I wasn’t sure how the backend would be working, so I put off frontend development in favor of the backend. I definitely feel comfortable with that now, but I also feel kind of behind on the frontend. I expect this upcoming sprint to be exactly that: a somewhat hectic sprint. We have our work cut out for us, so focus is the name of the game. Organizing with members of other teams should be greatly beneficial, especially with my beginners Vue.js status. 3 minds are greater than one!

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Software Testing: Jacoco

For this week’s blog post I chose to focus on a topic that I had to research for an honors project, this being Jacoco. In case you are not familiar with it, Jacoco is a software tool that is used to test code coverage, which in short just involves checking how much of a system’s code is being tested. This may sound redundant if you, like myself, have only really been using tests on small scale projects, but as a program’s complexity increases so does the complexity of the tests required. Additionally you will have to write more and more tests, making it difficult to determine exactly what has been covered. Before anything else however, I am going to break down exactly how code coverage is checked.

Having not known about Jacoco at all, I found this article on Baeldung that was extremely useful in understanding how it worked. As I stated the essential idea is to check code coverage, which consists of line and branch coverage. Line coverage essentially means Jacoco will check how many lines of code are being executed during tests to determine which are actually being tested. Branch coverages is similar to this, but focuses on checking the logical splits in the program, such as conditionals like if statements. The total amount of branches present is then compared to the amount that were covered to give the results. There is one more aspect of a program Jacoco checks for, being cyclomatic complexity. This is essentially a measure of the logical complexity of the program, or how many branches the program has. Now that we know what Jacoco is we can discuss why you might want to use it.

This testing tool certainly has some major benefits for anyone working on a large system. If you are working on writing tests for a system, it may begin as something straightforward, but as the system grows it will become increasingly hard to track exactly what components are being tested. This is where Jacoco comes in, allowing you to see exactly what lines, or just classes, are being tested so you can ensure there is sufficient test coverage. Additionally it can show you the degree of logical complexity present in the system, which could then be adjusted accordingly. One point to keep in mind that is mention in this article is that you should not get tunnel vision when trying to increase code coverage. High code coverage does not necessarily mean the tests being run are adequately testing the system. It is more important to focus on writing a few functional tests for each component rather than just having a plethora of tests that do not really do much of value. This article discusses Jacoco in more detail than I can so if this interests you I would recommend checking it out!

Source:

https://www.baeldung.com/jacoco

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Photo by Kaique Rocha on Pexels.com

During our second sprint for the InventorySystem project, we focused primarily on getting basic “skeleton” systems in-place. By this I mean that we tried to get simpler versions of each of our components working so that they could be used as a baseline for future development. The frontend, backend, database and IAM (Identity & Access Management) systems were focused on primarily throughout this period of work.

I would say that we likely had a proper amount of work planned for development, during this sprint our team was actually bigger, so it was a great help to have more people around to work on development tasks. Because of the larger team, we were able to split-off and each focus on a specific area of the project more effectively.

Two people focused on the frontend (one person worked on one of three necessary frontends each) since there was the project requires multiple front-end interfaces to function. One person focused on the IAM system specifically, and one person focused on the backend system initially. As the sprint progressed, everyone generally was able to complete the majority of necessary tasks, and the project went from having lots of documentation with little working code/examples to having a collection of basic interfaces and systems.

One difficulty I faced specifically was in trying to decide on the appearance & layout of the frontend I worked on during the sprint. Because the preexisting site for the food pantry exists only as a page on the main WSU website, I didn’t have much to go off-of for design besides the general color choices and logo design provided by the university. Something which I found helpful was to organize a meeting with the other teams working on the project, and to ask some questions regarding their process and design choices for their own front-ends. Additionally I was able to get some good advice and feedback from others on my own team based on the development of their frontend components for the project.

I think that having more team members definitely helped our team to be more productive, the process of “splitting-up” tasks worked a lot better this time around because of it. Previously the idea of each person “specializing” seemed harder to achieve, as despite the benefits of distributing the work, there were less people overall, and focusing on one thing meant that other areas would lose out on development focus. Now having a bigger team we were able to use this to our advantage and distribute work more effectively throughout the sprint.

In terms of communication, we used GitLab throughout this sprint to coordinate our efforts, and it seemed like everyone was more used to the process of creating issues and communicating concerns/ideas regarding those issues throughout development. Here: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/36 is one of the issues I worked on, and generally I tried to include things like screenshots of the work I was doing, links to the repository for any code or examples I had worked on, and descriptions included in the comments regarding the process and anything I might have concerns about. Other team members used Gitlab similarly, posting links to relevant resources which could be helpful to others, linking to their work/posting screenshots and describing any difficulties or issues they ran into. Overall I think it has been an excellent tool for organizing our work for the project, as a place to discuss problems related to it, and as a major source of reference.

Conclusively, I think that this sprint went well, and we were able to get some good progress in over the course of ~5 weeks or so. The increase in the size of our team, being used to the process of using Gitlab for coordination, and overall focus on creating “useable” mock-up and skeleton framework code seemed to allow for increased productivity during the sprint.

From the blog CS@Worcester – CodeRoad by toomeymatt1515 and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Backend Example: https://gitlab.com/LibreFoodPantry/training/spikeathons/winter-2021/stoney-manage-items/backend

For the second spring, our team focused on developing the frontends, backend, and keycloak of the inventory system. But a big problem the team encountered during the sprint is that to develop the inventory system, we had to learn all this new material such as Vue.js, Express, and API. Even though I was introduced to these concepts last semester, it’s still comparatively new next to all the time in college where I used Java and C++. And even though we had the entire first sprint to get familiar with the material, actually applying it to a project is a bit more difficult. It caused the progress on development to lag and a decent chunk of what was planned for the sprint didn’t get finished, like writing the API for example which was my responsibility and I’ll get to that later.

I worked on developing the backend and event system components for the inventory system during the second sprint. For the event system, I met up a couple times with the team members working on the event system from other teams. We talked about how our systems were going to communicate with each other to the point I at the very least know what to implement on my side. The inventory system just has to send messages to the reporting system whenever the inventory goes up or down and it will do that through a JavaScript file called “send.js”. I also managed to create a base skeleton for the backend which is heavily based on an existing example which I’ve linked above. I also tried to write the API but I didn’t really manage to finish it well enough and even though I did work with APIs last semester, it’s been a while. I feel that the biggest reason for the unfinished API is because I didn’t even study API during sprint one, I mainly studied express. All of these tasks most of what I did during sprint two outside of a few miscellaneous things that don’t come to mind immediately.

On what to improve as a team, I can’t really think of much outside of trying to keep up with the new material because I feel a good portion of the class is dealing with the same problem. I feel that the inventory team is doing decently all thing considering. As an individual I could improve on my knowledge of API and some other subjects by using the inventory system wiki more. I could also try and free up more time to work on the system since I planned to work on the API some more and I barely got anything done since I had a test last Friday and I have another test this coming Tuesday. I might have time on Tuesday afternoon or Wednesday but I also have other classes that I have to keep up with and I should also set a concrete goal or write a to do list to guide myself. I just came up with that and it sounds like a good idea so I’ll stick to that plan.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

Study the Classics

            In the “Study the Classics” learning pattern of the Apprenticeship Patterns book, the focus is on catching up with the well-known literature or practices in the field when your knowledge of theory is more limited. Luckily, I feel as though Worcester State has prepared me well with a mix of theory and practical, technical skill, but this pattern stood out to me, nonetheless. Sometimes, when talking with peers or reading online from people more experienced than I am, I find I can get bogged down in references to things I have no knowledge of. This usually detracts from what I was initially trying to find out about. There’s more than enough “good” material out there for many, many lifetimes worth of learning. What concerns me is finding the right material and learning about it in the best path. Even if I can find all the proper materials for my learning goals, working through it can be difficult or impossible if I don’t go about it in the correct way.

            As the pattern mentions, exposing your ignorance is as essential part of opening yourself up to learning. This is something I don’t think I really have a problem with, as I usually try to put my ego to the side when taking on new tasks. What I really need to start doing is also mentioned in the pattern: keep a reading list and read constantly. I’m not great on this front. Perhaps these are particularly difficult tasks for college students because most of our work comes outside of our courses anyways, but I could definitely stand to try more, especially once I’m out of college.

            I also find difficulty in using the classics to inspire more current learning. I do feel confident applying my knowledge to new topics (I feel confident that my knowledge is translatable) but discerning the relevant material from the outdated in the first place can be difficult. This is a very handy skill and I think it probably comes with an expanded knowledge base anyways. As long as I get on the road of continued learning and studying the classics, I think this skill should develop.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Learning Languages

I am once again impressed with the relevance of these patterns, covering many issues that I have been struggling with recently. For this week I chose to focus on the Your First Language pattern. This might sound strange, as I am a senior and at the end of a pretty significant part of my journey as a software engineer, and yet I feel as though I have yet to become an expert on any particular aspect of programming. In terms of programming languages, I have found myself vaguely utilizing many without fully understanding how they work. This is exactly the issue discussed in the pattern.

This pattern focuses on a few different tips for learning a new language well. After choosing a language to focus on this pattern advises you to focus on creating a useful feedback loop with whatever type of work you are doing. This can be through a variety of methods, being finding existing communities of practice online or someone you know who is an expert themselves. As for how to learn the language, there are a few different methods recommended. The overarching method is to have a specific problem to solve rather than just solving small examples present online and in books. I have often ran into this exact situation myself, finding my initial excitement in learning a new language stopped abruptly by some frustrating example problem that has little relevance to what I want to do with the language. Instead, what is recommended is to think of a larger problem you would like to solve with a program. Starting from this very general level try to break it down into smaller components and, after getting to the most basic component to work on, start from there.

Personally I once again had little to disagree with. I have realized that learning new languages seems to be a critical skill for software developers, as there is such a variety available. Each language generally has its own advantages and disadvantages, with some having specific use cases, like html for web design. Thus it is important to know how to go about successfully learning a new one,  as it is its own little road on your greater path to becoming a software developer.

Source:

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch02.html#your_first_language

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

It probably goes without saying, but this sprint certainly seemed more effective than the first. This is essentially a given, as a good portion of the first sprint consisted of figuring out how to work within my team in addition to adjusting to the teams shifting around a bit. After this, I feel as though we were able to accomplish everything we set out to, and a little more in some circumstances. Though this sprint certainly was not entirely bereft of some issues, at least with my own contributions to the team. Other than these though, I am satisfied with how this sprint went.

After adjusting to being embedded into the InventorySystem team, the sprint went very smoothly. Initially I had some difficulties being in a community of practice and the team, not really knowing if I should be meeting with others from my COP. We ended up establishing some meeting times and help each other with some parts of Keycloak. We were able to find a method of connecting our mock frontend app to keycloak, in addition to developing a logout function. Additionally, both Keycloak and the mock frontend app were containerized in docker. These were the major issues that I had focused on this sprint and all were effectively completed. Beyond myself, the InventorySystem seemed to accomplish many of the issues, with the exception of maybe one or two, that were posted for this sprint. One part that I felt did not go entirely well was how exactly I could help out the InventorySystem team. It might have just been the nature of the issues I had involving just using Keycloak, but I was concerned that I could have been helping them more in some way. Other than this there were no real issues that I could think of.

Despite the overall success of this sprint, there are a few more thing that I personally feel could change to improve the next sprint. I should clarify that these changes are entirely with myself, the first of which being what I felt was my own lack of participation in the InventoryTeam’s issues. I did not feel like I involved myself enough, this is also the reason why I cannot really speak on how the team can improve. As for changes I can make, I will simply try to involve myself a bit more, if not through taking up some of their issues then just through communicating more. I will try and ask where they are at throughout the sprint so I am more aware of what is happening and, ultimately, when I will be implementing Keycloak into the system. Additionally, I still had some struggles balancing my work for this class with some others, but I have been working on improving this for the next sprint. I have been sticking to the time I have set aside for working on schoolwork and have, at least, kept up. In conclusion, I am very pleased with my current progress going into sprint 3 and am excited to finally finish implementing Keycloak into a system!

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.