終点枕崎

プログラミングとvimと音楽と地理

僕は耳と目を閉じ口をつぐんだ人間になろうと考えた

今日は攻殻機動隊のおはなしです。まだテレビシリーズしか見ていませんが、何回でも見返したくなるカッコよさ。

知ったきっかけは、S.A.C. 2nd GIGの劇中歌の「トルキア」でした。荘厳な英語とロシア語のボーカル、現代的なシンセサイザーの音作り、それでいてエキゾチックな曲調。たまらんです。

攻殻機動隊の劇中歌はどれも素晴らしいですよね。もっとたくさんの人に知ってもらいたいです。

そういうわけで、僕のお気に入りをいくつかあげようと思います。

www.youtube.com
みんな大好きトルキア。一番のお気に入りです。

www.youtube.com
あえてアニメシーンの動画にしました。サイトーさん渋すぎますよね。流れるシーンも含めて好きな曲です。

www.youtube.com
S.A.C.のオープニング曲ですね。サビ前の不穏な感じが心をくすぐりますね。

www.youtube.com
言わずと知れた名曲。アニメシリーズを見終わった前と後とで全く印象が違う曲でした。見終わる前はいたって普通の曲って印象でしたが、見終わった後はより孤独感とか終末感を感じますね。

やはり見れば見るほど完璧なアニメだと思います。話の展開やシーンとBGMの絡み合いが絶妙。一話完結のストーリーは初見でも理解できるので、一周目でも内容が訳分からなさすぎてつまらなくなるってことがありませんでしたね。ミーハーでも楽しめるように気遣いができています。

そういうわけで、是非アニメみてくださいな。

伊那谷探訪

前期の期末試験が終わった。体力の消費と体の痛みがひどい。二度とやりたくない。

ところで、この度7/28-7/30の間、地理レポート資料集めのために長野県は伊那谷を訪れた。その記録をここに残そうと思う。

1日目

テストが終わった。うーれしー!!!

その足でまずは京都駅に向かう。伊那市にいい感じのゲストハウスが空いているみたいなので予約を入れた。一泊3500円というのは貧乏学生にはとても嬉しい。

バスは16:10に京都駅を発車して、東名高速に入る。そして名古屋からは中央自動車道で長野方面へ。中央道西春近バス停に到着したのは21時前。

バスを降りると道路以外周りに一切明かりがない。いや、覚悟はしていたが本当に何もない。目が慣れるのにしばらく時間がかかる。一緒に降りた一人の女性はあっという間に暗い坂道を降りていってしまった。当たり前である。ここで変質者に襲われたら生きては帰れない自信がある。

幸いなことに僕はそれほど暗闇が苦手でないから、のんびりと坂を降りることにする。非日常感と謎の高揚感と少しの不安感が入り混じった不思議な気分だった。

高速道路は伊那谷の中でも山に近い高台を走っているから伊那の夜景が一望できた。この高揚感はおそらくこれが原因であろう。写真に収めることができなかったのが残念である。今度はきちんと三脚を持って行くことにする。

f:id:uchifuji:20170802011617j:plain

坂道を降りて行くと直に崖にさしかかる。これは伊那谷の特徴的な地形で、田切地形という。谷の真ん中を流れる天竜川の河岸段丘だけでなく、扇状地を流れる支流にも侵食が進み、段丘崖が現れている。そのため、この地域には太田切川、中田切川、与田切川など、「田切」の名がつく天竜川の支流がいくつか見られる。

5kmほどの道のりを歩いて、ようやく今日の宿の赤石商店に到着した。

f:id:uchifuji:20170802012648j:plain
(7/30の朝に撮影)

古民家を改装したらしい。寝床はこんな感じのドミトリー。

f:id:uchifuji:20170802013202j:plain

店主は優しい人だった。「西春近から歩いてきた」と言うと、「外国人か」と苦笑いされてしまった。

明日は絶起するわけにはいかないから、早めに寝ることにする。

2日目

7時に起きた。この時間に起きたのは何ヶ月ぶりだろうか。

自転車をレンタルできるということなので喜んで使わせてもらうことにする。

自転車は天竜川を渡り、伊那市街へ入る。伊那の町は時代から取り残されたような町だった。最盛期は商店街は人で溢れ、多くの人が行き来していたのだろう。そういった名残を感じさせる街だった。またいつか時間をかけて散策してみたい。

f:id:uchifuji:20170807221550j:plain

伊那の町を抜けて程なく、天竜川の段丘崖に差し掛かる。その高さは優に50mはある。崖を登りきると、そこには広大な田園地帯が広がっていた。

f:id:uchifuji:20170804143427j:plainf:id:uchifuji:20170804143456j:plain
奥には伊那の町が見える。

このような広大な台地の上での水田耕作を可能にしたのは、ご存知の通り西天竜幹線水路である。

西天竜幹線水路は長野県の上伊那地方の天竜川西岸を流れる農業用水である。長野県岡谷市で天竜川から取水し、辰野町箕輪町南箕輪村伊那市の台地状の扇状地上を横断する。この一大事業によって、江戸時代に比べて石高が3倍に増えたらしい。

箕輪町郷土博物館でいただいた資料から引用して、西天竜幹線水路の概要とその歴史を記しておく。

・西天竜幹線水路の概要(西天竜用水路 箕輪町見学会資料 信州大学農学部 内川義行 から一部引用)
岡谷市川岸で取水、伊那市小沢側へ放流(流量5.56m^3/sec)
水路総延長 約26km
受益農地面積 1,180ha
事業総額 680余万円
・構造物(同上資料とpixiv百科事典から一部引用)
頭首工 1ヵ所
サイホン6ヵ所
土砂吐 7ヵ所
ゲート 2ヵ所
分水工 83ヵ所(現在) 内、円筒分水工は48ヶ所
水路橋 7ヵ所?
ずい道 不明
発電所 1ヵ所 発電所から2.5キロメートル程上流にいった小沢川の途中に助水工がある。
助水工 不明
[深沢水路橋]
箕輪町深沢川を渡る鉄筋コンクリートラーメン構造の水路橋。
現在は廃止、道路に転用。水路は逆サイフォン形式に置き換えられた。
橋長 145m 幅 3m 橋脚高 15m
[円筒分水工](西天竜幹線水路 箕輪町見学会資料 信州大学農学部 内川義行 から一部引用)
開発は可知貫一(京都帝国大学)。穂坂申彦が導入。

形状 箇所数
27
20
矩形+半円水槽 1
48
分岐数 箇所数
1 4
2 19
3 20
4 4
不明 1

・西天竜幹線水路の歴史(西天竜用水と開田 より一部引用)
大正7年(1918年)
この年起こった米騒動第一次世界大戦により、政府が食糧増産政策をとったため、開発の機運が高まった。政府が開墾費用の40%を補助し、急速に実現の運びとなった。これ以前にも明治時代にも3回開発の計画や測量が行われたが、いずれも工事着手には至らなかった。
大正8年(1919年)
5月から全地区の測量が行われ、9月に完了。また先に申請した西天竜耕地整理組合が県知事より認可され、12月4日に創立総会が開かれた。
大正10年(1921年)
用地買収開始
大正11年(1922年)
11月に起工式を挙行し、水路工事着手
昭和3年(1928年)
第5期工事までが竣工し、11月に通水式を挙行した。これに先行し、2月からは開田工事が始まっている。
昭和4年(1929年)
6月に頭首工が完成
この頃に水争いが発生し、組合当局に改善要求
昭和8年(1933年)
円筒分水の工事に着手
昭和13年(1938年)
3月、深沢サイフォン工事が竣工
昭和14年(1939年)
4月に開田工事が竣工
昭和15年(1940年)
4月28日、竣工祝賀式を盛大に挙行

工事着手から18年、悲願であった疏水工事が終結し、約1,200ha(サッカーグラウンド1700枚分)が青々とした田園地帯と化したのであった。

全国各地の用水路の中でもこの西天竜幹線水路が異色な理由は、他でもなく48基の円筒分水工群である。円筒分水の仕組みに関しては、次のサイトに説明を任せることにする。
円筒分水ドット・コム
綺麗な円形をした分水槽、メカニックな機能美、そしてそれに見え隠れする血に彩られた水争いの歴史。なかなか興味深いものではなかろうか。

今回は伊那市南箕輪村箕輪町区間の水路沿いを輪行し、円筒分水の写真を撮ってきた。その中でも気に入った分水の写真をいくつかあげる。

f:id:uchifuji:20170808154654j:plainf:id:uchifuji:20170808154604j:plainf:id:uchifuji:20170808154434j:plainf:id:uchifuji:20170808155140j:plain

円筒分水や水路はよく手入れされている。一部の円筒分水のコンクリートはピカピカだった。全国的に円筒分水がその役目を終えていっている中、こうして持続的な改修がされているのは貴重である。

次に向かったのは箕輪町郷土博物館である。ここでは上伊那地方の水事情について貴重なお話を聞くことができた。

f:id:uchifuji:20170808155646j:plain

昔から上伊那地方の段丘面を水田開発しようという構想はあったらしい。昔の人も勿体無いと感じていたのだろう。しかし、それの実現には近代的な用水技術の出現を待たなければいけなかった。

近代化以前にも、用水路の建設によって開田された地域は僅かながら存在した。山奥の小さな沢から取水し、樋を伝って村まで水を引いたり、カナートのような横井戸を掘って地下水を集めたりなど。それほどまでして水を得る必要があったのだ。

また、木曽山脈にかかる伊那市の権兵衛峠には、かつてその峠を越えた用水路が存在した。木曽山用水といい、日本海側に注ぐ奈良井川の支流、白川の上流部から取水し、等高線に沿って、僅かな下り勾配を作りながら権兵衛峠を越え、太平洋側である伊那谷へ導水していたという。この用水路は、なんと中央分水嶺を越えていたのだ。水に対する執念をひしひしと感じる。

郷土博物館の職員の方にお礼を言い、その場を後にする。次は県道88号線を南下し、駒ヶ根市へ向かう。

小沢川の田切地形によって道が分断されていて辛い。川を横切るためだけに、40mもアップダウンしなければならないのだ。隣を走る中央自動車道の橋梁を横目に見ながら坂を登る。

f:id:uchifuji:20170808161619j:plainf:id:uchifuji:20170808161730j:plain

2時間ほどかかって、駒ヶ根市に到着。駒ケ根名物ソースカツ丼を食べることにする。明治亭本店に行ったが、1時すぎにも関わらず大行列ができていたので素直に諦めた。

代わりに駒ケ根駅前の「きよし」さんでカツ丼(上)をいただく。1080円。甘いソースとサクサクの衣の相性が絶妙だった。上を頼んだだけあって、肉も柔らかく美味しい。

f:id:uchifuji:20170808162355j:plain

午後は雨予報のため、国道153号線で赤石商店へ帰ることにする。

f:id:uchifuji:20170808162726p:plain

雨に降られながらも午後3時ごろに赤石商店に到着。店主にまた「外国人か」と苦笑いされてしまう。

なんでも、この辺りでは自転車に乗る人がいないらしい。言われてみれば、自転車に乗ったおばちゃん1人と、チャリダー1人しか見かけなかった。完全に車社会。近くのコンビニでさえも車で行くらしい。
歩いている人はもっと少ない。登校中の中学生しか見かけなかった。店主は、「歩いていると珍しいから見られるんだよねー」と言っていた。

晩御飯は、赤石商店を間借りして営業していたカレー屋さんでカレーをいただく。インディカ米とジャポニカ米のミックスで、インディカ米が苦手な僕でも食べやすい。
f:id:uchifuji:20170808163733j:plain

3日目

今日は帰るだけの日程だ。

6:53、伊那市発。天竜峡で乗り換えて、中部天竜へ向かう。天竜峡をすぎると、その先は秘境駅が連続する。誰が使っているのだろうか?駅への道が獣道だけしかないような駅がゴロゴロある。

f:id:uchifuji:20170808204319j:plain

昨日の雨のせいもあり、天竜川は濁っていた。

10:42、中部天竜着。佐久間ダム発電所が見える。次の列車まで1時間ほどあるからここで昼食をとる。が、駅前を見ると全くと言っていいほど活気がない。嫌な予感がして、駅員に食堂があるかどうか尋ねる。
「日曜日だから、空いてるのは病院の売店くらいですかねー。あとはやってるかどうかわかんないけど、食堂のいどばたさんが病院の隣にあるよ。」
いや、旅行中の昼食が病院の売店だなんて旅情がなさすぎる。食わない方がマシなくらいだ。いどばたに一縷の望みを託す。

f:id:uchifuji:20170808204203j:plain

橋を渡って対岸へゆく。上流では濁っていた天竜川も、ここでは透明さを取り戻しているようだ。

f:id:uchifuji:20170808204531j:plain

幸いにも営業していた。手打ちかけそば(700円)を食らう。

f:id:uchifuji:20170808204722j:plain

「アワビカレー」と書かれた広告が目に入る。山の中でアワビとはこれいかに。

話を聞くと、廃校になった小学校の跡地を、アワビの養殖場に仕立て上げたという。いわゆる町おこしってやつだ。まだアワビがなかなか育たないので、月に2日間しか提供できないらしい。残念なことに訪れたのが第4日曜日だったからありつけなかった。今度中部天竜を訪れた時は、もっとアワビが育つようになっていると良いのだが…

11:36、中部天竜発。豊橋へ向かう。
13:23、豊橋着。抹茶あんまきを食らう。
13:33、豊橋発。東海道本線を乗り継いで京都まで帰る。書くことがない。
京都に着いたのは16:42。9時間42分の長旅だった。

旅を終えて

良質なレポート資料が手に入ったのはもちろん、段丘崖の高さや開田された水田地帯の広大さを肌で感じることができ、レポートを書く上で非常に参考になった。

あと人生初のゲストハウスを体験できて非常に満足。赤石商店には、機会があればまた訪れたいものだ。

switch vs ハッシュマップ+関数オブジェクト

前々からちょっと気になってたやつです。

switch case 文で分岐するのと、switchの式をキーにしてハッシュマップに関数オブジェクトを突っ込んだものとどちらが速いかか調べました。

検証方法

16の分岐を持つ処理を100,000,000回繰り返して、それにかかった時間の平均を取る。岐条件の定数式は整数型とする。言語はC++

分岐数を16にしたのは、それ以上の分岐数になることが滅多にないからです。

定数式の値がバラバラでない時

定数式の値があまりバラバラでない時(例えば 1, 2, 4, 5, 8)、switch case 文に対してコンパイラはジャンプテーブルと呼ばれるアドレス表を生成します。なのでswitchを使ってもハッシュマップを使っても定数時間で分岐します。ただハッシュマップはハッシュテーブルを経由する為、switchと比べて無駄が多いです。

ソースコード

#include <iostream>
#include <functional>
#include <chrono>
#include <unordered_map>

int main(int argc, char* argv[])
{
	int i;
	std::cin >> i;

	auto start = std::chrono::system_clock::now();

	for(int j = 0; j < 100000000; j++)
	{
		switch(i)
		{
			case 0:
				i = 1;
				break;
			case 1:
				i = 2;
				break;
			case 2:
				i = 3;
				break;
			case 3:
				i = 4;
				break;
			case 4:
				i = 5;
				break;
			case 5:
				i = 6;
				break;
			case 6:
				i = 7;
				break;
			case 7:
				i = 8;
				break;
			case 8:
				i = 9;
				break;
			case 9:
				i = 10;
				break;
			case 10:
				i = 11;
				break;
			case 11:
				i = 12;
				break;
			case 12:
				i = 13;
				break;
			case 13:
				i = 14;
				break;
			case 14:
				i = 15;
				break;
			case 15:
				i = 0;
				break;
		}
	}

	auto end = std::chrono::system_clock::now();
	auto msec = std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count();

	std::cout << msec << std::endl;

	std::unordered_map<int, std::function<void()>> func_table;
	func_table.insert(std::make_pair(0, [&i](){ i = 1; }));
	func_table.insert(std::make_pair(1, [&i](){ i = 2; }));
	func_table.insert(std::make_pair(2, [&i](){ i = 3; }));
	func_table.insert(std::make_pair(3, [&i](){ i = 4; }));
	func_table.insert(std::make_pair(4, [&i](){ i = 5; }));
	func_table.insert(std::make_pair(5, [&i](){ i = 6; }));
	func_table.insert(std::make_pair(6, [&i](){ i = 7; }));
	func_table.insert(std::make_pair(7, [&i](){ i = 8; }));
	func_table.insert(std::make_pair(8, [&i](){ i = 9; }));
	func_table.insert(std::make_pair(9, [&i](){ i = 10; }));
	func_table.insert(std::make_pair(10, [&i](){ i = 11; }));
	func_table.insert(std::make_pair(11, [&i](){ i = 12; }));
	func_table.insert(std::make_pair(12, [&i](){ i = 13; }));
	func_table.insert(std::make_pair(13, [&i](){ i = 14; }));
	func_table.insert(std::make_pair(14, [&i](){ i = 15; }));
	func_table.insert(std::make_pair(15, [&i](){ i = 0; }));

	start = std::chrono::system_clock::now();

	for(int j = 0; j < 100000000; j++)
	{
		func_table[i]();
	}

	end = std::chrono::system_clock::now();

	msec = std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count();
	std::cout << msec << std::endl;

	return 0;
}

コンパイル

clang++ switch.cpp --std=c++11 -o switch.out -O2

結果

8回測った平均です。

switch case 178.5ms
ハッシュマップ 1146.375ms

圧倒的にswitchが速い!!!!

定数式の値がバラバラの時

このような時、switch case 文に対してコンパイラは一部で二分探索をするアセンブリコードを生成します。

ソースコード

#include <iostream>
#include <functional>
#include <chrono>
#include <unordered_map>

int main(int argc, char* argv[])
{
	int i;
	std::cin >> i;

	auto start = std::chrono::system_clock::now();

	for(int j = 0; j < 100000000; j++)
	{
		switch(i)
		{
			case 1:
				i = 2;
				break;
			case 2:
				i = 4;
				break;
			case 4:
				i = 8;
				break;
			case 8:
				i = 16;
				break;
			case 16:
				i = 32;
				break;
			case 32:
				i = 64;
			case 64:
				i = 128;
				break;
			case 128:
				i = 256;
				break;
			case 256:
				i = 512;
				break;
			case 512:
				i = 1024;
				break;
			case 1024:
				i = 2048;
				break;
			case 2048:
				i = 4096;
				break;
			case 4096:
				i = 8192;
				break;
			case 8192:
				i = 16384;
				break;
			case 16384:
				i = 32768;
				break;
			case 32768:
				i = 1;
				break;
		}
	}

	auto end = std::chrono::system_clock::now();
	auto msec = std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count();

	std::cout << msec << std::endl;

	std::unordered_map<int, std::function<void()>> func_table;
	func_table.insert(std::make_pair(1, [&i](){ i = 2; }));
	func_table.insert(std::make_pair(2, [&i](){ i = 4; }));
	func_table.insert(std::make_pair(4, [&i](){ i = 8; }));
	func_table.insert(std::make_pair(8, [&i](){ i = 16; }));
	func_table.insert(std::make_pair(16, [&i](){ i = 32; }));
	func_table.insert(std::make_pair(32, [&i](){ i = 64; }));
	func_table.insert(std::make_pair(64, [&i](){ i = 128; }));
	func_table.insert(std::make_pair(128, [&i](){ i = 256; }));
	func_table.insert(std::make_pair(256, [&i](){ i = 512; }));
	func_table.insert(std::make_pair(512, [&i](){ i = 1024; }));
	func_table.insert(std::make_pair(1024, [&i](){ i = 2048; }));
	func_table.insert(std::make_pair(2048, [&i](){ i = 4096; }));
	func_table.insert(std::make_pair(4096, [&i](){ i = 8192; }));
	func_table.insert(std::make_pair(8192, [&i](){ i = 16384; }));
	func_table.insert(std::make_pair(16384, [&i](){ i = 32768; }));
	func_table.insert(std::make_pair(32768, [&i](){ i = 1; }));

	start = std::chrono::system_clock::now();

	for(int j = 0; j < 100000000; j++)
	{
		func_table[i]();
	}

	end = std::chrono::system_clock::now();

	msec = std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count();
	std::cout << msec << std::endl;

	return 0;
}

コンパイル

clang++ switch.cpp --std=c++11 -o switch.out -O2

結果

8回計測して平均

switch case 249.5ms
ハッシュマップ 2065.25ms

当たり前ですが、さっきとあまり変わりませんね。二分探索のオーダーはO(log(n))なので、もっと分岐数が多ければ差は縮まるかもしれませんが、そんなに多くの分岐を使うことがまずないですね。

結論

switch case でいいやん。

壁を設置する粒子

どうもこんばんは。もう春も終わろうとしているこの頃ですが、僕は何をしていたかというと、よくわからない妙ちくりんなものを作っていました。

言葉で説明するよりも、まずは動画を見てもらった方がいいですね。カクカクしていて申し訳ないです。

youtu.be

概要

振る舞いのルールは非常に単純で、次の3つのルールに従っています。

  1. 粒子は一定速度で動き、自分の通ったところに壁を設置する
  2. 粒子は壁に当たると反射される(自分で設置した壁も含めて)
  3. 壁は一定時間経つと消滅

一見線分が動いているように見えますが、内部的には先頭の粒子とそれに続く壁によって構成されています。

なぜ作ったの?

複雑な動きを眺めてニヤニヤしたかったから。ただ、予想してたよりかなり「収束」(後から説明)が発生することがわかったので、ライフゲームのように安定に向かわないようなパターンを作るのは不可能かと思います。

開発言語は?

Javaです。

点と点の当たり判定はないの?

粒子の大きさはゼロなので当たり判定はないです。仮にあっても、実数同士の比較なのであまり意味がないです。ただ粒子と壁の間には当たり判定があります。ちなみに壁の厚さもゼロです。

収束する粒子

f:id:uchifuji:20170518013201p:plain
注意深く見ればわかりますが、動かなくなってその場にとどまり続ける粒子がちらほら見られます。この粒子は「収束」を起こしていて、粒子の位置する点は収束した点を示します。

そもそもなぜ収束するのかという話ですが、大雑把に言えば

なんらかの原因で粒子が四方を壁に囲まれる → 自分の設置した壁に無限にぶつかりまくって身動きが取れなくなる = 収束

という仕組みで発生します。例えばこんな感じ。自分自身で設置した壁に当たって自滅する粒子、とても健気です。
f:id:uchifuji:20170518022223p:plain

当然、壁の消滅時間が長いほど収束は頻繁に起きます。あと粒子の密度が高いほど収束の起きる確率が高い(つまり衝突する確率が高い)。動画では一定の間隔で新しい粒子を追加していますが、時間が経てば一定の密度で均衡します。

そもそも本当に収束するのか

壁が永遠に消えないのであれば収束するのは当たり前です。しかし、壁が有限時間内に消滅する場合だと、この「収束」は少々直感に反します。いつかは壁は消えるのだから、もう一度粒子は動き出しそうです。

正直にいうと、最初作った時は本当に収束するのかあやふやにしたまま「収束」の処理を行っていました。時間あたりの衝突回数が閾値を超えた時に収束扱いにするというものです。ただこの「収束」を取り入れないと、延々と壁と反射し続ける粒子が発生してプログラムが固まっちゃうんですよね。仕方ないね。

こういったメタ的な理由で勝手に収束させていたのですが、先日これを大学の友人に見せたところ、「本当に収束するのか」という疑問を呈されまして。確かにそうです。

というわけで、このままあやふやにしておくのも気持ち悪いので、自分なりに考察を試みました。少なくとも分かったのは、

  • 収束には2個以上の粒子が必要
  • 収束するパターンは一応存在はする
  • 粒子が反射するたびに粒子が移動可能な範囲は狭義単調減少する。だからt(n)(n回目の衝突からn+1回目の衝突までの時間)は狭義単調減少する数列a(n)によって上から押さえることができるはず。ただa(n)の無限級数が収束することを示せない。

ということです。全然分かってないじょのいこ。

収束するパターンの例

筆者はε-N論法習いたてのペーペーなので、間違ったこといってるかもしれません。もし何かあればコメントで指摘お願いします。
f:id:uchifuji:20170518024157j:plain
このパターンは、同じ反射のパターンを再帰的に繰り返します。なので、先ほど定義したa(n)は指数関数的に減少します。なのでt(n)の無限級数は有限値に収束。よって粒子の総運動時間は有限時間内に収束します。それよりも長く壁の消滅時間を設定すれば粒子は収束します。

というわけで収束するパターンは存在するには存在すると思います。しかし、もっと一般的に、どんな条件なら収束するのか、そしてそれをどのように示すのかは分かりませんでした。数学のプロよ解いてくれ…。

最後に

なんとも歯切れの悪い記事になってしまいましたが、これが現時点での僕が持てる知識を総動員して考えた結果です。これらの問題を解く鍵があるのなら、ご教授いただけると嬉しいです。

それではまた。
f:id:uchifuji:20170518033535p:plain
(壁が消えない場合の収束する様子)

終点枕崎

utchyと申します。はじめまして。
終点枕崎、始めさせていただきます。


まず最初に、このブログを始めるにあたって

  • 筆者のプロフィール
  • このブログを立ち上げた目的
  • ブログの主な方針

以上三つを以下に記します。

筆者のプロフィール

はてなブログのプロフィールにも書きましたが改めて

名前utchy
職業学生
在住地京都
趣味プログラミング/音楽制作
興味Vim/執筆活動/英語/地理学

趣味と興味の違いは、趣味(既に色々やってきたもの)、興味(これからやりたいと思っていること)です。


5年間ほど趣味でC++を触ってきました。
最近はガベージコレクションの便利さに感動しつつ、Javaにどっぷりはまっています。更新はしばらくはJava関連ばかりになるかと思います。

あと友人に触発されて最近Vimを使ってコーデイングしています。
Javaの開発でVim使うってのはやせ我慢な気もしますが、あれです、経験大事です。

このブログを立ち上げた目的

  1. 文章力をつける
  2. 自分の見たこと、知ったこと、やったことを文章の形で残しておく

1.は僕のただの願望です。文章力、大事。

2.今までも趣味的な活動はやってきたのですが、それを文章の形で残して、他の様々な人に見てもらうといった機会はありませんでした。
これを機に色々情報を発信して行けたらなと思います。あと備忘録的な記事も書けたらなと。

ブログの主な方針

更新頻度ですが、基本週一回以上の更新を心がけるつもりです。ただあまりに内容が薄くなってしまうような恐れがあれば、次の週に回すかもしれないです。
内容としては、技術的な内容が主な要素になるかと思います。それに加えて音楽のことや、地理的な小話なんかも投稿しようと考えています。