While there were some issues along the way, I feel like the first sprint was a success in the end. I ended up doing three issues with one done, and two issues still having problems and needing to be saved for the next sprint. The links to all three issues can be found below. The first issue I completed was update or add all doc, licensing, lint config, .gitignore, and .gitattribute to General, and I found no issues, so it was pretty easy, and did not take that long. The second issue was updating the pipelines, where I thought I completed it, but there was still more to do, so it was saved for the next sprint. My final issue was the same as the first but for the API, and I managed to finish it, but it had a problem from the pipeline, and needed to be saved for the next sprint as well. This blog will go over my retrospective thoughts of the first sprint now that it is over.

Throughout the sprint, there were many things that worked well. One thing that worked well was how our team developed a genuine camaraderie, which is important when it comes to teamwork. You need to have trust in each other that you will get your work done, and trust that we are there to help each other, and I think our team has developed that. Another thing that worked well was our communication during class hours. During the time we were in class, our communication was great, and we really helped each other out with our problems. Later in the blog, I will mention how we should find time to do more of it after class hours. Having these positives after the first sprint is great, and it can only get better from here.

There were also some things that did not work well throughout the sprint. One thing that did not work well was our time management. Every task we did ended up taking one weight over what we predicted. I think this experience will help this, and it will improve for the next sprint, so it is not too big of an issue. Another thing that did not work well was how one member made a change in the name of an issue, and it confused everyone else. We should be more open to the whole team for any little change made next time. We can definitely improve on these issues for the next sprint.

For our team to improve, there are plenty of changes that we can make. One change is having more communication from Thursday to Tuesday, as it is a long break to have no meeting with the team. We are planning to fix this by finding some time between the days to meet for an hour and check up on each other’s progress. If we have an issue after class Thursday, we won’t need to wait until Tuesday’s meeting to look for a fix, and waste all of the time that is precious in a sprint. Another change we can make to improve as a team is our experience. In the first sprint, we had no experience with sprints before, and it led to our issues. Now that we have the first sprint as experience, I think that will improve our team to better prepare for the next.

There are also many things that I could change to improve individually as well. One huge thing I could change to improve is my knowledge of VSCode and Docker. In the beginning of the sprint, I was having many troubles with the simple parts of VSCode and Docker, as I had not used it since Fall 2021. It got better throughout the sprint, and I am feeling more confident in my abilities now as we start the second sprint. Another change I could make to improve is to more quickly admit when I need help. There were many times during the sprint where I delayed asking for help, so I could try to fix the issues by myself. I think if I tried to come to everyone faster, it could have freed more time to worry about other issues. I think with the experience from the first sprint, I will be better with this in the next sprint. This first sprint started off a little rocky with inexperience showing up, but it ended with the whole team confidently looking ahead to what is next.

Issue Links

1. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/96
2. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/98
3. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/issues/8 

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

This was my first instance of using and being a part of the scrum workflow. Even though I knew how scrum worked from learning it in a previous class, I was still shocked at how enjoyable and manageable the scrum workflow process was. Our group was assigned the InventorySystem component of Thea’s Pantry. For this sprint, I focused on the CheckInventoryFrontend part of the InventorySystem. Our group did a sprint pre-planning, and we created issues for the “Convert all InventorySystem projects to new project structure” epic. I first made a sub-epic, made each bullet point its own issue, and then linked those issues to CheckInventoryFrontend (Link: https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/-/epics/29). I will now go into more detail about what I have accomplished during the sprint. 

Evidence of Activity

Issue #1: Update devcontainer files

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/merge_requests/10/diffs#6e656a06857650151f28f253233ed97584044098

For this issue, both the devcontainer.json and Dockerfile files in the .devcontainer folder were compared and updated to match the same files in the GuestInfoFrontend.

Issue #2: Update Pipeline/CI files

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/merge_requests/9/diffs

For this issue, the .gitlab-ci.yml file, the Dockerfile, package.json, and Header.vue found in ./src were updated to match the already updated and working pipeline found in the GuestInfoFrontend.

Issue #3: All documentation, licensing, linting configuration, .gitignore, .gitattributes files must be updated or added

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/merge_requests/7/diffs

In this issue, docs/developer and linting files were added, and the .gitattributes file was updated.

Issue #4: Revise directory structure:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/merge_requests/8/diffs

For this issue, bin was renamed to commands, files were moved from the top level into src, new commands such as build.sh were added, and some files and folders were deleted to match the GuestInfoFrontend.

I reviewed, approved, and merged the following issues:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/merge_requests/10

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/merge_requests/9

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/merge_requests/17

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/merge_requests/18

What worked well?

Working as a team went really smoothly during this sprint. Our team had three frontends that were very similar, so once one person who was working on a frontend was able to figure out how to solve an issue, they would be able to help the other members working on frontends. Communication between team members was also great. When one member needed help, myself and other members would communicate over discord to discuss and fix the issue.

What didn’t work well?

I feel like there wasn’t much that didn’t work well. Very rarely in class we would get off topic and start a conversation about something else like discussing what computer parts are good. That time could have been better spent working on the issues.

What changes could be made to improve as a team?

We split the work so that basically one person was assigned to a part of the InventorySystem. We could have picked up issues in other parts of the InventorySystem to diversify our knowledge on how the InventorySystem works as a whole.

What changes could be made to improve as an individual?

Changes that I could have made to improve as an individual would be to actively search for a solution to problems that may have arised. When updating the pipeline, the program was giving me an unknown error and the professor said that he would look into the problem. Instead of trying to solve the issue myself, I waited for the professor to figure it out. Instead, I should have been also trying to find the solution to the error.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

For sprint 1, I did insufficient work. The only changes that I ended up contributing are in this commit, which adds a Node script that runs an example unit test on GuestInfoBackend.

Before this class, I had not written any JavaScript unit tests, I was not aware of any testing frameworks for the language. I assumed that implementing simple unit tests would be trivial. I ended up spending a few hours learning how to use the mocha testing tool and chai assertion library. Because I needed to make HTTP requests, I spent the rest of the sprint trying to get chai-http working in order to do something similar to the previous testing implementation that I wasn’t aware of at the time.

Many projects will export an Express app as a node module. This makes it easy to use the same module both as a listening server and to serve requests by some parallel testing environment. Because we instead define our own entrypoint in src/index.js, I was gradually exploring how to define a second testing entrypoint when sprint 1 ended.

Many of the changes that both I and the team need to make for sprint 2 are circumstantial. We understood very little about many of the issues early in sprint 1. Some were small syntax changes, but others required quite a bit of domain knowledge. We’ve since developed enough of that knowledge. Especially now that we’ve agreed to delay significant front-end changes to sprint 3, we have most of the information needed to be confident we can address most of the sprint 2 issues.

Personally, I was much busier leading up to the end of February, and didn’t always reserve enough of my weekend time to work on issues, which obviously just need to change for sprints 2 & 3. I also was slow to bring my chai-http woes to our professor, when he could have shown me the branch with most of this work done for me.

One change that I’m interested in is finalizing a collection of changes before pulling a merge commit branch. Sometimes we may want to swap to another issue without committing to the current branch or using git stash, and sometimes it became clear we should have split an issue into multiple issues. For sprint 2, we’ve found a work-in-progress workflow where we instead work on a local branch, and then, after we’re ready to push code, create the merge request and set the remote to that remote merge request branch.

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/40: The documentation of the project needed to be updated for the Backend

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/41: The directory structure was outdated and needed to be revised for the Backend

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/42: The dev containers needed to be updated to reflect new settings and extensions for the Backend

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/43: The pipeline files needed to be adjusted to reflect new standard for the Backend

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/11: he dev containers needed to be updated to reflect new settings and extensions for the AddInventoryFrontend

Our team worked very well together. We were always in communication on when we needed help and what work we accomplished. The standup meetings were efficient which allowed us to jump straight into the work for the class. Whenever someone needed help with an issue, there was at least one team member available to help out and solve the issue. The way the epics were divided allowed everyone to pick a project that they were comfortable working in, and helping each other out allowed people to delve into different project types.

While everyone was working in a project they felt comfortable in, the way we structured the work didn’t allow us to really experience different project types. I focused on the backend for the entire sprint, so I did not gain much experience in working within any of the front ends or the API. This caused issues when someone asked for help, we didn’t necessarily have all of the answers to help them.

Overall, the team accomplished a lot during the sprint. We completed all of our work before the sprint ended, which gave us time to fix a few major issues we ran into completing the last few issues. For the next sprint, we should focus on spreading out the work through the different projects so that one person doesn’t just work with one project type. The whole team should be experiencing the different projects so that when an individual, even if they are not from our team, should be able to respond and help with the issue. This will also help for future careers, as when we get jobs in the real world we can say that we have experience working in all different types of environments. The different projects also contain different languages which will help with development.

Personally, I put a lot of effort towards my team and towards our work. Next sprint, I should consider spending more time at home doing work so that more of the epic can be completed. I was available most times to respond to my teammates and any other individuals who needed help, but my out of class time could have been spent better working on my own issues and completing them. Now that I am the scrum master for this sprint, I can work on my leadership skills as I did not really show them and use them effectively last sprint. Overall I feel I did well for the sprint, and I learned a lot to be able to enhance this current sprint.

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

Sprint 1 is now over and overall I believe my team and I did a good job for our first sprint. I think there are lots of things we did well but there is still plenty of room for improvement. 

The first thing our team did that I thought worked well was breaking up and weighing our epics. We took the larger epics like updating the documentation or revising the directories and split them up so each problem subgroup would have one. This worked well because each team member got to work on a piece of each epic which gave a good experience to everyone. Everyone working on similar issues was also good because when one or more of us ran into a problem the others were able to help or the team members working on frontends were able to tackle a problem together since what we had to do for this sprint was very similar. Our weights for the issues were also a pretty good estimate. We were able to get the full 35 points of work done right in time for the end of the sprint. 

Something our team can do to improve for the next sprint is to spread out the work better. In this sprint, we mostly worked in a single subgroup but I think switching things up would benefit us. Since we only worked in a single subgroup only three of our group members got to work on the frontend, one person got to work on the backend, and the last member only worked on API. For our next sprint, we want to switch these roles so every team member can get experience in each area. 

I worked on the CheckOutGuestFrontend as well as reviewed and merged code from other team members. The issues I worked on are the following:

The first issue I had was to update or add the files for the documentation, licensing, linting configuration, .gitignore, and .gitattributes to match the inventoryAPI. 

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/13

The next issue I worked on was revising the directory structure to match the inventoryAPI again.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/14

I then worked on updating the devcontainer files to match the inventoryAPI.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/15

The last issue and the most difficult one I worked on was updating the pipeline/CI files.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/16

A change I could make to improve as an individual is spending a little more time outside of class working on issues when I get stuck instead of waiting for the next class to ask about the problem. Some issues need more direct help to figure out but I think spending more time trying to figure out an issue instead of asking for help after a short time would be good for improving my problem-solving skills. I think another individual issue that can be improved is getting over the fear of completely breaking the code since I am unfamiliar with how certain things work. Sprint 2 seems like the work will be less trying to match the code up to already existing code so having to dedicate more time outside of class will be necessary. 

Overall I think sprint 1 was very successful but there is always room for growth. By doing the changes the team discussed I think sprint 2 will be even more successful.

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

Sprint 1 of working on the LibreFoodPantry was a nice dip in the water of how the scrum framework works. So far, I understand why this framework is very important to the software development process and the added organization it brings when it comes to producing software.

The first thing I worked on in sprint 1 is “added use-strict to the backend” (Link 1). Before working on this issue, it was important for me to understand what “use-strict” was used for. I found out that the “use strict”; line is used to define that the JavaScript code is in “strict mode.” When JavaScript code is executed in “strict mode,” it means that non-existing properties, variables, and objects will throw an error. This was very simple, and it didn’t take too much time to understand the issue and how to resolve it.

Another issue I worked on was “removing the MongoID schema in the GuestInfoBackend” (Link 2). This was also very easy; it consisted of changing the OpenApi.yaml, which included a MongoID schema. The MongoID is unused in the GuestInfoSystem; thus, it must be removed. The biggest problem was merge conflicts. One team member had made a change in the OpenApi.yaml file in the backend in one branch while I was making a change to the YAML file in another branch, and Git didn’t like this. In the future, I think it’s important for us to recognize when issues will show a merge conflict; it’s important to understand them too. I spent some time figuring it out, but then I ended up watching this video on YouTube that perfectly explained the point of merge conflicts. Anyways, I will be able to resolve this better in the future.

The third issue was to “create docker-compose.yaml for the guestinfointegration” (Link 3). I’ve never worked with Docker, so this was a big task for me. I had to attempt to understand Docker the best I could. When I try to read over documentation of another system, I tend to get very frustrated because I’m only left with questions. I think the best thing to do when it comes to this is to take it slow and grasp all the information that makes sense at the moment, then take it from there. Also, it’s best to ask a lot of questions whenever possible. I tend to try and figure things out on my own when I don’t really need to. I have all these resources and people I can go to, and I’m not capitalizing. Despite this, I learned a lot about Docker, and I will definitely come back to it whenever I need to.

The final issue I worked on before ending the Sprint was “Configure guestinfoIntegration” (Link 4). When going into this issue, I didn’t know exactly what the guestinfoIntegration was used for, but from my understanding, it is used as a mock repository showing how the GuestinfoSystem works. Configuring the file wasn’t hard; the only thing I had trouble with was understanding that the Integrations had no build image, thus no build meant that I needed to change the Git testing pipeline. It seems like I should invest more time into looking at the resources that have been presented in the LibreFoodPantry common services. I spent a lot of time getting the pipeline to work, which is good because now I have a better knowledge of how it all works. My concerns are that I take a significant amount of time on issues that can easily be resolved, so it’s my job to look at all my options before scrambling for a solution.

As an individual, I spent a considerable amount of time working on these issues and learned a lot about certain aspects of the project. I want to be able to better organize my findings and solutions in the next sprint. I also want to get a significant amount done between classes. This means setting deadlines so that I’ll have one issue done between each class.

Regarding the team, we have decided that we need to better space out our issues so that no one is doing too much and spending a lot of time on a certain issues, as this could be a problem for productivity. We have also decided that we need to capitalize on local branches before merging, which could help when it comes to merge conflicts. Heading into Sprint 2, maximizing our productivity is the goal.

Link 1: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/59

Link 2: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/60

Link 3: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfointegration/-/merge_requests/3

Link 4: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfointegration/-/issues/2

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Sprint 1 has come to an end, and it’s time for the sprint retrospective. For the first sprint of this semester, I worked on issues for AddInventoryFrontend for the Inventory System. The following are links showing my activity for the project:

• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/9. This addressed the creation of developer documentation that was not previously present in AddInventoryFrontend but is present in GuestInfoFrontend, and I made sure that it had the licensing files, and added the linting files, and edited the .gitattributes file.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/10. This addressed the revision of the directory structure in which I compared files in AddInventoryFrontend to GuestInfoFrontend and created any files that GuestInfoFrontend had that AddInvenoryFrontend did not have and renamed and relocated files, or created folders to match GuestInfoFrontend.
• https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/12. This addressed the updating of the pipeline/CI files in which I updated the package.json and .gitlab-ci.yml files.

I have also reviewed a merge request from a teammate in which I checked if they created the necessary files with content similar to GuestInfoAPI: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryapi/-/merge_requests/5 

What worked well with the group is that we all separately worked on the same type of issue. If one member had difficulties with the issue, then another member who figured it out would be able to guide them. For example, we all worked on updating pipeline/CI files and there were some cases where a few people working in frontend had the same errors like issues with using commads/build.sh and were able to work it out with each other. We also had great team communication and were able to freely communicate what we were stuck on or working on, and could easily reach each other outside of class. 

We cooperated well as a group and didn’t seem to have any issues. We had just technical issues rather than teamwork or workload issues. Even then, we did help each other out and I took note of what we may need to remember moving on. When I was stuck facing some errors on an issue, a teammate helped by picking up an issue for AddInventoryFrontend that I was too preoccupied to handle.

To improve as a team, we could work more on projects at home and also try to branch out more. We sort of stuck to our own projects–for example, I handled most of the issues for AddInventoryFrontend, one person worked on InventoryAPI, one for CheckInventoryFrontend, one for CheckOutGuestFrontend, and one for InventoryBackend. It might be more fair to work on different areas for people who ended up working on an area they didn’t want to work with.

In terms of improving as an individual, I could put more time outside of class into my issues–but of course this would happen naturally since this next sprint would have more “intensive” work rather than some copy-pasting situations we had for issues this sprint. I should also be less afraid to make some changes thinking it could mess something up.

I think this first sprint went well with our communication and team support system.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

This blog post is about the sprint 1 retrospective. This is our first sprint as a third group in the Cs-448 class. The topic of the project that we will be working on, which was presented to us as a team is about LibreFood Pantry AWS Deployment. In the first moment, the professor sent an email as a beginning to present us that what group we would be in, who would be the members of our group, and most importantly what would be the project we would work on. That was our first familiarization with our team members. Working as a group for one project, I took it as a very positive thing. I really like when I share ideas with other people about a specific topic, and I also like when I take ideas from others from where I can learn too.

The first thing we as a team did, was that we first created the issues. After that, we shared the roles on what we will be working on. We had very good communication as a team and we also were really clear about the project. The issues I worked on were the Deployment Option for EKS and the other issue was research I did about the Microservices Architecture.

These were the two issues I worked on. In the first issue I had about deploying options for EKS, I tried to give some tips about deploying applications Amazon EKS in the cloud, also I tried to determine which deployment options for EKS we should be using. For my second issue, I mostly did research on what is Microservice Architecture, when, and how to use it, and most importantly the benefits that microservices have.

Working as a team on one project like this, looked like a little challenge thing for me. But at the same time, it helped me improve my acknowledgments. We as a team on this first sprint tried to share ideas, and give our contributions regarding the issues that we created. We had some struggles mabey in the first days we started working on the issues, but got the point. And I think that overall we have done a very good job as a team. We also tried to find other communication ways, like writing for any question or suggestion through discord, and also we have met each other virtually through zoom meetings. These helped us a lot as a team too. And hope that all other sprints will work better than we start.

The issues I worked on:

Deployment Option for EKS: https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/15

Research Microservices architecture: https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/14

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

At the beginning of the sprint a general overview was collectively made by the group and some confusion over the scope of work completed so far occurred. We were expecting a majority of our work to be code refactoring but at the time it was noticed that there was no actual operating code to refactor really, and our collective effort was directed at simpler cleanup tasks.

During the first sprint I assigned myself to two tasks created by Sebastian:

1^st https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/61

2^nd https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/2

The first task was creating landing pages for to later connect to the second task which was assigning href links to those landing pages.

I specifically chose these as I have never worked with html except for one occasion earlier in my youth during high school. I felt like this was a good opportunity for learning html and getting familiar with it as it is something I should know how to work with on at least a basic level. The majority of my time was spent on learning how to code in html and dealing with what I considered to be how weird it handles spacing and formatting.

My general experience with learning html did not go as well as I hoped. As with learning anything new the tricks of the trade generally do not surface early on and instead are buried deeper in more specific tutorials.

I generally struggled with spacing and formatting and in specific aligning a couple text boxes until my fellow team member Kurt off the top of his head mentioned that you could add spacing and tabs with specific code that made the pages look slightly more organized. He also told me about CSS and I spent some time learning about that and bootstrapping to find an easier way to automate the formatting of the landing pages.

Now I could have originally finished the landing pages and connecting them to the main landing page, but I had decided that without a more complete formatting style and still uncertain as to the future of those landing pages (the way the users will be directed to these pages depends on the Keycloak and Kubernetes systems being developed by the other teams and might require a complete design change to those landing pages), I chose not to finish the landing pages during the first sprint.

The second issue relates to a far simpler task that seemed a bit more difficult at the time but as I discovered it was far simpler. At the start it seemed like I might have to create other structures in the other front ends for linking together all the landing pages. Luckily after looking over the code it seemed to me that all I would need to do to link the landing pages together would be through the one hub located in the header.vue in the addinventory front end. It is the one point that has the href linking to the other front ends and I’ll be likely directing the landing pages from this point. Ultimately again it wasn’t implemented as the formatting was not completed for the landing pages. Overall I spent far too much time kind of randomly learning html and felt like I needed to find a more organized path to learning html. I also am expecting during the next sprint to have a far more coherent style and to format it based on Worcester States’s general website formatting and color scheme, as well as actually creating the pages and linking them together to finish these two issues

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.