The Clean Coder Chapters 11 & 12

This week i read chapters 11 and 12 in The Clean Coder by Robert C. Martin.

Chapter 11 is about pressure in the workplace. As someone who has not yet had a full time programming job this is not something that i have a ton of experience in so this chapter was extra interesting. I’m sure even assignments due in a small time frame cannot compare to the pressure of programming in a full time career under  a time restraint. The first tip that the author suggests is avoiding pressure altogether whenever possible. This goes back to one of the main points of the entire book, which is not committing to things that you are not one-hundred percent sure of. If there is no way to avoid the pressure, then the best way to go about it is to maintain your discipline throughout the pressure. He discusses how disciplines you abandon in times of pressure are not really your disciplines at all if you do not believe in them enough to maintain using them when it matters most. Maintaining your disciplines, remembering not to panic and communicating with your team are the best ways to get through a high pressure environment in the best way possible.

Chapter 12 is about Collaboration. At the beginning of this chapter the author goes on to describe the average programmer, someone who most likely does not enjoy working with people and much prefers machines. Although as he also said this is not all programmers, i completely agree and most of the time this is me to a tee. Working with other people causes so many complications. However as he also says not working with others can be catastrophic. As much as we would like to just sit by ourselves work on our own code and not have social interaction, that is just not possible and for good reason. He talks about something called collective ownership which is  a very good concept to have in my opinion. This means that as a team you take collective ownership for all the code in your department, not just the code that you have written. This creates a much better quality code, and helps people to work much better. Robert also talks about pair programming and how rewarding of an experience it can be and i could not agree more with this as well. Pair programming is an opportunity to learn so much from someone with more experience or to pass on your experience to someone who is new. Not to mention it can help you get past roadblocks in your code.

Sprint Review 2/22

This week our group has just finished another sprint slightly longer than the last. We are still working on the AMPATH section of the open source OpenMRS project. We have started getting slightly more into the code itself and so far it has been a rewarding experience.

This spring was all about getting the cloned ng2-amrs directory to install and build successfully. Although it sounds simple enough there were quite a few bumps along the way preventing us from being able to run the build and log in. However we were able to overcome these obstacles by getting aid from the team as well as the rest of the class when it was necessary. Once that was taken care of the next step task in the sprint was to get the standalone version of the OpenMRS version downloaded and the server up and running. Again this did not come without some degree of difficulty, however it was nothing that we were not able to overcome.

Once that was all done we decided to change the way that we wanted to organize our contributions to the open source repository. So we created a github organization and forked the ampath repository into that organization, and from there we forked the organizations repository and cloned it onto each of our computers. This means that we had to delete the repository that we had just spent a good amount of time getting to run and redo the whole process. The good thing is that the entire thing was a lot easier the second time around and we were all able to redo the installations within around an hours time.

Unfortunately we did not have enough time to complete everything on the sprint backlog such as redoing one of the login modules in order to get a better idea of the code that we are working with. So that was put back into the backlog for the next weeks sprint. Upon completion of the sprint we performed a sprint review and a retrospective. Although there was not a great deal of work to be done this sprint i feel we are getting a better idea of the process as a whole and learning to work as a team. I look forward to the next sprint.

The Clean Coder Chapters 5 and 6

This is a review of Chapters 5 and 6 in “The Clean Coder” written by Robert C. Martin.

Chapter 5 is titled Test Driven Development. This is a development process in which you write the unit test first just enough to have it fail then you write just enough code to pass the test. You then go back and write more code then more test until the development process is completed. The author seems to be a large fan of Unit Testing saying that there is really no better way of developing, and anyone who disagrees needs to basically get over it and accept the truth. This was interesting to me because i have learned about unit testing before and from what i understood it isn’t incredibly popular. However i have not currently been in the workforce so i am now 100% sure if this is actually the case. I am actually a fan of TDD, i found it to be very fast paced and at the end you are guaranteed 100percent code coverage of code that you know works, what more could you ask for.

Chapter 6 was especially important to me, the chapter was titled practicing. The author goes on to discuss that any professional no matter what his field spends a good amount of time practicing his craft. He talks about how it is not the duty of a company to allow their employees time to practice, it is the job of the individual, a company is there to spice up your resume and it is practice that makes it so you can be paid well. Practice is something that i agree is very important to becoming a good developer and it is also something that i personally do not take as seriously as i should. He then goes on to compare programming to the practice of a martial art and discusses many types of practice such as kata. This is a small programming exercise that you can practice repeatedly so that you can become a better programmer. This will allow you to spend less time thinking about the typing and the syntax and more time thinking about the harder problem at hand. There are a large amount of resources out there for young developers to practice, one of them being Codewars which calls its practice problems kata and structures itself very similarly to the way that Martin suggested that we were to practice.

Week 3 Reflection

This is a reflection of the third week of my software development capstone.

This was another short sprint where there was not much for us to accomplish apart from finishing the angular tour of heroes tutorial if we had not already done so. One thing that did make it unique however was we officially ended a sprint and with that came the all the necessary procedures. As a team we began by filling out a reflection on our team mates where we rated them in categories such as attendance and communication, so that we can continue to function as a team as effectively as possible. Since there was not alot for us to accomplish this sprint it was relatively easy to close it out, it did however give us an idea of how exactly that process works as well as an opportunity to carry it out. We began the process by conducting a small sprint review, where we went over what we accomplished and what we committed to but did not actually accomplish. Then we conducted the retrospective. This is the part where we analyze how we worked as a team, what we learned and how we could improve going forward. Overall this was a very rewarding experience, and i learned a great deal from the experience.

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.

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.

 

Review of “The Clean Coder” Chapter 1 & 2

In addition to my weekly post reviewing what i have learned as well as my progress on the AMPATH project, i will also be writing a weekly blog discussing chapters in “The Clean Coder” by Robert C. Martin.

This week i have read the first two chapters of the book, and i almost found it hard to put down. The author has a good way of connecting with the reader and making him invested in what he is saying.

The first two chapters basically begin with the author attempting to define professionalism in the best war possible. This is a large task and takes a deal of time to fully understand what a professional is and how he operates. There was one point in the first chapter where he discussed writing and releasing code that had cost the company 10,000 dollars and he went on to say that a professional would reimburse the company for that loss where as a non professional would shrug it off and just say that “eh it happens”. This hit me pretty hard, and i completely agree. If you are not invested in the code that you write then why even write it at all? Are you ding it just to get a paycheck at the end of the week? If that is the case then the code that you are writing is most likely not that good at all. He goes on further in the chapter to discuss continuing your education and even compares our profession to that of a surgeon and uses the Hippocratic oath as an example. Again this is something that i found very powerful, as people do not understand the effect bad code can have in certain situations, imagine a bug in a self-driving car. He then states that you should spend at least 20 hours outside of work to be furthering your education and working on personal development. I believe this to be the key to success especially in our industry, things are moving so quickly that if you don’t stay up to date on languages and frameworks you yourself will become outdated and find yourself out of a job.

The second chapter discusses things that i am currently not as familiar with because it involves working in teams on large projects.However it was very interesting and insightful to read. I can completely understand the importance of staying true to your own objectives and maintaining composure in confrontations. However i  think the author may have understated how difficult that that may actually be for some of us.

Week 1 Reflection

I will be writing a weekly reflection for my software development capstone in order to discuss what i have learned that week as well as my current progress and thoughts regarding the ongoing capstone project.

This is the first post in a series now that the first week of the semester is over. Although we did not do a great deal in the first week i have actually learned quite a bit. We have gone over the SCRUM development process as well as begun to implement it on a hands on project. This was an interesting experience because i have not done anything quite like this before. We have assembled teams of six people to work on parts of an open source project. Going forward it should be an interesting and unique learning experience.

I have also never contributed to an open source project before so i am very excited to begin learning about the project and open source as a whole. Working in actual development teams and submitting our code for professionals to review should be interesting. Hopefully we are able to get some of our code actually implemented into the project but who knows. The project we will be working on is called OpenMRS, and specifically a portion of that project known as AMPATH, which is located in Kenya.

5 Excuses Every Software Tester Must Stop Giving

Week 12 blog post for Software Testing

This week i have decided to read 5 Excuses Every Software Tester Must Stop Giving by Mahesh C..

As i am still relatively new to the world of software testing i am very interested in what exactly software testers do on a daily basis. What better way to do that then by looking at excuses software testers make very frequently, it was my hope to gain insight into the software testing world through this article.

The first excuse was “we don’t control our Test Environment, we have limited access”. The article then goes over the benefits of being able to fully control the environment. an example of this being ” You know all involved components, all software used along with their versions for your product to function. With time, trust me you will have many insights about their working, limitations and possible failure points.”. More importantly it discusses how you can actually do this within a team/ organization. They suggest starting to work very closely with a developer team and start to learn how they do everything and once you have shown competence ask them for control and logically they should give it to you.

The next excuse was “We don’t deploy a build, some other team does it for us”. They then discuss why this is a bad attitude to have, and their explanation is something that resonates with me personally. They suggest that deployment teaches you a lot due to it not always working and failing often means you are forced to learn and debug. This is something that i have personally learned, through my own experience.

Then it goes to “We don’t debug an issue, we find steps and log it”. In order for personal growth it is better to ask yourself a few personal questions and make sure the reason for the bug isn’t easily determined.

4. “I don’t know why it happened. Developer resolved it and i simply verified it”. This is somthing i completely understand. Learn from the developer and thenmaybe next time you won’t need them to fix it and you can do it yourself. A lot of these excuses are just plain lazy from ever perspective.

5. “I didn’t get the opportunity to work on anything else than Manual Testing”. There are time actors involved however there is always that extra bit of time where you could do these things. Again this comes down to the testers being just plain lazy.

The Complete Beginner’s Guide to Responsive Web Design Testing

Week 11 Blog Post for Software Testing

This week i decided to read The Complete Beginner’s Guide to Responsive Web Design Testing by Laxmi

This article was of interest to me because in my Software Construction class i am developing a web application as my final project. Therefore i have become slightly more interested in web design and the testing that is involved with it.

One of the largest issues of this generation is that you do not know if the user will be on a cell phone a tablet a laptop or even a TV and the screen sizes for all of these devices range from 4 inches to 60 inches. Therefore you need to develop your web application in a way that it is able to look good and work properly on all of these devices. they define responsive design as “one website for every screen”. Although it encompasses much more than that. They later go on further to define it as a website designed to have a superior user experience, easy navigation, clear and simple interface, able to adapt easily and work in all resolutions, browsers, screen sizes, hardware, and operating systems.

This is done through flexible layouts, media queries, and flexible media. The issue is how do you test if a website is responsive without pulling it up on all of the possible screen sizes which is impossible to do. This is where software testing tools come in that change the screen size and resolution allowing you to test for a large variety of devices.

As i am developing a web application myself i found this article to be interesting and helpful at the same time. I look forward to optimizing my website using the information that i have learned in order to create a better experience for the user.