  |
はてなキーワード: エンジンとは
http://nlab.itmedia.co.jp/nl/articles/1811/10/news009_3.html
ねとらぼ：VTuberという呼称についてどう考えていますか？ バーチャルタレントとか呼び名はいろいろあると思いますが。
荒木：社内ではVTuberって言ってますね。今は適切な用語がないからVTuberを使っちゃってるけれど、新しい言葉がでてきてほしい。
「バーチャルYouTuber」「VTuber」はこのまま定着する気しかしない。色んな前例があるし。
誰か詳しい人いたら直してください。
トルクとは回転軸からある距離離れたときそこにかかる力と、その距離の積でモーメントと同じ。単位は仕事[N・m]
トルクをタイヤの半径で割ったものが駆動力で、これが乗り物の加速度を定める。
・タイヤが小さい
・タイヤが大きい
駆動力が小さいので加速しにくい。
疑問：これだけ考えるとタイヤが小さい方が速さを求める上では優れているように思える。
しかし実感としてタイヤ幅が大きい方が漕いでいて楽な気がする。慣性モーメントのせいか？
エンジン（またはペダル）の回転数とタイヤの回転数の比をギア比という。とりあえずタイヤに対してのエンジンの回転数の比ということにしておく（決めておかないと混乱する。）
ギア比が大きい（自転車でいうとペダルが重くなるギアの状態）トルクが大きくなり、べダルの回転数が下がる。
ギア比が小さい（自転車でいうペダルが重くなるギアの状態）とトルクが小さくなり、ペダルの回転数が上がる。
ギア比が小さいと回転数が上がりかつ必要な力も小さいため楽に加速するが所詮トルクが小さいので限界がくる。
従って１速から順にギアを変えていくのは、回転数を稼いでから順にトルクが大きい状態という、馬力を上げるための理にかなった順序。
またチャリの場合はギアチェンジすると回転数を維持するのにエネルギーが必要だから、漕いでてしんどい。→結果そのギアに適した回転数に落ち着く
車体の速度が上がっていくと抵抗力曲線と駆動力曲線（横軸が速度、縦軸が抵抗力と駆動力）の交点となる最高速度に達する。
最高速度に近づくに従って余裕駆動力が減っていくので加速しづらくなる。（駆動力曲線が上に凸の曲線だから？）
疑問：最高速度に近づいても「界王拳」みたいにトルクを一気に上げられれば（クラッシュバンディグーのニトロ的な）最高速度付近での加速度の上げづらさはないのではないか？
それともそれができる時点で駆動力曲線は上向きにシフトするように描かれるのだろうか。そんな仕組みがある自動車や自転車が無いから現実に議論されない？
かなり興奮しているし酔っているので要領を得ないかも。
今日急にうちに派遣で来てるおっさんに飲みに誘われて、会社の近くの安い居酒屋につれていかれた。
なんで誘われたかというとこれもうまく言えないのだが、チームや全体での飲み会で近くにいることが多く、不幸なことに自分が少し聞き上手だからかもしれない。
とにかく席についてビールが来ないうちに、人をばかにしたような半笑いで話を切り出された。
おっさんが持っている10年も前にあったようなガラケーのメモ帳画面を見せられ、君になら理解できるだろうとかクィータとかいうサイトにはろくな人材がいないとかブツブツ言っていて、俺はメモの中身を読み進めているうちに顔が引きつっていくのがわかってなぜか記事自体よりもそのことで笑いが止まらなくなりそうなった。
しばらく自分はどうすればいいのか知らないふりをするべきか、なだめたほうがいいのかまじでわからなかったのだが、結局記事の本意を聞きたい好奇心には打ち勝てなかった。
ちなみに自分の仕事場ではWinXPが現役で動いている。派遣おっさんも含め会社がそういうカラーだと言えば伝わるだろうか。
自分は趣味でReact(ないしReactNative) とかで家計簿アプリを作っているし、Androidも（それこそJavaでだが）やっていてちょっと新しい技術は知っているというレベルである。
端的に言うと「必修」という意味で使ったらしい。ルー大柴かおまえは。いや意味が通ってないしルーに失礼か。
・JavaとJavascriptが同列になっている点について
どうやらプロトタイプベースのオブジェクト志向という意味をはきちがえている。
つまりJavascriptはオブジェクト指向言語のプロトタイプとして生まれた言語であり、完全オブジェクト指向言語（これも意味がわからなかった）のJavaとは切っても切り離せない関係であると思っているらしい。もう自分はここらへんから笑いが変な声で漏れる笑いを堪えられなくなっていて、喘息気味なんですとかアホな言い訳で必死にごまかそうとしていたんだけれど、この派遣のおっさんに対してそこまで気を使っている自分にも笑いが止まらなくなってまあなんというか、おもしろかった。
Rubyが（というかRORが？）動作が遅いという話をどこかで読んだか聞いたかしたらしく、そして動作が遅いかわりに処理がしっかりしている（現文ママ）という位置付けの言語だと思っているらしい。正確性が必要な処理はサブルーチンにしたRubyに投げるべきだとかなんとか。
パッセンジャーよりもエンジンクスにひもづけるべき（現文ママ）とか言っててもうビールがまずくて仕方ない。
・MSDN
自分はMSDNは学生時代にVisualC++とかで使ったことがあって、デスクトップアプリ用のライブラリだとずっと思ってたんだけど、違うんですかね。（無知）
MSDM（何度聞いてもエムにしか聞こえない）の逆アセンブリ言語がC++だとか、ここの話は輪をかけて本当に何言ってるのかわからなかった。
ねこのことを考えて耐えた。
・SQL
あんま深く考えてなかったらしい。言語と名前がついているから言語のくくりに入れた、くらいのスタンス。
ちなみになぜか、使ったこともないらしいSQLiteで配列型を使えないことは知っていた。
と、ひと通り聞きたかったことを聞いた後、もうなんか疲れ果てたのでビールを半分残して帰った。
説明するのだるい感じになってきたな…あのね、ロボットの問題は「ガッシリ物を掴めるモーター」とかじゃないんだよ。人間は見たまま物体をひょいと掴むってことができるじゃん。で、落としたらキャッチとかできるじゃん。で、その動きを一回記録すれば大電力を注ぎ込んでロボットに同じ動きをさせることはできる。横増田が言ってる「プログラムした動きを繰り返すだけ」は昭和の頃から自動車では普通にやってるし、無しでは現代社会は回らなくなってはいるのよ。
だけど、その動きを自動生成することができない。
つーのは、生物は生まれてから10年や50年で機械学習してものを掴んだり操作したりする動きを覚えるわけじゃなくて、小鳥から人間まで共通に持ってる脳のハードウェア処理エンジンをチューニングして使ってる。鹿の子供は生まれてから10分で立ち上がって親についていくというくらい、ほぼ遺伝子に書き込まれて完成済みの専用計算ブロックがある。そしてその構成は完全には解明されていないどころか、まだ具体的にどういう小部分があって同相互接続されているのかさっぱり分からず、工業の分野の数学的モデルで解決しよう(古典・現代制御)とか解明された他の手法を転用してなんとか真似できないか(ディープラーニング™など)と試行錯誤している状態。
このハードウェア処理エンジンは動物に基本的に備わっているから、ハード的に人間の動きをほぼ再現できるロボットを見ると、形には自然と機能が伴うと思ってチャチャッとソフトを開発すれば何でも掴めて人間を置き換えられると思っちゃう。
違うんだよ。この完全に理性とか思考とかいった人類が人類である価値を全く含まない部分が、最低賃金以上の金を支払う価値が全く無い単純極まる肉体労働タスクこそが、種としての人類の最後の砦といっても過言ではないんだ。
前回まで手続型言語の基本（構造化プログラミング、オブジェクト指向プログラミング）を見てきた。
今回から問合型言語のSQLを学び、データベース（DB）を使ってみよう。
大量のデータを記録して、活用するために特化したソフトウェアが「データベース」だ。
データベースには、いろんな種類があるけど、今回学ぶのは「リレーショナル・データベース」（RDB）だ。
データベースがなかった時代の人々は、大量のデータを扱うのに苦労していた。
データベースを活用すれば、人間は脳の記憶力を補完して、膨大な知識を扱うことができるようになる。
キミも今日からデータベースを活用して、記憶力を100億倍にしよう！ドラえもんの暗記パンなんて目じゃないぜ！！！
MySQLは無料で使えるRDBです。MySQLでデータベースの練習をやってみよう。
それではさっそく、以前インストールしたXAMPPで、MySQLを使ってみよう。
Port(s)が「80,443」「3306」と表示されたら、PHPとMySQLが使える状態になってます。
Webブラウザー（Google Chromeなど）で、「 http://localhost/phpmyadmin/ 」というURLを開く。
「phpMyAdmin」は、MySQLを管理するツールです。
「phpMyAdmin」で検索したら、使い方を紹介する記事が、たくさん見つかります。
phpMyAdmin(ピーエイチピーマイアドミン)はMySQLサーバーをウェブブラウザで管理するためのデータベース接続クライアントツールで、PHPで実装されている。
検索したら、こんなのがありました。
後で簡単なチャット（おしゃべり）ができるWebアプリを作ってみたいと思う。（Twitterをショボくしたシステムｗ）
チャット用のデータベースとして「chat」という名前のデータベースを作ろう。
これで「chat」という空のデータベースが1個できた。
「chat」データベースの中に、テーブルを1個作ってみよう。
すると「名前」「データ型」「長さ/値」「デフォルト値」…などの空欄がたくさん並んだ画面が表示されただろう。
これら4段の下にある「ストレージエンジン:」欄は「InnoDB」にしておく。
ここまで入力したら、画面右下にある「SQLのプレビュー」というボタンをクリックしてみよう。
すると、
CREATE TABLE `chat`.`message` (
`id` INT NOT NULL AUTO_INCREMENT ,
`create_at` DATETIME NOT NULL ,
`update_at` TIMESTAMP on update CURRENT_TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ,
というSQL文が表示されただろう。
これが「SQL」というデータベースを操作するプログラミング言語の書き方なんだ。
今はツールを使って自動的にSQL文を作成したが、SQLの文法を学べば、自分で書けるようになる。
とりあえず、今はphpMyAdminでMySQLを簡単に操作してみよう。
すると、画面左側のデータベース一覧で、「chat」の下に「message」というテーブルが表示されるようになっただろう。
データベースと、その中のテーブル（表）を作ったけど、まだデータが入ってないので空のままだ。
すると、
INSERT INTO `message` (`id`, `create_at`, `update_at`, `message`) VALUES (NULL, '2018-10-24 12:34:56', CURRENT_TIMESTAMP, 'Hello, world!')
というSQL文が表示されただろう。
これがデータを操作するSQL文の一例だ。これも後でSQLの文法を学んでみよう。
これでデータが1件追加できた。
こんなかんじで、とりあえず、phpMyAdminでMySQLをいろいろいじって練習してみよう。
次回以降の予定は、
といったかんじです。
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
anond:20181022232327 増田式プログラマー養成講座 その９ MVCフレームワークを使ってみよう
anond:20181023184616 増田式プログラマー養成講座 その10 OOPの参考書
anond:20181024214133 増田式プログラマー養成講座 その11 データベースを使ってみよう ←★今ここ★
anond:20181026145516 増田式プログラマー養成講座 その12 データベースの参考書
：
結構よくまとまっているとは思うんですけど、博士学生だからか少し偏りがあるので、もし参考にする学生が居たときのために、少し補足させてください（ちなみに私は本職です）。
挙げられている分野は、いわゆる古典的なCGの分野の一部で、そこに当てはまらないものも沢山あります。例えば、3Dプリンタに関する技術とか（fabrication）、建築関係、VR/AR、HCI、HPC/ハードウェア、computational photography、アート、数値計算、言語処理（CUDAの元はSIGGRAPHの論文ですよ）などです。実際のところ、かなり色々なトピックがあり、この分野の研究者でも全てを挙げられる人は居ないと思います。トピックが違うと同じCGの研究者でも話が通じない事もあります。他分野の専門家と組んで研究している人も多いので、かなり懐が広い分野だと思います。自分の興味のあるもの+CG、という研究をしている人が多数居ます。
なお、西田先生は日本では有名なのかもしれませんが、国際的に著名な研究者は各分野で違います。SIGGRAPH/SIGGRAPH AsiaなどのTechnical Paper Committteeの名前をチェックすれば、最近勢いがある若手や著名な人がだいたい分かると思います。自分の興味のある分野の研究者が海外に居れば、留学しましょう。
これは訂正された点を含めると、だいたい合ってます。訂正にあるように、基本的には、大きな学会のProceedingの論文 = ジャーナル論文なので、その場合ジャーナル論文としてカウントする人が多いです。ジャンル別の会議に理論的な研究が発表されるかどうかというと、そうでもないでしょう。どちらかといえば、研究としてのインパクトが小さいが発表したいとか、SIGGRAPH/SIGGRAPH Asiaに落ちたので、再投稿というケースが多いです。国内の学会・雑誌はアレなので、英語で文章が書けないと死にます。
CGではIFを気にする人はあまり居ません。研究者としてのアウトプットは、国際的にはSIGGRAPH/SIGGRAPH Asia/TOGを含めた、主要な学会での論文の本数が重要です。Pacific GraphicsおよびEurographicsは、それぞれの地域ではそれなりに評価されますが、国際的には評価されない場合があります。あと、勘違いされているケースが多いので強調しますが、SIGGRAPH/SIGGRAPH AsiaでカウントされるのはTechnical Papersだけです。その他のプログラムは、参加したいなら出してもいいけど、研究業績にはカウントされません。その他のプログラムばかりで発表していて、Technical Papersで論文が出て無いのに、SIGGRAPHで活躍していると強調している研究室（国内外にあります）は注意しましょう。分野全体の業績評価の実態と違います。
学位取得難易度は、研究室および大学によって大きく違います。上記の著名な国際会議に通すことを期待している研究室だと、アイデアが重要な分（データやモデルを少し変えて、少し性能が良くなったぐらいでは論文は通りません）、他の分野より要求される能力は高めです。ただ、懐が広い分野なので、自分の得意なことを生かして研究ができれば、研究に没頭できて楽しく過ごせると思います。実際、活躍している人はそういう人です。標準的なアウトプットとしては、1年あたり、ジャーナルになる学会に1本ぐらいでしょう。博士課程が3年なら3本ですね。リジェクトされるので、その倍ぐらいはプロジェクトをこなす必要があります。
実装力は超重要です。アイデアを形にして実験出来ない人は苦労します。言及元に書いてあるものの3倍は実装します。
研究の歴史が長いトピックは既存の研究に対して新規性を出すのが難しいので、その分論文を書くのは難しいという、ごく当たり前な状況です。書かれているように、レンダリングや流体は難しいと認識はされていますが、それは歴史が比較的長く、劇的な性能向上が難しいからです。逆に最近出てきたトピックの中だと、新しい応用を見つけてそれを古典的な方法で解く感じの研究が多いです（3Dプリンタ向けのデザインの最適化など）。そのようなトピックであれば、面白い応用さえ思いつけば、既存研究との比較をあまりしなくても通る論文が書けるでしょう。いずれにしても、如何にして新しいアイデア（新しい理論・手法であったり、新しい応用であったり）を思いつくかが重要です。
各分野の所感については、言及元は一学生の感想で、それが分野全体としての共通認識かというと、そうではないように思います。一口にCGと言っても研究分野が多岐にわたるので、それぞれの分野の専門家に話を聞くのがベストです。
研究室で育ててきたエンジンがあるかどうかは（そしてそれを弟子に使わせるかどうかは）研究者によります。進学する際には、その辺をチェックしましょう。ただ、現在活躍している人には、自分で書きたがる人が多いです。「レンダリスト」という言葉は聞いたことがありません。
だいたい正しいと思います。応用的な研究と言うと、表面的な印象を受ける人がいるかもしれませんが、ただ何かを達成すればいいというよりは、実際の問題を解けて理論的にも面白いという研究を目指す人が多い分野です。査読ではその両面が評価されるので、査読者によってどちらに重きを置くかも違い、皆を納得させる成果を出すのはなかなか大変です。
CGは、研究を頑張って学会等に論文を沢山出せれば就職先も引く手あまただし、研究成果は専門外の人（例えば家族とか）にも分かりやすいし、自分の興味のある事をコアにして研究できる懐の広さがあり、とても楽しい研究分野です。どの分野で研究しようか迷っている人はぜひ！
ハイスペックな人のエントリだったり、さらにいやいや君もずいぶんすごいね。
というエントリだったので、本当に普通な感じで埋もれているエンジニアが転職した時の話をしようと思う。
現在私は同業界の大手企業で働いている。転職結果としては年収も大きく上がったし、
年齢：39歳
＜前職＞
中堅の独立系SI企業（WEBもSierもやってるような感じ）社員600名程度
に所属していた。勤続は7年目
＜技術力＞
技術力はほんとに並の下程度。
JavaとかPHPとかやっていて、PHPがメインだったかな。主にWEBサービスを作ったり、社内WEBシステム作ったりしてた。
プログラミングの基礎はあるし、SQLやその他DBの知識もそれなりにある。サーバーの知識はあんまりないし、
Linuxのコマンドは正直ちょっと苦手だし、AWSとか触ってないし、なんならApacheだってそんなに詳しくない。
ググっていつも解決する。フルスタックエンジニア？なんだそれ？こちらサーバーサイドエンジニアだ、文句あんのか？
新しい技術や言語は基礎があるので飲み込みは早い方だと思う。なので対応力はある方だ。Rubyでもpythonでもコード見れば読めるし、
大抵のことは理解できると思う。でも業務では使ってない。JQureyもまぁ普通に使えるけどJSのコードとかたぶん汚いと思う。
色々と新しい技術をググって記事見たりして「わかった気になるタイプ」だと思う。36歳くらいでやっと「デザインパターン」
知らないとやばいんだ。勉強しないと！と焦って本だけ一応読んで「わかった気」になった。
ここまで読めばわかると思うけどエンジニアとしてはだいぶ「ポンコツ」だ。
でも仕事のためにやってるエンジニアとか結構こういう人が大半な気もするんだよね。
立ち位置は開発リードとか設計とか上流も少しやってた。年齢のせいもあると思うけど、
まぁうまく立ち回って仕事してた感じだと思う。コミュ力はそれなりにある方だと思う。
もうエンジニアとかお前が名乗るなよとか言われそうだな。。。すまん。
このまま、今のポジションで仕事を続けてたら永遠に新しいこととか他の言語を使って業務をすることができそうになかったから。
嘘だ、人間関係だ。ほとほと同僚、後輩、パートナーに愛想が尽きたからだ。それと上司やその上の部長にもだ。
客先で顧客と一緒に仕事をしてたが顧客側の人はほんとにまともで良い人ばっかりだった。転職する時にそれだけ、ちょっと寂しくなったな。
ポンコツながらプロジェクトでは納期を守り何とかやり抜いてきたが、全く評価されない現実もあり、それも嫌だった。あと、給料安い。
表向きはいろんな理由があるだろうけど、転職する人の理由はきっとこれが現実だと思う。
＜概要＞
転職を決意
↓
↓
↓
DODAとリクルート系は良い思い出が一切ないので登録してない。
↓
↓
↓
↓
↓
ビズリーチ経由でB社で金融系ITに強めの転職エージェントに会う
↓
＜詳細と雑感＞
転職しよう！と思ってからとりあず動けーーー！って感じで動いた感じです。
総応募数は覚えてないけど30～50社くらいだったと思う。書類で超落ちる。年齢のせいも大きい。
エン転職のスカウトは全然ダメだった。めぼしい企業がなかったし、年齢のせいか知らんけど、
ギークリーから応募したのが一番多いと思うけど、とにかく手あたり次第に紹介してくる。
よさそうな企業もあったけど、面接まで行ったのは4社程度ですべてお祈りだった。
2次や最終までは行くが、いまいち紹介された企業に自分の志望動機を合わせる作業がどうにも苦手でうまく行かなかった。
ギークリーはほんとに求人が多いから、たくさん見て選びたい人には向いてると思うけど、自分には向いてなかったな。
他にもビズリーチ経由で4社くらい直接カジュアル面談があったけど、有名なY社とか、運輸系のY社のシステム会社とか、
印刷系のD社の子会社とか、どれも最初のカジュアル面談で、それ以後連絡なかったなぁ。
そんな感じで行き詰って2か月。心機一転また別のところ！というのと、
自分でもう一度ポンコツなりに職務経歴書を頑張ってブラッシュアップし、面接対策もして、改めてA社とB社とつながった。
B社からの紹介はとても面白い会社だったし、一次面接もかなり好感触だったのだが、なぜかその後に論文筆記があり、
書いて出したら、落ちた。どうやら思想が合わなかったらしい。
A社から紹介されたのが、医療系のWEBサービスの会社と誰もが知ってる大手企業。
どうやら大手企業とは結構つながりのあるエージェント会社だったみたい。
自分が大手に行けるか半信半疑だったが、面接対策も結構しっかりしてくれて助かった。
同じ質問を面接でされたので、うまく答えることができたと思うし、職務経歴書も一緒に見てくれた。
そして、2か月でこの医療系の会社と大手から内定を頂いた。転職活動は実質4か月くらい。
どちらも良い会社だったので、本当に迷ったが、大手の方にした。
断るのもエージェントがやってくれるのでこれも結構気持ちが楽だった。
＜振り返って思うこと＞
ポンコツなりにアピールできるポイントがあれば、それをしっかりアピールするような職務経歴書を作ったり、
私の場合は3回目の転職だったので、今までの経歴をきちんとよどみなくアピールできるような練習は有効だった。
転職活動初期は全然対策してないこともあって、やっぱり落ちたのかなと思う。
だんだんエンジンがかかって、面接にも慣れていき、最終的に大物ゲットできた感じだ。
そして、面接ではやっぱり自分はできる奴だ！ということをちゃんとアピールした方がいいと思った。
謙遜とかいらないし、こういう職務なんですができますか？と言われても、普通に全然問題ないです。くらいに言ってもいいと思う。
ハイスペックエンジニアとかいやいや十分すごいですわ的なエンジニアは、自分で活動して、普通に交渉もして、
自分がより有利な環境を手に入れることができると思うけど、私のようなポンコツは普通にエージェント使って、
普通に応募して、面接対策しっかりして、志望動機もちゃんと頑張ってたくさん考えて、ちゃんと喋る練習して、それで行けば結構いけると思う。
落ちるのはやっぱり職務経歴書がまだちゃんと練れてないのと、面接の練習や、志望動機が甘いんだと思う。そこを頑張れば良い環境に転職できると思う。
おススメのエージェントとかは特にないかな。自分に合ったものを自分で転職活動しながら、見つけるのが良いと思う。
1つ言うならエージェントを1つに絞らないことかな。忙しくなるけど、いろんな所と付き合って、自分に合うところを見つければいいと思う。
そういう意味ではビズリーチは大小さまざまなエージェント会社があり、そこから連絡がバシバシ来るので登録しておくとよいかもしれないです。
＜まとめ＞
こんな感じだ。読み返すとあんまり参考にならないかもしれない。。。
私は前の会社で全然評価されなかったが、今の大手に移ったら、普通に評価が上がって、給料もしっかり上がった。
環境次第で人の評価って全然変わるし、所詮評価する側のフィルターをかけた評価なんてやっぱり気にしなくていいんだと思った。
実際前職の部長に退職の旨と転職先の話をした時に「子会社ですか？」とか言われたし、「いえ、本体です。」と答えたら「マジで？」という顔をしてた。
部長のフィルターでは自分の評価はそんな感じだったんだなと実感した。
今ももちろん良いフィルターをかけて評価してもらっていると思うけど、自分にとってどっちが良いかは明白だし、
その良いフィルターが本当になるようにもっと努力したいと思う。
今の市況ならほんとに転職すれば年収上がるくらいの状況だし、勤続3～5年以上で、
自分の現状に不満があるなら、いっちょやってみるのも良いかもしれません。
誰かの参考になれば幸いです。
「男なんだろ？ ぐずぐずするなよ」
2.ありえない解決策を図る
「胸のエンジンに 火をつけろ」
3.自分に有利な将来像を予想する
4.知能障害を起こす
「イー！イー！」
「若さってなんだ？ 愛ってなんだ？」
6.主観で決め付ける
「振り向かないことさ ためらわないことさ」
8.レッテル貼りをする
http://dlit.hatenablog.com/entry/2018/10/10/080521
https://anond.hatelabo.jp/20181010122823
私もこの流れに賛同したので続きます。私は博士課程の学生なので、多少間違いがあるかもしれませんが、大筋は合ってると期待します。身バレしない程度にざっくりとした纏めにとどめますが、誤りがあった場合の修正については諸氏にお願いしたい。他の研究者の諸事情を聞くのは面白いですね。
というようなモノになると思います。各分野を横断する様な複合的な研究も多いのですが、大雑把にというところでお許しください。最も著名な研究者は現在はドワンゴリサーチを主幹しておられる西田先生でしょう。
国内ですと画像電子学会、VCシンポジウムといった会議や雑誌に投稿しますが、国内への投稿はあまり重要視されていないという現状があります。では、どこへ投稿するのか？といいますと、Siggraph (Asia) 、 Eurograph、Pacific Graphics などの主要な総合会議になります。主要会議については、インパクトを重視する面もあるのですが、各ジャンルで、例えばレンダリングではEGSRなど、主要な国際会議と同等レベルの難易度とみなされる会議があり、これらの専門ジャンルの分派会議は総合会議よりは多分に理論的な研究が発表される傾向があります。最も評価が高いのは主要三会議ですが、それらでの採択が無理なら、再実験や修正したのちに、ランクを落として投稿し、より注目度の高い会議での採択を目指します。
CGの論文は、ACMのデジタルライブラリーに公開されるほかは、殆どの場合は著者の一人がプレプリントを公開する慣習があります。ACMのみですと会員登録をしていない実業界の人の目に触れにくいという事情が影響しているのかなと。SiggraphとEurograph及び主要な分会を除いては、基本的には国際会議で発表された論文は、Proceedingになります。基本的にはというのは、その中の優れたもの何報かはジャーナルに採択されることもあるからです。またジャーナルに直接応募する事も出来ますが、ジャーナルへの投稿は会議への投稿よりも時間を要する事情もあって国際会議へ投稿する人が多い様です。当然ですが、これらは全て査読されます。何度もリジェクトされます・・・。
https://www.eg.org/wp/eurographics-publications/cgf/
https://www.siggraph.org/tags/tog
一般的な論文のページ数は1ページ両面印刷 2段構成で10P程度です。とても短いですが、短い分だけ綺麗に纏める能力が問われる事になりますし、一言一句と言えども無駄にできない厳しい調整を繰り返して執筆します。
主要会議は下記のリンクに纏められています。リンクから論文も見れますので、ご興味があればどうぞ。
http://kesen.realtimerendering.com/
CG業界における最高峰の雑誌は、ACM Transactions on Graphics で、IFは 4,218となっています。
次いで重要なのが、
IEEE Transactions on Visualization and Computer Graphics でIFは 3.078。
Computer Graphics Forum でIFは 2.046。
ieee computer graphics and applications で、IFは 1.64と続きます。
残念な事ではありますが、CGではIFが1.0を超えるジャーナルは少ないので、研究者の多さに比較して掲載枠は少なく競争は非常に激しくなっています。これもジャーナルよりは、それと同等に評価されるトップカンファレンスの proceedingにする理由かもしれません。
学位の取得難易度は、理工学系では高くない方だと思います。博士を取る過程で要求されるのは、雑誌ないし高レベルの会議のproceeding 2報というのが観測範囲での相場です。国内会議への投稿や、査読なし投稿、講演資料などを含めると5本程度はある感じになるのではないかと思います。博士を獲得するまでにかかる時間は3年となっています。それより長くかかる人も、短く終える人もいます。アカデミックなポストは常に足りない状況にあり、非常に優秀な研究者も結構苦労してるように見受けられますが、産業界に就職する場合は非常に簡単です。
CGをやる上で必要になる数学と物理は、基礎科学分野では学部生時代にやる様な初歩的な数学や物理です。最適化問題を解くことが多くなる関係で最適化数学についてはよくやっておいた方が良いようです。この辺りはジャンルに関係なく一通り勉強しておく必要があります。数学や物理の勉強量は、基礎科学分野よりも多くはない分、情報系のアルゴリズムに関する基本的な理論やプログラミングによる実装能力が問題になります。研究の為には比較対象となる研究を数本程度自分で実装したりする必要がある上に、バグを出せば致命傷になるという点が実装力の高さを要求する理由です。優秀な学生は、そこらの社会人よりも優秀という事は珍しくなく。プロコンでレッドコーダー（日本で20人程度らしい）を持っているという様な人もいます。
一本の研究を終えるのに読みこむ論文は、20～50、自分で実装する研究が 1～3、という量になると思います。斜め読みするものまで入れると、その倍くらいでしょうか。物理学と比べると明らかに楽ですね。
CGでは、どのジャンルを選ぶかで博士の取り易さに差はないように思えますが、レンダリング分野は先鋭化しすぎていて、既存の研究をキャッチアップして実装し、自分の研究を行うまでの間に膨大な努力を必要とする上に、光学的にみて正しいのか？（追記: 実際に物体に光を当てた場合に得られる画像ないしデータは、計算によって得られた結果と等しい物になっているのか？ ）という様な厳しい評価を受ける傾向があり、（CG系の）他分野に比べて業績を出すのが大変だと思います。研究者の中には10年以上に渡って育てて来たレンダリングエンジンをベースに研究を行う為に新参との差が大きいのです。そういう意味で優れた研究者に師事する事が非常に重要と言われています（師匠がエンジンを持ってますので）。最近は深層学習との組み合わせも増えてきているので、勉強量は非常に多いジャンルだと思います。その分、ゲームや映像分野で花形であり就職の際には引く手あまたになります。
近年、流体シミュレーションや弾性体シミュレーションは、新規性を出すことが難しいジャンルの一つと言われていて、トップカンファレンスでは採択本数が多くはありません。テーマ選びが難しい分野だと思います。リアルタイムなシミュレーションが難しい分野なので、ゲームなどでの応用を狙ったリアルタイム化の研究などが学生には人気がある様です。リアルタイム化すると理論的には正しくない、という様な齟齬が生まれる事が難しく、その折り合いの付け方に肝があるようです。レンダリング同様に就職に強い技術でしょう。流体力学や有限要素法などの知識を特に必要としますが、定型化されている部分があるのでキャッチアップはレンダリングよりは容易と思います。
モーションとはどんなものか？というと、ゲームや映画などで使われるキャラクタの動作＝アニメーションの事です。行われる研究はすぐにでも実用化できそうな研究が多く、実際に企業（ディズニーなど）での研究成果が発表されることも珍しくはありません。髪の動作の研究なども、モーション研究のテーマの一つです。これも就職するなら強い分野です。特定の数学や物理に依存せず、基本的な数学の知識全般を必要とします。例えば衝突を考慮するならば力学を使うというような感じです。
かつてはCADなどで流行りのジャンルだったのですが、CADの研究が下火になったこともあり、現在は傍流の研究です。ただ形状解析の研究は、テクスチャ展開などCGに必要な技術を支えるものではあるので、現在も一部の研究者によって行われています。ゲームや映画で使うLODを作成する技術も、この分野の成果の一つです。他にはMRで赤外線センサーから取得した点群を形状に変換するといった場面で研究が役に立ちます。就職という観点から見ると、企業からの需要は少ないかもしれません。微分幾何と一部は位相幾何が特に必要となる知識です。
画像処理は画像認識系の会議へ行く事も多いのですが、近年、注目を浴びているのは、深層学習と組み合わせることで、ラフな線画をプロが書いた様な鮮明な線画に自動的に置き換えたり、また無彩色の画像に彩色する様な研究です。特に必要とするものはなく広く知識を必要とします。部分的には、色空間を多様体と考える様な研究もあったりするので、位相幾何学をしっていないとというような事もあります。伝統のある研究ジャンルだけに、問われる知識も広範です。画像認識系の研究にも精通している必要がある為、論文を読む量は多いでしょう。
基礎科学系では疑問視されることはないと思いますが、学科としての歴史が浅くかつ実業に寄った分野なので、論文の評価はどうなってんの？という疑問があるかと思い追記します。
査読の際に問われるのは、手法の妥当性です。先行研究との比べて何が改善されているか？理論的にそれは正しい計算なのか？といった事を主に問われます。情報工学のCG分野も科学ですので、先行研究との比較もデータを集め、解析的に、何がどの程度良くなっているか？を記述します。また、各研究が基本的な知識として使っている基礎科学系の知識にそって、理論的に研究手法が正しいものであるかも厳しく見られます。査読によって疑問を示された場合、一定の反論期間を与えられます。
研究者は査読を通過するために、動画やプログラムコードなど、再現性を示す資料を合わせて提出することで、査読者を納得させる工夫を行います。時には論文そのものよりも追加提出資料のボリュームが大きくなるという事もあります。というか、それが常でしょうか。
自身の研究も含めて既存の研究は、後発の研究者によって実装され検証されます。上手くいかなければ質問を受けるし、疑問を提示され、後発の論文で批判を受けることもあります。そうならぬように、実装したものを公開している研究者もいます。親切な研究者であれば、比較に使うと言えばコードや実験に用いたデータをくれることもあります。
以上のような仕組みによってCG系の論文は研究としての質を保っています。地道で厳しい基礎研究ではなく、実業に近い応用的な研究なので、すぐに企業で使われる事も多く、それも研究の妥当性を証明する一つの手段となっています。
sisopt 結構誤りあると思う。SIGGRAPH(Asia)論文はTOGに自動的に載るし、TOGに載った論文はSIGGRAPH(Asia)での発表権が与えられるからそれらは同等
これはその通りです。誤った情報を書いてしまい、失礼しました。業績要件については私の知ってる方を含めての狭い観測範囲ですが、なるべく高いレベルで 2報という方が多いようです。全大学ではないことはご了承ください。ご指摘いただきありがとうございました。
あーん？ 覗き穴は無くても換気口だったりエンジンの吸気口だったりはあるだろうが。
iPhone(つーかスマホ)はレンズとセンサーは小さいけどCPUとDSPがいいからなあ
コンデジの台湾製1枚1000~2000円のSoCでどれだけ戦えるものか
世間のスマホがCortexA9積んでる頃に、MIPSの400MHzのコアとかARM9の200Mhzのコアを使ってたよ
それで画処理は全部で3秒以内と言われてもなって感じだった
DSPはDSPで、専用でなく出来合いのSoCのオマケだからお仕着せの画処理が基本で大したチューニングはできない
6年前の話だから今は状況が変わってるのかもしれないが、当時は高感度撮影するのでなければ5万円以下のコンデジはiPhoneや他のスマホ以下だった
これは間違いない
今だから書くけど、自社設計でも何でもないSoCに「自社の画像処理エンジンを積んでます」みたいな書き方をするのは詐欺じゃないのかと思っていた(どことは言わないが)
曰く、チューニングが自社流だから間違ってはいないという見解らしい
そんなのありかよ
