Friday, September 16, 2016

Android Font Settings To Enable Font Variants

Today I learned that fonts often have settings to enable alternate representations of particular characters. For example Gotham is not a monospaced font.  However, if you enabled the "tnum" setting for your Android TextView, then the font will render as monospaced. That is cool!

It appears Android is supporting a W3 standard with this feature. The documentation has a link that references CSS Fonts. Furthermore, this method was added as part of API 21. So unfortunately your users on older API will not see the awesome column layout you can produce.

Android TextView Documentation

In code this would look something like this:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {    grandTotal.setFontFeatureSettings("tnum");}
or perhaps you are targetting API 21 and can apply the XML setting so that any string put into the field uses the "tnum" or other settings:


Or perhaps you are targeting API 19 and your TextView has a style set that you can override in the values-21 directory:

    android:text="$20.13" />

Then you can define a base style configuration in values/styles.xml
<style name="example"> <item name="android:textSize">24sp</item> </style>
and then apply the fontFeatureSettings in values-v21/styles.xml
<style name="example"> <item name="android:textSize">24sp</item> <item name="android:fontFeatureSettings">tnum</item> </style>
I think the screenshot below with two emulators illustrates the difference well. You can clearly see that the columns do not line up between the three TextView fields.
On the right with "tnum"

Tuesday, August 30, 2016

Constant Code Reivew

Pair programming is constant code review.

Is there a column on your Kanban board for "Code Review"? Do you pair program? Why would you need that code review column?  That column is counter intuitive. It is not an agile software practice. I am not proposing you never code review. Actually the opposite. You are more likely doing constant code review.

We know that bugs are easier to fix the earlier they are found. So we pair program. Fix the bug as soon as it's typed with an attentive pair. You save time by doing it right the first time. Each time you or your pair inadvertently types a bug is a learning/teaching opportunity. Use these moments to talk and internalize how that bug came through and make a mental note to not let it happen again. When you make the mistake is the best time to learn from the mistake. So make sure your pair is being attentive and reviewing the code you type.

How big are your stories? Do they take more than one pairing session? Every time you pair-switch the incoming person should be reviewing the code. The review should cover the design patterns in use as well as looking for typical pitfalls where bugs crop up. Sure, there are probably other things that happen during pair switch. Make sure you review the code that came before! Maybe your stories are not bigger than one pairing session.  It does not matter.  Hold your pair accountable to be an active copilot.

The Agile Manifesto says "Individuals and interactions over processes and tools".  A code review column is putting process over your team members. We already established that you are pair programming. Why would you need to declare code review only happens after the pair team thinks the story is complete. What!? That doesn't make sense. How can the story be finished if it still needs a code review. Invest in your people. Don't let them use a code review column as a safety net that catches problems. The tightrope walker that has no net is much better at their craft than the one using a net.  They have to be or it's a really short career (grin). Take away your safety net to get better at YOUR craft.