Monthly Archives: February 2017

Reflections (2/22/17) Week 4

After deciding to have the reflections due at the end of each sprint instead of the end of the week, this reflection is going to summarize what happened during the last two sprints. The team began by forking the AMPath code on github and cloning the code to their computers. After getting the code settled and making sure everyone can open up the code in Webstorm, we tried to make sure that everyone was able to connect to the AMPath database through local host 3000. A majority of us had a problem where we got the login page to AMPath to appear, however the bottom right kept saying that the server was offline instead of online so we could not connect to it. That obstacle was later solved thanks to Ryan and other people in the class for searching for workarounds to the problem. The most common fix was a google chrome extension that you could download and it will allow you to connect to the server, however when that extension ran on my laptop it disconnected me from using the web. Later on, we found another fix that Ryan suggested which includes adding code to an xml file in the OpenMRS standalone folder and the connection worked out well with no side effects. We also added the proper OpenMRS directory to the server settings which connected us properly.

Other than connecting to AMPath, some users in our team had trouble starting OpenMRS itself since it took around 30 minutes to open for people, later on that issue was resolved but i do not recall what fixed it for them .We troubleshooted by giving them faster internet through a wireless adapter but that did not work out, they probably reinstalled it. We were also instructed to modify the login page of the AMPath and also get a proper understanding of the code which some of us did, but not all. We are now awaiting access to the tracker so we can help fix bugs and as well look forward to the EPIC goal that we are going to do as a class.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

Software Dev Capstone Week 4

What we did this week in Capstone. This week was more of an experimentation week, more playing around with the codes. The main concern for this week is to get everybody up to date so that everyone can run ng2-amrs with 0 problems.

  1. Make sure everyone can run ng2-amrs and be connected with either openmrs standalone or the openmrs SDK.

We ran into some major issues with one of our team member unable to get openmrs server to run properly no matter what. It even went as far as reformatting the laptop but the issue still popped up. We may have to ask the OpenMRS community for help on this critical issue.

By next sprint we will have JIRA tickets set up and have minor issues to fix within the OpenMRS project. Hopefully that let us focus on a small part of the large network of OpenMRS modules. This will let us become more familiar with the code also.

From the blog CS@Worcester – Site Title by nealw5 and used with permission of the author. All other rights reserved by the author.

Retrospective Sprint 2

Overall sprint two went well. Our basic Trello tasks were completed which included setting up, connecting, and building our APATH login. The main issue that arose with connecting to AMPATH was the server on the site; it wouldn’t allow any user to connect normally. Therefore either the user could download a chrome extension, which for some of us caused our Wi-Fi to crash, or add a code snippet to one of the xml file. Option B proved to be the more promising choice that most of us went with. Some of us were able to begin rewriting some of the module, nothing too special yet, but it will still be placed onto the backlog of the next sprint.

A big part of our retrospective was that we realized our communication and teamwork has been rather poor. Up to this point, the majority of the work has been done independently which we believe to be partly caused by nothing has been too extreme or challenging that we have had to collaborate on, but nonetheless we are looking to improve in those aspects come the next sprint. On the other hand we have had some issues with attendance and participation in daily scrums that we addressed and hope will be fixed for the next sprint.

 

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

Learning Reflection, February 22

This week I spent a lot of time reading and learning stuff on Angular 2. I bought the ng-book 2 along with the beginner’s screen cast; I spent a lot of time reading the book and listening to the screen cast.

I found the first few chapters in the book good and the first half of the screen cast was good. I could not understand the other half of the screen cast and some chapters in the book were not written well. I plan read more chapters in book and if I don’t like it I plan to return the book. I expect a lot more from a book worth $79.

The deeper I delve into Angular 2 I find that there are a lot of things I don’t know, things like reactive programming and asynchronous programming.

The problem that I find frustrating is that there aren’t many good books on Angular 2.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

The Clean Coder: Chapters 9 & 10

Chapter 9 “Time Management” revolves around the different strategies we can use to ensure the proper utilization of time by effectively managing it. Author Martin fist discussions about meetings. He argues meetings are necessary but at the same time they might huge time wasters. He suggests be very careful about which meetings you attend and which you politely refuse. When the meeting gets boring, leave. If you find yourself stuck in a meeting that is not a good use of your time, you need to find a way to politely exit that meeting.
Next big thing in this chapter Martin discuss is about disagreements. He believes without data, any argument that doesn’t forge agreement within a few minutes simply won’t ever forge agreement. The only thing to do is to go get some data. The question arises how do you get the data you need to settle a disagreement? Sometimes you can run experiments, or do some simulation or modeling. But sometimes the best alternative is to simply flip a coin to choose one of the two paths in question.
Furthermore, Martin goes on to lists some intellectual exercise that helps build concentration and focus. He talks about the pattern of his sleep; the caffeine he consumes; the way he recharges himself by taking naps, meditations, and muscle focus. Never the less he explains how the well-known Pomodoro Technique, shortly knows as tomatoes, manages his time and focus.
This chapter,to sum up, was very much productive to me. I often find myself falling in the trap of priority inversion. I find ways to avoid doing the real work. I convince myself that something else is more urgent, and I do that instead. As the writer suggests from now on wards, I will try to evaluate the priority of each task, disregarding my personal fears and desires, and execute those tasks in priority order as best as I can.

 
Next chapter “Estimation” is about takes on estimates in different ways. Martin defines the term estimate in terms of business and developers point of view. He states business likes to view estimates as commitments. Developers like to view estimates as estimates. Furthermore, author describes the different techniques to make estimations such as wideband delphi, flying fingers, and planning poker.
The biggest takeaway from this chapter to me is to be more precise in my commitment. I will not commit unless I know for certain I will succeed.

From the blog CS@Worcester – Software Dev Capstone by osworup007 and used with permission of the author. All other rights reserved by the author.

The Clean Coder: Chapters 9 & 10

The Management. Such an interesting topic for a book dedicated to becoming a professional. What Uncle Bob is talking about here is two distinct forms of management; personal management and business management. Interestingly enough, these two topics become intertwined quite often. The first instance in which this appears in the book is when he talks about meetings. When the section starts on meetings Uncle Bob stated something I’ve been saying for years now.

There are two truths about meeting.
1. Meetings are necessary.
2. Meetings are huge time wasters.

My current position requires me to attend an occasional meeting, typically conference call style. The one thing I have found is that these meetings are very important to keep people up to date on whatever the contents of the meeting are and it helps get every one on the same page. However, every meeting I have been apart of was by no means short. I believe the shortest meeting I was ever apart of still lasted 45 minutes and by the end I walked out with no more knowledge then I had gone in with. Having had these experiences, when I saw Uncle Bob’s statement about the two truths of meetings I felt relieved that I wasn’t the only one that felt this way. Uncle Bob went on to talk about the different meetings that are had in a Scrum methodology of software development. Reading his thoughts on how these scrum meetings should go is very interesting. Currently with the Capstone class at WSU we are using Scrum and I can see how some of these meetings could go very long. I believe my team and I have done a good job and avoiding wasted time during these meetings, though.

The rest of chapter 9 covers ways to stay focused. Fortunately for me, most of these methodologies or theories appear to be common sense to me and I didn’t take away that much new information from these paragraphs.

Chapter 10 talks about estimates. Interestingly enough, I’ve had to create a few estimates in my line of work. Granted these were extremely small scale and usually completed in under an hour. The thing I learned from creating those estimates was, it’s incredibly hard to estimate time for when things go wrong.

As I mentioned in a previous blog post I listened to a podcast (You can find it here ) on software estimation a few months back. This chapter from Uncle Bob felt like a refresher on the things talked about in the podcast. What I find most fascinating about this subject, is that in my field an estimate is occasionally taken as “set-in-stone” and “done-deal” type of artifacts. However, that’s what business has turned it into and that was never what estimates were intended to be used for.

I don’t have too much more to say about estimates for software, seeing as I haven’t had to ever create one yet. However, I know when my time comes to finally use this information, I will be referring back to Uncle Bob!

From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapter 9-10

Chapter 9 and 10 of Clean Coder talks about time management and estimation. Both of these issues goes hand in hand. Meetings are abundant in workplaces and it can lead to huge amount of time wasted that could be better used to focus on the project. Of course you need meetings to keep track of progress, give updates of project status, and check if the project is on track with expectation. The key is to find a balance between those two.

Time estimation is something every project faces. The book gives good advice on one should make probabilistic estimate unless they are absolutely sure they can give a hard number of the time it takes to finish a task. In the real world this goes way less smoothly. Many projects even if you are confident in your own ability relies on many other people from different teams, department, and even other companies. You can give an estimate that is only as good as if other people also make their estimate. That is an important key to keep in mind. Sometimes, even when making probabilistic estimation, upper management may want certain goals to reach by a certain deadline. This lead to anything from crunch time to unexpected delay in other task. Practical estimate is good advice, but sometimes it just does not match the practical reality.

From the blog CS@Worcester – Site Title by nealw5 and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 9 and 10

Chapter 9: Time Management
This is a very interesting chapter as everything revolves around
time and it is something that we never seem to have enough of am I right? Of
course I am. I myself have been trying for years to come up with some sort of
consistence as far as a schedule goes, but with my situation up until I started
with college was different as I am on disability so I tried to keep to a
regular schedule so I didn’t get caught in some weird time continuum while I
figured out my next step. I have found it difficult to manage time while in
school though and try to set a schedule, but each semester that changes and
well I get out of sync. Thank goodness this is the final semester (well until
grad school if I go that route) and I will hopefully be gainfully employed
shortly thereafter. Anyways I suppose I should get back to the chapter at hand,
time management. I found it amusing how he referred to meetings as necessary
and huge time wasters because it is so true no matter what your job is. I never
gave much thought about how much per person it actually costs for a meeting.
There are a lot of good points in the chapter concerning meetings in general,
but a lot of it is in my opinion common sense. Have and agenda and a goal. Well
of course there is an agenda and a goal, I know there are a lot of times where
meetings don’t seem to have either but there generally is. I really like the
stand up meeting like we are suppose to do for Agile development. Twenty
seconds per question, no more than a minute per person; in, out, done the way
it should be in my opinion. Short, sweet, and to the point I say. No beating
around the bush. I liked his quote from Kent Beck, “Any argument that can’t be
settled in five minutes can’t be settled by arguing.”. Awesome words of wisdom.
There are a decent amount of items in this chapter I really enjoyed, especially
how he compared stuff to D & D type games, like focus manna, if you use up
all your focus manna in the meeting, you’ll have none left for coding, how very
true indeed.
Time Boxing and Tomatoes. I am definitely going to give this a
shot. I think it is a really great idea to set a timer and let nothing
interfere with your plan, actually carrying out to a tee may be a different story
but still worth a shot none the less. I love it; dividing your time between
tomato and non tomato time. I am actually laughing right now thinking about it,
how many tomato’s did you get done today Jim? 
Only 15, slacker! Over all I thought this chapter was well done and a
very important, if not one of the most important things that needs to be worked
out. If you can’t learn how to manage time effectively and overcome adversity
when something hinders your plans, you will have a hard time getting things done
and you will probably find yourself moving out of a job versus up in the job.
Chapter 10 Estimation:
I really like how he put it right out there in the first sentence.
“Estimation
is one of the simplest, yet most frightening activities that software professionals
face. So much business value depends on it. So much of our reputations ride on
it. So much of our angst and failure are caused by it. It is
the primary wedge that has been driven between business
people and developers. It is the source of nearly all the distrust that rules
that relationship.”

He hits the nail on the head as far as what an
estimate is and how they are interpreted differently. As commitments and
guesses. In reality an estimate is just a guess at when you think you will be
done, however they are never set hard in stone, but the issue is that the
business man hears oh it will be done by such and such date, great. I mean
there really isn’t much that I have to say on this chapter other than when I
give an estimate, I try and be as clear as possible and look at all the facts
and take in all the information that I have and add on some extra time just in
case it falls through. I also make sure that I communicate if anything isn’t
going according to plan and adjust accordingly. There were a lot of great
techniques he described, but I think it is something that has to be learned by
doing, and by making mistakes.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 9 and 10

Chapter 9: Time Management
This is a very interesting chapter as everything revolves around
time and it is something that we never seem to have enough of am I right? Of
course I am. I myself have been trying for years to come up with some sort of
consistence as far as a schedule goes, but with my situation up until I started
with college was different as I am on disability so I tried to keep to a
regular schedule so I didn’t get caught in some weird time continuum while I
figured out my next step. I have found it difficult to manage time while in
school though and try to set a schedule, but each semester that changes and
well I get out of sync. Thank goodness this is the final semester (well until
grad school if I go that route) and I will hopefully be gainfully employed
shortly thereafter. Anyways I suppose I should get back to the chapter at hand,
time management. I found it amusing how he referred to meetings as necessary
and huge time wasters because it is so true no matter what your job is. I never
gave much thought about how much per person it actually costs for a meeting.
There are a lot of good points in the chapter concerning meetings in general,
but a lot of it is in my opinion common sense. Have and agenda and a goal. Well
of course there is an agenda and a goal, I know there are a lot of times where
meetings don’t seem to have either but there generally is. I really like the
stand up meeting like we are suppose to do for Agile development. Twenty
seconds per question, no more than a minute per person; in, out, done the way
it should be in my opinion. Short, sweet, and to the point I say. No beating
around the bush. I liked his quote from Kent Beck, “Any argument that can’t be
settled in five minutes can’t be settled by arguing.”. Awesome words of wisdom.
There are a decent amount of items in this chapter I really enjoyed, especially
how he compared stuff to D & D type games, like focus manna, if you use up
all your focus manna in the meeting, you’ll have none left for coding, how very
true indeed.
Time Boxing and Tomatoes. I am definitely going to give this a
shot. I think it is a really great idea to set a timer and let nothing
interfere with your plan, actually carrying out to a tee may be a different story
but still worth a shot none the less. I love it; dividing your time between
tomato and non tomato time. I am actually laughing right now thinking about it,
how many tomato’s did you get done today Jim? 
Only 15, slacker! Over all I thought this chapter was well done and a
very important, if not one of the most important things that needs to be worked
out. If you can’t learn how to manage time effectively and overcome adversity
when something hinders your plans, you will have a hard time getting things done
and you will probably find yourself moving out of a job versus up in the job.
Chapter 10 Estimation:
I really like how he put it right out there in the first sentence.
“Estimation
is one of the simplest, yet most frightening activities that software professionals
face. So much business value depends on it. So much of our reputations ride on
it. So much of our angst and failure are caused by it. It is
the primary wedge that has been driven between business
people and developers. It is the source of nearly all the distrust that rules
that relationship.”

He hits the nail on the head as far as what an
estimate is and how they are interpreted differently. As commitments and
guesses. In reality an estimate is just a guess at when you think you will be
done, however they are never set hard in stone, but the issue is that the
business man hears oh it will be done by such and such date, great. I mean
there really isn’t much that I have to say on this chapter other than when I
give an estimate, I try and be as clear as possible and look at all the facts
and take in all the information that I have and add on some extra time just in
case it falls through. I also make sure that I communicate if anything isn’t
going according to plan and adjust accordingly. There were a lot of great
techniques he described, but I think it is something that has to be learned by
doing, and by making mistakes.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 9 and 10

Chapter 9: Time Management
This is a very interesting chapter as everything revolves around
time and it is something that we never seem to have enough of am I right? Of
course I am. I myself have been trying for years to come up with some sort of
consistence as far as a schedule goes, but with my situation up until I started
with college was different as I am on disability so I tried to keep to a
regular schedule so I didn’t get caught in some weird time continuum while I
figured out my next step. I have found it difficult to manage time while in
school though and try to set a schedule, but each semester that changes and
well I get out of sync. Thank goodness this is the final semester (well until
grad school if I go that route) and I will hopefully be gainfully employed
shortly thereafter. Anyways I suppose I should get back to the chapter at hand,
time management. I found it amusing how he referred to meetings as necessary
and huge time wasters because it is so true no matter what your job is. I never
gave much thought about how much per person it actually costs for a meeting.
There are a lot of good points in the chapter concerning meetings in general,
but a lot of it is in my opinion common sense. Have and agenda and a goal. Well
of course there is an agenda and a goal, I know there are a lot of times where
meetings don’t seem to have either but there generally is. I really like the
stand up meeting like we are suppose to do for Agile development. Twenty
seconds per question, no more than a minute per person; in, out, done the way
it should be in my opinion. Short, sweet, and to the point I say. No beating
around the bush. I liked his quote from Kent Beck, “Any argument that can’t be
settled in five minutes can’t be settled by arguing.”. Awesome words of wisdom.
There are a decent amount of items in this chapter I really enjoyed, especially
how he compared stuff to D & D type games, like focus manna, if you use up
all your focus manna in the meeting, you’ll have none left for coding, how very
true indeed.
Time Boxing and Tomatoes. I am definitely going to give this a
shot. I think it is a really great idea to set a timer and let nothing
interfere with your plan, actually carrying out to a tee may be a different story
but still worth a shot none the less. I love it; dividing your time between
tomato and non tomato time. I am actually laughing right now thinking about it,
how many tomato’s did you get done today Jim? 
Only 15, slacker! Over all I thought this chapter was well done and a
very important, if not one of the most important things that needs to be worked
out. If you can’t learn how to manage time effectively and overcome adversity
when something hinders your plans, you will have a hard time getting things done
and you will probably find yourself moving out of a job versus up in the job.
Chapter 10 Estimation:
I really like how he put it right out there in the first sentence.
“Estimation
is one of the simplest, yet most frightening activities that software professionals
face. So much business value depends on it. So much of our reputations ride on
it. So much of our angst and failure are caused by it. It is
the primary wedge that has been driven between business
people and developers. It is the source of nearly all the distrust that rules
that relationship.”

He hits the nail on the head as far as what an
estimate is and how they are interpreted differently. As commitments and
guesses. In reality an estimate is just a guess at when you think you will be
done, however they are never set hard in stone, but the issue is that the
business man hears oh it will be done by such and such date, great. I mean
there really isn’t much that I have to say on this chapter other than when I
give an estimate, I try and be as clear as possible and look at all the facts
and take in all the information that I have and add on some extra time just in
case it falls through. I also make sure that I communicate if anything isn’t
going according to plan and adjust accordingly. There were a lot of great
techniques he described, but I think it is something that has to be learned by
doing, and by making mistakes.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.