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.

Third Sprint Retrospective

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:


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.

Concrete Skills

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.

Second Sprint Retrospective

This sprint cycle was focused on coming up with the design of the offline module. We spent most of the sprint researching and thinking through what we were going to do in the future. It was mostly planning and research,. It became clear pretty quickly in that we were interested in doing the offline storage of the offline module for the application. So we did research on one of the suggested services in the users tasks, pouchDB.

I mainly read through the articles they suggested and other articles on the different ways to store data offline with an app and encryption. Doing research on the encryption aspect may turn out to be pointless since another team as decided to take up the aspect.

I also considered what the offline version of the app would look like. The look has to change somewhat to let the user know they have gone offline, and also due to the missing information and features available when offline. Also Towards this end, I went through all the pages on the apps test server to get the general visual design of the application. I also communicated with the Ampath team about the apparent loss of the fake patient data that was on the test server, but was removed for some reason. Felix, from the Ampath team, was a great help with this. The JSON representation snippets Jonathon gave us and the general description also was a great help in visualizing the look of the application when it goes offline.

I decided to make a small mock up of the visualization of the applications offline look on balsamiq. Considering the minimized nature of the data when it stored offline, and the lack of other features mentioned in the documentation, such as offline clinic viewing, I removed everything but the patient search. This should be simple to accomplish in angular from what I’ve seen by simply hiding features from users when they are offline. This means the application looks almost identical other than features being removed, and a limited number of tabs on patient information.

The team went through the code of the application during meetings to get a general gist of how it is layed out. We asked theAmpath team if they had a UML diagram to better aid us in understanding the way the code is organized and laid out, and how it all comes together. Unfortunately, they did not, which means we will simply have to get used to the way the application is organized.

The biggest take away from this sprint is the lack of direction that comes from having a higher level manager. Without this, the sprint felt somewhat lacking in direction. I realized that a lot more initiative would be required to get things going, but I still found myself lacking. I feel like this is a good learning experience. In the real world, nothing is perfect. There might not be concrete goals or plans. There is a lot that relies on me and others making ourselves be active and actively open up communication with other teams and people.

First Sprint Retrospective

My first sprint experience was interesting. The experience was more of a sprint-lite, a streamlined version of the process. The tasks we had to accomplish did not have to be split up between team members and there was no real roadblocks that had to be overcome except minor issues which were solved with out too much hair pulling.

This weeks sprint was a learning experience in that it was my first time with sprinting on a software project. It allowed me to get some of the basics down and get used to the experience. Not much would change with the knowledge I have now, other than issues would be fixed sooner. Though they were fixed quite quickly to begin with.

I feel like most of our progress was made during the in class meetings, as we could share a large amount of our findings with each other and have long discussions on them. In the future, I feel as if more discussion should be had remotely, to increase productivity overall. Though this time it did not really matter. Helpful links and tips were still posted to slack. The Trello board was set up quite quickly, and the stand ups were finished by everyone pretty consistently. Barring two very minor misses. Overall, the team worked really well together. Everyone was helpful and made contributions to aid others. I brought up a fix for an issue I will describe in a few moments, and was helped in resolving an error by a fellow team member.

During the week everyone had to setup their teams repositories which had forked versions of the n2-amrs app. They then had to get the application working on their machines. The steps to take were basic, but they did not end up being as simple as they should have. Npm install should have installed all dependencies and npm run should started the application running. However, many people, including me, received errors when trying to install dependencies. The errors mention files that do not exist in the application. I searched the issue and online and was able to come upon a page on git about the specific issue with many suggestions for fixing it. Here’s a link to the page in question:


The method that ended up working for me was to delete package-lock.json, which would be reinstalled along with the other dependencies after running npm install.

Running the application came with an issue in the styles guide file, where it could not find another file called ladda.min.css . There were suggested fixes on the general slack channel, and suggestions made by my team mates. I ultimately fixed it by moving the ladd.min.css file and then rewriting the path in the styles guide file to its new location.

The Importance of Feedback

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.

Software Craftsmanship

I tried to go into the Apprentice Patterns with an open mind, but this was difficult as my preconceived notions of an apprentice craftsman generally aligned with the old timey examples the first chapter described as not being what a software craftsman apprentice would look like.

The first chapter did a good job avoiding my worst expectations for the text, advocating for a return to past apprentice master relationships or some other ridiculous notion. These worries were not at the forefront of my mind, but they were at the back hoping they turned out to be unwarranted. Which they were thankfully.

The focus on being determined, hard working, and eager to learn and advance was definitely expected and aligned with what I believed a good software developer would be like. I agree with the assertion that people are not simply talented and skilled to begin with, it takes work to get there and continued work to maintain the level of skill achieved. Being talented or not is often seen as a binary value that you have or do not, stifling some who believe it is simply out of their grasp. I enjoy the text dissuading this line of thinking.

Being a software craftsman means to be skill centric rather than process centric is an idea that I’ve implicitly come to myself, but never really thought about in terms of consequences. The downsides of a skill centric field is petty obvious when it was stated, but I never considered it before. My eyes have opened somewhat and I feel like I will be seeing careers around me in terms of skill or process centric for some time.

When the text described the roles and differences between apprentices, journeymen, and masters it was about what I expected. It was somewhat vague, but that makes sense given how undefined things can be in the real world. What I found interesting was the mention of how some apprentice patterns would not work for a journeyman and that failure for them and masters cause much more harm than an apprentice’s. Failure is not discouraged for an apprentice, it is seen as a learning experience. So the limiting of options as one gains more responsibilities and failure becomes less acceptable was something I did not consider. Obviously as one gains more responsibility and experience failure should happen much less, but it is interesting to consider if the pressure of not being allowed to fail limits growth or not.

Overall, I am quite excited to keep reading the text. It seems to be geared specifically to people in my situation. Having several patterns that give guidance when I might not have any provides a nice safety net I can fall back on instead of guessing what works.

Manual Testing and Security

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

Headless Browser Testing and Selenium

Today I’ve discovered the amazing world of browser testing.

I’ve been learning about tools lately in our final classes, such as Pit Testing. But using an already existing tool, a web browser, to automate tests, was a really cool discovery.

Over on Awesome Testing’s blog, they have many posts talking about Selenium, which made me finally look it up. On the home page of Selenium, they proudly proclaim, “Selenium automates browsers. That’s it!” They know how amazing just that is. By automating a web browser, the capabilities are nearly limitless. You can distribute scripts across many environments. Create bug reproductions scripts, and scripts to aid in automated exploratory testing.

By using versatile and common tools such as web browsers, including the most popular ones like Chrome and Firefox, one can test all manner of things. Browsers can read html, styling elements, javascript, and AJAX. They can gain incredible amounts of information and interact with web pages in ways that with just a small amount of automation can test almost everything about a web page and thus web sites. As browsers also have the ability to view certain files such .pdf files, this increases their ability to test.

The possibilities with Selenium are really wonderful to think about. But the post by Awesome testing today is talking specifically about headless browser testing.

What’s a headless browser? Simply a browser without a Graphic User Interface. So instead one uses a command line like interface or network interface. This is helpful for Continuous Integration in that a display might not always be available. Unix systems, for example, don’t have display outputs on by default. In which case, headless browsers allow us to test them instead of using combinations of other tools to do the same job.

By combining Selenium and a headless browser we can do headless browser testing on servers and web sites. It’s so simple, and also so interesting. This gave me a glimpse of the way professional testers combine multiple tools along with coding, most of the article is dedicated to showcasing java code for headless browser testing in Firefox, to create their own toolbox of software for making sure things work. It also showed a concrete example a testing method used in Continuous Integration, which was nice. I was also introduced to a very exciting new tool, Selenium. Having a new toy to play with is always exciting though.

Original post: http://www.awesome-testing.com/2017/09/firefox-selenium-browser-capabilities.html