  |
はてなキーワード: パイプラインとは
げんきであかるい、いっしょうけんめいな担当者。
社会ではまだまだ若手も若手に属する20代前半の武器は多分こんなもの。
期待にこたえるために頑張ってきた。
だが、ここにきて疲れた。
締め切り守らないデザイナーへの催促も、
同僚の進捗確認も、
すべてが面倒くさい。いきることですら。
かんじにへんかんするのもめんどうくさい。
たいぴんぐ も めんどう だが もうすこし。
よかれとおもったことがうらめにでる。
きたい された こと に こたえられない くやしく かなしく みじめで ひりき で
おのれの むりょくさに なすすべもなく。
３０００年、ただひたすらねていたい。
第一に、発端となった元ツイートには「非エンジニア新卒女子」とはっきり書いてあるのに
《旧式言語を学ばずに関数型言語一本槍でエキスパートを目指すような感じの方》
《「まず軽く触れてみよう」とか「趣味でやってみるか」といった程度ならいいのですが》
《実際には肝心なことを何も知らないのに、なんか知っていると思い込んでいる状態が、私いわく「脳味噌膿んでる」》
ひどい書きっぷりだよね。
もし自分が当事者だったら「見ず知らずの人になんでここまで言われなきゃいけないの」と傷つくと思う。
第二に、下位層のレイヤーについて知っていなければ上位層のことをちゃんとやる資格がない
という態度が明らかに本人のダブルスタンダードっぷりを示している点
と言いたいのだと思うけど、最近のCPUはマシン語に書かれていある命令をそのまま実行しない。
インテルの場合もCISCの命令セットで記述されたコードをRISC的なマイクロコードに分解・解釈して実行する。
さらに内部はパイプライン化されているため、単純に「１命令ずつ逐次実行」されてもいない。
外側から観察するとあたかもマシン語の命令列をひとつずつ逐次実行しているかのように振る舞っているだけだ。
マシン語のコードで記述されたプログラムが、命令通り入力と出力を繰り返すなら、内部でどのような先読みや予測分岐を繰り返していても問題ない？マシン語の忠実な実行装置とみなしてよい？もちろん回路の設計ミスで誤動作するかも知れないけど、それがプログラマの「根本的な過ち」になる？
OCamlの世界で記述されているロジックが、OCamlの仕様通りにちゃんと動作すれば、その下位層にあるマシン語がどういうパラダイムで記述されていても関係ないと考えていいと俺は思う。
余談１
くだんの女子について、周辺のツイートを見てみると（完全に部外者の憶測だけど）Railsを主力とするソフトウェア企業に非エンジニアとして新卒で入社した新人がプログラミングに興味を持ったのに対して上司がOCamlの本を教科書として渡したのでそれを学んでプログラミング考え方を身につけた。その後Railsについても学んでみようとしたが、考え方のギャップに強い違和感を覚えた。…という経緯みたいだ。
余談２
https://twitter.com/camloeba/status/611051620877537281
https://twitter.com/sessoh/status/611052396161183744
このやりとり、拙僧さんが「肝心なこと」と思ってることを卯之助さんは「重要でない」と言ってるんじゃないですかね。
820 ソーゾー君 2015/01/10(土) 03:40:34 S8z9YJTo
陰謀論を語るなアホ。
安部の仲間の香港カキョウが2ちゃんで自民ネットサポーターと茶番劇をやるのは今に始まったことじゃねーだろ？
ロシアのガスをパイプラインで中国に供給の話が纏まったから焦ってんのか？
しかも、支払いはドル建てではなく人民元建てだもんなwこれは発狂するわなw
ロシアはパイプラインを「中国→朝鮮半島→北海道」と繋げる計画だから焦るわなw
中国、北朝鮮はロシアの計画に賛同してパイプラインを繋げるから、
日本は断固として中国、北朝鮮と対立しないとパイプラインが繋がっちゃうもんなw
円建てで支払えるのにアホだろ？
しかも、北方領土２島返還も付いてくるのに自民党と霞が関の糞役人が拒否しやがった。
何故、マスコミが中国、北朝鮮を必死にバッシングするか理解したかね？
日本はガスや石油などのエネルギーを欧米企業に一極依存している。
止められたら終わり。値段も当然、言い値となる。
おまけにドル建てで支払わなきゃならんから大量にドルや米国債を保有せにゃならん。
ロシアのガスや石油がパイプラインで供給されたらエネルギーの依存は一極ではなくなる。
一極なら選択権は無いので言い値となるが、複数の売り手から買うから交渉が出来る。
簡単だろ？
http://jbbs.shitaraba.net/bbs/read.cgi/movie/10043/1414594539/
ベイマックスは見てないけど、それはそうかもなと思う。
一方で、「天才はいない」と言っても、一人一人は日本にいたら天才クラスになるレベルなんじゃねーかなとも思う。
つまり単純に平均レベルが低いということ。グーグルなんかは正にそうで、日本でなら天才クラスの人材が普通に鯖缶とかやってる感じ。
例えばpixarあたりで普通にパイプラインのエンジニアやってるような人間がsiggraphに論文ポロポロ通してたりする。
日本だったら速攻でパーマネントアカポスゲットくらいの業績を挙げている。
最近増田でも打線組む投稿が散見されるので、マイナーどころのファミコンクソゲーで組んでみよう。
家庭用ゲーム機の出現から30数年、携帯ゲームの嚆矢となる携帯アプリの出現から10数年。クソゲーを語る文化もまた成熟しつつある。
そうした文化にこの文章が影響を与えられるとは到底思えないが、まぁ見て楽しんでもらえたら嬉しい。
擬似的な３D空間を探索するゲーム。主人公が腰の悪そうな歩き方をし、移動も遅い。上にしかビームを出せないくせに敵が横からもくる。ヒントも意味不明で音楽も気持ち悪いし壁が目に悪い光り方をする。タカラが生んだ先駆的クソゲー。
https://www.youtube.com/watch?v=tL71-Hsh9lo
坂本竜馬を操作して明治維新をおこそう。前半がアドベンチャーモードで薩長同盟を締結し、後半が戊辰戦争シミュレーション。アドベンチャーモードは中岡慎太郎が強すぎて竜馬を使うことはない。シミュレーションモードは新政府軍が弱過ぎて板垣や伊藤が隣の藩の雑兵に殺されるレベル。そして何故か生きて戊辰戦争に身を投ずる坂本。史実とは？
http://nicoviewer.net/sm4286007
糞。ゴーストバスターズのロゴがあるだろ。禁止マークにゴーストが収まっとるあれだ。あれを動かすゲームなんだぜ。これ。
https://www.youtube.com/watch?v=YxJNXahpPHc
ノストラダムスの大予言後の世界を旅するRPG。最終的に天道という実在する新宗教に帰依せよ、という結論に至る怪奇的ストーリー。宗教的、神秘主義的な世界観は独創的ですらあるが戦闘は連打ゲーであり移動は何故か恐竜で行なう。1989年という時代性、今よりももっと精神や信仰や信奉というものが身近だった、すなわち「オウム」以後に忌避されるようになった若者のスピリチュアルなものへの傾倒の時代を象徴するクソゲー。こうした意味で、もう現れない時代性を反映した記念すべきクソゲーなのだ。
https://www.youtube.com/watch?v=H_rYG_ZM4Oo
ファミコンのパスワードは長い。特に長いものにこの『覇邪の封印』と『ドラゴンクエスト2』とがあるが、その評価には著しい格差がある。主人公に付いてる妖精の性格が悪く、ヒロインを憎悪しておっさんを贔屓する。悪徳商人を殺す王道ファンタジーRPG。
https://www.youtube.com/watch?v=aKe7yIqj4TY
すまんこれは名作だ。ゲームの歴史上、「攻撃して倒すゲーム」が主流のなか「最後まで守りきる」ゲーム。そしてかなり難しい。それゆえクソゲーと揶揄されるが、本当はとってもソリッドなゲーム。女の子はかわいいし、実際難易度も凝りに凝っている。
https://www.youtube.com/watch?v=cBmHNRZBZsY
マップと実際の道路が合っていない。マップ見ないで画面で覚えようにも、道路が変なところどうしで繋がっている。プレイヤーはマップと実際の画面とを総合して、自分の心の中でゲームの空間をイメージせねばならない。
https://www.youtube.com/watch?v=L2ABLQKHHCU
プーチンが領土欲を露骨に発露する2014年現在、再評価も求められるゲーム。なぜか水道管を東京モスクワ間で結ぶ。石油じゃねえのかよ。このゲームゴルビーあまり関係ないのにゴルビーの肖像権をロシア大使館に申請し、許可されている。なぜロシアも許可したのか。失敗すると可愛い女の子が投身自殺する。
https://www.youtube.com/watch?v=AC0IKZet0Ds
パリダカに出るために車を調達するところから始める。途中野生生物を倒したり、内戦中と思しきアフリカ国家を通る。荒唐無稽な出来なのだが、どこか「これがパリダカの雰囲気か」と思わせる説得力があるクソゲー。もちろん現実のものとは全然違うんだけど。音楽がかっこいい。
原子核の分野やFORTRANの分野で技術の継承の何が失われているのかはわからないんだけれでも、
私が考えるに、現在の「原子炉の設計（利権込）の技術」が失われることで、
今まで切り捨てられていた別のタイプの原子炉にスポットが当たるということはないのだろうか？
自然環境の変化で、恐竜のような大型生物がほろんで、小型の哺乳類や小型の爬虫類がいきのびたような。
FORTRANはどうするかね。「動いているものは変えるな」の原則からすると、絶滅を待つしかないのか。
下水道とは何か。
・
放流される水は、冗談抜きで途上国の上水よりもきれいだったりする。
そのまま上水の水源に使ってもトラブルが起こる確率はそれなり低いとは思う。
・
雑に言えば、大きな誤解を生むと思うけど、実は上水も下水も処理としての根本は同じだ。
水中の浮遊物や生物などを濾し取る。
その方法として、水圧をかけて砂の中を通すとか（急速濾過）、自然流下で砂の中を通すとか(緩速濾過）、一度深いプールを経由することで不純物を沈めるとか(沈下槽)、薬品や紫外線で殺菌をするとか、凝集剤で不純物を固めるとか。基本的に酸素を豊富に含ませれば水は勝手にきれいになる。
・
砂の中を通すのは、正確には濾し取るのではなくて細かい不純物を砂に吸着させるとかなんとか、話が脱線するのでこの辺はつっこまない。
・
ともかく、下水道が整備されるということは、汚水が河川や海に流れこむ事を防ぎ、伝染病の発生リスクを大幅に下げる事でもある。
当然、人口密集地で発生した汚水を速やかに処理場に送るため、悪臭も著しく押さえられる。
というわけで、浄水施設とケーブルテレビなら浄水施設を先に整備するべきだと僕は思っている。
・
その上で、下水道の普及を推進する政策への懐疑がある。というよりも、あれは失敗した政策だったとおそらく関係者はみんな思っている。
・
庭先に設置する浄水施設だ。
これは、イメージされる下水処理施設と機能は同じ。小型版と思ってもらえば間違いはない。
個人で所有し、汚水を個人の責任で浄水し、排水するわけだが、設置に土地がいると言うこともあり、都市部では設置が難しい。その上、大量の汚泥を各所で浄水するのは効率が悪い。
・
ところが、国はこれを過疎地域にさえ整備しようとした。
しかも、法律で下水道に設置するには合併処理浄化槽をコンクリートでつぶさなければならない。
300人分浄水能力を持った施設に、50人分の汚泥しか流れ込まないとバクテリアが餓死して浄水能力は大きく損なわれる。
その上、施設の維持自体にも過大な費用がかかる。受益人数に対すれば異常なほどの税金が投入される。
もちろん、施設自体も寿命があり20年もすれば立て直した方が安くなるほど維持費がかかる。
いっそつぶしてしまって合併処理浄化槽に戻した方がいいとわかってきてもすでにつぶしてしまっている。
かくして戻ることも出来ずに金食い虫を抱えた過疎の自治体が全国にたくさんある。
簡単に予想できた事でも、国はそれを推進し、大量の資源を資金を無為にした。
・
両方経験できたので書く。
いいところ：
(2)基本頭の良い人、仕事出来る人だらけ。
(3)金で解決できることは、無駄でも何でも、即、金で解決。担当が簡単に使える金は2～3桁違う。
(4)イメージが良い
(5)外国人もたくさんいる、海外企業とのやりとりもじゃんじゃん。
(6)意外と給料高い
(7)イメージに引かれて寄ってくる人が多いので、採用もそんなに苦労せず贅沢な事が可能。
(8)女の人美人、男の人イケメン揃い。（たまに、顔とスタイルで選んでんじゃないのか?と思うこととても多い）
(9)食堂がかっこいい。
(11) 世間様が思う「ちゃんと仕事が出来てますね」というレベルを維持するのに、どんだけたくさんの人的リソースと、お金がいるかがよく分かる。
わるいところ：
(1) みんな頭良すぎる／能力高すぎるので、大変窮屈。ちょっとの手抜き、失敗も大変しにくい。
(2) お金と人ありすぎるためか、政治競争がすごい。権力争いも組織単位で行われるのでケンカのレベルが違う。
(3) 新しい事が大変しにくい。仕事の流れにちょっとでも異変を起こそうとすると、まわりに与える影響があまりにでかすぎるので批判殺到で即つぶれる。
(5) 下請けシバキが凄すぎ。たまに下請けきっと死んじゃうんじゃないか?とか思う。（でも代わりの下請けも日夜補充されるぐらいいっぱいいる）
(6) やることでかい、組織の効率と仕事の流れが良すぎるので、基本仕事量多すぎ。担当者がつぶれない限り、めちゃくちゃな残業量になり、それが何年もずっと続く。
(7) 普通には調達が大変難しい規模の金額のやりとりの仕事が多いので、会社で得た経験が会社放り出された後に役立つか？
といわれると、クソの役にもまったく立たないと思われ。
(8) スキル大変身につけても、同じかそれ以上の人もいっぱいいるので、霞んでしまう。
(9) 中途の人は配属部門で必要なスキル／知識／暗黙知がないと、漏れなくいじめられ続ける。そのいじめも、学校で起きるいじめのような陰湿っぷりになる。
(10) 新卒が育つかは運に左右されすぎ。まあ、一人で生きていけるような育ち方ができるかは相当に運がないと正直絶望的と思った方がいい。
(11) 人で本気で困ることがないので、採用の合否の理由がめちゃくちゃ。どうみてもスキル／能力あるという人ですら、人当たりにちょっとだけ癖が
あるだけで、それが理由で問答無用で落とされる。合格するのは、スキル／能力が高い「のに」、当たり障りのなさそうな人ばかり。
(12) 仕事の担当範囲がはっきりしすぎていて、ちょっとでも枠越える動きが出来ない。
(13) 経営層との距離が遠すぎ。話が出来るレベルになるまで、時間かかりすぎ。
2. ちっこい～300人規模の企業
いいところ：
(1) 面倒見が良い人が多い。
(2) 人が育つ。（育ちがよく育つかはまったくわからんが、一人で社会に放り出されても、たくましくやっていけるでしょうね）
(3) じつは仕事に波ができるので、死ぬほど忙しい時と、暇な時がちゃんと来る。
(4) まわりに与える影響が少ないので、新しい事は大変しやすい。
(5) 出世は楽勝。ちょっと頭よいか、よいところがあればすぐにリーダシップとれる。
(6) 人一人、何役でもこなし、出きることは何でもやるし、やれる。
(7) 自分でも頑張れば出せるような金額のお金で仕事するので、いろいろ節約の知恵がつく。
(8) 経営層とすぐに話ができる。
(9) 人の流れが激しいので、いじめが発生しにくい。
わるいところ：
(1) 基本的にお金がないので、とにかくアウトプットも含めて安い仕事が多い
(2) 人材がくせありすぎ。バカが多い。意識低い人が多いので、人の能力で大変苦労する。
(3) 給料が安い。
(4) お金の力を知らない人多すぎ。
(5) 仕事のアウトプットが非効率。お金と人材がないから、効率的に仕事のパイプラインを用意出来ないため、途中工程の人はすぐ暇になったりする。
(6) 世間様のいうちゃんとした仕事は、金と人的リソース用意出来ないので、無理。でも、60点とるぐらいのレベルの仕事なら可能。
(8) 会社存続にかかわる危機感だけは高いくせに、金/コネがなさすぎて具体的に何も出来ない。
(10) お金の流れる仕組みを作るために必要なお金が揃えられないので、なにも出来なくて悶々とする事が多い。基本ニッチ分野しか狙えない。
(11) 下請けシバキはめちゃくちゃぬるい。シバクと付き合ってもらえないので。
世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。
いや実際に "ない" というのはかなり語弊があるかもしれない。
しかし、通常この種の説明している本に辿り着くまでには多くの時間が必要だ。
普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要な概念を獲得するのだと思う。
例えば、「計算機プログラムの構造と解釈」や「実用 Common Lisp」、「コンピュータプログラミングの概念・技法・モデル」などの書籍は現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。
しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。
そして、"普通のプログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。
僕はそうは思わない。
というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムとデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。
授業で出された宿題だったり、人それぞれだろう。
このような目の前の問題を解決したい人達が、わざわざ Lisp や Mozart など何の役に立つのか分からない言語を、根気よく勉強するのだろうか。（ちなみに、Lisp や Mozart は上記の書籍で実際に使われている言語である。）
新しいプログラミング言語を学ぶことや、プログラミングの種々の概念を獲得することではない。
もちろんプログラミング言語を上達するためには一つでも多くの概念を会得する必要があるので、あるレベル以上を目指すのであればこれらの書籍を読むことや、抽象化を実現するための様々なツールを手にすることは必須だと思う。
純粋にプログラミングを楽しんでいる人やハッカーを目指したい人はこのような文章を読むのではなく、ぜひ上記に挙げた本を実際に購入し、自分の手で動かして確かめてみることを勧める。プログラミングに対する考え方や姿勢が変わるのは間違いないと思う。
今回はそのような”純粋にプログラミングを楽しんでいる人”に向けた文章でない。
現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。
そのような人の中で、なかなかプログラミングが上達しないという人に向けた文章である。
もしプログラミングの学習に限界を感じているのであれば、プログラミングの学習方法が間違っている可能性が高い。
そして残念なことに、初学者向けの書籍では、"プログラミング言語の文法" を説く本はあれど、"プログラミングの学習方法や上達するための正しいスタンス" を説く本はほとんどない。
できるだけ多くの人にプログラムをする楽しみを知ってもらうためにも、
より多くの人がより生産的にプログラムが出来るようになるためにも、
そして特に、右も左も分からなかったプログラミングを始めたばかりの過去の自分に対して、
効果的な学習方法やプログラムする際の指針を書き記したいと思う。
それらは単に指針を示しているだけなので、
どんなプログラミング言語を使っていようとすぐに実践に移せるはずだ。
後はどれだけそれを実践に移し地道にプログラミングしていくだけである。
正しい努力と、ちょっとしたコツさえ知っていれば驚く程生産性を挙げられるはずだと確信している。
プログラマのレベルを以下の 3 つに分けてそれぞれについて説明していきたい。
・使えるプログラミング言語は一つだけ
ただし以下のことは出来ない。
・500行以上のコードが書けない
2. 中級者レベル
・1つ以上のプログラミング言語は使える
・オブジェクト指向は理解している
ただし以下に当てはまる。
・自分が制作しているアプリケーション向けに "実用的なフレームワークやライブラリ" を書けない
・1万行以上のコードだとスパゲッティコードになり、保守不能になる
・適切なサブルーチン化できない
3. 上級者レベル
・プログラミング歴 3 年以上
・現実の問題に対して適切なデータ構造とアルゴリズムを選択できる
・抽象化について理解し、可変部分と不変部分を考慮した設計ができる
またそれぞれのレベルをクリアするには明確な壁がある様に思う。
これらの壁を超えるにはどうすればよいかを説明する。
前置きが長くなったが、以下ではまず初級者レベルの人に向けた具体的なアドバイスをする。
完全に初心者レベルの人はまずどのようにプログラミングを行えばよいのか分からない。一行も書けない。そのため、必然的に以下のような行動を取ると思う。
・本に載っているプログラムをそのまま書き写す（いわゆる写経）
上のような行動を行なっているだけでは、いつまで経っても自分でプログラミングが出来るようにならない。
なぜなら上記のプロセスでは決定的に重要なことが学べないからだ。
それは、【プログラミング言語のモデル】を自分の中に作ることである。
それは普通の言語と同じように文法が存在し、そのしきたりに沿って記述しなければならない。
そのしきたりを学べば書けるようになれる。非常に単純だ。
それなのに、なぜいつまで経っても書けないのか？
それは、”書き写す・コピーする” だけでは、そのしきたりが習得できないからである。
特に最初のうちのプログラミングは頭を作業使う作業でなく、むしろ "体で覚える" 類のものである。
それは例えば、日本語を話すことと似ている。
友達と会話する時、頭を使っているだろうか。
それは簡単な受け答えについては体が覚えているので、考えるより先に日本語が出てくるのではないだろうか。
プログラミングも同様に頭を使うのではなく、こうしたい時はこう書く、という反射神経を育てなければならない。
もちろん日本語話せるだけでは、ミーティングでプレゼン出来ないのと同様に、文法が出来ただけではプログラミングが出来るとは言えない。しかし、文法が出来ないと "現実の問題に対処するソフトウェアを作る" というレベルには到底進めない。そのために、まずそのような文法の反射神経やパイプラインを頭の中に作る必要があるのだ。
・"何をしたい時" に "どう書けば正しく動くか" というデータベース（プログラミング言語のモデル）を自分の中に作ること
このままでは抽象的すぎるので、このような "データベース" や "考える習慣" を自分の中に作るための具体的な指針を以下に挙げる。
1. エラーをたくさん出す
2. デバックの仕方を覚える
3. 小さく動かして確かめる
4. Google を使い倒す
つまり、小さく動かして、エラーをいっぱい出し、デバッグを素早く行なって、分からないことは google などの検索エンジンで解決する。これが上達のコツである。
これらについては以下で詳しく説明するとして、
無理して覚えなくてよい。
プログラマは覚えることが星の数ほどあるので、メソッドなどはリファレンス片手に検索できればよい。
よく使うメソッドなどについては自然に覚えていくので、積極的に覚える必要はなし。それこそ、"体" で覚えるはずである。
覚えられないメソッドについてはそもそもあまり使わないから覚えられないので、重要性は低く覚える必要はない。
むしろ実現したい処理が既にメソッドや関数として提供されていないか、調べる力の方が大事。
・エラーがいっぱい出てつらい
全く問題ない。
・写経をしなければならない
教科書や本の中に書いてあることをそのままエディタで書き写し、実行することを写経という。
上記でも述べたように、これからあまり無駄な努力をしないことを願って言えば、
写経して書いた 10000 行のプログラムより、自分で考えて書いた 100 行のプログラムの方が遥かに意義がある。
そこに "言語のモデル" や "思考" が伴わないと意味がない。
”思考” が伴わないとただの書き写す作業をしているだけだ。
自分の中に "モデル" が出来ていないので、いざ自分でプログラミングしようと試みても、写経をしているだけでは全く書き出せないだろう。
写経はそもそもプログラミングに対するスタンスやプロセスそのものを勘違いさせる危険性をはらんでいるいる。
写経する場合、書き写しの間違いがなければプログラムは問題なく動く。
しかし実際のプログラムではコンパイルや実行するまで、そのプログラムが期待通りに動くかどうか、は絶対に分からない。
そして通常は一気に全てを書き上げるのではなく、まず小さなコア部分を書き、少しずつ他のコア以外の部分を書き上げながらプログラムを完璧なものにしていく。
書き間違えさえなければ正しく動くと知っているプログラムを、上から一行ずつ書いていくプロセスとは正反対だ。
また、以下で述べるようにエラーが発生した場合のデバッグ作業は非常に重要であるだが、そのための作法も写経から学ぶことができない。
なぜならば、写経中にエラーが発生した場合、教科書と自分で書いたプログラムの間違い探しをまず一番最初に行うからだ。これはプログラミングに関する作業ではなく、むしろ間違い探し絵本とにらめっこしているに近い内容である。
それでは、デバッグ方法や言語のモデルを作るとても大切なプロセスを経験できない。
ゆえにそのようにして完成したプログラムもおそらく正しく動きはするが、得られる経験値は驚くほど低いはずである。
とは言え、いきなり自分で書けと言われても書けないと思うので、小さなプログラムを一旦は教科書通り写し、その後自分なりに改変していくのがよいと思う。この場合も写経にはほとんどが意味がないと思った方がよい。"自分なりに改変する" というプロセスこそ意味がある。
今度はどのように "言語のモデル" を自分の中に作っていくかについて説明する。
初心者はエラーを出さない様にと慎重にプログラミングしようとしがちだ。
なぜならば、エラーを出すごとに、その言語の新しいルールを１つずつ学んでいくことになるからだ。
PHP で例えると、
printf の書式だとか
文末に付けるセミコロンだとか
function はネストできないとか
変数には $ を付けなければならないだとか
グローバル変数を関数の中で使う場合は global 宣言するとか
などである。
初心者のうちは一切上のようなルールは知らないはずだからエラーを全て踏むかもしれない。
例え今回作っていたプログラムでエラーを踏まなかったとしても、回数をこなしていけばいくつかエラーに遭遇するだろう。
しかし、それでよいのだ。
エラーを修正することの繰り返しの中で、その言語のモデルが自分の中に出来てくる。
そのようなトライアンドエラーを繰り返えすことで、"言語のモデル" は文字通り体の中に染み込み、プログラムをだんだんと書ける様になっていく。
おそらくこれはは自転車に乗れるようになるプロセスと似たようなものだと思う。
誰しも最初は上手く走れずに転んでばかりいるけれど、何度も何度も転んで起き上がってを繰り返しているうちに少しずつ多くの距離をこげるようになっていくだろう。
そして最終定期には、難なく自転車を乗りこなせるようなっている。
それらのエラーを地道に１つずつ潰して間違いを訂正していくうちに、少しずつ多くの行数の複雑なプログラム書けるようになっていく。
そして最終的には、自由にプログラミング言語を使いこなせるようになっていることに気付くだろう。
自転車も本を読んだだけで乗れるようにはなれないのと同じで
プログラミング言語も本を読んだだけで出来るようになれると思わない方がよい。
それらはトライアンドエラーの繰り返しの中でしか得ることはできないし、誰かから教わる類のスキルでもない。
そして、プログラミングを行うからにはエラーとは一生付き合っていかなければならない。
早めにそれに気付いて受け入れる必要がある。
実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。
期待しない動作をした時のデバッグという。
まずいちばん基本的で一番重要なデバック方法は printf デバックである。これをまず出来るようにする。
怪しい変数をとにかく printf で出力し、変な値が入っていないかを確かめる方法である。
僕が常々許せないと思っていることは、初学者向けの書籍にはデバッグの重要性やその具体的な方法論が非常に重要であるにも関わらず、それについては解説すらされていないことである。
初心者だからこそ、デバッグの方法論や開発環境をきちんと整えるべきである。
ほとんどの言語処理系では、デバッグ作業を支援する機能を提供している。
分からなければ、"言語 デバッグ方法" でグーグルで検索してみればよい。
例を挙げると、
javascript だったら firebug
各言語にはいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。
これは無益な時間を過ごさないためにも本当に重要な要素なので、面倒くさがらずに開発環境を整えや方法論をマスターすること。
最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。
その理由は簡単で、人間は正確無比に物事を進めるのは苦手な一方で、プログラミングでは正確無比に物事を進めることを要求されるからである。そのため、大きなプログラムを一度も実行せずに作成し、一気に確かめようとするとまず間違いなく正しく動作しない。
そして厄介なことに、大きなプログラムを作ってしまうとどこに問題があるのか切り分けすることが困難になるので、ますますデバックが難しくなってしまう。
そのためまず小さく作って小さく確かめ、部品を組み合わせてプログラムを作っていくことが大事になる。
一般的に言って、どんなに熟練したプログラマーであろうとも、一つのミスもせずに一定以上の大きさのソフトウェアを作り上げることは不可能である。そのため、ミスやエラーはある程度発生することを前提に、少し作っては実行して確かめる、というサイクルをたくさん回す習慣を付ける。
ソフトウェアは一行書き上げた瞬間から指数関数的に複雑性が増大し、気付いた時にはどうにもならなくなっていることも多い。そういう時は思い切って一から作り直すという選択肢も検討してみるべきだ。
"Small is Beautiful"
これは非常に有名な unix （という OS）の設計理念である。
unix の開発者は様々な失敗経験から、このようなソフトウェア開発のベストプラクティスを学んだに違いない。
まだプログラミング経験の浅い人も、これから偉大な開発者の経験から学ぶことができるはずである。"Small is Beautiful"。小さく作って動かすこと。
先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。
おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。
原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。
現実のプログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事な能力とは、実は "忍耐力" だろうと少しばかり思っている。
でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。
そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。
ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。
つ
前のはこれ http://anond.hatelabo.jp/20121219191602
http://toro.2ch.net/test/read.cgi/unix/1036951410/601
601 ：名無しさん＠お腹いっぱい。：2012/07/10(火) 15:04:00.62 今月はじめ、職場に古いパソコン(i486DX2の結構ローエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要がありハードにパソコン系を採用するのは聞いていたの ですが、搬入されたパソコンのダンホール箱に印刷されていたのはPC-9801という 文字でした。 「うへぇ～、よりによって98かよ」 NetBSD/OpenBSDインストール不可、Solarisも不可、SATA-HDDからブートできるのか、 今時のLCDディスプレイにつながるのか、FreeBSD9.xは対応してるのか、 今時のネットに繋いでもセキュリティは大丈夫なのか不安はつきませんし、 非メジャーなのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にそれに触れて刷りこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、唯一コンソールでの漢字ROMによる日本語表示ができたPC-98は大学など 教育機関に浸透していて、日本のパソコン界に多くのバカを輩出しました。 これから私は、おそらくそういうバカが、makeしてもemacsが入らない、 TeXが入らない、firefoxは使えないのか、Rubyが使えないのかなどと、 サバ管気取りの偏ったどうでもいい我侭を言い出し、(だから鯖にするんじゃねーよ、 鯖の常識で話すなつーのに)それと戦わなければならないのでしょう。 そして時代によって決着している、過去20年のパソコン界隈のくだらないそれらの 議論が再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではPC/ATでもSPARCでもPA-RISCでも PowerPCでもなんでもいいですがメジャーかつ現行のマシンにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/992942337/737
737 ：名無しさん＠お腹いっぱい。：2012/09/16(日) 16:27:31.40 今月はじめ、職場に新しい組み込みマシン(ファンレスの結構省電力構成)が入りました。 多分私が開発全般をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要があり、プログラムにアセンブラを使用するのは 聞いていたのですが、添付のサンプルソースコードからチラッと見えたのは LD A,(HL)という命令でした。 「うへぇ～、よりによってZ80かよ」 アドレッシングモード皆無、リロケート不可、使いにくいインデックスレジスタ、 今時の関数引数のスタック渡しに対応できるのか不安はつきませんし、 今の若者はこんなCPU使わないので人材も少なくソフト開発も大変です。 おそらく導入に際して、大学など教育機関で最初にZ80に触れて刷りこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、8bitCPUでi8080上位互換でi8085よりも多くのツギハギ命令を追加拡張した Z80は大学など教育機関に浸透していて、日本のCPU界に多くのバカが輩出しました。 これから私は、おそらくそういうバカが、ADD A,(HL)はできるのにADD B,(HL)は できないのかとか、相対アドレスのCALL命令はないのとか、 スタックフレームポインタとして使いたいのにLD HL,SPっていう命令ないじゃんとか、 アセンブラ通気取りの偏ったどうでもいい我侭を言い出し(だからZ80使うんじゃねーよ) それと戦わなければならないのでしょう。そして時代によって決着している、 過去30余年のCPU界隈のくだらないそれらの議論が再現され、それに巻き込まれるの でしょう。もう今からうんざりです。 だからお願いです。教育現場ではi386でもi568でもi686でも x86_64でもなんでもいいですが現行のCPUにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/1011306728/134
134 ：名無しさん＠お腹いっぱい。：2012/07/15(日) 14:17:53.53 今月はじめ、職場に新しいPC(Core i7の結構ハイエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要があり、X Window System上のアプリケーションを 使用するのは聞いていたのですが、OSを起動して黒いバックに白い文字だけの 英語の画面に表示されていたのはlogin:というプロンプトでした。 「うへぇ～、よりによってxinit方式かよ」 CUIログインなんて古い、コマンド入力なんて古い、今の奴は日本語入力設定大丈夫 なのか(XMODIFIERS)、今時のマルチシート環境に対応できるのか不安はつきませんし、 xinitユーザーが少ないのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にxinitに触れて刷りこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、X11で唯一$HOME/.xinitrcを手書きするというCUI的方法で環境設定できた xinit方式は大学など教育機関に浸透していて、日本のX11界に多くのバカが輩出しました。 これから私は、おそらくそういうバカが、GNOME/KDEはどうやって起動するのか、 ウィンドウマネージャを終了したらXごと落ちたとか、ck-xinit-sessionはないのか などと、X11通気取りの偏ったどうでもいい我侭を言い出し(だからxinit方式にするん じゃねーよ)それと戦わなければならないのでしょう。そして時代によって 決着している、過去25年のX11界隈のくだらないそれらの議論が再現され、 それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではgdmでもkdmでもwdmでも xdmでもなんでもいいですがグラフィカルなディスプレイマネージャにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/1094041299/383
383 ：名無しさん＠お腹いっぱい。：2012/07/12(木) 19:20:13.06 今月はじめ、職場に新しいPC(Core i7の結構ハイエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要があり、制御コマンドとしてシェルスクリプトを 使用するのは聞いていたのですが、そのファイルを開いて1行目に書かれていたのは #!/bin/tcshという文字列でした。 「うへぇ～、よりによってtcshかよ」 ファイル記述子のリダイレクト不可、クオートのネスティング等に無理あり、 今の奴でさえシェル関数は使えないし、パイプラインの終了ステータスもおかしいし、 今時の担当者が扱ってセキュリティは大丈夫なのか不安はつきませんし、 スクリプトとしてのcshは嫌われるのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にcshに触れて刷りこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、シェルで唯一aliasやhistoryやジョブコントロールの機能が使えた cshは大学など教育機関に浸透していて、日本のシェル界に多くのバカを輩出しました。 これから私は、おそらくそういうバカが、$*でスペース入りファイル名が扱えないとか $<でファイルから読めないのかとか、if文の条件式のコマンドでリダイレクト できないのかなどと、シェル通気取りの偏ったどうでもいい我侭を言い出し (だからcshスクリプト書くんじゃねーよ)それと戦わなければならないのでしょう。 そして時代によって決着している、過去25年のシェル界隈のくだらないそれらの議論が 再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではbashでもzshでもkshでもashでも Bourne shでもなんでもいいですがBシェル系のシェルにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
続く。
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}
または
f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}
と書けます。lambda内でreturnが使えますから、書きたければ
f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}
でもOKです。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
自分が言いたかったことは1つなのですが、そこから自分が気が付いて欲しかったのは3つのことなのです。
1つのことっていうのは
なのです。
「原子力は安全」と思っている人にも、こういった事故は絶対起こらない・・・と思っていた人はいたかと思います。
が、3つ目のことから、「原子力は危険だけどある程度ちゃんと制御すれば事故は起こるかもしれないけど安全」と思っていた人の方が多かったのではないでしょうか。
自分はむしろ「原子力は安全じゃないじゃん」と言っている人「事故なんて起こしてけしからん」と言っている人、事故を見て原発を即時停止しろと叫んでいる人こそ事故は100%起こらないと思っていたのではないかと思いますし、そういう人は別の発電方法では100%事故は起こらないと思ってそういうリスクから目をそむけているのではないでしょうか。
実際、火力発電所の事故は、燃料・・・たとえば石炭であれば炭鉱爆発や落盤による事故、石油であれば油田やヤードの火災やタンカーの座礁による原油流出事故、天然ガスならパイプラインやガス田での爆発事故があり得ます。
そういった事故から目をそむけていませんか？という意味でこの記事を書きましたし、原子力は絶対安全なんてありえないから原子力に頼るのはもう限界なんじゃないか・・・と言う意味でもこの記事を書きました。
自分は、「原子力は人が扱えるような代物ではない」と常々思っていました。所謂「パンドラの箱」です。
「原子力は危険だけどある程度ちゃんと制御すれば安全」って言うけど、結局は人が制御できるような代物ではなかったんだ・・・と言う感じでしょうか。
ですが、柏崎の原発が1機止まっただけで夏場に電力不足騒ぎが起こったのですから、原発即時停止は現実的でないように感じます。
まず最初に、今回の地震と津波に際して早くから支援体制を敷いていただいた
食品メーカーの方々
それを高速も動かない間にも届けてくれた運送関連の方々
販売をしていただいたスーパーの方々
現在も被災地への物資提供・医療支援・ボランティアを続けて頂いている
企業や個人の方には感謝してもしきれません。
未だ満足にインターネットや連絡手段が取れない被災地の方に代わりまして
御礼を申し上げます。
また、地震発生時から燃料不足など困難な状況でありながら
昼夜問わずインフラ復旧の為に当たっていただいた電力水道ガス道路関連の方、
市ガスに関しては現在も名古屋ナンバーや大阪ナンバーなど遠方からも
現在も支援を頂いている状態です。
余震による新たな再点検を求められるといった苦境が続いておりますが
自身の安全も含めて無理を成されないように。
市ガスに関しては仙台の天然ガス施設が被害を受け、新潟からのパイプラインで提供されています。
下水についても今回の津波で破壊されたり電子系統がやられた関係で２～３年は簡易処理しか出来ない状態です。
宮城県に限らず被災地を抱える県の方で処理場が機能してない地域の人は
自分たちは水が使えるからと今までのような使い方をしてしまいますと
疫病が発生する可能性も否定できませんので節水に努めましょう。
津波で下水処理場、ゴミ焼却施設に大きな被害、想像を超える宮城県内各施設の被災状況(2)
下水道復旧は数年かかる見通し 沿岸部に集中、被害深刻
http://www.asahi.com/special/10005/TKY201104020353.html
＞下水管や処理場が復旧しないと、汚水が路上にあふれ疫病を引き起こす恐れすらある。このため新潟、札幌、大阪など自治体の下水道事業者からのべ２６００人が応援に駆けつけ、被災状況の調査や簡易処理での復旧の手助けをしている。
過ちを繰り返さない為に。
私が住んでいた地域は幸いにも地震から２日後という
早期に電気の復旧が行われた為、
手元にあったIS01のワンセグテレビと充電池でギリギリ間に合わない程度で
情報難民にならずに済んだという綱渡り的状態だった。
その間もワンセグで見ていた、地震だ！津波だ！何人が死んだ！
在京キー局主体報道が並ぶ。
そして思った。
それを今、報道してどうなるのだ、人一人も助けられないじゃないか。
家族や親戚が居ても津波の被災地に行く手段は無いのだ。
津波による第一報の大切さはわかる。
でも、それが終わったら次の事を考えなきゃいけない。
死ななかった人の命を如何に助けるかだ。
まずは
車での移動はしないでください、
不要不急な人には売らないでくださいとマスメディアは伝えるべきだった。
緊急車両だけに、と。
更に３０分歩いて帰宅していった。
－
自宅の電気が１３日夜に復旧した翌日の１４日、
電気が復旧したテレビで見た情報が計画停電発表による東京での買い占め、
計画停電の影響で弁当やパンなどがいつも以上に売れる事は別におかしくないと
最初、連日の報道に何やってんだかという呆れがあったが
次の瞬間、恐ろしさに気づいた。
そのガソリンや軽油が届かない事で間接的に救える人を殺しているのではないかと。
共に千葉のコンビナートが被害を受けたことによる需給バランスが崩れた為だ、
それにすぐ届く訳じゃないと思いながら軽い怒りと
地震が起きる前に石油精製の設備が余ってるという情報を報道で知っていたから
どちらなんだろうという不安が感じた事を憶えている。
後に撮影した写真を確認しながらに
仙台でも地震発生後に冷静さを失い
自分が良ければ、家族は大丈夫だろうかという感覚で
間接的に人を殺したかもしれないという意味では
仙台も同じだなと人の事言えないじゃないか思い直した。
仙台港石油コンビナート鎮火 「在庫配分、被災地優先」宮城知事
http://www.kahoku.co.jp/spe/spe_sys1062/20110316_39.htm
この１５日緊急車両優先と宮城県知事が指示するまで
仙台で起きた事は地震発生翌日後ガソリンスタンドが自主的に行なった
一般車ガソリン５L１０L規制＋
整理券受け取りまで朝方から４時間待ちで受け取り午後３時といった
自主規制だった。
－
次に重要なのが生活情報だ。
給水車は何処に出てますと行った情報もテレビのL字に載り始めたのが１３日か１４日
後に知ったがラジオの方が生活情報を流すまで早かったとの事。
そして情報を得る為に重要な電池。
準備はしていたつもりが充電池の自己放電で３セットの内１セット、
しかも半分程度しか残量が残っていなかった。
これが今回の最大の危機であり、認識の甘さが露呈した格好となった。
頑張れ日本、がんばろう日本と言い出したのは３月２０日
http://woman.infoseek.co.jp/news/entertainment/story.html?q=20110320hochi169
http://mainichi.jp/select/biz/bizbuz/news/20110320dog00m020025000c.html
ACジャパンのサッカー編はYoutubeの日付を見ると２２日
http://www.youtube.com/watch?v=Pre2YcOROnk
ＡＣが新ＣＭ制作！ＳＭＡＰ、長友ら出演
http://www.sanspo.com/geino/news/110324/gnj1103240505012-n2.htm
http://weblog.hochi.co.jp/tajihouronn/2011/03/post-8942.html
＞青葉区の北仙台のあるスタンドで前日の夜９時から並んだ男性は、
＞翌朝７時半の開店と同時に１０リットル制限の給油に成功。
＞しかし、１１時前には完売となりました。
＞この日給油ができたのは約３００台。
＞後続の２００台以上の人々は徒労に終わりました。
仙台の物資状況 3月21日
http://ffxi.no-blog.jp/2008/2011/03/post_d3bf.html
仙台の物資状況（震災から2週間
http://ffxi.no-blog.jp/2008/2011/03/15_d5e5.html
＞昨日3/26のスーパー （市中心部からバスで20分ほどの周辺部）
POPからみるにミヤギ生協です。
ミヤギ生協はそれでも全国から商品をかき集めていて商品が充実してる方でした。
高速が一般開放された３月２４日がターニングポイントで３月２６日から商品が徐々に入ってきました。
それまでは大根一本３００円、キャベツ６００円、タマゴ４００円といった状態です。
それでも商品が買えた仙台はまだ良い方です。
この頃、津波の被害を受けた被災地は悲惨です、
仮にお金があっても禄に買う所も水も電気もガスもありません。
それで計画停電したから東京目線でがんばろう日本、頑張れ日本なんて言ったら
被災地は見捨てられたと思うでしょう。
それ以前にがんばろう日本、頑張れ日本って誰に言ってるの？
食事も無く、ろくに暖房もなく、薬もガソリンが無く届かなくて
避難所だけで３０人以上亡くなってるのに。
被災者に頑張れって言うの？命を繋ぐ事に精一杯なのに
頑張れる人はもう限界まで頑張ってのに。
意味が分からないよ。といった状態でした。
そんな状態で頑張れなんて言われたら鬱状態になり、
下のような言葉が被災者から出てくるのは仕方がないじゃないですか。
それなのに
＞何でこんな態度でかいの？鬱病つーかただのクズ
とか、他にも叩くような事がはてブに書かれています。
はてブで書けるなって、
人として本当のクズをはてブでこれだけの数同時に見るとは思いませんでした、
ただただ怒りしか湧いてきません。
「『頑張って』と言わないで…」被災地からの悲痛な声。
http://www.excite.co.jp/News/entertainment_g/20110320/Techinsight_20110320_50513.html
＞3月19日の『ニュース 深読み』（NHK総合）では、被災者から次のようなコメントが寄せられた。
＞「電気が復旧し、避難所から自宅を片付けるため家に戻った。あまりの惨状に呆然としていると
＞テレビから、“頑張ってください。”との声がしてきた。何度も何度も。
＞“これ以上、どうやって頑張るの？”と悲しくなった。」
＞「“頑張ってください。”って言葉を聞くたびに、落ち込んでしまいます。」
頑張れとか復興とかって、多分、今言うことじゃない。
http://anond.hatelabo.jp/20110407001402
＞すげぇ言われてるんだけど、CMとかで、頑張れ頑張れとか。
＞ちょっと気を許すと、「一緒に頑張ろう！１人じゃない！」とか言うわけ。
＞いや、おまえら家あるじゃん？そのCM撮ったら家帰ってるじゃんって。
＞仕事もあるじゃんって。
＞「正直、不幸になってくれたら嬉しい」
＞と言われた。
CMについて思っていた気持ちを書いてくれたID:nakamurabashiさんの記事です、
これを読んで今回の事を書く気になりました。
[雑文]なんかいろいろおかしいなーと思った話
http://d.hatena.ne.jp/nakamurabashi/20110410/1302373143
＞なんていうのか「だれが」「だれに向けて」「なんのために」言ってのかまったくわからなかった。
＞あれ、サッカーの日本代表応援してても同じじゃねえかな、って。
＞で、さっき不意に気づいた。まず、被災地の人たちはがんばれない。がんばれるわけない。
＞だって、家とかなくなって、体育館とかで暮らしてて、がんばれるはずないじゃん。
＞じゃあ「がんばれ」のメッセージはそれ以外の人たちに向けられている、と考えられるんだけど、
＞じゃあ、あの大量のがんばれ日本とか強いぞ日本とか団結は日本の力って、いったいなんなんだろう。
＞ふつうの人たちのがんばりの許容量を超えたがんばれメッセージだけが大量に出回ってる。
＞善意搾り出さなきゃいけないってことか。そうやって搾り出された善意どこ行くん。千羽鶴作ればいいん？
この時期に必要な言葉は被災者に向けてなら
いつになったらこの状況を抜け出せるのかという希望です。
頑張ろうという言葉も最低でも食、衣食住が足りて
そして被災者、被災地域の方からの声として出るべき言葉であって
その地域以外からの頑張ろうの強制ではないはずです。
被災地域以外であれば酷い被害状況ですが、
今も命の危険に晒されてながらも助けられる命があるのです、
その命を助ける為にも〇〇日まで我慢してください。というべきだったはずです。
また、どんなに平凡な表現であっても伝えるべき言葉は
頑張れ日本やがんばろう日本、日本の力を信じてるではなかったはずです。
フジテレビがひとつになろうと言ったって情報共有が成されなければ
その言葉だけでは思いをひとつになんかなれないのです。
日本の力を信じてるという意味のない言葉より
まだテレ朝がテレビで、日テレがホームページで言ってるつながろう日本の方がまだ伝わります。
「被災に遭っても頑張ってる姿、助け合う姿、必死に生きようとする姿に感動しました」
「過酷な状況なのに物資の奪い合いも強盗盗難の類も少ない」
何を言ってるんですか、非常に厳しい状態でこれ以上誰も死んで欲しくないと
命があるだけでいいのです。
私も今回の震災で叔父を亡くしました。
今、命がある被災者を全力で支えることができるのは生きて無事な人間だけじゃないですか
被災者を頑張れる環境まで持っていく事が今できる我々の責任じゃないんですか。
死んでしまったらどうしようもないんです、取り返しは効かないんです。
また日本では同じように大震災といわれる事が起きるでしょう。
その状況の時に今回と同じ事を繰り返してはいけないのです。
－
備蓄について
今回の地震で分かった事は在庫を抱え込まないかんばん方式やコンビニの単品管理に代表される
今回は地震が起きた時が午後３時に近い頃でまずはみんなが自宅に帰宅して
家族の安否確認をすることに必死で何かを買って帰ろうという余裕も無く、
停電したことから店側の準備も整ってなかったことから
長蛇の列が出来ることになる。
イオンやヨークベニマル（イトーヨーカドー系列）などは２時間待ちにもなり、
開店している店の商品は一日で底を突く。
更に翌日は開くかどうかもわからない店に皆が並び店員が大慌てで
仕方ないとばかりに繰り上げ開店を行い、商品は消えていった。
まるで食欲旺盛な大蛇があるだけのエサを丸呑みして行くようだった。
この時に大切なのが
平時に普段、自分の家で消費する一ヶ月分の物を備蓄しておくこと。
そして出来るだけ買い占めなきゃ不安だという気持ちを周りに起こさせない事である。
ちなみに私は自慢じゃないが貧乏だ、貧乏人には貧乏人らしい
備蓄のやり方がある。
その家によって違うと思うが
米なら楽天辺りで30kg買って米びつに一袋分（10kg）+一袋10kgで合計20ｋｇになったら
一袋10ｋｇ買い足して20kgを割らないようにするだけでも主食は確保できる。
基本的に精米した米は賞味期限が短い、
３ヶ月も持たないというか食べられなくはないが風味は落ちる、
虫が付くかもしてないと米屋さんなら言うだろう。
また、備蓄向きと思われているインスタントラーメンも賞味期限は一年持たない。
特にフライ麺の賞味期限切れは食あたりの可能性があるので賞味期限は守った方がいいです。
2chのスレなどを見ると麺を茹でてお湯を捨てれば
メーカーが余裕を見て設定してるであろうマージン分３ヶ月ぐらい過ぎても食える的な話もあるが、
災害時で最も重要な水を捨てるという蛮行を働けば下手すりゃ死にかけます。
止めておきましょう。
日清食品 よくお寄せいただくご質問
http://www.nissinfoods.co.jp/utility/customer/faq.html
弊社で販売している製品の賞味期限は通常製造日からカップめんで5ヶ月、袋めんで6ヶ月となっています。
スパゲッティと乾燥大豆は涼しく風通しのいい所に置くと３年間持つので
スパゲッティを500g入り20袋＝10kg用意しておくと飽きが起きにくい。
また乾燥大豆はどうしても起きやすい野菜不足やタンパク質不足を解消できる
備蓄のマストアイテムと言ってもいい。
いっそのこと避難所に備蓄して欲しいくらいだ。
イタリア軍の逸話を知ってる人はスパゲッティは水を大量に必要になるじゃないか！
と言うかもしれない。
それはあくまで茹で汁を捨てるという事を前提にしている。
スパゲッティを茹でる時は塩を入れないで茹で汁を味付けし直せば
乾燥大豆は30ｋｇ単位で買うのが一番安い。
国産大豆でも１万円、アメリカ産大豆でも6000円程度であることから
お米と変わらないぐらいの安さだ。
30kgを買ってみたが二人分と考えると一合カップで量ると150g程度で二日分になる。＝400日
一袋で一年程度、多すぎると感じたら知り合いと分ければいい。
大豆ダイエットで有名な大豆イソフラボンの影響か、大豆を食べて自転車で移動するようになったら
一年で100kg→70kgになった。ダイエットにもおすすめである。
地震があった時点での備蓄は
米が米びつに一袋分（10kg）+一袋10kgで合計20ｋｇ
スパゲッティ500g入り25袋 12.5ｋｇ
乾燥大豆 10kg程度
賞味期限が切れた いりゴマ１ｋｇ５袋＝５ｋｇ
賞味期限が切れた インスタント味噌汁２５０個（一袋１００個入り）
この賞味期限が切れたものは賞味期限間近の商品を格安で売ってくれる所を
見つけたので買い貯めしていた物だ。
乾物や熟成が見込めるもの、アルミパウチな上調味料なラーメンスープなどであることから
どれも賞味期限が半年は過ぎているので気になる人にはオススメしかねる。
今回の震災を乗り越えられたのもこの備蓄でバリエーションが増やせたから
という気がしないでもない。
災害時は水分も大切だ。
普段は飲まないがお客さんように特売日に100円で買ったジュースも
備蓄してあった。
ただし、炭酸入りだと賞味期限近くなると微炭酸になってしまう、
その点は注意。
バヤリース1.5L×２本
伊藤園天然水ソーダ1.5L×２本
本当ならば給水所ができる３日間に必要なペットボトルの水を準備しておいたほうがいい。
一人当たり一日２Lペットボトル１本が目安だ。
備蓄ではないが他にあった水分は
ヨーグルトを作る為に買って置いた低脂肪牛乳１L×４本
電気ポット（１Lタイプ）＋魔法瓶エアーポット（2.2Lタイプ）
うちでは小型の電気ポットで沸かしてエアーポットに入れるようにする事で
保温時の電気を使わないようにしている。
と同時にお湯を移して空になった電気ポットに常に１Lの水を入れておく事で
断水時に最低１Lの水を確保できるようにしている。
LPガスという状況下での苦肉のエコ＋災害対策という訳だ。
エアーポットのお湯が温くなれば電気ポットに戻して沸かし直したり、
もう１L沸かしたお湯を入れればいい。
エアーポットは空気が多ければ多いほど冷えやすい、
朝２L入れて徐々に使ってぬるくなったら料理に使ってもいいのだ。
燃料や電池の備蓄について
今回、問題が出たのが電池だった。
準備していた物が単三１２本。
しかし、自然放電と昇圧機能のないUSBコネクタ付きバッテリーケース
BP‐1だった為、充電が直前まで使っていた１セット分しか使えなかった。
USB出力付電池ボックス２種を試す 【起】
http://mast.cocolog-nifty.com/main/2010/03/usb-e306.html
電池の備蓄を考えた場合、
エネループか普段使いの100円ショップ充電池＋アルカリ乾電池の二択だろう。
電池は時間が経つほど残量が減って行く。
使用推奨年月日が製造から５年の物が多い物を考えると
一年目に５セット買って一年毎に１セットづつ買い換えるという事がよいのではないかと思う。
余震の事を考えるとロウソクよりLEDライトの方が安全だからだ、
http://www.kansai-event.com/kinomayoi/battery/alkaline.html
＞上位のほうが消費期限が長い ＝ 製造から日が経っていない。
＞という考察もできるのではないでしょうか。
＞グラフに載せている「オーム電機(参考) 消費期限04-2005」や
＞「富士通7300(参考) 消費期限 08-2003」の電池はかなり性能が落ちています。
燃料の備蓄について
今回、電気が二日後に回復したという奇跡的な状況が起きた事や
地下埋設型のLPガス事で安全ピンが作動する事もなく当日から使えた事が
他の方と比べて非常に楽な展開になったは間違いない。
ガスが使えない状態であったとしたら
＋余裕があれば電気があれば使えるIH卓上コンロを準備する必要がある。
必要としてカセットコンロに載る鍋やフライパンのサイズは２８ｃｍ、
ミニサイズのカセットコンロは１８ｃｍが標準的なので注意しよう。
カセットガスは高いので電気が復旧したらIH卓上コンロに切り替えたい所だ。
両方使えるIH対応の物を普段から使っておきたい。
石油ストーブは暖房と料理両方に使える凄い奴。
しかし、備蓄の事を考えるとエアコンがある家は持っていないケースが多いかもしれない。
また、地震での転倒による火災発生などに気をつける必要がある。
灯油に限らずガソリン軽油といった石油類は使わずに一年間置いておくと
劣化してしまい煤が不完全燃焼が発生する可能性がある。
どうやら燃料劣化防止剤スタビルというものがあるらしい。
よく分からないが調べてみてはどうだろうか。
http://minkara.carview.co.jp/userid/355641/car/259411/1470407/parts.aspx
http://item.rakuten.co.jp/yusayusa/10000460/
トイレットペーパーはシングルで１２コ入りのものを３セット準備しておくとよい。
これも最低２セットは維持しておくこと。
鼻紙から食器の汚れを拭き取るのにも使える。
水が重要な時に力を発揮する。（特に汁物を食べた時）
備蓄としてはそんなに必要ではないかもしれない。
ダイソーやイオンで売ってる４０M巻を２本買って一本維持する形でいい。
水汲み道具の準備
折りたたみの水を入れるウォーターバックみたいなものもありますが
常日頃から水を貯めるということを意識して
ゴミ捨て場に捨ててある４Lの焼酎ペットか２０L焼酎が入っていたキュービテナーを保存しましょう。
衛生状態がいいので使いやすいです。
水専用のポリ管を用意してもいいです。
最高気温が２０度以上（スプレーで黒く塗っておくと１５度以上）
の気温になって晴れの日に４Lペットを日の当たる外に置いておくと
体を洗うのに丁度いい温度になります、一人が全身を洗うには１６Lは必要です。
日頃から近くのゴミ捨て場でカンビンペットボトルの日にもらっていきましょう。
４本置いて温まったら翌日が雨でなければ新しく水を入れたペットボトルと交換して置いておきます。
一人当たり８本あるとスムーズに使えます。
これもLPガスが高いから考えついた方法ですが
夏場などで備蓄の水が多く必要になる季節にマッチしています。
テレビで学者さんが言うには一日１０％ぐらい下がる的な事を言ってたので
それ対策と地震後に白濁が発生しやすいので
それを避ける為に貯め水用としても４Lペットは便利です。
ですが、大きすぎて蛇口から水を入れられない場合があります。
その場合は醤油などに使われている取っ手付き1.8Lペットに入れてから移すか
瞬間湯沸かし器の目盛を水にして入れましょう。
津波や計画避難など家を離れなければいけなくなった時に持って行けるもの
リュックサック一つ分と考えたほうがいい。
数日分の着替え、５００mlペット２本、クッキーや飴玉などの最低限の食料
貴重品、モバイル機器 歯ブラシ等衛生用品 トイレットペーパー１個 ゴミ袋
赤ちゃんのおしりふき（体を拭く為） 使い捨てマスク トランプや双六、ポータブル将棋
皮手袋 軍手
他にもあるかもしれないので教えて欲しい。
軽登山に必要なものを参考にするといいかもしれない。
スーパーはコンビニの一週間以上早く商品が入荷し始めたのに比べて
更にチェーン毎の復旧度合が明らかに違ったのだ。
具体的に書くと
スーパーの開店情報については河北新報で１７日から掲載されるようになってきているが
26日時点で
ローソン 食品なし
ファミリーマート 山崎の菓子パン（コッペパン、ソーセージパン）、東洋水産の緑のたぬき・赤いきつねのみ
セブンイレブン おにぎり、賞味期限が長い弁当（４日間ぐらい）業務用の牛乳、タマゴ、食パン
また最小ロットを１個からという必要な分を必要な分だけ
送る為には合同配送センターが必要となり
スーパーのように箱買いで直に送ってもらう事ができない構造が
立ち遅れを招いたと見ている。
スーパーには惣菜加工のキッチンが付いてることから
原材料が手に入れば加工出来てる違い
http://my.reset.jp/~adachihayao/index3news.htm
２０１０年１１月２８日 ー パキスタンは温家宝に１５０億ドル期待ー
パキスタンの人は，個々には優秀な人が多い。昔のイスラマバードのＪＩＣＡ事務所でも，彼等を重く使っていた。事務所に入ると，ずらりと窓側に並んだパキスタン人スタッフが立派な髭を蓄えて悠然と座っている姿を見ると，一見，日本人スタッフが使われているような錯覚に陥る。私たちをパキスタン北部の辺境に案内してくれたパキスタン人スタッフは優秀で，かなり突っ込んだ議論が出来る。
雪の降りそうな初冬だったが，パキスタンの山奥深く分け入って，雪に霞む村落を眺めていると，人口１億を超すパキスタンの構造が見えてくる。どこまで入っても人が住んでいる。チトラルを見上げるところまで入ったが，最後は泊まるところを捜して，一軒家を見つけ，電灯のないところで長靴を履いたまま一晩，眠られぬ夜を過ごした。帰途，スワット平野のホテルが，随分立派に見えたことだった。
この間，殆ど女性の姿を見ることはなく，途中ですれ違っても，顔を見せずに隠れて去って行く，イスラマバードに帰ってきて，顔を見せて颯爽と歩いている女性を見ると，こちらが恥ずかしいような錯覚に陥る，あの平和なスワット平野は，今はアルカイダで厳しい状態が続いているという。イスラマバードのホテル、奥さんを現地で亡くした日本人観光客に会ったが，奥さんは唐天竺を求めて来られた，幸せでしょう，と慰めてあげたことだった。
それほど奥の深いパキスタンであるが，しかし一方で，政府官僚の傍若無人，無法な社会に戻ると，思わず印象は一変する。北西辺境州で州政府と中央官庁が頭から対立していて，日本のＯＤＡの訪問も，その対立の前では忘れ去られる。結局あるプロジェクトの協定書に署名が出来ず，ペシャワールからイスラマバードに引き返したが，救急車が来るたびに，おい，サインを求めて追っかけてきたぞ，と冗談を言っていた。
帰国の空港についてパキスタン航空のチェックインカウンターに行くと，チケットの再確認の欄がペンで書いてある，無効だという。何を言っているのか，と大げんかをして手続き進めたが，単独出張のＯＥＣＦの方は，結局載せて貰えなかった。当時はビジネスクラスで，機内に乗り込むと，軍人らしきグループが席を占めている，席のない軍人はパイロットの横に潜り込んでいる，彼等を載せるために，我々のチケットを無効にしようとしていた。
アフガニスタンの問題が起こってから，米国を初め西側諸国はパキスタン支援を強化して行き，日本もＯＤＡでこれを支援する姿勢にあったが，ＪＩＣＡの緒方理事長もあるインタビューで，パキスタンは我々は入れない，と難しい治安問題を語っていた。しかしパキスタンは，無尽蔵とも言えるような中国の資金攻勢に完全に征服されかかっている。結局，ミャンマーやスリランカ，カンボジアのように，心も売り渡す状況にある。
パキスタンのザルダリ大統領は，３ヶ月に一度は必ず北京に行く，と宣言して，北京で幹部に会って貰えないときは，雲南省の昆明や上海に回って，中国企業との会談に明け暮れている。パキスタンは電力不足で，政府は国民を宥めるために大規模ダムの推進を喧伝しているが，なかなか資金が集まらない。それでも，中国の企業によるダム建設の約束が進んできている。原子力も含め，中国はそこまでパキスタンを支援出来るのか。
中国は，ミャンマーにインド洋への進出拠点を求め，スリランカに手を差し伸べて，資源ルートの開発を進めており，最近は，ラオスを経てカンボジアに至るルートも開発している。パキスタンはそれこそ中国にとって，インド洋進出への第２のルートなのである。カラコルムハイウエーは実質中国が開発したものだが，中国領の新疆ウイグル自治区ｊからこのルートを経て南下が可能である。
これに，南西部のグワダール海港を繋げば，立派なエネルギー回廊が完成するわけで，この意図はパキスタンの利害とも一致している。パキスタンは，イランからのガスパイプライン完成が一つの夢であるが，協力が出来そうな雰囲気であったインドへのパイプライン延長は，結局，パキスタンへのインドの警戒と米国が，イランとインドとの繋がりを警戒して反対に回り，結局インドはイランからのガスパイプライン構想から離脱した。
中国の温家宝首相が，この１２月半ば，イスラマバードを訪問する。今日のパキスタン紙の記事では，パキスタン外務省が殆どの関係省庁に文書を回し，至急，中国との間で結ぶべきプロジェクトの協定書を準備せよ，と要請した。それはエネルギー問題と道路建設が主題で，電力では，タールの石炭火力，チャシュマの原子力，インダス川上流にある大規模ダムなどで，パキスタンは１５０億ドルに上る支援または投資を期待している。
パキスタンが特に重要視しているのは，中国の意図に沿ったエネルギー回廊の完成である。それは，中東の目の先に位置するグワダール港の整備，グワダールからケッタまでの道路整備，これをアフガニスタン方向とカラコルムハイウエー方向に連携する道路の整備，そうして究極は，イランのガスをイスラマバードを経由して中国の新疆ウイグル自治区に繋ぐことである。パキスタンも，身も心も中国に売ることになる。
パキスタンの電力事情は厳しい，長期に亘って計画停電が続いている。政府は，大ダムが出来れば問題は解決する，もうすぐだ，と国民を宥めようとしているが，大規模ダムがそう簡単に出来るわけはない。それでも今日のパキスタン紙は，電力の関する目標値を詳しく記事にしている。出所は，国家送電網公社ＮＴＤＣの資料のようである，折角だから，ここで順を追って数字を拾っておきたい。
政府は２０１１年末の発電設備を，２２,６９７ＭＷとしており，これに対応するピーク需要は，２１,７０５ＭＷである。このピーク需要を満たすために必要な発電設備は，２,７１３１ＭＷで，不足分は，４,４３４ＭＷである。２０１２年には，ピーク需要は，２,３４４１ＭＷ，必要な設備は，２９,３０１ＭＷ，不足は５,５１３ＭＷに広がる。２０１３年には，ピークは２５,３０６ＭＷ，設備計画では，２６２７９ＭＷ，必要設備は３１,６３３ＭＷ，不足は５,３５４ＭＷである。
.同じように，２０１４年では，ピーク，２７４３８ＭＷ，計画は，２９,４０５ＭＷ，必要は，３４,２９８ＭＷ，不足は，４,８９３ＭＷである。２０１５年では，ピークは２９４６３ＭＷ，計画は，３３,６３０ＭＷ，必要は，３６,９２９ＭＷ，不足は，３,１９９ＭＷである。２０１０年時点の現状は，設備が，１９,２４６ＭＷ，有効出力は，１７,７７９ＭＷ，夏期の有効は，１４,８４０ＭＷ，冬季になると激減，１２,４８２ＭＷである。
ＷＡＰＤＡの水力設備は，６,４４４ＭＷであるが，夏期には，６,２５０ＭＷ，更には冬季には，２,３００ＭＷに落ちる。ＧＮＣＯＳの設備は，４,８２９ＭＷで有効は，３,５８０ＭＷであるが，夏期には，２,７８０ＭＷ，冬季には３,２２２ＭＷに落ちる。ＩＰＰは，設備が，７,９１１ＭＷ，有効が，７,６９５ＭＷ，夏期には５,７５０ＭＷ，冬季には，６,９００ＭＷである。レンタルは，約６０ＭＷである。
明日から，黄海に於ける米韓軍事演習が始まる。中国の警戒に対しては，米国は一応公海上，として強硬の構えである。今後，南シナ海や東シナ海の制海権に対して，どの様な示唆があるのか，注目するが，中国で建造中の空母が完成すると，話は一変するのか。ベトナムにしても，マレーシアにしても，フィリッピンにしても，インドネシアにしても，目の前に中国の空母を見ながら，石油生産を行うことになるのか。
昨日も書いたが，中国に言いたいのは，北朝鮮，ミャンマーに対して，彼処までコミットしながら，北朝鮮の核，北朝鮮の砲撃，北朝鮮の拉致，ミャンマーの核開発などに対して，何も言えないのか。返って中国の弱腰を追求する必要がある。説得できないなら，中国もグルなのか，と言われても仕方がない。そんなに弱腰なら，経済的支援や目に余る投資を止めるべきだ，という世論が興るだおる。
この一触即発の東アジアの状況の中で，フィリッピンのアキノ大統領が韓国からの５万人のフィリッピン人の避難を受け入れて欲しい，と言っている。これは面白い問いかけである。まだ起こっていない状態を材料に，日本に踏み絵を迫ったような感じ。広くフィリッピンの看護士を受け入れる体制に日本はあるが，本気かどうか試されることになる。５万人を日本国内で自由にするのか，出来るのか，日本にとっては難問である。
