はじめに こんにちは。サーバーサイドエンジニアの mokuo です。 最近、ミニマムな React アプリを実装する機会がありました。 社内のメンバーにアドバイスをもらいながら、今（2024年前半） React アプリをミニマムに作るならこんな感じかな、という構成になった気がするので、ご紹介したいと思います。 実例の1つとして参考にしていただけますと、幸いです。 はじめに 本文 📝 機能要件 ⚒️ 採用したツール (npm モジュール) 📁 ディレクトリ構成 👨💻 プロトタイピングの実施 🍩 おまけ コンポーネント設計について フロントエンドに DDD のエッセンスを取り入れてみたい おわりに 本文 📝 機能要件 社内の限られた CS メンバーのみが利用する、管理画面を開発しました。 バックエンドは Golang で実装される API サーバーで、認証機能以外だと、2つの機能
リリースした新機能がビジネス指標に何の影響も与えていない。ユーザーからの評判も芳しくない。いや、そもそも反応すらない無風状態。我々が費やした努力と時間はなんだったのか。 このような失敗は、ソフトウェアプロダクト開発に携わっていると何度でも経験します。むしろ、期待通りの成果を得られることの方が少ないでしょう。 失敗から得られる知見もありますが、それと引き換えに費やしたコストと時間は戻せません。それが繰り返されると、組織全体の士気が落ち、学習性無力感に支配されていきます。ソフトウェアプロダクトは、そのマネジメントにおいて、常にこれらのリスクを抱えています。 本記事では、機能リリースに伴うこのようなリスクを制御する方法について考えます。 期待する成果が得られないことを前提に計画する機能リリースが期待どおりのインパクトをビジネスにもたらすかどうか。それを事前に予測し、世の中に送り出すべきアイデアを
※この投稿は米国時間 2021 年 2 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。 サイト信頼性エンジニアリング（または DevOps）を実装すると、魔法のようにすべてが改善されると思う人もいるでしょう。組織に SRE のおまじないをかけるだけで、サービスの信頼性と収益性が向上し、IT やプロダクト、エンジニアリングの各チームの誰もが満足すると。 このような勘違いが起こる理由は明らかです。世界屈指の信頼性と拡張性を誇るサービスのいくつかは、SRE チームの支援を得て稼働しているからです。Google がその代表的な例です。 私は、大規模な本番環境システムの稼働に明け暮れる生活を 20 年近く続けてきました。トレードオフ、信頼性、コスト、制約や要件が異なる多様なアーキテクチャの実装といったことで頭を悩ませ、深夜に呼び出されることもよくありました。最近では
【Terraform🧑🚀】tfstateファイルの分割パターンとディレクトリー構成への適用 - 好きな技術を布教したい 😗
この記事から得られる知識 この記事を読むと、以下を "完全に理解" できます✌️ Terraformのtfstateファイルを分割する目的と、オススメの分割パターンについて (★) Terraformのリポジトリやリモートバックエンドのディレクトリ構成の設計について 記事のざっくりした内容は、以下のスライドからキャッチアップできちゃいます！ この記事から得られる知識 01. はじめに 02. なぜ tfstate ファイルを分割するのか 分割していない場合 分割している場合 分割しなくていい場合 03. tfstate ファイルの分割 分割の境界 状態の依存関係図 依存関係図とは 依存関係の表現 ▼ 依存関係の表現記法 ▼ 依存関係がない場合 ▼ 依存関係がある場合 04. tfstate ファイルに基づくその他の設計 リポジトリ 🐱 の設計 リポジトリ分割 ディレクトリ 📂 構成 リ
こちらの反響もよかったこともあり、KubernetesにおけるCI/CD（継続的インテグレーションと継続的デリバリー）に焦点を絞って、いままでの経験も含めて大事なポイントをいくつかの切り口でまとめることにしました。 一部は書籍の内容とかぶる部分もあるのですが、わたしが普段Kubernetesでのアプリケーション運用に携わる中で大事だと思うことなど含めてご紹介します。 KubernetesにおけるCI/CDとしていますが、項目は必ずしもKubernetesに限った話ではありませんのでご了承ください。 また、もっといろんなトピックを書きたいのですが、すべてのトピックを揃えると記事自体のボリュームも大きくなり公開も遅くなりそうだったので、基本的な内容のみ選んでみました。随時追加されていく（あるいは別記事？）可能性があります。 ブランチ戦略 CI/CDの実践にまず根本的に関わるポイントとして、ブラ
ソフトウェア開発の指標でFour Keysも計測できるFindy Team+の開発チームは何から改善を始めたか - Agile Journey
ソフトウェア開発チームのパフォーマンスを測る指標、それがFour Keysです。「Four Keysはすぐに上がる数字ではなく、地道で本質的な取り組みをしながら、数値を見ることで自分たちはうまくやれていることを確認するもの」と語るのは、Findyのプロダクト開発部でエンジニアリングマネージャーを務める栁沢正二郎さん。 栁沢さんが開発に携わっているFindy Team+は、エンジニア組織がパフォーマンス改善に利用できるSaaSです。GitHubのリポジトリやJiraのイシュートラッキングなどを解析して、エンジニアやチームのパフォーマンスを数値化できます。2022年8月には、Four Keysについても可視化・分析できる「DevOps分析」機能をリリースしました。 注目したい点は、Findy Team+の開発組織自身がFindy Team+をドッグフーディングしていること。つまり、Four K
最短で高給を実現するには？スポーツからプログラミングに大きく軸足を変えシリコンバレーで働くエンジニアにその半生と学習法を聞いてみた
2030年には最大約79万人が不足する可能性があり、IT人材の不足はまだまだ続く見込みだということが(PDF)経済産業省の調査でわかってきています。そこで、今からでもITスキルを身につけてエンジニアに転職したい＆給料を上げたい……と考える人に向けて、あまり知られていない「エンジニアとして成功するために本当に大切なことは何か」を、文系からエンジニアになってシリコンバレーの企業で働くエキスパートエンジニアであり、かつオンライン動画学習プラットフォーム「Udemy」の講師でもある酒井潤さんに聞いてみました。 オンラインコース -世界最大級のオンライン学習プラットフォーム- Udemy https://www.udemy.com/ 目次 ◆1：文系から年収5000万円のエンジニアになるまでにたどった道のりとは？ ◆2：大切なのは「どの技術を学べばよいのか」という選び方 ◆3：デキるエンジニアの仕事
DevOpsやCIOps、GitOpsなどを通じて生産性向上を突き詰めていくと、コンパイルやテストだけではなくリリースまで自動したくなってきます。リリースには必要な作業が多く、また頻度も高くないため毎回思い出したり間違えたりが発生するためです。 特に変更内容をまとめて文書化する作業は、利用者に対する影響度もその煩雑さも高いため、自動化できれば文書の品質向上やリリース頻度の向上に大きく貢献できます。本記事では、筆者がNode/Java界隈でよく見るリリース自動化手法について紹介することで、リリース自動化の敷居を下げたいと思います。 なお本記事で言う「リリース」は、jarファイルやコンテナイメージなどビルドの成果物をリポジトリやGitHub Releasesにアップロードして他プロジェクトやデプロイ環境で利用できるようにすることを指しています。環境に対する「デプロイ」や、エンドユーザへの公開を
いきなり1,000行越えの差分のあるPRのレビューを依頼するのは今すぐやめろ。何年前の開発スタイルだよ 今回語りたいこと PR/リリース単位の違いの変化を時代と共に語るというのが主旨です この記事を書いた意図 最近開発速度を上げたい的なお話が多く、その際に何回も同じ話を説明することになっているので改めてここに書いておこうと思います。 もう少し膨らまして講義としてまとめた上で、オンボーディング研修の受講動画にしたいですね。 変化をざっくり言うと リリースされる単位は時代が下るごとに細かいサイズでリリースする方向に変化しています。 近年だと平均差分の中央値は（差分行数で比較した場合で）一桁台とかありますね。 古代、いにしえの時代 少数の大企業だけが使える「基幹系業務システム」というピラミッドみたいな代物を、SEという大工のような人たちを多数抱えたごく少数の「大規模SIer」という集団だけが造れ
Developers.IO 2019 TOKYOで登壇した際の資料です。 https://dev.classmethod.jp/event/report-developers-io-2019-tokyo-serverless-ci-cd-devops/Read less
【資料公開】価値をすばやく届けるための改善
みなさんこんにちは。@ryuzeeです。 2023年3月3日に開催のイベント「エンジニア文化祭 2023」の登壇資料を公開します。 改善というとすぐにプロセスの変更やツールの導入みたいな話になりがちですが、それだとまずいことが多いです。 ということで、本セッションでは、プロダクトで持続的に価値をすばやく届けるために改善をするときに、どんな切り口でどんなことを考えるとよいかをまとめました。 40分という短いセッションなので、細かいことまでは書ききれていませんが、考え方のヒントになれば幸いです。 忙しい方向けのまとめ アウトカムに注目して改善する プロセス改善だけでは無意味 複数の領域で改善していく（以下はあくまでも例） 問題設定力 たくさん作ることを目的にしない、課題にフォーカス、仮説検証、計測、捨てる…… 開発力 技術に向き合う、練習、継続的なテスト、問題の兆候に継続的に対処、機能横断……
他の方の記事ですが、読んでいておもしろかったです。記事に出ている本はClean ArchitectureとTDD、LeanとDevOpsの科学くらいしか読んだことなかったです。 また自分も書くことで、他の方も記事を書くようになり、ついでに他の方の記事を読んでみるなどしたいなと思ったので書いてみます。 私はソフトウェアエンジニアとしてのキャリアはまだ7年くらい[1]なので短い方ですが、約7年間の中で読んで印象に残ったものを紹介します。 計算機プログラムの構造と解釈 Scala関数型デザイン&プログラミング Effective Java Programming Rust 実践ドメイン駆動設計 なお、この記事ならびに本のリストは誰かの役に立つことは想定しておらず、単に自分が読んで影響を受けているなあと感じる本をまとめています。つまり自己満足です。 加えてこの手の記事を書く際には、一応筆者のプロフ
ここ数年、アジリティとセキュリティ(あるいはガバナンス)の両立について考える機会が多い。伝統的で規模の大きい企業にありがちな傾向として、セキュリティやガバナンスを確保するためにはシステムの開発/運用が鈍重、高コスト、不自由になったとしても已む無しとする思想がしばしば見受けられる。結果として例えば簡単な仮想サーバ１つを用意するだけでも数ヶ月の納期と膨大な工数を要するとか、世の中で当たり前に活用されている技術やプロセスが許可されない/導入に非現実的な手続きを要求されるといった状況が生まれる。 確かにシステムの安全性を適切にコントロールすることは重要である一方で、論理的に考えれば「セキュリティのためのビジネス」ではなく「ビジネスのためのセキュリティ」なのだから、セキュリティを確保するためにビジネスの成功が妨げられてしまっては本末転倒に思える。しかし実際には「セキュリティのためなので仕方がない」と
本文の内容は、2023年3月21にNIGEL DOUGLAS が投稿したブログ（https://sysdig.com/blog/terraform-security-best-practices）を元に日本語に翻訳・再構成した内容となっております。 コードとしてのインフラストラクチャ ー(IaC) を使用する場合、Terraform はデファクトのツールです。 リソース プロバイダーに関係なく、組織はそれらすべてを同時に操作できます。 コンフィギュレーションエラーがインフラストラクチャー全体に影響を与える可能性があるため、疑いの余地のない側面の 1 つは Terraform のセキュリティです。 この記事では、Terraformを使用するメリットを説明し、いくつかのセキュリティベストプラクティスを参照しながら、Terraformを安全な方法で使用するためのガイダンスを提供したいと思います。
社内PlatformチームのProduct Management
現職においてPlatform チーム（社内基盤チーム）として働き始めて2年近くがたった．このチームにおいて自分はTech Leadをメインに努めてきたが，同時にPlatformの「どのような機能を」「どのような優先度で」作るか? を決めるProduct Manager的な役割も果たしてきた（ちなみにTech Leadに関してはメルカリのテックリードが学んだ、HowよりWhyを重視することが大切なわけ で少し話した）．これは何度も失敗しながら悪戦苦闘しつつやってきたが自分たちなりのフレームワークをつくり実際に回すことができている． 未だに試行錯誤しているのでここで書いていることが正解だとは思っていないが，今後同じようにPlatformチーム的なことを始めるひとに向けて現状自分たちがどのようにやっているのかについて簡単にまとめておく（他の会社がどのようにやってるのかも聞きたいのでもし同じような
『Lean と DevOps の科学』って教養ないと理解できないじゃん！っていう話 - Qiita
今や生産性の可視化・評価指標といえば本書籍で紹介された『FourKeys』ですね。ちまたでは、絶対視されている様な表現・評価がされている記述をたまに見かけます。ですが、本当にそうでしょうか？ある方が調べたところ、FourKeys を使用している人のうち『Lean と DevOps の科学』を読んだことがない人は9割近くもいたそうです。 本記事では、FourKeys を有効に活用するために知っておくべき・理解しておくべき事柄を幅広い分野でまとめました。生産性を向上し、仕事の成果の質を上げたいと努力するエンジニアの方々が、次の日から使える情報を書けたのではないかと思います。FourKeys だけを見て生産性を上げるという行動は手段の目的化につながりかねません。Fourkeys の背景にある思想を知ることで、FourKeys を真に活用するきっかけになればと思います。 目次 初めに GW中に読も
オブザーバビリティ・エンジニアリング
本書は、近年のクラウドベースのソフトウェアシステム開発における設計プラクティスなどにおいて触れられる概念「オブザーバビリティ（可観測性）」に関する書籍です。オブザーバビリティとは何か、どのように役立てるのかなど、登場の背景から実践方法、組織、企業への適用といった幅広い視点で解説します。今後、ソフトウェアシステムの開発においてオブザーバビリティが果たすであろう、より大きな役割についても触れています。さらにSlackのゲスト寄稿者により、テストとデプロイプロセスへのオブザーバビリティの適用と、パイプラインによるテレメトリー管理についてのケーススタディを紹介。本書はソフトウェアに関わる多くの人々にとって今後より一般化するオブザーバビリティを知る第一歩となるでしょう。 本書に誤植などを発見された場合は問い合わせ窓口よりご連絡ください。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更
「Developers Meetup 急成長ベンチャーが向き合う『開発生産性』」は、開発組織や事業フェーズの異なる株式会社Another works・株式会社SmartHR・株式会社スタメンの3社が、開発生産性について語り尽くすイベントです。ここで株式会社SmartHRのすがわらまさのり氏が登壇。チーム増加に伴い起きた「認知負荷が高い」状況をどのように解決したかについて紹介します。 チームの増加に伴いできるようになったこと、やりにくくなったこと すがわらまさのり氏：ここから本題ですね。「開発生産性について、上から見るか、下から見るか」ということで、よろしくお願いします。過去に私が登壇したもので似たテーマがいくつかあるので、軽く紹介しておきます。もし気になる方がいれば後で見てください。 前提の共有というところで、先ほどもお話ししたように、私が担当したのは「SmartHR」の基本機能というプロ
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads 71 Ads API 11
SpringBoot/Quarkus/Micronautの性能を検証してみた ～その1 起動編～ - Taste of Tech Topics
こんにちは。@phonypianistです。 本投稿はアクロクエスト アドベントカレンダー 12月21日 の記事です。 最近、Quarkusアプリを本番適用しました。 QuarkusはJavaアプリを作るための軽量なフレームワークで起動が速いって聞くけど、実際どれくらい速いんだろう？と気になったので、Spring Bootや、類似OSSのMicronautと比べてみました。 背景 JavaのフレームワークといえばSpringBootが主流ですが、起動が遅かったり、必要なメモリが多かったりしています。 これは、アプリ起動時にリフレクションを用いてDI（Dependency Injection）を行っているのが要因の1つです。 マイクロサービス、コンテナネイティブなアプリケーションは、負荷の状況に応じて、シームレスにスケールアウトできる必要があります。 アプリケーションの起動速度が遅かったり、
Hidekazu Konishi - Profile / Biography | hidekazu-konishi.com
Hidekazu Konishi - Profile / Biography | hidekazu-konishi.com About Hidekazu Konishi Hidekazu Konishi is a Japan AWS Top Engineer, Japan AWS All Certifications Engineer (having passed All AWS Certification Exams), Cloud Engineer (specializing in Architecting and DevOps), Application Engineer, Prompt Engineer, and Tech Blogger. After gaining experience as an application engineer, he was assigned to
新卒でGoogleに入社して7年ちょっと経って、なんか最近社内・社外問わず転職しているひとをチラホラ見るし、ちょっとキャリアパスを真面目に考えたら転職してもいいかなぁと思ったので転職した。ちょうどいい時期にLaunchableにポジションがあったので、コンタクトをとって採用パスにのせてもらったら、採用された感じ。 9年ぶり2回目って書いたんですが、よく考えたらインターン後、日本からUS転籍後に退社しているので6年ぶり3回目が正しい気がする。 キャリアパスに思うところがあったとは なんかつらつら書こうと思ったけど、QuoraのWhy don't engineers make it further than being senior engineers at Google?の回答が良い感じの説明に見える。なんかTrajectory to L6は悪くなかったというかマネージャーからは「既にL6と
レガシーコードからの脱却
2019年10月4日のAWS DevDay / 2019年10月31日のEOF2019 / 2020年2月14日のDevelopers Summitで登壇した際のスライドです。 1. レガシーコードからの脱却 2020/2/14 株式会社アトラクタ 吉羽龍太郎 (@ryuzee) ✤ ✤ ✤ 初版: 2019/10/03 AWS DevDay 改訂: 2019/10/31 EOF2019 改訂: 2020/02/14 Developers Summit 2020 2. 株式会社アトラクタについて ✤ 社名：株式会社アトラクタ 英文表記：Attractor Inc. / https://www.attractor.co.jp ✤ 設立：2016年12月 ✤ 所在：東京都港区 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ アジャイル開発 / DevOps / チーム育成 /
このパターンには2つの背景があります。ひとつは、技術者がマイクロサービスアーキテクチャパターンを採用して、複数の(理想的には単一目的で、独立してデプロイ可能な)サービスで構成されるアプリケーションを開発するようになったことです。ふたつめは、企業がコンテナ(Dockerなど)、オーケストレータ(Kubernetesなど)、プロキシ/ゲートウェイ(Envoyなど)といった、クラウドネイティブなプラットフォームテクノロジを支持するようになったことです。 意図 サービスメッシュが解決しようとする問題は次のようなものです。 サービスディスカバリ、ルーティング、アプリケーションレベル(レイヤ7)の非機能通信要件を処理する言語対応の通信ライブラリを、個々のサービス用にコンパイルする必要性の排除 外部サービスのネットワークロケーション、セキュリティ認証、サービス品質(QoS)目標など、サービス通信設定の外
GWに技術書イッキ読み！Kindleセールで5/10まで半額の本を分野別に総まとめ - 仮想サーファーの日常
Amazonで、Kindle本が最大50％OFFになるゴールデンウィーク限定キャンペーンが開催されています。 期間は、2020年5月10日（日）まで。 50%OFFは、自分の観測範囲では前回の開催が2019年12月末だったので、4ヶ月ぶりの50%OFFセール。 これだけ多くの種類の技術書が50％OFFになる機会は多くないので、この機会にほしい本がないかチェックしておきたいですね。 【Kindle技術書50%OFFセール（5/10まで）】を見てみる この記事では、ゴールデンウィークに一気に技術書を読んで技術力を伸ばしたい方向けに、学びたい分野別にKIndleセール本をまとめました。 プログラミング言語を学ぶ HTML/CSSに入門したい HTML5/CSS3モダンコーディング フロントエンドエンジニアが教える3つの本格レイアウト スタンダード・グリッド・シングルページレイアウトの作り方 吉田
「コンテナ」「Kubernetes」はコスト削減のためではない――ガートナーが語る“誤解と真実”：最も重要なのは「組織変革」（1/2 ページ） 2021年6月21～22日にガートナーが開催した「アプリケーション・イノベーション＆ビジネス・ソリューション サミット」で、ガートナー ジャパンの桂島 航氏が「コンテナとKubernetesをITリーダーはどのように活用すべきか」と題して講演した。その内容をレポートする。 コンテナは、ほとんどの企業が利用するテクノロジーの一つに アジャイルなど開発手法の進化と、マイクロサービスアーキテクチャの進展で、アプリケーションやインフラに求められる要件は変わりつつある。その潮流の中で大きな役割を果たしているのがコンテナ技術とオーケストレーション技術のKubernetesだ。 2021年6月21〜22日にガートナーが主催した「アプリケーション・イノベーション＆
"Enterprise Roadmap to SRE"の日本語訳が出ました - YAMAGUCHI::weblog
はじめに こんにちは、Google CloudでオブザーバビリティとSREの担当をしているものです。今日は去年仕事でやってたものがようやっと表にでたのでその紹介をします。 「SREエンタープライズロードマップ」がでました Enterprise Roadmap to SREの日本語訳が公開されました。本レポートはSREに関して、その技術的立ち位置、導入する理由、必要なプロセス、文化、事例など、幅広く大局観を与えるコンパクトなレポートとなっています。ぜひご一読ください。#SRE #DevOps #GoogleCloudhttps://t.co/Lo1yY40CF4— Google Site Reliability Engineering (@googlesre) 2023年1月25日 「SREエンタープライズロードマップ」はかねてより "Enterprise Roadmap to SRE" と
2022年における開発組織のパフォーマンス計測とNewsPicksの取り組みについて - Uzabase for Engineers
NewsPicksの高山です。 2020年と2021年は「開発生産性」またはほぼ同義の「開発者体験」に注力した2年でした。特に2021年は、自分でも少しウザいぐらいに登壇やブログやインタビューでこの話をしていました。（後半からは「開発生産性」から派生してKotlinの話が主でした） tech.uzabase.com codezine.jp hatenanews.com zine.qiita.com zine.qiita.com tech.uzabase.com hatenanews.com 今回のブログでは、2021年のNewsPicks開発組織のパフォーマンス計測の現状と、界隈の動向についてまとめていきます。 背景 デプロイ頻度の計測 Findy Teams Four Keys まとめ 宣伝 背景 『LeanとDevOpsの科学』によると、一般的にアジャイル開発で良いとされる開発スタイル
Platform Engineering on Kubernetes を読んでCloud Native の現在地を理解する - じゃあ、おうちで学べる
はじめに 近年、Kubernetesの採用が進む中、複数のチームが関わり、複数のクラウドプロバイダーへのデプロイを行い、異なるスタックを扱う組織では、その導入の複雑さが新たな問題となっています。本書 『Platform Engineering on Kubernetes』は、Kubernetes に登場しつつあるベストプラクティスとオープンソースツールを活用し、これらのクラウドネイティブの問題を技術的に組織的にどのように解決するかを示してくれます。 learning.oreilly.com 本書では、Kubernetes上に優れたプラットフォームを構築するための要素を明確に定義し、組織の要件に合わせて必要なツールを体系的に紹介しており、実際の例とコードを交えながら各ステップをわかりやすく説明することで、最終的にはクラウドネイティブなソフトウェアを効率的に提供するための完全なプラットフォーム
生産性指標を可視化してチームのワークフローを改善したら生産性が爆上がりした話 - バイセル Tech Blog
はじめに こちらは バイセルテクノロジーズ Advent Calendar 2022 の 2 日目の記事です。 前日の記事は早瀬さん「ApolloClient から Relay に乗り換えようとして諦めた話」でした。 こんにちは！株式会社バイセルテクノロジーズのテクノロジー戦略本部に所属している藤澤です。最近ではチームのテックリードのロールも担っています。 現在私の所属しているプロジェクトでは、チームの開発手法としてスクラムを採用しており、スクラムを通じて自分達の生産性を改善するための取り組みを続けて来ました。 その一環として、生産性指標を計測し定量的にチームの生産性を観察することを始めたのですが、最近になって指標が急激に改善してきました。 そこで、今回はバイセルアドベントカレンダー 2 日目の記事として、生産性向上のためにチームとしてやってきたことを紹介したいと思います。 はじめに 背景
Dockerって何？ って聞かれたときの解説、の解説
TL;DR Dockerは仮想化であるコンテナの実装の一種 ただし、広義のDockerはOCI系コンテナの総称 アプリの配布と実行の仕組みと思えばOK コンテナによりIaCや一貫したデプロイ、H/Wの効率的な利用がしやすくなる ※ コメントでいくつか指摘があったので記事を更新しました。ご指摘ありがとうございました！ はじめに おそらく過去幾度となく生み出されたであろうDocker解説記事となります。正確には解説動画の解説記事。 というのも、Dockerあるいはコンテナはもはや当たり前、と言えるほど普及してるようにもSNSやブログとかだけ見てると思えますが、実際には話題は知ってるけど良く分かってない/業務で今度使う事を検討したいけどつまり何なの？ って人もまだまだ多いです。 なので私が 「Dockerって何？」 と聞かれたとき答えてる内容を動画にしてみました。技術的な詳細を解説というよりは
Register now for a full day of community, learning, and all things Visual Studio Code vscode.dev(!) October 20, 2021 by Chris Dias, @chrisdias Back in 2019, when the .dev top-level domain opened, we picked up vscode.dev and quickly parked it, pointing at our website code.visualstudio.com (or, if you are from the Boston area like me, we "pahked it"). Like a lot of people who buy a .dev domain, we h
表1(翻訳者により追加) MLOpsにおいて、DevOpsから追加された項目 以下では，予測サービスとして機能するMLモデルのトレーニングと評価の代表的な手順を説明します． MLのためのデータサイエンスの手順 どのMLプロジェクトでも、ビジネスユースケースを定義して成功基準を確立した後、 MLモデルを本番環境にデリバリする過程には次の手順が含まれます。 これらの手順は手動で完了することも、自動パイプラインで完了することもできます。 データ抽出： MLタスクのさまざまなデータソースから関連データを選択して統合します。 データ分析： 探索的データ分析 （EDA） を 実行して、MLモデルの構築に使用可能なデータを把握します。 このプロセスにより、次のことが起こります。 モデルが期待するデータスキーマと特性を理解します。 モデルに必要なデータの準備と特徴量エンジニアリングを特定します。 データの
どうも、かとじゅんです。 松岡さん(id:little_hands)が以下の記事を更新されたそうです。松岡さん自身が悩まれた中で検討したオプションであって、唯一の正解ではないと踏まえたうえで、率直な感想を述べたいと思います。結論からいうと、論旨は前回の記事と変わりませんが、コード例で具体的な考え方を示している点を工夫しています。 little-hands.hatenablog.com 前回の考察記事も古くなったので、最新の記事に併せて考察をまとめ直したいと思います。 blog.j5ik2o.me ドメインモデル ドメインモデル図が追加されていますね。以下の３つの集約があるそうです。「一つの集約にまとめればいいよね」という提案はなしという前提で考えます。 ユーザー タスク アクティビティ・レポート 「アクティビティ・レポート」は「タスク」もしくは「ユーザー」に関連を持つようです。 「これらの
いまさらですが、DevOpsとは何か、具体的には何に取り組むべきなのかについて整理しました。DevOpsとは、サービスの継続的な改善を実現するために、Dev自身がサービスの運用ができるよう、Opsは運用作業のツール化を進めていく取り組みです。そして、DevOpsエンジニアやSREなど、新たな役割への転換が求められます。 DevOps = 開発と運用の協業？ Velocity 2009というイベントで、写真共有サイトFlickrのエンジニアJohn Allspaw氏とPaul Hammon氏が「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」（ ビデオ / スライド ）という講演を行います。この講演ではWebサービスの運用における開発チームと運用チームの協業が語られています。両者が同じ目線に立つためにツールを活用するとともに、カル
CyberAgent AI事業本部新卒研修「MLOps」の資料を公開します | CyberAgent Developers Blog
はじめに 近年、様々な分野で機械学習の利用が進む中、モデルの品質を担保し、継続的な学習を行うための施策が重要視されています。そのため、機械学習のためのDevOpsであるMLOpsの必要性が高まっており、AI事業本部でも研修内容に取り入れています。 より良いMLOpsを構築するためには、アプリケーションやインフラの知識も必要です。そのため、今年は昨年までと異なり、MLエンジニアだけでなくソフトウェアエンジニアも講義に参加しました。また、新たに実践編が加わり、より業務を意識した講義が追加されました。 Container編 基礎編 応用編 実践編 そこで、今回は研修で行われた各講義の資料を公開したいと思います。 Container編 Container編では、コンテナにまつわる技術に対しインデックスを張ることと、イメージ作成や運用時のTipsを学び実業務に役立てることを目的としています。 そのた
目次 目次 はじめに DOPってどんな試験？ 受験のきっかけ 試験予約から合格までの流れ ピアソンVUEで予約 試験環境の準備 OnVUEにて試験にチェックイン 問題を解く お風呂受験のうまみ・つらみ うまみ つらみ 総論 その他 気付き・注意点 試験ポリシーの詳細 おわりに はじめに AWS認定試験を自宅のお風呂で受験して無事に合格することができました！ 自宅受験は便利ですが、そんなスペースが中々ない、いざ問題が起きたら怖いから躊躇している、という方は多いのではないでしょうか。 そこで、今回はこれから自宅受験を考えている方々の参考になるように予約から試験当日までの流れやお風呂で受けてみて分かったうまみ・つらみ、注意点などを書いていこうと思います。 ちなみに今回、私が受けた試験はDOP(DevOps Engineer - Professional)です。 DOPってどんな試験？ AWS認定
なぜDXは分かりにくいのか？ なぜ３種類のDXが生まれたのか？ ビジネスパーソンのためのDX入門セミナー【セミナーレポート】 | Aidemy Business
Aidemy Business > AI-CAN > なぜDXは分かりにくいのか？ なぜ３種類のDXが生まれたのか？ ビジネスパーソンのためのDX入門セミナー【セミナーレポート】 この記事は2020年12月23日に開催されたWebセミナー「DXを徹底解説！ビジネスパーソンのためのDX入門セミナー」のレポートです。 ※記事化のために一部を編集しています。 2020年12月23日、“中山ところてん”として知られる株式会社NextInt代表の中山心太氏と、株式会社アイデミーの共催セミナーが開催されました。Aidemy Businessの新講座「ビジネスパーソンのためのDX入門講座」を制作された中山氏が、そのエッセンスを凝縮してお話しくださいました。進行は、アイデミーで開発本部コンテンツ部長を務める登坂直矢です。 中山ところてん（中山心太）氏 株式会社NextInt代表 著書： 『仕事ではじめる機
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
GitLab Flow + GitHub Actions ではじめる、デプロイフローの改善・自動化 - エクサウィザーズ Engineer Blog
DevOps エンジニアの 根本 征 です。 前回のエントリーでは GitHub Actions の self-hosted runners について紹介しました。 今回はそれらを活用したデプロイフロー(主に API / Frontend)の改善について紹介したいと思います。 これまでのデプロイフローと課題 GitHub Flow はどうか GitLab Flow とは git-pr-release + GitHub Actions を使った、リリース Pull Request の自動生成 GitHub Actions を使ってデプロイを行う 効果と課題 おわりに これまでのデプロイフローと課題 部署やサービスによって異なりますが、これまでのデプロイにまつわる環境は大まかに下記のような状況でした。 3つの環境 develop 環境(主に開発者が使う環境) staging 環境(本番リリース
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ミニマムな React Web アプリケーションの技術スタックを大公開！ - inSmartBank
ビジネスインパクトのない新機能に費やす時間とコストを低減する｜mtx2s
SRE を成功させるには、まず計画を立てることが大事 | Google Cloud 公式ブログ
KubernetesにおけるCI/CD実践の勘所まとめ · Goldstine研究所
リリース自動化の嬉しみとその手法 - Kengo's blog
いきなり1,000行越えの差分のあるPRのレビューを依頼するのは今すぐやめろ。何年前の開発スタイルだよ
サーバーレスの基本とCI/CD構築 & 運用 〜システムは動いてからが本番だ〜
ソフトウェアエンジニアをしていて影響を受けた5冊（+α）
なぜセキュリティを言い訳にアジリティが犠牲になるのか - 流沙河鎮
Terraformセキュリティベストプラクティス
認知負荷は「ワーキングメモリに対する負荷」のこと 認知科学の観点から課題を整理すると“つらい”の輪郭が見えてくる
デフォルトで信頼できる Chrome 拡張機能
Googleを退職してLaunchableに入社しました - draftcode.osak.jp
サービスメッシュ必読ガイド - マイクロサービス時代のサービス間通信管理
「コンテナ」「Kubernetes」はコスト削減のためではない――ガートナーが語る“誤解と真実”
vscode.dev Visual Studio Code for the Web
MLOps: 機械学習における継続的デリバリとパイプラインの自動化 を翻訳してみた - Qiita
「DDDで複数集約間の整合性を確保する方法 Rev2」に対する考察 - かとじゅんの技術日誌
DevOpsとは開発チーム自身が運用できるようにすること - arclamp
お風呂でAWS認定試験を受けて合格した話 - ailes blog
TensorFlow で機械学習ゼロからヒーローへ