MongoDB Tuning: disable-transparent-hugepages fix

MongoDB Tuning: disable-transparent-hugepages fix for Debian/Ubuntu

Seeing: "WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'."?

Run the following commands to quickly do what MongoDB describes at greater length.

  # Currently just debian
  sudo curl -sSL -o /etc/init.d/disable-transparent-hugepages
  sudo chmod 755 /etc/init.d/disable-transparent-hugepages
  sudo update-rc.d disable-transparent-hugepages defaults


When AI Fails & the Crashing Robotic Cars

Robotic Cars: More accidents (now With Less Injury & Damages!)

Google's self-driving cars are apparently in 2x as many accidents as human drivers - If you think this is just buggy new tech, way too complex from the get-go - well, you're partially right. An important detail I should share: as of Dec 2015 virtually all accidents were not the robots fault.

The accidents are caused by humans drivers unfamiliar with robotic drivers. Furthermore, Google has programmed the cars to obey the law in absolute terms - never speeding, difficulty merging in dense or fast freeway traffic. This opens up a bunch of legal, ethical questions -

  • Is it ever ok:
    • to avoid a rear-end collision if it means driving past the walkway at a red light assuming path is clear ?
    • to drive on the sidewalk to avoid a bicycle cutting across lanes? - is it ok for AI to accept this breach in 'rules of the road'

I understand Google's approach, especially when trying to minimize liability: always follow the rules - logically it follows that you cannot really be at fault if you always observe the law.

There would be massive liability if an accident happened because of intentionally designed 'flexibility' around the laws.

Don't let the future escape us

The future will still arrive, even if the robots drive like octagenarians.

Perhaps a simple fix for now would be to use bright red flashing LEDs (think school buses) to warn human drivers they are about to rear-end an innocent robot.

I would be more comfortable with a car which had tiers of observance and rule adherance. To my mind this would be much closer to how humans drive.

Imagine 3-tiers of system-perception as follows: (decision & other layers omitted for simplicity)

  1. base: follows laws with annoying precision
  2. local: flexibile adjustments based on current traffic - to allow merge on the highway if say, 10MPH+ is needed. Conversely if the traffic is simply going too fast, the car should be smart enough to pull over to avoid being a nuissance to other drivers.
  3. 360: calculate ANY potential extreme collision risk/avoidance measures - driving on a shoulder or

This would likely require a smart balancing act - say tier 1 detects an immenent accident which cannot be avoided following the laws, it would then shift all processor power into tier 3 - hopefully finding a creative way to avoid harm.

Robotic cars are on the cusp of being technically smarter & faster than any human driver. Accept it. Welcome it.


Higher Order Programming

Work-in-progress (updated Dec. 2015)

Array- or Set-based Coding Style

An Anti-Pattern?

This is an exploration of advantages gained when you code most things as an array. (Using Jedi concepts from SmallTalk)

Here's some guiding principles:

  1. All input is array-like. Even if an array of 1.
  2. Functions should generally accept AND return arrays.
  3. 9 out of 10 examples of corporate code suffers from what I call schema surplusage - unmitigated table + field proliferation.
  4. Yes, beware fat ASS models - with all the predictable trappings: most of the issue here is fragile instance state - often the result of having so many features, levers and knobs to be aware of: partitioned classes, scoping, locks, async/mutexing, using idiomatic patterns, familiar?

  5. So let me take a common problem and shoehorn ~~~add~~~ some set-based musings.

    1. Why is a Property price always a single data point? Why would I make price(s) an Array?
    2. Let's add this functionality: a. New requirements: ListPrice, PriceSavings
  6. These changes hopefully look no worse than my sorry attempt:


public class Property {
  public String Name;
  public float Price;
  public float ListPrice;
  public float PriceSavings;

  public Property(String name, float price) {
    this.Name = name;
    this.Price = price;
    this.ListPrice = price;
    this.PriceSavings = 0.0f;

  public float getPriceSavings() {
    return this.ListPrice * this.PriceSavings;


  1. I'm not sure about you, but the price of just about anything is in flux over time.
  2. Let's say we need to support the following app:
    • Directory of Real Estate Properties
      1. Support price changes
      2. Calulate Price savings compared to original price
      3. Calulate Price savings compared to previous price change
      4. Support comparing price changes vs. # hits
  3. To support this kind of feature set one might implement any number of solutions: perhaps adding additional fields to the class, or adding a SQL table tracking price changes, etc... I propose a more flexible solution every language supports: treat the field price as an array.
  4. It may seem silly or too limited at first, but you can get so much mileage switching from singular variables to sets - let's say Property class includes int price = 125000 - change it to int prices = [50, 100, 125].
  5. Bear with me. That is not likely the final re-factor on that...

Work-in-progress (updated Dec. 2015)

// forgive me, es6 for brevity:
function Property({name='widget', prices=[]}) {


Beautiful Models (and Data)

Work-in-progress (updated Dec. 2015)

The issue we'll examine is deceptively simple & subtle: Naming

I want to avoid my usualt exuberance for super-fancy-tech-lingo on this article; hopefully I can illustrate the issue in a more useful fashion.

While covered in exhausting detail before, the subject matter often gets too technical for the novice programmer to draw any practical understanding. You probably don't need to read this if the following makes sense: No-Sql denormalization strategy, or Boyce Codd Normal Forms

Recommended reading includes:

  1. Book: Code Complete

The Problem - by Example

Have you ever designed a data model (in code, Sql, or excel worksheets)? Does the following look familiar?

*** anti-pattern - don't copy-paste ***
* User
  - id
  - avatarUrl
  - email
  - passwordHash

* Agent
  - id
  - primaryPhoto
  - agentName
  - agentEmail
  - agentPhoneMain
  - agentEmailPrimary
  - agentPhonePrimary
  - agentAddressLine1
  - agentCompanyName
  - agentCompanyAddress
  - *userEmail* - 'Pointer' to User table ^^^

If this is familiar to you, I'll bet you:

  1. Feel any change to your app will necessitate hours of arduous debugging.
  2. Fear ANY Changing Requirements schema refactor

The Cost of Bad (Naming) Habits

Let's examine some of the subtle issues (probably familiar):


Why is naming a field agentEmailPrimary the worst?

For starters, you are not creating an entirely new object unto the universe. Over-specificity has some traps:

  1. 'Locked' into highly specific name, means agentEmailPrimary probably make your views and related code 0% reusable, and featuring annoyingly recurring bugs like:
    • Data not syncing between tables (not obvious if needs to propagate to agent.agentEmail or vice-versa - nevermind complexity of manually implementing where & how to enforce this 'logic' ...)
    • Validation rules/logic are likely duplicated & inconsitent.
    • Increasingly, your project will resemble a shaky Jenga tower.
    • Fragility piles up with every single new file, as an extremely high attention to detail is required for even trivial changes

I know, you probably feel something like...

fuck this

A Solution

// Dan's Recommended Schema Consolidation:

  - id
  - role: ['agent', 'lead', 'admin']
  - name
  - phone
  - address
  - email
  - passwordHash
  - company
    - name
    - address

I removed the Agent table, as it didn't contain fields which were uniquely related to Agents.

All changes were made with these general ideas in mind:

  1. Eliminate unessesary tables. If you have a few dozen tables, this step is mandatory.
    1. Try merge related tables. Important if you are coming from a SQL background to No-SQL
    2. Delete redundant data collection (e.g. remove ActivityLogs table if replaced by Google Analytics)
  2. Try keeping all field names to a single word/noun/pro-noun.
    1. There is no such thing as Agent.agentEmail or Agent.agentPhonePrimary. Period.
    2. By using Highly Specific Names, you cast-in-stone a specific level of code-reusability and durability, well, specifically ZERO %.
    3. Don't think you are doing yourself any favors with crap like this User.profileSummaryEmail (where 'profile' could include contact details for a personal ads site) . This is probably a good point to create a new table, say Profiles which includes

Work-in-progress (updated Sep. 2015)

AngularJS v2.0 and the Impending Schism

I think we are witnessing the Python 2->3 'Conversion' all over again. AngularJS v2.0 introduces too many changes. Not least of which is TypeScript, which is a big ask amidst the finalization of JS's latest version: ES6.

Let me say clearly: I love TypeScript. I seccretly wish the TC-39 meetings had produced it... They didn't. However, They came up with another (totally different), also-awesome spec...

While TypeScript compiles to JavaScript, it doesn't mean you blindly copy & paste 'compiled' TypeScript. It effectively becomes required learning, as to understand annotated AngularJS 2.0 TypeScript.

Now, newbies must climb 'Mount TypeScript' before they can even start assembling an Angular app (with some level of understanding).

I have a feeling how this might go...

endless loop

Oh well, I'll add it to the Newbie training list: somewhere between Basic Shell Usage and Gulp or Grunt? Godsend+Misery!

Anyway, I hope this works out...

everything is going to be ok