This pattern begins by discussing the fact that many experienced developers will often refer to older books that are assumed to have been read by any developer in their position. If you come across a situation in which you are unaware of the book being mentioned, you should make sure to add it into your next books to read. Often times these old books contained outdated technology but certain ideals and basics behind them never change. You have to be careful though when going into the so-called classics of software development. You must be able to distinguish which books no longer have any benefit as the technology has changed so drastically or is not even still used. However, if you run into a software developer that has a book that seems to be too outdated to still be relevant, you should open a conversation with them to be to get the reasoning behind the book and potentially add it to your reading list.

What I found interesting about this was that often times in classes you do end up reading articles that are from over 15-20 years ago that still hold true. I believe this to be true because of the nature of computing, the basics almost always remain the same, people have just become cleverer on how they can be manipulated. By being able to look into the beginning of how a certain software was created, it can also give insight on how the current version of the software can be improved. Often times when adding to software they are looking only at the most current forms of it, when looking further backwards could also prove beneficial.

I think this pattern has pushed me to start to try and expand upon the books that I read for whatever happens in my path towards a career. All too often, I glaze through texts not fully absorbing what is inside. The times I have genuinely studied the texts and books I was given, I found that I was able to massively expand my knowledge and it really comes down to commitment. I agree with this pattern because they also mention that not only should you keep up with the classics, but you should be mixing in the most modern books as well to always stay up to date.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

I like how in this book the author talks about patterns, its problems and then solutions.

When you are hired by a company, part of a job is to be aware of what you are doing. Are you doing according to the instructions or you are scheming and completing the task by avoiding some minor details. Companies who hire you depend on you. They depend on your intelligence.

Sometimes no one is aware or actually knows how to complete the task. It is very common for entry level software engineers to not know much about how companies want them to do it. Even people who have 10 years of experience, lack some skills when they are given a task.

This creates a problem. A problem where you find yourself frustrated. You would feel unaccomplished and start to question if you are even capable of doing the job.

I have been there and yes it is frustrating. Knowing that you are able to do the task but in some areas you are uncertain. It’s easy to get yourself in a loop of finding the right thing to do. The right thing to do is actually working on a skill where you are having trouble with.

You have to show the people,who are dependent on your work, that the learning is a  part of “delivering software”. You have to be honest with your colleagues and mentor. Let them know that you are unaware of a certain thing. Don’t hesitate to ask for help. The first step to achieve something is to be confident. It sets your mind and lets you focus on the task. It prevents you from wasting time. If the person sees your confidence they would trust your progress and would know that you are capable of doing it. Building trust with your college and clients build strong relationship. This is what you need to have a successful career, especially in the programming field.

You should not ignore what you do not know. You have to learn and go through it because even the smallest thing can make a big impact. This matter is any field. Being in a team, where everyone’s task is to learn, grow and give. If one of the team members fails to do any of the 3 tasks, the whole team fails.

One of the most important traits that a craftsman can possess is the ability to learn, identify an area of ignorance and work to reduce it.

By exposing and then confronting your ignorance you get a much better grasp of the task. You will be able to complete the work with understanding.

I have failed a couple times by ignoring the skills that I don’t know.

In the beginning you don’t feel the urge to actually learn about it but in the long run you would not be satisfied with your work. You would consistently look back and wish you’ve learned that before.

Whenever I get stuck on something I try to do more research on it, read about it, ask someone who has knowledge on it. It is a lot of work but in the long run it is helpful because these small strategies make a big difference.

From the blog CS@Worcester – Tech a Talk -Arisha Khan by ajahan22 and used with permission of the author. All other rights reserved by the author.

The apprenticeship pattern Draw Your Own Map helps express the idea that you create your destiny so to speak. There are things that may be required of you to achieve a goal and other people may be involved along the way but when it comes down to it only you are responsible for the steps you take in order to reach your destination. Your Professors, employers, or counselors can help guide and teach you but they cannot decide for you what you will do. It’s all up to yourself to hone your skills and knowledge to forge your own path, to decide what your goals are. This apprenticeship pattern isn’t just about creating large long term goals either, it’s also about making some goals, the single steps. Having small goals will help lead you towards your ultimate path, failures and successes will help mold you, but the more goals you pursue the more knowledge you will have of yourself.

I think this apprenticeship pattern is especially correlated to my experience in Computer Science. This pattern is all about making your own future and since the very first day of pursuing a Computer Science degree that has been an important skill to learn. When learning about programming you can learn all the textbook examples and read documentation and examples. However, the real learning comes when you start making mistakes. When you start to learn through trial and error along with educating yourself. You learn the skills necessary to be a programmer but in order to program you have to apply those skills yourself. It’s like being an English major who wants to one day write a great novel. You learn all the skills to write well, but you have to create the story, it won’t write itself just because you know the skills. Just as your Professors cannot write your code for you, or your employer cannot apply for your next job for you. You must create your own future with skills that you learn to use for yourself.

Since learning that Computer Science is all about taking your skills and applying them in your own fashion, it has given me insight to my future that I did not have before. It’s true that I do not know where my career will take me specifically, but with my knowledge and skills I learned I know how to get myself there. Wherever “there” may be for you, you can Draw Your Own Map.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

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:

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.

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.

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.

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.

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.