menu

魔法を失う日

魔法は在る日を境に突然なくなったりはしない。魔法によって自分を運んでくれていた船がいつの間にか止まってしまっていることに、いつの日か気づくのだ。自分のまわりの世界が止まっていることに気づいてはじめて、自分が魔法を使えていたと知ったのだとしたら、なんと不幸なことだろうか。あなたにはもはや魔法の力はないのに、魔法によって過ごせた楽しい思い出だけが存在するのだ。いまとなっては船を降りる覚悟もできぬまま、餓死するまで言い訳と躊躇にとらわれるだけだ。その前に精神を病んでしまうかもしれない。
魔法は、心と世界を繋いでくれていたのだ。

誰もが本当はかつて魔法を使えたのだということを、私は知っている。

昔の記憶を思い出せなくなるのといっしょに、魔法の力も失われていく。
失われていく前に見つけなければならないものは、あなたの半身、肉体である。
肉体と繋がって魔法使いは人間となる。その足で地球を回し、肩で風を切って喜びを感じる。
あなたはあなたの船ではなく、魔法を失った人の船が止まっているのに気づいたとき、魔法が存在したことを知る。魔法によって過ごした幸せな日々は、あなたの目指すべき目標に変わる。頭と身体で考え、頭と身体で幸せを作っていこうとする。

 

魔法が、自然に存在した世界ではそうだった。

衆愚と批評

社会学的批評が語らなければならない問題は、「流行っているこれは何か」ではなく「なぜこれが時代の必然として流行るのか」だろう
そういう意味ではSNS以前と以後で批評の形が変わっていないことは明らかにおかしい
ポップカルチャーすら生き抜いた批評が現在形を無くしているように見えるのは、批評というものが「優れた小数の人による洞察」ではなくて単に「たくさんの人が見ている意見」に過ぎなかったということだ。近代において文化の担い手が大衆に移ったとしても、メディアに言葉を載せるのに能力やコネが必要だった時代では良識ある発言者の言葉だけが批評になる可能性を持つことができた。SNS以後、誰かがシェアしたものだけがメディアとなる時代ではまず誰かの共感を得てはじめて言葉は広がり始める。必然として全体の意見は衆愚になる。
批評が現在取り組まなければならないのはこの衆愚であり、それは建築においても政治においても社会学においても変わらないんじゃなかろうか。そして時代の波に乗るしか文化の生き残る道はないのだとすれば批評は言葉を捨てなければならない。なぜならそれは共感を得るにはあまりにも抽象的すぎるからだ。言葉としての批評は唯一、後世から見た時代のリファレンスとしての役割を残して死んだ。ペンが剣や銃よりも強い時代は終わっているのだ。

実装ゲーを抜け出して相対化ゲーに参加する

実装は熱意と時間があれば誰にでもできる。

新しいものが出てきたタイミングであなたが思いつく既存物との組み合わせは誰もが同時に思いついている。

その新技術の開発者や周辺人物と比べればスタートラインすらあなたの遥か前方にあるのだ。

勘違いをしている。

組み合わせることがイノベーションというのは結果論に過ぎない。

あなたの洞察によって整理された仕組みを実装するのに既存物の組み合わせが必要なだけだ。

相対化して、実装せよ。

計算力が上がりモジュール価格が下がり続ける限り、人間の改善スピードを圧倒的に上回る試行が可能となる領域は広がり続ける。

そうした世界では相対化自体に価値は無い。批評や予想はむなしく現実の後を人間の速度で歩き続ける。まるで人間から見たゾンビのように、ゆっくりと。

洞察を、実現せよ。

たくさんのdxfをillustratorで開けるように変換する

現在のIllustratorでは、AutoCAD以外から書き出したdxfを開こうとすると「テキストファイル」として認識されてしまいます。

https://helpx.adobe.com/jp/illustrator/kb/234692.html

AutoCADのheaderが無いからなのですが、せめて選択できるとか警告を出すとかにしてほしい。。。

まあ出来ないものは仕方ないとして、例えばOpenSCADやKiCADで書き出したdxfを毎度テキストエディタで開いて、上記サイトを開いてheaderをコピペして、無駄な改行を削除して。。。とやるのはさすがに極まっています。愚が。

こんなときこそautomatorの出番です。(osx限定)

automatorで「アプリケーション」を作成し、「シェルスクリプトを実行」、「引数として」入力を引き渡し、以下のコマンドを実行します:


for f in "$@"
do
	LF=$(printf '\\\012_')
	LF=${LF%_}
	sed -i "" -e "1s/^/0${LF}SECTION${LF}2${LF}HEADER${LF}9${LF}\$ACADVER${LF}1${LF}AC1008${LF}/" $f
done

sedの挙動はLinuxのGNU版とosxのBSD版では微妙に違いがあり、下記サイトを参考にしました。

http://qiita.com/catfist/items/1156ae0c7875f61417ee

そしたら後は作成されたappをdockに追加して、headerを追加したいファイル群をアイコンにドラッグ&ドロップするだけでおkです。

個人的にosx卒業する機運が高まりつつあるなか、こういう小回りの良さが捨てがたいなぁと思います。

confluenceをmedium風のコンテンツファーストデザインにする

cssを書いた:

https://github.com/Drunkar/confluence_css_mediumlike

 

cssを適用するブラウザ拡張(たとえばchromeならstylishなど)で適用する。

※ コンテンツ内容は変わりません

デザインコンセプト

会社での情報共有ツールとしていろんなところで使われているっぽいconfluenceだが、残念なことにそのデザインはひどい:

  • 統一されていない: 場所によってavatar画像が四角だったり丸だったり。
  • メリハリにとぼしい: 見出しがはっきりと分かれてくれないので、見出しを識別する負担を見る人に強いている
  • フォントがダサい: Arialしか指定されてないので日本語は完全にOS依存
  • 意味のないリンクが多い: “Confluence”とかいらねーし。コンテンツこそが重要。

特にやりたかったことは、

  • ブログ投稿の敷居を下げる

こと。情報発信がカジュアルにできればみんな動いてる感が出て良い循環が生まれる気がする。このへんはgithubのプロファイルページの”Contribution activity”が分かりやすくて良いデザインだなーと思っていた(自分のアクティビティだけしか表示されないけど)。

なのでデザインのコンセプトは以下のとおり:

  • 記事の内容を見るためにあるので、もちろんコンテンツファースト
  • ただし記事階層へのリンクなど、情報の構造は表示する
  • 日頃から良いと思っていたMediumとGithubを参考にする
  • 文字のメリハリをはっきりつける: mediumでも弱いと思っていたので見出しの直前はさらに離す
  • 良い日本語フォントを使う: Noto sans jp

なぜコンテンツファーストか

そもそもmediumがなぜあのようにワンカラムで、記事コンテンツとシェアメニューしか表示していないのか。逆になぜ普通のブログは「人気記事」とか「最近の更新」とかブログパーツとかが表示されているのか。

答えは簡単で、前者はSNS+スマホ時代に適したデザイン、後者はPC時代のデザインだからだ。SNS以前のPC時代では検索エンジンが流入の要だったため、まさにサイトを「訪問」する感覚で人はブラウジングをしていた。そうした時代に別記事へのリンクや楽しめるコンテンツをサイト内に配することは、回遊性を高めて滞在時間を延ばすのに大きな効果を発揮した。しかし今ではメディアによってはSNS流入がほぼすべて、特にニュースやちょっとした記事に関してはその傾向が顕著だろう。

したがって独自コンテンツでサイト内をぐるぐる回らせるより、使いやすく見やすく共有しやすいデザインの方が結果として双方向メディアはうまくいくように思われる。それを体現しているのがmediumだと僕は考えている。

なので社内wikiとしてのconfluenceがPC時代のデザインを踏襲するのは根本的に間違っている。それは単に頭に思いついたデザインの骨格をかっこよくしていこうとするだけの作業で、良いデザインにはいっこうに近づけない。

情報を共有し、見て、みんながなにかをやっていることを感じながらたまに覗ければよいのだ。

 

このブログもいいかげんに移行したい…

AITalk WebAPIを使ってwavを生成してs3に保存するaws lambda

LINE BOT AWARDSのハッカソンに参加した。ぷ◯きゅあがタスクの終了や寝る時間などを通知すると同時に音声合成でしゃべってくれる、という(いちおう)親子向けのBOTを作った。

LINE apiはeventに応じてwebhookが飛んでくる仕様になっているため、serverlessのアーキテクチャでシステムを作った。つまりlambda、step functionsをはじめとしたaws漬けだったのだが簡単に優れた設計のアプリが作れて僕スゴいじゃなくてawsマジすごい。

そのソースコードも公開する予定なのだが、スポンサー企業でもあったAITalkさんのAPIを呼んで音声合成したWAVEファイルをs3に保存するところは汎用性が高そうなのでgithubにrepositoryを作った。

https://github.com/Drunkar/aitalk_webapi_wav_generator_lambda

中身もいちおうここに貼っておく。めんどくさかったのは、jsのaws-sdkにはs3にファイルをアップロードする方法がなかった(rubyにはあるみたい)ので、jsのオブジェクトとしてメモリに保持した状態でputObject()することでI got Kotonaki. たぶんstreamを理解している人ならば一時ファイルとして/tmp以下に保存することなくs3にアップロードするコードが書けると思う。


var http = require("http");
var fs = require("fs");
var aws = require("aws-sdk");

var api_url = "http://webapi.aitalk.jp/webapi/v2/ttsget.php";

exports.handler = function(event, context) {
    var request_url = api_url +
        "?username=" + encodeURI(event.aitalk_username) +
        "&password=" + encodeURI(event.aitalk_password) +
        "&text=" + encodeURI(event.text) +
        "&speaker_name=" + encodeURI(event.aitalk_speaker_name) +
        "&volume=" + encodeURI(event.aitalk_volume) +
        "&speed=" + encodeURI(event.aitalk_speed) +
        "&pitch=" + encodeURI(event.aitalk_pitch) +
        "&range=" + encodeURI(event.aitalk_range) +
        "&ext=wav&use_wdic=1";

    var outFile = fs.createWriteStream("/tmp/" + event.filename);
    // start download
    http.get(request_url, function(res) {

        // output as a file
        res.pipe(outFile);

        // download end
        res.on("end", function() {
            outFile.close();

            // open the wav file as a js object and putObject to S3
            var s3 = new aws.S3();
            fs.readFile("/tmp/" + event.filename, function(err, data) {
                if (err) {
                    return console.log(err);
                }
                var params = {
                    Bucket: event.bucket,
                    Key: event.filename,
                    Body: data,
                    ContentType: "audio/wav",
                    ACL: "public-read"
                };
                s3.putObject(params, function(err, data) {
                    console.log(err, data);
                });
            });

        });
    }).on("error", function(e) {
        context.done("error", e);
    });
};

テストイベントを以下のように飛ばせばおk。


{
  "aitalk_username": "",
  "aitalk_password": "",
  "aitalk_speaker_name": "nozomi_emo",
  "aitalk_volume": "2.00",
  "aitalk_speed": "1.20",
  "aitalk_pitch": "0.90",
  "aitalk_range": "2.00",
  "text": "戦争に負けたから堕ちるのではないのだ。人間だから堕ちるのであり、生きているから堕ちるだけだ。",
  "filename": "voice.wav",
  "bucket": ""
}

NeoPixel系のRGB LEDがたくさんあるので調べてみた

NeoPixelってなんですか

Adafruitが販売している、シリアル通信でRGB値が制御できるLEDのこと。ここではトップ画像にあるような、マイコンを内蔵したRGB LEDチップについて述べる。厳密にはNeoPixelとはこれらマイコン付RGB LEDを総称したadafruitの商品シリーズ名である。

NeoPixelの歴史

小型のマイコン内蔵RGB LEDが出てきてからの歴史は以下の感じ。

  1. WS2812時代: 元祖NeoPixel? 6つのピンのうち5つを使用し、LED用のpowerとcircuit用のpowerが分かれていた。
  2. WS2812B時代: powerが1つに統合されて4ピンに。
  3. SKの登場: WS2812BのクローンであるSK6812が登場。製造元が違うと思われるがどちらもNeoPixelとして公式に販売されており同じ明るさ、色、プロトコルで動作する。
  4. DotStarの登場: 新たな商品ラインナップとして高リフレッシュレートのDotStarシリーズが登場。チップ型番が”APA”からはじまる。

販売店や製造元

選び方

POV[Persistent Of Vision] に使うのならばDotStar、それ以外ならNeoPixelで一番手に入りやすいWS2812B、SK6812が良い。adafruitの公式ショップで買うとめちゃくちゃに高いが、Aliexpress等で半額以下で手に入る。秋月とかLEDピカリ館でも売っている。

参考: NeoPixel vs DotStar

https://learn.adafruit.com/adafruit-dotstar-leds/overview#dotstars-vs-neopixels

NeoPixelsの方が安いし扱いやすくform-factorも多様なので、POV(persistence-of-vision)のように高リフレッシュが必要とか、割り込みが必要な処理の中で使ってるとかでない限りNeoPixelで良いっぽい。

参考: 各製品の特徴

1. WS2812(元祖NeoPixel?)

6つのピンのうち5つを使用し、LED用のpowerとcircuit用のpowerが分かれていた。
コレ以前の世代(WS2802)は5mm×5mmより大きいledしかなかったもよう。

2. WS281X, SK681X系(WS2812BやSK6812等、最もよく知られたNeoPixel)

WS2812からpowerが1つに統合されて4ピンになった。
XT1511というクローンもあるようだがその詳細はよくわからん。
WS281X系はマイナーアップデート版( http://www.instructables.com/id/Compare-SK6822-WS2813-APA102-SK9822/step2/WS2813-and-SK6822-LED/ )らしいがあまり手にはいらないので、大量に使いたい場合はWS2812BかSK6812に限る。

重さ

http://www.akiba-led.jp/product/1499
この防水stripを5LED分切り出してみると、1.07g。防水ビニルを剥がすと0.43g。

SK6812MINI

通常のNeoPixelは5mm×5mmだが、こちらは3.5mm×3.5mm。サイズがシビアな場合に。

https://cdn-shop.adafruit.com/product-files/2686/SK6812MINI_REV.01-1-2.pdf

ちなみに香港国際空港には全面LEDサイネージとなっている柱がある。液晶と比べてフチがないのですごく目を惹くが、このディスプレイに使われてるLEDは2mm-3mm角だった。どこで手に入るのだろう。

3. WS2822, SK6822 (進化版だが流通量が少ない)

各LEDにIDを振ることで1つのLEDが壊れてもstripの後ろが消えることがなくなった。しかしIDを送ったりするためピンは6本に戻った。WS2822は特にあまり出回っていない。

シリアルLED(WS2822S)をつかってみました。

プロテインについて本気出して考えてみた

今年の私は筋肥大を目指すこととなった。

そこに至る経緯はまた別の日に書くとして、そうなったからには目的を達成するのに効率的な手段を講じるのが必然である。僕は意味のあることをするのが好きだ。意味のないことを考えるのも同じぐらい好きだけれども、実行するときにはもっぱら意味のあることを好む。

そうだね。プロテインだね。

なぜプロテインを飲むのか

トレーニングや食事管理にはさまざまな目的がある:

  • 減量
  • 増量
  • 筋肥大

等が代表的だろうか。体脂肪と筋肉の量を調整することによって目的を達成する。筋肉は傷ついた筋繊維を補修することで肥大していくのだが、その過程で必要となる補修材がアミノ酸で、アミノ酸の原料がたんぱく質である。したがって

  1. 筋繊維を傷つける
  2. たんぱく質を補給する

ことが必要だ。一般に筋肥大を目的としたトレーニングを行っている場合、一日に体重×2/1000 [g] のたんぱく質が必要だと言われている。体重が60kgの人ならば120gである。コンビニのサラダチキン1つに含まれるたんぱく質が25gぐらい、ゆで卵1つに含まれるたんぱく質が6gぐらいであることを考えると、たんぱく質が豊富なおかずを6〜8品ぐらい食べることでようやく必要なたんぱく質を摂取できることになる。当然これだけの食事を一般的な食品から作るとなると膨大な熱量になる。筋肉は肥大するかもしれないが間違いなく肥満になるだろう。

だから、プロテインによってたんぱく質を集中的に補給する必要があるのだ。

たんぱく質の質

すでにここ一年で口にしたよりも多く「たんぱく質」と言っているが、実はたんぱく質といってもすべて同じというわけではなく、質の違いがある。わかりにくいのでqualityと書こう。みんな大好き定量指標だ。たんぱく質のqualityはどのような指標であらわされるのだろうか。

「プロテイン 比較」と検索すると、「アミノ酸スコア」とか「プロテインスコア」とかいう指標がよく出てくる。よく売れているプロテインのいくつかには、「アミノ酸スコア100」や「アミノ酸スコア100の原料を使用」と記載されている。さらには、「アミノ酸スコアはダメだ。プロテインスコアも見ろ。」というような論旨の似たような記事がたくさん見つかった。

端的にいうと必須アミノ酸の量が十分にあるかどうかという指標だが、調べてみるとどうやらこれらは国際連合食糧農業機関(FAO)が策定した指標らしい。全米マッスル協会とかではないので、より多くの人を健康にする食糧供給に資する指標ということだろう。アミノ酸スコアに上限がつけられていることも一応これで説明がつく。

もうちょっと調べてみるとPDCAASやDIAASといったものも出てきていて、指標はさらに進化していることがわかった:

  • 1957年: プロテインスコア

↓ 人体における必要量を考慮

  • 1973年以降: アミノ酸スコア。日本では1973年か1985年の指標を使っていることが多い。

↓ 吸収率を考慮。便中の窒素含有量から吸収率を推定する。

  • 1993年: たん白質消化吸収率補正アミノ酸スコア(PDCAAS)

↓ Antinutrient (反栄養因子: 栄養の吸収を妨害する)を考慮していない。-> タンパク質のsourceを考慮に影響される。上限も撤廃。

結局指標はなにがいいのか

基本的に指標は理にかなった根拠を持って更新されているように見えるので、最新の指標が良いと思う。ただし、PDCAASからは便を使って測定するなど人体との相互作用を考慮しているために食品単体では検査できない。ほとんどの食品やプロテインがアミノ酸スコアを採用しているのは測定が簡易な指標であるためと思われる。(人体に分解・吸収されるまでを考慮する栄養学の進化を無視しているとも言えるが。)

今回は吸収スピードの高い動物性たんぱく質、特にホエイプロテインのみを対象にするので吸収効率とかは似通ってると考えてもいいと思う(卵とかカゼインとか配合してるものもあると思うけど。)アミノ酸組成だけからプロテインを評価する場合は上限を撤廃したアミノ酸スコアとかを考えると良さそう。

ただし、人気のあるプロテインでもアミノ酸の種類を制限していたりleucineを減らしていたり、アミノ酸スコアで計れない合成をしている場合もあってこのへんはよくわからない。良い効果があるのかもしれない。

プロテインを調べてみよう

日本と海外で売れてるものから調べてみた。

このうちweb検索でアミノ酸組成を発見できたものはたったの3製品だった。ファック。

意味のあるたんぱく質摂取をしたいので、成分が見つからなかったものは論外である。成分が見つからないもののひとつ、amazon.co.jpで一番売れてるsavasのやつとかはたんぱく質含有率が低めで、そのかわりにいろんな栄養素を含んでいるようだけどそれが筋肥大に与える影響をメカニズムから説明するべきだろう。というかプロのトレーナーとかはこんなブラックボックスを使ってどうやってトレーニング計画をたてているのか?なにか私には計り知れないコツがあるのだろうか。

もうこれしかないじゃん

アミノ酸組成が確認できた3製品は、以下の3つ:

  • ボディウイング製「ホエイプロテイン」 (Amazon.co.jp 4位)
  • Champion Performance製「Pure Whey Plus」(Amazon.co.jp 5位)
  • Optimum Nutrition製「Gold Standard 100% Whey」(bodybuilding.com 2016 1位)

この中では、Optimum Nutrition製 Gold Standard 100% Wheyが一番良い (商品画像はamazonアフィリンク)

  • たんぱく質含有率が高い (77.42%)
  • アミノ酸スコアが高い (96.89)
  • PDCAASも算出されていてしかも高い (100)
  • それなりに安い (3,029円/kg)
  • bodybuilding.comで10年連続売上1位という圧倒的実績

など、買わない理由が浮かばないほど。私は迷わずこれを買った。

いちおう残りの2製品も紹介しておく。2番目のおすすめはボディウイング製 ホエイプロテインだ。

今回調べた国産プロテインでは唯一アミノ酸組成の情報があり、たんぱく質含有率が高く(78%) アミノ酸スコアも高い (100.96) うえにGold Standardよりも700円ほど安い (2,290円/kg)。ただし一食分として推奨されている量が若干少ないので厳密に推奨量を守った場合、たんぱく質は1食で18.72gしか摂れない。またボディウイングは水素水を販売していたりもするので、売れそうな商品をOEMで売っているだけの業者なのではという疑いの目を私は向けている。ちょっとの値段の差に目をつぶれば、プロテイン会社としての実績もあり研究がなされている(と思われる)Optimum Nutrition製品を買うほうが懸命な判断だと私は思った。

3番目はChampion Performance製 Pure Whey Plus。

驚くほどアミノ酸スコアが低い(44.54)が、これはisoleucineが要因だ。2番目に低いスコアはPhenylalanineの96.57で、これはOptimum Nutrition製 Gold Standardとほぼおなじ。Isoleucineだけ圧倒的に少ないのは意図的にカットしているからでは、とも思ったがAmazon.comでの商品詳細説明に「pure whey plus ultra-refined protein helps stop muscle breakdown by delivering essential branched chain amino acids (such as leucine, isoleucine, and valine) your muscles crave after heavy weight training…」とisoleucineの重要性を書いてもいるので合成の都合上やむなく低い値となっているのだろう。したがってこれを買うのはおすすめしない。

今回集めたデータ

あまりたいしたものではないですが、せっかく集めたデータなので公開します。MITライセンスです。

https://docs.google.com/spreadsheets/d/1hvKrslxb1-EiENHSrUPnL4MUMOkoyfZeK2wfcqRVgJk/edit?usp=sharing

トレーニング方法とかもおもしろいものが見つかれば書きます。

git stashでオートセーブを実現するatom packageを作った

(この記事はAtom Advent Calendar 2016 に参加しています: http://qiita.com/advent-calendar/2016/atom )

 

かつて、こんなことはなかったでしょうか:

チームでgitを使っていて、masterの変更を反映させたいとき。

「ローカルの編集を退避させたいのだけど、stashでなんかよくわからん記録をつくるほどでもないし、コンフリクトしているファイルだけcheckoutしちゃおう。」

「よし、mergeできた。(俺もgit使いこなせるようになってきたナァ)」

―10分後

「よし、全体をbuildしてruntimeテストしよう」 → ERROR

ナンデ!?

 

gitの操作によって必要なローカルの変更を削除しちゃう経験、ありませんでしたか?僕はありました。

むしゃくしゃしたのでこれを解消するatom packageを作りました。(実際にはどちらかというと泣きそうになりました)

git-auto-stash

https://atom.io/packages/git-auto-stash です。

これを導入することで、定期的にgit stashが作られ、ファイル喪失の悲劇が多少減るのでは、と思っています。ぜひ使っていただいて、必要な機能などフィードバックをください。

 

自動保存を実現するしくみ

gitってファイルの履歴が保存されるんだし、gitの機能をどうにか使ってこの自動保存の仕組みを作れないか、と考えていたところ、「working treeに影響を及ぼさずにgit stashを作る方法」があることを知りました。

git stash create + git stash store -m <コメント> <hash>

です。

これを定期的に行うことで、トラッキングされているファイルであれば、stashに保存されるようになります。こちらはなにも考えなくてよしなにしてくれるというのが素晴らしいですね。具体的には、atom.workspace.observeTextEditorsで取得できるeditorのonDidStopChangingを使って保存のトリガーとしています。

何分ごとに保存するか、auto stashの最大数はいくらにするかはsettings画面から指定できます。

 

atomナンデか

DropboxやTimeMachineでいいじゃん、という人もいるでしょう。

しかしこうした汎用的なサービスはいちいち過去ファイルを掘っていくのが面倒だし、それならば開発の際に必ずと言っていいほどお世話になるgitとatomで完結するほうが、僕には気持ちの良い解決に思えたのです。

また、sublimetextじゃないの?て人もいるかと思いますが、もうatomに乗り換えちゃいなよ、と言っておきます。それぐらいatomは進化しています。

atomはsublimetextよりも思想的に優れて(electronを採用してる点とか)いたものの恋に落ちるような心地よさは微塵も無く、僕も何度か乗り換えを試みましたが最終的には殺意とともに離別したものでした。ところが今年の10月ごろに半年ぶり4度目ぐらいの乗り換えを試みたところ起動はすんなり、packageもほぼエラーが起きない、書いていてウザい機能がオプションで無効化できる、さらにelectronならではの異常に便利なpackage群が僕を待っていました。

ES6ムズいね

はじめてES6を触ったのでPromiseの理解に最初はとても苦しみました。結果なんとか動くコードにはなったものの間違いなくベストプラクティスに則っていないため、pull requestお待ちしております。

いまは指定した分数ごとにauto stashを行うだけですが、1分前、10分前、30分前、60分前、3時間、6時間、12時間、24時間ぐらいに一定間隔の過去stashを保存しておく機能は今後追加したいなと思っています。