1. POODR Highlights Part 1

    By Shaun Finglas

    Practical Object-Oriented Design in Ruby or POODR is clearly a book about Ruby development, however the odd aspect is much of the concepts apply to other languages. In fact I've taken these ideas and used them both before and after reading the book in other dynamic languages and even static …

  2. The New Guy

    By Shaun Finglas

    Everyone is new at some point. No matter your experience level. You're either new to the team or new to the business. Being the “new person” is both a blessing and a curse.

    You're New

    When you're new you come with no baggage. You're full of questions and curiosity.

    • Why …
  3. New and Shiny Things

    By Shaun Finglas

    There is risk with upgrading anything, be it language, framework, library, OS or third parties.

    In the past I was rather gung-ho about upgrading. New version out? We need it. In fact, this need is often a want. The new version often seems better. Developers seem addicted to the latest …

  4. Past Mistakes - ORMs and Bounded Contexts

    By Shaun Finglas

    Sticking with the theme of documenting past mistakes, it's worth expanding a real life scenario where I was unaware of the use of bounded contexts and fully understanding the tools you use.

    Ignoring a Bounded Context

    A fellow developer set upon a quest to rid numerous projects of duplicated records …

  5. Test Your Live System using Live Service Tests

    By Shaun Finglas

    Traditionally there are three categories of functional tests.

    • Acceptance
    • Integration
    • Unit

    This is often refereed to as the testing pyramid. Unit tests form the bulk of your suite, followed by a smaller subset of integration tests. Acceptance tests that cover features should be the tip of your testing strategy, few …

  6. Why You Should Do Code Katas

    By Shaun Finglas

    Code katas are simple exercises that are meant to be repeated. They are great for learning a new language or tool. The goal is to learn something, not to complete them. In fact, if you don't finish a kata that is perfectly normal as long as you take something away …

  7. Notes on Building and Deploying Software

    By Shaun Finglas

    Builds and Deploys

    Ideally a build and deploy should be a single step, included within the check out of the repository. Additionally the build should include and install pre-requisites if missing. You can safely assume the target OS is at least configured, but any missing packages should be installed as …

  8. Ten Lessons from Rewriting Software

    By Shaun Finglas
    1. It Will Take A Lot Longer Than Estimated

      • Its navie to actually think this but if a system has been in production for say five years, expecting to reproduce it in five weeks is not possible. You may be able to get 80% of the core functionality done, but the …
  9. Anaemic Domain Models and Code Smells

    By Shaun Finglas

    An anaemic domain model (ADM) is considered a code smell in many cases. An ADM is present when you have a entity representing your domain, but void of any behaviour. Any logic is separate and operated upon in isolation. Such domain models can be thought of as simple property bags …

  10. I Need to Stop Misusing Divs

    By Shaun Finglas

    I a certainly not a skilled or expert front end developer. While I'm more than capable of creating pages I lack any design magic to make them look half decent. Despite this one area where improvement can be made is in my markup itself.

    Over the past few months I've …

  11. UI Composition Techniques for Services

    By Shaun Finglas

    When using services be it SOA, microservices or some other hybrid approach, at some point you will need to display an aggregation of data onto a UI. This simple task can actually involve some complexity and hidden pitfalls.

    As an example, this blog could be powered by three independent services …

  12. DDD - Bounded Contexts

    By Shaun Finglas

    A single domain can grow large when applying Domain Driven Design. It can become very hard to contain a single model when using ubiquitous language to model the domain. Classic examples prevalent in many domains would be Customer or User models. A bounded context allows you to break down a …

« Page 2 / 13 »