Diary

@ssig33

最近 Conoha 不安定

22 May 2018 Tue 00:19

アメリカの安い VPS みたいの探すかー

22 May 2018 Tue 00:19

ようやくムサンナ県の情勢が頭から抜けてきた

07 May 2018 Mon 11:56

風邪ひいたっぽい

02 May 2018 Wed 14:19

キリン

02 May 2018 Wed 14:18

コアラ

02 May 2018 Wed 14:07

インド人

01 May 2018 Tue 14:33

localStorage 使ってるコードいい加減なんとかしないとなあ

01 May 2018 Tue 14:32

アル中は死ぬ病気です

アル中は死ぬ病気です

治療受けて 1 年で 3 割ぐらい死にます。 5 年だと半分近く死にます。糖尿病、肝臓病、精神状態の悪化による自殺、酔いによる事故死などさまざまな死因があります。

アル中は否認する病気です

「自分が決してアル中であることを認めない」というのもアル中の症状です。「山口容疑者は自分がアル中であることを認めろ」などと責めてもなににもなりません。

アル中の治療とは断酒です

アル中による急性の諸症状が落ち着かせたらあとはひたすら酒を飲まないように指導するのが治療です。一度アル中になった人が治療の結果酒との適切な付き合い方を回復できるということはありません。

むしろ一度断酒した人が再度飲酒を開始した場合治療開始以前よりも激しい依存症になりそのまま死亡することが多いです。

たとえばほんのちょっと、一滴飲まされた というのから 3 ヶ月で車に飛び込んだだかぼーっとしてて轢かれただかで死んだ人を見たことがあります(彼女の場合自殺なのか事故なのかよく分かりませんでした)。

アル中で断酒している人にいたずらで酒を飲ませる みたいなことは殺人です。まず証拠は残りませんから、殺人をしたいと思っている場合はやってみるといいでしょう。

アル中はなかなか治りません

1 年で 3 割死んで 5 年で半分死ぬ、ということから分かるとおり、 4 割ぐらいの人しか治療 == 断酒には成功しません。

アル中患者のケアは極めて危険な行為です

多くの場合ケアをする側の精神にも多大な傷を残すものです。 TOKIO のメンバーは山口容疑者をケアすべき、などと言うべきではないです。

自分の身を守るためにアル中の近親者を見捨てざるを得なかった、ということを心の傷としている人たちは沢山います。そのような人達の古傷にさらに切り付けるような行為です。そういう人達を傷つけて遊びたい場合はやればいいです。

山口容疑者は以前からアル中の治療を受けている可能性が高い

https://jisin.jp/serial/johnnys/johnnysinfo/26142 などにある通り、精神科への通院をしているようです。

そのうえで記者会見の場に出てきて否認をする、というのはそれはもうそういう病気だから、としか言いようがないです。

アル中は性犯罪を誘発しません

山口容疑者が性犯罪者になったのは、アル中とはあまり関係ない彼固有の問題です。

山口容疑者の「責任」を問うのはほぼ無意味です

精神病患者であろうと犯罪の「責任」はその当人にしか帰さないものです。しかし犯罪の「責任」とはどういうことでしょうか。私は「更生のための適切なアクションを取らない限り社会がその人物を排除することを認める」ということだと思っています。

つまり、「責任」とは帰るべき場所のある、どこまでも生きている者の世界の話です。ですが、山口容疑者は急性アルコール性肝炎ないしは肝硬変で入院し、退院直後に今回のトラブルを起しています。正直彼は棺桶に片足を突っ込んでいます。口でどれだけ否認をしたところで、彼自身終焉の時が近付いていることは理解しているはずです。

そのような人物にたいして生者の理屈は通用しません。

27 Apr 2018 Fri 14:12

VR 機器常に持ち歩くみたいの結構キツい

26 Apr 2018 Thu 09:53

日報 2005 年分はとりあえず全部読んだ

その結果の感想としては、やはり https://diary.app.ssig33.com/349 で書いたような事態である可能性は高いと思う。

のように受け取った人がメモを書き込んだ形跡が多々あるので。

というようなことを思う。

以下は読んで面白いと思ったことシリーズです

イラクではスイカに毒を入れるのは一般的

イラクの冠婚葬祭

指揮官の能力差について

太田清彦一佐(当時)の群長指導

立花尊顯一佐(当時)の群長指導

イギリスは糞

気温やばい

連絡将校日記シリーズ

17 Apr 2018 Tue 00:49

キャッシュで問題解決しようとするとだいたいひどい目に合うんだよな 。そのキャッシュいらなくなってもやめわすれてたりとか、、、

16 Apr 2018 Mon 19:31

変なところにキャッシュいれてた、、、

16 Apr 2018 Mon 19:30

なんかキャッシュうまいところ飛びませんね

16 Apr 2018 Mon 19:26

Dell のデカい PC 手持ちのあらゆるカバンに入らなくて即死したので https://www.amazon.co.jp/dp/B074JF38SF/ これ買った。

15.6 インチ PC 対応みたいなやつ MacBookPro がギリギリ入るみたいなサイズであることが多いのでこういうデカい 15.6 インチ PC 買うと破滅するなという感じでした。

買ったカバンは PC と VR 関連機器全部入るので最強

16 Apr 2018 Mon 11:57

Cloudflare で TLS 対応して Fastly でキャッシュしたりバックエンドにルーティングしたり みたいな構成が貧者の最強 Web サイト運用プランという感じしますね。

14 Apr 2018 Sat 23:12

ssig33.com も Fastly でキャッシュするようにした

14 Apr 2018 Sat 23:12

Dell の Inspiron 7000 Gaming とかいうやつ買った ら翌日に中国で次世代機発表されて oh... となったのだが CPU に HT ついたことぐらいしか差分なくて 17% オフで買えたしまあよかったかなという気持ち。

安かったから 3 年保証とかつけてしまったけど GTX 1060 のノートを 3 年も使うかどうか、、、、

  • 1 年目: 一部超高負荷 VR ゲー以外は余裕
  • 2 年目: 多少無理出てくるけど非 VR ゲーは問題なし
  • 3 年目: バッテリーもへたってきて実質雑用機化

という感じになるんですかねー

14 Apr 2018 Sat 23:00

日報の再発見

家掃除してなら渋い資料が出てきた

Rick Koikeさん(@ssig33)がシェアした投稿 -

ぼくはこんな資料を持っています。おそらく、公安警察の警察官が私的にファイリングしてきたものだと思います。そこに、以下のようなものがあります。

Rick Koikeさん(@ssig33)がシェアした投稿 -

これをファイルした警察官の素性について、ぼくは全く知りません。ですが、彼は「捨てろ」という指示を守らなかったわけです。ここに載っている門脇なる人物は白鳥事件の関係者なので、これはおそらく 1950 年代に作成されたファイルでしょう。

「旧軍の戦闘詳報ですらちゃんと残ってるんだから自衛隊の日報がちゃんと管理されてないわけない」みたいな意見ありますが、少なくとも警察においては 1950 年代の時点で「資料を焼け」と上層部が指示し、そう言われた警察官はその命令を無視して勝手に資料を保管する、そんなふうになっていたわけです。

結局のところその旧軍の文書管理にしたところで上っ面だけをまねた猿真似にすぎず、情報を大量に蓄積して活用するなんて考え方は日本に定着したことは一度もなく、文書管理は常にいい加減であったみたいな可能性のほうがはるかに高いんじゃないでしょうか。

だいたい旧軍の発行文書だって「あったらしいことはわかってるけどどこにも現物はない」なんて話いくらでも聞くじゃないですか。

11 Apr 2018 Wed 12:03

まともな Slack クライアントとしての IRCCloud のご紹介

irccloud

IRCCloudというサービスがあります。 IRC を使っていた人には tiarra + web クライアントみたいのをサービス化したもの、と言えば一言で分かってもらえるようなサービスです。 Android と iOS で動くクライアントもあり、とても快適です。

こちらのサービスですが、先月 Slack に(IRC 経由ではなく)直接接続する機能が実装されています。

これによって何が嬉しいのかというと、複数のチームをまたいで未読のチャンネルをどんどん読んでいくみたいなことが非常に簡単になっています。 Slack チームの切り替えのレスポンスの悪さは悲惨なものですが、 IRCCloud はそのあたりが非常に快適です。スレッドのような Slack 独自の機能にもきちんと対応しています。

Slack 接続を使うには月 $5 の有料プランを使用する必要がありますが、たくさんの Slack チームに参加している人の場合、快適にチャンネルを読み書きするというインタラクションに年間 6000 円ちょっとを払うというのは、悪くない選択だと思います。本当に快適なので。

IRCCloud のユーザーが増えて少しでもこのサービスの継続性が上がってほしいので勝手に宣伝したというお話でした。

06 Apr 2018 Fri 08:57

見てるページを全部保存するという行ない をもうずっとしていて、以下のような user.js でページを全部保存してます。

// ==UserScript==
// @name         見たサイト全部保存
// @namespace    http://tampermonkey.net/
// @version      0.1
// @author       You
// @match        http://*/*
// @match        https://*/*
// @grant        GM_xmlhttpRequest
// @noframes
// ==/UserScript==

if(!!document.querySelector('title')){
  const title = document.querySelector("title").textContent;
  const url = location.href;
  GM_xmlhttpRequest({method: 'POST', url: '秘密の API', data: JSON.stringify({title: title, url: url})});
}

で秘密の API で受け取ったものを、あとから非同期処理で puppeteer でキャプチャと PDF を取得しています。

const puppeteer = require('puppeteer');

(async () => {
  try{
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto(process.argv[2]);
  await page.screenshot({path: 'data/'+process.argv[3]+'.thumbnail.png'});
  await page.screenshot({path: 'data/'+process.argv[3]+'.png', fullPage: true});
  await page.pdf({path: 'data/'+process.argv[3]+'.pdf'});
  await browser.close();
  } catch(e) { console.log(e) ; proccess.exit()}
})();

でまあいろいろあって Web からこんな感じでみられるようにしてます。

img

pupeteer で取得した PDF は Google Drive に Google Docs ドキュメントとしてアップロードもしてます。こうすると Google Drive を無料で使える全文検索エンジンとして利用することができ、最強ということになります。

Web 側の UI に Google Drive で検索してきて、それと関連するキャプチャとかを見られるような UI とかをつけてあります。

見たページをこういうかたちを全部保存しておくと、サイトが潰れたりしても大丈夫ですし、「どっかで見たと思うんだけどどこにあるか思い出せない」みたいな情報も「自分が見た範囲内から検索」ができるとあっさり見つかったりします。

03 Apr 2018 Tue 12:00

CDN であれこれやっていっているのは仕事でそういうことをしたいからで 自分が覚えるより知ってる人材雇ってもらうほうがはやいんじゃないの?とは思ってるんだが、そんな人材は求人市場にあんまり出てきてないっぽいんだよな。 死を感じる。

02 Apr 2018 Mon 17:04

iMac 買うか、、、

02 Apr 2018 Mon 14:04

人間性

29 Mar 2018 Thu 13:33

ねむい

29 Mar 2018 Thu 13:33

キャッシュに使う CDN Fastly にしてみた

ずいぶん前に Fastly 使ったとき Web 管理画面意味不明だったんだけど、今はかなりまともになってる。 とりあえず Fastly 試してみたいで導入しただけなのでこのサイトいまかなりやばいことになってて、 TLS 化するために Cloudflare 使っててその後ろに Fastly がいるみたいになってる。完全に無駄。

26 Mar 2018 Mon 23:02

Firebase がデフォルトで対応してない OAuth2 Provider に Firebase でログイン できたら便利だなと思ったのでやってみる。今回僕が扱いたい「Firebase がデフォルトで対応してない OAuth2 Provider」というのは今働いている会社であるところのユビレジです。

カスタム認証というのが提供されていて、そういうことをしたい時これを利用すればよいのだと思われる。ところが、これは基本的にはサーバーサイドで Firebase とやり取りして認証用トークンを作成する必要がある。

今回いじりたいのは自社サービスなので、そっちをいじってもいいのだろうと思う。ただまあめんどうなのでクライアントサイドと Cloud Functions だけで問題を解決したい。

というわけで CloudFunctions 側に以下のようなものを実装した。ここにある oauth2 というのは simple-oauth2 というライブラリのアレです、アレ。 redirect_uri はとりあえず http://localhost:5000/callback を指定している。

exports.auth = functions.https.onRequest((req, res) => {
  const authorizationUri = oauth2.authorizationCode.authorizeURL({ redirect_uri: redirect_uri });
  res.redirect(authorizationUri);
});


exports.callback = functions.https.onRequest((req, res) => {
  const tokenConfig = {
    code: req.query.code,
    redirect_uri: redirect_uri
  };
  // ユビレジの accessToken を取得
  oauth2.authorizationCode.getToken(tokenConfig).then((result)=>{
    const accessToken = oauth2.accessToken.create(result);
    const account_id = String(accessToken.token.account_id);
    // カスタムトークンを生成
    admin.auth().createCustomToken(account_id).then((customToken)=>{
      // ユビレジの accessToken を firestore に保存しておく
      const db = admin.firestore()
      const ref = db.collection('credentials').doc(account_id)
      ref.set(accessToken.token).then(()=>{
        ref.update(accessToken.token).then(()=>{
          res.redirect(`/?customToken=${customToken}`);
        });
      });
    });
  });
});

ルーティングは以下のように

  • / は index.html を普通に返す
  • /auth で ↑ の auth
  • /callback で ↑ の callback

を使う。

で index.html 側では location.search を見て customeToken があれば

firebase.auth().signInWithCustomToken

で認証してやっていく。たぶんこれでセキュリティ上の問題もない、よね?

これで Firebase Hosting と Firebase Cloud Functions だけで Firebase がデフォルトで対応していない OAuth2 Provider にログインが出来た。

サーバサイドで accessToken などを Cloud Firestore に入れているので、認証後はそこから accessToken をとってきてユビレジ API にアクセスできる。

というつもりだったのだが、ここまで作って気付いたことがあり、なんとユビレジ API は CORS 対応してないので、 Cloud Functions でプロキシしてあげないといまのままだと動かない、、、

というわけなので CORS 対応 Pull Request を作ろうと思う。

09 Mar 2018 Fri 17:31

Firebase 使ってみた 2018

最近は技術についてはレイトマジョリティでいいなと思ってる。 Firebase はもう完全にやっていけるかんじっぽいのというのを各方面から聞いたので試してみた。

だいぶ前に Firebase を使ってみたとき、 Realtime Database のクセが強すぎてこれはあかんなという感じだった。今では Cloud Firestore があるので話が違うだろうと思いあらためて実用アプリを一個作ってみた。

前にクライアントサイドだけで実行して保存先は Google Drive という野蛮なメモツールを作ったことがあった。これのバックエンドを Google Drive から Firebase にしてみた。

元々のツールが Google Drive との接続部分を一つのファイルに切り出していたので、これをいじって Firebase に対応するだけでスッと作れた。

出来たメモツール、 Markdown メモツールとして結構素性いい感じになったので別途公開したりしたい。

さらに React Native を使って iPhone クライアントも作ってみた。

Firebase の感想 2018 年版

Cloud Firestore はすごい

Realtime Database は本当にリアルタイムなアプリケーション専用の設計になっていて、リアルタイム性別にいらないんだけど、、、みたいな時はすごく使いづらかった。

Cloud Firestore は集計関連以外だいたい RDBMS みたいな感覚で使える。大抵のアプリにおいて Realtime Database よりも遥かに簡単に使えると思う。普通の Web 系プログラマーにとってはかなり直感的。

ただし、書き込み速度についてはかなり遅くて、たとえば特定のドキュメントのカウンターとかを頻繁に更新する場合は、そのドキュメントの配下にカウンター専用シャーディングドキュメントみたいのを作って更新時にランダムに選択したカウンターをインクリメントし表示時に合算せよみたいな地獄のノウハウが公式から提供されている。正直こんなのまともな人間がやることではない。

こういう無理なことをするくらいなら Cloud Functions 経由で BigQuery にデータをコピーし、 Cloud Functions に適切に API を実装することが楽である場合が多いだろうと思う。

「殆どの」ワークロードは Cloud Functions 抜きで実装でき、結果として自分で一からサーバーサイドをなんとかするより遥かに低コストになると思う。

全文検索も Cloud Functions で解決することが推奨されているタスクだ。このドキュメントで紹介されている algolia という全文検索ソリューションはかなり強力で、 Firebase に興味がないという人もこれだけは使ってみる価値があると思った。

また Firebase の特筆事項として「 Google/Twitter/Facebook およびメールアドレスとパスワード」でログインできるみたいなサイトを本当に一瞬で作れる点がある。認証まわりの気軽さは本当にすごい。

React Native と Firebase

react-native-firebase というライブラリがあって、結構楽にやっていける。ただし、 react-native-firebase で認証まわりを作るには現状かなりのエアリーディング力がもとめられる。各種ライブラリの README やドキュメントを読むだけでは動くものにはならないのが現状。

まとめ

これまで何度か Firebase で遊んでみて、その度に「これはダメだな、まだまだ Rails でサーバーを書く時代だ」などと思ったものだけど、そろそろ山が動いたと思った。

あと一言

Firebase という名前を mBaaS とアクセス解析という相互にそんなに関係ない二つの分野にひろがるブランド名に使っている結果検索性が非常に悪い。マーケティング担当者は切腹したほうがいい。

06 Mar 2018 Tue 14:50

泥酔

14 Feb 2018 Wed 14:28

Next