zennに移行します
しばらく更新していませんでしたが、技術メモは今後zennに書いていこうと思います。 技術ブログ自体の存在価値が問われる時代ですが...
ここの記事はそのままにして、たまにポエムとかzennに投稿するには憚られるような記事を投稿する予定です。
<php>get_object_varsを共通のスーパークラスのメソッドに実装するときの注意
概要
PHP8においてインスタンスの情報を取得するメソッドにget_object_varsがあり、これを使えば引数に渡したインスタンスのもつアクセス可能なプロパティについてArray型で出力してくれる。
これはDTOのようなプロパティ主体で構成されるクラスなんかの共通処理として実装しておけば色々楽になりそうだったので、抽象クラスにget_object_vars($this)を戻り値として返すようなpublicなメソッドを定義した。(オーバライドせずそのまま使用する用途)
問題
継承先のクラスではprivateのプロパティは「アクセス不能」とみなされ取得できない。
誤解いただきたくないのは、上記のようにインスタンス内部で引数を$thisとして当該メソッドをラップしたメソッドを定義して継承元クラスのインスタンスでは 通常のgetterメソッドと同様にprivateだろうが当然アクセスできる。
<?php class Test1{ public function pp(){ var_dump(get_object_vars($this)); } } class Test2 extends Test1{ public $v1='a'; protected $v2='b'; private $v3='c'; } $t=new Test2; $t->pp(); > array(2) { ["v1"]=> string(1) "a" ["v2"]=> string(1) "b" }
調べるとこれはPHP5で入った変更のようで、継承先のプロパティがprivateであった場合は継承元で定義したget_object_vars()はアクセスできなくなったようだ。
対策
いまのところ思いつくのは以下2つ
- protectedにする。
- 各クラスに直接定義を実装する。
前者が良さそう、個人的にはできるだけプロパティはprivateにしておきたい(でないとOOPの意味が薄くなる)ので。
Mysqlでレコード挿入時に作成日を、更新時に更新日を自動で行えるようにする
概要
DBの各テーブルには大抵の場合、更新日と作成日、また作成者を登録したくなる。
これを全テーブルで、更には各updateとinsertのSQL操作で毎回書くのは冗長すぎるのでなんとか自動でできる手段を探していたが、 テーブル作成段階でこれを可能にする方法があったのでその備忘録。
結論
CREATE TABLE文で以下のようにする。
CREATE TABLE Users ( //他のカラム定義 created DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id) );
見たとおりだが
- insert時のデフォルト値について：
DEFAULTに`CURRENT_TIMESTAMPを設定(insert時点の日時で記録) - update時の値について(updatedカラム):
ON UPDATEでCURRENT_TIMESTAMPを設定
が実現している。
その他
他のテーブル定義にデフォルトでupdatedやcreatedを付加する便利な方法を探している。
(テーブル作成時にコピペするだけなので大した手間というわけではないのだが、やはりめんどくさい...
<PHP>サブディレクトリのnamespaceの名前解決ができない
概要
以前にcomposerを導入したとき、composer.jsonで定義したauto_loaderがなぜか機能せず、一旦調査保留にしていたのだが、その原因がざっくりわかったのでとりあえずのメモ
原因
自分でプロジェクトのソース内で宣言していたspl_autoload_registerがどうも悪さをしてたようで、当該宣言を削除しcomposer側で生成されるauto_loaderを読み込むようにしたところ、サブディレクトリの名前空間も無事読み込めるようになった。
todo
spl_autoload_registerとかcomposerのautoload周りの挙動を理解する。
PHPのnamespace(名前空間)について
はじめに
Pythonにはなく、ほかの言語ではある程度一般的な概念としてnamespaceがあるが、 requireやincludeといった宣言との使い分けがよくわからなかったのでそのメモ
requireとinclude
ざっくりいうと読み込む対象が読み込めなかった場合に...
- 警告のみで継続->include
- 中断->requrie
という違いなようだ。 またrequireに関してはrequire_onceもあり、こちらは既に読み込み済みの場合は多重で読み込むことで発生するバグを防ぐことが可能であるので、 一般的にはrequire_onceを使う場面のほうが多いように感じる。
namespaceの意義
useによる宣言で、クラスもしくは名前空間の指定ができる。つまり...
- requireとinclude -> ファイル指定
- use (namespace) -> 名前空間もしくはクラス
と端的に言えそうだ。
どちらを使うべきか
大抵他ファイルで定義しているクラスを読み込むことが一般的だと思うので、 メインではuseを使うのが良さそう。積極的に名前空間を活用することで、他ファイルとの宣言名の衝突への配慮はかなり少なくて済むと思うので。
それ以外への対処はrequireを使って書く、というのが良いのかもしれない。
その他
詳しくは要調査。とりあえずの現段階の知識として残しておく
参考
PHPのインタプリタを手っ取り早く利用する方法(wsl2(windows)&docker&tmux)
概要
プログラミング言語のインタプリタで簡単に組み込み関数の挙動を見てみたかったりする場合、Pythonのようなスクリプト言語だと組み込みでインタプリタがすぐに使用可能であるが、PHPだとインストールの方法によってはインタプリタが有効になっていないようだった。
一応特定のバージョン(v5?)以降はビルド時の設定によってPHPのインタプリタを有効にすることもできるが、wsl環境を汚したくない等の理由でせっかくdockerがあるのでそこで試せれば良いやという結論に、その備忘録。
構築方法
方法もクソもないが、dockerHUBにphp8.0-cliのイメージがあるのでそれをpullして使うだけ。
最近はtmuxを使用するのにハマっており、インストールさえしていれば簡単に利用できる。(なければapt install tmux)
(windows powershell)$ wsl -d ubuntu (wsl)$ docker pull phpdockerio/php:8.0-cli (wsl)$ tmux (tmux:wsl)$ docker run -it --rm <pullしたimage> /bin/bash (tmux:php8.0-cli container)$ php8.0 -a (tmux:php8.0-cli container)php >
雑感
だんだんwindowsでの開発もなれてきた。(macのときのようにローカルで開発して汚さない点ではこっちのほうがいいまである。) より便利な使い方を追求していきたい。
参考
Chrome Remote Desktopで一部キーが反応しない、もしくは謎のショートカットと関連付けられる現象
概要
題の通り、Chrome Remote Desktop(windowsのRDPのようにリモートで社外から社内のPCにアクセスできるツール)において、キーボードの一部キーが反応しないという現象が発生した。
正確には反応するキーもあり、正しく入力できる場合もあれば、なぜか接続が切れる(自分の場合はPとRキー)で再接続になったりと、ググっても類似の現象がなく、困っていたのだが今日ふと解決に至った。
原因と対策
Vimium(Chrome拡張機能)が原因だった。拡張機能から無効にすれば正常に動作するようになる。
この不具合(現象)の厄介なところは、ChromeRemoteDesktopのデスクトップアプリケーションを使用しても現象に改善が見られなかったことだった。(この線があり、vimiumが原因だと思い当たるまでに時間を要した。。。)
あともう一つ厄介だったのが、接続元ではなく接続先のブラウザ設定に原因があったので、気づくのがより遅れてしまった。
今回の現象はブラウザの操作を簡易化する拡張機能との競合で起こりうる可能性があるので、類似の現象が発生した場合はまずChromeの拡張機能に悪さしているものがないかどうか調べてみるのが良さそうだ。
シェルスクリプトでファイルに行を挿入したい
概要
CLIでログデータを簡易的に処理する際、headerがなかったので該当のログデータにヘッダー行を挿入したかった。
結論
以下で可能。
複数ファイルがある場合のケースを記載。
#!/bin/bash
IFS=$'\n'
header=`cat ./header.txt`
for file in *.log
do
sed -i 2i$header $file
done
補足として...
IFS はInput Field Separaterの略で、今回の例に限らず基本メトリクスデータは空白による行列分割を行っているので、
これを変更しないと処理中に分割して解釈されるので少し中止したいところ。
ハマりどころ
今回はsed -iによって、解決できたので問題とならなかったが (sed等の上書きモードが使用できない等の)場合によっては、以下のようにしたくなると思う。
#仮にsedに上書きモード(-iオプション)がなかったとして cat $filename | sed 2i $header > $filename
これについては結果対象のファイルは空となる。
理由は以下ブログで原因と対処法が記述されているので参考にされたい。
参考
データベース設計(エンティティ抽出とビジネス的正規化)
はじめに
いくつかの書籍や記事を参考にしながらまともにRDBのデータベース設計をやったのでその備忘録。
使用した書籍は以下。
色々な書籍を並行利用して勉強すると理解が深まるので良かった。
かなり前に勉強した記録が混じっているので未整備だが、後日編集/追記予定で一旦投稿。
基本のき
流れや、知っておくべきことをざっと箇条書きにしてみる。
知っておくべきこと
エンティティには2種類あり、
- イベント系…動詞化出来るもの(商品購入、 商品出品)、When(タイムスタンプ)をつけられるものかどうか
- リソース系…複数名詞 かできるもの
がある。
またエンティティの抽出作業については初期段階では網羅的にまずはとにかく書き出すことが重要。
簡単に言うと
- 発生する作業の一連の流れを思いつくだけ書き出す
- 各作業について、どんな画面を遷移するかイメージする
正規化
- オブジェクト指向でもよく言われることだが、テーブルの保持する役割・意味が単一となるような正規化をすること。
- 一つの事実は一つの場所に
- ビジネス上における正規化という目線のほうがわかりやすい。データ上重複して見えてもビジネス上ではデータの意味がことなればそれは同じデータとして扱ってはいけない。(重複ではな
プライマリキーの話
業務で使用するコードはプライマリキーにしてはいけない
業務で現在使用されている=ビジネス側の都合で作成したコードは現時点でユニークであって変更可能性が低くても、将来的に変更可能性が生じ問題となるケースが多い。 また複数のコードによる複合プライマリキーしてユニークであること保持している場合も同様で、いずれかのコードに変更があった場合に問題が生じる。
解決策は単なる連番によるプライマリキーを(システム側の意図した識別子で)設定すること。
コード=プライマリキーとすることの弊害
- 諸々問題(再利用性が低いものをレコードとして保持したくない、もしくはそういう顧客は後に集計したいケースがある)
データベースは「事実」を「正しく記録」することが重要！！！！！
つまりどんなに再利用可能性が低い顧客でも、顧客レコードとしては区別するべき。(それぞれユニークなIDを持つレコードを作成するべき) 後者の、後にそういった顧客をまとめて集計したい場合は別途顧客コード等のカラムで同じIDをふるなどする。databaseはビジネスやプログラム側の要求には引っ張られてはいけない。対象が計画的モデルの場合
- 計画的モデル＝複数のバージョンが切り替わる(物自体を特定する識別子は必要だが、同時にバージョンを意味するコードには変更が加わる
製品コードをつけるとして、予め変更可能性がある時点でプライマリキーには設定できない。じゃあ仮コードを別途作ってそれを主キーとしても(仮：製品)の2通りのコードしか保持できない。
また製品コードの履歴を管理できなくなる問題もある。
解決には、製品識別子を外部キーとした製品コード(バージョン)のテーブルを別途作成して、使用期間をカラムとして持たせておく。
その他の問題
- ある一つのものに対して、複数のコード体系が割り振られている場合
- コード体系の統一ができるならそれを、(ビジネス側で難しそうであれば)関連エンティティ(m:m)を作成する。
- 関連エンティティとは異なるコード体系を外部キーとしてまとめたエンティティ(レコード)のこと
データモデルが複雑になることに恐れるな
- 業務のシステム化を検討する際、多くの場合においてその業務フローや各エンティティの意味付けの多岐化等により、ER図も複雑化するケースが少なくない。 これは仮にデータベース上で複雑さを回避(例えばビジネス上複数の意味合い、もしくはステータスを含むものを単一のエンティティやカラムで管理)した場合、それはプログラム上のswitchやif等の複雑な条件分岐によって判断することになる。対象が複雑である以上、制作するシステムのレイヤのどこかは必ず複雑になる。それがデータに関係する複雑さなのであれば、それはそのまま表現しなければならない。(テーブルの関係が複雑になることは悪ではない)
データのライフサイクルとその後の都合よって生じる問題
- 一般的にはデータはCRUDのサイクルで最後はDeleteされて、レコードそのものが消失するが個別の要件(そのレコードを参照している別テーブルのレコードがあった場合等)で削除されたと「みなす(ステータスにする)」ケースがある。また、レコードの削除後に識別子の再利用をするケースがあるが、これは過去の(バックアップした)データベースと連結したい場合には、識別子が重複することとなるため虫食いの再利用が推奨されない。
xampp環境で直接開発しているときのエラー出力確認方法
開発環境
大雑把に以下のような構成で開発している。
VScode(remote-container)----
|(デプロイは内部でのファイル移動)
WSL2(ubuntu)------------docker container(Apache tomcat/PHP)
端的に言えば、webサーバ上で直で開発しているようなものでこのときバックエンドのエラーについて確認する方法についてわからなかったので、その時の備忘録。
確認方法
結論：何らかの方法で/opt/lamp/logs/php_error_logを監視すれば良い。
監視の方法としてはいくつか方法があるが、調べたところ以下のような感じが良さそう。
$ tmux new -s <terminal-name> $ tail -f /opt/lamp/logs/php_error_log (or less +F <logfilepath>)
lessコマンドの方だと監視→閲覧を[Ctr-C]、閲覧→監視を[F]で簡単に切り替えられるのが良いらしい。
その他
もう少しいい方法を探したい。(なんかイレギュラーなきがする)
参考
wsl2を使う前にやっておきたいこと(ディストロのバックアップ)
はじめに
転職してから開発環境がMac→Windowsと変更になり、色々と試行錯誤している最中です。 windowsでの開発、となるとwindowsデスクトップアプリケーション等のを除いた一般的なweb/ネイティブアプリケーションの開発はunix環境で行うのが一番ベストなので、 そうなるとwsl2を使うのが一番良い選択肢だと思う。
wsl2はディストロ(≒ディストリビューション)をdocker imageのように使えない
見出しの通りなのだが、例えばdockerでubuntuのイメージを使いまわしたい場合は、docker hubで公式のイメージを引っ張ってくるか、自分でビルドしておいたイメージを利用すればいい。
wsl2も一見同じようなことができそうなのだが、基本的にはできない。(そもそもそのケースならdocker使えよ、という議論はなしでお願いします)
とにかく今回はそういったdockerライクなユースケースに対応するための準備をしておく。
1. 任意のディストロをインストール
詳細は公式docを参照されたいが、以下コマンドでインストール可能なディストリビューションを表示できる。
> wsl --list -o インストールできる有効なディストリビューションの一覧を次に示します。 'wsl --install -d <Distro>' を使用してインストールします。 NAME FRIENDLY NAME Ubuntu Ubuntu Debian Debian GNU/Linux kali-linux Kali Linux Rolling openSUSE-42 openSUSE Leap 42 SLES-12 SUSE Linux Enterprise Server v12 Ubuntu-16.04 Ubuntu 16.04 LTS Ubuntu-18.04 Ubuntu 18.04 LTS Ubuntu-20.04 Ubuntu 20.04 LTS $ wsl --install -d Ubuntu-20.04
今回はUbuntu-20.04を選択する。
2. ディストロをエクスポートする
dockerで言うところのcommitコマンド。
1のようにコマンドでインストールした場合、ディストロは以下ディレクトリにある。
C:\Users\<username>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc\
エクスポートするには--exportコマンドで以下のように実行する。
wsl --export <エクスポートするdistro> <保存名>
バックアップの保存先として、package以下にdistro_backupを作成した。
今回は先程インストールしたUbuntu-20.04を選択したいので以下のよう実行する。
wsl --export Ubuntu-20.04 C:\Users\<username>\AppData\Local\Packages\distro_backup\Ubuntu-20.04.tar
3. ディストロをインポート(複製)する
dockerで言うところのbuildに近いところ、docker:container=linux:distribution みたいな感じ。
importではディストロに対して名前を個別につけることができるので、当初の目的であったディストリビューションの複製が可能になる。
wsl --import <ディストリビューションにつける名前><インポートに利用するdistroのパス> <インストール先> <ファイル名>
なお、追加可能なオプションとしてversionがあるが、これはおそらくwslバージョンなので、未指定な場合はset-default-versionで指定しているバージョンになると思われる。(多分)
今回自分はk8s用の環境を分離することが目的だったためubuntu-20.04-k8sという名前で作成する。
$ wsl --import Ubuntu20.04-k8s 'C:\Users\<username>\AppData\Local\Packages\Ubuntu20.04-k8s' 'C:\Users\<username>\AppData\Local\Packages\distro_backup\Ubuntu-20.04.tar' $ wsl --list Linux 用 Windows サブシステム ディストリビューション: Ubuntu-20.04 (既定) docker-desktop docker-desktop-data Ubuntu20.04-k8s
無事追加できた。
ログインは以下でできる。
$ wsl -d Ubuntu20.04-k8s
なおエクスポートに利用したディストリビューションは削除してもok(2でエクスポートしたディストロがあれば複製可能)
awkでオプション'OFS'(output field separater)が適用されない
概要
タイトルの通り、以下のようにpsコマンドの情報を整形しようとしたとき、想定した内容にならなかった。
$ ps aux | grep httpd | grep -v grep | awk -F ' ' -v 'OFS=#' '{print $1 $2}'
apache5768
apache5769
apache5776
apache5777
apache5779
apache6679
root17779
特にエラーはなく、表示も1,2列目が表示されている。
結論
typoレベルのミスで、'{print$1 $2}'の列指定の間にカンマがないことが原因だった。
カンマをいれると...
ps aux | grep httpd | grep -v grep | awk -F ' ' -v 'OFS=#' '{print $1,$2}'
apache#5768
apache#5769
apache#5776
apache#5777
apache#5779
apache#6679
root#17779
想定どおりに表示された。
ただし、$0で指定した場合はOFSが適用されないのでこれは別途調査しようと思う。(仕様？)
wsl2にsshで接続する
概要
ホストOS
|(ssh 接続)
ゲストOS(wsl2,ubuntu20.04)
通常はホストOS側でwsl2がインストール完了していれば、wsl -d Ubuntu20.04のようにコマンドを叩けば、一般的なsshと同様な感覚でログインシェルに接続できる。
なので本来この作業は意味がない(ゲスト-ホスト間のファイル転送もwslからみると/mnt/c/以下にホストOSのシステムドライブがマウントされているため、容易にアクセスができるため)
今後wsl2のUbuntuサーバーにホストOSが所属するLAN内のPCから直接wsl2のゲストサーバーに接続することを目指して、まずは前段階の準備として一般的なssh接続導入の準備をする。 なお以降ゲストOSのことはwsl2サーバーと記載する。
wsl2サーバーへログイン
Windows Powershell からwsl2コマンドを実行してログインする。
わからない場合は--listオプションをつけてインストール済みのディストーションを探す。
$ wsl --list Linux 用 Windows サブシステム ディストリビューション: Ubuntu (既定) docker-desktop docker-desktop-data $ wsl -d Ubuntu // ログインシェルへ
wsl2サーバーでのsshサーバーの導入
$ sudo apt install -y openssh-server
自分の場合は導入済みだった。(おそらくwslコマンド自体がssh接続のラッパーだからだと思う、調べてはいない)
sshd_configの編集
以下の記述を編集(コメントアウトをはずす)
$ sudo vi /etc/ssh/sshd_config //sshd_config PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 PasswordAuthentication no
編集が終わったら、sshサーバーを再起動する。
$ sudo service ssh restart $ sudo service ssh status * sshd is running
statusを確認してrunningとなっていればsshサーバーの準備は完了
ホスト側公開鍵の仕込み
おそらく以下でいけるはず
// wslサーバ側で操作 $ cat /mnt/c/Users/t-kod/.ssh/ssh_key.pub > .ssh/authorized_keys $ chmod 600 .ssh/authorized_keys
これでゲストOS側の準備は整った。
$exitで切断して、ホストOSで操作をする。
ssh_config作成
wsl2ではPC(wsl2)の再起動のたびにIPアドレスが動的に変化する。 これについてはスクリプトで動的にconfigを編集したいが、今回はとりあえず接続だけの確認をする。
// wslのIPアドレスを確認 $ wsl -d Ubuntu --exec ip address // eth0のinetを確認 $ touch .ssh/config
Host wsl-ubuntu Hostname <今確認したIPアドレス> User ubuntu Port 22 IdentityFile ~/.ssh/ssh_key IdentitiesOnly yes
これで準備完了。
$ ssh wsl-ubuntu // wslサーバへ接続
その他
近いうちにほかサーバとのssh接続については別途試して記事化予定
tomcatのheapdump取得&apacheやtomcatといったユーザにログインできない問題
やりたかったこと
tomcat上で動いているwebアプリケーションの不具合調査のためjcmdコマンドでJVMの情報取得を試みたときに以下のようなエラーがでた。
$ jcmd 27318 GC.heap_dump /var/log/heapdump/heapdump.hprof
27318:
com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
at sun.tools.attach.LinuxVirtualMachine.<init>(LinuxVirtualMachine.java:106)
at sun.tools.attach.LinuxAttachProvider.attachVirtualMachine(LinuxAttachProvider.java:63)
at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:208)
at sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:147)
at sun.tools.jcmd.JCmd.main(JCmd.java:131)
調べたところ、JVMを起動したユーザ以外は拒否されていることが原因らしいので以下のようにログインユーザの変更を試みたができなかった。
$ su - tomcat su: failed to execute /bin/nologin: そのようなファイルやディレクトリはありません
これの解決策について調べたので備忘録として残しておく。
エラーメッセージの意味と原因
ざっくり結論、ユーザによってはbashとかのログインシェルが存在しないケースがあり、
$ cat /etc/passwd
で見てみると、
tomcat:x:88:88:Apache Tomcat:/usr/share/tomcat:/bin/nologin
みたいな感じで ログインシェルが /bin/nologin となっているとログインシェルが存在しないことを意味しているようだ。
解決方法
解決方法は単純、suコマンドの-sオプションでログインシェルを指定してやればいいので、
(root@/)$ su -s /bin/bash tomcat bash-4.2$ pwd /root bash-4.2$ id uid=88(tomcat) gid=88(tomcat) groups=88(tomcat)
というようにログインできた。
またもとからやりたかったJVMの情報取得をjcmdコマンドで確認してみると...
bash-4.2$ jcmd 27318 VM.flags 27318: -XX:....
無事確認することができた。 tomcatについては知見がまったくないのでこれから(必要に応じて)情報を整理していきたい。
久々の、あとこれからどう生きるか
2020年～2021年は色々な方にご迷惑をおかけしました。
久々の投稿になりました。 一応見出しの期間にもわずかに投稿していた時期はあったのですが、基本的にはプログラミングそのもの自体あまりしていませんでした。
精神に不調を来したことで、口約束ではありましたが約束やプロジェクトをいくつか反故にし、前職もなし崩し的に退職することとなり、これまで自分が寝る間を惜しんで積み上げてきたものもすべて無に帰し、27年間の人生で最も苦しい時期でした。 自身の至らなさでご迷惑をおかけした方には大変申し訳ことをしたと現在は反省しています。謝罪してもしたりませんし、そもそもこのブログで謝罪することに意味はありませんが、せめてものこれからをより良くしていくための決意としたいです。
現在は
2021/11頃に前職に就職するきっかけになった先輩に背中を押していただけたことで再就職活動を再開し、現在は2022年1月から都内のwebシステム会社のソフトウェアエンジニアとして復帰をさせていただけています。 精神的な不調も現在は大きく改善し、健常者と同じ様に不都合なく働けて、そして生活もできています。
苦しい時期を経験して得たものは
ふさぎ込んでいた時期は、この期間中に限らずこれまでやってきたことすべてが無意味で今後二度と良くなることはないし、その権利ももうないと考えていました。 正直一部の方については恨めしく考えていた時期もありました。
ですが、今はこの精神的不調だった時期も自分にとって幸運だった、必要なことであったと思えるようになりました。 この時期を通じて、人への共感性や自身を俯瞰的にみる能力といった精神面の成熟、もしくは変化が自分でも感じられるようになったと思います。
2社目に転職でソフトウェアエンジニアとして入社したときの当時の自分は、新卒で入社した重電メーカーで養成された向上心やこだわり、価値観といったものがかなり強くなっていて、それが良くも悪くも自分や周囲の人間を苦しめていたと思います。 端的にいえば、「自分に厳しく、他人にも厳しく」といった人間へ近づいていたと思います。気づけば昔思っていたなりたくない大人の像へ近づいていました。
今回の経験を経て、自分がかつて抱いていた理想の大人になることを思い出せ、改めてどういう人間になりたいのかについて納得して考え直せました。
2022年から、どういう風に生きたいか
- やっぱり人生は楽しく生きたい
- 生きがい・やりがいも感じていたい
- せっかく時間も使うからには仕事であっても、なんであってもできるだけ有意義にしたい
- お金につながらない=直接的に非生産的といって排除したくない、のんびりする時間やゲームする時間、音楽を聞く時間にも間接的には生産性はあるし、そもそも生産性が全てではない
- 人の気持ち、心はわからない。だからこそ優しく、そして自分にも優しくする
- できるだけ沢山挑戦して失敗し、それを許す。それを他人にもできるようにする
- 今やりたいことは今やる、本能をもっと優先する
- 素直・柔軟であるか、あるべき論に囚われたり視野狭窄に陥ってないか、またそれを他人に強制していないか定期的に確認する
- 習慣化にこだわりすぎない。短期的に途絶えても中長期的に継続することが大事。これも本能ベースでやりたいことをやる
- 睡眠は絶対ないがしろにしてはいけない。睡眠導入剤を飲んででも寝る
上記が今考えているどういう人間でありたいか、どう生きたいかです。 柔軟を大事にしているように今書いた基準にも囚われすぎずもっと肩の力を抜いてこれから日々生きていきたいと思います。
