ヤマト運輸株式会社 | GitHub
1919年の創業以来、日本初となる路線事業を開始し、1976年には個人間で簡単に荷物を送ることができる「宅急便」を発売するなど、日本全国を網羅する物流ネットワークを構築し、社会的インフラとして社会課題の解決に取り組んできた。現在は、宅配便サービス国内シェア第1位（シェア：46.6%、2021年度、国土交通省調べ※）、国内宅急便ネットワークカバー率100％を誇り、宅配便の年間取扱個数は約22.5億個（2021年3月期）に達した。2020年1月に経営構造改革プラン「YAMATO NEXT100」を策定し、データ・ドリブン経営を推進している。 ※令和３年度 宅配便等取扱個数の調査及び集計方法（国土交通省） 開発環境の内製化の実現に向けAzureとGitHubを採用 開発基盤を統一し、アジャイル開発とDevOpsを促進 ・AzureとGitHubを採用し開発基盤の内製化へシフト、DevOps導入を
0から始めるNode.jsパフォーマンスチューニング
近年の Node.js は API のサーバとしてはもちろん、Nuxt.js や Next.js といった SSR や BFF などフロントエンドのためのバックエンド言語としての人気が高まっています。 フロントエンドエンジニアがコンテキストスイッチ少なくバックエンドの整備ができることは非常に大きな利点です。 ですが、フロントエンド（ブラウザ側）とバックエンド（サーバ側）ではパフォーマンスチューニングで見るべき点が大きく違います。 しかし Node.js アプリケーションのパフォーマンスイシューの見つけ方などがまとまっている資料は少ないです。 そこで、本記事ではフロントエンドエンジニアが Node.js でパフォーマンスイシューを見つけ、改善するため自分が普段パフォーマンスチューニングを依頼されているときにみている基礎的なポイトをまとめていきます。 1. 計測ステップlink Node.js
スタートアップのCTOクラスの人がたまにそういうことを言っているのを聞くことがあります。もしくは「スピード優先だからテストを書かない」等です。 それは真ではなく、言ってしまえば、未熟だからテストを書「け」ない、のではないでしょうか。ただ、スタートアップという言葉に未熟であるという意味が含まれているのであれば「スタートアップだからテストを書かない」という問は真になるかも知れません。スタートアップは得てして未熟なものだし、それでも良いからです。 テストを書かないというジャッジをするのは構いません。でもそれは、スタートアップだからでもスピード優先だからでもない。自分達が未熟だからで、そこには向き合うべきだと考えます。状況のせいにするのではなく、徹底的に自分ごと化する。それがスタートアップに求められる姿勢です。少なくとも技術のトップが自分たちの技術力に向き合わないのはまずいでしょう。 「スタートア
Masanori Kusunoki / 楠 正憲 on Twitter: "COCOAは途中まで私たち補佐官も入っていたので、決して運用保守を軽視したつもりはなかったのですが、EN API自体のプライバシー哲学に沿おうとすると既存のデバッグ用ツールがほぼ使えなくなってしまったのと、EN APIの更新がスマ… https://t.co/iQ5kltAo9k"
COCOAは途中まで私たち補佐官も入っていたので、決して運用保守を軽視したつもりはなかったのですが、EN API自体のプライバシー哲学に沿おうとすると既存のデバッグ用ツールがほぼ使えなくなってしまったのと、EN APIの更新がスマ… https://t.co/iQ5kltAo9k
数時間かかる週一リリースを毎日何度も爆速でできるようにするまで / CI/CD Conference 2021
CI/CD Conference 2021
コードレビュー虎の巻 - Qiita
レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 （作業成果物の欠陥と改善の機会を探すレビュー） 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考： あなたのおっしゃるレビューってどのことかし
みなさん、コードを書く前に設計書を書きますか？ 書くか書かないかは人それぞれだと思いますが、「設計」というプロセス自体は意識的であれ無意識的であれエンジニアであれば全員やっていることだと思います。 今回は設計プロセスの改善という文脈で私たちがDesign Docという仕組みを導入したことについて共有しようと思います。もし同じような状況を経験している人がいたら参考になれば幸いです。 導入の背景まずは導入するに至った状況からお話します。 私たちのサービスは、利用していただくユーザーの数が増加しています。それに伴って品質のハードルも上がってきました。サービスに障害が発生するとユーザーさんに大きな損害を出してしまうことになるからです。そこで今まで以上に安全にサービスを開発できる仕組みづくりが必要になりました。ですが、実現のためには大きく2つの課題がありました。 課題1. 開発スピードが徐々に鈍化し
月間10万人が読んでいるCoral Insightsのニュースレターにご登録いただくと、Coral Capitalメンバーによる国内外のスタートアップ業界の最新動向に関するブログや、特別イベントの情報等について、定期的にお送りさせていただきます。ぜひ、ご登録ください！ ウクライナのソフトウェア開発者Dmitry Zaporozhets氏が2011年10月に、たった1人で開始したオープンソースプロジェクト「GitLab」。それが、ちょうど10年を経て時価総額1兆円もうかがうほどの大成功したDevOpsのSaaSプラットフォームへと進化することになると想像した人は、ほとんどいなかったと思います。GitLabのライセンス・SaaSビジネスを展開するGitLab Inc.は9月17日付けで米国証券取引委員会（SEC）に対してFORM S-1を提出し、IPOへ向けて最終段階に入りました。 開発初期か
Steven J. Vaughan-Nichols （Special to ZDNET.com） 翻訳校正： 石橋啓一郎 2019-11-01 07:30 Linuxの生みの親であるLinus Torvalds氏は、もう講演はしていない。フランスのリヨンで開催された「Open Source Summit Europe」で同氏が行ったのは、友人であるVMwareの最高オープンソース責任者Dirk Hohndel氏との対話であり、同氏は以前もこの形式で登壇している。Torvalds氏はこの基調ディスカッションで、自分はもはやプログラマーではないと考えていることを明らかにした。 では、誰もが「プログラマーの中のプログラマー」だと考えている同氏は今、何をやっているのだろうか。Torvalds氏は次のように説明した。 もうコーディングは全然やっていない。私がコードを書くのは、ほとんどがメールの中だ。
みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 アジャイルコーチや技術顧問の仕事は多岐にわたりますが、その1つに社内での講演やセミナーがあります。 今回、技術顧問先のイベントで登壇しましたので、その際の資料を公開します。 アジャイルとは直接関係ないものも多々含まれていますが、ネタということでご了承ください。 アジャイル全般QCDSを同時にすべて固定することはできない要件の決まったものを早く・安く作る方法ではない開発だけをアジャイルにしても意味がないアジャイルで請負契約は無理だと心得ようすべてがアジャイルに適しているわけではない大規模アジャイルは小さなアジャイルの成功後アジャイル導入を支援しようアジャイル推進での組織的な課題に取り組もう無駄な社内プロセスを廃止するよう働きかけよう効率ではなく成果に着目した組織設計をし
組織にテストを書く文化を根付かせる戦略と戦術（2020秋版） / Strategy and Tactics of Building Automated Testing Culture into Organization 2020 Autumn Edition
ソフトウェアテストシンポジウム 2020 新潟 JaSST'20 Niigata 基調講演 2020年9月28日（月） http://www.jasst.jp/symposium/jasst20niigata.html
弊社では2019年3月ごろから「無人化システム」の駆逐を進めています。本記事ではこの取り組みを、組織マネジメントとエンジニアリングの側面から紹介します。 恐怖の無人化システム 「無人化システム」は社内の独自用語なので、まずは言葉の意味から説明します。 無人化とはなにか 無人化の前に属人化について触れておきましょう。weblio辞書から属人化について引用します[1]。 ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。 無人化は属人化の進化系です。無人化とは「属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること」と定義できます。誰がどう見てもダメな状態ですね。 無人化システムとはなにか システム運用が属人化し、かつその運用者が退職するとシステムが無人化します。我々の会社ではこのようなシステムを『無人化システム』と呼んでい
エンジニアとして今の自分を形成した本5冊 エンジニアとして働くにあたって自分が大きく影響を受けた本を考えてみた。もちろん他にもあるが、今回は以下の5冊に絞って紹介する。 Clean Coder（クリーンコーダー） Team Geek Clean Architecture（クリーンアーキテクチャ） テスト駆動開発 LeanとDevOpsの科学 この記事の対象者としては、独学でプログラムを書き始めた人やエンジニアスクールを卒業したばかりの方というよりは、実務経験を1~3年くらい積んでいるけど次に何を学べば良いかわからず、自分でイマイチ伸び悩んでいると感じている人を主に想定している（かつての自分がそうだった）。 特にチーム開発、オブジェクト指向言語でのコーディング、テストコードを書いた経験がある人が読んで、本に書いてあることを実践すると自分の成長を実感するだろう。 「Clean Coder」、「
ローカル環境を汚さずDockerコンテナのオーバーヘッドもなく、開発環境を自在に構築できる「Devbox 0.2.0」登場
ローカル環境を汚さずDockerコンテナのオーバーヘッドもなく、開発環境を自在に構築できる「Devbox 0.2.0」登場 Dockerコンテナの技術を用いることで、プログラミング言語のランタイムやライブラリ、ミドルウェアなどの開発環境一式を比較的容易に導入することが可能になりました。 ただしDockerコンテナにもファイルシステムのオーバーヘッドなどがあり、Dockerコンテナ内の開発環境ではコンパイルなどに時間がかかってしまう場合があったと開発ツールベンダのJetpack Technologiesは自社の経験から指摘します。 そこで同社がオープンソースで開発しているのが「Devbox」です（ちなみにマイクロソフトによる仮想化された開発環境の「Dev box」とは名前は似ていますが別のものです）。 Devboxは、ローカル環境上に分離した環境を用意しそこで開発環境を構築可能にしつつ、Do
こんにちは。はてなのアプリケーションエンジニアの id:onk です。 最近、若手エンジニアを中心に、いろいろな技術を見つめ直すワーキンググループをやっています。今回は、その中から「デプロイ」の会で発表されたことをまとめました（なお、私は会のとりまとめをやっている非若手です）。 デプロイのライフサイクルの違い Infrastructure Platformでのデプロイ Application Runtime Platformでのデプロイ Applicationsのデプロイ デプロイ方式はどのように変化してきたか In place から Blue/Green へ Immutable Infrastructure という考え方 オートスケールへの対応 push 型デプロイと pull 型デプロイ コンテナによるデプロイの現況 コントロールプレーンによって何が変わったか ECS におけるデプロイ
質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition
質とスピード（2020秋100分拡大版） 2020/11/20 @ JaSST'20 Kyushu
ローコードテスト自動化ツールの mabl がすごい
というのを使っていて思ったのでレポを書いていきます。 mabl とは - 基本的な機能 ざっくり言うと E2E テストをお手軽にメンテできるツールです。 こんな感じでポチポチ画面を操作していくと、それで実行したアクション(ボタンやリンクをクリックするなど)を自動で記録してくれて、E2E のテストを作成することが出来ます。 コードを書かずに E2E テストをサクッと作れちゃうのが魅力な訳ですが、それだけではありません。そんなすごいところを紹介していこうと思います。 mabl のここがすごい Auto Healing 何やら回復魔法みたいな感じでかっこいいですが、何かというと E2E テストがコケるようになった時に自動で修復してくれる機能です。 例えばボタンの位置が変わってしまっても、同じ文脈であろうボタンを自動で探して修復したりしてくれます。 E2E での辛さといえば、やはりテストのメンテナ
目次 はじめに 今回作成するシステムの概要 Azure OpenAI セットアップ Azure DevOps の Azure Repos をセットアップ Next.js でフロントエンド構築 Azure Static Web Apps へ Pipelines を用いて Deploy 動作確認 お片付け はじめに 昨今ちまたで話題の OpenAI。chatGPT はさらっと触ったけど、API までは触ってないなぁ…という方向けのハンズオン 🖐️ となります。 この記事の目標としては、OpenAI を触ってみたい全てのアゲアゲエンジニアがハンズオン出来ることです。 セットアップで詰まるところはどんどんコメント欄に質問していただいたら、がんがん返していきますので、ご遠慮なく質問してください！ では、Let's ハンズオン！ 今回作成するシステムの概要 今回作成するシステムは Azure 上で作
NewsPicksにCTOとして入社して1年でDX Criteriaを大幅改善した話 - Uzabase for Engineers
こんにちは。このブログでは初めまして。2020年の2月にNewsPicksに入社した高山です。 今回は僕がNewsPicksのCTOになってからの1年でやったお仕事について書いていきます。 CTO最初のミッション DX Criteriaについて 「デプロイ回数」を定点観測 やってきたチャレンジ 1年経ってみて CTO最初のミッション NewsPicksは2013年に誕生し、5年ほどの壮大な創業期の間にたくさんの新しい領域に挑戦しており、僕が入社したときには既に事業面でもシステム面でも「それなりの複雑さ」という感じでした。 前任CTOの杉浦さん（今はグループ内でアメリカでの新規サービスの立ち上げをしています）からバトンを受け取って最初のミッションが「DX Criteriaを上げること」だと聞いたときにそのあたりの事情を全て察しました。😅 結論から先に書くと、1年で大幅改善を達成することがで
はじめに 事業としてソフトウェア開発を行う企業にとって、自分たちの開発チームの生産性が十分に高いのか、あるいはそうでないのかについては大きな関心があります。 そのこと自体は、何かを計測し、改善するというのは営利企業としては健全です。一方で、ソフトウェアエンジニアリングの世界で「生産性の高さ」だと主張できる汎用性の高い指標は存在しません。こういった状況の中で、「生産性」を巡る議論は経営やビジネス部門とエンジニアチームとの間で繰り広げられ、場合によっては大きな不和や不信感につながることも珍しいことではありません。 今回は、エンジニアの開発生産性について、さまざまなステークホルダーと議論する上で把握しておきたいさまざまな論点について解説します。それによって、「我々が本当に議論すべきテーマは何か」についての共通認識をつくるための土台を構築することを目的としています。 もしかしたら改善したいことは「
SRE NEXT 2022 2022-05-15 14:15〜15:00 Track A 非ITの事業会社にSREと言わずにSREを持ち込んだ #srenext
8年続く社内勉強会を続けていくために行っていること - NTT Communications Engineers' Blog
みなさんこんにちは、社内のエンジニアが働きやすくすることを目標にする Engineer Empowerment プロジェクトの @Mahito です。 社内勉強会を始めたけれど長く続かないという話は時々、知人から聞いたり Twitter で見かけたりすることがあります。 今回は NTT Com で 2014 年から 8 年間続いている社内勉強会 TechLunch の運営を続ける際に行っていることについて書きたいと思います。 本記事は少々長めになっているため、先に内容をまとめると以下のようになります。 社内勉強会 TechLunch の紹介 社内勉強会を長く続けるためにどんなことを考えたか 続けていくために「ゆるく」したこと 発表の敷居を下げる 運営が頑張りすぎない 参加者にもゆるく楽しんでもらう TechLunch とは NTTコミュニケーションズでは、TechLunch と称して社内ラ
品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020
品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020 ソフトウェア開発のプロジェクトにおいて、リリースに間に合わせるために開発スピードを優先させ、ひとまず質には目をつぶろう、という判断がしばしば行われることがあります。 はたしてその判断は正しいのでしょうか。2020年2月13日と14日の2日間、都内で行われたイベント「Developers Summit 2020」（デブサミ2020）」の和田卓人氏のセッション「質とスピード」は、これを深く考察したものでした。 この記事では、会場に立ち見がでるほど大人気だった本セッションの内容をダイジェストで紹介します。本記事は前編と後編に分かれています。いまお読みの記事は前編です。
はじめに インストールすればすぐに書けて動かせるのが魅力のPythonですが、 実際に業務などでキチンと書こうと思ったら Pythonのバージョン管理ツール パッケージマネージャー エディター(IDE) リンター フォーマッター 型チェッカー くらいは最低限用意する必要があります。 しかしこの界隈、怒涛の勢いで日々新しいものがリリースされていて一概に「これがベストプラクティス」を提示するのが難しいんですよね。そこで今回は上記それぞれのツールについて「こんなものがあるよ」というのをご紹介したいと思います。 TLDR バージョン/パッケージ管理はpyenv + Pipenvがスタンダードだった時代は終わった VS CodeかVimを使うなら型解析にPyrightを導入するとよい テンプレートを用意しました 1. バージョン/パッケージマネージャー プロジェクトごとに異なるPythonのバージョ
こんにちは。弊社のエンゲージメントサーベイ製品HR Spannerのリードエンジニアを担当している岡部です。昨今注目されているDevOpsとそのケイパビリティについて、およそ一年前に社内の勉強会で発表を行ないました。今回の機会に、こちらでも寄稿させていただきたいと思います。 元になっている書籍は比較的大規模な開発を対象にしていると思いますが、当社のHR Spannerは10名程度の比較的小規模な開発であり、それを前提とした内容になっています。 DevOpsとは何か？ 書籍「LeanとDevOpsの科学」では大規模アンケート調査により、高収益、高利益率、高市場占有率を持つ企業は、単に起業家精神やM&Aの取り組みだけでなく、開発組織におけるDevOpsのケイパビリティを強化している傾向が浮かび上がっています。この結果は単なる相関関係ではなく、統計手法によって因果関係として確認されています。また
IPA から アジャイル開発版「情報システム・モデル取引・契約書」が公開された。 【プレス発表】 DX推進に向け、アジャイル開発版の「情報システム・モデル取引・契約書」を公開 https://www.ipa.go.jp/about/press/20200331.html 【成果物公開ページ】 https://www.ipa.go.jp/ikc/reports/20200331_1.html 私はこの1年間、IPA の「社会実装推進委員会 モデル取引・契約書見直し検討部会 DX対応モデル契約見直し検討WG」の委員としてこのモデル契約書の策定に関わってきた。 モデル契約策定にあたって、私が特に実現できてよかったと思うことを書いていきたい。 準委任契約を前提とすることができた2012年にIPAから出された「非ウォーターフォール型開発に適したモデル契約書」（当時、IPAではアジャイルと言わずに非ウ
プリウス開発に見るアジャイル開発要素と今時の進め方：続編 / The Agile Development Elements and Current Approach as Seen in Prius Development: Sequel
弊社の伝説の開発のひとつ、スクラムの源流でもある、初代プリウスについて、当時の開発者たちが語る熱く、時には洩れる本音のトークを紹介します。また日本を代表するアジャイルコーチの皆さんと、温故知新の心構えでこれらを分析しました。開発者たちのトークに、いくつかの共通ワードが存在し、それがスクラムの源流と繋がっている所まで整理できたので解説します。更に、変化の時代、環境変化に対し、ハードウェア開発をどう進めるべきか？ いまどきの取り組みを現場の開発者たちの声と共にお届けいたします。本内容は、スクフェス三河「初代プリウスにみるアジャイル開発の要素と現代の環境での進め方について」の続編という位置付けになります。 / We will introduce passionate and occasionally candid discussions by the developers of our lege
フロントエンドのデベロッパー、バックエンドのデベロッパー、開発・運用に必要なスキルや知識、ツールやテクノロジーをステップバイステップのフローにまとめたロードマップを紹介します。 2021年、フロントエンドやバックエンドのデベロッパーが次に何を学べばよいか、キャリアアップのための道筋がコンパクトにまとめられています。 Developer Roadmaps Developer Roadmaps -GitHub フロントエンド デベロッパーのためのロードマップ バックエンド デベロッパーのためのロードマップ 開発・運用のためのロードマップ フロントエンド デベロッパーのためのロードマップ 2021年版、フロントエンド デベロッパーになるためのステップバイステップガイドです。PDFもダウンロードできます。 Frontend Roadmap.pdf フロントエンド デベロッパーのためのロードマップ
AWS Startup ブログ スタートアップのためのマイクロサービス入門 こんにちは、スタートアップ ソリューションアーキテクトの松田 (@mats16k) です。 以前「スタートアップのためのコンテナ入門 – Kubernetes 編」を出した際に記事内で、マイクロサービスやサービスメッシュにふれる機会がありました。今回は AWS でデベロッパーアドボケイトをしているトリ氏 (@toricls) にマイクロサービスについて記事を寄稿いただきました。 ※ 本記事は Software Design 2020年7月号 に掲載された「スタートアップのためのAWSテクノロジー講座 – マイクロサービスのあるべき姿と特徴を知る」からの転載、改修版です。 目次 マイクロサービスにはコンテナが必要なのか？ サービスメッシュは本当に必要なのか？ 「マイクロサービス」という言葉の功罪 マイクロサービスが必
こんにちは。たかやまです。 みなさんアーキテクチャを検討するときに、なにか参考にするアーキテクチャがあると助かりますよね？ 私もアーキテクチャ検討をするときは、車輪の再発明を避けるためゼロベースではなく先人たちのアーキテクチャを参考にさせていただくことが多いです。 そのおり、ちょうどお客様にアーキテクチャ検討に役立つサイトをご紹介する機会があり、参考にしているサイトを改めて調べると結構あったので今回こちらをブログにまとめてみたいと思います。 30 の目的別 クラウド構成と料金試算例 目的別クラウド構成と料金試算例 日本利用者向けに公開されているリファレンスアーキテクチャのサイトになります。 全ドキュメント日本語で料金試算も載っているため、アーキテクチャの検討はじめにおすすめのサイトです。 サーバレスパターン サーバーレスパターン サーバレスの汎用的なユースケースがまとめられたサイトになりま
米Microsoftが4月14日にリリースしたWindows 10の累積更新プログラム「KB4549951」に関して相次いで不具合の発生が報告されています。KB4549951は、Microsoft Officeのセキュリティ改善、Windowsのセキュリティ強化、またファイルの保存と管理に関する更新を目的としたアップデートですが、一部では、プログラムをインストールした後に、ファイルが勝手に削除されるなどといった重大な問題が発生しています。 報告された不具合の中には、KB4549951をインストール後、「Blue Screen of Death（BSOD、死のブルースクリーン）」と呼ばれるシステムの突然停止になったというケースも含まれています。他にも、Bluetoothに接続できない、Wi-Fiに接続できない、システムのパフォーマンス低下などの問題が発生しているとの報告があります。 これまで
アプリケーション開発者は Amazon ECS あるいは Kubernetes をどこまで知るべきか #AWSDevDay / You build it, you run it
Talked at AWS Dev Day Online Japan 2021. - 動画: https://youtu.be/I7mMQshlpcs - イベントページ: https://aws.amazon.com/jp/about-aws/events/2021/devday - Proposal: https://github.com/aws-events/aws-dev-day-online-japan-2021-cfp/issues/16
Github Actions チートシート
概要 何度も調べて何度もテストしたりしたので、多用するものをまとめていきたい。 項目 push時に実行 // feature/aaaで動く。 feature/aaa/bbbでは動かない on: push: branches: - feature/* // feature/aaa, feature/aaa/bbbで動く on: push: branches: - feature/** // なにかしらのtagがpushされたときに実行、branchのpushは無視 on: push: tags: [ '**' ] branches-ignore: [ '**' ] // 指定したpathの変更だけでは実行しない on: push: branches: - main paths-ignore: - '*.md' - 'docs/**' on: workflow_dispatch: inputs
こんにちは、SWETでCI/CDチームの前田（ @mad_p ）です。 SWETではCI/CDチームの一員として、Jenkins運用のサポートや、CI/CD回りのノウハウ蓄積・研究をしています。 はじめに Gitリポジトリをクローンすると、ローカルフォルダにはそのリポジトリの全体がダウンロードされ .git というフォルダに格納されます。ブランチをチェックアウトすると、ブランチ内のファイルがワーキングツリーとして展開されます。この様子を図にするとこのようになります。 この .git とワーキングツリーの使うディスク容量を節約しようというのが今回のお話です。特にJenkinsにおいて、大きめのGitリポジトリをクローンしてくる場合に課題があり、いろいろ工夫してみたので、その結果を紹介します。同じCI/CDチームの加瀬による記事「大規模リポジトリで高速にgit cloneするテクニック」と内容
6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない？となった話 - データエンジニアの酩酊日記
ここ半年ぐらい、かなり久々にクラウド使ってアプリやバッチの基盤作ったりしてきて、色々と思ったことを書き捨てる。 「ちょっと検証してみた」程度のものも含めれば、AWSとGCPは一通り主要なマネージドサービスを触ったし、実際に複数のアプリやらバッチやらをマネージドサービス上で本番稼働させて今も運用してるけど、結局DB以外は基本全部Kubernetesに乗せるのが一番楽だと強く思うようになった。 Kubernetesは学習コストや運用コストがそれなりに高く付くから安易に採用するのはどうなのか、みたいな論調もあるし、つい半年前までは自分もそう思ってた。サーバレスなマネージドサービスが色々出てきているのに、なんでわざわざKubernetesクラスタなんていう設計、運用に手間のかかるクラスタリングサーバーを立てて管理しないとならんのかと。 だけど、実際にいくつかのマネージドサービス使ってアプリやバッチ
弊社は未だにメインフレームの相手をしてCOBOLを書いているような、低技術力・プロマネ力偏重のSIer。 20代の若手SE(笑)である僕自身もウォーターフォールの経験しかなく、社内の99%も同じ。 最近興味があって近くにいる人とアジャイル開発の勉強をしていており、ジェフ・サザーランドの著書ほか何冊か本を読んだ、というだけのただのエンジニアワナビー。 最近近所で絵に描いたようなアジャイル失敗例があって、ちょっと誰かに聞いてほしくて書いてる。 この度、既存システムを刷新するプロジェクト（たぶん１億以上５億未満）をアジャイル開発でやることになり、先月くらいに最初のスプリントがスタートした。 アジャイル導入にはおそらく特に動機がなく、お客さんの偉い人たちが ・最近アジャイル？流行ってるんでしょ ・無限に要件変更できるんでしょ ・アジャイルにすると早く安くできるんでしょ などと仰せになった結果だと聞
【新機能】Google Cloud 純正の構成図ツール Architecture Diagramming Tool が発表されました | DevelopersIO
【新機能】Google Cloud 純正の構成図ツール Architecture Diagramming Tool が発表されました Google Cloud のアーキテクチャ図を書く純正のツール Architecture Diagramming Tool が発表されました。Google Cloud の構成図ツールの決定版になると思います。 ウィスキー、シガー、パイプをこよなく愛する大栗です。 先程 Google Cloud 純正のアーキテクチャ図作成ツールである Google Cloud Architecture Diagramming Tool が発表されました。 Introducing a Google Cloud architecture diagramming tool Google Cloud Architecture Diagramming Tool 今まではGoogle S
30分でわかるシステム運用アンチパターン / Operations Anti Patterns in 30 minutes
「システム運用アンチパターン - Forkwell Library #4」でお話しした際の資料となります。 https://forkwell.connpass.com/event/256481/ 動画はこちら。 https://youtu.be/hQAeMgXsZWc
2020/07/14 Cybozu Tech Meetup #3
AWS Lambda を使用した Web アプリケーションの開発プロジェクトで、バックエンド・フロントエンド・インフラを一貫して開発をしてきました。 改めてどのように開発をしていたのか、使った技術スタックや各サービスをどのように活用したかを整理したいと思い記事にしました。今後サーバーレス開発を行う際の技術選定の参考にしていただければ幸いです。 前提 Web アプリケーションです。 管理画面用の内部 Web API、外部のサービスと連携するための外部 Web API があります。 処理としてはリソースの CRUD がメインです。 管理画面は SPA で、バックエンドの Web API にリクエストします。 開発メンバーは 4 人ほどで、フロントエンドエンジニア、バックエンドエンジニアといった区分けはしていませんでした。 機能ごとにメンバー全員がバックエンドからフロントエンドまでを一気通貫で実
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「スタートアップだからテストを書かない」は正しいか - An Epicurean
安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド｜面川泰明
ウクライナ発個人プロジェクトGitLabが1兆円規模のIPOへ、その4つの教訓 | Coral Capital
"Linuxの生みの親"トーバルズ氏：「私はもうプログラマーではない」
【資料公開】アジャイルについてマネージャーが知るべき97のこと
「無人化システム」を駆逐する組織マネジメントとエンジニアリング
エンジニアとして今の自分を形成した本を5冊紹介する - パンダのプログラミングブログ
デプロイ今昔 - Hatena Developer Blog
まだOpenAI使ったことないの？この記事で全員ハンズオンさせてやんよ！
開発生産性について議論する前に知っておきたいこと - Qiita
非ITの事業会社にSREと言わずにSREを持ち込んだ
2020年5月におけるPython開発環境の選択肢 - Qiita
組織をハイパフォーマーにするスキル、DevOps - techtekt
IPA の アジャイル開発版「情報システム・モデル取引・契約書」｜木下史彦
2021年版、フロントエンドとバックエンドのデベロッパーに必要なスキルやツールをまとめたロードマップ
スタートアップのためのマイクロサービス入門 | Amazon Web Services
AWSアーキテクチャのサンプルをまとめてみた | DevelopersIO
Windows 10 更新プログラムで不具合が多発：アンインストールを推奨
大きなGitリポジトリをクローンするときの工夫を図解します - DeNA Testing Blog
旧来型SIerである弊社でアジャイル（スクラム）が上手く行っていない
インフラ自動化の落とし穴と宣言的アーキテクチャ
最近の業務での AWS サーバーレス開発を振り返ってみた | DevelopersIO