以下のような状況で、差分をメインブランチに反映するお手軽な方法。
開発ブランチの開発が終わった段階で、devブランチの差分を上書きするには、以下の手順を実行する。
$ git diff REL_14 dev > diff.patch
$ git apply -p1 ./diff.patch
devブランチで追加したファイル群をgit addでインデックスに追加するのを忘れないように。
$ git commit
$ rm diff.patch
2013年9月*1に招致が決まったオリンピックがやっと終わったらしい。らしいというのは、TVがないとオリンピック関連の動画はyoutubeをはじめどんな動画サイトであろうと1秒たりとも観ることができないためで、さすが映像権などあらゆる権利をガチガチに管理して金儲けに邁進する世界最大級の商業イベントである。
「温暖で晴天の日が多く、選手たちが自分の力を思う存分発揮できる理想的な気候」の下*2、106人中30人しか棄権しなかったマラソンや、1人しか吐かなかったトライアスロンなど、快適な環境で競技が行われたようで何よりである。
オリンピックが始まる前から英語圏での情報は酷いものばかり*3であったが、YAHOOのヘッドラインは別の世界線のように世界中諸手を挙げてオリンピックを歓迎、日本のオモテナシに感嘆しているように見えたのでよかった。やはり母国語で心地よい文章だけを読むのは精神衛生上非常によい。
もちろん開会式も閉会式も1秒たりとも観ていないのであるが、文化的にも文明的*4にも日本の国力を反映した非常によい開閉会式だったようである。ゲーム音楽や東京音頭まで飛び出したようで、国際的なイベントで自国民のノスタルジーにのみ訴えかけるという、内向き後ろ向きの出し物というのも自国開催の特権である。他国の視線など気にせず、165億円もの巨費を投じて自国民にしか通じないコンテキストの出し物をだせて、(結局何人辞めて、最終的に誰が担当なのかは知らないが)企画の人間も大満足だろう。
費用といえば、開催決定時に「これで東京のインフラを再構築できる」など開催を歓迎する声が多数あり、それを聞くたびに「コンパクト五輪、世界一金がかからない五輪と言ってるのに頭おかしいのか」と常々思っていたのだが、頭がおかしかったのはこちらだったようである。 なにせ現時点で3兆円を超え、これにチケットの払戻しや競技場の維持費など、4兆円を超える額がこのオリンピックに投入されるようで、これだけの金額が市場に流れ込めば、アテネやリオはじめ五輪後に経済クラッシュした他国の例に反し、経済も安泰である。 もちろん金の配分には仲介業者の介在が不可欠であるが、未開の発展途上国でもない限り、50％も80％もピンハネされるはずはないから安全安心である。
オリンピック期間中の感染爆発により、日本だけで観測されていた世にも奇妙なPCR検査否定論者*5が続々と検査しろ派に転向しているのも良い傾向だろう。 そもそもPCR否定論は2020年オリンピック開催のために感染者数を正確にカウントしたくなかった人たちの方便*6であり、終わってしまった今は否定する意味もない*7 *8。20兆円というコロナ予備費の使い残しも、パソナなどを使って迅速に国民に還元されるだろう。
*1:311からわずか2年半後で、10万人以上が避難生活していた時期だ。
*2:開催決定時に開催反対を表明すると非国民呼ばわりしていた人たちも、さぞかし爽やかな夏の日々を過ごしたことだろう。
*3:https://www.thesun.co.uk/sport/tokyo-olympics-2020/15640779/swimming-triathlon-poo-ecoli-water-games/ https://www.foxsports.com.au/tokyo-olympics-2021/swimming-in-poo-fears-of-sewage-leak-in-olympic-venue/news-story/9152e330a7dc15866a02646810cbd96b
*4:一番の出し物のドローンがIntelのものだったそうで。
*5:ワクチン否定論は世界各国で観測されたが、PCR検査否定論、しかもそれが主流というのは日本だけ。
*6:「日本の夏は温暖」「メルトダウンした原発はアンダーコントロール」と堂々と嘘をつく人間が2020年時点でも開催の可否について実権を持っていたことは事実であり、実際に1年延期したことも事実である。
*7:『日本はCTがあるからPCRはいらない』とか言ってた人たちも、さすがにもう消えたようである。CTでわかるということはすでに肺炎初期なので、それまでに感染してウイルスをかなりばら撒いている。PCRなら頻度をあげればばら撒き始めに検出できる。ま、PCRを受けたくても国が拡充しない方針なら検査できないで感染する不安に駆られるのは当然かもしれないが、だからといって馬鹿でもわかる簡単な扇動に乗っかってはいけない、あくまで「検査させろ」と主張しなければならない。検査しないということはログなしでトラブルシューティングするようなもので、計測しなければ予防はおろか実態把握すらできないのだが、それがわからない人間が自称エンジニアのなかにも相当高い割合（過半数以上、というかほぼ100％、判を押したような否定論を述べるかリツイートしていた。）いたというのは、、、、、実はそれほど驚きでもなかった。これに限らず明らかに意図的な誘導を試みているネットの意見に簡単に乗せられていくのをこの10年くらい観測し続けているので。驚くほど均質で、昆虫の群れを観察しているような感覚になる。
*8:実際、政権与党は昨年から事務職まで含めてPCR検査しているし、無理やり開催するためにオリンピックで選手含め関係者は頻繁にPCR検査をすることも周知になってしまったので、今更否定論を続けるのも苦しいだろう。さらにワクチン摂取しても(重症化率は下がるがそれでも)感染する(水疱瘡並の感染力を持つという)デルタ株がドミナントになって昨年のイタリア、スペイン、ニューヨーク並の事態がこれからやってくるのが確実なわけで、Take care. 実際、デルタ株、ラムダ株は洒落にならん。
そろそろCentOSでは対応が面倒な場面が増えてきたので、Ubuntuに移行すべく作業中。であるが、不慣れなので思ったように作業が進まない。
CentOS on Vagrantだとrootのパスワードはvagrantだが、Ubuntuは違うらしい。以下のコマンドでパスワードを設定できる。
$ sudo passwd root
とりあえず以下を実行。
$ sudo apt update $ sudo apt install build-essential $ sudo apt install bison flex $ sudo apt install binutils
追加で以下も。
$ sudo apt install libreadline-dev $ sudo apt install zlib1g $ sudo apt install zlib1g-dev $ sudo apt install libssl-dev
さらに以下も。
$ sudo apt install gdb
以下で良さげ。
$ sudo snap install emacs --classic
最新版のUbuntuを入れたら、Pythonは3.9だった。ラッキー。
しかしUbuntuはpipを独自拡張しているらしい。なんだそりゃ。
$ sudo apt install python3-pip
後々面倒が起きそうで嫌な感じである。
とりあえず定番のscikit-learnを、numpyやpandasと共に。
$ pip install numpy scipy joblib matplotlib scikit-image pandas $ pip install -U scikit-learn
ついでTensorflow+Keras.
$ sudo pip3 install tensorflow $ sudo pip3 install keras
たまにしか使わないのでいつも「perfだっけ？gperfだっけ？」とプロファイラの名前から検索している。 あまりにも効率が悪いのでここに使い方メモを記す。
gprofはbinutilsに含まれるらしい。
$ sudo yum install binutils
configureに--enable-profilingオプション(と--enable-debugオプション)を設定して実行。これで-pg ( と-g)オプション付きでgccが実行される。
特に準備は不要で、PostgreSQLを起動すればよい。 停止したプロセスのgmon.outが data/gprof/"プロセス番号/gmon.out"に書き込まれる。
$ find data/ | grep gmon data/gprof/2766/gmon.out data/gprof/avworker/gmon.out data/gprof/2776/gmon.out data/gprof/2775/gmon.out data/gprof/2774/gmon.out data/gprof/2768/gmon.out data/gprof/2770/gmon.out ... 略 ...
よって、ある一つのSQLのプロファイルを行いたい場合、(1)SQL毎にpsqlでプロセスを立ち上げ、(2)pg_backend_pid()でプロセス番号を確認して、(4)SQL*1を実行、(3)実行後は即座に終了、する。
$ psql testdb
psql (14beta2)
Type "help" for help.
testdb=# SELECT pg_backend_pid();
pg_backend_pid
----------------
2774
(1 row)
testdb=# SELECT count(*) FROM a1, a2;
count
-------
2000
(1 row)
testdb=# \q
最も単純に結果を知るには、以下のようにする。
$ gprof ./bin/postgres data/gprof/2774/gmon.out Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 12.50 0.67 0.67 166400001 0.00 0.00 ExecNestLoop 12.12 1.31 0.65 332803335 0.00 0.00 ExecInterpExpr 12.03 1.95 0.64 166403415 0.00 0.00 heapgettup_pagemode 6.02 2.27 0.32 166403328 0.00 0.00 SeqNext 5.83 2.58 0.31 499241656 0.00 0.00 MemoryContextReset 5.45 2.87 0.29 166403415 0.00 0.00 heap_getnextslot 4.70 3.12 0.25 739109 0.00 0.00 heapgetpage 4.51 3.36 0.24 166401650 0.00 0.00 ExecStoreBufferHeapTuple 4.51 3.60 0.24 166400005 0.00 0.00 fetch_input_tuple ... 略 ...
昨年末からコツコツと仕事の合間に作っていたプロダクトを今朝、リリースした。
思いの外時間がかかって結局7ヶ月強費やしたが無事リリースできた。(一応アリバイ作りのような感じで仕事の方は昨日会社のリポジトリにPushしておいた。)
で、ワクチンである。
なんだかんだ言って血栓など万が一のリスクもあることは承知の上で*1、それでも打たないことには日本含めてどこにも移動できないため、上のプログラムができた段階でワクチンを打つことにしていた。 で、今予約をして明日7月30日と来月8月27日にワクチンを打つことになった。 明日以降反応が無くなっていたら、ワクチンの影響ということで。
世界の製薬会社TOP3のうち2社があるスイスのくせに、ヨーロッパの中ではワクチン供給が遅れていた。しかし、それでも5月頃には普通にワクチンが打てるようになっていた。承認されているのはファイザーとモデルナ。アストラゼネカは承認されていない*2。
システムは完全にネットでの予約制で、まずはサイトに登録し、希望日の状況をみて予約を入れるシステム。 登録できるのは健康保険に入っている人間で、ということは住民登録している人間は原則的に登録可能。 逆に言えば、他のヨーロッパ諸国と比較すると非常に少ないがそれでもごく少数いるホームレスは打てない。これはなあ、と思う。この辺りはスイスは冷たい。
アイルランドでもそうだったが、公共機関のどのようなサイトであれ、インターフェイスの設計がどの国もどの組織も同じような作りになっていて、入り口のサイトにさえ辿りつければほとんど迷うことはない。こういう、ユーザとのインタフェースが整然としている”システム”をみると、内部のモジュール間も整然と設計されているだろうなと思うし、そもそも”システム”というものを皆が理解して作り、メンテし、使っているのだろうなあと感じる。
閑話休題。
2回分の予約を同時に入れなければならないが、2回目の日付は4週間後に固定で選べるのは時刻だけ。当たり前か。
今月中旬にドイツやベルギーで大洪水が起きたように、この夏はヨーロッパ全土で豪雨、雷雨が多く、スイスも例外でない。 明日ワクチン注射を決めたのは、直近の１週間で予報が曇りなのは明日の午前中だけだったからだが、8月27日がどうなっているかは不明なのでちょっと怖い(非常に雷雨が多い)。
*1:家系的にその手の疾患が多いし、その手の数値が子供の頃からちょっと悪い。
先月話題になったこの件、欧州の航空会社は血栓の恐れからワクチン摂取者の搭乗を見合わせるよう勧めていることからも、公に懸念されるほどのリスクがある。
Sky News: Airlines are addressing the problem of blood clots and are recommending VACCINATED people not to fly due to latest scientific insights and possible lawsuits. pic.twitter.com/lwWoDVKxjm
*2:日本でもアストラゼネカは承認したが公的には使ってない。 https://answers.ten-navi.com/pharmanews/20139/ なぜワクチンと名がつけば無条件にOKな人が多いのは何故だろう？ どんなものであれ良いものも悪いものもあるから、個別に判断しなけりゃならないと思うのだけども。「ワクチン、調べたけど原理的に問題ないっしょ」なんて、治験結果も論文も読み込まずにそこらのまとめサイトの情報だけで言い切るなど、命に関わる部分についてなぜそれほど雑な理解で安心できるのか、いつも不思議に思っている。
機械学習*1の手法を使ってPostgreSQLのモニタリングとパフォーマンス向上を目指す目的で開発していた pg_plan_inspectorというフレームワークを公開した。
とりあえず動画を。
この動画は、クエリの進捗を推測して表示するモジュールのデモ動画である。
詳細はREADMEを参照。
このフレームワークの開発動機は以下の2つ:
このフレームワークはまだ開発が始まったばかりで、POC(Proof Of Concept)モデルである。
現時点で開発動機の1.については達成できた。
開発動機の2.については、簡単なツールでテーブルの属性間の関数依存性を抽出し、拡張統計(Extended Statistics)を設定すべき候補をリストアップすることができることを示した。詳細はREADME-tools参照。
今後について、現時点では2段階の開発プランを持っている。
現時点でクエリの進捗を推測するために、線形回帰モデルでOptimizerの推定したPlan Rowsを補正している。 逆の見方をすれば、Optimizerが推定する際に補正してもよいはずである。
実際、同様のアイディアは(アプローチや実装方法は異なるが)pg_plan_advsrが既に実現している。
よってStep 1では、回帰モデルで得たパラメータをPostgreSQL側に渡し、Optimizerの推定値を補正する機能を実現する。
それから、今はアドホックな手法で関数依存性を抽出しているが、そのアルゴリズムも改良する予定。
これまでの実装の過程で、線形回帰モデルによる補正はNested Loopには比較的有効であることがわかったが、 Hash JoinやMerge Joinでは補正が難しい場合が多いこともわかっている。 また、テーブルの属性間に関数依存性があるとPostgreSQLのoptimizerは不正確なPlan Rowsを推定してしまい、線形回帰モデルでは補正できない状況になることも多い。
これらの問題に、近年ではAI(もしくは広く機械学習)の手法を使ってアプローチする論文やプロトタイプが数多く発表されている。 詳細はリファレンスの[6]や[7]などを参照のこと。
リファレンスに示したシステムのうち、いくつかはgithubでソースコードが公開されているので、使えるものは取り込んでしまおうと思っている。
またこれらは研究が目的であるため、純粋に正確なCardinality Estimationを得るアルゴリズムの開発を主眼としているようだが、 こちらは開発者なのでうまく動けばどのアルゴリズムでもよいし、実行後の結果を(教師データとして)フィードバックして学習をブーストすることも可能ではないかと目論んでいる。ま、この辺りは確証もない単なる思いつきである。
GithubというかGitの使い方。
あるプロダクト(ここではpostgresとする)のリポジトリをclone して、devブランチで独自機能を開発していたとする。 それを新たなリポジトリ(ここではmy-pgsqlとする)に移行して続きを開発する場合の手順。
最初は以下のような状態と仮定する。
$ls /home/vagrant/tmp postgres $ cd postgres $ git branch * dev master
GitHubに空のリポジトリを作成してcloneしてもよいし、直接git initで作成してもよい。とにかく以下のディレクトリ にリポジトリを作成する。
$ pwd /home/vagrant/tmp $ git clone git@github.com:s-hironobu/my-pgsql.git
リモートといいつつ、ファイルベースでリポジトリ を指定する。
$ cd my-pgsql $ git remote add local_repo file:///home/vagrant/tmp/my-pgsql/
あとはgit pullを実行すればよい。pullするブランチ(今回はdev) の指定を忘れずに。
$ git pull dev
Githubにpushする場合、リモートホストを削除して、git pushすればよい。
$ git remote remove local_repo $ git push
