  |
はてなキーワード: レイヤとは
前から思っている．
どこの界隈とは言わんが，一部の閉じた問題や決定論的な問題を解くのに特化したイキリエンジニアさん達ってライブラリがあることを理由に全て簡単だとみなしますよね．
一回くらいirisみたいなトイプロブレムではなく，ちゃんとしたデータ触ってモデル作って見て欲しい．
或いはそのモデリングに必要な数理を自分で追いかけ再構成してみてほしい．
そういうものをすべて軽量言語(LL)なくしてスクラッチできるのか？ そうできなければ理解していないのか？
お前たちはイキっているにすぎない，プリミティブなレイヤに魂を奪われて本質が何も見えていない愚か者だ．
お前たちはLLを親の仇のように嫌うが，お前たちはコーディングなどという下流工程の作業に囚われているだけだ．
呼ばれたようで。
https://japan.zdnet.com/article/35081029/
影響力の大きさ
フラッシュメモリを用いたSSDは、磁気ディスクを用いたハードディスクよりも高速なストレージだが、I/Oスタックは同じだ。このため、デバイスにデータを書き込む際に生じる問題（遅延、エラー、複数のバッファ間の調整）はそのまま残っている。つまり、SSDは単なる高速なディスクにすぎないと言える。
しかしNVMは単に高速なだけではない。NVMには永続性があり、ストレージとしても使用できるメモリである、ストレージクラスメモリ（SCM）に利用できる。
純粋なSCMは、DRAMとストレージデバイスの違いをなくしてしまう。メモリとストレージを別に持つのではなく、永続的にデータを保持できる単一レイヤのメモリを持つことができるわけだ。
昔からのことナリよ。
要約：意見を上げるときの「めんどくささ」を減らせば意見は出やすくなる。
でもなんでテーブルに上がらない。それは「上げるとめんどくさい」からとおもう。
現場が思ったことがあっても言えなかったり、言っても意味なかったりする。
「この声にはこう対応する。言いにくいと思うが勇気を出して言ってくれた人は評価したい」
という意思表示をするといいと思う。
そうすると最初は中々言い出せなかった人も、チラホラと問題点上げるようになって
結果経営陣が中々聞き出せなかった現場の本音も出るようになると思う。
言っても誰も傷つかない問題は、
残業代がでないことくらいだ。出すとはいってるけど申請誰もしてない。機能してない
みんな困っていることはある
問題点は上がっていないというより、「上げたことあるけどめんどくさいからやめてる」が正しいと思う
前の会社にはgoogleformで会社に匿名で意見を投稿できる仕組みがある。
それはすると呼び出されたり経営陣から日報の返信来たり。めんどくさくなるからです。
めんどくさいっていうのって、アプリもサービスもあらゆるものにおいて障害だったりする
この「めんどくさい」を除いてあげることがあらゆるものの普及で最初にするべきなことだと思う。
前の会社では、
会社の問題点を書くと日報全返信や面談パターンだったんだけど、あれもめんどくさいと思われると思う。
全返信でくると「あ、こういうこと言うとこんな結果になるんだ。やっぱ俺は言わんとこ」ってなってしまう
僕だって色んな人に社内外関わらず相談したけど、結果、相談相手に残業のことは広まっちゃったわけだ。
これってなんかlose-loseな関係でもったいないなあと思う。
あと、一度僕が他チームが悩んでる問題点を上げた結果該当のチームが呼び出されたことがあった。
社長に「なぜ正直にテーブルに上げないんだ」といわれてたんだけど、
これもめんどうくさいとおもう。そして結果そのチームの問題点（まぁ残業代や勤務時間なんだけど。）は解消されていない。
「問題点に気づけていなくて申し訳なかった。今回こういう声をあげなかったのは何故か教えて欲しい。言いにくいなら、誰になら言いやすいかとか教えて欲しい」ていう感じで
アプリも「このサービスの価値は提供できている。あとは自由に投稿してくれ」
では投稿されない。
「自由に変える環境は整える。自主的に提案してくれ」と主張するだけでは提案はこない。
サービスと同じで小さな問題点を潰して、めんどくさいを減らしていくことが必要だ
ブラックで話題のワタミは今でこそブランドがあるから相当ホワイトになったらしいけど
それまではあそこまで話題になるレベルのブラックさで成長していたわけだ
離職率や労働環境が業績との相関がない時、むりに労働環境を改善する必要はない。
要は、優秀な人がそこには必要なはずだ。
その優秀な人が作る、もしくは見つける媒体価値をオペレーション化して誰でも売れるようにする。
ある程度それが整っても、中間層の人が抜けるとそれを維持するのも大変
主力サービスの一つを立ち上げたひとはとある上場会社で役員をしている。
あと、SEO設計で今の大きなトラフィックを築いた人も過去にいる
今は二人共いない。
そう考えると現場の改善というよりも、中間層の定着率にまずフォーカスしたほうがいいかもしれない。例えば新卒の僕が抜けようが会社的に代わりはいるだろうからそんなに痛くないだろう。
それが整った後に更に下のレイヤその下のレイヤという感じかな。
現場の人も変われば変わるほどそのレクチャーに時間割かれるから
http://anond.hatelabo.jp/20161017031727
老婆心ながら，おそらくSIer関係を目指しているだろう情報系？学生へのアドバイス
どの大学でも学生課は糞対応なので，カウンセラー通して学生課に学費免除なり，奨学金なり，対応を仰げ．
このままいくと研究室・ゼミ配属で積みそうなにおいするから，中退・途中就職（大学頼らない就職）の選択肢も考えておけ．
- http://dotinstall.com/ title: dotinstall]
- http://gacco.org/ title: gacco]
- https://schoo.jp/ title: schoo]
SIerに関係ないと思われるが，Web系への選択肢も拡がるしな．騙されたとおもってやっておけ．
最近だと技術文書をMarkdown で書く場合も多いし知っておいて損ないで．
ドットインストールにも授業がある．
基本情報持ってるなら知ってると思うが，
慣れておくといいで．ついでに言語はC++でもいいが，SIerならJava8勉強しておけ．
多分授業だけだと，実際のコード使わないと思うので，自分でインストールして使ってみるとええで．
MySQLインストールして使えるようにしておけ．基本コマンドだけええで．
後々データベースの資格（シルバー，ゴールド）にもつながるしな．
基本情報持ってるならある程度知ってると思うが，低レイヤのIP/TCP, UDPのソケット通信をCでもJavaでも書けるようにしておくとええで．
開発の話あるしね
ドットインストールにもある．
今までやったこと忘れるのもったいないし，他人に見せる意味でも技術ブログやっておけ．毎日更新とかいらんで．
Linuxインストールしたレベルで，やったことならなんでもええで．
技術者の就職面接で，（関係ない）バイトしてました，サークルやってましたじゃあんま意味ないからな．
録画して好きな時間観て見ておけ．
情報系の授業もある．
コード書くようになったら騙されたと思って読んどけ．
自分の中の名著にしておけ．
スカウト来たら，入らないにしても会ってみるとええで．
バイト大事なのはわかるが，大学の目的は，知識で選択肢拡げるというのもあるので，頑張って生きるんやで．
じゃあの．
若者の成長曲線は半端なく、おじさんエンジニアは日々恐怖を覚えます。
出る杭はちゃんと打っておきましょう。
Emacs, VIM, zsh, tmuxなど…設定のいじりがいのあるツールは理想の環境を追い求めても終わりはなく、コンフィグはどんどん膨れ上がるばかりです。
それらを「一流のプログラマは、一つの道具にこだわりとことん使い尽くすもんだぜ」とでも言って、ずっとDotfilesのリポジトリばかりいじるようになってくれれば、彼らがプログラミングに費やす時間は減るはずです。
いくらアプリケーションが作れても、低レイヤのことが分からないとダメだと刷り込みます。
「プログラムがどうやって起動するか分かってる? えっ、mainを書けばそれが呼ばれる? あのなぁ、_startというのがあってだな…」
無駄に低レイヤに詳しいおじさん力を活かして、あたかも高水準言語でオレすげーしてるのは、お釈迦さまの手のひらの孫悟空みたいなものだと、思わせていくのです。
そうこうして、若者たちバイナリエディタを眺めて、「ふむふむこのファイルは〇〇だなっ」などと口にするようになったら儲けものです。高機能なIDEを使うよりも、バイナリエディタを愛用しそこに時間を使うようになるでしょう。
安定したプロダクトは、あっという間に習得してしまい、我々おじさんたちが安定するまで四苦八苦して身につけたノウハウは、「あっ、いまはそんなことしなくても大丈夫っすよ。昔は大変だったんすねw」と一笑に付される恐れがあります。
Javascript界隈など、安定しないプロダクトを積極的に使わせるように導きましょう。そこでGitHubにIssuesを上げまくるようになれば、時間を費やさせることができるでしょうし、さらには「このプロダクトはいつまでたってもクソだから、オレがもっとイケてるやつを作ることにしましたよー」なんて方向に向かわせることができれば、しめたものです。
若者の作業スピードの向上はかなりのものです。おじさんたちの体力と作業スピードでは到底かないません。
そこで、「若いんだからそんなこと手作業でやるんじゃない。ツール作っておけば、次からは一瞬で済むようになるだろうっ」と言ってやりましょう。若者がツールを作っている間に着々と作業すませてやるのです。
プレゼンというのは慣れてないと、激しく時間を使います。若者にはイベントの登壇機会を積極的にあたえ、そこで時間を使わせてやりましょう。
「ここで、〇〇って質問きたらどうする? えっ、考えてなかった? いやー、じゃあこれも調べておかないとねぇ」
なんて、いいながらレビューしてあげて、どんどん深みにはめてやりましょう。
中のひとです。
つっても「K社（仮）で本出してる原作者」なんで社内のひとじゃないけど、まあ、二次創作サイトの利害関係者ではあります。
別のかみつくつもりも否定するつもりもなく、どちらかというと考えの材料になるようにいくつか視点提供に来たよ！
まず、「いろんなものは一枚岩じゃない」っていう大前提は頭の片隅に置いておくべきだと思うんだよ。
二次創作にあたって、その原作者の意識なんて、みんなも判ってると思うけど一枚岩じゃない。自分は「BLだろうがヘイト創作だろうが何でも来い」だけど、そうじゃない原作者の方だってたくさんいる。図書館に本が所蔵される、ということだって、いろんなスタンスがあるのは、ニュースを見てればみんなもご存知の通りだよ。
そして企業内部であっても、というか、そうだからこそ、全く一枚岩じゃないというのは多分覚えておいていいと思う。それは編集者AさんとBさんでは二次創作に対する好悪が違うという個人の趣味的な問題というレベルでももちろん存在しうるんだけれど、もっと上のレイヤの、編集部の方針問題とかいう部分でも意見対立はあるんだ。
K社（仮）（という風にふんわり書いて話を続行する）の二次創作サイトなんてのは、社長直下の、社内のかなり高い場所から上位指令として企画が始まったわけだけど、かといって、企画遂行者や協力編集部がひとつの理念で固く結ばれているなんてことはなく、もっと社内の立場であるとか、政治的な損得勘定であるとか、ぶっちゃけ派閥で駆動してるよ。
（そうでもなければ似たようなライト文芸レーベルを連続立ち上げでつぶしあうとか、サイトそのものも似たコンセプトでバッティングとか、何やってんだあれって話だ。ああいうのも「要するに手柄を奪い合ってるのね」って理解のほうが正しい）
もちろん、企画遂行者の井上氏とかにインタビューすれば、それなりに理念的なコメントは出て来ると思う（確かそういうのもどこかで発表されてたはずだ）。でも、それが「K社（仮）の堅持すべき法や理念」ではないし、その証拠に、数年でうまく利益が回転しなければ、消滅や縮小するよ。利益を得るのが企業の使命なんだから、そういう意味では当たり前だよね。今目の前のチームを駆動するときに、ディレクションとしては理念が必要だから設定した、に近い。
むしろ、あの種の二次創作を囲い込もうっていう動きは「小説家になろう」みたいなサイトが十分にマネタイズできる、っていう発見のほうが、大きな影響を与えていると思うよ。
以上が、（自分なりに出来るだけ）自分自身の意見を脱色した「K社（仮）の中の人に聞きたい」に対する精いっぱいの誠実な回答です。つまり「そこまで確固とした理念なんてないし、参加者によって考えてることバラバラっすよ……そんな買いかぶりすぎっすよ……」というもの。
次は個人的に増田に対するレス。もちろんこれもまた、原作者一名のレスであって、代表するものではない。けれど、現場の意見のひとつとして届けたい。
戦争とかはそうかもしれないけれど、「本家越える」とか、普通にあるよ。
これは自戒を込めて言うけれど、自分を含めた多くのプロが、プロになれたのは、そりゃアマチュアの多くよりは、そこそこマシな作品を作れるから、ではあるけれど、アマチュアと隔絶したぶっちぎりの差をつけた天与の作品を作れるから、ではないよ。
プロと（少なくとも作品を作る才能ある）アマチュアの間に「作る作品のレベル」に、そこまで大きな差はない。
思うに、プロになるには、作品を作る才能以外に、プロになる才能（っていうか無鉄砲さ？）みたいなものや運命みたいなものが必要なんだよ。
と入ってもここでいう運とか運命は、出版社のスカウトが見つけてくれるかどうか？ とかコネ持ってるかどうかみたいな、夢見がちな話では一切なくて、もっと人生とか家庭環境の話でさ。
だって正直言って、マンガ家にしろ作家にしろ絵描きにしろ、みんな堅気の仕事とはいえないよね。「キミ来月原稿もってきてよ、デビューできるかも」っていわれて、実際最初の印税が発生するまで、半年や一年はかかるし、しかもそれで印税貰えたからって、一生生活が安泰になるなんてのは、夢のまた夢でしょう？ 控えめに言ってもそれは将来の選択であって、賭けに負ければ、履歴書に空白が数年発生する。いくら本人やる気や才能があったって、初期段階では、家族とか、友人とかに（生活面とか理解とか）迷惑かけざるを得ないんだよ。チャンスが訪れた時にそれに乗っかることができるか？ ってのは、そういう部分が大きい。家庭の事情でプロを断念するなんてざらに訊く話だ。
つまり、世の中には、描く作品の面白さはそこらのプロ以上だけど、いろんな事情でプロではない人――ってのがたくさんいるんだよ。もっともそれは１０年前よりはずっと状況が改善してて、サラリーマンをする傍ら書き溜めた原稿が、Web人気経由で単行本化！ みたいなケースが増えてきた。昔よりは、才能があるのに事情で埋もれる、は少なくなったと思う。でも、やっぱり、確率論的に「強いアマチュア」ってのは絶対にいる。
そして、そういうハイレベルな二次創作をする場合、キャラや世界設定が固まってるっていうのは、思ったよりも作品のクオリティに対してアドバンテージをもたらさない。つまり「二次創作でも別に敷居低くない」んだよ。
お話を作るうえで一番難易度が高いのは、エピソードを作って物語を駆動する部分で、キャラ設定や世界観設定って、大事じゃないとは言わないけれど、最難関じゃない。
（もちろんキャラを並べてエピソードは別作品から移植して、あるいはいきなりベッドシーンとなればそれはまた別の話だけど）
上記の視点で見る「この人なんで二次やってんだ？ とっとと商業書けばいいのに」みたいなアマチュアの人って、結構いる。たぶんそういう人にとって、二次をやるのは本当に愛情なんだと思う。
つまりここでいいたいのは「増田が思うほどプロのアドバンテージって絶対じゃないよ」ってこと。もちろん手塚治虫とかレジェンドクラスの人はまた別だけど、いま現代でいえば、いろんなプロの人がいるから、いっしょくたに神格化はできないよ。
最後になるけれど、いま、ものすごい数のマンガが出てラノベが出て深夜アニメもやってて、百花繚乱だ。飽和状態にさえ、見えると思う。
でも、個人的には、全く足りてない。
何が足りてないって、市場規模や読者が足りてないんだけど、でもそれって送り手とワンセットなんだよ。
二次創作は物語の一形態だと思う。物語が好きで、二次創作が好きだ。物語を作るのに必要なものは、物語りたい気持ちだ。物語りたい気持ちは、読む経験でしか培われないと思う。つまり、優秀な物語製作者は、過去、優秀な読者だったはずだ。
日本には創作者も読者もまだまだ足りてない。どんどん増やすべき。だって個人的にそういう世界の方が好きだから。だからみんなでバンバン読んでバンバン書けばいい。
業界としてもゼロサムゲーム（作品Aの読者が増えたら作品Bの読者が減る）なんて感覚は、さらさらない。もちろん自分自身にもない。むしろ、人気作品が増えてジャンルが盛り上がったほうが、みんなが幸せになると思ってる。
一枚岩じゃないので個人的なことしか言えないけれど、新年的に、そう思ってる。
読む量は増えたが書く量が減ったことに起因するのではないかと思ったが、英語に関して言えば読むどころか聞く量すら激減していることに気づく。これで翻訳を生業にする夢を諦めきれていないというのだから驚きである。高校大学と授業や試験で英語を扱ったときも「自分は中学英語の知識だけで問題を解いているなあ」と思っていたふしがあるが、まさかここに至るまでその意識を捨てきれていないというのはいかがなものか。むしろ劣化しているとさえ感じる。
この現状を打破するためにも積極的に英語に触れていこうと思うまではよいのだが、いざ自由な時間ができたところで訳しかけの『緋色の研究』に手を付けた試しがない。翻訳が趣味と言っていた自分は何だったのか。ただの就活用のアピール項目に過ぎなかったのか。お前の情熱とはその程度のものなのか。社会人になったら新聞の投書欄に投稿したいと言っていたのではなかったか。
と、ここまで考えたところで、なぜここまで翻訳業に固執するのかと思い直したところ、「自分のしたことが目に見えて分かる」ことに喜びを感じる自分というものに気づく。大企業にいるとそのようなことはそう起こるものではないし、それゆえに半ば業務に対する情熱を（半年も携わっていないのに！）失いかけているのだろう。さらに欲を丸出しにしてしまえば褒められたいのだろう。贅沢である。褒められなくとも自分が何かを創りだし、それに満足のいくことのできるような仕事がしたい、というのが恐らく本音だ。だがそのような職に就ける人間が果たしてどれほどいるというのか、と夢物語の一言で片付けてしまえばそれでお終いであるのに、いかんせん身近にそういう人がいるものだからどうにも未練がましくなってしまっているらしい。
なんだお前は、つまるところ物を書いて飯を食う人間になりたかったのか。
likeとcanは動詞と助動詞、レイヤすら違う話なのに。昔から文章にすることでストレスを発散してきたというだけで、どうしてそこまで思い上がれるのだろう。少しばかり英語の成績がよいというだけの、ただのいち理系学生だった自分が、中学生から抱く翻訳作家という夢を未だ捨てきれず、性懲りもなくくすぶらせ続けている。なんと往生際の悪い。だが文字通り今が往生際になるとすれば、きっとそのことを後悔するのだろうと思うと苦笑せざるを得ない。
我が家にインターネットという近代的通信網が導入されてからしばらく経ち、国語の授業で作文をするというとき、どうにもネットスラングを入れてしまいそうになる自分にふと気が付き「ああ自分はこんな文章しか書けなくなってしまったのだな」とショックを受けたことを思い出す。恐らくそれ以来、自分なりに人一倍言葉遣いに用心するようになったのだと記憶するが、それも言うなれば自己満足でしかなく、「言葉遣いが正しい」ことは「いい文章である」ことの十分条件ではないのである。
もっと言えば「いい文章である」かどうかは読み手が判断するものであり、いくら自分で「いい文章が書けた」と思ってもそれが万人にそう思わせるものであるとは限らない。「いい文章だ」と感じる読者がなるべく増えるようにするためにできる最低限の努力なのだ。そんな自己満足の世界で生計を立てられるほどの能力などあるはずもないのに、こうして毎日夢を見ているのは、まだ「お前には到底無理だ」という現実をはっきりと突き付けられていないからであり、それはある意味で幸福なことなのかもしれない。
そうだね。[上]君みたいな人材を伸ばすために、技術的にもビジネス的にもお互いがやりがいのある案件を、中年が生み出していかないとだめだね。
[中]はまだ様子見な部分があるけど、[下]は、来年以降に配属されてくる[上][中]にどんどん抜かれていくだろうな。
自分も理系でもなかったし、ITへ転職する前は営業職だったので、ある程度のレベルまでは誰でも到達できると勝手に思ってた。
向き不向きって本当にあるんだね。
幸いうちは上流から下流。下流もアプリやインフラなど。アプリもwebもモバイルもあるし、プログラムっていうカテゴリならミドルウェアのモジュール作ったり、ドライバ作ったりもある。今後はbigqueryやディープラーニングみたいな分野も力を入れていく。
[上]君にはいろんなレイヤを。[中]君は2年くらいのスパンで開発のイロハを。[下]君は、申し訳ないがおそらく手をかけれるのは今年いっぱいくらいだろうから、開発から手を引かせるかもしれない。ひょっとしたら他に向いている作業があるかもしれないしね。製品サポートとかセールス周りとか。
自分の部署は毎年数人だからなんとか見てあげれるけど、大企業で数十~数百で新卒とってるとこは、派閥も面倒だろうし、やっかみも多いだろし、大変だろうな。
前々から思っていたけど、ここ最近前にも増して女という生き物が邪魔すぎてストレスが溜まる。
俺が言う「邪魔」というのはなにも『女性の社会進出がぁ～』とか『人間、やっぱり外見より内面のほうが大事だよね～※』という高いレイヤの話ではない。
むしろレイヤ1＝物理層。文字通りの意味で「邪魔」なのである。
日々感じる事を挙げるとこんな感じ。
（歩きかたが邪魔）
歩道の真ん中付近を歩く。微妙に横のスペースが狭いので追い抜きづらい。
それでも追い抜こうとすると、何故かこちらに寄ってきてぶつかりそうになる。
そもそも後ろや死角に対して全く注意を払わない。
まあ言いたいことは上と同じ。
肉選ぶのにどんだけ時間使ってるんだよ。どれ選んでも大して変わらんから。お前がどかないと俺が買えないんだよ。
あとレジ。金払うのになんでそんなに時間かかるんだよ。ポイントカード出すなら予め用意してろ。小銭がきっちりあるか穴が空くほど財布の中見渡してんじゃねーよ。
いわゆる「ベビーカー問題」ね。まあこれに関しては正直言って寛大な心を持っているつもりではあるんだけど、やはりラッシュ時とか勘弁だし。むしろ同じ場所に居合わせてしまった自分の不運を呪う感じすな。
しかし女の方が圧倒的に多いのだ。少なくとも俺はそう感じる。
しかし社会生活においてはどうしようもなく邪魔な存在でしかない。
日常生活において器量の良い女が増える事を切に望む。
他人に、人間に、自分に、感情があるかないかってのは哲学的分野なんだよ。
人工知能にそれがないとすることは可能なんだけど、じゃあ同じ定義を用いた場合、人間にそれがあるのかないのかってところに問題が飛び火する。
この場合「俺がそう思ってるから俺がこの世界の法だ」ってのは通用しない。
もしそっち方向に議論を向けた場合、「じゃあみんなで（自治体で、国で、世界で）人工知能に人権があるかないか投票しましょうね」ってなるだけで、それは「事実」のレイヤじゃなくて「同意」のレイヤになるって話だ。
もし増田が「（そんなこと議論するまでもなく世界全部は俺に同意してくれるはずなので）人工知能に人権はない」って言ってるんだとすると、そりゃ議論の態度じゃなくて、ただのおバカって話になっちゃうわけだ。
二種類のレイヤが混ざってる。あと、スクリプト言語のレイヤは要らない。例は突っ込みどころが多すぎるので触れない。
コンピュータ上で動作するもの全て、システム周りの低レベルプログラムを含めてアプリケーションとして括るのはちょっと乱暴。
OSを書いてる人間から見ればユーザープロセスは全部アプリケーションだし、twitterから見たらAPIを叩くものは全てアプリケーションだろう。
基本的には外から持ってきたソフトウェア基盤の上に作るものを総称してアプリケーションと呼ぶのがより実態に近いと思う。
だいたい合ってる。ただ、高級言語より上にあるのは変。スクリプト言語は高級言語に含まれる。
だいたい合ってるが、自然言語云々は余計。例えばS式は自然言語のアナロジーではない。単に比較問題で抽象度が高いかどうかだけの区別でしかない。
OS云々は関係ない。OSもミドルウェアやライブラリーは使う。一般には自分が書いてないソフトウェア・コードをライブラリと呼び、何かと比較してより低いレイヤにあるライブラリをミドルウェアと呼ぶ。
問題ない
ここが一番まずい。まず、中間コードはコンパイラが内部的に処理の段階を分ける仕組みであって、出力ではない。
また、インタプリタはソース言語を逐次実行するのではなく、正確には中間コード（抽象構文木そのもを含む）を逐次実行するものだ。
他のプログラムで実行するコードを生成するものがコンパイラ、自分自身でコードを実行するのがインタプリタ、という区分けがわかりやすいと思う。
ただ、現実的にはインタプリタは内部的にコンパイラを持つし、コンパイラも最適化の過程では内部的にインタプリタを使う。
昨今はLLVMみたいに、コンパイラなのかインタプリタなのかコンテキストによって変わるものもあるので、正直区別しても意味がないと思うけど。
なんかレイヤが混ざってる気がするな。
確かに最適化っていうのはプラットフォームに依存するんで、ハードやインフラが変化すれば不要になるものも多いよ。でもさ、ハードの進歩を1年待つより今出すことに意味があるってことはよくあるわけさ。
このゲームエンジン重いけど最適化しても次世代機ならどうせ無駄になるんだから、最適化やめましょう、ゲームタイトルは次世代機出た後にリリースしましょう、とか言ってたらいつまでたってもワクワクするものは出てこないよ。
で、アプリのプラクティスが下層に影響されるのはそのとおりなんだけど、例えばかつて中央のCPUで処理してたのが分散してローカルで処理しましょうってなってそれがまたサーバにアプリ乗っけようってなってそこからさらにいやクライアントにも振ろうってなって、でもこれって決して単に行ったり来たりしてるだけじゃなくて、スパイラルを描いて少しづつ昇ってるんじゃないかな。環境が一巡したときに、昔の技術のうち汎用性の高いものだけが蒸留されてさ。
http://jvn.jp/jp/JVN81094176/index.html Android OS がオープンリゾルバとして機能してしまう問題
ってやつね。
報告者の森下さんが「とある方から私個人宛で報告をいただき」と言っているので、その「とある」人として少し背景を書いてみようと思う。
https://twitter.com/OrangeMorishita/status/581314325853306882
発見のタイミングは、Android 4.2 のソースコードが出て少しして、ぐらい。この時点では、Android全てが修正されていなかった。当時、 CVE-2012-3411 (dnsmasq が libvirt の特定の config で使うときにオープリゾルバとなる) が発表されていて、これと同じ問題があるのでは、と調べた結果だった。Android のテザリングは、framework の指示を netd という daemon が受け取りネットワークの設定を変更して実現されている。で、テザリングのクライアントにDHCPでプライベートアドレスを配りDNSのリゾルバを提供するために、必要に応じて netd から dnsmasq が起動される。
そのころ、Android端末の製品開発で、スケジュールに珍しく余裕があり、わりと好き勝手できる状況だったので、AOSPのソースコードを精査していた。
いくつか、セキュリティ問題をみつけて、ものによって単に修正、修正と並行して Google に会社から報告、あるいは単に Google に会社から報告、ぐらいの対応をした。
この問題は、Google に報告だけ、の対応をとった。なぜかといえば、 次のような事情があった。
で、この報告の結果なのか、他の報告もあったのか分からないが、Android 4.3 のリリースに修正が含まれていた。もっとも、国内のほとんどのスマートフォン端末は Android 4.3 はスキップした。森下さんへの個人的な連絡の最初は、Android 4.3 発表より前。
正直、この問題のリスクは、端末ベンダ、および端末ユーザにとっては相当に低いものに見えた。3GやLTEの国内キャリアで、外から端末へ DNS query を許すところはほとんどないだろう、というのは直感的には思っていた(これが間違っている場合は、影響がケタ違いに大きくなるところだった。上流も下流も Wifi という構成のテザリングをAndroidは持っていないので、上流を Wifi と仮定すると、残るのは USB と Bluetooth だけになる) 。NAT される場合ならなおさら。
ただ、ネットワークインフラにとってのDDoSというのは、個々にとってはリスクが低くても、それが何百万台、何千万台とあれば影響が出てくるんじゃないか、という気もした。ちょうどそのころ、森下さんが DNS リフレクション攻撃に関してベンダ等への啓発を始めていたのが目に留まったので、森下さんに連絡してみた。脆弱性対応としてハンドリングするのがIPA や JPCERT/CC になるとしても、ネットワークインフラへの影響ということであれば、表に出ない話も扱える方が報告したほうが適切だと思った。私は原理的には分かってもネットワーク運用に関しては業界の外にいるからね。
事情は知らないけど。
ひとつの可能性としては、「対応未定」の端末、おそらくは対応しないことになるのだろうけど、それらの現役感がなくなってきたからじゃないかな。Android 4.2系が端末のラインナップとして長生きしすぎたせいで、けっこうOSバージョンアップではなくセキュリティ修正としての対応をする製品が多くなったのかなぁ、という気もするけど。
もうひとつの可能性としては、当初よりもインフラへのリスクが上がっているのかもしれない。Android 4.2系の端末で修正リリースが去年の秋とか、これからの近未来とかのが多い、という状況からするとね…。
Qiitaに書こうかと思ったけど、言いたいことも言えない、こんな世の中じゃ。
モバイルファースト、APIファーストな文脈でハイブリッドWebをやってきた目からすると、サーバーサイドでHTMLを生成してページ遷移させるなどという90年代調のクラシカルな発想を基本に据えるフレームワークはとても斬新に思えました。HTMLをゴリゴリ生成するなんてよほど特殊な最適化をしようとするのでなければそもそも発想として出てこないです。それでいてDSLやメタプログラミング等のテクニカルな技法が宝石のように鏤められている様はまるでエジプト時代の骨董品を見るかのような趣がありました。turbolinkなどは、かつて表計算ソフトに出しゃばっていたイルカを思い起こさせる味があります。かつて慣れ親しんできたSPAが星のように遠い存在になりました。
Web界隈の人々がモデルだとかアクティブレコードだとか"MVC"だとかを非常に具象的に話す様を見るにつけ、お前らどんだけPofEAA読み込んでるんだよと畏怖していた時期が僕にもありましたが、どうやら彼等はRailsのクラスやディレクトリという特定の実装について話していただけだったようです。Modelという概念もこれだけ肥大化してしまったら、オリジナルな概念で彼等と会話するのは諦めるべきかなと思いましたし、Railsの"MVC"をアンクォートして語るのはもはや害悪であるとすら感じました。
Rails界隈の人がよく「Railsの流儀」や「正しい"MVC"」というのを口角泡を飛ばして議論しているのを目にするのですが、おそらく外に広がる不条理で火傷を負って快適なRailsの世界に引き篭もった結果としての一種のストックホルム症候群なのだなと思いました。いまやAjaxとかWebsocketとかWebRTCとかを組み込もうとする至極真っ当な方法論がとてつもない高難度に見えてきます。設定よりも規約、というのも一つの方向性だと思いますが、ドメインやサービスレイヤの名前空間を構築しようとしたりコードジェネレーションしようとしたりしただけで地獄のようなCircular Dependency罰を受けてしまったので、自分がとても間違った事をしているような気がしてしまいました。とはいえConcernsに特別な名前や役割を与えられても正直しんどいので、皆が皆libにゴミを放り込んでいく様子にも納得がいきました。
RailsをAPIサーバーとして使おうとするとまずビューが無くなってMとCだけになりますが、いわゆる"MVC"の文脈で育ったエンジニアがなぜ息を吸うようにFat ControllerやFat Modelを作ってしまうのかという事が良く分かりました。多くのRailsのリファクタ手法と称されているものはクラスを書くファイルを分割する事以上のものでは無いように思えたので、Rails使いを大きめなAPIサーバー案件に回すときはセットポジションでDDDの青本を投げつける必要が有るなと思いました。
ビューとコントローラを結合させた場合、結合テストはCapybaraとかのBDDでマークアップサイドとの干渉を恐れながら強い気持ちでメンテしていくしか無いのかなと思いました。おそらく脳に電極を埋め込んでいるか、緑色のランプを見るだけでハイになれる特殊な人にしか生き抜けない闇が垣間見えました。コントローラを薄くしてサービスレイヤを挟めばその辺りもうまくいけそうな気がしましたが、ビューからヘルパーやモデルがいくらでも透けて見えてしまうという状況では裏側の完全性に自信を持つ事は難しそうでした。
ビューがRubyを叩いて永続化レイヤと直接コミュニケーション出来るというのはとても生産性が高いのだろうとは思いましたが、こうして出来たパーシャルやら何やらをデザイナーとどうやって共有するかを考えると頭痛が痛くなりました。おそらく適当に切り出して綺麗な空間をassets以下に構築した上でpublicにRPCのような窓口を備えたゴミを量産していくのかなと思いましたが、もっと綺麗な方法はあるのかもしれません。でもきっとRails案件に関われるデザイナーはRubyもバリバリ書けるに違いないはずなので、ここが問題になる事は無いのだろうなと思いました。
RESTはとても美しいパラダイムではありますが、そもそもHTTPがさほど美しくないので歪んだ空間には目を背けるか勝手解釈を与える事で人は初めてRESTfulを名乗る事が出来るのだと思います。GETがbodyを(公式には)持たないという事について美しい説明を与える事は出来ないでしょう。サーチAPIはどうしますか。ステータスコード足りなくないですか。401エラーはどうしますか。そしてRESTはあくまでリソースを抽象化する美しい概念なので、アクションや副作用については貧弱です。動詞が足りないですし、一般動詞に狭義の意味を与えてドキュメントするのは二度手間にしか見えません。PUTには冪等性があるべきみたいなこだわりは家の猫にでも説教してればいいと思います。というわけで、REST的な設計を拝借することはよしとしても、「○○はRESTでは無い故云々～」みたいな注文はやめて頂きたいものです。
とか言わないで欲しいです。こういう時にセットでPHPをディスって悦に浸るのは知る限りRubiestとPythonistaと中学生だけです。それにこれはあくまでサーバーサイド初心者の感想なので、想像するにこれ系のFWは多かれ少なかれ似たような不満を抱えるものなのかなと思います。というわけで、おそらくこれから選択肢がある限りはRailsを使い続けると思います。
10年くらいWeb開発業界にいて、ここ最近はRailsでアジャイルな高速開発的なものの周辺にいる。今は開発者〜マネージャの間を行き来しつつ顧客窓口〜実装まで一通りこなしている。
あちこち渡り歩いて色々なエンジニアと一緒に仕事をしたり、お客さんに頼まれてエンジニアの面接やらに顔を出したりすることがあるのだが、ここ最近のWeb開発はますます主力級のゴリゴリ書けるエンジニア（いわゆるフルスタックエンジニアと呼ばれるものも多分ここに入る）と大したことのないエンジニアの差が開いてきたように思う。
主力級のエンジニアは1〜2回がっつり打ち合わせしてプロジェクトの重要点とざっくりラフなイメージを共有すれば、どんなに遅くても1週間もすればプロトタイプが上がってきてお客さんに見せつつ微調整し、いわゆるアジャイルとかスパイラル開発的なことができる。デザイナがいなくてもBootstrapでとりあえず最低限の見た目を作ってくれるので、とりあえずデザイナ無しで開発して最終的にお客さんが気に入らなければWebデザイナに見た目整えさせてテンプレ取り込み、という開発がここ最近のメイン。
ソースコードもフレームワークやRESTfulの基本概念が理解されているコードなので、後日の機能修正の時にそのエンジニアが動けなくても自分がフォローして修正することもできる。
仕事もしやすいし、実質1〜2人の稼働でサクサク進められるのでコミュニケーションロスもなく楽しい。
一方、大したことないエンジニアは前述した流れが全くできない。
まず決定的なのは、開発が遅い。ちょっとしたデザイン無しのCMS（リッチUIなし）をRailsで書くのに1週間かかっても終わらなかったりする。これじゃ生PHPで書くのと変わらないかそれより遅いので、Rails使う意味がない。
次に、品質が低い。できあがったと言われて念のためチェックすると、基本的なCRUDレベルでエラーが出たり、お客さんに見せるプロトタイプだと言っているのに初期データ（seeds）の整備すらされていなかったりする。本人のローカル環境で動いてるけどstaging環境にdeployすると動かないとかはよくある。
パッと見に分からない部分もひどくて、ソースを確認すればあちこちどこかからコピペしてきたコードのつぎはぎで、HTML規約違反やJavaScriptのエラーまで放置されていたり。あと実装しましたと口頭で言っていた機能がソースコードコメントではTODOになっていたこともあった。
最後に、成長しない。開発上詰まった所なんかを主力級エンジニアに聞くのは構わないのだが、表層的な理解に留まり応用が利かない。30分〜1時間も主力級エンジニアの時間を浪費しながらもまた同じ様なところで同じ様なミスをする。自分もよくプチ勉強会みたいな状態になったときには参考図書や技術資料のポインタを投げたりしているのだが、参照先を見て深掘りすることはほぼない。
厄介なのは、こうした大したことないエンジニアも、Railsであればあちこちのチュートリアル記事や書籍を参考に、そこそこそれっぽく見える自作サービスくらいなら作れてしまうという点にもある。
彼らの作るサービスはまさに書籍やチュートリアルサイトのコピペの集大成だが、個人が趣味でやっているサービスとしては十分に動く。そして周りには「エンジニアです。個人でWebサービスも公開してます」となる。サービスの外からは内部のコード品質などはわからない。
プライベートで開発するのはむしろ奨励しているのだが、彼らはその拙い（あえて「拙い」と書く）サービスでもって「俺はもういっぱしのエンジニアだ」と勘違いしてしまっている様に思える。
だが違うのだ、お前が書いているシステムは「とりあえず動く」レベルのものであって、受託開発としてお金をもらってお客さんに納品するシステムや、数千万〜数億の売上を左右するような業務システムではその素人クオリティでは話にならないのだ。
適切な例外処理、担当者がミスしにくい管理画面の設計、お客さんの想定ユーザ数に耐えられるレベルでのスケールする設計、開発者が入れ替わっても保守が続けられるようにするための最低限のドキュメントなど、production level qualityに足りていない部分がいくらでもあって、そこまで考えられて「主力級エンジニア」なのだ。
こうした主力級エンジニアと大したことないエンジニアの谷は以前から感じていたが、ここ最近ではさらに顕著に感じるようになってきたように思う。
例えば、主力級エンジニアはRailsだけでなくミドルウェアやprovisioning（chefとかansible）、最近ではdockerやCI、AWSの新サービスなどについても各自追いかけていて、自分も含めてちょいちょい議論をすることがある。「最近のアレってどうなん？」とか「はてブでやたらXXX流行ってるけど、これって結局数年前のYYYの焼き直しじゃん」みたいな。
そんなところに大したことないエンジニアもはてブやRSSなどで用語は聞いたことがあるので混じってくるのだが、まず前提知識がなさすぎて議論にならない。大体「XXXマジすごいっすね〜（意訳）」で終わっていて、その技術の背景や今後どうなりそうか、自分達が取り入れることで業務効率や開発の楽しさが改善するのかといった視点がない。
他にも、ちょっとしたトラブルシューティングの際も、基礎がなさ過ぎて問題の切りわけができない。問題の原因がネットワークレイヤなのか、ミドルウェアなのか、アプリなのかすら判断できなかったり、そもそもアタリを付けるのが絶望的に遅かったり勘が悪い。
単に作業が遅いというのではなく、問題の切りわけというエンジニアとして最低限できないといけない事すらおぼつかないケースも見かける。
こうした大したことないエンジニアは速度・品質・難易度面で新規開発プロジェクトにアサインするリスクが高いので、必然既存サイトの運用・メンテ（ちょっとしたページデザインや文言修正）といったタスクが回されるのだが、最近この辺りも仕事がなくなってきているように思う。
というのは、お客さん側にRails Tutorial程度の開発知識を持っている元エンジニアや趣味でちょっと触ってみましたレベルの人が増えてきたから。これは恐らくRails特有な所（自作Webアプリ簡単に作れる啓蒙がなされている）がありそう。
ちょっと考えてみれば、文言修正やデザイン修正する程度の作業、外注に頼むと数万かかる上に見積やら稼働確保やらで数日〜数週間待たされるのに対し、担当者が自分でやってしまえばすぐに済む話というのはちょっと考えれば分かるわけで。
# もちろんそれでも保守契約や責任分解点の関係で外注するケースはあるだろうが、Railsを採用するようなWebサービスは速度重視のことが多い
そんな中、この「大したことないエンジニア」の人達はどうなるんだろうなあ、と思う。開発会社ではなくRailsシステムを運用しているユーザ企業に行けば多少は需要あるのかなーとも思うけど、ユーザ企業はできないエンジニア雇うほど余裕もないだろうし。
せめてコミュニケーションスキルが高いとかそういう利点があればいいんだけど、変に自分が「エンジニア」というプライドがあるのか、窓口とか管理方面は率先してやろうとしなかったりもするし。
早めに「エンジニア向いてないよ」と言ってあげるのが良いのだろうか？
