- I wanted to learn Kalaripayattu - took 1 month leave from office.
- Took flight to Kochi from Chennai.
- It was a small village in rainforest in a place called Athirapally in Kerala.
- This place was full of jungle, waterfalls and small tribal villages.
- A tribal man took me into the jungle where there was Kalari - the school to learn Kalaripayattu
- It was big room - lot of weapons - few people were practising
- Met a woman, Paravathi - tall, strong, brown in color, bold and big eyes. I looked at her biceps. - she was no less than a warrior.
- I was wondering is it really needed in this 21st century ? What about our army ? It looks like they are preparing for war. As usual I had many unanswered questions.
- She took me to her house - a small hut with granny inside. She told me to get sleep and wake up at 3 AM in the morning for practise.
- Granny told me stories about Kalaripayattu - how britishers banned that artform and came to the village in the search of that book. A book? What book? I asked
const { from, timer } = require('rxjs'); | |
const fetch = require('node-fetch'); | |
const getTimeFromAPI = () => { | |
return fetch('http://worldclockapi.com/api/json/est/now') | |
.then((resp) => resp.json()) | |
} | |
// Observer timer and subscribe |
(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.
Zagg multi node sync (for bitcoin blocks) won’t work since we were not making level dbs sync to each other.
- Setup 2 node zagg network using stellar’s configurations
- Throw transaction with Account Marker operation (for bitcoin transaction HEX) over one of the node.
- The operation has to go through validation from Bitcoin code base using
doValidate()
of the operation. - After getting all the operations validated, the transaction goes into mPendingTransaction (which is nothing but memepool for stellar.)
As you can see network is running
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b33ee58cff04 hyperledger/fabric-peer:1.4.0 "peer node start --p…" 2 minutes ago Up 2 minutes 0.0.0.0:7151->7051/tcp, 0.0.0.0:7152->7052/tcp, 0.0.0.0:7153->7053/tcp peer0.org2.hurley.lab
4e5f88113b8c hyperledger/fabric-peer:1.4.0 "peer node start --p…" 2 minutes ago Up 2 minutes 0.0.0.0:7051-7053->7051-7053/tcp peer0.org1.hurley.lab
e486d8bb7d29 hyperledger/fabric-couchdb:0.4.14 "tini -- /docker-ent…" 2 minutes ago Up 2 minutes 4369/tcp, 9100/tcp, 0.0.0.0:5184->5984/tcp couchdb.peer0.org2.hurley.lab
cb3d0de40305 hyperledger/fabric-ca:1.4.0 "fabric-ca-server st…" 2 minutes ago Up 2 minutes 0.0.0.0
#Introduction
Developing Chrome Extensions is REALLY fun if you are a Front End engineer. If you, however, struggle with visualizing the architecture of an application, then developing a Chrome Extension is going to bite your butt multiple times due the amount of excessive components the extension works with. Here are some pointers in how to start, what problems I encounter and how to avoid them.
Note: I'm not covering chrome package apps, which although similar, work in a different way. I also won't cover the page options api neither the new brand event pages. What I explain covers most basic chrome applications and should be enough to get you started.
Proposor----+---+---------------^---------------+---+-----------------^----^------------
/Acceptor | | | | | ACCEPT(s1,X) | |
| |PREPARE(s1) | | | | v
Acceptor ---v---|-----------^---|---------------|---v-----------------|------------------
| | |PROMISE(s1) | | ^ ACCEPTED(s1,X)
| | | | | |
Acceptor -------v-----------+---+---------------v---------------------v----v--------------