Developers Summit 2014 で新卒エンジニア研修についてお話してきました #devsumi - ryopeko の何か
2014/02/13 (木) に開催された Developers Summit (通称デブサミ) 2014 1日目で「新卒エンジニア研修でできることすべきこと」と題してお話してきました。 これはその記録です。 (わいふが名札書いてくれました) はじめに 今回わざわざお時間を割いてお話を聞きにきてくださった方々、デブサミスタッフのみなさま、本当にありがとうございました。 今回のセッションは以下のような内容で話してきました。 一口に新卒エンジニア研修と言っても単に詰め込んで終わり、というのではあまりに勿体無いということを実際のDeNAでの新卒エンジニア研修の事例を紹介しつつお話します。エンジニアに継続的な成長を促すことや自立性を持たせることはとても大変なことです。しかし新卒エンジニア研修ではこの様なエンジニアの素地とも言える部分を育むにはうってつけの場です。 本講演ではDeNAが試行錯誤を繰り
デブサミ2014「社内システムの構造と設計、実装のはなし」講演メモ #devsumi - 元RX-7乗りの適当な日々
失礼ながら、モリス節炸裂しまくりで面白かった。話上手だなぁ。 「社内システムの構造と設計、実装のはなし」 田籠 聡 氏 @tagomoris LINE(株) 開発支援室 LINE 「LINEというサービス、みなさんご存じない方もいらっしゃるとは思いますが(ry」 DevOps, by Ops, for Ops 今日言いたいことは、、、 社内システムほど他システムとの連携を考えよう 社内システムではJSON APIを使おう 必要なものを作ろう これから1つずつ説明します。 Webサービス今昔 Web2.0: マッシュアップ全盛期 OAuth流行、支配的に WebAPIの制限 GoogleMapsのJS APIの制限等 Open Web API トラフィック、レスポンスタイムが課題 ニコ動も最初はコンテンツストレージにyoutube使ってた 太平洋横断してTTLが コストは誰が払う？ 互換性
デブサミ2014「グリーを支えるデータ分析基盤の過去と現在」講演メモ #devsumi - 元RX-7乗りの適当な日々
どこもそれなりに苦労・工夫しているよなぁと、興味深く聞かせていただきました。 「グリーを支えるデータ分析基盤の過去と現在」 橋本 泰一 氏 グリー 10年ほど東工大で助手・特任准教授した後、2012年にグリーにジョイン 過去の話(2011年) Webサーバからログをrsyncでストレージへ バッチ処理で集計してDBへ(MySQL) ストレージもDBもハードウェアはSolaris Sun Fire X4540 だんだん困ってきた データがほしい人が増えてきた サービスや人が増えてきた データ提供が正直しんどくなってきた 今の話: コンセプト Accessability だれでも自由に Scalability どれだけ貯めこんでも グリーのデータ分析基盤 ゲーム Treasure Data ベース ゲームへのアクセスログ GREE Platform Hadoopベース ゲームからAPIへのログ
Developers Summit 2014 で「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」という内容で発表してきました - sifue's blog
あまりにタイトルが長すぎるだろうと各所から突っ込まれ、あまりにも詰め込んだ内容で発表してしまったとちょっと反省しています。 お話としては、現在ニコニコ生放送の内部をPHPからScalaへ書きなおしているよ、というお話でした。 発表内容はこちら。 Developers Summit 2014 「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」 from Yoshimura Soichiro これらの内容は、これからScalaを使ってWebサイトを構築、運営してみようとしているリーダーさん向けに書いたものとなっています。Play2/Scalaやドメイン駆動設計、またスクラム開発の導入への足がかりにの情報となっていれば幸いです。 こんな雪の中わざわざ聞きに来てくださった皆様、そしてこの書き直しを着想するにあたってお世話になった特にじゅんいちかと
#ymsr 送別会に行ってきた - t-wadaのブログ
(個人の日記レベルのエントリであり、故人の思い出語りなので、ご存じない方はそっと閉じてください) 俺たちの幹事 @yamashiro が亡くなってしまった。知らせを受けたときは正直現実味が感じられなかった。知らせてくれたのが @meso だったから真面目に受け取ることができたというか、最初は java-ja の悪ふざけの一種かもしれないと思ってしまった。 今日 (日付上はもう昨日のことだが) 彼の送別会があった。皆で LT したり、真冬なのに打ち上げ花火を見たり、遺品を奪い合うビンゴ大会を行ったり、 java-ja らしい露悪的で自重しない送別会だった。今日会った人たちは皆それぞれのやり方で @yamashiro の死を受け止めようとしているので、そして遺族である妹さんも送別会で「書いてほしい」と仰っていたので、久しぶりに個人の日記を書こうという気になった。 送別会の帰り道で思い出したのは
ymsr送別会 #ymsr
Ymsr送別会 #Ymsr Sun, Feb 16, 2014 One-minute readこのエントリは #ymsr というハッシュタグについて書かれている。なんのことかわからない人はタブをそっ閉じしてね。 メッセで済まない用件はだいたいロクでもない山城という男が死んだ。去年の12月のことだ。交通事故だったらしい。 仕事してたら、 @regtan からFBで「電話していい？」ってメッセージが入った。メッセで済まない用件はだいたいロクでもないものだってことはよく知ってる。対衝撃姿勢で覚悟を決めて「さあこい」と電話に出たら、この話。 人間心底びっくりすると「・・・まじで？」としか言えないもんだな、と改めて思い知らされた。 またよりにもよって、その日はjava-ja.忘年会2013の当日。 @meso が急遽幹事を引き継いだので、俺も勝手に手伝うことにして受付係をやっていた。近くのコンビニに
まとまった集中時間を確保するために - yaotti's diary
Rebuild: 32: How We Work Remotely (Naoya Ito)でのremote workの話で「どう自己管理して集中できる環境を作るか」みたいな話が少しあったので，今の自分の環境をまとめておく．ぼくは割り込みや誘惑にとても(!!!)弱いので，色々と工夫した結果それなりにうまく回るようになった． デスクトップ環境 普段の工夫 ブラウザ(プロファイルとfacebook) ポッドキャストでmiyagawaさんが触れていたけれど，ぼくもGoogle ChromeのProfileを仕事用とそうでないものとで分けている． 特にFacebookが問題で，仕事でFacebookメッセージをよく使うため仕事中にfbメッセージを返す→そのままFacebookをしばらく見てしまう→気が付いたら延々Facebook見てた，ということが頻発していた． そのため，今はFacebookは基本
ymsr送別会 - じゅんいち☆かとうの技術日誌
第一回チキチキjava-ja ymsr送別会 に参加してきたよ。 最後の餞として花火を送った。 山城花火！ #ymsr pic.twitter.com/oY9dvAQBwY— (λ_ → かとじゅん) (@j5ik2o) February 15, 2014 ついろぐで@を送った相手を調べてみたら、山城が一番多かったな。 そのツイートを調べたがほとんど中身がないなと思ったら、Facebookメッセンジャーで結構話してた。 山城との最初の出会いは、たぶんSeasar Conferenceの懇親会だったと思う。彼もScalaが好きということで2011年5月ぐらいから話すことが多くなった気がする。同年8月には彼の紹介でドワンゴ社に転職した。彼を通してドワンゴ社内の人間関係を作ったといってもいいかもしれない。 ドワンゴに入社してしばらくして、Scalaを使うことができる新規案件をゲットした。チームに
ymsrがいなかったら今の自分はないと思った話 - GoTheDistance
僕のところにymsrの訃報が飛び込んだのは、12/4のjava-ja忘年会の夜にymsrを通じて友人となった@loveatからの電話だった。不慮の事故で死んだって聞いたけどマジかっていう確認の電話を僕にくれた。電話をくれた彼の声も、震えていた。 その時、僕は仕事の帰りで名神高速道路を走行していた。「いや、俺のところにはそんな話来てない。ごめんな。」で電話を切ったあと、あまりの話に驚いて直ぐに最寄りのSAに車を停めた。悪い冗談で確認電話が来ることもない。そういうことなんだろう。とにかく落ち着きたくてタリーズに駆け込んでコーヒーを飲んだ。で、facebookを見た。主語は隠されているけど多方面から似たような雰囲気のPOSTがあって、なんだよこれはっていう複雑な気持ちを一掃したくて一気に珈琲を飲み干したことを覚えている。 僕は2003年からブログを始めて、2006年にはてなダイアリーに移行した。
リリース手順書について本気出して考えてみた #CleanReleaseManual - 邪道（旧）
社内でエンジニア向けのプレゼンをする機会があったので、リリース手順書について本気出して考えてみました。 手順書書くくらいなら自動化すればいいじゃん もちろんそうです。 でも、まともなリリース手順書をつくれなければ、自動化されたリリース作業を行うことはできても自ら自動化することはできません。 自動化やContinuous Deliveryはもちろん大事ですが、自分と一緒にはたらくエンジニアには自動の前に考えてほしいことがあったのでプレゼンにまとめてみました。 新人の頃の教訓 この内容は、すべて自分が新人の頃にリーダーから伝えてもらったことです。 「変化前の確認⇒変化⇒変化後の確認」さぼらない 上から下までコピペでリリースできることが最低限 リリース手順書には相手がいる 相手の事を思いやって書く 意図を持って書く 最初はなかなかうまく書くことができませんでしたが、新人の頃に癖づけることができて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
