エンジニアのための英語
本日、以下のような文章を読んだ > I was suffered from ~ ~の部分には遭遇した諸問題について書いてあったので、この文章は「苦しめられた」と言いたいのだと推察できた。ただ、残念な事に、be suffered というのは多分現在ではほとんど使わないし、意味が若干違ってくると思う（詳しくは検索してきて！） sufferと言う言葉は「苦しむ・被る」という意味なので、受け身にすれば「苦し『められる』」という意味になるのではないか、というつもりだったのはないかと推察するが、sufferはすでに受け身の意味なので、I sufferですでに何かに苦しめられているのであり、これをさらに受け身にする必要はない。 > I had to suffer from having to deal with spaghetti code とかなら、「スパゲッティコードに立ち向かわなくてはいけなかった
優れたプログラマに対しての、管理職への昇進以外のキャリアパス | POSTD
あなたは、これからキャリアを切り拓こうとしている素晴らしいエンジニアたちを抱えています。チームは優れた成果を出して成長し続けているので、何らかの具体的な方法で賞賛したいと考えています。すぐに思いつくことは、特にエンジニアたちがそのチーム内ですでに事実上リーダーの役割を果たしている場合には、彼らにチーム内での役職を与えて昇進させることでしょう。でもその報酬は、本当にエンジニアたちが望んでいるものでしょうか？ もしかしたら彼ら自身も、昇進は望むべきもの、と思い込んでいるだけではないでしょうか？ 人材マネジメント力は別のスキル エンジニアの世界では、エンジニアたちが技術面ではピークに達した後に、これまで習得したものとは全く別の、社交面だとかソフト面におけるスキルを学ぶよう求められることがよくあります。これらは、エンジニアたちが過去のキャリアではほとんど気にしていなかったものです。このようなスキル
「Webエンジニアが知っておきたいインフラの基本」という書籍が発売されます！ - netmark.jp
突然ですが Webエンジニアが知っておきたいインフラの基本 ~インフラの設計から構成、監視、チューニングまで~ という本を書きました。 2014/12/27に発売予定です。ぜひ購入してください！そして年末年始に熟読してください！ぜひ！ ※2015/2/1頃にKindle版も出ました！ 1〜4章は特にインフラに触れたことがない方向けに基本的な内容を、5〜8章はそれだけでなくインフラ初級〜中級のISUCON決勝に残れなかったくらいの方まで広く読んでいただきたい内容になっています。 私はWebシステムの監視・障害対応という職業柄、再現性の高い方法論を言語化してつくるようにしてまして、本書にはそれをたっぷり詰め込みました。 ISUCONやtuningathonでコンスタントに短時間でそれなりの成績を出せてきたのはこの本に書いたような方法論が背景にあるんです。 この本に書いてあることをきちんと実践で
優れたエンジニアを採用できないワケ | POSTD
あなたは技術者採用の面接が苦手ですね。そう、あなたですよ。間違ったスキルを探し求め、適正の無い人たちを採用して、自分自身と会社に悪い影響を与えているのです。応募者リストを見直さなくとも、今までとは違う人材を採用し、会社の業績を上げ、あなた自身も仕事をもっと楽しめるようになりますよ。 いささか大胆な物言いだということは承知しています。仕事での経験を積み面接を担当するようになってから10年、大小の企業の様々な部署で、技術者を雇うための数多くの面接をしてきました。採用する人材が会社に及ぼす影響についても見てきました。完璧な採用を目指せというつもりはありません。私自身がこれまで何度もしてきたあらゆる失敗をあなたが犯さなくても済むよう、お伝えしたいのです。私がこれまで学んできたことは次のようなことです。 誤った判断基準 1. 応募者の現時点の知識に基づいて採用しない 面接で犯しがちな最初の間違いは、
努力とセンスの関係と優秀なプログラマー - ワザノバ | wazanova
http://www.quora.com/What-are-the-best-kept-secrets-of-great-programmers/answer/Jeff-Darcy? 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約5時間前 スポーツにしろ、勉強にしろ、仕事にしろ、何をやるにもその特定の分野でトップ1%人は尊敬するほどすごいのですが、本人が長く続けつつ努力をしてきたことが垣間見えるので、なぜ優秀なのかというのが理解できる範囲。ただし、そのさらにトップ10%、いわゆる世の中でその分野のトップ0.1%の人というのは、すごすぎて、どうしてそうなれるのかが分からないと実感することがあります。議論している時に、数歩先の真理を理路整然と突然読み取って指摘されるような、驚くようなセンスを見せつけられる経験を数
運用エンジニアから開発エンジニアになるためにやったこと · As a Futurist...
Web の会社でエンジニアを始めて 4 年、ずっと運用エンジニアをやってました。運用とは端的に言うと、社内外の他人が作ったソフトウェアを期待通りに動作させるためのエンジニアリングだと思ってます。アプリケーションはもちろん開発者が作ったものですし、MySQL や Apache や Linux も全部他人が作り上げたソフトウェアであり、それらの設定を変更したりパッチを当てたり運用ツールを駆使することで、協調動作させることに磨きをかけてきました。 ただ、いつまでたっても他人の作ったものの面倒を見てることには変わりないし、運用ツールを開発したところでそれはあくまで誰かが生み出す価値のサポートにすぎないのが自分的には満足できなくて、ずっとアプリケーション(ビジネスロジック)が作りたいと思ってました。 で、今年の始めからたまたまタイミングよく新規開発の部署に入ることになって、いきなり開発者をやることに
エンジニアの評価基準とキャリアパスのお話 | 外道父の匠
春になって暖かくなると、ついつい意識が高ぶってしまいますね。 今回はあくまで個人的な、エンジニアの評価基準とキャリアパスについての私見を、どちらかというと新人の方向けに垂れ流してみたいと思います。 はじめに 新人の方々は今頃は、研修に追われていたり、それが終わっても配属先で揉みくちゃにされる日々が待っているでしょう。中には既に後ろ向きな思考になっている人もいるかもしれませんが、そういう人には今回どうでもよい話で、前向きな人がそのエネルギーをエンジニアとしての成長に無駄なくつぎ込むために、若いうちにあまり考えないけど、考えておいた方がよい話をします。 ITエンジニアとして始動すると、目の前に与えられた仕事だけでも楽しいのに（その過程で苦しむのは別として）、さらにその先にIT知識が広く深く待ち受けていて、こんなことをやりたいんだ、全部マスターしてやるんだと意気込むかもしれません。そして、目の前
非エンジニアの新卒にプログラミング研修を行いました - pixiv inside [archive]
今年のピクシブ株式会社には総合職 2 人とデザイナー 2 人が新卒として入社しました． そんなフレッシュな新卒に新卒エンジニアがプログラミングの基礎を教えろというお達しが出ました． ということで秋卒業で既に入社していた私（@catatsuy）とアルバイトから入社した 2 人（@geta6/@RooandQoo）の合計 3 人中心でプログラミング初心者向けに研修内容を考えました． 題材 @tarbrick からのリクエストで最終目標は『画像投稿掲示板を作る』ことに決まりました． 方針 今回のプログラミング研修の目的は総合職・デザイナーの人たちをエンジニアにすることではありません． エンジニアの人たちが普段の業務でどういったツールをどういった流れで使っているのかを学ぶことで，円滑にエンジニアとコミュニケーションを取れるようにすることが目的です． そこで方針として以下のものを決めました． 全員
![非エンジニアの新卒にプログラミング研修を行いました - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c5f9cb57c356bd055bcc4941b2635b49e5da47a3/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fc%2Fcatatsuy%2F20140428%2F20140428171910.jpg)
技術の進歩は「螺旋」である。 @ t_wada さん社内講演 - >& STDOUT
先週、新卒技術研修の一環として @t_wadaさん にご講演を頂きました。 題して「この先生きのこるためには」*1。 第一線のエンジニアとして素晴らしい薫陶の数々を授けて下さいましたので、渋谷や六本木の会社さんもオファーしてみたほうがいいですよ。ホント。 エンジニアはアーティストとしての側面も持つので、ファーストクラスの方の考え方に早いうちから触れておくことは、数年先の彼らの在り方に少なからず良い影響を与えるはずだ、という考え*2に基づくおふたりめの社外講師です。おひとりめは当時非公開でしたが、時効になってましたら教えてください。 新卒研修とはいうものの、社食のカフェテリアを全開放した形で既存社員にも受講してもらいました。正直、私も含めた既存社員のほうがよっぽど直接の教育効果は高かったんじゃないかと思いましたが、それはそれとして。ご講演の中でのいくつかの気づきを共有します。 技術の進歩は「
一流になれないプログラマの生存戦略 - 誰かの役に立てばいいブログ
(2013-12-28 タイトルをエンジニア→プログラマに変えました) cybozu.com の中の人、山本泰宇です。2013年も今日で仕事納めです。 さて、先ほどプレスリリースが出たのですが、来年から私は運用本部長として、自社クラウドサービスおよび社内情報システムの運用を統括する仕事をすることにしました。この２年ほどはプログラマとしての仕事を多くしていたのですが、今後は自らプログラミングする機会は大幅に減ることになると思います。 ご存知の方もいるかもしれませんが、実は私が本部長になるのは２度目です。2005年に開発部長になり、そのまま規模を拡大して2006年に開発本部長となり、2007年に退きました。本部は違いますが、７年ぶりの再登板ということになります。略歴としては以下のようになります。 2001年12月 サイボウズに入社 プログラマとしてガルーンを開発 2005年 開発部長
そして老害になる - 方向
闇 Advent Calendar 2013の7日目として老害化の話をします。 ベンチャーじゃなく大企業につとめてよかったことは、さまざまな技術バックグラウンドを持つ人と仕事ができていることだ。 色々な流儀や文化の人たちと接し、ぶつかることで自分の視野がどんどん広がっていくのを感じている。 昔話をすると、学生時代、自分は主にRubyを書いていてJavaやPHPをダサいものだと考え、時にはそれを口にすることもあった。 しかしdisるための根拠などをしっかりと持っていたわけではなく、なんとなくで 最新技術=かっこいい、べんり 古い技術=ださい、めんどくさい と考えていた 社会人になってからダサいと思っていたまともなPHPの書き方を知りそれはそれで悪くない、むしろRubyよりすぐれだところもたくさんある素晴らしい道具と知った。 逆にcoolだと思っていたnode.jsやCoffeeScriptに
エンジニアの成長と反抗期 | 外道父の匠
最近、後進の育成について考える機会があります。 ある時、こんな状況で困ることがあるんだけど、どう思う？ と聞かれて飛び出した言葉【反抗期】について考えてみます。 相談内容 育成や生産効率をテーマにした会食にて、相談された内容は あるエンジニアが実力以上に過信して自己評価する やたら特定の技術に拘って、結局リリースが伸びたり改悪したりする ・・・んだけど、これは何なんだろう、どうしたらいい？というもの。 これに対し、自身の辿った道も思い直して出した返答が 『それは、エンジニアの反抗期だよ』 もちろんこれは、こどもがヤダヤダ拒否する（＝仕事したくない）本来の意味ではなく 逆に、やり過ぎによる失敗経路への舵切りのことを指しています。 聞き手はこれで非常に納得がいった様子。 反抗期とは おそらく3～5年目の時期に、技術やアイデアに偏ったものを創り出すことがあります。 そして、閑古鳥／改悪サービスに
「#ぶつかり稽古」という事件について - Kentaro Kuribayashi's blog
去る11月23日、あるイベントが開催された。「秋のエンジニアぶつかり稽古 2013」という。何を目的にしたイベントなのか誰も(主催者側ですらも)わからないまま始まったこのイベントは、しかし、最後までその目的が明らかにならないままに、なぜか大成功の余韻だけはしっかり残して終わった、異常な「事件」と呼ぶ他ないものとなった。 事の発端 そもそもの始まりからして意味不明だったのである。発端はこれだ。 @__kan こんにちは、ペパボです。YAPC::ASIA参加者スペシャル特典にご応募いただき、ありがとうございます ！ @kentaro とのぶつかりげいこをぜひ開催したく思います。ご都合のよろしい日をいくつかご連絡下さい！ pic.twitter.com/uoj2uExHBU— ペパボ(paperboy&co.) (@pepabo) October 2, 2013 2ヶ月ほど前、YAPC::Asi
UI研究者 増井俊之が語るエンジニアに伝えたいこと | 三年予測 ｜dodaエンジニア IT
UI研究者 増井俊之 1959年生まれ。54歳。慶應義塾大学環境情報学部教授。東京大学大学院修士課程卒業後、富士通、シャープ、ソニーコンピュータサイエンス研究所、産業技術総合研究所を経て、2006年から2008年まで米AppleでiPhoneの日本語入力方式の開発に従事。2008年より慶應義塾大学。 慶應義塾大学SFC（湘南藤沢キャンパス）にある増井俊之の研究室は、混沌とした楽しさが感じられる場だった。まず、ドアの開閉の方法からして違う。「NFC対応のスマートフォンをかざして回す」操作で解錠する仕組みが作り込まれている。ドア解錠の機構から伸びるケーブルの先には、ガジェット作りでは定番のマイコンボード「Arduino」がある。ユーザインタフェース研究者である増井の研究成果をドア解錠の機構に組み込んでいるのだ。 研究室の入り口には、研究室メンバーが「ニコニコ学会」で大賞を獲得したときの副賞のだ
エンジニア採用ってむずかしい。
見つからないエンジニアを探し出す技術：なぜ，エンジニアの採用は難しいのか？｜gihyo.jp … 技術評論社というWeb連載が私の周囲だけかもしれないが、軽く話題になっている。この連載は「エンジニア出身の採用担当者」ならわかることだけど、そうでない人事部の人にはわからないことを教えてあげる、というスタンスで書かれているように見える。定義とターゲットがはっきりしないのでなんとも言えないけれども。 実のところ、エンジニアがあきらかに採用に関わっている会社でも実際は悩みまくっているのが本当のところ。自分も下手すると週に10回くらいは普通に面接して、最後のジャッジにも関わっているので関心のあること。まだ３回目なのでどのように発展するか楽しみである。 一方で、採用される側として見ると、それはそれで面白いことが書いてある。第3回には、勉強会を開こうにも場所を貸してくれない話が書かれている。「次にどうい
師弟登壇・新米サムライの集い 2013
新卒エンジニアの研修期間も終わった秋この頃ですが、会社の垣根を越えて研修内容を公開してしまおうというイベントです。 Webサービスを運営している会社に就職を考えているけど、研修の内容が気になるという就職活動中の学生の皆さん 半年間必死に勉強してきたけど、他社の研修内容が気になるという新卒エンジニアの皆さん 来年の研修内容をどうしよう...と困っている人事担当、研修担当の皆さん 上記のいずれかに当てはまる方はもちろん、当てはまらない方も是非お越しください! プログラム 13:00-13:10 開会の挨拶・諸注意 13:10-13:25 cookpad 発表者: @hotchpotch 13:25-13:55 DeNA 発表者: @ryopeko, 鈴木聡一郎 13:55-14:25 GREE 発表者: @imagire, 水谷 宗隆 14:25-14:30 休憩 14:30-15:00 ka
できるエンジニアだけで組織をつくる - ワザノバ | wazanova.jp
http://www.slideshare.net/bcantrill/surge2013 上記のスライドは、JoyentのSVP, EngineeringであるBryan Cantrillがエンジニア組織のあるべき姿ついてまとめたものです。BryanはSun Microsystems出身で、同社がOracleに買収されたのを受けて、2010年にJoyentに移ったという経歴。Joyentはクラウドサービスの会社ですが、Node.jsのスポンサー企業として知られ、Node.jsの中心人物であるIssac Schlueterなどフルタイムでオープンソース開発に従事する社員がいます。昨年、Greylock, Intel CapitalなどからSeries Dラウンドで$85Mの資金を調達してますので、投資家からは上場を期待されていると思われます。 彼の意見としては、 [モチベーションをあげるポ
【結果発表】 優秀なエンジニアが使うプログラミング言語とは？ - paiza times
paiza開発日誌一発目の記事は片山がお送りします。 さて、初回からいきなり釣りなタイトルですみません。今回何を書きたかったというと、僕たちが運営しているIT/Webエンジニア特化のコーディング転職サイトpaiza[パイザ]で出題している初級問題のプログラミング言語別結果が自分たちで見ても面白かったので、その結果を単純に皆様にお伝えできればと思いブログを書きました。 ■paiza初級問題のプログラミング言語別結果 このプログラミング問題はすでにクローズしているので、もうチャレンジすることはできません。初級問題はこれ以外にもいろいろあるので興味ある方はpaiza(http://paiza.jp)でぜひチャレンジしてみてください。 問題の内容はpaiza開始当初に作った問題ということもあり、n番目のフィボナッチ数列を求めよ、という内容のものを、フィボナッチ数列という言葉を出さずに出題しました。
TECH FESTA 2013 - TECH FESTA 2013
株式会社Zaim 代表取締役 閑歳 孝子氏 @kansai_takako 慶應義塾大学環境情報学部を卒業後、日経BP社で記者・編集、Web系ベンチャーでWebディレクター職を経て、2008年にユーザーローカルに一人目の社員として入社。 Webアクセス解析ツール事業の企画・開発・デザインなど全般を担当。 個人として開発・運用していた家計簿サービス「Zaim」を2012年9月に株式会社化し、独立。 ZaimはAppStoreの無料ファイナンス部門にて上位を1年以上維持している。 日本仮想化技術株式会社 代表取締役社長兼CEO 宮原 徹（みやはら とおる）氏 @tmiyahar 日本オラクル株式会社でのLinux版Oracleのマーケティングに従事後、2001年株式会社びぎねっとを設立。 Linuxをはじめとするオープンソースの普及活動を積極的に行い、IPA「2008年度 OSS貢献者賞」を受賞
ベンチャーで働くエンジニアに必要な「勇気」 | Nekoya press
「恐怖」を知ること 35歳が目前に迫りつつある中、ぼちぼちスピリチュアルなことも書いていこうかと思う今日この頃です。 これまで十数年、小さな会社やフリーランス、大企業（はすぐ辞めたけど）を渡り歩いてきて改めてベンチャーの面白さを実感しています。 様々な要素がありますが、その最たる物は「エンジニアが会社の命運を握っている」という紛れもない事実です。自社でプロダクトを開発しているベンチャーにおいて、どんなに立派な経営理念やビジネスモデルも動かないシステムの前ではクソの役にも立ちません。 そして、それはそのままエンジニアの過ちが会社を危機に陥れるリスクを意味します。言ってしまえば「ワンクリックデプロイ」が「ワンクリック倒産」へと直結するかもしれないのです。省力化そのものは目指すべきですが、自分の行為が内包するリスクは忘れてはならないのです。 「何か」が起きてしまった時に上長の責任だ、確認ミスだと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
