Author Archives: rydercsblog

Sprint Retrospective #6

During our last sprint we added some new features to our Tabs component. We were able to include buttons for adding and deleting tabs as well as a checkbox that selects a new tab when it is added. We also added some extra form fields within each tab. I think this was a very successful final sprint. We have a fully functioning tab component that follows the specifications that were outlined by AMPATH. Overall I’m satisfied with the progress we were able to make on this project.

During this sprint we added buttons for adding and deleting tabs. In our tabs.component.ts file we have an addTab() and removeTab() method. The addTab() method simply pushes a tab to the tab array. It also checks if the “select after adding” box is checked. If it is, the newly added tab is set as the selected tab. The removeTab() method calls the splice function on the given index in the tabs array. In our tabs.component.html file, we use the Angular Material mat-raised-button for the add and remove tab buttons. We also use the Angular Material mat-checkbox for the “select after adding” box.

Another thing that we accomplished during this sprint was adding extra form fields within each tab. We previously only had form fields for first name, last name, and address. This sprint we added fields for gender, birth date, and email. The field for gender uses mat-select, which allows the user to select a value from a set of options. For birth date we used MatDatepicker, which brings up a calendar and lets the user select a date. For the email we used Matinput and included an *ngIf statement to check if the email that was entered is invalid. We continued using the Angular Material documentation to help us get this part done.

Besides the add/remove tab buttons and extra form fields, we also started working on the final presentation during this sprint. My team was able to break up the work for the presentation well. I will be explaining most of the code that we have and will also talk about the changes that we made to it. In order to do this I have been reviewing the code that we have to make sure I understand how it all works. I’ve also been looking up information so that I can explain our code well. During this sprint we made a lot of progress towards being prepared for the final presentation.

Overall I think that our final sprint went very well. We were able to add the extra features to our code that we wanted to add. While there is still more that could potentially be added to our component, I’m pleased with what we were able to produce. We have a working tab component that follows the specifications that were given to us by AMPATH. I enjoyed working on this project with my team and learned a lot about Angular development. I would say that our final sprint, as well as this project in general, was very successful.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Dig Deeper

This apprenticeship pattern discusses the importance of digging deep into the tools, technologies, and techniques that you use. If your knowledge is superficial, you will have trouble fixing subtle problems and won’t even be aware of how little you know. You must have the depth of knowledge to understand why things are the way they are. This will allow you to actually be able to explain the details of what is going under the surface of the systems you work on.

This pattern discusses several things you must do to acquire a deeper knowledge of whatever you’re working on. You must have a shift in perspective that involves wanting to follow a problem through the layers of a system to understand the root of what is actually going on. You should be familiar with various kinds of debuggers and must also be able to read specifications. It is also important to get your information from primary sources. For example, instead of learning about something from a blog post you found online, you should read the thesis paper that defined the concept that the blog post is discussing. By applying this pattern, you will be able to truly understand how the tools and systems that you use actually work.

I agree with the idea of this pattern. You should try to dig as deep as you can whenever possible in order to understand how things work. However, I question how realistic it is for a working software developer to actually follow this pattern. If you are asked to implement something for work that has a deadline, you won’t have hours to spend reading academic papers when a quick Google search will get the job done most of the time. This pattern warns that you should take care to not accidentally become a narrow specialist, but if you are truly diving deep into everything you learn it would be hard not to. There just isn’t enough time in the day to learn the fundamental concepts behind every tool or technique that you use. While I agree with the idea behind this pattern, I don’t think it is a very realistic goal for the majority of people.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective #5

During Sprint #5 my team continued development of the Tabs branch in the AMPATH project. During our last sprint, I pushed a simple tabs component to Github. This sprint, we refactored the code to add a forms component for each tab. Overall, this was a very productive sprint.

The tabs component that I had originally pushed to Github included a list of patients, with a tab for each patient containing general information. However, the tab system that we need to create will be for forms, with various input fields for each tab. To do this, we used the Angular Material Design form fields. The following link was extremely helpful in learning how to implement the form fields: https://material.angular.io/components/form-field/overview

Adding the form fields required making some changes to our main html file. Originally, it used *ngFor to go through the hard-coded list of patients and generate a tab for each one. Since we are getting rid of the patients, we no longer have something to loop through to generate the tabs. To solve this we will have to implement an add/delete tab button. This will be our main focus for the next sprint. As of right now, we just have hard-coded tabs with the form fields within. The form fields are all the same basic types, as we don’t know which ones AMPATH will actually need. The three types of form fields that we have are input, which allows you to enter a line of text; textarea, which allows you to enter an expanding block of text; and option, which lets you pick an option from a drop down menu.

We did not run into too many challenges implementing the form fields. The main challenge was figuring out how to reorganize the html as the entire patient portion is now obsolete. Other than that, the only errors we ran into were pretty basic, such as missing a required import. I have enjoyed working with Angular Material Design as it works very well and looks good without having to make many adjustments. I’m glad we chose to work with it for this project because our other options seem like they would have been much more complicated.

After this sprint we are much closer to having the completed component that we are shooting for. We now have a working tab system with form fields located inside of them. We still have some work to do to get it finished, as we need buttons to add and delete tabs. However, I’m confident that we will be able to get that working during our last sprint. I feel that everybody on my team has a good understanding of the code that we have and we are all on the same page in terms of what we want to accomplish. I think that we are making very good progress and I am learning a lot about Angular and html. Overall, this was productive and satisfying sprint. We are making a lot of progress and have a clear and reasonable goal for our final sprint.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Craft over Art

This pattern is about the conflict between creating software that is beautiful and creating software that is useful. While you may find opportunities to do something truly fantastic, a craftsman should always focus on delivering value to the customer rather than advancing his or her own self-interests. You must find a way to balance the conflicting demands of creating quality software while still putting your customer’s interests first. Software built for customers can be beautiful, but it must always be useful. Following this pattern means that you must be willing to sacrifice beauty in favor of utility when it becomes necessary.

A craftsman must also produce satisfactory quality even if he or she doesn’t feel like it. Craftsmen can’t wait for inspiration to strike before delivering a product. However, it’s not about simply doing what is fastest. A craft artifact should always display at least a minimal level of quality. This means you must always be making trade-offs between beauty and utility, and sometimes you will make the wrong trade-off. However, by fixing these mistakes, you will learn lessons that are impossible to learn in any other way.

I enjoyed reading this pattern. I have always found it interesting how programming is so technical yet can be incredibly artistic at the same time. This pattern brings up a very valid point that even though you may be able to create something artistic, utility will always be a priority when software is made for a customer. I think the following sentence from the pattern sums it up perfectly: “The things we build for customers can be beautiful, but must be useful.”

As a programmer, it is often tough to decide whether to code something that gets the job done but is ugly, or something that takes more time but is beautiful. It is important to analyze the purpose of what you’re creating to decide which direction you should head in. Reading this pattern made me think a lot about utility vs beauty in software development. I do agree with the main point that as a craftsman creating something for a customer, utility should be prioritized. Overall, I thought this was an interesting and useful pattern.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective #4

Sprint #4 was a very productive sprint for my team. We were able to get a lot of research and planning done in regards to the tab component that we will be creating for the AMPATH project. We also narrowed down the exact functionality that this component will have and discussed how it will interact with the rest of the app. During this sprint, each member of my team began coding an Angular component to get a better understanding of how we can implement the tab functionality. I was able to create a test component with tab functionality that displays patient information.

My plan for writing the test component was to follow the beginning of the Angular Tour of Heroes tutorial then build off of it. This was a useful way to do it because I was able to start with a base application that I could modify into something else. My team decided that we should each create a component just to see how it worked, so it didn’t necessarily have to be related to the tab functionality. However, I decided to build a tab functionality for my component because I felt that it would give me a better understanding of what we would have to do to to get our project built. What my code does is display patient names on tabs at the top of the screen. When you click on one of the tabs, it brings up information about the patient including the name, id number, age, and gender. It also allows you to edit the patient’s name, which reflects instantly on the tab itself. For our actual project we will need to connect to some sort of database for patient information, but for this test I just created a Patient class with the attributes that each patient will have. I then have a mock-patients.ts file with an array of predetermined patient information. The patients.component.html file is where the tab functionality resides. I used the Angular Material Design tab component to build the tabs. This link was very helpful for showing how to implement that: https://material.angular.io/components/tabs/examples

The biggest challenge I had was making the correct set of patient information display when clicking on a tab. I originally had something similar to the Tour of Heroes tutorial, where clicking on something brings you to a separate section of html. However, this didn’t work great with the tab functionality, as it required waiting a few seconds before clicking on a tab would bring up the correct information. I was able to fix this by putting the part that displays patient information in the mat-tab-group and using *ngFor.

Overall I feel that this we made a lot of progress during this sprint. It felt good to finally code something with a tangible result. By creating the test project my memory of Angular and html was refreshed and I learned how to implement Angular Material Design. This will be a big help throughout the next few sprints as we develop the tab component for the AMPATH project.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Practice, Practice, Practice

This pattern discusses the importance of practicing when it comes to improving your skills as a software developer. Many people’s daily programming activities do not give them the space to learn by making mistakes. If you find this to be the case, it is important to find an environment where you can practice without interruptions or pressure. For this pattern to be useful you need to carve out time to develop software in a relaxed and stress-free environment. If you aren’t relaxed, it will be harder to learn from your practice. Feedback is also important when it comes to practicing coding because it helps prevent bad techniques from being developed. The point of practicing is not to hone your memory, but to learn the nuances of your skill. This is why it is effective to do something a little different every time an exercise is performed. Choosing the right thing to practice is almost as important as the practicing itself. A good way to practice is to go through old programming books that focus on the fundamentals of computer science, as the information rarely stops being useful and provides a large source of interesting problems.

Reading this pattern was interesting because it complements the last pattern I wrote about, Use the Source. While that pattern discusses how reading code is important for improvement, this pattern talks about how practicing coding is important. I thought this pattern was very useful because it goes over the most effective strategies for practicing. The advice given about practicing in a relaxed environment and practicing within a community is very true. Enjoying your practice and getting feedback on it are both important aspects that are necessary if you want to see real improvement. The advice about doing exercises from older books that focus on the fundamentals rather than the latest trendy framework is also useful. There are so many frameworks out there that it can be overwhelming to pick one that you want to practice with, and sticking to the basics is usually more helpful anyways. Overall I thought this pattern was interesting to read through and I will try to apply what I’ve learned from it when I’m practicing in the future.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Use the Source

Use the Source is about the importance of reading other people’s code. Reading code is important because it is the only way to truly understand a system. Without studying and emulating examples of good code, you may never realize the bad habits that you have. A good practice is to read the code of the applications and tools that you use every day. By doing this you will learn good programming practices and start to understand the systems that surround you. It is also important to have other people read your code. Taking feedback from others will help you become a better programmer. Thanks to the large amount of open source projects available, it’s possible to read or contribute to a wide variety of projects built by the global community of software developers.

I enjoyed reading this pattern and found it to be extremely relevant. It is true that the only way to really understand code is to read it. I found it interesting how the author said that working programmers spend far more time reading code than writing it. If your only experience coding is what you’ve done in school, that might be hard to believe. But it makes sense for a number of reasons. Professional developers work on projects much larger than those that students work on, and all of that code must be read in order to understand it. Developers also don’t want to reinvent the wheel for every project, so a lot of time is probably spent reading implementations that others have created. Being able to quickly understand what a piece of code does by reading it is an important skill that isn’t taught in school. To become a great developer, you have to spend a lot of time reading other people’s code. This will introduce you to new ideas and better coding practices.

I thought that this pattern was very useful. When I have wanted to improve my coding skills in the past I have always tried writing new programs. I never realized that reading code is just as important. This is a great pattern that I will definitely try to implement in my life.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Rubbing Elbows

The Rubbing Elbows pattern is a solution to the problem of productivity reaching a plateau. If you always develop software by yourself, you may eventually get the feeling that there are superior techniques that you don’t know about. In order to fix this, you must rub elbows with another software developer. This means you must work on a hands-on task, side-by-side. This is necessary because there are some things that can only be learned when you are sitting with another software developer working to accomplish something.  There are many little techniques that can only be picked up when collaborating closely with somebody. The author uses pair programming as an example of this pattern. Apprentices should always look for opportunities to work on teams that use the technique of pair programming. However, pair programming isn’t the only application of this pattern. You can collaborate on a number of things such as a presentation, academic paper, or an open source project’s sprint. The goal of this pattern is to find ways to expose yourself to the working habits of other skilled people so that you can pick up on those habits and refine your skills.

I think that this pattern makes a lot of sense. If you are programming by yourself all the time, you will almost certainly reach a plateau because you aren’t being exposed to new ideas and techniques. Reading this pattern made me realize how important it is to work side-by-side with other people. It is true that by doing this you will pick up on the small techniques that the other person uses, and will learn things that can’t be taught in a book or classroom. I really liked the Richard Sennett quote about the ideal craft workshop. It captures the idea that gaining knowledge isn’t just about listening to words, but absorbing the thousands of little techniques that make up a skill. After reading this pattern I have a greater appreciation for pair programming, as I now realize the benefits of working on a task right next to somebody. Overall I found this pattern very useful and it has inspired me to rub elbows with fellow software developers.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective #3

During our third sprint we finally got an idea of what we will be coding for this project. Greg Shmidt from AMPATH sent us videos that showcased wireframes of the electronic medical record system that they are requesting. The main thing that I did during this sprint was watch these videos and start planning with my team what we will be working on and how we will go about coding it.

After watching all of Greg’s videos, my team decided that we wanted to work on the tab functionality. The tab is one of Google’s standard material design elements, and Greg showed a few examples of apps such as Google Music and Twitter that incorporate tabs similar to the way that we will be for this project. Each tab will contain a form that displays patient information. The tab bar must also be able to scroll to show additional tabs.

During this sprint my team began planning how we are going to go about designing and implementing the tab system. A link was posted on the Slack channel to documentation about coding mobile Angular user interfaces. This was helpful to read through as it gave me a better idea of what we will actually have to do to code the tab system. I also found a page on tabs on the Angular site that was useful to read through: https://material.angular.io/components/tabs/overview

One challenge in implementing the tab system will be making it so that it functions with the systems that the other groups are developing. To do this we will have to figure out which services we will need to use. Luckily, a member of another group found where all the services are located in the ng2-amrs project. During this sprint I began looking at these services to figure out what they do so that we will know which ones we will have to implement when creating the tab functionality.

After this sprint I believe that my team is ready to actually start coding. We now have clear instructions on what to do and have done preparation work that let us get a better understanding of how we are going to proceed. During this sprint I learned what is expected from us for this project and gained a conceptual understanding of how to implement a tab system in Angular. It is exciting to finally know what we are working on and I’m glad that we can now begin to make progress on this project.

Overall, I would say that this was a successful sprint and I would not proceed differently in light of anything that was learned throughout the sprint. I am satisfied with the way my team is working together and I believe we will begin to make a lot of tangible progress during the next sprint. I think that the tab component we are working on will be a lot of fun and am glad that we chose it. This project is definitely going well and I’m excited to continue working with my team.

 

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Retreat into Competence

The Retreat into Competence pattern describes what you should do when you feel overwhelmed with how little you know. Every apprentice will eventually feel ignorant or incompetent compared to the craftsmen they will meet. This should not be a reason to worry as it is a normal and inevitable phenomenon. However, when it happens you should retreat briefly into your competence. What this means is to work on something that you already know very well in order to regain some confidence and realize how much you’ve learned since you began your journey. This pattern is relevant for people who are struggling or stretched beyond their ability. If you find yourself in this position, you may need to take a step back before you can continue going forward. However, it is important to realize that this pattern is only a short-term fix so that you don’t surrender to the comfort of working only on things that you know very well.

I enjoyed reading this pattern and found it to be useful because it is applicable to everybody at one point or another. Reading this pattern reminded me of impostor syndrome, which is when somebody persistently feels like a fraud despite evidence of their competence. I think this is something that a lot of computer science students feel since there is so much information to learn and the technology and tools we use are always changing. I think that this pattern is great advice for someone who has a case of impostor syndrome or simply feels overwhelmed by their work. Taking a step back and working on something that you’re comfortable with will allow you to clear your head and regain your composure. It is important to remind yourself from time to time how much you actually know and realize that many things you do easily now once seemed impossibly complicated. Retreating into your competence will help you spring forward when you go back to new challenges. I’m glad that I read this pattern as this advice will definitely help whenever I feel lost or overwhelmed in the future. I now know that in situations like that it will help to retreat into competence for a little while.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.