To be successful in software development field communication, dedication of working along with different work environments, gaining trust from team members and clients is important.

Imagine you are new in a fully developed team. All team members know each other well enough to be comfortable discussing the software that they will be working on. And there you are, unaware of the work environment, software and team members. It is because you are new and also because they are unaware of you as well. Now, if you don’t start communicating with your team because of lack of experience or knowledge on a software, programming or any specific task in hand then you will prevent the team’s growth and their trust in you. 

In order to prevent any miscommunication, try to ask questions, add up your opinions, learn from them, shadow how they are doing and ask to volunteer. Taking small steps in account will never lose their trust in you. They will acknowledge that you are willing to help even with little knowledge. Such as, maintaining, reviewing code, “bug fixing, eliminating technical debt, setting up the project wiki, updating documentation, acting as a sounding board for other people’s ideas, and so on.” Try to focus on less edgy work, where there are less risks rather than “rather than the core where there are usually many dependencies and lots of complexity.”

Acknowledging simply takes you from doing nothing to doing something  meaningful for yourself and for the team. It will be hard beauce you are putting time and effort into something that isn’t big enough for you to enhance your programming skills. But if you take in this action and do more research and discuss with your group you will soon be able to help in complex areas on a project. 

It is something that everyone complains about when they are in this situation. It is like being an intern again. It is a slow process towards your growth in the field but the only way to get out of it is to be patient and try to give your efforts to contribute to the project.

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.

Today I have decided to post about the “Record What You Learn” pattern. This pattern is targeted at developers who find themselves repeatedly learning about the same topics. Some lessons just never seem to stick in their memories, and they often forget the details of their past works. According to the pattern, simply recording what you learn in a journal, wiki, or blog can be an effective solution to this problem. Keeping such a record not only helps reinforce old lessons, but it can provide us with a powerful tool for drawing new connections in our knowledge and developing new lessons to pursue. A record also helps us understand how we came to develop our skills and allows us to easily share our experiences with others.

I decided to read this pattern because I often find myself repeating old lessons. Many programming projects I have worked on, both on my own and for school, have required me to reapply topics I worked with in the past. More often than not, I struggle to remember all the details I need and have to search for tutorials or guides to refresh my memory. In fact, my list of bookmarks in my browser is crowded by tutorials that I have needed to return to many times. Whenever I find myself searching for help with an old skill, I just get frustrated with myself for having a poor memory. I never even considered keeping a record of my lessons to make them easier to remember.

Reading this pattern has definitely changed my perspective on my troubles with remembering old lessons. I may be having these difficulties because I have not done anything to reinforce my lessons, and not simply because my memory is bad. I definitely think keeping a record in a journal or a personal wiki would be helpful to me. Instead of searching through my list of bookmarked tutorials for hours searching for one bit of information, I could simply refer to my own record to find what I need quickly. A record would also make it easier to reflect on my past lessons, which I think could help motivate me to continue learning new things. In addition, a record might make it easier for me to help others learn skills, as it would allow me to look back on how I learned those skills myself. I was honestly surprised by how useful recording what you learn can be, so this pattern has made it clear that creating a record of my lessons would be worth doing.

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.

My final project has not been an easy task to deal with thus far. After going far in depth with one of my designs, I came to discover that the use of angular material alongside bootstrap which caused quite a few problems. I have decided to do a full overhaul into angular material. The reason I am choosing angular material is because there seems to be more typescript capabilities while bootstrap seems to be heavy on javascript and css. By going down this path I have been able to make steady progress with my current version of my application which at the time is mostly an interactive sidebar. The main concern I will have this week is being able to make the workouts appear on the home page. I would like to be able to use angular to create a visually appealing layout which will allow for the user to go through the different workouts and select the ones that they would like to use. If I was able to have more time on something like this my end goal would be to add in I/O devices such as being able to print your workout after it has been created. Due to time restraints I will have to remain with simply being able to select and track the wanted workouts on the app. Another large problem I will have to come up with a solution with is whether or not there will be a way to save workouts, or have the workouts appear and when the next desired workout regime is needed, to simply delete the old and then add to the new one. Another issue I have run into is being able to seamlessly add in new workouts to the app without having any effect on the previously existing workouts. This next week will be the time to grind out any and hopefully all of these problems. I have been diving deeper into angular material in order to get a better understanding. I have also been researching more html and css as I have not had much prior experience with these. This has caused me quite a bit of stress because very minute changes have broken the entire app, but I believe that by completing this I will have gained the necessary knowledge of what will be needed in the future. I am excited to complete this app but it is also been an extremely difficult time which will all pay off in the end.

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

Over the past week, my work on my CS-343 Final Project has been focused on creating a more interesting layout for my components. I have not changed the function of the program or added any more features yet, but I think I have made some great progress towards making the GUI look more like I planned it to in my wireframe. The program currently looks like this:

I managed to create this layout by making use of Angular’s Grid List material. Using material.angular.io as a reference, I was able to figure out how to import this tool into my project and use it to arrange components with the <mat-grid-list> and <mat-grid-tile> tags in my app.component.html file. By combining this information with what I learned about CSS and HTML last week, I was able to create the layout pictured above.

In addition to working on the layout, I made some major changes to the project’s organization. One significant change was the creation of a new Angular component: the options-menu. Previously, the input forms for changing width and height were simply parts of the app.component.html file. I decided it would make more sense to create a new component so that these options and the new options I plan to add this week will stay organized in my new layout. Another major change I made was in the way data is passed between components. Before, I simply had the input forms in the app component update the size of the rectangle by searching for it by its id. Now, the forms actually pass data from the options-menu to the rectangle using a data service. I decided to implement this method of data sharing after reading about it in this article on angularfirebase.com (see the section on Unrelated Components). I had difficulty understanding how a data service works at first, but I eventually understood it by messing with my own. Creating a data service has definitely made passing data between components far simpler than it was before, and I plan to add more to it this week.

As I am due to present my completed project this Friday, I have less than a week to finish working on it. My plan for this week is to finish adding the features I planned for the project in the beginning. This includes making a simple puzzle game that can be played in the rectangle area, as well as more options to configure it besides the width and height. I would also like to work on cleaning up my layout to make it more visually appealing. Finally, if I have time, I would like to create a back-end server that will allow users to store their scores form playing the game. It seems like a lot to add, but making this layout and creating a data service have only made me more comfortable working with the Angular framework. I think I will be able to complete much of what I have planned in time for Friday.

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.

In my previous blog for CS-443, I discussed my experience revisiting the class activity about static testing tools. I focused on figuring out the Checkstyle tool, which makes sure that the code complies with a set of style guidelines specified in an xml file. However, the class activity dealt with more tools than just Checkstyle. Today, I would like to look at the second part of this activity, which deals with tools that detect actual bugs rather than simple style issues.

The bug-finding tools that the activity focuses on are FindBugs, SpotBugs, and PMD. Much like Checkstyle, these three tools are extremely easy to add to a Gradle project by adding a few new lines to the build.gradle file. They each require just a single line to apply them as a plugin for the project. In addition, a small block of text can be used to set different properties for each tool, such as their version number. The activity also recommended adding lines to the options for FindBugs and SpotBugs to report their findings in an html file, since they use an xml file by default. This made the errors much more readable and easier to understand. Finally, a single line must be added to the Dependencies for SpotBugs to function.

Once build.gradle is properly configured, the tools are run simply by building the project (or calling “gradle check,” as I discovered). All three tools will then analyze the code and create reports explaining the types of errors they find. I ran the tools on the code provided for the activity, and I was surprised by how useful their reports were. They point out code that follows bad practice, code that may cause compatibility issues on different platforms, and even code that may negatively impact performance. I find it interesting that these tools are able to detect such errors without running the code, and I definitely see them being extremely useful as I often do not detect such errors myself even after hours of searching for problems manually.

Since these tools are so effective at finding errors, I was curious if there was even any benefit to using manual code review over one of these tools. I did a bit of research into this, and I found a blog post on synopsis.com that I think makes a great point – that these tools are unable to understand the context of potential errors in the same way that a human can. The blog also lists eight major limitations of these tools that should be considered when using them over manual review. Although static testing tools are able to find error in code quickly and easily, it is still necessary for the developers to determine whether the errors detected are valid or useful.

Link to the blog:

https://www.synopsys.com/blogs/software-security/static-analysis-tools-finding-bugs/

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.

By now, I’ve become rather accustomed to Typescript, Angular, and even CSS. Once the basic functionality of this project was working, motivation and momentum made it easy to continue adding more features. As evidence 14 out of 21 commits have been made in the past week, and although some are small it shows how easy adding features becomes when you have a good base built.

The database building and making sure it was in sync with file uploads was the most challenging part of this project so far. Two new services were created: one to handle all interactions with the database and another to provide information about the user that is currently logged in. Having Components communicate through a service decouples them from each other and the parent. The Components can simply subscribe to the data they need. This blog post was most helpful in determining the best approach for my needs, but Angular’s documentation filled in the blanks as needed.

An interesting bug I encountered was that uploading a new file overwrote all previous files. This was occurring because I was using the same reference to storage, but a new one is required for each upload. This was a simple solution, but puzzling at first. This was only noticed when I tried deleting a file: other files were still in the database and storage, but the link to all files returned a 404 error.

Then my least favorite part came: improving the UI. I love making things work, but making them flashy and fancy frankly seems like a waste of time, as long as it doesn’t detract from the user experience. Still, I quite enjoyed making it look nicer, despite some frustrations with CSS. The biggest issue I’ve had is CSS styles from outside components affecting the inner ones. I also wish browsers were more standardized. It has been difficult creating a consistent user experience across browsers, save for creating new elements from scratch. In the case of file uploads, for example, it is much simpler to hide the actual element and forward user clicks from a custom text input and browse button.

My last task will be to add some graphs to process information and display it to the user. This is of little use for the project as it stands, but will be incredibly useful for my Independent Study project next semester when I re-brand it. I have to give some credit to the Angular framework for making it easier, but using software engineering principles has allowed for an iterative project. I have a working project at every step with a much bigger end goal in mind.

There is still some polishing I’d like to do, and of course there could always be more features. This project was a great chance to dive into Angular and web development.

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

Hello, again my fellow readers!

This week we shall continue looking at Apprenticeship Patterns. I decided to skip over the Unleash Your Enthusiasm pattern and instead decided to talk about the Concrete Skills pattern this week instead.

The Concrete Skills pattern seeks to solve the problem of joining a team of craftsmen to further your learning opportunities. This could also be the all-important problem of getting a job. The problem keeps on going as you are too much of a risk as you may not be able to directly contribute anything to the team. You may not be able to even indirectly contribute.

The solution proposed is fairly self-explanatory. It’s right in the name of the pattern! Acquire concrete skills that allow you to demonstrate ability with relevant tools and technology. The pattern does suggest acquiring some skills that are geared more towards getting past HR and managers. I do like the proposed idea of “buzzword bingo” that the pattern mentions briefly. The rest of the concrete skills that you learn should be directed at showing your team that you are actually useful and that someone doesn’t need to look over your shoulder constantly to ensure you don’t mess up or break something. It goes on to make a good point. When faced with a hiring manager, they will ultimately be looking for someone who can actually contribute in some way on the first day. Having concrete skills is, as the pattern puts it, a way to meet them halfway. Then as you progress, you will have to rely on these concrete skills less and less. To learn what concrete skills to build, the pattern suggests looking at resumes of people whose skill you respect in the business. Identify some skills from the resume and work on them and of course, keep reviewing your own resume.

This is what drew me to talk about this pattern. It is directly relatable to me as I am in the job hunt as I am graduating soon. I found this entire pattern to be generally good advice for anyone in the software development field seeking a job. It also corroborates what a lot of people have given me advice for job hunting.

That’s all for this week. I wonder what pattern I will get to read about next?

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.