Tuesday, January 31, 2017

The Clean Coder Chapters 3 and 4

The Clean Coder Chapters 3 & 4

Chapter 3:

I had favorable things to say about the first two chapters because they kind of reminded me that no matter where you work or shall I say I have worked, a lot of it rings true but it is also to me just common sense. I mean saying no and saying yes? I feel like a bit too much is dedicated to this and it gets old real fast and I want to skip on but I pushed through chapter 3 and well once again I have to say it is really to me a lot of common sense things. I guess I shouldn’t say common sense, but for me I learned a lot of this by trial and error and promising things to people that I knew I couldn’t get done but just wanted to please so and so and felt that I would just deal with the blow back later. You can only do that sort of thing so many times (for me once or twice was enough) before you catch on and realize not to promise things that you can’t deliver and to commit to things that you’ll do when you say you will. I guess the book does a decent job at laying out situations and the outcomes so hopefully people won’t make the same mistakes that Bob made. I feel though that I have lived through all of the scenarios in some way or another so I guess I got a chuckle out of it. He says that the language of commitment can sound scary and it can help solve a lot of the communications problems facing coders. He is absolutely right but it definitely takes time to learn how to do it and be taken serious about it. You have to build trust and being straight about things is the best way to do it.

Chapter 4:


I feel that this chapter is also about experience and a bit of sense. This is all life stuff and applies to any form of work in my opinion. He talks about preparedness and how coding is intellectually challenging and how if you aren’t prepared for it your work will suffer. I find that this seems like my dad is preaching at me when I was 16. I mean of course your work is going to suffer when you can’t concentrate or when you are tired. The worst code written at 3am, I have been there and don’t do that anymore because I have learned the hard way and the good ole flow zone where you think you are actually doing an awesome job reminds of the people who say they do their best work high or drunk. Sorry it just doesn’t work like that as like he said, yes you may get a lot done, but what did you miss? I am sorry but I guess I am kind of disappointed with the first few chapters. I was good with the first two at first but the next two to me seem to be more of the same lessons just in a different context and I can’t write anymore about them. It does however seem like the rest of the book will be decent to me. I thought his other book ( Clean Code) was good so I figured that this would be more of the same and I hope the rest is.

Tuesday, January 24, 2017

The Clean Coder Chapters 1 & 2 and Week 1

The Clean Coder, Chapters 1 & 2

After reading the first 2 chapters I felt like I had read my own experiences over the past twenty something years. I wasn’t a programmer or in anything to do with computers, but the more I read and learn about this field the more I find that even though I was doing something different, a lot of the same issues happen no matter where you are.

In the first chapter on professionalism he talks about how it is easier to be a nonprofessional because they don’t have to take responsibility for the job they do. That got me to thinking about the term. No matter what job or jobs I have had I always tried to do them as a professional. I think the term work ethic could be used to describe professionalism as well. You get out what you put in. I felt like I had been in similar situations as I read the chapter. He seemed to go through something everyone must go through at some point in life. I enjoyed how he learned from his errors and passed wisdom on. The lessons learned from releasing the product without properly testing and it went south. This was all to save face and look good because it went out on time, but then the backfire. Though you think you are saving time, in the end you lose time and man hours when if it had of been done right the first time a lot could be prevented.

I like his take on the do no harm function as well. We can’t be perfect, but we must be responsible for our imperfections and should always be trying to get our error rate approaching zero and expect QA to find nothing wrong. If that is the thought process you should genuinely be surprised when they do find a flaw. I have been in the situation where I half assed something to get it done on time and was not surprised in the least when it failed. Wasted time and hours when I should have just done it right the first time.

I really felt like his work ethic and knowing your field hit the nail on the head as well. They gave me something to try and think about. I like the time breakdown. It humbled me actually when he was talking about the first 40 are for the employer and 20 aside for me. I had never thought of it that way and it humbled me. He set up some very realistic ideas on how to utilize time. As far as knowing the field, I feel like I have a lot to do. I know I am just getting started, but I didn’t realize just how much there is to just know for the basics. I picked up a copy of the gang of four design patterns books to increase my learning on that end and plan on just plucking away each day to increase my chops.
Overall I gained a great deal from chapter one and plan on reading it again. I wish I had come across this sooner.

Chapter 2 and saying no brought back many memories as well. I think a lot of people in general have issues with saying no and want to just get along and cause no waves. I am one of those, well was. I do not like to say no because it is uncomfortable for sure, but that was because of the way that I said no. I usually offended someone because I didn’t think before I spoke. I have changed. He makes some great points on how to and not to approach situations. His role playing scenarios were ones I have been a part of myself to some degree. I was one of those people that used to say I’ll try and had never thought boss would think of that as a yes I can get it done on time. It makes sense though because I’ll try is like beating around the bush.  Overall there were a lot of good points that can be used no matter where or what job you are doing. I am sure that once I get into the field that I will be practicing my version of saying no and this book will come to mind.

Week 1 learning

I am still trying to process everything that I have gone over this week and am still in the process of going over it. The first couple weeks of the semester are the hardest for me. I try to make a schedule of my time so I can manage everything. I am excited for this one though as it is my last undergrad semester and a long time coming. I have been going through some Angular 2 tutorials to get a grasp on how it works, and using the node package manager and other tools. I think it is going to be a lot of fun to learn and use and I hope to become proficient with it.

The Open MRS project is overwhelming to me so far, but that is I guess because I am just getting into what it is all about. I tried the demo and like the functionality and can’t wait to get my hands dirty. I think it is great that so many folks are collaborating on this records system that can help so many people around the globe. I am eager to get started in this journey and hope that whatever we do this semester has an impact in the years to come. I know I am going to have a lot of challenges, but I welcome them with open arms.



Wednesday, January 18, 2017

New post for Software Dev Capstone

This is my up and running post for this semesters software development capstone class. I look forward to a great semester and some good blogs and a lot of learning and put everything we learned together.

Monday, December 19, 2016

On the semester

Well for my last blog of the semester I figured I would give some thoughts on the semester and my experience blogging. I don’t anticipate this to be very long but here goes. At first I was unsure what to make of blogging as I had never done it before, but as I got into it I thought that it is a great idea to get your ideas out there and to have others see what you’re up to and what the latest testing and development tools and techniques you have been using. It seems to be great as well for others to possibly give feedback on what you’ve written or input on experiences they may have had and can give advice on how to improve on what you have been doing.

That being said, as far as having to try and come up with something to write every week after checking out 5 blogs on testing and picking one that seems to be interesting to you ended up feeling more like a chore to me. I am not saying I didn’t learn anything or that I didn’t enjoy seeing what types of testing styles and techniques folks are using in the industry as I have never worked in the industry as of yet and it gave me a glimpse into what I might be working with and getting involved in possible. My main issue was that I was writing about something that I have had no practical experience in so it was hard to talk about something I haven’t used. I mean it was fine for a few blogs, but after writing about testing techniques that other people are writing about, you begin to realize that there seems to be only so many things and a lot of the blogs talk about similar things or experiences, just in different companies or settings. The name changed but the test stayed similar.


Overall it was a great learning experience and I would take any of it back and I hope that some of you had a good experience as well and it was a pleasure to spend the semester with all of you.

Sunday, December 18, 2016

In memory testing

I really enjoyed this blog because I had never heard of in memory databases before this. They do however make sense to me. I had always thought of databases as their own unit, but never really gave much thought to an in memory one. The fast access for certain programs makes a huge amount of sense and I can see the uses for them as he gave examples of routing tables and event poster.

What was interesting is that I can see the use for things such as router tables, but didn’t give much thought to the testing uses part of it. Databases can be overwhelmingly large and when it comes to testing, I imagine that that size comes with a cost, speed. In comes in memory databases to the rescue. It drastically reduces the time to test because of the speed that memory works at which in my mind can increase the output of the product possibly.

I think that if I ever do a lot of testing this is something that I may indeed try out. You can read more about it here:


http://www.martinfowler.com/bliki/InMemoryTestDatabase.html

Tuesday, December 13, 2016

On bug prevention

I really enjoyed this blog. The main theme more or less was can bugs be prevented? He goes on to talk about how in testing we go at the software from many different angles looks for bugs, but just how often is it that we actually think about preventing them and are they actually inevitable and can they even be prevented in the first place? While bugs are inevitable he believes that they can be somewhat prevented and after reading his blog I believe he is right.

He goes on to explain the general things we can do about prevention such as better communication, trying to make less mistakes in the code, understanding the platform that is being worked on and the list goes on. The main question he asks is this; What can a tester do to help with bug prevention? Testing happens usually after the bug is already in place and it is the then too late to prevent the bug right? Well maybe not. He goes on to say that the testing and the results report can actually influence the teams thought in some areas or things. He says, “For example, something as ‘innocent’ as an email saying: ‘I’m planning some testing of feature X and I wanted to make sure I’m not duplicating work on this. What kind of unit tests have you done on this?’ can gently nudge coders to think about unit-testing their code (and the bug prevention benefits that come from writing code that is unit-testable in the first place).

I really enjoyed this blog as he makes many good points and if I am ever in the tester role I will surely take some of his points to heart.
You can read the full blog here:

https://offbeattesting.com/2016/12/13/preventing-bugs/

Tuesday, December 6, 2016

Software Project

I figured that I would start a blog about my software development project that I am doing in coordination with another classmate. I have to say that I was very excited about this because up until now, aside from a few projects of my own (small to say the least), I have never been involved in really working with someone to create something from idea to release. The finished product will not be complete by the time it is due but we will continue after classes end to complete it. We are using the agile development process for the project which is nice because we don’t necessarily have to have the whole project complete all at once, but instead base it upon what is important based upon the client’s need and timeframe.

On to the project. We are creating a web application called Web Hall Pass which is based on a program a teacher at Leicester high school developed in Visual basic, but wanted it redone in a different language so it could be used on a server. What the program does is allow students to check out to the bathroom, principal, gym, nurse, etc. and generate a hall pass either by printing it or the student can take a picture with their phone via the program which is running on a computer in the classroom. This is good in that the student can get up and check out when he/she needs to go somewhere without interrupting the teacher mid class.

After discussion we chose a PHP web framework called Laravel that uses the Model View Controller (MVC) architectural pattern. There are some challenges because neither of us have ever used this before so a lot of reading and doing tutorials was a necessity. Once we got the basics down, working with the framework didn’t seem as intimidating. The great thing about Laravel is the ease of creating tables, and html pages(blades) and how seamless the integration is between the framework and the database. You run commands using PHP artisan to create models, controllers, migrations and too much to discuss here. That being said we have barely scratched the surface of what is capable. The nice thing about it is that it takes away the daunting tasks that you face in just using PHP alone. Validation, security, authorization and more is already taken into account with Laravel, where as in PHP you have to write all of that.


The main thing I think that I see with web frameworks is that they allow you to go from idea to release faster than ever, and as we all know time is of the essence.