Author Archives: erik

Use the Source

Problem

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?

Solution

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

Problem

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

Solution

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

Problem

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.

Solution

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

Problem

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.

Solution

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.