1
2
3
4
5
6
7
8
9
10
11
12
13
14

let result;
if (isBar) {
   if (isBaz) {
      result = 'foo truetrue';
   } else {
      result = 'foo truefalse';
   }
} else {
   if (isBaz) {
      result = 'foo falsetrue';
   } else {
      result = 'foo falsefalse';
   }
}

Can be reduced to

1
2
3
4
5
6
7
8

const fooByIsBarIsBaz = {};
fooByIsBarIsBaz[true] = {};
fooByIsBarIsBaz[true][true] = 'foo truetrue';
fooByIsBarIsBaz[true][false] = 'foo truefalse';
fooByIsBarIsBaz[false] = {};
fooByIsBarIsBaz[false][true] = 'foo falsetrue';
fooByIsBarIsBaz[false][false] = 'foo falsefalse';
const result = fooByIsBarIsBaz[isBar][isBaz];

1
2

console.log(fooByIsBarIsBaz); // { false: { false: "foo falsefalse", true: "foo falsetrue" ...
console.log(fooByIsBarIsBaz[true][false]); // foo truefalse

Amazing post about how CPU and memory architecture has changed over the years.

using predictable memory access patterns and operating on chunks of data that are smaller than your CPU cache will get you most of the benefit of modern caches.

• Processor speed has increased much more than memory speed. To work around this CPUs use:
  • Caching - Fast access to frequently used data.
  • Prefetching - Fast access by pre-loading data into the cache if the access pattern is predictable. Example: sequential access of 8 bytes in a loop can achieve 22Gb/sec on 3Ghz processor out of a maximum 24Gb/sec (3Ghz * 8 bytes = 24,000,000,000 bytes/sec).
• Out of order execution - Speculatively execute and re-order executions to avoid stalling on a single resource. Instructions with dependencies will execute in the correct order with respect to one another.
• There are no guarantees that interactions between cores will be ordered unless serializing instructors or memory fences are used.

Post

A heap-based implementation of a min priority queue. I’m not sure why C# doesn’t have priority queues as part of the language.

The Code

I took a crack at creating dashboards using Facebook’s React & Flux libraries.

• It was easy to get something up working and then iterate on it.
• I found the functional concepts they are pushing a refreshing change from messing with jquery. The code looks actually looks like code instead of a tangled rat’s nest of callbacks and dom mutations.
• It’s explicit about how state is stored and mutated. People don’t think enough about this stuff and haveing it front and center is nice.
• The flux pattern is interesting. I like how it separates concerns but it seems like there is a lot of code duplication.
• The idea of updating state and re-rendering reminds me of a game loop.
• I’m not sure how the virtual DOM will perform for larger views but the “native calls are slow” argument makes sense. I’ve had screens with bad jank when lots of Backbone sub-views are re-rendered at the same time.
• The jsx concept of combining template(html) and code is a bit strange but I think they are on to something. With Backbone, you usually end up editing the template/model/view files for most changes so I agree that they aren’t independent concerns.
• I also used Webstorm (support for jsx) for the first time and I’m not sure I can go back to using Visual Studio for JS.

Prototype Code