Retrospective #1

Now that Sprint 1 has come to an end, it is time for the retrospective blog. I will start by including everything I contributed to this sprint:

This link is a note in an issue where I have put a document discussing the Pros and Cons of whether we should be using a relational database or not. I put some examples of relational databases and non-relational databases for when I was making a decision along with links explaining a few of them.

This link is another comment on GitLab basically stating that we are using mySQL because of the simplicity and it is easy to look up information on it if needed.

This is the repository for our database currently, it is currently on a separate branch and not merged with the master due to a sudden change in database fields which will be implemented first thing in the next sprint.

This is another repository that holds the results of completing the Tour of Heroes Angular tutorial. This was the last thing completed for the current sprint to give me a refresher on Angular as I haven’t worked with Angular in a little over a year.

This was our first sprint so everything obviously wasn’t going to be perfect. However, I believe that we used GitLab very well considering this is my first time actually collaborating on a big project using GitLab. I think that we created issues that were specific enough to be considered issues. We utilized the boards well too. Our communication was mainly done through class and text message, but overall, I still think we communicated every issue that needed to be communicated.

Of course there were things that didn’t work well either considering it was the first sprint and this is most of our first experiences with Agile and sprints. While I mentioned that our GitLab use was very good. There were some faults with it as well. For example, my desktop didn’t let me push to GitLab which is an issue that still needs to be resolved. I specifically had trouble working with the separate branches because it was confusing at first. Our issues weren’t created the right way at first, and had to be restarted even though there were ways to just edit them without restarting. We had good communication, but I felt as though I wasn’t as involved as I should have been with the other team members work. I also think that there wasn’t enough communication between the other groups in the class as a whole.

Some of the changes that can be made as a team is more involvement in each others work. I think that we can all spend more class time looking at each others work rather than looking at it on our own time because this allows for more discussion. I also think that our team could start communicating with other teams more. Most of the teams came to us rather than us going over to the other teams to collaborate.

My individual changes that I need to make is talking more to my team members about what they have been working on rather than focusing on my own work. I could offer more solutions to the front end team about design. Probably my biggest issue would be my procrastination. I have to start working on my assignments earlier because that has an effect on how the rest of my team performs. I think that this next sprint will be much better now that we have been exposed to this more.

Breakable Toys

This week I decided to write about the Breakable Toys pattern because the last pattern that I wrote about mentioned this pattern, and it was in the See Also section of the last pattern as well. From the title, I have gathered that this pattern is about just random coding projects that have no consequences and the programmer can just experiment with the code and try out new things.

After reading the Context section i discovered that this pattern involves failure and learning from those failures in order to become a better developer. The problem of this pattern basically says that you work in a field that doesn’t allow for failure, but your individual growth depends on failure. This makes sense because there isn’t a lot of room for mistakes in a real work environment because mistakes can lead to much bigger issues.

The solution to this problem is as I mentioned earlier with slight differences. Rather than coding just random projects, you should code projects that “are similar in toolset” (Oshineye, Hoover). The authors recommend using Wikis as your breakable toy. They say this because of their simplicity. They also mention that they can be great for learning HTTP and REST which I thought was interesting because our Capstone involves both HTTP and REST, so maybe I should start working on a wiki on the side. Another breakable toy idea that they suggested that one of their ex-colleagues used is creating games. This is a cool tool because it is a fun way to learn how to code because at the end you are given a product that you can play with way after the fact. Realistically, you could just look up Tetris on the internet, but it is much cooler if you are playing something of your own creation. Lastly, they mention how this pattern is similar to Be The Worst which is actually what I plan on writing about for my next blog.

The Action section basically just tells the programmer to create a very simple wiki, and add features into it as you continue with your career. I like this method because there are no repercussions if you mess up and you can learn from these mistakes. I think that I will actually use this pattern in the future, and my internship has kind of done this for me too. The projects that are assigned to me are projects that they use in their day to day life, but I have freedom to make mistakes and learn from them.

Practice, Practice, Practice

For this weeks assignment, I decided to write about the “Practice, Practice, Practice” pattern in the book. This one looked interesting to me because I thought to myself, “Obviously, you have to practice, what could they possibly have written for this” To my surprise they actually had a method that I wasn’t expecting.

The article starts off with a context and a problem like all of the sections do and basically the problem is that a programmer doesn’t have room to make mistakes in their daily job, and they can’t learn because of that. This problem makes sense because messing up in your daily job is too stressful. You aren’t given any room to actually learn from those mistakes.

The solution part, like all the patterns, is the longest part because this is where everything is explained. This section leads off by describing the ideal world as being like a school almost. Programmers can be given random assignments and receive feedback on said assignments, and they can get more assignments as they progress. However, we don’t live in that ideal world, so programmers “must fall back on their own resources to achieve the same effect.” (Oshineye, Hoover).

The next part is what really intrigued me. They relate coding to martial arts by saying the katas are a great way to practice. Katas are basically opponent less exercises to take away the stress from the fighter so they can just learn. In programming terms, this basically means just performing exercises on your own to help you learn without the pressure of being fired. I love that someone made an actual coding dojo in Paris because it is such a good idea. It gives people the chance to code stress free, and there are other people there to review the code that is being produced, and help those who are struggling.

The action section tells the reader to find a problem in one of their books that they should struggle with and they should keep doing it and keep note of how their solutions change each time they perform the exercise. This is a great way to learn because it gives the programmer a chance to learn how to better their code and come up with better, more efficient solutions.

Overall, I really enjoyed this section. Like I mentioned before, I didn’t know how they made practice a whole pattern, but it was very interesting. The whole martial arts metaphor worked really well because coding and martial arts apparently have a lot of similarities. I plan on using this method in my future.


The White Belt

For this week’s blog post, I decided to write about The White Belt.  This section is in Chapter 2 which is called Emptying The Cup, and if I remember the introduction for Chapter 2 correctly, this chapter 100% belongs in this section. Like all sections in this book, it is split up into 5 sections, context, problem, solution, action, and see also. The context is a short sentence that basically explains the reader is now confident in his abilities in a certain language, and people rely on them for help. I was actually shocked to read this because typically the white belt symbolizes the beginning, and this book’s description of a white belt is knowing a language and helping people. That’s shocking to me because that just means I have no belt because I feel like I’m in no position to be helping people with the skills I have now.

The next section is the problem. This section was also very short, but it should be because it is only discussing the issue. The issue for this section is that it is difficult to learn new things, and that your “personal development may have stalled” (Oshineye, Hoover). While this isn’t an issue for me yet because I am still learning my first language, this could very much be an issue in the future for me as I also struggle with learning new things.

The solution section urges the reader to start to learn new things by unlearning the things he already knows. They use real life examples as well as some code examples to get their point across. I particularly enjoyed the code section because I liked how they showed the same process being done with two “radically different” (Oshineye, Hoover). languages. They did this to show that because you have a solution in one language, you should still learn a new language to broaden your horizons.

This section was a really easy read for me. The part where they talked about how the white belt had to learn the way while the black belt knows the way really hit me because that was how my internship was. I had to watch and learn everyday before I could even do anything, and it was actually nice to learn along the way because I realized there was so much more that I had to learn before starting my real job.

Apprenticeship Patterns

This week we were tasked with reading and reviewing chapter 1 and the introductions of chapters 2-6 of our book, Apprenticeship Patterns. 

Chapter 1: This was a great introduction to a book. I am not a person who usually reads books because I usually find them boring, but I have to say that this introduction has really grabbed my attention. The parts that really stuck out to me was the very first paragraph, and Dave’s Story. I loved the first paragraph because it says that the book is for people who “have had a taste of developing and want to take it further.” This is an important quote because that includes me and every CS student at Worcester State. This capstone project is some student’s first taste of real development. I really liked Dave’s story too because it reminded me of myself, I have had trouble with software development in my time here at Worcester State, but through my classes, I have developed confidence in my abilities, and learned a lot. The description of apprenticeship also reminds me of my internship because that is what I am doing there. I am basically learning from my master by doing small projects that give me experience.

Chapter 2: I felt that this chapter was more irrelevant because most of us have already passed the step of choosing our first language. By first language, I mean choosing one that we will become fluent in. I have chosen Java as mine because that is what I have learned the most about, and it is the primary language that my job uses as well. However, this chapter did show me that you don’t have to be proficient in multiple languages, but you should master one of them. I also really enjoyed the connection between apprenticeship and the “Tasting a New Cup of Tea” story. It has a really deep meaning of getting rid of bad things, and learning new and better things. I will also be using that empty java class technique for when I need to test unknown features.

Chapter 3: I felt as though this chapter was a direct attack on me. Honestly, I am one of those people that is in this field for the money, and I will probably be taking the job that offers me the highest amount of money. However, after reading through this I will be thinking about learning more about the long road as it could help me enjoy what I do and make a lot of money along the way.

Chapter 4: This chapter was great. I love the “Be the Worst” mentality because I do think like this, but unlike these other people. I haven’t been using that to better myself. I always just assumed I wouldn’t be as good as them, but I should be using that as a way to learn more so I can become as good or better than them.

Chapter 5: This chapter was less interesting to me because it told me stuff that I already know. I know that I need to expand my horizons when it comes to software development. Another reason I disliked this part was because it told me to do a lot of reading, and as I mentioned before I do not like reading. I’m going to use this section as my chapter 6 review too because they both have to do with reading. Chapter 6 was irrelevant to me because I don’t have an extensive reading list nor plan on having one.


The LibreFoodPantry FOSSisms

For this first (technically second) post of this semester,  I decided to talk about the FOSSisms section of the LibreFoodPantry main page. This sections was located under the about section. This sections leads off with a short introduction about what FOSSisms are and it was very useful considering I have never seen the word used before. To put it simply, FOSSisms are maxims that Heidi Ellis developed from, open source culture. I won’t talk about all 16 of them because I would be here all day, but I will talk about some of my favorites. I really enjoyed the productively lost section because it explains that the students should get lost, but that they should use this sense of confusion to learn more about what they are confused about. The last section, I’ll talk about is avoiding uncommunicated work. This section was interesting because it basically says that all work should be communicated with other members of the group, and I think that is extremely important for this project that we are about to take on.

One Month Later, We’re Back

Hello again everyone, I know it has only been a month, but I am back to writing posts bi-weekly for my software development capstone. In this blog, I will be mainly discussing topics covered from the book for CS-448. This is my last semester at Worcester State University, and I’m looking forward to writing more blogs for all of you.