「疎結合」を含む日記 RSS

はてなキーワード: 疎結合とは

2020-06-19

anond:20200619163719

ちなみに権利問題があるから、ほぼおりじなると オープンソース版と トリプルスタックぐらいだから、好きなの選べる。そういうのも売りだった。

オープソースがいいという人もいれば、商用ライブラリがいいという人もいるからな。

互換性がすくなくて、まぁでも 大したことはない まぁでも選べるから 実はオープンソースのXX使ってるでしょというのは 正解でもあるし 間違いでもある。

オリジナルスタック オープンソーススタック 有償の某社清貧など 色々なパーツが取り替えられるように疎結合で作ってある。デフォルトは外部公開しやすいように オープンソースを呼ぶようになってるから誤解されやすい。

2020-05-30

Manycoreという技術のものIntelもだしてる。さらなるManyはGPGPUでやってる。

他方シングルコア性能は上がってはいるが4Gぐらいで、議論を呼んでる。

議論を読んでいるのは、コンパイラ最適化と、マイクロコード最適化

そこはかなり疎結合からな。インタプリタで言うエンジン最適化ではないが

CPUでどう最適化されるか?をインタプリタがもうすこし制御すればインタプリタスクリプトコードをもう少し効率的な生成にできるのではないか?というアプローチJava的ではなくPython的にあらわれはじめていて、けっこう、興味深い

 

デフォルトPythonコーダー機械語の変換について学習させてあるPythonという考え方はとてもポケモン的で面白い

2020-04-12

anond:20190329105413

最近Laravelで開発してるPHPerだけど、その辺ってDI疎結合に出来ないのかな?

RailsってDIないの?と思ったら、そもそもRubyインスタンスへの依存性は動的に変更できるらしいじゃん

FWがどうとかじゃなくてプログラマが適切に設計できる技術がないだけじゃないの?

view部分はJSON返すAPI作っておけばいいし、この人が何を言ってるのかよくわからん

一昔前のRailsおじさんが作った密結合のシステムを今でも作っちゃうってこと?

2019-08-24

anond:20190823210357

確認したら同じようなことが既に書かれてた

はずかし

”1人月”って表現めちゃ理不尽な感じがするよね・・・

俺は優秀に入る部類ではなく類友と言われるかもしれないが

出来ます!って面しておきながら

「ええとあなた疎結合』って聞いたことあります?」

というレベルなので自信をもって「あいつらよりはマシ」と言える・・・

2019-07-03

役に立たないReactJS vs Vue.js

Reactはライフサイクルを細かく設定でき、その辺きちんと設定できないとまともに動かない。一方Vue.もライフサイクルを細かく設定できるが、適当に書いてもなんとなく動く感じがある。書き方はReactのほうが好きで、フックを使って疎結合コンポーネントを作れるのは大きい。

あとReactはVirtualDOMからTypeScript恩恵を受けやすそうな気がする。VueTypeScriptは試してないけど、DOM内のv-なんちゃらattributeのSyntaxチェック働かなさそうだし。

2019-06-07

railsしかできない奴と仕事するのが辛い

Ruby on Railsを使うことは出来ても

プログラミングはできてない奴ばっかり

スパゲッティコードだらけで

変数メソッドスコープもめちゃくちゃ

入門レベルにも満たない

昔はphperなんて蔑称もあったがrailsしかできない奴に比べたらよっぽど優秀だわ

基礎もなければ融通も応用も利かない

馬鹿の一つ覚えでrails wayに乗ることに必死

railsを盲信し過ぎて思考停止してるから規模が大きくなっているのに

作り方も考え方もプロトタイプレベルのまま

可読性も可用性も拡張性も低い

意味理解できてないくせに口癖は「MVC」「疎結合

勉強しようともしない

セキュリティデータ整合性担保されていないお粗末なクソシステム

エンジニアを名乗らないで欲しい

2019-03-29

Rails技術負債である

Railsを使うと、初速は早くなる。それは間違いないと思う。一方で、RailsはVierwからDBまで密結合したフレームワークなので、「段階的なアップグレード」とかがむずかしい。ヴァージョンをあげるときには一気にエイヤであげる必要が出てきがちであるさらに、プロダクトが巨大になってくると結局様々な工夫を凝らしてViewからDBまでの間を疎結合にしていくことになる。そうなってくると、「これRailsである意味あるんだっけ」となって、段階的なアップグレードのしくさや気をぬくと密結合な設計になるという欠点が目立ってくる。

これは、まさに技術負債のものである。ここでわたしが「技術負債」を「単なる悪いもの」として扱っているわけではないことに注意してほしい。Railsを使うというのは、そういう将来の負債を借り入れて、その借金を使って早くプロダクトを世の中に届けるという判断をしている、ということだ、ということを言っているのであって、「借金してでも早く出したい」という判断合理的で正しい場合ってのは、腐るほどある。

ただ、Railsを選ぶときに、「今俺たちは借金をしているんだ」って思いながら選んでほしい。その感覚がないと、プロダクトが軌道にのったあとも借金を返すためのリソースを捻出しないまま、破綻したコードベースに消耗してプログラマがどんどん逃げて言って最後にはプロダクトが潰れて終わるので。

2019-03-22

いけあやとちょまど

前者は、女優業とエンジニア業が疎結合なのでキャリアメンテは用意だけど、後者は密結合なので大変そう

2019-03-07

「すっきりする」の謎

よく「男女がいてこらえられなくなった男が女に抜いてもらう」みたいな展開のエロ作品あるじゃん。あれ自体はまあ夢みたいなところあるし、あわよくば僕もされたいから、「現実ではありえない」みたいなツッコミをされても「現実ではない。」みたいな返しをしておけばいいけどさ。

でも、その流れで。どうしても納得のいかないが1つだけあって。

「すっきりした?」

すっきりするって何?10年来射精し続けてきて1回もすっきりなんてしたことないぞ?お前は射精を何だと思っているんだ!?

疑問その1. 「他者による射精目標とはすなわち性欲の鎮圧以外を含みうるのか?」

まず、他者から観測可能な結果の一つであるところの射精目標とした一連の行動 S について考えなければならない気がするんだよな。別にこれは自分で手コキしようと他人任意ズリさせようと何でもよくて、最終的に射精するために行う動作ならばなんでもいいんだけど。あ、話を簡単にするためにとりあえずドライは考えない方向で。

英語でシコることを jerk off というらしいので、抜く人を jerker 、 抜かれる人を jerkee とおくことにするか。一人遊びならこの2つは参照等価ってことで。さしずめ、冒頭のストーリーならば jerker !== jerkee && jerkee.sex === 'male' && jerker.sex === 'female' ってわけだ。

この場合、少なくとも jerker の目標には「jerkee を射精させること」が含まれる。「S は射精させるために行われる」という前提だけど、まあ「S が行われるならばそれは射精させるためである」でもいい……よな。射精以外の目的もつ行動は S に含まない、にしよう。

性欲の鎮圧以外を含みうるのか、については真だろうな。「なさけない顔を見る」とか「背徳感を得る」とか、よく考えれば他の目的なんていくらでも足せるじゃんな。

……うーん。射精って jerkee が自分身体契約を以て行われるものではないんだよなあ。あたりまえだけど目標は叶わない可能性も十二分にあるし。

目標が叶わないといえば、男女の場合は往々にして知識が非対称だから jerker が射精させようとしてもできないってのは普通にありうるか。それはそれでかわいそうだな……。jerkee になったらいたたまれなくて泣いちゃうかもしれない。

あー。射精コミュニケーションという説があるな。一人遊びは実際自己との深い対話だもんな。我々は精液が尿道から射出されるという非対称な現象を通じて相互理解の境地にいたることができるのか。

そんなわけねえだろ

疑問その2. 「射精他者から観測可能であることは自明か?」

実はこれけっこう怪しいと思っていて。というのも、枯れると文字通り枯れるから観測不能になっていくじゃん。まあ握っていればちんちんの収縮ぐらいはわかるだろうけど。

観測を以って射精定義するならば精液が出なくなった時点でそれはもはや射精ではないということになっちゃねこれ。言葉としては正しいと思うけど、ではドライオーガズムではない、シコってイッたが外見上何も起こらないというのはどう定義しておけばいいんだ? vacuous ejaculation とでもしておくか。

vacuous ejaculation を認めるとこの男女間射精コミュニケーションの飽和状態ってかなり危うそうだ。 jerker の手が果てるのと jerkee の精液が果てるの、よほど jerker が虚弱貧弱でない限り後者が先だし、前者が発生するまでは continuous vacuous ejaculation が発生する。vacuous でなくとも理性を保つのは極めて困難であるからして、これは廃人まっしぐらなんじゃないのか?

疑問その3. 「射精は様々な情動疎結合なのか?それとも密結合なのか?」

これは絶対に疎だと思うね。密結合だったらちんちん生活支配されないじゃん。

疑問その4. 「射精によってすっきりすることは可能なのか?」

前半は全部わりとどうでも良い文章で、本題はこっからだよ。

結局「すっきりする」というのがわからない。単にたまっていたものが抜けたような感じを受けるという程度の話なのであればそれは単純で、物理的に抜けているのだから可能である結論付けられるように思える。

しかし、しかしだ。「すっきり度」を時間微分して、射精した瞬間その値が一定以上でなければ実感として「すっきりした」という感覚を得られないとしたら?絶対的に一定以上常にすっきりしている人間は、つまり「すっきりした」という感覚を一生得られないということにつながるのではないか

同じことが「賢者タイム」という概念についても言える気がしてきたぞ。賢者になりきってしまったらちょっとやそっとの愚行では何とも思わなくんしまうんじゃん。

結論

自分がシコりすぎて頭がおかしくなっている。そろそろ通算10000回はシコったと思うし、自分にごほうびでも買ってあげたほうがいいかもしれんなあ。

思い付いたことを適当に並べているだけなので論理的破綻しているところがあっても多少は目をつぶってほしい。

2018-12-27

anond:20181227003648

一番いい例があるぞw 税務計算だ。>大規模な疎結合やらなんやら 国税庁はなぜ脱税を見抜けるかの仕組みは正に増田の言ってることじゃね。

あと多分増田意図的中二病ワードを使ってるのだから一応指摘しておくが、そういうのが一番わかりやすオカルト認定チェックポイントからな。

まりやりたくないけど

大規模計算

とはなんであるかを具体的に数字などを置いて説明してみてくれ。まあ、抽象的でもええぞ。

論理的説明できるかどうかを増田自身がまず証明しよう。

あとな、

どうして、スーパーコンピュータインターコネクトやトポロジが設計上の今日的なテーマになっているのか

しろレギュレーションからこれらの発展を求められただけであって、巨大な問題を高速で解くという解法に関してはほぼ増田が言うところのgoogle式でいいはずなんやけど、認識間違ってる?

まあそれと物理エンジンの話は未知の粒子(それこそ時間を司る粒子)の存在だったりがあったりする以上今までもこれから先数十年は「それっぽい再現」にしかならんのはそうだが、それは揚げ足取りみたいなもんや。

「一番短い時間単位で粒子は同時に一つだけ動く」ルールで一応アインシュタイン世界エミュレーションできるんだから、それは不可能ではない(計算する時間無視すれば)って話でSFにも近い話だから別に増田は納得しなくてもいい。本題とは関係ないしな。

いずれにしてもだな。最初Pezyへの偏見から切り出したのは事実だが、この偏見が未だ解けずにいる。増田はその知性主義というやつでなんとかこの偏見を解いてみてくれ。

嘆くだけでは、何も進まんぞ。

2018-10-12

プログラミング本質カプセル化ブラックボックス

コンピュータマシン語命令文もデータも数値で表す。これは今も昔も同じ。

数値だけでは人間管理しづらいので命令文を mov や add のようなわかり易い単語に置き換えたのがアセンブラ

(わかりづらい数字人間理解やす英単語に置き換えた)

アセンブラも規模が大きくなると人間には管理しずらくなる。

そのため人間言語により近い高水言語が生まれた。

if や for などで制御をわかりやすくした。

複数の処理をひとまとめで扱うサブルーチン関数プロシージャ・ファンクション

いったものができた。

(処理の流れをわかりやすくした、構造化、カプセル化

複数データをひとまとめで扱うレコード型や構造体生まれた。

カプセル化

コードデータをまとめて扱うクラスができた。

カプセル化抽象化

アプリケーションからOS機能を呼ぶシステムコールAPIが生まれ

ブラックボックス化)

複数クラスコードデータをひとまとめにするにモジュールができた。

カプセル化

プログラムを外部から操作するRPC、CORBA、SOAPRMIができた。

リモートから操作ブラックボック化)

WebAPIアーキテクチャーを超えての疎結合が進む

さらなるブラックボックス化)

IaaS / SaaS / PaaS を使いネット上のサービスにつないでシステムを構築する。サーバ管理不要に。

ブラックボックス化)

CIツールサーバ数台〜数百台を1人で扱えるようになった

操作の簡略化)

DockerWEB/DB/KVSなどをまとめてコマンド1つで扱えるようになった。

カプセル化抽象化

プログラミングとはわかりづらいマシン語人間にわかやすくするのが本質

カプセル化ブラックボックス化・操作の簡略化は正義

2018-09-13

仕事では完璧にしようとか考えず動く程度に適当に作ればいい

面倒な上司がいろいろ文句をつけてくる

意味不明ものが多いし何かとケチつけないと気がすまない性格から面倒なことを一々と

直接のユーザから意見なら多少は変でもそのユーザ必要としてるなら納得できるし、イライラすることもない

依頼があったわけでもないのに謎の基準文句をつけてくる

社内でそんなことこだわったところで実際には気にされないことが多いのにだ

まだデザイナーデザインについてこうした方がUXいいねみたいなことをいうならわかる

専門の人の意見だし

そうでもないのに何かと文句をつけてくる

増田なのでwebで例をだそう

CSS すらまともに使いこなせずマージンもパディングもないような酷い作りのものしか作らないのにソッチのほうが良いという

色は red, green, yellow と標準のペイントのデフォルトカラーかよというような色を指定してくる

#fcfcfc や #0a0a0a なんて使おうものなら白と黒しろ

max-width を指定せずに画面の端から端まであるようなものがいいという

そのわりにグラデーション無意味につけたがる

一部例じゃなく本音が出たがまぁいいか

今の時代アプリサービスを全く見てないのか?としか言えないようなセンス

自社サービスなんて手を出したらこれは酷いと話題になりそうなもの

見た目にあまりこだわれない社内用サービスしか作ってないからと言って、その他サービスをみてる人からすれば明らかに

残念なしか時代遅れなものが良いと思ってる

しかデザインに限ったことではないがまだ序盤の時点で言っておけばいいものの完成後にいまから変えるなんて難しいのが

わかりきってるようなときになってからああしろこうしろ言い出す

先に書いたようにユーザ要望ならまだ仕方ないと言えるがなぜこんな無意味なことに付き合わなければならないのか


わりと自分完璧主義なところもあるので作るならちゃんと作ろうとしてるんだが

こういうのを相手にしないといけないせいで結局グチャグチャになってくる

色のバランスレイアウトを考えたところで一瞬でそのバランス無意味になるようなことになる

プログラムだって全然関係ないものを無理やり入れ込まないといけないようなことになることも多い

疎結合だとかグローバルをつかわないとかそういう作りやすくするためのことをしていても

それが維持できないような無茶で無意味な指示が出る

根本的に変えたり対処するためのものを作るとかすればなんとかできなくはない

しかしそんな時間はないので結局ひどい作りになるしかない

過去プロジェクトでもそういうのが多いか自分で作るのくらいは扱いやすくしたいと考えていたのだが

過去のもこういう経緯で酷いものになっていったのかなと思う


過去に言われたものだと速度を優先だとか言って自分で作ったものよりは遅くするなと言う

そしてそのコードは本人でしか読めないような酷いものだった

しかしながら関数は使わずコピペだわforeachなどは使わずループ変数を使って地道にやるなどメンテナンス

できる気がしないが速度においては早いと言えるもの

当たり前のようにグローバル変数がいっぱいあるしライブラリ使用箇所はカスタマイズするための仕組みがあるのに

ライブラリ自体をどんどん書き換えていく

便利で読みやすいような書き方だと速度的にはそれに劣る

だがわざわざそんな扱いづらいし見づらいコードは書きたくない

そんなに速度にこだわるなら勝手に一人で機械語でも書いてろよって思う

しかし速度に加えてメンテやすしろという

どちらか取捨選択すべきものなのに両方みたせとか無理なことを言う

ちなみに便利なライブラリは基本無駄が多い遅いものからライブラリ頼みのベンダはクソだとか

能力がないだとか言っていた


そういえば昔先輩社員仕事したときには変に凝ったものとか必要以上に作り込んだりはしないほうがいいとか

言っていてそれなりに手抜きでさらっと一応は動くようなものを作っていた

私はそういうやり方が嫌いだったのだが今ではこういう環境に長くいた結果仕事のものにこだわって作り込んでも無駄

ということがわかってそうなったのかなと感じた

自分でもサビ残休日無償出勤してまでいいものにしようと努力はしていたが謎の指摘に合わせていると

愛着もなくなってきたし後は適当に済ませてしまおうかなという気持ち

ちゃんとした自分なりの完璧ものを作ろうとするなら仕事ではなく趣味で作ってるツールライブラリ

やればいいかと思う


作ったもの次第でユーザが集まる自社のウェブサービスパッケージ商品ゲームなどは作り込む方が

良いと思うが先に値段が決まって受注して作るようなものだと最低限の要望さえ満たしていればあとは

どうでもいい

しろ不便な方が改修依頼が来て稼げる

さらには綺麗で完璧な作りで大抵の想定できる改修は1日とかからないようなものに仕上げるよりも

どこ変えればいいかや影響範囲すらわからいくらいモノのほうが実作業時間が多いのでそれだけ請求できる

先に作り込むメリットがない


ストレスが溜まってきたので発散がてら書いてみたけど疲れてるのかわりと分かりづらい文章になった

けどまぁいいか

そろそろ転職でもしたいなーと考え始めた










2018-03-23

anond:20180323000414

双方個人には責任は無いと思う。

ただ、A社の配置問題もあったろうけど、増田会社のせいでもある。

他社他部署間で緊急の作業依頼を当たり前に遂行される前提の業務設計になってるのが間違いで、それを国内企業全体で作り変えていかないと育児世代活用体制なんか整わない。

もっと言えば、発注してる業務が何なのかわからないけど、増田会社外注してる業務を自社で遂行するための人員を雇う選択肢もあるのに、雇用の面倒なんかと天秤にかけて組織機能としては疎結合にしたいか外注にした。でも自社との連携には密連携要求する。

こういうアンバランスのしわ寄せで労働者同士が首絞め合うことになってる。

2016-10-03

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

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

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

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

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

2016-09-29

IT】死にコードってどうすりゃいいの?

プログラミングにおける死にコードって皆どうしてんだろ

テストコード書くって方針は無しで)

 

存在するリスク 

勘違いする

邪魔

バグの温床

 

消すリスク

・実は使ってるかもしれない

・再テスト必要

・また使うかもしれない

 

アイディア

存在しても邪魔にならないようにする

  ・勘違いしづらいコード

  ・隠蔽

・速攻消せるようにする

  ・厳重に疎結合を保つ

 

何かしっくりこない

2016-05-13

プログラミングの極意

師匠プログラミングとは深淵なる神の御業(みわざ)。あらゆることを可能とし、あらゆることが不可能であると知る。」

弟子「さすが師匠っす。私にはまだまだ理解できないっす」

師匠「当然だ。」

師匠「ところで弟子よ。お前はプログラミングを覚えて何をしたい?」

弟子「今はIT技術者が少ないといいます。この未曾有の危機エンジニアとなってこの町を、この世界自分の手で守りたい」

師匠「ふむ。良い心がけだ。精進したまえ」

弟子「ところで師匠

師匠「なんだ弟子よ」

弟子師匠のもとでC#プログラミングを学び始めて1年。if文だとかwhile文とかどうでもいいクソ知識を覚えて参りましたがやっぱり何の役にも立ちません。」

師匠「そうであろう。考えてみろ。お前は日本語を話せるが、アナウンサーにも小説家にも程遠いだろう?プログラミング言語を覚えるだけで何かできるようになると本当に思っているのか?」

弟子「そんな・・・だったら英語覚えて、おとといskypeで話しかけてきたカウガールキャッキャウフフしてた方がマシじゃないか

師匠「ちょ、おま、それアカンやつや」

弟子師匠バカ。もう知らない!」

世界コンピュータ端末があふれるようになって数年。

一般人Windows PCAndroidスマホを使う。*nixだのpicマイコンだのasicだのとは違う。

その時点において、かつて王道だったC言語を学ぶ意義はパンピーには無い。

ベーマガ失われた世界で、人々はプログラミングを見失い、

人が使ってるからという理由自分の使うアプリを決められ、

ひっきりなしに飛んでくる他人からメッセージに反応することを強要される毎日

師匠文字数字から初めて、基本的文法を覚えるだけで1年かかるか……そりゃつまんねーよな」

師匠ファイル入出力やってようやくCRUDが学べる」

師匠関数スコープを覚えて、ようやく構造プログラミングが学べる」

師匠「だが……学校じゃ文法やって終わりってんだからCRUD構造化もやらずに何ができるかってんだ。副作用とかどうでもいいことばかりは教えるくせによ」

師匠機能抽象化モジュール疎結合重要だろう。そのためのオブジェクト指向だろう。」

師匠「なぜ抽象化疎結合かといえば分割統治をしたいからだ」

師匠「なぜ抽象化分割統治をしたいかと言えば、人の短期記憶は5チャンクが限界からだ。つまりは頭の小さな人間が巨大なシステム理解するための知恵だ。

師匠HSPプログラムを書いていて、500行くらい書いたらもう頭がごちゃごちゃになって限界を感じるあの感じ(個人の乾燥です)」

師匠HSP名誉のためにも言っておくが、500行以内であれば簡潔だし、絶大な威力を発揮するツールだ」

師匠「逆にCは3行書いたら、その関数の非力さに頭が痛くなる(個人の乾燥です)」

師匠アセンブラに至ってはmov 1, $ax とか書いた時点で発狂する。なんでintel構文じゃないんだ!と」

師匠「つまるところ、プログラミングとは自由を勝ち取るために、人間限界と戦うことだ」

師匠「創意工夫をこらして、今できないことをどうやってできるようにするのか。どんな可能性があるのか」

師匠構造プログラミングをすればバグが出なくなるわけじゃない。OOPプログラミングがうまくなるわけでもない」

師匠プログラミングの極意とは現実と戦うという覚悟だ」


弟子覚悟wwwww。少年漫画の見すぎなんだよ。何か奇声あげたら変身してパワーアップてかwww?おめでたい奴だな。貴様師匠として利用価値がなさそうだ。このあたりで成敗してやる。カラオケ女の子デュエットしてやる」

師匠「本性を現しおったなぁぁっ!このバカ弟子がぁぁっ!!」

2016-03-26

疎結合で、生きる。

たまに、密に。

2015-06-15

http://anond.hatelabo.jp/20150615004630

いくつかあるSNSの中で最も、交流関係を気にせずに使えるのがTwitterだろう。

大半は、独り言を言っているに過ぎない。

その独り言に興味を持ったやつが返信してきたり、リツイートしたりしているだけだ。

気にせず独り言を言っていればいい。基本的に誰も聞いていない。

旅先の写真をアップしてるやつ、飯の写真をアップしてるやつ等々いるが、自己満足に過ぎない。

花火シーズンになると、花火写真をアップしたりする。これも自己満足しかない。

互いが密結合なSNSで一人、独り言を連発していれば、痛い人認定されるが、twitterなら平気だ。

twitterでは、お互い、疎結合だ、独り言を連発していようが、何ら問題ない。

2015-05-01

少し愚痴

アニメ業界の友人の話だ。

たぶん聞いても判らないだろうし、マニアならギリギリ判るかも知れない、ぐらいの知名度だ。

彼の年収は、400万に届かない。

もちろん、独り身の彼は、たまの休みピザを頼んだり、気になったアニメのBlu−rayを買えるぐらいには貰ってる。

アニメではないが、近い業界の友人も居る。

彼の年収も、400万に届かない。

テレビCMパチンコなんかのCGを作ってる。業界では大手の方の会社に勤めてる。

たぶん正社員だと思うが、そこまで雇用形態を詳しく突っ込んで聞いたことはない。

たまに集まって飲むと、平野耕太が昔描いてた、隕石を観ながらアニメを観る男三人みたいになる。

先が見えない、結婚できない、仕事が忙しい。

それでも、恵まれてるしな、アニメ面白いしな、仕事は嫌いじゃないしな、恵まれてるよな。

そんな話をする。全員薄々判ってる。

制作製作の違いは、金を自分で持つかどうかだ、みたいなホントかどうか判らない話にもなる。

アニメーション制作会社は、制作だよな。

昔、大学情報かなにかの授業で習った、疎結合みたいだなと話題になったことがある。疎結合

密結合は、がっちり組み合わさってる。だから、一カ所落ちると全部落ちる。

金を出すスポンサーが居て、会社があって、アニメを作って、コける。会社は潰れる。

疎結合は、そこそこ離れてる。だから、一カ所落ちてもそこだけ落ちるだけですむ。

金を出すスポンサー複数居て、製作委員会がある。当たれば分配し、コければそこまで。

製作委員会は、制作会社作成を依頼する。

制作会社お金を貰い、作品を納品をする。当たろうがコけようが、変わらない。

結合が疎だから制作会社が壊れても、別に製作委員会は困らない。出したお金分は困るけど。

制作会社も、製作委員会が沢山あれば、それぞれからちゃんとお金をもらえる。一本ごとに社運を賭けなくて済む。

制作会社は、社員を抱えてる。外注の人も居る。仕事発注して、お金を払い、成果物を受け取る。

とても疎で、製作委員会アニメーターの間は、電動歯ブラシみたいに、間違いなく充電してるはずなのに接点がない。

そんな話をする。全員薄々判ってる。

自分たちが、多分どこまで上り詰めても、そんなに給料が増えないってことは、判る。

だって業界の重鎮だって、そんなに貰ってないもの。上の給料が伸びなければ、下は少なくなる。

今更何でも屋さんにはなれないし、みたいな話もする。

でも、仕事を取ってくるところが、もっと高い金額で受注してくれればとは言えない。仕事が無くなれば潰れる。

そうむやみやたらに社運を賭けられても困る。社員も居るわけだし。

下請けも居る。良い仕事はして欲しいけど、無い袖は振れない。社員には給料払わないといけないし。

単価安すぎるよなと誰かが言う。どうしてこうなっちゃったのかなと答える。

全員黙り込む。それでも現場は回る。

特にオチは無い。

そういえば、あのアニメ元ネタあいつ使われたな、ぐらいの話で盛り上がるくらいだ。

だって、ここでないどこかも、きっと同じだし。

もし放課後サマーレッスンに衝撃を受けたって宮崎駿が言いだして、格安でVRコンテンツ受注しだしたら,困るよな。

手弁当でVRコンテンツ配布されたりしたら、オレ達、宮さんなんて気楽に呼べる身分ですらないから、困るよな。

困るけど、きっとそれで、オレ達みたいな野郎が、その道に進む切っ掛けになったりするんだぜ。

スタジオぬえってすげえよな。なんか儲かってるかどうかも判らないけど、続いてるしな。

独立したり合併したり潰れたり、プロレス団体みたいだよなって言ったら、それは違うと言われた。

原画動画の違いみたいなものだと言われた。キーフレームがあって、その間を動画が埋める。

キーフレームは、絵コンテから出来る。

良い絵コンテがあって、良いキーフレームがあって、良い動画があれば、良いアニメになる。

もちろん色も塗って合成もして仕上げもしてそれを回して、声も音響も良い方が良い。

でも、良くても悪くても、もらえる金額は同じなんだよな。でも、良いもの作りたいよな。

社運を賭ければ儲かるけど、そうそう賭けられても困るから、難しいよな。

そんな話をする。全員薄々判ってる。特にオチは無い。

2015-01-28

http://anond.hatelabo.jp/20150127233707

疎結合するにもAPI仕様とか決めなきゃで

システム間で必須データがないとかで項目追加したり

銀行の慣習で合わせられずに悩んでたりとか

疎結合で行きたいのにAシステムとBシステムで同時にデータを投入しないといけなくて

疎結合にできないから直接コード叩いたりするにしても

その調整もままならないから関係で待たされたり嫌がらせされたり

してるんじゃね?

疎結合ですべてがハッピーなんて絶対にないから

そもそもSOAなんてweb2.0と同じバスワードだw

http://anond.hatelabo.jp/20150128000450

次期システムとは大雑把にいうと80年代に構築され今なお稼働しているシステムのうち、外為、内為、預金などの業務にて稼働するサービス(実際のプログラムになる)を疎結合

日本語も読めない人に限って、すぐ非コミュとか言っちゃうんだよなぁ…

http://anond.hatelabo.jp/20150127233707

うん?

疎結合システムを作ろうって話なのに、規模のせいにしちゃうん?

2013-03-28

挫折しそうなプログラミング初心者への助言

挫折するな

・わけわからんことも絶対に「慣れ」て分かるようになるから諦めるな

・だからわけわからなくてもぶつかり続けろ

・小問をいっぱい解いてプログラム作成の手順「仕様決定→コードへの落とし込み→デバッグ」を体で覚えろ(例:「解きながら学ぶC言語」)

プログラムは文と式で構成されていることを意識しろ

・処理を共通化できそうなら関数しろ

・処理が複雑になったら関数にわけろ

自分のやりたいことを分解して、小さなことからしづつ進めていけ

ソースコードが複雑になってきたらクラスを使え

仕事クラスに分担しろ

・○○係みたいな感じでクラスを人だと思って作業分担させろ

・そしてクラス同士を連携させるんだ

・ただし、連携はなるべく少なくするんだぞ。「疎結合」を意識しろ

・複数のクラス管理するクラスを作るとすっきりする場合があるぞ

変数関数クラスファイルなどの名前付けは重要だぞ。知らないひとが見ても誤解しないような名前をつけるんだぞ

抽象化重要だぞ。うまく抽象化された関数クラスは「実装すべきことがシンプルになる」「汎用性があがる」「不具合を見つけやすい」といいことづくめだぞ

抽象化がわかりにくかったら、汎用的にすることを考えるといいぞ

本屋プログラミング書籍コーナーの書籍タイトルだけでもすべて目を通しておけ

・本のタイトルに聞いたことがない単語があったら中身を読んでみろ

プログラミング書籍いっぱい買うと本棚からプレッシャーでやる気が起きる(かもしれない)ぞ

プログラム難しすぎるって?大丈夫、慣れるから

プログラミング複雑すぎて人間にはできる気がしないって?大丈夫、慣れるから

プログラミング奥深すぎるって?あまり深淵のぞくなよ!ほどほどにしとけ

・「根性」があればなんとかなるぞ

・「好奇心」があれば技術に関する情報勝手に集まってくるぞ

・「楽したい気持ち(工夫を楽しむ心)」があればいつまでもプログラミングを好きでいられるぞ

2013-03-21

SIer向いてないので辞めることにする

日本SIerが求めている人材いかなるものか、よーくわかったよ。

めんどくさいことをめんどくさがらずにやってくれる人だろ。

スパゲッティ化してどうして動いてるのか意味不明コードを解読してくれる人。

コードを修正した場合の影響範囲を大量のExcelドキュメントから洗い出してくれる人。

自動化されていない単調で膨大なテストを手抜きせずにこなしてくれる人。

営業と話の辻褄合わせるためだけの、何の意味もない数字合わせの工数見積徹夜でやってくれる人。

そういう人材だろ。

疎結合で変更に強いソフトウェア設計できる人、

テスト自動化ができる人、

ソースコードを読めばすべてが理解できるようなプログラムが書ける人、

科学的な工数見積ができる人なんてのは必要ないんだな。

突貫工事で初期開発を終わらせて、

あとはできあがったものえっちらおっちら運用してくのがビジネスモデルなんだものな。

おれSIer向いてないわ。辞めよう。

ログイン ユーザー登録
ようこそ ゲスト さん