Make組ブログ

Python、Webアプリや製品・サービス開発についてhirokikyが書きます。

#stapy Pythonのコア開発者のパネルディスカッションでモデレーターをしました

f:id:hirokiky:20180914210903j:plain

photos.google.com

Start Python Club主催のPython Global Meetupというイベントで登壇しました。

https://photos.google.com/share/AF1QipPtD1KElDUYuK8aRbWrmA0YgMoEUiI9xdPiZlzJg1_jEbpi8VQRuQ5r7e-W8CdxjA?key=eEJsSUVZWExaZXExY0tJN21vYXd1UTZZMWtvckpR

このイベントのメインイベントであるパネルディスカッションで、司会をしました。

このブログはその次の日に書いています。 すごく良いイベントだったので、今のホットな気持ちで思うがままに書きたいと思います。

この会のスゴい点

このPython Global Meetup、本当にすごいイベントでした。 なぜか。間違いなく、登壇者の豪華さと、その人たちがパネルディスカッションをするということですね。

MarcさんはUnicodeをPythonに導入した人ですし、EuroPythonSocietyというEuroPythonを運営する組織の会長をされています。

稲田さんはBDFL deglegateとしてPythonの最終決定の一部を委任されていますし、CompactOrderedDictというPython3.6からの辞書の実装を作られた方です。

あつおさんはpython.jpを立ち上げていてかつ、Unicodeに関するPEPをAcceptされている方です。

Pavlosさんは金融、銀行の分野でオペレーションを自動化する企業をMarcさんと作っている方で、エンタープライズ領域でのPythonプログラミングの長い経験がありつつ、それをビジネスに繋げている人でもあります。

この豪華な布陣ですよ。 もはや、この中の1人だけでPyConのキーノートスピーチをできるんじゃないかというレベルです。

この方たちが集まるだけでもう十分というわけですが、野心的なのがこの4人でパネルディスカッションをするという点ですね。 その話を聞いただけで面白そうなことは間違いありませんが、誰が司会（モデレーター）をやるのかは難しいと思います。

そこで白羽の矢が立ったのが僕ということですね。

チャレンジングだったこと

チャレンジングな点は3つありました。

  1. ライブのパネルディスカッションであること
  2. Pythonの超すごい人が超深い話をすること
  3. 日英混合でのパネルディスカッションであること

当日うまく回るか全く分かりませんでしたが、周りの方のサポートもいただいて楽しいパネルディスカッションになって良かったです。

事前準備としてはPythonのコア開発についてやUnicode周りのPEP、登壇いただいた稲田さん、Marcさん、あつおさんのPEPを読み込んでいました。 あと、パブロスさんの興味分野が技術を使った問題の解決やビジセスサイドにあると事前に聞き、当日はなるべく「コア開発」に限らない質問に変えていました。

日英のパネルディスカッションで同時通訳は入っていましたが、司会者としてはレシーバーの設定を切り替えながら聞くのは不可能だと判断して通訳は聞いていませんでした。 ラグもありますし、ライブのトークでは通訳者さんに技術単語の共有もできないので僕がどのみち補足する必要もありましたので。

ただ今回かなり大変な、チャレンジングな機会でしたが、僕としては大きな自信になったなと思います。 司会としても話を回せるし、英語もその場でかなり話せることが分かったので良かったです。

知れたこと、面白かったこと

  • PythonのCompact Ordered Dictの実装は、メモリー効率や実行速度を狙った結果、副次的にキーの順序が保持されるようになっている。
  • Pythonのコア開発に触れるなら、やっぱりpython-devのメーリングリストを読むところから始めると良い
    • 日本の情報には限界があるので、コアの開発は英語を読もう
  • 昨今のOSS開発はテックジャイアントが強くサポートしている。どう変わってくるか、どう思うか
    • => 今までテックジャイアントはオープンソースの恩恵を強く受けてきた
    • 例えばmacはBSDベースにしているところが大きい
    • そのテック企業が大きくなってOSSをサポートしている現状は、恩返しとしてポジティブに受け取っている
  • Unicodeには目に見える1文字1文字と違うユニットに分けたような構造で内部的に階層、表現方法がある
  • MedusaというWebサーバーを書く基本になるようなライブラリー（Webサーバー？）がある
  • Pythonに貢献するというのは何もコア開発だけでない。Pythonを使ったり、知見を共有したり、PSFのメンバーに登録したり、誰かに教えてあげることも十分素晴らしい貢献
  • もし本家に貢献したいのであれば、Issueで簡単なことから手伝いができる
    • バグという報告の動作検証をする
    • 質問の適切な投稿場所を案内する
    • 足りない情報があれば質問したり、自分で調べて書き込んであげる

いや、パネルディスカッション中の参加者の方からの質問も良かったですね。すごい良い質問でした。

他に事前に調べてたこととしては、UCSやPythonの新しいUTF-8モード、Windowsでのロケールの扱いやLANG_CTYPEがCのときの扱いの変更などでした。ですが理解が深まって良かったです。 BDFL deglegateやPEPについてなど壇上で簡単に解説しましたが、伝わっていれば嬉しいです。

まとめ

とにかく、うまく話がまとまってかつ、来てくださった方にも楽しんでいただけで良かったです。 うまく伝えられていると嬉しいですが、難しいこともあったと思います。できればその分からなかった内容やスライドの内容を調べてみて、ブログなどにまとめてくれると新しいPythonへの貢献になるのではないでしょうか。

登壇者の皆さん、Python Start Clubの皆さん、この企画に誘ってくれた寺田さん、三菱UFJ信託銀行の皆さん、会場提供のFiNCの皆さん、ホンヤクの皆さんありがとうございました。 そして何より、参加いただいた皆さん、ありがとうございました。

Enjoy Python!

CodeMirrorでphrasesオプションを使ってUIを日本語化できるようになったという話

CodeMirror JavaScript

2018年8月25日にリリースされたCodeMirrorの5.40.0から、検索ダイアログなどのUIを日本語化できるようになりました。

New features

New method phrase and option phrases to make translating UI text in addons easier.

github.com

何が嬉しいのか

CodeMirrorの検索アドオンなどを使うとき、ダイアログ内の一部UIを英語から日本語に置き換えられませんでした。 例えば Search: や (Use /re/ syntax for regexp search) という文言が変更できませんでした （それほど難しい文言でもないので英語のままでも良いですが、置き換えられるとUI上、言語を統一できてキレイです）。

CodeMirror: Search/Replace Demo

phrasesオプションに指定して変更できます

phrases というオプションをCodeMirrorに指定して、置き換える言葉を設定できます。 プロパティーにキーになる文言を、値に変更したい文言を指定します。

以下の例では searchアドオンのフレーズ を置き換えています。

CodeMirror(targetElement, {
  ...,
  phrases: {
    'Search:': '検索:',
    'Replace:': '置換:',
    '(Use /re/ syntax for regexp search)': '(/正規表現/ と書いて正規表現で検索できます)',
    'With:': '置換する文字:',
    'Replace?': '置換しますか？',
    'Yes': 'はい',
    'No': 'いいえ',
    'All': 'すべて',
    'Stop': 'やめる'
  }
})

そうすると、表示される文言を日本語に変更できます。

f:id:hirokiky:20180903193303p:plain

文言がユーザーのAccept-Languageによって切り替わるわけではないので「国際化」とは呼べなそうですが、僕はかなりありがたい機能だと思います。

DjangoRestFrameworkのSerializerから関数/メソッドの結果をフィールドの値として返す

Django

DjangoRestFrameworkのSerializer（ModelSerializer）で、フィールドの値を関数/メソッドの結果で返したいことがあります。 これはバリデーションとしてSerializerを使うのでなく、モデルから辞書に値を変換したい場合の話です。

例えば、フィールドの日時が何日前かや、何かしら加工した値が欲しい場合です。 もちろんモデル自体にプロパティとして実装すれば疑問なくフィールドとして使えますが、そのSerializerでだけやりたい処理の場合はこの方法が有効です。

以下の例では Foo モデルに、 bar というフィールドでメソッドの結果を返すようにしています。 serializers.SerializerMethodField を使ってできます。この場合 bar はリードオンリーのフィールドになります。

class FooSerializer(serializers.ModelSerializer):
    bar = serializers.SerializerMethodField()

    def get_bar(self, obj):
        return obj.bar.title()

    class Meta:
        model = Foo
        fields = (
            ...
            'bar'
        )

SerializerMethodField に何も指定しないと、メソッド名は get_bar がデフォルトで指定されます。 メソッド名を特別に指定したい場合は SerializerMethodField("calc_bar") のようにします。

でもこのときにメソッド名もフィールドと同じ名前（上記では bar ）にしてしまうと、フィールドが無効になってしまうので気をつけてください。 （名前が被ってしまうので、クラス内の値として後に書いたものだけが有効になってしまう）。

www.django-rest-framework.org

Ansibleでファイルの存在確認にstatを使ったら大きいファイルには動作が遅すぎたのでやったこと

Ansible

Ansibleでファイルが存在しているかによって処理を分けたいことがあります。 そんなときは stat を使うとできますが、対象のファイルが数GB単位で大きいと処理が遅くなります。

下の例ではファイルが存在しないときだけ実行するタスクを書いています。

    - name: とあるファイルが存在しているかチェックする
      stat:
        path: /path/to/file
      register: the_file_stat
    - name: （ファイルが存在してないときだけやりたい処理）
      shell: ...
      when: the_file_stat.stat.exists == False

ですがこの stat は、ファイルをチェックするだけでなくてチェックサムなども計算してくれます。 かなり重いファイルの場合、この処理で時間がかかってしまいます。 ファイルの存在チェックだけで良い場合は、チェックサムは不要なので以下のようにして遅くなる原因の処理を無くせます。

    - name: とあるファイルが存在しているかチェックする
      stat:
        path: /path/to/file
        get_checksum: false
        get_md5: false
      register: the_file_stat

このIssueで自己解決してる人が居たので、参考になりました。

github.com

Ubuntu18.04でDockerのDNS解決がホストのDNSにならない問題の話

Ubuntu Docker

Ubuntu18.04でDocker (17) を動かすとホストのDNSの設定を使わずに 8.8.8.8 を使ってしまう問題がありました。

何が困るかというと、AWSで動かしている場合ローカルのDNSを使わずにパブリックIPを引いてしまうとSecurityGroupの許可設定が効かないことです。 例えば、コンテナー内部からデーターベースにアクセスできないなどの問題が起こります （システムの都合上ECSなど使わずにEC2にDockerを入れて自分で可動させています）。

github.com

原因としては、ホストPCで systemd-resolved を見る設定になっているのだけど、 その設定を使おうとしたDockerコンテナーが使えずに 8.8.8.8 にフォールバックしたみたいな話のようです。

systemd-resolved 伝わないようにしちゃうみたいな回避が効きますが、まぁあんまり良い気持ちではないですね。 上記のIssueコメントで紹介されています。

pay.jpでプランを変更すると変更前のプランの金額で決済される不具合（修正済み）に当たった

製品開発

注意書き

以下の本文は情報だけを伝えようと書いています。 この文章は個人や企業を評価する意図はありません。

本文

pay.jp で定期課金のプランを契約期間中に変更すると、変更前のプランの料金で決済される不具合に当たりました。 この不具合は現在（2018/08/09）、修正済みです。

2018年7月ごろに、有料のプランから他の有料のプランへ変更する際に発生する不具合でした。 例えば月額5000円のプランから3000円のプランに変更したとき、元の料金を返金後に通常3000円で決済されますが、決済が5000円になっていたという不具合でした

昔からあったというわけではなく、新しく発生した不具合でした。 プランの返金は有効にしていましたが、発生したケースが厳密にはどういう場合なのか私には分かりません。

pay.jp にSlackから問い合わせし、不具合の修正とお客様への返金の処理を依頼しました。 このとき追加で問題が発生しました。不具合の対応用の返金をする処理に間違いがあったらしく、該当のお客様にさらに決済されるという問題も起こりました。この重ねての問題も現在は返金にて対応いただきました。

pay.jp は2016年春ごろから導入しており、現在2018年までの2年間で不具合は2件目です （サービスの障害やメンテナンスは除く）。

おわりに

私個人としてはpay.jpさんには今後も頑張って欲しいと思っています。 一緒に良いサービスを作っていきたいと応援の気持ちがとても大きいです。

改めてになりますが、今回の不具合によってご迷惑、ご心配をおかけした方々、申し訳ありませんでした。 pay.jpさんも対応いただきありがとうございました。

クラウドファンディングは支援（バック）するときが気持ちの最高潮なのかなと思った

考え

www.kickstarter.com

クラウドファンディングは支援（バック）するときが気持ちとして最高潮なんじゃないかなって思ったという話です。

僕はクラウドファンディングが好きでKickstarterで色々眺めたり支援したりしています。 PebbleTime、PebbleTime2、HighPerformanceDjango、Magit、ガジェットっぽいものとかOSS系とかを見ています。

そのうちの一つ、以前DeusExAriaというプロジェクトを支援していました。 これはスマートウォッチに取り付けるデバイスで、腕の筋肉を検知してスマートウォッチの操作ができるというものです。

www.kickstarter.com

これはすごくないですか。

スマートウォッチを愛用している人であれば、ふと時計を見たときに簡単に操作するのであれば片手で済ませれば便利だなと思うと思います。 電車のつり革に掴まっているときなど、片手がふさがっているときは結構多いです。それを解決するDeusExAria、これはすごい、と。 支援したのは2年くらい前で、僕はPebble Timeが大好きだったのでそれと互換があるこの製品も支援しました。

支援したときはプロジェクトの支援を呼びかける動画を見返したり、ワクワクしていました。 Pebble Timeも最高でしたし、このとき気持ちの最高潮を迎えるわけです。

人間面白いもので、他に面白いことがあるとスッカリ忘れるものです。今になって完成した製品が届きました。

ただ残念なことにPebble用のリワードで支援したのに、そのPebble自体が死んでしまったのでAndroidWatch用の製品が届きました。 僕はスマートウォッチへの情熱を失っていたので、全く持って要らないものを手に入れてしまったことになります。 あー、なんとも悲しいスタートアップ支援、というお話でした。

ちなみに今はプロジェクト名が変わって Flicktek となっています。 このプロジェクトが成功したのは純粋に嬉しいのですが、僕の求めてたものとはミスマッチになってしまいました。

こんな感じで、クラウドファンディングというのは支援する瞬間こそが気持ちとしての最高潮で、プロジェクトが成功する瞬間や製品が届くのは2の次なのかなと思います （PebbleTime2はどうしようもなく成功してほしかったですが）。 クラウドファンディングは「何かを作ろう」とかのプロジェクトに、お金を払って応援する仕組みですよね。 そういう意味での支援したときが気持ちとして最高潮というのは間違ってないのかもしれません。

応援したい気持ちがあれば支援することはとても良いと僕も思いますし大好きですが、資産の流動性を失っている点や、失敗したときに返金されるかどうかは気をつけたほうが良いですね。 リワードがあっても自分の期待するものとは限りません。 自分の可処分所得というか、その中でも特に使って良い「寄付枠」みたいなものから使うと良いと思います（それにも増してクラウドファンディングは夢があって素晴らしいですが）。

技術書のクラウドファンディング PEAKS も僕もしょっちゅう見ていますが、支援貧乏にならないようには気をつけたいと思います。 見返りを期待しない程度に留めるのが良いのではないでしょうか。 そのほうが夢があって素敵ですしね。