ssmjp ssmonline #38 "第四回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/307397/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
はじめまして @shimma です。本業はD2C企業のCTOとして働く傍ら、業務支援として複数社、インフラを中心に直接手を動かして、社内で横展開できるような設計・コードベースをご提供しています。 枯れた技術で コード行数少なく 運用コストかからず 8-9割くらいのことを解決できる こちらが私の設計がポリシーです。 世の中9割はスプレッドシートで解決できる 私達の想像以上に、世の中の困りごとの大半はスプレッドシートやエクセルで解決ができます。エンジニアに依頼しなくても直接ロジック変更できるなど、組織リソースの有効化としてもメリットあります。 一方、複雑な数式やマクロにすべてを寄せ切り、ロジックを育てていくと、メンテナンスが困難を極めていきます。この記事を読んで頂いている技術者の方々であれば 複雑な箇所はコードによせて 変更しやすい所はスプレッドシート/Google App Script とい
「ソフトウェアの「詳細設計書」とはなんなのか」というブログ記事を読んで考えたこと。設計に関するプロセスとドキュメンテーションの関係性についての考えの整理。SI屋的な視点で。 2024/8/18追記:文中にあった雑な文系disが不愉快というご指摘を受けました。ご指摘の通りだと思いましたので訂正しています。大変失礼しました。 「詳細設計書」とはなんなのか nowokay.hatenablog.com こちらの記事では詳細設計書とは以下のようなものであると整理されている。 表現を変えたコーディング(の一種) 机上プロトタイプ(の一種) 分析資料 保守(のための)資料 (水平作業の場合の)作業指示書 (委託している場合の)契約資料 上記以外で考えられるのは次のようなものがあるだろう 利害関係者が要求している たとえば受託開発において発注者が要求している場合 ほかには連携している相手先システム側から
近年のソフトウェアプロダクト開発組織の活動単位としてよく言われるのは、「少人数で安定したチーム」であろう。表現は違えど、どの文献でもそのように述べられる。 それでは、「少人数」と「安定」の2つの要件を満たせば高パフォーマンスなチームが設計できるかと言えば、そんなはずもない。他にも要件があるはずだ。 そこで、チームに共通して必要だと考える要件を、設計に関わったこれまでの組織から抽出して言語化し、原則としてまとめてみた。それが、「安定」「アトミック」「非兼務」「少人数」「流動性」「イテレーティブ」の6つだ。 初期に携わった組織には欠けていた要素もあるが、何度も失敗を重ねるうちに見いだしたものだ。組織設計のプラクティスとしてよく聞くものもあるが、いずれも実体験を経て必要だと感じたものばかりである。 なお、本記事で取り上げる6つのチーム設計原則だけでは、組織設計として不十分だ。チームにどういった機
こんにちは!サイオステクノロジーの安藤 浩です。DB設計書の生成が容易にできるDBMLをご紹介します。DBMLの入門として、DBMLの書き方、ER図生成方法、Github actionsでCIを実行して閲覧する方法をご紹介させていただきます。 DBMLとは DBML は DataBase Markup Language の略でDB構造を定義するために設計された言語です。 DB構造に焦点を当てており、可読性の高い言語です。 dbdiagram.io や dbdocs.io などを利用することでDBドキュメントの生成が可能です。 コードベースで図を生成できる点でPlantUMLと似ていますね。 DBMLの書き方 テーブルの書き方 まずはテーブルの定義の例をもとにDBMLの記法を紹介していきます。users というテーブルを作成してみます。コードは以下のようになります。 Table users
従業員からも必要とされるビジネスモデルを「置きに行く」 当たり前のことですが、経営者は「自分が作りたいと思っているもの」や「やりたいと思っていること」が、お客様だけでなく、従業員からも必要とされているかどうかを、まずは冷静に見極める必要があります。 よく「集客さえできれば、もっと売上が上がるはずだ」とか、「良い人材さえ採用できれば、うちの会社はもっと伸びるはずだ」と言う経営者がいますが、問題の本質は、実はそこではありません。 本当に問題なのは「自分がやりたいこと」と「お客様や従業員に求められていること」がズレてしまっている点です。 結果として、経営者は「お客様が集まらない……」「良い人材が全然集まらない……」といった苦しい戦いをせざるをえなくなってしまうのです。 お客様や従業員から「本当に必要とされるもの」であれば、向こうの方から探してでも、人がやって来るようになります。 では、お客様だけ
はじめに データベース(DB)の設計は、システムの性能や保守性に大きな影響を与えます。 この記事では、最低限パフォーマンスの低下や管理の複雑化を引き起こさないようにするために覚えておくべきことを、アンチパターンとしてまとめました。 本記事は、 現在仕事でデータベースを扱っており、データ設計について今一度おさらいしたい データベースについての基礎知識やお作法を身に付けたい という人を対象として想定しています。 これらに当てはまる方はぜひ一度確認してみてください! 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています!興味をお持ちいただける方は、こちらまで。 DB設計アンチパターン 早速、DB設計におけるアンチパターンを紹介します。 それぞれアンチパターンのテーブルを見て
しのゆ𝕏酒くずエンジニア @shinoyu 新宿で社長やってるソフトウェアエンジニア18年生のおかまちゃん / 💻技術🎧 V系 🎀ロリィタの人 / 170スペ110 スプリング、骨ウェーブ、顔ソフエレ / 絡みない鍵とスパムは🚫 / 原則IT関連業のみフォロー /たまに会えるかも @shinjukudist しのゆ𝕏酒くずエンジニア @shinoyu わし詳細設計書書くのやだよ( ̄・ω・ ̄) 細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない。 必要なのは完成に必要要件がまとめられたもの。それを元に受け入れ試験書がつくられる。それクリアすればどう作ってようが構わんわけだ 改修コストを下げるための設計になってることは前提だけどね。 だけど、詳細設計書が必要となる現場はこの設計することはできない。だってそれできてたら詳細設計書
CTO 室の恩田(@takashi_onda)です。 一休レストランのフロントエンドアーキテクトを担当しています。 Intro 一休レストランでは、以前ご紹介したようにフロントエンドで React / Remix を利用しています。 user-first.ikyu.co.jp 一方、設計方針としては、React / Remix への依存が最小になるように心掛けています。 今日は、そんな一見矛盾するような設計方針について、ご紹介したいと思います。 この記事を読んでいただき Remix に興味をもたれたら、明後日 2024/8/7(水) 19:00〜 のオンラインイベント offers-jp.connpass.com にもご参加いただけると嬉しいです。 この記事でご紹介している疎結合なフロントエンドアーキテクチャを実現する Remix の魅力についてお話します。 なぜ依存を最小にするのか? R
服さん @fukusanity 尻のデザインすごくて、中心に肛門っていうウンチが出る穴があるんだけど、普通なら蓋みたいな構造にしてしまいそうなところを2つの肉の塊でギュッと包むことで穴を塞いでるんですよね。蓋みたいな構造だと汚れが溜まりそうだし、ウンチ出す前に蓋を開ける手間が発生するんだけど、考えた奴は賢すぎる 2023-12-26 23:20:25 服さん @fukusanity 「2つの肉を挟み込む穴の開閉構造(以下: 肉挟み込み開閉構造)」は水でジャーっと洗えば汚れを落とせるしガチですごい.だからこそ肛門はヒンジを伴う蓋の構造ではなく,肉挟み込み開閉構造が採用されたのでしょう.この仕組み口部にも採用されており,恐らくですが特許を押さえていますね 2023-12-27 09:59:49 服さん @fukusanity この前これに気付いて「現状の尻を超える尻の設計は無理だ」と思った。そ
煽りじゃなくてマジでこれ 賃貸から要望出しまくった注文住宅に引っ越したら何も困らなくなった 男性設計士も考えてないわけじゃないんだが 片付ける側の発想ではなく、片付けてもらう側の発想で設計しているんだよね システム開発に例えるとユーザーを誘導する設計ではなく、ユーザーが勝手にうまく使ってくれると想定して設計している感じ 賃貸や建売では不可能な収納術 ものの定位置を決める 出したら出しっぱなしの人でも定位置があると片付ける確率が上がる必要なものは必要な場所の近くに収納する でかい収納だと必然的に必要な場所から遠ざかる。小さい収納を複数用意する収納との距離が近づくほど出したら出しっぱなしの人でも片付ける確率が上がる収納ボックスのサイズに合わせる ホムセンでもニトリでもいいけどサイズをきっちり合わせる見た目が整うほど出したら出しっぱなしの人でも片付ける確率が上がるできるかぎり玄関で済ませる 上着
2024年7月25日紙版発売 柴田芳樹 著 A5判/208ページ 定価2,860円(本体2,600円+税10%) ISBN 978-4-297-14293-3 Gihyo Direct Amazon 楽天ブックス ヨドバシ.com 電子版 Amazon Kindle honto この本の概要 本書は,著者が1993年から約30年間経験してきたAPI仕様の作成,2003年から20年間経験してきたテストファースト開発/テスト駆動開発の知見をまとめたものであり,一般的なソフトウェア開発者が習得することが容易ではない事柄を,本書を通して学び,実践してもらうことを目的としています。 本書が提唱する「API仕様ファースト開発」はWebサービスにおける大域的なテスト駆動開発の実現に必要なものであり,また,API仕様ファースト開発を実現するにはテスト駆動開発が必要です。API仕様ファースト開発とテスト駆動
特徴 女性らしいイメージがやや多い 下記のような柔らかい印象のイラストが多いです。 【ガジェットストック】 ガジェット関連のものを使用したい場合は、下記を使用すると良いと思われます。 【アイコン系】 【human pictogram 2.0】 オリンピックで流行ったやつです。 本サイトでは、アタッチメントをつけたりすることでかなりカスタマイズ性が高いのが特徴です。 【EXPERIENCE JAPAN PICTOGRAMS】 特徴 海外から見た日本が表現されている これはシンプルにUIが凝ってたので紹介します。 和テイストを演出したい場合は、良さそうですね! 【ICOOON MONO】 こちら色・サイズも変更可能です! 【Icon-rainbow】 ICOOON MONOと異なり、こちらは、中が肉抜きされているのが特徴。 【IFN FREE ICONS】 このデザインはどのようなパターンにマ
【Unit4 ブログリレー4日目】 こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 今回は、SNSではごく一般的ないいねとその通知機能をDynamoDBを利用して実装したら思ったより大変だったので、その詳細をご紹介します。 キャナルシティ劇場は、福岡県福岡市博多区の複合商業施設「キャナルシティ博多」のシアタービル最上階に位置する劇場。本文には特に関係ありません。 m3ラウンジ m3ラウンジのいいねとその通知の要件 RDBで実装したらどうなるか いいね機能 通知機能 DynamoDBで実装する いいね機能 通知機能 いいねする いいねを取り消す 通知を表示する 未読の通知の取得 未読の通知数 未読の通知を既読にする テーブル設計むずい PKとSKに何を選ぶか LSIは途中から作れない DynamoDBをローカルで動かして設計する まとめ We are h
はじめに 前々回や、前回に引き続き、ソフトウェア設計の指針に関する話をしたいと思います。 関数やクラス、そしてサービスなどシステムの塊の単位をモジュールと呼び、モジュールを作る事で、認知負荷を下げ複雑性と戦うという話をしてきました。では、モジュールは「いつ」分割するのが良いでしょうか? また、他にも共通モジュールを不用意に作ってしまって苦労した人も多いのでは無いでしょうか? 今回はそのあたりの話をしていきます。 TL;DR 以下があればモジュール設計を見直す 単純な要件/普段の利用に対して、タイプ量や約束事が多い 共通モジュールが「使われ方」に依存する モジュールの役割を一言で説明できない コード管理や性能/データ整合性など利用に際してのペナルティが高い 分割 is NOT 正義 - FizzBuzz Enterprise Edition 複雑性を排除するためにモジュール分割をすることは重
はじめに フロントエンドのディレクトリ構成、世の中に色んな「推し」が有って悩みますよね。 例えば、、、 さらに最近は、App Directoryの登場や、それに合わせたNext.js公式の「推し」構成がドキュメント化されたりと、さらに色々なパターンが出てきています。 本記事の趣旨 本記事では、具体的な構成そのものではなく、 様々ある構成を横串で見通して整理できる設計思想を紹介します。 新しい推し構成の紹介ではなく、構成を考えたり決めたりするときに役立つ抽象的・汎用的な指針を提供できればと考えています。 基本となる考え 分割の方向 一般的に、アーキテクチャにおける分割には2つの方向が有ります。 (出典も良書なのでリンクを貼っておきます: https://www.amazon.co.jp/dp/4873119820) これはディレクトリにおいても同じだと思っていて、筆者は分かりやすさのために
はじめに 最近書いてるソフトウェア設計シリーズです。今回は例外に関して。以前、以下のような記事を書いたのですが、もう少し深堀して書いてみました。 ちなみにソフトウェア設計シリーズは他には以下を書いています。 モジュールになぜ分けるのか? モジュール、依存、そしてカプセル化 モジュールをどう分割するのか? 簡潔さは力なり? 予測可能な振る舞いと簡潔さについて ドキュメントとしてのコメント TL;DR 例外は「原則」キャッチしない 業務例外や必ずハンドリングさせたい例外はOptionalなど戻り値の方が便利 だいたい以下の図が言いたい事のすべて 例外処理とは? 「例外処理(Exception Handling)」は言語に依らず普遍的な関心事です。端的に言えば例外処理は異常やシステムの動作に不備が発生した際の特別な分岐処理です。リカバリやリソースの解放、あるいはユーザへの通知などがありますね。
こんにちは、ウォンテッドリーDev Branch VPoE 室長の髙橋です。 ウォンテッドリーの開発組織であるDev Branchでは、外部から有識者を招いて勉強会を開催したり、技術顧問として知見を取り入れるなど、プロダクト開発により強い組織となるためにさまざまな施策を行っています。 今回、「テスト書いてないとかお前それ @t_wada の前でも同じ事言えんの」 でおなじみのt_wadaさん(和田 卓人さん、以下和田さん)に「予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント」をウォンテッドリー向けにカスタマイズして講演いただきました。 このストーリーでは、今回の講演の経緯から社内の反応・Q&Aまで、講演に関する詳細をご紹介いたします。 社内講演のきっかけ事の発端は、弊社のVPoEである要(X : @nory_kaname)より、外部エンジニアを招いて勉強会を開催する旨の問いかけ
Object Oriented Conference 2024 登壇の機会をいただいたので、ここ数年、設計について考えていることを、言語化してみました。 はじめに 設計と開発プロセスの関係性 ソフトウェア設計の知識と技能 ① ソフトウェア設計の基礎知識 a. 基本課題 b. 解決のアプローチ c. モジュール化:基本となる4つの技法 ② モジュール化 a. モジュールの分類 b. オブジェクト指向プログラミングのモジュール化 c. ドメイン駆動設計のモジュール化 ③アプリケーションのモジュール構成(参照モデル) コア(中心) ポート(境界) アダプタ(周辺) ④モデル駆動設計 全体 事業活動、要件、アーキテクチャ コア(中央) 業務ロジック、ドメインモデル 業務機能、アプリケーションサービス アダプター(周辺) 記録モデル、データベーススキーマ 連係モデル、プロトコル設計 対話モデル、イン
2024年4月25日紙版発売 2024年4月25日電子版発売 市原創,板倉広明 著 A5判/456ページ 定価3,740円(本体3,400円+税10%) ISBN 978-4-297-14178-3 Gihyo Direct Amazon 楽天ブックス ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle 楽天kobo honto この本の概要 SSL/TLSは,通信の秘密を守るために利用されている通信プロトコルです。HTTPSやHTTP/3にも利用されており,今日のWebでは利用が一般的になっています。本書では,その最新バージョンであるTLS 1.3のしくみと,その使い方を解説します。SSL/TLSは公開されている実装例などを真似すれば基本的な動作はさせられますが,それを応用していくには技術に関する理論の理解が必須になります。しかしSSL
Amazon Web Services ブログ サーバーレスマイクロサービスを構築するための設計アプローチの比較 AWS Lambda でワークロードを設計すると、コードレベルでもインフラレベルでも表現できるモジュール性のために、開発者に疑問が生じます。また、コードを実行するためにサーバーレスを使用するには、基盤となる機能コンポーネントからビジネスロジックを抽出するためのさらなる検討が必要です。この意図的な関心の分離により、堅牢なモジュール性が保証され、進化的なアーキテクチャへの道が開かれます。 この投稿は同期ワークロードに焦点を当てていますが、他のワークロードのタイプでも同様の考慮が当てはまります。API の境界を特定し、コンシューマと API について擦り合わせた後、その境界と関連するアーキテクチャを構成します。 Lambda 関数を使用して API を構成する最も一般的な 2 つの方
横浜市は、みなとみらい地区にある「Kアリーナ横浜」の混雑緩和などのために整備した歩道橋で、設計ミスによる強度不足などが明らかになったとして、6月1日に予定されていた開通を急きょ延期することにしました。 横浜市西区のみなとみらい地区には2万席を誇る音楽専用のアリーナ、「Kアリーナ横浜」が去年完成し、市は混雑を緩和するなどの目的で、全長130.4メートルの歩道橋を整備しました。 しかし、横浜市によりますと、5月中旬、橋桁を支える鉄筋コンクリート製の橋台という部分に長さ1.2メートル、幅3ミリほどのひび割れが見つかりました。 設計を担当した「JR東日本コンサルタンツ」は、当初は問題ないという見解だったものの、30日になって設計ミスによる構造上の問題があったと市に連絡してきたということです。 橋台の中の鉄筋の数が足らず、強度が足りない状態だということです。 このため、横浜市は1日に予定されていた開
要旨 コメントを適切に記述することは、特にインターフェイス(クラスやメソッド)において重要です。これにより、直感性が高まり、抽象化が十分に行われているかを確認する手助けになります。そのため、コメントはソフトウェア設計プロセスの重要な一部と位置づけられます。 2種類のコメントタイプ まず、コメントを2種類に分類します。 1️⃣ コードをより詳細化するコメント(lower-level comment) 2️⃣ コードをより抽象化するコメント(higher-level comment) どちらも必要なコメントとしつつ、本書では後者のコメントをより重視しています。 1️⃣ コードを詳細化するコメント(lower-level comment) 変数名などに残すタイプのコメントで、宣言した対象の単位や境界値、null許容などの詳細を明示することで、コードの正確性を高めます。こちらのタイプのコメントも必
はじめに お客様に提案をしているときの会話です。 お客様:「詳細設計書は作りますか」 私:「昔ながらの詳細設計(ロジックを日本語で書くもの)は作りません。クラス図とか、シーケンス図は複雑であれば作りますが、今回のシステムはそこまで必要なものはないものなので、割愛しようと思っています。」 お客様:「保守をお願いするかどうか未定なので、場合によっては引継ぎのために作ってもらうかもしれません」 私:「・・・・」 といった感じで、私がこの業界に入った30年前は、確かにプログラムを作る前に、詳細設計書と呼ばれるプログラムを日本語で書いていました。 最近、詳細設計と呼ばれるものを作った記憶がなく、無駄なものは作りたくないなぁという思いから、コードから自動生成できないかなと思って、いろいろ試してみました。 Doxygenって いろいろ調べてみると、Doxygen にたどり着きました。 色々な言語に対応し
チャット型ソフトウェアからAIアシスタント型ソフトウェアへの変化 OpenAIが発表したChatGPTの登場から、一年以上が経とうとしています。ChatGPT API公開後の初期段階では、人間とAI(特にここでは大規模言語モデル)との単純な対話を提供するソフトウェアが中心でした。しかし今では、OpenAI GPTs(以下GPTs)やMicrosoft Copilot(以下Copilot)を代表とする、AIによる外部データへのアクセスやAPI通信によって人間を支援する「AIアシスタント型」のソフトウェアが台頭してきています。 GPTsは、ユーザー自身が好みのAIアシスタントを制作できる仕組みです。ChatGPTは汎用的な仕組みのため、特定の業務を行わせようとすると、役割や前提を含んだ長々としたプロンプトを入力する必要がありました。その点でGPTsは、AIに対する指示だけでなく、AIが参照可能
Feature-Sliced Designというフロントエンドアーキテクチャ設計方法論をプロジェクトに導入してみたところ、 個人的には良いと感じているので、どのような設計方法論なのか、具体的にどのような部分が良いと感じたかを紹介していきたいと思います。 Feature-Sliced Designとは? Feature-Sliced Designは、フロントエンドアプリケーションを対象としたアーキテクチャ設計方法論です。公式サイトでは、「コードを整理するためのルールと規約の集大成」と記載されています。 Feature-Sliced Designの設計方法論 Feature-Sliced Designでは、プロジェクトはLayerで構成され、各LayerはSliceで構成され、各SliceはSegmentで構成されます。 Layer Feature-Sliced Designの第一階層をLay
Thinkings株式会社 では sonarATS の開発にあたり、基本的にはデザイナーがFigmaを作成し、それに基づいてエンジニアが開発するというフローを取っています。 そんな中、先日エンジニアサイドで画面設計を行ってみるという実験的な取り組みをしました。 本記事では画面設計を行うことになった経緯と具体的な取り組み内容を振り返り、エンジニアが画面設計をすることのメリットと課題感について考えたことをまとめたいと思います。 エンジニアサイドで画面設計をするきっかけとなった要因 エンジニアサイドで画面設計をすることとなった理由として、大きく分けて以下3つの要因がありました。 デザイナータスク削減の目標 あるマスタ画面を開発したときの課題感 上述の通り、『簡単なマスタ画面の開発』のような共通的な画面設計になる機能については、できるだけデザイナーが介入せずエンジニア主導で開発している → 実際に
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く