I wrote a blog post about git-number and how useful it was for my command line git usage. In an on-going effort to simplify my lifestyle & setup, I replaced git-number with a few git aliases. I’ll explain how I recreated the functionality in this blog post.

A few Kotlin constructs have been introduced into the language over time. I wrote this post as a personal/public service advisory to remind us of their significance.

I’ve been looking into Tufte CSS recently. Tufte CSS -inspired by the teachings of the legendary Edward Tufte¹- provides suggestions and tools to style web articles for improved legibility.

I’ve started to incorporate some of those principles here while still trying to keep the authenticity of my original design. Most of these changes have been in the realm of CSS however the sidenotes feature was a slightly trickier beast.

If you’re a software engineer trying to be snarky, it’s important to get these terms right for maximum effect.

What is Yak-Shaving?

“Shaving a Yak” means performing a seemingly endless series of small tasks that must be completed before the next step in the project can move forward.

Is this a good thing or a bad thing?

It depends. Yak Shaving is sometimes very much necessary. It’s “bad” only when done unnecessarily. It’s unfortunate when necessary but might not be a bad thing at all under certain circumstances.

Two big announcements:

1. I made my first screen cast ¹
2. I’ve updated the permalink title for all the blog posts here ²

I wanted to make sure that external blogs linking to previous post links wouldn’t break. So in order to do this, I had to edit all of my previous blog posts and add a redirect_from tag.

Life is too short to be doing this manually so I whipped up an awk program to do it for me in about 20 minutes. It was so much fun building the program that I figured I should screen cast the process.

If you’re a programmer these days, you probably spend a large part of your day in git. If you’re a command line zealot like me, you realize the holy ways of using your Terminal app for everything and aren’t seduced by fancy GUIs that only stand to dissuade you from pure unbridled productivity.

With that in mind, one typically finds themselves in a position where they have a few files that have changed liked so:

This blog now ¹ uses Jekyll - a static blog generator that takes markdown as an input and pumps html as output. I then copy it over to my hosting server - Firebase, which then happily serves it to the interwebs.

This setup has worked out swimmingly well thus far and has been rock solid. Even when my last post got high up the ranks of HN, my blog held steady. Not even the slightest of fears or signs of being fireballed or slashdotted. This is the beauty of HTML.

The TestObserver is an RxJava staple for testing.

It allows you to assert values in a stream, in the specific order they were emitted. Here’s a quick code snippet from the movies-usf repository ¹:

@Test
fun onSearchingForMovieBladeRunner_shouldSeeSearchResult() {
    viewModel = MSMainVm(mockApp, mockMovieRepo)
    val viewStateTester = viewModel.viewState.test()

    viewModel.processInput(SearchMovieEvent("blade runner 2049"))

    viewStateTester.assertValueAt(1) {
        assertThat(it.searchedMovieTitle).isEqualTo("Searching Movie...")
        true
    }

    viewStateTester.assertValueAt(2) {
        assertThat(it.searchedMovieTitle).isEqualTo("Blade Runner 2049")
        // ...
        true
    }
}

If you look at the source for the base TestObserver, there are a bunch of these useful methods:

This super intesting stack overflow answer explains why -in programming- if you have a sorted array, somehow magically it can seem like it’s easier to process each element vs processing the same array if it were unsorted.

tl;dr - branch prediction

With a sorted array, the condition data[c] >= 128 is first false for a streak of values, then becomes true for all later values. That’s easy to predict. With an unsorted array, you pay for the branching cost.

Sometime back I ran across a thread where folks talked about this programming style called “Space Shuttle style” that the Kubernetes codebase followed.

// ==================================================================
// PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE.
// KEEP THE SPACE SHUTTLE FLYING.
// ==================================================================
//
// This controller is intentionally written in a very verbose style.  You will
// notice:
//
// 1.  Every 'if' statement has a matching 'else' (exception: simple error
//     checks for a client API call)
// 2.  Things that may seem obvious are commented explicitly
//
// We call this style 'space shuttle style'.  Space shuttle style is meant to
// ensure that every branch and condition is considered and accounted for -
// the same way code is written at NASA for applications like the space
// shuttle.
//
// Originally, the work of this controller was split amongst three
// controllers.  This controller is the result a large effort to simplify the
// PV subsystem.  During that effort, it became clear that we needed to ensure
// that every single condition was handled and accounted for in the code, even
// if it resulted in no-op code branches.
//
// As a result, the controller code may seem overly verbose, commented, and
// 'branchy'.  However, a large amount of business knowledge and context is
// recorded here in order to ensure that future maintainers can correctly
// reason through the complexities of the binding behavior.  For that reason,
// changes to this file should preserve and add to the space shuttle style.
//
// ==================================================================
// PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE.
// KEEP THE SPACE SHUTTLE FLYING.
// ==================================================================

To be clear: I don’t follow the Space Shuttle style programming with my own code. However, I’ve noticed now that when I do comment my code, I’m a little more liberal with my explanations. It’s made me realize that commenting your code doesn’t necessarily always mean bastardizing it.

This is a fantastic post by Erik where he explains the nuance between IO-bound and CPU-bound operations in programming.

… libraries have dedicated APIs for I/O scheduling work, separate from other types of operations

…. but why is this the case? Why don’t we use a single thread pool for all background operations? The operating system will handle the scheduling of these threads the same

I love how this specific question is framed (a good interview question for advanced mobile developers):

A not so well known api in RxJava is the .hide() operator.

When does one use the hide operator in Rx?

From the docs:

Hides the identity of this Observable and its Disposable.

Allows hiding extra features such as Subject’s Observer methods or preventing certain identity-based optimizations (fusion). there are a lot of complex operations that take place internally in RxJava (like internal queue creation, worker instantiation + release, numerous atomic variables being created and modified.)

This feature is beneficial for projects defining custom source sets, since the compilation of independent source sets can be parallelized. In the case of multiplatform projects, targets for different platforms can also be built in parallel. For Android, the debug and release build types can be compiled in parallel.

This sounds pretty cool, however I paused to think how often would i need the debug and release build types to be compiled in parallel? Probably CI like environment? oooo but with androidTest and test ? that might help.

We recently held our semi-annual hackathon at Instacart - the Carrot Wars 2018!

In putting this hackathon together, I noticed a pretty blaring gap - there wasn’t a simple (and free) online service that would quickly tabulate the results for a hackathon event. We looked around and found some nifty options, but most of them were a tad bit too expensive for our liking. They also were not setup for a single event use or required a monthly subscription. There other usage restrictions, too - max vote count, concurrent user count, etc.

Checkout this quick blog post I wrote for my company, tweaking the existing Kotlin TODO to work towards our requirements.

While I don’t think this solution is a panacea for all your missing code snippets, I have found some luck with this method, in adding accountability for those PR review feedback comments you say you’ll get to, but conveniently forget :)

Here’s a bonus if you’re reading this article from here:

In case you haven’t heard: RxJava2 was released sometime back. RxJava 2 was a massive rewrite with breaking apis (but for good reasons). Most dependent libraries have upgraded by now though, so you’re safe to pull that migration trigger with your codebases.

Folks starting out directly with Rx2 might enjoy this guide but it’s the ones that started with Rx 1 that will probably appreciate it the most.

Disposing Subscriptions

This was the part that I initially found most tricky to grasp but also most important to know as an AndroidDev (memory leak and all).

A common question most android developers have when using RxJava is: how do I cache or persist the work done by my observables over a configuration change? If you start a network call and the user decides to rotate the screen, the work spent in executing that network call would have been in vain (considering the OS would re-create your activity).

There are two widely accepted solutions to this problem:

hear ye, hear ye! the 2nd episode of the Fragmented Podcast is out. Donn and i start by discussing Lamas, blue dresses and IDEs for Android development!

i spent a huge part of my 2014 on “Rx” (or reactive extensions) which is essentially a library that helps with a development pattern called “reactive programming”. i think Rx is going to be huge in the app development world. it’s already picked up a lot of steam, but i think it’s going to become a staple for professional app developers.

consider this extremely common scenario:

you’re in Burundi surfing facebook. you want to get the latest updates from facebook, so your smart phone (from a network in Burundi) shoots a request to the facebook servers in Menlo Park. that server reconciles your request and sends back 5 epic selfies from your dearest friends. in our universe, this takes time. maybe not a whole lot according to you (a second perhaps) but for that mini super-computer you hold in your hand, that’s 1000000 microseconds. that’s a long time that you’re asking it to twiddle its thumbs (given that it usually processes stuff in a couple of microseconds). what’s it supposed to do until it hears back from the facebook servers? after it’s done showing you the updates for your first screen, when would it know to trigger another update? what if the data that came back from the servers indicated that you need some more information? what if the third request in that chain failed for some reason? welcome to the world of asynchronous programming. Rx (or FRP as it is mistakingly assumed to be synonymous with) was built to deal with a lot of this pain.

Ok, so in my previous post I innocuously introduced the .share() operator.

Observable<Object> tapEventEmitter = _rxBus.toObserverable().share();

What is this share operator?

The .share() operator is basically just a wrapper to the chained call .publish().refcount().

You’ll find the chained combo .publish().refcount() used in quite a few Rx examples on the web. It allows you to “share” the emission of the stream. Considering how powerpacked and frequently used this combo is, RxJava basically introduced the friendlier more useful operator share(). This mechanism is sometimes referred to as “multicasting”.

i listen to a tonne of podcasts. i find activities such as doing my laundry, driving back home from work, doing the dishes … all delightful because it gives me a chance to strap on some headphones and listen to a bunch of podcasts. in the time that i run those dreadfully boring chores i’ve found myself learning so much about technology and good software development.

as i was driving back home today i was listening to an episode of Ruby Rogues and thought to myself:

This is a bonus RxJava post that I landed up writing along with my previous post on creating an event bus with RxJava. If you went through the code in the actual repo you would have noticed more than one version of the bottom fragment in the RxBus demo.

Originally I envisioned the RxBus example being a tad bit fanicer however as I coded up the example, I realized that too many concepts were getting conflated. The ridiculous simplicity of the RxBus implementation was lost. So I dumbed down the original example but left in the original code for the Rx padawans.

This post has three parts:

1. quick primer on what an event bus is
2. implementing the event bus with RxJava
3. parting thoughts on this approach

“RxBus” is not going to be a library. Implementing an event bus with RxJava is so ridiculously easy that it doesn’t warrant the bloat of an independent library.

Part 1: What is an event bus?

Let’s talk about two concepts that seem similar: the Observer pattern and the Pub-sub pattern.

I’ve read and watched a lot on Rx. Most examples either use the J8 lambda notations/Scala/Groovy or some other awesome language that us Android developers are constantly envious of.

Unfortunately I could never find real-world simple examples in Android that could show me how to use RxJava. To scratch that itch, I created a github repo with a couple of nifty examples using RxJava. You can build the apk and run the app to see different working examples.

Mobile devices are getting pretty fast, but they aren’t infinitely fast yet. If you want your app to be able to do any serious work without affecting the user experience by locking up the interface, you’ll have to resort to running things in parallel. On Android, this is done with “threads”.

Grab yourself a cup of coffee and read this post line by line. I’ll introduce you to the concept of threads, talk about how Java uses threads and explain how “Handlers” in Android help with threading.

This is by far the funniest stuff I’ve read this year. Never fails to crack me up…

There’s something innately comforting about coding. The solution is not known but the variables are fixed. The ambiguities are minimal and the choices are simple. The rule book is adhered to. You mess up and you get bugs, you get it right and a solution is reached. If the solution is good, it becomes poetry.

I realize why management have it tough now. The jargon, documentation, definitions, ambiguity and interpretations that they have to deal with are such a mess.

… You should mention what technologies you are using (because listing WCF or Java will save me the hassle of applying, and you the hassle of rejecting me), but don’t list specific tools, languages and frameworks as requirements.

Good developers who know Rails can learn Django or Node.

Going between Oracle, SQL Server, MySQL and Postgres is all pretty trivial.

… I remember being asked quite eagerly, during a pre-interview, if I knew a specific view engine (like erb, or haml…). Seriously, a view engine!?!? A shitty programmer can learn a new view engine in 10 minutes. Or a more common one that always gets to me is listing some specific version control software. Or a specific library that solves a trivial problem (I see this all the time from the .NET world with DI and mocking frameworks)

Dr.Neil Degrasse Tyson on the Verge:

.. the bulk of the Androids get their time from GPS satellites.. The time keeping bases for the GPS satellites was defined upto 1982 and since 1982, 15 seconds have been added to civil time and that 15s is not included in the Andorid time keeping settings (because their getting their time directly from GPS), whereas the iPhone compensates for this and puts the 15s backs in…

If you’re in the business of hiring programmers, the article linked is a must read. It’s concise and a gold read. No excuse for not reading it.

• Avoid nano-questions
• A good engineer thinks abstractly in terms of designing and building systems, they think in terms of algorithms, components, and engineering design. They do not necessarily know all of the details of syntax of a given language, especially if they are used to a good IDE…
• … it is more important that I be able to tell you when and where I should use inheritance, and when and where I should use polymorphism, than to be able to spit off the definition. ((bolded text my own))
• Basically: Any question that takes 5 seconds to answer with Google is not a good question. My favorite phone interview question? “What’s your favorite language?” followed by “What are it’s weaknesses?”

definitely dated, but interesting yardsticks.

via Hacker News

You’d be surprised how valuable the skill of eloquent communication is even in the field of IT. Keeping users apprised with your progress is perhaps the most important thing to do when working with clients. But keeping them apprised is tricky business and the ability to clearly put down in words,what to expect, is a basic necessity today.

Even if you have nothing to do with CS or computers, you should read the linked article. Fantastic advice.

What you need to know about RAM, memory, CPU Processing and other important stuff that could tell you why your computer is slow.

Physical RAM/Memory

RAM chips funcion quite literally like your Computer’s Memory. All the information that needs to be remembered when operating between different tasks (or even the same task) gets stored here. You know how people who have great memories can be awesome, that translates to the computer world as well, more memory = more awesome. So 8GB » 4GB » 2GB » 1GB » (this is 2011, don’t even consider anything less than 1GB).