Category Archives: CS-Worcester

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.

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.

Environment Setup Status Update

It has been a few weeks since I have updated regarding my status on this project, and I apologize for that. It has been a serious challenge trying to get the proper set up in order to work on the OpenMRS Radiology Module. Our group has been plugging along at it every week trying to troubleshoot and determine what piece of the puzzle is missing to get things up and running. My computer in particular is having an issue that when the software is up and running, and all necessary services are running, the page cannot be found. The interesting thing about this issue is that it is inconsistent. For example, sometimes restarting the computer will fix it; sometimes nothing will fix it; and other times it works fine with no problems. I have not been able to get this running consistently enough to be able to use my computer for development to work on the OpenMRS module. The past few sessions I have been attempting to assist other team members in getting a successful version running on their computer.

One of the issues that our group was having is a problem where it cannot locate the Java JDK. This issue was resolved by an unknown solution. A few people were having problems with ports that were not available. The solution to this problem was properly shutting down using vagrant halt rather than using the Virtual Machine controls to shut down the machine.

My current plan is to continue to attempt to get everything running on my computer and hopefully be able to get some coding in! It has been sort of frustrating trying over and over the same methods to attain no results. I truly believe that if I were to do a factory reset to my computer I would be able to get it going, but I am not willing to completely erase all of my data at this point even with a backup.

When to say no… and when to say yes

Chapter 2 of clean code deals with learning how to say no in a professional environment. The chapter is very helpful in the sense of giving example of exactly why you should never commit yourself to something that you will not be able to carry out completely. If you overbook yourself and commit to jobs that you are not able to complete you will create a chain of problems that will come back to you later in the future. The moment that you tell your boss that you can “possibly” get something done, the expectations have been set at the point and there will now be disappointment and possibly consequences depending the the importance of the project that you are working on. It is also a let down to your team when you begin to commit to things that cannot be done because you will often drag others down with you.

However, this does not mean that you should not take on tasks that will challenge you because life should be comfortable and easy. By all means if you know for a fact that the task being asked of you is something that can be tackled, than DO IT! Showing that your team can perform on demand and have fantastic outputs is a great thing, but it is very important to ensure you do not allow yourself to be taken advantage of. It really all comes down to a very simple phrase by a very wise man..

“Do; or do not. There is no trying.” – Yoda

The Clean Coder Chapter 1

Chapter 1 of the clean coder written by Robert C . Martin covered a number of topic that apply to workers as they enter their professional work environment. The transition between being a student and a being a professional in the work field is a tremendous difference. Responsibility is probably the most significant factor regarding working in a professional environment. Anything that you say, do, or create is directly attached to you, and you should take pride in the things that you do. With this being said it is very important that you stay up to date with things and be sure that your work is something worth sending out for other people to see. In order to stay up to date with the changing times and technology, it requires you to take a good portion of your own time and do further reading and studying in your field. Spending time outside work to further your career is a very good investment of time because it will allow you to increase your skills, while at the same time making yourself a much more marketable employee for future employers who could potentially hire you. Your work should not be faulty to Quality Assurance. What this means is that you should not be known as the person who always has issues when the code is send off to be tested. You want to be known as the person that has the code that is impossible to find problems with.

All in all this was a very good chapter and I really enjoyed the reminder of learning outside of work and being sure to exercise pride and caution in everything that you do.

Setting up OpenMRS Evironment

Setting up the environment necessary to run OpenMRS on my system turned out to be quite the process. I think that the major reason that it gave me so much trouble was all of the previous years of “stuff” that had gathered on my laptop. I have a Macbook Pro running OS X El Captain.

The installation procedure was relatively straight forward. You begin the process by downloading the OpenMRS repository from git hub and storing it in your desired location. After downloading is complete you build OpenMRS using Maven, and begin to set up the server. Once at this point, you navigate into the directory with the server and start it up. If this runs for you without complaining about anything, that wala! Your almost done! Mine however had many issues that were preventing it from installing. Many of my issues had to do with things that needed to be updated and properly assigned (i.e. Java). Once the server is going you need to install a GUI that you can use to interact with the OpenMRS system. For the purposes of this class we installed the Legacy UI.

For me the one issue that was continuously surfacing was the Java on my machine not lining up with the Java that the compiler was searching for. After many struggles and much consulting I finally got the Java pointing to the right directory. Once this was corrected everything ran perfectly, and there were no further errors.

First Post

Starting up this blog to begin sharing things that I learn along my Computer Science journey. I will be contributing to OpenMRS this semester as part of my senior capstone project. Looking forward to a great year!