sensinci

[sensinci]

Sprint 3 Retrospective Reflection

In this blog post, I will reflect on the third sprint of my capstone project. I will discuss what worked well, what didn’t work well, changes we can make to improve as a team, changes I can make to improve as an individual, and I will end by listing links to the work I have done with descriptions.

One of the things that worked well for me personally during this sprint was the quality of documentation that I had created. I would say that my documentation was consistent from beginning to end for sprint 3. For all the work and decisions I made for this sprint, I made sure to document it for my current teammates but also for the next students who would be taking over this project. Another thing that worked well for me this sprint, was creating a document with specific goals that I wanted to accomplish prior to each class. I regularly checked in with this document through sprint 3 and it served as my personal issues board. I kept updating the specifications of my issues but the overall gist of the issue remained intact for the duration of sprint 3.

For things that didn’t work that well in this sprint, even though I consider sprint 3 to be my most productive sprint, I also feel like I did not deliver enough minimum viable products that possessed incremental improvements. While I did produce a minimum viable product for updating our landing page, that soon got quickly incremented with another teammate’s commit. What I was really hoping I would be able to crack was creating an interactive drawing page for the writing portion of our application. While I made several attempts in creating this feature, they were all ultimately unsuccessful in producing a minimally viable product that improved on the pre-existing code.

As far as what we could improve on as a team, one of the things that I think could have made us even more successful would have been having a conversation about what we wanted the minimum viable product for sprint 3 to be. I think we knew all the work/issues that needed to be done for this sprint and we went full steam ahead, however, we probably could have benefited from taking a mental snapshot of where we were at the end of sprint 2 and where we hoped to be at the end of sprint 3.

When it comes to changes that I can make to improve as an individual, I would like to address my previous issue of what I don’t think worked that well for me in this sprint. Next time, I think I should focus on taking what is already present and making one minor incremental improvement before moving forward with an exploratory phase to create a major improvement. My initial increment doesn’t have to be much, but it would allow us to say we delivered something different from sprint 2. By doing something small and simple first, I can then focus my efforts on riskier experiments. If these experiments work out, the risk would have paid off, but if they don’t work out, I can fall back on the safe, small incremental improvement I made.

Links to evidence of activity on GitLab with descriptions:

What I essentially did for this was replace the “We want pizza” landing page to one with two separate buttons. One leads to the “Writing Portion” of our app and the other leads to the “Reading Portion” of our app.

I asked for clarification on why an issue was closed so that it is documented.

I explained my process with getting expo running for me (which is different from how one of my teammates was doing this).

I pulled and checked out the code per my teammate's request to make sure it worked on my end.

I pulled and examined Emmanuel’s code per his request and then made some exploratory attempts to implement a writing feature.

I documented a potential idea for our issue with implementing the reading portion of our application.

I created an issue with some notes for whoever starts the process for this issue.

[sensinci]

Apprenticeship Pattern: Record What You Learn

The pattern I decided to read is titled “Record What You Learn” from chapter 5 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern starts out by giving context of a situation I know I have found myself in multiple times. This situation is one where I am relearning the same technical lessons over and over again. The proposed solution to this problem is to keep a chronological record of the lessons I’ve learned. This record can be made in the format of a blog or wiki, to name a few options. Additionally, these kinds of records can be made public or private. Public records are good for building connections since others can read them and private records are good for being painfully honest with yourself about your progress. The last section of the solution ends on discussing how your record keeping tool can be an example of a Breakable Toy and how this Breakable Toy can help you extract lessons from it as one grows from a novice to a more experienced developer. The actionable item this excerpt ends with is encouraging its readers to start immediately because these entries can become the basis for books, magazines, and blog posts in the future.

In response to the question, “Will this pattern cause you to change the way you will work?”, my answer is a resounding yes. I’ve read this pattern multiple times before writing this blog post and have slowly been successfully developing my own personal journal/“Breakable toy”. I think one of the reasons why this has been so effective for me has to do with the following line I found interesting while reading this pattern, “The private record allows you to be painfully honest with yourself about the progress you are making”. In my journal, I get to reflect on how well I truly know certain technologies and what I still want to learn. And whenever I learn something new, I write about it in a way that is meaningful to me (as opposed to doing work for a class deadline). Therefore, I completely agree with the information in this pattern. It has been a super beneficial process for me so far and it is rewarding to physically see the evidence of what I've been learning in one localized place. I’m happy that if I have taken anything from this book, it is a journal/“Breakable Toy” I can continue using in my career and life.

[sensinci]

Sprint 2 Retrospective Reflection

In this blog post, I will reflect on the second sprint of my capstone project. I will discuss what worked well, what didn’t work well, changes we can make to improve as a team, changes I can make to improve as an individual, and I will end by listing links to the work I have done with descriptions.

To start off discussing what worked well, one of our biggest accomplishments, if not our biggest accomplishment (in my opinion) was successfully creating a functioning docker image that we were all able to pull and use on our individual laptops. This was a big milestone for us because during sprint 1 we were running into compatibility issues and had no standardized way of creating and sharing code with one another.

For things that didn’t work that well, I would like to bring up something that was a common theme in our retrospective meeting: our lack of regularly documenting our work. I think this was something that we started off on the right track at the beginning of our sprint after having discussed this as an important thing to do in our first retrospective meeting. But with spring break, the week we had off from class, we fell back into the habit of doing work without documenting as we go along. Another thing I would like to mention for this category were the issues we created that started with “Learn to…”. By creating these kinds of issues, it made it difficult to deliver something tangible as it relates to our capstone project. While there was a lot that we learned, it should be represented in the future by applying our new knowledge in a practical way. Lastly, I would like to mention that although we had a functioning docker image to use, it has been incredibly slow to use while on campus/in class. There were classes where I felt like I was simply working on setting up my container just to shut it down by the time class was over.

In our retrospective meeting, one of the big things we discussed we could all improve on as a team is thoroughly knowing our issues board. As a team, we should constantly be reading, updating, asking clarifying questions, and breaking down issues into manageable steps. Part of me was afraid of touching issues that my peers created because I didn’t want to change their original idea, but it is exactly this collaborative process that is needed to create a productive sprint. Doing this clarifies the work at hand and prevents things like creating duplicate issues.

When it comes to changes that I can make to improve as an individual, my goal for sprint 3 is to use my class time more effectively. This last sprint has taught me that it is especially difficult for me to dive into my code when my peers are around me. Some of the best technical work I have done comes from me working in an independent, library-like environment. Because of this, I will focus on using daily standup meetings and my class time as an opportunity to get very comfortable with our issues board. If there are issues that require further details I can add them in class and if there are questions I need to ask my peers about issues they’ve created I can ask them in person. I believe making this small change will be more effective than spending my hour and fifteen minutes in class trying to code with intermittent distractions that may pertain to the capstone, but do not always pertain to what I’m coding.

Links to evidence of activity on GitLab with descriptions:

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/21

I created this issue.

While I did not post the comments on 3/1, I helped Sofia write the comments where we created smaller steps on how to go about setting up a Docker image with the React Native framework.

While I did not post the comment on 3/14, I encouraged my teammate to write up the documentation on creating a container for React Native and the third party application, Expo. Additionally, I followed the steps in case there were any clarifying edits that needed to be made.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/22

I created this issue.

We learned that adding the extension ID of the dependency in question, along with its version, to the package.json file is how we go about adding/removing dependencies to a Docker image.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/23

I created this issue.

I responded to my classmate by adding a clarifying description to this issue.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/24

I created this issue.

I had a conversation with Sofia on how another issue essentially covers the basics of this issue so it was redundant to have both. As a result of this conversation, this issue was abandoned.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/25

I created this issue.

I created a clarifying description with steps for this issue.

[sensinci]

Apprenticeship Pattern: Familiar Tools

The pattern I decided to read is titled “Familiar Tools” from chapter 6 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The problem that this pattern presents asks the reader how they plan on completing a work project if there are so many new things to learn with each project (from the technical to non-technical aspects). The solution to this problem starts by informing the reader that they should have a reliable set of familiar tools to use for each project they start. However, the reading goes on to explain that readers should be weary about how they use these tools and how dependent they are on these tools. A larger message stresses the importance of how in the process of becoming a journeyman, we may need to painfully abandon some tools and learn new, better, more effective tools in their place. The text ends by encouraging readers to either build a toolbox they can bring to a project, or if they already have a toolbox, examine potential replacement tools.

Reading this pattern was surprisingly encouraging. I don’t think that was an intention of this reading but the reason it had this effect on me was because as someone who is in the beginning of their journey in software development, it can feel pretty intimidating to just be starting out when there are people who have been working in this field for years. And yet, that person and I may be in the process of learning some of the same things today. While the other person is likely to have much more experience in using tools than I am, it is comforting to know there are things we will be learning at the same time.

This pattern has changed the way I think about my work because it has gotten my wheels turning as to what five tools I would like to have in my toolbox and what tools I think I need to continue exploring.

Lastly, there isn’t anything significant in this pattern that I disagree with. This is another pattern I enjoyed reading.

[sensinci]

Apprenticeship Pattern: Expose Your Ignorance

The pattern I decided to read is titled “Expose Your Ignorance” from chapter 2 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern starts with throwing out a hypothetical problem where the reader is working for an employer that is expecting the reader to deliver a product but the reader is unfamiliar with the required technologies. The solution to this problem is in giving an honest response and building a reputation on your ability to learn rather building a reputation on what you know. This pattern also mentions how asking questions is a great way to expose your ignorance because you show what you are learning to your teammates. The pattern ends by discussing how exposing your ignorance is a trait of walking the long road because it means you are open to learning unfamiliar technologies and new domains. Whereas, experts tend to narrow their scope of learning, practice, and projects by specializing in specific things.

There were two instantly helpful pieces of information I gathered from reading this pattern. The first useful piece of information was how as I work on becoming a software craftsman, it is more useful to be known for my ability to learn things instead of being known for the specific technologies I am already familiar with. This piece of advice immediately affects how I think and how I will speak about future projects.

The second thought-provoking piece I read was how becoming an expert is a by-product of the long road I am on. This absolutely blew my mind but also humbled me because I should have known this already since I use a similar perspective for exercising in the gym. My goal of living a long and healthy life means that as a result I will have strong muscles if I am regularly going to the gym. I think one of the reasons this was so striking to me is because I feel like I have such a long way to go before I feel confident enough to call myself an expert in something. Therefore, hearing that becoming an expert is a by-product of the long road showed me how long this long road really is for me.

Lastly, there isn’t anything significant in this pattern that I disagree with. It was an enjoyable pattern to read and one where I learned some valuable information.

[sensinci]

Apprenticeship Pattern: Stay in the Trenches

The pattern I decided to read is titled “Stay in the Trenches” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern spoke about how people often equate being promoted into a managerial role with success but how this can actually take you away from the craft of programming. The pattern goes on to talk about how we should work with our employers to see if they can reward us in other ways that keep us close to the act of programming. Next, the pattern discusses how it is easy to apply this pattern selfishly but that experienced developers will find ways to make choices that will help their co-workers as well. Lastly, this pattern ends with suggesting its reader to come prepared with alternative rewards in case they don’t like the rewards offered by their potential employers, especially if they take them away from programming.

The most thought-provoking piece of information I got from this pattern was the bit about how I should make choices that are in my best interest, but how those choices don’t have to be blind to the needs of those around me. It was interesting to hear this because in a pattern that I’m learning about negotiating and advocating for myself, I’m also being taught how I can still be compassionate to others on my team. This is refreshing to hear because it seems like developing can often be a cut throat and intense environment to work in.

As far as how this pattern has caused me to change the way I think, I would say it re-enforced some of the beliefs I had. In a way, I’ve learned first hand what this pattern has described. I started working in human services as a residential counselor and worked my way up to managing a group home on my own. I learned the hard way that by entering a managerial role, I did a lot less case management and had less time with the individuals I served than when I was a residential counselor. Because of this and some other factors, I decided to step down back to the role of a residential counselor which I personally find more rewarding. This realization I made is the kind of message I got from reading this pattern. If I am passionate about programming, I need to be mindful of the opportunities I may receive in the future and make sure they are aligned with my desire to be a software craftsman.

Lastly, I’d like to mention that there isn’t anything in this pattern that I disagree with. It was reassuring to hear something I have learned in life being echoed in this book, even though it was in a different career path.

[sensinci]

Apprenticeship Pattern: Draw Your Own Map

The pattern I decided to read is titled “Draw Your Own Map” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern was about taking ownership of your professional career as a software craftsman. We learned that in many jobs, you may get pigeonholed to do one particular thing when you may be passionate about learning or doing something different. This passage reassured its readers that they had options and didn’t need to feel trapped, or stuck. By spending some time reflecting  and drawing your own map, you can make career choices that feel empowering instead of limiting.

One of the most thought-provoking points that was brought up in this reading, has been mentioned before and I think I have highlighted in a previous blog post but I would like to reiterate it here because it continues to resonate with me. This pattern mentioned how sometimes it is better to “move into a less hierarchically impressive role in order to stay “on the map.””. Especially if staying on the map is, “more congruent with your goals and will lead you to greater heights in the long term.” This resonates with me because I want to make decisions that are aligned with my goals and beliefs in my professional career, even if that means making some temporary sacrifices.

As far as how this pattern has caused me to change the way I think about my profession, it has encouraged me to either make career choices that open up opportunities or help me  pick a specialization I am passionate and confident in. While my first job after graduation is likely going to be something to get my “foot in the door”, after some time in my first job, it is important for me to spend some time thinking about what the next best step is going to be. My first job is likely going to teach me a lot about what I like and don’t like and it is a place where I can see my interests developing as a software craftsman.

Lastly, I’d like to mention that there isn’t anything in this pattern that I disagree with. It has encouraged me to start thinking about my own map and it has made me peek at some new potential patterns for me to read next (e.g. Expand Your Bandwidth, Use Your Title).

[sensinci]

Sprint Retrospective Reflection

In this blog post, I will reflect on the first sprint of my capstone project. I will discuss what worked well, what didn’t work well, changes we can make to improve as a team, changes I can make to improve as an individual, and I will end by listing links to the work I have done with one sentence descriptions.

To start off discussing what worked well, I would like to pick one thing I decided on doing without much prompting. In addition to checking in with my team during the week and through discord, I made an agreement with myself to try to submit at least once a week a “bigger” message on our GitLab that would hopefully be useful. While I think it is important to post links and resources for us to learn more about certain tools and technologies, I wanted to include some posts/documentation on bigger conversations we had during our stand up meetings and detailed documentation of my setup process with certain technologies (e.g see post on setting up React native and post on the user flow diagram).

For things that didn’t work that well, I would like to discuss some of the technological difficulties I had. For the first couple of stand up meetings, I thought I would be able to do this capstone with my old laptop. After realizing that this capstone would require some more CPU power than my laptop could offer, I purchased a laptop that was more appropriate for the demands of this course. After setting up my laptop, I noticed a significant change in the amount of work I could then produce. I do think there is a minimum laptop requirement as far as performance is concerned, especially when we are testing frameworks and downloading various software/programs to build our first app. For example, I ended up downloading Android Studio for this capstone and this is a large application. There was no way I could have used my old laptop with Android Studio. I’m happy with the purchase I made and I know it will last me into the first couple of years of my professional career.

One thing my team could improve on for the next sprint is better documentation. This is something Dr. Wurst had mentioned and also a bigger conversation we had as a team during our retrospective team meeting. We discussed how although we may be doing a lot of work and research on our own, if we are not documenting this process, it’s like it never happened to future groups who join this capstone project. We discussed how sometimes it’s difficult to document as we work because it breaks up our “flow”. One solution we came up with to address this problem is setting aside 10-20 minutes at the end of our work to strictly document what was done.

One thing I think I can work on doing better in our second sprint is documenting the work I have done. This was especially a challenge for me in the beginning when I was transition from one laptop to another, but now that I have a more reliable set up, this is something that should not be as much of a challenge to do. Moving forward, I like the idea of checking in at least once a week with my teammates outside of regular class time to update them on the progress I have made. This would be a great way to build a routine where I am regularly creating some form of documentation.

Lastly, I will include links as evidence of activity on I’ve contributed to GitLab with one sentence descriptions.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/17#note_852841115\

In this post, I wrote some notes on some of my research in deciding whether React was a viable framework for us to use.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/documentation/-/issues/2#note_848876182

In this post, I posted a digital version of the user flow diagram we had discussed in class.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/documentation/-/issues/2#note_840272759

In this post, I posted some documentation notes on setting up react native in addition some of code and screenshots of a potential place for us to start.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/9#note_839072762

In this post, I made a comment about the difference between the LICENSE.md and LICENSE_FOR_CONTENT.md files.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/commits/main

I posted six required files to our General repository.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/5#note_839049184

I posted a link that teaches about .gitattributes in a straightforward manner.

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/10#note_838060720

Communicated with my team that I moved something to “Needs Review” for them to pick up and move to the “Done” category. 

Links to issues I’ve opened/created:

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/12

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/11

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/10

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/9

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/demo-react/-/issues/9

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/10

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/9

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/8

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/7

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/6

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/6

https://gitlab.com/worcester/cs/naturalization-interview-confidence-environment/General/-/issues/5

[sensinci]

Apprenticeship Pattern: Nuture Your Passion

The pattern I decided to read is titled “Nurture Your Passion” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The line that I think best summarizes this pattern is the one that states, “The people who walk The Long Road are not the heroes who sprint for a few years and burn out—they are the people moving at a sustainable pace for decades.” I really liked this quote because I’ve heard so many stories of young software developers who do amazing work at their first couple of jobs, but suddenly stop working because they are not feeling fulfilled. I think part of the reason for that is because many software developers enter the field and work themselves to the bone without really thinking about the “why” behind their work.

The reading adds that the jobs can foster a highly competitive, fast paced, and toxic work environment that further leads to developers burning out. The reading provides some potential solutions to this problem: 1. work on something you like 2. seek out kindred spirits 3. study the classics 4. draw your own map 5. set boundaries

One of the most thought-provoking things I took away from this reading was how by setting boundaries in my first job as a developer, I may get passed over for pay raises, promotions, kudos, or popularity. But on the other hand, by taking care of myself I am less likely to burn out and have a more sustainable career.

Therefore, I would say this pattern has indeed caused me to change the way I think I will work in my profession. While I want to be seen and known as a hard worker, I also think it is important for me to be mindful of how I am working and find balance.

Overall, there isn’t anything that stands out that I strongly disagree with. In fact, this pattern alluded to some other patterns that I am now more interested in learning and reading about to help me make sure I nurture my passion as I enter the software development field.

[sensinci]

Apprenticeship Pattern: Craft over Art

The pattern I decided to read is titled “Craft over Art” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The line that best summarizes this pattern is the one that states how the programs we create can be beautiful, but must be useful. This pattern starts off with a quote by Richard Stallman in “Art and Programming” that defines programming as, “a craft, which is a kind of art, but not a fine art.” This distinction is important because it shows how making beautiful programs is a good thing, but how its beauty should never outweigh the utility of the program that has been created. This pattern ends by giving us two tasks. The first task asks us to find something to do where we can prioritize usefulness over beauty. The second task is a reflective one that has us think about times we have chosen artistry over utility in our craft.

One of the sentences that I found interesting was the one that described how “utility and beauty are not opposed to each other, but interdependent.” This sentence stood out to me because although there is no denying that programs must be useful, it reminded me that I can not completely neglect the aesthetics of my program either because it goes hand in hand with how it is used practically.

As far as how this pattern has caused me to change the way I think, I would say that this pattern has made me be more mindful about the kinds of choices we make in our capstone project. We have already had a couple of conversations around this topic and I’m happy to say that our team has erred on the side of practicality over aesthetics. One of the things we have said in our team is that we should focus on setting the foundation of our project, and if we have enough time, we can come back and worry about our application's appearance some more.

Overall, there isn’t anything that stands out that I strongly disagree with. It was a reassuring chapter to read after reflecting on some of the decisions my capstone team has already made on this topic. Additionally, it is a great message to instill early on in my programming career.

[sensinci]

Apprenticeship Pattern: Concrete Skills

The pattern I decided to read is titled “Concrete Skills” from chapter 2 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern starts off by discussing how hiring managers have no incentive to hire someone who can not directly contribute to a team’s workload. Hoover and Oshineye ask the following rhetorical question from a recruiters point of view: “If we hire you today, what can you do on Monday morning that will benefit us?”. In short, the solution to this problem is to develop and maintain some concrete skills. We learn that with time we will become less dependent on our concrete skills and get hired through the reputation we have garnered from notable projects. This pattern ends by giving the reader a recommendation on how they can begin developing some concrete skills.

The thing I found most interesting from the reading is that at some point in my journey I will become less dependent on my concrete skills. My portfolio and “deeper qualities” will be what matter more. This was interesting to me because in a section that stresses the importance of learning concrete skills in the beginning of my professional journey, I am still getting a message that soft skills are important. This shows me how there is an important balance of maintaining the hard skills I’ve learned in addition to being a team player, having good communication, being empathetic and having many other traits that fall under the soft skills category.

Overall, there isn’t anything that stands out that I strongly disagree with in the reading. As far as how this pattern has caused me to change the way I think, I would say that it has emphasized the importance of regularly updating my resume with technical skills since this is something many hiring managers focus on. Since there are plenty of skills I’ve been developing in school this past year, I took the advice from this pattern to heart and almost immediately started jotting down the skills I have started developing. I also started looking into CVs online for inspiration of concrete skills I want to develop and to add to my own resume.

[sensinci]

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

I found a lot of useful information in chapter 1 and in the introduction sections of chapters 2-6 in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. However, certain chapters were more impactful than others for me. In this post, I will discuss how and why chapters 1, 2, and 4 were personally significant.

Chapter 1 is titled Introduction and one of the most impactful parts of this chapter was the section that discussed growth mindset. I’ve heard this term before and knew generally what it meant but it was nice re-reading and re-learning this. I especially liked the line that mentions failure as an incentive to try a different approach next time. I have definitely seen failure as an unmotivating factor once or twice in the past so I like how this definition flips people’s outlook on failure on its head.

Chapter 2 is titled Emptying the Cup and the reason I list this chapter as second most impactful/relevant to me is because there was a blurb that discussed the importance of acquiring concrete skills in a specific technology and how that will open doors for you. I have an interest in acquiring concrete skills not only to help my team members complete our capstone project, but I am also interested in learning the “right” concrete skills that will set me up for a successful career after graduation.

Chapter 4 is titled Accurate Self-Assessment and the line that stood out to me in this introduction was the one that described how my goal should be to measure my abilities and to find ways to be better than I was yesterday. Again, this is pertinent to me both for my capstone project and for my career after graduation. I’m particularly interested in reading the sections titled, “Be the Worst” and “Sweep the Floor” which seem to have discussions about finding ways to push and improve yourself to be a better developer.

Overall, I wouldn’t really say this reading changed any of my opinions but it did reinforce beliefs I’ve had (e.g. growth mindset) and the overall message that this career can be a lifelong passion if I wish to make it that. This is reassuring to hear because I often feel like I’m behind some of my other peers since this is my second undergraduate degree I am pursuing.

Lastly, I would like to add that I agree with most, if not all, of the themes in this reading. While some may be more relevant than others at this particular moment in time, I know other themes will likely be more relevant at different stages of my life.

[sensinci]

Familiarizing Myself with Thea’s Pantry

I found something useful when reviewing the Workflow documentation for Thea’s Pantry. There are five workflow steps listed online that we should be following but for this post I will focus on Conventional Commits. Although we reviewed this in class, reviewing on my own helped me solidify my understanding of this tool that we will be expected to use. Conventional Commits appear to simply be a set of rules we will need to follow whenever making a commit. The nice thing about Conventional Commits is that it is easy to read for both humans and computers, it works with plenty of other tools (like commitlint), and it dovetails with the Semantic Versioning Specification that is common in the developing field. There were plenty of examples on how to write Conventional Commits on the official website which was useful to review before I start writing my own.

[sensinci]

Familiarizing Myself with LibreFoodPantry

One thing I found useful was reading the FOSSisms that came from the Values on the LibreFoodPantry website. FOSSism are pieces of wisdom for individuals who are about to work in an open source community. I will focus on the second FOSSism that stood out to me. This FOSSism instructed individuals to “Be productively lost”. This resonated with me because I feel like my technical skills still have a ways to go. It helped ease some of my anxiety around this topic because a period of feeling disoriented is described as being “perfectly natural”. Furthermore, I was advised to use this moment productively to learn more about the open source project/community I am about to be a part of. This was only one of the first FOSSisms that caught my eye but I would like to include the link here because there are many more I could write about.

FOSSisms Link: https://opensource.com/education/14/6/16-foss-principles-for-educators

[sensinci]

Self-Directed Professional Development Post #7

For my last blog post, I’ve decided to review an article titled, “HTTP Methods” from the website, https://restfulapi.net/http-methods. The reason I picked this article is because 1. it directly relates to one of our course topics, “REST API Design” and 2. it helps me further prepare and review for my upcoming final exam. In addition to the resources that I have from the class POGIL activities, I wanted to find another resource to solidify my understanding of HTTP methods. In this post, I will start by going over the 5 HTTP methods and the information I’ve gleaned by reading this article, and then I will move onto a reflection on how effective this article was in helping me learn this course topic.

In the list of review topics for my upcoming exam, I’m asked to know what the HTTP methods are used for and how they differ depending on whether I am referencing an entire collection or a single element in a collection. In the article that I’ve selected to read, the HTTP GET method is discussed first. I’m reminded that the GET method is used to retrieve information and that it can be used for both a collection and a single resource. This lines up pretty well with what we have learned from our class activity 12 (see table in Wikipedia citation below). Next, HTTP POST is brought up in the article and we learn that it is used to create a new resource in a collection. We are encouraged not to use POST on a single resource/element and this corresponds with the information from activity 12. Subsequently, the article discusses the HTTP PUT method. We learn that PUT is used to update an existing resource or create it if it does not already exist. PUT methods can be used on both elements and collections (this also matches up with the information learned in activity 12). In fourth place, the article discusses the HTTP DELETE method, one of the more straightforward methods, that can delete single elements or an entire collection. Lastly, with HTTP PATCH, we learn that it can be used to make a partial update on a resource and that it is usually used on elements. Personally, I preferred the description of this method over the one given in activity 12 but the article did support the point that PATCH is not usually used on an entire collection.

Finally, once I was done reading/taking notes on the article, I felt even more confident in my understanding of HTTP methods. I thought the article was both straightforward and educational, and therefore effective. The language was easy to understand and it provided me with another perspective to learn the class material. I would recommend this article to anyone else who is learning about HTTP methods for the first time or simply needs a refresher on the topic.

Article:

https://restfulapi.net/http-methods/

Wikipedia link:

https://en.wikipedia.org/w/index.php?title=Representational_state_transfer&oldid=866461276

[sensinci]

Self-Directed Professional Development Post #6

For this week’s blog post, I’ve decided to continue watching the video I started in my professional development post #4, “Object Oriented Design Tutorial: Creating a UML Design from Scratch” and start the next video in this series titled, “Object Oriented Design Tutorial 2: How to Turn a UML Design into Code” by Derek Banas. The reason I picked this video is because 1. it directly relates to one of our course topics, “Modeling: Unified Modeling Language (UML)” and 2. because it teaches a methodical process to creating UML diagrams and the code that goes with it. Since I will likely be making more UML diagrams in my educational/professional life, I want to further develop these skills. In my last post, I learned how to use a Use Case Description to create an Object Model and a Sequence Diagram. In this post, I will start by discussing how an Object Model and the Sequence Diagram is used to create a Class Diagram. I will then move on to discussing how these models and diagrams can be used to create Java code.

When Derek is creating his Class Diagram, he uses his Object Model to create the class name and the data fields of his classes. Derek then uses his sequence diagram to bring in the methods for each of the classes he creates. One thing that I thought was interesting as he brought in the methods for his Class Diagram was that he added an additional method that he did not include in his logic when creating his sequence diagram. He added a getCoinOption method and stated that he may not end up needing this method but will include it just in case he missed something with his logic. It is nice to know that using his approach allows me to make these kinds of edits on the fly.

In Derek’s next video, he uses his class diagram to lay out the data fields and methods in his IDE. Once he has outlined his program, he uses the sequence diagram to write his code. Derek starts with the coin class. In this class he mentions how he starts with what makes the most sense to him to get his code to work. He mentions once his code works, he can come back and worry about optimization. He uses an array that contains heads or tails for the coin value and Math.random to return the value of the coin flip. Observing this process was beneficial because it showed me how important it is to think of the data structures I will be working with and the operations that I want to perform.

Overall, I’m very happy with this series. One of the things I enjoy the most is that Derek is doing all this from scratch so we get to see any obstacles that come up along the way. I’m looking forward to seeing his working program at the end.

Tutorial links:

https://www.youtube.com/watch?v=fJW65Wo7IHI&list=PLGLfVvz_LVvS5P7khyR4xDp7T9lCk9PgE&index=3

https://www.youtube.com/watch?v=1BVXQ64wI00&list=PLGLfVvz_LVvS5P7khyR4xDp7T9lCk9PgE&index=2

[sensinci]

Self-Directed Professional Development Post #5

For this week’s blog post, I’ve decided to continue watching the video I started in my last professional development post, “Object Oriented Design Tutorial: Creating a UML Design from Scratch” by Derek Banas. The reason I picked this video is because 1. it directly relates to one of our course topics, “Modeling: Unified Modeling Language (UML)” and 2. because it teaches a methodical process to creating UML diagrams. Again, since I will likely be making more UML diagrams in my educational/professional life, I want to further develop this skill. In my last post, I learned how to create a Use Case Description, and in this post, I will discuss how to use a Use Case Description to create an Object Model and a Sequence Diagram.

Derek starts his Object Model by using the actors he listed in his Case Description to create 3 separate object boxes in his Object Model diagram. He connects the actors/boxes with a line to show what action is carried between the given object and the multiplicity that each box has. Next, Derek fills in each object he has created with pertinent data fields, for example, since there is one object box for two players, he adds name as an important piece of information to differentiate the two players. This process was valuable to me because I tried to predict what information would be important before Derek did. I wanted to include some methods in the object model, but I learned this is not where I do this. Derek only includes attributes of the objects and other objects that a specific class will use (e.g. the CoinGame includes both the players and the coin actors).

The next thing Derek does is create a Sequence Diagram. It is important to mention that in this video, Derek mentions that he has another introductory video into Sequence Diagrams so he goes somewhat quickly through this process. Either way, there was a lot that happened and that I learned from observing this process. Overall, the main takeaway from this part of the tutorial is that Derek uses the Steps of Execution from the Case Description to lay out the logic of the program he is creating. Throughout this process I thought it was interesting that there were some things that Derek, himself, was not sure of as far as what made the most logical sense, but he went forward with what worked for him. This was really insightful because as I practice this process on my own, I’m realizing that I can create a similar program with a slightly different logical order of what makes the most sense to me.

My goal is to continue following Derek along in this process so I can use a similar approach to create a simple program on my own. For my next post, I’m considering following Derek as he creates a UML he describes to be “easy” now that he has his Sequence Diagram created.

Tutorial link: https://www.youtube.com/watch?v=fJW65Wo7IHI&list=PLGLfVvz_LVvS5P7khyR4xDp7T9lCk9PgE&index=3