When you think of the word smell, your first thought
is probably not computer design. Design smells are a vital part of designing
clean, readable and re-usable code. In total there are 7 main design smells.
They are rigidity, fragility, immobility, viscosity, needless repetition,
needless complexity and opacity. The reason they are called smells is because when
there is a “high smell” of one of these terms it means there is probably poor
code. According to Wikipedia, the origin of the term design smell was originally
from code smell which was in Martin Fowler’s book Refactoring: Improving the Design of Existing Code.

(https://en.wikipedia.org/wiki/Design_smell)

In this book the term code smell was essentially the
same as a high smell/bad smell would indicate a deeper problem in the code,
rather than what was on the surface.

The first design smell is rigidity. When code is has
high rigidity, it means there is often a lot of code that is hard-coded in. This
causes the code to become rigid because small changes can cause a much larger
impact through-out. In order to avoid a high rigidity smell, code should be
dynamic and able to fit the system it is in. If there is too much hard-coding
it will be very tough to make changes later on.

The next design smell is fragility, and this is
similar to rigidity with a few exceptions. Fragility is the tendency of code to
break when a small change is made, similar to rigidity. The main difference between
these two is with fragility, the areas that suffer are often unrelated to the
changes made. With rigidity, the changes directly affect the code related.

The third design smell is immobility. For a lot of
code to be useful, it needs to be able to work with other systems as well. With
immobility, the code or program could be beneficial to other areas but there is
too much effort/risk to be able to successfully integrate it.

The fourth design smell is viscosity which means that
code can become “thick” and hard to work with. When you are designing a
program, you want to be able to modify it along with the design, but “hacks”
can be done to quickly fix the issue. The problem is that the more hacks in the
program, the less the program sticks to its design. This cause a lot of extra
code and the program becomes highly viscous. It is important to know the impact
of these small hacks and how to limit them.

The next design smell is needless repetition, which is
pretty straight forward. In a program, you do not want to have to repeat the
same code over and over. Instead find ways to integrate and abstract the code
for re-usability.

The next design smell is needless complexity, again,
pretty straight forward. This can happen when a program includes sections that
are not yet utilized but “could be”. That extra code is clogging space and has
no benefit.

The last design smell is opacity. Opacity simply means
to become less clear. This can happen when there are many changes to a program
but no effort to keep the code clean and organized. Eventually the code will
become foreign to all that had worked on it before without proper care.

Keep all these design smells in the back of your mind
next project!

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

Hi dear readers. Welcome back/all to my next blog post about the next Pattern. The next Pattern I am going to write today is about ‘Reading List’. Yep you heard it right! Reading List! Just because you are a developer doesn’t mean that you got no more reading to do.

This Pattern in the book talks about how to start with a reading list and how to keep up with it. The authors make very good points when they say that its hard to even start a reading list as you might not be sure what to read first. I like how one of the recommendations is to ask your mentor/professor. They would be the people who know your development level better than anyone and will definitely be a great help. Another point to keep in mind is that the initial Reading List you have created might (probably will) change after you have finished one of them. Having a Reading List is great because it also makes you reflect about what you read previously.

As mentioned in the book, we should always think and analyze about the book we just read and try to figure out on our own on what should be the next book to read. Computer Science is one of these field that new things will  always keep coming up and what better than books will be describing these new innovations. Indeed these new books should be on top of the list.

I believe that there will be cases where you/me as a reader will be disappointed on one or more books. It’s not right that just because one book was not good enough, we should stop reading other books. I think that when you don’t find a book interesting or good enough, it’s a good sign as you are thinking about the book content. This will give you a better understanding on what you would like to read next and what is your favorite area. For example, for my reading lots of books about programming languages wouldn’t be too much interesting. On the other hand there are people who love reading each and every book about programming languages and this is because they’re passionate about it.

I would recommend to just start somewhere, and then you will be able to figure out on what to jump on next.

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

On my readings on the patterns, “share what you learn”. By teaching what you already know about your profession, you’ll learn more, make new connections with people, and find new opportunities. And by doing that you will may find it very fun.

From the reading, to my understanding, another reason you shouldn’t wait to start sharing with others is that it will help you learn. Research has shown that when we explain something to other people, we come to understand it better ourselves. The process of teaching or sharing what we have learned to others, helps us recognize gaps in our own understanding and better organize information in our minds.

Also one thing i notice about sharing what you learn with others will give your talents more exposure, thus giving the people you interact with the opportunity to identify you as a valuable expert. Helping others can help you build your reputation. Also sharing what you learn can be a great tool for everyone. All you need to do is to be permanently connected to the hot business topics and offer your expertise every time you can. When people are open to prove their value through their competence, it’s easier to notice the ones likely to organize people and to take initiative.

Let’s take for instance, you are in the team, by sharing  what you learn or known and talking about certain decisions and procedures, the new guys or juniors could easily acquire new sets of skills. Create an environment where everybody is encouraged to ask questions, and help professionals in all your locations and job positions stay updated with the latest information in their field. Also by sharing what you learn, increases the productivity of your team. You can work faster and smarter, as you get easier access to the internal resources and expertise within your organization. Projects don’t get delayed, people swimmingly get the information they need in order to do their jobs and your business fills the bill.

I really enjoyed reading the pattern because i got the some main importance of sharing, strategic ways of sharing and things that i do not have to do.

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

I learned a lot from this first sprint. A lot of issues were being run into and as a team we were able to overcome these obstacles to all continue. Something that I learned that collaboration can often lead to success because you may learn something about a topic that you may not know. Next I will explain some of the tasks our group has completed. First, we had to make sure all of us had a sprint backlog. These included tasks for our sprint timeframe that we should be able to complete. We setup a group environment on GitHub to clone our ng2-amrs repositories so we could get oiur AMPATH portal up and running. This is where we, and many others, ran into most of our problems. A lot of us had many different errors so it was very confusing trying to find fixes for all of us at first. We coordinated with other groups via slack channels in order to first find out who was having what errors. After posting about the errors and discussing them in the slack channels and amongst each other at our meetings, we started to research for solutions.

For example, one of my teammates was getting an error upon trying to run the “ng serve” command in order to get the virtual server running to launch the AMPATH login portal. This error was stating that there was an incompatibility with Windows 64 bit operating systems and would keep failing at compilation. In order to solve this, we needed to research the issue and eventually found a fix online that worked for the majority of people having issues with this. One specific issue that also seemed to affect people trying to run the “ng serve” or “ng build” commands was that it was throwing that certain dependencies were missing. After trying multiple things, we eventually found out ourselves that this was indeed and issue with the installation of node.js. In one of our previous software developement classes, we had already installed node.js. However, there was one major issue that kept us from compiling the project succesfully. This issue was that the first time we had installed node.js, we did not specify it to install all of the dependencies, therefore “ng serve” was not able to run because it would fail at compilation due to these missing dependencies. The fix we found for this was to completely uninstall node.js and reinstall it, but this time also installing all the dependencies (python, net framework, etc.) This fix corrected the issues for us and we were finally able to run the command and go to the local host AMPATH portal. Next there seemed to be an issue where compilation would hang at around 92% and fail. The fix for this was to run two different commands that we had found on stackoverflow for someone who was having this same issue: https://stackoverflow.com/questions/50621043/fatal-error-call-and-retry-last-allocation-failed-javascript-heap-out-of-memo

The fix fix for this was to run two commands in the node modules folder that fixed the package.json file. After this, we ran “npm run build-prod” and then this fixed the issue.

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.

Often times we feel as if we may know how to do something, when in reality we may not know. Some problems that arise can may seem familiar but often times need more digging to figure out the answer or solution to. The Expose your ignorance pattern explains this by growing yourself in order to find a solution. The pattern states that we are not going to know every little detail about every software or domain we need to use in our jobs. There are people depending on us to perform a task, but the issue is what exactly do we do when we can’t overcome these obstacles? Even if you don’t know what you are doing or aren’t aware of a certain situation, it is always better to atleast look like or be willing to be competent in whatever the task at hand is. One great point that I think this pattern brought up was conceding your pressure and just telling your clients or colleagues that everything is okay, even when it is not. If you just tell people that thing are okay even though they aren’t this can lead to a massive snowball effect.

For example, maybe you don’t understand how to use the companies’ software that you are working for yet and there is some things you either want clarified or need more time on. If you were to just say that you understand everything, what does this precedent set? It tells people that you are okay to move on to the next thing and most often than not, whatever that “next thing” is, it most likely builds upon the previous task or requirement you should understand. Sometimes it is just better to be honest and let your team understand that  although you may not currently understand what is happening now, you will be able to learn it. As long as you show you are able to learn the materials and keep up even when you are behind, you will always be valuable. Ask questions because not only will it help you, but it can often times help whoever is answering the question with something they may not have known about either.

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.

For this blog post, I will be discussing the Apprentice Pattern, Expose your Ignorance, found in the text Apprenticeship Patterns. This pattern piqued my interest. It discussed how to deal with inevitably not knowing something. It is comforting to hear that I am not the only one who sometimes feels out of their depth.

This pattern gave me a few things to work on. It can feel natural to tell people what they want to hear, but that isn’t a good way to build trust. I know it may seem obvious, but it is very easy to fall into that trap, and I know from experience. I like the idea of building a reputation on my ability to learn rather than what I say I know.

Ignorance isn’t something to hide — it is a chance to grow. This brings to mind a “growth mindset,” which means that instead of seeing challenges as something that sets one back is instead something that can be learned from and used as fuel to grow. It is clear that this book adopts this idea, even if it isn’t necessarily one of the patterns.

The pattern made me think of my ignorance in a new light. Instead of trying to pretend that I know more than I do, I should make it well known what I don’t know. My reputation shouldn’t come from what I know, it is my ability to learn new things.

I also liked how they wrote that being an expert is not the goal. The example of a marathoner having strong legs from running even if that wasn’t the goal seemed like an apt metaphor that being an expert is likewise a byproduct. In addition even if we are experts in one area, we will always be ignorant elsewhere. We should relish in what we do not know. Ignorance is something that should be welcomed because it means we are learning and growing.

I feel this pattern is tougher said than done. It is a simple concept, but it might take years to fully master. That being said, simply being aware of my shortcomings in this area is a huge step forward. This is something I intend to start immediately in every project that I am currently working on and every project in the future.

From the blog Sam Bryan by 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 forth individual Apprenticeship pattern I have chosen “Practice, Practice, Practice”. I will first summarize the pattern and then I will state my reaction of this pattern.

Practice, Practice, Practice summarized

It is important that you take the time to practice your craft in a comfortable stress free environment where you can make mistakes and learn from them. It is just as important to have constant feedback in order to avoid developing bad habits. According to the book, “The key to this pattern is to carve out some time to develop software in a stress-free and playful environment: no release dates, no production issues, no interruptions. As Dave Thomas says of practicing, “It has to be acceptable to relax, because if you aren’t relaxed you’re not going to learn from the practice.””. This pattern tells you about a good tool to use. That is a coder’s dojo, which is a place where people can perform code katas regularly and publicly within a tight-knit community of craftsman. This tool is also good because it allows constant feedback. Another good tool to use is one of your old programming books. Pick an exercise from the book that is not too easy for you. Then, try to solve it from scratch for once a week for about a month. By doing this it will allow you to see how much your solution has improved and sharpen up your skills.

My Reaction

This pattern shows you that a good craftsman, must constantly practice in order to sharpen his/her skills. It also, tells you to constantly receive feedback of what you practice because it helps prevent you from forming bad habits. Personally, I agree with this idea. I found that this idea is not just 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 “practice, practice, practice” on this long road of Software Craftsmanship.

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.

For the fourth week’s reading, I chose to read the pattern, Breakable Toys. This pattern focused on the problem where you are introduced into an environment that doesn’t allow you to fail. Even though everyone knows that you are learning from your failures is the best form of learning. There solution is that you create something similar or a private environment where you can create and work around projects that are similar but not replicas of the projects where you work. The goal is to learn from failing in similar projects where you can learn how to work around them and possibly apply concepts learned in the future. An action provided for this pattern is to build a simple wiki while maintaining quality. In effect, you should be able to keep implementing more features by learning and applying them. Concluding this would be, don’t let work constraints prevent you from learning for yourself and take control of what you can learn and apply.

What I found interesting about this pattern would be their example of breakable toys. Which is to re-create known tools to give yourself a deeper understanding about the tool and why it came to be that way. Examples of these are games like Tetris, tic-tac-toe, or other simple software. By being able to successfully recreate such games and software, you can get a feel for the thought process and problems that the first creators may have come across and face long ago. Enabling yourself to have time, experiment, fail, and try again is essential in learning. Another would be the wiki solution, as you may learn much more than expected over a longer period of time.

This pattern has reinforced my current thoughts about my intended profession. I believe that there will be many different environments to face in the future. Some may be welcoming, and some may not be so welcoming. By learning about how to deal with a situation such as this one where failure is not allowed. Being able to adapt quickly and create a workable solution is important in progressing as a person and in the field of software development.

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.