Category Archives: cs-wsu

Intentions and Goals Part 2: Defining Needs

Setting goals allows me to take things one at a time and move over those self-imposed barriers effortlessly, but it is the learning and the love of the process that don’t even allow me to put those barriers there in the first place.
Now on to one of the actual goals, I have been wanting to use what I am learning as a computer science major to implement into my current workplace. I think that it has been a great opportunity to work there and they have provided a good environment for self-development similar to that of being in school. As a token of appreciation, it would mean a lot to me to be able to leave something useful behind. That something useful would be in the form of Software. In the past year or so I have had a level of engagement in my courses that I haven’t had in a while and that is most likely due to recognizing the practical application of what I’m being taught. This has led me to be vigilant at my workplace and observe problems that can be solved with software. After figuring out what the problems are and defining those issues
For a while, I have been stuck on what to do now after defining the problems from the software development class, and based on the topic of my last two blog posts it is clear to me that figuring out suitable architecture is important to a well-developed software system. To do this, I need to understand the important requirements of the users involved. Currently, I am under the impression that microservices architecture would be most suitable as many of its defining characteristics would fulfill the requirements of the business. Within this process of developing software, I am learning that there is a lot of picking and choosing systems that are specific to the needs of the business. Although it can still be overwhelming, I am relieved that there are already many preexisting systems and that picking and choosing make it a little easier instead of having to completely create something from scratch. On the aspect of picking already developed systems, the topic of API comes into mind I found this useful article outlining different APIs and their use cases and how some are still in use today and fit specific needs. The article points to the idea that even though some APIs might seemingly be outdated that they still have a use case that only requires such an API and nothing more.

I understand that I still have a lot to look out and plenty to learn but recognizing that there is a direct application to what I am learning provides some great motivation and hope that will allow me to continue to get over whatever barriers may be in the way whether self-imposed or not.

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

Welcome To Sovi’s Glass Case

This marks the first post of hopefully many blogs, Hello World.

From the blog CS WSU – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

The Start of a Beautiful Friendship

Being able to optimize software development is very important but the practice of optimizing can be a constant battle when attempting to create good software. The last class I took prior to CS-343 was CS-373, an Operating Systems course. The final project of that course had us create our own phone applications, and while it was exciting to finally work on such a project, it turned out to be very difficult in some aspects. I had the idea of creating a finance app. It was supposed to record ones spending habits throughout the coming months and weeks- planning out a minimum amount they should spend and save. I thought it was going to be very easy to implement and I wrote down ideas that the application software was going to include such as a credential screen, a colorful UI, a splash screen with the logo, etc. The idea of implementing a way of connecting actual bank accounts to gather information was also in play. Unfortunately due to my lack of experience It was hard for me to complete my vision and at the end of the day, I was only able to submit an unfinished application.

There were many reasons for such results, first off, the code was a mess. I would write countless lines of code, and the program, for being a simple finance application, took ages to write. I had to implement over 1000 lines of code just to record information like user spending and budget analytics. It was a nightmare because my only priority was to get my code to work but how the code was organized would stop me in my tracks. I would sit in front of my computer screen for hours looking for compiler errors or logic errors. It made development very frustrating. I’ve taken classes such as CS-348 which served the purpose of explaining how to completely avoid similar issues that I was having, but this project being my first big project, it proved to be a lot more difficult to make a habit of those practices than anticipated. With that being said, the purpose of this blog will be to record my software development process. Whether it be a new technique I’ve learned, a new technology that has really helped me, and whatnot.

From the blog cs-wsu – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

“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.

“Practice, Practice, Practice”

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

Sprint 3 Retrospective

Issues Evidence

Issue:: HTTP Get Range of Questionnaire Submissions

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

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

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

Issue:: testing API for getRange

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

·  Reflection on what worked well

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

·  Reflection on what didn’t work well

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

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

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

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

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

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

“Be The Worst”

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

“Kindred Spirits”

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

Chapter 4: Accurate Self Assesment

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

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