Chris Arriola

Musings from an active observer.

Deep Work


“What should I do next to get better at X?”


Practice… right?


When I was in college, I followed a blog by Cal Newport called “Study Hacks”. If you haven’t heard of it yet, I highly encourage you to check it out. It changed a lot of my perspectives and some of the lessons I learned I still practice today. Check it out here.

As I was thinking about the question above, I thought of a topic discussed on Study Hacks called Deep Work.

Deep work, according to Cal, is the type of work that causes our abilities to continually improve. It is a source of deeper satisfaction; that is, a feeling of passion towards whatever it is we’re pursuing. In contrast, so called shallow work are the types of tasks that require minimal amount of effort. These are the tasks that through repetition and training we’re able to do with our eyes closed.

Figuratively, of course.

The answer to the question I posed to myself requires some amount of deep work. With that said, here’s how I go about preparing myself for some deep work:

  1. Quiet time

    The simple act of turning off all my devices and “unplugging” myself unleashes tons of creative juices. Distractions from tweets, likes, +1s, e-mails, etc. make it hard to get into any sort of rhythm. Once unplugged, I find that I don’t really need to think of anything at all – ideas just start flowing.

    Ironically, some of my most creative moments are in the plane when I’m bored out of my mind. Who said boredom was a bad thing??

  2. Plan for tomorrow

    I have trouble maintaining a very rigid routine/schedule. However, it’s incredibly easy to plan for the next day. I find that if I just jot down a few reasonable and achievable tasks for myself to do the next day, my mind has time to prepare for what’s ahead. Surprisingly, this motivates me to wake up early the following day too.

  3. Be in the now.

    The most important part about execution of deep work is to be in the moment. You just need to pay attention to what you’re doing. To “pay attention” is such a great sentiment in this context as it reminds us that attention costs something… energy.

How do you prepare yourself for deep work?


Blog Migration

Just moved my blog from a wordpress.com site to Octopress hosted on GitHub. Surprisingly, the set-up was really quick including migrating all of my posts and tweaking some colors from the theme I chose. Not everything went smoothly though; I lost all of my comments and images on posts had some formatting issues. Aside from that, it only took a few hours.

Feel free to leave a comment for any suggestions!



Preparing for a Hackathon (A Mobile Perspective)

Image

The time-pressure imposed at hackathons make it essential for teams to prepare ahead of time so that they can focus on the most critical tasks (building the actual product) the day of the event. Typically though, hackers come in without a team or idea. Whether you fall under this category or not, preparation is still important. Given that a full-blown business and a polished working product is unlikely to be built overnight, the point of a hackathon should be to learn as much as you can as well as form long-lasting relationships with people in your team—the burning desire for building and creating new things does not stop after a weekend!

Let’s say you do have a team and an idea to work on over the course of a sleep-deprived weekend. So where should you start? I thought I’d share some mobile-specific (Android and iOS) tools and projects you can leverage to bootstrap the development process.

Back-end

If you want to do data-persistence you can always build your own server logic, create RESTful APIs and create database schemas, but if you want a simple back-end service solution, the best option right now is to use Parse. Parse allows you to create models in a nice visual dashboard and then automatically creates a RESTful API for you to do CRUD operations on that model. Best of all, Parse is free until you hit a million requests on the API which is something you don’t have to worry about in a hackathon setting. In short, if you’re building a mobile app and you don’t have a dedicated server guy, go with Parse.

Networking

If you’re going to be integrating with some sort of web service (Facebook, Twitter, etc.), chances are, you’ll be using their APIs. Perhaps you might build your own API. Regardless, client-side you’ll need a pretty solid networking library to use. iOS and Android have their native implementations but you’ll be better of using a 3rd party library with a much simpler API that abstracts all the nitty-gritty details of HTTP. For iOS, AFNetworking and RestKit (uses AFNetworking) are the common solutions, whereas for Android, you have a couple of options but to name a few OkHTTP, Retrofit and android-async-http are pretty solid.

Convenience Libraries

Do you make common mistakes on Android such as forgetting to check for null? Do you have the issue of stale objects such as Fragments and/or Activities when doing callbacks? A couple of ways to get around that is to use Guava which has a lot of convenience classes that for Java, and to use some sort of event bus such as Square’s Otto to avoid callback nightmare.

Hopefully these tools help you with your next Hackathon. If you have any suggestions/tips please feel free to leave a comment. Keep hacking!


Android Security Part 1 - Reverse Engineering Android Apps

Google introduced automatic support for ProGuard, a code obfuscation tool, in ADT as early as December 2010 in version 8.0.0. It is integrated into the build system to make code obfuscation a pretty “straightforward” process. Since then, Google has encouraged—albeit not proactively—developers to enable ProGuard to prevent hackers from reverse engineering and hacking applications. Despite enabling ProGuard, however, a very persistent hacker may still be able to reverse engineer a ProGuard-ed application but the task becomes exponentially harder. There are other good practices developers should abide by to ensure a secure app, but code obfuscation should always be the first line of defense (more information on code obfuscation on Android here and here). Out of curiosity, I went ahead and did some reverse engineering on some popular apps (all have more than 1 million downloads on Google Play) that may contain user sensitive information and un/surprisingly, 10 out of 12 weren’t doing some sort of code obfuscation. I’m sharing in this post what and how I did that to point out 2 things: (1) how easy it is to reverse engineer an app, and (2) to increase awareness of the importance of security specifically code obfuscation.

Methodology

My methodology was simple, in fact, a quick Google Search on ”Android Hacking” should give anyone the tools to do this. Below are the steps:
  1. Obtain the .apk files of the applications of interest by using Astro File Manager. Simply navigate to “tools” in the options menu, “Application Backup”, and then select all the apps you’re interested in. Once backup is perform, an image is obtained of the apps and the corresponding .apk files will be stored under your SD card’s backups/ directory.
  2. Unpack .apk file using unzip.
  3. Disassemble compiled classes.dex file using baksmali. This will generate tons of .smali files.
  4. Perform static analysis on .smali files.
For step 4, if an application does not have code obfuscation, then all static constant declarations can be read in plain text (red flag!). You can still take things a step further, for instance, by writing smali code and retracing your steps to create your own custom hacked-out app.

Results

Understanding smali code is pretty straightforward event without prior knowledge of the language especially when it comes to finding static member fields. Declared String values are human-readable. Here are a few screen-shots of what I’ve found:
Fig. 1 Fig. 2 Fig. 3 Fig. 4

Conclusion

ProGuard creates drastic improvements in security. Here’s an example of how smali code would look like with ProGuard on vs. with ProGuard off. Say your Activity has a static member field HACK_THIS:
Fig. 5
When we disassemble the resulting .dex file without ProGuard enabled, we get this: Fig. 6
Whereas code obfuscation using ProGuard results in:
From this comparison, you can observe the following: enabling ProGuard in this situation removes the human-readable static member field whereas disabling it leaves it in plain-text in smali assembly code. Although the content of the String gets copied wherever it is used in code as seen on line 39 in Figure 7, the context of what that String represents is virtually unknown. Again, a persistent hacker may deduce what that means through brute-force, but ProGuard increases the complexity of the task. ##### Any tips on how to create a secure Android app? Leave a comment below!


Dynamic Data with ListView + Loading Footer

A pretty common UI design pattern for  ListViews on Android is displaying a loading footer for the dynamic loading of a list. It’s a pattern used by several well known apps - Twitter, Gmail and Instagram to mention a few - to display data without having to click a button to paginate through information. Essentially, as a user scrolls down to the end of a list, which indicates the end of the current page, a loading indicator is displayed at the footer of the list to notify the user that the list is in the process of populating more data. [caption id=”attachment_389” align=”aligncenter” width=”510”] Dynamic Loading of a List (http://www.androidpatterns.com/uap_pattern/dynamic-loading-of-a-list)[/caption] While playing around with this pattern, I was quite surprise how not-so-straightforward it was to implement this (then again, that’s programming for you). With that said, I’d like to share my implementation with you in case you’re trying to use this pattern in your application.

Trial 1

The intuitive way to go about this is to (1) simply attach an Adapter with the first page of items to a ListView, (2) attach an OnScrollListener to detect if the bottom of the list has been reached, if so, (3) add a loading footer view to the list while retrieving more data, and when the retrieval process is done, remove the loading footer and (4) update the adapter with the recently pulled data. Sounds pretty straightforward right? Turns out, it’s not. Here’s some code snippets of the above approach. (1) & (2)
ListView list = (ListView) findViewById(R.id.listview);
MyAdapter adapter = new MyAdapter(context, items);
list.setAdapter(adapter);

list.setOnScrollListener(new OnScrollListener() {
    @Override
    public void onScrollStateChanged(AbsListView view, 
            int scrollState) {
         // Do nothing
    }

    @Override
    public void onScroll(AbsListView view, int firstVisibleItem, 
            int visibleItemCount, int totalItemCount) {

        // threshold being indicator if bottom of list is hit
        if (firstVisibleItem = threshold) {
            pullMoreData();
        }
    }
});
(3) & (4)
private void pullMoreData() {
    doNetworkRequest(page); // Perform request for next page
    list.addFooterView(loadingFooter);
}

@Override
public void onNetworkRequestComplete(Request request) {
    list.removeFooterView(loadingFooter);
    adapter.addAll(request.getData());
    adapter.notifyDataSetChanged();
}
This implementation, however, does not result in the intended action - the footer never gets displayed. A work-around I did for this leads me to…

Trial 2

With my second trial, I did this: (1) attached the footer first before the adapter, and when the bottom of the list has been reached and new data has been retrieved, (2) reattach the footer and create a new adapter with the old+new data which is then reattached to the list. Finally, to bring the user back to the scroll position, I (3) keep track of the first visible item on the scroll view and set the list selection to be this item. Immediately, a few things must be popping up in your head such as: that must be slow! it’s a hack! there has to be a cleaner way! etc. I can’t agree with you more. (1), (2) & (3)
ListView list = (ListView) findViewById(R.id.listview);
list.addFooterView(loadingFooter);

MyAdapter adapter = new MyAdapter(context, items);
list.setAdapter(adapter);

list.setOnScrollListener(new OnScrollListener() {
    @Override
    public void onScrollStateChanged(AbsListView view, 
            int scrollState) {
         // Do nothing
    }

    @Override
    public void onScroll(AbsListView view, int firstVisibleItem, 
            int visibleItemCount, int totalItemCount) {

 // member variable for restoring selection
        mSelection = firstVisibleItem;

 // threshold being indicator if bottom of list is hit
        if (firstVisibleItem = threshold) {
            pullMoreData();
        }
    }
});

@Override
public void onNetworkRequestComplete(Request request) {
    list.removeFooterView(loadingFooter);
    list.addFooterView(loadingFooter);

    MyAdapter newAdapter = new MyAdapter(this);
    newAdapter.addOldData(adapter);
    newAdapter.addAll(request.getData());

    list.setAdapter(newAdapter);
    adapter = newAdapter;

 // Set table to last selection
    list.setSelection(mSelection)
}
Albeit some performance issues and jerkiness because of (3), this implementation actually works. Can we do better than this?

Trial 3

The trick, it turns out, is to attach the footer view before setting the adapter, this way, any combination of adding and removing of the footer view/s just works. Why does it have to be in order!? If you have the answer, please leave a comment. I’d love to know
ListView list = (ListView) findViewById(R.id.listview);
list.addFooterView(loadingFooter);

MyAdapter adapter = new MyAdapter(context, items);
list.setAdapter(adapter);

// this step is important to not display the footer view // right of the bat.
list.removeFooterView(loadingFooter);

list.setOnScrollListener(new OnScrollListener() {
    @Override
    public void onScrollStateChanged(AbsListView view, 
            int scrollState) {
 // Do nothing
    }

    @Override
    public void onScroll(AbsListView view, int firstVisibleItem, 
            int visibleItemCount, int totalItemCount) {
 // threshold being indicator if bottom of list is hit
        if (firstVisibleItem = threshold) {
            pullMoreData();
        }
    }
});
I’ll share more Android quirks as they come up, I hope this helped.

Too Many to One - Implementing mHealth

For about a year and a half now, I’ve been volunteering with Global HEED—a non-profit organization focused on supporting health, education, and economic development globally. Global HEED was started in 2008 by founders Sonny Bandyopadhyay and Zain Ahmed while both pursuing their degrees at the University of Emory. Over the course of 5 years, Global HEED has made a tremendous impact in communities around the world, most notably, in a small village in Guatemala called Calhuitz. Medical students enroll to become a summer fellow wherein they will be responsible for any of the following: developing & teaching public health topics, assessing the communities needs, shadowing/assisting a doctor or nurse, etc. Some of the projects in the past involved building a pharmacy, a community health worker training center, and even first community health clinic in Calhuitz. The newest project within Global HEED is the mHealth initiative—a telemedicine project whose goal is to improve the quality of healthcare in under-served communities. Specifically, we’re collaborating with Partners for Care, an NGO based in Kenya, to implement mHealth in the slums of Nairobi by utilizing Sana Mobile.

Problem

The underlying problem is this: there are too many people in need of healthcare but there aren’t enough physicians that can support that need. As a result, not everyone gets treated; in addition, taking into account waiting and travel time, visiting a clinic or hospital can be very time consuming. In some instances, patients have to travel ~10 km by foot to pay a visit to the nearest clinic. It’s a very brutal experience as you might imagine.

Proposed Solution

To alleviate this, we implemented Sana as essentially a triaging tool to improve  the delivery and efficiency of healthcare. It works as follows: a community health worker visits a patient and enters the necessary information through the mobile device (patient information, symptoms, photos, etc.), the information is then sent to an electronic medical record system, OpenMRS, wherein a remote doctor can send a diagnosis back to the community health worker who would then perform the necessary action (more on this here). Although the entire process seems simple, there’s still a couple of BIG obstacles to go through before we can comfortably expand into other regions. To name a few, we need to verify uploading information to the EMR works 99% of the time, that patient data is consistent with what’s recorded, that the community generally accepts the technology, that the project can be evaluated in a metric and quantifiable way… thinking about all this is giving me a headache.

Conclusion

Despite all these obstacles, seeing the passion within the organization itself, that is Global HEED, gives me the confidence that these “minor” obstacles can be eventually surpassed. For instance, even though members of Global HEED are from all over the nation—Atlanta, San Francisco, and New York City to name a few—we somehow still manage to consistently collaborate and work towards the same goal thanks to the very passionate leaders within the organization. Not to mention, our use of technology for communication, which enables us to connect, should be a testament to the potential of technology for improving the lives of those around us; not just for those a few houses away, but also for those on the opposite side of the globe.
We who work in technology have nurtured an especially rare gift: the opportunity to effect change at an unprecedented scale and rate. Technology, community, and capitalism combine to make Silicon Valley the potential epicenter of vast positive change. We can tackle the world’s biggest problems and take on bold missions like fixing education, re-imagining energy distribution, connecting people, or even democratizing democracy. And with increasingly severe threats to our survival — rapid climate change, an unstable international economy, and unsustainable energy consumption — it is more important than ever that we use these gifts to change the world, foster happiness and alleviate suffering, for us and our fellow beings. by Justin Rosentein
##### If you’re a developer and would like to contribute to the project, please feel free to reach out! You can also just jump and start pushing code into the Sana source code repository, it’s open source.


Optimizing Android Layouts

I recently used the hierarchyviewer & lint tool in the Android SDK and was pretty surprised with the results I saw. Many of the views I had were heavily nested and some views did not necessarily have to be inflated off the bat (progress indicators and refresh icons to name a few). As a result, my activity took a performance hit because of a badly designed layout. Here’s a technique I used that I picked up at AnDevCon III to flatten my layouts and in general make them more performant.

ViewStub

Essentially, ViewStub is a lightweight and cheap to inflate widget that you can include in a layout. Its purpose is basically to serve as a stub or placeholder for views that don’t necessarily need to be inflated on creation. For example, let’s say your app displays notifications on a SlidingDrawer; however, when there are no notifications, that SlidingDrawer should be hidden. What you can do then is create a ViewStub that points to your SlidingDrawer layout implementation and when notifications are present, you can simply inflate the ViewStub. Here’s an example taken from Android Developers that displays the flattening of the view hierarchy using ViewStubs. Layout without ViewStub: [caption id=”attachment_341” align=”aligncenter” width=”510”] Layout Without ViewStub[/caption] Layout using ViewStub: [caption id=”attachment_342” align=”aligncenter” width=”468”] Layout With ViewStub[/caption] The code for your layout:
<ViewStub
android:id="@+id/stub_slidingdrawer"
android:layout="@layout/slidingdrawer"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
/>
The code to inflate the ViewStub:
ViewStub stub = (ViewStub) findViewById(R.id.stub_slidingdrawer); View v = stub.inflate(); 
For my specific case, it took about half the time to inflate the entire layout tree by using a ViewStub for infrequently used child layouts. Pretty sweet.