サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
中東情勢
please-sleep.cou929.nu
bash のシェルスクリプトを書くときに、いつも脳死で以下をやっている。(同僚が整備してくれたものをコピペしている) エディタなり CI で shellcheck をまわす set -euxo pipefail と冒頭に書く こんな感じ #!/bin/bash set -euxo pipefail いつまでもコピペではさすがにアレなので、意味を調べたメモ。 shellcheck koalaman/shellcheck: ShellCheck, a static analysis tool for shell scripts イケてない書き方に警告を出してくれる それぞれの警告にはエラーコード割り振られていてとても便利 エラーコードごとに正誤例、解説が書かれているのでわかりやすい SC1000 の例 CI もそうだし、エディタのプラグインも充実 しているのでとりあえず入れておくと良い set
マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
Go の database/sql パッケージ の DB 構造体 は、データベースへのコネクションプールを管理し、かつスレッドセーフ (goroutine セーフと言ったほうが良いのだろうか…?) にそれらの接続を使用できることを保証している。 ドキュメント にも次のように書かれている。 DB is a database handle representing a pool of zero or more underlying connections. It’s safe for concurrent use by multiple goroutines. こちらの基本的な実装内容と、動作を制御するパラメータについて調べてみた。 基礎知識のおさらい database/sql パッケージはデータストアの実装によらない一般的な SQL のインタフェースを提供している。具体的なデータストアへの接
Browserify を触ってみたメモ。 Browserify とは CommonJS のモジュールの仕組み、つまり Node.js の require をブラウザ上でも使えるようにするもの、ということでいいみたい。Readme を読む限りは、npm にあるモジュールをブラウザ上にもっていくために作られ始めたような印象をうけるが、ちまたのエントリーをみていると AMD に代わりに CommonJS でフロントエンドの依存関係の管理をする (RequireJS ではなく、Node.js 感覚で require 関数をフロントエンドで使う) ためのツールとしても使っていいようだ。 やりたいこと 複数の js ファイルの依存関係を記述したい 最終的に、依存関係を考慮した順番で、ひとつの js ファイルに結合したい 作りたいのは第三者のサイトに埋め込んでもらうスクリプト (サードパーティスクリプト
Google JavaScript Style Guide 和訳 Google JavaScript Style Guide の本家の更新に和訳も追従した。 主な変更点 クリティカルな修正が多かった。そもそもの言語仕様の間違いが二点と、脆弱性につながるルールの修正。 NaN == NaN が true になるという 間違った記述 の修正 セミコロン省略時の自動挿入について。二項演算子の前には自動挿入されないが、されるという前提のルールになっていた。そのためルールの必然性がなくなってしまった。 その旨をコメントに記載しつつ、一貫性のため過去と同じルールでこれからも行くことになった。 eval() の利用を JSON のパースに利用することを禁止。普通に JSON.parse() を推奨するように。 JSON を eval() でパースすると、悪意のあるコードが実行される脆弱性になる。その旨も
古い文章だけど、Caching Tutorial for Web Authors and Webmasters を読んだメモ。ウェブマスター向けのブラウザキャッシュの概要。 ブラウザキャッシュは、ブラウザがサーバからレスポンスされたリソースを (場合によっては) ローカルに保存しておいて、二度目以降の表示では (場合によっては) キャッシュから読むという動作。無駄なリクエストが減ることでサーバリソースにも優しいし、ユーザーにとっては表示速度向上というメリットがある。 コンテンツをどのようにキャッシュするかを、サーバが UA に HTTP ヘッダを利用して指示する。Expires や Cache-Control ヘッダがその例だ。html の meta 要素で、たとえば <meta http-equiv="Cache-Control" content="no-store" /> というふうに
プライベートブラウジングモードのいろいろ - Please Sleep の続き。あるブラウザがプライベートブラウジングモード (Private Browsing, InPrivate Browsing, Incognito) であるか JavaScript で判定する方法について。 browser history sniffing の対策が入りプライベートモードの一般的な判定ができなくなったと思われたが、ブラウザによっていくつかの API の挙動が通常・プライベートモードで変化するため、それを利用して判定ができるということを教えていただいた。 @cou929 http://t.co/1OE9k3kJv9 プライベートブラウズ判定方法あります、SafariだとlocalStorage,DNT Firefox Chromeは https://t.co/mDDRfUeCP9 — ma
すこし古いけどこちらを読んだ。 pull request を利用した開発ワークフロー // Speaker Deck 非常にわかりやすく読ませてもらったが、本筋とはちょっとずれるレビューの勘所の話がとても面白く参考になった。 レビューコメントにラベルをつける [MUST] 問題があり、必ず治す [IMO] 意見、緩やかな指摘。自分ならこう書くけどどう? [nits] ほんの小さな指摘。インデントやタイポ たしかに普段のコードレビューでも、特に意識せずこれらは使い分けていた。こうしてラベルとして明示することでレビュイーに意図が伝わりやすい。レビュアーもこうした観点からレビューを行える。なによりレビュアー・レビュイー双方にとって明確に、指摘事項に優先順位がつけられる。こうすることでレビューとその後のアクションをよりスムーズにすすめる手助けになっている。 いいレビューとだめなレビューというものは
Friendly iFrame という、サードパーティスクリプトの呼び出し方法について調べた。手法自体はかなり古いもので、後述する iAB のドキュメントは 2008 年に出ているものだ。Google の DFP などでは現在でも使われている。 Friendly iFrame (FiF) とは サードパーティのスクリプト (広告タグや SNS のシェアボタン、ブログパーツなど) をページに埋め込む手法のひとつ。より狭義には、iAB が出す Best Practices for Rich Media Ads in Asynchronous Ad Environments (pdf) で説明されている、(主に) リッチアドのアドタグを設計・設置する際のベストプラクティス。 利点と他手法との比較 Friendly iFrame を他のサードパーティスクリプトの埋め込み手法と比較すると、ページのレ
GoogleのDesign Docについて調べました.Design Docとは,Googleのエンジニアがソフトウエアを開発する際に必ず書くドキュメントです. 一般的にDesign Documentというと,設計仕様書のことをさすようです.設計仕様書はソフトウエアのシステム的な設計がどのように行われているかを記したドキュメントです.一方でGoogleのDesign Docは,あるソフトウエアについて,何を・なぜ・どのように作るかを記したもののようです.両者ともあつかっている対象や,対象としている読者が少しずつ異なっています.このエントリーではGoogleのDesign Docについて扱います. Design Docの内容 Design Docについては,Googleの鵜飼文敏さんによる以下のプレゼンテーションで触れられています. 鵜飼文敏さんの講演「ハッカーのソフトウェアエンジニアリング」
PhantomJS で itunes の url に接続しようとするとエラーになり、デバッグしたいので方法を調べた話。 まず、SSL の通信なので、別のプロセスから tcpdump などで通信をキャプチャすることは難しい。 方法の一つとして、--debug=yes というコマンドラインオプションを渡すと、詳細なログをだしてくれるようだ。(ドキュメント には載っていないオプションだった) $ phantomjs --debug=yes crawl.js 2014-11-01T15:53:28 [DEBUG] CookieJar - Created but will not store cookies (use option '--cookies-file=' to enable persisten cookie storage) 2014-11-01T15:53:28 [DEBUG] Pha
iPhone アプリのデバッグや挙動調査のために通信を見てみたい。Burp Proxy というソフトで proxy を mac にたてておき、iPhone の proxy 設定を mac に向けて、いわゆる Man in the Middle 方式で通信を覗いてみる。仮想の SSL 証明書を iPhone にインポートすることで SSL 通信もキャプチャできる。JailBrake は不要。 必要なもの Burp Proxy iPhone 構成ユーティリティ 手順 Burp Proxy の起動と設定 proxy タブ -> option タブ -> proxy listeners にエントリがひとつあるので選択して edit Bind to address -> All interfaces を選択。ダイアログが出るが続行する Intercept タブに移って、”Intercept is O
モジュールのロードまわり lib/sinon.js がモジュールのエンドポイント sinon object の作成、環境に応じた初期化、ユーティリティメソッドの定義を行う spy や mock などの機能毎にファイルが分かれる lib/sinon/*.js に配置 lib/sinon/spy.js など sinon.js 大きくは以下のように sinon object を作って返す。 var sinon = (function() { function somePrivateFunction() {}; var sinon = { foo: function foo() {} }; return sinon; }()); node の場合、ブラウザの場合、busterjs の場合で異なった初期化を行う。 node の環境かどうかの判定は module.exports の有無で行う。 var
paulirish/browser-logos · GitHub バグを見つける 表示系のものならスクリーンショットをとっておく すでに報告されていないか調べる ブラウザごとのバグトラッカーで検索してみる サポートフォーラムなどコミュニティに相談してみる ブラウザの種類とバージョンの絞込み 他のブラウザでは発生するか. 他のバージョンでも発生するか (stable を使っているなら beta や nightly でも見てみる等) テストケースの最小化 バグを再現させる最小のテストケースを作ります 今回出会ったのは表示系のバグだったので, html / css を削りながら現象を再現させていき, 同じ現象が起こる最小の html を作りました バグの報告先とフォーマットの確認 ブラウザごとにバグ報告のガイドラインがあるはずなので, それを読めばどのように報告すればよいかわかるはずです chr
var img = new Image(); img.onload = function() { // event handler }; img.src = 'http://example.com/foo.png'; document.body.appendChild(img); こういうふうに動的に画像をロードして、かつ onload のイベントを取りたい場合。三行目で src 属性に url を設定した時点で即座に非同期のリクエストが飛ぶ。画像のリクエストが完了する前に次の行へ処理が移る。よって src 属性に値をセットする前にイベントリスナの設定をしなくてはいけない。 というのも、たぶん src の挙動をちゃんと理解していなくて、以下のようなコードをサンプルとしてあげているブログなどを複数目にしたので気になったという経緯。 var img = new Image(); img.src
w/--write-out というオプションがあり、いろいろと細かい情報をフォーマットして出力できる。たとえばこうするとレスポンスタイムだけを出力できる。 curl -kL 'https://example.com/' -o /dev/null -w "%{time_total}" 2> /dev/null レスポンスのステータスコードも出したい場合は curl -kL 'https://example.com/' -o /dev/null -w "%{http_code}\t%{time_total}" 2> /dev/null たとえばこれをログにだしておいたり、growthforecast などに投げ込んでおくと、エンドポイントの簡易的な計測に使えそうだ。 ほかにも色々なオプションがあるので man を参照。 参考 curlのオプション勉強したのでまとめ - うまい棒blog
GitHub pull request builder plugin - Jenkins - Jenkins Wiki GitHub pull request builder plugin を使うと、 プルリクエストを自動でマージしてテスト 結果を GitHub の Status API で通知 プルリクエストにコメントしてテストをリトライ などということができる。 設定手順 設定手順は他のシンプルなプラグインに比べてちょっと複雑。 ボットユーザの作成 事前にボット用のユーザーを作成して、対象のリポジトリのコラボレーターとして登録しておく。このボットユーザーがプルリクにコメントしたりするので、アイコンをそれっぽくしておくと楽しい。 全体の設定 プラグイン全体の設定をする。ここの設定がデフォルトとなり、プロジェクトごとに上書きして使う。 Jenkinsの管理 -> システムの設定 -> Gi
C10K とか, Web サーバ (あるいは Node.js みたいなフレームワーク) とか, Web システムのパフォーマンスとかを議論するときには, いかに並列処理するか (スレッドとか) と いかに IO をうまくハンドリングするか (multiplexing とかノンブロッキング・非同期とか) の知識が共通で必要になる気がするのでここを抑えておきたい. ここからイベントドリブン (libev とか) -> 実際のサーバやフレームワーク・ライブラリの実装 という風に進んでいけばいい気がする 結論 これを読むのが一番近道感がある. UNIXネットワークプログラミング〈Vol.1〉ネットワークAPI:ソケットとXTI - W.Richard Stevens Process & Thread どちらも処理の並行実施の単位 プロセスを復習すると 処理の実行単位 メモリを個別に持つ 1 つ以上
ActiveRecord がデータベースとの接続をどう管理しているのかを調べたメモ。主に active_record/connection_adapters 以下の話。現時点での main ブランチの HEAD を参照した。 詰まったときに調べる箇所のあたりを付けられるよう全体観を持ちたいという目的だったので、細かい部分まで把握しきれていはおらず、ご了承ください。 ActiveRecord の使い方のおさらい まず最初にユーザーとして、ActiveRecord でデータベースにクエリを発行する際の流れを簡単におさらいする。 まずデータベースの接続情報を database.yml に記載する。ここではメインとなる primay DB と animals DB の 2 つがあり、またそれぞれに primary (master) と replica があるとする (この例は Active Rec
スラッシュを考慮したマッチを行っているものを RFC 6265 準拠と呼んでいる。詳細は後述 単純に前方一致でマッチしているものをネットスケープの仕様に準拠と呼んでいる 仕様 そもそも Cookie は仕様からして揺れている。現在ある文章は以下の 4 つ。 Client Side State - HTTP Cookies Netscape が定めた文章。現在ではもとのリソースはなくなっており、第三者によってアーカイブされているものしかない。古いがものによっては依然デファクト。 RFC 2109 - HTTP State Management Mechanism Obsolated かつ Historical。1997 の文章。 RFC 2965 - HTTP State Management Mechanism Obsolated かつ Historical。2000 年の文章。Cooki
このとおりにやる gitolite 導入 - Please Sleep まず gitolite の gl-system-install が通らない. File::Path の make_path が無いと言われる. 調べると perl のバージョンがすごく古い cou929:kosei% perl -v This is perl, v5.8.8 built for x86_64-linux-thread-multi cou929:kosei% perl -MFile::Path -le 'print $File::Path::VERSION' 1.08 少なくともこのバージョンの File::Path には make_path は無いようだ ちょっとぐぐってみたけど手軽にシステム perl のバージョンをあげる方法はなさそう. yum のリポジトリ追加していけないかなと思ったけど, 少なく
iOS7 の Safari にて。サードパーティドメインの iframe 内で、そのドメインの localStorage にデータを保存しても、Safari の再起動でそのデータが削除されているようにみえる。Safari の再起動とは、ホームボタンをダブルタップしてアプリのプロセスを殺して再起動するという作業だ。タブを開閉したり、プロセスは継続したままたホームボタンを一回タップして終了・起動を繰り返した場合は当然データが保持されている。よってセッションストレージよりはデータの寿命が長いが、しかしプロセスの終了とともにデータが揮発するという、よくわからない現象だ。 サンプルが少ないので確かではないが、以下の条件で発生するようだった。 iOS 7.0.2、7.0.4 で発生した iOS7 未満では発生しなかった ハードのバージョンは iPhone4S、iPhone5 で発生した iPhone5
BrowserStack にてそれぞれデフォルト設定のブラウザで調査。IE 中心に調べたので他のブラウザは網羅的ではない。あとから補完して別途公開したい。 サマリー 最も一般的な挙動は、追加日時 (おそらく最終更新日時) が古いものを一件削除し、新しいクッキーを受け入れるという、LRU 的なアルゴリズム。ここからブラウザやバージョンによってバリエーションがある。 Chrome は一件ではなく一度に三十件削除する その代わり受け入れるクッキー数は多め バックエンドを Chromium (Blink) に切り替えてからの Opera も同様 古い Opera は、追加しようとしたクッキーを受け入れ、その次に新しいもの一件を削除する。 Safari は単に追加順ではなく独自のソート順でクッキーを管理。その降順または昇順で一件を削除する。 バージョンによって動きがばらばらなので、詳しく調査したい。
PhantomJS: Download and Install ここにバイナリがおいてあるのでダウンロードして展開してパスを通すだけで大丈夫。qt とか webkit をインストールする必要すらなくて超簡単。 古いシステムなどでソースから入れたい場合は PhantomJS: Build Instructions に従う。以下のステップだけでいいらしい sudo yum install gcc gcc-c++ make git openssl-devel freetype-devel fontconfig-devel git clone git://github.com/ariya/phantomjs.git cd phantomjs git checkout 1.9 ./build.sh ソースから入れる場合も同様に qt などは必要なくて、build.sh を叩くだけでいいそうだ。簡単。
アカウントをつくる heroku toolbelt をインストールする インストール後 heroku コマンドが使えるようになる $ heroku --version heroku-toolbelt/3.2.1 (x86_64-darwin10.8.0) ruby/1.9.3 sinatra のアプリを書く Gemfile を準備する。モジュールをインストールする $ cat Gemfile source 'https://rubygems.org' gem 'sinatra' $ bundle install --path vendor/bundle vendor、.bundle は gitignore する。Gemfile.lock はバージョン管理する。 プロジェクトのルートに app.rb などを作ってアプリを書く。テンプレートは views 以下におく。今回は erb を使う。
リスティング広告のオークションがどういうふうなメカニズムになっているのか調べた。各社のヘルプページと、基礎となっている論文があったので読んだメモ。 BIng Ads Auction Explained Bing Ads Auction Explained: How Bid, Cost-per-Click and Quality Score Work Together QS (Quality Score) 広告のスコア。キーワード相関性などで決まる。ただし Bid 金額は QS に影響しない。 Ad Rank 最終的な表示順。Ad Rank の降順になる。 Ad Rank = Bid * QS CPC 実績値ではなく、クリック時に請求される課金額 CPC = Bid * Competitor’s Ad Rank / Your Ad Rank Bid 額よりは下がる Competitor’s
面倒くさいけど一番確実なのは iPhone 構成ユーティリティで確認する方法だと思う。 アップル - サポート - ダウンロード こちらからダウンロードし起動 iPhone を接続 左カラムの LIBRARY -> Devices から接続したデバイスを選択 上部にある Export ボタンでデバイス情報を出力 これでデバイス情報の XML ファイルが出力される。この中からなんとかみたいアプリの情報を探さなければならない。 CFBundleDisplayName という要素にデバイスで表示されるアプリ名が入る。 <key>CFBundleDisplayName</key> <string>FooApp</string> CFBundleURLSchemes にそのアプリの URL スキームが入る <key>CFBundleURLSchemes</key> <array> <string>f
which を使う 最初に思いついた方法. if [ `which SOME_COMMAND` ]; then echo 'found' fi # 一行で which SOME_COMMAND > /dev/null 2>&1 && echo 'found' type を使う OSに付属するシェルスクリプトを読んで技術を盗む(1/2) - @IT で紹介されていた方法. コマンドは違うが考え方は上記と同じ. if type logger > /dev/null 2>&1; then LOGGER="logger -s -p user.notice -t dhclient" else LOGGER=echo fi command -v を使う rvm がこういうふうにやっていた. なぜ builtin command というふうにわざわざやっているのかがよくわからない. command って
ジェイクエリーすぐ忘れる DOM エレメント -> jQuery オブジェクト $() 関数に入れてあげれば OK var sample = document.querySelector('#sample'); var jq_obj = $(sample); jQuery オブジェクト -> DOM エレメント jQuery オブジェクトのインデックス 0 らしい var dom_element = jq_obj[0]; 検証 var body = document.querySelector('body'); var jq_obj = $(body); var dom_elm = jq_obj[0]; body === dom_elm // true
次のページ
このページを最初にブックマークしてみませんか?
『Please Sleep』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く