  |
はてなキーワード: Docsとは
なんかゲーム記事とか英語圏でも色々情報が出てるようなのでまとめてみる
箇条書き
・集会所でクエスト受注してフィールドに移動して最大4人で狩るというゲームの基本部分は一緒
・クエストの途中で信号弾を上げると他のハンターに募集がかかる（★足りない人は入れない
・HP・スタミナはある（なんか通常時は消えてるらしい。ダメージ受けたりすると表示される？
・スリングというツールがある。石を飛ばしたりワイヤーを出せる道具
・石はフィールドで拾ってそのまま使う
・導蟲という蟲がいて、モンスターの足跡などを探知して場所を知らせてくれる（PVの緑色の光
・導蟲を使ってモンスターを見つける。アイテムも見つける（採取ポイントかな？
・一応普段のモンハンと同じようにエリア毎に番号が振られてるらしい。
・尻尾は切れる
・フックショットを使って表面をはじき飛ばすことができます←Google翻訳ではわかりませんでした（笑）
・ベースキャンプにファストトラベル可能（鳥型恐竜を呼んで移動？
・ベースキャンプで武器防具チェンジ可能（クエスト中に装備変えれる
・弾の種類と弾薬切り替えはあり
・デモでやったのはチュートリアルで、クエスト提供者の顔を表示したワイプが右上に出ていた。
・スピンオフではない。
・開発期間は4年
・もともとはモンスタハンター5だった
・ベースキャンプはランダムに配置される。狩りが始まるたびにハンターは別のベースキャンプに行く
・水にはもぐれるけど水中戦はなし
・30FPS固定
・トンファーなし？
・アイルーはあり
・ギリースーツありでモンスターから身を隠せる（スキルかなにからしい
・逆におびき寄せるスキルみたいなのもあり
・川を爆破して水流でモンスターを流したり出来る。
・逆に上部の岩？かなにかを落下させてモンスターを押しつぶすことも出来る
・そのうち1体は草食動物を丸呑みした
※PVの感じだとMAPが縦に長い場所もあって飛び降りとか色々有効に使えるっぽい
ttp://www.neogaf.com/forum/showthread.php?t=1391293
ttp://game.watch.impress.co.jp/docs...w/1065192.html
ttp://dengekionline.com/elem/000/001/538/1538583/
ttp://www.4gamer.net/games/384/G038421/20170614098/
面白そうなので買うかな
自分より優れたるものを自分の周りに置きし者ここに眠る。カーネギー
できる人ばかり辞めていく会社が研修費用を出すようになったら、さらに退職が加速したというお話「人事に聞かせたい」 - Togetterまとめ
「従業員にトレーニングをして、よそへ行ってしまったらどうするのか」という疑問に対するStanger氏の答えは、「従業員にトレーニングをしないで、彼らが会社にとどまってしまったらどうするのか」ということになる。
従業員の才能を爆発させるには「会社に人を長く留める」戦略を捨てる必要がある
ttps://b.hatena.ne.jp/entry/s/gigazine.net/news/20171005-superboss/
「弱いつながり」理論でいうと、SNSでつながる友だちは、それこそFacebookの友だちが3,000人規模で、国内のスタートアップの経営者なら、たいていの人に直接または1hopでつながることができる。
ttps://s.nikkei.com/2vJsvYx
優れたマネージャーは自分より高い給与をもらう可能性のあるポテンシャルの高い部下を喜んで雇う
ttp://b.hatena.ne.jp/entry/www.masafumiotsuka.com/2015/11/the_peter_principle.html
人材は会社の資産として残らないが仕組みは会社の資産として永遠に残る
ttps://www.amazon.co.jp/dp/B010JM64M6/
ttps://employment.en-japan.com/engineerhub/entry/2019/11/07/103000
ttps://www.slideshare.net/yattom/ss-79372905
ttps://tinyurl.com/y8tkhuhz
ttps://bit.ly/2MylBjs
"競争優位につながるような戦略的なソフトを開発しようとするなら内製しかない。"
ttps://www.amazon.co.jp/dp/4822273784
ttps://medium.com/@kuranuki/aac6062adfb2
どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるか
（中略）
ソフトウェア開発とは、経営的意思決定の集積なのだから、経営的意思決定を外部の会社に委託するというのは、「経営を外部の会社にやってもらうようなもの」だからだ。
もっと言うなら、自分の会社の今後のビジネス的ポジションを、他社に決めてもらうようなものだからだ。
外注を出された会社は、そのソフトウェアが未来に実現するであろうビジネス的価値を犠牲にして、できるだけ少ないコストで作ろうとする。
ttp://fromdusktildawn.hatenadiary.jp/entry/20061003/1159869683
ttps://bit.ly/2JzCggZ
「ソフトウェア業界（特に受託開発業界）は、基本的に正直者が馬鹿を見る世界である。顧客が、保守性というソフトウェアの最も重要な品質を正しく評価できないという、情報の非対称性が存在するからだ」/分かるなぁ
「モダンな開発環境×技術顧問×内製化」Sansan×日経電子版 アプリ開発の最前線を語る夜
ボタンを1つ追加するだけで2週間。内製化によるスピードアップは必須だった。
「アプリ内にボタンを1つ追加するだけで、2週間の開発期間と、数十万円のコストが発生していました。それでは急な仕様変更に対応できないし、技術ノウハウも貯まらない。」
ネットサービスの肝は、開発にかける額の多寡というよりは、内製化するかどうかにあると思っています。
ローンチした後、そこからの追加・改善はものすごいスピードでやらなくちゃいけない。これは、内製体制でないと絶対に不可能です。
2017年1月、ネット証券大手のマネックス証券は証券基幹システムを刷新した。
お客様へ提供するサービスの開発スピード向上と、ノウハウの社内蓄積、開発コストの適正化を目的に、
（中略）
サービスの改善や新サービスの開発時に、ASPサービスの提供会社との会議に費やしていた時間を削減し開発のスピードアップを図ることで、競合他社への競争力を強化したいと考えました。
ttp://b.hatena.ne.jp/entry/s/quality-start.in/it-strategy/467
ttps://twitter.com/kanayang2009/status/129677947572465666
ttps://amzn.to/2ncDXrO
だから育てるんだ。
ABテスト デザイン OR ボタン OR 文言 - Twitter検索
外注でもA/Bテストでユーザの反応を計測してトライ・アンド・エラーでシステム開発ってできるもんなんだろうか。
できるとして、それって内製化した方がずっとクオリティ高くなるんじゃないの？
ttps://twitter.com/fromdusktildawn/status/874796380522336256
「外部委託すると細かい継続的な機能の改善が遅くなるので、自社採用でかなり優秀な人材をケチらずに採るべきだね。なかなか見つからなくても妥協せずに」ホリエモン
ttps://bit.ly/2QWMsoJ
外注はPDCAを回せないという致命的な欠点がある。ITスタートアップの感覚だと外注と内製には天と地ほどの差がある
ttps://bit.ly/2J5UCWQ
銀の弾丸ではないがリーンな開発は競争力の源泉。そのためにはPMFをコントロールできる開発チームが必須でそれは内製でしか達成困難。
ttps://bit.ly/2vkDd8E
正解に当たるまで回し続ける！3ヶ月で200回のA/Bテストから得た「意外な結果」とは
弊社のイベント一覧のページなのですが、単なるテキストの羅列のパターンと、リッチなレイアウトのものでテストすると、いつも必ずテキストの方が勝ちます。
海外テック情報局：eBayではダサいデザインのほうがコンバージョン率が高かった｜gihyo.jp … 技術評論社
デザイナと口論したいのではなく，見たいのは数字とお客さんの利用例。
そして何がうまくいっているのか突き止めたい。
選択の科学 ２４種類のジャムを売り場に並べたときと、６種類のジャムを売り場に並べたときでは、前者は、後者の売り上げの１０分の1しかなかったのです。
ttps://amzn.to/2I2V1O4
エンジニアでないファウンダーは最大一人まででお願いします | On Off and Beyond
理由１：変更につぐ変更を重ねられるようにする
最近 lean startup なる考え方がはやってますが、これはどういうことかというと、
東大合格者ランキングは正しいのか？――常に分母は何かを考えよ
何事にも閾値はある。そこに至らなければ、意味がないという数字だ。
「頭のいい人が成功しない理由」という本に、閾値の話があった。
だれもが中途半端にやめてしまう。それでは足りない。閾値を越えない。
ttps://ameblo.jp/chimu841/entry-10036171360.html
ttps://amzn.to/2Odv25b
①内製
②外注
フラクタルなレモン市場問題｜建築不動産クラスタ交流会の件その１
ttp://realtor-readyabooks.hatenablog.com/entry/20100515/1273919457
ttp://ledsun.hatenablog.com/entry/2016/02/28/014851
ttps://ja.wikipedia.org/wiki/情報の非対称性
ttps://ja.wikipedia.org/wiki/逆選抜
ttps://ja.wikipedia.org/wiki/取引コスト
「探索コスト」
時給制（時間を売る）が生産効率低いのって自明だよなぁ・・相当ボランティア精神ないと時給制で効率よくやろうって気持ちにならないよね
でも拘束時間で金額を決めてしまっては効率化を目指さなくなるんじゃないか
ttp://b.hatena.ne.jp/entry/b.hatena.ne.jp/entry/194800390/comment/redhornet96
ttp://b.hatena.ne.jp/entry/twitter.com/etomiho/status/872820182883762176
ttp://b.hatena.ne.jp/entry/twitter.com/etomiho/status/872822997106565120
ttp://getlife.hateblo.jp/entry/2013/09/10/015011
見積もりが人日で工数を計算していると、実際にはそれよりも短期間で実装できても見積もり日数になるまで納品を待ったりすることはある。
納期よりもかなり早い段階で実際には完成しているにも関わらず、
エージェントが利益相反行動をしていないかどうか監視するためのコスト。
自身の行動がプリンシバルの利益追求にかなっていることを証明するために
ttps://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1212240292
ttps://twitter.com/search?q=rails%E3%80%80%E9%A1%A7%E5%95%8F
「顧問プログラマ」再考 - Rails 雑感 - Ruby on Rails with OIAX
ttps://www.oiax.jp/rails/zakkan/rethinking_of_adviser_programmer.html
ITエンジニア採用に欠かせない原則とは (1/5)：IT人材ラボ
ttp://b.hatena.ne.jp/entry/s/itjinzai-lab.jp/article/detail/856
ttps://www.slideshare.net/fukumura1/fukuokarubykaigi-medpeer-ver1
【256人がリモートワークで回る仕組みを考える】後編
ttps://www.remotework-labo.jp/2015/10/interview_10/
http://anond.hatelabo.jp/20170305115905 を増田以外のホットエントリで見ると。
| コメント率 | タイトル | コメント数/ブクマ数 | ブクマページ |
|---|---|---|---|
| 0.0% | Python3.6 から追加された文法機能 - Qiita | 0/96 | b.hatena.ne.jp/entry/324476241 |
| 0.8% | 文章をベクトル化して類似文章の検索 - Qiita | 2/245 | b.hatena.ne.jp/entry/324662835 |
| 1.0% | [wip] 会社のサーバサイドエンジニアにReactとかReduxのことを説明する資料 - Qiit | 1/97 | b.hatena.ne.jp/entry/319535213 |
| 1.1% | 機械学習とディープラーニングの入門者向けコンテンツまとめ - Qiita | 1/94 | b.hatena.ne.jp/entry/321793279 |
| 1.9% | Web制作時の概算費用と想定納品日を簡単に計算する票をつくってみた – のんびりデザインしているよう | 7/375 | b.hatena.ne.jp/entry/320010979 |
| 2.0% | 最近見かけるレイアウト・ナビゲーション・スライダー・フォームなどがどうやって実装されているのかのまと | 7/344 | b.hatena.ne.jp/entry/322198623 |
| 2.2% | フロントエンド知らない私のwebpack入門 その1 - Qiita | 4/186 | b.hatena.ne.jp/entry/319233247 |
| 2.3% | フルマネージドのSaaS型クラウド・データベース・サービスdashDBの活用スタイルとは ～手間いら | 5/216 | b.hatena.ne.jp/entry/323891713 |
| 2.4% | Pythonをやるときに参考になりそうな情報 - のんびりSEの議事録 | 19/807 | b.hatena.ne.jp/entry/322300431 |
| 2.5% | React基礎 · GitBook | 17/681 | b.hatena.ne.jp/entry/321494522 |
| 2.7% | 開発効率を上げるテスト設計 // Speaker Deck | 5/183 | b.hatena.ne.jp/entry/323584734 |
| 2.8% | 畳み込みニューラルネットワークの可視化 - 人工知能に関する断創録 | 3/108 | b.hatena.ne.jp/entry/322431100 |
| 2.8% | グランブルーファンタジーを支えるインフラの技術 // Speaker Deck | 10/359 | b.hatena.ne.jp/entry/324611754 |
| 2.9% | 仮想DOMの内部の動き ｜ プログラミング ｜ POSTD | 6/206 | b.hatena.ne.jp/entry/321289144 |
| 3.0% | 金融データのPythonでの扱い方 - 今日も窓辺でプログラム | 16/527 | b.hatena.ne.jp/entry/322842311 |
| 3.1% | Python Jupyter notebookでpandasを使いCSVを読み込みグラフを描画してp | 5/162 | b.hatena.ne.jp/entry/321556884 |
| 3.1% | React Redux Real World Examples 〜先人から学ぶReact Redux | 9/290 | b.hatena.ne.jp/entry/323749846 |
| 3.2% | Awesome Python：素晴らしい Python フレームワーク・ライブラリ・ソフトウェア・リ | 15/472 | b.hatena.ne.jp/entry/319013267 |
| 3.2% | 履歴書の志望動機｜最速で書く方法と受かる書き方 | 14/433 | b.hatena.ne.jp/entry/279613157 |
| 3.4% | 今日からはじめるGitHub 〜 初心者がGitをインストールして、プルリクできるようになるまでを解 | 38/1128 | b.hatena.ne.jp/entry/318690305 |
| 3.4% | スケーラブル GCP アーキテクチャ | 6/178 | b.hatena.ne.jp/entry/322723492 |
| 3.5% | アーキテクチャから新しい！ 初めてのエディタには、21世紀生まれの「Atom」がおすすめ【続・若手エ | 11/311 | b.hatena.ne.jp/entry/322534650 |
| 3.5% | フロントエンドの基礎知識 // Speaker Deck | 15/423 | b.hatena.ne.jp/entry/322749937 |
| 3.7% | ロードバランサー再入門 ｜ ツチノコブログ | 26/704 | b.hatena.ne.jp/entry/323163487 |
| 3.7% | APIサーバを立てるためのCORS設定決定版 - Qiita | 5/134 | b.hatena.ne.jp/entry/321742626 |
| 3.8% | 【画像】こんなのソフマップじゃないｗｗｗｗｗｗｗｗｗｗｗｗｗｗ｜ラビット速報 | 5/131 | b.hatena.ne.jp/entry/321219627 |
| 4.0% | 【動画あり】人志松本のゾッとする話のあるある探検隊の話怖すぎwwwwww ｜ ２ちゃんねるスレッドま | 10/252 | b.hatena.ne.jp/entry/319507149 |
| 4.0% | （翻訳）2017年の展望: pandas, Arrow, Feather, Parquet, Spa | 7/176 | b.hatena.ne.jp/entry/324411617 |
| 4.2% | 【たまに行くよ！って人向け】いつもと少しちがう東京ディズニーシーデートにするための5つの方法 @ja | 3/72 | b.hatena.ne.jp/entry/321496344 |
| 4.3% | 高速なシステムを作る方法 // Speaker Deck | 9/211 | b.hatena.ne.jp/entry/283448858 |
| 4.3% | 処分・廃棄にお金は要らない！？パソコンを無料引取してくれる業者一覧 | 7/162 | b.hatena.ne.jp/entry/320803373 |
| 4.3% | スタディサプリを支えるデータ分析基盤 ～設計の勘所と利活用事例～ | 3/69 | b.hatena.ne.jp/entry/322583838 |
| 4.4% | 「Front-End Developer Handbook 2017」がGitBookで無償公開。フ | 24/542 | b.hatena.ne.jp/entry/318947145 |
| 4.6% | デブサミ2017「DeNAの機械学習基盤と分析基盤」講演メモ #devsumi - 元RX-7乗りの | 7/152 | b.hatena.ne.jp/entry/322562611 |
| 4.6% | 大量の要素を高速に表示するためのバーチャルレンダリング入門 / Virtual Rendering | 6/130 | b.hatena.ne.jp/entry/323604383 |
| 4.7% | MySQLアンチパターン | 22/473 | b.hatena.ne.jp/entry/319218778 |
| 4.7% | 5年間コードを書き続けたエンジニアが、新人に読んでもらいたい11冊+αを紹介する - エンジニアHu | 47/1006 | b.hatena.ne.jp/entry/313934939 |
| 4.7% | グーグル社員も長友選手も行う集中力を高める方法 - 自分で学ぶ心理学 | 20/427 | b.hatena.ne.jp/entry/322090614 |
| 4.8% | 例の機械学習コースが良いらしいと知りながらも2年間スルーし続けたがやはり良かったという話 - Qii | 68/1418 | b.hatena.ne.jp/entry/321403591 |
| 4.9% | NoSQL を使用する場合と SQL を使用する場合 ｜ Microsoft Docs | 28/577 | b.hatena.ne.jp/entry/322834020 |
| 4.9% | Awesome Selenium : 素晴しい Selenium ライブラリの数々 - Qiita | 5/102 | b.hatena.ne.jp/entry/321629987 |
| 4.9% | 誰でもできる、プレゼンが劇的にうまくなる基本テクニック - 科学と非科学の迷宮 | 77/1557 | b.hatena.ne.jp/entry/318913434 |
| 5.0% | 脆弱性発見者が注目する近年のWeb技術 // Speaker Deck | 24/481 | b.hatena.ne.jp/entry/319516657 |
| 5.1% | たった3つのコトで仕事が楽になる！「できる上司の会議」がマジで真似したい ｜ CuRAZY [クレイ | 7/138 | b.hatena.ne.jp/entry/322534334 |
| 5.1% | 日経電子版を支える基盤API // Speaker Deck | 13/256 | b.hatena.ne.jp/entry/319592914 |
| 5.1% | 30歳から始める数学 - Shoyan blog | 50/982 | b.hatena.ne.jp/entry/323617832 |
| 5.1% | インフラチームと開発チームの垣根をなくすためにAWSのCI環境を構築した話 - VOYAGE GRO | 20/392 | b.hatena.ne.jp/entry/323171376 |
| 5.1% | 『How to Get Startup Ideas』 - いかにスタートアップのアイデアを得るか - | 17/333 | b.hatena.ne.jp/entry/324384439 |
| 5.1% | 無料でウェブサイトやブログに使える写真を検索可能な28サービスまとめ - GIGAZINE | 18/350 | b.hatena.ne.jp/entry/323600897 |
| 5.2% | 内向的な人のための面接ガイド - GIGAZINE | 14/271 | b.hatena.ne.jp/entry/322036523 |
Python、データベース関連が目立つ。コメント無しで96ブクマに達するPythonさん凄い。マウンティング心?を刺激しないのだろうか。炎上したくない人はインデントに気をつけながらオブジェクト指向で書くといい。
| コメント率 | タイトル | コメント数/ブクマ数 | ブクマページ |
|---|---|---|---|
| 74.5% | はてブに要望「返信出来るようにして欲しい」 - interact | 114/153 | b.hatena.ne.jp/entry/319990286 |
| 73.5% | 「あなたが朱雀とか白虎とか四神を覚えたキッカケは何？」という質問に対し世代がバレそうになる人々→「幽 | 319/434 | b.hatena.ne.jp/entry/322198765 |
| 67.8% | 内海 聡さんのツイート: "あなたが甲殻類のアレルギーだった場合、あなたの心は殻に閉じこもっている可 | 449/662 | b.hatena.ne.jp/entry/318821783 |
| 67.4% | 日米首脳会談 首相は「ドラえもん」のスネ夫になった！民進党の野田幹事長が批判 （産経新聞） - Ya | 95/141 | b.hatena.ne.jp/entry/321930776 |
| 65.7% | いい記事書けばブクマつくとか嘘っぱち！こんな嘘がまかり通るはてな界に物申すっ！ - ゆるくいきていく | 260/396 | b.hatena.ne.jp/entry/323206934 |
| 65.5% | 痛いニュース(ﾉ∀`) : 梅沢富美男（66）、老害判定に怒り 「日本は俺達が作ったんだぞ！」 - | 190/290 | b.hatena.ne.jp/entry/322785094 |
| 65.5% | 茶碗に米粒を残した状態で「完食」する人は完全悪ではないけど相容れられない、という話に意見続々 - T | 413/631 | b.hatena.ne.jp/entry/321479096 |
| 64.6% | けものフレンズを視聴1分30秒で挫折。 - 自由ネコ | 122/189 | b.hatena.ne.jp/entry/321589678 |
| 63.7% | 「けものフレンズ」コスプレ批判に対する異論まとめ - Togetterまとめ | 228/358 | b.hatena.ne.jp/entry/323622485 |
| 63.6% | 『レジでバレる！二流の人の超ヤバい3欠点』という東洋経済の記事を読んで。クレジットカードのイメージは | 119/187 | b.hatena.ne.jp/entry/323599229 |
| 63.5% | 痛いニュース(ﾉ∀`) : 日本在住のイスラム教徒の子どもがハラール非対応給食に苦慮→学校側に配慮求 | 290/457 | b.hatena.ne.jp/entry/321128745 |
| 63.0% | あざなわさんの炎上とはてな村の権威のなさ - メロンダウト | 133/211 | b.hatena.ne.jp/entry/323813866 |
| 62.7% | プレミアムフライデーって何でこんなに叩かれてるんだろう？ - シャイニングマンの「勇気を君に」 | 126/201 | b.hatena.ne.jp/entry/324113658 |
| 62.5% | 飯田譲治さんのツイート: "日本が悪い日本が悪いって、民間人は殺さないってルール破って、原爆落として | 65/104 | b.hatena.ne.jp/entry/321434534 |
| 62.4% | 偏差値40の大学は日本に必要なのか？子供を焼き殺す大学に補助金は不要 - カキカエブログ | 166/266 | b.hatena.ne.jp/entry/318786744 |
| 62.2% | 坂上忍 清水富美加の月給５万円は正当「僕らの時もそうだった」 （デイリースポーツ） - Yahoo! | 237/381 | b.hatena.ne.jp/entry/321888913 |
| 61.9% | 清水富美加17日著書出版「全部、言っちゃうね。」 - 芸能 : 日刊スポーツ | 73/118 | b.hatena.ne.jp/entry/322431771 |
| 61.5% | 警視庁捜査1課長が竹刀で23歳美人記者をボコボコ （文春オンライン） - Yahoo!ニュース | 415/675 | b.hatena.ne.jp/entry/322218394 |
| 60.7% | 「ゴルフに興じる首相、誇れない」民進・蓮舫氏：朝日新聞デジタル | 136/224 | b.hatena.ne.jp/entry/321608217 |
| 60.6% | 金があるのに、理屈をつけてコンテンツに金を落とさない」連中について - うらがみらいぶらり | 243/401 | b.hatena.ne.jp/entry/321324226 |
| 60.6% | 痛いニュース(ﾉ∀`) : 中学校で「やばい」という言葉を使用禁止に 若い世代で意味が多様化 - ラ | 132/218 | b.hatena.ne.jp/entry/324642052 |
| 60.3% | 受動喫煙対策「東京だけでやれ」 自民党内で反対論噴出：朝日新聞デジタル | 241/400 | b.hatena.ne.jp/entry/321316384 |
| 60.1% | 娘の卒業式用の服を買いに行ったら驚愕した - コバろぐ | 92/153 | b.hatena.ne.jp/entry/321299915 |
| 60.1% | 「洗剤いらず」スポンジで教頭などが児童の体こすりけが ｜ NHKニュース | 215/358 | b.hatena.ne.jp/entry/322584234 |
| 60.0% | 松井一郎さんのツイート: "長谷川さんが、ブログで伝えたかったのは、健康であるための自己管理の重要性 | 201/335 | b.hatena.ne.jp/entry/320414066 |
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。
要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。
ここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここにお詫びと感謝を述べておきたい。
抽出条件だが、参考にできそうなコミットログを多く含んでいそうなリポジトリをGitHubのSTARの多い方からざっと目で見て適当に選び、それぞれ最新コミットから5000件抽出した（あわせて前処理として、コミットログ冒頭のタグ情報は消去した）。
atomのみ5400件抽出していたため、計25400件のコミットログがベースである。このうち、以下の条件に合致するものは参考例にすべきでないとして一律排除した。
こうして残った8540件を眺めながら、適当に切り出したのがこの用例集である。個人的に「うーんこの」と思った表現も、散見される場合は載せた。
ということで、以下用例を羅列していく。
以上の用例をふまえ、今回の参考ログ8540件から先頭の単語を出現回数で並べると次のようになった。
| Add | 1149 |
| Fix | 1014 |
| Update | 584 |
| Remove | 566 |
| Use | 382 |
| Don't | 260 |
| Make | 228 |
| Move | 178 |
| Change | 103 |
| Rename | 85 |
| Improve | 76 |
| Avoid | 68 |
| Allow | 65 |
| Implement | 60 |
| Handle | 58 |
コミットログの基本形はもちろん動詞 + 名詞である。名詞は固有名詞、複数形、不可算名詞が多いが、単数形の場合の冠詞は a が使われるか、あるいは省略される。the はまず使われない。
何かを追加した、という表現では非常に広く Add が使われる。メソッドからテスト、ドキュメントに至るまで大概これでまかなえる。
一方、何かを修正した、という表現では広く Fix が使われる。「何か」は typo や crash といった単語からメソッド名まで幅広い名詞を取るが、動名詞はあまり取らないのと、that節は取らないのでその点は注意が必要である。
Fix は「何かが正しく動くようにした」ことを示し、正しい動作内容が何かを説明しない。そこで正しい動作内容に言及したい場合は Make sure が使われる（こちらはthat節が取れる）。ただし Fix よりもニュアンス的に重い表現と思われ、Fix を使わず Make sure ばかり使うのはちょっとキモいのではないかと思う（Ensure はさらに重い表現っぽい）。
また、Fix は typo 以外でのドキュメント修正に対して使われることは稀である。対して Update はドキュメント、コメント、テストに使われ、本体のコードの修正に対しては使われない。本体コードの修正にあわせてテストも更新したなら Update が使われる。ただ、テスト機構それ自体のバグを修正したなら Fix である。
無駄な何かを単純に除去したなら Remove を使う。これまでのもの(A)から別のもの(B)に切り替えたのであれば Use B instead of A か Change A to B が使われる。新たに何かを利用するようにしたのであれば Use を、利用を取りやめた場合は Don't use を使うことが多い。
何かをしないようにしたなら Don't を、内部実装の効率化なら Make A + 比較級/形容詞 か Improve が使われる。
中身の変更を伴わない単なる名前の変更なら Rename A to B、コードや機能の論理上の場所を移動させたなら Move A to B である。
この辺はリファクタリングと呼ばれる行為と思うが、Refactor というぼんやりした動詞はあまり使われず、このように変更内容の種類に応じて動詞が使い分けられている。
コミットログにはWhyを書くべきだ、というのを何かで見かけたので because とか since を使ったログがどの程度あるかを調べたが、8540件のうち22件だった。基本的に短く、シンプルに、一目で意味が取れるログが好まれる傾向がある。例えば get rid of とか2件しか使われておらず、圧倒的に remove である。
一方で、シンプルな単語だけど開始単語としては使われないものもある。例えば次のような単語である。Expand(9)、Extend(8)、Print(5)、Optimize(5)、Publish(4)、Append(4)、Modify(3)、Manage(2)、Revise(2)、Dump(2)、Insert(2)、Migrate(2)、Enhance(1)、Edit(1) 。いずれもカッコ内は8540件に対する冒頭での登場回数である。結局、より一般的で平易な単語で表せたり、Refactor同様に抽象度が高すぎると使われないのだろう。
8000件もログを見たおかげで、迷いなくコミットメッセージが思いつくようになったのが個人的には今回書いてて最大の収穫だった。たぶんカンニングペーパーを作る行為それ自体が効率のいい学習になるという話と同じだと思う。
このまとめも100以上用例を転載してあるので、それを読むだけでも多少は効果があるんじゃないかと思う。同じようにコミットログ書きたくねぇなぁ英語わっかんねぇなぁと思っている人にとって、何か役に立つところがあれば幸いである。
NHKやYahoo!ニュースをブクマしてないか読み返しもしてないんだろうなぁ。
そこらへんのリンク先、半年後には消えるのがほとんど。
既に他の増田が指摘してるが、元増田でもちゃんと言及があるだろ。
Impressと言えば新聞社等のニュース配信と異なり、過去の記事も削除されることなく
それに今回のインプレスの件は、ニュースサイトのような
「記事のブクマページのリンクをクリック → 記事が消されてて読めない」
というのとは逆のケース。
例：はてななどの各社担当者が自作サーバーのノウハウを紹介 -BB Watch
記事の旧URL
bb.watch.impress.co.jp/docs/news/20091126_331459.html
↓
……の、ブクマページ （※現時点で471ブクマ）
b.hatena.ne.jp/entry/bb.watch.impress.co.jp/docs/news/20091126_331459.html
↓
……の、リンクをクリックすると、リニューアル後のURLへリダイレクトされる
bb.watch.impress.co.jp/docs/news/331459.html
……ので、旧ブクマページから元記事を読む際には不便は生じない。
記事のリニューアル後のURL
bb.watch.impress.co.jp/docs/news/331459.html
↓
……をブクマしようとすると飛ばされるのは、新たなURLのブクマページ （※現時点で0ブクマ）
b.hatena.ne.jp/entry/bb.watch.impress.co.jp/docs/news/331459.html
ブクマページのURLも変わってしまったことで、過去の多数のブコメへの動線が途切れてしまった。
また、ひとつの記事に複数のブクマページが存在することで、ブコメの散逸が起こってしまう。
ブコメのデータが削除されてしまったわけではないので「資産が失われた」は大袈裟かと思うけど、不便ではある。
以下のような例があるので、技術的には対応は可能なようだけど……
Google ウェブマスター向け公式ブログ
googlewebmastercentral-ja.blogspot.jp/
↓
……をブクマしようとすると、
b.hatena.ne.jp/entry/googlewebmastercentral-ja.blogspot.jp/
このエントリーには、他のブックマークエントリーページが存在します。以下のリンク先から、別のコメントなどの情報も参照できます。
Webmaster Central 日本版 公式ブログ 481 users
http://googlewebmastercentral-ja.blogspot.com/
と表示される。
無視してそのままブクマしようとしても、実際には『このエントリーには～』で示された「blogspot.com」の方がブクマされる。
この組み合わせで仕事として本をまるごと一冊書いている人間としての感想。
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以下というのは、現時点でそんなに高い付加価値なのだろうか。
追記：
そういう評判をネットで読んでChromebookを購入して使ってましたが、オフライン環境で電源OFFから立ち上げるとゲストユーザーとしてしか使えず、いろいろ制限が多すぎて面倒なので結局売ってしまいました。（再追記：映像ありがとうございます。去年秋頃までAsus C200MAを使っていて、何回やってもオフライン環境では自分のアカウントでログインできなかったんですが、その後アップデートで改善されたという理解でよいのでしょうか。ちなみに、このエントリの著者です→http://anond.hatelabo.jp/20150927211800）
Google日本語入力はとてもよいと思いますが、問題は別の言語（欧文）との入力を組み合わせる場合です。Android端末と共通の問題ですが、特定言語（欧文）に特有でしかも頻繁に使う引用記号などがChromebookでは瞬時に打てません。OS全体の言語設定を変えても無理でした。多言語処理が一番まともにできるのがmacとiOSという消極的な理由で現在の選択肢に落ち着いています。
iPad miniのバッテリ残量：38％
自分の場合は、特定の仕事に必要な条件を列挙していって、あとのことには目をつぶったら消去法でこの組み合わせになった。最初は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のキーボード周りがもう少し洗練されてきたら乗り換える可能性もあります。
京大ミス・ミスターコンテスト2015がTwitter上で盛んに行われた批判（と一部中傷）により中止に追い込まれた。私自身は京大生でもジェンダー論界隈の人間でもないのだが、この過程を見ていて多くの疑問を感じたので、ここにまとめていく。別にミスコン批判について詳しく解説する記事ではないので、そのようなものを期待していたなら別に読まなくていい。
基本的にはこのtogetterに沿って発言していく。ミスコン批判者側のパースペクティヴがわかりやすく整理された良いまとめであると思う。最初に断っておくが、私はミスコンをやめさせることには賛成であり、その意味でミスコン批判者側である。ミスコンを開催するようなやつらは大抵が最も憎むべきタイプのキモい人間である。しかし今回、ミスコン開催反対派としていち早くステートメントを出していた人々の持つある決定的な傾向が私にはないと感じたので、普通の意味でのミスコン批判を〈ミスコン批判〉と呼び、この記事で疑問を投げかける対象となるものを「ミスコン批判」と呼ぶことにしよう。
注意しなければならないのは、私は「ミスコン批判」者に敵意は全くない、ということだ。ミスコンを中止に追いやったこと、ただその一点に関しては全面的に肯定したい。この記事が特定の人々に対する人格攻撃に見えたのなら先に謝罪しておこう。申し訳ない。私が考えたことのどこが間違っているのかをわかりやすく教えてくれるひとが現れれば、私は満足だ。
11月16日に「京大ミス・ミスターコンテスト」なるアカウントが取り上げられたことから騒動は始まる（アカウント作成自体は7月のようである）。
【開催】本日より京大ミス・ミスターコンテストを開催します！???????? 11/29まで１日１回投票を受け付けております????是非サイトをCHECKしてみて下さい????✨ ▶︎http://www.missmisterkyoto.com/
これまでに何度かミスコンに関し議論が繰り広げられてきた（そして開催を阻止してきた）京大でのミスコン開催がこの時点で全くと言っていいほど問題視されていなかったという事態を重く見たひでシス氏らは、「京大ミス・ミスターコンテスト2015の問題点まとめ」なる文書の公開及びミスコン運営団体に対する公開質問状の提出を実行した。
「京大ミス・ミスターコンテスト2015の問題点まとめ」草案 です。気が付いた点があれば自由にコメントや編集をしてください。 https://t.co/ZZeaWzn81b
.@kyotomissmr 京大ミス・ミスターコンテスト（京大ミスコン）に対して公開質問状送りました。https://t.co/ENgjjDZwvk 多くの京大生たちが貴団体のコンテストについて違和感・疑問点を抱いています。生産的な対話となることを期待し、誠実な回答を希望します。
正直に言うと私にはこの公開質問状の意味がわからない。大学当局主催ならまだしも、単なるひとつの学生団体（企業が関わっているかどうかは本質的な問題ではない）にこのような物々しい文書を送りつけても「一部のTwitterユーザーに臨場感を提供できる」ことくらいしか得られないだろう。
今回、貴団体が「京大ミス・ミスターコンテスト」をWeb上で開催していることを知りました。しかし、私はこのコンテストにどこか違和感を覚えざるを得ませんでした。それは、これまで京大において積み重ねられてきた、ミスコン開催を巡る歴史と議論をまったく軽視しているように思えたからです。
「これまでのミスコン開催を巡る歴史と議論を軽視している」のは当たり前ではないか？ そんな歴史と議論を認知している学生がいったどれ程いるというのだろうか。私が部外者であるから知らないだけでほんとうは多くの京大生――あくまでも「当時の」――がミスコン問題を認知している、という可能性もあるが、そもそも前回類似の問題が取り沙汰されたのが2012年（なんと3年も前である！ 当時の2回生は留年・休学あるいは大学院進学していなければもういない）らしいということからも明らかであろう（そしてあなたが京大生ならば、2012年から2015年にかけてあなたのフォロー欄にどれだけの変化があったか考えてみてほしい）。2012年のミスコン問題について調べたところ今回のものとは異なる質の問題だとも感じたので、実質2004年まで遡って議論を追っていく必要がある。Twitterも存在しない時代じゃないか。突然「これまでのミスコン開催を巡る歴史と議論」などと言われても混乱するだけだ。
今回議論に参加したわれわれ京大生の多くは本コンテストの開催を知りませんでした。京大の名前を冠しているにも関わらず、京大生への認知不足に不信感を感じる覚える意見が多く出たのは事実です。「大部分の京大生の知らぬ間に京大ミス・ミスターコンテストを開催し既成事実を作ろうとしたのではないか」等の疑問点や不満を持っている方が多くいます。ミスコン開催容認派からもこのような声は聞かれました。本コンテストの告知をどのように行ったか具体的にご回答下さい。
これは単なる団体の体力の問題だろう。7月にアカウントを作り、9日間でフォロワーを300人まで増やし、ビラも配っていたのに「知らぬ間に」などと責めたてるのはちょっと厳しすぎる。普通にかわいそう。「京大」名義の使用には許可が必要という話は置いておくとして、京大の名前を冠しているかどうかは本質的に重要な要素なのだろうか。逆に、誰の目から見ても十分な告知が成されたところで京大の名前を冠しても良いと言えるのだろうか。ところで私の大学のミスコンも毎年知らぬ間に終わっている。あれが外見至上主義的だなんて思ったこともない（し無自覚に外見至上主義を推奨しているようにも見えない）。
「美」のほうには噛みつくのに「知」のほうには噛みつかない理由についてひでシス氏は以下のようにツイートしている。
ちなみに「人を社会的に容姿で順序付けることはよくない」と考えている人たち、その理論も論理力という権力勾配に乗って展開されてること、人を学力で順序付けることに関してはどう考えてるのだろう。ぼくは「学力による順序付けは生産性向上を通じて人類の幸福に影響する」で一応決着つけてるんだけど
故にこの批判の核、と言うか土台は、ガッチガチの功利主義であることが明らかとなった。「普遍的な道徳が前提とされていて、それに従っている」というわけではないらしい（「ミスコン批判」者の中には功利と道徳の混同が見られるステートメントを提出する者が多く見られた）。功利に基づく批判はホリィ・セン氏の以下のツイートの後半と衝突する。
「容姿」という価値基準が絶対化してしまった世界――「顔という牢獄」――からの逃げ場はあるべきで、京大はその逃げ場を担っていると思う。もし京大がミスコンを許してしまったら、他大学も「右にならえ」でしょうよ。ある種の「多様性の維持」のためにも、ミスコンは阻止しなきゃならん。マジで。
〈ミスコン批判〉とは「多様性の維持」のためにミスコンを阻止しようという運動であるという側面を持つ、ということか。「功利」という価値基準が絶対化してしまった世界――「ユーティリティという牢獄」――からの逃げ場もあるべきである。もし京大が功利主義を許してしまったら、他大学も「右にならえ」でしょうよ。ある種の「多様性の維持」のためにも、功利主義には断固として抵抗しなきゃならん。マジで。
今回気になったのは、そういった少しでもマシな社会を引き寄せるための泥臭い活動を、シニカルを装って冷笑したりこのヒドい現状をさも世の中の真理のように説いたりする言説があったことですかね。「たしかにおかしいとは思うが仕方ない」と言った瞬間に少しでもマシな社会は手から離れていってしまう
良い社会を実現するためには何をやってもいいのだろうか。功利主義的には良いんだけど。社会的に悪い影響を与えるというただその一点だけを根拠にして、単なる一つの企画を弾圧することを手放しで称賛するような風潮を放置しているとさらにとんでもないことになるのは火を見るより明らかであろう。正当かつ普遍的な理由で反対していないのだから、中止の時点で追及はやめるべきである。
先程のホリィ・セン氏のツイートに従うなら、今回のミスコンを功利主義的に弾圧することは避けるべきなのだ。ホリィ・セン氏のツイートそれ自体が京大における 「多様性の維持」という価値基準が絶対化してしまった世界――「ダイバーシティという牢獄」――を象徴してしまっているのが残念ではあるが。
さて、公開質問状に戻ろう。
突然「容姿による人間の順序付け」というワードが出てきたが、ミスコンと何の関係があるんだ？ そもそも「ミスコン」と「容姿」の間に直接的な関係はあるのだろうか。これらの間接的・結果的な「つながり」がこの一文によって再生産されている、ただそれだけである。
c. 所謂「女性らしさ」や「男性らしさ」の押し付けに繋がることについてどういった意見を持っていますか？
大学という本来容姿や性で判断されてはならない場でこういった企画を行うことは問題だ。という意見が寄せられています。
ミス・ミスターコンテストは、ほとんど容姿で判断されるコンテストと言って過言ではなく、そういったコンテストを男女で分けて行い、女性（男性）同士を比べてその中で１番を決めると、「この人が女性（男性）の中で１番」という「基準」が生まれてしまう。その「基準」は女性（男性）らしさの押し付けに繋がっているという意見が出ました。
同上。直接的には繋がらない。最初からルッキズムが浸透していることを仮定しており、本末転倒である。また、ミスコンごときが出場者以外への特定の価値基準の「押し付け」に繋がるとは到底思えない。
公開質問状についての主要な議題は以上である。この質問状とTwitterでの制御の効かなくなった批判・中傷によりミスコンは中止となった。
今回のコンテストの中止を決定いたしましたのでご報告いたします。
中止の決定の後4時間ほどで公開質問状に対する回答が送られてきた。ただ多くの質問に説明責任がないとして回答しないもので、不誠実だと感じられた。
説明責任はない。どうして説明責任があると思ったのだろう。純粋に、不思議だ。
京大ミスコン問題2015の公開質問状に対して回答が得られたので、議論用のDocsと総括用Docsを作成しました。ご自由にコメント・編集下さい。 回答と議論： https://docs.google.com/document/d/1BybFd2Th2NzTMQ3AK76kTrVjxB7S0jkMBSjVKGdQ4oE/edit 総括とこれから： https://docs.google.com/document/d/1L8bcokWX-gEHD0ecqT8UC_NyDBrboPULl3TSlZewjY4/edit
また、以下のような危うい意見もあった。
ミスコンの基盤となる差別的価値観は日常の模倣で、「ミスコン」はステージだけでなく日常で行われ続けているという事を認識してたら、一つ企画が中止になったところで「勝利」なんて言えないと思うけど。。ミスコン反対もクエストになってどうすんの。 >京大ミスコンクエスト
このような発言をすることによって差別的価値観を再生産し続けると永遠に闘い続けなきゃいけなくなりますよ、としか言いようがない。自足自給はやめましょう。
ちなみに言っておきますけど、ミスコンの内包している問題的構造は日常の中に浸透しているからこそ今回ミスコンがミスコンとして具現化した・言い換えるならばミスコンは日常的にも起きている、というのはその通り。
同上。
moralistよりもethicistになりましょう。そして自分たちがやったことについてもう一度よく考え直してみましょう。
以上、眠くなってきて最後の方はテキトーになっているが、ここで終わろう。言葉をうまく選べているか不安だが、最初に述べた通り、攻撃の意思はない。
Playbooks — Ansible Documentation
railsbox - Fast and easy Ruby on Rails virtual boxes
Ansible入門 (全15回) - プログラミングならドットインストール
Amazon.co.jp： 入門Ansible eBook: 若山史郎: Kindleストア
Amazon.co.jp: Ansible Configuration Management 電子書籍: Daniel Hall: Kindleストア
Red HatがITオートメーションのAnsibleを$150Mで買収へ…OpenStackデプロイをDevOpsのために簡易化
Git Clone (スタートアップスクリプトID:112600117316)
指定のGitリポジトリをcloneし、指定の実行ファイルを自動的に実行します。
https://github.com/philc/terraform
fog - The Ruby cloud services library
A list of base boxes for Vagrant - Vagrantbox.es
Discover Vagrant Boxes | Atlas by HashiCorp
https://github.com/ryotarai/itamae
Itamae - Infra as Code 現状確認会 // Speaker Deck
Amazon.co.jp： Chef実践入門 ~コードによるインフラ構築の自動化 (WEB+DB PRESS plus): 吉羽 龍太郎, 安藤 祐介, 伊藤 直也, 菅井 祐太朗, 並河 祐貴: 本
Docker - Build, Ship, and Run Any App, Anywhere
[翻訳] Dockerについてよくある勘違い | TechRacho
Puppet Labs: IT Automation Software for System Administrators
想像をはるかに超える高速性と安定性を持つWindows ServerをメインにWindows＋Linuxのハイブリッド環境でインフラを構築
http://gihyo.jp/admin/serial/01/gloops/0001
IISとASP.NET，そしてC＃で書かれたアプリケーションが
想像をはるかに超える高速性を実現していることが挙げられます。
そのうえ，安定して動作しているのです。
ttp://itpro.nikkeibp.co.jp/article/NEWS/20090609/331590/?SS=imgview&FD=-654674548
HPCでもダントツのパフォーマンスをたたき出すWindows
ttp://cloud.watch.impress.co.jp/docs/interview/20101224_416025.html
ttp://wsmgr.jp.brothersoft.com/screenshot-50450.html
NASパフォーマンス比較テストでWindowsがLinuxを圧倒！！
ttp://www.flexense.com/documents/nas_performance_comparison.pdf
ttp://it.slashdot.jp/story/12/04/24/0052242/
【一方Linuxは…】
Linux Daily Topics：2011年9月2日 Kernel.orgがトロイの木馬の侵入被害に｜gihyo.jp … 技術評論社
ttp://gihyo.jp/admin/clip/01/linux_dt/201109/02
Linux カーネルの基盤サイトがクラッキングの被害に - japan.internet.com
ttp://japan.internet.com/webtech/20110902/2.html
Linux Daily Topics：2011年9月15日 狙われるLinux… 今度はLinux Foundationが標的に｜gihyo.jp … 技術評論社
ttp://gihyo.jp/admin/clip/01/linux_dt/201109/15
Linux Daily Topics：2011年9月2日 Kernel.orgがトロイの木馬の侵入被害に｜gihyo.jp … 技術評論社
ttp://gihyo.jp/admin/clip/01/linux_dt/201109/02
Linux カーネルの基盤サイトがクラッキングの被害に - japan.internet.com
ttp://japan.internet.com/webtech/20110902/2.html
Linux Daily Topics：2011年9月15日 狙われるLinux… 今度はLinux Foundationが標的に｜gihyo.jp … 技術評論社
ttp://gihyo.jp/admin/clip/01/linux_dt/201109/15
MySQL.comのWebサイトに不正なコード 闇市場でroot権限も販売か
ttp://www.itmedia.co.jp/news/articles/1109/27/news027.html
またもOSSプロジェクトが被害に! Wineプロジェクト、不正侵入を発表 | エンタープライズ | マイコミジャーナル
ttp://journal.mycom.co.jp/news/2011/10/13/115/index.html
・安定性・信頼性
フリーソフトであるLinuxの安定性・信頼性はハッキリ言って問題外。
1日連続で稼動させることすら困難。
いまやWindowsの安定性・信頼性はメインフレーム(汎用機)をも凌ぐ。
世界中のメインフレームが全てWindowsServerに置き換わったのがその証拠。
・脆弱性
Linux()
Linuxで稼動している世界中のサーバーがクラックされまくっている。
デフォルトスタンダードOSとしてあらゆる攻撃を受けてきたWindowsはいまや世界で一番強固なOSとなった。
豊富なウイルス対策ソフトもさりながら、カーネルの構造的に絶対に外部からクラックされることが無いOSとなった。
しかし上記内容により安定稼動させるのはほぼ不可能。
またサポートが存在しないため自前で何とかするしかなくかえってコスト高となる。
OSは無料ではないが従来のメインフレームのOSと比較すると安価。
もともと安定性に優れたOSであるため、誰にでも安定稼動させることが容易である。
サポート面もマイクロソフトを始め、各ベンダーが完璧なサポートを行える体制となっている。
そんでもって、 Microsoft は持っている。僕同様、みんなも知ってると思うけど、なんと驚くべきことに、 Microsoft はそれをよく理解していない。実に。でも彼らは、純粋に、偶然、プラットフォームを提供するビジネスから始まって成長してきたから、プラットフォームを分かっているんだ。彼らはその領域で30数年やってきた。 msdn.com に行って、少しの間ブラウジングしてみればわかる。もし見たことが無ければ、驚く準備をしておいた方が良い。なぜならそれがとてつもなく巨大だからだ。何千の、何千の、何千もの API コールがある。彼らは巨大なプラットフォームを持っている。実際の処大きすぎて、全く統率が取れていないけれど、少なくとも彼らはやっている。
Amazon は自分のものにしている。 Amazon の AWS （ aws.amazon.com ）は途方も無くすばらしい。行ってみてご覧よ。クリックして回ってみるんだ。全く恥ずかしくなる。僕らはこれらのひとかけらも持ち合わせていない。
Apple も、明確に、自分のものにしている。彼らは基本的にクローズな選択を、特にモバイルプラットフォーム周りでしているけれど、アクセシビリティを理解しているし、サードパーティ開発者の力もよく分かっていて、自分たちのドッグフードを食べている。それでさ、わかるだろ？。彼らは実に見事なドッグフードを作る。彼らの APIコールは Microsoft のそれに比べて実にクリーンで、ずっと昔からそれを維持している。
Facebookも持ってる。だからこそ心配になるんだ。ぐうたらな僕をここまでして書かせた理由はそれだ。僕は元来ブログするのも、プラスする（って言うのかどうか知らないけど）のも嫌いだ。そもそもGoogle+はぶっちゃけ話をするのにはひどい場所だけど、とにかくやらなきゃならない。Googleに成功して欲しいと思ったらね。で、僕は成功して欲しい！。まあ要は Facebook が僕を呼んでいるし、きっとそっちでやるほうがずっと楽なんだろうけど、Google は僕にとって家だし、だからこういう家族同士のお節介焼きのようなことをやっていこうよと言ってるわけだ。（訳注：この辺の訳怪しい。トラバで指摘いただいたのがすてきだったのでまるっと差し替え！。"アドバイス" thx ！）
Microsoft と Amazon 、それに Facebook （たぶん。実際僕はよく見ていないんだ。だってすごく落ち込むからね…）の提供するプラットフォームに驚いた後に、 developers.google.com に行ってちょっとブラウズしてみて欲しい。ね？大きな差だろう？。まるで君の5年生の甥っ子が、巨大で強力なプラットフォーム企業がもしリソース的に独りの小学5年生しか人を割けないって時に作るようなものをデモしてみなさい、なんていう宿題でもでっち上げたみたいな感じだよ。
どうか悪く思わないで欲しい。 Developer relations チームが、これを外部に提供できる形にするためにとんでもない努力をしてきたってことを僕は分かっている。僕が知る限り、彼らはとにかくケツを蹴り上げつつけている。なぜなら彼らはプラットフォームを理解しているからさ。プラットフォームに対して実に冷淡で、しかも時には敵対心さえあらわにされるような環境の中で、彼らは英雄のように努力している。
僕は率直に、 developer.google.com が外部の人にとってどう見えるかを説明しているだけさ。全く幼稚に見えるだろう。 Maps API は一体どこにあるっていうんだ？。いくつかはなんだかよくわからないラボプロジェクトとやらに入っている。で、いざたどり着いてみれば、そこにある API は全くけちな代物だ。まさに本当の意味でドッグフードだ。オーガニックなんかとは無縁だね。僕らの内部 API に比べれば、まるで不格好な別物だよ。
Google+ についても、悪く思わないで欲しい。到底彼らだけが違反者ってわけじゃない。文化的なものが絡んでいるんだ。僕らが内部でやってることっていうのはさ、基本的には、惨めでマイノリティなプラットフォーム部隊が、無敵で予算も自信もたっぷりのプロダクト部隊に多かれ少なかれ負け続けている、そんな戦争なんだよ。
ゼロから構築したプログラマブルなプラットフォームになるべきなんだってうまく気づいたチームってのはみんな弱者さ。 Maps や Docs なんかが思い浮かぶ。 Gmail もなんとなくそっちの方に進みはじめたように見える。でも彼らがそのために予算を獲得するのは実に難しい。なぜなら、それは僕らのカルチャーじゃないんだ。 Maestro の予算なんか、 壮大な Microsoft Office プログラミングプラットフォームの足下にも及ばないちっぽけなものだ。ふわふわ毛皮のうさぎちゃんと、 T-Rex の対決みたいなものさ。 Docs チームだって、このスクリプティング機能が無ければ Office に太刀打ちできないってのはよく分かっているんだ。でも残念なことに、予算が付かない。つまりさ、そうじゃないとは思うんだけど、現状 Apps スクリプトが Spreadsheet だけで動作して、 API の一部としてキーボードショートカットすらない。まさにチームが愛されていないって思うしか無いよね。
皮肉にも、 Wave は偉大なプラットフォームだった。冥福を祈りたい。でもプラットフォーム的な何かを作るっていうことは、そのまますなわち成功を意味するって訳じゃあ無い。プラットフォームにはキラーアプリが必要だ。 Facebook そのもの（つまり、 wall やら friends やらなんやらというデフォルトの機能）が、 Facebook プラットフォームのキラーアプリだ。そして、 Facebook アプリが、 Facebook プラットフォーム無しで成功できると結論づけるのは、深刻な誤りだと僕は思う。
みんなは、外の人たちが Google は傲慢だって言い続けているの、知っているよね？。僕は Googler だ。だから、みんなと同じように、外の人たちがそう言っているといらいらとする。僕らは全般的に見て全く傲慢じゃ無い。僕らは、まあ、99%は傲慢じゃない。僕はこの文章をこう始めた（遠い記憶をさかのぼってよ）、 Google は「正しいことだけをする」って表現した。僕らはよかれと思ったことだけをしている。だから、人々が僕らが傲慢だって言うときは、まあ大抵彼らを雇ってあげなかったときか、僕らのポリシーに不満があるか、まあそんなようなところじゃないかな。彼らはそれで気分が良くなるから、傲慢だ傲慢だと言っているんだろう。
でも、もし僕らが、僕らは全ての人に対して完璧なプロダクトをデザインする方法を知っているだなんて、そんなスタンスを取るんだとしたら、僕を信用してくれて良いと思うけど、結構そういう話を聞くんだけど、僕らは飛んだ間抜けになる。それを傲慢って言ったり、無邪気さって言ったり、なんて言ってもいいけど、結局の処、それは愚かさに他ならない。全ての人にとって完璧なプロダクトなんて、無いんだ。
デフォルトフォントサイズを設定できないブラウザについて話してこの話題を締めくくろうか。アクセシビリティへの侮辱ってやつについて語ろう。つまり、いずれ僕は年を取って、ほとんど目が見えなくなる。事実そうだと思う。僕は人生でずっと近視だったし、40歳にもなれば今度は近いものが見えなくなる。そうなればフォントの選択ってのは生死を分ける重要なポイントだ。それは君を完全にその製品から追い出してしまう。ところがどっこい Chrome チームってのははっきりと傲慢だから、彼らはゼロコンフィギュレーションプロダクトなんて言ってて、まったく厚かましくも、もし目が見えなかったり耳が聞こえないなりなんなりするなら、お前はファックユーだぜってなもんだ。残りの人生、全てのページを表示する度に Ctrl-+ を押せって言うんだよ。
これは彼らの問題じゃ無い。みんなの問題だ。僕らが徹底してプロダクト企業だということが問題だ。僕らは広くアピールするプロダクトを作った。例えば検索がそうだ。そのあまりにもひどい成功が、僕らの目をくらませてしまった。
Amazon もまたプロダクト企業だった。だから。 Bezos にプラットフォームの必要性を理解させるのには、外部の力が必要だった。その力ってのはどんどんと蒸発していく利幅だった。彼は追い詰められて、脱出方法を考えなければならなかった。でも彼の持ちえたものは、エンジニア達とコンピュータの群れだった。そこからどうにかマネタイズするには…？。結果論だけれど、そうして彼は AWS にたどり着いたわけだ。
Microsoft はプラットフォームとして始まった。だから彼らにはたくさんの習慣があった。
でも、 Facebook は…、彼らは僕を不安にさせる。僕はエキスパートではないけれど、でも、彼らは最初プロダクトとしてスタートして、そしてそれをうまく成功につなげていたことは確かだ。だから、彼らがどうやってプラットフォームへと変革を遂げたのか、僕にはわからない。それは比較的昔のことだったろうと思う。 Mafia Wars のようなものが現れる前に、彼らがプラットフォームにならなければならなかった時よりもずっと昔。
たぶん彼らは僕らを見て、こう自問したのかも知れない。「どうやったら Google を倒せる？。 Google に足りないものはなんだ？」
僕らが直面している問題はとても大きい。僕らがキャッチアップを始めるには、めざましい文化的な改革が必要だ。僕らは内部的にもサービス指向なプラットフォームを持っていないし、同じように外部的にもそうだ。この「自分のものにしていない」感じは、まさに会社全体を覆う風土病だ。 PM は分かってない。エンジニアも分かってない。プロダクトチームも分かってない。誰も分かっていない。たとえ一個人で分かっている人間がいたとしても、もしそれが君だとしても、僕らがそれを総力を挙げて緊急事態として扱わなければ、これっぽっちも意味が無いんだ。僕らはプロダクトをローンチして、それを後から魔法のように美しい外部拡張可能なプラットフォームに成長させられる、そんなふりをし続けることを、やめなければならない。何度もやって、だめだったじゃないか。
プラットフォームの黄金律「自分のドッグフードを食べろ」はこう言い換えることができる。「プラットフォームから始めろ。そしてそれをなんにでも使え」（訳注："アドバイス" thx ！）。後からちゃんとやるなんて不可能だ。少なくとも、簡単には無理だ。 MS Office をプラットフォーム化した人たちに尋ねてみればいい。あるいは Amazon をプラットフォーム化する為に努力した人たちに。遅れてしまえば、正しく立て直すのに10倍の苦労が必要になるだろう。ごまかしはできない。内部アプリが特別な優先アクセスを受けられるようなバックドアを秘密に仕込むなんて、どんな理由があっても不可能だ。難しい問題から、まず最初に解決しなければならないんだ。
僕は遅すぎると言いたいわけじゃ無い。けれど、待てば待つほど、致命的な遅れへとどんどん近づいてゆく。
この記事をどう纏めて終えればいいか、正直よくわからない。言うべきことは全て言ったと思う。この記事はできあがるのに6年かかっていると言える。僕が紳士的ではなくて申し訳ないと思う。プロダクトやチーム、個人を僕が誤解していたら申し訳ないと思う。もし僕らがたくさんのプラットフォームを実は作っていて、僕や、僕が話した人たちみんなが偶然知らないだけだったとしたら、申し訳ないと思う。
でも、僕らは今すぐに始めないとならない。
音楽配信会社 4/1からAndroid向けにも1曲300～420円で配信
ttp://workingnews.blog117.fc2.com/blog-entry-2707.html
99 ： のり(大阪府)：2010/04/01(木) 10:47:48.08 ID:q6Vh7b9j
ttp://k-tai.impress.co.jp/docs/news/20100121_343845.html
>Androidの著作権保護技術を用いた世界初の音楽配信サービス。ただ、
>その著作権保護の関係上、パソコンなどへ楽曲データをバックアップ
>することはできず、機種変更や故障による本体交換時、メモリカードの紛失時でも
>楽曲データを引き継げない。ただし、楽曲購入から一定期間は再ダウンロード
>できるようになる見込み。また、ダウンロードした楽曲は着信音として設定できる。
検索したらやっぱ駄目みたいだ。
著作権は大事なのはわかる。
着信音設定とかいらねぇから安く使いやすくすべきだと思うんだが本当頑固だなｗ
176 ： ペン(dion軍)：2010/04/01(木) 21:06:38.03 ID:CW/SqX1O
»99
信じられない。
バックアップすら無理なんて！
102 ： パステル(福岡県)：2010/04/01(木) 10:50:00.53 ID:+9xuf8Da
»99
正にゴミだなこれ
165 ： パステル(catv?)：2010/04/01(木) 15:44:08.90 ID:a8DrKRux
»99
これエイプリルフールだろ？
166 ： パステル(愛媛県)：2010/04/01(木) 16:12:50.32 ID:gR30KRDC
»165
違うよ
105 ： 硯(東日本)：2010/04/01(木) 10:55:29.62 ID:Sebjpzij
»99
もう正気じゃねえだろこんなん
108 ： ムーラン(東京都)：2010/04/01(木) 10:59:01.67 ID:oGTISN2E
»105
ttp://pc.watch.impress.co.jp/docs/column/hot/20100113_341860.html
しかし、ここでどんなに馬車事業を保護しても、それを守りきれないことを歴史は示している。むしろ馬車事業を守ろうとすることで、鉄道網の整備が遅れ、他の産業まで競争力を失う。別に馬車事業の人が悪いことをしたわけではないし、責任があるわけでもない。が、それこそが「革命」ということの本質ではないか。重要なことは、馬車事業を守ることではなく、馬車業者をいかに鉄道業者に転換していくかだが、すべての馬車事業者が鉄道事業者として成功できるわけではない。その痛みを許容できなければ、ますますこの国が苦しいことになるのではないかと懸念している。
いろんな人たちがGoogle Chromeの戦略性を誤解しているので、
その戦略性と位置づけをまとめてみたいと思います。
まず、タブごとにクラッシュコントロールをできるようにするブラウザを開発することが
http://crypto.stanford.edu/websec/chromium/chromium-security-architecture.pdf
それも単に、ウェブサーフィンのブラウザとして有益そうだなー？
というような曖昧な理由ではないんです。
ご存知のように、Googleが検索の次のフィールドとして据えているのは、
クラウドコンピューティングによってOfficeマネーを手繰り寄せることです。
このマーケットを開拓するには、
ひとつのタブが落ちれば全体も落ちてしまうブラウザなんてあり得ないんです。
だって、Gmailウィンドウを開いてるときに、別のタブが固まっただけで
ブラウザが落ちてしまったら、クラウドなんて使い物になりませんから。
GmailとGoogle Docsを同時に立ち上げているのに、
Docsが落ちたせいでブラウザ全体がクラッシュしてメールの文章が途中で消えてしまった・・・
なんていう事象が頻繁に起こっては利便性に欠けます。
#そのために現状のGmailでは、こまめに自動保存するハメになってしまい、コンピュータのリソースを無駄遣いしています。
要するに、ウェブブラウジングとしてのブラウザを目指しているのではなく、
クラウド向けのアプリブラウザとしての地位を確立することが目的なのです。
巷のIT系情報サイトとか新聞の報道では、ブラウザ戦争勃発、とか言われていますが、
まったく未来が見えてないですね。
単なるブラウザを開発したところで、別にGoogleとしてはオイシイことなんて何もないんですから。
ちなみに、独自エンジンV8の構築もクラウドコンピューティングの最適化が目的ですよね。
WEBページの表示が早い、とか悠長な比較をしてる場合じゃないと思うんですが。
Chromeの機能的な特徴が1)でしたが、デザインにも戦略性が込められています。
つまり、今後製品化されるAndroid向けのブラウザを見据えて最適化されたものと推察できます。
Googleの次の戦略は、モバイル検索クエリを確保することですが、
Androidも含めて、今回のChromeでようやく土台が整った感じです。
まず、IEやFirefoxとの比較として弾さんが述べているように、
Eee PCのようなミニノートでさえも、現行ブラウザでは手狭すぎます。
さらに、その省スペース化に一役買っているComboBoxこそ、モバイルの世界戦略に大きく寄与します。
なぜなら、検索とURLが同一の窓から入力できるので、いちいちGoogleトップにアクセスすることなく、
モバイルからの検索クエリをゲットすることが可能となるからです。
検索クエリもURLクエリもウェブに対するアクセスとしては同一のものであるという哲学に感嘆するのもさることながら、
モバイル向けにも同様のデザインを展開すると、非常にシンプルで機能的です。
Chromeは、Androidのデフォルトブラウザになるのが必然ですから、
ComboBoxによって、日本のi-modeやEZwebから公式検索クエリをゲットしているのと同様のことを
■まとめ
どう考えても、Google Chromeは、20％ルールから生まれたものではなく、80%のほうです。
・モバイルサーチ
というGooleが開拓しなければならない二つの市場を飛車角取りするためのソリューションです。
PC上でChromeを介したクラウドアプリが確立すれば、新規参入のAndroidを使用する理由となりますし、
その逆もまたしかりだと思います。
Googleカレンダー、Gmail, Google Docsなどを基軸にPCと携帯をスムーズに連携させれば、
iPhoneがMobile Meでやろうとしていることをはるかに凌駕することができるのも明らかです。
AndroidとChromeが両者オープンソースなのは、早期にクラウドとモバイルのデファクトを確立するために
■余談
中の人としては、「ベータ版でなんとかここまで持ってきた・・・」という感じかもしれません。
■その他
Google Earthに代表される20%のほうは、「Googleってすげー」と思わせるような技術ブランディングに寄与しています。
ちなみに、仮にGoogleと同様の外観のサイトがあって、ここにMSNやYahoo!の検索結果を表示したとしても、
その検索結果がGoogleのものではないと誰が判断できるでしょうか。
ほとんどの人は、その判断基準を持ち合わせていないと思います。
「Googleはイメージ戦略の成功のたまものだ」みたいなことを言っていた記憶がありますが、
まさに的を得た発言かもしれません。
