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.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

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

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

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:

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

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

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

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I’ve decided to watch a video titled, “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. This video is actually part of a series titled, “Object Oriented Design” and in the next video Derek shows how to create code from the UML design he’s created. Since I will likely be making more UML diagrams in my educational/professional life, I figured it would be good to further develop this skill.

One of the first things Derek mentions in this video is that he will be showing both the analysis and design stages for this process. The program that Derek is tasked to create for this video is a coin flipping program for two individuals. One player selects heads or tails, the other player gets assigned the other coin side, and the winner and loser is selected. Derek starts this process with something called a Use Case Description. For this description, Derek has a basic text editor open with the following categories: description, triggers, actors, preconditions, goals, not available, and steps of execution. Derek goes through each of these categories and writes in the relevant information for the program he needs to create:

1. The description describes what happens in the program.
2. Triggers mention how the program/game starts.
3. Actors include the two players, the coin, and coin game.  
4. Preconditions lists the things that need to be true for this program to run (i.e. 2 players are available, a coin is available).
5. Goals list the outcome of the program (i.e. one player wins and the other loses).
6. Not available references potential invalid inputs and extensions on how to make the program better in the future.
7. Steps of execution describes what the program will do in a numbered list (each number represents a specific task).

Although this was only one part of the 30 minute tutorial, this was still an extremely useful process for me to observe Derek do. I learned how important it is to critically think about what you want your program to do before you jump into programming. I am definitely guilty of trying to jump into coding sometimes but I can see how cleaner and clearer code can be written by thinking and mapping things out in advance.

The thing I’m happiest about from this blog entry is finding this series and Derek’s YouTube channel. He has multiple tutorials on his channel that I can see myself learning a lot from. His videos are educational and thorough (many of them are 20-30 minutes long). As I continue growing as a programmer, I will definitely be referencing him to learn more useful information, techniques, and procedures.

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

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I’ve decided to learn more about API documentation. I found a YouTube video titled, “Get an overview of the Java API documentation and how to use it” in order to do this. The reason I picked this topic is because as I create and design programs/software, I will likely be referencing Java API documentation. Therefore it is important that I understand and know how to navigate this information. 

One of the first things this tutorial taught me is that the documentation I will be using will be under Java SE and not Java JDK. The speaker of this tutorial, Steve Perry, did not go too in depth into what Java JDK is so I ended up doing some additional research to learn more about JDK. JDK stands for Java Development Kit and it is a platform released  by Oracle Corporation to develop Java applications. Although this may seem like a trivial thing to learn, I appreciated learning more Java/programming jargon.

After explaining that the different classes in API documentation are grouped by modules, Steve selects the java.base module to walk through because of how commonly used it is. In modules, there are packages which are a group of related classes. The first package Steve introduces and reviews is the java.lang, which contains classes that are fundamental to the Java language. He explains that each package starts out with a description of the package, followed by its interface, classes, enumerations, exceptions, and errors. Steve also refers to the documentation of this particular class as a javadoc which is something I’ve heard before but now know exactly what it refers to. 

Steve then selects the String class, again, because of how commonly used it is. We then learn how to access String’s constructors and methods. Steve shows us how clicking on a method gives you more details, such as a method’s description, parameters, return values, etc. The last useful bit of information I learned from this video was how to access the information for classes if I don’t know what module or package they may be in. I can do this by using the index or clicking on the top left section titled, “All Classes” in order to do so.

Overall, I considered this to be a very worthwhile use of my time because API documentation is something I often get redirected to when I have a question about a particular class I’m using. However, since API documentation contains so much information, I often get overwhelmed and lost in all the classes and information available for a particular class. Because of this blog post and this tutorial, I was able to learn the organizational scheme for API documentation in a way that I will remember. Although it may seem like a small step, it’s a step that makes me a little more confident as a java programmer.

Tutorial link: https://www.youtube.com/watch?v=ULEOb8wLa_k

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

The article I’ve decided to read for this blog entry is titled, “Getting Started – An overview of Markdown, how it works, and what you can do with it.” The reason I picked this article is because it is connected to our first homework assignment. Our first homework assignment has us working with UML class diagrams and when I clicked on the web IDE on GitLab, I was brought to a file that was written in Markdown language where I would have to add my Java code and create PlantUML class diagrams. I’m not too familiar with Markdown language and since I would be interacting with it for my first homework assignment, I figured I’d do some research to learn more about it. 

The article I read starts out by defining Markdown language, “Markdown is a lightweight markup language that you can use to add formatting elements to plaintext text documents.” The article then goes into explaining why people use Markdown. I’ve learned that Markdown can be used for essentially anything: from websites, documents, notes, books, presentations, email messages, to technical documentation. I also learned that Markdown is platform independent and that the content that is created on it doesn’t get locked into a proprietary file format like Microsoft Word. 

Next, the article discusses how Markdown works. This process can be generalized into four steps:

1. Create a Markdown file.

2. Open the file in an Markdown application.

3. Use the Markdown application to convert the file to an HTML document.

4. Render the HTML document to a web browser (or another document).

During this part of the article, we also learn more about Dillinger, a Markdown editor that combines these steps. It was useful for me to learn the name of this editor because if I were to ever use Markdown for myself, I now know a common and popular editor to do so.

Lastly, the article’s main ending point is that there are many different “flavors of Markdown” and that using Markdown with one editor may provide a very different experience than using Markdown with a different editor. Many of the basic syntax may be the same but there are extended syntax elements that likely differ.

One of the biggest takeaways for me is that after I finished reading this article, I looked into other kinds of markup languages and learned how they are different from programming languages and scripting languages. Unlike programming and scripting languages, markup languages are presentation languages that do not do logical operations. It’s safe to say that, now that I’ve learned about Markdown, I feel more confident moving forward with my homework assignment (even if what I learned was going to be only a minor piece of my overall assignment).

Article: https://www.markdownguide.org/getting-started/

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.