No vertical align with display:table-cell

I got everything to work in most browsers, but not always in IE11. Apparently, IE 11 ignores width/height inside display:table-cell.

The solution that almost worked, see CodePen. It works in Chrome (left), IE10(middle), but NOT in IE11(right)

Screen Shot 2014-05-12 at 4.56.22 PM

<div class="container">
 <div class="cell">
 <img src=""/>

.container {
display: table;
table-layout: fixed; /*crucial for IE*/
border: 1px solid black;
.cell {
display: table-cell;
vertical-align: middle;

img {
max-width: 100%;
max-height: 100%;
margin: auto;


How to speed up page load?

A very common interview question and a really good video is here:

An interesting way to look at the question:

To understand how absurd this question is – for fast pages, what is the right number of requests and optimal page size, Paul posed another similar question – for good health, what is the right number of meals and optimal pounds per meal to eat?

The answer is – not all requests are equal, not all bytes are equal.



Docker on Mac

Trying to set up Docker on Mac, and it seems like Vagrant is a good option.

Some Docker-friendly Vagrant base boxes are listed here:

Step zero:
install Vagrant and Virtualbox

Step one:

vagrant init phusion/ubuntu-12.04-amd64

Step two:
Modify the vagrant file. Pay attention to the network settings:

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
 # Every Vagrant virtual environment requires a box to build off of. = "phusion/ubuntu-12.04-amd64"

 # Create a private network, which allows host-only access to the machine
 # using a specific IP. "private_network", ip: ""

 # Share an additional folder to the guest VM. The first argument is
 # the path on the host to the actual folder. The second argument is
 # the path on the guest to mount the folder. And the optional third
 # argument is a set of non-required options.
 config.vm.synced_folder "../srv", "/vagrant_srv"


Step three, run this to install docker:

wget -q -O - | apt-key add -;
echo deb docker main > /etc/apt/sources.list.d/docker.list;
apt-get update -qq; apt-get install -q -y --force-yes lxc-docker; 

I am using private network from vagrant so that all ports are automatically forwarded so that you can visit however you want

View story at


Thoughts on React

React is the next big thing…

No I am just kidding…

It is a great idea and is way smaller than Angular. However, after sometime, I feel like it was designed to present data, not editing data. It is extremely painful to change a deeply nested component, and ask the root component to respond to it.

Here are some interesting ideas on how to solve the problem.

One is with event bus. Coming from Backbone, I almost don’t know what to do when I don’t have any event bus…

This is exactly the problem we’ve been running into building a medium sized interactive app in React. The management of data flow and state changes through the component hierarchy with callbacks can get quite complex, and you end up writing lots of callback boilerplate. So we’ve ended up rolling an event system that sits alongside the React components, and a lot of our app’s interactivity is managed through the event system.” quoted from this url:

The other is with callbacks from the child component to its parent. This might be the recommended way from the React team, but I don’t like it because you quickly accumulate so many boilerplate code …

I think this is the most underdocumented part of React right now. The suggested way to communicate between components is to simply set props when communicating from parent to child and to pass callbacks through props when communicating from child to parent.” quoted from this url:

The third one is this thing called the flux system architecture , which I don’t quite understand. It seems to be the same as the event bus system, but I am not 100% sure.

It works well with React because the objects are passed directly into React views for consumption, where they cannot be modified by the views themselves. When a view wants to change a piece of data, (perhaps based on user input), the view informs the store that something has changed, which will validate the input and then propagate the change out to the rest of the application. In this way, you never worry about incremental state mutation, or incremental updates, and every change that happens to the system (whether it comes from user input, an ajax response from the server, or anything else) goes through the exact same flow (which handles validation, batching, persisting, etc).

We think of Flux as complementary to React. When you build your views in React, something needs to track the data and interact with the server (fetching more data or performing writes). Flux prescribes how to structure those pieces in a way that makes it easy to reason about the data flow, even when the application needs are inherently complicated.
As one example, we’ve found that using models tends to push application logic into the view layer, rather than keeping it close to the data layer. With centralized stores, all changes are expressed by the view as the intent to take an action. A payload sent to the stores could indicate that the user wants to mark a message as read. The stores then internally make all the changes that the action implies – marking the message as read and decrementing the unread count on the thread – rather than making the view know about that bookkeeping.
Moving this application logic into the central store layer makes it more testable, and it becomes easier to refactor the internal representation without breaking existing views. We also get a nice separation of concerns between the views and the data layer, something that React already encourages.”

An example with flux can be found here: