Angular を勉強中のとある学生から質問をもらった。いい質問だったので将来同じことを疑問に思う人のためにも書き残しておこうと思う。 なぜプロパティバインディングと属性バインディングは分かれているのか「属性は HTML タグに付与する情報で、プロパティは DOM 要素に紐づくものだということはわかっているけど、データバインディングにおいてこれを区別する必要がなぜあるのか？」という質問をもらった。 これに対して、要約すると「対応するプロパティがない属性や、属性とプロパティで名前が異なる場合があり、そういうときに属性バインディングでしかバインディングできないから」というように答えた。 公式ドキュメントでは 属性、クラス、スタイルのバインディングに記載がある。 https://angular.jp/guide/attribute-binding プロパティバインディングと属性バインディングプロ

Gitを用いた開発作業を行う際、意図がわからないメッセージのコミットを積み重ねていくと、コミットログを見る人の負担が増えたり、コミットログを活用する習慣がなくなっていき、開発効率の低下を招きます。この...

@1000ch です、今回は新しいメルカリ Web について書きます。この大きなプロジェクトのリリースは、多くの人の多大なる貢献によって成されたものです。そのプロジェクトの立ち上がりから今日まで、リードする役割でプロジェクトを見てきた一部始終を記録するべく書きます。 メルカリにおけるレガシーなソフトウェア ソフトウェアは生モノとよく言われますが、古くなったソフトウェアとどう付き合っていくかは、どの開発組織も抱えている、あるいはいつかはぶつかる課題なのではないかと思います。多くの方々に利用して頂くためには大規模なソフトウェア群を開発し運用する必要があります。しかし、はじめから全てを見越して完璧なアーキテクチャを構築するのは不可能であり、それをビジネスの成長に耐えうるものにソフトウェアを成長させていくのがエンジニアリングの責務です。 2013 年にスタートしたメルカリに於いても例外はなく、急速

視座の可視化というこの記事がめちゃくちゃ好きで、たまに読み返している。 note.com ここに書いてある、課題があった時のアクションのレベルみたいな話がわかる~~~って感じで好き。 具体的には何らかの課題があったときに下記のどのアクションをするか判断できそうです。 ・ そもそも気づいていない ・ 認知してる（けど言語化できない） ・ 問題指摘する ・ 解決策を提示する ・ 解決する 自分の経験だと、「問題指摘する」と「解決策を提示する」の間に結構隔たりがあって、指摘したら物事が前に進むと感じている人が意外と多い気がする。 また、問題を指摘してるつもりで、実は問題を把握できてなかったり適切に指摘できてないケースも多い。例えばあまり理にかなっていないと感じる制度に対して「これなんでずっとこうなってるのか謎」「こう変えればいいのに」とコメントしたとして、これは問題の指摘と言えるだろうか。これは

プロダクト開発や技術に関わっていると数多の問題と向き合うことになる。ブルドーザー業務は楽しい、いろんなこといろんな手段で解決する。デザインからAWSまで、技術でも物理でも何でも振り回して状況を変える起点となるのは楽しい。一方でマネージャーとしても同じような・またはより高品質に「解決できる人を作ること」が求められていることへのジレンマについて整理したい。 「解決できる人」をつくる解決者のジレンマ問題を解決する人＝解決者は大体は「自分で解決したい」と思っている。それは解決したい課題があり、それに挑戦することや解決した実績を作りたいと思っている。私もそう。一方でキャリアにおけるある地点、とくにマネージャーになるという地点からこれがガラッと変わる。「解決できる人を作ること」が求められ始める。指示者・実行者の関係しかない組織でもスケールしていくためには指示者が増えなければいけないからだ。始皇帝の時代