Diary

@ssig33

Amazon Cloud Drive に入れてるゴミの掃除が 140 日ぐらいかかる見通しで、契約切れぎりぎりまでかかりそう、、、

19 Jun 2017 Mon 00:36

最近ユビレジではじめた Slack チャンネルの新しい運用 なんですが、ユーザーサポートから開発者への問い合わせが作成されると自動でそれに対応する Slack のチャンネルが作成される。それは開発者全体チャットみたいなチャンネルに通知される。ユーザーサポートから開発者に問い合わせがくる場合というのは、大抵なんらかのソフトウェアの不具合である。

するとその問い合わせにある問題について知識のある開発者がそのチャンネルに入ってあーでもないこーでもないみたいに議論しながら対応してサポート担当者やら関連する案件の提携先企業やらとやりとりする。また障害であればそこで対応作業の内容を逐次事前に通告して他のメンバーのレビューを仰いでから行う。結果についても遅滞なく報告する。

このようにしているといずれ障害や問題は解決するので、その時点でそのチャンネルはアーカイブして社内 Wiki に簡単な概要を作成する。概要には当然チャットログへのリンクを貼っておく。これは前 papix さんが LT かなんかで話していた奴をパクって始めた。

  • 障害対応の記録を確実に残してノウハウをチーム全体で共有すること

が本来の目的だったが、

  • チャット経由で複数人が素早く障害対応を行えるようになり障害時のチームとしてのレスポンスが大幅に向上した
  • リモート作業中の開発者でも的確に障害対応へ参加できるようになった

という効果があり非常によかった。トピックごとに Slack チャンネルを作ってガンガン捨ててゆくというのはありだと思う。少なくともスレッドでごちゃごちゃやっていくぐらいなら使い捨てチャンネル作ってしまえばいいのでは。

17 Jun 2017 Sat 23:45

IT 技術者に必要なコミュニケーションスキルとは何か というと、それはもう以下の二つに集約されます。

  1. 出来なさそうな時は出来ないと言う
  2. 作業単位は小さくして早めに報告する

1 に関してですが、出来ると言っておきながら出来なければそれは作業者の責任ですが、出来ないと言ってそのままチームとして改善がされずに出来なければそれはもう管理者の責任です。管理者としても早めに言ってもらえれば対処できるんだけど、、、みたいなふうに思ってることが殆どだと思うので、仕事がダルかったら早めに言うべきです。「えっお前さっきは出来るって言ってたじゃん」みたいなことを言ってくるタイプのリーダーがあなたの上司なら今すぐ転職先を探しましょう、まともなリーダーはどこにでもいます。

2 ですが、これは Pull Request は小さくしてくれという話

  1. Refactor hogehoge
  2. impl. hugahuga of pikapika
  3. impl. aaaa of pikapika
  4. Refactor pikapika

みたいな感じになっている Pull Request をレビューしたい人はいないです。あらかじめ分割して提出しておくとみんな幸せになる。

こういうのこそがコミュニケーション力、というか相手を思いやる心というか、そういうものと思う。

15 Jun 2017 Thu 14:50

http://diary.app.ssig33.com/263 これ書いてる

12 Jun 2017 Mon 23:22

天ぷら

12 Jun 2017 Mon 23:21

Heroku で静的サイト配信 したいみたいなことがたまにあると思うんですけど、 Heroku Container Registry + nginx でやると今は楽ですね。 Heroku で Docker コンテナを動かす場合、 EXPOSE とかはすべて無視されます。 PORT という環境変数経由で公開すべきポート番号がコンテナ側に通報されます。なので _/nginx を使ってあれこれする場合は以下のようにあれこれするとよいかと。

default.conf

server {
    listen       ${PORT};
    server_name  localhost;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

Dockerfile

FROM nginx
COPY contents /usr/share/nginx/html
COPY default.conf /template
RUN rm /etc/nginx/conf.d/default.conf
CMD /bin/bash -c "envsubst < /template > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'"

このようにして contents に配信したい静的サイトを入れておけば、

$ heroku container:push -a YOUR_APP_NAME

Heroku のインフラを使って静的サイトを配信できます。というか動かしてるのは単なる nginx なので、一つの Heroku アプリにディレクトリ切って複数アプリデプロイしたいとかそういうときにもこれは使えますね。 PHP でなんかやったりするときは便利かもしれない。

12 Jun 2017 Mon 15:51

PR とか 広告 とかタイトルに入れるとアクセスが 1/5 ~ 1/30 ぐらいまで減るんで 、まあそうしろとか言われると収入が 1/10 とかになって廃業せざるを得ないんですよ、あの人たち。お前廃業しろよ、って言われたら徹底的に話そらしながら抵抗せざるを得ないと思うし、まあださくなるのもしょうがないんじゃないですかね。僕もお前ら全員廃業しろよとは思ってるけど。

自分が今のヨッピーのあの立場に立たされた時に、ああいう醜態を晒さずに済むように、足場を複数持っておきたいと思った。

それはそうとしてああいう自意識が肥大しきった広告業界人はどんどん酷い目にあってほしいですね。

11 Jun 2017 Sun 12:27

最近流行りの JS フレームワーク

  • Angular: アメリカ
  • React: 東欧とロシア
  • Vue: 中国

というイメージがある、俺はロシアを信じる。

09 Jun 2017 Fri 23:31

山本七平 は非キリスト教徒への軽蔑意識と戦争による日本への恨みがあるのだからそのへん割り引いて読みなよみたいな長文を書きたいんだけどだるい、誰か書いてもいいよ。

08 Jun 2017 Thu 01:04

最近はあまり運用上の問題はおきていない

07 Jun 2017 Wed 15:13

そんなわけでフィードのオートディスカバリはつけた

05 Jun 2017 Mon 00:40

最近わりと雑になってて goroutine で再実行とかも特に考えずに非同期処理みたいなコードを書くことが増えてる。どうせ失敗してもいいだろみたいな前提に基く設計ということは考えてはいるんだけど。

05 Jun 2017 Mon 00:38

なんだかなあ

05 Jun 2017 Mon 00:37

だるい

05 Jun 2017 Mon 00:34

携帯電話ほしいんだけどほしい携帯電話はない

05 Jun 2017 Mon 00:33

コミュニティにすげー嫌いな奴がいるというだけで 最近ある OSS をあんまり使わなくなっていて(それが何かは言わん)、まあ不毛であり、不合理の極みではある。

ただやっていく段階で勉強会とかなるべくスルーしたいとかなると、こういうことになる。

05 Jun 2017 Mon 00:32

そういえばこのサイトフィードのオートディスカバリ着けてなかったん

05 Jun 2017 Mon 00:28

最近は War Thunder で SL が不足して困ってます

05 Jun 2017 Mon 00:28

404 not found

03 Jun 2017 Sat 17:22

Go 最初は br だの err だの i だのそんな変数名のつけかた頭おかしいやろみたいな気持ちになるんだけど気付けばまあ自分もなんの疑問もなく

 func chkErr(err, error){
}

とかなんとか書くようになっているのであった。関数の解決する問題の範囲を極限まで狭くしろとかなんとかまあ理屈は分かるんだけど、我々は残念ながら理屈だけの世界で生きているわけではないから最終的に人間は死滅していくのであった。人間は死ぬが故に非合理、これだけは忘れてはいかんと思う。

それからわりとありがちなのが

if err != nil {
  return result, nil
} else {
  return nil, err
}

みたいなことをしたいというやつ。 nil も返せるようにするためには成功時の結果をポインタで返せるようにしとかないといけないから、そうした事情もあって気付けばなんでもかんでもポインタで返すようになって、別にポインタにしなくていいものも速攻ポインタにする病みたいのに罹患するようになる。僕自身注意しないとこれをやってしまうし、ライブラリのコードを読んでもわりと多くの人がポインタ太郎になっている。

実際には return するものは関数の最初で初期化しておいて、処理が失敗してエラーになればまあエラーになったときの状態を返せばいいのであろう。関数を利用する側が err が nil でなければその結果の側については捨てればいいだけなので。

でもなんだかんだでいろいろな事情があって return するものを初期化する位置が後ろのほうにズレていって nil も返したいんですが〜みたいになる。やはりこれも人間は死ぬが故に非合理という話である、そこでちゃんと関数の設計をまともにして直す暇があればとりあえずプロダクトを動く状態に持っていってしまいたくなる。

03 Jun 2017 Sat 13:07

Rails 書けると次の転職有利だから 書けるようになっときたいみたいなことを複数人の有能な技術者から言われて、まあそんなもんかいな、と。

ちょっと便利な Web おじさんとしてやっていくのが今後のキャリア形成に向けていいことなのかどうか、ということを考えてみたけど、いずれにせよ出来るにこしたことはないのかもしれない。

03 Jun 2017 Sat 12:52

知識を得るための知識

  • 図書館のリファレンスカウンターというところにいって、こういうことについて書いてある本と Web サイトを教えてくれとかいうとわりといろいろ教えてくれる
    • Web サイトも教えてくれるというのがポイント
  • 自宅の近所の新規店舗とかそういうのは Instagram のハッシュタグ継続監視
  • 得た知識はなんらかの永続的な手段でまとめておく、この際一覧や再分類、コピーがいつでも可能な形にしておく
  • Google とかは知ってることをもう一度みたいとき、つまりブックマークがわりにでもする

こういう話が知識を得るための知識なのでは

02 Jun 2017 Fri 22:26

Github の Project 機能いつのまにかにかなり便利になっていて 、まずリポジトリごとだけではなくて、オーガナイゼーションに Project を作れるようになっている。あれを最初みた人はだれでも複数リポジトリを跨げるようにしないと問題にならない、と思ったはずだがそれは実現した。

また Project 上で作成したふせんを issue に変換できるようになっている。また変化する際にどのリポジトリの issue にするかを選択できる。

結果として、

  1. Project の画面上であーでもないこーでもないみたいな感じでタスクを洗い出し計画をたてる
  2. それを各リポジトリの issue にしてそこに詳細を書いてしかるべき人物にアサインする
  3. 以後は Project の画面上で複数のリポジトリにまたがったプロジェクトの状況を一覧、管理する

ということができるようになった。多くの組織でこれは実用品になるものだと思うし、 IT プロジェジュト向けのプロジェクト管理ツールみたいなものを作っている会社に出資している人などは今すぐ撤退戦をはじめるべきだろう。

02 Jun 2017 Fri 17:23

サピエンス全史って本 前によんだんだけど、西ヨーロッパは近世以降急激に発展していって世界を制覇したみたいな雑なことが書いてあった。実際にはローマ帝国時代も木工技術では「蛮族」のヨーロッパがローマとギリシャを凌駕していたし、水車や建築などのエンジニアリングにおいてもヨーロッパは実際のところ常に優れた技術を持っていた。そしてそれを常に進歩させていた。

歴史において「急になにかが起った」などということはよほどミクロな事象でない限り通常あまりない。それを支える技術的な条件が常に存在している。例えば日本においても鎌倉北条執権政府の崩壊からあの異様な政権足利政権の誕生まではまるで急流のように見えるが、実際には貨幣の普及と金融業の発達という社会工学的な条件が存在していた。技術史の観点が欠けているとああいう適当な本を書いてしまうことになるので本当に注意したほうがいいと思った。

01 Jun 2017 Thu 17:31

Web アプリケーションのインフラ等の即応対応要員の問題だが 、単純にいって 1 年間は 9000 時間弱ある。一方人間の稼働時間はというと、土日祝日盆正月で 120 日、これに年次有給休暇が 10-20 日はある。 Web 業界では平均勤続年数がさほど長くないからここでは有給 15 日で計算するとして 230日 * 8時間 で 1840 時間ある。 面倒なので 1800 時間としよう。

単位時間あたり二人の要員をアサインする場合 8 時間交代でぎちぎちに監視スケジュールを組んだとして単純にいって 10 人いれば事は足りるということになる。突発的な事態については他の開発者にも応援を要請するとしても、とにかく 10 人は必要である。

実際のところ、昼間の業務から完全に外してとかじゃなくて、昼間のインフラ開発の業務も行いつつ定期的に深夜番や早朝番などを続ける形で入れていくことになるだろうが、総じて最低限で 10 人必要というのは動かない。大星ビル管理事件というのがあって、即応体制を会社から義務付けられた要員はたとえその時間寝ているだけであっても労働時間ということになる。また監視対象のシステムが大規模になるにしたがって必要な人員は 2 倍 3 倍と増えていくことだろう。

銀行やら 24 時間稼働の製造業やらあるいは Web 系であっても景気のいいところならこのあたりきちんとした体制をとっていることだろうと思う。実際 Uber の SRE チームには 100 人を越えるインフラエンジニアがいると聞く。

ただ現実には日本の Web 系でそこまできちんと抱えられるのは極一部の大手に限られるだろうし、結構勢いありそうなところでも SRE チームが数人みたいな話は聞く。でも結局その人数だと SLA 提供できないわけで(やれば長時間残業など違法行為になる可能性が高い)、もうそれだったらやっても無駄、最初から 24 時間運用監視とか諦めた方がいい。こういうものは必要に達していないマンパワーを用意したところでそれは壮大なる無駄に過ぎない。 30 発撃てばだいたい目標に命中するという精度の大砲を持っていた時に、砲弾を 10 発しか持っていなければそれはもうその砲を持っていることは全く無意味であるのと同じような問題である。

我々は Heroku に乗っかってやっていっています。今のところ Heroku, Google Apps Engine, AWS Beanstalk などしか信用できるアプリケーションを普通の日本の Web 系が提供する手段はないと思う。それくらい日本の市場が小さいという話でもある。

31 May 2017 Wed 23:06

仕事しかしてなくてまずい

31 May 2017 Wed 17:49

自分より有能だが専門分野が違う人の受け入れ という問題があって、具体的には Web やったことはないけどネイティブとシステムプログラミングの分野で多大な実績のある人がこんど Web の人として来る。

技術者としてあきらかに今うちで Web やってる人より実力があるので、 Web に慣れてしまえば第一級の戦力となって俺の仕事は減ることになるのでこれは非常に望ましい事態と言える。

いろいろと物事をかっとばして言うと Web エンジニアとしてのマインドセットをインストールしてもらえればいいという話だと思う。では Web のマインドセットとは何か?という問題について考えている。

自分のところの現在の事情と、根本的なマインドセットというものを混同しないように考えないとえらいことになる。自分より優れた技術者のスキルセットを汚してしまうと大変なことになってしまうから、よく考えないといけないと思っている。

いろいろあるけど、ログさえしっかりしてれば失敗は許容される環境である、というのは Web の特徴ではないかと思っている。

25 May 2017 Thu 16:56

Next