今日は、YAPC::Asia 2014に足を運んでいます。この記事は、会場で書いている所です。
百花繚乱、YAPC::Asiaの懐の深さを感じられる、多岐にわたった分野のトークを聞く事ができました。明日もめっちゃ楽しみです！
そうそう、2日目である明日は、僕も朝 10:30から「突然ITインフラを任された人のための…監視設計入門」と題して登壇します。ぜひ、遊びにきて下さい！！！
それでは、今回もノートをアップしておきます。
Perl meets Real World 〜ハードウェアと恋に落ちるPerlの使い方〜
- @mackee_w さん
- カヤックに勤めている。Goはあまり書いてない。周りは書いてる。
- カヤックの面接のステップをパスできる権利、渡します！
- 感想
- 電子工作、目に見えて結果が出てくるので楽しそうだ。
- 秋葉で抵抗1個を買って組み立てるより断然始めやすいことがわかった。
- PWM制御、ラズパイでやるとCPU食うの初めて知った。
- なぜWebアプリエンジニアがハードウェア？
- 去年少しだけやった。
- 調べたら最近のハードは凄いことがわかってきた
- 技術
- ラズパイ
- Arduino
- OpenCV
- Ansible (ラズパイに適用)
- 全て秋葉やWeb等で普通に買える
- ソフトウェアは全てにWebに通づる技術
-
楽しかったので、一部紹介します！
- 話さない事
- ハンダ付け
- 回路設計
- ガチのArduion
- ガチの電子工作
- Raspberry pi
- Webに近い(Arduinoに比べて)
- Perlも動く！
- ラズパイの特徴を説明
- PidoraはIPアドレスをしゃべる機能があるらしい！
- kano というオールインワンパッケージがある。
- Raspberry Pi GPIO
- 電気を見聞きし、しゃべる。
- モーター: 四肢
- センサー: 五感
- 最も低いレイヤーを手軽に扱えるのがラズパイの良さ！
- Arduion
- 電気を扱う事に特化している
- USBは入力専用
- で、Perlは…動かない。
- Arduino IDE
- シールド – 親亀・子亀方式で拡張するアタッチメント。複数重ねられる。
- ライブラリやArduinoを前提としたキットも販売されている
- mackee_wさんの使い分け方
- Raspi
- 画像処理やエンコード等の重たい処理
- 複雑なアルゴリズム (PC向けライブラリが動きやすい)
- 簡単な電源On/Off (PWM制御できるらしいがCPUを食う)
- Arduino
- よりハードウェアを積極的に制御するとき
- PWM制御もRasPiよりやりやすい
- Raspi
- オープンソースハードウェア
- ファーム
- 回路図 (Raspiも)
- 基盤配置図 (Eagle形式)
- など…
- Aruduino UNOは配られている
- Arduino自体を自作できる！
- 実際クローンがいろいろある。クローンは安い。
- ハックを促す
- エコシステムができやすい
- ただし名前等は保護している
- Arduino自作のメリット
- 機能追加
- フットプリントを減らす
- Arduinoのエコシステムの恩恵を受けられる
- デモ: ネギを振ってみる
- 縛り: Arduino言語で書かない、Perlで書く！
- GROVE System
- キット
- ライブラリも完備
- Firmata
- MIDIベースのハードウェア制御プロトコル
- Arduion + Raspberry Pi
- LEDをピカピカ光らせられる
- サーボモーター
- Redisもステータス管理で使ってる
- Raspi Camで見せますよ
- 実機はイベントホールで見せます！
- まとめ
- ハードウェアは自分で作れる時代だ
- 事例: IRKit
- たりないこと
- エンジニアリングの仕組み化
- 勉強会等
- テスト環境
- ハードウェアは自分で作れる時代だ
- 質疑
- Q: ラズパイでPWM制御をすると実際どんな弊害が出る？
- A: CPUを食いまくって他の処理ができなくなる
完成されたシステムなどない。完成された人間もいない。あるのは成長し続ける未完成なシステムと、それを支える未完成な人間だけだ
- @kenjiskywalker さん
- 子供できた！
- 感想
- けんじおじさんの独断と偏見をもっと聞きたかった。
- Webサービスの誕生
- 必要な事 2つ: 同じ環境を作り直す・保険(リスクヘッジ)
- どうして必要: 人間は失敗する、ハードは壊れる。
- 成長期
- お客さんは増える→ロード高まる、パフォーマンスが落ちる。
- 機能分け
- 繰り返し: いつでもどこでも、同じものが作れるようにしとくと、スケールアウトもスムーズ。
- 簡易性: 依存性も持たせないように
- 機能追加
- バッチ、キャッシュ、キュー…
- 時は流れて…
- 障害、失敗、あったけれども…
- 記録・保険・再現性・簡易性→どうにかここまでやってきた
- 精度の問題
- 判断が難しい
- 完全にケースバイケース: 時間・コスト・リスク…資源の問題
- どうにか継続する事ができた
- 旅ももうすぐ終わる
- 絶対壊れないものはない
- The Unix Phirosophy
- 式年遷宮
- 予想できる変化・予想できない変化→その変化に対応する
- Infrastructure as a Code
JSON SchemaとAPIテスト
- @deme0607
- DeNA新卒入社 2年目
- Software engineer in test
- randexp-multibyte
- 感想
- スキーマ定義をつくるの、DBだけでなくJSONでもちゃんとやった方がテストが楽なのを改めて認識した。
- 自動生成するツールを作られて公開されているの、素晴らしいと思った。
- API結合テスト
- 投げて受け取るだけでいいの？
- 経路に、いろんなもの…LB, Rev. Proxyなどなど。実際はDBもある。
- これだと単体テストでは品質を担保できない。
- 実施フロー
- 正常・異常系リスエストデータ(近似 テストケース)を作る。
- 仕様とリスクエストデータから、期待するレスポンスを定義。
- JSONスキーマ
- 変数名・構造・型を定義
- データ検証に活用できる: Validataをかける
- 使用自然言語を問わず伝えられる
- 仕様と実装の乖離が抑えられる
- Web::DB Press No.82 にも書いた
- JSON Schemaをテストに活用
- 上記がそろえば自動テスト…できない…けど、楽はできる！
- 正常・異常系リクエストデータはJSON Schemaをもとに自動生成できる。
- ドメイン知識(業務仕様)に基づくケースは自動生成できない
- APIクライアントの自動生成: jsonism
- まとめ
- JSON Schema重要！
- 質問した
- Q: JSON Schemaを作るフローがあるのか？
- A: テストのために作ってはいない。もともと、作る仕組みができていた。
DBIx::Class – what is it and what is it good for?
- @Ribasushi さん
- 寿司関係ない！
- 感想
- DBを叩くプログラムの書き方がどんどん抽象化して行く流れをかいま見た。
- ITインフラをやっている立場として、問題があった時の追いかけ方を追求しておく必要があると感じた。
- DBIx::Class
- Class:DBI, Class::DBI:Sweet から影響を受けた
- 色々誤解を招いている気がする、との本人の弁。
- 上位レイヤーの話をして行きます。
- 使われている所
- あまり公開できない
- BBC iPlayer
- モルガンスタンレー
- PHPで作り直さないと行けないところを…DBIxならできる！
- (あれ、これよくわからんかった。)
- DBIx::Classとは何か
- DBI Extension
- O/R Mapper
- Frameworkでもある
- レイヤーを部分的に自分で書き換える事ができる
- レイヤー
- データソース・リレーションシップ
- クエリ定義
- データ取得
- ストレージI/O抽象化
- バックワード
- 後方互換性
- 自分でいじったりしなければ問題ないはず
- 最適化すると10倍くらいパフォーマンスが出る
- ライブラリを入れ替える
- 安全な所からパフォーマンスを引き出して行く
- 今後3〜4倍早くできるはず
- 後方互換性
- (実際の使い方の解説)
- O/Rマッパ使ってれば使えそう
- 複数のResultSourcesをバインドできる
- NOT NULL制約もあまり意識しなくて書けるっぽい
- サブクエリのラッピングもできる
- Relation Metadata Travasal
- このやり方が良いと思っている、とのこと。
- Arbitrary(プログラムが適当に解釈して、という感じ？)に圧縮されて解釈さる
- ResultSet操作、1行ずつ、ガバッと、両方行けるっぽい。内部のクエリ実行も、必要になる時まで遅延させる事もできるらしい。
- パフォーマンスを悪化させるクエリが見つかりづらい可能性、ありそう。
- 内部で逐次余計な事をしていないので高速化しているらしい。(質問あったけどまとめて聞き直さないと。)
- DBDのバージョンアップは大変
- 本番機でリコンパイルはつらみある
- DBIcは再接続、再実行できる。txn_doを使うと更によい。
めし
songumuさんのライブコーディング
- 色々大変そうだけどエキサイティング感高かった！
- 無限コーヒー最高
DeNAが歩んだデプロイ自動化への道
- @aoneko さん
- モバゲープラットフォーム担当
- 感想
- 地味に、しかし確実にやっていく必要がある事を、心折れずにがんばっている人がいてとても勇気づけられた。
- 今後の経過も聞いてみたいと思った。
- なぜデプロイ自動化か
- 「安全工学」の範疇
- 早く安全に届ける事が重要: スピード・品質・コストのトレードオフ
- Noの状態: 赤ペン先生とマークシートの比較→自動化
- 全ては出荷プロセス: 問題が早く見つかればそれだけ良い
- リリースに困難さを感じるかどうかがシステムの安全性の指標の一つとなる
- リリースプロセスの自動化→システムの自浄作用が働く
- Mobageアーキテクチャについて
- 事業フェーズの話
- 一人で開発運用→急成長→肥大化→キャー
- あらゆる機能がContainerに詰め込まれていた
- 中身、よくわからん
- 開発・本番で動きが違う
- リリース手順が煩雑
- めっちゃ足かせあった
- 如何にしてレガシーから脱却するか
- 「適切なサイズとは、それだけで優れた事である。」: SOA
- コンテナを小さなサービス単位に切り出していく
- 新しいコンポーネント: しがらみが少ない→だからそこから自動化を始める
- 自動化の条件を満たしているかを確認
- 事業フェーズの話
- デプロイ自動化の実例
- ビルドパイプライン(by Jenkins)
- 前Jobが成功したら、次のJobを実行する、というフローを組める。
- (パイプラインのためのプログラム書かなくて良さそうだ)
- Hubot連携とかもやりやすそう
- GitHub Flowに近いブランチ運用をやってるっぽい
- ビルドパイプラインの構築を1発スクリプトで組めるようにした
- ビルドパイプライン(by Jenkins)
- 所感
- 明らかに開発が楽になった
- 情報共有も楽になった
- 心理的障壁も軽減
- デザイナさんだけでもリリースプロセスを踏めるようになった
- 課題
- 現実との差異
- 網羅
- 依存
- 間引き
- 並列化・高速化
- 現実との差異
- 質問した
- Q: テストの速度が上がらないとあったが、どの辺りが問題？Jenkinsを並列化すればよくね？
- A: 並列化で解決できる部分もある。ただ、結合試験はそうも行かないので、課題と考えている。
- コメ: 確かに結合試験は並列化しづらいものがありそう。またお話聞かせて下さい。
O2O/IoT/Wearable時代におけるWeb以外のネットワーク技術入門
- 感想
- IoT案件、増えそう。
- 開発案件としては今後ホットになるのだろうなと思った。
- レイテンシが重要、そしてショートパケットが飛び交うネットワークがより増えて行く気がして震えた。
- MQTTとは
- PubSub
- 省エネ
- QoS, Will
- ワイルドカードSubscription可能
- シンプル
- EventHub サーベイ
- Plagger
- IFTTT
- Yahoo! Pipes
- Belugaが裏で使ってた
- グループチャットと相性が良い
- M2Mに限られるわけではない
- 省エネ
- M2M…電池、特にボタン電池は非常に重要。
- バイナリフォーマットのパケット・手続きの簡略化
- BTLE, HTTP2.0, SPDY等のプロトコルのトレンド
- (HTTP2.0は何方かと言えば高速化)
- QoS
- 0,1,2のレベル
- ネットワークは不安定になる、という前提を置く。
- 重複の許容、どの程度保証するか、など。
- QoS 0
- 投げっぱなし
- QoS 1
- メッセージを保存してPublish
- Ackを返して届いたらメッセージを消す だめならリトライ
- 確実に届くけど重複する可能性がある
- QoS 2
- ID付きで1回だけ必ず届くように保証する
- Will
- セマンティックなLeave Message
- Timeout, Pingを組み合わせて切断検知もできる
- MQTT-SN
- Sensor Network
- ゲートウェイをまとめあげる
- HTTPに比べて？
- 省エネ？本当？
- 比較対象おかしくね？
- Redisとかと比較したらいいんじゃね？
- M2M界隈の議論…商業施設・センサーネットワークどうする？で、出てきた会社の属性に引っ張られてきたっぽい。
- CoAP: HTTPベースのマシンネットワーク最適化プロトコル
- まあ、こう考えるとMQTTと性質が違うのはわかるよね。
- CoAP/CoAE
- LAN外とリアルタイム通信するには工夫が必要
- Bonjour (DNS-SD)
- Webアーキテクチャと親和性が高い
- 比較するならMQTT-SNかなー
- エンジニアが遊ぶ隙間少なさそう
- 標準化中！
-
WebRTCとかも見てみるといいよ！
- MQのMQってなに？
- JobQueue
- AMQP (RabbitMQ)
- XMPP
- バックエンド向けじゃない(MQTTも)
- 色々できるけど複雑で実装コストも高い
- PCの前に座ったユーザに向けてという用途
- レガシーで微妙な仕様が残っている
- Redis/STOMP
- シンプルでテキストベース
- Redisってプロトコルより実装だよね
- 省エネ・QoS・Willってのはない
- でもシンプル
- 何を目指したプロトコルか？で選ぶ
- PerlでMQTT
- AnyEvent MQTTっておもろい
- BTLE
- iBeacon
- 時代の変遷
- Broadcast
- Pull
- Push
- (Pick?)
- iBeaconがキーになる？
- セキュリティとプライバシーを考慮したパーソナライズが求められる
ウェッブエンジニアのローレベルプログラミング
-
@cho45 さん
- 感想
- 久々アマチュア無線の話題が出てきて何か嬉しかった
- 私は中学生の頃にやっていて、2級を持ってる。
- 「毎日、これができるようになった！という感動を改めて味わいたい」って趣旨の言葉、響いた。
- 久々アマチュア無線の話題が出てきて何か嬉しかった
- アジェンダ
- ARMアッセンブリのすすめ
- ハードウェアプログラミング
- 更にローレベルへ
- ARM/Linux用のアッセンブリのススメ
- x86より命令数が少ない
- メモリ操作はldr/strのみ
- スマホとかだいたいARM
- レジスタ名がわかりやすい
- Linux上で動けばデバッグしやすい
- ARMマシンが無くてもQEMUでもできる
- ほとんど全ての命令に条件を設定できる
- ググったら命令一覧が出てくる！
- x86より命令数が少ない
- Linux ABI
- スタック、システムコールについて定められている。
- EABIだけ覚えとけ
- モティベーション
- 何を書く？
- ブログツール！
- blosxom
- テキストファイルを返す！だけのCGI。
- できた！
- ラズパイ
- GPIO
- ファイルシステム経由で操作
- i2c
- SPI
- RS232C
- RasPiでベアメタル
- そういうのあるそうだ
- mrubyで実装している
- 作り込むと…
- Sleep、Linuxカーネルって凄いな！
- OSブートプロセスへの親しみがわいてくる
- 生で自分のコードが動く喜びがある
- 更なるハードウェアプログラミング
- Arduino
- リアルタイム実装かなり得意(さすがマイコン)
- ラズパイにはA/D変換機が無い
- 電子工作の知識が必要になってくる！
- データシート読む
- 切り分け
- モジュール化
- 信頼性設計
- プログラム書くのとあんまかわらない
- 回路設計できると夢が広がる！
- Arduino
-
毎日、これができるようになった！という感動を改めて味わいたい方はオススメ！
How’s startup life? – working as CTO in Japan
-
@shohey1226 さん
- 感想
- 資金調達の所、もっと聞いてみたかった。
- VCと話をして苦労した事があった。
- 開発にJSが締める割合が高まっている模様。JSちゃんとやらんとな。
- 資金調達の所、もっと聞いてみたかった。
-
モノ・サービスを作って企業価値を最大化
-
投資家とのコミュニケーション・コミットメント
-
エンジニアもFinanceの知識を持とう
- シェアオフィスで働いている
- 何も知らないまま起業→情報交換できる
- 採用しやすい・手伝ってもらえる人を探しやすい
- (場所に寄るが)パーティなどで酒を入れつつ情報交換もできる
- どんな人が必要？
- Finance
- Technology
- Design
- その他は積極的にアウトソース使用
- 誰とやる？
- 企業文化とつながるので特に初期の人選は重要
- 話し合って作れる
- スクラッチから作れる
- Perlだよね！
- 学ぶ時間がなかなかできない
- 開発
- JS 70%
- Perl 20%
- ITインフラ 10%
- 日本における起業のエコシステムはなかなか厳しい感
- 特に投資額が低い
- 社会的地位が低い
- なぜスタートアップ
- リスクの再考
- お金ばかりではない
- 世の中に無いプロダクトを作りたい
開発合宿！！！！
- @yasuhiro_onishi さん
- はてな サービス開発本部長
- 最近あんまりPerlモジュールを書いてない
- 感想
- 開発合宿、やってみたい。知り合いとでいいからやってみたい。
- 新しいプロダクトを作るの、最近は遠さがっているので、ちょっとモティベーション上げて行くきっかけを作りたくなった。
- 開発合宿
- はてなでは2005年からやってる
- うちがOriginだ！と思ってる
- はてなブックマークもここから
- やると決めた次の日に合宿(合宿前に何を作るか決めていなかった)
- 目的
- 最初は数年で1カ所で集まってやる
- 複数チームにコンペティションに変わって行った
- 流れ
- 2泊3日
- 2〜3時間くらいの距離
- 初日でチームビルド→開発
- 最終日に成果発表
- pros
- 非連続
- 普段の業務から離れる
- 普段と違う人
- 祭り
- 非日常
- cons
- 回線が良くない
- 大画面モニタが無い
- イス悪い
- 飲み過ぎ
- 寝ないで続けちゃう
- 準備ノウハウを伝授
- 企画・テーマ決め
- 幹事決め
- 宿と飯の手配
- 旅のしおり作成
- 買い出しと荷物発送
- 宿選びポイント
- 有線・無線LAN
- 一日中使えるか
- 会議室とプロジェクタ
- 3日座椅子だと腰を悪くする
- 持ち込み・冷蔵庫
- 周辺環境・コンビニ
- 酒は切れる！
- 準備物
- VPN張れると尚良い
- レンタカーで運ぶ
- 飲食
- ゴミ袋
- 紙コップ・紙皿・割り箸
- 企画
- 模造紙
- ペンやマーカー
- 付箋
- メモ用紙はたくさん
- 賞品等
- バリエーション
- アイディアソン
- 事前に集めとく
- 賛同者を集めてチームビルド
- 非・開発者もアイディアを出せる
- アイディアだけのコンテストも(合宿じゃないけど)やったことある
- 複数会場
- 非参加者を巻き込む
- アイディアソン
- 成果発表
- Ustなどで非参加者も巻き込む
- 家族も来てもらって社員旅行化する
- 社員22名、家族16名(うち8人が子供)
- 会社見学会っぽい
- でもカオス過ぎてやめた
- 実況したりした
- 1時間毎にレポーティング
- 一体感出す
- まとめ
- 盛り上がる！
- コストもかかる
- 準備をちゃんとやって会社を盛り上げよう！
- 質問と回答
- 半年に1回
- 最長 米国合宿1週間
LT
キーワード