Author Archives: Matthew Foley

Sprint 6 Retrospective

Well here we are – the end of the last full sprint for the spring 2018 semester. Honestly, it is a bit surreal. Everyone in this class has been working towards the goal of an undergraduate degree for the vast majority of their lives and now we are all just weeks away from achieving this goal. It is awesome to see everyone in the class continuing to work hard on this project with Ampath. It would be very easy for us to check out at this point in the semester.

I understand that this retrospective blog is supposed to focus on the current sprint, but seeing how this is the last opportunity I am going to have to write this blog for this class, I’d like to take a moment to reflect on what “The Perfect Name” was able to accomplish this semester. So, please bear with me…

I couldn’t be prouder of what our team was able to accomplish this semester. Our knowledge about the Ampath project, Angular, Typescript, Agile software development, etc. has grown tremendously. We have all come a long way when compared to the beginning of the semester. The learning curve for this project was quite steep and even with that we were still able to produce a demonstrable feature by the end of the semester. Although we may not have accomplished everything we set out to do at the start, we still made great strides towards the ultimate goal and have put whoever takes over the feature in a good spot to complete it. Now, onto a retrospective more focused on this sprint…

As usual, the team work very well together this sprint. No one is afraid to ask question at this point and everyone tries to help out anywhere and everywhere they can. If I’m being honest I would say last sprint was probably a bit more productive than this sprint, but I’d say this was our second most productive sprint of the semester. This sprint we had to take a step back and look at where we stood compared with the goal we had set at the beginning of the semester. During planning we all agreed we weren’t going to totally reach our goal; we did not implement the encryption service and we weren’t able to add the ability to store multiple users. We agreed everything else we had set out to do at the start of the semester would be done by the end of the semester. Because we agreed we weren’t going accomplish everything, we set out this sprint to leave whoever takes over for us in the best position possible. To do this we had two main goals: completely finish any outstanding tasks – we felt it was better to make sure we finished the work we had already started the right way rather than rushing through it to try and make an attempt at the encryption service and/or multiple user storage (it wasn’t realistic to finish either given the time constants), and to thoroughly document what we were able to accomplish so whoever takes over wouldn’t have to waste their time figuring out what was done.

I am happy to report that we were able to accomplish most of the goals I mentioned above this sprint. We created a document explaining what was done, where the code was changed, etc. This document can be found on our team page of the CS448 Slack channel. Hopefully it will be useful to whoever takes over. We are still working on the backend for the offline credential storage checkbox, but we are confident it will be done by the end of the semester. Once the backend is done, all that we will be leaving outstanding is encrypting the password (which will hopefully be simple with the help of the encryption team’s work) and storing multiple users. It was really nice to see ideas actually play out, even if it wasn’t as quite as feature rich as we had originally hopped for. The documentation and backend were the two main goals this sprint, but obviously there were several other smaller things accomplished as well (some research, tests, minor bug fixes, etc).

Lastly, I’d like to thank everyone involved with this project for a great semester. I couldn’t have asked for a better group of people to work with. I know I made some new friends along the way. I hope that was the case for others as well!

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Sprint 5 Retrospective

As we enter the home stretch, the team has continued to make good progress on the project. It’s weird to think we only have four weeks or so left in the semester. It has flown by! The team continues to work well together and communication is never an issue. In fact, I’d say it is even one of our strengths. Even on days we don’t have class and we are at work and/or busy doing other things, team members are quick to respond to each other’s questions, put pull requests through, etc. Good communication is always vitally important to the success of a project, so it is great to see us excelling at this. I don’t have any pressing complaints or need-to-work-ons at this point. I think a lot of that stuff was hashed out earlier in the semester and if an issue comes up now, we are quick to address it mid-sprint rather than putting it off.

For sprint five, the team set out to further improve the rudimentary version of the offline login service that we created last sprint. We were able to make some progress towards this, although it still isn’t quite all the way there (it wasn’t expected to be all the way there this sprint). The other main goal of this sprint was to get Ampath’s approval for our plan to implement the offline login service. To do this, we reviewed and updated the high level designs I had created earlier as a team. I thought this was a very good exercise as it allowed for us to make sure that everyone is on the same page. We were able to present these designs to Ampath to ensure that we were going about this the correct way. They approved of the design without asking for any changes to be made to it, so we can press on with the implementation of the design with full confidence now. It was nice that we were able to get this approved because now we don’t have that lingering concern in the back of heads that we might have to scrap everything we had done.

Although those were the two main goals this sprint, we also got a bunch of other stuff done. We were able to make progress towards updating the GUI to give the user the option of storing the credentials offline rather than just doing it automatically. This is an important feature to have because we don’t want to be storing credentials for every single user that logins into the app. This is not only inefficient but, could also cause security problems. All of us were also able to do some research on subscription processing. This was done because another team is planning to use this.  George was able to fix the OnlineTrackerComponent bug and make a pull request to Ampath to fix this issue. Kudos to him for taking this on. It was a bug found mid sprint, so it could have waited until next sprint as we had already committed to a bunch of work, but he took it on anyhow. We were also able to document out new Git approach after there was a bit of hiccup this sprint (luckily, we were able to get it fixed). Several other minor tasks in addition to what I’ve mentioned were completed as well.

Next sprint is our last full sprint for the semester. I believe the plan is to continue to work on implementing the offline login service, however I think documentation of what we have done and what still needs to be done should also be a focus. This way both the Ampath folks and, should a team in next year’s capstone pick off where we left off, will be able to tell what progress/changes were made. It should make their lives’ significantly easier and prevent them from having to start from scratch.

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – The Deep End

The Deep End pattern in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discusses an important hurdle any good software developer will find themselves in at least once in their career. Complacency is a dangerous thing and can often cause a person to get stuck in a rut[AP]. People who want to move up in the world have to be willing to take risks and bigger leaps than they would normally feel comfortable doing[AP]. That is what this pattern is all about; taking the risky jump.

If you are comfortable where you are and don’t see a need to move up or change what you do, then making small incremental changes is perfectly fine. However, most people at some point are going to want to really switch things up. The issue is they are often scared because they are not confident that they will be able to succeed with the big change[AP]. If you really want the change you are going to have to be willing to take that risk[AP]. This “big change” could be something like accepting that great promotion you were afraid to take in the past, taking an assignment in a foreign country, or even switching companies[AP].

By taking on roles you are uncomfortable with, you will grow your portfolio, experience, social group, etc. Most of the time the benefits outweigh the drawbacks. However, the pattern notes that you have to be aware of when you are truly getting in over your head[AP]. You have to know when to ask for help or when take a step back and reevaluate[AP]. Don’t feel like you have to do it all on your own simply because you knew the risk you were taking. If you fail, or decide that the change you made is not right for you, it will not ruin you or your career if you take the right approach[AP].

I generally agree with what this pattern has to say. There is certainly risk involved in making a big move, especially if you are comfortable with where you are in your career, but I think it is a risk most developers have to take at some point in order to become a master craftsman. You can’t wait until you are ready to change things up. You’ll never actually end up doing it. There has to be a bit of blind faith. Even if it doesn’t work out, there is such a demand for people in this field you will almost certainly have a soft landing.

 

Link to pattern in book: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch02s07.html

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Sprint 4 Retrospective

This sprint The Perfect Name pressed onward with the implementation of the offline logon service. We are continue make progress towards our goal, although it has been a bit of a grind in my opinion. The group continues to work well as a unit. We always seem to have a good idea of what each of us is working on and there is good communication both inside and outside of the classroom. One thing I think we could do better is to have better communication with the other teams. I feel that we often get so busy working on own stuff we forget to check and makes sure we are all on the same page.

This sprint the main goal was to actually start working on implementing the offline logon service. George took on the brunt of that work along with other team members pitching in along the way. Although it is still a work in progress, you can see that significant strides were made on this. There is now a rough working version of it. Although the main goal of the sprint was to work on the offline logon service, there was a bunch of other tasks that needed to be done that were necessary for us and/or the offline logon service depends on. We were able to put together a high level design (HLD) for the front end of the offline logon service. The goal behind this was to determine how we are going to allow the user to choose whether they want to store their credentials temporarily offline. We felt that it is was best to give the user the option because space is likely a limiting factor. It may not be possible to store every single user’s credentials and even if it is it wouldn’t be very efficient. The HLD for the this can be found on Balsamiq as well as the AMPATH documentation thread of the CS-448 Slack page.

Also on the to do list for this sprint was to familiarize ourselves with PouchDb. The reasoning for this at the start of the sprint was although we really only need to store one item in the database, we still felt it was important to have a good understanding of how the database works because it likely what will be used for the offline data storage. Everyone got a chance to look into this. I know few others and myself had gone through some tutorials on it as well. I was also able to install PouchDb on my local copy of ng2-amrs. Jason’s fix came in handy here. In addition to his steps, I also needed to disable my antivirus. It was causing problems when the install was trying to rename some files. I notified the teams on Slack about this incase they ran into the same problem. During the sprint review today we decided that we might head in a different direction regarding how we will store the credentials, but it was still a good learning experience nonetheless. We also began to work on defining the API for the offline logon service and we discussed HLD for the backend of the offline logon service. This will really come together more as we get a better idea of where we are heading.

A lot was accomplished this sprint. I think it was our most productive sprint to date. We are getting there. It is a slow process, but we are getting closer each and every week.

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Sweep the Floor

The Sweep the Floor pattern in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discusses some of the obstacles a person may face when joining a new team. Joining a new team is challenge for everyone, no matter their skill level or amount of experience [AP]. The team your are joining has to feel you out and you have to feel out the new team to get an idea of where you place is within it [AP]. This can be a daunting task, especially if you have never done it before.

The pattern suggests to try and take on simpler tasks to start such as code review or product support [AP]. The team is more apt to let you take on these tasks not only because their time could probably be better spent elsewhere, but also because the simple tasks inherently have less risk involved [AP]. Chances are it isn’t the end of the world if it isn’t completed in time and if it does have to be completed by a certain time they know that it is easy enough for them to pick up and finish. The other suggestion the pattern has is to take on the “dirty work” [AP]. This could be something like updating documentation (what developer wants to spend time of documentation?) or maintaining a development environment [AP]. Chances are you’ll earn some brownie points for taking on tasks like this as well.

I can personally attest to this. When I first started my internship I did a lot of documentation work. It was one of the few things at the time I felt comfortable doing because I knew it wasn’t the end of the world if it was done incorrectly or not completed on time. This helped me a lot because by writing documentation I got to know the project I was working on well. Gradually I was given more complex and critical tasks. Almost two years later I am comfortable with grabbing just about any task off the board.

One thing you have to be careful of is becoming the teams “gopher” as the book puts in it [AP]. In other words, you don’t want to get stuck doing these tasks all of the time simply because the team knows you can do them and/or assumes you like to do them. You have to be willing to push your boundaries a bit to assure this doesn’t happen [AP].

 

Link to pattern in book: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch04s05.html

 

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Sustainable Motivations

I think most people would say a career in software development is a pretty damn good choice to make. The field is growing at a rapid pace and jobs within the field typically come with high paying salaries and flexible hours. Because of this, it can be easy to find yourself complacent in your current position and lacking the motivation to continue to learn new topics. You may find yourself thinking “I’m making a six-figure salary and I am very comfortable with my current position. Why would I go out of my way to learn new material?” The pattern Sustainable Motivations in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discusses some ideas on how to prevent/get yourself out of this trap. It also discusses how to avoid some other situations that could potentially prevent you from mastering the craft.

The key to becoming a master software developer is to keep yourself motivated [AP]. As I mentioned earlier, sometimes this motivation can dwindle [AP]. The pattern suggests to keep a list of things that you are motivated by to help remind yourself of what is truly important to you [AP]. I think that this is a great idea. It allows you to keep reality in check. Everyone needs that once in a while. If being considered an expert in your field is on that list, then you should do all in your power to prevent yourself from becoming complacent. If it isn’t and you truly feel that your motivations have changed being an expert is no longer a priority than that is ok. Just don’t give yourself that false intention of wanting to be an expert when in the back of your mind you know your motives are in a different place.

The other thing to keep in mind if you find yourself questioning your motivations and/or if you still want to be in the software field is to simply give it some time [AP]. There are going to be bad weeks at work. There are going to be weeks where you are working nights and weekends to meet a deadline that you knew from the beginning wasn’t realistic. There are going to be weeks where you question management’s decisions. I can go on, but you get the point. Not every week at work is going to be all hunky dory. Be mindful not to make a life changing knee-jerk decision that you may regret. Give it some time and your motivation will probably return.

 

Link to pattern in book: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch03s03.html

 

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

Now that we are at the end of Sprint three and about to start Sprint 4 we are really starting to get into the thick of things. I am looking forward to really starting to dig in and try to implement what we have been working on the past sprint.

Sprint three went smoothly for the most part. Everyone has been really good about the standups and I think people are getting a feel for how much information they need to provide. The statuses are brief and informative. I feel we are also starting to get more done in the class time we have together. We are continuing down the right path. Having the snow days on Thursday and Tuesday set us back a little as I feel it is critical to have that face to face communication. The standups do a good job at keeping each other up to date on what each team member is working on; it is just no substitution for face to face communication and collaboration. However, that is not to say we weren’t able to accomplish what we wanted to get done this sprint…

The biggest goal of this sprint was to understand how APATH currently implements the logon process. This was my primary focus this sprint because we believe we should be able to leverage a lot of what they already have in their code to help implement the logon process. At this point I feel I have a better understanding of how their logon process works, but I don’t feel I have a full understanding of it yet. There code is relatively organized, but it is quite overwhelming. The biggest challenge is understanding how each service and module interacts with one another. Unfortunately, the code is lacking comments, further adding to the challenge of trying to understand what is happening. It would be nice if they had some sort of high level design architecture type diagram/documentation. I think it would go a long way in painting a picture of how everything intertwines.

Although I still don’t have a very clear understanding of how all of the code works, I feel myself and the team has a good enough understanding to make an attempt at implementing the offline login process. We were able to put together a high level diagram using Balsamiq on how we want to go about implementing this design. I think the diagram helped in painting a better picture of what we want to do.  We also collaborated with the ‘Field Idiots’ to get and understanding on how they are going to implement the offline database. We are going to need to leverage their work to store the  user credentials, so it is important that we stay on the same page. I am a bit concerned that we may have a dependency on their database being up and running. I am not sure if there is any way to “mock” that. We also briefly talked with ‘Everyone Else’ a regarding the encryption process. All of these teams need to mesh together so we can ensure all of our work will work with one another’s.

Lastly, we also took some time to look into the bridge pattern, as it seems we are heading down the road of that type of design. There is a ton of documentation of this online so it was pretty easy to find the information we needed.

 

 

 

 

 

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.