Category Archives: cs-wsu

Whats Next?

I have had this unhealthy assumption in my mind that CS is just preparing us to just sit at our desk all day and write code for hours upon hours(at least in the industry context). Although, in the cases where this may be true, for those that are in that position, there may be a good chance that they are doing what they enjoy. I don’t see this being the entire case for me. Knowing this, a couple questions and thoughts come to mind; in exploring different roles one can play in the tech industry, where may my own opportunities lie? Can I recognize what I am learning in relation to that, maybe even evaluate how/what I am learning to where I might see myself? Can I map out my career?

I think it is important to ask such questions while taking these CS courses. While asking such questions during the courses I can recognize where my strengths may lie and discover possible passions/interest. I am prone to overthinking(especially with complex ideas) and such practices allow me to step back a little. Going off previously stated questions, there is something about the front-end that is quite alluring to me. Which leads me to an article that I found titled “Exploring the front-end of project management”

Although it doesn’t talk about specific front-end development tools, (a topic in which I would like to look more into) and more so on what comprises the front-end and the role of management, it is a exploration into the front-end, or defined in the paper as the “earliest stages of a project”.  I think that the article is still relevant as we can recognize that the POGIL group work style of the class allows students to be able to work in groups, the prevalence of different roles is to almost simulate the professional setting in which on may work. This style teaches students to be able to work well with others and communicate very complex ideas. I personally find a lot of enjoyment in working in groups and struggling and learning together, specifically; exploring and playing with the different roles from manager to presenter, working through unexpected situations through analysis and modification, and sharing finding with the entire class. From my brief research, the front-end to me seems to be where I can explore not only different roles but explore even more broad experience from different aspects of the tech industry.

On a different note, I made an observation in my last post about the nature of the learning that is done in CS and how topics can connect. I described that connection of topics as niches. I wanted to make a correction and niches may not be the right word. Perhaps, layers, at least in the context of this class I could argue that front-end being a layer in software development is more suitable. If anyone gets what I am trying to say and can find a better way to word it, please let me know.

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.

Thoughts on Front-End Development

I often find it hard to relate back to other courses and easily forget about what I have previously learned. Luckily, my memory is not as bad as I think it is and it eventually comes back to me, especially in the case where I have to come back to a skill/technique regularly. I find that with Computer Science the evolution of knowledge is one that is clear yet has a depth of knowledge that intertwines one course with the next.

On one hand, you can have a course that is so specific in a niche of CS that it may be hard to see its relevance in another CS course on the other hand you may have a course that is seemingly so broad that it is hard to pinpoint how it may carry over.

I think that with any specific area of interest, as one continues with their education, the degree to which prior knowledge is necessary and relevant to learning a new topic only increases the further you progress.

All this is to say that last semester I took a cloud computing course and I remember that course being broad in its application of cloud computing. I wanted to look into the use of cloud computing in the context of software design and architecture. Secondly, after only getting a taste of front-end development in this course I wanted more and I wanted to solidify my understanding of the back-end and front-end in an attempt to satisfy a goal of mine described in a previous blog post.

Overall I’m not seeing any major differences between implementing software through the cloud vs other options other than the vast benefits that cloud computing can offer. Benefits of cloud computing range from storage, server, database, software networking, intelligence, and analytics. The blog begins with describing what cloud computing is then goes into detail about what front-end and back-end cloud architecture is along with cloud based delivery.

I was then led to another blog about specifically front-end development as I was not satisfied with what the previous blog provided. This blog hooked me with its first line saying “Front-end developers need to design sites that are engaging enough to nudge the target audience toward a conversion.” I find this idea to be very interesting because it starts to dive into the purpose of front-end development.  In my next post I will discuss where I may see myself in the future and what role I might want to play in the tech industry. There is a point in the blog in which the duties of a front-end developer are laid out leading to an intrigue and wonder about whether this is a niche in CS where I may see myself, in front-end development I feel it might be a role in which I can use a variety of skills/techniques in order to develop myself.

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.

Smells and Senses

I want to focus this blog post not on something that I’m interested in but rather something I think that I should know. I decided to put some more research into design smells, this topic seemed valuable because I have this perception that understanding and looking at code is not a skill that I have yet to developed. I wish to improve upon this, so I found this presentation on code refactoring and design smells that is pretty in depth and it goes into a little more detail about what we had discussed in class. In the class activity we connected technical uses of the word to technical definitions based on our understanding of the common definition. This activity provided a basis for understanding different smells. This led me to find a higher-level presentation on design smells and grasp some level of understanding of what was being discussed. In the video the speaker Sandi Metz suggests that when you can identify a code smell you can then refactor the code to better suite future use. What refactoring is, is the ability to rearrange code without changing its behavior. The ability to look at code and associate information is exactly what I am looking for.

There were a couple of ideas that stood out to me. The presenter offered an analogy that stood out to me that  refactoring is kind of like a recipe. Sandi then provides a valuable resource that maps specific code smells to a reference in Martin Fowlers book , a refactoring recipe that is “curative”  to that code smell. This leads me to another suggestion that it is okay at some level to “own your code smell” if it is working and won’t change in the future. This reference to Martin Fowlers books immediately reminded me of his very informative blog. The book itself seems very interesting to me and could potentially offer a wealth of valuable knowledge that could vastly improve my abilities.

As an avid home cook this analogy spoke to my soul, all this talk of smells and recipes sparked an understanding of code that I was not familiar with. In my journey as a home cook, I have been exploring the ability to make food more creatively as instructed by a transformative cookbook that I have been reading. There is an idea that I have been working on that suggests not following a recipe and relying on your senses and being actively involved to create a wonderful dish. I find that this relates heavily to my journey in becoming a software developer, taking information from outside resources and interpreting it in a practical way all while relying on my senses and built intuition.

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.

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.