Category Archives: cs-wsu

Sprint-3 Retrospective

Sprint 3 was a bittersweet moment for us. We were proud of the progress we had made. On Gitlab, we officially had tons of content regarding Keycloak. Including multiple branches of code, research written in our own words, and documented tutorials. As well as demo apps we successfully secured with Keycloak. But it also signified the end of our work in the class. We now had to allocate our attention to preparing the next class to continue work on the project. Which meant, a decline in our progress to the final product and the end of our work in teams. Which saying goodbye isn’t always so easy.

                Our first Sprint required us to provide massive amounts of research. Which made Sprint 3 smooth sailing. From the start we were geared to creating documentation. Therefore, many of our issues in Sprint 3 was not anything new for us. We had to continue making documentation. And that’s what we did. We wanted to get the next team on the same page we left off on as soon as possible. So, the team worked to create documentation explaining how our tutorials worked, and how to get them to work on any machine. We also wanted the next team to skip a lot of the speedbumps we came across. There was so much information I personally studied during all three Sprints that was not important to our team’s issues. Not that the information wasn’t good, it just wasn’t important for us. And it slowed much of our process down. Having that in mind really set Sprint 3 up in a way that left us feeling like we need what we needed to do.

I created documentation for our team’s history. ( ) As well as documentation for Docker Compose File Examples ( )

                For things I could have done better? Communication is extremely important. I was really locked in on this “Deploying Keycloak on AWS” tutorial during the beginning of the Sprint. I came across a couple speedbumps during my run, and I was awfully silent about it. That was a big hurdle to attempt alone, and I didn’t ask anyone for help. Not only did I neglect this information from the team, but I ended up abandoning that tutorial entirely. Which ultimately burnt my time and wasn’t beneficial for anyone. This is something I need to work on with myself for the future. That was a huge over-estimate of my own ability. And instead of being open about it, I was silent. At the time I was just sorry that I was not successful in completing the tutorial. But now I feel sorry that I simply was not communicating with the team during that time. For myself, I can’t let that fly. I need to be better.

                As for the team? I truthfully don’t have much to critique. I think my team is a great group of students and I am thankful for their work this semester. We always found the time that worked for everybody to get together and get the work done. Of course, we could always have better communication. But I only say that because I saw it happening within myself. This was honestly the most open and communicative team I have been a part of. Something that could’ve helped us a little more. Probably taking more advantage of screensharing software. I feel like watching things happen live on someone else’s screen could’ve been beneficial. I don’t think we did that enough.

From the blog CS-WSU – Andrew Sychtysz Software Developer by Andrew Sychtysz and used with permission of the author. All other rights reserved by the author.

“Practice, Practice, Practice”

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

Issues Evidence

Issue:: HTTP Get Range of Questionnaire Submissions

This issue was added to this sprint to complement the client specification. The main idea was to create an endpoint to query the questionnaire data set and return values within a specific date range.

Issue:: API: determine input fields for Guest info and QS collection

This issue is vague and shows that we have much to improve on naming issues. I interpreted this as looking at the API calls and parameters to make sure they all meet client specification.

Issue:: testing API for getRange

This was done in multiple levels. At the backend with dummy values and a working clone of the app designed to emulate the android calls.

·  Reflection on what worked well

This sprint started well we had a better understanding of the agile workflow. Communication was key to many of the problems we had to tackle. We meet a few times online outside classroom to clarify definition on what needed to be worked on. We shared our work during these sessions and worked out the logic for a few methods. The attendance was important, and participation help us be successful this sprint. Not everything was as smooth as it could have been, but we did finish the sprint with working elements of this current sprint goals. One very important element that was added to this sprint was the mock app feature which allowed for integration testing. This helps because it shows the API will work not only in a web page or web app but also in an android environment without any unintended consequences. I can attest to integration problems because in my robotics project different components networking with each other would behave strangely in ways we didn’t expect or understand. So, checking communication was made successfully with no hick ups is a big plus.      

·  Reflection on what didn’t work well

We still struggle to give tasks meaningful names that everyone understood. At the end of the sprint finals and projects kept most of us busy. Not the entire group meet during the off-class meetings. We worried so much about having something to show that we perhaps missed out on the opportunity to write better documentation to assist future developers. The API version correction was not completely done because we lacked understanding of the CI environment and other school commitments kept most of us from dedicating a huge amount of time to it.   

·  Reflection on what changes could be made to improve as a team

We could have used more time outside the classroom. We did meet more often and had more meaningful interactions than the previous 2 sprints but there is still a lot of room for improvement there. Communication on what each of us were working on could improve. Sometimes we would not work on things because we thought they were being worked on or started working on things already done. Some of us merged the work to main which is fine, but it caused some conflicts trying to merge the branches back. Some issues were not taken or if taken not assigned causing confusion.

·  Reflection on what changes could be made to improve as an individual

I could have dedicated more of my time understanding the technologies and concepts. Although I gained a great amount of knowledge on JavaScript, I still don’t have the adequate know-how to be proficient in the language. Another thing that I could have done better to help would be to dig deeper in understanding the GitLab CI/CD environment and its automation. This lack of understanding prevented me from accomplishing some goals I wished I had completed this sprint. I wish I had taken less classes this semester and dedicated more of my time to this class. A few times I obsessed over parts of projects where I was stuck and wasted time without meaningful gain. This happened less often than other sprints because I did make note of this bad habit, but breaking the habit was more difficult than I thought. The few times I overcome this habit and broke away from the infinite loop of no success I was able to stumble into the solution later because my mind was uncluttered and clear. One of the goals I have for myself in the future is to never dwell or obsess a problem.  

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

“Be The Worst”

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

“Kindred Spirits”

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

Chapter 4: Accurate Self Assesment

I need to continuously improve my skills as a Software Developer. What can I do to make sure I am taking advantage of every learning opportunity? This chapter provided more perspectives to me on the environment of interacting with my current and future colleagues.  If I am hired to develop software, I will then be responsible to develop software. It can seem daunting, but it shouldn’t be. This chapter helped me better my perception of a future in the workplace. If I am hired and on a team of developers that are far more skilled than me, I can’t be afraid. I need to be excited and ready to learn. This chapter helped me realize that this will be the best time for me. The best-case scenario is that I am the worst programmer on the team. That is because that will be when I learn the absolute most. If the time is put in and the gears in the brain are moving, I will be a sponge absorbing information. Further crafting and homing in my programming skills. If I am not as good, it is no big deal. I will just have to put in more effort. It is as simple as that. It would be an enormous opportunity to be around world class coders. If my colleagues are extremely far ahead of my learning curve, I must take advantage and put more time in to learn from them. The chapter helped me see this type of mindset. I also enjoyed that the chapter included a small story about two programmers who did not work together but were friends. They shared many of their experiences, learnings, and passions. This allowed them to even further better themselves. They weren’t talking about work related topics. They were just bonding over their passion for their industries. And it further developed their journey down the road. Which I completely agree with. I think these types of relationships will always be extremely important in any type of skill you wish to perfect. But for our case of a future in programming? This is a different beast. These types of friends, coworkers, mentors will all be vital to the process of growing and getting better at what we do.

From the blog CS-WSU – Andrew Sychtysz Software Developer by Andrew Sychtysz and used with permission of the author. All other rights reserved by the author.

Draw your Own Map Pattern

So far, I have looked through all the patterns in the book as learning patterns. This pattern is somehow different it shows not a formula for growth but a remedy against decay. It tells us of things to come in our professional lives. It warns of the possibility of professional demands that can crush one’s soul. It tells stories of individuals bravely breaking through barriers imposed by different situations in life.

This pattern may seem unwarranted to the steps we are about to take, moving in fresh to the work force, but I believe it applies just as well now as it probably will 4 or 8 years from now. With the semester coming to an end many students probably had an internship opportunity, but many more probably didn’t. Finding out what makes someone tick can be hard especially with the lack of reasonable experience in different subfields. There is a lot of opportunity out there but not all of it are the best fit. I refrain from saying good or bad because I believe these are relative qualifiers.

Knowing what you want is important and changing your mind about what you thought you wanted is part of the process too. A lot of us will start on the first opportunity that comes out. Some of us may be luckier and have a short buffer to sort through a little. None will truly know what they are handed until they take the first step. But regardless of when and which, we must know the direction we want to take. Even not so glorious opportunities can serve us well as long as there are steppingstones in the right direction. We must watch for the fool stones, and this happens a lot I can say it from personal experience. You may find yourself in a place filled with opportunities that do not apply to you only because systematically maintaining you where you are is of greater interest to your employer and believe me, they will do the dance to have you stay there as long as possible. The author warns for that specifically. I think we are at a better place than the examples the author mentions. These people where stuck for years and the longer you take to move the greater obsolescence in your skill set. We must not wait long when is time to move. Employers have their own interest, and it is perfectly fine and healthy. But so should you have your own interests at heart and if they don’t align, then perhaps it is better for the employer, as well as yourself, to part ways.

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

Sprint #2 Retrospective

Issues Evidence

Issue:: backend: look at all lose files in backend/ and determine what is needed and keep them if so.

This issue was worked out in different layers. I wanted to be careful to maintain integrity while modifying the code.

Issue:: backend: in source/data create .js files for methods to be used.

In this issue we have decided after reviewing the code from last semester’s software architecture class that we would reuse it because it served the purpose of the project. Much of the code had to be changed and reformatted to meet our needs.

Issue:: backend: source/ figure out index.js

This file initialized the objects that are important for the operations across the various actions the backend is responsible for. My idea was to explore and find out more about the JavaScript syntax and methods and modules handling as well as behaviors.

Issue:: all: setup semantic release.

This was commission by Dr. Wurst, my colleague Robin and I had already worked through the process of factoring the steps needed to set up the continuous integration GitLab environment. Even though the steps were clear, I took longer than expected some failures along the way actually helped me look deeper into the settings of the continuous integration environment and experiment on them to find out the innerworkings of GitLab’s continuous integration tool and its security.

  •   Reflection on what worked well

In this sprint we tried to work out the issues we had on the first. The idea was to not repeat the mistakes already made and if mistakes were made, we would want them to at least be new ones. In that sense our sprint was successful we were able to identify and adjust expectations. One of the important things that we worked on was to be more specific on the issues and to delineate a better definition of done. In this sprint we were able to connect our different projects and also able to identify points where modifications need to be made in order to work properly.

  •   Reflection on what didn’t work well

Our team suffered from the short absence of some members due to personal unforeseen reasons. The team adapted and the absentee members put back in their missing share and we were able to still have our goals completed. We communicated well as a team but sometimes we would put in too much work leaving little to share. Thankfully the work done individually was hardly final and the trouble shooting, and integration made sure everyone had a part to play. We also had trouble with issue artifacts from the last spring. The names didn’t help us make much sense of what we needed then and moving them around got us a bit lost on planning for the last sprint.

  • Reflection on what changes could be made to improve as a team

To improve as a team, I think communication is definitely key. We should have more meetings outside class and maybe work on issues within these meetings. I see that sometimes we do work during class, but I think these one-on-one meetings would be better utilized for higher level organization, like adjusting tasks, trouble shooting, cleaning up the repo and other tasks. Reaching out is also a good idea if anyone is stuck. It not only helps the person trying to solve the problem but also whoever is there to help. It reinforces what they know and build confidence at the team level.

  •   Reflection on what changes could be made to improve as an individual

I personally think that I could have done more if I have not obsessed over an issue or another. I actually have found myself paralyzed by over planning. I have so many things to get done that organizing how to do them take longer than it is worth. I increasingly found that a generic schedule with cut off set times to switch from one activity to the next can help but a lot of times I freeze when stuck and enter a brute force infinite loop. This account for most of my wasted time that is when I believe that productivity not only flattens but drops so sharply that even if I moved forward, I still feel like I am stepping backwards. Shuffling tasks is truly the best way to succeed in not all but most so ill try to be better at that.  

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

Sprint 2: Retrospective.

If I were to define this Sprint for our team, I would use the word “Progression”. That is a key difference I see within the team wrapping up our second sprint. In the first Sprint, I was personally all over the place regarding my focus and my steps in collaborating with the team. It simply felt like I just did not know where to start. This Sprint, I was able to lock myself down and work on something for a long period of time. Opposing to the first Sprint where I was trying to have an ultimate understanding of every key word in our epics. I was successful in building a good base of knowledge for myself during the first Sprint. But, as the second Sprint went on, I had a better grasp of how to prioritize myself and my work. I noticed it within the team as well. It seemed that during this Sprint, we were all one the same page. And if someone wasn’t up to speed, we often stopped what we were doing to help. Honestly spectacular work from the team. Anytime anything was uploaded, the teammate who uploaded the work always made sure to let everyone know and teach them about their work.

One huge piece of work I had during the second Sprint was my “NodeJS App Secured by Keycloak Demo”.

Gitlab Link:

Tutorial Link:

The primary focus of the tutorial was to secure Node.js REST APIs with Keycloak Node.js (Server-Side) Adaptor. The great thing about this tutorial is it did multiple things for me. It gave me an extreme understanding of how to work the Keycloak Administration Console. It turns out to be a super simple interface to work with. At first it was a little confusing but once you can understand the Keycloak lingo/terms it is a cake walk. I feel super confident within the Administration Console because of the tutorial. It also teaches you how to generate access tokens for users. Overall helping you build your Node.js application to be configured for a Keycloak Node.js Adaptor. I still have more plans with the tutorial. I got it to work. I got the correct output the tutorial outputted. But I still don’t have a 100% concrete understanding of how everything is working. I will be continuing to work with this tutorial as I believe it will be much more useful for us in our next Sprint.

It is tough for me to talk about things that didn’t work well for us this Sprint. Obviously, there is always room for improvement. But I really saw great work ethic from all my teammates this Sprint. From start to finish, we were working at a phenomenal rate. And we were communicating very well. We communicated much more this Sprint than the last one. Even creating days where we all met online outside of class to further our collaboration. I am very proud of the team. If I was to nitpick anything, it would be our Issue board. It is not easy making a board that flows. We need to work on breaking issues into smaller ones. And try to better define the issue. Some of our issues you look at and it’s kind of hard to decipher where you would start or how you would approach the issue. I must add, this was an issue during the first Sprint, and I saw much improvement during the second Sprint. It’s just simply we can continue improving.

One conscious effort I need to make for improvement during the next Sprint is my Gitlab Contributions. I just don’t think I have been working enough inside of Gitlab. There are so many small things that I can do for our entire Project page. From creating more issues, comments, fixing typos, etc. I just can do much more. Mike has been a great role model for this. His name is all over our Activity page. He actually has been doing a phenomenal job at that, and it motivates me to do more myself. To wrap my feelings about the sprint, I am proud of the team. We have provided 2 demos, and a Vue app build from scratch. The team worked tirelessly to make sure we all have these demos working on our computers. And helping everyone understand all the new information we gathered. I truthfully am excited to move into our next Sprint and keep the progression moving.

From the blog CS-WSU – Andrew Sychtysz Software Developer by Andrew Sychtysz and used with permission of the author. All other rights reserved by the author.

Chapter 3: Walking the Long Road

                The chapter starts off with Dave recognizing that the people who are miles ahead of him are on the same road. I really homed in on this. One of my weaknesses is that I can be very critical towards myself. Which is fine until I start comparing myself to others. When my colleagues and I are both presented with a new challenge, it can feel daunting if my classmates are gripping understanding of the intense concepts at quicker rate than I. I was faced with many challenges like so before I read this book. The reason why I didn’t give up, was because I somehow recognized this “Long Road” concept. Rather than thinking I was too far behind, I thought that if I could keep up a pace I would catch up. And eventually I did. Once I caught up, I was able to keep progressing and even pass some of my colleagues. I didn’t recognize this situation the same way the book did. But I had a similar mindset when it came to me continuously pushing forward.

                When the chapter starts breaking into the concept of planning for the “long term” my attention is further grasped. Everyone as a Software Developer is reaching to obtain mastery level understanding. Of course, we are all seeking ways to stop having to research and ask questions. In a perfect world, we could write any software we wanted at the pace of writing an essay. But the world is far from perfect. And as an apprentice, we are far from being at that level of coding. We need to plan our own journey in a way that allows us to continue progressing. And we need to understand that the journey is going to be long. With this recognition, we can begin planning to accomplish whatever we want. No options are closed for us, and we have all the time in the world to catch up to someone who is ahead of us.

                Many basic concepts were stated regarding keeping your passion during the hard times. It is clear, that there is no way around the struggle. It is guaranteed to come with it. And it will be a unique and different experience every time you hit a tall obstacle. If you digest in a route that automatically interests you, these painful moments won’t be so painful. And it will give you a stronger ability to keep pushing through it.  It’s all about carefully setting yourself up on a path to success. We are given the tools to do so. It is up to the programmer to choose which tools they want to spend their lives mastering.

From the blog CS-WSU – Andrew Sychtysz Software Developer by Andrew Sychtysz and used with permission of the author. All other rights reserved by the author.