Hello everybody and welcome to another CS 448 apprenticeship patterns blog post. After coming back from spring break which was a relaxing week, the pattern that I will be discussing today is nurtured your passion. This blog covers how to protect your passion for software craftsmanship. I agree with this article when it goes over that the environment can disrupt your passion for software craftsmanship. This article gives good advice on how to keep your focus on becoming software craftsmanship like finding something at work that interests me and that I can enjoy. Also, it’s important to find the time to work on a project that is more enjoyable. I agree on this because during the beginning stage of my programming journey I would work on learning the fundamentals of programming and problem solving which was not really enjoyable and at times I felt like quitting but when I eventually move to the more advanced classes I found that I was working on more application based projects so that made me more passion to learn more but if I was just working on the fundamental stuff than I would probably quit programming because it wasn’t as enjoyable like creating applications. One of the other tips that it gives is studied the classics which was to learn the fundamentals which I understand is important, but I figure it’s better for me to learn the classics and work on the enjoyable project at the same time. I like that tip that you should find an environment that is comfortable to work in because certain stuff can bother you like co-employees, the rate of pay etc. and this can affect your passion for software craftsmanship. All in all, I think this pattern is helpful like all the rest but there were some things I didn’t think we have control of sometimes because yes, we could also leave an annoying situation but many jobs I know from experience always has its flaws but finding a job that provides more enjoyable work it more reasonable. I think this pattern is great and it inspires me to be more in control of my journey.
Hi everyone and welcome to another CS 448 blog. Today blog is going about study the classics which is one of the apprenticeship patterns by Adewale Oshineye, Dave Hoover. This blog is a simple pattern which helps me understand the importance of learning the basic. This pattern is about constantly updating your knowledge about the field and making sure you have a strong foundation on the field. After reading this apprenticeship patterns I realize that I should ask where the sources of information are coming from when trying to understand a subject from a person. Most of the time when I don’t understand something that is being talked about, I usually just ask the individual to explain the details in more depth but now I understand I should ask the person where they had discovered the information so I can learn it. I think the biggest problem I have with advancing my skills in programming is that I don’t read enough. After reading this pattern I decided I going to make a reading list to further my knowledge in programming. I like how the pattern points out that there a reason why the classic books are kept and are important to learn. This change the way I judge classic textbooks and now I more interested in them. Most of my books are updated so I haven’t look at any old books yet but I disagree with this pattern a little because some of the books like programming books always have to be updated so the classics wouldn’t apply but I can see other books like theory having classic book that can still relate even in today times. All in all, I think this apprenticeship pattern study the classics is important to the pattern because it explains the importance of understanding the classics while using modern tools. After reading this article I learn to read more, and I change my view on reading. I always feel like watching videos and doing projects was enough, but I now realize that you have read more of both classics and modern book to further my knowledge in the programming field.
Welcome back everyone to another CS 448 blog post. Today topic is going to be about the second sprint retrospective. This second blog post is going to about the recent actions that I been learning in the class, the work and work products that I am producing during the second sprint. The second sprint was very informative we worked on researching many topics that can potentially relate to our projected plan like Angular testing, Ampath, etc. During this sprint, I already had the Ampath to run on the personal computer but there were a few group members that were having minor issues when building the Ampath project, so I prioritize some so my time towards having Ampath running on every member in the group personal computer. I research many of Unit testing for Angulars like Karma and Protractor and found it important to learn for a solid foundation when testing in Angular. There was really much work again during this sprint as we were waiting for more information about objective for the Ampath project but meeting on this sprint we finally got some clarity in the project. We added more task in our sprint backlog like figuring if we will get access to Ampath on our computers, keeping an eye out for Zeplin shared folder and finding out more about mocking the database. There were also some videos from Gregory Schmidt that we had to watch which I finish which gives the main idea on which we should create during this semester. I found these videos easy to understand and after I feel more anxious and clearer on what must be done. I saw that Gregory Schmidt was developing an android application and now curious if we can create the Ampath application in another platform like IOS. My thoughts on the project are that the project will be a simple application that records and stores data. I will be continuing to do more research on this project during the break and found out more about the developing environment and programming language that we will be using. I researched briefly on how to save data into a database and I found that in IOS developing you can use SQL to create a database and then import the database into the swift project. I believe that you can probably apply the same concept with another other environment and programming language. Other than this information, I really haven’t done any significant towards the Ampath project. Also, if anyone is still having trouble getting the Ampath project to run on their personal computer just follow the lists of steps that I and the members of my group posted on slack. During the sprint, our group work well and perform great together as a team. I learned a lot of important information about testing and application development during this step. I am planning on applying some the stuff that learning in application developing in Swift towards the Ampath project. All in all, this is what happen and the things I learned during this sprint.
Hi everyone and welcome to another CS 448 Software Development Capstone blog. Today blog topic is about one of the individual apprenticeship patterns which happen to record what you learn. I wanted to read more about this pattern because I can relate. Ever since last semester I been writing many blogs and didn’t fully understand why I was posting them. At first, I thought this method of recording what I learn was to help us research more information and writing them as blogs would help us understand the material better. After reading this, I realize that it’s just more than blogging once per week. I understand that recording our journey helps keep vital resources, makes our journey explicit, and can be helpful to many others. I feel like after reading this individual apprenticeship pattern I will change the way I work because all this time I was blogging, I didn’t really blog for purpose and just blog because it was assigned so I think I will be more efficient when I blog now. I also picked up a new idea from reading this pattern which is to have two journal that is private and public. I can use the public for sharing what I have learned and gaining feedback and the private one for me, to be honest with my status in programming. I do agree that it best to have both because of the perks that each offer. I like when the record what you learn pattern state that Dave was constantly posting his journey for years and eventually, he had tons of resources that he then later uses later in his career. The reason why I like this statement is that it makes me more motivated when posting these blog assignments because I know that eventually, it will come in handy one day in my career. All in all, I felt like this individual apprenticeship pattern, record what you learn is very informative. I learned that every apprentice should keep a journal for their journey and try to write every day as one day it will help others and even help themselves.
Hello everyone, today blog is going to be about why doctors hate their computers. When I started reading this, I learn that it’s difficult for many others to adapt to new things like technology. Which I think this is accurate not just for doctors related field but for anyone so not comfortable with a computer before. I learned when a company that wants to switch to new software etc. its very costly not only for the new technology but for the other like loss of revenue. I have seen this process because when visiting my doctors during one of these phases of upgrading and I saw many IT employees helping the clinics get familiar with the new software. I never thought of how costly it was until I read this. Also, I learned that when transferring records like the size of the hospital. I learned that one of the issuing was that the doctors had a different idea on how the software should be run so they didn’t like having full control. But eventually when the doctor gets used to the software it very easy for them because they can access data remotely and most of the clinical routine did not change very much. When one the Dr. Sadoughi switch to the new software she said it cause worse than good. This is because she is stating that the computer software was pointless and more time-consuming. It’s wasn’t straight to the point like what she was used too. I kind of agree with her on some of her points when stating that it’s annoying with some software takes a lot of time to navigate through to get to the solution. I was surprised that the computer was making it so difficult for the doctor’s life, but I think since the software seems too new, I think eventually it will be easier for the doctors later. I don’t think after reading this article I will change the way I work because I been using a computer daily and I feel like I can adapt to new software rather than a doctor who not really computer friendly. It also seems like the software was more design for the patients than doctors. I think when making the software they were thinking the consumer was the patients instead of the doctors because that why the information seems to fit the patients. I can relate with the doctors because when working with new software in different jobs I found that some software is better created than others. All in all, I think this article pointed out it’s hard for some user to get comfortable with computers and many software programs created had many flaws but I think later in the future many upgrade and patch will solve the problem and it benefits everyone.
Hello everyone and welcome to the first sprint retrospective blog posts. Today I’m going to go over what had happened during the first sprint. During the first sprint, we first got familiar with each other because we just had form groups. We then decided on a team name which was 3m2g which stands for 3 mud kips and 2 goats. This team name was combined with two of the most voted names that were considered. We made a list of what had to be done in the product backlog and discussed with each other on what can be done in a certain amount of time. Here were the objectives that we had to complete. First, as a team developing software for AMPATH, we need a GitHub group so we can fork the AMPATH/ng2-amrs repository. Second, as a developer working on AMPATH/ng2-amrs, I need to clone ng2-amrs to my computer (every team member). Third, as a developer working on ng2-amrs, I need to set up my development environment so I can build/run ng2-amrs. Fourth, as a developer working on ng2-amrs, I need to learn about testing in Angular so I can write tests for our new code. When setting up the environment, it was easy because most of the needed software so already installed from the previous CS course. I had the following software and applications was already installed like Insomnia, Gradle, and some sort of Typescript IDE which I had Visual Studio Code installed. Some of the members of my group didn’t have some the development environment installed so the members that finished help provide information when needed. We also had to learn more about these testing tools which are karma and protractor. During the process, the of cloning the AMPATH/ng2-amrs project, Me and my fellow’s group members didn’t come across an issue. The only problem we had to was attempting to run the project which was unsuccessful. I then decided to follow one of the apprentice patterns which had to advise me to ask the help when needed. So, I call my friend Khoa which I and he went over the error and then figure out the solution. I then posted the solution into slack and notify my group of my fix. I learn more about understand certain errors and how to fix them on the day. Some of the software and application that I had installed on my previous class work fine but just need to be updated. When working on the first sprint I became more familiar with SCRUM and really understanding the importance of it. Also, when looking for information about testing in angular I came across many informative sites when inputting angular test on google. I missed the last day of the sprint, but the members of my team were very helpful in informing me of the information that I missed during that day. All in all, this first sprint was simply because the product backlog was a familiar assignment that was accomplished before and I enjoy working with the members of my group.
Welcome back everybody to another Apprenticeship Patterns by Adewale Oshineye, Dave Hoover blog post. Today pattern is to learn how you fail which is about how we should gain knowledge from our failure. I agreed with this pattern context that failure is inevitable. I believe every successful person failed more than they succeed. I think that failure can be anything from programming to any day life activity. When reading this pattern, I realize that I have a lot of daily life fail goals. I will prioritize the fail and figure what is worth solving. I learned that it’s important to gain self-knowledge about the patterns, conditions, habits, and behaviors that lead me to fail. I disagree that we should consider cutting out losses and accept that there will be some things that we are not good at. I believe that some things that are out of our control should consider cutting loose but things that just requires more effort should always be work on to fix. I think it’s important to set unrealistic goals every day so you can push your boundaries. Even though I different thoughts on this patterning method to set realistic goals, I can envision that setting accomplishable goals can be more effective than setting unrealistic goals. This method will result in many failures but that will have many benefits as well when progressing to be a better version of yourself. After reading this pattern I am more aware of the way I now work. I feel the need to go over my failures and evaluate them. I found this pattern useful but very familiar. Even though this pattern was very brief, I still think it’s important for every programmer to review. This pattern made me realize that setting too many goals and I should be more focus on the worthy ones. I didn’t physical do the action exercise, but I don’t the main objective of the activity when reading it. I think the main idea of the action is that error is inevitable. All in all, this pattern learn how you fail is worth reading and change the way I work.