Pattern 1 : Your first language

 

This pattern talks about the biggest step for every “programmer”. I mean i can also say you need to take this step before you are given the title of a programmer. After reading the section above this pattern which addressed emptying your cup before receiving more, i found it very easily cohesive with the content of this pattern. Programming is almost like nothing you have done before. But its only when you begin to understand it, that you begin to see how in tune it is with things that we do everyday unconsciously.  I agreed with how the author addressed this chapter. Unless you open your mind to accept new understanding and insight, grasping the concept of programming as a whole becomes almost impossible. The only way to truly excel at this craft is to dedicated your entire life as a programmer to the cause of learning and improving everyday regardless of how much you know. because for all you know, a new language can erupt tomorrow and render your task and routine of today, obsolete. Everyday you sit down to program you have to be yielding to learn and grown because there can be a new framework that came out yesterday that can make your life a lot easier as long as you know how to implement it. To better implement new techniques and methods will ultimately depend on your understanding of the basics of programming. And your understanding of the basics and fundamentals can be attributed to your in dept understanding of your first  language and the tasks you used it for. But once you have acquired this knowledge do not allow yourself to be bound by this knowledge but instead use it as fuel to attain new heights in the programming world. Every task that you are able to complete or solve should fuel you to learn the next thing in line. Programming is one of those things that theoretical knowledge only goes a distant. Using the knowledge to build, solve and overcome new challenges broadens one’s understanding of the art and this is the path that leads to greatness. The learning curve of a particular framework or technology grows exponentially in regards to the task and problems it is used to fixed.

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Chapter 2 Emptying the Cup

In Chapter 2 of the Apprenticeship patterns, this chapter provides an overview of how an apprentice starts out into his journey. The chapter is broken down into sections where Hoover and Oshineye layout the details of “Emptying the Cup.” Patterns about understanding your first language, wearing the White Belt, Unleashing Enthusiasm, acquiring concrete skills, exposing your ignorance in a specific technology, confronting that ignorance, taking a chance to dive in The Deep End, and Retreat into Competence are the patterns an apprentice will experience and go through.

One of the patterns that sparked my interest was First Language. In the beginning of this pattern, there was a quote that i strongly agreed with. “By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race.[…T]he technical terms of any profession or trade are incomprehensible to those who have never been trained to use them. But this is not because they are difficult in themselves. On the contrary they have invariably been introduced to make things easy.” This quote from Alfred North Whitehead reminded me on concepts of effective and efficient programming techniques. One of the concepts of effective programming techniques was the acronym YAGNI, which stands for “You Ain’t Gonna Need It.” To be an effective programmer, you need to manage your time wisely and devote that time to parts of your code that are going to matter the most. There’s no need to waste time adding things to your code that aren’t going to matter. It’s the same thing that goes for the brain. If you remove all the unnecessary thoughts in the mind, it will provide more room for mental power to make things easy when you work and conduct your tasks. I feel like that is the message that is being sent by Whitehead and why I think this quote was placed into this section of the First Language.  I find this chapter to be very useful and I agree, especially as a programmer, that efficiency in the workplace is important and that this chapter and pattern highlights that aspect.

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Find Mentors

Short Summary

 

CS@Worcester
CS-448
Week-2

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.

Choosing a CMS

When choosing a content management system (CMS) to begin developing a website for myself or someone else, there are a few important considerations that must be made:

1. Who will be maintaining the website after development is finished?

I think that possibly the most important consideration that needs to be made when choosing a CMS for website development is who will be the one responsible for maintaining and updating the website once development is complete. Nothing is more frustrating than going on a beautifully designed website only to be faced with outdated and/or broken content. It does not matter how beautiful or complex the original design is if there is a need for dynamically updated content and nobody around who possesses the skill set required to make the changes or update the content.

2. What type of website is being built?

Another important consideration is the type of content that the website will serve. While many CMSs have support for multiple types of websites such as blogs, ecommerce stores, and static content sites, one may be better suited to a particular task than another. Choosing the right CMS for the job can make both the developer’s life easier and also create a more efficient, polished finished product.

3. How is the website being deployed?

In addition to considering how the website will be hosted and deployed, it is important to consider what the expected volume of traffic will be when choosing a CMS. If the expected volume is extremely high, then perhaps a cloud-based SaaS CMS is the best option. A cloud-based solution would allow for much easier load distribution and balancing and may be automatically handled by the platform itself. If volume is expected to be relatively light or the site is to be hosted locally, considerations must be made for the hardware/software support of the systems on which the site will be running.

4. Does the website need to integrate with existing infrastructure?

In addition to hardware/software considerations for deployment, another factor to think about is what types of IT infrastructure is already in place that will need to be integrated into the website. If there are already databases in existence, ensuring that the website will be able to integrate with them will save significant time and cost over having to migrate data between systems.

5. What kind of support is available for the CMS?

Whether it is for the developer, or for the client after development has been completed, what types of support and how easily accessible it is can be an important factor in deciding on a CMS. Are security patches regularly released so that the site will not be vulnerable? Is there a community that releases plugins, themes or other types of time-saving customizations for the CMS?

In deciding on which CMS to use for the development of the Massachusetts HOSA website, I considered these five points and decided on WordPress. My experience with WordPress as a CMS has been very positive, and I feel that choosing such a user-friendly CMS will allow for straightforward updating and maintaining of the website for many years to come. WordPress is flexible, powerful, and will be easy to scale should the needs of the organization change in the future.

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

The White Belt

I’ve been in the Computer Science (CS) program at WSU for quite some time now. Though I’ve learned a lot in the process, I realize that graduating in May will be just the beginning of my career. I still have a lifetime responsibility of learning ahead of me, and I must find a way to effectively approach this everlasting task.

The textbook references The White Belt as what I feel to be a highly effective pattern to apply when learning new things. The idea is to keep an open mind and bring a proverbial “clean slate” whenever approaching something new. I’m going to use the example of learning new programming languages to further explain this pattern.

We focus a lot on the Java programming language in our school’s CS program. Because of this, I feel I have a proficient understanding of that particular language. We have branched out into other programming languages as well, such as C and TypeScript. But since Java was my first programming language I’ve become proficient in, I always find myself comparing the new languages I learn to Java while I am learning them. The White Belt pattern has changed the way I feel I should be approaching new material. I shouldn’t be making assumptions of new technologies based on my knowledge of other topics, no matter how comparable they may seem. I should be applying The White Belt pattern when approaching new ideas.

For instance, consider a scenario where an algorithm that has been coded in the most effective way known possible for the Java programming language. I should not assume that the code will be just as efficient in a different programming language just because some of the terminology may be similar. I should approach learning a new programming language in the same fashion that I learned Java. A good start would be to consult the community who are well-versed in the skill I am seeking to learn. I ought to start at the very beginning, practicing beginner projects before attempting the more advanced ones. As simple as a “Hello World” exercise may seem based on prior coding experience, The White Belt suggests I should “set this previous knowledge aside.” Based on reading the context of this pattern, I will always try to approach new topics with an open mind and a “clean slate.” This applies not only to the example of learning new programming languages, but also any new situation I may find myself during my professional career.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 Reaction

The introductory chapter to Dave Hoover and Adewale Oshineye’s Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman is a set of definitions for the focal topics of the book – the apprentice, the journeyman, the master and apprenticeship itself. Perhaps more importantly, and certainly of greater impact in my mind, is the brief discussion regarding some of the primary goals that an apprentice ought to have. The role of the apprentice as strictly a learner was one that came as obvious, but I think what made the read novel for me was the methodology suggested. Specifically, Hoover recalls the pivotal moments of his learning, and a majority of them involve having lacking work examined by more experienced developers, having it improved by working with those developers, and taking lessons away from those experiences.

I actually reread Dave’s recollection several times to reprocess it, and I was alarmed at how much it made me think about myself and how I began and, of course, where I ought to be taking myself through the start of my software development career. The shock Dave describes of going from your first language – which you’ve spent ample amounts of time attaining proficiency in – to one that behaves or looks very differently is something I’m familiar with. I count myself very fortunate to have had the weak exposure to programming that I did (Game Maker Language in freshman year of high school, if you were curious), because looking back on it, the task of learning even Java after that first language was especially difficult. I have in fact wondered about this idea over my time in University; I’ve thought for the past couple of years about whether or not we are mistaken to only mandate exposure to Object-Oriented Programming in our classroom. From what I understand, the CS program is beginning to walk students into other paradigms here and there. However, I cannot help but ponder whether my fellow students are able to program in any other paradigm – I know I certainly have a hard enough time with it, and I’ve made a point to try and work out Haskell.

I digress. Where I was intending to go with this was: I recognize and can identify the situations Dave describes in myself and in my own experiences. I find the idea of putting out work with the intent of having it get picked apart to be profound and daunting, but sensible. And, the more I consider it, the more I think that it would be an intellectual dishonesty to do otherwise.

Admittedly, I payed far less attention to the definitions and dissections of the journeyman and master. For the moment, I’m still trying to get myself into the mindset that I think I ought to be now: I want to begin displaying my work for the world to see and have it critiqued. I want to hear of my shortcomings and inefficiencies, then use the ideas of people smarter than I am to turn myself into a peer on equal footing with those people. It is, I should think, rewarding in multiple ways to develop a humble frame of mind that can receive criticism and can be incorrect without feeling some level of inadequacy. Often one’s greatest inhibitor to success is oneself, and I can only imagine that this applies to me just as much as to any other person. Therefore, I should not assume that I can break these barriers on my own; it will take the guidance and wisdom of those who have already attained such success. And so begins the story of the apprentice.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – The Long Road

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye isn’t a book for those looking to take the easy road. It isn’t a book for those looking to quickly ascend in to management. It isn’t a book for those looking to become wealthy fast. What it is however, is a book for those looking to truly become masters at what they do. In chapter 3, a pattern called “The Long Road” [AP] is discussed. It discusses how in today’ society there is a big draw towards quickly rising to fame and wealth [AP]. People want to get rich quick and without much effort [AP]. The pattern discusses how for most people that is unrealistic [AP]. More importantly, if you truly want to be great at your craft of choice, then jumping into management isn’t the right path to take [AP]. Expect to sacrifice promotions and salary increases and make other sacrifices along the way [AP]. Some people may aspire to go into management. If that case, there is nothing wrong with that and no one is going to stop you. But that’s not what this book is about.

I agree that to truly become a master software developer, you have to continue to be actively developing for a long time. The field is forever changing and changing quickly. Each passing year you continue to hone the skills you currently have while picking up more new skills along the way. Eventually you’ll get to the point where you can handle any situation. I feel when you reach that point; when you have an answer for everything (or almost everything) relating to your field then you truly have mastered what you do. To get to this point will take a long time. I also feel that this road is not for everyone. Not everyone wants to be developing software into their 40’s or 50’s. Some may want to move on to other things. Some feel that the role of a developer is merely a stepping stone for higher ranking positions. There is nothing wrong with this philosophy. Not everyone aspires to be a master developer. Personally, I am not sure if I want to become a master developer. I’m not sure if I want to be a true developer into my 40’s or 50’s. I feel this is a question I will answer for myself as time goes on and my career develops. I don’t think anyone my age (I’m 21) has an answer to this question. However, if you are one of the one’s who do want to be a master, then long road is the only way to get there.

 

Link to pattern in the book: http://chimera.labs.oreilly.com/books/1234000001813/ch03.html#the_long_road

 

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

Staying Open to New Ideas

After a few years of using mainly one language to accomplish programming assignments, I will certainly admit to becoming complacent with Java. If I was asked to write pseudocode, my mind immediately begins object orientation and even begins running through some of the Java syntax. While this can be helpful, as I feel my ability to think in Java means that I may be well on my way to becoming bilingual, there are also many drawbacks to complacency.

Applying this Java-like thinking to problems in other languages or under other frameworks is where problems may arise. Rather than being open to discovering and developing new skills, the existing knowledge becomes a hindrance to learning. Attempting to apply existing knowledge to problems of a different sort or in a different language may slow progress, and make learning even more difficult and frustrating.

The solution offered by Hoover and Oshineye in Apprenticeship Patterns is to put on The White Belt and allow oneself to be ignorant by putting aside accumulated knowledge and experience, leaving no choice but to learn the way through trial, error and reflection. Treating new learning opportunities in this way allows for more deeper understanding and helps to create more smooth communications with members of the existing community.

I recently decided to expand my software development experience by studying JavaScript. While I feel confident that I have stumbled over the most difficult learning hurdles at this point, I wish that I had read this apprenticeship pattern before my attempt. I feel that I had a difficult time initially overcoming how fundamentally different JavaScript is, and often found myself grasping for the comfort of Java. It wasn’t until I took a step back from what I was doing that I realized I needed to open my mind to fully understand and appreciate JavaScript for what it was rather than how it was different from or similar to Java. The example that Apprenticeship Patterns uses, a lottery program written in three languages (Java, Io and J) is especially telling of this fact.

While I would have previously described myself as open minded and always willing to learn, I believe that The White Belt pattern has helped me see a more valuable way to approach new learning. I will certainly be using the ideas of Hoover and Oshineye the next time I attempt to learn a new programming paradigm.

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

CS@Worcester – Fun in Function 2018-01-24 23:39:17

The first chapter of Apprenticeship Patterns introduces the main concepts used throughout the book and outlines the book’s purpose. Software development is treated like the kind of craft practiced in medieval guilds, where there’s an apprentice stage, a journeyman stage, and a master stage. The book is a pattern language meant to serve as a guide for navigating a software apprenticeship, consisting of solutions to common problems people encounter in the apprentice stage. A software apprenticeship is defined as a stage where you, as a new software developer, are working to find better ways of doing things; as well as people, jobs, and situations that force you to learn those ways. It’s a period composed mostly of focus on yourself and your growth (as opposed to responsibilities to others) and continuous learning.

Before reading this, it hadn’t occurred to me to treat specific jobs as opportunities to learn and improve the craft, rather than the learning of the craft being a prerequisite for getting a job. The mindset demonstrated in this introduction seems to emphasize valuing software development as a craft in a way similar to the way I’ve seen artists talk about valuing art for the sake of art. It’s an attitude I didn’t really expect to see in a STEM field, but it’s one I’m very open to, since I’ve found that believing in the inherent value of the work you’re doing (instead of being motivated only by outside factors) is one of the best ways to maintain passion. It also would’ve never crossed my mind to think of a career in software development in terms of medieval craft guilds, but the roles outlined in the book made me want to fail a lot in the beginning so that I can learn from it and not fail when I have greater responsibilities later on.

The idea that you’re not supposed to know how to do everything at this stage is one I found comforting. Reading Dave’s story made me feel less insecure about my own late start in this field of study and my ignorance, which I think was partially the point.

The prospect of having to carve out your own apprenticeship because the industry isn’t currently structured to support it is somewhat intimidating, but I’m also intrigued by the idea and think this approach could be fun. Pursuing a goal beyond and bigger than meeting the requirements of a certain job or just plain advancement naturally seems more enjoyable.

I expect this book will be useful to me because I need challenge in order to be happy, and it promises advice on how to avoid pitfalls that will lead to me losing the challenge that made me choose this major in the first place. I’d be interested in reading this book even outside the context of this class because I’m unsure about basically all aspects of trying to start a career, and having some ideas of how to navigate it will be helpful.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman- Chapter 1

Woah !, I really enjoyed reading the book , Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. I have read many books and been in the software-learning role for a while but this book spoke entirely about how I had been seeing this field and how i felt it should be done. I am very emotionally connected to this life craft. I am currently a CS student and like this author, it wasn’t until my junior year in college that I began to see a future with this program for me. I had excelled in class and managed to perform okay but when I I tried to create new project for myself to work on, I found my self always hitting a blank wall. It wasn’t till last summer that I figured what was going on. I was studying how to program like it was a task to be done instead of a skill that needed to be cultivated. When attempting to cultivate a land there are many steps that has to be taken. The soil has to be prepped, and catered for the incoming crops. Everyone wants to be great at programming but you can’t expect a 3 year old to read a college level book. In programing, the gap between the proficient and beginner is so large but unlike ages and height, its not easily noticeable. Its it only when you decide to create something from scratch that’s when you realize and begin to appreciate the people who were able to build Operating systems and large software programs from scratch. This goes to prove the apprenticeship of the software journey. Those people that are able to do that, often don’t hold very high degrees when they were building those programs instead they invest time and dedicate their efforts into making a change by creating and developing something that will benefit the world. From this reading I do agree and believe that one has to invest time, sweat and effort into learning the art of thinking like a programmer. It is only then can you start to see what they can see and think like they can. In programming, if you can’t see and logically make the connection, it’s almost impossible to create. Teaching an individual what to see and how to interpret it takes time and is also greatly individualized. Just like apprenticeship, everyone has their own pace and cognitive strength and moving forward should only be allowed when what is needed is grasped. In a perfect world, everyone that graduates in software development should be able to code quiet adequately but such is not life and I believe and agree with this book in the sense that if you should approach software development as a personal piece of art that continually needed to be perfected, you will become a successful programmer.

 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.