This Sprint was a good one. We gained traction last sprint and kept that that going this sprint as well. The momentum was not fully there as Spring Break was a bit of a speed bump to getting in to the flow of the project, and then afterward many end of semester projects came up that took my time. But either way, by the end we had the basic bare bones of an offline data storage service, a good stopping for next sprint to continue and hopefully finish off.

I continued experimenting with PouchDB this sprint, still on a separate angular project than the ng2-amrs project. This was mostly to avoid the hassle of installing and getting PouchDB working on the ng2-amrs project, as I had seen and heard frustrations from my team and others. This also let me worry solely on getting PouchDB working in a project and creating a successfully working angular project service to handle the logic of the offline storage, with methods for adding and getting documents from the PouchDB database.

I realized after a meeting with my team one day that the formatting of my code was different than the project, and so I copied the ng2-amrs projects tslint.json file into my own to make sure transferring any code I used would be easy and issue free. I fixed my function calls to use the recommended “ => “. After I made the code still work and formatted correctly, I created a new service called simply “offlineStorage”. It had a cunstructor that created a new PouchDB database, and just two methods, one to add a document to the database and one to get a document back.

The code in these methods was reworked code from the examples on PouchDB’s website, with added console logs to see the results. Then to actually test the service, I modified the .spec file for it by adding more tests than the default one. This part was done along with my entire team across two of our in person meetings. We were able to confirm that the service actually created a database, added documents of given data with a given id, and got documents back with a desired id.

The main issue that popped up with the tests were the fact I and my team were wondering how to interact with the documents received by using the get command. When checked the type of the response, it simply stated it was an object. I was not sure how to check the contents of the document and see if it was the correct one. On the last meeting our professor helpfully suggested we see if it was a JSON object, which it was. I felt a bit silly, but now with that issue solved, working with the documents we get from PouchDB and possible ones we add into PouchDB should go much smoother.

During this sprint, occasionally conversations would veer into discussing how we would receive the data from an mrs server and what kind of format the data would be. But after discussing it among ourselves, a helpful diagram drawn up by our team mate Connor showing our role in the overall project and we decided to only worry about our task, offline storage, and nothing else. So we are going to focus completely on fleshing out the service that will handle offline storage tasks using PouchDB. With a narrowing of possible tasks, the division of work for the next step should be very clear.

I feel like it took a bit, but we cleared another hurdle. After this we should speed up next sprint, and hopefully have a completed service that can handle offline storage and a pull request to the master ng2-amrs project by the end of next sprint.

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.

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.

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.

While learning how to be a great apprentice is great, the main issue is getting to that point. Specifically being accepted onto a team or project, being hired by a company. To be a part of a professional team and become an apprentice is the first step and can be the hardest thing to accomplice for some.

As the book states, it is a risk hiring someone new and untested for teams out there. You may not be able to contribute to the teams work and you may not even be able to take care of automating simple manual tasks. So then how does one solve this issue? By having Concrete Skills. Having skills that will first of all get you through the HR filter and technical skills that can and will aid any team you are on. This makes the risk of hiring you on much lower, and makes the decision easier.

This apprenticeship pattern was not really at all surprising. Every step of the way, I was nodding my head. Learning concrete skills just makes too much sense in my head to be something anyone can disagree with as a valid way of making it more likely to be hired on to teams. Reading this apprenticeship pattern has not changed any of my thoughts on my chosen profession but has solidified the path I believed I would have to take in the first place.

The story the pattern offered did make me open my horizons when it comes to what count as concrete skills. Skills gained as a therapist would obviously be helpful in a team setting, but it is not something that would come to my mind readily. I mainly think of only technical skills, but social skills that can aid the rest of the team in ways I or they would not expect are also completely valid avenues to making it easier to hire oneself.

Also, looking at others CV’s and resumes, then pulling out the concrete skills that one can learn themselves and demonstrate easily, is a simple action that I can start doing now. Something obvious in hindsight that I should have been doing from the start.

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.

I decided to focus on the pattern involving feedback loops this week, because I saw it being referenced in many of the various other patterns throughout the text I browsed. Also, because it seems like to be a good apprentice, having lots of feedback to see what one is doing right or wrong seems like an incredibly important step.

The pattern is called Create Feedback Loops. The idea behind it is incredibly simple, but strong. Make sure to set up mechanisms that will give you concrete feedback on how you are doing. There are many various possibilities, from purely technical such as test-driven development to simply asking others for honest criticism of what you have done.

However, make sure the feedback is examined and the good feedback that can be implemented is taken, not bad advice that can set you back in the disguise of feedback. It is important to have positive feedback that encourages you to keep doing good things, and balancing feedback which discourages bad things.

I have realized the importance of concrete feedback implicitly throughout the years, but having it cemented as the important step it is and being explicitly aware of it, I feel, will make things going forward much easier for me. I have experienced the feeling of being completely lost many times and see how good feedback loops would have prevented many of these instances.

I was nodding my head the entire time reading the section on this pattern. Everything stated made sense and I could relate to. The personal story of Patrick’s situation was something I’ve felt many times in and out of software, where any feedback you get is vague at best and it feels impossible to know where you should head or do. Unfortunately, this was a situation I faced with some courses and professors, where after a discussion or question and answer session, I felt like nothing was clarified or it was even less clarified. These situations sometimes worked and sometimes did not, but I was always left with the sense that I did not learn much.

Going forward, I will attempt to avoid this from happening as much in the future as possible by using the techniques and actions the text suggests.

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.

There’s been a lot of automation mentioned throughout the Awesome Testing blog.

A popular topic in testing is apparently the automation vs manual testing debate. Advocates of manual testing state that an automated test is never going to compare to a humans intelligence and possible deductions. Which I can definitely agree with. Human intelligence is a very important aspect of many projects. It’s this aspect that machine learning tries to replicate in machines through code. It’s why identifying what’s in an image is so difficult.

But according to the post, the crowd who argues this is slowly losing ground because of the advancement and evolution in production cycles. With Continuous Development and Integration, release cycles have become shorter and more frequent. As the releases are more and more frequent, the human intelligence doesn’t have time to figure out problems.

It is much easier to let automated test find almost all of the bugs in your product and then release. If any glaring issues are discovered by human users or others later, the product can simply be rolled back to a previous stable release. It’s a question of balancing risk and profit. With Continuous Integration, and things like Blue Green testing mentioned in earlier posts, letting some issues go isn’t such a big deal. And this speed of release is much more profitable and productive than waiting for manual testing to find almost every issue.

However, in security testing, the risk associated is much, much higher. If you release with a security flaw in a service product like Facebook, users can have their valuable information stolen and used for malicious purposes. They can lose money and have their identities stolen. It’s impossible to simply roll back to a previous version and fix any damage caused by a security bug.

In this case it is much better to have a skilled pentester, a penetration tester, whose job is manually and automatically find possible points of penetration into a system. Speedy releases are not a priority with the level of risk involved. Thus, manual testing by the pentester is required. These are experts in many fields. Networking, programming, psychology, social engineering, and more.

Social engineering and psychology are more important than one would expect, as so much security can be bypassed by getting an admin password from an admin. Humans are a huge weakpoint in most systems that can’t be automatically tested.

In the field of security testing, manual testing is still incredibly important. I originally was nodding my head that automation was much more effective, especially with version control. But this post changed my mind somewhat and showed how important human intelligence still is to computer fields.

Original post: http://www.awesome-testing.com/2017/03/automated-testing-vs-manual-testing.html

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.