aretan.jp

ランチセッション　DeNA　QuizNow!¶

思いついたらやる
バカバカしくてもやる
やりすぎて怒られるぐらいがちょうどいい
それぞれの専門を共有していく　Xcode勉強会　Photoshop勉強会
勉強会のスタイルを社内に生かしていく

作られては消えていくクラスタの運用話　株式会社バスキュール¶

http://www.slideshare.net/tsuyoshitorii5/yapcasia2014-2-public
MIES　テレビ局　サーバー　視聴者（テレビ・スマホ）
IRC Hipchat → Slack
Proteus-Monitor
俺がSPOFだ！
Vagrant ＋ vagrant-aws ＋ chef-deploy
AWS CloudFormation ＋ AWS AutoScalinh
Chef ＋ Berkshelf
vagrant-ami
base-cookbookで全サーバーにある共通のものをする
rakeですべての操作をする（基本的にvagrantのラッパー）
rake local:task
rake aws:task
rake aws_cf：task
別のAWSアカウントでやるときの問題
・AMI移動　（BaseAMI作り直し）
・Keypair設定
・AWSキー更新 IAMロール使わない
・アプリケーションの設定
・・・
Omniscient　サービス全体のコンフィグを持つ
AWSからOmniscientにコンフィグをpullしてきて再起動的なことをする
Docker化したい　→　開発配布　サービス配布　プロダクション配布

Scala in Perl Company　株式会社はてな¶

https://speakerdeck.com/hakobe/scala-in-perl-company
価値を生み出すにはソフトウェア進化を継続することが重要
・機能追加
・リニューアル
・パフォーマンス改善
・外部変化への対応
・リファクタリング
・ライブラリ更新
エラー検知の限界
カバレッジを高めればいいが、どこまでコストかける？
エンジニアが頑張ってコードを把握するしかない？
はてなが使っていた社内向けの管理ツールをサービス化　mackerel
MUST: 静的型システム
SHOULD: 柔軟さ　実績　社内に書ける人がいる
→ Haskell？ → Scala
Javaのライブラリが使える：データベースドライバ、ネットワーク
言語仕様が多いので勉強するのが大変
Hatenaではソフトウェア進化を安全に行うことに課題意識
型システムも最高だけど課題もある

コマンドラインツール　楽天株式会社¶

https://speakerdeck.com/tcnksm/komandorainturunituiteyu-rutokinipu-falseyu-rukoto-number-yapcasia
実践することによって良いコマンドラインツールが作れる
良いコマンドラインツールとは
1つのことに集中できる　→　UNIXという考え方
直感的に使える　→　コマンドラインツールにもUI/UXがある　GNU標準インターフェース
他のアプリと連携できる　→　終了コード　標準出力
利用を助けてくれる　→　ドキュメントが無いのは論外　README　helpオプション　manpage
適切なデフォルト値　→　デフォルト＞設定ファイル＞環境変数＞引数
すぐにインストールできる　→　brewなどのパッケージマネージャでインストールできる

コードを書く前にREADMEを書く
NAME　CIステータス
Golangならgoxで全プラットフォームにクロスコンパイルできる
ghrでgithubにどかんとリリース
git this
hub create
git push
ghr

DeNAが歩んだデプロイ自動化への道¶

なぜデプロイ自動化なのか
　安全工学　システムの事故などを防ぐ
　スピード　タイムトゥマーケット
　スピードｘ品質ｘコストのトレードオフ
　悪いシステムほど問題が後になって発見される
　リリースに困難さを感じるかどうかがシステムの安全性の指標となる
　リリースプロセスの自動化を考えれば、システムの自浄作用が働く
Mobageアーキテクチャについて
　最初は一人で始めたシステムが成長とともに肥大化した
　1コンポーネントで色々つまっていく 開発で本番で動きが違う
　いかにしてレガシーから脱却するか？
　大きなコンポーネントを小さくわけていく

　自動化できるデプロイの条件
　　・version管理されている
　　・CI環境が構築されUT、受け入れテストが自動化されている
　　・データベーススキーマがバージョン管理されている
　　・いつでもクリーンな動作環境を作れる
　　・環境を問わない簡易なデプロイスクリプトであること
　リリースはデプロイだけじゃない　デプロイメントパイプライン
　開発＞UT＞検証環境デプロイ＞検証環境受け入れテスト
　これら一連のすべてをversion管理にコミットする度に行う
　テストの定義
　　・単体テスト
　　・結合テスト　End-to-End
　CI/CD 継続的インテグレーション　継続的デリバリー
　　コミット単位でリリースサイクルを繰り返す
　　反復されたプロセスは信頼に足る
　　Jenkinsを用いたCI/CD環境
　　　ビルドパイプラインの構築
　　CIだけやっていたが、CDで手戻りが減った
　　わりと泥臭くクリアしながら段階的に本番投入した

WHERE狙いのキー、ORDER BY狙いのキー　GMO株式会社¶

http://www.slideshare.net/yoku0825/whereorder-by
ORDER BY狙いのキーはソート済みなので先頭から取り出す
だからJOINするとORDER BYでキーが使えてない事が多い
ORDER BYをインデックスで解決するには外部表にキーがないとだめ
思ってないようにインデックスが使えてない事が多いので注意する
WHEREで絞れる場合はWHERE
WHEREがほとんど機能しない場合はORDER BYを

ウェッブエンジニアのローレベルプログラミング¶

https://docs.google.com/presentation/d/1eyawDBqXlUSS40kVEGYMP79c3xhyNX_VbTJ68ziLJSM/pub?start=false&loop=false&delayms=3000#slide=id.p
ARM assemblyのススメ
ハードウェアプログラミング
さらにローレベルへ
すごい人は下から上まで全部できる
Armはx86に比べて命令数が少ない
スマフォはだいたいARM Linux/Rasberry Piも
レジスタ名が大変わかりやすいr0～r15 32bit
ARMのアーキテクチャ
基本32bit固定命令調
演算は常にレジスタ対象（ロード/ストアアーキテクチャ）
ほとんどすべての命令に条件を設定できる
LinuxABI　バイナリレベルでのOSとアプリ間のきめごと
ARM Linux ABI
ss -o sketch.o sketch.s
ld -o sketch -e _start sketch.o
./a.out
アセンブリで何を書くか？　簡易blosxom
ハードウェアプログラミング
Raspery pi　GPIOがいい
トランジスタスイッチング　FETスイッチング
周辺機器のハードウェアプロトコルをしる必要がある　I2C（2線式プロトコル）
I2C Linuxにドライバがあればすぐつかえる
Arduinoというのも聞く　→　パソコンではなくマイコン　OSがない
Raspery piもOSなくてよくね？　→　OSレスでいける　mrubyでいける
OSブートプロセスへの親しみも沸く
Raspberry piはまだ囚われている　ホストコンピューターからの解放
Arduinoは単体でも動く　→　AVRというワンチップマイコン
250円から50円ぐらいで買える　ATmegaならI2Cも動く
モールス符号を変換するとか
イーグルというので
コード書いた結果が電気に直結する
CPUを使い切ることしか考えてない
VUSBで振動するだけのマウス（USB機器）作った
データシート（仕様書）よむ・モジュール化・信頼性
プログラミングを始めた時のように新鮮な感動がえれる

How's startup life? Working as CTO in Japan　株式会社Actie（元モルガンスタンレー）¶

http://shoheik.hatenablog.com/entry/2014/08/29/180501
Goal: Exit - IPO or Buyout
Seed＞Angels＞Early＞Round＞Goal
株が無いとスタートアップは意味がない（エンジニアは強気にCEOに交渉する）
シェアオフィスでアドバイスがもらえる・仲間がつのれる・パーティー
Who is startup：Finance　Technology　Design
どんどんアウトソースしていく
スタートアップは誰とやるのかが大切
Mojolicious/PSGIで作っている
AngularJSで書いてるからAPIで返すだけ
Chef, Puppet　→　Ansible
サーバーはDigitalOcean（AWS使いたいけど）
日本ではまだ投資額が少ない
なぜスタートアップなのか？　→　リスクを考えなおす
金だけじゃなくて世の中にないプロダクトを作るのは楽しい
自分自身を成長させたい人は挑戦したほうが良い（独身であれば）

開発合宿　株式会社はてな¶

https://speakerdeck.com/onishi/hatena-camp
温泉やリゾートに出向き寝泊まりしながら集中的にソフトウェア開発をする行為のこと（Wikipedia）
はてなブックマーク２００５－０２－０５（開発開始）→２００５－０２－１０（ベータリリース）
数人で一つのサービスを作る　→　複数チームでコンペティション
基本フォーマット　2泊3日　片道２－３時間　初日チームビルド　最終成果発表
合宿は新サービスなど非連続な開発、普段と違う、お祭り感、非日常感、モチベーション向上
合宿は回線がよくない、大画面モニタがない、アーロンチェアがない、飲み過ぎる、寝ない
準備：企画・テーマ、幹事、宿・食事手配、旅のしおり、買い出し・荷物発送
宿：LAN環境、一日中作業できる・椅子、会議室・プロジェクタ、持ち込み・冷蔵庫、周辺環境・コンビニ
準備機材：無線LANルータ、VPN、電源タップ、プロジェクタ、レンタカー
準備飲食：お菓子、ソフドリ、お酒、ゴミ袋、紙コップ
準備企画：模造紙、ペン、付箋、メモ、賞金・商品
開発合宿バリエーション：アイデアソン（アイデアだけのコンテスト）、オフィスでも同時開催（経費削減）
成果発表回：非参加者もまきこむ
開発合宿は盛り上がる、コストはかかる、企画・準備をしっかり
サイクル：半年～1年に1回はやりたい