Robust Python読んだ

learning.oreilly.com

Robust Pythonという本を読みました。

どんな本か

You’ll journey through numerous ways to make Python clean and maintainable.

とあるように、Pythonでキレイでメンテしやすいコード書こうという本です。

なお、

This is not intended to be your first Python text

Pythonを初めて学ぶための本ではなく、基本的な構文(ループとか)の説明はありません。

扱う話題は、

  • 型ヒント
    • 入門、Collection、Typecheckerのカスタマイズ、導入戦略
  • 型定義
    • Enum、dataclass、継承、duck typing、Protocol、pydantic
  • 拡張しやすい実装の話
  • セーフティーネット」の話
    • 静的解析(pylint、dodgyによる機密情報ベタ書きの検知、banditによるセキュリティの確認)
    • テスト(pytest、behaveによるBDD、HypothesisによるProperty-based testing、mutmutによるMutation esting)

などがあります。

なお、2021年に出版された本で、邦訳は(今のところ)ありません。

他の本

邦訳されている本に限っても、「Python初心者の一歩先」似たティストの本は激戦区で、

あたりが競合になりそうです。

これらの本と比べたRobust Pythonの特徴ですが、

  • 他の本と比べて「Robust」の話題に特化。「Robust」に関係薄い話題は含まれない
    • 具体的には、C言語による拡張や、ジェネレータ・イテレータ、並行・並列プログラミング、パッケージの作成
  • 他の本と比べて比較的新しい
    • Robust Pythonは2021年
    • エキスパートPythonプログラミングは原著(4版)が2021年、邦訳(3版)は2019年
    • Fluent Pythonは2015年(2版は準備中)
    • Pythonハッカーガイドブックは邦訳2020年、原著は2018年
  • 厚さ的には(比較的)薄め

また、この本のテーマである「Robust」なコードに関しては

  • リーダブルコード
  • プログラミング作法

あたりと多少被りそうですが、Robust Pythonは良くも悪くもPython特化な点が差別化ポイントになりそうです。

Robust Pythonが扱っていない(そして他の本では扱っている)話題も多いので、Python始めた人に「二冊目」の本として読むのは微妙な気がします。

単に動くコードを超えて、メンテしやすいコードを書くための「三冊目」として読む・薦めるのが良いかもしれません。

その他

「きれいなコードとはなにか」「なぜきれいなコードが必要か」を扱う章があります。

その中で、「コードは非同期コミュニケーションだから意図を込めて、意図をわかるように書け」みたいな記載がお気に入りです。

Expert Python Programming(4版)読んだ

tl;dr

  • Expert Python Programmingの4版が英語だと出ているよ
  • mutation testingとか分散トレーシングとかナウい話が追加されてるよ
  • 一部削除された話もあるよ
    • ドキュメント、良い名前の付け方

Expert Python Programming(エキスパートPython)とは

英語版の説明ページいわく

Complete with best practices, useful tools, and standards implemented by professional Python developers, this fourth edition has been extensively updated. Become familiar with the latest Python improvements, syntax elements, and interesting tools to boost your development efficiency.

日本語版の説明ページいわく

本書は、Pythonを使って仕事をしている開発者が普段どのようなツールやテクニックを用いて仕事をしているのか、また開発者が実際に現場で用いているベストプラクティスについて解説した書籍です。本書を読むことで、先進的なPythonプログラマが日常的に使用している開発ノウハウを学ぶことができます。

要するに、言語そのものだけでなく、プラクティスやツールも紹介してくれるクールな本です。

版の歴史

英語 O'reillyのSafari経由のサブスクリプションで読めます。

  • 2008年に1版
  • 2016年に2版
  • 2019年に3版
  • 2021年に4版

日本語版

なお、私は日本語版の2版を昔読みました。3版は読んでないです(違いの確認は目次とO'reilly safariでの流し読み)。

過去の版との違い

以下の章が増えてる・他の章から独立した章になっています。

  • 「New Things in Python」(3章)
    • 3.8, 3.9で追加された機能の紹介の章です
    • assignment expression とかtype hintingの拡張、新しい標準ライブラリ(zoneinfo, graphlib)
  • Python in Comparison with Other Languages」(4章)
    • 他の言語と比較しつつ、多重継承、プライベート化、duck typingあたりの紹介です
  • 「Interfaces, Patterns, and Modularity」(5章)
    • 抽象クラス(ABC)、Inversion of Controlあたりの紹介です
  • 「Observing Application Behavior and Performance」(12章)
    • ログ、モニタリング(Sentry)、メトリクス(Prometheus)、分散トレーシング(Jaeger)の章です

一方、2版・3版から削除されている章もあります。章を削除した意図は特に書いていない?と思います。

  • 「良い名前を選ぶ」
    • PEP8とか変数名・クラス名の章
  • 「構文ベストプラクティス クラス以外」
  • 「構文ベストプラクティス: クラスの世界」
  • 「コードをデプロイする」
  • 「コードの管理」
    • GitとかCI/CDの章
  • 「プロジェクトのドキュメント作成」
    • 技術文書とかreStrcuturedTextの章
    • (reStrcuturedTextは3版では独立した章に)
  • Pythonのためのデザインパターン

なお、削除された章の一部は、4版では(内容・タイトルが追加・変更の上)別の章に対応する気もしています(明言はされていないです)。

  • 「構文ベストプラクティス: クラスの世界」 -> 「Python in Comparison with Other Languages」
  • Pythonのためのデザインパターン」->「Interfaces, Patterns, and Modularity」
  • 「コードをデプロイする」-> 「Observing Application Behavior and Performance」

その他増えてそうな内容(過去の版で見落としただけかも)

  • Poetry
  • mutation testing
    • コードの方を変更してテストの品質測るやつ
    • mutmutによるテストが紹介されています

(補足)2版と3版の違い

訳者の清水川さんのブログが詳しいです

  • 「イベント駆動形プログラミング」(Event-Driven Programming)の章が追加
  • 「現代的なPython開発環境」・「メタプログラミングの要素」「reStrcturedText入門」の章が他の章から分離

したのが大きな点でしょうか

www.freia.jp

Prefect Orionについて何か書いた

Prefectとは

AirflowやDigDagと同じワークフローエンジンです。

このブログでも紹介していますが、

などがわかりやすいと思います。

英語でもよければ、公式ページ(core部分オーケストレーションの二つ)がわかりやすいです。

Prefect Orionとは

2021/10/6にPrefectがアナウンスした「our second-generation workflow engine」です。

まだTechnical Previewで出ている情報も少ないですが、Prefect Orionについて調べてみようというのが、今回の記事です。

正直、まだぼんやりしています

なにはともあれ触ってみる

Getting startedがあります。

下例では既存のPrefectと分けたいのでPoetry使っていますが、適当に読み替えてください。

# インストール
poetry new advent_calendar_prefect
cd advent_calendar_prefect/advent_calendar_prefect
poetry add "prefect>=2.0.0a"
poetry shell

basic.pyとして保存します。

from prefect import flow, task
from typing import List
import httpx


@task(retries=3)
def get_stars(repo: str):
    url = f"https://api.github.com/repos/{repo}"
    count = httpx.get(url).json()["stargazers_count"]
    print(f"{repo} has {count} stars!")


@flow(name="Github Stars")
def github_stars(repos: List[str]):
    for repo in repos:
        get_stars(repo)


# run the flow!
github_stars(["PrefectHQ/Prefect", "PrefectHQ/miter-design"])

実行

python basic2.py  
07:48:04.506 | Beginning flow run 'merciful-unicorn' for flow 'Github Stars'...
07:48:04.506 | Starting executor `SequentialExecutor`...
07:48:04.731 | Submitting task run 'get_stars-e40861f0-0' to executor...
PrefectHQ/Prefect has 7906 stars!
07:48:05.229 | Task run 'get_stars-e40861f0-0' finished in state Completed(message=None, type=COMPLETED)
07:48:05.319 | Submitting task run 'get_stars-e40861f0-1' to executor...
PrefectHQ/miter-design has 12 stars!
07:48:05.796 | Task run 'get_stars-e40861f0-1' finished in state Completed(message=None, type=COMPLETED)
07:48:05.800 | Shutting down executor `SequentialExecutor`...
07:48:05.882 | Flow run 'merciful-unicorn' finished in state Completed(message='All states completed.', type=COMPLETED)

サーバを起動

prefect orion start

f:id:toukoudo:20211210075028p:plain
prefet_orion

サーバを起動する前に実行したFlowも登録されていることに注目です。

(~/.prefect/orion.dbに情報が保存されるようです)

エラー

常に起きるかは不明ですが、自分の場合以下のエラーがでました(抜粋)。

sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) no such table: flow
[SQL: INSERT INTO flow (id, created, updated, name, tags) VALUES (?, ?, ?, ?, ?) ON CONFLICT (name) DO NOTHING]
[parameters: ('cb63d353-0279-4e4c-adfd-5bb1254b88d7', '2021-12-06 22:33:35.319780', '2021-12-06 22:33:35.319804', 'my-favorite-function', '[]')]
(Background on this error at: https://sqlalche.me/e/14/e3q8)

DBをリセットするコマンドを実行すると動くようになりました。

prefect orion reset-db

画面を眺める

わくわく

f:id:toukoudo:20211210081034p:plain
トップ画面

f:id:toukoudo:20211210082020p:plain
flow run

f:id:toukoudo:20211210082108p:plain
radar

Prefectとの画面の違い

Technical Previewという事情もあり、Prefectよりも機能は(かなり)少ないです。

例えば、

  • 画面からのFlow実行
  • ログの確認
  • Interactive API

などはありません(未実装なだけなのか、意図的に実装していないのか不明)。

余談ですが、デフォルトポートが衝突(OrionのWebserverとPrefectのApollo Serverが4200)するので、そのままでは同時起動できません。

Radar

現時点でのOrionと従来のPrefectの最大の違いは、Radarかもしれません。

従来のPrefectが上から下に依存関係を配置に応じた配置を行っていたのに対し、Radarでは同心円状に配置し、依存関係のTask同士を結びます。

大規模な場合や、Subflowが多く使われている場合に便利になるらしいです(が、運用してみないとわかりませんね…)。

https://www.prefect.io/assets/img/ui-2.c31b79ad.svg (従来のPrefect。Prefect Core - Prefectより)

f:id:toukoudo:20211211070443p:plain
Radar
(Radar。Introducing Radar - Prefectより)

ビジョンのはなし

Orionが目指していることは、CEOのブログで説明されています。

方向転換というより、従来のPrefectの方向性

  • 通常のPythonコードに近い感じで書ける
  • ローカルでの開発を便利に

をさらに進めたいように感じました。

DAG-free

  • 表現力(ストリーミング、動的な依存…)と、 デベロッパーエクスペリエンスの点で、従来のDAGは制約となっている
  • DAGのようにワークフロー全体を事前に定義するのではなく、実行時に定義することで制約をなくし、 通常のPythonコードのように書けるようにしたい(「code as workflow」)

developer experience

  • 通常のPythonコードのように書ける・ローカルで実行できる(前述の「code as workflow」)
  • スケジュール実行以外は、 Orion Server無しでも同じように実行できる(「ephemeral Orion API」)
  • 広く使われているツールの上に実装することで、採用コストを下げる

※ 通常のPythonコードのように書ける例として、subflowの書き方の変化が紹介されています

youtu.be

orchestration as a service

  • オーケストレーションを、jobの実行ではなく、状態推移を管理するルールと定義
  • Orionではわかりやすいルールエンジンを書いた。これにより、推移した理由がわかりやすく説明できるようになった

機能のはなし

公式ページに大量に機能や、実装の方針が列挙されています(下図)。 ただし、Orion固有ではなくPrefectでも実装されている機能も記載されている気がします(VersioningやMapping)。

個人的には

  • Prefect IDE
  • Serverless Execution
  • The flow never stopps

あたりの記載が気になりました。

www.prefect.io

f:id:toukoudo:20211210094504p:plainf:id:toukoudo:20211210094507p:plainf:id:toukoudo:20211210094510p:plainf:id:toukoudo:20211210094514p:plain
機能たち

Data Pipelines with Apache Airflow読んだ

learning.oreilly.com

内容

  • Airflowの概要
    • ワークフローエンジンのご利益
    • 提供する機能の概要(スケジュール、DAG)
    • Airflowを選ぶ理由、選ばない理由
  • Airflowの入門
    • DAGの例
    • Task・Operator
    • Airflow UI
    • スケジュール
    • テンプレート
    • Task間の依存定義
    • トリガー
  • 外部システム(S3やRDB)との連携
    • Operator、Hookの例の説明
  • 独自のコンポーネントの作り方(Operator、Hook、Sensor)
  • テスト
  • Airflowとコンテナ
    • PythonOperatorだと依存関係大変になるので、DockerOperator・KubernetesPodOperator使う話
  • ベストプラクティス
  • 本番デプロイ(Executor、ログ、監視)
  • セキュリティ(認証・認可)
  • クラウドサービス   * Azure、GCPAWS、Astronomer
    • (著者の一人がAstornomerの中の人ですが、意外とAstronomerの話題少ないです)
  • サンプル・プロジェクト
    • タクシーデータをAPIで取得して、変更

その他

  • Airflowは2系で大きく機能が増えましたが、この本は基本的に1系(1.10?)です。一部2系に関する補足説明があります
    • TaskFlow API
  • いくつかAirflow以外の話題がありますが、それに関しては説明があるので予備知識なくても大丈夫だと思います
    • pytest
    • Dockerコンテナ
    • Sagemaker

著者

  • Bas Harenslakさん
    • AstronomerのSolution Architect・Airflowのcommitter
  • Julian de Ruiter さん
    • GoDataDriven(データエンジニアリングのコンサル会社)のデータサイエンティスト・MLエンジニア

感想

  • 一冊まるごとAirflowな、(たぶん)初めて・唯一の本。Airflow使うなら読んで損はないかと
    • 本以外なら、公式ドキュメントかUdemyにいくつかコース()が良さそう
  • 入門の章は公式ドキュメントで十分かも。テストとかベストプラクティスあたりの価値が高いと思う
  • 他のワークフローエンジンとの比較(e.g. DagsterやPrefect)はあまりないです
  • Airlfowの「できるけどやらない方がいい事」、「やるなら注意してやるべき事」を説明してくれているのが、良きかな
    • 「ストリーミングデータの処理」とか「xcomに大きなデータ入れる」とか「動的なDAGを書く」とか
    • Airflowは分散Python行基盤なので、いずれもやろうと思えば出来てしまうので、↑のような制約の把握大事
  • execution dateの説明に一節丸ごと使っているのが面白い。Airflowでわかりにくい&引っかかりやすい概念なんだな

今更ながら分散システムデザインパターン読んだ

この本は

  • 原著は2018年、翻訳は2019年
  • 著者のBurnsさんは、GoogleMicrosoftKubernetesの開発をしていた・している人
  • 書名の通り、複数のノードで処理を行う場合の色々なパターンを解説している本
    • また、副題(コンテナを使ったスケーラブルなサービスの設計)の通り、コンテナ・Kubernetesを例にした話が多い(が、それに限定されない)

内容

  • スケーラブル、疎結合にするため分散システム増えたよね
  • パターンを知っておくと良いよ
  • 各パターン(12個?)の紹介。各パターンに関して、おおよそ以下の記載
    • 概要
    • 使用する例
    • ハンズオン(Kubernetesの上でnginxやConsul等)

紹介されているパターン

感想

  • ぼんやり思っていた概念に、名前与えられて言語化できた気がする。思考の節約や議論の共通化に良さげ
    • 一章に記載されている、パターンとして学ぶことのメリット
  • 「オーナーシップ」の章を読むと、分散システムで(正しく)ロックするの大変だなーとの思い
    • 分散でなくても大変だろうけど
  • ワークキューの話でメッセージの重複(exactly-onceとか)の記載が(多分)無いのが意外。新しい概念なのかな?

「Software Engineering Daily:(1273)AWS with Pete Cheslock] 」聞いた

Podcast Software Engineering Daily
エピソード (#1273)AWS with Pete Cheslock |

# 1273~1277 |

公開 2021/06/7
トピック クラウド
ホスト Corey Quinn(代理ホスト) |

ゲスト Pete Cheslock(#1273, AWS回)、Allmaの人

コンテキスト

聞き取ったこと

  • JEDIの話
  • サービス・アップデートが多いのでついていくの大変
    • どれが重要なのか
  • AWSの開発スピード
    • 早いし、顧客が多いのでフィードバックも多くもらえる
    • フィードバックの聞き取りどうしてるんだろうね。アカウントマネージャだとスケールしないのでは
    • 最初の方は駄目なこともあるので、後で検討する時は、思い出すのではなく、再度確認すること大事
  • 製品をdeprecationしないのがすごい
    • 放置はするけど、deprecationにはならない
    • SimpleDBと古いインスタンスクラスが例
  • Two Pizza teamの文化が強い
    • 製品で画面が違うのはこのせい
  • 歴史の話
    • S3の登場はすごかったが、みんなが理解するのに時間がかかった
    • 最初の頃は競合いなかった
    • データの移動は難しいので、最初にS3にデータをどんどん入れさせることで、AWSからの移行の可能性が下がった
  • "old guard enterprise"の話。Microsoftが強いね
    • ストーリの伝え方
    • 40年に渡る存在感と、欠陥を誤り続けた経験、ActiveDirectoryなど
      • 壊れる時は壊れる

「Software Engineering Daily:(#1277)Oracle Cloud with Salman Paracha」聞いた

Podcast Software Engineering Daily
エピソード (#1277)Oracle Cloud with Salman Paracha
# 1273~1277
公開 2021/06/11
トピック クラウド
ホスト Corey Quinn(代理ホスト)
ゲスト Salman ParachaOracle回)、OracleのGroup Vice Presidentの人

コンテキスト

聞き取ったこと

  • ゲスト(Salman Parachaさん)は元々AWSの人、今はOracleの「Group Vice President, Cloud Engineering Cloud」
  • 「second generation cloud」の話
    • Oracleの用語っぽい
    • レガシーなソフトウェアを使っている顧客が移行しやすい点を重視
    •  オンプレからlift and shiftの例として、L2レイヤーの話
  • 費用のメリット話
  • Oracle Cloud顧客の例
    • VMWareのユーザ
    • HPC
    • Independent Software Vendor(Zoom)
  • Oracle Cloudの投資の話
    • AWS/Azure/GCPが「multiple tens of billions」を四半期に設備投資しているが、Oracleはしていないのでは?とのツッコミ
  • オンプレ移行の話
    • 冗長性を維持しつつ、小さな規模で初めて、線形にスケールできる
    • 規制やレイテンシでクラウド移行が難しい顧客のために、Oracle Cloud一式をデータセンターに配置することもできる
  • データセンターにOracle Cloudを配置する Cloud@Customerの話

    • 2000平方フィート(185平方メートル)、50万ワットをデータセンター内に確保してくれれば、Oracle Cloudのリージョン一式を持ってこれる      

      感想

  • エンタープライズ企業・オンプレからの移行の話題が、他のクラウド回より多い印象

  • 「linearly scale」という用語が頻繁にでてきた。何かアピールポイントなのかな
  • 全般的にOracleに対する当たりが強い
    • Oracle, one of the most hated names in tech in some ways」
    • 「People will complain about Oracle, the overall company, without any provocation. And let's be honest, a lot of this is very well deserved」