Category Archives: Week 13

CS-343 Final Project – Part 2

Over the weekend, I have started working on my CS-343 final project by creating a simple Angular application that I will use as a base to build the rest of the project off of. The application simply draws a rectangle with a length and width that are entered by the user. When the user enters a new width or height, they can click a button to update the rectangle without reloading the page or loading a new page. The application currently looks like this:

The Default State – 50 X 50 Rectangle
Editing the Dimensions to 150 X 225 (Note that the text stays centered)

Although this application is extremely basic, writing it has greatly improved my understanding of TypeScript, CSS, and especially HTML. While the in-class activity on Angular helped introduce me to the basics of HTML, researching and working with HTML on my own has definitely made me more comfortable with it.

I started writing this program by creating elements to take user inputs with text fields and buttons, using the class activity as a reference. I researched the HTML tags I needed to create these elements, and I came across a site called w3schools.com that provides documentation of HTML tags (such as <form>) as well as executable example code to demonstrate their uses. This site proved to be a valuable resource for understanding HTML, and I will certainly continue to refer back to it as I continue work on my project. Once my input forms were created, I quickly discovered that submitting data in a form refreshes the page by default, which I did not want to happen. I found out through research that writing ‘onsubmit=”return false”’ in the <form> declaration overwrites this behavior, and I quickly added it to my forms.

Next, I researched how to draw a simple rectangle that I would resize according to the input. I found that I could create one using the <div> tag and specifying its dimensions in its style field. I also discovered that I could change these dimensions code by setting an id for the <div> and using the ‘document.getElementById’ function to edit it from the TypeScript code, allowing me to pass data from my input fields to my rectangle

At this point, I could successfully resize the rectangle using user input. However, the ‘Text’ label was not centered in the rectangle, and I decided I would try to fix that. I came across another page from w3schools that explained how to center text both horizontally and vertically using CSS. I decided I would make the rectangle into its own Angular component so that I could put all the necessary style information into a .css file, and I managed to figure out how to do this by referring back to the class activity.

So far, this project has taught me more about HTML, CSS, and Angular components. It has also led me to several helpful references, such as w3schools.com, which I am sure will help me going forward. Now that I am feeling more comfortable with HTML and Angular, I plan to work on creating more elements that take user input and organizing my components into a more interesting layout similar to my wireframe. I am really starting to enjoy working with HTML and TypeScript, so I am looking forward to making more progress on this project in the coming week.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

More SPA progress

With the semester coming to an end and the holidays, I’ve been busy and have not made as much progress as I would have liked on my SPA. I did find a better way of obtaining the evolution chains. The looped API calls were a sloppy solution, but I realized I could simply make multiple calls per input. After that I tried to find a way to visually organize the evolution families, but my nested Angular loops make it difficult to style and I haven’t found a satisfactory solution yet.

I have implemented the popup that displays the entire evolution family. The popup blocks interaction with the underlay and forces focus on the popup until dismissed.

A general issue I have ran into is the SPA updating as it fetches data. This causes the images to load at different times, affecting layout. I also have an issue where the page does not always grab the evolution family causing it to occasionally pass a null evolution chain. Searching a second time often fixes this but I am not sure of its cause.

My goals for this project now are to polish up what I have and find some new useful functions to add.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Making Sense of Static Testing

Last week in CS-443, we did a class activity on static testing tools. These tools are able to detect issues in a program without executing the code. Previous activities had focused on dynamic testing, which does involve code execution, so static testing was definitely new to me. However, I had a hard time learning about the tools due to problems I had with the activity. One of its early parts involved building and running a batch file for the project we were working with. This batch file refused to run properly on my computer, so I was unable to progress with the activity and thus did not get to work with the static testing tools for myself. I observed what my group’s technician did with the tools, and it was interesting to see them in action, but I had a hard time understanding what the tools were doing since I was not working with them myself. Today, I decided to address this problem by revisiting the activity on my own and doing extra research into static testing.

Unfortunately, I was unable to get the batch file to run on my computer. No matter what I tried, it always failed to find or load the main class of the project. After about an hour of messing with file directories, I decided it was not worth spending more time trying to get the batch file to work. I was able to run the project using the gradle run command, and I decided to move on so I could actually try working with a static testing tool. The tool I worked with was Checkstyle, which looks over the code and makes sure it complies with the style guidelines specified in an xml file. I found it interesting that the tool is fully customizable, as the guidelines it checks for can be changed by altering the xml file that the tool uses. The tool is also extremely simple to add to a project, as it only requires a few extra lines in the build.gradle file: one to add the plugin, one to state which version to use, and one to declare which xml file contains the style guidelines.

Although I was able to figure out Checkstyle, I still was not sure I understood the fundamentals of static testing. I decided to do more research instead of continuing with the activity, and I came across an article from Guru99.com about the basics of static testing and testing review. I think the article does a great job introducing the concept of static testing and explaining why and how it is used. It is from reading this article that I learned the difference between static and dynamic testing. It also explained to me why static testing is used and introduced me to different types of static testing, such as manual reviews. I won’t go into every detail about the article here, but it definitely helped me make more sense of static testing and I certainly recommend it to anyone who is also confused by it.

You can find the article here:

https://www.guru99.com/testing-review.html

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

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&#039; 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&#039;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.