Kentucky Fire Cured – Chunky

Mon 1er billet sur une nouvelle passion, les cigares! Merci mathieu B. il se reconnaitra 🙂

Découvert au Tabac à Porte de St Cloud sur Paris (sur le rond point). Le buraliste qui est fan de cigare également, m’a proposé de tester celui là. Effectivement l’odeur particulière m’a interpelé.

Le Chunky 4×46 est assez petit comparé au Robusto dont j’ai pris l’habitude. J’ai mis ~30min pour le déguster.
Il est assez gras, et dans son petit sachet fraicheur, par ailleurs, je conseil de le laisser dans son sachet si comme moi j’ai une petite cave et le mettre bien à part! Car son odeur peut imprégner les autres cigares.

Allumage sans problème, pas de rallumage au cours de la dégustation.

On s’attends a avoir un gout très prononcé, acre et bien fort vu l’odeur, mais au contraire! Je fus assez surpris de la saveur de ce dernier.
Arôme de bois brulé agréable et surprenant, à partir de la moitié, un petit goût d’amertume arrive de manière subtile.

Je me souviens plus du prix de ce dernier, mais en tout cas, j’ai bien aimé.

Conclusion: un petit cigare et surprenant, pour ceux qui aime les cigares un peu fort.

Ma note: 14/20

Setup a quick Squid proxy for dev testing with docker-compose

As a developer not in a startup, we do not have any proxy to setup. So we use to develop as usual in a beautiful world! But, when deploying for the first time in a particular production environment, we can often have some surprise!

Here my surprise was the squid proxy! Our API is behind a squid proxy…

But how to recreate the environment when coding/testing? Docker-compose is the solution!

Let’s create the docker-compose docker-compose.test.yml:

version: '2'

services: 
  api: 
    container_name: 'my-api' 
      extends: file: ./docker-compose.dev.yml 
      service: api 
    volumes: 
      - ../reports:/app/reports 
      - ../mocks:/app/mocks 
    command: "npm run test" 
    ports: 
      - "3000:3000" 
    environment: 
      NODE_ENV: test 
      http_proxy: http://squid:3128 
      https_proxy: http://squid:3128 
      no_proxy: localhost, 127.0.0.1, elasticsearch 
    depends_on: 
      - mongo 
      - elasticsearch 
      - squid 
    networks: 
      - api-network 
  mongo: 
    container_name: 'mongo-test' 
    image: mongo:3.6.4 
    ports: 
      - "27017:27017" 
    networks: 
      - api-network 
  elasticsearch: 
    container_name: 'es-test' 
    image: docker.elastic.co/elasticsearch/elasticsearch:6.4.0 
    expose: 
      - "9200" 
      - "9300" 
    networks: 
      - api-network 
  squid: 
    container_name: 'squid-test' 
    image: datadog/squid 
    expose: 
      - 3128 
    networks: 
      - api-network

networks: api-network:

Running this compose file, now I run my tests without changing my env var..

How to make brew works after uninstalling xcode

On my macbook pro with 128Gb, I’ve uninstall xcode (take almost 12Gb, 10% of the storage!).

Once removed, I’ve notice that homebrew is looking for xcode…


$> brew install dotnet
Updating Homebrew...
==> Homebrew has enabled anonymous aggregate formulae and cask analytics.
Read the analytics documentation (and how to opt-out) here:
https://docs.brew.sh/Analytics

xcrun: error: active developer path ("/Applications/Xcode.app/Contents/Developer") does not exist
Use sudo xcode-select --switch path/to/Xcode.app to specify the Xcode that you wish to use for command line developer tools, or use xcode-select --install to install the standalone command line develo
per tools.
See man xcode-select for more details.

Wait! So when calling


$> xcode-select --install
xcode-select: error: command line tools are already installed, use "Software Update" to install updates

Cool! I’m stuck…

In fact, I just have to switch to the CommandLine installed


$> sudo xcode-select --switch /Library/Developer/CommandLineTools

And voilà

Dynamic partials template with handlebars-loader

How to handle dynamic partials? Here the solution!

I’m actually working to move out from bower/grunt to webpack, we do use handlebars for templating with precompiled templates/partials.

Here how to manage dynamic partials with handlebars-loader.

During the migration, I find out that handlebars-loader cannot manage dynamic partials… (see Issue #81)

I figured out that webpack guide lines for loader is :

  1. A loader is a single function
  2. Should do only 1 task
  3. Should not have any state when launching the task

That’s why handlebars-loader create a handlebars context when it compile.

To handle dynamic partials like {> (whichPartial)} or {> lookup . 'myVar'} we will register partials by our self.

Just register all your “partials” that could be called dynamically.


import Handlebars from 'handlebars'
import MyPartial1 from './_myPartial1.handlebars'
Handlebars.partials['myPartial1'] = MyPartial1; // < Here we register precompiled as partial.

Hope that’s help!