久しぶりに恵比寿で降りたかも。
オープニング / @kmizu
19:06
- 趣旨
- ライブラリ開発における苦労話を共有したい。
- 大体が暗黙知のまま
- 書籍になってない
- #NextbeatTechBar
- 会社紹介
19:13
Rubyの標準添付ライブラリを開発する / @soutaro
19:15 リモート発表
- gem = ライブラリ
- RubyGem = ツール or ホスティングサービス
- Bundler = インストール管理ツール Gemfileをよんで
- なぜツールが2つあるのか? → rubygemがすごく古いから 2004年 mavenがでたあたり
- bundler 2010年 5年間で必要なことがわかった
- ライブラリ分類
- embedded: 必須 Cで書かれている
- standard lib: gemになっていない 歴史的に標準添付
- deefault gems: core-teamが管理 openssl yaml
- buldled gem: rubyをインストールするとはいるがruby本体との関係は緩い (bundled_gems)
- rbs gemの開発
- ruby 3.0からbundled gemsになっている
- rbs: プログラムの型を表現する
- rbs gemの中には組み込みの型が定義されている
- rbsの定義はそのときのrubyリリース版のもの
- なのでruby開発版ではCIのrbsテストが失敗したりする。
- なのでプルリクエストを出しにくくなっている。
- rbsをリリースしなくても最新rbsをcommit+pushしておけばCIでテストできて、それからrbsをリリースできるようになった。
- rbs_skip_testsに書いておくとテストをスキップできるようにできる。
19:31
- embededはrubyで書かれてないのでそのための解析機をつくるのはめんどくさい。
19:33
趣味のBlenderアドオン/ライブラリ開発で、Pythonエコシステムが想定する開発プロセスを無理やり導入する / @saturday06
19:33
- キャラの物理テクスチャを共有する共通規格がない。
- poetry/pyproject.toml
- mypy --strict
- blenderは一般的な書き方とはちがっててうまくとおらない。
- bar: intProperty(main=0,...)
- pythonの文法は簡単だからregexでがんばって回避
- __init__.py
- そのフォルダがパッケージになる。
- どこでgit cloneするかでパッケージ名がかわってしまう。
- blenderの型定義を書いた
- 3000行になった
- 3Dデータを不用意に公開してしまわないように工夫が必要だった
- 一般人はgithubのページをみてもわからない
- ファイルをへらしたreadmeブランチをつくって "download" をみつけてもらう。
- blenderはZIPファイルのままでインストールしないといけない。
- でも無意識にunzipしてしまう。。。
- pull requestもらってもコードのクセがちがってマージしにくい。
- そのままマージしてからlinter/formatterをかける。
- github issueがそのサポートスレッドになってしまう。
- 1issue=1バグにしてほしい。
- バグ報告をgithubにだしてくれなくてdiscordに書かれてしまう。
19:51
- libreofficeのバグを2chであつめて直してて粘着するひとがいて、それにくらべたら楽。
- jarファイルも同じ経緯で拡張子を変えてて、おなじようにしてみてはどうか?
- いまのところ変わらなさそう。
- webstoreから入れる方向になりそう。
19:56
個人開発OSSが世界に勝てなかった話 / @yukinarit
19:56
- pyserde パイセルデ
- Rustのserdeはpyserde にインスパイヤされている
- 証券会社: transportが multicastつかったりでgRPCつかえず → 自前
- pydantic: データバリデーションライブラリ
- なぜ勝てなかったか?
- 1. 一人 vs 企業 開発力の差は問題ではないとおもっている
- 2. 広報活動
- 3. Rust スクリプトもRustで書くようになって pythonをつかわなくなった キャッチアップしなくなってしまった dogfooding重要
- ドキュメントは英語で readme, tutorial/guide, API.
- とことん自動化している CHANGELOG 作成も自動化している
- 全部自分でやらない
- OSS活動をしたいひとがいて、簡単なissueをのこしておくとやってくる。
- Good first issueラベルをつけておくとよい。
- プロジェクトの方針に合わないプルリクは入れない。
- おもいきって互換性は捨てる。
- 機能ごとの超簡単なexampleを作る。テストにもなるしshowcaseにもなる。
- 無理をしない。家族優先にして空いた時間に。
20:15
- github sponsorはまだ早いかなぁとおもってやってない。
20:17
(休憩)
ライブラリをパブリッシュせずにすばやく試す方法 / @exoego
20:31
- ライブラリ開発でよく困ること
- プルリクおくってもマージしてもらえない。
- マージされたけどpublishされない。
- forkすると、つかっている他のライブラリも対応しないといけなくなる。
- maven centrall, npm, pypi, rubygems なしにつかえるといいなぁ。
- 1. local publishする。CIはうごかない。
- 2. gitリポジトリを指定する(とつかえるようにしてくれるツールがある)
- VMのようなソースコードだけで動く言語ではないと
- gitpackというツールがあるよ
20:40
SRE領域におけるライブラリ開発の取り組み / @sre_yamakita
20:40
- site reliability engineering
- 属人化させない
- トレンドにながされない
- バージョン管理はしっかりと SREはAPIよびだしが多くてバグると被害がおおきい
バニラJS開発ライブラリー事情 / @piro_or
20:46
- 昔のfirefoxはJS注入になってて、静的解析しにくい。名前汚染とかも。
20:54
セキュアなライブラリ開発〜OpenSSFの取り組みについて〜 / @kamiazya
20:54
- ts-graphviz
- 依存関係の脆弱性
- OpenSSF linuxfundation サプライチェーンの安全化
- 1. OpenSSFガイド 資料集
- 2. OpenSSFベストプラクティス バッジ
- 3. OpenSSFスコアカード CLIツール
21:00
クロージング
〜21:01
懇親会
JS,TS,Rustとかいまどきの話ばかりで話の輪にバリアが...
懇親会終了まぎわにC++でもりあがってるところがあって、やっと話に入れたわ...