雑食日誌スマートフォン用の表示で見る雑食日誌Vue.jsとServerless。PythonDjangoの管理画面のパスワードリセットにメールアドレス認証を実装する機会があったので、記事にまとめてみました。公式ドキュメントを参考に実装しています。DjangoGitHubに実装を公開しています。github.com目次Djangoの初期設定URLの追加Gmailで送ってみるDjangoの初期設定Djangoのマネージドコマンドを使ってプロジェクトの初期化を行います。django_admin_emailURLの追加Djangoは管理画面のパスワードリセットのURL設定を追記するだけで設定できます。テンプレートで決められているため、変えられません。urls.pyに以下を追記する。アクセスするとログイン画面にパスワードリセットのリンクが追加されます。管理画面のログインのテンプレートHTMLを確認してみましょう。URLに登録されているかで、リンクを出し分けていることがわかります。%}Gmailで送ってみる開発環境でのメール送信はc-bataさんの記事が参考にになります。ここではGmailを使ったメール送信を設定してみます。settings.pyに以下の設定を追加します。'587'送信する前にGoogle側のパスワード設定を変える必要があります。安全性の低いアプリの許可」をONにします。実際に送られたメールはこちら。あなたのアカウントのパスワードリセットが要求されたため、送信されました。チームローカル感丸出しですが無事に送れました。SESを組み込んだメール送信もやってみたいです。Japanに参加してきました。実業務でのお話やVueのこれからのようなコアな話まで聞けたので、レポートにまとめたいと思います。キーノートEvan氏によるVue3.0の展望についてでした。以下の変更が加えられます。API何点か気になった話を書いていきます。Shakingが出てきました。バンドルせずにビルドできるそうです。メンテナンスのしやすさではデバッグ機能の追加がありました。Devtoolの確認に加えて、イベントなどのブレークポイントを見れるようになるのはでかいですね。APIはReactで出てきた機能らしいです。アフターパーティーで詳しく聞けました。ストア管理するほどでもない状態を楽にできるそうなので、Reactを触って先に体験したいですね。勉強不足で多くを理解できなかったですが、復習して3.0を待ちたいと思います。アプリだけではなく、クーポンやスタンプのページはVueで開発されているようです。新規開発もNuxtやVueを用いて開発されてるみたいですねー。ブースではVueのクイズに答えると抽選でVue.js入門をゲットできる催しをやってました。抽選は逃してしまいましたが、面白い企画でした。ScouterさんNuxtMeetUpでおなじみのScouterさんの発表でした。みなさんだいたい2014年のVueがメジャーバージョンになる前から使い始めてますね。Scouterさんはエンジニア10名で継続的にプロダクトをローンチしていてすごいです。Reproさんラストは普段もくもく会でお世話になっているReproさんのセッションでした。最初はjQueryで開発されていたものをVueで書き換えたということでした。jQueryからの移行しやすさはVueの魅力の一つなのかなと思いました。これからspeakerdeck.comWebComponents(以下WC)とVueとの共存についてのセッションでした。WCのメリットは以下のようです。CLI3はWCへのbuildをサポートしているためビルド時にtargetオプションをつけることで動かせます。./src/App.vueそのため、Vueで開発してきたものをWCを用いて描画することが簡単にできます。WCはWeb標準機能のため、相対的に寿命が長く、激しい変更が少ないことが見込まれます。いつVueが終わってしまうかという心配事が減ることが期待できますね。WCはあくまでDOMの可視化にまつわる仕組みなのでアプリケーションフレームワークとしての機能は有していません。データ管理やイベントなどフレームワークとしてはVueが、UI部分はWCに置き換わるのが今後の展望とのことでした。WCのデフォルトでマテリアルデザインをサポートし始めたら強いですね。記法がVueに似ている(VueがWCに着想を得ている)とのことだったので自作アプリにも組み込みたいです。デザインと実装の統合slides.comデザインと実装に距離ができてしまう問題を解決するツールについてのセッションでした。デザインとフロントエンドの実装では以下の課題がみられます。デザインファイルと実装で使うツールが異なるデザインと実装の管理が重複する動的なデザインを考慮しにくい現在開発されていて、上記課題を解決しようとしているツールには以下があるそうです。XReactのコンポーネントを出力するそこでkatashinさんはSFCでデザインできるようにするツールを開発中でした。toolSFCをプレビューし、ドラッグ&ドロップやインスペクターでデザインを変更します。変更はSFCのファイルにも反映されて、デザインとSFCファイルの双方向バインディングが実現されていました。デザイナーにも使ってもらえることを目標にしているので、デザインツールで使えるような機能も考えているようです。実装はクライアント・サーバ型でできていて、SFCをASTに変換し、WebSocketを通してレンダリングされていました。クライアント・サーバ型のメリットは以下になるそうです。babelを使っていて、TypeScript対応もあるみたいですね。一人でパーサーを書いて、WebSocketを使い、デザインツールを追従していることが驚きでした。今後はコンポーネントカタログの自動生成も考えているそうなので、とても期待しています。デザインと実装の狭間デザイナーとエンジニア間の協業という観点のエモいお話でした。Designが主流になる中でデザイナーからコンポーネントベースの手法が適応されている背景があります。コンポーネントベースでデザインする上での難点は以下になっているそうです。学習コストが高いデザインの自由度が下がる認識が異なるコンポーネントはエンジニアの概念のため、デザイナーに適応することは難しいそうです。オブジェクト指向プログラミングでした。効率が上がるため現在では主流になっています。デザインの世界では構造化プログラミング的手法のため、いきなり実践するということは無理とのことです。そもそもデザイナーとエンジニアは責任が異なります。デザイナーはインターフェースの価値を高めて、ユーザーに届け、エンジニアは効率を重視し、保守性を高めています。そんな中での現実的な解決策は以下が挙げられていました。エンジニアがデザインを覚えるいい感じのツールを作る(さっきのトークの続きだ...)デザイナーの横でコンポーネントをひたすら写経する弊社ではエンジニアがコンポーネント化する作業を行なっているので、より良いプロセスを考えていきたいです。noteをNuxt.jsで再構築した話speakerdeck.comSPAからNuxtへ移行したためになるお話でした。noteは当初Angularで開発されていたようです。この時の技術選定はAngularのみメジャーバージョンに上がっていることが大きかったようです。SPAのみでは以下の課題がありました。初期表示速度の遅延コーディング規約などの負債フレームワークを変えてのフルスクラッチは難しいと思います。noteさんはCEOが技術よりということで理解が得られていました。Vueを選んだ理由は以下になるそうです。学習コストの低さドキュメントの充実度(日本語が充実)コミュニティの活発度が高い移行手順はページごとに社内リリースから初めて徐々に本番に移行していくやり方ですね。Designを取り入れていました。Vueを使って堅牢なシステムを作るときのベストなのかなと思います。Designは分子と有機体の違いがわからなくなりますね...Vuexの参照は有機体以上にしているそうです。ルールを明文化して、コードレビューの観点にすることが大事なんだと思いました。Bookを導入していました。私自身設定周りで挫折した経験があるのですが、Nuxt2.0になったことで楽になっているそうです。ストーリーをメンテナンスするのが大変なのと、通信周りのスタブ化が辛いため、対象を原子・分子に絞っていました。Lambdaの構成でした。mya-akeさんのブログで解消できるそうです。インフラ管理のコストやスケーリングを考えると良さそうですね。以下の欠点を超えられれば使いたいです。NodeのバージョンがLambdaに依存するデプロイできる容量が決まっているこれまでの移行プロジェクトはnoteのなかでまとまっています。note.muNuxtの導入を考えているのでとても参考になりました。テストspeakerdeck.comラストはコンポーネントテストのお話でした。コンポーネントの何をどこまでテストするかはいつも悩むのでノウハウを聞けてよかったです。単体テストを自動化するのは外部からみた振る舞いをテストしていました。「外部からみた振る舞い」は何かしらのインプットに対してアウトプットが期待とおりかチェックすることです。CSSEventStoreのアクションにまとめられていました。Lifecycleでは必要なデータを取得するぐらいなので優先度は低いそうです。他のテストに影響が出るので、場合によってはモックしてもよさそうですね。PropsやStoreはスナップショットテストを用いていました。コード修正の前後の差分を確認し、期待通りであればUpdateする機能です。今まで使いこなせていない機能なので活用したいと思います。Testにて行なっていました。スナップショットテストの応用で画像を取得して差分を出力する仕組みです。CIに組み込むことで、レビュー観点の一つになるため、レビュワーの負担が軽減するのが良さげです。レビュワーがチェックアウトしてビルド・確認をする手間が省けるのは大きいですね。ツールはStorybookとreg-suitoを用いていました。Testを使っていました。テスト範囲はクリックとinputイベントに絞っていて、難しいテストは実施しない選択を取っているそうです。変更に強くするためのテストであることを忘れずに自分のプロジェクトに適応していきたいです。まとめフロントエンドのカンファレンス自体初めてでしたがとても内容の濃い1日でした。実践的なお話をたくさん聞けたので、どんどん投入していきたいと思います。スタッフの方々本当にありがとうございました。Japan参加レポートTweet広告を非表示にするもっと読むコメントを書く2018-10-30GraphQLを試してみたGraphQLこんにちは。約半年ぶりの投稿です。最近AppSyncを触る機会があったので、基礎となるGraphQLを学びたいと思います。特定条件のリポジトリ数の取得まとめGraphQLとはGraphQLはフロントエンドがサーバのデータをいい感じに取得するためのクエリ言語です(怒られそう)。調べる限りは以下のような特徴がありました。APIで試してみます。GitHubはAPIのバージョン4からGraphQLを導入しています。v4検証環境GitHubのデベロッパーツールを使用します。GraphQLはエンドポイントをリソースごとに分けずにパラメータで指定します。向け、パラメータにクエリを入れています。単一のリソースfieldsから指定したキーの値を取得できます。現在ログインしているユーザのメールアドレスを取得してみます。fieldsにログインユーザー情報が入っています。クエリ内にパラメータ(email)を指定して取得することができます。引数を取ることができます。GitHubのDockerトピックに関連するトピックを取得してみます。オブジェクトのリストになっています。)を選択できることが異なる点ですね。使ってリスト値と欲しいパラメータを取得することができます。今回はよく使うDjangoRESTFrameworkのPR一覧とそれぞれのコミット数を調べてみます。あることと、最新の5つを取得するよう指定しています。DjangoRESTFrameworkのGitHubをみると正しそうです。PRのリスト値にあたり、その中でPRのNoやコミット数を指定しています。パラメータが入っているので、データを全て取得せずに総数を把握することができますね。自分でSchemaを定義する場合はクライアントが欲しい値を自由に追加することができます。特定条件のリポジトリ数の取得GraphQLのPaginationを使ってクエリ結果の総数を取得できます。Pythonで書かれているスター数1000以上のリポジトリが何個あるか調べてみます。GitHubで定義されているコネクションです。定義できるようになっています。取ることでリポジトリ数を取得しています。引数を変えて、色々な検索をかけられるのはよいですね。中心にGraphQLを試してみました。GraphQLのメリットはクライアントの負担が減ることなのかなという所感です。Schemaの定義はクライアントの要求を取り入れつつ、データベース内のモデルの知識が求められそうですね。その辺りも今後調べたいと思います。BacklogPythonエンジニア見習いのぬまやんです。今回はBacklogAPIのクライアントライブラリを作ってみました。Backlogの課題やプロジェクトをオブジェクトとして扱えるようにしています。今まで作りかけだった自作のライブラリにエキスパートPythonプログラミングの内容を実践してみたいと思ったことがきっかけです。ついてPythonのベストプラクティスをまとめていただいている本になります。単行本この商品を含むブログを見る作ったもの作成したライブラリはGitHubにて管理していて、PyPIに公開しています。実現したかったことはBacklogのプロジェクトや課題をオブジェクトとして扱うことです。そのため以下のような操作感にしています。issue.delete()エキスパートPythonプログラミングを参考にしたところPyPIのへのアップロード今回のライブラリの目標はPyPIにアップロードして、公開することでした。requirements.txtなど準備するものが多いです。本書にはこの設定方法について詳細や一般的な手段が記されています。本書内で何箇所か説明されている新しいPyPIはすでに公開されています。DescriptionについてMarkdownの対応も完了しています。対応方法はsetup.pyのsetup関数に以下を追加するだけです。long_description_content_type='text/markdown',コード管理手法コードの管理として、継続的デプロイが紹介されています。私はGitHubにてホスティングしていたため、TravisCIを用いて自動テストを行いました。TravisCIを用いた所感は以下になります。設定方法のドキュメントが読みやすい他にも紹介されているJenkinsやBuildbotについても試していきたいと思います。テスト駆動開発テストについては基礎から応用まで幅広く記されています。pytestの使い方が説明されています。今回はBacklogという外部APIを用いたライブラリなので、Mockを作成する方法やtoxを使ったマトリックステストも使ってみました。本書から引用したツール・ライブラリは以下になります。documentation作ってみた感想ベースとなる書籍があったためPyPIでの公開はスムーズにできました。ライブラリ自体を使用する側の目線に立って作ることが難しかったです。現状はまだまだ使いにくいものなので、改善していきたいと思います。使用感を教えていただけると大変嬉しいです。ライブラリの操作で何箇所か詰まってしまったので、備忘録として記載します。APIのクライアントライブラリであり、Bot開発を簡単に始めることがきます。デコレータを用いて、イベントごとの処理を分けて記述したり、Signatureから署名を検証する操作を簡単にかけます。Botを作成するときは以下の公式ドキュメントからチャネルの作成まで完了する必要があります。登録が終わったら、自分のBotの各種設定をコンソール画面から取得することができます。POSTリクエストを発行できます。URLの項目にPOST先のURLを定義することで設定が完了します。Djangoではルーティングを用いてURLを設定します。APIを用いいる場合は以下の二つの定義が必要になります。これらがそれぞれLINE_ACCESS_SECRETとCHANNEL_ACCESS_TOKENに当たります。Djangoのviews.py上では以下になります。WebhookHandler(channel_secret=LINE_ACCESS_SECRET)handlerの使い方レスポンスの関数呼び出しとリクエストの署名検証リクエストごとの関数を呼び出すためにはWebhookHandlerのhandleメソッドを用います。handleメソッドは署名検証も同時に行います。引数にはレスポンスのbodyと署名検証のためのsignatureを使います。status=200)イベントごとに関数を定義handlerのaddメソッドを用いて、リクエストのイベントごとに実行する関数を記述できます。友達追加されたときに「初めまして」というメッセージを送信する処理は以下のようになります。)handler.addメソッドには引数にリクエストのイベントを指定します。イベントはlinebot.modelsに定義されていて、メッセージやグループ参加などがあります。APIで定義されているリクエストボディになります。リプライはLineBotApiのメソッドを用いています。引数のevent.reply_tokenはイベントの応答に用いるトークンです。第二引数にはlinebot.modelsに定義されている返信用のTextSendMessageオブジェクトを渡しています。内容でも処理を分けることができます。f.write(c)まとめline-bot-sdk-pythonを使ってイベントごとにレスポンスを変える処理を作りました。処理部分を関数で簡単に分けることができるためとてもシンプルに書くことができます。この処理を使って複数のAPIを連携したbotを作ったので、後日まとめたいです。複数のチェックボックスやテキストから値を得る方法がわからなかったので調べてみました。request.POSTからkey-valueで取得しようとすると一つのinputタグしか取得できないため、POSTのメソッドを使用しなければなりません。HTMLサンプルのHTMLは以下になります。nameが同一で、valueが異なるときを想定しています。今回は関数ベースのviewが前提です。'value2']getlistメソッドについてrequest.POSTおよびrequest.GETオブジェクトはdjango.http.QueryDictクラスのインスタンスでした。urlencodeなどのメソッドも追加されていることがわかりました。このQueryDictのメソッドを用いてリストを得ることができます。参考にした公式ドキュメントを貼付します。複数チェックボックスTweet広告を非表示にするもっと読むコメントを書く2018-04-22独学プログラマーを読んでみたPythonこの本を買ったきっかけきっかけは第一章を本屋で読んだことでした。私は現在未経験からプログラマーを目指している一員です。プログラミングの勉強を初めて一年くらいがたち、本格的にプログラマーへの転職を考えていました。そんな中で目にした本書のイントロダクションは印象的でした。著者がモチベーションを維持するためのテクニックは衝撃的で、全く思いつかない上に真似できません。未経験からプロになるために必要なことがわかると思い、購入しました。本書は六部構成になっており、プログラミングの基本から、各ツールの使い方など広く浅い内容であると思います。本書はプログラミング経験のない方をメインターゲットとしています。そのため、普段からガリガリ書いているプログラマーの方には少し物足りないかもしれないです。良かったところ各章にチャレンジ問題がある読んだあとにどのくらい身についてるかをチェックできるので助かります。実際にコードを書くときに日本語を扱う上でのギャップはなく、原著のように読むことができました。各詳細サイトも日本語版のリンクが添付してあり、参考になりました。データ構造・アルゴリズムプログラミングの入門本ではあまり触れられない内容に見えますが、本書では紹介されています。この本で学ぶというようりも、課題の一つとして認識するためという印象です。Part5いざ言語の文法や使い方を覚えた状態から"仕事"にするまでに何が必要か書いてあります。紹介されているのは欧米流ですが、参考になることはとても多いです。総評もっと早く手に取れたら良かったです。Pythonの入門本というよりもプログラマーの入門本だと思っています。これからプログラマーへの道を考えている人にはおすすめの一冊です。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。