ホンモノのエンジニアになりたい

ITやビジネス、テクノロジーの話を中心とした雑記ブログです。

【読書感想文】「ハッカーと画家」を読んで。二流の証明。

読書感想文です。今回読んだ本はこちらです。

 

ハッカーと画家 コンピュータ時代の創造者たち

ハッカーと画家 コンピュータ時代の創造者たち

 

 

読もうと思った理由

年末年始で積読タワーを消化しようと思って手に取りました。そもそも買った理由をもう覚えてないですが、確か内容や書評を見てではなくタイトルと装丁で何となく買いをした本だったと記憶しています。私が憧れる「ハッカー」と、凄くイノベーティブな雰囲気を醸し出す「画家」の組み合わせですからね。

私は読み物系の本は移動中や隙間時間に読むことが多いんですが、本書はオサレな装丁で、オサレなタイトルなので、人前で読むことが憚れ、お家で一気読みすることにしました。

 

全体の感想

買ったときは気づかなかったんですが、この本、ボールグレアム氏の本でした。前に以下の読書感想文をこのブログで書いていますが、このYコンビネータというシードファンドを作った人です。私的にはこの「Yコンビネーター」は大当たりな本だったのもあって、本書もとても楽しく興味深く読むことが出来ました。「Yコンビネーター」読んだ!超アツかった!という人にはとてもオススメできる本です。

(以下、「Yコンビネータ―」と記載した場合は書籍を指すことにします。ファンドとしてのYコンビネータ―の場合は括弧無しで記載します。)

 

本書は著者がウェブ公開しているエッセイをまとめて構成されているそうです。たぶん↓が本家。

http://www.paulgraham.com/articles.html

 

内容を振り返って考えてみると本書は「概ねIT系の自己啓発本」と分類するのがいいんじゃないかと思います。「ハッカーと画家」というタイトルに自己啓発っぽさは皆無ですが、読めば「自分ならどう考えるか」とか「コード書きてぇ」という気持ちになります。本を読んで考える、触発されてモノ作りをするモチベーションが生まれる、これって本来自己啓発本が備えていなくちゃならない要素だと思うんです。書いてある通りにやってみようとなるのはハウツー本ですし。なので私は本書のような内容を含んだ書籍こそが、自己啓発本と呼ばれるべきものなんだなぁと思いました。

 

全体の評価としてはとても面白く、以前読んだ「Yコンビネーター」と並ぶ面白さがありました。本書はエッセイという形をとっているので静的な読み物という印象です。対して「Yコンビネーター」はドキュメンタリー形式というのもあって動的だったという印象です。読中読後の熱量は「Yコンビネータ―」の方が強いと感じました。「Yコンビネーター」は本を読みながら本当にコードを書きたくてウズウズしちゃいました。「ハッカーと画家」は読中読後にコード書きたい欲が溢れ出てくるというよりも、より脳ミソを強く揺すられたという印象です。巻末にある監訳者のあとがきにこう書いてあります。

ポール・グレアムのエッセイは挑発的だと言われる。(中略)賛成にせよ、反対にせよ、彼のエッセイには人の頭の中にある「一言いいたくなる」ボタンを押す何かがあるようだ。いや、むしろ彼のエッセイが押すのは「何かやりたくなる」ボタンなのかもしれない。

 

正にこれだなと思いました。著者は本書で書きたいことを書いていますが、そこにはそのように考える根拠として、そこに至る論理を開けっ広げに書いています。その論理のところが論理的に正しいとは言えない部分があって、そここそが「一言言いたくなる」の源泉になっているのだと思います。こう書くと誤解されそうですが、論理的に正しくないと書いているのは、論理的に間違っているという意味ではなく、証明しきれない部分を自身の知識や経験から補って結論付けているところにあります。(まぁエッセイですからね)ポールグレアム風に書くとこんな感じです。

 

日本は労働生産性が低いと分析されているが本当にそうなのだろうか。時間を守り、勤勉で、ロボットのように働く彼らの生産性が低いというのは直感的には誤りだと感じる。きっと彼らが仕事をする環境だったり、周りにある他の外部要因に原因があるはずだ。例えば……

 

といった書き方がされているんです。何か一言言いたくならないだろうか。私はとてもなりました。読み進むたびに「いやいや、そこはこうなんじゃないのか」とか「自分の周りならきっとこうだ」というように思考を促される感覚がありました。良い本を読んだ時によく思うことですが、良い本は”本全体”から強いメッセージが発せられている気がします。良いことが書いてある章や節、センテンスがあるのではなく、本全体から出てくる魅力があるのだと思います。だから良い本であるほど、感想文を書くのが難しい。内容の薄っぺらい本だったら感想を書くのって楽なんですよ。著者の言いたいことが大して無いし、大したものでも無いですから。

 

二流の証明

本書の感想文(このエントリ自体)を書いている途中で思い付いた、ある種メタ的な感想です。 

ハッカーと画家を読んでいると、読中とても心地よい感じがしていました。先に書いた通り「一言いいたくなる」部分もそうですが、自分の思考回路と似ている感じがしたんです。だけど、一流の人が言語化した内容に対して「そうそう、俺もそう思ってた。」なんてことを言うのは正に二流の証明だと思ってしまったわけです。本書の中でデザインに関する話があるんですが、その中にこう書いてあります。

 

いくつかの偉大な発見はあまりにも単純に見えて、「これなら自分でも思いついたよ」と言いたくなることがある。発見者はこう言うだろう。「じゃあ君が思いつけばよかったじゃないか」

 

本書を読んでいると「そうそう俺もそう思ってた」と思うところがあるんですが、じゃあそれを本書を読む前に言語化できたかというと、まぁできなかっただろうなぁと思います(これこそ読書の良い所ではありますけど)。つまり上記の引用文中で「これなら自分でも思いついたよ」と言う人間と同じってことです。心地よく読むことが出来て、感想を書いていったら、その感想文自体が本書の中で言及されている二流どころの表現になってしまいましたというお話です。

 

意図せずつながった自分の興味

私は読中この本の著者がポールグレアムだと気づかずに読み始め、オモロイオモロイと思って読んでいました。でも実はもう1つ私から見た興味の繋がりがありました。本書で何度か引用されているエリック・レイモンドのところです。

私はこのブログのタイトル通り、ホンモノのエンジニアに憧れていて、ホンモノのエンジニアってどういうエンジニアなんだろうかと調べていたことがありました。そのときに見つけて思わずブックマークし、繰返し読んでいるエッセイ(というべきか?)があります。これ↓ 

How To Become A Hacker: Japanese

 

なんとまぁ自分が気に入って繰返し読んでいたエッセイが本書で紹介されているじゃないの。何かこれがすごくうれしかったです。自分でこうやって書いていて恥ずかしいなと思う部分もあるんですけど、まぁ感想文ですから素直に書かせてください。

  

「美しい」の答え

本書には「美しさ」に対して深堀していく章があります。私もこの美しさという概念の存在について疑問に思っていたことがあって、その点に触れられていたところは特に面白かったです。(うーん、後出しで「俺もそう思ってた」って書いてますね)

ずっと疑問に思っていたことなんですが、美術系の人は置いておいても、学者、プログラマ、その他色々な分野のトップクラスの人って、「美しい」という表現を使うんですよね。この美しいという表現が私には理解できないものなんです。トップクラスの人たちがよく使う表現なので、どんな分野でも突き詰めていくことで、最終的に分野を問わず得られる感覚なんだとは思ってるんです。

いきなり「美」の対極にある例となりますが、ゴキブリやムカデといった虫は、それが気持ち悪い存在だと教えられたわけでもないのに、大勢の人が嫌悪感を覚えます。嫌悪感ってのは感覚的なものです。なので真に共有できないはずだし、そもそも「ゴキブリは気持ち悪い」と教わったわけでもないのに、多くの人が同じ感覚を覚えるってのはすごく不思議なことだと思っていたんです。

「ゴキブリは気持ち悪い」というのは教育を受けなくても何かの能力を高めなくても感じることができます。でも、「美しい」という表現は分野のトップクラスの人しか言いません。(たまにこれを利用して美しいという表現を使ってマウントを取ろうとするクズみたいなのはいますけどね)

ということは、人間は醜いものを感じ取るセンサーはみんな持っていて、美しいものを感じ取るセンサーは一部のトップクラスの人しか持っていないのか。でも醜いと美しいは1つのベクトル上にある評価基準だとも思えます。ならば負の方向への感覚はみんな持っていて正の方向への感覚を持っていないということか。もしそうならなんかこれってすごく嫌な感じがしますよね。

 

話を読書感想文に戻します。本書では「美しさ」に対して分析を行っている点がすごく面白かったです。美しさについて、そこに共通している要因がわかれば、他の分野に応用できるのではないかという考えで、「美」の共通項を14個挙げています。例えば「良いデザインは単純である。」といった感じで、いづれも興味深く読めました。

 

そしてこの章の最後に書いてある結論がまた良いんですよ。美の共通項を挙げて解説した章なんだけど、最後は、

醜いものを許せないだけでは十分ではない。どこを直せばよいのか知る嗅覚を得るためには、その分野を十分に理解していなければならない。しっかり勉強しなくちゃならないんだ。

と書いています。美を分解してそこに共通している因子を取り出したんだから、今度は逆にその因子を組み込んでいけば美しいものが出来上がる、と言うのかと思ったら全然そんなことはなかった。私の感覚的な理解ですが、原因と結果の話に似ていると思いました。美しいものや、それに共通して存在する因子というのは結果なんだと思います(因子なのに結果と書いているのでわからづらいですが)。あくまでも上手くいっているものから抜き出した共通因子でしかなく、それ自体で美の全てを説明することができない。美しいと言われるものが結果として備えている共通因子なわけです。

結局この章で書いているのは、あくまでも美しさを構成する因子を説明しているだけで、美しいものを作るプロセスはまた違うものだということです。最終的には「しっかり勉強しなくちゃならないんだ」という険しい道のりを結論としているところが美しいなと思いました。

 

これキタ!ポイント

「これキタ!」ポイントを引用しながらメモっておきます。

 

第0章

フォーカスグループはその時流行りのうわべの装飾を欲しがるかもしれない。だが本当に欲しいのは、洗練された買い手の真似をすることだ。

これ冒頭の0章にさらっと書いてありましたけど、すごく本質的なことだと思ったのでメモっておきます。ブランド好きな人たちってのは、そのブランドが優れているから買うのではなく、そのブランドを身に着けている自分の姿が好きなんだと私は思っていました。最近のインフルエンサーの異常な盛り上がりを考えると、みんな何かそういう真似たいと思う誰かを求めているのかもしれないなと思いました。

 

第1章

時を遡って13歳の自分にアドバイスできるとしたら、まず頭を上げて回りを見てみろと言ってやりたい。当時は気づいていなかったのだが、自分たちがいた世界のすべては張りぼての偽物だった。

文章がカッコイイなと思ったのと、すごく考えさせられたところです。著者は13歳のときにいた世界のすべては張りぼての偽物だったと書いています。私が13歳の頃はと考えたんですが、いやむしろ今も私は張りぼての偽物の世界にいるような感じがしています。これを書いている2019年1月は厚労省の統計問題が盛り上がっていますが、あれなんかはモロ張りぼての偽物なわけです。でも張りぼてであろうとも全ての面を作りきってしまえば意外とバレないし、張りぼてでも世界は回っていくんだと思いました。だから今この世界にある例えば統計問題みたいな張りぼてだけど世界は回っているという何かを見つけて、それをぶっ壊すという考えが大事なのではないかと。

 

第2章

作家や画家や建築家が創りながら作品を理解してゆくのと同じで、プログラマはプログラムを書きながら理解してゆくべきなんだ。(中略)プログラミング言語はプログラムを考えるためのものであって、既に考えたプログラムを書き下すためのものじゃない。

 

プログラムの仕様に完璧さを期待するなんて非現実的だ。そのことをまず認めて、仕様がプログラムを書いている最中に変わっていっても、それを受け入れられるような書き方をすべきなんだ。(大企業の構造にはこれをやりにくくさせるものがあり、これもベンチャー企業の利する点だ。)

哀しい事に私は普段の業務でコードを書きませんが、SIerにいる人間として忘れてはいけないことなんだと思いました。これを忘れてしまうと完全に終わったエンジニアになると思います。だからやっぱりIT企業にいて、コードを書かないとかサーバに触らない人って、何かを作り続けないと感覚がおかしくなっていってしまうんだろうなと思いました。

 

第5章

プロジェクトに人員を追加することは、プロジェクトをかえって遅れさせがちだ。開発者間の可能な連携の数はグループの大きさに対して指数的に増大する。

これは実感として確かにあると思いました。遅れているならリソース追加だ、となるケースってわりとあると思いますが、現場ではそんな単純な足し算で遅れを取り戻せたりはしません。

 

サーバが問題を起こすのは、私たちにとって何が何でも避けるべきことだった。ちょうど、おもちゃ屋にとっての危険なおもちゃとか、食品業者にとってもサルモネラ菌などと同じようなものだ。

サーバ屋の顔を持つ私から見て、これも確かにあるなぁと思ったのでメモとして引用しています。金融系や公共系のシステムをやっていると、サービス停止=死刑みたいなところがあって、それは確かに食品業者にとってのサルモネラ菌なのかもと思いました。

 

大会社にとってWebベースアプリケーションを使うことはITをアウトソースするということになる。

ここでいうWebベースアプリケーションは今でいうパブリッククラウドのことですね。感覚的な話ですが、アウトソースという言葉を使うとどうも人に委託するというイメージがありますが、パブリッククラウドを使うってのも一種のアウトソースなんだなぁと逆に新鮮に思ったので引用しました。

 

入門レベルのユーザは、どこを簡単で明快にすべきか教えてくれる。最も進んだユーザは、どういう機能を足したらよいかを教えてくれる。最良のソフトウェアは簡単であるものだが、それはデフォルト設定がそうなっているためで、ユーザが望めばその選択に限界があってはならない。

 

第6章

大学を卒業しようとしている学生は、就職しなくちゃならないと周りから言われるし、自分でもそう考える。まるで組織のメンバーになることが重要であるかのように。でももっと直接的に言えば、人々が欲することを始めることが必要なんだ。人々が欲することをすることが重要なのであって、集団に属することは問題じゃない。

真理だと思った。就職ってのはあくまで手段であって目的ではない。就社ではなく、文字通り就職することが大事ということですね。ただこれは真理である一方で日本で流行るかというと難しい気がします。超大手企業に入るためには良い大学を良い成績で卒業して、更にどの会社にも洗脳されていないプレーンな人材であることを求められるし、卒業後に起業してみたけどダメでした御社に入りたいんですが、という異端人材はなかなか受け入れられない傾向が強い。安定した会社に入るためには素直なフリして新卒で門戸をたたかないといけない。ここでいう「集団に属することは問題じゃない」と考えて我が道を突き進むことは見識を広げることには繋がるが、日本では入れる会社を狭める行為に繋がってしまう。でも真理。

 

私は恐ろしく困難な技術上の問題に丸一日がかりで皆で取り組み、精も根も尽き果ててしまった時のことを覚えている。それでも私は嬉しかった。私たちがこれだけ苦労するような問題なら、きっと競争相手は誰も解決できないだろうと思ったからだ。(中略)競争相手が真似するのが難しすぎるような技術を作りさえすれば、他の防御に頼る必要はない。難しい問題を選ぶことから始め、決断が必要な場面では常に難しい方を選べばよい。

冒頭で紹介した「Yコンビネータ」にも似たようなことが書いてあった。「Yコンビネータ―」では「他の連中より真剣に考え抜いた点だけが優位点になる」とあった。これはやっぱり仕事をする中で忘れてはいけないこと。

 

 

第9章 

良いデザインは再デザインだ

熟練者は初期の仕事を捨てるつもりでやる。計画が変更されることを予定してかかるのだ。

 

第12章

もし、他の誰もが使っているからという理由で技術を選ぶなら、Windowsを走らせておけばいいのさ。技術を選択する時は、ほかの人がどうやっているかなんて無視して、何が最適かを見極めることだけを考えるべきだ。

 

第13章

この世にある多くのプロジェクトの要求はさして高くない。おそらくプログラミングの殆どは、既存の部品をつなぎ合わせる小さな糊付けプログラムを書くようなものだ。それならもう手に馴染んでいて、目的に合わせたライブラリが充実している言語を使えばいい。

個人開発をやる時に常に考えたいメッセージです。糊付けで開発したアプリケーションはアイディア次第で面白いものが作れるけど、真似するのが簡単です。やっぱりIT業界にいるとなると、いずれは起業して金儲けしたるどー、と漠然とした妄想はするわけで、その時に忘れちゃならない内容だと思います。

 

大きな組織では、このアプローチを「業界のベストプラクティス」という言葉で表される。その目的は髪のとんがった上司を責任から守ることだ。彼が「業界のベストプラクティス」である何かを選んでそれで会社が競争に負けたら、悪いのは彼じゃない。彼が選んだのではなく、業界が選んだのだから。

「業界のベストプラクティス」はあなたをトップにするのではなく、単に平凡にするだけだ。

 

第16章

素晴らしいハッカーはまた、一般的に、オープンソースソフトウェアを使うことを主張する。そちらのほうが良質だというだけでなく、自分で多くをコントロールできるからだ。良いハッカーはコントロールしたがる。それが彼らを良いハッカーたらしめている理由の一つだ。何かが壊れたら、自分で直したいんだ。

 

オフィス環境というのは、その中で仕事をするためのものであって、そういう環境にも関わらず仕事をする、というものじゃないはずだ。

以前読んだピープルウェアという本にも似たようなことが書いてあった。エンジニアの集中力を無くさせるような環境はいかんというもの。

 

 

用語解説

システム管理者症候群

システム管理者が、監視しているシステムがユーザにとっての道具ではなく、それ自体が目的であるかのように思い込んでしまうこと。より一般的には、顧客を、それが自分の存在理由のはずなのに、単に煩わしいものと感じてしまうこと。競争に晒されていない職種に特有の病である。

 

 おわり

 

 

【Python】imghdr.what()でJPEGファイルが判定できない

タイトルの通り、imghdr.what()で画像ファイルのフォーマットを調べたら一部のJPEGファイルが上手く検出できない事象が発生しました。

幸いなことに既に原因と解決策を公開してくれている人がおりました。

qiita.com

このエントリでは私なりにもう半歩ほど踏み込んで事象を整理してみようと思います。

環境
CentOS Linux release 7.4.1708 (Core)
Python 3.6.5


何で検出できないか?

上で紹介したQiita記事に簡潔にまとめられていますが、ソースコードではこうなっていると。

def test_jpeg(h, f):
    """JPEG data in JFIF or Exif format"""
    if h[6:10] in (b'JFIF', b'Exif'):
        return 'jpeg'


ファイル先頭の7~10バイトのところに'JFIF'、'Exif'という文字列があればJpegと判定する仕様になっています。 WikipediaJPEGを調べてみると、以下のように書いてあります。

マジックナンバー \xff\xd8

標準では、特定の種類の画像の正式なフォーマットがなく、JFIF形式(マジックナンバー上は、6バイト目から始まる形式部分にJFIFと記されているもの)が事実上の標準ファイルフォーマットとなっている。 JPEG - Wikipedia


マジックナンバーは「FFD8」であるが、JPEGの事実上の標準はJFIFであり、それを表すのは6バイト目からの「JFIF」文字列(を表すバイナリ部分)であると。
手元のJPEGファイルをバイナリエディタで見てみるとこうなっている。

①普通のJPEG
f:id:kwnflog:20181230171758p:plain

②問題のJPEG f:id:kwnflog:20181230171844p:plain

Exif形式 f:id:kwnflog:20181230171904p:plain

問題のJPEGではマジックナンバーの直後に量子化テーブル定義という、あのー、あれだ、いわゆるあれが入っている(た、たぶん画像データ部分)。 本来はJFIFだと「FFE0」、Exifだと「FFE1」が来ないといけないっぽい。

ちなみにLinuxのfileコマンドでは以下のように表示されます。fileコマンドは偉大。

$ file JFIF-ari.jpg
JFIF-ari.jpg: JPEG image data, JFIF standard 1.01

$ file JFIF-nasi.jpg
JFIF-nasi.jpg: JPEG image data

$ file Exif.JPG
Exif.JPG: JPEG image data, EXIF standard 2.2


まとめると、どんな理由かはわかりませんがJPEGファイルのヘッダに事実上の標準とされているJFIF情報が存在しなく、そこを読んでファイル形式を判定するimghdrコマンドも機能しないというのがうまく判定できない理由となるようです。


JFIFExif無しファイルが来た時にどーするか?

冒頭でリンクを貼ったQiitaの人と同じような対応をしました。先頭の2バイトがFFD8ならJPEGと判定するロジックです。(ロジックというレベルじゃないですね)

f=open('/path/to/file','rb')
f_head = f.read()[:2]
f.close()
if f_head == b'\xff\xd8':
    print('JPEGです')


これをimghdr.what()に引っかからなかったファイルに実行してJPEG判定をする。

たぶんもっとエレガントな書き方、対応法があるんでしょうけど、目的である画像ファイルフォーマットの判定は出来たのでこれでよしとします。

おわり

CentOS7.4にLibreOfficeをインストールする

現在(2018/11時点)の最新版LibreOfficeをインストールするにあたりやってみたこと、うまくいかなかったことをダラダラ書きます。世の中に似たようなエントリは多数あるけども、バージョンや環境の違いで微妙に変わることも多く、きっと誰か(未来の自分を含む)の役に立つだろうと思い筆を取りました。

●ゴール
CentOSのシェルからLibreOfficeコマンドが打てるところまで

●環境
CentOS 7.4 x64(virtualbox
LibreOffice 6.1.3


まずは本家サイトのダウンロードページ↓にアクセス

https://ja.libreoffice.org/download/libreoffice/

f:id:kwnflog:20181111135420p:plain

インストール環境に合わせたインストーラのダウンロードページが表示されます。

↑のキャプチャはローカルマシンのWindows10からアクセスしているので、Windows x86_64のダウンロードページになっています。インストール環境と別環境からアクセスしている場合は、「変更しますか?」をクリック。

f:id:kwnflog:20181111135551p:plain

OSの選択画面に飛ぶので、該当の環境を選択する。チェックボックスのように見えますが、実はリンクになっているので欲しいインストーラをクリック。私の場合はCentOS x64なので、赤枠の(まるでチェックボックスかのような)リンクをクリック。

f:id:kwnflog:20181111135854p:plain

インストール環境に合致したダウンロード画面に遷移したので、「ダウンロードバージョン」ボタンを右クリックして、「リンクのアドレスをコピー」

(上記キャプチャはChromeで表示した画面です。ブラウザによっては文言が違うので適宜読み替えてください)

すると、クリップボードにURLが格納される。私がやった時は以下のURLがコピーされていました。

https://donate.libreoffice.org/home/dl/rpm-x86_64/6.1.3/ja/LibreOffice_6.1.3_Linux_x86-64_rpm.tar.gz


で、ここからはCentOSのシェル上でコマンドを打っていく。

私はローカルPCの仮想環境でやっていますので、rootユーザで操作しています。必要ならば適宜sudoを入れてroot権限で実行してください。

まずは前手順で得たURLへ向けてwgetコマンドを打ってtarファイルを取得する。

# wget https://donate.libreoffice.org/home/dl/rpm-x86_64/6.1.3/ja/LibreOffice_6.1.3_Linux_x86-64_rpm.tar.gz
--2018-11-11 12:16:07-- https://donate.libreoffice.org/home/dl/rpm-x86_64/6.1.3
/ja/LibreOffice_6.1.3_Linux_x86-64_rpm.tar.gz
donate.libreoffice.org (donate.libreoffice.org) をDNSに問いあわせています... 89.
238.68.168, 2a00:1828:a012:168::1
donate.libreoffice.org (donate.libreoffice.org)|89.238.68.168|:443 に接続してい
ます... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 特定できません [text/html]
`LibreOffice_6.1.3_Linux_x86-64_rpm.tar.gz' に保存中

[ <=> ] 33,308 --.-K/s 時間 0.001s

2018-11-11 12:16:08 (54.3 MB/s) - `LibreOffice_6.1.3_Linux_x86-64_rpm.tar.gz' へ
保存終了 [33308]



何かわかりませんが、インストーラの実体は落ちてこなくて、ダウンロードページのhtmlがtarファイルとして保存されてる。調べてみたけど、わからず。

でも結局はtarファイルがあれば良いはずなので、上で貼った最後のキャプチャ画面で素直にダウンロードボタンをクリックしてローカルPC上にtarファイルを落とす。

でローカルPCからインストール環境へtar.gzファイルを転送。

tar解凍

# tar zxvf LibreOffice_6.1.3_Linux_x86-64_rpm.tar.gz

LibreOffice_6.1.3.2_Linux_x86-64_rpm/
LibreOffice_6.1.3.2_Linux_x86-64_rpm/readmes/
LibreOffice_6.1.3.2_Linux_x86-64_rpm/readmes/README_en-US
LibreOffice_6.1.3.2_Linux_x86-64_rpm/RPMS/

(以下略)

解凍できたら、RPMディレクトリまで移動する。

# cd LibreOffice_6.1.3

# ls -l
合計 16
drwxrwxr-x 2 root root 4096 10月 30 11:24 RPMS
-rwxr-xr-x 1 root root 10490 10月 30 11:24 install
drwxr-xr-x 2 root root 26 10月 30 11:24 readmes

# cd RPMS/

ネットで調べた通りにrpmコマンドでインストール!

# rpm -Uvh *.rpm
エラー: 依存性の欠如:
libXinerama.so.1()(64bit) は libobasis6.1-core-6.1.3.2-2.x86_64 に必要とされています

うわーメンドクセー

ググってもイマイチわからなかったので、yumさんにお任せしてみる。

# yum install *.rpm

ダーっと画面が流れていく中で、以下の出力があったので、yumさんが解決してくれたようです。

依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ libobasis6.1-base.x86_64 0:6.1.3.2-2 を インストール
---> パッケージ libobasis6.1-calc.x86_64 0:6.1.3.2-2 を インストール
---> パッケージ libobasis6.1-core.x86_64 0:6.1.3.2-2 を インストール
--> 依存性の処理をしています: libXinerama.so.1()(64bit) のパッケージ: libobasis6
.1-core-6.1.3.2-2.x86_64


一応書き残しておきます。私の環境では以下の通り、インストール容量として570MBの空き容量が要求されました。ちなみにtar.gzファイルは218MB、解凍後のRPMファイルが220MBくらいなので、作業前に最低1GBくらいは容量を確保しておくのがよろしいかと思われる。環境によっては前提となるライブラリを持っていなかったりすると、更に多くの容量が求められるはずです。tarファイル消せばもう少し少なくなりますけど。

トランザクションの要約
===================================================
インストール 42 パッケージ (+2 個の依存関係のパッケージ)

合計容量: 570 M
総ダウンロード容量: 52 k
インストール容量: 570 M
Is this ok [y/d/N]:

yumコマンドの最後に以下が出力。

依存性関連をインストールしました:
libXext.x86_64 0:1.3.3-3.el7 libXinerama.x86_64 0:1.1.3-2.1.el7
完了しました!

先ほど怒られたライブラリ依存の問題を無事に解決してくれて「完了しました!」と。 うん、元気があってよろしい!

さて、どちらにインストールされたのやらと探すと、

# find / -name *libreoffice*
/usr/bin/libreoffice6.1
/opt/libreoffice6.1

# ls -l /usr/bin/libreoffice6.1
lrwxrwxrwx 1 root root 35 11月 11 12:43 /usr/bin/libreoffice6.1 -> /opt/libreoffice6.1/program/soffice

実体は/opt/libreoffice6.1/program にあるsofficeらしい。

よし動かそう。コマンドラインオプションは何だったかなとヘルプオプション付きで実行してみる。

# libreoffice6.1 -h

/opt/libreoffice6.1/program/soffice.bin: error while loading shared libraries: libcairo.so.2: cannot open shared object file: No such file or directory


むむむ

libcairo.so.2とかってライブラリが無い。。。

これはググって解決。

Amazon Linuxで同じ問題に直面した方がQiitaに書いてくれていたのでマネする。

Amazon LinuxでLibre Officeをつかう - Qiita

# yum install cairo

->完了しました!

さぁ動け!というかまずヘルプ見せろ!

# libreoffice6.1 -h
/opt/libreoffice6.1/program/soffice.bin: error while loading shared libraries: libSM.so.6: cannot open shared object file: No such file or directory

libSM.so.6 ガ、アリマセン

ここで「ハイハイどうせlibSMとかってやつをyumすればいいんしょ」と思ってやってみると、

# yum install libSM
->完了しました!

yum searchとかinfoコマンドくらい打つべきだったなと少し反省。

ハイッ、で次は何のライブラリが足りないの?ねぇどうせまたでしょ!

# libreoffice6.1 -h
LibreOffice 6.1.3.2 
Usage: soffice [argument...]
argument - switches, switch parameters and document URIs (filenames).
(以下、ヘルプ画面略)


あ、ようやくヘルプ見れた。

ということはーーーー?

# libreoffice6.1 --convert-to pdf /tmp/test.xlsx
javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx
convert /tmp/test.xlsx -> /tmp/test.pdf using filter : calc_pdf_Export

できた!

何かJREが無いと引き続き怒られはしてますが、目的であったエクセルファイルのPDFコンバートが上手く動いてくれました。

このJRE無いぞメッセージは、結構昔から確認されているもののようで、ネット上にいくつか情報がありました。まぁ書いてある通り、LibreOfficeJavaを見つけられないために表示される警告です。

解決しないとCalcのアドオン周りのセッティングが出来ないといった症状が出るようです。私はコマンドラインからファイル変換が出来ればそれでよいので、修正はしませんが、GUI上で「ツール」→「オプション」→「詳細」と進んでJREのパスを教えてあげれば警告を抑止できるらしい。やらないけど。

もしかしたらインストール時に環境変数JAVA_HOMEとかを持ってれば勝手に読んでくれたかもなぁ。


xlsx->pdf変換が出来たので、作業が捗るぜと思ったら、PDFファイルがモジバケしとりました。関係無いだろうと思いつつ、ダウンロードページにある日本語パッケージを入れたがやはり文字化け。そりゃそうだよね。そういうことじゃないもんね。

色々トライエラーを繰り返して原因切り分けを行いましたが、文字化けの直接的な原因にはたどり着けず。

もしかしたら日本語環境のWindows上で作ったxlsxファイルって中身がSJISになっている?と思ってxlsxをzip展開して中身を調べてみましたが、UTF-8でしたのでCentOSでも中身を読めるはず。

ネット上で調べた感じだと、フォント設定によっては似たような現象が発生するらしいことがわかりました。何か腑に落ちませんが、GUIでファイルを開いてフォントの設定をすることで直るとか。

ここですぐにGUIでやってみればよかったんですが、私はサーバの容量の関係でデスクトップを入れておらず、空き容量も枯渇しておったので何とかGUIを使わない方法で直せないかと思案しておりました。

結果的にはこの選択が泥沼でした。要はコマンド操作やLibreのconfigらしきファイルを探して手動でカチャカチャいじってれば直るんじゃねと思っていたのですが、さにあらず。(出来るのかもしれませんが)

結局は何とか空き容量を確保してデスクトップを入れるという選択になりました。


で、デスクトップ入れました-、LibreOffice開きます-、日本語で表示されてます-

・・・え?

あれ何か日本語で表示されているのだが???

なんもしてないのに。コマンドを打って見よう

# libreoffice6.1 --convert-to pdf /tmp/test.xlsx
convert /tmp/test.xlsx -> /tmp/test.pdf using filter : calc_pdf_Export


それまでJREが無いって怒られていたのに、急に静かになった。出力されたPDFを開いてみると日本語が表示されてる...

何かよくわかりませんが、X Window入れてLibreOfficeを起動したら、文字化けが無くなっておりました。

X Window入れた時にJREが一緒に入ってきた?

LibreOfficeGUI起動をトリガーに初期設定が走って文字関連の設定がされた?

考えられるのは以上の二点。

原因を追究したい気持ちはあるものの、目的は別のところにあるためここでお終い。

時間が出来たら追及してみようと思います。(こういう時は大抵しない)

おわり

NginX+Gunicorn+Bottleでアプリケーションを公開する?

ローカル環境でPythonのBottleを使ってWEBアプリを書いて、いざ公開というときに実際のサーバ環境をどうするかで悩みました。

色々調べながら環境を作りましたが、非WEB屋の私には躓いたところも多く、悩み調べた内容、そして最終的に到達した理解の部分までこのウェブログに残しておきます。個人的な理解のため間違いもあるかもしれないですがご容赦ください。なおこのエントリでは各ミドルウェアの設定値については触れません。あくまで考え方や全体の構成についてのエントリになります。

  

1.本番でもBottleでrunするんでしょ?

WEBフレームワーク初心者の私にとっては、「BottleでrunってすればWEBサーバ動くじゃない、本番サーバでも80ポートでrunしてlistenしてればいいんでしょ?」と思っていました。

ただ調べていくとどうやらBottleのrunでrunさせるのは性能面や信頼性の観点で良くないらしい。確かにローカル仮想サーバでrunさせてる時には10回に1回くらいの割合でコネクションエラーが発生していました。

オープンソースプロジェクトとして時間をかけて進化してきたNginXやApacheと、フレームワークにちょこんと居座るビルトインサーバのどちらがWEBサーバとして優れているかといったらそりゃ前者って話なんでしょう。餅は餅屋の原理。

 

2.NginXからのSupervisorしたGunicornからのアプリケーション(Bottleなど)がトレンドなんだって

さて、どのお餅屋さんを使おうかしら、と調べていくとNginXをフロントに使ってSupervisorしたGunicornからアプリケーション(DjangoとかFlaskとかBottleとか)を稼働させるというのが最近のトレンドらしい。

  

トレンドってなんやねん!と思う気持ちもあるが、それは置いておこう。

ただ、ただただ素直に意味がわからない。

私が勉強不足なだけですが、正直何が何だか全く意味がわからなかった。NginXがWEBサーバというのは知っていましたし、アプリケーションは私の場合Bottleになるのでしょう。GunicornとSupervisorは初めて聞きました。

調べてみるとGunicornはPythonWSGIサーバというものらしい。WSGIサーバはWikipediaにこう書いてある。

Web Server Gateway Interface (WSGI; ウィズギー) は、プログラミング言語Pythonにおいて、WebサーバとWebアプリケーション(もしくはWebアプリケーションフレームワーク)を接続するための、標準化されたインタフェース定義である。

Web Server Gateway Interface - Wikipedia

 

なるほど合点!標準化されたインタフェース定義か!

って意味わからん!

 

Wikiのページの中にWSGIサーバという項があってこのように書いてある。

WSGIサーバ(WSGIアプリケーションコンテナ)は、WSGIアプリケーションを常駐させ、HTTPクライアントからリクエストを受け取るごとに、WSGIアプリケーションのcallableオブジェクトを呼び出す。これによって、クライアントからのリクエストがアプリケーションに転送される。

GunicornはWSGIサーバなので正にここに書いてあるお仕事をします。Bottleで書いたアプリケーションを常駐させて、クライアントからのリクエストが来ると適宜Bottleアプリへリクエストを渡していく。

 

ピンと来ない人もいるでしょうが、WSGI意味わからん勢は説明書読むより動かした方が理解が早いです。大抵のソフトウェアは動かした方が理解が早まると思うんですが、私は説明書を読みこむタイプなので、ガッツリ調べてしまいました。素直に動かせば何となくわかると思う。

 

私はGunicornを勉強しはじめた時に「WSGIは標準化されたインタフェース定義である」に対して「WSGIは定義?じゃあWSGIサーバは定義をServeしてくれんの?意味不なんだが!」と思ったが、そんな風に考えてはいけなかった。

だって例えば「WEBサーバ」はWEB自体をServeしてくれるわけではないし、もう少し具体的に「HTTPサーバ」と言ったとしても、Hyper-TextをTransferするProtocolをServeしてくれるわけじゃない。

あくまでも、Hyper-TextをTransferするProtocolに準拠した仕様のServiceをServeしてくれるものなわけです。WEBサーバやHTTPサーバという言葉を何となくそのまま受け入れているのであれば、同じようにWSGIサーバという言葉も受け入れなければ、それはWSGIさん差別です。HTTPサーバさんと同じようにフワっとした理解でWSGIサーバさんを受け入れられるか、オープンで優しい心を持つ者かどうか試される場と思って間違いない。

 

WEBサーバ・HTTPサーバという言葉と同水準でこのWSGIサーバのことを考えると、要はWSGIサーバというのは「Pythonにおいて、WebサーバとWebアプリを接続するための、標準化されたインタフェース定義に準拠した仕様のServiceをServeしてくれるサーバ」と解釈するのが正しいわけだ。

 

クソ面倒くさい説明を書きましたが、とにかくWEBサーバとWEBアプリを橋渡ししてくれるサーバという抽象的な理解に留めておいて問題はありません。それくらいの理解レベルで手を動かしていった方がトータルで早いです。「WSGIよくわからん...ワイ頭悪いのかも」なんて思い悩む必要は無いです。さーっとWikiを読んでざっくり理解して、設定して動かして、それから具体的な理解へ進めばよろしい。

 

さて、ここでGunicornが何となく理解できたものとすると、今回のNginX+Gunicorn+Bottleという全体構成について見通しがついた感じになると思う。大雑把に以下のような並びでリクエストを処理していくシステムになる。

 

Nginx <-> Gunicorn <-> Bottle

NginX・ ・・・フロントのWEBサーバとして動作

Gunicorn・・・NginXとBottleアプリを繋ぐ謎のインタフェース

Bottle ・ ・・・これはアプリケーション本体

 

ちなみに、ここまで登場しないSupervisorさんはGunicornさんのプロセスを管理する人になるため、全体の流れからは切り離して考えてOKです。あくまでWEBアプリケーションとしての処理はNginx <-> Gunicorn <-> Bottleの3人でワチャワチャやるものです。

 

3.インストールして繋げてみる

はてさて、ここから3人のお友達(Nginx、Gunicorn、Bottle)を連携させて求めるべき姿に仕上げていく。とりあえずBottleアプリは既にあるので、あとはNginXさんとGunicornさんを呼んでくることになる。

NginXとGunicornをインストールして、「いっせーのーせっ!」でくっ付けることもできますが、私はWEB周りはド素人だから1つずつ進めていくことにした。

これは私見100%ですが、非WEB屋さんや全くのド素人がいきなりガッチャンコでこの三人衆を繋げると、上手く接続できない時に原因の特定が難しくなるのでオススメしません。上手く接続出来たら出来たで、「何か知らんけど出来た」状態にしかならないのでエンジニアとしてどうなのよという話もあるし、運用中のトラブルなど発生しようもんなら手に負えなくなるので、やっぱり初心者は1つずつ接続を確認して誰がどういう仕事をしてくれているのか理解することが重要だと思う。

 

さて、それでは1つずつ繋げていくとして、どこを動かして繋げていけばいいか、私が辿った道を紹介します。

①Bottleの単独動作(本番サーバでrunして動作することを確認する)

②NginXの単独動作

③NginXをリバースプロキシとして動作させrunさせたBottleアプリへ接続

④GunicornからBottleアプリへの接続

⑤NginX→Gunicorn→Bottleの接続

 

①Bottleの単独動作(本番サーバでrunして動作することを確認する)

まずは開発環境で作成したBottleアプリケーションが単独動作することを確認する。これはOS設定やPython、パッケージ周りのインストールがミスってないかを確認するテストになる。ここの動作が担保されていないとNginX・Gunicornと繋いだところでうまくいかない時の原因追究が分かりづらくなるだけだから、先に単独で動かしてみる。サーバ上でlocalhost向けにcurlコマンドを打って期待するレスポンスが返って来ればそれでよろしい。

 

②NginXの単独動作

NginXを動かして外の世界からウェルカム画面やHello Worldあたりが出ることを確認しておく。ネットワークやFirewallといった外面の問題が無い事がここで担保される。

 

③NginXをリバースプロキシとして動作させrunさせたBottleアプリへ接続

BottleとNginXがそれぞれ動作したら、とりあえず繋げてみたくなるのが人情。別にこのプロセスは踏まなくてもよかったかもしれません。Bottleアプリを適当なポート(8080ポートとか)でrunさせる。NginXは80ポートでListenさせてリバースプロキシで8080ポートへリクエストを流す。NginXのリバースプロキシが動作することの確認になる。ここの確認は外の世界からブラウザアクセスするのがいいと思う。

 

④GunicornからBottleアプリへの接続

Gunicornをインストールして、GunicornからBottleアプリを起動する。Bottleアプリはrunの行をコメントアウトしておくと確実にGunicornで動作していることが確認できる。Gunicornは外から見るとwebサーバとして動作するので、curlコマンドかブラウザアクセスで確認できる。

 

⑤NginX→Gunicorn→Bottleの接続

GunicornとBottleの接続が取れているので、頭にNginXを噛ませる。NginXのリバースプロキシの向き先をGunicornに設定する。これで目的の形に。

 

ここで調べてもわからなかったことが1つ。NginXからGunicornへリクエストを流す際にIPアドレス+ポートで繋げるか、ソケット通信で繋げるか。色々見てみましたが、みんなどっちというわけでもなく、ある人はIPアドレス、ある人はソケット通信と割とばらばらのご様子でした。性能や拡張性とか保守性とか違いはあるんでしょうけど、いまいちどっちがどう優れているのかはわからなかったです。ソケットの方が速そうと思って私はソケットで繋げました。

 

WEBド素人の私がこの構成でWEBサービスを稼働させて面白いなと思ったのは、NginXは当然として、GunicornもBottleアプリもみんなやろうと思えばWEBサーバとして動作できるところです。それぞれ単独でも動かせるし、それぞれを連携させて動かすこともできる。これは想定通りに動いてくれない時に問題点を局所化出来るので、構築している時のトラブルシュートがすごく楽でした。

ただ一方でちゃんと理解しないと運用中のトラブルに対応出来ないだとか、実は間違った状態で稼働していたとかってことが起こりそうな気がします。あと理解に至るハードルが割と高い。WSGIも動かすまでは何してくれるものか分かりづらいし、構成上、中間にいるGunicornの存在は外から認識しづらいという面がある。NginXはフロントで動くので80ポートとコネクションが取れるかである程度外から挙動が見えるし、バックにいるBottleアプリは最終的なレスポンスによって動作が見える。Gunicornは動作が外から見えないのでハードルが高いです。それぞれのログを見れば動作状況はわかりますが、やっぱりド素人に対してはハードルが高く見える。

本当のITド素人がPython(やRails)アプリ作ってIaaS環境で公開することは多くないと思いますが、、、、あ、Herokuってもしかして、この辺のメンドイ所を楽にしてくれるのかしら

 

おわりに

このエントリはローカル環境で作っていたおもちゃアプリを公開しようと思い、環境面を調べていく中で、よくわかんねーなと思ったのがきっかけでした。「世の情報を集めて整理していってもイマイチ理解できない、それじゃ自分がまとめよう」と勢い込んで書き始めたのですが、長いだけで具体的な設定値も書けてないし、はたして意味があるのかもはやわかりません。

誰か一人でもいいから、このエントリが役に立ってくれるといいなと思い、筆を置きます。

 

【読書感想文】リーダブルコードを読んで、一流のプログラマーに憧れて

読書感想文です。

 

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

 

 

この本を読もうと思った理由

 

良いコードを書こう系の情報を集めていると自然に目に入ってくるほど、色々な所で評価されている本だからです。

 

私は普段SIerでサーバ屋さんやセキュリティ屋さんの顔をして仕事しているので、ぶっちゃけ仕事に直結する本ではないです。ただぼんやりと未来の事を想像すると、私が現役で働いている間にサーバ屋の仕事ってどんどん減っていくだろうなと思っているので、これからも技術者として生きていくならキチンとコードを読み書きできるスキルが必要になる。

 

特に書くってところはある程度の数をこなさないとダメで、しかも漫然と数をこなしてもこれまたダメで、武道の型のように清く正しく美しい基本を身に着けた上で書かないといけないと考えています。これまで三十余年生きてきて勉強もスポーツも仕事も大抵の事はそうでした。たぶんプログラミングも同じだと思います。

 

というわけで、清く正しく美しい型を求めて本書を手に取ってみたということになります。

 

インターネッツ上で「英語版PDFは公開されてる」という情報を見たので検索してみました。本家ではなくアーカイブサイトですけど、メモとして残しておく。

https://the-eye.eu/public/Books/IT%20Various/the_art_of_readable_code.pdf

 

 

全体の感想

読みやすい本

まず1つ目に書きたいことは、とても読みやすい本だったということ。

本書はオライリージャパンの出版ですが、とても読みやすかったです。オライリーは全般的に ”良い意味で” 堅いところがある印象ですが、読み物系やマジ初心者向け系は割と読みやすい本が多いです。この本も読み物系としてかなり読みやすいです。

「良い本とは聞くけど、ボク ”No オライリー” なんですよ」という方でも余裕で読めます。私はオライリーチャレンジに失敗して何冊か本棚のオブジェとしてしまいましたが、これは楽勝で読めました。

 

訳者まえがきに書いてあるんですが、「(コードの)読みやすさを扱った本の翻訳が読みにくいというのではシャレにならない」 とある通り、訳者がいい仕事をしてくれています。もちろん原著が素晴らしいのはそうなんだと思いますが翻訳のせいでダメになる本もいっぱいある中で、本書が読みやすいのは訳者の仕事のおかげなんだろうと読後に思いました。

内容自体もシンプルで読みやすいです。全体ボリュームは200ページ程度だし、1つの章は10ページくらい、1つの節は1~2ページです。ちょっとした空き時間や休憩時間にパラパラ眺めるのにいい感じです。

 

本書にはコードを綺麗にするために、「明確な単語を選ぶ」とか「大きな問題を分割する」などなどのテクニックが紹介されています。本書で紹介されている「読みやすい良いコードを書くテクニック」は本書の執筆にあたっても同じく使われているんだろうなと感じました。全体的に読みやすい良い設計がなされている本という印象です。

 

読み手を選ぶかもね

全体通しての2つ目の感想は、「読み手を選ぶかも」です。この本はサブタイトル「より良いコードを書くためのシンプルで実践的なテクニック」の通り、シンプルなテクニックについて書いてあります。

本書はそれなりにコードを書けるけど、効率性や美しさを追及する上級者には至らない中級者層をメインターゲットにしているんだと思います。上級者から見ると「新しいことは何も書いてなかった。自分にとって当たり前の内容ですけど。ははん。」と映る内容です(たぶん)。逆にプログラミング初心者には「CとかJSとかPythonとかいろんなプログラム言語でサンプルが書いてあるので無理。あたしRubyしか分からないし。」と思うでしょう。

基本的には何らかの言語で”アプリケーション”と呼べる代物を作ったことがあって、作れるけど綺麗でエレガントなコードを書きたいと思っている人が対象になるかと思います。

 

と思ったんですが踏み込んで考えるとちょっと違うかも。

読み手側の反応を考えると上に書いたように上級者は「ははん」だし、初級者は「むり」という反応を示すと思います。ただ書き手側の思いはまた別物だろうなと思います。上級者には知識の整理に使って欲しいし、知らないことがあったらコードの書き方をアップデートしていってもらいたい。初級者にはそれこそ早く知ってもらいたい内容という思いがあるのだと推察いたします。

 

というわけで結局プログラム書く人はレベルに依らず皆読んだ方がいい本ってことになる。うんたぶんそうだ。

 

内容が良い

3つ目は内容が良いって話です。プログラミングの基本的なお作法が纏められているので私のように独学でアプリケーション作っている人間にはとても有難い書籍でした。

一例を挙げると、変数のネーミングのところは特に刺さりました。tmpとかretvalという名前の変数を作ることがよろしくないというのは、一般論として聞いたことがあったし、実践して苦い思いもしたので理解していました。ただし本書によると、本当にその変数の役割が一時的なものである場合はtmpでいいと記載されていました。このようにtmpが本当にtmpであるならOKといった具合に名が体を表すことこそが重要だと。しかし何でも拘ればいいってもんでもなくて、スコープが狭い数行の中でしか生きられない変数であれば頭文字一文字でもOKだと書いてある。

「名前に拘ろう、tmpは良くない」というのは感覚的に理解できていたが、なぜだめなのか、どうしたらいいのか、一切合切ぜんぶダメなのか、と問われると本書を読む前だったら論理的に説明できなかったと思う。こういった内容が頭の中で整理できて、なぜダメなのかが理解できると応用を利かすことができるようになる(気がする)。

 

別の方のブログエントリで、「読みやすさと言っているけど、定量的な評価がなされていない」という意見も見かけました。確かにそうだなと思いました。こういった海外翻訳本だと綿密な調査をベースにしてこっちの方が良いとか悪いとかってことを論じる本が割にあるイメージですが、本書ではそこまでやった上で書かれているわけではありません。これについては本書内でも「最終的には個人の好みになってしまうこともある」と書かれているので、そういうことなんでしょう。本書では「一貫性のあるスタイルは、正しいスタイルよりも大切だ」ともあります。一貫して汚いコードではだめだけど、どっちの書き方でも一長一短あるよねということであれば、どちらが優れているかよりもその書き方で統一されているかのほうが大事であると。

 

メモっておきたいところ

個人的にクリップしておきたいと思ったところを簡単にまとめます。

2章 名前に情報を詰め込む

明確な単語を選ぶ

名前を付けるとき「取ってくる系だからとりあえずGET」と考えるのではなく、ネット経由ならDownloadにするとか、動作や状態を説明するよりよい単語を使う。

 

tmpやretvalなどの汎用的な名前を避ける

絶対禁止ではないけど、tmpが本当にテンポラリなのかちゃんと考えよう。変数の生存期間が長いと、あらためて読んだ時に「あれ?このtmpって何入ってるんだっけ?」となり読みやすいコードとは言えない。

 

スコープが小さければ短い名前でもいい

tmpの話とも似ているけど、数行程度でしか生きられない狭いスコープの中でだったら長ったらしい具体的な名前をつけなくても読みやすい。

 

3章 誤解されない名前

限界値を含めるときはminとmaxを使う

境界値を含む/含まないで発生する不具合をなくすために、min、maxという単語を使う。以上以下、未満の情報を名前に含める。

 

範囲を指定するときはfirstとlastを使う

start/stopで指定すると、stopが指すものが範囲に含まれるか曖昧になる。lastであればより明確に包含関係を表現できる。

 

ブール値の名前

ブール値の変数名は、より状態を明確にするために、is・has・can・shouldを先頭につけるのがいい。

 

4章 美しさ

一貫性と意味のある並び

一連のコードの中で、ある場所ではABCと並んでいるものは別の場所でも同じ並び順で書く。

 

個人的な好みと一貫性

最終的に個人の好みになってしまうこともあるが、「正しい」スタイルよりも「一貫性」のあるスタイルの方が大切だ。

 

5章 コメントすべきを知る

コメントするべきでは「ない」こと

コードからすぐに読み取れる内容はコメントに書かない。

 

ひどい名前はコメントをつけずに名前を変える

名前だけでは正確に内容を読み取れないところにコメントを書くのではなく、名前自体をわかりやすいものに変える。

 

6章 コメントは正確に簡潔に

あいまいな代名詞を避ける

「これ」「その」などの代名詞を使用することは避ける。

 

入出力のコーナーケースに実例を使う

コメントに入出力の実例を書く時は、境界値を意識して読み手の理解を促す例を使う。

 

情報密度の高い言葉を使う

コメントは長々と正確に書くのではなく、密度の高い言葉で簡潔に書く。

 

第二部以降の覚えておきたいところ

  • 無関係の下位問題を抽出する
  • タスクを小さくして、一度に1つのことを
  • ネストを浅くする(読み手の精神的スタックにプッシュする量を減らす)

 

おわりに

こりゃ良い本ですわ。

私のように独学でコードを書いている人は、コードレビューなんて受ける機会が無いので、ダメな書き方なところがいっぱいあるんだろうなと思っていたんです。本職の人もそうかもしれないですが、自分で書いて一通り動作しているコードを修正するのを極端に面倒に思ったりもします。

 

この本の内容を生かして、未来の自分が理解しやすいコードを書いていこうという気持ちが出てきました。

プログラミング初心者の方は早い段階で綺麗な型を身に着けられるし、上級者にとっては言語化されてまとめられているものとして有用だろうしと、多くの人の役に立つ素晴らしい本だと思います。ネット上で高い評価を受けているのも納得です。

 

久しぶりに気に喰わない所の無い本でした。

 

以上

【読書感想文】「LEAN ENTERPRISE」を読んで

読書感想文です。今回読んだ本はずーっと気になってたこちら。

 

リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり (THE LEAN SERIES)

リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり (THE LEAN SERIES)

 

 

本のタイトルの通り、エンタープライズ(企業)にLEAN開発の手法を適用するための方法が書かれた一冊です。

 

この本を読もうと思った理由

オライリー(出版社)がシリーズ物として出版してるんだったら多分本物なんでしょ、と前から思っていました。で、こういうシリーズ物はきちんと出版された順に読んでいきたい派なんですが、ふと図書館でこの「LEAN ENTERPRISE」だけがちょこんと棚に載っているのを見つけてしまい、巡り合せを感じ借りてきてしまいました。

 

このリーンシリーズは2012年に日経BP社から「リーン・スタートアップ」が出版されたのが最初かと思います。

リーン・スタートアップ

リーン・スタートアップ

 

 

その後、オライリージャパンがシリーズ物として、6冊出版しています。「LEAN ENTERPRISE」はオライリージャパンが出版している内の一冊です。オライリーの出版は以下のリンクにまとめられています。
O'Reilly Japan - The Lean Series

  

私がリーン開発に興味を持ち始めたのは、2015年ごろだったと思います。本屋のオライリーコーナーでRunning LEANとLEAN Analytics、LEAN顧客開発が平積みで置かれていて、ポップに「今話題のLEAN開発!」といったコメントが書いてあって気になり始めたのが最初だっと思います。

それからもうかれこれ3年、さぼっていたわけではないですが、後回し後回しになってようやく巡り合ったのがこの2018年8月というわけです。

 

全体の感想

満点!まではいかないけど、すごく良い本でした。アウトプットしたいと思える本でしたね。

 

まず本書の軸になる考え方、リーンスタートアップについて振り返ってまとめてみます。ざーっくり言うと、こんな感じです。

  1. 事業のアイディア(仮説)を出す
  2. アイディアの効果を測定できるMVP(最小限の効果を持った試作品)を作る
  3. 新しモノ好きのアーリーアダプター層に使ってもらう
  4. 効果を測定し、アイディアを捨てたり方向性を変えたり、小刻みな軌道修正を繰り返す

 

スモールスタートで始めて、短期間でユーザの関心を調べたり、ユーザの声を反映させながら、ニーズに合致した製品へ仕上げていくという考え方です。

 

本書を読んでいてビビっと来たのは、MVP(最小限の効果を持った試作品)のところですね。私はSIerに勤めているので、MVPを作る状況にはなりませんが、考え方は非常に参考になりました。

 

スモールスタートは割と知られたやり方ですが、MVPは言われると当たり前なんですけど実際に作ったって話は聞いたことがありません。技術者側の立場で考えると、最小限の効果しか持たない試作品というのは作っていて悶々とするんでしょうか。技術者だけのチームであればスモールスタートで、「小さくても完璧なモノ」を作りたくなってしまうんじゃないでしょうかね。こんなサービス作りたい!という熱意が強いほど、完璧なサービスに仕上げたくなってしまう、熱が高いほどMVP作成という効率的な開発法から離れていってしまうというの面白い事象だと思いました。

 

こういったリーン開発の手法はこれからルールを作っていく新しい組織や、容易にルールの改定が可能な小規模組織で導入しやすいです。じゃあ大きな組織でリーン開発の手法は適用できないのか?この疑問に答え、実例を交えて紹介するのが本書です。

 

 

だいぶ逸れてしまいましたが、本書を読んだ上での全体視点での感想です。

  1. LEAN開発とは、という目次項目はない
  2. ちゃんとしてる本
  3. 結構難しい

 

1つ目は本書に「LEAN開発とは」という目次項目はありません。LEAN開発とか、LEANスタートアップについて真面目に知りたいなら先述の「リーンスタートアップ」あたりを読む必要があるのでしょう。本書では冒頭に書いてありますが、理屈・理論をこね回す書籍ではありません。エンタープライズ(大企業)向けにリーンを適用しようという本なので、あくまで応用のための本になります。

といっても、リーンスタートアップという仕組みの上澄み部分だけを知りたいと考えている人には良書です。電子レンジの仕組みを知らなくても誰でも使えるのと同じです。

リーンの考え方の中で、大企業に適用することの出来る部分を詳しく書いてあるので、本書だけを読んでも問題ないと思います。リーンの理屈や全体像を知りたい人は出版された順に読んでいくのがよさそうです。

 

 2つ目は「ちゃんとしてる本」です。何を言っているかと言うと、考え方の前提がきちんと提示されているという事を言っています。開発手法とかマネジメント手法というのは、他の科学分野と同じでいきなり新しい手法がぽんっと出てくるものではありません。「誰それが研究していた何とか論ではあれがこうだと言っている」と前提になった研究や書籍がくどいほど書いてある。数えたわけではないですが、全体の3割くらいのページに引用元が記されていて、巻末の参考文献は12ページもある。読みやすいライトな論文を読んでいるような感じです。

しかしちゃんとしているが故に一般書籍としては読みづらさがある。まぁ如何に今までしょうもない本を読んできたかの露呈となるので、これ以上は恥ずかしくて書けないですが、オライリーの読み物らしさはありましたね。人に薦められるかと言ったら、本気で「組織を変えたい」と思っている人以外には薦められないですね。

 

3つ目は「結構難しい」です。一つ一つのトピックは難しくないですし、それぞれ嚙み砕いて読者にわかるように”内容”が解説されています。問題は言葉です。私は割とこういう海外の開発手法の本は好んで読むのでそこまでではなかったですが、一般的なサラリーマンが手を出すと読み切れないかもしれません。ぐだぐだ書くよりも実例を出します。本書で説明なしに使われる言葉です。

デリバリー、イテレーションインサイト、エンゲージメント、バックログ、WIP、インテグレーション、バッチ、ハードニング、デプロイ、マイグレーション、コンバージョン、ロギング

この言葉の意味や指すところがわからないと本書を読むのが苦痛になると思います。

本書のタイトルをもう一度見てみると、こうなっています。

「リーンエンタープライズ イノベーションを実現する創発的な組織作り」

特にIT系を示唆する用語がタイトルに入っていないので、一般のサラリーマンが「イノベーティブな組織を作りたい!」と思って手に取ると痛い思いをすると思います(普通のサラリーマンがオライリーコーナーに行くことは殆ど無いとは思いますが)。前述の固さと相成ってギブアップしてしまうのではないだろうか。

 

最初に戻ります。満点!とまで言えなかったのは、全体的な固さとちょこちょこカタカナ英語の意味がわからなかったところからの読みづらさです。こんな固い本だとは思ってなかったので心の準備が出来てなかったというのもありますが。

ただ内容は非常に面白かった。読み進むたびに考えさせられる良書でした。

 

ビビッときたところ

この時点で長いエントリになってしまいましたが、これは書いておきたいと思うポイントだけ引用します。

 

社会学者ウェストラムの組織の分類

病的組織は不安と恐怖が蔓延しています。人々は情報をため込んだり、政治的な理由から隠したり、自分を良く見せようと改ざんしたりします。

官僚的組織は自分たちの部門を守ります。部門にいる人は自分たちの「縄張り」を維持し、自分たちのルールを主張し、何でも自分たちのやり方でやろうとします。

創発的組織はミッションに集中します。「どうすれば目標を達成できるのか?」の質問に答え、高いパフォーマンスとそのために必要な事が何よりも優先されます。

私が勤めているSIerでは病的組織1、官僚的組織8.9、創発的組織0.1、といったところです。創発的組織は見たことがないですが、それなりの規模の会社なので無いことは無いはずという意味で0ではないだろうと。私のいる部署は超がつくほどの官僚的組織です。事前に根回しして、毒にも薬にもならない指摘を頂戴しないと話が先に進まない。そんな文化なのに、やれ働き改革だ、やれイノベーションだという耳障りの良い言葉が飛び交う。まずは自分たちの部署がどういう組織なのかを理解する必要性があるのだと思いました。

 

「プロジェクト」では、顧客に届けられた価値ではなく、仕事が時間・予算通りに完了したかどうかで人々を判断します。したがって、生産性は成果(アウトカム)ではなく、結果(アウトプット)にもとづいて計測されます。

開発者たちは、実世界で大規模に使えるようにすることではなく、開発マシンでコードを書きあげることに対して報酬を得るようになります。こうして私たちは働き過ぎと高稼働に報酬を与えてしまう持続不可能な「英雄文化」を作り出すのです。

会社や部署ごとに”俺たちのやり方”がありますが、結局下っ端は”俺たちのやり方”でやるべき作業をやることが仕事になっている。本来は予算制約の中で顧客が受け取る価値の最大化を図ることが求められるのに、いつの間にか俺たちのやり方を構成する作業をこなすことが仕事になってしまう。そしてその作業を如何に効率的に多くこなすかが評価の指標となっている。

100の価値を創る仕事に10時間をかけたら生産性は10です。今のうちの会社では(殆どの日本の会社もそうだと思うが)この仕事を9時間で済ますにはどうしたらいいかという話ばかりになっています。これって働き方改革だなんだという話が出る前からみんな頑張って取り組んでいたので、乾いた雑巾を絞る行為なんです。本物の改革を目指すならば、時間を削ることも大事ですが、結局のところは価値の量を増大させることに帰着します。当然そこには先行投資が必要になったり、仕事のやり方を変えたり、痛みが伴うことが多いですが、そうやって成果を求めていくことが重要なんだろうと思います。

 

(スタートアップ買収により)優秀な人材を獲得して病的あるいは官僚的文化に入れても、その文化が変わる事はありません。その人たちを壊してしまうだけです。

文化を意図的に変えるのは難しい事です。「文化は非常に安定的で、変革が困難」であり、「成功に至るまでの考え方、感じ方、世の中に対する認識など、グループが学び、蓄積したものを象徴するものが文化」だからです。

この部分を読んで頭をよぎったのは「組織の文化は金で買えない」ということ。買えるのはせいぜい文化を変革させるきっかけ程度のものです。

 

これらを達成してもらうまでは、問題の解決や機会の追求のために大規模な計画を開始するようなことはさせません。

・達成されるべき計測可能なビジネス成果を定義する

・成果に向かって計測可能な進捗を示せる、最少限のプロトタイプを構築する

・提案する解決策が顧客のために作られ、実際に価値を提供していることを実証する

ここはLEANの考え方が端的に書いてあるところだったので引用してみました。”計測可能”な進捗と成果を計る指標を定義し、最小限のプロトタイプを作って、価値を提供していることを実証する。

以前Yコンビネータ―の本を読んだ時も同じようなことが書いてありました。1週間の目標をたてて、測定すべき指標を追いかけて対策を立てていく。似たような考え方を持っている人の本を私が好んで読んでいるだけかもしれませんが、異なる本で同じことが書いてあると、やっぱりそうなのか、と思ってきますね。

 

従来の財務会計では、業績・キャッシュフロー・収益性比率を計測します。これらはイノベーションのために作られたものではないので、新しい製品や活動を抑制したり、殺したりする恐れがあります。

 これは本書を読んで一番ビビビッときたところです。

私が務めているSIerでは厳格に業績が管理されていますが、それはSI事業であっても新事業計画でも同じ方法で管理されています。SIerではSI事業がベースになっているので、業績管理もSI事業を前提に考えられています。予算や納期、品質、使う技術などを長ったらしい計画書にまとめ、計画通りに予算を使いながら納品して、計画以上の利益を上げるというものです。

ただ新事業計画なんて不確実性だらけなんだから通常のSI事業並みの精度で計画を作ることなんて無理なんです(ちなみにSI事業にしてもそんなに高い精度で計画作れないですが)。じゃあ不確実性に対する予算をまとめてプールしておけばいいじゃない、と思う人もいるでしょうけど、業績管理システムはそんな入力項目を用意してくれていない。私が勤めている会社では不確実性なんてものはそもそも存在しないことになっています。そんなものがプロジェクトにあるんだとしたら「なぜ見積もりをすることができたのか?」という話しになり社内でボッコボコにされる。プロジェクトには不確実性が存在することをみんなが認識しているのに、社内のルール上、業績管理システム上は存在しないことになっている。表面上は会社のルールに従い、実態は不確実性に対してみんながそれぞれ独自の対処をしているのが現実です。工程ごとに多めにバッファを積んだり、計画外の要員に内緒で作業をさせたりとかやり方は色々あるようですけど。

これってすごくアホらしいんですよ。不確実性を無いものとするってのは、ただの会社や管理職の保身から出る理屈であって、プロジェクトを管理して多くの利益を生み出したいというプロジェクト管理の基本的な考えからは遠く離れています。大抵の場合は何だかんだ上手く終われているやり方ではありますが、やはり新事業をやるうえでSI事業と同じような考え方ではうまくいかないのだと思います。

本書を読んで特に考えさせられたのはここで、明確に書いてあるわけではないですが「不確実性とお友達になる」というのがリーン開発の本質なんじゃないかと思いました。不確実性を溜め込めば溜め込むほど爆発した時の威力が高いので、ほどほどにガス抜きさせてやって大爆発させないようにうまく付き合っていくのが大事なのではと。

 

小さく分散した自律的なチームをたくさん作る事です。本当に分散した組織は、補完性原則に従います。つまり、基本的に決定というものは、その決定によって直接影響を受ける人たちが下すべきなのです。官僚組織の上位レベルは、下位レベルでは効果的に行えないタスクのみを実行すべきです。上位レベルは下位レベルを「補完」すべきということです。

この考え方は初めて知ったのでメモっておく意味で引用。

以前、読書感想文を書いた「SEの教科書」にあった「上流工程で作り込んだ問題をプログラマが対処する。原因を作り出したところには、具体的な苦痛は無い場合が多い」という話と似ているなと思いました。微妙に対象が違う話ではありますが、本書に書いてある内容はより積極的に上位下位のそれぞれの人たちが”すべき事”に注目している点が面白いと感じました。

 

予防的コントロールを間違ったレベルで実行すると、不必要に高いコストをもたらします。

・簡単に自動化できる単純なタスクなのに、他のチームに実行をお願いしなければいけない。

・リスクを理解できない人から承認をもらう必要があるが、その人が多忙なのでボトルネックになっている。

・完成してもすぐに時代遅れになる不正確なドキュメントを大量に作らなければいけない。

・大きなバッチをチームや委員会に渡した後、その処理や承認が終わるまで待たなければならない。

私はSIerで金融系システムを担当することが多いのですが、これ全部あてはまる。もちろんガッチガチの運用をしているので、不必要に高いコストと一言で片づけるのは乱暴でそれが必要になった背景もあるんですが、全項目に「そうだそうだ」と思う所がある。権限や責任を厳密に定義しすぎると遅くなる(コストがかかる)という話です。アウトプットしたいと思ったのは、権限や責任所在の厳密さと、スピードやコストはトレードオフであるということ。何かまずい事が起こった時に再発防止策が実行されますが、これによって責任所在が明確になり権限が絞られていく。これ自体が悪い事ではないですが、業務の全てにこの考え方を適用していくのは誤りだと思います。金融系でガチガチのチームにいると、この再発防止の考え方がスタンダードになってしまって、何でもかんでもこの考え方を適用していってしまう。何でそうなるかと言うと、責任範囲が厳密に決められれば他の事を考えなくていいので楽になるからです。こうなると段々と上で引用した病的組織、官僚的組織の色合いが濃くなっていき、創発的組織が持つ要素は失われていく。そしてこの考え方は”文化”としてそこで働く人の心に刻み込まれる。

なので金融系SIのようなガチガチな仕事をしている人は特にこの責任所在の明確化とスピード・コストのトレードオフの関係性は強く意識して、対象の仕事によって使い分けないといけないと思う。

 

改善には決して終わりがありません。

これは覚えておきたい良い言葉なので引用。改善に取り組んですぐに良い結果が出るばかりではないですが、当たり前のように続けていくことが重要なんだなと。

 

おわりに

ここまで書いてあらためて振り返ると、良い事がいっぱい書いてある本だったなという印象です。個人的には読みづらさも感じましたが、内容はとても良い。特に基本的な考え方の部分でMVP(最小限の効果を持った試作品)は覚えておきたい。少し不思議なのは、仕事の中で資料作りをする時は、時間をかけずに粗い骨子を作ってレビューを受けるんですが、新事業や新しい取り組みの話になるとその考え方がスパッと頭から無くなってしまうということ。会社の中で予算のルールがあるからという理由もあると思いますが、なぜだか試作品を作るという考えがスパッと消えてしまう。

後は文中にも書いた「不確実性とお友達になる」。不確実性は見えないものなので、蓋をして隠しておきたいと考えてしまいますが、うまく付き合ってコントロールしていくことが重要なんだと思いました。

 

このリーン開発はとても面白い手法だったので、今後少なくともエリック・リースのリーン・スタートアップは読んでみたいと思います。

 

おわり

 

MariaDBの設定テンプレファイルが見つからないの巻

MariaDBのコンフィグテンプレファイルが見当たらなかったのであれこれ調べた内容を書き残しておく。

 

長くなったので結論だけ先に。

  • MariaDB v10.3.2以降には、それまで設定例として含まれていたmy-small.cnfなどのテンプレファイルは無くなった。
  • 基本はデフォルト値で導入して明確に実現したい要件があればconfファイルに書き込む。


 

インストールした日:2018/07/15

データベース製品 :MariaDB 10.3.8  database server(現在時点で最新)

インストール方法 :レポジトリを追加してyum

OS:CentOS 7.4

稼働環境:Oracle Virtual Box

 

事象(困ったところ)

インターネッツの情報を参考にMariaDBをインストール、それから初期セットアップのためにcnfファイル(config)の設定テンプレをコピーしようとしたら、テンプレファイルが見つからなかった。以下のようなテンプレファイルが/usr/share/mysql/ ディレクトリ配下に存在することを期待していたが無かった。

my-small.cnf
my-medium.cnf
my-large.cnf
my-huge.cnf
  

もう少し詳しくやった事を書いておく

最初は公式の情報からレポジトリを追加してyumで本体をインストール

MariaDB - Setting up MariaDB Repositories - MariaDB


次に /usr/share/mysql にあるmy-large.cnfファイルをコピーして/etc/my.cnf.dディレクトリにserver.cnfの名前で保存する。が /usr/share/mysql ディレクトリにmy-large.cnfが見当たらなかった。

 

$ ls -l /usr/share/mysql/ | grep cnf
-rw-r--r--. 1 root root 3479 72 18:31 wsrep.cnf


インストールに失敗したのかしら?設定の考え方が変わったのかしら?と思い悩みながら、とりあえず今のコンフィグの状態を見てみる。

 

$ cat /etc/my.cnf
#
# This group is read both both by the client and the server
# use it for options that affect everything
#
[client-server]

#
# include all files from the config directory
#
!includedir /etc/my.cnf.d

 

これはインターネッツの情報通り/etc/my.cnf.d配下のファイルをインクルードしておられる。/etc/my.cnf.d配下を見てみると、こうなっている。

$ ls -l /etc/my.cnf.d
合計 12
-rw-r--r--. 1 root root 763 72 16:34 enable_encryption.preset
-rw-r--r--. 1 root root 232 72 16:34 mysql-clients.cnf
-rw-r--r--. 1 root root 1080 72 16:34 server.cnf

 

インストール後のデフォルト状態のserver.cnfを見てみるとこう。

$ head /etc/my.cnf.d/server.cnf
#
# These groups are read by MariaDB server.
# Use it for options that only the server (but not clients) should see
#
# See the examples of server my.cnf files in /usr/share/mysql/
#

 

#5: # See the examples of server my.cnf files in /usr/share/mysql/

/usr/share/mysql/ ディレクトリにあるサンプルを見ろ、と書いてある。

 

ネットで調べた初期設定手順では/usr/share/mysql/my-****.cnf をコピペしなはれと書いてあった。server.cnfには /usr/share/mysql ディレクトリを見てみろと書いてある。

 

でも/usr/share/mysqlディレクトリにはテンプレコンフィグファイルは見当たらない。

findコマンドで検索してもmy-****.cnfというファイルはシステム上に無い。

 

 

インストール時に変なパラメータを渡したわけでもなく、素直にインストールしたしエラーも無く完了していたはずなんだけどなぁ。

 

あるはずのファイルが無いってのはやっぱり何かがおかしい...でもMariaDB自体は普通に起動できている...configのテンプレファイルだけ欠落しているとは考えづらい。

 

ここで「まぁ動いてればいっか。ダメならダメで後から何か症状が出るっしょ」と考えられないのが、金融系SEとして調教された人間の考え方である。

 

調査

テンプレファイルが見当たらないというワードで調べたが、ぱっと見た感じ「同じ状態になってオラ困ったぞ」という情報も見当たらない。

やっぱりインストールの時に何かやらかしてたのかなぁと不安になったが、以下の情報を発見。

mariadb.com

上記リンクから引用します。

The following my.cnf example files were included with MariaDB until MariaDB 10.3.1. 

Google翻訳
次のmy.cnfサンプルファイルは、MariaDB 10.3.1までMariaDBに含まれていました。

 

今回インストールした最新版(v10.3.8)では含まれていないということか.....

 

さらに調べたらこんな情報も発見

https://git.launchpad.net/maria/commit/support-files?id=7fee164faf8fce7be4ebe322d2178efd3d075eae

  

このローンチパッドというサイトは公式からリンクされているページです。以下のMariaDB公式サイトの中段あたり「LaunchPadリポジトリ」から飛べます。GitHubとの住み分けがよくわからんけど、公式からリンクされているちゃんとしたソース管理システムです。

MariaDB はどこでダウンロードできるの? - MariaDB Knowledge Base

 

LaunchPadのページから引用

Remove dated my-{size}.cnf files

The dates on the these files shows they are very dated. Following the sentiments of MDEV-9882 the default values are quite decent so lets remove this old stuff.

Google翻訳
これらのファイルの日付は、日付が古いことを示しています。 MDEV-9882の感想に従えば、デフォルト値はまともですので、この古いものを取り除くことができます。

 

ここから更にもう1つ情報を発見。上記引用文中にあるMDEV-9882でググって出てきたページ。どういうサイトかはわからないけど、製品の不具合なんかを投稿するサイト?

[MDEV-9882] Lack of config defaults in 10.1.13 - JIRA

 

コンフィグデフォルトファイルが無くなった!と登録された内容に対して、Sergei Golubchikという人(ググったところMariaDBのChief Architectという立場らしい。要は中の人)のコメントにこう書いてあった。

 

This is intentional. We set generally useful defaults in the server. Configuration files are for the end user to modify the defaults, not for us to set them.  

Google翻訳
これは意図的です。一般的に有用なデフォルトをサーバーに設定します。設定ファイルはエンドユーザがデフォルトを変更するためのものであり、私たちが設定するものではありません。

 

つまりちゃんとしたデフォルト値を設定しているから、基本はデフォルトで使って大丈夫よと、で変えたいところは変えてくれよと、そういうことなのねきっと。設定の考え方が変わったと。

 

MariaDBのセットアップ手順を紹介しているサイトのいくつかは、テンプレのcnfファイルコピーをせずに、キャラクタセットだけUTF8に変更しているものがあったが、あれが正解なのかもしれない。

 

よっぽどメモリ使用量を制御したいといった要件がなければ、デフォルト+文字コードくらいで運用を開始してもいいのかも。まぁ厳しい要件で環境構築することになっても結局はメモリの動きなんかはある程度動かしながら挙動を見ていくことになるので、いずれにしても最初はあまり細かいことは考えなくていいのではないかと思われる。  

 

ちなみにではあるが、実は途中で調べるのが面倒になり、過去のバージョンであるv.10.2系をインストールしてコンフィグテンプレ(my-large.cnf)を抜き出し、最新のv10.3.8に投入するという少々乱暴なやり方でやってみていた。

 

でもやっぱしそれじゃいかん、気持ち悪いと思ってちゃんと調べ直したのですが、過去バージョンに含まれるコンフィグテンプレファイル(my-large.cnf)を投入しても別にエラーが出たり起動しなくなるといった事はありませんでした。

 

目に見えるエラーや警告は無かったので、あのテンプレはあのテンプレで特定のシチュエーションには使えるもののように思えます。もちろん廃止されているパラメータなんかもあるかもしれないので、それは調査しないと危険ですけど、とりあえず動かす分には動かせると。

 

おわり