Sprint 6 was a continuation of sprint 5 and hasn’t had much difference. As usual, we started sprint 6 by reviewing what was done in sprint 5, particularly our achievements and failures. Jason updated us with the version of code to work with at that point. Our activities in sprint 6 was a built up from previous sprints. Also in our last meeting, we went over everything we did so far from sprint 1 through sprint 6 and it appeared a lot has been done though there is still some work to do.
Sprint 6 meetings went on successfully without any interference and we had very effective meetings and discussions. Among the activities that enforce effectiveness in sprint 6 was work sharing. Jason share the work among us and that kind of put everybody busy trying to come up with specific tasked result. We held effective discussions, with every member of the team coming up with some ideas which usually called for more explanations and discussion for consideration. Rick Phillips continued to offer advice but this time, was very involved actively in trying to help us have something presentable at the end of the sprint. Jason also continually integrates ideas we came up with from our meeting, slack interaction with the team members especially Rick Phillips and from DJ of AMPATH into code.
Also, we moved away from encryption because we think other teams are working mainly on that aspect of the project and we doing that too seems double work to us. This idea helped us stayed focus on our offline data capture task.
Besides, from sprint 5, the issues we had with pouchdb was the fact that it capture a bunch of data which we think might have not been what been what we wanted; we at least wish to filter the result into certain fields in order to handle the limitations of storage space and that led us to trying to come up with a new GUI that will at least capture enough data for the user when he/she is offline. After several discussions, we could not exactly tell what field to keep and what to leave out. With regards, Rick Phan and Jason contacted DJ again as to what exactly they want for the new GUI. DJ then gave us a list of five things they wanted the new GUI to display. They wanted the user to b able to get the General info of a patient, Patient visits, Vitals, Lab results and HIV Summary. I was tasked to design a mock up for this, which I was working on. But DJ wanted to see it as soon as possible and Jason quickly responded to it and DJ accepted it and the team sticks that model.
In summary, I think sprint 6 was very successful and I love the enthusiasm and passion that we put into work. Even though, we are not totally done and the semester is almost ended, the team has something to contribute to AMPATH. I believe the work sharing that was listed on trello board also helped kept everyone busy. For the first time I learnt an abstract way of how to design GUI and mock ups in blasamiq in sprint 6.
WordPress.com is excited to announce our newest offering: a course just for beginning bloggers where you’ll learn everything you need to know about blogging from the most trusted experts in the industry. We have helped millions of blogs get up and running, we know what works, and we want you to to know everything we know. This course provides all the fundamental skills and inspiration you need to get your blog started, an interactive community forum, and content updated annually.
This pattern also dealt with a very important aspect in our everyday activities as an apprentice. I will say feedback are necessary because they do not just correct me but they also guide me to explore new directions and track specific causes to my failure. Even though, we got positive and negative feedback, I strongly believe if you are able to accept them regardless of what kind they are and do a thoroughly assessment of yourself, they can be useful to you. Sometime, you might believe yourself and try counter defends yourself by explaining as to why you did something to a criticism instead of accepting it as a feedback. Getting feedback that enable you to figure out what to do more or less is very important to your success. I have drawn a lot of ideas from this pattern that I think will go a long way to help me stay focus in the software development industry.
For instance, I will be very mindful of what could come of me if I am in the teams where my skills are above average or below average. I will be very careful not to think I am the best when encounter with such situation. I will also not down grade myself too much to the extent that it will destroy me because I am the less skill among the team I am working with; it will give me the opportunity to extend my tentacle and learn more to catch up with them should that be the situation.
I really like the ideas discussed in this pattern. Because, as a newcomer, I am bound to face some shocks regarding feedback I will receiver but with this pattern’s ideas in mind, I think these shocks could be turn into something useful that will help me assess myself. I wasn’t even aware of some of those techniques for obtaining feedback such as test driven development, Exams and certifications that have been discussed in this pattern until I read it. Before reading this pattern and if I haven’t come across it, I will just assume I didn’t meet the standard a company might want if I am not offered a job after attending an interview. I wouldn’t bother myself to do a follow up to know why and what I need to improve on. The ideas in this pattern are really going to help me in the future.
I chose this pattern because it is in connection with my previous pattern “record what you learn”. I also find some useful links to expose your ignorance pattern too. It does made sense to me that after you record what you learn, you share them for other people to benefit from your learning; sharing with others will be easy because you already have them documented. You can share what you learn in many ways such blog post, tutorials and one on one or group discussion with people you think might be interesting in the topic. One on one discussion is sometimes embarrassing if your target group already knows the subject but it is good place to start when you find people interesting in knowing what you learnt. Sharing is not always easy for me because I always feel like someone has already dealt with what I learnt and no one might need it. But I was proven wrong in one of my presentation as what I shared was straight forward and the people like it very much than what they already knew regarding the subject matter. Also, in the mixed of a team 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 helps me in understanding the scope of my knowledge better. This boiled to the point that sharing what you learn will not only make you valuable to the community but will also let you stay on top of your field of study.
Besides, the challenging expect of sharing what you learn is the ethical part of it. Sometimes how to re-factor what you learn into your own work is difficult because it is straight forward knowledge and you can’t go around it to make you own.
After reading this pattern, it has reinforced the power of recording what I learn as it will make it easy for me to share what I learn with others. I also didn’t pay attention to the effects of what I shared in the past and after reading this, it has opened my eyes to look out for the legal, political and financial implication to what I share in the future.
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.