おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、アプリの認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げます。さらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。

セキュアでないトークン

トークンベースの認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなものを設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分のプラットフォームも自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースのフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。

トークンベースのシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的なスクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。

もし生成されるトークンが予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまいます。筆者は、fortune 500 クラスの大企業による OAuth ベースなサービスが一種の単調増加 ID (おそらくデータベースのフィールド？) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在のトークン ID を見て、その後の ID を予測すれば、続く任意のユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。

このクラスの攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意の OAuth ベースなサービスが外部レビューでセキュリティを証明してもらえる可能性はあまり高くありません。

本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースのサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通の OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通の実装における」OAuth がよくやる使い方ではサーバの信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。

一方、一部の OAuth ベースの実装は乱数の必要性をクライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者な利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者は脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険を回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。

クロス サイト・リクエスト・フォージェリ (CSRF)

本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクをユーザが貼れる、掲示板やメッセージングソフトのようなサイト自体からでもスタート可能なのです。

色々な手法で CSRF に立ち向かうべく設計された数々のテクニックやフレームワークがあります。これらのシステムの多くは、OAuth ベースのものと統合すると使いものにならなくなったり、サイトを攻撃にさらしかねない行為を促すことがあります。

CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装はユーザを特定の外部サイトから連れてくるよう要求しますから、この防御策は執行できません。OAuth サーバがリダイレクトする膨大なサードパーティのドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。

また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要があります。OAuth の背後にある原則のひとつは OAuth ベースのサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています。理想の認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。

転送元と転送先のどちらかだけの、部分的なホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能のオンオフに中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者は CSRF 対策フレームワークを一切使用できなくなります。

OAuth は CSRF 攻撃を防ぐ CSRF トークンを指定するようにと、オプショナルな state パラメータを定義しています。しかしながら、OAuth ベースのサービスは一般的に state の長さや文字種を制限し、要求どおりそのままで返さないことがあるようです。そこで、おかしな互換性問題が起こるため、多くの OAuth ベースサービス利用者はリダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されています。state パラメータの別の懸念は、EVS 側で state にアクセスのある人はだれでも、リクエストを改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。

OAuth ベース API の利用者は、自分のアプリやサービスを登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的に危険の伴うアイディアで姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースなサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効でパラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険なものを state パラメータに詰めこもうとし始めたり、浅薄なシステムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザを不適切なページに誘導する危険性が出てきます。これは「10.15. オープン・リダイレクト」に分類されます。

こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体が悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザに大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報で認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法や改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通の実装における」OAuth の低品質な設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベースの利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています。

ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります。

章のまとめ

セキュリティに関して言えば、「普通の実装における」OAuth の仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースなサービスの中には、種々の攻撃に対して無防備でいることを利用者に公然と要求するものがあります。サービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要なセキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質なプログラミング習慣を招いています。OAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティを提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。

この記事についていえば、個人的に蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所で OAuth に使っているのを見たまま開発者がコピーした結果というものもあります。

OAuth ベースのサービス開発者もその利用者側の開発者も、OAuth ベースのプラットフォームを実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラスの攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装の仕様書やセキュリティ・ガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルのセキュリティを実現することはできません。

真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます。

ユーザビリティ関連

(略: ふつうの実装では、サービス側がプラグを引き抜くようにして自由に利用者を出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)

(略: サービス側からは API 利用者という大きすぎる単位でしか見えないので、たとえばビデオカメラのアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位。対策としてユーザに開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)

(略: ふつうの実装は SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリが cURL 的なもので API を叩こうとしても、JavaScript が必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新がメタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのはセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトやデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。http サーバをlocalhostで立てるとかアホか。)

(略: オープンソースにしづらい)

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認

Permalink | 記事への反応(2) | 14:55

2016-04-24

■http://anond.hatelabo.jp/20160424125740

わかる

匿名という時点で現実と繋がってない無意味な感覚

結局大手メディアが自らの意見の互換品として一部拾い上げる以外で実在しない感じ

ただ見知らぬ奴と意見や相談のやり取りをしたい場合はその限りではないが

Permalink | 記事への反応(0) | 13:10

2016-04-20

■[ゲーム日記]４月２０日

○朝食：なし

○昼食：おにぎり三つ（梅、鳥五目、ツナマヨ）

○夕食：パン二つ（ベーコンマヨ、チーズレタス）、中華丼

○調子

むきゅー！

仕事は適度にこなした。

むきゅむきゅーだんしゅでむきゅっきゅーだなあ。

○ボーダーランズ1

FPSとハクスラ要素を混ぜ合わせた感じのゲーム。

Oneの360 互換機能を使ってプレイしています。

四人の主人公から一人を選ぶみたいで、

オーソドックスな主人公タイプで、タレット設置なども出来るRoland

むきむきのパワータイプで、爆発物も得意なBrick

スナイパータイプで、ペットの鷹とコンビを組むMordecai

紅一点で、絡め手が得意なLilith

って感じの四人。

僕が選んだのは、Brickさん。

僕はポケモンで悪タイプを愛しているぐらいだから「絡め手」が好きなんだけど、このボーダーランズは、

ソロプレイが中心なので、まずゲーム性に慣れるために難しそうな「絡め手」のLilithさんはちょっと辞めておいた。

で、バスから降りて、自分の住処となる場所の安全を確保する感じのミッションをこなした。

といっても、お使いしたり、犬やザコモヒカンを倒した程度なんだけどね。

なんだけど、このゲームメチャクチャ難しいね。

何が難しいって、FPSお馴染みの体力回復はじっとしてればいい、ってシステムじゃないみたいなんだよね。

どうやら、回復アイテムとかをちゃんと買ったりしないといけないみたい。

FPSとハクスラを合わせた感じだとは聞いてたけど、なるほどこれは確かにFPSって感じは薄いね。

レベルを上げて行くと、スキルを選択したりとかの育成要素もあるみたいなので、

色々楽しめそうでうきうきしている。

○ゲームニュース

海外で初代『Max Payne』がPS4向けに移植―バレットタイムが特徴のRemedy出世作

http://www.gamespark.jp/article/2016/04/20/65307.html

ふふふ、ふふふ、ふふふふふふ。

良い作品になるといいですね。

Permalink | 記事への反応(1) | 23:55

2016-03-28

■

http://www.slideshare.net/KenyaKodaira/2016-59970832

なんかたくさんブクマされてますが、読む必要ないと思います。

p.4

HTML Template Engin`d`ってなんですかね。誤字脱字チェックはしましょうね。
gulpのgは小文字なのでよろしくです。

p.5

ん〜非常に大きな枠での話をしてますけど、これから出てくる項目がそれらを解決できるのかなぁと、不安がつのりますね
むしろ「なんでそんなルールを？」という質問が噴出しそうですが！？

p.6

こういうアジェンダの書き方、斬新ですね

p.8

EditorCodingってなに

p.9

コードブロックが見づらいっす。黒バックにblueて誰が読めるのだろうか。若者か。
npm install後に急にgulpって書いてあるけど、それは何をするタスクなのです？
- まぁ、この後gulpタスクについて出てるんでしょう……
  - 出てこなかった

p.10

ちょっとだけ違和感のあるディレクトリ構成

p.15

FixとかAddとかはいいと思うっていうかみんなやってることなんですが、黒括弧はないでしょう。
日本語モードと英語モードを行ったり来たりするのだるいんですよ。
- Fix - about / フッターリンクを修正
- これなら「フッター〜」までを英語モードのまま書ける。

p.16

逆に考えるんだ。Thumbs.dbと.sass-cache/はバージョン管理しちゃっていいさと。

p.18

コードの品質が維持される場合に限り、難読化、最小化、コンパイルするのは自由です

HTMLの話ですよね？　コードの品質が維持されない難読化や最小化やコンパイルってなんだろう。
あとに出てくるけど、CSSには容量削減を異常に求めすぎてるわりには、HTMLには無関心な感じがするんですよね。

p.19

a、span、imgなどの最小の位置にでは開業は適宜対応

その適宜が人によってブレるから、それを潰すのが「フォーマット」だと思うんすよね。
いっそ「新しい要素が出現したら必ず改行する」くらい言ってほしい。
あと日本語が変なんで、それも。

p.20

NGってなってますけど、NGの理由が伝わってこないっすね。
divの閉じタグが不正なのはスペース関わらずNGだよ！

p.21、22

わたしはオッサンなんで、このルールは好きじゃないんですよ。
//で始まってると、ルート相対パスと見間違えちゃうんだよね。
それに、ソースファイル上ではそのHTMLがhttpsかどうかがわからないじゃないですか。
自身のドキュメントのスキーマに準じたURIの解決に頼るのは、メンテナンス性があるとは思わないんですよね。
Googleが言ってたら正しいと思わない方がいいっすよ。あいつらは自分たちのことしか考えてないっすからね。
- ブコメでGoogleのコーディング規約の批判はGoogleに向けろって言ってる人いました。
- 大事なのは選ぶことだそうですが、スキーマの省略は選ぶべき項目だとは思いません。
- なのでわたしはそれを選んだことに苦言を呈します。

p.23、24

.editorconfigにどう書けばいいかをだな……。

p.25

HTMLのルールだとしたら、そういう開発の都合のコメントを残して納品するのはお行儀が良くないっすね。
Jadeを使う前提のようだし、Jadeコメントでの話をしてるなら別にいいんすけどね。
でもさっきからJadeのサンプルが全く出てこないからオッサン不安になってきちゃったっす。

p.26

正しいHTML

HTMLの正しさとは？
参考リンクから察するに、invalidでなければいいと思ってるなんてことはないっすよね。

p.27、28

default.cssの中身がどうなってるか知らないけど、link[rel="stylesheet"]は「そうするほか解決できない」という理由がない限り、htmlのhead要素内に書きましょうね。
あと、CSS ファイルを外部化しただけで「プレゼンテーション（スタイル）と振る舞い（スクリプト）は、ストラクチャ（マークアップ）から分離する」ことができるわけじゃないので、それも忘れずによろしくです。

p.29、30

こういうのは、文字参照で記述しなければならない記号を規定して列挙しときましょうね。

p.31

アクシビリティー（笑）さっきから誤字脱字が多いんだが。

p.32

えっとえっと……「スプレッドシートのスクショです」って説明されて、ユーザーに何がわかりますか？
「このスプレッドシートでは、年を行に、月を列した2010年から 2015年までのアクセス数の分布が表でまとめられている」くらいのコンテキストを入れていきませんか。
気遣いではなくウェブサイト製作者の責任として。
ちなみにalt属性のテキストは、コンテンツマネージャーが考えるべき範囲だと思ってます。

p.36、37

クォーテーションとかはさ、lint設定を開発に組み込む方法を紹介すべきじゃないですかね。
gulpに普通にありますよ。 https://www.npmjs.com/package/gulp-htmlhint
あと、容量の削減とかいうなら、空要素のスペースとスラッシュのことも、書いて欲しかったっす。
正直、開発ソースの容量を削減するのは無意味だと思いますけどね。

p.40

CSSの教科書

いやいや、CSS”設計の”教科書ですからね、その本。
脱字なのかな！？

p.42、43

その命名だとまだ粒度が大きくて、何を示しているのかわからないと思うのはわたしだけでしょうか。
それでどのコンポーネントなのか特定できる程度の規模のサイトなら、CSS 設計いらないんじゃないですかね。

p.44、45

セレクタの単語は、むしろ絶対に省略させないようにした方がいいと思うんですよね。
省略していいなら、省略のルールまで決めていきましょう。
教えてgooに非常にいいページがありますよ。 http://oshiete.goo.ne.jp/qa/341377.html

p.49、50

ステートの上書きまでショートハンドでまとめて書くなんてことはしませんよね？さすがに。

p.57、58

HEXの短縮は規定しなくていいと思います。
ビルドをかける前に勝手に置換されるような仕組みを入れるべきところかと。
gulpでできますし、ググれば出てきます。
ちなみに、#f00よりもredの方が1バイト少ないんですよ。
容量削減は人が思いつきでやるには不十分なのです。
そんなのはビルド時に機械がやればいい。
容量の削減を理由に人の行為に制限をかけるのが愚かな行為だと気付いてくれたらうれしいっす。

p.61、62

もしかして勘違いしているんじゃないかと思ったんですが、「プロパティの終端」は、「宣言」の終端ではないですよ、一応。

p.63、64

と思ったら宣言のことを「プロパティ名」ってさ。どういうことです。

p.71

TODOでコメント書くのって、一時的なメモというか、あとでリファクタリングする前提のコメントだと思ってました。
だから、TODOで「何のためのものなのか誰が入れたのか」書かれててもどうしようもないような。

p.72、73

FLOCSSとMindBEMdingを共存させるなら、書くべきことが足りなすぎませんか。

p.73

block__element__elementは使用しない

冗長になるからやめようって思ってるなら、やめるのはいいけど、そもそもB__E__EはBEMじゃないってことを忘れないでほしいっすね。
https://en.bem.info/faq/#why-does-bem-not-recommend-using-elements-within-elements-block__elem1__elem2
「冗長になるから」じゃなくて「BEMじゃないから」やめろ、です。

p.78、79

打ち消しを減らすのは悪いことじゃないっすね。
でも、追加的なスタイルの宣言をモディファイアの仕事にさせるのは、なかなか危ないと思うんですよね。
決まったルールもなく大量にモディファイアが増えたCSSはコンポーネント管理されていると言えるんでしょうか。
再利用性？　必要になったら作り直す方が早いと思いませんか？
設計してても作り直すことになると思いますけどね。
あなたはそのプロジェクトのコンポーネントがどうスケールしていくかなんて、予測できているんですか？

p.80、81

言ってることは概ね正しいっす。でもサンプルのCSSにタイプセレクタが入っているのはツメが甘いとしか。

p.87

日本語校正を。

GoogleChromeなら変換時に右側に△マーク〜

それGoogle 日本語入力のことかな〜それともChromeにそういう機能があるのかな〜

p.96

この手の分類で上手くいくというのは幻想。試しに次の画像のファイル名を考えてみてください。
「ボタンを示すアイコンで、テキストが含まれていて、背景で使うことが想定されるもの」

コンポーネント単位で使う画像ファイルと、ページ単位で使う画像ファイルがあるのが変なんですよね。
- 管理区分が横断しているというか。
- 画像もすべてコンポーネント単位で管理すればいいわけなんですが。
  - でもあなたはきっと、同じファイルを別名で複数持っておくことを許してくれなそうだ。

p.98

※svgにすることで1つの画像でまかなえる場合はsvgを使用する

言っている意味がよくわからないです。
インライン SVGを使用してfillプロパティーなどで色のバリエーションを管理するってことでしょうか。だったらsvg ファイルとしては保持されないですが。
もしくはSVG スプライト？　スプライトならpngでよくないですか？　なんでわざわざsvg？
急にsvgが出て来て混乱しちゃう！

p.102

ここまで4回くらい読みなおしたんですけが、どうにも上澄みだけの理解しかしてないように感じるんですよね。
Jadeについては何かルールは設けないのでしょうか。
JavaScriptについては……？

そのほかにも、ライティング自体が下手すぎて、これを人に見せるのはどうなのっていう感じがしちゃいました。
誤字脱字くらいはちゃんとチェックしたほうがいいでしょうね。

ルールを設けるのは悪いことではないですが、穴があってはいけません。
- あいまいな基準や不足だらけのルールに、誰が期待できるでしょうか。
エビデンスの弱さも気になります。
コーディングルールの半分くらいはnodeプラグイン互換のlintツールでチェック可能です。

結論：いろいろ惜しいけど、よくなる余地はたくさんあるので、がんばってください。

Permalink | 記事への反応(0) | 11:26

2016-03-18

■http://anond.hatelabo.jp/20160318122914

それを許可した途端うまく動かないシステムが大量発生するおそれがあるから

互換性の乏しい選択肢が乱立するよりもありがたいわ

Permalink | 記事への反応(0) | 12:59

2016-03-12

■プログレッシブ最高じゃねえかNHK 死ね

元日本マイクロソフトの古川享さんブログより。このブログかなり前から消えてるんだけど、復活の目処は無いのだろうか

放送・通信の在り方に関する、私見その９

http://furukawablog.spaces.live.com/blog/cns!156823E649BD3714!4256.entry

https://web.archive.org/web/20061105065656/http://furukawablog.spaces.live.com/blog/cns!156823E649BD3714!4256.entry

さて、この話をいつかはちゃんと記述しておかねばと常々思っていたのですが、それに取り掛かろうと思うと胸の古傷が疼くというか、平常心を保って書こうと思ってもキーボードを叩く手に自然と汗が滲んでくるのです。しっかり深呼吸をして、書きます。（またまた長文にて、失礼）

まず、1999年 5月24日発表の郵政省資料「地上デジタルＴＶ放送方式について電気通信技術審議会から答申」に記述のある以下の文章をご査読ください；

「また、昨年９月の暫定方式や既に答申がなされているＢＳデジタル放送方式、ＣＳデジタル放送方式の技術的条件において、実証実験を必要とする映像の表示方法とされていた720p（有効走査線数720本の順次走査による映像表示方法）について実験を行った結果、その性能が確認されたこと等が併せて報告されました。　この中で、720pは技術的にＨＤＴＶ放送と位置付けることが可能である、と結論付けられています。」（同上答申より引用）

関連記事は、日経産業新聞(1999年 5月25日 PP.3)、日本経済新聞(1999年 5月25日 PP.11)、電波新聞(1999年 5月26日 PP.2)などにも掲載されています。

以下は、そこに至るまでの「血と汗と涙のお話」であります。

今となっては、720pや1080pのプログレッシブ方式はプラズマや液晶テレビとの親和性、映画やCGなどの映像制作に有利なバリアブル・ピッチによる撮影、パソコンによる編集や再生環境においてその優位性を疑う人は居ないと思うのですが...1998年からこの1999年 5月24日までの間、この720pを日本の放送業界から抹殺しようとする「ありとあらゆる活動を展開した集団」がおり、その軋轢の中で多くの人が傷付き市場から去ることになったのでした。

私個人の主張、そしてマイクロソフトの立場は、1080iと720pどちらが良いか、どちらかひとつを採択するかではなく、仕様の中に1080iと720pを併記して頂きたいというものでした。　米国の放送方式はATSCによるHD 放送に向けた放送の標準フォーマットとして早くから 1080i、720p、480p、480iが規定されていました。50年以上前に発明されたテレビ放送が米国に合わせてNTSC 方式を日本は採用し、ヨーロッパ・中国・ロシアなどがPAL 方式を採用してきた背景からすれば、日米のテレビ方式がデジタル・ハイビジョン（HD 放送）の時代になっても米国と同様の1080i及び720pを両方サポートするということは自然なことと思われました。日米間の互換性だけではなく、当時よりブラウン管チューブを使った重たいテレビ受像機は、急激な勢いでプラズマ TVや液晶テレビに取って変わることは明らかであり、走査線が走り一本ずつの光るスダレを交互に表示して人間の眼の残像を利用してひとつの映像に重ね合わせるという飛び越し走査よりは、一つ一つのセルが自ら発光する、もしくは遮光をオン・オフして光源を反射もしくは直視し映像を表現するフラットパネルの時代には、プログレッシブ（順次）方式が有利と思われました。さらに、映像圧縮に採用されたMPEG2 方式においては、1080iは22Mbpsでは最高品質の映像を表示するも、その転送レートを15Mbps以下まで落としてくると映像が破綻するという現象も既知のことでした。720pはMPEG2による映像圧縮でも15Mbpsでほぼ最高品質を達成し,12Mbpsでもほぼ実用の域を保ち、さらにMPEG2以外の圧縮方式 MPEG4、H.264、WMV（現在のVC1）などを使えば8Mbpsから 12MbpsでHD 放送を伝送できるというのが、私たちの主張でした。

当時の私の主張をまとめると、「HD 放送は1080iもしくは720pいずれでも撮影、記録、編集、伝送、受信、視聴できることとする。映像圧縮に関してはMPEG2に限らず、将来の斬新な圧縮技術を随時採択できることにする。コンテンツ保護技術や、個人の認証、課金技術は特定技術一つに限らず、複数の技術をそれぞれもしくは組み合わせて提供可能とする。放送と通信の融合（連携）サービスを記述するメタ言語はHTMLをベースに各種プラグインそしてXMLに対応する。XHTMLをベースにしたBMLはそのサブセットとして組み込む。」

それに対して、1080i擁護派は、「1080iが優れた方式で、議論の余地は無い、プログレッシブの話をするなら帰れ!!」（実際に砧の某研究所で当時の所長に言われた言葉ですが...今の所長さん（E並氏）はとても紳士ですので、私は尊敬しております。決して誤解のないように）郵政省の会合でも何度となく放送のプロ達に諭（さと）されたものです。｢君はPC 業界に都合の良い方向へ持っていこうとしてるんでしょ｣「崇高な放送の世界を邪悪な世界に引き込もうとしている」と..多くの人が同席する会議の場で私は名指しで糾弾されたものです。

将来のデジタル放送の規格に720pは絶対入れないという強い意思とあらゆる活動は「1080iと720pを併記したらどうか」と主張する陣営を徹底的に痛めつけました。

当時、松下電器産業殿は720pの優位性を説きながらDVC Proをレリースされ、1080iと720pの両用機能を持った松下電器産業のHD D5という放送局用ビデオデッキは、AJ-HD2700やAJ-HD3700という型番で欧米の放送局でも沢山採用され、放送業界の権威あるエミー賞をDVC ProもHD D5も受賞されています。このD5というビデオデッキはNHK殿に納入する時、720pの機能が付いているなんてことがバレると殺されるので、本体に点在するボタンを11個以上押さないと、（つまり二人の人間の指を駆使してボタンを押さないと720pの機能はアクティブにならないように細工がしてあったそうです。）..まるで隠れキリシタンが隠し絵にキリスト像を描いていたような話でありますが..この類（たぐい）のプレッシャは日々激しいものになってきて、魔女狩りに駆り出された狂信的な信者が、誰彼となく次々と火あぶりに挙げるような行為が続いたのです。

480pと720pの実験放送をやっていた日本テレビのSさんとKさんの受けた仕打ちは、某放送局のEB沢さんから直接日テレ社長のUJ家氏に電話をかけてこられて、「お宅の技術のトップの人間は、ウチに対抗して何かやっているようだけど、けしからん話だ。そんなことではデジタル・ハイビジョンの映像をウチから供給できなくなるけれど、それでも良いのかねぇ」と迫ったそうです。その結果Sさん、Kさんは当然将来取締役が約束されてもおかしくない何十年にも渡る業界に対する貢献がありながらいつのまにか表街道を去ってしまうことになりました。

テレビ朝日殿が新しいスタジオを作るにあたり、1080i/720pの両用ビデオ・スイッチャーを東芝から導入された時、某放送局のキツイお達しがテレ朝と東芝に飛び、720pの機能は殺して納入するようにとの指示が飛んだそうです。そして、BS-iのスタジオ導入で,1080iのカメラと720pのカメラを性能評価したという話を聞きつけて、「まさか720pのカメラを導入するなんてことはありませんね？」という問い合わせが某局から入ったそうです。

TBS殿も全く同様にメインスタジオへのHD機材導入にあたって1080iと720pの両用システムの導入計画は純粋な技術的観点の選択肢だけではなく、それ以外の見えない力に奔走されておられました。「魂の報道」を標榜するTBS殿の報道部門が、DVC Pro　720pを採択されたことが、唯一の救いと感じられました。

NAB98の会場にて明日から開場というまさに前日のこと、某放送局のY氏、会場を事前に巡回されJVC殿の会場にて1080iと720pの両用カメラを発見、JVC殿に対して「好ましくない表示は控えるようにと一括」結果としてNAB98の初日には無残にも綺麗にできた展示パネルの1080i/720pの文字列の720pの部分にはガムテープが張ってありました。

毎週のようにこのような話を耳にするにつけ、これは魔女狩りでも特高警察の検閲でもあるまいに…現代の話なのに本当にそんなことが起っているのだろうかと自分の耳を疑っていました。そしてそれが、とうとう我が身にも降りかかったのでした。

1998年のNABショウでマイクロソフトは初めて放送関連のコンベンションで技術展示をすることになりました（関連記事）。松下殿より当時500万円程したHD D5デッキをマイクロソフトは購入し、1080iと720pの映像を左右1対で比較デモ表示し、どのように優位性が表示されるか比較デモを予定していました。1080iの標準的な撮影は1440x1150の1080i標準ビデオカメラによる撮影結果を1920x1080の映像に計算しなおし（アップスケール）、それをスダレのような偶数・奇数のフィールドに振り分け送出するという方式を取っていました（現在のデジタル・ハイビジョン放送の標準撮影方法です。）。そして同じ映像を1280x720の720p標準カメラで撮影しD5デッキに録画した映像をそのまま720ｐで再生するというデモ内容でした。映像の再生には当時の最高品質のCRT スタジオ・モニター(8000 ドルクラスのSONY 製品を2台)をマイクロソフトの展示会場に用意しておりました。比較展示用デモ映像は同じスタジオ環境で撮影した1080iと720pのそれぞれの映像データをお持ちの松下電器産業殿からD5の録画テープをお借りして、初日のデモへ向けて全ての設営と映像チェックが終わった時のことです。某放送局の方が、マイクロソフトのブースを垣間見るや、とても渋い顔をしておられます。

私は夕方の6時過ぎに会場の設営も終わり、ホテルに戻ろうとしていたところ、松下殿から緊急の連絡が入り、展示に使っていたビデオテープを持って松下殿の技術担当役員のホテルの部屋まで来て欲しいとのこと..部屋に入るとその役員さんは、ベッドの上にあぐらをかいて、その両脇には15人を超そうという松下の方々が壁沿いに2列にずらりと並んで座っているではないですか..その姿はまるで、新入りの囚人（私）が牢名主の親分に「今日からお世話になります」と仁義を切るのかい、というような雰囲気でありました。

そしてその親分さんが言うには、「そのテープ黙って置いて、帰ってくれ」とのこと..「冗談じゃない、そんなことしたら明日の展示は何も映像が表示できないではないですか？何故そんな唐突な話をこの期に及んでされるのですか」と問いただしたところ、松下がマイクロソフトに協力して720pを推進するのはけしからんと、某放送局からお叱りを受けたと..それだけでも絶句の出来事なのに…「とにかく松下から映像を貸し出すなどとんでもない..即効撤収してくるように」との具体的な命令を受け私は必至に食い下がり、「その映像作品は全て松下殿の著作物であり、某放送局に文句を言われる筋のモノでは無いはずです。それを何故ゆえに引き上げなければならないのですか？」と伺えば..「その中のヨーロッパのお城のシーンはARIB加盟各社がテスト映像として皆で利用するために松下が供出したもので、そのテスト映像をARIBの会員でもないマイクロソフトが勝手に使うのは如何なものか？」とのこと..私はさらに一歩も引かず交渉を続け…もしそれが現実になるのなら「明日の朝は急遽説明のパネルを書いて、某放送局の名前を実名で明らかにした上で、この名前の会社の不当な介入でマイクロソフトでは展示ができなくなりました」と張り出しますよとまで迫りましたが担当役員は首を立てに振りません。最期に私は「判りましたこのテープはここに置いて行きますが、夜中に誰かに盗まれたということにして私が犯人になりますから..盗難届けを出してください!!それでは如何でしょうか？」と交渉は3時間を越える押し問答となりました。

その結果最後に明らかにされた背景は、某放送局の方から松下の役員に語られた厳しい言葉でした。それは、「君、僕らは今年50億円くらい君の会社からモノ買う予定だよねぇ、そんな態度でいると、50億円のビジネス失うことになるよ、君ぃ!!　それでも良いのだね!!!」というもので、担当役員は縮み上がってしまったのだそうです。技術担当の役員がマイクロソフトの展示に協力をした結果、50億円のビジネスを失うことになったら営業担当の役員との軋轢を生むことは必至であり、そこまでのリスクを負ってまでビデオテープをマイクロソフトに貸し出すわけにはいかないとの判断、私はビジネスの交渉でこんなに困り果てたことは一生に何度も無いというぐらい意気消沈しきっておりました。

夜10時にならんとするタイミングで、日本からシアトル経由でラスベガスに到着後、時差から回復する間も無く会場の設営を手伝っていた私はもうダウン寸前…そこで思いついた解決策は「判りました、このテープはお返ししましょう。その代わり今から新規に撮影を開始しますから、必要な機材と人を朝まで貸してください」と何とも無謀な提案を申し出たのでした。　NABのメイン会場からマイクロソフトの借りていたヒルトンホテルの部屋まで、HD カメラ（当時は100kg以上あったと思います）とD5のデッキを担いで深夜に部屋へ持ち込みスイッチャーや編集機もないままイッパツ撮りでデモ映像を仕上げなければなりません。私はそれまでにいくつかの放送スタジオに見学に行ったことはあるものの、映像プロデュースも撮影も全くのシロウトですので、カメラのライティング、撮影のオペレーションに付き合ってくれる人たち3人ほどに朝まで付き合ってもらいました。

途方に暮れて困ったことは、深夜の12時にラスベガスのホテルで撮影できる生素材など有りはしないのです。それも著作権、肖像権を侵害せず、HD 映像の違いが際立って表現できる素材、なおかつ1080iより720pの方が綺麗に見えるという素材（多くは、風にそよぐ木々とか波打つ水面、キックされたサッカーボールなんてものが使われるのですが..残された時間に日中でロケハンに出かけることもできず、全てはラスベガス・ヒルトンの部屋で深夜、朝までの6時間以内に解決しなければなりません。

まず、深夜のルームサービスで果物の盛り込みを頼みました。そしてその果物の表面に霧を吹いて光るリンゴの表面に張り付く水滴なんてものを撮影しました。本格的なスタジオと違って光の回り方も映像のモニタを視ても、思ったような映像にはなりません。

夜も更けて3時を廻り4時にならんとした頃でしょうか、雑誌のカラーグラビアをメクりながら、この際著作権の許諾を無視して雑誌に写っている写真を撮影してしまおうか？こんな深夜にマトモに著作権の許諾などできる素材など有りはしないし、と途方に暮れていたところ、あるアイディアが湧き出てきました。「そうだ、ドル紙幣を撮影すれば手彫りのエッチングで表現された人間の顔やお札の文様はHD 撮影すればビックリするほど細かい映像として撮影対象になるに違いない、誰でもそのパターンが何か理解できるはずだし、何よりもお札の縦横無尽に走っているストライプが際立って720pと1080iの違いを引き立ててくれるに違いない」と確信するに至ったのです。ドル紙幣をビデオ撮影しても肖像権や著作権を主張する人もあるまい、という点が一番大事なポイントだったのです。

壁に貼り付けた50ドル札（私の持っていたピン札はそれしかなかったので）にバッチリとライティングを施し、撮影した結果は「キタ、キタ、キターッ」という感じ!!カメラをパンして右へ左へ振りながらお札の表面を舐めるように撮影した720pの映像は細かい線の1本1本を明確に表示して、1080iの映像は実に見事にモアレ縞が出まくり画面にチリチリと汚い映像が糸を引きます。これでこの映像をそれぞれディスプレィに表示した上で、 Permalink | 記事への反応(0) | 11:32

2016-03-02

■[ゲーム日記]３月２日

○朝食：なし

○昼食：おにぎり三つ

○夕食：パン三つ

○調子

おちごとはむきゅむきゅー！っていいながら、マウスさんとキーボードさんを動かしてわらせた。

来週から少し忙しそうだけど、今週は楽そう。

ただ、この仕事は3月までで、4月からはまた新しい職場になる予定だったんだけど、

なんか4月以降も今の職場に残れるかもしれないらしい。

けど、同じ会社の咲の深堀さんに似てる人は、4月からは今の職場には残れないらしい。

なので営業の人に「二人でチームみたいに動かしたいから、営業的には深堀さんが辞めるなら、増田さんも一緒に別の職場にしようと思ってるんだけど、どう？」って聞かれた。

うーむ、これは難しい問題だなあ。

正直、今の職場は

駅から近い、突発的なトラブルが無い限り忙しくない、業務も自分のわかる言語だし難しくない、

とかなり良い感じだから、個人的には辞めたくない。

何より、ようやく業務仕様も理解してきて仕事が楽しくなりだしてるからなあ。

だけどそれは、深堀さんが色々調整してくれてこそだったりもするから、出来れば一緒にいたい。

けど、

深堀さんと一緒に別の職場

深堀さんとは離れて今の職場

の二択しかないから、よおく考えて返事をしたいと思う。

あーでも、悩ましいなあ。

っていうか、こういう職場を転々とする系の仕事、僕には向いてなさげなんだよなあ。

はあ、むきゅむきゅーだ。

○ゲームニュース

ハードコアなローグライクアクション「Below」のプレイアブルデモが公開。食料と水分を補給しながら洞窟を進め

http://www.4gamer.net/games/253/G025347/20160302033/

そうやあ、E3のムービーでこんなのあったなあ。

どうやら、水面下では動いてたらしく、ようやくプレイアブル出展したらしい。

ローグライクは大好きなジャンルだし、貴重なコンソールでは独占なので、購入予定だな。

新コンテンツを導入する決定版『Ori and the Blind Forest: DE』3月11日海外発売決定

http://www.gamespark.jp/article/2016/03/02/64097.html

通常版は買ってるので、お安く買えるらしいので、買おうと思う。

思うけど、僕が望んでたイージーモードは搭載されないようだ。

うーむ、僕には難易度が高すぎてあまり楽しめなくて、積みゲーにしちゃってるんだよなあ。

Windows 10向けの『Forza Motorsport 6: Apex』が発表！―Free-to-Playで今春配信

http://www.gamespark.jp/article/2016/03/02/64091.html

あー。

まあ、キラーインスティンクトのシーズン3もWin10で遊べるし、クァンタムブレイクもだし、

ここ最近のMSの流れを見ると妥当ちゃ妥当か。

けど、看板タイトルのForzaがこうなると、ますます Oneの存在意義がなあ。

GearsもUEはWin10で遊べるらしいし……

ま、まあ、Haloが遊べるだけでOneの価値はあるか。

Microsoft、Windows 10とXbox Oneなどを包括する「UWP構想」を本格的に始動。Xboxでは家庭用ゲームハードの世代交代が無くなる？

http://jp.automaton.am/articles/newsjp/microsoft-started-to-make-universal-windows-platform-games/

う、うーん。

そらWindowsで長年互換を追求してるMSが言う分には説得力がある。

けど、ゲームではMicrosoft派の僕が普段使いのパソコンはWidowsじゃなくてOS Xを使ってる理由として

「ハードのごたごたが面倒くさい」っていうのがあるんだよね。

やれ、ビデオボードがどうのとか全く知識もないし、調べる気すら起きない。

日本のノベル主体のゲームなら、MacBookAirにWindows入れても十分動くから、それで十分って感じなんだよね。

そういう、ハードのカスタマイズ？的なのが面倒くさい層のために、家庭用ゲームコンソールってのがあるわけで、

正直、

「PCゲームのように、自分の所持するXboxの性能に合わせてグラフィックを調整したり、あるいは最新のゲームを買うためにXboxをアップグレードあるいは買い換えるという日常が、将来的にはやって来るのかもしれない。」

っていう本文の未来は、あまり歓迎したくないなあ。

こちとら、64拡張パックすら、面倒くさいんだよ。

Permalink | 記事への反応(0) | 21:40

2016-02-13

■http://anond.hatelabo.jp/20160207164547

移住。

少なくとも今時の高校生とか平気で３垢とかあるしTwitter 互換クライアントもそういう使い分け歓迎している

Permalink | 記事への反応(0) | 09:52

2016-02-03

■OSのアップグレードに関して思うこと

Windowsは最新版への更新を推し進めるMicrosoftが文句言われる

Androidは最新版へ上げない端末メーカーが文句言われる

アプリの非互換が発生するのはどっちも同じなのに、面白いよね。

Permalink | 記事への反応(1) | 08:09

2016-01-23

■http://anond.hatelabo.jp/20160123213257

(トラバはらないのは何かポリシーがあるんだろうな)

だから、コンサルやってるってこと。顧客の問題を、プログラムを書いて解決したら、報酬をもらえる、それだけの話だよ。

顧客の問題はそれぞれ個別なんだから、互換性が問題になるケースもあれば運用で回避できるケースもある。互換性に引っ張られたくなければ後者のようなケースだけ請ければいい話。

Permalink | 記事への反応(0) | 21:46

2016-01-17

■CDって偉大なフォーマットだったな

・デジタルデータにしたことで数十年単位での無劣化保管を実現

・あらゆる音源を共通フォーマットに統一し高い互換性を確保

・コピープロテクトがないのでいつでも誰でも自由に活用できる

もしCDにどれか一つでも欠けていたら今のオーディオ界はないのでは

Permalink | 記事への反応(1) | 15:46

2016-01-16

■テキスト 入力 専用機としてiPad mini + Magic Keyboardをお勧めする理由

この組み合わせで仕事として本をまるごと一冊書いている人間としての感想。

iPad mini 4 16GB + Magic Keyboardの組み合わせでMacbook Air最安モデルの約半額で、macの快適なキーボードを使って高速で仕事ができ、電源がない場所でも一日中問題ない。

iPadは消費電力がPCより少ないので、スマホ用のモバイルバッテリを持ち歩けば、24 時間電源なしでいける。

実感として、iOSが仕事に使えないというのは、すでに過去の話になっている。（追記：ものを書くという仕事に関して使える/使えないを議論している旨をタイトルで表明している。他の業種については論じていない）

勤務先の事情によりつねにフルWindowsを使わなければならないという制限が外せる人は、重いノート pcとACアダプタをバタバタ持ち歩いたり、最近たくさん出始めている格安 windows10 タブレットにキーボードカバーやらをつけて、安っぽいキーボードの打ちにくさを我慢しながら使う必要はもはやないと思う。

現在の組み合わせにたどり着く前に、Macbook Air、Windows ノート、Windows タブレット、Android タブレット、Chromebook、Pomera DM100を買って使ってみたが、常に以下のいずれかの点で問題があった。

・バッテリーの持ち時間

・携帯性と重さ

・キーボードの快適さ

・直感的な操作と速さ

・オフライン環境での使用（Chromebookは速くて快適だが、オフライン環境で起動するとログインすらできない）

・日本語処理、多言語処理の甘さ

・クラウド上でのファイル保管・同期

・原稿へのスタイル適用（章タイトル・見出しのフォント変更、ルビ振り、レイアウト指定等）

上記の欠点をすべて補うのが最初に述べた組み合わせであった。

特にキーボードの選択は、一日8時間以上タイピングを続ける人間にとっては致命的であった。現在出回っているMicrosoftのモバイルキーボードはAmazon等での評価が高かったので全種類試してみたが、打鍵の快適さはMagic Keyboardに比べると、どれも3万円前後の格安 Windows タブレットについてくるキーボードと変わりない。

携帯性と重さという点では、最初のうちはMacbook Airに満足していたが、やはりこの機械の独特のゴツゴツ感と肌触りの冷たさには最後まで抵抗があった。また、あのアダプタをつねに持ち歩くと、けっこうかさばるのである（あのアダプタの華奢な感じが携帯時に与える不安は、Macbook Airをずっと持ち歩いている人ならわかってくれるだろう）。

iPad miniの分解できるアダプタ＆ケーブルは、カバンに入れるときに大きな安心感を与える。また、旅行中以外はそれすら持ち歩く必要がないことにあとで気づいた。

iPad mini 4 16GB + Magic Keyboardで約530g、好みのケースを付けて600 - 650g 、

テキスト入力メインでの動作時間が体感で約8〜9時間といったところだ。

一方、最近話題になったキングジムの小さな pc ポータブック XMC10は、本体重量が約830g、

動作時間は約5時間。本日付での価格.comの最安値は約9万円。

Surfaceをはじめとして、携帯性を重視したWindows機を最近各社がこぞって出しているが、サクサク動くスペックにして15 - 20万の価格帯を考えるとどれもライトユーザーにとっては高嶺の花だという感じがする。フルwindowsで1kg以下というのは、現時点でそんなに高い付加価値なのだろうか。

追記：

＞Docsはオフラインでもほぼ完全な形で使えるはず

そういう評判をネットで読んでChromebookを購入して使ってましたが、オフライン環境で電源OFFから立ち上げるとゲストユーザーとしてしか使えず、いろいろ制限が多すぎて面倒なので結局売ってしまいました。（再追記：映像ありがとうございます。去年秋頃までAsus C200MAを使っていて、何回やってもオフライン環境では自分のアカウントでログインできなかったんですが、その後アップデートで改善されたという理解でよいのでしょうか。ちなみに、このエントリの著者です→http://anond.hatelabo.jp/20150927211800）

Google日本語入力はとてもよいと思いますが、問題は別の言語（欧文）との入力を組み合わせる場合です。Android端末と共通の問題ですが、特定言語（欧文）に特有でしかも頻繁に使う引用記号などがChromebookでは瞬時に打てません。OS全体の言語設定を変えても無理でした。多言語処理が一番まともにできるのがmacとiOSという消極的な理由で現在の選択肢に落ち着いています。

8時間書き続けて、現在

iPad miniのバッテリ残量：38％

Magic Keyboardのバッテリ残量：100%

自分の場合は、特定の仕事に必要な条件を列挙していって、あとのことには目をつぶったら消去法でこの組み合わせになった。最初はiPad miniなんて割高な情弱向けの端末だと思って、見向きもしなかったが、いろいろ試してみて結局現時点でこれが残った感じか。

出先であれもこれもやる必要がありそうだと考えて、「全部入り」を選択するとフルwindowsのノートになるんじゃないか。

その場合でも、価格/重量/バッテリー持続時間/キーボードやタッチバッドの使いやすさ等で、トレードオフがある。

あらゆるシーンでフルwindowsが必要だという考え方は、仕事に必要なものの明確化ができていないか、心配事が多くて、バッグにいろいろ詰め込みすぎて重くなってしまう事態に似ていると思う。

文章を書く時は横置き。iPad miniだと、縦置きでPagesを使うと字が小さすぎる。Wordのドラフト表示みたいなのができて、プレーンテキストだけじゃなくて、傍線を引いたりスタイル設定できるアプリがあったらそっちに乗り換えて縦置きで書くかも。

Thinkpadのキーボードの使い心地、自分も大好きだけど、やっぱり重量が問題。

歩き回って考える→カフェや図書館で座って書く→歩き回って考える

の繰り返しで書いていくので、バックパックに重いノート pc一式を入れて1日それをやると、背負い紐が肩に食い込んで痛くなってくる。

テーブルが高すぎる施設もけっこうあるので、キーボードだけを膝に置いて打てるのは便利。

タブレットホルダーやらをいちいち立ててセッティングするのが面倒ではある。

帰宅してから古くて大きい方のiPad + Microsoft Universal Mobile Keyboardでこれを書いてみたが、やっぱりこのキーボードは長時間執筆には向いていないと感じる。ちなみにこれは、最近話題だったASUS Transbook T90 CHI のキーボードによく似ていると思うのは自分だけ？まったく使えないほどひどくはないが、どこかおもちゃっぽい。

iPadの日本語入力が完全ではないというのはまったく同意します。ただ、使い続けているとなんとかなってきます。いまのところATOKは買わずに、もともとの日本語入力だけで毎日原稿用紙10枚分書いています。他の人が言われてるほどこの日本語入力は苦痛ではないです。

なぜキーボードにそんなにこだわるのかというと、腱鞘炎が再発しないように気をつけているから。

エディタは無料のPages。UIの好き嫌いで選んでますが、結果的にアイディア出しをやりながら草稿を貯めていく作業にけっこう向いているようです。起動すると文書がカード形式で並び、それまで自分が考えてきたことがおよそ俯瞰できます。Command + Spaceキーでスポットライト機能を出して検索するとpages ファイルは全文検索がかかるので、ipadに入れてある他の資料、複数の草稿の間を行き来しながら納品原稿を仕上げていくイメージです。縦書き状態のチェック等は最後にdocx 形式にエクスポートしてノート pcでやります。pages ファイルとdocx ファイルの互換性、見た目の再現性等については、校正が入るので基本的には問題になりません。

なぜ電源のない環境にこだわるかというと、自分の場合、歩いて体を動かしているといちばん考えがまとまるので、ある程度まとまって座ったところに電源があるかないかを気にして行動を制限したくないからです。

「多言語処理」で意味するところは、複数の言語に特有な記号や文字組みを同一の文書内で適切に混在させるという程度のことです。

日本語入力を切って半角入力にしただけでは入力しにくい欧文の記号はたくさんあります（アクセント記号、"と違うかたちの引用符、改行できないスペース記号等）。日本語と英語だけを混在させる分にはこれは問題になりませんが、他の欧文を表示させる段階になると問題になってきて、Androidはこういった処理がひどく弱いので実用に耐えませんでした。Windows + Wordで文書を書いている分にはこの問題はクリアされていますが、日本語版のwindowsにたとえばフランスで作られた辞書アプリをインストールすると、文字化けします。OS全体の言語設定をフランス語に変更しても解消されません。一方、同じアプリのmac版は、OSの言語設定に関係なく適切に表示されます。こうした処理をユーザーの側がいちいち気にしないレベルで解決されているのがmacとiOSという消極的な理由で、少々高くてもしょうがなく使うわけです。Androidのキーボード周りがもう少し洗練されてきたら乗り換える可能性もあります。

Permalink | 記事への反応(7) | 12:56

2016-01-05

■4人のいい女

自分にとってのいい女の定義が微妙で困る。

自分にとって欲しい魅力を書くが、それが相反するものだというのも知っているが、改めて書いてみたい。

一般社会でこんなもんまともに言える機会はそうそう無いが、頭の整理のためにまとめてみる。女性からはぼろくそだってのも知ってるが、それはそれで別の話だ。

どうせモノ扱いだ、ダッチワイフにしろとか、色いろあるのだが、そういう話じゃない。

まず、セックスしたい女、パートナーとしたい女、連れて歩きたい女、子供生ませたい女　この4つに分かれる。

・セックスしたい女

分かりやすい。まず僕とセックスしていることを他人に口外しない、ブサでもエロければOk。そして何よりもセックスがある程度好きなことが条件だ。年齢はセックスするだけであれば、正直そこまで拘らない。

美人で肉感的であればと妄想はあるにはあるのだが、現実論として美女で肉感的な女性に限って、そういう男しか来ないので、辟易しているのも知っている。

逆にAVなどに出る女性は、こういう理想を形にする事でお金にしているんだろう。

・パートナーとしたい女

子無しの関係で、結婚・事実婚でもいい。セックスも必要あればするが、それが絶対ではない。異性友人の上方互換みたいなもので、できれば一緒に一生いたい。それぐらい精神的に必要な女。が、こういう女性は大抵、子供が出来ると人間が変わってしまう。良くも悪くも。

・連れて歩きたい女

セックスしたい女と近いのだが、これは単に見せびらかしたい美人である事だけが重要。ブサイクと仕事以外で一緒の空気を吸うのですら嫌だ。仕事はその点偉大だ。どんなブスでも一緒にいる理由を与えてくれる。

・子供を生ませたい女

健康で若く、良い遺伝子を持ってさえいればOk。そりゃ若い女に群がるわけだ。

…。

ここまで願望書いてて、そりゃ生きててつまんねーなと。

Permalink | 記事への反応(1) | 00:01

2016-01-01

■[ゲーム日記]１月１日

○朝食：納豆卵掛けご飯

○昼食：なし

○夕食：まだ食べてない

○調子

む、む、む、むきゅー！

午前の六時半頃に目が覚めて、朝ご飯を食べて「よおし、今年はゲームするぞー！」と思って

積んでたマスエフェクト1を360にインストールしてたら、爆睡してた。（今気づいたけどOneの互換に対応してるから、そっちにインストしてもよかったかな）

そして起きたのは午後八時頃。

な、なんだかなー。

一日を完全に無駄にしてしまった。

電気毛布がぬくぬくすぎるのがよくないんだよなあ。

Permalink | 記事への反応(0) | 23:44

■Vimのプラグインを作るならグローバル変数名を意識しよう

グローバル変数を使う場合は変数名の先頭に名前空間をつけよう。

ありきたりな名前を付けると他のプラグインに影響する可能性があるからだ。

ダメな変数名の付け方

let g:age = 20

良い変数名の付け方

let g:namespace#age = 20

名前空間の区切りは#でなくてもPHPのPSRで定義されているように_を使っても良いだろう

後は互換性を維持できるよう、よく考えて名前を決めること。

プラグイン利用者は頻繁な仕様変更を望まないからである。

jedi.vimやsyntasticなどの著名なプラグインはしっかりとした変数名をつけているので参考になるだろう

Permalink | 記事への反応(0) | 12:16

2015-12-30

■Excelが最強格闘技 である事

今、ちょうどExcelを使っている所でこれを書いている。

何故書いているかというと、XMLのデータのインポートを待っているからだ。

若い時は、Excelで全てをこなそうとする日系企業、はたまたドメ会社を心の底からバカにしていたのだが、年月が経ち、結果としてExcel最強説を私めが、提唱させていただきたい。

昔Excelが嫌いだった理由は、1　ダサい　2　ダサい　3　ダサい　4　経理じゃないんだから　5　これだけ洗練された仕組みがあるのにExcel使ってるの？　6　ダサい　7　重い

…などなどの理由である。

昔の自分へ、反駁を試みたい。

Excelの素晴らしい所

・大抵の会社と人が使っている　（若しくは互換性のある仕組みを使っている）

大学の研究室であれば、実験的なものを使うことでもよかろう。しかし社会はそうなっていないのだ。近所の八百屋も取り敢えず使い方は分からないまでも、Excelが入っているものなのだ。

これは大きい。

逆に言うと、これだけ日本で浸透しているからこそ、ダサいとも言えるのだが。

・Excel方眼紙

よくExcel方眼紙否定論者を見かける。こういう奴らは、Excel方眼紙の利点を理解していない。Wordでやってみろ。計算がスムースに出来ないではないか。結果Excelで良いのである。

・もはや表計算ソフトではなく、Officeそのものである

Excel 否定論者は、否定したいがあまり、過去のExcelのイメージしか持っていない。実際長いこと使っていると、Excelが表計算ではなく簡易的なデータベースとして大きく進化していたり、フォーマットの違うファイルを取り敢えず一回Excelに入れて吐き出しをさせるなど、文字列の扱いが遥かに得意になっていることに驚きを禁じ得ない。