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

* 開催日: 2022/12/17 13:15
* 司会: wateさん
* 参加人数: 参加者: ???名 (うち学生 0名)
* HackMD: <https://hackmd.io/abcdefghijklmn>
* connpass: <https://histudy.connpass.com/event/268681/>
* ハッシュタグ：[#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/)
* Advent Calendar始まる
* [adventar.org](https://adventar.org/)
* [Qiita Advent Calendar](https://qiita.com/advent-calendar/2022)
* [ChatGPT](https://chat.openai.com/auth/login)
* [AWS re:Invent 11/28-12/2](https://reinvent.awsevents.com/)
* [WebAssemblyランタイム「Wasmer 3.0」が公開、WebAssemblyから実行ファイルを生成可能に](https://codezine.jp/article/detail/16928)ってどんなメリットがあるの?
* [Debian 11.6](https://lists.debian.org/debian-release/2022/11/msg00251.html)がリリースされます
* OCaml 5.0 がリリースされました
* [AWSがLinux関連OSSを特許リスクから守る「Open Invention Network」に加盟を発表](https://www.publickey1.jp/blog/22/awslinuxossopen_invention_network.html)
* もともとGogsフォークだった[Gitea](https://gitea.io/ja-jp/)がもめごと起こして、[Codeberg](https://codeberg.org/)がForgejoとしてフォークしてる
* redditの/r/selfhostedの投稿「[Codeberg forks Gitea with Forgejo](https://www.reddit.com/r/selfhosted/comments/zndd0n/codeberg_forks_gitea_with_forgejo/)」
* Codeberg launches Forgejo — Codeberg News: <https://blog.codeberg.org/codeberg-launches-forgejo.html>

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

* 変ジニアの集まりです！(キモい)
* 変人じゃなくて常識人になろう。Lispの標準といえば Common LispやR6RSですよ!

* Youtube動画作成の簡単なサンプルを一応公開できる状態に出来ました
* エフェクト系を一切入れていないので、音声と背景が流れる程度です．．．
* [シーズン１サンプル](https://youtu.be/Vu5W7jrY7is)

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

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

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

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

### ウルトラワイド曲面モニタを入手しました (かねだ)

* 以前から欲しかったんだけど、さすがにモニタに13万出す気になれなかったんで躊躇してたのが、久しぶりに検索してみると5～6万だったので思い切って購入
* https://www.amazon.co.jp/gp/product/B097275MTF/?th=1 これ
* デュアルモニタだと、どうしても高さや角度が奇麗に揃わず視線を動かした時に違和感があったり、モニタの枠が気になったりしてたのが無くなった
* 半面、ウィンドウ最大化すると一気に視界いっぱいに広がるのは良かったり悪かったり(この辺は『慣れ』の問題)
* 他人が書いたコードは長すぎて折れるのがいやだった。
* linter かコーディングルールで縛ったほうがいい。
* PHPなら通常80文字、最大でも120文字くらい?
* 2kモニター二枚(Full HD)よりちょっとせまい
* HAWEI
* 34インチ
* 9.5kg
* 最近は重くなる傾向
* [43型](https://www.amazon.co.jp/gp/product/B085Y5BB1L)使ってる
* 2枚並べるとディスプレイの間が気になる。
* 最大6枚まで可能!
* 最近の自作パーツは光る!!
* 4枚くらいほしいときがある。
* あまり枚数が多い環境になれると、mac bookを持ち出したとこにつらくなるから...
* モニターx1 + ノートPC をマウスを共有する
* [Barrier](https://github.com/debauchee/barrier)を使ってデスクトップとノートでマウスキーボードを共有してます
* 老眼...
* Webアクセシビリティって大事と実感する
* ブラウザ開いたら `Ctrl +`
* 授業で学生が作成した字が読めない...
* redmineで字が読めないとかある
* 昔のMTGで「いつかは自分もなるから」って
* フォントのサイズを変えたい!
* 昔は解像度が低くかったから...DPIを上げる方向

### 今年のAdvent Calendarについて語ろう (fu7mu4)

今年のAdvent Calendarに参加したかどうか、よかったものはあるか、何ソレおいしいの? などを全員から聞きたい。

* Advent Calendar
* [adventar.org](https://adventar.org/)
* [Qiita Advent Calendar](https://qiita.com/advent-calendar/2022)
* Advent Calendarの質の悪化
* 続かずに一日二日で終わる
* 記事を書く人がいなくて強要するようになるとダメだと思う
* 書きたい人が書くっていうのが大事!
* organizationでネタが散っている。
* それなら複数のAdvent Calendarをつくった方がよくない?
* organizationでAnsibleのことを書くならAnsibleに書くとか。
* 終った感がするアドカレは哀しい感じがする。
* [Ansible lint Advent Calendar 2022](https://qiita.com/advent-calendar/2022/ansible-lint)
* `リントとは`から書いている。
* [Elixir言語](https://qiita.com/advent-calendar/2022/elixir) 15もカレンダーがある件。
* go言語は3つしかない!
* Lispもがんばるべき?
* [adventar.org](https://adventar.org/) は スパムが多い印象残念。
* [やらかしちゃった人Advent Calendar](https://qiita.com/advent-calendar/2022/yarakashi-production) が寂しい。参加人数が少なく勢いが...
* 会社的に出せないかなどの絡みがあって。
* インシデント・事故になってしまうから。
* フリーランスでそれはできない
* やらかしちゃった人Advent Calendar にこっそり書いちゃったのがやらかし
* ゆるされるのは新人の特権(2回目はないよ)
* 新人が失敗して組織として改善されるのはありなんじゃないかな。
* ドキュメントがない、チェック体制を改善、自動化しよう
* ふりかえりがなかったら本当に意味ないから
* GitLabさん、どうした?
* 鼻歌を歌いながら復旧を中継

### [pre-commit][]使ってめんどくさいチェック処理を自動化した(ワテ)

* シンタックスチェックとかコーディング規約のチェックとかを[pre-commit][]で自動化した
* [pre-commit][]ならコミット時にチェックできるので予想以上に便利だった
* 終わったつもりでpushしたら後からCIに怒られて萎えるということが減る
* さすがにテスト部分はCIでやらないと[pre-commit][]でやると辛そう・・
* 【Git】コミット直前に自動でファイルを整形する「pre-commit」が便利すぎたので紹介したい | DevelopersIO: <https://dev.classmethod.jp/articles/introduce-pre-commit/>
* 勉強会のサイトにも組み込んでみました
* https://github.com/histudy/site/blob/master/.pre-commit-config.yaml
* [textlint][] + [textlint-rule-prh][]で表記ゆれの統一も！
* https://github.com/histudy/site/blob/master/prh.yml
* ルールを自分用に書き直せば以下の記事のようなこともできるようになる(はず)
* [記事を書くときの自分ルール](https://zenn.dev/suzuki_hoge/articles/2022-12-output-my-rule-37db5df201ba16)
* コーディング規約を全部確認して、デフォルト値を設定しなおした
* [用語集的なもの(表記ゆれ対策)](https://github.com/histudy/site/blob/master/prh.yml)
* 開く漢字などもprhで指定できる。正規表現で設定できるのがいい。
* [共同通信社の記者ハンドブック](https://www.kyodo.co.jp/books/isbn/978-4-7641-0733-5/)でOSSドキュメントの表記を合せようとしていた。漢字を開く、単位の付け方などを参考にしていた
* 1900円
* 電子版はない
* マスコード?
* textlintは自動で修正できる。
* markdown lint も
* markdown flavor(markdown方言)によってはリストが正しく表示されないことがある。
* 2文字スペース vs 4文字スペースはエディタの設定が影響することがある。
* 半角と全角の間をあけない
* [lintの設定](https://github.com/histudy/site/blob/master/prh.yml)でルール決めておいてやれば楽：暗黙の了解を減らすといい
* `--fix` で自動修正はいい。古参の開発者がルールを守らないことがある
* lint指摘 → 確認 → `git add`/`git commit`

[pre-commit]: https://pre-commit.com/
[textlint]: https://textlint.github.io/
[textlint-rule-prh]: https://github.com/textlint-rule/textlint-rule-prh

## 休憩 15:00-15:10

* bootstrap 4が2023年1月1日でサポート終了の話とか
* VSCodeの[HTML CSS Support](https://marketplace.visualstudio.com/items?itemName=ecmel.vscode-html-css)では、CSSのクラスも見てくれるのでbootstrapのclassも補完してくれます

### フリーランスのスキルセット(funatsu)

* どんな案件やってるんだろ？という疑問
* 自由を求めるフリーランスと学生からのフリーランスがある
* 会社のつらみからフリーランスになることはあるが、いきなりフリーランスはリスク
* ビジネス上のマナー、暗黙知、商習慣を学んだ方がいい。こういうのは会社で学ぶことができる
* お客さんにいってはダメとかとか
* 安い案件ばかり受けることになりがち
* バックに会社のあるフリーランスもある
* 派遣でそういった人が来ると困る
* コードだけ書けても意味はない。コーディング規約などのルールなどがある。(お客さんの要望・要件)
* 自分の好みでコード書いちゃだめ
* 要件が決まっていなかったら自分でディレクションする必要がある。
* 業務知識もいる、特殊な場合は除く
* 自分で調べて、わからないこともやる。
* 下請け法なども知って自分の身を自分で守る。
* 弁護士
* 会社が守ってくれていることを自分でやらないといけない。
* **わからない** のは自分で調べるという能力・気概は必要
* 案件サイズ
* 大きい案件は仕事をふる相手が...
* 自分の裁量があるかないか、他の人とするとか
* チームメンバーとしてはいるなら、前職のときのコネが必要だったりする。
* つながりのある会社から..など
* 発注する側も不安なので、安心させる必要がある。
* 小さい案件をまわしあって信頼するメンバーを探す
* デザイナーやフロントエンドも必要になることがある。
* 小さい案件をビジネスでやってみるとか。プロジェクト管理ツール([Redmine](https://redmine.jp/), [backlog](https://backlog.com/ja/lp/standard/), [jira](https://www.atlassian.com/ja/software/jira), [notion](https://www.notion.so/ja-jp)など)がつかえるかどうかなど
* WEB制作だと要件が[Evernote](https://evernote.com/intl/jp)にしかないというようなプロジェクトもあることはある。
* 変更の意図が読めないのはダメ。不毛な修正を繰り返す破目になる
* notionはDB機能が強力、table viewなどがあって便利
* DBの正規化などの知識が必要では?
* JSON文字列いれないでみたいな?
* RedmineとJiraは PROJECTのワークフローを制限できる。
* どの状態からどの状態に遷移できるかを制限できる機能
* 顧客がいる場合やPMの承認がいるようなビジネス的なこと。
* バグが勝手にクローズされると困る。
* Redmine は破棄された理由を強制できる
* 需要どこにあるんだろ
* スキルセット晒してみるとか？
* フリーランスは安定性がない。案件はパートナーの数。仲間で案件をシェアする。そうでないと、営業も自分ですることになる。
* Redmineのたてかた
* 自社案件ならインスタンスひとつで複数のプロジェクト
* 顧客毎にインスタンスをたてる
* 総務系のものも管理できる
* ドキュメント管理に notionを使うのはいいかもしれない
* 要件はnotion あど自由な組み合せがありえる
* Redmine の使い勝手がよくないのが悪い
* 古いOSSのため、作りが古くさくなっている。
* 画面が古いだけではないと思う。
* モジュール構成にして、gitなどを外部にしたい
* グループをネストしたいなど要望多数
* 全部Self hostできるようにする、男のロマンプロジェクト: [mattermost(go)](https://mattermost.com/), [gitea(go)](https://gitea.io/ja-jp/), [HedgeDog(node)](https://hedgedoc.org/) ...などもDBのテーブルを参照している
* [mattermostのロール](https://github.com/wate/ansible-role-mattermost)
* [Nextcloud](https://nextcloud.com/), [MinIO](https://min.io/)
* シングルサインオンの [Keycloak](https://www.keycloak.org/)
* レンタルサーバーなどで稼動するようにしたい
* あまりプロジェクト管理ができていない人がすぐにはじめられるような
* ガントチャート機能欲しい
* Redmineの機能を切り出していきたい
* [Redmine Database Schema](https://github.com/wate/redmine_db_schema/)

### 休憩 16:00-16:05

### JBBFのポーズを判定してみました（もりや）

* MediaPipeの[Pose-Detection](https://github.com/tensorflow/tfjs-models/tree/master/pose-detection)を使って[JBBF](https://www.jbbf.jp/)の規定ポーズを判別できるか
* JBBF（日本ボディビル・フィットネス連盟）[規定のポーズ](https://www.jbbf.jp/download/Committee/2022%94N%93x%94%C5_JBBF%8B%A3%8BZ%83%8B%81%5B%83%8B%83%7D%83j%83%85%83A%83%8B_20220624%8D%C5%90V%94%C5.pdf)
* 全12種類あり、大会では定められたポーズを順番にキメて行く
* モストマスキュラー！と会社で言ったら、は？と言われたので判別できる物があればいいと気付く
* [K-Mean](https://ja.wikipedia.org/wiki/K%E5%B9%B3%E5%9D%87%E6%B3%95)解析で始め出来るか試したが上手くいかない
* Pose-Detectionで座標を取得し、各部位の角度情報を正規化して判別を行うと上手く
* 腕の長さなどで判別する場合、厚着で体の大きさが変わる、体の角度、背景との同化、などが原因で一定の値を求めることが出来ない
* 肘、手首、肩、などの部位ごとの角度を正規化することで、ある程度の精度を出せる
* 会社で披露した所、は？で終わったので、新しいマッスルの可能性を模索
* ポージングの判定が夏と冬で体の座標検知が大幅る変わる問題
* カメラの性能で判定が大幅に変わる問題
* 厚着、背景と同化している、ほぼ座標が取れない
* カメラの性能で判定結果が著しく変わる
* 高解像度なカメラほど、判定の正確性が下がる
* アニメーション処理を[WebGL](https://developer.mozilla.org/ja/docs/Web/API/WebGL_API/Tutorial/Getting_started_with_WebGL)、CSSアニメーションで分けると、使い所が分かれて良い
* [WebGL](https://developer.mozilla.org/ja/docs/Web/API/WebGL_API/Tutorial/Getting_started_with_WebGL)のエフェクトを[Adobe AfterEffects](https://www.adobe.com/jp/products/aftereffects.html)で透過動画を作るといい感じにはなる
* [WebGL](https://developer.mozilla.org/ja/docs/Web/API/WebGL_API/Tutorial/Getting_started_with_WebGL)側のオブジェクトの重なりを計算してくれない
* ボディビルの掛け声をかけられるようにする
* 私は[この掛け声](https://ogura-moai.hatenablog.com/entry/2020/01/17/200730)しか知りません（の）
* [なかやまきんに君、あの名画の世界に登場し魂の「ヤーーーー！！」　ecforce新CM「牛乳を注ぐ男」篇](https://www.youtube.com/watch?v=nYZKqouHxAk)
* これを思い出したｗ
* 人体切り抜きも出来ますんで、似た感じで実現可能です。
* フィットネス系なら使えるのでは?
* フィットネスのポージングを判定する[モデル](https://google.github.io/mediapipe/solutions/pose)があるので、何かできそう
* 筋肉はすべてを解決するから問題ない
* [停電が発生して玄関ゲートが開かなくなっても](https://karapaia.com/archives/52294845.html)、筋肉なら解決できる
* 3次元的に位置を取得する方が正確性が高いように感じるが2次元の画像学習を使って進めていくのはなぜ？
* 3次元的な位置取得は現状速度が遅く2～15FPS程度しか速度が出ない
* 装置の値段も非常に高く、データも大量に発生する為、業務用と以外では実用性がまだ低い
* 2次元情報からAIを使うと、精度は下がりますが100fpsを超えることも可能なので、厳密に計測する必要がないなら、こちらのほうが有効に使える
* iPhone12 Pro 以降には[LiDAR](https://ja.wikipedia.org/wiki/LIDAR)がある
* 室内の計測、メートル級のオブジェクト建築物の計測では威力を発揮
* 目のくぼみ、鼻の形状など細かい形状は取りにくい
* 顔の凹凸等細かい形状を取るには画像をくるっと回って取るようなのが今のところ良い
* 開発で使える深度センサーが色々出てきているので、業務展開するならこういったデバイスを使うのもあり
* [Intel RealSense](https://www.intel.co.jp/content/www/jp/ja/architecture-and-technology/realsense-overview.html)
* [Azure Kinect DK](https://azure.microsoft.com/ja-jp/products/kinect-dk/)　旧XBOXのKinectセンサーです
* [Omron LiDARセンサー](https://www.omron.com/jp/ja/news/2018/09/c0913.html)
---

* URLのコピペがめんどくさそうだったので気になった
* [TabCopy(Chrome)](
https://chrome.google.com/webstore/detail/tabcopy/micdllihgoppmejpecmkilggmaagfdmb?hl=ja)

### 文系学生にWebアプリを書かせる授業が一段落しました(のがた)

* [姫路独協大学のシラバス](https://www.himeji-du.ac.jp/univ/syllabus/refer/10/3/2022_10_111645.html)
* [Flask](https://flask.palletsprojects.com/en/2.2.x/)を使って文系学生にWebアプリっぽい物を書かせる授業、一段落しました
* 物は、ログインして書き込みと画像が貼れる掲示板ぽいヤツ
* 授業は「プログラミング」(Python)の授業を取った人としていたけれど、取ってない人もいて、ちょっと大変でした
* 授業をやって思ったこと
* みんな、真面目に出席して偉い！
* Flask/Jinja2+bootstrap+[TinyDB](https://tinydb.readthedocs.io/en/latest/)は、とりあえず成功
* テンプレートエンジン
* Python：[Jinja](https://jinja.palletsprojects.com/en/3.1.x/)
* PHP：[Twig](https://twig.symfony.com/)
* JavaScript：[Nunjucks](https://mozilla.github.io/nunjucks/)
* 授業環境としてVS CodeとDev containerを使うのも成功
* Webアプリは知識が多岐にわたるから深くやることが難しい
* HTML, CSS, JavaScript, Database ...
* エディタの補完機能を無視して、頑張って全部入力しちゃう学生がいる
* Flask はよかった。
* HTMLを編集させて、テンプレートにする流れはうまくいけた
* ビジュアルからはいったらすんなりいけた
* VSCodeのdev containerは環境が統一できてすっごく楽
* https://github.com/nogajun/hdu-devcontainer
* 知識は定着しているかというと....
* https://github.com/devcontainers/templates/tree/main/src/python

### Bootstrap4が1/1でサポート終了(かねだ)

* 昨日（12/16）知ってPM大慌て
* https://endoflife.date/bootstrap
* 一か月くらいCDN生きてるよね？
* 古い記述`<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.5.2/css/bootstrap.min.css" ` は書き換えないとね

### PHPのフレームワーク選び(ワテ)

※ネタがなかったとき用なので時間が足りない場合はスキップしてください。

* [それぞれの特徴から考えるフレームワーク選び](https://speakerdeck.com/ippey/soresorenote-zheng-karakao-eruhuremuwakuxuan-hi)

「[PHPerのための「PHPフレームワーク」を語り合うPHP TechCafe](https://rakus.connpass.com/event/264108/)」で
発表されてた資料ですが、なかなかに出来が良かったので、
これを見てどう思うかを話し合ってみたくなった

* PHPのマイクロフレームワーク[Slim](https://www.slimframework.com/)
* シンプルでほとんどないPHPフレームワーク
* CakePHPは逆にいろいろ付いているし、ドキュメントも充実している
* CakePHPの日本語ドキュメント: <https://book.cakephp.org/4/ja/index.html>
* ライフサイクルのまとめサイト: <https://endoflife.date/>

### Android のライセンス表示のしくみがつらい(fu7mu4)

* AOSP(Android Open Source Project) アプリじゃない方の標準的なライセンスファイルを収集する仕組みがアレな件
1. AOSPの中では Android.mkファイルやAndroid.bpなどのmake ファイルで、ライセンスが書かれているファイルを指定する
2. `make`で全体をビルドする再に指定されたOSSのライセンスファイルを NOTICE*.xml.gz に格納
3. 初回起動時に、NOTICE.xml.gzから HTMLを生成する
4. ユーザーが表示する
* LICENSEの著者名に今どき文字化けが発生した...マジかよ。
* LICENCEファイルはUTF-8
* XMLファイルはUTF-8
* HTMLが 未指定???→ ISO-8859-1
* SMALL LETTER A WITH A CUTE(UTF-8) : 'c3a1'
* LETTER A WITH CUTE(ISO-8859-1) : 'c3'
* REVERSE EXPLAMATION(ISO-8859-1) : 'a1'

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

### イベント名(開催日時)

(イベントの概要をここに書く)