2022年9月7日（水）に、 Hatena Engineer Seminar #21 をオンライン開催しました。ご参加いただいたみなさま、ありがとうございました。 このエントリーでは、当日のアーカイブ動画や公開資料をご紹介します。 Hatena Engineer Seminar #21 について 発表概要と資料 GraphQLを使い続けて気づいたこと 〜マンガノでの活用事例から〜 - by id:miki_bene Perl でも GraphQL が使いたい - by id:nakaoka3 マルチテナントで GraphQL を使う際の工夫 - by id:mizdra GraphQLでフロントエンドとバックエンドを分離する - by id:magaming はてなが作るマンガアプリのGraphQL導入から活用 ～ コミックDAYSからGigaViewer for Appsへ～ - by

こんにちは。 はてなインターン2019 システム基盤開発コースでやったことをお話していきます。 今年のシステム基盤開発コースでは、コードネームphoenixと題して、「毎日生まれ変わるセキュアな踏み台サーバ」の作成に取り組みました。 なぜつくったのか 踏み台サーバ なぜ毎日生まれ変わるのか なぜコンテナを使ったのか 踏み台サーバを更新する仕組み SSMセッションを用いたログイン CloudFormationによる自動デプロイ（未完） Terraformによる自動デプロイ 感想など なぜつくったのか まずはじめに、なぜこのような踏み台サーバの構築を行うことになったのかについて説明します。 多くの現場でもそうであると想像されるように、現状のはてなでは様々な社内サービスや、稼働中のサーバー・データベースにアクセスするために踏み台サーバを経由する必要があります。はてなには種々のサービスが存在してい

こんにちは、マンガチームアプリケーションエンジニアのすてにゃん ( id:stefafafan ) です。マンガチーム以前はMackerelチームに所属していて、その時の仕事については以下の記事を参照ください。 developer.hatenastaff.com 「はてなではどういうものを開発しているのだろう？」「あの方はどういう仕事をしていて、どういう事を意識しているのだろう？」など、気になっている人もいると思うので、今回ははてなのマンガチームでの仕事を紹介したいと思います。 はてなのマンガチームとは？ はじめてのチーム異動 GigaViewerに関わり始める GigaViewer採用3例目「マガポケ」 GigaViewerについての解説記事を社内向けに書いた GigaViewer採用4例目「コミックDAYS」 GigaViewer採用5例目「くらげバンチ」 振り返り はてなのマンガチー

こんにちは、アプリケーションエンジニアのid:shiba_yu36です。今日は社内で数年ほど取り組んでいる障害情報の社内共有についてご紹介したいと思います。 障害情報を社内共有する理由 サービスを運営しているなら、出来る限りサービスが一時的に止まってしまうなどの障害を起こさないように事前に対策を取るなど気をつけるべきです。しかし、どれだけ事前に対策をとっても、急激なアクセスの増加や、意図しないバグの混入、オペレーションのミスなどを理由として、障害を起こしてしまうことがあります。 障害が起きた時、それに暫定的に対応して終わりとしてしまうことも多いです。しかし、復旧した後大事なのは、障害に対して適切に振り返りをし、同じサービスで同様の理由で障害を起こさない、また社内で同様の理由の障害を未然に防ぐことです。 そこで、はてなでは障害の暫定対応をした後は、障害の振り返りや他チームへの知識共有のために

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

はじめに はてなサマーインターン2017の大規模システムコースの成果報告をします。 今年の大規模システムコースではメンターのid:masayoshiさんとid:y_uukiさんの下、自律分散監視システムとそれを利用したネットワークグラフの可視化に取り組みました。自律分散監視システムでは単純なクラスタリングによる死活状況の確認だけではなくアプリケーションレベルの疎通確認を行えるものを実現しました。またどのようにしてクラスタを形成するかという問題に取り組む内に、サービス間のネットワーク上のつながりを取得できるようになり、その情報でサーバー間の関係性の可視化を行いました。この記事では、それらの詳細を説明します。 はじめに 自律監視システムの実現 中央サーバー型の監視システム 自律分散監視システム アプリケーションレベルの相互監視 どうやってクラスタを形成するか？ 実験 ネットワークグラフの可視化

※ GitHub と Slack を利用している人向けの記事になります こんにちは。はてなでアプリケーションエンジニアをしている id:hatz48 です。 社内で使っているちょっとしたツールの紹介と、それを作るのに Google App Script を利用したら楽だったという話をしようと思います。 どんなツールですか github.com はてなでは現在、コードの管理に GitHub/GitHub Enterprise、コミュニケーションツールに Slack を利用しています。 GitHub と Slack を利用していれば、おそらくその二つの連携機能 も利用しているのではないかと思います。連携はとても便利ですが、現状すべての活動を Slack に流すことが出来るわけではありません。出来ないことのうちの一つが「ラベル変更」の通知です。 はてなではいくつかのチームで、ラベルによるレビュー

はじめまして。iOSとAndroidアプリの開発を行っている、アプリケーションエンジニアの id:ikesyo です。今年1月の入社後、初めての開発者ブログでの記事になります。最近の大きな出来事は、家族会議の結果、『ユーリ!!! on ICE』のBlu-ray全巻購入をしたことです。 この記事は、はてなエンジニアアドベントカレンダー2016の17日目の記事です。昨日は id:aereal によるはてなブログのデプロイを約6倍高速化したはなし - Sexually Knowingでした。 私は現在、自分のライブラリであるHimotokiやiOS開発用のパッケージマネージャのCarthageなど、全部で十数個のオープンソースソフトウェアの開発、メンテナンスを行っています。最初の頃はGitHubでPull Requestを出すのも怖かった私ですが、自身の活動を振り返ることで、どのようにオープンソ

この記事は、はてなエンジニアアドベントカレンダー2016の1日目の記事です。 8月よりCTOになりましたid:motemenです。たいそうな肩書きがつきましたが、引き続きチーフエンジニアという役職も兼任しており、これまでどおりアプリケーションを書きつつ、技術組織の開発・改善をおこなっています。 せっかくの機会なので、このエントリでは現時点でのはてなのエンジニア組織の概観と取り組みを紹介しようと思います。 技術グループ はてなにおいてエンジニアと呼ばれる職種の人は、それぞれが提供するサービス（ウェブサービス、スマートフォンアプリ、インフラなど）を軸とする開発本部に属しつつ、職能を軸とした横串の組織である「技術グループ」に所属する、という形態を採っています。現時点で、ここに属するのは40名強になっています。 会社を駆動させていくお金を生み出すのは造られたシステムであったり、営業活動であったりす

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

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

チーフエンジニアの id:Songmu です。 4月に 新人エンジニア研修を行なった のですが、その際に、「インフラを意識したアプリケーションの書き方」という講義を担当しました。そこでおこなった講義の内容について整理しながら書き起こしていきたいと思います。 インフラを意識すると何が良いか 業務でWebアプリケーションを扱うと、個人ではなかなか扱えないトラフィックであったりデータ量を扱うことになります。小規模サービスでは考えなくてよかった多くのことを考慮する必要がでてきます。なかなか体験できないことでもあるので、楽しく、やりがいもあります。 また、そういった経験を通して、インフラを意識しコードをかけるスキルを身につけることは、Webエンジニアとしては大きな強みとなります。ISUCONで優勝できるかもしれません*1。 インフラを意識すると何が良いか 〜 中規模ベンチャーの場合 そもそも、はてな

こんにちは、はてなウェブオペレーションエンジニアの id:y_uuki です。 GMOペパボ株式会社さんとの共同で「ペパボ・はてな技術大会」を福岡と京都で開催します。 今回は、ペパボさんとはてなのインフラエンジニア・ウェブオペレーションエンジニアが集まり、インフラ技術基盤をテーマとした様々なトピックについてご紹介する予定です。 「Webサービスの運用管理からの解放」、「STNSで実現する次世代ユーザー管理」、「システムを改善する行動ログ 」、「WebサービスにおけるOSとミドルウェアのパフォーマンス改善」といったテーマによるトークを予定しています。 さらに、ペパボさんとはてなの若手インフラエンジニア・ウェブオペレーションエンジニアによる座談会も予定しています。 日程と場所 はてな・ペパボ技術大会: 7月2日(土)@はてな京都オフィス ペパボ・はてな技術大会: 7月9日(土)@ペパボ福岡支社