- 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.
- 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.
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.
You work in an environment that does not allow for failure. Yet failure is often the best way to learn anything. Only by attempting to do bold things, failing, learning from that failure, and trying again do we grow into the kind of people who can succeed when faced with difficult problems.
The solution the text offers is to build “toy systems that are similar in toolset, but not in scope to the systems you build at work.” Experience is build upon failure and success, having a more or less private space to seek out failures in order to learn from them. When implementing this pattern, the text suggests making your systems relevant and useful to your life as an apprentice. Suggestions include building a wiki, calendar, or address book.
“Breakable Toys is more about deliberately creating opportunities to learn by stepping beyond your boundaries and single-handedly building complete software projects.”
The projects you take on may be excessive and not complete but having the ability to fail, and find solutions trial and error will benefit you in the long run. Maintaining a wiki leads you to learn about things like HTTP, REST, parsing, web design, caching, full-text search, databases, concurrency, and possibly data migration. Other forms of breakable toys include games like Tetris and Tic Tac Toe, blogging software, and IRC clients. The intent of Breakable Toys is learning new things and allowing yourself to learn from roadblocks that might occur.
During Sprint Retrospective 2, I learned more about the OpenMRS REST endpoints that Ampath uses for it’s core services. I learned more about what the Ampath team is looking for in terms of an encryption service if we are using open source code. In general they are looking for stability: i.e. number of contributors, number of commits, recent activity, any big name (Google, Microsoft, etc), and adaptability. I learned there is a standard Webcrypto that most browsers use as a standard and that we should stick to that standard. I learned more about time planning, and the need to do a better job documenting what we are doing, and splitting up tasks for individuals to work on.
The team worked well, I’m more productive when we are all together going through the code on the projector. It’s nice to have others looking at the same material you are, sometimes they notice things you don’t and it helps everyone on the team learn. I try to participate and offer any tips or advice I might have. I try being prepared for the sprint by trying to understand what is going on and how the services on the application work. I think we need to do a better job documenting everything we do and making sure to share it with those who it might help, with the addition of the documentation thread on slack, it will make sharing that information easier. Next sprint I am going to keep a log of what I am doing, or ideas I have as a personal log to help me organize and write my sprint retrospectives. Now that we have more of an idea what our team should be focusing on, we can start getting into the details of implementing the encryption service and how that ties in with the other functions being added by other teams.
During Sprint Retrospective 2, our team organized our trello board and began to add tasks we thought we could complete during the sprint. We planned on walking through some of the ng2-amrs services, looking into the REST endpoints (with the postman app), checking out Balsamiq, and to coming up with design ideas for implementing an offline service for ng2-amrs. We started our work by walking through some of the services in the openmrs-api folder. We went through some of the endpoint in the OpenMRS Rest Web Services API wiki. We looked into the service that sets a users location, the patient search function, the offline / online indicator, and we began to see how those services work with the front end, and the OpenMRS api that performs a lot of the functions on ng2-amrs. We began to turn our attention to finding out how to implement a service that encrypts and decrypts data. We did some research online for possible solutions and found a few options that we shared with the Ampath team asking for their input: bcryptjs, forge, crypto-js. We are going to look more into forge because it seems to have the most activity.
The performance of your daily programming activities does not give you room to learn by making mistakes. It’s as if you’re always on stage.
The book suggests taking the time to practice your craft somewhere without interruptions, in an environment where you can feel comfortable making mistakes. Ideally we would use the technique “deliberate practice”, described in K. Anders Ericsson’s research: a mentor would assign you exercise based on their knowledge of your strengths and weaknesses. The mentor would help you evaluate your work and then you would work together to create the next exercise. The mentor would then use the experience of working with other students to create more challenging exercises that add small chunks of abstract knowledge that allows you to hone your strengths and correct weaknesses. Unfortunately we do not live in an ideal world and a lot of our practice on the job. The first example the text mentions is called “code kata”, which is essentially a practice session that some companies are starting to utilize for their teams. The text mentions another pattern, Breakable Toys, the ability to work on a piece of software in a stress free environment where you have control of everything. Finding new challenges and working on problems that are harder than you’re used to can help keep you master your craft.
The pattern had good advice and good information. The idea of having “code katas” seems like a good way to practice your skill and see what other people are working on. I think most developers do this already but the textbook mentioned the Breakable Toys pattern, where you take time to develop software in a stress-free and playful environment. I think it’s important to get periodic feedback, the text mentioned if you aren’t getting periodic feedback you could be developing bad habits. I think it’s important to always practice and find more challenging problems. I think having unique experiences with developing keeps an interest in the subject and avoids created burn out from seeing the same language or pattern you’re used to working with. Reading about this pattern has reminded me to try to always keep an interest in the subject by creating unique challenges, practicing, and seeking feedback.