I have no professional developer experience yet, and that can make starting a career difficult. To make up for the lack of experience, I will need to procure and maintain some concrete skills. Concrete skills demonstrate the ability to utilize knowledge. The apprentice pattern “Concrete Skills” from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, by Dave Hoover and Adewale Oshineye, addresses the usefulness of concrete skills when seeking a career.

“If we hire you today, what can you do on Monday morning that will benefit us?”

This question from the pattern makes clear what a concrete skill is. Businesses are not looking for someone with just knowledge, they are looking for someone who can do the job. It is important to practice some concrete skills with current technologies and frameworks so I can hit the ground running when I start a job. The pattern lists several examples of skills to explore: basic web design, JavaScript, open source frameworks, build files, and a language’s standard libraries.

The pattern suggests collecting CVs, Curriculum Vitae, for respected developers to find out what kind of skills to practice. The CVs will contain the concrete skills of those developers. With this knowledge, I would only need to choose which skills that would be immediately useful for my desired career path. The pattern then suggests creating toy implementations of the chosen skills for practice, which then can be used as examples in interviews.

 “Concrete Skills” advises going through one’s own CV and find all the discrete skills. These skills are the only information many hiring managers will look at, according to “Concrete Skills.” This makes having demonstrable skills a necessity when looking for a job.

The pattern, “Concrete Skills,” seems like common sense, but I think it is an important point that needs to be stated. It is easy to lose yourself in the studying of development techniques and forget to polish the skills you already possess. The lesson this pattern is trying to teach is summed up nicely by a quote from Pete McBreen’s Software Craftmanship: The New Imperative:

“Having knowledge is not the same as having the skill and practical ability to apply that knowledge to create software applications. This is where craftsmanship comes in.”

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.

We live in a world where various complicated software projects have different time frames and require a variety of tools to complete tasks. Employers are also reluctant to employ so many professionals to fill all their positions. The problem is that developers learn only what they need to get the job done, and they are not thinking of tomorrow. Sometimes they have to make decisions without even understanding what the issue is and copy some toy examples that would help them solve the issue. In a short time, they become part of the new technology, but they don’t know anything else other than that part of the technology. Moreover, they tend to have trouble keeping the code in good shape, even though the instructions they use cut corners and simplify complicated things in particular. It means that they are constantly wallowing in a perfect way of studying a thousand instruments or something that needs deep knowledge. People sometimes criticize the developers for getting a poor CV, but they forget that developers can learn so little unless they get put under serious tests.

This pattern made me realize that I need to dig deeper into tools, technologies, and techniques. Resources that developers need to be familiar with include debuggers that allow them to see wire-level debuggers that display network traffic and readability. When you can read all descriptions and coding, nothing can hold the process of learning and continuing to work. One method of using this prototype is to collect knowledge from primary sources. Many fake posts can lead you to the wrong path. Do not just take the opinion of someone, figure out who came up with the ideas first, and understand the problems they were trying to solve. Furthermore, as an apprentice, you shouldn’t look for code to copy but you should be focusing on gaining new knowledge from reading different tutorials. Gaining deep knowledge is hard, but by applying this pattern regularly, you will be one of the people who know exactly how everything works. It is better to succeed than to fail…

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

The next Apprenticeship pattern I’ve decided to discuss is titled “Concrete Skills.” This pattern is targeted at developers who wish to join a talented team in order to find better learning opportunities. The problem here is that professional development teams have no incentive to hire new developers who cannot immediately contribute to their work. The pattern explains that, in order to acquire a position in such a team, a developer should develop concrete skills. These are specific skills that a developer is particularly experienced with, such as working with a certain language or development framework. By knowing and being able to list their concrete skills, a developer can help themselves gain the trust of professional teams and begin a career as a software developer.

I chose to read this pattern because I have often experienced fears regarding my ability to find a career with my current experience level. I frequently feel that my current skill set is not good enough for me to be useful on any professional development teams. I think this pattern has helped clarify my reasoning behind these fears. Development teams focus on concrete skills when determining who to accept, while I have always been focused on my overall skillset. This perspective has caused me to focus on what I don’t understand when looking over the work of experienced developers, which has only served to discourage me and make me feel inadequate.

In order to get a start as a software developer, I should focus on determining what my concreate skills are and solidifying them. This pattern helped me understand that concrete skills are more important than overall experience to teams accepting new members. For this reason, I should focus less on what I don’t know and how I compare to other developers, and I should instead concentrate on the skills I already have. In the time I have been pursuing software development, I’ve become skilled at programming in many languages, especially Java. I’ve also learned to use tools like Git and frameworks like Angular, and I’ve done lots of work with creating GUIs. These are just a few of my concrete skills, and I’m sure many of them would be useful on a development team. If I start concentrating more on solidifying these skills and less on grasping at skills I don’t have, I could likely put together a list of concrete skills that would help me find a place on a professional team.

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.

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.