Monthly Archives: January 2017

Week 2: The Clean Coder, Ch. 3 & 4

In chapter three of the The Clean Coder, authored by Robert Martin, the focus was on saying yes and meaning it. This chapter is some what of a continuation of the last. It is very easy, when asked to preform a task, to almost reactively say yes. The author stress the fact to consider what is being asked and to only say yes if you will accomplish the task by the deadline. This is important as meeting keeping to you promises will mean others can trust and depend on you. If a person is always saying yes without delivering one will not be able take them at there word. This is where the author start using the phrase “the language of commitment”. With this he means use strong words that will convey your true intention. Use words like will or by in place of words like try, hope, or plan to. By using strong words you will minimize the worry in others, But again, this is only true if you keep to your promises. This chapter continues on the thought in chapter two in the idea that it is okay to say no or something is not possible. It is far better to say no than to say yes only to not complete the task at hand.

Referring to the same situation in my blog last week, I was working at a cabinet making company where one of the employees would always say yes. This habit of saying yes to all the tasks and deadlines meant nobody know what to expect to actually be accomplished. The word yes meant nothing. I also recall many times I was given a task and my response was “I will try to complete it” most of the time I had every intention on completing it but the words I used didn’t show it.

The fourth chapter is where the books starts to focus on coding. The author goes into some areas that are good programing techniques, like per programing, but also covers bad practices such as rushing, programing when tired or warn out, calling code done before it is actually ready to ship. He also talks about “the zone”, this is a state of being highly focused, a type of tunnel vision. In his opinion he thinks this is bad place to be and suggest taking a break or finding a partner to program with if you find your self slip in to the zone. People are different though, some like listening to music or having the television on in the background, personally I like to work without the outside noise. One of the last items covered in the chapter was knowing when to take a break. Sometimes it is good to walk away from the computer and in many cases you will think of a solution while preforming some mundane task.

From the blog CS@WSU – :(){ :|: & };: by rmurphy12blog and used with permission of the author. All other rights reserved by the author.

Learning Angular 2 (Week 2: 1/24 -1/30)

Following up with one of my previous posts about how our Software Development Capstone class will be working alongside with OpenMRS and AMPATH on some type of possible software that can be used within their medical system, I have recently started learning the basics of Angular 2. Angular 2 is the primary programming language used by OpenMRS so that is the language that is being requested for us to code in.

From the tutorials I have been following so far, it seems fairly simple to catch onto so far so that is a relief. One fascinating thing I’ve noticed is the similarity of Angular 2 and HTML. I’ve coded in HTML before and I was surprised to see that Angular 2 has the same syntax when it comes to the opening and closing brackets. Now I might just be ignorant to web programming languages and maybe all web programming languages follows that same syntax but whether or not that is the case; Angular 2 will be easier for me to learn than I had initially thought.

Just as a side note, I have started using WebStorm for JavaScript coding and so far it’s pretty good. I like the design and layout of the program, it kind of reminds me of the design layout of Komodo Edit.

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

Chapter 3 & 4 Review

This week we read chapters 3 and four of “The Clean Code” by Robert C. Martin.

The third chapter of this book is titled Saying yes, and in it the author talks about a very important topic known as commitment. Meaning that when you say you ate going to do something you are committing yourself to follow through on that. He then goes on to discuss everything regarding the subject. He talks about things like recognizing lack of commitment, and talks about what commitment sounds like. This entire chapter was very interesting to me but everything he said regarding commitment was very relevant to today’s society. I feel as though commitment is something that is very important especially in this profession and something that is lacking in most individuals including myself. A lack of commitment could cause a large amount of issues in a development environment especially if people are looking to you in order to get things done.

Chapter 4 of the book is titled coding. This was another great chapter in the book. In this chapter the author discussed writing intelligent code and the amount of work that really is. He goes on to discuss his principles and behaviors surrounding code. Issues like being prepared, meaning mentally taking care of yourself and putting yourself in the best place to write good code, as well as things like worry code. This means that you are thinking about something else and the code your writing is in the back of your head. He then talks about something called the flow zone which most people have had some experience with doing things like homework. It is his idea that being in this state while coding is not a good idea even though most developers think so. This is due to the fact that you do not always see the whole picture while in this zone and you are usually not kind to interruptions. The chapter goes on to discuss a large variety of topics like knowing when to walk away, overtime, and rushing. All in all this is a very important chapter in my opinion and a large amount of what he talked about is something that every developer should consider. This field is not easy and requires preparation and taking care of your body and mind.

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

The Clean Coder Chapters 3 & 4

In the third chapter of Clean Coder by Robert Martin, he talks more about making sure that you are clear about what you plan to do. Even though this chapter is titled “Saying Yes”, it’s more about how to make sure you can say yes and what it means to say it. A lot of this chapter is common sense and builds upon chapter 2. Basically that if you’re a professional you want to make sure you stick to the schedule you’ve set up for yourself and your team. Make sure that you stick to the deadlines that you have proposed and don’t agree to any extra work that you know you are not able to do. Also if you say you are going to finish something by a certain date, you are agreeing to be done by then and not “sort of” done. If you run into obstacles that may delay you and, in turn, the project, make sure to let your team or boss know immediately to figure out a plan. (This last part is covered in chapter 4, but feels like it should have been included with the part about commitment.)

In chapter 4, Martin discusses things that may impair your ability to code and how to deal with them. Again this chapter boils down to make sure that you take care of yourself, mentally as well as physically, and don’t ignore the fact that you work in teams or pairs. With most of this chapter, I agree with Martin. I find it hurtful for what I’m working on if I’m worried about something else or if I’m up really late at night. Since most everything you do is within a team, you don’t want to ignore them by being in “The Zone”; I know that I get rude when I tunnel vision into something. The only thing I don’t agree with is music. I sometimes find it helpful to put on music that is relaxing and has no lyrics, but when I really need to concentrate I turn it off. The last main thing that I agree with is helping one another. I have learned so much more from someone showing me how to do something or teaching someone else to do it. Programming is no longer something that is done purely by oneself, so helping and communicating to your team is an important part for one’s career.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

Week 2 Reflection

This blog post is a reflection on the second week of the semester in my Software Development Capstone.

This week was a relatively slow one due to there being a snow day on Tuesday causing our team to miss our first real meeting together as a group. Then the following Thursday i was sick and unable to attend classes. In my absence my team created a trello board to keep track of our progress on the openMRS project as well as a slack channel where we are to hold our daily scrum meetings on the days that we do not see each other in  class.

Our group has also begun learning how to use angular two as well as setting up our program environment, including getting node and npm installed.

I look forward to beginning to look at some of the openMRS repositories in order to better understand what we are working with, as well as learning and implementing angular 2 and contributing to an opensource project.

 

From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

Reflection on Week 2

This week was a productive week for me. Last week I got a basic understanding of what AMPATH and OpenMRS are. This week I focused on Angular 2, and getting up to speed with the language. I noticed that a lot of things are similar to HTML which i know a decent amount of. The fact that these two languages tie together will help me learn it faster in the long run. A couple things that held me back in the beginning were setting up my programming environment, and a couple things in the Hero’s tutorial that took me little while to figure out. But it was all part of the learning experience and I feel like I came out of those problems more knowledgeable than I was before. In weeks to come I plan to master Angular 2 to prepare for the projects to come.

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

Reflection Week 2

So the second week of class didn’t consist of too much either, other than getting your environment set up and just getting your required software and making the accounts we will need to further our work. Even though we only had one class this week, we still got a chance to get together and work on a list of some tasks given to us. We are still focusing on doing tutorials and learning as much as we can of angular 2. I learned about what slack was and how to use it/what its used for. We all set up our slack channels and linked them to trello so we can effectively communicate through out the week, even if we don’t see each other and apply scrum framework to our processes. I also learned about trello, and that we can use the trello with our slacks to make a backlog of items we need to work on, are working on, and are done with and all share it with each other. We all also had to create a student account to get to access all the tools from Jetbrains for over a year, giving us many of its useful tools like the Webstorm IDE. We also all introduced ourselves and posted on a forum and replied to our AMPATH client for the first time.

From the blog CS@worcester – CS Blog by Gautam by csblogbyg and used with permission of the author. All other rights reserved by the author.

The Clean Coder Chapters 3 and 4

This week we were assigned to read chapters 3 and 4 in “The Clean Coder” book. These chapters brought some things that I didn’t realize I did to my attention. First of all, in chapter 3 it talked about key words that people use that implied that they can’t or won’t get something done. Saying something like “I’ll try to get it done” is a lot different than “I will get this done”. I fall victim to saying I will try to do something or I should do something, and knowing in the back of my mind that I will most likely not get it done. 

In chapter 4 something that surprised me was when the author said to avoid the zone. It makes sense why he would say this. In the zone, you are focused on one thing, and that is to get as much code done as possible. The setback with this is that you lose sight of the bigger picture and in the end, the code will come out with a lot more bugs than if you were not in the zone. For this reason, developers should try to stay out of the zone. 

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

Reflections Week 2

In the second week of my Software Development Capstone course, we continued on preparations for our team that would help us work on the project. The first thing that we started to do was setup a Trello account for each team member and link the board to our Slack group. This allowed us to then setup Trello so that the team could easily keep up on what everyone was doing in the current Sprint. We made it so our board had lists for “Product Backlog”, “Sprint Backlog”, “Doing”, “Done”, and “Archived Cards”. I found that working with Trello was really easy and quite intuitive for what we were using it for. Once we start the project, everyone will simply just make a card that states what they are doing in the Sprint, and then move it to the appropriate place to indicate how they are doing with it. They can even make check boxes to section out what the task involves and show how their progress is going.

After doing that, each team was instructed to go to the OpenMRS website and create an OpenMRS ID – which I had already done the first week. Once that was finished, we had to then make a short introduction post on the OpenMRS boards saying where we were from, and why were we working with OpenMRS.

The next thing that was on the list was partially setting up our environment so that we could work with Angular 2. It was suggested that Webstorm from JetBrains would work best for what we were going to be doing. After downloading that and playing around for a bit- I was familiar with IntelliJ so I didn’t spend too much time doing this – I found that several people also used PhpStorm and Atom. I decided to download them as well to look into them and see which of the three I would prefer to use for the rest of the project.

The last item that we did for the week was the (simple) tutorial found here. For the most part this tutorial was informative. I was able to understand basics of Angular pretty easily; like the syntax, different imports in Angular, how to do two-way binding, and how to make displays in Angular. However when it came to how to use Promises for data services, the basics of routing, and how to use HTTP services, this tutorial wasn’t great. There would be multiple times where I needed to look that their completed version to see where I needed to make the changes to my tutorial code because they were unclear where the lines went. Sometimes I would even have the exact same code as their working example, but mine would not show. In the end, I decided to just read what they had for the tutorial and look at how it was coded in their working example so that I understood it and didn’t confuse myself further. I think, if I were to do this again, I would just make the tutorial locally and not use the online editor they provided so that I know where the problem is.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

The Clean Coder, Chapter 3 & 4

Chapter 3 and 4 of The Clean Coder by Robert C. Martin explains when to say “yes” in workplace and what are some of the authors personal definitions and experiences of good or bad coding practices. Author also explains some strategies on what is good coding practices and how to become a successful, efficient and professional coder.

For me personally, these two chapters were as interesting and informative as the first two chapters of this book. I really liked how the author talked about the importance of time and being late. Author said, “regularly measure your progress against your goal, and come up with three fact-based end: best case, nominal case, and worst case.” The reason why this phrase resonated with me is because I was discussing with my group and Dr. Wurst earlier that how I feel like the daily scrums are happening too often for me during the week. I am too busy during the week and I barely get anything done. So, for the daily scrums I won’t have anything significant to talk about or offer to the group during week that can show that I am progressing and not stagnant in my contribution to the team. Dr. Wurst respond was that I do not have to say what I cannot deliver. He elaborated that some team members might have time during week days and can get done more during that period. While some group members might be busy during week days and can contribute more over weekend. In either case, commit to a time and task; and deliver it. This gives team members a clear picture of where the member is and what he/she is doing. This is what the author also suggests that be transparent with your team members. If you are going to be late on a task that you committed to. Let your team know about it that you committed to this task, but this is how much progress you have made so far and this is your plan to finish it up. If you are stuck, ask for help from your team members. There might be a member who might have a solution to your problem or you can do pair programming with another team member. The bottom-line is that be honest and transparent with your team.

It was a joyful and learning read for me. I look forward to more reading and writing about this book!!

From the blog Software Learning and Development – Site Title by hhussainsite and used with permission of the author. All other rights reserved by the author.