This feed will contain blogs for my aforementioned Software Dev Capstone course, as it did for the courses I have taken previously. I’m excited to share my experiences in class as well as reflections on the reading materials this spring semester.
From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.
Hey guys, here’s to another (and my last) semester of this CS series of blog posts!
Hopefully you will HIIT–or should I say reach–all of your professional and personal goals for this year. There’s so many things to always keep improving on but it’s always easier when you break things down to smaller changes or achievements.
Here’s a picture of one of my personal goals as can be seen in my university’s Wellness Center:
One day I will be able to get up there without being lifted…alright I’ve gotta get back to practicing my jumps.
Best of Luck,
Sami
From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.
Sprint 6 was the final sprint of the semester. We rounded up this sprint with an unfinished solution to issue APTS-254. Over the course of this sprint, we were feeling really good on our understanding of this issue. We required quite a bit of clarification from the Ampath team. After getting some really good clarification we found that the code we needed to work on was in an entire different directory from the one we had been previously working in. Once we finally found where we should be working, we began digging in deep into the issue. The first thing we noticed is that this issue was associated with their ETL server implementation. None of us on the team had previous understanding of what an ETL server was so we I did some digging. I found a few resources online (Here’s a good brief description) that I summarized for the group. The idea was fairly simple, except the way the Ampath team was using ETL was basically by skipping the Load portion and just passing the transformed data to the end user as a notification.
I had a really good understanding of the issue at this point and even began writing some code that I thought might work for this specific issue. Part of the major issue that stopped us from being able to test this solution was the fact that we were unable to test that our solutions actually worked before committing changes. In order to test our solutions we were going to need a running ETL server. In the end I was kind of bummed we weren’t able to resolve another issue before semester’s end. But I felt good in the things I learned from trying to resolve this issue.
I would love to continue working on these issues in the future but with all my personal projects and the fact that I will be starting a new job (as a Software Developer) on the 22nd, I don’t plan on having a lot of extra time. All in all I really enjoyed working on Angular 2 and seeing how a large scale project like Ampath was built.
From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.
This previous sprint was quite a successful sprint. We successfully had our code accepted into the Ampath project this previous sprint! It took us a while to get the understanding we required for the issue, but once we fully understood the issue it only took the team about a day to come up with a valid working solution. Once we as a team had decided to create a pull request, I went ahead and initiated this task. The biggest speed bump we hit for sure this sprint was getting the fix officially accepted and pulled into the project. The Ampath team had a specific set of guidelines they would have liked us to follow, we were not aware of these guidelines to begin with however. The first thing we needed to do was officially have the Ampath QA team checkout our fix and run it against their test systems. Then once that occurred once more developer was required to test the fix and check the quality of the code being applied to the fix. Once this was done our fix was accepted.
The second phase of Sprint was information gathering for the next issue we are working on. Towards the end of the sprint we received clarification on the issue and we have found that this may be a trickier issue then we initially thought. We are excited to get working on this issue this sprint, because we would like to see at least one more accepted change from out team before the semester’s end.
From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.
Cahpter 5 resembled Chapter 2 from Robert C. Martin’s book The Clean Coder which has many of the same themes as this book. This chapter mostly covers the fact that as a professional you occasionally need to say no. If you don’t say no when you should say no, things can get ugly quick. I won’t talk too much on the reasons why here because I talked about it in more detail here.
I do want to talk briefly about one thing that was said in this chapter. With good managers, there should never be a “us and them” attitude. This could never be more true and I recently experienced the downside to an “us and them” attitude. I was on a job with the the VP of Stack Testing in Bridgeport, CT. We were working as contractors for a fairly large power generation company, we’ll call them “Big Guys”. So Big Guys have so many power plants that instead of contracting companies like us to do their stack testing, they have an entire team of internal stack testers. However, an issue came up where Bug Guys’ stack testing team didn’t have some special analyzers that my company has. This equipment is very expensive and very complicated to use. So we arrived on site and immediately the upper management of Big Guys made us feel threatened. The upper management made multiple comments about how if we screwed up even the slightest bit that they were going to throw us off site and hire a different contractor. That was the first sign this was going to be a rough few days. Anyways, we ended up meeting Big Guys stack testing team, we’ll call them “Little guys”. All of the stack testers from Little guys were incredibly nice and welcoming to us. They were excited to have us on site and really excited to see our equipment in action.
After a 16 hour day of testing along side Little guys, we started seeing some trends. Big Guys management kept referring to the testing that was happening as “Your tests”(Directed towards Little Guys), like somehow Little Guys are requiring them to test when the reality it that the State of Connecticut was the one requiring THEM (Notice the beggining of the Us and Them mentality). Then we noticed that Big Guys were not giving Little guys any information until the very last second. Each time they did this the sent Little guys into a frenzy getting ready for the next test. Same things like this kept happening throughout the day.
We arrive on site the next day to find out that after the previous day, Little guys were upset and disgruntled about the previous days happenings. They began venting to myself and my boss. The “Us and them” mentality become so apparent when they started go against what Big guys were telling them to do. Towards the end of the second day, Big guys told little guys on their last hour of tests to pause their tests. Big guys eventually told us why they paused the test and the reason was completely strange. They had us pause for reason that were 100% unrelated to what we were doing at that moment. Little guys made a unilateral decision to continue testing so they could leave before 7 pm. Obviously Big guys were furious when they found out and there was a yelling match (Thankfully neither my boss nor I were present for) between Big guys and Little guys. The moral of the story is if they had not had this us vs. them mentality I am almost positive the days would have been smoother and we there definitely would have been less contention.
Chapter 6 talks about Craftsmen as gardeners. I really appreciate this visual. There certainly is a difference between someone who plants and someone who gardens. Someone who plants prepares their base, digs their holes and plants their plants and then moves on. If you do this as a gardener then you will quickly find your plants getting choked out by weeds or overgrowing other plants. This is not okay. One of the most interesting points made was the mindset of developers thinking the didn’t have enough time. I never realized it, but I have done this. Multiple times. Working on small projects I could have saved my self countless hours if I had simply taken the time to create unit tests. I see that now. I know that now. But I still don’t always do it. Why? “CAUSE I THERE’S NO TIME FOR THAT!!”. Really? Really, Tyler? Don’t you remember last time you said that? You spent hours debugging a simple logical error that could have been found in seconds using unit tests. ….Yeah, I still skipped unit testing to push features “faster”. This is something I am trying to break for sure and this chapter was a good reminder that it’s a time saver for everyone if I simply write unit tests and take the time.
Guess what, Tyler. There. Is. Time. Write Unit Tests!
I have the written on a sticky note on my monitor at home.
From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.
This sprint reflection will be a brief one. Unfortunately for the majority of this previous sprint (8 or 9 days) I was sick. I was so sick I couldn’t really move off the bed. So unfortunately I missed out on almost the entire sprint. My team was very flexible with me being down and they were able to work around that.
Once I started feeling better I began playing some catch up with the group, communication to me teammates to see what I’ve missed and figure out where they were at. We are working on an issue in the Ampath system (NGPOC-185). Initially when we took the issue we assumed we knew what the issue was talking about. However, after I started feeling better I started testing some things out in the Ampath POC system. What I found was our initial thoughts on the issue were completely wrong! This was extremely unfortunate because the team had put in a lot of time to find a good fix to what we thought the problem was. The lesson learned here for sure was; if there is ANY doubt in your understanding of an issue, get clarification!
We concluded our sprint with a retrospective. The main thing we discussed was our failure in this area, and how to avoid this in the past. We also discussed how we were going to make up for lost time. So moving forward we’ve decided that we are going to work in pairs. The issues seem to be easy enough that 6 people to 1 issue is overkill. This should allow our team to move forward and begin progressing and be able to increase the velocity of our scrum group.
From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.
Chapter 3 of The Software Craftsman is spent defining what is a Software Craftsman. The earlier parts of the chapter are spent on talking about the history of Software Craftsmanship, that is all very interesting but I’d like to discuss the Software Craftsmanship manifesto.
Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions but, also a community of professionals
Not only customer collaboration, but also productive partnerships
So, lets take a look at this line-by-line. The first line states “Not only working software, but also well-crafted software”. I think we can all agree as some form of software developer this is the best thing to strive for. The question then becomes, how do we get here? Sandro makes a statement that is truly interesting. After describing what any good developer would know to be truly well-crafted software, Sandro states “In order to evolve applications, developers must not shy away from changing them.”. This statement is so intriguing to me because it simply makes sense. You can’t have evolution without change, and you want your software to evolve to “well-crafted”, right? Well in order to do that, you’re going to have to make changes to the code, sometimes that may be big. Other times it may be small.
The next line says we should be steadily adding value to the project. This is again something that no one can refute as a good thing. However, I think as developers, we many times find it hard to “Leave it cleaner than we found it”. As you are reading this I can almost guarantee that you are thinking back to a time where you made a bug fix, but that bug fix made things just a little bit messy. I am sure whatever reason you had for putting in that bug fix messy like that was valid. However, this starts becoming an issue when everybody working on the project adds some messy code here and there. Eventually the system becomes maintainable and it’s an unfortunate side-effect to us being humans. However, as software craftsmen we need to strive to not get caught in this net and constantly clean up the code.
The next line says we need to be a community of professionals. I really like this piece. I’ve worked with people on both ends of the spectrum (not in the software field). On one end there are people out there who will give you the bare-bones, need-to-know information to get the job done. I am unsure as to why anybody would want to do this. Flip the coin and I’ve worked with people who are delighted to share their knowledge and understanding of the given subject matter. I think mentor-ship is incredibly important. If no one ever mentored a young developer and didn’t pass down the knowledge that’s been attained over their long career, then the young developer is going to fall into all the same pitfalls that has plagued software development for years.
This final line in the manifesto, is essentially stating: In order to succeed you will need to act as a professional. It also talks about the flip side of your manager needing to act as a professional and expect you to act as a professional. We should want to strive to produce the best possible products we can and in doing just that, I think a lot of the time the customers or the employers are more willing to work with you through issues. They are able to see past you as their employee or contractor and begin to see that developing software is a partnership. In order to create good software there needs to be professionalism on both sides of the coin.
Chapter 4 talked about attitude of the software craftsmen. More so the chapter discussed our attitude towards pursuit of knowledge. The pursuit of knowledge should be a personal burden and not a burden you try and place of your employer. It is your sole responsibility to continuously improve skills and knowledge as a craftsman.
Many of the ways to improve this were discussed in an earlier blog covering “The Clean Coder” book. I won’t re-hash something I’ve already discussed. But as a brief summary, some good ways to extend your knowledge is through books, blogs, podcasts, training events, seminars, meetups and coding challenges.
From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.
I’ve really enjoyed reading The Clean Coder I think Uncle Bob has made some very clear and important points. This week was quite short and so there is only so much to write for this post. This books is great for a student hasn’t begun working or an engineer who’s at his first job fresh out of college. However, for anyone who has worked in the “real-world”, we already know the things that are stated in chapters 11 & 12.
One of the more interesting topics that I never really had a name for was Crisis Discipline. This is something in my current field that is incredibly important. I work as an Air Quality Engineer. Part of my job is to execute wet sample extractions for pollutant sources per federally regulated methods. In these methods everything I need to do in order to get proper extraction of whatever pollutant I am looking for is written in stone. However, during the actually sample gathering there are ways you can “speed up” the process or “cut corners” to make the job easier. However, EVERY single time someone decides to do this (No one has in my company), it backfires and them. It usually lands them rerunning an entire testing program that may costs tens-of-thousands of dollars.
The next chapter interestingly talks about collaboration. This is something again, that as working person in a technical field, I have found that a second pair of eyes is ALWAYS better. I spent a lot of my earlier years building and fabricating anything from specialized flanges to electrical control boxes. When you spend time designing something and working on something, no matter how good you are, you will screw up. Period. End of discussion. I remember training a young technician on how to rewire a simple relay system that controls a heater block. When the technician had completed the task they simply put it back on the shelf.. Job done, right? This technician in particular had an issue with me always checking his work and I knew that I would do it forever and a day because we are human and humans are fallible. However, from his point of view, he thought I was always passively aggressively saying he wasn’t smart enough. So I decided to go out and check the heater anyways. I found that two of the wires were backwards, and that was going to cause the relay to stay closed 100% of the time which meant power was going to be continually supplied to the heater. The next morning I got in my normal time which was well before the rest of the technicians and I plugged the heater that he had worked on in. Long story short, when he had made it in to work he saw a BRIGHT cherry red heating element just about ready to melt through the metal casing. When he asked me what had happened I explained to him that is why I always check his work and why I always have other engineers check my work.
From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.
Another sprint down! This sprint was much more exciting then previous sprints. This sprint we were finally able to get OpenMRS and Ampath running locally on our machines so we could fiddle with it! I have a tendency to probe things I don’t understand until I either 1, understand them or 2 break them. Luckily this time was the former over the latter. Part of our previous sprint was to re-write an Ampath module, specifically the authentication. This was to help us learn how the REST API works and to generally learn how Angular works. We broke our sprint down into a few steps.
These four basic steps were what we felt as a scrum team, each individual could finish in the time we had for the given sprint. Unfortunately for me, because I enjoying coding and learning new things so much, I finished this by day 3 of our approximately 8 day sprint cycle. This left me with nothing to do, but plenty of time on my hands. I took that time to start researching TDD inside of Angular and how to write Karma tests. I really like the Karma framework and the way you simply declare what a test should be doing. I feel that it makes your testing output extremely easy to read, which is especially nice when you are showing it off to your wife who is by no means a software developer. But in the case of the real world, it gives someone A LOT of insight into what your code is supposed to do by them simply running test.
Tomorrow we start Sprint 3. From my understanding we are going to become familiar with JIRA and Ampaths issue tracking, so we can start (hopefully) resolving some issues for them! I am very exciting to be finally diving deep into this project and I hope to make some significant changes!
From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.
The Management. Such an interesting topic for a book dedicated to becoming a professional. What Uncle Bob is talking about here is two distinct forms of management; personal management and business management. Interestingly enough, these two topics become intertwined quite often. The first instance in which this appears in the book is when he talks about meetings. When the section starts on meetings Uncle Bob stated something I’ve been saying for years now.
There are two truths about meeting.
1. Meetings are necessary.
2. Meetings are huge time wasters.
My current position requires me to attend an occasional meeting, typically conference call style. The one thing I have found is that these meetings are very important to keep people up to date on whatever the contents of the meeting are and it helps get every one on the same page. However, every meeting I have been apart of was by no means short. I believe the shortest meeting I was ever apart of still lasted 45 minutes and by the end I walked out with no more knowledge then I had gone in with. Having had these experiences, when I saw Uncle Bob’s statement about the two truths of meetings I felt relieved that I wasn’t the only one that felt this way. Uncle Bob went on to talk about the different meetings that are had in a Scrum methodology of software development. Reading his thoughts on how these scrum meetings should go is very interesting. Currently with the Capstone class at WSU we are using Scrum and I can see how some of these meetings could go very long. I believe my team and I have done a good job and avoiding wasted time during these meetings, though.
The rest of chapter 9 covers ways to stay focused. Fortunately for me, most of these methodologies or theories appear to be common sense to me and I didn’t take away that much new information from these paragraphs.
Chapter 10 talks about estimates. Interestingly enough, I’ve had to create a few estimates in my line of work. Granted these were extremely small scale and usually completed in under an hour. The thing I learned from creating those estimates was, it’s incredibly hard to estimate time for when things go wrong.
As I mentioned in a previous blog post I listened to a podcast (You can find it here ) on software estimation a few months back. This chapter from Uncle Bob felt like a refresher on the things talked about in the podcast. What I find most fascinating about this subject, is that in my field an estimate is occasionally taken as “set-in-stone” and “done-deal” type of artifacts. However, that’s what business has turned it into and that was never what estimates were intended to be used for.
I don’t have too much more to say about estimates for software, seeing as I haven’t had to ever create one yet. However, I know when my time comes to finally use this information, I will be referring back to Uncle Bob!
From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.