Post #32 – Ampath Application Development – Sprint 6 Retrospective

At the end of last sprint, we had finally resolved compilation problems that 3 of our 5 team members were experiencing, and we have Jason Knowles to thank for that.  Our team felt a rejuvination of morale at the beginning of this sprint, and we began finally resumed work on implementation of our offline encryption-service.  We split up the labor of implementing the service, among our 5 team members.  I was made responsible of implementing functionality for ‘salting’.  In encryption, a ‘salt’ is piece of random data that is used as an additional input to a hash function.  Within the hash function, the salt is concatenated to the password or passphrase to be hashed, which will help defend the encrypted data from rainbow table attacks.  I spent our first couple meetings researching salt, and was absent for most of the third meeting because I had to attend a lecture.  As I have mentioned in earlier blog posts, our team planned to use the crypto-js encryption library for our offline encryption service – but when I did make it to the third meeting, my team members were having problems importing the crypto-js library into the Ampath application source.  I had not experienced this problem yet because I had been doing all my implementation for the service within an npm runkit that had crypto-js integrated.  This problem, apparently, ruined productivity for that meeting and the majority of it and the following meeting were spent trying to resolve this issue.  Our teammate, Henry, began to have errors within his application toward the end of the sprint, haulting his progress.  We were unable to resolve these issues by the end of the sprint.

During the second half of the sprint, I worked on implementation of the salting functionality.  We discussed approaches with Matt Foley, of one of the other development teams, and we came up with a plan.  Their team is working on an offline login service, and login data is currently the primary focus of our offline encryption.  We decided that the salt for login data encryption would be the user’s username and the timestamp of their computer at the time of their login.  One meeting was spent merging changes from our group repository with my working repository.  Once that was done, I spent the remainder of the sprint writing a mock service for salting functionality.  I did my rough work in an npm runkit with crypto-js integrated, because we were not able to figure out how to import crypto-js into the Ampath application.  This is a major problem as we do not have any more time to research other encryption libraries.  We decided that we will just all write mock implementation for the purposes of our end-of-semester presentation.  The implementation for salting functionality seems pretty simple to me it is just incredibly unfortunate that we can not get the library imported into the application.  Professor Wurst said that we can still work on implementation if we wish, but we will have to reserve only a small amount of time for it as we have to prepare for our presentation.

From the blog CS@Worcester – by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective – The Final Sprint

This last sprint cycle for my team was probably the most productive sprint in terms of producing code but we ran into a lot of issues when it came to dealing with Promise objects. As I have mentioned in my previous blog posts, when making calls to to a pouchDB instance (i.e. db.put(), db.remove(), db.get(), etc…) those calls return what is known as a Promise object. At Mozilla.org I found a good definition of Promise objects. They describe them as “a proxy for a value not necessarily known when the promise is created.”  Hence, using promises allows developers to write asynchronous code fairly easily. The reason I say this is because asynchronous functions may have multiple expected outcomes/return values without knowing the order in which they will be generated. Before promises, asynchronous functions were handled using callbacks which would either deal with any errors the function might generate or execute the function as expected. You can refer to this link for a more in-depth explanation on the benefits of using Promise Objects instead of callbacks for asynchronous code.

Below is a diagram depicting how promises operate:

promises

As you can see above, promise objects may be chained together using .then() which provides the capability to easily write functions with multiple asynchronous actions expected.

Initially, my team and I didn’t have a great grasp on the concept of Promise Objects and were expecting our code to return explicit values. Here’s an example of our addDoc() function in which we expected to get a boolean value to be returned:

Screenshot 2018-05-02 21.22.17

The problem with this is that our function was actually returning  a promise object which that returned true when the necessary conditions were satisfied. After doing some research and working with the team who were writing the offline data capture service we realized our function was actually returning a Promise Object. Furthermore, we figured out that we could expand the functionality of our addDoc() method by utilizing the chaining of promises. With this knowledge, we re-wrote our addDoc() method so that it expected a Promise Object to be returned and could update an existing record if it’s ID was found in the PouchDB instance. Here is what the addDoc() function looked like after making those changes:

Screenshot 2018-05-02 21.25.19

Testing functions that return promise objects also proved to be quite difficult. Here is a screen shot, taken from my gitHub page, depicting the test we wrote for the addDoc() method:

Screenshot 2018-05-02 21.43.24

As you can see, highlighted in red, we initially had our function call inside the expect() part of our test. Then, we changed our test (shown highlighted in green) by moving the expect() inside of the .then() call after the addDoc() function. Subsequently, our test successfully passed and we thought we were on the right track. However, some of our functions had long chains of promises with multiple asynchronous actions expected. Thus, some of our tests were producing output that was hard to explain because we were still expecting our code to execute in a synchronous manner like if-else statements. In other words, anticipating that the result of each .then() call would be returned in a synchronous fashion, which was not the case.

In hindsight, a better method of testing our functions may have been just simply testing whether the correct pouchDB function was getting called the right time. We were trying to test whether the promises returned in our functions were, themselves, returning correct values. It may have been better practice to just log the responses of promise objects called in our code rather than testing the expected return values since asynchronous code may return things in an unforeseen order.

 

 

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

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.

Apprenticeship Pattern: Draw Your Own Map

This week I read the apprenticeship pattern “Draw Your Own Map”, and it is on the the most inspiring patterns that I’ve read so far. This pattern instructs you to do exactly what its title states, and this is big for me because it gives me a sense of control. This pattern asks you to reflect about your current path, your current position and answer the question “is this really where I want to be in the future?”. If this the answer to the previous question is not a yes, and there is no way to alter your current path to fit with the path that you desire, then the author suggests that you leave, even if you are leaving a “great” title or fantastic salary. Of course what is being asked by this pattern is very intimidating and can be very difficult to actually do when the time comes. This is because from the moment we decide to go to school and take on a new career, the path is already laid out for us and society expects us to follow it, that is: get your degree, get a job, stick with that job and try to climb the corporate ladder there. That being said, there is nothing wrong with the climb if you are happy with where you are, the difficulty comes from taking the risk and abandoning what is sure and working for what you want.

I could not agree anymore with this pattern, and having read it it caused me to think about what some of my goals are. Though I enjoy learning about software and will be very happy to enter the field and work as an employee for a few years, one day I would like to start my own company. I’m sure that making the decision to leave a secure source of income behind a taking the financial risk of starting a company will not be an easy one, but that is what this whole pattern is all about. This pattern has changed the way that I think about the software industry and even working as a whole, it’s made me realize that in the end despite all of the technical challenges and setback that we will face in the professional world what matters is doing what you love, and this is a mentality that I will take with me throughout my career.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

A Different Road

Complementing and maybe even contrasting The Long Road pattern described earlier this week, A Different Road is a pattern about when you stop being a craftsman.

After a long time on your Long Road of being a software craftsman you will have to seriously consider your future in the career and the industry. And as you do this, you may realize you no longer wish to continue the life long journey of moving to software mastery. In this case, you move off the long road and take a different road in your life. We all are on our own life long journeys and this can take us in many different directions depending on the circumstances.

Other software craftsman will not hold it against you if you decide to move on to something else. I personally would never judge someone for deciding they needed to change careers or that this particular career is not for them. I would wish them the best.

And this different path can also lead back to the long road. It is not a clear cut thing. Life is flexible and can the path you take through it can wind around in interesting ways. People can leave the road of being software craftsman and later on realize it was a mistake or it suits them better now. And as the book states, and my personal opinion states, other craftsman would welcome them back with open arms. I would think nothing of it if someone left the field for several years to follow another dream or similar, and then coming back when realizing that that was their calling. I can see myself changing careers and fields in pursuit of my calling depending on how each turns out. As I have stated before, what someone desires in life can change even day to day, as can their goals.

The unfortunate reality is that some in the industry will look down on this, or look at it with suspicion. Mostly those in charge of hiring decisions, most unfortunately. But this is a minor hurdle that can be overcome. It should not dissuade anyone from pursuing what they believe is their path in life. This is something I also whole heartedly believe.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

The Long Road

The Long Road is an apprenticeship pattern that is much more focused on the long term than some others. The situation it is designed for is essentially your entire career path. A craftsman is someone who is wholly dedicated to their craft and improving themselves in this. Someone who holds a genuine excitement and skill for the craft. Because of this, the path to becoming a true master craftsman is one that focuses wholly on the craft. So what to do you do when the opportunity presents itself to you to gain a promotion or a new job that gives you a large raise in income or something similar, but takes you away from your craft?

The Long Road posits that the best path to being a true craftsman is taking, well, the long road. There are no shortcuts, no big jumps that can lead to mastery. And moving away from this long road to being a master is something that should be avoided. This goes against conventional wisdom that most people have, to take the biggest opportunity that raises your station in life when it presents itself. But this does not improve yourself as a craftsman.

The way to do this is to slowly, but surely, build yourself up. Use the other patterns and have a genuine desire to learn and improve. It will take a long time and could be arduous, but it is the sure path to mastery. And it has no end, a life long journey of steady improvement. Such a long journey presents itself a wide variety of possibilities, which should be kept in mind as one walks the long road ahead of themselves.

This pattern definitely has the ability to be controversial for some, because it does go against conventional wisdom. When choosing whether to follow it one has to consider what they truly want in the end. I agree that the best way to being a master software craftsman is not veering off the path of being a software craftsman. But do I stick to this path that stringently? Is my ultimate goal in life to become a master? This pattern forces one to look to the future and question what their ultimate goals are, and I’m still wondering. There probably is no straight answer, as desires change throughout ones life, maybe even day to day.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

The Long Road

The Long Road is an apprenticeship pattern that is much more focused on the long term than some others. The situation it is designed for is essentially your entire career path. A craftsman is someone who is wholly dedicated to their craft and improving themselves in this. Someone who holds a genuine excitement and skill for the craft. Because of this, the path to becoming a true master craftsman is one that focuses wholly on the craft. So what to do you do when the opportunity presents itself to you to gain a promotion or a new job that gives you a large raise in income or something similar, but takes you away from your craft?

The Long Road posits that the best path to being a true craftsman is taking, well, the long road. There are no shortcuts, no big jumps that can lead to mastery. And moving away from this long road to being a master is something that should be avoided. This goes against conventional wisdom that most people have, to take the biggest opportunity that raises your station in life when it presents itself. But this does not improve yourself as a craftsman.

The way to do this is to slowly, but surely, build yourself up. Use the other patterns and have a genuine desire to learn and improve. It will take a long time and could be arduous, but it is the sure path to mastery. And it has no end, a life long journey of steady improvement. Such a long journey presents itself a wide variety of possibilities, which should be kept in mind as one walks the long road ahead of themselves.

This pattern definitely has the ability to be controversial for some, because it does go against conventional wisdom. When choosing whether to follow it one has to consider what they truly want in the end. I agree that the best way to being a master software craftsman is not veering off the path of being a software craftsman. But do I stick to this path that stringently? Is my ultimate goal in life to become a master? This pattern forces one to look to the future and question what their ultimate goals are, and I’m still wondering. There probably is no straight answer, as desires change throughout ones life, maybe even day to day.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

Dig Deeper

Problem

You keep running into difficulty maintaining the code you’ve written because it turns out that the tutorials you followed cut corners and simplified complex issues. You find that your superficial knowledge of a thousand tools means you’re always floundering whenever a subtle bug arises or you have to do something that demands deep knowledge. People often accuse you of having a misleading CV because you don’t distinguish between a couple of weeks of extending an existing web service and a deep knowledge of the issues inherent in maintaining an interoperable and highly scalable enterprise system. What’s even worse is that because your knowledge is so superficial, you’re not even aware of how little you know until something or someone puts you to the test.

Solution

The solution the text offers is to “dig deep into tools, technologies, and techniques. To acquire the depths of knowledge to the point that you know why thing are the way they are.” Depth meaning you understand the forces that leads to a design rather than just the details of the design. Areas where you have deep knowledge feed your confidence and allows yourself to apply your value early when on a new team. Having the background knowledge of how things work gives you the ability to fall back onto that to tackle difficult challenges and allows you to explain the inner workings on to tools and systems you are working on. This knowledge will help you in interviews, setting yourself apart from others because you can explain how a system or tools works. Using primary sources is the best way to understand the deeper workings of things, you can follow the trail of information that leads you to the decisions made along the way and why they were chosen.

This pattern is overall good advice for anyone who want’s to be a software craftsman. It’s important to Dig Deep into something you are passionate about. You don’t have to know everything about programming and software design but you should know a good amount about a few important areas. The ability to fall back on that background knowledge keeps you from struggling to understand new concepts, and makes you an asset to any team because you understand what’s going on beneath the surface. With this knowledge you can help others by explaining things in a clear way. Doing research and looking into primary resources allows you to get to the core of the information. It takes time to learn how things work but the benefits are worth it. This pattern will definitely improve my professional career and ability to help other understand deeper concepts.

The post Dig Deeper appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Draw Your Own Map

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

Preparing to Present

Over the past semester, I’ve been working with Dr. Vallejos to build a website for Massachusetts HOSA. At the conclusion of my independent study project, I will be presenting my project to the Computer Science faculty and other CS students. In preparing for this presentation, I came to a couple of realizations about what I’ve learned from this experience.

While I certainly think that I have improved upon my technical skills in CSS and PHP, I think that what is perhaps more valuable is the immense amount of real-world project management experience that I have gained. This experience has already allowed me to build a better understanding of project requirements at work and for the software development capstone project with AMPATH Informatics. Being able to understand the requirements of stakeholders is essential to delivering a product that meets their expectations. Asking the right questions the first time will prevent having to reach out again and again for clarification of the requirements. People are generally very busy and they will not be available to answer your questions or provide you with information. Whether it is a customer, manager, or product owner, it is best not to waste other people’s time with comeback questions because of your own failure to fully consider the project’s requirements.

I also believe that I greatly improved my personal software development process throughout this project. Although it took a couple of mistakes for me to learn, I am thankful that I made these mistakes in a safe environment and lost nothing but a few hours of my time. I was initially pretty careless, making customization changes to the theme files directly on the web server itself, not backing up, and not tracking any of my changes. After losing all of my theme customizations by updating the theme, I decided to make some changes to this process. I implemented Git version control, allowing me to make and test changes locally before pushing to the actual website as well as tracking changes incrementally and allowing me to rollback to any revision, as desired. I also implemented automatic offsite backup in Google Drive, which runs weekly to ensure that even if I do mess something up, there’s always a working copy safely stored elsewhere.

I have always been an avid believer in learning through experience, and the MassHOSA website project has been a fantastic opportunity to learn through my experiences. Not only have I had the chance to both sharpen my technical skills and widen my skill set, I have gained invaluable experience managing a project and working with stakeholders on bringing an idea from the conceptual phase through to a working product.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.