In chapter five of Robert C. Martin’s The Clean Coder, his topic is Test Driven Development (TDD).  Last semester I took a course called Software Construction, Design, and Architecture, in which we practiced a bit of TDD.  I also took a class called Software Quality Assurance and Testing, and if the title did not give it away, was mostly about software testing.  With the benefit of those courses I do know a bit about TDD, and because of this, I can confidently say that Martin was spot on with this chapter.  The most important thing to take away from this chapter is Martin’s three laws of TDD.  The first is, “you are not allowed to write any production code until you have first written a failing unit test.” The second is, “you are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing.” Finally, the third is, “you are not allowed to write more production code that is sufficient to pass the currently failing unit test.”  The rest of the chapter is dedicated to explaining the benefits of TDD.  My suggestion is to try a simple program, and if you follow his three laws, you should be able to determine the benefits for yourself.

Chapter six was entitled “Practicing.”  The message of this chapter was, that to be a professional programmer, you must keep your skills sharp, and in order to keep your skills sharp, you must practice.  Martin discusses his experience with the Coding Dojo, and the activities associated with it.  Kata, Wasa, and Randori are three coding activities used to hone your programming skills.  Martin also suggests working on Open Source Projects or mixing up which languages and platforms in order to expand your knowledge.  I certainly believe that practicing is an important part of being a programmer.  Once you become an experienced programmer it makes sense to repeat older problems and try to hone your skills.  I, on the other hand, still consider myself a novice, and I think my time is better served expanding my knowledge as much as possible before I begin repeating past projects.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

I continued reading The Clean Coder by Robert C. Martin this week.  This blog post centers around the content of chapters three and four.  The majority of chapter three is actually an article by Roy Osherove entitled, A Language of Commitment.  The main theme of Osherove’s article is the three parts of making a commitment, which are, “you say you’ll do it,” “you mean it,” and “you actually do it.”  Essentially he is speaking to following through with your promises.  Osherove also speaks to signs of noncommitment, such as using words like “need,” “should,” “hope,” “wish,” or “let’s.”  He says that a real commitment follows a structure like, “I will … by …”  At the end of the chapter, Martin summarizes Osherove’s points, and puts it in terms of professionals.  This chapter was pretty straight forward and I can’t say that I disagree with the message.

Martin entitles his fourth chapter “Coding” but if you were hoping to find some code, then you will only find disappointment.  This chapter centers mostly on when you should not write code, how you are probably using bad practice while coding, and how you should mitigate expectations.  Personally, I think a more proper title for this chapter would be “Negative Nancy’s Guide to Why You Suck at Coding.”  First of all, this chapter begins with a section called “Preparedness” but I do not see the relevance to the material in the section.  Martin describes the necessary elements of code, and then he talks about concentration.  He then describes a plethora of different distractions and advises the aspiring professional programmer not to get distracted.  On a side note, I found it interesting that Martin suggests that a programmer should put in eight solid hours a day instead of attempting to code for longer.  I found this interesting because in chapter one he suggests that you should commit at least 60 hours a week to your career.  If you only code for eight hours a day, seven days a week, that only equates to 56 hours.  For someone who claims to be a great professional programmer, I find his basic math skills lacking.

Well, I am now 76 pages into this textbook, only 109 more pages to go.  I’m not saying that this is the worst text I have ever read, and it has certainly given me something to write about, but I am certainly finding The Clean Coder to be far more idealistic than practical.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

This is the first installment of learning reflection posts for my capstone at WSU.  This week in class we formed groups to work on projects.  I am still figuring out what we will be doing exactly, we are very early in the process, but we started pulling resources.  This week I read up on OpenMRS and AMPATH.  I started reading through this book which I found on the OpenMRS website and gained some knowledge about the background and goals of the project.  As for AMPATH, I perused the website, and gained an understanding as to what they are trying to accomplish.  In all honesty, it seems like OpenMRS and AMPATH are noble endeavors, and I’m excited to get started on our own project.  I suppose the next step is to get together with our group and begin creating our product backlog, and start our first sprint cycle.  Unfortunately, this week was mostly spent on researching what we are getting involved with, and there was little physical progress.  Hopefully, next week will involve more direction and some real progress will be made.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

This past week I read the first two chapters of The Clean Coder by Robert C. Martin.  The first chapter’s main focus is on professionalism.  Martin defines professionalism as a “marker of responsibility and accountability,” (8).  He then proceeds to explain what he means by that statement, and he describes what he believes makes a programmer a nonprofessional.  In chapter two Martin describes in detail an aspect of being a professional.  He stresses the importance of saying “no” when a programmer is asked to complete tasks in unrealistic timeframes.  He provides numerous situations and describes why some ways of handling the situation of saying “no” are better than others.

So I am 43 pages into reading The Clean Coder, and I must say that Martin definitely has a very strong opinion concerning his topic.  To an extent I would say that I find it overboard and at times even condescending.  The thought that an employee is only a professional if he or she would pay ten thousand dollars back to the company for an error just seems unrealistic.  Additionally, I can’t imagine an employee keeping his or her job for very long if he or she kept saying no to their employer when asked to complete an assignment.  I understand that I am oversimplifying Martin’s point, but at the same time, you must make adjustments and compromises in order to fulfill demand, even if that means not testing every piece of code that you write.  Hopefully I find some more realistic information in the later chapters, because as it stands, I find Martin’s writing to be far too idealistic to be useful.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Well, it’s a brand new semester and that means a whole new slew of blog posts.  Buckle up buckaroos!

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Week 12

For my final blog I want to talk about a skill that I have learned is needed, when to give up. When having a deadline you must not only try and implement new interesting technologies, yet also provide a fluid user experience that is inline with the software requirements. While working on a school project I crammed learning many tools into a three week span to produce a product. Our product was a web based Hall pass. This was a simple application that would stress many concepts yet as an idea remained simple relative to many other ideas.

To name a few tools Chris Braley and I learned:

• gulp
• composer
• Laravel Framework
• Homestead using Vagrant
• Eloquent
• Elixr

These are just the main components of our web application. We worked very hard to learn and implement our ideas and Models in this new environment. We were successful yet we had to make some compromises on how we went about it. In order to preserve the development time we had we needed to skip learning the in’s and out’s of Laravel Homestead. This is a virtual machine vagrant setup that has everything you need to work with laravel, yet getting it to work properly for both of us was a challenge and we spent a great deal of time on this. Eventually we had to make the decision to throw in the towel to ensure we could produce the requirements at the quality we desired. Choosing to ignore this aspect and the advanced Roles management library allowed us to develop a system that could handle improper input from the user to avoid errors. We chose to step back and reevaluate the need of this aspect of laravel and we knew we could continue to develop without it. This ultimately led to our success of our final project.

From the blog CS443 – Triforce Code| Exploring and Learning by CS443 – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.

Week 11

Penetration Testing and Vulnerability Scanning are two sides of vital testing that should be preformed on all production applications. But what are they? and what are their differences?

Lets start by defining each.

Penetration Testing is the act of brute forcing, and using common and known hacking techniques to exploit weaknesses of an application.

Vulnerability Testing/Scanning is the act of checking all software versions to ensure they are up to date with current security standards.

Will these prevent an attack, maybe…There will always be a possibility of being compromised but the more caution and thought you put into your design you can minimize this risk. Because just like physical crimes, criminals look for unlocked doors.

 As you can imagine both of these are vital to a systems analysis. Yet both have their time and place. These test should be ran when major software upgrades and even downgrades are needed to ensure software integrity. Tools like Kali and Appscan by IBM, are just an example of a penetration testing software suite and a vulnerability scanner.

The main difference is this:

Penetration testing looks for unknown vulnerabilities and scanning checks for known security issues in older dependencies.

Getting Started with Web Application Penetration Testing

From the blog CS443 – Triforce Code| Exploring and Learning by CS443 – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.

Week 10

Backend testing sounds like a scary word. To be able to take out the intimidation from this idea we need to break it down into its components that usually make up a backend:

• Database(s)
• API’s
• Servers

Honestly that all! Now that we broke it down into terms that we have heard before it become easier to think about how we would go about testing each one of these components.

Databases:

How would you test a database? Well lets start with what does this component should provide.

• Lists of data
• Quick Responses
• Secure connections

Now there is a lot of room for error if your database is not properly configured. Security relies on both the UI restricting access, and security patches being up to date. Quick responses is something that should not be too hard, yet if you create complex queries without the hardware to handle the transactions in mass quantities, bottlenecking could occur. The same could be in the inverse. If you have a poor query and have multiple collections of data stored and variable you may use more time than thought to manipulate the data. This is why you want Entity relationships to be properly initialized to leverage the Databases design for relational queries that are cached and fast.

So how do we test this? well the answer is pretty simple. SQL! you want to create queries of equal complexity of your application and gather results and statistics on how your database handles the queries. By doing these tests a developer is able to leverage the optimal way of extracting data for their application.

API’s:

API’s are Application Program Interface’s that allow you to connect to a suite of public functions that are open for use. These are usually decided upon early on. So testing for these can begin early to allow for re-evaluation of the goal/implementation if problems arise. The trouble with many API’s is that they can be depreciated and this is common as many companies improve their software and databases. You can create custom tests and view the logs to see the output of the API call.

Servers:

Now this is a topic which is hard get specific but say you have a server with a OS and tools that server the purpose needed then the steps you can take to test this just like any part of the database is benchmark softwares. This allows the tester to grade the performance and many other factors of software and other tools.

Working on a backend in a way may sound scary but remember this is not something we have not worked with before, it just could be on a larger scale :).

Resource:

How to Perform Backend Testing

From the blog CS443 – Triforce Code| Exploring and Learning by CS443 – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.

Week 9

I have been enjoying the Software Testing Help Blog. The writer has a way with keeping me interested while making me think in a few different ways. When I saw this post I couldn’t help but read it. Sushma goes on to many points and explains both sides of the coin for Developers vs Tester. I love the start and it just makes sense, Developers think “how can I build this application” and Testers think “how can I break it”. She goes on to explain that this game of cat and mouse is like Tom and Jerry ( a Cartoon that makes up a large portion of my childhood so it rang with me) when they work together you get a beautiful end result. Although much of her article explains how testing at the end of an applications development cycle is just expensive and impractical. That testing is something that should and is commonly done throughout the development cycle.  The ending of her blog sums up some great ideals of both a Tester and Developer that really shows how they are designed to work together to achieve an end result. Throughout she explains how a tester needs to think about how an input form may react to different inputs based on the requirements. This to me only makes sense yet the whole time I was thinking the developer should be wise enough to put in place these error messages and handlings. She ended up wrapping this up in a nice description of what a developer’s goal is and what a tester’s goal is.

I could not write this portion any better and it made the whole blog meld together perfectly for me. It really sums up the job descriptions to see how they end up with the same goal in mind, a great piece of software/1=

Resource:

The Difference in Perspective of “Testers” and “Developers”

From the blog CS443 – Triforce Code| Exploring and Learning by CS443 – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.

Week 8

Coding as we all know can have its challenges, yet sometimes you just get stuck and frustrated with seemingly no solution. Then you decide you need a walk or coffee break and you come back solve your problem almost immediately. Trust me it has happened to me more than I can count. Taking a break is not always just to get through a coding wall but also to allow yourself to think more clearly of your goals and the direction you choose to take.

Sometimes you can go on a coding marathon and at the end realize you have overcomplicated the solution and need to refactor. This is why we are seeing so many companies in the tech industry encourage their employees to stop and take a break from their work. Stress can be a motivator but also a hindrance to clear thought. The open environments that companies such as Google or Facebook have are not just to keep their employees happy but to make them feel less constricted and stressed, they can solve problems in an environment that encourages creativity as well as being human and playing a game or interacting with coworkers. Companies like Google have seen the power of leaving computer nerds with free time and plenty of passion (and an NDA that owns every cool Idea you have :P). Taking a break is not just for getting stuck but also can help us take a step back and realize the big picture and not just the piece you are working on.

Inspiring Resource Blog:

http://brianburridge.com/2007/07/08/increase-programming-efficiency-by-taking-breaks/

From the blog CS443 – Triforce Code| Exploring and Learning by CS443 – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.