をしようと思ったのですの。

前に書いたように、ラムダというか匿名関数自体は使えるし、それを投げることも出来るのですの。なのでいけるかなと思ったのですの。

でも、クラスメソッドとして書いた関数は、匿名関数のように投げ回すことが出来ないようなのですの。ふべん。

代わりにこう↓かけたらいいなと、

class Foo{
 $bar = function (){
  return ~~~;
 };
}

思ったのですけどダメで、、

PHP:プロパティ
http://php.net/manual/ja/language.oop5.properties.php
宣言時に初期値を設定することもできますが、初期値は定数値でなければなりません。
ということで、
こう↓するしかないみたいですの。

class Foo{
 public $bar;
 function __construct(){
  $bar =  function (){
   return ~~~;
  };
 }
}

でもこの方法だと、関数をたくさん並べたときに宣言と定義の位置が離れて見づらくなるので嫌なのですの、、

なんとか良い感じに書ける方法があればいいのですけど、、


--2018/12/24 追記
メンバ変数の宣言時に関数を代入出来ないのなら、メンバ変数の宣言をコンストラクタ内に持ってくればいいじゃないですの!

class Foo{
 function __construct(){
  $this->bar = function (){
   return ~~~;
  };
 }
}

一応これは成功しましたの。さすがPHPですの。
ただ、ここでもう一つ問題がわかって。メンバ変数に関数を入れた場合、それを呼び出すときに普通のクラスメソッドのようには呼び出せないそうなのですの。

【PHP】プロパティに格納されたクロージャを呼び出す方法まとめ
https://qiita.com/rhap/items/1701247844772c3c92f0

なぜそんな意地悪を。。

ということで、ここで心が折れましたの。
自由に投げられるクラスメソッドが欲しくて調べはじめたので、普通のクラスメソッドとして扱えなくなってしまうようだと厳しいですの。

しかも、一番簡単そうな「括弧でくくる」方法は、PHP5.4では使えないようですの。いったんローカル変数に入れて呼び出す方法なら出来たのですけど、これはちょっと嫌ですの。

↓これはNGで
    /*
     * @dataProvider forNantoka
     */

↓これだと動くみたいですの
    /**
     * @dataProvider forNantoka
     */

上段のアスタリスクに注目ですの。

/*~*/は通常のブロックコメントで、
/**~*/はドキュメンテーションブロックという、アノテーションを書くための特殊なブロックだそうですの。

@dataProvider もアノテーションの一つなので、ドキュメンテーションブロックで書かないと動かないということですの。


PHPUnit data provider error
https://stackoverflow.com/questions/14426208/phpunit-data-provider-error

2. アノテーション
https://phpunit.readthedocs.io/ja/latest/annotations.html

2日ほど頭を抱えていたのがやっと動いたのでメモですの。

Windows環境
NetBeans8.2(PHP用)
XAMPP1.8.2(PHP5.4.31)

・ツール>オプション>一般 の設定
 PHP5インタプリタ
  xampp/php/php.exe

・ツール>オプション>フレームワークおよびツール>PHPUnit の設定
 PHPUnitスクリプト
  xampp/php/phpunit.bat

 スケルトン・ジェネレータ・スクリプト
  DLしたpharファイルをおいた場所を指定(たぶんどこでも良い)

・プロジェクト・プロパティ(プロジェクトを右クリック>プロパティ) の設定
 テスト>PHPUnit
  ブートストラップの使用 にチェックを入れ、「生成」ボタンを押す

・xDebugの設定(コードカバレッジを取るのに必要)
 xamppのphp.iniの最後のほうの[XDebug]の欄のコメントアウトをすべて外して、xamppのapacheを再起動する

入管法改正案、衆院を通過
https://www.sankei.com/politics/news/181127/plt1811270039-n1.html

次から次へと、悪法ばかりよくも思いつくものですの。

とりあえず、ヤフコメで見かけた擁護意見への反論を書いておきますの。

・介護や土建など、きつい仕事に日本人が就きたがらないから仕方がない
→就業したくなるまで待遇を改善するのが先
 それでやっていけないような企業は淘汰されたほうがよい。介護など福祉についても、料金そのものを抑えるのではなく、料金の値上げを社会保障で吸収する形にするのがよい。日本人にしろ外国人にしろ、誰かを奴隷にさえすれば済むという発想はもうやめよう。

・高度な技能を持つ人材限定だから、一般の労働者に影響はない
→うそ
 仮に優秀な人材だけを100人いれたとして、その100人がいなければその職に付けたはずの100人があぶれて下層に落ちる。すると、下層でも100人が職にあぶれて、さらに下の層に落ちる。この連鎖が、最下層で100人が職にあぶれるまで続く。いれた人材が優秀であればあるほど、かえって全体に与える負の影響は大きくなる。

と書くと、対案は?と言い出す人が多いようなので、いちおう書いておくと、対案はこの改正案の廃止ですの。

なんというか、労働者から見てようやく売り手市場になって、さあこれから賃金が上がっていくぞというときに、どうして? という気分ですの。経団連の人たちはみんな、正当な賃金を払ったら死んじゃう病気にでもかかっているのかしら?

持っている本のタイトル(ピンク)、著者名、著者紹介 ですの。

とくに流れを感じられるようなリストにはなっていないのですけど、ソフトウェア見積もりとCodeCompleteの著者が同じだったのは驚きましたの。どちらも良書で、とくにCodeCompleteは最高の一冊なので、さすがという感じですの。 


Clean Architecture 達人に学ぶソフトウェアの構造と設計
Robert C. Martin/ロバート・セシル・マーティン(1952~)
コンサルティング会社を経営(Uncle Bob Consulting LLC. と、Clean Coders)
アジャイルソフトウェア開発宣言の共著者、FitNesseの作者
愛称:ボブおじさん 
SOLID原則をまとめた。Clean Architectureの提唱者

ソフトウェア見積り 人月の暗黙知を解き明かす
Code Complete 第2版 完全なプログラミングを目指して
Steve McConnell/スティーブ マコネル(1962~)
ソフトウェア工学教科書の著者
ソフトウェアエンジニアリングとプロジェクト管理の専門家
他に有名らしい本:ラピッドデベロップメント―効率的な開発を目指して

熊とワルツを リスクを愉しむプロジェクト管理
Tom DeMarco/トム デマルコ(1940~)
70年代の構造化分析と構造化された設計の開発における主要人物の1人
有名な本:構造化分析とシステム仕様

ソフトウェアテスト293の鉄則
Cem Kaner/セム ケイナー
フロリダ工科大学のソフトウェア工学教授
ソフトウェアテスティング協会(AST)を設立
消費者保護擁護者としての立法業務(統一コンピュータ情報取引法、統一電子取引法の草案への参加など)を行った。

ユースケース駆動開発実践ガイド
Doug Rosenberg/ダグ・ローゼンバーグ
Iconixプロセスの提唱者。XPの最も激しい反対者の1人
(↑の本もIconixの本らしい)

レガシーコード改善ガイド
Michael C. Feathers/マイケル・C・フェザーズ
Object Mentor社勤務(コンサルティング系の会社?)
CppUnit、FitCPPのオリジナル開発者 


レガシーソフトウェア改善ガイド
Chris Birchall/クリス・バーチャル
広範なプロジェクトを経験後、ロンドンのガーディアン紙で、
シニアデベロッパとしてWebサイトのバックエンドサービスを担当

最近読んでいるClean Architectureの著者のRobert C. Martinさんが、Wikiを使ったテストツール FitNesseの作者さんでしたの。びっくり。FitNesseは以前、テストについて調べていたときに見つけて面白いなーと思ったツールだったのですの。

ソフトウェアの世界の有名人なのだから、なにかすごいソフトを作っていても驚くことではないはずなのですけど、いざ遭遇すると破壊力が高いですの。

そういえば、Winnyで有名な(?)金子勇さんを初めて知ったのは、NekoFightの作者さんとしてでしたの。

NekoFight
http://kaneko-isamu.la.coocan.jp/nfight.htm 

あんまり話題になった記憶のないソフトなのですけど、実際、とんでもない作品で。初めてみたとき、世間知らずなわらわは「ネットの世の中にはこんなものを作れる人がごろごろいるのかー」と、ショックを受けた作品でもありますの。

10年くらい前、AIを作ろうとして、3層ニューラルネット+バックプロパゲーションを勉強していて、難しすぎてぜんぜんわからなくて困っていたわらわの目に飛び込んできたのが、この文章でしたの。
 AIの方式は単なる3層ニューラルネットで、学習アルゴリズムは私独自のED法(誤差拡散法)です。
ED法は、バックプロパゲーションが実際の神経系のメカニズムとしてはありえないというのが気になって私の方で考え出した学習アルゴリズムですが、 学習速度が非常に速いのと、中間層を増やせば無制限に性能が上がるのが特徴のアルゴリズムです。私の方では、おそらく本物の脳みそ(前頭前野大脳皮質)も こんな学習アルゴリズムなんじゃないかと思ってますがもちろん確証は無し(笑)
ものすごく苦労しても理解できないものを、あっさり(?)超えていってしまう。こんな人がその辺にいるなら、わらわがやってもしょうがないのでは?と思ったものですの。

あとで経歴を知ってびっくり。ぜんぜんその辺にいないレベルの人でしたの。(原子力研究所で働いて、未踏ソフトウェアに参加して、東大大学院で教えてた人)

NekoFightは、そのうち注目されて解説でも出回らないかなと思ってずっと見ていたので、まさかの訃報に別の意味でもショックを受け。。

なんだかうまくまとまらない文章になってしまったのですけど、話を戻すと、技術書の内容自体ではなく、”人”について調べてみるのも面白いかなと思ったのですの。

それまで自動テストを導入していない状態から、いきなりフルセットのテスト項目を想定してテスト駆動開発をはじめるのは大変で当然だと思いますの。

そこで思ったのは、次のようなステップで進めていけば始めやすいのでは?ということですの。
  1. 要求を実現するための、シンプルなテスト項目だけで開発を進める
  2. たいてい訪れる「実装中にうまくいかなくなって動作を検証したくなるとき」が来たら、その内容をテスト項目として追加していく
  3. あらかた形が出来てきたら、テスト項目を増やしてフルセットに近づけていく
おそらく、いきなり網羅的なテストとか、異常テストとかを盛り込んで始めるのは、慣れた人でないと難しいのではと思うのですの。

というか、実装前にクラス/メソッドレベルで完璧に設計が出来ているというのは非現実的なので、実装しながら問題点に気づいてあれこれ変えて形を作っていくことを考えると、こういう感じでないとロスが大きいと思うのですの。

ただ、試してみたわけではないので、いまのところ空論ですの。
これまでの議論から必然的に導けるのは、コンポーネントの構造をトップダウンで設計するのは不可能だということだ。コンポーネントの構造は、システム 設計の際に検討するだけのものではなく、その後もどんどん変わっていく。
Clean Architecture 達人に学ぶソフトウェアの構造と設計
第14章>トップダウンの設計 より

アジャイルで開発する場合、テストその他の自動化は推奨ではなく必須だそうですの。
であれば、どんな言語を使うか選ぶ際も、その言語に対応した自動化ツールがどのくらいあって、どういう使い勝手なのか、うまく連携は出来るのか、といったことが、言語そのものの良し悪しと同じくらい大切になってくるのかなと思いましたの。

自動採番されるIdの値を綺麗に取得する方法ですの。

(例)
var entity = new Entity();
context.Add(entity);
context.SaveChanges();
int n = entity.Id;

SaveChanges()した時点でentity.Idが書き換えられて、自動採番された新しい行の数値が入るので、それをそのまま取得することが出来ますの。

参考
[C#-ADO.NET] Entity Framework で IDENTITY 列を持ったテーブルに行を挿入した時の IDENTITY 列の値の取得
https://code.msdn.microsoft.com/DataAccess-howto-383a3202

はじめ全然わからなくて、1日はまりましたの。
「entity framework SCOPE_IDENTITY()」で検索したらあっさり上のページが見つかったので、検索も発想力が大事だと思ったのですの。その前に地力があれば良いのかもですけど。

自動マイグレーションが出来ないということは、 手動でする必要があるということですの。

やり方は、パッケージマネージャーコンソールで、
Add-Migration piyo
して、
Update-Database
すれば大丈夫ですの。

ちょっとめんどうなのは、(現在のバージョンでは)piyoの部分は毎回変える必要があるということですの。変更ごとに記録を作っていく感じですの。

↓過去のバージョンでは、-Force オプションで上書き保存が出来たようですの。
EF Migrations Command Reference
https://coding.abel.nu/2012/03/ef-migrations-command-reference/ 

↓現在のバージョンのオプション
EF コア パッケージ マネージャー コンソール ツール
https://docs.microsoft.com/ja-jp/ef/core/miscellaneous/cli/powershell

開発中に何度もモデルを変更して、大量にマイグレーションファイルが出来てしまうのは嫌なので、なにか方法があればと思ったのですけど。自動マイグレーションの削除といい、柔軟さ・開発速度の追求よりは、やや堅い方向に進んでいるのかなと言う気がしますの。


参考

EntityFrameworkのMigrationを試してみる 
https://cfm-art.sakura.ne.jp/sys/archives/307

EF Core automatic migration
http://weblog.afsharm.com/2017/09/ef-core-automatic-migration/

Entity Framework Core 2.0 以降では、自動マイグレーションの機能は削除されていて、今後も追加される予定はないそうですの。

自動マイグレーションやってみたかったのですけど、出来ないんじゃしかたないですの。

一つのビューで複数のモデルを扱う方法について。
結局、専用クラスを作るのが一番簡単なようですの。部分ビューを使う方法もあるそうなのですけど、これはよくわからなかったですの。

本当はTupleが使えればよかったのですけど、残念ながら、@model~の型定義はTupleに対応していないそうですの。(将来対応する予定?)


@model does not support the C# syntax for tuple #1592
https://github.com/aspnet/Razor/issues/1592

図書館<本棚<本 という構造を、Controllerから渡してViewで処理をする場合。

Viewでは以下のようにしますの。

@model IEnumerable<プロジェクト名.Models.図書館>
@foreach (var 本棚 in Model.本棚s){
    @foreach (var 本 in 本棚.本s){
         @Html.DisplayFor(x => x.書名)
    }
}

※Controllerから送られた情報は、Modelというオブジェクトに入っている決まりで、「@model~」は、そのオブジェクトの型の指定ですの。(*1)


Controllerのほうでは、以下のようにしますの。

public async Task Index(){
    return View(await _context.図書館
        .Include(x => x.本棚)
        .ThenInclude(x => x.本)
        .ToListAsync());
}


ここで少しわかりにくいのが.Include()で、これは「関連オブジェクトの内容も一緒に読み込むための指定」ですの。逆に言うと、これをしないとViewで本棚sの内容を見ようとしたときにnull例外が出ますの。(*2)

同様に、.ThenInclude()は「関連オブジェクトの関連オブジェクトの内容も一緒に読み込むための指定」ですの。例では孫オブジェクトの指定に使っているけれども、ひ孫オブジェクトの指定でも同様に繋げていけばいいはずですの。たぶん。

ちなみに、.ThenInclude()での指定時は、VisualStudioのバージョンによっては、正しく指定していても構文エラーの表示がされることがあり、その場合は無視して良いそうですの。

VS2017で試したところでは、エラーにはならなかったけどコード補完は上手く効いていないようでしたの(=「x.」まで打っても候補に「本」が出てこなかったですの)。

参考

UWPでEntity Framework OneToMany
http://blog.okazuki.jp/entry/2016/03/12/093957

関連データの読み込み
https://docs.microsoft.com/ja-jp/ef/core/querying/related-data


*1) ただの型指定なので、「@model~」の記載自体で情報を受け取っているわけでは(たぶん)無いですの。

*2) 本棚sがnullなのか、本棚の内容がnullだったのかは未調査ですの。ただ、foreachで回そうとしたときに落ちたので、たぶん、本棚sごとnullになるのだと思いますの。

ASP.NET Core でMVCしようとするとお世話になるのが、Entity Frameworkですの。
2007年に、.NET framework 3.5で標準ライブラリに組み込まれたということで、思ったよりも古いもののようですの。

1つのPOCO(Plain Old CLR Object)なクラスで、1つのエンティティ(テーブル的なもの)を表現しますの。

POCOなエンティティクラスは、以下のように
public class Hondana {
    public int Id {get; set;}
    public string Code {get; Set;}
}
シンプルな形で定義しますの。(プロパティの定義はたぶん必要?)

本棚テーブルに対して、そこに入る本テーブルを作って使いたいような場合は、ちょっと謎だったのですけど、以下で大丈夫ですの。

他のエンティティを配下に持ちたい場合(1対nで繋げたい場合)、
public virtual ICollection Hon {get; Set;}
のように、相手の情報をコレクションで持って、

相手方には、自分の情報を持たせますの。
public virtual Hondana Hondana {get; set;}

お互いにコレクションで持ち合うと、n対nの関係が作れますの。


参考

連載:Entity Framework 4.1入門
第2回 EF 4.1の規約とデータベースの初期化方法
http://www.atmarkit.co.jp/fdotnet/ef4basic/ef4codefirst02/ef4codefirst02_01.html

public void なにか言う(string s, Action say) => say(s);
public void 言う(string s) => print(s);

public void ぴよって言う()=> なにか言う("ぴよ", 言う);

ぴよって言う()の中身の通り、なにか言う()は出力用の関数を外部からもらう形になっているので、言う()では無い関数を渡すことで、出力先や方法などを容易に変えることが出来ますの。(例えば、ファイルに出力するなど)

ちなみに、値を返さない関数の型はAction、返すものはFuncと書くそうですの。ここではActionを使う例のみ。

名前も微妙に長いしなぜわけたのですの。ぜんぶ、F<>でよかったような。

Actionの場合はまだいいけれど、Funcで「関数を返す関数」を返す、をやりはじめると定義が長くなりがちなので、なるべく短く書ける記法を用意しておいて欲しかったですの。

(あとで思ったけど、たしかにFuncだけだと値を返さない場合を表現しきれないので、わけるのはしょうがなかったのかもですの)

PHP 5.3 のラムダとクロージャーを活用する
https://www.ibm.com/developerworks/jp/opensource/library/os-php-lambda/index.html
$horse = function() {return "with no name";};
print $horse();
いわゆるラムダ式っぽいものは使えないものの、PHP5.3からはこのように無名関数を定義することができ、これがPHPでのラムダということになるそうですの。

また、 PHP4.0の時点でも
$horse = create_function('', 'return "with no name";');
という、どうしようもない記法も存在していたそうですの。ただ、これは本当にどうしようも無さすぎて使う気にはなれないですの。。

ちなみに、古い古いと言われるCentOSのYum標準リポジトリでも、CentOS6の時点でPHP5.3.3が入っているそうなので、上の無名関数の記法はどこででも使えると思って良さそうですの。(CentOS5とかを除けば、、)

ちょっとやる気でましたの。

書こうとして数日、手が止まってしまいましたの。
PHPという言語への興味の惹かれなさが浮き彫りに…という感じですの。

使うシーンは多いので、一度、改めて整理してみることに価値はあると思うのですけど、手が動かないですの。

関数型発祥らしく、計算や判定の類は書きやすく、逆に、副作用が中心になる、手続き型を強制されるような部分は(単体では)書きにくいか書けないという感じだと思いますの。

基本的に大抵のことは出来て、別関数でお膳立てしてあげれば何でも出来る、という印象ですの。(お膳立てしすぎると、最悪、ラムダ式の部分がただのラッパーになるというのはあるにしろ、、)


また、C#7からは、式中で変数の宣言が出来るようになったそうで、逆に言えば、C#6ではそれが出来ないですの。

でも、単に変数を加工していく感じを真似るだけなら、selectでメソッドチェーンしていく構造にする手も。あまり意味はないかも知れないけれど。

例えば、引数で数値をもらって、それを要素1つのIEnumerableに変換してselectを繰り返して、最後に数値に戻して返す。

public int getPiyo(int x) => Enumerable.Repeat(x, 1).Select(c => c * 2).Select(c => c / 2).First();

意味があるかはともかく、一応出来るようですの。

ちなみに、この例のような数値計算なら
public int getPiyo(int x) => x * 2 / 2;
と書くのが圧倒的に素直ですの。

+ 日本語コーディングしようぜ
http://www.flat7th.org/~keizo/wiki/code2/KyDml6XmnKzoqp7jgrPjg7zjg4fjgqPjg7PjgrDjgZfjgojjgYbjgZw

日本語コーディング、そういうのもあるのかですの。

大会かなにかで賞金が成績によって決まるものがあったとして、
参加者が10人未満なら成績の合計、10人以上なら成績の平均の10倍が賞金になるとき、それを求めるクラスメソッド、

public int getBonus(IEnumerable scores)
{
 if (scores.Count() < 10)
 {
  return scores.Sum();
 }
 else
 {
  return (int)scores.Average() * 10;
 }
}

これを、ラムダ式と日本語コーディングにおまけで三項演算を加えて書くと以下ですの。

(一行版)
public int get賞金(IEnumerable 成績s) => 成績s.Count() < 10 ? 成績s.Sum() : (int)成績s.Average() * 10;

(改行を入れた版)
public int get賞金(IEnumerable 成績s) => 
成績s.Count() < 10
? 成績s.Sum()
: (int)成績s.Average() * 10;

量的に少ないせいか、思ったより迫力がないですの。むしろ最初のコードより短くて見やすい気もしますの。
ただ、わらわがC#の標準の中括弧の付け方(BSD/オールマン・スタイル)が嫌いなこともあって、そもそも中括弧を使わないで済むというのはとても爽快ですの。

使いそうなLinq関数

Select(式)(シーケンスを加工する)
Where(式)(条件を満たす要素を取得)
First()(先頭の要素を取得)
All(式)(すべての要素が条件を満たすか)
Any(式)(条件を満たす要素が1つでもあるか)
ToArray()(配列に変換)
Constains(値)(条件に一致する要素があるか)
ElementAt(値)(指定番目の要素を取得)

クラスメソッドとして書く場合は、
public int a(int n) => n + 1;
のような短文形式のみ可能で、
public int a(int n) => {(略); return n};
のようなブロックで囲う複文形式は許可されないですの。

同様に、if文は使えない…けれど、三項演算子は使えるようですの。
public int a(int n) => n == 1 ? 1 : 0;


式形式のメンバー (C# プログラミング ガイド)
https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/statements-expressions-operators/expression-bodied-members
式本体の定義のサポートは、メソッドとプロパティの get アクセサーのために C# 6 で導入され、C# 7.0 で拡張されました。 
とあるように、基本的には簡単な(?)getアクセサ用にあるようですの。

Unity 2018.1 リリース
https://blogs.unity3d.com/jp/2018/05/02/2018-1-is-now-available/
スクリプトのアップグレード .NET 4.x
新しいスクリプティングランタイムは Unity 2018.1 では試作版ではなくなり、安定スクリプティングランタイムの初回プレビュー版となります。
(中略)
例えば、C# 6 と新しい .NET API によって、Unity にモダンな .NET ライブラリやツールとの互換性がもたらされます。

MonoDevelop の廃止
Unityに依存している限り、言語の最新バージョンを常に使えないのは苦しいけれども、これでひとまずC#6までは安心して使えるようになったようですの。

わらわはMonoDevelop好きだったので、廃止は残念ですの。

ろくなプログラムを書いていないせいか、
ろくにプログラムを書いていないせいか、
最近、プログラミング能力が上がるどころか地に落ちている気がしますの。

関数型言語の美しさに触れてからというもの、オブジェクト指向の醜い部分が気になってしかたがなく。オブジェクト指向を捨てたはいいものの、関数型を実用できるほどの力も環境もなく。

いっとき、C#のLinqに賭けたものの、期待したほどの力はLinqには無く。

今はただ、PHPあたりでゴミクズのようなコードを書くばかり。

プログラミング自体もまあ好きだったけれど、やっぱりその前に、プログラミングで好きなものを作るのが好きだったのかな、と、素朴に思うのですの。いまごろになって。

どうでもいいものを、どうでもいい感じで作りすぎたせいなのか、好きなものをプログラミングすることさえちょっと抵抗感を感じてしまう今日このごろですの。

新しいことを学ぶこと自体が嫌になったわけではないのですけど、IT関係で新しいことを学ぶ意欲は激減していますの。いろんな技術書を見ても、わくわくするどころか、ふーんそれで?ってなってしまいますの。

よくIT辞めた人が農業にいくのわかるきがしますの。食べ物にはわかりやすく価値があるけれど、ITはわかりやすい価値からもっとも遠い。わらわは頭が悪いので、その価値がわからなくなってきましたの。

わくわくが欲しい。さもなければ、お金が欲しいものですの。

省庁データ、近く西暦で統一…来春は間に合わず
https://headlines.yahoo.co.jp/hl?a=20180520-00050149-yom-pol


良いことだと思いますの。でも、書類などに出力するときは今まで通り和暦で出すらしくて、口惜しい感じですの。いっそ全て西暦にしてしまえばいいのにですの。

そもそも和暦がなぜ必要なのか。いまだに、わらわは西暦→和暦の変換を暗算では出来ないですの。ものすごくたまにしか使わないからですの。

ときどき、なぜわざわざキリスト教の暦を使わなければならないのかと言う人がいるのですけど、それは改元がないからですの。改元さえ無いのなら和暦でもいいけれど、それがある以上、和暦は使用に適さないですの。

もしどうしても和暦を使いたいのなら、改元を捨てるしか無いですの。つまり、今からでも「平成からは改元なし」とするのですの。そうして平成500年、平成2500年…となっていくのなら、まだ許容範囲ですの。過去については西暦と併用するとしても。

一方で、もし文化的な意味で、和暦を今まで通りの形で「残したい」のなら、実用に使うことは辞めたほうがいいですの。実用に使う道具は必ず、使う人の要望で変わっていくものですの。

国家施設の飾りや、国家イベントの旗にだけ書かれるような、そういう非日常で非実用な、象徴的な存在になればいいと思いますの。和暦の基準になっている天皇がそうであるように。


…と思ったとき、ふと、
天皇の状態変化が、使用を義務付けられている暦にクリティカルな変化を及ぼすという構造は、天皇は象徴でなければいけないという制約からやや逸脱するのでは?と思ったのですの。

そしたら、公文書での和暦の使用は特に法令などで義務付けられているものではなく、ただの慣習らしいですの。なるほど、ならセーフだと思いますの。頑なに和暦だから義務なのかと思ってたですの。

しかしそれなら、なおのこと西暦に統一するか、せめて記入欄に西暦も印刷してどちらで書いても良いようにしておいて欲しいものですの。どうせもう中身は西暦になるのだし。

FireFoxのソース画面では、<!要素>という書き方は怒られてしまいますの。
タコって。

タコなコメントとは言うものの、コメントとしては機能していないようですの。たぶん無効なタグ扱いですの。

ソースはこの辺のようですの。(FireFoxの開発or翻訳リポジトリっぽい)
https://hg.mozilla.org/l10n-central/ja/file/default/dom/chrome/layout/htmlparser.properties

ここによれば、他にも「タコな文書型宣言が見つかりました」もあるようですの。

↓遭遇した方のブログ

タコな文書型宣言(爆笑)
https://blogs.yahoo.co.jp/katsutoshi_maita/31904592.html