パスワード保存のベストプラクティスと bcrypt のメモ書き | tech - 氾濫原
考えてみるとほとんどパスワードを保存するコードを書いたことがない。現状のベストプラクティスを知らなかったのでメモ書き。 現状では bcrypt 使うのがいいみたい。b は Blowfish の b。 Modular Crypt Format というフォーマットとコンパチの出力をする。crypt (3) はもともと DES の短いフォーマットだが、弱すぎたため md5 拡張なりSHA512 拡張などが存在している。(htpasswd でも使われているので見たことある人は多いだろう) これの Blowflish を使ったものが bcrypt で、prefix に $2$, $2a$, $2x$, $2y$ $2b$ がついている。prefix の違いはバージョンの違いであり、現在は 2b を使うのが良い。ストレッチング回数も出力に含まれるので、あるとき急にストレッチング回数を増やしても特に問題
「通知の表示」の許可を求めてくるサイトが増えてうざい件 | tech - 氾濫原
出初めたぐらいに「これ、どうでもいい個人サイトとかもやりだしたらうざいだろうな」と思っていたけど、最近まさにそういう状態になっている。当然サービスワーカーもインストールされてる。ほとんどの場合サイトにアクセスしたときに勝手に出る。 たまたまうっかり見たサイトが「通知の表示」を求めてくるのは「お前おれのこと好きなんだろ」みたいな態度で心底気持ちが悪く、通知については明示的に許可がなければできないけど、サービスワーカーは自動的にインストールされるので、(別にそういう機能はないが) ストーカーっぽくてマジで気持ちが悪い。 特に前段階なしに通知の許可を求めるみたいなの、いったいどういうつもりなのか…… お前は「はじめまして〜」とか言った直後に「僕に興味があるんですよね? つまり好きってことですよね? 付き合いましょうよ〜」とか言う人間なのか。せめて「フィードを登録」みたいなノリで「通知をうけとる」
ErgoDox ではないナニか。オープンソースかつ Bluetooth 接続のキーボード | tech - 氾濫原
ここ数ヶ月ぐらいキーボードを作っていた。そのためにいろいろ yak-shaving としかいいようがないことも多々していた。 いろいろ書くことが多いので、細かい設計などについては別途エントリを分ける。 コンセンプトとキーレイアウトおよび技術仕様の決定 回路設計とアートワーク・実際の製作 ファームウェアの実装 あたりをそれぞれ別途詳細なエントリを書く。だいたいの人は細かいことはどうでもいいと思うので、概要のみこのエントリにまとめる。 コンセプトや特長 UNIX ベースのキーレイアウト (というかHHKBをベース) とし、違和感なしに分割キーボードとする。 キー配列 UNIX キーボードを2分割した形を基本にする。つまり HHKB とほぼ同じで、Ctrl キーはAの左、ESC は 1 の左など。 矢印キーはどうしても欲しい (HHKB への大きな不満のひとつ) F1〜F12キーもできれば欲しい
Adsense の新しい広告ユニット | tech - 氾濫原
最近になって「関連コンテンツ」と「ページ単位の広告」というのが beta になって登場した。サイト最適化と同時にこれらも有効にしてみたりしていた。 関連コンテンツ 広告ユニットではあるが、サイト内の関連コンテンツを表示してくれるので普通に便利。先頭に2つぐらい広告が入る感じ。便利になるだけで収益にならないユニットなのかと思ったけど、ちゃんと収益にもなる模様。 パフォーマンスレポートを見てみても、他のユニットと比較してかなり収益性が高そう (このサイトの場合そもそも微々たるものだけど) ページ単位の広告 「ページ単位の広告」という名前の中にさらに2種類ある。 「アンカー広告」はよくあるスマフォ向けの広告で、画面下を常時占領するタイプ。ただ、position: fixed で固定しているようで、JS の scroll イベントを奪っている系のウザさはないのが救い。 「モバイル全面広告」はときど
筋の悪さ | tech - 氾濫原
JS しか書いてないんだなって人は筋悪いものをありがたがっていたりする印象はある。しかし筋悪いものをありがたがるみたいなのはどこにでもいるので、JSがどうとかは直接は関係がないはずではあると思う。JSしか書いてない人とPHPしか書いてない人は似たようなもんで、単に広範囲の知識に興味がないだけな気がする。 それはともかく「これは筋悪そうだな」っていう感覚がどこからくるのかよくわかってないので、現時点で思いつく限り雑にメモしておく。 割の合わなさ 「これは何の問題を解決してるんだろう」と思ってドキュメント読んだりソース読んだりした結果、大したことを解決してなくて、その割に実装量が多いとか学習コストが高いと、筋悪いなあと思う。 フットプリントや学習コストに対して提供されるモノが「割に合わない」のは筋が悪く感じる。 将来性のなさ 「あ、これはただの流行だな」みたいな、5年後には消滅してるなというも
JavaScript の必要ないソーシャルボタン | tech - 氾濫原
JSなしのソーシャルボタンというのを作ってみました。このサイトの各エントリ下部に実装されているものです。 動機 各サービス、JS を読みこんでボタンを表示するタイプのものをメインに提供していますが、ソーシャルサービスへのシェアという機能で外部リソースの読み込みとJSの実行が発生するのは、提供される機能に対して割に合わないのではないかと思っていました。 実際ウェブサイトのパフォーマンスチューニングをしていると、細かいボタンのJSのダウンロード・パース・実行・表示後のリフローが結構多くて気になります。 実装 テストページ https://lowreal.net/2016/sharebuttons/test.html サービス Facebook Twitter Google+ LINE はてなブックマーク HTML+CSS+各サービスのアイコン画像(5つ)です。 各サービスのアイコンをSVGにし
YAPC::Asia で「ウェブエンジニアのローレベルプログラミング」という発表をしました | tech - 氾濫原
ちょっと時間に対して話したいことが多すぎて、各分野での掘り下げが足りなかったとは思いますが、一通り下のほうまで盛りこみました。 電子工学について：自分は学校で電子工学を体系的に学んだことはありません。 YAPC 会期中はそこらへん歩いてます。
プログラムが書けない人に「仕様変更」について説明するには | tech - 氾濫原
「仕様変更」という言葉はプログラム書く人じゃないと、そのイメージが掴めないと思う。イメージが掴めない人に対してそれを説明するとしたら何がいいだろう？ と思った。 とりあえず、料理に例えたらいいのではないかと思ったので、それに例えて考えてみる。 仕様とはレシピのことであり、最終的には具体的に「食べることができる美味しい料理」すなわち「うまく動くプログラム」を作ることを目的としている。 仕様というのは、最初は「イタリア料理」「日本料理」「中華料理」程度しか示されない。当然この時点では方針程度しか考えることができない。食材を買うこともできない。せいぜい使う調味料を揃えるぐらいしかできない。 もう少し進むと、料理名まで具体化される。スパゲティを作りましょうとか、ピザを作りましょうとかだ。とりあえずここまできたら小麦粉を買おうとかまではできるかもしれない。でも実際に作りはじめることはできない。 さら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
