Azure アプリケーションの設計原則 | Microsoft Docs
次の設計原則に従って、アプリケーションのスケーラビリティを上げて、回復力や管理しやすさを強化します。 自動修復機能を設計します 。 分散システムでは、障害が発生します。 障害の発生に備えてアプリケーションの自動修復機能を設計します。 すべての要素を冗長にします 。 単一障害点をなくすようにアプリケーションに冗長性を組み込みます。 調整を最小限に抑えます 。 アプリケーション サービス間の調整を最小限に抑えてスケーラビリティを実現します。 スケール アウトするように設計します 。需要に応じて新規インスタンスを追加または削除し、水平方向に拡張できるようにアプリケーションを設計します。 制限に対処するようにパーティション化します 。 パーティション分割を使用して、データベース、ネットワーク、コンピューティングの制限に対処します。 操作に合わせて設計します 。 運用チームが必要なツールを得られるよ
限界集落化するIT業界？ - Qiita
はじめに 日本は2021年時点で高齢化率(65歳以上の高齢者の比率)が28.9%の超高齢化社会のようです。 そして、わたし達の勤める会社も高齢化が緩やかに進んで いると思います。意外と認識するのが難しいのですが、すべての人は生きているだけで年を取りますので、会社の構成員の平均年齢は毎年自動で上がります。 会社の高齢化は、IT業界の人口分布を調べると確認できそうです。 出典 : - IT 人材需給に関する調査 － 調査報告書：みずほ情報総研株式会社 レポートは出てきましたが、分かるような分からないような感じですね。 仕事の役割が変わりそうな年代で再集計してグラフ化してみましょう。 みなさんが仕事をしている周りの人達の年齢層はどのようなものでしょうか？ このグラフに当てはまっているでしょうか？ もしもそうであるとしたら、限界集落化が進行している可能性があります。 限界集落化 限界集落とは、人口
【エンジニア向け】コピペで使えるChatGPTプロンプト構文20選を公開いたしました
株式会社Emposy（代表取締役：木谷真也）は、8月中旬にリリースした「AIの島」のメディアにエンジニア向けのChatGPTのプロンプトを20選公開いたしました。 プロンプト集の内容 今回、エンジニア向けに本当に使える厳選したプロンプト20選をまとめた記事をアップいたしました。 よく利用する以下の３項目に分けて、ご紹介しています。 ①コーディング ②バグの特定/修正作業 ③その他（便利なプロンプト） プロンプトはすべて、１クリックコピーですぐ使える状態にしているので、エンジニアの方は一度目を通して見てください。 プロンプト集のURL: https://ai-island-media.com/2023/08/28/chatgpt-prompt-20/ 今回はプロンプト５選をご紹介（一部） ①深津式プロンプト ChatGPTに役割を与え、ChatGPT自身が「何を書くべきか」を事前に知らせるこ
ハヤカワのオススメ本12冊+α（〜12/1 kindle版セール中）2023.11/30更新 - 沼の見える街
［2023年11月30日更新］ ハヤカワがまたkindle本の大規模セールをやっている（今回はブラックフライデーセールで12/1までとのこと）。 amzn.to 私もハヤカワの本が好きで、面白かった本をよくオススメしてるのだが、セールのたびにいちいち紹介するのも面倒なので、広くオススメできそうな本をまとめておく。 ちなみにハヤカワといえばSFの印象があるだろうが、私はけっこうノンフィクションに偏っているので、単純に面白かった本をフィクション/ノンフィクション問わずごちゃまぜで紹介したい。タイトルで10冊といいつつ上下巻やシリーズも１冊扱いで、関連書もちょいちょい並べてるので明らかに数十冊はあるが…。ついでなのでその他のオススメ本も軽めに紹介しとく。セール時はどれもだいたい半額なので買っといて損なし。 『プロジェクト・ヘイル・メアリー』 『イヌはなぜ愛してくれるのか 「最良の友」の科学』 『
人事制度ハンドブック - kaneda blog
2022年5月6日 人事制度 人事制度ハンドブック 22年1月から開始したブログ。 人事制度の設計・運用に関する記事のまとめです。 今後、人事制度を設計する際のハンドブックとして、随時更新していきます。 ■書籍：スタートアップのための人事制度の作り方 ■ブログ本体：https://kaneda3.com/ Pickup スタートアップにおける組織づくりの鉄則 今年、何パーセント昇給しましたか？(昇給率の話) 「売上が上がらないことよりも、人が辞める方がつらい」という本音 人事制度を使って、入社時に「期待」を伝える方法 等級の中に「サブグレード」をつくってはいけない 等級制度と評価制度の違い 降格・降給は、「カルチャー」である 【スライド公開】スタートアップにおける等級別の報酬レンジ 報酬水準に関する公開資料_ver5.0 昇格に、メリットはあるのか？ 急成長できるスタートアップの組織文化と
AWSハンズオンの探し方 | DevelopersIO
お客様にAWSを学習するためのハンズオンの探し方を教えて欲しいと依頼されることがあったので、その際に調べた内容をまとめました。AWSのハンズオンを探す際にご利用ください。それぞれのハンズオンの個数は 2022-07-07 時点のものです。 2022-09-27 にAWSの日本語ハンズオンまとめページである JP Contents Hub がリリースされました。このブログで紹介している各種ハンズオンへのリンクも含まれているようですので、まずはJP Contents Hubを参照いただくのがよいかもしれません。JP Contents Hubの解説は AWS 日本語ハンズオンまとめ JP Contents Hub のご紹介 | Amazon Web Services ブログ を参照してください。 AWS ハンズオン資料 ハンズオン資料 | AWS クラウドサービス活用資料集 22 個のハンズオン
スタートアップで、カルチャーが全く違う2つの組織を作った話｜Ubie (ユビー)｜note
新型コロナウイルス感染症やコロナワクチンについては、必ず1次情報として厚生労働省や首相官邸のウェブサイトなど公的機関で発表されている発生状況やQ&A、相談窓口の情報もご確認ください。※非常時のため、すべての関連記事に本注意書きを一時的に出しています。 これは何？50名規模の医療AIスタートアップUbie において、カルチャーや採用基準が全く異なる2つのチームを立ち上げ、数ヶ月運用してきました。 スタートアップでは比較的珍しい取り組みで、採用応募者等からもよくご質問いただくので、背景やチームごとの違いをまとめてみました。 はじめに 現在Ubieには、0→1フェーズの「開発」をミッションとしたUbie Discoveryチーム(40名規模)と、1→100フェーズの「拡張」をミッションとしたUbie Customer Scienceチーム(10名規模)という2つの組織があります。 Ubie Di
ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
これだけは押さえよう！住所フォームの作り方 - ケンオールブログ
まとめ 住所フォームの作り方 住所フォームを作るときには以下の4つを押さえましょう。 オートコンプリート機能に最適化する 郵便番号フィールドは1フィールドにしてハイフン有無どちらも対応する モバイルUX優先なら郵便番号が入力されたら即座に補完。精度優先なら郵便番号補完ボタンを設置 住所フィールドは「都道府県」「市区町村」「町名以下」の3フィールドが基本。「建物」フィールドはオプション 本文 地域SNSのユーザー登録、ECサイトの配送先入力、資料請求、自治体サイトでの電子申請など、ウェブサービスを活用する上で住所入力は欠かすことができません。 住所入力をシンプルかつ正確に行えるような入力インタフェース（住所フォーム）は、離脱率を減らし、コンバージョン率を向上させる上で重要です。 郵便番号を入力すると対応する住所を自動入力する機能（郵便番号による住所補完）は、住所フォームの改善方法として最も効
DDDに関する論の主戦軸を整理してみた（2020年版） - Qiita
各アクターのメンタルモデルと、複数のアクターが共用する"ドメインモデル"には情報構造上のギャップがある まず最初に、天重氏（@tenjuu99）による次の記事を参照する。 MVCとは何か ぜひ全編を読んでいただきたい。以降読んでいただいた前提で書く。 中盤《2. ドメインモデル》で、飲食店での複写式伝票の話をしている。下に記事中の図を引用させていただく。 この複写式伝票は、ある一つのドメインモデルを"実装"している、といえる。天重氏は、「この注文伝票をぼくが面白いとおもったのは、厨房の人とホールの人で情報構造が違っている点です。」と言っている。 ホールの人にとっての情報構造： ・席番号と料理の紐付けに関心がある。 厨房の人にとっての情報構造： ・料理を出す順番に関心がある。 （席番号と料理の紐付けに制約されずに、料理を出して行きたい。） そして、この複写式伝票は、 両者の情報構造の違い（と
レイヤードアーキテクチャ - kawasima
POSAでの定義 レイヤードアーキテクチャを、体系だって書いたのは「Pattern-Oriented Software Architecture, Volume 1, A System of Patterns」だろう。まずはその原典に立ち返って、レイヤードアーキテクチャとは何かをみてみる。 コンテキスト ソースコードの変更がシステム全体に波及させたくない。それが1つのコンポーネントに閉じられ、他に影響を与えないようにすべきだ。 インタフェースは安定している。標準化団体によって規定されている場合もある。 システムの一部は交換可能である。コンポーネントはシステムの他の部分に影響を与えることなく、実装を入れ替えることができる。 現在設計しているシステムと同様の下位レイヤの課題をもつ他のシステムを、将来構築することがあるかもしれない。 理解のしやすさと保守性のために同じ責務はグルーピングしておきた
『ビジネスの仕組みがわかる 図解のつくりかた』全文公開｜図解総研
「ビジネスの仕組みがわかる 図解のつくりかた」という本を全文公開します！この本は、2020年4月に出版されたスマホサイズのコンパクトな新書です。『ビジネスモデル2.0図鑑』を出版後、多くの反響をいただき、さまざまな企業でビジネスモデル図解について講演・ワークショップを開催してきたノウハウを凝縮した一冊になっています。 ※当記事の情報を転載、複製、改変等は禁止いたします それではここから全文公開をご覧ください。 第１章：ビジネスモデル図解、基本の「き」はじめに 僕たちが『ビジネスモデル2.0図鑑』を出版したのは２０１８年９月のことです。「Amazon Go」や「Spotify」など、１００の事例のビジネスモデルを同じフォーマットで図解した本は、７万部を超えるベストセラーになりました。その後さまざまな反響を得て、企業から多数の講演・ワークショップの依頼をいただきました。「ビジネスモデルを自分で
レバレジーズを退職します／人材紹介の最前線で見えたITエンジニアとして長く生き続けるための傾向と対策｜久松剛／IT百物語の蒐集家
本日8月26日、レバレジーズ最終出社でした（8月末退職）。レバレジーズではメディアシステム部部長としてエンジニアリングマネージメントを中心に担当した他、レバテック技術顧問としてエージェントの専門性向上などを担い、ITエンジニアのキャリアについて接したり深く考える機会が多くありました。写真は最初の勤務地のヒカリエと、現在のスクランブルスクエアです。 退職理由などについてはここ数年情シスの長としてレピュテーションリスクの観点から監視する側だったので特に書きませんが、代わりに私が採用時・入社後に示してきたITエンジニアとして長く生き続けるためのポイントについてここに記します。つまりは「指名されるエンジニア」になるために必要な事柄です。IT業界に出入りして20年。数多のプレイヤーの栄枯盛衰を見てのお話です。この観察結果からまとめた内容になります。 最も恐れなければならないのは忘却されること 以前に
Archi – Open Source ArchiMate Modelling
Archi The Open Source modelling toolkit for creating ArchiMate models and sketches. Used by Enterprise Architects everywhere. Download The Archi® modelling toolkit is targeted toward all levels of Enterprise Architects and Modellers. It provides a low cost to entry solution to users who may be making their first steps in the ArchiMate modelling language, or who are looking for an open source, cros
ソフトウェアのもっとも重要な品質は発展性 - ソフトウェア設計を考える
ソフトウェアでもっとも重視すべき品質は「発展性」なんだと思う。 機能要求や非機能要求は、時間とともに変化する。その要求の変化に対応してソフトウェアを発展させていける能力、つまり発展性こそがソフトウェアの価値を大きく左右する。 発展性に問題があり変化ができないソフトウェアと、発展性に優れ変化と成長を続けやすいソフトウェアの価値の差ということだ。 発展性の価値 顧客のニーズは変化する。また、市場の競合関係も変化する。そういう事業環境の変化にあわせて、ソフトウェアにも変化を続ける能力が求められている。 また、顧客のニーズや市場環境の変化がゆるやかだとしても、事業活動をすれば組織は経験を通じて学び成長していく。開発チームに限っても、ソフトウェア開発運用の経験を積むことで、開発の考え方とやり方にさまざまな学びと成長がある。そうやって学んだ知識を適切にかつ迅速にソフトウェアに反映できるほど、事業により
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ops Guides
OKRはツリーではない
接触確認アプリ「COCOA」、ソースコードをGitHub上に公開
NoCodeと負の遺産 - 西尾泰和のScrapbox
一人学際
