ついにスクスタがリリースされたので、どっぷりハマってます

 

 HTC U12+ を使い始めて、1年以上が経過しました。今でも私のメイン端末であり、大事に使っています。大事に使っていますが、酔っぱらって帰った日に勢いで?ガラスフィルムを剥がすという凶行をしたりしましたが、はい、大事に使っています。剥がした理由は私にもわかりません。

 

 さて、そもそもこの端末は私がとある3Dゲームを行うための端末として選んだものです。そのゲームの発表があったのが2017年、リリース予定とされたのが2018年、実際にリリースされたのが2019年9月末・・・と、長く長く待たされたわけですが、やっとリリースされたので、どっぷり遊んでいます。正直このままなかったことにされるのも覚悟してた。

 

 そのゲームこそが、そう。

 

Screenshot_20190925-212311

 ラブライブ スクールアイドルフェスティバル オールスターズ

 今日は下手糞ながらもこれのレビューでも・・・。というわけで今回はただのオタ記事です。興味ない人はここで回れ右。

続きを読む

Visual Studio Codeでもっと雑に背景画像を設定したい

 気が付けば8月どころか9月も終わりそうで大慌てしている僕です。御機嫌よう。相も変わらず社畜業に

 

 以前、「Visual Studio Code のデバッグコンソールとかに背景画像を設定したい」という記事でVScodeの背景画像を設定する方法を書きました。あの方法ならエディタ部分の背景、コンソール部分の背景など個別に設定するのには向いています。

 が。
 「そんなに細かく設定はいらなくて、1枚だけビターンと全体的に反映させてはい終了!みたいな、もっと雑でいいから楽に設定したい」という要望が出てきました。自分の中から。なのでもっと簡単な方法を紹介しときます。これもまた、CSS詳しい人なら最初から思いついてそうな内容ではありますが。

 

◆やり方

 基本的なやり方は同じで、CSSファイルをいじるだけです。前回の記事では書き忘れましたが、CSSファイルの場所は

C:\Users\{ユーザー名}\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench

 です。ユーザー名部分は適宜置き換えてください。CSSファイルはVer1.38.1時点で「workbench.desktop.main.css」です。少し前までは「workbench.main.css」というファイル名でしたが、最近変わりました。今後も変わっていくかもしれないですね。
 ファイルの末尾に、以下の感じで追記します。

body {
    background: url("///C:/vscode_custom/backgroundimg.jpg") no-repeat;
    background-position: left top;
    background-size: cover;
    opacity: 0.7;
}

 以前は「.monaco-workbench .part.panel」という名の要素だかクラスだかを指定してましたが、全体に貼り付けるだけならそんな深い階層探さなくても、「body」で全体的にはっつけちゃえばいいわけですね。

 

image

  適用した感じはこんな感じ。エディタやコンソール、そしてエクスプローラーやウィンドウバーなど全体に背景画像が設定されていますね。これでええやん!

 もちろん使用する場合は自己責任で、となりますが、これで皆さんも開発中のモチベをUPさせて、快適な 社畜ライフ プログラミングタイムを送れるようにしていきましょう。

U12+でUQモバイルに乗り換えたら、快適になったけど、うっとうしいSMSが届く

 

 お久しぶりです、OD-10Zです。炎上案件がたて続いててめっきり更新頻度が落ちていますが、私は元気です。

 

 さて、私は長いことIIJを使っていました。MVNOですから、通信速度が遅いことはふつうに我慢できたんですけど、ここ最近は速度よりも、通信が中断される頻度がめちゃくちゃ高いことが気になっており、かなりのストレスになっていました。なのでここは思い切って乗り換えることにしようかな、と……。メイン端末は今もSIMフリーのHTC U12+なので、こういう時に乗換のハードルが低いのはありがたいですね。
 乗換先として検討したのはUQモバイルです。2週間ほど無料でお試しが出来るトライSIMがあるので、まずはトライSIMに申し込んでみました。

 

Screenshot_20190707-123330 Screenshot_20190707-123336

 

 届いたSIMをぶっ刺すと、↑のようにUQモバイルのAPN設定がデフォルトで用意されているので、それを選ぶだけで設定切り替え完了です。楽ちんね!

 

Screenshot_20190624-121941

 

 UQモバイルはIIJと同じMVNO……といってもKDDIのサブブランドですから、速度はかなり速いです。昼時でも30Mbps以上出てるのでかなり快適です。そしてIIJのときの不満点だった、頻繁に発生していた通信途絶も、UQモバイルでは全然発生しません。この時点でかなり満足です。

 

Screenshot_20190624-210450

 平日の夜、会社を出たところで試してみたら、びっくりするような数値も出てきました。これ自宅回線よりはえぇわ……。

 

 

 

 と、いいこと尽くしで乗換を即決しようとしていたのですが、ここで問題が発生。それが、

image Screenshot_20190625-141435

 この、頻繁にSMSで届く鬱陶しいニュース

 Webで調べてみると、どうやらKDDIが緊急地震速報の仕組みを使って配信しているメールとのことで。仕組み上、これの配信を止めることは出来ません。届く内容は色々ですが、時期的に芸能系のニュースがやたら多くて、かけらも興味がない自分としてはこれのストレスが半端なかったです。

 

 対策は、これの送信先をブロックするだけなのですが……。U12+の問題なのかなんなのか、普通に届いたSMSをロングタップ → 連絡先をブロック としても止まりませんでした。なんでだろなーと思って色々試したところ、「連絡先に登録したうえでブロックすれば止まる」ということがわかりました。(保証は出来ませんが、私はこれでピタリと止まりました)

 

Screenshot_20190709-085415

 迷惑SMSを送ってくる番号は現時点では

 ・9701060
 ・9711060
 ・43009
 ・43013

 の4つだったので、それを全て登録します。(自宅とか勤務先とかの種別は別にどれでも構いません)
 名前はてきとーに「迷惑SMS」とでもしときます。

 

image Screenshot_20190709-085250

 登録したら、メニューにある「連絡先をブロック」をタップし、確認メッセージでOKを押します。

 

 

image

 これで無事に、迷惑SMSが届かなくなりました。やれやれ。

 

 

 連絡先として登録しないと(何故か)ブロック設定をすり抜けてくる、ということに気付くまでに時間がかかり、乗換を躊躇ってましたが、これで個人的には問題なくなったので、MNPしました。今ではUQモバイルで快適ライフを過ごしています。今のところは特に支障はありません。

PostgreSQL:テーブル・カラム情報をクエリで取得する

 テーブル一覧を取得したりカラム一覧を取得して、あれこれしたい、というときは結構あると思います。PostgreSQLでも当然そういう要望はあってぐぐれば出てくるんですが、いちいちクエリ書くの面倒くさいのでViewとして定義して使っています。折角なので自分が使ってるやつをここにペタペタしときますので、ご参考までにどうぞ。

--DROP VIEW public.view_columnlist;
CREATE OR REPLACE VIEW public.view_columnlist AS
    SELECT      cls.oid          AS object_id
               ,nms.nspname      AS schema_name
               ,cls.relname      AS table_name
               ,des1.description AS table_logical_name
               ,att.attnum       AS column_no
               ,att.attname      AS column_name
               ,des2.description AS column_logical_name
               ,typ.typname      AS column_type
               ,COALESCE(idx.indisprimary, FALSE) AS column_is_primary_key
               ,att.attnotnull   AS column_is_not_null
               ,cls.relkind      AS object_type
    FROM        pg_catalog.pg_class       cls
    LEFT  JOIN  pg_catalog.pg_namespace   nms
            ON  cls.relnamespace = nms.oid
    LEFT  JOIN  pg_catalog.pg_attribute   att
            ON  cls.oid = att.attrelid
           AND  att.attnum > 0
    LEFT  JOIN  pg_catalog.pg_type typ
            ON  att.atttypid = typ.oid
    LEFT  JOIN  pg_catalog.pg_description des1
            ON  cls.oid = des1.objoid
           AND  des1.objsubid = 0
    LEFT  JOIN  pg_catalog.pg_description des2
            ON  cls.oid = des2.objoid
           AND  att.attnum = des2.objsubid
    LEFT  JOIN  (SELECT indrelid,UNNEST(indkey) AS pk_column_no,indisprimary FROM pg_catalog.pg_index WHERE indisprimary) idx
            ON  cls.oid = idx.indrelid
           AND  att.attnum = idx.pk_column_no
    WHERE       cls.relkind IN ('r','v','m')
      AND       nms.nspname = 'public'
    ORDER BY    schema_name
               ,table_name
               ,column_no
    ;

ALTER TABLE public.view_columnlist
    OWNER TO ユーザー名;


COMMENT ON VIEW view_columnlist IS 'VIEW_テーブルカラム一覧取得';
COMMENT ON COLUMN view_columnlist.object_id IS 'OID';
COMMENT ON COLUMN view_columnlist.schema_name IS 'スキーマ名';
COMMENT ON COLUMN view_columnlist.table_name IS 'テーブル名';
COMMENT ON COLUMN view_columnlist.table_logical_name IS 'テーブル論理名';
COMMENT ON COLUMN view_columnlist.column_no IS 'カラム番号';
COMMENT ON COLUMN view_columnlist.column_name IS 'カラム名';
COMMENT ON COLUMN view_columnlist.column_logical_name IS 'カラム論理名';
COMMENT ON COLUMN view_columnlist.column_type IS 'カラム型';
COMMENT ON COLUMN view_columnlist.object_type IS 'オブジェクト型';
COMMENT ON COLUMN view_columnlist.column_is_primary_key IS '主キー制約';
COMMENT ON COLUMN view_columnlist.column_is_not_null IS '非NULL制約';

 ながい!
 けどそんなに複雑なことはしてないので、簡単に解説しておきます。

◆ざっくり解説

 全てPostgreSQLのシステムカタログテーブルです。まあ当然ですよね。詳細は公式ドキュメントを参照していただくとして、何のテーブルで何のために結合しているかだけ羅列しておきます。尚、各システムカタログテーブルは内部的にoid列をもっており、これが各テーブル間を結合するためのキーとなっています。(ただしoid同士を直接結び付けるわけではない)

テーブル名 説明
pg_class テーブルやビューなどの一覧が定義されている。クエリのメインのテーブル。
pg_namespace 各オブジェクトの名前空間を管理する。
取得対象を絞り込むために使用。(システム系のものを排除)
pg_class.relnamespace と同じ値がこのテーブルのoidになっている。
pg_attribute テーブルやビューの列情報を管理する。
列番号や名前を取得するために使用。
このテーブルのattrelidがpg_class.oidと同じ値になっている。
列番号が1以上の行が列情報。
pg_type 型情報が定義されている。
各カラムの型情報を取得するために使用。
pg_attribute.atttypidと同じ値がこのテーブルのoidになっている。
pg_description 各オブジェクトのコメントを管理する。
テーブルやカラムのコメント情報を取得するために使用。
pg_class.oidと同じ値がこのテーブルのobjoidに格納される。
テーブル情報(objsubid = 0)とカラム情報の両方を取得。
pg_index インデックス情報の一部を管理する。
主キー情報を取得するために使用。(サブクエリでindisprimary(bool)を絞り込んで使用)

indrelidが対象となるテーブルのOID(pg_class.oid)、indkeyが列番号(pg_attribute.attnum)と同じ値になる。
※ただしindkeyは配列型なので扱いに注意

 各テーブルの結合部分がTry&Errorで作ってったので面倒くさかったです。とはいえ、ドキュメントと実テーブルの内容さえわかってしまえば、あとは時間の問題だけでした。

 残りについては各カラムにつけた別名を見て頂ければ意味はわかってもらえると思います。また、WHERE句にある「cls.relkind IN (‘r’,’v’,’m’)」についてですが、これはオブジェクトの種類を絞り込んでおり、具体的には「r:テーブル」「v:ビュー」「m:マテリアライズドビュー」となります。詳細は公式ドキュm(略)

◆実際に使ってみる

 まずはテキトーに、テーブルを用意します。こんな具合に。

image

image

image

 そして、先ほど作成したビューを開いてみます。

image

 ちゃんと取得できてますね。なんか表示されてないテーブルがある気がするかもしれませんが、目の錯覚です。

 つたないクエリですが、よければご参考までに。(結構前に作ったやつなので、環境によってはうまく動かないかもしれませんが)

◆補足

 テーブルやカラムのコメント欄を論理名としているのは、普段はフリーツールの「A5:SQL Mk-2」を使用している関係からです。このツールではコメントを論理名として扱ってくれます。
 尚、論理名を指定しつつコメントも設定したい場合は、コメント部分をタブ区切りにすると認識してくれます。(その場合は上のクエリもタブで区切るように手直ししてください。具体的には↓みたいに)

--               ,des2.description AS column_logical_name
,COALESCE(CASE POSITION(CHR(9) IN des2.description) 
		 WHEN 0 THEN des2.description
		 ELSE        SUBSTRING(des2.description FROM 0 FOR POSITION(CHR(9) IN des2.description))
		 END
		,att.attname) 
				 AS column_logical_name
,CASE POSITION(CHR(9) IN des2.description) 
	WHEN 0 THEN NULL
	ELSE        SUBSTRING(des2.description FROM POSITION(CHR(9) IN des2.description))
END              AS column_comment

 んでもってこんなクエリを発行しておきます。

COMMENT ON COLUMN my_favorite_koto_hono.ss_evaluation IS 'SS評価    やっぱりことほのなんだよちゅんなぁ(・8・)';

※わかりづらいですが、間のはスペースではなくタブです

 そうするとこうなります。

image

image

 ばっちりね!

ブログに載せてたコード(の一部)をSyntaxHighlightに対応させました

 

 令和がはじまりましたね。ようこそ新時代。

 3月と4月は、炎上案件にぶち込まれて社畜ってた合間に、推し事でライブやら劇場版やらを見に行きまくってたせいで、すっかり更新をサボってしまいました。特に書けるネタが無かったというのもありますが。(ちなみにサンシャインの劇場版は40回見てきました

 

 で、タイトルの通りですが。
 ブログに載せていたSQLのコードとかが、変な表示になってしまっていた件、遅くなりましたが修正しておきました。一部、というのは「コノ世界ニ非ズ」に改名して以降の分だけ、です。(コード載せてるのなんて最近のくらいしかないはずですが……)

 現在ならばこんな感じで綺麗にシンタックスハイライトされて表示されています。

image

 

 うちのブログはWordpressの無料版の「Wordpress.com」を使っており、こいつではシンタックスハイライトって出来ないのかな?(追加プラグインとかで)と思って、調べてみたら、普通にやり方が書いてあるサイトがあって判明しました。思い込みしないで、ちゃんと調べないとダメですね。

 で、やり方は、なんてことはないです、コード部分を [code]で囲ってやるだけでいいみたいです。
 また、SQLとかCSSとか、言語に応じてハイライトを対応させることも出来るみたいで、例えばSQLならば[code language="sql"]って書いて囲ってやればいいみたいです。楽ちんね!

 と、いうわけで今後コードを載せるときは、ちゃんとこの機能を使って載せていきたいと思います。それでは令和もよろしくお願いします。

PostgreSQL: すべてのfunctionを一括で削除したい

 

 前に書いた「PostgreSQL:複数定義があるFunctionの一覧をクエリで取得する」って記事の続き的なもの。すっかり書くの忘れてましたが

 さて、上にあげた記事のように、うちのPJではめちゃくちゃFunctionが多くて色々と問題が起きておりまして。そのうえ、環境ごとにDBが乱立してしまい、あるDBのFunctionが最新版では無かったりして環境ごとに挙動が異なり、混乱を招いたりするのは日常茶飯事でした。
 もう完全に管理できてへんやんけ!という本音は横に置いておき、ひとまず事態を収めねばなりません。幸い、FunctionそのものはテキストファイルにしてSVN上で保存してあったので、最新版を当て直すだけならば、さほど難しくありません。

 しかし、どうせ当て直しするなら消し忘れの古い定義のFunctionとか、不要になったFunctionとか、一括して整理したいなぁと思いまして。なんか一括で消せないのかなーと思って調べたのですが、特にそういう機能は無いらしく、1個ずつ手動で消すのはあまりにも面倒だったので、↓みたいな方法で消すことにしました。

 

◆FunctionでFunctionを消す

 やり方は単純で、システムテーブルからFunction名とか引数定義とかを引っ張ってきて、動的SQL文を作って削除するってのを繰り返すだけです。らくちんね。
 自分自身を消さないようにしたり、対象を絞るようにするのを忘れないでください。例えば弊社の場合は、関数名の先頭に「fn_」ってつけることが規則になっていたので、絞り込むのは簡単でした。

・システムテーブルからFunction名と引数定義を取得する

SELECT
    nmsp.nspname || '.' || pgp.proname || '(' || pg_catalog.oidvectortypes(pgp.proargtypes) || ')' AS functionName
FROM
    pg_catalog.pg_proc pgp 
    LEFT JOIN pg_catalog.pg_namespace nmsp
    ON nmsp.oid = pgp.pronamespace
WHERE
        pgp.prorettype <> 'pg_catalog.cstring'::pg_catalog.regtype
    AND NOT pgp.proisagg
    AND nmsp.nspname = 'public'
    AND pgp.proname like 'fn_%'
;

 これを実行すると、publicに定義されてる、名前がfn_ではじまるfunction一覧が引数の型定義とセットで手に入ります。「名前(引数1の型, 引数2の型)」みたいな形で。あとはこれを、「DROP FUNCTION 名前(引数1の型, 引数2の型);」という文字列に加工してやって、ループで動的SQLとして実行し続ければOKです。

・動的SQLとしてDROP文を実行する

DECLARE
    rec_funcname_list  record;
    txt_sql            text;
BEGIN
    FOR rec_funcname_list IN
    SELECT
            nmsp.nspname || '.' || pgp.proname || '(' || pg_catalog.oidvectortypes(pgp.proargtypes) || ')' AS functionName
    FROM
            pg_catalog.pg_proc pgp
            LEFT JOIN pg_catalog.pg_namespace nmsp 
                   ON nmsp.oid = pgp.pronamespace
    WHERE   pgp.prorettype <> 'pg_catalog.cstring'::pg_catalog.regtype
      AND   NOT pgp.proisagg
      AND   nmsp.nspname = 'public' 
      AND   pgp.proname like 'fn_%'
    LOOP
        txt_sql = 'DROP FUNCTION ' || rec_funcname_list.functionName;
        execute txt_sql;
    END LOOP;
END;

 エラー処理とかは省略してます。実際に使ってるやつからは若干改変してます。(ほんとちょとだけ)
 先に書いたSQLの結果件数だけループさせて、「execute txt_sql;」で実行し続けるだけの簡単なfunctionです。

 使う場合には自己責任でどうぞ。(事前に、SELECT部分だけ実行してちゃんと目的のものだけになってるか、は目を通しておいたほうがいいと思います)

VisualStudioCode で 「Building workspace」とか「Compile」がいつまで経っても終わらない現象。あるいは異常に時間がかかる。

 

 結論だけ見たいって人は、「◆見つけた回避策」までスキップ。

 

◆前置き

 推し事 お仕事では、JavaでWEBアプリケーションの開発を行っている部隊に所属している私です。これまでは、関連会社間で標準として定められた、プラグインマシマシ過ぎのEclipseを使っていたのですが、これが資産管理系のツールやら社内ネットワークやらと大変に相性が悪く、頻繁に固まる(落ちる)ような環境でして……。そんな環境での開発を強いられていました。
 変数コピーしようとして選択状態にしたり、コード打ち込んだり、ファイル切り替えたり……そんな些細なことで、固まりやがるのですよ。ストレスで寿命がマッハです。

 そんなある日、いつも通り応答なしになったEclipseさんを放置しながらネットを見ていたところ、VisualStudioCodeでJava開発環境を整える、という記事がたまたま目に入りました。完全に思いつきて、ものは試しにと使い始めてみたところ、これがとても快適でめっちゃ気に入ってしまい、上司らとの色々な交渉の末にこっちをメインの開発環境に切り替えられることになりました。

 これでEclipseから解放されるぞ、と喜んでいたのですがしかし、そこで遭遇したのが、この表題の現象。

image

 この写真にある「Building workspace – 0%」が点滅を繰り返し、ずっと終わらんのです。
(警告数とか、他の情報は気にしないでください、撮影のために色々したやつなので。本件とは関係ありません。キャプチャではなく写真なあたりも、察して!)

 これが終わらないせいで、いつまで経ってもデバッグ実行が出来ず、また定義情報の参照なども出来ず、Javadocは表示されずF12を押しても定義に飛べず、といった感じで、このままでは開発に支障が出てしまう状態でした。
 ネットで調べても同様の現象に引っかかっている人はあまりおらず、Githubのコメント欄に海外の人で似たような人が何人かいた程度でした。(そしてその人達も未解決っぽい?)

 厳密には、待ってればちゃんとビルドは終わるんです。2時間くらい待てばですが
 一度終わってしまえば、そのあとはしばらく平和な状態になり、ソース書き換えたりしてもちゃんとすぐ反映されるし、その際の自動ビルドもすぐ終わってるんです。しかし何かがトリガーになるようで、いきなりまた現象が再発する、という状態でした……。

 この現象に、かれこれ2か月ほど悩まされてきていました。それでもVisualStudioCodeを使い続けて、色々と試行錯誤してました。(こんな状態でも、弊社のEclipse使い続けるよりマシだったので)
 そして先日ついに! この現象を回避する方法を特定したので、情報共有も兼ねて、ここに記事として残しておきたいと思います。同じ問題で悩まされてる人に少しでも参考になれば……と思いますが……。(ただ、うちの場合は環境が変だったことに依存してそうなため、あまり参考にはならないかもしれません)

 というわけで、次からが本題。

 

◆環境

 まず、使用OSやVScodeのバージョン、主な拡張機能等を整理します。

Windows 7 SP1(現象発生時点での最新のWinUpd適用済)
Visual Studio Code 1.30.1(user setup)
 ・Java Extension Pack
 ・Spring Boot Extension Pack
 ・Lombok Annotations Support for VSCode
Spring Boot 1.5.12
PostgreSQL 10.5
Gradle使用(version 2.6)
バージョン管理:Subversion 1.9..以下省略 (クライアント側はTortoiseSVNを使用)

 主だったところはこんな感じ。VScodeでJava(+ Spring boot)開発をやるって場合のごくありふれた構成です。強いて上げるとするなら、Gradleが大分古い(2.6)ことやバージョン管理がGitではなくSubversionってところがレトロな感じですね。これでも少し前までバージョン管理使ってなかった状況からは大分改善されてるんだぜ……?

 バージョンはともかく、Subversionのディレクトリ構成が少し変わってるので、下図に提示します。

・branches
  –各ブランチ(省略)
・tags
  –各tags(省略)
・trunk
  –ドキュメント類(省略)
・src
  –各プロジェクトのソース類
  |-project_a
  |-project_b

 こんな感じの構成です。
 trunkではなく、別途「src」というソース管理専用のディレクトリを作って、その中で開発を行っていました。ちなみにこの構成を決めたのは前任者(退職済)なので、どうしてこういう構造にしたのか、その理由は誰も知りません。コワイ!

 ここでは、現象の起きている対象のプロジェクトを「project_a」という名前に仮定して話を進めます。

 

◆調査経緯

 さて。
 わざわざ「Subversion」の構造を挙げたので勘のいい方はお気づきかもしれませんが、今回の事象の原因にはこれがか関わってきます。めっちゃ重要です。しかしその、構成がちょっとアレなのと再現確認が不十分なので、あまり自信はないのですが……。
 それはそれとして、私はこの件に関しては、以下のような経緯で調査してました。

 まず、この環境は一応自分が管理者となっていることもあって、TortoiseSVNを使って全ディレクトリをローカルにチェックアウトして使っておりました。VScodeでは、このチェックアウトしたディレクトリの中にある src/project_a を開いて開発を行おうとしており、その際にこの現象が発生していました。
 拡張機能やVScodeのログ確認、ワークスペースフォルダやキャッシュフォルダのクリア、VScodeの再インストール、System Setup版への変更や、前回記事のような改造CSSをやめるなど、色々やりましたが全く解決せず。その後も色々調べていたところ、この現象、部内で私だけでなく複数人で発生しており、しかしその一方で現象が発生しない人もいることがわかりました。何人かに協力を仰いで調査したところ、以下のことが判明しました。

・現象が起きない人は、今まで一度も起きていない
・現象が起きる人は、ほぼ確実に発生する
・OSやVScodeのバージョンは関係なさそう?(混在してたので)
・上記拡張機能以外は、各自自由な状態
現象が起きる人のPCでも、branchesに置いたソースならば現象が発生しない
もう一つの「project_b」では現象が発生しない

 下2つがかなり気になりますね。ここら辺を重点的に見てみることにしました。

 まずは「project_b」ですが、これはproject_aと比べると圧倒的に小さいプロジェクトです。ソースのファイル数も10個程度しかないもので、こいつは基本的に「project_a」の補助ツール的なものでした。こちらをVScodeで開いても、特に現象は発生しておりません。一方で、「project_a」はソースファイル、JSやHTMLなどのリソースも含めると数千ファイルあるような規模です。
 次にbranchesのほうですが、ここには project_a の専用カスタマイズを行う場合のソースが、srcからブランチを切って格納されています。なので基本的に規模としては「src」の中にあるものと大差ありません。ですが、こちらのソースをいくつかVScodeで開いてみたのですが、なんと全く現象が起きないではありませんか!

 個の段階で一先ずメンバーには、srcからbranchesのほうに新しくブランチを切って、当面の間、メインの開発環境をそっちに移動してもらい、私だけがsrcに残って調査を続けることになりました。そしてそこからさらに数日……ついに現象の回避策を見つけるに至ったのです!

 

◆見つけた回避策

 Subversionでチェックアウト済みの「project_a」を、別のディレクトリに直接チェックアウトしなおして、そこを開く。

 

 以上。

 

 終わり!

 

 閉廷!!!!!

 

 いや、本当にこれだけだったんです。

 例えば、「C:\svn」ってディレクトリに全部チェックアウトしていたとすると、これまでは「C:\svn\src\project_a」を開いていたのですが、これをやめて「C:\svn_src_pj_a」というディレクトリに /src/project_a だけをチェックアウトして、これを開くようにした。こう変えただけで、まったく現象が発生しなくなりました。うっそだろお前、と叫んでしまったのも無理ない話です。

 私だけの環境かもしれない、と思ったのですが、これを他の人にも試してみてもらったところ、全員が解決しました。お前マジかよお前ェー!

 

◆推察

 ここからは推察というかただの妄想ですが、何故、これだけで現象が回避できたのでしょうか。
 VScodeはバージョン管理との連携機能を備えていますが、これはGitにしか対応しておらず、Subversionは対応しておりません。しかし、どこかで見かけたのですが、Subversionのチェックアウトしたときに作成される「.svc」のディレクトリがある場合にはそれを無視するよう設定する、的な記述を見た覚えがあるのです。もしそれが自分の記憶違いでないなら、VScodeはSubversionに非対応だとしても、Subversionそのものについては何かしら認識しているのかもしれません。

 そうなると、Subversionでは一般的ではない(かもしれない)ディレクトリ構造でのソースフォルダで、ソースを開いていたことが、裏側で何か予期せぬ動作を引き起こしていたのかもしれません。branchesディレクトリのほうなら何も問題が無かったというのも、そこらへんが理由なのかな?と。
 ちなみにproject_bについては単に、現象が起きているものの規模が小さすぎてbuild時間が伸びていることに気付けてないだけなのでは?という予想しています。

 ちなみに、別フォルダにあらためてリポジトリ全部まるごとチェックアウトしなおしてproject_aを開いてみましたが、現象が再現しました。やっぱり構造の問題なのでしょうか……?

 

 推察部分に関しては完全に未検証ですし、これといった根拠もあるわけではないので、素っ頓狂なことを言っている可能性もあります。しかしいずれにせよ、もし同現象で悩まれている方は、一度別ディレクトリにソースフォルダをチェックアウトしなおす、という手段を、是非一度お試ししてみてもらいたいものです。

Visual Studio Code のデバッグコンソールとかに背景画像を設定したい

 

 メリークリスマスを通り越して、気が付けば大晦日も大晦日。みなさん如何お過ごしでしょうか。僕はAqoursの紅白出場が見れたので満足しているところです。

 

 で、ふと、そうおいえば12月はまだブログ更新してなかったことを思い出して、今あわてて書いているところです。別にノルマとか無いんですけども。というわけでタイトルの通りです。

 本題。エディタとかに背景画像を設定するのは、ぐぐればすぐ出てくるので簡単に出来てるんですよ。主に幻想ツバメさんとこの記事を参考にさせてもらいまして。要はCSSいじってあれこれ弄っちゃうってわけですね。これによって、こんな感じにするところまではあっさり出来ました。

image

 

 

 そこまでは良かったんですが、エディタやターミナルは画像設定できてもデバッグコンソールとかのタブが出来なかったんですよね。(ターミナルと共通だと思ってた)

 

image

 

 

 これがググってもどう書けばいいのか出てこなかったので、自分で適当に調べて、設定してみました。のでそれ晒しときます。ただ、ぶっちゃけCSSとか全然詳しくないので、なんか変な書き方してたらゴメンナサイね、適宜修正して使ってください。(もちろん自己責任でお願いします)

 

 ヘルプの開発者ツールから適当に要素を調べた感じ、デバッグコンソールの要素名はpanelみたいなので、「 workbench.main.css 」に以下を書き加えてみました。

.monaco-workbench .part.panel {
    background: url("///C:/MyData/vscode_custom/panel.jpg") no-repeat;
    background-position: right top; 
    background-size: contain;
}

 

 したらばこんな感じで、デバッグコンソールにも画像を設定できました。

image

 

 細かい調整とかは必要ですが、ひとまず画像設定するだけならこれで……。誰かの役に立てば幸いです。

 

 

 それではみなさん、よいお年を。

PostgreSQL Conference Japan 2018 に参加してきました

 

 11/22に東京で行われた「PostgreSQL Conference Japan 2018」に参加してきました。

 本イベントは日本PostgreSQLユーザー会主催のイベントで、PostgreSQLに関する色々なお話が聞ける楽しいイベントでした。有料イベントではありますが一般参加なら5,000円(早割なら半額)と比較的安価なので、気軽に参加できました。とはいっても、私はお仕事として参加したので会社持ちです。(しかし懇親会費用は出なかった)

 当日はTwitterでハッシュタグ付きでツイートしまくってたので、最近私をフォローした人はビックリしたかもしれません。普段はずっと「ラブライブがー!」「Aqoursがー!」とかばかりツイートしてますが、実は私、本当は技術者側の人間なんですよ!(デデン

 ということで、ざっくり振り返りです。自分のメモとかツイートとかベースに振り返ってます。
 AMは基調講演が2つ、PMは3つのトラックに分かれて一般公演、という感じです。受付でノベリティとしてロゴ入りの水とシールなどをもらいました。わーい。

image image

◆基調講演

 基調講演1つ目は、NTT OSSセンタの坂田氏による、企業ユーザーから見たPostgreSQLの歴史と展望。Ver8あたりから使って・コミュニティに貢献されてきたとのことで、自分が知らない時代の話が聞けて面白かったです。
 私がさわりはじめたのがVer9.4からなんですが、この話に出てきたVer8のころは色々と課題も多かったようで……チェックポイント時に大幅に性能が低下するとか、VACUUM時の課題とか……。そういった課題を確実に対応していって、今ではビジネスユースにも十分に応えられるものになっていったんですね。
 また、レプリケーション機能に関して、当時コミュニティとしては「外部機能として実装」というスタンスでいたものの、8.1のころにNTT内部で開発を勧めて8.3でOSS版を公開し、それの必要性を各所で語って回った結果本体機能として段階的に取り込まれていったそうです。中々に胸熱な話でした。
 現状もPostgreSQLはまだ課題を抱えていたり機能として中途半端なものもあるけれど、上記のように段階的に進んでいくとのことなので、今後の更なる改善に期待がもてそうです。

 2つ目の基調講演は、Microsoftの藤田氏。
 なんとMicrosoftはこのイベントのプラチナサポンサーとのこと。随所で、MSはOSSに力いれてますよって話とセットで古き悪しきMS帝国みたいな自虐的な話が入り、正直自分はその手のネタはもう食傷気味なんですが、参加者にはそれなりにウケていました。MSに対してはまだそんな感じのイメージの人が多いんだなぁ、とぼんやり思ったり。
 前半ではAzureの話、後半からはAzure上の「Azure Database for PostgreSQL」の紹介。Azureに限らずクラウドのフルマネージドなDBサービス使うと楽ですよー、といった感じ。これは自分も全面的に同意です。
 AzurenoPostgreSQLは、MS独自のカスタマイズはしておらず、コミュニティ版をそのまま使っているそうです。何か手を入れたくなったときはコミュニティにパッチを投げているとのこと。現状は9.5、9.6、10をサポート。11はもう少し待ってください、とのことでそう遠くないうちにサポートされそうですね。
 ひとつ驚いたのは、「Azure Database for PostgreSQL」はダウンタイム無しでスケーリング可能とのことです。AmazonのRDSは1分程度ダウンすると聞いていたので、Azureもそうだと思ってたんですけど。ちなみにこれはService Fabricのおかげとかなんとか。(詳細はよくわかってないです)

 ちなみにAzure上のPostgreSQLは、実体としてはWindowsコンテナとして動作しているとのこと。前半の内容ではAzure上で動いているOSはLinuxが50%以上になった的な話もしてたので、これにはビックリしました。てっきりLinuxかと……。Windowsコンテナで動いてるってことは、PostgreSQLもWindows版ってことですから、ちょっとだけ注意が必要になりそうですね。

 

◆一般公演

 PMからの一般公演は3つのトラックにわかれており、そのうちの1つはチュートリアルコースとなっていました。私はこれには参加してないのですが、10月にリリースされたVer11の解体新書とか、チューニングに関する話とか、結構興味のある内容もありました。身体が3つあれば……!
 というわけで参加したやつだけ、簡単に振り返りをば。

 

・A1.MySQLからPostgreSQLへの移行とDBリファクタリング

 株式会社オミカレの高橋氏による、実例に基づいた話。いわゆる「秘伝のソース」状態と化していたため、例えばDBテーブルの性別欄に入っている値が「0、1、2、男性女性」という状態になっているといった、「あーあるある」ってみんなの目が死ぬような状況にあったものを、PostgreSQLへ移行したというお話。
 僕個人としては、担当してるシステムのDBは最初からPostgreSQLなので移行という観点ではあまり関係ないのですが、移行時にMySQLと比較した場合のメリットとか(トリガー関連が決め手になったようです)が聞けて、中々に新鮮な話でした。

 

・A2.EDB Postgres はここまできた!パフォーマンス問題解決のヒント

 株式会社アシストの佐瀬氏による、PostgreSQL11での性能改善に関する話が中心でした。セッションタイトル的にEDB版の話がメインのように感じられますが、実際にはそんなにEDB要素は無かったです。
 パーティショニングに関する性能改善がかなり大きいらしく、パーティション化していない9.6のDBとパーティション化したPostgreSQL11のDBとでは、最大350倍もの性能差があったとのこと。350……これは大きいですね。どうしてそこまでの性能差が出たのか、内部的な動きも一部含めて解説。
 また、アシスト社への問い合わせが多い内容や実例などから、パフォーマンスチューニングで実際に起こっていた問題と対処方法などをいくつか紹介してくれました。Oracleから移行してきたパターンだとOracleのヒントをそのまま使っている場合に誤った実行計画になるとか、大量にテーブルを結合している場合の「join_collapse_limit 」「from_collapse_limit」パラメータに関する話など。このあたりは結構参考になりそうで、助かります。

 

・B3.Citusを使ってPostgreSQLをスケールアウトしてみよう

 ここだけBトラックに移動して、スケールアウトの話を聞いてきました。
 日本HPの篠田氏によるCitus(サイタス。シータスではないらしいです)の概要とその導入方法。CitusはExtensionsとして提供されているため、導入は簡単に行えるというのが最大のメリットかと。コーディネーターと複数のワーカーによって構成されて、実データはワーカー側に分散して保存する、というもの。
 しかし意外と制約が多く、一例として「分散キーの更新不可能」「SELECT FOR UPDATE不可能(レプリカ作成してる場合のみ)」「WITH RECURSIVE句使用不能」「PARTITION BY句の使用に制限あり」など。WITH RECURSIVEが使えないのは結構痛いですね……。しっかり吟味する必要はありますが、条件があうなら簡単に分散化できるので検討の余地はありかと。

 

・A4.運用が大分変わるよ。オンプレ PostgreSQL から AWS のマネージド PostgreSQL の担当になっての知見

 オイシックス・ラ・大地株式会社の林氏による、ECサイト上の分析基盤としてAWS上のPostgreSQLを使うようになった話。それ以前はMySQLを使用されていたそうです。
 この直前に行われていたA3トラックがAWSの紹介だったことと、そのまま継続してA4を受けている人が多かったからか、クラウドを採用するメリットを説明する際にAWSへの熱いダイマが入っていました(サーバーを即用意できるとか、フルマネージドなので管理が楽とか)。 AWSにしろAzureにしろ、特に理由がない限りはもうクラウド上のマネージドサービス使ったほうが圧倒的に楽なんですよねぇ……と改めて実感。
 また、AWSのRDS PostgreSQLはスケーリングに応じて一定の閾値でチューニングが自動的に行われるため、ある程度はチューニングを意識せずに使える、というメリットもあるとのこと。これは初耳でした。しかしスケーリング時には一時停止があるため注意、とのこと。無停止でスケーリング可能なAzureと、チューニング不要のAWSと……どっちもメリットデメリットがある感じですね。

 

◆LT

 最後にLTがいくつかありました。
 「デッドロックが趣味」という人とか、「PostgreSQLで山手線ゲーム」をした人など、中々に濃い?内容でした。今までMS系の勉強会とかカンファレンスへの参加が多めな私でしたが、ああ、どこ行っても頭おかしい(誉め言葉)人はいるんだなぁ、と感じました。(小並感)

 その後は懇親会でしたが、私は不参加なのでここで終了と相成りました。

 

 個人的には、結構収穫の多いカンファレンスだったなと思います。
 最近の自分は、なんだかんだでPostgreSQLにどっぷりになりつつあるので、今後も勉強会とかカンファレンスがあれば積極的に参加していきたいですね。

 あ、あとA4で紹介されてた「[改訂新版]内部構造から学ぶPostgreSQL 設計・運用計画の鉄則 (Amazonへのリンク)」は、早速買ってきました。まずはざっくり読んでおこうかなと。

PostgreSQL:お仕事の関係でAzure Database for PostgreSQLを立てたので、そのメモ

 仕事のほうではずっと社内のWindows版PostgreSQLしか使ってこなかった自分ですが、ここ最近になって、DBをクラウドのフルマネージド環境に移行させる流れがあがってきまして。その流れでAzure上に1つ作成したのですが、折角なので、メモを残しておきます。そんなに大して難しくないですけど。

 尚、Azureのアカウント作ったりとかそういうところはバッサリとカットです。

◆AzureにPostgreSQLのDBを作成する

 まず、ポータル画面にアクセスしたら、左のメニューの「すべてのサービス」を開きます。
 Azureにはいっぱいサービスがありますが、「データベース」カテゴリの中に「AzureDatabase for PostgreSQL」があります。名前の右側にある「★」のマークをクリックすれば、左メニューのお気に入り欄に表示されるようになるので、押しておきましょう。

image

 

 メニューをクリックしたら、PostgreSQLの作成したインスタンス一覧が表示されます。最初は何もないですけど、スクリーンショット取ったのが作成後なので既に出来ちゃってますが、気にしないでください。
 新しく作成するためには、左上にある「追加」をクリックします。

image

 

 新規作成にあたって入力する内容はそんなに多くないです。

image

 サーバー名:任意のもの
 サブスクリプション:契約してるやつを
 リソースグループ:とりあえずテキトーなリソースグループを作成しました
 サーバー管理者ログイン名:任意のもの(ここでは定番の「postgres」に)
 パスワード:任意のもの(パスワード文字列にはルールあり)
 場所:任意の場所
 バージョン:11月2日現在で選べたのは 9.5、9.6、10 の3つ

 そして最後の「価格レベル」の欄です。
 サーバーに割り当てるスペックに応じて金額が変わります。高スペックであれば当然、高価格になりますし、低スペックならばそれなりに安くなります。

image

 ほぼほぼ最低状態にして、毎月のコスト見積もりがおおよそ4400円。これ、実際には使用した分に応じての課金っぽいので、あくまでも見積もり価格だということに気を付けましょう。

 構成を選んだら画面下のOKボタンを押すと、一つ前の画面に戻ります。内容に間違いがなければ、これまた画面下の「作成」ボタンを押します。それからしばらく(1分程度?)待つと、通知欄に作成完了の旨が表示されます。

 

◆接続してみる

 作成が完了したら、Azure Database for PostgreSQLの一覧に表示が出てきていますので、サーバー名をクリックします。すると、そのサーバーの「概要」ページが表示され、詳細が確認できます。

image

 設定の「接続のセキュリティ」をクリックします。

image

 

 テスト用なので、「SSL接続」を無効に。ファイアウォール規則のところに、自PCのIPアドレスを打ち込んで接続許可の状態にします。(入力後、画面上の「保存」を押すのを忘れずに)

 

 ここまで設定しておけば、とりあえず、ローカルクライアントから接続可能になっているはずです。pgAdminなりA5SQLなりのクライアントを起動して、接続テストをしてみます。今回、この記事書いてる段階で自PCのpgAdminがご機嫌ナナメだったので、A5SQLで確認してみます。

 

サーバー名:先ほどの概要ページに表示されているので、それを
データベース名:postgres
ユーザー名:作成時に指定したもの(後ろに「@サーバー名」をつける必要があるので注意)
パスワード:作成時に指定したもの
ポート番号:既定の5432

image

 内容に誤りが無ければ、テスト接続できるはず。

 

 接続できたあとは、普通にPostgreSQLです。

 

◆少しだけ見てみる

 さてさて、これでPostgreSQLのインスタンスが立ち上がったわけですが、現在どんな状態なんでしょうか。少しのぞいてみます。まずはさくっと、バージョン確認。

image

 作成時に指定したバージョンは「10」でした。実際にインストールされたものは「10.5」です。10.5がリリースされたのは今年の8月で、現時点では10での最新版ですね。割と早めに新しいバージョンが導入されているようで、好感触です。流石に先月リリースされたばかりのPostgreSQL 11 は、まだみたいですが。

 

 次に、DB一覧を見てみます。

image

 初期状態では、デフォルトのpostgres以外にも2つ、DBがあることがわかります。名前的に恐らくAzure側の管理・メンテ用でしょう。これらにはウカツに触れないようにしておきましょう。

 では、試しにCREATE DATABASEしておきましょう。

CREATE DATABASE test_db_01 WITH
       OWNER = postgres
       TEMPLATE = DEFAULT
       ENCODING = 'UTF8'
       TABLESPACE = DEFAULT
       CONNECTION LIMIT = -1
;

 

 で、もう一度、DB一覧を取得してみます。

 

image

 

 ちゃんと出来てますね、OK。

 

 これから先、しばらくAzure Database for PostgreSQLを少しいじっていってみたいと思います。なのでまた何か記事にするかも。