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

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

写真は妻が作った雪だるまです。 From: 株式会社Kaizen Platform 2/28が最終出社日でした やってたこと Webフロントエンド SPA開発 (React/TypeScript) Schema-first GraphQLによるAPI仕様中心開発の整備 UX/UI設計 Webパフォーマンス計測、改善 その他 lacolaco.hatenablog.com To: bitbank株式会社 4月から入社します 週4日にしてもらいました 空いた1日はClassiでの技術顧問とOSS、個人開発などに使います やりたいこと ある程度の規模に育ったAngularアプリの開発に関わりたい Angularのエキスパートとして持てる力を尽くしてチームを加速させたい Web技術とブロックチェーンのこれからについて、持論を持てる程度の学びを得たい ついでにマイクロペイメントまで学びを得られたら嬉

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

この記事ではAngularDart/Flutterの文脈で新しいコンポーネント設計パターンとして広まりつつあるBLoCパターンを、Angularの語彙で理解し、実装する方法を紹介する。 BLoCパターンとは BLoCとは、Business Logic Componentの略である。 BLoCを使ったアプリケーションの実装パターンをBLoCパターンと呼ぶ。 まず誤解を招きそうなポイントとして、この"Component"はReactやAngularなどでいうところのビューを構築する"コンポーネント"ではない。 一般的な単語としての、アプリケーションを構成するひとかたまりの要素という意味の"Component"なので誤解しないこと。 対比するレベルとしては、"UI Component" vs "Business Logic Component"のようになる。 BLoCは複数の環境向けにアプリケー

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

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

mizchi.hatenablog.com エモにはエモ。 わかる だいたいわかる。そもそもSPAの必須パーツであるクライアントサイドルーティングなんてブラウザ機能の再実装の極致だし、ブラウザ上でアプリケーション作るとなるとブラウザに足りてない部分はラップして、アプリケーションプラットフォームにしたてる必要がある。 Angularはアプリケーションフレームワークとして、HTMLの限界をカバーするために独自にHTMLのパーサーを積んでいる。 テンプレート構文をサポートするためでもあるが、おそらく中途半端にブラウザの機能に頼ってデータモデルからビューへの投影にノイズが含まれるよりは、 Angularという世界に閉じた一気通貫なフローを採用して、ブラウザとのコミュニーケーションを最小限にしたかったのも大きいと思う。 というか、Native ScriptとかWeb WorkerとかSSRとか、クロ

自作のライブラリのCIをCircleCIからGitHub Actionsへ移行したメモ github.com github.com 特にメリットがあるから乗り換えたとかいうわけでもないけど、GitHubだけで完結するならそれに越したことはない ファイルの場所 .github/workflows/<ワークフローの名前>.yml だが、いまのところ複数作るユースケースが見えないので main.yml とした。 実行環境 ubuntu-latest を選択した。特に理由はないけど一応MacOSやWindowsも選べるっぽい？ Software in virtual environments for GitHub Actions - GitHub Help を見るとわかるが、 めちゃくちゃ充実したプリインのソフトウェアがある。 yarn や Git、Docker、Chromeもなんの設定もなく最初

次世代Webカンファレンス、お疲れ様でした！ nextwebconf.connpass.com ありがたいことに2015年に続き、フロントエンドのセッションで登壇させてもらいました。 楽しかったですが、やはり80分のなかで話せることは限られますね... 次世代らしい話を求める期待に応えられたかはわからないですが、僕個人としては「まだ話せたな」というのは正直なところですね。 kobaさん、kazuponさん、takanoripeさんとはまたじっくり話したいです。 動画はYouTubeにアップロードされています。 www.youtube.com 内容の振り返りはひとりでやっても仕方ないので、当日に備えて用意していたネタ帳を一部公開してみます。 Webアプリケーション開発における "当たり前" の水準の変化 ちょっとだけ話せたネタ 型がある開発は当たり前になってきた 状態管理というものを気にする

タイトルのとおり、AngularのGoogle Developers Expertsになりました！ https://developers.google.com/experts/people/suguru-inatomi Angular GDEは世界では82人目になるようですが、日本では僕が初めてです。やったぜ！ github.com まだ高専生だったころ、2013年にGDGのGoogle I/O 報告会九州会場に参加して、そこではじめてGDEを知りました。 それからずっとGDEに憧れていたので、5年越しにひとつ夢が叶いました。大好きなAngularでGDEになれて本当に嬉しいです。 プログラムの進行をサポートしてくれたGoogleのえーじさんやたくおさん、面接に協力してくれたGDEのFilipさんとAngular TeamのStephenには大感謝です。 Angular GDEはWeb G

僕は誰かに褒められたとき、謙遜しないようにしている。 褒められたら「ありがとうございます」「嬉しいです」「照れます」と、はっきり言葉で喜びを示す。 これを心がけはじめた最初のころは意識的だったけど、最近では意識しなくても自然にそう振る舞えるようになった。 これまで何人かに、「それいいですね」と言われることがあって、そういえばこの自分ルールについてちゃんと言葉にしたことがなかったなと思ってこの記事を書いている。 褒めたいと思ったあなたを否定しない 「謙遜しない」というルールの根幹は、「褒めたいと思ったあなたを否定しない」ということ。 褒めてもらったことが、自分が本当に認められたいことではないときもある。あるいは、何気なくやったことで自分ではそれほど価値を感じていないことのときもある。 それでも、相手が自分を褒めたいと思ったそのことはその人にとって疑いようのない事実である。「そう思った」という

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

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

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

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