PyCon JP 2019で登壇 & 参加しました #pyconjp

  • POSTS
ありがたいことに、昨年のPyCon JP 2018に続き、今年もCfPが採択されたので登壇 & 参加してきました。 スライド: https://speakerdeck.com/sin_tanaka_21/pyconjp-2019 配信: https://youtu.be/lCQWLAJf6xQ CfPや、当日の意識したこと等、メモ書き程度に残しておきます CfPについて 昨年は割と小賢しいタイトルをつけたなぁと自負していて、「実践入門」って一体なんだよって感じではあったので今年はシンプルに、「やりたいこと」と「PyCon自体のテーマ」をかけ合わせる感じにしました。 PyCon JP 2018のスライド: https://speakerdeck.com/sin_tanaka_21/pyconjp-2018 YouTube: https://youtu.be/zgTP_4-XEpw 決まったタイトルが Pythonでライブをしよう!FoxDotを使った新時代のPython活用法 でした。 まぁ、「新時代」と謳いつつも、 FoxDot やライブコーディング自体は随分前から存在しているので微妙だなと思わんではないのですが、「PyConの場でライブコーディングの実演したら新時代感あるやろ!」と思って応募しました。 内容の検討 CfP出した段階で草案は考えていたのですが、内容を詰めたのは採択が決まってからです。昨年は7月の半ばぐらいでしたが、今年は6月には採択速報が出ていたため、準備期間が長くてありがたかったです。 考えた結果、ライブコーディングについて説明するのだから、やはりデモは力入れたいというのと、私自身がが知識欲満たせるプレゼンが好きという理由で特殊メソッドのオーバーロードの解説をすることにしました。 あとは、当初メディア・アートとの関連も少し話す予定でしたが、 自分が詳しくないので付け焼き刃 Pythonとの関わりが薄い の理由で話さないことにしました。 当日のデモ FoxDot だと3連5連のハイハット作るのが楽だし、トラップ流行ってるしそれっぽいBPM/ビートでいくかーとか、電子音に合いそうだし小室っぽいコード進行(GetWild風)にするかーとか、全部で5案ぐらい考えたんですが、最終的には、「変わったことはしないで、すごい風に魅せる」を念頭において、 カノン進行 一般的な House/Techno 辺りのBPM FoxDot のbellが結構いい音 & カノン進行に合うので主軸に置く メソッドチェーンで音を重ねる 転調で盛り上がりを作る 徐々に音数を増やす/減らす なデモに仕上げました。 あとは事前に用意したコードを徐々にコメントアウト解除する方式でやれば本番も大丈夫かな! …と思ったのですが、むくむくと欲が出てきて、 「本当のライブコーディングは事前に用意したコードをコメントアウトしておくのか…?」 「その場でコーディングしてくのが本物のライブコーディング&カッコいいのでは…?」 と思い立ち、PyCon前の土曜日にデモの案ができあがって、そこからはひたすら流れの暗記と練習をしました。 結果、本番では無事成功し、やはりコメントアウト方式よりも説得力が出た気がしています。相当アドレナリン出ました。 後日同僚から「カンペあったの?」と聞かれたのですがカンペは用意できませんでした。 ライブ性のあるものに対し、カンペを用意しないのはプレゼンとしてはバッドプラクティスかもですが、今回はギリギリまでデモを詰めていたためカンペを用意する余裕がなかったのと、「カンペを見ながらやる」というのも実はそこそこ練習が必要、の考えのもと用意しませんでした。 その他 今年からリアルタイムで配信されており、休憩時間にスマホで過去の配信を見ることができたので、かなり体験として良かったです。 良くも悪くも来年現地行くか迷うぐらい。。 今年は以下の辺りの発表を見ました。まだ全然観きれてない。。 メディアが運用すべき持続可能なVTuberをつくる技術(加藤皓也/Hiroya Kato) - YouTube 知ろう!使おう!HDF5ファイル!(thinkAmi) - YouTube 基調講演_Pythonで切り開く新しい農業(小池 誠) - YouTube Pythonで始めてみよう関数型プログラミング(寺嶋 哲/Terajima Satoshi) - YouTube Doujin-activity with Ren’Py(Daisuke Saito) - YouTube Djangoで実践ドメイン駆動設計による実装(大島和輝) - YouTube Pythonと便利ガジェット、サービス、ツールを使ってセンシング〜見る化してみよう(知野 雄二/Yuji Chino) - YouTube PythonとAutoML(芝田 将) - YouTube PythonとGoogle Optimization Toolsの最適化ライブラリで、「人と人の相性を考慮したシフトスケジューラ」を作ってみた。(鈴木庸氏) - YouTube 個人的には発表を受けて Ren'py について調べていたら近年の超名作 Doki Doki Literature Club!

ポエム: gitはGUIでなくCUIをオススメする理由

  • POSTS
CUI vs GUI 「別にどっちつかってもgitの難しさは変わらないのでCUI使ったほうがよくない?」が私の意見です。 なぜなら、branch, push, pull, conflict, rebaseのあたりの概念理解のinterfaceに依らないからです。 変わるのはコマンド叩くかボタン押すかだけです。 じゃあなぜCUIを進めるのか 概念理解の速度が変わらないならGUIだっていいじゃないかと思うかもしれません。 CUIを進める理由は2つです 問題が発生したとき、原因の切り分けが難しい GUIクライアント特有のメタコマンドとgitのコマンドが紐付いていない場合がある 原因の切り分け? 例えば、GUI上でbranchをpushをしてエラーが発生した場合、原因は何でしょうか? GUI上で設定が漏れている? 単純にremoteに今のcommitよりも進んだbranchが既にpush済なのかも? CUI上でエラーが発生した場合、疑う箇所はgitのエラーだけです。GUI特有の問題かも?という懸念を捨てられます。 またGUI特有の問題は以下の理由により検索性が高くないです。 GUI特有のメタコマンド? revert という単語の意味は もとに戻す という意味です。 (これは一部想像も交じるし、そんなGUIクライアントは無いと思いますが、)もしもGUI上に revert stage というボタンがあった場合、「現在のstageにある変更をHEADと同一にする」という意味かもしれません( git reset . && git checkout . に相当) そして、gitには revert というコマンドがありますが、これは「あるcommitの打ち消しのcommitを作成する」というコマンドです。 GUI上でやっていた revert stage と git revert パッと見は似ていますが、動作はまるで違います。 このように、GUIではボタンにかかれている動作が、gitのコマンドそのものになっていない場合があります。 GUIでラップされてしまったボタンを覚えるよりも、CUIでgitのコマンドを覚えるほうがのちのち役に立ちますし、検索性も高いです。 結論 裏側でどんなコマンド走ってるのか、そのコマンドの意味を理解できている、調べればわかる人はGUIでもいいと思います。 最初に言ったとおりgitの難しさはCUIだろうがGUIだろうが変わらないので、それならgitそのものを学べるCUIがオススメという話でした。

Chalice(Lambda + API Gateway)を使ってInteractiveComponentを扱うSlackAppを作る

  • POSTS
SlackのInteractiveComponent Making messages interactive | Slack SlackBotでもInteractiveComponent自体を投稿することはできるが(単にattachmentsを付与すれば良い)、アクションのリダイレクト先を指定することができないのでSlackAppを作成する必要がある ※: SlackBotとSlackAppは別物 想定仕様 EventAPIとInteractiveComponentのリダイレクト先に指定するサーバはAPI Gateway + Lambdaを使う Flaskライクに書いたAPIをAPI Gateway + Lambda etc..へデプロイできるフレームワークChaliceを使う SlackAppにメンションを飛ばすとInteractiveComponentを返す EventSubscribe(EventAPI) で app_mention イベントをlistenする RedirectURLは foo-bar-domain/api を想定 InteractiveComponentにはYes/Noボタンを付ける どちらかのボタンが押されたとき対応する文章を返す RedirectURLは foo-bar-domain/api/reaction とする SlackAppの作成 Slack API | Slack でStartBuildingボタンを押すとアプリを作成することができます つづけて、 - BotUserの作成 - InteractiveComponentsの有効化 - Permissionの設定 - chat:write:bot - bot BotUser作成したときに付与される をしておきます。最後にInstallAppすることでWorkspaceへAppをインストールします RedirectURLはデプロイ後、URLが決定したら設定します ChaliceでEventAPI、InteractiveComponentのRedirectを受けるAPIを作る chaliceをインストールしてプロジェクトを作成します AWS Chalice — Python Serverless Microframework for AWS 1.8.0 documentation

iOS12 で SMS で受け取った認証コードを補完候補に出すときは autocomplete 属性に one-time-code を指定する

  • POSTS
iOS12ではセキュリティ周りのアップデートで、セキュリティコードの自動入力がサポートされました。 主な機能として、サインイン時のパスワード自動入力や、アカウント作成時の自動パスワード生成などがサポートされました。 以下のブログでネイティブアプリの実装を紹介しています。gif付きでわかりやすいです。 すぐできる iOS Strong Password and Security Code AutoFill – PSYENCE:MEDIA そんなアップデートの中で、地味ではありますが、SMSで受けとった認証コードを補完候補に出す、という機能が追加されました(上記のブログ内のgif参照)。 本記事では、 MobileSafari(WebView) 内で有効にするのに手間取ったのでメモ。 やったこと 記事のタイトル通りですが、 <input> タグの autocomplete 属性に one-time-code を指定することで実現可能です。 <input id="single-factor-code-text-field" autocomplete="one-time-code"/> Enabling Password AutoFill on an HTML Input Element | Apple Developer Documentation まとめ HTMLはどことなくエンジニアが軽視しがちな領域ですが、正しく構造化したり、適切な属性を付与することで、メンテナンス性やアクセシビリティの向上が見込めます。 地味ではありますが、少し手を加えるだけでユーザビリティ向上につながりますね。

fzf + sqliteを使ってChromeの閲覧履歴をインクリメンタルサーチする

  • POSTS
JSL (日本システム技研) Advent Calendar 2018 - Qiita の12日目の記事です。 モチベーション Chromeの履歴が見辛いのでいい感じに表示したい 履歴を見やすくするプラグインはいくつかあるが、ターミナルから「履歴閲覧→開く」ができるとシームレスにWebブラウジングに移れそう なので今回は、sqliteを使ってユーザのローカルに保存してある履歴ファイルを閲覧 + fzfを使ってインクリメンタルサーチ するコマンドを実現するための方法を書く。 最終的にやったこと fzfの公式サンプルに載ってた。 Examples · junegunn/fzf Wiki サンプルに沿って、パスの通った場所に以下のようなコマンドを置きました。名前はChromeHistoryで ch としました。 #!/usr/bin/env zsh ch() { local cols sep google_history open cols=$(( COLUMNS / 3 )) sep='{::}' if [ "$(uname)" = "Darwin" ]; then google_history="$HOME/Library/Application Support/Google/Chrome/Default/History" open=open else google_history="$HOME/.config/google-chrome/Default/History" open=xdg-open fi cp -f "$google_history" /tmp/h sqlite3 -separator $sep /tmp/h \ "select substr(title, 1, $cols), url from urls order by last_visit_time desc" | awk -F $sep '{printf "%-'$cols's \x1b[36m%s\x1b[m\n", $1, $2}' | fzf --ansi --multi --preview-window down:1 | sed 's#.

PyCharmの機能をIdeaVimのnormalモードに割り当てる

  • POSTS
IDEにPyCharm、Vim用のキーバインド設定のためにIdeaVimというPluginを使っています。 PyCharmはそれ自体が便利で、機能も豊富で素晴らしいIDEです。今回はPyCharmに備わっている各機能をVimのnormalモードに割り当てるまでの設定をしたいと思います。 今回はPyCharmですが、JetBrains系のIDEであれば同様に設定できるかと思います。 今回は Navigator > Next Method / Previous Method をVimのnormalモードの <C-n / C-p> に割り当てます。 Next Method / Previous Method は、名の通り、今いる位置から次/前のメソッドの行頭に移動する機能です。 デフォルトではCtrl + Shift + Option[Alt] + ↓ / ↑ なので結構押しづらい。 単に当該機能のキーマップを Ctrl + n / p に割り当てることでも問題ないのですが、自分の設定だと、それぞれUp / Downが割り当てられているため、normalモードのみこの機能が効くようにしたい。 .ideavimrc を作成する 通常のVimを使用するときに、 .vimrc を設定するように、IdeaVimでも同様の設定ファイル .ideavimrc があります。 これに通常のVimの設定に加えて、IdeaVim独自の設定をします。 $ touch ~/.ideavimrc .ideavimrc を設定する 以下のようにnormalモードの にそれぞれの機能をマッピングします。 nnoremap <C-n> :action MethodDown<CR> nnoremap <C-p> :action MethodUp<CR> なお、設定できるPyCharmのアクションの一覧は、IdeaVimを導入したPyCharmのエディタ上で、 :actionlist とすると見ること出来ます。