| 6708 |
雨が降っている |
はくぶん |
2015-07-01 04:20:28 |
昨日は夕方からずっと一晩中雨だった。
こんなに降ったのは久し振りじゃないかな。
ちっとも嬉しくはないのだが、まあ梅雨だから仕方ない。
そして、まだまだ止む気配がない。
天気予報によると、午前中一杯は降るみたいだ。
梅雨の中で最も嫌いな梅雨の日。
それがこんな天気の日である。
雨が降るにしても、夜に降って、朝には上がってくれていれば、梅雨といえども何も嫌いではない。
問題は昼間に雨が降ることなのである。
日本の梅雨は一日中雨が降り続く天気である。
最近はそうでもなくなって来たが、それでも夜中に降って、朝に上がっていることは少ない。
だから梅雨は無くなって欲しいのである。
しかし、気候が亜熱帯になっても、梅雨は相変わらず存在したまま。
梅雨って国の寄生虫だったのか？
|
| メッセージ文字数：322／335 |
| |
| 6707 |
デフォルト文字セットの意義 |
はくぶん |
2015-06-30 09:03:05 |
実験では一切化けてはおらず、やはり文字セットが単なるデフォルト値でしかないことが分かった。
デフォルトの文字セットがどうなっていようと、文字を格納すれば、その文字コードも格納され、その文字コードで出力すれば、一切化けることなく表示される。
単にそれだけのことなのだろう。
それなら何のためのデフォルト値なのだろうか。
普通、文字には必ず文字コードが付随する。
文字コードのない文字など存在しないため、テーブルに文字が格納される際、必ず文字コード情報も一緒に格納される。
つまりデフォルト値など不要なはずである。
それとも、テーブルには文字は格納されるが、文字コードは格納されないのだろうか。
常にデフォルトの文字セットで格納される、ということなのだろうか。
もしそうなら、デフォルトとは違う文字コードで表示しているこの掲示板の文字が化けないはずがない。
途中で文字コードを変換しているわけではないのだから。
この部分をネットで調べてみたが、何も見つけることは出来なかった。
テーブルのデフォルト文字セットが、実際に格納される文字の文字コードと異なる場合、どこにその影響が出て来るのか、または一切出ないのか。
今後も継続的に調べてみる必要があるだろう。
|
| メッセージ文字数：512／528 |
| |
| 6706 |
文字セット |
はくぶん |
2015-06-29 10:45:40 |
テーブルの文字セットなんて果たして意味があるのか？
そう思わせるような現象に遭遇した。
いや、開設当初から疑問に思っていたことではあるが、特に何も支障はないので、そのまま放っておいた。
たまたま何の気なしに文字セットを変えてみたが、特に無いも変わったところはない。
普通、文字セットを変更すれば、文字化けが起こりそうなのだが、一文字たりとも化けてはいない。
じゃあ、投稿は大丈夫なのか、ということで、これからその実験。
上手く行ったら、この投稿も化けずに表示される。
上手く行かなかったら、暫く化けたままの表示が続く。
今までの投稿が化けないんだから、この投稿も化けるはずがないのだが、そこは理屈の通らぬコンピュータの世界。
何かの拍子に化けることだってあり得る。
何かの拍子に何回も化けることもあるし、一度だけ化けることもある。
とにかく試してみようと思う。
|
| メッセージ文字数：369／382 |
| |
| 6705 |
ヨイショの国 |
はくぶん |
2015-06-29 08:19:12 |
どの世界にもヨイショする奴はいるね。
醜態晒してるって事が分からないのだろう。
周囲の人間もヨイショマンだらけ。
ヨイショが当り前になっている禄でもない国、日本。
そこまで自分を偽って、人の気に入られたいかね。
自分を信じる事が出来ない人間達。
だから、他人の評価が自分の全て。
ヨイショするしか道は残されてないよな。
日本中の至る所で、今日もヨイショの始まり始まり！
馬鹿馬鹿しい。
|
| メッセージ文字数：183／194 |
| |
| 6704 |
今日も腹を立てずに済んだ |
はくぶん |
2015-06-28 11:02:24 |
絶対に失敗のない考え方があるという話は、以前にしたことがあると思う。
上手く行かない事があったとしたら、それは神様が“止めろ”とか“するな”とか言っているのだ、と。
その事柄が、相手が、方向が、お前に合わないから、軌道修正させようとしたのだ、と。
この考え方は、非常に前向きだ。
普通なら怒ったり、恨んだり、自棄になったりする場面でも、この考え方をすると、その状況が正解になってしまう。
何より人前で醜態を晒さずに済む。
今日、この考え方で、また一つ腹を立てずに済んだ。
いや、多少腹は立っていたが、それに支配されずに済んだ。
色々有益な言葉はあるが、これほど容易に実行でき、即効性があるものも珍しい。
さあ、今日は代わりに何か、神様が俺にプレゼントしてくれるのだろう。
|
| メッセージ文字数：326／338 |
| |
| 6703 |
返答なし |
はくぶん |
2015-06-28 09:30:22 |
使いたくない気持ちは分からんでもない。
自分の所有物だと思っているのだろう。
確かに最も時間と労力を使って、完成に近づける努力をしたことは認める。
それにより、より一層愛着も湧いたことだろう。
あれ以来、何の返答もない。
何か否定的な意見を俺に返せば、俺に詰め寄られても反論できないことがよく分かっているのだろう。
このまま立ち消えになるのを待っていることなど、先刻お見通しである。
あの時の俺への対応。
それまでおぼろげだった事が明確になった瞬間だった。
しかし、それは個人情報の塊なのである。
誰かが私物として所有していてはいけないものなのである。
それに対して、こう反論するかもしれない。
ネット上の閉ざされた空間で、メンバーにだけは公開している、と。
管理しているだけで、所有しているわけではない、と。
自分が管理することを、誰も否定してはいない、と。
確かにそうだ。
それなら、なぜ俺の提案に前向きではないのだ。
もっと楽に管理できるシステムを、なぜ受け入れようとしないのか。
システムに不備がないことなど、既に試して分かっているはずだ。
一つだけ現状と変わる点があるとすれば、それはメンバー皆で共同管理になるという事だけなのだが。
|
| メッセージ文字数：502／525 |
| |
| 6702 |
自然の摂理に対する反逆 |
はくぶん |
2015-06-27 07:42:40 |
アメリカの最高裁判所で、同性同士の婚姻が正式に認められたらしい。
これにより、同性婚を禁じる州は、その事自体が違憲となる。
同性同士が結婚。
最高裁判所がそれにお墨付きを与える。
アメリカは何でもやってくれるね。
とてもキリスト教国とは思えない。
しかし、少なくとも日本は、これを見習わないで貰いたい。
自然の摂理に対する反逆。
イエス・キリストの前で、この事実を堂々と述べることが出来るのだろうか。
|
| メッセージ文字数：192／202 |
| |
| 6701 |
梅雨の雨間 |
はくぶん |
2015-06-26 06:05:26 |
外は雨が降っている。
梅雨に入ったとは言え、それほど雨の降らない毎日に、今年の梅雨は空梅雨かなどと期待していたが、どうやら偶々だったようだ。
今日は雨時々曇り、ということは殆ど一日雨だということだな。
降水確率もそれを端的に物語っている。
俺にとって一番嫌いな梅雨の天気。
それが今日のような天気だ。
|
| メッセージ文字数：145／150 |
| |
| 6700 |
日常使うデータ |
はくぶん |
2015-06-25 01:34:33 |
日常使うもので、SQLに入れておくと便利なものは何だろうかと考えた。
色々あるように思えるが、わざわざSQLに入れておく必要のあるものなど無いような気がする。
数が多いという観点では、郵便番号が該当する。
実際に使われているのは約14万番号とのこと。
確かに14万もあればSQLに入れておいてもいいかなとは思う。
ただ、それほど使う機会があるのかどうかは疑問だが。
現在の郵便番号は7桁で1000万通りの番号が作れるらしい。
確かに0から9までの10個の数字を、7桁に配置すれば、10＾7＝1000万である。
もちろん、その中には000-0000や999-9999などのような極端な場合も含まれる。
しかし、上述の通り、使われているのは14万通り。
1.4％の使用率。
高々人口1億数千万人しかいない日本人の住所を指し示すのに、1000万通りの受け皿が必要だったのだろうか。
有効利用として7割は超えて欲しいところだ。
単純に47都道府県で割ると、1000万÷47≒21万。
1都道府県あたり、それの7割、つまり14.7万個の郵便番号を使って初めて有効利用と言える。
日本全体で考えると、1億数千万の人口に対して1000万の郵便番号ということは、10数人に対して1つの割り振りということになる。
1世帯4人家族なら、3〜4世帯に対して1つの割り振りという計算だ。
その7割で有効活用と見なしたとしても、4〜5世帯に1つの割り振りになる。
結局7桁も要らなかったんだよな。
世界のIPアドレスは枯渇寸前だが、日本の郵便番号は空きだらけ。
非常に対照的だ。
14万の郵便番号。
SQLに入れておいて、果たして使う機会があるのだろうか。
あるとしても、郵便番号から住所、住所から郵便番号、その二つの検索くらいだろう。
年にそう何回も使わないとなると、わざわざSQLに入れるよりも、テキストファイルで持っていてもいいような気がする。
いちいち開いて見るには容量的に大きいが、スクリプト経由で読み込めば、それほど容量も時間も掛からないだろう。
なんかそんな風に思えて来た。
それなら、日常使うデータで、わざわざSQLに入れてでも、というデータは果たしてあるのだろうか。
|
| メッセージ文字数：902／932 |
| |
| 6699 |
晴れ時々曇り？ |
はくぶん |
2015-06-24 07:23:40 |
今日の天気は“晴れ時々曇り”なんだそうだが、今の空を見ると、晴れているという様子ではない。
むしろ曇り空。
“曇り時々晴れ”の間違いではないのか、という疑問さえ浮かぶほどである。
さて、遅々として進まない活動であるが、昨夜ちょっと進展があった。
まあ、これからだろう。
いきなりドバッとやってしまうと、途中で息切れする。
それは昔からの俺の悪い癖。
最後に上手く行くことが大事なのだ。
|
| メッセージ文字数：185／194 |
| |
| 6698 |
二つの発見 |
はくぶん |
2015-06-23 02:16:48 |
昨夜はいくつか新しい事を発見した一夜だった。
1)SQLのDSNにオプション設定項目
前々からあることは知っていたが、何に使うのかわからなかったので、設定した事がなかった。
昨夜、CGI側ではなくSQL側でUTFフラグをONに出来ること知り、俄然このDSNに興味が湧いた。
DSNのオプション項目に“mysql_enable_utf8”と記述すればいいらしい。
現在のスクリプトは、すべてCGI側でUTFフラグをONにしている。
今からすべてのDSN文を変更するのは面倒だし、エラーが誘発される恐れもあるので、次回何かを作る時から、SQL側でUTFフラグをONにするようにしよう。
2)UTFフラグをONにする
SQLから読み出したデータは、そのままだとUTFフラグがOFFのままだから、decodeしてUTFフラグをONにする必要がある。
SQLから読み出すデータは、配列になっていることが多いので、最近は配列のリファレンスで受け取るようにしている。
以前は配列で受け取っていたが、どこかのQ＆Aサイトを見たとき、皆配列のリファレンスで受け、誰も配列で受け取っている人がいなかったので、そういうものなのかと思って、それ以降、俺も配列のリファレンスで受け取るようにしている。
配列で受けようと、配列のリファレンスで受けようと、その後にdecodeという作業が来るわけだが、decodeは変数単位（配列なら要素単位）の作業なので、配列を一発ドンでdecode出来ない。
俺はforのループで回して、要素単位でdecodeしていた。
しかし、map関数を使えば、一発ドンでdecode出来ることを知る。
一発ドンと言っても、実際には要素単位でdecodeしているのだが、ループで回すわけではないので、要素を一つずつdecodeしているという印象はない。
今まで4行使って書いていた部分が、1行で済んでしまった。
パフォーマンス的には変わらないのかもしれないが、コードが見た目にシンプルで美しい。
というわけで、昨夜はF1を観戦し、その後、ナショナルジオグラフィーを観ながら、二つの新たな発見を楽しんだのであった。
|
| メッセージ文字数：887／907 |
| |
| 6697 |
覚える事、忘れる事 |
はくぶん |
2015-06-22 05:29:49 |
やっぱり思い付いた事はすぐに書かないと忘れてしまうね。
もちろん若い頃ならいつまででも覚えていたが、年を取るに従って持続時間が短くなる一方。
一番初めに意識したのは28歳の時だったとはっきり記憶している。
ほんのちょっとした事だった。
皆に伝えなきゃいけない事があったのだが、伝え忘れた。
今までそんな事は一度も無かったので、ちょっとした衝撃を受けた。
だからよく覚えているのである。
しかし、忘れるということが決して悪い事ではないと、最近は思うようになって来た。
決して負け惜しみや言い訳で言っているのではない。
歳を取ると忘れなければいけない事が多くなる。
いつまでも覚えていちゃいけない事も増える。
だから忘れる事に長けて来るんだと。
人を恨まないために、悲しみが続かないために、忘れる事を覚えるのだと。
|
| メッセージ文字数：343／355 |
| |
| 6696 |
ある一つの小さなお別れ |
はくぶん |
2015-06-21 20:16:22 |
約9年間、俺の髪を切り続けてくれた兄ちゃんが、自分の店を開くために、今月末でその店を辞めるらしい。
今日、髪を切りに行って、初めて聞かされた。
あと2週間遅かったら、最後の挨拶が出来ないところだった。
普通なら、その日のローテーションで、誰が切るとは決まっていない店らしいのだが、俺の場合は、いつも、その兄ちゃんで、他の人に切ってもらったことがない。
俺の髪を切るのは、かなり勉強になったらしく、かなり感謝された。
来月から赤穂で開業するらしい。
ちょっと髪を切りに行ける距離ではないので、これでお別れになる可能性が高いが、店のブログとフェイスブックを開設すると言っていたので、ネットで見つけたら、ぜひ投稿したいと思う。
想ヘアー。
繁盛することを祈ってます。
|
| メッセージ文字数：322／332 |
| |
| 6695 |
連続投稿終了 |
はくぶん |
2015-06-21 08:16:22 |
一昨年の9月から続いていた連続投稿が、昨日で途切れた。
別にわざと終わらせたわけではない。
知らないうちに今日になってしまっていただけである。
しかし、これで良かったのかもしれない。
書く事もないのに、毎日々々無理矢理何かを書くよりは、何かあった時だけ書くという方が自然だ。
そういう意味でも、連続投稿が途切れて良かったのかもしれない。
ずっと続いていただけに、もったいないと言えばもったいないが、これを機に何かが変わることを期待しよう。
ここで一つ自分に課題が出来た。
連続投稿日数をSQLだけで求めようとしたら、そのSQL構文はどう書けばいいんだろうか。
|
| メッセージ文字数：271／280 |
| |
| 6694 |
梅雨入りしていた |
はくぶん |
2015-06-19 06:49:16 |
そう言えば、梅雨入り宣言を聞かないが、梅雨に入ったのだろうか。
毎日梅雨のような鬱陶しい天気。
時期的に見て、梅雨に入っていたとしても決しておかしくはない。
ちなみに、過去のデータによると、最も早い梅雨入りは1956年と2011年の5月22日頃で、最も遅い梅雨入りは1958年の6月25日頃とのことである。
今年の梅雨入りは一体いつ頃なのか、ちょっと調べてみた。
■ 平成27年の梅雨入り 更新日：平成27年6月11日
| 地方 |
平成27年 |
平年差 |
昨年差 |
平年 |
昨年 |
| 沖縄 |
5月20日ごろ |
11日遅い |
15日遅い |
5月 9日ごろ |
5月 5日ごろ |
| 奄美 |
5月19日ごろ |
8日遅い |
14日遅い |
5月11日ごろ |
5月 5日ごろ |
| 九州南部 |
6月2日ごろ |
2日遅い |
同じ |
5月31日ごろ |
6月 2日ごろ |
| 九州北部 |
6月2日ごろ |
3日早い |
同じ |
6月 5日ごろ |
6月 2日ごろ |
| 四国 |
6月3日ごろ |
2日早い |
1日遅い |
6月 5日ごろ |
6月 2日ごろ |
| 中国 |
6月3日ごろ |
4日早い |
1日遅い |
6月 7日ごろ |
6月 2日ごろ |
| 近畿 |
6月3日ごろ |
4日早い |
同じ |
6月 7日ごろ |
6月 3日ごろ |
| 東海 |
6月8日ごろ |
同じ |
4日遅い |
6月 8日ごろ |
6月 4日ごろ |
| 関東甲信 |
6月8日ごろ |
同じ |
3日遅い |
6月 8日ごろ |
6月 5日ごろ |
| 北陸 |
|
|
|
6月12日ごろ |
6月 5日ごろ |
| 東北南部 |
|
|
|
6月12日ごろ |
6月 5日ごろ |
| 東北北部 |
|
|
|
6月14日ごろ |
6月 6日ごろ |
俺が知らなかっただけで、近畿地方は既に6月3日に梅雨入りしている。
6月11日時点で梅雨に入っていないのは、北陸と東北だけで、他の地方はすべて梅雨に入っていた。
今日はもう6月19日。
ということは、北陸も東北も既に梅雨に入っているだろう。
最近は6月中旬というイメージのある梅雨。
近畿地方の例年は6月7日頃のようだ。
今年は例年に比べて梅雨入りがちょっと早いが、実は昨年もちょっと早かったようだ。
梅雨明けがまだ予想されていないので、いつ頃になるのか正確にはわからないが、恐らく最近の例年通り、7月半ばまでずれ込むことになるのだろう。
遂に俺の一番嫌いな季節がやって来てしまった。
一ヶ月辛抱だな。
|
| メッセージ文字数：1377／3385 |
| |
| 6693 |
あの時と違う |
はくぶん |
2015-06-18 14:08:01 |
2年前はここに来るのが一種の楽しみでもあった。
何回来ただろうか。
10回くらい来たんじゃないだろうか。
全然楽しい場所ではないのだが、何となく落ち着いた気持ちになっていたものだ。
今回、全然楽しみではない。
気持ちが落ち着くなどということもない。
あの時と何も変わっていないが、あの時とは感じ方が違う。
新鮮味がなくなったから？
そうかもしれない。
もしそうなら、あの時は何回も来て、よくずっと同じ気持ちが続いていたものだ。
また同じ事の繰り返しだろうか？
少しは違う展開を希望する。
|
| メッセージ文字数：232／245 |
| |
| 6692 |
明日は雨 |
はくぶん |
2015-06-18 00:52:33 |
天気予報によれば、明日は雨時々止む一日になるようである。
肝心な日に雨が降るとは、俺と大阪との相性をよく表していると言える。
今日は何かが吹っ切れた日でもあった。
別にきっかけがあったわけではない。
自然とそう思えた、といったところだろう。
今まで何かの呪縛に掛かっていて、それが解けた感じだ。
若い頃はそんな呪縛などなかった。
いつ、どんなきっかけで掛かってしまったのだろうか。
情報の洪水の中で、知らない内に掛かってしまったのだろうか。
|
| メッセージ文字数：212／221 |
| |
| 6691 |
マルチテーブルインサート |
はくぶん |
2015-06-17 03:21:43 |
マージテーブル関連を色々調べていると、マルチテーブルインサートという技術を紹介しているサイトに出くわした。
普通SQLのINSERT構文は、一つのテーブルに対してしか発行できないのだが、複数のテーブルに対して同時にインサートを発行する構文があるようだ。
ちょうどそんな構文が欲しいと思っていたところなので、早速内容を詳しく読んでみると、残念なことにOracleでしか使えない構文だということが分かった。
しかし、せっかく調べたので、その構文を掲載しておく。
INSERT ALL
INTO テーブル1 (カラム1, カラム2) values (値1, 値2)
INTO テーブル2 (カラム1, カラム2) values (値3, 値4)
SELECT * FROM dual;
こんな感じの構文なんだが、INSERT構文なのに最後にSELECT文がある。
なぜSELECT文が必要なのか分からない。
構文を見ると、何度も発行しなきゃならないINSERT構文を、まとめて1回で発行しているに過ぎない。
普通ならループ構文を使って処理するのだが、と筆者が言っている通り、ループで処理する内容を、一つの構文内に並べて書いたのが、このマルチテーブルインサート構文だと言えよう。
ループが大量に発生するような処理でもなければ、ループを数回回そうと、この構文で一度にINSERTしようと、パフォーマンス的にはそれ程の違いはないかもしれない。
まあ、いずれにせよ、Oracleでなければ使えない構文。
俺の場合は、普通にループを回して処理するしかないみたいだ。
|
| メッセージ文字数：662／681 |
| |
| 6690 |
マージテーブル実装 |
はくぶん |
2015-06-16 07:17:02 |
マージテーブルを実装してみた。
感想は、思ったほど速くも遅くもならない、ということ。
単に分割したテーブルを繋げているだけだな、という印象。
しかし、各テーブルを分割したまま扱えるのは便利。
例えば、5年分くらいのアクセスログがあるとして、それが一つのテーブルに収まってると、読み書きを一つのテーブルでしなければならない。
しかし、テーブルが年毎に分散されていると、今年のテーブルに新規ログを書き込んでる裏で、4年前のレコードを集計したりもできる。
一つのテーブルではできない分業が可能となるのだ。
技術者によっては、このテーブル一つ分をメモリに丸々収まる大きさに切り分け、すべてのテーブルをメモリ上にロードして運用してる例もあるらしい。
ディスクにデータを参照しに行かなくて済むから、全体としてかなりのスピードアップに繋がるようだ。
ただ、それなりにサーバの台数も要るので、素人が出来る技ではないのだが。
しかし、この話、発想次第ではこの自宅サーバのような小さな環境でも、何かに応用できるかもしれない。
マージテーブルとは、それだけ未知の可能性を秘めた、用途の広い技術だということだろう。
取りあえず年毎にログを分割してみた。
もうちょっと調整の必要もあるが、先ず何よりログテーブルの入れ替えシステムを作らないといけない。
と言うのも、新しい年に変わる際には必ずテーブルが一つ増えることになるので、マージテーブルを再構築しなければならないのである。
現在、マージテーブルは2008年から2015年まで8つのログテーブルを連結しているが、2016年のテーブルが増えても、マージテーブルを再構築しない限り、そのテーブルはマージテーブルには取り込まれないのである。
手動でやってもいいのだが、これが結構面倒、というより、注意点がいくつもあるので、それを見落とさないようにするためには、今の時点ですべてを自動化してしまった方が、早くて安全だろうと思うからだ。
元日の深夜にそんな面倒な作業をしたくないという意味合いもある。
ここで一つ、あるサイトで指摘されていた重要項目を、備忘録として記しておこう。
マージテーブルを作る際、記述部分の後半は、
ENGINE=MRG_MyISAM UNION=(連結する基テーブルたち) INSERT_METHOD=FIRSTかLAST
と説明されている。
しかし、
DEFAULT CHARSET=utf8
の項目は必ず入れること。
マニュアルには載っていないが、これを入れないと、エラー1168が返って来る場合がある。
ERROR 1168 (HY000): Unable to open underlying table which is differently defined or of non-MyISAM type or doesn't exist.
こんなエラー文だが、俺も出た。
訳すと、マージテーブル内の基テーブルに関して、マージテーブルと定義が違うため、またはMyISAMタイプじゃないため、もしくは存在しないため、（マージテーブルを通して）基テーブルが開けない、と言っているのである。
処理の内容がエラーなのではなく、基テーブルにCHAR型カラムがあると、マージテーブルがカラム定義を判断できず、その結果このエラーとなるようだ。
それを回避するために、ちゃんと文字コードを記述した方がいいとのこと。
基テーブルにCHAR型カラムが含まれていなければ、文字コードを指定しなくても大丈夫らしいが、CHAR型を含まないテーブル構成があり得るかどうか。
少なくとも俺の場合はあり得ないので、これは毎回入れることにした。
この件に関する詳しい内容はこちらのページで。
|
| メッセージ文字数：1521／1626 |
| |
| 6689 |
マージテーブル |
はくぶん |
2015-06-15 04:42:12 |
この掲示板のアクセスログがかなり肥大して来たので、データを分散しようと画策中。
始めにユニオンを試してみたが、話にならないくらい遅い。
テーブルを一つのままにしておくと3秒強で済む処理が、ユニオンで結合することにより30秒以上掛かる。
処理時間が10倍に延びるなどナンセンスである。
そうなって来ると、何のためにこのユニオンという機能があるのか分からない。
単に結合するだけ。
時間は問いませんよ。
そんな状況でしか使えない機能ということになる。
SQLを扱う人間に、それを納得する者などいないだろう。
今までマージテーブルの存在は知ってはいたが、実際に使ってみようと思ったことはなかった。
しかし、今回いよいよこのマージテーブルを使うことになりそうだ。
テーブルにまだまだ余裕があると言えばあるのだが、早めに対処しておいて失敗はない。
転ばぬ先の杖。
それがマージテーブルということである。
|
| メッセージ文字数：383／398 |
| |