Diary

@ssig33

29/Apr/2017 (Sat)

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

21:26

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

21:25

27/Apr/2017 (Thu)

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);
});
18:33

25/Apr/2017 (Tue)

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

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

18:40

23/Apr/2017 (Sun)

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

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

17:56

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

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

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

16:42

22/Apr/2017 (Sat)

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

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

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

17:18

21/Apr/2017 (Fri)

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

12:54

16/Apr/2017 (Sun)

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 を読んでそのとおりにやる。

雑感

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

20:30

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

09:42

04/Apr/2017 (Tue)

事故の現場から

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

タクシー突入

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

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

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

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

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

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

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

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

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

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

22:43

02/Apr/2017 (Sun)

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

17:10

31/Mar/2017 (Fri)

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

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

21:11

30/Mar/2017 (Thu)

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 がそこそこ辛いとかそういう問題をある程度解決する。

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

15:11

29/Mar/2017 (Wed)

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

22:45

test

class Gomi
  def gomi
    @gomi
  end
end
21:18

28/Mar/2017 (Tue)

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

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

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

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

15:48

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

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

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

00:19

25/Mar/2017 (Sat)

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

img

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

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

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

11:01

24/Mar/2017 (Fri)

オレオレ Docker Registry を完全排除できたので今日は勝ちました

20:42

ワークアラウンド感やばいけど 一応 service mode で cron 的なことする方法なくはないんだな。

https://github.com/docker/docker/issues/23880#issuecomment-277805149

15:22

通関進めますとのこと

15:19

adafruit から買い物したら住所表記が不完全だったとかいって UPS から住所教えろってメールきたんだけど これってまずは UPS が adafruit に確認して、 adafruit 上で俺が住所入れなおして、 adafruit がそれを UPS に通知するのが正しいんじゃないの?

そこまで気にするの神経質すぎると思うからまあ普通に住所返答したんだけど。

14:43

23/Mar/2017 (Thu)

クレジットカード決済の実装 、一番いいのは

  • Amazon Payment
  • Paypal

みたいに完全に外部のサービスとして構築されていてそこにリダイレクトして処理が行われるものを使うことだろう。

ただ Amazon アカウントもってないだとか Paypal アカウント持ってないだとかいう人は結構多いし、 B2B 系だとさらにいろいろ面倒は増すと思う。国内だと GMO ペイメントがアカウントなしで GMO 側のドメインで決済できるものを提供していたと思うが使ったことないのでよく知らない。こういうタイプは最も望ましい、と思う。

まあ他にもそういうリンク型みたいのいろいろあるだろ。専門じゃないからよく知らん。

非通過型決済とでもいうのか、クライアントサイドで決済を行なって決済事業者としかクレカ情報をやり取りしないタイプの決済サービスが最近は出てきている。 Stripe がそういうのだと代表的なのかな?国内だと pay.jp とか GMO ペイメントのトークン決済とか。

こういうの実は侵入に対する脆弱性は従来型の決済サービスとそこまで変わらんと思う。 http://anond.hatelabo.jp/20170322160743 にも書いたが結局侵入を受ければ一定期間の間に入力されたクレジットカード番号は抜かれてしまうので。

  • 自社のデータベースに保存していたクレジットカード番号 5 万件が流出しました
  • 侵入を受けていた 2 週間の間に入力されたクレジットカード番号 350 件が流出しました

という事案を比較したときに、企業イメージなりサービスなりへのダメージはその総量はほとんど変化がないのではないか。

はっきりいって自社ドメインにクレカ番号入力ページを設けるメリットは何一つとしてないと思う。どうしてもやりたいんであれば、決済ページだけ完全にドメイン、サーバー、ネットワークなどを分けるしかないのでは。

例えば kanekure.ssig33.com にクレカ決済を入れたいとしたら kanekure-payment.com みたいなドメインを別途設けてそこに OAuth その他 SSO 手段で安全に認証情報を渡してそこで決済させる、みたいな。その決済ドメインでは決済サービス提供以外の JavaScript などは一切使用しないようする。これは DOM Based XSS の可能性を極限まで下げるため。またサーバーセキュリティなども本体サービスとは別基準で運用する。

ようするに Paypal とかリンク型の決済サービスとかを車輪の再発明するしかないと思うのですよ。もし Stripe や pay.jp みたいのを使う場合でも。

だったら最初から Paypal とかリンク型の決済サービスを使っとけばいいよねという話だし、 JavaScript 型のクレカ決済サービスは本質的にナンセンスなものだと俺は思っている。

12:24

SSH 専用デバイスみたいのほしければ GPD Pocket でいいじゃん みたいの言われたんだけど、 GPD Win はゲームパッド部分は最高だったがキーボードは最悪(いきなり認識しなくなる、電源設計の失敗でキーボードの電源が切れるという問題、個体差ありというアナウンスがあった)みたいな感じだったので、正直ゲーム部分以外の設計力については GPD は一切信用できないと思っている。

ゲーム機としては最高なんだけどねー。

あと立って使えるサイズ感がよくて、俺の手は女性小さめみたいなサイズなのでいろいろ制約がある

12:05

20/Mar/2017 (Mon)

Old Man's War っていう小説だったかで 未来のコンピューターは内部のデータバスが無線化されているから、個人用ハンドヘルドをうっかり使ってしまうと通信諜報で自位置が暴露されるみたいな SF ネタがあった。

僕の作っているハンドヘルドもキーボードの接続は楽をするために BT で、あれを最初読んだときなんなんだこの設定みたいに思ったんだけど、以外とありうる方向性なのかもしれない。

全然関係ない話だけど、米軍基地は作戦直前になると個人の携帯電話を使って家族に連絡したりする軍人が多いから、携帯電話電波の増減を観測するだけで作戦の兆候を掴めるという話があった。今はゲリラ戦の時代だからその辺曖昧だけど、たとえば第三次世界大戦がおきて、前線近くの基地で厳重な無線封鎖が行われるみたいな事態になったときに、現代の軍人はそのストレスだけでやばいことになりそうである。

15:16

iPhone や Android の SSH クライアントにまともなのがないからもう SSH するだけのハンドヘルドみたいのがほしくなって 、いやそれ GPD Win でいいじゃん的なあれではあるんだろうけど、 GPD Win は電源設計をミスっただかでキーボードの挙動が大変に不信。パッドでちょっとしたゲームとかを遊ぶ分にはあれ最高なんだけどね。

ということで作り始めた。方針としてはマルチメディアとか PIM とかは必要なくて、本当に純粋にどっかに SSH して Vim が使えればそれでおっけーぐらい。

参考になることやってる人いないか調べてみると、まあいた。

この人の場合、 Pi Zero 初代でやってるから USB ひきまわしたりとかいろいろやってる。けど Pi Zero W なら本体に接続しないといけないデバイスは、ディスプレイと電源だけ。

電源については、電子工作の経験がまったくないので、なんか楽にできる手段ないかなあと思って検索していたところ、

というものを見つけた。電源の制御とバッテリーへの充電をやってくれるすげえ基盤みたいのがある。というわけで無知識でも言われた通りにはんだ付けするだけでそれっぽく動く。

ここまではできてる。

あとはケーシングなんだけど、これまた 3DCAD の経験がほとんどないので、どうしたもんかなという。とりあえずプラ板切り貼りしてそれっぽくするところからはじめてみようか、というのが現状。

ところでこれをやっていて、ほしいものは全部海外から買った。電源まわりとかなんかいいのないかなみたいな感じで秋葉原にいったりしてみたけど、千石撫子みたいな名前の店にとりあえず行って、ほしいものの型番を店員に伝えても店員が気合で店内を探して回るみたいな世界観で、電子の街のはずなのに IT 化とか全くされてなくてやばい感じだった。

15:12

Next