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

* 開催日: 2022/06/18 13:15 - 18:38
* 司会: wateさん
* 参加人数: 参加者: 9名 (うち学生 0名)
* HackMD: https://hackmd.io/QPKkt7bHT7Sd3ly-j6Kyug
* connpass: https://histudy.connpass.com/event/250348/
* ハッシュタグ：[#histudy](https://twitter.com/search?q=%23histudy&src=typd)
* Discord(オンラインミーティング専用)姫路IT系勉強会招待コード: https://discord.gg/rZCeScB
* Discordは無料プランに乗れる人数(10人以内)なので使っています。
* 有料版でも$15/月程度なら払えなくもないですね。
* Discord以外にも色々ありますので、人数が増えたら検討しましょう。
* 前回からのニュース
* [Atlassian Confluenceさん、認証なしでリモートコード実行の脆弱性のゼロデイ](https://www.itmedia.co.jp/news/articles/2206/03/news133.html)
* [中国のGithubといわれる、Giteeが検閲?](https://opensource.srad.jp/story/22/06/01/1642257/)
* [libfuseはsshfs開発終了し後継者を募集](https://github.com/libfuse/sshfs)
* [Atomエディタ開発終了](https://github.blog/2022-06-08-sunsetting-atom/)
* IE さようなら !

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

ここの下にお題(相談したいこと、発表したいこと、Common Lispへの賛辞などなんでも)おかきください。

## ただの出オチ: git for bash 環境でスクリプト選定(fu7mu4)

* [git for windows](https://gitforwindows.org/) がインストールされている環境で、スクリプトを書くお仕事があった
* git for bashなら 選択肢は sed or awk or bash or [perl](https://www.perl.org/)
* **perl大好き!**
* 連想リスト(辞書)がほしかったからだよ
* 正直にいえば、どれ使っても黒魔術といわれるわけですが..
* **perl に文句いわないでほしい**
* 悪いのは git for windows限定の要件だからね。
* python は git for windows に [python](https://www.python.org/) がないから駄目、別途インストールいるからだって
* go はスクリプトじゃないから
* *git bash特別ルール*
* `chmod +x` はしても意味なし
* Windows のファイルシステムは実行権限が管理されていないから
* 代りに `#!/bin/bash` か `#!/usr/bin/perl` を書くと実行権限が与えられるらしい。
* コード行数で成果はかるのやめよう!
* Windows/macOS/Linux で共通した開発するにはどうする?
* [vagrant](https://www.vagrantup.com/)とVirtualBox はちょっとというとき
* 開発者以外に成果を見せたいときとか。
* Docker + VSCode + なにかいい拡張はないか?
* [VSCode × Docker で簡単 devcontainer 環境構築！](https://weseek.co.jp/tech/2331/)
* PHPの開発でDockerを使うと、DBがあるので、Docker-Composeを使うことになる?
* PHP の ビルドブラウザ
* PHP -s で簡易サーバーが起動するんだけど、アクセス制御があってじゃあ、nginx をかまして...となる。
* [node](https://nodejs.org/ja/) なら express のフレームワーク(WEBサーバー機能提供)をかいて、PHPに接続という方法もある。
* rails なら...
* common lisp なら [SWANKサーバによるEmacs SLIMEとdocker-composeとの連携 -- 現代的なCommon Lisp開発](https://blog.3qe.us/entry/2018/06/21/025948)
* Wordpress も [ローカル(local/local by Flywheel)](https://localwp.com/)?
* データの共有をどうするのか?
* devcontainer をしこんで、DB を dump するコマンドをしこむ
* Redmineの開発者は[GitHub - ishikawa999/redmine_development_docker](https://github.com/ishikawa999/redmine_development_docker)としている。
* Dockerfile 書きたくない
* 内部に ansible いれてしまうと楽
* bash で file1 がなかったら、somecode を実行はこうかける? `[ ! -f file1 ] somecode`
* [Dev Container が VSCode から CLI にもやって来た](https://zenn.dev/hankei6km/articles/devcontainers-in-cli-ci)
* npm でコマンドたたいている?

## コンテナ開発のトレンドを教えてほしい（かねだ）

* 先月開発チームの環境づくりのためにdocker-compose.yml書いたんですが、「ローカルとリモート（クラウド）同じ設定ファイルでバンッて出来る方法無い？」と訊かれました
* クラウドはk8s使うのかなと思うんですが、ローカル環境に何使うのが良いんでしょう？
* ローカルk8s
* [k3s(Lightweight Kubernetes)](https://k3s.io/) 軽いらしい
* [minikube](https://minikube.sigs.k8s.io/docs/start/) 最初に出たやつ？
* [microk8s](https://microk8s.io/) Canonical
* いっそDocker-ceのまま
* [docker-ce(debian)](https://docs.docker.jp/engine/installation/linux/docker-ce/debian.html)
* [Containerd](https://containerd.io/)
* 完全一致は無理じゃないの?
* google の話によると、クラウドとローカルに差がある。
* そのまま動かしたときにも差異がある。
* 動けばいいレベルなら可能
* クラウドと同じリソースを用意するのは無理
* docker engine以外をいれかえられるなら問題ない
* k8s はネットワークスイッチあたりを変更しているので完全一致はむりかも
* この相談は開発用途だから完全一致でなくても大丈夫なはず
* compose しているとイメージが肥大化していくおそれ
* [マルチステージビルド](https://docs.docker.jp/develop/develop-images/multistage-build.html)で Dockerのイメージサイズ拡大を抑える
* 黒魔術化して読めなくなる、副作用がある
* **いじるな危険**とするといじる人がでてくる
* いじった人がわるいから放置しかないよ。イメージ消そう
* 最近のイメージは軽量化のため
* Docker Desktop が話題にでない...?
* Docker Desktopが有料化しているから([Docker Desktop無料の猶予期間が今日で終了。250人以上もしくは年間売り上げ1000万ドル（約11億円）以上の組織は有料に](https://www.publickey1.jp/blog/22/docker_desktop250100011_1.html)) かも?
* [Ranchar Desktop](https://rancherdesktop.io/) もあるよ
* K8s あるよ
* VSCode の devcontainer もはいっているよ。
* [まるでDocker Desktop！！Rancher Desktopの登場です - Qiita](https://qiita.com/moritalous/items/14d4099023981dcf4fd2)
* WSL2上のopenSUSE？ [SUSE、Kubernetes管理ツールのRancher Labsを買収へ](https://japan.zdnet.com/article/35156530/)
* [Kompose - Convert your Docker Compose file to Kubernetes or OpenShift](https://kompose.io/)は対応している?
* 開発環境がWindowsなもので
* 開発者全員にWindowsノートPC貸与
* Ubuntu っていうソフトいれると Windowsをきれいきれいにできます。
* debian もいいです。
* debian は [testing](https://wiki.debian.org/DebianTesting) が基本(??)
* Docker compose ? docker-compose ? どっち?
* [Docker Compose V2(Version 2) GA のまとめ](https://qiita.com/zembutsu/items/d82b2ae1a511ebd6a350)
* docker-compose は v1で サポート終了で
* docker compose が v2が docker 本体のプラグインになった

## WSLで開発をするうえでやっておくと良い設定など（yabonary）

* Macでの開発から、WSL2を使って開発するのをメインに切り替えようとしている
* M１チップだと配布されてるDockerコンテナ動かなかったりしてつらいため
* [VSCode](https://code.visualstudio.com/)と[IntelliJ](https://www.jetbrains.com/ja-jp/idea/)を使っている
* VSCodeはプラグインの[Remote-WSL](https://docs.microsoft.com/ja-jp/windows/wsl/tutorials/wsl-vscode)を使って$wslフォルダを開くと簡単
* IntelliJは$wslフォルダを開くとインタプリタ設定してねって言われるので言われた通りやるとあとはよしなにしてくれる
* [IntelliJ IDEA 2022.1 Help/WSL](https://www.jetbrains.com/help/idea/how-to-use-wsl-development-environment-in-product.html)
* Windows はもういいでしょ。
* Linuxで消しま...
* Windows はOFFICE用とかおしごと用
* WSLの制限
* WSL からGPU をさわるとよくないらしい
* WSL からGUI もあまりつかわないので
* メモリの半分か8GBの少ない方がWSLで消費されるので、Windows には 16GB以上いれておくこと
* メモリは16GB 4枚刺し
* メモリの余裕は心の余裕
* メモリサイズは設定ファイル（[%USERPROFILE%\.wslconfig](https://docs.microsoft.com/ja-jp/windows/wsl/wsl-config#configuration-settings-for-wslcon)）で制御できるらしい
* Windows はゲーム機
* ストレージは注意
* WSL2でコンテナっていうのはあまりオススめできない
* VSCode + devcontainerでいいと思う
* [Visual Studio Code Remote Development](https://code.visualstudio.com/docs/remote/remote-overview)
* Intellij もあるようだ
*[JetBrainsのリモート開発(SSHベース)](https://blog.jetbrains.com/ja/blog/2021/11/29/introducing-remote-development-for-jetbrains-ides/)
* 結局サーバー立てたくなるよね... インフラ沼にようこそ
* サーバー構築・運用・保守はいや
* チーム適性があるんじゃない?
* チーム開発だと違う職種やレベルの人がはいってくるので地獄
* バックボーンが違うので専門語にならないようにしないと
* 各人の人間性?
* 発言者だけの話ではなく、聞く側もそのドメインの言葉を理解するように努めたい
* ITパスポートは広く浅くで、会話するにはこの辺の単語はわかるとうれしい
* ITパスポート用語辞典【シラバス5.0】
* [ストラテジ系](https://www.itpassportsiken.com/word/index_st.html)
* [マネジメント系](https://www.itpassportsiken.com/word/index_ma.html)
* [テクノロジ系](https://www.itpassportsiken.com/word/index_te.html)

### 車載開発やる上でやっておいた方がよいことなど（inapyon）

* 弊社内の部署が組織変更で完全に車関係案件の部署に取り込まれてきている
* Androidの業務用端末の案件もいつまであるか怪しいので、車載開発やる上でよく使う技術とかあれば教えてほしいです
* 車載やってる同期に聞いたら、MATLABとか数学の話でてきてビビってます……
必要な人には必要だが、全員に求められるわけではないかな。
* 車載はエンジン系？カーナビなどのそれ以外系？
* エンジン系は人命にかかわるのでとてもしんどい
* [IVI(in-vehicle infotainment)系](https://mobility-transformation.com/magazine/ivi-2/) (アクセサリ)はまだ気楽
* 車載カーナビには主に2系統
* [Android系](https://source.android.com/?hl=ja)(主流)
* Googleの出すセキュリティアップデート対応など多くをGoogle/AOSP の影響を受ける
* [AGL(Automotive Grade Linux)](https://jidounten-lab.com/u_agl-connected-matome)系
* [AGLはLF傘下のプロジェクトです](https://www.automotivelinux.org/)
* トヨタ系がすすめてる
* TOYOTAのTRIADが開発している[Arene](https://forbesjapan.com/articles/detail/45171)という新しいOSあるけど...
* ISO21434
* [「ISO 21434」の衝撃、クルマに迫るサイバー攻撃対策](https://xtech.nikkei.com/atcl/nxt/column/18/00001/04291/)
* [自動車サイバーセキュリティ（CSMS）を理解して対策を！](https://qualitycube.jp/carcybersecurity)
* 自動運転の車は OTA(OverTheAir)、車のセキュリティ、セキュリティのある開発組織が必要になる
* ISO21434認定されていないと製品出荷できない
* 車系の企業は取るか、発注元のグループとして振る舞う必要がある。
* 単一の規格ではなく、他の規格を参照しまくるので覚えようとすると地獄、ISO9001, ISO27000, ...
* 国別の認定があるので1カ国で規格取れたらOK！ではない
* 2022/07くらいから認定がないといけなくなる
* ライセンスコンプライアンス
* AGLでもAndroidでも OSはLinuxがベースになるのでソースコードの開示が発生する
* Linux以外にも、内部的にOSSを利用することになる
* 各ライセンスの内容を理解したり、表記・公開の確認も
* Androidとかは随時更新が入る
* これも月一更新で、公開する内容が変化する。
* Android開発とAOSPの開発の違い
* Androidのアプリ開発は AOSP の内部を変更しないので楽
* Android車載開発は、ドライバ層まで手をいれる必要がある。
* 下周りを変更した場合、Googleが提供するテストをクリアしないといけない
* 月一更新で、自分達の独自開発部分に更新があたっていないといいですね。
* 開発規模
* 車の販売はモデル年、販売先、グレードなどで複数のバージョンを開発する必要がある。
* それぞれの要素で機能などがかわる。→利用するOSSが変る→公開する情報も変る
* それぞれのバージョンで何がはいっているのかを管理しないといけない。
* その他にも法令による開発への影響あるよね
* 個人情報保護法の改正もありましたね。
* 改正したので把握しないといけない
* [【2022年4月施行】個人情報保護法改正とは？改正点を解説！（新旧対照表つき）](https://keiyaku-watch.jp/media/hourei/kojinjyouhouhogohouishohou202101)
* メール
* メールはかかわりたくないでござる、
* RFC違反メールとかいろいろトラブルの元
* mail daemon さんのメールはもう飽きました。
* PPAP
* そもそもメールはオワコン説
* メールで大事な内容を送らない方がいい
* クローズドなチャットツールがベター
* SMS の拡張版
* [リッチコミュニケーションサービス](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%83%E3%83%81%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9)

### 会社の規制で出来なくなった事を乗り越えることが出来ました（もりや）

* 入社してすぐのパソコンにそこまで詳しく無い頃、おそらく皆さんもされたであろう
* 他人のパソコンの起動後のスクリーンショットを撮る
* そのスクリーンショットを壁紙にする
* 並んでいるアイコンをすべて消す
* パソコンが操作できなくなったと慌てる
* ~~「そんなことする奴おらんやろ」~~
* 以前のWindowsではキーに音が設定出来た
* Enterキーにホイットニー・ヒューストンの「[I Will Always Love You](https://www.youtube.com/watch?v=3JWTaaS7LdU)」のサビを割り当てる
* [ｴﾝﾀﾞｰ](https://youtu.be/3JWTaaS7LdU?t=107)
* →他人のパソコンを勝手操作して、設定を変えてはいけないルールができる
* リモートデスクトップを経由して、Enterキーに「[I Will Always Love You](https://www.youtube.com/watch?v=3JWTaaS7LdU)」のサビを割り当てる
* →他人のパソコンを直接、遠隔問わず設定を変えてはいけないルールができる
* ActiveDirectoryを使い、他人が接続したときにEnterキーに「I Will Always Love You」のサビを割り当てる
* 「いや、遠隔で設定変えているやん」「本人がアクセスしているから自分で変えたことになるよっていえます」
* →いかなる手段を用いても、設定を変えてはいけないルールができる
* 「このルールだと、Admin権限に意味なくなるけど??」
* ニューラルネットを使い、タイプ音から入力キーを割り出すキーロガーの報告が出る
* 国内でも実証の[報告](https://shizuoka.repo.nii.ac.jp/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=12312&item_no=1&page_id=13&block_id=21)
* これを応用すると、すべての規制を突破して鳴らせる
1. エンターキーを押下
2. キーボード音取得
3. 音声を解析してエンターキー判定
4. [エンダー](https://youtu.be/3JWTaaS7LdU?t=107)
* [MFCC](https://qiita.com/tmtakashi_dist/items/eecb705ea48260db0b62)を使うと音声波形よりは距離の精度が出る
* Rasberry PIではMFCCに変換するライブラリのインストールで失敗する
* しょうがないので、CNNではなく全結合ネットワークで学習させると非常に精度が悪い
* 将来的には、WEBサーバーで[エンダー](https://youtu.be/3JWTaaS7LdU?t=107)したい
* 技術のm(ry
* 学習・習得し、日の目を見ていない技術、知識も必ず輝く日がやってくる
* どんな壁（規制）も超えられる可能性がある
## CloudFlare Zero TrustでZero Trust始めませんか？
* CDNで有名な[Cloudflare](https://www.cloudflare.com/ja-jp/)が出しているWireguardベースのZero Trust製品
* 昔はCloudflare Teamsという名前で出してた
* 無料版でも50名まで組織に参加可能
* VPNの代わりに繋いだり
* [ngork](https://ngrok.com/)みたいな感じで[FW](https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%82%A2%E3%82%A6%E3%82%A9%E3%83%BC%E3%83%AB)に穴あけせずに一部サービスだけ公開もできます
* [「Cloudflare Zero Trust」 で組織のゼロトラストネットワークを構成する - Zenn](https://zenn.dev/hiroe_orz17/articles/67f63b9c7a9da5)
* 基本的にローカル側はクライアントとして駆動するのでFWの穴あけが不要
* [NW管理者](https://ja.wikipedia.org/wiki/%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E7%AE%A1%E7%90%86%E8%80%85)に相談なく社内NWをつなぐのはやめましょう
* [VPN装置やファイアウォールを無料でクラウド化！　より使いやすく進化した「Cloudflare Zero Trust」【イニシャルB】](https://internet.watch.impress.co.jp/docs/column/shimizu/1410247.html)

### 小ネタ： 皆さんのリモートワーク事情など（inapyon）
* 出社日設定の流れとか来ているんですかね？
* ちょうど、つい先日出社日（SESで出てる人は帰社日）があったが、全員リモートだった
* フリーランスに出社日はない
* 情シスにテレワークは無いです・・・
* PC壊れた！今から交換して！があるので
* 週二日リモートワーク
* 出社する理由がわかるのであればいいが、なんとなくでてほしいというのであれば暴動がおこりそうという話があった
* 新人の場合や教育の場は出社が必要?
* 新人には厳しいかもしれない
* 出社して質問しなければならない状況は避けるべき。普段から文書化しよう。
* マニュアルなどが整備できていないのであれば、整備した方がいい
* リモートワークだと管理できない、評価できないというのはダメじゃないか。
* 通話ツールを使っているのあります?
* gather
* 仮想オフィス
* カンファレンスなどでは利用したことがある。
* メンバーの忙しさがどうにも表示されていない感がある。
* 忙しいかどうかがわかればいいのでは?
* 他人の作業を評価できるかどうかで出社しているかどうかは関係ない
* [ドキュメントに固執せよ](https://gfngfn.github.io/ja/posts/2022-06-18-be-a-documentation-geek/)
* 管理職ならこういった仕組みを構築する、管理する、必要がある。

### Linux系 Vtuber (fu7mu4)
* こんなマニアックな [Vtuber(さくらのクラウド & MIRACLE LINUX8.4でコンテナイメージのSBOMアテステーションをやってみた)](https://qiita.com/lina_kumagaya/items/9edfa84b6f9b2d4f3d5e) がいた
* コンテナイメージのSBOMアステーション?なにそれおいしいの?
* [SBOM](https://www.hitachi-solutions.co.jp/oms/sp/blog/2021120105/):ソフトウェア一覧表(Bill of Materials)はひらたくいうとOSSなどのリストで、名前やバージョンがはいっている
* コンテナイメージからは SBOMが生成できる
* SBOMがあると、脆弱性対応などが効率的にできてうれしい
* でも SBOM を生成したあとにコンテナイメージを変更されてしまったら?と考えると、SBOM のありがたみが薄れるよね。
* じゃあ、SBOMを生成したイメージと SBOM を暗号化技術でひもづけして SBOMを生成したときのイメージからかわっていないことを検証できるようにしよう。(アステーション)
* さくらの中の人?なの
* 知らん