MySQL Beginners Talk #1に参加してきたので、そのメモ

参加してきました。思い切りそのままメモ転載。

初心者向けMySQLの始め方 - tmtmsさん

  • MySQLオープンソース(GPL)なRDBMS
  • たいていのLinuxには含まれている
  • 今なら5.5系を使いましょう
  • 公式バイナリを使うのがいい
  • 設定ファイル(my.cnf)は読まれる場所は全部読まれて、あと勝ちになるので注意が必要
  • skip-name-resolve, innodb-file-per-tableとかshow-warningsとか
    • skip-name-resolveをしておくと、クライアントが接続してきたときに逆引きしなくなる
  • mysqld_safeは最近は安定しているので使わなくてもいいと思う
  • kill -9 はダメ、絶対!
  • 待受ポートはTCP:3306とUNIX Socket:/tmp/mysql.sock
  • パスワードの設定はプロンプトの画面で set password [for user@host] = password('hogehoge');
  • -pの後ろに空白は要らない
  • (初期状態では)匿名ユーザ(適当な名前のユーザ)はパスワードなしでtest DB(information_schema)にアクセスできる
    • 気持ち悪いので消しておいたほうがいい(基本的には自分自身からしか繋げないけど)
    • root@localhostだけ残して消しても問題ない
  • たいていは grant all on DB名 to user@host; で権限を与えれば良い
    • 細かくもできるがDB単位くらいで
  • 127.0.0.1localhostは違うよ!
  • 日本語
    • 初心者は黙って utf8
      • [mysqld] character-set-server = utf8 / [mysql] default-character-set = utf8
      • アプリなどは、それぞれで指定
  • charset と collation
    • charsetはコードと文字の対応(ざっくりいうと)
      • mysql-5.5からはutf8mb4も使える
    • collationは文字の照合順序
      • utf8_general_ciはデフォルト大文字小文字を区別しない
      • utf8_binは大文字小文字を区別する
      • utf8_unicode_ci はUCAによるcollation。全角半角も区別しない。

ORACLEさん、ハイパー宣伝タイム

  • MySQLの普及率 60.5% (2009年調べ)
  • 資格認定試験 = MySQL 5 Database (Administrator|Developer) など
    • 実際の運用管理の現場で求められる知識とスキルの認定
  • 資格に対応した講習もあるよ
    • TuningやClusterの講習もあるが、テキストが英語です!
      • 秋くらいには日本語でできるかも(確約はできません)
  • トレーニング・オンデマンドというビデオ教材での研修もある
    • テキストはPDF
    • 有効期限は購入より3ヶ月
      • 半額で3ヶ月延長可能
    • iPadでも見られるよ!
      • HTML5 の動画なので
    • MySQLの講習は日本語化されていません!
      • ITの世界は英語必須だから、問題ないよね
      • しゃべっている内容が字幕で出るので、全文検索もできて便利

MySQLインストールお作法 - @meiji さん

  • あまりよく考えずにソースからインストールするのはやめましょう
    • 本に書いてあるからってダメ!絶対!
    • 公式のバイナリがいいよ
    • RPM全部入りのやつもあります
      • その中でどれ入れたらいいの?
      • Cのライブラリ(libmysqlclient.so.xx)が必要なら、MySQL-sharedが必要。shared-compatパッケージには旧バージョンのライブラリが入っている
      • 5.1まではshered-compatとsharedの共存は不可(compatに最新版も含まれているため)
      • libmysqlclient.soを使わないプログラムを書く場合は、MySQL-connectorが必要
    • Windowsはbitを気にすればいいだけ
      • インストール時のcharset周りのpath周りだけ気をつけてね
  • データとバックアップ/バイナリログは別の場所(ディスク)にしておこう

MySQL日本語利用徹底入門 - @nippondanjiさん

MySQL文字コード

  • 照合順序
    • 文字の並び順
    • ソートや比較の処理に影響
    • show collation
  • 文字コードがセッションごと/テーブルごと/カラムごとに異なるかも
    • 柔軟さの現れだが、扱いには十分注意
    • カラムごとに指定可能で、指定しなければテーブルのデフォルト文字コード、テーブルの文字コード指定がなければDBの文字コード、DBの文字コード指定がない場合はcharacter_set_serverが使われる
    • 基本はcharacter_set_serverを指定しておく
  • 照合順序の指定
    • カラムであればcollate utf8_binのように指定
  • 確認方法
    • show create table テーブル; で文字コードを確認すること大事
    • show full fields テーブル; でcollationの確認ができる(collationがわかれば文字コードもわかる)
    • information_schemaを使って確認することもできる
  • 文字コード関連のオプション
    • character_set_server
    • character_set_database
    • character_set_connection
    • character_set_client
    • character_set_results
    • character_set_system
    • character_set_filesystem
  • skip_character_set_client_handshake
    • クライアントが指定した文字コードを無視
      • C APIPHPの時に便利
      • Connector/Jでは効かない
  • default_character_setはserver側の文字コード指定では使えない(MySQL5.5以降)
    • クライアント側では使える

文字コード関係のトラブル

  • 文字化け
  • LOAD DATA IN FILE
    • ファイルの文字コードがcharacter_set_databaseになっていることを期待される
    • テーブルの文字コードと同じ場合には bunary に一時的にSETしてあげる
    • mysqlimportを使う
  • SELECT ... INTO OUTFILE
    • 後で LOAD DATAで読む場合は binaryを指定するといい
    • CHARACTER SET 〇〇 のように指定するといい
  • latin1で格納されている?
    • セッションの文字コードもテーブルの文字コードもlatin1の場合には化けずに格納できてしまう
    • はまりやすい
      • SELECT INTO OUTFILEなんかでbinaryでダンプして作りなおす必要あり
  • 5C問題
    • Shift JISの2バイト目が0x5C (\) の場合に起こる
  • ラウンドトリップ変換
    • ダッシュサインなんかがいい例
    • 検索の時に引っかからなくなる

まとめ

  • 自動変換が起こらないようにする
  • 迷ったらすべてutf8いで統一する
  • showコマンドやinformation_schemaで色々捗ります
  • 鍵本が近日増刷予定!

LTセッション

studio0340_comさん

  • スロークエリどうにかならない?
    • innodb_buffer_poolを増やして対応
      • 本当に改善って言っていいの?
  • インデックス使っていないスロークエリを探せ!
    • min_examined_row_limit
      • 指定行以上のテーブルから読み込んだクエリをスロークエリに記録する
      • これがデフォルト10000行以上 デフォルト値は0なので記録されない。潜在的な性能劣化をさせる危険性を秘めているクエリを見つけるために10000行とかにしておく。ただ、これを超えないと記録されないので、値の設定は吟味が必要。
  • mysqldumpではまった
    • ダンプ中に更新が走ったものは、その間(ロックされている間)は更新されない
  • dump-slave
    • ダンプ中はreplicationが止まる!
    • パッチができて、対応(実際はFlush logsに関するもの)

Beginnerならきっと役立つMaster-Slave環境 - @yut148さん

  • Paasで無料なのもあるよ!
    • ただ使うだけなら自前で環境作らなくてもよいのではないかということ
    • 流れるデータには注意

MySQL Casual Talks - @myfinderさん

  • ガチュアルではなくカジュアルです!
  • ノウハウの共有 ≠ 事業価値の毀損
    • 画像がDBに入っていたっていいじゃない
    • autoincrementでもいいじゃない
  • あなたの疑問は誰かの疑問
  • LTは直前でも申し込みOK
  • #mysql-casual@freenode (IRC) で開催について最初に話されるよ(多分)

1台から500台までのMySQL運用(Beginners編) - @kazeburoさん

  • Livedoorは基本的には開発者がサーバを見てきた
    • サービスごとに差が生まれる
    • いくない
  • 仮想化によるサーバ集約で4桁台あったサーバが400台に
  • 基本的にはMySQL 5.1.x
    • 必ずinnoDB-pluginを使う
      • Fast Index Creation 様さま!
  • my.cnfを共通化
    • セットアップツールの提供
      • よくあるチューニングを施してある
  • my-moder.cnf
    • 標準のはいまいち
    • オレオレmy.cnfに自身がある人いない?
  • No MyISAM
    • 絶対に使わない
    • kill -9 しても壊れない
  • xtrabackup
  • ログ系のテーブル
    • Expire処理を忘れるとひどいことに
      • 必ず消すことを忘れないように!
    • 件数が多くなると、削除するほうが大変です!削除戦略をしっかり立てておきましょう。
  • モニタリング
    • 必須です

私がMySQLを始めた理由 - オラクルのやまさきさん

  • MySQLGPL
    • 発展が多くの人に価値をもたらす

感想など

@tmtmsさんのお話は、初めて触る方がどんなことに注意しながら使っていったらよいかという視点で、実際に動かしてある程度何かをしてみるまでの導入部分をすべて網羅しているんじゃないかなと思いました。自分のように触り始めてある程度たった人でも、基本的な部分を見なおしてみるのにはすごくいい機会になりました。

さすがに@nippondanjiさんの話はBeginnerの枠を超えていたような気がしなくも無いですが、最初に文字コード周りの話を理解しておくことでハマりポイントを減らすことができるので、いいですね。さすがエンジニア目線だけでなくサポート目線も持っている方だなぁと、あっけにとられながらも勉強させていただきました。鍵本は増刷されたらぜひとも購入させていただきたいと思います(まだ買ってないのかなんて言わないで><)。

自分は大規模なサービスでMySQLを使ったことが無いですし、ガチなチューニングなんかもしたことがないので、ペラッペラな知識や経験しかないのですが、こういった基礎的な部分を再確認させてもらえる機会があったのはすこくプラスになりました。ガチュアルと呼ばれる人たちに少しでも近づけるよう、最低限基礎は染み込ませておきたい。

追記

  • 2012.06.11コメントでの指摘を受けて min_examined_row_limit のところを修正

hbstudy#33のMercurialハンズオンに参加してきました

はい、とてつもなく久しぶりのブログです。最近ブログネタになるようなことをほとんどしていませんです。

4/28(土)に開催された hbstudy #33 に参加してきたので、レポート的なものを書いておこうかと思います。

バージョン管理の必要性

  • ファイルの変更の5w1h(いつ、どこで、だれが、何を、なぜ、どうやって)がわかる

バージョン管理が必要なファイル

  • サーバの設定ファイル
  • デプロイスクリプト
  • 環境構築のためのプロビジョニングスクリプト
  • ドキュメント

など編集するものすべて

バージョン管理すると

  • 変更の経緯がわかる
    • セットアップが職人技じゃなくなる
  • どのファイルが変更されたかすぐにわかる
  • .bakとかできなくなる
    • 心の平穏w

インフラ向きのバージョンな管理システムは

  • git
    • [o] 手軽にバージョン管理
    • [o] 他のサーバと履歴を共有
    • [o] チェンジセット
    • [o] ブランチ
    • [x] コマンド体型が他と違う(モヒカン向け)
    • [x] Windowsで使うにはmsysが必要
  • Mercurial
    • [o] 手軽にバージョン管理
    • [o] 他のサーバと履歴を共有
    • [o] チェンジセット
    • [o] ブランチ
    • [o] Windowsサポート
    • [x] githubをサポートしていない

どこででも使えるMercurialいいよ!!
癖も少ないし!

Mercurial

  • Mercurial = 水銀
    • なのでコマンドは hg (元素記号)

分散バージョン管理システム

  • 手軽にバージョン管理
    • あとからサーバを準備して、他サーバとの共有も可
  • ローカルコミット
  • 手軽なブランチングと安全なマージ
    • コミット済みの変更をマージするので安心

特徴

  • gitに比べてシンプル
    • リビジョングラフがすべて
    • 分岐はブランチ
  • エクステンション
    • pythonで拡張可能
    • 便利な機能はエクステンションなので、有効にしないとダメ(同梱されているものもすべて無効化されている)
    • 履歴改変系もエクステンション
  • 安全な履歴管理
    • 履歴は神聖
    • 改変可能かどうかを示す phase という安全弁
    • 危険な履歴改変はエクステンションを有効にする必要あり
      • rebase, transplant, mq

履歴改変

履歴改変はpushしていないもののみ可能
→ push 後は誰が触っているかわからない
  • コミットログをあとから変更
  • コミット忘れの追加など
  • コミットを移動する

用語など

資料を参照

ハンズオン

各自で進めましょう!

  1. 課題のダウンロード
  2. おすすめ.hgrcをベースに.hgrc設定
  3. 基本操作
  4. リポジトリサーバを使う

基本操作

  • Blockdigのリポジトリをcloneして、ログやリビジョングラフを見てみる
    • 深夜2時過ぎにcommitしてる!
  • 課題用ディレクトリでリポジトリを作成
    • hg init
  • 今あるファイルをリポジトリに追加
    • status -> add -> status -> commit -> status
  • 少しずつファイルを変更しながら、コマンドの使い方を覚える
    • 編集 -> diff -> status -> commit
  • (直前の)コミットの取り消し
    • commit -> rollback -> revert
      • 直前以前のコミットを取り消すにはbackuoutを使う
  • マルチプルヘッドを作る
    • prarentsで現在のリビジョンを確認(Nとする)
    • 編集 -> commit -> update N -> 編集 -> commit -> update N -> 編集 -> commit -> glog でリビジョングラフを確認
  • マルチプルヘッドをマージ
    • merge
      • ヘッドが3つ以上ある場合は merge REV のようにリビジョン番号を指定する
    • マージしたらコミット
    • マージツールが起動してしまう場合は update --clean で元に戻して、 merge --tool=internal:merge をする
  • マージの取り消し
    • update --clean

リポジトリサーバを使う

  • 簡易的にサーバを起動
    • リポジトリのあるディレクトリで hg serve
      • 8000ポートでサーバが起動
    • pull, push, cloneを試す

hgrcの内容はこんな感じで

[web]
    allow_push = *
    push_ssl = False
  • コンフリクトさせたり解決したり

このへんで時間切れと相成りました。


講師の troter さんとサポートで来て下さっていた方々、heartbeatsの皆様、お疲れ様でした!
懇親会も含めて、楽しめました。

※相変わらず、まとまりもなく、資料を見れば書いてあることばかりですが、大目に見てください。

odstudy 2012.02 「エンジニアのための提案力向上セミナー」 in qpcon のメモ

2012.02.25のqpstudy系の勉強会が一同に介したカンファレンスに参加してきました。その中で聴講した odstudy の「エンジニアのための提案力向上セミナー」のメモです。ほとんど書き写しになっちゃいましたが、そこはまとめ力のない私を笑って済ましていただければとw

話者

  • teian-lab 式町久美子さん (APMP)

teian-lab

  • 提案力を高めたいヒトタチによる提案力を高めるための勉強会
  • いろんな業界/業種でノウハウ、経験を共有
  • 内容
    • 提案書の書き方
    • 提案計画の仕方
    • プレゼンテーション
  • 大事にしたいこと
    • 頑張り過ぎない
    • 自分もみんなも楽しむ

どのような提案?

  • 上司への改善提案
  • お客様への提案
  • コンペ
    • どう考えても負け試合になりそうな場合とかにどう対応していくか
  • 将来チェレンジしてみたいこと

どうやって書くの?

  1. 提案戦略
  2. エグゼクティブサマリー
  3. ストーリーボーディング
  4. FAB (Feature, Advantage, Benefit)

提案戦略

  • 説明が通じない
  • 的を外す/話す相手を間違える
    • いつも話している人(現場)のレベルに合わせるのではなく、その上司(決済者)に届くように
  • 承認を得られない
    • 伝え方がよくないのかも
戦略策定
  • 優位性
    • 自分の提案でなければならない理由を見つけて伝える
    • 調整
  • 提案相手を取り巻く環境
    • プロジェクト名、背景、ニーズなど
    • 社内の場合は、どういう経路でニーズが生まれているか(誰の要望が背景にあるか)とか
  • 強み・弱み分析
    • 自社/競合
    • 自社でなければならない理由
      • ディスカウントできないときに、ギャップを埋めるために何ができるか
      • 要求を満たすためにできること
  • 優位性を導き出す
    • プロジェクト管理とか
  • どれだけ相手を理解しているか
    • 伝えるべき相手
      • 立場に寄って関心事が違う
      • 誰に提案をするのか
        • 技術のわからない人に、細かい技術を説明するのはNG.Issueをどれだけ満足させられるか、予算はどれくらいか
      • ホットボタン
        • 顧客にとって最も重要なこと

エグゼクティブサマリー

  • 短時間で提案内容が理解できるもの
  • ココだけ読めば8割のない様が理解できる
  • 全ページの1割以内
  • お客さんと相談しながら作ると良い
ベネフィット
  • お客さん目線のベネフィット
ポイント
  • 相手の要求にダイレクトな答えが出せているか
  • 他社との違いが明確に打ち出せているか
    • 製品の機能や使い方だけの説明になっていないか(自分主体の言葉)
    • 相手主体の言葉を使う

ストーリーボーディング

伝わりやすいストーリーを書き始める前に考える
  • ホットボタンや評価基準への答えをわかる位置に見せる
    • 1章で要求に対する回答をまとめておく
  • ちゃんと内容の整合性があるか
    • 2章以降で話す詳細説明が、1章で伝えたissueへの回答から外れることがないか
    • 資料を作る人の間での連携
      • 1枚は「必ずこれを入れるべき(1章との整合性の担保)」を指定しておく
執筆者向けガイド
  • テンプレートを作って渡す
    • ここにベネフィットを書くなど
    • RFPから外れることが無いように必須要件は記載しておく
読み手を惹きつける
  • ベネフィットから書く

FAB (Feature Advantage Benefit)

  • 特徴
  • 利点
  • 利益
相手にとってのベネフィットを先に述べる
  • 固有の問題解決に対してどう役立つか
  • 仕様から書かない
    • エンジニアは仕様から書きがち
    • 何が得なのかは理解されない

質問

  • 技術的な内容ではなく、金額で決まってしまう場合にどういう提案の仕方がいいのか?
    • 自分たちでなければならないような関係を作るように、そういうアクションを会社全体で作っていく。
    • この技術でないとお客さんの要求が満たせないというような関係を作れるか
      • ここはちょっと質問者が求めてる回答とは違ったような空気だった。
  • 仕事をしてる時に気をつけていること
    • お客さんの状態を事実に基づいて判断したいので、営業さんにそれが本当に事実なのか(営業フィルタがかかっていないか)を聞き出すようにする
    • チーム全体(営業、SEなど話を聞いてきた人+それ以外の人)で要求を共有するようにする

まとまらないまとめ

  • 自分のやったことをアピールする発表と違って、「提案」は相手からの「要求」があってそれに対する「回答」である
  • 自分(たち)がやったこと/できること(仕様)を事細かに説明するのは、要求者側からするとあまり意味のあるものではない
  • 誰に対して(現場の人間だけではなく、決済者全員)響く内容にするかが重要
  • 何よりも、「要求」に対する「回答」を全面に押し出して、わかりやすく伝える
  • 「回答」の中にはFABを含める
  • ヒアリング内容に個人のフィルタがかからないように、要求を聞くときは立場の違う複数人(営業とSEとか)で聞き、帰社後に関係者全員で共有することで認識のズレが起こらないようにする。

といったところでしょうか。
自分は対お客さんに提案をしたことは(ほぼ)ないのですが、対社内(上司)では苦労をしているので聞いた内容を生かしていければいいな思う所存にございます。