はてなブックマークチームの id:itchyny です。 チームのメンバー間で知見を共有することは、とても大事なことです。 特に開発エンジニア同士のコミュニケーションを増やし、お互いに足りていない知見を共有し合うことでチームの生産性を向上することは、プロダクトの成長につながります。 プロダクトの実装や設計の知見を共有するためによく取られる方法として、詳しい人が講義形式で教えるというスタイルがあります。 特に、チームに新しいメンバーが入ったときには、プロダクトの概要やコードのアーキテクチャについて説明することは一般的に行われています。 講義形式で教えるというスタイルはよく行われる方法でありながら、いくつかの課題があると感じています。 まずは説明会に参加するメンバーが、どうしても受け身になってしまいます。 説明された瞬間は分かったような気になっていても、次の週には忘れてしまうことはよくあること

こんにちは。はてなのアプリケーションエンジニアの id:onk です。 最近、若手エンジニアを中心に、いろいろな技術を見つめ直すワーキンググループをやっています。今回は、その中から「デプロイ」の会で発表されたことをまとめました（なお、私は会のとりまとめをやっている非若手です）。 デプロイのライフサイクルの違い Infrastructure Platformでのデプロイ Application Runtime Platformでのデプロイ Applicationsのデプロイ デプロイ方式はどのように変化してきたか In place から Blue/Green へ Immutable Infrastructure という考え方 オートスケールへの対応 push 型デプロイと pull 型デプロイ コンテナによるデプロイの現況 コントロールプレーンによって何が変わったか ECS におけるデプロイ

はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機

この記事は、はてなエンジニアアドベントカレンダー2016の14日目の記事です。13日は id:astj による『Perl 6 のモジュールエコシステムの話とモジュールを公開する話 (2016年12月版) - 平常運転』でした。 こんにちは。Mackerelチームでアプリケーションエンジニアをやっている id:itchyny です。 Mackerelは、同じ役割を持つホストを束ねた「ロール」、そしてロールを束ねた「サービス」というまとまりでホストを管理し、一覧性の良いグラフ画面を提供しています。 ロールあたりのホスト数、そしてサービスあたりのロール数が増えると、グラフの画面のパフォーマンスに大きく影響します。 Mackerelチームでは大規模なサービスでも快適にグラフを閲覧できるように、継続的に画面のパフォーマンスを改善してきました。 本記事では、Mackerelのフロントエンドのパフォーマ

こんにちは。アプリケーションエンジニアの id:daiksy です。 はてなでは毎週木曜日に技術勉強会を開催しています。 参考: 寿司と勉強会とエンジニア - Hatena Developer Blog 先週、当番が回ってきたので、「バックログに入らないタスクを可視化する仕組み」というトークをしました。 speakerdeck.com 詳細はスライドを見ていただくとして、この発表で定義された「税」などの用語が、さっそく社内でのコミュニケーションでも使われだして、エンジニア同士で、ある概念について共通の認識を持つためにもこういった場は効果があるな、と実感しました。 はてなでは、アプリケーションを構築する技術だけではなく、プロジェクトマネジメントやチームビルディングの知見などもこうして技術勉強会で共有されています。

Webサービスの開発は、ユーザ/顧客へ価値を早く届けるため、競合より早くリリースするため、人的リソースを無駄使いしないためなど、とにかく素早く進めたいものですね。一方で、開発を急ぐあまり品質を犠牲にすればかえって価値が失われたり、技術的負債が溜まって長期的なコストが大幅に増大する可能性もあります。開発速度とプロダクト品質は基本的にはトレードオフの関係にあるのでしょう。 開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なるとおもいます。この状況の認識がチームメンバー間でずれていると、チームのパフォーマンスを最大限に発揮できないばかりか、チーム内の関係悪化も招きかねません。エンジニアたちとプロダクトオーナーの間の対立のようなありがちな問題の原因の一つかもしれません。 そこで、開発速度と品質のトレードオフをどう判断すべきかの基準を明確にして、原則それに従

こんにちは、チーフエンジニアの id:hakobe932 です。 はてなでは毎週、社内技術勉強会を開催しています。先週の勉強会では現在開催中のはてなインターン2016の参加者のみなさんもインターン生も参加して、いっしょに技術交流を行いました。 このエントリでは、そこで発表した、契約による設計の紹介をしたスライドを公開します。 契約による設計はBertrand Meyer氏によるオブジェクト指向入門*1という書籍で紹介されている考え方です。 オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者: バートランド・メイヤー,酒匂寛出版社/メーカー: 翔泳社発売日: 2007/01/10メディア: 単行本（ソフトカバー）購入: 11人 クリック: 307回この商品を含むブログ (130件) を見る 契約による設計で

こんにちは。はてなチーフエンジニアの id:Songmu です。 去る、6月16日（火）にHatena Engineer Seminar #5をはてな東京オフィス、イベントスペースにて開催いたしました。火曜の夜という時間帯にも関わらず、多数のご参加誠にありがとうございました。 今回は、全文検索やレコメンドエンジン、機械学習などコアな技術について、はてなならではの取り組みをお伝えできたのではないかと思います。 それぞれ短いながらボリュームのある内容であったので、参加者の皆様の頭も疲れたのではないかとも思いますが、その後の懇親会も非常に盛り上がっていたのも開催者として非常に嬉しく思いました。 これからも、定期的にEngineer Seminarを開催し、皆様にはてな内での技術的取り組みをお伝えしていきます。また、アンケートにも皆様熱心にお答えいただきましてありがとうございました。頂きましたフィ

アプリケーションエンジニアの id:nobuoka です。 現在は 「少年ジャンプルーキー」 の開発に携わっています。 面白い漫画作品が数多く集まっておりますので、是非ご覧ください！ さて、去る 1 月 11 日に 「Jenkins ユーザ・カンファレンス 2015 東京」 が開催されました。 はてなからも 「はてなにおける継続的デプロイメントの現状と Docker の導入」 というタイトルでセッション発表を行いました。 ここに発表資料を公開します。 発表資料 はてなにおける継続的デプロイメントの現状と Docker の導入 from Yu Nobuoka 概要 内容としては次の 3 点です。 はてな全体のサービス開発と Jenkins についての概要 「少年ジャンプルーキー」 の開発プロセスと Jenkins の活用 開発中の機能を確認するための web アプリケーションを Docker

こんにちは、id:onishi です。先日、はてなでサービス開発合宿を開催しました。 サービス開発合宿とは、短期間（通常2〜3日）通常の開発業務から離れ、集中して開発を行い、新しいサービスや機能を開発するという合宿です。はてなの主力サービスである「はてなブックマーク」も開発合宿から生まれたサービスです。 今回は京都のオフィスと滋賀の合宿所の2拠点に分かれての開催でした。水曜日からスタートして、金曜日の午前中までが開発タイム。チームに分かれて思い思いのテーマで開発を行います。今回の合宿では38人が11のチームに分かれて開発を行いました。金曜日の午後は京都オフィスのセミナールームに集合して、合宿の成果を発表し、投票で順位を競うイベントも開催しました。 開発した機能やサービスについては、このあと一般のユーザーのみなさまへ公開するものもあるかもしれませんのでお楽しみに。 さて、今回の開発者ブログで