ロシア行ってきたメモ(準備編)
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 新ロシア語入門を使用。 ほとんどの場所で英語が通じたが、ロシア語会話として覚えておいてよかったのは以下:
- トイレどこですか
- 「グジェ トゥアレット」といった感じの発音になる
- 後はロシア語が分からなくても大体身振りでわかる
- いくらですか
- 「スコリカ ストイト」
- 後の数字と合わせて覚えておくとよい
- 数字
- 聞き取れるとちょっとうれしい
またキリル文字は覚えておいて非常に助かった。 キリル文字で書かれるとパッと見てわからないものの、 実際読んでみると知っている英単語だったというパターンは結構あった。 ロシアだって外来語はあるわけで、新しい単語だとこの傾向は強い。
その他買っておいてよかったもの
旅行前にいろいろ買ったが、そこそこよかったものを挙げておく。
新宿 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のデータベース
- データはどうしているか
最近のデータベース
- CAP定理
- 分散DBに関する制限
- 一貫性をとるか、可用性をとるか？をこれまでは考えないといけなかった
- Google Spanner
- CAP 定理を克服している
- 「TrueTime」という仕組みにより分散した状態でも一貫性を保っている
- CockrouchDB
- CAP定理が間違っているという前提に立つと
- 可用性に注意してから一貫性をやれば良さそう
- FaunaDB というのがある
- Calvin Fauna のペーパー
- ネットワークパーティションは「相対的に」大した頻度で起きない
- Calvin によると、分散したログに書き込むことはできる
- そのあと順番を見ればいい
- そのあとで一貫性をすべてのノードにPUSHすればよい
- CAP定理でなく、CAP else?
- Calvin Fauna のペーパー
線形コンシステンシー
- 線形コンシステンシー
- 分散 DB が 5 つで、write consistency が 3 とすると
- 3つのノードで合意を立てないといけない
- 残りのノードに read が行行われていると、どんな値が読みだされるかわからない
- read も同じように consistency をもつ
- 時間で見て一貫性を担保するのも難しい
- これは 100 % まではうまくいかないが十分信頼できる
- Starbucksで気にしているのは順序
- すべてのノードで値を読みだす必要がある
- これに必要なのが線形 consistency
- すべてのノードで値を読みだす必要がある
- 分散 DB が 5 つで、write consistency が 3 とすると
メモ：線形コンシステンシーについてはちょっとよくわかってない。後で調べておきたい。
まとめ
- どこでも Reactive は必要か？
- まあ、そう
- しかし必要以上の苦労をしょい込む必要はない
- ひとつのツールに固執するのは避けたほうがよい
- 価値をだすためになにができるかをよく考えよう
LT
今回の LT は 1 つで、Scala の Future による並列・並行プログラミングの話だった。 - Future は ExecutionContext を定義して渡すことで挙動を制御できる - 例えばデフォルトではスレッドプールとキューの上限が両方溢れたらエラーになるが、 上限をなくしてしまうこともできる
感想
Jamie さんの話は思ってたのと違って Reactive の話はそれほどなかったが、 最近の分散 DB の話は追っかけていなかったので聞けて良かった。 特に Google Spanner は名前は知っていたが、CAP 定理を克服しようとしているというのは知らなかったので、これは結構驚いた。 Fauna DB と線形コンシステンシーの話はあまりよくわかっていないので、できれば調べておきたい。
Fortran 2003 の PROTECTED
相変わらず仕事で実装しているFortranコンパイラの話。
で、その時の作業としては他の開発者が実装したPROTECTEDの実装を確認しておかしい部分があったら修正する、くらいのものだった。
PROTECTEDっていったらJavaのPROTECTEDみたく、継承した側でしかアクセスできないようにする修飾子でしょ？と思いつつ実装部分を見るとおかしそうなところはない。
ちゃんとPUBLIC・PRIVATEとは排他になっているみたいだし…
一応次のコードを書いて 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 は名前が直感に反する用語が多い気がする。
buildersocn に参加してきた 2
その 1 の次の日に参加してきたセッション。
静的解析とUIの自動生成を駆使してモバイルアプリの運用コストを大幅に下げた話
https://www.slideshare.net/takuyaueda967/ui-78581401
@tenntenn さんによる Go の話。
複雑な配信条件を記述するために Go 言語を DSL として使用している。
Googleが開発したニューラルネット専用LSI「Tensor Processing Unit」
@kazunori_279 さんによる TPU の話。
第1世代 TPU の話で、発表中に説明された特徴としては
以前に、TPU は 1 CPU サイクルで 16x16 の行列計算をしている、という話を聞いたことがあったが、 今回の話を聞く限りはスループットでの話のようだ。
Make you a React: How to build your own JavaScript framework.
@jbucaron さんによる JavaScript で Reactive フレームワークを作る話。
Reactive フレームワークで使われる仮想 DOM の仕組みと、それを実装する場合どうなるか、とうことをコードを交えて説明してもらえたので非常にわかりやすかった。
仮想 DOM の裏側ではやっぱり結構泥臭いことしているんだな。
OSS貢献超入門
https://www.slideshare.net/shigemk2/oss-78585757
@shigemk2 さんによる OSS に貢献するにはどこから始めるのがおすすめかという話。
結論は、好きなリポジトリを watch しよう。そのためには gitter などをスマホに入れておくのがおすすめらしい。
builderscon に参加してきた 1
builderscon に参加してきた。
オープニングセッションによると YAPC::ASIA の精神的後継であるとのこと。 セッションに統一したジャンルはないということだったが、 もともと Web 系のカンファレンスが前身だったらしくセッションもその傾向が強いようだ。
自分は若干門外漢な感じだが、カンファレンスのテーマ自体「知らなかった、を聞く」なのでまあいいんじゃないかと思う。実際、行ってきたセッションではとりあえずはずれはなかった感じである。
以下行ってきたセッションの感想。
DeepLearningによるアイドル顔識別を支える技術
@sugyan さんによる発表。 テーマとしては、Deep Learning 自体より、 それを実施するまでに使用した技術を紹介するようなセッションだった。
アイドル顔画像のクローリングから始まり、画像の回転のための OpenCV のために Docker で環境構築したり、ラベル付けを簡単にするためにWebアプリを作ったりと、ほぼ０から顔認識の実施までにどういうことをしたかが分かる良い発表だった。継続大事。
マイクロチームでの高速な新規開発を支える開発・分析基盤
@timakin さんの発表。
少人数・短期間でアプリのリリースをするためにどういうことをしたか、という内容で、 自分にとってはかなり知らない世界の話だった。 何をどう組み合わせればやりたいことが実現できそうか、というノウハウもすごいが、 それを手早く実現するために Infrastructure As Code を組織で実践できているのもすごい。
自分が同じようなことをやるとしたら環境構築の部分ですぐつまずくと思う。
あと CircleCI は相当すごいらしい。
複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ
@Shinpeim さんの発表。
ちょうど DDD を勉強していたので、 割と近い内容の話を実例を見ながら聞けたのはタイミングとしてもよかった。
State の部分についてはイメージがちょっとつかめなかった。単にモデルとして持っておくのとどうちがうのか。 コードは公開されてたと思うので後で目を通しておきたい。
あと Helper としていたのは DDD だと Service に当たるものなんだろうか。
Building high performance push notification server in Go
@cubicdaiya さんによる発表。
Notification の push 先が遠い場所にあるため高レイテンシになり、Go の非同期な並行処理で性能が出せたという話。 コード上ですごい特別なことをしているわけではないようだったので、やっぱり Go すごいなという結論になるか。
その他
ランチセッションは部屋が人でいっぱいだったので行かなかった。弁当も受け取り損ねた。仕方ないね。
社内 DDD 勉強会 #5
www.slideshare.net
社内で行う予定だった DDD 勉強会のスライド。 来週に延期になったので後で修正するかもしれない。 DDD本をとりあえず浅くカバーしたのでこれで一区切りつけたい。 もうちょっと技術的な話の方が人集められたんだろうか？
読んでで思ったが相当わかりづらい気がする。
社内 DDD 勉強会 #4
www.slideshare.net
社内で行った勉強会の資料。
内容としてはほぼ DDD に書いてあるとおり。 DDD 本自体は若干古いので、紹介されているリファクタリングの手法は割と古いのかもしれない。
DDD としてリファクタリングは必須だろうが、リファクタリング手法としては特に DDD 独自の変わったことをしているわけではないようだった。
