たまの・港フェスティバル 2017

この記事は【2017年5月20日】と作成から2年以上経っているため、記事の内容が古い可能性があります。最新の情報を合わせてご確認されることを推奨いたします。

今日は天気も良いので,たまの・港フェスティバルに行ってきた。玉野市最大規模のイベントらしく,今回で21回とのことで歴史も長いようである。

会場は宇野港,自家用車で行く方は臨時駐車場が用意されており無料で利用できる。駐車場が会場から遠い場合は,シャトルバスも出ている。

フェスティバルは土・日で行われ,今日は初日である。人も多く賑わっているようだった。とにかく日差しが強いので,暑さ対策はきっちりしておいた方が良いだろう。特に水分補給はこまめに行なよう気をつけたいところだ。

見所の1つは,「日本丸」という帆船である。帆を張った姿は圧巻だ。日常を離れ,大海原を航海したくなるような凛々しい姿をしている。風を上手くつかみ,たわむ帆と堂々たる姿で海を渡る光景も見てみたいところだ。

他にも屋台を中心に様々な催しがある。

これは,廃材で作った魚のアートだろう。物に溢れる現代故に考えさせられる作品だ。ふとジブリアニメの『ハウルの動く城』が頭に浮かんだ。

よく見ると滑り台になっている。魚の口が入り口だ。

ボートの波止場にはクラゲの姿も見える。クラゲもフェスティバルを楽しんでいるようだ。

こちらは,ラジコンの船だろうか。進みは遅いが見ていて飽きないオブジェクトだ。後ろを走る中型船ラジコンと並ぶと,江戸時代からタイムスリップして現代にやってきた川舟の漕ぎ手といった感じだ。『仁』の逆バージョンだ。

かき氷を自転車で作る『チャリ氷』。自転車の動力がチェーンで連結されたかき氷機に伝わり,かき氷が出来上がる。自分で一生懸命チャリンコ漕いで作ったかき氷はひときわ美味しいだろう。面白いアイデアだと思った。

石鹸のデコページュを体験できるブースもある。専門学校の方のブースだ。とても可愛らしい石鹸を作ることができた。材料も簡単に用意できるらしいので,手作りプレゼントで喜ばれるかも。

海風も心地よいので,ぜひ休息のひと時を

PR

デコパージュはじめてセットBOOK【専用液2本 平筆1本付き】 (バラエティ)

新品価格
¥1,598から
(2017/5/20 22:16時点)

pukiwikiの編集画面で入力のショートカットボタンをつける

この記事は【2017年5月14日】と作成から2年以上経っているため、記事の内容が古い可能性があります。最新の情報を合わせてご確認されることを推奨いたします。

pukiwikiは大変便利な情報整理ツールで昔から利用させていただいています。データベースソフトウェア不要で設置が簡単であるもの魅力の1つです。

wikiの編集画面でwiki記法の入力を簡単に行ないたいということもあり,ちょっとしたヘルパーを仕込んでみました。あまり深く考えて作っていないので,整理されていない感はありますが,私の要望は十分に満たしているので良しとしたいと思います。

こんな感じで動きます。もし参考になりましたら幸いです。

使用方法

form_helper.phpをskinの下とかに置きます。続いてlib/html.phpを以下のように編集します。

あとは,jsコードをskinで読み込みます。jQueryも必要です。

編集画面はこんな感じになります。form_helperの定義配列を編集すれば好きなショートカットが作れます。

リンクを掲載しますが,利用は個人の責任でお願いします。

pukiwiki_form_helper.zip – 2017/05/14

SQLクエリジェネレータsqlsmithを使ってみる

この記事は【2017年4月7日】と作成から2年以上経っているため、記事の内容が古い可能性があります。最新の情報を合わせてご確認されることを推奨いたします。

sqlsmithというSQLを自動生成してくれるソフトウェアがある。現在は,PostgreSQL9.1 or laterとSQLite3がサポートされているらしい。

https://github.com/anse1/sqlsmith

Build on OSX

早速ビルドして試してみる。環境はOSX。

とREADME.mdのとおりにすると以下のようなエラーになってしまう。。どうもヘッダーファイルが見つからないらしい。

brew install postgresqlでインストールした先の情報は,以下のようになっており,/usr/local/Cellar/postgresql/9.6.2/includeにあるらしい。

postgres.hhの以下を変更することで対応した。

実行

--max-queriesを指定すると最大試行回数を指定できる。なおトランザクションは全てロールバックされる。

--dry-runするとSQLが標準出力に出力される。

コマンドラインオプション

オプション 説明
--target=constr 接続先 --target="host=/tmp port=5432 dbname=regression"
--sqlite=URI SQLiteへの接続先 --sqlite="foo.db"
--log-to=constr ログ出力先のデータベース。スキーマ定義は,log.sqlにある。 --log-to="host=/tmp port=5432 dbname=regression_log"
--seed シード --seed=$(date +%s)
--dump-all-graphs 生成された抽象構文木ASTを出力する --dump-all-graphs
--dry-run クエリを実行せず出力する --dry-run
--exclude-catalog リレーションにカタログテーブルを使わない --exclude-catalog
--max-queries この値に指定されたクエリを実行すると処理を終了する --max-queries=10

実行情報

--verboseオプションをつけると,クエリ実行の情報が標準エラー出力に表示される。

文字 意味
. 成功
t タイムアウト
s 構文エラー
c コネクションエラー
e その他のエラー

内部調査

全体の処理の流れは以下のようになっている。カスタマイズしたい時の参考になるかもしれない。

メイン処理

メイン部分の処理の流れは以下のとおり。コマンド実行すると,sqliteかpostgresqlかに応じてスキーマ及びドライバを初期化し,無限ループでひたすらクエリを生成して実行する。--max-queriesオプションが指定されていれば,指定回数のクエリが投入されてからプログラムは終了する。

ロガー

クエリ生成及び実行,エラーのタイミングで呼ばれる。処理内容は,generatedexecutederrorメソッドで実装する。loggerクラスの仮想関数をオーバーライドすれば独自のロガーを作成できる。

impedance_feedback

クエリ実行の統計を記録する

pqxx_logger

クエリ実行の統計情報をpostgresqlデータベースに記録する。

cerr_logger

標準エラー出力に情報を出力する。--verboseオプションが指定された場合に有効。

ast_logger

--dump-all-graphsオプションが指定された場合に有効。ASTをxml形式でファイルに出力する。sqlsmith-<実行回数>.xmlというファイル名で作業ディレクトリに出力される。xmlは,graphml形式に対応している。

クエリ生成

ASTノードはクラスで宣言されており,各ノードクラスのoutメソッドを呼ぶことでクエリが組み立てられる。ASTノードのベースクラスはprodクラスである。

またASTは,Visitorパターンで実装されている。ASTツリーをwalkしたい場合はVisitorを実装して,ルートノードのacceptにVisitorオブジェクトを渡して呼び出してやれば良い。

各ノードのクエリ生成をカスタマイズするには,ASTノードクラスのoutメソッドをオーバーライドすれば可能である。以下例である。

ASTノード生成の関数も少し触る必要がある。

参考リンク

  • https://korte.credativ.com/~ase/sqlsmith-talk.pdf
  • https://github.com/anse1/sqlsmith

PostgreSQL9.5ストリーミングレプリケーションメモ

この記事は【2017年2月5日】と作成から2年以上経っているため、記事の内容が古い可能性があります。最新の情報を合わせてご確認されることを推奨いたします。

最近PostgreSQLに触れる機会が増え学習中です。

PostgreSQLでは、バージョン9から非同期レプリケーション機能が組み込まれ、以降同期レプリケーション、カスケードレプリケーションと進化し、バージョン9.6でマルチ同期レプリケーション[1]9.5までは、プライマリサーバに対して同期スタンバイは1サーバのみであったが、9.6からは複数ノードで同期レプリケーションが可能になったが可能になったそうです。

最新バージョン9.6のマルチ同期レプリケーション機能も試してみたいところですが、まずは9.5までのストリーミングレプリケーションに関して備忘録を兼ねたメモです。

PostgreSQL9.5で可能なレプリケーション構成

同期スタンバイサーバは1つのみ

バージョン9.5では、同期スタンバイを組めるのは1サーバのみ[2]http://www.postgresql.jp/document/9.5/html/runtime-config-replication.html#guc-synchronous-standby-namesとなっています。synchronous_standby_namesという設定値に同期スタンバイサーバを指定することで、同期モードで動作するスタンバイサーバを指定することができますが、カンマ区切りで複数のノードを指定した場合は、最初に指定されたサーバが同期スタンバイとなり、残りのサーバは同期候補になります。

上記はローカルマシン上で異なるportを使って複数のpostgresを起動することを想定した場合の最小限の設定例です。

上記設定の場合、standby1が同期スタンバイになります。pg_stat_replicationビューを参照することでレプリケーションの状態を知ることができます。同期スタンバイでないサーバのsync_stateは、potential(同期候補)となります。

同期スタンバイがダウンした場合

potentialのスタンバイサーバがいる状態で同期スタンバイサーバがダウンした場合、potentialサーバが同期スタンバイに昇格します。試しに上記構成で、standby1をstop -m immediateしてみます。

こうすると、pg_stat_replicationは以下のようになります。standby2のsync_stateがsyncになっているのがわかります。

続いてダウンしたスタンバイサーバ(standby1)を、設定はそのままでクラスタに再度参加させると、追加したスタンバイの方が優先度が高いため同期スタンバイとなり、追加前に同期スタンバイであったサーバ(standby2)は、potentialになります。

カスケード接続

PostgreSQLのレプリケーションでは、スタンバイにスタンバイを繋げるカスケード接続も可能です。設定は非常にシンプルで、recovery.confのprimary_conninfoに接続先のスタンバイサーバを指定するだけです。(pg_hba.confでの接続許可やmax_wal_sendersなどの設定は必要です)

カスケード接続されるスタンバイサーバは非同期レプリケーションとなります(standby2のsynchronous_standby_namesにstandby3を指定しても同期にはならない)。

プライマリへの昇格

プライマリサーバに何らかの異常が発生し、スタンバイサーバを新しくプライマリサーバとして稼働させたい場合は、スタンバイサーバ上でpg_ctl promoteコマンドを実行します(アプリケーション側は何らかの切り替え処理等が必要)。これにより、スタンバイサーバはプライマリサーバに昇格し、新プライマリサーバで更新処理を実行することができるようになります。PostgreSQL自体に自動フェイルオーバ機能はないので,スタンバイからプライマリへの切り替えを自動で行ないたい場合は別のツールを組み合わせて使う必要があります。

また,pg_ctl promoteを実行するとタイムラインIDが新しくなります。PostgreSQLでは,「タイムライン」[3]https://www.postgresql.jp/document/9.5/html/continuous-archiving.htmlという概念でリカバリ前後におけるデータベースシステムを区別するようになっています。上記のプライマリ昇格では,pg_ctl promoteを実行する前にタイムラインIDが1であった場合,promote後にはインクリメントされて2のようタイムラインIDが変わります。

以下,pg_ctl promoteを実行したサーバのpg_xlogディレクトリです。WALのファイル名の先頭部分「00000001」がタイムラインIDを示していますが,promote前後で「00000001」から「00000002」に変わっていることが確認できます。

同期スタンバイの切り離し

プライマリサーバと同期スタンバイでレプリケーションを構成していて,同期スタンバイサーバが何らかの異常で停止した場合,プライマリサーバで更新処理ができなくなってしまいます。この場合,プライマリサーバの設定ファイルを書き換え,異常のあった同期スタンバイサーバを切り離す必要があります。

上記の同期設定をコメントアウトし,pg_ctl reloadします。これで,引き続きプライマリサーバで更新処理を継続できるようになります。

 

レプリケーションの動きを確認するのに、以下の拙作なツールが役立つかもしれません

https://github.com/moritoru81/pgenv2

参考リンク

PostgreSQL全機能バイブル

新品価格
¥3,780から
(2017/2/5 20:14時点)

脚注

脚注
1 9.5までは、プライマリサーバに対して同期スタンバイは1サーバのみであったが、9.6からは複数ノードで同期レプリケーションが可能になった
2 http://www.postgresql.jp/document/9.5/html/runtime-config-replication.html#guc-synchronous-standby-names
3 https://www.postgresql.jp/document/9.5/html/continuous-archiving.html

【企業経営理論】CSRとコーポレートガバナンス メモ

この記事は【2017年1月7日】と作成から2年以上経っているため、記事の内容が古い可能性があります。最新の情報を合わせてご確認されることを推奨いたします。

明日から3連休。少し気が抜けてしまった。。

企業の社会的責任とコーポレートガバナンス。

これは,日頃のニュースでもよく耳にするし,会社に勤めている人であれば社内でも頻繁に耳にするであろうワード。

最近であれば,医療系のキュレーションサイトの運営なんかが,まさにCSRでの倫理的な面が問われる話題だったと思う。企業は,もちろん企業活動を存続していくには利潤追求の姿勢が必要であるが,そういった経済的活動だけでなく社会に対する責任が求められる。基本責任,義務責任,そして文化,経済,政治,環境様々な支援責任を伴なう。つまり社会貢献。国際規格でも社会的責任に関する規格がありガイダンスとして利用されている。

また,情報開示の積極的な姿勢が望まれ,IRを含め様々な活動に関する積極的で自発的な開示をすることが求められている。

コーポレートガバナンス。これは,最近で言うと家具を取り扱う企業のニュースが新しいだろうか。経営のチェック機能。適切に経営が行われているのか客観的に評価できなければならない。日本は,取締役と経営陣が重複する傾向があり,米国に比べるとチェック機能が弱い。社外取締役の選任などでガバナンス機能を強化できる。