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.
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.
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.
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 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. ( https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/documentation/-/blob/main/History.md ) As well as documentation for Docker Compose File Examples ( https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/blob/main/Docker_Compose_Examples.md )
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.
From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.
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.
https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/issues/19
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.
https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/issues/15
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.
https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/issues/17
· 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.
From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.
From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.
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.
So far, I have looked through all the patterns in the book as learning patterns. This pattern is somehow different it shows not a formula for growth but a remedy against decay. It tells us of things to come in our professional lives. It warns of the possibility of professional demands that can crush one’s soul. It tells stories of individuals bravely breaking through barriers imposed by different situations in life.
This pattern may seem unwarranted to the steps we are about to take, moving in fresh to the work force, but I believe it applies just as well now as it probably will 4 or 8 years from now. With the semester coming to an end many students probably had an internship opportunity, but many more probably didn’t. Finding out what makes someone tick can be hard especially with the lack of reasonable experience in different subfields. There is a lot of opportunity out there but not all of it are the best fit. I refrain from saying good or bad because I believe these are relative qualifiers.
Knowing what you want is important and changing your mind about what you thought you wanted is part of the process too. A lot of us will start on the first opportunity that comes out. Some of us may be luckier and have a short buffer to sort through a little. None will truly know what they are handed until they take the first step. But regardless of when and which, we must know the direction we want to take. Even not so glorious opportunities can serve us well as long as there are steppingstones in the right direction. We must watch for the fool stones, and this happens a lot I can say it from personal experience. You may find yourself in a place filled with opportunities that do not apply to you only because systematically maintaining you where you are is of greater interest to your employer and believe me, they will do the dance to have you stay there as long as possible. The author warns for that specifically. I think we are at a better place than the examples the author mentions. These people where stuck for years and the longer you take to move the greater obsolescence in your skill set. We must not wait long when is time to move. Employers have their own interest, and it is perfectly fine and healthy. But so should you have your own interests at heart and if they don’t align, then perhaps it is better for the employer, as well as yourself, to part ways.
From the blog CS@Worcester – technology blog by jeffersonbourguignoncoutinho and used with permission of the author. All other rights reserved by the author.