bookmarkいまさら聞けない Polymer 入門 - Polyfills は Web Components の夢をみるか

このところ Polymer ならびにその関連技術と格闘していたので知見を記録します。 Polymer とは Polymer Project Google 社のエンジニアが生みだした JavaScript ライブラリで、Web Comonents の要素技術を採用しつつ UI コンポーネントのセットを簡単に利用できるよう構築されたもの、というのが、雑な説明ですが Polymer のあらましです。Material Design な UI を簡単に導入できることもよく語られる特徴です。 Polyfills とは Polyfills とは、非モダンブラウザでもモダンブラウザに実装された技術 – HTML5 や JavaScript、CSS3 – が動作するよう、どうにかこうにか頑張ろうという人類の営みの総称です(たぶん)。したがって Polyfills という概念の内側に Polymer という実装が存在するという位置づけと言えるでしょう。Polymer は、ブラウザ、ブラウザのバージョン、デバイスという垣根を超えるものとして期待されています。あるいは、いました。 Polyfills について語るうえで切っても切れないのが、Web Components です。 WebComponents.org Web Components は新しいものではないため、以下を例とする詳細な解説が既に存在します。 Web Componentsが変えるWeb開発の未来 | HTML5Experts.jp 以下が Web Components の要素技術であるとされます。 HTML Templates HTML Imports Custom Elements Shadow DOM Polymer のいいところ 一般に Polymer 導入のモチベーションとなる点をあげます。

today 2016-10-14 Fri
bookmarkキャズムを大きく超えた Python - PyCon JP 2016 振り返り

PyCon JP 2016 に参加しました。Development Splint の日程をまだ残しておりますが Conference Day の振り返りです。ちなみに自分の活動振り返りおよび感じたことなどがおもで他の登壇者のかたのセッションのレポートはありません。つまりポエムです。 PyCon JP 2016 とわたし 昨年は以下のエントリにて、CfP だせばよかったかなとぼやいていた次第ですが、 PyCon JP 2015 振り返り コミュニティのライフサイクルについて - Librabuch 今年はイベント開催中の(会社的な)状況がまったく見えなかったので CfP を見送ってしまいました。Lightning Talks については、ネタが思いつけば手を上げたかったのですが、至らず。いま思えば SymPy ネタなどで攻めていけばよかったですね。PyCon JP 2017 ないし、APAC で CfP 出そうかなとは考えています。 今回、PyCon JP としても初めての試みであった Product Fair の モデレーターをつとめる機会を賜りまして、セッションという意味での活動は Product Fair が主でありました。 Product Fair を終えて 上述のとおり Product Fair の モデレーター を担当しました。今回の機会を賜りましたことに関係者の皆様へは心よりの御礼申しあげます。 過去のモデレーター経験というと エンジニアサポート CROSS 2015 での Python コミュニティの集いが印象深いです。 「Webアプリケーションから機械学習まで ~ PythonとPythonコミュニティの2015年大展望 」レポート:エンジニアサポート CROSS 2015 レポート|gihyo.

today 2016-09-23 Fri
bookmarkGo言語で Elasticsearch Index の再構築を行う

Elasticsearch で Index の再構築を行う場合、ダウンタイムを低減するために Alias 機能を利用するのが常道のようです。 Index Aliases and Zero Downtime | Elasticsearch: The Definitive Guide [2.x] | Elastic Elasticsearch インデックス・エイリアス — Hello! Elasticsearch. — Medium 今回 Elasticsearch を Go言語で利用するにあたり、elastic を利用します。elastic は Elasticsearch の クライアントライブラリです。 olivere/elastic: Elasticsearch client for Go. Go言語向け Elasticsearch クライアント Elastic の紹介とコントリビューション | カメリオ開発者ブログ なお、Elasticsearch は REST API が整備されているので、ライブラリ や SDK がなくとも利用は平易です。JSON の処理を手間に感じるようであれば、ライブラリの利用を検討するとよいと思います。 アイデア概要 Alias を利用するにあたり、Index の命名を以下のようにします。 Index名 = Alias名 - タイムスタンプ (などのなにか) 具体的な状態を以下に示します。

today 2016-07-03 Sun
bookmarkAWS Lambda で本番/検証環境を切り替える

AWS Lambda で本番/検証環境を切り替える場合、いくつかの手段があります。今回はContext オブジェクトから得られる関数名を利用するアプローチを紹介します。なおコード例は Python です。 前提: AWS Lambda に環境変数はない AWS Lambda に 環境変数はありません。機能追加が待ち望まれる今日この頃ですが、外部サービスのトークンなど、セキュリティ上の観点からソースコードに埋め込みたくない情報を利用する場合は、AWS KMS を利用するのが宜しいと思います。 本番/検証環境の切替方法 ところで、ソースコード中で $ENV などの環境変数の値に応じて、設定ファイルの読み込み先やログ出力のレベルを変更するなど、プログラムの動作を変更したい場合があります。 上述のとおり、AWS Lambda では環境変数は利用できないので、どこかから情報を取得する必要があります。 1つの方法として、Build/Deploy のプロセスの中で値を変更する策が考えられます。環境毎に設定ファイルを用意しておき、ファイル名を変更してもよいかも知れません。しかし、CI サービスを利用しない/できない場合や、その他要因でこの方法がとれない場合、以下の方法を検討してみてください。 context.function_name の利用 The Context Object (Python) - AWS Lambda AWS Lambda の Entry Point (標準では lambda_handler()) へ渡される2つのオブジェクトのうち、context からは AWS Lambda の環境に関するさまざまな情報を取得できます。内容は上述の公式ドキュメントが詳しいです。 本番/検証環境それぞれで別の Function として Deploy している場合、動作の切替判定に context.function_name が利用できます。 def lambda_handler(event, context): if context.function_name == "your-awesome-function": log_level = "ERROR" elif context.function_name == "dev-your-awesome-function": log_level = "INFO" else: log_level = "DEBUG" Unit Test AWS Lambda は特性上、手元に実行環境がないため、簡単なスクリプトでも Unit Test を準備しておくことをおすすめします。Unit Test では、Context オブジェクトは以下のように生成し、lambda_hanlder() に渡します。

today 2016-07-02 Sat
bookmarkPython で パッケージを vendoring しつつ AWS Lambda へデプロイ

Glide で Go 言語のパッケージ管理と vendoring - Librabuch で書いた vendoring のプロセスは現状そこそこうまく回っています。 最近 AWS Lambda のコードを Python で書く機会が多いのですが、ここでも vendoring することにしました。 課題 AWS Lambda で Python の サードパーティ・パッケージを利用する場合、デプロイファイル群の中にパッケージを含める必要があります。よくサンプルでは、プロジェクト直下に pip install requests -t . などとしたのちにプロジェクトのディレクトリごと zip で固める方法が提示されます。 元々、関係無いファイルが含まれるディレクトリごとデプロイするのはあまり上品ではないなぁと思っていたので、対象物だけ明示的に指定するようにしていたのですが、依存パッケージに変化があった際にデプロイスクリプトを追従させるのも手間でした。 解決案 上述のとおり、Lambda へのアップロードにはパッケージを含める必要があるので、vendoring を行ったうえで、vendoring ディレクトリをデプロイファイル群に含めるようにします。 vendoring は以下のコマンドで実行できます。 mkdir ./vendor pip install -U -r requirements.txt -t ./vendor # もちろん個別指定でも OK # pip install -U requests -t ./vendor vendor ディレクトリを認識させるために、lambda_function.py にコードを追加します。 import os import sys # 以下の行を追加 sys.

today 2016-04-29 Fri
bookmarkAWS Cognito User Pools は人類待望の IDaaS かも

引き続き主語大きめでお届けしております。 人類に IDaaS は早すぎた話 で IDaaS について触れました。昨日、Amazon Web Service から関連するリリースが出ました。 New – Your User Pools for Amazon Cognito | AWS Blog これまでの Cognito これまでも Amazon Cognito は、モバイルアプリや JavaScript アプリケーションから、AWS のサービスにアクセスするための認可・認証の機能を提供していました。しかし、ユーザーのパスワードや属性情報を Cognito が保持できるわけではありませんでした。また、Webサービスにおける一般的な認可のための機能やフロー – パスワードの複雑性の管理や Emailアドレス確認のプロセス – は提供されていなかったため、いわゆる IDaaS とは同カテゴリながら少し異なる位置づけでした。 これからの Cognito User Pools の登場によって、Cognito を本格的な IDaaS として利用開始できることが期待されます。 他の IDaaS に対する優位性は、User Pools が AWS の中に存在するという点に尽きます。サービスの継続性や堅牢性については相当のレベルで担保されることになると考えて差し支えないでしょう。一方、SDK 以上のツールは今後も提供されないと考えられるため、Auth0 の Lock のようなエレガントな認証インターフェースを実現したければ自前で実装するしかありません。この点については他の IDaaS に優位性がありそうです。 IDaaS についての補足 IDaaS というワードで調べると、サービスの種類はそこまで多くありません。しかし色々調査した結果、 BaaS や mBaaS のプラットフォームの中にユーザー認証機能があり、IDaaS の役割の一部または全部を兼ねているケースのほうが多いことがわかりました。例えば、Firebase や ニフティクラウド mobile backend などが該当します。IDaaS の機能のみが必要であれば IDaaS を、BaaS的ななにかも必要であれば BaaS も含めて利用サービスを検討するのが良さそうです。

today 2016-04-21 Thu
bookmarkAmazon CloudFront Origin Path と Invalidations の関係

Amazon CloudFront の Origin を Amazon S3 に設定し、かつ、Origin Path が root (S3 Bucket 直下) ではない場合、Invalidations の Path との関係が気になっていたのでその検証結果の備忘録です。 結論としては、Origin Path のディレクトリは含めずにその直下から Invalidation の Path を指定するのが正しいようです。 まとめると以下です。 https://librabuch.jp/index.html に対して Invalidations を行う場合で S3 Bucket に www ディレクトリを作成し、CloudFront の Origin Path を www/ に設定している場合 Invalidations の Path は /www/index.html ではなく /index.html と指定する。 なお、/ と /index.html は当然異なるので、https://librabuch.jp に対して Invalidations を実行したい場合は path を / に指定する必要があります。

today 2016-04-09 Sat
bookmarkGlide で Go 言語のパッケージ管理と vendoring

Go 言語の vendoring ツールとして Glide を使い始めました。 Masterminds/glide: Package Management for Golang vendoring とは vendoring とは、アプリケーションが依存する 3rd-Party パッケージ/ライブラリのソースコードそのものを自身のレポジトリに含めて管理する試みのこと、を指す用語の模様です(たぶん)。 Node.js における package.json に依存関係が書かれている状態だけでは vendoring ではないです。node_modules ディレクトリ自体をレポジトリの管理対象に含めることで vendoring ができている状態、と言えるようになります。 Node.js (というか npm) に限らず、node_modules 的な役割のディレクトリは .gitignore で無視するのがよくあるプロジェクトの管理方法です。vendoring 自体の厳密な定義の話や、vendoring することの是非については言及の対象外として、Go 言語で vendoring を行う話に進めます。 2点だけ補足をすると、Go 言語は外部パッケージを go get で Github などのレポジトリから直接ソースコードを取得してくる方式になっており、元来 vendoring とは相性がよいものでした。加え、npm の left-pad 問題もあり、多少プロジェクトのレポジトリが肥大化したとしても依存しているコードは自身の責任で保全できていたほうがいいだろうと考えたのが、vendoring を始めた動機です。 Go 1.6 のパッケージ管理について Go 1.6 からの標準機能として、コンパイラが $GOPATH 以外に ./vendor ディレクトリ配下を探索するようになりました。この点の歴史的経緯については既に情報が多いので割愛します。これから Go を始める方はそうなったことだけ把握していれば問題無いと思います。 参考 : Go言語のDependency/Vendoringの問題と今後.gbあるいはGo1.5 | SOTA この標準機能に、いまでは主要な Go 言語の 3rd-Party パッケージが対応しています。人気があり現在もメンテナンスが続いていそうなパッケージをいくつか列挙します。

today 2016-04-09 Sat