3月に発売されたばかりの『誤謬論入門 優れた議論の実践ガイド』（原題：Attacking Faulty Reasoning）*1を読んだ。 誤謬論入門　優れた議論の実践ガイド 作者:T・エドワード・デイマー九夏社Amazon 原書は、非形式論理学・クリティカルシンキングの教科書として使われているもので、初版が1980年、今回の翻訳の底本となっている第7版が2013年の出版と、帯に謳われている通りの「ロングセラー」本のようである。 自分はこの分野が専門だったわけでもないのだが、論理学には学生時代少し興味があったし、どうすれば議論を実りのあるもの、平行線を辿らずに済むものにできるかということを意識する機会も多いので、この翻訳本の紹介を見てすぐ予約購入した。 「前件否定の誤謬」や「規範的前提の欠如の誤謬」といった「論理学らしい」誤謬のほかに、「藁人形論法」や「お前だって論法」といったTwitte

この記事は、 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

はじめに 目次 はじめに 目次 GitHubに草を生やして100日目の節目に アウトプット全体をふりかえる ブログ（記事21本）をふりかえる 意図：技術の勉強を駆動する&長い文章を書くために 実績：投稿した記事を一覧にしてふりかえる 感想：ノルマは守れている。しかし、ただそれだけだ。 登壇（5分間LT×2回）をふりかえる 意図：コンフォートゾーンに留まらない 実績：ブログの記事でふりかえる 感想：登壇に必要な安心感、学生症候群 GitHubでの「草生やし」（100日間）をふりかえる 意図：技術から逃げないこと。Write Code Every Day 実績：コントリビューショングラフとTweetでふりかえる 感想：「草」を目的にすることの功罪 おわりに 全体的な感想 今後の方針 ふりかえってみて感じたこと Special Thanks to @kakakakakku GitHubに草を生や

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

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

昨年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 どんな本？ 書籍のテーマはソフトウェアの複雑さです。複雑さとは、システムを理解したり変更したりするのを困難にさせるも