自分が大好きだった、Message Passing はなしをふったりふられたの後日談を @karino2 さんが、Podcast で語ってくれていたので、アンサーソング。
読者としては、Message Passing という共著ブログは RSS に登録して毎回とても楽しみにしていた。 著者陣はなぜかやってよかった、大成功だね! という感想を出している方が少なく @morrita さんが
特に皆が書いてくれたものを読むのはすごく楽しかったので、うまくいった気もしています。 https://messagepassing.github.io/023-s1/04-morrita/
というポジティブな感想を残してくれており、読者としても著者陣が良い体験として経験されているとすごく嬉しい。 続編を期待しております。
以下、Podcast 内でのご意見に関するお話。記憶の中から書き出しているので正確性に欠けるかもしれません
書く習慣を身に着けていないと、書けないし、普段から書く習慣を実践したい @morrita さん
同意。自分も今年から脱 Twitter をして、Blog で記事を執筆するようにしているが、以前よりもほんの少しだけど読みやすい文章に変わった気がする。
Blog 記事の感想は欲しい。。。が今だと一方通行。Twitter での言及はいまがポピュラーだが、それはなんか違う。 どちらかというち意見を書くというよりも、意見を求めているときがある。
これも非常にわかる。自分も双方的な意見交換を Blog 上で行いたくてコメント機能を導入1したが、今の所導入してから 1 件のリアクションしかされていない…2
このコメント機能の Giscus の良いところは、
記事に絵文字リアクションを行える GitHub アカウントが必要なのでスパムをかなり弾けそう なのだが、全然使われない…
はてぶで 969 件とかなりブックマーク3された記事で、自分の Blog でもおそらく歴代最大の閲覧数を持つ記事でさえもコメントはされなかった。
いや、はてぶやってるヒトははてぶでコメントすると思うので、単純にはいえないですが…一つの指標として
はてなスターや、Medium の clap のような弱いシグナルが欲しくて導入したのだが、なかなか思い通りにいかない。
海外の有名所の Blog 記事だとコメントが殺到しているので、これも日本独特の問題なのか? それとも到達する数の規模が違うからそのぶんコメントが多くなる傾向などがあるのだろうか?
increments などの雑誌に比べて Message Passsing は、他の著者が書いた記事に返信していくような形式なので、重複した内容が少ないのが良い点 @morrita さん...
社内でデータ分析のレポートを書く際は Google Colab がとても便利な事に気がついた。
Google Bigquery でデータを抽出、Google Sheets で可視化 従来だと、自分がやっていた方法として、
Google BQ などで分析対象結果のデータを抽出 その結果を Google Spread Sheet として保存して、Google Sheets の機能で可視化。元の SQL のコードは、別シートを作ってそこに貼り付けておく。 利点としては、一度データを抽出した後は、Google Sheets で二次加工が簡単にできる点がとても便利。 また、 Google Sheet を共有後に Produc Manager が出したい数値を、Product Manager 自身が Google Sheets を元にさっと計算することもできる。
だが、二次加工が便利なのはいいが、大抵の可視化ってパターンが決まっているかつ二次加工の状況が必ず発生するわけではないので、SQL 取得とその可視化を一気通貫でできないかなと考えていた。
なにか良い方法無いかなと思っている矢先に、別のチームの同僚が、Google Colab を使って、BQ を dataframe として保存後 matplotlib で可視化しているのを見かけて、
求めていたのは…こ、これだ….
となり、速攻取り入れました。
良いと思ったところは積極的に真似する
Google Colab なら、データの取得・加工・可視化までを完結可能 Google Colab の利点を列挙しておく
SQL のコード、データ抽出や可視化のロジックなどが Python で記述可能かつ、Google Colab で完結 matplotlib で可視化できるので、見やすく美しい図を作れる そしてそのコードは他のデータ分析でも再利用可能 pandas dataframe で Google BQ からデータを取得するので、Standard SQL だけでは難しい計算も pandas、 numpy や scipy などを使ってデータ加工が簡単にできるのも、便利 Google Sheets 同様、簡単に社内で共有できる Markdown も Google Colab 内で書けるので、凝った文章などもいれてレポートも書ける マジックコマンドで、Google BQ の結果を dataframe として保存1したり、...
2022 年、初めてまともな確定申告をやったので、所感をメモ。
実際には 2021 年に初めて確定申告を行ったのだが、ふるさと納税と医療費控除のみだったので、まとも?な確定申告は 2022 年がはじめてといってもいいだろう。
会計ソフトはマネーフォワードと迷ったが、クラウド会計ソフト freee 会計を採用した。 前評判では会計知識がある人からすると抽象化されすぎており、むず痒くなるという記事を見たのだが会計知識がない自分からすると全く問題なく使えた。 会計周りもすべてクレカ経由でしか支出していないのでひたすら振り分けて終わり。 これらは実質作業時間 15 時間程度。 振替項目が何が適切なのかの調査に一番時間が取られた。 書類提出も Andorid のアプリと連携することで free で完結して、ネット上で提出できて良い体験だった。 来年もしやることがあればものすごく早く終わりそう。 マネーフォワードの確定申告は、最初の画面で心が折れて回れ右をした。
freee が「寄附金控除に関する証明書」の xml を読み込める機能に対応しており、ポチポチで終わった。 事前の証明書を発行するための手続きが若干煩雑だったが、今までに比べると圧倒的に楽だった。 証明書の管理もしなくて良くなったのは革命では? 実作業時間は 30 分程度。 紙がもったいないので、個人的には自治体から書類は送らないで欲しい。
医療費控除は、国税庁が公開してくれているエクセルにデータを打ち込んで終わり。 実作業時間は 2 時間程度。 そのフォーマットに free が対応してくれているので読み込んで終わり。
最終的な e-Tax の提出は、スマホでカードリーダーを読み込んで連携1させれば終わりだったので非常に快適だった。 2021 年は張り切って、IC カードリーダーを買ったが結局手持ちの Mac と Safari の相性が悪くかなり粘ったが結局紙に印刷して送付したという思い出がある。
アイ・オー・データ IC カードリーダー ぴタッチ 確定申告 e-Tax
国税庁が用意した Safari の拡張機能周りが魔窟で、当時のサイトを忘れたがマニュアルにかかれていない設定をしないとマイナンバー読み込みプログラムがそもそも起動しなかった。 リベンジできてなにより。 完全に無用になった IC カードリーダーは即売却した。
総評 年々システムが改善されて自動化されていて、素晴らしい。
賛否両論あると思うが、医療費もマイナンバーの保険証化2によりデータが収集されるらしいのでぜひ浸透してほしい。 最近のニュースでは別途診察代金が請求される方式らしく3、ここに税金使わないで何に使うんだろうかと思ったが、予算が取れなかったのかなと色々と考えをめぐらした。 せっかく良い活用が期待できるのに、使う動機を無くすのはもったいない。
e-Tax、スマホがあれば IC カードリーダーは不要に - ケータイ Watch ↩︎...
5 回目のニュースレター配信です。更新頻度を保つために、1 時間で読めるだけ記事を読んで配信していくスタイルに次回からしようと思いました。 本格的に精読したい面白い記事が来ると一時間なんて一瞬で潰れてしまう…
Search Introducing Natural Language Search for Podcast Episodes
Spotify が Podcast 検索において text matching の従来の検索エンジンではなく、ニューラル検索を導入した解説記事。 ニューラル検索の実運用例として面白かったので、以下に抄訳として内容をまとめた。
Beyond term-based Search 「electric cars climate impact」と自然言語のクエリを Elasticsearch に投げても何も検索結果が表示されなかった…だが検索されなかったのは、Spotify 上の Podcast に関連する内容がなかったからなのだろうか?
NOTE:個人的に本当に結果が出なかったのかは気になるところではある。ワードの完全一致ならともかく、BoW や BM25 で検索すれば結果は出るのでは…?
Natural Language Search 自然言語検索(Natural Language Search、またの名を意味検索(Semantic Search) と呼ばれる技術について調査を始めた。すごくざっくり言えば、従来ではクエリとドキュメントの単語の一致によって検索を行っていたが、意味検索ではクエリとドキュメントの意味的な相関によって検索を行う。
実際の検索結果の例を見ても、クエリのすべての単語が Podcast のタイトルには含まれていない(Elasticsearch が検索結果を出さない理由でもある)が検索結果として妥当なことがわかる。
Technical solution これらの結果を実現するために深層学習の技術である、自己教師学習と Transformer を利用、そしてそれらの結果を高速に提供するために近似近傍探索(Approximate Nearest Neighbor (ANN))を利用する。
共通の埋め込み空間上で、クエリのベクトルに近い Podcast を検索結果として計算する。また、Podcast の題目、説明文、そして親ポッドキャストのテキスト情報などを連結して特徴量とする。
Picking the right pre-trained Transformer model for our task BERT のような Transformer モデルは、自然言語処理タスクでは現在最高峰の性能を誇っている。 BERT は 2 つの観点から高性能になっている...
gRPCurl 1 を使ってリクエストを送る際に、 reflection を機能を使わずに protobufs のファイルを読み込もうとすると
1 Failed to process proto source files.: could not parse given files: ~ no such file or directory とエラーがでてコマンドが実行できなかった。
対処方法としては grpcurl コマンドを実行する際に、-proto フラグを利用するだけではなく、-import-path フラグを指定する必要がある2。
-import-pathフラグの指定により、参照する protobufs の依存関係のパスを grpcurl に伝えることで上記のエラーが解消される。
例えば、protobufs の内部で
1 import "~/---.proto" のように他の protobufs を import していると上記のエラーの発生原因となる。
つまり、-import-pathを指定しないと、import 文実行時に grpcurl 内部で、参照する protobufs の root path が不明なので、パスがうまく処理されずに import 文の実行処理がコケてしまうと理解。
fullstorydev/grpcurl: Like cURL, but for gRPC: Command-line tool for interacting with gRPC servers ↩︎...