Subscribed unsubscribe Subscribe Subscribe

Hatena Developer Blog

はてな開発者ブログ

「Hatena Engineer Seminar #6 〜インフラ編〜 @ Tokyo」を開催しました & 資料を公開しました! #hatenatech

こんにちは、Web アプリケーションエンジニアの id:KGA です。

去る、8月31日(水) にはてな東京オフィスのイベントスペース SHIBAFU において Hatena Engineer Seminar #6 〜インフラ編〜 @ Tokyo を開催いたしました。約1年ぶりの開催となりましたが、平日夜の開催にもかかわらず多数の方にご来場いただき、昨今の、インフラ技術や Web オペレーションエンジニアの働き方への注目度の高まりを肌で感じることができました。ご来場いただいたみなさま、誠にありがとうございました。


f:id:KGA:20160831192409j:plain
冒頭では新 CTO id:motemen よりご挨拶させていただきました

今回は、前回から少し間を置いての開催となってしまいましたが、今後はもう少し頻度を上げて定期的に Engineer Seminar を開催していく予定です。次回のテーマも固まりつつあるので、詳細が決まり次第お知らせいたします。

また、当日にもお伝えしましたが、はてなでは Web オペレーションエンジニア、セールスエンジニアともに鋭意募集しておりますのでご興味のある方はぜひご応募ください。

hatenacorp.jp

hatenacorp.jp


もちろん、Web アプリケーションエンジニアも募集中です!

hatenacorp.jp


最後になりましたが、当日の発表資料を掲載いたしますのでぜひご覧ください。この度は多数のご参加、誠にありがとうございました。次回も会場にてお会いできることを楽しみにお待ちしています!

トーク

はてなのログ運用これまでとこれから id:wtatsuru

speakerdeck.com

はてなのサーバプロビジョニングについて id:hagihala

speakerdeck.com

MySQL運用とらぶるすとーり〜^2 id:ichirin2501

speakerdeck.com

LT

アプリケーションエンジニアからみたはてなのインフラの話 id:KGA

speakerdeck.com

東京にいながら仕事のほとんどを京都のエンジニアと一緒にしている私のリモートワークの話 id:dekokun

speakerdeck.com

セールスエンジニアとして今後身につけていきたい技術 id:a-know

www.slideshare.net

社内技術勉強会で「技術ブログを書くことについて」発表しました

こんにちは、アプリケーションエンジニアのid:shiba_yu36です。今回ははてなで毎週開催している社内技術勉強会で発表した「技術ブログを書くことについて」という発表資料を公開します。

speakerdeck.com


今回の発表をなぜ行ったかというと、もっと気軽に自分のやったことをブログに書くといいのではという考え方を社内に伝えたかったからです。エンジニアをしていると、ブログを書くときは他の人が書いていないことしか書いてはいけない、しかも完璧に書かなければならない、というような気持ちになることもあります。しかし、ブログを書くことで自分の学習をより深め、加速することもできるので、あまり気負いせずにブログを継続して書いて欲しいという思いを発表しました。これがエンジニアのブログに関する正しい考え方と言い張るつもりはなくて、一つのブログに対する考え方として、参考になれば良いなと思います。

発表では次の3つのテーマを話しました。

  • なぜここまでブログを書くのか
  • 技術ブログを書くモチベーションの保ち方
  • 発見したブログテクニック

以下に発表内容について簡単にまとめてみます。

なぜここまでブログを書くのか

このテーマのサマリーは、ブログを書くことはプレゼンス向上や承認欲求を満たすためだけでなくて、自分の学習を深める効果もあるということです。僕は以下の三つの理由から、ブログを書くことが学習を深めることに繋がると考えています。

  • 書くことによって自分の考えがまとまる
  • 書いたブログの内容について他の人に教えてもらえる
  • 未来に自分のブログが教えてくれる
書くことによって自分の考えがまとまる

僕は文章を書くことによって、その内容について自分のなかで知識が整理されて、学習が深まると思っています。書籍を読んだり、他の人の技術ブログを読むことによって、内容について理解した気になりますが、実際にまとめてみようとすると筆が止まることはよくあると思います。筆が止まるということは、その部分について考えがまとまっていないということなので、さらに調査することで学習が深まる効果を得ることができています。

書いたブログの内容について他の人に教えてもらえる

ブログを公開すると、その記事に対してブックマークでコメントをもらったり、Twitterで指摘をされたりします。それにより自分が気づいていなかった知識に気づくことができ、学習が深まります。

未来に自分のブログが教えてくれる

技術の勉強をしても、大体の場合数ヶ月ほど経つとその内容についてうろ覚えになってしまいます。その時に書いたブログを見返すことで、復習になります。

また、書いた時点の知識よりさらに知識がついた状態で自分のブログを読み返すことができるので、新しい知識と合わせて読むことで新たな発見が出来ることもあります。

技術ブログを書くモチベーションの保ち方

ブログをどんどん書くと学習が深まるという話をしましたが、しかし書き続けるモチベーションをどう保つのかということは難しい問題です。僕はモチベーションを保つために、次のことを心がけています。

  • すぐ書く
    • 書きたいと思ったらその熱量が残っているうちにすぐ書く
    • 当日〜1週間以内に書くことを心がけている
  • 短く書く
    • 1記事には1テーマで、できる限り短く書く
    • 頑張っていろいろなことを書こうとすると、途中で力尽き、最後まで書ききれないことがある
    • 大きくなり過ぎたら、適切に分割して書く
  • 自分のために書く
    • 今の学習のためと思って気軽に書く
    • 同じようなテーマが書かれていたとしても、あまり気にせず自分の言葉でまとめる
    • 見られることをあまり意識し過ぎると、完璧に書こうとして時間がかかりモチベーションが落ちたり、もし公開して見られなかった時に二度と書きたくないという思いになることがある
  • 完璧でなくても公開する
    • 完璧な内容にしようとすると、多大な労力がかかり、モチベーションを保てないことがある
    • 未来の自分が理解できるくらいまでまとめたら、ある程度切りをつけて公開してしまう
    • ただし、嘘は書かないように気をつける
    • 自分は大体8割くらい完成したなと思ったら公開している

発見したブログテクニック

最後に自分がブログを書き続けていて学んだブログのテクニックについて紹介しました。

炎上を防止する
  • 前提をちゃんと書く
    • どういう立場で書くのか
    • 何のテーマについて書いて、逆に何については書かないのか
  • 事実と意見を区別する
    • 意見(自分が思った・考えたこと)を、事実のように書かない
  • 必要以上に主語を大きくし過ぎない
素早く書くテクニック
  • 自分用の記事のテンプレを作る
    • 毎回最初から構成を考えて書くのは大変
    • 自分のよく書くパターンを作る
    • 例えば、新しいことをやった時は、「これまでの課題」 -> 「解決策としてやったこと」 -> 「今後の課題」という流れで書くとか
  • 推敲しながら書かない
    • 書きながらわかり易さのチェックをせず、まず一回書き終える
    • 書き終えてから推敲をする
文章を分かりやすく書くテクニック
  • 理科系の作文技術など、そのテクニックについてよくまとまっている本があるので読みましょう
  • ただし、スキルを学んでもそれは突然発揮できないので、継続して文章を書くことが大事
ネタ集めのテクニック
  • 書きたいと思ったことはすぐにメモをする
  • 自分はTrelloにTo Publishレーンを作る、Githubのprivate repositoryに書くことのメモを置いておくなどをしている

発表の後に出た質問

今回の発表にははてなにインターンに来ている人たちも参加していたのですが、その一人から良い質問がありました。「自分はブログを書いているのだけどコメントが付きません。コメントが付くためにはどうすればいいのですか?」という質問でした。

この質問に対して僕はちゃんと答えられませんでした。しかし、よくブログを書いているid:Songmuさんやid:y_uukiさんが、実際に少ししかブログを書いていないとコメントが付かないので継続してブログを書き続けるしかない、といった内容のことを言っていて、確かにそのとおりだなと感じました。僕自身もブログを1週間に1回以上書き続けて1年くらいたった時に、ようやく初めてブックマークコメントで指摘してもらえた記憶があります。

このように、そもそも指摘をうけるまで到達するのも大変なので、やはり最初はハードルを下げて、自分の学習のためと思って書き続けるのが良いのではと思いました。最初は今日やったことくらいを書くところからスタートするのでも良いと思います。

まとめ

今回は社内の勉強会で発表した「技術ブログを書くことについて」という資料を紹介しました。今回の発表でエンジニアがより気軽に自分のためにブログを書けるようになってくれたらなと思います。

契約による設計の紹介

こんにちは、チーフエンジニアの id:hakobe932 です。

はてなでは毎週、社内技術勉強会を開催しています。先週の勉強会では現在開催中のはてなインターン2016の参加者のみなさんもインターン生も参加して、いっしょに技術交流を行いました。

このエントリでは、そこで発表した、契約による設計の紹介をしたスライドを公開します。

契約による設計はBertrand Meyer氏によるオブジェクト指向入門*1という書籍で紹介されている考え方です。

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

契約による設計では、関数やメソッドと、それらを利用するコードとの間に以下のような契約を考えて分析します。

もしそちらが事前条件を満たした状態で私を 呼ぶと約束して下さるならば、お返しに事後条件を満たす状態を最終的に実現することをお約束します。

関数の仕様を決める時に、関数を実行するのに何が必要か(事前条件)、そしてどういった結果を返してくれるのか(事後条件) をはっきりさせて分析することで、関数の責任や他の部分との境界を明確にして整理することができます。さらに、契約に基づいて関数の事前条件や事後条件をコード上に表明(assertion)として表現することで、コードのまちがいに気付きやすくなり、信頼性の高いソフトウェア開発につながります。

関数とそれを使うコードの間に具体的にどのような契約を考えるのかは、関数の所属しているクラスやモジュールのアーキテクチャ上での役割に対応づけて考えることも必要で、ソフトウェア全体の設計整理していくことにもなります。

実際のプロジェクトでも、関数やクラス、クラスが属するレイヤなどにどういった責任を持たせていくかは難しいところです。そういった場面で、もしかすると契約による設計の考え方が役に立つかもしれません。

このような技術発表もやっている、はてなの社内技術勉強会の事情が気になる方はぜひ以下のエントリをご欄ください。

developer.hatenastaff.com

*1:入門と銘打っていますが原題はObject-Oriented Software Constructionであり、あまり入門的ではありません

Scala 関西 Summit ではてなにおけるマイクロサービスと Scala について発表します

こんにちは、アプリケーションエンジニアの id:aereal です。

summit.scala-kansai.org

来たる10月8日に Scala 関西 Summit という関西最大級の Scala カンファレンスが大阪で催されます。

このカンファレンスにおいて、「はてなにおけるマイクロサービスと Scala」と題してはてなにおいて Scala でマイクロサービスを開発した経験に基づく持続可能なサービスの分割や結合にまつわる考察や知見をお話しさせていただきます。

内容について

以下に CfP に記載したトークの概要を引用します:

はてなにおける Scala でマイクロサービスを開発した事例についてご紹介します。

サーバー監視サービスの Mackerel (https://mackerel.io/) や現在進行中のはてなブックマークリニューアルで主たる言語として Scala を採用しているはてなで、新たなマイクロサービスの開発を Scala で進めました。

先行するプロジェクトの知見を活かして DDD (ドメイン駆動設計) を更に洗練し実践するために、ユースケース駆動設計を導入し漸進的な分析や、ビルドプロジェクト構成やプログラミング要素技術に関して様々な工夫をしています。

過去のはてなにおける統合パターンの歴史を踏まえつつ、なぜそう至ったのかという背景まで含めた持続可能なマイクロサービスの設計についてご紹介します。


はてなは今年で創業15周年を迎えました。成長と拡大に伴い、現在稼動しているサービスは内部向けのものを含め多数・多岐に渡っています。

完全に独立し単独で役目を果たすサービスは稀で、他のサービスと連携して役目を果たすことがほとんどです。サービス同士を結合する手法もその時々で模索し試行錯誤を重ねてきました。

現在、はてなでは結合のパターンとしてマイクロサービスを HTTP で繋ぐ手法が増えつつあります。 そこに至る背景や過去の結合パターンを振り返りますので、これからマイクロサービス化を検討している方や既にマイクロサービス化し運用されている方にとって、興味深い内容となるでしょう。

また Perl を主たる言語として採用してきたはてながなぜ Scala を選んだかについても触れますので、いわゆる LL を採用してきたが Scala を検討している方にも言語選択の実例として有意義ではないかと思います。

会場でお会いしましょう

既に参加登録が始まって おります。ぜひ参加いただき足を運んで聞いてみてください。会場でお会いできることを楽しみにしています!

「Hatena Engineer Seminar #6 〜インフラ編〜 @ Tokyo」を8/31(水)に開催します! #hatenatech

こんにちは、ウェブオペレーションエンジニアの id:y_uuki です。

約1年ぶりにHatena Engineer Seminarを開催します。今回は、インフラ編ということで、はてなのウェブオペレーションエンジニアを中心としたスタッフが、はてなのサービスを支えるインフラ技術に関する取り組みをご紹介します。

「アクセスログ解析」「サーバプロビジョニング」「MySQL運用」といったインフラ技術そのものの発表に加えて、「リモートワーク」「ウェブアプリケーションエンジニアからみたウェブオペレーションエンジニア」「セールスエンジニア」といった働き方や他の職種と絡めたLTもご用意しています。

冒頭では新CTO id:motemen からの挨拶もあります!

大規模なウェブサービスのインフラ技術に興味のある方や、はてなのウェブオペレーションエンジニアが普段何をやっているのかを知りたい方はぜひご参加ください。

セミナー後は、ささやかですが懇親会も予定しています! みなさまのご参加をお待ちしています。

イベント日程と会場

  • イベント名: Hatena Engineer Seminar #6 〜インフラ編〜 @ Tokyo
  • 日時: 8/31(水) 19:20-21:40(19:00 受付開始/懇親会含む)
  • 参加費: 無料
  • 定員:60名(応募者多数の場合は抽選とさせていただきます)
  • 会場:株式会社はてな 東京オフィス

タイムテーブル

※ 内容を変更する可能性があります

時刻 名前 タイトル 時間
19:00 - 受付開始・開場 -
19:20 motemen 開会の挨拶 5分
19:25 wtatsuru はてなにおけるログ解析のこれまでとこれから 20分
19:45 hagihala はてなのサーバプロビジョニングの話(仮) 20分
20:05 ichirin2501 MySQL運用とらぶるすとーり〜^3 20分
20:25 - 休憩 5分
20:30 kga (LT) アプリケーションエンジニアからみたはてなのインフラの話 5分
20:35 dekokun (LT) 東京にいながら仕事のほとんどを京都のエンジニアと一緒にしている私のリモートワークの話 5分
20:40 a-know (LT) セールスエンジニアを支え そうな技術 5分
20:45 - 懇親会 軽食と飲み物を用意しています! -
21:40 - お開き -

お申し込み方法

以下のページからお申し込みください。

hatena.connpass.com

2016年ウェブオペレーションエンジニアの新卒研修

ウェブオペレーションエンジニアの id:y_uuki です。2016年度のウェブオペレーションエンジニアの新卒研修を紹介します。

今年はウェブオペレーションエンジニアとして2名(id:masayoshi id:taketo957)が新卒として入社しました。若手のインフラ系エンジニアが少ないと言われる昨今で、もともと7人のインフラチームに2人も新卒が加わることはなかなか珍しいのではないでしょうか。

今年の新卒エンジニアは 2016年度はてな新人エンジニア研修を行いました - Hatena Developer Blog のエントリで紹介した新人エンジニア研修の後に、チームに配属されました。通例であれば、チーム配属後はOJTという名目で即実戦投入されます。しかし、今回は、OJTの前段に2週間程度の研修期間を設けてみました。

研修の動機

ウェブオペレーションエンジニアは、一般的なコンピュータサイエンスやウェブシステムの知識に加えて、社内のインフラ基盤や各サービス固有の知識も広く求められます。前者については、書籍やウェブ上の資料で体系的に学ぶことが比較的容易です。しかし、後者については、まとまった資料がない、というのはよくある話です。したがって、具体的なタスクをこなして、ボトムアップに学んでいくことになります。

それはそれで悪くはないのですが、トップダウンに全体の構成をみる機会がないことが問題だと思っていました。具体的には、以下のようなものです。

  • 部分しか知らないと、上位レイヤと下位レイヤの両方を睨んだ最適な解決方法を発見できない
  • 部分しか知らないと、既存の解決方法があることにすら気づかない
  • やったことないタスクをやるときに、作業見積もりができない

これらをある程度解決するために、新卒向けに研修を導入することにしました。

研修の設計

問題を踏まえて、どのように研修を設計したらよいか考えました。チームの状況を鑑みて、丁寧に資料を作成し、講義をする暇は残念ながらありませんでした。

そこで、自律学習とフィードバックをベースにした研修内容を考えました。課題を与えて、課題に対してアウトプットしてもらい、アウトプットを先輩社員がこまめにフィードバックするというものです。これで、業務に必要な知識がすべて身につくわけではもちろんないので、ポインタを知っておくことが大事です。

課題は知識課題、設計課題、実践課題の3種類用意しました。

知識課題

知識課題は、はてなのインフラの現状を理解するための課題です。はてなのインフラを構成する各トピックについて、自力で調査し、その結果をまとめてもらいます。1日ごとにトピックを用意し、次の日にアウトプット内容をみて先輩社員がフィードバックします。各トピックについて、一般的な知識はある程度あるものとして、はてなではどのようにやっているのかを把握することに主眼を置いています。

調査を進めるにあたって、社内のwikiをみてもよいし、GHEにあるリポジトリも自由にみてもらってよいし、サーバにログインして非破壊的なコマンドを実行してもよいとしました。

あまり長々と研修期間を設けるわけにはいかなかったので、かなり詰め込んだ内容になっています。

  • 1日目: サーバプロビジョニング
    • オンプレミス環境におけるブートストラップの仕組み: KickstartやXen環境の作成の仕組み
    • AWS環境におけるEC2インスタンス作成の仕組み
    • Chef運用
    • アプリケーションデプロイ (Capistrano)
  • 2日目: 仮想化基盤の構成
    • Xenの構成
    • LVMの構成
  • 2日目: ロードバランサの構成
    • LVS/TUN
    • LVSの台数やLVSとサブネットの関係など
  • 3日目: 冗長化の仕組み
    • Keepalived
    • MHA & ENI
  • 3日目: MySQL運用
    • フェイルオーバの仕組み
    • 参照用スレーブ
    • バックアップ方法
  • 4日目: サーバモニタリング
    • Mackerelのステータス管理やロール管理
    • Mackerelと各ツールの連携
  • 4日目: 典型的なサービス構成
    • オンプレミス: 人力検索はてなの構成
    • AWS: はてなブログの構成
  • 5日目: その他
    • 各種サービス探訪
    • 各リポジトリ探訪
    • ネットワーク構成

設計課題

設計課題は、スケーラビリティのあるシステムをどのように設計するのかを理解するための課題です。3日ほどで課題に対する設計案を考えてもらって、発表形式で議論しました。

設計課題を設けた理由は、最近のシステムが昔に比べて要求が厳しくなっているため、気軽に任せられるようなシステムが減ってきたことです。そこで、既存のシステムをベースに大きな機能を追加するときや、アクセスが10倍になっても耐えられるようにするにはどう設計するかを考えてフィードバックする機会があればよいと考えました。

今回のお題は、「Mackerelにおいて現状の100倍の稼働エージェント数に耐えられるシステムを設計せよ」でした。他の既存サービスや架空サービスをテーマにすることも考えましたが、一番難しくておもしろいやつがよかろうということで、Mackerelにしました。

いきなり100倍と言われても、とっかかりがないと考えにくいため、以下の手順で考えてもらうようにしました。

  • 1. 現状の構成
  • 2. 現状構成の限界エージェント数
  • 3. エージェント数 10倍にしたときの構成
  • 4. エージェント数 100倍にしたときの構成

アウトプットとして以下の要求をだしました。

  • システムの構成図
  • それぞれのロールにどれくらいの規模のサーバが何台くらい必要なのか
  • 現構成から新構成にするにあたってデータ移行をどのように行うか
  • 必要に応じてアプリケーションをどのように変更するか

正解はもちろんないので、アウトプットとアウトプットに対するフィードバックを通じて、システム設計の勘所が分かれば目的達成です。

実践課題

実践課題は従来からやっていたOJTと同じものです。基本的なオペレーションを含むメンテナンスタスクと本番サービスのシステム構築が主な内容です。

研修のKPT

設計研修が終わった段階で、研修を受けたメンティー2人とメンターでKPT会をしました。

メンティー

  • Keep
    • 研修を通じて横で一緒に作業してる時にそれどうやってるのみたいなのを共有できたりできたのは最高だった
    • 設計研修は少し重かったけど実際のサービスについて調べまくるのでPWGとかに出ても話の流れについていけるのが良かった
    • 研修で色々調べる事でどの情報が古いかとかを判断する機会になるのは良い事だと思った
    • 二人で相談しながら出来たので良かった
    • サービスの構成や、はてなインフラの構成の概要がわかった
    • git grep, ag でリポジトリ内を検索や、Mackerlを使った検索などもわかった
    • 役割分担をできてよかった
  • Problem/Try
    • 調べることに熱中して、メモや、時間などを気にしなかった場面があった
    • 調べる内容も本質ではないところを調べすぎたところがある
    • 資料作りに向けての時間をもう少し作ったほうが良かった
    • (設計研修では)他社の事例をもっと見ても良かった
    • 定量的に見られるようになりたい
    • もう少し質問をすべきだったのかも知れない
    • もう少しコードを見たほうが良い
    • 設計研修はもう少し時間が欲しかったかもしれない
    • サービス影響を考えて踏みとどまる事が多かった

メンター

  • Keep
    • 新卒同士で組んで課題に取り組んでもらうのは良かった。ペアで知識を補完しあってたのがよかった
    • 知識 => 設計の課題の流れがよかった
    • 設計課題が難しすぎるかと思ったけど、ちゃんとできてた
    • メンターの負荷を最小にしつつ、今後必要となる要素(はてなのシステムの全体把握)をある程度伝えられた気がする
    • 設計課題の成果を他のチーム(Mackerelチーム)のエンジニアにもみてもらえた
  • Problem
    • 知識課題でも毎日メンターからのFBは設けたが、うまく機能していない気がする
    • メンターから課題進捗が把握しづらくて、翌日の朝にレポートを見てその場でFBだったのでやりづらかった。仮にあまり芳しくない状況のときのリカバリが難しいかもしれない
    • 急いで作ったこともあって、全体的に課題の出し方が雑だった
    • 2人じゃないとしんどい課題もありそうだったので、次の入社が1人のときにどうするか
  • Try
    • 知識課題は具体的なトピックを充実させたほうが良さそう
    • 昼も雑談とかで軽く話したほうがいいかもしれない
    • 知識課題は質問をいくつか並べてそれに答える形がよさそう
    • 設計課題は成果物のイメージをちゃんと伝えられるように

あとがき

初の試みであるウェブオペレーションエンジニアの新卒研修を紹介しました。

もともとウェブオペレーションエンジニア向けにOJT以外の研修をやるという話はありませんでした。しかし、チーム配属直前に、以前自分が雑につくったOJT用issueが、今年の新卒向けに雑にコピペされていくのをみて、このままではまずいと思い、研修を計画しました。

はてな・ペパボ技術大会〜インフラ技術基盤〜@京都 行ってきたメモ - haya14busa にメモしてもらっていますが、 はてな・ペパボ技術大会の若手座談会で、おもしろかったと言及してもらえたので、やってよかったのかなと思いました。

はてなでは、ウェブオペレーションエンジニア職の応募をお待ちしています。ただいま絶賛募集中です。

YAPC::Asia Hachioji 2016 にはてなのエンジニア4人が登壇しました!

こんにちは。はてなの id:stefafafan です。
先日 YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa が開催されましたね。こちらのイベントに私も含め、はてなから4人のエンジニアが登壇しました!この記事ではそれぞれ発表した内容を簡単に紹介いたします。

はてなブログのAMP対応で学ぶウェブサービスのAMP対応

id:hitode909 によるウェブサービスのAMP対応についての発表です。AMPの紹介をはじめ、素朴なウェブサービスのAMP対応、そしてはてなブログのAMP対応についてお話しました。

発表資料

blog.sushi.money

ウェブサービスの開発フローケーススタディ

id:shimobayashi による開発フローについての発表です。チームでウェブサービスを開発するにあたってどのように開発フローを変化させていったかをケーススタディ形式でお話しました。

発表資料

speakerdeck.com

アプリケーションエンジニアのための監視入門

id:Songmu による発表です。Mackerelの紹介をしつつ、アプリケーションエンジニアのためのWebサービスの監視についてお話しました。こちらは「飛び込み枠」での発表でした。

Anime that I Recommend for Engineers to Watch

id:stefafafan によるエンジニア向けのアニメと技術でアニメファンをサポートする方法についてのLTでした。

発表資料

speakerdeck.com


いかがでしたか。今回こちらのイベントに参加できなかった方も、今後関東や関西のイベントではてなのエンジニアと直接お話する機会はありますのでご期待ください。

またはてなではWebアプリケーションエンジニア、Webオペレーションエンジニアともに募集しておりますので興味のある方は応募お待ちしております。
hatenacorp.jp