【WIZARDRY】【戦闘の監獄】リュードの迷宮地下4階~5階 | 自分、ぼっちですが何か? (taki-lab.site)


この階も前回と同様、6階と7階がペアになっていて、
最後に封印されたボスを倒すと次の会に進めます。
これは最近知ったのですが、オリジナルバージョンの謎解きが難しすぎて不評だったらしく、リメイク版では簡略化されているらしい。
その分敵が強化されているのだとか。
【WIZARDRY】【戦闘の監獄】リュードの迷宮地下4階~5階 | 自分、ぼっちですが何か? (taki-lab.site)


この階も前回と同様、6階と7階がペアになっていて、
最後に封印されたボスを倒すと次の会に進めます。
これは最近知ったのですが、オリジナルバージョンの謎解きが難しすぎて不評だったらしく、リメイク版では簡略化されているらしい。
その分敵が強化されているのだとか。
今週から新しい現場に入りました。
とはいっても、まだ支給PCをセットアップして、業務ツールのアカウントを設定して、動作環境を立ち上げて、までの段階なので、まだソースコードを見ていません。
開発しているプロダクトの話は出来ませんが、どんな環境で動かしているのか。

AWS上にDockerコンテナを稼働させて運用しているようです。
あまりAWS独自のサービスは使用していないみたいで、
使用しているデータベースなどもDockerコンテナで稼働させているみたいです。
AWSの独自サービスを使用していないので、ローカル環境でも動作確認できるっぽい。
以前AWS関連の開発をしていた頃は、ガリガリにAWS独自サービスを使用していたので、動作確認もAWS上に用意しなければならない、と言うのがあったので。
今回は動作を確認しながらコードを書くというやり方が出来そうです。
Windows上でDockerを使用する場合はDocker Desktopを使うのですが、
今の職場ではWSL2上にサービスを稼働させてDockerを動かしているようです。
どちらかと言えばLinux上でDockerを動かすイメージに近いやり方だと思います。
すげぇ。
そして、API仕様書もすでに用意されています。
何故英語なのかは不明です。
ただ理解しなければならない国際標準の仕様がベースにあり、その内容もいずれ理解しないと行けないので、英語の世界は避けられないようです。
まぁ、今年中は開発環境構築とシステムの理解とかが中心になりそう。
そして、年末年始は11連休。
稼働時間は大丈夫か?

以前から楽天市場で稼いだ楽天ポイントを、投資信託に回して資産を増やす、ということをコツコツとやっていたのですが、
約2万円分の投資信託を持っていたんですが、
年に二回(6月と12月)に300円~600円のお金をもらっていることに気がつきまして、
「2万円の投資で年間数百円貰えるのって、投資の方が銀行に預けるより効率良いんじゃね?」
ということに気がついてしまいました。
と言うことで、今回は投資に関するお話です。
昔(35年ぐらい前)はバブリーな時代だったので、銀行に預けて利子で増やす、というのが当たり前でした。
当時のマンガ雑誌で「銀行に預けて増やす」というのを読んだ記憶があります。
その反面、株式については全く教えてられませんでしたね。
社会の公民の授業で「株式会社」の仕組みを教えて貰ったくらいです。
まぁ、当時はインターネットが存在しない時代なので、株式も物理的な証券として持っていた時代です。
今は株式は全て電子化されていますけどね。
そのうち、インターネットも一般に普及してきたので、ネットで株式を購入できる時代になってきました。(だいたい20年前)
とはいってもまだまだ庶民が手を出せるものではありませんでした。
購入単位が100株~1000株になるので、買おうと思ったら100万円ぐらい持っていないと買えないんですよね。
で、今は少額でも1株単位で購入できるようになり、さらにポイントで株式を購入できるようになり、我々平民でも気軽に株式に手を出すことが出来るようになりました。
では、株式でお金を稼ぐ方法を紹介します。
たぶん、一般的な「株で稼ぐ方法」というのはこれだと思います。
株式は株式市場が営業している間は常に価格が変化しているので、
株の値段が安いときに購入して、株の値段が高くなったときに売ります。
そのときの差額が「利益」となります。
ただ、この方法だと確実に稼げるわけではありません。
株の価格が購入時より下がる事もあり得るからです。
なので、売るに売れなくなったり、損を覚悟で売る、というようなケースがあります。
なので、確実に稼ぐにはそれなりの覚悟と知識が必要だと思います。
自分はこれで稼げる自信ありません。
なので、自分はこちらの方でお金を増やす方法を選択しました。
元々株式とは、株式を発行し、それを購入して貰うことで会社は営業資金を集めます。
そして、株式会社が生み出した利益の一部を株主に還元する、というのが元々の仕組みです。
なので、購入した株の会社の収益にも影響されますが、一般的に上で説明した売却益で稼ぐよりも損になるリスクは少ないと言われています。
株式はどうしても投資先の会社の業績に影響を受けるため、大きく化けることもありますが、大きく損をする可能性もあります。
そのリスクを軽減するためなのかどうかは知りませんが、投資信託という選択もあります。
投資信託は投資のプロにお金を預け、代わりに運用してくれます。
プロは分散投資で運用してくれるため、大きく稼ぐことはありませんが、大きく損をするリスクも少ないです。
投資信託は会社を選ぶのでは無く、投資プランを見て選択することになります。
各プラン毎にこれまでの運用実績が見れるようになっているので、それを参考にすると良いと思います。
こちらも運用実績に応じて利益が分配されます。
プランの中には銀行の利息よりもはるかに大きいものもあります。
賢くお金を管理するためには、預金と投資を上手に使い分ける必要があります。
預金は預けたお金をATM等でいつでも引き出すことが出来ます。
しかし、投資したものを現金化する場合は、まず株式などの売却することから始まります。
株式の売買は市場の営業中しか出来ませんし、価格も変動しているので、購入時のお金がそのまま戻ることはありません。
さらに証券会社に支払う手数料(結構バカにならない額)もかかりますしね。
なので、すぐに使用する可能性がある予備のお金は預金口座へ、
しばらく使用する予定の無いお金は投資に回す、というのが賢い使い方と言われています。
NISAは投資信託の一つと思っています。
仕組みも投資信託と似ています。
株式や投資信託で得られた利益は全て課税対象となりますが、
NISAによる利益は非課税となります。
そのかわり、個人が使用できるNISA口座は一つだけで、預けることが出来る金額にも上限があります。
複数の証券会社に口座を持っていてもNISA口座を作成出来るのは一つだけで、証券会社を変える場合はNISA口座の引っ越し手続きが必要になります。
さらに、令和6年から新NISAが始まります。
新NISAは仕組みが単純化され、上限も拡大されます。
これから資産を作っていくことを考えた場合、NISAを利用するのはメリットが大きいので、最大限有効活用していきたいですね。
納豆には以下の特徴があります。
植物なのにタンパク質を多く含んでいます。
とくにこのタンパク質に含まれる必須アミノ酸が多く、
アミノ酸スコアは満点の100点です。
必須アミノ酸は体内で生成できない成分で、食品から摂取素津必要があり、
その値が高ければそれだけ効率よく摂取できることになります。
大豆製品のアミノ酸スコアは100なので、ほぼ満点ですね。
それ以外にも大豆由来のミネラルやビタミン、食物繊維も含まれています。
発酵食品というと、乳酸菌が豊富というイメージありますよね。
なので、これらの微生物が腸内環境を整えてくれます。
とくに納豆菌は胃酸にも強く、腸内環境改善に役に立ってくれます。
腸内環境が良くなれば、吸収された養分から様々なホルモンを生成することが出来、
それらはストレスの軽減などの役に立ってくれます。
納豆菌によって生成されるナットウキナーゼは動脈硬化予防に役立ってくれます。
動脈硬化、高血圧など気にしている方は積極的に食べた方が良いかもしれません。
栄養素についてはタカノフーズのサイトに詳しくまとめられています。
https://www.takanofoods.co.jp/fun/nattoeiyo/
これは納豆だけに限らず、過度に栄養を取り過ぎてしまうと、体に悪影響を及ぼす可能性が指摘されています。
納豆の場合は、プリン体を含んでいるため、食べ過ぎると痛風になりやすいと言われています。
そのため、納豆は一日1~2パックが適量とされています。
納豆の起源については様々な説があり、それに関する書物が残っていないため、何が起源だったかは不明のままです。
ただ、その節でも共通しているのは、
これらの要素が偶然組み合わさって、偶然納豆が誕生したと言われています。
納豆菌というのは、藁などの枯れ草の中にいる枯草菌の中の一つで、
納豆菌と枯草菌の遺伝情報(DNA)は酷似していると言うことが分かっています。
納豆の原料である大豆なんですが、
日本で使用されている大豆の大部分は輸入品です。
アメリカでは遺伝子組み換え大豆が流通しているそうですが、
日本に輸入されている大豆は全て遺伝子組み換えされてない大豆です。
なので、大豆に関してはこのへん心配しなくて問題なし。
しかし、YouTubeのショート動画で
納豆菌に対して遺伝子組み換えを行っている
ということが分かりました。
これはミツカンが行った研究のレポートで、
納豆独特の匂いを抑えるために、
納豆菌に対して遺伝子組み換えを行って匂いの元となる成分の生成を抑えることが出来た、と報告されており、
これで製造された納豆は「におわなっとう」という商品名で販売されているようです。
さらにレポートの中には2種類の遺伝子組み換え手法が記載されていますが、
結局どちらもいろいろ問題ありとされて採用していないと結論づけています。(これは危険だというわけでは無く、安全であるという理解が得られないという理由で)
で、結局従来の技法である「遺伝子相同組み換え技術」を使用したと記載されています。
ん?従来の技法?
このレポートは2007年に作成されたものなので、それより以前から遺伝子組み換え技術が存在していたことになります。
こちらに比較的わかりやすい説明が書かれています。
https://hp.brs.nihon-u.ac.jp/~inasweb/narai/narai/xiang_tong_zu_huanetoha.html
これを何とかしてまとめると、
もともと細胞は外的要因でDNAを損傷すると、近くの同じようなDNAと持つ細胞からDNAの情報を借りて自身のDNAの修復を行います。
ここでいう外的要因とは、紫外線やX線などですね。
最近話題になったあきたこまちRのケースではX線、
におわなっとうのケースでは紫外線を使用しています。
われわれ人間も太陽の光を浴びているので、太陽光を浴びているだけで紫外線を受け、DNAが破壊されているかもしれません。
でも人間であり続けているのはこういったDNA修復機能が働いていて、DNAを修復しているからなんですね。
これが同意組み換えという働きなのですが、これを利用して遺伝子組み換えを行います。
大前提として、DNAのゲノム解析を行い、DNAのどの部分がなんの働きをしているのか、が明らかになっており、そのDNAのみをピンポイントで破壊できる、ということです。
現在の技術ではこれらが可能になっています。
あきたこまちRではカリウムを吸収するDNAを、におわなっとうではにおい成分を生成するDNAのみを人為的に破壊します。
そのあと、細胞は勝手に同意組み換えを行い、DNAの修復を行うのですが、
その結果、目的通りの働きをしてくれるDNAを持つ細胞が生まれれば成功になります。
遺伝子組み換えというと、やっぱり最初は意図的に遺伝子を組み替えるというイメージがありました。
上のミツカンのレポートにある遺伝子組み換えの手法もこれに近いように思いました。
が、結局はこれらの手法は採用されませんでした。
今回採用した遺伝子組み換えの手法ですが、破壊方法も修復方法も自然界では普通にあり得る現象なので、
遺伝子を破壊する箇所は人為的であるものの、それ以外はすべて自然の細胞の働きによるもの、という認識です。
これは遺伝子組み換えに関する資料です。
62ページに安全性についての説明があり、最終的には厚生労働省の認可が下りないと市場に流通させることはできません。
当然ながら企業側でも遺伝子組み換えで終わりではなく、生産物の特性や安全性などの十分検証させ、問題なしと判断してから厚生労働省の審査を行っています。
さらに言うと、こういうハンドブックがあるということから、すでにかなり以前から遺伝子組み換え技術が当たり前のように身の回りにあることがわかります。
ぶっちゃけ、身の回りから遺伝子組み換え製品を排除することは不可能だと思いました。
すでに周りの生活に完全に溶け込んでいます。
さらに極論を言ってしまえば、品種改良とはDNAを変えることなのです。
われわれ人間だってみんなDNAは似ているものの、まったく同じ人はいません。
まったく同じDNAを持っていたら、それはクローン人間です。
従来の品種改良は従来の品種を掛け合わせて、目的の特性を持った個体が生まれるまで繰り返す、という手法でしたが、
このやり方では時間がかかります。
が、このやり方でやったとしても、結局は目的の特性を持ったDNAを持つ個体が生まれることを期待しての行為なので、
結局は同じことのようにも感じます。
そして、結局のところ、これが危険か安全かなんて自分でもわからないので、
これまでなんでもなかったから、そんなに気にすることじゃない。
とも思えます。
まぁ、我々は自由主義の国家に住んでいるので、何を買うかについても自由が保障されています。
気になる人は自分が食べているものを調べて、自分で選択して買うのが良いのではないでしょうか?
我々ITエンジニアからすれば、常にこれについて頭を悩ませます。
どれだけ一生懸命テストを実施したとしても、本番運用すれば必ず問題が出るからです。
なので、我々は問題が起きないように最大限の努力をしますが、絶対に問題起きないとは言えないのが正直なところです。
食品に関しても同じで、
全ての食品、食べても問題起きないとは絶対に言い切れません。
保存状態が悪かったら腐敗しておなか壊しますし、
体のいいものだけを食べ続けても、偏った食事はやっぱり体を壊しますし、
そもそも生活習慣が良くないから体を壊す、というケースもあるかと思います。
ワクチン否定派はなんでもワクチンのせいにしたがりますが、
健康についてもこれだけの影響が考えられるのだから、
むしろワクチン以外の可能性のほうが大きいのではないか、とも思えますよね?
そんなに気にするな。(気になるなら自己責任で調べればいい)
前回の続き。
【Docker】【GitLab】WindowsのDocker環境にGitLabサーバを立ち上げる。 | 自分、ぼっちですが何か? (taki-lab.site)
GitLabサーバからメール通知を送信できるようにします。
今回もこちらのサイトを参考にしています。
https://e-penguiner.com/gitlab-with-docker-onpremise/#index_id11
この中ではSTMPサーバとしてGmailを利用しているので、同じようにします。
つまりGmailのアカウントからGitlabの通知メールが届くイメージですね。
これを可能にするためには、Gmailのアカウント設定を変更し、
二段階認証を設定する
アプリパスワードを設定する
という手順が必要になります。
こちらのサイトに説明が書いてあります。
https://e-penguiner.com/app-passwd-two-step-verification-for-gmail/
アカウントの設定から二段階認証を有効にします。
このとき、電話番号を入力し、SMSで受信した番号を入力する必要があります。
この手順を完了すると、アプリパスワードの項目が表示されるようになります。
アプリパスワードの項目から進んでいくと、16桁の英数字が表示されます。
この値は今後表示されることは無いので、必ずメモしてください。
/srv/gitlab/config/gitlab.rbを編集します。
...
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.gmail.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "your-email@gmail.com"
gitlab_rails['smtp_password'] = "your-password"
gitlab_rails['smtp_domain'] = "smtp.gmail.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_tls'] = false
gitlab_rails['smtp_openssl_verify_mode'] = 'peer'
smtp_user_nameとsmtp_passwordは自分の環境に合わせて書き換えてください。
smtp_user_nameはGmailアカウントのメールアドレス、
smtp_passwordはアプリパスワード16桁の英数字を記入します(スペースは不要)。
保存したら設定の読み込み。
docker-compose exec gitlab gitlab-ctl reconfigure
そしてサーバ再起動。
docker-compose exec gitlab gitlab-ctl restart
ブラウザからGitlabにrootでログインし、ユーザーセッティングの画面へ。

Gmailのメールアドレスを入力すると、正しく設定できていれば、確認用のメールが届くので、リンクをクリックして認証を完了させる。
ドメインが合っていない場合はリンク先のドメインを良い感じに変更してください。
以下のようにdocker-compose.ymlを修正すると、Dockerビルド時にここまでの設定変更を反映できます。
version: '3'
services:
gitlab:
image: 'gitlab/gitlab-ee:latest'
restart: always
environment:
GITLAB_OMNIBUS_CONFIG: |
external_url 'http://gitlab.example.com:8080'
gitlab_rails['gitlab_shell_ssh_port'] = 2222
nginx['listen_port'] = 80
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.gmail.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "your-email@gmail.com"
gitlab_rails['smtp_password'] = "your-password"
gitlab_rails['smtp_domain'] = "smtp.gmail.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_tls'] = false
gitlab_rails['smtp_openssl_verify_mode'] = 'peer'
ports:
- '8080:80'
- '2222:22'
volumes:
- '/srv/gitlab/config:/etc/gitlab'
- '/srv/gitlab/logs:/var/log/gitlab'
- '/srv/gitlab/data:/var/opt/gitlab'
今回の講習会は決算についてでした。
確定申告はその年の1月1日から12月31日までが対象となり、
翌年2月の期限までに確定申告する必要があります。
で、今回は確定申告提出前の決算の話です。
というか、これまでやってきた仕分けないように間違いが無いかの確認がメインでした。
死んだ親父は全部手書きでやってたらしいけど、メッチャ大変だったと思うなぁ。
パソコン使える今の時代に感謝だぜ。
データ書き換えれば修正できちゃうからね。
これを見れば入力ミスがあるかどうか、一発で分かるらしい。

見せられるところが少なくてすまねぇ。
多分手書きだと計算ミスで数字が合わないとか起こりそう。
自分はパソコンで仕事用のカードと銀行口座の情報を読み込んで作成しているので、基本的に計算ミスは起こらない。
しかし、仕分け項目を間違って入力すると、この表がおかしくなります。
今回の講習で分かったのは、
期末残高がマイナスになることはあり得ない。
借方金額は主に収入関連の数字が入る。(報酬、事業主貸、クレジットの返済額等)
逆に貸方金額は支出関連の数字が入る。(経費など)
なので、数字が入ってはいけないところもあります。
左のリンクからそのリストが表示され、修正出来るのが便利ですね。
そして、このデータは来年度の青色申告の初期データになるので、口座残高やクレジットカードの未払い金額が一致することも確認しましょう。
あとは在庫品の棚卸しとかありましたけど、オイラには余り関係ないことだったので、割愛。
こちらの記事を参考にしました。
https://e-penguiner.com/gitlab-with-docker-onpremise/#google_vignette
今回はローカルのみでの利用を想定しているので、暗号化はしません。
前提条件として、WSL2の有効化とDocker Desktopのインストールが必要です。
そして作業はWindowsストアアプリからLinuxをインストールして、Linux上に構築します。
適当なフォルダを作成し、そのなかにdocker-cmpose.ymlファイルを作成。
version: '3'
services:
gitlab:
image: 'gitlab/gitlab-ee:latest'
restart: always
environment:
GITLAB_OMNIBUS_CONFIG: |
external_url 'http://gitlab.example.com:8080'
gitlab_rails['gitlab_shell_ssh_port'] = 2222
nginx['listen_port'] = 80
ports:
- '8080:80'
- '2222:22'
volumes:
- '/srv/gitlab/config:/etc/gitlab'
- '/srv/gitlab/logs:/var/log/gitlab'
- '/srv/gitlab/data:/var/opt/gitlab'
これの内容を説明すると、
Docker作成時に、GitLabの最新バージョンを使用します。
※念のため言うと、実際業務で使用する場合は必ず特定のバージョンを指定するらしい。今回のように常に最新バージョンはアウト。
ポート番号はホスト側8080とコンテナ側80、ホスト側2222とコンテナ側22が接続されます。
80はhttp、22はsshのデフォルトポート番号ですね。
別の番号を使用する場合は設定変更が必要です。
volumesにコンテナのディレクトリにホストのディレクトリをマウントさせます。
この設定では、
コンテナ /etc/gitlab – ホスト /srv/gitlab/config
コンテナ /var/log/gitlab – ホスト /srv/gitlab/logs
コンテナ /var/opt/gitlab – ホスト /srv/gitlab/data
つまりコンテナ側で作成したファイルが、ホストの上のディレクトリに出力されるわけですね。
これでコンテナを立ち上げます。
docker-compose up -d
立ち上がり完了まで待ちます。(結構時間かかります)
docker-compose ps
これで、statusがhealthyと表示されれば立ち上がり完了です。
ブラウザでhttp://自分のIPアドレス:8080にアクセスしてGitLabの画面が表示されればOKです。
Linuxのコンソールで以下のコマンドを入力します。
docker-compose exec gitlab gitlab-rails console -e production
Rubyのコンソールに切り替わるので、以下のコマンドを入力します。
user = User.where(id: 1).first
user.password = '新しいパスワード'
user.password_confirmation = '新しいパスワード'
user.save!
exit
パスワードは複雑な文字列で入力しないとエラーになります。
正常に入力完了したらログイン画面からrootでログインできることを確認して、
ログイン出来たらOK。
こちらの記事を参考にさせて頂きました。
https://road-bike.net/archives/42971
元々WordPressには投稿記事をX(旧Twitter)に自動ポストする機能があったのですが、
X(旧Twitter)のAPI有料化に伴い、この機能はWordPressから削除されました。
それ以降、作成した記事は手動でX(旧Twitter)にポストしてたのですが、
やっぱりめんどくさい。
なので、代わる方法を調べた結果、上のリンク先のページにたどり着きました。
とりあえずやってみました。
BufferはSNS等に、設定した時間に自動的に投稿してくれるWebアプリです。
WordPressに専用プラグインを追加することで、
WordPressに投稿した記事を元にポスト内容を作成してBufferに登録してくれます。
あとは時間になればBufferが自動的にポストしてくれる、という仕組み。
まず、Bufferにアカウントを作成(英語です)。
アカウントを作成したらX(旧Twitter)のアカウントと連携。
WordPressのプラグインから「WP to Buffer」を検索し、インストール&有効化します。
設定でポストフォーマットを設定できます。
あとはブログ記事を作成して、Bufferに登録されているのを確認したらOK。
時間になったら勝手にポストしてくれます。

よきよき。
Bufferの動作確認テスト
自分はGoogle Pixel Watch2を使用しているのですが、
12月頭ぐらいから睡眠スコアが表示されなくなりました。

最初これ見たときは、
また睡眠が悪化したのか??
と思って、お酒も抑えて、しっかり眠るためのルーティンもしっかり行って様子を見てたのですが、一向に改善されませんでした。
この時期、お酒をケース買いして、おうち晩酌してたので、それが影響したのか?とも思って、
これから次の案件獲得に向けてしっかり体調を整えないといけないという状況でもあったので、
結構ヒヤヒヤしていましたが、

これって睡眠が悪化したのでは無く、正しく計測できていないのでは?と思い始めたのが昨日。
端末(Google Pixel Watch2本体)を再起動しました。

昨日の夜、端末を再起動し、睡眠データを取得させてみました。
はい、きちんと測定できていました。
しかも80というギリ合格ライン。
なので、何か怪しい挙動を始めたら再起動するのはオススメ。