歩いたら休め

なんでこんな模様をしているのですか?

【本】『みずほ銀行システム統合、苦闘の19年史』を読みました

のんびり読もうとしたのですが、ちょっと高めに設定していたにも関わらずメルカリで売れてしまったので急いで読んでました。

きちんと経営レイヤーで意思決定できていなかったことが原因で、やや雑ですがまとめてしまうと『失敗の本質』にあるような「戦略のミスは戦術でカバーできない」ということだと思えました。また、特に私に刺さった箇所はここです。同じ箇所をツイートしている人がいました。

jbpress.ismedia.jp

【雑記】メルカリに本を60冊くらい出品しました

https://www.mercari.com/jp/u/252084402/

知り合いから「古書店に売るより高く売れるから、メルカリにしばらく出品した後に残ったものを引き取ってもらってる」って聞いたので、私もそうしてみます。私と趣味が合いそうな方は、是非チェックしてみてください。

【雑記】今年は英語をちゃんと勉強します

この間、海外に住んでる友達と久しぶりに会ってその一味と映画を見に行きました。ただ共通の友達が英語ネイティブが多く、ふとした話に全然ついていけずに悔しい思いをしました。あとLINEでの略語表現が全然わからん。

(雑談なので文脈がわかりづらく、例えば「ICカード乗車券付きのクレジットカードを使ってるんだけど、設定の問題でオートチャージ機能が使えてなかったんだ」みたいな話だったそうなので特に難しかった気はするんですが)

なので今年は英語を毎日勉強しようと思います(完)。

続きを読む

【Python】バリデーションを行うライブラリのpydanticが便利だった

同僚からFastAPIを薦めてもらって、バリデーションの機構が便利(そして早い)ということを教えてもらいました。

その中でjsonリクエストのアノテーションに使われているライブラリがpydanticで、FastAPI以外でも、辞書オブジェクトのバリデーションやキャスト、またSQLAlchemyのORMとの組み合わせなどもできるようです。

pydantic-docs.helpmanual.io

これについて記事にまとめようと思ったのですが、今の所特に詰まりどころもなく、日本語の記事ならこちらに素晴らしいものがありました。ですのでこちらを読んでください。

qiita.com

まあ良いライブラリを教えてもらったってことでw

【参加レポート】Data Platform Meetup vol.2に参加しました

Data Platform Meetup Vol.2に参加したので、その参加レポートを書きます。

実は既に @ikedaosushi さんが記事を書いているのでそちらを読んでください。よくまとまった記事なので「私は書く必要ないんじゃないか」とも思ってしまったのですが、私が感じたこと + 質疑応答の内容を追記していきます。

blog.ikedaosushi.com

個人的に三行でまとめると↓のような感想でした。

  • 社内コミュニティやドキュメントなどの啓蒙活動でスキルやナレッジの伝達を各社努力している
  • Redshiftはマジで大変そう(自分はBig Queryにかなり救われている)
  • 縦持ち、横持ちはコンテキストによって必要性が変わるので使い分ける(snowflake schema)

私も似た感想でした。

啓蒙活動について

特にpixivの長部さんの発表でよく触れられていました。「分析・データ加工の代行を期待されてしまう」というのは自分たちの会社でも起こっていて、「(悪く言うと)便利屋からどう脱却して専門性を発揮していくか」という話はデータ組織に普遍的なテーマなのかもしれません。

そのためにナレッジ共有の場や教材作成を作ったそうなのですが、個人的にはそこのモチベーションや目標の置き方をどうやっているのか気になりました。実際そういう質問もあり、それには「元々問題意識を持った人の寄り合いが部署になった経緯があるのでメンバーのモチベーションが高く、問題になってない」というような趣旨の回答されていました。

RedShift VS BigQueryについて

CookpadのInuzukaさんの発表。RedShiftの同時接続数などの制約をどう回避して便利に使うかという発表もありました。技術的な話としては面白かったのですが、自分たちのチームでGCPのBigQueryを利用しているところではあまり問題になったことがない箇所(課金額の見積もりちゃんとしてないと困る程度)ではありました(一応同時実行数などの制限もあるのですが、自分たちのユースケースだと全然余裕です)。

ただ自分たちのチームでは、DWHがBigQueryで、(機械学習も含めた)システムの開発や運用をAWSで行っているので、データやモデルをどうやり取りするかといった別の問題はあるように思います。実際にはそこまで考えて技術選定する必要があると思います。

各発表のQ & A

できるだけメモを取ったつもりですが、抜け漏れや要旨が間違っている点があればご指摘ください🙏

プロダクト中心のデータ駆動を推進していくために大事なこと

Q. 学習教材はエンジニア向け以外にもあるか?

A. ビジネス職向けのSQLチュートリアルもある。もちろんエンジニア向けも用意している。

Q. BigQueryは従量課金なので、自由に使わせるのは課金額の点で怖くないか?

A. 裁量にまかせているものの、監視はしている。特に前日のクエリの課金額順の通知はしていて、問題のあるクエリを書いた人に指摘はしている。

Q. 教材のモチベーション維持ってどうやってる?直接ビジネスに影響しない箇所なので、KPIの設定など苦戦するのでは?

A. 元々、組織の発端が問題意識を持った人の寄り合い状態から始まっていて、メンバーのモチベーションも高いので大きな問題になってない。

Q. 民主化のためにLOOKERを利用しているとのことだが、LOOKMLは誰が定義してる?

A. リポジトリは統一していて、そこに各部署のエンジニアがコミットしてる。また規約の定義やコードレビューはデータ駆動推進室が行っている。

データを用意しただけだと使われないので、使ってもらえるようにした努力

Q. 事業部制を取っている会社でデータを集約してるのすごい。ガバナンスを効かせるのって工夫したのでは?

A.\ データの追加はこちら側がやってる。プロダクトのDBのコピーと、個人情報のマスキングして入れるのが大変だった。ただ要望を定型フォーマットで出してくれるように工夫してる。

Q. (クックパッドのコミッタの方から)dmemoの要望ってありますか?

A. Redshiftに直接繋いでいて、ActiveRecordのinteger型がRedshiftと互換性がないので独自に潰す必要があった点が大変だった。

Q. 具体的に「こういうことをしたら喜ばれた」って話はありますか?

A. データの使い方といってもいろいろあって、分析・機械学習などの応用がいくらの価値を創出したか出しづらいんですけど…。ただ、インプレッションログの表示順位を工夫した(受注確率が高い顧客を上にもってくるなど)。

DWHを活用したクックパッド機械学習プロジェクト

時間が取れなかったため質疑応答の時間なし。他の発表も短い時間だったので、もう少し一つ一つの発表をじっくり聞きたかった気がします…。

アプリデータの分析を楽に効果的に!FirebaseAnalyticsとお友達になると良い3つの理由

Q. クライアントサイドの時刻ってイベント発生時刻と送信時刻のどちらか?クライアント側で時刻が狂ってる場合はどう扱ってる?

A. 時刻は基本的にイベント発生時刻で、タイムゾーンはすべてUTC。イベント発生時にオフラインだった場合のデータが後でバルク送信された場合に過去のデータが変わることはあるので、3日さかのぼってデータマートを作ってる。

DWH デザインパターン 〜 テーブル設計編 〜

Q. テーブルの設計で、ディメンションとファクトを分けるのが習慣としてある人とない人がいて、「なぜこう持たないの?」って衝突があるはず。そこは乗り越えた?

A. レビューや「規約に乗るとこういうメリットがある」と説明することで乗り越えている。また規約に則って作ると便利になるように補助するツールを実装している。

Q. 「指標」部分はどうしてるのか?(ここの質問の意図がメモできませんでした…)

A. 具体的な指標の話は(業務の話になるので)外で話しづらいが、再利用しやすい形にはしてる。指標のカタログを作っているイメージ。

【プログラミング】mix-inやtraitより継承のほうが優れているケースは存在するのか?(が分からなかった)

kiito.hatenablog.com

↑最近こちらに悩んでいます。感覚的には積極的にmix-in(と委譲)を使ったほうがモデリングしやすいのですが、もしかすると継承のほうが便利なケースがあるかも分かりません。それで以下の2つを調べていました。

  • 「inheritance is not subtyping」問題
  • Rustのtraitが導入されるまでの議論を追う(端的に言うとRustでなぜクラスの継承の機能が実装されなかったのか追う)

ところが、前者はきちんと追おうとすると型理論の話が分からないし、後者もGitHubのissueなどにあるんじゃないかと思ったのですが見つけられていません。一応それっぽい議論はあったのですが、こちらも「継承がないとGUIプログラミングきつくない?」「いやいやそんなことないよ」程度の内容に見えて、もう少し具体的じゃないときつい感じします。

internals.rust-lang.org

一旦諦めて他のことやろうと思います。

【Python】継承という機能はmix-inだけで十分なんじゃないか説

最近、Pythonでコードを書いていて、薄々「継承で使うのはmix-inクラスだけでいいんじゃないか」と感じています。ここでいうmix-inクラスというのは、以下の記事で述べられているような「インスタンス変数を含まず、メソッドのみを持つ多重継承用のクラス」のことです。

www.atmarkit.co.jp

あるいは、「インスタンス変数を含むクラスを継承するのは1つだけ」とするルールを自らに課す方法もある。その場合、追加で継承できるのは「メソッドのみを含んだクラス」となる。そうすることで、インスタンス変数の共有によって生じる問題を回避できるようになる。

これに反論のある方は少ないと思います。また、「親クラスでインスタンス変数を定義する処理(ほぼ __init__ だと思います)を共通化する必要性がなければ、通常の親クラスを使わずにmix-inクラスだけで表現できるのではないか?」さらに「 __init__ などの処理を共通化して得られるコストメリットは少ないのではないか?」と感じています。その理由は以下の通りです。

  • Rustなどの言語では「インスタンス変数を含まない多重継承用のクラス」にあたるtraitと実装用の構造体の機能がはっきり分かれている(詳しくないので間違ってたら教えてください)
  • インスタンス変数を利用する処理を複数の子クラスで共通化する」ことにメリットがあるコードに出くわしたことがないように感じている
  • 他に自分が感じている感想として、単一継承でも継承関係が深くなると、インスタンス変数がどこで定義されているものか分からなくなる。そもそもリスコフの置換原則を満たしていないクラスに継承を使っているようなコードだったのが問題かもしれませんが…

この話を友人にしたところ、「多重継承したい場合に『インスタンス変数を含むクラスを継承するのは1つだけ』とするルールが必要なのは異論ない」「ただ、 __init__ の処理を共通化するメリットがある場面もあるのではないか?(極端な例だが子クラスが100個あって全部で同じ初期化処理がある場合)」というような意見を貰いました。

というわけで、「mix-inだけでいいんじゃないか説」の完全な証明にはならないものの、「子クラスが100個あって全部で同じ初期化処理がある場合」に、「インスタンス変数を含まない多重継承用のクラス」しかない言語ではどう解決しているのか(それとも __init__ を共通化するより楽な設計はあるのか)を調べてみようと思います。

と思ったのですが、サクッと調べた程度では全然結論が出なかったので一旦諦めました。

様々な記事

teratail.com

medium.com

class Dog
 include Runnable
end

class Cat
 include Runnable
end

module Rannable
 def run
 end
end

Dog.new.run

こちらも「Dogは走れるものの一種(Dog is a Runable)」と解釈できるんじゃないかと思ってしまいます。

riptutorial.com

TODO:: Rustのtraitが導入されるまでの議論を追う

www.buildinsider.net

kiito.hatenablog.com

TODO:: 「inheritance is not subtyping」問題