Author Archives: mattyd99

The Deep End

For this weeks blog post I will be looking at the pattern called “The Deep End”. The context behind this one is that taking small safe steps leaves you unsatisfied and you are beginning to fear that you may be in a rut. Instead of diligence that could attain the next level you are in a rut where bland competence eventually will decay into mediocrity. The problem with this is that you need to grow your skills, confidence and portfolio of successful work. Challenging yourself with bigger things like bigger projects, larger teams and more difficult and complex tasks, new workplaces and more. This will again help you grow as a developer instead of settling for a rut. The solution to this is to jump in at the deep end, taking it head on almost. Waiting until you are “ready” can turn into a disaster or a pattern of never doing anything. When offered a higher profile role or a more difficult problem grab onto it with both hands take it head on. Personal growth will only occur if you are doing something out of your comfort zone and doing things that stretch your boundaries. This of course will have its risks without a doubt. If you get it wrong and way in over your head you could drown. But thankfully in the business there are many places where you can take risks without destroying your career if you were to fail. These risks are opportunities that will help you grow. It means taking a foreign assignment when its offered, even if the possibility of failure is staring in your face. Acting on this will be extremely beneficial to you when in a rut. Thinking of the biggest projects you have worked on and then writing down the answers to these questions pertaining to the difficulty of other projects is a good way to start. Using metrics to measure every project, in a sense, of your own projects. I find this pattern to be very on par with the be the worst mentality. In a sense you are putting yourself in an environment that may or may not cause you to fail miserably but if you succeed you will grow immensely.

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

Breakable Toys

For this weeks blog post I will be looking into the Breakable Toy pattern. The context behind this pattern is that experience is built upon failure as much as if not more than success. This is something that most people will agree with that you cannot better yourself without failure or knowing your shortcomings. Say for example you are working in an environment that really does not permit failure yet failure is important to learn from your mistakes. This could cause you to play everything safe without being bold causing you to never truly get the most out of your job. By being bold, failing due to new tricks or the boldness can you grow into a better version of yourself when faced with difficult problems. In a way this pattern is very similar to Be the Worst, but that pattern is about finding a team where you can be the worst in order to grow. Breakable Toys is about creating opportunities to learn by going out of your comfort zone and single handedly building complete software projects. Using your favorite tools to build the worlds simplest wiki while still maintaining the highest standards of quality is an example that fits this situation well. The initial version will not be fancy in anyway but a simple user interface that lets you view and edit the plain text files. As the project moves along you can add more features and find new interesting ways to distinguish the project from the other pre existing thousands. Let your professional- interests guide you not the constrains of existing implementations. It does no0t matter what you decide to do in this project but as long as you are experimenting and learning from it you are growing as an individual. Back to the be your worst blog I wrote a few weeks back I completely agree with the breakable toy ideology. This is a very good mentality to have especially for your own growth one I would see myself using yet again.

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

Out of the Trenches

For this weeks blog post I will be looking into the pattern where are you told to “Stay in the Trenches”. Here you are advised to stay in the trenches even if you are offered release off the front lines into a much safer area. What does this mean in a modern day environment well you are on the “front line” to say of a programming job where you in a “grunt” position where basic programming duties fall upon you. One day you are offered a promotion where you will no longer be programming or doing to say the “dirty work” but in a more comfortable position. As it says in the pattern that most people always assume a promotion into management is associated with success. Thinking that if anyone is offered a position like that it’s a no brainier to take, meaning you are doing good.  The reason going into a management position where you are out of the trenches is that your mastery fades due to you not practicing it anymore. To counter this maybe working with your employer to find other rewards for your good work whether that be more pay or other nontraditional technical leadership roles. If your employer is inflexible then it is perhaps better to seek opportunities elsewhere. This pattern is very interesting to me as it makes a lot of sense to stay in the trenches for experience rather than dwindle. It also falls upon the person to decide whether or not they want to stay on the front line or go up the ladder into a management position.  Someone may feel more comfortable or even get more out of a management position instead of being a front line programmer. But again, that is all up to the individual and isn’t really predetermined in my mind. It all depends on what you want to do with your career and so forth so its hard to tell if I could see myself applying this method to a real life situation.

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

Sprint 2 Retrospective

For this past sprint we didn’t really accomplish all the much since we had no work provided to us. One of the biggest accomplishments was getting the ngl serve and ampath login working for myself. Kyle was running into the same issue I was having and the problem was easily fixed thanks to him. All I had to was go down a version or two to npm version 8.12 somehow that worked while other fixes did not. After this we reviewed some angular and had a week of review essentially. Then yesterday we were given new tasks to complete from the project lead himself. Now we have a direction of what to do for this sprint given to us through several YouTube videos made by the project lead. Each video contains specific details on what we must accomplish/what is needed to essentially full the order. So in summary not much actually happened since the last sprint due to not having any new work given. Looking forward to working on this project in the coming weeks with my team where we will hopefully tackle each problem/objective well as we did for the initial problems.

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

A Big Fish in a Small Pond

The pattern I chose for this week’s blog post is falls along of “Be the worst”. Now it doesn’t quite literally mean become the worst at what you are doing specially in the software field but rather surround yourself with better or stronger developers. From this you can be the worst or weakest member of the group and only have room to grow. If you settle for being mediocre or unaware of others strengths you will not learn or grow. The example they use is becoming a big fish in a small pond, it is critical for the big fish to be aware of other ponds within the vast global network of said ponds and realize that there are even bigger fish than that of your little pond. Going back to surrounding yourself with a team of better individuals you will then only grow due to you not wanting to be the bottom or smaller fish. From this you will work harder than you would normally if you settled for a buck average understanding. You will learn new ways to tackle obstacles in front of you almost mimicking the stronger developers’ habits until you reach their level. The others will also help you in the long run, preventing you from making mistakes how to recover and more. Some downsides of this is of course there is a risk you could drag the team down and a good team will not appreciate a free boater. Another downside is that you could end up feeling bad about yourself and your own skill levels as you being the worst in the group. This is after a sink or swim strategy so sinking will of course feel like drowning. In short being the worst pattern will allow you to increase your learning and growth levels to rival that of the stronger members of your team. I find this pattern to be very interesting because not often do you hear “go be the worst in the group” or something along the lines due to the potential of you perhaps causing a big problem for it. But it makes sense for those who want to learn and become better than their previous self’s and also see where they stand in the field compared to others. I can myself honestly trying this in the future if need be. In all honestly there have been groups I’ve been in where I could be considered the worst, whether that be in software or any group/based activity or environment. In these situations you can feel yourself wanting to be better and not be dead weight and after it I feel like I learned more on the subject, grew in it and overall bettered myself. Wherever I end up in the future and I find myself as a “big fish” in a small pond unaware of the other bigger fish out there I will use this pattern to grow and better myself.

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

Sprint Review #1

For this first sprint we all communicated well when were in person, speaking what was wrong and then some. Everyone is vocal on and offline, except for me who sort of just lurks on slack due to my own procrastination which I will be fixing for my next sprint. Not much was really done with sprint as it was more of a trial and error-based sprint with trying to get our projects to start. First it was a server issue then it became an issue with the ng2 commands. I am still experiencing issues with my setup of the ng2 while everyone else has completed initial set up. At first, I was having an angular issue which a few people outside my group was having than it was a ncss-sass issue which is yet to be resolved at the time of writing this. My laptop is not the best and is all around a pain to use due to this I plan on getting a new laptop soon if not this week. In the meantime, I will try and resolve my issues on my desktop on home so any progress is not wasted on my old “laptop”. As I said above everyone started the day we were assigned are groups in class trying to get everything situated. From here the error we were all facing involved the etl server not working. After a week of plug and chugging along I believe Gulshan was the first one to complete the initial set up after he was faced with a windows x64 error. From here James and Harry fixed their errors with Kyle being next up. After I wrestled with an angular issue, laptop issue and such I am a step closer to completing the initial ng2 setup. As I am writing this I am trying to reinstall my node.js dependencies for the third time. After some research online for the node-sass error I was receiving there should be a gulp-sass line in the package. Son along with the other json files, in my case there was not. After trying some more commands in the prompt a python dependency error began to prompt. So I redownloaded chocolatey to get python through the PowerShell window but to no avail. Hopefully this will be fixed when my new laptop comes, or a new solution comes up. All in all from this sprint I learned that I need to get better to manage my time much better and not wait until the last minute. So from the future I will strive to be better at communicating and trying my hardest.

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

Why Doctors Hate their Computers

After reading “Why Doctors Hate their Computers” by the New Yorker my opinion on the topic has changed a bit. I’m sure everyone has gone to the doctors before and waited much longer than they were supposed to due to the doctor running late or some other issue. Leading many to believe that Doctors never run on time when you want them to, especially for your appointments. Now I can see why Doctors are late so often or overburden with the amount of data that they are required to enter in for each patient into a system that could be difficult for them to use on their own or are not the best at it. The whole piece was very interesting and enlightening honestly on the matter of new software for Doctors and the process of learning/switching over from a familiar one. One thing I found interesting was the hiring of scribes to start writing/doing most of the computer work for the doctors themselves to help “remedy” the inconvenience of doing so. The results from this were surprising as well with it actually being very effective but not solving the problem for the doctors themselves almost just beating around the bush. The tension between learning the new software and putting in all the information that they had previously been able to. What I mean by this is three nurses may write three different diagnoses for the same person in the system causing a mass confusion for the doctor. Or in other cases the system wouldn’t allow every detail that they wanted to add like they would do in a handwritten fashion. The lesson from the implementation of this system apply to almost any new system implementation throughout any workplace honestly. Speaking from a personal experience, at my Part Time Job at Lowes they introduced a new system called Sterling for the customer service desk. This system was to replace the old system of how internet orders were placed, tracked, and overall managed. Now I do not work customer service, I work over in the lawn and garden section but after hearing from coworkers and such I know how difficult it was for people to make the adjustment to sterling. The system was alien and overwhelming to all workers even those who knew and used it prior to our store. They all learned some tricks around it and finally learned to cope with it fine with occasional hiccups here and there. So a new software implementation issue isn’t just unique to medical care systems / work spaces. The real customers of the systems are those that have to use the system on a day to day basis, trying to get the most out of their own system even it means wrestling with it. Overall this article was very enjoyable to read while also shedding light onto new topics I had previously been unaware of.

 

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

Apprenticeship Patterns Chapters 1-6

First of all from just the introduction chapter I like how everything is written, making it feel nice and easy to read without being overburdened by new things to newcomers but takes it slow. The beginning part where they provided an example of someone who decided it would be best if they were to reveal their ignorance on their programming language knowledge to their mentors was an interesting and relatable topic. This is something I agree with a lot, its harmful to not say anything in the face of your pride alone when you could speak up and face it head on.  Throughout the reading it seems to stress the ignorance of your own that could hinder your development. It also stresses the importance of finding a friend or someone you know who is knowledgeable in programming to help you. The reason for this is that if someone close to you gives you assistance the return rate of said assistance would be faster than that of someone who is not close to you, allowing maximum growth. I also like how the reading stresses craft over art or rather how programming is a craft rather than a fine art. The example they use is a perfect one, where a solution is already been proven and is readily available, but the customers problem offers you to do something unique or “fantastic” as they say. Essentially creating something new rather than going down the tested and true path. Honestly chapter three and four were pretty insightful into a mindset that is needed in the programming field, at least one where you become a better version of yourself. The idea of perpetual learning is something I agree with completely, the example they give right at the beginning of chapter five is a good one. Essentially becoming narrow-minded or solely focused on “low-level” details of what you only work on a day to day basis can be harmful for your growth. But by stepping out of these bounds and trying to “perpetually learn” things is something you should do as it can only be beneficial and not harmful to your growth. They give some examples on how to start this but of course the easiest way is to simply go online and look at the hundreds of readily available sites whether they be academic based sites, podcasts, YouTube videos or a blog from some high end developer and more. Chapter six was almost a reaffirmation of some of the ideas talked about in five with you constructing your own curriculum, something that goes hand and hand to perpetual learning. Again this is something I agree with a lot as having your own set curriculum whether it be reading a book related to your field, watching videos/podcasts or doing research and more these are all important to improve one’s self. All and all I thought this reading was pretty good and straight forward, a good almost pep talk to those who may not know what to do or how to improve your self in the field.

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

Introduction Post for Capstone (CS-448)

Hello,

My name is Matthew DePalo and this is my first blog post for my Capstone class this year!

 

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

You don’t no smoke

For this weeks blog post I will be looking at smoke testing.

A smoke test is used to describe a suite of basic tests that verify that the major features of an application are working properly. A most common se of this is simply to determine whether a build is stable and ready for further testing or a final check before you submit something.  The result of this testing is used to decide if what you built is stable enough to proceed with even further testing. The terminology behind the name comes from a similar type of hardware testing in which the device passed the test if it did not catch fire the first time it was turned on. The testing covers most of the major functions of the software but none of them in extreme depth. The result simply is whether or not you must go deeper or not. If it fails you stop further tests and try to fix what you already have. This testing helps expose integration and other major problems early in development cycles. It can be conducted on both newly created software and enhanced software. A smoke test is almost always performed manually with some help of automation tools or scripts but if the builds are prepared frequently automated smoke testing is the best to use. After an application becomes more developed and mature in a sense with more functionality the smoke test will need to be made more expansive. Sometimes even just one incorrect character in the code could render an entire application useless. The advantages of this smoke testing expose integration issues and helps you uncover the issues early.

 

http://softwaretestingfundamentals.com/smoke-testing/

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