Drafts

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

GitHub のコミット一括削除方法

どこまでもどるか決める、一括削除が適切か立ち止まる

多くの人が参加しているようなプロジェクトではコミットログをいじることは望ましくないとか、基本的にはコミットログをいじることは推奨されていません。パスワードのような機密情報をアップしてしまったとか、大容量のファイルを誤ってアップしてしまったとかそういう場合に適切なんじゃないかと思います。私の場合は後者でした。

また、いざという時のために現在のワークスペースをどこかにコピーしておくことをお勧めします。

手元のワークスペースを直前のコミットの状態に合わせる

git reset --hard HEAD

手元のコミットログを削除

たとえば4つ前まで戻す場合は

git rebase -i HEAD~4

すると

pick c047b57 コミットメッセージ１
pick 7ad53bb コミットメッセージ２
pick 4904961 コミットメッセージ３
pick 0f4a444 コミットメッセージ４

みたいなのを編集する画面になるから、残したいコミットだけを残して削除、保存、エディタを閉じる。

Successfully rebased and updated refs/heads/master.

みたいなメッセージが出る。

それを強制的に GitHub にあげる

git push origin +master

この + 記述が無いと Updates were rejected エラーが出ます。

以上。

参考

■

盆に見た映画の感想。ネタバレ容赦なし（見ていないと意味が分からないと思う）。３つ見たうちの２つに関するメモ。身から出た錆で意気消沈していたので、映画でも見れば気分が変わるかもと期待して。

『セッション』90点

前から見たいなとは思っていた。その理由の一つはジャズをテーマに扱った映画であることだったが、結論から言えば、特にジャズ映画としてはノれなかった。でも、見る価値のある映画だった。あと、注意点として、セッションという邦題はマーケティング上の理由だろうが全く内容を反映していない。

私はこの映画のメインテーマを「求道」だと捉えた。禁欲、自己との闘い、ライバルとの競争や、師弟のありかたも基本的にはその一部に過ぎない。「求道」に関してそういうモチーフはありふれている。平成19年度入学式（大学院）総長式辞 | 東京大学 での「孤独を恐れぬ勇気」からのくだりや、『たたかう音楽』の著者高橋悠治に関するドキュメンタリー なんかも私は連想した。

次世代を育てるための過剰なまでの厳しさを語るシーンは、その後の裏切り行為によって建前として否定されたとみるべきではない。あれも確かにフレッチャーの本音だ。求道において being upset （これを「悔しい」と訳したのは非常に的確だ）は重要な推進力だ。誰にでもそれが効くわけでもなければ、度を越せば鬱や自殺だって引き起こす。Sean Casey を殺してしまったことは大きな損失であるし、フレッチャーはそれにショックを受けている。交通事故という嘘もその罪悪感の裏返しだろう。しかし、

But I tried. I actually fucking tried.

とそういう教育法を実践したことを誇るフレッチャーを殴りつけることができる言葉は、直前の本人の言葉

I never really had a Charlie Parker.

「結果が全て」だということだけだ。そしてその結果は最後に訪れる。拳で殴り掛かったり、倫理的に糾弾することは、求道の埒外だ。アンドリューは最後の喧嘩に音楽で答える。だから結果的にはフレッチャー的なるものが一貫して流れている。Sean Casey に対するフレッチャーの涙のエピソードや女の子への激励はその流れと共存する。

ホモソ云々は、そうラベリングすることがどう役立つのか意味があるのか見当がつかないので詳細な言及を放棄する。

映画の中と同様、現世ではフレッチャーは指導者としては放逐されるだろう。日本なら、芸術家としてさえも放逐されかねない。だからこそ、心の中にフレッチャーを。

余談１

途中の

アンドリュー: Because I wanna be great.

ニコル: And you're not?

アンドリュー: I wanna be one of the greats.

のやり取りで出てくる「偉大」概念や、序盤でフレッチャーに言わされる

I'm here for a reason.

自らの意志で音楽をやっているのだという宣言は、その中身のなさ（「偉大」とはなにかが分からない、理由は何かがわからない）が印象的だ。求道における信念というのは最後に言葉では説明できないものがあるほうが強かったりするものだ。

余談２

Charlie Parker のシンバルエピソードは不正確らしい。参考: Getting Jazz Right in the Movies - The New Yorker

あまり史実をこういう不正確な使い方するのは好きではないし、フレッチャーが自分に都合よく覚えているとしても、それをどっかに注記しておくのが良いかと思う。もとから映画なんかすべてフィクションだとエンドロールにも書いてあるし、そこを気にするのは好みの問題でしかないが。

参考


BUDDY RICH IMPOSSIBLE DRUM SOLO HQ

最後のシーンの元ネタらしい

『エターナル・サンシャイン』70点

ナンパをする映画ということで推薦された。ビフォア・サンセットを例に挙げたので、「電車の中で」という部分も含めて一致している（そんな推薦ができることに驚きｗ）が、あの強引で我儘な感じは女性が口説く側だから許されるのであって、見ててヒヤヒヤするものだった。

クレメンタインがメンヘラキャラで、記憶の消去というネタも、メンヘラの記憶喪失から発想したのかなと思った。そういう意味では途中ＳＦな設定が出てくるものの、非常にリアリティのある映画だった。でも、最後はただ刹那的な恋の肯定に聞こえてしまい、ただ寂しく感じた。

映画のつくりとしては、素晴らしかった。見てる側が記憶消去後の場面から見るため主人公と同じ当惑を感じるとか、過去の思い出が消去のために挿入される構図とか、無駄がなく完璧だった。

僕は映画に薬としての効能を求めるので、見た後に落ち込んじゃうこの映画はおそらく再訪しないと思う。

cron で source コマンドを有効にする方法

結論

crontab に

SHELL=/bin/bash

と書くことで、シェルが bash に切り替わり、source コマンドが使えるようになる。

参考

Windows コマンドプロンプトから Python に変数を渡す

結論

  • スペースを含む変数の場合は " で囲う必要がある。
  • しかし、~(チルダ) を使って自分で設定した変数の "(ダブルクオート)は外せない
    • %変数の使い方に書かれているような特殊変数には効果あり。
    • だから、ちゃんと受け渡し先で解釈されるように試行錯誤。
  • " で囲った場合は \ は基本的には一つでＯＫ
    • ただし、" 直前に \ を置く場合は \\ とする。
    • 例: set path="C:\hoge\fuga piyo\hogera\\"

以下テスト例

> set a="a a"
> python test.py %a% %a%

['test.py', 'a a', 'a a']

> python test.py %a %a
['test.py', 'a']

> set b="b\"
> python test.py %b% %b%
['test.py', 'b" b"']

> set c=c\
> python test.py %c% %c%
['test.py', 'c\\', 'c\\']

> set d=d\\
> python test.py %d% %d%
['test.py', 'd\\\\', 'd\\\\']

> set e=e e\\
> python test.py %e% %e%
['test.py', 'e', 'e\\\\', 'e', 'e\\\\']

> set f="f f\\"
> python test.py %f% %f%
['test.py', 'f f\\', 'f f\\']

> set g="g\\ g\\"
> python test.py %g% %g%
['test.py', 'g\\\\ g\\', 'g\\\\ g\\']

> set h="h\ h\\"
> python test.py %h% %h%
['test.py', 'h\\ h\\', 'h\\ h\\']

> python test.py %~h%
The following usage of the path operator in batch-parameter
substitution is invalid: %~h%

For valid formats type CALL /? or FOR /?

> set i="i i\"
> python test.py %i% %i%
['test.py', 'i i" i', 'i"']

test.py

import sys
print(sys.argv)

モバイルファーストというバズワードについて

きっと、ブログを書くような文字の入力はそのうち音声認識に置き換わる、だから一般人にはキーボードは不要になる…

そういう予想は支持するが、モバイルファーストという言葉で指されるのは、大抵「だから、うちのソリューションでモバイルやりましょう」と持っていくための煽りが多くて正直馬鹿にしていた。

例えば、Webサイト設計で「モバイルファースト」はなぜ重要なのか？allWebクリエイター塾 菊池 崇 先生が解説 - schoo（スクー） WEB-campus では

  • モバイルの方が市場が広い
  • モバイルの画面が小さい分、本当に重要なことにフォーカスできる
  • モバイルの機能が様々な新しいイノベーションの土台になる

とモバイルファーストのメリットが説明されている。

１つ目はわかる。２つ目はもともとZenの国日本がなんでYahooのトップ画面みたいなん好むねんみたいなデザインの問題の話であって、もし広い画面でも「本当に重要なことにフォーカス」できないならそれはデザインが悪い。３つ目はモバイルがもつセンサー機能を活用したウェブサイトが例に挙げられているが、そんなものはUXのデザインの時点で出てくる話であって、ウェブサイト設計の段階で出てくる話ではない。

…という具合に、全く学ぶところが見つからなかったモバイルファーストという概念だが、最近軽量な CSS のフレームワークに乗り換えて開発することが多く、その Milligram | A minimalist CSS framework. になるほどな文言をみつけた。

The Mobile First is the design strategy that takes priority development for mobile devices like smartphones and tablets. It means all styles outside of a media queries apply to all devices, then larger screens are targeted for enhancement. This prevents small devices from having to parse tons of unused CSS.

「（前略）全メディアに共通するスタイルがまず適用されて、大きなスクリーンは拡張として対象にされる。小さいデバイスが使わない大量のCSSを解析するの無駄だろう」。

つまり、モバイルにもデスクトップにも対応しますって言ったときに、前者の方が非力なんだから後者の方が重くてよい。そうならばモバイルに最適化した設計をして、それをデスクトップに拡張する CSS を追加で書けという話になる。

skeleton-frameworkとかでもなんでリストの間こんなに幅が開いているんだろうと思ったけど、実際モバイルで操作すると、リストがリンクになってた場合、リストが詰まっていると指で押す場所が難しくなるのだ。デスクトップではもうすこし狭めに見せたいということなら、それを追加で書けばいいだろう。

これはまあウェブデザインだけじゃなくていろんな制度設計にも言えるけれど、弱くて人数の多い対象者を第一のモデルにしてデザインすることでデザインの想定と不一致があった場合に背負うユーザのコストの負荷を全体で最小化するというのは良いストラテジーで、それをウェブに適用したら「モバイルファースト」になるんだよね。

参考（これを書くにあたって読んだもの、というだけ）：

Annotation Properties の Semantics

2009-09-07 に書かれた Dublin Core in OWL 2 という文書には

And annotation properties allow for both because they have no semantic relevance for reasoning.

というくだりがあって、明確に Literal しか目的語に取らない Data Properties と、目的語に任意の individual を取る Object Properties に対し、どっちとるかわからない場合に押し込める先としての (Dirty?) Hack が頭にあった。

で、先日書いた「意味」の認識を更新し続けるためのフレームワークを書いた論文にも domain がハッキリしない述語に関して owl2 の semantics を引いて注を加えたのだが、そこで引いたOWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition)の中に以下のくだりを見つけてしまった。

For annotations properties note that annotations are not "semantic-free" under the OWL 2 RDF-Based Semantics. Just like every other triple or set of triples occurring in an RDF graph, an annotation is assigned a truth value by any given OWL 2 RDF-Based interpretation. Hence, although annotations are meant to be "semantically weak", i.e., their formal meaning does not significantly exceed that originating from the RDF Semantics specification, adding an annotation may still change the meaning of an ontology. A similar discussion holds for statements that are built from ontology properties, such as owl:imports, which are used to define relationships between two ontologies.

確かに "semantically weak" だとは認めているが、annotation property の値が主語の意味を変えうると書いている（この文脈では主語は TBox の中の語彙が想定されている）。そりゃ、元の文脈で、X は ObjectProperty or DataProperty ∧ どちらも意味を持つ → X は意味を持つ、ことが当然推論されるので、"semantic-free" だとは思っていないが、じゃあそもそも "semantically weak" だとか議論する意味はどこにあったのだろうと疑問になる。OWL 意味論で拡張される部分が無いと言いたいのだろうか。

ここらへんを手がかりに Annotation Properties の Semantics を考えることで、「どっちとるかわからない場合に押し込める」というのはどのくらい正しいのか検討してみたい。

ウェブのオントロジー言語OWL -- ウェブに存在するものとその関係の定義では、

プロパティには、個体（オブジェクト）を別の個体（オブジェクト）と関連づける個体値型プロパティと、オブジェクトをデータ型値に結びつけるデータ値型プロパティがあります。両者はそれぞれowl:ObjectProperty要素、owl:DatatypeProperty要素で定義します。また、特別なプロパティとしてオントロジーの管理情報を記述するowl:OntologyProperty、オントロジーの注釈に用いるowl:AnnotationPropertyがあります。OWLでのプロパティは、必ずこの4つのどれかのタイプを持たなければなりません（個体の記述に用いるのは個体値型もしくはデータ値型のみ）。

と書かれている。Dublin Core も個々の書誌情報の記述＝個体の記述なのだから、Annotaion Properties を用いるのは正しくないことになる。ところでこの制約はどこから来ているのか。

OWL 2 Web Ontology Language New Features and Rationale の punningあたりを見ていると、これは OWL 1 の制約であって、OWL 2 ではその制約が緩められている。さっきの制約を記述したページはとても古く、おそらく OWL 2 の変更を反映していないと考えられる。

ちなみに、Annotation Properties の特殊性は、OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition) #5.5 Annotation Properties にも "IRIs from the reserved vocabulary other than the ones listed above must not be used to identify annotation properties in an OWL 2 DL ontology." という形で、OWL 2 DL においては 9つの Annotation Properties しか許容されないと書いている。これは、これら9つしか OWL 2 DL において意味論がハッキリしていないからというだけであって、その Annotation Property を用いる対象自体は"Annotation properties can be used to provide an annotation for an ontology, axiom, or an IRI." と書いているので個体に対して用いるのもアリだ。

だって、この9つというのは、

  • The rdfs:label annotation property can be used to provide an IRI with a human-readable label.
  • The rdfs:comment annotation property can be used to provide an IRI with a human-readable comment.
  • The rdfs:seeAlso annotation property can be used to provide an IRI with another IRI such that the latter provides additional information about the former.
  • The rdfs:isDefinedBy annotation property can be used to provide an IRI with another IRI such that the latter provides information about the definition of the former; the way in which this information is provided is not described by this specification.
  • An annotation with the owl:deprecated annotation property and the value equal to "true"^^xsd:boolean can be used to specify that an IRI is deprecated.
  • The owl:versionInfo annotation property can be used to provide an IRI with a string that describes the IRI's version.
  • The owl:priorVersion annotation property is described in more detail in Section 3.5.
  • The owl:backwardCompatibleWith annotation property is described in more detail in Section 3.5.
  • The owl:incompatibleWith annotation property is described in more detail in Section 3.5.

なんだから、rdfs:label が個体に用いれないとなったら大変だ。

あと、 OWL 2 の RDF-Based Semanticsにおいて、Table 5.1 と 5.2 を見る限り、owl:AnnotationProperty の domain と range は IOAP に等しく、その外延が IR × IR であり、IR は空集合を除くすべての要素を指すわけだから、 domain と range の観点からしていえば "semantic-free" だ。一方で、semantics は domain と range にだけ依存する（≒型にのみ依存する）わけではないので、用法としてどんなIRIに用いても意味があるかは微妙。

そして、この domain や range の面からは全く制約できないこと、部分集合に対してしか意味論をキッチリ定義できないこと、あたりを指して "semantically weak" と言わざるを得ないのだと思う。一般的にはこれはもっとポジティブに「人間にとって"意味"があるが、機械にとって"意味"がない」という認識がなされていると思うが、つまり人間にとってどう意味があるか定式化できないんでしょう。

ここまで見てくると、Annotation Properties は 弱い Semantics を有していて、それは domain や range で規定されるようなものではなくて、推論機構によってはちゃんと規定された Semantics を有している Annotation Properties は9つだけに限られていたりする。そうすると、目的語が何かわからないから Dublin Core のような語彙を Annotation Property にしておくといのは Dirty Hack くさい（そういう domain や range の議論の外に Annotation Properties の Semantics の核があるから）。一方で、title が常にリテラル値を取ると決めたならば、rdfs:label の subproperty にしてしまえばいいのだ。元の"Dublin Core in OWL 2"ではdcterms:titleがリテラル値以外を取るかもしれないなんて書かれているが、2012年更新版では明確にリテラル値だと書かれているのだし。

もし、リテラルかindividualかどちらを取るかわからない述語があれば、単に Property だとだけ定義しておけばいいし、その Semantics を明確に定義したければ、Object Property にしておいて、リテラル値を目的語に取りたいときには、

A 今議論している述語 [rdfs:label リテラル値].

のように空ノードを用いて individual 化すればよいのではないかと思う。こうして置くことには意義があり、SPARQLでクエリを書くときに、（間に挟まるのが Named か Non-nammed Individual かという違いはあれど）リテラル値 は同じ位置に来るため、SequencePath を用いてシンプルに書くことができる。なによりモデル構造が統一されるのは気持ちいいではないか（笑）なんにせよ、range の曖昧性は Annotation Properties を採用する理由にしてはならないと思う。

日本語でこれを書いてもこの議論に興味と見識がある人はかなり限られると思うけれど、変なところがあったらぜひ忌憚なくご指摘ください。

最近ブログを更新していないことの理由と効用

■ - Drafts で書いていた Markdown container のエディタとＣＭＳのα版が完成したため、つまり強力なチラシの裏を手に入れたため、ブログの更新頻度がガクッと下がった。実際に書いてみると、一部の実装は Python で行い、ほとんどの実装を Windows のコマンドスクリプトで書くという予想外の実装になった。使い勝手を上げるためにどうしてもＯＳと密結合してしまうのだ。レジストリもいじっている。今後は Linux や Mac でも同様のことができるか確かめたい。

ちなみに、もともと１ファイルで持ち運びたいという欲求で設計したものだったが、記事の中でも書いているようにエディタの設計にあたって、一旦zipを解凍して取り扱うようにしたこともあり、現在は非圧縮版のみで環境を整えている。つまりフォルダ単位で記事を管理しているだけである。

今、鋭意整えているのはメタデータの仕様であり、container.xml ではなく、metadata.json を META-INF に入れている。発想のもととなったTextBundle とかも json でメタデータを持っており、なおかつ拡張性などについても設計しているのでそういう部分を参考にしつつ、Dublin Core のようなもっと広い文脈のものも考慮に入れている。

効用

  • 余計なことをブログに書くことが少なくなったのではないか
    • 人に読まれることを前提に書かなくなったので、余計な事に関する記事を作成する丁寧さが減った
      • それはそういう方面での学びを放棄することでもあるので一長一短だけれど
  • もともと手元にあった別のチラシの裏システムが効率的になった
    • このブログに書くような、メモと記事の間のような立場の書き物を置く場所ができたので、メモのところに肥大なまとまりが蓄積されてしまって年間１万行以上のメモが産出されて全文検索以外に参照する術がないという状況を脱した。そのメモはあとで自分が読んでも分からないこともあるレベルだったので、このブログのように少なくとも僕が読めば１年前の記事でもわかるレベルにはなった。
  • もう少し公開したら他の人の役に立ちそうなことも公開しなくなってしまった。これはデメリットかもね。
    • まあそれも熟成したら公開するから良いのではないか。