自由に回転する回転翼が付いた荷物をベランダから落すと、 普通に落すよりも、回転翼が回りながらゆっくり落下します。 荷物からみれば、回転翼によって揚力(浮き上がらせる力)が働いているわけです。 荷物はそのうち適当なスピードに落ち着きますが、 これが荷物の重さと回転翼の揚力がつりあった状態です。
もし、それだけの風が下から吹いて来れば、荷物は浮いていられます。 この速度を V (←大文字) とします。この値は回転翼が同じなら、概ね 荷物の重さだけで決まりますので 飛んでいる最中はまず一定という事ですから、 定数風味を加えて大文字で表記するわけです。
オートジャイロの回転翼の軸は若干後ろに傾いているわけです。 進行方向と、この傾き軸のなす角を図のとおり、αとします。 機体後部のプロペラによる推進で、前方に速度vにて前進しているとき、 回転翼には下から速度 v * cos α の風が吹きます。
もし v * cos αが V 以上であれば、機体は浮くわけです。
推力が無くなっても、回転翼が止まってしまわない限り、 たかだか速度Vで降下するだけです。 また回転翼のジャイロ効果(角運動量の保存)にもよって、 挙動は非常に安定しています。 つまり比較的安全な空の乗物でもあると言えます。
御教授いただいたラック様、ありがとうございました。
開発経験といってもたいしたものは無いので、 そんなに面白い人に出会ったわけではありませんが…
地雷君は自分では何もしない。 爆発する必要すらない。 地雷君はただ、最初からそこに居る。 それだけで地雷君は所与の目的を達成する。
最初に学んだプログラミング言語のスタイルは あとをひくものだが、それにしても度が過ぎている奴というのは居るものだ。 ほとんど全てのコードが同じインデント位置に並び、 全ての変数が大域変数の、 そのまま basic に翻訳できそうな perl ruby python lisp (何でも好きな言語を入れてくれ) のコード。
彼は一見すると怠け者にはとても見えない。 だが、なにがしかの選択を迫られた時に次のような振舞をとることで、 それを見分ける事ができる。 すなわち彼は、二つの選択肢のうちAをとることでどんなリスクとコストが 発生するか十二分に雄弁かつ説得的に、その選択をとることが 愚劣さのこのうえない証明であるかのように語る事ができ、 一方のBをとることで、ほとんど予測不可能な開発期間と 人員とライセンス料が必要になることを、 これまた十二分に雄弁かつ説得的に語る事ができる。 だがそれらをどうやって克服するかについては決して、 一言も語らない。つまり、言ってる事はそれなりに立派だが、 彼が本当に言いたいのはズバリ「何もやりたくない」という事だ。
徹底的に調子の良い事を言うが、 こいつにはどんな些細な事も安心して任す事は絶対にできない。 こいつに物事をきちんとやらせるためには、 完全無欠な管理が必要だが、 そのコストは自分で全てやるという選択をとった場合に要求される労力を軽く上回る。
代入、ループとif、ポインタ、再帰のどれかで 何かを間違ってしまった奴。
彼は全ての段階が想定外にうまくいくという仮定を使う。 ここで彼に可能な論理演算は and だけである。 数値演算では、コストやリスクや時間には常に算出可能な最低の値を用いるが、 性能や市場規模には算出可能な最大の値を用いる。 この想定が誤っている事が判明しても無論、彼は何もしない。 何かができるほどの者は、そもそもこんな想定はしないからだ。
無論、今の職場にはこんなの一人も居ませんよ。 むしろ私が困ったちゃんですからね。
プログラムとは思った通りに動かないが、 書いた通りに動くものだ。しかしこれには例外がある。 彼の思った通りにプログラムが動くのだ。
おなじみの空挺部隊だ。 彼等が違うのは、技量というよりもむしろ覚悟の量と質である。 彼等にとっては、四方を敵に囲まれているのが自然なのだ。
チューリングテストにパスする万能チューリングマシン。
私が先任ホゲリ軍曹のハートマンだ。 以後、話かけられるまでコーディングをやめるな。 口からクソたれる前とあとにコードを書け。 貴様等が私の訓練に生き残れたら、各人がevalとなる。 高階帰納関数に祈りを捧げるlambdaの司祭だ。 だがそれまではvoidだ。 貴様等は人間ではない。 mallocのカスをかき集めた価値すら無い！ ケツから read() するまでしごいてやる。 CPUでファックするまでしごきたおす！ ポインタのクソをひねりだせ！ さもなくばクソ地獄だ！
最近、ちょっとしんどいスケジュールがしばらく続いていると すぐに「デスマーチ」という用語が使われる傾向があるように思う。 ところでデスマーチといえば私です。 ここらで一つ、私がデスマーチとは何か、という事を明確にしておく必要があるようだ。
予算や人員が半分とか機能が倍とか、そんな定量的な基準は、 この現象の本質を掴んでいない。
まず、以下の条件が必要だ。
これが単一のプロジェクトについて複数回、半年以上の期間にわたって続いている事が必要だ。
納期に向かって最大限に資源を集中し、頂点に向かって全てが凝集している最中に、 ゴールが一ヵ月先に移動し、仕様も変更され、 それに伴って実装もテストもハードウェア構成も変更される。 そして再び新たなゴールに向かって全てを集中していく、 というプロセスに入るわけだ。 無論、この新しいゴールもまた絶対不可能な納期なわけだが、 その一週間前に、またしても仕様変更が起きる。
これが3度起きると「これは絶対、永遠に終らない」という認識を プロジェクトの全員が、共有するようになる。
だが、これだけでは「デスマーチ」とは認められないのである。残念ながら。 こんなのは普通によくある、ちょっとしんどめのちょっとダメめなプロジェクトでしかない。
このプロジェクトがデスマーチと呼ばれるためには、 居なくなる奴が必要だ。 それもズバリ言って、プロジェクトのキーマン、彼なくしてはそもそもこのプロジェクトは ありえなかったという人物、彼が(理由は何でもいいが、 多くの場合は犠牲の小羊として燃え尽きて)居なくなるという事が必要なのだ。 しかしそれでもプロジェクトは中断されない。 ここで初めてそのプロジェクトがデスマーチと化す。
キーマンが居なくなり、もはやどこへ向かうのかも判らない。 いつ終るのかも判らない。 ここで下克上を一発きめてキーマンにとってかわり、 見事着地させるという可能性も無いわけではない。 魔法使いと空挺とマシンと鬼軍曹が居ればそれも可能だろうが、 そんなのが居ないからこうなったわけで、 現実には控え目にいっても極めて難しい。 つまりこのプロジェクトから解放されるためには、プロジェクト自体が消滅するか、 自分も燃え尽きて居なくなる必要があるだろう。
これがデスマーチだ。 だからデスマーチの「デス」は比喩ではない。 実際に生命に危険が及ぶ可能性はかなり高い。
いわばデスマーチとは卵子に向かって突進する精子である。 大半の精子は受精できずに力尽きる。 ただ一つの精子だけが卵子まで到達し、「プロジェクトX」として報道される。