2026-08-06

Findy AI Meetup in Fukuoka #7 に参加してきました

Findy AI Meetup in Fukuoka #7 - connpass に参加してきました。

今日勉強になったこと

AI時代こそ、コーディングルールやテストコードの整備などの基本が大事
基本情報技術者試験が大事
githubにチケットを切って、後はAIにやらせてしまうやり方は、第2段階に入っている
「AIの成果物チェックは本体コードは見ずにテストコードのチェックをしている」という話を聞けた
技術者向けドキュメントでwordやexcelは使わない。markdownやnotionを使う

特に2点目の「基本情報技術者試験が大事」という話は納得いった。

僕らが若手の頃は情報処理技術者試験はあくまで理論でそれよりもコードを実際に書ける能力が大事だったのでコーディングの実務能力が大事だったけど、今はコーディングはAIがやってしまうのでコーディング実務能力はそんなに大事ではない。それよりも基本をしっかり抑えられているかどうかが大事で基本情報技術者を取っている新人と取ってない新人は１年経つと差が顕著に出てくるそう。

自分の部署の若手には、この話をしてもしようがないかなと最初は思った。私の部署はいわゆる「情シス」なので、バリバリの技術者である必要はないから。でもやっぱり機会を見て話すことにする。僕の話をきいてどうするかは若手が”知った上で”決めればよくて、僕が話さなければ"知らない"のでアクションをとりようもないからね。

2026-06-17

Findy AI Meetup in Fukuoka #6 に参加してきました

Findy AI Meetup in Fukuoka #6 - connpass に参加してきました。

普段できないような今どきのIT系技術の会話ができてとても楽しかったです。

今回のイベントのテーマはAIによるレビューのお話でしたが、発表者のお話が早いのと、自分がまだAIにレビューさせることしたことすらない低いレベルだったので、「へー、そうなんだ、ふーん」という感じであまりついていけてない感じでした。

ただ、開始前の雑談やその後の懇親会などで会社にいるだけでは聞けないようないろんなお話が聞けて楽しかったです。

勉強になったこと

AIに「レビューして」と指示したときは、レビューアーモードになるので、コードを書くときとは違うAIの振る舞いをするらしい。AIが書いたコードをAIにレビューさせるのは、コードを書いた本人がレビューするような感じでピンとこなかったのだけど、やってみようという気になった。
Findyさんは営業分析などでBIツールを使うのではなく、自然言語の問い合わせをAIにSQLクエリなどに変換させてデータベースからデータをひろって分析させて、傾向調査をするようなレベルに取り組んでるとのこと。
自分の会社ではまだBIツールを入れてる段階なので、ずっと先の話にしかならないが、先端企業はもうそういうレベルに取り組んでるんだなとおもった。
AIのノウハウをチームで共有する方法としては、会議や発表会などをつかってやっているというお話を聞けた。場をつくらないといけないんだなと思った。

最後に驚いたこと

私はAngularを使っているのですが、あまり流行らない技術なのかなと思っていて、何気なく「Angularあまりはやらないですよね。」と会話していた方が実はAngularの福岡コミュニティの主催をしている方々の一人だったこと。終わったあとにネットで調べて気がついて驚きました。さらにXをフォローしようと思ったら、知らないうちにフォローしていた人でした。

次回があるので、その時にAngularのもっとつっこんだ話をしてみようと思いました。

次回も参加予定です。楽しみです。

2026-05-08

Angular 19：バリデーションの debounce 待ちを fakeAsync で解決する

パスワードバリデーターなどで timer(500) を使って debounce 処理を入れた場合、テストの書き方に工夫が必要です。

普通にテストを書くと、入力後に 0.5 秒経過するのを待ってからじゃないと結果を検証できません。たかが 0.5 秒ですが、テストが増えるたびにこの「待ち時間」が積み重なるのは嫌ですよね。

そこで fakeAsync を使いましょう。

実装のイメージ

例えば、以下のようなバリデーターのテストを想定してみます。

// validator側で 500ms の debounce がある想定
it('500ms経過後にバリデーションが実行されること', fakeAsync(() => {
  //controlの処理は省略。
  //controlに設定されたvalidatorの内部で timer(500)が使われている

  control.setValue('password123');

  // まだバリデーションは走っていない
  expect(control.pending).toBe(true);

  // 501ms 進める（実際には待たない！）
  tick(501);

  // 時間が進んだので結果が確定している
  expect(control.valid).toBe(true);
}));

ポイント

fakeAsync でテスト用関数を包む
tick(501) を呼ぶ

これだけで、コード上は 0.5 秒経ったことにして、即座にアサーションを実行できます。非同期処理が絡むテストをサクサク動かしたい時の強い味方です！

この記事はAI（Gemini）による推敲・構成の提案を受けて作成しました。

2026-03-22

systemdで1分毎にプログラムを動かす設定

例えば、my-programというサービスを定義して、１分毎に動かす場合の設定

1. /etc/systemd/systemの下に設定ファイルを２つ(my-program.service, my-program.timer)配置する

1. 1. my-program.service

[Unit]
Description=My Program Service (Oneshot)
After=network.target

[Service]
Type=oneshot
ExecStart=/path/to/my_program
WorkingDirectory=/path/to
User=worker-user
Group=worker-group

1. 2. my-program.timer

[Unit]
Description=Run My Program every minute

[Timer]
OnCalendar=*:0/1
Unit=my-program.service

[Install]
WantedBy=timers.target

2. systemctlでtimer設定を有効化

sudo systemctl enable --now my-program.timer

3. 設定確認

sudo systemctl list-timers my-program.timer

4. 標準出力ログ確認( -f は tail -fと同じ監視するオプション)

sudo journalctl -u my-program.service -f

2025-12-17

angular 19：ng testでgtagでエラーを回避

angular 19で ng testするとgtagでエラーになりテストが動かなかった。

回避方法は

tsconfig.spec.jsonのtypesの中に"@types/gtag.js"を追加する

例）

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "outDir": "./out-tsc/spec",
    "types": [
      "jasmine",
      "@angular/localize",  /* ここの末尾にカンマを入れて */
      "@types/gtag.js"      /* この行を追加
    ]
  },
  "include": [
    "src/**/*.spec.ts",
    "src/**/*.d.ts"
  ]
}

2025-11-22

dockerでよく使うコマンドメモ

イメージからコンテナを作成し、起動
- シンプル
  docker run -it (image name) (start program path)
  ex: docker run -it debian /bin/bash
- データボリュームをマウント
  docker run -it -v (datavolume name):(mount point) (image name) (start program path)
  ex: docker run -it -v vol01:/mnt deb_pgsql /bin/bash
- 特定のユーザーで実行
  docker run -it -u (user name) (image name) (start program path)
  ex: docker run -it -u postgres deb_pgsql /bin/bash
  ※-uのユーザー名はコンテナ側に設定されていれば基本はOK
- ポートをマッピング
  -p (host port):(container port)
  ex: -p 80:80
コンテナからイメージを作成
docker commit (container-id) (image-name)
イメージのタグを変更
docker tag (current-image):(current-tag) (new-image):(new-tag)
ex: docker tag
コンテナスタート
docker start -ai (container-id)
デタッチとアタッチ
- デタッチ（コンテナを起動したまま抜ける）
  ctrl+P -> ctrl-Q
- アタッチ（起動したコンテナに接続）
  docker attach (container-id)
起動中のコンテナに接続
docker exec -it (container-id) /bin/bash
コンテナ状態確認
- 実行中のみ
  docker ps
- 停止中のものを含む
  docker ps -a
データボリューム作成
docker volume create --name=datavolumename
その他
- ユーザーの環境変数設定などのログイン時処理は.bashrcではなく.bash_profile

2025-11-13

Tracのバージョンアップ手順メモ

Tracのver 1.2から1.4へのバージョンアップ作業をした時のメモ(Windows)

環境

Pythonのバージョンは2.7.17を使用
データベースにPostgreSQL 11を使用

作業手順

(python2が動作するよう環境変数等の設定）
virtualenvでtrac1.4用の環境を作成
```
python -m virtualenv trac14env
```
作成した環境にセット
```
cd trac14env
Scripts\activate.bat
```

pipが動かなかったので、プロキシ設定

set HTTP_PROXY=http://(ip address):(port)
set HTTPS_PROXY=http://(ip address):(port)

Trac 1.4.4とpsycopg2をインストール
```
pip install Trac==1.4.4 psycopg2
```
pgAdmin4を使用してデータベースをtrac1.4用にコピー
1. trac1.2で使用していたデータベースをバックアップ
2. 新たにtrac1.4用データベースを作成
3. バックアップしたデータを新しいデータベースにリストア
エクスプローラでtrac1.2のフォルダを作成したtrac14envの下にコピー
コピーしたフォルダの下にある(プロジェクトフォルダ)\conf\trac.iniを編集
database=の値を新しく作成したtrac1.4用データベースに設定

アップグレード作業

trac-admin (プロジェクトフォルダ絶対パス) upgrade
trac-admin (プロジェクトフォルダ絶対パス) wiki upgrade

動作確認

tracd --port 8000 --basic-auth=(省略) (プロジェクトフォルダ)