Sprint Review Blog # 1

          We learned quite a bit in our first sprint for the AMPATH project which ranged from troubleshooting compiling errors to understanding team dynamics. After some reflection, I found that the mutual troubleshooting that our team did allowed us to bypass any icebreakers that were needed. We were able to professionally and respectfully look into each other’s problems while making sure that no one was left in the dark. After learning about our team dynamic, I will proceed to do more involved communication through slack rather than other private forms of communication. We had begun to use texting a form of communication but quickly changed to slack to ensure that everything was able to be pulled up easier in the future for documentation and blogs. We learned to better troubleshoot using sites such as stackoverflow and GitHub to find information on node as well as npm versions. The start of our first sprint consisted of working on the front end of the project to make sure it was able to run and look into the server side as well to gain more information on how it worked. We had many problems when trying to make the ng2-amrs repository to work when we cloned them on to our own computers. We consulted each other and the various other teams to understand the common problems everyone was having and fix them together. After cloning the proper files onto our computers, we immediate ran into problems when trying to run the project. We were met with various errors that we were able to fix by updating our versions of npm and nodeJS. The npm version was easy to update through commands in the terminal but various team members were having issues with updating node through the terminal, so a manual reinstallation was necessary. During the installation, we found that we must check a box that allowed node to install packages that may be needed as a project is built to ensure that the project could continue to compile. After this error, I happened to get a windows x64 compatibility error for certain files within the project, specifically a file named style.scss. Fortunately, our professor was able to locate a solution to the error and explained that we should type the command “npm rebuild node-sass” to rebuild that node so that it would work with our version of windows. After trying to build the project once more, we ran into another error when running the command “ng build –prod” which would have let us build the project and figure out any other errors we were having. The error said that the javascript process ran out of memory which seemed quite odd. Our teammate Harry was able to troubleshoot this error from stackoverflow using google and emailing people from AMPATH. We were able to change some of the memory restrictions on the javascript process and ran the command npm start which allowed us to fully compile the project and get an interface running. We currently are still facing issues because the project says that it was compiled with warnings which we have not delved into yet as we are awaiting more information from AMPATH. Our troubleshooting methods were mainly using our resources from the internet to find out why the project was running into issues until we were able to properly compile it into a workable interface.

 

References:

Node JS manual update

https://nodejs.org/en/

Style.scss error

https://github.com/sass/node-sass/issues/1918

JavaScript out of memory error

https://stackoverflow.com/questions/50621043/fatal-error-call-and-retry-last-allocation-failed-javascript-heap-out-of-memo

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Software Capstone: Project Progress

In our class, we are working on a project that has to do with the food pantry on campus. We are designing software in the Java language in hopes that we can create a web based database solution for our pantry.

So far, we have been setting up the basic structure of our Gitlab repository and communication methods. We use Trello as an online cork-board showing our progress across each of the activities we must accomplish in designing the software. We use Slack for our main channel of communication. Besides that, Gitlab takes care of the file hosting and in accounting for the different versions of our code.

We have set up a Maven project with basic test code and a few other files pertinent to the project. Otherwise, progress is moving along slowly but steadily.
Currently, I am working on implementing test code to parse JSON files (read and write to them to be more specific.)

I will write more as time goes on, for now I hope you have a good rest of your day or night.

SMR

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

Apprenticeship Patterns Blog: Confront Your Ignorance

Hello and welcome back to benderson’s blog! This week we are discussing a different pattern that is found in the book Apprentice Pattern called “Confront Your Ignorance”. Confront your ignorance talks about identifying gaps in your skillset that is relevant and will affect your everyday work. The book talks about a common problem with most people trying to master computer science and that is where to start. There is so much in computer science that you don’t know where to begin, you got to decide on a language to learn, what to program, etc. There are too many pathways just to choose one. The solution though is to pick one skill/technique that will help you actively fill the gaps in your knowledge, and you can do this in many ways as well, some suggestions that book has is to look at overviews or FAQs of different computer science topics. Either you eventually master it, or you get good enough in the skill and you move onto other gaps that you need to fill. To find the gaps in your skillset, you need to do another pattern known as “Expose Your Ignorance” which confronting your ignorance attacks.

Confronting your ignorance is a challenge of mine as I want to be proficient in other programming languages other than java, but I don’t know which one to choose half the time. I have tried python and a little C but I always get caught up in something else and never finish learning all the ins and outs of the languages. I feel like I’m familiar with all my ignorance’s, so I’m passed the exposing my ignorance’s phase and I just need to confront them. As I have said before, I’m worried about getting into my first job and not being able to work efficiently enough so getting experience and filling my gaps is something that I need to do to gain more confidence. I probably will start learning another programming language soon that most workplaces use just so I’m ready to use the language right when I get into the job. Eventually though, I will do my best to fill all by gaps and get the job I need to succeed. Thank you for joining us this week on benderson’s blog, make sure to comeback next week for more patterns.

 

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

Expose Your Ignorance

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.

Ignoramus? Me?

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.

Journey into Practice, Practice, Practice (An Individual Apprenticeship Pattern)

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.

Learn how you fail

Welcome back everybody to another Apprenticeship Patterns by Adewale Oshineye, Dave Hoover blog post. Today pattern is to learn how you fail which is about how we should gain knowledge from our failure. I agreed with this pattern context that failure is inevitable. I believe every successful person failed more than they succeed. I think that failure can be anything from programming to any day life activity. When reading this pattern, I realize that I have a lot of daily life fail goals. I will prioritize the fail and figure what is worth solving. I learned that it’s important to gain self-knowledge about the patterns, conditions, habits, and behaviors that lead me to fail. I disagree that we should consider cutting out losses and accept that there will be some things that we are not good at. I believe that some things that are out of our control should consider cutting loose but things that just requires more effort should always be work on to fix. I think it’s important to set unrealistic goals every day so you can push your boundaries. Even though I different thoughts on this patterning method to set realistic goals, I can envision that setting accomplishable goals can be more effective than setting unrealistic goals. This method will result in many failures but that will have many benefits as well when progressing to be a better version of yourself. After reading this pattern I am more aware of the way I now work. I feel the need to go over my failures and evaluate them. I found this pattern useful but very familiar. Even though this pattern was very brief, I still think it’s important for every programmer to review. This pattern made me realize that setting too many goals and I should be more focus on the worthy ones. I didn’t physical do the action exercise, but I don’t the main objective of the activity when reading it. I think the main idea of the action is that error is inevitable. All in all, this pattern learn how you fail is worth reading and change the way I work.

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

Creating your own toys!

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.

Reflecting on “Apprenticeship Patterns” – Sweep the Floor

It’s fair to say that I am nervous about entering a computer science job and working with a professional software development team for the first time. While I will be fortunate enough to graduate with knowledge of agile development, I have a feeling that it will be quite different to participate in development with more experienced coworkers, rather than with classmates with similar skill levels as me. This week’s apprenticeship pattern, “Sweep the Floor,” described various ways that I can potentially overcome this initial worry of fitting in and being able to contribute on the team to the best of my ability.

Sweep the Floor discusses my exact predicament: being the new apprentice on the team and struggling to find my place within it. The solution for this issue is to work on simple and more mundane, or unglamorous, tasks which the rest of the team may find more tedious. Or, the apprentice may focus more on the “edges” of the project (rather than the “core”) to minimize any risks to the project that could come with putting a newcomer on the more difficult parts of the work. These tasks are still necessary for team success, and therefore make great experience for an apprentice who is just starting out in the field. By completing these seemingly unimportant tasks, the apprentice can show the rest of the team that he or she is capable of producing quality work that benefits the whole group.

Before I read about this pattern, I was already aware that as a new member of the software development team, I wouldn’t have as much responsibility or experience as other coworkers who have been on the team for a longer period of time. This pattern gave me a better sense of direction, in terms of more specifics for the kind of work I could expect to complete when first starting out on the development team. I have always found some reassurance in the thought that new employers and colleagues expect fresh college graduates to not have much experience outside of the coding projects they completed for classes. This pattern helped further encourage me that I can make the most of this “newbie” status by finding important tasks to do and still gaining valuable practice.

Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Pattern 1: Your First Language

I decided to dive in with one of the first patterns of the selection, “Your First Language”. I chose this one because I was curious about the tips that the author would give individuals trying to decide on a first language, as well as to see if any of the tips translated for someone like myself, who is trying to branch out into learning more and more languages. This pattern breaks down the steps to choosing a first language and gives several factors for why you should potentially choose a language but makes sure that it is clear that these are tips and not the only reasons for selecting a first language. After picking the first language, the pattern lays out some tips for how to actually learn the new language. The pattern also lays out a simple means of learning more languages down the line and why someone should pick a particular different language.

I’m glad that I chose this pattern because I’m currently in a position where I am forced to learn a new language for a job I will be starting after graduation. The language that my new position almost entirely uses is C++ and I have absolutely no experience in it. The procrastination is killing me as my “native tongue” as the pattern describes it, is Java. Java is what I always try to use to solve problems even if I’m being asked to write in a language like javascript, python, etc. I always revert back to the concepts I’ve learned throughout college almost exclusively using Java. Learning C++ is going to be something that I must do and will attack throughout the next few months before starting my job. The opening to the article was also very helpful in relieving the stress slightly as it talks about how when you start your first job, you’re not expected to be an expert in ANYTHING. I’ve learned that through my last two internships where even though they were both Java based, they used entirely different frameworks and almost everything that isn’t core Java syntax, required an entirely different skill set and understanding.

The only part of the pattern that you could argue I disagree with, is the complete focus on your choice being driven by potential physical mentors. With the internet and communities within the internet, it is relatively easy to find mentors online who are more than happy to answer any of your questions in understanding a new concept or a language for that matter. Overall, I found this pattern VERY useful!

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.