今あらためてコンテナ界隈を俯瞰する「Docker/Kubernetes コンテナ開発入門」 | DevelopersIO
単著ならではの一貫性と、筆者のノウハウをありったけ突っ込んでやろう！というあっつい想いを感じる素晴らしい書籍です。 「2018年から2024年、コンテナ界隈もいろいろ変わったもんだなぁ…（しみじみ）」 献本いただいた「Docker/Kubernetes 実践コンテナ開発入門 改訂新版」を眺めながら、ハマコーはそんな感慨にふけっておりました。 5年前、Docker始める人はまずこれ！書評「Docker/Kubernetes 実践コンテナ開発入門」で旧版の書評を書いたご縁で、著者の山田さんより改訂新版の献本をいただき、今この場にその本があるというわけです。 改めて中身読んでいたのですが、単著でこれはマジでやばいです。今コンテナを使った開発を進めようとしたときにでてくるであろう、開発〜運用面でのトピックが幅広く凝縮されている本で、「これ一冊読んどけば、マジはずれないよ」というぐらいの力が入った書
)
名前に関するガイドライン | Microsoft Docs
名前付けのガイドラインでは、アセンブリ、名前空間、型、メンバー、およびパラメーターなど、クラス ライブラリの構成要素に対して適切な識別子を選択するためのガイダンスを示します。 これらのガイドラインに従った識別子を選択すると、ライブラリの使いやすさが向上します。このため、ユーザーはライブラリを使用するために新しい一連の規則を習得する必要性を感じずに済みます。 開発者にとって一貫性のある環境を提供するには、パブリック クラスやプロテクト メソッドなど、公開される要素にこれらのガイドラインを適用する必要があります。 ただし、コード全体での一貫性を維持し保守性を向上させるには、これらの規則をコード全体で一貫して使用することを検討します。 Portions Copyright 2005 Microsoft Corporation. All rights reserved. Portions Copy
「良い名前付け」の参考サイトまとめ - Qiita
おはようございますこんにちわこんばんわ。どうもぶたです。 以前、チーム内で「変数や関数の名前に妥協したくないなー。どうしたら上手く命名できるんだろう？やっぱり英語の勉強？」という話になったので、今回は名前付け、命名についてまとめます。 とは言え、自分自身多くの記事やドキュメント、書籍などに助けられているので、ほぼ紹介記事になります。 ただ、順番には気をつけた方がいいと個人的には思っています。 何事もそうですが、なぜやるのかを知ってからどうやるのかを学ぶべきかな、と。 例えば、「この単語とこの単語はニュアンスが違う」「そんな単語存在しないよ」「単数と複数が間違ってる」 そんなレビューを受けたことがある人もいると思います。僕も言われたことがあります。 そういった内容の記事もたくさんあります。僕も読み込んでいますしストックして参照できるようにしています。 それはそれで有用ですし、是非意識していき
Azure Game Development Virtual Machineをデプロイしてみた。 - JBS Tech Blog
はじめに デプロイ手順 RDP接続と初期設定 はじめに Azure Game Development Virtual Machineをデプロイしてみました。 BlenderやUnreal Engineは手動でインストールすることも可能ですが、個別にインストールして開発環境を構築するのって結構面倒ですよね。 Azure Game Development Virtual Machineは、デプロイするだけで開発に必要な環境が一通りセットアップできるので、実際に試してみました。 docs.microsoft.com 仮想マシン作成後の初回ログイン時にEpic Gamesアカウントによるログインを要求されます。 デプロイする前にEpic Gamesのアカウントを作成しておきましょう。 デプロイ手順 azure portalにログインし、Azure Game Development Virtual
Microsoft の「クラウドアプリケーションのベストプラクティス」が良かったので紹介したい | DevelopersIO
こんにちは。CX事業本部MAD事業部のYui(@MayForBlue)です。 最近調べものをしている中で見つけたドキュメントが良かったのでご紹介したいと思います。 先にまとめ Microsoft の RESTful Web API の設計 のドキュメントが API 設計を考える上で勉強になった 関連する クラウド アプリケーションのベスト プラクティス のドキュメントもアプリケーションを設計する際の指標として良さそう RESTful Web API の設計 最近 API 設計やパス設計について考える機会があったのですが、これという正解がなかったり、人によって思想やこだわりが違ったりして結構難しいなと感じていました。 そんな中で下記のドキュメントを見つけてひとつの指標として良いなと思ったのでご紹介します。 内容（項目） REST とは何か リソースを中心とした API 設計の整理 HTTP
UMLとかAWS構成図とかを描くツール
UMLとか構成図とかの図を描くの何のツールを使えばいいか迷いませんか？私は迷います。 ですので、最近使っているツールを紹介します。 世の中にツールがイロイロあるのは理解した上で、大量に紹介するとやっぱり迷うので、似たようなツールや個人的に使わないツールはバッサリ省いています。 パワポで描く まずはPowerPointです。 エンジニアや技術系の方は「パワポで図を描くのはちょっと、、、」と思われるかも知れませんが、状況によってありだと思っています。 パワポのメリット パワポは、ビジネスユーザーならほぼ誰でも使える システムを作る時に、お客さん側も含めた関わるメンバー全員がITに詳しいとは限りません。しかしそういう人にもシステムに対する理解は最低限していただく必要があります。システム構成図とか特に興味がない人に説明するときに「新しいツールをいれてください」というのはハードルが高いです。 パワポ
結局UMLとかシーケンス図とかAWSの図とかどれで描くと良いのよ？と思ったときの選択肢 - Qiita
自身のプライオリティによりますが、いくつか。 Markdownで幅広く再利用性を利かせたい、長期的に丁寧に版管理したい 自分自身の操作性、描きやすさと、見た目 俄然手軽に、短期的に、Onlineでいつでもどこでも いずれかという視点で考えると良いのかなと思い、並べてみました。 1. 長期的に: Markdownで幅広く再利用性を利かせたい、丁寧に版管理したいなら Markdownで描くことのメリットは再利用性。 将来的に追記・編集、自分以外の誰かが手を入れる可能性が高い。 現在のドキュメントだけでなく多種説明資料、媒体に転用する可能性がある。 ...という点で差分管理をしたいなら、以下。 VSCodeでPlantUML、Mermaid 上記参考で以下。 Alt+D でプレビュー起動。 Ctrl + Shift + P でコマンドパレットを起動し、出力。 png, svg, eps, pdf
Roslyn CodeAnalysisでC#ソースの解析をしてみる - 気まま研究所ブログ
お久しぶりです。 多忙によりブログネタが全くできず、今まで放置状態でした。 さて、今日はVisual Studio 2015から導入されたRoslynコンパイラのAPIの一部で、C#ソースを解析するCodeAnalysisを使って解析を行ってみます。 大学の卒研で触ることがあったのですが、ネット漁ってもあんまり情報がなかったのでこれから利用する方の参考になればと思います。 はじめに 検証環境 必要なライブラリ 下準備 解析するソースコード 構文解析 ライブラリの取り込み 標準ライブラリの場所 コンパイラの生成 解析結果の整形 ノードの取得 クラス, インタフェース, 列挙型, 構造体, デリゲートの取得 メソッド, コンストラクタの取得 プロパティの取得 フィールドの取得 基底クラスの取得 全文 おまけ ドキュメント用内部IDの取得 ドキュメント用XMLの取得 おわりに はじめに Code
Windows / Visual Studio 使いが WSL 2 / Visual Studio Code で環境構築した時の手順 - しばやん雑記
基本的には Windows と Visual Studio を使って Azure Functions や GitHub で公開しているアプリケーションとライブラリを書いていますが、最近は Python や Go を書く必要がちょいちょい出てきたので、色々と観念して WSL 2 の環境を構築して使っています。 特に Python は Azure Functions だと Linux のみ対応となるので、Windows 上での開発は難しくなっています。他にも個人的に PR を投げている Terraform Provider for Azure も Windows 上では一部のテストが通らなくなっているので、WSL 2 を使わないと難しい状況です。 環境構築系はメモっておかないと後ではまるので、自分が必要な範囲で手順を残します。 基本的な WSL 2 環境構築 Visual Studio Cod
Docker完全に理解した | IIJ Engineers Blog
九州支社技術部(九州・中四国事業部)所属。自作パソコン好きで、ハードウェア選定の仕事を与えると喜ぶ。最近は何でもコンテナにしたい教に入信し、コンテナ化の機会を虎視眈々と狙っている。 Docker完全に理解した？ 【エンジニア用語解説】 「完全に理解した」 製品を利用をするためのチュートリアルを完了できたという意味。 「なにもわからない」 製品が本質的に抱える問題に直面するほど熟知が進んだという意味。 「チョットデキル」 同じ製品を自分でも１から作れるという意味。または開発者本人。 — 伊藤 祐策(パソコンの大先生) (@ito_yusaku) September 20, 2018 ということで、Docker完全に理解したので、自分なりの「これからDockerでコンテナを始める時のポイント」をいくつかご紹介したいと思います。 申し遅れましたが、九州支社技術部(九州・中四国事業部)所属のy-m
Dockerfileのベストプラクティス８選
はじめに Dockerfileを書く上で、Docker社の推奨するベストプラクティスを８つにまとめました。 ベストプラクティスに従うことによって、簡単・安全・効率的な、Dockerfileの作成を目指します。 Dockerのガイドライン コンテナは、必要最小限（エフェメラル）であるべき。 Dockerfile で定義されたイメージを使って作成されるコンテナは、可能ならばエフェメラル（短命；ephemeral）にすべきです。私たちの「エフェメラル」とは、停止・破棄可能であり、明らかに最小のセットアップで構築して使えることを意味します。 Dockerfileベストプラクティス 1. Baseイメージは、公式の信頼できるものを使おう 特定の言語などを扱う場合は、公式が言語が入ったイメージを配布してくれている場合が多いので、そちらを使おう。
完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita
これはなにか エンジニア、ビジネスサイドの方に向けた、「良い要件定義の作り方」について書いた記事です。 長文がつらつらと書いてある本稿ですが、要するに言いたいことは、 ● 完璧な要件定義など幻想であり、誰がどう作っても不完全である ● そのため、一番危険なのは、とびきり賢い人が出してきた要件定義で、 「あの人が作ったんだから大丈夫」と盲目的に考えること ● 完璧にはならないことを受け入れ、ベストを尽くす姿勢が大事 ●そもそも、アジャイル開発において、完璧な要件定義は求められていない ●良い要件定義には以下のスタンスが必要 ● UXから逆算する ● 削ぎ落とす ● 個ではなく、チームで作る ● レビューを徹底する ● 3つのシナリオを想定する ということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれ
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
Azure Virtual Machines で Visual Studio 2015環境を構築する - 1.21 jigowatts
概要 いつでもどこでもVisual Studioが使えたらいいのになぁ。 ということで、AzureのVirtual Machinesで開発環境を作っておくことにしました。 環境 Azure 開発者プログラム特典サブスクリプション 仮想マシン作成 ハブメニューの[Virtual Machines]を開き、ブレードの[追加]から選択画面へ。 今回は「Visual Studio Community 2015 Update 2 with Universal Windows Tools and Azure SDK 2.9 on Windows Server 2012 R2」を選択しました。 ちなみに、ここでWindows10とかVisual Studio Enterprise 2015を選ぶとMSDNサブスクリプションを要求されました。 "作成"ボタンを押下したら、いい感じに仮想マシンの設定を行い"
プロダクトマネジメント入門: 失敗しないプロダクトの作り方を学ぼう
Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ
【個人開発・ポートフォリオに】無料で簡単にいい感じのデザインにできるサービスまとめ - Qiita
個人開発・ポートフォリオ作成をする方に贈る いくらプロダクトが素晴らしいとしても、一見してダサいデザインだと、ユーザーは使う気がなくなってしまう。 でも、今からデザインの勉強をするのは面倒だし、そこまでこだわりがあるわけでもない。 Q. 簡単に及第点のデザインにできるサービスとかないんですか？ A. あります。 ということで、デザインのことはよくわからなくても、簡単にそれっぽくできるサービスをまとめました。 個人的には、「それっぽさ」の大部分はページレイアウトと画像、「こなれ感」は配色とフォントによって構成されていると思っています。 また、私はケチなのでここで紹介しているものは、すべて無料で使えるサービスです（課金プランはある）。 書かないこと 細かい使い方 大体有名なので、使い方はggれば出てきます。 ライセンスなどの情報 特に素材系は規約などを確認の上で使ってください。 あくまでも、こ
テスト、正常系から書くか異常系から書くか - hitode909の日記
今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値
ダミーデータ作成のお供に！ VS Code 拡張機能「vscode-random」で人名やカラーコードなどを自動生成してもらおう！ | DevelopersIO
はじめに ダミーデータを作成しなければならないときってありますよね？ テストデータやサンプル画面を作るときに値をどうするか困ったことありませんか？ そういった悩みを VS Code で解決するための拡張機能が vscode-random です。 https://marketplace.visualstudio.com/items?itemName=jrebocho.vscode-random デモ （GitHub リポジトリより引用） 拡張機能としてはカーソル位置にランダムな値を挿入するという単純なものなのですが、VS Code のマルチカーソル機能と組み合わせることで非常に強力な体験を得ることができます。 名前やメールアドレスの項目がある JSON や YAML に対し、複数の項目にまとめて値を挿入して作り上げるのは気持ちいいこと間違いなし！ 対応コマンド コマンド 説明 生成例
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Visual Studio」の中の人が作ったプログラマー向け十徳ナイフ「DevToys」／今までググって探していたツールがひとまとめに
開発者向けのテストの本いろいろ
