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.

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.

Finalizing Diagrams and Configuring Discord

Last week started on Monday by creating a new issue for adding the LFP upstream master into the CONTRIBUTING document. I then made a new feature branch and started creating diagrams for the commits and their messages document. I also replied to Dr. Jackson’s comment on a merge request and said he can merge the CI/CD documents into master. I then started fixing the workflow diagrams according to Dr. Jackson’s review of them. I did this before continuing on the commits and their messages document since I was using the workflow commit diagrams as the base for these and if the old ones had issues so would the new ones based off these. I fixed the different diagrams and took some new screenshots for the sections that Dr. Jackson said these would work better than diagrams in. I then pushed my changes.

Tuesday started with quickly looking at the coordinating meeting minutes from earlier in the day before the weekly research meeting. In the meeting Dr. Wurst decided my top priority should be working on the SIGCSE paper and writing in the section that pertained to my research project this summer. Then after that would be Discord since we have scheduled a meeting for Friday to configure the LFP Discord server. After the meeting, I read through the SIGCSE paper and then wrote my section about what we have done this summer with researching and testing workflows and features in GitHub and GitLab. After doing that I started looking at how we should configure the LFP Discord server. I read the link Dr. Jackson posted earlier on an issue about Discord and it gave me some ideas we could use. I especially liked the idea of a welcome channel which is where the link to the server should point to to properly induct new users. There were other good ideas too including having different user roles, and limiting sending messages in certain channels. I created a new Discord server to test out a lot of these settings. I also started thinking about how to arrange our current Discord channels and maybe do this by channel type such having text channels be one group and GitLab projects (auto notification bots) be another. I also created a new issue that we discussed during our research meeting about creating a fallback plan for premium features if we weren’t able to keep our GitLab Gold tier membership and were reverted back to Free. Finally, I tested out the README install instructions for the BEAR-Necessities-Market project to see if I could get this to work since someone was having problems getting this to work. I eventually did get this work on both my computers.

Wednesday I checked the paper to see if I needed to make any edits on my section. I then started working on the commits and their messages diagrams. I updated the previously created ones to fix the same errors that the workflow ones had and created a diagram for branch synchronization commits. I added these to the document and opened a new merge request. I then worked on removing the old unneeded GitHub documentation and all GitHub references from all of the ProjectTemplate documents.

Thursday I further fixed the workflow and commits and their messages diagrams according to Dr. Jackson’s new comments. I then worked on writing a Discord configuration and tips guide. I did this by going through all of the user settings available in the Discord desktop application (and web UI) and wrote down what my recommendations were to maximize privacy and minimize annoyances that Discord can cause with its default settings (such as some of the gaming features). I also added the GitLab CI configuration file I created for BEAR-Necessities-Market in the testing group to the actual project on GitLab, so it doesn’t get lost if we delete these testing repositories.

Friday, we had the Discord configuration meeting. This went great and we quickly reached a lot of decisions. The most important topics we covered were the channel structure for the server and the different user roles. We decided that each project would have a channel group with its different channels underneath. We also decided that there would be three roles, Trustees who have all permissions, Mentors who act as moderators with some moderation permissions, and everyone else who have more limited permissions (there is also an admin role for non-trustees for need administrative permissions). We also decided there would be an announcements channel and that we would have a welcome channel to greet new members. After the meeting I started configuring the Discord server and successfully implemented the new configuration plan. Every project got its own group, an announcements channel that bots (such as Yappy) use to automatically post updates for project updates, a text channel, and a voice channel. I also made it so that all of the announcement channels could only be posted to by Trustees and Yappy. I then updated my Discord configuration guide to include the new changes to the channel structure and also added an invite link to our CONTRIBUTING document for the Discord server. Finally, I responded to some questions on Discord about where some documents and work was located in GitLab.

Saturday, I deleted all repositories and groups under the various testing groups we created this summer on GitLab and GitHub so that they weren’t lingering around past this summer. I also added DCO checks to the remaining projects that needed them and double checked that all of the projects had this enabled. Finally, I assigned myself to some issues to work on for next week and created a new issue for the broken screenshots in the various ProjectTemplate documents.

Processing JSON Data with Jackson

The article that I read this week is about processing JSON data with Jackson. I thought this would be a good article to read after using JSON data a lot this week for processing input and output in our final projects, and since Spring Boot uses Jackson as the way for processing JSON. I wanted to learn more about how this works, especially after getting some errors when trying to pass in certain data types this week (particularly Calendar objects). This post goes over how to read and write JSON data to and from Java objects using Jackson for data binding. It does this by creating an example POJO to use for input and output. It creates a basic employee with the fields of name, ID number, address and other typical fields, it also has an object within an object by using an address within Employee that contains a street, city, and zip code. The article creates an example of this in a JSON input file and creates the necessary Java classes and then implements the Jackson methods (such as ObjectMapper) for databinding and outputting Java input as a JSON file.

I think that it was interesting to see how to do this with the Jackson implementation as a seemingly more proper method of converting JSON to Java objects and the other way around. Especially after spending the past week creating and getting our project to pass similar data back and forth between JSON and Java. It does seem out of the ordinary to me that both of the example classes don’t use constructors, instead using just set methods to create the object, but that’s how this implementation is supposed to work with Jackson. I particularly liked the Tree Model implementation in the article and was not aware that this was a way of processing JSON data. This article has definitely made me think more about the different ways of processing JSON data with web applications and REST APIs and the best practices to use when doing this, especially with larger, serious implementations for applications. If time permits for our final project, I would like to try and do a similar implementation in this article for our JSON processing. By doing this, it would make adding new objects to the database a lot cleaner (especially without needing a constructor) in the implementation than it currently is.

Source: https://dzone.com/articles/processing-json-with-jackson