Category Archives: Sprint 2

Sprint 2 Retrospective

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem

Here is the Link to the repositories that contains everything we worked on Sprint-2. Backend, Frontend, Event system, and Keycloak.

RabbitMQ Docker container:  Created a Docker container for Reporting Team

Learn how to get messages from Queue:  Learned How to send and receive messages using JSON object

Meeting with other Event System Team:  Met with the other teams to discuss the format and schema

Review CSS and HTML:  Reviewed CSS and HTML for the Frontend design.

Work with Backend/Database for MQ: Worked with Database and Backend to figure out the Receive file.

For the Sprint, I worked mostly on the Event System components with the Backend person. We figured out how to properly send and receive messages using the JSON object.

What worked well / did not work well

For the Sprint, I worked mostly on the Event System components with the Backend person. We figured out how to properly send and receive messages using the JSON object. I noticed that working together with the team has improved our work productivity significantly and working together helped us to solve problems as a team. For this Sprint there were still a lot of confusing elements. Especially, we had a hard time understanding how the report worked and what the data was involved in the report. Also, the issue description on Gitlab was not precise enough or was not broken down into steps. We were lost in some aspects and did not know what questions to ask. However, it is almost the end of the semester and everyone is busy with exams and project from other classes

What changes could be made to improve as a team?

As a team, we should be communicating more with each other and the professor whenever there is confusion or questions regarding the materials. Also, breaking down the task into small issues will help the team tackle problems one by one. I think it will be great for our team to talk with the other group for example all the FrontEnd people can meet and talk more about the issues and problems they are facing. The same goes for the backend, this will help improve as a team. We also need to add more info to the cards which solve the issue of any confusion regarding who is doing what task.

 What changes could be made to improve as an Individual?

As an Individual, I should be talking with my team more rather than just doing the issues that are assigned to me. If I am struggling with something, then I should ask my teammate or the professor for help rather than just waiting and trying to figure out myself. Since it towards the end of the semester and since every class, I have a project, I should be planning or a schedule to work on individual tasks rather than doing everything at once.

Overall, this was a great learning experience. I think the second sprint was a success and we got a lot of working parts done for the project. I’m looking forward to seeing what the reporting team will accomplish towards the end of the semester.

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective II – Reporting System

I am part of Reporting System group in this project and my job is to support and secure other system through keycloak. It is a 5-person team, and my part in this group is to implement a third-party system (KeyCloak), deploying the system (using docker) and help other system by embedding in their teams. Also help with other team tasks other than IAM system.

What I think that worked well in this sprint was that we were clear on what to read and what to look for. We understood the instructions and started the work that we thought it would be useful for us to know and learn. I was able to make some progress and secure the frontend of the system. Created a realm for the reporting team and added their users. This link is a good source for anyone who is new to Keycloak and wants to know how it works. There is information for everything you might need with keycloak.

https://www.keycloak.org/documentation

Again, like last sprint something that I would say it didn’t work well it was the amount of information we had to learn and go through. Because this is a project that is new to everyone, we were kind of lost in the beginning until we selected what worked for us and what not. It is risky when you are introduced with a new tool and you get lost in the sea of information. Again, overthinking some basic stuff that didn’t need a lot of time spending on it continued in this sprint too.

I think in this team I feel comfortable and able to communicate openly with my teammates. Most of the time we spent it working individually or in groups of 2-3. The examples that were provided to us for frontend and backend has helped us a lot in this second sprint. Also, when we assigned issues, we could have left it unsigned, as long as, all issues were done by the end of the sprint.

As an individual what I could have changed is helping my team more in other issues too and discuss the problems with my team.

In this second sprint we had enough issues for a team of 5 people. Most of the issues were about building frontend, backend, and figure it out how to make the reporting system work. Issues were mostly individual but also, we had ones that we developed in group. I was assigned to creating a docker container for keycloack and securing the example frontend through keycloack. I was able to finish both issues with success and the one that were in group too. Created a project file with all my documentation in GitLab with steps I followed, to complete the work I was assigned for.

We all wrote our descriptions on the issues, what we learned and how we are going to use it in the future. The link is provided in GitLab so anyone who comes after us or want to check on what we did, can use it, and help the others too.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/keycloak-configuartion

Read the readme.md file in the project to follow the instructions. Overall, this sprint was better than the first one and we got result. If the first one was trying to understand what was happening, this second sprint was more hands on the deck sprint, with real result and projects running.

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 2

Hello,

welcome back.

  In todays blog post I will be writing about my second sprint developing part of my universities food pantry website. My team recently finished the second sprint, during which we focused on developing basic skeleton code with basic functionality in place for future development. I and another teammate worked on the front-end development of the project while one classmate worked on the backend and another person worked on the IAM (Identity and Access Management) Communication among our group occurred mainly through GitLab and discord. At the beginning of the sprint, we mainly had documentation on the concepts we were to begin using and now we have progressed to having multiple branches of skeleton code developed.

During the first sprint, I had begun researching REST API and OPEN API with intentions on developing that area of the project. However, due to personal health reasons I was unavailable for slightly over two weeks and was not sure if a return to the project was possible. Due to these unforeseen setbacks, my team had to switch up task assignment. When I returned, another teammate was tasked with taking on the API design, which meant I was to take on the checkout guest front-end. This set me back even further than anticipated because now I had to switch to doing a completely different part of the development process. I began researching and completing tutorials on Vue.js which ended up being quite a bit to take on whilst trying to develop something presentable with Vue.js for the first time. I learned quite a bit and am happy with the progress I made as a student. I take pride in the development of the Checkout Guest front end thus far. It is linked below under the updatedFunctionality branch:

CheckoutGuest

For the second sprint, our team faced the challenge of applying the knowledge/concepts we gained earlier studying Express, Vue and keycloak and applying it. I was uncertain of how to approach the input validation of the student ID field but ended up modifying some code for an input field. I specifically spent some time verifying that the submit button was disabled unless an input of seven digits was entered. I assumed we would work with the WSU pattern of blue and yellow and designed in this way though I was uncertain of specific design layout and appearance that other teams planned to develop. A member of my team had contacted other teams with questions regarding appearance and then refactored according to the newly acquired information. A small hiccup with practical application is to be expected when developing with new frameworks but I still think we worked well despite the initial chaos of using these new frameworks, especially the combination of multiple frameworks.

To improve as a team, we should become more comfortable and fluid working with these new concepts and frameworks by continually practicing them daily in small increments rather than in large infrequent bursts of use. This would help to solidify these new concepts in our minds and keep them fresh. To improve as an individual, I would benefit from checking GitLab daily rather than a few times a week. This will help me to stay more on top of how the other members of my team are progressing and coordinate with them on challenges or setbacks either of us face before they become a major setback.

Overall, our team is doing quite well despite the setbacks. I am grateful to have the opportunity to work with such excellent developers who have great communication skills, are not afraid to ask questions. We work well as a team, and my teammates have been very cordial with any questions or comments about the design process outside of class hours. As someone who grew up dependent on food pantries like this one, I am honored to be able to dedicate my time to the development of this project.

Thanks for taking the time to stop by.

  • John Simolaris

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 Blog Post

This second sprint has been a bit better in terms of actionable steps; this was aided greatly by the mock front and back end. The mock allowed us to test configuring a realm to a container locally which was the floor for proof of concept. Unfortunately, the lack of architecture made further progress confusing as I didn’t understand why all images couldn’t be on same container network. After it was determined that the architecture called for further subdivision, it became unclear what microservices should be on which image and/or network. For instance, it was more or less determined that Keycloak should be on its own separate container (presumably with WildFly) but at the beginning of sprint I wrongly believed, based on previous internet searches, that NGINX should be on the same image as Keycloak but this was later discovered to be unnecessary as the mock front end contains NGINX within our system.

On that same note, the task breakdown and codification into issues for the respective boards suffers from an incongruity where ignorance of the matter begets ignorance in the approach and then future work is inaccurately reflected in the process. This isn’t necessarily an issue with the approach as whole but it seems as though, for the past two sprints, this unfamiliarity with the microservices and their implementation into our architecture forced me into a series of micro pivots which quickly evanesced away from the originally declared issues. If the goal of scrum is not to constantly be inundated with creating issue cards, updating them, and closing the now obsolete ones, then perhaps it would behoove us to reconsider the amount of research time necessary or have a much more closely-guided approach to issue construction. If this rapid pivoting away from cards is acceptable (and their grades reflect this) then that’s not particularly bad news for students. However, we have to be honest with ourselves and have the hard conversation that Scrum in this setting does not accurately map to what Behr, et al. would refer to as WIP (work in progress).

The low-hanging fruit of constructive team feedback would be the necessity of more frequent external meetings. It certainly was not for lack of trying; the most charitable reading of the situation was that I found there to be no strong consensus on when the team schedules would align. We also would have benefited from more frequent contact internally. Barring all real-world, unforeseen, obligations that took team members away from us the scattering of the team into groups caused our reviews to be staggered resulting in the loss of two full class periods of collaboration. My prescription for this would be that those who come after us should successfully drill down on establishing a running prototype before splitting off into the other groups.

My individual criticisms to my work flow largely still touch on the externalities I’ve lamented in a prior blog post but, if I must touch on them briefly, they’ve stayed mostly the same. It’s quite apparent that certain teaching staff in the university have struggled to pivot to remote teaching and, if I’m to attribute to ignorance and not malice, they seem to have bequeathed those struggles to their students. To those teachers I would like to remind them that Monday holidays are not a surprise and certainly not an invitation to delegate away your teaching responsibilities because you’re lagging behind curriculum milestones. If these teachers cannot grade in a timely manner, then my deepest sympathies, but please do not complain that the bulk of your students keep getting concepts incorrect and you have to re-grade their assignments and/or assign extra credit to help inflate grades. I’m a commuter student with one semester until graduation so I will stay here at Worcester State; if I was a commuter student with two semesters left, I would have transferred out.

https://gitlab.com/nanuchi/techworld-js-docker-demo-app
When paired with their “Docker Tutorial For Beginners” has been an invaluable resource to teach myself Docker and use continuously as a reference.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

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.

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.

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.

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.

Retrospective #2

There is one month left in the semester and it is already time for the second retrospective blog. This was certainly an interesting sprint due to the unprecedented pandemic that took the world by storm. Luckily, it doesn’t hinder us too much as technology exists enough to where we can still collaborate with our partners and other teams thanks to discord, Zoom, Gitlab, etc. To begin this post, I’ll be posting links to the progress I made this sprint.

This is thew link to our database repository because I had to modify it to reflect the new changes that were made after our meeting with Joanne. I am also using this link to show that the branches have been merged because I am no longer testing it.

This is a link to another one of my closed issues. This issue pertains to connecting the database to the server. While, I haven’t figured it out quite yet, there is a link in this issue with a tutorial that I have been using to experiment connecting servers with databases.

There wasn’t a large amount done by me on this sprint due to the COVID-19 outbreak which caused us to have a whole extra week off of school, and completely shifted us to online learning. However, there was a large improvement from the last sprint. Our Gitlab use improved immensely between sprint 1 and sprint 2. We started using the “blocked by” features to make sure issues were getting done in the order that they had to be. We also started commenting more on our issues, so everyone can see our progress rather than just our group knowing what we did. Also, I feel like our communication worked better compared to last sprint, but it could definitely still be improved.

As for what didn’t work well, I think that I could have gotten more work done for this sprint seeing that I only worked on database stuff for this sprint. I also feel like were still only involved in our each individual part of the project when we need to be more involved in each others parts. I also believe our communication with other teams could still use some work especially for this upcoming sprint because if we have time, we need to work on the aesthetic of our web application.

When it comes down to improvements, I know that I can try to work on a little more for this upcoming sprint. Once I figure out how to connect the database to the server, I can then move on to starting my work on Docker and helping everyone else with what they have to do, and hopefully we’ll be able to get to aesthetic because I feel like I would be helpful on that front. As for the team improvements, I still think that our communication with each other could be improved. For example, we can have more zoom meetings with each other and show each other our work. I also think we should talk to the other teams as well because they might be able to help us with things that we are stuck with. Besides that, I think our team is in great shape for the last sprint.

 

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.