Category Archives: #CS

Josie’s Notes Introduction

So I guess I have to start blogging now. I never really thought I would be doing this but here I am. This Blog is starting out because of my class CS-348 Software Management Process but who knows where this will go, Anyways that is all I have today… Ciao Ciao

From the blog CS@Worcester – Josies Notes by josielrivas 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 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.

Sprint Retrospective 2

By this sprint, everyone had an idea of what they were doing and what needed to be done. So everyone was on track with required workflow. In this sprint, people started to add issues of their own. I should have added issues I found in this project, but I just discussed with the team members, and they added it. Overall, for this sprint, I have a mixed feeling about it. I felt as if I didn’t do much help to the team, but at the same time I felt like I gave my all to the team. I did solve a couple issues during this sprint.

The first issue I solved was simple enough that I forgot to add it to the project issue board. Logically, it made sense to fix this issue so that the form doesn’t become annoying to the user. Imagine clicking on the input field every time the form loaded. So guest 1 comes and swipes, guest 2 comes then you have to click on the input field, guest 3 comes click again. Doing that over and over again would have been exhausting. I didn’t really notice this issue until I tested the code with card reader. At first, I thought I had to write some method so that the text would automatically focus on the input field. I was lost and had no idea about how to make it work. At the end, I felt really stupid because the solution was simple, and I was overthinking it. The solution was in the HTML input attribute type. All I had to add was “autofill” in the input attribute. Refer to this commit. Here

For the second issue I fixed, it really took the best of me and my time. My goal was to on a click of a button which is in one of the child component in Vue, I had to get the data from localhost, store it as an object then pass it to another child component so that those data would automatically fill the form. Sounds simple and easy. But the thing is, you cannot pass data from one child component to another. So the process was to get data from one child component, pass it to parent component using emit and then pass that data to another child component from parent component using props. Michale had already passed the data from component to component and I thought it would be relatively be the same. I couldn’t be any more wrong. I did everything same as Michale and everything worked as we wanted. Since our API was not fully done, I tested my method using Jsonplaceholder and sent the data to another component. I put the Jsonplaceholder’s ID number as a zip code, and it displayed as I wanted it to be. The major problem was that I was using options:Lifecycle that would assign the data before the form loads, which leads to not being able to edit the form data. Removing the lifecycle and just mounting it to v-model worked, but it rendered the first child component twice in the same page. Other than that, everything was working. I was able to get the data, pass to the form and edit then submit the edited data. I am not really sure how this worked, but to fix the issue of rendering the component twice, I hid the first component when the submit button is clicked. After that, everything worked as we wanted. Refer to this commit for code details. here

On to the third issue, when swiping the card, the input field only picked up the correct ID on the first swipe only. This issue was taken by another teammate, but since he wasn’t able to complete it, I took it from there. After a couple of hours of debugging, I was left with nothing. I understood the code the previous developers left, but I wasn’t sure why the issue was as it is. I started to think that if it worked on first swipe, let’s make every swipe as first one. So the solution was simple. Refer to this commit on line 93. here

This Sprint showed who is really dedicated to the project, who is really passionate to the software developing. It seemed as everyone was giving their 100% effort to the project and were all liking the process. I don’t have a single doubt that we won’t be able to finish this by the end.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Rubbing Elbows

The context of this pattern is that although there are many people teaching you about coding, when it comes to actually developing software, it will be all in your hands. However, the problem is that your productivity has reached a plateau. One of the solution for this is to pair up with another software developer and accomplish a hands-on task together, side by side. Of course, it will be much better if the developer is better than you or has more experience. While pair programming can be an excellent technique for learning, it is a complex activity and is not always an inherently positive experience. However, when used effectively, it is one of the most powerful ways to learn, particularly from mentors. But how do we know that we are improving when pair programming? One of the way to know is that you will feel lost or behind with all the work/knowledge. At first, it feels like you are failing, but it isn’t always the case. It simply means you need to either slow thing down by asking questions, or endure the feeling of being lost and try to pick up the bits that you do understand. The action part of this pattern is to find an open source project to work with your pair programmer. Spend some time working on it each week together on the project. If you lose motivation for a long time, then it is time to change your partner.

When it comes to pair programming, I have done nothing but leetcode together with a programmer for like a week or so. Although I have never done pair programming for a long time, I do always surround myself with better developers than me. But that does not mean it breaks my plateau. I do learn new things here and there, but I have not actually done a project with that knowledge. Now comparing to our capstone project, I am learning new things with this group and project. All the programmer in my team seems they are better than me, so while I am doing my part of the issue for the project, I am also learning what the others did and how it connects with my issue. The problem with me is that I lack to have a vision of a finished project, but with this team and this project I can clearly see what our finished project will be at the end.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Learn How You Fail

The context of this pattern is that you cannot avoid failure. If you never failed, then that means you either avoided pushing at the boundaries of your abilities or has learned to overlook your own mistakes. The problem is that even though your learning skills have improved, your failures and weakness still remains the same. The solution is as follows, seek to identify the way in which you tend to fail and try to resolve them. Accept that there will be some things that you are not good at, or that would require a disproportionate investment of time and effort in order to make a small improvement.

Now for the action part, this is what I liked the most about the pattern. In the programming language of your choice, use a simple text editor to write an implementation of binary search in one sitting. Do not compile or run it. Write all the tests that you think are needed to verify your code you just implemented. Now, go back and re-read your code and find all the errors you think you made, keep doing that until you are satisfied with the code. Make sure you give in your 100% knowledge to it. Then, finally, try to compile and run it. Before you fix all the errors, look over them and try to understand how you could have avoided such error in the first place.

For me, this pattern was really helpful. I wish I had known about this pattern when I was taking a data structure and algorithm analysis class because I really had rough in those classes. I should have done this action part for all the topics in those classes. Such as, post order tree or pre-order tree from data structures or Dijkstra’s algorithm and divide and conquer from algorithm analysis class. I have been bad at so many stuffs now that if I do something wrong, it does not even faze me anymore. But one thing I did that I’m proud of is that, whatever I failed at doing, at the end I made sure I know how to do it the correct way. What I need to work on is to practice by implementing code in a simple text editor without any error warnings.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Sweep the Floor

The context of this pattern is that you are a new apprentice on a project. However, the problem is that you don’t know what your role is in this team. You don’t know how to contribute to the team and help them in any way necessary. The solution is to volunteer for simple, unglamorous, yet necessary tasks for the team. This way, you can earn team member’s trust, and you also get to show the team members how quality of work you can do. The tasks may be such as maintaining the build system, production support, responding to maintenance requests, bug fixing code review etc. The tasks can be anything, but it cannot have any high risks. Starting a core tasks and failing puts you into a bad side of a team, so it is better to start off with an easy tasks and actually finish it to have good relationship with everyone on the team. These short takes benefits the team, but it will also benefit your apprentice because such chores are often skipped in academic courses and by doing them you can fill in the gaps in your knowledge. After all, if no one sweeps the floor, then the glamorous work can’t be done because the team is hip-deep in dirt.

This pattern kind of reminded me of our group for the capstone project. When we first formed the group, I was assigned to the frontend part of the project. I was ready to do the first task from the GitLab issue board, but my main question was how can I convince the team that I can do this project together with the team and can actually make some contribution. In this computer science major, I feel as if I am always a step behind from everyone and have to add in extra effort to be on the same level as everyone else. So to show my skill, my first task was to connect two components and load one component only on click, which in my opinion is not an easy task but also not a hard task and I think I managed to do that, and the team seemed to love the way it turned out to be.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Craft over Art

This pattern starts off with a strong quote by Richard Stallman who states “I would describe programming as a craft, which is a kind of art, but not a fine art. Craft means making useful objects with perhaps decorative touches. Fine art means making thing purely for their beauty”. And this quote hit me right in the chest because I wished I had read this quote way earlier, around sophomore year or so. At that year, I was just trying to learn programming while also struggling. At that time, all I could do was some cool stuffs in my own personal computer’s terminal. There wasn’t any time when I thought I should build something that is useful and also could be used by others. All I had in my mind was how to make this code work so that it looks cool in my own terminal.

The context of this pattern is that I am being paid to build something that will solve a problem of a customer. However, the problem is that although there is a solution, my customer’s problem represents an opportunity to do something truly fantastic and is a chance to impress my colleagues with something beautiful. The solution starts as, the things we build for customer can be beautiful, but must be useful. This pattern is developing the ability to sacrifice beauty in favor of utility if and when it becomes necessary. The more useful a piece of software, the more important it is that the software be high quality. But quality takes time. You will have to work toward a suitable level of quality by repeatedly making trade-offs between beauty and utility. Ken Auer also states a really nice and meaningful quote, “Working on real problems for real people is what hones the craft, not just doing it for self-satisfaction”. The action is to do something useful rather than beautiful. This pattern reminds me of an app I made in operating system class with Professor Shruti Nagpal. For that class, our final project was to make something from what we learned in the class. Since my parents kept on asking me what is the current dollar rate compared to Nepali Rupees, I decided to make a currency converter app for them. The app may not be used by many people, but when I think of something I did useful, that’s all I could think of, and I don’t hear my parents asking for dollar rates anymore.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Retreat into competence

The context of this pattern is that when you realize how little you know, when you get out of your comfort zone and try new things. I think everyone who has done programming has gone through this problem. When you are writing code, nothing works on the first try then you try again the next day, and it still does not work the way you want it to be, at that time you feel like you don’t know anything at all. Then after a couple tries, the solution starts to come to you and everything starts to make sense, then you connect every idea and make it work. Just when you feel like you know everything and move to the new issue/project then the cycle repeats, once again you are introduced to the vast reaches of your ignorance, and you are overwhelmed.

The solution to such problem is to take a step back to jump two steps forward like a slingshot in carnivals. As the pattern says apprenticeship is a roller coaster ride as you thrive to learn new technologies, leveraging your knowledge and creativity to deliver value to your customers but if you compare yourself to someone who knows more than you or is an expert in the field then you will feel terror of perceiving just how little you know of things. A pattern like this is relevant to people (such as myself) who have pushed themselves beyond their ability, where they are constantly trying to learn new things, one after another, and there will be a time when this pattern kicks in. When such things happen, you retreat back to your competence to regain your composure. Take some time to build something that you already know how to build then use that experience to recognize how far you have come, then use that recognition to boost your confidence. For example, pick something self-contained that you know really well and reimplement it to remind yourself of your own capabilities. There is also a way to prevent from overwhelming, you can accept that his pattern is only a short time fix. You can set yourself a time limit. For example, I will refactor this code for half an hour before I jump into making another function or adding another feature.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Retrospective 1

When I saw the assigned group for the project, I had no idea who the people were. I saw the familiar faces, but did not know anyone’s name. On the first day of us seeing each other, we had a good greeting, even though we were missing two people. That day we all just talked about our repository, discord, and how to access them. We also talked about who will be the scrum master, for the project. The day went smooth like a butter.

On to the next week, all 6 of us were there and our scrum master (Vien) already had in his mind what to do for the project and how the planning should be, while all I did over the weekend was sleeping. Our scrum master divided the group into two, Frontend and Backend. I choose to be on the frontend team as I kind of wanted to learn more about frameworks such as Vue, React, or Angular. As I cloned the repository to my local machine, I had no idea what I was looking at, the docker images were wrong, the form for guest info did not open all the contents, the styling of the form was not responsive, and so on. Our (frontend team) first task was to refactor the frontend repo using vue.js and this is exactly what I wanted, I wanted to get more in depth with Vue.

On the third week, our scrum master already put up a lot of issues in the issue board, and I was so happy he did it. There was already a branch called refactor-branch which was created by our scrum master, and it had two components inside it. Frontend had 2 separate parts to complete. When a page reloads for the first time, it should only show an option for guest ID and nothing else, once the guest enters the ID, the rest of the form should display. Our main goal for that week was to display the rest of the form when the user clicks the submit button. One of my teammate refactored the guest login while the other teammate did the rest of the form in vue.js, and I connected both of their work/component in the main app.vue.

Fourth week, our side of the project were starting to look well, but there were still lots of work for us to do. Although I connected the two components together based on the button, it had its flaws, the form opened and closed once the user enters all 7 digits of their ID. To make it short and easy to understand, the button acted like a switch for a light. If a user clicks once, the form shows and when a user clicks again then the form hides plus the form stayed there even if a user removed their ID. It was a little success from my side, but in general, It looked lame, and I felt stupid. In order to fix that, I made little changes in the id-input component, and I was able to get the form to show only once and when a user removes even one digit from the search input then the form hides until he/she enter all 7 digits again. link.

5th week, Everything was going smooth. Teammates were adding small little important details here and there but at the end, who would want to use a form that has no style right? So I took a task to style the whole form which was left by previous students. And at the end I was able to get the form to look decent, although we might change the style or import one from the existing website.

At the end of the sprint, when my teammate displayed the form in a larger screen than my personal device, I noticed that the form stretches with the screen size. I managed to make form adjustable in phone screen, but I forgot about the screen that’s bigger than my computer, so I fixed it by setting a max width here.

Overall, I think our spring went well. The frontend side did a pretty good job and I when I looked over all the commits in the backend repositories, I noticed that they have been working even harder than the frontend team. In my opinion, I think it would be better to have only 2 people on the frontend and have 3 people for the backend while scrum master looks over all the infracture/review for the tasks. As for myself, I need to discuss more with my group about my work and share everything. With all due respect to my teammates, I don’t think we could have done this well without our scrum master (Vien) who have a good vision and I can tell that he is really putting all of his time to this project. Overall, I’m glad I’m working with this amazing team.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.