AWS Lambdaでのネイティブコード実行
なんと、まだ日本にいます。12月下旬からなので既に2ヶ月以上。流石にそろそろ帰米します。
さて、AWS lambdaのこと。
Lambda Execution Environment and Available Libraries - AWS Lambda
If you are using any native binaries in your code, make sure they are compiled in this environment. Note that only 64-bit binaries are supported on AWS Lambda.
公式のドキュメントの冒頭、初め何を言ってるのか分からなかった。ネイティブバイナリって何のことだろうかと。
調べると要はLambdaの設置Zipパッケージの中にネイティブバイナリを置いておいて、Pythonやnode.jsで書いたLambda関数から呼べるということでした。スピンアップ効率にはちょっと疑問あるけど、腹に抱えこんでさえいればコマンド叩けるんだね。
hugo-lambda/RunHugo.js at bb3709a27a0c19fd6bdfb712305a8ecfdc4c3a59 · ryansb/hugo-lambda · GitHub
function runHugo(next) { console.log("Running hugo"); var child = spawn("./hugo", ["-v", "--source=" + tmpDir, "--destination=" + pubDir], {}); child.stdout.on('data', function (data) { console.log('hugo-stdout: ' + data); }); child.stderr.on('data', function (data) { console.log('hugo-stderr: ' + data); }); child.on('error', function(err) { console.log("hugo failed with error: " + err); next(err); }); child.on('close', function(code) { console.log("hugo exited with code: " + code); next(null); }); },
この例示で抱え込まれている「hugo」はGoで書かれているOSSなので、LambdaがGoに対応した今ではもっと直接的なアプローチにも道が開きましたが、これは一つのベストプラクティスだと思う。
Python速修
スーパーバイザーで入ったプロジェクトがPythonメインだったため、これまでずっと食わず嫌いだったPythonを速修しています。初めてPythonの名を知ったのは間違いなく10年以上前、もしかしたら15年ぐらいかもと思いますが、オフサイドルールと呼ばれる改行とインデントでブロック認識させる書き方がなんか馴染めなくてHello World以前に避けてました(たとえばYAMLよりJSONの方が好き)。時が過ぎ、GoogleがAppEngineをPython版でリリースした時も遅れてJava版も出たし、クラウドでの機械学習等についてはその機運が高まっている時にそもそも自分が手を動かすところにいなかった。つまりこれまでは避けてもなんの支障もなかった。
しかし、今やAmazonやGoogleやその他のクラウドでもPythonが第一言語なのかなというぐらいにどこでも対応されているのでやって無駄はなかろうし、とにかくプロジェクトの採用言語がすでにPythonだったから避けられないだろうと、重い腰あげて学んでみました。隙間時間での取り組みでカレンダーとしては年明け約二週間、ここまでで正味3日ぐらい。
Python環境を作る
MacにHomeBrewでpyenv入れてPython 3.6.4をインストールしました。その後のことですがリントのためflake8も入れた。
AtomでのPython環境作り
- autocomplete-python:識別子の自動補完。やってみたら完璧レベルに補完してくれて快適
- python-indent:オフサイドルールのためのインデント処理。これ大事。
- indent-guide-improved:インデントを可視化する。これ重要。
- linter-flake8:当然のリントツール。私はこれが無いとアプリケーション書けないと思ってる。
- platformio-ide-terminal:シェルがエディタにくっついていると便利。
Pythonチュートリアル
- 作者: Guido van Rossum,鴨澤眞夫
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/03/24
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
まずは移動時間や寝る前とか、待ち合わせ前に喫茶店で時間調整しているときに本を一冊。このPythonチュートリアルはどうやら公式的なものっぽい位置付けで、常にWEBに上がってるものの製本版なのですが、私も中高年なのでスクリーン長時間みてると目がしょぼつくから紙で購入。
Pythonの公式姿勢が此の期に及んでまだ控えめなのか、他に書けるプログラミング言語がしっかりある人向けにしか書かれていない。すなわち非オフサイドルールなC系文法に馴染んでいる人にPythonすごいよとアピールする本。結果としてチュートリアルにして全く入門本でなく、Python初心者に向けていて全くプログラミング初心者には向けていないのが私にちょうど良かった。
- この本でだいたいPythonの基本的なことを知ることができるんじゃないかな?地平線を知らないので断言できないが。
- 4章 制御構造、5章 データ構造、6章 モジュール、これらでPython書ける気がする。実際書けた。
- 続いて7章 例外処理、8章 クラス、で他言語との文法の違いだけ追えば、既存コードを読める。
- 薄い本なので正味1日ぐらいで終えられる。
既にPythonが素敵だなあと思い始めてきた。私はGO言語を書いたときにタプルとスライスを知って便利だと思ってたのだけど、どちらもPythonにしっかりあって素敵。タプルの代入で開くやり方で関数戻り値の書き方もGO言語的(もしくはSwift的とも)にできる。
Fluent Python
Fluent Python ―Pythonicな思考とコーディング手法
- 作者: Luciano Ramalho,豊沢聡,桑井博之,梶原玲子
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/10/07
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
amazon.co.jpでポチった時には気がつかなかったが、これは800ページ弱と厚く、昔ながらのコンピューター書籍サイズな大型本でした。普段持ち歩く重さでは無いです。
まだ読み始めですが、これは超良書。当然プログラム入門本で無くPython初心者向けでもないのですが、かといって普段づかいの実践的なことが内容なので興味を逸らさず、5,800円の書籍価格と読むために係る自分の時給を足しても久しぶりにTOCの良い本だった。マストバイ。
- やっぱりPythonはそのデータ構造のところのテクニックがユニークだし大事。
- 関数型プログラミングできる。データ構造のところで知ったデリゲートパターン(?、つまりはダンダー)を活用したのも素敵だけど、最近の私はTypeScriptでもクラスベースを避け関数型風に書くのが好きなのでPythonでもそう書けるのは嬉しい。
- 普通の自然科学書としても読んで面白いレベル。
- まだまだ読み進める先の先には、コルーチンとか非同期処理についてもちゃんと章があった。今読んでるところから400ページぐらい後ろなので目次しか見てないけど。
PyCharm
PyCharmはJetBrainのシリーズ商品でPythonのIDEですがこちらにコミュニティ版として無料の奴があった。IDEとしてJetBrainの製品群は完成度レベルが高いのですがPyCharmはいかに?Atomで環境作ったばかりで痛みがまだ無いために試していない。この後、速修時期を終えてもまだしばらくPythonやることあればダウンロードしたり課金したりするかもしれない。
ちなみにWEBフロントを書く用にはWebStormがお気に入りでずっとサブスクライブ課金しています。WebStormは初期試用無料はあるけどコミュニティ版はないってのがエグいな。それだけ需要があるってことなのでしょう。
現時点での感想
Python面白い。特にデータ構造周辺が素敵。まだPythonで非同期処理を書く局面に到達できていないのですが、クラウドAPIコールで必ず出てきますので。。。Pythonが面白いとはいえ、まだ私はTypeScriptがより好きだな。画面をPythonで書くことはおそらくこれからもないと思うので、サーバ&クライアントを両方書けるTypeScriptがまだまだラブ。
Alexa...アレクサ?
Amazon Echo Dot (2nd Gen.)を買いました。日本では招待制購入みたいですが、米国では有り余っているのか値引きして$30になった上、オーダーしたらFree-2day指定のはずが翌日届きました。当然英語版ですが、いきなり日本語化します。
- 箱から出してmini-USB電源ケーブルを繋ぐ
- https://alexa.amazon.co.jp をPCブラウザで開き、日本のAmazonアカウントでログイン
- 画面の手順説明にしたがって、Echo DotにWiFiの設定をする
- 言語に日本語選択肢が無いので英語のままでセットアップ。その後10分ぐらい放置してたらファームのアップデートが始まった
- 数分でファームアップデートが完了すると、日本語が選べるようになる。
- PCブラウザの設定画面で言語を日本語に設定する。
- 住所はAmazon.co.jpアカウントに残ってた日本の最後住所になってたので、今住んでる米国住所を入力する。
- 気温は摂氏、長さはメートル法に設定する。
- ウェイクワードを、AlexaからOK Googleに変更しようとしたら、ダメじゃん。Amazon的に用意されているワードからのみの選択だった
OK。Alexaからアレクサに帰化しました。
ここのところ数ヶ月、小さな業務機能を作るのにサーバレスはじめて、実装はServerless.com + TypeScriptで、クラウド環境はAmazon Lambda + Amazon RDS + Amazon SNS + Google Drive + Google Sheetsというのを一通り習得してました。今回Echo Dotを買ったのはここ1ヶ月ぐらいSNSで話題になってたのもありますが、Lambdaのドキュメント見てるとAlexaのインターフェイスががっちり定義されていたので結構手軽にAlexaスキルを作れそうと思ったからです。
時期的にAdvent Calendarを書けばよかったのだけど、そこは激しく色々嵌ってたので、それどころじゃなく。今週から2ヶ月日本へ出張のため年末年始は日本のカレンダーで休みなので、アレクサのスキル書いて遊びながらサーバレス開発の備忘をしてこうと思います。
続 keyof T
keyof Tを用いて連想配列でアクセスする際の縛りを前に書きましたが、もっとスマートな書き方を思いついたのでメモ。
test ('power of keyof', () => { function checkObject<T>(props: T): { [N in keyof T]?: string } { return Object.keys(props).reduce( (prior, key) => { // propsを型変換するのではなく、連想配列キーを「as keyof」でTへ縛る。 const value = props[key as keyof T]; if (typeof value === 'number' && value > 0) { return prior; } return { ...prior, [key]: `${key} is invalid.` }; }, {}, ); } type Target = { first: string, second: number, third: number, fourth: boolean, }; const target: Target = { first: '', second: 10, third: -3, fourth: true }; const result = checkObject<Target>(target); expect(result.first).toBe('first is invalid.'); });
変えたのは一箇所で、props[key as keyof T]のとこ。propsを「as { [key: string]: any }」で型変換するのではなく、連想配列キーを「as keyof」でTへ縛る。この応用で、関数の引数とかで、name: stringがあったときに、name: keyof Tというのも有用かと思います。
function foo<T>(obj: T, name: keyof T): any { return T[name]; }
コードとしてはあまり意味がないけど、これでしょうがなくanyで受けてたところが改善されます。
High Sierraでgit不具合
日本での週末、まだ時差ボケですごく早朝に起きてしまう。
WEB見ててもSierraの時のようには悲鳴があがってない気がしたので、特に検証もすることなくHigh Sierraにアップグレードしました。噂のAPFSなる新ファイルシステムに何のためらいもなく変更されています。見ると構造が物理-コンテナ-ボリュームと層ができていて、未マウントで700MBオーバーで何かがあったり、VMとか表示されているのが見えます。うっすらと互換性に危険な匂いですね。
で、一通り普段使いのアプリを動かして見たら、WebStormでエラーが出た。
4:38 Can't start Git: /usr/bin/git Probably the path to Git executable is not valid. xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun.
WebStormのIDE自体は問題なさそうなんだけど、Gitでエラーを出したみたい。直下でxcrunが無いと言われていて、それはcommand line toolsファミリーとしてエラーメッセージからすぐ面の割れるヤツです。同様な事例がMacOSアップグレード時に頻出してましたので、これなら慌てない。
$ xcode-select --install
私は今はフルのXcodeは入れてなくて、Toolsだけ。それをボタンで選んでクリックするとしばらく時間かかりますがToolsの再インストールが完了。そのままWebStormの再起動もなく完治しました。
治ってしばらくしたら、App Storeでもcommand line toolsのアップデートを促してきましたが、アップデート進めてもすでに入れているのでインストーラーが必要ない旨の表示を出してきて終了。いまのところファイルシステム起因等のヤバイヤツは見つけてません。大丈夫っぽい。
.d.tsをどうつくるか
Angularが教えてくれた。
TypeScriptの学びの中で、他のライブラリの型情報をどう手に入れるかは説明されているのだけど、ライブラリとしてどのように型情報を提供するのかはあまり説明されていない。ECMAScriptで書かれたライブラリに後付けでindex.d.tsだけ書かれ、それが@typesに登録されているというのがよくあるケースだけども、そもそもTypeScriptで書いてる場合はどうしたらよいのか。まさか二度手間にチマチマ書きおろすわけもなかろうと調べてるうちに、事例としてとてつもなく巨大なのがあるのを思い出しました。Angularです。たぶんこいつはTypeScriptで書かれた世界最大のソフトウェアなんじゃないかなと思います。実際に、Angularはチマチマindex.d.tsを書くなんてことはしていなく、以下のようなindex.tsを用意しています。
// index.ts export * from './public_api';
このexportしている元を辿って行っても、何段階かは同じようにexport * from XXXというのが徐々に増えながら続いたりもします。そしてこのソースコードを以下のコンパイラオプションで変換する。出力先は私はlibにしましたが、これはお好きなもので結構です。
// tsconfig.json { "compilerOptions": { "outDir": "lib", "declaration": true, } }
declarationスイッチをtrueにすると、全ての.tsファイルから.jsファイルと.d.tsファイルのペアを生成します。index.tsをコンパイルすると、index.jsとindex.d.tsを作ってくれる。そしてこのできたindex.d.tsをpackage.jsonで明らかにすればよい。
// package.json { "main": "./lib/index.js", "types": "./lib/index.d.ts", }
これでライブラリを利用するのがECMAScriptからでもTypeScriptからでも可能になります。
React v16、Enzyme v3
昨日から日本に来てます。
さて、炎上の末にライセンスがMITになったReactのv16がリリースされたと同時期に、Enzymeもv3がリリース。v3からsetupに変化がありました。
Working with React 16.x · Enzyme
説明とおりにしたけど動かねー。CSSセレクターで引っ掛けてたパターンが全滅。@types/enzymeはエラー、さらにはReact本体も警告だしている。
Warning: React depends on requestAnimationFrame. Make sure that you load a polyfill in older browsers. http://fb.me/react-polyfills
React 16 JavaScript Environment.md · GitHub
いろいろ読んで解決しました。
requestAnimationFrameの対処
// package.json部分 "jest": { "moduleFileExtensions": [ "ts", "tsx", "js" ], "setupFiles": [ "raf/polyfill", "./tools/enzyme.setup.js" ], "transform": { "^.+\\.(ts|tsx)$": "./node_modules/ts-jest/preprocessor.js" }, "testMatch": [ "**/__tests__/*((Test|Spec)\\.(ts|tsx))" ] },
yarn add raf -D をしたあとで、package.jsonのjest.setupFilesに、raf/polyfillを追加すると警告は消える。rafはレガシーブラウザでrequestAnimationFrameを埋めるライブラリ。JsDOMがEnzymeの依存で入ってくる古いものだったので、試みに最新に上げてもみましたが、このrequestAnimationFrameは手当しないとダメだった。
@types/enzymeの対処
node_modulesの中の@types/enzymeを見ると、自身の腹にnode_modules/@types/reactを抱え込んでいた。これが悪影響するので抱え込んでるnode_modulesを削除で、問題解決。デプロイのミスかな?
Enzyme v3へのマイグレーション
Migration from 2.x to 3.x · Enzyme
まず説明されてることとして、Jest起動時に走らせるsetupでEnzymeのアダプターなるものを導入する。
// ./tools/enzyme.setup.js // Enzyme v3かつJsDOM v11 var Enzyme = require('enzyme'); var Adapter = require('enzyme-adapter-react-16'); Enzyme.configure({ adapter: new Adapter() }); const { JSDOM } = require('jsdom'); const jsdom = new JSDOM('<!doctype html><html><body></body></html>'); const { window } = jsdom; function copyProps(src, target) { const props = Object.getOwnPropertyNames(src) .filter(prop => typeof target[prop] === 'undefined') .map(prop => Object.getOwnPropertyDescriptor(src, prop)); Object.defineProperties(target, props); } global.window = window; global.document = window.document; global.navigator = { userAgent: 'node.js', }; copyProps(window, global);
「the internal implementation of enzyme has been almost completely rewritten.」とのことですが説明されていたことは私の問題には関係なく、調べて見ると次と同じ現象?
テスト対象のノードを取りやすくするために、id="0"、id="1"、...、id="7"とidに数字を使ってたのですが、form.find('#0')とすると爆発。これはidをid="zero"、id="one"、...、id="seven"と文字で振り直して、form.find('#zero')とすればOK。その後にIDは数字で始まっちゃダメなルールだということをスレッドで教わりました。v2まで通ってたほうがバグでv3で修正されたとの結論。
Reactライクライブラリ
EnzymeのアダプターはReactの各バージョンの挙動の違いに対応するものを整理したと同時に、将来はReactライクライブラリの対応もしたいとのことが書いてありました。PreactやInfernoってこのマイグレーションガイドで初めてしりましたが面白そう。material-uiやreact-routerなどエコシステムのこともあるので近日の現実解ではないけど、JSX変換や基本的なAPIのところをカバーして差し替え可能にするというのはこのEnzymeだけでなく、TypescriptやBabelにもすでにあるので将来無謀なことではないように思います。