エンジニアのための英語
本日、以下のような文章を読んだ > I was suffered from ~ ~の部分には遭遇した諸問題について書いてあったので、この文章は「苦しめられた」と言いたいのだと推察できた。ただ、残念な事に、be suffered というのは多分現在ではほとんど使わないし、意味が若干違ってくると思う（詳しくは検索してきて！） sufferと言う言葉は「苦しむ・被る」という意味なので、受け身にすれば「苦し『められる』」という意味になるのではないか、というつもりだったのはないかと推察するが、sufferはすでに受け身の意味なので、I sufferですでに何かに苦しめられているのであり、これをさらに受け身にする必要はない。 > I had to suffer from having to deal with spaghetti code とかなら、「スパゲッティコードに立ち向かわなくてはいけなかった
プログラマ能力指標表 | POSTD
2015年05月27日: 表が見にくいというご意見を頂いたため、原文著者に連絡のうえ体裁を修正しました。 上位のレベルには下位のレベルの知識も蓄積されているということに注意してください。つまり、レベル n であれば n より低いレベルの知識も全てあります。 コンピュータサイエンス データ構造
エンジニアに必要な説明能力 - Konifar's WIP
最近、本業のTaptripで新機能の開発やコードレビューの数が多くなってきた中、 やはりエンジニアに必要なのは説明能力だなぁと感じることが多々あります。 これは受託の場合は全然違うよと言われるかもしれないし、裁量のある環境だけの話なのかもしれないですが、あくまで自分の感じたこととして考えをまとめておこうと思います。 エンジニアは説明することが多い 開発職じゃないとピンと来ないかもしれないですが、何かを説明することって意外と多いです。 例えばバグ修正をする時に、一番理想的な修正をするとテストも含め2日かかるけど、暫定修正なら半日で終わるみたいな場合。 「ユーザーへの影響が大きいので暫定修正で直して、次のリリースで回収できるように調整します」みたいな説明をしたりします。 もっとコードレベルの話で言うと、例えばこんなやりとりをしたりします。 ほとんど伏せているのでわかりにくいかもしれませんが、
Scaling Gilt: from monolith ruby app to micro service scala service architecture
Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/1OvXF7o. Yoni Goldberg discusses the many advantages that microservices can offer or has offered to the Gilt engineering team, as well as the challenges and how Gilt’s engineers have gone about resolving these challenges. Yoni also provides a deep-dive exploration of Gilt’s Ops strategy (Docker + AWS), approach to
新卒インフラエンジニアを育成した話 | 外道父の匠
お久しぶりでございます。諸事情によって半年近くも息を潜めていましたが、また継続的なアウトプットをしていきたいと思います。あうとぷっとあうとぷっと。 昨年からAWSに触り始めて、少しずつ研究して、今年から本番運用を開始できています。なので、そっち方面が多くなりそうなのですが、その一発目として昨年にAWSを軸に新卒インフラエンジニアを育成してみた話を書いてみます。 経緯 ウチでは一般的な新卒採用を行っています。内定が出て、入社後はエンジニアも一定期間の研修を受けて、そして配属されることになっています。 私は稀に、キャリアプランによっては内定した段階の子との面談を組まされるのですが、その時点でインフラエンジニアになるという断固たる決意を持っていて、研修の段階に入っても意志は変わらなかった野郎がいたのでインフラ部隊に入れることにしました。しましたといっても普通は、配属は本人の希望以外に人事部判断や
エンジニアとしていかに成長するかについて、GMOグループの新卒エンジニア・クリエータの皆さんにお話した - Kentaro Kuribayashi's blog
GMOグループにはGMOテクノロジーブートキャンプという新卒エンジニア・クリエータ向けの研修メニューがあって、そこでなんか話してくれという要請があったので、「エンジニアになる」というタイトルで、エンジニアとしての成長について、少しお話をしてきました。 自分自身がエンジニアとしていままでどうしてきたかみたいな話は、まとまった形ではこれまでしたことがなかったわけですが、立場上とか年齢的にも「僕ごときが……」とかいってもいられないので、恥を忍んでスピリチュアルな話をしてみました。以下、ご笑覧くださいませ。 いいたいことはだいたいスライドに書きこんだのですが、以下、ちょっとだけ補足。 このスライドを作っていた時に、ちょうど「現場ロックイン」についてのエントリが話題になったり、また、このエントリを書く直前にも似たような話題のエントリを見たりしました。 現場ロックインが技術力さげてるのかもしれない -
エンジニアを一人にさせない - futoase
エンジニアを一人にしない これは、決して一人プロダクトが悪ということじゃない。 孤独、孤立させることが問題ということ。 エンジニアを一人にさせないために 一人になってるエンジニアの周りができること 飯に誘う チャットルームで飯でいくらか話していた話題から、興味ありそうな部屋に招待する gitの使い方や、Windows 10の話とか、プロダクト外の話であれば共有しても問題ないのでそういうことをガンガン話す 飲み会については、たまにプライベートで安い飲み屋でもいいから誘う。お酒飲めない場合はランチ！ もしエンジニアが体を動かすことに興味があるのであれば、フットサルなど、プロダクトではないけど協調作業を通じて成果がでるようなことをさせる。協力系のボドゲ(パンデミックとか)でも良いかもしれない 一人になってるエンジニア、あなた自身ができること エンジニアのエリアに顔を出して、挨拶する。これだけでも
クックパッド舘野祐一氏がマネジメントに目覚めた3冊とは？【連載:エンジニアとして錆びないために読む本】 - エンジニアtype
トップページ > ノウハウ > エンジニアとして錆びないために読む本 > クックパッド舘野祐一氏がマネジメントに目覚めた3冊とは？【連載:エンジニアとして錆びないために読む本】 業界内で名の通ったCTO（最高技術責任者）や、CTOに就任したばかりのエンジニアに、仕事に役立つ書籍や読書体験を紹介してもらうこの連載。第2回目の今回は、日本最大の料理レシピサイトを運営するクックパッドの執行役CTO・舘野祐一氏に登場してもらう。 国内外でのM＆Aや海外進出を積極的に推し進め、成長への道を走り続けているクックパッド。その躍進を技術面から支える舘野氏が選んだのは、「襟を正してマネジメントに向き合うために読む3冊」だと言う。 これらの本を選んだ理由について、舘野氏に聞いていく。 技術部長就任を機に、経営やマネジメント本を読むように 20代は技術書をよく読んでいたという舘野氏が、経営やマネジメントに関する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
