Category Archives: Week 6

Apprenticeship Pattern: Stay in the Trenches

The pattern I decided to read is titled “Stay in the Trenches” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern spoke about how people often equate being promoted into a managerial role with success but how this can actually take you away from the craft of programming. The pattern goes on to talk about how we should work with our employers to see if they can reward us in other ways that keep us close to the act of programming. Next, the pattern discusses how it is easy to apply this pattern selfishly but that experienced developers will find ways to make choices that will help their co-workers as well. Lastly, this pattern ends with suggesting its reader to come prepared with alternative rewards in case they don’t like the rewards offered by their potential employers, especially if they take them away from programming.

The most thought-provoking piece of information I got from this pattern was the bit about how I should make choices that are in my best interest, but how those choices don’t have to be blind to the needs of those around me. It was interesting to hear this because in a pattern that I’m learning about negotiating and advocating for myself, I’m also being taught how I can still be compassionate to others on my team. This is refreshing to hear because it seems like developing can often be a cut throat and intense environment to work in.

As far as how this pattern has caused me to change the way I think, I would say it re-enforced some of the beliefs I had. In a way, I’ve learned first hand what this pattern has described. I started working in human services as a residential counselor and worked my way up to managing a group home on my own. I learned the hard way that by entering a managerial role, I did a lot less case management and had less time with the individuals I served than when I was a residential counselor. Because of this and some other factors, I decided to step down back to the role of a residential counselor which I personally find more rewarding. This realization I made is the kind of message I got from reading this pattern. If I am passionate about programming, I need to be mindful of the opportunities I may receive in the future and make sure they are aligned with my desire to be a software craftsman.

Lastly, I’d like to mention that there isn’t anything in this pattern that I disagree with. It was reassuring to hear something I have learned in life being echoed in this book, even though it was in a different career path.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

Craft over Art

This pattern starts off with a strong quote by Richard Stallman who states “I would describe programming as a craft, which is a kind of art, but not a fine art. Craft means making useful objects with perhaps decorative touches. Fine art means making thing purely for their beauty”. And this quote hit me right in the chest because I wished I had read this quote way earlier, around sophomore year or so. At that year, I was just trying to learn programming while also struggling. At that time, all I could do was some cool stuffs in my own personal computer’s terminal. There wasn’t any time when I thought I should build something that is useful and also could be used by others. All I had in my mind was how to make this code work so that it looks cool in my own terminal.

The context of this pattern is that I am being paid to build something that will solve a problem of a customer. However, the problem is that although there is a solution, my customer’s problem represents an opportunity to do something truly fantastic and is a chance to impress my colleagues with something beautiful. The solution starts as, the things we build for customer can be beautiful, but must be useful. This pattern is developing the ability to sacrifice beauty in favor of utility if and when it becomes necessary. The more useful a piece of software, the more important it is that the software be high quality. But quality takes time. You will have to work toward a suitable level of quality by repeatedly making trade-offs between beauty and utility. Ken Auer also states a really nice and meaningful quote, “Working on real problems for real people is what hones the craft, not just doing it for self-satisfaction”. The action is to do something useful rather than beautiful. This pattern reminds me of an app I made in operating system class with Professor Shruti Nagpal. For that class, our final project was to make something from what we learned in the class. Since my parents kept on asking me what is the current dollar rate compared to Nepali Rupees, I decided to make a currency converter app for them. The app may not be used by many people, but when I think of something I did useful, that’s all I could think of, and I don’t hear my parents asking for dollar rates anymore.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Your first language

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.

—Alfred North Whitehead, An Introduction to Mathematics

The individual Apprenticeship Pattern detached from the book that I wanted to choose as the first one and discuss is Your first language. I choose to start with this pattern because it sounds so familiar to me.

Knowing programming languages has been way too early for me. And now I am studying here, ending the third year of my computer science major. But at the same time, I have done kind of the same major that was for Informatics. About eleven years ago, I chose to study programming because it looked so challenging as a major and that could have courses where I could have mostly learned. The first programming language I used to study there, was the c++ programming language. This course was really helpful for me as the first language, because it helped me learn how to develop operating systems, games, different browsers, and many other things. After the c++ programming language, some other languages I studied there, were Java, Unix Systems Programming, etc. These were programs that helped me a lot in relation to my major. But there was something different. Here firstly I had to choose Introduction to programming, which I think is the base for being a good developer, and then study other helpful programming courses.

I find somehow myself at the solution that Alfred North Whitehead has given on this pattern. He said that first pick a language and then became fluent in it. After some years, this language will be the main one we can solve problems. And I totally agree with this solution because as much as you work for something specific, as much fluent you will be in solving problems. One other solution that he has also given, is that we can also ask the most experienced and available programmer we know for some help. And at this point, I have been lucky. Not only here that I have my cousin, but even when I first studied computers in general in my country, I used to have friends that were more experienced with the programming languages and with whom we have the possibility to discuss different problems faced while programming. But still, I agree when A.N. Whitehead says that we don’t have to be completely dependent on experienced friends. I have always tried to take lessons from them about the problems I can’t solve and also learn from these mistakes.

To sum up, I think that working on programming languages is challenging at the beginning. But once we learn about it, and make that our own language, we will get used to that. It will become something we will like to work on and solve problems as experienced programmers.

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

The White Belt Pattern

The white belt apprentice pattern refers to the part of the movie where the main character thinks they know it all, but instead suffer tragically in some way due to their ignorance. This pattern recognizes that now that you have some skills, the real journey begins.

Assumptions can sometimes be dangerous and can impede your learning. Many times, when I’m trying to learn something, I associate with how it can be like doing something else. While this can be helpful to get me to remember how to do something, this method can also leave out the realization of other possibilities that a certain strategy offers. For example, throughout experimentation with different ingredients and brewing strategies, today many different brews of beer exist. This wouldn’t be possible if these craftsmen didn’t take the time to forget what they knew about making beer already, otherwise they would have just crafted the same one beer repeatedly.

While I find the information in the pattern interesting, I really wonder if I can apply it in my own endeavors in programming. I become doubtful I guess because this is a new way of thinking about how to learn for me. However, I feel like the explanation of learning your second language is put perfectly in the book. The need to feel productive is a dominant urge that I have, but that need must be sacrificed sometimes to learn something new and improve upon my skills. In fact, the book says that this is the most productive way of doing this so in turn, I guess nothing is really being lost.

Becoming comfortable with not being great at something after being great at it for the sake of learning is something I need to get better at. Learning how to do things with my left hand will be helpful if I cannot do things with my right hand, although it would feel naturally uncomfortable to do so. While I am open to and applaud the idea of this pattern, I can see myself struggling to apply it in my own life.

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.

Apprenticeship pattern: Unleash your enthousiasm.

I decided to write this week on chapter two, about “Unleash Your Enthusiasm”. I was reading this and got very interested because it is something that has been an issue for me for a very long time. The excitement that we have when having ideas and want to share them with others is huge, but then we feel like we might do too much or that it’s not good enough and end up not sharing it at all.

I have found myself holding back many times from sharing ideas, my thoughts. In this case, it goes both ways: when I find myself holding back because I have more enthusiasm than my colleagues do, but also when their ideas sound great and better than mine and I step back because I feel like they’re doing better than I am. But reading this pattern made me understand that there are never bad ideas in computer science. All ideas are good, we just better them, but there are no bad or nonintelligent ideas.

As software developers, we have to understand that there is no way we will be working on our own. The fact is we will be working as teams, we will have to share our thoughts, ideas and work all together as a group. So, feeling that we want to share whatever we have, we have to go for it because we can always bring something unique in our teams, some unique attributes to our groups as well as our enthusiasm.

That is why it is important to have a team that is all excited and enthusiastic because when the morale is low, or teams are not welcoming the newcomers, we will definitely feel uncomfortable and would not like to share our enthusiasm. One thing I understood is bringing our ideas and passions will add intelligence and diversity to the team.

Being in a team with people of different levels of experience is very important because they can always help others improve and get better. But also, those who have a low level of experience compared to others in the tram, should not feel intimidated. It might be hard, but we should feel free to share and be open-minded to learn and become better at what we do.

Also, it is very important to have that person in the team who makes us feel comfortable and is willing to help. They will help us get along with the team and feel more comfortable talking. I did it in my software development capstone; I knew some people in the team, and others I just met them. In the beginning, it was hard but then, I decided to open up to the one I knew before and he made me feel comfortable. After feeling comfortable sharing with him, he helped me feel comfortable sharing with the team too because he thought my ideas were awesome and encouraged me.

Never keep our ideas and enthusiasm for ourselves because we might lose the opportunity to bring something great and unique to our team, make a difference, and also learn from the experience.

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.

Craft Over Art

This week I decided to read “Craft over Art” from chapter 3. This chapter simply teaches us that as a craftsman, our prime focus should be to build something that serves the need of others instead of using a project for self-interests or to impress colleagues. This reminds me of most of the projects we are working on in class right now, especially the Thea’s Food Pantry. The focus is to build something that will serve the Worcester State Community.

I believe the benefit of doing something that serves the need of others is that we are doing something for real people. Seeing customers benefit our work, being happy with the product, use it and see it being successful is a great feeling of achievement. We see customers happy, satisfied and using something useful that will probably be there for a long period of time. Working directly for a client can also be stressful as there is a timeline that needs to be met, there are requirements, specifications, policies to follow and it is not always easy to satisfy every customer.

This is where I am bringing the beauty aspect. While reading the book, I understood that focusing on the usefulness rather than the beauty might only apply to a craftsman as he is still in the learning process, embracing his ignorance, taking the long road. Focusing on the beauty aspect of a project can be stressful, distracting and take away the usefulness which should be the priority. However, I believe in a more professional world, for a reputable company, being able to deliver both the value of a product and adding the refining beauty aspect is definitely advantageous. From my perspective, In the future, when I develop projects for customers, I will focus on the value and the usefulness it will bring to the community. However, one client is different from another. One community is different from another. Depending on where I work, if after getting to know the mission of the tech company I will work with and studying the type of customers we usually have, I find that beauty is something they want on top of the usefulness, I will want to deliver that and meet their needs. I think beauty is used nowadays to attract people even when the product itself is not well developed, has flaws and will not be durable. It is unfortunate that art to attract money is put first over craft to serve a community.

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.

Learn How You Fail

Learn How You Fail

This Apprenticeship Pattern covers learning how to fail, and more importantly how to recover from failing. It makes the point that failure is necessary to learn a new skill, and if you’re never failing then you’re likely not trying new things and not expanding your knowledge. Failure is a normal and natural part of learning something new, and it’s just as much a part of the process as anything else. If you want to learn a new skill, you can’t be afraid of failure, and you have to accept that it will happen at some point. By trying to avoid failure, you’re actively hindering your learning and limiting your potential skill.

The Apprenticeship Pattern also makes the point that learning how you fail helps with self-assessment. Through failure, you can learn more about yourself, such as what things you have more difficulty with, and what things you can pick up relatively easily. If you don’t try to push yourself to failure then you’ll never discover your limits, and you won’t know how efficiently and effectively you could be working. Failure also forces you to admit your weaknesses, and to learn not to waste time with things that are outside of your skillset, and instead spend your time doing things that you know you can do correctly.

The Apprenticeship Pattern also makes a point about not getting down on yourself about your failures. By changing your mindset from failure being a bad thing to failure being a valuable experience for learning, you will become more productive overall and more capable of learning new skills. If every time you experience failure you get down on yourself and become afraid of failure to avoid the experience, then you’ll become much less productive, much less capable of learning new skills, and much less experienced overall. The correct way to minimize failures and maximize potential is not to avoid it altogether, but instead to take it on your stride and learn from it so that the situation in which the failure would occur wouldn’t ever happen again, rather than avoiding the failure itself. Only in this way would you be able to become a proficient software craftsman, because that requires learning many new skills, and has the potential for many pitfalls and failings that you must learn from.

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

Code, Run, Break, Repeat.

Upon reading the first line of “Breakable Toys”, I knew I was in for a pattern that I could connect to. Often, my behavior can be related to a “bull in a china shop”; while not outwardly malicious, my clumsy nature with unfamiliar material can often lead to mishaps and damages.

This is where the breakable toys come into play. According to “Apprenticeship Patterns”, journey-programmers can benefit from making similar programs to the ones that they work with in their profession. These “dummy programs” can then be played with to one’s content, allowing for all sorts of experimentation without worries of destroying the actual project.

To me, I found it useful that the pattern recommends “creating a familiar game like tic-tac-toe in many different languages”. It reminds me of my earlier projects where, as stated in a previous blog, I would practice new languages with familiar tactics. I find it to be a valuable way of connecting “Breakable Toys” to other patterns (such as “Your First Language”).

Most importantly, I believe that “Breakable Toys” is one of the most instrumental patterns to my professional future. Science is not a field involving constant “correct-ness”; science instead does quite the opposite, and computer science is a subset of the broad field. With breakable toys, we are constantly trying to find wrong answers, to push boundaries and discover what can and cannot be done with languages, data structures, APIs and the like.

Perhaps I need to read the section again to fully understand it, but I am at a bit of a loss for the example action being “to create a wiki”. As stated above, I think that better examples for breakable toys would involve familiar projects/programs in new languages, or using different algorithms/data structures. The wiki can be a good start as a “portfolio” to hold all these projects, but on its own I don’t feel as though a wiki is allowing much time out of the comfort zone.

Personally, I feel as though “breakable toys” is an easy concept to understand, but is also a bit more difficult to apply in practice. As I question the pattern’s “classic examples” (like the Wiki), I push forward as the pattern implies as its intention. However, as I leave this comfort zone, I wonder if I stray too far, over my head of expertise (even for a “failure-safe” experience)…

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

API (Application Programming Interface)

Applications such as Expedia, Amazon, Netflix or Facebook are using an API that facilitates the sharing data from one application to another. There are hundreds of APIs for many fields like finance, social network, payments and e-commerce. Nowadays, the fastest-growing category APIs is sharing and analyzing of data across various applications which is a place the characteristics of the API determine the value of the application or deem it untenable for use in the real world. But how could APIs connect each application together, let’s us take a deep dive into the world of APIs.

API stand for Application Programming Interface which includes three important components

  • Procedures: Known as routine which refer to the specific tasks or functions a program performs. For example: Facebook provides a search API for developers to examine data for analytical purpose
  • Protocols: The format is used to communicate data between applications. However application might not have the same format
  • Tools: Simply put – building blocks which is the recipe to construct new program

APIs are needed to bring applications together to perform a designed function which allows to use, share and execute data. APIs act as middle man, this allows developers to build new functions between applications and businesses use on a daily basis.

How APIs actually work?

Application: Enterprise businesses and corporation rely onto user financial data, inventory levels and purchase order confirmation back and forth between suppliers, customers and partners. Consumers and business depend on mobile application, spending much time per day on smartphone and tablet apps to exchange businesses with partner and customers.

Programming: Application relies on programming. The application does not make itself. In other words, we would not be able to make new application without developers who write the code to create, testing and design the application software and user interface.

Interface: This is where users and application interact with each other

API is important that without it we would not be able to order stuff from Amazon or personalize your favorite Google homepage. The simple way to understand APIs is to understand that API is an interface that let this application talk to another inside the application via commands designed by programmers.

Types of APIs

  • Rest APIs: known as RESTful APIs, stands for Representational State Transfer. It has grown in popularity of late, as an essential part of Web Services. It’s designed for developers to perform requests and receive responses via HTTP. There are four types of HTTP commands that REST is based on which are GET, PUT, POST, and DELETE. Instagram uses API for users to pull up information and pictures
  • SOAP APIs: Stands for Simple Object Access Protocol. SOAP is a protocol that is defined by a standard. It is dependent on XML-based systems and programming, has larger and more expensive data. Despite the disadvantages, SOAP provides better security for users.
  • RPC APIs: Remote Procedure Call was the earliest form of APIs. They are designed to execute the block of code on different servers.

APIs are running data for business every day. They give businesses and users the flexibility to increase productivity and improve security. Taking advantage of APIs can help them have innovative approaches. While the potential is undeniable, efficiency is still another matter.

Source:

https://www.cleo.com/blog/knowledge-base-what-is-an-api

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

Docker

What is vs What isn’t

Docker is an infrastructure manager for Linux Containers. Docker is an excellent image distribution strategy for server templates created with configuration management systems like as Chef, Puppet, SaltStack, and others. Docker is not a replacement for Configuration Managers such as Chef, Puppet, SaltStack, and others. Docker offers a single store of public and private disk images that may be used to run a variety of operating systems (Ubuntu, Centos, Fedora, even Gentoo). Docker is not yet capable of connecting several servers or virtual machines.

When to use

Docker, like git or java, is a basic technology that you should start using in your everyday development and operations processes. You may use docker as a version control system for the complete operating system of your project. You can also use a docker to distribute/collaborate on your app’s operating system with a team. When your project has to go through many stages of development, use Docker. Try Drone or Shippable, both of which support Docker CI/CD. One of the best thing is that docker allows you to execute your code in the same environment as your server on your laptop.

Docker comparison

When you run java, you run the program on any system with a JVM, however, when you run docker, you run the code on any machine with a Docker server after you arrange your servers exactly the way you want them. Git tracks the changes in your code while docker tracks the changes in your system. In Docker, you can track changes throughout your entire system. GitHub is mainly though for code management, and Docker Hub is though for container build, management and distribution. They all work in the same way, despite the fact that they do various tasks.

Why docker

Since we’re already using Docker in class, why not take advantage of the extra time to learn more about it? I understood what Docker was but had never considered what it wasn’t, therefore this post helped me better comprehend what Docker isn’t. I’ve also discovered how docker is similar to both java and git, something I never considered before. I had no idea there were alternatives to Docker, such as the Amazon AMI Marketplace, which is the closest thing you’ll find to the Docker Index. With Docker, you can run the images on any Linux server that runs Docker. Another is the Warden project, which is an LXC manager designed for Cloud Foundry but lacks any of Docker’s social capabilities, such as sharing images with others on the Docker Index. The most important thing I learned is when to use docker.

https://www.ctl.io/developers/blog/post/what-is-docker-and-when-to-use-it/

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.