Monthly Archives: April 2018

Sprint 4 Retrospective

It seems that as each sprint goes by, we tend to achieve a substantial amount more than the preceding one. This sprint is no exception. I feel it has a lot to do with us becoming more familiar with the project, as well as the Angular framework.

Our main objectives for Sprint 4 were the following:

1.  Finish refactoring online-tracker to include a service.
2.  Successfully install PouchDB within the AMPATH app.
3.  Research and attempt using the PouchDB API to:
        (a)  perform REST calls.
        (b)  deal with synchronization.
        (c)  encrypt the data within the database.

Refactoring online-tracker to include a service:
We were able to accomplish this. I should point out that the refactoring of online-tracker was a bit more complicated than we anticipated. Initially we thought that just moving around some code would do the trick. But once we attempted to test the code, we realized we had a series of issues that needed addressing. For example, our original service essentially wasn’t returning anything, making it extremely difficult to test. Further, there were some issues with the Observable.timer() that periodically checks for connectivity. Since it wasn’t being properly closed, it was causing potential resource leaks that seemed to slow down the whole app. Felix from the AMPATH team helped us resolve these issues. The end result is that our pull request was accepted, and is officially part of the ng2-amrs repository. I tried to document the whole process the best I could to help others in the future. If you want to check it out, the PDF is located here.

Successfully install PouchDB within the AMPATH app:
We did not expect this to give us so much trouble, but ultimately we were sucessful. We were able to install PouchDB dependancies inside a new standalone Angular app, but every time we would try to install it within our clones of ng2-amrs, the app would no longer compile. With the help of another team working on offline storage, we were able to get it working. Here’s how our team was able to do it:

   1. Clone a clean copy of ng2-amrs, i.e.:  git clone https://github.com//ng2-amrs ng2-amrs-pouchdb
   2. Open ng2-amrs-pouchdb in WebStorm and press ALT-F12 (or Fn-ALT-F12) to start a terminal.
   3. Delete package-lock.json from the Project menu in WebStorm (make sure safe delete is checked)
   4. npm install pouchdb @types/pouchdb
   5. If package-lock.json is recreated, delete it again by following step 3.
   6. npm install webpack webpack-dev-server karma-cli protractor typescript release-it rimraf -g
   7. If package-lock.json is recreated, delete it again by following step 3.
   8. npm install

Research and attempt using the PouchDB API:
I believe our whole team was able to read most (if not all) the chapters in the official PouchDB guide. We were able to make some progress regarding actual implementation within the AMPATH app. For instance, we were able to configure a router for an offline-storage component, and we can now link to it directly within ng2-amrs. Further, we performed some REST calls using the PouchDB API.

Going forward into the next sprint, I think we need to focus on subscribing to data using observables, and then storing that data offline. This will require further experimentation with the PouchDB API. During the next several days, we will look into encryption at a high level, but will focus primarily on data capturing using PouchDB.

Synchronization between an offline database and the AMPATH server is our ultimate goal for this project. Based on our research so far, this task in particular seems pretty advanced. We are likely going to need assistance from the AMPATH team. I have been communicating with Felix regarding these issues.

Overall, I think we worked well as a team, and as a class in general. Everyone seems genuinely interested in completing the tasks we’ve set for ourselves. Communication has been strong for the most part; we always seem to know what each of us is working on.

 

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

Post #26 – Ampath Application Development – Sprint 4 Retrospective

Last sprint, we were tasked with creating test-applications that utilized a few different encryption libaries, so we could get an idea which library would be the best to use for the implementation of offline-encryption.  We didn’t really finish doing that by the time this sprint began, so we decided to keep some of those tasks on the sprint backlog to continue working on them this sprint.  I spent the first half of this sprint researching and implementing encryption using the bcryptjs encryption library.  This sprint was divided by spring break, during which I mostly took a break from school work.  I did, however, do some refreshing of programming in JavaScript.  This refresher made me feel much more comfortable coming back from spring break.  I expressed my confidence in bcryptjs to my teammates, and presented them with a mock encryption service that I wrote.

The test-application that I made demonstrated bcryptjs’s usefullness in encrypting passwords, but my teammates were curious how the library would handle encrypting other kinds of data that we may experience within the Ampath application.  We came to the realization that bcryptjs is useful and easy-to-use for password encryption, but lacks functionality for encrypting other kinds of data.  We decided that this would be problematic, effectively eliminating it from our choices.  We communicated well and discussed our remaining options with a sense of direction we hadn’t had in the previous sprints.  After further research, we came to the agreement that we would run with the encryption library crypto-js. We began looking at resources for crypto-js and wanted to begin testing some implementation.  We also discussed potential strategies for dividing the work that we must do among our team members.  We do not have a solid plan in place right now, because we were unsure if it would even be necessary to divid the task among all member of the team.  During our next sprint-planning meeting, we intend to talk more about the division of labor and how we intend to move forward with implementation and avoiding compilation issues.  Unfortunately, when me, Erik, and Oren tried to run our application on the last day of the sprint, we all had the same compilation errors, despite having not changed any code since the week we worked on it.  We spent the remaining day of the sprint troubleshooting this issue, to no avail.  Shane and Caleb, members of the ‘Everyone Else’ team, recommended that we try running the command ‘npm rebuild’ in the WebStorm terminal, which is what he and his team members did when they encountered this issue.  I have not tried this solution out yet, but I intend to in the next sprint.

I feel that we made some real progress this week.  We were able to successfully agree upon the best-fit library for our task, and we began troubleshooting errors so that we can get back on track to implementing offline-encryption.  I feel much more comfortable with our strategy than I have been feeling in the previous weeks, and I feel very motivated moving forward.

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

Sprint Retrospective Blog 4

Our team, Everyone Else is making good progress with our first module. Sense we are solely tasked with creating the offline data storage module, we had to narrow our view. We had been worrying too much about how the other modules would work with ours and didn’t focus much on just creating the offline storage module. After our meeting today, we could tell we were more focused on our task and our task only. Connor created a flowchart on Balsamiq showing the flow of the data and where we stand in the whole project. Basically we just need to create the place to store data with appropriate methods and let the other groups do their legwork. I noticed myself going to ask questions to the team that really had no relevance in our current progress of the project. Instead of focusing on getting ANY items stored, we were worried about storing the CORRECT data. Realistically, we just needed to do tests with any JSON Object to ensure that it would work. That is what we are focused on now, getting our module working and worrying about the perfection later.

This sprint was a real confident booster for me. I finally sorted out all of my issues with the application. In case you find yourself in a situation where your app won’t  build properly, I highly suggest trying “npm rebuild” in your project folder.  This reloaded all of the dependencies I had previously installed and ended up working after the first try, even with pouchDB installed!  I still feel slightly behind on knowledge, but working with my team I am learning more every day. I think if we had previous experience with this language, we would have a much easier time with it. However, for our team never working with angular before, I think we are making very good progress.

I am now in a position where I feel comfortable adding to and testing the project. The angular learning curve is steeper than I had expected but I am slowly making progress with it. I would be lost without my teammates. They helped me figure out the errors and save my project file. While I was struggling getting my code to run, the team had already taken a couple of leaps forward. We created the actual service and have a basic test implemented. We officially moved out of the research phase and are getting into the production of code. We each have our own method we need to implement by next meeting and I feel as though our progress will speed up tenfold.

I am in charge of creating the “put” method for our database so that we can easily add information into the database that we created.  Caleb, Fuverion, and Ben will be writing the other methods. Connor will be doing the majority of the testing. With the tasks broken down into different jobs we should be able to efficiently finish this module pretty quickly and show it to AMPath for improvement.

From the blog CS@Worcester – Rookey Mistake by Shane Rookey 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.

CS@Worcester – Fun in Function 2018-04-02 15:51:35

“Dig Deeper” is a pattern that I wanted to apply before I’d read about it. Ever since I started taking computer science courses past the 101 level, I’ve had the persistent nagging awareness that the knowledge I’m gaining is superficial, and there is so much more to be understood. I can feel the difference between knowing how to solve a problem and knowing why the solution is the correct one or the best option within the context of the problem. While deep understanding is a goal for its own sake for me, the writers present this as a goal because of the many problems that arise from only having a shallow understanding: being unable to fix subtle bugs, difficulty maintaining your own code, not realizing a problem you’re trying to solve has a well-known solution or is impossible to solve, and people thinking you’ve misled them about what skills you have. In addition, the lack of awareness of how little you know generates problems of its own.

To gain a deeper understanding of the technologies you use, the writers suggest reading specifications and learning from the original sources to see how the ideas came about.

I subconsciously understood this second method was important. My initial intention in studying computer science was to learn the entire history of computers as a way of discovering why things are the way they are now. I felt like I wouldn’t truly understand until I did that. Additionally, I also heard from several sources while learning C that The C Programming Language, the book co-written by the language’s designer in order to introduce it, is still the best resource there is.

The writers warn that if you apply this pattern regularly, you will naturally end up being given the most difficult assignments. This gives you the opportunity to both fail and succeed spectacularly. You will also likely be the one everyone turns to for code magic when they can’t figure out what they’re doing wrong. They advise you to continue searching for opportunities to be the worst one on a team.

This pattern is probably going to be the one that influences me the most, because it gives so many specific examples to look up of resources that lead to deeper understanding. I’m going to immediately go and apply this pattern, because I’ve been wanting to dig deeper in order to better understand the medical app we’re working on in the Software Development Capstone. Roy Fielding’s PhD thesis on REST sounds promising.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Exposing Your Ignorance

When someone relies on you in a project, for work or in any other situation, sometimes you realize you do not know how to use a particular tool or technology required. Your coworkers or manager need to have confidence when you are assigned a task, but if you tell them you are unfamiliar with the technology required to do the job, would they not lose that confidence in you? But you can not lie either, of course. What do you do?

Tell them anyway, show them that learning is an unavoidable part of software development and no one can be familiar with every piece of technology out there. If you have to reassure them that you can complete what is needed of you, do so with your ability to learn. Let them see your growth throughout your career. There is an ingrained instinct in most people to appear competent, and to do otherwise goes against that instinct. It can also be a matter of pride, not wanting to look ignorant.

But it has to be done. Exposing ones ignorance and marching on is part of the process and leads to much more growth overall. It allows others to aid you as well and lets the team act as a team. I myself have trouble doing this, so this pattern was an important and difficult one for me to read. I have had trouble admitting ignorance in the past, and while it has not hurt me, it definitely did not result in me learning anything new or fixing my ignorance.

While I have not taken the exact actions described in this pattern, I have made an effort the last year or so to ask questions when someone mentions something I am ignorant of. Instead of going with the flow and letting my ignorance pass by undetected, I try and use it as a moment to learn something new. Exposing my ignorance publicly as the pattern suggests is a bit more daunting. I already do that somewhat implicitly in my blog posts, but I guess I should start doing it explicitly as well. Wish me luck.

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.

Walking the Long Road: Nurture Your Passion

In this Apprenticeship Pattern “Nurture Your Passion”, it explains the the importance of your passion as a software developer and how it can be exposed to situations or circumstances that can affect to maintain that passion. This pattern illustrates various ways to protect and keep that passion healthy as possible in order to prolong the enjoyment of being a software developer such as:

  1. Work on what you like.
  2. Join a local or study group that enjoys and focuses on the same things that you enjoy or want to learn more about.
  3. Read books that can expand your view of the field.
  4. Create your own path or move into an organization where your needs, asprirations, and goals can come to fruition.

“Paul Graham said, “The key to being a great hacker may be to work on what you like…. To do something well you have to love it. So to the extent that you can preserve hacking as something you love, you’re likely to do it well.”

This statement by Paul Graham was very interesting and useful to me because for me as an individual, I produce the best work when I love and enjoy what I do. There have been some instances of my life where I would not produce my best work where my state of mind does not like what I am currently doing, whether it be a class that I am taking at school or a part time job.

“To become a journeyman, you will need to have a passion for software craftsmanship. Unfortunately, your daily activities often work to diminish this passion. You might be faced with demoralizing corporate hierarchies, project death marches, abusive managers, or cynical colleagues. It’s hard for your passion to grow when exposed to such hostile conditions, but there are some basic actions you can take to sustain it.”

This is another statement that I found useful and will help me in my intended career because I understand at the end of the day, work is work, and there will always be times where deadlines, corporate needs, managers and co-workers will stress me out, which will lead to a decrease in my passion for software development, particularly video game development. However, the actions that I’ll take will help reinforce my passion to sustain the harsh natures of the work environment and to prolong my love to hone my craft.

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

Apprenticeship Patterns: Retreat into Competence

For this weeks pattern I wanted to understand and analyze “Retreat into Competence.” This pattern addresses the issues of an individual feeling overwhelmed about not having enough knowledge or experience to tackle a project. In my experience in computer science, this happens almost every time I am introduced to a new project or concept. In… Continue reading Apprenticeship Patterns: Retreat into Competence →

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

Using Breakable Toys

I am a strong believer in not being afraid to fail. Failure is how we learn and improve. If you are not facing failure, then perhaps you are not pushing yourself hard enough. It is difficult to grow as an individual and certainly as a software developer if you are not pushing your personal limits. Pushing the limits of what you are comfortable with will inevitably mean failure at one point or another. It is important to know that failure is perfectly acceptable, and learning from your failures helps you to grow.

I was relieved to learn that the ideas presented in Hoover and Oshineye’s Apprenticeship Patterns aligned so well with my personal thinking. The Breakable Toys pattern specifically mentions not being afraid to fail, and gives advice on creating a safe environment to try things. Because it would be dangerous and risky to do your experimenting at work, Hoover and Oshineye recommend creating a safe space. What you create in your safe space should be relevant to your work as an apprentice, and similar in toolset but smaller in scope.

While I have made quite a few of my own programs just messing around to gain familiarity with a particular subject or idea, the specific nature of these programs makes them lose relevance quickly. They are abandoned shortly after they serve their purpose of familiarizing me with an idea. I like the solution presented by Hoover and Oshineye to create software such as a wiki, game, blog, or IRC client. These types of software will not lose their relevancy, as they can be continuously used and further developed. New features can be added that not only serve practical uses, but allow for new opportunities for learning and practice.

Creating software for personal use is far less risky than playing around on company time. If you do it right, you may even get something useful in addition to the knowledge you gain from your failures. I am looking forward to attempting to develop one of the suggested tools suggested in the Breakable Toys pattern. While I do not think I will be writing any software that lives up to Torvald’s breakable toy, I can certainly appreciate the value in trying, and also in failing.

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

Apprenticeship Patterns – Dig Deeper

This pattern relates to my situation almost perfectly. The authors assume that you are an undergraduate who has knowledge of one or more languages. However, the way we learn to use tools is not always the best way to get a deep knowledge of the tools we are using. The authors say that this knowledge is superficial. It is superficial because you have to look up what to do every time a new bug arises. This line sums it up pretty well, “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.” (Oshineye, Hoover)

I am a little different than the people they are directing this pattern to because I am aware of how little I know in the grand scheme of things. Besides that, the solution to this problem is not cutting corners. Don’t take those shortcuts that will help you finish the project 15 minutes quicker, learn to grind through the hard work and come out with the rewards of Deep Knowledge of tools, technologies, and techniques. I have spent a lot of time being frustrated with my own programs and this pattern helps open my eyes to how many shortcuts I must have taken. To truly understand everything about what your working on you need to develop the deep knowledge and the work ethic needed to get there.

My favorite part of this pattern was some of the advice the authors give. “Find out who first came up with the ideas and understand the problems they were trying to solve.” (Oshineye, Hoover) This has never really crossed my mind (I know, sad). I never thought to go all the way back to the origins of the problem. This will definitely be useful to me in the future. Another piece of advice that I always fail to follow is “when you read a tutorial, you should not be looking for code to copy but for a mental structure in which to place your new knowledge.” (Oshineye, Hoover) I find that sometimes when on a time schedule or you are picking certain things from a tutorial, you feel like you don’t have time to fully go through tutorials and learn everything about the guide. While sometimes this is true, it’s more than likely an excuse to get the project done quicker. I will be diving more into tutorials rather than taking them at face value for their code.

Overall, I think this pattern is great for apprentices. It goes to show that many people take shortcuts and if you do the same, you aren’t building your knowledge the way you should.

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.