Author Archives: Andrew Sychtysz

“The Deep End” Apprenticeship Pattern

This pattern compares the rigorous process leaving your comfort zone in a programming work environment to learning how to swim in the deep end of water. But it is a little more intense as it explains the scenarios of the water and your ability to swim. There are going to be job opportunities that might in fact be out of your skill level.

There are also jobs that might be out of your skill level but not out of your reach. Meaning, if you can reach the skill level with hard work and determination, you should go for it. Just put in those extra hours for however long it takes at the new job to catch up. But also, you need to be able to recognize your own abilities. If you can’t reach, there expectations consider other options.

The pattern includes strategies on what you should do if you find yourself struggling to keep yourself afloat in an environment filled with deadlines that you are struggling to meet. It really tries to touch on the possibility of the worst. As in, if you were hired and you are struggling to meet project deadlines. What should you do? That is what this pattern really tries to break that down how to take one step back and regain.   

I thought this pattern was extremely thought provoking. And really instilled in my own anxieties about my future in the field. What path do I want to dedicate my next year, my next five years, my next ten years? This pattern changes the “Long Road” into the “Intense River”. And I am trying to figure out what river I want to kayak on. Will I be safe going down an intermediate river? I need to create skills that will allow me to adapt.

This chapter also causes me to address my own faults and indiscipline’s. The Software field the way I see it requires a true passion to get better every day. I am all for that. That is exactly the type of thing I need to do something for the rest of my life. It is extremely exciting, but the severity is certainly no joke. I have a lot to improve on to contribute to some of these amazing things we are seeing today.  

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.

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.

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.

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.

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:

Product Link:

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

Issue Link:

Product Link:

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:

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.

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

As I progressed in Computer Science, there was a lot of pressure when it came to thinking computationally. Many of the tests we have faced included problems where you would have to be correct on all aspects or you are simply wrong. There is no close answer only an exact. Which is very fair to a degree. Obviously if there is a mistake in the math, a mistake in the code, or some kind of error, the entire system can fail. When thinking in this way, it can feel very intimidating when beginning your work with a team of Software Developers. You don’t want to be the one who messes something up for everyone else.

That is where the 1st Chapter comes in handy. You will learn quick that this is not the case when working in a team with this format of Apprentice, Journeyman, and Master. You should have no fear whatsoever when it comes to potentially messing the project up for the entire group. I really do hope my classmates catch this part. This format encourages mistakes, encourages risk, and encourages you to give it your best shot no matter what. This will be beneficial for every single programmer involved. What will be detrimental is if someone is tied to this fear. If they are afraid to even attempt anything, it will be negligent for everyone.

The more I read, I really do become passionate about this idea of not being afraid. If you are completely so far off, there is nothing to be ashamed of. The team will take notice, and they will help you get to speed. It’s important to help those behind to get up to speed. But that is not even the main point. Being incorrect will help those who are correct or those who are close to being correct. It is extremely advantageous to see a different perspective on a problem. Even if that perspective is incorrect, it most certainly can lead to good ideas.

 Which leads me to the next topic I found very informative and thought-provoking. Ch. 5 “Share What you Learn”. Sharing what you learn will help you go from apprentice to journeyman sure. You are teaching your teammates new things. But, what really takes me away here is how sharing what you learn and trying to teach it to someone else will only cement your findings deeper for yourself. Bridging the gap between your knowledge and someone else’s understanding is not always easy. It may take some time. That being said, this extra use of your knowledge will only make you stronger with the concepts. I see a large importance in this, especially when it comes to our future in this class.

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.

Thea’s Pantry Set-Up Task #4

The architecture is laid out very nice right here. And it really makes a lot more sense of the work we did in Software Architecture and Design. Meaning, you can see what we were learning last semester in a practical matter. Essentially this Web Service Application will support the user with multiple API’s. Including two Third-Party systems for Logins and Events. It really is some interesting stuff. The Technology we are working with is the same as well. We will only improve our understanding from here. Workflow is exciting because we will finally learn large team orientated branching techniques. And the release Process takes advantage of the Semantic Versioning we have already learned about. Which will feel good to use. Especially after a version you are proud of.

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.

Libre Food Pantry Set-Up Task#3

FOSSisms is a very important page to read. It really prepares you for the team mindset you should enter before starting work in a FOSS team environment. If these FOSSism guidelines are followed it is clear great progress for projects will be made. It might be nerve-wracking when it is your turn to commit a change, but the FOSSisms ease the stress. You shouldn’t be nervous to make mistakes in this environment. You will learn from them, and it won’t negatively impact the team as you would think. Everything that the Libre Food Pantry provides is truthfully phenomenal from Communication to Organization. A stress-free moderated zone to contribute tons of code where you will receive feedback.  

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.

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.


                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:

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.