はてなブックマーク

昨年11月末に発売された『Googleのソフトウェアエンジニアリング』を読みました。 Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 細かい内容についての感想はTwitterの方に放流しているので、ブログでは簡単に。 とりあえず一周した。17章以降は基本「いやーGoogleさんすごいっす」という感じだったが、ところどころ役立つ話があったし、「エンジニアリングを発展させていった先の一つの形がこうなのか」という面白さは大きかった。逆に前半は実践的にかなり勉強になったのでちゃんと復習しよう…… #swebookjp— こま (@koma_koma_d) 2022年1月3日 全体の構成 書籍全体の構成は、以下のようになっています。 分量としては、「第4部 ツール」が最も大きな部分を占めています。 第2部から第4部に

あけましておめでとうございます、になるはずだったのですが、後から読んだ『Googleのソフトウェアエンジニアリング』の方を先に記事にしたので新年2本目の更新です。 ky-yk-d.hatenablog.com さて、本題。最近のお気に入りポッドキャストであるe34.fmで激賞されていた『A Philosophy of Software Design』を読みました。初版は2018年に出ていて、今回は2021年に出た第2版を読みました。 スパゲッティコードを想起させる装丁 A Philosophy of Software Design, 2nd Edition (English Edition) 作者:Ousterhout, John K. Amazon scrapbox.io どんな本？ 書籍のテーマはソフトウェアの複雑さです。複雑さとは、システムを理解したり変更したりするのを困難にさせるも

ソフトウェアアーキテクチャに関するプラクティスとして、アーキテクチャデシジョンレコード（Architecture Decision Records, ADR）というものがあります。この記事は、それを組織構造に適用してみるとどうなるだろうと考えてみるものです。100%妄想ですので、予めご了承ください。 （↓妄想が湧いたときのツイート） 組織構造についてのアーキテクチャデシジョンレコード（ADR）というプラクティス、あると助かる場面はありそうだなと思いました— こま (@koma_koma_d) 2021年11月27日 2021/11/30 追記: 数日前に、同じくADRを組織の領域に適用する話が出ていました。 dev.classmethod.jp ADRとは？ 今回の題材である（本家の）ADRとは、以下のようなものです。 テキストベースの軽量なテンプレートを使用して、アーキテクチャ上の設計判

邦訳が待望されていた『Team Topologies』（邦題は『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』。以下、「ちいとぽ」）ですが、発売日（12月1日）を前にして翻訳レビュワーを務められた角谷さんからご恵投いただいた（ありがとうございますありがとうございます）ので、とりあえず一気に読みました。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 作者:マシュー・スケルトン,マニュエル・パイス日本能率協会マネジメントセンターAmazon ※Kindle版も出る予定とのことです。 内容については、すでにiki-ikiやTwitterで色々話を角谷さんから聞いていて、ある程度前提があったのですが、実際に読んでみて印象に残ったことや感じたことを2点ほど記します。 一読した感想を先に記しておくと、この本は、自分一人で読んで、自分の組織について「あのチ

※以下の記事は研修の内容を伝えることを意図したものではなく個人的な感想と学んだことを記載したものです。 Agile Testing for the Whole Team 研修 3/1~3/3の3日間で、アギレルゴコンサルティング主催のオンライン研修「Agile Testing for the Whole Team」に参加してきた。 www.jp.agilergo.com 講師は Janet Gregory（@janetgregoryca） さん。『実践アジャイルテスト』の著者の一人で、最近では『Agile Testing Condensed』という書籍も執筆している（こちらについても既にブロッコリーさん（id:nihonbuson） による邦訳がある）。 実践アジャイルテスト: テスターとアジャイルチームのための実践ガイド 作者:リサ クリスピン,ジャネット グレゴリー翔泳社Amazon

要約 『Clean Architecture』における「単一責任の原則（SRP）」の説明において、アンクル・ボブはコンウェイの法則に言及している。コンウェイの法則によって補強されていると思われるSRPの主張は、2014年のアンクル・ボブのブログ記事において既に現れている。「変更の理由」を「人間」であると同定することは、アンクル・ボブにおけるSRPを一段階踏み込んだ主張にしている。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 作者:Robert C.MartinKADOKAWAAmazon SOLID原則との出会い ソフトウェア開発の世界には、「〇〇原則」や「〇〇法則」といったものが数多く存在している。その中でも、最も著名なものの1つが、SOLID原則であろう。SOLID原則とは、以下の5つの原則の頭文字をとったアクロニムである*1。 Ｓ：単一責任の原則（Sin

前回の記事で、リレーショナルデータベースの役割として、以下の3つを挙げ、ドメイン駆動設計においては最後のものにあまり重きが置かれていないことを指摘した。 集合演算によるリレーションの導出（検索） ディスクへの書き込みによる永続化（蓄積） 各種制約によるデータの整合性の確保 ky-yk-d.hatenablog.com 本記事では、リレーショナルデータベースの特性を改めて検討し、その特性からの帰結としてCQRSとSQLQLを位置付けてみたい。 リレーショナルモデルにおける整合性の確保 整合性の確保をリレーショナルデータベースが担うという発想は、決して新奇なものではない。リレーショナルモデルの父であるコッドの1970年の論文「A Relational Model of Data for Large Data Banks」*1でも、データの整合性（consistency）というテーマが大きく取り

この記事は write-blog-every-week Advent Calendar 2018 11日目の記事です。 前日の記事は、nitt-san（@nitt_san）さんの「インプットからアウトプットへ -2017年〜2018年の自分を振り返る-」でした。 nitt-san.hatenablog.com Angular のルーティング機能を試したい 以前、Vue.jsを勉強していた際に、Vue Routerの「ネストされたルート」を扱う方法を試した。 ky-yk-d.hatenablog.com Vue.jsにおける「ネストされたルート」は、Vue Routerの公式ガイドにも記載されている名称だ。 ネストされたルート | Vue Router 実際のアプリケーションの UI では通常複数のレベルの階層的にネストしたコンポーネントで構成されます。ネストされたコンポーネントの特定の構造

ドメイン駆動設計を意識しながら設計をしている*1ときに、関連テーブルの操作に関して悩んでいたことがあった。人に相談に乗ってもらい、自分でも改めて書籍などを見ながら考え直したところ、自分の集約への理解が全く不十分であったことがわかった。 TL;DR 問い： ある集約への変更のために、関連テーブルへの操作を実体のテーブルへの操作と別に提供したくなったらどうする？ 回答： 集約の単位とは独立に提供したくなるのは集約をちゃんと考えられていないからかもしれないので考え直そう。 前提 「部署」と「社員」という2つの実体*2の間に、「所属」という多対多の関連が存在しているとする。部署は部員として複数の社員を持つことができる一方で、社員は所属先として複数の部署を持つことができる（つまり、兼部を許す）。「所属」を連関エンティティとすることで、以下のようなデータベース設計になっているとする。 このようなデータ

ゲストで出演させてもらった「#成し遂げたいam」のep.8が公開された。前後編に分けて収録したうちの後編である。なお、前編が公開されたときに記事を一本書いているので、ポッドキャスト収録ということについてはそちらもご覧いただきたい。 anchor.fm ky-yk-d.hatenablog.com 後半では、「言葉にこだわる」ということについて喋らせてもらった。意味が曖昧であることが問題になる例として「技術力」を、曖昧さに加えて価値判断が込められていることが問題になる例として「レガシー」をそれぞれ挙げ、適切な言語表現を利用することが思考・コミュニケーションの両面において重要なのではないか、ということを話した。 ep.8の後半*1では、技術者のアウトプット*2について「エモい」という表現が使われるケースについて話している。今回も公開を前にして聴き直させてもらったのだが、「エモ」については言葉足

テスト技術についての資格である「JSTQB認定テスト技術者資格」のテキストを読んだ。読もうと思った理由は後述するが、ソフトウェア開発についての考えに別の光を当ててくれるいい体験になった。 ソフトウェアテスト教科書 JSTQB Foundation 第3版 作者: 大西建児,勝亦匡秀,佐々木方規,鈴木三紀夫,中野直樹,町田欣史,湯本剛,吉澤智美出版社/メーカー: 翔泳社発売日: 2011/11/12メディア: 単行本（ソフトカバー）購入: 5人 クリック: 85回この商品を含むブログ (12件) を見る なぜテストを学ぼうと思ったのか 僕は開発者、プログラマという自己認識をしており、現在の業務の中心はソースコードを書くことだ。また、普段勉強している事柄も、コードの書き方やプログラミング言語についてのものが中心になっている。 しかしながら、今回、テストの勉強をざっとでいいのでしておくべきだと思

前回の記事に引き続き、Vue Routerについての記事となります。 ky-yk-d.hatenablog.com Vue Routerでアクセス制限を実現する 今回は、ナビゲーションガードを利用したアクセス制限を実現するコードを解読していきます。実現したいのは、「特定のパスに対してアクセス制限をかける」ことです。 今回は、コードの中核部分を『基礎から学ぶVue.js』（およびそのサポートページ）に負っています。初心者にわかりやすく、また実践的でもあり、そしてサポートページが実に充実している書籍です。ありがたい。 CHAPTER 9 | 基礎から学ぶ Vue.js 基礎から学ぶ Vue.js 作者: mio出版社/メーカー: シーアンドアール研究所発売日: 2018/05/29メディア: 単行本（ソフトカバー）この商品を含むブログを見る 今回のコードを置いているGitHubリポジトリはこち

APIの定義を書く：Excel仕様書はもういやだ RESTful APIを提供するサーバと、そのAPIを利用するクライアント（たとえばSPA）とを並行で開発しようとするとき、まずAPIを定義して、それに基づいてサーバ／クライアント双方の実装を進めようと考えるのは自然だと思う。 そうと決まれば、「API仕様書_20190110.xlsx」と題するファイルを新規作成し、シート別にリソース毎の定義を書き始め・・・てはいけない。せっかくAPIを定義したドキュメントを作成するなら、するのなら、ソースコードの自動生成などの恩恵も受けたい。受けられるはずだ。 少しググってみる。どうやらSwaggerというものを使えばいいらしい。Swaggerに興味を持ったタイミングで、ちょうど書店に平積みになっていた『WEB+DB PRESS Vol.108』の表紙が目に入った。そこには、「スキーマ駆動Web API開

この記事は、 write-blog-every-week Advent Calendar 2018 24日目の記事です。 昨日の記事は、KIDANI Akito（@kdnakt）さんでした。 kdnakt.hatenablog.com 2017年4月に新卒・未経験で就職した僕にとって、2018年は、エンジニアとして本格的に一歩を踏み出した年になった。仕事で悩んだり、GitHubに草を生やしたり、ブログを書いたり、今までになく活動的な1年だった。中でも、4月下旬から始めたブログは、 きっかけの存在でもあるkakakakakkuさん write-blog-every-week Slackのみなさん の支えもあって、今週に到るまで毎週1回の更新を保つことができており、生活の一部になりつつある。休日ってブログ書くためにあるんでしたよね。 しかし、今回の記事ではブログを中心に据えることはしない。Ad

JS初心者がよくわからないまま書いたLambda 以前、このような記事を書きました。LINEのMessaging APIを用いた簡単なbotの実装の紹介記事です。実はこちらのブログで最も多くのブクマ（16ブクマ）を集めている記事となっています（2018.07.15現在）。 ky-yk-d.hatenablog.com 表題の通り、この記事を書いたのはJavaScriptを触り始めたころです。全体的に、見よう見まねでコーディングしていたのですが、中でも理解できていなかったのはhttpリクエストを送っている箇所です。この部分については完全にコピペ、意味も「あーなんか本文くっつけて送ってんだなー」くらいの理解でした。 記事の執筆から2ヶ月弱が経ち、この箇所について多少なりともわかってきたので、かつての自分と同レベルの方（来月くらいには自分もまたそこに戻っているかもしれない・・・）のためにメモを残

前回のLINE Bot作成に引き続き、AWS関連です。Webアプリ側に寄せています。 ky-yk-d.hatenablog.com 前回やったこと 今回やること Amazon Dynamo DB の設定 AWS Lambda の設定 Amazon API Gateway の設定 Webページ（HTML & JavaScript）の作成 送信ボタンの処理 取得ボタンの処理 仕上げ（CORSの有効化） 終わりに 前回やったこと API Gateway からLambda関数を呼び出す 今回やること Lambdaの裏側にDynamoDBを置く（前回はLambda側に全て記載されていた） WebページからJavaScriptでAPI GatewayのAPIを叩く 新たなデータを作成する/取得した結果を表示する LINEボットを作成して、 API GatewayからLambda関数を呼び出す流れはわか

この記事は、#セイチョウ・ジャーニー Advent Calendar 9日目の記事です。 前日の記事は、べこ（@becolomochi）さんの「仕事を通して成長について考えてみた」でした。 note.mu 「成長とは習慣の改善である」？ 2018年10月8日に開催された「技術書典5」において、「Growthfaction」というサークルから『セイチョウ・ジャーニー』が頒布された。 booth.pm 僕はこのサークルのメンバーではないが、知人が複数関わっていることから、「付録A みんなのセイチョウ・ジャーニー」に寄稿をさせていただいた。指定のテーマである「あなたにとっての成長とは」という問いに対して、下記のように書いた。 悪い習慣を捨てて、良い習慣を身に付けること。そして、身に付けた良い習慣をより優れた習慣にすることです*1。 寄稿をしてから、このテーマについては折に触れて再考する機会があっ

"Unlearn"という言葉は、どれだけの人にとって馴染みのあるものだろうか。 僕はこの言葉に、学生時代に出会っている。教育学系の大学院にいたので、自分自身の研究テーマとは離れているものの、「学び」とは何かというような議論にも接することがあった。その中で、「Unlearn=学びほぐし」という言葉遣いがなされていたことを記憶していた。 今年になってから、この言葉に複数回接することがあり、少しこのUnlearnについて調べてみた。この記事では、この辺りの経緯と途中経過としてまとめておく。問題意識に導かれることも、学術的に網羅性を考慮して調査をしたわけではないので、あくまで覚書である。 日本のアジャイルの文脈でのUnlearnとの再会 野中郁次郎と竹内弘高におけるUnlearn 鶴見俊輔の「まなびほぐし」 一般的な英単語としてのUnlearn 終わりに 参考文献 日本のアジャイルの文脈でのUnl

前回UdemyのVue.jsのコースについての記事を書きましたが、続きがなかなか視聴できていないので、今週はそれとは違う内容になります。少々お待ちください・・・。 さて、ブログを始めたくらいの時期からこれまで、フロントエンドの勉強を細々と続けてきました。 GitHub Pagesで静的Webサイトを公開したり ky-yk-d.hatenablog.com twitter:cardやog:imageを設定してみたり ky-yk-d.hatenablog.com Dynamo DBに繋いでみたり ky-yk-d.hatenablog.com と、少しずつ知識は広がってきていますが、その中で、チラチラと目に入りながらも避けてきたものがあります。 それは、Webpackです。 公式のホームページかっこいいですね。 webpack.js.org 単にWebサイトの基本やVue.jsの文法を学ぶだけな

はじめに 相も変わらず、雑記である。言いたいことは、タイトルの通りである。内容は、職場をより良くしたいという思いを持った人間の反省である。全編通して自分語りの色合いが濃いので、職場改善に興味のある方でもこの記事は読みづらいと思う。人に伝える価値のあるだけの事柄が自分語りに含まれていると信じるからこそ公開するのであるが、最低限の仕事として、職場の改善に関心のある方には下記の2冊の本を勧めておきたい。 カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで 作者: 市谷聡啓,新井剛出版社/メーカー: 翔泳社発売日: 2018/02/07メディア: 単行本（ソフトカバー）この商品を含むブログ (2件) を見る Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン 作者: Mary Lynn Manns,Linda Rising,川口恭

Martin Fowlerの『リファクタリング』で紹介されているKent Beckの言葉として以下のようなものがある。 僕は、偉大なプログラマなんかじゃない。偉大な習慣を身につけたプログラマなんだ。 この言葉について少し調べてみたところ、思うところ／学ぶところがあった。 身につけることのできる「偉大」 この引用句、原文（わざわざ手に入れることはしなかったので、孫引きにはなる）においては、以下のようになっているらしい。 I'm not a great programmer; I'm just a good programmer with great habits. Kent Beck - Wikiquote この言葉の最大のポイントは、"great"という形容詞で（自らを示す）プログラマを修飾するのではなく、（自らが身につけた）習慣を修飾するように「ずらし」ているところだろう。「偉大なのは自

8月23日の夕方から、「きょん、やっとむ、ryuzeeらと語るアジャイル開発の本質」（@デンソー東京支社）に参加してきた。 connpass.com イベントレポート的なものは、別にまとめている。本記事は、イベントに参加した感想として書き始めたが、感想の域を大幅に越えて、現時点での僕のアジャイルへの認識をまとめるものとなったため、イベントレポートからは独立させることとした。そちらに関心のある方は、下記に貼り付けた記事を参照していただければよいが、アジャイルに造詣の深い方々にはぜひ、本記事で書いた私見に対してのご指摘・ご批判をいただきたいと思っている。なにせ、僕はアジャイル非実践者であり、誤解や表面的な理解をしていると思うからだ。 ky-yk-d.hatenablog.com （2018.08.27追記） 良質なイベントレポートを公開してくださった方がいらっしゃったので、ご紹介します。 ba