Rapid prototyping exercices

Exercise 1: Mobile TV programs dashboard

  • Scenario: when users login on the app what will they see, what can they do
  • Goals: Engagement

Exercise 2: Rapid prototyping of a live class

  • Scenario: User is watch a live class – with interactive features
  • Goals: interactivity with the teacher and / or other studens, accessibility, access to materials

Exercise 3: A memo card :

  • scenario: User selected to watch a series of random memo cards
  • goals: Fun, Interactive

Exercise 4: Collaborative social media publishing

  • Scenario: User create an plan content for multiple social media
  • What to think of: Various roles – Content creator, Editor, Translator, Manager, Advertiser
  • Goals: Clarity
  • Tip: Think Buffer/Hootsuite

Exercise 5 Collaborative Translation system

  • Scenario: Translators, editor, proofreader, collaboration options
  • goals: Simplicity, clarity, option for everyone to work on it
  • Tip: think kanboard, vertical and / or horizontal

Exercise 6 Scheduling Meeting

  • Scenario: User want to schedule a meeting with a professional
  • goals: Simplicity, clarity
  • Tip: Calendar app

Exercise 7 Task managements

  • Scenario: User want to add a task to a task list, to project or to a
  • goals: Simplicity, clarity
  • Tip: Calendar app

Yes, once this was the internet

Internet Explorer is EVIL!


ARNGREN – ecommerce from hell


LingsCar – UK best car shop


WebRTC is great
Janus is a cool library (link if you never heard of it : github and good intro link)

But boy is it CPU intensive.

here are some links for the case you’re looking at ways to lower the damage

Client CPU benchmark and how to improve it

Performance analysis of the Janus WebRTC gateway

WebRTC – CPU reduction, settings to tweak

WebRTC SFU Load Testing

What is it?

source code on github

From the website :

SRS delivers rtmp/hls/http/hds live on x86/x64/arm/mips linux/osx, supports origin/edge/vhost and transcode/ingest and dvr/forward and http-api/http-callback/reload, introduces tracable session-oriented log, exports client srs-librtmp, with stream caster to push MPEGTS-over-UDP/RTSP to SRS, provides EN/CN wiki and the most simple architecture.

Basically it is a simple way to set up and get going with an RTMP server.

How to Create an SRS Server

I obsviously still need to test it live. But this looks like a nice option.
Alternative is to go with Nginx as a server like for example in this demo.

I haven’t made my mind yet which is the best option to go with.
I’d tend to say Nginx is more robust … but maybe just because of the brand and actual SRS is as good and maybe simple to manage… dunno yet…

Some research I have made recently while working on a broadcasting module of an app.
Just saving here some of the best link I have found – as backup and maybe of interest for some people.

Obviously if you are looking for a super structured article – I am far from it at this point – but that’s still the filtered version of a few hours of research to find the relevant and usable stuff – and it is practically what I have used to get to the point of a transcoding version of ffmpeg with facebook live (next step is to turn it into a nodejs microservice)

Setting up a RTMP server

Getting started with nginx-rtmp-module: a FOSS alternative to Wowza, FMS, et al.

How to set up your own private RTMP server using Nginx/

Streaming Video on Demand with nginx and RTMP Module

Facebook Live with nodejs



FFmpeg to facebook live









Cicada 3301 is an organization who used puzzles to possibly recruit codebreakers/linguists from the public.

The first internet puzzle started on January 4, 2012, and ran for approximately one month.

A second round began one year later on January 4, 2013, and a third round following the confirmation of a fresh clue posted on Twitter on January 4, 2014.

MongoDB Schema Design – Many small documents or fewer large documents?

Source : Stackoverflow

Modeling One-to-Few

An example of “one-to-few” might be the addresses for a person. This is a good use case for embedding – you’d put the addresses in an array inside of your Person object.


An example of “one-to-many” might be parts for a product in a replacement parts ordering system. Each product may have up to several hundred replacement parts, but never more than a couple thousand or so. This is a good use case for referencing – you’d put the ObjectIDs of the parts in an array in product document.


An example of “one-to-squillions” might be an event logging system that collects log messages for different machines. Any given host could generate enough messages to overflow the 16 MB document size, even if all you stored in the array was the ObjectID. This is the classic use case for “parent-referencing” – you’d have a document for the host, and then store the ObjectID of the host in the documents for the log messages.

How should I implement this schema in MongoDB?

   username_name: string

   title: string
   description: string
   link: string

   user_id: integer
   camp_id: integer

   os: text
   referer: text
   camp_id: integer
   user_id: integer


MongoDB relationships: embed or reference?


  • Put as much in as possible

    The joy of a Document database is that it eliminates lots of Joins. Your first instinct should be to place as much in a single document as you can. Because MongoDB documents have structure, and because you can efficiently query within that structure (this means that you can take the part of the document that you need, so document size shouldn’t worry you much) there is no immediate need to normalize data like you would in SQL. In particular any data that is not useful apart from its parent document should be part of the same document.

  • Separate data that can be referred to from multiple places into its own collection.

    This is not so much a “storage space” issue as it is a “data consistency” issue. If many records will refer to the same data it is more efficient and less error prone to update a single record and keep references to it in other places.

  • Document size considerations

    MongoDB imposes a 4MB (16MB with 1.8) size limit on a single document. In a world of GB of data this sounds small, but it is also 30 thousand tweets or 250 typical Stack Overflow answers or 20 flicker photos. On the other hand, this is far more information than one might want to present at one time on a typical web page. First consider what will make your queries easier. In many cases concern about document sizes will be premature optimization.

  • Complex data structures:

    MongoDB can store arbitrary deep nested data structures, but cannot search them efficiently. If your data forms a tree, forest or graph, you effectively need to store each node and its edges in a separate document. (Note that there are data stores specifically designed for this type of data that one should consider as well)

    It has also been pointed out than it is impossible to return a subset of elements in a document. If you need to pick-and-choose a few bits of each document, it will be easier to separate them out.

  • Data Consistency

    MongoDB makes a trade off between efficiency and consistency. The rule is changes to a single document are always atomic, while updates to multiple documents should never be assumed to be atomic. There is also no way to “lock” a record on the server (you can build this into the client’s logic using for example a “lock” field). When you design your schema consider how you will keep your data consistent. Generally, the more that you keep in a document the better.

Mongo schema design (Youtube playlist)

Looking to build a calendar app in React.
You are not alone.

I did some research to see what the world published on this so far, and here is what I have found.

Room Booking System

A room booking system built with MongoDB, Express, Node.js and ReactJS.

This one has a lot going on. But it’s interesting to have a look at it.

It seems like it’s a uni project or something… at least it’s organised as such.

It has wireframes and docs and a breakdown of the use case and a working demo.

Git repository: https://github.com/julia-/room-booking-system

Demo: https://room-booking-system.netlify.com/

React Big Calendar

A Google Calendar clone in react.

An events calendar component built for React and made for modern browsers (read: IE10+) and uses flexbox over the classic tables-ception approach.

Git Repo: https://github.com/intljusticemission/react-big-calendar

Demo: http://intljusticemission.github.io/react-big-calendar/examples/index.html

React Google Calendar

Like above but also integrate the Google API stuff so it does not only *look* like Google Calendar but can actually talk to Google Calendar.

Git Repository: https://github.com/crashspringfield/react-google-calendar

For now that’s all I have found. I might post an update if I find anything interesting extra.

On a side note – there is this guy doing a tutorial on react native book app here – that’s interesting and can spark some ideas too, so I am putting it here.