検索

9月1日より始めた減量だが、4ヶ月でおよそ10kgの減量に成功した。現在80kgを切りつつある最中。
BMI標準体重は71.3kgなので、ようやく折り返しポイント通過中、という状況。
食事制限と週3日のジムでのマンツーマントレーニング（20分程度の筋トレ）を続けている。

正直なところ、荷重トレーニングについてはここ2ヶ月ほど重さが変わっていない。デスクワークで日常的に筋肉を使っていないこともあるせいか、どうも、あるレベルの重さ以上にはなかなか上げられない。
それでも減量は続いていることから、筋肉が増えるというよりはやはり脂肪を減らす方向が維持されていると考えるべきか。
実際、去年末～今年前半の筋肉を増やす方向のトレーニングでもあまり目立って筋肉が増えたわけではない。子供の頃から運動してなかったこともあり、筋肉がつきにくいのだろうか。

ともあれ、今のペースを維持することにまずは専念して、折返しを走り切ることに集中したい。

2018年は個人のブログはほとんど書けなかった。
まず仕事としてのアプリケーション開発に燃え尽きてしまったのと、今年の前半～夏は特に体幹トレーニングにシフトしてからは強度が強すぎるせいか土曜のトレーニングのあとは日曜まで倒れ込む有様で、あまりプライベートな休みを勉強/プログラミング/ブログ書きに割くことができなかった。

代わりに、ぐったりしてる土曜のトレーニング後や日曜などにアニメはたくさん視聴できた気がする。正直、ここまでアニメを観まくったのは人生初だったかもしれない。pixivに没頭する時間はその分減った。

また、奈良・飛鳥旅行と恐山旅行で、日本仏教の始点と終点（というか霊場としての北端）をこの目で見てこれたのが一番のハイライトと言える。
どうも、この２つの旅行で仏教については「やるだけやった」感が出てしまい、探究心が急降下してしまった。
とはいえ信仰が無くなるとかそういうことではなく、あとは実践あるのみ、と踏ん切りがついたというべきか。

来年については、引き続き減量を続ける。一応BMI標準が目標だが、いけそうなら70kgを少し切りたい。医者からは「40歳になるまでに学生時代の体重に戻さないと大変なことになるよ」と脅されているが、大学時代のみならず高校時代まで含めれば、67kgあたりまで削れたときがある。よって、そこまで削れればこの上ない成果といえる。が、まぁそもそも今のトレーニングは「太った脂肪を落とす」内容なので、標準体重まで到達した後にさらに脂肪を落とすのがどれほど健康やトレーニング内容に影響するか、そのときにまた検討することになるだろう。

標準体重到達前後から婚活も再開したいし・・・。

仕事については今の所モチベーションは保たれている。が、さすがに今年は一つのアプリ開発に没頭しすぎたので、来年は別のアプリ開発や、仕事で必要なインフラ周りの拡張作業、あとはレガシーのクリーニングなどでちょっと趣向を変えて仕込みの年にしたい・・・できるといいなぁ・・・というところ。

あまりプライベートタイムを費やして新しいアレコレに挑戦しよう、という欲は無い。仕事と趣味のオーバーラップ領域が多いので、仕事で必要になったことを趣味とプライベートタイムに昇華させるサイクルをうまく嵌め込んで行ければいいなぁ、という感じ。新しい言語やFWにアレコレ手を出すというよりは、仕様とか実装の調査などが多くなりそう。また、そもそも調べ物でお金をもらいたくて今の会社に入ったという面もあるので、仕事として調べ物が必要となればまさにそれこそが趣味の実践となる。

そんな感じで、来年は肩の力抜いてく感じで。

使い方とか、雰囲気などわかる参考URLのメモです。

• ログ収集ツールの比較 - Qiita
  • https://qiita.com/kazookie/items/eef3071a0667cb4d5136
    • Fluentd, Logstash, Apache Flume, Apache Kafka の紹介。
• ログ収集系の個人的まとめ - Qiita
  • https://qiita.com/zuzu0301/items/d2b46c817d97f330d91d
    • 収集 : Fluentd, Logstash, Apache Flume / 集積 : Elasticsearch, InfluxDB, MongoDB / 解析・ダッシュボード : Tableau, Kibana, Grafana の紹介。

Fluentd関連参考

• 柔軟なログ収集を可能にする「fluentd」入門 | さくらのナレッジ
  • https://knowledge.sakura.ad.jp/1336/
• Fluentdとログ収集のパターン - Go ahead!
  • http://repeatedly.github.io/ja/2014/07/fluentd-and-log-forwarding-patterns/
• Fluentdで各サーバからログ収集し、1箇所に集約してS3ログやElasticSearch Serviceに転送 - Qiita
  • https://qiita.com/hayashier/items/b20a909fc94a9579bfa0
• td-agent(Fluentd) を利用したログ収集 - ユニファ開発者ブログ
  • https://tech.unifa-e.com/entry/2017/01/19/194052

Embulk : Fluentdと開発者が同じで、Fluendtがstreamなら、Embulkはbulk転送。

• 【Embulk】使い方あれこれ - Qiita
  • https://qiita.com/da-sugi/items/13d4ead19c86d783ebb4
• Embulkについてまとめてみた　2017/08 - Qiita
  • https://qiita.com/tashiro_gaku/items/f7fa0f1a99c759d947a7
• 大量データの転送にEmbulkを使ってみたら本当に楽だった - VOYAGE GROUP techlog
  • https://techlog.voyagegroup.com/entry/2017/07/31/173839
• Embulkの使い方メモ - Qiita
  • https://qiita.com/reflet/items/812d6a5a436862e26f19

なお、Datadog/Mackerel/NewRelic はログ収集ではなくてモニタリングサービス(メトリクス収集など)なので、データ・ログ収集とは全然違う分野のサービス群。
参考：

• モニタリングサービス（Mackerel、Datadog、New Relic）入門！ - Qiita
  • https://qiita.com/uzresk/items/fa58720acbe7672607c9

Glamenv-Septzen : ぐらめぬ・ぜぷつぇん

msakamoto-sf こと 坂本昌彦 によるプログラミング技術を中心としたブログ兼Wikiです。

Twitter: @msakamoto_sf

GitHub:

• https://github.com/msakamoto-sf/

Qiita:

• https://qiita.com/msakamoto_sf

使用しているツールの制約上、コメントやトラックバックは受け付けられません。
本コンテンツへのご意見もしくはコメント投稿用アカウント申請については、Eメールにて下記アドレスまでご連絡下さい。

sakamoto.gsyc.3s@gmail.com

なお、2001 - 2003年にかけて作成し、Niftyホームページ上にて公開していたコンテンツについては以下を参照して下さい。(*1)

風晶のＣ言語プログラミング

https://www.glamenv-septzen.net/nifty/index.html

2010年頃作ってた英語出張版

https://www.glamenv-septzen.net/en/

msakamoto-sfのプロフィール

本名

坂本昌彦, 1981年生まれ

出身地

千葉県香取市(*1)

主に使うプログラミング言語

PHP, Java

PHPは趣味です。仕事ではJavaをメインとして雑食性です。C(Windows, UNIX)/VB/Ruby/Perlなどの使用経験が有ります。

• 2004/04 - 2009/07 : 東京都立川市内のソフトハウスでPGとかSEなどに従事。
• 2009/09 - 2009/12 : 東京都内にてポータルサイトの開発に従事。
• 2009/12 - 2011/05 : 無職
• 2011/05 - : 東京都内のWebアプリケーション脆弱性検査業務に従事。

GitHub:

• https://github.com/msakamoto-sf/

Qiita:

• https://qiita.com/msakamoto_sf

XhwlayというPHPライブラリと、このサイトでも使っているYakiBikiというWikiクローンをマイペースで開発しています。

• Xhwlay : https://github.com/msakamoto-sf/xhwlay-php
• YakiBiki : https://github.com/msakamoto-sf/yakibiki-php

座右の銘

BRAIN VALLEY (瀬名秀明, 角川書店), 下巻 382p(ハードカバー版)より：

この世で最も厄介な人種は科学者だ。
精神は小学生より幼稚であるにも関わらず、人一倍プライドと体面を気にかける。
彼らは決して社会に出してはいけない。
山奥に隔離し、ふんだんな機材と試薬と実験動物を与えて飼い慣らすに限る。
そして時々、お前が世界で一番偉いのだと声をかけてやるのだ。
そうすれば１００年に一度くらいは有益な成果を上げるかもしれない。
だがいずれにせよ、愚かで小賢しい存在であることに変わりはない。

本書中に登場する、とある人物からの視点。
「科学者」→「プログラマ」なり「SE」なり「IT技術者」なり「ギーク」なりに置換する。
トラウマ級に精神に刻み込まれた、戒めの言葉。

読んだ本

読書 参照

好きな絵師

• 智内兄助
• 清原啓子(銅版画)
• 松井冬子
• 冬目景(漫画家)

2017年10月頃から、近所のコナミスポーツクラブのジムに通い始めた。

• 2017年10月～ : 6週間のダイエット・トレーニング("バイオメトリクス"), 週三回, 毎回30分くらい, 93kg -> 89kg
• 2018年12月～2月くらい？ : 4週間の筋肉強化トレーニング("V-BODY"), 週二回, 毎回30分くらい
• 2018年3月くらい？～7月 : トレーナーとのマンツーマントレーニング("パーソナルトレーニング"), 週一回, 毎回30分くらい

最初のダイエット・トレーニングでなんとか90kgを切れたが、その後のトレーニングは筋力強化のため、体重は減っていない。トレーナーのその時点でのおすすめとしてはダイエット・トレーニングの後に筋力強化に進む人も多いとのことだったし、筋力強化系のトレーニングはやったことなかったので、実験目的で挑戦してみた。

体重についてだが、2018年前半で数回福岡出張に行ってそこで散々飲み食いしてしまったため、2018年5月頃に92kgまでリバウンドしてしまった。
その後、6-7月にかけて91kgくらいまで戻せたが、91kgを下回らない日々が続いている。

全体的な感想としては、どうも筋力強化が思ったよりも体に負担がかかってしまい、まずはダイエット・トレーニングが先のようだと感じている。

というのも、5月くらいからパーソナルトレーニングで体幹トレーニングを取り入れてもらったのだが、これがかなり汗だくで、暑くなってくる6月くらいから、トレーニング終わったあとは精根尽き果てた状態になっていた。暑くなってくるとジム内も冷房が入るが、この冷房の風が汗だくの体に堪える。
日によってはトレーニング終了後は悪寒や震え、頭痛などでグロッキー状態になったこともあった。

しかも、トレーニングが終わったあとに筋肉痛とともに、頭痛に襲われるようになった。これは筋力強化のトレーニングのときからも時々あったのだが、何が弱るかというと、土曜日にトレーニングに行ったあと、日曜日が筋肉痛と頭痛により、最低限の買い物以外は基本、家で寝込むかアニメ見て終わり、という状況になってしまった。読書やプログラミングなどの活動が全くできない状況だった。

ついには、7/28 の昼間のトレーニング終了後にどうにも悪寒が止まらず更衣室でうずくまってしまい、救急搬送されるに至った。（救急車が到着する頃にはもう大分回復していて、病院で点滴打ってもらったらすぐ帰れたのは幸いだった）

心配したトレーナーにより、8月一杯は強度を落として弱めのトレーニングに切り替えてもらい、それによりトレーニング後の頭痛も無くなった。

また、体幹トレーニングを導入した5月くらいから、トレーニング前に測っている血圧が高めになっているのもトレーナーから指摘された。どうも、体幹トレーニングだと「踏ん張る」動きが多くなる都合で、血圧が高くなる傾向があるらしい。（個人差もあるようだし、自分の場合、高くなるといっても最高140くらい）

そのため強度を落とすとともに、体幹トレーニングも5-7月まで3種目くらいやっていたのを、0か、1種目程度に変更された。

結果、8月一杯の血圧を見てみると少しずつ最高血圧が低くなっているので、やはり体幹トレーニングが血圧を高める一因の可能性が高いようだ。（全体的にトレーニングの強度を弱めてるので、体幹トレーニングだけが要因とは言えない。また、そもそも夏の暑い中をジムまで移動して、その後数分の着替えで急な冷房で体が冷やされるので、その影響も考慮したい）

救急搬送の次の週にトレーナーと今後のメニューについて打ち合わせしたときに、前述の体幹トレーニングと血圧の関係を聞かされた。また、念の為医者に相談してもらうようトレーナーから言われたため、近くの糖尿病・高血圧など成人病メインの内科クリニックにでかけて健康相談をした。医師からは、筋肉強化よりは減量を進められた。血圧についてはまだ薬が必要なほどではないとのこと。ただ、血圧についてはジムや病院などだとどうしても緊張状態が入ってしまい、平常時の血圧にはなりづらい。なので、家で毎日測ってみてね、と言われたので3千円くらいのシンプルな血圧計を買ってみて、なるべく毎日、朝と夜に測るようにしてみたところ、なるほど、確かにジムで測るよりも若干低い値になっていた。

ということで、そのへんもトレーナーと共有してみて、ここはやはり減量だろうということで、9月からまたダイエット・トレーニングを始めてみた次第。

ここまで1年ほどジムで有料トレーニングを受けてみたが、90kg台の体重の状況では、やはり減量トレーニングが最も優先すべき事項であり、また効果も出やすいようだ。

一方で筋肉強化については体重90kg台の状況ではあまり意味が無かったようにも思える。というのは、もともと筋肉を使わない日常（デスクワーク）なので、トレーニングをしないとあっという間に筋肉が落ちてしまう。
実際、救急搬送された次の週に体脂肪率を計測したら、筋肉量が28kgと出て、その後トレーニング強度を下げて1ヶ月経ち、ダイエット・トレーニング開始時にまた体脂肪率を測定したら筋肉量が 27.7 kg まで300g落ちていた。これは2018年最初にやった筋肉強化トレーニング4週間コースの1回分で増量した分に等しい。

つまり、自分の今のライフスタイル・ワークスタイルにおいては「日常に支障が出ない範囲のトレーニング(救急搬送後の8月のトレーニングレベル) 」では、「血圧や日常に支障が出るレベルのトレーニング」でつけた筋肉が消えてしまう、ということになる。

言い換えると、血圧や日常に支障が出るレベルのトレーニングで増量した筋肉は、その後の血圧や日常に支障が出ないレベルのトレーニングでは維持できない。（少なくとも2018年前半の自分の体では）

言い換えてみれば「そりゃそうだ」という話で、成長期ならいざ知らず、思春期～成人までを通じて運動嫌いで運動らしい運動をしてこなかったメタボの30台後半なのだから、たかだか半年ほどで増量した筋肉がそう楽に維持できるものでもない。

実際、今日はこうしてブログを書けているが、5～7月の救急搬送まで、土曜日のトレーニングのあとはグロッキー状態でブログを書ける状態ではなかった。そこまでして増量した筋肉が、「体に無理のない」トレーニング1ヶ月で300gも消えてしまうのだから、これはもう、無理筋というものだったのかもしれない。

ということで、兎にも角にも減量最優先という戦略に切り替えてまた少し実験を続けてみて、自分の体がどう反応するか？特に、去年のダイエット・トレーニングでは、それまでジムに行ってなかった状態で始めたが、今年は1年ほどトレーニングに慣れて筋肉も一応増えた状態で始まるので、それでどう違いが出るかを検証してみたい。

2018-07-15, 16 と、青森県むつ市の霊場恐山に一泊二日でお参りというか観光してきた。

7/14-15 : 往路は八戸に前泊

東京から八戸までは東北新幹線で3時間と少しで本数も多いのだが、問題は八戸～JR下北駅と、JR下北駅～恐山にある。
JR八戸駅～JR下北駅は青い森鉄道と途中の野辺地からの大湊線になるが、これが本数が少ない。2時間程度に1本。
さらにJR下北駅～恐山のバスも2-3時間に1本。
つまり、待たずに乗り換えというのが相当難しい。乗り継ぎが上手くないと、八戸か下北駅で1-2時間はたっぷり待つことになる。
いずれも時刻表はインターネットで公開されている。それをもとに恐山から逆算していくと、15日中に東京から恐山まで移動するとなると途中トラブルによる遅延バッファが確保できなくなる。
（ちなみに羽田～青森でJALの空路という手もあったが、検討が間近だったためか片道だけで3万数千円となり、新幹線往復に匹敵する金額となった。お財布事情から空路は断念）

恐山自体は観光スポットとしては徒歩45分～1時間程度で見て回れる。宿坊「吉祥閣」にも泊まるので、恐山到着日は帰りの時間は考慮しなくて良い。
とはいえ、歩き回る疲れなども考えると少し余裕を持ちたい。つまり、恐山には夕方遅くではなく、昼過ぎ頃には到着したい。
そうなると、東京を相当朝早くに出ないとバッファ込みで乗り継げなくなる。

そこで今回は思い切って、14日に八戸に前泊することにした。
厳密にはJR八戸駅ではなく、そこから八戸線で2駅の「本」八戸駅近くのビジネスホテルに前泊。
これなら、14日/15日とかなり余裕を持って動ける。
ついでに八戸の海産物なども食べられそう。

ということで、7/14の 15:20 東京発はやぶさ27号に乗り、無事 18:13 JR八戸駅到着。その後 18:22 にJR八戸駅発の八戸線、鮫・久慈方面の下り列車で二駅、18:30に本八戸駅に到着。
どうやら新幹線停車駅の「八戸」よりは、「本八戸」の方が市街に近いらしく、本八戸駅から徒歩数分で八戸市役所があり、さらに徒歩数分でホテルや飲食店が賑わう街なかに出る。
その日はそこのビジネスホテルで宿泊した。
ホテルの1Fに居酒屋があり、そこのお食事券付きのプランだったので夕食をそこで食べて、ウニとかイカとか美味しかったです。

明けて 7/15 は 09:32 に本八戸駅発、09:41 に八戸駅着。そこで少し小休憩したのち、10:51 八戸駅発 JR快速リゾートあすなろ下北1号・大湊行に乗る。
ここから、三沢を経て野辺地、野辺地から大湊線でひたすら下北半島に向けて列車に揺られる。
12:34 にJR下北駅到着。ここで、恐山が開山している5月～10月は上記の快速リゾートあすなろの時間に合わせてバスが増発してくれてて、12:45 恐山行きのバスにそのまま接続できた。
無事 13:30 頃恐山到着。

ちなみに、恐山の途中に「冷水」という停留所がある。ここは山の清水が湧き出ていて、飲むと寿命が延びるとか。
停車ボタンを押す人はいなかったんですが、運転手さんは勝手に停めて、「どうぞ降りて、観てってください」とサービスしてくれました。
自分含めて12,3人くらいの乗客でしたが、みんな湧き水を味見してました。

7/15 : 恐山宿坊「吉祥閣」に1泊

恐山：
http://www.mutsu-kanko.jp/guide/miru_01.html
862年開山、当初は天台宗の修練道場。現在は曹洞宗。

恐山温泉宿坊 吉祥閣：
http://mutsu-kanko.jp/guide/osorezan_annai.html
https://www.aptinet.jp/Detail_display_00004276.html

恐山ですが、聞きしに勝る風景。漂う硫黄臭。そこかしこに積まれた石、宇曽利湖に吹き下ろす風でカラカラ回り続ける風車。
硫黄を含んだ蒸気が吹き出ているポイントも数箇所ありました。
（夜に法話をしてくれた院代によると、昭和30年ごろはもっとそこかしこで蒸気が吹き出てたらしく、近年は大分落ち着いてるとのこと。）
火山特有の軽石が大量に転がっており、賽の河原に見立てて、石を積んだ山があちこちにあります。
お地蔵様や観音様の石像・お堂もあちこちにあり、昨日今日買ってきたばかりと思われるようなお菓子などが沢山お供えされてました。

イタコさんとは会いませんでした。というのも、恐山にイタコが集まるのは 7/20 頃と10月の体育の日前後に開催される大祭にあわせており、自分が行ったのはその1週間前で、まだイタコが集まってなかったのです。
（明けて 7/16 には、イタコさんが小屋を立てたりして準備を始めてました）

ここで恐山とイタコさんの関係ですが、恐山自体は現在は曹洞宗の「恐山菩提寺」が管理してます。お寺自体はむつ市の市内にあり、雪解けする5月～10月の間に「霊場恐山」に出張してるような状況。
イタコさんの方ですが、もともとこちらは東北地方に根付いている民間のシャーマン（巫女）で、普段は地元でひっそりと自営業的にやってるそうです。
恐山の大祭に合わせて、縁日の出店じゃないですが人が沢山くるので営業チャンスとばかりに恐山に集まって、死者を降ろす口寄せを行う。
曹洞宗の方は、基本的にはイタコさんについて特に管理もせず、くるもの拒まずで受け入れてるだけで、特にイタコさんの営業窓口とか管理的なことはしていません。要するに無関係。
ところが、お寺さんに掛かってくる電話の8割近くがイタコさんに関わる電話とのことで、「恐山＝イタコ」の図式は中々覆し難いようでした。

特筆すべきは、硫黄臭漂う火山ならではの温泉。境内には4箇所の温泉小屋が建てられていて、男湯・女湯・混浴それぞれあり、入浴することができます。
硫黄成分が強いため長湯は推奨されてません。数分～10分程度までとの注意書きが貼られてます。
真水のシャワーなどは無いので、その点も注意が必要です。
宿坊の大浴場なら真水・お湯のでるシャワーがありますが、そちらは宿泊者専用となっています。

温泉入ってみましたが、ポカポカで気持ち良かったです。
硫黄臭が強く、温泉を出てからもそうですが、温泉卵食べたいな～と滞在中ずっと思ってました。

宿坊の方は、曹洞宗のお寺ということもあり、食事はみんな揃って精進料理。食べる前と後にみんなでお唱えします。
ご飯のあとは、恐山菩提寺の院代（住職代理）を務める南 直哉氏の法話を1時間ほど聞くことができました。
全く不勉強で予備知識無しで聞いたのですが、インタビューや著作活動、座禅と仏教の議論などで大変有名な方で、思いもかけずそのような方の法話を聞くことができてラッキーでした。
ブログで恐山や仏教などについて記事を沢山書いてる人でした：
「恐山あれこれ日記」 https://blog.goo.ne.jp/jikisaim

内容も面白く、笑いを誘いつつも所々でドキリとさせるようなツッコミを入れてくるなど、1時間があっという間に過ぎました。

その他、参考にした宿泊レポート：

• https://gurutabi.gnavi.co.jp/a/a_1252/
• http://simokita.org/sight/osore/
• http://www.geocities.jp/la_valise_m/hotel/08_hotel_kissyoukaku.html
• http://www.geocities.jp/oyu_web/t348.html
• http://peepar.net/osorezan

7/16 : 朝のお勤め

宿泊者は朝6時半からの朝のお勤めに参列。
驚いたことに、早朝にもかかわらず宿泊者以外の方も参列していた。
地元の方か、あるいは遠方からはるばる車で来られた方たちのようだ。

朝のお勤めで驚いたのは、般若心経の読経で、和太鼓をドンドコドンドコ早めのビートを刻みつつ唱えていた点。
これがお堂に響き、まるでラップのビートのように一気に般若心経の読経が終わった。このような読経には初めて遭遇した。

その後お堂を移ってそちらでもお勤め。こちらは卒塔婆供養などで卒塔婆を頼んだ人たちも参列しており、お勤めが終わったあと、卒塔婆を配っていた。
宿泊者の中にも、年配の方が何名か卒塔婆を受け取り、外の卒塔婆建てるところに持っていっていた。
その後朝食（精進料理）を食べて、解散。

帰りが問題で、恐山発のバスは 10時からあるが、10時発だと下北駅が10:45着となり、八戸行きの電車は 14:11 下北駅発からとなって数時間待つ羽目になる。
10:26発の八戸行に乗れれば楽だが、バスではどうしようもない・・・
ということで、宿坊の人にお願いしてタクシーを呼んでもらいました。恐山からJR下北駅まで、タクシーで 4,350 円でした・・・。
（他の宿泊者はみんな、マイカーか 13時恐山発のバスみたいで、タクシーは自分一人だった）

そこで 10:26 発の八戸行に無事接続、12:30には八戸駅に到着できました。

新幹線は 16:16 八戸駅発のはやぶさ30号を予約していたので、大分時間が空きました。
そこで、せっかくなので八戸駅から100円バスで行ける「八食センター」に行ってみました。
https://www.849net.com/

八戸の海産物などが集まる市場で、観光客向けの食堂やお土産も沢山売ってます。
ホタテ、牡蠣、ウニ、ホヤ、イカ、サバ、ほっけなどが沢山並んでました。食堂でも食べてみましたが、大変美味しかったです。
ちょうど連休ということもあり、家族連れ・親子連れで賑わってました。

海産物を堪能した後、100円バスでまた八戸まで戻り、お土産など買って 16:16 八戸発のはやぶさ30号で 19:04 東京到着、帰宅しました。

感想

2013年に高野山・比叡山。
その後2-3回ほど京都旅行の機会があり、都度あちこちの寺社を巡り、東西本願寺・真言宗・臨済系のお寺参り。
2016年に身延山（日蓮宗）、福井の永平寺（曹洞宗）。
そして2018年に恐山と、ついに日本仏教三大霊場を制覇、さらに主要宗派の本山系をお参りできた。

東北地方では、死者の魂は恐山に集まるという信仰が根付いている。
そのため、恐山に来ることで死者と対話できる（物理的な意味ではなく、多分、それぞれの心の中で）。
自分の場合、特にそうした信仰ベースがなかったこともあり、恐山に来てみて、亡くなった親族が「いる・ある」ような感覚は感じなかった。
しかし、自分は感じないものの、積み重ねられた膨大な小石の山。そこかしこの地蔵・菩薩像に山のように積まれた供物。石に彫ってある死者の名前。
死者に関する膨大な思念が、恐山という場所に凝縮されていることは確かに感じた。

恐山が最初に開山したのは、890年代に天台宗による。その後、紆余曲折があったらしく今は曹洞宗管理となっている。
念仏、浄土、真言などのツールを持たず、臨済とも違い、「ただ坐る」を極限まで煮詰めた曹洞宗だからこそ、膨大な死者への思いを受け止める・・・というか、うまく恐山そのものへ素通しできているのではないかと、そんなことを感じた。
なんというか、恐山への思いは、念仏とか浄土とか真言などの仕掛け・設定・方法論で味付けできるようなものでもないし、それが助けになるような代物でもない気がした。
「恐山に行けば、亡くなったあの人と会える・話せる、感じることができる」という世界観に対して、そうしたツールは余分でしか無い。
生と死に禅という形で体当たりしてきた曹洞宗だからこそ、参拝者の中の恐山への想いをあるがままに昇華させられるのではないか。
そんなことを考えた。

三大霊場はそれぞれ特色があった。以下は個人的な見解。

• 観光第一は高野山。紀州の山奥だが、周辺の観光スポットも多く、寺域も観光色を強く出していて、観光しやすい。
• 交通の便第一は比叡山。京都から1時間ほど観光バスに揺られるもよし、車の便も良し。
• 峻厳第一が恐山。観光スポットでもないし、交通の便も悪い。たとえ観光で訪れたとしても、「今、そこ」の死者への想いに圧倒されることは確実。

恐山は２つの意味から、「終点」だな、と感じた。
1つは、霊場としての日本仏教の北端であること。膨大な思いが集まる霊場・寺域としてはおそらく日本最北であり、東北の地元にがっつり根を下ろしている。
2つは、生死の終端であること。これはもうそのままで、「死ねば恐山に上る」とまで信仰されてる以上、死の終端になっている。

恐山は単なる観光スポット・奇景スポットではない。今、同じ時間を生きる人達の、死者への思いがリアルタイムに染み込んでいく。同じ空気を吸う。
つまるところ、今なお運営され続けている墓地・霊園と同等に感じる。
それが、観光スポットとして強く押し出されている他２つ・高野山、比叡山との大きな違いに感じた。

ようするに観光色薄め、真面目な場所でした。

ちなみに、心霊現象とか幽霊の話は、無いそうです。
実際行ってみて、「幽霊になったとしてもこんな場所に長居したくねーなー・・・」と思うほどの荒涼とした場所。
そんな場所で、そこかしこに地蔵・菩薩像があって新しいお供えが供給され、毎日毎日読経されてりゃ、むしろ幽霊となって恐山に留まる方が難しいのでは・・・とすら感じました。
もうね、地蔵や観音菩薩によって、即成仏ですよ。幽霊となってあの場所に出た日にゃ。

2018-04-30 から 2018-05-04 まで、4泊5日で奈良エリアの遺跡・寺社仏閣を回ってきた。
主な目的：

• 聖地巡礼 :「火の鳥」ヤマト編/鳳凰編、「三つ目がとおる」(酒船石遺跡)、諸星大二郎「暗黒神話」(亀石など)、山岸凉子「日出処の天子」(飛鳥・斑鳩エリア)
• 仏教伝来～奈良仏教が興った場所を実際に行ってみて、仏像や寺などの物見遊山。

結果として、奈良旅行におけるメジャーどころをほとんど巡ることができた。
行ってないのは、石上神社～三輪神社の山の辺の道エリアだが、三輪神社については学生時代に行ってるのと、今回は仏教の「起点」を見に行くという目的なので外した。
（じつは大学3年か4年に、古事記や同様に三つ目がとおる・暗黒神話系をテーマに奈良、特に飛鳥エリア・三輪山エリアは回っている。今回は仏教の起点テーマなのと、折角なので飛鳥エリアをもう一度回って、写真撮ってみたい、という目的）

5日間、延々と歩き回って寺を回って、しばらくお寺参りは行きたくない位に回り尽くした。

• [ Prev ]
• [ Next ]
• [ Java ]

Javaの「セキュリティ機能」は複数の異なる領域をカバーしている。そのため、ドキュメントの迷子にならないよう、ざっくり整理した。
(2018-01時点のJava8ドキュメントをベースに整理した)

Oracle Java 開発者ガイドからの入り口

• https://docs.oracle.com/javase/8/docs/technotes/guides/security/index.html
• https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/index.html

Javaのセキュリティ機能の分類

一口に「セキュリティ機能」といっても、暗号化, PKI, SSL/TLS という「いかにも」な機能から、認証機能、アクセス制御、XML署名というニッチな機能もカバーしている。

• Java™ Security Overview
  • https://docs.oracle.com/javase/8/docs/technotes/guides/security/overview/jsoverview.html
  • https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/overview/jsoverview.html

概要ドキュメントをベースにしつつ、歴史的な経緯や正確性を無視してざっくり3分野に分けた。

1. 暗号技術をベースとした機能群

JCA : Java Cryptography Architecture, 暗号技術の各種アルゴリズム実装を提供する共通基盤アーキテクチャで、以下のような機能を提供している。

• MessageDigestアルゴリズム
• デジタル署名アルゴリズム
• 対称鍵暗号(ブロック/ストリーム暗号)
• 非対称鍵暗号(公開鍵暗号)
• パスワードベース暗号化(Password-based Encryption)
• 楕円鍵暗号(Elliptic Curve Cryptography)
• 鍵合意アルゴリズム(Diffie-Hellman等で使う)
• Key Generator
• メッセージ認証コード(MAC : Message Authentication Code, HMAC : Hashed MAC)
• 乱数生成器, 擬似乱数生成器(PRNG : Pseudo Random Number Generator)

JCAをベースとしたセキュリティ機能としては、PKI, 通信経路のセキュリティ, XML署名を提供している。

公式ガイド：

• https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html
• https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/crypto/CryptoSpec.html

PKI : 公開鍵インフラストラクチャ

暗号技術のうち、公開鍵暗号とデジタル署名をメインとした応用技術。
鍵および証明書ストレージ, PKI用コマンドラインツール(keytool, jarsigner)を提供している。

公式ガイド：

• X.509証明書とCRLについてのざっくりガイド
  • https://docs.oracle.com/javase/8/docs/technotes/guides/security/cert3.html
  • https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/cert3.html
• 証明書パス(「証明書チェーン」)を扱う Java Certification Path API
  • https://docs.oracle.com/javase/8/docs/technotes/guides/security/certpath/CertPathProgGuide.html
  • https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/certpath/CertPathProgGuide.html
  • (証明書パスの扱いメインなのに、中身のタイトルが"Java PKI Programmer's Guide"となっているのが微妙に納得行かない)

通信経路のセキュリティ

暗号技術を活用した通信経路(プロトコル)のセキュリティを実現する。

公式ガイド：

• JSSE : Java Secure Socket Extension, SSL/TLS機能を提供する。
  • https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html
  • https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/jsse/JSSERefGuide.html
• SASL : Simple Authentication and Security Layer, アプリケーション間の通信における認証フレームワーク。LDAPv3やIMAPv4などで使われている。
  • https://docs.oracle.com/javase/8/docs/technotes/guides/security/sasl/sasl-refguide.html
  • https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/sasl/sasl-refguide.html
• GSS-API(Generic Security Service Application Programming Interface)
  • (理解不足。実装非依存でアプリケーション用セキュリティ機能を提供するAPIらしい。ここに分類して良いのか不明。)
  • https://tools.ietf.org/html/rfc2078
  • https://tools.ietf.org/html/rfc2743
  • Oracle 公式開発ガイドからは、セキュリティトップから「Java Generic Security Services (Java GSS-API)」を参照のこと。

XML署名

XML署名の生成・検証用APIが提供されている。
公式ガイド：

• Oracle 公式開発ガイドからは、セキュリティトップから「XMLデジタル署名」,"XML Digital Signature" を参照のこと。

2. アクセス制御

どこからロードされたJavaクラスか、署名データなどを元に、JavaのAPI呼び出しやファイルアクセスなどに対するアクセス制御を実現する。
例としてはJava Appletやプラグインアーキテクチャがある。こうした「信頼できないコード」に対して、 `System.exit()` を始めとした「危険な」(= 信頼できないコードをホストする実行環境から見た場合に、実行・アクセスしてほしくないリソース・機能へのアクセス) API呼び出しを制限するような場合に活用する。
"SecurityManager", "Permission"という単語が出てくると大体この分野の話。

公式ガイド：

• Oracle 公式開発ガイドからは、セキュリティトップから「ポリシー」(Policy)関連のトピックを参照のこと。

3. 認証機能(JAAS : Java Authentication and Authorization Service)

Kerberos, スマートカード, LDPA/NIS, PKCS11 などによるユーザの認証(Authentication)・承認(Authorization)フレームワークを提供する。
アクセス制御の中で、アプリケーションが認証したユーザに基づくアクセス制御(承認)を実現したい場合に活用する(らしい)。

公式ガイド：

• Oracle 公式開発ガイドからは、セキュリティトップから「Java Authentication and Authorization Service (JAAS)」関連のトピックを参照のこと。

Provider方式とプロバイダ名のメモ

• Javaセキュリティ機能の設計方針として、インターフェイスと実装の分離が特徴。
  • 設計思想としては、あるアルゴリズムや機能(=「エンジン」)・プロトコルについて複数のプロバイダから実装を提供することができる。
  • アルゴリズム・プロトコル名を指定する場合に、使用するプロバイダ名も指定することができる。
• 標準のアルゴリズム名、プロバイダ名についてはOracle公式開発ガイドを参照。
  • 標準アルゴリズム名
    • https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html
    • https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/StandardNames.html
  • (少なくともOracle Javaで利用できる)プロバイダ名
    • https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html
    • https://docs.oracle.com/javase/jp/8/docs/technotes/guides/security/SunProviders.html
    • 歴史的に、最初は輸出制限がかかっていたものが徐々に使えるようになっていった。そのため、Sun由来でも複数のプロバイダが提供されており、実装している内容がオーバーラップしてたり後に作られた方が充実してたりする。

感想

以下は筆者の感想。

• Webアプリケーションのサーバサイド開発でJavaを用いる場合は、主にJCA, SSL/TLS, PKI関連技術が用いられることになるだろう。
  • とはいっても、HTTPSの設定はApache/nginxなどリバースプロキシか、やってもTomcatなどのアプリケーションサーバ側の設定でカバーする場合が多くなり、これらの詳細な知識が求められる場面は少なくなってきたかもしれない。
  • 非常に古いJavaや、非常に古いシステムと通信する際に、手動でカスタマイズが必要となったりする。
  • SOAPなどXML通信を扱う場合はXML署名を使うこともありそう。
• 今では滅多にJava Appletで開発することが無くなった。アクセス制御や認証機能などは今はどんな領域で使われているのだろうか？
  • JenkinsやCMSのように、不特定多数の人間が信頼できないプラグインをロードしたり、JavaScriptのJava実装(Nashorn)やGroovyなどの動的JVMスクリプト言語を動かす場合のSandbox環境の構築で使われているのは確か。
  • ユーザが任意のコードを動かすデスクトップアプリケーションにおいては、Javaのアクセス制御機能で何を守るのかから考える必要がありそう。

• [ Prev ]
• [ Next ]
• [ Up ]
• [ Java ]

• [ Prev ]
• [ Next ]
• [ 技術 ]

Nmapの参考URLのメモ。

使い方と公式リファレンス：

• Nmap リファレンスガイド (Man Page)
  • https://nmap.org/man/jp/
• オプション概要
  • https://nmap.org/man/jp/man-briefoptions.html
• ポートスキャンの基本
  • https://nmap.org/man/jp/man-port-scanning-basics.html
• 清く、正しい、nmapの使い方
  • http://www.yk.rim.or.jp/~shikap/security/use_nmap.html
• Linuxコマンド集 - 【nmap】ポートスキャンを実施する：ITpro
  • http://itpro.nikkeibp.co.jp/atcl/column/14/230520/072800001/
• ポートスキャンツール「Nmap」を使ったセキュリティチェック | OSDN Magazine
  • https://mag.osdn.jp/13/04/01/140000

スキャンのパフォーマンス、特にUDP関連：

• ポートスキャンのテクニック
  • https://nmap.org/man/jp/man-port-scanning-techniques.html
• タイミングとパフォーマンス
  • https://nmap.org/man/jp/man-performance.html
• UDPポートのオープン状態が知りたい - ITmedia エンタープライズ
  • http://www.itmedia.co.jp/help/tips/linux/l0535.html
• network scanners - Increase speed in nmap UDP scan? - Information Security Stack Exchange
  • https://security.stackexchange.com/questions/52566/increase-speed-in-nmap-udp-scan

豆知識系：

• Nmapを検証してみました【NSE編】 – (n)
  • http://n.pentest.ninja/?p=32488
• Nmap 9つの真実
  • https://www.slideshare.net/abend_cve_9999_0001/nmap-9
• Nmapの真実
  • https://www.slideshare.net/abend_cve_9999_0001/nmap-61009153

• [ Prev ]
• [ Next ]
• [ 技術 ]

先週末に Fate/stay night UBW, 昨日今日の土日で Fate/stay night とシリーズ逆順で一気見したので感想。（ネタバレあり）