  |
はてなキーワード: バリとは
(1巡目)
目「ワークライフバランスを大切にしたい増田さんは～」
読み上げ係「ワームホール クライシス……スパイシー オン ザ フューチャー (楽しくなってきた) エターナル デスティニー ラブ アンド ピース OK☆」
意識「えっ？なにそれ絶対おかしい！ちょっと目！もっとよく確認してちゃんと解析班に渡して！！」
(2巡目)
目「ワークライフバランス……」
意識「うぉーくらい ＆ ばらんす？……！もしかして、ワークライフバランス？」
(3巡目)
意識「やはりワークライフバランス！……で、ワークライフバランスがどうしたって！？もっかい最初から！急いで！」
(4巡目)
読み上げ係「フォークダンスライブを大切にしたい増田さんは～」
意識「ふんふん、ワークライフバランスの話、そしてこの人はフォークダンスが大事な趣味なのか」
意識「ホバリ…？おいフォークダンスどこいった！？どこから間違った！？目ェ！！」
目「……ワークライフバランスを～」
不慣れな言葉や長い単語が出てくる文章だと、内容をちゃんと頭に入れるのに時間かかりすぎる上に、
仕事の付き合いで嫌々ねー、本当は全然行きたくなかったんだけどしつこく誘われちゃってさー、本当に行きたくなかったんだけどさー、ってこんな前置きはどうでもいいな。
前回デビュー戦は飛び入りな上に張り切って待合室で爪切って行ったら「爪切った直後に触られると刺さって痛いんだよ、よく考えろ」的な説教をくらってかなり落ち込んだ。
今回は人気があるらしい嬢を予約して挑戦。
どの写真も同じ顔の角度で撮ってるから心配だったけどほぼ写真通りだった。細身でどっちかっていえば美人系か。
で、どんな話の流れだったか忘れたがその嬢が周りとポケモンで盛り上がってるって話を始めた。
まーどうせほどほどに交換したりほどほどに対戦している程度だろ、と思って軽く聞き流していた。
一方そのころ俺のポケットモンスター（英語圏のスラング）は順調にレベルアップしていた。
「俺もゲームよくやるよ」
「へー。なにやりました最近？」
OverwatchやFallout4なんかじゃ通じないだろう。かといってスマホゲーはカジュアルすぎる。
「す、スプラトゥーンとか」
「あー、周りに勧められてるけどやってないんですよねー」
その後の話の流れで、スプラトゥーンは遊んでないけどWii Uは持ってるらしい。あれ、けっこうマジでゲーム好きっぽい？
「ゲーム好きなの？」
「最近は時間なくてポケモンしか遊んでないけど。誰も知らないようなハードも持ってますよ」
誰も知らないハード？どうせXboxとかバーチャルボーイとか3DOとかプレイディアとか止まりだろ？
「なに、Xboxとか？」
鼻で笑われた・・・。
「え、じゃあなに」
「うん。ピピンアットマークは数年前に箱付きのやつをアキバ・・・じゃなかった中野で見つけて、この子は私に買われるためにいる！って思って買ったんだけど。買ってから気付いたんだよね、ソフトがぜんぜんわからない(笑)。でもピピンアットマークはバンダイだからガンダムのソフトは出てるだろーと思って探したんだけど見つかんなかった。だから一度もピピンアットマークで遊んでない(笑)」
一方俺の両乳のアットマークもピンピンになっていた。
「ハイサターンも車の中で遊べるけどさ、友達の運転してる車の助手席で一人でバーチャやっててもねえ(笑)」
「近くを走ってるドライバーも、えっバーチャ！？って驚くよね・・・」
「いやー普通の人はバーチャ知らないでしょ？このまえ20代のヤングなお客さんがね、PROJECT X ZONEの参戦キャラの半分もわからないって言ってて。鉄拳は知ってるけど、バーチャもストライダー飛竜もわからないって言われて。すごくショックだった。私は全キャラわかったのに」
いや俺もストライダー飛竜はよく知らない。それとこの嬢のプロフィールは20代前半だったはずだけど、今の発言でうちゅうのほうそくがみだれてね？
このあとも逆転裁判6が期待できないとか（俺は大逆転裁判の途中で積んでる）、ブレイブリーセカンドががっかりだったとか（俺はフォーザシークエルの途中で積んでる）、ゼノブレイドクロスもがっかりだったとか（俺は前作も今作も途中で積んでる）、さっき「忙しくてポケモンしかやってない」って言ってたわりに、俺なんかの何倍も現役ゲーマーらしい話をされた。
「も、もしかして、ポケモンもけっこうやりこんでます？（思わず敬語）」
「ううん全然。でも6Vは何匹か持ってる」
やりこんでるじゃねえか！
「好きなポケモンで厳選しまくって、200個くらいタマゴ割ってようやく欲しいやつ出たんだよねー」
「は、はあ」
俺は本編ストーリークリアしてちょっとポケモン集めたくらいでやめてしまう程度だから、まったく頭が下がるばかりである。
一方俺のポケットモンスター（英語圏のスラング）はメガシンカしていた。技はかたくなる、こうそくいどう、つのでつく、みだれづき。
フィニッシュ後、身体をすすぎながらせがた三四郎と湯川専務の話で盛り上がった。この嬢、30代前半の俺と同世代としか思えねえ。
一方俺の湯川専務（のちのクオカード社長）は常務に降格していた。
で、現状、俺調べだとソープ嬢の2人に1人はピピンアットマークとハイサターンを持っている計算になるんだけど、これが全国的な標準値とみていいの？
（１０日１１時半追記）
ネットの片隅で誰の目にも触れないつもりで事細かに書いたが、この勢いで世の中を石鹸（ソープだけに）すると嬢本人の目に留まってもおかしくないと思って震えている。
増田が「保育園落ちた日本死ね！」で国会を揺るがすレベルの最先端メディアだってことを忘れてたわ。
そんなことより、主さん主さん聞いてくださいよ。
そしたらなんか人がめっちゃくちゃいっぱいで座れないんです。
で、よく見たらなんか垂れ幕下がってて、50円引き、とか書いてあるんです。
もうね、アホかと。馬鹿かと。
お前らな、100円引き如きで普段来ていない天一に来てんじゃねーよ、ボケが。
100円だよ、100円。
よーしパパ特大頼んじゃうぞー、とか言ってるの。もう見てられない。
Uの字テーブルの向かいに座った奴といつ喧嘩が始まってもおかしくない、
刺すか刺されるか、そんな雰囲気がいいんじゃねーか。女子供は、すっこんでろ。
で、やっと座れたかと思ったら、隣の奴が、大盛バリカタで、とか言ってるんです。
そこでまたぶち切れですよ。
得意げな顔して何が、バリカタで、だ。
お前は本当にバリカタを食べたいのかと問いたい。問い詰めたい。小1時間問い詰めたい。
天下一品通の俺から言わせて貰えば今、天一通の間で最新流行はやっぱり、
白髪ねぎってのは枡一杯に白ねぎが入ってる。そん代わりチャーシューが少なめ。これ。
で、それに大盛メンマ。これ最強。
しかし頼むと次から店員にマークされるという危険も伴う、諸刃の剣。
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。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 に立ち向かうべく設計された数々のテクニックやフレームワークがあります。これらのシステムの多くは、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 のような場合は期限切れがあってはならないので、パスワード等を預かる認
彼女の一日は日頃の感謝と安全祈願を込めて愛用する道具のお手入れから始まる。
縦ロールは自律でセット。
お支度を済ませてお嬢様は軽やかに言った。
「それでは行って参ります」
決戦場となる体育館に三名のサバイバリストがつどう。彼女たちは一辺が5mの正三角形の頂点に立った。
「最後の戦いが二対一なんて酷くありませんの？」
縦ロールのお嬢様はやんわり抗議する。
ルール上、禁じられた行為ではないが、今までタイマンばかりだったのに唐突な感は否めない。
しかし、姫カットお嬢様とセミロングお嬢様にも言い分はあった。
「あなたが「ふつう」でしたら、こんな戦い方はしませんけど……」
「おわかりですね？」
縦ロールのお嬢様は物憂げにうなづいた。
「そうですわね……分かっていますわ。美しさは罪、ということですわね？」
「ぜ、ぜんぜん分かっていませんね！！」
セミロングのお嬢様は脱力した。姫カットのお嬢様には彼女よりも耐性がある。
「あと、これは最後の戦いではありませんよ。
「私のはナイｒ……」
最初に武器――ねじ込みクロスを使って作った十字槍だ――を構えたお嬢様に、
「なかなか安定感がありますわね」
セミロングお嬢様の持つ500mmのSGP25Aパイプは1本で1.2kgになる。
服の中はもう少し短いものも多いが、これらを14本と多数の継ぎ手を抱えた彼女は20kg以上嵩増しされていた。
彼女が戦いを急いだ背景には重くてしんどいという切実な理由もあったりする。
「力で引けないならば！」
両縦ロールが地面に打ち込まれ、チェーンブロックのレバーが引かれる。
「ぐぅ……！」
有無をいわさぬ機械のパワーにセミロングお嬢様は顔をしかめた。
「私のことを忘れすぎです！」
戦闘態勢を整えた姫カットのお嬢様が鉄鎖引きの横合いから参入する。
「忘れてなどいませんわ！」
チェーンブロックのロックがいきなり外され、踏ん張っていた鉄パイプさんは自分の力で後ろに吹っ飛ぶ。
「えいっ！」
さらに工具の本体側が迫る姫カットお嬢様の左手に投げつけられる。
さきほどまで熱心にお手入れしていたのに酷い仕打ち。
それでも物言わぬチェーンブロックは健気にお役目を果たし、姫カットお嬢様に攻撃回避の労をとらせた。
その眼前に縦ロールお嬢様は駆け寄っている。
「いただきですわ」
いつもなら接近戦は姫カットお嬢様の望むところだが、回避直後は流石に体勢が悪い。
膝を突かんばかりの彼女に、掌底が打ち下ろされる。それを跳ね上げて袖を絡めようとする動きを許さず、右のミドルキック。
ガードをしてもダメージが加算される。
「ぐぅ！」
今度は姫カットお嬢様が下から右貫手を繰り出すが、左縦ロールが一閃。
貫手を弾き飛ばして、巻き毛が背後に回り込む。
インシュロック使いの首筋に死に神に鎌を突きつけられたような寒気が走る。
予感が現実にならなかったのは、セミロングお嬢様が槍を投げて敵を後退させてくれたおかげだった。
「わずらわしいですわ」
さきほど伸ばした左縦ロールが巻き戻ると同時にチェーンブロックを姫カットお嬢様の背中に肉迫させている！
「……っ！」
鉄鎖に背中を強打され、姫カットお嬢様の息が詰まった。一対一なら勝負ありであるが、
「やああああっ！」
白い鋼管を構えたお嬢様が自分に注意を向けるため、喚声をあげて突っ込んでいく。
縦ロールお嬢様は再度フックを投げつけて、敵の接近を止めた。
唇をシミターのように吊り上げた彼女は、右の縦ロールを綱引きの相手に指向する。
彼女は咄嗟に半身の構えを強くし、敵への投影面積を最小限にした。
ゴアッッ
真横にいる姫カットお嬢様は、右縦ロールが一瞬かすみ、発生した疎密波が縦ロールの前後に広がる様を目撃した。
縦ロールの中から「何か」が高速で飛び出し、セミロングお嬢様を襲う。
「きゃあっ！？」
スカートのブリーツに仕込んだスウェージロックのシームレスパイプが甲高い音を立ててひしゃげる。
ふとももと脇腹への被弾は一発ずつが肌にまで突き刺さった。
「くあっ！」
「おほほ！コイルガンのお味はいかがかしら？おかわりたーんとありますわよ？」
説明しよう！
縦ロールお嬢様は電線を断続的に仕込んだ縦ロールを次々に急速回転させ、
発生した磁場でロールに装填したニードルを順次加速させ高速で撃ち出したのだ！！
凄いね人体。
よく知らない兵器。気持ち悪い。セミロングお嬢様が青サバより血の気の引いた顔で叫んだ。
「そこ！変な混ぜっ返しをしないでください」
アホボケとクールボケに対してツッコミは自分一人。セミロングお嬢様は二対一が別の構図に思えてきた。
漫才によって敵の注意を分散させる意図は理解していたけれども。
「やっぱり三人は姦しいですわ」
縦ロールお嬢様はもう一人への隙ができるのを承知の上で、左ロール砲をセミロングお嬢様に向けた。
まずは配管工を倒す。
姫カットお嬢様が左縦ロールに結びつけた透明なインシュロックの輪かざりを引いたのだ。
彼女は事前に縦ロールのパワーとスピードを把握している。ただで真横の通過を許しはしない！
ニードルの散弾が縦ロールお嬢様にとっての二人の敵、その間に着弾する。
「今です！」
事実上１ターンに三回以上動ける天衣無縫のお嬢様を倒すためには同時攻撃が必要だった。
サバイバルゲーム開始以来はじめて、彼女の顔から余裕が失われる。至急チェーンブロックを波打たせて波動の鞭にセミロングお嬢様を襲わせる。
――はずが、標的は脱皮を済ませていた。重量級の上着をフックに巻き付けて身軽になったお嬢様が突っ込んでくる。
右縦ロールを地面に突き刺しての回転キック。
だが、今度は姫カットお嬢様が上着を脱ぎ、縦ロールの台風に覆い被せた。
大量のインシュロックが織り込まれ、末端がお嬢様の手に握られた、それはまさに投網。縦ロールお嬢様の回転は自らを縛り付ける結果に陥ってしまう。
「うきゅ～」
目がぐるぐる状態の珍獣を狩人たちは押さえつけた。姫カットお嬢様はインシュロックを通したマウントベースをいくつもいくつも床に接着しまくる。
ひとつひとつは5kgf程度の耐過重だが、何十個もつけられては、さしもの縦ロールも動かせなくなる。
「やっておしまい！」
「すみません、縦ロールさん！！」
セミロングのお嬢様は、超硬（タングステンカーバイド）のジグソーブレードを装備したレシプロソーを取り出すと、哀れな獲物に向けた。
「およしになって！何をなさるつもり！？」
至近距離からの悲鳴を浴びたセミロングお嬢様の手が危なっかしく震える。
「うう、罪悪感が……」
「反対側は私が切ります。彼女を自由にしてあげましょう、この縦ロールから」
そう言って姫カットお嬢様は本来はコンクリート切断用のダイアモンドホイールを装着したサンダーを取り出した。
戦闘前に情報交換をした二人のお嬢様は、残る一人は動く巻き毛によって、おかしくなっていると判断していた。
同様の症状を示していたポニーテールのお嬢様が、セミロングのお嬢様に倒されてから、すっかり彼女に懐いている様子からも、そう思ったのだ。
二対一で卑怯と罵られても異常をきたした仲間を放っておくわけにはいかない。
「うぅ……」
強力を通り越して凶悪なツールにざっくりと縦ロールを切り落とされたお嬢様は喪失感と開放感を同時に覚えた。
自分が縦ロールに洗脳されていたと、彼女を引き起こした二人に洗脳される。
「わたくしは今まで縦ロールに操られていましたの！？」
縦ロールあらためウェーブロングのお嬢様は憑き物が落ちた顔でつぶやいた。
「今までなんてことを……」
思わず姫カットお嬢様とセミロングお嬢様は彼女ひしと抱きしめた。
「よかったですね」
「友情の勝利です」
「ありがとう、わたくしの最高のお友達！……ところで、決着がまだですわね？」
「「え？」」
ぴちゅーん
アフロのお嬢様と同じく、縦ロールの使用に耐えてきたウェーブロングお嬢様の肉体も強靱だった。
二人まとめての裏投げという豪快な決まり手で、増田お嬢サバイバル大会は幕を閉じた。
ちなみに縦ロールは毎朝牛乳を飲んで体操していたら動かせるようになったそうな。
「残り１名！
ありがとうございました」
前回
http://anond.hatelabo.jp/20160414193717
次回
元日本マイクロソフトの古川享さんブログより。このブログかなり前から消えてるんだけど、復活の目処は無いのだろうか
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
うちの職場の特徴なのか、業務がやたらと複雑にしてしまう傾向になる。
例えば、1枚の申請書に対する対応マニュアルが150枚あったりする。
誰もそんなマニュアルは読まないし、読み切れないので対応にミスが出る。
「もっと簡単にできませんか？」と何度か提案はしてみたものの、難色を示すばかりで改善しようとはならなかった。
記載量は多いほうがいい、ページがいくらあっても問題がないという考え方がある。
その業務自体はアウトソーシングしているので、ミスがあった場合に相手を非難する根拠となるからだ。
その際の対応は「しっかりマニュアルを確認してください。」「確認して処理します。」といった会話だけで抜本的な解決には至らない。
前置きが長くなってしまったが、なぜ仕事を簡単にすることができないのかという壁にぶつかってしまっている。
恐らく、「簡単＝劣っている」という考え方がどこかにあるんだと思っている。
例えば、らくらくフォンは簡単に使えるかもしれないが、そのユーザーはどこか見下される傾向にある。
これはらくらくフォンが機械に詳しくない人にとってバリアフリーな機器であることからきているように思う。
通常のものが使えないから特別に配慮されたものしかうまくつかないといった具合に。
だから簡単にするという必要が出た場合、誰かができないからそのために配慮して簡単にするという考え方をしてしまい、
それに対し肯定的にことを進めることに抵抗があるのではないだろうか。
前述した業務に関する問題が求めるところの「簡単さ」は性質が違うもので、
バリアフリーデザインに関連してよく出てくるユニバーサルデザインの考え方に近い。
誰にとってもやりにくい設計がされてしまっており、これについて対処することは、
特定の誰かではなく、すべての人にとって益のあることであるという考え方である。
結果として簡単にしたことにより、今までそれができていなかった人ができるようになるかもしれないが、
それはバリフリーの、特定の誰かを目的としたものとは性質が違うわけだ。
仕事においてユーバーサルデザインの考え方、誰もが簡単にできるように、
塗りポイントを第一に並べるのもわかるが、リザルトの塗りポイントは結果論であり、それ以前までの行動如何によっては１位はどうなの？というのもある。
例えば、勝ちチーム１位が１０５０ポイント、２位が１０００ポイントだったとしよう。
単純に塗りポイントで比較すれば１位が１番貢献しているだろう。
しかしだ。
１位のキル数とデス数がそれぞれ０と２、２位のそれがそれぞれ３と１だったとしたら、どうだろうか？
キル数はナワバリにおいては「相手に塗らせない時間を与えた」数であり、デス数は「相手に塗る時間を与えた」数と読みかえることができる。
このとき、キル数＞デス数なら「相手により塗らせなかった」のであり、キル＜デスなら「相手により塗らせた」のだから、結果的には２位の方がチームにより貢献しているはずだ。
影の功労者と言っても過言ではないだろう。
このように、１回のバトルで真に貢献したキャラをみつけるための指標はないだろうか？理系のはてなーならモデルのひとつぐらい容易く構築できないだろうか？
あいにく私はこれからドバイに億単位の商談を複数まとめに出向かねばならないため、日本を発たねばならない。アプデ直後の雰囲気に触れられず残念であるが、これも持つべきものの定めなので仕方がない。
前回で http://anond.hatelabo.jp/20150925125835 あなたのパスタがまずい理由
美味しいパスタが作れるようになりましたが、デブだのと健康被害が増えてはどうしようもありません
ヘルシーにする方法もお伝えしておくことにしよう。
…と思いましたが、パスタが揚がっちゃうといけないので、番外で麺の茹でに関する注意を3つしておきます。
いちお手順に従っていきます
乾麺のスパゲッティだと食事前１時間くらいに麺を水に浸しますね。
うん、水です水。
白いフニャフニャ麺になりますので、
すると鍋はでっかい必要はなくなります。茹で時間も2-3分くらいになります
じゃーまず、茹でますよー
茹でません！
では本当に麺を茹でますねー
いま何グラム入れた？何本入れた？多くない？
お腹がすいてるから？家族の分まとめて？？いやいや、多いですそれ。多い。多いよ。
1 大量に茹でるな
茹でるのは時間がかかるし、いっぺんにやりたい気持ちはよーくわかるよ。
けどね、せっかく作った美味しいソースとちゃんと絡ませることができるの？
ようやく、塩と油の量覚えたのに、麺の量変えたら、そらあかん。
それになんで２人前や３人前にフレキシブルに量を自在に変えて作れるとおもったの？
正しい油と塩の量でできると思っちゃったの？
え？油を倍にしてソースかければいい？
そうかそうか、これ
覚えて帰ってほしい。帰って欲しい。
素材の冷温を無視させてもらえるなら合えるという言葉合がピッタリ。
いっぺんにやるのはまだ無理！！！！
いつも同じ量を茹でろ
さて、茹で具合です。
白に変わったらアウトです。
アウトです(俺の好みの場合)
2 アルデンテ
先に言っとくと
湯で時間は好みです（ｺﾉﾐ）
好みではあるけど、なんであれほど言われてるアルデンテにせんの？
「あたし、かた麺は好きじゃないしー」
え？？
あ、あー。あー…
アルデンテって「ちょっと硬めが美味しいよ」って話だと思った？
ラーメンを食べる若者がバリカタだ粉落としだのと硬さを競うがごとく、イタリアの小僧たちは「俺、アルデンティッシモー」なんて言ってると？
…そうじゃないよ？(そうなのかもしれんけど)
ざるに上げたりフライパンの上で麺を混ぜる時間も、麺の茹だりは進行するから早めに釜から揚げようね！って意味だかんね？
手際が悪い人は、その分早くあげよう！
あとは好み！
水はしっかり切れ
え？びっくりするよね？そんなこと？って俺もそう思う。
けど、何度も言ってるけど、麺とソースを絡ませるのが最大の重要項目。
麺にソースという服を着せるわけだよ？なんで茹で汁を着せたままなん？
ちなみに
水をどうしても切りたくないザル無いわーな人
麺を茹でるときに塩を入れてアルデンテをもっと早めにしてフライパンでしっかりと手早くソースと絡ませる
のならばそれでもok
3 水はしっかり切れ(※塩水て茹でない場合)
・裏返す
基本。特にチャックによる擦れに弱いため。
・チャックを閉じる
完全に閉じきると開ける時大変なので閉じ具合はお好みで
チャックがプラ製の奴を選んで買うこと。
チャックが金属製の奴は他の洗濯物に傷入れる場合があるので要注意。
↓避けるべき添加物
・蛍光増白剤
嫁が青白くなる。
避けた方が良さげ。洗い上がり微妙。
印刷こそ無事と思われるが、
色柄モノにこんなもん突っ込むバカは居ないと思うが、
洗濯槽クリーナーがガッツリ残ってたりとかのパターンに気を付ける。
・柔軟剤を適量使う
汚れがそのまま残って変色の原因になったりする。
・いきなりお湯洗いしない
お湯で洗うと血液系の汚れが凝固して取れなくなる。
俺らは抱き枕とチュッチュするために寝る前に髭剃るもんで、
血液汚れは気付かずポツリと付いてたりするもんだ。
色移りの多い衣類やポケットに入れ忘れたペンとかあると悲惨やぞ。
まず前回の柔軟剤を血痕を落とすため、
頻繁に洗い替えるもんでも無いので、
サボって一回洗いで済ませたりすると変色することがある。
大事な布類にコレやるバカは居ないとおもうけど… 基本熱は加えない。
・綺麗な針金ハンガーを使う
プラスチックハンガー、木製ハンガーにはバリやササクレがあることがあるので危い。
https://www.nitori-net.jp/store/ja/ec/8500596
私は耐水ペーパーを使ってシャワーかけながら全体を#600で磨き、
下辺のみ続けてシャワーかけながら#1000、#2000で磨いた。
最後に全体をシャワーかけながらウエスでシコって砥粒を落として完成。
ここまでする意味があるかは知らん。
・陰干しする
黒人だろうが白人だろうが人間なら赤系の色になるので結論に差は無い。
赤は光に弱い色なので、嫁を美しく保ちたいなら天然日サロはやめておけということだ。
http://blog.livedoor.jp/route408/archives/52258122.html
熱湯洗いしようがタンブラー乾燥しようがそう簡単に印刷が落ちる事は無い。
でも扱いによっては表面の風合いとかテキメンに変わったりするし、
やっぱ嫁は長く綺麗でいて欲しいモンだから。
大切大切ゥ！
