はてなキーワード: ソースコードとは
ためらわずに指摘するけど、
指摘した人が部長(偉い人)で、それ間違いって言えずに
プロジェクト迷走ってのがあってな(w
真面目な話ソースコードのレビューなんて10年以上のキャリアがないと
むつかしいよ。
まとめりゃいいかというと、何でもかんでも1つにまとめたがゆえに、小さな修正で何十箇所にも影響が出て被害甚大って事もあるし
塩梅がむずかしい。
技術者を抱える組織のマネージャーって、専門知識についても理解があって(もちろんほんとのエキスパートには敵わないけど)、
部下のそれぞれの担当領域の報告について、今後どう進めるかの決定権とその責任を持つ、という認識でいいのだろうか。
その決定によって、今後の方向性とそれに伴う予算やリソースが決まるわけだし。
部下の報告の方法は、ソフトウェアであれば、上司にソースコードや要求書読ませるのは職務放棄とは思うが、
取りうるいくつかの選択肢と、それぞれの長所短所とかかるコスト等の分析までしていれば最低限はOKだろう。
全部を定量的に可視化できれば理想だが、定量的に表現するのが簡単じゃない(時間や手間がすごくかかる)場合や、
そもそも方法が確立されていないような場合、可視化しきれなかった部分は仕事としてみなされない。
決定する対象にもよるが、自分が管理しているチームの定量化できない部分の事情にも理解を持ち、
ある程度アナログな決定ができるのがマネージャーとしての能力ではないかと自分は思っている。
全部定量的に示せたら、それ既にマネージャーの判断要らなくないですか。
専門知識とか、年々変化している技術動向や開発環境について、新たに勉強しようとしない人が出世して、
「俺がわかるように説明しろ」て言ってるのはなんでだろう。
015-06-27ブログ記事のコピーと右クリック禁止でパクリ転載防止する方法トップ >ブログ運営ブログ記事のコピーと右クリック禁止でパクリ転載防止する方法右クリック禁止とコピー禁止のCSSを紹介します。これでブログの記事をパクられた。画像を勝手に利用された、というのが多少防げる。まあ著作権法違反は親告罪なので探して、訴えないといけないけど、その手間は多少減るでしょ。ビックするほど情報リテラシーが低いのでこの程度でめんどくせってなります。CSSでテキストのマウスドラッグでの選択とコピー禁止CSSのエリアに以下内容を記述することで、テキスト選択とマウスのドラッグを禁止してコピーを防止することが出来ます。body{user-select:none;-moz-user-select:none;-webkit-user-select:none;-webkit-user-drag:none;-khtml-user-select:none;-khtml-user-drag:none;}下書いたのに実際にやってないwwあれ?いれた?まぁ、あとで削除しとこまあちなみにこのブログで採用しているからコピー出来ないから簡単にできないよ!!って人いると思います。CSS解除して出来るようにするのが優しさだと思いましたが、めんどくささを体験してもらうためにそのままにします。そのうちもとに戻してるかもね!コピペさせてよ!という人向けにはてなブックマークに書いといたのでそこからコピーすればいいよ。ちなみにこれはFirefoxとsafariとGoogleChromeで有効で、あの憎きIEには通用しないので別の対処方法を入れます。あと右クリック禁止はこれだけだと出来ないのでそれもあわせて対策ちなみにはてなブログでスマホとPCのデザインをわけていると、PCの デザインCSSに入れてもきかないっぽいので、細かいこと角のめんどくさいので適当にスマホ用のデザインページで<style></style>でくくってフッターにでも突っ込んでおくといいよ。それでとりあえず使えるからJavaScriptで右クリック禁止でコピーを禁止する右クリックで画像保存などができるので、画像保存禁止対策とインターネットエクスプローラー通称インターネットをみるやつの対策をジャバスクリプトでテキストのコピー禁止対策をします。<body></body>の間に以下のジャバスクリプトを記入<body oncontextmenu='return false' onselectstart="return false">はてなブックマークにコメントで書いといたのでそこからコピーすればいいじゃない!これで右クリックの禁止とIEでテキスト選択とコピーができなくなります。はてなブログならフッターエリアにでも突っ込んでおけばいいと思いますよ記事を引用コピペしたい場合IEでジャバスクリプトをオフにするまあジャバスクリプトはオフにすれば回避されますが、どうせコピペしてパクるような人は、その程度の情報リテラシーなのでほかのサイトに行ってコピペすると思います。世の中の記事はだいたい誰かが同じようなことを書いているものです。調べればなんでも分かるのはそのおかげですし。普通に引用したい人はIEでジャバスクリプトをオフにするか、ソースコードからコピペすればOKです。はてなブログはRSS全文配信なんでRSSからコピペできるはてなブログの場合は、パクりたいブログ記事をRSS登録すれば、RSS経由で記事を全部一気にコピペしてパクって転載することが出来ます。何でそんなの紹介するの?と言われそうですが、どうやってぱくった!!アップした瞬間にどうやってと思う人が出てくるからです。RSSからパクられないようにするには全文配信のはてなブログをやめればいいんですよね。ある程度ユーザー確保したら、WordPressあたりに引っ越せばいいんじゃないですかね。これで対策はできます。そもそもやだ!ぱくられたくない!と最初から思う人ははてなブログ以外を利用するという選択も必要ですね。パクるのをめんどくさくさせて他でパクってもらう対策ですね結局はパクられる対策としては、めんどくさい、なんかちょっとやばいかもと思わせて自分のブログでパクられる確率を減らしておけばいいんです。コピペ出来る方がそのサイトでわからないことがあったらすぐに検索できるからやらない方が便利よ。これやると、引用して言及してくれる人とはいなくなりますので、まぁ、いちいちやらないくてもいいとおもいます。今回は試しにこんな方法もそういえばあるよって感じで紹介。記事がパクられたら楽しんで記事ネタにしてストレス発散キュレーションメディアやバイラルメディアでパクられるのは、まあよく言われる有名税的な感じで仕方ないわ的な感じです。親告罪だしみつけだすのめんどくさいし。もし見つけたらそこで怒るよりも、パクられた時に楽しんで、このサイトにパクられた~!記事ネタ増えた~!やったね、試しに少額訴訟でも起こしてみようとか、プロバイダやキュレーションメディアなどに情報開示請求してみた。とかそういう遊びをして見るといいと思います。パクった人じゃなくて、ブログサービスなどを提供している会社やパクリメディア本体に集団訴訟してみた。とか遊べばいいんじゃないんですかね。テキストなんて海外で英語翻訳されたらもう調査するのも大変だし。100%防ぐのは無理ですからね。死んでから国ごとによって違いますが著作権なんて切れたら無料で使えるようになるし。あまりイライラしてもしょうがないです。まあ著作権は権利者の保護と文化の発展の両方の意味合いがあるので、文化に貢献した!とか思っておけばいいんじゃないんですか。
昔から、同時に視界に入らない情報を引き継いで処理するのが苦手だ。
教科書の前のページに書いてある表と、次のページの記述を行ったり来たりしながら見比べる、みたいな作業をイメージしてもらえれば近いと思う。
何回行ったり来たりしても、ページをめくると何がなんだったのかきれいさっぱり忘れていてまったく思い出せない。
そのうち自分が何を調べようとしていたのかすら分からなくなったり、無理やり思い出してもねつ造された記憶だったりする。
結局、どちらか一方をノートや付箋に書き写して、二つの情報を並べてようやく確認ができる有様。
並べて見比べながら進める作業も苦手ではあるけど、ページめくりとかで一旦視界から消える場合よりはまだマシになる。
どーも気合いや根性ではどうにもならないし、かといって、いちいち丸暗記するレベルで覚え込んでから進んでいては時間がかかって仕方ない。
仕事をし始めてもマニュアルを読むとか資料を読むような時にものすごく苦労しているし、
プログラムのソースコードを眺めていても、昔誰かが書いた画面分割しても1画面に収まらないような長い処理とかが出てくると、
途端にその部分を読んで理解するだけで一日が潰れてしまったり、一日がかりでも通して読み切れなかったりする。
根本的に「さっき見たものをちょっとの間正確に覚えておく」みたいな能力が欠如してるレベルで足りないのだと思うのだけど、なんというか、昔思っていた以上に生き辛い。
前から言おうと思ってたんだけど、朝飯ちゃんと食べたほうがいいぞ。俺もうつの気がある方だが、朝飯抜いて働くと午後ヘロヘロになるわ。ソリティアでやり過ごす日はいいんだけど、ガチで熱中した日はヤバイ。帰宅時に電車の窓に映った顔見ると、まるでゾンビのミイラみたいになってる。つってもまあ、こういうのは個人差があるから、一概には言えないね。はてブには”朝飯はむしろ食べないほうがいいんだよ、胃に負担をかけるから。朝はうんこタイム”派もいるみたい。
それに慣れるまでは、面倒くさいしな。でもまあ、夏は体力使うからな。暑い日にクーラーがキンキンに効いた部屋と蒸し風呂みたいな満員電車を行ったり来たりすると、相当消耗するから、ビタミンCはとったほうがいいぞ。100%ジュースとカロリーメイト(フルーツ味)が俺のお気に入りだった(チョコレート味はやめておけ。チョコレートには石炭が入ってるんだ。黒は石炭の黒だ。他に黒い食いもんがあるか? って高校の時の山岳部の先輩が真顔で言ってたので、当時から俺はフルーツ味ばかり食べてた。よく考えるとバカだ)。
夏バテとか甘く見ないほうがいいぜ。ビタミンCと、あと、ビタミンB1とアリシンだ。これが効く。つまりは”豚肉と玉ねぎ”。大事なことだから太字で言ったぜ。これも人によると思うけど、俺なんかは夏バテがヤバイ時はマジで眼の焦点が合わない。ボーっとして、7の素因数分解さえできなくなる(えーっと2と3?)。ところが昼飯に豚丼食べるとあら不思議。瞬く間にカタタタタカタタタ ターン! に早変わり(うるさい)。豚のビタミンB1の効果を玉ねぎのアリシンが超加速するらしい。近くにないから今はいけないけど、松屋はさぞ繁盛していくことだろう。
ところで、医者に相談して薬変えてもらう、ってのはどうだ。医療費が高い、っていうなら、低額で診察してくるとこがあるんだぜ。
http://www.min-iren.gr.jp/?p=20120 解説記事へのはてプ:http://b.hatena.ne.jp/entry/bylines.news.yahoo.co.jp/fujitatakanori/20140221-00032867/
あと、ジェネリック医薬品って知っているか? まず診察受けるじゃん? 処方箋もらうじゃん? それもって薬局いくじゃん? そしたらそこでナース服のおばちゃんにこういうんだ。「あ、『ジェネリック』の方をください」
ニヤリと笑うおばちゃん。ちょっと待ってな、と呟いて店の奥へと消えた。しばらくして帰ってきて、無造作にレジ台に放る。それは、いつものと同じ薬に見えた。だが、
――ほれ。XXX円だよ。
驚いた。それは従来の薬の1/3程度だったのだ。そうか、これがウワサに聞く、『ジェネリック医薬品』の力か。俺は密かに微笑んだ。
ところで興が乗ったので調べてみた。国民の三大義務のひとつ、勤労の義務、のはなし。いや初めて知ったんだけどこれが結構マヌケな話でさ、憲法 27条には、
27条
って書いてあんのに、99条に
99条
つまり、憲法は国家が守るべきルールであって、国民のルールじゃない。おいおい、それなら27条は何なんだ? お前は俺をバカにしてんのか、それともお前がバカなの? ってなるんだけど、どうも、専門家の間では「これは”プログラム規定”なのだ」って解釈が主流らしい。要はスローガンのようなものなんだって。この例では、”働ける人は働こうね”的な意味合いらしい。
…よくわかんないよね。最近9条に関する話がホットだけど、俺はそっちには、「ソースコードはいじれないので、代わりにコンパイラを変更してしのぎましょう」的なノリを感じるのだが、27条は明確にバグだね。
「技術的負債!」と声を荒らげる”意識の高い”ひとほど技術的負債を残してしまう、というジレンマがあるように思う。
Twitter でよく見る「クソコードのメンテつらい。技術的負債だ」という類の投稿。
本当にそのコードがよく書かれていなかったのかもしれない。
だけれども、その投稿をしたひとが「他人のソースコードを理解しようとすることに慣れていなかった」のだとしたら。
こんなに不幸なことはないと思う。
そのひとは自分に最適化されたコードを書き続け、そこから外れたコード、自分の理解の及ばないコードを「クソコード」と形容し、生きてゆくのだろう。
そのひとのコードは会社で「技術的負債」と呼ばれているかもしれない。
Twitter やはてブや Rebuild.fm から最先端の技術やコンセプトの知識を仕入れてきて、会社のプロジェクトで試すひと。
そういうひとには、次のような基本的な質問をするようにしている。
こういう質問に対して、ウェブ上で誰かの言っている一般的な利点をただ述べたり、うまく答えられずに不機嫌になったりするひとは危険だ。
自分の頭で考えることができていない。
「Twitter でみながその技術の話をしていて、ただ楽しそうに見えたから」、というところなのだと思う。
技術やコンセプトが生まれた背景には「必要性」みたいなものがあるはずで、それを理解し、説明できるようにした上で、自分の今いる状況に照らしあわせ、判断しなくちゃいけない。
もしもその技術やコンセプトとプロジェクトに齟齬があったのなら。近い未来に、それは「技術的負債」と呼ばれることになるだろう。
「技術的負債!」と声を荒らげる”意識の高い”ひと。若くて、ピュアなひと。
ソースコードの複雑さを表す指数で、これが高いソースコードはバグが多いって言われてるの。
サイクロマチックの発案者に直接、科学的根拠あるのかって聞いたら「実際に役にたってるから(根拠は)いいだろ」みたいな返事らしいのな。
たしかにソースが複雑だったらバグは増えるだろうけど、それならツールを使わないと算出できないような複雑な指数をつかわなくても「ネストは○段まで」「サブルーチンは短く」「サブルーチンのローカル変数は○個まで」みたいな単純なやり方でもいいよな。
サイクロマチックでなくても、見た目が複雑なソースなら大きくなる指数を適当にでっち上げても「この指数とバグの発生件数は相関関係がある」って言えそうだよな。
途中でこのことに気づいて秋からどんどん公開していった
クソだと思っていたが意外に評価されたりする
A社で内定出てから、ダメ元で受けてたB社のESが通ってて、B社から内定が出て、A社の人事を裏切ってしまった
狭い業界なので筋が通らないことはしないこと、将来干される気がしてて怖い
どうやらもうすぐ1年たつらしい。
が、宣伝活動が目に余るのでhttp://anond.hatelabo.jp/20141204085433に引き続き、こき下ろす。
「ブラウザ」を検索しただけで広告が出るありさまだが、何よりも問題なのは、広告が嘘を言っていることである。
まず、「軽い」とは言えない。他のブラウザと比べて特別軽くはない。Chromium派生ブラウザはメモリが十分にある環境においては速いが、メモリ消費量が非常に多いので軽いとは限らない。
「純国産」は間違いなく嘘。ソースコードの大半はChromium(by Google)だというのに、純国産だと名乗っているのはChromiumを冒涜する行為である。もしGoogle本社が日本なら間違っていないんだけど。国産と"純"国産では意味が全然違うので。
速いのも安全なのも大半はChromiumのおかげなことを忘れているのではないか。
というか、Chromiumを勝手に改変しているだけなのに、何を根拠に「安全」と言っているのだろうか。Chromeはセキュリティ修正を目的としたバージョンアップが何度かあるのだが、それについていくとは限らないというのに。
マルウェア広告ほどではないが、嘘広告でうざい。一応マルウェアじゃないのが不幸中の幸いみたいなものだ。
ソフトウェアを紹介しているとあるニュースサイトに何度か掲載してもらってるようだ。
多額な広告料を出しているせいかは知らないが、2014年のM大賞にて銅賞を受賞。(これなら、似たようなスタンス+αのVivaldiも銅賞以上はもらえそうだな)
ときおりMトークという記事を独占してもらったりするのだが、これも多額の広告料を出しているのだろうか。
とうとう、他のソフトと一緒にバンドルされるようになったみたい。
インストールは任意になっているようなので、別に問題ではない。これも宣伝活動の一環だろう。
以前、「Google Chrome と同等の機能を実現」とか謳ってることをこき下ろしたが、まだこの文言が修正されていない。
H.264、MP3、AACコーデックやDRM機能(Widevine)などが入って初めてGoogle Chrome と同等と言えるのに、できていない。嘘をずっとつき続けている。
以上を要約すると、「ただのChromium派生ブラウザのくせにでしゃばりやがって」かな。
一応名誉のために言っておくが、(ユーザーによる提案によって)他のChromium派生機能にはない独自の機能を標準搭載していることは評価する。
だが、その宣伝手法と自発的でない開発態度がまったく気に食わない。
ネタできたらまたこき下ろしてやる。
元増田の分野は、国内が強いとかメーカーとアカデミアの距離が遠いとかあるの? もしくは最終的にアカポスに就きたいとか。
単に今の環境に手応えを感じてないだけなら、国内でD進はリスク高すぎるんじゃないかなあ。分野にもよるだろうし、もう行きたい研究室決まってるなら別だろうけど。
ソースコードって言ってるからCS系だとすると、USの院に行くとか、国内国外に限らず小さくてもコード書きつつ論文も出してるような尖った企業を当たってみる、とかどうだろう。
仕事は楽しいし、給料もいいから辞めるのは勿体無いんだけど、どーしても博士課程への進学が諦めきれない。
Dr.取っても生涯年収上がるわけじゃないし、教授になれるわけでもないから、意味があまりない。
ただ、論文書く過程で、自分で新しい価値を考え出したり、それを自力で実現したりする過程を体験したい。
それで、結果としてちゃんとした論文誌にファーストで論文載せたい。
そうしたら今より数倍自分の能力上がる気がするし、人生楽しめそうな気がしてる。
設計の仕事は仕様決めて、工程引いて、下請け使って、金の管理するだけで、技術的に勉強にならない。
ソースコードも書かない。ただ給料は良いし、1年目で2ヶ月も海外出張行かせてもらったりで、ありがたい環境でもある。
どう生きるべきか…
僕は情報系の世界にいるのだけれども、女の子は女の子であるだけでちやほやされるし、ずるい
もちろん色んな苦労もあるんだろうけれども、ずるい
僕は競技プログラミングをやってるのだけど、僕も、ちょっと練習したり、成果を書くくらいでちやほやされたい
ってことで、女の子になってみた。女の子だと偽るのはずるいので、女の子として振る舞うことを表明しつつ、女の子でないのが解るようにしてみた
具体的には、Twitterで@meguru_compってアカウントを作った
女の子(エロゲーのキャラ)になりきって、ひたすら競技プログラミングの問題を解き、思ったことや解き方、ソースコードをひたすらに書いていくアカウントだ
これで僕もちやほやされるに違いない。ちやほやされたら僕もやる気が出て、最強になれるに違いない
なんでだろ。何が悪いんだろ。誰かおしえてください
この記事見て思ったんだけど、
はてなブックマーク - 週刊「しょうもないWebアプリをつくる」創刊号 – アクセスカウンター | CreativeStyle
http://b.hatena.ne.jp/entry/kadoppe.com/archives/2015/04/syomonai-1st-access-counter.html
タイトルがキャッチーだよね。ディアゴスティーニとかあの辺の雑誌を思い起こさせる。でも記事の中身はどうも全然違ってるみたいなんだ。
ディアゴスティーニは、毎週1つ部品が付録についてきて、それを全部組み合わせると一個の製品が出来上がるってものだけど、このブログはそんなのではなく、毎週1つアプリをリリースするんだって。
ここでちょっと話を置いといて、今プログラミング教育だなんだとネットでアピールされていて、無料で学べるサイトまとめや有料レクチャーの宣伝記事なんかが人気エントリになったりしてるよな。無料で学べるサイトなんかはいくつか覗いてみたりしたけど、ずぶの素人としては最初のページで挫折しちゃうわけだよ。「こうすれば"Hello World"と表示できます」ってその通りやってみても何の達成感も得られないんだよな。だから何なんだって。こういう基礎部分が重要だってことは分かるんだけど、意味が分からずこんなことやってもつまんないよな。結局Hello World表示させるだけでいつも飽きちゃうの。
で、最初の話に戻るんだけど、ディアゴスティーニみたいに「週刊 プログラミングでWebアプリを作る」なんてレクチャーサイトがあったらいいのになぁって思うんだよ。「週刊 スマホ用パズルゲームを作る」でも「週刊 ブラウザゲームを作る」でもいいけど。
毎週ソースコード?が数行アップされて、それを全部コピペしていくだけで、1つのアプリが完成するの。記事ではコードの他に、使われている構文の基礎的な解説や、何のためにその構文が書かれているのかとか解説されるの。
最終的にできるアプリは実用的に遊べたり使えたりするもの。そうでないと単にコピペ作業するだけだとしても、モチベーションが上がらないからね。
コピペしただけで何も身につかないとか言う人もいるだろうけど、「プログラミングでアプリを完成させた」という流れを全て体験することが重要だと思うんだ。最初にそういう流れを体験しとけば、その後のHello Worldみたいな基礎的な勉強への苦手意識がずいぶん減るのではないかと。少なくとも俺は減る。
そんなわけでプログラミング学習したいから本当に「週刊 スマホアプリを作る」みたいなの出ないかなぁ~。そういう無料サイトが出る前に、ディアゴスティーニが電子書籍で発売しそうだ。それでもいいけど。
anond:20150327184724のつづき。
JD(Job Description)に書いていない限りは、プリセールスエンジニアとして採用された人間は営業組織に属し、プリセールス活動を行う。通常小さな会社(グローバルで数百人、日本で10人等)であってもカスタマーサポートの組織と営業の組織はトップレベルから分かれており、プリセールスのエンジニアが購入後の顧客(やパートナー)の代わりになって自ら社内でトラブルのエスカレーションをすることは無いし、そのような権限も無い(日本の代理店ビジネスの場合は、解析や切り分けはたいていサポートを提供しているパートナーの仕事だ)。購入後の顧客で発生したトラブルに関してプリセールスエンジニアができることといえば、進捗が遅い時に催促したり、状況をかいつまんで顧客に知らせることくらいだと思うが、これとて営業でも実施可能なことである。
次項の内容とも関連するが、火事場に駆り出されて業務範囲外な支援やコミットをさせられるかどうかは営業の力量や考え方次第でもある。
営業によってスタイルは様々。御用聞きに徹して顧客の言うことはなんでも受け入れ、その結果社内の色々な組織に無理を通して煙たがらる人もいるし、できること・できないことの見極めと顧客に対するお断りの仕方等のバランス感覚が大変優れている人もいる。前者と組むことになったプリセールスエンジニアは、(会社ではなく)その営業個人の顧客からの評価を高めるために使われることを強いられるため要注意。
組む営業が変わった時には、まずその人がどんな考えを持っているのか、自分との間の力関係はどうなのか、組織の中でどういうポジションなのか等を見極めてどう振る舞うかを考えよう。
例えば上記の前者のような人であっても、社内での影響力が大きく売り上げへの寄与がそれなりにあればそれに従わざるを得ない。従わずにダメ出しされてしまった場合には自分の雇用が怪しくなる(”刺される”と言う)。逆に社内での影響力が小さければ自分が上司を使って刺してやればいい。
前述のとおり、「エンジニア」という名前がつきはするものの、結局のところ同じ組織の他人が作ったブラックボックスを販売するための技術サポートをする仕事にすぎないので、ガチエンジニアである設計・開発に比べると必要とされる技術レベルはそんなに高くない。強いて言えば、わからないことがあったときに調べて付け焼き刃の知識を得る力があれば良いと思う。また、簡単なツール等が作れると便利なこともあるので、言語は問わないもののプログラムの経験または知識はあったほうが良い。
日本で日本の顧客を相手にした販売のサポートを行う仕事なため、ネイティブ並のレベルは必須ではない。文書の読み書きと口頭でのコミュニケーションができ、自分の思っていることや疑問点が英語話者に伝えられればとりあえずはOKだと思うが、他の国の人(特にHQ)との個人的な繋がりがあった方が有利な場面もあるため、英語のコミュニケーションはできるに越したことはない。
英語と技術レベルについては、面接で30分程度も話せば把握可能なので、特に資格を持っている必要はない。
今まで見てきた中での最年長は40代前半なので、だいたい定年はそのくらいの年齢だと思う。一般的には大きな会社の方が「この人何の仕事だろう」というポジションが多い業務が細分化されているので、ジョブチェンジを考えている人は30台半ばくらいまでには大きな会社に入ったほうがいいと思う。社内の方がジョブチェンジはやりやすいからだ。
今まで見てきた中では、以下のような出口を見た。
1と2は、技術的な知識を活かして少し別の仕事をというケース。3は同じ組織での昇進なので、厳密に言えば出口ではないが、新しいキャリアなので挙げた。5はほとんどいないが、「メーカー=製造元=技術情報の海」みたいな幻想を抱いて入って来たものの、単なる海外営業所の一つという現実に失望してすぐに辞めてしまうパターン。英語がネイティブ並みだとHQへの転勤や、日本でビジネスを開始したばかりのスタートアップ(従業員1-2名)の同じようなポジション(+α)への転職も可能になり「スタートアップ渡り歩き人材」への道も開け、その場合50歳くらいまでは粘れるが、スタートアップは長期雇用になりづらく、ジョブホッパーになってスタートアップ以外からは歓迎されない立場になってしまうリスクもある。
「外資のメーカーで働く」と言うと聞こえが良いが、社内では単に極東の一拠点の売り子である。どの職種、どのような会社からの転職を考えているかにもよるが、万人に勧められる仕事ではないのは間違いない。また、会社によって待遇やワーク・ライフバランスは異なるため、人材紹介会社や面接の担当者の言うことを鵜呑みにせず、前回のエントリーにも書いた通り本音の情報を得ることをお勧めする。
1KB=8192ビットぐらい意識しなくても読み換えできるだろう。
そんなとこに難癖つけるってことはビットもバイトもイメージできてないのはお前じゃないか。
オウム返しするtwitter botのソースコードのサイズなんて1KBぐらいだろ。
せいぜい数十行のプログラムってことだ。
わかったか?
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系の端末で修正リリースが去年の秋とか、これからの近未来とかのが多い、という状況からするとね…。