This is a simple chat-like program using pub-sub pattern, backed by PostgreSQL's LISTEN/NOTIFY command.
publish message to foo
channel from user nickname
.
$ python pub.py foo nickname
PUBLISH to channel #foo
~/Projects/opensource $ rails -v | |
ruby Rails 3.0.5 | |
~/Projects/opensource $ ruby -v | |
ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin10.6.0] | |
~/Projects/opensource $ rails new foo | |
create | |
create README | |
... | |
create vendor/plugins/.gitkeep | |
~/Projects/opensource $ cd foo/ |
;SMBDIS.ASM - A COMPREHENSIVE SUPER MARIO BROS. DISASSEMBLY | |
;by doppelganger ([email protected]) | |
;This file is provided for your own use as-is. It will require the character rom data | |
;and an iNES file header to get it to work. | |
;There are so many people I have to thank for this, that taking all the credit for | |
;myself would be an unforgivable act of arrogance. Without their help this would | |
;probably not be possible. So I thank all the peeps in the nesdev scene whose insight into | |
;the 6502 and the NES helped me learn how it works (you guys know who you are, there's no |
#!/bin/bash | |
# Instead of editing a file with <<<< ==== >>> conflict markers, this opens | |
# each "side" of the conflict markers in a two-way vimdiff window. | |
# | |
# Layout: | |
# | |
# Tab1 is a two-way diff of the conflicts. | |
# +--------------------------------+ | |
# | LCONFL | RCONFL | | |
# +--------------------------------+ |
weave∙partition≡id : ∀ {A} {m n m+n : ℕ} {mn-proof : m + n ≅ m+n} | |
fn (vec : Vec A (m + n)) → | |
weave (partition {A} {m} {n} fn vec) ≅ vec | |
weave∙partition≡id {A} {0} fn [] = refl | |
weave∙partition≡id {A} {suc m} {0} fn (x ∷ xs) = | |
cong (_∷_ x) (weave∙partition≡id {A} {m} {_} {_} {+0 m} fn xs) | |
weave∙partition≡id {A} {0} {suc n} fn (x ∷ xs) = | |
cong (_∷_ x) (weave∙partition≡id {A} {0} {_} {_} {refl} fn xs) | |
weave∙partition≡id {A} {suc m} {suc n} fn (x ∷ xs) with fn x | |
... | true = cong (_∷_ x) (weave∙partition≡id {A} {m} {_} {_} {refl} fn xs) |
#!/usr/bin/env ruby | |
# This script has been slightly adapted from: | |
# http://blog.bigbinary.com/2013/09/19/do-not-allow-force-pusht-to-master.html | |
class PrePushHandler | |
def handle | |
reject if force_pushing? && pushing_to_master? | |
end |
Hi there!
The docker cheat sheet has moved to a Github project under https://github.com/wsargent/docker-cheat-sheet.
Please click on the link above to go to the cheat sheet.
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
In this gist I would like to describe an idea for GraphQL subscriptions. It was inspired by conversations about subscriptions in the GraphQL slack channel and different GH issues, like #89 and #411.
At the moment GraphQL allows 2 types of queries:
query
mutation
Reference implementation also adds the third type: subscription
. It does not have any semantics yet, so here I would like to propose one possible semantics interpretation and the reasoning behind it.
// Define your components like: | |
class MyComponent extends React.Component { | |
static fetchData = (params) => { | |
// return an action here. | |
}; | |
/* ... */ | |
} | |
function fetchComponentData(component, store, params) { |