ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも
この記事は Wano Group Advent Calendar 2019 の7目の記事となります。 アドベントカレンダーに「なにか」書くといって7日を予約していたんですが、特にネタを考えてなかったら、前日にネタが降ってきたという話です。 ※後日談を追加しました(2019/12/15) 始まりは経理担当者のSさんの指摘 ちょうど昨日(12/06)のことです。経理担当者のSさんに「Google Cloud Service から38,653円がクレジットカードの明細にあるのですが、証憑がないんですが…」と相談を受けました。月初は会社に対する請求の確認作業があり、請求書がない引き落としとかは問題になりますので、たまに確認されることがあります。 新しくサービスを開始する際に、AWSやGCPとか有料サービスのアカウントを新しく作る必要があったりすると、そんなことが起きたりします。要は経理担当にメール
テストの自動化とテスト駆動開発
組織としてテスト自動化に取り組むべき理由と、手段としてのテスト駆動開発を紹介する講演資料です。以下のような内容です。 ねらい： ・主に顧客向けの業務システム(B2B)を開発している、 ・プロジェクトベース、ウォーターフォールプロセスが主流の開発現場や運用保守の現場にいる、 ・マネージャーのかたに向け、 ・テスト自動化が自分たちのメリットになると納得してもらい、 ・その道筋として2つのアプローチを紹介して、 - テスト駆動開発 - ペアプログラミング ・組織的・長期的に取り組む価値を感じてもらう アジェンダ: 1.自動化したい理由 2.必要な人材を考える 3.テスト自動化の端緒 ～テスト駆動開発について～ 4.深めつつ広げる鍵 ～ペアプログラミングについて～ 5.見る夢について
こんにちは、開発チームのアーキテクトをやっている竹野（@Altech）です。先日、新人研修でソフトウェアの設計について話す機会がありました。 ソフトウェアの設計というのは関連する領域が広いため、どうしても断片的な理解になりがちです。そこで、早い段階で全体像を感じてもらうために、ソフトウェア設計の Why と How と What を1時間でまとめて話すというちょっと意欲的なコンセプトで研修を行いました。今回は、その内容を記事にしました。 この研修のねらいはじめにソフトウェアの設計について書かれた情報は世の中に多いですが、その情報の多くは How であり、それだけを読んで適切に使うことが難しいと感じています。その直接的な理由は、How に対しての What、How / What に対しての Why が語られることが少ないからです。 ただ、How だけを知っていると、それは本当に問題を解決して
伊藤直也氏が一休で学んだ、CTOの本当の役割
以前より国内トップクラスのWebエンジニアとして名を馳せていた伊藤直也氏。一休の執行役員CTOに就任することが発表されてから、約3年半が経過した。CTOのキャリアとしては「はてなブックマーク」の開発を手掛けたはてなに次いで一休が2社目となる。 7人目のメンバーとして参画したはてな時代とは異なり、ビジネスモデルがある程度確立している一休の組織で経験を積んでいくなかで、伊藤氏は事業会社のCTOとしてあるべき姿に気付いたという。 同氏は現在、CTOの役割をどう考えているのだろうか。外部技術顧問時代から関わってきた一休の5年間を振り返りながら、明らかにしていく。 問題を「解決する」のではなく、問題を「理解する」サポートをしていた技術顧問時代 ――はてな時代と現在の一休とで、CTOとしての役割に違いはありますか。 はてな入社時はエンジニアが3人しかいなかったので、CTOというよりはリーダーのような役
この記事は本番環境でやらかしちゃった人 Advent Calendar 2019 17日目の記事です。 はじめまして、ダーシノ(@bc_rikko)です。 突然ですが、懺悔します。 私は転職して10ヶ月で2回も本番環境をぶっ飛ばしました。お客様をはじめ、関係各位には多大なるご迷惑をおかけしたことを、ここでお詫び申し上げます。 1回目は2015年11月27日、入社27日目のこと。 gitの設定ミスにより壊れたブランチをmasterにforce pushしてしまい、CIが流れて本番環境が壊れた。原因はpush.defaultなのだが、詳しくはすでに記事を書いているのでそちらを読んでほしい。 2回目は翌年9月1日、入社してちょうど10ヶ月たった日のことだ。 またしても本番環境をぶっ飛ばした。しかも、前回より盛大に……。 タイトルにもあるようにrsyncコマンドが原因だ。 当記事では、この「rsy
概要 AI革命のインフラを目指すSaaS系スタートアップのFastLabel（最近資金調達しました！記事はこちら）で働いているが、今までGCPで動かしていたインフラを訳あってAWSに基盤を載せ替えることになった。 スタートアップは何よりスピードが求められるが、だからといってセキュリティやモニタリング、可用性を疎かにはできないし、大きなインフラコストに耐えられるほど体力もない。 アプリケーション要件を満たしつつ、以下を実現するアーキテクチャを設計する。 シンプルな構成・構築の容易さ スピーディな開発・適用 可用性の担保 セキュリティの担保 最低限のモニタリング 低コスト（リソース・運用） ここで紹介するアーキテクチャは実際に運用まで行っており、問題なく稼働しているし、先日AWSの方にレビューしてもらったが、「なかなかイケてる」というお言葉をもらい、特に改善点も指摘されなかった。 結論（アーキ
こんにちは、よしこです。 株式会社ナレッジワーク というスタートアップで、2020年4月の創業時から一人目のフロントエンドエンジニアをしています。 初期に考えて組み上げたスタックで1年半ほど開発・運用してみて、なかなか快適に日々開発ができているので 新規開発のプロダクト立ち上げ時にどのようにフロントエンドを構築したのか？ 立ち上げから1年以上開発・運用を続けてきた今、それらの選択はどうだったのか？ を記事にして振り返り、公開したいなと思いました。 （プロダクトの内容はステルスで進めていてあまり対外的な発信ができないので、かわりに技術的なところはどんどんオープンにしていきたいなという気持ちがあります） いろいろな項目ごとに振り返りたいので、この記事は各項目を横断するindexとして項目ごとの概要を簡単に説明し、深堀りは項目ごとに追って詳細な記事を書いていく予定です！ 前提 プロダクトとしての
ペアプログラミングで「強いエンジニアチーム」を作る！ ヤフーが実践する全てペアプロ開発の手法 - エンジニアHub｜Webエンジニアのキャリアを考える！
ペアプログラミングで「強いエンジニアチーム」を作る！ ヤフーが実践する全てペアプロ開発の手法 ペアプログラミング（ペアプロ）のメリットや導入方法について、ヤフー株式会社の山下真一郎さんが、フリマアプリ「ヤフオク!」や「PayPayフリマ」での実例をもとに紹介します。 ペアプログラミング（以下、ペアプロ）は、2人のエンジニアが共同でプログラムを書いていく開発スタイルです。メンバー同士での知識の共有や、プロダクトの品質向上が見込めるとされており、多くの企業が導入を進めています。 本稿では、ヤフー株式会社のヤフオク!カンパニー開発本部でペアプロを導入し、現在はPayPayフリマの開発の取りまとめを行う山下真一郎（@shin_yahoojp）さんに、ペアプロに取り組む意義やその手法について解説してもらいました。 なぜペアプロが必要なのか？ 質の高いコードレビューとしてのペアプロ ペアローテーション
はじめに こんにちは。 GMOアドマーケティングのKONCEです。 新卒で入社し、数年経ちました。日々の業務で学ぶことは多いですが、今年度は技術の深堀りをテーマにやっていきたいと思っています。 今回は入社してDBやSQLに関しては業務内で学ぶことが多く、特別訓練をしていたわけではなかったのですが、「SQLアンチパターン」を用いて学びながら、改めて自分の現状を見つめ直していけたらと思います。 今回は学習を行う側面と自分自身のレベルについて見直していきたいので 知っていた → ○ 部分的に知っていた → △ 知らなかった → × を付けてみようと思います。 目次 SQLアンチパターンについて Ⅰ部 データベース論理設計のアンチパターン 2-1. [○]1章 ジェイウォーク（信号無視） 2-2. [×]2章 ナイーブツリー（素朴な木） 2-3. [○]3章 IDリクワイアド（とりあえずID） 2
私個人の障害対応の経験と 一昨日参加したIncident Response Meetup vol.1での学びから 障害対応において大切だと感じていることをまとめる。 障害とは リリース後のシステムにおいてシステムの不具合やユーザーの操作ミスによってユーザー業務に影響が出ているもしくは出る恐れがあるもの。 障害対応の目的 システムを直すことではなく、ユーザー影響の回避・低減・早期回復をすること。 障害対応に対する心構え システムの信頼性の要である 障害への対応の仕方でユーザー影響が大きく変わる いつ発生するかわからないため特定の人が常に障害対応をするということは不可能である 素早く適切に行動するための備えが重要である 役割分担 障害対応では復旧対応、原因調査、ユーザーへの説明、社内調整などたくさんのことをやる必要がある。 またそれぞれの作業の難易度が高いことも多い。 一人の人間にできることは
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
「Firebase は安いし楽だしマジ最高」という一心で技術選定してしまったプロダクトが成功して見えてきた課題、割高なコスト・権限管理・カスタマイズ性、そして （特性やスキルセット的に）RDB 製品が適していたのに無理やり Firestore を採用したことによるデータ不整合。 その結果チーム内で Firebase を抜ける機運が高まるも、Firebase べっとりなアプリケーションすぎて移行しづらいといった問題に出会うかもしれません。 そのような場合に備え、Firebase の存在を隠蔽して開発することに挑戦してみましょう。 注意: Firebase を剥がしているときに「俺、次は絶対そうするわ」と感じたものを書いているだけであり、まだ実際にはこのパターンでプロダクション導入していません。 あくまで個人開発で試してみていけそうと思ったので、提案しますという体です。 また Firebase
こんにちは、一休.comスパ(以下、「スパ」)の開発を担当しているshibataiと申します🙏 今回はスパのデータベースの在庫の持ち方で試行錯誤した話をさせていただきます。 背景 2024-03-29追記: 一休.comスパにおける在庫の特徴について 一休.comスパが扱う「在庫」は、「ある日付の特定の時間に対する空き枠」です。以降の説明では、スパ施設ごと、日付ごと、また時間ごとに増えていく「在庫」をいかに効率よく扱うかについて説明しています。 詳細については次のスレッドも参照してください！ https://t.co/Y0SPmDE4yZ この記事のコメントみてると、少し我々のシステムの要件が伝わってないというかそこの説明が記事に不足しているように思った。ので以下その補足— naoya (@naoya_ito) March 29, 2024 現在の実装 スパは予約を受け付けるために在庫の
設計に悩みすぎる前に手を動かしてみる話
私がソフトウェア開発において心がけていることの一つに「設計に悩み始めたらとりあえず手を動かす」というものがあります。今まで深く考えずにそう心がけていましたが、この記事で自分がなぜそうしているのか整理して言語化してみたいと思います。 話のスコープ ここでいう「手を動かす」とは「コードを書く」ことです。設計と聞いて人によって思い浮かべるものが違いますが、ここでは「一人のソフトウェアエンジニアが四半期程度かけて開発する規模の機能の設計」を想定しています。何人ものソフトウェアエンジニアが長期に渡って行うような大規模開発には当てはまらないです。 本題 次のような経験はないでしょうか？ 設計を考えながらデザインドキュメントを書いていたら細部の粗が見えてきて無限に悩み続けてしまった。考えなきゃいけないことがどんどん膨らんでいって、いつまでも実装に手を付けられなかった。 これに対して私は「設計に悩み始めた
「1人アジャイル」から始める、アジャイル開発導入のススメ｜Agile Journeyローンチによせて - Agile Journey
みなさん、こんにちは。 ユーザベースという会社でSaaS事業のCTOを務める林 尚之です。 本日、新しいWebメディア『Agile Journey』がローンチされました。私はこのメディアに編集長として関わりますが、本稿では『Agile Journey』がどんなメディアで、なぜアジャイルをテーマとしたメディアを立ち上げたのかをお伝えしたいと思います。 『Agile Journey』はできるかぎり「実践」にフォーカスしていきたいと考えています。すでに世の中には、アジャイルに関する事柄を解説する本や資料がたくさんあり、「ペアプロってなに？」「TDDってなに？」という問いに対する基本的な解は容易に見つかるでしょう。しかし、「やり方を知る・理解する」と、「それをいかに実践するか」には別の難しさがあります。実際、私も「アジャイルをいかにして、実践するか」に関して日々、頭を悩ませていますし、試行錯誤を繰
1. Mobility Technologies Co., Ltd. Data Engineering Study #2 データ収集の基本と 「JapanTaxi」アプリにおける実践例 株式会社 Mobility Technologies 渡部 徹太郎 2020/8/19 2. Mobility Technologies Co., Ltd. 自己紹介 2 ID ：fetaro 名前：渡部 徹太郎 学生：東京工業大学でデータベースと情報検索の研究 (@日本データベース学会) 職歴： * 野村総合研究所(NRI) - オンライントレードシステム基盤 - オープンソース技術部隊 * リクルートテクノロジーズ - ビッグデータ分析基盤 * MobilityTechnologies - データエンジニア エディタ：emacs派→ InteliJ派 日本AWSユーザ会(JAWS) ビッグデータ支部長
Pythonで始める ドキュメント・インテリジェンス入門 / Introduction to Document Intelligence with Python
ビジネス文書をデータ化し構造や内容を理解するアプリケーションはドキュメント・インテリジェンスと呼ばれ、画像処理や自然言語処理といった複数の要素技術を組み合わせて開発する必要があります。何が必要でどう実現すれば良いのかといった第一歩を、Pythonでの具体的な構築事例とともに紹介します。 https…
「もうさばき切れない」アクセスが激増したECプラットフォームにおける負荷対策 - BASEプロダクトチームブログ
はじめに CTOの川口 (id:dmnlk) です。 5月にオンラインmeetupをさせて頂きその中で「具体的な負荷対策に関しては開発ブログで！」と言っていた件ですが気づいたらもう9月になりかけていました。 コロナ禍においてネットショップ作成サービス「BASE」の利用者様が急増しました。 www.nikkei.com 5 月には 100 万ショップを超えるショップオーナー様にご利用していただいております。 今まで EC 事業を行っていなかった飲食店様や様々な業種の方が利用をはじめていただき、ショップオーナー様も購入者様共に短期の見通しでは想定をしていないアクセスが発生しました。 その途中でシステムとして対応しきれない面もあり、アクセス負荷によるサービスの不安定を招き皆様にはご不便や販売時間を変更していただくお願いなどをしてしまい大変申し訳ありませんでした。 現在では安定しておりますが、その
CTO室SREの @sinsoku です。 社内のGitHub ActionsのYAMLが複雑になってきたので、私が参考にしてる情報や注意点、イディオムなどをまとめておきます。 頻繁に参照するページ 新しい機能の説明が日本語ページに反映されていないため、基本的に英語ページを読むことを推奨。 ワークフロー構文 YAMLの基本構文の確認 コンテキストおよび式の構文 github オブジェクトの情報、関数の確認 ワークフローをトリガーするイベント 各イベントの GITHUB_SHA と GITHUB_REF が記載されている About GitHub-hosted runners インストールされているSoftwareのバージョンなどが記載されている GitHub REST API APIを使うときに参照する よく使うaction actions/checkout イベントによってはデフォルトブ
こんにちは！スタンディングデスクを導入して快適な開発環境と運動不足の両方を解消できるようになったのではと感じている、広告技術部のUT@mocyutoです。 今回は半年ほどEKSを運用して秒間3万リクエストのトラフィックをさばくほどになりました。 秒間3万は広告システムだと割とあるとは思いますが、kubernetesでも運用できているので紹介しようと思います。 対象のEKSで構築したサービスは広告の配信サーバです。 広告配信サーバの要件として、まず50ms以内にレスポンスを返さなければいけません。 構築したk8sのレスポンスタイムの99パーセンタイルは10msほどで返せています。 以下は必要最小限のクラスタの構成図です。 全体像 API 弊社のサーバサイドはほぼGoで作られているので、例に漏れずGoで作られています。 pod構成はAPI、fluentd、envoyの サイドカーパターン です
Software Design連載 2021年8月号 Python製のレガシー＆大規模システムをどうリファクタリングするか - MonotaRO Tech Blog
Software Design連載開始 ※ (2021/09/02 08:55) 「Pythonを用いて開発を始めたのが2003年」を「Pythonを用いて開発を始めたのが2002年」に修正 こんにちは。金谷です。 このたび、モノタロウにおけるPython大規模開発に関する取り組みを、技術評論社様で発刊されている Software Design に連載させていただくことになりました。 モノタロウがPythonを用いて開発を始めたのが2002年。2021年の現在もPythonを用いた開発が続けられています。 事業の成長に伴い、関連するシステムやエンジニアの数も増え続けていくなかで、いかに安定的に価値を提供し続けられるのか。 モノタロウにおける取り組みを、開発や運用周りを通してご紹介していきます。 本記事の初出は、 Software Design2021年8月号「Pythonモダン化計画（第1
2019/10/11に行われた「「テスト」の話を聞いてみようの会」での登壇資料です
タイトル通りですが、1年目エンジニアのインフラのイの字も知らなかった私が1ヶ月半かけてKubernetesで環境構築するまでの失敗の軌跡です（そして環境構築できたのが奇跡）。 理想的にはこれを読めばインフラ初心者でもKubernetes（以下k8s）で環境構築できるところまで説明することですが、そういうわけでなく、環境構築の解説というより自分の失敗やつまづきポイント、役に立ったことをただただ書き連ねていきます。ただ他の初心者の方も同じようなところでつまづくこともあると思うので少しでもお役に立てたら嬉しいです。 バックエンド側で使った技術は以下になっています。 言語：Ruby（RoR） API：GraphQL インフラ：Azure その他：Docker、k8s 実際の実装でハマったところは各章の最後に教訓として簡単にまとめてはいますが、大事なことは先に結論として述べておきます。 Docker
はてなのMackerelチームはKubernetesクラスタを自前で構築して運用していたが、撤退を選択したという。なぜ、Kubernetesの運用を諦めて撤退を選んだのか。はてなのMackerelチームでSREを務める今井隼人氏が語った。 コンテナ型仮想化技術を活用したアプリケーションの管理（オーケストレーション）ツール「Kubernetes」が注目を集めている。その背景の一端にあるのが、アプリケーションをコンテナ化し、マネージドKubernetesサービスで実行することによるメリットの享受と、運用負荷の軽減だ。 参考記事：「Kubernetes」とは何か――コンテナ型仮想化の本番利用に向けた課題 参考記事：「Kubernetesで運用する」その前に Kubernetesを本番環境で利用する際のポイント そんな中、「Kubernetesクラスタを自前で構築して運用していたが、撤退を選択した
最近、TDDのテストコードは捨てても良いかみたいな議論を見ました。 これに対する自分個人の経験上の意見ですが、TDDは雑多にテストコードを使い捨てても効果を出せると思います。 もちろん、TDDで保守性が高く価値あるテストを書いて、捨てずにCIや中長期的なリファクタリングで再利用していくと、TDDの効果を増幅できます。ただ、それをするにはスキルや事前の工夫、労力が必要ですし、できる場面に限りがあります。 そういったことをやらず、もっとゆるい姿勢で取り組んでも、費用対効果をプラスにできる手法がTDDだと考えています。 今回は、そのTDDでゆるくしてもよいポイントを、実経験からまとめたいと思います。 TDDのテストは使い捨てでいい TDDのテストはプログラマのこまごまな課題に応じて累積的に作られるため、保守コストがかかるテスト・保守する価値の低いテストが生まれがちです。そのためテストの使い捨ての
宿泊予約事業やレストラン予約事業などを手掛ける、株式会社一休。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Teams」を活用いただいています。 今回は、執行役員CTOを務める伊藤直也さんにインタビュー。実際に「Findy Teams」上のデータを参照しながら、エンジニア組織における生産性についての考え方などを伺っていきます。 ■プロフィール 伊藤 直也 株式会社 一休 執行役員 CTO コロナ禍における開発を、Findy Teamsで振り返る ──こちらが御社の2020年1月から直近までのデータになります。プルリク作成数はだいたい平均値を超えていて、件数としては2020年7月と2020年10月に大きな山があります。今年は5月頃から全体的に伸びている傾向にありますが、これらの要因として考えられる部分はありますか？ Findy Teamsのチ
はじめに 今日は、ニコニコのプレミアム会員サービスを支える「プレミアム課金システム」を動画システムのモノリスから切り出し、変更可能にしていった過程について書きます。プレミアム課金システムは金銭を扱うシステムですので、「（特に、失敗した）話を聞くのは面白いけど、自分で触りたくない」と思われる方も多いのではないでしょうか。 この記事では、決済にかかわるシステムでも一般的なシステム改善の方法が適用できることをお伝えしたいと思います。また、コストを抑えつつ着実なシステム改善を行う方法論としてもご理解していただけると嬉しく思います。 背景 プレミアム会員サービスについて 月額500円（税別）のプレミアム会員制度には159万人（2020年9月末現在）の方が加入してくださっており、ニコニコ事業を支える主要な有料サービスです。 ニコニコ動画は2006年にサービスを開始し、2007年にプレミアム会員サービス
songmu @songmu feature branchか、feature flagかっていうのは実は結論のない話なんだろうな、とは思ってる。僕はfeature branchに慣れすぎてしまったけど Kazunori Otani @katzchang Gitのリポジトリ/ブランチ戦略で確実に言えそうなのは、「分岐した状態をできるだけ短くしよう」で、それを実現するためにはじつはGitだけの問題じゃなかったりするので、みなさんがんばっていきましょう。
大規模リファクタリングの極意
iOSDC 2021 での登壇資料となります。 登壇内容 https://www.youtube.com/watch?v=yWO47AFkDls 以下、スライド内に登場するリンク一覧です。 MoT Teck Talk vol.3 「タ…
2020年秋にVue.jsのアプリケーションを作るなら、押さえておきたい5つのポイント | フューチャー技術ブログ
TIGの伊藤真彦です。 ここ最近はVue.jsでのフロントエンド開発を行っています。 ほぼ何もない状態からのスタート段階から始めたのですが、その際調査したことが学びになったので共有します。 ※この記事は 2020/10/13 に執筆されました。調査日は2020/08/17～2020/09/01 のため、バージョンなど当時と状況が異なるものがあります。この1ヶ月の間でも、alphaからbetaに変わったり、betaが取れたりと進化が速いです。 公式ライブラリのステータスはこちらもご参考ください。 https://v3.vuejs.org/guide/migration/introduction.html#supporting-libraries 前提として押さえておきたい2点のポイント環境構築はVue CLIフューチャーでは仕事ですぐに使えるTypeScriptと題しまして、TypeScri
【保存版】東京リージョンの AWS 障害発生時にクラスメソッドのテクニカルサポートチームがやっていること | DevelopersIO
どのような事前準備をしているか 有事の際は想定外のことが発生しやすく、事前準備をしていないと冷静な対応が難しくなります。 いきなりしっかりした事前準備をすることは難しいので、徐々に成熟度を上げていきます。 本章では以下の観点で、事前準備についてご紹介します。 手順書 自動化 訓練 手順書 フローやチェックリストを含む手順書を準備しています。 手順書の内容は後述します。 分かりやすい手順書を準備することも重要ですが、その手順書への導線づくりも大切にしています。 運用周りのドキュメントは数が多く、目的のドキュメントが埋もれてしまい他のメンバーが見つけられない場合があるからです。 周知に加えて、ドキュメントの階層を見直したり、特定チャンネルに手順書の URL をピン留めしておくなど、手順書に辿り着きやすくする工夫をしています。 分かりやすい手順書の書き方については、以下のブログが参考になります。
大規模なソフトウェア開発は多くの人が関わり、多額の資金が費やされますが、時として社内外の要因によって開発現場が地獄と化す場合もあります。近年ではみずほ銀行の基幹システム開発が書籍化されるほど苦難の道を歩んだことはIT業界で知られていますが、そんな「地獄の開発現場」がかつてUberにも存在したと、元UberのエンジニアであるMcLaren Stanley氏が当時の状況を振り返っています。 Alright folks, gather round and let me tell you the story of (almost) the biggest engineering disaster I’ve ever had the misfortune of being involved in. It’s a tale of politics, architecture and the sunk
数列の和を求めるプログラムを作成することになり、意気揚々と以下のようなプログラムを書いたという状況を想像して下さい。 function sum(nums, acc = 0) { if (nums.length === 0) return 0; if (nums.length === 1) return nums[0]; return sum(nums.slice(1), acc + nums[0]); } const nums = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]; console.log(sum(nums)); // expected: 55 一見すると何も問題なさそうに見えるプログラムですが、実はバグがあります (皆さん分かりますか?) *1。実際に上記プログラムを実行すると 55 ではなく 10 が出力されます。 こうした場面に遭遇すると、自然と sum
「どのように開発するか」だけでなく、上流からプロジェクトに携わり「何を開発するか」から検討したい、と考えているエンジニアの方は少なくないでしょう。 一方、実際の開発現場では「WHAT（何を開発するか）」がすでにある程度検討され、エンジニアはその実現方法を具体化させるフェーズから参画し「HOW（どのように開発するか）」を考えるケースが多いのではないでしょうか。 「WHAT（何を開発するか）」を検討するフェーズからボトムアップでアイデアを出し、プロダクトの成長にコミットしたいーー。そんな思いを強く持つエンジニアにとって、理想的な環境とも言えるのがリクルートです。 今回、同社を代表するプロダクトである『SUUMO』のレコメンドAPIのインフラを、機械学習エンジニア（以下、MLE）とデータエンジニア（以下、DE）が連携して改修したプロジェクトを参考に、事業成長にコミットするエンジニアの姿を伝えます
こんにちは、今回はデータ基盤構築を担当しているmarushoがお送りします。 今日はestieで実践しているデータベースのドキュメント管理方法をご紹介します。 はじめに 独自成長していくデータベースたち 失われたドキュメント どうすれば低コストなドキュメント管理ができるのか そして生まれた、schema collectorという自動化ツール SchemaSpy Mysql diff Priv Page ECS タスクスケジューラ ドキュメントを腐らせない おわりに はじめに estieはオフィスを中心とした不動産データを取り扱うスタートアップ企業です。 estie（オフィス探しサービス）とestie pro（不動産事業者向けデータプラットフォーム）の2つのサービスを運営しています。 詳しくは、こちらの記事をご覧ください。 inside.estie.co.jp estieでは、不動産に関する
この記事はRetty Advent Calendar 2019 21日目の記事です。エンジニアの 神@pikatenor がお送りします。11日目の記事に書かれた「弊社エンジニアの神（注・人名であり実名です）」とは私のことです。 qiita.com さて世はまさにマイクロサービス大航海時代、大規模化した組織・肥大化したコードベースのメンテナンスを継続的に行っていくべく、アプリケーションを機能別に分割する同手法が注目を集めていることは皆さんもご存知でしょう。 マイクロサービスアーキテクチャ特有の設計課題はいくつかありますが、今回は認証情報のような、サービス間でグローバルに共有されるセッション情報の管理のパターンについて調べたことをまとめてみたいと思います。 背景 HTTP は本質的にステートレスなプロトコルですが、実際の Web サービス上では複数リクエストをまたがって状態を保持するために、
Kubernetesの「ブランチデプロイ」で誰もがハッピーなDev環境を作る - HRBrain Blog
こんにちは。HRBrainでインフラエンジニアをしている間野(@mano_0307)です。 今年の5月にインフラエンジニアとして入社しました。Kubernetesを使っている弊社で、Kubernetesをまったく触ったことのない私のような人間がインフラエンジニアになれるというのが弊社の素晴らしいところです。合言葉は「トライドリブン」。日々トライができる素晴らしい環境です。 Dev環境という各社共通の悩み 多くの会社で何かと困っているのがdev環境なのではないかと思います。 dev環境今日も空いてないよ・・・フルリモートでどうせバレないし、寝ちゃお あれ？久々に使ったdev5環境がうまく動かないよ。・・・(数時間後)あー、最新のmasterがrebaseされてないからAPIのinterface変わってんじゃん！うわー寝よ・・・ そろそろdev環境増やしたいな・・・でも、あの設定も複製しなきゃ
2021/7/28, Retty ✕ Mercari Analyst Talk Night! https://mercari.connpass.com/event/218848/
Kubernetesを１年間運用してわかった３つのこと - SMARTCAMP Engineer Blog
スマートキャンプ、エンジニアの入山です。 弊社で技術的挑戦の意味も込めて始めたKubernetes（k8s）も、小規模ながら運用を開始して1年以上が経ちました！ 現在では、k8sでのインフラを採用したプロダクトが無事に本番リリースを迎え、ユーザーが本番稼働を行うまでになっており、躓きながらも少しずつ運用知見が溜まってきています。 今回は、k8sを実際に運用してわかった３つの知見を紹介したいと思います！ PodのNode配置が偏る 解決策 ローリングアップデート時にダウンタイムが発生する 解決策 Pod削除時にコンテナによってプロセスが終了するタイミングが異なる 解決策 最後に PodのNode配置が偏る k8sではPodを新規作成する場合に、kube-schedulerが各ノードのリソース使用状況等から判断した最適なNodeへスケジューリング（配置）を行います。 しかし、このスケジューリン
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita
Google Maps APIで50万以上使っていた話 - Qiita
ソフトウェア設計の Why & What & How | Wantedly Engineer Blog
rsyncの悲劇 〜本番環境を消し飛ばす前に覚えておきたいこと〜
SaaS系スタートアップのリアルなAWSアーキテクチャ設計
2020年に立ち上げたWebフロントエンド構成の振り返り
業務でどれだけSQL力がつくのか ~SQLアンチパターンを用いて確認~ 前編
障害対応で大切だと感じていることのまとめ - Qiita
RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
Firebaseの存在をフロントエンドから隠蔽するために
データベースの在庫の持ち方をビットで管理してる話 - 一休.com Developers Blog
データ収集の基本と「JapanTaxi」アプリにおける実践例
入門 GitHub Actions - メドピア開発者ブログ
秒間3万リクエストをkubernetesでさばく - Gunosy Tech Blog
テストを書きたくない話 / I don't want to write tests
インフラど素人が1ヶ月半でKubernetes本番環境を作るまでの失敗の軌跡（奇跡） - Qiita
Kubernetesの自前運用は難しい？ はてなの撤退事例
TDDはゆるく実践しても大丈夫 - 千里霧中
リモートでむしろ生産性が上がったエンジニア組織の作り方を一休 CTOの伊藤さんに聞いてみた
ニコニコで12年運用した決済システムを移行する上で必要だったこと - Qiita
git の develop ブランチは必要なのか、またはリリースtagについて
「地獄のアプリ開発」を経験した元Uberのエンジニアがその真実を語る
JavaScript で print デバッグ時に変数名を出力する - mizdra's blog
データエンジニアが事業成長をリードする。『SUUMO』のレコメンドAPIはこうして進化した - はてなニュース
データベースのドキュメント管理を自動化した話 - estie inside blog
マイクロサービス時代のセッション管理 - Retty Tech Blog
メルカリにおけるA/Bテスト標準化への取り組み