Category Archives: cs-wsu

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.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/backend/-/issues/11

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.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/backend/-/issues/5

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.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/backend/-/issues/7

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.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/general-repository/-/issues/10

  •   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: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/tree/KeycloakNodeJSAppDemo

Tutorial Link: https://medium.com/devops-dudes/securing-node-js-express-rest-apis-with-keycloak-a4946083be51

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.

Learning Pattern Nurture your Passion

The main idea for this pattern is to help one maintain his level of excitement for the field. The author presents warnings of moments where one’s career can be the culprit of discouragement and discontent. He presents a few ways to remediate the situation some by which one could steer their environment to a better place. He doesn’t stop short of recommending leaving a toxic environment if nothing works. The drastic measure is something I would like to avoid because the reason I return to school was the result of it.

This pattern is linked to a lot of other very good patterns, and I am not surprised so many fit well with it. Nurturing one’s passion is the best way to achieve excellence in any filed. Particularly I feel that “Draw your Own Map” is very descriptive of I what plan for myself. I haven’t read this pattern yet, but I think it will be my next one. This support pattern, as explained within “Nurture your Passion”, states that one should know what it wants and pursue it. I like this idea because it removes the self-pity victim mentality away from the equation. This mentality can induce a state of paralysis that is not healthy and hinder you from accomplishing what you want.

My goal after school is to try to find something I am really excited about and maybe even sacrificing pay or title for it. The field of software technology offers the opportunity for a lifelong learning experience. It is so broad, intersects so many fields and industries that it allows for a vast array of choice in which anyone can find something they are passionate about. It also offers the opportunity to trade your convictions and passions for financial gain and we should be careful about that. Some of the things I hear the author talk about I think relate well to what I hear from the gaming industry where is said that they work long stressful hours, and their pay is not up to par to other types of developers. This is a good cautionary tale because most people probably go into this subfield for passion, but passion can become obsession, and that can be very unhealthy.

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

The long Road learning pattern

The long road learning pattern sets its premises on favoring rather than quick results cumulative progress. I believe that working towards a 4-year college degree and the tradeoff that comes with it puts us in that category. We all know that even after the switch from student to paid professional the road doesn’t end. In fact, one of the reasons, I decided to pursue a career in technology was the promise of perpetual learning that the field offers.

The author mentions the constant change in technology and a deeper intrinsic knowledge we developed over time to deal with them. In a sense I believe, he meant that as we acquire experience, we become more sensitive to patterns.  These patterns can help us become more agile in adapting to new tech as well as seeing projections of how they would unfold ahead of their full development. Regardless of how far we get we must not give into the ego and assume things with certainty we can’t guarantee.

We must watch for hardening during the long road. The author doesn’t offer any cautionary warning for this pattern, but I believe it warrants one. In many professions I see how the long road can become a trap to steer you away from self-development. It is extremely easy as you gather knowledge along the road to become a know-it-all. To me there are 2 versions of the know-it-all; the flexible version where one knows a lot but is open to change; the hardened version where one knows a lot and cannot change. I think it has a lot to do with egos, the flexible one is probably perceived by others as knowledgeable but does not care about the title itself so it makes it easier in the long run to reshape knowledge; and the hardened one sees itself as knowledgeable, the title is important so no exterior knowledge that conflicts with its own can be accepted. The hardened one should be avoided; professional life is about social interactions and the hardened one will become isolated or be avoided by others while the flexible one will flourish in a social environment and grow with it.

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

Sprint #1 Retrospective

Regardless of this being our first sprint I believe we were successful at laying out the groundwork and finding each other’s rhythm and perspective. I do think that our team could mature from the information we generated while working on processing what we needed to do. It was interesting to work with gathering the information we needed and not jump into the work itself. At times I as well as others started on tasks that were not planned or even required out of eagerness to see concrete completion. I am a big fan of lists and found it refreshing that the solution to an organized workflow was just to stick with it. Software development is most definitely not work for the anxious and it offers some lively wrestling with the meaning of the word done.

Issues I was Assigned to:

Building a container, was an issue that I assigned myself to because I thought that I could use the experience I had researching it for software architecture as well as other tasks that were closely related. I used the docker files from previous projects of similar scopes to produce development environments suitable to each of the tasks we needed them for.

Contact the I AM team to determine security key format, in this issue we had to gather information on a fellow team’s project. After communicating with them we reiterated what we thought would be the case. Their project required acquiring knowledge on a technology they had no previous experience with, so we thought it would be best to wait until their second sprint when our fellow team would mature the use of this new technology so they could give us an educated use guideline.     

List dev environment tools, this issue was a collaboration by all. It required us to think about certain tools that we like working with and decide whether to set them as default tools to the docker containers in all projects. I personally think this issue was important to have us feel each other’s work antics and to have a hands-on direct collaborative first encounter and produce a list that we were all invited to read, change, discuss and concretize its idea by cross-referencing this issue with the building a container issue.

Clone the API project we constructed last semester into the new API repository, this issue required us to search on previous work and define the scaffold by which we would build our design. APIs are something new to me and I believe to most members of the team, but I think this can also be an advantage because it hasn’t been that long since we looked at it. The sample API is for reference only and should be removed as the actual API is written.

Determine .yaml files for methods; break down into smaller issues, this issue started with a different name and is a good example on how we evolved as work started getting under way. Some of the issues we had with naming issues was that we did not have matured the idea of the project’s purpose enough to be more succinct in setting our actions. Some issues had very broad names which the lack of description rendered their completion troublesome. We decided that a study should be done to break this issue into tasks with a set definition of done. I believe this issue helped us forecasting work for the coming sprint and gave us enough space to now have a much less crowded sprint planning. Another thing I think would have helped would have been having backlog refinement meetings to come up with new issues or being less abstract about the issues we already have.  

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

Unleash your Enthusiasm Learning Pattern

Being a beginner have very few perks so we must utilize them to their utmost extent. The authors make the point of arguing that the new guy has the ability to bring new life into a team that could perhaps have gone stale or that maybe could be improved by such addition. I must confess this learning pattern, or I would better describe it by calling it a resilience building pattern, is a pattern that can help with confidence building and narrowing the aim for purpose. When working with a team in an environment that is new, you don’t only confront with your team’s expectations of what you can do, but also with your own expectations on what you think you should be able to contribute. This ties well with something I think every student struggles with and may carry over to the professional struggles of transition called impostor syndrome.

I have read about impostor syndrome before repeatedly in quorums in which professional developers as well as other professionals talk about it or answer questions about it. I should say that the mere volume in which these topics appear in the wild is a telltale of what should be expected in the first few years of a developer. As a student we easily fall trapped by the illusion of being undeserving, when we grapple with the idea that we have much to learn still. Sometimes it is true that we are unprepared to complete a task or that some of the background knowledge needed for the task was under evaluated in the past and have become a barrier to present issues. But even on the eve of such failures we must not succumb to the temptation of self-assigning ourselves with the impostor role. The imposter would not put in the years of instruction and struggle to become the product of these experiences.

There are little cautionary tales in this pattern as well. This is something I think the authors were very smart to add. In the wild dealing with real world social interaction there can be no one fits all solution. Feeling out group dynamics while applying these tactics is very important. We all have the tendency to grow a little cynical over time so we shouldn’t be judging too harshly an individual or group’s receptivity. If we use just the right mix of the appropriate beginner enthusiasm, we can feel like we belong, or even better, like we have something to add.

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

Sprint 1 Retrospective

My first Sprint Retrospective experience overall truly has been great. Being introduced to a new team environment is different every time, I did not really know what to expect. I had a specific mindset going into this one particularly. I wanted to know, where will I fit in best? I wanted to know the best ways I could assist my team in tackling this project. My teammates made this process very easy. They are intelligent and very ambitious about our project. They were very open about their strong suits and what topics they thought they might not feel as strong in. It allowed us to fill in those gaps and get everyone on the same page. I learn a lot from them.

List of my major contributions to GitLab:

Issue Title: Basics of Keycloak.
Issue Link: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/issues/1

Product Link: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/blob/main/Keycloak%20Introductions.md

Issue Title: Gateway/Ingress. Once requests are past it, are all communications considered secure?

Issue Link: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/general/-/issues/4

Product Link: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/blob/main/API_AccessControl_Authentication_using_Istio_Ingress_Gateway.md

It’s been a very fluid experience so far teamwise most definitely. My individual performance is a different story. I need to make a conscious effort to change the some of the ways I approach things the next Sprint. I created 13 out of 44 issues created. I undercalculated the weight on many of those issues. And instead of continuing to build those issues into smaller ones, I just kept trying to take the heavy issue head on. This put me in many inconclusive rabbit holes. Instead of confusing my teammates with information that is still very new to me, I just kept reading in hopes that something would suddenly click for me and I could produce a confident result. I will link an example of one of the issues I am referring to.

Research: Deploying Keycloak on AWS Kubernetes: https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/general/-/issues/5

Another issue I struggled with was the Gateway/Ingress Research Issue I completed. I spent an incredible amount of time creating that research writeup. Which I personally don’t feel confident on it. I am not sure it is tutorial we will even be following. But I think that it is a good start to grasp the concept of what we will be working on. Another one of my struggles was that I didn’t prioritize Keycloak. I completed my Gateway/Ingress research before I attempted to secure my first NodeJS App with Keycloak versus a Standalone version. Which the Standalone version does not promote a strong understanding of Keycloak versus securing a NodeJS app.

Aside from my self criticisms. I feel very confident heading into our next Sprint. I really am finally starting to feel that confidence behind my understanding of these concepts. It was relieving to secure a NodeJS app with Keycloak for the first time. And it was extremely motivating to start coding again. I can really feel all the knowledge I absorbed start to piece together. I am excited to move forward with tutorials to further learn my way around Keycloak. I have been communicating with other groups on how to deploy Keycloak on AWS Kubernetes. I know what I personally need to improve on to further help elevate my teams process during our next Sprint.

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

Sweeping The Floor Learning Pattern

This pattern is very important it tells us how to begin the career switch from student to paid professional. It is a scary moment of unprecedented uncertainty. It helps us see with a clearer image that there are levels of expectation. These expectations are stratified to build a path to success. It also throws cautionary tales of getting comfortable doing the work at the outer layers of what’s expected.

This is very personal because everyone of us graduating will face the reality of a professional environment. I could not say that it will be harsh or easy. What I can say is that the expectations and anxiety that we generate ourselves is harsh. It makes me feel better to think that the professional world in general has a path in which one can climb, even if this path is steep. The great fear is that there is no path, the goal is the space station, and you don’t know how to build a rocket.

Putting my trust on the writers I expect this sweeping the floor pattern a practiced reality in real situations. I don’t believe there are any menial tasks. All tasks must be completed, and I wouldn’t mind if I had to do some of them or even all of them if it’s all I can do. I have used this pattern in my own life differently. When my car brakes I usually fix it myself because I can not afford the extra expense, this is something that I really don’t want to do. It takes time away from my studies, but it also helps me afford it. Some people say why should they pay a mechanic x amount for only an hour of work but the amount it would take a normal person without the tools and environment would much offset whatever savings they think they had. Most of the time I think if I had the money, I would pay double for a professional to do this for me.

You learn the cost of doing something by doing things you wouldn’t necessarily want to do. Sweeping the floor may begin with doing the easy undesirable work but it must progress into doing work you are uncomfortable with. Success in life comes when you accept uncertainty and never get too cozy as to be paralyzed by extraneous events.      

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

Digg Deeper Learning Pattern

This pattern is a great idea for a beginner such as me. It offers a way to complement the lack of knowledge that comes with the lack of experience. It should be used carefully because of the ease of wanting to just reinforce the skills you are already good at. Knowing a little on a lot of subjects will not help getting things done and knowing a lot in just one subject will get you just as far. The secret as I see it is to have a good toolbox and know how to at least hold each tool. As you need to pick up each of these tools you learn about them more in depth but not too much to hinder your progress. As you shuffle through this toolbox picking up things you need and not obsessing on one tool you build a hierarchy of depth in the knowledge of things you need most. We will handle the same tool more than once and every time we do, we should dig just a little more.

The author presents a more all in version of the dig deeper which I think is the philosophical normalized world idea. It would be nice if we had the luxury of tunnel vision and look for the PhD dissertation of the original design algorithm for every tool we use, but it is also the easiest way to fall into a deadlock. I find that in school it is very hard to get in depth knowledge on every subject as much as I want. Time and time again I see myself compromising and kicking the can down the road, because I do want in-depth knowledge in some subjects, but there are time sensitive co-responsibilities that need immediate attention. Although, as I said earlier, some of these tools that I want to understand better come up again and again over the semesters and I do indeed gain a little more ground on understanding them.

I believe the author is right when he says that we need to learn to dive into ever lower levels of understanding.  By lower I mean from specific to general and by specific, I mean not only the surface high level function you need. The author does throw a little caution which I also mentioned earlier. The risk of becoming what some call a one trick pony.  The balance is really hard to define, and it is very personal. I don’t have my own balance definition yet, but I hope that with time this too will come.

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