Saturday, August 16, 2014

standalone cheap hardware principle = development principle you should apply every-time at any cost and how

Dev principle: 
Been able to develop in standalone mode on cheap hardware is a hard requirement

Why? To be efficient, you need simplicity (their is always a layer of abstraction who breaks like: internet, vpn, remote desktop, grid, file server, wiki, hardware, ....

  • Split data/code dependency (need to work on a grid, cloud or supercomputer)
  • add small testing dataset to your code base
  • Data dependency should be avoided at any cost
But I need access to my data on a file server and can't mount it?
  1. commit small anonymised data (MAT: Metadata Anonymisation Toolkit) or
  2. transfer file:
    1. scp @machine:/somewhere/abc.txt .
    2. rsync @machine:/somewhere/abc.txt .
  3. Use sshfs (warning: recommended for browsing & not recommended if you need to access lot of data from use scp or rsync instead)
    • use your favorite linux distribution like ubuntu
    • You are stuck on window, use a virtualbox
    • apt-get install sshfs
    • sshfs @machine:/somewhere somewhere -o sftp_server=/usr/libexec/openssh/sftp-server

Enjoy working a a cheap unconnected hardware and be so much more efficient (time is your biggest asset). Its a win/win for you and your company. 

Software coder protection principle rule #1: keep your tools at any cost and how

Your value is linked to your tools so never break that link. Why? Ask yourself what can you do without your tools? Answer: less stuff + way slower+harder to be a serial-entrepreneur.
Most company will force you to break it and use proprietary argument to support it and make you sign contract to make you their property.

As a founder, you define the rule & vision so:

  • You need to make the distinction between business IP and generic IP
  • Generic IP don't need to be kept secret
  • Most software company are leveraging generic IP (open source)
  • Contribution to open source is good because:
    • Helps attracting talent
    • Leverage the community
    • Makes better employee (not invented here syndrome/disease)

So what should you do:
  • Split your code always into 2 parts: external/internal
  • external contributions to existing project is much better to make this rule not breakable by investors
  • Leverage/contribute/create your own open source projects now if you haven't done it already
  • Info about opensource licences you should include
  • Make it a rule to contribute

So the protection rule #1 of software coder is:

  • Make opensource part of your software since its inception/creation

If you don't follow this rule, when you will leave or get fire from your own company, life will be much easier if you have your tools to move forward on your next projects. 

Wednesday, August 6, 2014

My simple ETA estimator

Here is an improved version of how we were calculating ETA in one of my previous company:

You need 4 scores as follow: 
  • Effort(task) = Task effort team average point            (people agnostic) [1=easy;2=medium; 3=hard]
  • Complexity(task) = Complexity effort team average point   [Fibonacci: 1=easy, 2=medium, 3=hard, 4=quite hard ...]
  • Knowledge(task, user) = expertise/knowledge [1=expert;2=intermediate....]  (Bob+task#1=2; Alice+task#1=3)
  • UserEfficiency(user) = user point/day factor [1,2,3...]             (ex: Bob=2; Alice=3)

Once you assign a user to a task, you can compute an ETA like this: 

ETA (task,user)= Effort(task)*Complexity(task)*Knowledge(task,user)*UserEfficiency(user)



ETA(task1,Bob)=1*1*2*2=4 days
ETA(task1,Bob)=1*1*3*3=9 days

Saturday, July 19, 2014

Simple way to make bash script configurable

In order to simplify testing, I needed to make a bash script configurable. 
Yes bash is quite convenient to archive some tasks. 
I had trouble finding the syntax to override environment variable.

Here is a simple way to make to do it:

  • set default environment variables (recommendation = pointing to stable code)
  • make override config file a parameter 
  • add this to make config override working (config is argument 4):

# check override configuration
if [ ! -z $4 ]
    echo "load config file:" $4
    source $4
    echo "default config (stable branch)"

    eval var=\\$VARIABLE
    [ -z ${!var} ] && { echo "Need to set $VARIABLE"; exit 1; }
    echo $VARIABLE":"${!var}


Yes the syntax is a little cryptic but that is the only way I found to make is working;)
Btw, this isn't working in sh (calling source to set variables). 

Monday, July 7, 2014

which and alias: which doesn't consider aliases......use type not which

Have you notive that "which cmd" doesn't give your alias path if cmd is in your aliases?

Aliases are checked before paths when you try to run a cmd in a prompt but which doesn't consider aliases. Which search for the cmd in your paths. If cmd is in your path, you will be confused and you might turn crazy as I close did.

Use type instead of which.

usage: which [options] [--] COMMAND [...]
             Write the full path of COMMAND(s) to standard output.

usage: type [-aftpP] name [name ...]
With no options, indicate how each name would be interpreted if used as a command name

Monday, June 16, 2014

The revenge of the close architecture (Apple success = the black box model for B2C)

Most people are expecting Apple slow decline since Steve Jobs died. Basically, history will repeat itself : microsoft vs apple and now android vs iphone. Open architecture will win again against close architecture.

I am not so sure and here is why: 
  • Apple is fundamentally B2C
  • C want stuff that works, real plug and play. Average Joe don't really care if its not an open architecture like microsoft and android. Average Joe want stuff that works straight away. 
  • Increase of complexity (ISP/wifi/driver/software/configuration/....) + new businesses in tech support like

The black box model says basically that at a level of complexity, we are no longer able to understand increasingly complex explanation (stack of layers of abstractions). Basically, in the future, it will be the norm to convince people with images and emotions rather than arguments

Close architecture has the major advantage of keeping thing simple which is becoming more and more relevant in this techno world. Open architecture is for geeks and businesses.  


Here is the black box model as expose in "the decision book:50 decision models".  

What you shouldn't forget about transition to leadership

Here are the 2 most important concepts of transition to leadership:

I do recommend you take some time to read "the decision book:50 decision models".  

You will learn about: 

"The key to successful leadership today is influence, not authority." --Ken Blanchard

Cover Title Page
Instructions for use
The Eisenhower matrix: How to work more efficientiy
The SWOT analysis: How to find the right solution
The BCG box: How to evaluate costs and benefits
The project portfolio matrix: How to maintain an overview
The John Whitmore model: Am Ipursuing the right goal?
The rubber band model: How to deaf with a dilemma
The feedback model: Dealing with other people's compliments and criticisms
The family tree model: The contacts you shouid maintain
The morphological box and SCAMPER: Why you have to be structured to be creative
The Esquire gift model: How much to spend on gifts
The consequences model: Why it is important to make decisions prompt/y
The conflict resolution model: How to resolve a conflict elegantly
The crossroads model: So what next?
The flow model: What makes you happy?
The Johari window: What others know about you
The cognitive dissonance model: Why people smoke when they know it's unhealthy
The music matrix: What your taste in music says about you
The unimaginable model: What do you believe in that you cannot prove?
The Uffe Elbaek model: How to get to know yourself
The fashion model: How we dress
The energy model: Are you living in the here and now?
The SuperMemo model: How to remember everything you have ever learned
The political compass: What political parties stand for
The personal performance model: How to recognise whether you should change your job
The making-of model: To determine your future. first understand your past
The personal potential trap: Why it is better not to expect anything
The hype cycle: How to identify the next big thing
The subtle signals model: Why nuances matter E The network taraet model: What vour friends sav abo
The network target model: What your friends say abo'Ut you
The superficial knowledge model: Everything you don need to know
The Swiss cheese model: How mistakes happen
The Maslow pyramids: What you actually need. what you want
Thinking outside the box: How to come up with brilliant ideas
The Sinus Milieu and Bourdieu models: Where you belong
The double-loop learning model: How to learn from your mistakes
The Al model: What kind of discussion type are you?
The small-world model: How arm” the world really is
The Pareto principle: Why 80 per cent of the output is achieved with 20 per cent of the input
The long-tail model: How the internet is transforming the economy
The Monte Carlo simulation: Why we can only approximate a definitive outcome
The black swan model: Why your experiences don make you any wiser
The chasm - the diffusion model: Why everybody has an iPod
The black box model: Why faith is replacing knowledge
The status model: How to recognise a winner
The prisoner's dilemma: When is it worth trusting someone?
The Drexler-Sibbet team pedormance model: How to turn a group into a team
The team model: Is your team up to the job?
The gap-in-lhe-market model: How to recognise a bankabfe idea
The Hersey—Blanchard model (situational leadership): How to successfully manage your employees
The role-playing model: How to change your own point of view
The result optimisation model: Why the printer always breaks down just before a deadline
The world's next top model
NOW IT'S YOUR TURN Drawing lesson 1 Drawing lesson 2
My models
APPENDIX Bibliography Illustration credits Final note Thanks
The authors