giantneco’s blog

技術メモ

社内システムパフォーマンス勉強会 #0

www.slideshare.net

  • 見切り発車した勉強会の資料

下期勉強会

10月中は特に行動を起こさなかったが、上期同様に下期でも何か勉強会開こうかと考えている。 候補としては:

  • 詳解システムパフォーマンス読書会
    • 自分がまだ通読できてないので
    • 人をかなり選ぶんじゃないかと思う
  • CI
    • 需要は高そう
    • 勉強するってほどのことでもない気はする。どういう CI にするかはプロジェクトしだいだし
  • なにかプログラミング言語
    • 良さそうなのがあれば
    • 書いてみたもののあまり思いつかない
  • 機械学習
    • もう別の人がやっている

やっぱりよそのプロジェクトでの需要が分からないので、計画を立てづらい

ドメイン駆動設計勉強会の結果を発表した

www.slideshare.net

職場の部会で、今年の 5 月から 8 月あたりに行った勉強会の発表をやれと言われたときに作った資料。 15 分しかないので、DDD というよりは勉強会自体に関しての発表にした。

後々見てみて思ったのは: - まとめがない - 掴みの写真でも入れておいた方がよかったのでは?

直近で旅行行ってたんだからその写真を貼り付けておいてもよかった気がする。

LINE Developer Day 2017 に参加してきたメモ

ちょっと前の 9/28 に行われた LINE Developer Day に参加してきた。 半分くらいは会社見学のつもり。

セッションの内容としては「Developer」とあるように、 LINEが作成した OSS やプラットフォームについての紹介をするセッションが多かった。 大体のセッションはフロントエンドエンジニア向けという感じで、ちょっと前提知識に欠ける自分には厳しかった。 LINE でどういう体制でどういう働き方をしているか、というのに興味があったがそこら辺の紹介は少な目。

見てきたセッションは以下:

  • Opening Session
  • The Technologies in Clova
  • Central Dogma:LINE の Gitをベースにした高可用性サービス構成レポジトリ
  • Paying back technical debt - LINE Androidクライアントの事例から -
  • なぜLINEではウェブトラッキングシステムがフロントエンド開発チームによって構築されたのか
  • HBase at LINE 2017
  • LINE Login - new features and mechanism
  • Verda Cloud Family
  • セキュリティのためのデータ分析 / ログ分析プラットフォーム Monolith と LINE Spam対策の現状

個人的に面白かったのは Paying back technical debt のセッション。 LINE の Android チームは技術負債の返済のため次のようなことをしていた。

  • コードの改善
    • Kotlin の採用
    • ReactiveX, Data Binder の採用
    • コーディングスタンダードの設定
    • ベストプラクティスに従った実装をすることによる制
  • CIの改善
    • コード変更の支援
      • PR 作成の手伝いをする Bot の作成
        • 対応する PR を確認しやすいようにリンクを生成したり
        • レビュアーの提案を行ったり
    • ブランチマージャーでの定期的なマージ
    • ルールの強制
      • issue を管理する Bot の作成
        • PR に BTS 番号を記述するように強制
      • ライブラリのバージョンを監視
        • 新しいバージョンが出た場合にすぐに対応できるようにする
  • チームの改善
    • 技術負債の支払いを属人化させないためにチーム文化も変えた
    • チーム文化の改善
    • 知識共有

CI と Bot は結構相性良さそうだ。 あとインストール手順とか、バグの再現手順とかをコピペして実行できるようにするのはまねしたい。

余談だが LINE のノベルティはかなり豪華だった。定番のシールに加えてマグカップと四葉のクローバー栽培キットがついてくる。

ロシア行ってきたメモ(準備編)

2017/9/15 から 2017/9/23 まで夏休みとしてロシアに旅行をしてきた。

このエントリでは旅行する際におこなった準備について説明する。 観光編?気が向いたら書く。

なんでまたロシアに行こうとしたのか?

  • 5 月にカンボジアに行ってきたがその時にしばらく暑いところは行きたくないなあ
  • → じゃあ次は北の方に行こう
  • → 「北欧が好き!」や「女シベリア鉄道一人旅」などを読む
  • フィンランドあたりもいいけど行きやすいところはなんか嫌だ
  • → ロシア調べてみるとビザは必要なものの、経済制裁ルーブルが割と安い
  • → ビザも頑張れば一人で取れる
  • → じゃあロシアに行ってみるか

ホテルと移動手段

ホテルと飛行機は毎度の通り Expedia.com で購入した。 結構長めに休みを取ったので、モスクワとサンクトペテルブルクの2箇所を観光する予定にした。 キジ島なども見たかったが、黄金の環などの郊外になると1,2日くらい軽くかかりそうなので都市近辺だけを見て回ることにした。

鉄道に乗りたかったので、モスクワ・サンクトペテルブルク間の移動にはサプサン号を使用することに決めた。

こちらの予約は検索して広告に出てきたRussianTrainsを利用した。鉄道チケットのオプションでバウチャーを発行してくれるようだったので、ついでに購入するようにした。

ビザ

ビザ取得の大まかな流れとしては:

  • ホテルの確定、海外旅行保険の取得
  • バウチャーの取得
  • ビザ申請書の作成
  • 大使館へ書類の提出
  • 大使館でビザの受け取り

のようになる。

まず宿泊先はバウチャーの申請に必要になる。特にホテル側への申請などは必要ない。 また海外旅行保険はビザ申請書作成の際に入力欄があるのでこれに保険証番号を入力するのに使用した。

バウチャーは事前に調べていたTravelRussia.su を利用しようと考えていたが、前述の RussianTrains で鉄道チケットと同時購入できるようだったのでこれを利用した。 チケットの購入後にバウチャーに必要な情報を入力し、一日二日くらい待つとメールでバウチャーが送られてくる。 必要な情報を入力する際は、宿泊地とその住所を英語で入力しておくと、サイト側で足りない情報を補ったうえでバウチャーにしてくれる。 バウチャーは印刷して大使館へ提出する。 バウチャーの正確な値段は忘れたが、1400円位だったかな?たいして高くはなかった。

次に在日ロシア大使館のサイトでビザ申請書を作る。 日本語が選択できるので、特に困るようなことはないと思う。 順次入力していくと、pdf が作成される。こちらも印刷。写真張り付けて、サインもしておく。

書類がそろったので、8/10 にロシア大使館にビザ申請に行った。 個人ビザの受付は午前中しかしていないので、10時ごろに東京の在日ロシア大使館に向かった。 大使館に入って右側がビザ受付。番号札を引いて待つ。 番号は呼ばれず、置いてあるモニタに現在の受付番号が表示されている。 その日は混んでいたらしく、10時に番号札を引いたが結局12時ごろにようやく受け付けてもらえた。 パスポートを大量に持った人がいたが、たぶんビザ申請の代行業者だと思う。

真ん中の 2 番カウンターで書類とパスポートを提出し、ビザの受け取りまでの日数を伝える。 営業日で 10 日以降にすると無料でビザが作れるので、10 日以降の受け取りを希望する。 すぐに隣のカウンターに進んで、ビザと引き換えになる黄色いレシートをもらう。 ちなみにビザはパスポートに直接印刷されるので、ビザを受け取るまでパスポートは預けたままになる。

営業日で 10 日後、つまり 14 日後の 8/24 にビザを受け取りに行った。 今度は直接 3 番カウンターに並び、黄色いレシートを渡してビザが印刷されたパスポートを受け取る。

以上のように、書類を入力する面倒くささと大使館までいかないといけない面倒くささはあったものも、 料金はたいしてかからずにビザを取得することができた。

余談ではあるが、2017/8 からウラジオストクから入国の場合はビザの申請が簡略化されたようである。 移動できる範囲に制限があるが、そうとう簡単になったらしい。

なお、ビザを申請する際には次のブログ記事も参考になった - http://musyokutabi.net/archives/51819016.html

チケットの予約

チケットは以下を日本から予約した: - クレムリンの武器庫 - クレムリンの公式サイトから購入 - 共通チケットは買うのを忘れていたが、当日に券売機から問題なく買えた - マリインスキー劇場チケット - マリインスキー劇場の公式サイトから購入 - エルミタージュ美術館チケット - エルミタージュ美術館の公式サイトから購入

ここら辺のチケットの情報は検索すれば情報はいろいろ出てくる。

あとエカテリーナ宮殿の電子チケットもここで買ったが、これは現地で訪問前日になって購入した。 このサイトはちょっと不親切だったが、このブログ記事を見て何とか購入できた。[Visiting]>[Admissin & Hours]を選択して、book E-ticketsのリンクをクリック。 Catherine Palace historic interiorsのチケットを購入した。

ボリジョイ劇場の白鳥の湖もみたかったが、1ヵ月前の時点で売り切れになっていたのであきらめた。 相当前から予約しないといけなさそう。

ロシア語の勉強

Android アプリの Duolingo と NHK 新ロシア語入門を使用。 ほとんどの場所で英語が通じたが、ロシア語会話として覚えておいてよかったのは以下:

  • トイレどこですか
    • 「グジェ トゥアレット」といった感じの発音になる
    • 後はロシア語が分からなくても大体身振りでわかる
  • いくらですか
    • 「スコリカ ストイト」
    • 後の数字と合わせて覚えておくとよい
  • 数字
    • 聞き取れるとちょっとうれしい

またキリル文字は覚えておいて非常に助かった。 キリル文字で書かれるとパッと見てわからないものの、 実際読んでみると知っている英単語だったというパターンは結構あった。 ロシアだって外来語はあるわけで、新しい単語だとこの傾向は強い。

その他買っておいてよかったもの

旅行前にいろいろ買ったが、そこそこよかったものを挙げておく。

  • Bobby
    • 防刃など対盗難機能付きの多機能リュックサック
    • リュックサック裏にも収納があったのでリュックサックを開かずに、よく使うモノを出し入れできたのは非常に便利だった
    • 結構人気があるらしく東急ハンズビックカメラでも売っている。自分はビックカメラで購入
    • 通販で買おうとすると類似品が非常に多いので注意
  • Kindle Paper White 32GB マンガモデル
    • マンガをいれると普通の Kindle では容量が足りなくなるのでこの機会に切り替えた
    • ページ送りも速くなってて快適だった
  • ユニクロのウルトラライトダウン
    • ロシアでは外は寒くても室内は暖かいのでジャケットを脱ぎ着することは多かった
    • この点、このダウンは丸めてすぐにリュックサックにしまえたのでよかった

新宿 Geek Lounge 第2回に参加してきた

9/5に新宿で行われた新宿 Geek Lounge に参加してきた。 新宿 Geek Lounge はセプテーニオリジナルさん主催のイベントで、今回が2回目の開催になる。

Future of Reactive Architectures

今回の目玉はこの Jamie Allen さんのセッション。Jamie Allen さんは Lightbend(Scalaの考案者が創業したところ)からスターバックス(コーヒーを飲むところ)に移られて、現在ディレクターとして活躍されている方である。

タイトルは上記の通りだが、Scala と Reactive について詳しく触れるわけではなく、内容としては次のようなものだった

スターバックスでのソフトウェア部門の立ち上げ

  • スターバックスでのソフトウェア部門を立ち上げる際には、
    • ビジネス上の価値を出すことに重点を置いた
    • 未経験者も多かったため、どのように学ばせるかを模索していく必要があった
    • Scala関数型プログラミングスタイルで書くか、リアクティブプログラミングスタイルで書くかなどを部門のスタンダードで決めなかった
      • これは最初に集まったメンバーが何を得意としているか把握していなかったため
      • また FP も Reactive のどちらも大事にいsたかったため
    • 実装にあった手はメンバにとって一番やりづらい方式を採用するようにした
      • たとえば通信は Restful スタイルにした
      • 当然時間はかかったが、勘所をつかむことができた
    • チーム全体に関数型プログラミングやリアクティブをいきわたらせるのは難しい
      • とはいえ完全に理解していてもそれで価値を出せるわけではないのでそれでよい
    • チームをどうつくればいいか?
      • TypeSafe では、新しい人を加えられないチームがたくさんあった
      • 前提となる知識が深すぎて、新しい人を受け入れることができない

Starbucksのデータベース

  • データはどうしているか
    • Starbucks では AWS で構築し、IaaC を推進している(=自動化は進んでいる)
    • セキュリティはしっかり組み込まれている
      • Starbucksは銀行としての役割もある。これはプリペイドカードに結構お金が使われているため
    • Cassandra はいい
      • 一貫性には問題あり
      • アプリケーション側で担保している
      • 他のデータベースも検討中

最近のデータベース

  • CAP定理
    • 分散DBに関する制限
    • 一貫性をとるか、可用性をとるか?をこれまでは考えないといけなかった
  • Google Spanner
    • CAP 定理を克服している
    • 「TrueTime」という仕組みにより分散した状態でも一貫性を保っている
  • CockrouchDB
    • OSS版の Google Spanner
    • TrueTime はないが、NTP を使ってノードでどちらが先に起こったかを調べる
    • ただし、NTP は完全ではないので注意
  • CAP定理が間違っているという前提に立つと
    • 可用性に注意してから一貫性をやれば良さそう
  • FaunaDB というのがある
    • Calvin Fauna のペーパー
      • ネットワークパーティションは「相対的に」大した頻度で起きない
      • Calvin によると、分散したログに書き込むことはできる
      • そのあと順番を見ればいい
      • そのあとで一貫性をすべてのノードにPUSHすればよい
    • CAP定理でなく、CAP else?

線形コンシステンシー

  • 線形コンシステンシー
    • 分散 DB が 5 つで、write consistency が 3 とすると
      • 3つのノードで合意を立てないといけない
      • 残りのノードに read が行行われていると、どんな値が読みだされるかわからない
    • read も同じように consistency をもつ
    • 時間で見て一貫性を担保するのも難しい
      • これは 100 % まではうまくいかないが十分信頼できる
    • Starbucksで気にしているのは順序
      • すべてのノードで値を読みだす必要がある
        • これに必要なのが線形 consistency

メモ:線形コンシステンシーについてはちょっとよくわかってない。後で調べておきたい。

まとめ

  • どこでも Reactive は必要か?
    • まあ、そう
    • しかし必要以上の苦労をしょい込む必要はない
    • ひとつのツールに固執するのは避けたほうがよい
    • 価値をだすためになにができるかをよく考えよう

LT

今回の LT は 1 つで、Scala の Future による並列・並行プログラミングの話だった。 - Future は ExecutionContext を定義して渡すことで挙動を制御できる - 例えばデフォルトではスレッドプールとキューの上限が両方溢れたらエラーになるが、 上限をなくしてしまうこともできる

感想

Jamie さんの話は思ってたのと違って Reactive の話はそれほどなかったが、 最近の分散 DB の話は追っかけていなかったので聞けて良かった。 特に Google Spanner は名前は知っていたが、CAP 定理を克服しようとしているというのは知らなかったので、これは結構驚いた。 Fauna DB と線形コンシステンシーの話はあまりよくわかっていないので、できれば調べておきたい。

Fortran 2003 の PROTECTED

相変わらず仕事で実装しているFortranコンパイラの話。

で、その時の作業としては他の開発者が実装したPROTECTEDの実装を確認しておかしい部分があったら修正する、くらいのものだった。 PROTECTEDっていったらJavaPROTECTEDみたく、継承した側でしかアクセスできないようにする修飾子でしょ?と思いつつ実装部分を見るとおかしそうなところはない。 ちゃんとPUBLICPRIVATEとは排他になっているみたいだし…

一応次のコードを書いて gfortran とエラー出力を比較してみることにした。

MODULE m
   INTEGER, PUBLIC, PROTECTED :: i
END MODULE m

ところがこのコードはパスしてしまう。Fortran の仕様書を見てみると次のようにあった。

A nonpointer object that has the PROTECTED attribute and is accessed by
use association shall not appear in a variable definition context (16.6.7) or
as the data-target or proc-target in a pointer-assignment-stmt.

要するに、参照結合した(つまり USE して見えるようになった)変数にPROTECTEDが付いていると代入が出来なくなるとのこと。 結局最初にされていた実装はかなり仕様から外れていることが分かったのでそこそこの量を修正することになった。

やっぱりどうも Fortran は名前が直感に反する用語が多い気がする。