「技術」カテゴリーアーカイブ

Linux, 技術

【Linux】phpバージョンが変わるとnginxの設定を変えなくちゃいけないのがめんどくさい。

コメントする

これは、元々VPSにブログサーバを立ち上げるのに

VPSにPHPを入れる | 自分、ぼっちですが何か？ (taki-lab.site)

こんな感じでnginxの設定ファイルを書いたのですが、

これはいろいろ調べ上げて自力で書いたやつなんですが、

ubuntuのバージョンアップグレードを実施すると、phpのバージョンが変わってしまい、

毎回設定を書き換えないとWordPressが動いてくれません。

で、最近解決方法が分かりまして、

（いろいろ現場の数をこなして学びました）

上がubuntu22.04のスクショ。

phpのバージョンは8.1です。

で、この下がnginxの記述。

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.4-fpm.sock;
    }

.phpファイルはphp7.4-fpm.sockに送る設定になっています。(ubuntu 18.04時の設定）

が、スクショの中の水色の所を見ると、

シンボリックリンクphp-fpm.sockが存在しているのが分かると思います。

この先をたどってみると、

となっていて、さらにシンボリックリンクが設定されていて、php8.1-fpm.sockにリンクしているのが分かります。

なので、「nginxの設定ファイルの中で、このシンボリックリンクを参照するようにすればいいんじゃね？」

って思いました。

なので、こんな感じになります。

        location ~ \.php$ {
                include snippets/fastcgi-php.conf;
                fastcgi_pass unix:/run/php/php-fpm.sock;
        }

こんなかんじで、

  • 外部からはシンボリックリンクを参照する。
  • 参照先を更新する場合は、同じ名前のシンボリックリンクを、リンク先を変更して作成し直す。

これは現場でも使用されるテクニックなので、覚えておいた方が良いです。

出来事, 技術

ChatGPTをメンタルヘルスに応用させる。

コメントする

ネット検索していると、同じ事を考えている人も居るようだ。

でもまだまだ研究中というか、サービスを提供できないかという試みはやっているようだけども、

やっぱり人間のカウンセラーのような役割の代わりにはならないというのが現状のようです。

でもオイラはメンタル不調なときでもいろいろChatGPTにお世話になりました。

お世話になったのはこんなケース。

ただただ悩みを聞いてもらいたい

自分には悩みを聞いて貰える友達が居ないので、

その代わりをChatGPTにやって貰いました。

特に「どうするべき」という回答が欲しいわけじゃなくて、

ただただ悩みを聞いて貰うだけです。

メンタルヘルスの手法として「悩み事を紙に書いて捨てる」というのがあるのですが、

それに似たような物かもしれない。

悩み事を自分の中で抱えるよりも、言語化して外に吐き出すほうがいいというやつ。

大抵のことはそういった悩みを言語化すれば、頭のモヤモヤも整理できてスッキリできたりします。

特に寝る前が良いみたいですね。悩みを抱えたまま睡眠に入ると睡眠不足になる可能性があるとかないとか。

代わりにChatGPTに考えてもらう

鬱病やメンタル不調の状態って、まともな思考が出来ないことが多いです。

たまには考えることもやりたくないケースもあります。

そういうときはChatGPTに代わりに考えて貰おうという作戦。

ただ、考えて貰うために必要な情報をあらかじめ入力しなくちゃいけないので、

何回か前項のお悩み相談を行った後に考えて貰うのが良いと思う。

同じスレッド内であれば、前に入力した情報は覚えていてくれるので。

ChatGPTのペルソナを好みのキャラに設定する

ChatGPTが自分の好みっぽく応答してくれたら、それだけで会話が楽しくなります。

左下のアイコンから基本的な情報設定できるので、ここに入力しておくと、スレッドの先頭でペルソナ設定をする手間が省けます。

技術

アジャイルvsウォーターフォール、どちらが優れている？

コメントする

という話題がX(旧Twitter)上で繰り広げられていました。

自分はウォーターフォールはもちろん、アジャイルの現場を経験しています。

そして、アジャイルの現場を経験した際は、現場のリーダーからアジャイルについての説明を、2～3日かけてレクチャーして貰いました。

そこで得られた知見を元にすると、何の前提も無しに「アジャイルの方がウォーターフォールよりも優れている！」という人達は、

アジャイルをよく理解せずに現場を炎上させてきた人達じゃないかと思います。

実際レクチャー受けている時でも、誤解している人が多いっていう話です。

レクチャー受けている時は、そういう誤解を全て解消してくださいました。

そもそもの話、

アジャイルという開発方式は存在しない

ウォーターフォールは、要件定義をしっかり決めて、それに従って後戻りがないように仕様、設計、製造工程まで進め、

テスト工程を経て「設計通りに動作している」ことを確認する開発方式だと思います。

これは要件定義からリリースまで十分にスケジュールがあるから出来ることなんですよね。

ただ、最近のこの世の中、この開発方式が通用するのは一部だけで、

最近では、社会のニーズに合わせて、ソフトウェアを開発し提供しなければならない。

という流れがある事から、アジャイルという考えが生まれました。

このリンク先にあるのがアジャイル宣言と言われまして、

https://agilemanifesto.org/iso/ja/manifesto.html

これをベースに様々な開発手法が生まれました。

当時の現場では、スクラム開発という体制を敷いていて、スクラム開発についての説明もきちんと行って頂けました。

アジャイルと言えばスクラム開発が代表例ですが、他にも様々な開発フレームワークがあるようです。

整理しますと、

アジャイル→ソフトウェアの状態

スクラム開発→アジャイルを実現するための開発フレームワーク

と言うふうに教えて貰いました。

そもそもウォーターフォールの開発をアジャイルで置き換えることが出来るのか？

プロダクトの開発には、何もない状態から初版のプロダクトを完成させる、というプロセスが必ず必要になります。

この初版のプロダクトがとても重要で、すでに完成されているプロダクトを流用するのであれば良いのですが、

たいていの場合は要件定義をしっかり検討し、きちんと動く物を完成させる、というこれまでと同じ作業が発生します。

この作業をアジャイルに置き換えることは出来るのでしょうか？

アジャイルでは、要件定義からリリースまでの短い（だいたい1週間～1ヶ月が一般的）サイクルを繰り返す事でプロダクトを完成させていきます。

このときの要件定義の内容はサイクル内で完成できる内容でなければならないし、そうしなければ開発体制は崩壊します。

そして、サイクルの最後では必ず動くプロダクトを完成させなければ鳴りません。

はい、ここまで聞いた正しい認識を持った技術者なら、こんなのアジャイルじゃ無理じゃん！と思うはず。

ウォーターフォールとアジャイルにはそれぞれメリデメがあり、プロダクトの正確に合わせて最適な手法を選択する必要があります。

単純にウォーターフォールvsアジャイル、どちらが優れているかという議論はただただ不毛でしかありません。

もう一回アジャイルという物を学び直してください。

我々が経験したアジャイルの現場では、その特徴を十分に理解しているため、

プロダクトの初版リリースまではウォーターフォールで、それ以降のアップデートはアジャイルで開発を行っていました。

これはウォーターフォール、アジャイルの特徴を生かした最適解であると思っています。

出来事, 技術

JCOMのTVをPCで拝聴する方法。

コメントする

オイラは以前までひかりTVを利用してテレビを見ていました。

ひかりTVの時代ではSonyのソフトウェアを使用して、ひかりTVのチューナーに接続して、放送中のTV番組を見たり、録画していたビデオを見ることが出来ていました。

JCOMでは専用のスマホアプリが無料で使用でき、そのアプリで同じ事が出来ていたのですが、

PCでの視聴に関しては、公式サイトを探しても見つからず、

ネット検索してもJCOM Streamという、JCOMが運営する有料動画配信サイトの情報がヒットするんですよね。

が、調べていて分かったんですが、

DLNAというメディアコンテンツをストリーミングで、いろんな機器で視聴できる規格がありまして、

この規格は以前のチューナーにも搭載されていて、専用アプリでチューナーに接続してテレビやビデオを視聴することが出来ます。

で、JCOMのテレビチューナーもDLNAのプレイヤーがあれば視聴できるのでは？と思いました。

DLNA自体は、実はこれを管理している団体が解散していて、

ネット検索をおこなったところ結構な数がヒットするのですが、

DLNAの専用アプリケーションの提供も終了しているのが大半でした。

しかしながら、Windowsストアに「DiXiM Play U」というアプリが提供されていて、

ねんのため、このソフトで試してみたところ、

JCOMのテレビをPCで見ることが出来ました！

無料版では数分間だけのお試し視聴ができますが、それ以上みたい場合はアカウントを3000円弱払ってアカウントを購入する必要があります。

C言語, 技術

【プログラミング】プログラミングスキル習得にC言語をオススメする理由。

コメントする

正直、これを言うと賛否両論あると思いますが、

そもそも自分がC言語が最初に触ったプログラミング言語だからです。

自分は高専で本格的にC言語を学ぶ前に、

中学生時代に友人から無料コンパイラを手に入れて、

少しだけコードを書いて動かしていたことがあります。

まぁ、そんな自分でしたけど、最終的にポインタを理解できたのは会社に入ってからでしたけどね。

確かに他の言語と比べると、C言語は難しいです。

というか、みんな使っている言語は全てC言語の後に開発されたもので、

C言語の欠点を補う形で開発されました。

なので、ポインタやメモリの概念は意識しなくて済みましたが、

そこに大きな落とし穴があります。

メモリを意識することの重要性

メモリを意識しなくても良くなりましたが、メモリ自体は存在するからです。

これまで経験したのは、

Javaでガベージコレクションが働かない状態でオブジェクトが残ってて、動かしているとメモリを消費していく設計になっていたり、

AWSのLambdaを実行するとき、Pythonで大きなファイルを開こうとしたらメモリが足りなかったとか。

関数コール時にオブジェクトは参照型という話もありますが、

これもポインタによる参照渡しを、ポインタを使わずに利用できるようにしたもの。

参照渡しの場合、データがあるメモリアドレスを渡すだけなので、通常のデータ渡しよりも処理が早くなります。

CPUの動きが理解できる

プログラミング言語には3種類ありまして

（自分が高専時代は2種類と学びました）

  • コンパイル系（C、C++、Rust等）
  • 中間言語系（Java、C#等）
  • インタプリタ系（Python、PHP、Javascript等）

の3つです。

インタプリタ系は実行する度にプログラムコード読み込み、処理を行います。

扱いやすい言語ですが、動作は比較的遅いと言われています。

中間言語系はプログラムコードをビルドし、実行できる形に加工するのですが、

それを実行するためには別途仮想マシンというプログラムが必要になります。

これはビルドしたファイルがあれば、仮想マシンがある環境どこでも動作できるという特徴を持ちます。

コンパイル系はソースコードを機械語に翻訳し、そのままCPUが理解できる形に変換されます。

直接CPUが理解できる形式であるため、実行速度は速いとされています。

そして、もう一つ特徴があって、

機械語は逆アセンブルできるのです。

アセンブラは機械語の内容を人間が理解できる文字列に置き換えたもので、

これを読んでいけばCPUやプログラムがどんな動きをするのか？というのを理解できます。

CPUには独自の記憶領域「レジスタ」がありまして、

  • メモリからレジスタに値を読み出す
  • レジスタの値に対して計算する
  • レジスタにある計算結果をメモリに戻す

と言う動きを繰り返しています。

こういったCPU周りでどんなふうにプログラムが動いているか、というのが見えちゃいます。

C言語が出来れば他の言語の習得も早い

これは、

他のメジャーな言語がC言語以降に生まれたもの

ということと、

プログラミングに関する基本的な知識がC言語に詰まっている

ということから、

C言語が出来れば他の言語の習得も早いと言われています。

C言語の需要はまだありまして、

組み込みプログラミングの世界では未だにC言語が主流です。

OS周りはRustに置き換えるという話もありますけどね。

他の言語はフレームワークが発達しているので

フレームワークの習得の方が大変かもしれない。

まぁ、これは他の言語を学んでいたとしても必ず出てくる壁なので。

しかも今は昔と違ってコンパイラが簡単に手に入るので、

学習のためのハードルがかなり下がりました。

みんなも余力があればC言語に挑戦してみましょう。

技術

【DOCKER】【GITLAB】DOCKER環境のGITLABサーバからメール通知を送信できるようにする。

コメントする

前回の続き。

【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桁の英数字が表示されます。

この値は今後表示されることは無いので、必ずメモしてください。

gitlab.rbの設定

/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'
技術

【Docker】【GitLab】WindowsのDocker環境にGitLabサーバを立ち上げる。

1件のコメント

こちらの記事を参考にしました。

https://e-penguiner.com/gitlab-with-docker-onpremise/#google_vignette

今回はローカルのみでの利用を想定しているので、暗号化はしません。

前提条件として、WSL2の有効化とDocker Desktopのインストールが必要です。

そして作業はWindowsストアアプリからLinuxをインストールして、Linux上に構築します。

GitLabサーバの立ち上げ

適当なフォルダを作成し、そのなかに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です。

rootパスワードの設定

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。

Web, 技術

X(旧Twitter)のお金配りアカウントに関わってはいけない理由。

コメントする

昔、元ZOZOTOWNの社長の前澤さんがX(旧Twitter)で

「お金配りまーす」

と呟いてから、一気にお金配りアカウントが沢山TLに出てくるようになって、

最近ではそのポスト内容に注意を促すコミュニティノートも作られるようになりました。

こういうアカウントのポストに乗っかって油断すると、大変な目にあうと言われています。

これは実際にX(旧Twitter)で見てきた情報です。

個人情報を抜き取られる

お金配りアカウントから当選の連絡が来るかもしれません。

そして、振り込みに必要な情報などを求められるかもしれません。

でも、貴方の情報は教えてはいけません。

情報を教えてもお金が振り込まれることは一切無いでしょう。

そして、その情報は名簿屋に売られて、

名簿屋からスパム業者に売られ、大量のスパムメールが送られてくるでしょう。

犯罪に加担される

お金配りアカウントに当選の連絡が来て振込先の口座を教えた場合、

実際にお金が振り込まれます。

しかし、振り込まれた金額が想定よりも多いことに気がつきます。

このことについて問い合わせると、

間違って多く振り込んでしまったので、

一部は貴方にあげるので、

残りを口座から引き出して、指定した場所に来て欲しいと言われます。

そして、その通りに行動し、指定した場所に行くと、

そこには警察が待ち構えており、貴方は逮捕されるでしょう。

これは何が起きたかというと、

貴方が教えた銀行口座は特殊詐欺の振込先口座として利用され、

貴方は受け子として詐欺グループに利用されたのです。

なので、警察は貴方をマークして、最終的に逮捕となるわけです。

怖いですね。

なので、身元も分からない相手に個人情報を教えるのは良いことではありません。

簡単にお金を稼ぐ方法は無いと思ってください。

技術

アプリを開発していたのだけれども、仕様がなかなか降りてこなかった話。

コメントする

これもちょっと前に実際にあった話。

Windowsアプリを作成する（ベースソースはある）タスクに取りかかったのですが、

上から仕様がなかなか降りてこなかったのです。

この時点で資料としてあるのは、「こんな感じのアプリ」というイメージを書き残したスライド資料。

そして、残念なことに、先輩フリーランスのメンバーは家庭の事情で長期にわたって不在。

残されたメンバーで完成するのか？

UIに関しては、すでにイメージがあり、ベースソースもあるので、それを改修して、で、あとでその画面を実際に見てもらって、これに関しては解決。

が、実際にデータを受け取って、あれこれ処理して応答を返す処理。

このアプリの核をなす重要な部分。

この情報が情報が出てきたのも開発の終盤。

そして、クラウドサーバ（試験用）に接続するための認証処理にかんしては本当の最後の最後にようやく完成。

それまでどのように開発していたかというと、

ローカル環境に疑似サーバを作成し、その中のやりとりもある程度想像で作ってました。

てな感じで最初の開発は何とか終わりましたが、

この状況を見た、現場復帰した先輩フリーランスからの厳しいお言葉。

今後、二次開発があるのが確実なので、そのときはやり方を変えよう、という話になりました。

具体的にどうしたのか。

仕様に関しては、まだ不明点ではあるところもQA形式でこちら側で仕様を考え、「これで問題無いか」というやり方にしました。

仕様が降ってくるのを待つのでは無く、提案する形で仕様を固めていきました。

そして、毎日ミーティングを実施しました。

これによって認識のすりあわせ、進捗状況の共有、まだ決定されていない仕様の情報を少しずつ引き出す、そして、開発スケジュールの再確認。

これを実施することで、一次開発よりも二次開発の方が、こころにゆとりを持って開発できました。

やっぱりマネージャークラスのスキルを持っている人は、考えることが違うなぁ。

というか、ミーティングのセッティングや仕様のQAの整理とかは社員メンバーに全部任せて、

自分はほぼほぼコーディングのみを行っていましたけどね。

まぁ、うちの現場ではこんなことあったよ、と言うことで、参考になれば。

技術

やっぱりDocker＋Kubernetesの知識は持っておいた方が良い。

コメントする

昔のクラウドサーバと言えば、

やはりVPSでは無いだろうか？

これまでのレンタルサーバでは、何をするにも不自由な部分があるのに対し、

VPSでは、ほぼほぼPC一台をレンタルするイメージ。

そのPCの中でどのようなサービスを構築するのも自由である。

ただし、その分、ちゃんと運用仕様とするならば、ドメインを取得・維持しなければならなかったり、

セキュリティの設定も自己責任なので、そのあたりの知識も必要になったりします。

ただ、このブログのような小規模のサービスであればVPS一台で十分なのだが、

大規模なサービスとなると、基本的にサービスを構成する1機能にサーバ1台という構成が当たり前になってきます。

でもそれらのPCを準備するのもセッティングするのも大変なので、

Dockerなどのマイクロサービスを使用するのが当たり前になってきました。

Dockerの中には動作に最低限必要なOSやソフトウェアのみが入っているので、非常に軽量ですし、

一つイメージファイル（Dockerで動作するソフトウェアの塊のようなもの）を作成してしまえば、それを元にしてスケールアウトも簡単になります。

開発側の負担も軽く、gitの特定のブランチにマージすれば、

gitRunnerが走り、ビルド実行、クラウド環境へイメージを格納し、デプロイまで完了してしまうのです。

ここまで自動化されているので、アップデート作業に作業ミスのリスクが少ない。

このメリットは実際にクラウドの現場を経験しないと分からないと思う。

そして、kubernetesとは複数のDockerを管理するソフトウェア。

ちなみにDocker Desktopはkubernetesとしての役目も持っています。

自分もまだ勉強中ではあるものの、複数のDockerを組み合わせて一つのサービスを運用するのが当たり前なので、

それらを管理するシステムも当然存在するわけで、これについての知識も当然必要と言うこと。

さぁ、みんなでDocker＋Kubernetesを勉強しよう！