インフラエンジニアBooks 30分でわかる「Dockerコンテナ開発・環境構築の基本」登壇資料です。
![インフラエンジニアBooks 30分でわかる「Dockerコンテナ開発・環境構築の基本」](https://cdn-ak-scissors.b.st-hatena.com/image/square/1a79d3d461a3a130a459dac73490204aa0d79bde/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fec130c52de4645dcb912c7f76875ee5e%2Fslide_0.jpg%3F21392937)
こんにちは、freee会計でワークフロー機能の開発をしている @mitubaEX です。 先日 freee会計のパフォーマンスチューニングに取り組みました。本記事では、調査の流れ、改善の事例を紹介します。 問題発覚までの流れ freee では自社の経理業務に freee会計を利用しており、その中でも経費精算の機能はほぼすべての従業員が利用しています。そのため日々多くのフィードバックをもらえます。そのフィードバックの1つで、「経費精算の一覧を開くのが遅い」という報告をもらいました。幸い表示件数を指定できるので調整すれば遅くはならないのですが、一覧性が下がってしまうため有用な解決策ではありません。 そこでワークフローを開発しているチームで、このパフォーマンスイシューの調査を始めました。 調査する まず事前調査として Datadog*1 で一覧画面を表示するリクエストの処理を確認しました。 一覧
自分はこれまでの仕事で、バグ修正や機能追加でPullRequestを送るときに、考慮の抜けもれやケアレスミスが非常に少ない方であると思っている。振り返ってみて、これは自分に課している習慣が大いに効いていると思っているので、メモしておく。 毎回のcommit時 必要な部分だけをgit addし、git diff --cachedによって差分をセルフコードレビューした上でcommitする PullRequest作成時 filesの内容をセルフコードレビューし、直した方が良い部分は直す + わかりにくい部分にGitHub上でラインコメントを行う + コード上にコメントを残した方がいいならコメントする ユーザーの導線に影響するコードなら、必ず自動テストだけでなく、自分自身でユーザーの行動をトレースし、違和感がある部分が存在しないかチェックする。チェックした流れについては、PullRequest上に
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1~2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文: www.industrialempathy.com 関連書籍: Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安:11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
エンジニア版ベストキッド 師匠 「ログを出す!ログを読む!」「syslogに出す! loggerで出す!」「ログレベルアップ!ダウン!アップ!ダウン!」 生徒 「クラウドネイティブなマイクロサービスの作り方を教えてくれる約束だ!」 プロダクション環境にて… 生徒「ログが…有る!これだ!」— magnoliak🍧 (@magnolia_k_) 2022年4月10日 ふとベストキッドの台詞を思い出して、雑に書いてみたけど、案外いいこと書いてるなーって自分でも思ってしまった。 loggerの使い方は入門書に載ってたり載ってなかったりするし、どんなタイミングでどんな情報をどこに出すべきか?みたいな話は一子相伝の秘伝の技みたいになりがちだし。 まさにそう思います。https://t.co/ZKTTtdwB1d— Hideo Fukumori (@hideo_fukumori) 2022年4月11日
こんにちは!CTO統括室の黒崎(@kur_m88)です。2022年度のサイバーエージェントには新卒のエンジニアが約90名入社してくれました。 アフターコロナー1期生の新入社員へ、代表藤田からのメッセージ 2014年までエンジニアブログを遡ると、こんな企画がありました。この企画を8年ぶりに復活させてみようと思います。 #e100q 新人エンジニアにお勧めする一冊 思いつきで企画してみたので100人に聞く時間はありませんでしたが、約40名から返事をもらえました。 社内でアンケートを募集した様子 おすすめする一冊の被りが多ければランキング形式にしようと思っていたのですが、あまり被りがありませんでした。 ちょっと分量が多いですがせっかくなので全部紹介しようと思います。 先輩エンジニア達から新人エンジニアに向けた言葉ももらったので、最後に載せてあります。ぜひ最後までご覧ください! 新人エンジニアにお
突然ですが世の中には2種類のエンジニアがいます。 開発環境をずっと立ち上げっぱなしにするエンジニアと毎回落とすエンジニアです。 自分を含む毎回落とすエンジニアにとって、開発環境を立ち上げる度に複数のターミナルを開き、それぞれでコマンドをたくさん打たないといけないのは苦痛です🥺 そこでこの記事ではVSCodeでプロジェクトを開いたときに開発環境を自動で立ち上げる方法をご紹介します! おまけで紹介するAlfredまで設定するとコマンド一発で開発環境が立ち上がるようになり、こんな感じになります! ではいってみましょう! 対象読者 開発環境を毎回落とすエンジニア VSCodeを使っている 開発環境を立ち上げるためのコマンドがたくさんあって毎回打つのがめんどくさい 環境 VSCode: 1.66.0 macOS Monterey Hello Custom Task! VSCodeでプロジェクトを開
キャッシュは、CPUのバスやネットワークなど様々な情報伝達経路において、ある領域から他の領域へ情報を転送する際、その転送遅延を極力隠蔽し転送効率を向上するために考案された記憶階層の実現手段である。(引用: フリー百科事典『ウィキペディア(Wikipedia)』) こんにちは、@kaa_a_zu です。私たちエンジニアは、「キャッシュ」というワードをよく口にしています。それはインフラの設計をしている時かもしれないし、表示されるコンテンツが変わらない時かもしれないし、パフォーマンスの改善をしている時かもしれません。普段何気なく使っている「キャッシュ」とは一体何なのでしょうか。この記事は、そんな「(Webフロントエンドを触るエンジニアが知るべき)キャッシュ」について、どんなものがあるのかがちょっと分かったという状態になることを目的に書いています。
はじめまして。Shougo(@ShougoMatsu) という者です。私は現在、日中ソフトウェアエンジニアとして働く傍ら、GitHub Sponsorsで支援を頂いてテキストエディタ(Vim、neovim)本体を改善する活動やテキストエディタプラグイン開発を行っています。 今回「自分自身のキャリアを振り返り、スキルを向上させるために取り組んできたこと」について解説してほしいという依頼がありました。自分がプラグイン開発を始めてから、もう15年という長い月日が経っていて、世間ではテキストエディタの大ベテランと思われているようです。もうそこまで来てしまったのかと思うと同時に、時間さえかければ誰でもここに到達できると私は考えています。 私をはじめ誰しも最初は初心者です。右も左も分からない状態から始まるのです。私の経験が「自分はこれからどうすればよいのか分からない」「何か強みを持ちたい」と思っている
こんにちは、freee会計のプロダクトマネージャー(以下PM)をしております、gokiです。 皆さん、「ドメイン知識」という言葉、聞いたことありますか? ドメイン知識(英: Domain knowledge)または領域知識は、はっきり限定された、ある専門分野に特化した分野の知識であり、一般知識またはドメイン独立の知識と対比される。 ドメイン知識 - Wikipedia freee会計での開発現場で例示すると「確定申告のプロダクトを作るには、開発技術だけでなくそもそも確定申告業務の理解というドメイン知識が必要だよね」みたいな使われ方をします。 freeeはスモールビジネスの皆さんのバックオフィス業務を改善するプロダクトを作っているので、このドメイン知識が開発においても必要な場面が多いです。 そこで、今回はドメイン知識が必要な開発をどのように進めるか、というコツをPM目線でご紹介しようと思いま
エンジニア不足、エンジニア不足と言われて久しいですが、日本でのプログラミングスクールの先駆けとも言えるTECH::CAMPさんのサービス開始が2014年なので、今や8年が過ぎようとしているわけです。 ともすると、市場に既にベテラン級のエンジニアがわんさかいてもおかしくないんですが、今でも「エンジニア採用できない」という声が絶えることないように見えます。はて?どうしたことだろうか、と思ったので今市場でどんなエンジニアが求められているのかを考えてみました。 高い技術力よりも「いい感じ」力を求めている エンジニアというと、技術を駆使して問題解決をするスペシャリストというイメージがあり、技術力が高い=優秀という認識を持つのが自然です。実際、技術力が低くてまともにプロダクト開発出来ないようでは論外だし、技術的な難問の攻略が命運を分けるケースはあるにはあります。 しかし、実際には開発プロジェクトの失敗
超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話(1) Regional Scrum Gathering Tokyo 2022 代表的なアジャイル開発手法であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2022」が、1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されました。 そのクロージングセッションとして行われたのが、現在シアトル在住でMicrosoft Azureの開発を担当している牛尾剛氏による「アメリカの超巨大クラウドの中の人に転生したガチ三流プログラマが米国システム開発の現実をリークする話」です。 本記事ではほぼ90分におよぶセッションの内容を、前編、後編(1)、後編(2)の3本に分けて紹介します(この記事は後編(1)です)。 前編では、子供の頃からプロ
三流プログラマがなぜ米マイクロソフトの開発者になれたのか? ガチ三流プログラマが超巨大クラウドの中の人に転生した話。Regional Scrum Gathering Tokyo 2022 代表的なアジャイル開発手法であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2022」が、1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されました。 そのクロージングセッションとして行われたのが、現在シアトル在住でMicrosoft Azureの開発を担当している牛尾剛氏による「アメリカの超巨大クラウドの中の人に転生したガチ三流プログラマが米国システム開発の現実をリークする話」です。 子供の頃からプログラマになることを目指しながらも、同僚からは「プログラミングの才能がない」とはっきり言われるなど、自分はガチの三流プログラマだと称する
この記事は 個人開発 Advent Calendar 2021 の18日目の記事です。 「もうスマホアプリ市場はレッドオーシャン」とか、「個人アプリは埋もれてしまって全然ダウンロードされない」とかいう話をちらほら聞きます。 実際、過去に個人でアプリをリリースしたけれど、ヒットしなくて辞めてしまった、という人もいるのではないでしょうか。 では、もし… ヒット作が出ないまま10年間個人アプリ開発を続けたら、どうなってしまうのか という話をします。 作ったものまずは、これまで作ったアプリやダウンロード数などのデータをまとめます。 これまでにリリースしたアプリは、 iOS(ツール系):39本 Android(ツール系):1本 ゲーム:29本 で、計68本です。 (Androidアプリは、iOSアプリのAndroid版なので合計にはノーカウント) ツール系アプリは、「写真/ビデオ」カテゴリが多いです
はじめに こんにちは、ゆずたそ(@yuzutas0)です。この連載では、ソフトウェア開発者からプロダクトマネージャーに転向した筆者が、多くの失敗を経て重要性を痛感した「プロダクトマネージャーのマインドセット」を解説します。 主な対象読者としては、同じようにソフトウェア開発を出自とした方で、「同じような失敗経験のある方」「これから失敗を経験するであろう方」を想定しています。連載の前提条件の詳細、免責事項などについては、第1回の冒頭を併せて参照ください。 トレードオフが生じる場面 今回は意思決定について扱います。たとえステークホルダーの協力を引き出し、どれだけ試行錯誤しても、どこかでトレードオフが生じることになります。関係者全員が問題と向き合い、議論を整理した上で、それでも一つの結論にならないという場面が訪れます。そこではプロダクトマネージャーとして意思決定を求められます。 画面に表示するテキ
これはなにか エンジニア、ビジネスサイドの方に向けた、「良い要件定義の作り方」について書いた記事です。 長文がつらつらと書いてある本稿ですが、要するに言いたいことは、 ● 完璧な要件定義など幻想であり、誰がどう作っても不完全である ● そのため、一番危険なのは、とびきり賢い人が出してきた要件定義で、 「あの人が作ったんだから大丈夫」と盲目的に考えること ● 完璧にはならないことを受け入れ、ベストを尽くす姿勢が大事 ●そもそも、アジャイル開発において、完璧な要件定義は求められていない ●良い要件定義には以下のスタンスが必要 ● UXから逆算する ● 削ぎ落とす ● 個ではなく、チームで作る ● レビューを徹底する ● 3つのシナリオを想定する ということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれ
Netflixがシステム運用に取り入れている、カオスエンジニアリング(chaos engineering)という手法があります。例えば機能を冗長化したシステムでも、いざ障害が起きたときに別系統が想定どおり機能するか分からない。そこで実際に動いているシステムで意図的に障害を起こし、挙動を確認してシステムの改善につなげる考え方です。 株式会社ユーザベースでは、アンチフラジャイル(antifragile、反脆弱)なシステムを目指してカオスエンジニアリングを導入しています。システムだけでなく、エンジニア組織においてもカオスエンジニアリングを応用した改善プロセスに着手しています。キーパーソンがいなくなってもプロジェクトはうまく動き続けるか、実際に外れてもらって確認するのです。 このチャレンジングな取り組みについて、CTOの林尚之さんと、システムでも組織でもカオスエンジニアリングを体験したエンジニアの
この度転職活動を行って無事内定をいただいたので、記念に面接の中でいただいた質問をまとめてみました。 某大手金融のフィンテックエンジニアに転職します!! 転職活動当初は、レガシー、ジョブホッパー、経験少でダメ出しの嵐🍃 でも諦めずNuxt+Firebaseでのサービス開発、マイクロサービス化ポートフォリオ、CTFの取組、GitHub毎日コントリビュート、個人活動も頑張って内定頂けて本当よかった😁 — bindingpry (@bindingpry) November 19, 2021 基本的に技術面接では、履歴書や実務経験の技術、ポートフォリオで扱っている技術、自分で口にした技術を深ぼられることが多かったです。 そこはしっかり技術を扱えるだけでなく説明できるようにすることも必要だと思いました。(自分は最初ボロボロでしたが笑) また正社員の面接では技術と同等に、仕事への姿勢、性格、事業への
Advent Calendar day 7 担当の vvakame です。 予告では Apollo Federation Gateway Node.js実装についてポイント解説 としていましたが、社内各所のご協力によりAdvent Calendarの私の担当日に間に合う形で公開できる運びとなりました。そのため告知とは異なりますが GitHub上のsensitive data削除の手順と道のり をお届けしていきたいと思います。 メルペイVPoE hidekによるday 1の記事で振り返りがあったように、今年、弊社ではCodecovのBash Uploaderに係る情報流出という事案が発生しました。当該インシデント対応において、プレスリリースにも記載のある通り、ソースコード上に混入してしまった認証情報や一部個人情報などの機密性の高い情報(sensitive data)について調査を実施し、対応
はじめに お久しぶりです、皆様のサンドバックが帰ってまいりました。 投稿ができていない期間、Nuxtにボコボコにされて裸足で逃げ出し、逃げた先のReactにも強烈な左カウンターをお見舞いされました。 本来であれば、このような場所に投稿することすらはばかられる内容ですが、敢えて書きましょう。 私はフロント開発を炎上させた愚か者です。 なぜ今懺悔するのか Twitterでこんな投稿を見ました。 確かに、実務で得られる経験は、とても大きく得難いものです。 当然、ご迷惑をおかけしてしまうことは、だれであろうとあるでしょう。 ただし、その「ご迷惑」の大きさについて、我々は知っておかなくてはなりません。 見えている地雷を踏んでしまうようなモノ好きもいないでしょう。 特に、この手の地雷は強力ですからね。 塵となって吹き飛んだ私の命が、新たな浅瀬の民の糧となることを祈っています。 具体的に何が起こったのか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く