Category Archives: CS448

How to Learn about New Tools

The second Apprenticeship Patterns pattern I looked at today is “Confront Your Ignorance”.

This pattern explains how to improve your knowledge in areas you aren’t as experienced in. The pattern also provides possible drawbacks of focusing too much on self-improvement.

The “Context” and the “Problem” sections of this pattern are relatable to me currently. I can clearly see that I have a problem with my knowledge of Angular and I need to learn more about this in order to develop frontend applications. I do somewhat disagree with the part of the problem area that says I “do not know how to begin”. I think at this point I have a decent idea of how to learn about new tools. Although maybe it is correct as I have still yet to feel like I have a good understanding of Angular after trying to learn more about it.

I do like and use both of the suggested methods for learning about new tools. Usually I like to read documentation and introduction guides on a tool’s website, but I also like to follow along with example projects. Additionally, I have found that watching a video tutorial series (mainly on YouTube) on a particular topic can help a lot with learning about something new. This is how I learned about a lot of the backend tools my team used this semester and I am especially a fan of the YouTube channel one of my teammates found. This suggestion is something that I feel should be included in this pattern as I have found this method to be one of the most valuable ways of learning about new tools, especially if there isn’t much documentation for it.

If I had to pick only one thing to learn more about it would be Angular. This is something I have consistently been trying to learn about for a while, ever since I first learned about it, and it has been something I’ve tried to improve on this semester but I am still not satisfied with my knowledge with this tool.

I did find the provided downsides to be the more intriguing part of this pattern as these are points I wouldn’t have thought to be in a pattern about how to learn new skills, but they do make sense after reading about them.

I do think that this pattern provides some good general information about learning about new topics, but for me I wish it was a bit more specific as I find that I was familiar with most of the information provided in this pattern about learning about new tools.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

The Value of Asking Questions

This morning’s pattern in Apprenticeship Patterns is “Expose Your Ignorance”.

This pattern helps explain to early developers how to get over their initial lack of knowledge in the field by asking questions and seeking out knowledge and the importance of doing this instead of pretending to know everything.

To me this pattern and especially the “Problem” area feels very relatable right now with where I am this semester, especially with another attempt at learning how Angular works.

I do find that this pattern provides me with some valuable reassurance, and it is more comforting to know that this problem happens to other people.

Lately with my work this semester I have apparently been following the advice this pattern gives and trying to ask others in my group for help when I don’t understand something that I have been trying to do. This is important in our group, especially as different team members in our group have their own areas of knowledge from what they’ve learned this semester. Reflecting back on this more I wish that I asked more questions (especially during meetings) and focused more about how something works instead of just the solution as this would have had a far greater benefit in increasing my knowledge.

I agree with the idea that answering questions helps to understand the problem better. I can think of many times this semester where I either asked questions that helped find errors in something or when answering someone else’s question made me think more about it.

I do like the idea that the “Action” section presents, although it does feel somewhat exposing to visibly have on display things I don’t know. I am trying to think of a good digital place to put something like this, perhaps on my GitLab account. As I’ve probably alluded to in my posts so far, I think my top items (although this isn’t five items as the pattern suggest, these are things that are particularly holding me back) with my current work would currently be: Angular (and specifically forms), HTML, and Jasmine (this is especially a rather new one for me). I would like to refine this list some more and pick more specific topics to work on learning in each one of these broader items.

This pattern provides helpful knowledge and helps explain the importance of learning from others. Again, as I said before in my previous post, I wish I read this pattern earlier as the ideas presented in this pattern would have improved my learning this semester.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Helpful Advice for Seeking Employment

Today’s chapter in Apprenticeship Patterns is “Concrete Skills”.

This pattern provides an overview to the idea of more specific skills developers should have as they start their careers.

I think that this pattern serves as a good introduction to this topic. This pattern seems especially relevant to where I am now as I will soon be looking for employment after graduation and this is a good general reminder of things that software development managers are looking for.

I like and agree with the idea of creating a project for demonstrating your knowledge of the skills that you have acquired. This is what my team has been doing for our work so far this semester on the UpdateGuest project and I, along with my teammates, think this helps to cement the knowledge gained when learning new tools and languages. This pattern serves as another good reminder that this is also something I want to do more of with my personal project and I particularly want to start moving away from using languages I already know to learning and improving my abilities in these “concrete skills” with new and different tools that I am more unfamiliar with. I specifically want to get better at some of the examples mentioned in this pattern including web design and JavaScript, along with Angular as these three things seem like important requirements for developers now.

Although I think this pattern provides helpful information, I do wish that this pattern was more specific and detailed. I believe this pattern could benefit from expanding upon the information it offers. I also think that it would benefit from including an example CV showing how these skills are listed and defined on a real document. After reading this “action” section, I am now curious as to what the most important skills are for a starting position in the DevOps field and if I already know any of these skills. Again, I think this section could benefit from suggestions as to where to go to look for these besides people you may know.

Altogether I did find this pattern helpful and a useful reminder of what the most important parts of a resume are for a software developer. This is true especially as I move on to creating and refining my own resume in preparation for getting my first job in the software development field.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

The Benefits of Being a Beginner

This evening I continue my reading of Apprenticeship Patterns with the third pattern titled “Unleash Your Enthusiasm”.

This relatively short pattern describes the benefits and possible disadvantages, along with how to handle the “enthusiasm” of being a new developer.

I both agree and disagree with both of the areas of this pattern that describe the “context” and the “problem”. In my current situation and from my memory of the time I have spent in the software development courses so far, I have found that the professors I have worked with and learned from can have more “enthusiasm” than I do. I think that this is one of my favorite parts about taking this track of computer science was getting to learn from people who enjoy the work and learning as much or more than I do. I think this was specifically the case last summer with my work on the LFP community which really helped to motivate me to contribute to it and kept me going. At the same time, I also agree with the idea this pattern presents that a rather unenthusiastic group can bring down the mood of someone excited about being new to the field.

I do understand the rather unfortunate idea of only being excited about projects outside of regular work. I personally find this to be true and that although I usually enjoy working on my project, it is not just because of the topic or the self-interest, but also because of the freedom allowed in the workflow when you work on your own project. I think this point about a group’s attitude while working is something I want to keep in mind when I begin looking for a job as a software developer, as I would prefer to have a job where everyone enjoys the work they do and encourages this passion in each other.

Overall the quality this pattern describes seems like one of the best perks of being new to this field. I do worry that for me this quality will diminish over time and I hope that I haven’t lost it already before I’ve even started. I think that this pattern does a good job of pointing out this quality of a beginner’s enthusiasm and that it is something I want to work towards keeping now that I am more aware of it.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Learning how to Learn

Tonight I am continuing with my reading of the Apprenticeship Patterns with toady’s pattern being “The White Belt”.

This pattern helps to explain how to get over the obstacle of learning and implementing new information after mastering “your first language”.

This pattern feels applicable to me as I feel this is the stage I have reached with the first language I learned. I particularly connect with the problem area that describes a difficulty with learning new tools as this is something I feel I am beginning to run into (especially with Angular) while learning new tools for my work on the UpdateGuest project.

I do think that I try to take the approach mentioned in this pattern of forgetting what I know when learning new tools, but I think that now I am more consciously aware of the value of this I think it may further help with how I learn.

I also agree with the point this pattern makes about being afraid of looking bad when trying something new. I recognize that this has held me back in some of my work this semester as I did not want to commit code that I was unsure of. With the help of this pattern, I realize that I need to get over this fear and not let it hold me back.

One of my favorite parts of this pattern is the example code. I appreciate how the beginning of this is in Java, as this makes it easy for me to understand and it makes the comparison more meaningful. The real beauty of the example is how the multi-line Java snippet is condensed into one small line in the J implementation. This vastly condensed (and somewhat strange to me) implementation really helps me to appreciate and understand the point this pattern makes of needing different approaches when using new tools that are unfamiliar from what you already know. This example makes me want to take up this challenge of learning something that is new and completely the opposite from what I already know.

For me, I read this pattern at a great time, and I even wish I had read it earlier this semester as it could have helped me with my work developing for LibreFoodPantry. I am going to make a point of keeping this pattern (and the cleverly quoted advice from Yoda in The Empire Strikes Back) in mind as I continue to learn about new tools this semester.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Beginning the Patterns

This evening I began my reading of the patterns in Apprenticeship Patterns, starting with the first pattern “Your First Language”.

This pattern provides guidance in selecting the first programming language you will learn as more of a beginner and the importance of this first language. The pattern also explains how to move on from this first language to learning others.

I liked this pattern as it let me reflect about my overall usage of Java, the first language I truly learned as a computer science major. Reading this pattern has made me question my usage of this language and particularly if I over-rely on it. I am also wondering if this is the best language to continue using or if I should switch to another language as my primary programming language.

I agree with the advice given of picking a real project for helping to learn a language. This is what I would like to do more of with my side project, and I would like to use this project more for learning new tools and languages.

I liked the idea of using tests as a way to verify your comprehension of a language, instead of just testing the code. I particularly like how this idea is a different approach to thinking about testing and its usage and how to use testing when starting out with a new language. This point is definitely something I want to keep in mind when I learn new languages.

Additionally, I liked the idea of picking languages according to the knowledge the people you know have. With my experience, I agree with this sentiment and I think there is a lot of value in having someone you can go to that can help you get back on track with coding problems. At the same time though I do somewhat disagree with this idea and I think that someone should decide on which language to learn based more on the availability and quality of the resources available for learning a tool or language. The reason for this is that I would prefer to have a reliance on resources rather than having to rely on someone else.

I further agree with the notion of getting “stuck” in the first language you learn. This is something that I am afraid of doing, especially with the longer I use Java as my primary language.

This pattern has helped me to reflect on my current knowledge and usage of programming languages. It has increased my wanting to learn a new language and I will keep it in mind as I switch to learning and using new languages.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Second Sprint Retrospective

This week concluded the second sprint with my work on the UpdateGuest team developing for LibreFoodPantry. This sprint was exciting as we began creating the implementation of our service.

One of the first issues I helped work on this sprint was coming up with questions for the Thea’s Pantry staff member for when they came to our class.

During this sprint our team also focused on improving working together as a team as were beginning to implement our service.

An issue directly related to this included standardizing our IDEs as we prepared to code together on this project.

Secondly, as part of learning to code as a team I also re-read the first five chapters of Clean Code by Robert C. Martin to review best coding practices.

Additionally during this sprint I helped to implement the web interface for our frontend service where I began to learn how to use Angular again and also learned how to use Angular Material. This issue has two merge requests associated with it, one mainly adding Angular Material to the project, and another adding the implementation of the Web UI.

During this sprint I also reviewed and commented on two different merge requests. The first merge request was for implementing MongoDb for our backend service. The second was for the front end architecture document.

Individually, I think I am getting better at becoming a Scrum Master and learning to listen to other people during our meetings as I help to facilitate them. Although I have found it harder to do this when we switched to online meetings as sometimes it is harder to hear people talk than in-person. During the final sprint I would still like to improve on my ability to listen to other people’s suggestions, both during meetings and on GitLab.

I do think I need to get better at being patient with the rate that changes are made. This issue specifically occurred with a merge request when I directly made changes to a branch without asking first (even though I figured I should) as I thought it would be quicker than submitting another review for it. I do regret doing this as it led to a small conflict. We did resolve this issue and as a team we have made a new working policy that helps address this issue, so each developer only works on their branch individually to help avoid merge conflicts, in addition to helping with this issue.

As a team I think we did good this sprint. We finished several issues early on in the sprint and I am particularly happy with the work that was accomplished for the backend service and the web UI. I think that our team was also better at communicating this sprint and that we have improved our communication on issues and our use of GitLab to coordinate and communicate with each other. I also think we had some great collaboration this sprint with reviewing each other’s work, discussing and implementing suggestions, and even having multiple people working on the same branch.

I also think there is further room for improvement with our communication over GitLab and in meetings. Improving GitLab communication is especially important since we no longer have face-to-face meetings, and GitLab is where most of the remaining time discussing issues and work will be spent in the upcoming final sprint.

I do wish we were able to finish all of the issues we planned on doing for this sprint, but I understand that given the many different events over the past month that other things just got in the way of this. Part of this issue also has to do with the weights issues were assigned during planning. I personally think I need to improve my weighting estimates for issues as this seemed way off for this sprint. I think this was part of the reason we were unable to finish all of our issues as issues became more involved and took longer than was originally anticipated when planning for the sprint. Additionally, I think as a team we need to break issues into both smaller and more defined tasks, that way the work is more defined and the issue weight can be estimated more clearly. These factors are something I have been trying to take into account for while planning for the last sprint.

Overall, I am looking forward to our upcoming final sprint and I am excited to see if we can finish the UpdateGuest service.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern Review #7:Dig Deeper

In practice, algorithm problems do not arise at thebeginning of a large project. Rather, they typically ariseas sub-problems when it suddenly becomes clear that theprogrammer does not know how to proceed or that thecurrent program is inadequate.Steven S. Skiena, The Algorithm Design Manual

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

Developing for LFP Again: First Sprint Retrospective

For over the past month I have been working as a member of the UpdateGuest team as part of developing for the LibreFoodPantry community. This blog post is a retrospective for the first sprint our team had. During this first sprint our team focused on setting up the UpdateGuest service and beginning the research into the tools we want to use to implement this service.

The issues that I was assigned to work on for this first sprint mostly focused on figuring out what we needed from other teams for the UpdateGuest service to function and what information the UpdateGuest service needs to store and to provide for other services under the VisitModule.

Specifically looking at the work I did this sprint:

The first issue I worked on was determining what data fields UpdateGuest would store, this was relatively simple and we decided that our service would mostly be using the fields the RegisterGuest team was storing since our service pulls guest data from theirs.

The second issue I worked on was a quick one creating a .gitignore file for one of our projects.

The third issue I worked on was determining the endpoints UpdateGuest needed from RegisterGuest to be able to get data from their service, this was solved quickly as the RegisterGuest team posted an issue where they listed all of the endpoints their service would have and this was all we needed.

The last issue I solved was what endpoints UpdateGuest needed to create for other services to use (along with our own), this became a discussion on many things, mostly with our team and the RegisterGuest team, to coordinate the endpoints and data they needed from us and how to format the endpoints and the data we are sending back and forth, but also how our service functions in general.

Finally, I helped to discuss and merge the creation of the Angular app for the UpdateGuestWebUI project.

I think that during this first sprint that our team did well. We successfully completed nearly all of the issues that we initially proposed to work on at the beginning of the sprint and even managed to create a couple of new ones and pull some additional issues from the backlog that were completed. Our pacing and completion of issues was mostly on track with the weighting system we used when creating the issues during sprint planning, although this might need some refining. We had good meetings in class where we all talked about what we were working on and we resolved any issues or questions that were ongoing with our work. We also used GitLab effectively to coordinate all of this work and document the different discussions and work as it was ongoing throughout the sprint.

I think that some things could be improved. I think that we could all try talking and communicating a bit more both in-class during our sprint meetings and outside of class either on issues on GitLab or on Discord. From Dr. Wurst’s suggestion I think we should establish some working policies for the rest of the semester’s sprints, especially about communication, but also when work should be done on the project. I think this is necessary so that others have time to contribute and interact on other group member’s issues and work before class meetings, so we are better prepared to discuss them in-class. I think specifically we need to define a team policy of replying to comments on GitLab or Discord when someone directly mentions an individual or the whole team asking for input that helps to solve or facilitate an issue.

Individually I think that I need to improve on my own communication skills and in helping facilitating team meetings in-class. Most importantly, I think that I need to get better at letting others talk and understanding the points they are making, especially if their opinions or solutions differ from my own, before I comment on them. Additionally, I think I need to get better at articulating my explanations of solutions and trying to not sound condescending while doing this. I also think that I could improve on my response time when directly mentioned on GitLab on issues.

Overall, I am excited to be working on a LibreFoodPantry project again and look forward to the remaining sprints as we continue developing our services this semester.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 1

What we did as group for sprint For this sprint we as a team started our first meeting by putting in place a plan for the whole sprint, we picked the first steps of the architectural design for our API. We decided the roles for each one of us, and then divided the tasks, so … Continue reading Sprint Retrospective 1

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.