インド人同僚に贈る言葉

2020.01.31 に職場のインド人の同僚が最終出社日を迎え、たくさんの関係者が集まり見送りました。次は普段の会話が英語の、よりグローバルな環境で頑張るそうだ。

その人が入社したとき同じチームに所属していた自分が主に面倒を見ることになり、日本語を勉強中だった彼とのやり取りは、はたから見ればとても大変なものにみえただろうが、自分からすると楽しいやり取りが多かった

自分は英語が拙く、彼は訛りがあるものの英語はペラペラ

ちぐはぐな自分の英語を聞きながら何を伝えたいのか読み取る日々は、もしかしたら彼に大きな不快感を与えていたかもしれないとも考えていたが、彼はそんなことは感じさせないほどにいつも真摯に反応してくれた。

覚えたての日本語を使ってときおり自分に話をしてくれるのだが、「お盛ん」を誤って人に使ってしまったエピソードは今でも鮮明に思い出せる

自分と彼とで職場内のスペースでランチをしていると、通りかかる人がたまたま自分の知り合いばかりで、挨拶を繰り返すということをしていた。この光景を見て彼は「odajunさんはお盛んですね」と言ったのだ

最初は自分も戸惑ったが、よくよく話を聞いてみると、前日の日本語講習で

「人気だ(popular)」=「盛んだ」

といった表現を学んだということだった

しかしこれは対象が人以外で成り立つもので、人に使うとセクシャルな意味になるよとその場で笑いながら説明した。日本語は難しい

また入社した当時、ちょうど国勢調査が実施されるタイミングで、外国人向けの資料を見ながら記入方法とかを説明するというミッションはなかなか大変だった。他にも日本での生活に関すること、水道、電気などのインフラ周りの細かい契約の相談など、学んだことのない英単語を引っ張り出して何とか伝えるというのも、今思うとなかなか楽しい体験だった

今では日本語もペラペラで面白い冗談をいったりできるほど。チームは別々になってしまったが、人づてに彼の活躍は聞こえてくる

同じくインドからきた新人さんをフォローしたり、持ち前の英語力で海外のカンファレンスでカジュアルにいろいろな人と話してチームメンバーに有益な情報を日本語で解説しながらシェアしたり、言葉の壁を突破し大きくステップアップした彼はとても頼もしくなった

そんな彼も今の会社で働くのは今週限り

たくさんの感謝と新しい挑戦への激励を伝えられるだけ伝えたつもりではあるがうまく言葉になっていたかはわからない

本当にお疲れさまでした。その真摯な立ちふるまいで、また仲間をたくさんつくってください。そして、たくさん話しをしてくれて本当にありがとうございます。

近い将来、また「盛んだ」と言ってもらえるような人望のある存在になって笑いあえたら幸い

セキュリティのために実施したこと

EC2インスタンスにて実施したこと

サイトのために使用しているEC2インスタンスに対して、とりあえず以下の作業を実施したよというメモ

実施項目

  • 新規管理用アカウント作成
  • デフォルトアカウント(ec2-user)の削除
  • port22 以外での ssh port 用意
  • port22 の閉鎖
  • 一部の海外からのアクセス拒否

参考

WordPress Plugin

インストール・設定した項目

  • All In One WP Security & Firewall

項目一つ一つ確認して、必要と思われる項目についてチェックつけて実施している

参考

AWS EC2 WordPress Nginx 環境のSSL(https)対応

自身のサイトのSSL対応が思いのほか手間取ったので、その時の作業手順について記録しておく(2020/01/22 時点の作業記録)

作業開始時点の状況

以下のことができている状態からスタートしています

  • AWS EC2 でのインスタンス作成済み(1インスタンス)
  • WordPress でサイトの構築済み(投稿記事5程度)
  • 独自ドメインの取得・移行済み
  • GoogleAnalyst 導入済み
  • 環境
    • Amazon Linux AMI 2018.03
    • Nginx 1:1.14.1-2.34.amzn1
    • WordPress 5.3.2

上記の状態で特にロードバランサーや証明書などは用意していない状態から以下に示す手順で作業を実施

証明書の発行

証明書発行手順

まずはAWSのサービス中にある「 Certificate Manager 」から証明書の発行を実施します。「証明書のプロビジョニング」をクリック

「パブリック証明書のリクエスト」を選択して「証明書のリクエスト」に進む

ドメイン名の追加の部分で独自ドメインとドメインの前にアスタリスクをつけたサブドメインに対応する形のものを入力して「次へ」をクリック

  • 自身のケースの場合以下の2つ
    • odajun.work
    • *.odajun.work

検証方法の選択では、「DNSの検証」を選択して「次へ」をクリック

タグ名の入力では現時点で使用することはないので適当に入力。管理項目が増えてくるとタグの整理によって管理コストを抑えたりすることができると思われる。

確認画面で各入力内容が意図したものとなっていることを確認し「確定とリクエスト」をクリック

確定直後は各ドメインが検証中のステータスとなっている。ドメインの左にある三角ボタンを押して項目の expand 項目を表示させ、その中にある「Route53でレコードの作成」というのをクリックし、既存のホストゾーン中に対応するCNAMEレコードを作成する。これをドメインごとに実施する(検証中のまま続行のボタンを押しても同様の作業は実施できる)。

レコード作成後以下のように成功のステータスになる(数分時間を要する可能性あり)

ロードバランサーの作成

ロードバランサーを用いる理由

単独のEC2インスタンスに対してなぜロードバランサーが必要か?
ロードバランサーの役割は内包する機能にもよりますが、EC2のロードバランサーだと主に以下の3つの役割があるのだろうと思います。

  1. HTTP(S)リスナー層とEC2インスタンス層の分離により、EC2インスタンスのメンテしやすさ向上
  2. ロードバランサーからEC2インスタンスへのヘルスチェックを行い異常を検知・通知する
  3. SSL終端をロードバランサーまでとする

購買サイトなどを運営する場合は、1, 2 の機能は重要度が高いと思いますが、自身のケースでは、3 の重要度が高い。もしも SSLの終端をEC2までとした場合、OpenSSL関連のパッケージのインストール、更新などをインスタンスで実施しなければなりません。脆弱性が見つかったときは最優先で実施しなければならず結構大変なので、小規模なサイトであればSSLの終端をロードバランサーまでとするのが運用コストから見ても良いと思います。

ロードバランサー作成手順

AWSのサービスからEC2を選び、EC2の項目からロードバランサーを選択

「ロードバランサーの作成」をクリック、ロードバランサーの種類から「HTTP, HTTPS」を選択

 ロードバランサーの設定にて、デフォルトから変更した入力内容は以下の通り

  • 名前
    • lb-odajun-work (何でも良い)
  • リスナー
    • 「リスナーの追加」のボタンをクリックし、HTTPSを選択する
    • ロードバランサーのポートは自動で443が入力される
  • アベイラビリティゾーン
    • 作成済みのインスタンスを含んだVPCを選択し、表示されているアベイラビリティゾーンの2つ以上にチェックを入れる
    • アベイラビリティゾーンからパブリックサブネットを選択する

セキュリティ設定の構成にて、「ACMから証明書を選択する」を選び、証明書の名前に、前の手順で用意した証明書の名前が選ばれていることを確認する
また、セキュリティポリシーの選択はデフォルトのまま

セキュリティグループの設定では、「既存のセキュリティグループを選択する」を選び、対象のECインスタンスが含まれているセキュリティグループを選択する(画像撮り忘れた)

ルーティングの設定では、名前のところのみ lb-tar-group-odajun-work (何でも良い)と入力し、他の項目は変更しない

ターゲットの登録では、作成済みのインスタンスから、ポート80, 443の2つが登録された状態としておく

以上でロードバランサーに関する設定は完了

セキュリティグループの設定修正

自身の最初の作業においてこの部分が抜けており正常にアクセスできないとなったので忘れないようにかいておく。他のサイトにある手順に含まれていなかったりもしたので、自身のケースのみ必要だったのかもしれないが。。。

修正しない場合の状態について

1度目の作業を実施し終えた際にサイトが正常に見れない事がわかり、調査しているとロードバランサーのステータスが以下のようになっていた

リスナーとしてポート80を登録しているが、セキュリティグループの設定でポート80のインバウンドが許可されていないという状態だった
これをみてセキュリティグループの設定に手を入れていないことに気づいた

修正後のセキュリティグループ設定について

ロードバランサーにて設定したセキュリティグループのインバウンド設定、以下のようなHTTP:80, HTTPS:443 のリクエストを許可する内容となるように修正する

Aレコードにロードバランサーを割り当てる

AWSのサービスからRoute53を選び、ホストゾーン -> 独自ドメインのAレコードとクリック(このときAレコードに割り当てている IPアドレスを控えておくと、トラブルがあったときにすぐ戻せるので便利)
「エイリアス」が「いいえ」となっている状態から「はい」を選び、「エイリアス先」から作成したロードバランサーを選択

設定を保存したらサイトに http, https それぞれでアクセスし、ともに表示される状態であることを確認する。httpでは特に異常はなく、httpsでは表示崩れなどが発生している状態となっていれば想定通り。想定外の状態であれば、今までの設定について見直す

http から https へのリダイレクト

現状は http, https ともにアクセスでき、httpでアクセスされると http のままサイトが閲覧できる状態なので、httpでのアクセスが来た場合は、https にリダイレクトする設定を行う

wordpress.conf 中の location の上の行に以下の項目を追加し保存

$ sudo vim /etc/nginx/conf.d/wordpres.conf

server {
・・・・・・・・・・・・・・・・・
   if ($http_x_forwarded_proto = 'http'){
       return 301 https://$host$request_uri;
   }
   location / {
・・・・・・・・・・・・・・・・・
 }

nginx の再起動を実施

$ sudo service nginx restart

https は先程と同じく表示崩れを起こした状態で変わらず、http でリクエストすると、URLが https にかわり同じく表示崩れを起こした状態となっていれば想定通り

DB中の設定修正

独自ドメインへの移行時と同様に、DB中に http://で保存された設定があるのでこれを修正する

mysql> update wp_options set option_value = 'https://talesof.odajun.work' where option_name = 'home';

mysql> update wp_options set option_value = 'https://talesof.odajun.work' where option_name = 'siteurl';

SSL制限の設定追加

wp-config.php にSSLがonとなっているときは、管理画面の表示、サイトのログインは SSLを矯正する設定を追加する

$ sudo vim /var/www/html/wp-config.php

/* For HTTPS */
$_SERVER['HTTPS']='on';
define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);

/* define('ABSPATH', dirname(FILE) . '/'); よりも前の行に必ず設定する */

設定後は nginx の再起動を実施

$ sudo service nginx restart

ここまでの作業を実施した状態で https でサイトを確認すると、表示崩れなどは発生せず、管理画面にも問題なく遷移する状態となると思う(自身のケースではここまでで https リクエストについては問題なくできる状態となった)

Really Simple SSL の有効化

今までの作業と一部重複する機能でもあるが、抜け漏れのないようにプラグインを使用して SSL化を実施しておく

WordPress のプラグインから Really Simple SSL をインストールし有効化する
インストール時点で SSL化するに当たりなにか問題があれば、SSL化できない旨の表示が出る(画像撮り忘れた)

問題がなければ SSL化を実施する

この状態で自身のサイト情報で「接続が保護されている」といった表示が出て、Amazon から発行された証明書が使われている状態であれば問題なし

Google Analytics の設定修正

Google Analytics の設定では http を対象としていたため、これを https に書き換える

アナリティクスのページから「管理」-> 「プロパティ管理」とたどる

デフォルトURLを https に変更する

設定変更後、自身でサイトにアクセスした状態で、アナリティクスのリアルタイムのダッシュボードにおいて訪問中ユーザーがカウントされていることを確認できれば問題なし

おわりに

自身がSSL(https)対応としてまとめて実施した作業は以上です。
セキュリティという観点から見ればまだまだ実施しないといけないことはあるので、徐々に実施していこうと思います

作業をするに当たり他の方の作業記録とかを見たりしましたが、自身のケースとばっちり一致するようなケースはなく、とりあえずやってみてトラブったらそのときに調査といった手段しかなかったので少々難儀しました

この記録はわりと自身の備忘録として書いたので、参考にされる方がいた場合、必要な作業と微妙に異なるかもしれないのでお気をつけて。

参考

AWS EC2 WordPress Nginx 環境での TimeZone の変更

いろいろ調べてる中で access log のタイムスタンプが日本時間になっていないことに気づいたので対応した。その時の作業について記録する

date コマンドを叩くと UTC となっており、22日0時頃に実施したにもかかわらず21日15時とか指しているのが確認できる

$ date
Tue Jan 21 15:28:36 UTC 2020

まずは /etc/localtime を Tokyo の物を指すように修正

$ sudo rm -f /etc/localtime
$ sudo ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 30 Jan 22 00:29 /etc/localtime -> /usr/share/zoneinfo/Asia/Tokyo

この修正を crond 似反映させるため再起動

$ sudo service crond status
crond (pid  2825) is running...
$ sudo service crond restart
Stopping crond:                                            [  OK  ]
Starting crond:                                            [  OK  ]

ハードウェアクロックの時刻も合わせて変更しておく

$ sudo vim  /etc/sysconfig/clock
$ cat  /etc/sysconfig/clock
ZONE="Asia/Tokyo"
UTC=false

nginx の再起動の実施

$ sudo service nginx restart

date コマンドの内容や、access log の内容を確認し、時間が調整されていることを確認する

$ date
Wed Jan 22 00:35:48 JST 2020

$ sudo tail /var/log/nginx/access.log
****************- - [22/Jan/2020:00:40:56 +0900] ************

参考: https://itneko.com/linux-nginx/

くじびきボイロマッチ4位

Splatoon2 のボイスロイド作成者のみの大会に参加し4位になりました!!!!!

コケいろさんがスクスロでガンガン前線を上げて、MARUさんが後ろから的確に相手を射抜き、ボールドンさんが全体を見ながらインクアーマーやキルサポートなど縦横無尽に走り回り、頼もしい味方にキャリーされて予選リーグを見事突破。

決勝リーグでは惜しくも初戦で敗退してしまいましたが全体では4位と好成績を残すことができた。

自分は完全にマスコットやったな(;・∀・)

拮抗した試合が多く、逆転したり逆転されたりと熱い試合が多く、やってても見てても面白い大会だった

ボールドを使える人が揃ったということもあり、予選リーグではボールド4枚のガチホコが披露でき、圧倒的攻撃力を見せつけ勝利したことも印象深い。第2回大会を見た人にはっきりと記憶を植え付けることができたんではなかろうか。

大会が終わってから、自分がかなり足引っぱってしもうたという申し訳ない気持ちでいっぱいになった。ボールドを使うなら使うでもっと役に立てることがあっただろうに、辞めてた期間が悔やまれるばかり。

今後、同じような人たちとも楽しめるように、ほそぼそと続けて徐々にウデマエを上げていきたい所存。

くじびきボイロマッチ2運営Twitterアカウント

くじびきボイロマッチアーカイブ

既存wordpress の独自ドメインへの移行

すでにサービス稼働してパブリックなIPアドレスをURLとして使用している wordpress を、独自に取得したドメインに移行した

この作業において参考になる情報が少ない、または自身のケースと一致する事例があまり見受けられなかったので、備忘録として実施した作業などを記録しておく

独自ドメインの取得

ムームードメインより odajun.works というドメインを10年契約で購入(2019/08/28 ~ 2029/08/28, 9697円)

AWS の Route53で似たようなドメイン(odajun.works)を購入した場合は33,062円(30$/年, 投稿時レート1$=110.21円)なので比較的抑えた料金で用意できたのではないかと思う

料金体系がAWSと分離されてるので忘れないように注意。10年後の自分頑張れ!

Route53より取得済みドメインをHostZoneに追加

この部分の手順はこちらの外部資料の通りの手順なので記録としては割愛する

最終的にAレコードとしてサイトで使用する talesof.odajun.works のドメインが登録されており、このドメインからこのサイトのパブリックIPが辿れる状態となっていればよい

ここまでの作業で問題なければ https://talesof.odajun.works にアクセスすると nginx のデフォルトページに遷移する状態となる(まだブログのページは見れない)

wordpress 設定ファイルの修正

EC2 のインスタンスにログインし設定ファイルを修正する

/etc/nginx/conf.d/wordpres.conf
・・・
server_name talesof.odajun.work;  # このレコードの追記
・・・

設定を変更したら再起動

sudo service nginx restart

再起動後 https://talesof.odajun.works にアクセスするとブログのトップページが表示されるようになるが、「ログイン」などの内部リンクの先はIPのURLのままとなっている

wordpress DB中のアドレス修正

wordpress の設定の一部はDBに保管されており、サイトのURLについても合わせて保管されている

mysql> select * from wp_options where option_name = 'home';
+-----------+-------------+-----------------------+----------+
| option_id | option_name | option_value          | autoload |
+-----------+-------------+-----------------------+----------+
|         2 | home        | http://***.***.***.*** | yes      |
+-----------+-------------+-----------------------+----------+
1 row in set (0.00 sec)

mysql> select * from wp_options where option_name = 'siteurl';
+-----------+-------------+-----------------------+----------+
| option_id | option_name | option_value          | autoload |
+-----------+-------------+-----------------------+----------+
|         1 | siteurl     | http://***.***.***.*** | yes      |
+-----------+-------------+-----------------------+----------+
1 row in set (0.01 sec)

これらの値を独自ドメインへと変更する

mysql> update wp_options set option_value = 'https://talesof.odajun.work' where option_name = 'siteurl';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> update wp_options set option_value = 'https://talesof.odajun.work' where option_name = 'home';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

+-----------+-------------+----------------------------+----------+
| option_id | option_name | option_value               | autoload |
+-----------+-------------+----------------------------+----------+
|         2 | home        | https://talesof.odajun.work | yes      |
+-----------+-------------+----------------------------+----------+
1 row in set (0.00 sec)

mysql> select * from wp_options where option_name = 'siteurl';
+-----------+-------------+----------------------------+----------+
| option_id | option_name | option_value               | autoload |
+-----------+-------------+----------------------------+----------+
|         1 | siteurl     | https://talesof.odajun.work | yes      |
+-----------+-------------+----------------------------+----------+
1 row in set (0.00 sec)

この状態で再起動を実施

sudo service nginx restart

再起動後、 https://talesof.odajun.works にアクセスし、サイト内リンクが独自ドメインへと変更されており、サイトの編集なども変わらず実施できることを確認する

リアル麻雀・深夜の勢い記録

これは2020/01/13に実施されたリアル麻雀に関する記録である

当日の夜に勢いに任せてオダジュンの主観全開で書いているため、認識の齟齬などありうるということを念頭に置いて読んでほしい。多分正しい情報は wiki にて書かれると思うのでそちらも参照されるのが良いだろう

U-23サッカー日本代表がアジア代表を決めるグループリーグにおいて敗退が決まった日の翌日、日本中が成人式で賑わう中テイルズ勢雀士のしっぽら、あら、つしよ、オダジュンは2020年最初のリアル麻雀に興じていた

結果をまず書くと、あらさんが100を超える大きなプラスを叩き出し、つっしーもすこしではあるがプラスの結果となった。これに対して自分は最後の追い上げの甲斐あり10数点のマイナス、そして珍しく大きなマイナスを叩き出したのはしっぽらさん(正しい点数についてはwiki中の記録を参照されたし)。普段寝ていないことが正常であると豪語しているものの、9半荘という長丁場に集中力が持たなかったのかもしれない

まぁあの空間で集中力を維持することはほぼほぼ不可能ではないかと思っているのだが。。。

この日の麻雀において個人的に印象深かったのは、これでもかとドラがのったこと

役の半数以上がドラだったのではないかと思うほどのりにのり、自分を含めて周りを驚かせるようなことができたので点数以上に満足していたりする

しかもそれが自分含め3人がリーチをしているときにドラ単騎嵌張待ちで あがりをかっさらい、裏ドラも同じドラ表示牌となりドラが倍になったりしたらもう最高ですね

リーチツモ中の手配がカンアシストにより中がドラとなり、 リーチツモ中ドラ3と進化したときなんかは笑うしかなかった

ドラゴンロードは自分の前にできていたのかもしれない

迷言として加えられそうなのはガイアの派生

いろいろあったがつっしーの「ガイアが囁いた結果ダブロンになった」が特筆されるものであろう。まぁテ勢麻雀の中でのダブロンは安いが合わせて発動し致命傷にはならなかった

その他ではつっしーが点数の計算間違いをしたときのあらさんからの「よくも騙したなぁぁぁぁ!」、テ勢麻雀トロフィー激ムズ説、「とりあえず1回見逃して」の下りあたりをメモしている。後日wiki入りさせなければ(これ書いてる暇があれば入れられたのではという議論は今はおいておく)

勢いで書き始めたがそろそろ眠くなってきた。今は14日の0時45分、仕事いけんのかこれ?

そしてメインの飲み会・・・メインではないはずだが記憶の殆どが飲み会になってて麻雀の記憶が薄くなっている。それほどまでに飲み会の場が荒れたのだ。疲労感やばい(語彙力も失いつつある)

早すぎる入場により30分周辺を徘徊してからの開始となった飲み会、つっしーの靴紐話の前に、自分の何かしらの話が話題になったような気がしたが忘れた(足の骨折れた話だっけ?)

当初予定していたつっしーの蝶々結びの確認をしてみたのだが、まるで手品でも見せられたかのように、違和感はあるものの違いを具体的に指摘できないという状況に陥り、結果として次回集まるときに再確認となってしまった

つっしーの蝶々結びから、他にもなにか特徴的な違いがあるのではないかと皆で考えて出てきたのが「漢字の書き順」、このひらめきが悲劇を生むと誰が予想できようか。。。

人によって差がでるような(間違えやすい)漢字は何かと考え、自分がチョイスした漢字は「必」という漢字。詳細はwikiにゆずるが、この書き順で4人全員が異なる書き順を示すという奇跡が起きた。この漢字は5画からなり、書き方としては120通りあるとはいえ、4人全員が異なるという結果に全員が戸惑いを隠せない

そんな中で絶対的な自信を持っていたしっぽらさんではあったが、正しい書き順は自分が書いたものであり赤っ恥をかいてしまう。そこからは全員がドツボにはまってしまい、様々な書き順を書き比べた結果全員が重症を負う。全員の症状は以下の通り
・自信満々で間違いうまくマウントが取れないしっぽら
・そもそも漢字が正しくないあら
・自分の名前の書き順を間違ったオダジュン
・ことごとく自身の書き順が間違いであることに気付かされるつしよ

誰もが何を言っても惨めな状態というよくわからない状況ではあったが、リアル麻雀においてまたひとつ記憶に残る奇跡が起きたことは喜ばしいことと思いたい(これにより忘れられた記憶もあるかもしれないが)

時間も時間なのでひとまずここで筆を置こう。1時を超えて何をしているのだろうという疑問や、嫁に真面目に怒られるのではないかという不安もあるが、深夜にこれを書こうと思えるほどにこの日のリアル麻雀も楽しいイベントであった

またやりたぃぃぃい!

富士山登頂準備

2018/08 の富士山登頂の準備について自身の備忘録目的も兼ねて記録する

自分は未経験者だったので、宿の手配は経験者の友人がやってくれました。

なので、そのあたりの詳細については省きます。

泊まった宿は東洋館というところで

美味しいハンバーグ定食が夕食として出てきます。

合わせて、いなり寿司を翌日のお弁当として持たせてくれました。

持っていくものの準備について

自分は初心者で山登りの道具は何も持っていません

そのため、全面的に道具はレンタルしました。

レンタルしたのはやまどうぐレンタル屋

レンタルした内容はフルサポート12点セットで1泊2日手ぶら割
(15000円ぐらい)

受け取り場所は吉田ルート5合目店として予約

一緒に富士山に行った友人は初心者6点セットを選んでたりしましたが

砂埃などで結構汚れるので洗濯の手間を考えると
フルセットのほうがよいかも

ネックウォーマーやマスクのような口や鼻を覆うことができるものがあると砂埃が口にはいることを防ぐことができて有効

天気がいいと日差しが強いのでサングラスはお好みで

これ書いてる間に1年ぐらい経ってしもうたのでここまでで(=ω=;

富士山登頂(2018.08.17-18)

友人に連れられて、富士山に登ってきました

大学のときに行きたいと話はしていたものの、

行動に移せず月日が流れてもう社会人数年目

ここを逃すと今後チャンスがないと思い、思い切って登ることを決意

普段使わない太ももを酷使しつつ、雲の上からの風景を拝み、無事登頂

もう一度くるかもしれないので、今回の登山の準備などを

次回の投稿にて記録しておこうと思います。