Sentry をローカルの Docker で動かす

docs.sentry.io

これです

この公式マニュアルが割と不親切で、半年ちょい前にもやったのに詰まったので記録

$ git clone git@github.com:getsentry/onpremise.git
$ cd /path/to/getsentry/onpremise
$ make build
$ docker run --detach --name sentry-redis redis:3.2-alpine
$ docker run --detach --name sentry-postgres --env POSTGRES_PASSWORD=secret --env POSTGRES_USER=sentry postgres:9.5
$ docker run --detach --name sentry-smtp tianon/exim4
$ SENTRY_SECRET_KEY=$(docker run --rm sentry-onpremise config generate-secret-key)
# .bashrc に入れるなりしたほうがいいかも
$ docker run --rm -it --link sentry-redis:redis --link sentry-postgres:postgres --link sentry-smtp:smtp --env SENTRY_SECRET_KEY=${SENTRY_SECRET_KEY} sentry-onpremise upgrade
# 中略
Created internal Sentry project (slug=internal, id=1)

Would you like to create a user account now? [Y/n]: Y
Email: pasora@example.com # 多分なんでもいい
Password:
Repeat for confirmation:
Should this user be a superuser? [y/N]: y
User created: pasora@example.com
Added to organization: sentry
# 略
$ docker run --detach --link sentry-redis:redis --link sentry-postgres:postgres --link sentry-smtp:smtp --env SENTRY_SECRET_KEY=${SENTRY_SECRET_KEY} --name sentry-web-01 --publish 9000:9000 sentry-onpremise run web
$ docker run --detach --link sentry-redis:redis --link sentry-postgres:postgres --link sentry-smtp:smtp --env SENTRY_SECRET_KEY=${SENTRY_SECRET_KEY} --name sentry-worker-01 sentry-onpremise run worker
$ docker run --detach --link sentry-redis:redis --link sentry-postgres:postgres --link sentry-smtp:smtp --env SENTRY_SECRET_KEY=${SENTRY_SECRET_KEY} --name sentry-cron sentry-onpremise run cron

んー、とりあえず起動するけど初期設定がうまくいかない

ポストモーテム

今春(平たく言えば) SRE の部署に異動したのでもろもろ勉強中なのだが、
マネージャーが
cloudplatform-jp.googleblog.com を指して
「この会社に最も足りないのは『非難を伴わない障害報告書を記録するカルチャー』だ」
と言っていた。

社内に障害報告を行うためのツールはあるのだが、
エンジニアがビジネスサイドに説明するためのツールにもなっているという側面があるために
サービスへの影響がどの程度だったか、再発防止策は何かというところに重点が寄っている。

思い返すと、鉄道業界はこのあたりのカルチャーがしっかりしていると感じる。

トラブルが起こるとマネージャーがエンジニアから聞き取りを行ってレポートを作成するが、
当時オペレーターが持っていた知識と経験から何を考えて何を行ったのか、
使っていたツールなどの挙動/反応を限りなく細かく記録していくことが重視される。
場合によっては作業者の睡眠時間、健康状態、精神状況までも記録対象だ。
作業ログが残っている場合はそれらも全て引用した上で、
非難されるというよりは正直に全てを話すように言われる。
「必ずミスは起こる」ということを全員が常識として持っているので、
その記録から可能な限り学ぼうとするのだ。

他チームを含めて全てのエンジニアが学ぶべきと判断された場合は
報告書の概要と再発防止策が1枚の紙にまとめられ、
各チーム執務エリアの壁にしばらく貼られることになる。
エンジニアが出勤したときには読むことが必須で、
内容を確認したら捺印することになっている。
捺印した数日後にマネージャーその内容を抜き打ちで
確認されることもあるため流し読みでは済まない。

重いインシデントに関しては月に1度行われる全体会議で振り返りが行われるが、
時には自チームや自社にとどまらず他社の事例も取り上げられる。
「ヒヤリハット」程度の事案でもエンジニア内の
ローカル SNS のようなもので雑談と共に共有される。

以上単語を無理やり IT 業界っぽく置き換えたので伝わりづらいかもしれないが、
とにかく日常のコミュニケーションに占める事故に関する割合が多い。
常に KYT を行う文化があり、起こった事故に対して後ろ向きではない。
事故を起こした本人は落ち込むが、周囲が「今回たまたま君が引いただけだ」
「昔自分もやった」「誰だってミスを起こす」とフォローに入る。

さすが一歩間違えれば人命に関わる社会インフラを支える企業、と言うのは楽だが、
実際ここまでのチームを作っていくのは人材の入れ替わりの激しい IT 業界ではなおさら難しい。

せっかく事故防止に関して強いカルチャーを持つ組織を経験したので
なんとか今後の仕組み作りに活かせないかと考えている。

香港で AIRSIM の開通に困った話

つながらない

香港旅行に行くのでインターネットどうしようと調べていて、

www.airsim.com.hk

という、1枚の SIM カードを挿しておいて、世界各国対応したプランを買っておけば
それぞれの国でローミングして携帯電話の通信ができるというサービスを見つけた。

Amazon でこの SIM カードを買い、プランを買っておいたので
現地に着いて端末を何回か再起動すればつながるだろうと踏んでいたのだが、
空港着いてからどんだけ待っても何度再起動してもパケットが通らなかった。

この時点ではアンテナピクトは5本立っていて、「4G」やら「3G」やらが横に表示されない状態。

APN を設定しないとダメ

Nexus 5 を貸した同行者は、同様の事前準備で
自動的にインターネットに接続できる状態になっていたので
ネットワーク設定を見比べていたところ、自分の端末では APN 設定が無いことに気が付いた。

APN 設定

答えはこれだった。
単に APN 名に cmhk と入れるだけだ。

恐らく端末特有の問題

Nexus 5 はグローバルモデルのスマートフォンなのですんなり行って、
自分が使っていたのは Xperia Z4 Tablet ドコモ版 (SO-05G) の SIM ロックを解除したものだったので
そもそもドコモ以外の設定は持っておらず、AIRSIM のアプリもそこまで設定してくれなかったのでこうなったのだろうと予想している。

同じ問題にはまっていた同行者の端末も日本製の SIM フリー機だったので、
日本の各 MVNO の設定は持っているが…ということなのか。

インターネットの設定にインターネットが必要

今回は偶然うまくいった同行者がいたので助かったが、
肝心の APN 名が書いてある AIRSIM のアプリがインターネットにつながっていないと
何もできないので、これでは本末転倒ではないか。

空港には Wi-Fi が飛んでいるので空港でやればいいというのはあるのだが、
自動でうまくいかなかった場合の接続方法くらいアプリの中に入れておいてほしい。

ちなみに別の同行者の iPhone 7 は未だにつながらない。困った。

このポストが用心深い日本人の目に留まって役に立つことを願う。

及川卓也さんの話を聞いてきた話

概要

に行ってきた。

全体を通して、コンピュータ、ネットワークの歴史から現代に通ずる部分を見出そうというテーマだった。その歴史の部分に関してはほとんど知っていたものであったので、それ以外で気になったものをキーワード単位で残す。

The best way to predict the future is to invent it.

No one can actually predict the future but we can be ready for it and that's largely our jobs as software developers. To be adaptive and be ready for the future.

コンピュータの進化

「おもちゃ」が世界を変えてきた

メインフレームを真面目に開発していた人たちからしたら、ミニコンは大した性能でもない「おもちゃ」にしか見えなかった
そのような「おもちゃ」が世界を覆うようになる

東海岸から西海岸へ

クローズドからオープンへ
NIH Syndrome (自前主義の終わり)

シリコンバレーというコミュニティ

どこの企業で何をやっているかは誰も気にしていない
「自分はこういう技術者で、今はたまたまこの会社で何をしている」
いかに自分の技術スタックをポータブルにするか

プラットフォーム戦略

なぜ OS とプロセッサという単なる部品のメーカーがパーソナルコンピュータ業界で覇権を握れたか
自分たちの上で他社が活動することでプラットフォーム自体が勝手に育っていくようにする

ウェブの発展

標準化してから実装ではなく、実装が標準化のプロセスに組み込まれている
rough consensus and running code

今どきのチャットツール

電子メールはインターネットでの企業活動が多くないうちに開発された一方、90年後半以降に多くの企業が営利目的で参入したためインターオペラビリティが一切無い

今後のソフトウェア開発

仮説検証をいかに小さな単位で回していくか
lean -> agile -> devops へ

プラットフォーム戦略を持つ

楽して稼ぎたい
10%増ではなく、10倍を目指せと言われたときに発想を転換しなければならない
創造性は制約を好む

今後、すべての企業はソフトウェアカンパニーになっていく

感想

この講演は、私の前ポストの続きとして行われたものである。及川さんも「実際の歴史からパターンを見ましょう」ということで始まった。
歴史は歴史として知っていたのだが、実際にその時代にソフトウェアエンジニアとして活躍されていた経験からお話が聞けたので良かった。

ちょっと話が外れるが、ちょうど最近

死ぬこと以外かすり傷

を読んだ。恐らくこれもパターン認識の類だと思うのだが、言っていることがほぼ同じなのだ。ただもちろんその表現や程度には相当の差があるのだが。
また及川さんが6年前に出演した をもう一度見た。これまた表現を変えて同じことを言っていることに気づいた。
こう気づけるようになっただけでも最近のもろもろの収穫は大きかろう。

まつもとゆきひろさんの話を聞いてきた話

概要

に行ってきた。以下メモ。

まえおき

現代は死にやすい

テクノロジーがむしろ人を不幸にしていることがある。

エントリーシートは史上最悪の発明

クリックひとつで数百社にエントリーできるのはテクノロジーっちゃあテクノロジーだが人事担当者も就活生も幸せにならない。

年寄りはポジションを既に確立している

若者はポジションを得るのに必死

その段階で罠にかかることが多い。

若いうちに無駄にする時間は無い

偉人を見ていても若い頃のほうが功績が大きいことが多い、Ruby を開発したのは27の頃。
20代は体力があり、思考も柔軟。(30代で遅いということもない)
とりあえず3年様子を見るなんていう暇はない。

学生時代と社会の違い

学生時代

万能性が求められる。苦手を克服するのがよい。均質性に価値がある。
戦前戦中のように代替可能な存在を育成されている。

社会

満点が無い。苦手を克服するという戦略が効かなくなる。
長所を伸ばし、欠点は他のリソースで補う。

ルールが変わっている

ちょっと考えればわかる社会でのルールの変化に気づかない、気づこうとしない人が多い。言ってしまえば社会みんなで学生気分。
それでも年寄りはポジションがあるので押し通せる。割を食うのは若者。

生存する裏技1

学生時代と社会でルールが違うことを認識する

組織の中で自分だけが気づいているならそれは武器になる。
自分の長所を認識することが大事。

生存する裏技2

取引

完訳 7つの習慣 人格主義の回復

7つの習慣にある、2者間での持続可能な取引は

• Win-Win
• No Deal

だけ。
持続可能でない取引からは逃げてもいい。

我慢しない

空気を読む必要はない。自分の直感に従うべき。取り返せないミスはそうそうない。

生存する裏技3

成功談はアテにならない

伝記が出る頃には社会が変わっている。そのままは使えない。
伝記を書く頃には本人が覚えていないし、話が盛られる。

パターン認識

成功者には、学歴でも資産でもなくパターン認識能力に相関があった。
過去の成功談からパターンを学ぶことが大事。

抽象化

抽象度が高いものは寿命が長い。アプリケーションの教科書よりもアルゴリズムの教科書のほうが長く使われる。
抽象化は特にこの職業で求められるが、漏れると途端に全体が崩れるので注意。

ブラック企業

プログラマ3大美徳

• 怠惰
• 短期
• 傲慢

これらは人間に向かっていくと悪い方向に行く。自分のプログラミングに向かっていくと良い。

労働とは

我慢に対するものではなく、価値創造の対価。
苦痛に耐えることが良いことではない。これは上から下まで総勘違いしていることが多い。
理不尽は拒否するべき。

残業時間増加

1. 集中
   優秀な人に仕事が集まる。
2. 感染
   「あの人が残ってるのに帰れない」
3. 麻痺
   「昨日も今日も大丈夫だったから明日も大丈夫だろう」

この恒常性バイアスは怖い。自分の認知に関わらず、死ぬときは死ぬ。

日本語

「頑張れ」はうまく外国語で訳せない。日本語はカジュアルに我慢を強要する言語。

直感に従う

興味は他人の決めた尺度で決める必要はない。

死なないためには逃げても良い。

頑張る、我慢するのは過程であって目的ではない。「こっちに行けば幸せになりそう」という直感に従う。

思い込みはインバリデーションのないキャッシュ

学生時代からの慣性はかなり大きい。現実は常に変わっていくことに気づくべき。 キャッシュミスのコストは積極的に払う。

逆張り

鶏口牛後。大多数が選ぶ選択肢より常に少数に回る。同調圧力には鈍感になる。

コントロール意識

人間は叱られた途端にコントロール意識を失い生産性が60%落ちる。
プログラミングで面白いのは万能感だよね。

インプット/アウトプット

インプットは差別化要因にならない。

アウトプットの邪魔をするのは思い込み

YouTuber は一見誰でもできるようなことをやっているが、やっているかどうかが差。
クオリティはとりあえず置いてやるしかない。

感想

以下感想。
とにかく Matz がいい人。あんだけの功績を残した人がこんなんでいいのかと思うくらい。
パターン認識はもともと得意だと思っていたがもう少し意識的にやってみるかと思った。なにか定量的にこの手の能力が測れる手段があれば教えてください。
残業時間が増える件はちょうど最近「麻痺」するまで体験したので身にしみた。危ない。生存戦略を持つぞ。
今現在、自分が社内でどうするか揺れている時期だったので、直感に従って空気を読まずにやっていこうと決心できた。話を聞けてよかった。

Mac セットアップ

Mac mini を買ったので、セットアップの記録です。

OS アップデート

キーボードまわり

fn キー

システム環境設定→キーボード→キーボード
F1、F2などのキーを標準のファンクションキーとして使用にチェック

キーのリピート

システム環境設定→キーボード→キーボード
スライダをどっちも右端に

入力ソース設定

システム環境設定→キーボード→入力ソース
英数(Google) と ひらがな(Google) だけにする

IME 切り替え設定

システム環境設定→キーボード→ショートカット
前の入力ソースを選択: ^スペース
入力メニューの次のソースを選択: ^⌥スペース

Google IME

一般
¥キーで入力する文字: バックスラッシュ

入力補助→半角・全角
アルファベット
数字
(){}[]
.,
”’
:;
%#&@$^_|`\
<>=+-/*
を変換前・変換中ともに半角に

その他
ログイン時に変換エンジンプログラムを起動するにチェック

Dock

システム環境設定→Dock
ウィンドウをしまうときのエフェクト: スケールエフェクト
(ジニーエフェクトが好きじゃない)

「ダウンロード」を右クリック
内容の表示形式: グリッド
(ファンはまっすぐ出てこないから好きじゃない)

Mission Control

システム環境設定→Mission Control
最新の使用状況に基づいて操作スペースを自動的に並び替えるを外す
(勝手に並び替えられると調子狂う)

ソフト

Thunderbird

JetBrains Toolbox

PlayMemories Home

Action Cam Movie Creator

True Key

パスワードマネージャは大事ですね

マカフィー リブセーフ

インストール完了して「お使いのMacは安全です」とかなんとか言っといて後から自分で開いてセットアップしないといけないのアホらしい

Google Chrome

ダウンロード前に各ファイルの保存場所を確認するを無効化

HWMonitor

Karabiner Elements

App Store

• Magnet
• Slack
• LINE
  設定→トーク
  サジェスト表示をオンをオフ
  設定→トーク
  送信方法: Command+Enter
• TweetDeck
• 夜フクロウ

Apple Watch でロック解除

システム環境設定→セキュリティとプライバシー→一般
Apple WatchでこのMacのロックを解除できるようにする
なんだこれすごい

ファイアウォール

システム環境設定→セキュリティとプライバシー→ファイアウォール
オンにする
デフォルトでオフなのは意味あるんだっけか

メニューバーに音量を表示

システム環境設定→サウンド→出力
メニューバーに音量を表示

Night Shift

システム環境設定→ディスプレイ→Night Shift

メニューバーの時計

システム環境設定→日付と時刻→時計
秒を表示をオン
日付を表示 をオン

トラックパッド

システム環境設定→トラックパッド→その他のジェスチャ
ページ間をスワイプをオフ

スクリーンショットに影を付けない

$ defaults write com.apple.screencapture disable-shadow -boolean true
$ killall SystemUIServer

ズーム機能

システム環境設定→アクセシビリティ→ズーム機能
スクロールジェスチャと修飾キーを使ってズーム にチェック

Hostname を変える

システム環境設定→共有→編集…

brew

• htop
• yarn
• tmux
• reattarch-to-user-namespace

ターミナル

環境設定…→プロファイル→シェル
シェルの終了時: シェルが正常に終了した場合は閉じる
環境設定…→プロファイル→詳細
VT100アプリケーションのキーパッドモードを許可のチェックを外す

ssh-keygen
GitHub に鍵登録
git config --global user.email
git config --global user.name

次の3月

今年が2018年で今は2月なので今が2018年2月ということにしよう。
日本語で「次の3月」がいつかと言われると、当然そろそろ始まる3月だろう。

英語がわかる人なら何が言いたいのかなんとなくわかるかと思うが、
以前「次の3月」と言いたくて "next March" と言ったら "next March?" と聞き返された。
よくよく聞いてみると、2019年3月と受け取られたとのことだった。

じゃあ2018年3月はどう言うかというと、"this March" らしい。
直訳すれば「この3月」だが、日本語で「この3月」という表現は
現在が2月であるというコンテキストでは通じない。
なんなら年始に当該年末を指して「この12月」なんて言ったら昨年末と受け取られかねない。

このことを考えていて、そういえば西武鉄道の駅の発車標が

1. こんど
2. つぎ
3. そのつぎ
4. そのあと

と並んでいるのを思い出した。
この日本語が正しいのかは全然わからないが、つぎが次ではなくてこんどが次なのだ(？)。
"this March" は「こんどの3月」で "next March" は「次の3月」ということか。よくわからん。

この理屈は英語だけなんだろうか。
英語話者に改めて聞いてみたら「そういうもんだからそういうもんだ」と言われた。

"next" という単語で「隣」を表すことがあるし
単に日本語の「次」とは違う意味を持っているんだろうとは思うが、うまい説明が欲しい。