Installing keycloak

Keycloak is a redhat (and therefore now IBM) product for Identity and Access Management.

If you need an auth service for your app, Keycloak is a perfect candidate.


I like docker compose, so here is how I do it using official example from their repo:

version: '3'
      driver: local
      image: postgres
        - postgres_data:/var/lib/postgresql/data
        POSTGRES_DB: dbname
        POSTGRES_USER: dbuser
        POSTGRES_PASSWORD: dbpassword
      image: jboss/keycloak
        DB_ADDR: postgres
        DB_DATABASE: dbname
        DB_USER: dbuser
        DB_PASSWORD: dbpassword
        KEYCLOAK_USER: admin
        KEYCLOAK_PASSWORD: adminpwd
        - 26000:8080
        - postgres

Rose are red
Violets are blue
Newsletter are hard to do.

Here is release 0

If You’re Not Embarrassed By The First Version Of Your Product,
You’ve Launched Too Late


watch video

Key take away :


Uppy The happy uploader

Gamification for engagement and monetisation

engagement and monetisation are nearly two aspects of the same thing.
The user want to use to your app and is ready to invest more time or more money for it.


  • Reddit : gamified status. Paid for social status using credits
  • Audible : subscription earn you points, with points you can gain option to download books. Stop your sub and you lose all your points.
  • Stack overflow: Points for status based on competency and status, if you dont have enough credit you cannot vote or you cannot comment or don’t have access to some of the features
  • Duolingo : An app for learning language. Good use of gamification mechanism to drive consistency.

In app payment mechanisms :

  • pay to get more :
    • closed member area – exclusivity
    • extra services (free delivery) – conveniency
  • pay as you go
    • fake currency allow to create a loss-aversion mechanism
    • extend existing services
  • Speed throatling : pay to get it faster

here is how you can restream a source video from one RTMP to Facebook live

ffmpeg -i "rtmp://" \
-r 30 \
-ar 44100 \
 -s 1280x720 \
 -c:a libfdk_aac -b:a 90k \
 -movflags +faststart \
 -preset veryfast -crf 28 \
 -tune zerolatency \
 -profile:v baseline \
-maxrate 1000k \
-vcodec libx264 \
-bufsize 10000k \
-g 60 \
-max muxing_queue_size 1024 \
-f flv "rtmp://"

ok lets break this down a bit:
-r is for output framerate
-ar is for audio rate
-s is for scale – i.e. the size of the video
-c:a is for audio encoding – note that this can be replaced by aac on some distribution

Needed this for a project

Here are some ressources for medium like elements for your react app

NB: Article still in progress

A jargon-free explanation of Agile for people who just want to work and build a product.

The basics

Agile is based on the recognition of a few facts:

  • We suck at time estimation
  • We suck at communication
  • It is easier to correct small mistakes than big ones

So taking this into consideration, the main idea is to break down a big projects into a loads of small ones. Very small ones. Like one or two weeks long projects, up to one month max.

Why? Because small projects means only small mistakes, easier to correct and stay on track.

In this short period of time, we try our best to produce something that look like the final product or part of it.

We test it, fix our assumptions for further planning : time, resources and what is the end result – and then we go at it again.

That’s it.



Seriously. Don’t over complicate it.
We could. But we are not going to do that here.
What’s important is too understand the strenghts of Agile is to keep things simple.

Really simple.


I promised a jargon-free article but we still need to get some words out of the way because you will see them very often.

Roadmap: The big blocks you want to achieve
Backlog: A huge list of stuff you have to do to make the roadmap happen
Sprint: The small block of time you need to deliver a version of the product.
Standup meeting: Not really standing up – but the concept is to keep so simple you could have these meeting over a watercooler. Have these often. Like everyday if you can. Maybe even twice a day.
Burndown Chart: How fast will you burn that pile of stuff you gotta do to get this product shipped? That’s question everyone want to know? Well, you don’t really know anything what you know is that it’s day 1 and you have 856 items to do to ship this project. If day 2 you have only 850 and day 3 you have 842 then you can start getting an idea of the speed you will go and how fast you “burndown” these fuckers.
Kanban board

Agile applied to web application


Design Workshops
Design Sprint

Design deliverables
Design system

  • Components
  • Brand
    UX Wireframes


Marketing & User feedback

Iterations and new features

The end?

Maybe you are asking why there are so many books, so many trainings about it if that’s so simple?

It is because simple is hard.

We – as humans – tend to like :

  • perfection
  • security
  • predictability

Agile provide none of that out of the box.

No perfection
Since you keep doing small parts of the project, you keep delivering a half-done product . You have to be ok to ship something that is not yet perfect. This is harder than it looks. But you gotta trust the process and just keep on delivery small parts that accumulate over time to the full picture.

No security / predictability
It is lie to promise anything more than “We will try our best to achieve this and that in a given amount of time”.
A lie we say all the time.
Security does not come from agile.
It comes from experience. If you have experience with the work and with team that will be working on it, you have can have good confidence that your estimation is close to the truth. Roughly. That’s also why doing a gantt chart at the begining of a project when you have never worked with these people you cannot say anything smarter than – “Let’s start to work and see how fast we are chopping down these trees”. Once you’ve cut trees for a couple of weeks you can start getting a better idea of an estimate.

So really it is just a realistic approach to risk management – meaning, since we are brutally honnest about our lack of guaranties regarding the results, let’s break it down into a very small chunk of manageable pieces of work where we have high confidence we can manage – and predict – but if not – then it is no big deal because we can also improve the week after.

That’s it.

The big secret is that even regular project management know time scheduling is a big illusion. Agile decided to make this official and not lie to ourselves.

Of course there are some ways to do time estimations in agile – which are actually pretty accurate. But that’s because the philosophy of the method is that we are pretty bad at time estimation and therefore it’s taking a radical approach to it.

Recommendation Engines / Recommender systems are information filtering systems that deal with the problem of information overload by filtering vital information fragment out of a large amount of dynamically generated information according to user’s preferences, interest, or observed behavior about the item. Recommendation Engines / Recommender system has the ability to predict whether a particular user would prefer an item or not based on the user’s profile

  • Facebook : People You May Know
  • Netflix : Other Movies You May Enjoy
  • LinkedIn: Jobs You May Be Interested In
  • Amazon : Customer who bought this item also bought
  • YouTube : Recommended Videos
  • Waze : Best Route

Building a recommendation engins

Things is made relatively easier than what it used to be.

Tutorials and stuff


interesting idea