Apprenticeship Pattern: Record What You Learn

This week I also read the pattern “Record What You Learn”, and this is a pattern that I am not anywhere near doing correctly. I think that this problem is useful, and though not as significantly as the others, still one worth implementing. This pattern is essentially asking you to take notes and record all of the things that you’ve learned throughout your journey. Taking notes does help in learning, but its real power comes when you actually go back and review these notes. The author alludes to the previously mentioned by suggesting that we keep our notes in a medium that we are more likely to access and interact with. Often times notes are taken in a subject specific notebook or application, the problem with this can be actually going back to this material to review it since it may lack that personal touch. This problem can be alleviated by storing your notes in a personal wiki, journal, or blog, the key being that this medium is personal and that it is something we interact with often.

The author emphasized the idea that your notes should be a “nursery, not a graveyard”, meaning that these notes should be a source of progress and growth and not stagnation. Even if you go through your notes daily, if you are only trying to memorize what is in your notes rather than trying to gain new insights and making new connections with them your time could be better spent doing something else. The other great benefit of having these notes is the fact that they act as some sort of wiki for you. The author mentions this and I have seen the truth in that myself. There have been times when there was a problem/bug that I could not figure out and the solution required multiple different things to be done, when I originally learned to solve the problem it may have taken me hours to gather all of the resources and information, but after storing all of those steps in my notes, I do it in minutes. Taking notes can often be too mundane and boring to actually want to do but this pattern has really showed me that it’s worth powering through it. By recording what you learn you have a detailed history of your grown, your own personal archive, and source of future ideas and innovations and because of this I will definitely try to apply this pattern as well 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.

Apprenticeship Pattern – Retreat into Competence

This pattern is all about taking a step back, a deep breath, and fighting through the struggles you might be having. The authors talk about the roller coaster ride that an apprenticeship can become. They include advice about what to do when you feel like you aren’t making any progress and how to fix the situation. Essentially, I think the authors wrote this pattern for people struggling to learn new technologies. It can be scary to jump into a project that you had never been familiar with before and  the authors provide a confidence booster to help you bounceback. The authors say to set a time limit for yourself to go back and practice the things you already know and are comfortable with, once that time limit is up, go back and try to work through the new problems you might be having. Build up your confidence and keep the forward momentum going.

I didn’t find this pattern to be as immediately useful as some of the other patterns, however I chose this pattern because this situation can happen to anyone. I am sure that it can be very easy to become overwhelmed with a project that you are not entirely comfortable with. However, I don’t necessarily agree with retreating, even if it is only for a short time. I find that being resilient and stubborn can help you fight through your issues, spending consecutive time working on something can help you break through the obstacles that you didn’t think you could. I don’t really understand the actions the authors say to take:

“Pick something self-contained that you know really well and reimplement it. For instance, Ade likes to implement caching algorithms because they can range from the trivial to the highly complex. They also allow opportunities to reinforce his intuition about design and algorithmic complexity.”

For example, it is great that he likes to implement caching algorithms but what does that have to do with the project he is working on, assuming that it has nothing to do with caching? Going back and doing something you’ve done many times can certainly help build confidence but I also think it might be too much of a distraction to try and be productive. Overall, I think not giving up is the most important part of succeeding. If you need a break you could ask someone (like a mentor) to help you learn the process.

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

Apprenticeship Pattern: Practice, Practice, Practice

This week I read the pattern “Practice, Practice, Practice” and the focus of this pattern is pretty obvious. An expected theme that I came across when reading this pattern was the importance of practice itself, but the author went beyond that and specified the type of practice that is most valuable. The technique of practice that is optimal is said to be “deliberate practice” in which “ a mentor would assign you an exercise based on her understanding of your strengths and weaknesses…”. This method of practice is good because the exercises that you are practicing with match your skill level and most important of all, you are receiving feedback. Depending on your performance, this mentor would then decide whether or not increase the difficulty of the exercises. I can see the value in practicing like this, a big thing stopping me and many others from going back and practicing is how boring and mundane it is and this method ensures that you are amply challenged.

Another aspect of practice that the author mentions that you don’t often hear about is relaxation. The author says “if you aren’t relaxed you’re not going to learn from the practice”, in my experience this could not be anymore true. The practice that you are doing should be relaxing, it should be done without a deadline in an environment where you can break things without consequence.That brings me back to the level of challenge once again, this is because the practice should be done at a difficulty where you can learn but not too difficult that you get frustrated. Having learn how much being relaxed helps in the learning process I intend to use this going forward. The goal is to get to the point where you enjoy your practice sessions if you do not then you should likely change how you are practicing, and if that still fails then it could be because you don’t really enjoy the thing you are practicing.

The other major point that the author hit upon was feedback, this topic has been addressed in other patterns throughout the book and this is because of how important it really is. Yes it is true that practice makes you better, but practicing the wrong this will make you better at the wrong thing. Feedback is important because it makes sure that while you are practicing you are doing things right and developing good habits.

This pattern has reinforced to me the importance of practice, but more than that it’s showed me the importance of CORRECT practice. I plan on implementing this pattern not only throughout my software career, but on any skill that I want to develop in the future.

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

Apprenticeship Patterns – Breakable Toys

In this pattern, the authors discuss the importance of building what they call “breakable toys.” The context they present is one in which the apprentice needs an outlet for failure, so to speak, because in order to gain the experience needed to excel in the software development field they must make mistakes and learn from them. This can be difficult in a professional setting as management and other superiors may not be expecting failure from the new apprentice. Hence, making mistakes in the work environment can have negative repercussions. While it’s impossible to avoid failure in the computer science field, it can be somewhat contained by adopting this pattern and breaking things in a low-stakes environment where the only one effected by failure is the apprentice himself.

The authors stress the fact that the only way to progress in the software development field is to make lots of mistakes and even just flat out fail sometimes in order to learn and grow as an individual and as a software craftsman. The authors advise apprentices to make breakable toys which resemble what they might be building at work. This allows the apprentice more flexibility in design and a lot less stress when compared to the professional setting. One example of a “breakable toy” the authors suggest for apprentices is putting together a wiki. They go on to show that by taking on this type of project the apprentice can learn new things about a variety of topics ranging from “HTTP, REST, parsing, web design, caching, full-text search, databases, and concurrency.”

I have to say I certainly agree with the authors after reading about this pattern. Even before I read this I have been experimenting with “breakable toys” of my own. When it comes to learning new things within the field, I am a very hands-on learner so building things and breaking them are a must if I hope to gain new useful skills. Since I work in Security, some of the side projects I have going on at the moment are things like building my own firewall and deploying a Security Onion instance within my home lab in order to gain first hand experience regarding best practices for Network Security Monitoring.

 

 

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.

Apprenticeship Patterns – Expand Your Bandwidth

This is the first pattern in chapter 5 of Apprenticeship Patterns which focusses on how to address the steep learning curve associated with picking up new programming languages and/or practices. The context the authors present in this pattern is one in which the apprentice has acquired a set of “basic skills” that must be improved in order to become a journeyman. They describe the problem as being that the basic skills held by the apprentice are insufficient for high-level projects that require a more extensive knowledge base and/or skillset. The authors use the analogy that up to this point the apprentice has been sipping information through a straw but the time has come where they must drink from the fire hose of information.

As a solution, the authors suggest apprentices should “expand [their] ability to take in new information.” To do this, the authors advocate for apprentices to not just read books pertaining to knowledge they seek to gain but rather utilize a number of resources in combination with the reading to increase retention and understanding. Some of things they suggest are signing up for Google Reader and subscribing to software development blogs, following “luminaries” on twitter, subscribing to online mailing lists and answering people’s questions, as well as physically or virtually attending technical conferences. The authors note that when the so-called fire hose of information is turned on it can be difficult for an apprentice to get other work done as most of their time will be taken up by the process of ingesting a plethora of new information. Hence, they recommend that this pattern should not be used for more than a few months otherwise it may have yield diminished returns by decreasing an apprentice’s development velocity.

I found this particular pattern to offer some highly valuable advise in terms of how to really push my development career forward. I think that I can actually put this pattern to practice after graduation as I am moving into a position that requires a strong understanding of python programming. Up until this point in my career, I would describe my python programming skills as being basic but in order to excel in my position I will need to acquire a deeper set of skills. After reading this, I decided that when I start my new job I will try to put my mouth to the fire hose information, so to speak, in order to gain essential knowledge and put myself in a position to excel.

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

Summary

This sprint was a very important one considering what we had sought out to accomplish. In this sprint, we wanted to add many functionalities and since it was the last full sprint before the end of the semester, we wanted to address all the major functionalities we felt needed to be added before we called it a semester. Some of these tasks that was being addressed this sprint was : 

  1. Updating Offline Track Refresh Time.
  2. Documentation of work that was completed 
  3. Test Cases – UI Checkbox Test 
  4. Backend Functionalities. 

Most of the documentation was done by our team captain, since he had the most understanding of all the moving parts that was involved in the program.

What was Accomplished 

Of the tasks that was set out to be completed, we were able to complete the offline track refresh time and also the backend functionalities of the program. To make things more clear, we also documented a list of classes and files that we touched / edited and also draw a diagram of how we envisioned our additions and modifications to function within the application. Backend functionalities was tricky but we were able to write modify existing methods and function and also wrote new methods that would aid in completing the requested task. All this work was again documented and revised.  I believe the most challenging tasks through out the sprint was coming up with test cases that would evaluated and affirm the functioning of the proposed written code. I was personally in charge of this testing. From deciding to address testing, i was able to dig through many codes and files that we later had to review and revise. Every code we wrote needed some sort of testing module that would verify its status and would be used to troubleshoot should we find have any issues in the future. 

Reflections 

After this sprint, i conclude that testing although may not seem like it, is one of the tedious tasks of writing code. In order to write efficient and proper test, you need to be able to understand the logic thats already being implemented in the code then reverse the thought process and develop a new way that you can verify that the task got accomplished.  I realized that not only do you need to be able to read and understand code efficiently, you also need a creative edge that would be used in coming up with test cases and scenarios. This is because unlike coding, often test cases and implementations are unique and does not already have a laid out methods to get this accomplished. Coding requires pose and originality but i believe testing adds a touch of creativity to this paradigm. Overall it was a good sprint and i think we were able to communicate better and get a lot done. 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 6

During Sprint Retrospective 6 I continued to learn more about the CryptoJS library, encryption, Angular, and Git. From the CryptoJS npm page, this code snippet helped me understand how data is encrypted and decrypted using the CryptoJS library:

var CryptoJS = require("crypto-js");
 
var data = [{id: 1}, {id: 2}]
 
// Encrypt
var ciphertext = CryptoJS.AES.encrypt(JSON.stringify(data), 'secret key 123');
 
// Decrypt
var bytes  = CryptoJS.AES.decrypt(ciphertext.toString(), 'secret key 123');
var decryptedData = JSON.parse(bytes.toString(CryptoJS.enc.Utf8));
 
console.log(decryptedData);

My job on the team was to implement a function to encrypt a data record, I also added the decryption function as they go hand-in-hand. The example shown above is in Javascript but easily implemented them into a Typescript file. The following are the functions I came up with in my encryption / decryption service file:

Encrypt a Record


public encryptRecord(data: any[], privateKey: string) : string{
    let ciphertext = CryptoJS.AES.encrypt(JSON.stringify(data), privateKey);
    return ciphertext;
}

This function takes a set of data, and a given private key, encrypts the data, and returns and the encrypted string.

Decrypt a Record


public decryptRecord(ciphertext: string, privateKey: string) : string{
    let bytes  = CryptoJS.AES.decrypt(ciphertext.toString(), privateKey);
    let decryptedData = JSON.parse(bytes.toString(CryptoJS.enc.Utf8));
    return decryptedData;
}

This function takes the encrypted string, and a private key and returns the decrypted string.

I learned a lot of information about Typescript and web applications, I learned more about Node.js, encryption, and Javascript. I feel this information will help me in my professional career, especially if I am working with web development and API’s. I am interesting in further contributing to this open source project, and possibly more. I would like to improve my skills in Javascript and Angular. I would like to learn more about Angular testing and continue to work on the tests I wrote for my functions, to make sure they are working properly.

The team was successful in finding a suitable cryptography library that had all the features we were looking for, but we did run into trouble getting CryptoJS implemented in the ampath application. I successfully implemented the features for encrypting and decrypting a data record, hopefully it will be used to help future teams encrypt patient data. I think I spent too much time researching and not enough time actually working with the ampath application. I did find though that the solution I needed was easier that I thought it would be. We all hit some roadblocks getting things to always work, sometimes the ampath application would give us compilation errors out of nowhere.

During this Sprint we continued working on our respective parts of the encryption service. I successfully wrote two functions, one to encrypt a data record and one to decrypt a data record. I wrote test files for the functions that I believe will work but had some trouble getting the tests to work. Once we made the decision to use CryptoJS, I used this source to help me contribute my part to the project. I pushed my part of the project to my local repository and then made a pull request for the group repository. I did have some trouble with Git dealing with merge conflicts and setting the remote, but feel I was due for a refresher and eventually solved my problems.

The post Sprint Retrospective 6 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.

Sprint 6 Retrospective

This was our final full sprint, the next one being only a couple days, and designed for gathering our thoughts, doing a pseudo post mortem, and presenting what we learned through the project. With it, we have essentially finished the project. This last sprint was mostly dedicated to a final breakthrough on on our service and the use of Promises.

In the beginning of the sprint, it was filled with some level of frustration. Our team lacked extensive or comprehensive knowledge on Promises, and asynchronous coding in general. This led to some blind trial and error attempts at trying to get our service to work correctly. The main issue was that our tests were failing in ways that were confusing. The main way being that the code in our service functions were seemingly being skipped, not happening at all, or just not returning what was expected or wanted.

Due to this, it was hard to tell where we were going wrong. Because of this, we eventually began researching Promises more to discover what the issue was. Eventually in one of our bi weekly, in person meetings it was brought to my attention by Shane Rookey, a team mate, that the issue was not that were doing something wrong in our functions. The main issue was the way were testing them.

With a promise, due to it being asynchronous, it is unknown when it is resolved. That’s why you use the ‘.then’ method of a promise. This method executes a function when the promise resolves, or when it fails. When the promise resolves, then do this, essentially. We would use PouchDB’s methods (.get, .put, etc), handle it in a .then, and then attempt to return the response of those methods. And then in our tests we would use a simple line of code to see if the response was what we expected.

However, because what was being returned from the methods was a promise, doing anything with it without using .then just does not work. We were simply using a line of code that expected the responses from the methods to have a field called ‘ok’ to be true. But that is a regular synchronous line of code. It has to be placed in the .then to work. Anything done with a promise has to be done in a .then. And attempting to return it also does not work, as after something is done in a .then, it returns another promise.

You can not just write the functions in the service asynchronously and then just go on as normal when handling them in tests and other services or code. That was what we did not understand. Once that was understood, writing tests and actually seeing if our functions, well, functioned, was much easier. Another team by this point had managed to get a service running that would take patient data and store it using PouchDB. We both met during the sprint and decided we should focus on getting tests running for the service while they focused on getting a GUI to display stored data up and running.

In the end, I felt more could have been done if we had some more prior knowledge. And also, if there was a bit more of a comprehensive guide on using promises and how to work with them. Some more comprehensive documentation would have smoothed things out. Our team will strive to document all these things for future developers that work on the project, which will hopefully aid in alleviating a lot of frustration.

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.

Sprint #6 Retrospective

During this Sprint, my team and I tried to complete as much as we could since we are coming to an end in the semester. We wanted to at least give JJ and the AMPATH people some sort of workable interface for our offline data capture service. Throughout the process of finishing and having a workable interface, the team and I decided to focus all of our attention on that aspect, aside from the encryption service that I was trying to discuss with the encryption team involving the javascript implementation crypto.js.

Some tasks that we did during the week that helped lead us to establishing the offline data capture service interface were:

  • Help ensure GUI code is compatible with any offline-capturing abilities we implement when the user is online and vice versa.
  • Create balsamiq diagrams outlining current and anticipated implementations of offline-capturing the OpenMRS / ETL data.
  • Ensure all new components, GUIs, etc comply with basic AMPATH CSS styles, overall look and coding convention.
  • Code the offline GUI based on the help and input from Jerry and other teammates.
  • Write/maintain tests for our implementations so they are always as current as possible.
  • Seek help from the AMPATH development team if any of us hit a roadblock concerning implementation.
  • Offer suggestions to other teams based on our overall process, so that all teams’ implementations can work together as smoothly as possible.
  • Touch base with all teams (encryption, offline-storage, and login) regarding their overall progress.
  • Develop high-level idea of a Doctor/Provider object so we can consider if it is worth implementation.
  • Develop mock diagram where a “Doctor/Provider” can pick and choose what patients to sync.

The above tasks were what was tried and attempted. What was done and completed were the establishment of the Doctor/Provider object, and the mock diagram. For the GUI task, we had to communicate with JJ a lot. Due to the amount of time the team had, we had a feeling that there wouldn’t be enough time to create a perfect GUI, even though JJ wanted one. Midway through the sprint, we sent JJ our progress on what we did so far for the offline data capture service through a walk-through video that we shared on the slack channel. JJ then understood where were at with the progress and we concluded that it was okay to work towards establishing an interface where the user can clearly see if he is offline/online along with the data. That was one of the tasks that we had approach differently and adjusted to.

As a team, we learned to make a major adjustment to our task during this sprint. We knew that time was a concern, and what the people at AMPATH and JJ were expecting to get, which was the new offline GUI, seemed to be too much. We wanted to at least deliver something to them that at least worked, which is why we moved away from creating the new GUI. From this situation, this could be applied in real life software development environments because there will come times where I would have to adjust my tasks to deliver something that the customer wants, even if it isn’t 100% of what they want it to be, it will perform the same functions of what they want it to do.

The team’s performance during this sprint was above above average. Everyone contributed evenly or more than an adequate effort throughout this sprint. Communication was very effective between each member and between our team and AMPATH. As an individual, I performed average during this sprint. I mainly tried to talk to the other teams, trying to get some info on their status. The only team that we communicated to more than others was the offline data storage team, and we began to work alongside with them since our tasks were similar to theirs. I also tried to help find several components in the AMPATH code for which JJ wanted the interface to display such such as genral patient data, vitals, lab results, and HIV summaries.

Overall, the team worked diligently and we wouldn’t have proceeded in any other way. We will try to have our offline interface working, completed and delivered hopefully by the end of this next half sprint.

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.

Sprint Retrospective 6

This sprint, we managed to get multiple changes merged into our team’s offline-login branch. Luigi and I worked on coding the back end of the checkbox with George’s help. In the authentication service, Luigi created two new methods, authenticateAndSave and setAndSaveCredentials. These mirror the authenticate method and the setCredentials method respectively, each with an added boolean parameter. We decided this would be simpler than trying to restructure the existing methods to accept a boolean value they would only use sometimes. The authenticateAndSave method saves the boolean value in the saveOfflineCreds variable and then passes other duties to the authenticate method, and setAndSaveCredentials stores the user in localStorage and then passes other duties to the setCredentials method.

For my part, I tried to modify the login component to utilize authenticateAndSave instead of authenticate when the checkbox is checked. Attempting to make this change produced a lot of unexpected difficulties. Using the HTML checkbox’s id attribute, I declared a variable to perform the .checked method on, which defaulted to the type HTMLElement. Trying to call .checked on this object didn’t work, so I tried to cast it to an HTMLInputElement, the type that has this method, in the declaration. When this wasn’t allowed by the TSLint file, I used “as” syntax type assertion. This was accepted without compiler errors, and I could call .checked on the HTMLInputElement object, but we found later that the code testing whether the checkbox is checked broke the ability to log in. When you click the login button, the login method gets to the conditional statement that checks whether the checkbox is checked and can’t go past it, giving a type error that says “Cannot read property ‘checked’ of null.” We weren’t able to fix this by the end of this sprint, but we plan on it being the final change we make before the semester ends. Once we can verify that the authenticateAndSave method is called correctly, the back end will be complete and users will have the option to store their credentials for offline use later.

Members of our team also made edits to the online tracker component, wrote tests for the checkbox functionality, and documented the progress we’ve made so far so that whoever continues the work after us can better understand our choices.

I thought our teamwork was excellent this sprint too. George identified to Luigi and I the parts of the code he’d written which in conjunction stored the user credentials in localStorage. Luigi and I were able to complete separate parts of the checkbox back end task and then integrate them.

I definitely could have benefited from a more in-depth knowledge of HTML and JavaScript this sprint. Following this course, I plan to set aside some time to dive deeper into these and CSS, so that in the future I won’t get blindsided by problems like the one I’m facing trying to get my checkbox element recognized as the appropriate type. I do feel like my skills are steadily improving and that this course has aided that. I look forward to having more opportunities to grow as I begin my career.

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