姫路IT系勉強会 2023.02

最近のニュース

自己紹介

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

お題

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

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

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

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

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

Bluetooth LEの飛距離について(妖介)

  • 最近やった案件で幼稚園などの登下校バスの置き去り対策・検出がありました
    • 対策ソリューションが各社からリリースされた。組み込み系が多い
  • Bluetoothビーコンを使ってバス内の親機と接続で検出してるそうです
    • 車庫に入ったときに接続が残っていれば置き去りの可能性あり
  • Androidの公式ドキュメントによれば接続距離10～100mらしいんですが、実際のところどうなのか有識者がいらっしゃったらお伺いしたいです
  • アシックス製品はGPSもいれており、そのため電池の消耗が激しいらしい
  • 実測値(10年前)
    • 実測でいくと10m
    • 鉄筋のカベだと遮蔽される
  • 省エネルギーのBluetooth Low Energy の方かも?
  • Bluetoothの規格のバージョンで異なる。最新のものだとゲーミング機器だと遅延10msecなどに規格がある。
  • 楽器演奏だとタイミングをあわせるのは厳しいので、有線でおこなったりする。
  • 音毎にミキシングするならDA変換するから遅延が発生するのできびしい。
  • 電子レンジの周波数とかぶるのはなんともならないのか。
    • Bluetoothは2.4GHz帯で、Wifiに5GHz帯に現在は6GHz帯が追加された。
    • Bluetoothは下位互換性があるので変らないだろう。
    • Wifiの方が500mいける。(ただし低速度になる)
      • IoT向けなんでしょうね。
    • 32～128kbps … AirH" ? 年齢バレちゃう

Laravel10出ましたね（かねだ）

  • Laravel ９系のマイナーバージョンアップだって人がいるみたいですが、
  • インストールしてみたら、さまざまな変更があって苦労した
    • .envのエントリーが変更になってるのはびっくり（MAIL_DRIVER => MAIL_MAILERとか）
      • 名前としては確かに MAIL_DRIVER より MAIL_MAILER の方がしっくりくる。名前を派手にかえる系かな。
      • 地雷が多い
    • 言語ファイル置き場(langディレクトリ)の場所の変更が有ったりpublishしないと作成されなかったり
    • LaravelはLTSがない状態でやっていくのか、頻繁にアップデートしていくか
      • ちょっと怖い。リスクがある、人気さがらないか?
      • LaravelはLTSを辞めたらしい。
      • フレームワークは5年くらいサポートしてくれるとうれしい。
  • まさに今月からプロジェクトスタートするんで、これ使うらしいです
  • PHPもLaravelも毎年のバージョンアップで大変
  • LaravelのEoL
    • Laravel 8.2.2にしてくれたらよかった。
      • Ubuntu/Fedoraっぽい, bleeding Edge ?
    • CakePHPはもう少し安心してつかえる。
      • Debianっぽい
  • システムをぽこぽこ変えてくれるお客さんならいいのですが。
  • CentOS みたいに10年サポートは浦島太郎になってしまうので4年ぐらいで変えたい。
  • Laravelはフロントエンドまわりはいい。モダン!
  • Laravelを使うならWAFがほしい。サポートが切れてもWAFで弾くぐらいはしたい。
  • 某社は開発するシステムは全部ワンオフ(製品ごとに一からつくる)
    • 1回納品してからはそのままで、あるとき突然改修依頼がくる
    • あたまおかしい(ほめていない)
    • セキュリティ上の懸念がある→開発者が鍛えられるからヨシ!
  • Debian 12はフリーズが開始…
    • Bookwormからnginxのmodsecurityプラグインがaptではいるようになってうれしい
    • 以前はこのプラグインは自前でビルドが必要だった。これで簡易WAFで最低限の防御ができる。
    • libnginx-mod-http-modsecurity
    • サポート切れてもWAFでカバーできてうれしい。
  • WAFでセキュリティが担保できるっていうのはリテラシーが必要。
    • 「WAFは万能ではないのでルールを運用しないといけないよね!大丈夫ですか?」→「運用っているの?」「ソレナニオイシイノ」という人もいる
    • セキュリティソフトもウィルスパターン更新するよね??
    • 正常系がWAFでブロックされたりするでしょ。
      • シグニチャ更新で挙動変わるときもあるのでは？
    • テスト環境からWAFを入れて開発したほうがいいかも

遅ればせながら、WSLでsystemd使えるようになってます！（かねだ）

休憩

再開は15:00~です。

GraphQL つかっていますか？ (アカベコ)

  • GraphQLはAPIの規格のようなもの。
  • 使っているとしたらどのようなserver/client構成にしているのか聞きたいです
  • うちはNest/NextでフロントのGraphQLクライアントは urql を採用してます
  • Query/Fragment設計とかで知見あればうかがいたい
    • 会社では使っていないが個人では試している。
      • 一人でserver/clientを開発でする分には、いらないんじゃないか説
        • ある程度分業化・API抽象化が進んでいるときに変更点をGraphQLで吸収できる
      • 目的としているサーバー意外でもGraphQLで集約できる(単一エンドポイント!)。
        • 間にGraphQLサーバーに集約できると便利なことがある。
        • 知っているサーバーは1つでいい。
    • 型つけするメリットが理解される必要がある。文化圏の問題。
      • 静的型付けはほしい、便利?
      • 画面毎に必要・不要なパラメーターが指定できるのもいいと思う。
    • データサーバーにはやさしい?
      • 人間がかわるところが減る。SQLのがんばるところを減らせる。
    • OpenAPI：https://www.openapis.org/
    • GraphQLはサーバー側が厳しくなることもある。
      • META社のリレーという規格・設計方法があり、これで対応できる
        • https://github.com/facebook/relay
        • NodeとEdgeを指定させることでデータ容量などから負荷のコストを自動計算してくれる。
        • これであまりに深い場所に投げると負荷制限を超えた場合はエラーを返すなども可能。
      • RESTだと、複数のQueryを投げないといけないことがある。
    • GraphQLは大きなバイナリ(Base64でエンコード)を投げてはいけない
      • クエリのパーサーが重くなって死ぬため
  • Reactを使う場合Redux とかで便利にできる。
    • 状態管理をGraphQLクライアントに丸投げできるのでhookだけでできる。
    • GraphQLとかはストアしてあるデータが古くなったかどうかを管理するフラグがあるので、必要なデータだけ取りにいくといったことができる。
  • デメリット
    • 今あるシステムで互換性のないシステムをリリースしている場合、GraphQLは向かない。
      • GraphQLは基本的に長く運用されるような現場に向いている。
      • 型定義があると便利なんだけどチーム開発ができていないときびしいというのはある。
    • 将来(5年後)にどうなっているかわからない。
      • システムのトレンドがどうなっているのか。5年後にどうなるかわからないものは。厳しい。
  • TypeScriptの型定義をJavaScriptの型アノテーションにしようという提案(TC39)がある。
  • WASIはクロスプラットフォームの標準バイナリ規格になるんじゃないか?
  • 便利よねで始めるのは怖い
    • 深く理解してから始めるならいいけど。
    • JS界隈は流行りに飛び付く傾向がある。怖い。
    • システムのライフサイクルを考えているのだろうか? 業態とか。
    • だいたいのシステムの寿命は5年いかないからいいんじゃないという意見もある。
    • 個人開発のはいつまでメンテナンスされるかどうかは怖い、避ける
    • 導入時の手間やコストを下げられるのは、導入したいと考えている
      • 例えばGraphQLは導入に一週間以上かかるので許容されない。
      • これが1日作業でメリットがあるなら導入できる
      • ただしそのようなものはでてきていない
    • 年々新しい技術の取り込みには否定的になってきている。年齢?
    • 新しい技術を取り込むのは学習コストがある。
  • 両極端な対話ができておもしろかった。
  • 新しい技術の評価は重要ですよ。
    • 逆に新しい情報をキャッチしていかないのもリスクにはなるので、把握は必要ですよ。
    • 世界的に技術レベルが世代レベルでおくれてしまう可能性はある。
    • 試しておく、採用しない理由が説明できるというのは重要。
    • リスクの少ないプロジェクトで試すというのはいいと思う。
      • 自社システムで試せばいい
      • 顧客システムで採用を求められたときに対応できる。
    • 男のロマン、ロマン駆動開発。

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

Youtube用動画β4が出来ました（もりや）

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

フロントエンド開発のためのセキュリティ入門 (ワテ)

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

  • フロントエンド開発のためのセキュリティ入門知らなかったでは済まされない脆弱性対策の必須知識
  • ソースネクストの事件
  • 今さら感がある
    • 今の若い人は知らないからじゃないの?
      • 今の人は知らないといけないことが多すぎる
      • 昔は両方をやっていたが、今は分業ができている。
      • インフラまで含めるときびしい。
      • 開発環境の構築だけでも、dockerで構築するので説明がむずかしい。
      • 補足情報が多くなりすぎている。
      • 今の人は、インプットとアウトプットではヒットしない。ブラウザに絵を出さないとだめ。
        • 黒い画面は拒否されてしまう。
    • フロントから言わせてもらうと、フロントとサーバーがまざってきてる
      • 昔バックエンドで対応していたことをフロントでもやる必要がでてきた
      • AJAXなどの時代でAsyncみたいなことをやるようになって、セキュリティをやらないといけなくなったのがある。
    • これまではセキュリティをやらなくてもすんでいたんだけど今は必要になってきた。
  • 某ネットのメールはスパムが多くて本来のメールがスパム扱いされてしまう。
  • アドワーズ広告でスパムサイトを上位にだすとか。
  • フロントエンド向けもあるけどバックエンド向けにもセキュリティ意識してくださいよね、目線があるのかなと。
    • バックエンドはフロントからおかしなデータがくることはないと想定するのはおかしくない?
    • フロントを信用してはいけない。
      • GraphQLはフロントから送られてきたデータを検証するというのがある。
      • 受領データのサニタイズなども必要ですよね。
  • セキュリティ診断やWAFを提供しているところが監修している。
    • 自分達のノウハウを公開してくれている本なので良心的。
    • 徳丸本はいい本だけど、時代を感じる本。内容は普遍的だがVMWare PlayerでVMを作るなどモダンではない。
  • 安全圏でいた人もいる
    • 保護されている安全圏だけでやっていた人もいます。
  • リクエスト毎に認証する必要がある?
    • コストとパフォーマンスの問題もある。本人認証とデータ自体を確認するの二種類がある。
    • 文字列に対しておきるインジェクションは本人であっても怪しいデータは検証しないといけない。
    • 認証であってもなりすましなどがあるからデータの検証は必要。
    • オンラインゲームなどは通信を検証している。パフォーマンスは必要。
  • この本のフロントエンドはブラウザだけではなく、スマフォなどサーバーに接続するものすべてなので範囲が広い。

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

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

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

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

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

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

  • sed や awk や bash などは短く書いてきちんと仕事できていいのですが、いつの間にか人に読まれなくなる、敬遠される、みたいな風潮があります(泣)
  • bashくらいはいいのではないかと思いますが、このようなことは他言語でもあるのでしょうか?
    • 他の言語でもある。
  • 老害のなげきなんじゃないか?
  • シェルスクリップトは読んでもらえない。
  • 開発の主となる言語で書かないといけないのかなと思う。
  • 他の人もメンテナンスできないといけない。
  • Ansibleでも同じですが、Ansibleだと他の人にも読み書きできる。
    • 処理を書かないというのが重要なのもかも、宣言的であればいいのかな。
    • 自分だけにかえってこないようにしたい。

告知

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