When we begin working on a problem, one of our main tasks is to build a theory about the problem space so that we can capture and communicate our understanding about it to others and to machines. Given that when we begin building these theories we might know only a few parts of the elephant and not the whole elephant itself, what chance do we stand to discover the whole elephant if our starting point is a few limited perspectives? In this post, I share an example of how to arrive at higher level theories about a domain via bottom up exploration using systematic beta abstraction.
In the movie “The Martian”, Matt Damon plays astronaut Mark Watney who gets stranded on Mars and makes history by practicing open defecation and growing potatoes using his own shit as manure on Martian soil.
ReactJS is gradually moving towards a purely functional style of specifying
application views. In recent versions, you’re encouraged to use a pure
functional syntax that maps a view’s props to the appropriate virtual-dom
components. Combined with Flux, this approach is getting closer to what is
already established in the Elm world, where it is referred to as The Elm
Architecture. This is particularly visible in the increasing
emphasis on working exclusively with
props and avoiding
rendering React components, and piping all inputs and events into the
When Don Norman and Bruce Tognazzini write that Apple is giving design a bad name, you sit up and listen. They write that Apple has thrown away well established design principles and gone for the pretty and snazzy instead.
Recently, I had to work on an animated view for an iOS app. I built the view
using explicit layer-based animations (
CABAsicAnimation and brethren) in a
separate app and it worked fine. Then I moved the view into the host
application and all hell broke loose. After much fighting with the API,
I finally arrived at the techniques needed to ensure that the animations
work as intended irrespective of context. This post collects these notes as
a list of recommendations to follow.
Yesterday, I drove an automatic for the first time. When driving a manual shifter, my brain is on auto pilot - I’m seldom aware of my gear shifts and footwork. When I drove the automatic, all of this suddenly needed to be consciously done. So there was a bit of struggle I experienced with a supposedly simpler system. Bleh! The automatic drive is not intuitive.
Now, wait a minute. We know that folks who shift (ahem!) from automatic to manual face a harder struggle. In the software world, there is a similar hurdle faced by folks shifting between operating systems, and yet we see wars of the kind “my OS is more intuitive than yours”. What do people mean when they say something like that?
These are elaborate notes on a “Tech Tonic” talk given at Pramati Technologies, Chennai, on 23rd July 2015. The organization of this post reflects the talk itself.
The net neutrality debate in India largely lingers on what folks will have to pay for that they’re now getting for free, how much more it is going to cost them to do the same things they’re doing today, what will happen to the small business guys as the large guys take over with money power, etc. Even the (in)venerable AIB does more or less the same pitch in their now famous [Save The Internet][STI] video. There is also [the article on The Hindu][article] pointing out the panel recommendations and they mostly have to do with who and what needs to be paid for and what is to be left untouched.
Much of this money-focused hoohah is a distraction on why net neutrality is important to us. If we don’t adopt a “we won’t touch the internet” policy, there is much more at stake than just a few people making more money than we think they should.