- MuscleMixin
- Rubyと筋肉を作り込む話
- PicoRubyとマイコンでトレーニング計測装置を作る
- LEDで速度と加速度を示す
- ダンベルを挙げる速度と重量が相関する
- 速度を知りたい
- 機器は大がかりであったりプロ向けであったりする
- 自作する
- エンジニアリング
- お小遣いの範囲
- 速度を知りたい
- ATOM Matrixを採用
- オールインワンであることを重視
- Hello, PicoRubyはできた
- それ以外(センサーなど)が動かない
- ic2がない、などなど
- Fail Fast
- それ以外(センサーなど)が動かない
- プロトタイプから作る
- Arduino IDEで作る
- ある程度作り込む
- Rubyで動かしたい
- 当初作りたいものを作る
- PicoRuby, ESP32, i2cの組み合わせを動くようにする
- 助けを得て、picoruby-i2cのESP32バージョンがマージされる
- 加速度センターはスタンドアロンのライブラリとして実装
- PicoRuby, ESP32, i2cの組み合わせを動くようにする
- 今後の課題
- 筋肉
- トレーニング・栄養・休息
- 装置
- 機能追加
- メモリ問題の解消
- プロファイリング
- 落ちない脂肪はない、付かない筋肉はない
- 落ちないメモリはない、追加できない機能はない
- 筋肉
Last active
June 28, 2025 09:06
-
-
Save okuramasafumi/59c05c71c29af55f4be3337aa032c827 to your computer and use it in GitHub Desktop.
関西Ruby会議08
- Rubyとロボットの話
- Rubyと作ろう!ロボット制御
- 6軸ロボットを動かす
- ロボット制御の2つの世界
- HWリアルタイム
- 1msecの制御
- SWリアルタイム
- もう少しゆるい
- 今回はこちら
- HWリアルタイム
- ROS
- Robot Operating System
- OSというか、通信ミドルウェアを中心としたエコシステム
- ノード(プロセスのようなもの)を基本とした分散アーキテクチャ
- PubSub, RPC的な通信の仕組み
- 基本的にLinux
- 公式開発言語はC++とPython
- デバッグツールやライブラリが充実している
- Rubyのクライアントライブラリがすでに存在している
- rclrb
- Linuxでは使える
- マイコンでも動かしたい
- rclrb
- micro-ROS
- リアルタイムOSでの動作を想定
- 各種マイコンサポート
- 開発言語はC言語
- mrubyから使えそう
- 開発内容
- mrubyとmicro-ROSを同時にビルドできる環境の構築
- 最新のESP32への適合
- mruby_esp32_microrosの実装
- これがメイン
- mrubyでロボットが動くようになった
- 30ヘルツくらいで動く
- 課題がたくさん
- rcl APIをどうRubyらしく使えるようにするか
- PicoRubyでも使えるようにしたい
- RBSを使われるようにするための活動
- RBS/Steepのメモリ削減
- SteepのLSPサーバーでメモリ使用量が多い
- マルチプロセス、エディタ常駐
- 複数プロジェクトだとすごい量のメモリを食う
- マルチプロセス、エディタ常駐
- Majo
- Refork
- SteepのLSPサーバーでメモリ使用量が多い
- Majoは長生きするRubyプロセスのためのメモリプロファイラー
- memory_profilerというgemもある
- ピーク時の使用量がわからない
- 全てのオブジェクトを集計しても、プロファイリング中に生成されたものだけを集計しても、うまくいかない
- ピーク時の使用量がわからない
- MajoはGCを生き残ったオブジェクトだけを対象にする
- 出力はmemory_profilerをほぼ同じ
- CSV出力も可能
- 集計前のデータなので加工もできる
- CSV出力も可能
- 実装は、オブジェクトの生成と解放にフック
- rb_gc_countも記録しておく
- ObjectSpaceのmemsize_ofメソッドも使う
- CレベルのTracePoint APIを使う
- GCが走っている最中なので、フックの間ではGCするようなことはできない
- 【私見】これはRubyKaigiでのIvoの話と一緒
- GCが走っている最中なので、フックの間ではGCするようなことはできない
- 効果:空のHash/Arrayがたくさんあったのを削減
- memory_profilerというgemもある
- Refork
- メモリ削減は十分ではないので、メモリ管理の方法に注目
- ワーカープロセスごとにメモリを使っていた
- fork, Copy on Writeの説明
- CoWをうまく使えていない
- 管理プロセスとワーカープロセスが共有できるメモリが少ない
- Refork
- 管理プロセスから一つのワーカープロセスをforkし、そこからさらにforkする
- Pumaなどで使われているテクニック
- Steepの実装:
- 一つのワーカープロセスを1回温めてからrefork
- プロセス間通信
- IO.pipe
- 孫プロセスとの通信の難しさ
- 子ワーカー作成時点で孫プロセス用のパイプを予め作成する必要がある
- 解決方法:UNIXSocket.pair
- sockerpairシステムコール
- ファイルディスクリプタを送受信できる
- パイプを子プロセスに送れる
- ファイルシステムで通信することもできる
- 権限管理や削除などが面倒
- その他reforkの話
- Process.waitは子プロセスしか待てない
- Process.warmupをfork直前に呼ぶとメモリが削減できる
- 実装を通して
- RubyKaigiをもっと楽しめた
- 自作サービスの話
- Annict
- 観たアニメが記録できるWebサービス
- 以前はスプレッドシートで観たアニメを管理していた
- 他の記録サービスも利用していたが、自分のユースケースが満たせなかった
- アニメデータのインフラを目指す
- データベースの拡充
- WebAPI
- Mewst
- マイクロブログ
- タイムラインは時系列のみ、ポストへの反応はスタンプのみ
- ほっと出来る居場所がほしかった
- 他の人の活動はたまたま観られる
- ブログとして便利な機能を追加したい
- クライアントのためのAPIを追加したい
- Wikino
- Wikiアプリ
- Markdownで書ける、関連ページリスト
- インターネットに公開可
- Markdownで書けるCosenseがほしかった
- 他のサービスはMarkdownには対応している
- ドキュメント界のGitHubを目指す
- 10年の開発で得た知見
- 自分が欲しいものを作っても意外と使ってもらえる
- 続けるために無理をしない
- 技術的な実験ができる
- Railsアプリの設計の話
- オレオレクラス設計
- 最初は良くてもだんだんしっくり来なくなる
- 利用目的が漠然としている
- 最初は良くてもだんだんしっくり来なくなる
- 解決したい問題
- トランザクションを張る場所をまとめる
- 入れ子を防ぐ
- モデルのコールバックを避ける
- 副作用がある場合
- ビューでデータベースへのアクセスを避ける
- N+1の解決が難しくなってしまう
- トランザクションを張る場所をまとめる
- クラス設計
- View, Componentはview_component gemを利用
- Sorbetで型付けできる
- Formはいわゆるフォームオブジェクト
- Modelは構造体やPOROだけ、DBアクセスなし
- RecordはActiveRecord
- RepositoryはRecordをModelに変換するクラス
- Serviceはデータの永続化を行う
- トランザクションはこの中で開始する
- ビジネスロジックは書かない
- View, Componentはview_component gemを利用
- 依存関係を整理する
- 独自クラスは個人開発だから自由に使える
- チーム開発なら標準構成に従ったほうがいいときもある
- オレオレクラス設計
- dRubyでゲームを作った話
- dRubyとWebSocketを使用
- SurvivorとHunterに分かれてプレイ
- なぜdRubyを使ったか
- dRuby on Browser again!の発表
- ゲーム全体のアーキテクチャ
- ブラウザではThree.js
- 中間サーバはSinatra
- ブラウザと中間サーバはWebSocket
- ゲームサーバーはRuby実装
- ゲームサーバーと中間サーバはdRubyで通信
- 3種類のスレッド
- dRubyメイン
- WebSocket状態更新
- タイマー
- dRubyではブラウザと直接通信できない
- バグ集
- 相手のアバターが見えない
- JS側のミス
- 画面がブルブルする
- サーバーへのアクセスが多すぎるので減らし、クライアント側を優先で処理する
- 捕まったSurvivorが移動できる
- サーバーへのアクセスが減ったため、確認がされていないケースがある
- 相手のアバターが見えない
- 改善したい点
- dRubyなのでセキュアではない
- パフォーマンスの懸念
- ruby.wasmで動かす
- Creative Codingをするようになったきっかけ
- Processingとの出会い
- 偶発性
- いつものWebサイトを構築する感じでCreative Codingをする
- 見つけた作品(アナログ時計を並べてパターンを構築する)のオマージュを作りたい
- 1st versionはVueで作る
- 2nd versionはRuby(Rails)で書く
- 前回はJSで作ったので今回はJSを減らす
- Hotwireを使う
- 時計の針を自由に操作する
- 時計っぽいが時計にはない動き
- 長針と短針の角度を別々に持つ
- 時計っぽいが時計にはない動き
- 時計をルールに沿って並べる
- 位置ごとに性質を分ける
- 配置を数字に割り当てる
- 前回はJSで作ったので今回はJSを減らす
- Railsアプリケーションとしての動き
- 配置のマッピングごとに時計オブジェクトを作成し、コントローラにオブジェクトを渡してビューで描画
- 初回アクセス以降の動き
- Turbo Frameを使うとアニメーションがなくなる
- CSSアニメーションをメイン、1分ごとに初期値に戻るのでTurbo Frameを発火させる
- 遅延があるので良い感じにごまかす
- Turbo Frameを使うとアニメーションがなくなる
- WASM版も作った
- こちらはそのままcanvasにレンダーする
- 個人開発楽しい
- 富岳の話
- 神戸にある
- CPU -> CMU -> ラック -> ラック400台で富岳
- 数理社会科学に活用されている
- 社会科学にも
- 人流交通、経済、社会ネットワーク
- OACIS
- シミュレーション実行管理システム
- 研究者は思考し、シミュレーションをループし、成果をまとめて発表する
- シミュレーションのループはボトルネックになりがち
- 結果が散らばり覚えづらい、自動化が難しいなど
- シミュレーションのループはボトルネックになりがち
- Webアプリケーションとして公開するものではなく、GUIアプリケーションのように使われる
- ワーカーがいて、計算ノードにSSHログインしてジョブを投入
- ワーカーは定期的にジョブの結果をチェック
- パラメータの組み合わせを網羅的に実行できる
- 実行結果を可視化することもできる
- 工夫:
- シミュレーターはRubyではない言語が多く、入出力形式も様々
- 文字列で登録し、シェルスクリプトで実行
- APIで相関の探索やパラメータの最適化を自動化できる
- 開発の歴史
- 2013年から
- 様々な利用例がある
- 科学技術計算でもRubyは使われている
- 生活の中でのrails new
- 「やるぞ!!」という気持ちを持ち帰ってもらうのが狙い
- ここ数年個人開発でリリースまでいってない
- 手持ちのサービスがほしい
- ポッドキャスト関係のサービスを作る
- RSSはポッドキャスト関係ではまだ使われている
- 作る意味はあるか?
- 既存サービスもある(Spotifyなど)
- Rails界隈で作っている人もいる
- ポッドキャスト関係のサービスを作る
- ChatGPTを補助として使う
- 手持ちのサービスがほしい
- 作ったポッドキャストアプリ
- 音声・画像ファイルの保存と配信
- ActiveStorage, S3, CloudFront
- RSSフィードの発行
- respond_to/format.rssのみで足りる
- インフラはAmazon Lightsail
- Herokuなどの選択肢も浮かんだが、AWSに寄せる
- デプロイはKamal2
- せっかくRails 8でrails newしたので
- SQLiteを本番で使っている
- これもRails 8のデフォルト
- 音声・画像ファイルの保存と配信
- Spotifyが生成するフィードに合わせていく
- リリースできた理由
- 小さく作って出す
- 様子を実況する
- 自分が最初のユーザーであること
- 続かない理由
- お金
- 気を抜くと3000円くらいインフラにかかる
- 使わないまま払うのはつらい
- 気を抜くと3000円くらいインフラにかかる
- ユーザー不在
- 外部要因(外部APIの仕様変更)
- お金
- 「作ろう」までに至る機運
- 好きなことや趣味をたくさん持つ
- コミュニティで他の人の勢いを知る
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment