Author Archives: nbhc24

Sprint 6 Retrospective

This sprint we made huge advancements towards accomplishing our goals for the semester.  Unfortunately, due to the time constraints, we will not be able to produce a final product.  Hopefully, we will be able to provide something that the next class can build on and learn from what we are able to put together and pass on to them.

For this sprint, we each chose a different aspect of what was needed and each worked on different services that we planned to bring together at the end and the beginning of this next sprint before working on the presentation.  We ran into a lot of issues though during this sprint with having crypto-js importing correctly. I am unsure at this time whether the crypto-js library will be able to be used moving forward or if the team that works on encryption next semester will have to find a different library to use.  I do feel that we have learned a lot of lessons though. We were able to participate in a project the same way that we will when we start working after graduation. I believe that is more or less left to figure it out on our own and put into scrums will make the transition easier when we take on our first real-world project outside of school.  I believe that another part that worked against us is that none of us were quick enough or confident enough to step up into a leadership role to help guide the team and help make sure we were reaching goals throughout the sprint, as well as the other sprints.

This sprint I did learn a lot more about Angular and testing in Angular in particular.  The set up reminded me a lot of JUnit testing that we have done in the past. You start by declaring whatever variables are necessary at the beginning of the test.  If they are variables that you need to be repeated for multiple tests you can either put them under declare each or to declare once before any tests run. Then in your tests to state whether or not you expect to equal or not equal a specific outcome.  From there you will be presented with an output to let you know if the test either passed, failed, or failed to run successfully. I do hope that while we will not complete what we were asked to deliver, what we will present will help future classes and does not have to be thrown out completely.

The next sprint will be our final sprint and will also be a shortened sprint, roughly half the length as a regular sprint.  We will be preparing our final group presentations and it will be tough to do without having a set of deliverables to present to the rest of the class.  I do think that ours will be a little different than the rest of the groups as we will be focusing more the lessons that we learned from failing to meet the desired objective of this semester.

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

The White Belt

The White Belt apprenticeship pattern is one that focuses on your mindset when approaching new problems and learning new skills.  It encourages you to approach new situations from a point of view that you are a beginner. That can be confusing, it’s not to say that you should forget everything that you have learned in the past, just that while using skills that you may already have when learning new ones just keep in mind that you do not know the new skill and should approach it with an openness and readiness to learn as much as possible.

When I was in the Army we were constantly going through additional schools and courses to build our list of skills.  Whether it was general skills for service or specific to our job such as new routers or satellite terminals. With all this schooling we learned quickly that you need to realize that you don’t know what you are in the course for and are there to learn that skill or how that equipment works.  When you realize that you are a beginner you open your mind to the possibility of accepting all the little things that you need to know to help grow your proficiency with this new skill.

My first job out of college will be a Quality Assurance Engineer role and the company I will be working for does not use an object-oriented programming language.  This will be a large shift from college where I spent the past four years developing skills and learning new things centered around object-oriented programming languages.  I plan to take the skills that I have learned through the years at Worcester State and keep them in the back of my mind and use as a foundation, but I will approach it with a clear head that I don’t know what I am doing, but open and ready to learn what they teach me.  Another important point to keep in mind is that even if I think I know some it is important to find out how they want me to accomplish the type of task. There may be a specific way that the company needs it done, those reasons could be from a legal standpoint or just company preference.  I’ve learned over time that the specific reason why things are done a certain way may not get passed down and may not make sense at the time, but chances are they are done that way for a reason and there is a better approach and talk to your manager if you think you may have a better way.

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

Dig Deeper

Dig deeper is a very important apprenticeship pattern to remember throughout your career and especially one to pay close attention to early on in your career.  It stresses that just writing a solution that you found online or just guessed until it worked is not good enough. It is important to know why the code solved the problem that you were having.  You should also look as to why was this the chosen solution, why code A over code B. This will help you stand out at work as someone who is a more effective problem solver. This will also help so you don’t submit a project that is only half complete; maybe the question that was answered on stack overflow did not include a test that was specific to your work.  If you do not dig deeper into your solution you may not realize this and turn in an unfinished project. When you only scratch the surface and just barely do enough to get by or even less than that work falls to others. There is a set amount of work that needs to be done for each project. Just because you do less doesn’t mean less work needs to be done, it just means that you are putting a bigger burden on the rest of your team that needs to complete their own work and pick up your slack as well.

When moving on from school I intend to make it a point to set aside time to review all the work that I complete as well as try to fully understand other parts of the program that I have a chance to see before submitting my work.  I think this will be beneficial for a few different reasons. First it will help set an impression with both my peers and superiors that I am a thorough worker who puts extra effort into my code. More importantly though it will allow me to expand my knowledge and provide the best possible solution for the problem that I am presented with.  It will help a well rounded tool kit that I may not only use immediately but could be applied in the future too. Doing this early on will create a solid foundation to build on for the foreseeable future.

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

Sprint 5 Retrospective

This sprint felt much more productive than the previous sprints from my perspective.  I think that is mostly because we did more than research or creating test programs. This sprint we started writing services for the AMPATH project.  We created an encryption service, at this time it specifically focuses on hashing passwords. We also added a test for this method simultaneously, by the end of this sprint though we were unable to run the test successfully.  Moving forward that will have to be one of the focuses is to get this test working, I believe that it is necessary for us to get this test successful in order to use it as a template for creating our other tests. There are two pieces of wisdom that have stuck with me that I believe will really come in handy for this next sprint.  “Slow is smooth, smooth is fast” and “Those who fail to plan should plan to fail”.

If we rush into writing other tests without building a successful one I think that there is a very high chance that we will get in over our head with too many tests that will fail for various reasons and we will start to try and fix different issues at the same time and just creating more issues.  If we take our time and focus on fixing this test first then we will have a clear picture of what is needed to write successful tests. We need to slowly approach this to help the project from a larger perspective move smoothly and at a good pace.

Since we are quickly approaching the end of the semester and the end of the project, everyone participating in the next sprint planning meeting is crucial.  If we do not take the full opportunity to carefully plan out what we will each be doing over the next week and a half the risk of us falling incredibly far behind to not be able to produce any meaningful deliverable to the project and negatively affect the ability for the other teams to effectively move forward on their own projects.

The service we did write however is a good start, we created an encryption directory within src/app.  In this, we created a hashed password service that takes a string and hashes the string. In the spec service for the hashed password, we wrote a test to test if the hashed password does not equal the original string that was used as a test password.  The test originally failed and produced the error that “Cannot find type definition file for ‘source map’.” After doing some research I thought I found a solution for manually adding “@types/source-map” to the package.json folder. After adding this and running ‘npm install sourcemap@latest –save’ the new error that was given was that there were now conflicting definitions for source map.  The solution on stack overflow that I found called for doing both, but I will now try removing the line from the package.json folder and see if that produces any significant changes. Depending on what that produces will determine the direction that we move in from there.

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

Breakable Toys

When starting in a new work environment, especially when stepping into a new craft as an apprentice you only want to produce positive results, even though failing is a great learning tool.  A good apprenticeship pattern to develop is to create breakable toys. Develop personal projects that you can afford to fail on and break so that you can learn these valuable lessons without it having an impact on your performance review and without risking your job.  These can be programs, servers or anything else that mimics your work station and helps develop your toolset. The important part though is to remember that it while it should mimic your workstation it should not intermingle with your work by any means. This could lead to massive problems if you break your toy and it negatively affects your work.  You also don’t want to run the risk of breaking any confidential agreement that may lead to legal trouble beyond just losing your job. This is not a pattern that should just be applied blindly; you need to apply a basic level of common sense of whether or not it would be ok to include things that you may have gotten from work onto an unsecured system.

When I start my new career I intend to mock my work station at home to the best of my ability.  I will use this to create similar projects to the one that I am working on so that way I can have more freedom trying solutions.  While that is part of what version control fixes this will allow slightly more freedom to try things that shouldn’t work and take the time to see why they don’t work as a viable solution to the task at hand.  Then as time permits I can create new projects that are not associated with work and expand my toolset to work on mastering new areas of my craft. I know for myself that I learn better by doing something hands on rather than in a visual manner.  Creating a personal workstation will allow me to further develop my craft and skills that I need to succeed in this new role. It will also allow me to explore and create any personal projects that I may find interesting that will help develop a broader toolkit that may come in handy later in life.

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

Learn How You Fail

Everyone is going to fail at one point or another in our lives.  Those that do not experience failure haven’t tried; failure is a part of living.  The important part is to see what these failures are, see what setbacks you face and what you are going to change moving forward in order to try and keep from repeating the same failures over and over again.  It may also just mean recognizing when things are heading in a direction towards failure and cutting your losses.

This is another apprenticeship pattern that I believe can be applied to any other profession and also extends to all aspects of life.  Early on in my career in the Army, I saw my share of failures and mistakes. The Army knows that this will happen and that is a big part of basic training.  Making mistakes and realizing that a lot of the time it is not the end of the world. The important part is to not dwell on your mistakes and feel sorry for yourself, but instead to identify what caused the failures and change your habits or actions to prevent that mistake from happening again.

Starting at a junior position I will be in a position to make plenty of mistakes and fail multiple times.  I am excited about this opportunity because while I understand that failure should not be celebrated and we showed be striving for success, it does give me the chance to learn and grow in this field.  It will give me a chance to stumble and interact with my superiors who will provide guidance and pass along what they have learned. If I stay away from any position or role that has the opportunity for failure means that I have also stayed away from any role or position that gave me a chance to succeed and progress toward a mastery of the craft.  Taking risks and running the possibility of failure is what will help me grow in this trade and pass that knowledge along to others that I work with and those that come after me and hopefully leave the field a little better than when I came into it.

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

Share What You Learn

Share what you learn is a pattern that believes that in order for new apprentices and others to learn we need to share what knowledge we have.  This is a very important apprenticeship pattern that is looked over often. Passing along your knowledge is what allows future generations to improve standards and practices.  It may also help your peers fill in that missing piece that they may need in order to complete a large project that they are stuck on. With the advancement in technology, it is easier than ever to share what you have learned with almost anyone around the world.

My past work experiences have instilled in me that this is absolutely true.  When I joined the Geek Squad at Best Buy I had a base level of technical knowledge but was not an expert by any means.  Thanks to the other employees sharing what they knew as I watched on for the first few weeks. This allowed me to take in and learn from what they already knew instead of being on my own to figure out what the specific problem was, research the different possibilities that could have caused this to occur, and finally trying the different solutions through trial and error.  This not only made my life easier but created a better experience for our customers. They got their device back sooner because we already had a good idea of what the problem was and they were able to start from the most likely solutions and work out from there. It also made them feel more confident in our abilities to work on their unit. While some may know that there can be different causes for a problem and a solution could be as easy as turning it off and on again, most customers that I interacted with did not know or understand this concept and would sharply lose confidence in us if we were not magically able to touch the device and have it fixed so the quicker we are able to do so the better.

As a brand new apprentice, I will not have the ability to follow through with this pattern right away I will be able to, and plan to, take full advantage of others sharing what they have learned and absorbing as much information as I can to better contribute to the team and the final products.  I do believe that it is a very important pattern and as soon as I am in a position to help pass any knowledge that I have along to others in order to help them improve and develop in their trade I intend to take full advantage of that opportunity. It will help improve on three different aspects.  First, it will help the apprentice to develop a stronger toolkit moving forward. Second, it will help you develop leadership skills and presentation skills. Lastly, it will help your trade as a whole, having more skilled tradesmen working will help create better products and practices.

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

Sprint 4 Retrospective

This sprint was a little different than the others because the week of spring break was in the middle of our sprint.  I think for most of the team, and certainly know that this applies to myself, that the week of spring break threw off my rhythm of work.  I had plans for things to accomplish, but other things kept coming up to include taking a break from all school work and reset. Although we were able to accomplish several of our goals and move forward as a team.  We worked on different basic programs that used encryption in order to try and find which library would work best for this project. In the end, we chose the crypto-js library. Crypto-js is flexible enough that it can effectively encrypt a string to allow us to accomplish our goal of encrypting passwords.  It will also allow us to encrypt objects so that will make it easier to encrypt information inputted by the users. From what we can tell so far this will cover all of the encryption needs that were laid out in the user stories at the beginning of the semester.

We also talked and realized that we may not be moving at the best pace and are not where we are all happy to be for the project at this point in the semester.  It’s important that we realize that we can’t go back and change what has happened earlier in the semester. All we can do is realize what we may have done wrong and fix those issues moving forward to the rest of the semester.  We discussed it a little during our retrospective and will talk about it more when we plan our next sprint. We will keep the lessons that we learned both good and bad while moving forward and accomplishing as much as we can for the end of the semester.

As a positive, we realized a good formula for our team in regards to breaking up the larger tasks into smaller more manageable individualistic tasks for team members to accomplish.  I feel that we have developed a good level of communication throughout our team. In my opinion, I believe that it took us a little longer than we all would have liked to get to this level of comfort and ease of sharing ideas that we may be a little nervous of that is not one hundred percent correct and the best solution.  We have developed a more open communication and I have noticed that we are starting to share more ideas and that will help us for the next couple of sprints to effectively produce a product that can help the Ampath project improve.

One obstacle that we need to realize that we need to get over is that while we may have to write a basic encryption service we will also have to develop more communication will all of the other teams and work together to write the code that will go into each of their services that the other teams are developing.  If we don’t do this then all of the teams run the risk of the services not syncing up on the encryption level or the teams trying to use different encryption libraries because we did not proactively work with the rest of the class to prevent that issue from occurring.

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

Sprint 3 Retrospective

I feel that this sprint was good from the aspect that during the planning phase we seemed to come together more, and everyone added more input into tasks to break the items on the product backlog into and which ones we felt that we could accomplish during this sprint.  I feel that we are starting to hit our stride and be more comfortable as a team voicing opinions and ideas to each other.  Even though we are approaching the halfway mark in the semester without making too many contributions to the project.  From this last sprint into this upcoming sprint, each member of the team is making a bare-bones application with each one using a different encryption method.  When we meet again we will all have a better understanding of how encryption is applied in Angular and we can effectively suggest an encryption method to the Ampath team.   After that, I feel like we will have better direction and a better sense of purpose as a team since we will be working on services that can be applied to the project and feel more like we are contributing.

While our communication improved during the work classes we still have a lot of work to do communicating outside of class.  Some of our work classes were canceled due to snow and I believe that negatively impacted our team more than it should have.  Someone mentioned during the sprint review that the sprint would have gone better if we had been able to have more work classes.  While I don’t disagree with that statement it did make me think; did we utilize our time and communication ability between classes as much as possible?  I cannot honestly say that we did or feel like we accomplished all that we could in the time allotted.

I was assigned to create an application using crypto-js.  My first step was to do research, this included three different areas to focus on.  The first was encryption in general to get more familiarity with it, the second was how encryption was implemented in Angular, and the third part was to research crypto-js and how it was specifically implemented.  I found several examples of how to insert the encryption code into a program as well as one to create an Angular app to encrypt a file.  I lost the link to the site and am on the hunt to find it again, I was lucky enough to have downloaded the sample code already.

I hope that after spring break we can accomplish more as a team during our sprints and feel that we will after hitting these setbacks and discussing our team shortcomings at the sprint retrospectives we will keep improving every time.  After this upcoming sprint, we will be able to choose an encryption method with reasons why to back it up when we present it to Ampath.  Then I truly believe that we will have a renewed sense of purpose that will give the team the drive we need to meet our project goals by the end of the semester.

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

Practice, Practice, Practice

No one is born with the skills needed to be an expert in their craft and very rarely are skilled immediately after learning how to do something new.  As the new member of the team you may not notice it, but it took your other team members years of practice to get to where they are and you can get there too.  Taking risks and making mistakes are important parts of learning new skills and honing your craft. Most work environments provide very little opportunity for young developers, or apprentices in most fields, to make these mistakes or the time to work through them on their own.  It’s important to put aside time to work on a personal project or two in order to work on new skills or just get more comfortable with the skills that you already have.

 

When I worked for Geek Squad I would often be at the counter talking to customers and would have to try and identify what the issue with the computer was and either perform a quick fix or document the specific issue for intake and extended repair.  While we had the opportunity to make some temporary mistakes or try a fix that does nothing, we did not have that luxury at the front counter when working directly with customers that expected us to know exactly what command to run, or the location of every setting for every system and operating system.  What I chose to do was to buy a cheap laptop, take it home and essentially find various ways to break it. In this low stress environment, I was able to get more knowledgeable with different systems and common problems.

 

This is a tool that I intend to use as often as possible when starting a new career.  While I have had practice and learning while completing assignments for the past four years; real world projects and capacity of assignments will vary greatly from what I have done so far.  My plan is to clone my workspace at home to an extent. This will allow me to create a sandbox to try new solutions without breaking programs or causing more work for my other team members. I believe that this is a double edged sword though and you need to be careful with how much additional work you take on without finding a hobby and personal life to balance it with.  I find the breaks beneficial because they allow me to think about something else and that’s when solutions often become clear; getting too consumed with solving a problem that you are practicing on you no longer see the forest through the trees and risk burning out.

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