Nicole Carpenter

Writing Better Tests

09 Dec 2016

When I first started my apprenticeship at 8th Light, I learned very quickly that testing code was not just a good thing to do, but also a published company value. Those were the early days when I was just beginning to appreciate the many benefits of TDD, while also learning how to craft meaningful and valuable tests. Now that I am more experienced and aware of the value that testing provides, I have been able...

Pairing Tour Day 9

15 Nov 2016

If you have not yet noticed, the dates of my “pairing tour” blogs have been relatively spread out. This is because I am not taking the typical 2 week block at the end of my apprenticeship for pairing, but rather picking one person per week to work with during the couple of months leading up to my challenges. This allows both me and my pairs more flexibility in planning a productive day with actual coding....

Pairing Tour Day 8

07 Nov 2016

Finally, on one of the last days of pairing, I got a chance to pair on a Clojure project. Mike D had been on this particular project for two years, so he was a great person to sit next to for the day. I really like functional programming for the fact that it forces you to handle data without the overhead of OO structure. Let me start by noting that the application we worked on...

Pairing Tour Day 7

02 Nov 2016

Last week was my first time going to 8th Light’s Libertyville office, today will hopefully be my last. I don’t have an issue with the office itself, just long commutes seem incredibly inefficient to me. Today I paired with Colin. Colin is the company’s CTO, and as such, I had a hard time pinning him down for an pairing appointment on a day where we could actually work on code. My encore appearance in Libertyville...

Pairing Tour Day 6

26 Oct 2016

For my most recent pairing tour adventure, I met up with Stephen in Libertyville, a commute that I had been avoiding with vigor for the past eight months. Of everyone in the office, I probably have spoken to Stephen the least. The Libertyville office is a couple of hours away and I don’t blame him for opting to not take the trip. One benefit that I had with pairing with Stephen is that he is...

Pairing Tour Day 5

13 Oct 2016

Pairing today was with Brian N, who works on the same client as my mentor, Zack, but on a different project team. Zack is on a team that deals more with the marketing aspects of the application, though their current focus aligns more closely with what Brian’s team usually does. Brian’s team works mostly with the client facing side of the application. The client that they work with has the largest number of 8th Light...

Pairing Tour Day 4

11 Oct 2016

Today was my second day pairing with Zack. As predicted yesterday, I did get more keyboard time. If there is one lesson that I have learned today, it is that JavaScript is omnipresent, and I have to get better at it. I will start with an observation that I also made while working with Malcolm, which is that I am still surprised at how much non-coding time is spent during the day. Zack ran a...

Pairing Tour Day 3

10 Oct 2016

Today I had an abbreviated day of pairing with Zack, after my original pairing partner was having a day not well suited for pairing. The benefit to starting my pairing two months rather than two weeks before the end of my apprenticeship is that the value of my experience with each pair can remain high in instances like this. This is the third person with whom I have changed pairing days with due to either...

Pairing Tour Day 2

06 Oct 2016

Today, my second day pairing with Malcolm, we virtually met from two different sides of the city. It actually worked out well that we were pairing remotely because I was able to work from home while waiting on a washer machine delivery. Now, I have worked from home on a couple of previous occasions, but today was a lot more productive because pairing remotely forced me to remain focused, which is not the usual state...

Pairing Tour Day 1

05 Oct 2016

Today I had my first soft introduction to my pairing tour, working with a familiar face: my mentor Malcolm. I have paired before with him, but previously I was working towards my own personal goals, not on his daily client work. Today I got my first glimpse of what my day-to-day is going to look like once I finish my apprenticeship. I am definitely nervous going into my pairing tour, especially considering I have very...

Pushing to Clojars with Gradle

04 Oct 2016

The title of this post is misleading, because I still don’t know how to push to Clojars with Gradle, but I did learn a lot trying to figure it out. Let’s start out with the basics. I created a project that I divided into two applications, with Application 1 being a dependency of Application 2. Application 1 is an HTTP server whose sole concern is receiving an HTTP request and returning an HTTP response. How...

So that's what CI is for

03 Oct 2016

Last week I pushed up my Note Taker application to GitHub and was met with an unpleasant error that I couldn’t figure out how to reconcile. The command "eval ./gradlew assemble" failed 3 times. I have a problem where sometimes when I see red, I get tunnel vision and I focus on only a small piece of the error, rather than reading the entire picture. In this case, the error message itself was what I...

Testing Behavior vs Implementation

09 Sep 2016

I sent my mentors a message last night, several hours past when the last dev left the building, proclaming that finally, 6 months into my apprenticeship, I was able to understand the value and meaning behind the idea of testing behavior vs implementation. If you are a regular consumer of my blog, you probably recognize this topic. This is something that I have struggled to grasp because I had a hard time differentiating the difference...

IO Streams

10 Aug 2016

Essentially, An input/output (IO) stream is a way for a Java program to interact with the outside world, a powerful abstraction that represents a source of continuous data entering or exiting a program. The source or destination of data can be one of a wide range of entities - such as a file on disk, a network connection, a keyboard or any peripheral device, or another program. The types of IO can be categorized three...

Mocking HTTP Server Sockets for Tests

10 Aug 2016

I have been picking away at my Java HTTP server for the past few weeks, but the bulk of my time has been spent writing and unwriting the part where I open the socket connections. My first solution on my spike worked great, but then when I tried to apply TDD and reimplement the same design, I quickly realized that it just was not going to work out. Here is a simplified version of where...

Type Casting

05 Aug 2016

One thing you discover quickly about Java is how fussy it is about the information it will handle. Java methods and constructors require things to take a specific form and won’t accept alternatives. When you send arguments to methods or use variables in expressions, you must use variables of the correct data types. If a method requires an int, the Java compiler responds with an error if you try to send a float value to...

HTTP

04 Aug 2016

HTTP stands for Hypertext Transfer Protocol, and it is the protocol that is used for communication over the web. HTTP is what allows you to view content on a web browser, so for instance when you go to www.google.com, you are greeted with the familiar Google Doodle and search bar. This dynamic page lives on a server somewhere controlled by Google. It is called a server because it serves something, in this case an html...

Gradle Build

28 Jul 2016

With deciding to not use an IDE to develop my Java Http Server, I am accepting the additional responsibility of correctly wiring up the server’s dependencies and learning how to create my own jar files. I have not gotten to the point where I need to do that yet, so currently I am still working off of a very rudimentary file structure. . ├── README.md ├── build.gradle └── src ├── main │ └── java │...

Issues with My Game of Life Implementation

27 Jul 2016

I spent the last two and a half days working on Conway’s Game of Life in Clojure. This was my punishment (not really) for trying to write object oriented tic tac toe. While I got clearance from my mentor to return to the Java Http Server I was working on previously, there is one nagging issue that I have with the implementation that I designed that I want to walk through my potential refactoring. The...

Object Oriented vs Functional

27 Jul 2016

In my previous post I spoke about idiomatic Clojure and the reasons we would want to write code that follows a language’s style and structure conventions. I mentioned that certain rules apply to object oriented languages that cannot necessarily be applied to functional code, so now I am going to give an overview about why that is and what the general differences are between object oriented and functional programming languages. Most people, when they start...

Idiomatic Clojure

26 Jul 2016

I just received my last bit of feedback from my Clojure tic tac toe application. There were a few nit-picky things that I should have caught, but besides those, the major theme was that my Clojure was not Clojure enough. Sure, I was using Clojure constructs, and everything worked and was tested, but it was very obvious that I was trying to force a functional programming peg into a object oriented programming hole. One term...

Reading for Comprehension

22 Jul 2016

I am almost two-thirds of the way through GOOS and I am finding that, with yet another technical book, I am having a difficult time following what is going on. This book is a walk through of a test driven approach to writing an application using Java, JUnit, and JMock. This is not an unfamiliar feeling during my apprenticeship. My first couple of assigned reading materials were Bob Martin’s Clean Code and Agile Software Development,...

The Main Class

21 Jul 2016

For the last few weeks I have been reading GOOS, and chapter 18 of the book works through refactoring the main method. I am but a Java novice, so I wanted to dig a little deeper into what belongs in the main method and the best way to design it. The main method should be used only as an entry point to start the program. It can live in any class, but it should logically...

Handling Exceptions

21 Jul 2016

In my previous post, I introduced you (myself) to Java exceptions including defining what an exception is, identifying some of the reasons they would occur, and noting the difference between checked and unchecked exceptions. In this post I will talk about ways to handle different types of exceptions. First of all, an exception is not an error. An exception is a way of handling an error. Exceptions are classes, or in an object oriented language,...

About Exceptions

21 Jul 2016

I am attempting to make a Java server without having any experience in Java. I do feel like I have a pretty decent handle on the language, considering that I had worked on my first apprenticeship project in Swift, also a statically typed language, and also because several of the technical books I have picked up during my apprenticeship have had code examples written in Java. That being said, one thing that I am finding...

Testing the GUI

20 Jul 2016

Now that I have a Clojure sprint under my belt, I am coming back to working with Object Oriented languages for my current assignment, building a Java server. So far, everything I have built during my apprenticeship has worked strictly as a terminal application, however I see an expansion on the horizon. Many of my cohort mates have gone on to integrate one of their apprenticeship projects with their server, whether as a mobile app...

Future Requirement Creep

15 Jun 2016

For almost four years throughout college I worked for a local granite company in Richmond, VA. One of my responsibilities as a salesperson was to go to my clients’ homes for in-home estimates. Estimating granite was a pretty simple process; you measure the cabinet bases and add the appropriate overhang. Sure, sometimes the final estimate would differ from the original for a change in plan like moving the seams or a change in design, but...

Generics

14 Jun 2016

As I was reading through GOOS, I came across a part of the code that uses generics, and a caution to try to not use generics whenever possible. This brought up one important question: what the heck is a generic? According to the Java documentation, generics in Java allow types to be parameters when defining classes, interfaces and methods. By type we mean a class or interface which could be a given Java class like...

The Black Box

12 Jun 2016

In the last post I briefly mentioned the concept of black box testing. A black box overall in computer science terms refers to a system or a component that has a set of known inputs and a set of known outputs. Outputs which are generated by some kind of transformation. The contents of that box, or more specifically the internal operational details, are hidden away from the user. A car can be thought of as...

End to End Testing

12 Jun 2016

I have spoken of end to end testing in a few of my posts, but I have never actually written these types of tests, so I am looking into some of the ins and outs for when I do. End-to-end testing is designed to make sure the flow of an application behaves as expected from start to finish. One reason to use this type of testing is to determine system dependencies. It also involves writing...

Cutting the Perfect Slice

11 Jun 2016

Vertical slicing is a way to divide an application’s design into very simple working end to end versions. This requires deciding on the possible states of the application and splitting up the different paths to get from a beginning state to an end state as would occur in the final version of the application. If you are working on an application that deals with an external database, business logic, and a user interface, for example,...

Wrappers

10 Jun 2016

I started to hear the term “wrapper” during my apprenticeship, and I generally used context clues to decide on its meaning, but I thought I would take a closer look. Using a wrapper, or wrapping a specific function, came up first when I was working with my hangman application’s input/output methods. My mentor encouraged me to wrap the system actions like print and readline in application functions so their behavior could be tested. More recently,...

Refactoring Tic Tac Toe Board

09 Jun 2016

During my tic tac toe application review, two points were brought to my attention regarding my handling of the tic tac toe board. I had taken the appropriate first step in designing the tic tac toe board to be an extension of an abstract board object, but how I was using that abstraction, and for what my tic tac toe board was responsible, fell a little short in the implementation. Abstract Board I created an...

Why

03 Jun 2016

Many times in my learning journey I’ll read or watch something, understand it at that point, but when the time comes to explain it to someone else, I have a difficult time relaying it back. I remember when I applied to Dev Bootcamp, they even asked during the interview process for you to pick any concept or action and explain the procedure to the interviewer. I did not see the value at the time, but...

Encapsulation and the Universe

02 Jun 2016

Encapsulation was one of things that I realized that I was doing already, but never associated the activity with the word. I actually thought that encapsulation was a much more complex concept until I took the time to look it up as I came across it in GOOS. The concept of encapsulation is pretty simple: hide what you don’t want others to know about and that to which you want to restrict access. The idea...

Fail First, Fix Later

01 Jun 2016

One very prominent bit of wisdom when programming in a test driven development manner is that we should follow what is known as the red-green-refactor cycle. This cycle dictates that before we write logic to make the test pass, we should first run the test, knowing that it will fail, followed by writing the least bit of logic to make the test pass, and then refactoring the test in a meaningful way. What maybe is...

Working with Legacy Code

31 May 2016

I have never claimed to be a reader, and I won’t promise that this copy of Michael C. Feathers’ Working Effectively with Legacy Code will get cracked concurrently with GOOS, but it is definitely on my must read list. The thing that I am most concerned with, as I am move along in my apprenticeship, is being thrust onto a team and having no idea what is going on or how the code works. Chapter...

Revisiting Ruby Ttt Unbeatable Ai

27 May 2016

I have been working for the past eight day on creating an unbeatable AI computer for my tic tac toe Python application. When I applied to 8th Light, given the opportunity to code for an unbeatable computer, my ruby submission outlined a long chain of if/else statements that checked several conditions to decide where was the best position to place a computer marker to never lose. My May self is somewhat surprised that my December...

A Case for Mocks

27 May 2016

Chapter 3 of what will henceforth be known as GOOS (Growing Object-Oriented Software, Guided by Tests), presents a brief introduction into the testing methods to be presented in the book. One topic that was introduced was using a Java mock library called JMock. While I have not yet written a line of code in Java, I am certain it will appear soon in my apprenticeship, so I will be exploring JMock as a language infant....

The Law of Demeter

26 May 2016

The idea behind the Law of Demeter is to reduce coupling between classes. The law states that a software unit, like a method, should only communicate with units that are closely related. That means that a method should only know about the class in which it belongs, the method’s arguments, any object created within that method, or the class’s direct component objects. Method calls should not be made on an object that was returned by...

Levels of Testing

25 May 2016

Yesterday we apprentices spent time with Mike Jansen of 8th Light’s Chicago office talking about testing, and different levels of the so called “testing pyramid”. I began reading Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce, and the concept was raised again in the first chapter. Freeman and Pryce talk about unit tests and acceptance tests, briefly glossing over the fact that acceptance tests live somewhere in between. Mike’s pyramid looks...

Finite State Machine

24 May 2016

The concept of a state machine came up during my last post about the State pattern, and again in the final chapter of Robert Martin’s Agile Software Development- Principles, Patterns and Practices, so I decided to dive a little deeper. A Finite State Machine, also known as a state machine or FSM, according to wikipedia, is a mathematical model of computation used to design both computer programs and sequential logic circuits. A FSM consists of...

The State Pattern

23 May 2016

A few weeks ago, I wrote a post about state in my Snowman application. In the post I noted that the state of something refers to the contents stored in memory at any given point in time. The State Pattern is a design pattern that implements a state machine in an object-oriented way. To demonstrate this pattern, let’s look at the states of an online purchase. To think about the different states, we would consider...

On the Edge of the Minimax Cliff

20 May 2016

I have been working on my minimax algorithm for a solid three business days. In fact, were I not assigned a pretty ridiculous blogging requirement, that would have probably been three entire days. That is three days of cursing the Internet, three days of throwing books, three days of drowning in my own tears. Well, it has not really been that bad. I still don’t have a working solution so I am a little bummed...

The Visitor Pattern

19 May 2016

The visitor pattern is applied when there is a need to perform operations on objects that do not share a common base class or conform to a common protocol. The operations do not take place in the object, but rather are performed from an external class, allowing you to even add additional functionality that the concrete class does not allow. That last bit is key because this pattern allows you to add methods to a...

The Proxy Pattern

19 May 2016

In the tech world you may hear about a ”proxy server”, which is a middleman computer or software system that separates a client and a server. In real world terms, a proxy is a person or other entity that is given the authority to represent someone. This is typically used in the scope of voting; when a lawmaker cannot physically place a vote due to other obligations, they would assign a proxy to vote on...

The Adapter Pattern

18 May 2016

The Adapter pattern is a way to allow two classes to speak to each other that are otherwise not connected. This pattern is commonly used when dealing with third party APIs or any other class that is subject to frequent changes. The adapter will convert the interface of the API into an interface that our application can use. There are a few players to consider with the Adapter pattern. The adapter is the client interface...

The Observer Pattern

17 May 2016

The observer pattern is one that considers a one to many relationship with one single object and its many dependents. When the object changes its state, its dependants are made aware of the change. The object is the subject and its dependents are the observers, because they are observing the subject for a change. A real world application of this pattern would be an auction. The bid is the subject and its state changes when...

The Composite Pattern

12 May 2016

The Composite pattern offers a way to pair down one to many relationships at the file level into one to one relationships by creating a composite object that will maintains knowledge of many objects. You can manipulate the composite to act on a group of objects instead of having each object implemented individually. The composite can help with pairing down duplication because it will stand in for the same action for all of the objects....

The Builder Pattern

12 May 2016

The builder pattern was something that came up during my last project when I was making a Hangman application because I was creating a new instance of one class from a method in my other class, creating a hard dependency. This problem caused a violation of the Dependency Inversion Principle (DIP). Incidentally, the same problem came up on my Tic Tac Toe application, through essentially the same place in my View class. My View was...

The Factory Method

11 May 2016

Whenever I would hear the term factory tossed about the apprentice table, I would shudder a bit because my imagination paired the term with complexity. When I think factory, I think of Henry Ford’s Model T line, with hundreds of hands touching thousands of part. A factory in the programming sense does have a literal translation, but it is less about the abstract idea of complexity, and more about the literal role of a factory...

The Acyclic Dependencies Principle

11 May 2016

In software development, in addition to following good organizational practices at the class level, it is also important to consider how our packages are linked. When a package relies on another package for something, we say that there is a dependency between the packages. This means that the packages have to communicate with each other. Every package will have at least one dependency because this is how the system is connected. The trick is to...

Designing Through Tests

10 May 2016

I would like to pause momentarily to pat myself on the back for how steadfast I have been up to this point in my commitment to test driven development for my Tic Tac Toe application. In my previous application, a hangman console application in Swift, I was supposed to be test driving the application, but really that just turned into me “spiking” functionality, refactoring, and testing the working code. That is far from the Red-Green-Refactor...

Payroll Case Study - Abstractions

06 May 2016

I am presently going through chapter 19 of Robert C. Martin’s *Agile Software Design- Principles, Patterns and Practices. In this chapter, he starts into the payroll case study that was introduced during the earlier discussion of the SOLID principles. The chapter walks through some use cases that would come up during an initial iteration for this type of system. From my perspective, the most important part of the chapter was the process of coming up...

The Null Object Pattern

05 May 2016

The Null Object pattern is just a way to encapsulate the absence of a particular value within an accepted data type. For instance, if we are expecting an array, but there are no values in the array, instead of returning null, we can return [] for which there are no negative consequences. When using the pattern, the null is not necessarily unexpected; this is not so much a defensive pattern as much as a way...

The Singleton Pattern

04 May 2016

While the singleton pattern will not be used extensively, it is important to acknowledge. The pattern allows for the creation of one and only one instance of a class. We would use this pattern if the object controls concurrent access to a shared resource, and its access will be requested from multiple, disparate parts of the system. In order to ensure that a class cannot be created more than once, certain checks are written into...

The Template Method Pattern

02 May 2016

The Template Method pattern offers a very simple way to reuse code and reduce duplication by defining invariant behaviors within an abstract class, and then having concrete subclasses implement the abstract methods. A class marked abstract in Java is the same as a protocol in Swift. The protocol acts as a contract, specifying the functions or variables that an adopting class would need to include, in the protocol, they will not contain logic. For the...

The Facade Pattern

02 May 2016

The word facade comes from the French word meaning “face”. When someone refers to a facade in the physical sense, they are typically referring to the face, or any exterior wall, of a building. Additionally, a person can be giving off a certain facade, where they are portraying something superficial, often with hidden emotions or intent beneath. In the context of design patterns, the Facade pattern follows a similar path. In all cases, we are...

The Command Pattern

29 Apr 2016

The command pattern is a design pattern that aids in maintaining S.O.L.I.D code by encapsulating certain actions within classes, allowing for extension and facilitating testing. It completely decouples the sender, the object evoking the action, and the receiver, the object that is receiving the execution request. In the command pattern, there are four main players: the command object, which stores the values for the parameters of the receiver methods, the client, which instantiates the command...

The Dependency Inversion Principle

28 Apr 2016

I must admit, the first time I saw this concept in Bob Martin’s Clean Code, I was completely lost. I had just successfully implemented knowingly dependency injection, so my brain was at capacity with regards to dependency anything. Now, a month later, I am ready to revisit the subject. I am reading Martin’s Agile Software Development- Principles, Patterns and Practices and in my last four blogs, I have covered the first four S.O.L.I.D principles. Dependency...

The Interface Segregation Principle

28 Apr 2016

We have reached the I in S.O.L.I.D: interface segregation. Let’s break this down. The segregation part of interface segregation is pretty simple to understand. We want our interfaces to work independently of other parts of the system. I can assume from what I have read so far of Uncle Bob’s Clean Code and Agile Software Design - Principles, Patterns and Practices, that this also means that the interfaces will be free of dependencies. Then we...

The Liskov Substitution Principle

27 Apr 2016

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S,where S is a subtype of T. I want to start off by recounting the shock and joy that I experienced when reading that the author of the Liskov Substitution Principle is a woman. Cheers, Barbara Liskov! I never was that great at math. Thankfully, there is this alternative definition: If a program...

The Open-Closed Principle

26 Apr 2016

The Open-Closed Principle states that “software entities should be open for extension, but closed for modification”. What exactly does that mean? One way that you can think about OCP is that in order to make modifications, you are not actually changing a base class, but rather, you are adding code in the form of an abstraction to deal with the new requirements. This is easier to illustrate with an example. In my past life, I...

The Single Responsibility Principle

22 Apr 2016

The Single Responsibility Principle highlights the idea that a class should, as the name suggests, be responsible for one thing only. Modules that follow this principle have code that is highly cohesive, meaning the behaviors are highly related and strongly focused. A good barometer as to whether a class is following this principle is if, when describing the functionality of the class, you say “and”, it probably is not following the single responsibility. For instance,...

Legacy Systems

21 Apr 2016

I used to always think of legacy as a positive thing. When we take steps to preserve our legacy, we are bringing forth the positive aspects of ourselves to live on after we pass. A politician backs policies that will paint him in a positive light after he leaves office, his legacy. Not speaking ill of the dead is also a preservation of legacy. But if we are talking about software, on the other hand,...

The Bowling Game Design Process

21 Apr 2016

Chapter 6 of Robert C. Martin’s Agile Software Development: Principles, Patterns and Practices walks through his process pairing with Robert S. Koss on a Java bowling game scoring application. This chapter was very enlightening for me because it helped me witness the TDD process in action. Because there were no new technical concepts brought up in this chapter, I am just going to highlight some of the process that really surprised me as a junior...

Refactoring

20 Apr 2016

If you look in the refrigerator at 8th Light, you can usually tell when I have been there. The fridge will be stocked with all labels facing forward, all cans and bottles covered and aligned, just as the Marine Corps taught me. Everything has its place. Someone reaching into the fridge can quickly and easily find what they are looking for. This is how I want to leave my code. Writing good code takes both...

TDD - Driving the Application Design

15 Apr 2016

The act of writing a unit test is more an act of design than of verification. It is also more of an act of documentation than verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function. This note opens Robert C. Martin’s Agile Software Development: Principles, Patterns and Practices, my current daily reader. It particularly stuck with me...

The Planning Game

14 Apr 2016

Extreme programming takes a new approach to planning software development. My main observation about XP planning is how incredibly transparent the process is for the client. Clients participate in the initial release planning at the inception of the project, where a general idea of the shape of the project is established. Throughout the project, they plan along side of the developers during iteration planning meetings, where a more detailed plan for that iteration period is...

Pair Programming

13 Apr 2016

Last week I wrote a post that gave a quick overview of Extreme Programming, but now I want to talk about my experience with one aspect of XP: pair programming. I started my software development career at a programming bootcamp. The first nine weeks of the program were entirely remote, so the work that I was doing was rarely seen by others, which for me at that point in my skills dive was completely fine....

Agile Practices

13 Apr 2016

I have never been a professional developer. I am as close now as I have been to being a professional developer, but I have still not contributed “production” code, or participated on a software team. My only perspective of that world is what I have been told, and the resounding statistic rolling through my head is that historically and overwhelmingly, software projects fail. The godfathers of the agile methodology took note of this dismal fact,...

Improving Your Test Suite

12 Apr 2016

In John Searls’s 2015 RubyConf talk entitled How to Stop Hating Your Test Suite, he describes 15 pointers to designing an effective and efficient test suite based on three general principles: test structure, test isolation, and test feedback. I am going to outline one pointer from each area. Test structure - Limit the size of new objects John Searls, in his talk, mentions that he likes to limit new objects to 1 public method and...

What to do on Monday morning

07 Apr 2016

After reading through Software Craftsmanship by Pete McBreen, I am convinced that my decision to apply to an apprenticeship as my first step out of school was indeed the correct choice. I knew I was not ready to jump straight into contributing to production code, but now I am sure that no one out of traditional schooling is. Programming is something that takes practice. Sure, you can get by without a solid foundation, but very...

Repositioning Software Engineering

06 Apr 2016

Software engineering is appropriate when it comes to developing applications that are allowed large budgets, scopes and timelines. Because of the lack of constraints in these three areas, a different process for developing the software would be appropriate than for, say, a project that is under a tight and abrupt deadline. Larger scale projects, safety critical projects, or projects that involve a hardware component being developed concurrently, have the necessity to take more time in...

Implications of Software Craftsmanship

05 Apr 2016

Craftsmanship of any kind is a tiered approach to gaining mastery at something. Software craftsmanship, besides producing products that are at the highest standard, goes beyond the product to the people. The craftsman at all levels, his client, and the end users of the software are all important parts of the process. Becoming a craftsman is journey that starts with an apprenticeship. Apprentices learn from journeyman, who were once apprentices themselves. Journeymen that take on...

Software Craftsmanship

01 Apr 2016

I have been at 8th Light for exactly one month. I have discovered a lot about myself in these few weeks and both questioned and championed my potential as a software developer. In the last year or so that I have been on this trajectory, I have quarrelled with the fact that I chose to pursue something that I knew would not come easy for me. From the very first time I was dropped into...

Questioning Software Engineers

31 Mar 2016

I personally have never paid too much thought as to what makes someone a “software engineer”. To me, engineer was always more of a loose term for someone whose college degree contained the word “engineer”. I remember my Information Systems management professor citing that somewhere around 4 out of 5 “engineers” are actually just project managers. Those numbers have not been independently verified, but I see where he was going. Software Craftsmanship by Pete McBreen...

What's the deal with state?

30 Mar 2016

Prior to a couple of weeks ago, my deep understanding of state was reserved to the subject of matter: is something a solid, a liquid or a gas. In my pull request notes of my SnowMan application, however, my mentor wants me to consider another state: the state of my program’s variables. Why was I holding the state variables? It was a great question that I could answer shallowly with context clues and general knowledge,...

Clean Code: Chapter 17 - Smells and Heuristics

29 Mar 2016

Code smells are something my mentors here at 8th Light have been warning me about since I started my SnowMan project. I personally do not have the instinctive nose as do they, so I decided that I am going to make a quick cheat sheet with those that are listed in the book. Code Smell / Heuristic Description Refactoring Comments Inappropriate information Record keeping or other metadata...

Clean Code: Chapter 16 - Refactoring SerialDate

28 Mar 2016

SerialDate is a Java class that defines the requirements for manipulating dates when you need an instance without the precision that Java.util.Date gives. It is part of the JCommon library, which is a free, general purpose library. For me that brings up the question: what are these Java libraries? And why do we need them? As I am working on my Swift project, I am both using Swift’s standard library, and also avoiding using any...

Clean Code: Chapter 15 - JUnit Intervals

27 Mar 2016

Chapter 15 talks about the Java testing frame JUnit and ways in which the framework can be improved and refactored. Because the book does such a great job at showing how even professional level code can be improved, I am not going to try to re-explain the author’s work. Instead, I am going to talk about the subject of unit testing and why we take the time to test our code. Unit testing is a...

Clean Code: Chapter 14 - Successive Refinement

26 Mar 2016

While reading the first couple of chapters of Clean Code, I quickly realized that this book was going to be heavily laced with Java examples. The only moderate experience that I had with a programming language before joining 8th Light was with Ruby, and getting thrown into Java, while concurrently playing with Swift, was going to take a lot of slower paced reading for me to somewhat figure out what was going on in the...

Clean Code: Chapter 13 - Concurrency

23 Mar 2016

Before reading chapter 13 I had never heard of the concept of concurrency. I started programming a few months ago, and I have never dealt with production code in any sizeable scope. I think that trying to tackle explaining concurrency in detail is a little bit beyond my current capabilities, but in general, concurrency means decoupling what takes place in applications from when those things take place. This allows programs to operate without functional order...

Clean Code: Chapter 12 - Emergence

22 Mar 2016

Chapter 12 discusses some overall techniques that you can use to keep your whole code base clean and user-friendly. Specifically, the author references Kent Beck’s four rules of simple design, which note that a design is simple if it runs all the tests, contains no duplication, expresses the intent of the programmer, and minimizes the number of classes and methods. The concept that I want to talk about a little deeper is testing the application....

Clean Code: Chapter 11 - Systems

21 Mar 2016

Chapter 11 covers the higher level system design. One of the concepts that is discussed in this chapter is dependency injection, so I will go into my learning example on an application I am currently working on in Swift. The application is a hangman (Snowman) game that displays letter blanks to a player and the player guesses the letters until either they guess the word, or they run out of guesses. In Swift, the application’s...

Clean Code: Chapter 10 - Classes

18 Mar 2016

Chapter 10 of Clean Code talks about keeping classes clean and organized. All of the rules from the previous chapters apply in maintaining clean classes, such as descriptive naming, keeping classes small, and following the step-down method for organizing the functions within the class. This chapter, additionally, introduces several methods of the SOLID principle, to which I will detail today. SOLID is an acronym that speaks to five basic principles of Object Oriented software design:...

Clean Code: Chapter 9 - Unit Tests

17 Mar 2016

First Law You may not write production code until you have written a failing unit test. Se— layout: post title: “Clean Code: Chapter 9 - Unit Tests” date: 2016-03-17 — Robert C. Martin, in his book Clean Code, outlines three laws to abide by when working in a test driven development (TDD) fashion: First Law You may not write production code until you have written a failing unit test. Second Law You may not write...

Clean Code: Chapter 8 - Boundaries

16 Mar 2016

Boundaries are the points when your code meets with code written by others, where you have little control on what they deliver. It’s good to buffer these boundaries with Adapters so that your dependency on third party software isn’t widespread and when the third party software changes, you have one place to go and make the change. You want to explore the boundaries of third party systems. While it is not necessary to test third...

Clean Code: Chapter 7 - Error Handling

15 Mar 2016

Error handling is important, but if it obscures logic, it’s wrong As can be interpreted from the quote, error handling can become a nuisance to writing clean code. You want the logic of the code to be able to shine, and not get bogged down with error handling and interpretation. There are a few general guidelines to follow when deciding how to handle errors. One consideration is to use exceptions rather than return codes. Coding...

Clean Code: Chapter 6 - Objects and Data Structures

14 Mar 2016

There is an interesting distinction that Robert Martin, the author of Clean Code makes between objects and data structures. He observes that objects expose behavior and hide data, while data structures expose data and have no significant behavior. Programs will contain both data structures and objects, and each will have its purpose within the code. Because the data in objects is hidden, new objects can be added without changing the behaviors that are available. Conversely,...

Clean Code: Chapter 5 - Formatting

13 Mar 2016

Formatting, while not consequential to how the code actually works, does make a huge difference in how future user of the code will be able to navigate and understand what is going on. In formatting, particularly, the broken window theory applies. The broken window theory is a social science concept that looks at how a single, small act of neglect can lead to snowballing negative effects. The theory gets its name from the idea that...

Clean Code: Chapter 4 - Comments

08 Mar 2016

As a general rule, comments are bad. In addition to cluttering the code, comments become useless as code changes because often the comments are not changed when the code is changed. Usually if you find yourself needing to write a comment, it is because the code is not clear. There could be many reasons that the code is not clear, some of which were discussed in the previous posts about Robert C. Martin’s book, Clean...

Clean Code: Chapter 3 - Functions

07 Mar 2016

Functions should be as small as the action they take, which is to say, very, very small. Think one to two lines. In fact, a good rule of thumb is to never have more than one line of code per block, and one or two indentations per function. Deeper indentation indicates nesting, which can complicate code more than need be. Clean code author Robert C. Martin includes a great quote about the purpose of functions:...

Clean Code: Chapter 2 - Meaningful Names

04 Mar 2016

One of the most fundamental aspects of clean, readable code has to do with creating meaningful, sustainable names throughout the code base. Clean Code describes several conventions with which to follow, all of which are guidelines, but consider them best practices. Meaningful names means more than just consistency and readability. Here is a highlight of the concepts covered in Chapter 2 of Clean Code: Convention Description Example Use Intention revealing names Why does it exist?...

Clean Code: Chapter 1

03 Mar 2016

What do Grady Booch, Dave Thomas, Michael Feathers, Ron Jeffries and Ward Cunningham all have in common? Well besides being experts in their fields, they are also people whose opinions about software development strategies you should pay attention to, and additionally, they are all featured in Robert C. Martin’s book, Clean Code: A Handbook of Agile Software Craftsmanship. In order to understand what it means to write “clean code”, one has to recognize, not only...

Day 2 - Installing Swift Package Manager on Apple Platform

02 Mar 2016

Swift Package Manager is a handy swift tool that allows for the easy distribution of Swift code, while, according to its https://github.com/apple/swift-package-manager, addresses “compiling and linking Swift packages, managing dependencies, versioning, and supporting flexible distribution and collaboration models”. For laypeople like myself, that means GitHub integration. In order to install SPM, it needs to be downloaded from the https://swift.org/download/ download page. It is very important that the options at the very top are selected, under...

8th Light Chronicles: Day 1

01 Mar 2016

I realize that day 1 at a new job in a new industry is probably not the most accurate way to gauge the direction of your future, but man, do I have some observations. Before I get into the technical content that shall be the focus of this blog, I want to point out how huge of a change this new world seems to be. I cannot separate my decision to get into consulting from...

Why I code

31 Oct 2015

“Why do you want to be a developer?” This question seems to come up a lot during interviews. It is a different question from “Why do you want to work here?” because it speaks to something bigger than a job. It speaks to one’s identity. Like many other college students, I began college with very little direction. My sister was the only person I knew who had attended and graduated from college, so I used...

Personal blog

Writing Better Tests

09 Dec 2016

Pairing Tour Day 9

15 Nov 2016

Pairing Tour Day 8

07 Nov 2016

Pairing Tour Day 7

02 Nov 2016

Pairing Tour Day 6

26 Oct 2016

Pairing Tour Day 5

13 Oct 2016

Pairing Tour Day 4

11 Oct 2016

Pairing Tour Day 3

10 Oct 2016

Pairing Tour Day 2

06 Oct 2016

Pairing Tour Day 1

05 Oct 2016

Pushing to Clojars with Gradle

04 Oct 2016

So that's what CI is for

03 Oct 2016

Testing Behavior vs Implementation

09 Sep 2016

IO Streams

10 Aug 2016

Mocking HTTP Server Sockets for Tests

10 Aug 2016

Type Casting

05 Aug 2016

HTTP

04 Aug 2016

Gradle Build

28 Jul 2016

Issues with My Game of Life Implementation

27 Jul 2016

Object Oriented vs Functional

27 Jul 2016

Idiomatic Clojure

26 Jul 2016

Reading for Comprehension

22 Jul 2016

The Main Class

21 Jul 2016

Handling Exceptions

21 Jul 2016

About Exceptions

21 Jul 2016

Testing the GUI

20 Jul 2016

Future Requirement Creep

15 Jun 2016

Generics

14 Jun 2016

The Black Box

12 Jun 2016

End to End Testing

12 Jun 2016

Cutting the Perfect Slice

11 Jun 2016

Wrappers

10 Jun 2016

Refactoring Tic Tac Toe Board

09 Jun 2016

Why

03 Jun 2016

Encapsulation and the Universe

02 Jun 2016

Fail First, Fix Later

01 Jun 2016

Working with Legacy Code

31 May 2016

Revisiting Ruby Ttt Unbeatable Ai

27 May 2016

A Case for Mocks

27 May 2016

The Law of Demeter