コードレビューに限らず、いろいろなレビューがいろいろなプロセスに組み込まれている。 だが、レビューにおいて、たとえ内容に瑕疵があっても承認されるなら、そのレビューは単なる形式・儀式に過ぎない。 "何かを保障するためのプロセス"としてのレビューを機能させることを目的とするなら、そこには却下の可能性があることが必要条件だ。 保障: ある状態がそこなわれることのないように、保護し守ること。(https://kotobank.jp/word/%E4%BF%9D%E9%9A%9C-630029) 却下と批判的立場 そのようなレビューにおいて、レビュアーは「これは承認しても大丈夫か」と思考する。 「承認しても大丈夫だ」という確信を得るということは、裏返せば「却下すべき理由がない」という確信を得ることである。 その確信が得られるのは「却下すべき理由を探したが見つからなかった」ときである。 つまりレビュア

発見したつもりだが、すでに周知のことかもしれない。が、少なくとも私には知られていなかった。全文はScrapboxに。 scrapbox.io TL;DR システムの構造を変更するほうが組織の構造を変更するよりも困難である場合、組織の構造はむしろシステムの構造から優越的に影響を受ける 「コンウェイの法則の反転現象」と呼ぶものについて システムの構造と組織の構造がミスマッチしたとき、システムの構造を変化することが容易でなければ、組織の構造のほうが適応してしまう システム開発能力の養成が不十分なまま内製化を進める組織においては、この反転現象が起こりやすい また、ソフトウェア開発現場のアジャイル化はこの現象をさらに促進するだろう アジャイルな組織とは変更容易性の高い組織であるため、相対的に必然的に組織の構造のほうが適応しやすい この現象によって、逆コンウェイ戦略を狙ってシステム構造の改善をめがけた

根本の問題意識 ソフトウェアの設計スキルはどのように獲得する（させる）ことが効果的であるのか ソフトウェアアーキテクチャの目的 そもそもソフトウェアアーキテクチャはどのような欲望を満たすための方法か ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するための必要な人材を最小限に抑えること である。 (CLEAN ARCHITECTURE) 「求められるシステムを構築・保守するための必要な人材を最小限に抑えたい」 => 構築容易性 と 保守容易性 を確保したい 構築容易性 「構築しやすさ」とは？ ソフトウェアを構築するとはどういうことか ソフトウェアの2つの価値: 「振る舞い」と「構造」 振る舞い: 要件を満たすこと => いわゆる機能 構造: 振る舞いを簡単に変更できること => いわゆるアーキテクチャ 構築しやすさ=価値の生み出しやすさ 要件を満たしながら振る舞いを変更

調べれば大抵の情報は誰でも手に入る今日このごろ。特に技術的な情報はオープンソースで一次情報へのアクセスは容易になった。 それと同時に繰り返し言われるアウトプットの重要性。 しかし、ブログやLTなどでアウトプットしても、「もっと質のいい情報があるのに自分がアウトプットする必要があるのか」「逆にノイズになるだけじゃないか」というような考えになってしまう人もいるのではないか。 そんな架空の声にお応えして、それでもなおあえて、一次情報ではない「あなたのアウトプット」の重要性を伝えてみようと思う。 実際にやる人は多くない 定量的なデータがあるわけではないが、直感的に共感してもらえるだろう。 ある技術や手法が話題になったとして、それを情報として知っている人はこの時代いくらでもいる。 だが、それを実際にその手でやったことがあるというだけでかなり群衆からは抜きん出た経験を持つことになる。 ましてやそれをや

有言実行しなきゃね... ちょっと来月の頭くらいまでに、「本当にAngularは学習コストが高いのか？」っていう内容のブログを書くので、書いてなかったら怒ってください— lacolaco / Suguru Inatomi (@laco2net) 2019年1月24日 この記事では、「学習コストが高い」と評されがちなAngularについて、本当にその学習コストは高いのかということについて紐解いていきます。 先に言っておきますが、ReactやVueをはじめとする他のフレームワークとの比較はしません。また、なかなか本題に入らない回りくどい文章になる予定なので、予めご了承ください。そして筆者はAngularが大好きです。Angularが好きな人間が書いたポジショントークであることは前提として読んでください。 そもそも学習コストとは何だ？ まずはじめに、「学習コスト」って何だ？っていうところから始め

「Angularって静的なWebサイトを吐き出せる技術とかないんですか」という質問を受けることがたびたびあります。 例えばGatsbyやGridsome、Next.js、Nuxt.jsなどのようなものですね。 サーバーサイドレンダリングの仕組みは自体はすでにAngular Universalがありますし技術的に難しいことではないので、コミュニティのなかでAngularベースで静的サイトを作るための新しいフレームワークが生まれてくることはあるかもしれません。 しかし僕の個人的な見解では、少なくともAngularチームが公式に提供することはないと思っています。 ではなぜAngularチームはそこにフォーカスしないのかということについて、今Angularが向かっている方向と一緒に理解してみましょう。 いまあるWebに溶け込んでいく 2017年の後半あたりから、Angularチームの主眼は静的なW

技術的に誤った認識でnot for meされるのは悲しいし寂しいので、誤った認識に反論しておきます。 React の過激派(高尚なコードを求める人々)と Vue の過激派(動けば良い人々)と Angular の過激派(オブジェクト指向信仰の人々)— ユーン🍆 (@euxn23) August 7, 2018 何を以ってオブジェクト指向とするかは人それぞれだけど、Angularはオブジェクト指向ではないと個人的には思ってる。 クラス使ってたらオブジェクト指向、というのであればそれは否定できない。 ちなみに過激というかアドバンスドな設計をすればするほどAngularもRxJSをベースにしたリアクティブプログラミングに寄っていく傾向にある。 AngularとAngularFire（FirebaseのAngular向けライブラリ）を使って簡単なアプリケーションでも書いてみれば多少体感できると思う

愚痴。 最近特定の技術やライブラリ、ツールなどに対して、「自分には合わなかった」のような発言をする人をよく見かける。 ちょっと前だと「○○はクソ」のような直接的なdisが目立っていた気がするので、少しは丸くなったつもりなのかもしれないが、 Angularというひとつの技術のユーザーコミュニティを主催する僕としては余計に迷惑だ。 もっと慎重になれ medium.com AirbnbがReact Nativeを使うのをやめた記事、これは本当に偉い。 技術選定を行い、結果的にマッチしなかった、というレポートには、最低限次の項目が必要だと考えている。 開発の目的 選定理由 マッチしなかった理由 このどれが欠けてもいけない。単に言葉遣いが柔らかいだけでdisと変わりないどころか、下手するとFUDにすらなり得る。 FUD - Wikipedia FUD（英: Fear, Uncertainty and

DISCLAIMER: これは本当にただのメモ書きで、これがベストプラクティスだとかいう話ではないので、同じようなことを考えてる人いたら今度議論しましょうよ、って程度の話の種。 GraphQLを使うべきスポット、RESTfulが好ましいスポットについて今日ぼんやり考えていて、なんとなく言語化ができる気がするので文字起こししてみる。 Backend for UsecaseとBackend for Resource バックエンドのAPIには2種類あって、 「データ」を構成する「リソース」を提供するもの アプリケーションの「ユースケース」がもつシナリオのなかで登場する「データ」部分を埋めるためのもの を区別することが必要そう、と思っている。 まず前者を Backend for Resource (BFR)と呼ぶことにする。これはわかりやすくて、これはまさしくRESTfulそのもの。 RDBやそう

常に危機感がある。これは自分が博士号も修士号も持っておらず、第三者から観測可能な価値を持っていないどころか、コンピューターサイエンスの教育を受けたことがないくせにソフトウェアエンジニアとして専門職に就いて生計を立てているのが根底にあるかもしれない。 プログラマーとしてインターネット上で活動しはじめたころからずっとアカデミーに対して劣等感がある。 自分がやっていることなんて高度な教育を受けた人間がちょっと参入してくればあっという間に淘汰されるだろうし、常に風前の灯火っていう感じがしてる。 正直なところ1年後に自分に仕事があるかどうかまったく自信がない。半年後すら曖昧だ。3年後なんてまったく想像もできない。 何をしても足りてない気がするから、毎日生き急いでいるような気がする。 本当は価値がないかもしれないけども、少なくとも価値があると錯覚してもらうために、常に可能な限り優れた成果を出してそれを

Webにかぎらず、アプリケーションというのは作って終わりではなく、その後も継続して改修・改善されていくケースが多い。受託で開発して納品して終わりというケースでも、納品した先にメンテナンスする人がいる。 この記事では、Angularアプリケーションの開発において、いかにメンテナンス性を維持して、持続可能なプロジェクトを構成するかについての個人的な見解をまとめる。 フレームワークを邪魔しない Angularアプリケーションのメンテナンスにおいて、いちばん重要なことはいかにAngularのアップデートを阻害しないかという点に尽きる。 これはAngularに限った話ではなくフレームワークと呼ばれるものを使うなら常に必要なことであるし、 アップデートが定期的に降ってくることが決まっているAngularであればなおさらである。 アプリケーションの一番根幹となる部分の鮮度が落ちれば、その他の部分はそれに

Angular 2から6までの主要な進化をまとめた記事を読みたい。— Masahiko Sakakibara (@rdlabo) 2018年4月20日 逆にIonicの変遷が知りたいですね 最近Stencilも出てきたしその辺の絡みとか俯瞰的に見てみたいです— lacolaco (@laco2net) 2018年4月20日 rdlaboさんがしっかりGW明けにIonicの記事書いてくれたので、僕もAngularのv2からv6まで、3年弱の変遷についてまとめます。 Ionic 2 から 4 への、この2年間の進化を振り返る 前Angular v2時代 Angular v2 オフラインコンパイル AngularJSへの .component 逆輸入 Animation API Language Service Angular CLIとスタイルガイド SystemJSからwebpackへ For