Sprint 5 was a continuation of sprint 4. Again, we started sprint 5 by reviewing what was done in the sprint 4, particularly our achievements and failures. As a matter of fact, we revisited pouchdb to make sure that we have it installed and running in everybody PC. This success in Sprint 4 has helped us very much in continuing to explore ways of capturing the offline data. In Sprint 5, there were no any interruptions and the team was able to do our regular team meetings without any interference. I will say Sprint 5nwas very effective in terms of meetings and discussions. We were able to hold effective discussions, coming up with some ideas and also explaining to each other what we meant by the ideas we came up with. I will personally give credit to Rick Phillips for offering those pieces of advice. His advice has been very informative and that has helped the team a lot in doing and understanding our work. Jason has also been doing well in integrating those ideas we came up with and the advice offered by Rick Phillips into code.
Again, for our offline data capture task, even though, the idea of using local storage system was established in the previous sprint, the team was still unsure of if the pouchdb I have been preaching on since day one will work for us. But now, I can authoritatively say that the team is confidence that we could capture the data remotely using pouchdb based on our further experiments. As usual, we continue to and will still do more research on pouchdb to gain insight of how we can possibly capture the data; we continued to dig deeper into pouchdb by learning more tutorials of how to synchronize data between two servers. One of the major problems we were facing in our data capturing task was getting the data. We could initially write a dummy data into the pouchdb but we wanted to capture the data from the AMPATH database. By Rick advice, we were able to search for data through the patient database of the AMPATH and store it into an array which we could iterate through to store each into separate files in pouchdb.
Besides, at this point, we look close to getting the task done but still face some problems. We are not completely sure of what need to be sync back. I personally suggested to the team that I think the ideal way is to synchronize just the differences. I will prefer we are able to add a function that checks for difference and synchronize that to the database than synchronizing the whole data captured remotely including the old that was retried while going offline. I also think it will not be useful for the doctor to have a whole bunch of data that he/she doesn’t need and I think we should be able to come up with away that the doctor could filter the data down to just what he/she need at the time when he/she is going offline. This also led us to haven to design a GUI for the doctor. With regard, I created an abstract ER Diagram with three entities; thus the Doctor, Appointment and Patient, showing how the relationships and cardinalities. Rick and I are now waiting to kickoff with design for the GUI when we are clear of the filed they want us to include.
In summary, I would say this Sprint has been very interesting due to the enthusiasm and passion that we put into work. I believed if the team keeps up with this enthusiasm, we would definitely get the work done. I also think the work sharing that has been listed on trello board will also help keeps everyone busy.
The ideas discussed in this pattern are often ignored by a lot of people including me. Documenting what you learn will not only serve as a further reference but will also save you a lot of time refreshing your mind on topics that you might have lost ideas. In the other hand, you may still remember what you have learned on a problem but the issue is that you have got only the main ideas, forgotten the details in it.
I got to realized how ignorance I am about recording what I learn after reading this pattern. I think I have never learn why I fails sometimes because on my reflection, I realized that in most cases, I overlook some of the things I learn as a real event and therefore don’t think I will ever forget them. But in the long round I lose track of most things as time goes on. On reflecting on why I sometimes don’t document what I learn, I couldn’t find a particular reason for that. Gone on the days when there was limited storage in our computers, and in the worst case, no internet access, we could record what we learn on note books. The only problem I had with that was, as time passes, you turn to have more books and you overlook their important. Sometimes you are tempted to trash your entire old document thinking you have enough knowledge that can deal with issues coming from these documents. But I realized this is not true because not long ago, I have encountered a situation where I have to go all the way back to my high school note book for the solution.
After reading this pattern, I think I will not ignore the power of recording what I learn anymore. With internet access, recording is going to be more convenient and effective. For some time now, I have been saving what I learn in goggle docs but after reading this pattern I have taken another twist to blog all my learning. I think this can help me easily managed and share what I learn with others.
This pattern also captured a very important issue that is often ignored. As a newcomer, you need someone to guide and coach you to get grounds in the field. We sometime failed to understand that only what is learned in class can’t take us to the field. The outside world has its own convention of doing things and a newcomer need somebody who is already in the field with experience to guide him. There are so many benefits for having a mentor. Working alone is the hardest thing you could face in the outside world and having someone as a mentor walking with you side by side or sitting with you face to face could save you a whole lot of time spent trying to figure out how to dealt with certain problems. Even though it sound very simple to say find a mentor, it is usually challenging to get someone who is willing to accept you as an apprentice. Even though the writer talks about the field being young and which we can’t tell who is a master craftsman, I don’ think that is a problem. Because, no matter the situation is, those who are already in the field will have some experience that a newcomer doesn’t have. The issue here is everybody readiness to share what have been learned. Most people don’t want to share their knowledge with others because they feared their jobs would be taken from them. They also forget the fact that when you teach other of what you know, it helps you remember it all the time. In fact, it sticks in your mind forever. With regards to this problem, if you are fortunate to have many people mentor you, you will definitely gain enough knowledge to keep you going in the field. Another thing that every apprentice needs to know is that nobody knows everything and though the master has more experience than he has, they might both be learning certain things together. Regardless of whatever challenges I might face in the industry, with this whole ideas in my mind, I think I can survive in the industry.
Sprint 4 was more or less a continuation of sprint 3. We started sprint 4 by reviewing what was done in the proceeding sprint. It appeared not much was done in sprints 3 due to the weather interruptions. This time around the team was able to meet on a regular bases and things that some of the team members could not accomplish on our own was brought up for discussion and eventually, fixing them. With regards to what was to be done, things were quite straight forward because we knew what we were up to at this point; we knew we are working on the offline data capture which the app is aiming on getting data collected in the remote location where there is no internet access and synchronizing it with the main server either automatically or by manual update to the service.
Also, another task for team was the online tracker component, which the team was assigned to work on refactoring it into a service that will include an indication as to whether the user is online or offline. The main idea behind this was to have the service include an indication in the form of green light signaling the user is online or a red light for offline. That is to say, the user is connected to internet or has no internet connectivity. Even though, Jason had this aspect of the work completed, which work exactly as we have projected it to do and ready to push back for consideration in sprint 3, we were unsure if AMPATH will accept it. The good news to this is that the pull request got accepted and it is now part of the AMPATH app.
Again, back to our offline data capture task, the idea of using local storage system was established and we were going to research how to syncs the data to AMPATH main server. We were unsure of the encryption part and as far as I know, the team hasn’t been able to lay hand on something useful regarding how we could encrypt our data. Based on our research, we could synchronize our local storage with the main server through pouchdb; we found out that we could only achieve our goals by using pouchdb even though there might be several tools out there to do the same job. As we did in the proceeding sprint, we continued to dig deep into pouchdb by learning some tutorials of how to synchronize data between two servers and we finally landed on the idea that led us to install the pouchdb on the AMPATH app. We had error initially when we tried to install it but Jason figured it out that we could only do that by cloning a fresh copy of the ng2-amrs from the original repository. The errors exist because we modified the code setting in the beginning for compilation issues. Now we are able to remotely store dummy data in our pouchdb that synchronize with our AMPATH app.
In summary, I would say even though we were challenged in this sprint, with the enthusiasm and passion for the work we were able to have something going and I believed the team is keeping up with the enthusiasm that we put into work in the previous sprints and for being able to experiment pouchdb with the AMPATH app, we are confidence that our assignment would be accomplished at the end.
This pattern is one among the entire patterns that I am not surprise of the ideas discussed in it even though I might not have thought of them as something important if I had not read this pattern. It is quite obvious that as a newcomer to an industry with more experience craftsmen, I will be thinking of how to contribute to my team and also to get the trust of my employer. It won’t be surprising that my employer or team members are wondering how I would fit in the team and be productive to them; but with the ideas from this pattern, that is the least to think of. For instance, there are so many ways that as a newcomer, I can contribute to my team. As the writer rightly said, volunteering for simple and smaller task within the team will enable me to grow with confidence and self respect. With the ideas of this pattern at the back of my mind, I would be coming forward to volunteer for tasks that looks small and could be achieve with or without little effort. I believed this would help deepen my knowledge as I go as well as help me built a reputation for myself. I also think as a newcomer, even if you have the experience that is required to do major tasks, you would still need to humbly start from sweeping the floor whiles trying to tackle the bigger ones. My reason for saying this is that, team members might think you want to show off and you might end up losing the needed support from them.
The pattern also discussed the issues of being condemned to do the minor tasks but I wouldn’t see this as a condemnation provided they are not too much for me to handle; what I would need to is to keep a close eye on what the team is doing regarding the major works making sure I understands what they does and if there are unclear stuffs, then I would ask questions. Also, I won’t be intimidated to sweeping just the floor but would be taking challenging task as well. In fact, I would try to make time to sweep the floor which would serve as something that interest me in the team just to have the passion for it.
This pattern is very important to every young developer who wants to stay on track of his ambitions. As the writer rightly said, it is hard to protect your passion, let alone grow it in a very constrained environment. I know as an inexperience apprentice seeking to explore the industry of software development, I am going to face many problems not limited to doing what I will not like. For that reason, I will need to find something that interests me at work in order to survive the challenges that will arise. I think it might be challenging to find something as you are not working for yourself; your employer will have his predefined requirement and conventions that might conflict with your passion. One thing I am not sure it is properly address is the issue of doing something you love even though the writer offers some suggestions. According to Paul Graham, “to become a successful developer may be to work on what you like and to do something well, you have to love it”. I have an issue here because, not all your assignment at work will be what you will like to do. I understood to grow my passion, I will need to set clear boundaries within which I am willing to work. So if the work at hand doesn’t falls within my set boundaries, do I quit my job? In those situations, what do I do then? I also strongly agreed with the writer about immersing yourself in some of the great literature of our field. I think this book will serve as a great reference tool to deal with most problems arising outside the classroom upon graduation as far as the patterns are concern. This book will be my dictionary to all kinds of situation that I might come across as I travel the journey in the software development industry.
I have seen this pattern as the most challenging to deal with among the entire pattern I have read so far. Even though it offers some strategies not limited to walking out of meetings that has become abusive and redirecting cynical conversation toward constructive topics or refusing to distribute code that doesn’t meet your minimum standards, your team members and even superiors whom you take directions from might develop the impression that you lack respect for them and the penalty can go as far terminating your employment.
Sprint 3 has been very challenging due to the weather interruption of our meetings. In my opinion, this print has not been effective even though we individually learned or did something that was geared toward accomplishing our task for the sprint. In this regards, I think our goals for this sprint has not yet been met. For instance, we started sprint 3 planning by deciding on what service to work as a team. We chose the offline data capture service to work with. this service was chosen with the mindset that the app is to collect data in the remote location where there is no internet access, so that when the user comes back to a network zone the data that has been gathered is either automatically synchronized with the main server or manually update the server to add up the new data.
Also, the team was again, assigned to work on refactoring the online tracker component of the app into a service that will include an indication as to whether the user is online or offline. This service will include an indication in the form of green light signaling the user is online or a red light for offline. This will basically tell the user whether he/she is connected to internet or has no internet connectivity. Thanks to Jason, this aspect of the work has been completed and ready to push back for consideration. He has re-factored that part to work exactly as we wanted it to do.
In order to achieve this goal we then tasked ourselves to go research into offline data services that uses angular platform as the AMPATH app is an angular based app and study pouch db to acquire knowledge of how to synchronize the data captured remotely to the local server. With regards, I spent quit amount of time studying tutorials on pouch db and couch db which I think will work well with synchronization of our work if properly implemented.
Again, Jason and Rick Phillips came up with the idea for implement the local storage which I think is working well with AMPATH app. We can remotely save data into it. We are now working on synchronizing the data into the server which I think this a part that pouch db come in to play. I am pretty much sure based on my little knowledge with the pouch db, it’s going to work out for us. I am confidence about that because in my exploration of the pouch db, I noticed that pouch db got doc count and update sequence. The update sequence tells you how many revisions have been made to the entire database and this is the thing that help synches all the databases together. It also has a function such db.changes which keeps pulls changes to the database. And to do that, live have to be true. Live true tells it to keep pulling the changes to the database.
Besides, per the recommendation by Jason, I had also learned a couple of angular tutorials which help in figuring out of what is going on in the app
Though it has been a rough print taken into consideration the snow storms that kept the team out of meetings, I believed the team kept up with the enthusiasm that it put into work in the previous sprints and we are on the way to having more work accomplished in our future sprints.
This pattern is one among the many which I have drawn so much knowledge and think will go a long way to help me grow in my future employment activities as far as software development is concerned. Educationists will tell you that learning is a gradual process and I know it’s not going to end in the classroom when the time come and I am out of the classroom to the field to face the world. This pattern has just reaffirmed that learning is still going to take place afterward. It is really hard as David H. Hoover admitted to say you don’t know when they expect you to know what they are asking you to deliver. But for my own good I will not be tempted to give quick answers to questions that will put me in trouble later on. Again, this pattern has also given me the idea that as an apprentice, my goal is not to become an expert but that will come naturally as I go the journey and explore deep into an interesting areas of learning.
I strongly agreed with the point that when your answer questions, you become clarified of your own knowledge. This is true because, anytime I help someone do something or explain something to someone, I will never forget that subject again; that is stick in my head forever. I used to be shy to speech in public even if I know the answer but as I grow and become more familiar with difference group of people, things began to change. From then, anytime a question is asked in the mixed of people, I always try to be first to respond to it if only I have an idea of what is being asked because I know how it help me in understanding the scope of my knowledge better.
I have been trying to cherry pick these patterns but I realized going through all of them will help me more because, they are interconnected. So far, with what I have learned, all the patterns has something unique that I think if carefully adopted will go a long way to help me deal with all the problems I will be facing as an inexperience apprentice.
This pattern has reopened my mind on how the society expects us to function without taken into consideration what the individual passion is. I kind of knew many point mentioned in this pattern but didn’t know how to deal with them until I read this pattern. It is true that the community I live in wants me as a young graduate to get a nice reputable job with lucrative sum of money. They would expect me to have solutions to problems at the tips of my hands. But the little I know is that learning is an ongoing process and takes place gradually. Implies I might get my four years college training and graduated alright but my learning doesn’t end there. As an apprentice, I should continue to learn in order to achieve that mantle of the journeyman. Looking up to satisfy the society would do me no good than to draw me back from the long term goals that I have set for myself. Being able to growth in this industry requires me to be patience and stay focus to my long term goals.
One thing that marvels me is promotions. I didn’t see promotion as a detractor until I studied this pattern. I usually would take promotions as a reward for your good and professional word. But after reading this pattern, I have come to realized that not all promotions are worth taken. For example, as a software developer, taken a promotion to managerial position that has no connection with your previous duties will harm you at the long round. I would rather demand an increase in pay than promotion in order to stay focus on my passion for developing.
Also, it’s a norm, and as society demands, people would always seek a well paying job than seeking to develop their skills. It is quite challenging to work for less money when you know you can get more for the same input. But that notwithstanding, one need to weigh passion and long term ambition for his career against the present even though, I think the long term would pay you than your present.
This sprint session was really tough for me at the beginning. I was confused as to what exactly was expected from us and was stressed for some time. Not having a sense of direction regarding which specific file to look at was a big issue. Thanks to the team members especially Rick Phillips who came out with an outline of what the team at that point need to focus on.
First and foremost, we started the sprint by deciding how we want to manage the gitHub repository. We came out with the decision that Rick Phillips should make a copy and give every team member the right to pull and edit. We also had to read the user story by the AMPATH which was quit straight forward. I did not know all these at the beginning.
Also, one most important among our task was to come up with design ideas to implement the ng2-amrs offline module and I think it is a good idea to have such a system. If my memory is right, I think we concluded with an idea that there should be a front server, intermediate and the remote server. Even though we are not sure if that will work for AMPATH, I believed we had a good idea. The intermediate server will act in between the remote server and the front server. The offline service would then be pending within the intermediate servers and anytime service is restored the front and the remote server would be updated.
Rick Phillips again draws our attention to the router component which helped us dig more to see how components are in connection with each other. With regards, we try to understand the AMPATH node paths on mapping the routes of the code in connection with AMPATH server; we together experimented some search by checking the URLs to see what component get invoked when a particular call is made. Even though things were not quit clear, I still have little ideas as to how some of the component got called. This was really helpful in understanding some of the parts in the ng2-amrs code that I do not understand earlier. Digging to the router component too has caused us as a team to do more outside the project search and tutorials to understand better how routing in angular work. Though, at this point, I cannot strongly say I understand how it works, I still had little knowledge which help me understands things to the point the team discussion has been. I will continue to explore the router component to improve on the little knowledge I had from this sprint.
Besides, per the recommendation by Jason, I had also learned a couple of angular tutorials which help in figuring out of what is going on in the app. Though it has been time consuming trying to figure out things by ourselves, the sprint has actually challenge me to learn more stuffs on angular and above all routing which I have never thought of. I believed if the team keeps up with the enthusiasm that it put into work in this sprint period, we would have more work accomplished in our future sprints.