I am writing this blog post about the “Be the Worst” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of the pattern, it is about trying to be in the presence of people with more experience than you so that you can learn from them, as opposed to being experienced already and not having the opportunity to learn from others. I can see this being a useful way to learn, but at the same time it does seem a bit selfish to put your own education above the quality of whatever it is you happen to be working on with everyone else. To be the worst may indicate that you do not actually belong where you are while you exploit the opportunity to learn. If this does not turn out to be a concern then it is still the case that you would not be performing as well as anyone else, so it may be discouraging to have a responsibility and not be prepared for it. Maybe being the worst is taking it to the extreme, but the more general goal of not being the smartest person in the room is a good way to learn from the person who does have more experience. I have been programming in the same language for the last decade and I now know everything about the language down to the exact differences between each version, and that came from being involved with other people who had knowledge that I did not have. Now there is no learning opportunity after having mastered this language, so since I have not nearly the same level of experience in any other language, it would be a significant learning opportunity to surround myself with experts in another language that I intend to become versed in. Since I have learned everything I needed to know to do the things I want to do, I have stopped learning at the same rate. Moving forward into a career, I expect it will become necessary to be just as experienced in more languages, so engaging with experienced programmers who use those languages will be beneficial.
Not a lot has happened in the last two weeks. There has not been a clear assignment given to be accomplished individually or as a team. On the first class meeting of this sprint, I helped Matt get through the final errors to get the ng2-amrs, since he was seeing the same errors that I had seen and figured out how to get through myself. After installing the right version of node, and then following the determined steps to fix the series of error messages that come up after trying to run npm start, it says compiled with warnings and does not error and the AMPATH login page comes up when visiting localhost:3000 in a browser.
From watching the first of the six AMPATH videos that we were sent, it looks like we are being given an existing user interface and it is up to us to implement the desired logic and behavior to have it interact with the medical records back end. The videos walk through some of the buttons and elements that were already placed together on the front end, and some specifics are described about what the elements are supposed to be for and how they should interact with the medical records data. From here on, we will finish watching the rest of the videos to better understand what they explain and what is expected of us, and we will have to decide among the other teams who is doing what, and figure out what it is we are actually going to be doing and how to do it. From what I have understood so far, I think that we are going to need to read a lot of the code that has been written so far, and then while we are writing more code to implement the new front end features, we will be referring to the existing code in order to find out how to access or manipulate certain data and objects. Depending on the amount of documentation that exists, it is possible that we may need to come up with our own documentation just to keep track of how everything works. I think that our previous experience programming in typescript during the last semester should be helpful while writing the code for this, although this does seem like it is going to be significantly more in-depth in certain areas.
This past week has been about trying to get the ng2-amrs environment working, and trying to get through the errors that show up when running the npm start command. I have learned a lot of the steps to take in order to approach this problem, although I am still not finished with it. I am not sure that I would proceed differently, I just think it would have been better if these problems were already known, since everyone is having them, and it would have been better if there were more instructions to deal with these expected problems. Most of the approach involves googling error messages, which can definitely be applied in other situations.
Most of the week was spent looking up different npm, ng and node commands, googling error messages, and trying different combinations of the commands and re-installing things after nothing worked. The reason that I took these steps is because I really do not know what I am doing and running through permutations of commands seems to be the only way to move forward to get the program to run without errors. A lot of the process involved referring to the slack channels, where teammates and other teams have run into the same problems and found solutions.
The ng2-amrs readme on the github page says to run the ng serve command for a dev server. What it does not say is what to do when this does not work. A guess at the problem involves version issues with angular, npm and node. Different versions were attempted to try to solve errors. Most of the steps involve googling the error message, which leads to a stackoverflow post that says to install a certain thing that solves the problem. When it does not solve the problem, it becomes very unclear what to do next. Changing versions and re-installing things has not seemed to work.
I have deleted and re-cloned the ng2-amrs folder from github. When I run the ng serve command, I currently see an error Could not find module “@angular-devkit/build-angular”. I google this and stackoverflow tells me to run npm install –save-dev @angular-devkit/build-angular. After I do this and re-try ng serve, a few more errors show up that do not seem to be as easy to deal with. One teammate found npm-check that will list missing things and things that are out of date, so I installed and ran that and had it automatically install everything it found using npm-check -y. After that finished, I re-tried ng serve, and it came back with a new error about styles.scss. I searched the error and found a command npm rebuild node-sass to deal with it. Running ng serve again, now I get some typescript errors. I check the group slack channel and see the command npm start, so I try that, and the next error I see is Error: Can’t resolve ‘pouchdb/dist/pouchdb’. I try running npm install and that brings back the scss error, but this time the same command that fixed it before does not fix it anymore, and it complains that I use a 64-bit operating system. I downgraded to node 8.12.0 and re-tried fixing styles.scss and running npm start. It actually seems to be working now. It says compiled with warnings, I open localhost:3000 in my browser and the ampath page comes up.
I am writing this blog post in response to the The New Yorker article “Why Doctors Hate Their Computers” by Atul Gawande. I thought that it was an interesting story. In general it seemed to be a look into how doctors and other medical healthcare workers are fed up with the poorly designed software that they are being forced to use. Some shorter stories about scientists and engineers are also included, and they have similar complaints, which shows that this is not just a problem among doctors using electronic medical records systems.
The main problems that seemed to make the doctors’ jobs harder was the fact that the programs required them to fill out excessive amount of detailed information before they are able to move forward. Their workflow is being interrupted and they are unable to do their job in the same way that previously worked well. The new computer interface may have streamlined some of the process, but it became too bureaucratic and inflexible. The fact that some of them decided to work with the I.T. department to hack the system and write their own better interface was not surprising given how much complaining came before that. It is obvious that the users of the system are not the real customers. The real customers – the people who made the decisions about how the program should control how the doctors work – seem to be the hospital administrators. They worked with the software engineers to design a program that forces the doctors to pay more attention to what they need the doctors to do for them, instead of what the patients need.
I do not think this article will change how I work or how I think about the things I make at the moment, but that is just because I am not making any sort of widely used software for important applications like medical records systems. In the future, though, I might recall this article if I happen to be working on some software application that has a variety of different users with different needs and I am given only one perspective. I imagine the developers of the system that the article is referring to might have been wondering about some of the user experience details. If they recognized that the users of their software are not the same people as the ones telling them how to make the software work, then they might have already had some concerns of their own that they were not able to address because the users, the doctors, are not the ones in charge of how the program they are going to be using is going to work. Something I do wonder because of this article is about how these problems can be avoided.
The first chapter and the next five chapter introductions draw an outline for a general guide to how to learn. The relevance of software development or of the term “software craftsmanship” seems to go away after the first chapter, where the rest is just about self improvement and how to learn. I agree with the points being made in each chapter, but I am also recognizing that these ideas seem to extend to literally every field of study, and not just software engineering. Throughout most of the reading, I was actually thinking about mathematics and not software development, and the ideas apply just the same.
I think that chapter 5 seems to be the most relevant to me. I know that I have learned a lot already, and I am also aware that there is a lot more that I do not know, and even more that I am not even aware of. There is a lot of content to learn about that I find interesting, and I always seem to find that I am preoccupied with other tasks such that I am unable to spend as much time looking into new interesting material as I would like. I started reading the beginning of chapter five just as I was thinking this, and the chapter opens with a quote, directly relevant to that thought, about how there will always be some distraction from learning, so it is necessary to seek knowledge anyway even when the conditions are unfavorable.
I think the idea of “emptying the cup” from chapter 2 is also relevant. Chapter 1 mentions that somebody may recognize that they are at the beginning, as a newcomer to software development, even if they have already been programming for several years. I think it would be likely to have been exposed to some software development projects and practices during the “several years” of programming, so the term “beginner” does not seem to fit very well for somebody with that much experience. On the other hand, somebody who has been actively learning to the extent described within these chapters will definitely have transcended their level of experience. The idea of a “full cup” comes into play when an experienced person is not inclusive of further experience and knowledge. There is the expression about teaching an old dog new tricks. It is necessary, in order to learn, to actually want to learn.
I can see myself applying the principles in these chapters more so toward my mathematical education than my software development education, only because I am more aware of what I do not know in regards to mathematics. I expect that the focus should shift more specifically toward software development in later chapters; knowledge of careers and how software development works on the level of employment is much less familiar to me than the computer science component of software development, although there is still much more to learn in computer science alone.
I am writing in response to the blog post at https://www.guru99.com/software-testing-seven-principles.html titled “7 Software Testing Principles: Learn with Examples”.
This blog post highlights some useful general guidelines for software testing. In order to write effective test cases, it is important to follow some logical approach toward determining what to test for and how to test it, and this is a guide that describes such a set of principles to follow that are well suited to capture the logic involved in software testing.
The first principle is that exhaustive testing is not possible. I am not sure I believe this. In general it is useful to assume there exists no perfect test, but for simple enough applications where the number of possible interactions are enumerable, I would think that it would be possible to achieve exhaustive testing, much like an exhaustive proof, where every possible path is covered and verified. Maybe I am missing the implausible event that the test is correct but the computer running the tests is corrupted in such a way that certain tests are not run. This is relevant to a point made in this area, which is risk assessment.
The second and third principles make similar points. Always running the same tests will eventually not cover certain issues. If all of the same methods for testing are always applied exactly the same, then eventually there will be some scenario which the particular method is not suited for, and it will miss something. This leads into the later principles: the absence of a failure is not proof of success, and context is important. Developing tests suited for the particular application is necessary to ensure the correlation between tests passing and the program functioning correctly, and just because every test passed does not mean the program is going to work perfectly.
This set of software testing principles can be summarized in a few basic points. Develop test cases that are well suited specifically for the application that is being tested, consider the risk of certain operations causing a failure, and do not assume that everything works perfectly just because every test case passed.
I am writing in response to the blog post at https://www.shiftedup.com/2015/05/07/five-programming-problems-every-software-engineer-should-be-able-to-solve-in-less-than-1-hour titled “Five programming problems every Software Engineer should be able to solve in less than 1 hour”.
This blog post shares a story about a history of people who apply for the position of a software engineer and claim some loosely related skills without actually having any chance of understanding or performing the job. The frustration of the author is expressed, and the author lists five programming tasks to disqualify any supposed “software developer” who would not be able to complete them in under an hour. I attempted them myself and they only took five minutes.
I am not sure what motivation people have to apply for a job that they are in no way capable of performing, but the author of this blog post seems to be fed up with how common it is. Supposedly, though, people who do not know what programming is are attempting to become software engineers.
I think that the list of five programming problems and the time constraint of one hour is a generous filter to sort out all of the people who have never written a program in any language ever before. It certainly would not be enough to qualify for the position of a software engineer, but that is not what the problems are meant to indicate upon fulfillment, it is simply what they are meant to reject upon failure. Somebody who claims to be a “developer” and fails to accomplish these simple tasks should revisit their resume.
The problems themselves are very basic. Find the sum of some numbers using loops or recursion, combine elements in two arrays, calculate Fibonacci numbers, and the last two problems are more peculiar but still simple demonstrations of basic problem solving. It should be evident in much less than an hour whether a person is capable of solving them, and any experienced software engineer should only need ten minutes.
The blog post acknowledges some feedback about the last two problems that are a bit less conventional than the others, but I think that the ability to solve unconventional problems is important, and I think anyone who writes code in something besides a markup language or an object notation could solve them.
I am writing in response to the blog post at https://www.codementor.io/learn-programming/comparing-programming-paradigms-procedural-programming-vs-object-oriented-programming titled “Comparing Programming Paradigms: Procedural Programming vs Object-Oriented Programming”.
Object oriented programming seems to be the focus of all that is ever taught in a computer science course after the basics of syntax and control structures are covered, which are the basis for procedural programming. The shift into object oriented programming seems to mostly be for the sake of establishing proper design principles such as encapsulation and normalization to reduce redundancy, but these are not mutually exclusive features of the object oriented programming paradigm; it is still entirely feasible to write procedural code that is still “good” code.
The blog post does not directly define what procedural programming is about, but it alludes to the writing of straightforward code that makes use of variables, scope, functions and control loops. Then comes the brief anecdote of writing thousand-line long programs that start to become difficult to maintain, and how the object oriented programming paradigm is the solution. Object oriented design is definitely helpful for improving the scalability of a large program by introducing better organizational practices to the code structure, but the principles of encapsulation and modularity can be applied directly to the poorly maintained program anyway without changing paradigms. This is not to say that object oriented programming is bad or unnecessary, but the point is that procedural programming is not bad and does not need object oriented programming to “fix” it. Procedural code happens to be the most common poorly written code because it is most commonly used by beginners, who learn about better coding practices once introduced to object oriented programming.
Some of the faults with object oriented programming are described in the blog post, adding that it is not the best idea to avoid the use of procedural programming for the sake of adopting the exclusive use of object oriented programming. Modularity regarding class extensions and modification of a class can make things difficult in languages that focus on object oriented programming, where overriding a method or re-implementing a class may have adverse effects on subclasses. It is ultimately decided that multi-paradigm programming is a good choice, where the benefits of procedural and object oriented programming can be combined.
I am writing in response to the blog post at https://www.guru99.com/positive-vs-negative-testing.html titled “Positive Vs Negative testing”.
Positive and negative testing have some features in common with the details of boundary value testing that we covered in class. Robust boundary value testing, in particular, tests values not only on the boundaries but also inside and outside of the boundaries. Testing input values that are inside the boundaries is called positive testing, and testing input values that are outside of the boundaries is called negative testing.
The blog post confirms as much. Positive testing is about providing valid inputs and testing that the application behaves as expected. Negative testing is about providing invalid inputs and testing that the application does not do anything that it is not expected to do. Boundary value analysis and equivalence partitioning are listed as techniques for positive and negative testing. Testing input data that is chosen within the boundary qualifies as positive testing, and testing input data that is chosen outside the boundary is negative testing. Equivalence class partitioning has partitions that are also valid or invalid based on whether they are inside the boundary. Testing valid partitions is positive testing, and testing invalid inputs is negative testing.
“Positive testing” and “negative testing” are separate types of testing by themselves, but it does not necessarily make sense to only use one of them; they do not provide a complete analysis of the program’s behavior. Positive testing will yield no conclusions about the behavior of the program given invalid inputs, and negative testing does not verify that the program behaves as it is supposed to when it is given valid inputs. Boundary value testing and equivalence class testing are specific methods that use positive and negative testing, and the process of testing inputs directly falls under black box testing, which does not make the distinction between whether an input is categorized as valid or not, only whether the program behaves correctly. Doing both positive testing and negative testing will provide sufficient information about the behavior of the program to be confident about whether the program is going to behave correctly.