The Apprenticeship pattern I would like to focus on this week is “The Long Road.” The pattern explains that becoming a master of software development is a lifelong endeavor. This conflicts with our cultural obsession with quick results and rapid progression. Developers who wish to become masters need to understand this and learn to focus on long-term goals to help them build their skills over time. Mastering new skills can take many years, but preparing ourselves to dedicate our time towards learning such skills can open up many new possibilities. The pattern emphasizes that The Long Road towards mastery is not for everyone and that there are plenty of other paths to take. However, choosing to aim towards mastery with this path enables us to better understand the fundamentals of the craft, helping us maintain our abilities in a field that is constantly changing.

I chose to discuss this pattern because it has been referenced by several of the other patterns I have posted about. After reading through it, I definitely understand why The Long Road is so important to these other patterns. The book is targeted at those who wish to master software craftsmanship, which requires a lifelong dedication to development and programming. As such, the other patterns might not be as effective for a reader who lacks this dedication or has different goals. Reading this pattern has made me more aware of the necessity of lifelong dedication on the road to software mastery. It has also made me question if I have this dedication myself and if this path is really the right one for me.

I’ve never really had an ultimate goal in mind while studying software development. I know I enjoy programming and want to learn more about it, but I don’t know how I want to apply myself professionally. The Long Road sounds quite appealing in some aspects. It would allow me to focus on programming instead of taking higher-paying jobs which don’t interest me. It would also allow me to use the skills of others to set goals for myself instead getting discouraged by them as I often do now. However, the time and dedication required for The Long Road are frightening to me. Because of my recent struggles regarding my passion for programming, I am unsure if I would have the motivation to continue learning new software development skills for the rest of my life. I think, for the time being, I should focus on nurturing my passion for programming. This will, hopefully, help me decide if I should pursue a different path or if I am ready to walk The Long Road.

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.

The white belt is discussing the situation where you are feeling yourself come into full fruition with your first language. However, once you reach this area it is common to feel that your progress and knowledge is starting to plateau. It often becomes harder to learn a new language per-se when it is easiest to fall back into the one you are so comfortable in. What wearing the white belt means, is being able to fully put aside any of your other knowledge and be able to accept that you are new to this and must re-learn in a new way. By approaching a new situation with a stance of “not knowing” as the pattern says, you will be able to have a broader grasp on the subject. This will also allow for you to be able to progress in the new skill much quicker due to the fact that you are not letting previous, possibly contradicting knowledge of another skill have any affect on your current learning. This is often the easiest way to not feel like you are plateau, but instead staring up another steep cliff of learning. That is how you can ensure that you never stop learning. In this pattern it is worth mentioning that a skilled industry veteran ended up “wearing the white belt” after reading a book that caused him to change how he wrote code entirely. The codebase he writes now he has claimed to be “better tested, more loosely coupled and more adaptable system”.

I find this pattern one of my favorite due to the amount of times I have had to wear the white belt. I began writing code in Java since I was 14-15 and had been my predominant language up until learning C some 5 years later. I originally struggled with C because I had been trying to relate it too much to Java. After viewing it as a completely different world, unrelated to Java I began to have swift development in C. From there I then had to do the same when teaching myself Angular. Angular was different from anything I had done before but again once I started to view it as such, my progress was much quicker. I even had ended up deleting a large portion of work with Angular that had taken me about 3 days to learn how to do. However, since I deep dove into learning everything about Angular, I was able to recreate it within 2 hours the next day.

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

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.