Category Archives: Sprint-3

Sprint 3 Retrospective

As many of the others in my group have said this was probably the best Sprint, we have had this semester. What specifically went well this semester was right when the Sprint started. That was a problem we had the last Sprint because we had a slow start because of Spring break. When this semester started, a lot of us were in the middle of working on issues so when this Sprint started, we continued working on the issues. A big problem we had last Sprint was we did not do enough documentation. Towards the end of the second Sprint and the beginning of this Sprint, our group made a big change. We decided that we would do little to no work in class and instead focus on updating the group on what we are working on, cleaning up our issue board, resolving any major issues that we encounter before that class, and documenting the progress we made in and out of class. This is because we made the realization that most of us in the group worked better alone, but when we ran into issues none of us were shy about bringing them up in the group meetings. We also did not have any issue asking others in the group for help. This was one of the most successful changes we made to the group. When we made this change, it caused the productivity of the project to skyrocket.

What I think did not go with this sprint was how ambitious our group was this sprint. We planned to get a lot complete in a short time and it did not all get done. For example, we wanted to complete the cards.js file and the display.js file as well as the prompts.js and writing.js file. We also wanted to add theming to our project so that it would look neat and professional. We ended up finishing the cards.js file but did not finish working out all of the bugs for the display.js file. In terms of the writing portion of the project, what we wanted to use at the start of the sprint did not end up working and we ended up adding a placeholder with some functionality so that we could have something to present.

I think we did not have too much to work on this sprint as a team. For the most part, I think it worked out very well. I think as a team we really improved our documentation this sprint. What I think we can improve a little is our individual documentation for issues and other small features that we worked on. Towards the end of the sprint, our documentation was a little lacking compared to the beginning of the sprint because we were rushing to the finish.

During the sprint, what I worked on was leftover from the previous sprint. In the previous sprint, we made a display page, but it did not properly transfer information from one page to another.

So, for a while, I contemplated how to move forward in the project and considered restructuring our project or looking at other ways to transfer information from one page to another.

How I fixed these issues was by simplifying our structure and moving screens to their own respective files.

Before this change, our app.js file did too much and was handling the navigation for the project as well as creating multiple screens. Moving things to their own files simplified our file structure and fixed some of our earlier navigation issues as a result.

When I did this change to restructure our project, it made creating the display page a lot easier and I was able to get it working to an extent. We can transfer information and display it on the screen but it currently does not display the correct information.

This is not because our function is wrong but because our logic is off. The function displays whatever we pass but we have a hard time figuring out what to pass. I was really stubborn at first when I encountered this issue and did not want to ask for this last issue. I have the issue at a weight of 2 but it is definitely more. Even when we had three people working on it, it was not done. So, what I need to improve on is to be less stubborn and ask for help even if it’s last minute.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

One More Sprint (CS-448 Sprint Retrospective Blog 3)

INTRODUCTION: As the final Sprint of my team’s Software Development Capstone project introduces its conclusion, I feel as though it is a good time to reflect on the results of this sprint. Going further, some aspects of this blog (specifically the conclusion) will involve reflection of the project in its entirety. To start, I believe that this sprint may have been weaker than previous ones. Factors supporting this argument include the idea that we now have experience from the previous sprints and that we should be more prepared; factors against the argument include non-work related considerations (such as future semester set-up).

POSITIVE FACTORS: During the final sprint, these favorable events had occurred:

  • Our team had made progress on getting Keycloak into a Docker container. Hopefully, futures semesters will be able to complete the project for us (allowing connection to the AWS Team, and other teams in general).
  • Speaking of progress, our Product Owner (our Instructor/Professor) has mentioned that the team has made an impressive amount of progress in general. Factors involved with the amount of progress include comparisons to previous semesters’ work, and consideration of the fact that our team had quite literally started this project from scratch.

NEGATIVE FACTORS: As much as the team has improved, there were still some bumps in the project’s road. These bumps include:

  • To contrast the statement in the “Positive Factors” section, work on the Keycloak Docker container has been completed, but we do not have a final product yet. However, in our defense: part of this sprint was spent setting up the project for the teams that will work on it in the future.
  • As mentioned in the “Self-Improvement Suggestions” section below, this team has done quite well during this sprint (considering the fact that the Scrum Master was not as involved as previous sprints). I understand that Scrum Masters do not have a drastic amount of authority over the rest of the team; at the same time, too little involvement with the team’s work essentially makes them a facilitator “in name only”.

TEAM IMPROVEMENT SUGGESTIONS: Even though we have no more sprints left for the project, it is still a valuable form of criticism to discuss where the team can improve. Factors involve:

  • I believe that additional dedication to Sprint Planning would be beneficial for the team. While our first two sprints involved research of our issues (in other words, we didn’t know what we needed to do), having a clear idea of the end goal will make for more efficient work. This is opposed to issues being brainstormed and abandoned like darts thrown at a board.
  • In addition to Sprint Planning, having a better structure for our Sprint Review/Demo classes can help. While we get our work done, it’s also important to know how to present it in a neat, organized manner that is easy for the Product Owner to interpret.

SELF-IMPROVEMENT SUGGESTIONS: In addition to team improvement, there is always room for self-improvement. Some ideas for my own improvement are:

  • Since I was the Scrum Master for this sprint, I must say that I was not as involved with the role as I would have liked to have been. In future projects, I would like to dedicate more time to the role; hopefully, outside commitments won’t weigh me down like they did during this semester.
  • In future Scrum work, I would also like to be more involved with Gitlab issue board work (this factor ties into my criticism of my Scrum Master performance). I feel as though reviewing and commenting on issues isn’t enough; taking the initiative and creating issues is a key factor of being a leader on the team.

Considering the project (and its semester) as a whole, I will say that I appreciate my teammates and the work that they have done. We have all made this Capstone project a pleasure to be involved with; in fact, due to how pleasant the overall experience was, I have shown interest in working with the LibreFoodPantry software outside of the class. To be honest, there’s no reason not to be involved – working with LFP has varying levels of commitment. Regardless of the commitment level, the work is a great way of acquiring work experience and keeping Software Development skills fresh.


From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

My third and final sprint for my software development capstone has come to an end. Here is what I did, and my thoughts on it.

This represents my thoughts on this file after looking it over. There’s probably still room for improvement but I didn’t think it was the best use of our time.

Changed the API to swap out json for plain text, since we want to return a .csv file.

Removed this because the previous commit made it unnecessary.

Some minor restructuring of the API.

Fixed a typo in the filename of the .yaml file mentioned above.

I think everyone had a pretty good work ethic. While individually we may have struggled, we collectively knew what we were doing.

As far as things that didn’t go well, I think we’re still struggling with assigning correct weight point values and issue granularity. Most things I did felt either too easy or too hard for their given point values, mainly the former.

The issues we made mostly felt to me like they were too specific. Sometimes this meant they were too easy, but not necessarily. I think it caused unnecessary confusion, since what should be one task might get split up into three, done by three different people. There’d then be no way for any of them individually to check their work.

There’s the possibility of coordinating the issues so that it’s clear they’re dependent on each other, but I think it would be simpler to just have them all be the same thing. I wouldn’t coordinate issues in this way unless they were clearly separate tasks, but still related.

One thing I think we could have done as a team is coordinate more. I think communication was our biggest weakness. I always felt like no matter what I was doing, I was always kind of going off on my own. At the start of the semester, we agreed to take turns being the scrum master, but as it went on we focused less and less on procedural concerns. I think we could have benefited a lot if someone had stepped up to be the team leader.

As far as things I could have done to improve, I could research more. My biggest roadblock was not really understanding how all the moving parts fit together. I think I overestimated my skills a lot. Also, in the context of a college class, there’s a strong incentive to just do the bare minimum to pass, with any independent study taking away from other classes and out of school activities. I did manage to get a little bit of independent study about the tools we were using in, but not nearly as much as I’d have liked.

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

Sprint 3 Retrospective

For the last sprint, the main objective, from a frontend perspective, was adding some final touches to the code and making documentation for next years group. My biggest objective however for this sprint was to get semantic versioning to work. Semantic versioning, in simple terms, allows us to make version tags for any ne code that is pushed to the main repository. For example, if I pushed something new to the main branch that is a new feature, it will tag this as let’s say “v2-0-1” and it will make a container as well with this tag. This is helpful to us because if we ever need to go back to an old version of the code, it will be easy using the tag container in our docker-compose file. This for a few days was giving me issues until I found what the cause was. The main issue was our docker compose version. Throughout the sprints we have been using version 3.8 but for semantic versioning to work I need to add a docker compose apk to the ci and change the version to 3.3. This allowed the versioning to work and tag.

For this sprint I though everyone worked well together and got a lot done on both the frontend and the backend. Like the other sprint we did a divide and conquer style of completing the issues the were left for us to finish in this sprint. Everyone had a final hard task to do in both the frontend and the backend which gave us more hands-on knowledge that we all can take to our future workplaces.  The only thing that I think didn’t work well for this sprint was people doing task but not assigning themselves the issues. We had an issue where two people were working on the same issue which caused confusion between the two. A compromise was eventually found, and the issue was complete but in the future people should not be doing this as it could lead to a bug or error In the code from different algorithm styles.    

As a team, besides what I talked about above, I found that there is not much we can improve on as a team. I found that this sprint went very well and am proud of the work the was complete during this time. Also, this being our last sprint we will not meet again to be able to improve together. As an individual like last sprints, I had some issues with commits again. For semantic version I had roughly 30 commits trying to test the pipeline and find the errors. I could not find a way to test the ci locally, so I swamped the commit log with tests. In the future I need to either find a way to test ci locally to make changes before clogging the system or I need to e better about error tracing so there is only like 5 commits compared to 30.


Update guest data to new datapoints:

Updated port numbers in code:

Updated README:

Semantic versioning: and many more commits in repo for testing

Fix v-show bug:

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Retro #3

With this being our last Sprint for the semester, it couldn’t have ended on a better note. Cooperation between the team members and communication continued to be effective. Everyone seemed stepped up and the work ethic was beyond that I could imagine. Comparing to other team/group projects I have been on in the past.

During this sprint, I worked on creating a key for the endpoint authentication. We were still waiting on the actual key from the IAM team so in the meantime, I created a code that will give authorized individuals in the LibreFoodPantry access to their sites. Such has if a guest has access to the LibreFoodPantry portal, once they put in their login credentials, they will either be authorized or unauthorized. This was by request of the client.

Some of the issues that we faced was the getRange API calls. This method required additional coding to the NestTester, API and the backend. Once that was completed, we were able to move on from this project.

I think over the past two sprints, our usage and knowledge of GitLab Epics and Issues board just continued to improve. One issue we faced in the beginning was apply the proper weight to each ticket. As the sprints continued, our distribution of the weight continued to get better. We ended having a better workflow and a more balanced and shared workload.

With a good portion of our task completed, we mostly spent this sprint communication with the IAM team to get a better understanding of when they need to integrate security mechanisms into our remote function calls. We concluded that this will not be complete this semester and will have to be pushed to next years Capstone class.

We were giving the option to continue to work on this the rest of the summer to better improve the progress that we have. This is not a bad option since technically this is for a real work client that is expecting some type of prototype. Joe has decided to stay on and continue to work on this while myself, I have opted not to. With this being my last year, I have other opportunities that I will be pursuing to better myself in this field.

As the conclusion to this spring, the group decided that each member will record a portion of the project and prepare a video presentation. I’m overseeing the consolidation all the recordings and preparing a video presentation for Dr. Wurst. We broke down what needs to be discussed and each member will pick what they would like to talk about. I will take what’s left over to check off all the topics that we would like to discuss/present.

The capstone was a good experience and helped be become a better team member. Being able to see each member grow from the first sprint till now is always something that I am proud of because I know they each learned and took something away from this class. Not all was smooth, and we definitely had some bumps along the way but in a real world scenario, that is what happens and you have to learn how to adjust and get over those bumps. Theirs always a solution to any problem, isn’t that was coding is, solving problems.

From the blog CS@Worcester – The Dive by gonzalezwsu22 and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective Reflection

In this blog post, I will reflect on the third sprint of my capstone project. I will discuss what worked well, what didn’t work well, changes we can make to improve as a team, changes I can make to improve as an individual, and I will end by listing links to the work I have done with descriptions.

One of the things that worked well for me personally during this sprint was the quality of documentation that I had created. I would say that my documentation was consistent from beginning to end for sprint 3. For all the work and decisions I made for this sprint, I made sure to document it for my current teammates but also for the next students who would be taking over this project. Another thing that worked well for me this sprint, was creating a document with specific goals that I wanted to accomplish prior to each class. I regularly checked in with this document through sprint 3 and it served as my personal issues board. I kept updating the specifications of my issues but the overall gist of the issue remained intact for the duration of sprint 3.

For things that didn’t work that well in this sprint, even though I consider sprint 3 to be my most productive sprint, I also feel like I did not deliver enough minimum viable products that possessed incremental improvements. While I did produce a minimum viable product for updating our landing page, that soon got quickly incremented with another teammate’s commit. What I was really hoping I would be able to crack was creating an interactive drawing page for the writing portion of our application. While I made several attempts in creating this feature, they were all ultimately unsuccessful in producing a minimally viable product that improved on the pre-existing code.

As far as what we could improve on as a team, one of the things that I think could have made us even more successful would have been having a conversation about what we wanted the minimum viable product for sprint 3 to be. I think we knew all the work/issues that needed to be done for this sprint and we went full steam ahead, however, we probably could have benefited from taking a mental snapshot of where we were at the end of sprint 2 and where we hoped to be at the end of sprint 3.

When it comes to changes that I can make to improve as an individual, I would like to address my previous issue of what I don’t think worked that well for me in this sprint. Next time, I think I should focus on taking what is already present and making one minor incremental improvement before moving forward with an exploratory phase to create a major improvement. My initial increment doesn’t have to be much, but it would allow us to say we delivered something different from sprint 2. By doing something small and simple first, I can then focus my efforts on riskier experiments. If these experiments work out, the risk would have paid off, but if they don’t work out, I can fall back on the safe, small incremental improvement I made.

Links to evidence of activity on GitLab with descriptions:

  • What I essentially did for this was replace the “We want pizza” landing page to one with two separate buttons. One leads to the “Writing Portion” of our app and the other leads to the “Reading Portion” of our app.
  • I asked for clarification on why an issue was closed so that it is documented.
  • I explained my process with getting expo running for me (which is different from how one of my teammates was doing this).
  • I pulled and checked out the code per my teammate’s request to make sure it worked on my end.
  • I pulled and examined Emmanuel’s code per his request and then made some exploratory attempts to implement a writing feature.
  • I documented a potential idea for our issue with implementing the reading portion of our application.
  • I created an issue with some notes for whoever starts the process for this issue.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 3

Oddly enough, I found this sprint to be a tad more challenging than both the first and second. I’d say this is primarily because we were nearing the end of our project, and the team had some difficulty accurately choosing and weighting our epics and issues. I’m unsure if the rest of the team would agree with this sentiment, but it’s certainly something I felt at the beginning of the sprint. We all eventually found worthwhile contributions to work through, but the lack of cohesion or agreement at the beginning was a little jarring. 

Despite this, I’d say the team got some of the harder pieces of work done near the end of the sprint. I certainly remember the getRange file for the API being a huge hurdle to get functioning, but with Jeff and Kenny working together they made it work in the end. Personally, I felt a little stuck after implementing a few new schemas in the API, as I had elected to work on the key validation from the other groups’ projects. I thought I’d give it a shot, as encryption has always been pretty fascinating to me with all the different types of encoding techniques that exist. However, I soon found I was quite far out of my depth; I ended up staring at StackOverload and random forums trying to get the verification working for a lot of class time. There were a few times I thought I had cracked it, but unfortunately it broke the code every time I pushed it into our repository.

In the future and during my career, it’s pretty crucial I learn to reach out or actually post something on one of these forums for help. I’m sure during the process of an actual situation my seniors will be vastly more knowledgeable than me on basically everything, so this is a skill that should hopefully develop naturally. Of course it’s important not to be an incessant pest, but with my genuine willingness to improve I’m sure I’ll be fine.  

Overall, I was still really satisfied with the team this sprint. I think we all found our roles and niches in the project to work on, and were more than willing to answer questions and help out whenever it was needed. I found the capstone to be a great introduction to my future career opportunities, and the familiarity I garnered over the semester should boost my competency level pretty far beyond what it would have been otherwise. I also look forward to working on a team with a dedicated scrum leader who I can look to for some direction if I feel lost.

One thing that I do think the team could have communicated better on was our presentation. I know it’s pretty separate from the actual work we were doing, but for a good amount of time I had no idea what I was supposed to be covering in the video. I defaulted to whatever the team didn’t initially choose, as I wanted them to be more interested in what they were presenting. Unfortunately, it was difficult to glean my responsibilities as some members were quick to post what they preferred, while others didn’t accurately mention their coverage. In the end I just went over the API, and I hope I didn’t overlap all too much with the others’ videos. Regardless, that’s a minor gripe, and I don’t blame anyone because it’s the end of the semester. 

As for some contributions, I added these pretty minor things to the API over the sprint.

I also helped out a bit on the getRange before I started working on the backend key validation. It starts on line 56 of this link.

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Sprint 3- Retrospective

This last sprint did not go as smooth as the previous, we encountered a bunch of roadblocks with the backend that sort of disturbed the plans and dynamic established previously. We were able to get to a decent and somewhat better end product then what we started off with but we didn’t quite reach some of our main goals.

What didn’t work well

As a team:

The biggest issue was the backend not running. We started the spring with all the endpoints written down but we had an issue with connecting it to the database and getting it to work. About half the issues of the sprint were solely related to the backend and now that we could run or test anything, a lot of us were left with not much to do, or not knowing what to do. Consequently it led to a lot of not really productive time.


Going into the sprint, my task was supposed to be testing and fixing the two endpoints that I wrote and that didn’t end up happening because of the backend not running. Since there was already two other members actively working on the backend, I found myself not working on anything for like half the sprint. At point, I would join in with the backend work but it turned out to be us three doing the same test so I decided to look inside the folder to see if there was something else I could do.

I also think that this sprint being toward the end of the semester, I ended up focusing my energy on another project since I couldn’t find anything to do.

What worked well

As a team:

We were able to fully refactor the front-ends for the most part, we updated all repositories with all the necessary add-ons (commitlint, RabbitMQ tutorials,…). The backend was created and is running. It’s not working yet and consequently the endpoints are not tested yet. In general, we accomplished over 80% of what the goal was for the semester so it was indeed a success.


The one good outcome was that I learned a little bit about automation testing. There was a Testing folder inside the microservices example with classes like axios.js, chai.js api.js and so on. It was a bit confusing but I discovered a bunch of links (blogs and videos) that helped a bit. I pushed a document with all the links in the documentation folder for the other teams to refer to it.

Changes to be Made

Most changes that need to be made are for the next team. They can work on the following:

  • get the backend to run, it is very close to being ready as it is working already;
  • Take a brief moment to modify the user interfaces for check inventory and add inventory to prevent user error;
  • Test and fix all endpoints;
  • Develop the front-end calls based off what was set up in the backend and connect it to the web pages for testing the frontend containers with the backend


Add document with Information on testing folder(backend) (#39) · Issues · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / InventoryBackend · GitLab

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

Sprint 3 Retrospective

During Sprint three we ran into issues that bottle necked our project. But in the end we were able to overcome these obstacles and make some good progress.

What did not go as well was the planning of our issues, and not knowing how long each issue would take. One of our issues was connecting our API to our backend, and building our server. This issue ended up taking three people from our group more than two weeks. And we were unable to meanigfully test any HTTP calls until our backend was running properly. Looking back, we should have starting working on this during sprint 2.

What did go really well this sprint was working together to get the app running. We spent one class, all working together. Working through docker errors and making progresss that way. Chirstian made progress on his own as well. He made a docker file and reused the shell scripts from last semester to get the server running. The issue we ran into was that even with the server running, we could not execute any http call, without getting a connection error. This was the status of the issue for about two weeks.

I tried to work through the connections errors using stack overflow and other online resources, but to no avail. I then asked Jared, and sent him a screen shot and he said they ran into a similar issue in his group. Then, Duwal, Jared, and I jumped on a discord call and together we got the server running, so that we could call our http methods wihout connection errors. This was a huge break through for the team.

Another issue we ran into as a team was meeting to make our video presentation. We had a hard time picking a time in which everyone was free. Because classes had ended, and group members had finals and other engagements. The solution we came to was that everyone filmed their part and sent the video to Christian, who is going to edit it together and submit.

One thing I can do to improve as an individual is learning to ask for help, outside of the normal avenues. Once I asked Jared for help, he knew where to get started on our problem. So I learned that sometimes I need to ask an outside opinion for help. There is a limit to how much I can figure out by debugging and googling on my own. And sometimes an outside perspective, or somebody that has encountered this problem before can make all of the difference.

Below are the issues I worked on this sprint:

I added access token capability to the API repo. I added a schema for a 403 response. And I added that response to every path in the API repo. Link:

I researched endpoint testing standards and created a template js file in the backend repo. Link:

I debgugged tbe connection / server problems in the backend repo. Link:

I helped Duwal with the test file for returning the API version. Link:

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

Sprint #3 Retrospective

During this sprint my previous work in getting the front ends linked to each other for testing would finally be quickly integrated for the two front ends addInventory and checkInventory.

While figuring out how to properly implement it into checkoutGuest front end, it was found to be not properly set up like the other projects and would require setting it up to be the same as the other front ends in terms of their vue formatting.

I was spending the majority of my time learning more about vue and how to set it up within an already created project and managing the new changes when I decided to take a peek at the previous branches as the way this project was currently setup didn’t match the others and I considered the possibility of something in development perhaps being left behind.

I found a branch called updatedFunctionality, and in it was a project formatting exactly like the other front ends and I knew then and there that we needed to integrate it within our current branch. My professor recommended that before we merge it into the main one to do a merge into a test branch to simulate what it would be like between the two and see what conflicting merges we would have to deal with. He also preferred that we didn’t just erase the main branch’s development as to not leave out the work created by previous students.

I successfully merged the two branches and got approval to merge the main and this branch and deal with the conflicting merges of which there was not too much. With some help from my fellow group member Fadi Akram the branch would be merged and my I would implement the changes needed to connect this front ends to the others like I did at the start of the sprint.

Afterwards I would spend my time testing and working on the user interaction portion of checkoutGuest as it involves a point in which the user of this station will be scanning or manually entering in student ID’s to record items being taken out of Thea’s Pantry. Working on previously established work from Professor Wurst, I modified the user interface to accept ID from both keypresses, scanning, and manually entry by keypress in the same format as it being scanned. I also made sure to prevent future issues by preventing negative values being submitted and locking the text box for user ID when a proper value is entered to prevent further changes if there was a mistake made. I also added a clear button should the user desire to make a change as they have entered the ID, should it not match the one they have typed.

There is still some modifications that should be made to the interface like allowing during manual entry to delete the desired values and modifying the value of the idnum variable to match. It would be just checking for the backspace or delete keypress and modifying the value, but it would require testing and I can’t say I am certain if that would work perfectly just from that idea.

Overall this was a far more productive sprint for myself than the previous ones. The efforts made in the previous ones helped me to succeed in this sprint thanks to understanding vue and html better.

During this sprint my team was primarily focused on fixing the backend and had I finished my work sooner I would have been working with them as well trying to debug it. My team did come together well to focus on that issue but our ability to work on testing the backend was limited by it not being able to startup and work.

I did struggle with some of the JavaScript coding while refactoring it a bit and that is definitely one avenue I need to take to improve on my own skills. It’s fairly similar to other languages I have used but some of the syntax did in a sense fight back against me, like how JavaScript handles operands with their weird truthy and falsey system. While creating conditional checks some would still pass through as it was still considered “truthy”.

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.