Quran SDK (library) for iOS

I mentioned a good while previously that I'd extracted code out from my Hifdh Tracker and Hifdh Tester Android apps into a Quran SDK for Android. Well I've just started porting these apps to iOS and as a first step I've ported the Quran SDK for Android to its iOS equivalent. The Android and iOS SDKs are essentially Kotlin and Swift (respectively) wrappers around the Quran database which make it super easy to get data out of the database. You can find the repository for the SDKs here. The README in the repository explains how to incorporate and make use of the SDKs in your own Android and iOS projects.

Android: Display bulleted list in a TextView

The BulletSpan class in Android has some quirks about it which makes it a little difficult to use. For example, each character sequence which is to be bulleted has to be preceded by a new line character. And using BulletSpan alone you're not able to specify how much vertical space you want between each bulleted character sequence. For this reason I've put together a Kotlin extension function on the SpannableStringBuilder class named appendBulletSpans(...) which takes the difficulty away from creating a bulleted list.

You can use this extension function as follows:

val spannableStringBuilder = SpannableStringBuilder()

spannableStringBuilder.append("Here is a list of fruits:")

spannableStringBuilder.appendBulletSpans(
    paragraphs = arrayOf("apple", "banana", "carrot"),
    putVerticalSpaceBeforeFirstParagraph = true,
    verticalSpaceToPutBetweenParagraphs = verticalSpaceInPixels,
    horizontalSpaceToPutBetweenBulletPointAndParagraph = horizontalSpaceInPixels,
    bulletPointColor = Color.BLACK
)

textView.text = spannableStringBuilder

This will render the text in a TextView as follows:

You can find the source code for this extension function in the SpannableStringBuilderExtensions.kt file in this repository.

Book Review: Pivot – Real Cut Through Stories by Experts at the Frontline of Agility and Transformation

This was an alright read. Some of the contributions I thought were a bit on the theoretical side which wasn't what I was expecting judging by the title but there were some good real life examples mixed in. Some of the points that stood out for me were (1) the importance of differentiating between Agile the process and agility as a mindset, (2) understanding that being agile and willing to change a product's direction is a good thing but changing direction doesn't come for free and (3) having a hero culture in an organisation is bad without exception.

Below is a small selection of excerpts from the book:

"Having even just a few people in hero positions can be a sign of bad leadership."

"Leaders should foster environments where the team as a whole is valued and appreciated. It is not to say that we shouldn't acknowledge individual efforts. After a job well done and recognising the team, if you feel someone deserves more, tell them in person."

"I recommend replacing the demand for heroism and sacrifice to setting a goal of sustainable goals. As a result, the team becomes confident in their abilities without the hero of the team."

"The traditional image of heroism does not fit all-stars agile team."

"A leader should be equipped to spot both a culture of hero worship and individuals who engage in self-sacrificial behaviour at the cost of long-term sustainability."

"No more heroes."

"Knowing your organisations purpose and creating a unified vision spanning organisational silo together with cross-team collaboration is essential to delivering value and maintaining market relevance. Nokia's high performing Agile teams, did not stop it from losing huge market share to Apple and Google in the upper end of the smart phone market.  Being Agile is not enough."

"There is no world where feedback doesn't take time to implement. If this is a project with an agreed delivery date, when the client gives you feedback, you need to manage expectations and move the goalposts. Change doesn't come for free. Adapting to change is a two-way thing."

The Four Types of Test Double: Dummy, Stub, Fake, Mock

A test double is a pretend object used in place of a real object for testing purposes. The four types of test double are as follows:

Dummy

• An object that is passed around but never used.
• Used to help fill parameter lists or fulfil mandatory field requirements where the object will never get used but gets the code to run.
• In many cases it's just an empty or null object.

Stub

• An object that always returns the same canned response.
• Used when you want to replace a real implementation with an object that will return the same response every time.

Fake

• An actual working implementation (close to but not of production quality or configuration) that can replace the real implementation.
• Can be seen as an enhanced stub that almost does the same work as the production code but takes a few shortcuts in order to fulfil the testing requirements.
• An example is an in-memory database (used instead of a real, persistent database).

Mock

• An object that represents a series of expectations and provides canned responses.
• Can be seen as a programmable stub which can be told the sequence of calls to expect and how it should respond to each one.
• Combines well with Dependency Injection in that it allows pretend objects to be injected that will behave in precisely known ways.

(Source: The Well-Grounded Java Developer, by Benjamin J. Evans and Martijn Verburg)

Book Review: The Well-Grounded Java Developer, by Benjamin J Evans and Martin Verburg

Although Java 9 is now out and this book was written way back when Java 7 was new I still found this to be a very useful and educational read. The book explains the fundamentals of the Java platform (e.g. bytecode, garbage collection) and programming principles in general (e.g. concurrency, dependency injection, functional programming) in a way that I've not seen in any other book. The introduction and contrast of the Groovy, Scala and Clojure JVM languages I also thought was done well. Some aspects of the book are now dated but it's still worthwhile skimming over for a historical context of how the platform has developed. If you're new to programming and new to Java development however this probably isn't the right book to start with.

Types of programming languages

Interpreted vs Compiled

• In an interpreted language each step of the source code is executed as is.
• A compiled language uses a compiler to convert the human-readable source code into a binary form as an initial task.

Dynamic vs Static

• In a dynamic language a variable can contain different types at different times.
• In a static language the type information is all about the variable itself, not the value in the variable.

Imperative vs Functional

• An imperative language models the running state of a program as mutable data and issues a list of instructions that transform that running state.
• A functional language operates on values but, instead of altering the inputs, functions act like mathematical functions and return new values.

(Source: The Well-Grounded Java Developer, by Benjamin J. Evans and Martijn Verburg)

Book Review: The Elements of Scrum, by Chris Sims and Hillary Louise Johnson

I got this book after reading the abridged version by the same authors. Like the abridged version this book is well written and the concepts well explained. The book opens with a good comparison of "waterfall" vs "agile" development. Following this is a very enjoyable exposition of the agile values and principles (individuals and interactions over processes and tools etc etc). Following this is the core part of the book: explanations of the roles (product owner, scrum master, team member), ceremonies (sprint planning, daily standup, sprint review, sprint retrospective, backlog grooming, story time) and artifacts (product backlog, sprint backlog, burn charts, task board, definition of done) that make up scrum. Within the core part of the book is a good explanation of what user stories are and how they help with understanding what needs to be built, for who and, importantly, why. And closing out the core part of the book is a discussion on some tried and tested strategies for estimating stories.

I've not read any other books on scrum so I can't compare but I'd be very very amazed to find a better one out there than this one. This book covered absolutely lots of ground whilst remaining compact and, most importantly, very readable.

Below is a small selection of quotes from the book:

"...only by demonstrating working software to your customer can you find out what they really want... agile processes include constant feedback from customers, projects stay relevant and on track..."

"...The main idea behind the agile approach is to deliver business value immediately, in the form of working software, and to continue delivering value in regular increments..."

"...Document as you go, and only as needed..."

"...It’s only human nature to become attached to something you worked hard to produce; if you spend the same amount of time drafting your documentation as Tolstoy spent writing War and Peace, you may find yourself treating your masterpiece as if it were the work product itself..."

"...In order to be successful, a contributor-scrum master must put the needs and success of the team above the desire to directly contribute..."

"...Being a scrum team member isn’t about getting your job done, it’s about getting the job done..."

"...Velocity should never be used as a performance metric: it’s not about demonstrating to management that you’re working fast enough; it’s about gaining predictability of schedule..."