日本列島「現代アート」を旅する を読んだ

日本列島「現代アート」を旅する (小学館新書)

なぜ読もうと思ったか

現代アートなんも分からんすぎるので入門書を読みたかった。いくつかの入門系書籍のうち奥さんにオススメされたのがこれ。

どのような本か

著者が選んだ「これだけは絶対見ておきたい傑作10点」を紹介している。全て日本にある。が、全てが日本人の作品というわけではない。

書評というか感想

現代アートというのは本当に難解で、アートの歴史とかアーティストの思想とかその他教養的なものをたくさん知っていないとさっぱり理解できない。というのが現時点での感想なんだけど、この本を読んで現代アートへの理解がほんの少し深まった気がする。多分。

世界的に評価されていて、かつ日本に恒久展示されている作品を題材にしているので、どんなアーティストのどんな作品がどのような理由でどう評価されているのかを知った上で実物を見に行くことができる。これは学習の方法としては効率が良い感じがするので僕みたいな現代アート初心者には役に立ちそう。というか立っている。

実際に、本書で紹介されている三島喜美代の作品を実際に見に行ったところ大変良かった。ART FACTORY城南島というところにあるので関東在住の方はぜひ行ってみて欲しい。無料です。何も知らずに見に行くのもいいけど、個人的にはそのアーティストや作品についての背景をある程度勉強してから行った方が作品の解釈がしやすいし興味が持てて良いと思う。

とりあえず本書で紹介されているイサム・ノグチ、マーク・ロスコ、アントニー・ゴームリー、三島喜美代、ロン・ミュエク、レアンドロ・エルリッヒ、安田侃、ジェームズ・タレル、内藤礼、ウォルター・デ・マリア、このくらいはちゃんと名前覚えて作品の一つくらいは見ておきたい。先は長いが、新しいことを学ぶのは楽しい。アートなんか全く興味もなかった自分を色々連れまわしてくれる奥さんに感謝。

達人プログラマーを読んだ

新装版 達人プログラマー 職人から名匠への道

なぜ読もうと思ったか

有名な書籍だし前から読みたいと思っていたので。  

どのような本か

達人（Pragmatic）プログラマーになるための心構えやテクニックをまとめた本。内容は精神的なものから具体的な技術プラクティスまで多岐に渡る。

書評というか感想

一言で言うと「このタイミングで読んで良かった」というのが感想。

リーダブルコードやアジャイルサムライ を読んだときと同じように、「ああ、これは名著や…名著なんや…」という感覚はあった。ただ、この本をエンジニア１〜２年目に読んでいたらどうだっただろう。同じように感じられたかどうかは定かでない。

というのも、体感的には「分かる〜」と共感できる内容が七割、「そうか〜なるほどな〜」と勉強になるのが二割、残りの一割は「そうなの？うーむ」と考えさせられるような感じだった。もっと未熟な頃に読んでいれば共感できる割合が減ってなんだかよくわからんなーへーという感じで適当に読み流してしまっていたかもしれない。 

1999年出版のこの書籍は控えめに言っても町有名であり、世界中に影響を与えていると思われるので、僕自身もこれまで学んできたことのうち少なくない部分がこの本に端を発している（は大袈裟かもしれないが）。DRY原則とか。なので「分かる〜」となるのは当たり前なわけです。数年かけてこの本の内容を学んできたようなものなのだから。

初学者が本書を読んで、内容を胸に刻んで、さあがんばろう！となるのもそれはそれでいいとは思うけど、個人的には色々わかってきたこのタイミングで読んだことで本書の素晴らしさをより理解できたという風に感じているので、どちらかというと初学者よりは数年〜くらい経験のある方にオススメです。というか多分、みんな読んだ方がいいと思う。内容に同意できるかどうかは別にして。

思ったより読むの大変だったけど、読んで良かったー。

Twitterのスレッドで適当に感想を垂れ流してみた。効果があったかは不明。いくつかリプライをもらえたのは収穫だった。

達人プログラマー読んでる

— inoue (@_SummerTree) 2021年3月28日

神宮の杜芸術祝祭 と LOUIS VUITTON & に行った

行きました。神宮の杜芸術祝祭は明治神宮宝物殿で催されている展示、LOUIS VUITTON &は原宿のjingでやってるエキシビジョン。

まず宝物殿。明治神宮って球場とかがある方しか行ったことがなくて、宝物殿の存在も知らなかった。あとすごく広い公園というか草原？があって、近所の保育園児と思しき子供達が走り回っていた。霊験あらたかなお散歩だな。しかし東京にもこんなに広くて青々とした場所があるんですねえ。

で宝物殿よ。厳かでなかなか格好良い建物。中に入るといくつかの彫刻作品が展示されていた。平櫛田中さんというのは初めて聞く名前だったのだが、どうやら1900年代彫刻界の重鎮のようだ。確かに作品が凄かった。木彫りとは思えない精巧さに思わず舌を巻いた。圧倒的な技術というのは万人を魅了するなあ。

平櫛さん以外は基本的に存命アーティストの作品が展示されていた。宮島達夫、名和晃平の作品が見れてよかった。他の方達のことは全然知らなかったので、少しずつ覚えていきたい。須田悦弘さんという方の作品が面白かったなあ。

宝物殿を出て、歩いて原宿駅の方まで行って「LOUIS VUITTON &」へ。

ブランドにあまり興味がないのでルイ・ヴィトンについてもほとんど何も知らなかったのだけど、創業者は元々トランク職人だったらしい。へえー。それから世界中の様々なアーティストとコラボしていてアーティスティックな作品がたくさんある。全然知らんかった。我らが日本からは村上隆や草間彌生、山本寛斎とか。面白いなー。

ルイ・ヴィトンの歴史というかこれまでの歩みが少しだけ分かった気がした。面白いトランクやバッグもたくさんあったし、アーティストのコラボでは多様なプロダクトがあって格好良かった。ヴィトンに対するイメージが結構変わったかもしれない。

両方ともかなり見応えある展示だったのに、無料。完全無料。宝物殿の方はまあわかるとしても、ヴィトンのこれが無料ってのはだいぶ太っ腹だと思う。面白いので暇な人は行ってみたらいいんじゃないでしょうか。原宿駅すぐそばです。

その後若手アーティストさんの個展にお邪魔して、帰宅。

奥さんに連れられてちょくちょく現代美術を見ているけど、結構楽しい。本当はもっと勉強して知識がついたらもっと面白くなるんだろう。ぼちぼち本でも読んでいきます。

本当は映える写真などを貼り付けた方がブログ的にはいいんだろうけど、僕は写真が苦手なのです…。まあそういうシャレオツな投稿はインスタグラマーの皆さんに任せて僕はダラダラ活字だけで適当に日記を書いていればいいか。苦手なことはやらないのが一番。

LeanとDevOpsの科学 を読んだ

LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ

なぜ読もうと思ったか

オススメしている人が何人か身近にいたので、なんとなく。

どのような本か

超意訳すると、「IT部門のパフォーマンスの高さは、組織全体の業績と高い相関をもつ」と誰もがいうが、大抵何の根拠もない戯言にすぎない。なので、学術的調査・分析方法を用いてガチで研究してみた。そしたら、「ソフトウェアデリバリのパフォーマンスが組織全体の業績に重要な影響を及ぼす」ことが判明したぜ！詳しく説明するからみんなも参考にしてくれよな！な本。ただし実際はもっと堅い。（そして戯言云々は著者の台詞ではない。その辺はご愛嬌）

書評というか感想

思ったよりすごい本だった。

まず、普通のDevOpsとか継続的デリバリの書籍と違うのは、学問の世界で用いられるような厳格な調査研究方法を用いていること。そして、DevOpsやリーンマネジメントが組織の収益性、市場占有率、生産性に良い影響を与える（本書では「予測」、より厳密には「推計予測（inferential prediction）」という言葉を使っている）こと。開発組織のパフォーマンスの測定方法や改善の仕方、さらには組織文化にまで踏み込んでいて、尚且つそれらの相関関係や予測関係もまた全て厳格な調査研究によって分析していることである。

自分でも何言ってるのか分からなくなってきたけど、本文もこのような調子なので結構堅いです。ちょっと読みづらめ。でも内容は本当に素晴らしい。

ソフトウェアデリバリのパフォーマンスを計測するための方法や、その計測結果が組織のパフォーマンス（収益性、生産性、市場占有率）にどのような相関があるか、というのが主題。

前半（〜11章）は組織のパフォーマンスを上げるためのプラクティスと調査結果が解説されていて、めちゃくちゃ読み応えある。後半（12章〜）はどのように調査・分析を行なったのかの説明という感じで、本当は読んだ方がいいけどしんどい人は読み飛ばしてもいいかも。前半の内容がなぜ信頼できるのかを示しているので、大事と言えば大事。

実際本書に書いてあるプラクティスについて言及すると文字数がいくらあっても足りないので、読んでくださいとしか言えません。。が、ものすごくざっくり言うと、「DevOpsとリーンマネジメントのプラクティスをやればソフトウェアデリバリのパフォーマンスのデリバリが上がり、そして組織全体のパフォーマンスも上がる」と言うことなのでDevOpsとリーンをやりましょう。実際には組織文化、継続的デリバリ、リーダーシップ等についてもプラクティスと調査結果があって、その辺もすごく面白いのだけれども。

読んでいると話が色々広がってだんだん訳わからなくなってくるのですが、安心してください。242, 243ページに見開きで全体の相関図が書いてあります。本書の内容が一つの図に全て詰まっているので最終的にはこの図を頭に叩き込めばOK。私も叩き込みます。結構ややこしいけど。

そして、読んでて気づいたけどリーン開発とかリーンマネジメントの本読んだことない。正直あまり分かってない。浅学非才が身に染みているので他にも色々読まなければ。。

この本は現場のエンジニアが読むのももちろん効果的だけれども、マネージャや開発組織を横断的にみているような技術スペシャリスト、ひいては経営者も読んだ方がいいと思う。マジで。そのくらいためになる本です。ただ結構難しいと言うかややこしいので、一回読んだだけでは全部は頭に入ってこない感あります。もう半分以上忘れた。もう一回読まないとなあ。

しかしたまたま手に取った本がすごい本だったので驚いています。もしかして、みんな知ってた…？この本がすごいって、有名…？最近技術書あまり読んでなかったのがよくなかったのかなあ。完全に名著だと思うんだけど全然知らなかった。これから周りにオススメしていきたい。

ちなみに、この本が書かれるきっかけとなったレポート（State of DevOps Report）の本書執筆時の最新版である2017年版はここからダウンロードできるようです。本書には調査研究の生データは載ってなかったけど、こっちには載ってるんだろうか。ちょっと気力がなくて読んでない。2020年版もあるみたいだからそっちを見た方がいいのかもしれない。積読をあといくつか消化したら読んでみよう。

最後に一つ、「組織文化をどう変えていくか」という節が非常に興味深かったので、ここだけ引用しておきたい。

組織文化を変えていく上でまず最初にやるべきなのは、関係者の思考方法を変えることではなく、関係者の言動、つまり皆が何をどう行うかを変えることだ

これはなるほどなーと思った。この言説をもとに、本書では「リーンとアジャイルのプラクティスを実践すれば組織文化に好影響を与えられる」という仮説を掲げ、技術的プラクティスと管理のプラクティスが組織文化にもたらす影響を測定したらしい。結果としてこの二種のプラクティスの実践により文化の改善を図れると。

この辺りの方法論は開発に限らず色々応用できそう。とにかく興味深い本なので折に触れて何度も読み返したい。

独習Java 新版 を読んだ

独習Java 新版

なぜ読もうと思ったか

大学の研究室に置いてあった独習Java（Java 6まで対応だった気がする）を読んで、なるほど、オブジェクト指向ってこういう感じなのかー。へー。なんかわかんないけど便利そうだなあ、などと思ったものの研究が始まってみればそこにあったのはC++で書かれたシミュレーターであった…というのが僕とJavaとの出会いであり、それ以降ほとんどJavaに関わることなく生きてきたのだが、なんやかんや仕事でJavaを使うことになり、じゃあ独習Javaをもう一回読んでみるか！おっ、なんか新版出てるしとりあえずこれ読んでみるかーてなもんです。

どのような本か

Javaを独習するための本。 …というのは冗談で、Javaの基本的な構文から標準クラスライブラリ、マルチスレッドプログラミングあたりまで手広くカバーしている本。Java未経験者でも大丈夫だけどプログラミング自体が未経験だと厳しいかも。サードパーティのライブラリやフレームワークの話はほぼないので、これを読んでもWebサービスとかAndroidアプリは作れません。

書評というか感想

良い。なんか前の版と比べてポップになって読みやすくなっている気がする。サンプルコードも多いし分かりやすいと思った。Java 6の頃から変わらないところは復習になったし、Lambda, Functional Interface, Stream APIあたりであやふやだった知識が整理されて良かった。プログラミング経験はあるけどJavaは未経験、という人にオススメできる本。

この本自体とは関係ないのだが、自分の中でJavaと言ったら「完全未経験の新卒がSIerに入ると最初に研修で覚えさせられる言語」というイメージだったのだが、現代の現場ではJava 8 以降の比較的新しい機能を活用したコードが求められるわけで、未経験者が頑張ってJavaの基本的の構文を覚えたとしてもそれでOptionalやStreamをゴリゴリ使ったコードが書けて読めるか？というと難しそう。僕なんて昔ジェネリクスすら全く理解できなかったし。一応プログラミング自体は研究で多少やっていたにも関わらずですよ。まあ僕の頭が悪いだけという説もあるけど、プログラミング未経験者が3ヶ月やそこらの研修中にCollector.of メソッドのシグネチャとか見たら卒倒してしまうんではないか。

public static <T,A,R> Collector<T,A,R> of(Supplier<A> supplier, 
    BiConsumer<A,T> accumulator, BinaryOperator<A> combiner,
    Function<A,R> finisher, Collector.Characteristics... chara)

うん、僕も卒倒しそう。

まあこんなややこしすぎる見た目のメソッドなんかもちゃんとサンプルコードつきで解説してくれてるのでこの本は良い本です。あと今未経験からプログラミングを始めるなら、JavaよりGoとかRubyとかJavaScriptとかがいいんだろうなーと思いました。知らんけど。

Java ビルドツール入門 を読んだ

Javaビルドツール入門 Maven/Gradle/SBT/Bazel対応

なぜ読もうと思ったか

あまりJavaと関わらずに生きていたのだが最近仕事で使い始めたのもありJava関連の書籍などを眺めていたところ発見。へー、Javaのビルドツールの本とかあるんだな、MavenとGradleは使ったことあるけどSBTとかBazelってなに？似たような技術を比較しながら学ぶのって面白いよなあ。読んでみるか。てな感じです。

どのような本か

完全にタイトル通り。Javaのビルドツール４種についての入門レベルの解説。 １章がビルドツールの基礎知識、２，３章がMaven、４，５章がGradle、６章がSBT、７章がBazel。

書評というか感想

それぞれのビルドツールについて最小構成のプロジェクトからwebアプリケーション、GUIアプリケーション、Spring Bootアプリケーション等のプロジェクトをビルドするサンプルコード付きで丁寧に解説していて非常にわかりやすい。プログラミング初心者でも大丈夫。多分。未経験者は無理。

ただしあくまで入門レベルの解説なので、これを読んだからと言っていきなり商用Webアプリのビルド設定ができるようにはならない。ちゃんと公式サイト等で理解を深める必要がある。この本の意義は複数のビルドツールで同じようなことをするとどのような違いがあるのかがサクッと分かるところであって、それぞれのツールに関してまともに扱えるレベルになることが目的であれば別の本（というか公式ドキュメント）を読んだほうがいい。

自分にとってはMavenもGradleも日本語での解説を読むのが初めてだったこと、SBTとBazelについては全く知らなかったことから楽しく読めました。土日で一気に読めるくらいの分量と難しさ（簡単さ）なのもよかった。

しかし、こういう本を読んでいるとスクリプト言語の手軽さが際立つと言うか、Rubyしかやってない人がこの本を読んだら「えっなんでビルドツールが４つもあるの？なに昔はAntというのがあって？そして他にもまだある？どういうことなの・・・？」とブツブツつぶやきながらrubygems.orgの方角（どっちだよ）に向かって祈らざるを得ないと思う。Gemさえ知ってればいいなんて最高。ありがとうGem。ありがとうcomposer。もしくはnpm、あるいはpip。

こいつらはただのパッケージ管理なのでmavenやgradleと等価ではないのだが、pom.xmlとか書いてるとどうしても「ビルドって大変だなあ」と思ってしまう。Gemfileだけ書いてrails sすればだいたい動く、みたいなのって素敵じゃないですか。スクリプト言語というか、Railsは偉大。この本関係ないけど。

Datadog Agentを手元のマシンで動かして、ローカルのサーバを監視する

Datadogの新しいサービスを使い始めるときやcustom metricsを作りたいとき、まずローカルで動作確認したくなると思う。

「Datadog Agentをローカルで動かす方法」みたいな公式ドキュメントやブログ記事が意外となかったのでやり方をメモしておく。

ApplicationがDocker Containerとして動作する場合

dd-agentの公式イメージを使って、アプリケーションとDatadog Agentを同じネットワーク上で動かせば良い。具体的にはdocker-composeを使うのが簡単。 dd-agentの使い方についてはhttps://docs.datadoghq.com/agent/docker/?tab=standard、別のコンテナからTraceを取得する方法はhttps://docs.datadoghq.com/agent/docker/apm/?tab=linux#tracing-from-other-containersを見れば良いです。

下記は最低限の設定をしたdocker-compose.ymlの例。使っているサービスはAPMのみ。

version: '3.8'

services:
  app:
    ... (略)
  db:
    ... (略)
  datadog-agent:
    image: gcr.io/datadoghq/agent:latest
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /proc/:/host/proc/:ro
      - /sys/fs/cgroup/:/host/sys/fs/cgroup:ro
    environment:
      - DD_API_KEY=<YOUR_API_KEY>
      - DD_APM_ENABLED=true
      - DD_APM_NON_LOCAL_TRAFFIC=true

アプリケーション側でdatadog agentのhost名をdatadog-agentにしましょう。

# Javaの場合
DD_AGENT_HOST=datadog-agent
java -Ddd.agent.host=$DD_AGENT_HOST -jar yourApp.jar

# Rubyだとこう
Datadog.configure do |c|
  c.tracer hostname: 'datadog-agent'
end

// Go
tracer.Start(tracer.WithAgentAddr("datadog-agent"))

あとはdatadog-agentコンテナのログを眺めていればなんとなく動作が分かる。Trace何件送りました、みたいな。これがずっと0件だと何かしら間違っている可能性が高い。

結構簡単でよかった。

ApplicationがDockerizeされていない場合

やったことないけど多分同じ。DD_APM_NON_LOCAL_TRAFFIC=trueは要らなそう。この場合はdocker-compose使う必然性がないので公式に載ってる通りにdocker runすれば良いと思われるが、その場合はagentのポートまで指定したほうが良さそう。デフォルトは8126。

補足

これはローカルからやってるテストですよーってのがちゃんと分かるように、DD_ENVなりなんなりに"local"とか"test"とか入れときましょう。