【メモ】Chefがバージョンアップしてライセンスエラーが出るようになった【#np2020】

「Chef」が100%オープンソースに | OSDN Magazine

設定管理ツール「Chef」を開発する米Chefは4月2日、Chefソフトウェアを完全にオープンソースとして公開することを発表した。ライセンスはApache License 2.0で、商標ポリシーが守られている限りソースコードの使用、配布、収益化に制限を設けないという。  Chefはこれまでコア部分のみがオープンソースとして提供されていたが、今回プロダクトコードのすべてをオープンソースとする。これによりコミュニティの目標とChefの目標を連携させることができ、より良いソフトウェアの構築につながると期待を寄せている。  ライセンスは、Chef Infra、Chef InSpec、Chef Habitatと一貫性のあるApache License 2を採用、商標ポリシーが守られている限り、ソースコードの使用、配布、収益化に制限を設けないとしている。今後、Chefチームが生成するソフトウェアはすべてオープンなリポジトリに入り、ロードマップなどの製品開発プロセスについてもオープンにしていくという。

Chefがオープンソースになった影響なのか、ver.15からライセンスへの同意を設定ファイルに含めないといけなくなったらしく、そのままではエラーが出て動かない。
==> default: Chef Infra Client cannot execute without accepting the license Chef never successfully completed! Any errors should be visible in the output above. Please fix your recipes so that they properly complete.
ドキュメントを読むとvagrantではこう追加せよとあったのでやってみたんだけど……

Accepting the Chef License — Chef Docs

Vagrant This license acceptance can be done via the arguments API:

config.vm.provision "chef_zero" do |chef|
chef.arguments = "--chef-license accept"
end
怒られた。
==> default: /opt/chef/embedded/lib/ruby/gems/2.6.0/gems/mixlib-cli-2.0.3/lib/mixlib/cli.rb:230:in `parse_options’: invalid option: –chef-license (OptionParser::InvalidOption)
「–chef-license」っていうオプションなんか知らねーって言われてるみたい。多分、何かをアップデートしたら動くようになるんだろうなと思いつつ、面倒くさかったのでドキュメントにあったもうひとつの方法「Chefのバージョンを固定する」を試す。
config.vm.provision "chef_zero" do |chef|
chef.version = "14.12.3"
end
無事、vagrant起動。初めからこうしておけばよかったんや…… とはいえ、バージョンアップしないというのもアレなので、そのうち何かしたいと思います。どうしたらいいかわかんないけど。誰か教えてください。

続きを読む

【メモ】ファイルを変更していないはずなのにgit pullでmerge出来ない場合

Git-Logo-2Color.png masterブランチしかなく、作業者が自分1人しかおらず、ファイルの変更は手元の端末でしか行っていなくて、かつ、プログラムが書き換える可能性もないファイルを更新しようとしているのに、なぜか、

error: Your local changes to the following files would be overwritten by merge:
index.html
Please, commit your changes or stash them before you can merge.
Aborting
と出てmergeに失敗する。 おかしいなあと思っていたんですけど、これ、gitがファイルのパーミッションの変化を「変更あり」と検知してしまうからだそうです。vagrantの設定のせいか、手元のファイル(Mac)とvagrant上のファイルとでパーミッションが変わっているということなのかも知れません。 これを解決するには、パーミッションの変化を無視するように設定してやれば良いようです。
git config core.filemode false
なるほどね。手元がWindowsだったりするともっと顕著に出るかも。

続きを読む

冪等性(べきとうせい)

最近ずっと Ansible の勉強をしています。次に導入するサーバの設定を Ansible で設計・反映させる予定だからなんですが、ぶっちゃけ1台だけのサーバなら直接コマンド入力で設定した方がずっと早いし、Ansible を使う意味は限りなくゼロに近いです。でもまあ最近の環境構築ではこういう技術を使うのがスタンダードだって言うし、身につけておいたらどこかで役立つかも知れないので勉強がてらやってるって感じです。サーバを実際に設定できるようになるのはいつになることやら。 で、Ansibleを触っているとよくこの言葉を見掛けます。 「冪等性」 漢字だとわかりづらいですが、「べきとう」というひらがなであればどこかで聞いたことがあると思います。プログラミングでは割と普通に使われる単語です。

冪等 – Wikipedia

数学において、冪等性(べきとうせい、英: idempotence 「巾等性」とも書くが読み方は同じ)は、大雑把に言って、ある操作を1回行っても複数回行っても結果が同じであることをいう概念である。まれに等冪(とうべき)とも

続きを読む

タスクをチケット管理する(物理)

タスク管理のためのツールは色々ありまして、僕自身も業務ではRedmineとGitHubのPRとissueを組み合わせる感じで管理しています。詳細が誰にもわかる形で残るし、関連情報や関連チケットを紐付けたり担当者を明確にしたり期日をはっきりさせたり、あるのとないのとでは大違いです。超便利。 ただ、自分自身のちょっとしたタスクという点で言うとちょっと大仰なんですよね。チームで動いていて情報を誰かと共有する必要がある、タスクのサイズが割と大きめである、PCで参照すること前提に情報を記載したいなどの要件があれば便利と言えるんですけど、小さいサイズのタスクを備忘録的に使うのには向いてません。そういうレベルのタスク管理で昔から使われているのが「付箋」で、デスクトップ上に付箋を再現するソフトウェアもたくさんリリースされています。使ってみたこともあるんですが、ウィンドウの下に隠れてしまうのが不便、かつ、ウィンドウの下に隠れない(常に最前面に表示)とそれはそれで邪魔というなんとも微妙な感じがあって、使うのを止めてしまいました。 それ以来iPhoneのメモにあるチェックリストを使ったり、試行錯誤していたんですが、最近引き出しの中に昔ながらの「付箋」があることに気付いて使ってみたら、まあなんというか、便利ですよね。細かい情報を記載するのには向いてませんが、

  1. タスクをなるべく小さく分割する
  2. 付箋1つに記載するタスクは1つだけ
  3. 最小限の動きで見える部分(かつ邪魔にならない場所)に貼っておく
  4. 終わったら終わった端から捨てる
というルールを作って運用してみたら、あら便利。 年配の方や非技術者の方には「お前今さら何言ってんだ」と言われるかも知れませんが、いやあ、なんでもかんでもデジタルにしたがるもんなんですよ技術者ってのは。確かに検索機能とかリンク機能とか、デジタルじゃないと上手く機能しない機能ってたくさんありますし、便利だとも思うんですけど、アナログで十分って言うこともたまにはありますよね。僕にとってはそれがこれでした。

運用上の注意

ちょっと運用してみて思ったことをざっくりと。
  • つい付箋にあれこれ書いてしまいがちなのを控える
  • 詳しいことが決まっていない案件は大枠だけ書いておけばOK(上の画像の「Laravel」みたいに)
  • 要件が決まったらそれに合わせてチケットを細かく切る
  • 情報が少ないので付箋だけで完結させるのは不可能。別にドキュメントがあることが前提
  • 終わったら即捨てる。容赦なく捨てる
アナログでいいとはいえ、詳しい情報を残せないのはつらい。そういう意味ではきちんとドキュメントも残して、そこからタスクを切り出す際のUIとしてチケット(物理)があるという感じの捉え方です。今のところGoogleドキュメントに残していますが、情報が増えてきたらGitHubのwikiに移行するかもしれません。以前はPukiwikiをサーバに入れて運用していたこともあるんですけど、なかなかねえ。情報が散乱しがちで、綺麗にまとめるの難しいんですよね。かといって記憶しておくってのは不可能だし。趣味でプログラミングしてる人はこういうのどうしてるんでしょうかね。趣味でもきちんとタスク管理してるのかしら。

続きを読む

【メモ】Vagrant で共有フォルダのマウントに失敗する

vagrant.pngのサムネイル画像 試したいことがあって通常使用しているのとは別にテスト用にレポジトリをcloneしてVMを作るということをしたらば、次の様なエラーが。

Vagrantで共有フォルダのマウントに失敗するときの対処方法 – Qiita

Failed to mount folders in Linux guest. This is usually because the “vboxsf” file system is not available. Please verify that the guest additions are properly installed in the guest and can work properly. The command attempted was: (中略) The error output from the last command was: /sbin/mount.vboxsf: mounting failed with the error: No such device

要するに共有フォルダがマウントできない、そもそもvboxsfが見つからんと言われているみたいです。Guest Addtionsがちゃんと読み込まれてないっぽい? 上記エントリではプラグイン「vbguest」をインストールしておけば解決してくれると書かれているのですが、僕の環境ではどうも解決してくれない。「解消しない場合」という項目にあったこちらを参照したところ、逆に「vbguest」が問題になるケースがあるとのこと。 つまりこう:

vagrant-vbguestプラグインがGuestAdditionsを無効にしてしまう – Qiita

  1. VirtualBoxのバージョンとGAのバージョンが異なるためvbguestプラグインがGAの再ビルドを始める
  2. インストール済みGAが削除される
  3. アクティブなkernelと同じバージョンのkernel-develをインストールしようとするが、より新しいkernelが公開されているのでみつからない
  4. GAのビルドが失敗し、GAが動作しない状態に

なるほど。 結局どうしたらいいかっていうと、Guest OSのkernelをアップデートすれば幸せになれるらしいので、次のコマンドを実行。
$ vagrant ssh -c 'sudo yum update -y kernel'
$ vagrant reload
その上で vagrant reload してやると、
  1. 正しい kernel-debel を取得する
  2. 正常に GuestAddtions が更新される
  3. 正常にマウント出来る
という流れで無事起動に成功。 軽くハマって余計な時間食っちゃった。 とりあえず直って良かったです。感謝。

続きを読む

gettextのmo/poファイルを更新したらApacheを再起動する

PHP サイトを国際化するにあたってgettextを使って、mo/poファイルを作って翻訳を行うということはよくあり、今触っているシステムでもFuelの下で(Fuelのi18nは使わずに)gettextを使って日本語版と英語版の切り替えを実現しています。当然、このファイルは頻繁に更新されるわけですが、ローカルで確認していると更新後にロケールが正しく取得されずに日本語版で英語が表示されてしまうことがよくあります。何度かページ更新したり、時間をおいたりすると直るんですが、ローカルならまだしも本番環境で同じことが起こったら軽く事故ですね。ファイルサイズとかサーバスペックとかでキャッシュ更新タイミングが決まってるのか、運良く本番環境では発生していなかったようですが。 で、これなんともならんのかなあと思ってたら、こんな情報が。

PHPでgettextする際の注意事項というか、setlocaleの罠 – tohokuaikiのチラシの裏

罠3 Apacheを再起動せよ なんか、setlocaleが成功したり失敗したりする。。。。 検索したらPHPドキュメントのコメントが・・・。 PHP: setlocale – Manual

Omer Sabic On Linux/Apache, when you install and try to use a new locale, the setlocale() function with the new locale will fail sometimes, but not always. To furthermore complicate, setlocale() will always complete with any of the previously installed locales. This would seem a really weird behaviour, which you can fix by restarting Apache, as Kari Sderholm aka Haprog mentioned, but I felt it needed to be properly pointed out.
Apacheを再起動せよと・・・・。 確かに治った。

なるほど。そしてリリース手順に「services httpd graceful」を組み込んだら、ロケールの設定に失敗することがなくなりました。おおー。これまでモヤモヤしてたのが解決してスッキリしてよかったけど、でもまじかー。こんな簡単なことだったのか。

続きを読む

道具へのこだわりとパフォーマンスと

その昔は、仕事で使うものにこだわっていたときもありました。お気に入りのキーボードはダイアテックのMajestouchで、メカニカルで深めのキーが好きでした。軽いものより剛性が高くしっかりしたものが好みで、キーは英字のみで十分だけど変換は欲しいから日本語キーボードの方が良い……普段自分が気に入っているものを使っている分、普段と違うものを使うと違和感があってストレスでした。 プログラマの仕事を辞めて、前ほどはキーボードを叩かなくなり、また自宅で高いキーボードに珈琲をこぼすことが立て続けにあって以来、そういうこだわりはなくなってきました。今家で使っているキーボードはLogicoolの無線キーボード。 ​ いかにも安っぽい打ち心地で打鍵感もふにゃっとしていてキレが無く、そのせいで打ち間違いが多いんじゃないかとさえ思いますが、何より安い。2,000円くらい。そして途切れることなくしっかり動くし電池の保ちも悪くない。一応耐水と書いてあって確かに少しくらいなら水をこぼしても大丈夫だけど、大体の場合キー単位で動かなくなって交換。Amazonの注文履歴を見返してみると2年に1回くらい壊して新しいのを買っていて今使ってるのが3台目みたいですが、年1,000円と考えればまあ安いもん。 パートタイムでエンジニア的なことをしていたとき、職場で使っていたのはなぜかMacばかりで、キーボードは前回が普通のテンキー付きフルサイズキーボード、そして今回はテンキーのないコンパクトな「Apple Magic Keyboard」。普段Macは全く使っていないものの、前職と合わせて2年以上触っているので、Macのキーボード自体は慣れていて大丈夫。ただこのキーボードコンパクトなだけあって、キーボードのピッチが若干狭いんですよね。キーも、Appleのキーボードはみんなそうだけど、ちょっと盛り上がったボタンみたいな感じで、左右との境界が小さいので、つい隣のボタンを押してしまうと言うか押し間違えそうになっても感触で気付きづらい。ブラインドタッチは出来るけれど、直す回数が多くて……OSもキーボードもPCですら道具を選ばなくなって、ベストマッチとまではいかなくても何を使ってもストレス無く作業できるようになったと思っていたのですが、このキーボードのピッチは苦労するな…… そんなこと思ってたけど、3ヶ月くらいで慣れましたね。逆に普段使いのキーボードでTYPOが増えた時期もあったけど、それももう大丈夫。人ってのは環境に適応していくもんだなあと思いました。 プロとして自分が使う道具にこだわっていくのはとても大事だと今でも思っていて、実際、色んな包丁を使ってきてそれだけは自分専用のものを持とうと思って年末にちょっといい包丁を買ったんですけど、でも「どんな道具でも使いこなす」というのも大事なんだよなと改めて思いました。なんだろうな。働いていると道具の善し悪しを選べないときもあるけれど、そんなときに当たった道具次第で自分のパフォーマンスが大きく左右されるのもプロとしてはダメだと思うのですよ。道具へのこだわりを持ちつつ、道具を選ばずに動ける柔軟さを。特定の道具とのコンビでしか働けないようでは、まだまだなんでしょうね。 「弘法筆を選ばず」というけれど、空海さんだって筆は選んだと思うんですよ。お気に入りの筆もあっただろうし、書くものによって適切な筆の選択もあったでしょう、でも例えそれが自分の望み通りにならなかったとしても、その時手にした筆で、高いパフォーマンスを残せる。本人の中では「ああ、あの筆があったらな」と言うのが合ったかも知れないけれど、でも周りから評価を得るに足る仕事は出来る。んで、そうなるためには結局、道具を選り好みしていてはダメなんだってことなんだろうなあと思ったのです。なんでも使える方が便利だしさ。 まあでも、このキーボード。可愛くて軽くて無線が安定してて良いキーボードですよ。テンキーが無いのがツラいときもありますが(「+」の入力がシフト押しながらになるのがホントツラい)、それ以外は大丈夫。あまりに安定しているせいで最近まで優先だと思ってケーブルを繋いだまま使ってました。もう半年も使ってるのに!先週くらい仕事中、ケーブル外して無線だってのがわかって自分の間抜けさに大笑いしそうになりました。可愛い奴め。

続きを読む

「シンプル志向」と他人の意見を聞くことと

黒板に電球イラスト3 昼間、エンジニアのパートタイムな仕事再開して5ヶ月経ちます。以前は自分が仕切ってやっていた開発ですが、今は自分より全然優秀な(そしてきちんとコミュニケーション能力があり、すぐに結果を出せる)エンジニアが上にいてくれるので、すごく気が楽です。もうね、方針とかコーディング規約とかプロジェクト進行の細則とか、好みちゃうのって思うような小さいところまで全部おまかせにして、それに従うようにしています。僕の好み通りにコーディングしたところで、僕がずっとこの会社にいるわけでもないのでね。それなら、統一性があった方がずっといい。 で、コードレビューの際にそういう指摘を受けて修正する機会が多くあるんですけど、そのうちの1つがとにかく徹底的にシンプル志向。少しでも技巧的な処理を行うと、「難読なのでシンプルな構造にしてください」という指摘を受けます。なんだろう、例えば入れ子の三項演算子とか一目でNG。そんなの僕も好きじゃないのでやらないけど。変数が多く乱立してるのもお好みじゃないみたいで、array_map() とかarray_filter() とかを無名関数と組み合わせて処理するのが好きみたい。その方が見えにくくなることもあるんじゃないの、と思ったりもするけれど、処理部分を明確にわけておきたいというのは理解出来ます。そうしておけば後で手を入れることになったとき、わかりやすいしね。 現在触っているプログラム群は、僕が退職後に導入された新システムで、今の上司が入社する前に、外注先で作られたシステムなんだけど、これがねー。あんまり言及するのはよして置くけど、難読って言うか場当たり的に建てられててすごくメンテナンス性が悪いのよね。700行くらいswitch構文につっこむとか平気でやってるし。しかもその中で変数使い回したり、global変数呼んだりやりたい放題で、コードが難しいというよりかは純粋にわかりづらい。きっと納期ギリギリで、リファクタリングする暇がなかったんだろうね。今2人でタスクをこなしながら触った部分はリファクタリングを進めてるけど、まあ大変。僕が来るまでに1年くらいあるのかな、そう考えると今はまだマシになった方だろうし、そこでの経験もシンプル志向の元になっているのかも。 個人的にはコードの難読性と、プログラム全体の難読性は必ずしも一致しない、部分であれば短い行数で終えることを志向してもいいのではと思ったりするんだけど、でも同時に、誰か優秀な人が言うことにとりあえず従ってみて結果を見てみるというのも面白いよねと思って日々働いてます。若い頃だったら議論したかも知れないけど、まあ今はね。自分の思い通りにコーディング出来なくたって何に影響することもない、そもそも賞与も昇給もないんだし評価されるということ自体がない、ストレスもなんもない、むしろ違う考え方を知れて面白いと思うし。 この考え方は、未経験で飲食に入れてもらってそこで「私は何も知りません」というスタイルで全部言われたとおりにやってみて、身についた考え方かな。決して「自分の意見を持たずに他人の言うとおりにする」って言うことではなくて、自分の狭い了見でごちゃごちゃ言う前に、他人のいうことも試してみるべき、そういう意見を聞く耳を持つべき、自分の実力が劣る場合にはそれが一番早く成長する手段ってこと。自分のこだわりを持つのはそれからでも遅くないし。 なんか、大人になっちゃったなー。 とか言いつつ、今でもすげー小さいことで議論しようとしたりするけど(笑) ま、性分が変わったわけではないってことで。

続きを読む