I wasn’t sure if “Share What You Learn” would be applicable at my current level of experience for exactly the reason the writers give for why apprentices might have doubts about the pattern: I assumed this sort of thing should be left to people who know exactly what they’re doing. They brought up points I hadn’t considered in response to this. An apprentice’s minimal knowledge will make their explanations short and to the point, and they won’t make the mistake of assuming the people they’re sharing with have prior knowledge that they don’t. This makes their explanations, in some ways, more useful to other apprentices than an explanation from a journeyman or master.

The benefit to the apprentice sharing what they’ve learned is something I acknowledged in my blog on “Record What You Learn”: the best way you can learn something yourself is to teach it to someone else. The writers mention this benefit, but they also warn of several ways that applying this pattern can end up doing more harm than good which I hadn’t considered. Sharing your knowledge might get you into legal trouble if what you’re sharing is a trade secret, or sharing particular information may actually be harmful to others. You should be careful about what you choose to teach others, and if no one else seems to have explained it, you should consider why. Other concerns include that people might feel as though you’re bragging or explaining concepts in condescending ways if you’re not sharing with humility, or they might assume you have an ulterior motive. Conversely, the writers assert that it’s selfish to seek ways to better your own learning and not consider how others could benefit if you were to share what you know.

They suggest developing a habit of applying this pattern early on, but I still don’t feel like I’m ready to offer anything substantial. If in the near future I learn something I identify as significant enough to record it, I will remember to apply this pattern as well and write an introduction to the topic that others might find useful.

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

Our team is currently tasked with creating an offline password-encryption service for the Ampath application.  After consulting with the people at Ampath, we made the decision to devote this sprint to creating test-applications that utilize the 3 encryption-libaries we discussed with them.  Unfortunately, our meetings were interrupted again this sprint; 2 of our 4 meetings were cancelled due to snow.  The days that we did meet, we spent a majority of our time coding and discussing our progress.

I was tasked with creating a test-application that utilizes the encryption libary bcryptjs .  Bcryptjs uses salt and an adaptive function to improve security and its implementation purely in JavaScript provides resistance to brute-force attacks.  I was the team member who suggested bcryptjs, when we compiled options to discuss with the Ampath people, so it felt natural for me to be the one writing the test application.

I did run into some trouble, though –  all of the resources and APIs for bcryptjs are tailored to JavaScript, rather than TypeScript.  This has been quite an impediment for me as I am not proficient in JavaScript, so I have had to learn a bit of JavaScript at the same time as I develop this test-application.  We are using WebCharm to work on development for the application, and WebCharm has a tool to compile TypeScript to JavaScript, and I have been looking into whether it is possible to compile JavaSvcript to TypeSript.  As I mentioned earlier, 2 of our 4 meetings were cancelled due to snow and I was without power for 3 days of the sprint, so I was not able to troubeshoot and push through this problem in time.  The issue of being unfamiliar with JavaScript, as well as installation and compilation errors, has also been afflicting my teammates – nobody was able to produce a working test-application by the end of the sprint.  Spring break is coming up and, while we are not required to work toward sprint goals during break, I intend to try and get myself up to speed with Angular, JavaScript, and bcryptjs so that, upon our return to school, I will be ready to make a meaningful contribution toward meeting this goal for the Ampath organization.

It definitely felt like all the teams had much more direction during this sprint.  We have begun implementation and feel more familiar with the application itself.  Our team has been using our in-class meetings more efficiently and I think we all have more of an idea of each other’s working-pace.  I feel a bit worried about the fact that my teammates and I feel unsure of ourselves within JavaScript, because I think it will be hard for us to have to learn JavaScript at the same time as we work on the Ampath application.  I’m hoping that Spring break will allow us to gather ourselves and come back more productive than ever.  I have still enjoyed working on the application, so far, and I hope that we can make some sort of meaningful contribution(s).

From the blog CS@Worcester – by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.

The “Learn How You Fail” blog pattern is about finding the ways in which you tend to fail or make mistakes.  The solution does not claim to save a programmer from ever failing (that’s not possible), but is instead about learning what tends to lead you to failure.  It’s part of drawing accurate boundaries around yourself as a learner: figuring out where you can grow and improve, what tends to throw you off track, and what may not be worth the effort of improvement.  The authors have a very concrete action step to help: using only a text editor, write an implementation of a simple algorithm, write all of the tests, refine the algorithm until you’re sure it will compile and pass the tests, then actually try to compile and test it to see where you failed.

Learning my weak points, where I tend to make mistakes, is a big part of my life as a gamer.  I try to improve my performance (whether that’s technical gameplay, strategy, tactical decision-making, etc.) with every game.  A very important aspect of that is determining what kinds of mistakes I tend to make.  Where do I overthink?  Where do I underthink?  What can I take away from losses, and when is it worthwhile to acknowledge but let go of a weakness (at least for a while) to focus on something else?

This apprenticeship pattern also resonates with me for a different reason.  I struggled through much of middle and high school with a mild nonverbal learning disability.  It took years of practice and tutoring for me to really be able to work through it.  An important part of that (or, I think, any therapeutic process) was finding points of failure.  I struggled to express myself in writing, especially meeting word counts for papers.  I had (and still have) difficulty breaking focus or task-switching.  Recognizing these things was the first step to improving them.

I think that learning how you fail is not just a skill that’s important for software apprenticeship and craft.  It’s an important life skill; at least, it has been for me.

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

https://www.codeproject.com/Articles/524235/Codeplusreviewplusguidelines

This week is another blog post on code review. Unlike the other article which gives suggestions, this article is an overview of code review. So, what is code review? This article defines it as a systematic examination of programming language source codes. It main intent is to find and fix mistakes overlooked in initial development phase. This helps to improves the quality of the software and also helps give critiques on the developer’s skills, which is always an advantage to improving their skills.

Why are code reviews important? We start with some statistics. The article lists that the average rate for detecting defect is 25%, the rate found through functional testing is 35%, and that found through integration testing is 45%. In contrast, the rate of defect detection through code review is 55% to 60%, indicating that code review is one of the most important aspects of code review. The article further goes on to list some important statistics on code review that I thought were extremely interesting. Before code review were introduced into the organization, it is estimated that about 55% of one-line maintenance changes were in error. After its introduction it decreased to 2%. After code reviews were introduced it was estimated that 95% were correct the first time whereas before under 20% were correct the first time. In an experiment, a group of 11 programs were developed by the same group of people. The group were split into 2 groups. The first 5 developed without code reviews. The remaining 6 developed with code reviews. After its release into production, the first 5 had an average of 4.5 errors per 100 lines of code. The other team had an average of .82 errors per 100 lines of code. Reviews were found to cut the errors by over 80%, which demonstrates the importance of code reviews. For this study however, I wonder if for both teams the individuals had equal experiences and skills. Were both sides equally weighted? An interesting statistics is the IBM Orbit project. IBM’s 500,000 line Orbit project used 11 levels of inspections and had only about 1% of errors.

Finally, we close off this blog post with a discussion on the main goals of code review. The article lists the main intent to spot and fix defects early in the development process. The second goal is to share ideas with other team members, so that everyone can share from one another. Sharing ideas then helps to maintain a level of consistency in the design and implementation. Finally, code reviews helps to build confidence in the stakeholder about the technical quality of execution. Code review overall, helps to create more confidence and reliability in the product, since as a team it is easier to catch bugs.

Overall, I choose this article because I strongly believe a good code review is always difficult to conduct. It takes practice to be efficient. This article emphasizes the importance of code review in software engineering, but still it takes time to develop the essential skills to be effective in code reviews. That is why I chose this article this week to emphasize the importance of code reviews and to learn about its main intents and advantages in software engineering.

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

Knowing what you know

knowing what you don’t know

not having a means to discover what you don’t know

not knowing what means exist to learn what you don’t know

not knowing how knowledge acquisition works

can we answer these questions concretely or only philosophically?

What is quality?

one answer: How well the customer or user of a thing views it as useful/helpful

feels good to use it

easy to operate

know what it can do and can’t do and am happy with that

joy out of using it

customized, personal, based on individual

quality =/= bug-free

one piece of software has a lot of known bugs but is heavily used by thousands or hundreds of thousands of people, another one is bug-free but only used by 10 people, which is higher quality?

The context, its ability to solve a problem in that context,

does it solve the problem in the context in which we’re expecting to solve that problem, without unexpected consequences

chair w/out a seat is low-quality bc you expect to be able to sit on a chair. can’t serve its basic purpose

different chair with seat, but front right leg is 3 inches too short. Leaning back is fine but leaning forward you might fall on the floor. A higher quality chair wouldn’t “crash” like that

how delightful is it to sit in the chair

not just requirements or fitness for use

value to some person

–

what is a test case?

Specific action and outcome

thing u wanna try and a result you wanna verify

ex. post a message to slack, verify it shows up

1 dude argues it’s still one test case if you perform the action and verify the result across different OSes

any time inputs are applied to a program, outputs generated, and a judgment call made.

Judgment call might be different based on context

judgment calls are the hardest part of testing, and it’s based on your own definition of quality

–

what is testing?

1: Investigating, evaluating, learning, sometimes judging?

Vs

2: only judging, that’s what we hire testers to do

1: not only judging: giving new ideas for inputs and outputs

new ideas for tests can follow from results/judgment calls of previous tests

breaking things, discovering where things fail

identifying those judgment calls? The judgments that would put the product at risk

–

what’s a tester?

Keenly focused on risk-to-return

lowering risk on high-value quality propositions

–

what is integration testing?

Making sure all the pieces fit together

the tests you write to make sure other people don’t break you

input, output, judgment call = does your component still return the expected results that my component is counting on?

–

performance testing

inputs and outputs that let you know product is performing as expected

how long actions take in application over a variety of scenarios

key actions product takes and how long each of them takes in different contexts

output = time, judgment = is the time it takes acceptable/good?

Is faster always better? no. only has to be fast enough for the customer

easy to increase performance in the wrong areas. Make the parts that matter fast

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

A while ago (long while), I talked about an interesting post about the something called Test Ops in this post: https://fusfaultyfunctions.wordpress.com/2017/09/20/the-future-of-testing-taking-an-interesting-turn/.

Now I’d like to talk about a post by Awesome Testing describing an important topic in Test Ops, Testing in Progress. Essentially, its a set of ways of testing that utilizes real users and the different ideas and implementations that arise in a production environment. So how do you test a new feature or update produced for a service.

Obviously, the one metric is that it works without errors for the users. But the next most important metric, is the number of users it retains. The amount of people using the service and continuing to use the service is the most important thing for these applications. And this needs to be tested.

Now what do you do when you produce a new feature and need to test it? You could just throw it out into the wild and then see how the statistics work out. If it worked, keep it, otherwise throw it away. But that can annoy users and make you lose people.

There is no one best way, but there are several different ones used. There’s risks that need to be mitigated. So the first method outlined is Blue-Green Deployment, or Canary Deployment. You deploy the new feature or software on a separate series of servers, the blue pool. Preliminary tests are done, internal, users, and then if it looks good 5% of users are redirected to it from the original servers, the green pool. Then you can see how well the new software is working. If it doesn’t look good, move everyone back to the green pool.

Test Flights are similar. You hide a new feature in a code path, with another code path without the feature. By changing a config file, you show the new feature to users in the same manner as in Canary Deployment. First internal users, then lets say 5%. The feature can always be reverted with a change of a config file. A/B testing is a bit more extreme, essentially you have, say, two variations of an application. Fifty percent of users see one and the other, and the one that retains the most users becomes the finalized version.

There’s also a technique where faults are intentionally injects in software. In this way, it leads to a design that focuses on being secure. And then there’s one popularized by Microsoft. Developers are forced to use the applications that are being developed locally, to ensure the program is a reasonably good user experience.

Overall, it’s really interesting seeing the considerations required when dealing with testing new software. I never considered that not only would testing test for working product, but one that works well too. It makes testing a much more complicated, yet exciting field. It also makes the job of a tester much more integral to the success of an application.

Original Post: http://www.awesome-testing.com/2016/09/testops-2-testing-in-production.html

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.

The resource I discovered this week is partially a blog post, but mostly the mobile app that the blog post is about. The app is called Enki. It’s similar to the language-learning app Duolingo, but its purpose is to help people learn new software development skills in small chunks every day. The blog post explains why the app was developed: the options that currently exist for ongoing learning about software development take a lot of time, something developers tend to be short on. They can also be boring and inefficient. The app creators wanted something fun, engaging, useful, and quick. The mobile platform was selected so that users would always be able to have it with them, and therefore be able to squeeze learning into limited free time like a work commute or the time it takes for their code to compile. The daily lessons, called workouts, stick to small tips and bits of applicable information instead of getting bogged down in details that people who’ve passed the beginner stage probably already know. They’re also designed specifically with avoiding boredom in mind, so the workouts contain engaging challenges and game-like elements.

I chose this resource because it’s one of the only

books and video courses

Blog post explained why the app was developed

current options for [continuous] learning

they wanted something that could help you practice a little bit each day

Affected me immediately because I downloaded and started using the app. So far have only brushed up on html skills, but it seems interesting, and I intend to keep using it. It seems like a fun way to learn new things or to get a refresher.

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