プログラマ行進曲第二章

主にソフトウェア関連の技術をネタにした記事を執筆するためのブログ

Ansibleの変数の優先順位を理解してなくて詰まってしまったという話

TL;DR

基本的に以下の記事の方と同じハマり方をした、という話しです。

qiita.com

詰まった箇所

具体的に言うと、既存のansible roleを使ったplaybookを修正する必要があり、その際デフォルトで以下のようなフラグ変数を用意して、JenkinsのLTSを通常使用するようにしようとしました。

jenkins_lts_use: true

そして、LTSを使用しないサイトでは jenkins_lts_use: false とやって、この変数の値に応じて別の変数(yum repositoryのURLなど)を分岐させるという作りにして動作検証していたところ、 jenkins_lts_use: false とhost_varsに書いたのに上書きされない状態で「何故だ!?」と時間を消費することに。

ちゃんとdebugモジュールを使って変数の値が変わったかどうか確認したところ、私の意図とは違い、 jenkins_lts_use: true という値のままでした。

原因

「これはすっかり忘れてたけど、多分ansibleの変数が使われる優先順位の問題だろうな」と思ったのでインターネットでググったとこ ろ、この記事冒頭で紹介した記事を見つけ、ビンゴでした。

公式ドキュメントでは以下の箇所にあたります。

docs.ansible.com

Here is the order of precedence from least to greatest (the last listed variables winning prioritization):

  • command line values (eg “-u user”)
  • role defaults [1]
  • inventory file or script group vars [2]
  • inventory group_vars/all [3]
  • playbook group_vars/all [3]
  • inventory group_vars/* [3]
  • playbook group_vars/* [3]
  • inventory file or script host vars [2]
  • inventory host_vars/* [3]
  • playbook host_vars/* [3]
  • host facts / cached set_facts [4]
  • play vars
  • play vars_prompt
  • play vars_files
  • role vars (defined in role/vars/main.yml)
  • block vars (only for tasks in block)
  • task vars (only for the task)
  • include_vars
  • set_facts / registered vars
  • role (and include_role) params
  • include params
  • extra vars (always win precedence)

冒頭の記事とこの公式ドキュメントの記述を見た後、私が追加したデフォルト変数はどこに追加したものか確認したところ、role defaults ではなく role vars (defined in role/vars/main.yml) でした。

jenkins_lts_use: false を追加したのは playbook host_vars/* だったので role vars (defined in role/vars/main.yml) より優先順位が低く、この影響で変数が上書きされない状態だったと言うことが分かりました。

jenkins_lts_use: truerole defaults に書くようにして問題解決。

一応対処出来てよかったです。

Ansibleのwhen節で複数行に複数の条件を書くやり方に迷ったので調べた

結論から書くと、以下のように書ける。

when: >
  ('redhat-stable' in repo_url) or
  ('redhat-stable' in repo_key_url) or
  ('redhat-stable' in package_url)

ポイントは以下の通り。以下の説明は細かい検証はしていない or メモしていないので細かい部分で間違っているかもしれないです。

> とか | を使って複数行に書けるようになる

上記のwhenの場合、条件をそれぞれカッコでくくる

そうしないとエラーになった。原因までは調べてない。

when内では変数はそのまま、文字列はクオートでくくる

repo_url がansibleの変数(中身は文字列)の時、 'redhat-stable' in repo_url は問題ないが、 redhat-stable in repo_url はエラーになるということ。

Ansible難しいなと思ったところ

yamlファイル内に書くとき、「こう書きたい」と思った表現が書けるかどうか、以下の知識を持っていないと完全に判断が付けられないところ。

  • Ansible固有の知識
    • when節に書ける法則 etc.
  • Jinja2の知識
  • YAMLの仕様・知識

『FACTFULNESS(ファクトフルネス)』をだいぶ前に読み終えました

平成と令和にかけたゴールデンウィークに突入してるのに「時間が無くて今まで下書き・構想のままのブログ記事書けませんでした」とか流石に言いづらいので、久し振りに書評(というか読書感想)記事を書きます。

題材は、1月の以下の記事を書いたときに読み終えた『FACTFULNESS(ファクトフルネス)』(以下『ファクトフルネス』)です。

FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣

FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣

  • 作者: ハンス・ロスリング,オーラ・ロスリング,アンナ・ロスリング・ロンランド,上杉周作,関美和
  • 出版社/メーカー: 日経BP社
  • 発売日: 2019/01/11
  • メディア: 単行本
  • この商品を含むブログ (1件) を見る

読み終えたのは以下の記事によると2019/01/19ですね。

takuan-osho.hatenablog.com

早めに読書感想のブログ記事を書きたいと思ってます。

こんなふうに書いてから3ヶ月以上経過してしまっていますね。死です。

読んでみての感想

『ビル・ゲイツやバラク・オバマ推薦!』のような宣伝のされ方をしていた書籍ですが、その人たちが推したくなるのも分かる、良い内容の書籍だと思いました。

正直読んだのが3ヶ月前で復習もしていないので細かいことは忘れてしまっているのですが、だいたい以下のようなことが書いてあったかと思います。

  • 世の中にはデータに基づいていない間違った思い込み・言説に溢れている
  • そういった思い込み・言説は大概刺激的で扇情的な内容が含まれていて、ドラマチックすぎる世界の見方を植え付けてしまっている
  • 一般市民だけでなく、世界をリードする指導者や有識者といった高い教育を受けているはずの人ですらそういった思い込み・言説・世界の見方を信じているという現状が今までの(著者の)講演内での質問により明らかになっている
  • このドラマチックすぎる世界の見方は大抵、「世の中はどんどん悪くなっているか、もしくは以前と同じく悪いままで改善されていない」という世界観に満ちているが、データに基づいて見てみれば、そんなことはなく、世界は段々よくなっていることが分かる
  • こういった世界の見方をしてしまうのは10個の人間の本能による影響が強い(ので、これらの本能に自覚的になる必要がある)

…だいたいこんな感じだったと思います。

少し前にあった統計学ブームや、昨今のフェイクニュースといった背景を頭の中に入れて読んでみると尚面白くな感じる書籍でした。

本の内容の多くは事例が多いので人によっては退屈に感じてしまうかもしれません。

個人的には翻訳された日本語の文章が自然すぎて、読んでいて引っかかりを覚えるところがなかったので非常に読みやすかったです。

読んだ後に感じた疑問

本の内容はとてもいい!という前提で、読書後に以下のような疑問が生まれました。

「政府統計とか公式統計の値自体が信用おけない場合はどうしたらいいんですかね?」という疑問です。

こんなの答えが出ないだろうし、そもそもファクトフルネスの大元のサイトでは答えが出ている話なのかもしれないけれど、やはり気になってしまいます。

というのも、最近日本のニュースでは統計不正や廃棄といった問題が度々報道されているのを目にしているからです。

この記事を書いた直近のニュースだと以下のものが挙げられるでしょうか。

www.tokyo-np.co.jp

本業の研究者でもなければ、データを追うだけでも大変なのに、そのデータ自体が本当に信用できるかどうかを検証する必要もあるなんて状態になっていたら、この書籍に書いてある「事実に基づく世界の見方」を実践するのは事実上無理なのでは?と思わずにはいられませんでした。

あと、これとは別件(?)で、よくある批判に対して翻訳者の方が誠実に答えているエントリもまだしっかり読めていないので、これを読むところから始めた方がいいのかもしれません。

jp.chibicode.com

まとめ

各所で絶賛されているので、逆に今更読まない方がいいかもと思う人はいるでしょうし、私もその考えに同調してしまいたくなる部分はあるのですが、まあ一度読んで損はないと思います。いい本です。

ただ、これを実践するのはかなり大変な類いの本なので、怠け癖の強い私のような人間は「もう日々のデータをアップデートして改訂された版が定期的に欲しい」という、この本で主張されている態度と真逆の態度を取りたくなってしまいますね。

データに基づいて議論したり決定するのは大変だなあと思いました。

何度目か分からないiOSプログラミングへの再入門をまた始めたという話

前回の記事で、前職の同僚にiOSプログラミングを教え始めたという話をしました。

takuan-osho.hatenablog.com

今のところゆるゆると続いていて、私もiOSプログラミングはそこまで深くやったことはないので、教えるついでに自分も再入門しなおし始めました。

以前にもこのブログで何回か言及した記憶はあるのですが、私、iOSプログラミングに入門しては挫折するということを繰り返していて、「今だと10回は超えないが、両手で数えるくらいは入門しては挫折している」という状態です。

今度の再入門がどれくらい続くかは不透明ですが、仕事とは全く関係ない分野だからこそ飽きが来にくいということと、今回は前職の同僚と一緒に勉強しているということもあり、以前よりかは続けられるのではないかと目論んでいます。

前職の同僚に教える際に教材として使っている書籍はこちらです。

本気ではじめるiPhoneアプリ作り Xcode 10.x対応 (Informatics&IDEA)

本気ではじめるiPhoneアプリ作り Xcode 10.x対応 (Informatics&IDEA)

以前iOSプログラミングに入門したときに使っていた書籍の最新バージョンです。

前に使った時に分かりやすいと思ったことと、応用を見据えた事項を抜き出して構成している書籍だったので好印象だったことから選びました。特にWeb APIを利用したアプリ作りを入れているのが好印象でした。

他人にプログラミングを教えていると「ここで詰まると思っていたのに、別のこの場所の方が分かりづらくて詰まるものなのか」とか意外な発見があって、自分も勉強になってます。

次回はこの教えた経験をもとに、(iOS)プログラミング初心者が詰まった事項をコードを交えて少し紹介する記事を書ければいいなと思ってます。

前職の同僚にプログラミングを教えたという話

大したことではないんですが、少しでもいいから記録を残しておいた方が後々振り返ったりしたくなったときに有益だと思ったので記事の形にして残します。

ふと自分のiPhoneのTwitterクライアントの通知が来ていたのに気づき、アプリを立ち上げて何の通知か確認すると、DMが1通来ていることに気づきました。

ここ最近は普段DMでやり取りする相手もいないので「一体何だろう?」と思い、確認してみると前職の同僚から「Swiftの経験ありますか?もしよければ教えて欲しいです」(意訳)とメッセージが。

正直SwiftはiOSプログラミングに入門した際に必要な分だけしかやったことがなくて、人に教えられる程度のものが備わっているわけではないとは知りつつも、その同僚がどんなことを考えているか何回かやり取りした後、詳しいことを確認するために一回会って話すことにしました。

話しを聞いた人たちの了解を取ってこの記事を書いているわけではないので、機微な情報には触れない程度にザックリとしたことを書くと、以下のようなことが決まりました。

  • iOSプログラミングを始めようと思っている前職の同僚たち*1は各自集まりながら勉強していく
  • 私はアドバイザー的な形でその学習を補佐し、ベストエフォートでサポートする

一回みんなでモブプログラミングみたいなことをして、初めて触れるSwiftがどんなものかを体験するくらいのところまではいけました。

プログラミングを仕事以外で真面目に教えるという経験は中々得られないので、そこが自分にとって魅力的に感じ、まず一回試してみたのですが、結構楽しくてよかったですね。

今後続くかどうかは分かりませんが、可能ならユルユルと続いてもらえるといいなー、なんて思う週末でした。

*1:メッセージを送ってきたのは1人でしたが、話をしたのは複数名でした

瞑想シーズン1-31日目

今日は以下の場所・時で瞑想しました。

  • 二度寝前
  • 仕事の合間合間
  • 昼食時のゆったりしたとき
  • 帰宅時の電車の中
  • 今この記事を書いている最中

クオリティも量も無いとはいえ、2019年になって今日まで一ヶ月間毎日この瞑想記録を書いてきましたが、あまりに不毛な要素があるので毎日更新するのはやめにしようかと思います。

一応技術ネタ主体のためのブログにしているつもりなので、それが押し流されてしまうのが痛いんですよね。

というわけで、一週間に一回か、隔週で一回くらいのペースに落として瞑想記録をつけようかなと今は思っていて、その分技術ネタのアウトプットを軽いものでもいいからしていくようにしたいと思っています。

直近では読んだ本の書評をしたいと思っていて、さっさと書けばいいのですけれど、まあ筆が進まなくてダメですね。

ま、適当にやっていきます。