@t_wadaさんが翻訳されていた技術的負債の記事をあらためて読んでみたら非常に面白かった。技術的負債の本来の意味が説明されているので、まだ読んだことがない人は一読をおすすめする。 その翻訳記事を読みながら、Jasper(僕が開発しているGitHub用のIssueリーダー)のv1.0で技術的負債を返済したことを思い出した。そこで、その翻訳記事を参考にして技術的負債の生態について自分なりに考えてみることにした。すると面白い生態がいくつか見えてきた。例えば「生態③: むしろ技術的負債が生まれることそれ自体はポジティブである」などである。今日はそのことについて書いてみようと思う。 ちなみに今回は技術的負債への対処までは解明することができなかった。いつか続きを書けたらいいなと思う。 技術的負債が生まれる背景 まずはJasperで経験した技術的負債を紹介する。負債の内容自体はそんなに重要ではないので
長年、後回しにしてきた「正規表現」。四の五の言わずにはじめようよ!と20年前の自分に伝えたく、まとめてみました。 詳しい方が見ると、乱暴だったり、おかしなところがあると思いますが、入り口に立つことが大切だと考えています(書いた人は文系・グラフィックデザイン関連です)。 はじめにたとえば、文章中に「コンピュータ」と「コンピューター」が混在していて、これを「コンピューター」に統一したいとき、あなたなら、どうしますか? 単純な検索置換なら、次のような順番で処理できます。 ❶「コンピューター」を「コンピュータ」に一括置換する ❷「コンピュータ」を「コンピューター」に一括置換する ❸ ちょっと心配なので「ーー」(音引きの繰り返し)をチェック これはこれでアリなのですが、1回の作業でできたらベターです。 しかし、「コンピュ-タ」のように正しく音引き(ー)が入力されていない場合には単純な検索置換ではお手
はじめにベンチャー企業でのマネージャー歴約10年ですが、10年経ってベンチャー企業に必要なマネジメントノウハウを体系化して、その体系化したものを人に教える仕事をしてます。 体系的にマネジメントを教わることなく、何かが起こるたびに都度経験から学んだり、上司から薫陶を得たり、書籍で学んだりしながら10年掛けて学びました。そして、それら断片的な学びをつなげて体系化しました。 体系化してみたら何のことはない、これが実行できれば必ず成果は出ます。 そして、経験が浅い新米マネージャーであっても、本マニュアルを元に徹底的にトレーニングされれば実行できるようになります。 マネジメントは経験でもセンスでもなく、業務マニュアルとして「型」化し実行可能です。 (本マニュアルはベンチャーに特化しています。ベンチャーという特殊なシチュエーションにフォーカスしなければ業務マニュアルのような各論ではなく一般論に終始して
March 6, 2021 Volume 19, issue 1 PDF The SPACE of Developer Productivity There's more to it than you think. Nicole Forsgren, GitHub Margaret-Anne Storey, University of Victoria Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, Microsoft Research Developer productivity is complex and nuanced, with important implications for software development teams. A clear understanding of defin
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く