Monthly Archives: January 2017

Week 2 Reflections

Reflections on Week 2
This week was actually pretty good for me. I think that our
team works well together and that it is going to be a productive semester. This
week I was able to get my accounts set up with OpenMRS and trello and learned a
bit about Scrum and finally started to put it to use. I like it because I am
finally putting everything that I have been learning so far to use or will be.
Aside from getting the basics set up we are going to be using Angular this semester
and I have never used it before. I am familiar to some extent with Javascript
but I feel that I have so much more to learn with Angular even though it is based
on JS.
I went through the Angular Tour of Heroes tutorial here and I have to say
that though I enjoyed it, I am still a bit foggy and will be going back through
it and doing another tutorial I have found. I am fairly comfortable with a lot
of it, but when it came to routing and navigation I felt a little lost so I am
going through some more on that area. I really like how the framework actually
works though and think that it is going to be a great experience this semester
and hope to be proficient with it as I hope to get into Web Development of some
sort and I know that this is used a lot. It doesn’t really take a lot to get an
app off the ground running, but digging deeper is going to be fun. I really
like how it is easy to split your app off into multiple modules or components
as your project gets bigger. I am confident that it will all come together
though and I will be proficient before I know it.

I am looking forward to what this week brings and what new
challenges are ahead of me. I am taking everything as it comes in and trying
not to put too much on my plate and so far I have been able to do that. 

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

Week 2 Reflections

Reflections on Week 2
This week was actually pretty good for me. I think that our team works well together and that it is going to be a productive semester. This week I was able to get my accounts set up with OpenMRS and trello and learned a bit about Scrum and finally started to put it to use. I like it because I am finally putting everything that I have been learning so far to use or will be. Aside from getting the basics set up we are going to be using Angular this semester and I have never used it before. I am familiar to some extent with Javascript but I feel that I have so much more to learn with Angular even though it is based on JS.
I went through the Angular Tour of Heroes tutorial here and I have to say that though I enjoyed it, I am still a bit foggy and will be going back through it and doing another tutorial I have found. I am fairly comfortable with a lot of it, but when it came to routing and navigation I felt a little lost so I am going through some more on that area. I really like how the framework actually works though and think that it is going to be a great experience this semester and hope to be proficient with it as I hope to get into Web Development of some sort and I know that this is used a lot. It doesn’t really take a lot to get an app off the ground running, but digging deeper is going to be fun. I really like how it is easy to split your app off into multiple modules or components as your project gets bigger. I am confident that it will all come together though and I will be proficient before I know it.

I am looking forward to what this week brings and what new challenges are ahead of me. I am taking everything as it comes in and trying not to put too much on my plate and so far I have been able to do that. 

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

Reflections and Learning (Week 2 1/31/17)

During this week, my team and I got more organized and set up our work environment. First and foremost, all the teams including ours decided to use the program Slack, which is pretty much a chatting software like Skype and discord but allows us to use different channels to talk as well as other beneficial communication features. We got together in our own channel which was named after our team, Zolinq and started to get everyone together on their as well as pinning messages on our channel board.

When we met up in the beginning of the week, we started to use Trello, a program to manage tasks and improve communication and organization throughout our team. After we accessed the Trello board from our course, I created a Trello for our own team and Kyle copied the tasks from the professor’s board onto our. Later on that week, I organized our Trello into 3 categories “Backlog”, “Doing”, and “Done”. I put all of the cards (tasks that we created for our team to maintain) into the appropriate pile and then decided to make another category for the writing aspects that are due more frequently, such as the blogs and daily scrums.  I learned how to maintain a Trello board for the team which is really cool.

One assignment that I didn’t expect to do was the Daily Scrums, which each team member have to post about their progress on the project so far in our chat channel. I understand why we must do it and the team didn’t upload their daily scrums the first time around since there really wasn’t much to report on. It was a bit unorganized, but now I learned I should have took the professor’s advice by making another channel for our team, specifically for daily scrums. I did that this week so that should not be a problem.

After getting the management duties settled, I started setting up my work environment to start coding the angular tutorial. I decided to do so on my PC first since its more powerful and I wanted to code on it first, so I installed the Webstorm IDE with the free one year license and also installed Node.JS which came with npm. I downloaded the quick start file and imported the project and then ran npm and it all worked well. It was really interesting setting up that environment.

While doing the tutorial, I had issues with the local host page on my browser compile successfully and refresh automatically. It turns out even the slightest syntax error can cause the application to freak out and I had to revert it a couple of times. I have to be careful of angular when i do JavaScript as it feels less robust than java or C++. The syntax for an app environment is sort of new to me but the web elements that I learned from web development was recognizable so I was able to understand it quicker than i thought.

Afterwards, I installed the environment on my laptop and helped my teammates who were having trouble installing it (its worse with different OS) and now we are all on the same page. The next time we meet, communication with my team will be all set, as we also made a Facebook group to keep us up to date with each other’s work. Communication with your team is important, as it was learned in the QA class, and I think we got that down. Next up is more angular and finding out the features we need to build for openMRS.

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.

The Clean Coder Chapters 3 and 4

The Clean Coder Chapters 3 & 4
Chapter 3:
I had favorable things to say about the first two chapters
because they kind of reminded me that no matter where you work or shall I say I
have worked, a lot of it rings true but it is also to me just common sense. I
mean saying no and saying yes? I feel like a bit too much is dedicated to this
and it gets old real fast and I want to skip on but I pushed through chapter 3
and well once again I have to say it is really to me a lot of common sense
things. I guess I shouldn’t say common sense, but for me I learned a lot of
this by trial and error and promising things to people that I knew I couldn’t
get done but just wanted to please so and so and felt that I would just deal
with the blow back later. You can only do that sort of thing so many times (for
me once or twice was enough) before you catch on and realize not to promise
things that you can’t deliver and to commit to things that you’ll do when you
say you will. I guess the book does a decent job at laying out situations and
the outcomes so hopefully people won’t make the same mistakes that Bob made. I
feel though that I have lived through all of the scenarios in some way or
another so I guess I got a chuckle out of it. He says that the language of
commitment can sound scary and it can help solve a lot of the communications
problems facing coders. He is absolutely right but it definitely takes time to
learn how to do it and be taken serious about it. You have to build trust and
being straight about things is the best way to do it.
Chapter 4:

I feel that this chapter is also about experience and a bit
of sense. This is all life stuff and applies to any form of work in my opinion.
He talks about preparedness and how coding is intellectually challenging and
how if you aren’t prepared for it your work will suffer. I find that this seems
like my dad is preaching at me when I was 16. I mean of course your work is
going to suffer when you can’t concentrate or when you are tired. The worst
code written at 3am, I have been there and don’t do that anymore because I have
learned the hard way and the good ole flow zone where you think you are
actually doing an awesome job reminds of the people who say they do their best
work high or drunk. Sorry it just doesn’t work like that as like he said, yes
you may get a lot done, but what did you miss? I am sorry but I guess I am kind
of disappointed with the first few chapters. I was good with the first two at
first but the next two to me seem to be more of the same lessons just in a
different context and I can’t write anymore about them. It does however seem
like the rest of the book will be decent to me. I thought his other book (
Clean Code) was good so I figured that this would be more of the same and I
hope the rest is.

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

The Clean Coder Chapters 3 and 4

The Clean Coder Chapters 3 & 4
Chapter 3:
I had favorable things to say about the first two chapters
because they kind of reminded me that no matter where you work or shall I say I
have worked, a lot of it rings true but it is also to me just common sense. I
mean saying no and saying yes? I feel like a bit too much is dedicated to this
and it gets old real fast and I want to skip on but I pushed through chapter 3
and well once again I have to say it is really to me a lot of common sense
things. I guess I shouldn’t say common sense, but for me I learned a lot of
this by trial and error and promising things to people that I knew I couldn’t
get done but just wanted to please so and so and felt that I would just deal
with the blow back later. You can only do that sort of thing so many times (for
me once or twice was enough) before you catch on and realize not to promise
things that you can’t deliver and to commit to things that you’ll do when you
say you will. I guess the book does a decent job at laying out situations and
the outcomes so hopefully people won’t make the same mistakes that Bob made. I
feel though that I have lived through all of the scenarios in some way or
another so I guess I got a chuckle out of it. He says that the language of
commitment can sound scary and it can help solve a lot of the communications
problems facing coders. He is absolutely right but it definitely takes time to
learn how to do it and be taken serious about it. You have to build trust and
being straight about things is the best way to do it.
Chapter 4:

I feel that this chapter is also about experience and a bit
of sense. This is all life stuff and applies to any form of work in my opinion.
He talks about preparedness and how coding is intellectually challenging and
how if you aren’t prepared for it your work will suffer. I find that this seems
like my dad is preaching at me when I was 16. I mean of course your work is
going to suffer when you can’t concentrate or when you are tired. The worst
code written at 3am, I have been there and don’t do that anymore because I have
learned the hard way and the good ole flow zone where you think you are
actually doing an awesome job reminds of the people who say they do their best
work high or drunk. Sorry it just doesn’t work like that as like he said, yes
you may get a lot done, but what did you miss? I am sorry but I guess I am kind
of disappointed with the first few chapters. I was good with the first two at
first but the next two to me seem to be more of the same lessons just in a
different context and I can’t write anymore about them. It does however seem
like the rest of the book will be decent to me. I thought his other book (
Clean Code) was good so I figured that this would be more of the same and I
hope the rest is.

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

The Clean Coder Chapters 3 and 4

The Clean Coder Chapters 3 & 4
Chapter 3:
I had favorable things to say about the first two chapters
because they kind of reminded me that no matter where you work or shall I say I
have worked, a lot of it rings true but it is also to me just common sense. I
mean saying no and saying yes? I feel like a bit too much is dedicated to this
and it gets old real fast and I want to skip on but I pushed through chapter 3
and well once again I have to say it is really to me a lot of common sense
things. I guess I shouldn’t say common sense, but for me I learned a lot of
this by trial and error and promising things to people that I knew I couldn’t
get done but just wanted to please so and so and felt that I would just deal
with the blow back later. You can only do that sort of thing so many times (for
me once or twice was enough) before you catch on and realize not to promise
things that you can’t deliver and to commit to things that you’ll do when you
say you will. I guess the book does a decent job at laying out situations and
the outcomes so hopefully people won’t make the same mistakes that Bob made. I
feel though that I have lived through all of the scenarios in some way or
another so I guess I got a chuckle out of it. He says that the language of
commitment can sound scary and it can help solve a lot of the communications
problems facing coders. He is absolutely right but it definitely takes time to
learn how to do it and be taken serious about it. You have to build trust and
being straight about things is the best way to do it.
Chapter 4:

I feel that this chapter is also about experience and a bit
of sense. This is all life stuff and applies to any form of work in my opinion.
He talks about preparedness and how coding is intellectually challenging and
how if you aren’t prepared for it your work will suffer. I find that this seems
like my dad is preaching at me when I was 16. I mean of course your work is
going to suffer when you can’t concentrate or when you are tired. The worst
code written at 3am, I have been there and don’t do that anymore because I have
learned the hard way and the good ole flow zone where you think you are
actually doing an awesome job reminds of the people who say they do their best
work high or drunk. Sorry it just doesn’t work like that as like he said, yes
you may get a lot done, but what did you miss? I am sorry but I guess I am kind
of disappointed with the first few chapters. I was good with the first two at
first but the next two to me seem to be more of the same lessons just in a
different context and I can’t write anymore about them. It does however seem
like the rest of the book will be decent to me. I thought his other book (
Clean Code) was good so I figured that this would be more of the same and I
hope the rest is.

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

The Clean Coder Chapters 3 and 4

The Clean Coder Chapters 3 & 4
Chapter 3:
I had favorable things to say about the first two chapters
because they kind of reminded me that no matter where you work or shall I say I
have worked, a lot of it rings true but it is also to me just common sense. I
mean saying no and saying yes? I feel like a bit too much is dedicated to this
and it gets old real fast and I want to skip on but I pushed through chapter 3
and well once again I have to say it is really to me a lot of common sense
things. I guess I shouldn’t say common sense, but for me I learned a lot of
this by trial and error and promising things to people that I knew I couldn’t
get done but just wanted to please so and so and felt that I would just deal
with the blow back later. You can only do that sort of thing so many times (for
me once or twice was enough) before you catch on and realize not to promise
things that you can’t deliver and to commit to things that you’ll do when you
say you will. I guess the book does a decent job at laying out situations and
the outcomes so hopefully people won’t make the same mistakes that Bob made. I
feel though that I have lived through all of the scenarios in some way or
another so I guess I got a chuckle out of it. He says that the language of
commitment can sound scary and it can help solve a lot of the communications
problems facing coders. He is absolutely right but it definitely takes time to
learn how to do it and be taken serious about it. You have to build trust and
being straight about things is the best way to do it.
Chapter 4:

I feel that this chapter is also about experience and a bit
of sense. This is all life stuff and applies to any form of work in my opinion.
He talks about preparedness and how coding is intellectually challenging and
how if you aren’t prepared for it your work will suffer. I find that this seems
like my dad is preaching at me when I was 16. I mean of course your work is
going to suffer when you can’t concentrate or when you are tired. The worst
code written at 3am, I have been there and don’t do that anymore because I have
learned the hard way and the good ole flow zone where you think you are
actually doing an awesome job reminds of the people who say they do their best
work high or drunk. Sorry it just doesn’t work like that as like he said, yes
you may get a lot done, but what did you miss? I am sorry but I guess I am kind
of disappointed with the first few chapters. I was good with the first two at
first but the next two to me seem to be more of the same lessons just in a
different context and I can’t write anymore about them. It does however seem
like the rest of the book will be decent to me. I thought his other book (
Clean Code) was good so I figured that this would be more of the same and I
hope the rest is.

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

The Clean Coder Chapters 3 and 4

The Clean Coder Chapters 3 & 4
Chapter 3:
I had favorable things to say about the first two chapters
because they kind of reminded me that no matter where you work or shall I say I
have worked, a lot of it rings true but it is also to me just common sense. I
mean saying no and saying yes? I feel like a bit too much is dedicated to this
and it gets old real fast and I want to skip on but I pushed through chapter 3
and well once again I have to say it is really to me a lot of common sense
things. I guess I shouldn’t say common sense, but for me I learned a lot of
this by trial and error and promising things to people that I knew I couldn’t
get done but just wanted to please so and so and felt that I would just deal
with the blow back later. You can only do that sort of thing so many times (for
me once or twice was enough) before you catch on and realize not to promise
things that you can’t deliver and to commit to things that you’ll do when you
say you will. I guess the book does a decent job at laying out situations and
the outcomes so hopefully people won’t make the same mistakes that Bob made. I
feel though that I have lived through all of the scenarios in some way or
another so I guess I got a chuckle out of it. He says that the language of
commitment can sound scary and it can help solve a lot of the communications
problems facing coders. He is absolutely right but it definitely takes time to
learn how to do it and be taken serious about it. You have to build trust and
being straight about things is the best way to do it.
Chapter 4:

I feel that this chapter is also about experience and a bit
of sense. This is all life stuff and applies to any form of work in my opinion.
He talks about preparedness and how coding is intellectually challenging and
how if you aren’t prepared for it your work will suffer. I find that this seems
like my dad is preaching at me when I was 16. I mean of course your work is
going to suffer when you can’t concentrate or when you are tired. The worst
code written at 3am, I have been there and don’t do that anymore because I have
learned the hard way and the good ole flow zone where you think you are
actually doing an awesome job reminds of the people who say they do their best
work high or drunk. Sorry it just doesn’t work like that as like he said, yes
you may get a lot done, but what did you miss? I am sorry but I guess I am kind
of disappointed with the first few chapters. I was good with the first two at
first but the next two to me seem to be more of the same lessons just in a
different context and I can’t write anymore about them. It does however seem
like the rest of the book will be decent to me. I thought his other book (
Clean Code) was good so I figured that this would be more of the same and I
hope the rest is.

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

The Clean Coder Chapters 3 and 4

The Clean Coder Chapters 3 & 4
Chapter 3:
I had favorable things to say about the first two chapters because they kind of reminded me that no matter where you work or shall I say I have worked, a lot of it rings true but it is also to me just common sense. I mean saying no and saying yes? I feel like a bit too much is dedicated to this and it gets old real fast and I want to skip on but I pushed through chapter 3 and well once again I have to say it is really to me a lot of common sense things. I guess I shouldn’t say common sense, but for me I learned a lot of this by trial and error and promising things to people that I knew I couldn’t get done but just wanted to please so and so and felt that I would just deal with the blow back later. You can only do that sort of thing so many times (for me once or twice was enough) before you catch on and realize not to promise things that you can’t deliver and to commit to things that you’ll do when you say you will. I guess the book does a decent job at laying out situations and the outcomes so hopefully people won’t make the same mistakes that Bob made. I feel though that I have lived through all of the scenarios in some way or another so I guess I got a chuckle out of it. He says that the language of commitment can sound scary and it can help solve a lot of the communications problems facing coders. He is absolutely right but it definitely takes time to learn how to do it and be taken serious about it. You have to build trust and being straight about things is the best way to do it.
Chapter 4:

I feel that this chapter is also about experience and a bit of sense. This is all life stuff and applies to any form of work in my opinion. He talks about preparedness and how coding is intellectually challenging and how if you aren’t prepared for it your work will suffer. I find that this seems like my dad is preaching at me when I was 16. I mean of course your work is going to suffer when you can’t concentrate or when you are tired. The worst code written at 3am, I have been there and don’t do that anymore because I have learned the hard way and the good ole flow zone where you think you are actually doing an awesome job reminds of the people who say they do their best work high or drunk. Sorry it just doesn’t work like that as like he said, yes you may get a lot done, but what did you miss? I am sorry but I guess I am kind of disappointed with the first few chapters. I was good with the first two at first but the next two to me seem to be more of the same lessons just in a different context and I can’t write anymore about them. It does however seem like the rest of the book will be decent to me. I thought his other book ( Clean Code) was good so I figured that this would be more of the same and I hope the rest is.

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

Week 2: The Clean Coder

This week we were assigned to read chapters 3 & 4 of The Clean Coder.  Chapter 3 was very interesting to me right off the bat; mainly because it was the complete opposite of last weeks chapter “Saying No”.  Chapter 3 was called, “Saying Yes”.  To sum up the chapter, it basically discussed how to tell if someone means what they are saying, and ways to change what you say to really mean it.  I found this chapter very useful because I personally know that I say things I don’t really mean to commit to all of the time.  One thing this chapter brings up a few times is when you hear someone say, “I need to lose weight”.  That is an extremely common phrase that people say, but it doesn’t necessarily mean they are truly going to commit to losing weight; they might just want to get around to it .. someday.  Chapter 3 stresses on the fact that as a professional, you should make it crystal clear when saying yes that you really do mean it and are going to commit to it.  Being able to say yes I will get something done as a professional and actually get it done is huge.  I have never really put too much thought into everyday conversations of people saying “yes” but not meaning.  But now that I think about it, there is so many times where someone says “yes”, but I just know that they don’t mean it so I don’t take it seriously.  In the workplace, that is not the professional thing to do and now I am aware of that.

Chapter 4 took a turn and was different then the last 2 chapters.  The difference with this chapter was that it was about your personal attitude towards coding, not how you communicate with others.  Although it is very important to have good communication skills as a developer; it is also very important to write good code.  The author took this chapter to discuss his personal things he has discovered that make his code a lot worse in the past.  A few of the tips he gave are:

  1. Don’t code if you are tired or distracted
  2. Don’t code at 3 AM
  3. Don’t code when you’re anxious
  4. Don’t code when you’re “In the Zone”
  5. Don’t code when listening to music

I am not going to sit here and list everything he said in the chapter, but I will say I don’t agree with some of his points at all while others I completely agree with.  For one, I have coded some of my best work when listening to music.  It’s interesting how music can help some people focus, while may distract others.  A tip I originally didn’t agree with at all was “Don’t code when you’re ‘In the Zone’”.  When I’m in the zone, there is no stopping me.  I love being in the zone and feel very productive when I am.  However, he did have a point that you may just be working at rapid speeds but not producing that good of work.  When you’re in the zone and writing a bunch of code, that is usually the code you will always have to revisit lateron and he’s 100% right about that.  It was interesting to me to recognize that being “in the zone” may not always be such a good thing. Finally one tip that stuck out to me that I can personally relate to is finding solutions in the car on the way home.  This has happened to me more then once where I left the office with no answer and on the way home, the solution just coming to me.  Something about taking your mind off of the problem and focusing on something else can lead to answers.  In the chapter, he calls this “disengagement” that may allow your mind to hunt for solutions in a different and more creative way.

 

From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.