Sarabande.jp

Channel Description:

Latest Articles in this Channel:

12/16/11--06:39: gondaba.com: Color Shades Theme Released! (chan 2647842)

gondaba.com: Color Shades Theme Released!:

Hey! You like how gondaba.com looks? Yeah, me too!

Well, now y’all can use the theme too! I’ve just submitted it to the theme garden, and it’s been accepted!

Just hit Customize, then Theme at the top. Then find mine, and click save! You’re all set.

Customization Hints

• In Customize, hit…




12/16/11--06:46: コードの練習記録のために別の Tumblr ブログを用意 (chan 2647842)

12月17日追記2: 練習記録を学習記録に変更しました。 12月17日追記: 画面上側のナビゲーションにリンク(「練習記録」)を追加しました。

当初はこのブログをコードの練習記録のために使っていましたが、 プログラマではない方のフォローや、リブログ、日記や翻訳などプログラムコード以外のネタが増えてきたので、別の Tumblr ブログを用意することにしました。

http://exercise.sarabande.jp/






12/16/11--15:24: 11の「やめたこと」で実現した1000万ダウンロード突破【スマホ2011冬】 - デジタル - 日経トレンディネット (chan 2647842)

11の「やめたこと」で実現した1000万ダウンロード突破【スマホ2011冬】 - デジタル - 日経トレンディネット:

paul-yamamoto:

1.「組織の細分化、階層化をやめる」 マネジャーが増えるということは、ゲームの作り手が一人減るということ。優秀な人間がマネジャーになるほど、アプリの制作力は低下する。

2.「職種別の目標設定をやめる」 プログラマー、企画など職種別に目標を設定すると、自分の担当部分しか見なくなる。評価はまずそのアプリの完成度に注目。その中で自分がどれだけ貢献したかというポイントに変更した。

3.「作業量の見積もりをやめる」 作業する本人が3日間徹夜で仕上げるつもりでも、上司はバッファを見て一週間と報告してくることが多い。どんどん仕事を依頼し、本人が「ここが限界」と自己申告すれば、そこまでにする「ギブアップ申告制」に変更。

4.「スケジュール管理をやめる」 スケジュールありきだと、だれもがクオリティーよりスケジュールを優先してしまう。スケジュール表をまとめただけで仕事をした気になってしまうのも問題。

5.「データ分析をやめる」 過去のデータを分析しても新しいアプリは生まれない。消去法でアプリを作成すると、センスのある人間の意見がつぶされてしまう。

6.「お客様のご意見どおりのアプリ変更はやめる」 お客様のご意見は、あくまでもアプリに問題があるかどうかのバロメーターとする。

7.「メンバーの教育はやめる」 優秀な人間を教育担当にするほどチームの制作力は低下する。

8.「承認はやめる」 「○○さんがいいと言ったので」という甘えを断ち切る。常に危機感のある状況にする。

9.「アドバイス／助け合いはやめる」 分かっていない人間に理解させるより、分かっている人間が作業したほうが早い。問題点は「ここがよくない」とストレートに事実だけを伝える。

10.「会議をやめる」 時間の無駄。制作チーム同士の席を近くするだけで問題ない。

11.「報告書をやめる」 自分自身がプロジェクトの進行具合を知りたい担当者のところに、知りたいタイミングで歩いていけばいいだけ。

「これ本当かな？」って疑いたくなるぐらい凄い！
こんなチーム作りたい！！こんな働き方がしたい！！！




12/16/11--16:48: npm でインストールされたパッケージの情報を調べるには？ (chan 2647842)

npm view コマンドを使う。コントリビュータの名前がずらりと表示されるので、それぞれの人が何を開発しているのか調べることで新しいツールを見つけることができるかもしれない。jsdom の場合、 RESTful Web Services と Agile Web Development with Rails の著者の1人である Sam Ruby の名前も入っていた。

npm view jsdom

{ name: 'jsdom',
  description: 'A javascript implementation of the W3C DOM',
  'dist-tags': { latest: '0.2.10' },
  versions: 
   [ '0.0.1',
     '0.1.2',
     '0.1.4',
     '0.1.5',
     '0.1.6',
     '0.1.7',
     '0.1.8',
     '0.1.9',
     '0.1.10',
     '0.1.11',
     '0.1.12',
     '0.1.13',
     '0.1.15',
     '0.1.16',
     '0.1.17',
     '0.1.18',
     '0.1.19',
     '0.1.20',
     '0.1.21',
     '0.1.22',
     '0.1.23',
     '0.2.0',
     '0.2.1',
     '0.2.2',
     '0.2.3',
     '0.2.4',
     '0.2.5',
     '0.2.6',
     '0.2.7',
     '0.2.8',
     '0.2.9',
     '0.2.10' ],
  maintainers: 'tmpvar ',
  time: 
   { '0.0.1': '2011-11-21T03:09:05.477Z',
     '0.1.2': '2011-11-21T03:09:53.766Z',
     '0.1.4': '2011-11-21T03:10:38.441Z',
     '0.1.5': '2011-11-21T03:11:18.142Z',
     '0.1.6': '2011-11-21T03:11:57.872Z',
     '0.1.7': '2011-11-21T03:12:37.152Z',
     '0.1.8': '2011-11-21T03:13:15.555Z',
     '0.1.9': '2011-11-21T03:13:55.435Z',
     '0.1.10': '2011-11-21T03:14:37.965Z',
     '0.1.11': '2011-11-21T03:15:12.565Z',
     '0.1.12': '2011-11-21T03:15:46.441Z',
     '0.1.13': '2011-11-21T03:16:22.598Z',
     '0.1.15': '2011-11-21T03:16:57.935Z',
     '0.1.16': '2011-11-21T03:17:31.089Z',
     '0.1.17': '2011-11-21T03:18:04.410Z',
     '0.1.18': '2011-11-21T03:18:37.311Z',
     '0.1.19': '2011-11-21T03:19:10.313Z',
     '0.1.20': '2011-11-21T03:19:43.587Z',
     '0.1.21': '2011-11-21T03:20:17.251Z',
     '0.1.22': '2011-11-21T03:20:51.248Z',
     '0.1.23': '2011-11-21T03:21:28.854Z',
     '0.2.0': '2011-11-21T03:22:02.086Z',
     '0.2.1': '2011-11-21T03:22:20.006Z',
     '0.2.2': '2011-11-21T03:22:39.637Z',
     '0.2.3': '2011-11-21T03:23:02.172Z',
     '0.2.4': '2011-11-21T03:23:25.921Z',
     '0.2.5': '2011-11-21T03:27:21.095Z',
     '0.2.6': '2011-11-21T03:27:44.349Z',
     '0.2.7': '2011-11-21T03:28:04.973Z',
     '0.2.8': '2011-11-21T03:28:25.916Z',
     '0.2.9': '2011-11-21T03:28:47.572Z',
     '0.2.10': '2011-11-21T03:29:08.202Z' },
  version: '0.2.10',
  keywords: [ 'dom', 'w3c', 'javascript' ],
  contributors: 
   [ 'Vincent Greene ',
     'Dav Glass ',
     'Felix Gnass ',
     'Charlie Robbins ',
     'Aria Stewart ',
     'Matthew  (http://github.com/matthewpflueger/)',
     'Olivier El Mekki  (http://blog.olivier-elmekki.com/)',
     'Shimon Dookdin ',
     'Daniel Cassidy  (http://www.danielcassidy.me.uk/)',
     'Sam Ruby  (http://intertwingly.net/blog/)',
     'hij1nx (http://github.com/hij1nx)',
     'Yonathan Randolph (http://github.com/yonran)',
     'Martin Davis (http://github.com/waslogic)',
     'Andreas Lind Petersen ',
     'd-ash (http://github.com/d-ash)',
     'Robin Zhong ',
     'Alexander Flatter ',
     'Heng Liu ',
     'Brian McDaniel (http://github.com/brianmcd)',
     'John Hurliman ',
     'Jimmy Mabey',
     'Gregory Tomlinson',
     'Jason Davies (http://www.jasondavies.com/)',
     'Josh Marshall (http://www.ponderingtheobvious.com/)',
     'Jason Priestley (https://github.com/jhp)',
     'Derek Lindahl (https://github.com/dlindahl)',
     'Chris Roebuck  (http://www.quillu.com)' ],
  bugs: 
   { email: 'tmpvar@gmail.com',
     url: 'http://github.com/tmpvar/jsdom/issues' },
  licenses: 
   { type: 'MIT',
     url: 'http://github.com/tmpvar/jsdom/blob/master/LICENSE.txt' },
  repositories: 
   { type: 'git',
     url: 'http://github.com/tmpvar/jsdom.git' },
  implements: 'http://www.w3.org/TR/REC-DOM-Level-1',
  dependencies: 
   { htmlparser: '1.x',
     request: '2.x',
     cssom: '0.2.x',
     contextify: '0.0.x' },
  devDependencies: 
   { nodeunit: '>=0.5.x',
     'console.log': '*',
     optimist: '*' },
  engines: { node: '>=0.1.9' },
  directories: { lib: './lib/jsdom' },
  main: './lib/jsdom',
  dist: 
   { shasum: '445e36549318aea97f6cc59985cd1e2fc885537f',
     tarball: 'http://registry.npmjs.org/jsdom/-/jsdom-0.2.10.tgz' } }




12/16/11--22:06: "より高頻度にバグを修正し、かつ最近になって集中的に直しているほど、スコアが大きくなります。そしてスコアが大きいほど、相対的に見てそのコードにはバグがある可能性が高い、というのがこのアルゴリズムが示すとこ..." (chan 2647842)

“より高頻度にバグを修正し、かつ最近になって集中的に直しているほど、スコアが大きくなります。そしてスコアが大きいほど、相対的に見てそのコードにはバグがある可能性が高い、というのがこのアルゴリズムが示すところです。”

- グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している － Publickey


12/17/11--10:15: diary - rumblefish: 絵描き５年病 (chan 2647842)

diary - rumblefish: 絵描き５年病:

q-orbit-diary:

５年病の症状：

• 新しい概念や手法を吸収しなくなる。
• 何をやっても大して効果はないと思い始める。
• かといって、目標に向かって寸暇を惜しむ体でもない。
• pixivは欠かさず眺めて、それっぽいことをツイートするのが趣味になる。
• 「自分は絵描きだから～」というのを思考の枠にしてしまう。
• 手を動かすことを惜しみ始める。
• 「多分できる」と「できた」を混同する。
• 一度失敗しただけでスネてやらなくなる。
• 自分よりキャリアの無い人にエラそうな口を利きたがる。
• 不摂生と運動不足で体が劣化する。

出典はこちら 「エンジニア5年病」 - それなりブログ




12/17/11--12:04: "人々を自己信頼から遠ざけているもうひとつの恐怖は、一貫性である。（中略）　仮に矛盾したとして、それがなんだろう。記憶だけに頼らないこと、たとえ記憶がはっきりしているときでも、なるべく頼らないようにするこ..." (chan 2647842)

“人々を自己信頼から遠ざけているもうひとつの恐怖は、一貫性である。（中略）　仮に矛盾したとして、それがなんだろう。記憶だけに頼らないこと、たとえ記憶がはっきりしているときでも、なるべく頼らないようにすること、常に現在の視点から過去を徹底的に検証し、日々新しい一日を生きること、それこそが賢明な態度だと思われる。”

- Amazon.co.jp： 自己信頼[新訳]: ラルフ・ウォルドー・エマソン, 伊東奈美子: 本


12/17/11--12:08: "愚かな一貫性は小人物に憑いたおばけである Guido の重要な洞察のひとつは、コードは書かれる頻度よりも、読まれる頻 度のほうが高いということだ。ここで提供されるガイドラインは、コードの..." (chan 2647842)

“

愚かな一貫性は小人物に憑いたおばけである

Guido の重要な洞察のひとつは、コードは書かれる頻度よりも、読まれる頻 度のほうが高いということだ。ここで提供されるガイドラインは、コードの 可読性を高め、広範囲の Python コードに一貫させることを、意図されてい る。PEP 20 [6] が述べるとおり可読性は重要である。

スタイルガイドは一貫性に関わるものであり、重要なのは規定される一貫性 である。プロジェクト内の一貫性は、もっと重要である。モジュールや関数 内部での一貫性は、更に重要である。

しかし、一番重要なことは、いつ一貫性を破るかを知っておくことだ。スタ イルガイドが適用できないことだってある。疑わしいときには、自分自身で 最良の判断をすること。前例を見て、最も見栄えがいい方法を判断しなけれ ばならない。それから、尋ねることをためらってはいけない。 特定のルールを破る妥当な理由には、次のようなものがある。

(1) ルールを適用すると、ソースコードが読みにくくなる。そのルールに沿っ て書かれたソースコードを読むのに慣れている人にとっても、読みにく くなる。

(2) (歴史的な事情などによって）ルールを破っている既存のソースコード に囲まれている。— もっとも、この場合は（真の XP に則って）他人 の汚いソースコードを、きれいにする機会でもあるけれど。

”

- PEP 8 — Style Guide for Python Code


12/17/11--12:12: "根本的な帰属の誤り（こんぽんてきなきぞくのあやまり、英: Fundamental attribution..." (chan 2647842)

“根本的な帰属の誤り（こんぽんてきなきぞくのあやまり、英: Fundamental attribution error）は、個人の行動を説明するにあたって、気質的または個性的な面を重視しすぎて、状況的な面を軽視しすぎる傾向を言う。対応バイアス（たいおうバイアス、英: Correspondence bias）とも。すなわち、人間は人の行動を根拠なくその人の「種類」によって決定されていると見る傾向があり、社会的かつ状況的な影響を軽視する傾向がある。また、自身の行動については逆の見方をする傾向がある。この矛盾を「行為者-観察者バイアス（Actor-Observer bias）」と呼ぶ。”

- 根本的な帰属の誤り - Wikipedia


12/17/11--12:13: "ヒューリスティック（英: heuristic, 独:..." (chan 2647842)

“ヒューリスティック（英: heuristic, 独: Heuristik[1]）とは、必ず正しい答えが導けるわけではないが、ある程度のレベルで正解に近い解を得ることが出来る方法。答えの精度は保障されないが、回答に至るまでの時間が少なくて済む。主に計算機科学と心理学の世界で使われる語。どちらの分野での用法も根本的な意味は一緒だが、指示対象が違う。計算機科学ではプログラミングの方法を、心理学では人間の思考方法を指して使われる。論理学では仮説形成法と呼ばれている。”

- ヒューリスティクス - Wikipedia


12/17/11--23:49: 「イベントを発火させる」は適切な訳語とは思えない (chan 2647842)

JavaScript において「イベントを発火させる」という表現を出版書籍でも見かける。 おそらくは「fire event」の訳語から来ていると見られるが、「発火させる」＝「火をつける・燃え上がらせる」、「イベントに火をつける」＝「イベントで放火する」もしくは「イベントを煽る」など、別の意味に解釈される可能性がある。

これは fire の意味のあいまいさから来ているものなので、fire という原文にとらわれず、同じように使われるほかの動詞の訳語である「イベントを発生・発動させる」などに置き換えたほうがよいのではないだろうか。




12/18/11--13:34: quote を引用符と訳さなかった理由 (chan 2647842)

日本語の引用付なのか英語の引用付なのか、単一引用付なのか二重引用付のどちらを指すのか区別がつかなくなることから、訳語をクォートにしていた。




12/18/11--16:35: "Kindleが採用しているのはE Inkという電子ペーパーシステムである。凸版印刷のE Ink..." (chan 2647842)

“

Kindleが採用しているのはE Inkという電子ペーパーシステムである。凸版印刷のE Ink 電子ペーパーページの説明がわかりやすいと思われるが、最大の特徴は透過光ではなく反射光であるということだ。

紙の本もそうだが、物体に反射した光が目に入る。これが反射光。一方、テレビやパソコンのモニターはブラウン管や液晶やプラズマディスプレイが光を発している。これが透過光メディアだ。E Inkを使ったキンドルは、電子本デバイスでありながら、透過光ではなく反射光なのである。

反射光と透過光の違いは、実は非常に重大な意味を持っている。その意義について、丸田一『「場所」論―ウェブのリアリズム、地域のロマンチシズム (叢書コムニス08)』が非常にわかりやすくまとめているので、少し長くなるが引用したい（178～179ページ）。ここでは、映画も反射光メディアに含まれている。


　まず、確認したいのが、「透過光」がもたらす「距離埋没効果」である。パソコンのモニター、携帯電話をはじめ、ウェブ空間のインターフェースは、ほとんどが透過光によるスクリーンである。スクリーンにはブラウン管や液晶、有機ＥＬなど様々な映像表示方式が採用されているものの、どれも発光源を持ち、スクリーン表層を透過する光線で画面を表示することに変わりない。透過光による表示は、反射光の表示に比べて現前性が高く、利用者の身体とスクリーンとの間に横たわる十数センチ～数十七ンチという距離を埋めてくれる。


　透過光が強い現前性をもたらすことは、マクルーハンも『メディアの法則』［★125］で指摘している。マクルーハンは、映画の観客を二分して、一方には普通の映画と同じように反射光によって、もう一方には透過光によって同じ映画を鑑賞させるというハーバート・クルーグマンの実験を取り上げている。反射光のグループの感想は、映画を物語や技術に注目して理性的に分析し、批判する傾向が優位を占めたのに対して、透過光のグループでは、好き嫌いという情緒的で、主観的な反応が優位を占めた。

　反射光の映画において観客は、スクリーンと身体との物理的な距離を保ったまま、対象としてスクリーン上を見ている。この距離が映像を対象化し、観客に分析的で批判的な見方を与える。一方、透過光のテレビでは、スクリーンを越えて到達する光に視聴者が深く差し込まれてしまうので、映像は実際のスクリーン面から離れて、観客の目や身体を擬似的なスクリーンにして現前する［★126］。このように透過光の場合、観客は対象とうまく距離をとれず、場合によっては対象と位置的に重なってしまうことが、観客に情緒的、主観的な見方を与えるといえるだろう。

　ところで、パソコンのスクリーンを眺めていても発見できない誤字脱字が、プリントアウトすると容易に見つかるという経験は、誰もが一度はあるのではないだろうか。これも「反射光と透過光」である程度説明ができる。スクリーンの透過光で文字を読んでいても見逃しがちな誤字脱字は、プリントアウトした紙の反射光で読むと、対象を分析的、批判的に捉えることができるので、より発見されやすいといえる［★127］。

　このように現前性の強い透過光が、ウェブ空間のインターフェースに用いられているのは偶然ではないだろう。現前性の高い透過光は、スクリーンと利用者の身体との。間にある物理的な距離を埋没させ、スクリーンを没対象化させてしまう。これがスクリーンというインターフェースを準没入型に変えるのである。

”

- Amazon Kindle（アマゾン・キンドル）：「反射光の電子ブック」という革命的に新しいメディア - 絵文録ことのは - BLOGOS（ブロゴス） - livedoor ニュース (via yaruo) (via fatherion) (via 778) (via pedalfar) (via wiggling) (via tessar) (via nanospectives) (via takaoka) (via less-is-more) (via shigesa) (via plasticdreams) (via yaruo) (via motomocomo) (via f-o-pekoe)


12/18/11--18:42: 愚かな一貫性について言及のある書籍 (chan 2647842)

• ラルフ・ウォルド・エマソン　エマソンの論文集「自己信頼」
• 「多様な意見」はなぜ正しいのか　（スコット・ペイジ）
• 愚かしき一貫性は小心もののお化け(1分間リーダーシップ)
• 『影響力の武器』　ロバート・B・チャルディーニ

Guido の PEP 8 ではじめて知った表現だが、おそらくはラルフ・ウォルド・エマソンから来ているようなので、ほかにも引用したり似た表現を使った書籍はないかなと思ったら、以外とあった。




12/20/11--16:46: Doctrine 2.2 beta1 がリリース (chan 2647842)

• http://www.doctrine-project.org/blog/doctrine2-2-beta

改善内容のリストは次のとおり。

• ルールにもとづいてエンティティとアソシエーションをフィルタリングする。フィルタはパラメータ化もしくは有効・無効にすることができる。
• Geometries、IP などの複雑な SQL のサポート
• DQL におけるビット比較
• アノテーションのリファクタリング
• DQL のリファクタリング、ORDER BY と GROUP BY は SELECT 式の結果の変数をサポート
• DQL の結果におけるエンティティのエイリアス
• 単独のエンティティのフラッシュ




12/22/11--07:30: "自分で書いたコードは、働いていた２年半の間、全部メンテしていた。ソフトウェアの開発に最初から最後まで関わるという経験はとても貴重だったんじゃないだろうか。なぜなら、プロジェクト開始時のダメなデザインのし..." (chan 2647842)

“自分で書いたコードは、働いていた２年半の間、全部メンテしていた。ソフトウェアの開発に最初から最後まで関わるという経験はとても貴重だったんじゃないだろうか。なぜなら、プロジェクト開始時のダメなデザインのしっぺ返しを、後で自分でモロに受けるからだ。”

- フェイスブックのエンジニア、Evan Priestleyによる「ぼくはこうしてプログラミングを覚えた」 - モジログ (via dropped-rice-grain)


12/22/11--20:41: "深い理解と説明能力を欠いたまま、既存のパターンを感覚的に寄せ集めるだけでは、説得力のあるデザインを生み出すことはできません。" (chan 2647842)

“深い理解と説明能力を欠いたまま、既存のパターンを感覚的に寄せ集めるだけでは、説得力のあるデザインを生み出すことはできません。”

- 訳書『デザイニング・インターフェース』第2版の出版にあたって « IA Spectrum (via words-silence)


02/11/12--04:24: Bootstrap 2.0 と Google カスタム検索を導入 (chan 2647842)



CSS の勉強を兼ねて、Bootstrap 2.0 を導入しました。Bootstrap は Twitter が配布している HTML テンプレートで、現時点で Github で1万9千人がウォッチしています。

以前のテーマからの変更点は次のとおりです。

1. 横幅を最大限使うようにした
2. スクロールをしても表示され続けるグローバルナビゲーションの導入
3. Google カスタム検索の導入
4. JavaScript の読み込みを最後のほうに移動
5. プログラムコードのハイライト処理を行う google-code-prettify のイベントハンドラ登録を onload 属性から jQuery の ready メソッドに変更

1.のおかげで1つの記事の縦の長さが短くなったので、トップページに表示する記事の件数を10件に増やしました。

2.に関して、画面が小さくなると横に広がった項目が縦方向のドロップダウンに変わります。このように画面の大きさに合わせて変わるデザインはレスポンシブ Web デザインと呼ばれており、スマートフォンの普及とともに注目されるようになりました。

3.に関して、Google カスタム検索の CSS の調整は次のようにしました。最小限の作業としてフォームに置き換わる cse-search-form セレクタの幅を調整する必要があるでしょう。フォームのデフォルトのテーマファイルはdefault.cssです。

#cse-search-form {
  width: 250px;
}
input.gsc-input {
  #background-image: none !important;
  margin-top: 10px;
}
input.gsc-search-button {
  display: none;
}

4.に関して、JavaScript の読み込みは最後にしたほうが速いという Bootstrap の主張に合わせました。 5.に関して load イベントよりも jQuery の ready メソッドを通じて登録したほうが、速く表示されます。ついでに以前書いた google-code-prettifyの記事を更新しました。google-code-prettify は Bootstrap のマニュアルにおいても使われています。




02/11/12--20:06: Tumblr の記事に Gist のコードを埋め込む (chan 2647842)

2012年2月14日追記: Tumblr に埋め込んだ Gist の CSS の値を修正する

Tumblr でプログラムコードを掲載する問題はテキストエディタの置換機能を使って < を < に置き換える作業が必要であることと、特に HTML が混在している場合にエスケープ処理を施したコードは見づらくなることです。

コードの保存場所を Gist に移行すれば上記の問題が解決されるだけでなく、ほかのブログで同じコードの再利用をすることができます。

プログラムコードは時折改善されるので、もしコピー＆ペースト方式だと、掲載しているブログの数だけ修正しなければなりません。

Markdown 形式の記事を書いている場合 タグが無視されてしまう Tumblr 側の処理を回避する必要があります。

調べると、writeCapture を使った Ajax による読み込みで Tumblr の制限を回避している記事を見つけました。導入方法は掲載されている Gist の JavaScript コードをそのまま Tumblr のテーマにコピー＆ペーストするだけです。




02/13/12--08:50: Tumblr に埋め込んだ Gist にカスタム CSS を適用する (chan 2647842)



適用するカスタム CSS の優先順位を上げるために次のように書きました。

• HTML の style 属性に記述する
• 子孫セレクタの記述において div#content を追加
• オリジナルの CSS に対応する !important を追記

おそらくはブラウザのキャッシュが原因であるために、Tumblr のテーマを保存しても修正内容が反映されないことが何度かあり、そのたびにブラウザのキャッシュを削除しました。