In chapter 12 of Clean Coder, the book talked about collaboration. In the end, the book said that”Perhaps we didn’t get into programming to work with people. Tough luck for
us. Programming is all about working with people.” This just goes back on how communication is one of the most important thing for being a programmer.

Unless you are working on some passion project and is the sole developer, chances you are going to work in a more corporate setting. Knowing the social norm there is important. Meeting the deadline set by your boss is extremely important.

Not only with employers, working with your fellow programmers can be extremely difficult also. You have to talk to fellow workers to understand their section of the code, especially on huge projects. You have to talk to others to make sure you don’t have redundancies on the project. You might run into issues if office politics come into play. However, collaboration is extremely important to being a programmer.

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

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.

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.

This week in capstone, we dig deeper in the OpenMRS project.

The steps we did this week

1. Forked the openMRS git repo
2. Got ng2-amrs to build and run
3. Installed ng2-amrs standalone back end
4. Looked over how the ng2-amrs authentication system worked

People initially had issues with setting up the system. This was actually an issue with multiple OS. People where using OS bash, Node.JS terminal, Bash on W10, and Git Bash. People were confused on what to use at first and we had to clear that situation up and also the different IDE people were using.

We tried to get an understanding of how the entire system works. Initially we set up the front end of the system but was confused on how we get the login system to work (the back end system). It wasn’t until some noticed that there is a standalone that is needed for the back end system that we realize that is actually where we auth.

Although we got everything to work in the end, the steps could’ve been made smoother if everyone was using the same OS and IDE so there’s no differentiating the set up process. Obviously this is much harder to do in a school environment, but having to trouble many different IDE and OS set up can be very stressful especially if a much more complicated project comes up.

Also people speaking up in a team environment is also key, not realizing we needed a back end, we fumbled around confused on how they got auth to work. Until one person spoke up about the back end and then we got confirmations from outside the team on how the entire thing worked.

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

In Chapter 7 of Clean Coder, the book talked about communication and situations such as premature precision and specifying interface. In my opinion, the most important thing is communication bar none. I have faced situations like described in the book where Business side wanted exactly this but it wasn’t possible due to technical issues. There were also cases where there are multiple departments that want different things, where you end up having conflicting reports on what to do.

Many time in those experience, you end up either doing extra work that was not necessary at best, and at worst missing a key feature that the client really wants. You end up wasting time on features not needed and then crunching before the deadline to get what is needed done. It is imperative to get the full communication down and get everyone on board. The acceptance test, or QA is important here since it serve as an end goal and checklist to get the details and specifications right.

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

On chapter 6 of Clean Code, the book talk about law of Demeter and it showed an example of a code that was typed with a function that calls multiple other functions leading to an extremely confusing line of code. The fix is to separate them out into different lines with each line calling a function.  This is easier to read and have the proper formatting that is expected.

I have read and also written codes that did not have proper formatting and was a long line of calls. It was just a mess to read and I’m sure anybody afterwards trying to pick up my code will have a hard time understand my though process. It is imperative to have proper formatting to not only help yourself if you run into issue with your code, but to other people in the future that might be reading your code.

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

In chapter 3 of clean code, it was interesting to read his thought on switch statements. As someone who uses a lot of switch statement, it does look very ugly when it is inside your larger code class. It was a common mistake for me in the beginning of coding to have these huge switch statements inside the code. When things need to be changed, I would have find the switch statement inside my code and change it. The solution in the book is to use an abstract factory to hide the switch. However, even then it says the statement are only tolerated if they appear once and are used to create polymorphic objects.

In chapter 4 on comments, the book states that comment does not make up for bad codes. I chuckled when reading that as it was something that I’m guilty of doing.  There are codes I written where I comment that the code is a mess here and I will fix it later. Of course, I rarely ever go back and change it. It is a hard habit to fix especially since you know the code works, although it looks ugly and maybe a bit inefficient. Cleaning it up will benefit you and people who will read the code in the future.  The more you put it off, the less likely you will go back and change it. Commenting with a “will clean up later” just further exacerbate that problem. It is something I should work on in the future.

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

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.

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.

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.