Drafts

@cm3 の草稿置場 / 少々Wikiっぽく使っているので中身は適宜追記修正されます。

Paint.net で透過画像を作る

大きくわけて2つの方法があって

  1. 魔法の杖で抜く
  2. 専用のプラグインで抜く

魔法の杖で抜く

f:id:cm3ak:20200404154638p:plain

この魔法の杖で透過したい部分を選択して抜く。手軽だし、よしなにしてくれるけれどちょっと雑なので思ったようにいかなかったりもする

専用のプラグインで抜く

f:id:cm3ak:20200404155308p:plain

Kill Color Keeper ってのをダウンロードしてインストールする。インストールは Paint.net のインストールフォルダの Effects に解凍してでてきた dll ファイルを入れると、エフェクト > Color のところで選べるようになる。使い方はダウンロードのサイトを見ればよいが、色を直接指定して、その色からどうズレていても透過にするかとか、数値的に指定できるので、元から意図されて背景色が指定されているグリーンバックてきな状況できれいに抜ける

Google Photos のアルバムのコメントを使って、写真とコメント中心のウェブサイトを生成する

Google Photos は基本、容量無制限に使うことができるので、とても便利だ。間にコメントを入れたりもできるが、アルバムページのレイアウトの自由度自体はあまり高くない。そこで

  • Google Photos のアルバムをそのままウェブページに読み込み
  • コメントを解析してウェブの表示を工夫する

という方針で html + css + js だけでサイトを作る方法を書く(jsを正しく動かすために http-server は使っている)

f:id:cm3ak:20200104011732p:plain

  • Get started with REST  |  Google Photos APIs  |  Google Developersclient_id を得る。client_secret はサーバサイドを実装しないので使わない。http-server 使うので、http://localhost:8080Authorised JavaScript originsAuthorised redirect URIs に設定しておく。(環境によって適宜ポートを書き換えてください)
  • API key も取得する。同じ画面の Credentials in APIs & Services のリンクから、Create Credentials する。

f:id:cm3ak:20200104013258p:plain

f:id:cm3ak:20200104012602p:plain

完成品サンプル gist

troubleshooting

その他参考

証明書は正しいはずなのに NET::ERR_CERT_AUTHORITY_INVALID !?

NET::ERR_CERT_AUTHORITY_INVALID でググる

  • 利用者がその意味を理解する、適切な行動をとるための情報
  • サイト管理者がその意味を理解する、適切な行動をとるための情報
    • 証明書の問題を修正する
    • 時刻のズレを修正する

の情報が出てくる。証明書も、時刻も問題ないはずで、このエラーがでて"サイト管理者"が訂正できないパターンがあってそれにハマった。

管理しているサイトにアクセスしている環境に InterScan Web Security のようなWebゲートウェイセキュリティソフトウェアが導入されており、証明書を勝手にインポートしており、それが接続先と当然一致しないためこのエラーが出ていた。

おそらくこのパターンであると確認する方法:

  • SSL Certificate Checker - Diagnostic Tool | DigiCert.com のようなオンラインツールで証明書に何の問題もないことを確認する
  • ネットワークを手持ちのwifiルータと切り替えて、証明書が切り替わっていることを確認する。私の場合は発行者が IWSS.TREND となっていたので、それで気づくべきだった。

f:id:cm3ak:20191220201010p:plain

f:id:cm3ak:20191220201024p:plain

根本的な解決策は、その会社のネットワーク担当に問題を報告してWebゲートウェイセキュリティソフトウェアの設定を適切に変えてもらうことだと思う。

参考

f:id:cm3ak:20191220201523p:plain

Windows10で入力言語を切り替えるショートカットキーを無効にする方法(2019/12版)

いや、2019/12版とか書かなきゃいけないのが酷すぎるぜMS。

地域

f:id:cm3ak:20191203172807p:plain

言語設定

f:id:cm3ak:20191203172822p:plain

常に規定として使用する入力方式を選択する

f:id:cm3ak:20191203172839p:plain

入力言語のホットキー

f:id:cm3ak:20191203172853p:plain

ゴール。ここでショートカットを無効にする。

f:id:cm3ak:20191203173011p:plain

参考:

以下の2つのサイトの通りにやろうとすると、途中で当該のリンクが無いので行き詰る。

cmder導入 2019/11/12版

Windowsは最近コマンドプロンプトを進化させているので、cmderの必要性は薄れてきている。まだ、たまに必要になるときもあると思うので、パソコン移行の際に4年半前の記事 cmder導入 - Drafts をアップデートした内容を記載しておく。基本ほとんど一緒です。cmder(mini)を導入した。

Explorerと統合

f:id:cm3ak:20150413151555p:plain

すると好きなディレクトリで簡便にCmderを立ち上げることができるようになる。

f:id:cm3ak:20150413151810p:plain

エイリアスの設定

cmder\config\user_aliases.cmdinit.bat から読み込まれているので、そこを変更。

miniでインストールしたこともあって

e.=explorer .
gl=git log --oneline --all --graph --decorate  $*
ls=ls --color $*

を削除し、

ls=dir /B $*
pwd=cd
mv=move $*
clear=cls
f=fossil $*

を設定した。

スタートアップ時にUTF-8に切り替え

上で起動時に読み込んでいるinit.batの末尾に

chcp 65001

を書き込んでおくと、起動時にUTF-8で起動できる。しかし、これによって

>>> sys.stdin.encoding
'cp65001'
>>> sys.stdout.encoding
'cp65001'
>>> sys.stderr.encoding
'cp65001'

と設定されてしまいこれらを使うプログラムがLookupError: unknown encoding: cp65001というエラーを吐いてしまうので、

set PYTHONIOENCODING=utf-8

も足しておくとよい(参考:Windows cmd encoding change causes Python crash - Stack Overflow)。

f:id:cm3ak:20150410200044p:plain

タイ語もちゃんと表示される^^

SSH クライアントは PuTTY のまま

登録し直すのが面倒というのもあるが、ファイルの交換についてはWinSCPみたいなソフトが便利で、それと連携しているのでPuTTYが便利というのが大きな理由。plink.exeをssh.exeにリネームしてパスを通しておけば、sshコマンドも使えるようになるが、putty plink.exe disabled history - Google グループにあるように上ボタンとかで履歴が効かないので不便。だから、普通にputtyを使っている。-load オプションを使えば登録しておいたセッションをロードできる。

バッチファイルを Cmder で実行する方法

:: Add init batch file if there is "init.bat" in current directory
@if exist %CD%\init.bat (
    call %CD%\init.bat
)

:: Add init batch file via EXEC_BAT environmental variable
@if defined EXEC_BAT (
    call %EXEC_BAT%
)

これを cmder\vendor\init.bat 内に記述。

実行ファイルのカレントディレクトリに init.bat という名前で置くか、

set "EXEC_BAT=.\\pyenv3\\Scripts\\activate.bat"
start "" "C:\Users\User\programs\cmder\Cmder.exe"

のようにしてcmderを立ち上げるときに環境変数経由で実行するバッチファイルを指定してあげると読み込める。例示しているように vitrualenv とか使っている時に便利。

ちなみに activate.bat の

set "PROMPT=$P:$_$G$S"

コメントアウトしておくと cmder のプロンプトを書き換えられずに済むので良い。

引数付でも実行できる。例えば、fui.bat

@echo off

set p=%~1%
cd "%DROPBOX%\projects\"
set EXEC_BAT="fui-sub.bat" %p%
start "" "C:\Users\User\programs\cmder\Cmder.exe"

と書いておいて、EXEC_BATで呼び出しているfui-sub.bat

@echo off

set p=%~1%
cd "%DROPBOX%\projects\%p%\"
echo opening %p% fossil ui page...
fossil ui

って書いておけば、引数は受け継がれ、cmder を使って fossil ui が実行される。

参考:

"哇ㄟ"@79-AAA-jh = "我的"@79-AAA

f:id:cm3ak:20190728171432p:plain
哇ㄟ筆勒

YouTube で聴いていた歌の間奏部分で、"哇ㄟ筆勒" という表記が出てきてよくわからなかったので、調べてみたら、これは台湾語を漢字と注音記号で書いた表記で、"哇ㄟ" の部分は "我的" の意味、勒 は語気助詞(呢、啊、吧とかの仲間)で「~は?」という疑問を表すものだった。

"哇ㄟ" は発音としてアルファベットで書くと、wa ei となる。台語 警察を呼ぶ Call the policeというページの発音の「我的」で始まるフレーズを聞くとそれっぽい。

勒については 台湾で使われる中国語 語気助詞の違いについて ( 2 ) (音声付き) -「喔 (o),唷 (yo),勒/咧 (lei/lie),囉 (luo)」 | ぽずかふぇ に書かれていたし、大陸中国人にも聞いたけれど知っていた。

ちなみに、表題の 79-AAA-jh は 所謂台湾語=Taiwanese Hokkien を示す Linguasphere のIDである。IETF言語タグ の language tag にはISO 639-3が使われているがそれで台湾語を指すことはできない。linguasphère は単なる研究ネットワークでISOほどの標準化機能は無く、データベースとしてはある研究者が Han-Yu - hortensj-garden.org のように作っているものが存在するのみで知名度は低いが、ISO 639 より網羅性が高い。(階層性を持ち込んでしまうと、研究によって更新されうるので、あまりID体系としては好みじゃないけれど)

項目名付きリテラルという選択肢 - Drafts の補足として。

他の選択肢として、述語を詳細化する以外に typed literal にするという選択肢があって、それについて検討を加えたのと、CSVのセル内の構造データの扱い方についてのメモを書いておく

typed literal について

Triple store で一般的にサポートされている typed literal は XSD data types と呼ばれるもので、intとかdoubleとかdateTimeとかW3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes に見られるようなものだ。これによって数字や日付の一致や比較ができるようになっている。

項目名付きリテラルも"項目名がついたリテラルだ"という処理ができれば、項目の一覧を出したりできるといったように利便性が上がるかもしれないので、typed literal として扱う方法はないか、もしくは、項目名ごとに別々に typed literal にするのはどうなのか、そもそも typed literal は規約上、実装上、どのようになっているのか、と考えて、

を流し読んで、その後の実情などもチェックしたのだけれど、

  • typed literal の扱いは基本的に実装依存
  • typed literal の type を示す URI に何を書くかさえ規定されていない

さっき言及した基本的な xsd についてさえ

Multiple datatypes may be de-fined in the same document, such asxsd:stringandxsd:intthat are defined in thesame document at locationhttp://www.w3.org/2001/XMLSchema. Hence the RDFprocessor would not know what part of the code it should execute for each datatype.

という状況

  • だから論文では以下のインタフェースをJavaScriptで提供するURLをURIにする提案をしている
String getIri()
Boolean isWellFormed (lexicalForm)
Boolean recognisesDatatype (datatypeIri)
String[] getRecognisedDatatypes ()
Boolean isEqual (lexForm1, lexForm2[, datatypeIri2])
Integer compare (lexForm1, lexForm2[, datatypeIri2])
String getNormalForm (lexicalForm1)
String importLiteral (lexicalForm, datatypeIri)
String exportLiteral (lexicalForm, datatypeIri)

という結論です。

Custom Datatype というページに述語の詳細化のメリットが

  • Simpler querying of data by allowing the use of triple patterns, rather than FILTERs for extracting data of a common type.
  • More explicit, fine-grained semantics

デメリットが

  • Increases the number of very similar properties, requiring redundancy of data or reasoning to allow applications to treat them generically
  • Doesn't address the core requirement to indicate the lexical form of a structured value

と書かれていて、typed literal については

  • Use a custom datatype to label particular types of structured value that share a common lexical form. These values may be associated with a broad range of different properties. Processing applications may want to implement a common set type conversions or display options for the values.
  • Use a sub-property in all other cases

と書かれている。項目付きリテラルは幅広いプロパティの値として使えるので、規定しても良いけれども、結局ご利益が「項目の一覧を出したり」云々ならば、分析対象の項目名付きリテラルをSPARQLで一覧出力して、それに対してテキスト処理するのが正当であり、それが簡単にできるようにしておけば良い。また、項目ごとに別々の typed literal にするというのは以上より論外の選択肢。

もっといえば、RDF化するまえの元データをデータリポジトリで共有しておいた方がこういう分析には向く。

雑多な表構造メタデータに混ざってくるセル内のリスト構造

"1,4,10" みたいにリスト構造が1個のセルの中に入ってくることってそれなりにある。関わってるプロジェクトのうち2つでエクセルのセル内でリスト構造を扱うことになり、どちらも検討の結果セミコロンがデリミタに選定されている。カンマの方がプログラミング言語的にはリスト構造のデリミタとして一般的だけれども、カンマは文章内の読点や人名の姓名順序の入替を示す場合など他の用例が多すぎる。セミコロンもそれが無いわけではないけれど、ずっとマシ。

デリミタがちゃんと規定されているならば、CSVからRDFに変換する時点で、

  • external-object: 1
  • external-object: 4
  • external-object: 10

のように分割することは可能だし、そのほうがSPARQLの枠内である程度の分析ができるので良い。そもそもリスト構造がある時点で、リストアップされる対象が複数回出現することが多いだろうから、特段理由がない限り、項目付きリテラルではなくちゃんと構造化すると思うので、リスト構造がある場合に項目名付きリテラルを使う機会は少ないかもしれない。

セル内に項目名が現れることがある

話をややこしくしまって悪いけど、表構造データのセルの中に項目名っぽいものがあることがある。備考欄とかに多い。でも、これは仕方なくって、初めから表構造が完璧に決まってることなんてあまりない、データベース作っていって、それで初めて表の構造が定まってきたり、たまに出てくる値を備考欄に押し込めたかったり。

項目名付きリテラルの項目名は表のカラム名相当を対象にしているわけだけど、セル中の項目名についてはどうあつかったらよいのだろうか悩んでいる。

記述法は"関連事件: 尼港事件; OCM: 720; 726;" みたいな記法を思いついているのだけれど、いくつかのプロジェクトで試してからまた報告する。カッコを排し、リストのデリミタを一種類で済ませつつ、複数の項目名を入れ込めるようにするとか、さまざまな要求に従って今はこの形式になっているのだけど、前に作ったJSON Editorを捨ててこの方式でいくのかとか色々ありまして。

  • : と ; は見分けがつきにくい : はかなり良く使われるので固定したい。; の代わりに / を使おうとしたが ファイルのパスを書いたり、日付を書いたりでよく使うのでだめ、, カンマを再検討したけれど、やっぱり | パイプくらいがいいのではないか。
  • Model for Tabular Data and Metadata on the Web non-normative だけれど、こういうセルの parsing の話がある。これはかなり自由度を高く設定しているので、簡単に使い、実装するためのサブセットを見極めたほうがいい気はする。