Wranglerを触ってみたので、その感想などを書きます。WranglerはAWSの各サービス上にあるデータを操作するためのPythonライブラリです(つまりサービスではない)。Redshiftなど)へとアップロードすること、またその逆の作業が行えます。このような操作は各チームでライブラリを用意するか、個々のデベロッパーが都度開発することで実現されることが多かったでしょう。Wranglerが提供されたことにより、そのような手間を省くのに加え、データのやり取りを行う際のベストプラクティスに沿った実装を利用できる様になることが期待できます。基本的な使い方はリポジトリの利用例に十分に紹介されているので、S3とDataFrameをやり取りする際の細かい挙動について気になる点を1つだけ紹介します。pandaspandasとS3のやり取りとして、実験の途中や、バッチの実行結果として生じたDataFrameをS3に保存する(したい)というケースは多いかと思います。Wranglerはこれをサポートしています。この結果は少々直感とは異なり、以下のようになります。WranglerはデフォルトでS3へのアップロードを実行環境のCPUのコア数分だけ並列で行います。返り値として得ることができますが、別の文脈(別のプログラムやNotebook)からアクセスし直すのはやや煩雑でしょう。テーブル化し、即座にAthenaでクエリをすることが可能です。Wranglerに任せることができます。データカタログに所望のテーブルが自動で作成されます。次のようにしてAthenaにクエリを発行することができます。Athenaで扱うデータにとってはほぼ必須となるパーティションの制御もお手の物です。DataFrameをアップロードする際に、パーティションのキーとしたい列をDataFrameに予め用意してやることで、Hive式の配置でデータを格納することができます。month=9/うーん素晴らしい。Wranglerを使って即クラウド、再利用する際は同じ名前(パス、database、table)で呼び出して使う。Wranglerが提案するプラクティスはこのようなものではないでしょうか。WranglerはAWS環境を前提とすることでより強力な機能を提供できたとも捉えられるでしょう。最後にこれは余談ですが、クックパッドにいたころに作った、各種データソース(Redshift、MySQL、PostgreSQL、S3など)からデータを読み出す作業をライブラリ化したものがあります。Wranglerの登場によって、ほぼ完全に「しょぼい版」になってしまいましたね。SNSログインとネット上の情報についてemailとpasswordを二度入力させている間に貴重な新規ユーザーを離脱させてしまう代わりに、LINEやFacebookの見慣れたUIとホカホカに温まった(line.meやfacebook.comの)cookieを使ってポチポチサクサクと認証に必要な情報を集めたい。そんな要望を実現するために精一杯頑張るのもエンジニアの仕事です。(スタートアップにいればそんな要望も実装側の都合も頑張りもまるっと自分事ってこともあるでしょう。login"でググってみました。以上によりユーザーを「#{userId}さん」として認証する!(簡単!)といった手法を紹介するものでした。一方で、「OAuth使ってログイン実装しちゃまずいでしょ」という風のうわさも耳にします。(恥ずかしながら私の認識もその程度でした。)このような状況で、いざ自分で、一般ユーザーに公開するサービスに、LINEログインを実装する、という必要に迫られてみるとなかなかに心細い。そこで、OAuthだとかOIDCだとかLINEでログインだとかについて、それを認証機構としたRailsアプリケーションを一般ユーザー向けに公開するのに十分な自信を持てる程度まで調べました。以下は調べた結果得られた知識のうち、ネット上の情報とのダイバージェンスが大きいものを抜粋してまとめます。middlewareで、プログラミング言語のようなものです。middlewareです。GitHub等)と連携して認証を行う方法を、omniauthを使う開発者側からは幾分透過的に扱えるといったものです。/loginを通してユーザーのID(A1B2C3)が取得でき、それをよしなにやって(ユーザーを作ってセッションを作って...)に保存して「A1B2C3さんようこそ」となることが出来ます。風のうわさではこれはまずいらしい。出来た」ということにはならない」ということです。意味が違うからダメというだけで、神経質なエンジニアだけが気にする問題だ、という認識はやや危険であり、OAuth{,2}が認可(〇〇してよいかを決める)を行うためのものである以上は、それに基づいた実装が認証に必要なスペックを満たしているという筋合いも保証もないわけです。実際にこのような認証を行っていたことで生じた脆弱性(OAuthのせいではないが)があり、それをサポートするためにOAuthの拡張が(何度か)行われました。Connectに従うべきです。これは紛れもなく認証のための標準化された仕様であり、OAuthの仕組みを利用し、その上にいくつかのスペックを追加することで認証のスペックとして成立させています。細かい説明は参考文献に任せるとして、簡単には、OAuthによってアクセストークンを得る際にIDトークンが併せて返却され、その中身のsubという要素がユーザーの(IdP(LINE等)側でローカルに一意な、再利用されない)識別子であるということになります。これを以て(IdPへの信頼を前提として)、ユーザーを認証することが出来ます。omniauthに話題を戻すと、omniauth-lineもomniauth-facebookもomniauth-twitterも、ユーザー情報エンドポイントのような場所からidとかuserIdとかを持ってきて、uid(つまりこの名前で認証をしたいということだ)として認めています。Connectの名のもとに正しいとは言えません。Connectに準拠した認証を以て行うようにしましょう。(念の為ですが、omniauth-*の実装が悪いと言いたいのではなく、これを認証機構として取り入れてしまうことがまずくないとはいえない、だからみんな自分でちゃんと気をつけよう!ということです。継承した自前のstrategyを書いてやることでしょう。Connectに準拠したクライアント側の実装はそんなに難しくはありません(IdP側は大変そう)。Scopeにopenidを追加して、アクセストークンと一緒に返ってきたid_tokenをjwtデコードしてjwtのsignatureを検証してissとaudとexpを検証してsubをuidとするというだけです(と思う...)。Cognitoとか)それも不安(あるいは面倒)ということであれば、準拠した実装を使うことにしましょう。Connectに準拠したIdPとの連携をサポートしています。Connectに準拠しており、我々はCognitoを設定して、「認証して」だとか「IDをオクレ」だとかいうだけで、認証情報として認めることの出来るIDが降ってきます。認証の実行に掛かるオーバーヘッド(トークン取ったりほどいたり)をクラウドに逃がせる利点もあるし、今どきのやり方としてはおすすめ出来ると思います。細かいやり方はどうかドキュメントにおまかせします。(力尽きた)以上、各自頑張りましょう。10:46今からRailsでSNSログインを実装したい人へTweet広告を非表示にするもっと読むコメントを書くプロフィールid:ayemos株式会社ポインティのCTOとフリーランスをやってます。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。