Author Archives: kumarcomputerscience

Sprint Review Blog # 4

          Our fourth sprint laid the first real groundwork for the project design and coding. The AMPATH developers have given us more information as to how they want the simple app to look like. It should have a simplistic design within the flow and written code of the app to make sure it works properly. We created a new repository from a more updated version of the original files given to us. The original files were lacking in certain angular development modules so importing certain components and data became an issue quite quickly. The updated files now have those development modules which we have just cloned onto our computers and created a QForm component for the questionnaire form. We had to delete our previous branch known as questionnaire-form because it wasn’t up to date with the new files. We decided it would be easier to create a new branch from the new files and start over in this manner. We created the new QForm component and have laid the groundwork skeleton for how the design should look within our CSS and HTML files. The CSS is giving us issues however, because the form that we imported was vertical in format while the one that shows up when we ng serve is horizontal and slightly unformatted. We will continue to work on these issues to make sure they are ironed out and looking as proper as possible. We debug any issues we come across separately on our own and then bring it to the team if we can’t seem to figure it out. The option of multiple people debugging a problem is comforting and it allows a fresh look onto an engaging topic. I personally enjoy group debugging because it makes the learning experience much more enjoyable. I still think that the hardest part for the future will be to connect each component together and bind them into one final app with the other groups. We’ve already started collaborating with other teams on what information we all will be needing from a mock server. It will be necessary for the future so I think we should discuss how this server will be setup and which development tools will be used. We should also understand how data types will be formatted within this database so as to hold only meaningful information. It would be interesting to see how patient data types are handled at AMPATH but we’ll just have to make our own version based on guessing. I’m now more worried about connecting the CSS and HTML for the final application to make sure everything looks nice and simplistic since we had issues with our own CSS. We want to continue to understand how we should edit and evolve the code already given to us and turn it into the final product that they want. The most important aspect of this design that we decided on seems to be simplicity with functionality. We want to incorporate that using the imported modules while also gaining knowledge on how they designed their app.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

B10: Sweep The Floor

          The “Sweep The Floor” pattern is described as a way be able find your place on a new team that is unsure of you. This pattern expresses how to find a way to earn your teams trust and contribute to their work without getting in their way. A good way to start is to volunteer to do simple tasks to show initiative and competence for small tasks to eventually work your way up to the big ones. An important fact to remember is to go for quality of work rather than quantity to ensure your teammates of how seriously you are taking this opportunity given by them. This may seem like a step back from all the studying and preparation you’ve done to get to the point, but you must also remember that now you are hired to be on this team. You must prove yourself before they can put any sort of trust in you and the best way to do that without causing any accidents are smaller tasks. This does not mean that you should let the team see you as the pack mule for meaningless tasks, but rather someone who can pick up the slack if needed.

         I found this pattern to be a great introduction to read before really starting out on a team. It allows an easier incorporation to the team dynamic and earn a teammates trust. It created a good sense of what to do and not to do so as to make sure that you are doing extra work for the good of the team while not becoming a pack mule. I want to start using these skills and think that they will definitely make working in a team easier. I think it will make the workload harder, but it seems to be a good trade off to earn the respect for other teammates. I agree with this pattern for that very reason because respect is a very big deal in teamwork. Every team member should prove their skills and respect for the good of the team. I want to continue this practice to make sure that my dedication and commitment to the team is seen to create a better bond with teammates.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Sprint Review Blog # 3

            Our third sprint enlightened the path the group planned to take with the other groups for the splitting of objectives. The AMPATH administrators were able to give us more information based on the project specs that included wireframes of each component that we needed to create. The team heavily benefited from the clearer explanation by being able to divide the work out to our team members in a productive manner. We were able to understand what the project generally asked for and began working on our first component for the angular project. This sprint also gave us more time to look at the code AMPATH had given us for reference material on variable naming and options when creating the components. We compiled ideas on our first component and finalized that we would work on the form component. We analyzed the videos that were related to that component and realized that it could be made fairly easily but there were more questions that needed to be answered. We found that the question fields for the form were not stated, so we decided to create their names based on their question number. We would like to implement real questions, but we can only do that once we confirm this is needed with AMPATH. I think that we should proceed to understand the AMPATH format for their angular code and look into understanding how we will possibly setup the Mockito style of testing we are aiming for. A better understanding of the project will be needed to further enhance the user experience so as to create a flow within the program that seems seamless to the backend user. We want to continue to understand how we should edit and evolve the code already given to us and turn it into the final product that they want. I think that the hardest part for the future will be to connect each component together and bind them into one final app with the other groups. This is going to take a good amount of proper communication to achieve. It will be necessary for the future so I think it would be a good idea to start talking to the other groups about this now. This will keep them on alert and conscious of the code they write to make sure it can be understood properly by someone on another team. This app will be used by back end users for simplistic tasks such as filling out questionnaires and taking notes on patients based on their medications. It seems that another team has also found some Mockito code within the files given to us by AMPATH that could be useful in creating our own data to be fed into the application. I’m uneasy about the lack of information we have based on variables in play when looking at patients between our version of the application and the AMPATH application. I hope that the transition of data between the two applications would go smoothly but it doesn’t seem reasonable to think that this process would go without hiccups.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

B9: Rubbing Elbows

          The “Rubbing Elbows” pattern is described as a way be able to branch out and meet other developers instead of working alone. The book talks about how productivity and learning can understandable plateau if you constantly work alone. The best learning experiences come from balancing private learning with team learning whether that be in a large team or simply coding with another person. It allows you to learn things that can only be understood when you and another person have a shared goal in mind. There are little quirks that you can pick up when working with someone that a mentor may leave out or find trivial to teach due to the small scope of learning it provides but over time these quirks can add up. This being said, there are also negative effects of this pattern to watch out for. An example would be to not pick up bad habits that your partner may develop or have. Another example is to make sure to not fall behind on your part of the work because it then hinders your partners learning progress as well if he has to pick up the pieces behind you.

          I found this pattern to be understanding of solo programmers and shows them a way to learn more through working in teams. It showed that working in groups and teams can build communication skills and increases exposure to several coding styles. I found that when the book mentioned pair programming as an example, I got much more interested in the topic. The idea of switching off coding seems very interesting to me and makes me want to learn more for an experience programmer. I want to incorporate this mindset in my work environment to learn better from my peers. The pattern did a good job on the negatives as well by going into subconsciously learning habits that aren’t good for you. This can be helpful to keep me mindful that some habits should be avoided or corrected to increase proficiency at the language. I agree with this pattern very much as it has taught me to value pair programming much more and has instilled a new interest to find a coding buddy to learn off of.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

B8: Practice, Practice, Practice

        The “Practice, Practice, Practice” pattern is explained as one of the better ways to develop your skills in new areas and get better with hands-on learning. The book continues by saying that being able to learn skills on your own time gives you multiple benefits that can’t exactly be emulated in a work environment. In a work environment, you constantly feel the pressure of learning new skills and learning them quickly while practicing by yourself allows you to control the rate at which you want to comfortably learn. The main idea of this pattern is to have a stress-free environment for you to experiment and eventually learn in. The idea of integrating feedback loops should also be in the back of your mind since it could prove useful here. It is possible to develop bad habits as you practice so making sure that someone can give feedback on your practice afterwards is also crucial. This allows a better learning experience in the long run by quickly correcting any habits that form rather than letting them sit with you for an extended period of time.

            I found this pattern to be important and useful as a reminder to make sure that I keep practicing. It outlined the positives of practicing code and how to set a personal pace for learning compared to a work environment. I found that when the book talked about the fast pace of work being different from learning at home, it resonated with me much more. I want to incorporate this pacing technique for personal learning more to find out how it can affect my overview on a subject. I predict that it will allow me to continue learning without getting too burned out since I would be able to control the pace at which I want to digest information. This can be helpful because there are some days where I don’t feel like working a lot which allows me to control the learning load compared to days where I want to learn a lot. I agree with this pattern for that very reason, to be able to personally create my own time schedule as long as I continue practicing at a continuous rate. Practice can only make my knowledge base greater and it allows me to experiment with ideas that I wouldn’t be able to in a work environment at my own pace.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

B7: Read Constantly

       The “Read Constantly” pattern is described as a way to create a strong base of knowledge and an even better understanding of the industry around you. There seems to be such a vast amount of information out there today that it seems very intimidating to even fathom where you should start. Reading is the best way to start learning more about the industry and more abstract yet fundamental concepts. The idea of reading everyday may seem like a lot of work at first but the key is to completely immerse yourself into the context of the text. Find new ways to apply what you learn to what you are working on and familiarize yourself with patterns before they become more popular and widespread. Another good way to read is to section parts of the book into manageable pieces to organize your learning experience such that it flows easier reading from one chapter to another. The book also talks about momentum when finishing books by allowing a brief but not long period of absence from reading. Find your next book and move onto it as fast as you can without creating a disturbance in your work life.

            This pattern was interesting because it showed me a way to read without making it too overwhelming. Every book I find on coding seems to become very overwhelming with the amount of content inside. The content itself becomes boring when reading for too long, it begins to sound repetitive which leads to a lack of interest. I found the tactic of breaking these large amounts of reading into smaller portions a great idea. I’ve been currently applying this tactic with great results as I can retain the smaller amounts of information better and this allows me to keep a more vested interest in the book. I also found that focusing on the portions of the book that interest you can make it easier to read. Focusing on ideas and aspects that you want to learn more than the rest makes the reading go by much faster. I agree with this pattern because of the amount of information that is available at all times to us. It’s very important to use our resources to the best benefit we can take from them. Books and online readings are everywhere these days and it makes information much easier to obtain, so to sharpen your skills you must broaden your skill set as well.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Sprint Review Blog # 2

            Our second sprint had little coding action and more of a personal learning aspect that we decided to focus on. I found that the team benefited from individual learning in a similar fashion to an independent study when trying to learn about important concepts like Mockito testing and Angular formats. We then compiled our individual learning resources into our slack channel to help each other find resources that others may have missed. This allowed an easier flow of understanding while also being able to bring us all onto the same mindset of where we were in terms of starting the project. I will proceed to understand the AMPATH format for their angular code and translate that knowledge to the requirement we will need to meet in the future. AMPATH members have recently posted videos and presentations of how they want their new interface to look with explanations for user interactivity. We want to continue to understand how we should edit and evolve the code already given to us and turn it into the final product that they want. We will have to communicate not only with our team member but the other teams as well to go over which functions should be divided up and worked on. This will create a better organization system for how we should communicate with other teams as well to understand any implementations that they will do which might affect our portion of the project. We learned about how the AMPATH project works through the videos which explained everything from selection tabs to navigation elements. It seems that this design concept may be similar to that of a mobile app from the setup of the mockup files which makes our approach much easier to narrow down. The most important aspect of this design seems to be simplicity with functionality for the patients and their doctors. The ability to create a smooth design is going to be complicated with different teams working on separate functions that are supposed to come together to create this app. It will require concise and mutual communications from several fronts that we will need to perfect over time. I predict that in the beginning it will be difficult to explain our coding schemas and ideas properly to each other but once everyone gets a taste of each other’s coding styles, it can be done with minor hiccups. We also need to decide whether we will stick with the idea of using a Mockito style for our testing or setup a server on campus to continue working with fake data. We have communicated with multiple teams about this idea and think that we should at least try to see if setting up a server is viable with as few hiccups as possible otherwise, we will have to look further into testing. I believe that setting up the server could work out well for every group, but it could cause issues with connecting and internal errors that we wouldn’t be able to figure out properly. It is definitely worth a try as it would be an interesting experience to understand and make it easier to test if we should be able to get fake data.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

B6: Find Mentors

          The “Find Mentors” pattern is explained as the search for when beginners start looking for developed craftsman to show them a specified path. The book explains that the first step is to find someone who is already ahead of you and try to learn as much as you can from them. Eventually, someone will take on an apprentice and you will be able to establish a better idea of your future from there. It can be difficult to get attention from a single master as they try to teach you and try to work on their own projects. This can lead to having multiple people looking over your growth to make sure that there are multiple inputs to your learning experience. The important part of this step is to make sure to not get frustrated or confused with the multiple sources of information. Masters also have their own weaknesses, so make sure that you understand exactly what those weaknesses are and how you would change your learning methods to accommodate those weaknesses such that they aren’t mirrored onto you.

          I found the Find Mentors pattern interesting because it explains the benefits of having someone who can guide you while also explaining how to further enhance your learning with multiple masters. It taught me to understand the issues of having a working mentor when it comes to workloads. I had never thought about how the masters have their own lives to juggle while also trying to teach their students. I found that the idea of getting multiple master was useful but that it could also come with its own drawbacks in some scenarios. It would be tough to find a reliable master and the more masters you have, the more likely it is that one of them may be leading you astray. This idea is what I don’t like about this pattern and I intend to apply it to my own learning. I don’t mind finding a master as long as I feel comfortable double checking them to make sure that everything, I’m learning is correct and won’t harm my growth. Other than those drawbacks, I understood and enjoyed this pattern. It’s repetitive nature of the learning process for students is easy to grasp which makes that much easier to apply.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

B5: Expose Your Ignorance

          The “Expose Your Ignorance” pattern is described as a way to come to terms with the fact that you won’t know everything in your field. Everything starts as a learning process when you enter a new team. It becomes easier as time goes on and creates a better environment when your team sees you making sufficient progress and growth. The pattern explains that creating a strong relationship with clients and colleagues causes them to grow more interested in your growth as a developer because of the increased efficiency you gain which in turn helps push development even further. Telling people the truth that you’re in the process of learning new skills may make them see you as an amateur but it is certainly better than giving them false promises of creating a finished product on time when you can’t quite deliver on it. This also brings up the point of asking questions, since questions can also show your ignorance but that shouldn’t matter as much since it all is a learning experience. You must ask questions if you plan on putting your pride aside and showing your team that you truly want to learn without taking any shortcuts.

          I found the importance of being honest with your team very useful to expose your skill set to them. The idea of letting your team exactly what you can and can’t do will help them better gauge what tasks they should start you off with to make the learning process easier. I enjoyed the fact that the book doesn’t tell you to shy away from asking questions. Questions can make you seem much more ignorant but the reason why you ask questions is to learn in the first place. This pattern expresses the importance of learning through honesty with your teammates which I will incorporate into my own experiences. The honesty aspect also will help with trust within the team as it shows that I’m not willing to hide anything from them. I overall enjoyed this pattern and agree with it completely. It repeated some very important aspects of teamwork and honesty that I will make sure to never forget.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Sprint Review Blog # 1

          We learned quite a bit in our first sprint for the AMPATH project which ranged from troubleshooting compiling errors to understanding team dynamics. After some reflection, I found that the mutual troubleshooting that our team did allowed us to bypass any icebreakers that were needed. We were able to professionally and respectfully look into each other’s problems while making sure that no one was left in the dark. After learning about our team dynamic, I will proceed to do more involved communication through slack rather than other private forms of communication. We had begun to use texting a form of communication but quickly changed to slack to ensure that everything was able to be pulled up easier in the future for documentation and blogs. We learned to better troubleshoot using sites such as stackoverflow and GitHub to find information on node as well as npm versions. The start of our first sprint consisted of working on the front end of the project to make sure it was able to run and look into the server side as well to gain more information on how it worked. We had many problems when trying to make the ng2-amrs repository to work when we cloned them on to our own computers. We consulted each other and the various other teams to understand the common problems everyone was having and fix them together. After cloning the proper files onto our computers, we immediate ran into problems when trying to run the project. We were met with various errors that we were able to fix by updating our versions of npm and nodeJS. The npm version was easy to update through commands in the terminal but various team members were having issues with updating node through the terminal, so a manual reinstallation was necessary. During the installation, we found that we must check a box that allowed node to install packages that may be needed as a project is built to ensure that the project could continue to compile. After this error, I happened to get a windows x64 compatibility error for certain files within the project, specifically a file named style.scss. Fortunately, our professor was able to locate a solution to the error and explained that we should type the command “npm rebuild node-sass” to rebuild that node so that it would work with our version of windows. After trying to build the project once more, we ran into another error when running the command “ng build –prod” which would have let us build the project and figure out any other errors we were having. The error said that the javascript process ran out of memory which seemed quite odd. Our teammate Harry was able to troubleshoot this error from stackoverflow using google and emailing people from AMPATH. We were able to change some of the memory restrictions on the javascript process and ran the command npm start which allowed us to fully compile the project and get an interface running. We currently are still facing issues because the project says that it was compiled with warnings which we have not delved into yet as we are awaiting more information from AMPATH. Our troubleshooting methods were mainly using our resources from the internet to find out why the project was running into issues until we were able to properly compile it into a workable interface.



Node JS manual update

Style.scss error

JavaScript out of memory error

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.