「オーバーヘッド」を含む日記 RSS

はてなキーワード: オーバーヘッドとは

2017-10-08

anond:20171008105431

日本は海で隔てられてるから文化が違いすぎて細々した対応項目が多すぎる(個々の難易度や個々の予算じゃなくて積み重ねた量やオーバーヘッドが異様に大きくなる)し、その割に50年前みたいに日本企業世界中を握ってる訳でもないか購買力がない。だから日本で本気で売れても儲からない。もう日本の動向を探っておかないと、日本企業が売り始めたもの他国に波及してボロ負けするということもなくなったから、市場調査という意味で出す必要もない。

国内からすれば国内企業にとってはホームグラウンドから重要だと錯覚してしまうが、日本市場を捨ててもビジネス的に影響はあまり無い。むしろ今後を考えて中国市場名前を定着させる方が重要営利企業には儲かるから広く世界中で売りたいという動機はあるが、貧乏人にあまねく普及させる義務はない。だから捨てられる。

2017-07-20

https://anond.hatelabo.jp/20170720150317

あれはラモスだけのせいにするのは無理があるよ

カズ落選から岡田監督日本代表へのプレッシャーが高まってた

・今と比較にならないくらい影響力があったメディアが、W杯に浮かれて視聴者煽りまくってた

カズの代わり。これから代表の軸って言われてた城は無得点しかも、やっときた決定機にオーバーヘッド狙いにいって外す

・さんざん批判されても使い続けた城を交代。その直後に初得点アシストしたのは城に代わって入った呂比須

一億総張本、総セルジオ状態だったし、スポーツ界は根性論支配されていた

結果を出せていない選手が、ガム噛んで笑いながら試合するなんて論外だった

ラモスは元からヒートアップやすかった上、仮にも元日本代表から、さすがに今それやっちゃマズイって思ったんじゃないか

ファン心配になるくらい日本中イライラしてた

正直、メディアが加熱しまくってたから、ラモス解説がなくても城は戦犯扱いされただろうし、水かけ事件が起きたと思う

ラモス解説は褒められたもんじゃない。

でもそれだけ切り出すのは、特定選手ミスプレイを取り上げて戦犯に仕立て上げるのと変わらない

時代環境、状況。前後の流れがあるんだから

ネットが行き渡って、色々な情報に触れられる今だったら違っただろうね

2017-04-19

進撃の巨人最新刊めちゃくちゃ面白かった

ここからネタバレになるから独語人間のみ読んだ方が良い。

 

今まで敵だと思ってた巨人同胞たちの成れの果てで、

自由があると思ってた先が人間同士の戦争という非情な答えだったということ、

そしてそれでも進み続けなければいけないという記憶バトンエレンに託されたということ。

 

今まで出た巻の中でエレンの悲しみが短くも強烈に描写されてる。

これから迎えるであろう悲惨未来にどうエレンアルミン・ミカサたちが立ち向かっていくのか。

それが今から恐ろしくも楽しみである

 

進撃の巨人のここがすごいよ】

他の漫画を引き合いに出して悪いが、アイアムアヒーロー駄作だった。

完結後、再び全巻読み直して落ち着いて出した結論駄作だった。

ライブ感とか毎週楽しませてくれたからというのはやはり作品総評をする際に適切ではないと思う。

単に考えてませんでした、で済む言い訳からだ。

世界崩壊系、パニック漫画ラストが尻すぼみや雑な投げやりされる理由は、

既存世界崩壊した先にある新たな社会形態を作者が想像創造)しきれないからだ。

増田は嘘だと思うかもしれないが、人間想像力には限界がある。

時間空間を超えた次元人間イメージする術がないように、

体験し想起し再現できないものは頭の中でも思い描くことは不可能

実現可能なのは予測できる範囲内の事象に延長線上を引いたものであり、

からこそ人間想像できることは全て実現可能であると言われる所以である

 

漫画小説アニメ…というのは舞台設定を異世界世界改変とし、

世界の有り方そのものテーマに据えた場合、作者の頭脳演算能力に対して要求されるスペックが跳ね上がってしまうことが多々ある。

そうなった際に作者ができることは投げっぱなしにするか、夢オチ、爆発オチ、とってつけたようなオチしかない。

漫画登場人物は作者の頭脳を超えることはできないのと同じように想像力限界に突き当たってしまった漫画

そこで先に進めなくなり見えない壁にぶつかり、幕を下ろすしかなくなる。

それがアイアムアヒーローであり、20世紀少年であり、ドラゴンヘッドであり、数多のゾンビパニック映画オチだ。

とにかく異世界整合性を保って作るにはミニチュア宇宙新生させるに等しく、要求の脳スペックが高くなる傾向にある。

最後まで整合性を保ちながら物語を盛り上げ、終極させカタストロフィを見せるというのは

サッカーでいうとハットトリックを全部オーバーヘッドシュートで決めるくらいの高難易度技法であるサッカーよく知らないけど。

 

なので終わり方が雑魚いのは全部単なる作者の技量不足であり、

作者にパニック物の終局地を書ける力量さえあれば問題ないのだ。

そうやって終わらせた作品は数多あるけどそれを当たり前だと受け取ってきた結果、尻すぼみエンドが目立ってきた次第だ。

 

話を戻して、進撃の巨人は初期から最後までのプロットができているという発言が作者本人のインタビューで分かっている。

まり連載開始時点である程度世界を完成させてしまっているのだ。

実際書き始めながら着地点を探しているのではなく既に脳をまわして宇宙構成した後に書いている。

からこそ支離滅裂になったり伏線が回収できなくなったりしないし、本筋の中で意味のない寄り道をせずに本編を進めていっている。

1話1話無駄な話がないのだ。

からこそ面白い

単純に、1話ごとに重要エピソードを詰め込んで読ませてるから面白くないわけがない。

本来昔の週間連載がやっていた毎回読者をハラハラキドキさせるということをやりつつ、

あとから通してみても楽しめるという理想的漫画を描いているだけなのだ

この当たり前のことをどの漫画家も目指しているが大半の作家はそこに至らないが、

連載はじめての作品で既に両立させているという点が驚愕するべきところだろう。

 

一言でいうと

進撃の巨人面白い

2017-04-05

http://anond.hatelabo.jp/20170404154007

FAXって、なんだかんだ言って送信からしたら、電子化されてるより楽なことってあるんだよな。

例えば、ニッチ商品群の注文書をどこかの現場作成して、問屋に流すとする。

A.Fax利用の場合

1.現場で注文書に手で記載 → 2.FAX

B.メールで送る場合

1.現場で注文書に手で記載 → 2. メールに転記 or スキャン → 3. メール書いて添付して送る

C.電子化されている場合の例

1. iPadの注文アプリを起動、注文書新規作成やらやって、入力して送信

アプリ次第ではあるが、1ステップで済むようで、紙より楽にはならない可能性が高い。かつ、端末の維持・管理の手間が発生する。

この中だと、送信からしたら、FAXが一番楽だってなりがち。

また、発注側としては、それほど発注作業を多くやっているわけではない場合や、

注文のシステムアプリを構築したり(何か既存のを利用するにしても)するほどのものでもない場合など、

電子化したほうがオーバーヘッドが大きいとかもありうる。

尚、つい最近SMS送信APIなどを提供しているTwilioが、今更ながらFAX対応するとのニュースがあったくらいなので、

まぁ、相応に需要があって、これから先もなくならないという算段なんだろうな。

2017-02-11

勝手ジャンプ

◎:必ず読む/休載だと残念

○:読む/休載でもまあいいか

△:読むけどあってもなくても可

☓:終了マダ~?

ー:読んでないからどうでもいい

ONE PIECE:◎

ジャンプの稼ぎ頭にして唯一の大黒柱。連載終了の兆しが見えたらジャンプ終了のカウントダウンが始まる。

長期連載なのに物語の着地点は見えずに風呂敷は畳むどこか未だに広がるばかり。

物語には起伏があるため正直ダルいと思うときもあるが盛り上がり時はやはり魅せられる。

だが長期化が進めば進むほどジャンプ寿命がどんどん短くなってくるというジレンマの元となっている作品

準・柱の作品の終了を養分にしてどんどん大きくなっていくジャンプの大樹。

養分にされない作品の登場が望まれるが人気・長期連載のダブル攻撃に耐えられるのってなかなかいない。

僕のヒーローアカデミア:◎

ジャンプ代名詞である友情努力勝利」に無理なくマッチしているジャンプらしい作品

アニメ二期も始めるので絶好調

物語自体高校生活はあと二年あるので展望も明るい。

しか高校生終わったら物語もそこで終わってしま可能性があるのがネック。

卒業後にヒーロアカデミアの看板で行けるのか?

まあ、題名変えてそのままヒーロものでいけばいいんじゃない

ブラッククローバー:◎

魔法主題なのに主人公脳筋とはこれ如何に。まあ、魔法努力はわかりづらいので筋肉でそれをカバーか。

主人公の強みと弱みがハッキリと分かれているのでその分周りのキャラも参戦化しやすく見てて楽しい

逆にいうと主人公が弱みを克服すると一気にオレツエーだけの漫画になってしまいそうで失速してしまいそう。

物語の流れ的には時間的なネックがないため上手く行けば長期化も。

アニメ化も決まり柱になってくれるよう(編集部にも)期待される作品

鬼滅の刃:◎

正直作風は万人受けするものでない。それに物語自体本質は血なまぐさいのでこれまた人を選んでしまう。

だが、ジャンプ代名詞である友情努力勝利」にマッチ・・・(あれ? 友情ちょっとまだ成分低いかも。でも今後増えそう)

しているジャンプらしい作品しかギャグもあるときている。

ギャグは不真面目系ではなく本人はいたって真面目だけど結果としてギャグになるという天然系。

カチッとハマるときはとことんハマる。そして噛めば噛むほど味がでるスルメのような作品

大人気になることは恐らくないけど休載になったら二番目にダメージが高い作品

ハイキュー:○

ジャンプスポーツ部門担当天才肌と根性肌が努力でつながる。これまたジャンプ主題に沿った作品

でも天才肌の人が努力ちゃうと凡人はどうにもならないのでちょっとやめてほしいんですけど。

あとバレーはレシーブするときに手が痛いし突き指もしたしで苦手だったということもありそんなに力を入れて見れない。

それに残念ながらバレーが万人受けするスポーツかっていうと・・・

スポーツ系はそのスポーツに関心がないと難しい面はある。まあ、個人的理由

当然ながら高校生が主役なので終着地が高校生終了になってしまいそうなのがネック。大学生編もアリといえばアリだけど。

火ノ丸相撲:○

ジャンプスポーツ部門担当その2。漢臭い臭い作品。そして力士と言い張れば下半身廻しでも通報されないと知らしめた作品(違

主人公の夢は熱く周りの人間を巻き込んでいく展開はやはり熱い。

だがトーナメント制だとそれ故にある程度展開が読めてしまうのが悩みどころ。

やっぱり主人公チーム補正があるよね となると途端に冷めてしまうからそう見えないように上手く魅せるさじ加減が難しい。

そう納得させる部分が努力過程なのだけどあんまりそれやりすぎると人気が落ちるという悲しさ。

スポーツ系の宿命ですな。

着地点は力士審査を通れるかになるのでそこで物語終了となってしまうのがネック。

背すじをピン!と:○

社交ダンスを題材にとりあげた珍しい作品

何も取り柄がない(と本人が思っている)主人公が何かを成していくという展開はやはり熱い。そして眩しい。・・・年を取ったなぁと実感させられる瞬間でもある。

ただお披露目の舞台ダンス自体に関心がないと見てて辛い。何周もあるとお腹いっぱいになる。

何が凄いのかがイマイチピンと来ないので見ててふーんとなってしまう。社交ダンス舞台を見たことがあればたぶん違うのだろうけど。

マイナースポーツ共感が得にくいことがネックでありますな。

主人公の周りのメンツが凄すぎて後半は埋没してしまったのも残念。

物語が一段落したなーって思ったらいきなり二年後になったので多分来週で連載終わりだろうなー。

あぁ、ONE PIESEの養分になる作品がここにまたひとつ

※終了じゃなかったらゴメンナサイ

約束のネバーランド:○

家畜化されている子供という衝撃的な作品ジャンプしからぬところが注目を集めている模様。

子供なので脳筋的な展開にならず(なりかけたが返り討ち)知略を尽くしてどう出し抜くかを楽しむ作品

まあ、思考自体はちっとも子供じゃないんですけど。

周りの状況がちっとも公開されていないため今後の展開もまったく読めない。

もちろん敵の正体や世界の設定などもあるのだろうけどそこに行く前に連載が終わってしまいそうなドキドキ感もある。

施設編が第一部で逃走編や闘争編まで続ければ面白そうだけどジャンプとしては異色なので人気が持つかは不明

食戟のソーマ:○

ジャンプ食品部門担当物語ベース自体ジャンプ主題に合っているのでそんなに異色感はない。

そして食事をするシーンがエロくなるということを知らしめた作品。さすがto・・・じゃなくて佐伯先生

話の流れ的には作画が綺麗になったミスター味っ子なのだけれども。

女も脱がすが男も脱がす。エロい紳士も腐った淑女も引きつける作品

ただ、最近料理にちと食傷気味。力を込めた料理はたしかに美味そうだけどしょっちゅう食べると飽きるよね。

たまにはゆきひらで出ているような料理ほっこりしたい。クッキングパパは偉大ですなぁ・・・

まあ、題名に「食戟の」が付いている以上バトルもの看板は外せないからどうにもなりませんな。

これも学園卒業と同時に連載が終わりそう。

正直に言うと作者様には18禁の方に戻ってきてほしいなとは思うけれども(ボソ

斉木楠雄のψ難:○

ジャンプギャグ部門担当主人公ツエーものギャグには打ってつけですな。オチも決めやすいし超能力からある意味なんでもアリだし。

まさかアニメ化するとは思ってなかったけど意外と違和感なくてウケた。

一応舞台高校だけれでもギャグ漫画法則で年次は関係ないため人気がなくなったときが終わりどき。そういう意味では制限がない。逆にいえばいつでも終われるということだけど。

悲しいかギャグ漫画大黒柱になることは決してないのだけど(なれて準・柱)無いとそれはそれで困るものなのである

言うなれば親子丼の付け合せででるお新香のようなものだ。

ないとちょっと悲しい。そんな存在

ゆらぎ荘の幽奈さん:○

ジャンプエロ部門担当ToLOVEる主人公が出来る男にしたバージョン

ちなみにこれにエロをつけると完全なエロゲーの出来上がり。むしろそっちを見たいがそれだとジャンプからいなくなってしまう。悩む。

ギャグ漫画ではないので高校生が終わると舞台も終わる。

だが、恋愛系の漫画でもギャグ漫画法則(年度ループ)が起こりうるので人気しだい。

なにせヒロイン幽霊だし。年ループしてもきっとわからない。

・・・ただその場合オチは全員が死んでいたってことになるけれども。

ぼくたちは勉強ができない:○

ジャンプラブコメ部門担当。新連載組。

どっかで見た絵柄の人だなぁと思っていたらマジカルパティエ小咲ちゃんの人だった。

まだ一話だけなのでなんとも言えないが短期間で終わりそうな予感はある。

題名的にどっかでみたようなラノベのようだし。

主題的にも長期的ではないし。10話ぐらいの読み切りで読むとちょうど良さげ。

磯部磯兵衛物語:○

ジャンプギャグ部門江戸担当。かつてのうすた京介枠。安定の巻末。ないと不安になる。

10号では巻末ではなかったのでちょっと驚いた。・・・いや実質ここが巻末だったということなのだろうか。

浮世絵の画風をギャグにするというのは冒険であったと思うけど慣れると何だこの安定ぶりはという感じである

ジャンプには欠かせないが、でも単行本を買うことは決して無い。

銀魂:△~☓

ジャンプのバトル部門ギャグ部門を担ったハイブリッド作品

2~3Pを読んで今日ギャグとして読めばいいのかバトル(シリアス)として読めばいいのかを決定する。

ある意味こち亀のような作品ではあるがこちらの方が逆は下品・・・ん? こち亀別に上品ではないな・・・ゲス作品

現在物語を畳んでいる状態シリアス展開が長いが、シリアス長えよ!と作者が飽きたのかギャグ差し込むようになってきた。

なのでシリアスモードで読んでいるときギャグゲスギャグ差しまれると辛い。

ここでギャグかよ! とジャンプを叩きつけたくなる自分は悪くないとおもう。

青春兵器ナンバーワン:△

ジャンプギャグ部門担当。困ったことばかりする相手フォローするギャグ

まあ、可もなく不可もなく。

ただ、理不尽ギャグはすでに先輩がいるしなぁ・・・

左門くんはサモナー:△

ジャンプギャグ部門ゲス担当主人公ゲスカス。まあオチ主人公がひどい目に合うことがわかっているゆえにそこまで不快にならない。

だが、それゆえに主人公がめずらしく主人公らしい行動をしたとしてもちっとも褒められない。

不良がときおりみせる優しさが異常に高く評価されることはよくあることだけど、主人公ゲスさ故にそれすらない。

え? 主人公ってこんなんだったけ? と物語主人公役割を問い直したくなる作品だが、この物語主人公は間違いなく彼である

レゴラッソ:☓

ジャンプスポーツ部門担当。新連載組。早い終了が待たれる。

スポーツものとして描くのであれば主人公にはそのスポーツに対する圧倒的な「愛」が求められる。

そしてこの作品にはそれが足りなすぎる。正直サッカーやらずにテコンドーやってろよって感じ。

「なぜそのスポーツにハマったか?」の描写はあったが、その後のハマりぐあい描写が足りなすぎる。

キャプテン翼を見習えよ! サッカーの申し子の翼くんでさえオーバーヘッドキックを何度も練習して打てるようになったんだぞ!

憧れの光景を見てやろうと必死にドロドロになってそして出来て嬉しい!って笑顔になってそんな姿を見せらればそりゃこっちも嬉しいよ!

そういった過程もなしに物語を進めているからちっとも楽しめない。導入部がいろいろ足りなかった。そんな作品である

・・・まだ終わってないけど。

歪のアマルガム:☓

ジャンプのバトル部門(化物)担当。新連載組。初回は面白かったが回を繰り返すごとにつまんなくなってきた作品

だが打ち切り決定がなされたであろう回からまた面白くなってきた残念な作品

初回のノリをそのままつなげればよかったのに変にクールダウンした結果面白さも落ちてしまった感がある。

今の展開の勢いを最初からやっていればよかったのに。状況を落ち着かせるのがちょっと早すぎた気がする。

次回作に期待。

デモンズプラン:☓

ジャンプのバトル部門悪魔担当。新連載組。読み切りで終わらせた方がよかったでないか作品

回をます毎に加速度的につまんなくなった作品

たぶん初回ですでに力尽きていたのではなかろうか。話の作り方が週間連載に向いていないのかもしれない。

何が悪いというよりもただただつまらない。

一度そういった目で見てしまうと何をやってもだめである。さっさと畳んで次いった方がいい。

この作品を見ていると週間連載をしている人たちは本当にすごい人達なのだなぁと実感する。

HUNTER×HUNTER

とにかく連載を。言いたいことはただそれだけである

作品自体登場人物であるジンのような作品であるが、帰ってくる場所いつまでもあるとは限らないのだ。

ワールドトリガー

はやく、はやく読みたいよぉぉォォォォ!!!

ONE PIECEのように大黒柱になれる作品ではないが、建物工事には欠かせない基礎のような存在である

その基礎がないってどういうことよ? 建物ラグラきちゃうよ?

早急な復帰が求められるが作者さん体壊しちゃったゆえの休載からなぁ・・・

ワールドトリガーが連載されている限りジャンプを買い続けることをここに誓おう。

・・・◎となったのは19作品中4つだけだった。

え、なにジャンプってここまで落ち込んでるの。

ドラゴンボールとか連載されているときほとんどが◎だったのに。

ほんと早期のワールドトリガー復帰が望まれる!!

・・・ってことを書きたいだけだったのに何この長文。

2017-01-24

キャプテン翼で夢を持った話

久しぶりにキャプテン翼を読んだ。

小学生のころの僕はこれに影響されてサッカーをはじめる訳なのだが、あのころ練習たらこういう技が出来るようになると本格的に思っていたことを思い出した。

オーバーヘッド練習をしては背中を痛めていた。

日向小次郎タイガーショットをしては、足首を痛めていた。

三角飛びをしようとした日には、擦り傷だらけだった。

サッカーボールは友達なので抱いて寝た。

バカだったなぁ。。w

2017-01-19

http://anond.hatelabo.jp/20170119024402

シリコンバレー仕事してますが、全然違います

上とか下じゃなくて、そもそも分かれてないんです。いわゆる開発者設計実装テストまで全部やります日本みたいに上流のSIerがいて、下請けプログラマーがこきつかわれる・・・みたいな構図にはなってません。

上流なんてピンハネしてるだけのオーバーヘッドですし。

2016-11-14

ポリティカルコレクトネスはとっとと滅びてくれ

最近ポリティカルコレクトネス流行ってるらしいが、うんざりしているのでとっとと滅びてほしいと思う

ポリティカルコレクトネスポリコレで略しているうちはいいがPCと略してる奴がちらほらいる

回文脈でパソコンポリティカルコレクトネス判断しないといけない

読むのにオーバーヘッドが発生する

そもそもPCは略し過ぎだろ

レガシープログラマ宣言した変数名かよ

カッコつけて英語読みにしているのは別にいいとして政治的な正しさってなんだよ

ファシズムが主流だったらファシズムに従うのか?

後、ポリコレ棒とかい言葉が出現した時点でポリティカルコレクトネスイメージは失墜しているか

いずれポリコレとか言ってもリベラルが何か言ってるとかいうありがたみしかなくなるだろうよ

いい加減、俺の正義に反しているとか言ったらどうだ

2016-08-02

トヨタN次請け勤務の俺がトヨタカンバン方式とその周辺もろもろの諸問題説明しよう。

トヨタカンバン方式というと、JustInTimeとか物流効率化だとか先進的な言葉が並ぶがトヨタN次請け(N > 1)勤務の俺が説明しよう。

トヨタカンバン方式とは:

1.カンバン(品番が書かれた札)が仕入先に配られる(昔は運転手が納入した際に次の日のカンバンを貰ったそうだが、今は電子的にカンバンを発行する)

2.カンバンの枚数分だけパレット・容器(単位量がある)にカンバンを刺して納入する。基本カンバンが発行された次の日である

 例)品番XXXのカンバン5枚 = 5×パレットごとの運搬数

え、前の日に納入数が決まるの?と思った貴方貴方は真っ当な感覚の持ち主である


カンバン数だけ納入するというのは絶対である(急ぎとて特急料金などない。多い日は4回くらいトラックで走る)。

欠品や不良を連続して出そうものなら、得意先の品質保証会議などでつるし上げられ、自己批判をさせられ、大名行列のように仕入先に視察に来る。

改善なき場合は競合の仕入先に切り替えられる。

ほぼ笑い話だが、2次請け以下がトヨタの手入れを受ける際、1次などが事前にほころびを正しにくる。

しかも単価が非常に安い。部品にもよるだろうが利益10円以下の世界である

これは元請けにとっては非常に都合のいいことである。資材を調達したり、在庫を抱える必要がない。

下請けコストダウンに奔走してくれる。

さて、トヨタとて欠品が出るのは困るので、「内示数」なるものを出す。

これは生産計画で「月にこのくらい出るよ、準備しといてね」というものだ。

むろん見込み数なのでは元請けの都合で変更される。

今年ニュースになった工場爆発や地震などでラインが止まった場合、大量の部材を下請けが持つことになる。

金属製品などは錆が出てオシャカになるので、かなりの損害が出る。

また、従業員派遣社員への休業補償などもしなければならないが、もちろん本丸から保障などない。

せいぜい「低金利で貸し付けるよ」とか「手形を早めに換金してあげるよ」程度である

(実際今年「新型プリウスが出るから用意しとけよ」と内示があったが、2回のライン停止で大幅な生産減となった。

その時に下請け救済案として出されたのが上述である。)

さらに、毎年値下げ協力金なるものがある。これは協力とは言いつつ仕入先間の競合があるので強制力がある。

これがトヨタカンバン方式である

  • 補足

トヨタの一次請けはトヨタの子会社トヨタ主要株主なので本丸と大体同じである

トヨタおよび一次の生産技術品質管理は上に下に膨大な量のエクセルパワポ資料を作りまくるのが仕事

 恐らくSE以上にエクセル方眼紙パワポ芸の達人。

 「ぼくのかんがえたさいきょうのせいさんけいかく」を(紙の上で)実現すべく奮闘している。

 「受注数=生産数というキレイ生産計画以外存在しない!」ものとしている。

タスク管理カンバンなどは全くの勘違いであるトヨタカンバン方式とはきわめてウォーターフォール的な仕組みなのである

・もちろん下請けにもそれなりにメリットはある。

 というか定常的に大量の受注が見込めるのはありがたい(ただし利益率は相当に低い)。

 また少品種多量なので金型替えなどのオーバーヘッドが割りと低い(手広くやろうとするとここが問題となる)。

 世界に誇るトップメーカーのものづくりを担当しているというやりがい品質がよければ表彰されたりする。

・とはいえ2次以下はトヨタ以外の仕事も請け負って活路を見出そうとしないと飼い殺しのまま果てることになる。

 作れば売れた時代はとうに過ぎ、先細りは確実なので今が大きな転換点といえるかもしれない。

 ちょうど2代目、3代目の若社長世代交代の時期なので。

 ちなみに下請け下野する際にはトヨタや1次にどの役職で在籍してたかステータスとなる。

 大抵はこの過程を経て家業を継ぐ。

トヨタ以外の自動車産業現在は大抵かんばん方式である

・なんだかんだトヨタが儲かっていれば愛知県は安泰だと思う。

・いろいろな点で江戸幕府運営方法に近い。徳川出身の地だけある。

・「ほとんどいじめ」という意見があるが、トヨタ原理主義の結果だと思っている(苦しいことには変わりないが)。

【追記】

労働問題を指摘する方がいるがその通り。

過酷現場なので(トヨタ本丸ラインでもブーイングが出る位だから下請けさらに厳しい)人が集まらない。定着率が悪い。

経団連移民政策を支持するのはこの点である

昔はブラジル人労働者ががんばってくれたが、労働者の間にリーマンショック以後給与待遇全然向上しないこと(逆に最近生活費の高騰)に苛立ちが募っている。

労働組合に加入・争議に発展するケースも増加(労働組合もでかいところよりも2次以下の中小を狙ったほうが効くのでターゲットにしてくる)。

そして当然ながらこれは下請け責任でもって処理しなければならない。

【追記2】

今年に入って倒産廃業夜逃げがかなり増えている。

単価は上がらないが、品質要求だけは厳しくなっているので工数的にも人員的にも難しい。

2016-05-22

http://anond.hatelabo.jp/20160521235357

元増田です。トラバありがとう

世の中の絶対数は知りませんが、自分脳内ではもう「ページ遷移しない方がずっと楽に開発できてユーザ体験も向上するのに、敢えてそうしない理由がない」という至極単純な話なので、そこは悩むところではないです。ページを複数作り、<input type="hidden">とかセッション変数とか駆使する面倒ごとは、書かないでいいなら二度と書きたくない。

ユーザー体験がどうかはまあ意見が別れるでしょうからおいておくとして、ずっと楽に開発というのがよくわからないです。普通になんでもいいですけど、ウェブ側のフレームワークでちゃんとしたものを使っていれば別になんでもないことだと思うんですが、具体的にどういう状況を考えられていますか?

プログラムユーザーサイドだけでは完結しなくて、入力チェックとかいいろは絶対にやらないといけないですよね。ということで同じロジック複数書く場面が出てくることが多いと思います。そういう手間も含めたうえで開発が楽になるというのはちょっとよくわからないです。

んー、要するに「別物であるDartCoffeeScriptは許すけど、ES6で書く以上はES6外の独自構文を混ぜるのは許さん」という主張だと解釈したのですが、そういうことですか?

ちょっとここ書き方分かりづらかったかもですが、「ES6で書く以上はES6を使えばいいじゃん」「変な独自拡張を入れてまでJSを使い続ける理由わからん」という2つの疑問を同時に書いたつもりです。

将来長持ちする気がしています

PHPJSP,ASPが通ってきた道に見えてなりません(まあASPはまだ現役ですか。)。

正直その他のアプリケーション(サーバーサイドや、例えばAndroid/iOS開発)でこのような書き方はまずしないので、なぜわざわざ同一ファイルに書きたがるのかがわかりません。(ロードコストを嫌がっているとかですかね?)

テンプレート仮想DOMでもなければJavaScriptでもないので、速度や機能の面でReactがやっていることに遠く及ばないと思います

ええと、テンプレートストリングではなくて、mustacheみたいに十分枯れているテンプレートエンジンでもいいですが、必要かどうかは別として確かに機能豊富さはどうかはちょっとわかりません。

速度に関しては、実際みんな早いと言っていますがこの手の速度神話JSにかぎらず昔からちゃんと前提と状況を考えなくてはいけなくて、(例えばJavaは重い!とか関数呼び出しはオーバーヘッド!とか仮想関数は使うな!とか)例えばさっとぐぐるとこんなものが出てきました。

http://www.stefankrause.net/wp/?p=283

まあよくわかりませんが、結局あんまいじらないのが一番良いという当たり障りない結論になってしまいませんか?(あと原理的に生のDOM操作するのよりも早くなりようがない気がするんですがどうなんですかね??)

保守性に関して言うと、Reactは典型的な「ひとつの事だけをとても上手くやる」系のライブラリです。考え方のコツさえ掴めば、記憶すべき要素はjQueryやAngularと比べても圧倒的に少なく、むしろそこらのテンプレートエンジンを覚える方が面倒なくらいです。10年後に見ても何をやっていたのか30分で思い出したいというのであれば、むしろAngularとかよりReactを採用すべきだと思います

ごめんなさい、Reactまわりのエコシステム全体も含めた時を意味たかったです。leftpad騒動とかもあったように、なんかまだちょっと不安がある感じがします。偏見でしょうかね。。

2016-04-29

http://anond.hatelabo.jp/20160429123338

ヨーロッパ在住で、かなり使い倒していたけど便利でサラリーマンから学生まで幅広く使っていたな。でも儲かるものではないので、どこも完全に税金で持ち出しでその代わりに公害を減らしたり、他の公共交通へのオーバーヘッドを減らすみたいな計算してやってたみたいだけど。

2015-05-02

最古のプログラマブル機械プログラムによって動作の変化を制御できる機械)としては、1206年にアル=ジャザリが作った二足歩行ロボットがあると言われている。アル・ジャザリのロボットは、ボートに4体の演奏人形が乗ったもので、宮廷パーティで池に浮かべて音楽演奏したと言われている。プログラムカムにあり、それによって小さなてこを押して、打楽器演奏する。カムは実際には円筒ペグが突き刺された形であり、このペグの配置でプログラミングし、演奏パターンを変更した[1]。

1801年に開発されたジャカード織機がプログラマブル機械起源とされることが多い。この機械は、穴を開けた一連の厚紙(パンチカードの原型)を使った。穴の配列が布を織る際のパターン対応している。従って、カードを入れ替えることで全く異なる布を織ることができた。1830年ごろには、チャールズ・バベッジがパンチカードを使った解析機関を考案した。

このような先駆者発明さら進化させたのがハーマン・ホレリスであり、1896年にタビュレイティング・マシンカンパニー(Tabulating Machine Company、後のIBM) を設立した。彼はホレリス式パンチカード、タビュレーティングマシンキーパンチ機などを発明した。これらの発明情報処理産業の基礎となったのである1906年には、タビュレーティングマシンプラグボードを追加することで、組み替えれば様々な仕事ができるようになった。これがプログラミングへの第一歩である1940年代には、プラグボードによるプログラマブル機械が各種登場していた。初期のコンピュータにもプラグボードプログラムを組むものがあった。

パンチカードのつまった箱。プログラムデッキがいくつかある。フォン=ノイマンアーキテクチャ発明により、プログラムコンピュータメモリに格納できるようになった。初期のプログラム特定機械命令をそのまま並べて作られ、二進法記述されることが多かった。初期のコンピュータでは、電気的配線を変更したり、トグルスイッチなどで機械語を直接コンピュータ入力することで、プログラミングが行われた。しかし、機械語命令人間にとって扱いにくく、代わりに機械語命令ニーモニックとよばれる略語を割り当てた、アセンブリ言語が開発され、プログラマ命令をテキスト形式で記述できるようになった。アセンブリ言語は、コンピュータCPUによって種類が異なるため、アセンブリ言語でかかれたプログラムは、他機種のコンピュータで利用することができなかった。また、単純な処理をアセンブリ言語記述する場合にも、基本的な処理命令を大量に記述する必要があった。

そこで、特定コンピュータ依存しない記述方法で、処理の内容をより抽象的に記述するためのプログラミング言語が開発された。そして、プログラミング言語によって記述されたプログラムを、コンパイラを利用して機械語翻訳することで、実行プログラム作成することが一般的になった。1954年最初プログラミング言語の1つであるFORTRANが開発された。これにより、演算を直接数式のように記述できるようになった(例えば、Y = X*2 + 5*X + 9)。このプログラム記述(あるいは「ソース」)はコンパイラと呼ばれる特別プログラム機械命令に変換される。他にも様々な言語が開発された(ビジネス用途COBOLなど)。プログラム入力は依然としてパンチカードやさん孔テープで行われていた。1960年代後半、記憶装置や端末の価格が低下してきたことにより、キーボードから直接コンピュータプログラム入力できるようになってきた。このため、修正が容易に行えるようテキストエディタが開発された。プログラミング言語の処理方式は、コンパイラ方式インタプリタ方式に分類される。

コンピュータ能力は時と共に飛躍的な進化を遂げた。このため、より抽象化されたプログラミング言語が開発されるようになっていった。抽象化レベルの高い言語オーバーヘッドも大きいが、コンピュータ自体の性能の進化が激しいため、多少オーバーヘッドが増えても以前よりも高性能な動作が実現された。このような抽象化レベルの高い言語の利点は、習得が容易であることと、プログラム作成時間が短縮されることであるしかしそれでも、巨大で複雑なプログラムや、高速性が何よりも重視されるプログラムでは、現在でも比較的低レベル言語を使っている。

20世紀後半を通して、先進国ではプログラマが魅力的な職業の1つとされてきた。しかし、発展途上国の安い労働力プログラミングに利用する傾向が強まっている。この傾向がどれだけ続くのか、それによってどのような影響があるのかは未知数である

2015-04-10

最近システムソフトウェア開発のトレンドが分からない

10年位前、上位のサイトから電文を受け取り下位のサイトに再配信するプログラムを、Linux上にC言語実装する仕事を引き受け、死ぬ思いで片付けた。

その時にお世話になったのが「UNIXネットワークプログラミング」という本。

この本、POSIX準拠OS(要するにLinuxなどのUNIX系OS)におけるシステムプログラミングのノウハウに関しては名著、いやバイブルと言っていい。


しかし、である

この本は今や絶版なのだ

名著が絶版になる理由は色々あるだろうが、この本に限って言えばもはやそういう時代じゃない、そういう低レベル実装トレンドじゃないということなのだろう。


でも、そしたら「決して遅延が許されない再配信プログラム」は、一体何をどう使って作るんだ?

JavaPerl?全くイメージが湧かない。

プロセス間通信やスレッド制御、更にはシグナルも使い、それらが高速で動作しないといけない(いやスレッドは難しすぎて結局使わなかったけど)システムで、そんなオーバーヘッドが高い言語は使えないと思うのだが。

それらを解決できる気の利いたライブラリフレームワークもなさそうだし。

なので、同じ理由PythonRubyダメだろう。

そうなると、メジャーどころの言語は軒並み使えないじゃん。

或いは回線スイッチを高性能にして、サーバリソースも上げられるだけ上げるというように、インフラ側の強化で解決しちゃうとか?

それとも、そもそもそんな仕事がもはや存在しないってこと?

2014-11-10

http://anond.hatelabo.jp/20141110015137

そうなんよね。金がありあまっててミッションクリティカル携帯キャリアならではって感じではあったのでちょっと記事アドバイスとしては適切じゃなかったかも。

記事で言ってたように根幹のチェックして検収OKでもいいとおもった。そのシステムトレードオフどれくらい許容出来るかって感じで割り切りでいいと思う。

 

まるぱくりだけどKent beckトレードオフの制約を貼っとく(TDD議論で出てたものだけど受け入れテストにも適用できるとおもう)。

 

■ 頻度:どれくらいの頻度でフィードバックをもらいたいか?

■ 精度:レッド/グリーンシグナルに求める精度はどれくらいか?

オーバーヘッド:どれくらいのコストを費やせるか?

寿命:存続の見込みと期間の両方を考慮したソフトウェア寿命はどれくらいか?

2014-06-04

http://anond.hatelabo.jp/20140604133746

どうでもいいけことで申し訳ないんだが・・・

C#ならいいのかもしれんが、フットプリント的にどうなのよ。

現実問題 中身を実装するとこういうことだよねぇ。

class {
 bool nullable,
 bool value,

 bool operator == (NULL){
    if(nullable){
       return true;
     }
     return false;
  }
 bool operator == (bool){
    if(nullable){
       throw;
    }
    if(value){
       true;
     }
     return false;
  }

というオーバーヘッドフットプリントを許容してまでクラス化するようなものなんだろうか?

便利そうだけど すっげぇ 気になる。

C#からいいような気もするが、 bool演算つのために 関数コールして ifステート複数回判定するのはオーバーヘッドが大きすぎる気がする。

小さいアジャイルプログラム向き なのかね。

2014-02-26

この時代FTPなんて使いどころなどない。

http://b.hatena.ne.jp/entry/wp-d.org/2014/02/26/5709/

deployでGITの是非を語るならまだ分かるが

まるで、FTPに使いどころがあるような書き方をしてるのがいて

ブコメが恐怖に満ちてたので書く。

この時代FTPなんて使いどころがない。


理由

認証ユーザ名とパスワードは平文で送られる。

 まずなによりもこれ。FTP使うのは、公開共有フォルダと同じレベル

FTPなんて立てなくても、SSH/SCP/SFTPが確実にあいてる。

 あえてFTPサーバー立ててる時点で相当怪しい。確実にアホな理由。ユーザーが使えないからとか


FTPSは新規に使うモノじゃない。

 FTPS意識するような人なら、既にSSH/SFTPなり使ってる。

 FTPSはレガシーFTPに対して、応急処置でう使うモノであり、新規採用なんてありえない。

FTPというステートフルなプロトコルは、プログラムには本来扱いにくい

 だから、いまどきのデプロイにはFTPなんて一言もない。

 なのにあえてFTP立ててる時点で相当怪しい。その辺から離れた世界匂いしかしない。 

・外部データ連携は、APiがいくらでも空いてる。

 糞SIヤーさんでもいまどきしないからね?FTPなんて。ね?

パブリックファイル公開もいまどきあんまり意味がない

 FTPHTTPオーバーヘッドとか、このブロードバンド死語時代に何言ってるのよ?

 というかね、転送効率がそこまでシビアだったら別な方法選択するからありえない。

 あとさー。いまだにデカファイルFTPあけてファイル配るみたいなことやってるから

 勘違いする馬鹿がいっぱいいると思うの、そろそろやめていいよ。誰も困らないから

・アホなユーザーが使えるのはFTP

 アホなユーザーFTP利用させる==公開共有フォルダ化したどころかウィルスばら撒く温床にまでなった。

 というかGumblarのせいでこの世からFTP駆逐されたはずだが、

 なぜこの時代になってFTPなんて言葉が出るの?

なんで時と場合を考えろみたいな話になってるの?

時と場合なんてFTPにもうないはずなのだ

なんなの。なにこれすごくわい

PHP4とか来年流行るんじゃないの。

2013-12-20

PHP生産性の高さはやばい

自分JavaからPHPに入ったので、最初はとにかくクソな言語だと思っていた。

配列仕様がとにかくひどい。

Copy On Writeという謎仕様なのに加え、すべての配列が常に「順序付きマップ」という謎なものになっている。ただ単にマップ連想配列)を使いたいだけの場合でも、なぜが挿入順でキーが順序付けされているという仕様で、内部でどんだけオーバーヘッドがあるんだろうと考えると、それだけでストレスが溜まったものだ。

あと、何も宣言せず、$array['key1']['key2'] = 1としただけで、要素が1の配列が2つ作られる。これも気持ち悪い。この仕様のせいで、どれだけ見つけづらいバグが誘発されているかと思うと、それだけで痒くなった。

そんな風に思いながら、2年近く仕事をして、そこそこ大規模なシステムを一人で書けるようになった。それでも、PHPをやっている引け目のようなものはなくならなかった。

ただ、そんな思いのまま「意識が高い」系のプログラマが集まる会社に移り、RubyだとかPythonだとかScalaだとかが書けるようになった上で、あらためてPHPを見ると、その仕様が優れていることを痛感させられる。同じことを書こうとしたときの行数が圧倒的に少ないのだ。配列についてもたしかに、オーバーヘッドはあるが、実際にはパフォーマンスに影響することは少なく、それを通して得られる開発効率は半端じゃない。他の言語だといくつものライブラリを介して可能になることが、単にサーバファイルを置くだけで可能になるというのは、特に小規模なプロジェクトでは生産性の高さに直結する。

もちろん、プロセススレッドデータ共有の仕組みが前時代的で、パフォーマンス効率は高くない。言語仕様が、ノンブロッキングな処理に向いていないなど、用途によっては致命的な欠点もないわけではない。ただ、きちんと言語特性を理解するレベルで使ったことがないのに、仕様的に他の言語と変わっているところを挙げて、「PHPを使うのはレベルの低いエンジニア」というのは、そろそろ終わりにした方が良いと思う。

あと、話は変わるが「意識が高い系エンジニア」は、システムを開発する上で人件費採用コストの問題をあまり考えていないのではないかと思う。たとえば、ビジネスが急に大きくなって、取り急ぎ100人エンジニアを雇おうとなったときPHPならとりあえず書ける人間をかき集めやすい。RubyPythonで同じことをやると採用にかかる時間が大幅に伸びるか、人件費が大幅にアップするかになるだろう。これは、一緒に働くエンジニア所与の条件として見るか、お金を払って雇うべきダイナミックなものとして見るかの違うじゃないかと思う。

2013-11-10

無能プログラマの特徴


これ3つくらい当てはまったら無能なw

http://anond.hatelabo.jp/20131109185658

数学分かってても実装力が低い俺みたいなタイプ無能を捉えられてないっつーか。

特定経験依存せずに一般化するのは難しいが幾つか、実装力、問題解決力向上に絶対に外せない基本要素を追加しといたw

id:FTTH 「こーいうのを真に受ける/マジレスする」追加な

タンコガイを無能扱いするとか素晴らしい能力

2013-02-25

かいけど

Xbox360はGDDR「3」ね。

あとPCI-Eに刺すGPU元増田が書いてるように転送がむっちゃ遅くなるからCPUマザーボードGPU全部で包括的革新が起きないとPS4の構成に同じ価格帯で並ぶには5年程度じゃギリギリ無理。

GPU DirectもあくまでマルチGPU間の並列処理データ受け渡しのオーバーヘッドを無くす技術から普通GPGPU処理でCPU・メインメモリ頼りの構図はnVidiaけが頑張っても覆せない。

PS4や次世代箱に勝てる構成が近い将来に来るとしたらAMDのHSAかIntelXeon Phi統合CPUハイエンド向けに作られた時だけじゃないか

http://anond.hatelabo.jp/20130225110346

2013-02-23

ぼくのかんがえたPS4分析 - SONY製造業としての業から解き放たれたPS4

http://anond.hatelabo.jp/20130223090512

に触発されて俺なりのPS4分析をしてみた。

ハードウエア製造業の夢より、ソフトウエアクリエイタの夢 - ハードからソフトへと言う現実

一言で言うと↑これがPS4だと思う。

三行でまとめると

PSのビジネスモデルを振り返ってみるのだが、この切り口から行くとPSはSONY半導体戦略、そしてSONY製造業と言う性質とと切っても切れない関係がある。

利用上の注意

なおすべて妄想となっておりますので、これを真に受けて被った損害などについては一切責任を取れません。皆様におかれましてはその旨ご了解のうえご覧いただけますよう、よろしくお願いいたします。ご協力頂けない場合につきましては、いい歳こいたアラフォーの髭ヅラ男が涙目になると言う非常にウザイ状況が発生することとなり、誰も得をしません。ご理解とご協力をお願いいたします。

PSの歴史SONY戦略について

初代PSとそれがもたらしたもの

SONYゲーム機を一緒につくろうと言って任天堂に近づいたものの交渉が決裂してできあがったのがPSであったわけだがこれが大ヒット。

さらにPSでは、内部で使われている半導体を自社設計・自社かそれに近いFabで作る事によって

など副次的な効果もあり、さらに「SONYの旗艦」といったイメージを作り上げることができた。この他に、CD-ROMを手がける部門や、SONYのCDプレス工場部門等々、PS景気により、直接的なPSによって生み出される効果以外に、PSという揺るぎない需要存在する事で、設備投資などに積極的になれたといった効果がうまれた。

PS2では完璧芸術品であったDreamcastを殺すほど大成功

初代は始めどこまで意図されいたかは不明だが2台目ではそれらの経験が生かされる事となりより強化された。まず一番は半導体工場で有り、旺盛なその需要と、それによって得られた利益投資に回し新プロセスを開発、シュリンクすることによって最終的な黒字を目指すことで赤字で販売をスタートすることとなる。

ゲームハード赤字でも、ソフトが売れれば黒字。こんなの当たり前だろ、と言う話であるが、総合情報機器メーカであるSONYでは少し事情が異なる。これは、ソフトウエアライセンス事業による利益によって、間接的に半導体生産設備投資を補填すると言う形を意味する。もちろんそれ以外にもSONYの製造部門にもPS2赤字でも販売すると言う行為によってもたらされる間接的な利益が流れた。

ご存じの通り、PSは我が愛する芸術品たる至高のゲーム機Dreamcastを完膚なきまで叩きのめし世界最高の企業セガプラットフォームから引きずり卸しパチンコ屋に買われる所まで追い込む等大成功をとげた。そしてゲーム機生産により、SONY製造業部門を引っ張っていくという当初の見込みは大成功した。

それをさらに強化したのがPS3、そしてCellであった。

PS3Cell BE が見た夢

PS3時代になると、パソコンの旺盛な需要の元、急速に進化した集積回路は、プロセッサの新規開発コストさら半導体プロセス開発に必要な資金が膨大に膨らむという現実に、様々な企業が立ち向かうよう時代が来ていた。世界の巨人たるIntelと、それ以外という構図が生まれ、世界中でFabの統廃合が進んでいた。

その中で目をつけられたのがゲーム機という存在であるパソコンに対抗できるほどの膨大な需要を生むゲーム機は、薄利という性質を持ちながらも数が出るため、生産設備を拡大しやすプロセス開発の資金を捻出する事に有利であった。さらSONYは、ゲームハードウエアが、当時のパソコンなどに比べて圧倒的に高い性能を持っていなければ存在価値が無い、と言う観念を持っていた。これはかつて任天堂がもっていた思想であった。

さらIBMなどの思惑とも一致、開発がされたのがCell B.E.であり、この存在PS3を生んだ。そう、ここまで来てSONYは、半導体のためにゲーム機デザインしたのである

もちろんこの説にはいろいろな異論はある。しかし俺は順序としては、ソニーグループ全体の長期的な戦略にPSが生む半導体工場の増設という戦略が大規模に組み込まれていたのは間違いないのでは無いかとみている。そこで完成したマシンは、化け物であった。現在まで続く潮流であるGPGPU的な動作もこなCell B.Eがもたらす高性能と、高い拡張性を備え、既にゲーム機では無いとまで言わしめるものができた。この性能は当時の最新鋭コンピュータを大幅に上回るものであった。

しかし……。GPGPU概念は早すぎた。性能を引き出すことが、当人であるSONYでも難しかったのである。そしてこれはミドルウエアや開発ツールの乏しさにも繋がる。そのためスタートアップに失敗した。この失敗は、PSがゲーム機として優れていなかった、あるいは、他者装置に負けた、と言う意味で失敗では無い。製造業としてのSONYが、自社の思惑通りに事を運べなかったと言う事での失敗である

ハードウエアの夢、ソフトウエアの夢

結果SONYは、PS3需要を当て込んだ生産設備リストラ・売却するなどの対処をを迫られる。さら韓国勢などの追い上げ、AV市場の急速な変化、SONY本体の体力の低下、パソコン高速化などにも影響を受けることになる。

PS3のものは、OSの改良、ミドルウエアや開発ツールの向上などにゆっくりではあるが立ち上がってきたが、製造業としてのSONYPS3に期待した効果は得られず、ハードウエア屋、製造業がみた夢はここに破れた。

さら時代は動き、集積回路は、Intelプロセスで1世代以上先を行き、それ以外はすべて後から追うという構図が完全に定着してしまった。SONYも、SONY半導体と言えば、集積回路ではなく画像素子、と言う時代が来て久しい。世界中半導体製造業者の統廃合は進み、国内半導体産業は衰退した。新プロセス開発の難易度や、集積回路の大規模化から来る開発コストの上昇はいかんともしがたくなっていた。

ゲーム必要とするスペックはもはや飽和している。少しでもリアルに、少しでも高性能にと言う方面はすでにマニアのものだけになってしまい、それら需要だけで、そのとき販売されているパソコンを上回る高性能チップを開発、載せるコストを満たすことはできなくなっていた。具体的に言えば、ウルトラハイスペックの、GeForece GTX SLIクラスにも勝ちうるGPUを、専用設計オーバーヘッドを極力少なくすることができるとはいえ新規設計することが難しくなっていたのであるさらにはゲーム機業界ではスペック競争を離れた任天堂Wii、あるいはDSを生み出し、ケータイ、そしてスマフォとと言う存在カジュアルゲーム市場をかっさらうようになった。特に日本では据え置きゲーム機リビングルームに置かれ、パーソナルな空間に置いてゲーム機携帯ゲーム機になったのである

そして決定的だったのが、ゲームエンジンの躍進と越境であろう。従来はゲームエンジン製作環境ゲーム会社門外不出のものであった。しかしそれらが会社を通じて流通し始め、さらには専門業者も現れるようになったのである

家庭用ゲーム機と言えば、ゲーム機の性能を引き出すためにソフトごとにアセンブラ最適化チューニングを施す。それを行っても常に動作が一定になることがメリットとして、パソコンに比べてゲームは常に一定の動作をすることが担保できるためにゲーム製作に専念することができた。しかし、パソコンは十分に高性能になった。家庭用ゲーム機も十分に高性能になった。その結果、チューニングを行わなくてもそこそこの画面が作れるようになってきたのである。そこで余った能力ゲームエンジンオーバーヘッドを許容するようになり、ゲームエンジンの躍進に繋がった。さらゲームエンジンプラットフォーム間の差異すら吸収し始めた。あるゲームエンジン採用すれば、あまり手間をかけること無く、パソコン版、PS版、XBOX版、Wii版と複数プラットフォームで出せるようになったのである。これは、ゲームエンジンが新たなるゲーミングプラットフォームとして君臨する可能性を示唆していた。

しかし、チューニングなどといった、ユーザとは直接関係の無い部分に手間をかける必要が無く、作ったゲームがどこでも動く。これはクリエイタとしては非常にありがたい事なのでは無いか

ビジネス書に出てくる例えがある。ユーザねじ回しが欲しいのでは無い。ねじを回したいのである。同じように、客はゲームがしたい、もっといえば楽しいことがしたいのであって、別にゲーム機が欲しいわけでは無いのであるクリエイタはゲームを作りたいのであって、ゲームハードウエアを使いたいわけでは無いのである。ここに合致したのがクロスプラットフォームゲームエンジンであり、そしてこれらはクリエイタに作りやす環境提供し始めた。さらゲームエンジンは新たに現れたライバルであるタブレット/スマートフォンにも対応している。

しかゲームエンジンの躍進は、プラットフォームビジネス崩壊意味したし、PS3は性能を引き出すには高いレベルの専門的チューニング必要であった。しかゲームエンジンはそこにコストを払う事を選択せず、PS3は高い性能を持ちながらも、それ以外のあまり高性能ではないプラットフォームとほぼ同等、せいぜい高解像度テクスチャーに入れ替えられた程度のゲームしか提供されない、と言った事が発生するようになっていた。

ソフトウエアの夢が花開くのがPS4,PSVita

そしてPS4が出た。

PS4は有り体に言って、x86-64アーキテクチャコンピュータに、OpenGL/CL対応GPUを搭載した、本質的にはそこらのパソコンと変わらない構成である

さらに言えば、最新のCorei7+GeForce GTX…と行かなくとも、そこらのパソコンに較べ、性能は高くない。しかし、根本的にゲーム専用機が持つ、汎用パソコンには無い特徴

を備えている。さらには、GPUを扱いにくくする要因の一つとして上げられる、GPUCPUメモリ転送をほぼ考えなくて良いと言う仕様を打ち出してきた。これはCellCPUプログラミングが分断され、非常に開発を困難にしていたPS3反省ダイレクトに生かしてきたと考えられる。これはAMDが出していたコンセプトだ、と話題に上がるが、あくまでもパソコンの話であって、ゲーム機の分野では少なくとも、PS2プログラミングが困難な部分を、高速なバスで繋ぐことで隠蔽するよな仕様であったように記憶している。

さらx86-64アーキテクチャにしたことで、ゲームエンジンがPC向けエンジンの次に、素早くPSにも対応できる素地を整えた。Power向けに施す必要のあるチューニング不要にしたのである。従来はパソコンで開発されたクロスプラットフォームゲームは、パソコン向けと、家庭用ゲーム機向けの2種類作られた。そして家庭用ゲーム機向けは往々にして、ターゲットとなるハードウエアの中で一番性能の低いところに合わせたデータで作られた。平たく言えばPS3の方がXBOX360よりもはるか映像表現は優れているのに(※ただし使いこなせれば) XBOX360との差異はテクスチャムービー解像度程度の違いだけになってしまう事を意味していた。しかx86-64にしたことで、家庭用ゲーム機向けに統一してダウングレードされたデータからPS版を生成させるのではなく、パソコン向けのデータから生成させた方が早いと言う状況を作り出し、他の家庭用ゲーム機にくらべてアドバンテージを得ようとしているのでは無いだろうか。これはPS VitaARM採用したことも同じ事である

さらに、SONYは、PSVitaから進めてきた戦略として、自社による強力にプラットフォーム感の差異を吸収するミドルウエア群…これはゲームエンジンと読んでも良いのかも知れないが…を提供してくるだろう。x86ならば従来の資産を生かすこともできるし、世の中に出ているコンピュータ向けのライブラリも利用できる。急速に開発しやす環境を立ち上げているのではないだろうか。これはゲームエンジンにより脅かされる、プラットフォームビジネスへの対抗措置でもあるだろう。

これにより「雑事に捕らわれること無く、ゲームの楽しさ・表現のものに専念する」と言うクリエイタの夢を叶えるハードウエア、それがPS4であろうと思う。

平たく行ってしまうと、自社の半導体商売が死んだことにより、その死絡みから解き放たれたPSは、クリエイタ主導でゲームを作ると言う根本に立ち返って作ったのがPS4だ、と言う話である

しかしこれだとハードウエア製造業の夢はどうなってしまうのだろうか?そしてユーザ別にクリエイタの夢などはどうでもいい。下手をすると高性能なハードウエアを所有していると言う欲を満たせなくなる分だけこちらの方がまずいかも知れない。それをどうカバーするのか?と言う話になる。

「夢」PS4

ハードウエア/製造業の夢はどうなるのか

SONYは、次世代戦略として明らかにソフトウエア重視に舵を切っている。SONYは今、収支から見ると製造業では無く金融業であるが、その次に利益を生み出しているのは音楽映像ソフト部門とゲーム部門である

まずはここを潰してしまっては会社として立ち行かなくなる。それはまずい。ではどうするかというと、従来の「製造業としてのSONYを強くするために、PSの需要を利用する」のではなく「コンテンツ・製造複合体としてのSONYの核にPSを据え、関連商品を生み出す形で恩恵を得る」と言う形に舵を切ってくることになる。PS3でも一部行われているが、たとえばPSのリモートプレイを可能にするパソコンタブレット、PSを再生装置としてコンテンツ供給できるメディアサーバといった具合である

しかしこれらに対応させるために大切なPS本体の魅力を失わせては困ると言う事は強く意識されなければならないし、意識されていくだろうと思う。

ユーザの夢はどうなるのか

ユーザの夢は、将来的には作りやすゲームプラットフォームが生み出す新しいコンテンツという形で満たされることになるだろうが、直近では、ソーシャルへの展開という形で示されていると思う。将来的にはいかにコンテンツを集められるかと言う事にかかっている。が、ぶっちゃけていうとユーザから見たら、これほど夢の無い話は無いと言わざるをえない。

今回発表されたタイトルデモなどは実際にはチャンピオンで有り、実際にプレイして得られるのはPS3とそれほど感覚的に、革新的に良くなったと感じる部分は薄いと思う。この点で、PS4は、PS3と実働コンテンツはそれほど変わらないと思っている。マイナーバージョンアップ程度。パソコンWindows XPで評価が固まったようなものである。これはおそらく次に発表される新型Xboxでも同じだ。任天堂は少し別格の応えを出したが苦戦している。

結論 またしてもセガは早すぎた

かつてセガが出した芸術品とも言える至高のゲーム機DreamcastOSWindows CEを搭載した。プロセッサこそ独自であったがそれは当時のWIndows CEではあたりまえであり、むしろそこにWindowsと言う汎用のソフトウエアを利用したことで非常にゲームが開発しやすく、PCゲーム移植やす環境を作り上げた。それらはアーケードのnaomiプラットフォームや、ワンチップで埋め込まれたパチンコなどで今でも生き続ける。

任天堂WiiUコントローラに画面をつけDreamcastに追いついたように、SONYは、PS4で作りやすゲーム機という点で追いついたと言える。

またしてもセガは早すぎた。時代セガに追いついていなかったのであるDreamcastはその名の通り「夢を投げる」存在であったのだ。

2013-01-18

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

見出しはこれ http://anond.hatelabo.jp/20121219191602

UNIX

http://toro.2ch.net/test/read.cgi/unix/1288765389/232

232 :名無しさんお腹いっぱい。:2012/03/25(日) 15:05:26.72
今月はじめ、職場に新しいPC(Pentium4結構ハイエンド構成)が入りました。 
多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析シミュレーションなど行う必要がありOSオープン系を採用するのは 
聞いていたのですが、搬入されたPCのダンホール箱に乗っかっていたのは 
UNIXインストールパッケージでした。 

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

デバイスドライバがない、コマンドが変・オプションがない、X環境が古い、 
今の奴は日本語入力大丈夫なのか(Wnn/Canna/kinput2)、将来の64bit移行はどうなのか、 
今時のネット必須flashプラグイン存在するのか不安はつきませんし、 
非メジャーなのでネット上の情報も少なく調べるのも大変です。 
おそらく導入に際して、大学など教育機関最初にそれに触れて刷りこまれた人間強気知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 

昔、当時、唯一CADなどのエンジニアリング環境が充実していたUNIX大学など 
教育機関に浸透していて、日本UNIX界に多くのバカを輩出しました。 

これから私は、おそらくそういうバカが、makeしてもemacsが入らない、 
TeXが入らない、コンソールでEUCは使えないのか、Rubyが使えないのかなどと、 
サバ管気取りの偏ったどうでもいい我侭を言い出し、(だから鯖にするんじゃねーよ、 
鯖の常識で話すなつーのに)それと戦わなければならないのでしょう。 
そして時代によって決着している、過去10年のUNIX界隈のくだらないそれらの議論が 
再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 

だからお願いです。教育現場ではPlamoでもDebianでもRedHatでもKondaraでも 
Slackwareでもなんでもいいですがメジャーかつ現行のLinuxにしてください。 

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

NFS

http://toro.2ch.net/test/read.cgi/unix/1355909018/4

4 :名無しさんお腹いっぱい。:2012/12/19(水) 18:44:07.79
今月はじめ、職場に新しいPC(Core i7結構ハイエンド構成)が入りました。 
多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析シミュレーションなど行う必要があり、複数マシンファイルを共有するのは 
聞いていたのですが、起動したマシンの/etc/fstabの項目に書かれていたのは 
nfsという文字でした。 

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

ファイルロックすると刺さる、ファイルを消したのに.nfsXXXが残る、 
今の奴はACL大丈夫なのか、ファイルのCapabilityに対応してるのか、 
今時のLAN上で使ってもセキュリティ大丈夫なのか不安はつきませんし、 
ユーザーが減ってるのでネット上の情報も少なく調べるのも大変です。 
おそらく導入に際して、大学など教育機関最初にそれに触れてすりこまれた人間強気知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 

昔、当時、唯一ローカルディスクネットワーク上かの区別なく透過的にファイルアクセスできたNFS大学など教育機関に浸透していて、日本ストレージ界に 
多くのバカが輩出しました。 

これから私は、おそらくそういうバカが、ファイルに書き込んだら所有者がnobodyに 
なっちゃったよとか、タイムスタンプがずれるよとか、NFSv4にしたらマウント 
できなくなったよとか、TCPよりUDPの方がオーバーヘッドが無い分速いはずだよね 
などと、鯖管気取りの偏ったどうでもいい我侭を言いだし、 
(だからNFS鯖にするんじゃねーよ)それと戦わなければならないのでしょう。 
そして時代によって決着している、過去25年のNFS界隈のくだらないそれらの議論が 
再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 

だからお願いです。教育現場ではSambaでもNetatalkでもFTPでもなんでもいいですが 
安定してユーザーが多いファイル共有システムにしてください。 

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

FreeBSD

http://toro.2ch.net/test/read.cgi/unix/1351627596/3

3 :名無しさんお腹いっぱい。:2012/10/31(水) 10:57:28.82
今月はじめ、職場に新しいPC(Core i7結構ハイエンド構成)が入りました。 
多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析シミュレーションなど行う必要がありOSに*BSD採用するのは聞いていたのですが、 
搬入されたPCのダンホール箱に乗っかっていたのはFreeBSDインストールパッケージ 
でした。 

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

カーネルが変、日本語環境がない、ソフトが変・揃ってない、今の奴は 
日本語文字コード大丈夫なのか(utf-8)、x86_64環境大丈夫なのか、 
今時のネットに繋いでもセキュリティ大丈夫なのか不安はつきませんし、 
非メジャーなのでネット上の情報も少なく調べるのも大変です。 
おそらく導入に際して、大学など教育機関最初にそれに触れてすりこまれた人間強気知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 

昔、当時、唯一PC98環境が充実していたFreeBSD大学など教育機関に浸透していて、 
日本FreeBSD界に多くのバカが輩出しました。 

これから私は、おそらくそういうバカが、ポーツ(笑)emacsが入らない、 
TeXが入らない、コンソールでEUCは使えないのか、Rubyが使えないのかとかなどと、 
鯖管気取りの偏ったどうでもいい我侭をいいだし、(だから鯖にするんじゃねーよ、 
鯖の常識で話すなつーのに)それと戦わなければならないのでしょう。 
そして時代によって決着している、過去20年のFreeBSD界隈のくだらないそれらの議論が 
再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 

だからお願いです。教育現場ではUbuntuでもdebianでもFedoraでもRHELでも 
OpenSUSEでもなんでもいいですがメジャーかつ現行のLinuxにしてください。 

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

SPARC

http://toro.2ch.net/test/read.cgi/unix/1209056071/887

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

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

長くなるバイナリーコード奇数アドレスワードアクセス不可、使いにくい 
レジスタウィンドウ、今時の素早いコンテキストスイッチ対応できるのか不安は 
つきませんし、今の若者はこんなCPU使わないので人材も少なくソフト開発も大変です。 
おそらく導入に際して、大学など教育機関最初SPARCに触れて刷りこまれた人間強気知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 

昔、当時、32bitCPUでRISCでM68K系よりも高速で動作したSPARC大学など教育機関に浸透していて、日本CPU界に多くのバカが輩出しました。 

これから私は、おそらくそういうバカが、16bitイミーディエイト値すら1命令でロード 
できかないのかよとか、関数呼出しのたびになんで約100バイトスタックフレームが 
要るんだよとか、フラグレジスタの読み出しがなんで特権命令なんだよとか、 
%g0ってレジスタ値変わらないし壊れてるよ、初期不良で交換だよとか、 
アセンブラ通気取りの偏ったどうでもいい我侭を言い出し(だからSPARC使うんじゃ 
ねーよ) それと戦わなければならないのでしょう。そして時代によって決着している、 
過去25年のCPU界隈のくだらないそれらの議論が再現され、それに巻き込まれるの 
でしょう。もう今からうんざりです。 

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

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

2012-06-23

キスで学ぶPush実装技術

彼女MacBookを並べてコーディング

ようやくRailsの開発を一人で出来るようになった彼女が、俺に突然質問を投げかけた。

「ねぇ、WebサービスPushってどうやって実装するの?」

「一般的には3つの方法がある。」と俺は答えた。

クールな順にWebSocket、次にコメット最後ポーリングだよ」

彼女は目を輝かせながら「それでそれで?!」と説明を求めてくる。

ポーリングは、一定時間ごと、たとえば3秒ごとにAjaxサーバリクエストを送って新着の情報が無いか問い合わせて、もし新着があれば処理を、なければスルーして次の問い合わせに備えるPush通知の実装だ。手軽に実装できる反面、新着がない多くの時間常にリクエストを送り続けることになるので無駄が多い。大規模なサービスで実装すれば、それだけでDDoSっぽくなっちゃう。また、リアルタイムも厳密には実現できなくて、MAXポーリング間隔分のラグが発生してしまう。小規模なサービスで、とりあえず実装するにはオススメかな。」

なるほどなるほど、と彼女は頷く。


コメットは?」

コメットポーリングを改良したもので、ブラウザからリクエストが送られてきた時点ではサーバはすぐにレスポンスを返さずに、処理中ってことでコネクションを張ったまま一定時間つんだ。それで、なにか新着があったタイミングで、昔送られてきてたリクエストレスポンスを返す。そうすると、新着があったタイミングレスポンスを返すタイミングになるので、レスポンスはほぼリアルタイムになる」

「なるほど!すごい!!!

「頭の良い実装だよね。Facebookの通知なんかはコメットだよ。ただ、コメットも万能じゃない。まず、レスポンスはいつまでも待てるものではなく、待たせすぎちゃうとタイムアウトなっちゃうんだ。だから一定時間ごとには何もなくても"進捗はなかったよ”というレスポンスを返してあげなきゃいけない。また、サーバコネクションを常に割り当てないといけないので、IOをブロックするようなサーバだとリソースを食い過ぎて耐えれ無くなっちゃうから大規模な運用には金がかかっちゃうんだ。所詮HTTPを使ったごまかしでしか無い。オーバーヘッドが大きいんだよ。」

「な、なるほどー」

少し話が小難しくなったためか、一生懸命理解しようと彼女が頑張っている。かわいい

「そこでWebSocketの登場だ。WebSocketは厳密には違うんだけど、HTML5関連の新しい技術で、ネトゲで使うTCP/IPセッションのようなコネクションをサーバ側と張ることができる技術なんだ。しかNATとかも超えてくれる便利な技術。これがあればリアルタイムWebの実装はすごく簡単になるんだけど、まだ新しい技術というのもあるし、対応してるサーバライブラリの不足や、プログラミングスタイルイベント駆動になるという変化もあって、まだまだ一般的にはなってない。対応してるブラウザ最近まで多くはなかったしね。やっとiPhoneでも使えるようになったし、スマフォWebでも普通に使えるようになってきた。これからが楽しみだね。」

「うーんと、うーんと、つまり

彼女今日得た知識のまとめに入ったようだ。一生懸命Web技術を学ぼうとしている健気な彼女に、僕は心がキュンとなった。

「そう、つまり…」

僕は彼女の頭に手を回し、クイっと自分の顔を近づた。

びっくりして目を見開いている彼女

そんな彼女に向かって、連続5回キスをした。


「チュッ、チュッ、チュッ、チュッ、チュッ、」

「これがポーリング。」


今度は自分の顔を少し傾け、舌を入れる深いキス


「チュポッ…」


彼女の頬は少しだけ赤く染まっていた。


「これがWebSocket、そして…」


最後に僕は彼女の顔を両手でホールドし、8秒くらいの長い、とても長いキスをした。

彼女の顔は真っ赤に染まり、目は少しだけトロンとしていた。


「これがコメット。わかったかな?」



彼女はとても恥ずかしそうに「はい…////」と返事をした。


「よし、じゃあコーディングに戻ろう。」



コーディングを始めた5分後、彼女がおもむろに呟いた。



「私、コメットがいいな。。。////」


東京は快晴、今日も絶好のペアプロ日和だ。

2012-06-14

http://anond.hatelabo.jp/20120614160514

STLを使うことによる オーバーヘッドは 数~数百バイトオーダーだろ。どんなに見積もってもキロ単位

いくらなんでも、キロ単位を 詰めることは稀 というのがメモリ見解

メモリを最も使うのが、画像画像1枚で数百Kで こっちを何とかしたほうがよほどはやい。

ここで言ってるのはあくまでも、STLを使うことによるオーバーヘッドは メモリが潤沢にあるものと想定してもいいって話で

画像とか開放漏れをしてもいいって意味じゃない。

ここで行ってるCPUは モバイルだな。 電池の持ちにも直結するし、持ってるメモリを0クリアとか、やらなくてもいいと分かり切ってる時でかつ

リストVectorの子要素で、それが莫大に長いと事前にわかってる時だな。

2012-01-27

http://anond.hatelabo.jp/20120127061544

「人数増やすと…」について補足。

http://ja.wikipedia.org/wiki/%E4%BA%BA%E6%9C%88%E3%81%AE%E7%A5%9E%E8%A9%B1

スケジュールが遅れているソフトウェア開発プロジェクトにさらにプログラマを追加すると、そのプロジェクトはさらに大幅に遅れる。これを「ブルックスの法則」という。この大幅に遅れることの原因は、新しく参加するプログラマプロジェクトについて学ぶ時間が必要となること、およびプログラマが増えることでコミュニケーションオーバーヘッドが増えることである。N 人の人々が自分たちの間でコミュニケーションをとる場合 (階層的な組織を構成していないものと考える) 、N が増加すると、彼らの生産量 M は減少する。生産量 M が負の量になることさえ起こりうる (例えば、ある日の終業時点における全ての残務作業量が、その日の始業時点における全ての残務作業量よりも大きい場合——たくさんのバグを作りこんでしまった場合など) 。

今回のケースでは、60人が1300人になったので、コミュニケーション量は約477倍になるわけだ。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん