Diary

@ssig33

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

ssig33.com のキャッシュ飛ばなくなってるな

19 May 2017 Fri 19:20

日本人の栄養不足など存在しないのではないか?という毎日新聞の記事だが結構問題が多いと思う。

記事はこちら。アカウント作ればタダで全文読めます。

記事のコアな部分は

関係論文や各調査を比較し検証してみたところ、国民健康・栄養調査でも15%以上のエネルギーの過小申告があるのではないかと推測されます。

であるから、日本人の栄養不足など実際には嘘で、日本人は食いすぎでデブである、という主張だ。では実際の数字を見てみればどうであるか。記事にもある通り 20 代男性は 2650kcal ほどを摂取するのが理想であるが、調査では 2222kcal しか摂取していないという数字が出ているとある。

これが実際に 15% 下ブレした数字であるとすると、実際の 20 代男性は平均して 2614kcal ほど摂取していることになる。平均をとれば理想ちょうど、ということになる。では日本人男性は今もっとも理想的な栄養状態にあるのか。そうではないだろう。実際には平均を越えて食ってる人もいれば、平均を越えていない人もいる。ということは栄養が不足した状態で過している人も沢山いるという話になる。

また記事には

15年調査では、望ましい体格の指標であるBMI(体格指数)の平均(20~69歳)が、男性は23.83、女性は22.09という結果となっています。「健康的」とされるBMIの値である22を上回って

いるとあるが、そもそも 22 は「普通の中の普通」をあらわす数字なのであって 18.5 〜 25 までであれば健康的であるとされる。ようするに日本人男性は太りすぎていない。

こうしたデータが何を示すのか。それはよくわからない。現代では肉体労働が減っているから 2560kcal という数値が根拠のないものである、という主張はよくみる。

しかし、そうした主張をする人たちは日本には絶対的貧困が蔓延しつつあり、栄養失調状態で過す者が増えているという可能性から目を背けているだけではないか。その事実について考慮するだけでも不快な気持ちになることは分かるのだが、もしそうした事実があった場合さまざまな意味で致命的な問題である。であるゆえにそこから目を背けてはいけないと思う。

この記事についても無理矢理「日本人の栄養状態は富栄養であると思う」という著者の意見へこじつけ、誘導しているに過ぎない。

現実問題として食料品は商品改訂のたびに同じ値段で変える量が減っていくということが常態化しているし、またかつてよりも人々は多くの金額を家賃に払うようになってきているという傾向もある。通信費など新しい必須の支出も生まれた。にもかかわらず人々の給与は上がらなかったかかえって下った。とすれば絶対的な貧困により栄養失調状態に移行しつつある層が存在していてもおかしくはない。

思い込みや希望的観測によってこうした可能性を無視するようなことはやめたほうがいいのではないか。

19 May 2017 Fri 16:27

人間

19 May 2017 Fri 11:08

Next