「コミッタ」を含む日記 RSS

はてなキーワード: コミッタとは

2018-12-06

NTT新卒で落ちました

NTT退職エントリ流行っているようなのでそもそも入れなかった人の話でも書きます

といっても1X年前の話です。

増田はどんなひとか

1980年台前半生まれ

リーマンショック直前の超売り手市場新卒4月初頭というゴールデンタイムNTT系列何社も受けて全滅したアホ。

趣味プログラミング。ICPFCとか参加したり小さいツールを書いたりしてた。

大学の専攻は数学日本ではやたら偏差値の高いらしいT大学に現役で入ってそのまま修士卒。

どこを受けたのか

NTT株、NTTD、NTTS、NTTH、NTTCなど。略称がどこを指すかは適当に考えてね。

部落ちてます4月はこのせいでお祈りされまくり、結局決まったのはNTT以外で夏ごろで。

なぜNTTに応募したのか

電話がとても好きだった。高校ぐらいのときモデムから高速リダイヤルをかけるアプリとか、

公衆電話の番号を探すツールとかを書いていた。PHS携帯が普及しだしたこから

そもそも仕様があまり手に入らなかったので興味を持てなくなった。113はよくお世話になった。

就活ときそのへんのことを思い出したのと、プログラミングが好きだったのでNTTなら

なにかできるんじゃないだろうかと思いたくさん受けた。

なぜNTTをそんなに落ちたのか

当時はプログラマというもの地位ものすごく低い時代だったと思う。

そんな時代に「プログラミングやりたいです。ICPFCとかめっちゃ楽しいです。」という割に

基本情報すらとっておらず、コミュ力も非常に低い上に専攻が純粋数学とか落ちて然るべき。

更にNTTがどういう人材を欲しているのかという企業研究もろくにしていなかったため、

自分御社にどういう貢献ができるのかを説明できず、ただやりたいことだけを喋っていたた。

また純粋数学研究内容の説明がしにくいというのはわかりきった話だったので、それは対策するべきだった。

面接でどんなこと聞かれたのか

NTT

3分研究内容を話すというプレゼンSPIがよかったらしく1次面接免除という連絡をいただき

喜んで2次面接に望んだところ純粋数学研究発表で、「この研究社会的意義はなにか?」という質問をされ無事死亡。

NTTD

書類審査で通過できず。

NTTS

社名にソフトウェアなんてついてるぐらいだからプログラミングガッツリできるんだろうと思い、

CPU命令セットの素晴らしさとその効率的エミュレータ実装について熱く話す。

面接官の「そんなことにしか興味ないんですか?」という返事は今でも覚えている。

NTTH

グループディスカッションで落ちる。コミュ力とか見られてたきがするが審査員は見てただけなので詳細は不明

NTTC

面接前に社員雑談する謎の時間があり、「T大の人、ぜひ来てほしいんですけどNTTDとかNTT株に

取られちゃって蹴られてしまうんですよね…」という話を聞く。その時点でDには落ちていたので苦笑いして面接へ。

当時盛り上がっていたNGN関係の話で面接官と盛り上がるも俺が考える最強の通信スタック実装法を

熱く語ってしまドン引きされる。

結局どこにいったのか

NTT系列はだめだったので結局某SIer就職年収は300万弱から5年ぐらい在籍しても500万弱ぐらいだった。

最初は流石に年収低すぎということで某Rエージェント転職活動をするもリーマンショック真っ最中

在籍も1年とかだったため「君なにしにきたの?」オーラがすごかった。その時点での転職は失敗。

SIerによくある通り仕事コードというものほとんど書かず、ExcelWordがメインであった。

ただ仕事自体は暇だったので、合間にひたすらProject Eulerをやっていた。

今は何してるのか

今はお仕事が変わり、AI関係ソフトウェアエンジニアみたいなお仕事をしている。

相変わらず面接ではコード書きたいですとかAtCoderとかの競技プログラミングの話しかしていないのだけど、

10年前に比べると反応がとてもよくなったと感じる。年収都内に何の不自由もなく暮らせるぐらいまでは

もらえるようになった。プログラマ地位は相当向上しているのではないだろうか。

個人的にはAtCoderTopCoderで黄~青ぐらいのプログラマ社会的地位10年で年収400万から1000万ぐらいまで上がった感じがある。

結局NTTにいったほうがよかったのか

退職エントリ読んでみると、NTT株は行ってみたかたかも。

ブコメへの回答

anond:20181206084718

今は1000万!と言いたいところですが、うまい棒5万本分ほど足りません。一本行けるように今後も精進します。

ただ今都内ソフトウェアエンジニアバブルといってもよく、かなり年収水準が上がっている気がします。

ですので多少は夢を持ってもよいのかなと。

回答追記

anond:20181206104025

キリの人も入社時は優秀だったんだと思います。あともし採用されるポテンシャルがあったとしても

ちゃん業界研究しないのはだめかと。いろいろな意味で私はだめでしたね。

id:ueno_neco

1990年代はまだ固定電話の古い交換器や緑・ピンク電話などが残ってた時代で、電話面白い挙動

NIFTY-SERVEフォーラム等で盛り上がっていた時代でした。そのため当時は同じような人が結構いました。

id:sny22015

うけてません。NTTの社風に合わないと全滅する可能性もあった(そして実際そうなった)ということで、

ある意味リスク管理ができていなかったとも言えます

id:shinobue679fbea

最近NTTDのOSS関係へのコミットは凄まじいですね。あの部隊尊敬しています

あのへんのコミッタ方たちはどういうルート採用されたんでしょうね?

id:ockeghem

大学時代XSSバイナリ解析に興味があったはずなのですが、就活ではその道は選びませんでした。

忘れていたというのもあるのですが、その数年前に日本セキュリティ系の団体ちょっともめてしまった

というのがあるのかもしれません。日本セキュリティ業界ちょっと前までアングラっぽい雰囲気

漂っていました(世界的にそうだっただけな感じもします)が、そんな方たちも某FF○Iとか某NAとか

ホワイトハッカー側で大きく活躍されてるようで、もしセキュリティ業界に身をおいていたら

そういう変化も楽しめたのかなぁとは思います

あ、徳丸さんのブログはいつも楽しく拝見させていただいています

id:Lumin

あの某NAのLuminさんでしょうか。当時はとても落ち込みましたが、今では楽しくやれているので

人間万事塞翁が馬というところかなと思います

2018-11-28

7年勤めたNTT系列退職して2年半が経過しました(ノンキャリア編)

2年半ほど経ちますが、空前のNTT退職ブームなので便乗しちゃいます

はじめに

まず既知の通りNTTグループ社員数約28万人と非常に大きな組織であり、その中で研究所エリート中のエリートが就く位置にある。つまり上記の方達は警察でいえばキャリア組にあたる方達にあたる。以降キャリア組と呼ばせていただく。

一方で、私は地方ノンキャリア警察官のようなポジションにある子会社大株主研究所出身なので、その分際でこのようなエントリーを書くのはおこがましいかもしれないが、

キャリア組層のエントリーなのに共感できる部分がとても多い上に、すでに [ 10年勤めたNTT退職しました(無能編) https://anond.hatelabo.jp/20181126192228 ]のようなノンキャリアそうな人(←失礼はご愛嬌)のエントリーもあったりしたのでちゃっかり便乗させてもらう。

蛇足


自己紹介

自分について


会社について

データとデー子もこんな感じなのだろうか。ぜひ知りたいものだ。

よかったところ

各種エントリーと重複するところもあるがご愛嬌

いい人が多い
  • いい人の定義が難しいが、穏やかで真面目な人が多い。飲食店バイト時代のように「ボケコラ○すぞ」なんていう上司はまずいない。
  • たまにチート級の有能な人がいる。知っている人では今でも有名OSSプロジェクトコミッターやってたりとか。
  • たまにチート級の無能な人がいる。知っている人では開いてはいけないメールを毎回開く人とか。でもクビにも降格にも絶対にならないいいところ。
  • それ以外は可もなく不可もなく凡人。僕もその一人。思えば2-6-2の法則はよく出来ている。

法令遵守

金が腐るほどある



悪いところ≒退職理由

給料が安い

できる人もできない人もすべて同じ待遇

独自プロトコルが大好き

技術に興味がない人が多い

社内システムう○こ

その他

総評

2018-10-23

IT人材の難しさに関して

最近思うことがある。

日本人IT業界世界追従していくのは不可能ではないか、と。

エンジニアやってます。」

は確かに沢山存在する。

「有名OSSのコアコミッターです。」

エンジニアである

PC発注セットアップをしてます。」

これもまたエンジニアである

IT業界はとにかくスピードが早い。キャッチアップが常にできていなければ、すぐに取り残される。キャッチアップができない人材の元で育つ新人は間違いなく屍として死にゆくであろう。

しかし、IT業界に初めて触れる人間は、情報工学出身高等専門学校出身の方々とは違い、レガシーな先輩の元に行くのが大半なので、これまた人が育たない。

そして優秀な人材は優秀な人材だけのコミュニティの内でより内を強固にしていく。

外にいる屍を救う人間は誰もいない。

Githubawesomeの量を見るとわかるように、いくら技術的に抽象化されようともその量は無尽蔵、日々アップデート業界なので、いたしかたない部分もある。

逆に誰でも出来る分野は、すぐに舞い上がって「俺スゲー」となる人間が湧きやすいのでそれもそれである

人間は愚かな生き物である

海外事情は知らないが、少なくとも日本IT永久に閉ざされているであろう。

2018-10-21

普通プログラマ関数型プログラミング絶対理解できない

実を言うと、普通プログラマオブジェクト指向以前のプログラミング理解できないんだけど、あれらはまだ手続き的な要素を内在してるから、そっちだけを受け取ることはできる。

それまで手続き的な要素+宣言的な要素だったプログラミングが、関数型プログラミングへと移行する時に手続き的な要素を切り捨てたのね。より純粋手法進化するために。

から、それまで手続き部分だけを受け取って喜んでた普通プログラマは急にわからなくなりヒステリーを起こした。

だけど、プログラミング上級者はオブジェクト指向以前にも宣言的な部分しか見てないか普通プログラマが何を騒いでるのかわからない。

普通プログラマって、部品化の凄いやつが関数型プログラミングになるとか勘違いしがちだけど(staticおじさんもその変奏)、全く質の違うもの

部品化って、重複コードをひすたらサブルーチンに括り出すようなもの副作用がある。

日本SIer(日立NEC富士通とか)って教養がない極東田舎者から副作用理解できない。すぐに「部品化」を持ち上げる。怖いんだろう。自分理解できないプログラミングが。モナドですら大多数は理解できないんだものあん教科書的なものですら。

とにかくアジアってIT後進国なのね。トップ日本ですらこうなのだから。"NTT"データHaskellレガシーシステム脈絡なく解析してホルホルしてるレベルもの

まず日本に生まれた時点で、関数型プログラミング理解するには圧倒的に不利。こんなこと言うと、「普通プログラマにもわかやす説明できるのが一流ダー」みたいな恥ずかしい駄々っ子が沸いてくるけど、プログラミングって歴史上一度も大衆相手にしてないので。

昔は研究機関IBMで、今はMSGAFA

OSS恩恵で、普通プログラマコンパイラ無料で使えるようにになっただけで泣いて喜ぶべき。

そしてあれは、将来のスポンサーコミッタ入り口としてやってるの。1000人に1人、将来コミュニティに貢献する人材いるかもしれないと信じて。

シリコンバレー住人にもOSSコミッタにもなれない普通プログラマはまあ、おこぼれで"文化的"コスプレしてQiitaでもやればいいんだと思うよ。

anond:20181021093430

2018-10-16

anond:20181015215004

外資系にいたとき研修が充実してた。(会社の金で勉強

社内にはOSSコミッターがごろごろいた。(分からないことは開発者に聞くのが一番早いw)

日本IT企業アメリカに完全敗北してる理由自明ですね?

2018-10-05

転職について(採用側編)

前置き

いろいろ有って2年ほど努めた会社を離れることになった。職種WEBエンジニア。主にフロントエンド担当ポジションとしてはリーダー格。所属会社はいわゆるWEBベンチャー

何社も経験しているジョブホッパーだが、スキル経験はこの会社で一番貯めることが出来たし、一緒に働いてきた仲間はいい人たちだったので感謝している。しか事業方向性自分方向性がずれ始めたので会社を離れることになった。

この会社では採用担当することが出来、そのおかげか今回の転職活動人生で最もスムーズで、かなり質の高いオファー複数もらうことが出来た。どこも魅力的な会社で高い評価を頂いているので、辞退する会社には正直申し訳なく思う。もちろん超売り手市場の超売り手職種ということもあり、自分の実力以外の側面も強いのだが。

そこで2回に渡ってありきたりだけど、転職について書きたいと思う。今回は採用側としての視点で書く。

自分身バレ以上に応募者のプライバシーのほうが問題なので、ある程度ぼかして書いてます

採用側としての立ち位置

自分採用側としての立ち位置は以下の通りである

実際に通した人・通さなかった人

100名近く会って実際に通したのは5〜10程度。一次通過率厳しすぎじゃね?って思われるかもしれないが、自分としてはできる限り通すつもりでやった。それでもこの結果だった。

さなかった人

9割以上で通さなかったのはこういった人たちである

スキルがあまりにも低すぎる・ミスマッチな人

フロントエンドエンジニアということなので、最低限「HTML/CSS/JavaScriptコーディングできる人」「Gitを使った開発ができる人」という観点でだけしか見ていないのだが、それすら至っていない人が多かった。

職業訓練校で習ったので、AdobeHTMLCSSは出来ますjQueryプラグインは設置できますGitってなんですか?」とか「制作会社LPを量産してきました。Reactってなんですか?」とかそういう人である

いくら売り手市場とはいえWebアプリ開発者を求めているので、このレベルの人を採用して教育するほどの余裕はない。最低限学習意欲や、キャッチアップする能力があればいいのだが、こういう人に限って「これから頑張ります」という感じなので、正直お断りしていた。

こういう人は本来であれば書類スクリーニングすべきなのだが、会社自体が有名ではないせいか応募母数が多くないので、こういう人も書類は通していた。

逆にSIer社内SEから転向組の方も多かったが、「JAVAで基幹システム作っていますバージョン管理SVNです。Angularってなんですか?」とか「社内システム開発でベンダーコントロールしてました。希望年収は現職と同じく700万です」とか。もちろんGitHubアカウントなど持っていない。なぜ弊社に応募してこようと思ったのか謎である

恐らく流行モダンフロントエンドRailsGitHubでPR開発という、ベンチャーによくあるキラキラした部分に惹かれてきたんだろうけど、それにしても準備しなさすぎじゃないですか?この手の人に少し技術的に突っ込んだ質問をすると、大体とんちんかんな回答が返ってくる。

そもそもいくら応募母数が少ないとはいえこういう人を書類通過させるのもどうかと思う。もうちょっと書類スクリーニングしてくれと言ったが、自分意見は通らなかった。ちなみにその上司もも会社にいない。

職歴・経歴・スキル募集ポジションに大きな乖離がある人

上記に書いた社内SE氏もここに含まれるだろうが、それ以外にもこういう人がいた。

「43歳で現在雑用アルバイト会社ホームページ担当を片手間でやってます(一応paizaではS判定)。ところどころ空白期間あり(聞いたらガチニートだった)。Gitってなんですか?」とか「38歳でコンサル会社マーケティング担当ですが、技術スキル手に入れたいのでキャリアチェンジしたいです。スクールWEBコース勉強してますVue.jsってなんですか?」とか。

どちらも普通な書類落ちレベルだが、前者の方はpaiza経由なので面談確約だし(paiza経由でGit知らないとかギャグかと思った)、後者の方もポテンシャルによっては通してもいいのだが、年齢の割にちょっとキャリアに考えが甘すぎると思ったのでお断りした。

人柄に問題ありすぎな人

正直なところ、自分ジョブホッパーだしあまり性格がいいとは言い難いし、実はそこまで人柄は見ていないのだが(どんな人にも長所短所はあると思うので)、それにしてもちょっとこの人とは働きたくないなと言う人はお断りした。

具体的には「前回面談で日程勘違いですっぽかしたにもかかわらず、再設定された面談で一切謝罪もなかった」とか、退職理由を聞いたら「上司や同僚とうまくいっていない、自分にはもっとふさわしい職場がある」とか、技術的に少し乖離があります大丈夫ですか?と聞いたら「そんなの調べれば出来るし、大した問題ではない」と逆ギレ的に回答してくるなど。

ちなみにこれは全部同じ人。あまりにもひどいので速攻でお帰りいただいた。エージェント経由だったので、一応人柄でこれは駄目でしょ的なフィードバックを返したけど、多分こういう人は改まらないだろう。そもそもすっぽかした人を再面談なんてありえないと思うんだけどね(これは会社批判)。

ジョブホッパー自分が言うのもアレだが、こういう人は次の職場でも同じ問題で離職することになるだろう。まずは自分客観視することからおすすめしたい。

あと、印象に残っているのがいわゆる「意識高い系である

その人はもともと難関大学と出て難関資格を持っていて、それなりに高い給与をもらっているハイスペックな人だったが、WEBエンジニアになりたいということで海外エンジニア留学したといいう人である

と、ここまで聞けばポテンシャルだけでも一次通過でいいような気もするが、肝心のGitHubの成果物がいわゆるスクール勉強したものそのままという感じで、あまりクオリティが良いものではなかった。

聞いてみると、その成果物スクールの仲間で作ったもので、実装は他の人がやっていて、自分プロマネポジションをやっていたということである

年齢も若い人だったので「弊社みたいな有名ではないベンチャーではなく、いわゆるメガベンチャー的なところとか受けなかったのですか?あなたならそこでも活躍できそうですよ?」と聞いてみたところ「そういう大きなところでは、自分で手を動かすことが出来なさそうだから考えてないです」とのことである。言ってることとやってることがちぐはぐである

こういう人に必要なのはスクールに行くことではなく、まず自分がやりたいことを明確化して、実際にそれを実現するには何が必要かを考えることではないだろうか。

正直なところ、無理にエンジニアになるよりも大きな会社で、プロデューサーポジションかに行ったほうが幸せな気がする。ただそういうところも「意識高い系はいらんだろうけど。

通した人

通した人は母数があまりに少ないのだが、だいたい同じような傾向である

年齢や経歴はバラバラだけど、方向性はだいたい一緒である。正直なところ、実はそこまでハイスペックな人を求めているわけではないし、有名ベンチャーみたいにアウトプット原理主義というわけでもないのだが、ハイスペックな人はだいたい上記が当てはまる。

さてこれだけ頑張って一次面接通しても、最終的に採用に至ったのは2名である経営者現場判断はまた別なんだろうし、うちで欲しい人はよそでも欲しいので辞退もそれなりにあった。

採用に参加するのはおすすめ

エンジニアエンジニアリング以外したくない、自分業務以外はしたくない、という人も多いだろうが、採用に参加するのは自分にもメリットがあるのでおすすめである

チーム作りとかそういう意識高い的なことでもなく、ひたすら自分の他メリットとして考えても十分有用である。実際に自分面接官として苦労した話をすると共感を得ることが出来て、非常に有効だった。

次は求職者側の視点で書く。

追記

id:xlc 人が集まらないのはあなた会社に魅力がないから、という前提を忘れているんでないかい?

まさにそのとおりで、だからこそ採用に苦労するし、それどころか自分を含めて次々と離職している。ただ今回は自分採用視点でのナレッジを活かしたいからこういうのを書いた。

リファラルがどうのとマネージャーが言ってきたときは「うちの会社リファラルで人を採用できるような魅力あると思う?」と言ったらぐぬぬとなっていたw。

採用手当以前に、まずは作っているプロダクトと労働環境を魅力的にしろと。

M社の例の怪文書採用強者側の視点で、自分が書いたのは採用弱者側の視点。強弱にかかわらず最終通過率が殆ど変わらないのが興味深いと思う。

id:thesecret3 100名も会って採用1~2名なら人材紹介か社長一本釣りのほうがよくないか

社長エンジニアの実務層への伝手はほぼ皆無だし(ビジネス出身だし)、人材会社エージェントを使ってたけどほとんど効果なかった(M社と同じ感想)。いわゆるヘッドハンターを使うほどの金はないし。エグゼクティブではない実務レベルの人をヘッドハンティングするのは。。。これに関しては求職側編で書く。

2018-07-16

anond:20180716223023

いやあの、あなたがもし採用側だったら

コミッターでもない40代ITおじさん採用したいと思います

同程度仕事のできる30代おじさん採用したくなりませんか。

2018-01-14

IT業界某国スパイ巣窟

IT業界日本社会の縮図となっているんだよ - こうして僕らは腐る

http://www.byosoku100.com/entry/2018/01/13/212749

ITを学んでIT企業就職して、この国のIT企業はきっとCIAか何かによって弱体化を図られたとしか考えられないと思いました。

自分ロジック組んだり、アルゴリズムを考えたりする仕事をさせてくれている会社もありますが、会社の規模がでかくなればなるほどそういう仕事下流に任せる感が強い。まずこの構造が弱体化の出発点。

多重下請構造は、製造業日本ならではの伝統下流低賃金が根強い。背広を着た人がその伝統文化を売り捌く。文化が短納期、安請け合いを生み、短納期、安請け合いにより、品質が下がり、雇用も安く済まされ、弱いSEしかまらず、国際競争力はなくなる。この下請け構造文化を持ち込んだのは、他ならぬ製造業文化を固持してきたメーカーベンダーのように思えますメーカーベンダーCIAからなんだかのスパイ行為に加担したのでしょうか?

実はそんなメーカーベンダーにもいたのですが、ぽっと出の強いSEもいます。ところが強さが仇となり、全容を把握している神扱いで一段上に据えられます。そして多忙を極め、ロジックアルゴリズムをひねり出す知的生産力は、仕様書指示書と呼ばれるエクセル方眼紙に図形や文書を書き殴る作業力へと変貌します。

指示は全て自社フォーマット図面に書け!その図面審査承認課長に貰え!え?予算の都合、本部承認必要本部長いつ来るの?1週間後だって!?リスケだ!工数再見積もりだー…これは仕事ですか?それとも茶番ですか?こうして強いSEは弱体化します。強いSEほど自分の置かれた立場環境に順応しようとする意識が強く、仕事ができる人間になるためにはお上に楯突かず、弱体化を受け入れようと考えます

エクセルのvlookupを使うために、学生時代関数型言語を学んだわけじゃないのに…と就職して思うようになったunix文化を学んだ強いSEが、思考停止している情シスによって管理しきれないものは全てセキュリティホールみたいな会社にいたら、「あいつはセキュリティを脅かす不良社員」のレッテルを貼られ、朝から晩までvlookup,vlookup...(いやそのエクセル脆弱性情報パッチ出ているけど、いやお上のお達しを待て!的な茶番劇)せめてgrep,awk,sedくらい使わせてやれって、残業がなくなってボス最近社長の思いつきで始めた健康経営者として表彰されるかもしれんよ?思いつきだから明日あるか分からんけど…。いつまでこんな寸劇をやればいいのやら。学んだことは活かせません。茶番寸劇の中心にはやはりこの国のIT業界を弱体化させ国際競争力を低下させるスパイが潜んでいるとしかおもえません。

ここで、IT業界蔓延日本国際競争力をいちぢるしく低下させているスパイの特徴を述べておきます

・安請け合いをする無能な人

スパイ目的である国際競争力の低下にダイレクトアプローチするスパイ中のスパイです。こいつがいたら即辞めないと国や社会のためにも良くないです。

・「よく分からないものセキュリティの都合使えません」と思考停止している人

お前はそのツールコミッターでそのツール脆弱性を分かってそんな事を言っているのか?と、せめて同僚がツール有用性を知りつつ使いたいっていうならそれなりのセキュリティ的可用性を示すのが情シス仕事じゃねーのかと?まぁこ場合スパイなのでそんな調査は死んでもやりませんが…

・「ツール使用効率化ではなくズルだ!」と言い続ける人。

スパイの常套プロパガンダです。明らかにおかし言動なのでスパイの中では未熟者なのかもしれません。

・「大学で学んだことが社会では通用しない」と偉ぶる人

そのままで通用しないけど、出発点であるべき。でなければその空白を埋めるコストをどうしろと?そんな言葉マジで吐く人間は出発点にすら立たせて貰えていない場合が多い。ただ言葉を吐くスパイは、スパイが故に企業内の立場は上のほうにいるかもしれません。出発点に立っていなかろうが

法律無視する人

よく考えてみてください。遵法精神のあるスパイがいると思いますか?そもそもこのスパイ蔓延構造日本社会根深く浸透しているので、法律を取り締まる側もうまく騙されていると考える方が自然です。労基法下請法派遣法…機能しないのも当然です。

2017-12-16

オライリーで本書いたっていう印籠

ところてんさんがこの前書いてた話思い出したけど、たしかにちびると思うわ

 

Google社員の〜

・有名OSSコミッターの〜

オライリーで本出した〜

大学教授の〜

社長の〜

 

オライリー最強すぎる

平伏する

 

こういうのいろんな業界にありそうだな

それは平伏するしか無いみたいなやつ

武道館単独ライブした〜みたいな

M1で優勝した〜みたいな

2017-08-29

NDAに縛られるフリーランスとは将来を今の金銭に換えることだ

「**社で**の仕事をしています

フリーランスで**の仕事をしています

「**の会社をやってます

勉強会飲み会合コン。あらゆる所で繰り広げられる会話。

あなたはこれを言えるだろうか。

私は言えなかった。厳しいNDA、社名の無い名刺職種くらいしか伝えられない人に相手は興味を持たない。自分だってそうだ。

仕事は人脈か自己PRからしかまれない。自己PRという言い方がfitしなければ広告と言っても構わない。

OSSコミッターや技術blog,書籍を書くようなエンジニアならいいだろう。

だが、業務ビジネスコミットして仕事をするフリーランスNDAに縛られてしまえば、時間とそれまでの経験金銭に換える事にしかならない。

「今何をやってるんですか?」という質問に答えられない仕事をするべきではなかったのだ。

2017-07-14

一人では何ひとつできないエンジニア

私の仕事

 

StackOverflowの諸先輩方や

Qiitaの分かりやすいまとめや

技術者ニッチブログ

素晴らしいライブラリ、そのコミッタ

言語を生み出した天才たち

IDE開発者

PC製造者

その他ASPインフラなど、多くの方が居て奇跡的に成り立っています

一人では何もできません

99%は他の方に頼っています

ありがとう

ありがとう

2017-05-05

http://anond.hatelabo.jp/20170504083902

エンジニアリング勘違いしてる人がときどきいるけど、エンジニアリングってのは工場を作ることであって、ライン工になることではない。

ソフトウェアエンジニアリングにおいてファクトリーはフレームワーク(あるいはミドルウェア)である

大企業においてフレームワーク(ミドルウェア)を作る仕事は専用の部署があり、名だたるOSSコミッタなど一流のプログラマーが在籍している。

2017-02-03

http://b.hatena.ne.jp/entry.touch/tech.speee.jp/entry/2017/02/02/170401

個人を責めるつもりはない。

ただ、モラルのないサービスで得た金銭Rubyが発展していくならこれほど嫌なことはない。それをRubyistsがなんとも思わないならRubyにも未来はない。

Rubyコミッターを雇った以上、Speeeは二度とユーザーインターネット馬鹿にしたクソみたいなサービス作るなよ。laughy.jpのような。

Rubyを使う者のひとりとして言わずはいられない。

2017-01-24

OSSコミュニティについて思ったこと

この間、某有名なリポジトリメンテナンスモード(新機能追加よりもバグ等の修正を優先にする)に入っていることを知って独り言を書こうと思った。

また、この間メンテナや開発仲間でいろんなリポジトリの現状共有の話があった。

最近、様々なOSSコミュニティ記事を見るようになったのも理由の1つかもしれない。

はじめに私は複数リポジトリメンテナをしており、その目線で書けたらと思う。

私が最初に思ったのは結局、OSSコミュニティというのは社会構成は変わらないなぁと思った。

大きな違う点として、

だと思う。

私がOSS活動するのは、志が他の開発者と同じであり楽しいと思えるから

仕事だとお金を稼ぐためというのは当たり前だし、そのために働いている。

なのでお金を稼ぐためという人もいれば、サービスを使われたいとか、もっと拡大させたいとか様々な意識があると思う。

しかし、OSSコミュニティ活動するのは物を良くしたいという部分が大きくコントリビューターやコミッターがそういう意識活動していると思う。

メンテナが減るのは当たり前で、飽きもあるだろうし家庭の事情とかもあるだろう。

また、別の興味あるプロジェクトコントビュートしたり、自分の開発に専念するといったこともあるだろう。

これは私の中で転職に似ているなって思った。

自分のペースで活動できるのでブラックではない。

OSSコミュニティというのは今の時代、多くの会社普通に使っており、市場の規模は大きいと思う。

しかメンテナの数というのはとても少なく、著名なリポジトリでも2, 3人しかいないというところもある。

みんなが知っている有名なフレームワークツールも内部を見ると、少人数で回しているのが現状である

本当にPull Requestを出してくれる方や、バグRFC等のフィードバックをしてくれる方には感謝している。

そういう方が居てこそ成り立っており、このような体験仕事では得られないと思うので大切にしていきたい。

日本人の方の参入率は自分観測範囲では結構低く、やはり敷居が高いのかなって思った。

一番最初に壁になるのが英語だと私は思う。 実際、私はそうだった。

日本だと、どうしても日本語ドキュメント情報が充実していないと流行らないというのも実際そうだ。

新規の方が参入しやすいように考え直す時期なのかもしれない。

いかコミュニティを拡大させつつ維持していくのかが難しいかというのがメンバと話していて自分の中でわかった気がする。

2016-07-08

Rubyの開発をSVNでやってることについて改善のつもりがないと断言するのまじプゲラなんだけど

https://moneyforward.com/engineers_blog/2016/07/07/ruby-core-201606/

[#11741] Migrate Ruby to Git from Subversion

またこれか。

いつも「なぜRubyGitに移行しないんですか」とかいスレッドが立つんですけど、結論としては簡単で、移行するモチベーションがある人がいない。外野でガヤガヤ言うだけの人がどんなにたくさんいても無意味で、きちんと結果にコミットしていく係になるだけの気概のある人が必要で、そういう人が出てこない限りは何も変わらないと思います

ひとしきりゲラゲラ笑ったあとゾッとするよね。生産性の低い方法をとりつづけることを変えようとしない、コミッタ陣のその老害っぷりに。

SVNからGitに移行する」というのはそれ自体は開発手法の変化において本質的とは思わない。重要なのはパッチGitHubのpull-requestやGitLabのmerge-requestのような、差分を見ながら細かく議論できるウェブインターフェイスを使って適用していくことだと思ってる。だからGitに移行したいというリクエストを「またこれか」「移行するモチベーションがある人がいない」で済ませるのは、そういうpull-requestベースの開発手法をよしととしていないってことでしょ。それでいいの?

別におれはRubyコミッタじゃないしパッチ送ったこともないし、Git移行の作業を手伝うつもりもないよ。だって関係ないもん。ただ、いちRailsユーザとしてこのRuby開発陣の老害化にはちょっと背筋が寒くなる。自分たち老害化していることについて、もっと危機感をおぼえたほうがいいんじゃないのかな。

2016-06-29

ソフトウェアエンジニア転職するときに気をつけること

いままで3回転職したけど、うまく行ったこともあるし行かなかったこともある。いままではわりと気軽に転職先を決めてしまっていたのだけど、そろそろ慎重に行かないと後がないなという危機感を覚えたので、とりあえず今までのことを振り返って気をつけるポイントを書いてみようと思う。

自分はこんな感じのエンジニアです。

  1. 技術的には広く浅くタイプ
  2. デザインインフラは不得意
  3. マネージメントは不得意
  4. いままで所属していたのは上場企業が多かったが、スタートアップ経験済み
情報収集
IRを読め、短信だけでいいか

これまで何をしてきたか、これから何をするつもりなのか、会社の強みは何なのか、今後考えられるリスクをどう捉えているのか。上場企業ならばIRという形で外向けに情報を発信しているので、それを読むのはかなり大事

で、具体的に書いてなくてよくわからないところが絶対あるはずなので、それを面談で聞く。ピンと来なかったらその会社は駄目だ。

公開されているコードを読め

公開されているコードがなければリスクは跳ね上がる。もちろん公開していないすばらしい技術というのはあるのだけど、会社評価という点では使えない。

GitHub会社アカウントがあれば分かりやすいが、それ以外でもがんばって探そう。OpenJDK, Ruby, LLVMなど大きなOSSプロジェクトコミッタがいればちゃんとコミットをいくつか読もう。GitHubも個人リポジトリはなくても別のリポジトリコミットしているかもしれない。

面談
経営陣や部長クラス技術に対する考えを聞け

社長エンジニアを信頼しているかCTOがいる場合は、CTO社長信頼関係があるか。

技術手段に過ぎない、ビジネスへのビジョン大事。確かにその通り。ただしそれは、経営陣の技術者に対する信頼があればの話。

これはできれば上層部と平社員両方の考えを聞こう。

使っている技術スタックや将来への展望を聞け

技術目的にするな。確かにその通り。しかしいまどきSVNを使い続けていたりデプロイを手動でやっているのはさすがにヤバイ。ついでにOSSを利用することへの意見も聞いとけ。

もしそういうダメな状況を変えるために自分を雇うのだということであれば、上層部がそういう技術的なアップデートをどのくらい必要だと考えているかを聞くこと。社長が「エンジニアを君とあと何人か雇って、一年それに全力を注いでいいかバージョン管理インフラなどの下回りを一新したい、既存社員にも納得してもらう」というのであればいいかもしれない。権力のある人がそういう強い決意をもってないと改革は難しい。

この話は技術者ならば誰から聞いてもいい。もし面談過程技術者がでてこなければ、その会社は諦めよう。

デザインについてのどう考えているかを聞け

ここでいうデザインは「サービス設計」のことね。デザイナー出身マネージャーがいれば、その人と面談してデザインをどうやってしているかの具体的な流れを聞けると最高。あるいは、エンジニア・デザイナ・企画の三者がどうデザインに関わるかを聞くのでもいいかもしれない。

サービス開発手法については納得するまで聞け

企画デザインプロトタイピング、開発、リリース改善、このサイクルを具体的に聞こう。直近の成功例と失敗例を聞けると最高にいい。

これは現役の技術者から聞こう。実際に自分体験することになる日常になるのだから

外注と内製の比率とどういうとき外注するのかを聞け

外注管理することになったらとにかく最悪だ。そうでなくても、君がもし生粋エンジニアなら、外注にはなるべく関わらないほうが幸せだろうと思う。

以上。

願わくば、次の転職がうまくいかんことを。

追記

"見出しエンジニアと書いているのにプログラマの事しか書かれていない。それもソフトハウスへの転職。" という指摘をうけたのでタイトルだけ変えた。

2016-02-03

http://anond.hatelabo.jp/20160203010236

いるよね。

windowsこき下ろすお前にwindowsが作れるのか?パッチの一つでも送れるのか?

その割に大好きなLinuxカーネルコミッターなのか?

vimemacs

わらっちまうわ。その大好きなものでさっさと何か作れよ。評論してばっりじゃなくてさ。

少しでも自分が慣れたもの避難されて、自分アイデンティティが保てないチキンハートどもめ。

今の環境文句があるなら、さっさとgoogleなりamazonへ行ってくれよ。

はー。すっきりした。

2016-01-30

http://anond.hatelabo.jp/20160130005045

どうもありがとう

可能なら、言える範囲でご自身が感じたギャップを教えて欲しい。

ドワンゴを外から見てると、伝え聞く限りでは有名なコミッターとかハイスキル開発者がゴあちこちにいて、開発者がのびのびと良い環境仕事してる技術者楽園みたいなイメージと、一部の経営陣の思いつきで右往左往させられて疲弊している安月給の強制労働作業所の2つのイメージがごっちゃになってる。

2015-12-25

転職

次で四社目、Webエンジニア

零細企業入社にしては頑張ったと思う。

学生の頃すげーツイッターやってて、geekに憧れすぎて東京に出てweb企業転職する気まんまんでblogとかよくかいてた。その思考うまいこと実現された。

今は27で年収530ぐらいで、特にリーダーとかもやってない割にはまずまずなのかなと。入社時に一回少数チームのリーダーやったけど。

年に2万昇給できれば、24万*3年で30歳で600万ぐらいなのか。

やりたくないけど、案件リーダークラスになればもっといけるんだろう。

悪くはないのかな…。

大企業(今も大企業だけど)への転職ターゲットに入れることが出来るようになってきて、27歳、そろそろ一番バリューを出せるんじゃないか感があって、今のうちにガッツリ上げたい‥

というか今の配属が中途半端すぎて、もう違う所行きてぇ。もう一旦やりきったし、抜けるなら今…。

次の方向性は二つ。

自分が作っているものを愛せるプロダクト、サービスが作れるところに行く、ベンチャー抜けだしたぐらいの所。

もう一つはくっそ大企業給料よくて、SPI試験とかあって入るのがめんどくさい所。

後者技術が磨ければいいんだけど、売上が立っているところって安定志向で、マネジメント中心のあんまり尖ったことしないイメージが合って。。。最終着地にするぐらいの気持ちで行かないと駄目かなーって。Webでは尖ったこといってるけどぬー。

前者は、自分モチベーション駆動で働くということをしたいから最近やる気しないんだもん。。。だいたいのことは出来るようになってきたんじゃん?(ごめん言いすぎた。)作りたいものを形にする技術はそこそこあるので、ガッツリ力を振りかざしおれの心が満たされる仕事をする・・・マネジメントはおれの仕事を楽にするために行おう。もしくはサービス品質を上げるため。フロントエンドとか出来ないし・・・プロに頼むわ。なんか出口があるので上手くやれる気がするんだ・・・。書いてて思ったけど、「オレのサービス」じゃないという時点で何いってんだ感あるな。頼みベタだしなー。

なんか自分コントロールできる範囲というのを広げていかないといけないのかもしれない。

次どうしよ。もっとコード書いてモチベーションあげて、何かのコミッターになるとか、どっかで話すとかやって行かないともう一つ壁超えられないかなー。もしくはマネジメント的なとこやってお仕事スキル高めるかー。

2015-11-12

参考訳:拡散したJavaシリアル化の脆弱性についてApache Commons声明

原文:https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread

原題Apache Commons statement to widespread Java object de-serialisation vulnerability

翻訳日:2015年11月12日(午後にタイトル日本語しました)

----

2015年11月1日 火曜日

Apache CommonsJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント

著者:Bernd Eckenfels(コミッター), Gary Gregory(Apache Commons副責任者)

AppSecCali2015 でGabriel Lawrence (@gebl) と Chris Frohoff (@frohoff) によって発表された "Marshalling Pickles - how deserializing objects will ruin your day" は、信頼されないソースからシリアル化されたオブジェクトを受け取るときセキュリティ問題をいくつか明らかにしました。主な発見は、Java オブジェクトシリアライゼーション(訳注:seriarization/シリアル化/直列化=ネットワークで送受信できるようにメモリ上のオブジェクトデータバイト列で吐き出すこと。シリアル化されたJava オブジェクトRMIなどのリモート通信プロトコル使用される。)を使用する際に任意Java関数の実行や操作されたバイトコードの挿入さえもを行う方法説明です。

Frohoff氏のツールである ysoserial を使って、Foxglove Security社のStephen Breen (@breenmachine) 氏はWebSphereJBossJenkinsWebLogic、OpenNMSといった様々な製品調査し、(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) に各々の様々な攻撃シナリオ記述しています

両者の調査活動は、開発者Javaオブジェクトシリアライゼーションに信頼を置きすぎていることを示しています認証前のシリアル化されていないオブジェクトにも。

Javaにおけるオブジェクトのデシリアライゼーション(訳注:de-serialization/非直列化=ソフトウェアで扱うことができるように、送受信されたデータを元に戻すこと)が行われるとき、大抵は想定された型にキャストされ、それによって、Javaの厳しい型のシステムが、得られた有効オブジェクトツリーだけを保証しています

不幸にも、型のチェックが起こるまでの間に既にプラットホームコードが生成されて、重要ロジックは実行されてしまっています。そのため、最終的な型がチェックされる前に、開発者コントロールを離れた多くのコードが様々なオブジェクトの readObject() メソッドを通じて実行されてしまます脆弱性のあるアプリケーションクラスパスから得られるクラスの readObject() メソッドを組み合わせることで、攻撃者は(ローカルOSコマンドを実行するRuntime.exec()の呼び出しを含めて)機能を実行することができます

これに対する最も良い防御は、信頼されていないピア通信相手)とは複雑なシリアルプロトコルを使うことを避けることです。ホワイトリストアプローチ http://www.ibm.com/developerworks/library/se-lookahead/実装するように resolveClass をオーバーライドするカスタム版の ObjectInputStream を使うと、影響を制限することができますしかしながら、これは常にできることではなく、フレームワークアプリケーションサーバがエンドポイント提供しているような時にはできません。簡単な修正方法がなく、アプリケーションクライアントサーバプロトコルアーキテクチャを再検討する必要があるため、これはかなり悪いニュースです。

これらのかなり不幸な状況において、エクスプロイトのサンプルが見つかっています。Frohoff氏は、 Groovy ランタイムSpringフレームワークApache Commons コレクションからクラスを組み合わせるサンプルのペイロードに gadget chains (ガジェット・チェーン)を見つけています(訳注:provided)。これはこの脆弱性エクスプロイトのためにより多くのクラスを組み合わせられることは完全に確実なことで、しかし、これらは今日攻撃者が簡単に得られるチェーンです。

(Twitter画像)https://blogs.apache.org/foundation/mediaresource/ce15e57e-94a4-4d7b-914c-8eb8f026659c

この脆弱性のために利用される(訳注:blamed)ことができない確かな機能実装するクラスができ、安全性が信用できないコンテキストにおけるシリアル化を利用されないようにするような既知のケースの修正ができたとしても、少なくとも分かったケースだけでも継続的修正していくことが要求されますモグラ叩きゲームを始めるだけであるかも知れませんが。実際にはこれは、オリジナルチームが Apache Commons チームに警告が必要だと考えていない理由で、それゆえに比較的、活動開始が遅れました。

Apache Commons チームは InvokerTransformer クラスのでデシリアライゼーションを無効化することによって commons-collection の 3.2 と 4.0 のブランチにおける問題対処するために、チケット COLLECTION-580(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) を使っています議論されているやるべきことのアイテムは、変化させる仕組み毎(per-transformer basis)に、プログラマティックに有効にするような機能提供するかどうかです。

これには前例がありますOracle と OpenJDK JRE の一部であったり、バイトコードを挿入して実行することを許したりする com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl クラスで、セキュリティマネージャー定義されているとデシリアライゼーションを拒否します。

これはシステムプロパティ jdk.xml.enableTemplatesImplDeserialization=true とすることで無効にできますApache Commons Collection は、本来よりもこの実行モデルは一般化していないため、セキュリティマネージャー存在独立したこの機能無効化することを計画しています

しかしながら、明確化のために述べておくと、この便利な"ガジェット"は、唯一知られている方法でもなければ、特に未知のものでもありません。そのため、インストールされたものを強化されたバージョンApache Commons Collection に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。

このブログポストレビューのために Gabriel Lawrence に感謝したいと思います

Apache Commons Collection は、Java コレクションフレームワークに加えて追加のコレクションクラス提供する Java ライブラリです。InvokerTransformerコレクションにあるオブジェクトを(特にリフレクション呼び出しを通じてメソッドを呼び出すことで)変換するために使うことができる Transformer ファンクションインターフェース実装の一つです。

一般のSallyによる2015年11月10日午前10字15分にポスト | コメント[1]

コメント

OracleWeblogicセキュリティアラートを発行しています

http://www.oracle.com/technetwork/topics/security/alert-cve-2015-4852-2763333.html?evite=WWSU12091612MPP001

提供されている回避策は、T3プロトコルへのアクセス(とリバースプロキシーにおけるT3メソッドフィルタリング)です。

2015-07-24

エンジニア不足の話とエンジニア幸せ

https://news.careerconnection.jp/?p=14365

このニュースを見て、ネットの多くは、ちゃんと金払って、まともなエンジニアを集めろよ、

みたいな意見が多いが、じゃあエンジニア個人としてどうしたら幸せなのか、ちょっと考えてみたい。

ふつうの人と、当のエンジニア達との認識ギャップを中心に考える。

日本IT業界未来とかはどうでもいい。

前提

まず、現状をモデル化してみる。

新卒経験エンジニアレベル0

著名OSSコミッター程度をレベル10

その辺のよくあるプロジェクト現場リーダーアーキテクトができる程度をレベル6

とする。

認識ギャプ1:ふつうエンジニアとは

おそらくなんだけど、多くのエンジニア以外の人々は、レベル3~7ぐらいの区別が大して

ついてない問題がある。

エンジニア以外の人の認識では3~7ぐらいを一緒くたにして、「ふつうエンジニア」だと思っている。


当のエンジニア自身にしてみると、いや、4~6ぐらいからふつうになれた」、でしょ、なんて感じで思っている。

認識ギャップ2:スーパーエンジニア

ネットを見てるとスーパーエンジニア(9~10)の話をちょいちょいもってきてるけど、

そもそもそんなスーパーマンはその辺にいないので、普通の人には存在すらしらない。

仮に存在を知っていて、すごい人認識があっても、じゃあ6の人とどう違うんだろう、ってのがわからない。

ギャップを踏まえてまとめ:エンジニア単価(給料)について

ネットを見てると、技術力の高い人に金を払えと言ってる人が多いが、

上に書いたように3と5の区別ができるのはエンジニアぐらいであり、5だから単価上げるわ、とはなりにくい。

というわけで、単純に技術力を上げたところで、単価は上がらず給料も上がらない。

なので、エンジニア幸せ観点でいうと、


給料面については、上記のまとめに書いたが、実際の幸せでいうと、

働く同僚とか環境とかそういうのも要素として大きい。

Webでも、受託でも、その他でもなんでもいいが、日本エンジニア幸せ職場が多く生まれることを願ってやまない。

(そういう職場がなくなったらもう海を渡るしかないよね)

おしまい

2015-07-03

企業は有名エンジニアや有名コミッタを高額報酬で雇うべきである


奴らは会社仕事はあまりしない。

外で活動した方が自分にとって有益な事を分かっているか会社仕事なんてしないのである

それは会社が大きくなるにつれて顕著に現れる。

なぜなら自分仕事をしなくてもまわるからだ。

そして同僚からは有名であることへの嫉妬と働かないことへの不満で陰口がひどくなる。

アホな同僚は有名なだけで信者になり取り巻きになったりする。

それが対立するともう最悪で、こんな有名人雇わなければ良かったとなる。

ちなみにスタートアップの有名なエンジニアで個人プロジェクトコミットし続けているとしたら

それはあまり見込みのないスタートアップだと言える。

奴らを入れてしまったなら任せる仕事には気をつけろ。

ソロプロジェクトオープンソースプロジェクトなら適任だ。

または予め特別存在であることを示すのが良い。

奴らと良好な関係を築くのは簡単だ。

奴らは概してプライドが高い。

お世辞でもいいから自尊心を高めてあげれば良い。

逆に自尊心を傷つけられると簡単に辞める。

それでも雇うべきである理由は何よりも採用力だ。

採用に与える影響は凄まじい。

エンジニアなんてTVCMを見て糞アプリインストールするアホと同じで所詮ミーハーなのである

最初から客寄せパンダのための採用だと割り切るのが良い。

成果を出してきたらラッキーだと思い雇うと良いだろう。

もちろん有名人でありながら超絶仕事もするスーパーマンみたいな人がいる。

こういう人には逆立ちしても敵わないのである











さーって今日会社で書いた分コミットしよ!

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