Author Archives: erik

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));

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.

Dig Deeper


You keep running into difficulty maintaining the code you’ve written because it turns out that the tutorials you followed cut corners and simplified complex issues. You find that your superficial knowledge of a thousand tools means you’re always floundering whenever a subtle bug arises or you have to do something that demands deep knowledge. People often accuse you of having a misleading CV because you don’t distinguish between a couple of weeks of extending an existing web service and a deep knowledge of the issues inherent in maintaining an interoperable and highly scalable enterprise system. 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.


The solution the text offers is to “dig deep into tools, technologies, and techniques. To acquire the depths of knowledge to the point that you know why thing are the way they are.” Depth meaning you understand the forces that leads to a design rather than just the details of the design. Areas where you have deep knowledge feed your confidence and allows yourself to apply your value early when on a new team. Having the background knowledge of how things work gives you the ability to fall back onto that to tackle difficult challenges and allows you to explain the inner workings on to tools and systems you are working on. This knowledge will help you in interviews, setting yourself apart from others because you can explain how a system or tools works. Using primary sources is the best way to understand the deeper workings of things, you can follow the trail of information that leads you to the decisions made along the way and why they were chosen.

This pattern is overall good advice for anyone who want’s to be a software craftsman. It’s important to Dig Deep into something you are passionate about. You don’t have to know everything about programming and software design but you should know a good amount about a few important areas. The ability to fall back on that background knowledge keeps you from struggling to understand new concepts, and makes you an asset to any team because you understand what’s going on beneath the surface. With this knowledge you can help others by explaining things in a clear way. Doing research and looking into primary resources allows you to get to the core of the information. It takes time to learn how things work but the benefits are worth it. This pattern will definitely improve my professional career and ability to help other understand deeper concepts.

The post Dig Deeper 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.

Use the Source


Without exemplars of good practice to study and emulate, the Practice, Practice, Practice pattern only entrenches the bad habits you don’t know you have. If you never walk a mile in someone else’s moccasins, you may come to believe that all shoes are meant to have stones in them. So how do you find out if your work is any good, given that those around you may not have the ability to tell good code from bad?


The solution the text offers is to seek out other people’s code and read it. Start looking into applications and tools you use every day. It allows to you to learn how other professionals write code, and the thought process behind creating the infrastructure you’re using. When examining open source projects, it’s best to download the most recent version and preferably from the direct source so you can inspect the history of commits and track future updates. Learn the codebase and how the files are structured. Think about how you would have done things differently, and if maybe you should rethink the way you do something because someone might have a better solution.

This pattern has good tips on learning from the source. I liked the idea of starting with tools and applications you work with every day, I think starting with open source projects is a great way to learn how current professionals are writing code and what practices they are utilizing. You may find things you disagree with and things that make you re-think how to approach a problem. I think it’s also good advice to seek out others to read code you’ve written and have them offer feedback. It refreshing to know that so much content is available open source, and it can give people like me access to real working programs that I can learn and possible contribute to in the future. I like the idea of looking into sites like Git, Subversion, and Mercurial and learning how these projects work, and what design patterns and algorithms they are using. I believe reading and understanding open source projects will make me a better programmer, and will help me greatly in my professional career as I continue to add to my toolbox of best practices.

The post Use the Source 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 Retrospective 5

This sprint I learned a lot more about encryption services and typescript in general. Encryption using Javascript is not the best choice, especially in an open source project but I feel the solution we have will do the job and securely encrypt the data in the more secure way we can. I learned there are many solutions to our problem and a lot of solutions may be outdated or not maintained. We chose Crypto-JS to hash passwords and encrypt and decrypt data, it’s a popular Javascript crypto library and has an MIT license. The last update was a year ago but still feel this properly accomplishes what we want. I noticed there are a lot solutions for Javascript but not many are implemented in Typescript. I learned quite a bit about translating from Javascript to typescript and was able to implement a solution for an encryption function in a typescript service file. I learned more about testing in Angular 2 but still am having some trouble with tests. I will keep on focusing on writing good tests that comply with the Ampath standards. I enjoy getting to work on something that’s actually used by people, and will help people do their job. It’s nice to get experience working with a real web application that uses Javascript and APIs. I feel this will help me in my professional career, and will help the Ampath team improve their project.

I felt the team worked well during the sprint. We have all been having problems keeping the web application working and it seems to break even though the local files have not been touched. We all have the application working now and are on to writing the functions needed for the other teams to utilize. We have split up the tasks amongst ourselves and will hopefully have a working solution by the end of the the next sprint. I don’t see anything stopping up from completing the tasks, and we got the O.K. from Jonathan on the Ampath team on the encryption API interface. I am currently working on the encryptRecord function and am utilizing Crypto-JS for that. I have a function now that I think will do the job but still need to work on my angular 2 testing skills to make sure the function will work properly.

We began the sprint with the intention of creating an encryption service file that has the following functions: hashPassword, a function that hashes passwords with a salt when the user logs in. clearLocalSalt, a function that will clear the local salt generated at login, when the user logs out. encryptRecord, a function that takes data and a private key and encrypts the data for save local storage. decryptRecord, a function that takes the private key and encrypted data and decrypts it for when the user is connected to the internet. Now that we have a clear path and the O.K. from the ampath team, we can concentrate on our individual tasks and work the offline login team for assistance in generating a salt with a username and timestamp.

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

Record What You Learn


Those who do not learn from history are doomed to repeat it.


The solution the text offers is to keep a record of your journey in a journal, wiki, or blog. Having a chronological record of the lessons you’ve learned can help those you mentors you, it can also be a vital resource to draw upon when needed. Those who follow this pattern sooner or later realize they’re trying to solve a tough problem and use what you’ve recorded to solve the problem. Try to avoid writing lessons down and then losing the information and forgetting to keep it updated. An example the text offers is someone who keeps a wiki for his private thoughts and the other for sharing with the world.

I think the pattern is good advice, I like the idea of keeping a blog to update as I start my career as an apprentice. I liked the idea of having two wikis, one designed for personal use and one to share with others. Having a more personal blog or wiki allows you to be painfully honest with yourself and the progress you’re making. Having something to go back to and refresh yourself has many benefits and can help you in a bind when you might not have anyone to ask. I keep cheat sheets at the current job I work and having that information saved makes my job much easier. Another good suggestion from the text is creating a textfile or page on a blog or wiki to save tidbits of information or quotes from software craftsmen, in the example the book noted, someone uploaded all their saved quotes online for others to learn from. I like how this patterns ties into the Breakable Toys pattern, you can start projects that you can share online, creating a chronological history of every step of the project, where things went wrong, and what you did to fix it. I think during my time as an apprentice I will continue to blog what I learn and keep the lessons I learn from mentors and colleagues. I like the idea of Sharing What You Learn, a lot of the lessons I’ve learned have come from other people who’ve taken the time to create blogs posts or YouTube videos describing the steps they took.

The post Record What You Learn 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.

Kindred Spirits


Organizational cultures that encourage software craftsmanship are rare. You find yourself stranded without mentors and in an atmosphere that seems at odds with your aspirations.


The solution the text offers is to keep your momentum going, there will be times when you may not have access to a mentor so you must keep in contact with those who are walking a similar road you are, as well as seeking out others who may be looking to excel. The Long Road is not something you walk alone, some relationships are short and effective, others are long lasting, and help nurture your passion. Though there are many benefits of a community of like-minded people, you need to be wary of group-think. It’s O.K. to follow the crowd sometimes but must always remain vigilant and question something when you feel it’s important.

This pattern is a good reminder to always try to keep people around that you can rely on to share experiences and learn from each other. I think it’s interesting you can have mentors all over the world, you may have never even met in person but you have a connection because you are walking a similar road. Having a Kindred Spirit to talk to, to take a break from the 9 to 5 work and share something that may be new or interesting. The dynamic is different because you can share what you know without coming off as a mentor you should follow. Kindred Spirits reminds me how important relationships are especially with the people you work with, as they can be great resources especially when you need advice on something work related. Having a community around you is another good way to ensure you have kindred spirits, and I like the idea of healthy debate, to keep the community fresh and healthy. I like that the pattern encourages finding those in community who may have a broad interest in software development, but then slowly find those who may have a particular niche that you may benefit from. Knowing those with obscure knowledge can help you when you if you ever find yourself in a situation where you are working on something unfamiliar.

The post Kindred Spirits 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 Retrospective 4

During Sprint 4, our team worked individually on different encryption libraries to gain a little more insight into the quality and usability of each one. I continued to research WebCrypto API and found the performance of the library to be much faster than other encryption libraries.

The test platform was a MacBook Pro (MacBookPro11,5) with a 2.8 GHz Intel Core i7 running MacOS 10.13 Beta (17A306f) and Safari Technology Preview 35.

On the WebKit blog, authors noted what they thought the disparity was caused by, “Working with our JavaScriptCore team, we learned that the causes of these pure JavaScript implementations not performing well is that most of them are not actively maintained. Few of them take full advantage of our fast JavaScriptCore engine or modern JavaScript coding practices. Otherwise, the gaps may not be that huge.”  WebCrypto API also boasts better security models and gives an example why: “When developing with pure JavaScript crypto libraries, secret or private keys are often stored in the global JavaScript execution context.” Noting this leaves users extremely vulnerable as “keys are exposed to any Javascript resource being loaded”, and allows XSS attackers to steal the keys. WebCrypto API protects the secret or private keys by storing them completely outside of the Javascript execution context. Implementations on MacOS and iOS are based on CommonCrypto routines “which are highly tuned for our hardware platforms, and are regularly audited and reviewed for security and correctness.” They go on to say WebCrypto API is the best way to ensure the highest security protection. WebCrypto sounds like a great resource for quality encryption services but there are others that perform the same tasks and can do what we want securely. The team has decided to focus on CryptoJS, which in this case I don’t think performance will be a big issue, but will keep this information close because I may need it in the future.

I feel the team worked well during this sprint and learned a good amount amount each library. Respectively we worked on bcryptjs, webcrypto api, pouch-db/crypto-pouch, and forge. All options seemed to get the job done but felt that CryptoJS suited our needs the best, while still keeping in mind the Ampath team might have a different preferred encryption library. We all learned more about encryption, Javascript, and the use of Typescript services. My personal interest in security and encryption has increased after working on this project, and all the news we see every day about the privacy of consumers data being compromised.

The first week of the sprint, I spent researching WebCrypto API, looking for a solution to implement that into ng2-amrs. I found documentation but not many examples of how to implement it in Angular 2. I found examples written in Javascript but had trouble getting things to work. I found it difficult to  translate Javascript into Typescript, and how that is going to used in a Typescript service. While meeting with the team we decided that while the encryption libraries we all tested has their own pros and cons, we decided that CryptoJS best suits what we need to get an encryption service running. CryptoJS has more a little more information on how to implement what we need to get our encryption service running.



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

The Long Road


You aspire to become a master software craftsman, yet your aspiration conflicts with what people expect from you. Conventional wisdom tells you to take the highest-paying job and the first promotion you can get your hands on, to stop programming and get onto more important work rather than slowly building up your skills.


The solution the text offers is to first accept that what you want to become might be strange to others, and second to always think in the long term. Value learning and long term growth opportunities over salary and traditional notions of leadership. By focusing on your long term development, you are enriching yourself with a set of skills that aide learning, problem solving, and developing strong relationships with your customers. Keep in mind the length of your journey, if you have 20 years of work ahead of you, you have plenty of time to master your skills. The text mentions that this pattern is not for someone who wants to become CIOs or product managers, or filthy rich. Thankfully the software development field is constantly changing and new opportunities are always available.

I think this pattern is a good grounding for anyone who may be a little too ambitious, and may take promotions without understanding how this may affect the Long Road. Unfortunately, sometimes taking a promotion means a break from learning, and while you may be making better money, you may be setting yourself up for failure down the road, or at least you want have the same skills and knowledge you would if you continuously worked on being a software craftsman.  I do think it’s important to always consider the Long Road, where you are in your career and what kind of job you want. I think this pattern is subtlety saying that taking jobs as mangers or corporate executives may not be as rewarding as working on their craft their entire career. This pattern is a good reminder to me to keep the long road in the back of my mind and focus on always putting myself in a position where I can learn new things and hopefully avoid burn out.

The post The Long Road 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 Retrospective 3

During sprint 3, I worked more with encryption services and Webstorm trying to create a working an Angular app that encrypts and decrypts data using Webcrypto API. I have been researching the Webcrypto API for some time as it is completely new to me, including Javascript. I learned that there are not many Angular related examples of the Webcrypto API but I did find an example using Crypto JS that I am also interested in and I believe it will help me understand cryptography and how its implemented in Angular.  This resource had a lot of good information including why Webcrypto API is a good choice.

  • WebCrypto offers protection against overwriting (in Chrome), since window.crypto.subtle is read-only. This is good news for security but bad news for usability, because it makes it harder to work with polyfills.
  • Non-extractable keys make it very hard for attackers to steal your keys. Therefore, the “JavaScript is always insecure” issue is mostly resolved. You can create a key, store it at the client, and use it. But if you don’t specify it, you can never read the key, which means that attackers cannot do so. Tip: Use IndexedDB to store the keys.
  • WebCrypto uses SSL only (with the exception of localhost and extensions) which ensures that the data sent between the web server and the browser is encrypted and secure.

I think the team worked well on the day we were together in class. We missed class because of the weather and that was unfortunate because I feel more accomplished when I get to work with my team face to face. I am working hard learning about encryption, how it works, and what the current standard for secure web encryption is so we have a good path to start after getting the o.k. from the AMPATH team on a direction to go. I believe we are all learning something new about web cryptography, as we are all focusing on different javascript libraries. I plan to bring what I learn from the Webcrypto API to the team and allow us to make an informed decision on what encryption library we should choose.

During spring 3, I spend most of my time researching Web Cryptography API, including webcrypto-examples on GitHub. I’ve been using what I learn from the documentation and examples to get a working implementation on an app of my own to help the team move forward in creation of an offline module. I started focusing on the Webcrypto API because it seemed like a good starting point as it’s a popular javascript library that outperforms others significantly. The algorithm I am focusing on is AES-GCM, “the symmetric block cipher ratified as a standard by National Institute of Standards and Technology of the United States (NIST)” During the latest sprint meeting the team, we decided to keep working on our respective projects implementing an encryption service, once we meet after spring break we will began to make a game plan as to what to pitch to the AMPATH team.

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

Sustainable Motivations


Working in the trenches of real-world projects is rigorous, sometimes tedious, sometimes exhausting, often frustrating, and frequently overly chaotic or constraining.


The text suggests ensuring your “motivations for craftsmanship will adapt and survive through the trials and tribulations of The Long Road.” You must develop your technical skills because you will often find yourself working with “ambiguously specified projects with customers with shifting and conflicting demands.” There are times when you’ll love your job but there may be days, weeks, or months when you may question you motivation to the craft. Your job will present you with tedious, vague defined, and needlessly complex problems and you may have to deal with bureaucracy, difficult personalities, and spotty leadership.

…there is not much overlap between the kind of software that makes money and the kind of software that’s interesting to write…. If you want to make money, you tend to be forced to work on problems that are too nasty for anyone to solve for free.

—Paul Graham, Hackers & Painters

In More Secrets of Consulting, Dorset House, Jerry Weinberg describes this phenomenon as the Golden Lock: “I’d like to learn something new, but what I already know pays too well.” The risk of the Golden Lock highlights the importance of The Long Road, which requires ambition to attain mastery.

I think this pattern has good insight on maintaining motivation to become a software craftsman. It had some interesting examples explaining why you should avoid getting stuck in the Golden Lock, where you may find yourself not enjoying what you do but may stay there because you are making good money. It’s important to keep balance your passion and other aspects of your life, this ties into the “Nurture Your Passion” pattern. Another good tip from the pattern is the importance of developing your skill because you will be working with a variety of people who may not understand things at the same level or might make your job harder. I believe this pattern will help me in my professional career, it’s a good reminder to learn new things, work with different people, and to sustain my motivation to avoid burnout or Golden Lock.


The post Sustainable Motivations 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.