こんにちは、アプリケーションエンジニアのid:shiba_yu36です。今回ははてな社内で行っているエンジニアメンター制度について紹介したいと思います。 エンジニアメンター制度概要 はてなの技術グループでは、エンジニアメンター制度というものがあります。どのようなものかというと 新卒・中途、入社年数の長さに関わらず、全てのエンジニアには、必ずメンターが一人付く 基本的にはチーム外のシニアエンジニアと呼ばれる人たちがメンターとなる シニアエンジニアについては はてなの技術組織2016 - Hatena Developer Blog も参照 メンターは、目標設定・毎月の1on1・評価を通じて、メンティーの悩みの早期発見・解決、成長支援をおこなう またメンターは評価時期に、「専門スキル」という観点でメンティーの評価を行う という制度です。 それではこれから、どのような目的でメンター制度を導入してい

こんにちは、はてなブログユーザーチームのアプリケーションエンジニア・テックリードのid:aerealです。 京都では例年より早咲きの桜が見頃を迎え散りはじめた4月、今年も新卒をはじめとする新メンバーを迎え、心機一転より一層サービス開発に邁進していく心を新たにしました。 そんな中、新体制でやっていく上で昔から馴染のメンバーもそうでないメンバーも、今一度お互いのことを深く知ることが必要ではないかと考え、チームビルディングのためにドラッカー風エクササイズを実践してみました。 ドラッカー風エクササイズとは何か、実践してみてどんなものが得られたかを紹介します。 ドラッカー風エクササイズの紹介 ドラッカー風エクササイズとは『アジャルサムライ』のコラムで紹介されている、チームメンバーが4つの質問に答えるチームビルディングのためのエクササイズです。 プロジェクトを始めるときに、次の4つの質問をチームで共有

こんにちは。Mackerel開発チームディレクターの id:daiksy です。 Mackerelチームでは、開発プロセスにおけるプラクティスや、チームをうまく機能させるための様々な取り組みに対して、普段から定期的なカイゼンを行っています。 世の中は新年度を迎え、いろいろと新しい取り組みにチャレンジしやすい時期でもありますし、Mackerelチームで行った最近のカイゼンの様子を簡単にまとめてみようと思います。 振り返りでKPTをやめた Mackerelチームではスクラムをベースとした開発サイクルを採用しており、1スプリント2週間というペースで開発イベントが計画されています。スプリント最終日に振り返りを実施し、2週間の間に起きた出来事や課題などを議論して、次のスプリントでカイゼンをする、というルーチンです。 チームではこれまで長い間、KPTという振り返りのフレームワークを採用していました。K

こんにちは！チーフエンジニアの id:Songmu です。 来る10月30日(月)、サポーターズさんの会場をお借りして「Hatena Engineer Seminar #9」を開催します！今回は、はてな東京オフィスでの開催ではないのでご注意下さい。 connpass.com Hatena Engineer Seminarは、はてなのサービスを開発する上で、エンジニアがどのような事を考えているのか、どのような働き方をしているのかを語るイベントです。 過去にもインフラ技術やフロントエンド開発など、様々なテーマで開催されてきました。 Hatena Engineer Seminar - connpass 今回のテーマはスマートフォンです。 はてなは、Swiftのコミッターが在籍していたり、Kotlinをいち早くAndroid開発に取り入れるなど、スマートフォン開発に力を入れています。 今回は、はて

Webオペレーションエンジニアのid:y_uukiです。 最近、Webオペレーションチーム(正式にはシステムプラットフォーム部)のテックリードと名乗り、社内で活動し始めました。 テックリードについては、id:motemen の はてなにおけるテックリード、そしてサービスプラットフォームチームのテックリードについて - Hatena Developer Blog に書かれています。 もともと、テックリードというロールはサービス開発チーム向けのものであり、Webオペレーションチームでは特にテックリードはアサインされていませんでした。 今回、テックリードとなったのは、ちょうどやりたいことをやろうとしたときに、何らかのロール名があったほうがやりやすかろうと思い、マネージャーに相談して名乗り始めたのが経緯です。したがって、Webオペレーションチームのテックリードとはこうであるといった定義があるわけで

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

はじめに みなさま、こんにちは。株式会社はてなの id:funnelbit です。はてなでは Android アプリ、また最近では iOS アプリの開発に携わっています。 さて、Google は毎年5月に Google I/O という開発者向けイベントを開催しています。今年も現地時刻で5月17日から開催されました。Google I/O は抽選でチケットが決まる仕組みで、僕はこれまで当選することはなかったのですが、この度運良く Google I/O 2017 に行く事ができ、現地で発表と空気感を味わってきましたので、（少し前の話題になりますが）その一部を共有したいと思います。 今回の Google I/O では去年に引き続き機械学習を軸にした機能を押してきており、さらに AI にシフトしていくと強く明言。もはや「どのプラットフォームでソフトウェアを作る」かはさほど重要ではなく、いかなる環境に

こんにちは、 id:alpicola です。今年4月に新卒入社してアプリケーションエンジニアとして働いています。 ウェブアプリケーションはその性質上、データベースに対して同時に大量の問い合わせを行います。そうした中でデータベースが個々の問い合わせを処理していくときに起こっていることは何か、どういう順序で処理が行われるのか、というのは興味深い話題かと思います。例えばデータベースに対して行った更新処理の結果が、更新を行ったクライアント以外のクライアントからも「見える」ようになるのはいつでしょうか。入社間もない頃、先輩エンジニア達にそうした疑問をぶつけてみたところ、「トランザクション分離レベル」というキーワードと、この分野の古典的な論文 A Critique of ANSI SQL Isolation Levels を教えてもらい、輪読会を社内で開催しました。この記事ではこの輪読会の模様をレポー

こんにちは、アプリケーションエンジニアのid:takuji31です。今年の4月にはてなブックマークのチームにjoinし、はてなブックマークAndroidアプリのリノベーションを担当しました。 4月の末にはてなブックマークAndroidアプリのリノベーションが一通り完了しました。今日は大規模なアプリのリノベーションを完了して、実際にどうなったかを振り返ります。 はてなブックマークAndroidアプリのリノベーションについて 成果 画面ごとに優先順位をつけて、リファクタリングするものを選択した Activity/Fragment、ロジック部分のリファクタリングを行った 週に1回の定期リリースを行った やっていないこと 大きく変更が加わらないであろう画面のリノベーション 実際にやって見えた課題 大規模なアプリのコードをリファクタリングする見積の難しさ 設計の例外 途中参加したメンバーとしてリノベ

アプリケーションエンジニアの id:funnelbit(北村) です。先日 DroidKaigi 2017 で「大規模アプリのリノベーション」というタイトルで発表させていただきました。 speakerdeck.com 大まかな内容としましては以下のようなものです。 1. ドメイン知識を得る まずは現状のアプリケーションの解析からスタートします。実装済みの画面を洗い出し、現状を把握します。各画面や View に正しい名前付けを行います。 2. ライブラリと設計を決定する 次にライブラリ、設計を決定します。はてなブックマークの Android 版では MVVM を採用しています。また　Repository, Interactor, ViewModel, View といったレイヤー分けを行っています。この設計につきましては様々な議論があるところかと思います。これが唯一無二のものであると主張するつ

こんにちは、Web アプリケーションエンジニアの id:nanto_vi です。先日開催された Kyoto.js #12 において、「薄いフレームワーク指向の Web クライアントサイドプログラミング」と題した発表を行いました。とある Web アプリケーションの開発にあたって、JavaScript による GUI プログラミングにどう取り組んだかという話になります。当日のスライドの内容に口頭で伝えた内容を加え、以下にまとめます。 前提 SPA ではない そこまで覚悟しなくてもよい 薄いフレームワーク指向 cf. ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく - YAPC Asia 2011 開発期間が決まっている Web アプリケーションを新規開発するにあたり、クライアントサイドをどう実現するか。ここでは開発期間が決まっているというのが大きな要因となり、チームメンバーの

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

このエントリは、はてなエンジニアアドベントカレンダー2016の21日目の記事です。昨日は id:hakobe932さんによる次に何を勉強するかを決めるための作戦でした。 こんにちは、アプリケーションエンジニアのid:syou6162です。このエントリでは、今年の9月から社内で行なっている機械学習勉強会についての概要と、この数ヶ月でやってきた内容について紹介したいと思います。 最新の論文読み会、だけでいいのか? 他社から学ぶ 機械学習の学習データをどうやって効率的に作るか サービスへの事例や技術選定の基準をキーワードにまとめていく ときには最近の機械学習技術の話題にもキャッチアップ まとめ 最新の論文読み会、だけでいいのか? 私は今年の3月まで自然言語処理/機械学習の企業研究者として働いていて、転職して4月からはてなでエンジニアとして働いています。「転職してからあまり論文読めていないなぁー」

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

こんにちは。アプリケーションエンジニアのid:yashigani_wです。 はてなは、短期間にWebアプリケーション開発の基礎を身につけるための教材である「はてな教科書」をgithubで公開しています。 これは新入社員研修やはてなサマーインターンでの講義に利用されており、毎年のはてなサマーインターンの一環として加筆・修正し更新しています。 今年は「はてな教科書JavaScript編」「SwiftでのiOSアプリ開発」「Web開発におけるコンピュータサイエンス - 機械学習編」を変更・追加しました。 Webアプリケーション開発の学習や研修のために自由にご利用いただけます。 はてな教科書JavaScript編 今年のはてな教科書では、JavaScript教科書を一新しました。 JavaSctiptの講義は内容が長大になってしまったため、他の教科書とは別レポジトリに移動しました。 また、教科書は

こんにちは、アプリケーションエンジニアのid:shiba_yu36です。今回ははてなで毎週開催している社内技術勉強会で発表した「技術ブログを書くことについて」という発表資料を公開します。 speakerdeck.com 今回の発表をなぜ行ったかというと、もっと気軽に自分のやったことをブログに書くといいのではという考え方を社内に伝えたかったからです。エンジニアをしていると、ブログを書くときは他の人が書いていないことしか書いてはいけない、しかも完璧に書かなければならない、というような気持ちになることもあります。しかし、ブログを書くことで自分の学習をより深め、加速することもできるので、あまり気負いせずにブログを継続して書いて欲しいという思いを発表しました。これがエンジニアのブログに関する正しい考え方と言い張るつもりはなくて、一つのブログに対する考え方として、参考になれば良いなと思います。 発表で

こんにちは、Web アプリケーションエンジニアの id:KGA です。 去る、8月31日(水) にはてな東京オフィスのイベントスペース SHIBAFU において Hatena Engineer Seminar #6 〜インフラ編〜 @ Tokyo を開催いたしました。約1年ぶりの開催となりましたが、平日夜の開催にもかかわらず多数の方にご来場いただき、昨今の、インフラ技術や Web オペレーションエンジニアの働き方への注目度の高まりを肌で感じることができました。ご来場いただいたみなさま、誠にありがとうございました。 冒頭では新 CTO id:motemen よりご挨拶させていただきました 今回は、前回から少し間を置いての開催となってしまいましたが、今後はもう少し頻度を上げて定期的に Engineer Seminar を開催していく予定です。次回のテーマも固まりつつあるので、詳細が決まり次第お

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

こんにちは！はてなの id:stefafafan です。Mackerelチームのエンジニアとして去年入社しました。今回ははてなという会社に入社して間もない私が気づいた点について書きたいと思います。 エンジニアにとってのはてな モチベーションの高さ 情報共有 環境の改善 楽しく開発 スタッフにとってのはてな ミッションがしっかりと浸透している 環境の改善 エンジニアにとってのはてな 私はエンジニアとして入社したので、エンジニアの自分にとってはてながどういう環境なのかということを自分なりにお話してみます。一言で言ってしまうと、「とても良い環境」だと思っています。 モチベーションの高さ はてなのエンジニアのみなさんはもう本当にプログラミングが好きな方ばかり集まっていて、高品質なソフトウェアを開発することをいつも考えています。大学時代だと単位さえ取れれば良いみたいなひとが沢山いたりしましたが、はて

こんにちは、はてなの id:onishi です。 先日、こんな記事がはてなブックマークの人気エントリーに上がっていました。 なるほど、興味深いですね。こうやって眺めてみるとブログ事業者としては、テックブログにどんなブログサービスが使われているか気になります！ というわけで調べてみました。 エンジニアが見るべきテックブログのはてなブログ率は36%で同率首位か！？ 調査に使ったスプレッドシートはこちら https://docs.google.com/spreadsheets/d/14NuD7447Y_Vm0gPBVhPjiotwGNFdxfwV7ciGAzGlkLw/edit 調査方法がアバウトなので正確ではないかもしれません。ご了承ください。 エンジニアが見るべきテックブログを支えるブログを判定する技術 なんかひどい感じですがGoogle スプレッドシートの関数で動的にブログサービスの種類を