Diary

@ssig33

Docker Swarm Mode の問題を調べるのがだるいので 一端主要なアプリだけ Heroku にのせて課金した。金払える限りにおいては Heroku 使うのが明かに最高、、、

26 Jun 2017 Mon 10:06

Docker Swarm Mode 不調でだるい

26 Jun 2017 Mon 09:29

あきらかに俺を嫌ってそうな人がはてブで肯定的なコメントを付けていて、 気付いたことがあるんだけど、もしかしてこれ書いてるのが俺だって気付いてない可能性があるのか

22 Jun 2017 Thu 18:44

日付別ページへの動線を消すと殺風景になってよくなった

22 Jun 2017 Thu 18:43

日付別ページ、ページは残すけど導線は消したい

22 Jun 2017 Thu 18:28

CTO 候補っていう求人に応募する奴いるのかよ

19 Jun 2017 Mon 18:15

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

Next