Sprint Retrospective 2

Hello,

welcome back.

  In todays blog post I will be writing about my second sprint developing part of my universities food pantry website. My team recently finished the second sprint, during which we focused on developing basic skeleton code with basic functionality in place for future development. I and another teammate worked on the front-end development of the project while one classmate worked on the backend and another person worked on the IAM (Identity and Access Management) Communication among our group occurred mainly through GitLab and discord. At the beginning of the sprint, we mainly had documentation on the concepts we were to begin using and now we have progressed to having multiple branches of skeleton code developed.

During the first sprint, I had begun researching REST API and OPEN API with intentions on developing that area of the project. However, due to personal health reasons I was unavailable for slightly over two weeks and was not sure if a return to the project was possible. Due to these unforeseen setbacks, my team had to switch up task assignment. When I returned, another teammate was tasked with taking on the API design, which meant I was to take on the checkout guest front-end. This set me back even further than anticipated because now I had to switch to doing a completely different part of the development process. I began researching and completing tutorials on Vue.js which ended up being quite a bit to take on whilst trying to develop something presentable with Vue.js for the first time. I learned quite a bit and am happy with the progress I made as a student. I take pride in the development of the Checkout Guest front end thus far. It is linked below under the updatedFunctionality branch:

CheckoutGuest

For the second sprint, our team faced the challenge of applying the knowledge/concepts we gained earlier studying Express, Vue and keycloak and applying it. I was uncertain of how to approach the input validation of the student ID field but ended up modifying some code for an input field. I specifically spent some time verifying that the submit button was disabled unless an input of seven digits was entered. I assumed we would work with the WSU pattern of blue and yellow and designed in this way though I was uncertain of specific design layout and appearance that other teams planned to develop. A member of my team had contacted other teams with questions regarding appearance and then refactored according to the newly acquired information. A small hiccup with practical application is to be expected when developing with new frameworks but I still think we worked well despite the initial chaos of using these new frameworks, especially the combination of multiple frameworks.

To improve as a team, we should become more comfortable and fluid working with these new concepts and frameworks by continually practicing them daily in small increments rather than in large infrequent bursts of use. This would help to solidify these new concepts in our minds and keep them fresh. To improve as an individual, I would benefit from checking GitLab daily rather than a few times a week. This will help me to stay more on top of how the other members of my team are progressing and coordinate with them on challenges or setbacks either of us face before they become a major setback.

Overall, our team is doing quite well despite the setbacks. I am grateful to have the opportunity to work with such excellent developers who have great communication skills, are not afraid to ask questions. We work well as a team, and my teammates have been very cordial with any questions or comments about the design process outside of class hours. As someone who grew up dependent on food pantries like this one, I am honored to be able to dedicate my time to the development of this project.

Thanks for taking the time to stop by.

  • John Simolaris

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Nurture Your Passion

The key focus of this pattern is founded in the all too familiar scenario where you fundamentally enjoy the subject matter you are surrounded by at your work; however, the work itself gets in the way of your passion for the subject. An example of this would be suppose you are really passionate about software design and you enjoy taking your time making a solid product using good code. While that is your passion, and rightfully so, you may find your job is more concerned about functionality and speed. They might prefer you create shoddy code in a quick amount of time that works, rather than doing the job properly. As you might imagine, if your goal was to be employed to create solid code the way you always have, this might hurt your motivation.

The proposed solution to this predicament is to search around at your work and find something that properly interests you. Involve yourself in it and put in as much time towards it as possible. Outside of work, do the same. Find and work on interesting things that satiate your passion. I would continue the prior example to demonstrate how the solution works, except that its a pretty good example for why it doesn’t. I’m sure that in the right situation, the proposed solutions are good options. In situations such as above, however, it isn’t really possible to change what you do at work to better suit your passion. If you already work in software for the company, and the software isn’t up to your standard, where in the company can you go that is up to your standard?

Many companies have a fixed structure. Often, if you attempt to either move yourself around or change the structure itself, it is easier for the company to simply let you go and find someone else. That’s one of many problems that come from jobs being rare and workers being abundant. If jobs had to compete with one another for workers, overall conditions for workers would improve. As a quick aside: in my opinion, if the government weren’t trying its hardest to support major corporations (due to being bought out by them) and got rid of regulation that solely hurts small businesses, maybe in a more free-market economy where almost anyone can start up a company jobs could be abundant and would have to compete for workers. Speaking of idealistic views that might not actually stand up in real life, a second component to the proposed solution is to work on personal projects in your free time.

This is similarly not a valid option for many situations. Often, people simply do not have the time to work a full-time job and fulfill other responsibilities. Bringing up my example once again, you can work on quality software all week long in your free time, but writing code you know is bad and that you know could be better with just a little bit more time will always drain on you. Sometimes and for some people, it can be pretty easy to work on something you don’t enjoy. It can be easy to create something worthless and bad, but it depends on the situation and, more so, the person in particular. I personally find it extremely hard to work on things I don’t care about; even if I just have to do it badly.

It can be hard to have a strong passion for something and then have other people not allow you to do it. It isn’t even a matter of them letting you do it; it would be enough for them to do nothing. But often times, they directly work to oppose what your soul wants you to do. That said, you can’t just vilify them for it. You ended up in a bad situation but in the previous example, for instance, you wouldn’t be stuck. Maybe you misunderstood what they want or maybe they misled you. But if it’s a matter of your soul, so to speak, you can always leave the job. It isn’t always that simple; we have responsibilities and bills to pay. That’s why I personally believe that if you have the opportunity, build up your savings and investments. Sacrifice some of your standard of living now so you can afford to make a change like this in the future. Do your best to prevent yourself from getting trapped in life.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Record What You Learn

The section “Record What You Learn”, found in chapter five in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye, opens with the common saying “Those who do not learn from history are doomed to repeat it”. This section focuses on the practice of keeping some sort of diary to record what you learn throughout your career. Doing so has the benefit of creating a useful resource that can be referred back to at any time. It also has the added advantage of finding like minded individuals by finding common ground in what the both of you have learned. Both authors see these benefits since they also keep records of what they’ve learned. Oshineye uses two instances of the wiki, one public and one private, to share lessons he’s learned with others and give honest feedback to his own progress respectively. Meanwhile, Hoover kept a text file of references and quotes which eventually grew to such a size that he decided to publish it online for others to use. What separates this design pattern from another such as “Share What You Learn” is that “Record What You Learn” focuses on preserving the road you took to mastery so that you or others might learn something new from it.

While I haven’t reached mastery yet, I do generally try to write down what I learn. Admittedly, I partly do so I won’t fall asleep during lectures and I also often don’t go back to older notes. But I still notice some of the benefits like how generally more of the material sticks when I write down notes since I’m paying more attention to the material writing it down. And most of my older notes still exist, either digitally in my hard drive or physically in a stack of note books I keep inside box in the corner of my room. They’re still around and I can access them at any time which is one of the main benefits to “Record What You Learn”. So, when I’m talking to someone and they bring up a concept that I somewhat remember, I can open up my notes and refamiliarize myself.

From the blog CS@Worcester – Rainiery's Blog by rainiery and used with permission of the author. All other rights reserved by the author.

Nurture Your Passion

This week I decided to talk about Nurture Your Passion pattern. I think this pattern apply to a lot of people in different direction.  Our success comes not so much from what we do, but how well we do it. It also illustrates that regardless of your job or your position on the company ladder, you can be successful if you have passion for your work. Regardless of your current job bringing passion to your work can lay a foundation for success. Not just success in your current job, but success for every rung you want to take up the company ladder. You may hate your job now, but the attitude you take towards it can play a pivotal role in your career.

The book describes a case where You work in an environment that stifles your passion for the craft and what solution you can follow.  It is hard for your passion to grow when exposed to such hostile conditions, but there are some basic actions you can take to sustain it. Find something at work that interests you, identify it as something you enjoy, and pour yourself into it. Join a local user group that focuses on something you want to learn more about. Immersing yourself in some of the great literature of our field can carry you through the rough spots when your passion is in jeopardy. Moving into an organization that offers career paths congruent with your own can protect your passion.

These are some good advice you can follow. It is hard to find everything in one place but at least if you do something you like you are going to be happier. Remember passion is an emotion, a state of mind so the first thing you have to do is motivate yourself. Turn to another emotion to find the motivation that you need. Once you have the motivation you can apply the passion. Remember it is not about how you feel about your job. It is about putting passion into your work. Maybe you need to learn new skills, or you just need to fully engage yourself in your work.

References:


Apprenticeship Patterns by Adewale Oshineye; Dave Hoover

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Summary

In this sprint, I mainly did the following things:

What Worked Well

This sprint, I worked a lot with Marcos on the backend. Overall, I think that we worked well together. This was the first time I spent most of my time working with someone else and it went well. We didn’t really run into any issues because we made sure to be careful with git. I now see why its recommended to add new features on a new branch. We were able to split up the work and stay in communication.

I also had a decent understanding of OpenAPI and Node during the work. It felt like I knew what I was doing in a sense.

What Didn’t Work Well

I think the team overall just had a lot to do outside of this class. I was able to get done what I needed to during class but if I had to work on things outside of class as well, I wouldn’t have had the time and the motivation at the same time. I think that overall as a team we didn’t get as much done as I expected because people were busy with other classes.

We also still sometimes feel lost and don’t really know what questions to ask. This applies mostly to the details of the design or implementation. However, it was a lot better than Sprint 1.

What Changes Could be Made to Improve as a Team

We need to get used to typing out more info for the cards. I’ve also noticed people aren’t always moving the cards they’re working on into the “doing task” column. Besides that, I think as a team we’re doing pretty well. We work together when its necessary or convenient and manage our own work otherwise.

What Changes Could be Made to Improve as an Individual

I could dedicate more time to this class overall and I could ask teammates if they need help rather than always waiting for them to ask for it.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Software Quality Assurance and Testing Blog Post #4 (Program Graphs and DD Path Graphs)

The latest topic in my Software Quality Assurance and Testing class has been learning how to read and write program graphs and DD path graphs. We also have been learning how to make DD path graph tables that correspond with the DD path graphs and the program graphs. Our most recent assignment was all about these topics. With the amount of work we have put into learning these, the assignment proved to not be too difficult for me. It is generally easy to know how to read the program graphs because pretty much every node corresponds with a single line of code in a program. Where it gets tricky is when the program has loops and if statements. Converting to a DD path graph from the program graph is also not too hard if you know what you are doing. A lot of nodes from the program graph can be clumped together into single nodes (like all the instance variables for example). Lastly, creating the DD path graph table takes in account both the program graph and the DD path graph, but again is not too difficult to read or fill out. The amount of time we have spend on these topics in class while doing in-class activities has helped me tremendously, because looking at the graphs without knowing what you are looking at can be daunting and confusing. As much as I enjoy being able to understand the graphs and make them if I want, it is even more enjoyable knowing that these topics can all be used in real life. It is always very reassuring when I try to research topics from class and they seem to be very prominently used in the real world with lots of examples and helpful sources to teach me about them. In this case, these topics all seem to be used a lot and also seem to be very helpful for those who have used them before to study how a program could be working (or how it could be failing).

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective Blog Post

This second sprint has been a bit better in terms of actionable steps; this was aided greatly by the mock front and back end. The mock allowed us to test configuring a realm to a container locally which was the floor for proof of concept. Unfortunately, the lack of architecture made further progress confusing as I didn’t understand why all images couldn’t be on same container network. After it was determined that the architecture called for further subdivision, it became unclear what microservices should be on which image and/or network. For instance, it was more or less determined that Keycloak should be on its own separate container (presumably with WildFly) but at the beginning of sprint I wrongly believed, based on previous internet searches, that NGINX should be on the same image as Keycloak but this was later discovered to be unnecessary as the mock front end contains NGINX within our system.

On that same note, the task breakdown and codification into issues for the respective boards suffers from an incongruity where ignorance of the matter begets ignorance in the approach and then future work is inaccurately reflected in the process. This isn’t necessarily an issue with the approach as whole but it seems as though, for the past two sprints, this unfamiliarity with the microservices and their implementation into our architecture forced me into a series of micro pivots which quickly evanesced away from the originally declared issues. If the goal of scrum is not to constantly be inundated with creating issue cards, updating them, and closing the now obsolete ones, then perhaps it would behoove us to reconsider the amount of research time necessary or have a much more closely-guided approach to issue construction. If this rapid pivoting away from cards is acceptable (and their grades reflect this) then that’s not particularly bad news for students. However, we have to be honest with ourselves and have the hard conversation that Scrum in this setting does not accurately map to what Behr, et al. would refer to as WIP (work in progress).

The low-hanging fruit of constructive team feedback would be the necessity of more frequent external meetings. It certainly was not for lack of trying; the most charitable reading of the situation was that I found there to be no strong consensus on when the team schedules would align. We also would have benefited from more frequent contact internally. Barring all real-world, unforeseen, obligations that took team members away from us the scattering of the team into groups caused our reviews to be staggered resulting in the loss of two full class periods of collaboration. My prescription for this would be that those who come after us should successfully drill down on establishing a running prototype before splitting off into the other groups.

My individual criticisms to my work flow largely still touch on the externalities I’ve lamented in a prior blog post but, if I must touch on them briefly, they’ve stayed mostly the same. It’s quite apparent that certain teaching staff in the university have struggled to pivot to remote teaching and, if I’m to attribute to ignorance and not malice, they seem to have bequeathed those struggles to their students. To those teachers I would like to remind them that Monday holidays are not a surprise and certainly not an invitation to delegate away your teaching responsibilities because you’re lagging behind curriculum milestones. If these teachers cannot grade in a timely manner, then my deepest sympathies, but please do not complain that the bulk of your students keep getting concepts incorrect and you have to re-grade their assignments and/or assign extra credit to help inflate grades. I’m a commuter student with one semester until graduation so I will stay here at Worcester State; if I was a commuter student with two semesters left, I would have transferred out.

https://gitlab.com/nanuchi/techworld-js-docker-demo-app
When paired with their “Docker Tutorial For Beginners” has been an invaluable resource to teach myself Docker and use continuously as a reference.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

Sprint #2 Retrospective Blog Post

The second sprint of the semester started a bit rough for me with my surgery, but I was able to get most (if not all) of my work done throughout the weeks we worked. I was able to help a lot with creating the cards and giving them descriptions at the start, and then the first week or so of the sprint I was very busy. After this initial period, I was able to catch up on my work and get a lot done. I was primarily in charge of getting an updated example of our front end based on an old one that was provided to us from previous years. For this, I used google forms, but in the end I had to take screen shots of all my work and upload those in case the forms document that I created got deleted or lost. This will be helpful for our team and for any students working on this project in the future. There is still a bit of work I need to do on this example to make it perfect for what we want, but this has been added as a small task for me to complete in the next sprint. Overall, our entire team did very well getting a lot done, and although I did not get the backend coding assigned to me, I was able to lend my insight and some advice and code to my teammates. This sprint was a lot different than our previous sprint primarily because it had less to do with learning how to use cards and work in a sprint and had more to do with getting real work done to further our progress on this project. I presume that the next sprint will be even more important, and we will have a lot of hard work to do to try to complete all or most of our cards. Some things that worked well this sprint were our team’s hard work ethic for getting everything done and our ability to communicate well and let each other know what needs to get done and what we need help with. For this sprint, we actually added a member because of the IAmSystem team splitting up after the first sprint. This was not a problem at all and in fact was more helpful because we were able to get even more cards completed over the couple of weeks we had to work. If I were to change anything or expect anything more from the next print, it would be that I personally will be able to get a lot more work done earlier in the sprint without having a surgery as a distraction. I am excited to see how far we can get on this project by the conclusion of this semester, and hopefully we will be able to get a nice looking and working project by the end. This whole experience has been great for me so far for learning how to work in groups for sprints, and I know that after college I will run into many projects where I have to work like this.

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Erockwood Post #1

In my operating systems class, we are learning about all of the important roles the operating system has in a computer. There are many managers that the operating system itself manages to keep everything running as smoothly as possible. One thing I am most interested in when thinking about operating systems is concurrency and multithreading. Most tasks are done serially, which is to say one at a time. This worked well back in the day when most computers had only one or two cores. Nowadays, however, CPUs usually have 4+ cores, and if all tasks an operating system does are serial, then 3/4 of the CPUs resources are not being utilized. This is where concurrency / parallelism / multithreading comes into play. With them, we allow programs/tasks to run simultaneously, using more than one CPU core, to do more work in less time.

The only problem with this is trying to write the programs/tasks to take advantage of more cores. I know when I first tried to create and run a simple C program that would use more than one core, it was very confusing on trying to have everything be worked on by a separate thread. Eventually, after some trial and error, I got it working, and it slowly started to make sense on how to write this type of program. In doing some very simple calculations like I was trying to do in my example program, there is not much performance to be gained from multithreading the program, but in much bigger programs with bigger calculations to be done, there is definitely some time that can be saved by multithreading the process.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

Learn How You Fail

Failing is unavoidable and it happens to everyone at some point. In reality, anyone who has never failed at anything has either stopped challenging themselves or learnt to ignore their own mistakes.

Your skills are progressing but you are still failing and have some remaining weaknesses. So instead of drowning in a sea of self-pity over previous failures, develop some self-awareness of your own patterns, habits, behaviors, and other factors that play a role in causing you to fail. When you are aware of yourself and the things that mess you up, you give yourself the option of either trying to solve the issues or cut your losses. You cannot succeed in all, and recognizing your shortcomings is critical because it allows you to actively recognize distractions and concentrate on your goals.

Accept that there will be certain stuff you aren’t very good at.

Once you learn to accept your failures you can set realistic limitations on your goals.

Often times I get irritated by the fact I keep failing, but if I accept it, my failures become learning opportunities. I can then seek out guidance and learn new skills from someone who knows more about code than I do. It is hard, honest work to admit your shortcomings and it will take a lot of failures, but I am confident that eventually, it will all be worth the frustration.

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.