This week I read about frameworks by reading “What’s a framework? All about software frameworks” by Lucas Stahl and Sean Higgins. Sean and Lucas did a great explaining what a framework is by making it easy to understand and giving many examples.

A framework is like a template that can be used to build your code on top of. Frameworks are premade code that take care of some aspects of the program. They are also reusable functions that make programming easier. Most programming languages have at least one framework that use them. The content of a framework can be very different, and it depends on the needs of the programmer for which one they should use. Many frameworks are open source that are maintained by the community of programmers but there are some from large companies like Microsoft or Meta. Frameworks might sound like code libraries but there is a difference. A quote by David Fateh helps explain the difference. Fateh said, “A framework,” he says, “is like a construction blueprint: A template that defines a basic structure for your build. A code library is more like a carpenter’s tool belt: It has tools designed to perform specific tasks”.  Lucas and Sean go on to explain the benefits of using a framework. Some of the benefits are being able to focus on one area of development, easier testing, development speed, reliability, documentation, and better security. There are many benefits to using frameworks but there are a few challenges as well. These challenges are structural limitations because frame works can’t do everything, having to learn the framework and the language it is based on, as well as having to pick from the many frameworks that are available today.

I learned a lot from this article, and I think frameworks could be a useful tool to use when programming. The diverse selection available seems like they could help in many situations. Being able to use a framework to cover a part of a program like the backend for example so another part like the front end can be focused on sounds interesting. Being able to focus on your area of expertise is a major benefit of frameworks. Although there are some limitations of frameworks the benefits seem to outweigh the cons. After reading this article I am now curious about all these frameworks and how I could use them to better my development skills. In the future I suspect that frameworks will be a common use for me.

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

This week, I decided to look at an article based on the GRASP principles, and found this insightful article from Kamil Grzybek, an experienced designer in the .NET Framework. The GRASP concepts essentially explain how to assign certain responsibilities to different classes within a project. Each principle is derived from a problem, and the principle solves the problem. The first principle, Information Expert, decides which class will take the responsibility for a certain operation. In his example, his Customer class takes the responsibility of compiling an order since it has all the necessary information to do this. The next principle is Creator, which asks the question who creates an object? The answer according to the principle to assign a class to create this object, only if said class is closely related to the object. The next principle Controller decides who is the first object beyond the UI to control a systems operation and delegate information. The fourth and fifth principles are Low Coupling and High Cohesion, which solve the issue of keeping classes independent and to keep them focused on minimal tasks. The sixth principle is Indirection, which solves the issue of avoiding direct coupling between objects. The seventh principle is Polymorphism, which helps control flexibility within the code. The eighth principle, Pure Fabrication, solves the issues of what do to when there is an intermittent task that needs to be completed and avoiding more direct coupling between classes. The final principle, Protected Variants, is argued to be the most important principle. It helps to keep code available to change.

After reading this article, it seems to be a more expanded version of principles and concepts we have learned earlier in the class. Most of the principles within the GRASP lineup are connected to either another set of principles like SOLID, or directly correlate to a specific concept like loose coupling. The main reason I selected this article was the nice use of physical code examples to show off the principles. Throughout the whole article, Kamil used a Customer project that tracked orders. Each concept was show in a different section of the project, which makes it easier to visualize when thinking about how to apply it to code that I create. This article seems more to be for more experienced software designers, which I enjoyed. Learning new concepts with descriptions that are easy to understand can be helpful, but having a more challenging description given to me challenges me to understand the concepts deeper.

To use these principles in the future I must remember a two different ideas.
1.) All aspects of the code need to be individual and loosely related to avoid breaking the code when adding change
2.) It is easier to assign certain tasks to a separate class than to jam pack a single class with all of the functions

Link:http://www.kamilgrzybek.com/design/grasp-explained/

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

For this week, I chose to read the pattern ‘Sweep the Floor’ from Chapter 4: Accurate Self Assessment. This chapter is on, as you can read from the name of the chapter, accurate self assessment. I did another pattern from this chapter not too long ago but I think this chapter is easily the most relatable for me at least. For this pattern, the context of it is that you are a new apprentice on a project. I chose this because I could relate this back to when we were first starting our group projects and getting into our teams. It was a foreign experience to me since I hadn’t had an internship yet or anything of the sort. For the problem of the pattern, it revolves around you being unsure of your place on the team and the team is unsure of you. This was relatable to when we first started, we didn’t know each other and our work flows. Luckily, we were doing Scrum so we had a leader basically ease us into things. Additionally, the problem also is wishing to find a means of contributing to the team’s work, earning the team’s trust and growing as a craftsman.

For the solution, it followed the same approach as most of the solutions in this chapter were. Pushing yourself to do tasks in order to grow as a craftsman. With this pattern, the solution was to volunteer for simple, unglamorous tasks. This is ‘sweeping the floor.’ Doing tasks that are mandatory to the program’s success such as maintenance reports, bug fixing, code review, etc. I thought this was interesting because my approach to getting trust from a team is doing the hard work first in order to show I know what I’m doing and to show that I won’t let them down. However, this approach seems more personable than my approach and much simpler, on paper, as well. This solution does come with caveats though, as mentioned in the solution. One problem is you may become the team’s gopher, this means being condemned to doing menial tasks no one else will do. I, for one, don’t think that’s a big problem but I guess it depends on the person and their ambitions. Another problem is that you may find yourself intimidated by doing anything other than sweeping the floor. I can kind of understand where this point of view comes from but for me, I don’t think it would be much of an issue transitioning between hard tasks to relatively simple, menial tasks.

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

Passion is the devotion we invest in of our interest, could be a hobby, sport, or even a profession. Upon reading the book “Apprenticeship Patterns”. There are multiple chapters that are divided up into 35 patterns to give a breakdown of the broad idea of being a craftsman. For example, I have read chapter 3 “Walking the Long Road”, towards the pattern of “Nurture your Passion”. This pattern entails about keeping a strong leveled mentality. Going into our career field as a software developer which the environment would cause an impact on one’s passion. This pattern gives us an idea on how to tackle this situation. 

After understanding the purpose of this pattern, I saw it made sense to find multiple ways to help keep positive during workflow. The section of drawing your map caught my attention because whenever we have a certain goal, dreams, and needs it is separated out from our work goals, dreams, and needs. Two different lives which you try to maintain but eventually it outweighs each other which conflicts you. Personally, speaking we would rather just be selfish and accomplish our own goals and dreams. We are only human. But at the same time, we do not want it to conflict our mindsets when it comes to our profession.

For the type of action, they would want to conduct to keep our passion in check was to write up a list to control a conversation.  It is true you must keep a cool mind and keep your mind positive. But there will be days where things will not work out. For example, what if you had a bad day, the only it will do is put you in a funk for whatever reason It may be. Work related. Personal related. There are many factors you don’t have control like an environment or said workflow. 

I believe that I can take these steps but not all of them. I do agree that you must absolutely make sure the passion is there and do however to protect it because it what makes us motivated to stay concentrated. People are different and should be able to nurture their passion differently. Composing a list can help but nobody would like to compose one before work daily, that can be taxing. Sometimes you must be selfish, such as leaving work while the team are staying late. Just playing it by ear on a daily as it can shift constantly. A road we are set and take the necessary actions. 

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

Confront Your Ignorance

This pattern specifically covers an area of your skill-set or knowledge that you are not well-versed in. It challenges you to take the thing you are ignorant of that is relevant to your work or perhaps relevant to future work and invest your time to master it. The roundabout way of doing so is, as it describes, to pick the skill-set or technique and fill those gaps.

Seems simple enough but I felt as if this pattern is missing a bit of useful advice. Your personal growth when confronting your ignorance is more than organizational as the actions describes. It’s a matter of personal reflection and recognition. It’s definitely easier to say, “hey I know nothing about network communication”, and harder to recognize your own competency in network communication. The pattern does cover a bit of this, but it seems to focus far more in directly confronting easier problems.

I picked this specific pattern as it directly impacted how I worked during this semester’s sprints. In specific I applied this pattern unknowingly when I was thinking about working on a specific issue that related to using html. I have seen html code and references to it plenty of times during my college career but have never really used it before. I also overhead fellow classmates speak about it on rare occasions and mention building a custom resume styled website using html and other tools. I have had plenty of introductions and chances to learn something that is common in computer science, yet I have never taken the chance to learn it. At the start of the first sprint, I finally confronted my own ignorance around html and put myself into a situation where I would have to learn it in order to complete the issue. While I could have done this at any time it seemed prudent to place myself in a position to succeed at and implement to help motivate me to fill my gap in knowledge. This is why I felt like this pattern should describe learning how to identify your weaknesses a bit more as just knowing your weakness is quite different as confronting it is. One is merely a slight acknowledgement and the other lets you learn how to continually find your gaps.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

This apprenticeship pattern talks about how software developers should learn about how they fail. It specifically discusses how apprentices should seek to identify the ways in which they tend to fail and attempt to resolve those that they think are worth fixing. It should be noted that this apprenticeship pattern is not about dwelling on past mistakes nor is about seeking perfection. Rather, the goal is to get a better understanding of yourself and your behaviors, habits, patterns, and conditions that lead you down the path of failure. With the knowledge gained of yourself, you will have an awareness of your boundaries and limitations. This awareness could also help you make conscious decisions about your actions, goals, and career as well as temper the tendency towards idealism.

By becoming conscious of the things that lead you to failure, you permit yourself the choice between working to fix them or cutting your losses. It is important to accept that there will some things that you are either not good at or simply require you to invest too much time and effort to make a small improvement. This will feed into your accurate self-assessment, but it also allows you to set realistic limitations on your goals. It is impossible to be good at everything, and accepting your limitations is important because it forces you to consciously acknowledge distractions and focus on your goals.

I personally think that learning how you fail is an incredibly valuable skill to gain. Failure is inevitable, and everybody at some point or another is going to experience it. If somebody does not experience failure, then that means they either have not pushed their abilities to their limits or they have learned a way to overlook their mistakes. Learning to recognize your failures, what led you to fail, as well as what you can learn from your mistakes is all vital to growth. It also helps software developer apprentices like myself have the ability to make better career decisions when drawing career maps for ourselves because learning how we fail allows us to be aware of our limitations and boundaries.

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

               I mentioned in a previous post that, essentially, failure is as much an important factor of the learning process, at least for those who use the mistakes they make as an opportunity to reflect and properly understand the new knowledge that they may have gained. This means that our learning process has helped us, in a way, adapt our way that we approach problem solving so that we may avoid falling into any pitfalls depending on what we are needed to work on or properly utilize any techniques that we may have picked up for the right situation. However, no matter how diligent we are in our learning, we all have certain strengths and weaknesses that play a major role in each individual apprentice’s learning process. This situation is elaborated in the pattern titled “Learn how you fail”.

               Now, it is important to understand what is really means to “fail” in this case. This patter is not about an apprentice being unsuccessful in their craft and giving up without putting the proper amount of work to improve. Rather, it is about an apprentice’s acknowledgment of where their weaknesses related to their craft lie, which weaknesses does one feel they are worth working towards mending, as well as how to approach their craft in such ways that their weaknesses do not interfere. When one needs to learn how to fail, what they are really learning is developing the self-awareness that is needed to further hone their craft. While being an expert on a specific concept may be convenient, turning into a one-trick pony because one is complacent in what they are good at and do not feel like taking the risks necessary to improve their craft will do an apprentice more harm than good in the long run. An example from my own experience (though not CompSci related) that comes to mind is from my job as a tutor; while I am familiar with all the mathematics courses I am expected to know, I am aware of my weaknesses in the way I tend to communicate certain concepts to others. Through experience, I learned how exactly that weakness manifested so that I would make sure to change the way I would communicate my knowledge to others.

               Though gauging how far we have progressed in our learning process based on the number of our successes may help us in building up confidence to continue honing our craft, it is important to acknowledge and admit our weaknesses, as well as knowing which weaknesses are worth improving or avoiding provided we take the necessary risks.  

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

The breakable toys design pattern proposes a solution to working in an environment that does not welcome failure. Since failure is such a huge part of the learning process, it is important to create a private space outside of work where failure will not damage anything. Hoover and Oshineye recomend building a simple system that is relevant to your work and easy to build upon. For example, you could build your own wiki and use it to learn HTTP, databases, and web design. You should enjoy the thing you are building so that you are motivated to keep building and breaking it.

I think this design pattern is really interesting. I can see how it would be useful to have a private project to mess around with and not have to worry about breaking it. This seems like a very good way to build up your confidence in an area while also being able to experiment with new skillsets. I also think it is useful to build a project you are personally interested in. If you are interested in the project you are using to learn, you are more likely to keep experimenting with it.

I probably will wind up adopting this design pattern once I enter my professional career. I like the idea of having a private project to experiment with; it would be nice to have the chance to get more comfortable with concepts I’m less familiar with in an environment where failure has few consequences. I am specifically interested in the example the book mentions of creating breakable games. Especially if it’s a project I’m interested in and enjoy working on, I think it would be easy to keep myself interested in working on it.

I do disagree with this being the solution to a work environment that doesn’t allow for failure. I think any work environment should be able to tolerate failure; if your work expects you to succeed all the time, you should not be working there. Rather than taking on extra work in an effort to avoid failure, you should find a healthier work environment.

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