Diary

@ssig33

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

データベースサーバーの管理とかしたくないけどそれが仕事になってるし最悪に近い

12 May 2017 Fri 19:27

ストレージが限定されていたころは、それなりにファイルとかを整理してたんだけど 近年事実上ストレージの容量は無制限となったので、極めていいかげんにこれが扱われることになってしまった。動画、音楽、電子書籍についてはまあ自分で検索ソリューション作ってなんとかやってるんだけど、画像とドキュメントがどんどん適当にストレージに放りこまれたものが事実上利用不可能なままどうにもならなくなってきた。

どうにかならんもんかね。

12 May 2017 Fri 17:43

人間性

12 May 2017 Fri 17:41

この前弁護士とした会話

  1. 弁護士「最近は Google も SEO 対策とかに詳しくて本物の情報かどうかを重視してるんでしたっけ?」
  2. me「らしいですねえ」
  3. 弁護士「とはいえ何が本物の情報かって難しいですよね」
  4. me 「そりゃまあアディーレ法律事務所だって本物の法律事務所ですしね」
  5. 弁護士苦笑
  6. me 「やっぱあれ問題多いんですか?」
  7. 弁護士「そりゃまあ」
12 May 2017 Fri 17:37

労働基準関係法令違反に係る公表事案の面白いやつ を見ていきましょう。

前提

リストには送検段階で掲載されています。もしあなたが近代の法律論にのっとった人間であろうと思う限り、掲載されている企業の無罪を推定する必要があるでしょう。ここでは疑わしきも罰し明らかな善人だろうが気分次第で殴れという立場にたってやっていきます。

全体として工事現場での転落防止の不徹底、給与の支払い遅延などが多い。注目に価するものをいくつか紹介してゆく。

img

京都の解体工事の会社。なんと Web サイトがある。いったいコンクリート圧砕機を何に使ったのであろうか。

img

ブレーキが壊れたバキュームカーが街中を爆走していたというのは、考えられうる限り最悪の事態の一つだと言えるのではないか。

img

非常に豪快。

img

下請けを爆破した事例。

img

おそらく今回公表された事例のなかでは最強のものと思われる。自社で経営する日本語学校の外国人留学生を監禁し奴隷にして、また別に経営する介護施設などで強制労働させた事例である。これをやった人達はWebサイトを持っている。事情の詳細はこの記事が詳しい。

ちなみに

リストに掲載されている企業が少なすぎる!!!という意見があるが、これはあくまでも送検された事件についてのまとめです。今年の 1 月から長時間残業で労災が発生した企業についても都道府県のほうでも公表範囲を広めるようにという通達が出ている。これは以前から公表の基準自体は設定されていたのだが、あまりにも基準がきつくて意味がないと批判されていたもので、年初に基準が緩められた。これについては送検されなくても指導が行なわれたタイミングで企業名が公開されることになる。

こちらについてもいずれ厚生労働省によって日本全体でのまとめが作成されてゆくのではないか。

11 May 2017 Thu 17:13

一番フロントの nginx が Docker 化されてなくてアレなのでなんとかしたいんだけど、 Let's Encrypt とかあるからどうしたもんかねという問題がある。

08 May 2017 Mon 17:35

職場復帰済です

08 May 2017 Mon 17:24

docker swarm mode のマネージャーノード は可能であればメモリ 16GB ぐらいのマシン使ったほうがいいだろうなこれ。

08 May 2017 Mon 09:26

マネージャーのメモリバカ食い問題 たまに service 全部消して登録しなおすと解決することが分かった、ノードの追加削除が繰り返されることでネットワークの設定にゴミが貯まっていくことが問題で、サービス消すとそのへん掃除できる。

掃除自動化したらいいかもしれない。

08 May 2017 Mon 09:24

Docker Swarm Mode のマネージャーがわりとメモリ食う問題

07 May 2017 Sun 18:11

MySQL が落ちまくる、最高

05 May 2017 Fri 20:52

Web 系プログラマーの教育の問題だけど 基礎的な HTML/CSS の部分を覚えるのはプログラミングの学習「以前」にやっといてもらわないとどうにもならん。それも出来てない「初学者」を相手にしても多分どうにもならないです。何故なら目的に応じた HTML/CSS をなんとか書けるようになるかというところである程度スクリーニングされるから。

ですが現実問題としていちいち自分で Web サイトを作ったりブログのテーマを自作したりする若者は着実に減っています。よって HTML/CSS の基礎がない人間を相手にしなければならないと言える。大企業であればこうした問題に対処ができる。教育工程を充実させられるというのもあるが、やってみて駄目だった人を別の部署にまわす余裕があるという話でもある。

ではどうすればいいかというと、諦めて Web は全然金と手間かけない方針でやるとか、出来る人を高い金でもってくるとかしかないんじゃないかね。

HTML/CSS も書けない初学者を高確率で Web 系プログラマーにする方法など無いし、若者はみな Unity やら機械学習やらをやっている、平成もそろそろ終わるし今は Web の時代じゃない。

04 May 2017 Thu 22:29

去年の 9 月ごろの記録とか日記とか見ると、 この 8 ヶ月ほどで俺は本当に Cloud At Cost を完璧に操ってシステムを安定させる技術を得たのだなというのが分かるんだけど、大変に不毛。

03 May 2017 Wed 16:51

Go で Web アプリケーションやる 人が最近多いような気がするのだけど、というかこの日記サイト自体 Go で書かれていて僕もそういう人です。ですが、それをやるメリットってあるんですかね。

Web アプリを記述する言語としての Go のメリットは

  • Ruby とかよりは速い(PHP より速いのかは知らん)
  • libc と SSL の証明書ぐらいがあれば動くバイナリが作られるのでデプロイがそこそこ楽

ぐらいしか無いと思っていて、デメリットとしては、沢山あります。 Web を普通にやってる限り goroutine があるメリット別に受けられないんと違うか。フレームワーク内部では使われてたりするんだろうけど。

デプロイ云々に関しても Docker によって超富豪的にパッケージングする時代がやってきて、あまりメリットとしては大きいものではなくなってきていると思う。デプロイ先ノードが数千数万もあって Docker Registry の構築に神経を使うような世界ではそうでは ないかもしれないが、そんな人はあまり多くないだろう。

ではなんで僕が Go で Web をやるかというと、それはもうとにかく Ruby よりはだいぶ速いというのが大きいです。通常これは大した問題ではなくて、 Ruby や Rails は十分に速い。だが僕は Cloud At Cost というクソみたいな格安 VPS で構築されたサーバー 10 台を常用環境にを使っていて、このサイトとかもそこにデプロイしている。そこではディスク I/O 、CPU 、ネットワークが非常に貴重なリソースで、また頻繁にサーバーは故障する。そのような環境下では Go の軽便な性質が非常に有利に働く。

とはいえそんな糞みたいな環境でやっていってる奴が俺以外にいるのか?いねえだろ。

Go の Web アプリでの利点というのは金でなんとかなる程度の話ではないかと思う。ただ、 Go で Web をやってなんか辛いのかというと、まあ別にこんなもんだよな、、、感もあり Go だけでやっていく世界というのは、アリなんですかね。でも普通は PHP や Ruby でいいと思うんだよな。

というのは array と slice の違いも理解しないで Go やっていっているような人が最近多くて、そこを曖昧に済ませていい程度のユースケースなら PHP の方が幸せに生きていけるんじゃないの?と思うんですがどうでしょうか。

このへんはわりと Go をまっとうに使っている事例な気はしている。

03 May 2017 Wed 11:04

UPQ 問題に関連して思い出したこと なんだけど、 ODM/OEM の多用による日本企業の空洞化が進んでいる分野というのは何も IT 業界や家電業界に限らなくて、ファッション業界もこれがすごい。というかこっちのほうが中国における産業の立ち上がりが早かったりもともと調達前提のビジネスモデルが発達していた分エレクトロニクス関連よりも状況が酷いかもしれん。

なんでもいいから適当な郊外型ショッピングモール 2,3 個を回ってみればいいのだが、特に区別もつけられないようなどうでもいい店が沢山あって、しかもどのショッピングモールに行ってもかならずほとんど同じような店が同じように入居している。

ではそういう店はいわゆるセレクトショップなのか?というと自前のブランドの商品を売っている。あれはなんなのかという、中国のファッション企業に「ブランドを一個お願いします」という形で発注するとブランドイメージを中国の側で作ってくれたうえで商品ラインナップがまるごと一つそのままやってくるという素晴しいビジネスモデルになっている。販売員などはバイトであることが多いから、最も極端にあれを表すと

  1. 中国にメールを送る
  2. イオンに出店させてもらう
  3. 在庫管理をする

ということだけ本社はやっている格好である。

なぜこのような空虚なビジネスモデルが発生したかというと二通りある。「これからの時代セレクトショップ(調達型のビジネスモデル)は終わり!!!製造小売業の時代」みたいな趨勢があったときに、現実問題として製造小売に転身できる企業はあまり多くなかったから、中国からブランドそのものを調達するようになったというタイプが一つ。もうひとつは、わりとまっとうな製造小売業をやっていたメーカーが闇堕ちしたケース。

こういうブランドを運営する企業の特徴はなにかというと、一つの企業で異様に大量のブランドを運営していることである。実際にファッションとしてのコアな部分であろうはずのブランドイメージの構築、デザイン、製造は全て中国がやってくれるからどんどん大量にブランドを作ることができる。ショッピングモールでよくみるアレとアレとアレとアレとアレとアレとアレが同じ会社みたいの調べてみるとびっくりしますよ。

現実問題として日本のファッション業界で強い二社を見ると

  • 低価格の実用品という観点で徹底的に自社で商品コントロールをしている強固な製造小売業のユニクロ
  • 古来からの調達型ビジネスモデルを堅持するしまむら

なのでこうした半端な「製造小売業」はほんとうに半端ものでしかないのだけども、ビビッドなビジネスモデルでやっていくにはしまむらの規模が必要なのだった。だがいずれにせよ大量に展開されるショッピングモールに機械的に店舗を出店し続けることはそうした半端ものの彼らにとっては大変なことなので疲弊は著しいという。

僕は元来あまり服に興味があるわけでもないし、小売についてはもっと興味はなかったので、こういう状況があることを知ったのは 2 年前に POS レジを作る仕事をしはじめてからなのだが、おおよそ 2000 年代中頃から十年ほどかけて現在のようなしょうもない状況が作られてきたらしい。

結果として日本中に恐しく空虚なファッションブランドを沢山抱えた空虚な巨大建造物が大量に存在するというとんちのような事態になっている。j

ちなみに僕は aliexpress で買った服を来ています、 5 着買うと 1 着ぐらいまともなのが来るみたいな世界観でガチャみたいで楽しい。

01 May 2017 Mon 21:05

goroutine と sync.WaitGroup が ruby にほしいですね

29 Apr 2017 Sat 21:26

Ruby で書いてたバッチをどんどん Go に書き直していて、よくなっている

29 Apr 2017 Sat 21:25

shurcooL/github_flavored_markdown 捨てたときにシンタックスハイライトも壊していたので直した

class Gomi
  def unko
     p @gomi
  end
end
document.querySelectorAll('.highlight').forEach(function(div){
  let code = div.children[0];
  const lang = String(div.className.split("-")[1]);
  code.className = lang
  hljs.highlightBlock(code);
});
27 Apr 2017 Thu 18:33

日本のベンチャー、というか VC が人件費使うことをすごく嫌がるから ベンチャーにはチンピラみたいのしかいないし、そこそこ優秀な営業や技術者は創業 4-5 年たって自前で売上立ててそこから人件費払えるような会社にしかいないし、まともな人材に 500-600 万ぐらいでいいからベンチャーがちゃんと金払えるような文化を作っていかないとどうにもならないんじゃないかなーと常々思う。

出来る人がただの中小企業化してきてるような元ベンチャーにしかいないのは本当によくないよなーと常々思いますわ。

25 Apr 2017 Tue 18:40

Rails で作る -> 最近メンテしてないから Sinatra で書き直す -> Heroku に乗せて起動速くしたいから Go で書き直す みたいなこと何度もやっててバカなのか俺はという感じです。

Rails で書かれてもうメンテする気ないものを Sinatra にするの自体は結構オススメ。

23 Apr 2017 Sun 17:56

Heroku であちがちなオペレーションミス

  1. アプリ A の Heroku Scheduler を編集しようとして Dashboard からアプリ A の Scheduler を開く
  2. そのまま今度はアプリ B の Scheduler を開こうとして別にタブでアプリ B の Scheduler を開く
  3. アプリ A の Scheduler のタブに戻り編集する

するとどうなるか。アプリ B の Scheduler が更新される。これマジで糞なので改善してほしいですね。

23 Apr 2017 Sun 16:42

Docker で何が嬉しいのか というか我々がみな何を目指していたかというと、 Heroku の使い勝手を Heroku に縛られることなく得ることを目標にしていたわけです。もともと Docker 自体 dotCloud という Heroku クローンのようなサービスの実行エンジンから出てきたものだし。

ということで、 Docker に触れる前に Heroku にまず触れてみるといいと思う。というか大抵の人は Docker 使うより Heroku を使ってしまったほうが幸せなんじゃないですかね。僕は金ないので個人では Docker 使いまくってますが、所属してる会社には金があるので Heroku を使っている。

いずれにせよ、 Heroku に慣れてみると Docker やその周辺に散在する思想によって何が得られるかがはっきりとしてくる。

22 Apr 2017 Sat 17:18

Todo リスト系サービスってなんでどれもこれもセキュリティまわり適当なのかな

21 Apr 2017 Fri 12:54

Next