  |
はてなキーワード: 拡張とは
ガラケーを持っている方はすぐにスマートフォンに変更しましょう。
ガラケーのほうが電話がしやすいという意見が一部ではあるみたいですが、ガラケーは電話に特化されたものですから当然です。
小さく折り畳んで携帯でき、物理キーによるしっかりとした押しごたえはなかなかスマートフォン（以下スマホ）で体験できるものではありません。
しかしそれはよく考えれば当たり前のことで、まずスマホは電話ではありません。
いえ、もちろん歴史的な経緯を考えれば言うまでもなく携帯電話の延長線上にあるのですが、
事実として、スマホにおいては電話機能は百あるアプリの一つでしかありません。
通話するだけならば、ガラケー（特にらくらくホンのようなモデル）がベストなのは間違いありませんが、
そもそもの問題として、我々はどれだけ通話機能に比重を置いているのでしょうか。
仕事で用いる場合を除き、一日にそう何度もするものではないのではないしょうか。
我々はスマホによって、音楽を聞きながら近場の人気店を検索し、マップに導かれながら歩を進めることができます。
電車内ではSNSによって友人たちと思考を共有しながら、RSSリーダーで最新ニュースを流し見することもできますし、
ふと気になったものがあれば、即座に写真やメモとしてクラウド上にアップロードすることができます。
こうした生活は慣れない人からすれば奇妙に映るかも知れませんが、現実をより豊かに、便利にしていく存在として普及していくのは間違いないでしょう。
これらがなくとも生きていけると主張する向きも一方ではあるのかもしれませんが、
産業革命を例に出すまでもなく、古い概念によって設計されたものはやがて淘汰されていくのが宿命です。
ガラケーにおいて一番利用頻度の高いツールに電子メールというものがありますが、これらも衰退傾向にあります。
欧米の若者の間ではすでにSNSに取って代わられているという現実がありますが、そうでなくとも電子メールはあまりにも効率がわるく、
情報交換を円滑に行うツールとしては到底最適であるとは言えません。
ちょうど2年前の春先にiPadが発売された当初は日本でも多くの懐疑的な声が聞かれました。
しかし現実はどうでしょう。iPadは代を重ねるごとにその販売数を増し、
アップル社が時価総額世界一、もしくはマイクロソフト社の2倍という記録的な数字を叩き出すなかでその主力商品にまで成長して行きました。
iPadに限らず、タブレット型端末は今後のポストPC時代を大きく牽引していく製品になっていくでしょう。
こうした劇的な変動はいままさに起きており、旧来型の発想に囚われているようでは20年前の中間管理職がPCに悪戦苦闘したように、
時代の波からは大きく取り残され浦島太郎状態になってしまう恐れが大いにあります。
ガラケーひとつで的確な情報収集ができますか？SNSにアクセスできますか？クラウドにファイルをアップロードできますか？
「外部仕様を変更しているサービスはない」という指摘が多いので追記。
てか、FacebookもTwitterも、外部仕様をもりもり変更してますよね。Facebookなんて既存の機能が無くなったことが何度もあるはずだし、TwitterもWebインタフェースを全面的にREST API経由に切り替えた当初は批判が凄かったと記憶しているけど。
結局、「うまくやるか、うまくやれないか」であって、要求の変更が仕様の変更を求めているなら、それをすることも選択肢から除外されることじゃない。
はてなブログの場合は、過去の強み（職人芸で構築されたインフラ、はてな記法、カスタマイズ性の高さ、etc）が現在の負債になっているという状況で、「じゃあ、作り直しましょう」という判断自体はそんなに間違っているとは思えない。つうか、数年ブランクが空くと痛切に感じるけど、はてな記法辛いよ、実際。もうreSTかmarkdownの拡張でいいじゃん、という感じがする。
結論としては、「はてなダイアリー2.0」を作っても誰も得しないし、不満がある人はそのままはてダ1.0を使い続ければいいじゃん、ということ。
バランスの問題。
行き過ぎたレベリング重視型MMOが批判されたのもこれでしょ。組織的廃人や中華、キャンピング有利、時間拘束、etc。時間がない人はどうにもならない。選ばれた廃人だけが残っていくので新人が非常に参入しにくい。RMTが蔓延しやすい。
あと昔の攻撃力いくつうｐ！みたいな課金チケット必須なチョンゲやガチャ偏重ゲー、今も一部あるけど少数の超重課金から搾り出すモデル。メーカーは普通に遊ばせるための開発が馬鹿馬鹿しくなってゲーム内が貧弱に→ガチャしか更新しない。ゲームがうまかったりしてもあまり意味がないので、上達するのにやりがいを感じる人が萎える。
時々やるだけの人も沢山時間を使う人も遊べる。
金かけて即最強や課金装備持ってない奴はダンジョン来るなになってしまうような課金装備はださない。変わりにおしゃれ装備や成長が早くなるチケットを売る。時間がない社会人はチケットを買って、時間が有り余ってる人は無課金で時間を武器に。
出来る行動や到達できる強さには差を付けず、この二つの層が一緒に遊べるようにする。
課金装備もゲーム内で取引可能にして、日本円がなくて時間がある人はゲーム内マネーで取引して入手したり、時間をかけて入手できるようにどちらのルートも確保する。そうすると、日本円課金組とゲーム内マネー大量組みでいがみあうこともないし、ついでにRMTも阻止できて万々歳。（だって公式で売ってる課金アイテムをうった方が安全で効率よく日本円をゲームマネーにできる）MMO以外でもバランス型のネトゲはある。
一巡してサービスの質を謳って月額に戻る流れも若干あるな。もしくはゲーム内の必須ではない特定サービスに月額課金と同じような実質定額の料金がかかるモデル。ゲーム内の拡張倉庫の維持にお金がかかったり、土地の維持にお金がかかったり。アイテム課金という名の擬似月額課金みたいのもんだ。
大事なのはさ、払うお金にユーザーが納得できる価値があるかだよ。それが満足度が高いってこと。十分に金を払う価値があると思うなら気持ちよく金払う。課金叩きというと経済をわかってない嫌儲みたいに短絡されそうだけど、お金を払うのが嫌なんじゃなくて、価値がないと思うことにお金を払いたくないんだよ。
今のソーシャルゲーはとてもじゃないけど金を払う価値が無いと思ってる層がいるってこと。
当然、世の中にはネトゲに金を払う価値がないと思ってる人もいるし、パチンコに金を払う価値がないと思ってる人もいるし、ブランド物に金を払う価値がないと思ってる人もいるし、放射能対策を謳ったお高いお野菜に金を払う価値がないと思ってる人もいる。
どうしてもソーシャルゲーはevilに見える採算モデルで、段々改善してるとはいえ、evilな部分ばかり報道されてきているから
｢ネトゲ、エロゲ、家ゲ、音ゲ、etcの何が楽しいのかわからない｣（趣味の相違。野球の面白さがわからない、等と同じ）
｢ソーシャルゲーになんでお金つぎ込めるのかわからない｣（価値観への疑問、親しい人であれば不安、嫌悪）
ってなりやすいとは思うが。
これをさ、｢競馬になんでお金つぎ込めるのかわからない｣に置き換えてみよう。そしたら、｢いやいや。馬が面白いんだよ。それにせいぜい使っても重賞で数千円だよ｣とか｢馬券は100円でも買えるし、馬券買わなくても馬がわかると十分面白いよ｣とか｢競馬に関わる人たちのストーリーがね｣とか、色々説明しようが思い浮かぶんだけど、ソーシャルゲーならどう説明すんの？それが上手く出来ればソーシャルゲーのevilな課金モデルというイメージで嫌ってるゲーマー層の理解を得られるかも。
さんざん叩かれてるんで「見積もり金額がバラバラなんていう非常識な事態」が起きる最大の原因は「発注者が素人すぎて、発注内容が何を買いたいのかも良く分からない中身、なんていう非常識な事態」だから、ということは理解出来たと思う。
とはいえ素人が一朝一夕に発注仕様をまとめるなんて無理。どうしてもその業務が投げ出せないなら
1.その手の予約システムはweb上にくさるほどある。片っ端からアクセスして予約して使ってみる。
2.そのシステムで予約やらキャンセルやら、その他色々な機能を使ってみる。
3.最後はキャンセルしてばっくれろｗ キャンセル料くらいは勉強代とあきらめて自腹でｗ
4.自社のやりたい業務内容に近く、備えてる機能に不足がないシステムが見つかるまで１－３を繰り返す。
5.「実はこんな感じのシステムが欲しいんです」でURLつけて各業者に再見積もり依頼。最低限それに会場数やら頻度やら分かってる全ての数字はつける。
6.こんな依頼の仕方をしたら逃げる所や、リスクを積んで一気に数倍値上げしてくる所が出るだろうが、それが正当なので諦めれ。
7.実システムを例にした所で、しょせんユーザーサイドからいじって判る部分だけだと業者が見積もりにあたって想定したシステム機能は主にバックエンド関連で漏れ落ちだらけのはず。
そのままの金額で作ろうとすると、仕様変更で金が膨らんで後で上に怒られる（もしくは使い物にならないシステムできあがり）のは目に見えてるので、まずは出てきた見積もりの倍くらいの予算感と考えるといい。
8.見積もりで真ん中高めくらいの所を数社呼んで話を聞く。一番仕様の相談に親身になってくれそうなところを選定。
9.選んだ所にぶっちゃけて、リスク積んだ高めの見積もりを出して貰って、それで契約。
10.上には選定経緯や価格の妥当性を追求されるだろうがなんとかしろ。気の利いた業者だと他社の相見積もりくらい用意してくれることもある。
11.実際に仕様を決めるのは価格交渉しながら、とか契約が済んだ後から本格的に・・・という話になるが、わりとそういう業界なので気にしなくて良い。
9.でぶっちゃけてついてくる業者なら、最低赤字にならん数字は出してるはずなんで少々の仕様不備や決定遅れに対する無理は利くはず。
12.拡張性とメンテ頻度は案外費用に大きく利くし、業者側も想像がつきにくい所だから、その辺は自社の担当部門と良く話し合っておけ。
13.業者に仕様書を突きつけられても良く分からないのが関の山。仕様書は仕様書として実際の機能についてはユーザー画面と運用サイドの画面遷移ベースで話し合って合意しておくのがたぶん一番両者間の誤解が少ない。
随分業者に有利な選定方法に見えるかもしれんが、素人が発注して失敗しないようにするなら「これは儲けられそう」と思わせて業者を味方にするしかない。
Flashで作るかFlexで作るかの違いだと、レイヤーやムービークリップの概念とか共通だから問題無いぞ？
C99とANCI以前のCとか、ものすごい違うのだが？
昔からメンテしてるコードだと、コンパイラに「古い組み方です」的なwarning吐きまくられたりするし。
というか、CPUのbit数が違うだけで別物になる処理系だしな。
たまたまActionScriptが差すものの範囲が小さいから、混同されがちだが、ActionScriptはあくまで言語であって、ActionScriptが呼んでいるFlashのライブラリとは別物という解釈。
JavascriptだってDOM使わない独自拡張製品もいくつかでてるしな。かならずしもブラウザでDOMがなければJSというわけでもあるまい。
それだと、Flashで作るかFlexで作るかの違いについてお前が語るのはおかしくね？
まぁ、そう拡大解釈しても、
とかは依然あるわけだがなー。
追記: トラバ間違えた。
それを言い始めると Flashで作るかFlexで作るかでActionScriptも随分違ってくると思うけどな。
C（C++）言語だってWin32なのかMFCなのか,Linuxなのか、Macなのかでライブラリが違って大きく違うがC言語はC言語だ。
たまたまActionScriptが差すものの範囲が小さいから、混同されがちだが、ActionScriptはあくまで言語であって、ActionScriptが呼んでいるFlashのライブラリとは別物という解釈。
JavascriptだってDOM使わない独自拡張製品もいくつかでてるしな。かならずしもブラウザでDOMがなければJSというわけでもあるまい。
つーか、日銀のシステム使えば国庫金としてわりとカンタンに整理つけられると思うんだが。
それやらないってことは、これ休眠口座のカネを活用っつーよりは、ポジション作りの方が重要なんだろうな。
元日銀マンの俺が言うけど、普通に日銀ネットでやれるよこの程度のこと。
休眠口座のカネを一回日銀（＝国庫金）にブチ込んで、預金者からの申し立てがあったときは
銀行が日銀に申し立てるってことでフツーにクリアできる。だって、銀行預金と日銀はツーカーなんだから。
預金口座の管理業務なんて日銀の支店にやらせりゃよろしい。確かに結構コストはかかるだろうけど、
国庫金システム専門家揃いの日銀マンが新しくシステム組めば、たぶん確実に一番安くやれる。だって、既存のを拡張するだけだし。
つーか、国庫金として計上するならどの道日銀に入れるしかないのに、その間に基金とか意味不明。
全く必要ない組織作ろうとしてるぞこれ。
基本、元増田のおっしゃってることは正しい。
ただ、国庫金に帰属させた後でも申し立てに対して返金することは可能。そんな難しくないんだよ。預金者保護まで日銀でやれる。
確実に日銀にブン投げりゃ格安でやれる仕事だよこれ。思惑はこれ、「休眠口座のカネの活用」じゃないよ。
単なる天下りポジション作りだと思うわ。何のための日銀ネットだよ、使えよ馬鹿。
まぁ、最近インタゲ打ち出したりしていろいろ大変なんだろーけどさ。システム使わないのは勿体ないだろ。
普通にあるけど？
たとえばPS3の週刊トロステーションでは、トロとクロのいつもの掛け合いにTwitterでコメント付けられる。
Twitterと連動！ 『週刊トロ・ステーション』PS3向け機能拡張アップデートが本日実施
Twitter連動機能
「トロ･ステーション」の視聴時にユーザーのTwitterアカウントを使用し、ツイートすることが可能です。また、他「トロ・ステーション」でニュースの進行に合わせた他のユーザーのツイート内容を閲覧することが可能です。
というかクロが『それってニコ…』と言いかけてひっぱたかれてた。あとPSVITAの「みんなといっしょ」にもTwitter連携機能がある。
ガチでメーラとWordとExcel,パワポ（しかも2003（笑））、teraterm、FFFTP位しかつかわねーからさ
あいつら本気でXP(笑）、メモリ1GBで足りてるとか思ってるからタチがわりーわ。
・コードがかける若手SE（笑）がEclipseとかMySQL、Oracle,Chrome,Firefox,IE,Java,.netと使うからある程度スペックが欲しい。(と言っても今時の５万で買える普通スペックで良い。。）
↓
・若手が新しいPC寄越せと要求
↓
・年食ったコードがかけないSE（笑）はOffice2003（笑）位しか使わないし、めんどくさいから要らないと抜かす
↓
・先輩がいいって言ってるのにお前らが要求するのか？とか言って取り合わない。
↓
・ほんとに必要な最前線の若手にまともなPCが行かない、その結果朝にパソコン起動してメーラとEclipseが起動するのに１５分かかる環境の出来上がりｗｗｗ
一方部課長以上の役職には全員Androidタブレットが支給され
お飾り部長には組織移行都度に新PCが卸される（結局何してるかもしらんがｗOfficeとIEしかつかわねーくせによｗｗｗ）
そりゃ社員がセットアップするし、何も入ってねぇから環境移行もし易いもんなｗｗ
もちろんAndroidタブレットはメール確認するくらいにしか使わないｗｗｗ
iPadやAndroidタブレットのブラウザ、メールをちょこっと触った位で最新になったと思い込むめでたい老害達。
そのHTML5とサーバサイドの開発するのは俺たち若手SEなんだがなｗｗｗｗ
でも結局使わないし飽きて部長のタブレットは机の中に入れっぱかおきっぱ。
クラウドクラウド、SalesforcrSalesforce
クソウォーターフォール維持しながらスピード感がとか寝言ぬかしてんじゃねーぞｗｗヴォケが。
上の承認が～承認が～って要件定義が～ってお前らクソ共の承認があってスピードも何もねぇだろうがｗｗｗ
その上テストドリブンしようとすると、要件が固まってないだろ！とか抜かすし、殺すぞ。
結果アホ共が思いつきで言い放った言葉は忘れない
SalesForceのパンフレットに開発は１月を目処に実装する、みたいな文言を間に受けて
え？じゃあ、プロトタイピングとかテストドリブン型とかでやるの？とか聞くと、
いや、客の要件をしっかり聞いて要件をしっかり洗い出して～上司の承認をしっかりと得て手戻りがないように～とか抜かすｗｗｗｗｗｗ
おい、お前それ今までとかわらねーじゃねーかｗｗｗｗｗ
あーいうのは少人数チームで全員が開発者としてプログラムが十二分に書けて仕様書とかの書類を最低限にして
要件定義や決定権限の大部分を現場に委任して優先順位の高い項目からを集中してやるから出来るのであって
日本のほとんどのアホSI企業の典型的なコードの書けないExcel書くだけの御用聞きSE（笑）なんて邪魔以外の何者でもないｗｗｗ
そんなゴミSE（笑）が多くを占める会社で出来る事じゃねーんだよｗｗｗｗ
あーいうゴミ共は居るだけでどーでもいい好みでの文句をグダグダいうから余計に作業が遅くなるｗｗｗ
こういうクソみたいなことばっかりやってるから古い日本企業はダメなんだよ、ゴミどもが、さっさと潰れろ。
そして俺はクソSI業界を見限ってソーシャルゲーム業界に転職準備をしているのであった（完）
http://anond.hatelabo.jp/20120207005408
まなめはうす恐るべし
ちなみに私のPCのスペックはPen4 1.6Ghz メモリ1GB HDD 30GBです。
これでメインはJavaのStruts2とSpring Eclipse3.7で組んでます。
これより低い奴出てこいや…
とりあえず一部間違えていたので訂正ｗｗｗ
１．HDDは37GBでした。ごめんなさい、実際に見てみたら間違えてました。でもいつもSVNチェックアウトするときとかデカイzipを落とす時はいつも何か消してからしています。
２．ケースはチェーンで鍵がかけられているので開けられません(^p^)よって自分での拡張は不可
後、時々あった。
PGなんてのはゴミがやる仕事だからそんなの気にかける方がゴミ
とか
とか
コードを書かなきゃいけない時点で大手ではない
ちなみにT○SとかI○M、NT○の人もコード普通に書いてたよ。
ってか書くとこは書くでしょｗｗ
んで上みたいな考えの人はそれで構わないでしょう。
そうやって思っててコードやプログラム部分なんてどうでもいい。
フロントエンドやバックエンドが発達しても設計書レベルや提案レベルに落としこむ場合に実コードの知識なんて影響しない思うならそれでどうぞって感じ
いつまでも何でもバッチ処理（笑）にこだわる人も良くいますしねｗｗｗｗ
私からしたらいつまでコードの書けないSE（笑）が成り立つか逆に聞きたい位ｗｗｗ
ま～コードがかけないSE（笑）からいつも馬鹿にされてるのを知ってるから、コードがかけるSE（笑）はどんどん逃げてっているんですよね～
わざわざプログラム（笑）とか馬鹿にされてまで居るものじゃねーよｗｗｗ
現在どんどんSI業界から出来る人が率先して辞めてるからｗｗｗ
ただでさえ人材不足のクソSI業界にいつ影響が表面化するか（もうしてるか？）楽しみですNE!
私は先に役に立たない大量の船頭しかいない泥船から抜け出しますｗｗｗ
戻って来ることもないでしょう！多分！
それではアデュー！
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 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
昨年の大晦日に一方的にシフトを週一にされ（事実上の解雇韓国）
更に別のスタッフに逐一業務内容を報告させ（嗅ぎ回らせて
「意図的に指示を聞かず、陳列の間違いがすべてわたしのせいである」
という様に「解雇事由」になるよう工作するようなところだ。
内容はこちらのやることなすことを否定することで、
「その時こう考えた」ということは「言い訳」と一蹴され
「いや俺らが沿う感じなるなど。
何かを説明していても
「ていうか５分１０分でコロコロ考え変わるよねｗｗｗｗｗｗｗｗｗｗｗｗ」
という揚げ足取りで全く話にならない。
「仕事ができないってことでお前解雇することも出来んだよｗｗｗｗｗｗｗｗ」
といっても
「俺らがそう感じてるからお前は仕事できないしやる気もないのｗｗｗわかる？」
てかなんで期間中にそうしなかったの？うちの店長オオバカだろ。人見る目ないだろ。馬鹿なの？死ぬの？セリアなの？
ぶっちゃけ客として利用していた時から店員は無愛想だし唯一の取り柄は品揃えだと思ってましたから。
ついでにいうとGET店は何度か行きましたけどごちゃごちゃしてて１０分で帰りたくなるような店だった。
ぶっちゃけ「セリア」だなんて気づきもしなかったよ。だっていて楽しくないんだもんｗｗｗｗｗｗｗ
まあそういうとこの店長さんだから、気に入らない従業員はそういうふうに圧力かけてやめさせてきたんだろう。
というか、セリアは全店、そういう店なんだろう。
まあ貴重な言質はとれた。まあ気分で従業員のシフトを減らす店だと判明したので、改善は期待しないが、揉め事起こして辞めてやる。
「つなぎでもいいんだよ？ｗ給料高かったら店長もそっち行くしｗｗｗ」
昨年の大晦日に一方的にシフトを週一にされ（事実上の解雇韓国）
更に別のスタッフに逐一業務内容を報告させ（嗅ぎ回らせて
「意図的に指示を聞かず、陳列の間違いがすべてわたしのせいである」
という様に「解雇事由」になるよう工作するようなところだ。
内容はこちらのやることなすことを否定することで、
「その時こう考えた」ということは「言い訳」と一蹴され
「いや俺らが沿う感じなるなど。
何かを説明していても
「ていうか５分１０分でコロコロ考え変わるよねｗｗｗｗｗｗｗｗｗｗｗｗ」
という揚げ足取りで全く話にならない。
「仕事ができないってことでお前解雇することも出来んだよｗｗｗｗｗｗｗｗ」
といっても
「俺らがそう感じてるからお前は仕事できないしやる気もないのｗｗｗわかる？」
てかなんで期間中にそうしなかったの？うちの店長オオバカだろ。人見る目ないだろ。馬鹿なの？死ぬの？セリアなの？
ぶっちゃけ客として利用していた時から店員は無愛想だし唯一の取り柄は品揃えだと思ってましたから。
ついでにいうとGET店は何度か行きましたけどごちゃごちゃしてて１０分で帰りたくなるような店だった。
ぶっちゃけ「セリア」だなんて気づきもしなかったよ。だっていて楽しくないんだもんｗｗｗｗｗｗｗ
まあそういうとこの店長さんだから、気に入らない従業員はそういうふうに圧力かけてやめさせてきたんだろう。
というか、セリアは全店、そういう店なんだろう。
まあ貴重な言質はとれた。まあ気分で従業員のシフトを減らす店だと判明したので、改善は期待しないが、揉め事起こして辞めてやる。
「つなぎでもいいんだよ？ｗ給料高かったら店長もそっち行くしｗｗｗ」
昨年の大晦日に一方的にシフトを週一にされ（事実上の解雇韓国）
更に別のスタッフに逐一業務内容を報告させ（嗅ぎ回らせて
「意図的に指示を聞かず、陳列の間違いがすべてわたしのせいである」
という様に「解雇事由」になるよう工作するようなところだ。
内容はこちらのやることなすことを否定することで、
「その時こう考えた」ということは「言い訳」と一蹴され
「いや俺らが沿う感じなるなど。
何かを説明していても
「ていうか５分１０分でコロコロ考え変わるよねｗｗｗｗｗｗｗｗｗｗｗｗ」
という揚げ足取りで全く話にならない。
「仕事ができないってことでお前解雇することも出来んだよｗｗｗｗｗｗｗｗ」
といっても
「俺らがそう感じてるからお前は仕事できないしやる気もないのｗｗｗわかる？」
てかなんで期間中にそうしなかったの？うちの店長オオバカだろ。人見る目ないだろ。馬鹿なの？死ぬの？セリアなの？
ぶっちゃけ客として利用していた時から店員は無愛想だし唯一の取り柄は品揃えだと思ってましたから。
ついでにいうとGET店は何度か行きましたけどごちゃごちゃしてて１０分で帰りたくなるような店だった。
ぶっちゃけ「セリア」だなんて気づきもしなかったよ。だっていて楽しくないんだもんｗｗｗｗｗｗｗ
まあそういうとこの店長さんだから、気に入らない従業員はそういうふうに圧力かけてやめさせてきたんだろう。
というか、セリアは全店、そういう店なんだろう。
まあ貴重な言質はとれた。まあ気分で従業員のシフトを減らす店だと判明したので、改善は期待しないが、揉め事起こして辞めてやる。
「つなぎでもいいんだよ」
不景気の折、働いている会社や仕事が無くなった場合のことを考えた。
高校を卒業して、無意味で無駄な専門学校を出て、10年間ぐらい働いた。
税金をたくさん取られるので、想像していたほど金持ちにはならなかった。
中小企業の特徴かもしれないが、10年続けて働くと、古い人も新しい人も
含めて、8割ぐらいの人が入れ替わる。
上からの命令は何でも引き受け、仕事で潰れなければ、自然と出世する。
でも中小で10年も続く会社は、少ないため運が良かったのだと思う。
不景気にさらに災害に世界的不況も加わり、大手企業もつぶれる時代になった。
今までは考えたことが無かったが、自分も仕事を失ったどうなるのか、
最近考えるようになった。
現実的には、類似同業者への転職か、社内のメンバーで類似事業の立ち上げ
があり、そこで働く可能性が高いと思う。
現在の水準の給与も見込めないであろうし、類似事業同業である以上、市場の
先行きは明るいものではない。
ではまったく別の新天地を求めると考えると、果たして自分の10年間で得た能力
は、外に通用するものか、内部だけで通用する能力なのか、検討がつかない。
何とかなりそうな気もするが、年齢もフレッシュではなく、特定の資格もない。
経験もあり、仕事ができているのは、今の会社があり、その中でのノウハウが
外に出たら、只の小さいおじさんかもしれない。
そんなことも考えつつ、本を読んだり、ソーシャルを始めてみたり、学校にも
通って見たりした。それだけの目的でないのだが。
はっきり言って、どれも問題を解決できる何かが見つかる可能性は感じなかった。
見つける人もいるんだろうけど、自分には合わなかった。
哲学（自己啓発）やハウツー本は、著者自身の自己啓発（自分自身に言い聞かせ
ている）だったり、ハウツー本は一見良いけど、志が伴わないものは、頓挫する。
他人の上っ面だけ借りても意味が無い。
ソーシャルで著名人や有名人とつながり、未来の可能性もなんて、まず自分に相応
の価値がなければ可能性もなく、同じケツの穴のムジナ同士が、ごちゃごちゃして
いるようにしか感じない。意味が無い人には、意味が無い人しか集まらない。
学校で勉強する知識など、仕事では弱すぎて使えない。それなら仕事で実践で
導入して使ったほうが、ずっと経験値になる。
より生きるように、本は良質だと思った定番のビジネス本を繰り返し読み、
行うことは志となる土台や社会的正義などスジとなる、主張を持つようにしている。
ソーシャルや学校で勉強したことは、事業に入れ、業務の拡張につかっている。
そうこうしている内に、話は戻ってしまって、結局は今の仕事だけになっている。
だから、もし今の仕事が無くなったら、台湾に移り住み中国語を覚えようと
考えている。親戚もいる。
そうすれば、実態もわからないし結論も出ない悩みの種となっている、
次の仕事は、同業種の仕事か、他業種の仕事にするべきか考えずに済む。
台湾で中国語を覚えられるまでバカンスしてすごそうと、今は楽しみしている。
現実逃避とも言うが、現実進行も現実逃避も、人より飛び越えたほうが
得てして良い結果が出る。マイノリティーとも言える。
Webサービスになるんじゃないかなーってことを思いついたので、自力で作ってみよう思う。
プログラマとして社会人約三年経験後、無職半年目。別業界に行こうと思ってた。
でも思いついたからやってみるって言うのは有りだと思うんだ。
機能拡張とかばっかりだったから、どうしていいのかいまいちわかってない。
・レンタルサーバを借りる
・余裕があればドメイン取得
・開発言語はPHP（とはいえ独自フレームワークばっかりだったのでCakeとか使えないぞ……）
・MySQL実は使ったことがないんだよな。関数をチェックしておく必要性あり。
・UIはHTML5を意識したXHTMLで書いておけば将来的な移行がしやすいのかな。最初からHTML5で書くというのも手か？
・CSS3使ってもいいのかなあ
・関連商品の表示のために何をすればいいのか（DBに閲覧履歴を保持するのか？）
・他にも思いつき次第追記
・ここがわからないのであった
・twitterとかなのかな
まあ、作れないかもしれないけど、その時はその時。
FuelPHP Advent Calendar 2011 の 15日目。
FuelPHP の URL とコントローラの関係から続いて寄稿します。
早速ですが本題。
といって、そもそもの経緯を先に。
fuelphpを試そう！ってなもんで既存のサーバでPHP5.3にしよう〜という所が発端。
既にyumでPHP5.2ベースで環境が構築してあったせいで、色々とconflictしてインストールに手間取る。。。
案外、環境構築ってはまると手間よねーといった意味合いも込めて、
今後の参考迄に割とストレートにいける様にセットアップ手順をログります。
今回はせっかくなので、色々と最新パッケを用意します。
なので、fuelphpを動作させるために、今回は最新のRPMパッケからPHP5.3をインスコ。
$ sudo rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
$ sudo rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-5.rpm
(PHPを先にインストールすると色々こけるので先にmysqlをセットアップ)
で起動テスト。
いや、こけた。
起動せず。。
ふむ。repositoryをremi-testにしなければダメな模様。
再度インストールの場合には依存関係のパッケージでconflictするのでとにかく消す。
ごっそり消す！！
でインストール。
$ sudo yum --enablerepo=remi-test install mysql mysql-server
$ sudo /etc/init.d/mysqld start
Starting MySQL: [ OK ]
いった！
自動起動設定だけ済ませて次へ。
既存のphp5.2以前がある場合は、やはりとにかく、ごっそりremove！！
で以下に続く。
$ sudo yum --enablerepo=remi install -y php php-mysql php-xml php-mbstring php-common
ほんとはハマった辺りのログとかも入れた方がいいんでしょうが、今回はこれでご勘弁。
ソースから入れた方が楽だよなぁ・・・と何度か方向転換しかかりましたが・・・なんとか。
明日16日目は@madmamorさんの「FuelPHPのcoreクラスを拡張してみる。」ですね！
おたのしみに！
第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 練習問題
思うんだけど
弱者は死ね（強者の意志のような言い方） という話と 弱者は淘汰されて死んでしまう（自然現象）
という２つの話があって、
弱者は淘汰されて死んでしまう（自然現象） という当たり前の話なのに （今でも世界には餓死する人が普通にいる）
なんで、強者が弱者を守らないと弱者は死んでしまう。どうして、強者は弱者を守らないんだ？横暴だ！
という話になるんだろう。
常識的に考えれば、このままでは弱者の我々は競争に負けて死んでしまう。
競争に負けない程度強くなるためには、これこれこういう事業拡張が必要で、これだけの投資が必要だ。
だから、国は農業にこういう投資をして 産業を改革し、弱者が死なない程度の強者になれるようにすべきだ。
という妥当な話に なんで ならないんだろう。
ここにも、そこの内部の人とか、使ってて変な使い方してる人とかいるかもしれないけど
技術的にはまともなのかな
しかし、ラベリングにさえならない、妄想なのか想像なのか意味不明で、やり取りらしいやり取りもしてない、病院いけなんて話になってもない、こっちがＵＬＯＧ内でブロックした人に
延々と、掲示板を作られて、私の「精神病」「精神障害」「何らかの精神的な障害の疑い」 を心配し
居住権や人権についての概念の理解が皆無で、「立ち退きを命令」できると思っていて
人のブログやサイトは全く読まず、すぐに読めるものも読んでおらず
google earth以外では無いもう終わった工事をさも人に聞いたように、嘘をしれしれと書いていて、不気味に益々拍車をかけて何かを醸し出していた。みたいな・・・・・・・・・・
この人に全く相談した覚えも何か頼んだ覚えも何も無いし、そもそも全然交流ない
ここまで変な人とは思わなかったけど、コミュニケーションが取り辛かったので、ブロックにしただけで、ほとんど知らない人なのに
なぜ、こんなにあつかましくてずうずうしくてどうしようもないのか
例えば、私のブログを名古屋の公的機関へのメール相談で紹介し、＞時間に余裕がありましたら、その方が運営してるブログを読んで状況を把握してください。（ただし、大変読みにくく、解析に時間がかかります。）
参考URL http://d.hatena.ne.jp/oooquree/about
身内でもない頼んだわけでも相談したわけでもなく、事情を知ろうともせず ブログ読みもせず それでいて、違っていると言えば、ツイッタで話そうとしたり、チャットしようと書いたりしてくる
なんでチャットしなきゃいけないのか?????????？？？？？？？？？？？？？？？？
おかしい
魚拓は元を消すと取れない が ブラウザに残ってたのをコピペした増田と画像保存したもの
http://megalodon.jp/2011-1101-0217-03/ulog.cc/xa/sakura/oooquree/8320 魚拓です。
ulogは魚拓も消えてしまうらしい。魚拓の画像http://kie.nu/1yo http://kie.nu/1yp http://kie.nu/1yq http://kie.nu/1yr http://kie.nu/1ys
ログは増田に保存した http://anond.hatelabo.jp/20111101104747
http://togetter.com/li/208070 http://backupurl.com/uprs1n ←保存用 左のが見られない時に
人が少ないから風通しが悪くなるのかな？と思うけど、見られてるページは見られてるみたいで、人気ある人もいるみたいだけど、その人も、私の事で勝手に掲示板を作って、頭がおかしい事にして、事実無根なもうとっくに追ってる道路拡張工事を、今起こっている事のように、でっち上げ、立ち退き命令が出ているのに居座ってるとかいう掲示板を作っている人に、そこへ誘導する文を載せてるところに、「読んだ」「いいね」と入れてたりした。。。。。
もう少し冷静な人かと思った。
普通の感覚を持った人なら、ラベリングと言い出さなくても、レッテル貼りと言い出さなくても、エスパーじゃあるまいし、「精神病」「精神障害」「病院に行きたがらない」など全然やり取りしてないのに、わかるわけがないし
病院については、私はそれを取り巻く状況をもっと詳しく書いたりもしていたし・・・・・
思ったのは、そのエスパーの人はともかく、考え深そうな人にとっては、タブーな世界だったのかなあということ
エスパーの人は、タブーと言うより、穴があったら突っ込みたい、自分より弱そうだったら付け入りたい みたいなもんなんだろう
エスパーなのは、主観と客観の区別がきちんと付いてないので、私よりもそっち系に近いような気がする
http://anond.hatelabo.jp/20111101104747
何かを訴えてる人のを改変して、伝える悪趣味な遊びがあるのかもしれないけど
そういうことしたがる心理って、よっぽど普段相手にされてないからではないか？
ここでも、妙に注目されてる
http://backupurl.com/pmovg1 (http://togetter.com/id/twittの保存用)
18 hours ago · reply · retweet · favorite
こっちが、家主は転売目的の不動産業者と書いて調停の申立書の文面まで載せてるのに、いったいどこから「「「道路拡張工事の立ち退き命令が出ている所に住んでいる」」」という妄想が出てくるのか理解できない。
うちの親も年末に突然来て、これが鍵施錠してアパート半壊させた業者に協力して、警察が電話で話した時も鍵を持って来なかったけど、内容証明を出した弁護士には、電話でどれだけ私に愛情があるかを説くと弁護士に言われ大変ショックを受けたけど、Ulogでこっちがブロックしてるのに、相談に乗りたがり勝手に精神病にして名古屋の公的機関に対象もわからないのに相談したり問い合わせしたりする異様な行動力って・・・・・・
狂ってるのか、狂ったふりをしているのかわからない (これは私が親について区役所で言った言葉だが) id:Naruhodiusにもあてはまる
このあいだ精神科医をツイッタで名乗る英国育ち二重国籍の人が、カナダ育ちの英語の先生に英語力の怪しさを指摘され、自滅してた、という事があった。ちょうど自分がその医者に話しかけられて自分も怪しいと思った時に知った。医者のフォロワがいないのも指摘されてた。そんなんでも数百のフォロワが付く。
わざわざブロックしてる人の相談に乗りたがるのって、狂ってるだろ？
ＵＬＯＧでブロックして終わったと思ってたのに(その時はギークハウス関係者と知らなかった)
ブロックされて嫌がられている人の相談に乗ろうとしたり、関わろうとする理由が、精神病だからって・・・・・・
お前が精神病やろ？？？
って話じゃね？ｗｗｗ
ulogは魚拓取らさないようにしてあるようだ。取れなかったので画像にしたが、ここも保存リンク用
画像はこれ http://kie.nu/1yo http://kie.nu/1yp http://kie.nu/1yq http://kie.nu/1yr http://kie.nu/1ys
Ulogで、ほんの少しやり取りした時は、ギークハウス関係者とは知らなかった。
人を精神病認定しつつ、チャットしたがる心理って、一体どういう心理なんだろう？ それこそ正気を疑ってしまう。
http://togetter.com/li/208070 見られない時は保存用→ http://backupurl.com/uprs1n
この人が書いている道路拡張工事は、とっくに終わっている。 人に聞いたように書いているが、「「嘘」」だと思う。 google earth や map の画像がまだ工事中だからではないか？ 人に聞いたらわかる事なのに。。。 こんな風に平気で、嘘や思い付きを確定した事実のように語っている。
失敗例です。何かしたいと考えている方の参考になれば（良い案あれば教えて下さい）。
既に福祉医療法律の知識がある方にとっては失笑モノかもしれませんがなんで黙って見てるんですか＞＜
病院いけといっても行かない方をどうにかする施設は、無料法律相談所への連絡では見つからなかった。これがあれば解決すると思うのですが。。
目次
・感想（何の足しにもならないよ）
AtoMa
Re:する
精神障害者であることを前提に調べた。無料法律相談所へ連絡した。
■やったこと
・現地の人にネットで話して現場付近の事情を聞いた。無料法律相談所へのメールして対応することになる機関特定した。
■結論になる選択肢
・今、障害者手帳などをお持ちの場合、障害者世帯向公営住宅入居斡旋の制度があるので、瑞穂区役所で相談する。
・お持ちでない場合、まずは病院で診断を受けて下さい。病院のソーシャルワーカーさんに相談してみてはどうでしょう。
AtoMa
Re:する
名古屋市精神保健福祉センターに話を聞いた時の内容まとめ
目次に入れ忘れた。。
■名古屋市精神保健福祉センターに話を聞いた時の内容まとめ（録音はしてないです）
・保健所では診断を受けることはできないので第一にこちらに来られても、手帳がない場合は何も出来ない。
・何かの福祉的援助受けるには手帳が必要。病院で診断受けて下さい。
AtoMa
Re:する
■背景：現在瑞穂区では、道路拡張工事を行なっておりそのために立ち退きを命じられている人が居る（らしい・現地の人に聞いた話です）
■困っている人：その立ち退きを命じられている人で、何らかの障害を患っている疑いがあり、うまく対処できず不安があるようでインターネットで助けを求めている
■相談者（私）：困っている人の話を聴いたので、対応できる公的機関などを探して連絡しようとしている。
私が、困っている人の話しをざっと聴いて、さらに現地の人の話しを伺って事実関係のあるところの確認（工事していること）と、通常の対応はどうなるかを調べましたが素人ができることにも限界があると思いますので、あとは専門家の力をお借りしたいと思い相談します。
住宅の立ち退きを受けた場合は、親族などに連絡して済めば良いと思いますが、困っている人は嫌がって、立ち退かなければならないアパートに居座っている様子です。
現在、困っている人はここ数ヶ月に起こった立退き関係や、家族との関係に満足が行かない様子でインターネットに情報を載せて、あっちこっちで助けを求める活動をしています。
時間に余裕がありましたら、その方が運営してるブログを読んで状況を把握してください。（ただし、大変読みにくく、解析に時間がかかります。）
参考URL http://d.hatena.ne.jp/oooquree/about
■わたしが考える対処の流れ（素人がひねり出したものですので、最適ルートの最検討をお願いしたいです。。）
１）統合失調などの疑いがある人を説得するような専門のNPOなどがあれば、そこに要請し、困っている人に精神病を患ってることの診断書を受け取るよう説得する。
２）診断書があれば、家を失った場合でも入ることができる施設がある？（すみませんがそこまでは調べていません）と思われるので丁寧に誘導する。
困っている方が早く安心できて、インターネットで迷惑書き込みを続けるのをやめる一番良い方法を探しています。
対応すべき期限などの詳しい情報までは分かりません。相談者の私はどこを調べればよいのか分からないので、できれば専門家の方に対処をお願いしたいと思う次第です。
AtoMa
Re:する
この度は、「名古屋おしえてダイヤル」にお問合せいただき、ありがとうございます。
以下の通り、回答をさせていただきます。
精神障害者の方を対象とした関係施設には、
社会福祉法人や医療法人等の設置する施設に入所又は通所し、社会復帰に向け各種の訓練を行っている施設、
地域社会において自立した生活を営むための居住の場を提供し、世話人が日常生活における援助を行っている精神障害者のグループホームなどあります。
また、市営住宅家賃・敷金の減額の制度や障害者世帯向公営住宅入居斡旋の制度などがあります。
お問い合わせのメールによりますと、「統合失調などの疑いがある人」と記載されていますが、まずは、お住まいの区の瑞穂保健所または精神保健福祉センターにご相談ください。
○各区の保健所において、週1回、予約制にて精神科嘱託医による精神保健福祉相談日を設けています。
また、随時、精神保健福祉相談員、保健師等が相談・訪問指導を行っています。
○精神保健福祉センターここらぼにおいて、予約制にて思春期の精神保健相談、ひきこもり相談、高齢期の心の健康相談、薬物リハビリテーション相談、自死遺族相談などをはじめとする精神保健福祉相談を行っています。
相談日の日時などについての詳細は、瑞穂保健所または精神保健福祉センターへ直接お問合せください。
≪ 問合せ先≫
【瑞穂区保健所保健予防課保健感染症係】電話番号 **********
【名古屋市精神保健福祉センターここらぼ相談援助係】電話番号 **********)
問合せ応対時間は、土・日・祝及び12月29日～1月3日を除く、午前8時45分から午後5時15分まで
※プライバシー保護の観点から電子メールによる相談は受付けておりません。
またのご利用をお待ち致しております。
AtoMa
Re:する
感想（何の足しにもならないよ）
わたしにあらゆるルートあたる力は無いので、今できることはここまでです。
あとはどうなるのか？病院行きは嫌がっているようなので、後は強制退去待ち？不明。誰か教えて！
長文メディア上では、説得には逃げ道を用意しない・意味をその都度確認できる環境などの条件が最低限整わないとと思うので、説得は無理と素人でも思いました。
他この件で、わたしがひと通りやった路線で調べようとしてる人を見かけたら、ここの内容を提示すると良いかもしれません。
以上です。違う路線で調べる力をお持ちの方の意見あれば聴いてみたいです。
わたしは名誉毀損っぽい発言受けたしそれを活用できる案でもあったら使って下さい（ただしわたしが損する案はいやだ）。
渦中の人には関わりたくないけど私へは文句言えるみたいな人とかも書き込んだって下さい誰かの参考になるかも。
わたしは福祉系医療系法律系の知識が薄いので言いたい放題できるでしょう。
あとこれ最後に
わたしの立場はボランティアです。そこのところよろしく。この件でこれ以上何ができるか検討付きませんし一生懸命調べる余裕無いです。
掲示板くらいは作れるので必要になったら呼んで下さいな程度です。ここもだいぶ前作った階層型掲示板が使えると思って活用してるだけです。
以上です。
AtoMa
Re:する
© AtoMa製 TreeBBS Ver0.2.2
