Category Archives: cs-wsu

The Clean Coder Chapters 11 & 12

In chapter 11 of The Clean Coder, Martin talks about how to deal with pressure and stress when it comes to deadlines. None of this stuff is really new to me, especially being a college student and having to deal with deadlines for projects. He goes over how, if you can, avoid pressure, but, if you can’t, make sure to communicate this properly to the people you work with. Mainly, don’t take your stress out on the people that work with and for you. Also, if you are going to miss a deadline, tell your bosses and team way in advance so that you can plan out how to fix that. He points out that you should always follow your disciplines when you are under pressure because you know that the way you’ve been doing things is the right way to get the work done. This makes sense because this prevents you from having a huge mess that you will, most likely, just have to clean up later and waste more time. The last thing he went over is making sure to work in pairs which is common sense in programming now-a-days. You need at least one other person just to review your work to make sure you aren’t so stressed that you miss major flaws in your design.

This leads into what chapter 12 is about, which is working with people. Again, I personally find most everything that Martin has stated in this chapter to be a “no duh” kind of situation. He goes on to talk about how you should pay attention to the business that you are in so you know what is going on there. He gives an anecdote about a time he was fired for being, to summarize his post, “too into the technology and not into the business.” His story basically turned out that he liked the work for the job, but he didn’t care about job etiquette or manners; this includes basic things like what to wear at the job, who the higher-ups are,showing up on time, etc. To me all of this stuff is a no-brainer. When you get a job you follow the dress code, you know the people, and you show up on time. If you don’t like those rules, then look for a different job that will take you. The other two things Martin talks about in this chapter is “owned” code and pairing. I simply agree with him on both of these points. I don’t think people should have code that is “just theirs” because that creates so many issues due to them not wanting their code to be reviewed. This obviously leads to multiple issues down the line. Also, as I’ve already stated, paired programming is effective, and working in teams makes sure that messes and bugs are caught early before major issues start to happen.

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

Reflections on Learning and Work Products, Sprint 2

For our second Sprint in my Software Development Capstone we continued to set up our local computers so that we could work on OpenMRS and the AMPATH software. To do this, we first went to the OpenMRS Download Page and downloaded the OpenMRS Standalone version. Once that was downloaded onto my computer, I simply extracted the zip file and then ran the .jar file that was in the there to start the OpenMRS software (for this I also picked the demo data version that comes with 5,000 sample patients). Some people had issues that this point, but I was lucky that this worked right from the start for me so I didn’t have any modifications to make.

Once I had OpenMRS running, I then cloned the repository containing the Ampath Point of Care System Version 2 that one of my team members forked from AMPATH. To get this up and running I first had to download all the dependencies that they required. I first went and downloaded the newest version of Node.js from their website (for me that was the Windows 64-bit of LTS). Once that was working, I then downloaded the list of gloabals with npm install –global:

  • webpack (npm install –global webpack)
  • webpack-dev-server (npm install –global webpack-dev-server)
  • karma (npm install –global karma-cli)
  • protractor (npm install –global protractor)
  • typescript (npm install –global typescript)

Once all of that was installed, I finished up the rest of the installation by doing these last three steps:

  • npm install webpack-dev-server rimraf webpack -g to install required global dependencies
  • npm install to install all dependencies
  • npm run server to start the dev server in another tab

At first when I ran “npm install” it seemed to give me a list of issues, but when I ran the server everything seemed to work fine and I was able to get to the login screen.

With that completed, our team then set off to work on re-writing the Authentication Module in the AMPATH software and see if we could get it to work (basically just familiarizing ourselves with the software and Angular 2). Our team first put this up as one whole task that need to be completed, but after going through it, we decided to have a story time to break down this task into smaller ones. At this meeting we also decided on what our meaning of “Done” was. Since this was all done closer to the end of our Sprint (due to an excessive amount of snowstorms), our team was only able to do the very beginning of this project. We all start first on going over the login HTML and CSS. Since it’s been at least 4 years since the last time I wrote anything for HTML or CSS (not including what I did for the tour of heroes tutorial), I just put their code next to mine and copied it so I got a feel and could see what they were doing to create the login screen. The last thing that we got to do before the end of our Sprint this time was look over the authentication.module.ts and its dependencies to get a feel for how it works.

During our Sprint review/retrospective we decided to put the rest of the re-writing of the Authentication Module on our backlog and get to it next Sprint. Overall I think that this Sprint went really well, with the exception of how late we got to our story time, but that was all because of storms cancelling our time together and messing up our schedule. Another thing that I found really useful was one of my teammates saw that Scotch.io had a good chuck of their Routing Angular 2 Apps class free to watch. I ended up watching the first couple of videos and found it very helpful, and I will probably finish watching the rest of them over the weekend.

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 Chapters 7 & 8

Most of chapter 7  and 8 were things I had already learned from the previous testing class that I had taken. He goes over that unit tests are different than acceptance test, always try to make automated tests because they are cheaper, and all the different types of testing their are and what each one of them covers in the system.
The main thing that I took away from this chapter was that you, as a developer, should make sure that clear communication is established between your team and the stakeholders that you’re working with. Primarily you don’t ever want to assume that the other party knows what you are talking about, or that you are on the same page.  These assumptions can, and usually will, lead to huge messes down the line that may result in your team having to fix the entire design of an application that you were building because you misunderstood critical information that the client was ambiguous on. So, moral of the chapter, never be afraid to ask question and bring in people that may help to clarify the story that the client gives you.
I did also find the small section on testing GUIs interesting. Martin points out that you should not test the GUI itself, but the under lying structure by designing they system to treat it like an API. This makes perfect sense when you think about it because a GUI will always be changing to whatever the clients preference is.

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

Reflections Week 3

In Week 3 of my Software Development Capstone, we finished up our Sprint and focused on doing the Sprint review and retrospective. First we rated each team member on a scale of 1 to 3 – 1 being “Needs Improvement” and 3 being “Excellent” – on how well they preformed certain things during the Sprint; like communication, completion of tasks, etc. Overall our team went easy on one another for the first round since everyone was still getting the hang of doing the daily scrums and what we defined as “commitment.”

After that we did the overall retrospective of what our team could do better on in the future and also put items on the product backlog to address in the next Sprint. Again we didn’t go too far into the retrospective since we didn’t do much work besides go over the Angular 2 tutorial and read some of the Advanced pages about Angular. We did go over small things that we wanted to put on the Sprint Backlog such as making a proper definition of “done” for the team, and also setting up a priority list so we know how long certain tasks will take.

Overall it seemed to make sense to go easy on this first Sprint review/retrospective so that all team members have a baseline for how this will go. Once we have code and actual projects to work on, our team plans to go more in depth about giving reviews for people  and also take a bit longer with our retrospective about what our team could improve on in the future.

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 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.

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.

Reflections Week 1

For the first week of the Software Development Capstone we mostly focused on setting up teams that we will be working with for the rest of the semester. This was done by having one person voted in as a Team Recruiter and them being able to pick who was going to be with them. After everyone had a team of six, joined our class on Slack and then created a channel for our own team. Luckily, I have had experience with slack before and know how to use it so I didn’t have to do much reading about it.

We then moved onto learning about OpenMRS and AMPATH which is the specific project we will be working with. OpenMRS is a client-server application that allows people, with no previous programming knowledge, to build a medical records system. This is so that these systems can be easily built in developing countries. AMPATH is one of these medical record systems that is based out of Kenya and helps with numerous medical needs from disease to abuse.

On the software development side of things, OpenMRS uses three languages for their application. For the OpenMRS Platform they mainly use Spring MVC and Java EE, and for their ORM they use Hibernate. With most of their front end stuff they use Angular 2. For our group project, we were told that we’d mostly be working with Angular 2 so I started reading up on some basics about it and just going through simple tutorials. (For right now I’m just reading through this tutorial, but I noticed more on other blogs and hope to get to them this weekend.) I’ve done some small things with Javascript so I’m looking forward to learning how to work with Angular 2 in this up coming project!

If anyone else is interested in learning about OpenMRS or AMPATH, here are links to their sites:
OpenMRS Main Site
AMPATH Main Site
OpenMRS Developer’s Guide

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 Chapters 1 & 2

In Robert C. Martin first chapter of The Clean Coder: A Code of Conduct for Professional Programmers, he talks about what it is to be a professional. Professionalism, in Martin’s view, consists of two things: responsibility and accountability. To emphasize these aspects, Martin goes over what should be done as a programmer to make sure you’re working as a  professional. First he talks about how you should take responsibility for your code. If there are bugs, you should know about them, and take responsibility for them. You should not rely on QA to find your bugs, and apologize to them if they do find any. Make sure to always test your own code and know that it works. Also always automate your tests so that you can run them whenever they are needed. Never harm the structure of your code, but don’t be afraid to update it to make it flexible. Also keep learning for your career and not for your employer. This means take time to do task like read up on current practices, software, and anything that is relevant to your field. Also learn new languages, help people that are new to the field, and find ways to practice your expertise with other professionals. Martin also states that being a professional as means understanding humility and that means knowing when to apologize for a mistake they have made.

In his second chapter, Martin goes over why it is important to say no when you are in a professional environment. He goes over that confrontation is a part of being a professional and, if you continuously give into demands to satisfy your boss or yourself, it can lead to terrible outcomes. In this context, saying no is more to make sure that you don’t give false hope to your employer, overburden your team, and produce trash code. Martin also points out that it is better to stand up and say something about a bad situation rather than say nothing and let things fall apart.

I thoroughly agree with everything in the first chapter. This type of thinking about how to code, making sure it works, and take responsibility for what you have done has been repeated through so many of the previous classes that I’ve taken. I also agree with Martin on the fact that you should always use time outside of classes/work to practice or read up on items that are related to your career. I personally found the second chapter more relevant to myself because I have been put in a position where it would have been better for both myself and my employer to have said no. Luckily at the time I wasn’t working in the computer science field, but for a small company. The owner would continuously ask me to start jobs, which I would agree to, and then add on more work on top of that. It got to the point were I was never able to finish one project because I could not say no to the additional work they wanted done. This eventually burned me out to the point of dropping all the projects and then quitting the job. Now I know that saying no is not giving up, but making sure that you keep your projects, and yourself, on track.

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

Software Dev Capstone

This blog will be used for my Software Development Capstone that I’m currently taking. I will be making weekly posts about readings from The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin and, later in the semester, The Software Craftsman: Professionalism, Pragmatism, Pride by Sandro Mancuso.

I will also be posting about the work that I’ll be doing on the OpenMRS Project – specifically on the AMPATH Project.

-Caitlyn Lambert

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

5 Common Mistakes in Automated Testing

Original Article

In his article, Rohit Sharma goes over the top five most common mistakes users have made when using automation tools for testing.

The first item on his list is when testers “think of automation testing as little more than record and replay.” He goes on to say that proper automation testing is done when a tester has customized the generated script for their specific needs. Sharma also mentions that the record feature should only be seen as an outline and not as the finished script.

Second on the list is when testers do not validate the scripts that they are using. Sharma suggests that using checkpoints, at as many places as possible, can help to remedy this situation.

The third thing is that you don’t want to just validate your visible components when testing. Anything that happens on the back end should also be checked to make sure that your script is properly validating it (the two examples that Sharma gives are communications to a database, and making sure a file was automatically created properly).

Fourth on the list is making sure to remember that automated testing cannot replace human testing. Sharma states that “automation is a great way to augment your testing efforts,” but automation testing only works well “when you know what to look for.” In the case that he states, you could have a web page that generates unreadable text, but, unless you have someone looking out for that, you are unlikely to find it with automation testing.

The last item that Sharma talks about is making creating “inappropriate test cases.” He points out that there are multitudes of paths that a user can use in your application so trying to test all of them would waste time. Instead, try to figure out how to “condense all possible paths to a small sample of highly representative test cases,” so that it covers the majority of your user’s activity.

 

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