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

"Christianity is impossible"


I remember saying that to myself many years ago. And what I meant by that is “the Christian life is impossible to live”. The standard is too high. I can’t live it.

And I think I was right!

RxJava is not intuitive... and what helped me to somewhat understand it


"Software development has not changed in the last 40 years"... and what to do about it.


In the last 40 years computer hardware technology has increased the computing power of our machines by well over twenty orders of magnitude. We now play Angry Birds on our phones, which have the computing power of the freon cooled supercomputer monsters of the 70s.

But in that same 40 years software technology has barely changed at all. After all, we still write the same if statements, while loops, and assignment statements we did back in the ’60s. If I took a programmer from 1960 and brought him forward through time to sit at my laptop and write code; he’d need 24 hours to recover from the shock; but then he’ll be able to write the code. The concepts haven’t changed that much.

But three things have changed about the act of writing software…

— Uncle Bob Martin (from “Three Paradigms”)

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.