「未経験文系から3ヶ月でデータサイエンティストになって一発逆転」はここで終わり (2020/7/31 更新) - todo-mentor’s diary
データサイエンティストを生業にする手段と実態について述べる。 途中、具体例・境界値の例として私個人の話もするが、なるべく一般性のある話をする。 この記事で言いたいことは具体的には4つだ。 プログラミングスクールをディスるなら代わりの入門方法を提供しようよ。 もう「未経験文系から3ヶ月でデータサイエンティストで一発逆転物語」を止めろ。*1 おじさんは人生逆転したいなら真面目にやれ。 若者はワンチャンじゃなくて、ちゃんと化け物になれよ。 この記事についてはパブリック・ドメインとして転載・改変・リンク記載を自由にしてよいです。 (続き書いた) a. 入門は辛いが… b. 思考停止でプログラミングスクールに通うな。 なろう系・始めてみよう系資料一覧 （最速・最短ルート用） まずは動かしてみよう。強くてニューゲームが体験出来るぞ！ 入門以前の本 一般向け業界本 (AI業界と展望がわかる本) 技術者入
【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今
オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだのHatena
某所でオブジェクト指向についていろいろ書いたのでまとめておく。 問題意識としては初学者がなにかというと「オブジェクト指向できるようになりたい」のようなことを言うけどそこまでの優先順位でがんばるものではないんでは、というところです。 まず前提として、オブジェクト指向は1980-2000年くらいに流行って発達したものの、それ以降は時代にあわせた進歩はしていない20年以上前の技術ってのがあります。 そのころは今だとCPUのキャッシュにも満たないようなメモリをやりくりしてプログラムを書く必要があったので、オブジェクト指向はメモリ上のデータをコピーすることなくうまく使いまわせるようなプログラム技術になっています。 そしてオブジェクト指向にはそこから目だった更新はなく、タイトルに書いたように、カメラがやっとついたくらいのガラケーのような古い技術という感じがします。 オブジェクト指向について、アプリケー
はじめに 今回の記事では、私の独断と偏見でエンジニアリングにおける必須の書籍を、以下の分野に分けて40冊共有する。 Web開発 行動経済学 ソフトスキル その他 対象とする読者 プログラミング初心者 どの書籍から読み進めればいいかわからないプログラマー なにか新しい書籍を読みたいひと なんとなくタイトルが気になったひと Web開発 『リーダブルコード』 良質なコードの原則と具体的なテクニックを丁寧に解説している。プログラミング初心者はまずこれを読むべき。良質なコード―要は、メンテナンスしやすいコードを書く上で重要なヒントを教えてくれる。コーディングで一生役立つ知識が満載だ。何度読んでも決して色褪せることのない不朽の古典である。 『14歳からのプログラミング』 図解付きでプログラミングの基礎(例：変数、関数、条件分岐)を理解できる。小難しい専門用語が一切なく、初心者でも問題なく理解できるよう
2021年の「オブジェクト指向」を考える
きしださんが先日もたのしいお題を投下されていました。 出遅れましたがこのネタについて少し掘り下げてみます。 念のため個人的なスタンスをあらかじめ表明しておくと、オブジェクト指向に対してはそれなりに好意的ですが、別に時代の最先端だとかソフトウェア開発に必須の知識というほどではない（でも知っておくと便利というか、知らないと不便なこともあるかもしれないのでわざわざ避けるのはおすすめしない）というくらい温度感です。 オブジェクト指向 is 何 そもそも「オブジェクト指向」という言葉自体、座りの悪い言葉です。 意味が明確なのは「オブジェクト指向プログラミング(OOP)」、「オブジェクト指向プログラミング言語(OOPL)」、「オブジェクト指向設計(OOD)」「オブジェクト指向分析(OOA)」といった「オブジェクト指向なんとか」の方で、それらをふわっとまとめた（ような気がする）単語が「オブジェクト指向」
This is The Entire Computer Science Curriculum in 1000 YouTube Videos
This is The Entire Computer Science Curriculum in 1000 YouTube Videos In this article, we are going to create an entire Computer Science curriculum using only YouTube videos. The Computer Science curriculum is going to cover every skill essential for a Computer Science Engineer that has expertise in Artificial Intelligence and its subfields, like: Machine Learning, Deep Learning, Computer Vision,
キーポイント For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility. Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to inte
動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ
この文章は、2019年4月18日に開催された国際カンファレンス SeleniumConf Tokyo 2019 で行った基調講演の文字起こしを土台に加筆修正したものです。 当日の講演資料は speakerdeck で、動画は YouTube で公開されています。 Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo 動作するきれいなコード - どうたどり着くか 本日の講演タイトルは「動作するきれいなコード - どうたどり着くか」です。動作するきれいなコードへ至る道の話をさせていただこうと思います。 資料は公開予定で、講演の写真撮影も問題ありません。ツイッター等での実況も大歓迎です。ハッシュタグは #SeConfTokyo です。 改めて自己紹介です。和田卓人（わだたくと）といいまして、
ドメイン駆動設計に関する何か - 日々常々
2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも？くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ
オブジェクト指向宗教史
OOC 2024 の発表資料です。後のフィードバックを参考に、より妥当な文言に改訂してあります。 ※ 本コンテンツには、一部特定の宗教思想の迫害に言及する表現がございますが、そのような行いを肯定する意図の内容ではございません。
はじめに 以下おすすめする技術書達です。分類に迷うものありつつ、流行り廃りあるかもなので2022春と書きました。 技術書達 基本 プログラムはなぜ動くのか プログラムはなぜ動くのか 第3版 知っておきたいプログラミングの基礎知識 | 矢沢 久雄 |本 | 通販 | Amazon 2000年代から推されている基本情報技術者レベルの本 イラスト図解式 この一冊で全部わかるWeb技術の基本 イラスト図解式 この一冊で全部わかるWeb技術の基本 | NRIネットコム株式会社, 小林 恭平, 坂本 陽, 佐々木 拓郎 |本 | 通販 | Amazon Webの全体像から、HTTPでやりとりする仕組み、さまざまなデータ形式、Webアプリケーションの開発、セキュリティ、システムの構築・運用まで、これからWebにかかわる人が知っておきたい知識をこの一冊で丸ごと解説! リーダブルコード リーダブルコード ―
オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだの Hatena の件。基本的には同意。ただちょっと切り口が違うので自分の意見を言っておく。ただ、このテーマで何度か書こうとして失敗していて、今回も成功しているとはいえない。 宣言的プログラミングの時代 現代の主流は「宣言的プログラミング」であると思っている。これはリソースの宣言と、その状態遷移の手続きや振る舞いの付与が中心にある。 宣言型プログラミング - Wikipedia その代表的な例がフロントエンドの React と、バックエンドの k8s で、どちらも時系列に基づいた状態の宣言と、フレームワーク側による状態遷移処理、 Reconcillation(調停) が基礎にある。 フロントエンドとバックエンドという両極端な世界で、この変化が起きたのがこの時代を反映したものであると思う。 例えば、jQuer
名著「UNIXという考え方 - UNIX哲学」は本当に名著なのか？ 〜 著者のガンカーズは何者なのかとことん調べてみた - Qiita
補足 1975: トンプソンはベル研を一時休職し、母校のカリフォルニア大学バークレー校に Version 6 Unix をインストールする作業を手伝う。これは後に BSD Unix として配布される。 1984-1998: ガンカーズが DEC でプリンシパル・ソフトウェア・エンジニアを務めた時期 ガンカーズは DEC の Unix Engineering Group (UEG) に所属 いつから DEC に勤めていたのかは不明 P63 より「小さな会社で Version 7 Unix を使っていた」ので 1979 年よりも後 V7M の開発には関わってなさそう おそらく 1980-1984 の間に DEC に入社したと思われる ガンカーズが「UNIX の考え方」についての本はないだろうか？と考えたのは 1991 年 1988: POSIX.1 標準化（POSIX.2 は 1992 年）
2022/04/21更新 ふりかえってみて、この記事は手段と目的をごっちゃにしちゃった自分がよくわかる記事です。 DDDは「どうやってコードを書くか」が問題ではありません。その点を勘違いしちゃってるエンジニアの話として、続きを読みたい人は読んでください🙏 DDD（Domain Driven Design）って難しいですよね。難しい難しいとばかり考えていた僕もようやく最近になって少しずつわかってきた気がします。そのきっかけとなった書籍と僕のストーリーを本記事で紹介できたらと思います。 TL;DR Clean Architectureはなんとなくわかる DDDは難しい と感じている人は「Domain-Driven Design in PHP」を読むと道が拓けるかもしれない。 leanpub.com 僕とDDD DDDといえばEvansのドメイン駆動設計： エリック・エヴァンスのドメイン駆動設
Good Bye Web APIs
When building a single-page application or a mobile application, we usually need to implement a web API (REST, GraphQL, etc.) to connect the frontend and the backend. Technically, it's not very difficult, but it has some unfortunate consequences. Imagine two planets. The planet "frontend" speaks JavaScript and the planet "backend" also speaks JavaScript or any other advanced language. Now let's sa
CSSは簡単なコードで書けます。しかし、プロジェクトの規模が大きくなるにつれ、コードが重複したり、未使用のコードが増えたり、!importantでの上書きが増えたり、読みにくいコードになります。 CSSのセレクタの書き方・命名や管理を改善する、シンプルで非常に効果的な5つの原則を紹介します。 Improve your CSS with these 5 principles by Adrian Bece (@AdrianBDesigns) 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに CSSを改善する命名の原則 CSSを改善する詳細度の原則 CSSを改善するDRY原則 CSSを改善する単一責任の原則 CSSを改善する開放/閉鎖原則 CSSを改善する方法のまとめ はじめに CSSは簡単で分かりやすいのに、CSSを書く時に
2024/3/24に開催されたObject-Oriented Conferenceでの登壇資料です。 https://ooc.dev/2024/
ビジネスロジックを「型」で表現するOOPのための関数型DDD / Functional And Type-Safe DDD for OOP
Object-Oriented Conference 2024で発表した資料です。 https://fortee.jp/oocon-2024/proposal/b31c9818-3cb8-4350-adfe-cbc839cdf829 ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に代数的データ型などの関数型のパラダイムを加えたよりタイプセーフな関数型DDDを紹介します。 本セッションではドメインモデリングによって発見したモデルやビジネスロジックをソフトウェアに反映する際により型を重視した設計を加えます。 型で表現する範囲が広がることでビジネスロジックをより明確にコードで表現できるようになります。 さらには型で表現されているためコンパイルフェーズで気付けるミスが増え、ソフトウェアの品質向上にもつながります。 関数型の考えをいれるといってもただ単にHaskellなどに代表される関
第0章. なぜ Scala を使うのか？ はじめに 本稿は、John C. Mitchell 氏らによる Concepts in Programming Languages を基に自身の見解を交え、私がなぜ Scala を好んで使うのかを論じた記事になります。 プログラミング言語の歴史 本題に入る前に、プログラミング言語の歴史について紹介します。 年代 言語・イノベーション 1950 Fortran and Cobol 1960 Lisp and Algol 1970 Abstract data types (Simula, C, SQL) 1980 Objects (Smalltalk, C++) 1990 Java, JavaScript, Python, Ruby これは、年代ごとに開発された言語およびイノベーションを表にまとめたものになります。ただし、この表には欠けている事柄があり
この文章みてください。 オレはもう20年以上システム業界にいるけどな、その長い経験から言うと、オブジェクト指向なんてものは、理論としては面白いけど、およそ実用的とは言い難いものだな。まぁ、例えばGUIのコンポーネントとかはオブジェクト指向に基づいて作られているようだから、そういうツールとかを作る人には必要なものなのかもしれない。しかし君たちがいずれ作ることになる業務アルゴリズムにはまったく無縁のものだと思ってもらって間違いない。どうもこの業界、オブジェクト指向でなければダメ、というような風潮がまかりとおっているけどな、オブジェクト指向なんか本当に使っている人はほとんどいないよ。オレも少し勉強してみたけど、カプセル化とかポリ何とかとか、どうにも利点が理解できなかったね。実際、実業務で使ったことなどないしな…… 「またお前、オブジェクト指向の話をしてるのか」と思ったかもしれませんが、2010年
POSAでの定義 レイヤードアーキテクチャを、体系だって書いたのは「Pattern-Oriented Software Architecture, Volume 1, A System of Patterns」だろう。まずはその原典に立ち返って、レイヤードアーキテクチャとは何かをみてみる。 コンテキスト ソースコードの変更がシステム全体に波及させたくない。それが1つのコンポーネントに閉じられ、他に影響を与えないようにすべきだ。 インタフェースは安定している。標準化団体によって規定されている場合もある。 システムの一部は交換可能である。コンポーネントはシステムの他の部分に影響を与えることなく、実装を入れ替えることができる。 現在設計しているシステムと同様の下位レイヤの課題をもつ他のシステムを、将来構築することがあるかもしれない。 理解のしやすさと保守性のために同じ責務はグルーピングしておきた
「バニラ」の起源について
IBMのBookMasterでは、デフォルトを"vanilla"、特別な設定を"mocha"と呼んでいたらしい。 http://web.archive.org/web/20211224091337/ftp://public.dhe.ibm.com/printers/products/dcf/samples/B2H.HTM 「Chapter 6. Caveats and restrictions (what's supported and what's not!)」に以下の記述がある。 Conditional sections (.cs) and BookMaster's "vanilla" DVCF macros (.CONFIG and .WHEN) are supported, but not BookMaster's "mocha" DVCF macros (e.g. .USING,
2022/3/25に行われた「第一回プログラミング教育について話し合う会」でのLT資料です。 https://opt.connpass.com/event/240392/
2022/5/14に開催されたTechFeed Conference 2022の5分LTでの登壇資料です
追記: 振り返りを書いてみました～ -- ここから元記事 別題: 抽象化って言葉もう。。 社内の記事にて、オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) | アラン・シャロウェイ, ジェームズ・R・トロット, 村上 雅章 |本 | 通販 | Amazonを紹介してもらいました。 取り上げられた、共通性／可変性分析の解説を見て、はっと思うことがありポエムを仕立てました。 共通性／可変性分析 共通性／可変性分析については、書籍を読むかググって頂けると良いですが、社内記事が良かったので引用させて頂きます。 問題領域にある概念を見つける（共通性の分析） その流動的要素を洗い出す（可変性の分析） 流動的要素を見ながら、その概念が持つ責務を果たすための抽象的側面（≒インタフェース）を導く 各流動的要素の実装上の観点から、インタフェースが適切かどうかを見極め、補正する オ
Java 20, 21, オブジェクト指向からデータ指向へ / Java20, 21, Object Oriented to Data Oriented
2023/5/10(水)に開催されたTechFeed Experts Night#18での登壇資料です。 https://techfeed.io/events/techfeed-experts-night-18
Introduction Participation If you are interested in contributing to this book, check out the contribution guidelines. News 2024-03-17: You can now download the book in PDF format from this link. Design patterns In software development, we often come across problems that share similarities regardless of the environment they appear in. Although the implementation details are crucial to solve the tas
数日前にTwitterで, JavaScriptのオブジェクトに対する===の挙動が初心者には難しいみたいな話を見かけた. 発端や周辺の議論をちゃんと追いかけてないからとくに出典は貼らない. たぶん元々の話は「へぇ, こういう挙動なんだ, 簡単ではないね」くらいの話だったのかもしれない. 自分のタイムラインの観測範囲では「そうだそうだ, (参照の同一性ではなく)同値性にしとけばいいのに」と思っている人もそれなりにいそうに見えた. 個人的にも同値性が簡単に確認できるとよい気はするものの, 「なんでそうしないんだ, オブジェクトの中身を確認していくだけだろ!」みたいな簡単な話ではないことも知っているため, 以下のようなツイートをしたのだった. JavaScriptのオブジェクトの同値性、再帰的な構造とか作るとぜんぜん自明じゃないんだよなぁ。リンクの構造は違うけどプロパティを辿ったときのパスはど
「DIは必ずしも善ではない」| Dependency injection is not a virtue by DHH
DHHの Dependency injection is not a virtue(2013) という記事は有名ですが、ちゃんとした日本語訳が意外とないようなので、書き出してみて思ったことを要約してみた。[1] Rubyのエンジニアの中には、何も考えずに他のモデルのnewを書いてる人の割合が多いという（コードレビュー時のヒアリングによる）体感があり、また8年前の記事なので経験の浅い人は読んだことがない人もいると思う。該当する方は是非読んでほしい。 全部読む時間が無い人は要約へ. 原文と訳文 In languages less open than Ruby, hard-coded class references can make testing tough. If your Java code has Date date = new Date(); buried in its guts,
（6/22 注：書き足りないと思っていた箇所を補って加筆修正しました） エンジニアのbonotakeです。Ideinに入ってかれこれ3年以上経ちますが、Ideinでブログ記事を書くのは初めてです。 今日は、ソフトウェア設計の全く新しい考え方について書かれた "The Essence of Software" という本の紹介をしたいと思います。 この本の著者はMIT教授でソフトウェア工学の世界的な研究者であるDaniel Jacksonです。形式手法Alloyの発明者、と言ったほうが通じる人には通じるかもしれません。形式手法とは、ありていにいえば、数理論理学を駆使してソフトウェアに潜むバグを論理的に駆逐する手法です。 （個人的な宣伝ですが、彼の書いたAlloyの本を以前翻訳して出版しました。） そんな彼が昨年11月に新著を出版したというので、ほぼその日に買いました。……ですが、本を開いてみる
Why Is SQLite Coded In C
Note: Sections 2.0 and 3.0 of this article were added in response to comments on Hacker News and Reddit. Since its inception on 2000-05-29, SQLite has been implemented in generic C. C was and continues to be the best language for implementing a software library like SQLite. There are no plans to recode SQLite in any other programming language at this time. The reasons why C is the best language to
2020/5/13追記 オブジェクト指向と哲学の関係について書いた記事ではないです。せっかくだしQiitaっぽいタイトルつけようと思ったら結果的に釣りっぽくなってしまった 概要 オブジェクト指向とは何か？ということを真面目に調べていくと、オブジェクト指向には二種類ある、という話に突き当たる。sumim氏のQuora回答などを参照。 Smalltalkの設計者アラン・ケイによる、メッセージング重視のオブジェクト指向 C++の設計者ストラウストラップによる、クラス重視のオブジェクト指向 今回はこの前者のオブジェクト指向について、アラン・ケイの書きものを読んで調べた結果をまとめ、コメントを付す。 参考文献は最後にまとめて出す。参照元は「（AOO）」のように略記で示す。 アラン・ケイのオブジェクト指向 OOPは私にとって、メッセージング、状態処理の局所的な保持・保護と隠蔽、そしてあらゆる事象の徹底
オブジェクト指向のハードコア
オブジェクト指向のハードコアは2019年5月25日にゼロベースサロンで行われたイベントです。「オブジェクト指向」というキーワードについて、プログラミング、デザイン、哲学などの分野を横断しつつ知的な議論ができました。記録映像は必見。 企画意図／招待状 この研究会の企画意図については、私が送った招待状を見ていただくのが早いでしょう： いくつか異なる分野で「オブジェクト指向」がキーワードとして注目されています。昨年からGUIデザインの分野では「オブジェクト指向ユーザーインターフェイス」(OOUI)の議論がホットです。ソフトウェア開発の分野では、数年前からオブジェクト指向の見直しとしての「ドメイン駆動設計」(DDD)が広まっています（※原著である英語版から日本語への翻訳は数年遅れています）。さらには「オブジェクト指向存在論」(OOO)も思想業界でブームになっています。 これはもうオブジェクト指向の
SQLiteの公式Webサイトに、SQLite3をWebAssembly化した「SQLite3 WASM/JS」プロジェクトのページが公開されました。 これまでさまざまなWebAssembly版SQLiteの試みが行われてきたなかで、初めてSQLiteの正式なサブプロジェクトとして開発されるWebAssembly版SQLiteになります。 下記はドキュメント「About the sqlite3 WASM/JS Subproject」からの引用です。 this subproject is the first effort "officially" associated with the SQLite project, created with the goal of making WASM builds of the library first-class members of the fa
"Object-Oriented Conference 2024" の登壇資料です。 https://ooc.connpass.com/event/305241/
Object Oriented Conference 2024 登壇の機会をいただいたので、ここ数年、設計について考えていることを、言語化してみました。 はじめに 設計と開発プロセスの関係性 ソフトウェア設計の知識と技能 ① ソフトウェア設計の基礎知識 a. 基本課題 b. 解決のアプローチ c. モジュール化：基本となる４つの技法 ② モジュール化 a. モジュールの分類 b. オブジェクト指向プログラミングのモジュール化 c. ドメイン駆動設計のモジュール化 ③アプリケーションのモジュール構成（参照モデル） コア（中心） ポート（境界） アダプタ（周辺） ④モデル駆動設計 全体 事業活動、要件、アーキテクチャ コア（中央） 業務ロジック、ドメインモデル 業務機能、アプリケーションサービス アダプター（周辺） 記録モデル、データベーススキーマ 連係モデル、プロトコル設計 対話モデル、イン
現実世界の事象から学ぶSOLID原則
# Object-Oriented Conference 2024 https://fortee.jp/oocon-2024/proposal/e1eb34cf-78ef-43f6-8a03-bb26c996cb62 概要 オブジェクト指向プログラミング (OOP) のコーディング慣例として広く採用される、SOLIDの原則。 コードの保守性、拡張性、再利用性を語る上では共通言語としても使用される一方で、初学者にとっては決して理解のしやすいものではありません。 これらの原則が抽象的であり、実際のコードにどのように適用されるか・適用した際に得られるメリットを理解するのが難しいことが理解を困難にする一因です。 しかし一度理解すると、SOLID原則が現実世界のありとあらゆる場所で適用されていることに気が付くはずです。 「clean architecture 達人に学ぶソフトウェアの構造と設計」にお
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
オブジェクト指向プログラミング -- 1兆ドル規模の大失敗
エンジニアリングの必須図書 40冊 2023年版
マイクロサービス設計原則: SOLIDではなくIDEALS
新人さんにすすめる有益な技術書達 2022春 - Qiita
現代のオブジェクト指向の class の割れ窓化と宣言的プログラミング
僕とDDDとClean ArchitectureとやっぱりDDD - kenfdev’s blog
CSSは奥が深い！セレクタの書き方・命名や管理を改善する5つの原則
オブジェクト指向は必要なのか / Is object-oriented needed?
プログラミング言語論入門 - riswu’s blog
時代がstaticおじさんに追いついてきた(追記あり) - きしだのHatena
レイヤードアーキテクチャ - kawasima
教える側が知らないプログラミングの３つのこと
脱オブジェクト指向講座(5分LT資料)
オブジェクト指向プログラミングは終わった - Qiita
Introduction - Rust Design Patterns
再帰的な構造のデータの同値性判定はどうしたらいいか - 貳佰伍拾陸夜日記
"The Essence of Software"が提唱する全く新しいソフトウェア設計の考え方｜Idein株式会社
「アラン・ケイの」オブジェクト指向とは何だったか？元哲学者のエンジニアがまとめてみた - Qiita
SQLiteの正式なWebAssembly版「SQLite3 WASM/JS」が登場
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
設計の知識と技能で駆動するソフトウェア開発