Diary

@ssig33

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

16/Mar/2017 (Thu)

貧者のクラウドについて一度きっちりまとめを書かなければ、、、

19:21

マネージャーノードを 17.03 に上げてみた

今度は安定するといいが、、、

18:10

Cloud At Cost はインフラ養成ギプス というところがあって、本当にがんがん壊れるのでとにかく強固なインフラとはなにかということを常に考えていないと死ぬ。

個人的には得るものが本当に大きかったけど、他人に推奨できるかというと、、、

02:43

Cloud At Cost でのサーバー作成完全自動化した。 前は作成は手でやってちまちま Ansible で docker だの glusterfs だのをインストールしていたのだが、 Cloud At Cost の残存リソース量を監視してサーバーの作成から Ansible でのセットアップまでを勝手にやるようにした。

壊れたサーバーの削除まで自動化すればはかどるような気もする。壊れてるっぽかったらアラート投げるとかしてるので壊れてるっぽい時残存リソース量が十分あればとりあえず消しちゃってもいい気する。

02:41

手に巨大な血豆ができているのでチマメ隊になったとか言ってた

02:36

08/Mar/2017 (Wed)

mapk0y さんの反応で変なこと言ってないかとか確かめてるところある

16:26

money

16:25

06/Mar/2017 (Mon)

CloudAtCost がひさしぶりに大崩落している

16:16

05/Mar/2017 (Sun)

サーバーが多少体調崩してもサービス止まらないような構成を作った結果 としてサーバーが調子悪くなってることに気付けなくて、結構対処がめんどくさい段階になってから気付いて対処するみたいになっている。

ここで対処をもっと確実にやっていきましょうとかは当然だめで、早期の対処はなるべく自動化していく必要があるんだろう。縮退運転自動化みたいのばっか作ってきてしまった。

21:00

なんかいろいろ調子悪いっぽいけど気付いてなかった。

20:59

27/Feb/2017 (Mon)

conoha のサーバーがたまに死ぬ ので API で監視しては API 経由でリブートかけてるんだけどそのうち致命的にいろいろ吹っ飛びそうで怖い。

データはまあバックアップとってるし Docker Swarm Mode のおかげで復活にも大して時間はかからんのですが。。

23:31

26/Feb/2017 (Sun)

Docker 1.13 はだめ ということがわかってきたので 1.12 にいったん戻した。具体的になにが起きるかというと Docker swarm mode のマネージャーノードが 1.13 だと頻繁にメモリを大量消費してお亡くなりになられる。

worker が 1.13 で manager が 1.12 でも特に問題はないようなので当面その構成でやっていくことにする。

19:02

23/Feb/2017 (Thu)

LXD なんとなくさわってる。結構好き。

デプロイ以外の用途にも無理矢理 Docker 使ってる人はこっちも一緒に使ったほうがいいんじゃないか?

18:17

16/Feb/2017 (Thu)

iOS シュミレーター 遅いで検索したらサクっと答えがでてきてウケた。

http://ja.stackoverflow.com/questions/10019/ios%E3%82%B7%E3%83%9F%E3%83%A5%E3%83%AC%E3%83%BC%E3%82%BF%E3%83%BC%E3%81%AE%E5%8B%95%E4%BD%9C%E3%81%8C%E9%81%85%E3%81%84

このオプションなんのためにあんの、、、

18:36

最近 iOS Simulator が超絶遅くてこまってる

18:33

10/Feb/2017 (Fri)

WordPress で構築してたサイトを Heroku に移行させた

会社のサポートページが WordPress で構築されているのだが、これがよくわからないさくらの VPS にデプロイされていた。 OS が Ubuntu 12.04 でサポート切れ目前なのだが do-release-upgrade するよりは Heroku かなんかに引っ越してしまえばいいと思ったのでそうした。

を使うという手もあったんだろうけど、それはそれでめんどうそうだし自分達の運用ノウハウがある Heroku がよかろうという感じで決めた。

移行で実際にやること。

  1. 画像を S3 に上げる
  2. Heroku に WordPress デプロイ
  3. DNS 切り替え

まあこれだけなんだが、 1. は地獄である。

これについては実際のデータを見てほしいのだが、 wp_postmeta というテーブルの meta_value というカラムには例として以下のようなカラムが入っている(見やすくするために改行してます)。

a:4:{
  s:5:"width";
  i:2630;
  s:6:"height";
  i:1762;
  s:4:"file";
  s:44:"2017/01/d7ec2d3fea4756bc1642e0f10c180cf5.png";
  s:10:"image_meta";
  a:12{
    s:8:"aperture";
    s:1:"0";s:6:"credit";
    s:0:"";
    s:6:"camera";
    s:0:"";
    s:7:"caption";
    s:0:"";
    s:17:"created_timestamp";
    s:1:"0";
    s:9:"copyright";
    s:0:"";
    s:12:"focal_length";
    s:1:"0";
    s:3:"iso";
    s:1:"0";
    s:13:"shutter_speed";
    s:1:"0";
    s:5:"title";
    s:0:"";
    s:11:"orientation";
    s:1:"0";
    s:8:"keywords";
    a:0:{}
  }
}

えっ?なんだこのシリアライズ形式は。 WordPress が 15 年近く開発を継続されている CMS だと感じる瞬間である。画像を S3 に逃がすには WP Offload S3 というプラグインを使うのがよいのだが、過去画像について配慮してくれる機能はない。

WP Offload S3 は画像をアップロードするたびに wp_postmeta に上記の謎のシリアライズ形式で S3 に保存したよみたいな情報を保存してくれる。なので過去画像については自分で S3 にアップロードした後 wp_postmeta にそのデータを自分で insert すればよい。

ここで注意しなければならないのが、検索して出てくる情報は全て信用ならないということである。たいてい嘘か勘違いか古い情報が書かれている。すぐにデータベースをロールバックできる環境を作ってヒューリスティックになんども適当にやるのがよい。

過去記事に関しては、単に画像の URL を書き換えればいいだけなのでまあ sql の replace 構文かなにかを使って update をすれば一瞬。

Heroku へのデプロイはどうかというと、 wordpress ぐらいであれば push すれば動く。もし document root をプロジェクトのトップディレクトリ以外に変えたい場合(PHP だとそういうことは多いだろうし、実際僕は今回変えた)でも Heroku 側でサポートしてくれて Procfile を設置して

web: vendor/bin/heroku-hhvm-apache2

とかなんとか書けばいい。ローカルと Heroku で設置するファイルをちょっと変えたいみたいな需要もあるかもしれない(俺にはあった)。その場合はこの Procifile で apache 起動する前にふつうに cp コマンドとかでコピーするように設定すればいいだろう。

ちなみに上記のとおり Heroku では hhvm が使える。使えるのだが 3.5.1 とかなり古いので、まあ素直に PHP7 使ったらいいです。

なんか変なことしたい人は Container Registry 使ったらいいんじゃないですかね。

WordPress を Heroku に置くメリット

うちの会社の都合として Heroku に慣れてるというのがあった。それ以外に最大のメリットとしては Review Apps が使えるというのがあると思う。

デザインの変更の Pull Request の度に検証環境が立ち上がるようになるので、レビューとかはしやすくなるだろうと思う(とはいえまだサポートページの WordPress は Review Apps 有効化してない)。

感想

本当に WordPress と PHP は地獄で辛かった。

14:57

08/Feb/2017 (Wed)

WordPress の仕事が終わって本当によかった

18:51

Next