Site-Log on Tumblr

"今日、TLに流れてきた「鳴かぬなら　そういう種類の　ホトトギス」という言葉を、折々に思い出して一日が終わる。"

Twitter / masanimasaru (via akimbd)

(元記事： akimbd-blog (nashi-kyoから))

"簡単にここでクレピネヴィッチが説明している「軍事技術革命」（Military Technological Revolution: MTR）というものを説明しておきます。クレピネヴィッチは、この「軍事技術革命」というものが、１４世紀から数えると、少なくとも１０回起こったと分析しております。以下はその１０回の「革命」のポイントをその論文から抜き出したもの。１，歩兵革命（the Infantry Revolution）：長弓の技術が戦術面での革新と相まって、戦場における支配的な存在が騎兵から歩兵に移り変わることが可能になった。２，砲術革命（the Artillery Revolution）： 砲身の長大化、冶金技術の革新、そして火薬の性能の向上などによって砲兵が強力かつ安価になり、それにともなう攻城戦における組織変化のおかげで、城を守る側が不利になった。３，航海術と射撃の革命（the Revolution of Sail and Shot）：船の動力がオールから帆に変わり、これによって船に重量のある大砲を載せることが可能になって、戦艦が「浮上している兵士の要塞」から「砲台」に変わった。４，要塞革命（the Fortress Revolution）： 低く厚い壁の登場によって大砲の効果が薄れ、優位が攻撃側から防禦側に移った。 ５，火薬革命（the Gunpowder Revolution）：マスケット銃という技術革命が、横隊的（の次に方陣的）な戦術へのドクトリン面での変化とともにもたらされたもの。６，ナポレオン革命（the Napoleonic Revolution）：産業革命と兵器の大量生産 によって大陸軍の登場を可能にしており、これによって野戦軍の規模が桁違いの大きさになった。７，陸上戦革命（the Land Warfare Revolution）：鉄道や電信のような新しい民生技術が戦略的な機動性を向上させ、指揮官が戦場で大規模な部隊を維持しながら広範囲に分散した作戦を協調させることができるようになった。８，海軍革命（the Naval Revolution）：帆船が蒸気船に、そして木造船が鉄造船に変わったことによって、より重く大規模な戦艦や大砲が実現し、いままでの舷側に大砲を積むような戦術から新しい戦術の採用につながった。９，戦間期の革命（he Interwar Revolutions in Mechanization, Aviation and Information,）：これは機械化、航空機、そして情報面で起こったもの。機械・通信面での技術革新は、最終的に航空機と機械化された部隊を使用したドイツの電撃戦における統合作戦につながった。１０、核革命（the Nuclear Revolution ）：核兵器の登場によって起こったものであり、ドクトリンの理論化や弾道ミサイルの登場とも相まって、超大国の軍の中に新しい組織の創設を促すことになった。"

軍事における革命（RMA）とテクノロジーの話 : 地政学を英国で学んだ (via petapeta)

(元記事： geopoli.exblog.jp (nashi-kyoから))

"

フリーソフトウェア運動の中心的存在でGNUプロジェクトを導く世界的に著名なプログラマーのリチャード・ストールマン氏が、GNUプロジェクトに参加するすべてのプログラマーに向けて、「他者を思いやる寛容的なコミュニケーションをとること」を求める「GNU Kind Communications Guidelines」を発表しました。ソフトウェア開発の舞台に存在する摩擦や軋轢はソフトウェアにとっての、ひいては世界にとっての大きな損失であり、他者を尊重することの大切さを説いたガイドラインは、ソフトウェア開発者だけでなく多くの人が読む価値のある提言になっています。GNU Kind Communications Guidelines - GNU Project - Free Software Foundationhttps://www.gnu.org/philosophy/kind-communication.html
ストールマン氏によると、「非友好的で不快で拒絶的で、ときに過酷なコミュニケーションのパターンが存在することで、GNU開発への参加を避けてしまう開発者がいる」とのこと。性別、人種、宗教、文化的背景、政治的な見解など個人的な特徴や思想にかかわらず、GNUシステムの開発を進めることを奨励するために、ストールマン氏は「他者を尊重する心あるコミュニケーションが大切である」と考えています。そのため、GNU開発者には、以下の具体的な方法を実践して目標を達成してほしいと、開発者としてあるべき「心構え」や「姿勢」を説いています。1：他人の「仕事」に敬意を払う
たとえ他の参加者の発言に同意できない場合でも「彼らは誠実に投稿している」と仮定してください。コードやテキストがその「仕事」として提示されているときは、それを「仕事」として受け入れてください。「もしかすると間違っているのではないか？」という他人が犯したかもしれない疑いによって批判することはやめ、実際に何を話し、実際に何をしているかに固執してください。2：その人自身に敬意を払う
「敬意をもって他の参加者を扱う方法」について考えてください。同意できない人に対しては特に、です。例えば、他の参加者に話しかけるときに、その人が提示している名前で呼びかけてみてください。性の多様性を尊重する上でも、(彼や彼女などの代名詞ではなく)その人の名前で呼びかけるのは重要です。
他の参加者に対して厳しすぎるトーンを向けるのはやめてください。特に、個人攻撃は避けるべきです。「発言」を批判し、決して「個人」を批判しているわけではないことを示すべきです。
3：批判にも敬意を払う
自分の意見に対する批判は、決して個人を攻撃するものではないと認識してください。誰かが攻撃してきたと感じたり、たとえ誰かが尊厳を攻撃したと感じたとしても、それに反撃しないでください。それは、言葉を拡大解釈した攻撃の連鎖を引き起こす傾向にあります。感情は感情として述べつつも、平和を求めてください。物事を鎮めるために、1時間あるいは1日経って怒りを取り除いてから、あらためて返答してみてください。4：間違った人をフォローする
誰かが失敗したことをとがめられている場合、特にその人に対して親切にしてください。プログラミングとは多くの間違いを犯すことを意味しています。実際に私たちはみな間違いを犯しています。回帰テストが有用なのはそのせいです。誠実なプログラマーは間違いを犯して、その後に修正します。「完璧でないのは普通のこと」と示し、問題を修正し解決してくれるようフォローし、不完全な貢献に感謝を示してください。
5：テーマから外れない
議論の中で誰かが「脱線」しようとしているときは、今のトピックに焦点をあてて議論を進めてください。これは決して「脱線が悪い」ということではなく、また「議論が面白くない」ことを意味するものでもなく、「当面の問題に干渉してはならない」ということです。脱線については、別の場所で議論すべきということです。6：終わりを明確にすることはない
議論を終わらせる「最後の言葉」を求める必要はありません。「もう返信が不要だ」と判断するタイミングを探してください。おそらく関係するポイントが明らかになっています。囲碁を知っているなら、勝負が決着した時に敗者に直接的な反応が必要ないことを知っているかもしれません。何も言わないで、代わりに別の場所に行ってもOKです。
また、すでに議論が終わっているのに不必要に議論を蒸し返すのはやめてください。それは、活動の進展を妨げる傾向があります。7：不快にさせないことは説得につながる
アイデアの表現の仕方について、他の参加者が不満をもっているなら、どうかそれに応じる努力をしてください。同じことを、他人に心地よいように伝える表現をみつけられるはずです。他人の怒りをかわないことは、他人を説得する可能性を高めるものです。

上記はGNU Kind Communications Guidelinesの中からGNUプロジェクトに固有の問題を除いた提言ですが、複数の人が協力して進めていくことが求められるあらゆるプロジェクトを成功に導くためのコツにもなっていそうです。

GNUプロジェクト提唱者のリチャード・ストールマンによる「心あるコミュニケーションのガイドライン」が発表される - GIGAZINE (via petapeta)

(元記事： gigazine.net (nashi-kyoから))