「パイプライン」を含む日記 RSS

はてなキーワード: パイプラインとは

2016-12-20

世界疲れた人と人の世界にいきる辛さについて今思うことをつらつら

Web界隈で仕事をしている。

げんきであかるい、いっしょうけんめいな担当者

クライアントから評価は恐らくこのような具合だろう。

社会ではまだまだ若手も若手に属する20代前半の武器は多分こんなもの

期待にこたえるために頑張ってきた。

だが、ここにきて疲れた

テンション高めでのSlackでのやりとりも、

パイプラインゆえに他人の尻拭い的謝罪も、

女性はこうであれ的圧力も、

21時くらいに舞い込んでくる明日朝出しの修正指示も、

締め切り守らないデザイナーへの催促も、

同僚の進捗確認も、

すべてが面倒くさい。いきることですら。

かんじにへんかんするのもめんどうくさい。

たいぴんぐ も めんどう だが もうすこし。

よかれとおもったことがうらめにでる。

きたい された こと に こたえられない くやしく かなしく みじめで ひりき で

おのれの むりょくさに なすすべもなく。

3000年、ただひたすらねていたい。

わたしをしる者がだれもいなくなった世界たからかに笑いたい。

2016-10-03

かつてHTTP自体疎結合だった

HTTP最初、 「GET /file.html」の形式しかない疎結合だった。そのため誰でも簡単実装することができた。

HTTP/1.0、HTTP/1.1 となるにつれ、メドッドが増え、関連技術も増えていった。

HTTP/2 にいたってはパイプラインリソース結合、ストリーム多重化、フロー制御といったすげー複雑な仕様が増えた。

こんだけ複雑になったのは何かの陰謀だと思う。

2016-05-08

カステラパイプライン

今やカステラは時たま頂くおやつというより、様々な栄養素を含む生活に欠かせない国民食になった。そんな国民需要に応えるべく国はカステラ供給するインフラ整備を模索し始めた。もはや店頭に並んだカステラを買いに行くのすら非効率的。そこでぶち上げられたのが「カステラパイプライン構想」だ。読んで字の如しだが、カステラ水道管のように各家庭に配管で供給するものだ。カステラのような弾力性のある固形物をどのように供給するのだろうと思うだろう。まずカステラの幅を5切れ分を1パケット策定した。これが最小単位である

2015-10-22

http://anond.hatelabo.jp/20151022194837

の子育て大変そうイメージ

二人以上いるとこれがパイプライン的に並列で来るわけじゃん。子育て人生消費しつくしちゃいそうじゃんって気がする。

2015-07-20

そもそもホルムズ海峡機雷を除去する必要性を感じない。わざわざ海賊喧嘩売ってるように見える。陸路で海に出るかパイプライン敷設の交渉でもすればいいだろうに。

2015-07-02

http://anond.hatelabo.jp/20150702164429

プロセッサに1次2次キャッシュが搭載されてない時代ならば、アセンブラはムダな条件分岐ジャンプを極限まで減らせるから確実に速くなったんだけど、いまそれやるとパイプライン止めるだけだからたいていの場合は遅くなるんだよね。

メモリアクセスだって8か16の倍数区切りで読み書きしないと遅くなるか、SIMD命令ならメモリアクセス違反で止まるし。

俺がSIMDコード書く場合だって、上から下まで流れるだけのコードで条件分岐はさせないし、ループはCの構文使うし。

どうしても条件分岐必要ならばCMOV使うけど、これを使うくらいになるともう分けがからなくなって時間を猛烈に使うから止める。

いろいろさまざま念頭に置く必要があるから、そうとうこなれてるというか、とにかくアセンブラマシンコード母親並み無条件に好きなヒトじゃないと、ひたすら辛いだけだろーな。

それを知っててアセンブラを書いたことがない奴に書けっていうのは結構酷いと思うからから、それ相応の理由つけてごめんなさいした方が出来上がってくるものにとっても組むヒトにとっても結果プラスになるかもね。

2015-06-17

http://togetter.com/li/835942

セルフホスティング論争について俺がモヤモヤするのは2点

第一に、発端となった元ツイートには「非エンジニア新卒女子」とはっきり書いてあるのに

エンジニアとしては絶対に雇いたくない》

《旧式言語を学ばずに関数型言語一本槍でエキスパートを目指すような感じの方》

《「まず軽く触れてみよう」とか「趣味でやってみるか」といった程度ならいいのですが》

《実際には肝心なことを何も知らないのに、なんか知っていると思い込んでいる状態が、私いわく「脳味噌膿んでる」》

ひどい書きっぷりだよね。

もし自分当事者だったら「見ず知らずの人になんでここまで言われなきゃいけないの」と傷つくと思う。

第二に、下位層のレイヤーについて知っていなければ上位層のことをちゃんとやる資格がない

という態度が明らかに本人のダブルスタンダードっぷりを示している点

OCamlで書かれたコード関数型のパラダイム

コンパイルされたマシン語コード手続き型のパラダイム

と言いたいのだと思うけど、最近CPUマシン語に書かれていある命令をそのまま実行しない。

インテル場合CISC命令セットで記述されたコードRISC的なマイクロコードに分解・解釈して実行する。

さらに内部はパイプライン化されているため、単純に「1命令ずつ逐次実行」されてもいない。

外側から観察するとあたかマシン語命令列をひとつずつ逐次実行しているかのように振る舞っているだけだ。

マシン語コード記述されたプログラムが、命令通り入力と出力を繰り返すなら、内部でどのような先読み予測分岐を繰り返していても問題ない?マシン語の忠実な実行装置とみなしてよい?もちろん回路の設計ミスで誤動作するかも知れないけど、それがプログラマの「根本的な過ち」になる?

これは高級言語マシン語関係とまったく同じだ。

OCaml世界記述されているロジックが、OCaml仕様通りにちゃんと動作すれば、その下位層にあるマシン語がどういうパラダイム記述されていても関係ないと考えていいと俺は思う。

余談1

くだんの女子について、周辺のツイートを見てみると(完全に部外者憶測だけど)Railsを主力とするソフトウェア企業に非エンジニアとして新卒入社した新人プログラミングに興味を持ったのに対して上司OCamlの本を教科書として渡したのでそれを学んでプログラミング考え方を身につけた。その後Railsについても学んでみようとしたが、考え方のギャップに強い違和感を覚えた。…という経緯みたいだ。

余談2

https://twitter.com/camloeba/status/611051620877537281

https://twitter.com/sessoh/status/611052396161183744

このやりとり、拙僧さんが「肝心なこと」と思ってることを卯之助さんは「重要でない」と言ってるんじゃないですかね。

2015-01-11

中国がなんの目的2ちゃんねる攻撃するのよ?



820 ソーゾー君 2015/01/10(土) 03:40:34 S8z9YJTo

茶番劇で忙しいから静かなのかw

中国がなんの目的2ちゃんねる攻撃するのよ?

陰謀論を語るなアホ。

安部の仲間の香港カキョウが2ちゃん自民ネットサポーター茶番劇をやるのは今に始まったことじゃねーだろ?

香港カキョウの悪さを中国責任にするなよ?

在日右翼の悪さを日本責任にするようなもんだぞ?


ロシアのガスをパイプライン中国供給の話が纏まったから焦ってんのか?

しかも、支払いはドル建てではなく人民元建てだもんなwこれは発狂するわなw

ロシアパイプラインを「中国朝鮮半島北海道」と繋げる計画だから焦るわなw

から中国北朝鮮との対立を必死に煽るw


中国北朝鮮ロシアの計画に賛同してパイプラインを繋げるから

日本は断固として中国北朝鮮と対立しないとパイプラインが繋がっちゃうもんなw

円建てで支払えるのにアホだろ?

しかも、北方領土2島返還も付いてくるのに自民党霞が関の糞役人拒否しやがった。

その立役者鈴木宗男冤罪で叩き潰しやがった。


何故、マスコミ中国北朝鮮必死バッシングするか理解たかね?

日本はガスや石油などのエネルギー欧米企業に一極依存している。

止められたら終わり。値段も当然、言い値となる。

おまけにドル建てで支払わなきゃならんから大量にドル米国債を保有せにゃならん。


ロシアのガスや石油パイプライン供給されたらエネルギー依存は一極ではなくなる。

支払いも円建てで出来るからドル米国債の保有率も減らせる。

一極なら選択権は無いので言い値となるが、複数の売り手からうから交渉が出来る。

簡単だろ?




中央銀行・発行権】黒幕銀行家6【信用創造

http://jbbs.shitaraba.net/bbs/read.cgi/movie/10043/1414594539/

中央銀行・発行権】黒幕銀行家37【信用創造

http://wc2014.2ch.net/test/read.cgi/kokusai/1343051395/

2015-01-04

http://anond.hatelabo.jp/20150104012559

ベイマックスは見てないけど、それはそうかもなと思う。

一方で、「天才はいない」と言っても、一人一人は日本にいたら天才クラスになるレベルなんじゃねーかなとも思う。

まり単純に平均レベルが低いということ。グーグルなんかは正にそうで、日本でなら天才クラス人材普通に鯖缶とかやってる感じ。

例えばpixarあたりで普通にパイプラインエンジニアやってるような人間siggraph論文ポロポロ通してたりする。

日本だったら速攻でパーマネントアカポスゲットくらいの業績を挙げている。

翻って世界市場って意味ではOLMパックマンのやつは結構売れたと聞いたけどどうなん?あとポケモンとか?

2014-06-06

知られざるファミコンクソゲー打線組む

最近増田でも打線組む投稿散見されるので、マイナーどころのファミコンクソゲーで組んでみよう。

家庭用ゲーム機の出現から30数年、携帯ゲーム嚆矢となる携帯アプリの出現から10数年。クソゲーを語る文化もまた成熟しつつある。

そうした文化にこの文章が影響を与えられるとは到底思えないが、まぁ見て楽しんでもらえたら嬉しい。


1遊 光の戦士フォトン

擬似的な3D空間を探索するゲーム主人公が腰の悪そうな歩き方をし、移動も遅い。上にしかビームを出せないくせに敵が横からもくる。ヒントも意味不明音楽も気持ち悪いし壁が目に悪い光り方をする。タカラが生んだ先駆的クソゲー

https://www.youtube.com/watch?v=tL71-Hsh9lo


2右 明治維新

坂本竜馬操作して明治維新をおこそう。前半がアドベンチャーモード薩長同盟を締結し、後半が戊辰戦争シミュレーションアドベンチャーモード中岡慎太郎が強すぎて竜馬を使うことはない。シミュレーションモード新政府軍が弱過ぎて板垣伊藤が隣の藩の雑兵に殺されるレベル。そして何故か生きて戊辰戦争に身を投ずる坂本史実とは?

http://nicoviewer.net/sm4286007


3三 ゴーストバスターズ

糞。ゴーストバスターズロゴがあるだろ。禁止マークゴーストが収まっとるあれだ。あれを動かすゲームなんだぜ。これ。

https://www.youtube.com/watch?v=YxJNXahpPHc


4一 tao 

ノストラダムスの大予言後の世界を旅するRPG。最終的に天道という実在する新宗教帰依せよ、という結論に至る怪奇ストーリー宗教的神秘主義的な世界観は独創的ですらあるが戦闘は連打ゲーであり移動は何故か恐竜で行なう1989年という時代性、今よりももっと精神信仰や信奉というものが身近だった、すなわち「オウム」以後に忌避されるようになった若者スピリチュアルものへの傾倒の時代象徴するクソゲー。こうした意味で、もう現れない時代性を反映した記念すべきクソゲーなのだ

https://www.youtube.com/watch?v=H_rYG_ZM4Oo


5中 覇邪の封印

ファミコンパスワードは長い。特に長いものにこの『覇邪の封印』と『ドラゴンクエスト2』とがあるが、その評価には著しい格差がある。主人公に付いてる妖精性格が悪く、ヒロイン憎悪しておっさんを贔屓する。悪徳商人を殺す王道ファンタジーRPG

https://www.youtube.com/watch?v=aKe7yIqj4TY


6二 大怪獣デブラス

まんこれは名作だ。ゲーム歴史上、「攻撃して倒すゲーム」が主流のなか「最後まで守りきる」ゲーム。そしてかなり難しい。それゆえクソゲー揶揄されるが、本当はとってもソリッドなゲーム女の子かわいいし、実際難易度も凝りに凝っている。

https://www.youtube.com/watch?v=cBmHNRZBZsY


7捕 夢幻戦士ヴァリス

マップと実際の道路が合っていない。マップ見ないで画面で覚えようにも、道路が変なところどうしで繋がっている。プレイヤーマップと実際の画面とを総合して、自分の心の中でゲーム空間イメージせねばならない。

https://www.youtube.com/watch?v=L2ABLQKHHCU


8左 ゴルビーパイプライン大作戦

プーチン領土欲を露骨に発露する2014年現在、再評価も求められるゲーム。なぜか水道管を東京モスクワ間で結ぶ。石油じゃねえのかよ。このゲームゴルビーまり関係ないのにゴルビー肖像権ロシア大使館に申請し、許可されている。なぜロシアも許可したのか。失敗すると可愛い女の子投身自殺する。

https://www.youtube.com/watch?v=AC0IKZet0Ds


9投 パリダカールラリースペシャル

パリダカに出るために車を調達するところから始める。途中野生物を倒したり、内戦中と思しきアフリカ国家を通る。荒唐無稽な出来なのだが、どこか「これがパリダカ雰囲気か」と思わせる説得力があるクソゲー。もちろん現実のものとは全然違うんだけど。音楽がかっこいい。

https://www.youtube.com/watch?v=_-tYJwqMWI0

2014-05-16

http://anond.hatelabo.jp/20140516124556

原子核の分野やFORTRANの分野で技術継承の何が失われているのかはわからないんだけれでも、

私が考えるに、現在の「原子炉設計利権込)の技術」が失われることで、

今まで切り捨てられていた別のタイプ原子炉スポットが当たるということはないのだろうか?

自然環境の変化で、恐竜のような大型生物がほろんで、小型の哺乳類や小型の爬虫類がいきのびたような。

FORTRANはどうするかね。「動いているものは変えるな」の原則からすると、絶滅を待つしかないのか。

十分パイプラインが深く、並列化が進んでいるだろうFORTRANは、進化のしようがないね

2014-04-18

下水道についての話、または画一的政策の推進への嫌悪

下水道とは何か。

それは汚水を浄水施設に送るためのパイプラインである

では、浄水施設とは何をする場所か。

汚水規定よりも『きれいな水』にして川なり海に帰す施設だ。

放流される水は、冗談抜きで途上国の上水よりもきれいだったりする。

そのまま上水の水源に使ってもトラブルが起こる確率はそれなり低いとは思う。

雑に言えば、大きな誤解を生むと思うけど、実は上水も下水も処理としての根本は同じだ。

水中の浮遊物や生物などを濾し取る。

その方法として、水圧をかけて砂の中を通すとか(急速濾過)、自然流下で砂の中を通すとか(緩速濾過)、一度深いプールを経由することで不純物を沈めるとか(沈下槽)、薬品紫外線で殺菌をするとか、凝集剤で不純物を固めるとか。基本的酸素豊富に含ませれば水は勝手にきれいになる。

砂の中を通すのは、正確には濾し取るのではなくて細かい不純物を砂に吸着させるとかなんとか、話が脱線するのでこの辺はつっこまない。

ともかく、下水道が整備されるということは、汚水河川や海に流れこむ事を防ぎ、伝染病の発生リスクを大幅に下げる事でもある。

当然、人口密集地で発生した汚水を速やかに処理場に送るため、悪臭も著しく押さえられる。

というわけで、浄水施設ケーブルテレビなら浄水施設を先に整備するべきだと僕は思っている。

その上で、下水道の普及を推進する政策への懐疑がある。というよりも、あれは失敗した政策だったとおそらく関係者はみんな思っている。

汚水処理施設、浄水施設とは下水道の先にだけあるものではない

合併処理浄化槽というものがある。

庭先に設置する浄水施設だ。

これは、イメージされる下水処理施設機能は同じ。小型版と思ってもらえば間違いはない。

個人で所有し、汚水を個人の責任で浄水し、排水するわけだが、設置に土地がいると言うこともあり、都市部では設置が難しい。その上、大量の汚泥を各所で浄水するのは効率が悪い。

から下水道の普及は非常に合理的だった。

ところが、国はこれを過疎地域にさえ整備しようとした。

しかも、法律下水道に設置するには合併処理浄化槽をコンクリートでつぶさなければならない。

300人分浄水能力を持った施設に、50人分の汚泥しか流れ込まないとバクテリア餓死して浄水能力は大きく損なわれる。

その上、施設の維持自体にも過大な費用がかかる。受益人数に対すれば異常なほどの税金が投入される。

もちろん、施設自体寿命があり20年もすれば立て直した方が安くなるほど維持費がかかる。

いっそつぶしてしまって合併処理浄化槽に戻した方がいいとわかってきてもすでにつぶしてしまっている。

かくして戻ることも出来ずに金食い虫を抱えた過疎の自治体が全国にたくさんある。

簡単に予想できた事でも、国はそれを推進し、大量の資源資金無為にした。

それぞれのケースに応じて丁寧にものを考えないと、いけないよねというお話でした。

2014-03-05

ウクライナ情勢

そんなにクリミア半島をいじっちゃあ、らめぇ・・・

もうイジワルしないで、パイプラインで私の中に天然資源をちょおらぁい。

2013-11-09

でっかい企業と、ちっこい企業

両方経験できたので書く。

1. でっかい企業

  いいところ:

   (1)仕事スケールかい

   (2)基本頭の良い人、仕事出来る人だらけ。

   (3)金で解決できることは、無駄でも何でも、即、金で解決。担当が簡単に使える金は2~3桁違う。

   (4)イメージが良い

   (5)外国人もたくさんいる、海外企業とのやりとりもじゃんじゃん。

   (6)意外と給料高い

   (7)イメージに引かれて寄ってくる人が多いので、採用もそんなに苦労せず贅沢な事が可能。

   (8)女の人美人、男の人イケメン揃い。(たまに、顔とスタイルで選んでんじゃないのか?と思うこととても多い)

   (9)食堂がかっこいい。

   (10) 残業量を除き、基本的に法令遵守にこだわる。

   (11) 世間様が思う「ちゃんと仕事が出来てますね」というレベルを維持するのに、どんだけたくさんの人的リソースと、お金いるかがよく分かる。

   (12) 仕事担当が極めてはっきりしている。

  わるいところ:

   (1) みんな頭良すぎる/能力高すぎるので、大変窮屈。ちょっとの手抜き、失敗も大変しにくい。

   (2) お金と人ありすぎるためか、政治競争がすごい。権力争いも組織単位で行われるのでケンカレベルが違う。

   (3) 新しい事が大変しにくい。仕事の流れにちょっとでも異変を起こそうとすると、まわりに与える影響があまりにでかすぎるので批判殺到で即つぶれる

   (4) 基本的に競争激しすぎて出世絶望的。

   (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点とるぐらいのレベル仕事なら可能。

   (7) 人雇うのが大変しんどい。良い人採用なんて絶望的。

   (8) 会社存続にかかわる危機感だけは高いくせに、金/コネがなさすぎて具体的に何も出来ない。

   (9) 法令尊守は適当

   (10) お金の流れる仕組みを作るために必要お金が揃えられないので、なにも出来なくて悶々とする事が多い。基本ニッチ分野しか狙えない。

   (11) 下請けシバキはめちゃくちゃぬるい。シバクと付き合ってもらえないので。

まあ、人と状況と職種によりけりだとは思いますが、チラシの裏なので、書きました。

2013-08-14

なぜ「うちら世界」が話題になるのか

あぁいう損得勘定を抜きにした「無邪気なコミュニティ」に憧れてるからなんだよね。しかも行こうと思えばいけるのに一歩踏み出せない。それには踏み出した瞬間にパイプラインシステムからはみ出してしまうって言う教育学的な問題があるから。皆うちら世界動物たちを笑っているようで実は檻で守られているのは自分たちという人間動物園

2013-08-08

低学歴のせいにしてもしなくても「うちらの世界」は存在し続ける

社会的モラル見地から見た「バカ」低学歴世界に多いのは、低学歴だと選択肢比較的少なくなり、そして結果としてコミュニティが狭くなるから高学歴にバカが少なく感じるのは、高学歴世界ではコミュニティパイプラインがつながりやすいから。いろんな人がいる。1回いろんな人がいる世界に出くわすと、「うちらの世界」って忘れちゃう

バカを産む世界というのは、他の世界とのつながりが薄く、さまざまな価値観検証するチャンスを与えられない世界集団としての意思決定が極端な方向にぶれる世界同調圧力の強い世界だって世界ルールが違うんだもん、他の世界から見たらバカになって当たり前だよね。

その顕著な例として「低学歴世界」が挙げられただけで、「じゃあ高学歴にバカはいないのかよ、バーカ」みたいな水掛け論はちょっと斜め上って感じ。「高学歴にもこんなバカな例がある」みたいなブログ見たけど、「Aだからバカ」「Bだからバカ」「AもBも結局バカ」みたいに一つの事象を直接結果に結びつける人間が、彼らの世界孤立させるのを無意識であれども手伝ってるんじゃないかな。そこまで単純じゃないでしょう。

低学歴の人でも、たとえばネット大好きでいろんな人のブログ徘徊してたりとか、本・映画サブカル大好き!でいろんな価値観知ってたりとかすると、他者を受容することを覚えてる人は、違うんじゃないだろうか。世界が広がる。

どのわたしたちも、「うちらの世界」は通り抜けてきたと思う。小学校中学校に思い出すとのた打ち回りたいような黒歴史があるなら、まさにそれじゃないかな。プリクラ手帳に書いたビッシリの落書きとか、テキストサイトポエムってたりとか。あ、年代バレる。黒歴史は忘れたい過去なので、1度いろんな価値観の入り交じる世界に入ると、「うちらの世界」があったことなんて本当遠い過去になってしまう。

コミュニティの狭さは、視野や可能性の矮小さを産むし、その危険性は低学歴高学歴に関わらずいつでもわたしたちの隣にいる。でもじゃあどこまで世界を広げればいいんだろうね?これずーっと悩んでる。

2013-03-22

プログラミング出来ない奴ちょっと来い

プログラミング出来る方法教える。

世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。

いや実際に "ない" というのはかなり語弊があるかもしれない。

しかし、通常この種の説明している本に辿り着くまでには多くの時間必要だ。

普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要概念を獲得するのだと思う。

例えば、「計算機プログラム構造解釈」や「実用 Common Lisp」、「コンピュータプログラミング概念技法モデル」などの書籍現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。

しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。

そして、"普通プログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。

僕はそうは思わない。

というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。

それは自分の作りたいアプリだったり、

クライアントから発注されたプロジェクトだったり、

上司から頼まれた仕事だったり、

業務を効率化させるための Excel マクロだったり、

授業で出された宿題だったり、人それぞれだろう。

このような目の前の問題を解決したい人達が、わざわざ LispMozart など何の役に立つのか分からない言語を、根気よく勉強するのだろうか。(ちなみに、LispMozart は上記の書籍で実際に使われている言語である。)

目的現在の問題を解決することであって、

新しいプログラミング言語を学ぶことや、プログラミングの種々の概念を獲得することではない。

もちろんプログラミング言語を上達するためには一つでも多くの概念を会得する必要があるので、あるレベル以上を目指すのであればこれらの書籍を読むことや、抽象化を実現するための様々なツールを手にすることは必須だと思う。

純粋プログラミングを楽しんでいる人やハッカーを目指したい人はこのような文章を読むのではなく、ぜひ上記に挙げた本を実際に購入し、自分の手で動かして確かめてみることを勧める。プログラミングに対する考え方や姿勢が変わるのは間違いないと思う。

今回はそのような”純粋プログラミングを楽しんでいる人”に向けた文章でない。

現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。


そのような人の中で、なかなかプログラミングが上達しないという人に向けた文章である

もしプログラミング学習限界を感じているのであれば、プログラミング学習方法が間違っている可能性が高い。

そして残念なことに、初学者向けの書籍では、"プログラミング言語の文法" を説く本はあれど、"プログラミング学習方法や上達するための正しいスタンス" を説く本はほとんどない。


できるだけ多くの人にプログラムをする楽しみを知ってもらうためにも

より多くの人がより生産的にプログラムが出来るようになるためにも

そして特に、右も左も分からなかったプログラミングを始めたばかりの過去自分に対して、

効果的な学習方法プログラムする際の指針を書き記したいと思う。

それらは単に指針を示しているだけなので、

どんなプログラミング言語を使っていようとすぐに実践に移せるはずだ。

後はどれだけそれを実践に移し地道にプログラミングしていくだけである

正しい努力と、ちょっとしたコツさえ知っていれば驚く程生産性を挙げられるはずだと確信している。

プログラマレベルを以下の 3 つに分けてそれぞれについて説明していきたい。

1. 初心者レベル

プログラミング半年未満

・使えるプログラミング言語は一つだけ

ただし以下のことは出来ない。

・500行以上のコードが書けない

エラーが出た時の対処方法が分からない

写経は出来るが、自分プログラムが書けない

2. 中級者レベル

プログラミング半年 〜 3年

・1つ以上のプログラミング言語は使える

オブジェクト指向は理解している

ただし以下に当てはまる。

自分制作しているアプリケーション向けに "実用的なフレームワークライブラリ" を書けない

・1万行以上のコードだとスパゲッティコードになり、保守不能になる

・重複するコードが多く存在する

・適切なサブルーチン化できない

3. 上級者レベル

プログラミング歴 3 年以上

現実の問題に対して適切なデータ構造アルゴリズムを選択できる

抽象化について理解し、可変部分と不変部分を考慮した設計ができる

全てのプログラマはどれかのレベルに属するはずである

またそれぞれのレベルクリアするには明確な壁がある様に思う。

これらの壁を超えるにはどうすればよいかを説明する。

前置きが長くなったが、以下ではまず初級者レベルの人に向けた具体的なアドバイスをする。


初心者レベルの人に向けて

完全に初心者レベルの人はまずどのようにプログラミングを行えばよいのか分からない。一行も書けない。そのため、必然的に以下のような行動を取ると思う。

検索エンジンで似たプログラム検索コピーペーストする

・本に載っているプログラムをそのまま書き写す(いわゆる写経

上のような行動を行なっているだけでは、いつまで経っても自分プログラミングが出来るようにならない。

なぜなら上記のプロセスでは決定的に重要なことが学べないからだ。

それは、【プログラミング言語モデル】を自分の中に作ることである

プログラミング言語ルールの塊である

それは普通言語と同じように文法が存在し、そのしきたりに沿って記述しなければならない。

のしきたりを学べば書けるようになれる。非常に単純だ。

それなのに、なぜいつまで経っても書けないのか?

それは、”書き写す・コピーする” だけでは、そのしきたりが習得できないかである

特に最初のうちのプログラミングは頭を作業使う作業でなく、むしろ "体で覚える" 類のものである

それは例えば、日本語を話すことと似ている。

友達と会話する時、頭を使っているだろうか。

それは簡単な受け答えについては体が覚えているので、考えるより先に日本語が出てくるのではないだろうか。

プログラミングも同様に頭を使うのではなく、こうしたい時はこう書く、という反射神経を育てなければならない。

もちろん日本語話せるだけでは、ミーティングプレゼン出来ないのと同様に、文法が出来ただけではプログラミングが出来るとは言えない。しかし、文法が出来ないと "現実の問題に対処するソフトウェアを作る" というレベルには到底進めない。そのために、まずそのような文法の反射神経やパイプラインを頭の中に作る必要があるのだ。

それには以下の点を意識してプログラミングすればよい。

・"何をしたい時" に "どう書けば正しく動くか" というデータベースプログラミング言語モデル)を自分の中に作ること

このままでは抽象的すぎるので、このような "データベース" や "考える習慣" を自分の中に作るための具体的な指針を以下に挙げる。

1. エラーをたくさん出す

2. デバックの仕方を覚える

3. 小さく動かして確かめ

4. Google を使い倒す

まり、小さく動かして、エラーをいっぱい出し、デバッグを素早く行なって、分からないことは google などの検索エンジンで解決する。これが上達のコツである


これらについては以下で詳しく説明するとして、

まず最初初心者ありがちな間違いをいくつか列挙してする。


関数メソッドをたくさん覚えなければいけない

無理して覚えなくてよい。

プログラマは覚えることが星の数ほどあるので、メソッドなどはリファレンス片手に検索できればよい。

よく使うメソッドなどについては自然に覚えていくので、積極的に覚える必要はなし。それこそ、"体" で覚えるはずである

覚えられないメソッドについてはそもそもあまり使わないから覚えられないので、重要性は低く覚える必要はない。

しろ実現したい処理が既にメソッド関数として提供されていないか、調べる力の方が大事

エラーがいっぱい出てつらい

全く問題ない。

以下で述べるようにエラーとどう付き合うかが非常に重要

写経をしなければならない

教科書や本の中に書いてあることをそのままエディタで書き写し、実行することを写経という。

上記でも述べたように、これからまり無駄努力をしないことを願って言えば、

写経にはほとんど意味がないと思って取り組んだ方がいい。

写経して書いた 10000 行のプログラムより、自分で考えて書いた 100 行のプログラムの方が遥かに意義がある。

なぜならば写経は "作業" だからだ。

そこに "言語モデル" や "思考" が伴わないと意味がない。

”思考” が伴わないとただの書き写す作業をしているだけだ。

自分の中に "モデル" が出来ていないので、いざ自分プログラミングしようと試みても、写経をしているだけでは全く書き出せないだろう。

写経はそもそもプログラミングに対するスタンスプロセスのもの勘違いさせる危険性をはらんでいるいる。

写経する場合、書き写しの間違いがなければプログラムは問題なく動く。

しかし実際のプログラムではコンパイルや実行するまで、そのプログラムが期待通りに動くかどうか、は絶対に分からない。

そして通常は一気に全てを書き上げるのではなく、まず小さなコア部分を書き、少しずつ他のコア以外の部分を書き上げながらプログラム完璧ものにしていく。

書き間違えさえなければ正しく動くと知っているプログラムを、上から一行ずつ書いていくプロセスとは正反対だ。

また、以下で述べるようにエラーが発生した場合デバッグ作業は非常に重要であるだが、そのための作法写経から学ぶことができない。

なぜならば、写経中にエラーが発生した場合教科書自分で書いたプログラム間違い探しをまず一番最初に行うからだ。これはプログラミングに関する作業ではなく、むしろ間違い探し絵本とにらめっこしているに近い内容である

それでは、デバッグ方法言語モデルを作るとても大切なプロセス経験できない。

ゆえにそのようにして完成したプログラムもおそらく正しく動きはするが、得られる経験値は驚くほど低いはずである

とは言え、いきなり自分で書けと言われても書けないと思うので、小さなプログラムを一旦は教科書通り写し、その後自分なりに改変していくのがよいと思う。この場合写経にはほとんどが意味がないと思った方がよい。"自分なりに改変する" というプロセスこそ意味がある。

さて初心者が陥りやすい部分については説明したので、

今度はどのように "言語モデル" を自分の中に作っていくかについて説明する。

1. エラーをたくさん出す

初心者エラーを出さない様にと慎重にプログラミングしようとしがちだ。

はっきり言うと、それは間違ったプログラミングスタイルだ。

特に最初のうちは、エラーをなるべく多く出した方がよい。

なぜならば、エラーを出すごとに、その言語の新しいルールを1つずつ学んでいくことになるからだ。

PHP で例えると、

printf の書式だとか

文末に付けるセミコロンだとか

function はネストできないとか

変数には $ を付けなければならないだとか

グローバル変数関数の中で使う場合は global 宣言するとか

などである

初心者のうちは一切上のようなルールは知らないはずだからエラーを全て踏むかもしれない。

例え今回作っていたプログラムエラーを踏まなかったとしても、回数をこなしていけばいくつかエラーに遭遇するだろう。

しかし、それでよいのだ。

エラーを修正することの繰り返しの中で、その言語モデル自分の中に出来てくる。

そのようなトライアンドエラーを繰り返えすことで、"言語モデル" は文字通り体の中に染み込み、プログラムだんだんと書ける様になっていく。

おそらくこれはは自転車に乗れるようになるプロセスと似たようなものだと思う。

誰しも最初は上手く走れずに転んでばかりいるけれど、何度も何度も転んで起き上がってを繰り返しているうちに少しずつ多くの距離をこげるようになっていくだろう。

そして最終定期には、難なく自転車を乗りこなせるようなっている。

プログラミング言語を学ぶ時も同じである

最初は何度やってもいろいろなエラーが出てくる。

それらのエラーを地道に1つずつ潰して間違いを訂正していくうちに、少しずつ多くの行数の複雑なプログラム書けるようになっていく。

そして最終的には、自由にプログラミング言語を使いこなせるようになっていることに気付くだろう。

自転車も本を読んだだけで乗れるようにはなれないのと同じで

プログラミング言語も本を読んだだけで出来るようになれると思わない方がよい。

それらはトライアンドエラーの繰り返しの中でしか得ることはできないし、誰かから教わる類のスキルでもない。

そして、プログラミングを行うからにはエラーとは一生付き合っていかなければならない。

早めにそれに気付いて受け入れる必要がある。

2. デバッグの仕方を覚える

さてエラー重要性については上で強調した。

実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。

期待しない動作をした時のデバッグという。

まずいちばん基本的で一番重要デバック方法printf デバックである。これをまず出来るようにする。

怪しい変数をとにかく printf で出力し、変な値が入っていないかを確かめ方法である

僕が常々許せないと思っていることは、初学者向けの書籍にはデバッグ重要性やその具体的な方法論が非常に重要であるにも関わらず、それについては解説すらされていないことである

初心者からこそ、デバッグ方法論や開発環境をきちんと整えるべきである

ほとんどの言語処理系では、デバッグ作業を支援する機能提供している。

からなければ、"言語 デバッグ方法" でグーグル検索してみればよい。

例を挙げると、

C言語だったら、gdb

PHP だったら Xdebug

Ruby だったら pp モジュール

Schemegauche)だったら #?= デバッグ

javascript だったら firebug

言語はいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。

これは無益時間を過ごさないためにも本当に重要な要素なので、面倒くさがらずに開発環境を整えや方法論をマスターすること。


3 小さく動かして確かめ

最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。

その理由は簡単で、人間は正確無比に物事を進めるのは苦手な一方で、プログラミングでは正確無比に物事を進めることを要求されるからである。そのため、大きなプログラムを一度も実行せずに作成し、一気に確かめようとするとまず間違いなく正しく動作しない。

そして厄介なことに、大きなプログラムを作ってしまうとどこに問題があるのか切り分けすることが困難になるので、ますますデバックが難しくなってしまう。

そのためまず小さく作って小さく確かめ部品を組み合わせてプログラムを作っていくことが大事になる。

一般的に言って、どんなに熟練したプログラマーであろうとも、一つのミスもせずに一定以上の大きさのソフトウェアを作り上げることは不可能である。そのため、ミスエラーはある程度発生することを前提に、少し作っては実行して確かめる、というサイクルをたくさん回す習慣を付ける。

ソフトウェアは一行書き上げた瞬間から指数関数的に複雑性が増大し、気付いた時にはどうにもならなくなっていることも多い。そういう時は思い切って一から作り直すという選択肢検討してみるべきだ。

"Small is Beautiful"

これは非常に有名な unix (という OS)の設計理念である

unix開発者は様々な失敗経験から、このようなソフトウェア開発のベストプラクティスを学んだに違いない。

まだプログラミング経験の浅い人も、これから偉大な開発者経験から学ぶことができるはずである。"Small is Beautiful"。小さく作って動かすこと。


4 Google を使い倒す

先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。

おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。

原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。




現実プログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事能力とは、実は "忍耐力" だろうと少しばかり思っている。

でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。

そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。

ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。





2013-01-18

続・うへぇ苦労するのガイドライン

前のはこれ http://anond.hatelabo.jp/20121219191602

PC-98

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でもなんでもいいですがメジャーかつ現行のマシンにしてください。 

教育機関懐古趣味のバカを量産されると現場が非常に苦労するのです。 

Z80

http://toro.2ch.net/test/read.cgi/unix/992942337/737

737 :名無しさんお腹いっぱい。:2012/09/16(日) 16:27:31.40
今月はじめ、職場に新しい組み込みマシン(ファンレス結構省電力構成)が入りました。 
多分私が開発全般をまかされそうな雰囲気です。業務的にとある構造分析シミュレーションなど行う必要があり、プログラムアセンブラを使用するのは 
聞いていたのですが、添付のサンプルソースコードからチラッと見えたのは 
LD A,(HL)という命令でした。 

「うへぇ~、よりによってZ80かよ」 

アドレッシングモード皆無、リロケート不可、使いにくいインデックスレジスタ、 
今時の関数引数スタック渡しに対応できるのか不安はつきませんし、 
今の若者はこんなCPU使わないので人材も少なくソフト開発も大変です。 
おそらく導入に際して、大学など教育機関最初Z80に触れて刷りこまれた人間強気知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 

昔、当時、8bitCPUi8080上位互換i8085よりも多くのツギハギ命令を追加拡張した 
Z80大学など教育機関に浸透していて、日本CPU界に多くのバカが輩出しました。 

これから私は、おそらくそういうバカが、ADD A,(HL)はできるのにADD B,(HL)は 
できないのかとか、相対アドレスのCALL命令はないのとか、 
スタックフレームポインタとして使いたいのにLD HL,SPっていう命令ないじゃんとか、 
アセンブラ通気取りの偏ったどうでもいい我侭を言い出し(だからZ80使うんじゃねーよ) 
それと戦わなければならないのでしょう。そして時代によって決着している、 
過去30余年のCPU界隈のくだらないそれらの議論が再現され、それに巻き込まれるの 
でしょう。もう今からうんざりです。 

だからお願いです。教育現場ではi386でもi568でもi686でも 
x86_64でもなんでもいいですが現行のCPUにしてください。 

教育機関懐古趣味のバカを量産されると現場が非常に苦労するのです。 

xinit

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でもなんでもいいですがグラフィカルなディスプレイマネージャにしてください。 

教育機関懐古趣味のバカを量産されると現場が非常に苦労するのです。 

tcsh

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シェル系のシェルにしてください。 

教育機関懐古趣味のバカを量産されると現場が非常に苦労するのです。 

続く。

2012-01-18

Python vs Ruby vs PHP vs Haskell プログラミング言語バトル part1

 

42 : デフォルト名無しさん : 2011/11/12(土) 23:53:51.20

Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ

端末からテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに

PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか?

けどまぁ、情弱文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか

45 : デフォルト名無しさん : 2011/11/13(日) 01:41:24.25

数値計算や端末からテキスト処理なんてWeb系じゃ大して使わないからなあ…

43 : デフォルト名無しさん : 2011/11/13(日) 00:04:23.30

PHPが未だに現役なのは、単に歴史的な経緯でしかないだろ

Pythonに関しては、ZopeさえコケていなければWebサーバLLとして大成功していたはずなのに、

Railsなんかが登場したおかげで、すっかり影が薄くなってしまますた....

44 : デフォルト名無しさん : 2011/11/13(日) 00:49:55.28

zopeってコケてたんだ

ってか、railsインスパイアされたフレームワークって今じゃ幾らでもあるよね

djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、

pythonPHPの方がユーザー数は圧倒的に多いと思うんだけど

本家railsって、他を遥かに越えるほど良いものなんだっけ?

48 : デフォルト名無しさん : 2011/11/13(日) 08:30:25.68

44

Zopeが登場した当時、RDB+PHPはもう古い、これからOODB+ZopeWebの中軸になる!」

さかんに宣伝され、雑誌でもZope特集が組まれていた

 

少なくとも自分ZopeからPythonという言語を知ったし、その時点でRubyは知らなかった

そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう

今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい

 

djangoCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう

しかしRailsはRailsコミュニティの活動が活発だし、その進化は異常に早い

 

Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoCakePHPから

何かのイノベーションが提示されでもされない限り、後発のdjangoCakePHPRailsに追いつくのは無理

Railsは決して技術的に完璧Webフレームワークではないんだけどね....(たとえばSeaSideのような.... )

 

からこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている

51 : デフォルト名無しさん : 2011/11/13(日) 12:55:40.83

 C a k e P H P は う ん こ   

遅い、設計が古い、動作がおかしいの3重苦

日本では流行ってないけど海外だとYiiが流行ってきてる

55 : デフォルト名無しさん : 2011/11/13(日) 17:31:12.14

CakePHP使ってんの?

可哀そうにw

53 : デフォルト名無しさん : 2011/11/13(日) 14:44:48.55

求人PHPばかりだからPHPやるしかないだろ。

57 : デフォルト名無しさん : 2011/11/13(日) 19:34:04.95

でもやっぱりいつもの使い慣れたLL(Python/Ruby)で

Webサービスを書きたいってのがある

73 : デフォルト名無しさん : 2011/11/15(火) 17:32:46.07

アメリカ言語ユーザー数は

Python>>>>>>>>Ruby

求人数は

Ruby on Rails>>>>>>>>Django

http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=

どういうことなの?

74 : デフォルト名無しさん : 2011/11/15(火) 17:48:15.59

RubyRails以外に使い道がないか

75 : デフォルト名無しさん : 2011/11/15(火) 17:54:35.50

海外ではRubyは昨今のRailsバブルのお陰で

もはやWebスタートアップ共通語になってるらしいからね

求人数が多いのはそのためだと思うよ

76 : デフォルト名無しさん : 2011/11/15(火) 18:03:23.05

なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・

Pythonのほうが使いやすいと思うのだがフレームワークRailsが優位なんだろうか

77 : デフォルト名無しさん : 2011/11/15(火) 18:23:14.33

Djangoは周辺ライブラリ微妙だし本体も鈍くさい感じがする。

でも、FlaskはSinatraより好きだからPythonが嫌いってわけではない。むしろ好き。

 

ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。

78 : デフォルト名無しさん : 2011/11/15(火) 18:38:46.28

同感だ

同じように思っている人が他にもいて安心した

79 : デフォルト名無しさん : 2011/11/15(火) 18:54:37.13

PHPJavaScalaには

Railsみたいなフレームワークあるのに

Pythonはいいのないんだよな

80 : デフォルト名無しさん : 2011/11/15(火) 21:19:09.89

PHPフレームワークが乱立しすぎているから、RailsPHPで実装してみようというやつが出てきた。

Scalaも注目されだしたのはつい最近のことだしな。

それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、

つの間にかフェードアウト

ただ、どうやってもRailsもどきRailsを超えることはできないのは間違いない。

83 : デフォルト名無しさん : 2011/11/15(火) 21:25:38.55

パクリオリジナルを超えられない(キリッ って定型句だけど、

これってキリッって言いたいだけだと思う。

後発品が先に出たものを超えたものなんていくらでもあるから

84 : デフォルト名無しさん : 2011/11/15(火) 21:30:04.39

D言語って超えたって?

85 : デフォルト名無しさん : 2011/11/15(火) 21:31:12.00

B言語って超えたって?

86 : デフォルト名無しさん : 2011/11/15(火) 21:53:33.76

でもRailsRubyの黒魔術を使いまくりから

PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない

90 : デフォルト名無しさん : 2011/11/15(火) 22:50:07.81

スタートアップなんて根無し草の集まりにとって、

googleが囲った言語coolさを見出せないんだろ

123 : デフォルト名無しさん : 2011/11/20(日) 11:32:16.79

まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ

91 : デフォルト名無しさん : 2011/11/15(火) 22:52:42.98

そういう理由じゃなくてRailsのほうが単純に情報プラグインも多いからでしょ

3 : デフォルト名無しさん : 2011/11/15(火) 23:07:07.67

linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん

わざわざ不合理で不完全な言語を使うなんて

社会からハミ出た奴らの精神的な作用によるものじゃないの?

95 : デフォルト名無しさん : 2011/11/15(火) 23:20:20.21

django情報プラグインが増えないという、

現実に対する鬱憤を吐いてるようにしか聞こえないな

もしも

linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん

真実であるのなら、今頃はdjango情報プラグインが溢れかえっているはず

104 : デフォルト名無しさん : 2011/11/16(水) 01:20:49.05

Python信者乙。

yumや、gdbgnome拡張pythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。

ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。

94 : デフォルト名無しさん : 2011/11/15(火) 23:15:11.93

というか、世界中Pythonプログラマが Remeber Zope!! を合い言葉

打倒RailsたるWebフレームワークを開発しているはずだけど、

いまだにRailsを超えるプロダクトが登場しないのはナゼ?

Railsも登場してから、かなりの年月が経過しているんだけどなぁ....

その間にもRailsRails 3が登場して、REST/AJAXの強化等の進化継続しているよ

347 : デフォルト名無しさん : 2011/12/09(金) 10:16:35.22

Ruby では

ary.map {|x| x**2}

となるものが、Python では

map(lambda x: x**2, ary)

となり、lambda の本体が1つの式では表現しきれなくなると

def mapper(x):

.....

map(mapper, ary)

書き換える必要があります

348 : デフォルト名無しさん : 2011/12/09(金) 10:24:20.94

Pythonのlambdaを用いた階乗計算

f = lambda x:(x and f(x-1)*x)or 1

RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから

andやorを使った不自然記述をしなくても

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です。

390 : デフォルト名無しさん : 2011/12/10(土) 15:35:41.62

348

これはPythondisっているように見せかけてRubydisっているのか? と一瞬思ってしまったw

だってRubyのほうが長くない?CLのfuncallみたいなcall()がちょっとうざいし…

そしてどっちもlambda式の中で束縛変数名前再帰可能、と

350 : デフォルト名無しさん : 2011/12/09(金) 11:12:13.28

要素に対する関数適用と、抽出を組み合わせる場合

Python

print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]

暗号のように見える。

Ruby

puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}

思考の流れと、コードの流れが一致しているので書きやすい。

351 : デフォルト名無しさん : 2011/12/09(金) 11:22:55.04

だれだPythonなら書き方はひとつとか言ってるのは

map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))

354 : デフォルト名無しさん : 2011/12/09(金) 12:22:07.37

pythonて可読性が高いのをうたってる割にはそこいまいちだよね

353 : デフォルト名無しさん : 2011/12/09(金) 12:10:08.46

Ruby場合には、左から右へと無名関数データフローあるいは

パイプラインのように並ぶからコードが読みやすい

 

関数型プログラミングに不慣れな初心者でも、参照透明性のあるコード自然に書ける

プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby

 

それと比較すると、Pythonコードは、関数型プログラミングというもの

いかに高度で難解なものであるかという事をもったいぶってプログラマ押し付け

 

もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう

356 : デフォルト名無しさん : 2011/12/09(金) 12:53:45.66

階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す

result_list = source_list.map { |elem|

  x = foo(elem.x)  # ここが局所宣言を書く部分

  y = bar(elem.y)  # ここも局所宣言の続き

  x + y       # 最後に評価された式の値が、無名関数のリターン値になる

}

Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから

x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける

このポイントは、実用的なプログラム関数型風で書こうとした時に、威力を発揮する

357 : デフォルト名無しさん : 2011/12/09(金) 12:59:21.07

余計分かりづらくなった

358 : デフォルト名無しさん : 2011/12/09(金) 13:17:26.54

リスト内包表記が暗号みたいと言ってる奴は

高卒ドカタなんだろうなぁと可哀想になる

大学数学に触れる機会があれば

集合の表記に似せてることが分かるから

386 : デフォルト名無しさん : 2011/12/10(土) 01:41:34.46

数学とかで慣れてるし区切りが関数のがわかりやすい

359 : デフォルト名無しさん : 2011/12/09(金) 13:46:31.97

355

map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。

関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね

Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ

360 : デフォルト名無しさん : 2011/12/09(金) 13:53:28.85

Rubyだと直感的に書けるコード

[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')

Pythonだと読みにくい。

'-'.join(map(str, reversed(sorted([1,4,3,2]))))

361 : デフォルト名無しさん : 2011/12/09(金) 14:07:17.88

360

Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....

364 : デフォルト名無しさん : 2011/12/09(金) 14:28:55.99

カッコだらけのコードを分かりやすくする基本的な方法静的単一代入じゃないか

Rubyのやり方は基本ではなく玄人のやり方だろ

372 : 369 : 2011/12/09(金) 16:21:03.82

Pythonでは組み込みの型でメソッドチェインはやって欲しくないな

listにmap,filterメソッドができたとしても、

似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。

シーケンスプロトコルの利点が活かせない。

383 : デフォルト名無しさん : 2011/12/10(土) 01:17:28.39

372

外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてます

Rubyユーザーは列挙可能なものmapselectできて当然だろって思ってる気がしま

377 : デフォルト名無しさん : 2011/12/09(金) 18:41:51.79

Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる

得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない

Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い

379 : デフォルト名無しさん : 2011/12/09(金) 18:48:52.27

Pythonユーザー調教っぷりは異常

「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く

387 : デフォルト名無しさん : 2011/12/10(土) 13:40:40.74

リストの内包表記はシンプルに書けるときは使うけど

基本その場でdefするのがPython風なんだと思う。

389 : デフォルト名無しさん : 2011/12/10(土) 14:40:31.04

無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像

384 : デフォルト名無しさん : 2011/12/10(土) 01:23:49.48

outer(center(inter( arg )))

これを読みづらいと感じるのは、左から右に流れる

日本語文に慣れているからだと思うが、

もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか?

385 : デフォルト名無しさん : 2011/12/10(土) 01:34:57.89

なるほど、ということは右から左、左から右どっちでも行ける言語が最高ですね

F#パイプライン演算子最高ということで

2011-12-12

コンピュータプログラミング概念技法モデル」の目次

第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 練習問題

2011-04-16

http://anond.hatelabo.jp/20110409113742を書いた者です

自分が言いたかったことは1つなのですが、そこから自分が気が付いて欲しかったのは3つのことなです

1つのことっていうのは

  • 100%の安全なんてありえない

なのですけど、そこから気が付いて欲しかったのは

なのです

原子力は安全」と思っている人にも、こういった事故は絶対起こらない・・・と思っていた人はいたかと思います。

が、3つ目のことから、「原子力危険だけどある程度ちゃんと制御すれば事故は起こるかもしれないけど安全」と思っていた人の方が多かったのではないでしょうか。

自分はむしろ「原子力は安全じゃないじゃん」と言っている人「事故なんて起こしてけしからん」と言っている人、事故を見て原発を即時停止しろと叫んでいる人こそ事故は100%起こらないと思っていたのではないかと思いますし、そういう人は別の発電方法では100%事故は起こらないと思ってそういうリスクから目をそむけているのではないでしょうか。

実際、火力発電所事故は、燃料・・・たとえば石炭であれば炭鉱爆発や落盤による事故石油であれば油田ヤード火災タンカーの座礁による原油流出事故天然ガスならパイプラインガス田での爆発事故があり得ます

そういった事故から目をそむけていませんか?という意味でこの記事を書きましたし、原子力は絶対安全なんてありえないか原子力に頼るのはもう限界なんじゃないか・・・と言う意味でもこの記事を書きました


自分は、「原子力は人が扱えるような代物ではない」と常々思っていました。所謂「パンドラの箱です

原子力危険だけどある程度ちゃんと制御すれば安全」って言うけど、結局は人が制御できるような代物ではなかったんだ・・・と言う感じでしょうか。

ですが、柏崎原発が1機止まっただけで夏場に電力不足騒ぎが起こったのですから原発即時停止は現実的でないように感じます

他の発電のメリットリスク等々を考慮に入れた上で、理想的な原発段階的削減が行われていくことに期待しています。

2011-04-13

東日本大震災から一ヶ月 過ちを繰り返さない為に。

まず最初に、今回の地震と津波に際して早くから支援体制を敷いていただいた

食品メーカーの方々

それを高速も動かない間にも届けてくれた運送関連の方々

販売をしていただいたスーパーの方々

本当にありがとうございました

現在も被災地への物資提供・医療支援・ボランティアを続けて頂いている

企業や個人の方には感謝してもしきれません。

未だ満足にインターネットや連絡手段が取れない被災地の方に代わりまして

御礼を申し上げます。

また、地震発生時から燃料不足など困難な状況でありながら

昼夜問わずインフラ復旧の為に当たっていただいた電力水道ガス道路関連の方、

市ガスに関しては現在も名古屋ナンバーや大阪ナンバーなど遠方からも

現在も支援を頂いている状態です。

余震による新たな再点検を求められるといった苦境が続いておりますが

自身の安全も含めて無理を成されないように。

市ガスに関しては仙台の天然ガス施設が被害を受け、新潟からのパイプラインで提供されています。

下水についても今回の津波で破壊されたり電子系統がやられた関係で2~3年は簡易処理しか出来ない状態です。

宮城県に限らず被災地を抱える県の方で処理場が機能してない地域の人は

自分たちは水が使えるからと今までのような使い方をしてしまいますと

疫病が発生する可能性も否定できませんので節水に努めましょう。

津波で下水処理場、ゴミ焼却施設に大きな被害、想像を超える宮城県内各施設の被災状況(2)

http://www.toyokeizai.net/business/regional_economy/detail/AC/6cce509478eb9164e8311792de9d52d3/page/2/

下水道復旧は数年かかる見通し 沿岸部に集中、被害深刻

http://www.asahi.com/special/10005/TKY201104020353.html

>下水管や処理場が復旧しないと、汚水が路上にあふれ疫病を引き起こす恐れすらある。このため新潟、札幌、大阪など自治体下水道事業者からのべ2600人が応援に駆けつけ、被災状況の調査や簡易処理での復旧の手助けをしている。

過ちを繰り返さない為に。

私が住んでいた地域は幸いにも地震から2日後という

早期に電気の復旧が行われた為、

手元にあったIS01ワンセグテレビと充電池でギリギリ間に合わない程度で

情報難民にならずに済んだという綱渡り的状態だった。

その間もワンセグで見ていた、地震だ!津波だ!何人が死んだ!

在京キー局主体報道が並ぶ。

そして思った。

それを今、報道してどうなるのだ、人一人も助けられないじゃないか。

家族や親戚が居ても津波の被災地に行く手段は無いのだ。

津波による第一報の大切さはわかる。

でも、それが終わったら次の事を考えなきゃいけない。

死ななかった人の命を如何に助けるかだ。

まずは

車での移動はしないでください、

ガソリンスタンドも人工呼吸器で発電機が必要な人など

不要不急な人には売らないでくださいとマスメディアは伝えるべきだった。

緊急車両だけに、と。

実際、兄は帰宅困難者自動車で幹線道路が大渋滞する中で

進まない自動車を置いて3時間歩いて我が家に立ち寄り、

更に30分歩いて帰宅していった。

自宅の電気が13日夜に復旧した翌日の14日、

電気が復旧したテレビで見た情報が計画停電発表による東京での買い占め、

ガソリンスタンドへの行列との報道である

計画停電の影響で弁当やパンなどがいつも以上に売れる事は別におかしくないと

最初、連日の報道に何やってんだかという呆れがあったが

次の瞬間、恐ろしさに気づいた。

そのガソリンや軽油が届かない事で間接的に救える人を殺しているのではないかと。

共に千葉のコンビナートが被害を受けたことによる需給バランスが崩れた為だ、

それにすぐ届く訳じゃないと思いながら軽い怒りと

コンビナートがやられたという事による燃料不足の長期化と

地震が起きる前に石油精製の設備が余ってるという情報を報道で知っていたから

どちらなんだろうという不安が感じた事を憶えている。

後に撮影した写真を確認しながらに

仙台でも地震発生後に冷静さを失い

自分が良ければ、家族は大丈夫だろうかという感覚で

多くの自動車ガソリンスタンドに並んでいた事を思い出すと

間接的に人を殺したかもしれないという意味では

仙台も同じだなと人の事言えないじゃないか思い直した。

仙台港石油コンビナート鎮火 「在庫配分、被災地優先」宮城知事

http://www.kahoku.co.jp/spe/spe_sys1062/20110316_39.htm

この15日緊急車両優先と宮城県知事が指示するまで

仙台で起きた事は地震発生翌日後ガソリンスタンドが自主的に行なった

一般車ガソリン5L10L規制+

整理券受け取りまで朝方から4時間待ちで受け取り午後3時といった

自主規制だった。

次に重要なのが生活情報だ。

給水車は何処に出てますと行った情報もテレビのL字に載り始めたのが13日か14日

スーパーマーケットの営業情報については17日である

後に知ったがラジオの方が生活情報を流すまで早かったとの事。

震災時に必要なのは発生時のみ映像で確認が必要なテレビ

後は生活情報を放送しているラジオの方が重要だ。

そして情報を得る為に重要な電池。

準備はしていたつもりが充電池の自己放電で3セットの内1セット、

しかも半分程度しか残量が残っていなかった。

これが今回の最大の危機であり、認識の甘さが露呈した格好となった。

頑張れ日本、がんばろう日本、日本の力を信じてるへの違和感

日本テレビ系の3秒キャッチCMで

頑張れ日本、がんばろう日本と言い出したのは3月20日

http://woman.infoseek.co.jp/news/entertainment/story.html?q=20110320hochi169

http://mainichi.jp/select/biz/bizbuz/news/20110320dog00m020025000c.html

ACジャパンサッカー編はYoutubeの日付を見ると22日

http://www.youtube.com/watch?v=Pre2YcOROnk

サンスポによるとSMAP編が23日サッカー編が24日

ACが新CM制作!SMAP、長友ら出演 

http://www.sanspo.com/geino/news/110324/gnj1103240505012-n2.htm

その頃の仙台のガソリン事情 ブログ報知

http://weblog.hochi.co.jp/tajihouronn/2011/03/post-8942.html

青葉区北仙台のあるスタンドで前日の夜9時から並んだ男性は、

>翌朝7時半の開店と同時に10リットル制限の給油に成功。

>しかし、11時前には完売となりました

>この日給油ができたのは約300台。

>後続の200台以上の人々は徒労に終わりました

その頃の仙台のスーパードラッグストアの様子

仙台の物資状況 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からみるにミヤギ生協です。

ミヤギ生協はそれでも全国から商品をかき集めていて商品が充実してる方でした。

高速が一般開放された3月24日がターニングポイントで3月26日から商品が徐々に入ってきました

それまでは大根一本300円、キャベツ600円、タマゴ400円といった状態です。

それでも商品が買えた仙台はまだ良い方です。

この頃、津波の被害を受けた被災地は悲惨です、

一日1食や2食、一日おにぎり一個コッペパン一個の世界です。

仮にお金があっても禄に買う所も水も電気もガスもありません。

それで計画停電したから東京目線でがんばろう日本、頑張れ日本なんて言ったら

被災地は見捨てられたと思うでしょう。

それ以前にがんばろう日本、頑張れ日本って誰に言ってるの?

食事も無く、ろくに暖房もなく、薬もガソリンが無く届かなくて

避難所だけで30人以上亡くなってるのに。

被災者に頑張れって言うの?命を繋ぐ事に精一杯なのに

頑張れる人はもう限界まで頑張ってのに。

意味が分からないよ。といった状態でした。

そんな状態で頑張れなんて言われたら鬱状態になり、

下のような言葉が被災者から出てくるのは仕方がないじゃないですか

それなのに

>何でこんな態度でかいの?鬱病つーかただのクズ

とか、他にも叩くような事がはてブに書かれています。

はてブで書けるなって、

人として本当のクズをはてブでこれだけの数同時に見るとは思いませんでした、

ただただ怒りしか湧いてきません。

「『頑張って』と言わないで…」被災地からの悲痛な声。

http://www.excite.co.jp/News/entertainment_g/20110320/Techinsight_20110320_50513.html

3月19日の『ニュース 深読み』(NHK総合)では、被災者から次のようなコメントが寄せられた。

>「電気が復旧し、避難所から自宅を片付けるため家に戻った。あまりの惨状に呆然としていると

テレビから、“頑張ってください。”との声がしてきた。何度も何度も。

>“これ以上、どうやって頑張るの?”と悲しくなった。」

>「“頑張ってください。”って言葉を聞くたびに、落ち込んでしまいます。」

頑張れとか復興とかって、多分、今言うことじゃない。

http://anond.hatelabo.jp/20110407001402

>すげぇ言われてるんだけど、CMとかで、頑張れ頑張れとか。

>ちょっと気を許すと、「一緒に頑張ろう!1人じゃない!」とか言うわけ。

>いや、おまえら家あるじゃん?そのCM撮ったら家帰ってるじゃんって。

>仕事もあるじゃんって。

>「正直、不幸になってくれたら嬉しい」

>と言われた。

CMについて思っていた気持ちを書いてくれたID:nakamurabashiさんの記事です、

これを読んで今回の事を書く気になりました

[雑文]なんかいろいろおかしいなーと思った話

http://d.hatena.ne.jp/nakamurabashi/20110410/1302373143

>なんていうのか「だれが」「だれに向けて」「なんのために」言ってのかまったくわからなかった。

>あれ、サッカーの日本代表応援してても同じじゃねえかな、って。

>で、さっき不意に気づいた。まず、被災地の人たちはがんばれない。がんばれるわけない。

だって、家とかなくなって、体育館とかで暮らしてて、がんばれるはずないじゃん。

>じゃあ「がんばれ」のメッセージはそれ以外の人たちに向けられている、と考えられるんだけど、

>じゃあ、あの大量のがんばれ日本とか強いぞ日本とか団結は日本の力って、いったいなんなんだろう。

ふつうの人たちのがんばりの許容量を超えたがんばれメッセージけが大量に出回ってる。

>善意搾り出さなきゃいけないってことか。そうやって搾り出された善意どこ行くん。千羽鶴作ればいいん?

この時期に必要な言葉は被災者に向けてなら

いつになったらこの状況を抜け出せるのかという希望です。

頑張ろうという言葉も最低でも食、衣食住が足りて

そして被災者被災地域の方からの声として出るべき言葉であって

その地域以外からの頑張ろうの強制ではないはずです。

被災地域以外であれば酷い被害状況ですが、

今も命の危険に晒されてながらも助けられる命があるのです、

その命を助ける為にも〇〇日まで我慢してください。というべきだったはずです。

また、どんなに平凡な表現であっても伝えるべき言葉は

頑張れ日本やがんばろう日本、日本の力を信じてるではなかったはずです。

フジテレビひとつになろうと言ったって情報共有が成されなければ

その言葉だけでは思いをひとつになんかなれないのです。

頑張れ日本やがんばろう日本といった被災者を傷つける言葉や

日本の力を信じてるという意味のない言葉より

まだテレ朝テレビで、日テレホームページで言ってるつながろう日本の方がまだ伝わります。

「被災に遭っても頑張ってる姿、助け合う姿、必死に生きようとする姿に感動しました

「過酷な状況なのに物資の奪い合いも強盗盗難の類も少ない」

何を言ってるんですか、非常に厳しい状態でこれ以上誰も死んで欲しくないと

思えば誰だって助け合い支えあうはずです。

命があるだけでいいのです。

私も今回の震災で叔父を亡くしました

今、命がある被災者を全力で支えることができるのは生きて無事な人間だけじゃないですか

被災者を頑張れる環境まで持っていく事が今できる我々の責任じゃないんですか。

死んでしまったらどうしようもないんです、取り返しは効かないんです。

また日本では同じように大震災といわれる事が起きるでしょう。

その状況の時に今回と同じ事を繰り返してはいけないのです。

備蓄について

今回の地震で分かった事は在庫を抱え込まないかんばん方式やコンビニの単品管理に代表される

在庫最小化は物流が途絶えた途端に近所のコンビニスーパー

「近隣地域お客様冷蔵庫」の機能を失うということです。

今回は地震が起きた時が午後3時に近い頃でまずはみんなが自宅に帰宅して

家族の安否確認をすることに必死で何かを買って帰ろうという余裕も無く、

停電したことから店側の準備も整ってなかったことから

翌日からコンビニスーパーガソリンスタンド

普段は賞味期限が切れた商品を売ってた個人商店でさえも

長蛇の列が出来ることになる。

イオンヨークベニマルイトーヨーカドー系列)などは2時間待ちにもなり、

開店している店の商品は一日で底を突く。

更に翌日は開くかどうかもわからない店に皆が並び店員が大慌てで

仕方ないとばかりに繰り上げ開店を行い、商品は消えていった。

まるで食欲旺盛な大蛇があるだけのエサを丸呑みして行くようだった。

この時に大切なのが

平時に普段、自分の家で消費する一ヶ月分の物を備蓄しておくこと。

そして出来るだけ買い占めなきゃ不安だという気持ちを周りに起こさせない事である

ちなみに私は自慢じゃないが貧乏だ、貧乏人には貧乏人らしい

備蓄のやり方がある。

その家によって違うと思うが

米なら楽天辺りで30kg買って米びつに一袋分(10kg)+一袋10kgで合計20kgになったら

一袋10kg買い足して20kgを割らないようにするだけでも主食は確保できる。

基本的に精米した米は賞味期限が短い、

3ヶ月も持たないというか食べられなくはないが風味は落ちる、

虫が付くかもしてないと米屋さんなら言うだろう。

また、備蓄向きと思われているインスタントラーメン賞味期限一年持たない。

特にフライ麺の賞味期限切れは食あたりの可能性があるので賞味期限は守った方がいいです。

2chのスレなどを見ると麺を茹でてお湯を捨てれば

メーカーが余裕を見て設定してるであろうマージン分3ヶ月ぐらい過ぎても食える的な話もあるが、

かやくやスープダメになるらしく

災害時で最も重要な水を捨てるという蛮行を働けば下手すりゃ死にかけます。

止めておきましょう。

日清食品 よくお寄せいただくご質問

http://www.nissinfoods.co.jp/utility/customer/faq.html

弊社で販売している製品の賞味期限は通常製造日からカップめんで5ヶ月、袋めんで6ヶ月となっています。

スパゲッティと乾燥大豆は涼しく風通しのいい所に置くと3年間持つので

スパゲッティを500g入り20袋=10kg用意しておくと飽きが起きにくい。

また乾燥大豆はどうしても起きやすい野菜不足タンパク質不足を解消できる

備蓄のマストアイテムと言ってもいい。

いっそのこと避難所に備蓄して欲しいくらいだ。

イタリア軍の逸話を知ってる人はスパゲッティは水を大量に必要になるじゃないか!

と言うかもしれない。

それはあくまで茹で汁を捨てるという事を前提にしている。

スパゲッティを茹でる時は塩を入れないで茹で汁を味付けし直せば

スープにもスープスパゲッティにもなるのだ。

乾燥大豆は30kg単位で買うのが一番安い。

楽天などのインターネットショップ

国産大豆でも1万円、アメリカ産大豆でも6000円程度であることから

お米と変わらないぐらいの安さだ。

30kgを買ってみたが二人分と考えると一合カップで量ると150g程度で二日分になる。=400日

一袋で一年程度、多すぎると感じたら知り合いと分ければいい。

大豆ダイエットで有名な大豆イソフラボンの影響か、大豆を食べて自転車で移動するようになったら

一年で100kg→70kgになった。ダイエットにもおすすめである

地震があった時点での備蓄は

米が米びつに一袋分(10kg)+一袋10kgで合計20kg

スパゲッティ500g入り25袋 12.5kg

乾燥大豆 10kg程度

中国産わかめ100g×5袋

賞味期限が切れた いりゴマ1kg5袋=5kg

賞味期限が切れた 札幌味噌ラーメンスープの素1kg7袋

賞味期限が切れた インスタント味噌汁250個(一袋100個入り)

この賞味期限が切れたものは賞味期限間近の商品を格安で売ってくれる所を

見つけたので買い貯めしていた物だ。

乾物や熟成が見込めるもの、アルミパウチな上調味料ラーメンスープなどであることから

多少、賞味期限を超えても大丈夫だと思って買った物、

どれも賞味期限が半年は過ぎているので気になる人にはオススメしかねる。

今回の震災を乗り越えられたのもこの備蓄でバリエーションが増やせたから

という気がしないでもない。

長期戦の場合に野菜+肉不足で抵抗力が落ちる可能性が高い。

ビタミンCコストを考えるとDHCなどのカプセルで、

ビタミンAはレバーを下茹でして冷凍庫に入れておこう。

レバーは5gで一日に必要なビタミンAが得られる。

災害時は水分も大切だ。

普段は飲まないがお客さんように特売日に100円で買ったジュース

備蓄してあった。

ジュースは意外と賞味期限が長く9ヶ月ぐらい持つものもある。

ただし、炭酸入りだと賞味期限近くなると微炭酸になってしまう、

その点は注意。

バヤリース1.5L×2本

伊藤園天然水ソーダ1.5L×2本

本当ならば給水所ができる3日間に必要なペットボトルの水を準備しておいたほうがいい。

一人当たり一日2Lペットボトル1本が目安だ。

備蓄ではないが他にあった水分は

ヨーグルトを作る為に買って置いた低脂肪牛乳1L×4本

電気ポット(1Lタイプ)+魔法瓶エアーポット(2.2Lタイプ

うちでは小型の電気ポットで沸かしてエアーポットに入れるようにする事で

保温時の電気を使わないようにしている。

と同時にお湯を移して空になった電気ポットに常に1Lの水を入れておく事で

断水時に最低1Lの水を確保できるようにしている。

LPガスという状況下での苦肉のエコ+災害対策という訳だ。

エアーポットのお湯が温くなれば電気ポットに戻して沸かし直したり、

もう1L沸かしたお湯を入れればいい。

エアーポットは空気が多ければ多いほど冷えやすい、

朝2L入れて徐々に使ってぬるくなったら料理に使ってもいいのだ。

 燃料や電池の備蓄について

今回、問題が出たのが電池だった。

準備していた物が単三12本。

しかし、自然放電と昇圧機能のないUSBコネクタ付きバッテリーケース

BP‐1だった為、充電が直前まで使っていた1セット分しか使えなかった。

USB出力付電池ボックス2種を試す 【起】

http://mast.cocolog-nifty.com/main/2010/03/usb-e306.html

電池の備蓄を考えた場合

エネループか普段使いの100円ショップ充電池+アルカリ乾電池の二択だろう。

電池は時間が経つほど残量が減って行く。

使用推奨年月日が製造から5年の物が多い物を考えると

一年目に5セット買って一年毎に1セットづつ買い換えるという事がよいのではないかと思う。

余震の事を考えるとロウソクよりLEDライトの方が安全だからだ、

ラジオ+LEDライトと考えるとそのくらいは必要だろう。

100円ショップアルカリ乾電池 性能評価実験

http://www.kansai-event.com/kinomayoi/battery/alkaline.html

>上位のほうが消費期限が長い = 製造から日が経っていない。

>という考察もできるのではないでしょうか。

グラフに載せている「オーム電機(参考) 消費期限04-2005」や

>「富士通7300(参考) 消費期限 08-2003」の電池はかなり性能が落ちています。

燃料の備蓄について

今回、電気が二日後に回復したという奇跡的な状況が起きた事や

地下埋設型のLPガス事で安全ピンが作動する事もなく当日から使えた事が

他の方と比べて非常に楽な展開になったは間違いない。

ガスが使えない状態であったとしたら

カセットコンロか石油ストーブ

+余裕があれば電気があれば使えるIH卓上コンロを準備する必要がある。

カセットコンロカセットガスを最低限用意する事は

必要としてカセットコンロに載る鍋やフライパンサイズは28cm、

ミニサイズカセットコンロは18cmが標準的なので注意しよう。

カセットガスは高いので電気が復旧したらIH卓上コンロに切り替えたい所だ。

両方使えるIH対応の物を普段から使っておきたい。

石油ストーブは暖房と料理両方に使える凄い奴。

しかし、備蓄の事を考えるとエアコンがある家は持っていないケースが多いかもしれない。

また、地震での転倒による火災発生などに気をつける必要がある。

灯油に限らずガソリン軽油といった石油類は使わずに一年間置いておくと

劣化してしまい煤が不完全燃焼が発生する可能性がある。

どうやら燃料劣化防止剤スタビルというものがあるらしい。

よく分からないが調べてみてはどうだろうか。

http://minkara.carview.co.jp/userid/355641/car/259411/1470407/parts.aspx

http://item.rakuten.co.jp/yusayusa/10000460/

トイレットペーパーラップフィルムの備蓄について

トイレットペーパーシングルで12コ入りのものを3セット準備しておくとよい。

これも最低2セットは維持しておくこと。

鼻紙から食器の汚れを拭き取るのにも使える。

水が重要な時に力を発揮する。(特に汁物を食べた時)

ラップフィルムは100m巻を使っていたが

備蓄としてはそんなに必要ではないかもしれない。

ダイソーイオンで売ってる40M巻を2本買って一本維持する形でいい。

水汲み道具の準備

折りたたみの水を入れるウォーターバックみたいなものもありますが

常日頃から水を貯めるということを意識して

ゴミ捨て場に捨ててある4Lの焼酎ペットか20L焼酎が入っていたキューテナーを保存しましょう。

焼酎が入っていたものなのでジュースペットボトルと違い、

衛生状態がいいので使いやすいです。

水専用のポリ管を用意してもいいです。

最高気温が20度以上(スプレーで黒く塗っておくと15度以上)

の気温になって晴れの日に4Lペットを日の当たる外に置いておくと

体を洗うのに丁度いい温度になります、一人が全身を洗うには16Lは必要です。

日頃から近くのゴミ捨て場でカンビンペットボトルの日にもらっていきましょう。

4本置いて温まったら翌日が雨でなければ新しく水を入れたペットボトルと交換して置いておきます。

一人当たり8本あるとスムーズに使えます。

これもLPガスが高いから考えついた方法ですが

夏場などで備蓄の水が多く必要になる季節にマッチしています。

今回は原発の影響で放射性ヨウ素水道に含まれていました

放射性ヨウ素131は半減期が8日ということで

テレビで学者さんが言うには一日10%ぐらい下がる的な事を言ってたので

それ対策と地震後に白濁が発生しやすいので

それを避ける為に貯め水用としても4Lペットは便利です。

ですが、大きすぎて蛇口から水を入れられない場合があります。

その場合は醤油などに使われている取っ手付き1.8Lペットに入れてから移すか

瞬間湯沸かし器の目盛を水にして入れましょう。

津波や計画避難など家を離れなければいけなくなった時に持って行けるもの

リュックサック一つ分と考えたほうがいい。

数日分の着替え、500mlペット2本、クッキーや飴玉などの最低限の食料

貴重品、モバイル機器 歯ブラシ等衛生用品 トイレットペーパー1個 ゴミ袋

赤ちゃんのおしりふき(体を拭く為) 使い捨てマスク トランプ双六ポータブル将棋

皮手袋 軍手

他にもあるかもしれないので教えて欲しい。

軽登山に必要なものを参考にするといいかもしれない。

災害に強いスーパーマーケット、災害に弱いコンビニ

今回思ったことがスーパーコンビニの差である

スーパーコンビニの一週間以上早く商品が入荷し始めたのに比べて

コンビニは遅く入荷数も少なかったのである

更にチェーン毎の復旧度合が明らかに違ったのだ。

具体的に書くと

スーパーの開店情報については河北新報で17日から掲載されるようになってきているが

26日時点で

ローソン 食品なし

ファミリーマート 山崎菓子パンコッペパンソーセージパン)、東洋水産緑のたぬき赤いきつねのみ

セブンイレブン おにぎり賞味期限が長い弁当(4日間ぐらい)業務用の牛乳、タマゴ、食パン

サンクスは閉店の所が多く比較できなかった。

同日にヨークベニマル、みやぎ生協、ウジエスーパーと回ったが

ヨークベニマルとみやぎ生協は頑張っていた記憶がある。

つまり燃料不足な状態では店舗数が多いコンビニは不利で

また最小ロットを1個からという必要な分を必要な分だけ

送る為には合同配送センターが必要となり

スーパーのように箱買いで直に送ってもらう事ができない構造が

立ち遅れを招いたと見ている。

スーパーには惣菜加工のキッチンが付いてることから

原材料が手に入れば加工出来てる違い

2011-01-28

ここ数年に中国で爆発したもの

変電所変圧器

湯沸かし器

・肥だめ

アルコールランプ

爆竹工場

ネットカフェ

シリンダーチェア

・温水便座

・ゆたんぽ

・IH調理器

携帯電話

掃除機

飛行機

・教習車

タクシー

・というか、車全般

バス

タイヤ

マンション

・偽iPod

炭鉱

石油パイプライン

石油コンビナート

飛び降り自殺のおっさん空中で爆発

道路が爆発してバスが吹き飛ばされる

圧力鍋

誕生日ケーキのローソク

プラスチック工場

・油の加工工場

テレビ

・民家

花火工場

・公衆トイレ

郵便小包

団地

ロケット

化学工場

・電動バイク

病院

税務署

テーマパークアトラクション

カラオケ

原子力発電所

懐中電灯

ビール瓶

・カーエアコン

・歩行中の中国人

・風船1500個が爆発

労働教育

・AV女優蒼井そらの人気

マンション価格

労働者の不満

サッカー代表チームに対する怒り

 (順不同)

2011-01-14

http://anond.hatelabo.jp/20110114230925

そこまでやるなら

"\xNN\xXX\xXX\xXX\xXX"[i%15]

でよかろ。-'F' する意味が無い。¥x00 の形式で非ASCIIも指定できるんだから

はいえ、いまどきの パイプラインガシガシのコンピューターだとキャッシュがあるとはいえ、メモリアクセスで、レイテンシとレジスタのみでifジャンプとどっちが速いかは、やってみないとわからんなぁ。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん