Category Archives: Week-14

Breakable Toys

Summary:

I have chosen breakable toys for this weeks Apprenticeship pattern. Breakable toys pattern is about learning through our mistakes. The pattern explains that we work in a high pressure jobs and environment and understandably success is expected or at times even demanded of us. However, pattern also recognizes that failure is the key to success. By failing and discovering our faults, our flaws is a crucial step in the process for us to grow, learn and build on our experience which all in turn eventually leads us to succeed. Pattern emphasizes the importance of step one for any work we are attempting to complete. First step needs to be just that, the first step – a simple README file in Gitlab with a rough structure what we are working towards is as important as every code we write and every feature we experiment on.

Why this pattern?

This is one of the most important if not the most important Apprenticeship Pattern I have come across. There many external factors affect the work that is being done like time restrictions and financial restrictions which prove to be nothing but a hindrance. This year, I had to keep learning new languages like R, python, JavaScript, mocha and chai and services like docker, R studio, VS code, Jupiter, anaconda, etc. I cannot count how many times I have been stuck on some piece of code, spiraled down because I knew failure was unavoidable and start feeling the paralyzing fear take over.

Knowing and remembering that failure is as important as success in a learning environment has helped me lot. Organizing my failures as a software developer proved to be as important as completing building our backend because It’s not wrong to make mistakes, it’s wrong to repeat them. Pattern suggested that we should work on our smaller projects because it gives us the time to learn our tools and a safe environment where we have our freedom to fail. I have written simple codes for calculator and tic-tac-toe in python. Deployed a simple ‘Hello world’ website using AWS. To quote Thomas Edison, “I have not failed. I have just found 10,000 ways that won’t work.” The trial-and-error process has immensely helped me grow and then further implement that knowledge in my projects.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Blog 6: Share what you learn

The context given here is that You have been an apprentice for a little while. You know a few things and people are starting to look to you as a source of knowledge. Up until now, you have focused exclusively on your own improvement as a craftsman. To become a journeyman, you will need the ability to communicate effectively and bring other people up to speed quickly. A good way to prepare you for that is to develop the habit of regularly sharing the lessons you have learned. This may take the form of maintaining a blog or running “brown bag” sessions amongst your peers. You can also make presentations at conferences or write tutorials for the various technologies and techniques that you are learning.

The books highlight that Being part of a community of individuals where both learning on your own and humbly sharing that newly acquired knowledge are valued is one of the most powerful aspects of apprenticeship. It makes otherwise-esoteric fields of knowledge suddenly accessible, and provides apprentices with guides who speak their language. That being said some lessons should not be shared, and it’s important to keep in mind that there is an ethical dimension to knowledge. Before sharing something, consider whether that lesson is yours to share. It may be a secret, or it may harm others. Things that seem obvious to you because of your current context may in fact be your employer’s “secret sauce” and it is all too easy as an apprentice to overlook the consequences (legal, financial, and political) of sharing that knowledge.

I can personally relate to the content in this pattern because I have worked for 2 years as a tutor for introduction to programming class (java) and it has helped me on so many levels. I remember my first instinct was to decline the job when the position was first offered to me. But then I took “a risk” and started working as mentor and all of a sudden, my understanding in the class material got better. I got comfortable sharing knowledge in an effective way, and I got great public speaking skills

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

Blog 5: Use Your Title

The context given here is that as a result of your dedication to learning, you have been hired or promoted (formally or informally) into a position with a title containing words such as “senior,” “architect,” or “lead”. The problem is then that your job title doesn’t match what you see in the mirror. When you introduce yourself in a professional setting, you feel as if you have to apologize or explain away the difference between your skill level and your job description. The solution suggested is not to allow your title to affect you. It is a distraction that should be kept on the outskirts of your consciousness. Use your title to gauge your organization, not yourself.

Impressive titles and responsibilities do not indicate that your apprenticeship is over. They only serve to remind you that there is a shortage of craftsmen in our industry so we should not be fooled by an impressive title. Another variant of this theme is informal versus formal titles. For instance, you may have grown into a position of authority on your team, despite your formal title remaining the same. These informal titles can be hard to ignore, because they are constantly reinforced by your peers, even if they conflict with your self-assessment. During these times, your connections with your mentors and peers will be critical to keep you grounded in reality.

I was really glad to see that the title subject was tackled in this book. So many times, I have found myself in jobs doing way more than what my title said sometimes even doing something completely different. In my current position, I am doing my job and some part of the data analyst job and at first, I got slightly annoyed but I have now realized that I would try to learn from it as much as possible rather than complain about it

I also really liked their action plan which is to Write down a long and descriptive version of your job title. Make sure it accurately reflects what you really do at work and your skill level. Keep this updated, and from time to time imagine how you would view a stranger who had this job description.

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

Blog 4: Dig Deeper

This pattern encourages us to go beyond the surface level work. The context given is that You live in a world of tight deadlines and complex software projects that use a multitude of tools. Your employers cannot afford the luxury of employing enough specialists to fill every role. You learn only enough about any tool to get today’s job done. You select a handful of tutorials on the language or library that you’re working with today and consequently You make decisions without taking the time to understand the issues, and copy the toy examples provided with the tools. The problem is then that You keep running into difficulty maintaining the code you’ve written because it turns out that the tutorials you followed cut corners and simplified complex issues. You find that your superficial knowledge of a thousand tools means you’re always floundering whenever a subtle bug arises or you have to do something that demands deep knowledge.

The solution suggested is now to Learn to dig deep into tools, technologies, and techniques. Acquire the depths of knowledge to the point that you know why things are the way they are. Depth means understanding the forces that led to a design rather than just the details of a design. In other words, it also means understanding type theory rather than simply parroting the things you’ve heard others say. I agree with what is being said because the areas where you have deep knowledge feed your confidence and they indicate places where you can deliver value early in your time with a new team. More importantly, this depth of knowledge is something you can fall back on to give you the strength to tackle new areas.  I have mentioned before how I usually run straight to google or StackOverflow in time of doubts but 95% if the time the website only provides “quick fix” type of answers and there is no real learning happening. I have understood that applying this pattern regularly, will help me truly understand how my tools work and I will no longer just be gluing bits of code together and depending on other people’s magic to do the heavy lifting.

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

Use the Source

Programming involves applying the right pattern to a wide variety of scenarios. A way to learn how to apply those patterns is to analyze how other people have done them. One of the best ways to do this is by reviewing the publicly written code by someone who has published open-source code. Reading and understanding the craft a master has created, it will spawn ideas within you as to how to improve your own programming patterns and creations.  

I find it interesting that it gets easier to read someone else’s code the more that you read it and that the faster you can comprehend code is an indication of your level of mastery. I also found it to be an interesting recommendation to use git to track the history of code over time to view how it is improved. Doing this will help you identify the type of errors that passed inspection but eventually needed to be fixed or modified. In the future, you will be able to apply the patterns you observed to the code you write yourself.

I often program using TypeScript and open-source npm packages. Oftentimes with smaller node packages, they lack full documentation of the entire codebase. When this happens, I use my IDE’s source inspection tool to look at the function within the node package to understand how the package classes and functions work. There are also times when there is a node package written in JavaScript that does not come with predefined TypeScript type definitions.

To use these node packages with type safety, I write my own type definitions by inspecting the source code for the open-source package I am using. To some degree, I have already been reading the source, but not with the sole purpose of reading and learning the patterns of the software’s author. In the future, I will spend more time appreciating that I am looking at someone else’s craft that they fine-tuned to the best of their ability. Making sure to learn and take away as much as I can from their programming. I do not disagree with anything in this pattern, as viewing the source is something that I have already made a habit of doing.

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

The Long Road Pattern

For this week’s apprenticeship pattern, I did a reading on “The Long Road”. The Long Road pattern is about your future. In this pattern it talks about trying to imagine yourself 10 years, 20 years, or even 40 years from now. They want you to think about that and possibly write down a summary of your profession. By doing this, it will enable you to think how you would want your professional path to be like and allows you to plan how things could go. The problem in this pattern is that you want to become an expert in what you want to do however, things may get in the way like that such as promotions and just always picking the highest paying job and by doing this, it takes away the goal you had originally which is to do something that you enjoy doing but instead doing jobs that in reality sucks.

My initial reaction to this, is that it is an interesting pattern to read about. It is interesting because I never thought to look past 5 years into the future and just thinking about the future and where I want to be in general. Obviously, everyone wants to make six figures, but the main goal is to make that much by doing something you love or enjoy doing. After reading this pattern I did take a moment to think about where I would like to be down the road and it made me realize what I really wanted to do with my future. Of course things happen, and the future isn’t exactly set, but it gives me a good idea of what I need to do and what I have to do to accomplish it.

The pattern has changed the way I view my profession because I never thought about needing to take a step back and think about the distance future of where I would like to be. Do I still want to be programming all my life or would I like to do something different by the age of 40? It was an eye opener to me because it really allowed me to set goals that I want to achieve by a certain age. Sure, programming is fun and all but there’s much more to life than sitting around a desk and creating programs and such. I want to create memories that will last a lifetime and explore the world.  If I can find a career that would enable me to do that then that would be the ideal job.

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

Apprenticeship Patterns: Nurture Your Passion

Christian Shadis

In the apprenticeship pattern Nurture Your Passion, Hoover and Oshineye explore the importance maintaining an interest, curiosity, and passion for computer science despite hostile conditions. They discuss the ways hostile work environments, boring projects, and cynical coworkers can bring down the morale of programmers, especially those in a developer position rather than an engineer position. They discuss the ways in which the developer can resist these negative external conditions to maintain their passion for the subject and continue growing as a developer.

This pattern coincides well with the Breakable Toys pattern, which discusses using interesting personal projects to supplement your development skills to avoid stagnation. Using this pattern would be an excellent way to Nurture Your Passion. Working on fun and interesting projects is an intuitive way to gain appreciation for a skill and spending the extra time working and learning on your own is an excellent way to supplement your knowledge in the subject; a win-win!

The pattern makes a lot of sense – in my non-CS jobs, I often felt uninspired and bored. While the work was not as engaging or creative as development, I was completely devoid of passion for my work. This made the day drag, led to resentment for the company, and caused an overall poor experience working. Working in a field that I am far more interested in will give me the opportunity to have passion for my work, but I must try my best to ensure it does not fizzle out due to stagnation. If I lose passion for coding, my development job will become as unfulfilling as my previous jobs.

I hope to use this pattern throughout my career, but especially so over this coming summer. I am likely most qualified to be a software developer, which is not as exciting a job as an engineer but using this pattern will ensure that my passion for development does not disappear before achieving a more desirable position. Specifically, I plan to rebuild my website in a full-stack capacity to fill in web-dev knowledge gaps, but also just to have fun working on a type of project I have not before.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Perpetual Learning. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Vue.js Breakdown

Traditional web applications function by having single pages that need to be refreshed when data has to be updated or submitted. You can likely recall using a website where each time a form was submitted or a link was clicked, you had to wait for the data to process and a few seconds later a new page appears. This process feels very cumbersome and discourages the use of the service.

Modern-day web applications are single-page, meaning data is dynamically added and removed from the HTML without the page needing to be redownloaded. To do this, a virtual dom is created through javascript and rendered as HTML to the page. When the virtual dom has a change, the actual dom is updated only in the area that is needed, without reloading everything. This change in design improves speed, reduces the amount of data to load, and improves user experience. Most services used online today are single-page applications and when they are not, it feels old and outdated.

There are three main web frameworks that are used to create single-page applications and these are React.js, Angular, and Vue.js. Of these frameworks, Vue has the fastest-growing developer userbase. A main benefit of Vue is that it is an easy-to-learn framework. In Vue, the virtual dom has a two-way data binding. To dynamically control the webpage, Vue uses user-created components that are linked together in a hierarchy. Each component is abstracted and allowed to have variables passed to it to make it display specific data. This feature allows custom HTML components to be reused, reducing repeated code and unmanageably long HTML files. A benefit to Vue components is that they can be easily unit tested, as only a small portion of the web application will be tested at a time.

In each component, it can contain state variables, which are like javascript variables that are tied to an element on the webpage. When a state variable is changed, its value is updated on the webpage. The process of watching a variable for a state change and updating the virtual dom then rendering the update to the webpage is called data-binding. This process happens nearly instantaneously and is what makes using Vue-built applications feel seamless and snappy.

I have used React.js in the past and I am familiar with the structure of combining html and javascript together. I am interested in learning more about Vue and what benefits this framework has to offer. Vue separates out the style, structure, and logic of each component which forces developers to keep their code cleaner than in React.


Source: https://www.altexsoft.com/blog/engineering/pros-and-cons-of-vue-js

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

Npm and Yarn

When looking at Node, I was confused on what type of software it is. It seemed like a framework to me. As I did some research I came across some articles and found that it is a common misconception that people think it is a framework or even a programming language. Node.js is a java runtime environment (JRE). It is typically used in backend development, but it also has pretty good use in the front end as well. 

Over the course of the semester we have been using node modules in our projects. In order to get one of these modules in a project we would need to use the npm install method. Npm stands for Node Package Manager. It contains hundreds of thousands of repositories that developers can use to inject dependencies into their applications. At the time I didn’t really understand what the npm was used for so I would just blindly install packages into my projects so I could get them working. 

During the last few projects we were working on in class we started using Yarn, another type of package manager. Once again not knowing exactly what Yarn was or why I needed it I blindly installed the resources I needed for my project, and got to work. At the time, I didn’t notice any subtle differences. The packages I installed were also put into my node modules and I was able to work on my projects as needed. So what was the difference?

Yarn was developed as a response to some of the shortcomings of npm in the past. Over time the developers of the two package managers have been copying each other’s homework in terms of staying relevant in the developer community. One of the glaring differences between the two is that when installing packages, yarn installs multiple packages at one time while npm installs packages sequentially. In the grand scheme of things, this saves some time when setting up your projects. Both package managers allow the node modules to have the same file structure although the file signatures differ. In yarn, the node modules are generated with yarn.lock and in npm the node modules are generated with package-lock.json. Yarn has made it so it is easy to convert from package-lock.json to yarn.lock files in case users wanted to make the switch from npm to yarn. Npm however doesn’t seem to have the same ease of access when migrating from yarn to npm.

In terms of which package manager is better will depend on the developer. It is important to take into consideration though, that yarn is the later package manager. It has gained as much traction as npm has in its entirety, but this could just be due to the increasing demand in package managers in the present day. 

Sources:

NPM vs. Yarn: Which Package Manager Should You Choose?

https://www.geeksforgeeks.org/difference-between-npm-and-yarn/

https://www.section.io/engineering-education/nodejs-frontend-backend/

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Design Smells

Before constructing a project, we must picture out an image out or possibly draw it out to get a better grasp. This way tends to make a smother software as writing our code. But overtime we must face challenges along the way, which regards to maintaining software and keeping it maintained and readable. I have found this website which is called https://flylib.com/books/en/4.444.1.47/1/. This website is a library is all types of information regarding a library of books in different areas such as SQL, programming languages, interfaces, etc. I believe this website can aid me and any other developer to get a wider insight on the information they desire to seek. 

Design smells are basically violations regarding poor designing and that can be spread among other parts of one’s code and/or project. Which is why we have types of code smells to determine on how to seek and resolve it before it becomes an issue. The design smells are divided into seven principals.

Rigidity design is where you make a small change in your code could make huge, unexpected changes in other areas of the software. Fragility design is almost like rigidity, but this is where is when you alter a change in your code and broken code starts to erupt in. this is a sneaky design smell because we do not realize it sometimes and it can potentially make it through the production phase. Immobility design is common due to the fact of parts that are deemed useful are also harder to separate as it can pose a risk. Viscosity designs are also common when deciding between a not good choice that is convenient other than a good one that is not convenient. Needless design comes in two forms which are needless complexity and needless repetition. Needless complexity is straight forward of making your code overly complicated than it needs to be that consists of redundancy. Needless repetition is composed of unnecessary repetition. For example, when we make copies of classes to do the same thing and adding more classes on top which result in a developer’s laziness. Lastly, we have opacity design where readability becomes harder to read and takes time to understand the code which waste time on a developer. 

After gathering information on design smells and seen examples of each type of design smell in my CS-343 class. I understand that it is crucial to refactor code where it can stay readable and keeping it maintained. When starting a project, we always want to make a visual image to make it easier to implement. Also applying the rules and avoiding design smell as much as we can but sometimes, we can miss them and are able to determine the type of smell and find a solution. 

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.