全てのエンジニアに知ってもらいたいOSの中身について
- OSのレイヤーが自分の手から離れると怖い
- OSを知るとちょっと幸せ
- OSを知ってみよう
- ブートシーケンスからOSの動きを紐解く
プロテクトモード
質問１ TSSはどこに保存されるか
- メモリに保存される
- TSSレジスタに記載されているメモリアドレス
- キャッシュのこと？
- マルチコアの場合はL3キャッシュが共通になっている(ここにTSSがある？)
- キャッシュのこと？
質問２ 学び始めるなら何がオススメ？
- Linax1
- 30日でつくる自作OS入門っていう本がオススメ
質問３ システムコール 古くからあるコールとIntelとAMDの新しいコールの方式の違い
- 後ほどツイッターで回答
すべてが gem になる - サービス密結合からの段階的脱却
二つ目三つ目のサービスを開発するときに、数年後後悔しない設計について
サービス密結合って何がダメなんだけ？
- そもそも１つ目の鯖に相乗りしてたのはなんで？
- 手の込んだ機能(認証とか？)を共有できる(既存資産使いたい)
- 障害が起きたらやばい
- どっちのサービスが原因か(両表の知識が必要になっちゃう)
- 巻き添えで両表のサービスが落ちるかも
- モデルが混ざる
- 名前空間ちゃんとしよう(一つ目のサービス開発時に２つ目を考慮しないと・・・)
- DBのテーブル名とかもちゃんと考えないと
- そもそも１つ目の鯖に相乗りしてたのはなんで？
- 関連エンドポイントを全部網羅
- やった事
- routes.rbを全部見る => ネームスペースでわかる
- クライアントのAPIを見る
「何がマザーに依存しているか洗い出す」が目的だったけど、APIをみても依存度合いはわからない(モデルを全部理解していればわかるけど・・・)
ドメイン定義&移行先サーバづくり
- ドメインモデルの把握
- サーバは先に立ててしまう(新機能作るときにとりあえずこっちに書きましょう、を強制できる)
- チーム構成を変えた
変わった事
- 新機能追加を、恐れずにできるようになった
- コアのモデルは一つ目のサーバーAPIを叩く必要がある(ネガティブな事？)
コアモデルを新サーバから触れるように
gemにすれば生産性を下げずに一つ目サーバのモデルを共有できるのでは
まとめ
- 新しいサービスのネームスペースは大事
- 同じテーブルをサービス間で共有するのは良くない
- DBを最初から分ける
- テストはしっかり書く
- サービスがスケールしないと価値を生み出さないとあれなので見極めて
質問１ またがるモデルの障害切り分けをどうしているか
- 更新されるモデルが片方だけであることがわかっていた
- サービスかサイドキックから更新されることもわかってたのでスタックトレースでなんとか
質問２ 最終的にgemを消すときに共有しているテーブルをどうやって消すのか
- テーブルを共有しているが、レコードは共有されていないのでおそらくできる
デザイナーとうまく協働する方法
- デザインはどのくらいの範囲なのか
- 重要というのは誰にとって何が重要なのか
- エンジニア => 早く作って模索する
- デザイナー => 調査に基づいて設計する
- 自分が見ているタイムラインが常識に見えている
- 協業を難しくしている
- エコーチャンバー現象が起こっている事に気付いていない
- 当たり前という先入観
- 察して欲しいという受け身の態度
- 察するというのは、なんの基準なのか
- 人や文化を変えるのがいかに難しいか
- しかし、取り組まなければならない
- 同業者に伝えるのは簡単(別業種では同じようにいかない)
- 我々は良いものを作りたいと願う仲間である。ということは共通している。
- しかし、溝はある。
- 言語化
- 明文化
- デザイン的にはコンテンツモデルという（ドメイン駆動設計に似ている）
- 料理、レシピ、シェフなど、、、
- デザイナー、エンジニア、営業間で翻訳作業が必要になっている
- 料理、レシピ、シェフなど、、、
- コンテンツモデルからユーザー行動を考え、デザインとして形にする
- センスのようなよくわからないもの(暗黙知)で会話する必要はない
- 言葉合わせのためのモデリング
- 情報構造の理解、共有
- ユーザーが使っている言葉だけではなく
- 社内の人間が利用している言葉を観察する？
- 要素名クイズとかを利用して、辞書を作成する
- 開発とデザイン以外の視点も考慮する
- UIや機能の捉え方を共有・学習
- ニュアンスを合わせる
- かっこいい、可愛いとは何か
以下のように（マズロー欲求ピラミッドのようにデザイン的）重要度でピラミッドを作成
- 欠かせない価値観
- 使い続ける価値・意味
業種を超えた言葉の共有
- 言葉のニュアンスを理解する場
- チームにおける「良い」
- 評価
- 課題を解決しているかどうか
- ユーザーに提供する価値は何か
プロジェクトメンバーが（それなりに）納得できる施策
「これはどうですか」は危険信号
- センスとかは偉い人が決めている。はNG
対策
- 課題解決を議論のテーブルに乗せる
- デザインの経緯を記録する
- なぜそうなったのか
- 当時のトレードオフスライダー
- 文書の定型化を心がける
属人性を減らしたデザイン運用
- デザインシステムの第一歩
- まずは色から決める（ブルーとかパープルとか）
- お互いが入り込める隙間作り
- リモート勤務の場合とか
今後の課題
- 蓄積情報整理
- 参照性とか
- 自動化
- 蓄積情報整理
質問１ PMがある程度持っているデザインのビジョンをデザイナに話したときに、それに引きずられてしまうのでは
- 企業としてのビジョン、プロダクトとしてのビジョン、デザインが一貫していることを確認する場を設ける必要がある
- なんでダメなのかを聞く
- そのためのデータをデザイナーが閲覧できる状態にする
質問２ 途中からアサインされる人に伝える方法
- 大事なところ（この資料のココ！）を一枚のペーパーにまとめる
- 価値観の共有はどうすれば？
- デザイン原則。チームにおけるデザインの価値観の言語化
- 我々はなぜここにいるのか
- 価値観の共有はどうすれば？
- 大事なところ（この資料のココ！）を一枚のペーパーにまとめる
Webアプリケーションエンジニアが知るべきDNSの基本
- ipの解決問い合わせ順序
- ツリー構造
- ルート権威サーバは配下のjp権威サーバを知っている
- ゾーン
- リソースレコード
- 権威サーバのDBで管理
- リソースレコード
- ICANNがIPの元締め
ネガティブキャッシュ
- 名前解決ができなかった情報をキャッシュしておく
- このキャッシュが存在する場合は問い合わせをしなくなる
- 名前解決ができなかった情報をキャッシュしておく
もともとフルリゾルバのTTLが長い場合（４８時間とか）短くして、権威サーバのTTLを短くしても新IPが見れるようになるまで最大で４８時間かかってしまう
質問２ 適切なキャッシュ時間は？
- 最近は性能が高いので300秒とか
- 切り替え時は60秒ぐらい
質問３ ~allを使う局面はどういう
- 公式で非推奨
- -allのミスである可能性が高い
質問４ 複数のDNSの問い合わせ順番はあるのか
- お名前.comの実装によるはず
なぜ私はキーボードを作るのか
質問１ 自作キーボードは配列が格子型担っているが、使いやすいのか
- すぐ慣れる。macユーザーは多分すぐ慣れる。
質問２ タイピング速度とかはどう
- 計測してない。健康になったので生産性は上がったと思う
- ゲーミングに関しては自作だとズルできるのでよくないと思う
質問３ キー配列を好きにできるか
- すぐにできる。業務中に書き換えるのも可能。
質問４ 静電容量はできるのか
- できないのでは。銀軸が近いかも。hhkbを書き換えるのもいいのでは。
質問５ エルゴダッシュがいい理由
- 指の場所が斜めになっている？
- アイリスとかが似ているかも
質問６ コンスルーがプロマイクロ対策になる？
- ピンの形状が違う？ことによって抜き差しが可能になる
質問７ キーボードの剛性が必要？
- キースイッチの半田付けとかは自分次第
- 部品の品質にもよる
質問８ どこに何を割り当てたかわからなくならない？
- キーキャップの刻印
- 無刻印にマスキングテープ
- やってれば覚える
質問９ 無線のセパレートはできるのか
- 最近作った人が現れ始めた。界隈を監視すべし。
質問１０ 自作キーボード作る人は３つ４つ持ってるのはなぜ？
- 好きだから
- カスタマイズを続けている
LT
キーボードをカスタムしプログラミング環境を良くした話
- Elixir
- パイプ演算子 |> 直前の結果を次に代入
- しかし打ちにくい
- QMKを利用して解決する
- ファームウけあを書き込めるキーボードが必要
- QMKにマクロ機能がある => 一回のキープレスでたくさん打てる
- しかし打ちにくい
スーパーファミコン事始め
- コンパイラかげんごを自作する(to be continie)
Merpay
- マイクロサービス
- 各DBへのアクセスがメッシュになっちゃう
- 中間層を準備する
- バッチとストリームの二種
- schema registory
WebReplay
- コードの時効履歴を保持して巻き戻しをする（ブラウザでする）
- firefoxで実験的な機能 まだ重すぎて使い物にならない
- なんのためにある
- クライアントサイドのバグの再現
- 記録保存転送再生を想定している機能
今後の見通し
- ほっとくと落ちる
- mac以外でも動くように
- 現状はまだ期待できない
web開発の未来
- Live-edit(コードを書き換えると即時反映)
- あの頃を巻きもどせるのでは！！
- Live-edit(コードを書き換えると即時反映)
チームでテストを書くために
- チームでユニットテストを書くようになるまでに取り組んだこと
失敗
- ヘルパー関数がバグってた
- テストコード自体の品質
とにかく描いてみましょう
- 簡単なところ描いてみよう
- 小さく描いてみよう
cpanfileがrubyでパースできることに気づいた俺たちは
- cpanモジュールの一覧
プロジェクトマネジメントに足を突っ込んだ結果
- PMの問題を知ってれば開発上の問題点を開発できる？
- 問題のほとんど社会的な問題
- PMBOK読もう
5分でフォトブース
- 撮影
- 画像加工
- Grabcut
- アップロード
エディタ
Enxt Editor - 誰でもギット - 一般的な仕事もプルリク
アップデートばかりしている言い訳をさせてくれ
登壇やLTを始めてみたい方の背中を押してみたい
- 批判されたら
- 微妙だったら
無視されたら
未経験者の背中を押してあげよう
- まさかりはほどほどに
- アウトプットすることの学び
- 初心者枠もあるよ
- 背中を押されろ
本物のインターネットを提供した話
NodeでCloudFormationのテンプレート分割
- S3にあらかじめ置ける
インターネット障害を支配したい話
感想
buildersconの２日目。本日は夜まで会場にいたのでたくさんのセッションを聞く事が出来ました。
※公開された資料をまとめてくださった方がいるようです=> 資料まとめ
全てのエンジニアに知ってもらいたいOSの中身について
- 自分はコンピューターを使って仕事をしているにもかかわらず、話についていくのがやっとだった。
- 基本情報技術者試験とかでちょっとだけ勉強したようなコンピューターそのものの仕組みの発展形のことはじめ感。
- 今回の内容は本当に入り口部分なのだと感じる。奥が深く、複雑。
すべてが gem になる - サービス密結合からの段階的脱却
デザイナーとうまく協働する方法
- エンジニアとデザイナー、IT業界と他業界という違う価値観を持つ人同士が協働する場合、違う価値観を持っているという前提を全員で理解し、認識合わせをし続ける事が大切。
- ↑である事実も全員で理解し、歩み寄るための心理的安全性があるチームを構築する必要もある。
Webアプリケーションエンジニアが知るべきDNSの基本
なぜ私はキーボードを作るのか
全体を通して buildersconというイベント全体で「楽しい」という感情が大前提として参加者に共有されている事が感じられます。他のイベントと比べるわけではありませんが、比較的質問が出る際の謎のプレッシャーが薄くて、いい意味でゆるくオープンな空気だと思います。来年もまた参加したいです。
