This is my first post for CS-348 Software Process Management.
From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.
Category Archives: Blog
CS-343
This is my first post for CS-343 Software Construction Design & Architecture.
From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.
“NICE” Sprint 3 Retrospective
During our third and final sprint, we had a clear idea about what we wanted to achieve with our application. The first two splits helped create a foundation that allowed for us to propel much faster and efficiently compared to before. After spending the last sprint working on the docker container for our group, I wanted to contribute in a way that would be helpful to the react team. I ended up creating issues for myself that were more in line with the front end side of things that the react team had not really touched upon. I first decided to clean up a lot of the code from the react team, there were a lot of styles that were repetitively used by the team so I managed to implement a style page where certain style could be called upon instead of written out when being applied to something. The next thing I tried to tackle was an interactive page for users to select which kind of test they wanted to practice. This was implemented with a side scroll feature that was imported from the react-native-gesture-handler where I was learning the design parts of how things would look based on the style I would give it. I was also able to take images and icons as well to apply to the home page and menu screen which gave it a much better appearance to the eyes of the user.
As a team I felt as if this sprint all of the puzzle pieces finally came together. The react team was working cohesively together where as the others who did not work with them originally were able to go back and forth with them to push an pull code without being out of sync. The team cohesiveness really brought out the best in one another as were we able to divide issues into more manageable ones and we could really see the final product coming together.
With the docker team finally being able to assist the react team with the application as a whole, we were constantly running the application and testing it, and that led to a lot of discussion of things that needed to be fixed or added to the app. This would lead to us effectively being able to help one another spot mishaps and expedite the results we so eagerly wanted. Although we were not able to produce a functioning writing portion, we were able to create a placeholder for it that was substituted with a input on the they keyboard from the user.
Individually, I felt as though this sprint was one were I pushed myself the most. Maybe it was because the semester was coming to the end or that the application was seeing growth, but although I was lacking in basic knowledge of react native, I wanted to be sure I contributed more to the application and pushed myself to learn more. The only issue that I had with the sprint was that I wish I was able to be part of the react native team prior to this because I know I could have contributed more than what I already have. Seeing how fast I was able to grasp things, maybe I should have stepped up before and take on that challenge because I had a lot of fun during this sprint.
From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.
Sprint Review #3
This sprint was the worst one for me. The team did great job, it’s just I, who did not did much job in this sprint. This sprint/weeks of this semester was a roller roaster for me. So many projects to do, presentations, assignments, essays. Every professor was pushing their assignments. I learned a valuable lesson this past weeks and it was a “stick with one capstone my friend”. I took two capstones as I liked both software developing and data analysis. It is not that, I liked one capstone and dislike another one, it is because of the amount of work. I think it is okay to take two capstones if you are taking only 2-3 classes so that you can only focus on capstone classes but a semester with 5 classes, 4 of them are CS courses and each classes having final projects was a hell for me.
As for the sprint, I did not do much work than just cleaning up some code. You can find the commit here. In the console of the browser, there was an warning saying the request to HTTP request may not success every time. So I simply added a try catch to get rid of that annoying warning. So now if we make a bad request to HTTP then the code will console log an error. Another reason I added try catch is that, suppose we were to use this program in real life or real POS or anywhere where this application will be running and if there is a bad request then the application will crash. And nobody would want to restart the application every time. With try catch, the application will console log the error and keep running. That is all I did for the sprint. I did not put much work to the team and I wanted to do more but with tight schedules, I wasn’t able to do much. There was able another error with my device, the docker image kept failing for my MAC while it worked for the other devices of my team mates who had windows. I had that issue until my scrum master told me to add a timeout in the docker file which did fix the issue but then it was pretty late. It was my fault for not talking about it in meeting or in discord group chat. I was responsible for getting in touch with another group about key-cloak but I never had time to.
Final thoughts: Front-end wouldn’t have been success without Michale Friederich. He did all the integration between back-end and front-end. If I were to do that then it would take me longer. So hats off to him. Everyone in the group did an amazing job throughout the semester. I have read everyone’s sprint review blog and they are putting in the work more than me. If it were to be different team mates then I don’t think we would have finish this much of work at the end of the semester as everything was new to us. Everyone in my group had a great vision of what the project should look like at the end and we delivered it about 95% of finished application. The next group who will take over after us will just have to clean up the code, connect with key-cloak etc but it will not be as messy as it was when we first received the application as we had to reformat everything. Overall, I was paired with talented developers and I am glad I paired with them. Happy Coding!
From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.
The Long Road Pattern
For this week’s apprenticeship pattern, I did a reading on “The Long Road”. The Long Road pattern is about your future. In this pattern it talks about trying to imagine yourself 10 years, 20 years, or even 40 years from now. They want you to think about that and possibly write down a summary of your profession. By doing this, it will enable you to think how you would want your professional path to be like and allows you to plan how things could go. The problem in this pattern is that you want to become an expert in what you want to do however, things may get in the way like that such as promotions and just always picking the highest paying job and by doing this, it takes away the goal you had originally which is to do something that you enjoy doing but instead doing jobs that in reality sucks.
My initial reaction to this, is that it is an interesting pattern to read about. It is interesting because I never thought to look past 5 years into the future and just thinking about the future and where I want to be in general. Obviously, everyone wants to make six figures, but the main goal is to make that much by doing something you love or enjoy doing. After reading this pattern I did take a moment to think about where I would like to be down the road and it made me realize what I really wanted to do with my future. Of course things happen, and the future isn’t exactly set, but it gives me a good idea of what I need to do and what I have to do to accomplish it.
The pattern has changed the way I view my profession because I never thought about needing to take a step back and think about the distance future of where I would like to be. Do I still want to be programming all my life or would I like to do something different by the age of 40? It was an eye opener to me because it really allowed me to set goals that I want to achieve by a certain age. Sure, programming is fun and all but there’s much more to life than sitting around a desk and creating programs and such. I want to create memories that will last a lifetime and explore the world. If I can find a career that would enable me to do that then that would be the ideal job.
From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.
Third Sprint Retrospective
Reflection on what worked well and didn’t work well
After meeting for the Sprint Retrospective with my team as a whole, I can say that the project is progressing well. The flow of group work has improved more since everyone works together much more effectively. The front-end and back-end development teams have made significant progress towards the project. The backend is pretty much complete at this point and the frontend is pretty much there besides a few minor things. We don’t have any major programming problems coming off of our last sprint, just a few potential bug fixes and cleaning up to do. Finally, after looking back at what we did, we made it easier to run the servers, since in the last spring we had to run things one at a time, however now it will run all at once, making it more efficient. During this spring we also cleaned up a lot of the coding and did some minor bug fixes. The backend is pretty much completed now besides testing. We just didn’t have enough time for it, it would have been something we would have done if we had another sprint left in the semester.
Reflection on what changes could be made to improve as a team
The team worked great. We still have everyone on their original development team. The ones at the back end remain at the back end and those who worked on the frontend stayed on the frontend team. Both teams for this spring, started to run out of things to do since everything was either completed or almost completed at this point, or there wouldn’t be enough time to work on a new issue. From the way the meeting went, everyone was able to communicate all the problems they had with each other, and no one was afraid to ask if they needed help. For our last sprint, I would say that there was such an improvement comparing to the beginning of the semester. Everyone was comfortable with talking out loud, helping one another, and overall, just great teamwork.
Reflection on what changes could be made to improve as an individual
From my point of view, the sprint was very good. Since we were running out of things to work on the backend, there wasn’t much to do. I worked on changing the port numbers for the backend to be between 10350 to 10399. Help change the datatype for household members. As well as combining docker-compose for the backend. I worked with colleagues Jared and Vien on these issues and other issues that we had on the backend since there wasn’t much left to do for the backend. Same as the Sprint, we were able to continue to learn more from each other. In this final sprint, I would like to say that overall, I became a better programmer/ developer, and this was a great experience to be able to work on large project in a scrum environment. I was able to become more confident in my skills and also became better with communicating with team members.
Combine docker-compose Backend
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/34
Update Household Members Datatype
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/api/-/issues/12
Update Backend Ports
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/36
From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.
Retreat into Competence Pattern
For this week’s apprenticeship pattern, I did a reading on “Retreat into Competence”. Retreat into Competence pattern about feeling overwhelmed, realizing how little you know about or taking on a big project and things may not be working so well for you. In this pattern it talks about how you should “pull back and then launch forward like a stone from a catapult”. What this means it to retreat to a zone where you’re comfortable with and once you feel ready, you’ll be able to launch yourself even further than before you might have felt ‘stuck’. An example I found from this pattern is pick something that can be self-contained that you know really well and stick with it, by doing this, opportunities will emerge, and it will allow you to capitalize on those opportunities and you will end with great gains.
Unlike my other blog posts, my initial reaction is not quite the same since I have yet to experience this. The closest time I ever felt overwhelmed is just the pressure of trying to find a job by graduation. Its not exactly related to what this pattern talks about but the same concept. For me, it was a matter of constantly getting rejection emails from companies, so I took a step back to look at what I may be missing. Once I was able to go over my resume and qualifications, I started to reapply and now I am starting to receive multiple invitations to take coding assessments and scheduling interview dates. This pattern goes hand to hand with ‘Expose Your Ignorance’ and ‘Confront Your Ignorance’.
The pattern has changed the way I view my profession because I never thought about needing to take a step back in programming. Maybe because I never ran into a situation where I needed to? However, after reading about this pattern I started to reflect on the things I’ve done so far and what else could I do to improve my programming skills and knowledge. I am also trying to figure out what I am really good at so I can focus a little bit more on that skill and work around it so when the time comes and an opportunity presents itself, I will be able to capitalize on it.
From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.
Apprenticeship Pattern “Retreat Into Competence”
This apprenticeship pattern describes how we should approach difficulties that we encounter along our way of being an apprentice. There will be times when we are working on projects and are faced with difficult challenges that we don’t know if we can overcome, and there are ways to get around this. In the future we will try and expose our ignorance to learn new things, but in doing so we might take on more than we can handle. In doing so, it is okay to take a step and work on something else. Sometimes taking some time away from what you’re struggling on will help you in the long term. It is important that once you take that step back that you then take two steps forward and use that momentum to better yourself. Taking a step back might feel as though you are retreating into failure, but when you work on something you’re comfortable it also adds to your expertise in that area. This then leads to needing to grow as a software engineer and having to learn new things. What we must also remember is to seek support from our mentors and use them to help us become better equipped with handling these situations.
What I’ve taken from this pattern is that taking a step back from what we’re uncomfortable with okay. Sometimes it is okay to go backwards in order for us look back at what we’ve preciously done, then use that to our advantage of progressing forward with our skills. Growth can be looked at from many different views and that’s what we can take from this apprenticeship pattern. There is nothing wrong with facing failure head on, but it’s about how we bounce back that will make us better software engineers.
This pattern has reminded me of experiences I have had in my life. There have been times where I have been put into situations at work where I was required to do work I was unfamiliar with. In doing so, I reverted back to completing work I knew I could do, and once that was done I was then forced to work the things I was not too sure about. In this situation, I then reached out to engineers and other people who could assist me in my work. This then helped me to better understand how to approach this new situation and helped me gain knowledge and experience in completing it later on without the assistance of others.
From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.
The Deep End Pattern
For this week’s apprenticeship pattern, I did a reading on “The Deep End”. The Deep End is all about growing your skills, confidence, and your portfolio. At times you may feel as if you need to challenge yourself with bigger things such as projects or complex tasks, etc. This pattern tells you to literally jump in the deep end. For example, if you were offered a high profile job, then grasp it with both hands and take it on a ride. However, this does impose some risks because you could fail. Even if failing does happen, and be prepared if it does, recovering from a failure will opens many doors that those who are scared to take risks will never see.
My initial reaction after reading this pattern is that I can relate a lot with what this pattern has to say. I am constantly applying to jobs and some of them have requirements that seem to be out of reach with my portfolio that I have built up. Some descriptions of the jobs I see to me, makes me feel like I would have no idea what I would be doing, however I still apply to those jobs because I know I am more than capable of learning and implementing what I learn quickly and with accuracy. The reading was quite interesting and very useful. It is useful because it allows me to feel like I am not alone in these types of situations and its interesting because it talks about the many ways of how to get through it. It ties with other patterns I have talked about and mentions finding a mentor and just being brave and confidence.
The pattern has not changed the way how I view my profession because I know that many job postings will always have some sort of description to make the job sound harder than it is, and even if the job is hard, you can always learn and ask questions. I know that if I fail to get an offer, that means that I am lacking something, and it allows me to know what I need to work on. I am constantly practicing my skills and working on side projects to help myself get a good grip on how each technology work to ensure that I have the proper skill sets to tackle these types of problems when I eventually start my professional career.
From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.
The Deep End
For this week’s pattern, I decided to go with the deep end. The last pattern I wrote was about rubbing elbows and that pattern was all about how you have reached your plateau of your skills and how to get out of it, while this pattern “the deep end” is the other side of that plateau where you begin to fear that this isn’t a plateau but a rut. On a plateau, you consolidate your skills through diligent practice in order to attain the next level while in a rut, your bland competence eventually decays into mediocrity.
The problem is that you need to grow your skills, your confidence, and the portfolio of successful work. Talking about successful work, when I sent my resume to a mentor/friend to review and ask them for their opinion about how my resume is, he said my resume will not get me anywhere. I had decent projects such as discord bot, android app, website, etc. I thought this much project was enough to set my foot into IT field, but my friend asked me one question which left me speechless, “the projects you built, how has this helped you or anyone else?”. At that moment, I realized that I have just been wasting my time. My projects have done nothing. It was solely built for my own interest, and it had no impact to anyone or not even myself. It didn’t have any positive results where it catches recruiter’s eye. I began to think that I need to challenge myself with bigger things, bigger projects, larger teams, more complex tasks.
The actions are to ask yourself a question such as what is the biggest successful project you have eve worked on in terms of lines of code and number of developers. What is the biggest codebase you have ever built on your own?. The answers to these question will show you other dimensions of project complexity and other ways of measuring your projects. Use this metrics to measure every project you have ever been involved in and draw a chart. After a while, you will be able to use this chart to track down where your career is heading and even start to make choices based on the chart.
From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.