「デザイナーだけがデザインをする時代は古い」「デザインにセンスはない」と語るのは、Udemyの「UI/UXの改善を進めるための基礎講座」などで人気を誇る、UI/UXデザイナーの濱野将氏。生成AI時代において、デザインをビジネスをつなげるためのポイントや、UI/UXの基礎を解説します。 UI/UXデザイナーが教えるデザインの基本 濱野将氏：それでは、僕からは「ビジネスを実現する『デザイン』の基本」をお話しさせていただきます。よろしくお願いします。 今日のアジェンダはこんな感じです。「デザインの必要性」「デザイナーだけがデザインする時代はもう古い」「UI/UXについて」。今回はAIがテーマなので「AIを使ったプロジェクトの進め方」も少し紹介させていただきたいなと思っております。 簡単に自己紹介をさせてください。株式会社IMAKE代表の濱野と申します。職業はUI/UXデザイナーで、講師もさせてい
どうも、ばやしです。 2/27に行われたJoe Yoder : Domain modeling techniques for designing microservicesに参加してきたので、参加レポです。 なお私はDDDに詳しいわけでもなく、英語もおぼつかないので誤っている部分があるかもしれませんが、ご了承いただければと思います。 www.eventbrite.com どんな研修だったの？ ドメインモデリングを中心にドメイン駆動設計(以下DDD)の概念を学びつつ、それがどうマイクロサービスに役立つのかを学ぶ研修でした。 具体的にピザ屋のシステムや、交通違反システムを例に挙げてDDDの概念を理解しつつ、ワークショップではクレジットカードシステムを題材にイベントストーミングやマイクロサービスアーキテクチャ設計などを行いました。 全編英語だったのですが 英語で講義 日本人同士で日本語でワークシ
Rustでリレーショナルデータベースを自作したときの成果と反省と学び - Yoshisaurのメモ
はじめに この記事では、個人プロジェクトとしてRust言語でリレーショナルデータベースを開発した経験（もう五ヶ月も前...）について、その成果と反省、得た学びを共有します。 DBMSを自作した理由 自分がDBMSの自作に着手したのは、『Designing Data-Intensive Applications』という本の内容を深く理解するためでした。 この本は、データシステムの設計と運用において最も大切な「信頼性」、「拡張性」、「保守性」を保証する方法論を、豊富な文献を引用しつつ、理論と実践の橋渡しを巧みに行いながら、丁寧に説明している名著です。読んだことがない人は速攻購入してくだい。本当にいい本です。 この本は、データベースの内部構造に関する話も豊富に含まれていたので、「データベース自作してみようか...」という気持ちになりました。 Rustを採用した理由 データベースの実装のついでに、
PHPerKaigi 2024の登壇資料です。 https://phperkaigi.jp/2024/ - https://speakerdeck.com/moznion/pattern-and-strategy-of-web-application-caching - https://soudai.hatenablog.com/entry/cache-strategy
お疲れ様です。 前週に投稿した下記の記事について、多くの方に「いいね」、「ストック」していただきました。 皆さん、本当にありがとうございます。 今日は「Python だけで作る Web アプリケーション(フロントエンド編)の設計方針」について部分いたします。 本章ではこれまでの章の内容を踏まえて、設計方針を紹介します。 設計方針は 「積極的に TypeHint を活用すること」 「責務を明確に分け、適切な粒度でオブジェクトを分割すること」 「バックエンドの存在を前提にすること」の 3 つです。 TypeHint を活用する TypeHint とは以下のように変数や戻り値の型をヒントとして記述することです。 これはあくまでヒントなので実行時にその型を強制するわけではありません。つまり実行時にadd("1", "2")と書いても、文字列結合されて 12 になり期待する挙動ではありませんが、異常
概要 本記事は、スクラムを管理するアプリケーションをクリーンアーキテクチャの考え方で実装し、WebからもCLIからも動かせるようにしたという実践を紹介するものです。学習のための個人開発で作成したサンプルアプリケーションの設計と実装を適宜紹介することで、クリーンアーキテクチャに対する理解を深めることが目的です。 モチベーション なぜ現代の開発現場で定着しているクリーンアーキテクチャのアプリを手元で実装してみようと思ったかというと、私自身Webエンジニアとして働く中で、クリーンアーキテクチャの実践例は入出力をWebに限定したものばかりだったからです。 しかし、「詳細に依存せず抽象に依存すること」と唱えるクリーンアーキテクチャにとって、Webはただの詳細です。そこで、入力元、出力先を問わないアプリケーションはどのような書き味になるのか、自分で確かめてみたくなりました。 例えば、「ドメイン層は独立
米ドル/円 が150円と計算しやすくなり、コスト削減の圧力が日々強まる中、皆様お宝探しと垂れ流し回収の真っ最中でございましょうか。 最近はコスト削減や予算について見ることが多いので、その中で出てきた面白げな話に雑談を加えてとりとめなく書いてみようと思います。 削減余地はある 昨年にご好評いただいた AWSコスト削減とリソース管理 | 外道父の匠 を含め色々な削減施策を試みてきましたが、サクッと成果になる箇所から泥沼に動かない所まで様々あったりします。 ただ、どんなアカウントでもトラフィックや処理負荷には波があり、それに対する余剰リソースを確保して構成しているので、その辺をキュッと絞ることまで含めればやれることは必ず一定以上存在することになります。 そういう大きなお宝ではない小さなお宝だと様々あり、古びたとか退職者が作ったとかで、ほぼ使っていない垂れ流しリソースやデータをかき集めれば、チリツ
ダークファイバーでOPEN.ad.jpと接続してみた #インターネットゼミ | CyberAgent Developers Blog
こんにちは、インターネットゼミの小障子(@The_Ko_Show_)です。 インターネットゼミは「インターネット」について日々研究を行っているゼミです。 「インターネット」には多くの意味合いが思い浮かぶと思いますが、ゼミとしては特定の定義に限定せず広く各個人のインターネットについて研究を進めています。 インターネットゼミについてはこちらの記事をご覧ください。 インターネットゼミ開講のお知らせ 現在はオフィス近郊にラックを借りた上でAS63790を取得し、そのAS番号を用いて実験や研究を行いつつ、その結果を社内にフィードバックしています。もしピアリングやネットワーキングに興味がある方がいらっしゃればぜひご連絡ください。 インターネットゼミのインターネット構成 インターネットゼミの「Public ASプロジェクト」ではパブリックなAS番号 (AS63790) を取得し、我々が利用しているThe
【激歪】Seymour Duncan Slug レビュー！抵抗値47kΩ超のモンスターハムバッカー!!【ダンカン解析】 | ギターいじリストのおうち
生涯5000本以上のギターをいじり続けたきた管理人が実測データを交え世界一詳しいギターレビューやギターパーツ情報をお届け！
AWS環境を可視化できるソリューション【Lucidscale】を使って構成図を自動生成してみた | DevelopersIO
こんにちは。 繁松です。 はじめに AWS,Azure,GCPなどのクラウド環境を可視化できるサービス「Lucidscale」を使ってAWSの構成図を自動生成してみたのでブログにしました。 Lucidscaleを使うことで以下のような構成図を自動で生成することができます。 やってみた アカウント作成 Lucidscaleのアカウントを作成します。 https://lucidscale.com/ja 料金 2週間は無料で利用できます。 無料期間以降も継続利用する場合の料金は以下です。 インディビジュアルプラン（個人利用プラン） 1ユーザー（作成者）：￥269,000/年 チームプラン（チーム利用プラン） 1ユーザー（作成者）；￥269,000/年 1ユーザー（エクスプローラー）：￥54,900/年 https://lucid.app/ja/pricing/lucidscale#/pricin
チャット型ソフトウェアからAIアシスタント型ソフトウェアへの変化 OpenAIが発表したChatGPTの登場から、一年以上が経とうとしています。ChatGPT API公開後の初期段階では、人間とAI（特にここでは大規模言語モデル）との単純な対話を提供するソフトウェアが中心でした。しかし今では、OpenAI GPTs（以下GPTs）やMicrosoft Copilot（以下Copilot）を代表とする、AIによる外部データへのアクセスやAPI通信によって人間を支援する「AIアシスタント型」のソフトウェアが台頭してきています。 GPTsは、ユーザー自身が好みのAIアシスタントを制作できる仕組みです。ChatGPTは汎用的な仕組みのため、特定の業務を行わせようとすると、役割や前提を含んだ長々としたプロンプトを入力する必要がありました。その点でGPTsは、AIに対する指示だけでなく、AIが参照可能
このように、層ごとに関心事の分離を行うことで、保守性の高い（変更容易性や再利用性等）アプリケーションを実現できます。 しかし、「トランザクション」においてはどうでしょうか。 トランザクションはビジネス領域においても、技術領域においても関心事がある内容です。 そういう曖昧なものは「ひとまず usecase 層に入れてしまえ」という方針になりがちです。 ですが、DB 固有の知識を usecase 層の関心事にしてしまっては、関心事の分離をするメリットが得られません。 そのため、関心事の分離を実現しつつトランザクション実装をする方法を模索してみました。 前提 1. クリーンアーキテクチャを採用している（オニオンアーキテクチャやレイヤードアーキテクチャも含む） そもそもビジネス知識と技術知識を分離していないアーキテクチャを採用している場合、メリットは得られません。 そのため、オニオンアーキテクチャ
はじめに この記事は、業務でフロントエンドのディレクトリ設計思想を変更した際の作業をまとめた記事です📕 それなりの規模のプロジェクトでの移行作業のため、新規機能実装などに影響が出にくいようにリファクタリングを進めてきました。そこでの進め方や感想も含めてお伝えできればと思います。 前提 6年ほど運用しているReact Nativeのプロジェクトでの移行作業のお話です。 従来のディレクトリ設計思想はAtomic Designを採用していました。しかし、organismsのコンポーネントが300個近くにも及び、プロジェクトの規模が大きくなるにつれて様々な課題が浮き彫りになりました。これを機に設計思想の移行を決めました。 Layer型のAtomic DesignからFeature型のディレクトリ構造に移行していこうと思います😌 参考: ソフトウェアアーキテクチャの基礎 なぜ移行したか なぜ移行
レッドブルが「世界最速」FPVドローンRBD1開発、パイロットみずから設計。時速300km超のF1マシンにぴたりと追尾する映像公開 | テクノエッジ TechnoEdge
ガジェット全般、サイエンス、宇宙、音楽、モータースポーツetc... 電気・ネットワーク技術者。実績媒体Engadget日本版, Autoblog日本版, Forbes JAPAN他 エクストリームスポーツを効果的にマーケティングに取り込んできたエナジードリンクのレッドブルが新たに公開したのは、レッドブル・レーシングのF1マシンを世界最速のカメラ搭載ドローンでぴったり追跡する空撮映像です。 F1世界選手権の2024年シーズンは今週末に開幕します。昨シーズンはレッドブル・レーシングF1チームのマックス・フェルスタッペン選手が圧倒的な強さを見せつけて世界チャンピオンの座を防衛し、先頃行われたシーズン前の合同テストでも、圧倒的な安定感とスピードを誇示していました。 そんな自動車レースの頂点に立つレッドブルのF1マシンと世界チャンピオンを追いかけ回すドローンパイロットとして選ばれたのは、Dutch
風来のシレン6(2024)は、ローグライクジャンルのデジタルゲーム、不思議のダンジョン2 風来のシレン(1995)のシリーズ最新作。 読み解くべき価値を感じたため記事化する。 シレンやトルネコなど、不思議のダンジョンシリーズを多少なり触ったことがある人間を読者として想定している。 不思議のダンジョン 風来のシレン6 とぐろ島探検録(2024,スパイク・チュンソフト) (1)魅力 ①シビアな持ち物管理 ②持ち物の圧迫ストレス→マゼルンとお店による解放 ③鑑定タスクの消化 ④食料とレベルのトレードオフ ⑤持ち物スロットの疑似的な拡張 ⑥フロア移動直後の危機 ⑦死＝緊張の最高潮 (2)ボードゲームとの比較検討 ①カタン：建設資源のため込み⇔盗賊のリスク ②チケット・トゥ・ライド：列車カードのため込み⇔他者の先行リスク ③グレートウエスタントレイル：持ち物スロットとしてのウシ、マゼルンとしてのカン
仕様書通りにシステムを作りました。使えなくても知りません：「訴えてやる！」の前に読む IT訴訟 徹底解説（113）（1/3 ページ） ユーザー企業が作った仕様書に抜け漏れがあり、その通りに作ったシステムが使いものにならなかった。悪いのは、ベンダー、ユーザー企業、どちらなのか？ 連載目次 IT訴訟を例に取り、トラブルの予防策と対処法を解説する本連載。今回取り上げるのは、要件の不備についての裁判例である。ユーザーが示した要件に抜け漏れや誤りがあり、これに沿って構築したシステムはユーザーが本来望んだ動作をしなかったというものだ。 ユーザーはこれを債務不履行であると訴えるが、ベンダーは「言われた通りに作っただけで、こちらには責任はない」と反論した。 この手の紛争について、裁判所の立場はおおむね一貫しているように思われ、似たような判断が各地で示されている。今回取り上げる判決はこうした考え方の大本とな
WordCamp Kansai 2024 ハム『ブロックエディタでWebサイトの制作がどう変わったのか？実装事例から見る現在のWordPressの設計と構築』
WordCamp Kansai 2024 ハム『ブロックエディタでWebサイトの制作がどう変わったのか？実装事例から見る現在のWordPressの設計と構築』
煽りじゃなくてマジでこれ 賃貸から要望出しまくった注文住宅に引っ越したら何も困らなくなった 男性設計士も考えてないわけじゃないんだが 片付ける側の発想ではなく、片付けてもらう側の発想で設計しているんだよね システム開発に例えるとユーザーを誘導する設計ではなく、ユーザーが勝手にうまく使ってくれると想定して設計している感じ 賃貸や建売では不可能な収納術 ものの定位置を決める 出したら出しっぱなしの人でも定位置があると片付ける確率が上がる必要なものは必要な場所の近くに収納する でかい収納だと必然的に必要な場所から遠ざかる。小さい収納を複数用意する収納との距離が近づくほど出したら出しっぱなしの人でも片付ける確率が上がる収納ボックスのサイズに合わせる ホムセンでもニトリでもいいけどサイズをきっちり合わせる見た目が整うほど出したら出しっぱなしの人でも片付ける確率が上がるできるかぎり玄関で済ませる 上着
モジュール化 | 神戸大学MBA
原 拓志 現代の製品開発・生産のマネジメントにおいて、理解しておくべき概念の1つが「モジュール化」である。「モジュール化」とは、全体システムを、いくつかの下位システム（モジュール）にわけ、モジュール間のインターフェイスを標準化することによって、システム全体の構造を変革することなく、モジュールの取替や組換えによって、システムの機能を維持ないし変更できるようにする方法である。システムがハードウェアでもソフトウェアでも問わないし、比喩的に社会システムに適用することも可能だ。大量生産方式を特徴づける部品の互換化とも共通点があるが、互換部品が通常は同じ機能のものを指すのに対し、モジュール化の場合は、異なる機能のものも組換え可能にし、全体システムの機能を変革することも狙いにするところが相違する。 「モジュール化」のメリットの1つは、全体システムの変革に際して、変革を局所化することにより変革に伴う効率の
【ソフトウェア設計】モジュールをどう分割するのか？
はじめに 前々回や、前回に引き続き、ソフトウェア設計の指針に関する話をしたいと思います。 関数やクラス、そしてサービスなどシステムの塊の単位をモジュールと呼び、モジュールを作る事で、認知負荷を下げ複雑性と戦うという話をしてきました。では、モジュールは「いつ」分割するのが良いでしょうか？ また、他にも共通モジュールを不用意に作ってしまって苦労した人も多いのでは無いでしょうか？ 今回はそのあたりの話をしていきます。 TL;DR 以下があればモジュール設計を見直す 単純な要件/普段の利用に対して、タイプ量や約束事が多い 共通モジュールが「使われ方」に依存する モジュールの役割を一言で説明できない コード管理や性能/データ整合性など利用に際してのペナルティが高い 分割 is NOT 正義 - FizzBuzz Enterprise Edition 複雑性を排除するためにモジュール分割をすることは重
オンラインゲームを作ろう！と思ったことがある方は、 こちらの講演記事を1度は見たことがあるのではないでしょうか。 www.4gamer.net こちらの講演は、具体例を交えながら非常に分かりやすくオンラインゲームの主な同期方式が説明してあり、 2024年現在でもオンラインゲームの基礎を学ぶ資料として真っ先に名前を上げる最高の資料です。 しかしながら講演は2010年のものであり、オンラインゲームはこの10年余りで進化しています。 この辺りの進化の話を簡単にまとめつつ、オンラインゲームの同期方式の選び方を紹介します。 （上記講演記事の知識/用語を前提としているため、先に上記記事をお読みください。） オンラインゲームの民主化について 技術の話をする前に。 近年、「マルチプレイヤーゲーム」と聞いてオフラインの画面分割ゲームを想像する人はいないと言って良いほど オンラインゲームは民主化されてきました
TerraformのStateやModuleに関する設計 - tom-256.log
概要 名前付け 抽象度 インフラアーキテクチャ図 チーム 認証情報 変更(デプロイ)のライフサイクル DRYの誤用 コードの検索性 モジュール間の依存 アプリケーションレイヤーとの違い まとめ 概要 TerraformのStateやModuleに関する設計に関する考慮点をざっくり書く 名前付け ユビキタス言語とディレクトリ名や変数名を合わせて認知不可を下げる リソース名でなく役割・機能ベースのディレクトリ名にして認知不可を下げる プロダクトのコードネームはユビキタス言語なのでディレクトリ名にしても問題ない ModuleやStateのREADME.mdを書く https://github.com/terraform-docs/terraform-docs を使う うまく説明が書けない場合は設計に問題がある可能性がある チームメンバーが利用できるように考慮する いつどのようなときに使えばいいか
詳しい方いたら教えてください。めっちゃ欲しい情報ですん。 別にモノレポでなくてもいいんですが、backend/frontendをTSで開発されてる場合Prisma入れてる気がするのですがそういう時の型共有の方法、ggってもあまり出てこない気がする。 Prisma とは Node.jsのORMです。かなり使いやすくて気に入ってます。 スターもたくさんついてますね。 お金もたくさん調達できてるみたいでいい感じです。 Prismaの型の生成 参考: Set up Prisma 上記ページをもとにサクッとinstallすると /prisma に schema.prismaというファイルが生成されます。そのファイルに、例えばこんな感じでスキーマを定義してみます。 // ユーザー model User { id String @id @default(cuid()) slug String @uniq
プラットフォームの上に劣化版のプラットフォームを作成してしまうアンチパターン「内部プラットフォーム効果」とはどういうものなのか
「ソフトウェア設計におけるアンチパターンの中に特にひどいにも関わらず文書化されていないものがある」として、ソフトウェア開発のためのハウツーガイドを提供するサイト「The Daily WTF」の設立者であるアレックス・パパディムーリスさんが「内部プラットフォーム効果(Inner-platform effect)」について投稿しています。 The Inner-Platform Effect - The Daily WTF https://thedailywtf.com/articles/The_Inner-Platform_Effect パパディムーリスさんは「システムをカスタマイズしすぎることで設計時に使用されたプラットフォームの粗悪なレプリカになってしまう」という現象を、「内部プラットフォーム効果」と命名しました。 内部プラットフォーム効果の代表的な例として、エンジニア以外でもデータベース
SaaS アーキテクチャ概要
SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。
運用コストを低く抑えつつ全文検索機能を実現したい: SQLite3 で全文検索を実現する fts5 、ベクトル検索を実現する sqlite-vss
運用コストを低く抑えつつ全文検索機能を実現したい: SQLite3 で全文検索を実現する fts5 、ベクトル検索を実現する sqlite-vss 2024-02-22 ドキュメント数が 1 万件に満たない状況で全文検索をしたいドキュメントは頻繁に更新はされずに日時の更新で十分オンラインでのインデキシングを考えなくてよいので、バッチで十分みたいな状態でポータビリティが高く運用コストが低い状態で全文検索を実現したいなと調べていたら SQLite3 が良さそうだったというお話。 全文検索を実現する拡張機能: https://www.sqlite.org/fts5.htmlfts5 から relevancy による order by が使えるようになったらしく、version 4 以前は、relevance をチューニングして改善するのは難しそうだなと思った。この拡張機能が作成された経緯としては
設計品質と量産品質の違いとは？
設計品質と量産品質の違いとは？：ベンチャーが越えられない製品化の5つのハードル（7）（1/2 ページ） 連載「ベンチャーが越えられない製品化の5つのハードル」では、「オリジナルの製品を作りたい」「斬新なアイデアを形にしたい」と考え、製品化を目指す際に、絶対に押さえておかなければならないポイントを解説する。連載第7回は「設計品質」と「量産品質」の違いについて取り上げる。 前回、“中国人はなぜ「Made in Japan」の製品を爆買いするのか”をお伝えした。一般的に、外国人が「Made in Japan」を高く評価する理由として、次の2つが考えられる。 1つは、良い設計としっかりとした検証を行っているという評価だ。10万キロ以上走っても日本車のエンジンが全く壊れないのはその好例である。設計者が優れたエンジンの設計を行い、10万キロ以上走っても壊れないことを検証しているのだ。 もう1つは、バラ
鉄道の駅に設置されているホームドア。転落事故の防止に大きな効果を発揮しますが、都のまとめでは、都内の駅の設置率は、2023年3月現在、半数程度にとどまります。 こうした中、都営地下鉄では2月20日、設置率は100％となりました。最後に設置された押上駅のある浅草線は、5つの事業者による相互直通運転が行われ、ホームドアの設置は鬼門とされてきました。事業者それぞれで経営規模や車両が異なるため、足並みを揃えて高額な整備費用を負担できるかどうかが不透明だったためです。 しかし、今回、当初想定された車両改修コストは740分の1にまで抑えられ、ホームドアの全駅設置が実現しました。その立て役者となったのは2次元コードでした。
こんにちは、AIShift バックエンドエンジニアの石井(@sugar235711)です。 AIShiftでは去年の11月からAI Worker[1]という新しいサービスの開発が始まりました。（以下AI Worker） 本格的に開発が始まり3ヶ月弱経ったので、その間に試してきた技術やチームの取り組みについてまとめてみたいと思います。 はじめに この記事では、AI Workerのおおまかな概要・設計を説明し、それらのバックエンドを実現する上でどのような技術を試してきたのか、技術以外でのチームの取り組みについてまとめます。 少し分量が多いので、ライブラリについての情報を求めている方は、目次から気になる部分を読んでいただければと思います。 何を作っているのか ざっくりまとめると、Microsoft Teams/Web上で動くAIを活用した業務改善プラットフォームを作成しています。 GPTとRAG
はじめに こんにちは。ニコニコ動画開発の小池です。 私の所属するチームではニコニコ動画の動画サービスのサーバーサイドをメインに担当しております。 今回は PHPerKaigi2024 向けの記事として、動画サービスのコード改善についてこれまでの歴史や取り組みとその成果について紹介していきたいと思います。 文中の3つのフレーズをチャレンジトークンとしてみました。ぜひ探してみてください! （※ 記事の見出しにの横についている「#」はチャレンジトークンではありません。チャレンジトークンは文中に配置されています。紛らわしくてすみません！） 2006年: ローンチ ニコニコ動画は2006年にローンチされて以来、皆様の応援のおかげで現在までサービスが継続されております。 当時はRuby on Railsが流行り始めてCakePHPが出ているかどうかといったくらいの時代で、フレームワークを利用しないとい
「DNSに対する最悪の攻撃」 迅速なパッチ適用を推奨 ATHENEによると、KeyTrapを悪用した場合、単一のDNSパケットが結果的にCPUの使い果たしを誘導し、「Google Public DNS」やCloudflareのDNSなど広く使われているDNS実装やパブリックDNSプロバイダーを全て停止させることが可能だ。発表によると「BIND 9」を16時間ダウンさせたとされている。なお、この欠陥は「CVE-2023-50387」として特定されている。 この攻撃はインターネットの基本的な機能に深刻な影響を与え、世界中のWebクライアントの大部分が利用不能になる可能性がある。主要なDNSベンダーはこの攻撃を「これまでに発見されたDNSに対する最悪の攻撃」と呼んでおり、状況の重大さが指摘されている。 KeyTrapを悪用するサイバー攻撃者は、DNSSECを検証するDNSリゾルバを利用する全ての
『データモデリングでドメインを駆動する ――分散／疎結合な基幹系システムに向けて』”基幹システム”とは何か、どう作るのか、ということへの道標を示してくれる1冊 - Magnolia Tech
データモデリングでドメインを駆動する──分散／疎結合な基幹系システムに向けて 作者:杉本 啓技術評論社Amazon 著者の杉本啓様より献本いただきました。 「基幹システム」……よく考えると最近だんだんと聞く機会の減ってきたキーワードです。たまにメインフレーム上で動くCOBOLで組まれた基幹システムが負債になっている、といった比較的後ろ向きな話題の文脈で出てきて、あまり「攻めた」話題の文脈では出てこないイメージがあります。 本書は、この「そもそも基幹システムとは何か？」、その基幹システムの中心にある「帳簿」とはどんな役割を果たすのか？それらを支える「データモデル」はどのようなもので、どのような設計になるのか？といったことが、長年経営管理システムを作ってきた経験に裏打ちされた知識をもとに分かりやすく解説されます。 この手の、業務システムの設計の考え方、「要件に沿って設計する」以上の解説がなかな
チームトポロジーを読んだ感想
はじめに 最近、チームってどんな構成にするのがいいんだろうか？と考えたことがあって、参考になる情報がほしかったのでこの本を読んでみた。この本は組織設計について書かれた本で、次のようなことが書かれてる。 どうチームを構成するか？ チーム間のコミュニケーション（インタラクション）をどう設計するか？ 定義したチーム構成やコミュニケーションの設計をどう変化させていくべきか？ チームファースト、コンウェイの法則などの考え方をベースにこういった問いに答えており、具体的な事例も紹介されつつ説明されていたので、わかりやすかった。 個人的に特に知りたかったことが、１つのチーム内で複数のプロダクトを扱うときのアプローチ方法だった。この本はコンウェイの法則推しなので、境界線をみつけてチームを分けた方が良さそうだと思いつつ、よく読んでみると組織のサイズやソフトウェアの規模が小さい場合は、必ずしもこの法則に従わなく
詳細設計の書き方 - Qiita
はじめに システム開発において詳細設計という工程があります。 プログラマーはこの詳細設計を確認しながら開発を行うことになります。そのため詳細設計ではシステムの構造や仕様、動作などを細かく定義することが必要になります。 詳細設計を行うことでシステム開発の方向性が明確になり、コーディングやテストをスムーズに行うことができます。 詳細設計の成果物としてはクラス図やシーケンス図、画面設計書やデータベース設計書などがあり、システムの動きや機能を具体的に表現するものです。 今回は詳細設計を作成する機会があったので、詳細設計の書き方についてまとめたいと思います。 詳細設計の目的やメリット 詳細設計の目的は、システム開発の品質や効率を向上させることです。詳細設計では、システムの仕様や動作を細かく定義することで、以下のようなメリットがあります。 開発工程でのバグや遅延を減らすことができる テスト工程での不具
ここまで見てきた3社の事例は、いずれもプログラミング言語「Ruby」とそのWebアプリケーションフレームワーク「Ruby on Rails（以下、Rails）」で開発したアプリケーションにモジュラーモノリスを導入するものだった。Railsでアプリを開発すると通常はモノリスになるため、サービスの成長によって巨大なモノリスが出来上がる。これをモジュラーモノリス化することで、開発生産性を上げていた。 モジュラーモノリスはアーキテクチャーなので、実際にはプログラミング言語やフレームワークには依存しない。freeeの事例でも、Railsのシステムに加え、開発言語として「Go」を採用したシステムにモジュラーモノリスを導入していた。 今回は、開発言語として「TypeScript」、そのサーバーサイド実行環境として「Node.js」を採用したUbieの事例を取り上げる。同社は、消費者向けの症状検索エンジン
週末に自分がよく使っている技術をまとめたら反応が良かったので、テンプレートを作りました。 なにかWebサービスを作るときに、自分はこれらのライブラリを基本的には入れます。 ベースはcreate-next-appとなりますが、そこで生成された状態だと認証もDBも何もありません。 しかし、サービスを作るにあたって必要なケースがほとんどです。 このテンプレートには特定のライブラリを入れると毎回書かないといけない項目等を事前に作っておき、 開発に集中できる仕組みを作るのがゴールとなります。また、例を示しつつ削除するコード量を最小限に抑えます。 主にNext.js固有のハマるポイントや環境構築などめんどくさいけど毎回書いている点をカバーします。 linterと関連があるVSCode, pre-commit等の設定NextAuthに指定されたDB Schemaの作成やAPI routeの設置開発、テス
目次 どうにも俺にはタスク管理が必要らしい そもそもノートを取れなかった俺たちへ 時間で強制的にメモを取る 日記 手元におくA5の紙 ポケットに入れている手帳。 音声メモ・無線イヤホン 音声メモ・AppleWatch おわりに どうにも俺にはタスク管理が必要らしい だんだん仕事が煮詰まってきて、これほんとにタスク管理なりGTDなりしないと間に合わなくない？ ってなってきた。出荷時期までに終わらせておかなければいけないのだが、今は資材機材人材等の理由で処理できない問題がいくつか常に滞留している状況にいる。 だがこれがずっと意識の隅っこにいてワーキングメモリを食われている気がしてならない。もともとそんなにワーキングメモリが多くないたちの人間なのでややこしい思考をしようとすればその端から忘れていく。複雑な思考ができないのは普段のブコメやこのブログを読んでいても察してもらえているものと思う。 まず
PHPカンファレンス関西の登壇資料です。 WEB+DB PRESS Vol.134に詳細があります https://gihyo.jp/magazine/wdpress/archive/2023/vol134
主旨 以前はシステムの状態をオブジェクト指向でカプセル化し、オブジェクト同士の通信でシステムの制御をしようとしていた しかし、Webアプリケーションのように状態をメモリ上に保持し続けるのが難しい環境が増えると、上記のことがやりにくくなった（ORMのインピーダンスミスマッチの影響が大きくなった） 現在では、システム全体の状態を管理するためにオブジェクト指向を用いるシーンは減っているが、要所要所でシステムを抽象化する道具の一つとして用いるシーンはあり、適材適所で使い続ければ良い はじめに 一時期あれだけもてはやされた「オブジェクト指向」ですが、現在では「業務システム開発においてオブジェクト指向で作るとろくなことがない」、とか、いっそ「不要である」、という意見もよく見かけます。 オブジェクト指向、この記事では特に「オブジェクト指向プログラミング」を対象として話をしますが、その利点は以下の３点に集
これはなに ども、レバテック開発部のもりたです。最近めっちゃ元気！！ 今回は『データベースについて勉強したいあなたに送る技術書17冊(+11冊1講義7link)』として、もりたがここ半年くらいでわーっと集めたデータベース周りの書籍（とか）を紹介していきます。アプリケーションって結局はデータベースみたいなところがあると思うんですが、おれは長いことデータベースをどう学んだら良いのか分かりませんでした。同じような気持ちを抱えているITエンジニアの人もいると思うので、学習ロードマップと合わせて紹介していきます。 なお具体的な対象読者は業務でなんとなくSQL書いてるけど、ウィンドウ関数とか言われると分からんな……くらいの人です。 扱う領域と扱わない領域 扱う領域としてはだいたい以下 再入門本 SQL 内部構造 論理設計 周辺知識 データベース理論 その他高度なもの モデリング、NoSQL、分散データ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デザインにセンスは必要ない、大切なのは「情報を整理」する力 Udemyの人気講師が教える、UI/UXデザインの基礎
ドメインモデリングとマイクロサービスの研修に参加してきたよ - ばやしのブログ
キャッシュと向き合う、キャッシュと共に生きる / cache pattern
Python だけで作る Webアプリケーション(フロントエンド編)ー設計方針 - Qiita
TypeScriptでクリーンアーキテクチャを実践する
AWSが教えてくれないコスト削減の小話いろいろ | 外道父の匠
人間中心設計からAI中心設計へ ～AIエージェントによって変わるソフトウェアのパラダイム | gihyo.jp
どのレイヤー（層）でトランザクションを実装すべきか
フロントエンドのディレクトリ設計を移行した話 | Atomic Design → Feature
風来のシレン6のゲームデザイン : 精神科医のボードゲーム日記
仕様書通りにシステムを作りました。使えなくても知りません
収納がうまくいかないのは家事をしない男性が設計した家に住んでいるから
オンラインゲーム 10年の進化と同期方式の選び方 - きゅぶろぐ
モノレポにおけるback/front間のPrismaの型共有の方法
都営地下鉄全駅にホームドア 立て役者となったのは… | NHK
新規サービスのバックエンド開発で3ヶ月経ったので、試した技術や取り組みをまとめてみた
ニコニコ動画のコード改善の歩み - dwango on GitHub
「DNSに対する最悪の攻撃」 DNSSEC設計の根幹に関わる脆弱性「KeyTrap」が見つかる
TypeScriptでもモジュラーモノリス、Node.jsでシステム構築するUbie
Webサービスを作るときのテンプレートを作った - hiroppy's site
俺は権化ではないのでメモを取る。 - てのひらを、かえして
RDBアンチパターンと戦う - 削除フラグ 完全攻略ガイド / delete flag
オブジェクト指向は業務システムで本当に不要なのか？ - Qiita
データベースを勉強したいあなたに送る技術書17冊(+11冊1講義7link)