While looking at the course topics for my CS-343 class, the topic Law of Demeter caught my attention and I decided to dig deeper into the topic. I found a post by Arun Sasidharan called “Object Oriented Tricks: #2 Law of Demeter” which talks about what the law of Demeter is and how you should implement it into your code/design patterns. The Law of Demeter is basically that you shouldn’t give a single function the ability to know/navigate the entire system. Codes like ” obj.getX().getY().getZ().doSomething() ” has more knowledge of the structure system than it should. I think that it’s important to follow the Law of Demeter because not only does it look simpler to call only one method to solve a problem but it also avoids a possible security risk. If methods are able to be used and connected to figure out the layout of the system, then it makes the job of a hacker that much easier since they can figure out how they want to get to the information they want or to break the system.
The Law of Demeter seems to be a useful rule that helps to protect data and the overall structure of a system. I want to apply this to my own coding since it will simplify code and keep information secure. It seems that this is a difficult rule to apply and has some disadvantages to applying it as well like writing many wrapper methods and creating narrow interfaces. The Law of Demeter certainly fascinated me with how it can be used and why you should use it in your coding. I think that the Law of Demeter can and will be used as I learn more about it because for the most part I choose to take the easier approach in using multiple methods. Now that I know more about the Law of Demeter, I will look to apply it more in my code and find ways to avoid giving objects too much knowledge of the system structure. one thing that helped my understanding into what the Law of Demeter was was the use of the example of cells which was ” Cells don’t ask each other questions, they tell each other what to do”. this helped me to see how the Law of Demeter was applied and what it truly meant since the objects are the cells in this analogy, meaning that you shouldn’t have your objects asking around the system, the objects should be told what to do.

Link to Article Mentioned: https://hackernoon.com/object-oriented-tricks-2-law-of-demeter-4ecc9becad85

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

This week i picked the pattern, “your first language”. I was very interesting reading it. I got to know more about why you should learned your first language to perfection. At least master it well before learning another language. From the reading, get a language you like and very easy to use, is the best way to be a better programmer by mastering it. The reason is because all the programming languages follow the say pattern. Only different statement but the same principle. So by mastering one and feeling very comfy about it, make it very easy for you to learn new programming language with ease.

From the readings, to my understanding. I got to know by becoming very good at your first language, you need to ;

• Use the language all day, every day. Usually this means being full-time employed in the language.
• Read all you can about the language. Especially, “best practices” and idioms.
• Join a users group to talk with others about the language and what they do with it.
• Work with other people’s code! There is no faster way to learn what not to do in a language than to have to clean up after someone who did something awful.
• Support the code you write – every bug becomes a tour of your worst decisions!
• Study computer science and languages in general
• Learn a very different language. A great compliment to C would be a functional language like Lisp. This will turn the way you think about your procedural language inside out.
• Learn to use the frameworks and APIs available for that language.
• Take the time to do your own experiments with the language. SICP is not applicable to C, but the attitude of learning a language by testing its limits is a very productive one.
• Read the history of the language to learn why it was made the way it is.
• Attend conferences to hear the language authors speak, or to hear what industry leaders are doing with the language.
• Take a class in the language.
• Teach the language to others

As I said, reading this pattern made my understanding broadened. I really know by following the pattern given from the book will be a great fit for anyone who want to have a better and easy life at work in the future as a computer software or programmer.

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

On this Software Development Capstone journey part of my assignment is to choose 10 Individual Apprenticeship Patterns out of 35 patterns among Chapters 2-6 from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsmanby Dave Hoover and Adewale Oshineye. For my fifth individual Apprenticeship pattern I have chosen “Concrete Skills”.

Summary

Although you may have the skills to learn quickly, it is important to acquire and maintain concrete skills. This is because when you demonstrate that you have certain ability with specific tools and technologies it will increase your chances to be trusted enough to contribute with minor task until you start gaining stature, where at that point you will be able to contribute more directly. The concrete skills pattern suggests you to acquire the type of skills that would reassure your prospective team that they do not need to babysit you because you have skills that could be put to good use. It states that an “Examples of concrete skills include writing build files in various popular languages, knowledge of various popular open source frameworks like Hibernate and Struts, basic web design, JavaScript, and the standard libraries in your language of choice”. These concrete skills shows how you can benefit the company because it shows what you can bring to the table and be able to do on you first day of hire. According to the book a way you can show this by having “A deep understanding of Your First Language“. These skills are important in the beginning because as you “transition to the role of journeyman you will become less dependent on these skills, as you start to be hired on the basis of your reputation, your portfolio of previous work, and the deeper qualities you bring to a team”. Action to take are:

1. “Collect the CVs of people whose skills you respect.”
2. Identify five discrete skills on the CV for each of the people you chose, and then determine which one is useful for the kind of team you want to join.
3. “Put together a plan and a toy project that will demonstrate that you have acquired these skills. Implement the plan.”
4. Make sure you go through your own CV and separately list the concrete skills.

My Reaction

This pattern stresses the importance of developing concrete skills that would help you get hire in a job market. I agree with this idea. I found this pattern interesting but also useful and thought-provoking. This pattern has definitely changed the way I think about my profession and the way I think because it has made me realize that I need to sharping up my concrete skills in order to show how I can be beneficial in the work place environment.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

There are going to be many situations in which we will not be able to figure out a solution to something. Deciding what to do in these situations is a big portion of solving the problem. Sometimes we can get very frustrated and give up. Other times we will try mundane fixes that won’t even solve our main issue. One thing that we need to realize, however, is that we are not alone. Most often than not, some issues that we run into have been solved by someone else. There is no reason to tread dead water if a solution is out there. Finding the way to this solution is a key part in problem solving. So, what do we do from here? We seek out help.

The thing I liked the most about this method is that by seeking help, it shows our willingness to understand and continue to learn. It also teaches us how to figure something out on our own, even if we don’t know what that issue is. One main part I agree with about this method is that it explains how, since this field of study is fairly new, it can be difficult to narrow down the “masters of the craft” because an apprenticeship can only mean so much. The difficult part is finding that one person who CAN teach you and guide to on the right path. One of the hardest part about mastering something is finding a that specific master or network of masters in order to reach the goals you have set for yourself. You can’t expect to learn everything on your own, this is an issue in itself. You need to seek help, evaluate that help, and then decide if it is worth your time to continue to learn by them. If not, that’s something you will have to decide. One great modern tool that we can use to do this is the internet. A simple google search can solve a lot of our problems, especially in this field of study. But sometimes we also should be careful at which sources we are pulling from.

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

The apprenticeship pattern I decided to choose for this week’s blog was “Read Constantly.” It was somewhat self-explanatory, but I thought it had some good insights nonetheless.

It recommended reading books over blogs. I would imagine that this is the right course of action from researching blogs last semester. All the material was good and informative, but many times when the host was interviewing someone, it felt like a summary of what could be a very interesting book. There’s only so much that can be gained from a blog post or a podcast. The things that you learn from those can be valuable, but it is better to go deeper when possible. Even if you have a very wide base of knowledge, it will only get you so far when you only scratch the surface.

The quote at the very beginning, from Steve McConnell, says that if you read a good programming book every other month, you will distinguish yourself from your peers. This seems like a worthwhile task, and frankly it is very doable. He chalks this up to be 35 pages a week, which is less than many reading assignments for school. Those don’t take me very long and aren’t very hard. It would be helpful to read more supplemental material, especially on break and after I graduate.

I haven’t read any research papers in this field, but that sounds like something I should start thinking about doing, especially when I pursue a graduate program. It recommends reading some at least every once in a while.

It also recommends keeping a slim book to fill dead time throughout the day. I think this is a good idea, especially when something can be overwhelming. It’s like the old adage of how to eat an elephant — one bite at a time. Or in this case, one page at a time and whenever you have a moment.

This is something that I’ve been trying on my own in general as well. When I was younger, I was an incredibly avid reader, and I’ve slowly gotten out of the habit as I’ve gotten older. I would like to read more of everything. I think it is a mark of a well-rounded and intelligent person to be well read.

It was a new year’s resolution to read more. I have been trying read a few chapters everyday of something, which has mostly been non-technical so far. I’m going to to change that and start adding more material that will not just better me as a person but better me as a software engineer.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

For the fifth week’s reading, I chose to read the pattern, Be the Worst. It is about facing a problem where your rate of learning has plateaued. As such, a solution is needed and is presented as instead of being in a team where you are at the top. You will have to find a team where you can be at the very bottom. The objective is to work your way up from the bottom, and from that you should be able to learn from those who are better than you. By actively trying to become better than what you were before, you allow yourself to continuously improve. However, there are risks of placing yourself at the lowest. The first is that you could be a negative impact to the team which would mean that you aren’t contributing as much as you should. Second, you might find yourself losing motivation when things do not pan out the way you thought it would. The action provided in this pattern is to rank teams by skill level and find a team that would allow you to work your way up.

What I found interesting about this pattern is that there is no easy way of solving this problem. You have to be willing to improve, willing to learn, and willing to drop your comfortable position to continue chasing the top. After allowing yourself to do that, you need to continue having the motivation and enthusiasm to improve yourself in a team that you know is way more knowledgeable than yourself.

This pattern has made me think about the intended profession in a way that everything will not remain the same forever. As time passes, teams will become more knowledgeable, but every individual will learn at a different pace. If you happen to be a person that progresses faster and becomes better than the team much quicker. You will eventually come to the realization that your learning has plateaued. By planning your road map in conjunction with this pattern, you have a chance of continuing your journey to become a master if that is what you wish. This is what I learned from this pattern.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

This apprenticeship pattern seem to be able to fit most of us as we emerge as newly graduates going into the development field for the first time. We have enough basic skill and foundation to get us through problems but there are many things we have yet to uncover. Retreating into competence talks about how you begin to realize how little you actually know and the task you are assigned with may be a bit overwhelming.

The solution provided for this problem is to simply regain your confidence. Know that you have come a long way since day one and that you are capable or finding a solution. This is a problem that everyone will eventually go through; especially those who take on more than they could manage. The author suggests to re implement a concept that you know very well which usually works for me also. It allows me to regain composure and confidence at the same time.

I agree with the solution to this problem because I have already gone through it in my own ways. At the moment I am learning and gaining the skills to become a full stack developer. I am utilizing all my skills I have learned as well as new concepts that seem like a different language to me. Many times I find myself staring blankly at the screen, lost and confused at what I just wrote down or why my methodology isn’t working. Sometimes I even walk away and come back hours later. I find that each time this happens, I am leveling up; I am getting out of my comfort zone to learn new things. I know that this is just the beginning of this journey and it most definitely gives me confidence that I am able to solve the hardest of problems sooner or later.

Stay tuned for the next apprenticeship pattern!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

For today’s blog I will be writing about the “Expand Your Bandwidth” pattern out of chapter 5 of our text. I enjoy this pattern because the context is simple. “You have picked up a basic set of skills”. That’s it. That’s the context for the chapter. It is broad which leaves it open for many people to relate (perhaps not just software developers!). I can personally relate to this because I have a basic set of skills in programming that I have acquired over the past four years at school. Now that we have the context we can delve into the problem that the chapter presents to us. The problem put forth by the book is this: You have a narrow-focused low-level understanding of software development. The problem is that you think this way because of the narrow day to day scope of your work. When you work at a narrow scope of software development, then your knowledge and perception of software development becomes less broadened and more narrow and that is not good for a field that must consistently be changing and overcoming new ways of developing in the field. The solution is to broaden yourself by improving your ability to take in more amounts of new information. The text says “You’ve been drinking steadily through a straw. But there are seasons in apprenticeship when one must drink from the fire hose of information…” I think this is a perfect analogy because in a small setting like university classes we are hyper focused on our assignment at hand or the specific software skill/methodology that we are using for that class. A perfect example would be when I took my software testing class, we were solely focused on writing tests and not actually developing any code to test. In this case we were drinking from the straw, but sometimes a project would require you to know what was going on in the source code, which required other knowledge not related to testing, which in this case would be drinking from the fire hose; a much bigger flow of information. To make yourself marketable for a successful career you must know how to take all sorts of information from all aspects of software development. In this way and after reading this text, I believe that it is good to know a decent amount of information across many aspects of software development than it is to have a vast knowledge of one aspect of software development. Having the smaller knowledge of many areas allows for more flexibility and easier adaptations going from one task to another in the software development field.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.