  |
はてなキーワード: ストレージとは
どのオンラインストレージでも有料プランは容量も料金も似たようなもの。
でも、若干違いがあるので記載しておく。
オンラインストレージ選択の参考になれば幸いだ。
Onedrive
有料プラン1TBから。オフィスが無料でついてくるのがありがたすぎる。しかも金額は他のストレージとあまり変わらない。特にこだわりがなければOnedriveが最強。
欠点としては、アップロード時に通信速度が遅くなりすぎる。ネットしてるとイライラしてくる。
Dropboxはアップロード速度がOnedriveと同じくらいなのに遅くならないんだが。
あと、変なものをアップして垢バンくらったらどうしようかと不安になることもある（マイクロソフトのアカウントがバンされたらかなり痛い）。
以前は同期が速いのがよかったが、最近は他のストレージも速くなったのであまり変わらない。
ギャラクシーを使ってると、50GBのストレージが無料で付与される。
Boxsync
基本的にDropboxと変わらない。有料プランでガッツリ使ってるわけでなく細々としたものしか使ってないが、体感として同期速度は良い。
使ってない。
これもバンされたら怖い。Google+で子供の水浴び写真を載せててバンされたという話もあるので、使う気になれない。
写真の容量無制限が嬉しいところだが、これもバンが怖い。子供が裸で遊んでる写真とか怖くてアップできない。
本の自炊をしているので元データのバックアップとして使いたいが、大量すぎるのでアマゾンからクレームがきそうで使えない。
とにかく変なことしてバンされたくない。
通常はDropboxやOnedriveというフォルダができて、そこにデータを放り込むが、SugerSyncは適当なフォルダを同期できる。
何かしらのソフトのデータとかでマイドキュメントにしかおけないフォルダを同期するのに便利。
問題は有料プランレベルの大容量になるとまともに同期しない。いつまで経っても同期が終わらない、というか進まない。
2,3日放っておいたり、何回か同期を解除してやり直したりしたが、同期ができなかった。
現在は無料プランがなく、有料プランは他のストレージより高い。
容量10GB程度で安いプランを作ってほしいところ。
いろいろ使ってるんだが、こんなところか。
最近は外部のHDDにフォルダが作れるから、デスクトップに8TB HDDとか装備してやると複数のストレージを使い倒せる。
あとは、なんかの拍子に同期に失敗して全データが消えることもあるかもしれないから、バックアップは定期的にしてる。
もしかしたら情報が古くて間違ってるところもあるかもしれない。
違ってたら修正求む。
下記書籍を読んだ。今後のために、得られたことを整理して文字列化した。発信したくなったから匿名ダイアリーに投稿。 高木 繁治 (監修)，"脳のしくみ―脳の基本構造から記憶のあり方まで"，主婦の友社，2010． 脳 人間の生命活動を総合的に制御する重要な器官 大きく分けて 大脳 人間の知的活動にとって最も重要な，思考・知覚・記憶・言語・運動などの働きを担う 小脳 身体各部の運動が正確に行われるよう調整するのが主な役割, 平衡感覚も 脳幹 呼吸、血液循環、体温調整、代謝など、生命活動の維持 神経細胞（ニューロン）、それらをつなぐ神経線維が多数 支持・栄養補給のグリア細胞 大脳 三層 古皮質 旧皮質 新皮質 古:爬虫類の脳, 旧：旧哺乳類の脳 本能的な情動にかかわる大脳辺縁系 運動にかかわる大脳基底核 新：最も人間的な部分 大脳辺縁系 細かく見ていく 短期記憶蓄積 海馬 好き嫌いや怒りなどの感情 偏桃体 意欲に関係深い 側坐核、透明中隔 快・不快で行動意欲につなげる 帯状回 各器官をつなぐ 脳弓 食欲や性欲などの生存本能 恐怖や好き嫌いなど人間の本能的な感情 偏桃体は「情動の中枢」、好き嫌い、快不快、原始的、動物的感情を生む 左脳、右脳 小脳 身体を使って覚えたことは小脳に記憶 反復練習で正確に 脳幹 命の座 大脳、小脳、延髄をつなぐ 器官 間脳（視床、視床下部） 中脳 橋 延髄 など 心拍、呼吸、血液循環、体温調整 大脳が意識的な活動の中枢であるのに対し、脳幹は無意識的な生命活動の中枢 視床下部にぶらさがる脳下垂体 視床下部の指示のもと、ホルモン分泌 前葉 成長ホルモン 甲状腺刺激ホルモン 副腎皮質刺激ホルモン 生殖腺刺激ホルモン プロラクチン 後葉 オキシトシン バゾプレッシン その他 利き手 男女の脳 脳梁 女性のほうが太い 前交連 視床間橋も 左脳と右脳両方を連携して話す, コミュ力高 など 神経細胞, グリア細胞 情報伝達 神経細胞 大脳に140億 小脳に1000億 脳全体 千数百億 情報ネットワークを形成 構成 樹状突起, 他の神経細胞から情報を受け取る 軸索 樹状突起の一番長いもの、他の神経細胞との連絡, 神経細胞同士が結びついて情報が伝達され、新たな結びつきができることで”記憶”として蓄えられる 細胞体 心臓部 グリア細胞 接着剤 サポート 最近の研究では、グリア細胞も情報伝達に加担？ 神経細胞 情報伝達 電気信号 軸索 シナプス 神経伝達物質 電気信号の伝播 細胞膜 イオン チャンネル開閉 膜内と膜外とで電位差 電位差が隣に影響を与えそっちでも電位差 軸索を伝搬 軸索を髄鞘が覆っているかどうかで、伝搬速度も変化 情報伝達2 単一神経細胞内においては電気信号で伝達 神経細胞間のシナプス間隙では神経伝達物質で伝達 神経系 中枢神経 脳 脊髄 末梢神経 体性神経 感覚神経 運動神経 自律神経 相反する2種の拮抗でバランス ホメオスタシス 交感神経 興奮緊張 副交感神経 弛緩抑制 心 人間の心はどこにあるか 近代に入るまで：心臓 今：脳が重要 感情 人間だけがもつ特有のもの 親しみ 同情 憎しみ 羞恥心 動物的なもの 空腹が満たされたときの快感 睡眠不足の不快感 生命を脅かすものにあったときの恐怖、不安、闘争心 人間的な感情と区別して”情動”と呼ぶ 情動 視床下部 生物としての欲求、生存本能 食欲 睡眠欲 性欲 偏桃体 快 不快 怒り 恐れ 視床下部×偏桃体×海馬×外部からの情報＝情動 怒りや恐れで生理的変化 交感 増 副交感 減 情動だけでは暴走してしまう。大脳の前頭連合野で理性的に制御 感情の情報を大脳に伝える 偏桃体が喜怒哀楽などの感情を判断すると、脳内ホルモンという神経伝達物質によって、大脳皮質まで伝達 脳内ホルモンの分泌コントロール：モノアミン系 神経細胞の集合 モノアミン系 A 1-7 ノルアドレナリン 8-12 ドーパミン 6は怒りの中枢 10は人間にしかない C アドレナリン B A,Cを抑える ホルモンが脳内に伝わって、緊張や興奮などの生理的変化を身体にもたらす 感情は脳内ホルモンによって引き起こされるといってもよい 役割 ドーパミン 快感、幸福感を増幅、意欲・運動調節・ホルモン調節 ノルアドレナリン 怒り、不安、恐怖の感情、覚醒、記憶 アドレナリン 恐怖 これらにたいして抑止的に作用する神経伝達物質 セロトニン 睡眠、体温調節、生理的機能、過剰な興奮や衝動・抑うつ感の軽減 不足するとうつ状態 片頭痛の発症にも関与？ 幸福感の源 本能的な欲求が満たされたとき。動物全般にみられる ほめられる、試験合格、コンテスト優勝、新しい知識獲得 目標達成。小説が波乱万丈の末にハッピーエンド 快の感情を追求することが、まさに人間らしい幸福感であり、ひいては人類の進化につながる ドーパミンがその原動力 主な神経伝達物質 モノアミン ドーパミン ノルアドレナリン セロトニン βエンドルフィン アミノ酸 γ網の酪酸（ギャバ） グルタミン酸 アセチルコリン 神経ペプチド ストレス ホメオスタシス 病気やケガ、不快環境、トラブル、経済的不安といった原因（ストレッサー）から何らかの圧力を受けていると感じ、それに反応して心身が緊張している状態を指すのがストレス ストレスを感じると 脳内ホルモン分泌 → グルコース（身体のエネルギー源）の生成を促進 交感神経活性化 → 緊張が高まり、はたらきが活性化 ストレスから抜け出せず、長期間バランスを崩していると 睡眠障害、学習能力低下、集中力低下、感染症など 心拍数増加、血圧・血糖値の上昇、気管支拡張、思考力低下 ストレスの進行度 1. 警告期 ストレスに備えるべく活性化 2. 抵抗期 ストレスの原因と闘う時期 3. 疲労期 ストレスから抜け出せないと疲労期。糖質コルチコイドやアドレナリン、ノルアドレナリンなどが過剰に分泌されるために起こる。私たちがストレスを強く意識するのはこの時が多い ストレスは本来、外からの物理的、心理的圧力に備え、克服するための脳や身体の反応 ストレスが日常的にあっても不自然ではない ストレスのレベルが高すぎても低すぎても生産性は落ちることが証明済み 適度なストレス必要 定年後に燃え尽きてしまう人は、ストレスが少なすぎだからかも 必要なストレスでも、慢性化すると心身に変調 不安障害 強い恐怖感 動悸 息苦しさ めまい パニック障害 強迫観念へのとらわれ 強迫性障害 PTSD 人間が幸福を感じるとき、大脳辺縁系の帯状回にあるスピンドルニューロンという神経細胞が活性化し、細胞が伸長する いったん長くなると、不幸があっても縮まない 長い分だけ幸福感が持続する 幸福体験を重ねるほど伸び続ける ストレスに対しても強い抵抗力を持つ と言われている くよくよしないで前向きに考えることは脳を活性化し、免疫力を高め、病気を悪化させない効果につながる 恋愛 性欲 視床下部 第一性欲中枢 セックスを求める機能 第二性欲中枢 セックスを行うための機能 第一： 男 >> 女 第二（男）：摂食中枢のそば。空腹で生命の危機だと性欲高 第二（女）：満腹中枢のそば。失恋でやけ食いはこのため？ 人間だけがもつ感情の一つに、恋愛に関する感情 恋愛感情を起こすのは主として性欲の情動だが、それだけではない 恋愛対象としてふさわしいかを総合的に判断するのは前頭葉にある前頭連合野 言語 すべての民族に備わっている 記憶 短期記憶 作業メモリ 長期記憶 ストレージ 陳述記憶 意味記憶 一般的な知識 エピソード記憶 出来事 非陳述記憶 手続き記憶 身体で習得する記憶 プライミング記憶 無意識のうちに思い起こす記憶 エピソード記憶は、意識すれば比較的容易に思い出せる、意味記憶はきっかけがないとなかなか思い出せない 頭の中に画像を描いたり、メロディをつけたり、音読したり、語呂合わせにしたり、物語にしたてる、五感を駆使するなどすれば、意味記憶も同様に定着が可能 睡眠 体と脳の休息 夢 睡眠中に脳内で起こる仮想体験 五感 略 脳の発達・進化・老化 系統樹 魚類 両生類 爬虫類 鳥類 哺乳類 人類 大脳の神経細胞数 受精後四か月＝成人 誕生後に神経ネットワークを構築 20歳ころに完成 脳の老化は、神経細胞の変形と、脳内における密度の低下によるもの 大脳皮質の細胞数はあまり減少しない 脳幹の黒質では大きく減少、黒質は運動調節・ドーパミンを分泌、運動能力・意欲の低下 神経細胞同士をつなぐシナプスは増えることはあっても、減ることはない。記憶力や運動能力は衰えるが、思考力や判断力は衰えない 植物状態：大脳は機能停止。脳幹は機能 脳の病気 略 以上
31歳、WEB博物館の学芸員。大学の専攻はソフトウェア考古学。
行ったことのない人のために説明しておくと、WEB博物館はWEB150年周年を記念して設立された博物館で、WEBの歴史を振り返るとともに
各時代のサイトのデザインやインタラクションを体験できる日本唯一の博物館。古くは平面ディスプレイでのWEBページから、主流の空間型3次元MRの流れを体験できることが売りなんだけど、
まだ2010年~2020年代の展示が用意できていない。暫定的に、展示パネルでスクリーンショットを展示している。
この展示の担当者は俺。正直な所、ちゃんとした展示が開始できる見込みは立っていない。というのも、ソースコードはあるけれど、当時の技術背景がはっきりしないため、サイトを動かすことが全くできないためだ。
今時、平面ディスプレイなんて骨董品屋に行かないとお目にかかれないが、なぜか自宅の地下に眠っていた。
りんごのマークが描かれた物理キーボード搭載の、所謂ノートパソコンってやつ。金属ボディでかつ核シェルターに入ってたので、核戦争の時のEMPにやられずにかろうじて残っていたみたい。これを高校生の時に見つけて以来、徐々に二次元派になっていった。レトロPCマニアという区分の人間だ。
当時のソフトウェアを発掘、解析していくうちに、古い技術のソースコードを集めるのが趣味となり、大学ではソフトウェア考古学を専攻した。
大学時代にやってたことは、未処理地区に入ってストレージを発掘、残っている当時のソフトウェアを解析、当時のものを修復・復元などだ。
ここでは研究員がそれぞれの時代のWEB技術で作られた製作物を復元するプロジェクトに携わっていた。
で、俺の担当が暗黒の時代と言われた2010年~2020年代だった。
ソースコードは、骨董家から譲ってもらった。当時のサーバーやクラウドサービスは核戦争でほぼデータ消失しており、100年以上前のソースコードなんて絶望的だったが、ある企業が当時の中国のハッカー集団に抜かれたソースコードを保存していたストレージがたまたま現存していた。
開発に使われたJavaScriptという言語は、AIの解析によってバージョンが判明し、なんとか仕様が分かった。大学で近代プログラミング言語史の授業を取っておいてよかった。
とにかく、この時代はフロントエンドの開発環境の移り変わりが激しく、それぞれのパッケージが使われていた期間がとても短く、バージョンも多様に渡ることから、正解のパッケージが現存していない。
この時代は、まだIT教育がほとんどされていなかった時代でもあり、ソフトウェアエンジニアはほとんど独学で技術を身につけるのが普通で、そのためソフトウェアに対する価値観が多様であった。どんどん新しいパッケージが開発、公開され、そのため開発環境の移り変わりはとても激しく、特にフロントエンドは1~2年でガラリと変わっていたようだ。
すると、1~2年しか使われなかったパッケージなんて入っているピンポイントな生存ストレージなんか見つかるはずもなく、全然開発環境の復元が進まない。
別バージョンのパッケージが見つかることもたまにはあるので、それで代用を試みるけど、エラー文が多すぎてほとんど使えない。
当時の人は、やたら保守性にこだわっていたみたいだけど、こんなバージョン地獄でうまくやっていたのだろうか。
「わかったぞ！」
「わかりましたか」
「完全にわかった。
エロ漫画コレクター、江口快楽天氏（享年46歳）を殺害した犯人がな！ 江口夫人の淹れてくれたお茶を飲んでピンとひらめいたよ。残念ながらキミの出る幕はなさそうだ、探偵くん」
「では、警部の名推理を拝聴しましょうか」
「見ろ。江口氏は『至近距離で真正面から』『刃物でめったざし』されている。
なのに、抵抗した痕跡がない。
被害者は刺される直前まで犯人に対して油断しきっていたんだ。つまり、顔見知りの犯行だな。
被害者が風呂上がりでタオル一枚の素っ裸だったことからも、それが伺える。
となれば、事件当夜に現場となった江口邸内にいて、かつ被害者と最も親しかった人物――結婚十年目を迎えた妻の薔薇族氏（41歳）、夫婦の一粒種である絵留王くん（18歳）、古くからの親友であるボブ・ディラン氏（75歳）の三人に絞られる。
被害者は毎日決まった時間帯に入浴していた。犯人は湯浴みをおえた被害者を彼の書斎で待ち受けて凶行に及んだとおぼしい。この時間帯とその直後にアリバイのない人間が犯人だ。
容疑者三名のうち絵留王くんは自室で夏休みの宿題――ゆうちょアイディア貯金箱コンクールに出品するための貯金箱づくり――に励んでいた。その姿は他ならぬ君によって目撃されている。
奥さんの薔薇族氏は近所の奥様方と夏コミ同人誌製作の追いこみをしていた。
アリバイがないのはゲスト・ルームで作曲をしていたディラン氏だけ。
彼こそ犯人だ！」
「警部。落ち着いて。
それに『正面からめったざし』なんですよ？ 被害者氏は即死したわけじゃない。
いくら親しかろうが、殺意むきだしで襲い掛かってきている相手に対してまったく抵抗しないなんておおかしいでしょう」
「む、むう。言われてみれば……では、外部犯の可能性が否定できないということか。またふりだしからだな」
「いえ、警部の目のつけどころはいいと思います。
犯行の難しさ、内部犯であろうと外部犯であろうと一緒です。
ただ、なにか……欠けているピースが……」
「そうか！ 警部、被害者の左手に握られたものを見てください」
「左手？ おっ、この人間工学に基づいたハンドグリップとモノリスの叡智を思わせる漆黒のボディーは……
「そのとおり。
紙のように薄く感じられるよう、これまでの Kindle よりも20%以上軽く、平均で30%も薄くなり、人間工学に基づいた、左右で薄さのことなるデザインを採用、最も薄い箇所でわずか3.4mm。
それでいて、高剛性プレーティングを施したフレームと kindle 史上最強のカバーガラスを採用し、軽さを追求するとともに、いつでも気軽に持ち歩ける耐久性をも実現した Kindle 最新にして最強のニューモデルです」
「ぶっちゃけ、容量とCPUが旧モデルと変わんないから要らないと思っていたが、
こうして直に触ってみると超欲しくなるな。しかし、これがどうかしたのか？」
「警部、その Oasis にダウンロードされている書籍をチェックしてください」
「おう。……んん、立ち上がりが遅いな。
やはり性能が……うわっ」
「フフ。そこに表示されているのは、無修正のエロ漫画ですね？ しかも一番破廉恥なシーン」
「！？ なぜ、画面を見もしないでそれを！？」
「奥さん。この kindle は被害者本人が購入したものですか？」
「い、いえ。それは絵留王が主人の誕生日プレゼントにと昨晩渡したものです。あらかじめ容量いっぱいに購入していたエロ漫画といっしょに」
「でしょうね。つまり、絵留王、キミが快楽天氏殺害の犯人だ！」
「警部。死体をよく見てください。被害者は俯けに倒れているのに、タオルは尻の上にかぶさった格好になっている。おかしいとは思いませんか？ 普通、タオルを腰に巻いたまま倒れたなら、タオルはちんこと床のあいだに挟まれるはずです。
もうひとつあります。遺体発見当時、風呂場から現場となった書斎へ続くカーペットに足跡や染みは見あたりませんでした」
「な、なに？ なぜ教えてくれなかった」
「訊かれませんでしたから。
そして、これが一番重要ですが――なぜ風呂上がりの被害者の手に kindle が握られていたか、ということです」
「風呂場で使ってたんじゃないか？ kindle は防水機能もピカイチだからな。Waterfiの加工が施され、完璧な防水加工となっている。真水でも海水でも、ともかく200フィート以上の深さに時間無制限で耐えることができる。たとえばスキューバダイビングにでかけて、海の底に腰を落ち着けながら『海底二万里』を読むことができるわけだ。これはちょっとした「経験」になり得るかもしれない。」
「その割に kindle 本体に水滴はついていません日本人は臆病だから、風呂場で読むなら絶対ジップロックに入れますよ。しかしそのジップロックの形跡も見当たらない。
わかりますか、警部？ あらゆる証拠が『被害者は風呂に入っていなかった』ことを示唆しているのですよ。
では、風呂に入ってなかったとすれば何をやっていたのか。なぜ kindle oasis がここにあるのか。
裸族でも風呂上がりでもない大の男が裸体を晒す理由――となると、ひとつしかありませんね」
「！！ オナニーか！」
「新しいテクノロジーを手に入れたら、まずエロいことで試したくなる。おっさんに普遍の心理です。
「わかるなあ。だがね、探偵君、風呂がオナニーになっただけで何が違うのかね」
警部は、風呂に入るなら自慰行為をやる前がいいですか？ やったあとがいいですか？」
「そりゃあ、した後だろ」
「そう。被害者は風呂に入る前にkinオナを行っていた可能性が高い。
犯行の推定時刻が『定時の入浴直後』から『定時の入浴前』にずれるわけです。この差は大きい」
「そうか、入浴中〜入浴後にあった絵留王氏と薔薇族氏のアリバイが崩れるわけだな」
「そして、もう一つの大きなメリット。それこそ今回の大きな謎を説明するものです。
『真正面から抵抗を受けずに何度も刺す』ことを可能にしたのです！！！」
「おお〜〜〜〜！！！
って、い、いや、待ってくれ探偵くん。
いくら自慰中だったからといって、刺されてるのに気づかないのはいくらなんでもおかしいぞ」
「……警部。あなた、さっき Oasis を立ち上げたときになんて仰ってました？」
「えっ？ たしか、『立ち上がるのが遅い』と……ああああああ！！！！」
つまり、書庫がほぼ満杯ならマンガのページ送り速度はイライラするほど遅くなるのです！
これはkinオナにあたっては致命的な欠陥となる！
「そのときに発揮される強力な集中力！ そして分泌されるアドレナリンが被害者に『刃物で刺されている』痛みを認識させなかったんだ！」
ところで、ディラン氏、江口快楽天氏はオナニーするときは全裸になる派でしたか？」
「いや。いつもズボンとパンツだけを脱いでいた。『全裸オナニーなど文明化されてないサルのやることだ』とね」
そう、犯人が衣服を持ち去ったからです。どうしても『kinオナの最中に殺害した』と思われたくなかった。
それはアリバイ工作のためでもあり――そして、Oasis が自らと結びつくことを過剰に恐れたからだ。
絵留「……証拠は……あるのかよ？」
探偵「あなたが部屋で作っていた貯金箱……私も直に見て驚きましたよ。
――血の付着した衣服があしらわれているんですからね！」
“！？"
探偵「工作に使ったハサミを鑑識に回せばそれが凶器として使われたどうかはわかります。刺すだけではなく、遺体から服を切り離すのにもつかわれたのでしょう」
絵留「……ｸｿｯ……俺の負けだよ……」
警部「しかし……なぜだ。絵留王くんはエロ漫画読書界のホープとして、父子鷹でがんばってきたんじゃなかったのか？」
探偵「まさしく快楽天氏の英才教育こそが今回の動機なのでしょう。ですよね？ 絵留王さん――いや、絵留王ちゃん？」
絵留「！？ ……フッ、名前とヤドクガエル先生の描いたような外見のせいでたいがい勘違いされるんだがな。すると俺の『本当の年齢』も知っているわけか」
探偵「ええ。あなたは18歳じゃない。戸籍上はまだ小学生のはずです」
探偵「いかにも。貯金箱コンクールの応募資格は『小学生のみ』です。いい大人が夏休みの宿題に作るようなもんじゃありません」
警部「だが、なぜ江口一家は絵留王ちゃんがあたかも18歳であるかのようにふるまっていたんだ？」
探偵「さっきご自分で仰ってたじゃないですか。『エロ漫画読書界のホープ』だったって。エロ漫画を読めるのは何歳からですか？」
警部「！？ まさか――」
絵留「……そうだよ。あのクソ親父は、この12年ずっと俺を『18歳の成人男子』として扱ってきた。まだハイハイもおぼつかねえころから、朝から晩までエロ漫画、エロゲ、エロ同人漬け……。
冗談じゃねえ……俺には俺の人生がある。健全な小学生の女児としての、な。あいつは結局こどもを愛してなんかいなかった……」
探偵「……それは違います。絵留王ちゃん。なぜ快楽天氏はクソ性能の Oasis でオナニーをしていたと思いますか？ 彼ほどのエロ漫画マニアなら、さっさと合理性を優先して、紙の書籍に切り替えてたはずです。しかし死ぬまで Oasis を手放さなかった――」
絵留「……え…まさか……プレゼントだったからだっていうのかよ？ 俺からの誕生日プレゼントだったから、どんなクソ性能でも使ってたんだって……
そんな……オレは…‥じゃあなんで……うわあああ〜〜（泣き崩れる」
「今回もイヤな事件だったな……」
「kindle は使うものによって悪にも善にもなります。エロ漫画もまたそうなのでしょう」
「そうだな……わかっている……わかっているが……くそっ！ やりきれない……」
「ぼくも同じ気持です……もし彼らが kindle Oasis ではなくアレさえ持っていればと思うと」
「アレとは？」
「フフフ、これですよ（ﾊﾞｯ」
「あ、黒いシルエットを燦然と穿つ青白い光！！！それは、君、『kindle paperwhite のマンガモデル』じゃないか！」
「いかにも！ 通常の Paperwhite の8倍、32GBのストレージを実現し、マンガなら約700冊を保存可能！
快速ページターン機能を使えばマンガのページおくりのスピードが33%アップします！
さらにはピンチ＆ズーム機能で細部まで書き込まれた作品でも簡単に拡大が可能！
まさにマンガ大国ニッポンのために生まれた読書デバイスです！」
「なんてこった、これさえあれば今回の被害者も刺されたときにすぐに気づいて、ちゃんと娘と話し合いの場が持てたはず…‥」
「起こってしまったことは変えようがありません。しかし、新たな悲劇を防ぐことは……あれ？ 警部、どうしたんですか？ ニヤニヤして」
「フフ、こんなこともあろうかと私も既に購入していたのだよ。マンガモデルをな！ ほらここに」
警部！
それ、ダイナマイトですよ！」
「ば、爆発する〜〜〜！！！」
ドカーーーーン！！
「う、うーん……あれ？ 生きてる。警部も……」
「どうやら助かったようだな……」
「！？ 警部！ あの断崖の上ッ！」
「あ、あの人影はッ！」
（慈愛に満ちた微笑みを浮かべて立ち去っていくボブ・ディラン）
「……助けてくれたのか」
「おそらく、ノーベル賞委員会の刺客が警部の気づかないうちにマンガモデルとダイナマイトをすり替えていたんでしょう。あの場に居合わせていたディラン氏を爆殺するために……」
「あの屋敷に刺客が？」
「警部が冒頭で飲んでいたお茶、あれを手渡すときにすりかえが行われたのでしょう。お茶にアンフェタミンを混ぜることで警部の注意を散漫にさせ、違和感に気づかせなかった。
興奮作用で普段はにぶい警部が突然推理をひらめいてしまったのです。
それをきっかけに事件がスピード解決したせいで、かなり遅れてダイナマイトが爆発した」
「まさか薔薇族夫人がノーベル賞委員会の手先だったなんて…‥なんてやつらだ。ん？ 待てよ？
おい、今は2017年8月だぞ。ノーベル賞授賞式はもう去年の暮に終わったじゃないか。
結局、ディラン氏は会場に来なかった。
「警部。ボブ・ディランは信義の男です。
彼は一度結んだ約束を絶対に違えない。
授賞式に行くといったならば、かならず来ます」
「しかし現に――」
「現にディラン氏は去年の10月に『授賞式に来るか？』と訊ねられて、なんと答えていましたか？
『行くとも。可能ならね』ですよ。
――ことばどおりなら、彼には『行くことが不可能になる』可能性があったことになります」
「それが委員会による妨害工作だと？ ノーベル賞委員会はディラン氏を授賞式に出したかったんじゃないのか？
そのために受賞スピーチは代わりに歌でやっていいだとか、さんざん譲歩してきたんじゃなかったのか。
そもそもディラン氏を殺して彼らに何の得があるんだ？」
「ノーベル賞委員会はひとまとめにされがちですが、実態は各カテゴリーごとに分かれていて一枚岩じゃない。
特に文学賞はスウェーデン・アカデミーが担当しており、科学関連を司る本家スウェーデン王立科学アカデミーからは独立しています」
「違うとはいっても、同じスウェーデンのアカデミーなんだろ？ そんな喧嘩する理由が……」
「あるんです。王立科学アカデミーを設立したのはフレデリク一世。スウェーデン・アカデミーはグスタフ三世です。対立の歴史詳しく説明すると長くなるので省きますけれど、簡単にいえば、二つのアカデミーのもつ「本家」意識のぶつかりあいですね。
『元祖』である科学アカデミーにあの時の騒動に苦々しい思いを抱いていた。ポップ歌手風情に受賞させた上に、ノーベル賞全体の権威をコケにされたわけですからね。
だから、彼らはこう考えた。
『授賞式にこさせなければ、受賞はできない』。
殺してしまっては『死後受賞』になるので授賞式まで生かさず殺さずにしようとしたんです。
もっとも、ディラン氏は3万9211人のノーベル・ニンジャ部隊を相手に傷一つ負わなかったようですが――
ともあれ、目的は達成された。彼は2016年の授賞式に現れませんでした」
「だったらこれ以上ディラン氏に関わり合いになる必要はないじゃないか。何も殺すなんて……」
文学賞を二度獲った例はありませんが……ライナス・ポーリングの例を考えてみてください。
彼は54年に科学賞、62年に平和賞という異なるカテゴリーで受賞をはたしています。
愛と平和を歌ったボブ・ディランなら――いつか『平和賞受賞』もありうる」
「そうか。平和賞だけはスウェーデンじゃなくてノルウェーのノーベル委員会の管轄だから……」
ふだんからちゃらんぽらんな選考をしている平和賞委員会ですから、なおさらね」
「だから二度目の受賞――平和賞に選ばれる前にディランを殺そうとした」
「そう、本年度受賞者が発表される１０月までに、ね。去年四万人近い手駒を失ってしまった王立科学アカデミーには、今年のディラン氏の来瑞を止める手立てはありません。
ディラン氏は今度こそ授賞式に現れることでしょう。それが『可能』なんですからね」
「今回の事件も実はディラン氏が発端だったんです。
江口夫婦のうち薔薇族夫人は科学アカデミー側の人間でした。かたや夫の快楽天氏は文学アカデミー側。二人は敵対する組織に属しながらも愛によって結ばれた、いわばノーベルロミオとノーベルジュリエット。
ところが、夫がディラン氏を科学アカデミーの刺客から匿うことに決めたとき、調和は亀裂が走った。
彼女が何より許せなかったのは『自分への愛』より『ディラン氏への愛』を選んだことだったのかもしれません。その憎しみが彼女の心を悪魔に変えた。
考えてみてください。
いくら教育法に難点があったからといって、小学生が父親を殺そうとしますか？
そう、絵留王ちゃんは悪魔から禁断の果実を知らないうちに与えられてしまっていたがために、あんな凶行に及んだのです。
「娘を薬物で操ったのか……」
「夫人の親玉は世界に冠たるスウェーデン王立科学アカデミー……薬物の調達くらい、朝飯前でしょう」
「彼女は実の母親ではありません。快楽天氏と薔薇族夫人が結婚したのは十年前。絵留王ちゃんは十二歳です。
……警部、絵留王ちゃんの面立ちは誰かに似ているとおもいませんでしたか？ 快楽天氏でも、夫人でもなく――」
「――ボブ・ディランに！」
「快楽天氏は十二年前は『彼』ではなく『彼女』でした。絵留王ちゃんはボブ・ディラン氏と（当時女性だった）快楽天氏とのあいだの子供だったのです！」
「そんな……娘も夫人にとっては憎しみの対象だったのか」
「あの一家もまたノーベル賞騒動の被害者なのかもしれません……」
「いや、最も憎むべきは……
アンフェタミンだ！
こんな薬物さえなければ……」
「安易な薬物乱用の恐ろしさを学びましたね…‥。
薬物乱用は、単に乱用者自身の精神や身体上の問題にとどまらず、家庭内暴力などによる家庭の崩壊、さらには、殺人放火等悲惨な事件の原因にもなり、社会全体への問題と発展するといいます」
「そうだ……薬物は、使用しているうちにやめられなくなるという"依存性"と、乱用による"幻覚"、"妄想"に伴う自傷、他害の危険性がある。
一度だけのつもりがいつの間にか中毒となり、一度しかない人生が取り返しのつかないものとなるのだ……」
「このような薬物乱用の恐ろしさを十分に知っていただき、薬物乱用問題を考える際に以下のサイトを参考にしていただきたいと思います。
「完」
http://anond.hatelabo.jp/20150911124102
ただしズバリこの曲が聞きたい！という大ヒットスタンダードはけっこう入ってなかったりする。
BGMでいろんな曲を聞き流したい人にはけっこう良いと思う。
データはAndroidでSD移動が可能。契約切れると利用できなくなるけど、再契約でそのまま利用可能らしい。
Amazon kindle unlimited
unlimitedの本ばかり集めたページが見つからない。
無料ということであれこれ試し読みする、という使い方ができない。
ストレージもメインメモリ限定でAndroid端末利用者・自宅WiFi環境非保持者には優しくない。
けど１冊を聞き終えるにはすごく時間がかかる。
本屋で10分で流し読みするような本を聞くのに６時間のデータ。
紙の書籍なら流し読みしつつ前後に戻って内容確認もできるけど、音声データだと一度聞き外すと戻るのが億劫、意識が外れる一方になる。
書籍の実物を持ちつつ聞くならいいのかも。
聞き放題で聞いて元を取れるほどではない気がした。
Audible自体、大好きな書籍を繰り返しリピートで聞く以外には自分にはめぼしい利用方法が思いつかなかった。
聞く、というコンテンツ自体は期待をしているジャンルなので、今後に期待。
来月はApple Music？を試す予定。
来る10月1日～2日に開催される某アートイベントに、知り合って1年ぐらいの友人と共同で出展するのだけども。
先日電話した時、5年後に漫画家デビューする！と高らかに宣誓しておったその友人は昨年に引き続き2回目の出展、自分はこのイベントへの出展は初めて（二次創作の同人はやってるよ！）。お互いイラストが得意なもので共同でグッズ制作をして展示販売しようというもの。
一緒に出ようね！という話はその1年前から出ていて、本格的に申し込みを決めたのは7月の話。当落の発表は友人宛に1ヶ月前ぐらいに来てたはずなんだけど…。
モヤモヤ～と、友人が言う「昨年は自由な収入が少なく自家印刷や手作りの作品しか作れなかったけど、今年は印刷所に発注する形で本格的なものを作りたい！」というイメージだけが先走っており、なんとなくの案しか出ず開催3週間前の9月上旬にやっと制作物の詳細を決めた。だいたい印刷所にグッズを頼むのは、特急とかそういうのを除いて1週間～10日ぐらい納期をみておかないといけない。
こちらからは一応ほぼ毎日進捗報告してたし、私がやる分は一昨日ぐらいに仕上がってたんだけど、開催1週間前近くなった昨晩になっても友人分の原稿が1/3ぐらいしかあがっておらず、「さすがに今日ぐらいには発注しないと当日に間に合わないぞ」と連絡を取ったところ、今日の昼ぐらいに「作業用のクラウドストレージにファイル入れておいたので確認して」との返信。何件か新しいファイルが有ったのだけど、朝3時とか5時とか表示されているタイムスタンプを見るにどうも昨晩貫徹したっぽい……。
もともとその友人は自分の身体の弱さについても言及しており（実際、以前漫画の原稿で徹夜作業をして入院までしてたとか、それ以来ちょっと無理すると翌日すごく具合が悪くなるようになったとか）あまり強くは言えなかったし、もしかしたら他所に提出する漫画の原稿を同タイミングで抱えていたのかもしれない。
いや、twitterでもLINEでも一切そのような話（今抱えてる案件とか、体調とか）をしてなかったので知るよしもないんだけど……。
社会に出て半年も経てば、納期意識って多少ついてくるんじゃないか、漫画描きを本気でやるつもりなら締切の意識って持ってるはずじゃないのか。
そりゃ知り合って1年しか経ってないかもしれないけど、共同でプロジェクトを進めるならお互い他にやらなくちゃいけないこととか、体調がどうだとかそういう情報はシェアすべきじゃないのか。
どうなんだろう。
進捗どうですか、と聞いても、数十時間後にこれ終わりましたという結果しか返ってこない。ぶっちゃけ友人とは言え他人なのだし、どこまで踏み込んだ話を聞いていいのかもわからん。
まぁ、そういうやり取りが出来ない相手なら、一緒にプロジェクトを行うべきでない、と言われればそれまでだけど。
自分は同人誌・グッズ制作経験ありなので、印刷会社でこのグッズを作るには何日かかるよ、という情報は相手に開示したはずだったんだけど。
申込みは友人で、印刷会社のアカウントを持ってるからとグッズ発注を請け負ったのは自分。これ、どっちが悪いんやろね。どっちもやろうね。
年1開催なんだから次に作るものなんていつでも決められただろ、万が一原稿先走っててイベント出展の抽選落ちたとしても別の形で公開すればよかっただろ。もっと早く色々着手できたんじゃないのか。こっちは四半期に1回締切に追われてんねん。
http://style.nikkei.com/article/DGXMZO07281760V10C16A9000000?channel=DF260120166490
って言う記事を読んで、割りと頷ける部分は多いんだけどやっぱり商業ライターなのでバッサリ切れてないところがある（メーカーに気を使わなきゃならんだろうし）。たしかに多角的に見るのは公平だと思うんだけど、日本は大学生のPC所有／利用率が低いなんて言うニュースもあったし、ノートPCを買わなきゃいけない人もいると思うので、私見でバッサリ感のある記事を書いてみようと思った。
・CPUはわりとなんでもいい。Core i3～Core i7とかがいまの表記なんだけど、Core i5,Core i7,Core Mなんでもいい。極端に古くなければ困らない。
・メモリは４Gほしい。ちょっと詳しい人がせめて８Gとかいいだすけど、初めて買うノーパソなら４Gで十分だ。
・ストレージの容量も、あんまり気にしないでいい。でもHDDよりはSSDにしとくべき。これは記事の通り。CPUで２世代分くらい体感早くなる。
・光学ドライブとかいらねえですよ。めったに使わないし、もし使う場合は外付け買うとか、どっかでデータ読ませてもらうとかした方がいいよ。
・A4かB5ノートにしとけ。でかくて重いノートを家でデスクトップ代わりに使うとかもったいねえ。家で広い画面で使いたければ記事にあるようにディスプレイとマウスでも買っとくほうが安くて快適。
・この条件で７万前後なら概ね性能で不満は出ないと思われる。この性能なら、ネット見たりレポート書いたりWebみたり、休日にYoutubeしたり、あるいはSkypeで喋ったりしても、ぜんぜん余裕はある。おそらく今のノートパソコンの更新ペースから行って、大学４年間使っても困らない。
・CPUをCeleronというのかATOMというのにしてストレージをeMMCってのにすると、急に４万を切ったりもする。
・さすがに性能面では上に及ばず、動きがもっさりする。が、ネット見たりレポート書いたりWebみたり、休日にYoutubeしたり、あるいはSkypeで喋ったり出来ないかというと、多分全部できる。ただそれぞれがもっさりしてて作業モチベに悪影響があるくらいだ。でも、ノートパソコンを持ってないよりは遥かに良い。４万円だして、とりあえず買ったほうが良い。
・キーボードのついたPCのスキルなんてスマホやタブレットでは身につかないので、そこは別物だと割り切るべき。PCは「なんか楽しいものを見聞きできるモノ」じゃなくて「作業用の道具」なので。
・１０万円以上のノートパソコンは、PCが好きな人、すくなくともPCがある程度わかる人向けだと今は思っておいて良い。狙いは「その１」の６～８万円のにしておこう。それでももっといいのが欲しい人は↓
・おしゃれな使い方がしたい人はMacbookAirでもかっとけ。
・そうじゃねえならSIM挿せるのは費用対効果がいい（おすすめ）。挿せる機種少ないけど。
・格好いいパソコン持ってても彼女は出来ねえぞ（俺調べ）。肩を並べてレポート作成デートとか都市伝説だから。
・彼女がいるっぽい雰囲気（とか、出来たときの予行演習）をつかむためには、可愛いデザインのUSBメモリでも買っておけ。５００円とかあるから。
USB給電の問題ならハードかソフトが原因の切り分けが必要だけど、5年も使ってるならやっぱりまずは一度クリーンインストールだろうね。
ところでデスクトップなのかノートなのか書いてないからわからないけど、どっちにしてもSSDは2.5インチ規格なのでどちらでも問題なし。
SSDといっても基本的にはHDDとケーブルもコネクタも同じ規格なので、何か特別な処理を必要とするわけではない。
さらにストレージ換装によるメリットは、元データを削除しないで済むという点。
SSDに変えてから、元のHDDからゆっくりとデータをバックアップすればいいので、バックアップ→データ削除→バックアップ失敗発覚みたいな事故が起こらない。
最悪HDDに接続しなおせばもとの環境で起動できるので、パーツ交換の類ではかなり難易度は低い。（個人的にはCPU交換のほうが神経を使う）
簡単な手順
・購入時に付属していたインストールディスクを用意（なければリカバリディスクを作成）
・CD（DVD/BD）ドライブにディスクをセットして電源を入れる
・もとあるHDDを増設してデータを移行する（管理者権限とかあるから、ユーザーアカウントは同じ設定だと楽）
個人の使い方にもよるけど、SSDは基本的に容量が小さいので、マイドキュメント関連は場所をHDDに移動させたほうが運用が楽になる場合がある。
やったーーーーーーーーーーー！！！！大学生活最初の夏休み！！！！！！！！！！！
ということで、国立大学で理系学生ライフはじめた人の感想として、高校生のうちからこんなところ見てる人に向けて心得ておくといいことを色々書いてみます。今大人の増田さんにも昨今の大学生の一例として見て欲しいです。
これから書くことは個人の感想だし、高校時代の友人や先輩からの受け売りもあるし、さらにすべての大学に対してうまく当てはまるものではないことをお断りしておきます。というか高校生に向けた話なら今書かずに3月にでも書いたほうがいいとか、具体的な勉強方法については例えば"シケプリ"制度のある東大や横市医には全く当てはまらないとか、まあだめな所いろいろあると思います。ごめんなさい。
これ分かってないとだいぶやばいので一応書いておきます。大学入った瞬間すでに真っ白に燃え尽きてしまっててこの半期でリタイアしかけてる人を実際に見てしまってるので・・・。
1日が勉強と(睡眠OR風呂OR飯)で終わる日が何度もあります。受験の時は一応飯と睡眠は毎日とってたはずなんだけどなぁ。
これは失敗談なのですが、スマホ(もしくはSIMの刺さるスマートデバイス)は買いましょう。必須です。あなたがまだガラケーで親の承認得られないようでしたら合格直後に量販店に駆け込んでSIMフリー端末とプリペイドSIM買いましょう。ハイエンドである必要はないです。
今の大学生、コミュニケーションツールはほぼLINEの一人勝ちで、あとは若干のtwitterです。メールの時代は終わりました。私は頑なに(親の意向もあったのですが)ガラケー、しかも通話とSMSのみの契約だったのですが、そのせいでLINEを全くと言って良いほど使ってなく(一応PC上のAndroid仮想マシンとガラケーのSMSを使ってアカウントは作ってましたけど)入学直後の友達作りに完全に乗り遅れました。というわけで(別にスマホ持ってなかったのが主原因ではないですけど)今私には同学科の友人がいません。ココ重要。
もちろん友達作りだけでなく、「いつでもどこでもすぐググれる環境」を作っておくことはとても良い勉強の見方になります。もちろん重要な情報は本読んだほうがいいですけど、ちょっとしたことを最小の時間で解決できるという点において本当に便利です。
これも失敗談です。新学期が始まった直後は、サークルを宣伝するのを主目的とした(と今となっては感じます・・・)"履修相談テント"がキャンパスにたくさん並びます。履修相談とは読んで字のごとく履修について相談をすることで、例えば学内で使うwebサービスの使い方とか、要項に載ってない暗黙の了解とか、どの授業はテストが難しいだとかこの時間はこの授業をうけるといいとか、そういうことを先輩が教えてくれるらしいです。
しかし入学当初の私は、忙しいはずの先輩たちがそんな自らの時間を割いて後輩のためにいろいろ教えてくれるなんて虫のいい話があるわけ無い、全部宗教勧誘だと勝手に思って近づきもしなかったのですが、本当にいろいろ教えてくれるそうです。さらにメインの目的であるサークルの宣伝もそこまで押し売りみたいなものではないらしいです。
私は理想的な時間割を作ることに失敗し、本来1回生で終わるはずの第2外国語を2回生でもやるはめになったようです。あの時履修相談テントに行っていれば・・・！と常々思います。どうにかまだ留年条件は満たしてないと思いますが・・・。
自分用のノートパソコン持ってないなら買いましょう。必須です。入学直後ガイダンスで偉い人に「学内備え付けのパソコンが沢山あるから買わなくてもいい」みたいなこと言われましたが嘘でした。学内パソコンはたくさんありますが基本的に自分のパソコンを毎日持ち運んで毎日使います。授業の内容まとめたりレポート書いたりとかちょっとした空き時間にできます。後述するコンデジとICレコーダーの母艦としても大活躍します。
個人的にはB5サイズ程度でキーボードが打ちやすい、(自宅にデスクトップ機があるので)CPUは最重要というわけでもない、みたいな基準でアウトレットの型落ちThinkPad X250買いました。
別途PC用の手持ちバッグ持ち運ぶのが手間でなければB4サイズでもアリですし、生協で20万円とかするLet'snoteとか売ってますが、Let'snoteに期待されるであろう軽さ電池持ち頑丈さに加えて生協の手厚い補償とかを考えて価値があると思うならそれもアリだと思います。今のところ非Windowsで困る場面もあまり無い感じなので、Macでドヤリングも悪くないです(でもUSB typeCしか付いてないアレはどうなんでしょうかね)。surface持ってる人意外といますが、大学の机は得てして特に前後方向に狭いのでキックスタンドのせいであまり奥に置けないことを考えたほうがいいです。高い買い物なので、よく悩んで、量販店で実機触って、満足できるもの買いましょう。
なおOffice付属のものを買う必要はありません。まっとうな大学ならDreamsparkもしくは何らかの包括契約とかで実質タダみたいにOffice使えます。
これは私が文字書くのがすごい遅いせいでもあり、またノート写してくれる友だちがいないせいでもあり、また大学の授業というのはまあ本当に教授によって様々なので一概には言えないのですが、スライドをぱっぱっと切り替える人とか速記みたいなスピードで(でも読める)文字書いてすぐ消す人とかいるので、ノート取るの追いつきません。ただただ文章書く・話すだけの人ならパソコンやポメラでメモ取ればいいのですが、図とか数式とかいっぱい出てくるとそうも行きません。そういうとき現代の学生はすぐスマホで写真撮ったりするのですが、運悪く後ろの席にしか座れなかったりするとデジタルズームしかできないスマホのカメラだとどうしても文字が潰れて読めないことがあります。光学ズームのあるデジカメはそういう時の強い味方です。1万円前半くらいのでもいいので持ってると便利です。もちろんシャッター音は消しましょう・・・。
教授はとんでもなく重要なことを唐突にしゃべります。そういう時ちょっとでも眠くなったりボーッとしてるとアウトなので、授業中は常にICレコーダーで録音してます。万一なにか聞き逃しても後で確認すればいい、というのは精神的な余裕も生まれるので良いです。スマホで代用もできなくはないとは思いますが、専用ハードウェアは便利ですよ。PCと接続してデータ移せる機能は必須だと思いますが、外部ストレージが刺さるとかマイクが動いて指向性変わるとか電池交換が可能とか薄いとか、そこらへんは個人の好みで。
この手のものは操作感が命なので、ソフトの作り込みが良い主要3社(オリンパス・パナソニック・ソニー)が鉄板です。
紙で配られた資料はスキャン(してOCR)しましょう。電子データで配られた資料はプリントアウトしましょう。紙には紙の(直接書き込んでメモしやすい／切り取ってノートに貼れる)、電子データには電子データの(なんといっても検索性)良さがあります。
スキャナー持ってない場合、Office Lensなどのアプリで代用もできます。これはなかなかの優れもので、カメラで四角いもの撮ると自動で四角いもの検出して正面から撮ったように伸縮してコントラスト調整して読みやすくする、まで自動で行ってくれます。Microsoft純正アプリだけあってOneDriveへのアップロードもできますし、そうすればOCRも行ってくれます、これがスマホで完結する時代になったのですから恐ろしいものです。ただ自分の場合はハードオフのジャンクコーナーから動きそうなフラットヘッドスキャナ見極めて500円くらいで買いました。
プリントアウトはコンビニでもいいですが、最近は新品のレーザープリンタでもローエンドは1万円しないとかとんでもない安さになってるので、突然レポートをプリントアウトしなきゃいけなくなったりする時とかに備えて1つ家においているとほんとうに便利です。ただしこの手のローエンド品はドラムが交換できないようになっているので、つまりドラムの寿命が来たらその時点でプリンタの寿命なわけです。でもそれでも何万枚かはプリントアウトできるらしいので大学生が一人で使うぶんには全く困りません。交換用トナーもリサイクル品なら高くありません。レーザープリンタ、おすすめです。
理系と言ったら英語です(誰でも英語必須だと思いますが)。英語は何世紀にもわたって世界的なブームが続いてるので、絶対色んな場面で英語使います。東工(予定)や横国などみたいに院の授業は全部英語というのは極端な事例ですが、英語しか資料がないという場面はこれから何度も出くわすと思います。
授業で教えられるものだけでは足りないと思ったので、自ら英語に触れていくことにしました。これは私が個人的に合っていると思うやり方で、効率性とかよりも楽しさ・挫折しにくさ・"英語が嫌いにならないこと"が重点です。ちなみに海外渡航経験はゼロです。
リーディングは自分の興味ある物のネット記事とか読み漁るといいです。googleのニュース検索の中から適当にチョイスして読むとかいい感じです。
日常的に英語に触れる、という点ではブラウザやスマホやゲームやPCの言語設定を英語にするのが最高です。
つい最近ですが、持て余してるパソコンにUbuntuを英語設定でインストールしてみました。変なことするとエラーメッセージとかが英語でバンバン出るのでLinuxと英語が一挙に勉強できてヤバいです。Reboot even if system utterly broken!!
リスニングはラジオのAFN。あっBGMほしいな～といった時にちょくちょくかけます。AMの放送局とかありますがネットで聞けます。英語の冗談で笑えた時本当に嬉しいですよ。
ライティングはたまに海外の掲示板にチョロっとなにか書いたりとか、スピーキングはスマホにOKGoogleしたりとか、その程度です。
私は以上4つの定番ingに加えて、基本的な英単語について瞬間的にイメージをするというのも大事だと思ってて、P-Study systemをやっています。簡単な単語集を制限時間1.5秒とかで4択からパッパッと答えていくのが好きです。
これはおすすめするか迷ったのですが、Wikipediaの「Unicode6.0の携帯電話の絵文字の一覧」をぼーっと眺めることもあります。これも基本的な英単語を瞬間的にイメージする練習です。
Unicode6.0の携帯電話の絵文字の一覧 - Wikipedia
センター本番の英語は8割とか散々な結果で辛かったのですが、今の成績を見る限りどうにか帰国子女グループの次くらいにはできるようになってるみたいです。
レッドブルとかモンスターエナジーとか、エナジードリンクキメると本当に目が冴えますよね。でもただでさえ生活バランス崩れるのにそこにさらに追い打ちをかけるようなことはこれからはやめたほうがいいと思います。エナジードリンクは体力が増えるのではなく体力を前借りしてるだけです。生活リズム・体調が一番大事。18過ぎたら老化始まりますよ。野菜食べましょう。
運動しましょう。ネタではないです。ポケモン捕まえるためにランニングとかでもいいと思います。北大とか筑波とかだだっ広いところだとキャンパス内の散策だけでもいい運動になりそうです。体動かさない日が何日も続くと結構ダウナーになったりします。
個人的な経験になるのですが、体動かした後というのは疲れるというのよりも先に学業が捗るというのが来ます。高校までは通学に1時間とかかけてそれがそこそこの運動になってたわけで、大学のすぐ近くで一人暮らし始めて一気に運動量減ってたんですね。それで今まで運動不足という状況に陥らなかったわけです。
残念な話なのですが、学部学科にかぎらずチャラチャラした見た目・生き方の学生が存在します。ウェイはみんな早慶に行って国立のましてや理系の道に進めばもはやそういったのに出くわすことはないかと思ったのですが、大きな教室に1~2グループとか、ウェイは存在します。これは個人的にすごいカルチャーショックで大学に入ってからの悲しみランキング堂々トップなのですが、そういった生き方の人間はどこにでも一定数存在するということを高校生のうちに知っておけば、もう少しショックは減らせたのかなという思いです。
多くの講義は最後の日に試験があるわけですが、過去問を持っていると本当に捗ります。もちろん試験対策にもなるわけですが、普段の授業でも過去問を見ながら授業を受けるとどこが重要なポイントかがよくわかります。過去問なんて受験までの話だと思ってたのですがどうやらそうではないようです。
過去問の入手方法ですが、もうこれは同じ学科の知っている友人や先輩に頼むのが一番だと思います。残念ながらわたしにはそういった頼れる人がいないので、次点の手段であるインターネットを使います。
なんたるインターネットリテラシー欠如の無頓着かという話なのですが、例えばtwitterで鍵もかけずに学内でしか知り得ない情報を話すような学生というのが若干数いるので(プロフィールに大学のことが書かれてなくても、学内で起こったちょっとした出来事とかをキーワードに検索すると釣れます。教室内での出来事なら確実に同じ授業を受けている人になります。もちろんそこからフォロワーを芋づる式にたどっていくこともします)、そういったアカウントを監視して何か試験に関する情報をつぶやかないかどうか待つわけです。
ごく一部に限りますが、試験問題をアップロードしている非公式サイトなども存在したりします。むしろtwitterではそういうサイトの情報を得ることのほうが多いかも。
実験したらレポート書きます。おそらく(あなたが高校生ならあなたが思っている以上に)大学生活のうち大部分をレポート書くのが占めると思います。
「学生実験 レポート」とかググると章立ての仕方とか出てくるのでそれに従います。もしかしたら教授からなにか指定されるかもしれませんがその場合はそっちを優先します。
多くの場合目的→原理→手順→実験結果→考察→参考文献みたいな章立てで書いていくのですが、最初から順番に愚直に書いていくのはお勧めできません。実験が終わった段階で手順と実験結果は終わっているようなものですし、多くの場合教授が最重要視するのは考察です。まず原理を書いて自分が実験でなにをしたかったのかを再確認し、適当な関連しそうな事項が載っていそうな本を図書館で探して参考文献リストを埋め、本をパラパラめくりながら考察を考えていきます。次に自分が原理や考察を書いて何を学んだのかを目的の項でさもこれから学ぶかのように書き、最後に手順と実験結果を適当に埋めます。
もしWordでレポートを書く場合、"スタイル"を用意しましょう。スタイルとは段落や文字列などに個別にフォントなどを一括設定できる機能です。例えば「目的」と打ったあとその行にカーソル合わせたまま「見出し(自作)」とかいったスタイルを選択するとその行がMSゴシック12ptで「1. 目的」となってそこで改行するとスタイルが自動的に「本文(自作)」とかになってフォントがMS明朝10.5ptに変更されたりします。めちゃくちゃ便利。またページ番号も自動で入力されるように設定します。実験ごとに指定される書式とかあると思うので、それにそってスタイルを自作してテンプレートとして保存しましょう。スタイル機能、Wordにおける超超超重要機能なので絶対使いましょう。
また、とにかく何かしら文章を書いてページを埋めてレポートを書いた気分に浸りたい場合、"=rand()"と打ってみましょう。数段落の文章が自動で挿入されます。自分の場合何も書く文章が思いつかない時にこれをすると、なんだか自分がすごく文章をかける人間なんじゃないかと錯覚して結構書く文章を思いついたりします。
明るい青春、楽しいキャンパスライフなどというのは理系学部生には無縁の話です。実験・レポート・課題・自習の毎日です。もちろん自分が専門にしたいことを中心に学べるのはとても良いことなのですが。
そんな中でも趣味が1つあると、誇張でなく「生きる希望」になります。私は受験勉強に本腰を入れてから一切の趣味活動(上のリンクでバレバレです)を控えて、いざ合格した時に解禁してみると随分とそれを取り巻く環境が変わっていたのを知って戸惑ったのですが、それでも学業とは切り離して好きなものを持っていることに大きな大きな安心感を持っています。
以上、こんな感じです。まだまだ効率化しなくちゃいけないところはいろいろあると思いますが、どうにかほとんど単位は取れそうです。
JavaScript で UI を構築していると XSS がうんたらかんたらみたいな能書きをきちんと理解してきちんとやっていくのが一番よいというのはそうなのですが、 2016 年にもなってそんなことの学習に時間がしがし使うのもおかしい気がする。おかしい気がしないというそこのあなたは CPU や Flash ストレージから自作して現代風のシステム全部作っといてください。
生 PHP だけでなにかを作る人間はもうたぶんいないですし、 JavaScript での UI 構築ももうそういうものだと思っていいのではないでしょうか。 React か Angular かなんか使っとけばいいと思います。 React おすすめ。これらの現代っぽいフレームワークを使っている限り XSS のような初歩的なミスはほぼ起きません。 React の場合危険な機能には Dangerously Set innerHTML というヤバそうな名前がついていて便利です。
OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。
OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。
前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法で OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。
言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたのお気に入りの OAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。
また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法で OAuth を使っているサービスの利用者であっても、また自ら OAuth ベースのサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。
この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。
この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。
この前書きのあとは、まず OAuth のセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティのコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。
その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。
最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。
いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーが OAuth ベースのサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースのシステムの主要なセキュリティ欠陥は非常に蔓延しています。
筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。
というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。
ここで言及されている情報やリンクされている情報は今のところ既存のサービスに悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のものを破壊するのではなく改善することを目指してください。この記事は、自社サービスを不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。
この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。
まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。
ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッション・グループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。
ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザがビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。
ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的に営業部門のメンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。
トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティのアプリやサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:
上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。
さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザはインストールするネイティブアプリすべての信頼性に自分で責任を負う。
さらに
クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。
基本的に言って、OAuth のセキュリティガイドラインは、OAuth を利用する開発者がユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。
私の知る主要な OAuth ベースのサービスはほぼすべて、ここに概説した手法で攻撃可能です。
OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください！ 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者や管理者に「OAuth はもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。
OAuth ベースのサービス設計でよく見かける間違いは、ブラウザ用に、パラメータのひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティのプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザのブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリやサービスのユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローを OAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。
「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつのサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザがブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。
EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebook のユーザは全員 GMail に対して Facebook そのもののふりをすることができてしまうということです。
この問題は、OAuth エンドポイントがユーザのウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザをログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザのブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。
ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)
Citrix もこんな間違いをしています:
(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)
Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータをリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースのサービス開発者でさえも似たような状況で潜在的にヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。
サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービスは一般的にいって独自の「SDK」を提供しており、サードパーティの開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。
この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアントの機密情報を取得する脅威」に分類されています。しかしサーバがウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者は OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームが OAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
明らかに向き不向きがハッキリしていて、尚且つ向いている人が少ない開発に比べたら、運用の方が間口が広い(=向いている人が比較的多い)と一般には言われている。
この業界に入ってから数年前まで開発一筋で来て、それからつい最近まで運用チームに加わっていたのだが、とにかく他の人に比べて明らかに動けなかった。
そもそも自分は「パッと見で動いてんだったら放っときゃいいじゃん」という人間なので、毎日毎日ルーチンワークで目配せがずっと続くとか、その時点でゲンナリだった。
それから、監視対象の各機器(ストレージ・セキュリティ系アプライアンス・スイッチ等)や各種ミドルウェアはメーカーごとに仕様が違いすぎて、またその仕様も込み入っていることが面倒で、それぞれのオペレーションを覚えるのも苦痛だった。
てかそんなモノに、一体どう興味を持てというんだ？
当然、どれもこれも大まかに把握している程度に留まってしまい、そういう中途半端な理解だと、トラブった時に大変になると。
やたら読みにくいマニュアル片手に原因を探り、それでも分からないのでメーカーに問い合わせてログ提出→回答を元にオペレーション→やっぱり動かないみたいなケースが何度あったことか。
もちろん、そんな人間に重要な機器は任せられないので、自分などいてもいなくてもいいポジションに終始することになった。
そんな自分の経験から、運用業務に代表されるような、ああいう灯台守みたいな業務をテキパキこなせる人は心底凄いと思う。
個人的には運用なんてもう金輪際やりたくないけど、一つだけ、開発と違って基本何も起きなければ残業無しという点はとても魅力的なのだ。
一方、開発の「ややこしい物事を、コードやドキュメントという形で、可能な限りシンプルかつ分かりやすい内容にまとめていく」感覚が何者にも代え難いのは間違いないが、夜遅いのだけは本当に何とかして欲しい。
昔、一人屋台で小さく短い開発案件ばかりやっていた時は比較的時間の自由が効いたけど、今はもうそんな仕事ないし。
