| - | (A) | (B) | (C) |
| かしこまった席で着る服 | よそいき | よそいき | よそいき |
| 学校などの日常的な場で着る服 | 普段着 | 普段着 | 普段着 |
| 外出しない日中に着る服 | 普段着 | 寝間着 | 部屋着 |
| 寝るときに着る服 | 寝間着 | 寝間着 | 寝間着 |
この「部屋着」という文化がいつ、どこから来たのか謎なんだよなぁ。
あと「よそいき」も謎。学校行事で「子供は汚れてもいい服装で来てください」と言われても、それは「動きやすい服装で来てください」と同じ意味で、汚れちゃいけない服を子供に着せるというのは意味不明だった。それに、私の小学校の卒業式（1994年）では、いわゆる「よそいき」を着ている人は少数派だった。現在の卒業式の風景は、やはりスタジオアリスの作り上げた文化なのか？
rsyncは大量のファイルを走査するため、普通に実行するとページキャッシュに乗ったファイルが追い出されてしまう。 Linuxの場合、nocacheコマンド*1を利用することでページキャッシュを汚さずにrsyncを実行できる。リモートでもrsyncが実行されるので、以下のように実行する必要がある。
nocache rsync -aiv --rsync-patch='nocache rsync' some-host:/src/ /dest/
ただし、nocacheコマンドはDebianやUbuntuであればaptで取ってこれるが、CentOSやRHELのリポジトリにはないみたい*2。 そのため、RHELのrsyncでページキャッシュを汚さないためには、nocacheをソースで取ってきてmake installするしかない模様。
なお、rsync本体に対してページキャッシュを汚さないためのオプション --drop-cache が提案されたことがあるが、Linux-specificすぎるとのことでWONTFIXになっている*3。それに伴い、RHELのリポジトリでもWONTFIXになっている（RHELのrsyncのみパッチが当たっているとかいうことはない）*4。
変換対照の文字は、文化庁 常用漢字表*1で康煕字典体が示されているものを対照とした。常用漢字表のPDFの内容をテキストファイルへダンプし、以下のスクリプトで常用漢字とカッコ書きの康煕字典体とのペアを抽出した*2。
> Get-Content .\常用漢字表.txt | Where-Object { $_ -match '(?<Oyaji>.?) （(?<Itaiji>.?)） ' } | Foreach-Object { ("{0}{1}" -F $Matches.Oyaji, $Matches.Itaiji) }
上記の結果をもとに、trコマンド相当のコマンドレット*3を使って変換処理を実装した。
function tr { Param( [Parameter(ValueFromPipeline=$true,Mandatory=$true)] [string] $TargetString, [Parameter(Mandatory=$true)] [string] $FromString, [Parameter(Mandatory=$true)] [string] $ToString ) begin { # [-split ""] splits a surrogate pair into two invalid characters, # so the code below is not suitable for this purpose # $FromStringArray = $FromString -split ""; # $FromStringArray = $FromStringArray[1..($FromStringArray.length-2)]; # Split string into character array $FromStringArray = @(); $FromStringBytes = [Text.Encoding]::UTF32.GetBytes($FromString); for ($i=0; $i -lt $FromStringBytes.length; $i+=4) { $FromStringArray += [Text.Encoding]::UTF32.GetString($FromStringBytes, $i, 4); } $ToStringArray = @(); $ToStringBytes = [Text.Encoding]::UTF32.GetBytes($ToString); for ($i=0; $i -lt $ToStringBytes.length; $i+=4) { $ToStringArray += [Text.Encoding]::UTF32.GetString($ToStringBytes, $i, 4); } } process { for ($i=0; $i -lt $FromStringArray.Length -and $i -lt $ToStringArray.Length; $i++) { $TargetString = $TargetString.Replace($FromStringArray[$i],$ToStringArray[$i]); } $TargetString } } function ConvertFrom-Kokijitentai { Param( [Parameter(ValueFromPipeline=$true,Mandatory=$true)] [string] $TargetString ) begin { $FromString = "亞惡壓圍醫爲壹逸隱榮營衞驛謁圓鹽緣艷應歐毆櫻奧橫溫穩假價禍畫會悔海繪壞懷慨槪擴殼覺學嶽樂喝渴褐罐卷陷勸寬漢關歡觀氣祈既歸器僞戲犧舊據擧虛峽挾狹鄕響曉勤謹區驅勳薰徑莖惠揭溪經螢輕繼鷄藝擊缺硏縣儉劍險圈檢獻權顯驗嚴廣效恆黃鑛號國黑穀碎濟齋殺雜參棧蠶慘贊殘絲祉視齒兒辭濕實寫社者煮釋壽收臭從澁獸縱祝肅處暑署緖諸敍將祥稱涉燒證奬條狀乘淨剩疊繩壤孃讓釀觸囑神眞寢愼盡圖粹醉穗隨髓樞數瀨聲齊靜竊攝節專淺戰踐錢潛纖禪祖雙壯爭莊搜插巢曾瘦裝僧層總騷增憎藏贈臟卽屬續墮對體帶滯臺瀧擇澤擔單膽嘆團斷彈遲癡蟲晝鑄著廳徵聽懲敕鎭塚遞鐵點轉傳都燈當黨盜稻鬭德獨讀突屆難貳惱腦霸拜廢賣梅麥發髮拔繁晚蠻卑祕碑濱賓頻敏甁侮福拂佛倂竝塀餠邊變辨瓣辯勉步寶豐襃墨飜每萬滿免麵默彌譯藥與豫餘譽搖樣謠來賴亂覽欄龍隆虜兩獵綠淚壘類禮勵戾靈齡曆歷戀練鍊爐勞郞朗廊樓錄灣" $ToString = "亜悪圧囲医為壱逸隠栄営衛駅謁円塩縁艶応欧殴桜奥横温穏仮価禍画会悔海絵壊懐慨概拡殻覚学岳楽喝渇褐缶巻陥勧寛漢関歓観気祈既帰器偽戯犠旧拠挙虚峡挟狭郷響暁勤謹区駆勲薫径茎恵掲渓経蛍軽継鶏芸撃欠研県倹剣険圏検献権顕験厳広効恒黄鉱号国黒穀砕済斎殺雑参桟蚕惨賛残糸祉視歯児辞湿実写社者煮釈寿収臭従渋獣縦祝粛処暑署緒諸叙将祥称渉焼証奨条状乗浄剰畳縄壌嬢譲醸触嘱神真寝慎尽図粋酔穂随髄枢数瀬声斉静窃摂節専浅戦践銭潜繊禅祖双壮争荘捜挿巣曽痩装僧層総騒増憎蔵贈臓即属続堕対体帯滞台滝択沢担単胆嘆団断弾遅痴虫昼鋳著庁徴聴懲勅鎮塚逓鉄点転伝都灯当党盗稲闘徳独読突届難弐悩脳覇拝廃売梅麦発髪抜繁晩蛮卑秘碑浜賓頻敏瓶侮福払仏併並塀餅辺変弁弁弁勉歩宝豊褒墨翻毎万満免麺黙弥訳薬与予余誉揺様謡来頼乱覧欄竜隆虜両猟緑涙塁類礼励戻霊齢暦歴恋練錬炉労郎朗廊楼録湾" } process { tr -TargetString $TargetString -FromString $FromString -ToString $ToString } }
PS C:\> ConvertFrom-Kokijitentai "慶應義塾大學" 慶応義塾大学 PS C:\> ConvertFrom-Kokijitentai "智辯和歌山" 智弁和歌山 PS C:\> ConvertFrom-Kokijitentai "寶焼酎" 宝焼酎
*1:http://www.bunka.go.jp/kokugo_nihongo/sisaku/joho/joho/kijun/naikaku/pdf/joyokanjihyo_20101130.pdf
*2:「餠」「辨」「瓣」「辯」の4字は上手く抽出できなかったので手作業で追加した
どっちかもいうとこっちが本題。
さて、ソフトウェア考古学の目的としては、
の他にも、poorly-documentedなレガシーシステムのソースコードから、その仕様（あるいは意図）を読み解き復元し、システム再構築のインプットにするというケースが考えられます。
システムの技術的負債の解消や開発者の技術継承などを目的としてシステムを再構築する考え方としては、Fowler(2014)による犠牲的アーキテクチャ*1、および高橋 (2017)による式年遷宮アーキテクチャ*2が提案されています。 システム再構築にあたっては、セカンドシステム症候群を避けるためにも、まずは欲張らない（つまり、現行システムと同程度の）機能をカバーするよう開発を行うわけですが、その際これまで現行システムが本番環境で踏みつけてきた様々なコーナーケースの地雷を避けるには、現行システムの処理がなぜ現在のようになっているのかの理解が欠かせません。
ここで「システム再構築のインプットとなる設計思想の復元」を目的としたソフトウェア考古学的活動が必要になると思うのですが、そのような論文は見当たりません。とすると、
のどれかなのかなぁと思うのですが、どうなんでしょうね？（3に一票入れたいのですが、悲観的に過ぎるかな？）
ソフトウェア考古学（Software Archaeology）という考え方は、OOPSLA 2001で提唱されたのが始まりのようです *1。 Wikipediaにある通り *2 、poorly-documentedなレガシーシステムのソースコードやドキュメントをどう読み解くか？というところから始まったようなのですが、現時点では、Google Scholarで調べる限り、ソフトウェア考古学の研究分野は大きく以下の2つに分かれているように見えます。
分析に用いる手法や、その目的から見ると、後者はどちらかといえば「ソフトウェア考古学」というより「ソフトウェア発生学 (Software Embryology)」と呼ぶべきかもしれません。
現代のアジャイルソフトウェア開発においては、知識を個人でなく組織に溜め込むことで、必要なドキュメントを減らそう、それで代替できるドキュメントは作らないようにしよう、という考え方があるようです（聞いただけの話ですが……）。 ただ、ソフトウェア考古学が生まれた経緯を見るに「知識を組織に溜め込むことで、保守に必要な知識が失われないようにする」のは、果たして可能なのだろうか？ドキュメントを作らないことで、逆にソフトウェア考古学の出番が増えやしないか？という点は疑問に思っています。開発チームは存続していても、メンバーの退職・異動・昇進などのイベントを経ることで、どうしても開発開始当初に考えられていた設計上の思想はチーム内でも薄まっていきます。大量のバックグラウンドや経緯や意図を伝えるには、それに見あった量のドキュメントが必要なのでは？
アジャイルソフトウェア開発宣言がまとめられたのは2001年、今年で18年です。アジャイルソフトウェア開発の黎明期に作られたソフトウェアの開発思想や背景は、今でもチーム内に知識として保存されているのでしょうか？また、ソフトウェア考古学なしでもそのソフトウェアの保守開発に立ち向かえるのでしょうか？
*1:Ward Cunningham, Andrew Hunt, Brian Marick, Dave Thomas, "Software Archeology: Understanding Large Systems", OOPSLA 2001 Workshop, URL: https://web.archive.org/web/20100612232147/http://www.visibleworkings.com/archeology/position-papers.html
*2:https://en.wikipedia.org/wiki/Software_archaeology#cite_note-RGBH-1
*3:Bryon Moyer, "Software Archeology: Modernizing Old Systems," Embedded Technology Journal, March 4, 2009. URL: https://www.omg.org/adm/docs/Software_Archeology_4-Mar-2009.pdf
*4:Carrington, David, and S-K. Kim. "Teaching software design with open source software." 33rd Annual Frontiers in Education, 2003. FIE 2003.. Vol. 3. IEEE, 2003. URL: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.103.2003&rep=rep1&type=pdf
