Project

General

Profile

YAPC::Asia Tokyo 2014

ランチセッション 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が歩んだデプロイ自動化への道

なぜデプロイ自動化なのか
 安全工学 システムの事故などを防ぐ
 スピード タイムトゥマーケット
 スピードx品質xコストのトレードオフ
 悪いシステムほど問題が後になって発見される
 リリースに困難さを感じるかどうかがシステムの安全性の指標となる
 リリースプロセスの自動化を考えれば、システムの自浄作用が働く
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)
はてなブックマーク2005-02-05(開発開始)→2005-02-10(ベータリリース)
数人で一つのサービスを作る → 複数チームでコンペティション
基本フォーマット 2泊3日 片道2-3時間 初日チームビルド 最終成果発表
合宿は新サービスなど非連続な開発、普段と違う、お祭り感、非日常感、モチベーション向上
合宿は回線がよくない、大画面モニタがない、アーロンチェアがない、飲み過ぎる、寝ない
準備:企画・テーマ、幹事、宿・食事手配、旅のしおり、買い出し・荷物発送
宿:LAN環境、一日中作業できる・椅子、会議室・プロジェクタ、持ち込み・冷蔵庫、周辺環境・コンビニ
準備機材:無線LANルータ、VPN、電源タップ、プロジェクタ、レンタカー
準備飲食:お菓子、ソフドリ、お酒、ゴミ袋、紙コップ
準備企画:模造紙、ペン、付箋、メモ、賞金・商品
開発合宿バリエーション:アイデアソン(アイデアだけのコンテスト)、オフィスでも同時開催(経費削減)
成果発表回:非参加者もまきこむ
開発合宿は盛り上がる、コストはかかる、企画・準備をしっかり
サイクル:半年~1年に1回はやりたい

Added by aretan 2014-08-28 ago

ogp_icon_350px.png View (4.18 KB) 2018-03-09