h2o を systemd 管理下にした | tech - 氾濫原
徐々に daemontools 依存を外していってるが、とりあえず h2o を systemd に管理にすることにした。どうも daemontools だと annotate-backtrace-symbols のプロセスと親 h2o プロセスが消えずにずっと残って悪さをするので、これも解決できたらなあという気持ち。 以下のように h2o.service を作って配置 [Unit] Description=H2O HTTP Server After=network.target [Service] Type=simple WorkingDirectory=/srv/www ExecStartPre=/usr/local/bin/h2o -c /srv/www/h2o.conf.yaml -t ExecStart=/usr/local/bin/h2o -c /srv/www/h2o.conf
ウェブ縄文時代への回帰 | tech - 氾濫原
2016年にウェブ縄文時代がどうこう書いたけど最近どうやらウェブ縄文時代が本当にきつつあるみたい、と書こうとしたら既に morygonzalez さんが書かれていた のであまり書くことはない。縄文時代というか、個人サイトへの回帰という話だけど、観測範囲のブログやら日記がASPホスティングから個人サイトに移行したりしている。 知り合いとチャットしていて教えてもらったけど、国内だけの事象というわけではないみたいで、今年の6月には The Return of the 90s Web という記事が書かれていた。不思議な潮流。 2017年に個人サイトは終わってしまったのかと書いたことがあるけど、終わってないかもしれないので嬉しい。このエントリでも触れてるけどASPホスティングの個人ブログも、セルフホスティングの個人サイトも境界は技術的には曖昧で、しいていえばコンテンツを自分で所持しているといえるかど
Node.js の fs モジュールだけで GPIO の割込みを扱うには？ | tech - 氾濫原
以下のようにすれば動くことが確認できた。 select や poll を明示的に呼び出すことができないが、edge を設定しさえすれば fs.watch でイベントを受けとれるようだ。 また、seek() もなぜか存在してないが read() の引数に position というのがあり、これが seek() 相当になるようだ。 const fs_ = require('fs'); const fs = fs_.promises; fs.watch = fs_.watch; async function watchInterrupt(pin, func) { try { await fs.writeFile(`/sys/class/gpio/export`, `${pin}`); } catch (e) { if (e.code === 'EBUSY') { // ignore } else
localhost と書くと IPv6 対応したときに死ぬことがある | tech - 氾濫原
127.0.0.1 より localhost のほうが書きやすいし良さそう、と思って localhost と書いているとしばしばハマります。 というかなんとなく localhost = 127.0.0.1 と考えがちではないでしょうか？ そんなことはないので気をつけましょう。 最近のシステムなら /etc/hosts を確認すると少なくとも2つの localhost エントリを見ることができるでしょう。 127.0.0.1 localhost ::1 localhost 上は IPv4、下は IPv6 です。localhost はどちらのアドレスにも解決しうるホスト名となっています。 どういうときにハマるか 例えば同一サーバでリバースプロキシを行ってバックエンドサーバと繋ぎこみを行う場合、フロントのリバースプロキシで localhost:5000 と書くと IPv4 IPv6 どちらでアク
minimist でサブコマンド付きコマンドを実装する | tech - 氾濫原
node.js 用のコマンドラインパーサである minimist は必要最低限かつわかりやすくていいですね。 しかもサブコマンド用のオプションも用意されているので、ある程度複雑でも耐えられます。 以下がサブコマンドを実装したもののサンプルコードです。ポイントは親コマンド側では stopEarly を指定して、サブコマンド用の引数を解釈させないところです。 そのうえであらためてサブコマンド用の引数を minimist にかけることで必要な機能が実現できます。良いですね。 #!/usr/bin/env node import * as minimist from "minimist"; const commands : { [key: string]: (argv: any[]) => void } = { foobar : function (_argv: any[]) { const ar
フロントエンドはブラウザの実装と普及に律速される… | Mon, Feb 20. 2017 - 氾濫原
フロントエンドはブラウザの実装と普及に律速されるので、それほど急にできることが増えたりはしない。全てのブラウザに実装がのったとしても、十分に普及するには年単位で時間がかかる。なので急いで何かを覚える必要があるってことはまずない。 破壊と再生が繰替えされてるのは、実現性に影響するようなクリティカルな部分ではなくて、便利ツールとか便利な考え方とかの部分なので、不便を感じはじめるまで評価を遅延しても良い。 ウェブフロントエンドは動きが早いように見えるけど、あれは暇な人がそういうふうに見えるようにしているだけで、実際はそうでもない。「今はこれを覚えるべき!」みたいなのが時々あるが、いいたいだけで内容がないのであまり気にしないこと。 ずっと追いかけていないと取り残されるみたいな焦燥感を持つ必要はない。人生有限なので他に楽しそうなことがあればそっちやっていくほうが良い。
RabbitMQ で MQTT over WebSocket | tech - 氾濫原
ウェブページから JavaScript で MQTT ブローカーに送られてくるデータを取得したかったので、MQTT over WebSocket を試してみました。 RabbitMQ 3.6.6 をいれる Ubuntu のレポジトリのは 3.5.7 と古いので、Installing on Debian / Ubuntu にしたがって 3.6.6 にします。 既に古いのが入っていても、説明通りに RabbitMQの apt レポジトリを設定して、 apt-get update して install したら自動でアップグレードされます。 プラグインをいれる rabbitmq_web_mqtt をいれます。これは Community Plugins にありますが、 RabbitMQ のチームが作っているので安心感があります。プラグイン自体が比較的新しくて、RabbitMQ 3.6.1 以降でない
センサーデータ用に RabbitMQ + MQTT をセットアップする | tech - 氾濫原
RabbitMQ + MQTT で Pub/Sub サーバを立てることにしました。 いろいろなセンサーのグラフ化にあたって GrowthForecast へ直接 POST を行っていましたが、やはり一旦メッセージブローカー的なものをいれたほうがよさそうだという感じになってきました。 なぜメッセージブローカーが必要か センサーデータを複数のプログラムから使いたい場合、特にほぼリアルタイムで情報を得たいようなケースだと、直接各アプリケーションに投げるのではなくて、センサーはある一箇所に値を投げることだけを考え、アプリケーションはある一箇所からデータを受けとることだけを考えるように分離したくなります。 例えば今まではセンサーデータをアプリケーションであるグラフサービスに直接投げていましたが、これだとセンサーデータをさらに別のデバイスから読みだして表示するといった場合に、本来の用途ではないグラフサ
さくらのVPSのウェブサーバでIPv6の接続をうける | tech - 氾濫原
最初からアドレスついてたので意外とやることない。 ifconfig すると既に v6 のアドレスがついている。Scope:Global になっているやつがグローバルIPアドレス (正確にはグローバルユニキャストアドレス) inet6 addr: 2001:e42:102:1807:160:16:210:51/64 Scope:Global これを該当ドメインの AAAA レコードでひけるようにする。 nginx nginx -V の結果に --with-ipv6 があることを確認する。 server { listen 80; listen [::]:80; ... } という感じにして ipv6 側もlistenするようにする。 h2o listen: 80 と書いてる場合、デフォルトで v6 も listen するようになっているのでやることはない。 DNS サーバの IPv6 対応 こ
さくらのVPSにMondo Rescueのリストアができなかった (未解決) | tech - 氾濫原
前々から準備していて、いよいよ新しく契約を追加してリストアするぞ! と思ったらできませんでしたので顛末を記す。敗戦は惨め。 Ubuntu 12.04 で生成 バックアップをとったサーバは大阪リージョン、HDD 100GB メモリ1GB (さくらのVPS(v3) 1G) です。 sudo mondoarchive -O -i -N -d /tmp/backup -s 30g こんな感じで生成しました。HDD 100GB ですが Used: 12GB です。 $ mondoarchive -v mondoarchive v3.2.2-r3578 $ uname -a Linux stfuawsc.com 3.2.0-88-generic #126-Ubuntu SMP Mon Jul 6 21:33:03 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux さくらの
ErgoDox ではないナニか。オープンソースかつ Bluetooth 接続のキーボード | tech - 氾濫原
ここ数ヶ月ぐらいキーボードを作っていた。そのためにいろいろ yak-shaving としかいいようがないことも多々していた。 いろいろ書くことが多いので、細かい設計などについては別途エントリを分ける。 コンセンプトとキーレイアウトおよび技術仕様の決定 回路設計とアートワーク・実際の製作 ファームウェアの実装 あたりをそれぞれ別途詳細なエントリを書く。だいたいの人は細かいことはどうでもいいと思うので、概要のみこのエントリにまとめる。 コンセプトや特長 UNIX ベースのキーレイアウト (というかHHKBをベース) とし、違和感なしに分割キーボードとする。 キー配列 UNIX キーボードを2分割した形を基本にする。つまり HHKB とほぼ同じで、Ctrl キーはAの左、ESC は 1 の左など。 矢印キーはどうしても欲しい (HHKB への大きな不満のひとつ) F1〜F12キーもできれば欲しい
「通知の表示」の許可を求めてくるサイトが増えてうざい件 | tech - 氾濫原
出初めたぐらいに「これ、どうでもいい個人サイトとかもやりだしたらうざいだろうな」と思っていたけど、最近まさにそういう状態になっている。当然サービスワーカーもインストールされてる。ほとんどの場合サイトにアクセスしたときに勝手に出る。 たまたまうっかり見たサイトが「通知の表示」を求めてくるのは「お前おれのこと好きなんだろ」みたいな態度で心底気持ちが悪く、通知については明示的に許可がなければできないけど、サービスワーカーは自動的にインストールされるので、(別にそういう機能はないが) ストーカーっぽくてマジで気持ちが悪い。 特に前段階なしに通知の許可を求めるみたいなの、いったいどういうつもりなのか…… お前は「はじめまして〜」とか言った直後に「僕に興味があるんですよね? つまり好きってことですよね? 付き合いましょうよ〜」とか言う人間なのか。せめて「フィードを登録」みたいなノリで「通知をうけとる」
Server::Starter を node.js のサーバ起動に使う | tech - 氾濫原
Server::Starter は hot deploy 用の汎用スーパーデーモンで、Perl で書かれています。h2o の起動にも使われているのでみなさんおなじみでしょう！ Server::Starter がやってることは、Server::Starter 側で listen したソケットの fd を環境変数につっこんで子プロセスを起動というものです。子プロセス側では渡ってきた環境変数を読んで、fd について accept すれば良いことになります。 これを node.js でやるには以下のようにすれば良いようです。 //#!/usr/bin/env node "use strict"; const http = require('http'); const server_starter_port = process.env['SERVER_STARTER_PORT']; if (!ser
ブログのキャッシュバックエンドの変更 | tech - 氾濫原
今までは Cache::FileCache によるファイルシステムキャッシュにしていたけど、いくつか問題があって SQLite にかえた ファイルシステムキャッシュで困っていたこと なんか遅い キャッシュ無効化の処理のためにキャッシュを生成元とキャッシュのキーをキャッシュ内に格納したいが、アトミックにやるうまい方法がなかった SQLite 選択 Redis とかを立てるのが機能的には便利そうだけど、リソース的にあんまりサーバプロセスを増やしたくはないので、SQLite とした。 CREATE TABLE cache ( `cache_key` TEXT NOT NULL PRIMARY KEY, `content` BLOB NOT NULL ); CREATE TABLE cache_relation ( `id` INTEGER PRIMARY KEY, `cache_key` TEX
ES2015 の iterable/iterator/generator による無限 FizzBuzz (オブジェクト指向編) | tech - 氾濫原
ES2015 の iterable/iterator/generator による無限 FizzBuzz | tech - 氾濫原 に続いて、オブジェクト指向っぽく書けるようにしてみました。 ポイントはジェネレータ的なものをラップして常に It というクラスのインスタンスにするところです。 "use strict"; function It(iterable) { if (typeof this === 'undefined') return new It(iterable); this.iterable = iterable; } It.countup = function* (n) { for (;;) yield n++; }; It.prototype = { zip : function* () { const iterators = []; for (let it of this
Generator は iterator であり、iterable でもある | tech - 氾濫原
表題の通りですが、Generator にはいずれの protocol も実装されています。気になるのは iterable の挙動ですが、どうやらレシーバーの Generator 自身を返すようです。 function* count (n) { for (;;) yield n++; } var c = count(1); console.log(c.next, c[Symbol.iterator]); //=> [Function: next] [Function: [Symbol.iterator]] // iterator protocol console.log(c.next()); //=> { value: 1, done: false } console.log(c.next()); //=> { value: 2, done: false } console.log(c.ne
HTTP2 で何をサーバープッシュすべきか | tech - 氾濫原
意外と何をプッシュすべきか悩んだのでひとまず現時点での自分の結論をまとめました。 CSS は必ずプッシュ・JSは場合による サイトの構成によりますが、ページの表示に必要なものは全てプッシュするべきのようです。 CSS の全て ページの根幹に関わるJSの全て サーバプッシュの目的 まずサーバプッシュの目的を改めて確認しておくと、これはクリティカルレンダリングパスを削減するためです。 クリティカルレンダリングパスについては クリティカル レンダリング パスのパフォーマンスを分析する | Web Fundamentals - Google Developers がわかりやすいです。 サーバープッシュなしの場合 HTML+CSS 構成のページはクリティカルレンダリングパスが必ず2以上になります。つまり最低でもRTTの2倍の時間がページ表示に加算されます。 これをサーバプッシュで行う場合、HTML+
ブログシステムの HTML 生成を効率化 | tech - 氾濫原
そろそろやることなくなったので minify などをやることにしました。 ただ、ブログシステムの出力の最後ほうでページごとに全体を minify すると、全体としてどうしても処理に時間がかかってしまいます。要求として、キャッシュなしの状態からでも1エントリあたり0.1秒ぐらいでは処理したいので、これだと厳しい感じでした。(約7900エントリぐらいあるので、0.1s で処理しても全体のキャッシュ再構築に13分かかる計算です) いろいろ考えたのですが (そもそも minify しないとかも)、以下のようにしました エントリ本文はエントリ保存時に minify しておく (本文はDB に格納) テンプレートをテンプレートの段階で minify してキャッシュしておく minify には html-minifier を使っています。html-minifier はテンプレートを対象にした minif
リクエスト時の Cache-Control、max-age=0 と no-cache の違い | tech - 氾濫原
ほとんどのブラウザで、通常リロードは Cache-Control: max-age=0、スーパーリロードで Cache-Control: no-cache がリクエストヘッダとして送られてくるみたいなのですが、実際の挙動はともかく意味の違いがよくわかりませんでした。 RFC7234 によると max-age は The "max-age" request directive indicates that the client is unwilling to accept a response whose age is greater than the specified number of seconds. Unless the max-stale request directive is also present, the client is not willing to accept
筋の悪さ | tech - 氾濫原
JS しか書いてないんだなって人は筋悪いものをありがたがっていたりする印象はある。しかし筋悪いものをありがたがるみたいなのはどこにでもいるので、JSがどうとかは直接は関係がないはずではあると思う。JSしか書いてない人とPHPしか書いてない人は似たようなもんで、単に広範囲の知識に興味がないだけな気がする。 それはともかく「これは筋悪そうだな」っていう感覚がどこからくるのかよくわかってないので、現時点で思いつく限り雑にメモしておく。 割の合わなさ 「これは何の問題を解決してるんだろう」と思ってドキュメント読んだりソース読んだりした結果、大したことを解決してなくて、その割に実装量が多いとか学習コストが高いと、筋悪いなあと思う。 フットプリントや学習コストに対して提供されるモノが「割に合わない」のは筋が悪く感じる。 将来性のなさ 「あ、これはただの流行だな」みたいな、5年後には消滅してるなというも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
