「通知の表示」の許可を求めてくるサイトが増えてうざい件 | tech - 氾濫原
出初めたぐらいに「これ、どうでもいい個人サイトとかもやりだしたらうざいだろうな」と思っていたけど、最近まさにそういう状態になっている。当然サービスワーカーもインストールされてる。ほとんどの場合サイトにアクセスしたときに勝手に出る。 たまたまうっかり見たサイトが「通知の表示」を求めてくるのは「お前おれのこと好きなんだろ」みたいな態度で心底気持ちが悪く、通知については明示的に許可がなければできないけど、サービスワーカーは自動的にインストールされるので、(別にそういう機能はないが) ストーカーっぽくてマジで気持ちが悪い。 特に前段階なしに通知の許可を求めるみたいなの、いったいどういうつもりなのか…… お前は「はじめまして〜」とか言った直後に「僕に興味があるんですよね? つまり好きってことですよね? 付き合いましょうよ〜」とか言う人間なのか。せめて「フィードを登録」みたいなノリで「通知をうけとる」
SQLite で「PRIMARY KEY」を《真のプライマリキー》とするには | tech - 氾濫原
http://www.sqlite.org/withoutrowid.html WITHOUT ROWID 最適化について SQLite は常に暗黙的な rowid カラムを持っていることになっている。これはカラムとして明示することもできるし、interger primary key として定義されたフィールドは暗黙的な rowid の代わりにすることができる。SQLite ではこの rowid が基本のプライマリキーになっている。 適当な数値をプライマリキーにしたい場合はこれで全く問題ないが、複合キーだったり文字列をプライマリキーにしたい場合、その表面上のプライマリキーとは別に rowid カラムができる。このケースでは表面上のプライマリキーを使って SELECT しようとすると、表面上のプライマリキーのインデックスを探したうえで、さらに rowid のインデックスを探すことになる。つま
リクエスト時の 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年後には消滅してるなというも
C++ でビットフィールドを再発明する | tech - 氾濫原
ビットフィールドとは C/C++にはほとんど使われてないがビットフィールドという機能がある。 union { uint8_t raw; struct { unsigned FAULT_QUEUE : 2; unsigned CT_PIN_POLARITY : 1; unsigned INT_PIN_POLARITY : 1; unsigned INT_CT_MODE : 1; unsigned OPERATION_MODE : 2; unsigned RESOLUTION : 1; }; } config; このように書ける。struct 内で名前の後ろについているのが、そのフィールドで消費するビット数で、この場合合計で8bitになり、それを uint8_t と共用している。 こうすると config.OPERATION_MODE = 2; などと、マスクやシフトを伴わずに直接書けて、結果
kakaku.com の最安データを Google Spreadsheet で自動的に使う | tech - 氾濫原
=IMPORTXML("http://kakaku.com/item/xxxxx/", "string(//*[@id='minPrice']/a/span)")+0 みたいにすればいい。 Google Spreadsheet 側は ¥ マークとかカンマとかを無視して数値解釈してくれる。ただ、+0 をつけないと SUM() できない。 これで最安構成の合計金額をすぐだせます。 IMPORTXMLは2時間のキャッシュがあるそうですがこの用途では問題にはなりませんね。 トップ tech kakaku.com の最安データを Google Spreadsheet で自動的に使う
TheSchwartz の prioritize を有効にしたときの挙動は愉快 | tech | perl - 氾濫原
ワーカー使っていると、一部のジョブだけちょっと優先的に実行したいということがあるので、TheSchwartz の場合、prioritize => 1 にしてプライオリティを有効にするとよいのですが、挙動でハマったのでメモをしておきます。 今回のケース そもそもジョブごとにプライオリティはつけていないが、一部のジョブだけ手動対応で優先して処理を行いたくなった。 やったこと 該当ジョブを update job set run_after = insert_time, grabbed_until = insert_time, priority = 1 where ...; で優先順位を設定しすぐに実行開始できるようにした 結果 ＿人人人人人人人人人人人人＿ ＞ なかなか実行されない ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣ というのも、TheSchwartz は priority 順で
Perl (PSGI) で zip ファイルを動的に作りつつ順次クライアントに送りつける | tech - 氾濫原
滅多にないことだと思うが、非常に大きな zip ファイルを動的に生成してダウンロードさせるみたいなことをしたいことがあるかもしれない。 Archive::Zip だとストリーム生成できないので、Archive::Zip::SimpleZip を使う。Archive::Zip::SimpleZip だとストリーム出力で file handle などに書き出せる。 これで一度ファイルに書いてから、そのファイルを sendfile 的にレスポンスしてもいいのだけれど、書いている間はクライアントからしてみれば完全に無反応になるので、場合によってはタイムアウトになってしまうことがある。そこでストリーム出力をそのままクライアントにストリームしたくなる。 簡単なコードにすると以下のようになった。Archive::Zip::SimpleZip にコールバックかオブジェクトを渡せたらいいが、渡せないようなの
ngResource は何が便利なのか？ | tech - 氾濫原
ngResource は単にAPIのラッパーという感じではなくて、JS でサーバ側のモデルとうまく同期するように作られている。 最も簡単な例だと以下のように使うが、Entry.get は XHR が完了する前に、とりあえず空のオブジェクトが返るようになっており、XHR の完了とともに破壊的に書きかえられる。これにより、entry の変更がすぐ全体に伝わるようになっている。 var Entry = $resource('/entry/:id'); $scope.entry = Entry.get({ id : 0 }); デフォルトで定義されている query/get/save/delete だけを見ると単に REST API のラッパーのように見えるが、独自のメソッドを追加するとより理解しやすいコードを書ける。 以下のコードは、デフォルトで下書き状態で生成される Entry オブジェクトを
perl 5.19.9 の signatures 構文 (普通に引数を書ける構文) を試す | tech - 氾濫原
Perl 5.19.9 で実装された signatures の構文をためしてみる - tokuhirom blog を見てそんなのできたのか〜と思ったので、いろいろ試してみた。なんとこれは、今までになく直感的に引数が書けてしまう革命的構文です。 use v5.19; use strict; use warnings; use feature 'signatures'; no warnings "experimental::signatures"; use feature 'lexical_subs'; no warnings "experimental::lexical_subs"; # 引数の数チェックをしてくれる。便利 eval { say "check length of arguments"; state sub hello ($foo) { say "hello $foo"; }
Ruby でスコープをはずれたときに自動で何かをする | tech - 氾濫原
Guard オブジェクト Perl だと Guard オブジェクトとかいうハックがあって、スコープを出るタイミングで必ず呼ばれるファイナライザを使って、あるスコープでだけ有効な処理を書けたりします。 例えば、DB のトランザクションや、あるいは以下のように依存するプロセスをあるスコープでだけ起動して終了するような用途で使われています。 { my $guard = Proc::Guard->new(command => [ "memcached", "-p", "12321" ]); # do something ... }; # memcached has been killed 適当なメソッドにブロック(サブルーチン)を渡せばええやん、という気もしますし、実際 Ruby の transaction の場合そういう感じになります (Perl でももちろん同じようなサブルーチンを書くことはで
| tech | Wed, Feb 19. 2014 - 氾濫原
見るたびにいちいちコードを読まないと安心して使えないライブラリなんてライブラリの価値がない。ライブラリ自体はブラックボックスになっていても、インターフェイスからその挙動を想像できるべきだ。 ライブラリを使っている側のソースを読む場合ではなく、あるライブラリを使おうとするときは、一度はライブラリの読んだほうがいいとは思うが、その目的は、そのライブラリが信頼できるかを計るためで、使いかたや、細かい挙動を確認するためではない。そして「どの程度信頼できるか」ということ、すなわちイケてるかイケてないかだけを覚えていればよい。 あるライブラリを使ったコードを読むとき、そのライブラリのソースまで毎回を読んで挙動を調べたりしなくてはいけないライブラリはインターフェイスがイケてない。ライブラリのインターフェイスが説明的になっていない。適切なインターフェイス設計がされていない。 適切なインターフェイス設計がさ
プログラムが書けない人に「仕様変更」について説明するには | tech - 氾濫原
「仕様変更」という言葉はプログラム書く人じゃないと、そのイメージが掴めないと思う。イメージが掴めない人に対してそれを説明するとしたら何がいいだろう？ と思った。 とりあえず、料理に例えたらいいのではないかと思ったので、それに例えて考えてみる。 仕様とはレシピのことであり、最終的には具体的に「食べることができる美味しい料理」すなわち「うまく動くプログラム」を作ることを目的としている。 仕様というのは、最初は「イタリア料理」「日本料理」「中華料理」程度しか示されない。当然この時点では方針程度しか考えることができない。食材を買うこともできない。せいぜい使う調味料を揃えるぐらいしかできない。 もう少し進むと、料理名まで具体化される。スパゲティを作りましょうとか、ピザを作りましょうとかだ。とりあえずここまできたら小麦粉を買おうとかまではできるかもしれない。でも実際に作りはじめることはできない。 さら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
