Jeremiah Flaga My thoughts and experiences on programming, life, atbp.

HorizontalChangeHandler sliding from/to the left


I’m a very lazy programmer. One of my forms of laziness is that I never remember things about the code I write. Indeed, I deliberately try not to remember anything I can look up, because I’m afraid my brain will get full. I make a point of trying to put everything I should remember into the code so I don’t have to remember it.”

— Martin Fowler (from his Refactoring book, p. 56)

Another form of laziness that we, programmers, have is to not rewrite anything that is already written by other programmers.

"Working Effectively with Legacy Code" of Michael Feathers


“For a long time it’s puzzled me that most books on software development processes talk about what to do when you are starting from a blank sheet of editor screen. It’s puzzled me because that’s not the most common situation that people write code in. Most people have to make changes to an existing code base, even if it’s their own. In an ideal world this code base is well designed and well factored, but we all know how often the ideal world appears in our career.

“So this book is important because it’s written from the perspective of what to do with an imperfect yet valuable code base.”

— Martin Fowler

Recollection of my journey with Business Rules - Part 1


There are lot’s of reasons why one writes blog posts. One of them is this: so that he will have something to laught at when he gets older.

This post might be one of those posts I will laugh at when I get older… It sound like I’m bragging about my old but insignificant work! :laughing: Who cares, right? It might be insignificant to others, but it was significant to me.

So here we go…

In my five years of experience working as a programmer I have come into a deeper appreciation of the importance of separating the business rules from the other parts of a software system.

How to create tests when you are using Sugar ORM (version 5) in an Android app


Let’s say that in your Android application, you are using Sugar ORM in your data source class, which does the CRUD to your local database.

import com.example.domain.MyDataSource;
import com.example.domain.MyEntity;

import io.reactivex.Completable;

public class MyRepository implements MyDataSource {

    public Completable save(MyEntity myEntity) {
        return Completable.fromAction(() -> {
            MyDbModel myDbModel = new MyDbModel(;

    public Single<MyEntity> get(UUID id) {
        return Single.fromCallable(() -> {
            // TODO: Select.from(MyDbModel.class)...


… And you want to make tests for you save() method (some call this integration tests, instead of unit tests, because these tests touch the database).

On maintainability and the separation of the business rules


“The value of another’s experience is to give us hope, not to tell us how or whether to proceed.”

— Peter Block (through Woody Zuill in his talk on mob programming.)

Story time!…

During college, I became interested about solving algorithmic problems. But because of lack of mentorship and my lack of knowledge in higher maths and algorithms, I decided to concentrate my energies into studying how to create line-of-business (LOB) applications (or what is called “representational-transactional systems” here).

I thought to myself that creating LOB applications is much easier to do — it does not require lots of knowledge in maths — and I thought that I can easily get jobs in the future if I concentrate on creating LOB apps rather than solving algorithmic problems.

During those times, I was curious about how people structure their code in real-world projects.

Testability and good systems


I recently read “The Tale of Three Kings: A study in brokeness” by Gene Edwards.

It is a small book of comfort for Christians who experienced pain and heartache caused by other Christians! — A very beautiful book, I would say.

It tells the story of the young David in the hands of a mad king, King Saul; and the old David and the rebellion of his son Absalom.

TDD and acknowledging imperfection


(Just a thought regarding the discipline of TDD — TDD from the perspective of a hopeful inexperienced TDD advocate:smile: This might help convince others to accept TDD)

When we do TDD, we are acknowledging that we are not perfect beings

— That we might be wrong… and that someone else (in the future perhaps) is able to correct that wrong (that someone might still be you — the better future you!). And that by doing TDD, we are just making a way to make the work of that someone (which could be you) much easier and faster.

So software developers can call themselves (ourselves) engineers!?


I do not call myself a software engineer, even though many other programmers call themselves software engineers, because the “real” :grin: engineers might become angry with me. :laughing: … because engineers study lots of maths, and it seems like programming do not really require mastery in lots of maths…

But I recently found someone who says that we, programmers, are engineers! — — Glenn Vanderburg, in his talk “Real Software Engineering”.

OFW Watch


Yesterday, January 2, 2018, was the launching of the OFW Watch app in Mynd Consulting’s office in Davao.

This app, which is available for the web, and iPhone and Android devices, was made by my coleagues at Mynd Consulting. It is part of the advocacy of Mynd Consulting’s founder and president, Ma’am Myrna Padilla, on helping OFW’s solve some of their problems. — An app that will help “empower OFWs” is what they call it. — Ma’am Myrna herself is a former OFW, so she has a big heart for her fellow OFWs, and that is the reason why this app was created.

Books I read in 2017


Following what John Sonmez is doing, I will start listing the books that I read at the end of each year…

“Growing Object-Oriented Software, Guided By Tests” (GOOS) by Steve Freeman and Nat Pryce

GOOS image

Learned about what they call Outside-In TDD (Or London School of TDD as what Emily Bache calls it) — writing both End-to-End tests (also called functional tests or acceptance tests by others) and writing unit tests at the same time.

(Secret: I skipped some chapters in Part III because there are lots of code already and I find it hard to follow. I only wanted to glean general ideas during the time that I read this. But this book is a classic, so I’m going to read this again… later…)