オープンソースらしくソフトウェアを設計するThis post is also available in the following languages. English, Korean
ソフトウェア開発におけるクリエイティビティの最小化、認知負荷 - Runner in the High
前提としてクリエイティブな仕事は再現性が低い。しかし逆に言えば再現性があってはいけないものがクリエイティブであり、再現性がないからこそクリエイティブであると言える。アートのように非再現的なものはクリエイティブであり、再現性が低く刹那的な成果物であることに意味がある。 ソフトウェア開発にもまたアート的なクリエイティビティが求められつつも、ビジネスとしての利益追求では再現性が同時に求められることが多い。従って、多くの現場ではソフトウェア開発を再現性の高い労働集約的な仕事に転換しようとする。むしろ、そうしなければ開発組織の規模をスケールさせることができない。 ここで言うクリエイティビティの有無とは本質的に技術力とイコールであり、その具体性の表出はフレームワークやプログラミング言語を使うことではなく、逆にそれらを生み出す側にある。このレベルの技術力を持つ人材を集め続けるのは無理があるが、一方で技術
技術力のボトムライン、技術的負債 - Runner in the High
実際の現場に現れる負債とかクソコードとか呼ばれるものは、簡単にできるはずのものが何十にも不必要な複雑性でラップされた成果物（標準ライブラリ相当の実装を自前で全部書いていて、かつエッジケースでバグだらけ、とか）であることが多い。しかし一方で、そもそもの実現したいこと・あるべき仕様のレベルである程度複雑性が仕方ないケースに対して、最短ルートで立ち向かったものが技術的負債扱いになってしまうこともある。 かつて、某データフォーマットプロトコルで外部のアイデンティティプロバイダとデータ連携を行う機能を開発したことがあった。 さすがに1からRFCに沿って自分で全部作るのはおかしいに決まっているので、Githubで使えそうなOSSライブラリを探していたのだが、その際に見つけたものは90%は欲しい機能があるものの残り10%ほど必要な機能が足りていなかった。そこまで使えるなら、あとは自分らでフォークして足り
世界一わかりやすいClean Architecture - nuits.jp blog
本項は「C# Tokyo オンライン「世界一わかりやすいClean Architecture」他」による発表の登壇原稿となります。過去に発表した.NET版の記事はこちらにアーカイブしています。 本稿のサンプルコード・PPTはこちらで公開しています。 「CC BY-SA 4.0」で公開していますので、気に入っていただけたら営利目的含め、ライセンスの範囲で自由に利用していただいて問題ありません。 github.com また動画を以下で配信しています。よろしければご覧ください。 世界一わかりやすいClean Architecture はじめに まず初めに、クリーンアーキテクチャの誤解されがちな二つのことについてお話させていただきます。 その上で、クリーンアーキテクチャの本質とは何か？押さえておくべき、本当に重要だと考えている三つの事について、お話しします。 注意事項 さて本題に入る前に、少し注意
実践クリーンアーキテクチャ │ nrslib
YouTube での解説 YouTube にて Java コードをベースに解説を行いました。 コードの雰囲気は C# とほとんど同じなので参考になるかと思います。 もしよければご覧ください。 Java コードの記事リンク：https://nrslib.com/clean-architecture-with-java/ その他解説もしています。もしよろしければチャンネル登録をお願いいたします。 Qiita 版 Qiita に CUI や GUI 向けのクリーンアーキテクチャの記事を書きました。 ボブおじさんのクラス図を模したものです。 Web とはまた異なった実装になるので、もしよければ合わせてご参照ください。 https://qiita.com/nrslib/items/a5f902c4defc83bd46b8 さらに PHP の Laravel 版も作ってみました。 https://qi
Hexagonal Architecture(ヘキサゴナルアーキテクチャ) とは
以下の点に同意して読んでいただければと思います。 現在の筆者の理解度を整理する目的で書いた記事のため、間違った解釈があるかもしれません ご指摘いただければと思います 概念的な話は解釈が分かれやすいです。なので、この記事だけではなく提唱者の記事も含めて読むことをおすすめします 本記事の要約 ヘキサゴナルアーキテクチャはMVC(S) や レイヤードアーキテクチャ が持つ課題を解決するために生まれた ヘキサゴナルアーキテクチャの目的 ユースケースを実現するためのロジックが完全に独立した状態で実行できるようにする 外部技術を抽象化し、テスト容易性を高くする Driver, Driven, Application という境界を設けることで責務を分離できる Hexagonal Architecture について ヘキサゴナルアーキテクチャは Ports & Adapter(ポートアンドアダプタ) とも
Hexagonal Architecture
概要 HexagonalArchitecture(ヘキサゴナルアーキテクチャ)についての解説です。 ヘキサゴナルアーキテクチャはDomain Driven Design(DDD, ドメイン駆動設計)に連なる設計手法です。 レイヤードアーキテクチャを更に疎結合に推し進めた形です。 別名として、Ports and Adapters(ポートアダプター)とも呼ばれています。 サンプル 何はともあれサンプルコードです。 https://github.com/nrslib/HexagonalArchitectureSample 解説 ヘキサゴナルアーキテクチャは以下のような図が有名です。 この図の形が六角形のため、ヘキサゴナルと表現されました。 なお、六角形であることは重要な要素ではありません。 こちらの図はドメイン領域を中心に見据え、データの入力や反映処理を外側に押しやるように設計するということを図
Hello, Superflare
A full-stack toolkit for Cloudflare Workers. The best parts of D1, R2, Queues, and more—all in one place.
ソフトウェアエンジニアとしての能力を高める方法について考えてみた - joker1007’s diary
早朝の寝る前ぐらいの時間にぼやっと下記の様なツイートしたらちょっと反応を貰ったので、取り留めは無いが自分なりに考えていることを書いてみる。 人を育てるのも仕事の内というのは完全にその通りなんだが、そこにドキュメントや本があるから読みます、触って作ってみます、生きたコードを読みます、以外に学ぶ方法なんかねえし、知らねえよ。ただやればいいだけの事に説明も何も無いんだよな……。マジ分からん……。— joker1007 (アルフォートおじさん) (@joker1007) March 2, 2023 タイトルは雑に書いたけど、能力を高めるというと範囲が広過ぎるので、技術的な意味でできる事が増える、ということをテーマとして話をしていこうと思う。基本的に自分の考え方の話なのでそこは御留意ください。 ツイートした通りで、状況や対象に依って割合は変わるかもしれないが基本的にそのためにやることは3つしかないと
ありきたりなシェアウェア代替オープンソースソフトウェアのリスト
MS OfficeがどうのこうのAdobeがどうのこうのいやわかる、MS OfficeとかAdobeは業界標準だしファイル互換でインポートとかも楽だ。 ただまぁその万人へ必須か？と言われたら圧倒的にそれが必須じゃない仕事をしている人のほうが多い。 何なら仕事じゃなくて趣味レベルであるならばなおさらMS OfficeとかAdobeとか業界標準ソフトウェアじゃなくても良くなっちゃう。 ということで、ありきたりなシェアウェア代替オープンソースソフトウェアのリストを作ってみた。 Libreofficeド定番中のド定番、オープンソースのオフィススイートだ。 MS Officeじゃなくて良い人はLibreofficeかGoogleのクラウドのヤツを使ってる。 やはり主に使われるのはワープロソフトのWriterと表計算ソフトのCalcとプレゼンテーションソフトのImpressだが、MS Accessの代
ドメイン駆動設計の目的は何か - little hands' lab
ドメイン駆動設計の定義についてEric Evansはなんと言っているのか の記事の中で、EricEvansのドメイン駆動の定義を引用して以下のように和訳しました。 ドメインの中核となる複雑さと機会に焦点を当てる ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する 明示的にそれらのモデルを表現するソフトウェアを書く 境界付けられたコンテキストの中のユビキタス言語で話す この中で、重要なポイントが明示されていませんでした。 定義にある4点のようなことを、なぜやる必要があるのか？ ということです。 つまり、ドメイン駆動設計は、一体何を解決しようとしているのでしょうか？ ドメイン駆動設計は何を解決しようとしているのか DDDはソフトウェア開発手法の一つです。 なのでまず、ソフトウェア開発の目的について考えてみましょう。 人々はなぜ、ソフトウェアを開発するのでしょうか？ それは、
ソフトウェア開発の見積もり入門
見積もりとは？ Wikipediaによると見積もりとは、以下のようにあります。 見積（みつもり。見積り、見積もりとも書く）とは、金額・量・期間・行動を前もって概算すること。見積もること。あらましの計算をすること。また、その計算。目算。「所要時間を見積る」、「一日の来客者数をざっと見積もった」など、おおよその感覚で数字の見当をつける場合の口語体表現でも使われる。 Wikipedia このように見積もりとは、なにかを行う前に事前にその結果を予想しておくことを言います。 見積もりを使うケースは、ソフトウェア開発に限った話ではありませんが、製造業であるソフトウェア開発においては『見積もり』というタスクは様々なケースで登場します。 見積もりが苦手な人は多い ソフトウェア開発では、「この機能を開発するときにどのくらいで完成できますか？」といったケースが見積もりのシチュエーションとしては多いかと思います
「コード書きました、あとはよろしく」では優れたソフトウェアは生まれない コンテナのスペシャリストが語る、運用性を損なう8つの実装例
今押さえておくべき知識をアップデートし、ノウハウを共有し、さらなるスキルアップを実現する場として開催されている、AWS で最も Developer に特化したカンファレンス「AWS Dev Day Online Japan」。ここでSr. Product Developer Advocate, Elastic Containersの原氏が登壇。続いて、運用性に優れたソフトウェアが重要な理由と、運用性を損なう8つの実装例について紹介します。前回はこちらから。 You build it, you run it 原トリ氏：（スライドの「You build it, you run it」を指して）この言葉、聞いたこと、見たことがある方がいるかもしれません。これは、2006年にACM（Association for Computing Machinery）という団体が、Amazon AWSのCTOで
7つの設計原則とオブジェクト指向プログラミング - ソフトウェア設計を考える
設計原則はよい設計をするための指針です。 では、よい設計とはなんでしょうか？ もっとも重要なソフトウェア品質は発展性 ソフトウェアの発展性がビジネス価値を生む 発展性をうみだす７つの設計原則 モジュール化 モジュール化の２つのアプローチ 型によるモジュール化 手続き的なモジュール化 関心の分離 関心の4象限 入出力と計算・判断の分離 業務の関心と実装の詳細の分離 もっとも複雑な関心事（ビジネスロジック）の分離を徹底する カプセル化と抽象化 カプセル化 ビジネスロジックのカプセル化 抽象化 データ抽象 ビジネスロジックとデータ抽象 高凝集と疎結合 凝集度 結合度 隠された結合性の問題 定義の一点性 見た目が同じコード 7つの設計原則の学び方 コードの実装例 ドメインオブジェクト設計のガイドライン 実践ガイドとして使える本 設計の考え方を理解するための本 もっとも重要なソフトウェア品質は発展性
「仕事のコード」を残す際のチェックリスト｜Uchio Kondo
最初に注意: この文章は「はじめに」「総論」が長いです🙃 追記＠2021/08/11 17:46想像よりはるかに反響をいただいたので、せっかくだからと要点をMarkdownにしてGitHubに置いてみました。何かにご利用ください。 はじめに・「仕事のコード」、つまり、業務などで作ったコードが、なるべく負債にならず、なるべく俗人化しないようにするために留意すると良さそうなことを自分の経験などから列挙したものです。 ・ちなみに、「対象読者」に書いてありますが、そもそものモチベーションが「非エンジニアがノーコード系のサービスで作ったシステムが最近増えつつあるような...」というところでした。こういうのどう取り扱うといいんですかねとなった時、まずは運用できる形にしてもらいたい、という狙いがあります。結果的に、ジュニアなエンジニアが良いシステムを残す上でも使える知識かなと思います。 ・個別の項目に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - macoshita/wakeonlan-server
GitHub - jasontaylordev/CleanArchitecture: Clean Architecture Solution Template for ASP.NET Core
GitHub - nrjohnstone/ports-adapters-examples: Example implementation of a simple book order domain giving various examples of how to initialize adapters within a host
Ryou Ezoe(江添 亮) on Twitter: "単にリリース管理の方法を機能ベースから納期ベースに切り替えるのが主流になっただけ。 https://t.co/bUCL7t7hop"
VMagicMirror
