Monthly Archives: January 2017

Capstone Week 2

This week in the software capstone, I went through the AngularJS tour of hero tutorial. It was an enjoyable and well-made tutorial that introduce beginners to Angular.  The tutorial basically goes through the design of a small part of a video game. You are basically building an UI with data driven application to manage different heroes, hence the name tour of hero. It goes through both the HTML elements of the UI and how to bind our data to the template.

It also goes through using services and also navigating our UI through routing. Finally, it goes through providing HTTP services and connecting to an API server. However, in this case it is just a simulated API server. Overall, it was a very well made and fun tutorial to do. It is good for people who have no Angular or JavaScript experience. It is also interesting enough that if you want to refamiliarize yourself with Angular or JS. This tutorial is great for that also.

Other minor things that were done includes introducing to the OpenMRS team and setting up Trello.

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

Clean Code Chapter 1-2

In the first two chapters of Clean Code, the author talked about using meaningful names in your code. In many codes, you will see arbitrary names that will make no sense at all unless you are the author.  This is especially a troublesome thing in legacy codes where there is no way to reach the author of the code. The person that was brought on for maintenance or update then must spend a huge amount of time to understand the code. It becomes even harder when the code has syntax that is hard to understand.

Sometimes syntax usage is unavoidable especially in a corporate setting. When going into an existing project as a new member of a team, there is going to be a lot of company jargons that will be present that you must read up on and understand.

Most of what is written is basically common knowledge for me at this point, don’t use slangs, or random symbol, etc. However, in the final paragraph of chapter 2, it also says that good names require a shared cultural background many times. This is interesting as it is not something I have really thought of. Many tech sectors employ people from many different nationalities, especially India. The different cultural background may affect how to comment and name your code, since something that is common knowledge in America may not be elsewhere.

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

Capstone Week 1

Week 1 there were just some initial set up of Slack and learning what we are going to do for this project. Set up with Slack was simple. We decided not to have any leaders at first since we are currently not even sure what project we are doing. We know we are going to use AngularJS so we should plan and learn/refamiliarize with the framework.

Once we are more involved with the OpenMRS project, we will figure out what to do with Scrum, meetup, deadlines, etc.

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

The Clean Coder (Week 2)

This weeks reading will be from The Clean Coder by Robert C. Martin. This blog post will revolve around chapters 3 and 4.

Chapter 3 talks about saying yes and when one should say it. Throughout this chapter, Roy Osherove talks about the three main points of commitment.

  1. “You say you’ll do it”
  2. “You mean it”
  3. “You actually do it”

Osherove also talks about signs of non commitment.

  1. “Hope”
  2. “Need”
  3. “Let’s”
  4. “I will…by..”
  5. “Hope”

Osherove made a lot of valid points that I agree with. I noticed that sometimes when I tell myself that I “should” get something done, it doesn’t necessarily mean that It will be done. I feel like those non commitment words are just excuses to not completing a task. When a person says “I Will” when committing to something, it exhibits assurance to the other person, because it tells them that they are taking it seriously and will follow through with their commitment.

Chapter 4 talks about coding, but more specifically, it grasps on the topic of when to code, when not to code, and what to avoid while you’re coding. There was a story where code written at 3am is bad, because it’s difficult to focus at night. I don’t know if I agree with the author completely, because I like to stay up late and code sometimes.It all depends on what my activities are during the day. On the topic of when not to code, you should stop when you find yourself not producing quality code that you know you can produce. You should take a breather and relax so you can clear your head before resuming.

 

 

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

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.