Programming Projects and Practices

A site dedicated to my passion for application development


Putting together this website.

Improving my skills on both
the frontend UI and backend.

Finally writing the principles
I hold dear as a software developer.

Persuing my hobbies and my career.


James R. Galyen
125 Sheffield Rd.
Groveland, IL 61535

E-mail: See Resume
Tel.: See Resume

Software Design Patterns

Having a lot of something is great as long as it isn’t too much.

Too much of a good thing is not a good thing.

When you think about design patterns, you should ask yourself one question. What am I trying to accomplish? I want to preface that people tend to jump on a specific pattern or technology and use it for just about everything. Yes, familiarity and consistency can improve productivity. But in my experience, it can also introduce layers of inefficiency, unmanagability and delays.

How do we accomplish expectations?

My first go to is, which is better understood by also reading the principles behind the Agile Manifesto ( I have found that these ideas work very well to meet and often exceed expectations. You still need to conforming to existing business structures. Don’t go around your boss, Project Manager or Business Analyst and talk to the business directly if that is not how your business is structured. But responsibilities can be divided and still accomplish the Agile Manifesto as a whole / through a group.

Scrum and Extreme Programming are two different Agile approaches that can helps you. But the Agile Manifesto really supersedes those approaches. Because both approaches are heavily invested in tools and processes. And the Agile Manifesto says that there should be more importance placed on individuals and interactions than processes and tools. But it also goes on to say that the processes and tools are important. They just aren’t the most important thing in Agile.

It is also important to note that customer software is not always the solution. Maybe there is a boxed package that fulfills a majority or even all of the desired expectations. That boxed package may even be an open source project that is freely available for commercial use.

Another tip is to conform and work together with the people in your team . Get in sync and work like a well oiled machine. If you do nothing but think outside the box, nothing will be accomplished inside the box. Jump on other peoples ideas, be an encouragement and work towards a common goal. And only when great value might be added do you want to work outside of the box and add complexity.

Expectations may almost seem like a tangent leading away from Software Patterns and Practices; but on the contrary: The Software Patterns and Practices you chose to use should be built to achieve expectations.

Let’s Get Technical!

NOTE: Work in progress. Some places, references are missing. Other places may be incomplete.

Terms and Meanings

Action Item – An item, often including how-to steps, you wish to be accomplished.

User Story – An easily understandable way of writing business expectations.

Gherkin – A way of writing easily followable steps to complete a task.

Service Level Agreement (SLA) – A contract about up-time and guarantees an application is expected to adhere to.

Threat Management – Agreement on how data will be used and what would happen if that date gets stolen. Based around Security.

Critical Path – Linked functionality that is crucial for the applications purpose.

Red-Line Error Path – Linked functionality that is followed when system or application is not in an idea state. It is often present in robust applications. And may or may not be considered part of the Critical Path.

Minimal Viable Product (MVP) – An application that contains only a Critical Path set of functionality. The goal is for it not to lack in quality. But rather lack in features. Red-Line Error Path is sometimes not considered part of the Critical Path. So MVP has a tendency to lack in Quality.

Fully Featured Product (FFP): – An application that contains all the desired features. It is often associated with the waterfall methodology. But over time and with enough feature requests, a deployed Minimal Viable Product can be transitioned to a FFP.

Robust Quality Product (RQP) – An application that contains both the Critical Path and the Red-Line Error Path set of functionality. The application is aware when the Critical Path is not in a good state and acts accordingly. For instance, in a web application, an error message would be displayed to the user if the database is not reachable.

Note: There is a measurable line between MVP and FFP. But RQP is a different type of measurement applicable regardless if an application is closer to MVP or FFP.

Testing – Entry points that can be individually ran, or ran as a group, that verifies something is in a usable state.

Unit Test – A type of test which is limited to testing a small piece of code that does not reach out and interact with other pieces of code and does not access external resources.

Integration Tests – A broader type of test which can test how several units of code interact with each other. It may even access external resources. But it does not test the entire slice of functionality from beginning to end.

Functional Tests – This tests the a full slice of functionality, from the beginning to the end. Often involving a User Interface if one is involved in your application.

Test Driven Development (TDD) – A methodology where all code is first written in a test. Then refactored into the application.

Behavior Driven Development (BDD) – A methodology much like Test Driven Development, where everything from code to UI components to external resources are first written in a test. Then refactored into the application. The tests are then setup to include the purpose of the functionality you are trying to test. Often in the form of a User Story.

Concurrency / Multi-threading:

ACID (Atomicity, Consistency, Isolation, Durability) – A set of guarantees that makes sure data is in a consistent [or good] state before allowing access to that data (Consistency and Isolation). And if something goes wrong while in that isolated state, the changes can be undone (Atomicity and Durability). Note: ACID pattern is most-often associated with databases.

Immutable Object (unchangable object) – is an object who’s state cannot be modified after it is created. They are useful because they are inherently thread-safe. Once constructed, it can be read from multiple threads without locking.

Data Consistency – A guarantee that data will be in a useful state when accessed. Delaying access to data in an inconsistent state is one way to accomplish this. Denying access all-together is another. Returning a handle that can be used to see when the data is consistent. Returning a copy of the data when it was last consistent (read-isolation). And utilizing non-blocking mechanism is yet another.

Eventual Data Consistency – The idea that Consistency will eventually be achieved if you are able to identify it and have some process in place to bring it into a consistent state. It could be someone reviewing a report and manually correcting data. Or an automated process.

Permanent Data Inconsistency – The idea that there is a chance that data may never become consistent or reliable.

Immutable Data – Once a data structure is made (consisting of one or more data points), it cannot be changed. But instead, a new data structure can be constructed from the previous data structure with the desired modifications applied. Once constructed, it can be read from multiple threads without locking. Or another way to look at it: It is permanently locked for reading.






Layered / N-Tier –

Microservice –

Plugin/Moduler/Microkernel –



Event Driven –

Space Driven / Cloud Model – Replicated entry points to your system, often a website distributed across many servers (e.g. cloudflare), means you can also split your back-end processing across systems. There may be a delay before a central point collects that data. Or there may be a lookup across those dispersed back-end systems before being able to retrieve that data.

Through this website, I show my ambition and passion for programming. If you read my About Me Page, you will see how my apitite for programming first started.

Here is a picture of me and my wife.

My wife is currently software developer for United Facilities. She was a CS Major / Math Minor student (much like myself) at Bradley University in Peoria, IL.

Her skills include: Computer Programming using .NET C# / VB.NET, SQL, EDI, and Reporting; Artist (self-taught, skipping art 1 to art 2 and getting an A) working with drawing people, landscapes, and web design; Linguistics and Foreign Languages such as Japanese and Spanish (not to be confused with computer languages); Creative Writing; and probably much more.