This week, I read the apprenticeship pattern “Learn How You Fail”. To quickly summarize, this pattern asked you to stop looking at your successes and start actively seeking your failures and weaknesses in order to learn from them. I really liked the message behind this pattern because it is different from what we are accustomed to. It is normally very easy to focus on getting better at something you are mediocre at, and even easier to focus on getting better at something you are great at, but it is really difficult to confront your shortcomings and approach what you are terrible at. My interpretation of this pattern was that it doesn’t seek to discredit the good aspects of your skills but rather putting a focus on the bad as to make you a better engineer overall.

This is another applicable pattern for me personally because I still have a few areas of weakness in my development skills, even in some of the technologies and languages that I’ve been using many years. I have caught myself opting out for a simpler but worse performing option because I didn’t want to confront an area of weakness needed to implement the better solution. The other key aspect of this pattern in accurate self assessment, asking yourself “am I really this good at X, or is there major room to improve there”. I often find that we normally give ourselves the benefit of the doubt and say “Yes we are that good”, and this closes out any potential opportunities to actually improve. What this pattern teaches is to really ask and assess deeply and even ask for an external opinion (via peer review) for areas of weakness.

I agree with this pattern and I plan on implementing this going forward in my career. This pattern should be fairly easy to apply because of its practicality. If you are weak in a skill that will no longer needed, the pattern suggests that you shouldn’t waste your time with that and focus on more important areas of weakness. The only challenge to applying this pattern will be the reluctance to do what we are not good at, but I believe that overcoming this will be much easier if we think about the benefit that will come from fixing our weakest links.

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

This sprint was an important one, as we finally began true work on the project. My team and I seemed to have decided to work on the offline storage aspect of the project before even formally deciding it. We all started some preliminary research on PouchDB, the database tool suggested by the Ampath team, before this sprint started.

With this sprint, we began researching and experimenting with PouchDB in earnest. Breaking the larger task up into five individual tasks for all team members proved difficult. Thus we all began doing the same task in our different ways, and planned to meet up and discuss pitfalls and tips we discovered individually.

Unfortunately, due to snow storms and power outages caused by the storms, our next two in person meetings were canceled and communication for some team members was cut off. This meant meeting back up to discuss our experiences and research results did not happen, except a limited one between myself and two other members when we happened to be on campus at the same time. This was very helpful, and I wish we were able to have the two meetings we missed with everyone.

I began by reading through the documentation of PouchDB, learning how it is setup . It’s a NoSQL database that stores documents, that can have as many attributes as one wants. Each document has a unique ID and rev attribute. The unique ID is to give each document a unique identity. The rev attribute is to revise previous documents. The previous documents are not deleted from the database, but the new revised document is simply added to the database.

I began delving into PouchDB by doing the basic tutorial on PouchDB’s website, a basic Javascript project. I looked through the code to see the basic commands, such as creating a PouchDB database, adding documents to it, and getting documents from the database. After this I created a new angular project to play around with PouchDB in Angular. This led me to an unexpected error in creating a new Angular project using the Webworks IDE. I learned after some looking this is due to a change in Angular CLI 1.7.0 that makes creating a new project through Webworks and other JetBrains IDE’s impossible. The issue as explained by a Webworks Product Manager:

https://github.com/angular/angular-cli/issues/9655#issuecomment-370491452

After discovering this I simply made the new project using Angular CLI directly, then opened itin Webworks. I made a new project instead of playing with PouchDB in the ng2-amrs project is due to the amount of dependencies and pre-existing files in the project. I wanted to start with no baggage and play with PouchDB in a clean new environment. Through trial and error, and discussing with my team mates I learned one large mistake I made was following the Javascript and Typescript instructions for installing PouchDB. Due to the basic tutorial I did, I used the method that involves adding a script line in the index.html file of a project, and then used the TypeScript method which installed the @types folders for PouchDB, as Angular uses Typescript files. This led to issues with the import statements in my program. After getting rid of the line in my index.html, the import statements worked as stated in the instructions on the PouchDB website.

After this, using the examples shown on the PouchDB website, I was able to create a database, put in new documents, and got those documents back and logged them on the console in Angular. I read up on several resources to understand how promises work, as the PouchDB API uses promise formats for the commands I stated earlier. They are essentially a truncated try-catch block, that waits for a response before continuing on.

Despite the missed meetings, I feel like we got a good start to the project. We now have a foundation to complete the offline storage aspect of the project. Especially as one of our teammates has pushed their version of the project with PouchDB installed and dependency issues fixed on Github for us to use.

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.