Diary

@ssig33

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

Docker Swarm Mode で Mastodon 立てる

公式に用意されている Docker Image はクソであれを使ってデプロイするのは混乱の元でしかない。ローカルで assets:precompile してそれをボリュームでどうにかしろとかクソすぎる。というわけでわりかし楽に使えるイメージを作った。

一応公式を擁護すると docker build 中にリンクができないみたいな問題があってそれがだるいみたいな話はある。

事前に用意

  • Redis と PostgreSQL をどっかに立てる。 Swarm mode 使って立ててもいい。
  • S3 にバケットを作って静的サイト配信を On にする。またその静的サイトを Cloudfront で配信するようにする。
  • Mailgun にアカウントを作ってクレカ番号を入れる
    • 個人で立てたインスタンスぐらいだと課金されるぐらいにメール配信されないと思う(保証はしない)。
    • やる気があるなら自分で smtp サーバー立ててもいい、俺はやりたくない

デプロイ

Web

$ docker service create \
  -e REDIS_HOST= \
  -e REDIS_PORT= \
  -e DB_HOST= \
  -e DB_USER= \
  -e DB_PASS= \
  -e DB_NAME= \
  -e DB_PORT= \
  -e LOCAL_DOMAIN=Mastodon に割り当てるドメイン名 \
  -e LOCAL_HTTPS=false\
  -e SECRET_KEY_BASE=適当に入れる\
  -e OTP_SECRET=適当に入れる\
  -e PAPERCLIP_SECRET=適当に入れる\
  -e SMTP_SERVER=smtp.mailgun.org\
  -e SMTP_PORT=587\
  -e SMTP_LOGIN=Mailgunの設定 \
  -e SMTP_PASSWORD=Mailgunの設定 \
  -e SMTP_FROM_ADDRESS=Mailgunの設定 \
  -e RAILS_ENV=production \
  -e S3_ENABLED=true \
  -e S3_BUCKET=S3のバケット名 \
  -e AWS_ACCESS_KEY_ID= \
  -e AWS_SECRET_ACCESS_KEY= \
  -e S3_PROTOCOL=https \
  -e S3_REGION=us-east-1 \
  --name mastodon-web\
  -p 30001:3000 公開するポートは適当に決める \
  ssig33/mastodon bundle exec rails s -p 3000 -b 0.0.0.0

WebSocket

基本 Web と同じで最後のほうだけ以下のようにする

$ docker service create\
  (略)
   -p 30002:4000 \
   ssig33/mastodon npm run start

Sidekiq

基本 Web と同じで最後のほうだけ以下のようにする

$ docker service create\
  (略)
  ssig33/mastodon bundle exec sidekiq -q default -q mailers -q pull -q push

nginx

https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Production-guide.md を読んでそのとおりにやる。

雑感

もうちょっと気軽に個人がインスタンス立てられるようになるといいですねとは思うがなかなか簡単ではないな。

16 Apr 2017 Sun 20:30

最近 Cloud At Cost が猛烈に安定しててかえって心配

16 Apr 2017 Sun 09:42

事故の現場から

福岡で数回原三信病院というところまでタクシーに乗った。

タクシー突入

この病院はアクセルとブレーキを踏み間違えたタクシーに突入されるという事故を起したところだ。今はタクシーが突入してきても大丈夫なようにバリアが設置されていた。

Google Maps かなんかで地図を見て頂ければ分かるのだが、突入してくださいと言わんばかりの道の構造になっていたのでこういう対処は非常に正しいと思う。けど今したいのはその話じゃない。

タクシーに乗って原三信病院まで、というとどうしてもかならずあの事故が話題になる。そこで運転手の彼らの話をすると

  • 普段はおだやかな人だと聞いていた
  • キャリアも長いのに
  • まさかあんな事故を起すなんて魔が差したのだろうか

というような話を 3 回も聞くことになった。

思うに、まさに、この意識こそが事故の原因なのだ。彼らの話に欠けている認識はなにか。それは人は一定の確率で必ず錯誤を起すという事実だ。

ではその錯誤はいったいどのようにして重大事故へと発展するのか。錯誤が起きるとき、予想されていた事態と事実に違いがおきる。この違いに感じられる違和感を無視したまま現状動作を維持、強化することによって重大な事故へと繋がっていく。

  • 自分ではブレーキを踏んでいるつもりなのに加速している => ではこのブレーキをより強く踏み込もう

では人は錯誤に陥いったときどうするべきか。事実認識に対する違和感を感じたとき、あるいは錯誤の明確な結果が表われているとき、これは現状動作を直ちに停止するべきだ。 Gitlab の従業員はこの原則を記憶していたから、操作ミスで PostgreSQL をかっ飛ばしたあとは作業を停止し引き継ぎを行なっていた。

どうも福岡のタクシー業界全体で安全意識が欠けているように思えるしというかあいつらはマジで糞で猛烈な勢いで左折しながら左折中の車を左から抜いていったりするしどうにもならん、ほんとうにダメ。

04 Apr 2017 Tue 22:43

なんかまあちまちま落ちるときは落ちるけど 勝手に復帰するようになったし Cloud At Cost の奥義を究めたと言える

02 Apr 2017 Sun 17:10

明日から GW 終了まで長期休暇 なのでなにやろうか考えてる。本格的に iOS のコード書けないことが俺のなかで問題になってきているので iOS 向けになにか実用アプリを一つ作ろうという気持ちがある。

なにやったらいいかなー。あんまりアイディアない。セルフオーダー端末とか作ろうかな。

31 Mar 2017 Fri 21:11

AWS CodeBuild を使った超分散テストの知見

AWS CodeBuild で大量に Github からソースコードダウンロードすると死亡する

S3 に手順だけ記述された小さなファイルを上げておいて、それをダウンロードするようにしましょう

数百環境同時にプロビジョニングすると CodeBuild がコケがち

まずプロビジョニングはコケるという前提で再開処理をきちんと書く。その上で並列数はせいぜい 100 ぐらいに抑えておく。 100 だとまず失敗しないし、 100 並列でも十分。

Travis とかで Docker ビルドして push みたいなのだとキャッシュきかないのでキツい問題

自前で Jenkins を立てるととりあえず解決するけどだるいからイヤということで考えてみたのだが、

  1. Travis で Docker を使って bundle install とか npm i とかする
    • この結果は Volume とかつかって Travis 側にキャッシュが残るようにする
  2. そのようにして得られたディレクトリ全体を tar.gz で包んで S3 に上げる
  3. CodeBuild では S3 からそれをとってきて展開する

ここでポイントとなるのが Docker には言語その他実行環境だけ入れておいて、しかもそれを Docker Hub などネットワーク的にそこそこ強いところに入れておくということです。

Docker の使用を最小限にすることで、キャッシュ効かないとか Docker pull がそこそこ辛いとかそういう問題をある程度解決する。

ここまでやるメリットがあるかどうかは、よく知らん。

30 Mar 2017 Thu 15:11

シンタックスハイライトさせるようにした

29 Mar 2017 Wed 22:45

test

class Gomi
  def gomi
    @gomi
  end
end
29 Mar 2017 Wed 21:18

インフラや信頼性向上が経営陣から評価されない という話いくらでも聞く。そもそも技術者をどのような領域の仕事に注力させるかというのは経営判断の問題なので、

  1. インフラや信頼性向上にコストをかけるメリット、やらないデメリットを説明する
  2. その上でやらないという話になったら、やらない
  3. その判断が納得できないなら転職する

というふうにしかならないと思うんですよ。経営者に評価されない仕事を「自分は必要だと思うから」とかいってやったところで何になるのか?少なくとも給料にはなりません。 無駄な仕事しないほうがいいし、クソだと思った会社はとっとと辞めたほうがいい。

俺はというとそこまでやりたいわけでもないインフラや信頼性向上をやっていくことを会社から期待されている状態なので、 ssig33.com その他俺のやりたいことに生かせる知見が得られるように注意しながらやっていくという状態になっている。

28 Mar 2017 Tue 15:48

AWS CodeBuild の正しい?使い方 みたいなものが分かってきた気がする。これは従来の発想を捨てる必要がある。たとえばこれまで、一回のテストに用いるサーバーの数はたかだか、 10 とか 20 とかに制限されていることが多かった。

ところが AWS CodeBuild の場合いくらでもビルド環境を構築できるから、たとえばテストファイルの数だけ CodeBuild を立てて物凄い並列数で一つのビルドを高速に仕上げる、ということも可能になる。

「あまりにも大量に開発者がいるから常にビルドが走っていて Jenkins や Travis がうまっている」みたいな会社がおそらくこのサービスでは想定顧客だろう。しかしとにかく大量のテストを超並列に実行できればそれだけで嬉しいという人は多いはずで、開発効率の向上が達成されると思う。

28 Mar 2017 Tue 00:19

オレオレ SSH ハンドヘルドだが

img

こんな感じになっていて、機能としてはそろったのであとはこれをガワにつめるだけである。だけ。。。

はっきりいって俺にはソフトウェア以外ほとんどエンジニアリングの素養はない。ところが 2017 年では組み合わせるだけで簡単に製品ができるコンポーネントみたいなものがそこらに転がっている。そのため、 PC 自作程度の知識でもモバイルデバイスらしきものが作れてしまう。

恐らく Snapdragon 835 などを積んだ怪しいボードが中国で出回り始める日も近いだろうと思う。そうなると個人が自由自在にハンドヘルド Windows デバイスすら作るようになる、という日も来年ぐらいには来ているだろう。

25 Mar 2017 Sat 11:01

Next