  |
はてなキーワード: エンジニアとは
使えないものが多くて実装時にテーブル定義を変更することばかりでストレス
型が適当で真偽値だろうが数字だろうが日付でも何でも文字列型に入れようとしてるし
中には数値型に日付が入ってることもある（UnixTimestampという意味ではない）
とりあえず全部がnullable
auto_increment も考慮されてない
複合主キーばかりで扱いづらい（これは人によると思うけど）
列名もまともな英語になってないし、中には中途半端なローマ字が混ざってる
これなら列名を Col001 みたいな連番にしてくれたほうがマシなレベルのもある
DBの列名ってアプリケーション全体でそのまま使われる事が多くて、
サーバーサイドのアプリでも、フロントのウェブアプリやモバイルアプリでも一貫して同じ名前で使うのに分かりづらい名前
ゆるい環境じゃないと生きていけないような人ばかりなのに、静的型付け言語なんてお堅いものを選ぶんや（笑）
出社なんて無理！家で働きたい
なんてゆるいものばかり求めてるのに
人材管理と打ち合わせしかできなくなったエンジニアとしてのスキルはポンコツの人やん
なぜか会社から離れても業務上のポジションでコミュニケーション取ろうとするダメな感じ
返信するのもバカらしくなりそうな内容だがまあ
「お前の」上司はそうなんだろうね御愁傷様
人材管理と打ち合わせしかできなくなったエンジニアとしてのスキルはポンコツの人やん
なぜか会社から離れても業務上のポジションでコミュニケーション取ろうとするダメな感じ
新人エンジニア社員が現場のベテラン業務委託に話を聞いてもらえないとか、
テスターがエンジニアに話を聞いてもらえないとかいう話をよく聞くけど、
俺は新人の時点でそこそこコード書けたし、エンジニアの割にはコミュ力もある方だったから、実力で一目置かせて現場と仲良くなってた。
ついでに、はっとするような指摘をくれるテスターには逆に一目置いてる。
もちろん明らかに邪険にするような態度を取るのは社会人としてNGなんだけど、実力主義の職種なんだから人のせいにしてないでコミュ力含む自分の実力磨けよなという話。
従来プログラミング業界においては、やれ「ググる力が重要」だの、やれ「分からないことはググればいい」だのと言われてきたわけだが、もうそろそろこういう妄言は根絶されるべきだ。
そもそも、専門知識の要る分野でそれなりの水準の仕事をしようと思えば、ググって済むようなことはほとんどない。
実際、プログラミング以外のあらゆる分野で「ググればいい」なんて言われることはほぼ無い。その分野の仕事に必要な基礎知識を身につける方が圧倒的にウェイトが高いからだ。
「ググる力」とか言ってるアホは、じゃあためしに俺の手元に、タネンバウムの「コンピュータネットワーク」第6版があったから、これと同等の知識を、コーディング時の調べ物だけで身につけてみてくれないか。
こんな知識は業務で必要ない？そりゃお前がその程度の仕事しかしてないってだけだろ（笑）
ネットのサンプルコードコピペするしか能のないIT土方、コンピュータサイエンスや数学にコンプレックス持ってる低学歴は、さっさとエンジニアやめろ。少なくとも、他人（とくにプログラミング初学者）を自分と同じ水準に貶めるな。
まず挙げられるのが、何でもかんでも言わなきゃやらない指示待ち無能への揶揄である、ということ
オブラートを剥ぐと、その程度のこと自力でやれカスが、であるがそんなこと言うと社会人として終わってるのでオブラートに包むのである
つぎにそこまでは無能ではないが初心者へアドバイスとして述べられるパターン
こちらは単純、元増田にも触れられてるが専門知識で調べても出てこない部分はどうしても出てきてしまう
ただしここで重要になるのは直面したその問題が、調べてできることなのか調べてもどうしようもないことなのか、の見当がすばやくつけられるかどうかである
このセンスを鍛えるのに欠かせないのがいわゆる「ググる力」であるのでやってみろと言われるわけなのだ
その最新にある程度追従していかなければならないのは宿命となっている
優秀でなくともある程度マシな人材に育てるにはその感度を鍛えてやる必要がある
ここで重要になるのは「自分から調べる」と言う行為は当たり前であり苦にならないような状態にする必要があると言うこと
もちろん当然であるがググるは比喩であり本当にググるだけでなく書籍や勉強会など必要なものを必要なだけ自分で手に入れる能力である
つらつら思いついたことはこんなところかなあ
会計系の外資コンサルがエンジニア採用している(最初からIT部隊への出荷が決まっている)のはよく知られていると思うけど、
エンジニアに資格は不要と言われるけれど、個人的には結構勉強になると思う。
自己負担の実費でIPAのネスペ、セキスペと受けたけれど結構役に立ったなと思っている。
多分その辺を勉強していなかったらDNSキャッシュポイズニングとか迷惑メールフィルタのDKIMの仕組みとかDHCPスプーフィングとかセキュリティの話題に全くついていけなかったどころか興味も持っていなかったかも知れない。でもある程度わかって興味を持てるようにようになったのはIPAの試験のおかげ。
個人開発をしろだとか仕事でOJTでしか身につかないとかいう意見はあるが、個人的にはベクトルが違う、それはそれこれはこれだと思っている。
仕事をしながらDNSキャッシュポイズニングについて調べる機会とかなかなか遭遇しないだろうしARPの仕組みBGP-4の仕組みなんて絶対に知り得なかった。
野球で言うところの個人開発は練習試合、座学は筋トレ走り込みだ。練習試合だけしかしない人が野球が上手くなると思えない。
で、今IPAの試験も一通り受けて次勉強するって何をすればいいんだって思っている。
世の中にはまだまだ未知のIT技術に溢れている、低レイヤのICチップの仕組みだとか無線LANの仕組みとかJVMのこととか、都度都度自分で調べれば良いんだろうけど効率的ではないし、何より自分の全く知らない分野というものに気付く機会はない。
⚫︎2. 技術的なこと
コミュニケーション力とか地頭とかふんわりしたこと言われるけど、もう少し具体的に言語化したらこんな感じになるんだと思う。
エンジニアとしての身内からの評価が高いのはデバッグ能力とか設計能力とかだけど、結局マネジメントからの評価だったり社会人としての評価は年収に関係あるのは前半に書いてあるような技術とは直接関係ない能力だったりする。
従来プログラミング業界においては、やれ「ググる力が重要」だの、やれ「分からないことはググればいい」だのと言われてきたわけだが、もうそろそろこういう妄言は根絶されるべきだ。
そもそも、専門知識の要る分野でそれなりの水準の仕事をしようと思えば、ググって済むようなことはほとんどない。
実際、プログラミング以外のあらゆる分野で「ググればいい」なんて言われることはほぼ無い。その分野の仕事に必要な基礎知識を身につける方が圧倒的にウェイトが高いからだ。
「ググる力」とか言ってるアホは、じゃあためしに俺の手元に、タネンバウムの「コンピュータネットワーク」第6版があったから、これと同等の知識を、コーディング時の調べ物だけで身につけてみてくれないか。
こんな知識は業務で必要ない？そりゃお前がその程度の仕事しかしてないってだけだろ（笑）
ネットのサンプルコードコピペするしか能のないIT土方、コンピュータサイエンスや数学にコンプレックス持ってる低学歴は、さっさとエンジニアやめろ。少なくとも、他人（とくにプログラミング初学者）を自分と同じ水準に貶めるな。
「あの人って具体的に何やって有名なんですか？」
「有名なフレームワーク作って有名な人とかなんですか？」
ごっこ遊びしてるだけなのはわかるけど、ホリエモンとかちょまどやひろゆきを頂点とするエンジニア同士の馴れ合いめっちゃ苦手
勉強のためでもなくみんな集まってキョロキョロして面白くもないのにニヤニヤしてる
それぞれが仕事で具体的にどんな成果出したのかなんて誰も知らない
登壇する変なアイコンの変な人持ち上げなきゃ行けないんだろうなって思って
全く行きたいと思わない
僕の観察範囲だけで申し訳ないんだけど、楽天のエンジニア微妙じゃね？
3人ぐらいお仕事とか面接で話をしたんだけど、視野が狭いというか、ベンチャーに転職してきたのにビジネスサイドに寄り添ってないというか。
なんかでかい会社にいたというネームバリューだけでベンチャーに来た印象。
※まったくの偏見です
ボイジャー１号の問題が１つのチップに起因することを突き止めたＮＡＳＡのチームは、コマンドを送ってコンピューターシステムの再起動を試み、根本原因を探ろうとした。
３月１日にコマンドを送ったところ、同月３日になって、飛行データシステムの一部に、解読不能なデータとは違う挙動があることを発見。この信号は、飛行データシステムが正常に機能しているかどうかを判断するために使っていたそれまでの形式ではなかったものの、ＮＡＳＡのディープスペースネットワークで解読することに成功した。
この内容を調べた結果、問題の原因が判明。飛行データシステムのメモリの３％が破損していたことが分かった。システムのメモリの一部を保存していたチップが、同コンピューターのソフトウェアコードの一部も含めて正常に作動していなかった。チップの不具合の原因は不明だが、劣化した可能性や、宇宙空間からのエネルギー粒子が衝突した可能性が考えられるという。
科学データと工学データの解読ができなくなったのは、このチップに保存されていたコードの損失が原因だった。
このチップを修理する手段がなかったことから、同チームはこのチップに保存されていたコードを同システムのメモリの別の場所に移すことにした。全てのコードを保存できる区画は見つけることができなかったが、コードをセクションに分割して、それぞれ飛行データシステムの別々の場所に保存することに成功した。
計画を進行させるためには、こうしたコードのセクションが引き続き全体として機能することなどを確認する調整作業が必要だったとＮＡＳＡは説明する。飛行データシステムのメモリの別の部分で問題のコードの場所を参照している箇所も更新する必要があった。
ボイジャー１号の工学データのパッケージ化に必要なコードを見極めた技術者は、同システムのメモリの新しい場所を指し示すコードを４月１８日に送信。この信号がボイジャー１号に届くまでに約２２．５時間、地球に反応が戻ってくるまでにさらに２２．５時間を要した。
２０日、ボイジャー１号から届いた反応は、コードの修正が成功し、再び解読可能なデータを受信できる状態になったことを表していた。
その瞬間、ＮＡＳＡのジェット推進研究所は拍手と歓声に包まれた。
今後も同システムのソフトウェアの問題が起きた部分を別の場所に移す作業を継続し、数週間後には科学データを受信できる見通し。
「ボイジャーにこれから何が起きるかは分からない。それでも飛行を続けて私たちを驚かせ続けている」「数多くの異常が発生して次第に困難になっている。それでもこれまでのところ、幸運にも復旧できた。ミッションは続く。若いエンジニアがボイジャーチームに加わってその知識を生かし、ミッションを継続させている」。ボイジャーのプロジェクトマネジャー、スザンヌ・ドッド氏はそうコメントしている。
