  |
はてなキーワード: 疎結合とは
Manycoreという技術そのものはIntelもだしてる。さらなるManyはGPGPUでやってる。
他方シングルコア性能は上がってはいるが４Gぐらいで、議論を呼んでる。
今議論を読んでいるのは、コンパイラの最適化と、マイクロコードの最適化
そこはかなり疎結合だからな。インタプリタで言うエンジンの最適化ではないが
CPUでどう最適化されるか？をインタプリタがもうすこし制御すればインタプリタのスクリプトコードをもう少し効率的な生成にできるのではないか？というアプローチがJava的ではなくPython的にあらわれはじめていて、けっこう、興味深い
デフォルトのPythonとコーダーが機械語の変換について学習させてあるPythonという考え方はとてもポケモン的で面白い
Railsを使うと、初速は早くなる。それは間違いないと思う。一方で、RailsはVierwからDBまで密結合したフレームワークなので、「段階的なアップグレード」とかがむずかしい。ヴァージョンをあげるときには一気にエイヤであげる必要が出てきがちである。さらに、プロダクトが巨大になってくると結局様々な工夫を凝らしてViewからDBまでの間を疎結合にしていくことになる。そうなってくると、「これRailsである意味あるんだっけ」となって、段階的なアップグレードのしにくさや気をぬくと密結合な設計になるという欠点が目立ってくる。
これは、まさに技術的負債そのものである。ここでわたしが「技術的負債」を「単なる悪いもの」として扱っているわけではないことに注意してほしい。Railsを使うというのは、そういう将来の負債を借り入れて、その借金を使って早くプロダクトを世の中に届けるという判断をしている、ということだ、ということを言っているのであって、「借金してでも早く出したい」という判断が合理的で正しい場合ってのは、腐るほどある。
ただ、Railsを選ぶときに、「今俺たちは借金をしているんだ」って思いながら選んでほしい。その感覚がないと、プロダクトが軌道にのったあとも借金を返すためのリソースを捻出しないまま、破綻したコードベースに消耗してプログラマがどんどん逃げて言って最後にはプロダクトが潰れて終わるので。
よく「男女がいてこらえられなくなった男が女に抜いてもらう」みたいな展開のエロ作品あるじゃん。あれ自体はまあ夢みたいなところあるし、あわよくば僕もされたいから、「現実ではありえない」みたいなツッコミをされても「現実ではない。」みたいな返しをしておけばいいけどさ。
でも、その流れで。どうしても納得のいかないが1つだけあって。
「すっきりした？」
すっきりするって何？10年来射精し続けてきて1回もすっきりなんてしたことないぞ？お前は射精を何だと思っているんだ！？
まず、他者から観測可能な結果の一つであるところの射精を目標とした一連の行動 S について考えなければならない気がするんだよな。別にこれは自分で手コキしようと他人に任意ズリさせようと何でもよくて、最終的に射精するために行う動作ならばなんでもいいんだけど。あ、話を簡単にするためにとりあえずドライは考えない方向で。
英語でシコることを jerk off というらしいので、抜く人を jerker 、 抜かれる人を jerkee とおくことにするか。一人遊びならこの2つは参照等価ってことで。さしずめ、冒頭のストーリーならば jerker !== jerkee && jerkee.sex === 'male' && jerker.sex === 'female' ってわけだ。
この場合、少なくとも jerker の目標には「jerkee を射精させること」が含まれる。「S は射精させるために行われる」という前提だけど、まあ「S が行われるならばそれは射精させるためである」でもいい……よな。射精以外の目的をもつ行動は S に含まない、にしよう。
性欲の鎮圧以外を含みうるのか、については真だろうな。「なさけない顔を見る」とか「背徳感を得る」とか、よく考えれば他の目的なんていくらでも足せるじゃんな。
……うーん。射精って jerkee が自分の身体と契約を以て行われるものではないんだよなあ。あたりまえだけど目標は叶わない可能性も十二分にあるし。
目標が叶わないといえば、男女の場合は往々にして知識が非対称だから jerker が射精させようとしてもできないってのは普通にありうるか。それはそれでかわいそうだな……。jerkee になったらいたたまれなくて泣いちゃうかもしれない。
あー。射精はコミュニケーションという説があるな。一人遊びは実際自己との深い対話だもんな。我々は精液が尿道から射出されるという非対称な現象を通じて相互理解の境地にいたることができるのか。
そんなわけねえだろ
実はこれけっこう怪しいと思っていて。というのも、枯れると文字通り枯れるから観測不能になっていくじゃん。まあ握っていればちんちんの収縮ぐらいはわかるだろうけど。
観測を以って射精を定義するならば精液が出なくなった時点でそれはもはや射精ではないということになっちゃうねこれ。言葉としては正しいと思うけど、ではドライオーガズムではない、シコってイッたが外見上何も起こらないというのはどう定義しておけばいいんだ？ vacuous ejaculation とでもしておくか。
vacuous ejaculation を認めるとこの男女間射精コミュニケーションの飽和状態ってかなり危うそうだ。 jerker の手が果てるのと jerkee の精液が果てるの、よほど jerker が虚弱貧弱でない限り後者が先だし、前者が発生するまでは continuous vacuous ejaculation が発生する。vacuous でなくとも理性を保つのは極めて困難であるからして、これは廃人まっしぐらなんじゃないのか？
これは絶対に疎だと思うね。密結合だったらちんちんに生活が支配されないじゃん。
結局「すっきりする」というのがわからない。単にたまっていたものが抜けたような感じを受けるという程度の話なのであればそれは単純で、物理的に抜けているのだから可能であると結論付けられるように思える。
しかし、しかしだ。「すっきり度」を時間で微分して、射精した瞬間その値が一定以上でなければ実感として「すっきりした」という感覚を得られないとしたら？絶対的に一定以上常にすっきりしている人間は、つまり「すっきりした」という感覚を一生得られないということにつながるのではないか？
同じことが「賢者タイム」という概念についても言える気がしてきたぞ。賢者になりきってしまったらちょっとやそっとの愚行では何とも思わなくんしまうんじゃん。
自分がシコりすぎて頭がおかしくなっている。そろそろ通算10000回はシコったと思うし、自分にごほうびでも買ってあげたほうがいいかもしれんなあ。
一番いい例があるぞｗ 税務計算だ。＞大規模な疎結合やらなんやら 国税庁はなぜ脱税を見抜けるかの仕組みは正に増田の言ってることじゃね。
あと多分増田は意図的に中二病的ワードを使ってるのだから一応指摘しておくが、そういうのが一番わかりやすいオカルト認定チェックポイントやからな。
あまりやりたくないけど
大規模計算
とはなんであるかを具体的に数字などを置いて説明してみてくれ。まあ、抽象的でもええぞ。
あとな、
むしろレギュレーションからこれらの発展を求められただけであって、巨大な問題を高速で解くという解法に関してはほぼ増田が言うところのgoogle式でいいはずなんやけど、認識間違ってる？
まあそれと物理エンジンの話は未知の粒子（それこそ時間を司る粒子）の存在だったりがあったりする以上今までもこれから先数十年は「それっぽい再現」にしかならんのはそうだが、それは揚げ足取りみたいなもんや。
「一番短い時間の単位で粒子は同時に一つだけ動く」ルールで一応アインシュタイン世界はエミュレーションできるんだから、それは不可能ではない（計算する時間を無視すれば）って話でSFにも近い話だから別に増田は納得しなくてもいい。本題とは関係ないしな。
いずれにしてもだな。最初Pezyへの偏見から切り出したのは事実だが、この偏見が未だ解けずにいる。増田はその知性主義というやつでなんとかこの偏見を解いてみてくれ。
嘆くだけでは、何も進まんぞ。
コンピュータのマシン語は命令文もデータも数値で表す。これは今も昔も同じ。
数値だけでは人間が管理しづらいので命令文を mov や add のようなわかり易い単語に置き換えたのがアセンブラ。
複数の処理をひとまとめで扱うサブルーチン・関数・プロシージャ・ファンクションと
いったものができた。
（カプセル化）
アプリケーションからOSの機能を呼ぶシステムコール・APIが生まれた
（ブラックボックス化）
複数のクラスやコード、データをひとまとめにするにモジュールができた。
（カプセル化）
プログラムを外部から操作するRPC、CORBA、SOAP、RMIができた。
IaaS / SaaS / PaaS を使いネット上のサービスにつないでシステムを構築する。サーバ管理不要に。
（ブラックボックス化）
（操作の簡略化）
Docker でWEB/DB/KVSなどをまとめてコマンド１つで扱えるようになった。
意味不明なものが多いし何かとケチつけないと気がすまない性格だから面倒なことを一々と
直接のユーザからの意見なら多少は変でもそのユーザが必要としてるなら納得できるし、イライラすることもない
社内でそんなことこだわったところで実際には気にされないことが多いのにだ
まだデザイナーがデザインについてこうした方がUXがいいねみたいなことをいうならわかる
専門の人の意見だし
そうでもないのに何かと文句をつけてくる
CSS すらまともに使いこなせずマージンもパディングもないような酷い作りのものしか作らないのにソッチのほうが良いという
色は red, green, yellow と標準のペイントのデフォルトカラーかよというような色を指定してくる
#fcfcfc や #0a0a0a なんて使おうものなら白と黒にしろと
max-width を指定せずに画面の端から端まであるようなものがいいという
今の時代のアプリやサービスを全く見てないのか？としか言えないようなセンスだ
自社サービスなんて手を出したらこれは酷いと話題になりそうなものだ
見た目にあまりこだわれない社内用サービスしか作ってないからと言って、その他サービスをみてる人からすれば明らかに
しかもデザインに限ったことではないがまだ序盤の時点で言っておけばいいものの完成後にいまから変えるなんて難しいのが
わかりきってるようなときになってからああしろこうしろ言い出す
先に書いたようにユーザの要望ならまだ仕方ないと言えるがなぜこんな無意味なことに付き合わなければならないのか
わりと自分が完璧主義なところもあるので作るならちゃんと作ろうとしてるんだが
こういうのを相手にしないといけないせいで結局グチャグチャになってくる
色のバランスやレイアウトを考えたところで一瞬でそのバランスが無意味になるようなことになる
プログラム側だって全然関係ないものを無理やり入れ込まないといけないようなことになることも多い
疎結合だとかグローバルをつかわないとかそういう作りやすくするためのことをしていても
それが維持できないような無茶で無意味な指示が出る
根本的に変えたり対処するためのものを作るとかすればなんとかできなくはない
過去のプロジェクトでもそういうのが多いから自分で作るのくらいは扱いやすくしたいと考えていたのだが
過去に言われたものだと速度を優先だとか言って自分で作ったものよりは遅くするなと言う
しかしながら関数は使わずコピペだわforeachなどは使わずループ変数を使って地道にやるなどメンテナンスが
できる気がしないが速度においては早いと言えるものだ
当たり前のようにグローバル変数がいっぱいあるしライブラリの使用箇所はカスタマイズするための仕組みがあるのに
便利で読みやすいような書き方だと速度的にはそれに劣る
だがわざわざそんな扱いづらいし見づらいコードは書きたくない
そんなに速度にこだわるなら勝手に一人で機械語でも書いてろよって思う
どちらか取捨選択すべきものなのに両方みたせとか無理なことを言う
ちなみに便利なライブラリは基本無駄が多い遅いものだからライブラリ頼みのベンダはクソだとか
能力がないだとか言っていた
そういえば昔先輩社員と仕事したときには変に凝ったものとか必要以上に作り込んだりはしないほうがいいとか
言っていてそれなりに手抜きでさらっと一応は動くようなものを作っていた
私はそういうやり方が嫌いだったのだが今ではこういう環境に長くいた結果仕事のものにこだわって作り込んでも無駄
ということがわかってそうなったのかなと感じた
自分でもサビ残や休日に無償出勤してまでいいものにしようと努力はしていたが謎の指摘に合わせていると
愛着もなくなってきたし後は適当に済ませてしまおうかなという気持ちだ
ちゃんとした自分なりの完璧なものを作ろうとするなら仕事ではなく趣味で作ってるツールやライブラリで
やればいいかと思う
作ったもの次第でユーザが集まる自社のウェブサービスやパッケージの商品やゲームなどは作り込む方が
良いと思うが先に値段が決まって受注して作るようなものだと最低限の要望さえ満たしていればあとは
どうでもいい
むしろ不便な方が改修依頼が来て稼げる
さらには綺麗で完璧な作りで大抵の想定できる改修は１日とかからないようなものに仕上げるよりも
どこ変えればいいかや影響範囲すらわからないくらいモノのほうが実作業時間が多いのでそれだけ請求できる
先に作り込むメリットがない
ストレスが溜まってきたので発散がてら書いてみたけど疲れてるのかわりと分かりづらい文章になった
けどまぁいいか
そろそろ転職でもしたいなーと考え始めた
師匠「プログラミングとは深淵なる神の御業（みわざ）。あらゆることを可能とし、あらゆることが不可能であると知る。」
師匠「当然だ。」
師匠「ところで弟子よ。お前はプログラミングを覚えて何をしたい？」
弟子「今はIT技術者が少ないといいます。この未曾有の危機にエンジニアとなってこの町を、この世界を自分の手で守りたい」
弟子「師匠のもとでC#プログラミングを学び始めて1年。if文だとかwhile文とかどうでもいいクソ知識を覚えて参りましたがやっぱり何の役にも立ちません。」
師匠「そうであろう。考えてみろ。お前は日本語を話せるが、アナウンサーにも小説家にも程遠いだろう？プログラミング言語を覚えるだけで何かできるようになると本当に思っているのか？」
弟子「そんな・・・だったら英語覚えて、おとといskypeで話しかけてきたカウガールとキャッキャウフフしてた方がマシじゃないか」
一般人はWindows PCとAndroidスマホを使う。*nixだのpicマイコンだのasicだのとは違う。
その時点において、かつて王道だったC言語を学ぶ意義はパンピーには無い。
ひっきりなしに飛んでくる他人からのメッセージに反応することを強要される毎日。
師匠「文字、数字から初めて、基本的な文法を覚えるだけで1年かかるか……そりゃつまんねーよな」
師匠「関数とスコープを覚えて、ようやく構造化プログラミングが学べる」
師匠「だが……学校じゃ文法やって終わりってんだから、CRUDも構造化もやらずに何ができるかってんだ。副作用とかどうでもいいことばかりは教えるくせによ」
師匠「機能の抽象化、モジュールの疎結合が重要だろう。そのためのオブジェクト指向だろう。」
師匠「なぜ抽象化と分割統治をしたいかと言えば、人の短期記憶は5チャンクが限界だからだ。つまりは頭の小さな人間が巨大なシステムを理解するための知恵だ。
師匠「HSPでプログラムを書いていて、500行くらい書いたらもう頭がごちゃごちゃになって限界を感じるあの感じ（個人の乾燥です）」
師匠「HSPの名誉のためにも言っておくが、500行以内であれば簡潔だし、絶大な威力を発揮するツールだ」
師匠「逆にCは3行書いたら、その関数の非力さに頭が痛くなる(個人の乾燥です)」
師匠「アセンブラに至ってはmov 1, $ax とか書いた時点で発狂する。なんでintel構文じゃないんだ！と」
師匠「つまるところ、プログラミングとは自由を勝ち取るために、人間の限界と戦うことだ」
師匠「創意工夫をこらして、今できないことをどうやってできるようにするのか。どんな可能性があるのか」
師匠「構造化プログラミングをすればバグが出なくなるわけじゃない。OOPでプログラミングがうまくなるわけでもない」
弟子「覚悟ｗｗｗｗｗ。少年漫画の見すぎなんだよ。何か奇声あげたら変身してパワーアップてかｗｗｗ？おめでたい奴だな。貴様は師匠として利用価値がなさそうだ。このあたりで成敗してやる。カラオケで女の子とデュエットしてやる」
いくつかあるSNSの中で最も、交流関係を気にせずに使えるのがTwitterだろう。
大半は、独り言を言っているに過ぎない。
その独り言に興味を持ったやつが返信してきたり、リツイートしたりしているだけだ。
気にせず独り言を言っていればいい。基本的に誰も聞いていない。
旅先の写真をアップしてるやつ、飯の写真をアップしてるやつ等々いるが、自己満足に過ぎない。
花火シーズンになると、花火の写真をアップしたりする。これも自己満足でしかない。
互いが密結合なSNSで一人、独り言を連発していれば、痛い人認定されるが、twitterなら平気だ。
たぶん聞いても判らないだろうし、マニアならギリギリ判るかも知れない、ぐらいの知名度だ。
彼の年収は、400万に届かない。
もちろん、独り身の彼は、たまの休みにピザを頼んだり、気になったアニメのＢｌｕ−ｒａｙを買えるぐらいには貰ってる。
彼の年収も、400万に届かない。
テレビＣＭやパチンコなんかのＣＧを作ってる。業界では大手の方の会社に勤めてる。
たぶん正社員だと思うが、そこまで雇用形態を詳しく突っ込んで聞いたことはない。
たまに集まって飲むと、平野耕太が昔描いてた、隕石を観ながらアニメを観る男三人みたいになる。
それでも、恵まれてるしな、アニメも面白いしな、仕事は嫌いじゃないしな、恵まれてるよな。
そんな話をする。全員薄々判ってる。
制作と製作の違いは、金を自分で持つかどうかだ、みたいなホントかどうか判らない話にもなる。
昔、大学で情報かなにかの授業で習った、疎結合みたいだなと話題になったことがある。疎結合。
密結合は、がっちり組み合わさってる。だから、一カ所落ちると全部落ちる。
金を出すスポンサーが居て、会社があって、アニメを作って、コける。会社は潰れる。
疎結合は、そこそこ離れてる。だから、一カ所落ちてもそこだけ落ちるだけですむ。
金を出すスポンサーが複数居て、製作委員会がある。当たれば分配し、コければそこまで。
制作会社はお金を貰い、作品を納品をする。当たろうがコけようが、変わらない。
結合が疎だから、制作会社が壊れても、別に製作委員会は困らない。出したお金分は困るけど。
制作会社も、製作委員会が沢山あれば、それぞれからちゃんとお金をもらえる。一本ごとに社運を賭けなくて済む。
制作会社は、社員を抱えてる。外注の人も居る。仕事を発注して、お金を払い、成果物を受け取る。
とても疎で、製作委員会とアニメーターの間は、電動歯ブラシみたいに、間違いなく充電してるはずなのに接点がない。
そんな話をする。全員薄々判ってる。
自分たちが、多分どこまで上り詰めても、そんなに給料が増えないってことは、判る。
だって、業界の重鎮だって、そんなに貰ってないもの。上の給料が伸びなければ、下は少なくなる。
今更何でも屋さんにはなれないし、みたいな話もする。
でも、仕事を取ってくるところが、もっと高い金額で受注してくれればとは言えない。仕事が無くなれば潰れる。
そうむやみやたらに社運を賭けられても困る。社員も居るわけだし。
下請けも居る。良い仕事はして欲しいけど、無い袖は振れない。社員には給料払わないといけないし。
単価安すぎるよなと誰かが言う。どうしてこうなっちゃったのかなと答える。
全員黙り込む。それでも現場は回る。
そういえば、あのアニメの元ネタにあいつ使われたな、ぐらいの話で盛り上がるくらいだ。
だって、ここでないどこかも、きっと同じだし。
もし放課後サマーレッスンに衝撃を受けたって宮崎駿が言いだして、格安でＶＲコンテンツ受注しだしたら，困るよな。
手弁当でＶＲコンテンツ配布されたりしたら、オレ達、宮さんなんて気楽に呼べる身分ですらないから、困るよな。
困るけど、きっとそれで、オレ達みたいな野郎が、その道に進む切っ掛けになったりするんだぜ。
スタジオぬえってすげえよな。なんか儲かってるかどうかも判らないけど、続いてるしな。
独立したり合併したり潰れたり、プロレス団体みたいだよなって言ったら、それは違うと言われた。
原画と動画の違いみたいなものだと言われた。キーフレームがあって、その間を動画が埋める。
良い絵コンテがあって、良いキーフレームがあって、良い動画があれば、良いアニメになる。
もちろん色も塗って合成もして仕上げもしてそれを回して、声も音響も良い方が良い。
でも、良くても悪くても、もらえる金額は同じなんだよな。でも、良いもの作りたいよな。
・挫折するな
・わけわからんことも絶対に「慣れ」て分かるようになるから諦めるな
・小問をいっぱい解いてプログラム作成の手順「仕様決定→コードへの落とし込み→デバッグ」を体で覚えろ(例:「解きながら学ぶC言語」)
・処理が複雑になったら関数にわけろ
・自分のやりたいことを分解して、小さなことから少しづつ進めていけ
・○○係みたいな感じでクラスを人だと思って作業分担させろ
・ただし、連携はなるべく少なくするんだぞ。「疎結合」を意識しろ
・複数のクラスを管理するクラスを作るとすっきりする場合があるぞ
・変数、関数、クラス、ファイルなどの名前付けは重要だぞ。知らないひとが見ても誤解しないような名前をつけるんだぞ
・抽象化は重要だぞ。うまく抽象化された関数やクラスは「実装すべきことがシンプルになる」「汎用性があがる」「不具合を見つけやすい」といいことづくめだぞ
・抽象化がわかりにくかったら、汎用的にすることを考えるといいぞ
・本屋のプログラミング書籍コーナーの書籍はタイトルだけでもすべて目を通しておけ
・本のタイトルに聞いたことがない単語があったら中身を読んでみろ
・プログラミング書籍いっぱい買うと本棚からのプレッシャーでやる気が起きる(かもしれない)ぞ
・プログラミング複雑すぎて人間にはできる気がしないって？大丈夫、慣れるから！
・プログラミング奥深すぎるって？あまり深淵をのぞくなよ！ほどほどにしとけ
・「根性」があればなんとかなるぞ
日本のSIerが求めている人材がいかなるものか、よーくわかったよ。
めんどくさいことをめんどくさがらずにやってくれる人だろ。
スパゲッティ化してどうして動いてるのか意味不明なコードを解読してくれる人。
コードを修正した場合の影響範囲を大量のExcelドキュメントから洗い出してくれる人。
自動化されていない単調で膨大なテストを手抜きせずにこなしてくれる人。
営業と話の辻褄合わせるためだけの、何の意味もない数字合わせの工数見積を徹夜でやってくれる人。
そういう人材だろ。
ソースコードを読めばすべてが理解できるようなプログラムが書ける人、
突貫工事で初期開発を終わらせて、
あとはできあがったものをえっちらおっちら運用してくのがビジネスモデルなんだものな。
おれSIer向いてないわ。辞めよう。
日本のSIerが求めている人材がいかなるものか、よーくわかったよ。
めんどくさいことをめんどくさがらずにやってくれる人だろ。
スパゲッティ化してどうして動いてるのか意味不明なコードを解読してくれる人。
コードを修正した場合の影響範囲を大量のExcelドキュメントから洗い出してくれる人。
自動化されていない単調で膨大なテストを手抜きせずにこなしてくれる人。
営業と話の辻褄合わせるためだけの、何の意味もない数字合わせの工数見積を徹夜でやってくれる人。
そういう人材だろ。
ソースコードを読めばすべてが理解できるようなプログラムが書ける人、
突貫工事で初期開発を終わらせて、
あとはできあがったものをえっちらおっちら運用してくのがビジネスモデルなんだものな。
おれSIer向いてないわ。辞めよう。
