Category Archives: cs-wsu

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.

Expose your Ignorance Pattern

This learning pattern is very important it exposes us to a very delicate issue. Although the Software Development community is built around everchanging technologies, and we are all shooting at a moving target, the fear of letting others know what you do not know is constantly present. Particularly to me, another analogous fear that I think is related to this learning pattern is the fear of you believing you know something and being shown the opposite. I think that at this level in our learning careers, so close to graduating, this pattern is extremely important. This period of entering the field officially, is the period in which we feel the need to show what we know, coupled with doubts and the lack of experience which rob us the confidence we need.

I hope that once we internalize this pattern regardless of the fear of using it, the field, out in the wild will become gradually more amenable. Perhaps this is why I think that a job with a grounded company with tradition in technology is the best steppingstone to a software developer. Every company small or large today relies on technologies that we must understand. This is the reason I fear the non-tech companies that need tech people. The fear that they will expect the newbie to know it all, or worst, not understand what it really takes to get what they want. I think that this fear will probably gradually disappear maybe at about 2 years in the field.      

To sum up I must say that this pattern served me well in my career as a student and I think it will serve me just as well as a developer. I feel lucky to know that I can relate and count on people that are either having the same problem as me or have surpass it to help me. Reaching out to ask people for help is not only better than staying ignorant but help build confidence in the person whom you asked. Even when you ask someone who does not understand the field, their out of the box answer may guide you to a better understanding. I found that I discovered a lot of the answers I needed just by formulating the question and dissecting it to a non tech aficionado.  

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

Apprenticeship Patterns Chapter 1 and 2-6 introductions Summary

I found interesting that a lot of the practices mentioned in the book are probably day to day patterns that we practice involuntarily. Some patterns are surprisingly new and offer a good way to cope with the workflow of continuous learning. The comparison with medieval ways of artisanship in which the learning takes a practicum meaning and the theoretical is stripped out in favor of physical interaction which is very interesting. I am an enthusiast of the theoretical realm, but I must agree that expertise which people wrongly associate with the illusion of talent only comes with continuous long-term repetitions of small actions on limited theoretical content.     

The book showed me that there is more than one way to navigate through a lifelong learning journey. It is comforting to know that in the Software Development work environment the continuous improvement presented by the authors is not only present but encouraged. The idea of sharing these patterns and improving on them is very open source like. It shows the developer understanding of the need for each other and that there is no downside to help the general improvement of the community.  

The chapter that talks about perpetual learning is enlightening. It absolutely homes in on the greatest obstacle to learning which is distraction.  I agree to it but have my reservations because it also mentions that if you love learning you get over these distractions. What I think is truer is that focus is also the most important skill to be practiced. It involves more than a set of actions and habits; it also involves chemical reactions and sensorial exposure as well as countless parameters out of our control. I confess that as I navigate through my undergrad incursion, I came across supplements to improve focus and used them even if just for placebo effect. I have set controls such as continuous study times, set brakes, meditating 20 minutes for every hour, sleeping a minimum of 8 hours, balancing topics by due date and importance, not consuming alcohol even in social events, ignoring people and everything that is not study. Which is why I have a pile of mail and bills after every semester. But even after all the controls I still must continuously adjust and adapt to optimize focus. Without focus there can be no real learning.        

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

Breakable Toy Pattern

The breakable toy pattern is something I practice often without realizing it was considered a pattern for good learning practice. I must say at times I find it to be a double edge sword. Sometimes I look for things beyond my abilities and end up stuck, depressed, and put it in the back burner, but I end up unpacking them later [because I’m stubborn] sometimes over multiple iterations and when I finally get them working the achievement felt is increased in the same order. I think this pattern probably pairs well with other patterns such as confront your own ignorance maybe I’ll write about this one next. Anyway, I want to talk about how he describes the pattern in his own way.

The author makes a good point in the first few paragraphs that the point of a breakable toy was to be able to work on things you don’t usually work on. This description enforces that this pattern helps you learn without side effects on the systems you work on that are not toys. I believe that he makes this distinction to allow for a daring approach, one that would allow you to try something just to see what happens. This allows for a much deeper understanding of any problem. It is like testing to find boundaries, critical systems may not allow such playful adventures but even these critical systems had to be prototyped at some point and someone stress tested the system so you could have a safe playpen.

I know stress testing is an idea that could be consider a little alien to the breakable toy pattern, but I believe it is part of it. When building these breakable toys, we use tools and frame works that we sometimes stress to the end of their abilities. Then we find better tools and frameworks or learn to better use and manage the ones we have.

To conclude the breakable toy pattern allows for growth not only skill-wise but also mentally when we exercise self-control. It allows us to practice focus and confront anxiety. To build the skill set of building skill sets.       

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

Why Vue

There are several frontend frameworks available to pick from, so why do we use Vue? To research about Vue and learn about its benefits, I decided to read blogs from Vue mastery, specifically one written by Lauren Ramirez.

  • Vue does not use up too much memory. Vue allows us to import only the pieces of the library that we need, which means whatever we don’t use will be removed for us via treeshaking.
  • Virtual DOM (Document Object Model) uses compile-based optimization resulting in faster rendering times.
  • To work with Vue, we did not have to learn HTML, CSS, and JavaScript. It was surprisingly easy how we were able to learn as we go.
  • Vue has many libraries that can be added as needed. Some of which are:
    • Vue Router (client-side routing)
    • Vuex (state management)
    • Vue Test Utils (unit testing)
    • vue-devtools (debugging browser extension)
    • Vue CLI (for rapid project scaffolding and plugin management)
  • Vue’s one of the best features – Composition API;
    • We are able to group features into composition functions then call them in the setup instead of having large unreadable and unmaintained code directly in setup.
    • We are able to export features from components into the functions. This means we don’t have to keep re-writing code and avoid having useless repetition.
  • Vue has enhanced support for TypeScript users as well.
  • In Vue, we are able to use multi root components. In most front-end frameworks component template should contain exactly one root element because sibling elements aren’t allowed. The way around to that problem is using functional components, they are components where you have to pass no reactive data means component will not be watching for any data changes as well as not updating itself when something in parent component changes. However, they are instance less and you cannot refer to them anymore and everything is passed with context. With the multi root component support of Vue (Vue 3), there are no such restrictions and we can use any number of tags inside the template section.
  • Vue 3 gives us the Teleport component, which allows us to specify template HTML that we can send to another part of the DOM. Sometimes a piece of a component’s template belongs there logically, but it would be preferable to render it somewhere else. This is useful for things like modals, which may need to be placed outside of the body tag or outside the Vue app.
  • Most importantly, Vue is open source. Vue has complete freedom to be community-driven and its bottom line is the satisfaction of its end users. It doesn’t have to answer to the company-specific feature demands and corporate bureaucracy.

Source: https://www.vuemastery.com/blog/why-vue-is-the-best-framework-for-2021-and-beyond/

From the blog CS-WSU – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Differences in RESTApi’s.

In class we have been working on a RESTApi, frontend/backend, that supports a Food Drive. So far, we have a database that stores Items with orders. These orders have an ID as well as the items. These orders have preferences, restrictions, and emails attached. We developed HTTP calls to manipulate this data in a Rest API. We developed ways for the admins in the backend to manipulate this data. And we developed ways for the users to interact with their orders and items within the frontend of the API.

I thought it would be interesting to take a look at RESTApis that are available through the internet that are individually made, professionally made, and company made. The number of APIs out there is extremely broad and vast. Which makes it very exciting. There is essentially an API for everything out there. From news, health, gaming, PayPal, etc. there is literally everything available to you to implement in your own web service app.

This website here is a database full of APIs that are available for you to use.

Link: https://rapidapi.com/hub

                This led me to a couple interesting ones. For example, a gaming API for Call of Duty: Modern Warfare. It’s neat. You can implement this API into your web service and users will be able to get access to multiple statistics throughout the game. Say you wanted to develop a gaming website. Where users build teams, go to a match finder, play other teams, and improve their placing on a website leaderboard. If Call of Duty is one of the games these users play against each other on, you could implement this API. And allow users to show off their in-game stats.

                Try bringing this site even further. Imagine giving each users an account that has an empty balance. If there is a way for them to add their own money into the balance, then you could create wagers on the match finder. The match would require a price to enter. If the players have the funds in their balance, it will allow them to play. You would need to implement someway for the users to add money into their accounts. That’s when you implement the PayPal API.

Paypal API Link: https://developer.paypal.com/docs/api-basics/

Since PayPal interacts with user’s banking and extremely confidential information, to work with a PayPal API, you need Developer access. When you create a sandbox or live REST API app, PayPal generates a set of OAuth 2.0 client ID and secret credentials for the sandbox or live environment. You must receive a access token to be authorized. To go live with a PayPal API, your application must get accepted by PayPal before having access to any accounts. They way the accomplish this is by giving you a Sandbox that acts as a life environment but isn’t connected to any accounts. Once all your testing and debugging is done, that’s when you apply to use it live.

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.