Skip to content

Instantly share code, notes, and snippets.

View SekibOmazic's full-sized avatar

Sekib Omazic SekibOmazic

32 followers · 0 following
  • Matrix
View GitHub Profile
@rollacaster
rollacaster / Reactive Conf Proposal.md
Last active October 26, 2017 16:21

TL;DR: Star 🌟 this gist. (You might need to request the desktop version)

such meta

After buying the tickets for ReactiveConf I discovered the call for Lightning Talks and decided it's time to leave the attendee seat and hold my first public talk. To calculate the odds I wrote a script to get the current ranks of all Lightning Talks. This script is the topic of my talk:

Getting a Lightning Talk slot for ReactiveConf 2017 with FP

@teropa
teropa / reactive2015_gol.md
Created September 24, 2015 15:56
ClojureScript Game of Life - Reactive 2015 Lightning Talk Proposal

In my proposed lightning talk for the Reactive Conference, I'll create Conway's Game of Life in ClojureScript, and I'll do it in five minutes. I'll use an interactive programming workflow enabled by Figwheel. Each piece will be added into the running application without reloading the page.

If you want to see a little cellular lifeform spawn out of nothing into an running web browser window, I'd appreciate it if you starred this Gist!

Cheers,

(@teropa)

@robwormald
robwormald / angular2.jspm.md
Last active January 5, 2022 21:21

Angular2 + JSPM cheat sheet

First time setup

  • install jspm beta: npm install -g jspm@beta
  • set up your project: jspm init
  • install dependencies: jspm install angular2 reflect-metadata zone.js es6-shim

This will create a jspm_packages folder, and a config.js file.

Open the config.js file - this file manages options for the System.js loader - tweak it as appropriate

@evancz
evancz / Architecture.md
Last active December 21, 2022 14:28
Ideas and guidelines for architecting larger applications in Elm to be modular and extensible

Architecture in Elm

This document is a collection of concepts and strategies to make large Elm projects modular and extensible.

We will start by thinking about the structure of signals in our program. Broadly speaking, your application state should live in one big foldp. You will probably merge a bunch of input signals into a single stream of updates. This sounds a bit crazy at first, but it is in the same ballpark as Om or Facebook's Flux. There are a couple major benefits to having a centralized home for your application state:

  1. There is a single source of truth. Traditional approaches force you to write a decent amount of custom and error prone code to synchronize state between many different stateful components. (The state of this widget needs to be synced with the application state, which needs to be synced with some other widget, etc.) By placing all of your state in one location, you eliminate an entire class of bugs in which two components get into inconsistent states. We also think yo