Monthly Archives: January 2017

Week 2 – Learning Reflection

imgres

This past week I spent my time working with Angular 2.  More specifically, I worked through the Tour of Heroes.  I took my time going through the tutorial, and as a result, I feel as though I learned a lot.  Unfortunately, for everything I learned, I am sure that there is an equal or greater amount of information I did not retain.  I intend to spend the next couple days reinforcing that knowledge with some more readings.  Then the fun starts.  In the same manner that I have learned everything else, I need to apply some practical application to the material and gain some experience.  Luckily, I have a group of peers, a project to look forward to, and thirteen more weeks to practice.

I find that I am disappointed with my second week of learning reflection blogging.  I don’t think that it is for a lack of effort, but that I have not begun working on our own project.  The Tour of Heroes tutorial is pretty self-explanatory, and does not require any additional commentary.  Once we dive into our project, and hopefully that time comes soon, I will be able to write about that experience.  Until then, I will continue to learn as much about Angular 2 as I possibly can.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Capstone Project: Week 2 Reflections

Another week, here and gone. Man time flies by when you’re having fun!

This past week the group and I made our first approach to google’s javascript framework, Angular 2. We dove right in with TypeScript and Angular2 by following the Tour of Heroes tutorial. This was pretty awesome but also very overwhelming. I found that it was quite a bit of information to digest in such a small amount of time. I, just as many others, learn best by solving problems of my own so I actually tried to tweak the tour of heroes a little bit here and there to learn a little bit more. As we dive head-long into the AMPATH project I am sure there will be times where I am completely overwhelmed, due to having to learn this brand new framework but something about that really gets me giddy like a child! I enjoy stretching my knowledge base and this is a for-sure way to do that.

In retrospect, one tutorial felt too short and I felt I didn’t learn enough. Myself and others in my group have decided to append our sprint, mid sprint to extend our Angular 2 learning. I have started reading the advanced guide to Routing on the Angular website to try and glean a little better understanding in this complex topic.

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.

The Clean Coder: Chapters 3 & 4

Another week done and two more chapters of The Clean Coder read. This book has been quite enjoyable and it’s nice to have assigned reading from school that isn’t so “text-booky”. It’s nice to have something to read that is someone’s personal experience in the field of software engineering and hear about his successes and mistakes.

Chapter 3 talked about the flip side of chapter 3, saying yes and when to say it. I really enjoyed this chapter because it’s something I had make an conscious effort to approach in the past 9 months or so. I noticed at work I was using the phrases “try to get it done” and “might get it done”. I noticed this was simply giving me an excuse to take things at more of a relaxed pace and maybe not giving 100% to my employer. In May or June (I do not recall the exact date) I was moved into more of an IT infrastructural role at work. My first task.. Fully rebuild the LAN/WLAN structure of the facility. The president of the company told me this was of high importance to get this done a.s.a.p. and requested I estimate how long this would take. After some research and getting the things I needed on order I gave my boss a definitive date of 2 weeks until completion. Because I gave the president a definitive date and completed 2 days ahead of that date. He then started giving me tasks that we meant for my immediate supervisors because he knew that we would get a date things would be done by. I have since found that using correct language and giving good time tables creates better channels of communication and makes everyone in the organization happier.

Chapter 4 was the first time I had some serious differences in my ideas compared to Uncle Bob’s ideas. This was negated by the fact that he explicitly stated:

You will likely not agree with everything I say here. After all, this is deeply personal
stuff. In fact, you may violently disagree with some of my attitudes and principles.
That’s OK—they are not intended to be absolute truths for anyone other than me.

I find it funny that he had to mention 3 AM code. It seems to me that the general idea behind anyone who has tried solving a difficult problem with programming has come across this at least once in their efforts. I know I’ve talked with multiple programmers who all say the same thing, “If you can’t solve it, walk away for a while”. I’ve even told this to many programmers. It’s just a fact of life with any issue you can’t solve immediately. If you walk away and let your subconscious mull on the issue, 9 times out of 10, you’ll find the solution.

The one major thing I disagree with Uncle Bob on, is listening to music when trying to be productive. I am never more productive without music. I imagine this is something that changes from person to person as well. I know for my wife, she’s the most productive when things are dead silent. Now she’s a not a programmer and has never written a line of code but everyone has their own way of steadying their brain to focus in on a task. Part of my ritual to steady my brain is put on some music. Now I know that he also mentions avoid getting into the zone and this is something I already avoided anyways. But what music helps me accomplish is two things. It helps me set a rhythm to my work that keeps easily distracted part of my brain busy. Also, when I have headphones in it lets others know that I am baring down to get work done. In my office there are times I simply need to get stuff done and don’t have time for idle chit-chat. These are the times I find music especially helpful. If someone needs me they know they can simply come in to my area and I will almost always take my headphones off immediately. However, it puts up some sort of barrier that tells people I am too busy to chat about non-work-related topics.

All-in-all, it was another good week of reading what Uncle Bob had to say on Software engineering! I look forward to see what he has to say in Chapters 5 & 6.

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.

Week 2 Capstone

For week 2 many of the tasks were aimed at getting set up for the rest of the semester. This week is our first real Sprint following the Scrum cycle. The first sprint planning meeting was a little unconventional because all the stories really needed to be completed by each group member. Therefore there wasn’t really a division of work. The first story I completed was creating a Trello login and figuring out how to use the tool. Basically Trello is used for project management and consists of boards made up of lists filled with cards. This setup is acting as our Sprint Backlog and Task Board. We have 3 lists titled Backlog, Doing, and Done. Under each of these lists are the cards which represent a story that was assigned to the current sprint. The tool has an easy drag and drop feature for moving the stories to the correct columns. Next, the team integrated our Trello board with our Slack channel so we can modify the board and get notifications in Slack. There is a built in app for Trello in Slack so the integration is pretty easy and notifications can be configured to the team’s preferences. Next I created my OpenMRS ID so that I can communicate within the development community for the project. I then posted my introduction to the OpenMRS talk page which is basically a communication forum for the project. Lastly I installed WebStorm on my computer which is a JavaScript IDE built by JetBrains. I made a JetBrains student account which gave me access to all of JetBrains tools for free. I thought this was pretty cool and plan to revisit the site to see what other software they have. As for now I haven’t really started using WebStorm but plan to do some kind of tutorial to ensure I am using the IDE to its potential. Lastly, I realized I did not post my Daily Scrum in my slack channel on Friday so I need to make sure I am doing this in the future. As a team, each individual should be posting their stand-up in the channel Monday, Wednesday, and Friday. As this is our first sprint it will take a few cycles before we all are proficient in the sprint process. Looking into this upcoming week I still have the Angular Tour of Heroes to complete and I’m sure the team will be getting more familiar with the OpenMRS source code as well.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

The Clean Coder: Chapters 3 & 4

Chapter 3 covers the general topic of when and how to say yes as a professional at work. The stand out message is three simple rules: “You say you’ll do it. You mean it. You actually do it.” Avoiding phrases like “let’s” and “we” are crucial because they almost always hint at non-commitment. It said to make more definitive and personal statements. These include using “I” and giving a specific task which will be completed at a designated time. This chapter also reinforced a theme from chapter 2 in regards to only committing to what you can truly deliver. That is if you depend on another team or individual only make real statements about yourself however work with that other party as best you can to get closer to the target goal. Also another idea mentioned previously was early communication. Specifically mentioned in this chapter is to raise a red flag as early as possible because this gives the best chance at a work-around that still allows you to follow through with an expected task. The strongest point of the chapter is to be clear and definitive when saying yes, similar in how to say no in chapter 2.

After reading chapter 3 I have a few takeaways to reflect on. The first is to be more definitive in my own statements. I am definitely guilty of using the “I’ll do my best” mentality and after reading this chapter I realize that way of thinking won’t cut it in the long run. I also think an important message was to not commit to something that is out of your control. Looking forward I will take more time to think about what I am actually promising will get done and ensure it is fully within my power to do so. I also think the last scenario in the chapter was a good lesson. The employee promises that he will meet a Monday deadline knowing he is fully capable of doing so. It was his confident negotiating of taking a day off after his task was complete that I found worthy of remembering. This shows it’s sometimes okay to put in that extra work for an earlier deadline but not to be afraid to take that time to reset afterwards. Once again I believe applying the Scrum development process could help avoid some of these situations and improve your saying yes skills. By having semi-regular sprints you are saying yes and being held to your word on a more frequent basis. This development framework should help keep everyone honest and committed.

Chapter 4 talks about a wide spectrum of factors to keep in mind when actually coding to maintain the professional character the book strives for. One of the main factors mentioned is distractions while coding. This could be that you didn’t get enough sleep, a personal issue at home, or possibly just writers block. You should take some time away from the desk and see if there’s anything that can be resolved regarding the issue so that your mind will be able to focus on your code. Secondly, the author mentions “the zone” where programmers may feel like they are on a roll and have tunnel vision. He warns that you should never code in this state because you lose sight of big picture concepts and will likely return to the written code to fix mistakes. Overall the theme of this chapter is that you should recognize when you are not doing your best coding. It’s suggested to meet with a pairing partner or maybe just walk away for a few minutes so that only the best code gets written.

After reading chapter 4 I think there is a lot of good advice to keep in mind when coding in the future. This being said I’m not sure everything is as easy as it is told. Life distractions will always be present and I’m not sure trying to solve them at work would look professional among my peers. I do agree however with the idea of stepping away and taking a break if I feel like I’m not writing good code. Having a mentor, as the author mentions towards the end of the chapter, could be a great way to stay on track by meeting regularly with that mentor or even a partner. In regards to the author’s mention of false delivery and defining done the Scrum framework once again would help prevent the shortcomings mentioned in the chapter. Throughout the book so far Scrum has proven to address many of the concerns in each chapter. I am starting to see why this form of agile development has been so widely adopted.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

Reflection (Week 2)

Week 2 was rather very interesting, because I was exposed to new technologies, applications and languages. My team and I created a slack channel where we will be communicating with each other for the duration of the OpenMRS project. Along with creating a slack channel to communicate, we also created a Trello board, where we tackled on our very first sprint in order to get the project rolling. One of the tasks on our board, was to create a user login to the OpenMRS website and to introduce ourselves in the community forum page. As previously stated in my week 1 reflection post, we are working with Angular 2, and with that I had to download an application that was foreign to me called WebStorm to write our code in. I’ve never used it before, but i’m looking forward to learning how to use it.

From the blog CS@Worcester – My Blog by justcodeit94 and used with permission of the author. All other rights reserved by the author.

Reflections, Week 2

I spent this week learning Typescript and Angular2 (continuing from last week). I continued with what I did last week. The only thing which I did different this week was that I listened to videos on Angular2 and TypeScript on Lynda.com.

Some of the videos were good and some put me to sleep. I am also working on the Angular2 tutorial (building the tour of heroes app); I’ll complete it by the end of this sprint.

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 Beginning of the Team

Week 2

Second week in, we created team slacks to communicate effectively. We built our first short sprint for basic tasks to get the project going. This included creating a trello for a task board, linking the trello to our slacks, introducing ourselves to our client from AMPATH on a forum, and completing the Angular Tour of Heroes. Our project will be written in Angular 2, which previously I had never heard of, however it is just a form of Javascript. From research it sounds fairly easy to jump into especially if you haven’t been accustomed to Angular 1. The tutorial consists of a walkthrough of building an app to help a staffing agency manage its stable of heroes. My app is in the works and it is quite neat!

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

Clean Coder Chap 3+4 Week 2

Saying Yes:

When you say you are going to complete a task, you have to mean it…which in turn means to actually complete the task. Commitment means taking full responsibility, some results are out of your control however you must respectively anticipate the limits and raise any concerns from the start.

Coding:

Coding requires a certain level of focus that is unlike any other, distractions and overtime are major problems. A story is provided where code written at 3am causes severe problems; it is a bit difficult to focus in the middle of the night. Interruptions and music are also bad distractions but a helpful way to alleviate these issues is pair programming. Coding can not be rushed; it is a marathon, not a sprint. There is no reason to bring your work home in order to get a head start. Take your time and keep your focus.

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

The Clean Coder, Chapter 3 and 4 (Week 2)

The third chapter of this book is about when and how to say yes and commitment. I liked the section on commitment speech vs. noncommitment speech. We should avoid language that shows or may signal that we are not commited to doing something. For example, using words like I need to do this, I hope to get this done, or I should get this done by Friday signals to the other person that you might not do it at all.

There are three parts to making a commitment
1. You say you’ll do it.
2. You mean it.
3. You actually do it.

The secret to recognizing commitment when somebody says something, according to the author, is to look for the words I Will. When somebody uses the words I Will when commiting to something, it shows that they are commited to doing it. And using these words also forces you to fulfil you promise, because you might feel embarassed for not fulfilling you promise.

I personally plan to use the words I Will when I commit to something. This way it forces me to fulfil my promise and also avoids people thinking that I am not commited to doing something.

The second chapter of the book is about when to code, when not to code and what to avoid while coding. This chapter is about the author’s personal beliefs about the matter. I persoanlly don’t agree that 3AM code is bad, I am a night person and most of my best works and ideas come at night. My brain usually does not work 100% during the day, it only starts to work from 8PM to 2AM.

I do however agree with him on the HELP section. Building software is not an easy task; it is the responsibility of developers to help each other and it is a violation of professional ethics to not help others or receive help.

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