Pixel Pedals of Tomakomai (original) (raw)
昨日から YAPC::Hakodate 2024 に参加していました。今回は何も書き残すつもりはなかったのですが、せっかく会社のお金で来させてもらっているので何か収穫を持って帰らねばと思っていたら手元にメモができたので、未来の自分のためにも公開して残しておきます。
10/4 前夜祭
デジタルIDウォレットが切り開くHigh Assurance Identity Proofingの未来 / kokukuma さん
- high assurance identity proofing
- wallet を使った認証
- iOS / android credential manager
- どんな身元確認か、仕組み
- resolution 情報取得, validation 検証, verification 本当に本人が送ったのか
- ホ方式 写真とその厚みなどで確認
- へ方式 ICチップから読み込んだ情報で顔写真を使う
- ワ方式 特定取引情報(電子署名を利用) マイナンバーカードのパスワード=電子署名の持ち主
- verify with wallet API のイメージ
- 共有していいか確認 → アプリに提供
- 一度だけで本人確認、送る情報を絞れる
- RP server, RP, Issuer, Wallet
- データは RP server でしか復号できない
- HPK mdoc/mDL
- 本人情報は署名に含まれていない
- mdoc response 情報の一部だけ
- issure signature, digestの検証 / validation
- device signatureの検証 : verification 本人にしかできないから
- 希望→法要件、android + my nuber, digital credential から apple wallet
- 身元確認と同時にpasskey, walletから使える情報の追加(ホテルのチェックインとか)
- 海外展開
入門 バックアップ ~ データ保護の基礎から実践まで ~ / ryuichi_1208 さん
- バックアップをしないとデータロスト
- 仕事、個人レベルの影響
- gitlabさんの障害事例
- データがでかい、コストがかかる、設計が必要
- 目的(災害復旧なのか、法規制か)
- RPO(recovery point objective)とRTO
- リストア方針
- 定期的なリストアテストが必要(gitlabさんはリストアができなかった)
- フルリカバリーテスト
- シミュレーションテスト(手順書のテスト、トレーニング)
- リストアテストは自動化している
- セキュリティ
- 暗号化、アクセス制御、保管ポリシー
- 実装方法 フル、差分、増分(初回からの増分)、コールド、ホット
- 差分の欠点→リストアしにくさ。全部必要。
- コールドバックアップ 夜間のサービス停止が必要
- ホットバックアップ 静止点が必要
- バックアップはトレードオフ
- 実例
- コンテンツサーバとバックアップ、オンプレ
- コンテンツサーバ : HTTPなどでアップロードされている
- rsyncが使われる
- SSH、フル、差分、増分
- rsyncだけでは静止点が取れない
- flockでロックを取る?やったことはない
- 障害例: rsyncでページキャッシュが汚れると、パフォーマンスが悪くなる nocache で解決
- データベースのRPO フルバックアップの間隔では長すぎる
- PITR: point in time recovery / fullbackup からトランザクションログでroll forward
- MySQL InnoDB PITRも可能
- 論理バックアップと物理バックアップ
- 「本当に必要なときにないのがバックアップ」
ガバメントクラウド開発と変化と成長する組織 / kazeburo さん
- ガバメントクラウド デジタル庁、クラウドサービス基盤
- 既存のパブリッククラウドを最大限使う
- 柔軟、迅速な調達。セキュア。一括調達(市区町村など)、運用の省力化。
- 課題:コロナの給付金支給など
- 標準化
- 2012 霞が関クラウド、2017 cloud by default 2021 デジタル庁 2022-2024 ガバメントクラウド
- 17項目、300件の要件
- 要件、クラウドである。、パブリックである、リストア、グローバル10拠点以上など
- さくらがなぜ? 国産クラウドの価値、データ主権、デジタル赤字の改善
- 社会からの期待、ブランディング
- 2023年は15人
- IaaSの機能が多岐過ぎる、人不足、オンボーディングコストが高い
- チームを4分割
- 開発生産性「認知負荷(対象を限定)、コミュニケーションコスト」、並行開発
- 一人で速くではなく、みんなで遠くへ
- 自分ごと化のためにボトムアップが必要、読書会「生産性、互いを知る」
- leanとdevopsの科学
- 1on1 でメンバーに伝える「サプライズにしない」
- チームを維持する「プロダクトは長く続く」
- チームに自律性。チーム責任者、開発支援者、テックリード
- エンジニアの変化→自律的な動き
- スケールする課題が増えるとより良い解き方ができる
AWS Lambda FunctionURLで実現するスケーラブルで低コストなWebサービス構築 / fujiwara さん
- lambdaはFaaS / Perl も関数として呼び出せる
- イベントを契機にマイクロVMが起動
- 複数イベントで自動でスケール
- web app の lambda 化
- web hook などに使いやすい
- API gatway, app load balancer, lambda function URLs
- URLが発行される
- HTTPリクエストはJSON化される。
- use Kossy など使うと簡単。
- AWS::Lambda::PSGI
- Go は fujiwara/ridge (同じバイナリでlambdaとhttpに対応)
- lambda web adapter (別プロセスで解釈)
- Tonamel を lambdaへ移行
- e sportsのトーナメントを作れる
- 2017 / EC2 perl MySQL
- 2020 Goでマイクロサービス化
- 10以上がマイクロサービス
- 大会が始まった途端にスパイク。20倍
- 予測オートスケール→開催日と人数、閲覧者数は職人が推測
- 予測が外れると厳しい。月一回程度の障害
- ECSからlambda移行でコスト大幅減
- katsubushiとfluentdはECSのまま
- lambdaのコールドスタート? 1秒以内で問題なかった
- デプロイツール espresso / lambroll へ移行、簡単
- 開発環境、プレビューが欲しい
- lamux / alias機能で開発者ごとに呼び分ける
- perlbatross / コードの任意実行。外側のlambdaで
- IO待ちが多い、低レイテンシ、アクセスが一定、には lambda は向かない
座談会「50代を現役プログラマとして」
- スーパープログラマではない
- 平凡なプログラマ
- スーパープログラマの凄さを知れる
- 世界を変えられることを知っている
- なぜプログラミングできている?
- 運が良かった
- 事例を作っていきたい
- 運はすごくある。運を掴む行動はある。
- 年を取ると運を掴む行動が減る
- 場にいるのが大事
- 函館遠かった
- 平凡?スーパーではないが良い経験を積んだ人をなんて呼ぶか。価値があるはず。シニア
- 年令によってコードは変わった。戦略的。徹夜は無理。使う道具を選ばなくなった
- 新しい道具を便利と思い、乗り換えられる人
- 若い人と比べると、やはり乗り換えられてない。若い人と働くのは大事
50歳を超えると何が起きるのか
- 若い人からの突き上げ。年々優秀になっていく
- 2029年問題。情報が必須になった高校生が就職
- 認識の衰えが認識できない(間違えて今日みらい大に行ったり)
- 流動性知能の衰え 20年がピーク (推論力など)
- 生存戦略
- 結晶性知能を活用(過去に学んだ知識)
- 若い人とのプロトコルをアップデート
- モダンエルダー「経験で奉仕、若い人のメンター」
- 古い情報に抗うのは難しい「忘れる」
- ジュディマリは自分たちにとっての演歌
人生100年をハッピーに
- マルチステージの人生→意思決定が大事
- 計画的偶発性→不確実性との戦い
- 継続的な学習、ゲームチェンジャーを見抜く、やらないことを決める
- 経験への投資、先延ばしにしない(若い頃に投資)die with 0
- 無形資産への投資、スキル、仲間、投資
- 偶然を活かすための無形資産への投資
- 知能の変化を知る
- 人生で今が一番若い、知能の変化を活かす
- 「無計画的偶発性」
- 暗黙的に60歳を定年と見ているが、そうではない。何歳でも新しいチャレンジはできる。
- 35再定年説はなかった。リアル定年ものびる。地道にやるのが大事。
- いちばん大事なのは健康。
- 昔より腰が重い。若い人と働きたい。
小さな勉強会の始め方、広げ方、あるいは友達の作り方 / あらたまさん
- コミュニティの運営事例
- 若手webエンジニア交流会 引き継ぎが必要
- YAPC Japan
- Startup in Agile
- EMゆるミートアップ
- 勉強会の始め方→宣言する、一緒にやる人を探す
- まずは話しかける
- 話しかけてもらう材料を増やす。Tシャツ、スタッフになるなど
- 似たような悩みを持っている人は多い
- 無理に発話する必要はない
- OST 蜂、蝶。媒介、集める
- スピーカーはフィードバックを求めている
- 話したい気持ちと不安は両立。疲れたら休む。
- 続けられる?→飽きたらやめていい。新しい興味ができるのはいいこと
- 3回やってみて判断する、とか
10/5 本編
シェルとPerlの使い分け、そういった思考の道具は、どこから来て、どこへゆくのか? / 深町さん
- 技術史の話、お金の話
- コマンドライン操作、でコマンド履歴を保存、確認できるのが大事
- スクリプトが長くなるなら Perl 化
- Perl Conference Japan で話したこと
- コメントは必ず書く
- shell を 15 分で諦めた例(色々間違いをする)
- ls pwd cd make fg ...
- パイプ(メソッドチェーンと同じもの)
- 同じ時期に同じことを提唱する人はいる(歴史上に残るのは一人)
- パイプはどこか来たのか
- 仮説1. 実用性から? co-routine
* unix 回ハッツチームが | の記法を作った
- 仮説1. 実用性から? co-routine
- Unix の特徴
- マニュアルは完備
- Kernighan エバンジェリスト
- Ken Thompson が勝手に手伝ってくれてた
- Unix の立ち位置
- 軍用の予算よりは桁ハズレに少ない予算
- 民間企業
- 過去を振り返っって一般化すると、未来の傾向が読める
- 個別の予測は難しい
- Unix 史の振り返り
- お金が微妙、実用性
- コンピュータが高かった→効率化
- 科学技術者の狂気
- コンピュータは高価
- 助成金はどこに行くのか
- 最初は空軍
- タイムシェアリング、コンピュータグラフィックス、人工知能
- コンピュータはどのくらい速くなったのか
- 今の PC は半世紀前より数100倍速く、4桁くらい安い
- 1950 ~ 1970 年代の改善は冷戦のおかげ
- Vannevar Bush
- 20世紀最大の発明は?→コンテナ(システム)
- コピーコスト 0 円が大事
- パッケージビジネス、半導体
- 少数精鋭なら食べていける
- プログラミングはアートか?
- 狂気が必要
- 陶芸のほうが近い(実用性が必要)
- 幸せな環境→低価格、インタネット
- 実用上の理由、必要性
- 低コストで作れるものは、ある日突然変化する
- ベンチャーキャピタルから資金調達
- standalone な oftware の例→テトリス
- 修行中のプログラマーは、 AI によって食えなくなるかも
- 育てないと、会社の将来がなくなるのでは
プロファイラ開発者と見る「推測するな、計測せよ」 / osyoyu さん
- ソフトウェア産業の偉大な功績はハードウェア産業の功績を打ち消し続けること
- Henry Petroski
- 詳解システム・パフォーマンス / Brendan Gregg
- プロファイラとは?
- プログラムの遅い部分を特定
- -d:Profile
- Ruby プロファイラ Pf2 / Ruby の隅々まで正確に計測
- スレッドごと、フレームグラフ
- プロファイラは万能ではない
- frame graph だけ見てもだめ
- 推測するな、計測せよ
- 当てずっぽうでのパフォーマンス改善を戒める
- 計測すればそれでいいのか
- 当てずっぽうの計測にも意味がない
- 問題の真因に近づけていない
- 計測+検証可能な仮説→対応→検証(解決したの?)
- 計測 / 何を、どのように、どう評価する
- 事例 : 検索結果ページが開かない
- 計測できることが莫大にある
- 時間、メモリ使用量、リクエスト回数、関数の呼び出し回数
- それぞれにもいろんな単位がある
- 「因」「果」
- 「果」から「因」を特定していく必要がある
- 計測を繰り返して特定する
- 計測すべきことは状況の中で変化
- 仮説検証の中で計測すべきことは定まる?
- 「存在すら知らないこと」は調べられない
- CPU キャッシュの問題は CPU キャッシュを知らないと調べられない
- Known Known, Unknown Known (知っているが、まだ計測していない), Unknown Unknown
- Unknown Known, Unknown Unknown を Known Known にするのがパフォーマンスエンジニアリング
- いろんな計測
- ダルくてざっくり→ printf
- どう実装されているのか
- 時間は色々ある : REALTIME, MONOTONIC, CPUTIME
- プロファイラ / 一定時間ごとに、何をしているか
- カーネルタイマー(OS)にお願い
- シグナルハンドラ
- メモリの計測
- メモリレイテンシ / CPU のパフォーマンスカウンタ
- 下のレイヤが教えてくれることはすごく多い /proc/sys/kernel
- 計測はレイヤーをまたぐ芸術
- 「美しいと思いませんか」
- 結果をどう評価するか
- いつ計測するか、とセット
- 問題があったり isucon なら簡単だが
- プロファイラはそれを教えてくれない
- 「なんか遅い」を主観で判断するのはブレる
- パフォーマンス指標が必要 (isucon ではスコアを挙げて 100 万円)
- ワークロードの性質、 CPU 利用率
- メトリクスとしきい値
- メトリクスは計測
- 常に計測する
- プロファイラは「常に」ではないが
- Continuous Profiling
プロファイル作者の苦悩 (LT)
- 正しい計測ツールを図るのは難しい
- top で 100% ?本当に正しいのか
- プロファイラがパフォーマンスを歪める
- 処理が増えるため
- 観察者高価
- プロファイラ導入したときのパフォーマンス低下を計測
- 仮説検定まで
- プログラムが 1% 以上遅くならないようにする
- パフォーマンスツールは単一目的だがプロファイラは違う
- 何が求められているか不明
- 色んな知識がない人が遅い部分を知れる
* Unknown Unknown を作らない - デフォルトを決めるのは大変
- Ruby プロファイラは Ruby では作れない
- 計測ツールが正しいかを調べるのは困難
- 他のツールと比較・・・苦痛
- 「早すぎる最適化は諸悪の根源」→早いのはいいことでは
- profiler の出力のおすすめの見方は?
- frame graph 。その後に見る部分はシステム特性に応じて決めておくと良い
- 表示はどう決めている?自分で決める?
- 自分で決める部分は大きい、フィードバックほしい
- 他のプロファイラを参考にする。 firefox とか
- 多くの視点を得るにはどうする?
- 詳解システム・パフォーマンスを読む
- 本を通して浅く広い知識を得るのは良い。関係があるというとっかかりを得る
普通の Web エンジニアのための様相論理入門 / チェシャ猫 さん
- 時相論理 CTL 非同期システムのテスト
- 例: いいねするとゲージが上がる
- レースコンディションでうまくいかない(後勝ち)
- 大体の場合はうまくいく
- 非同期性は非決定性
- 動作の奇跡(グラフ)を網羅的に考慮
- 様相論理 Modal Logic
- グラフ構造上で意味論が展開(キャッチフレーズ的)
- 様相論理の種類
- Kripke 構造
- グラフのノード上で真偽値
- ノードと原子命題事に真偽値を与える
- CTL の論理式
- 原子命題 p は論理式
- 普通の論理式
- AX φ / AG φ / AF φ / EX φ / EG φ
- A(φ U Ψ)
- X (next) G (globally) F (future) U (until) パスの条件にする
- A (All) E (Exists)
- EX EG EU さえあればよい
- K, s |= Φ を定義
- AG(crash → EF recover) 故障後、復旧するルートが有る
- AG(crash → AF recover) 故障後、必ず復旧する
- 他の時相論理 / LTL CTL*
- システムを Kripke 構造、仕様を CTL 論理式で表現
- K と初期状態を与えると、Φかを調べる
- EX Φと E(ΦUΨ) の検査
- EG Φ 「無限に真が続く」計算が終わらない
- 強連結成分にたどり着くパスを探せばいい
- Kripke 構造 K の状態数が有限かであることは重要
- 濾過法
- 同値関係を定義
- 商集合で新しい状態を得る
- コンピュータサイエンスにおける様相論理、数学における証明と心理、モデル検査機をつくる
- ループに入れる PATH が複数あるとどうなる?
- exists がわかればいいので O.K.
- 濾過法のΦは?
- 検査したい論理式Φについて有限モデルを作るもの
- WEB サービスでどのように使えるのか
- 最上流。プロトコルなどの設計部分
未来は現在からの継続 / kii さん
- 「関数型プログラミングの基礎」
- 継続 : ある時点の計算に続くすべての計算
- 各計算の段階において、その後の計算が継続
- double(add(1, 2)) double は継続
- CPS / continuation passing stylle
- 継続を呼び出し元に教えると、処理を続けられる
- add を継続渡しに変える例
- 継続渡しにすると、処理が逆になる
- addCPS(1, 2, double)
- 成功継続と失敗継続
- 認知負荷が高い
- 再帰の場合関数の呼び出しスタック
- 末尾再帰最適化は気にする
- Promise のコールバック関数は継続みたいなもの
- 非決定性計算 1 + (2 or 3) = 3 or 4
- 2 を選んだ継続と 3 を選んだ継続
- パターンマッチ → 継続の分岐で利用
- Number(1) + Amb([2, 3])
- 型や値から複数の条件分岐
- OOP の多重ディスパッチに似ている
- 複数のインスタンスの動的な型情報に基づいて処理を決める
- 相手に自分のパターンを用意させておく
- FP でも OOP でも似た概念があって面白い
- 第一級継続、 call/cc 、継続モナド、代数的高価
- 業務で使うことは?
- 使おうとしたが使わなかった
- 継続渡しにどこで興味を持ったのか
- 関数型の本で知った
- CPS にするとテストをしにくくなる?
- 継続をモックする?どこまでできるのか。純粋関数を使えばモックしやすいのでは。多分やりにくい
けしからんライフログ研究 / 角 康之 さん
- 「公共の場でカメラを身につけるのはけしからん」
- 体験強調キャプチャ 2002 年
- 1 人称の映像の共有
- 顔数系
- 映像閲覧者のリアクションの理解と推薦への応用 2011年
- 非言語行動に注目したチュータリング会話の質評価
- チュータリングのインタラクションを動画、音声
- Slack へのアップロードして分析
- 「インターネットへの個人情報の共有は論外」
- PhotoChat 2005年
- 写真への落書きによるチャットシステム
- 「高速文字入力できるのだから手書きは不要」
- 環境音の近さによる会話場検出
- 音声のフーリエ変換で距離を調べる
- 「そんな方法でうまくいくわけがない。なめるな」→うまくいった
- tabimemo: 屋外での体験共有システム
- 「女子大生の卒業研究みたいだ」
- 凸凹スケッチ 2014年
- 深度センサーで距離を取っている
- 「スケッチの意義がまったくわかっとらん」
- 図書室での陣取り合戦ゲーム
- 人気のない棚に学生が集まる仕組み
- 本を借りる人の数が増えた
- 「滞在時間で手数付けするのはナンセンス」
- 社内会話による街の「いま」の可聴化 2012 年
- 社内会話が盛り上がっているところは賑わっているところ
- 「車の中の会話なんてノイズだらけで価値がない」
- WWW も同じことを言われていた
- Taxi Dash
- ボタンを押すとあいのり相手を見つけてくれる
- 「知らない人と相乗りを斡旋するなんて」
- ライフログ研究は人間科学
- 体験していない人には価値がわからない
- 10分程度のプロポーザルでは伝わらない
- プライバシー / 撮ってるほうが安心ではないか
- 「けしからん」と言われたほうが脈あり
- 学生は落ち込んでしまう
- 深い思考を促す。どうやって言い返すか、言語化
- 学生さんに「けしからん」と言われることを伝えていますか
- 「ここではなるべく役に立たないものを」と促す
off by one - 10年ぶりに CPAN Module を Update した理由 / dankogai さん
- 一個ズレた話 浮動小数と整数
- JSON の数値が復元できない
- log(2) の値を perl で表示して復元しても同じにならない
- node.js では復元できる
- 長く議論したが、そのまま行くことになった
- Rakudo は治った
- ワークアラウンド
- sprintf の %.17g
- C99 Hexadecimal Floating Point を利用
- 1997 年に書いたモジュール
- 例: stat
- JSON5
- JSON の拡張
- Hexadecimal に対応している
Webセキュリティのあるきかた / akiym さん
- Web アプリケーション開発で気をつけるべきこと
- ブラウザで URL にアクセス
- HTML/CSS
- HTTPアクセス
- URL も仕様は複雑
- URL のパスワード部分に誤読させるようなドメインを含める攻撃
- Cookie
- state less な HTTP での状態管理
- key=value で有効期限
- ドメイン、パスが同一であれば送信
- Set-Cookie のドメイン属性
- 先頭に . を入れても入れなくても同じ
- ドメインと path が違えば複数個保存される
- Cookie のどれを優先するかはアプリの実装依存
- Http Only : JS の禁止
- Secure : https のみ
- __Host prefix によって制限をかける
- Safari は __Host としなければならない
- SameSite / リクエストされた際での Cookie
- 同一サイト eTLD + 1
- .hokkaido.jp と .hakodate.hokkaido.jp
- publicsuffix/list
- SameSite=Lax をデフォルトとするブラウザは多い
- ほとんどのブラウザで SameSite=None とする場合は Secure が必須となる
- Cookie eviction / coookie数の上限を超えさせて上書き
- Same-Origin Policy (SOP)
- same-origin: scheme/host/port が同一
- Cross-Origin Resource Sharing (CORS)
- 異なるオリジンにリソースのアクセスを許可
- 単純リクエストではないもの
- カスタムヘッダ、 Content-Type を appliction/json などにする
- Cross-site reequest forgery (CSRF)
- CSRF の対策として「単純リクエストではないこと」を利用していると
- application/json かを確認
- Resource Isolation Policy / Google
- Same Site Cookie
- same-origin ではなく、サブドメインから
- Origin ヘッダのチェックは重要
- XSS Cross-site scripting
- self-XSS
- 被害者の操作によって発生する XSS
- Dev tools にコードを貼り付けさせて実行させるもの
- DOM-based XSS
- source: window.location など、入力ができるとこ
- sink: onclick など実行可能なところ
- エスケープは安全に表示できるようにする
- サニタイズは表示しても攻撃できないようにする
- ユーザが HTML を入力する際に JS の利用を禁止
- 自分で作るべきではない → DOMPurify
- sandbox domain
- ユーザが入力したものを表示する専用のもの
- cookie が書き込めないもの
- dngerouslySetInnerHTML / v-html
- 本当に使う必要があるのか考える
- javascript: URL
- user が URL を作れるときは確認が必要
- "javascript" で判定してはいけない(全角文字や改行などが入っていても動いてしまう)
- ライブラリに XSS が発生する sink もある / v-tooltip
- 古いライブラリのデフォルトの挙動に注意
- Content Security Policy (CSP)
- リソースごとにポリシーを設定できる
- TrustedTypes
- sync はいくつも存在する。見るのが大変
- Trusted Types しか sink に入れられないようにする
- CSS から指定
- X-Frame-Options 埋め込みの制限
- Strict-Transport-Security HTTPS を強制
- HSTS preload リストに登録すると https を強制
- X-Forwarded-For / proxy の IP アドレスを排除した一番端
- インジェクション
- order by はエスケープされていないことがある
- user data を受け取るときはすべてバリデーションする
- パストラバーサル
- パスの正規化に注意
- ロードバランサ、nginxやフレームワーク
//
を作れたりしてしまう
- S3 は . と .. はそのものとして扱われるが、アプリケーションが解釈してしまうことがある
- nginx で config を書くときに / で終わらないと /img.. のような指定が効いてしまう
- Q). Chrome の仕様が挙動とかどう付き合う
- A). 挙動を動かしながら調べる。泥臭い
北海道のエンジニアコミュニティ座談会
- mitani さん、 nagatani さん、 sugai さん、ジャンボさん、chikuwaさん
- 2013 年から OSC で勉強会のアンケートを取っている
- Hokkaido.pm 2010 年
- 函館本線沿線勉強会
- 函館本線の不思議な駅で勉強会があるのでは
- はこだてIKA
- みらい大にはもともと興味があった
- ハッカソンから Code for 道南(Hakodateへ)
- 昔からある
- OSC北海道
- 東京以外で初めて開催した
- local 任意団体から法人会
- 部活がある → 安全部、学生部
- 学生部
- コミュニティの変化
- 障壁
- 距離と天候
- 東京では勉強会の距離が近い
- 就職
- リモートワークで済むようになった
- 脱北の必要がないのでは
- コロナ後からフルリモートがまた終わりつつある
- 魅力
- やれそうなことが多い
- 年ごとに情報系の大学がある
- アルバイトがない→仕事がなさそう→脱北
- インスタントのコミュニティを作って集まれればいい
- マイクロコミュニティがいくつかあればいい
- 無理にやる必要はない。やれるときにやる
- すごい人がいるか / 活動力があったり、 OSS のコミッタだったり
- 運営が居ることを知らないと運営が必要なことが伝わらない
- Rubykaigi は代替わりのため一回やめた
- 活イカを一人で3バイ食べる
- 明日はイカまつりです
- 北海道に興味のあるエンジニアへ
- 今回は色んなバラバラな人を集めたので色んな話を聞けたのでは
code to survive
- dan the question 歓迎
- コードを書くだけでは成立しない
- コードを書かないと成立しない
- 小学4年生、未来大学
- 男の子がミサイルで犬を撃つ
- 機械工学科に入ってエンジンをやるつもりだったが、幼馴染が「これからはパソコン」と言っていた
- 電子回路、ハードウェア、ソフトウェア、ネットワークを体系的人学んだ
- 今はない学部
- 当時は Pascal でゲーム
- 犬を棒のようなもので叩くと遠くへ飛ぶ
- Twitter client を Swing で
- シングルスレッドのサンプラー
- 音がなると機能がすべて止まる
- 首都大学東京へ編入
- お金のためのバイト
- 地上波デジタル放送をスタジオ間転送
- 2011 年「ここからの時代は Perl 」
- Hachioji.pm
- 自己表現としてライブラリを公開し始めた
- はてなインターン 2013
- LINE でのバイト~就職
- 長年動く巨大 web app
- 業務で役に立つライブラリ、ミドルウェア重要性
- 便利であれば小粒でも
- Perl::Lint
- Sponsored Project
- $800 にしてしまった / 1,000 時間程度使った
- 換金してしまった
- YAPC::EU (Granada)
- lestrrat さんの助け
- After Party で声をかけてもらった
- 海外への興味
- tokuhirom さん「webサービスのおもしろさはトラフィックの量に比例する」
- ソラコム
- Soracom Global, Inc.
- コロナ真っ盛りでの移住 → カオス
- 開発と現地のカスタマーサポート
- 上場後 (某社を経て) SmartBank
- ソフトウェアプロダクトはチームワーク
- 興味ドリブンで個人技を磨く
- 技術、ドメインの資料は読めば読むほど身につく
- 読みきらなくても良い
- キャリアが浅い頃に読んだ本→ code complete
- とにかく大量に作る
- 量が質に転嫁する
- 作ったら外に出す→勝手に添削
- 仕事で再発明するには理由が必要。趣味であればいい
- 再発明によって先人から知見を得る
- 必要になりそうなパターンを先んじて全部作る
- 不要なものは捨てるといい
- 確認を待つと律速する
- 高速に物を作れるとそれだけでメリット
- 質と量が動悸する
- Shut the fuck up and write some code
- 個人技の向上は再現する?
- 教育。結果を図るのは難しい
- コンフォートゾーンから出続ける生存戦略
- とにかく手を動かす人が一番カッコイイ!
- 将来について考えていることがあれば教えて下さい
- マネージメントはフロンティア
- 5 年後にどうなってそうですか
- コードは書き続けていたい。汎化した形でスキルを移譲できるといい
- 本を出す?
- 10 年以上かかる
- 量をこなすのに「立ち止まってしまう」ことがあるが、どう乗り越える
- はてブ狙い、バズ狙い、ガソリンにしていた。今は違う
- コミュニティ。互いに話しながら一緒にやってくれる人
クロージング
- ベストスピーカー賞
- 副賞は北海道ギフトカタログ
- osyoyu さん 「とりあえず読めのために 940 ページの本。発送済なので出せないが」
- ベスト LT 賞
- スポンサー : トグルホールディングス株式会社さま
- Bose Quietconmfort Headphones
- うーたんさん「Kyoto からつながって良かった」
- 樽募金
- Kyoto から続いている
- 23,200 円
- もう締めました
- Thanks
- はこだて未来大学さま
- スタッフのみなさま
- スピーカーのみなさま(今回は厳選させていただきました)
- スポンサーのみなさま
- 参加者のみなさま
- 帰りのバスまであと 8 分
- 次回は福岡!・・・かもね
木更津に一泊をして、房総半島へ走りに行ってきた。
一日目は久里浜港まで自走をして東京湾フェリーで金谷港に渡ったあと、北上をして木更津へ至った。
二日目は五井駅まで輪行をした後、小湊鐵道といすみ鉄道に沿って大原駅へ至った。
今回の旅は、旅用のギアの確認と、そのギアでどのくらい走れるのかを把握する目的もあった。普段は 10Kg 程度の chpt3 を乗り回しているが、旅行に必要なものを積んだ M6R は 20Kg と倍の重さになる。いつもであればそんなに苦痛じゃない山道に非常に難儀した。楽しく旅行するのであれば、距離は 60Km 程度で獲得標高も 300m 以内に抑えられたほうが良さそうだ。
そして今回一番肝を冷やしたのは、 養老渓谷の通行止め である。後から知ったのだが、地元の人々も頭を悩ませている状態で、未だに電車も車もまともに通れない。バスで 45 分かけて迂回している状況だそうだ。今回はたまたま Google Maps で調べた抜け道 1 で事なきを得たが、それができなければ完全に詰んでいた。交通の便が良い都会と違い、田舎の道では完全に通行不能で迂回すらできない状況になる可能性があることを改めて実感した。遠方に旅行に行くときは、事前に情報を集める必要がある。
鶴見川源流の泉まで再び行ってきた。
前回 は写真だけだったが、今回は動画である。当たり前ではあるが、動画の方が記憶を辿りやすい。そして、撮ることを意識してみると、今まで素通りしていたところでも、思った以上に綺麗な風景が広がっていることに気がつく。
Insta360 GO 3S は小型なので、スマホなどと違って常に出しておける。スマホと違って、シャッターを押す前にスマホを取り出して準備するという1ステップが必要ない。綺麗な風景を見て撮りたいと思ったときに、すぐに撮れるのが良いところだ。
ヨドバシカメラで買いたいものがあったので、町田まで行ってきた。
尻手黒川道路は木々があって適度なアップダウンもあり、好きな道路だ。ただ、今日はお盆休みに規制する車で混雑していた。
町田から鶴見川経由で帰宅しても良かったのだが、せっかくなので境川を堪能してきた。前に境川を下ったのは 2022 年の 3 月で、まだブロンプトンを買ったばかりのときだった。あの頃と比べると、全てにおいて余裕がある。
帰りも輪行せずに自走した。ちょうど、 先月雨に降られたルート を逆回りで回った形である。せっかく大船に行ったので、栄光坂も登っておいた。
動画は大船近辺で切れている。 Insta360 Go 2 の電池が切れてしまったのだ。アダプタもモバイルバッテリもあったのだが、電圧が合わなくて充電できなかった。 2A ✕ 8V が推奨と書いてあったが、最近は USB-C で直接つなげるものしか持ち合わせていない。
日曜日はいつも、矢上川から鶴見川へ出て鴨池橋まで走って戻って来るお決まりルートを走っている。今日はその模様を動画を撮影した。
写真と文章でまとめるのもいいのだが、動画のほうが圧倒的に情報量が多い。もちろん、その分作るのも大変なのだが、今回アップしたのはご覧の通りお目汚しにしかならないレベルの品質の動画である。このくらいであれば、作成コストはかなり低い。個人がクォリティの高さにこだわる必要はないわけだし、理想のクォリティのものが作れないからと言って何も公開しなければ、それは0ということになる。 better than nothing だ。そもそもインタネットの良いところは、個人が自由に情報を発信できるところだ。 YouTube 上にプロによる高クォリティの動画が溢れているからと言って、特に臆する必要もないだろう。
機材は 3 年前に買った insta360 go2 である。トランジションも音楽も入れていないのは、工数の削減という観点も大きいが、自分の好みによるところが大きい。サイクリング動画に求めるのは環境音を含めた臨場感であって、他人の趣味で選曲された音楽を聞きたいわけではないのである。声を入れているのも好みであるが、なぜ声が入っている方がいいのかは自分でもよくわからない。環境音だけだと、退屈に思ってしまうのは事実だ。音声のある動画のほうが、編集は圧倒的に楽になる。音声以外の部分を捨てて行くだけで、動画は完成する。
「ただ自転車に乗りながら喋るだけの動画」というのは、先人がたくさんいる。
- Two Wheel Cruise - YouTube
- BikeBlogger - YouTube
- Fox Tokyo Riders. - YouTube
- たんすいかぶつ - YouTube
- 北海道ロードバイクLIFE - YouTube
ところで、 insta360 go2 でも割と目標としているものは撮れるのだが、どうせなら新しいカメラも欲しいと思う。 insta360 go2 は小さいところは本当に素晴らしいのだが、連続稼働時間の短さと動画品質の低さが気になる。恐らく間もなく発表されるであろう DJI Osmo Action 5 Pro だと稼働時間も品質も上がるだろう。また、チェストマウントに拘らないのであれば Insta 360 X4 も良い選択肢となる。カメラがどこを向いているか気にする必要がないというのは本当に魅力的だ。実際、今回の動画も前半はカメラが下を向いていてほぼ何も見えないのだが、こういう大失敗がなくなる。ただし、 360 度カメラを使うと、 なななさん のような前方と自撮りを組み合わせた動画になるのだが、腕やハンドルバーが入った視点ではないため臨場感に欠けるし、カメラが遠くなるので音声をどうかにかする必要も出てくる。
後何本かは insta360 go2 で撮ってみて、自分が必要とするカメラのスペックをきちんと考える必要がある。
YouTuber が 100Km を走っている動画を見て、無性に 100Km 走りたくなった。そんなことをしなくとも、先週も 雨の中 100Km 走った ばかりなのだが。
とりあえず、最近行っていない埼玉方面に向かうことにする。適当に検索して スターバックス三鷹武蔵境通り店 を最初の目的地にした。途中で道を間違えたが、ひとまず鶴川街道には到着。ここまでは 20Km で、まだまだ元気である。
ここからは、行ってみたかった多摩湖自転車道へ向かった。長いのはいいのだが、ランナーの往来や道路を横断する場所が多く、運動目当てに走るにはあまり向いてない。木が植えられており、日陰が多いのは良かった。
そのまま多摩湖へ入る。ちょうど橋の西側が多摩湖で、東側が住宅地になっており、なかなか壮観な眺めだ。
その後は交通量の多い所沢入間バイパスを経由して、 スターバックス 狭山市入間川にこにこテラス店 に立ち寄った。 one more チケットがあるのだ。バイパスの交通量には辟易したが、このスタバはサイクルラックもあって良かった。
さて、ここから和光市駅に向かって帰りは輪行したいのだが、 100Km 走るにはまだ 40Km は走る必要がある。入間川に自転車道があるようなので、そこから荒川を経由して行くことにした。川越狭山自転車道である。
この自転車道は人も少なく、走りやすくてとても良かった。近場にあればリピートしたいところであるが、近場にないので人が少ないのであろう。走っていくと、ちょうど 霞ヶ関駅へ行ったとき に通った初雁橋に辿り着いた。今日はここがゴールではないので、素通りして先に進んでいく。
人が少なくて走りやすいのはいいのだが、川沿いを走っていると補給ポイントも見つけられない。しかも、同じ景色が延々と続くので、無心で進んでいくしかない。そして、この猛暑である。チビチビと水分補給をしていたのだが、ついに水筒が空になってしまったので、止むを得ず土手下に見つけた怪しげな自販機で水を大量に買い込む。この土手へと至る道の上は自転車道なのだが、見ているとここから下ってくる車が結構ある。実はこの奥にはゴルフ場があって、そこへ向かっているのだということに、後から気がついた。
その後も人気のない川沿いの道を延々と進んで行く。すれ違ったローディーさんは数人だけで、ほとんど誰もいない。熱中症警戒アラートが出ている中、走っている方がおかしいのだ。実際、 100Km 走って和光市駅に着いた頃にはヘトヘトになってしまった。
水分は補給したが、糖分を一切取らなかったのが良くなかったのだろう。駅のホームで、メロンソーダ、ココア、ぶどうジュースと 1L ほどの糖分を一気飲みしてしまった。消費カロリーを見ると 2,250 Cal だったので、そりゃあ無理もないなと。いつでもコンビニにアクセスできる街中を走ったほうが、やっぱり楽だなあと思うのである。
今日の天気は曇りらしい。まだまだ梅雨空が続く中、貴重な中休みだ。
久々に鎌倉方面に行きたくなった。 CHPT3 を購入してすぐに登った栄光坂 に、もう一度チャレンジしたいのだ。あの時は坂の楽しみ方も知らず、ただ我武者羅に突撃して苦しかった。今度は改めてじっくりと堪能したいのである。
大船までは、いつもと違うルートを使って向かった。と言っても、基本的にはいつも通り Google Map 任せである。 昔はよく行っていた激安スーパー や旧居などを巡った後、 Google Map が示す道から普段は出てこないようなルートを選択した。横浜方面へは第一京浜やその裏の浜通りを使っていくことが多いのだが、今日は帷子川沿いを通って鎌倉街道に出た。その後は鎌倉ハムの工場の横を通り、ただならぬ雰囲気の陸橋を超えていく。
この陸橋の上部は歩道と一車線分の車道しかなく、対向車がある場合は待避所で待たなければならない。知らずに自転車で突入すると、肝を冷やすことになりそうだ。
ここを抜ければ大船駅前で、駅前をバスターミナル方面へ右折すれば、そのまま栄光坂に至る。信号で路線バスだけ先に行かせて、今回はじっくりと坂を堪能した。良い坂であった。
それにしても、照りつける太陽が痛いくらいである。曇りという予報はどうなってしまったのか。予報を信じてアームカバーをして来なかったので、すっかり日焼けしてしまった。
さて、目的は達成したので後は帰るだけだ。帰りはいつものように市道18号を行くことにする。もちろん、海側の道を使ったほうが近いし起伏も少なくて速いのだが、行きと帰りで同じ道を使ってしまうのはつまらない。ちょうどランチの時間だったので、たまたま近くにあった町中華でレバニラを頂く。駅前とは違い、郊外で潰れずに生き残っている店は大体美味い。この店も例外ではなかった。
家に帰るのであれば、ここから中山方面へ向かうことになるのだが、少々時間が早い。せっかくの梅雨の中休みなのだから、夜までしっかりと乗りたいものだ。そのまま町田方面へ向かうことにする。ちょうど、行ったことのない スターバックス町田金森店 という店舗があったので、行ってみた。熱くて喉もカラカラだったので、ベンティサイズのアイスコーヒーを一気に飲み干した。夏は冷たい飲み物が美味くて良い。
ついでに飲み物も補給しようとコンビニに入ったのだが、何を考えたのか炭酸水を買ってしまった。当たり前だが、ボトルに炭酸水を入れて自転車を漕げば、振動で炭酸は全て抜けてしまう。買ってから「しまった!」と思ったのだが、完全に後の祭りである。止むを得ず炭酸水をボトルに入れて走ったが、圧が高まり過ぎて水漏れした上に、フタを開けると「ポン!!」と弾け飛んでしまった。言うまでもないが大変危険なので、絶対にやってはいけない。
この時点で、時間は午後2時前。まだ時間がある。もう少し北上しよう。今度は スターバックス多摩境店 へ向かう。なぜそんなにスタバにばかりと思われるかもしれないが、アイスコーヒーを買うと one more チケットが着いてきて、もう一杯格安で飲めるのだ。正直、そんなに飲みたかったわけでもないのだが、2杯目のコーヒーもぐいと飲み干す。
ここから多摩川経由で帰れば、 100Km 以上の距離となる。どうせ明日も明後日も雨だろうから、天気の良い今日のうちにたくさん乗っておこう。多摩川に向かう途中には、まだ行ったことのない多摩動物公園がある。多摩モノレールに初めて乗ったときから気になっていた施設なのだが、未だに行ったことがない。向かってみることにした。
記憶によれば、動物園は山上にあったはずである。多少の坂道は覚悟して向かったのだが、まさかこんな立派なトンネルまであるとは思ってもみなかった。モノレールもそのままトンネル内に続いており、すごい迫力である。
最高地点はトンネル内にあり、そこから少し下ると多摩動物公園があった。アスレチック施設もあるようで、楽しそうだ。息子を連れてくると喜ぶだろうか。
そのまま下山して府中四谷橋を渡る。 Brompton in Palace に行くときにはいつも通る道だ。・・・と、ここで思い出した。今日は奇数月の第二土曜日なのではないかと。ああ、すっかり忘れていた、 今日は開催日 だった。まあでも、自分は車体にそれほど興味があるわけでもないし、ブロンプトンは乗り回してナンボのものだと思っている。こうしてロングライドができたのだから、かえって良い休日を過ごすことができた。
そんなことを思いながら多摩川を下っていると、ポツポツと雨粒が降ってきた。湿度が高いもんな、曇でも水滴くらいは落ちてくるよな、と呑気に構えていたのだが、そのまま雨は本降りとなった。話が違う。今日は梅雨の中休みだから帰らずにロングライドをしているのだ。雨の中走るのだったら、明日でも明後日でもいつでもできる。
振り返ってみるに、今日は朝からたっぷりと日焼けをして、帰りはザーザー降りの雨で車体ごとずぶ濡れになってしまった。全く曇りではなかったのである。一昨年も去年も痛い目にあってわかっていたことではあるのだが、夏の天気予報は信じてはいけない。