---
# System prepended metadata

title: 姫路IT勉強会 2023.02
tags: [histudy]

---

---
title: 姫路IT勉強会 2023.02
langs: ja-jp
---
姫路IT系勉強会 2023.02
=======================

* 開催日: 2023/02/18 13:15
* 司会: wateさん
* 参加人数: 参加者: 8名 (うち学生：0名)
* HackMD: <https://hackmd.io/NPNTELlFTs2iIWMl42naEg>
* connpass: <https://histudy.connpass.com/event/274401/>
* ハッシュタグ：[#histudy](https://twitter.com/search?q=%23histudy&src=typd)
* [姫路IT系勉強会 Discordへ参加する](https://discord.gg/rZCeScB)
    * **オンライン開催の場合はDiscordのボイスチャットを利用しています**
    * Discordは無料プランに乗れる人数(10人以内)なので使っています。
    * 有料版でも$15/月程度なら払えなくもないですね。
    * Discord以外にも色々ありますので、人数が増えたら検討しましょう。
* [姫路IT系勉強会 Slackへ参加する](https://join.slack.com/t/histudy/shared_invite/zt-ugowinom-ZG0ORhstkrqQGVyjksr_OA)
    * 勉強会当日以外での質疑応答やメンバー同士のコミュニケーションに利用しています
    * Slackでの話の流れから、突発的に臨時イベントが企画されされるケースがあります

最近のニュース
-----------------

* [姫路IT系勉強会](https://histudy.jp/) 
* [Chat-GPT](https://openai.com/blog/chatgpt/) とかのAIがはやってますね
    * [catgpt](https://catgpt.wvd.io/) にゃー
    * [docsgpt](https://github.com/arc53/docsgpt) わんわん
    * [bard](https://k-tai.watch.impress.co.jp/docs/news/1476510.html) ぴよぴよ
* 東京の海底に[ゴジラ](https://www.kaiho.mlit.go.jp/info/kouhou/r4/k230214_1/k230214_1.pdf)が!
* [NOSTR](https://github.com/nostr-protocol/nostr)は新しいSNSだよ。
    * マテ、これ消せないんじゃね?
* [アトラシアン、新サービス「Jira Product Discovery」発表。製品開発チームがアイデアを集め、優先順位を付け、計画と進捗を共有](https://www.publickey1.jp/blog/23/jira_product_discovery.html)
* [core-jsの開発者、支援を求める](https://opensource.srad.jp/story/23/02/16/1310246/)
    * [zloirock/core-js](https://github.com/zloirock/core-js)
* それゆけバグ踏み! みんなで人柱になろうぜ
    * [Homebrew 4.0.0](https://brew.sh/2023/02/16/homebrew-4.0.0/) 
    * [Laravel 10リリース、PHP 8.1以降をサポート](https://gihyo.jp/article/2023/02/laravel-10)


自己紹介
---------------

* 変ジニアの集まりです！(キモい)
* 昼ごはん食べてて遅れましたー（のがた）

お題
---------------

ここの下にお題(相談したいこと、発表したいことなどなんでも)お書きください。  
※ 記載するお題は参加者一人につき1つだけ記載するようにお願いします。  
※`### <ネタ>+(名前)`の形式でお題を記載してください。

### お題をここに書く(名前を書く)

(概要や背景などをここに書く)

### フリーランスのための確定申告、青色(雑談)

* フリーランスが多いから確定申告のための勉強会を開催してもいいかもしれない。
    * [slack](https://join.slack.com/t/histudy/shared_invite/zt-ugowinom-ZG0ORhstkrqQGVyjksr_OA)で確定申告手伝ってっていえば突発で開催するか
    * ただし売り上げなどが公開されちゃうので注意してください。
* 確定申告のサイトのつくりがおもしろい
    * デジタル庁ががんばって電子化されている[e-tax](https://www.e-tax.nta.go.jp/)はレベルがバラバラ。
    * このページは郵便番号いれたら住所まで自動入力されるのに次のページは全然できてないなど
* [やよいの青色申告](https://www.yayoi-kk.co.jp/products/aoiro_ol/)は便利
* マイナンバーポータルのパスワードとかで対応
* コロナ禍で税務署に人を来させないような方針ができたから?
* 自宅を事務所にする、話で面積を指定していけないなど、税理士に聞けるサービスが便利。青色だけだけど。
* 個人事業主はぼろもうけをしているなど目立つことがなければ、あまり確認されない?

### Bluetooth LEの飛距離について(妖介)
- 最近やった案件で幼稚園などの登下校バスの置き去り対策・検出がありました
    - 対策ソリューションが各社からリリースされた。組み込み系が多い
- [Bluetooth](https://www.bluetooth.com/)ビーコンを使ってバス内の親機と接続で検出してるそうです
    - 車庫に入ったときに接続が残っていれば置き去りの可能性あり
- [Androidの公式ドキュメント](https://www.android.com/intl/ja_jp/articles/bluetooth/)によれば接続距離10～100mらしいんですが、実際のところどうなのか有識者がいらっしゃったらお伺いしたいです
- アシックス製品はGPSもいれており、そのため電池の消耗が激しいらしい
- 実測値(10年前)
    - 実測でいくと10m
    - 鉄筋のカベだと遮蔽される
- 省エネルギーの[Bluetooth Low Energy](https://ja.wikipedia.org/wiki/Bluetooth_Low_Energy) の方かも?
- Bluetooth の規格のバージョンで異なる。最新のものだとゲーミング機器だと遅延10msecなどに規格がある。
- 楽器演奏だとタイミングをあわせるのは厳しいので、有線でおこなったりする。
- 音毎にミキシングするなら[DA変換](https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB-%E3%82%A2%E3%83%8A%E3%83%AD%E3%82%B0%E5%A4%89%E6%8F%9B%E5%9B%9E%E8%B7%AF)するから遅延が発生するのできびしい。
- 電子レンジの周波数とかぶるのはなんともならないのか。
    - Bluetooth は 2.4GHz帯で、[Wifi](https://www.wi-fi.org/ja)に 5GHz帯に現在は6GHz帯が追加された。
    - Bluetooth は下位互換性があるので変らないだろう。
    - Wifiの方が500mいける。(ただし低速度になる)
        - IoT向けなんでしょうね。
    - 32～128kbps ... AirH" ? 年齢バレちゃう

### Laravel10出ましたね（かねだ）

* [Laravel](https://laravel.com/) ９系のマイナーバージョンアップだって人がいるみたいですが、
* インストールしてみたら、さまざまな変更があって苦労した
    * `.env`のエントリーが変更になってるのはびっくり（MAIL_DRIVER => MAIL_MAILERとか）
        * 名前としては確かに `MAIL_DRIVER` より `MAIL_MAILER` の方がしっくりくる。名前を派手にかえる系かな。
        * 地雷が多い
    * 言語ファイル置き場(langディレクトリ)の場所の変更が有ったりpublishしないと作成されなかったり
    * Laravel は LTSがない状態でやっていくのか、頻繁にアップデートしていくか
        * ちょっと怖い。リスクがある、人気さがらないか?
        * Laravel は LTS を辞めたらしい。
        * フレームワークは5年くらいサポートしてくれるとうれしい。
* まさに今月からプロジェクトスタートするんで、これ使うらしいです
* [PHP](https://www.php.net/)もLaravelも毎年のバージョンアップで大変
* [LaravelのEoL](https://endoflife.date/laravel)
    * Laravel 8.2.2 にしてくれたらよかった。
        * Ubuntu/Fedoraっぽい, bleeding edge ?
    * [CakePHP](https://cakephp.org/jp)はもう少し安心してつかえる。
        * Debianっぽい
* システムをぽこぽこ変えてくれるお客さんならいいのですが。
* [CentOS](https://www.centos.org/) みたいに10年サポートは浦島太郎になってしまうので 4年ぐらいで変えたい。
    * 今はCentOS Streamは[ローリングリリース](https://ja.wikipedia.org/wiki/%E3%83%AD%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9)なんですけど?
* Laravel はフロントエンドまわりはいい。モダン!
* Laravel を使うなら WAFがほしい。サポートが切れてもWAFで弾くぐらいはしたい。
* 某社は開発するシステムは全部ワンオフ(製品ごとに一からつくる)
    * 一回納品してからはそのままで、あるとき突然改修依頼がくる
    * あたまおかしい(ほめていない)
    * セキュリティ上の懸念がある→開発者が鍛えられるからヨシ!
* Debian 12 はフリーズが開始...
    * Bookwormからnginxのmodsecurityプラグインがaptではいるようになってうれしい
    * 以前はこのプラグインは自前でビルドが必要だった。これで簡易[WAF](https://www.infraexpert.com/study/security17.html)で最低限の防御ができる。
    * [libnginx-mod-http-modsecurity](https://packages.debian.org/search?suite=default&section=all&arch=any&searchon=names&keywords=libnginx-mod-http-modsecurity)
        * 小ネタ: [とほほのModSecurity入門](https://www.tohoho-web.com/ex/modsecurity.html)があった
    * サポート切れてもWAFでカバーできてうれしい。
* WAFでセキュリティが担保できるっていうのはリテラシーが必要。
    * 「WAFは万能ではないのでルールを運用しないといけないよね!大丈夫ですか?」→「運用っているの?」「ソレナニオイシイノ」という人もいる
    * セキュリティソフトもウィルスパターン更新するよね??
    * 正常系がWAFでブロックされたりするでしょ。
        * シグニチャ更新で挙動変わるときもあるのでは？
    * テスト環境からWAFを入れて開発したほうがいいかも

### 遅ればせながら、[WSL](https://github.com/Microsoft/WSL)でsystemd使えるようになってます！（かねだ）

* ストア版のWSL使用で設定は必要
* [「Windows Subsystem for Linux」が「systemd」に対応へ](https://forest.watch.impress.co.jp/docs/news/1441775.html)
* ansibleでDaemon系をインストールしていくときにシステムでインストールできなかった。
    * あとで手作業でやる必要があった。
    * systemdができたので、[ansible](https://www.ansible.com/)でできるようになった。
    * 複数プロセスをすると、複雑になりがち。
    * [Docker compose](https://docs.docker.jp/compose/toc.html)でやろうとすると、DBやメールソフトを動かす必要があって大変、例えば [vagrant](https://www.vagrantup.com/)でやってしまった方が楽。
    * 開発環境でする場合はメールは、メールのテスト用などでシステム化したいですね。
        * https://mailcatcher.me/
        * https://github.com/mailhog/MailHog 
        * https://github.com/axllent/mailpit
        * https://mailtrap.io/ コンテナ外でトラップする
            * 実際にメール送信しない(これらに溜まっていく)
        * [MailCatcherでメール送信をテスト - Qiita](https://qiita.com/pocari/items/de0436c39ffc65647cf0)
            * Ruby 製で環境構築が大変...という課題について↑で Docker 化の話あり
        * https://github.com/redmine-patch-meetup/redmine-dev-mirror/blob/develop/.devcontainer/docker-compose.yml
* WSLでdockerdが動くよね。
    * dockerdの自動起動ができるよね

## 休憩

再開は15:00~です。

### [GraphQL](https://graphql.org/) つかっていますか？ (アカベコ)

- GraphQLはAPIの規格のようなもの。
- 使っているとしたらどのような server/client 構成にしているのか聞きたいです
- うちは Nest/Next でフロントの GraphQL クライアントは [urql](https://formidable.com/open-source/urql/) を採用してます 
- Query/Fragment 設計とかで知見あればうかがいたい
    - 会社では使っていないが個人では試している。
        - 一人でserver/clientを開発でする分には、いらないんじゃないか説
            - ある程度分業化・API抽象化が進んでいるときに変更点をGraphQLで吸収できる
        - 目的としているサーバー意外でもGraphQLで集約できる(単一エンドポイント!)。
            - 間にGraphQLサーバーに集約できると便利なことがある。
            - 知っているサーバーは一つでいい。
    - 型つけするメリットが理解される必要がある。文化圏の問題。
        - 静的型付けはほしい、便利?
        - 画面毎に必要・不要なパラメーターが指定できるのもいいと思う。
    - データサーバーにはやさしい?
        - 人間がかわるところが減る。SQLのがんばるところを減らせる。
    - OpenAPI：https://www.openapis.org/
      - [Swagger UI](https://swagger.io/tools/swagger-ui/)
    - GraphQLはサーバー側が厳しくなることもある。
        - META社のリレーという規格・設計方法があり、これで対応できる
            - https://github.com/facebook/relay
            - NodeとEdgeを指定させることでデータ容量などから負荷のコストを自動計算してくれる。
            - これであまりに深い場所に投げると負荷制限を超えた場合はエラーを返すなども可能。
        - [REST](https://developer.mozilla.org/ja/docs/Glossary/REST)だと、複数のQueryを投げないといけないことがある。
    - GraphQLは大きなバイナリ(Base64でエンコード)を投げてはいけない
        - クエリのパーサーが重くなって死ぬため
- Reactを使う場合[Redux](https://redux.js.org/) とかで便利にできる。
    - 状態管理をGraphQLクライアントに丸投げできるのでhookだけでできる。
    - GraphQLとかはストアしてあるデータが古くなったかどうかを管理するフラグがあるので、必要なデータだけ取りにいくといったことができる。
- デメリット
    - 今あるシステムで互換性のないシステムをリリースしている場合、GraphQLは向かない。
        - GraphQLは基本的に長く運用されるような現場に向いている。
        - 型定義があると便利なんだけどチーム開発ができていないときびしいというのはある。
    - 将来(5年後)にどうなっているかわからない。
        - システムのトレンドがどうなっているのか。5年後にどうなるかわからないものは。厳しい。 
- [TypeScript](https://www.typescriptlang.org/)の型定義をJavaScriptの型アノテーションにしようという提案(TC39)がある。
    - [マイクロソフト、JavaScriptに型宣言を追加しつつトランスパイラ不要の「Types as Comments」をJavaScript仕様策定会議のTC39に提案へ － Publickey](https://www.publickey1.jp/blog/22/javascripttypes_as_commentsjavascripttc39.html)
    - TypeScriptをJavaScriptに変換するときに、そのまま残しておく提案。ブラウザがTypescriptの型宣言として使うかどうかを任せる
- [WASI](https://wasi.dev/)はクロスプラットフォームの標準バイナリ規格になるんじゃないか?
    - [WASM](https://developer.mozilla.org/ja/docs/orphaned/WebAssembly)の中からブラウザのAPIを呼ぶというのはWEBブラウザの制約なんじゃないかな。
    - [WASMにGCをのせよう](https://www.publickey1.jp/blog/23/webassemblychrome_111dartwebassembly.html)という動きがある。
        - [仕様て](https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md)
        - [chrome実装中?](https://chromestatus.com/feature/6062715726462976)
    - メモリアロケーションのときの[マーシャライズ](https://www.itnavi.jp/words/%E3%83%9E%E3%83%BC%E3%82%B7%E3%83%A3%E3%83%AA%E3%83%B3%E3%82%B0/)が必要なので...
- 便利よねで始めるのは怖い
    - 深く理解してから始めるならいいけど。
    - JS界隈は流行りに飛び付く傾向がある。怖い。
    - システムのライフサイクルを考えているのだろうか? 業態とか。
    - だいたいのシステムの寿命は5年いかないからいいんじゃないという意見もある。
    - 個人開発のはいつまでメンテナンスされるかどうかは怖い、避ける
    - 導入時の手間やコストを下げられるのは、導入したいと考えている
        - 例えば GraphQL は導入に一週間以上かかるので許容されない。
        - これが1日作業でメリットがあるなら導入できる
        - ただしそのようなものはでてきていない
    - 年々新しい技術の取り込みには否定的になってきている。年齢?
    - 新しい技術を取り込むのは学習コストがある。
- 両極端な対話ができておもしろかった。
- 新しい技術の評価は重要ですよ。
    - 逆に新しい情報をキャッチしていかないのもリスクにはなるので、把握は必要ですよ。
    - 世界的に技術レベルが世代レベルでおくれてしまう可能性はある。
    - 試しておく、採用しない理由が説明できるというのは重要。
    - リスクの少ないプロジェクトで試すというのはいいと思う。
        - 自社システムで試せばいい
        - 顧客システムで採用を求められたときに対応できる。
    - 男のロマン、ロマン駆動開発。 

### オススメのプログラミング用フォント (アカベコ)

- Ricty Diminished を使っているが開発終了したので代替を検討中
  - [今までありがとう！ 日本人プログラマー向けフォントの先駆者「Ricty」の開発が終了 - やじうまの杜 - 窓の杜](https://forest.watch.impress.co.jp/docs/serial/yajiuma/1478305.html)
  - [RictyフォントとRicty Diminishedフォントが正式にサポート終了となった話 - Qiita](https://qiita.com/sounisi5011/items/62e4da71458ca7ce73c7)
- プログラミング用はiとlなどのフォントが区別しやすいのが嬉しい!
- みなさんの推しフォントがあれば教えてほしいです！
  - 推しではないけど使ってるフォントは[Hack](https://sourcefoundry.org/hack/)です。使ってる理由はKDEのMonospaceデフォルトフォントになってるから(変えるのがめんどくさくなった)
    - その前に使っていたのが[Inconsolata](https://levien.com/type/myfonts/inconsolata.html)
    - [プログラミングフォント 白源](https://github.com/yuru7/HackGen)
    - [UDEV Gothic](https://github.com/yuru7/udev-gothic)
        - Jetbrains monoを合成元に使用している。
- フォント関連ニュース
    - [「Noto」フォントが現存するほぼすべての文字言語に対応](https://forest.watch.impress.co.jp/docs/news/1478991.html)
- JetBrains社のIDEの製品で使用しているフォントがある。
    - [Jetbrains Mono](https://www.jetbrains.com/ja-jp/lp/mono/)
- 合成フォントの問題
    - 合成フォントは、メンテナンスがイマイチ。
    - Rictyはバグがあったが[誰も報告していない](https://dic.pixiv.net/a/%E5%82%8D%E8%A6%B3%E8%80%85%E5%8A%B9%E6%9E%9C)のであった。
- リガチャ
    - リガチャはあまり使わないなぁ。
    - プログラム用のリガチャはちょっと違う。
    - 文字数のカウントが狂うからよくない。

### Youtube用動画β4が出来ました（もりや）
 * 人に見せれるレベルまでとりあえず出来ました[βバージョン4](https://www.youtube.com/watch?v=sqGkoSKfHUs)
 * 内容へのツッコミを聞くべきか、制作の面倒話をするべきか
     * まじめに動画を作ると間違いなく時間とコストが合わない
     * タイムライン編集は無償版で十分
     * 文字テロップや映像エフェクトよりも内容に凝るべき
     * 初期コストは、マイクに一番投資すべきかも？
     * 視聴環境による差が大きいですが、PC視聴の場合顕著に違いが
* 経緯(エンダー伝説)
    * 上の動画を見てください
* 台本を作成してはなしている。 
    * キーワードを押さえて流れて話しては？
        * キューシートを作成してもいいけど、それを見ながら読むのはやめよう。
    * 文字起こしは[Whisper](https://openai.com/blog/whisper/)を使っているのでほぼ完ぺき
    * 安定してしゃべるのもつらい（日をまたいで収録するとピッチなどが変わる）
    * マイクはサウンドハウスで買おう
        * [Shure SM58](https://www.shure.com/ja-JP/products/microphones/sm58)
        * [マイク変える前です](https://studio.youtube.com/video/dQHXSgCAzwg/edit)
* つくりこみすぎでは?
    * ライブ感・アドリブ感をだしたらいいんじゃない。
        * 演出でがんばったら?
    * 今回で確定させて...というのは
    * ツールがあるといろいろ使ってしまう。
    * 収益考えるなら、長いのをとってから短いのをつくる。
        * ショートから長い本編にひっぱってくるのがトレンド。
        * 切り抜きのほうが受けがいい
    * 技術系の解説動画はダルくない? きびしい。
    * マジメな技術解説をする自分を関西人がそんなの己でいいのか?と一人の中での戦い。
* Done is better than perfectというから出してみたら?
* 普段どおりやってキャラクターを殺さないようにしたい
* 基本的につっこみを受けるコンテンツなのでそこを忘れない
    * 視聴者がつっこみをするタイミングを用意する
    * 視聴者がつっこみを表示させることはできないのか
    * キューシートにつっこみ役をいれて、音声読み上げでいいんじゃないの?
    * SEでツッコミを入れるのはどう?
    * 数パターンのツッコミ録音をつかいまわすとかもあり
    * [ラバーダックデバッグ](https://ja.wikipedia.org/wiki/%E3%83%A9%E3%83%90%E3%83%BC%E3%83%80%E3%83%83%E3%82%AF%E3%83%BB%E3%83%87%E3%83%90%E3%83%83%E3%82%B0)的なオーディエンスをおいておけば？

### [フロントエンド開発のためのセキュリティ入門](https://speakerdeck.com/masashi/frontend-security) (ワテ)

元PHPerだったせいか、またここらへんの問題に戻ってくるの？的なデジャブ(既視感)を感じる
※単に僕が年をとっただけ？

* [フロントエンド開発のためのセキュリティ入門知らなかったでは済まされない脆弱性対策の必須知識](https://www.shoeisha.co.jp/book/detail/9784798169477)
* ソースネクストの事件
    * [ソースネクストで11万人分のカード情報が漏洩の可能性「セキュリティコードも含めて漏洩」「決済システムごと改ざん」](https://togetter.com/li/2078461)
    * フォーム改竄されたので、[CVV](https://pay.line.me/portal/jp/about/credit-card/media/article/348)を奪う攻撃をうけた。
    * 本来はCVVをサーバーにもっていたわけではない。 
        * [フォーム改ざんによりクレジットカード情報を盗むデモンストレーション(Type4)](https://www.youtube.com/watch?v=XNgVeH12dEE&t=5s)
    * [経済産業省、全ECサイトが義務化対象 セキュリティー対策で脆弱性対策と本人認証導入を義務化](https://netkeizai.com/articles/detail/7922)
* 今さら感がある
    * 今の若い人は知らないからじゃないの?
        * 今の人は知らないといけないことが多すぎる
        * 昔は両方をやっていたが、今は分業ができている。
        * インフラまで含めるときびしい。
        * 開発環境の構築だけでも、dockerで構築するので説明がむずかしい。
        * 補足情報が多くなりすぎている。
        * 今の人は、インプットとアウトプットではヒットしない。ブラウザに絵を出さないとだめ。
            * 黒い画面は拒否されてしまう。 
    * フロントから言わせてもらうと、フロントとサーバーがまざってきてる
        * 昔バックエンドで対応していたことをフロントでもやる必要がでてきた
        * [AJAX](https://ja.wikipedia.org/wiki/Ajax)などの時代でAsyncみたいなことをやるようになって、セキュリティをやらないといけなくなったのがある。
    * これまではセキュリティをやらなくてもすんでいたんだけど今は必要になってきた。
* 某ネットのメールはスパムが多くて本来のメールがスパム扱いされてしまう。
* アドワーズ広告でスパムサイトを上位にだすとか。
* フロントエンド向けもあるけどバックエンド向けにもセキュリティ意識してくださいよね、目線があるのかなと。
    * バックエンドはフロントからおかしなデータがくることはないと想定するのはおかしくない?
    * フロントを信用してはいけない。
        * GraphQLはフロントから送られてきたデータを検証するというのがある。
        * 受領データのサニタイズなども必要ですよね。
* セキュリティ診断やWAFを提供しているところが監修している。
    * 自分達のノウハウを公開してくれている本なので良心的。
    * 徳丸本はいい本だけど、時代を感じる本。内容は普遍的だが[VMWare Player](https://en.wikipedia.org/wiki/VMware_Workstation_Player)でVMを作るなどモダンではない。
* 安全圏でいた人もいる
    * 保護されている安全圏だけでやっていた人もいます。
* リクエスト毎に認証する必要がある?
    * コストとパフォーマンスの問題もある。本人認証とデータ自体を確認するの二種類がある。
    * 文字列に対しておきるインジェクションは本人であっても怪しいデータは検証しないといけない。
    * 認証であってもなりすましなどがあるからデータの検証は必要。
    * オンラインゲームなどは通信を検証している。パフォーマンスは必要。
        * ドラクエ10を造った人がデータ検証のしくみを語っていた。
        * チーターを排除する仕組みがある。
        * FFで望遠でみると戦闘・攻撃の予兆を確認できてしまうという問題・疑惑 
            * [FF14 絶オメガ「世界最速クリアチームの外部ツール利用」が発覚。海外でミーム化される](https://kultur2.blog.fc2.com/blog-entry-5783.html)
        * UEFIに仕込むチート
            * Linuxへのインストールが難しくなるっている
            * BootloaderがロックされるとLinux はインストールできなくなってしまう。
* この本のフロントエンドはブラウザだけではなく、スマフォなどサーバーに接続するものすべてなので範囲が広い。

### テストラスト開発ってどう思う？ (ワテ)

* 以下の記事を読んで、ものすごく同意できる内容だったので、
* 他の人の意見も聞いてみたい。
* [雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発](https://blog.jnito.com/entry/2023/02/16/171810)
* テストファーストの話はよくあるが、この話は新しいなぁと。
* [t-wada](https://github.com/twada)さんも要件がしっかりしていないときは、テストもしっかりつくりこまないでよいといっている。
* テスト駆動開発も一人歩きしているような気がします。
* 納期もコストもギリギリな環境ではこういうのも現実的なのではないか。
* 要件満しているかわからないような状況もあるがチケットがあいまいな状況はある。
* 要件がフィックスしていないからテストができないのでは。
    * 要件がきまっていないときはテストも実装もできないのが正しい。
    * テストに対するいやな感情や経験がたまりがち
    * 仕様がただしいのかがわからない、要件が定義できていないんじゃない。
* プログラム暦が長いと要件が想像できてしまい、補完できてしまう。そうではない人は要件をきめて書く。
* 入札条件と要求に矛盾した自治体向けシステムは例外がありえる
    * なにかあったときに文句がでる。
    * 入札条件と自治体の条例が矛盾しているので、作成時は入札条件をまもっている必要があるけれど、納品後の監査ではねられる。
* テストの工数が含まれていますか?
    * 品質を求めるならテストの工数が必要
    * チケットの工数は要件定義の工数
* 手動テストと自動テストのコスト
    * 人件費....かなり上の人が手動テストをすること。
    * デグレはあたりまえなのに、理解されていない。

### lighttpdのdockerコンテナを作るのが大変だった(のがた)

* [bludit](https://www.bludit.com/)というCMSのコンテナを作りました
    * https://github.com/nogajun/bludit-docker
    * 公式がCentOSベースとnginxで割と重めでデカめ。そして更新してくれない
* で、Debianベースで[lighttpd](https://www.lighttpd.net/)で作ったけど、ログを出そうとしたら大変でした
    * dockerでログを出そうと思ったら出力先を標準出力にしてあげれば大丈夫
        * と思っていた人生でした
        * たとえば[nginx](https://nginx.org/en/)のdockerfileではこうなってます
            * `ln -sf /dev/stdout /var/log/nginx/access.log`
            * https://github.com/nginxinc/docker-nginx/blob/master/stable/debian/Dockerfile
        * これをやってもなぜか出ない
          * ていうか`/dev/stdout`は`/proc/self/fd/1`のシンボリックリンクで面倒なことがあるので詳しくは[ググってください](https://www.google.com/search?q=/proc/self/fd/1+docker)ということで…
    * 調べた結果、[名前付きパイプを作ってログを流す](https://redmine.lighttpd.net/issues/2731#note-15)というのが正解だったぽい
    * [名前つきパイプ](https://ja.wikipedia.org/wiki/%E5%90%8D%E5%89%8D%E4%BB%98%E3%81%8D%E3%83%91%E3%82%A4%E3%83%97)なら所有権もパーミッションも変えられる
        * やっぱりこういうのいる!と実感した。
        * 基本は必要。たびたび思い返さないといけない。

### 雑談ネタ：人柱になろうと思うのはどんなとき?(fu7mu4)

* オープンソースは、新しいものにとびつく人がいないと発展しない、という前提があります。最近でいえば、[Homebrew 4.0.0](https://brew.sh/2023/02/16/homebrew-4.0.0/)がリリースされたり、[OCaml 5.0.0](https://ocaml.org/news/ocaml-5.0)がリリースされたり、[Laravel 10](https://laravel-news.com/laravel-10)がリリースされたりしています。
* あなたはどんなときに新しいバージョンにアップグレードしますか? それとも極力しないですか?
    * 作っている人は[ドッグフーディング](https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%83%E3%82%B0%E3%83%95%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0)しないとダメかなという気持ち（の）
    * 痛いめを見ても公表しないことが多い。
    * 昔は blogなどで発表する人が多かった。
    * 失敗談を書いてくれる人のおかげで成長できた経験がある。
    * 成功談があってもうまくいくとは限らない。
    * 見合わないということがわかるというのは大事。
    * 人柱は貴重な人材!
    * オープンソースの開発でベータ版がでたときにテストしないのにリリースされたときに不具合報告するのはどうなの?
        * ベータから全部リリースして、全ユーザーをベータテスターにする方法
* 使ってもらわないとバグがでないが出さないとテストされない
* バージョニングってどうなってる?
    * Reactがv0...できていて、あるとき突然v15でリリースされた。
    * [clamav](https://www.clamav.net/) は v0.0 ... v0.100ぐらいになってから [v1.0系がリリース](https://blog.clamav.net/2022/11/clamav-100-lts-released.html)された。
    * [セマンティック バージョニング 2.0.0 | Semantic Versioning](https://semver.org/lang/ja/)
    * Linux Kernel は 2.6系からバージョンに意味がなくなって一気にあげた
        * [Linux Kernel Version History](https://en.wikipedia.org/wiki/Linux_kernel_version_history)
    * 最近はWEBでダウンロードするようになっているからあまり意識されていない。
        * 例えばいつに出すっていうのが決っていたら意味があるのかも?
    * ユーザーはバージョン番号をなんともおもってない?
    * バージョン番号はマーケティング用なんじゃないとか。
        * 実際の開発状況とは異なっている
        * 商品名なんじゃないか
- [renovatebot/renovate: Universal dependency update tool that fits into your workflows.](https://github.com/renovatebot/renovate)
    * 自身の GitHub に関連付けるとパッケージ更新を検知して通知 PR を生成してくれるツール
    * セマンティックバージョンに基づいて 変更が少なければ プルリクエストをmergeする。変更が大きければ、ブランチを取得して動作検証してから merge
        * 自動生成された、リリースノートなどで。


### 雑談ネタ：sedの呪文とか (fu7mu4)

* [sed](https://linuxjm.osdn.jp/html/GNU_sed/man1/sed.1.html) や [awk](https://www.tohoho-web.com/ex/awk.html) や [bash](https://www.gnu.org/software/bash/) などは短く書いてきちんと仕事できていいのですが、いつの間にか人に読まれなくなる、敬遠される、みたいな風潮があります(泣)
* bash くらいはいいのではないかと思いますが、このようなことは他言語でもあるのでしょうか?
    * 他の言語でもある。
* 老害のなげきなんじゃないか?
* シェルスクリップトは読んでもらえない。
* 開発の主となる言語で書かないといけないのかなと思う。
* 他の人もメンテナンスできないといけない。
* ansibleでも同じですが、ansibleだと他の人にも読み書きできる。
    * 処理を書かないというのが重要なのもかも、宣言的であればいいのかな。
    * 自分だけにかえってこないようにしたい。


告知
---------------

###  来月の 姫路IT系勉強会はオフライン開催です

