"Why libp2p?" ざっくり目を通した
(ページ内にリンク切れが多すぎなんですが…ページ見つかればPR出します)
libp2p, P2Pネットワークのライブラリ。勉強しないとなーなんだけど、今日はちょっとMTG多すぎボンバーで余裕がなかったため大急ぎメモ(ただの翻訳・要約)。しかも、ライブラリのメリットだけにフォーカスするよー!
- モジュール性 - ニーズに合わせてネットワークスタックを組み合わせて使うことができる
- トランスポートの豊富な選択肢 - 色々なプロトコルに対応しているため、ランタイムやネットワーク環境も柔軟に選べる
- 汎用性 - ピアのディスカバリーやデータ保存・受信について様々な方法を使用できる。かつ多くのプログラミング言語で実装されているため柔軟である
- セキュリティ - ピアIDの検証や暗号化通信などの機能を持つ
- ロバスト性 - 堅牢であり、中断や障害などからも素早く復旧できる。攻撃のミティゲーションも備えている
- レジリエンシー - P2Pネットワークは分散により単一障害点がない。到達できないピアがあっても、ディスカバリーやルーティングが働いてネットワークへのアクセスを可能にする
- 効率 - 分散のおかげでリソースを効率よく使える。効率や拡張性を重視したデータの保存・受信方法が色々存在する
- NATの課題にアプローチ - NATトラバーサル機能があり、NATやファイアウォールの後ろでもP2P通信ができるため、これらの障害時にネットワークにアクセスし続けられる
- メッセージの配布 - pub/subによる効率的かつ柔軟なメッセージングを提供している(gossipsub)
- 相互運用性 - プログラミング言語やバージョンが異なっても、libp2pは相互運用できる
- 分散型 - 中央集権型ではないことが大きな利点のひとつである。ネットワークの中断や検閲(?これは適切な訳なんだろうか。後日検討する)に強い
こういうざっくり情報があるだけでも物事はすごく分かりやすくなるので不思議。おやすみー!
チーム全員と毎週1on1(技術やタスクの話をする場)するのが良い習慣となった
アメリカに来てから実施していることのひとつに、複数の同僚との1on1がある。一般的に1on1と聞いて連想するような上司とのミーティングも行っているものの、ここで扱うのは同じ立場のメンバーたちと話す場である。とある同僚がやっていたので私も真似して実践している。
今、自分と同様にコードを書いているメンバー4人と毎週30分ずつ会って、
- 近況
- いま詰まっていること
- 最近学んだこと
- その相手だからこそ聞ける、担当箇所や専門領域についての質問(1つのOSSを作っているものの皆バックグラウンドや得意なことがバラバラなので)
- アメリカのカルチャー(これはアメリカのことを全然知らない私向けの特別プログラムw)
などを話したり、ペアプログラミングしたりしている。10月からオンボ―ディングを始め、今のところ役立っているので所感を書き留めておく。
良いところ
- 1人1人との距離を縮めやすい。リモートでしか会えないメンバーもいる中、話す機会が増えるのは新参者には特にありがたい
- 質問のハードルがすごく下がる
- 色々な領域に触れられる。関心を持てる。自分がアサインされたタスクだけに集中すると狭い範囲しか追わなくなったりするけど、他の作業をしているメンバーとも会うことで少しずつ別のことをする時間も取れる
- 1週間の良いペースメーカーになってくれる
- まとめて1日に押し込むのではなく、火・水・木にこれらの1on1を入れることで良いサイクルが出来ている
- 学びや疑問の整理が習慣化される。例えば「明後日の1on1にこれを持っていこう」などと思いついたら、それまでにポイントを抑えておくようになるので悪い先延ばしが減った
- 1週間があっという間であるということを感じ、気が引き締まるw 「うわぁ、もうまたこの人との1on1が来た!」とかちょっと焦ったりもしつつ、先週から自分が何をしてきたか振り返る機会にもなる
- ↑2点目・3点目は週次のチームミーティングなどでも代替できそうだが、1on1という相手と自分しか登場人物がいない場ならではのちょっと違う緊張感があるのだ。それがポジティブに作用している気がする
改善しがいのありそうなところ
- 1on1で話した内容をもっとチームに広げていきたい。すごくざっくり捉えると「SlackでDMはやめましょう」という話と似ていて、発信しない限り当然学びはクローズなところに留まってしまうし、同じ会話が複数の1on1で何度も行われることになりうる。「勉強になったなぁ」で終えず、朝会やドキュメントでもっと共有したい。数も多いのでなかなか大変ではあるけれど…
- もっとドキドキせず望めるようになりたい。これは英語のせいもあるけど、相手の貴重な時間をいただいているのに有意義な時間となっているだろうか…って気を揉むのに疲れるw メリットで挙げた緊張感の裏返しなのであまり問題ではないけど、たまにはネタのない日があっても、問題が解決に至らなくても、上手く話せなくても(英語)、気にしすぎないのが良さそう
GitHub Actionsでフォークしたリポジトリを自動更新(git diffして差分の有無でexit codeを変える)
GitHubでリポジトリをフォークした後、どうやってオリジナルを追従していますか?(この記事ではフォーク元をオリジナル、フォークにより出来たリポジトリをコピーと呼ぶことにします。)
フォークしたリポジトリ、mainは勝手に更新され続けて欲しい
— よこな / Ayana (@ihcomega) November 3, 2022
(願望)
以前はローカルでマージやプッシュをしていたものの、最近面倒になってきたのですごく雑にGitHub Actionsで定期的な更新をかけるようにしました。オリジナルのマージをフックに…とかやると完璧ですが、ひとまずないよりあった方がいいかなということでしゅっと用意したものです。pyrsia/pyrsia
がオリジナルのリポジトリです。
name: Update forked repos on: schedule: - cron: '*/30 * * * *' workflow_dispatch: jobs: build: runs-on: ubuntu-latest steps: - name: Check out repos uses: actions/checkout@master with: repository: ihcomega56/pyrsia token: ${{secrets.gh_token}} - name: Update repo run: | git remote add pyrsia https://github.com/pyrsia/pyrsia.git git fetch pyrsia git merge pyrsia/main git push origin main
対象はmainブランチのみですが
- コピーのリポジトリをチェックアウトする
- リモート(
git remote
)としてオリジナルを追加する - オリジナルのmainを取り込んでコピーを更新する
というシンプルな流れを実現しており、これを30分に一度回します。こんなんで役に立つかなぁと思ったけど、ローカルで時々コピーをプルするだけなので結構楽になりました。GitHub Actionsは負荷によってcronが遅れたりするようですが、今のところ快適です。あくまで、better than nothingの精神です。
なお、現状はすべてをベタ書きしているのでリポジトリ数が増えたら工夫しないと面倒ですね。
git diffして差分の有無でexit codeを変える
これを実現しようとしている最中に学んだことは1つ。
git diff --exit-code
このオプションにより、git diff
の結果、差分があればプログラムのexit codeを1, なければ0という風に結果を切り替えることができます。
実は、はじめyamlの後半を次のようにしていました。
## (チェックアウトまで中略) - name: Check the diff run: | git remote add pyrsia https://github.com/pyrsia/pyrsia.git git fetch pyrsia git diff --exit-code --quiet pyrsia/main - name: Update repo if: ${{ failure() }} run: | git merge pyrsia/main git push origin main
差分に応じてexit codeを変えて、Actionsの記法if: ${{ failure() }}
と合わせることで「diffがあるときのみマージする」を愚直に実現していたわけです(どうしてこうなったのか自分でも分からない)。冷静に考えて差分がない場合はマージとプッシュを空振りさせておけばいいじゃんということに気付き、よりシンプルな設定となったのでした。
webからワンクリックでも更新できるよね
このボタンもありますね。しばらくGitHubを使っていなかった間に実装されていました。ただ、コピーの方をブラウザで開くのが地味に面倒だったので上記に至りました。もっと良い追従の方法があれば教えてくださーい!
Git - サブモジュールがdirtyだと言われたので直した(コミットハッシュが"XXX-dirty")
Gitの本を出しておきながらアレだけど、サブモジュールのことをちゃんとしっかりはよく分かってない。ある日、いつものように git status
したらサブモジュールに差分があるではないか。
※本記事でとりあげる例において、スーパープロジェクト*1から見たbats/lib/bats
がサブモジュールである(GitHub - bats-core/bats-core: Bash Automated Testing Systemおよびその兄弟的なリポジトリたちを使っている)。
$ git status On branch pyrsia-1448 Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) (commit or discard the untracked or modified content in submodules) modified: bats/lib/bats (modified content) no changes added to commit (use "git add" and/or "git commit -a")
差分を見ると
$ git diff diff --git a/bats/lib/bats b/bats/lib/bats --- a/bats/lib/bats +++ b/bats/lib/bats @@ -1 +1 @@ -Subproject commit c97b3a1b8644ddede18bff6bc035c12e9f50be78 +Subproject commit c97b3a1b8644ddede18bff6bc035c12e9f50be78-dirty
何もしてないのにdirtyだなんて失礼しちゃう・・・意味を調べた。
結論
サブモジュール内のファイルに変更を加えてしまっている(何もしてないわけがない)。
解決策 - 差分自体をなくす
git status
が言う通りgit restore / checkout
して消してしまえば良い。ただ、サブモジュール側のGitディレクトリに対する操作となるようなので、カレントディレクトリを変更してから実行するか下記のように環境変数を使って場所を指定すれば良い。
$ GIT_DIR=bats/lib/bats/.git git restore .
解決策 - 同様の差分はそもそも無視する
基本的にサブモジュールに変更を加えたいことはない(よね?)と思っているので、見つけたら上記のような対処をしてしまうのがいい気がするものの、無視する方法もあるらしい。
git diff
やgit status
に--ignore-submodule
あるいは--ignore-submodules=dirty
(この場合はdirty
のときだけ無視。none
, all
, dirty
, untracked
のいずれかが使える)というオプションをつけるとサブモジュール内の変更は表示されない。
コマンド実行時にいちいち指定したくない場合、git config diff.ignoreSubmodules dirty
と設定変更しておけば毎度無視されるらしい。どういうモチベでオンにするのか正直よく分からないのはサブモジュール経験値が低いからか。
さらに、.gitmodules
ファイルにignore = dirty
って書くという方法(↓例)もあるが、チーム全体で無視しよう!とはなかなかならないような?(基本的に無視に否定的…)
[submodule "bats/lib/bats"] path = bats/lib/bats url = https://github.com/bats-core/bats-core.git ignore = dirty
だらだらと詳細
dirtyなんて失礼しちゃうと思ったところからの調べものメモ。差分が検知されたサブモジュールのGitディレクトリで改めてステータスを確認するとこうなった。
$ git status HEAD detached at c97b3a1 Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: test/file_setup_teardown.bats no changes added to commit (use "git add" and/or "git commit -a")
該当ファイルの差分はこんな感じで、ローカルで末尾のスペースが削られていた。
これを見てひらめいた。多分、ShellCheck(ShellscriptのLintツール)をプロジェクト全体にかけちゃったからだ・・・。
やはりサブモジュールに変更を加えたいことってあんまりない気がするから見つけたらちゃんと確認するのが良さそう。やりたいタイミングとして思いつくのはサブモジュールとして依存しているライブラリのバグを踏んだときの動作確認とかかな?それ以外は正規の更新手順を踏むんじゃなかろうか。
ちなみに、スーパープロジェクトで実行したgit status
の結果(冒頭の例)だが、ファイル編集・削除を行った場合は modified: bats/lib/bats (modified content)
、追加すると modified: bats/lib/bats (untracked content)
という表示になるようだ。dirty
にはこれらすべてが含まれ、 untracked
は追加のみを指すらしい。
参考文献 - 公式docありがとう
- Git - gitsubmodules Documentation
- Git - gitmodules Documentation
- Git - git-status Documentation
- Git - Environment Variables
*1:親にあたるリポジトリをこう呼ぶみたい。https://git-scm.com/docs/gitsubmodules/2.19.2
結婚後の姓変更手続きをやっと進めたので記録
結婚して9ヶ月くらい(?)経ったけど、新姓と旧姓をまぜて生活していた。手続きは面倒なので必要に迫られるまでやらないいつものスタイルを貫いていたところ、ついに困ったことが起きた。確定申告の還付金が振り込めないと言う*1。
ついに銀行口座の名義違いで実際の問題に出くわしてしまった〜確定申告の還付金が振り込めないって〜あああああ〜めんどくせえええ一念発起して全部更新します
— よこな / Ayana 🐸 (@ihcomega) 2022年4月11日
私のお金が!返ってこない!ということでやっと銀行やクレジットカードを更新し始めた。やってみて、ポイントは銀行絡みの3つかなと思った
- 事前に住所を最新化しておけば銀行の姓更新もオンラインで出来る*2ので便利っぽい。もちろん銀行による
- 銀行口座の更新は、そこからの各種引き落としが凪なタイミングを狙うと良い。結婚したらすぐ手続き!とすると面倒なことになりそう
- ネットバンキングは使えるようにしておこう(使ってない人がいるのか分からないけど)
結婚して割とすぐ更新したもの
- マイナンバーカード: 婚姻届を出すとそのまま役所で手続きされる。新旧の姓が印字されるので、色々な更新手続きに欠かせない。
- 保険証: お医者さんに行くので必要だった。会社にお願いして再発行となった
- パスポート: USのグリーンカードの抽選に申し込んだので必要だった。全く新規で発行し直すことも、今のパスポートの姓を変えて再発行することもできる。5年くらい残っていたので再発行にしたが、決まりで苗字が変わっただけなのにお金がかかる(6,000円)のは1ミリ納得がいかない
要するに公的書類はなんだかんだ必要なのでさっさと更新してあった。運転免許は持っていない。
確定申告をきっかけに更新したもの
- 銀行の口座名義: 公的書類と一致しないと還付金をゲットできないことがすべての出発点。今後他にも問題が出てくるかもしれない
- クレジットカードの名義: 引き落としの銀行口座と名義が一致しないと使えない
- 証券口座の名義: 入金の銀行口座と名義が一致しないと使えない
- 銀行やクレカを使うサービスの登録名: なんとかペイとかECサイトとかモバイルSuicaとか。新しい名義に合わせないと困ったことになったら面倒
依存する登録銀行口座を更新したのは
- 会社(副業先や印税含む)の給与振込先
- LOVOTの代金引き落とし先
更新対象を洗い出すにあたってはマネフォ様様で、銀行の動き履歴から漏れなく拾うことができた。ありがとうございます!
銀行口座名義更新体験記
ひとまずUFJだけ更新した。今どき、姓変更だけならオンラインで出来るらしい!
しかも、その手続きをすると印鑑レス口座に切り替わるとかめっちゃいい。
でもこの手続ではもちろん本人確認をするわけだが、公的書類に記載の住所と銀行の登録住所が異なっているとアウト。私は3つくらい前の住所が登録されていたので、諦めて窓口へ行くことに…。入籍前に住所だけアップデートしてれば出かけなくて済んだのかと思うと体験が違いすぎる。
予約せずに行った窓口ではフォンブースみたいなところに案内され、リモートでオペレーターの方に対応していただいた。家で電話するのとは違い、スキャナーとプリンターが設置されていて書類もやりとりできる。
窓口に持参したいものは
- 本人確認に使える公的書類
- 新旧の印鑑(旧はなくても何とかなる)
- 口座情報が分かるもの(要はキャッシュカードや通帳があれば良いが、これらの現物が必要になるわけではない)
ちなみに私は旧印鑑を持たずに行った。邪魔だなこの印鑑…とか思いながら収納の奥底にしまった記憶だけがあって、実際どこにあるか分からなかったので早々に諦めた。なので、住所・姓・印鑑の変更手続きをしていただいたことになる。印鑑がないと手続き完了までの時間が少し伸びるらしく、2〜3週間かかる模様。完了通知は来ず*3、ネットバンクにログインして変わってればOKって感じみたい。カードも再発行はなく旧姓のものを使い続けることができる*4。
書類は3枚書いたけど、署名と捺印だけの紙もあったし大した量じゃなかった。総じて、身構えるほど面倒ではないなという印象に終わった。ちょくちょく待ち時間があったので、それを活用してクレカや証券系の更新を行った。
クレジットカード名義更新体験記
使ってるカードが5枚くらいあるので頑張ってポチポチした。大体オンラインで出来るが、新幹線のエクスプレスカードでお世話になっているセディナだけは申請書を取り寄せて物理提出が必要みたい。
姓の更新手続きは「名義変更」か「再発行」っていうような名前になっており、後者について、言われてみれば当然だけど再発行という発想がなかったのでなかなか見つけられなくて泣いた。引き落とし口座の更新は実際に銀行の方の手続きが完了しないと出来ないので、また今度やる。
我がカードちゃんたちは4日、10日、27日に引き落としがあって、今回の手続きは12日に行ったわけだが図らずもベストタイミングだった。クレカの名義変更は済んでるけど銀行はまだ、となると多分名義人不一致で引き落とせなくて1ミリ面倒なことになるので、それを避けられそうな期間に済ませるのが良さそう。
ヤフーカードはこの再発行のおかげで予定より半年近く早くPayPayカードに切り替わることとなった。ちょっと嬉しい。
追記: 実はヤフーカードも申請書が届くパターンだった。カード来たと思ったら紙だった…なんか意外。
その他体験記
モバイルSuicaは運用でカバーみのある段取りだった。サイトから「姓を変更したい」と申請すると、(多分手動で)名前を更新できる状態に切り替えてくれる。すると1回だけ変更できるようになるのだ!もし間違えたら申請からやり直しだと思われる。どうしてこうなっているんだろうか?ポンポン変えられても困るけど、内容を審査するほどのことではない、みたいな感じかな…。
証券口座は古巣FOLIOのだけ持っているが、氏名の変更機能、自分で作った…というかプロジェクトマネジメントしていた気がする。懐
感想
- 最強に面倒なことだと思って避けてきたけど、半〜1日まとめて作業すれば終わるかもしれない。ただ完了まではバラバラとラグがあるのでやっぱり心理的にはだるい
- 銀行の名義変更、各種引き落としに間に合って欲しい
- 住所入力フォーム、2022年になっても半角で入れろとか全角じゃないとエラーみたいなやつがいっぱいで辛い
- 京都の住所が長すぎて入力できないシステムがまだあって辛い。逆に、全部入力しないと審査で弾かれる場合もあるので、空気を読まなくてはならない
これ以外は引き続き放置して(というかもう更新対象が把握できてないみたいなところがある)、気が向いたら変えていこう。もし自分が確定申告をしないタイプの人間だった場合、何がきっかけになっていたんだろう。
ちなみに仕事とか外に出る活動は旧姓のまま行っている。あとお店の予約は一緒に行く人がどちらで認識しているかと気分で変えている。
夫婦別姓はよ!!!とは思わないというか、私個人としてはどっちでもいいので流れに身を任せるけど、シンプルに面倒くさいな。とはいえ思ったよりは面倒じゃなかった。いや、面倒だけど仕組みの進化は感じる。まぁ全部マイナンバーでなんとかしてください!
PyLadies x Java女子部 の軌跡とコミュニティコラボのいいところ
これは PyLadies Japan Advent Calendar 2021 15日目の記事です。もう12月も半分過ぎようとしているんですね、恐ろしい。
Java女子部の運営をしておりますよこなと申します!
Java, Scala, Ruby, JavaScript, Goなど「ほんのちょっとでも書いたことがある言語」なら色々ありますが、Pythonだけは本当に全く書いたことがなくてごめんなさい (このポピュラーな言語をここまで書かずに来たんだからもうそのまま引退したいという謎の思いすら湧いている) 。
そんな私ですが、PyLadiesさんとは結構縁があって何度かイベントでご一緒したことがあります。
合同で主催した勉強会
一緒に登壇したイベント
こうして振り返ると記憶にあるより多かったです。
コミュニティコラボの良さ
この記事で「コラボは良いものだ」と伝えたいのは皆さんお察しの通りですが、どう良いかを一言にすると「幅が広がる」ということですね。
- イベントのテーマの幅が広がる。お互い知らないことを教え合うイベントも出来るし、共通テーマで言語毎に違うアプローチを知ってみるのも為になるし、特別なエッセンスを入れずただ同じことを学ぶのにも意義がある
- 参加者の幅が広がる。どんな幅かというと…
上で挙げた過去イベントでいうと、言語に関係なく活用できるGitを一緒に学んだり、「女性コミュニティ」という共通点から対談をしたりしたのは同じテーマを扱ったものです。一方、分析APIの会は「分析」というPythonが強みを持っていそうなジャンルを取り上げながらもJavaを使ってコードを書くことで新しいことを学び合う場でした。
個人としては単純により多くの人と知り合えるのが有益で嬉しいです!私の場合、SNSで日々の挑戦やご活躍に刺激をもらっているPyLadiesの方がいます。イベントで知り合って以来、IT業界特有のゆるさでSNSにて繋がり続けることができているので非常に尊いです。 *2
印象深いのは、生まれて初めて技術的な発表をした「Git for Begineers」の会です。先に書いたとおりコラボイベントは単体のときより人数が多くなりがちです。数十人の前での発表にすごく緊張したものの、皆さんあたたかくてそこから技術に関する登壇のハードルも下がっていきました。初めてはてブのブクマ数が結構いってホットエントリーに入ったぞ!みたいな体験もした気がします(これも人数が多かったのはプラスになったかもしれませんね)。優しい雰囲気の場で成功体験ができたのは今の自分を作っているひとつの要素だと感じます。よく考えたらこれがきっかけでGitの本を出版するまでに至りました。
ちょっと気持ちよく思い出を語ってしまい気持ち悪くて恐縮ですが、皆でわいわいと時間を共有することの良さがちょっぴり伝わるといいなぁ〜という一心です。
実際、私以外にもコラボの話で初めて大勢の前で登壇する経験をしたメンバーを知っていますし、きっと似たようなプラスの要素を得られるケースは少なくないはず!
コラボしようぜ
2022年、またPyLadiesさんとJava女子部で何かやりたいです!それ以外のコミュニティの方も、ぜひなんか一緒にやりましょう。願わくばオフライン…が出来たらいいですが、まずは気軽にオンラインから!
ちなみにJava女子部は年明け1月8日(土)に「座談会」というか参加者でおしゃべりやお悩み相談会をする激ゆるふわイベントをやる予定なので良かったらそこでも会いましょう〜!イベントページまだないんですが、doorkeeperやTwitterに情報流す予定です。
…って書くと、自分のコミュニティを宣伝したくてアドベントカレンダーに乗り込んできたみたいにならないか心配ですが、そんな思惑ではなく皆さんと勉強会とかパーティー(?)とかやれたら嬉しいです。
あ、あと自分自身の目標としてコラボイベントではないPyLadiesイベントに参加してみたいのでオススメ会があったら教えて下さい!
最後に
PyLadiesさんやJava女子部がいい感じに紹介されているインタビュー記事を貼って終わりにしまーす!この記事、そして関連するWomen Developers Summit (前述) は2021年の出来事なので新しい情報が詰まってます。
ということで、今まで & 2021年の PyLadies x Java女子部 ふりかえりでした。以上!アドベントカレンダー、もう1枠くらい空いてたら技術的な何かも書こうかな。
パネルディスカッション楽しかったです!#devsumiA #devsumi pic.twitter.com/4oTQElnsFc
— まーや(Maaya) (@maaya8585) November 17, 2021
最近久々に元気・ポジティブな状態で頑張れるようになってきた
1年半〜2年くらい前から「う〜ん疲れちゃった…」ってなって、省エネ状態で暮らしていました。
正直昔から頑張れるパワーには波がありますが、ここ2年くらいは人生で1番やる気がなくなっていて、「頑張っても周りの人の足元にも及ばない…」「仮に何かうまくいったとして、人類史に何が残るんだ…」「寝ていたほうがトータルの幸福度は高い」などと考えてふにゃふにゃでした。ちなみにここでいうやる気というのは主に趣味や自己研鑽、コミュニティ活動などオフ時間の頑張りに直結するものです。
かつては何の疑いもなく「頑張る」ことを正としていたにもかかわらず、段々とそのコスパに目がいってしまったこと、背伸びして頑張り続けるのが大変だと知ったことにより立ち止まってしまったようです。
永遠に布団にいる日もあったし、お医者さんにちょっと相談してみたりもしたけど、前職の友にもらった「長い人生だから立ち止まる時間があっても大丈夫」といった力強くありがたい言葉を胸に割とのんびりしていました。その間ちょうどコロナで家にいることも増えて、色々なことを考えました。
- なんか何事も進捗がない感じがするな〜でも別にそれでも困らないな〜今後も一生この感じでいこうかな〜
- コロナで大変な世の中だけど自分は何もできないな〜自分がやることが世にとってプラスになるかどうかもっと考えてみたいな〜
- 今まで何故頑張ってきたんだろう〜これから何を目指して生きていくんだろう〜
- とにかく好きな人達と関わりを持ち続けながら暮らすのが自分にとっては幸せだな〜そのためには時間やお金や色々な余裕があった方がいいのかな〜
ゆったりした生活による空き時間で、以前はあまりやらなかったゲームをするようになったり、久々な知人に積極的に「元気?」と連絡してみたり、行動にも小さな変化があった気がします。
いずれも「疲れちゃった…」とステイホームが重なったことによるものだと思われますが、「自分は何を考えているのか/大事にしているのか」を考える時間、やらなかったことや疎遠だった人に割く時間が増えたのは結果として良かったみたいです。
結局、立ち止まって色々考えているうちに具体的に実現したい目標ができて、最近漸く浮上してきました。
これは朗報なんですが最近目標ができまして。おかげで今週は寝すぎを脱却してやる気も前よりたくさんありました🌝
— よこな / Ayana (@ihcomega) June 13, 2021
まぁあまりノリノリで暮らし続けると反動がきちゃうんで、おだやかに人並みの暮らしをしていくぞー😗
ということで、このツイートをしたあたりから自分でも驚くほどみるみる元気になってきて、省エネモードはいったん終わりを迎えたのでした。たまには自分との対話に集中してみるもの良いものですね。そして目指すものがあると何をすべきか分かりやすくてとても良い…。
「自分には無理そうだけどわんちゃんできるかもしれない」ということを程よく抱えているのがトータルいちばん良い…しんどいけど…というのがこれまでの社会人ライフの学び。かなぁ〜
— よこな / Ayana (@ihcomega) August 25, 2021
自分の傾向をふまえるとこういうことなのかなという整理もできたので、適度に頑張り続ける生き方を今は選んでみます。
早速、前より起きている時間はめちゃくちゃ長くなったのにやりたいことが片付かなくなりつつあります。つまりはやはり波の大きい人間なんですが、今後は次のレベルアップとしてその波を小さくしていくところを目指します。安定感!