Since the last sprint retrospective, our group has been working to finalize everything that we have managed to get done so far. Most everything we do have to show for actually was created since the last sprint retrospective. Just about everything before then has been all about fixing errors, trying to understand Google’s material design and how to use it, setting up the development environment and fixing lots of errors. Another team had a working version of their component already, and our team was stuck on an error trying to get the styling to work correctly. The problem was that we were opening the component directly in the browser, just by opening the html file that has the component in it. There’s no connection between the styling code and the HTML code, so there’s no reason it would be properly formatted just from opening it directly, and that was the thing we were having a problem with. It turned out we had to use ng serve to start up the local amrs server, and then the component would show up correctly formatted after visiting localhost:4200. There were of course some more errors in the process of getting to this point, though, which I figured out through a series of Google searches and copying and pasting commands from stackoverflow answers from other people who had a similar problem. Since we got that working and were able to finally see our component correctly, we finished figuring out how to get Google’s material design template code integrated into the component, and then spent the last class officially adding our component to the main branch. The rest of the work we have been doing since then has been about preparing for the final presentation, recalling everything we have done so far and trying to allocate the material among all five of us to discuss when presenting. Most of the presentation is going to be talking about errors and the solutions to the errors and how the solutions to the errors were found. That is because most of this project has been about having errors, looking for the solution to the errors, having more errors with the solution, and then finding the right way to do things. Another portion of the presentation will be about setting up the development environment, which was a pretty big focus in this project. We spent the first couple of weeks setting up a development environment we never used, and then had to set up another development environment once we started working on the angular component. The rest of the presentation will be mostly about the actual programming of the component; what it is, what it is supposed to be for, and what further problems were had in developing it.
This class is very different from any other class I have had before, mainly because the whole time there was never a clear idea of what anyone is supposed to be doing or how anything is supposed to be done. It all seems to have worked out in the end, though.
I am writing this blog post about the “Retreat into Competence” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about handling being overwhelmed by new challenges. This is something I experience frequently, particularly because I actively search for new challenges and often find ones that are beyond my current ability. The recommended response is to go do something else that is more familiar instead. Succeeding at something familiar and reflecting on past success is comforting in the face of overwhelming ignorance. There are two definitions of the word “overwhelming” that I can imagine here, and the one that this chapter seems to be using is in an emotional sense. Recognizing one’s own incompetence is uncomfortable, so taking a moment to go back and successfully complete a familiar task feels better than struggling with an unfamiliar one. The other definition would be being overwhelmed in the sense of lacking the capacity to complete the given challenge. Retreating into competence is done for the sake of regaining confidence, and it is important to be able to handle being emotionally overwhelmed before trying to handle being academically overwhelmed. I have confidence in myself and my abilities, but when I am challenged by something new, I remain confident in what I know and recognize that it is a challenge because of what I do not know. I was doing a problem recently that required a certain background knowledge of combinatorial game theory that I did not have. Despite my aptitude for problem solving, my lack of education on the matter made the problem challenging (or overwhelming) to the extent that talent would not make up for inexperience. I saw it as a learning opportunity and started researching the information that I was not familiar with, and also did some easier problems instead that did not require a level of education I was lacking. Remaining in one’s own comfort zone is a good thing, but only briefly, as the chapter notes. It is taking a step backwards in order to prepare to continue moving forward and learning.
Since the last sprint retrospective blog post, our team has struggled to get the component we have been working on to show up correctly. It has been determined that the formatting code will not be applied to the component if it is just opened by itself in a browser. It is necessary for the amrs server to be running first, and then the component will show up at localhost:4200. We made progress once another group had us make a copy of their component and try to get theirs working for us, since they already had it working for them. I ran the commands cd amrs-simple-app, cd ampath-simple-app, git, checkout Tabs, git pull origin Tabs to make a copy of their component. Then I tried ng serve, and that errored, so I googled the error and found the solution and entered the command npm install –save-dev @angular-devkit/build-angular, npm audit fix, ng serve –prod, and then it worked. I waited for it to say “Compiled successfully” and opened localhost:4200 and the component showed up, correctly formatted.
Since that is out of the way now, we should be able to actually finish the one component we have been trying to get working for the last month. We should probably be able to do a second component, too, since the thing that has been holding us back the whole time has been solved. Now we can go back to our component, apply the solution that worked to display the other team’s component, and finish getting it to work and move on with the project.
I am writing this blog post about the “Expand Your Bandwidth” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about learning about a greater variety of topics than just what tends to be the most relevant. The chapter describes the problem as having a narrow understanding of software development that focuses only on the low-level details of past work. The solution to this is to just start learning about different things. I think that this is a relevant concept that I seem to be dealing with at the moment. My specialty is computer science, and I have a deep understanding of many of the fundamental concepts in computer science. Software development, though, involves much more than just computer science, and I have not researched software development beyond researching computer science. The problem here is that I have a narrow understanding of software development, and the solution is to research the other topics that are important to understand besides computer science.
I think that this chapter relates closely to the “Concrete Skills” apprenticeship pattern. The main difference is that this assumes you already have a full set of skills that are already being applied in a day job, and “Concrete Skills” is about developing those skills in the first place. I have not yet begun a career in software development, though, so these problems are effectively the same. I have a narrow understanding of software development, and this narrow understanding is a set of concrete skills.
There are often times that I do research new and unfamiliar concepts, but these tend to be concepts that are still within the field of computer science and not software development. I do have a goal of learning and understanding more, and there are a lot of topics that I find interesting enough to read about, develop some experience with and practice applying. This book constantly emphasizes the importance of a willingness to read, practice, research and learn, but it puts an equal emphasis on software development. My concerns should be lessened by just applying myself more toward software development in particular.
I am writing this blog post about the “Concrete Skills” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about dealing with concerns about seeking a role on a team but not having any practical experience. I chose to write about this pattern in particular because I find it relevant to myself at the moment. I am searching through job descriptions and they all seem to prefer certain areas of experience that I do not have. This is also evident in our capstone project. The “solution” section of this chapter in the book says to gain some concrete skills. I do have concrete skills; my aptitude is for mathematics, data structures and algorithms – computer science in general. It refers specifically to “tools” and “technologies”, though, and I know nothing about that. It becomes apparent when I work on the capstone project that my expertise has no application here. This sort of computer programming has nothing to do with computer “science.” There is no logical problem to solve, there are only tools and frameworks to learn how to utilize in order to accomplish some basic tasks. My past experiences have not seemed to have prepared me to be any better than anyone else at approaching these problems. It seems, then, that the “concrete skills” that I need are of a different sort. The chapter recommends looking at the CVs of others and finding a common set of discrete skills that seem important to become familiar with. This seems like a good idea. In order to gain some level of confidence about being able to perform on a team, it would be helpful to become familiar with the skills and common knowledge among the demographic. Rather than continuing to study computer science, there seems to be an additional field of knowledge that I am unaware of a name for, which is comprised of tools and technologies that are required for certain software development tasks. It seems like it will be important for me to gain some “concrete skills” in whatever field it is this might be.
Since the last sprint retrospective blog post, our team has begun to work on some of the components described in the first video. We are referring to the template wire frame layouts from the Zeppelin website, and we are working on form 1d in particular. It is still not very clear how to move forward and what to work on; the only way to make any progress is to keep focusing and thinking about what can be done and what to try looking at. The Angular Materials Design seemed to open the way into making progress. It established a much clearer way to begin the actual programming part of making the components. Everything we have done up to this point seems irrelevant now, but now things seem to be picking up in pace.
I have not begun writing any code myself, so my goal for the next sprint is to start writing code and finish an actual component. With the new angular materials design tool we are using now, this should be doable, since a lot of the code just comes from there, and it’s just a matter of implementing it by changing some small details. Progress has been slow, but progress is being made. I tried looking through the material design code to get started on the 1d form, so I tried copying out the template code and running it, but the CSS does not seem to be working. There was a series of errors that were resolved by installing a few things, and after getting through all of them and opening the webpage, the page shows up with the component in it but without any formatting or styling. The HTML code uses some made-up tags, and the angular code is meant to interpret it and apply the styling code, but there is not anywhere in the template HTML code that actually refers to another file that would be needed to interpret it. I do not know how this is supposed to work or how exactly this code is intended to be used, so a bit more research and testing and trial and error is required in order to get it to work.
I am writing this blog post about the “Expose Your Ignorance” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about making known what it is that you do not know in order to learn. People have a tendency of wanting to appear competent and knowledgeable about any job that is expected of them, but faking expertise is counterproductive. It is more helpful to seek knowledge than it is to hide ignorance. I have been looking at job descriptions lately, and many of them are filled with expectations and preferences referring to things I have never worked with before or have minimal experience with. My aptitude is for algorithms and data structures; I have studied and developed and implemented them a lot, for years. When it comes to “technologies”, though, I do not know anything about software development. There are so many languages and frameworks and libraries and acronyms that I am not familiar with because they have never been necessary or relevant before, and now I see that a lot of jobs are expecting proficiency with these tools. I am used to solving problems without extra tools, so in order to work in a new environment where an unfamiliar tool is necessary, it is important to establish that I do not know how to do anything using the tool. Then, I can begin to ask questions and learn how to apply my skills to the new problem. During the CAPSTONE project this semester, for instance, I am required to work with the Angular framework, and a tool for making things with Angular. I have no practical experience with any of these things, so whenever I need to know something in particular, I put out a question, so then I can learn. Rather than going off and trying to learn how to use these utilities, it is much more efficient to begin by seeing whether anybody else around already has an answer. Sharing knowledge and asking questions is a much more practical way to learn about how to work in a new environment.
I am writing this blog post about the “Read Constantly” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about spending more time reading about new material and ideas in order to stay in touch and learn about some new things. I think that this pattern is similar in many ways to the “Practice, Practice, Practice” apprenticeship pattern, because it is about taking the time and effort to become more familiar with a new topic. Reading research papers is an example given in the chapter. Any time I read about some unfamiliar topics, I always find that there is a huge depth of information that I have no idea about. Machine learning is one such topic that I spent a while reading about. After I had a good enough grasp of the basics behind the theory of it, I tried practicing implementing a basic multi layer feed forward neural network myself and have it classify some handwritten number symbols. Reading about it and implementing it was an interesting introduction into the field of machine learning, but continuing to read further into deep learning and the theory behind various learning algorithms, it becomes clear that there is still a ton about computer science that I have a ton to learn about. This is the case any time I look more than briefly into any broad topic. I was trying to implement a solution to a variant of the subset sum problem years ago and stumbled into NP-completeness and computational complexity theory. Constantly reading about new things is the only way to learn about different topics. The “problem” section in the book describes that there seems to be an endless amount of fundamental concepts that are unfamiliar despite proficiency in a programming language, and this is inevitable without reading constantly. Continuing to only practice in topics that are familiar makes it nearly impossible to expand into other fields without re-discovering them independently, which is unlikely when the areas are particularly advanced. Reading is like practicing learning. Proficiency in a language can only go so far.
I think things would be moving more quickly if all of the groups were communicating more about what everyone plans on doing, since everything is going to need to be divided among the groups, and then within our group we will need to divide tasks further among ourselves. Firstly, though, we need to understand the goals better in order to be able to come up with smaller tasks to break them into so that we can work on separate pieces of it individually, then bring it together as a group, and then bring each group’s contributions together to complete the project. Progress in this regard seems to be happening very slowly. We have a vague idea of what needs to be done and we do not know what comes next, so until a lot more detail is figured out, there is only one thing to do, and that is to clarify what needs to be done and come up with some more things to do so that the work can be performed in parallel by multiple teammates.
At this point it seems like the groups have decided on one particular thing to focus on, and our group is focusing on one particular component of one page of a wireframe made in Zepplin that was demonstrated in the first video. We do not know what we are doing, but we are making progress.
I am writing this blog post about the “Practice, Practice, Practice” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about the desire to improve and learn despite not having the opportunity to do so while working. The obvious solution that the book presents is to practice on your own time, while not working. Practicing something is certainly important; the process of practicing working with some idea is actively developing experience with that topic, rather than just reading about it and recognizing it. I have spent a lot of time reading about many different algorithms, and a lot of it does not really stay until I make it relevant by directly implementing it myself. The only consequence of doing this is educational, though; doing this while working would not be the appropriate time. Practice generally does not yield some purposeful product, whatever it is that is created in the end is only for the sake of experience. The book brings up a point about practicing the wrong things. I think this can be important. I have spent a lot of time practicing trying to write programs using the fewest amount of characters possible, which for obvious reasons is not a good way in general to go about programming. The result is typically a barely readable mess of what amounts to glorified machine code. I became good at it, but certainly the time would have been much better spent practicing something more practical than code golf. After gaining a lot of experience with different topics that I found interesting, I have been able to recognize situations where things I have practiced in the past are relevant and knew how to implement them as a solution. What I have noticed along the way is that now I would rather spend my time applying what I know than taking the time to practice something new and not produce anything meaningful. I still am interested in learning about a lot of things, but practice takes a lot of time, so the only way to learn is to take the extra time.