Pixel Pedals of Tomakomai

北海道苫小牧市出身の初老の日常

今日は YAPC::Hakodate 2024 の日でした

昨日から 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 で話したこと
    • 複雑な文字列操作、正規表現が必要なら Perl
    • shell は 100 行以内
  • コメントは必ず書く
  • shell を 15 分で諦めた例(色々間違いをする)
  • ls pwd cd make fg ...
    • ベスト 50 に Perl はない
    • 自作 Perl は 3 つだけ
    • make からは呼んでる
  • パイプ(メソッドチェーンと同じもの)
  • 同じ時期に同じことを提唱する人はいる(歴史上に残るのは一人)
  • パイプはどこか来たのか
    • 仮説1. 実用性から? co-routine
      • unix 回ハッツチームが | の記法を作った
  • Unix の特徴
  • Unix の立ち位置
    • 軍用の予算よりは桁ハズレに少ない予算
    • 民間企業
  • 過去を振り返っって一般化すると、未来の傾向が読める
    • 個別の予測は難しい
  • Unix 史の振り返り
    • お金が微妙、実用性
    • コンピュータが高かった→効率化
    • 科学技術者の狂気
  • コンピュータは高価
    • 1963 IBM 7094 32億
    • 1970 DEC PDP-11 3020万
    • 1974 altair 8800 31 万
    • なんとかお金をもらわないと研究できない
  • 助成金はどこに行くのか
    • 最初は空軍
    • タイムシェアリング、コンピュータグラフィックス、人工知能
  • コンピュータはどのくらい速くなったのか
  • 今の PC は半世紀前より数100倍速く、4桁くらい安い
  • 1950 ~ 1970 年代の改善は冷戦のおかげ
  • Vannevar Bush
    • Bush 式アナログコンピュータ 東京理科大にあるらしい(野田キャンパス)
    • マンハッタン計画 6000 人のエリート
    • 「量はとほうもない質に変わる」
    • As You May Think : 戦時研究を終えられるというエッセイだが、Memex が取り沙汰された
  • 20世紀最大の発明は?→コンテナ(システム)
  • コピーコスト 0 円が大事
    • パッケージビジネス、半導体
    • 少数精鋭なら食べていける
  • プログラミングはアートか?
    • 狂気が必要
    • 陶芸のほうが近い(実用性が必要)
  • 幸せな環境→低価格、インタネット
  • 実用上の理由、必要性
  • 低コストで作れるものは、ある日突然変化する
  • 修行中のプログラマーは、 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
  • どう実装されているのか
    • 「時間」
    • 一回図るのだけでいい??
    • Time.now はモノトニックではない
    • GC GBL も含む
    • あらゆるとこに仕込むのか
  • 時間は色々ある : REALTIME, MONOTONIC, CPUTIME
  • プロファイラ / 一定時間ごとに、何をしているか
    • カーネルタイマー(OS)にお願い
    • シグナルハンドラ
  • メモリの計測
    • VM でやるか、 malloc() に仕込むか
    • 計測には下のレイヤへの仕込みが可能
  • メモリレイテンシ / CPU のパフォーマンスカウンタ
  • 下のレイヤが教えてくれることはすごく多い /proc/sys/kernel
  • 計測はレイヤーをまたぐ芸術
    • 「美しいと思いませんか」
  • 結果をどう評価するか
    • いつ計測するか、とセット
    • 問題があったり isucon なら簡単だが
    • プロファイラはそれを教えてくれない
  • 「なんか遅い」を主観で判断するのはブレる
    • パフォーマンス指標が必要 (isucon ではスコアを挙げて 100 万円)
    • ワークロードの性質、 CPU 利用率
  • メトリクスとしきい値
    • メトリクスは計測
    • 常に計測する
  • プロファイラは「常に」ではないが
    • Continuous Profiling

プロファイル作者の苦悩 (LT)

  • 正しい計測ツールを図るのは難しい
  • top で 100% ?本当に正しいのか
  • プロファイラがパフォーマンスを歪める
    • 処理が増えるため
    • 観察者高価
  • プロファイラ導入したときのパフォーマンス低下を計測
    • 仮説検定まで
    • プログラムが 1% 以上遅くならないようにする
  • パフォーマンスツールは単一目的だがプロファイラは違う
    • 何が求められているか不明
    • 色んな知識がない人が遅い部分を知れる
      • Unknown Unknown を作らない
    • デフォルトを決めるのは大変
  • Ruby プロファイラは Ruby では作れない
  • 計測ツールが正しいかを調べるのは困難
    • 他のツールと比較・・・苦痛
  • 「早すぎる最適化は諸悪の根源」→早いのはいいことでは
    1. profiler の出力のおすすめの見方は?
      1. frame graph 。その後に見る部分はシステム特性に応じて決めておくと良い
    1. 表示はどう決めている?自分で決める?
      1. 自分で決める部分は大きい、フィードバックほしい
      1. 他のプロファイラを参考にする。 firefox とか
    1. 多くの視点を得るにはどうする?
      1. 詳解システム・パフォーマンスを読む
      1. 本を通して浅く広い知識を得るのは良い。関係があるというとっかかりを得る

普通の Web エンジニアのための様相論理入門 / チェシャ猫 さん

  • 時相論理 CTL 非同期システムのテスト
  • 例: いいねするとゲージが上がる
    • レースコンディションでうまくいかない(後勝ち)
    • 大体の場合はうまくいく
  • 非同期性は非決定性
    • 動作の奇跡(グラフ)を網羅的に考慮
  • 様相論理 Modal Logic
    • グラフ構造上で意味論が展開(キャッチフレーズ的)
  • 様相論理の種類
    • K 論理
    • Geach 論理 / グラフへの制約
    • 時相論理 / 演算子を追加
    • 様相μ計算 / 演算子を追加
  • 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 の状態数が有限かであることは重要
  • 濾過法
    • 同値関係を定義
    • 商集合で新しい状態を得る
  • コンピュータサイエンスにおける様相論理、数学における証明と心理、モデル検査機をつくる
    1. ループに入れる PATH が複数あるとどうなる?
      1. exists がわかればいいので O.K.
    1. 濾過法のΦは?
      1. 検査したい論理式Φについて有限モデルを作るもの
    1. WEB サービスでどのように使えるのか
      1. 最上流。プロトコルなどの設計部分

未来は現在からの継続 / 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 、継続モナド、代数的高価
    1. 業務で使うことは?
      1. 使おうとしたが使わなかった
    1. 継続渡しにどこで興味を持ったのか
      1. 関数型の本で知った
    1. CPS にするとテストをしにくくなる?
      1. 継続をモックする?どこまでできるのか。純粋関数を使えばモックしやすいのでは。多分やりにくい

けしからんライフログ研究 / 角 康之 さん

  • 「公共の場でカメラを身につけるのはけしからん」
  • 体験強調キャプチャ 2002 年
    • 1 人称の映像の共有
  • 顔数系
  • 映像閲覧者のリアクションの理解と推薦への応用 2011年
  • 非言語行動に注目したチュータリング会話の質評価
    • チュータリングのインタラクションを動画、音声
    • Slack へのアップロードして分析
    • 「インターネットへの個人情報の共有は論外」
  • PhotoChat 2005年
    • 写真への落書きによるチャットシステム
    • 「高速文字入力できるのだから手書きは不要」
  • 環境音の近さによる会話場検出
    • 音声のフーリエ変換で距離を調べる
    • 「そんな方法でうまくいくわけがない。なめるな」→うまくいった
  • tabimemo: 屋外での体験共有システム
    • 「女子大生の卒業研究みたいだ」
  • 凸凹スケッチ 2014年
    • 深度センサーで距離を取っている
    • 「スケッチの意義がまったくわかっとらん」
  • 図書室での陣取り合戦ゲーム
    • 人気のない棚に学生が集まる仕組み
    • 本を借りる人の数が増えた
    • 「滞在時間で手数付けするのはナンセンス」
  • 社内会話による街の「いま」の可聴化 2012 年
    • 社内会話が盛り上がっているところは賑わっているところ
    • 「車の中の会話なんてノイズだらけで価値がない」
    • WWW も同じことを言われていた
  • Taxi Dash
    • ボタンを押すとあいのり相手を見つけてくれる
    • 「知らない人と相乗りを斡旋するなんて」
  • ライフログ研究は人間科学
    • 体験していない人には価値がわからない
    • 10分程度のプロポーザルでは伝わらない
    • プライバシー / 撮ってるほうが安心ではないか
  • 「けしからん」と言われたほうが脈あり
    • 学生は落ち込んでしまう
    • 深い思考を促す。どうやって言い返すか、言語化
    1. 学生さんに「けしからん」と言われることを伝えていますか
      1. 「ここではなるべく役に立たないものを」と促す

off by one - 10年ぶりに CPAN Module を Update した理由 / dankogai さん

  • 一個ズレた話 浮動小数と整数
  • JSON の数値が復元できない
  • log(2) の値を perl で表示して復元しても同じにならない
    • node.js では復元できる
    • 長く議論したが、そのまま行くことになった
    • Rakudo は治った
  • ワークアラウンド
    • sprintf の %.17g
    • C99 Hexadecimal Floating Point を利用
  • 1997 年に書いたモジュール
  • 例: stat
    • 5.30 では負の値が出力される
    • 64bit 目が 1 になるデバイス番号を使っていなかったが、 FreeBSD が使うようになってしまった
  • JSON5
    • JSON の拡張
    • Hexadecimal に対応している
    1. JSON::PP や JSON::XS もバグっていますか
      1. はい、駄目です

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 アドレスを排除した一番端
  • インジェクション
    • SQL インジェクション、 OS コマンドインジェクション、 Server Side Template Injection
    • 適切なエスケープが必要
  • order by はエスケープされていないことがある
  • user data を受け取るときはすべてバリデーションする
  • パストラバーサル
  • パスの正規化に注意
  • S3 は . と .. はそのものとして扱われるが、アプリケーションが解釈してしまうことがある
  • nginx で config を書くときに / で終わらないと /img.. のような指定が効いてしまう
  • Q). Chrome の仕様が挙動とかどう付き合う
    • A). 挙動を動かしながら調べる。泥臭い

北海道のエンジニアコミュニティ座談会

  • mitani さん、 nagatani さん、 sugai さん、ジャンボさん、chikuwaさん
  • 2013 年から OSC で勉強会のアンケートを取っている
  • Hokkaido.pm 2010 年
    • lestrrat さんの助けで手伝い
    • Perl 入学式、 YAPC::Hokkaido
    • akiym さんは高1で来たが当時からすごかった
    • 高齢化が問題
  • 函館本線沿線勉強会
    • 函館本線の不思議な駅で勉強会があるのでは
  • はこだてIKA
    • みらい大にはもともと興味があった
    • ハッカソンから Code for 道南(Hakodateへ)
    • 昔からある
  • OSC北海道
    • 東京以外で初めて開催した
    • local 任意団体から法人会
    • 部活がある → 安全部、学生部
  • 学生部
    • IT勉強会カレンダーで東京が羨ましかった
    • はてなダイアリで書いたものから local 入り
    • 大人と学生は興味が一致しない
    • 室蘭と北見の学生が集まった → 学生部
    • 北海道の色んな大学で遠くて集まれないが、学生部で集まる
  • コミュニティの変化
    • jp.wordpress.org
    • 全員世代交代できた
    • Hokkaido.pm は 3 名体制で、世代交代していない
    • 終活もありうる
    • JPA はうまい。 local でも課題
    • 函館 IKA は若手がうまく来てくれた
    • 「みんな一旦脱北する」
  • 障壁
    • 距離と天候
    • 東京では勉強会の距離が近い
  • 就職
    • リモートワークで済むようになった
    • 脱北の必要がないのでは
    • コロナ後からフルリモートがまた終わりつつある
  • 魅力
    • やれそうなことが多い
    • 年ごとに情報系の大学がある
    • アルバイトがない→仕事がなさそう→脱北
  • インスタントのコミュニティを作って集まれればいい
    • マイクロコミュニティがいくつかあればいい
    • 無理にやる必要はない。やれるときにやる
    • すごい人がいるか / 活動力があったり、 OSS のコミッタだったり
  • 運営が居ることを知らないと運営が必要なことが伝わらない
    • Rubykaigi は代替わりのため一回やめた
  • イカを一人で3バイ食べる
    • 明日はイカまつりです
  • 北海道に興味のあるエンジニアへ
    • 移住して欲しい。市によっては補助金がある
    • 嫌だったら戻ればいい
    • るびま「コミュニティとはあなたです」作ればいい
    • クレイジーなことをしたければぜひ
    • 札幌は最近元気な人が多い
    • ゆるい◯◯勉強会が多い
  • 今回は色んなバラバラな人を集めたので色んな話を聞けたのでは

code to survive

  • dan the question 歓迎
  • コードを書くだけでは成立しない
  • コードを書かないと成立しない
  • 小学4年生、未来大学
    • 男の子がミサイルで犬を撃つ
  • 機械工学科に入ってエンジンをやるつもりだったが、幼馴染が「これからはパソコン」と言っていた
  • 電子回路、ハードウェア、ソフトウェア、ネットワークを体系的人学んだ
    • 今はない学部
    • 当時は Pascal でゲーム
    • 犬を棒のようなもので叩くと遠くへ飛ぶ
  • Twitter client を Swing で
  • シングルスレッドのサンプラー
    • 音がなると機能がすべて止まる
  • 首都大学東京編入
    • お金のためのバイト
    • 地上波デジタル放送をスタジオ間転送
  • 2011 年「ここからの時代は Perl
    • なぜか不明
    • SNMP MIB を Perl で書いて仕事で使っていた
  • Hachioji.pm
    • 主催者は PHP
    • Perl で自作していたチャットツール
    • yancha → Twiggy + jQuery
  • 自己表現としてライブラリを公開し始めた
    • github
    • 英語だから SPAM サイトと思っていた
  • はてなインターン 2013
    • 2 週間の座学 (Perl も )
    • 2 週間の実務
    • AtomPub API
  • LINE でのバイト~就職
    • 長年動く巨大 web app
    • 業務で役に立つライブラリ、ミドルウェア重要性
    • 便利であれば小粒でも
  • Perl::Lint
    • Sponsored Project
    • $800 にしてしまった / 1,000 時間程度使った
    • 換金してしまった
  • YAPC::EU (Granada)
    • lestrrat さんの助け
    • After Party で声をかけてもらった
    • 海外への興味
  • tokuhirom さん「webサービスのおもしろさはトラフィックの量に比例する」
  • ソラコム
    • スタートアップで一発当てたかった
    • 入社日に KDDI に買収されて終わった
    • WEB技術+セルラー技術
    • とにかく全部やる「低レベルネットワーク、コアネットワーク開発」
    • RFC は読みやすい
    • 3GPP ITUT などの仕様はやばい( 3GB の doc ファイル)
    • 3G sunset
  • Soracom Global, Inc.
    • コロナ真っ盛りでの移住 → カオス
    • 開発と現地のカスタマーサポート
  • 上場後 (某社を経て) SmartBank
  • ソフトウェアプロダクトはチームワーク
    • チームへのフレームワークに商店が当たりがち
    • チームを構成しているのは個人
    • 個人技による貢献。個人技を磨くとプロダクトは良くなる
    • 個人技が集まることによるチームワーク(それができなくてもなんとかするのがソフトウェア工学
  • 興味ドリブンで個人技を磨く
    • 技術、ドメインの資料は読めば読むほど身につく
    • 読みきらなくても良い
    • キャリアが浅い頃に読んだ本→ code complete
  • とにかく大量に作る
    • 量が質に転嫁する
    • 作ったら外に出す→勝手に添削
  • 仕事で再発明するには理由が必要。趣味であればいい
    • 再発明によって先人から知見を得る
  • 必要になりそうなパターンを先んじて全部作る
    • 不要なものは捨てるといい
    • 確認を待つと律速する
  • 高速に物を作れるとそれだけでメリット
    • 質と量が動悸する
    • Shut the fuck up and write some code
  • 個人技の向上は再現する?
    • 教育。結果を図るのは難しい
  • コンフォートゾーンから出続ける生存戦略
    • 「自分が一番下手」というマインド
    • 故郷があると、価値基準になる
    • Perl/YAPC/ 函館
  • とにかく手を動かす人が一番カッコイイ!
    1. 将来について考えていることがあれば教えて下さい
      1. マネージメントはフロンティア
    1. ロールモデルは?
      1. tokuhirom さん。ド直球のハッカーだけど PM もできる
    1. 「パソコンの時代」「Perlの時代」次は?
      1. (当てに行っていいですか?) LLM 来ると思う。チャットはまだギコチナイ体験。ドメインに当てはめていきたい
      1. 間違えました、個人技が来ます
    1. 5 年後にどうなってそうですか
      1. コードは書き続けていたい。汎化した形でスキルを移譲できるといい
    1. 本を出す?
      1. 10 年以上かかる
    1. 量をこなすのに「立ち止まってしまう」ことがあるが、どう乗り越える
      1. はてブ狙い、バズ狙い、ガソリンにしていた。今は違う
      1. コミュニティ。互いに話しながら一緒にやってくれる人

クロージング

  • ベストスピーカー賞
    • 副賞は北海道ギフトカタログ
    • osyoyu さん 「とりあえず読めのために 940 ページの本。発送済なので出せないが」
  • ベスト LT 賞
    • スポンサー : トグルホールディングス株式会社さま
    • Bose Quietconmfort Headphones
    • うーたんさん「Kyoto からつながって良かった」
  • 樽募金
    • Kyoto から続いている
    • 23,200 円
    • もう締めました
  • Thanks
    • はこだて未来大学さま
    • スタッフのみなさま
    • スピーカーのみなさま(今回は厳選させていただきました)
    • スポンサーのみなさま
    • 参加者のみなさま
  • 帰りのバスまであと 8 分
  • 次回は福岡!・・・かもね