Forem: yurfuwa

Gdiff / Gblame ~,p,:,HEAD

yurfuwa — Fri, 20 Apr 2018 04:59:22 +0000

Vimで GdiffとかGblame 使ってて、いつも忘れるのでメモ
Gblameでコミットログを出した後に、 ~,pで過去未来を辿れるが、そのあと現行のindexとdiffを出したいときは

:Gdiff :

すると現在のファイルと比較できる。 Gdiff master とか head を指定してしまうと挙動がちょっとあれになる

seealso : http://cohama.hateblo.jp/entry/20120317/1331978764

Dockerfileで Github Enterprise or PrivateRepository から pip install する

yurfuwa — Wed, 18 Apr 2018 06:05:24 +0000

Enterpriseなgithubをつかっていると、pipで自社のModuleをインストールしたいことはよくある。
privateなDockerImageをbuildするときに、privateなRepositoryからpipする的。

python:3.6とかのdockerの場合、ssh-agentが立ち上がってないので立ち上げて鍵登録まで一気に持っていく。
known_hostsに書き込まないと、知らんサイトとしてinteractiveにお伺いがきて蹴られる。

RUN eval `ssh-agent` && ssh-add -k any_your_key && mkdir -p ~/.ssh && ssh-keyscan -t rsa github.enterpise.domain > ~/.ssh/known_hosts \
&& pip install --no-cache-dir -r requirements.txt

RUN後は鍵登録が飛ぶので、Dockerimage内に鍵を含めたくない場合は、pipした後に消すと良い気もする。

TwitterのタイムラインからURLを抽出してRSSにしてFeedlyで読む

yurfuwa — Tue, 03 Apr 2018 20:21:26 +0000

昨今の界隈ではLDRことLive Dwango Reader (ex. Livedoor Reader)がサービス終了したことが話題になった。
自分はRSS readerには Feedly Pro を長らく使っており、LDRを利用したことがないので特に感慨はない。

Feedly

Feedlyについては簡単に説明しておきたい。
Feedlyは使いやすくシンプルなRSSリーダであり、mobile appもある。PROにすると検索性が格段にアップするし、なによりポピュラーな記事をサマって今日見るべきカテゴリをまとめてくれるのが便利だ。
さらに j で記事移動、v で記事移動、gg でカテゴリ移動のように、vimのようなショートカット配置になっているのも嬉しい。LDRより軽量とは言えないかもしれないが、見やすいしデザインはモダンだ。自分は多く時間を費やすものには金を払う価値があると思っている。

電子ドラッグ

さて、話を戻そう
そもそも最近のインターネットは受動的な情報選択をする傾向にある。TwitterやFacebookなどのソーシャルメディアが跋扈し、情報はほぼSNSによって共有される。
RSSリーダを使っているのはもはや老害の域に達しており、RSSを吐いてくれるサイトも随分減ってしまった。嘆かわしいがこればかりは仕方がない。

相対的にTwitterを見る時間が長くなってしまった人も多いだろう。流速のあるタイムラインでは、情報の取捨選択を瞬間的に行う必要がある。情報は必ずしも有益なものとは限らない。というより、ほとんどのツイートはノイズのようなもので、一時的に脳を麻薬のように刺激し、時間を浪費する。Twitterは電子ドラッグといっても過言ではない。

砂金拾い

しかし中には素晴らしい情報も紛れている。自分が興味があり、ナレッジを蓄積し、知的好奇心を満たしてくれるような素敵な情報の共有が、玉石混交に確かに存在している。
Twitterとは、砂金集めのようなものだ。そして自分の場合その砂金は、短文よりもURLの先にある。

というわけで私は、大量の砂から砂金を分け、革袋にまとめることにした。つまりTwitterで流れる文章からURLを抜き出し、RSSにまとめ、いつも使っているFeedlyに落とし込む。

アーキテクチャはこのようになる。

ポイントとしては

AWS APIGateway + Lambda + Dynamodb サーバレスで運用する。
Twitter API で stremに接続し、URLを抽出して投げる
APIGatewayはエンドポイントを用意し、 GET ではRSSを返し、 POSTでデータを蓄積する
TwitterのClientに Raspberry pi を使う

AWS APIGateway + Lambda + Dynamodb サーバレスで運用する。

今回はサーバレスな構成にしてみた。
まずは出力側から考えたい。
Dynamodbのテーブルは以下のようになっている

url
timestamp
created_at
expired_at (TTL)
text

TTLを使用することで、dynamodbに無尽蔵に突っ込まれるデータを定期的に消去する。ここでは登録から2時間後にしている。Feedlyはおおよそ30分間隔、速いと10分でRSSを取得しに来る。取り込まれてしまえばRSSには情報は残っていなくても良い。よって、2時間も消費期限が持てば充分であり、それ以降は必要ないので消してしまう。
Dynamodbはデータの蓄積にも金を取るし、バッチで一個一個消すのも面倒だ。TTLを使えば登録時に指定した時間に消えてくれる。
テーブルは常に表示されるべきRSSのデータのみで完結する。これによってLambdaでは単にlambda_handlerにGETが来たらテーブルをscanしてjsonにくるむだけ良い。

def respond(err, res=None):
    return {
        'statusCode': '400' if err else '200',
        'body': '{}' if err or not res else json.dumps(res,cls=DecimalEncoder),
        'headers': {
            'Content-Type': 'application/json',
        },
    }


def lambda_handler(event, context):

    operations = {
        'DELETE': lambda table, x: table.delete_item(**x),
        'GET': lambda table, x: table.scan(),
        'POST': lambda table, x: table.put_item(Item=x),
        'PUT': lambda table, x: table.update_item(**x),
    }

    operation = event['httpMethod']
    if operation in operations:
        payload = None if operation == 'GET' else json.loads(event['body'])
        return respond(None, operations[operation](table, payload))
    else:
        return respond(ValueError('Unsupported method "{}"'.format(operation)))

APIGatewayを使って、エンドポイントを定義する。

GETの統合レスポンスに application/rss+xml を指定し、本分マッピングテンプレートで以下のように登録する。
これによってLambda側で処理されたJSONをRSSにマッピングできる。Lambdaはあくまでデータ処理だけを考えればよく、APIGatewayが最終出荷物をコントロールしている。

#set($inputRoot = $util.parseJson($input.path('$.body')))
<?xml version='1.0' encoding='UTF-8'?>
<rss version='2.0'>
    <channel>
        <title>yurfuwa's twitter</title>
        <link>http://twitter.com/yurfuwa</link>
        <description>extract timeline-share-links</description>
        #foreach($item in $inputRoot.Items)
        <item>
            <title>$item.text</title>
            <link>$item.url</link>
            <description>$item.text</description>
            <pubDate>$item.created_at</pubDate>
        </item>
        #end

    </channel>
</rss>

これで、AWSから発行されたURLのエンドポイントを叩けば、dynamodbに登録されているデータのRSSが出力されるようになった。個人で利用するだけなので、ドメインを取得する必要もない。

Raspberry piでTwitterのクライアントを作る

自分は自宅サーバーをとうの昔に捨ててしまった。その代わりにRaspberry piを使っている。EC2も考えられるが、AWSは富豪的だ。たかが個人のタイムライン監視に、EC2でお金を払うのは辛い。個人用のSlack botなんかも、Raspberry piでやっている。

ここでも、特に難しいことはしないが、Lambdaではpython3を使ったがClientはnodeにしている。
Twitterのストリームに接続したら、expanded_urlが含まれているか見る。含まれていたら、指定のURLを除外して、整形して、APIGatewayで作ったエンドポイントに POST で投げる。
先程のLambdaはすでにPOSTで来たらDynamodbのテーブルにput_itemするようになっているから、これで完成。

var twitter = require('twitter');
var client = new twitter( {...})
var request = new require('request');
const urlRegex = require('url-regex');

var stream = client.stream('user', {with : 'followings'});

stream.on('data', function(event) {
    var media = event.entities.media;
    var url = event.entities.urls[0];
    if(event.lang == 'ja' && url && url.expanded_url && !(
        /instagram.com|twitter.com|twitpic.com|ift.tt|swarmapp.com|nico.ms|pixiv.net|bit.ly|this.kiji.is|nhknews.jp|fb.me|tenki.jp|j.mp|melonbooks|ask.fm/.test(url.expanded_url)
    )){

        var options = {
            uri: process.env.NODE_TWEET_SHARE_ENDPOINT,
            method: 'POST',
            json: {
                "url": url.expanded_url,
                "text": event.text.replace(/RT \@[A-z|a-z|0-9|\-|\_]+\:\ /,'').replace(urlRegex(),''),
                "created_at": event.created_at,
                "timestamp" : parseInt( Date.now() / 1000 ),
                "expired_at" : parseInt( Date.now() / 1000 ) + 7200
            }
        };

        request(options, function (error, response, body) {
              if (!error && response.statusCode == 200) {
                      console.log(body)
              }
        });

    }
});

運用費

さて、AWSのサービスを使っているので、一月のお値段が気になる。

このような感じ。EC2ではこうはいかない。Dynamodbは無料枠の範囲内で収まる。
TTL設定しないと爆死するし、Twitterのフォローが1万人とか監視いる人は知らん。

Feedlyで表示してみる

実際運用してみると素晴らしく、良い。
Feedlyは勝手に話題っぽいURLを優先してくれるので、無尽蔵にURLを突っ込んでも見るべきものから表示される。
Twitterを漠然と眺めている時間は減る上に、RSSは10分間隔で更新されるので速報系のニュースにも強い。

最終的にはディープラーニングでTwitterからのソースをクラスタリングして、カテゴリごとにRSSを吐くとなお良さそう。教師データは既にあるカテゴライズされたRSSのソースを使えばいいし。

RaspberryPi + AmazonAlexa を使って部屋の湿度を喋らせる

yurfuwa — Thu, 04 Jan 2018 07:22:57 +0000

部屋の乾燥が気になる季節。
加湿器を使って部屋を加湿している人も多いだろう。
自分はほしい加湿器(通称壺)があるものの、どの程度加湿されるのか怪しい。
まずは部屋がどの程度乾燥しているのか、そして加湿するとどのような変化があるのか定量的に視覚化したい。

作る。

センサはこれ。

配線はこれとかこれあたりを参考に。

自分のRaspberryPiのモデルは2011 12のModel B。GPIO配列はこう。

ふわこ

@yurfuwa

自宅rasp,いつもモデルとgpio配列を忘れがちだから貼っておこう

17:15 PM - 02 Jan 2018

実行コードはここのサンプルやつを流用。

フムー。干からびてしまう。

$ python dhht11.py
humidity: 6 %,  Temperature: 24 C

湿度5%というのは中東バーレーンと同等らしい。アラブ人だから仕方ないね。

次にAlexaに接続する。アーキテクチャ。

raspの実行コードからdynamodbにデータを格納し、AWS Lambdaを経由してAlexa Skill kitで喋らせる。

実行コードに以下を追加し、boto3からdynamodbのテーブルにアップデートを掛ける。一分毎の update_itemなので、キャパシティは全く気にする必要がない。DIYのデータストアに最適なのがDynamodbなんだよな。

def update_data(temp,humidity):
    db = session.resource('dynamodb')
    table = db.Table('room-status')
    room = table.update_item( Key = {'room' : 1 }, AttributeUpdates={ 'temp': { 'Value': temp, 'Action': 'PUT' }, 'humidity': { 'Value': humidity, 'Action': 'PUT' } })

Alexa Skill Kit 用の AWS Lambda の実行コードは Echokit を使う。デコレータとインテントがうまく紐付いており、かなり使いやすい。

import os
from echokit import EchoKit
import boto3
from boto3.session import Session
from boto3.dynamodb.conditions import Key, Attr

application_id = os.environ['APP_ID'] if 'APP_ID' in os.environ else 'amzn1.ask.skill.000'
app = EchoKit(application_id, verify_app_id=False)
handler = app.handler

# LaunchRequest
@app.launch
def on_launch(request, session):
    data = get_data()
    return app.response("部屋の温度は、{}度、湿度は{}%です".format(data['temp'],data['humidity']))


def get_data():
    db = session.resource('dynamodb')
    table = db.Table('room-status')
    room = table.get_item( Key = {'room' : 1 } )['Item']
    return room

読み取って喋るだけ。Alexaは喋りたい内容をJSONで適切に返す必要があるが、Echokitはうまく隠蔽してくれるのが良い。flask的な発想で実装されている。

Alexa Skillkitの登録周りは割愛。インテントモデルモクソもない。AWSLambdaのARNを登録するだけでいい。このタイプは本来スマートホームAPIを使うべきだが、スマートホームAPIにはEchoの高級なモデルか、Bluetoothのハブとなる端末を別途実装or買う必要がある。
インターネットに我が家の湿度情報を放流するほうが簡単である。
しかし恐らくこの実装は審査に通るまい。（Alexa Skill storeに登録するには審査が必要なのだ）

なのでここでスキルの実機端末へのクローズベータテストの機能を使う。これを使うと、特定のAmazonアカウントに対してクローズドベータと称してスキルをばらまくことができる。

テレーン

「うちの温度を開いて」

となっているのは、スマートホームAPIを使っていないからである。件の機能を使うと「うちの温度いくつ？」等でイケると思う。

鍋加湿ソリューション

さて、Alexaに湿度を喋らせることが出来たので、いつでも部屋の湿度はわかるが、湿度は全く改善していない。

加湿器を買えという意見もあるが、水を加熱すると蒸気が出ることが知られています。

ふわこ

@yurfuwa

鍋加湿ソリューション

14:22 PM - 03 Jan 2018

日本の家はよくできており、匂いがリビングに充満しないように熱い空気がキッチン上空に停滞するような構造になっている。なのでサーキュレータで無理やりリビングに空気をデリバリーした。

ふわこ

@yurfuwa

ソリューションによって得られた結果

14:38 PM - 03 Jan 2018

鍋加湿ソリューションで短時間に55%を達成したが、水の補給と火の始末がめんどくさい。
寝るときは止める必要があるのが課題。

なお止めると

ふわこ

@yurfuwa

05:51 AM - 04 Jan 2018

ものの1.5時間で湿度が半分になり、5%に向けて突き進む。
鍋加湿ソリューションにはサステナビリティがない。

やはり壺が欲しいので誰か買ってください

Flask + Tensorflow + Keras でモデルからのpredictが動作しない問題

yurfuwa — Thu, 16 Nov 2017 08:01:02 +0000

機械学習ライブラリを使ったPredictなAPI開発

WebサービスでAIを活用する場合、多くはmicroservices的にVPC内にAPIを独立してデプロイし、インターナルに利用することが増えてきた。ことChainerやTensorflowといった機械学習系のライブラリは、その歴史的背景や数学ライブラリからPythonと相性がよいため、必然的にPythonのWAFを選択することになる。

pythonでmicroservicesなAPIでのWAF

PythonでWebアプリケーションを開発するには、WAFとしてDjango,Flaskの二大巨頭が台頭しているが、概ねシンプルな推論のAPI開発にDjangoは大して冗長であって、Flask辺りがつかっていて小気味良い。

マルチスレッドにおけるモデルデータの参照問題

Tensorflowにしろ、Chainerにしろ、APIでの推論は、機械学習の成果として得られるモデルの読み込みが必要になる。
Tensorflow + Keras では、サーバ起動時に事前にモデルをメモリに展開し、グラフを構築しておく。リクエスト時にはそれを利用する形になる。

この時、マルチスレッドで動作していると、構築されたグラフのスレッドとは別のスレッドでリクエストを受け付けることになるので、グラフをスレッド間で共有する必要がある


global thread:

        self.model = load_model(model_path)
        self.model._make_predict_function()
        self.graph = tf.get_default_graph()

another thread:

        with self.graph.as_default():
            labels = self.model.predict(data)

see also : https://github.com/fchollet/keras/issues/2397

サーバレスアーキテクチャにおけるTensorflowの利用

昨今流行りのサーバレスであるが、GCP Cloudfunctionはそもそもnodejsしか使えないので除外、 AWS Lambdaが選択肢となる。

Tensorflowガンガン肥大していくが、学習はともかく認識時に必要最低限のモジュールだけを切り出したい
— ふわこ (@yurfuwa ) 2017年11月8日

このようなニーズがある。しかしAWS Lambdaには 50MB制限というのがあり、ひとつのLambda関数においての容量制限が厳しい。

ServerlessでTensorflowやろうと躍起になってたんですが、tensorflowどころかnumpyやらscipyやらが既に重すぎてaws lambdaで死ぬし、.soをstripしたり.pyc消しても焼け石に水だった
— ふわこ (@yurfuwa ) 2017年10月26日

素直にサーバーレスは諦めて、GCP AppEngineあたりで手を打つのが打倒っぽい。
AWSさん、なんとかなりませんか、これ。