何かを書き留める何か

数学や読んだ本について書く何かです。最近は社会人として生き残りの術を学ぶ日々です。

Yahoo! JAPAN MeetUp #9 EC技術カンファレンスに参加しました

私は統計警察でも統計ヤクザでもなければ無限警察でもない。

去る2017年2月18日にYahoo! JAPANにて『Yahoo! JAPAN MeetUp #9 EC技術カンファレンス』に参加した。 きっかけは先日参加した『Python 3.6 リリースパーティ』における宣伝である。 土曜日で気兼ねなく参加できるし、今の自分の仕事と重なる部分も多そうと思い参加した。 ヤフーのシステム的な内部事情も知りたいし、縁があれば面接を受けるかもしれないとも思ったからである。

以下に講演中に取ったメモとツイートを掲載する。 最初はメモを取っていたが、だんだん面倒になりツイートで代替した。

Yahoo! ショッピングの技術の話

  • ショッピングは1999年スタート。2012年に売り上げが前年割れして2013年にeコマース革命を行った。
  • 出店料無料、手数料無料。すると商品数3倍、店舗数16倍。
  • 2015年から11月11日(だったかな)を「いい買い物の日」と定めた。トラフィック量が急増。決済がダウンして偉い人に詰められる。
  • 中国アリババを訪問。トラフィックの平準化の秘訣を聞いたところ「お客様の買い物体験を優先させよ」というシステム面ではなくユーザビリティからのアドバイスを受ける。
  • カード後決済、サーキットブレーカを導入。2016年は乗り切った。
  • システム構成はPHPC++、たまにnode.js。今後はJava、node.js、C++でたまにPHPを使う。DBはOracle, MySQL, Cassandra, Redisを使っていく。
  • テクニカルディレクターとして意識しているのはトラブル検知の徹底、テストコードの徹底。
  • XPの導入、PaaSの導入、アリババのようなトラブルの自動検知及び自動解決を行っていきたい。

今後採用する技術としてJavaを選ぶあたりに、Yahoo!って大きい会社なんだなあという印象を持った。 開発規模が大きくなるとJavaの方がメリットが大きいのであろう。

これは「Q&A」のコーナーでFAQとして出てきた「どこでもオフィス」の利用率に関する回答に対する嫌味感想。 例えば、利用率の当初の想定が対象者の5%だったけど実際は10%も利用している、という状況でも「結構利用している」と答えて何ら違和感はない。 恐らく、割合を言えるほど利用者はいないのではと邪推するが、果たしてどうか。

ゼロからわかるヤフオク!システム超入門

ヤフオク!のシステムは米国Yahoo!ローカライズ版から始まったが2005年に日本独自システムが完成。 色々とレガシーな部分をどうにかこうにかリファクタリングを行っている。 現在の構成はマイクロサービスっぽい印象(そうは言っていなかったが)、かつFacadeパターンっぽい(Mediatorパターンも使っていたかも)。

これは「平行開発」という誤字を発見してほくそ笑んでいたらその誤字の真意に気づいてしまったツイート。

ヤフオク!の開発を支える技術

インフラチームによる発表でCIツールやらPaaSやらに関する話。 しっかりテストをしてるんだなー。

Yahoo! JAPANの決済 -これまでとこれから-

決済周りのシステムの開発の話。 縦軸に目盛りがない「単調増加」のグラフや言葉尻にかみついてみたりと自分の性格の悪さをひしひしと感じる。

ショッピングデータプラットフォームとデータ利活用

データプラットフォーム整備の話。 こんなに組み合わせがあります!というのをアピールするより好きな組み合わせで分析できる、のが主題である。 「可能性は無限大」と言っていたが、有限の選択肢なので高々可算である。

懇親会

ヤフオク!のインフラチームの方々、ショッピングのエンジニアの方、学生の方と雑談を行っていた。 料理はオードブルとお寿司であった。 場所が場所だけに(千代田区紀尾井町)怖くてお寿司を頼めない。

感想

日本インターネット業界の巨人『Yahoo! JAPAN』という見出しから始まる記事もある通り、ヤフーは日本のインターネットの代表の1つである。

codeiq.jp

その日本を代表するインターネット系企業の花形事業であるEC分野のシステムの様子を垣間見たのである。 その姿は、最新技術をどんどん取り入れて所謂イケてる企業、という姿ではなく長年インターネットを支えてきた、レガシーとなってしまったシステムと戦う姿であった。 システムの由来が米国Yahoo!であるものも多かった。利用者も非常に多いのでサービスを稼働させながらのリファクタリングは相当難しいだろう。 クラウド化も進んではいるものの、という印象。自前でできてしまうという面もあるし、AWSに移行させてもメリットが少ないのであろう。

社内がカンパニー制で区切られているが、カンパニーごとに文化が微妙に異なるらしい。良いことなのか悪いことなのかはちょっとすぐには判断できない。

「縁があれば面接を受けるかもしれない」と書いた。果たして僕は応募するだろうか? 率直な感想を綴ると、僕のスキルセット(Python少々、AWS少々、学部数学科レベルの数学(?)、修士(工学))とかみ合うだろうか?という思いがある。 事業は面白そうであり、全国規模(世界規模?)なので影響範囲も大きくやりがいもありそうである。 スキルに関しては今後伸ばせばよいではないか、という話でもあるのでかみ合わなそうだからやらないというのは違う気もする。

最後に、Yahoo!のスタッフの皆さんは丁寧に誘導を行ったり対応を行ったりしてとても楽しく時間を過ごすことができた。 楽しく時間を過ごしておいてグラフにケチをつけるという恩を仇で返す行為を平然と行う自分の行為を恨みつつ…。

Python 3.6 リリースパーティに参加しました

マイクを持って話す。これぞ文明の機器。

去る2017年1月31日にヤフージャパンにて「Python 3.6 リリースパーティ」が行われた。 pystudy.connpass.com

当初は一般参加のつもりであった。 石本さんのPython 3.6に関する一連のエントリを読んでクラス生成に関する新機能が『Effective Python』のメタクラスに関する項目で使えることに気づいた。 自分でも書いてみたら思いのほかきれいにかけたので発表してみようかと思い立った。

以下、感想を簡単に綴る。

開会

@atsuoishimoto 「Python 3.6 の新機能と改善」

www.slideshare.net

フォーマット文字列内部でエスケープが使えないのははまりポイントになりそうである。

@Masahito 「PEP526 and 周辺ツールについて」

www.slideshare.net

型チェッカのデファクトはmypyという認識であった。 単独で使うと効果が薄そうなので何かのツールにフックさせて適宜チェックすると効果がでそうである。 PyCharmを使うとよしなにやってくれそうである。

@t2y 「async関連」

speakerdeck.com

非同期には詳しくない、といいつつもここまで調査できてすごいなあと感じた。 中々非同期処理は慣れないのでいち早く武器にしたい。 そのためには項目40をasyncで書き直すのがよいであろう。これは読者への課題としよう。 (松坂和夫『集合・位相入門』に頻出する表現)

@CardinalXaro 「Effective Python in Python 3.6」

speakerdeck.com

色々とボケを考えてきたものの、概ねまじめに話していた。 多角形ときれいに発音する自信がなく、ポリゴンがとっさに頭に浮かんだのでつい口に出してしまった。

@terapyon 「この10年の Python

着実にPythonが進化してきた歴史を感じる。 僕が最初に触ったPythonはSage Mathなので恐らく2系であるが、Python単独で学び始めたのは3系である。学部3,4年の話なので3.2ぐらいと思われる。

@aodag 「Python3 移行への軌跡」

www.slideshare.net

こちらはPython3の移行の歴史でライブラリ側の進化を感じる。 AWS LambdaがPython 3に対応すれば恐らく新規にPython 2で開発することはないだろう。

最後に

スライド共有サイトにスライドをアップロードする経験ができてよかった。地味に憧れていた経験である。 関係者の皆様で発表する機会を得ることができた。 感謝の念でいっぱいである。

Python 3.6における『Effective Python』 項目35はこう変わる

項目35は言語に取り込まれた

Python 3.6がリリースされた。 Python 3.6で導入された新機能の一つに__init_subclass__がある、というのは前回の流れと同じ。

項目35「クラス属性をメタクラスで注釈する」はクラス定義後にプロパティを修正したり注釈を加えるといった機能をメタクラスで実現するという内容である。

class Meta(type):
    def __new__(meta, name, bases, class_dict):
        for key, value in class_dict.items():
            if isinstance(value, Field):
                value.name = key
                value.internal_name = '_' + key
        cls = type.__new__(meta, name, bases, class_dict)
        return cls


class Field(object):
    def __init__(self):
        self.name = None
        self.internal_name = None

    def __get__(self, instance, instance_type):
        if instance is None: return self
        return getattr(instance, self.internal_name, '')

    def __set__(self, instance, value):
        setattr(instance, self.internal_name, value)


class DatabaseRow(object, metaclass=Meta):
    pass


class Customer(DatabaseRow):
    first_name = Field()
    last_name = Field()
    prefix = Field()
    suffix = Field()


if __name__ == '__main__':  
    foo = Customer()
    print('Before:', repr(foo.first_name), foo.__dict__)
    foo.first_name = 'Euler'
    print('After: ', repr(foo.first_name), foo.__dict__)

この項目も PEP 487 -- Simpler customisation of class creation | Python.orgにある__set_name__を使うと簡単に書くことができる。

class Field(object):
    def __init__(self):
        self.name = None
        self.internal_name = None

    def __get__(self, instance, instance_type):
        if instance is None: return self
        return getattr(instance, self.internal_name, '')

    def __set__(self, instance, value):
        setattr(instance, self.internal_name, value)

    def __set_name__(self, owner, name):
        self.name = name
        self.internal_name = '_' + name


class Customer(object):
    first_name = Field()
    last_name = Field()
    prefix = Field()
    suffix = Field()


if __name__ == '__main__':
    foo = Customer()
    print('Before:', repr(foo.first_name), foo.__dict__)
    foo.first_name = 'Euler'
    print('After: ', repr(foo.first_name), foo.__dict__)

このように__set_name__を使えばメタクラスを定義せずに所望の内容を実現できる。

一連のエントリを振り返ると、項目33,34そして35はいずれもメタクラスを利用する内容であるが、Python 3.6からは__init_subclass__及び__set_name__で書き換えることができる。 メタクラスを使うとどうしても複雑になってしまうが、__init_subclass__及び__set_name__を使えばシンプルに書くことができる。 将来、『Effective Python』の項目33, 34, 35はメタクラスを使わない内容に更新されるであろう。