A collaborative AI workspace, built on your company context. Build and orchestrate agents right alongside your team's projects, meetings, and connected apps.
Clean Architectureという本とBuilding Evolutionary Architecturesという本を最近読んだのでざっくりとしたメモ。（両方共2-3時間ぐらいでざっくりとしか読んでないので、解釈間違いは普通にありそうです） 両方共アーキテクチャに対するメタ的な視点な部分があるので、合わせて読むと面白いかも。 Clean Architecture(Clean Codeの人のシリーズ)という本を読んだ。 Clean Architecture: A Craftsman’s Guide to Software Structure and Design | InformIT PDFとかEpubとかMobiが買える Robert C. MartinのClean *シリーズでいわゆるクリーンアーキテクチャそのものだけを扱ったという内容ではない。 でもクリーンアーキテクチャについ
ここ一年ほど、Fira Codeというオープンソースのコーディング用フォントを使っていて、Font Liguatureを使った==や'>='の表示が、慣れると等号関係が非常にわかりやすくなり、とても気に入っています。特にJavaScriptやTypeScriptなどで===と==の違いや、!==と!=の違いを際立たせてくれるので、これらの言語を書く機会がある人は試してみる価値があると思います。 本記事では、そんなFira Codeと、実際にエディタやIDE（個人的にエディタはVSC、IDEはIntelliJを使っています）への設定方法を紹介します。 Fira Codeって？ Fira CodeはFont Ligature（日本語では合字というそうです）を使ったコーディング向けのフォントで、オープンソースで開発・提供されています。以下の公式のレポジトリ画像を見るとわかるのですが、比例関係(<
この記事は、社内向けに書いた資料を公開の許可を得て加筆修正したものです。 記事中の具体例やサンプルコードはJavaScript/TypeScriptで書かれていますが、内容自体は言語にかかわらず使えます。 同僚の @shisama にも手伝っていただきました。 はじめに 命名について 条件式について 関数について 変数・定数について コメントについて 2020/11/02 ついに完結！ はじめに 読みやすいコードは、コメントがなくても文章を読むように理解できます。 逆に、読みにくいコードはコメントがあってもさっぱり意味がわかりません。 文章を読むように理解できるコードを書くために普段気をつけていることや、コードレビューの際に重点的に見ているところをまとめました。 普段から読みやすいコードを心がけている方にとっては何も目新しい物はなく、当たり前に意識しているであろうことばかりです。 特にプロ
自分の成果物を「ゴミ」「クズ」「底辺」と表現して卑下する人がいるが、よくない。具体的には以下。ちなみに作っている物自体はとても良いなあ、と思っていて、僕なんかプログラミング勉強して２ヶ月の頃、おそらくphpMyAdminを起動させて「わかんねえな」って画面の前で呆然としていただけだったはず。 自分にも「初心者の〜」とかそういう接頭句つけた時期があったのでわかるけど、こういった卑下をするのは大体、「自信がないけど成果物をオープンにしたくて、上級者から何か言われた時の免罪符にしたい」から。 なんだけど、大体意味がないし、自分にとって良くない影響がある。 こういう言葉を使って自分の成果物を世に出す経験を繰り返してしまうと、「この程度のクオリティでも"劣ってる可能性があるのはわかってます"って姿勢さえ表明しておけば良いだろう」って心理がうっすらと働いてしまい、無意識に自分の成果物に限界を作ってしま
はじめに コードリーディングの重要性はそこらじゅうで語り尽くされてる感があります。 僕も地道にコードリーディングをしているのですが、いざやろうとするとハードルが高いことがままあります。そこで、個人的にコードリーディングがはかどったと感じたテクニックをまとめておこうと思います。 筆者環境の前提 ソースコードのバージョン管理は Git を使っている 開発 PC は Mac を使っている エディタは Vim を使っている ghq + peco で読みたいリポジトリに気軽にたどり着く 読みたいソースコードのリポジトリが増えてくると、ローカル環境でのリポジトリをどのディレクトリに置くか、またいざ読もうとするときにディレクトリを辿っていくのが煩雑になってきます。 そんな時、読みたいリポジトリに気軽にたどり着くことができれば、読むハードルが下がります。 僕は peco と ghq の組み合わせを使ってい
はじめに try! Swift ではじめてDTO、POSOという言葉を聞いて、Entityとの違いとかよくわからなかったので調べてみた。 すると、類似の用語が5つでてきた。 VO (Value Object) DTO (Data Transfer Object) POSO (Plain Old Swift Object) JavaだとPOJO (Plain Old Java Object) DAO (Data Access Object) Entity いずれもシンプルに関連するデータをまとめたobjectだが、微妙に性質が異なる。 VO (Value Object) getterのみ 不変 DTO (Data Transfer Object) VO + setter 可変。外から変更可能 異なるレイヤー間（モデル層、ビュー層など）でデータを受け渡すのに使う POSO (Plain Old
iOSオールスターズ2 https://eventdots.jp/event/602872
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Functional and Reactive Domain Modelingとは、ドメイン駆動設計(DDD)の関数型プログラミング(FP)とリアクティブプログラミング(RP)によるアプローチを書いた本 1. 関数型ドメインモデリング：イントロダクション 変更可能なステートを避ける - 変更可能なステートは管理が難しく、非決定性につながる 参照透過性 - FPは、参照透過なモデルコンポーネントを設計する能力を提供する。モデルの振る舞いが純粋関数で構築されていることで合成性を得られ、小さな関数から大きな関数を作ることができる 自律的成長
Debasish (দেবাশিস্) Ghosh 🇮🇳 @debasishg Programmer. Author: Functional and Reactive Domain Modeling (Manning 2016), DSLs In Action (Manning 2010). Father. Husband. Seinfeld fanboy. FP aficionado. https://t.co/iMNdBBtBQC Debasish (দেবাশিস্) Ghosh 🇮🇳 @debasishg The first talk @ScalaMatsuri has numerous references to shapeless, scalaz, Prisms & Iso .. What can go wrong from here ? 2016-01-30 10:4
@joker1007さんが激推ししてたのでオブジェクト指向設計実践ガイド ～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方を読んだ。 なんかすんませんw Sandi Metz本はここ数年でトップクラスに良い本だったのでオススメです。 #railsdm— ジョーカー (onkさんに返済完了) (@joker1007) 2017年12月9日 内容としては、オブジェクト指向設計の核となるものを初めての人でもわかりやすく理解できるように書かれた本という感じ。 この手の本は静的型付け言語でかかれたものが多いがRubyで書かれてるのでゆるふわなwebエンジニアにも読みやすそう。 流行りのDDDをやるにもまずオブジェクト指向がしっかり理解できてないと厳しいし、まずはしっかり土台を固めようぜみたいな。 オブジェクト指向を理解した気になっている人とか、新卒で入社してきたwebエンジニア諸氏に
本エントリーでは次の点を整理したいと思います。 ServiceLocatorパターンとは何か？ Dependency Injection（以降DI）パターンとは何か？ DI Containerとは何か？ これらを使うと何がうれしいのか？ ServiceLocatorとDI何が違うのか？ ServiceLocatorとDIどちらを使うべきか？ はじめに 問題点 利用箇所の結合度をさげる 生成箇所の結合度をさげる ServiceLocatorパターン Dependency Injectionパターンを使う Dependency Injection Container ServiceLocatorとDependency Injection いずれを利用すべきか？ 本来不要であるServiceLocatorへの依存が発生してしまう 依存関係が分かりにくくなる テストが困難になる はじめに さて現代
会社にて「Service Locator パターン」という単語を聞いて「？」となったので、戒めも含めて調べてみたメモ。 いきなり結論 結論から言うと、Service Locator パターンも Dependency Injection (いわゆる DI )と同じようにクラス間の密結合度を緩和するためのものと考えてよさそう。 というか、こちらに超参考になる記述があるので、これを備忘録として残しておく。 概要 DDDとかの Repository パターンで DI を使用することがあるが、それと同じような目的で使用できる。 なんちゃってサンプルコード ここでは、ドメイン層がインフラ層に依存しないように Repository パターンを使用する場合の、 DI 版と Service Locator 版をそれぞれ考えてみる。 DI 使用したときの Repository パターン // アプリケーション
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
