Category Archives: Week 13

FPL&S 4: User Login, Email Verification, and a Hard Lesson in “this.”

Before creating a database, I needed a way to associate files with a user. This requires user authentication, which is thankfully provided by Google Firebase. In my experience, 3rd Normal Form (3NF) is the best compromise in database normalization, so I strive to achieve this when creating one. Therefore, instead of blindly implementing file storage for a single user, I put some thought in ahead of time of how I would store the data. Currently there are not many data to store, but 3NF is helpful in allowing for additions to a database in the future.

Google’s authentication provides a familiar, smooth interface for users to login or create a new account. In properly-designed, object-oriented software, it is a quick and secure way to implement authentication to quickly launch a product and still easily replace it with your own authentication implementation in the future. The API took a little getting used to (and again, their documentation is not easily converted to Typescript), but it only took a few hiccups to get everything working reliably.

The biggest of the hiccups was “this.”, (pronounced “this-dot”) when referring to member variables. I’ve heard legends of the horror of “this.” in JavaScript. I’ve seen Twitter posts lamenting the language for its strange behavior. But I never expected this.

In typical Java fashion, I was using callbacks for the authentication service. The module would need to update member variables, which are bound to elements through the *ng-if directive. Coming from Java, I naturally assumed calling “this.variable” within the callback would change the value, and the console was printing the correct value, but only within the callback function. As soon as it finished, “this.variable” was the old value. As it turned out, I was referring to two different “this’s”.

The problem is that “this” refers to the context in which a variable is called, not the class in which it is defined. This Stack Overflow post has some good answers describing why and the proper way to use it. My solution was to use arrow functions to pass the correct context to the callback function when I subscribed to it, like so:

ngOnInit() {
    this.angularFireAuth.authState.subscribe((user) => {
        this.firebaseAuthChangeListener(user, this);
    });
}

Subscribing to the authState gives us a user object, which needs to be passed to the custom callback function. ngOnInit() is called to initialize the Component, so the context is the Component itself. Therefore, we can refer to it using “this”, which we do to refer to other services and methods. Modifying the callback function to also take the context means we can modify the member variables of the Component using this argument.

I tried a few other solutions, but this was the simplest and the only one that reliably worked. If there are better TypeScript solutions, I’d love to hear them. For now, I can reliably register users and use their unique IDs to associate them with their file uploads in the database.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.

Imagine Getting Trash Talked By a Robot?

Alright everyone, I decided that for this week, I am going to move away from a QA article and talk about a general CS article. To be more specific, this article was about robots, and how even the words that they say can affect us humans. On first glance of the article, I read the title wrong and thought that humans were just bullying robots and seeing their reaction, but it is the opposite, robots are bullying humans.

The study conducted recently is a study about how human performance is affected by discouraging or encouraging words coming from a robot. They used a video game and the robot would comment on how the player was doing. It turns out that the robot saying mean things to the player about his performance caused the player to actually score lower than that of a player who was praised. As someone who dabbles in video games, I understand that people will talk about my bad skill, and I do believe that it makes players worse at what they are playing, but I didn’t think the words of a robot could have such an effect.

The test was conducted by Aaron M. Roth on about 40 participants. This test was important because most tests take a look at how humans and robots can cooperate, but this test looks at how they are when they are uncooperative. This isn’t tested as much so I fell that it is important to test this because as AI continues to develop and get better, we may see ourselves in a situation where a robot can become uncooperative. This study was done just to show that while human words definitely affect human performance, the words of a robot who is programmed to say such things can also be detrimental to us humans. We really are a weak race if I’m being honest.

I really enjoyed reading this article. The reason I chose to write this article over another QA article is that there are more ideas to write about in general CS where as QA articles are almost all the same. It is usually about the trends of 2019 or 2020. This was the first article I saw in the CS articles, and it was about robots bullying humans. This was really easy to read, and it was even easier to write about. My next blog is my last blog for the semester I believe, so hopefully there will be a great article for me to write about next week.

https://www.sciencedaily.com/releases/2019/11/191119075309.htm

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

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.

 

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

You Must Learn To Unlearn

Hello, again my fellow readers!

Last week we took a look at the beginner pattern, Your First Language. This week we will continue along the path to the next pattern, The White Belt.

As I have said, The White Belt is the next apprentice pattern after, Your First Language. This pattern is all about what to do after you have learned your first language and can strut your stuff with it. The problem The White Belt pattern is here to solve is when learning a second language becomes tiresome and tedious. Learning one language is great but, expanding your library is a must to become a software craftsman. What can happen, however, is slowdowns and stalling in learning. The solution to this is to adopt the mindset of a white belt. To quote the book, “Wearing the white belt is based on the realization that while the black belt knows the way, the white belt has no choice but to learn the way.” In other words, while you go about learning a new language, treat it as if it was brand new to you, even if you are learning something with familiar attributes. An excellent example is you have learned Java and now you are learning JavaScript. Both are fairly similar to each other and have overlapping ideas and methodology. Using the white belt philosophy, treat learning JavaScript as if it had no relation to Java. While this may seem counterintuitive (it still does to me),  the pattern claims that it will accelerate your learning. It will also allow you to discover new possibilities, as well as your mind, is open and without preconceived notions.

I understand where this pattern is coming from. I do get that an open mind can, and most likely will, lead to new possibilities. I agree with that. I suppose that my issue is that forgetting to accelerate learning is still something I find a bit backward. Looking at it, I must admit that I have not tried this method. Typically I find that making associations to things you do know is a good memory tactic and can speed up learning. It is entirely possible that the White Belt pattern will work for me. The only thing for it is to try it. I can legitimately say it doesn’t work without trying it for myself now can I?

Looks like I have some unlearning to do in my future.

Until next time readers!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Find Mentors

Hi dear readers. Welcome to my next blog post. In this blog post I am going to talk about the next pattern called “Find Mentors”. I strongly believe this is a very important pattern and I will explain why below.

In the path of your career, you will always find yourself struggling learning about new stuff or not knowing what to learn . Don’t freak out though, this is normal. I know it sounds weird, but this is just the start of your journey and you are expected to not know everything. However, sometimes is very hard on to determine what to learn next or what is your next step in your career. So as the book suggests, a mentor is always a good help to have.

Finding the perfect mentor for you is not easy and you probably will never find him/her. It is true that there are a lot of people out there who  are professionals in what they do, but that doesn’t mean they are meant to be mentors. However, do not get discouraged because there are plenty of people who like to be mentors, you just got to be patient until you find him/her.

Another good point that the authors make in the book is that you might change mentors often or have multiple mentors as different people are specialized in different areas and have different knowledge. The hard part in all this process is finding and convincing this person to be your mentor. It might be awkward for you to ask and also weird for them. Unfortunately there might also be cases when they will refuse, but do not get discouraged. You will find other mentors. If you really really like a specific person to be your mentor, you got to win his/her ‘heart’.

While you grow you will be able to understand if you are in need of changing mentors and there is nothing wrong with that. Also as they teach you, you will understand what you really like and what you want your focus to be in. So start being part of communities and look for your mentors based on what you’re interested.

From the blog CS@Worcester – Danja's Blog by danja9 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Find Mentors

The apprenticeship pattern Find Mentors refers to the problem in which you feel like you require help and guidance because you’re not sure where the path is taking you and you feel unprepared for what’s to come. The solution to this is to reach out to other craftsmen who are ahead of you and to try your best to learn from them.

This pattern in particular was interesting to me because I feel as though I’m at or nearing a point in which I would benefit greatly from mentorship. Of course, no matter how far along the path you are, there’s always something to gain from mentorship. People who just graduated or recently graduated, I feel, are more likely to have that feeling of being unsure of what they should be doing. These are the people who need help and guidance the most in order to push them along the path. Even though it would be ideal for apprentices to find mentors, it’s definitely not as simple as it sounds. I’m certain that some people who are in need of mentorship don’t feel as though they know anyone who they feel comfortable asking to be a mentor to them. One of the most interesting parts of the section is that, even if you feel intimidated about reaching out to someone to ask for an apprenticeship, the risk of being rejected or considered strange by a potential mentor is relatively low, while the potential payoff is huge. So, if you find someone that you’re really interested in learning from, you should definitely reach out to them as there’s so much to gain.

I don’t feel like the pattern really changed the way that I think about Software Engineering, but I think my biggest takeaway from this is the make sure to not be too intimidated to reach out for mentorship. Had I not read this pattern I’m certain that I would have felt that way for a long time, so hopefully in the future I power through. I think it would be a good idea to seek out opportunities to find potential mentors in the future.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Sprint 5 Retrospective

This past sprint was not quite as productive as we would have liked, although we did manage to start making great progress towards the end. In the beginning we ran into a tremendous amount of roadblocks. Between angular versioning, formatting errors, and more, we were really struggling to get off the ground in terms of productivity. It seemed as though, once one person had the local environment running on their machine, it broke for someone else. It wasn’t just a couple of us having issues, either. Each person in the group seemed to encounter some error at some point in time.

First, one of our members was struggling to build the angular environment at all. A fresh install of angular was required, which seemed to have fixed the issue. After that, I was facing some issues with something called polyfill.js, which was interfering with my ability to get my angular server running at all. Stack overflow wasn’t of much help because most of the issues I found posted were suggesting that I alter package-lock.json files, etc. These were all things that my teammates didn’t have to do in order to get the server running, so I figured that the solution was simpler than that. I was correct in my assumption once I remembered that AMPATH recommends that we run ng serve with the –prod tag as well. Upon doing this, the issue with pollyfill.js resolved and I could run the server perfectly fine.

Not only this, but we seemed to have many issues with git branching for whatever reason. We had previously played around with another group’s branch in order to confirm that we could get styling running at all on our local machines (which is how we realized we needed to ng serve in order to see styling). This ended up being a bit of an issue for a few of our team members, because they were seemingly unable to git checkout back into our branch — git was declaring that they didn’t have permission to join the branch again. In order to fix this, those members decided it was easiest if they just deleted the repository locally and recloned the project. Upon all of these changes, we were finally all caught up and able to ng serve nice and cleanly, without any big red errors.

Once we had fixed angular environment issues, we moved on to development and actually got some design happening. A big issue we were trying to conquer was that our angular form component using the material design “mat-form-field” module wasn’t displaying correctly. It was a standard HTML text field as opposed to the correct Angular Material styled one. Last sprint we discovered that we were being a bit silly with this and that we needed the angular server running for the text boxes to display correctly, but even still, our field component wasn’t functioning how we had anticipated. After playing with some other components (material design checkboxes, etc.) I realized that we foolishly hadn’t important the library for the material input field, which was nested within the form field. Due to this, it was completely un-styling our entire form field. After importing this correctly, it was (and has been) development game time.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Practice, Practice, Practice”

The apprenticeship pattern framed the problem is that if you do not have room to make mistakes in your day to day programming, you will not have room to grow. The next line hit close to home, “It’s as if you’re always on stage.”

I learn quite a bit from my school assignments, but I don’t always think I have mastered each area before moving on to the next topic. The problem arises when I know my code could be improved upon, but it’s currently working. I don’t want to restructure my code too much, because I’m afraid of making it worse.

The term comes to mind, “If it ain’t broke don’t fix it.” I have problems with this way of thinking, but when you’re pressed to make something work before the impending deadline, “good enough” is sometimes feels like the only option I have left.

This pattern champions a different approach to this kind of mentality. I like the idealized version that they have laid out based on the research of K. Anders Ericsson. This describes where a mentor would assign you a task based on your strengths and weaknesses. Once you have finished your mentor will review it and point out areas for potential growth the next time.

A important distinction the pattern makes is that we cannot use our profession to practice because when you practice, you make mistakes. You need to find time outside of your work session and make those mistakes when you practice.

I realize having a mentor may not always be realistic for everyone. However, I think I have a way to practice this over the summer. I have been talking to one of my classmates who has started a small consulting company. He offered me a position if I was interested, which I am.

They are currently is contracted by my alma mater, Quinsigamond Community College, to keep track of the information that is collected by their greenhouses. He has hinted that he might look to expand it if he is successful.

I feel this closely fits to what the pattern suggests. I will have a mentor. I will be practicing my skills and having close feedback. I will have room to make mistakes as my status as their employee does not solely rely on my performance. Don’t get me wrong, I still want to do a  good job, but it is not extremely high stakes. There is also the freedom to work when I choose, so I won’t be constrained by time, especially when I am going to be lifeguarding and taking a summer course. I am excited to begin this new chapter in my life — a new step on the journey towards mastery.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Confront Your Ignorance

The apprenticeship pattern I’m addressing this week is Confront Your Ignorance from Chapter 2: Emptying the Cup. This pattern follows the previous pattern in the same chapter, Expose Your Ignorance, which I’ve previously written about here. The idea is that, once you’ve identified where your weaknesses are in your area of work, you must confront those weaknesses in order to grow. It’s hard to know where to start. Sometimes you’ve pinpointed weaknesses in areas where it is expected for you to have expertise, and it seems like you’re the only one who actually has those weaknesses. It’s hard to know where to begin. Confront Your Ignorance suggests that you choose one area and start filling in the gaps. Do so in whatever way is most helpful for you — whether it be through introductory guides or through diving right in.

This pattern is actually very helpful for me in this very moment. Over the past few days, I’ve been dwelling extensively on what I do and don’t know. What is expected of me as a software engineer, and what I expect of myself in this discipline. I’ve come to recognize that I have many weaknesses that I’d like to eliminate — things like algorithms, many topics in systems engineering, and so much more. There’s a lot of things I would like to experiment with, and there are also a lot of things I need to understand before I can do that. Frankly, it has been pretty overwhelming to constantly think of all of these things at once, and it’s been fairly discouraging as well.

I’ve exposed my ignorances (or rather, they’ve been exposed for me through the interview process), and now it’s time to work on them. It’s not going to change over night, and it isn’t going to change all at once. However, it will improve through consistent, deliberate work. That involves choosing one topic and chipping away at it over time. The difficult thing for me is likely going to be choosing which topic to work on, because I have so many things I’d like to learn. I suppose I can’t go wrong though, so long as I commit to learning and keep checking new topics off my list.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Pattern 9 – Find Mentors

This week I decided to learn about how to “Find Mentors” by reading the pattern. This pattern gives advice about why and how apprentices should seek out to find mentors to continue down the path to becoming a journeyman. They give tips about attending conferences, joining online forums, and taking your potential mentors out to lunch if you have the opportunity.

I do agree that finding mentors is greatly important in the development process to become a successful software developer, but I think this pattern idolizes a certain type of developer and therefore limits the opportunities for mentorship for those who try to strictly follow what the pattern is advising. This pattern seems to focus on those who are directly working on the development of a particular language, framework, tool, or some variant of open-source software. They even pretty much open with the idea that it is very likely that your mentors are not local and that you will likely never meet them. I think that this is where the pattern is failing.

From my experience, there is almost always someone, or a group of people within a company that those with technical positions turn to for mentorship and advice. At my most recent internship, it was a man named Kurt who has worked on the proprietary software (Oracle) before signing onto the company that we both worked for over the summer (TJX). He initially was a contractor from Oracle, but TJX found that his expertise regarding the frameworks that made up our software made him too valuable to let go of and they hired him full time. He immediately became the go-to guy whenever anyone had a question about our software. He had been working on it for over 15 years and had gone through over 10 iterations of the software. A key thing to note is that while everyone asked him for help, they weren’t asking for mentorship. This is something that came with my internship as he was selected to be my “buddy”, which was just a fancy word for mentor. We spoke several times throughout the summer about both career goals, and different ways to solve problems. We spoke about how to solve certain problems that were specific, yet more general than our specific code base. To get this kind of mentorship, I didn’t need to lurk on an internet forum, and the same went for everyone I worked with that wanted to learn from him. All I had to do was ask. There will likely be a Curt everywhere, any of us end up working, and I plan on utilizing their mentorships.

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.