Inbreeding and evolution

Following a thread with my kids about the fragility of the human body
- I was telling them "imagine having a pet so fragile, that as it walks, it may slip, fall, break its head and die. Thats how humans are. Walking accidents, top heavy, too much guts and brains, too little muscle mass and bone mass to keep things together. Imagine a dipod, like a chicken falling as it walks and injuring itself.
To accentate the difference I pointed out to felines like chetah that while running at 70mph lounge to their prey, bringing it down to the ground - something equivalent of jumping off a car at highway speeds - and doing that multiple times daily.

My smart-alecky kids, instead of being impressed from my points they jumped to tell me I am wrong and that cheetahs are not that fast (todays kids have grown with animal planet and know pretty well the largest, fastest,deadliest,smartest of any sort of thing) . Defending my speed claims I arrived at the cheetah wikipedia page (I was off by a bit, cheetah go up to 100-110km per hr, and they are an extreme case) where I was attracted to the following comment (and abandoned the not as satisfying discussion with my kids):
The cheetah has unusually low genetic variability. This is accompanied by a very low sperm count, motility, and deformed flagella.
That seemed interesting. Reading further the article went on to explain that this was caused due to a recent genetic bottleneck.
It is thought that the species went through a prolonged period of inbreeding following a genetic bottleneck during the last ice age.
What changed my view from interest to annoyance was that comment though:
It has been suggested that the low genetic diversity of cheetahs is a cause of poor sperm, birth defects, cramped teeth, curled tails, and bent limbs. Some biologists even believe that they are too inbred to flourish as a species.^[45] Note, however, that they lost most of their genetic diversity thousands of years ago (see the beginning of this article), and yet seem to have only been in decline in the last century or so, suggesting factors other than genetics are mainly responsible.
See, my simple way to explain most of evolution effects to my kids, why I have black eyes, why my hair is thick and black why skin is this or that why swedish people are blond but Eskimos are dark haired, why our nose is less pointy than the chimps and the chimps nose is less pointy than other animals etc etc... all that includes a continuing combination of using
 - fatal disadvantages
 - strong advantages
to explain how a some particular member (or group) of a species was able to reach a certain level of environmental dominance/monopoply which often implies that this member will become a new Abraam patriarch/matriarch and explode its genetic tree - with most of the descendants carry the unique genetic characterists of nose, hair etc.

Its a relatively simplistic way to explain things - given the more incremental nature of genetic change ... still I think this model of explaining evolution is a very good one:
Where evolution happens the fastest when a relatively small sample of a species find itself owning a slice of the environment/geography , either due
 - they were able to move to a new place due to their small incremental advantage
 - they were they only ones to survive to the new place due to their incremental advantage
 (new place - may be the old place + some new environmental change (draught, flood, new disease, newfound prey, newfound enemies, newfound resources))
and then genetically explodes to fill the "new place" until it reaches some sort of equilibrium.
The smaller the group that survives, the biggest is the genetic bottlneck(and following inbreeding) and then the big is the change that happens as a result.

Of course human morals are seeing inbreeding as synonymous to incest and thus wrong/bad.
Somehow that same morality made it all the way to scientific analysis  and became a meaningful explanation -
 - this species is too much inbred thats why it wont survive
 - those species parents doesn't love/care for their offsprings that why it doesn't as well
 - that species is cannibalistic, it kills and eats its own ..... why should we even put it in the endangered list if it does that to its own.

I get annoyed just writing it.

Maps and visualizations

I found this at HN a couple weeks ago

http://twistedsifter.com/2013/08/maps-that-will-help-you-make-sense-of-the-world/

Apparently most of these come from a reddit  http://www.reddit.com/r/MapPorn/ . Some of the maps can be good topics for dinner discussions.. its a definitely intriguing list.

On the visualization topic, I really want to find a reason to play with D3.js ....

Marketing your node module - darker patterns

I am capturing here a few ideas that I've had recently in the same topic as in the last post .

I realize that the ideas become more and more extreme/desperate/dark still I felt that there is nothing wrong in capturing them.

At the high level the idea here is that you want to increase the "page rank" of your module.

Soon that pagerank will be a combination of

- the recent/all time downloads # as published by npm

- the page rank of the author (some aggregate of the pagerank of all the modules authored by the person)

- the github stars/forks accumulated by that module's repo

- the aggregate follows/starrs etc accumulated by that repo's owner

As a result improving the page rank of the module implies that you will somehow get these # s up - which is not obvious when nobody yet knows your module.

So here are a few things that you can do to speed up the process

Increasing Download counts

- Make sure that *you* use the new modules. You or your friends may have some modules that have daily downloads. You should see if it is possibly to refactor any of your existing modules (particular ones with high download counts) to make use of your module. If you achieve that any download of the former will result in downloads of the later!. This also means that as soon as you have one success you can easily build up on it... 

- Look at all the competing/alternative modules - find which modules/apps are using it. If you can make a case that your module can do a better job at it... than go ahead file an issue pull request doing the change (replacing one module with the other) and explaining that by doing so you are improving the functionality etc etc. The odds are that,  assuming your module is actually better,  the user of the alternative doesn't care whose module to use - he just cares to improve his own functionality and doing so with minimal personal effort.  Again here you should focus on cases where the target module has significant traffic

- Your employer may be a great resource. Most employers don't publish their code. However, they have teams of developers continuously commiting => firing continuous integration systems which do continously pull dependencies and rebuild stuff. Ie even private reposititories contribute to "download counts" and you definitely know at least one big such example - the repos of your employer. Finding how/where your opensource module can be used in your employer's repo is a very easy way to build up download count.

Increasing your module stars.

- Get people with lots of followers to star your module. The idea here is that if someone with lots of followers stars your repo... that goes into the newsfeed of all their followers . I typically find out about interesting new modules this way by looking what other people star...  Of course then the next question is and how do you get these guys to notice you?  The answer: the hard way. You need to closely keep an eye on their interests - where they put their time/commits - and knowing that may give you an idea about how you can help them . It might take more than one indirection - you see something that they do - you write some code/a PR for them - so as they know you / build up some credit - so when the time that they use something that you have a better version of... you are ready to offer your alternative - and if you persuade them to use your in your current project - they might be ok if you PR to replace the module in all prior modules they might have written depending on it.

- if you manage with all the above efforts to get someone to visit your module - your primary goals is not to star it - but to extend his page-count visit. Essentially think that you just bought an expensively aquired visitor and you want to get most of them. They came following a link towards a specific module but they actually may look around. You need to be prepared for that:

  + Your public repo should have only your jewels - it should not have every single repo you have ever written. This is very important - both because if you get followers you want them to checkout whatever you are creating and because a user with lots of crappy repos is just like a blogger with lots of crappy blog posts - nobody has the patience to go through the crap to find the jewel. So what you need to do is create a separate github account and move there anything thats is not yet publish-grade. This will also help you with the problem that the very first github push of a repo - will invite your followers to visit it - they should better see it in its full glory with the polished readme etc...

  + Your readme should have something provocative/novel in how it presents itself - "badges" (like travis)  that others don't use - interesting clip art, an animated gif that shows a terminal running the module etc

  + Your readme should point if possible to other modules of yours.

  + You should make sure that you have your links to your blog/homepage etc in your github account... again making sure that you appear as a guy that talks rarely but is worthwhile listen to when he does.  Exactly the opposite of me in this blog.....
  + Add a gitcomment thingy (what is a gitcomment will be captured in a future post) at the bottom of your project's readme - seeded with some comments from your friends.

Marketing your node module

Continuing the thoughts in the last post  I am finding a bitmore about the steps that you need to do to market your blog

I just tried to find a module that provide google spreadsheet editing capability..
When I type google spreadsheet in the npm search
npm find one module google-spreadsheet (right in the first rows) but the probably better module (comparable downloads, comparable github stars, include the exact string "google spreadsheet" in the description, include google and spreadsheet in the keywords) named google-spreadsheets is in the 3rd page after several completely unrelated to "spreadsheet" matches (somehow it seems that npm shows in the search even modules that don't match all my keywords.
Now this says something about the poor state of affairs in the node module search-land.
Looking at stackoverflow in case I am the last person that is not using someting cooler and better to find node modules... I found this post . which lead me to two more useful places (and a couple more broken links). A github wiki page that includes lots of modules - https://github.com/joyent/node/wiki/modules,
(unfortunately I didn't find any of the "google spreadsheet" modules I was looking for there which shows that while long this list can have significant gaps...) plus sth that went pretty close to what I was looking - nipster - a search tool that combines the github stars and a bit better (still lousy if you read the open issue) search.

Anyway, after logging in my todo "NIDEA - better npm module search" I concluded that until then one should definitely include in the "marketing steps" the following
 - add module in joyent module list page
 - make searches in npm to see if your module shows up - if not tinker with description, keywords etc until it does
 - look for your competition - other modules that show up on search - include in the description something that would make your module more attractive than them - its the only line that shows from your module in the search listing
 - look for what keywords your "competitor" modules are using - add them too - npm doesn't use any advanced matching that would decrease the weight of the keywords if there are many - so the more the merier.
 - confirm that your module shows up correctly in nipster search
 - pleade your gh friends to star it
 - make sure that you push in github with travis-ci any module/app that is using your module - for a while you will be the only user of your module and travis npm installs do count against the download counts that npm shows - which are the only signs of life when someone searches for your module.

Writing reusable modules vs deployable services

We were discussing this with gl and we realized that the differences (like in the past.. ) between writing code that becomes an open source node module vs writing code that is part of a deployable (web service/web app or even executable) are even fewer.

In reality it seems to me that you always need to think that you "deploy" your code
 0. npm version major to 1.0 from 0.xx
 1. fix up the readme
 2. add keywords to package.json to allow searches to find you
 3. possibly add command line executables, man page in your npm
 4. possibly add a drawing the way substack does
 5. post the link/readme of the module to your blog/twiter
 6. go through the places that you search to find a module (and when you didn'y you ended up builting it) and let them know you did (github issue comments, stack overflows, node mailing list
 7. (there are probably sites that are have some "new/cool modules… where it may be worth to submit your module to…)
--
Of course when you are substack.. all you need to do is add the module as public repo and your followers all find it… but even then he still does the 1..5.

It is also interesting that you rarely have a module that doesn't have a natural deploy:
 - gl created a random-password service. Its a deployable but ideally he should have captured the logic into a module - excluding the mouse-generating-randomness - the module's function would probably have a optional "randomness" paramterer.
 - I created a slugify-url module... given that its use is to create mnemonic filenames out of urls... it makes sense as npm -g installed executable with a man page etc.

Toilets and innovation

I have always been surprised by the difficulty that knowledge and innovation find to flow across cultures, fields, countries.

My wife just called me panicky to tell me that the washer water is coming out and it is all over the wooden floors. The most silly litlle thing and you have permanant damage to the floors. If I were in an appartment or a second floor the damage would extend to the ceiling of the guy below me. This disaster would never happen in Europe. There every toilet has in the middle what the showers have here: a small covered drain ,  and the toilet floor is always built in a way that it has a tilt towards that point. On top of avoiding flooding the appartment, it makes washing toilets a much less ugly chore.

(I will avoid discussing the details of the opposite problem. European toilet bowls haven't discovered the simple idea of being filled up with water (its more than that - they use a different flushing technique) Water is only at the very bottom which makes flushing/self cleaning a disaster compared to American toilets bowls...)

Nodejs development trick

I am developing an app . I have pushed out most of the functionality of the app in modules. The modules are relatively application specific - but they would allow someone to create a similar/slightly different app without having to deal/change much of the module-encapsulated code.
Any this has resulted in a 2 level deep dependence
 app depends on module1
module1 depends on module2.

To keep things developped in parallel modules are alredy in repos.. and published as they advance.
When I need to do some concurrent development across modules/apps how do I do it.

Here is my trick
I have cloned the repos of all three app, module1, module2 above.
I have run npm install in the app where I prefer to work
I run
> nodemon index.js 
in the app.
I remove the (sole code ) index.js in the node_modules and replace them with a soft link to the repos..
> cd node_modules/module1
> rm index.js
> ln -s ../../../module1/index.js .
> cd ../..
I do the same for the deeper module as well:
> cd node_modules/module1/node_modules/module2
> rm index.js
> ln -s ../../../../../module2/index.js .

At this point I can edit the module's index.js inside their own repos...as I would have like to do and the changes are automatically reflected in my app repo. Nodemon is smart , it does anyway a recursive decent and follows the symlinks... saving my index.js in the module repo results in nodemon restarting my app. 

The only problem is I need to remember and not do any destructive operations on the node_modules tree.