2018年の段階で私が知らないこと
Originally written in: English • Русский (авторский перевод) Translated by readers into: Deutsch • Español • Français • Português do Brasil • Svenska • Tiếng Việt • తెలుగు • 日本語 • 简体中文 • 繁體中文 • 한국어 Read the original • Improve this translation • View all translated posts 多くの人は、私が実際に持っている知識量より遥かに多くのことを知っていると思い込んでいる。それは悪い事ではないので文句を言っているわけではない。(世の少数派の人達は、努力して資格を得ているにもかかわらず、逆の偏見に苦しめられている。それはイケてない。) この記
他のチームに｢技術的支援｣をする時に気をつけていること - Masteries
自分が働いているGaiaxのように, 社内に複数の事業があり, それぞれにエンジニアが所属して働いている場合, ｢ねえ, ○○のチームの××って仕組み, どうやってるの? うちのチームでもやってみたい!｣といったコミュニケーションから, 他のチームに対して｢技術的支援｣をする機会が生まれる事が多々あります. 最近の例だと, 社内の新規事業の立ち上げや, オンプレからクラウドへの移管のタイミングで, Infrastructure as Codeやデプロイ施策, ChatOpsなど整えたいので, 相談に乗って欲しい! という声を何度か頂いた事がありますし, よくよく考えると今やっているPhotosynthへの留学も, 見方を変えれば｢Photosynthへの技術支援｣と言えるかもしれません. そういった｢技術的支援｣をする時に気をつけている事についてFacebookにつぶやいた所, 思ったより
1443641775
よく「どうやって情報手に入れてるの？」みたいに聞かれますが、そんなの、ひたすら時間かけてgithubみたりメーリングリスト読んだり最近ではgitterの会話読んでるに決まってます。 どうやって(How)ではなく、なぜ(Why)、自分がそんなことをするようになったのかを、あらためて書いてみる気になったので書いてみたいと思います。 書こうと思ったのは、Howだけ書いても、Why書かないとあまり意味ないと思うことが多くなったからですかね。(この件に関しては) 無責任に大雑把にいうと、(どんな理由であれ)情熱みたいなものがあれば、Howは自然に身につきます、たぶん。 なお、少し長くなるし、自分語りっぽくなるし、いつも書いてるようなものとは少し方向性が違い、具体的なすぐ役に立つ技術的な内容*1は基本出てこないので、期待してるものが違うと思う人は、ここで読むのやめたほうがいいと思います。 どれほどコー
護衛艦のシステムはスマホの普及で変化した――護衛艦プログラマーに聞く、艦船を動かすソフトウェア｜CodeZine×サイボウズ式
国防の要である「護衛艦」。護衛艦の動作にもソフトウェアは重要な役割を担っています。護衛艦を動かすシステムはどのようなものなのか、システムにどんなトレンドがあるのかについて、「護衛艦プログラマー」こと、三菱スペース・ソフトウエア株式会社の中島康貴さんにお話を聞きました。 中島康貴（なかしま・やすたか）さん 三菱スペース・ソフトウエア株式会社 鎌倉事業部第一技術部に所属。横浜国立大学工学部卒業、専門は航空宇宙工学。入社後は防衛分野の大規模組み込みリアルタイムシステムの新規開発及び保守改修のプロジェクトに携わり、現在、同社でエンジニアとして活躍中。 護衛艦のシステムは、ほぼ「組み込みリアルタイムシステム」 ――護衛艦を動かすシステムにはどのようなものがあるのでしょうか。 護衛艦の航行を導く航法統制システム、レーダーや武器の統制システム、そして艦内情報の共有システムなどがあります。これらシステムの
第36回 理想と現実のギャップは早めに軌道修正を――GitHubでコードをアピールして“はてな”に転職した若きエンジニア
「間違えた！」と思っても、3年は我慢すべきか？ 就職活動や転職活動を経て、目指す会社に入社してみたものの、思い描いていたイメージと「何かが違う」――そんな経験を持つ人も少なくないだろう。 世の中、理想と現実が細部まで一致することはまずあり得ない。多くの人が、細かなギャップを埋めながら現実と向き合っているはずだ。 しかしそのギャップが埋めきれないほど大きかった場合には、将来のためにも早い段階で大きな方向修正を行うべきかもしれない。たとえ転職してでも。 今回お話を伺った芝端紹公さんは、理想とするエンジニア像を曲げることなく追い求め、理想の仕事に巡り合えたエンジニアの一人である。 芝端さんの行動力は、理想と現実とのギャップに悩む多くのエンジニアにとっても参考になるのではないだろうか。 【転職者プロフィール】 芝端紹公さん（30歳） 株式会社はてな アプリケーションエンジニア（2012年4月入社）
プログラマ能力指標表 | POSTD
2015年05月27日: 表が見にくいというご意見を頂いたため、原文著者に連絡のうえ体裁を修正しました。 上位のレベルには下位のレベルの知識も蓄積されているということに注意してください。つまり、レベル n であれば n より低いレベルの知識も全てあります。 コンピュータサイエンス データ構造
エンジニアのための英語
本日、以下のような文章を読んだ > I was suffered from ~ ~の部分には遭遇した諸問題について書いてあったので、この文章は「苦しめられた」と言いたいのだと推察できた。ただ、残念な事に、be suffered というのは多分現在ではほとんど使わないし、意味が若干違ってくると思う（詳しくは検索してきて！） sufferと言う言葉は「苦しむ・被る」という意味なので、受け身にすれば「苦し『められる』」という意味になるのではないか、というつもりだったのはないかと推察するが、sufferはすでに受け身の意味なので、I sufferですでに何かに苦しめられているのであり、これをさらに受け身にする必要はない。 > I had to suffer from having to deal with spaghetti code とかなら、「スパゲッティコードに立ち向かわなくてはいけなかった
第2回 見つからないエンジニアを探し出す技術 | gihyo.jp
能力に自信がないのは、評価する機会に恵まれていないことの裏返し 「自分にそんなに自信を持っているエンジニアはいませんよ」 先週、とあるエンジニア対象のイベント（トークショーのゲストとして出演していました）で出会ったエンジニアの多くは、「エンジニア採用が難しいと企業が悩んでいる、だからエンジニアにとっては売り手市場なのだ」といくら説明しても、自分自身の能力にイマイチ自信が持てない、といった様子でした。 しかし、求人倍率などのデータを見れば、転職市場にエンジニアが足りていないのは一目瞭然です。私自身がプロデュースしているCodeIQへも、企業の採用担当者たちからの期待が高いことからも明らかなのですが。 本連載を読んでいる皆さんの中にも「自分の能力に絶対の自信がある」という人は、それほど多くないのかもしれません。しかし、それは同時に、自分の能力を客観的にアセスメント（評価）する機会に恵まれてい
U-NOTE - サイト閉鎖のお知らせ
U-NOTE サイト閉鎖のお知らせ 長らくのご利用、誠にありがとうございました。 当サイトは2024年12月31日をもちまして閉鎖いたしました。 これまでのご支援に心より感謝申し上げます。
Post by @shyouhei
ところでPerlリスクですか。まあ、あるんじゃないですか。ぶっちゃけ。でもさあ、さすがにPerlしか書けない人たちは転職先の選択肢のなさくらい自覚してると思う。なのでPerlがどうとかいう話はしないです。各自でどうぞ。 でね、ポイントはそこじゃないだろうと思うわけですよ。どんな選択をしても同様のリスクはあるんですよ。たとえばMacromedia ShockwaveでLingoで作ってたソフトとかさあ。今ではだれもメンテできないでしょう? だから今隆盛をきわめてる技術で作ったものが、何年か後にリスクになるってのは、それはそういうものなんですよ。べつにPerlに限らん。Perlはたまたま今そういうフェーズってだけで、明日は我が身ですよ。hamlとかsassとか。
コードの綺麗さの先にあるもの - Fashionable Life
2012-11-30 コードの綺麗さの先にあるもの 久々の更新になりますね。せっかくなのではてなブログに移りました。 昨日弊社代表の 「コードが汚くてもいい」っていう社長のインタビュー記事に対して 「コードが汚いのは悪だろ」って脊髄反射してるブクマコメントとかツイートが たくさんあるのでCTOとしての自分なりの意見を書いてみようと思う。 実際の現場 最初に記事を目にしたプログラマー達はまぁ「コードは汚くてもいい」にしか目にいかないだろう。そんな会社で働きたくないって思うかもしれない。この会社には汚いコードが溢れてるんだろうなと。 脊髄反射的にブコメしたり、ツイートされているものは全て拝見させていただいた。 では実際の現場はどうなのか。 盛大に勘違いされてそうだが、そもそもの大前提としてうちのコードは別に汚くない。 綺麗、汚いとかの定義は人それぞれだが、仮にその評価軸をリーダブルコード(可読
ソースコードに技術者のレベルが現れる：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
新規に書かれたソースコードを見ると、それを書いた技術者のレベルがある程度分かります。特に、レベルが低いエンジニアが書いたコードほど、よく分かります。レベルが低いというのは、全くの初心者という意味ではありません。社会人となってソフトウェア開発に従事して数年を経過して、本人はプログラミングできると思って書いているレベルであっても、書かれたコードを見ると、レベルが低いということです。 レベルが低い大きな理由の1つは、自分が書いたコードをスキルが高い人にレビューしてもらうという習慣を本人が持たないし、組織も持たないからです。もう1つの大きな理由は、使用しているシステムや開発言語に関した、きちんとした学習をしていないということも挙げられます。※ ※ たとえば、Java言語で開発していても『Effective Java』を読んだことさえないとか。 「初心者だからと言って汚いコードを書くことが許される訳
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【インタヴュー】新世界を創造するYコンビネーターのハッカーたち
デスマーチが起きる理由 - ３つの指標