堕天使の煉獄

本来の用法とは違うのだろうけど
プロジェクトをスクラップアンドビルド～

タイミング的に一度整理した方が
後々楽になるので、いったんプロジェクトの中身を空っぽにして
依存関係をチェックしながらソースを追加して行きつつ
その都度ソースコードの修正も……

とか良くやるのですが。

こんな記事が。
ttp://d.hatena.ne.jp/melpon/20101022/1287705842


そうだよなー。
いっぺんC#とか触ったり、テンプレートを常用しだすと
.cppって要らなくね？　ってなるよなぁ。

そういう意味では、おいらもすでに普通の C++ プログラマｗ

今のまでのところは、特に深く考えず、

単純にどうやっても代替案のない
特定ケースでの長大なcase文だとか
その場限定で使い回すこともない
長めの関数、
（個人的な基準では20～30行以上？
だいたい感覚的に長くなったなと思ったら分ける程度）

とかだけcppに書いて
あとはみんなヘッダに書く感じだったり。

全部ヘッダにあるのに
staticな変数の実体書くために
一行だけのcpp(include足せば二行だけど)
とか、あほらしいなーとかは思ってはいて。

__declspec(selectany)
を使うのも一般的なのかなー
vc++独自拡張だしなーコレ。

と、腑に落ちない物の、ｃ++ってこういうもんだよなーと
cppもそれなりに使ってたりしてたりしたんだけど
上の記事を読んで、

なんだ、そこまでやっちゃっていいんだ。

というか、c#とかの最近の言語風に書いちゃっても
別にいい、というか、もはや周りの環境がそういう感じになってるのかな？
とか感じたり。

最近じゃもう、最初に触った言語、習得した言語がc++です。
なんて人、ほとんどいないだろうしね。

そもそも、ヘッダとcpp分けるのって
大昔のｃ++以前のc言語の時代、
まだメモリもcpuも貧弱な時代に
コンパイルの負荷を分散させて、貧弱なハードウェア上でも
大きなプロジェクトをビルド出来る様にする仕組み
からの仕組みなわけで。

最近では分割コンパイルといえば、マルチコアやネットワークつかった
並列ビルドの方の意味合いにかわっちゃってるですよね。


なので、ビルドに何時間もかかるような規模のもので無ければ
むしろ分割コンパイルはしない方がマシ。（と書くと語弊があるな）

旧来の方式だと、
依存関係をまず調べて、依存関係内のものを一つのグループとして
そのグループをコンパイル。

共通して複数のグループに属しているヘッダなんかがあると
そのヘッダの中身を変更するだけで
依存関係のあるグループすべてがリコンパイル対象となってしまう。

なので、共通ヘッダみたいな、常にインクルードされるヘッダとか
ヘッダをまとめた共通ヘッダヘッダ、みたいなのを作ってると
とあるヘッダの改行一個の変更で、ほぼプロジェクト全部リビルド……
なんて憂き目にあう羽目になるんですよねｗ

さらにはその依存関係の順番によって
やっかいな循環参照だとかになったりもする。


いったんすべての宣言部分を読み込んで
そこで依存関係とか勝手にコンパイラの側で
整理してからコンパイルする方式のが
最近の状況的には現実的なのですよね。
（後発の最近の言語はそんな感じになってるっぽい）
メモリもｃｐｕパワーも有り余ってるわけだし。



それに似た感じのが上の記事の
cppを一つにする。
という方法論なのでしょうね。

んまあ、ヘッダの循環参照問題は依然として残りますが。
ほんとヘッダの循環参照ってやっかいなんですよね……

しかしヘッダオンリーで考えると
モジュール化（依存関係が切り離されて独立したグループ）を考えた
設計がやりやすくなるので、循環参照を起こりにくくすることが
できたりもする。


なので、なるほど、徹底してcppを使わないと言う方法も
良い方法なのだなぁと。



とはいえ。

スタティックライブラリ（LIB）化目的の物だと
ヘッダに全部書いちゃうのは問題アリアリだったりもするｗ

この記事のリンクもとだったか、どこかのコメントにあったけど
作成中は全部ヘッダに書いて、
完成したあとで、ヘッダとcppに分けた物を最終的なライブラリとして完成。

みたいなやり方をしているというのがあって
なるほど－とかおもたり。

cppを一つにする方法、たしかに
格段にビルド時間短縮出来るんですよね。

開発中の、頻繁に修正はいる時には
そのたびにビルドに３０秒とか１分とか掛かってると
ストレスでしかないですよね。


そんで気がつくと、半日ぐらい一切ビルドしないで
ひたすらコーディングして。

そんで半日分のコードをビルドして、一個もエラーでないと

「んひぃぃぃぃっ、ぎんもぢいひぃぃぃっっ」

とかなったりするのですが（ぉ
でもやっぱり、所詮人の手。
ビルドは通ってもコンパイルエラーじゃないバグはいくつも出てくるので
その後の検証とかも時間かかったりして。

やっぱ、少しずつトライアンドエラーしながら進めた方が
楽だったりもするし。
（ケースバイケースだけど）

そのときにビルドが毎回、数秒程度ならどれだけストレス減ることか。

ビルドするたびに飲み物おかわりとかしてると
しっこが止まらなくなります（ぉ

なので、制作中だけは、ほぼヘッダのみで記述して
最終的にはきっちりとcppとにわける。
と言う方法論は確かにいいやり方だな、とおもたり。


そんな感じで、ソースコードを全面修正中。

とはいえ、極端にcpp排斥するのも微妙かなーというところもあったり。

モジュール単位という考えをしっかりしていれば
というよりモジュール単位でのコンパイル単位？　みたいなのを
意識したコーディングに自然となるので、その中でならcppを使うのも
ありかなーと言う感じですね。

どういう意図でヘッダをリンクしてるのか、とか考えるようになるぽ。


ふむう。

うーんうーん。

そろそろしんどくなってきた。

相も変わらずＰＧやってるのですが。

ＧＵＩ機能的な文字列描画まわりテスト。


文字のアライメント付き表示（８方向+中央の９位置）とか
文字数が指定の範囲を超えたらスクロール表示とか。

そんでさらに、その文字列表示オブジェクトを
行の単位で扱えるリストビュー的なのとか。
行間のマージンの指定とかもあったり、背景の指定も出来たりみたいなの。

……。

クラスの実装はさておき、上の例を表示するのには
利用側からは、こんなかんじで記述して使うのですが……


なんかもう、多重継承にテンプレートに、さらにはクラステンプレートの継承とか
ｃ++の用法的にはまともな使い方してるつもりなんですけどね。

ただの文字を表示するだけに、なんだか大げさになりすぎたかなぁ。
とかちょっと我に返り気味……。

んまあ、ここから新しい機能とか追加したりするのは
仕組み的に楽なんでしょうけども、
一年後とかにコレ見て、利用法の方がすぐにぱっと出てくるかと言えば……。

そういうところは、テンプレートとか使うと
かえって訳がわからなくなっちゃうような。


あと、ｃ＋＋の駄目なところを回避するのが
結構な足かせになっちゃってるのを、最近頓に。

まず、上のソース見てもらうとわかるのですが
オブジェクトの生成にはだいたいmakeという生成ヘルパーを使用してます。

コレの中身は単純に自分をnewしてshared_ptrにいれて返してるだけの物です。

そうしている理由というのが、単にstd::make_shared<Hoge>(...)とか
毎回書くのが面倒……というわけではなく、（それも無いわけじゃないけどｗ）

C#なんかの最近の言語と違って、
ｃ++はインスタンスとポインタの両方の生成方法が任意に使えるのですが、
インスタンスで生成した物はポリモーフィズムが使えなくなっちゃうんですよね。

継承されたオブジェクトを親クラスに入れる事が出来る……というのは
ポインタ限定なんですよね。
（出来ない訳じゃないけど、する意味はない）

class HogeBase{...};
class Moge : public HogeBase{...};

で、

HogeBase* hoge1 = new Moge();

は、いいけど

HogeBase hoge2 = Moge();

だと、hoge2の中身はHogeBaseになってしまう
正確には、HogeBaseのコピーコンストラクタが呼ばれて
（上の例だとムーブコンストラクタかな？）実質
HogeBase hoge2 = HogeBase();

と同じ事になってしまう。
当然Mogeクラス独自のメソッドやメンバ変数は一切使えない。

スライシングと言う奴ですね。

なので、多態性を持たせようとおもうと、ポインタで生成させないといけない。
が、newしたらdeleteしないと、当然メモリリークしてしまう。

そうなると、必然的にshared_ptrに常に包む運用が現実的なわけです。
（スマポはポインタなので、多態性は普通につかえる）

で、そうなると、そもそもコンストラクタをprivateにしちゃって
makeメソッドからしか生成出来ない、つまりshared_ptrの形でしか
生成出来ないようにした方が都合がよいわけです。

が、しかし、ここでふぁっきんなのが、
そういう用途で使おうとおもうと

std::make_sharedが使えなくなっちゃうんですよね。

いや、回避方法はあるっちゃあるのですが。

通常の

std::shared_ptr<Hoge>(new Hoge);

にくらべて

std::make_shared<Hoge>();

で生成する事により、例外安全と、生成コストの軽減という恩恵がある。

が、std::make_sharedはprivateなコンストラクタが呼べないんですよね……。

回避するには、インナークラスを使った生成クラスを内部に持って、
そこで生成するとか、いくつか回避方法はあるものの。
実際のところ、make_sharedと通常の生成と、
そのコスト速度差はだいたい1.5倍～２倍程度らしいです。

毎フレーム大量に生成、消去する様な物の場合は
そもそもshared_ptrは向いてない、もしくはあろけーたを自作するなど
チューンが必要になったりするのだけども

今回のような一度生成したら、しばらく使い続ける様な物に関しては
最初の一回の生成のコストが多少増えたところで問題ない。

しかし、ｃ++なんて言語をやってる輩からすれば
実行速度が速い！　というのが矜持じゃないですか。

なので素直にmake_sharedが使えないというのは

「ふんぐぐぐぐぐっっっ……！！！（血涙）」

ってかんじなのですよ（ぉ

そんでさらに、スマポに包んで、もうあとは問題なしかと言えば問題はまだあって。

全部が全部shared_ptrにしてしまうと
浅いコピーと深いコピーを使い分ける必要も出てきたりで。

浅いコピーは、単純にメモリのアドレスのコピーだけ、みたいなの。

auto sp = std::make_shared<Hoge>(0,0);
//class Hoge() : m_pos(0,0){}とかになってるとおもいねぇ

auto sp2 = sp;

なんてやると、spとsp2のポインタが指すHogeクラスの実体は同じ物な訳です。

が、これだと都合が悪い時がある。

sp2->setPos(100,100);

なんてやった後、別の場所で

sp->pos();

とコピー元のほうをみると、
こっちもposの値は(100,100)になってしまうのです。
なぜなら、どちらも同じ実体を指している訳ですから。
解ってやってるときならともかく、
複製して、別の物を指していると思ったら、
同じ物という思い違いで思わぬバグになることもあるわけで。

そこで、深いコピー（ディープコピー）が必要になるわけで。

auto sp = std::make_shared<Hoge>(0,0);

auto sp2 = sp->clone();

とすると、
上のような事は起こらない。
cloneの中では新たにHogeクラスを新たにnewして中身をコピーするということが
行われている。
cloneした直後は、中身の値（オブジェクト自体がもってるメンバの値）は同じだけども
インスタンス（実体）は別物となる。

コピーするオブジェクトが、
値オブジェクトなのか（オブジェクトの中身が重要）
oop的なオブジェクトなのか（中身の違いよりも、どのオブジェクトなのかが重要？）
ディープコピーする意図というか意味を理解するには
対象のオブジェクトがどのような意図のオブジェクトなのかの理解が必要になる。
と、けっこう単純な話でもなかったりする。

そんでもって、clone関数は標準であるわけでなく、
自前で用意しないといけない。

上のソースコードの中でも
ラベルオブジェクトを一個だけ作って
ラベルリストに登録する際には、それぞれcloneしたものを登録してたりします。

この例の場合だと、
フォント、文字色、背景といった設定は複製して、
文字列だけ別のに変えたラベルを複製している感じです。

なんかいろいろとごてごて機能つけすぎると
生成部分が複数行になったりするぐらい糞長くなっちゃいがちなので

最初に一個ひな形的なのを作って
cloneで適時生成するようなほうのが楽ちんというのもあります。

がしかし、毎度コピーするたびに
コレは浅いコピーであるべきなのか、ディープコピーするべきなのか。

そしてディープコピーは普通に一回分の生成コスト+中身のコピーのコスト
が掛かるので必要なとき以外はするべきではない。

単純にみーんなスマポでハッピーというわけにも行かない、というかんじぽ。



んでまあ、何が言いたいのかといえば

単純なnewもつかえず、インスタンスも生成させない。
テンプレートでごてごて＜＞がついてる。

コピーにはcloneを使う。

なんか奇形なソースコードになってくなぁ……と。

どんどん、標準な機能が表から消えていき
独自の拡張関数ばかりになっていってしまい
ほんとこれ、１年後とか見たときに、すぐに使えるのだろうか？

もしくは、誰か他の人が見たとき
利用法がすぐに解るのだろうか？　と。

仕様書が無いと使えない、学習コストがかかるライブラリ。

なんか微妙だなぁ。


一昔前に一部で話題になった
main.cppだけで200kb超えの
うんこスパゲッティーソースコードのアクションゲーム。

変数名も、一文字とかざら。
ヘッダファイル？　何それ？
意味をなさない記号の変数名の嵐。
みんなグローバル。
リソース（マップ）とかもソースコードに直接記入。

とか、おおよそ、
やっちゃいけないと言われることがすべて詰まった
恐ろしいソースコードなのですが。

だが動く。

普通にオープニングから複数面クリア、エンディングまである。


オブジェクト指向だとか設計だとか……

そんなんよりもただ、

「動けばいいんだよ」

という強烈なアンチテーゼな作品ですよね。


どっかの二丁拳銃の女海賊さんも言ってたっけ。

「こんなもんはな、撃てて、当たりゃいいんだよ」

と。

「汎用性を求める決定をした時、そのプロジェクトの失敗も決定する」

と書くと、マーフィーの法則っぽい？ｗ


そんな感じで
ちまちまとオレオレライブラリ作りも不毛感がましてきて
末期的な感じだなーとか。

そろそろ、どんなでもいいからまともなゲームっぽいのつくらないとね。

以前つくったＡＤＶ用のシステムも
今見れば噴飯もののソースコードだけども
ちゃんと用件みたして動いてるんだものなぁ。

中身がどれほど高度で精練されていても、
未完成ならばそれに価値はないよな。

んでもまあ、その課程でえた経験と知識……その分だけはまあ
無駄ではないのかもだけども。

そこで失った時間的損失に釣り合うのかと言えば。


そんな感じでぐんにょり中な最近。

子供の頃は、飲み終わった後に
カップの底に溶けきれなかった砂糖が残るぐらい
紅茶には砂糖をアホほど入れてたりしてたり。

んが、そこそこ大人になってからは
紅茶もコーヒーもブラック、ストレートな嗜好になっていたのですが。

ここ最近、相変わらず食事量は少なめで
さらにウォーキングと筋トレなんかもやってたりするせいか。

なにげに思いつきでひさしぶりに
入れてみた砂糖入りの紅茶がやけに旨い。

食事の量が減ったところに運動してる所為で
糖分足りてないんでしょうかね。

てか、たまには入れてみよう、と思った時点ですでに
脳みそが支配されていたんだろうなｗ

んでもまあ、さすがに、
上記の飲み終わりにカップの底に砂糖が残るレベルではなく、
普通にティースプーン一杯ぐらいの適量程度しか入れてないですけど。


話は変わって。

某音楽系ブログを読んで。

ここ最近、ベテランのメタルバンド勢が
軒並にみ過去最高ランクのチャートインが相次いでいて
海外ではメタルが盛況だ、みたいな記事があったのですが……。

これって単純に、一般層が音楽に興味なくなって
がっつりと古くからの固定客のいるところが
相対的に浮き上がってきただけなんだろうなーとか。

15年くらい前だと20～30万枚とかだとぼちぼちってレベルだけど
今だとチャートのトップクラスの枚数だったりするし。

流行り廃りに関係なく
メタルを聞いてる人はずっと聞き続けてるって事なんじゃないのかな。


とかいいつつ、おいらのばあいは
ここ最近はめっきり新しいバンドに手を出してなかったり。

過去の反芻を繰り返しているかんじでｗ

相変わらずSTRATOVARIUS好き～だったりするし。
（んでも最近の大ティモさん抜けてからのはちょっと熱が冷め気味ではある。）

エリサ嬢在籍時のDarkMoorみたいなバンドでてこないかなぁ。

DarkMoor脱退組のその後のDreamakerも、エリサ嬢の別バンド？のHamkaも
ここ最近は活動止まってるっぽいしなぁ。

Dreamakerはデス声ありな硬派路線、Hamkaは民族系のテイストおおかったりと
DarkMoorの様なシンフォニックな感じは薄いので
ドストライクってかんじではないのだけども
好きなんですよね。

あいもかわらずメロスパ～。

ここ最近で見つけた良バンドといえば
Obsidian Shellぐらいかなぁ。
ttps://www.jamendo.com/en/list/a76571/angelic-asylum

↑のはオフィシャルから無料で公開されてるアルバム。

何とかライセンスってので、フリー公開されてるぽ。

なんか英語よくわからんのですが
最近はもう活動してないのかな？

更新終了したフリーウェアみたく、
権利は放棄しないけどオープンソースにしたよ～
な感じの公開みたい？

二曲目のOrphanageで一気に好きになりました。
シンフォニックで女性Ｖｏのメロスピ～。

他にも何枚かアルバム公開されてるのですが
このアルバム以外は
メタルから路線変更？　というか迷走してる感じで
あんまし好みから外れてて、個人的には微妙でしたけど。

なにげに後の作のが音質悪かったりとかするのは
レコード契約切られたとかそういう制作環境の影響とかなのだろうか……？？


しかし嗜好の変化が無いかと言えば、そういうわけでもなく
昔は、なんかたらたらと速くもなく遅くもなく、
悪くはないんだけども、かったるいなーと思っていた
インダストリアル系が、なんか普通にいいなと思うようになってきてたり。

最近、H.I.MとかD'espairsRayなんか普通に聞いてたりするし。


とりあえず、紅茶がおいしい最近。

先日の日記の、スリープモードの件は
やっぱりUW500が原因っぽいですね。

UW500の電源をオフにしてからスリープモードにすると
部屋の電気をつけ消ししても、スリープから復帰しなかったり。

その状態でUW500の電源をonにするとスリープから復帰するし。
……それ自体は普通か。
デフォルトでＵＳＢ機器の追加もスリープ解除の条件なってるみたいなので。

ただ、機器によってはデバイスの項目で
電源オプションの項目があって、スリープの復帰の対象デバイスから外すことができる
みたいな記事あったのですが、UW500にはそんな設定項目無い～

んまあ、win7はもはやほぼ非対応機器だからなぁ。

ただの音源ボードの代わりにはなるけど、
ｗｉｎ７用asioドライバが、「対応予定はない」ときっぱり宣言されちゃってる
もはや過去の遺物ｗ


しかしここ最近は、昼夜の寒暖の差が激しいですね。

昼間は半袖で、エアコンつけようか迷うぐらいに暑いのに
朝方は長袖長ズボンじゃないと寒いってかんじで。

体調崩さないように気をつけないとな。

先日の激しい雷がなってた時の事。

ｗｉｎ７のスリープモードは、デフォでは
ハイブリッドスリープという物になっていて、

メモリとＨＤＤ両方に状態を保存する仕組みだとかで。

スリープ中に落雷などで停電した場合、
過電流とかだとアウトだけども
（一応雷サージ対策付きのコンセント使ってるけど、どうなんでしょねコレ）
単なる停電の場合には、普通に電源が落ちて
また電源ボタンを押したら、ＨＤＤに保存された以前の状態を読み取って
スリープから復旧したときと同じになる。

そしてスリープ中はＨＤＤにアクセスはしないので
停電によるＨＤＤへの影響は無い。


という様な記事を読んで、
そっかー、以前は雷鳴ってきたらＰＣの電源落としてたけど
いまならスリープにしとけばおｋなのかー。


ということで、そうしてたのですが。


なにげにこのスリープモード
部屋の電気（蛍光灯）を付けたり消したりしたときに、
スリープが解ける時あるんですよね。

以前から部屋の電気をつけ消ししたときに
UW500というオーディオインターフェースが
勝手にスタンバイモードに移行して、音が出なくなる。
という現象が起こっていたのですが。
（いったんUW500の電源落として再起動すると元に戻るけど）

まさかスリープモードまで解除してしまうとは……
それも必ずってわけでなく10回にいっぺんぐらいの確率だったりして。


で、本題なのですが。

その先日の雷の日。

ドーンと、割と近くに落雷があった瞬間、
ＰＣのやつがひょっこりとスリープモードから解除されたんですよね……ｗ

落雷でスリープ復帰っておまっ……。


結局、手動でシャットダウンしました。

だめじゃん。スリープモード……。


どうも、大きな電流の変化があると、解除されてしまう模様。

なにげに、「スリープモード 蛍光灯」でググると
同じ状態の人がちらほらと。

たこ足をやめるとか、蛍光灯の種類を変えるとかでも
ある程度は緩和できるらしいのですが。

一件、気になる情報が。

部屋の電気のつけ消しでスリープが解除される時に
イベントログをみると、スリープの解除につかわれたデバイスが
ログに残るそうな。

その人の場合は、キーボードによってスリープが解除されたとなるとかで
スリープからの復帰にキーボードからの入力を条件に入れないことで
解決出来た……みたいな事が書いてある。

ふむう。

ということで、うちのイベントログを見てみる。



ズコーー


不明っておいｗ

てか、それ以外の、普通にキーボード触って復帰させたときのも
原因は不明になっとるやんけ。

で、「スリープ解除の原因: 不明」でググってみると
なんかわりと良くある感じっぽい？

うーん。

んまあ、「スリープ解除の原因: 不明」でググった結果の多くは
何もしてないのに勝手にスリープが解除される、
というトラブルに関わる感じ？　ってのがほとんどのようで
幸いそういう状態ではないのですが。

それでもなんだか、腑に落ちない感じ～。

ＵＳＢ機器周りの抜き差し等も関係するらしいので
上記の以前からある、UW500の電源周りの影響が
そのままスリープ解除につながっている線が濃厚な気もしないでもないぽ。

まだ試してないけど、スリープ中にUW500の電源をオン・オフしたら
スリープ復旧するのかなぁ。

あとで試してみよう。


しかしまあ、雷で停電ではなく、たぶん瞬間停電？　みたいな状態でも
スリープ復帰しちゃうのはなんかアレだなぁ。

まあ、ｘｐに比べて電源オフからの起動は随分と速くなったので
雷の時は素直に今まで通り電源オフにした方が良いということですかね。

……んでもｗｉｎ７って
ｘｐに比べてシャットダウンには時間が掛かるようになった気がするぽ。

終了してないプログラムが～っていうのが、なかなか終了しないまま
結構待たされたりして。

先日の雷のとき、スリープから復旧しちゃったときに
慌ててシャットダウンしたのだけども、なかなか電源落ちないのでやきもきしたｗ

電源落ちて数分後に、「ぱしっ」っていう空気を突き刺す音のあと
ものすごく近くで雷落ちたりして、ひえーってなったりして。

雷見るのは好きなんですけどね。

ＰＣとかぶっ壊されるのだけはかんべんな（コング調）なのですよ。


でもまあ、ＵＰＳとか入れるほど大層なものでもないしなぁ。

九月から深夜のウォーキング再開、と息巻いていたものの
１日、２日と雨。

んで、ようやく三日の夜からスタート。
しかし、四日目も雨。
が、かなり小雨。
ネットの天気図みれるところで、雨雲の動きみたいなのみたら
ちょうどウォーキング終わって帰宅する時刻あたりに
どざーっと降るっぽい感じらしい。

んー、ここで休んじゃうと、またずるずるいちゃいそうだなーってことで
行くことにする。

ほんのちょっとぱらついてる程度だったのだけども
その中を一時間も歩いてたら、やっぱりというか、
地味にびしょ濡れｗ

んで、帰宅後、お風呂に入ってる途中で
外は滝のような大雨。

うは、天気予報的中。

しかし、天気予報の雲の動きをみてると、
南西から北東に雨雲が動いていたのだけども。
外に出たとき、風は北から南に吹いてたんだよな。

空と地上で風の向きが逆だったのかな？？


で、今日も雨。

夜は止んでるっぽいんだけども、どうやら降ったり止んだりな感じらしい。

んでもって、すでに足が筋肉痛にｗ

ってことで、今日はウォーキングお休み～。

筋肉痛とか疲労たまってるときに運動しても意味ないどころか
逆効果なので、休むときは休む～。


しかし、久しぶりに行ったけど、
やっぱいいな。
人気のない深夜にぷらぷら出歩くのは。

しかし、相変わらず……というかむしろ増えた？
こんな時間（深夜の2時～３時）の、さらに人の通りとか民家の無い
田んぼだらけの道を選んで歩いてるのに、
結構車とすれ違う。

以前の時も、一台もすれ違わなかった日って
数えるほどしかなかったし。

自分のことは棚に上げつつ、こいつらこんな時間になにしてんだろ？
とか思ったり（ぉ


そんでもって相変わらず、うざったい珍走団は９月になっても走ってたり……
夏休み気分延長ですかね……
全員単独で誰にも迷惑掛けない感じで事故って死ねばいいのに……
（それでも警察とか消防とかに迷惑かけるか……）