Category Archives: Week 8

Apprenticeship Pattern: Dig Deeper

This week, I read the apprenticeship pattern “Dig Deeper”, and as the title suggests, this pattern was about trying to gather a much lower level understanding of some of the tools and the libraries that we use daily. The author acknowledged the fact that you do not always need to be an expert in everything to get the job done, sometimes a superficial level of many technologies is more valuable. This pattern suggested that a superficial level of understanding is needed in times where you need to just get something working, maybe you have a deadline, or you are satisfied with the way the product performs. This pattern also did a fantastic job of highlighting the value of digging deeper.

Like many of the patterns in this book, if applied, they will make you more desirable as an engineer. This pattern will not always lead to you acquiring a new skill, but rather it will sharpen your skills and give you an understanding so deep that you may find new ways to use the tools that you’ve always been using, as well as finding new solutions to that problem that has been glaring at you. One personal experience that I’ve had with this pattern was during an internship. I’ve previously had a very basic understanding of REST, and for the most part, that was enough for me to get by, but I was eventually assigned a task that required knowing more than just the basic GET, POST, PUSH, and DELETE requests. This task forced me to dig deeper into rest to understanding things like authentication, query parameters, and other low level details. Having been forced to dig deeper, I now have a much better understanding of REST and with this understanding comes the freedom to write better APIs as well as being able to diagnose issues much more quickly.

I find this pattern extremely useful, and although it may not always be possible/viable to dig deeper when working on a project, I now believe that it is always worth it to make the effort because the benefits are almost always worth the time investment.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Sweep the Floor – Apprenticeship Pattern

Sweeping the Floor is a saying for doing the dirty work that no one else wants to do. This pattern highlights what you can do to stand out as the new guy on the team and make yourself valuable to them. This pattern was an excellent read, you can read it yourself here: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch04s05.html

The pattern makes it obvious, almost every team has a job that no one WANTS to do. I have seen this at my own jobs. Things like cleaning, writing well thought-out documentation,  and even answering the phone are some of the small tasks that people would rather not do. Step in and volunteer to do those tasks. This will enable you to gain trust and socialize with the team so you can get your foot in the door. The authors go on to talk about how there are some negatives to sweeping the floor. However, In my opinion they are all avoidable. These negatives would be getting stuck as the teams scrub (someone who they make do all the menial tasks and never ask more of), or you will be too intimidated to try and step out of your comfort zone. Both of these are avoidable by being more assertive once you’ve gained trust and a place on the team.

I really enjoyed this pattern because it will be extremely relevant to me in the upcoming future. I am applying to (what feels like) hundreds of jobs to try and join a team when I graduate. I know I will have to prove myself and this pattern has given me a way to do it. Take pride in the small jobs and do them well, this will help you make a stand in your team. The only thing about this pattern I didn’t like was the fact that they added consequences to it. I feel like that really brought down the overall inspiration of the pattern. The consequences weren’t on my mind when I was reading the pattern until, of course, I read that part. They should have stressed that you need to be confident in your abilities to learn and continue to try and climb the totem pole.

Overall, the pattern is an excellent inspirational read for someone who just joined a team and are looking to prove themselves. I can certainly see myself doing this in my future jobs.

 

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

This pattern is one among the many which I have drawn so much knowledge and think will go a long way to help me grow in my future employment activities as far as software development is concerned. Educationists will tell you that learning is a gradual process and I know it’s not going to end in the classroom when the time come and I am out of the classroom to the field to face the world. This pattern has just reaffirmed that learning is still going to take place afterward. It is really hard as David H. Hoover admitted to say you don’t know when they expect you to know what they are asking you to deliver. But for my own good I will not be tempted to give quick answers to questions that will put me in trouble later on. Again, this  pattern has also given me the idea that as an apprentice, my goal is not to become an expert but that will come naturally as I go the journey and explore deep into an interesting areas of  learning.

I strongly agreed with the point that when your answer questions, you become clarified of your own knowledge. This is true because, anytime I help someone do something or explain something to someone, I will never forget that subject again; that is stick in my head forever. I used to be shy to speech in public even if I know the answer but as I grow and become more familiar with difference group of people, things began to change. From then,  anytime a question is asked in the mixed of people, I always try to be first to respond  to it if only I have an idea of what is being asked  because I know how it help me in understanding the scope of my knowledge better.

I have been trying to cherry pick these patterns but I realized going through all of them will help me more because, they are interconnected. So far, with what I have learned, all the patterns has something unique that I think if carefully adopted will go a long way to help me deal with all the problems I will be facing as an inexperience apprentice.

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Confront Your Ignorance

The context for this pattern, as described by the authors, is that you have found gaps in you skill set that are effecting your everyday work. The problem here is that your knowledge of essential tools and concepts is lagging behind that of your coworkers but you are expected to already have this knowledge as a prerequisite for being a productive member of the team. The authors explain that this particular pattern goes hand-in-hand with the “Expose Your Ignorance Pattern.” They stress the importance of adopting both of these patterns simultaneously as just adhering to one or the other can present problems of their own. For instance, by only exposing your ignorance and never confronting it you may end up in a constant state of ignorance and being overly dependent on other team members when it comes to completing essential tasks relating to the project at hand.  On the other hand, if you only confront your ignorance without ever exposing it you may be missing out on valuable insights your team members could provide you not to mention the fact that you may spend too much time trying to learn specific concepts that could have been easily explained to you by a team member who already has the knowledge you are seeking. According to the authors, the solution to this problem is to “strike a delicate balance” between these two patterns in order to ensure you are learning the essential skills necessary for your role without wasting to much time and allowing you to be as productive as possible.

I found this pattern to be quite relatable in my current role as a Security Analyst. When I first joined the team I had very little knowledge when it came to essential information security concepts. For example, in security it is crucial to have a fundamental understanding of how the different layers in the OSI network model function. This can be quite overwhelming at first considering that each of the seven layers have different functionality along with a multitude of associated protocols that they must adhere to. Luckily my team has been really supportive in helping me gain the necessary knowledge and skills by giving me practice problems and either providing me the resources necessary to learn essential skills or pointing me in the right direction to where I can find helpful resources. I think up to this point I’ve been able to maintain a healthy balance of exposing and confronting my ignorance but the advice provided in this pattern will definitely be useful going forward.

 

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

Recovering from Tragedy

After last week’s post I made a simple click that I’ve made probably hundreds of times before when I updated WordPress on the MassHOSA website. The difference this time, however, was that I wasn’t only updating the WordPress core but also the theme that was currently being used on the website. Depending on the update, you can sometimes get away with updating themes without losing customizations. If, however, the update includes changes to say styles.css, for example, your customizations will be obliterated.

I have nobody to blame but myself for this mistake. I was fully aware that updating a theme could wipe out customizations, and WordPress even has a handy warning on the theme update screen:

But, I was not thinking and clicked update – and lost all of the customizations that I had made to the theme, permanently. Here lies another issue: backups. I should have been making regular backups of both the WordPress filesystem and SQL databases, since at this point I have put a significant amount of effort into both the design (stored mainly on the filesystem in CSS and PHP files) and the content (stored mainly in the SQL database).

While this incident was certainly frustrating, it’s not that tragic. I was able to restore the customizations (this time in a child theme) in a matter of a few hours, and am happier with the outcome this time than I was after my original modifications. Using a child theme forced me to do things a bit differently than the first time around, but at this point I already had a pretty good idea of the changes that needed to be made. I am happy to be doing things the right way now, as my original design would not have been sustainable. Making changes directly to the themes CSS files means that you cannot apply updates as they become available. While this would be fine if updates only ever contained feature additions or style modifications that you were not interested in, this is not advisable when some updates contain security patches. Given the choice between leaving my website vulnerable to attack and losing customizations, I would rather put in a couple of hours of doing customizations the right way than face the repercussions of a breach.

 

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Practice, Practice, Practice

No one is born with the skills needed to be an expert in their craft and very rarely are skilled immediately after learning how to do something new.  As the new member of the team you may not notice it, but it took your other team members years of practice to get to where they are and you can get there too.  Taking risks and making mistakes are important parts of learning new skills and honing your craft. Most work environments provide very little opportunity for young developers, or apprentices in most fields, to make these mistakes or the time to work through them on their own.  It’s important to put aside time to work on a personal project or two in order to work on new skills or just get more comfortable with the skills that you already have.

 

When I worked for Geek Squad I would often be at the counter talking to customers and would have to try and identify what the issue with the computer was and either perform a quick fix or document the specific issue for intake and extended repair.  While we had the opportunity to make some temporary mistakes or try a fix that does nothing, we did not have that luxury at the front counter when working directly with customers that expected us to know exactly what command to run, or the location of every setting for every system and operating system.  What I chose to do was to buy a cheap laptop, take it home and essentially find various ways to break it. In this low stress environment, I was able to get more knowledgeable with different systems and common problems.

 

This is a tool that I intend to use as often as possible when starting a new career.  While I have had practice and learning while completing assignments for the past four years; real world projects and capacity of assignments will vary greatly from what I have done so far.  My plan is to clone my workspace at home to an extent. This will allow me to create a sandbox to try new solutions without breaking programs or causing more work for my other team members. I believe that this is a double edged sword though and you need to be careful with how much additional work you take on without finding a hobby and personal life to balance it with.  I find the breaks beneficial because they allow me to think about something else and that’s when solutions often become clear; getting too consumed with solving a problem that you are practicing on you no longer see the forest through the trees and risk burning out.

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

Apprenticeship Patterns – Learn How You Fail

People are going to have failures in their field of expertise at one point or another. There is simple no avoiding it. If someone claims that they have never made a mistake I am willing to bet that they are lying or have never even remotely pushed themselves in any way, shape, or form. The pattern Learn How You Fail in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discusses failure and how to handle failure.

The key message this pattern is trying to convey is how to learn from your failures [AP]. People are always going to be weak in certain areas [AP]. The key is to identify where your weaknesses are and be able to recognize when you are heading into one of those areas [AP]. If you can do that, then you are heading in the correct direction. However, simply identifying where your weaknesses is only one step [AP]. Not taking it any further than that is like a dentist saying you have a cavity and then not repairing it. Once you have found an area of weakness you need to be aware of what is causing that weakness and trying to improve that skillset [AP].

Knowing your weaknesses also allows you to set realistic boundaries [AP]. It allows you to keep your goals in sight without getting too side tracked on other matters that you are probably wasting your time on [AP]. That is not to say you should totally avoid your weaknesses. You are going to have to tackle some of them to get where you want to go.

I generally agree with this philosophy. I have always viewed failures as things that happen naturally and in most cases are a good thing (unless there is a deadline). If you never make any mistakes how are you supposed to learn? Be able to recognize quickly when you have made a mistake so you can take advantage of it. Failure is a bad thing if you never take anything from them. You’ll just end up making the same mistake over and over again. The pattern also suggests keeping a list of your skills and limitations to help yourself recognize when you are heading down the right path and more importantly, when you are heading down the wrong path [AP]. I think keep a list like this is a great idea. It allows for people to more easily recognize what they are good at. I may think about doing this myself. This pattern provides some great advice that I certainly will try to follow and I hope others will as well.

 

Link to pattern in book: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch05s09.html

 

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Money Shouldn’t be the (Only) Motivator

While money is certainly important, and should be a consideration – it should never be the primary motivator for choosing a particular career or even for choosing particular projects or roles in a position. Making decisions based on financial considerations alone is a quick way to end up hating what you do and having little opportunity to improve your situation. Making the correct choices about what you use at motivating factors to drive decision-making can help make software craftsmanship a more rewarding and valuable career. Following some of the advice given by Hoover and Oshineye in Apprenticeship Patterns should allow a new or aspiring software craftsman to identify the motivating factors that drive success in the position and lead to a satisfying career.

It is easy to stay motivated when things are going your way and you are working on projects that you find engaging, fun, and adequately challenging without being overly difficult. The problem that the Sustainable Motivations pattern is hoping to address, rather, is when things get a bit more difficult. Sometimes it becomes difficult to see the passion in software craftsmanship. For example, sometimes in the course of developing the necessary technical skills to become a master craftsman, the aspiring develop will be faced with hurdles such as ambiguously specified projects, or shifting and conflicting demands of customers. It’s times like these, argue Hoover and Oshineye, where the motivation and determination of the aspiring craftsman are truly tested.

While I feel lucky to be actively interested and continuously challenged by my current work, I am sure that my luck will run out at some time in the future. I will be presented with a project that I find tedious, frustrating, and maybe even exhausting. I am confident in my ability to remain focused and motivated on working towards the end goal of becoming a craftsman, however. I feel that as Hoover and Oshineye mention, if I ever begin to have doubts they will easily be overcome by a need to continue earning money or the desire to maintain a reputation as a technologist. These motivators should keep me in the craft until my situation improves and passion returns as my primary motivating factor.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Breakable Toys

Problem

You work in an environment that does not allow for failure. Yet failure is often the best way to learn anything. Only by attempting to do bold things, failing, learning from that failure, and trying again do we grow into the kind of people who can succeed when faced with difficult problems.

Solution

The solution the text offers is to build “toy systems that are similar in toolset, but not in scope to the systems you build at work.” Experience is build upon failure and success, having a more or less private space to seek out failures in order to learn from them. When implementing this pattern, the text suggests making your systems relevant and useful to your life as an apprentice. Suggestions include building a wiki, calendar, or address book.

“Breakable Toys is more about deliberately creating opportunities to learn by stepping beyond your boundaries and single-handedly building complete software projects.”

The projects you take on may be excessive and not complete but having the ability to fail, and find solutions trial and error will benefit you in the long run. Maintaining a wiki leads you to learn about things like HTTP, REST, parsing, web design, caching, full-text search, databases, concurrency, and possibly data migration. Other forms of breakable toys include games like Tetris and Tic Tac Toe, blogging software, and IRC clients. The intent of Breakable Toys is learning new things and allowing yourself to learn from roadblocks that might occur.

The idea of building a wiki to record what you learn is similar to this blog in that I am tracking my progression as an undergraduate seeking employment and mentors to help become a software craftsman. I’ve been using WordPress for some time and have slowly learned more about PHP, HTML, CSS, and SQL databases. I think the Breakable Toys pattern is an essential part of learning new and complicated projects. I liked the idea of creating other tools that help you in other aspects of life, like making your own calendar or address book. My first angular 2 project could be considered a breakable toy, I didn’t know anything about Angular and very little about Javascript but having the time to sit down and create a workable web app helped me learn about something new and has prepared me more for the Angular project I’m working on now.

The post Breakable Toys appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

HTML (Hypertext Markup Language) and CSS(Cascading Style Sheets)

HTML which stands for hypertext markup language and CSS(Cascading Style Sheets). Are what i decided to read about since with our final project with the typescript and angular , we will need HTML and CSS for it to work properly. Also giving it a better graphical look or user interface with the help of CSS.  Hope you viewers enjoy the article.

 

HTML stands for Hypertext Markup Language, and it is the most widely used language to
write Web Pages.
* Hypertext refers to the way in which Web pages (HTML documents) are linked
together. Thus, the link available on a webpage is called Hypertext.
* As its name suggests, HTML is a Markup Language which means you use HTML
to simply “mark-up” a text document with tags that tell a Web browser how to
structure it to display.
Originally, HTML was developed with the intent of defining the structure of documents like
headings, paragraphs, lists, and so forth to facilitate the sharing of scientific information
between researchers.
Now, HTML is being widely used to format web pages with the help of different tags
available in HTML language.

HTML Tags
As told earlier, HTML is a markup language and makes use of various tags to format the
content. These tags are enclosed within angle braces <Tag Name>. Except few tags,
most of the tags have their corresponding closing tags. For example, <html> has its
closing tag</html> and <body> tag has its closing tag </body> tag etc

A typical HTML document will have the following structure:

Document declaration tag
<html>
<head>
Document header related tags
</head>
<body>
Document body related tags
</body>
</html>

HTML Attributes

Attributes provide additional information about HTML elements.

  • All HTML elements can have attributes
  • Attributes provide additional information about an element
  • Attributes are always specified in the start tag
  • Attributes usually come in name/value pairs like: name=”value”

 

Now let get into CSS(Cascading Style Sheets).

CSS(Cascading Style Sheets) describes how HTML elements are to be displayed on screen, paper, or in other media. It saves a lot of work. It can control the layout of multiple web pages all at once

CSS is designed primarily to enable the separation of presentation and content, including aspects such as the layout , colors , and fonts . This separation can improve content accessibility , provide more flexibility and control in the specification of presentation characteristics, enable multiple HTML pages to share formatting by specifying the relevant CSS in a separate .css file, and reduce complexity and repetition in the structural content.

Separation of formatting and content makes it possible to present the same markup page in different styles for different rendering methods, such as on-screen, in print, by voice (via speech-based browser or screen reader), and on Braille-based tactile devices. It can also display the web page differently depending on the screen size or viewing device. Readers can also specify a different style sheet, such as a CSS file stored on their own computer, to override the one the author specified.

Changes to the graphic design of a document (or hundreds of documents) can be applied quickly and easily, by editing a few lines in the CSS file they use, rather than by changing markup in the documents.

example of Css

<!DOCTYPE html>
<html>
<head>
<style>
body {
background-color: lightblue;
}
</style>
</head>
<body>

<h1>Hello World!</h1>

<p>This page has a light blue background color!</p>

</body>
</html>

output:

Background will turn lightblue. try it!

Even though i know much about this article. It really helped me refreshed my mind on some stuff i forgot. now with no doubt , i know i will utilized this info to work better on my final project. Hope you guys also find this article very useful.

references : 

https://www.codecademy.com/courses/web-beginner-en-HZA3b/0/1?curriculum_id=50579fb998b470000202dc8b

https://www.w3schools.com/css/css_intro.asp

https://en.wikipedia.org/wiki/Cascading_Style_Sheets

 

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.