MySQL Casual Talks Vol.3 : ATND おつかれさまでした！
去る4月19日はこじはることAKB48小嶋陽菜の誕生日でした！
先日の握手会でそのことに気づいてしまったので
なにかこじはるネタでLTをしたいなということで
Haruna storage engineというネタをやりました。
InnoDB Deep Talk #1 : ATNDでd:id:moriyoshiさんがLTしていた
InnokoDBをパクったForkしただけのネタなんですけど
テーブル名で動作が変わるストレージエンジンネタもやってみたかったので
テーブル名に"mariko"が含まれてると麻里子様のツイートも取ってくるようにしてみました( *｀ω´)八(бвб)
きもい、滑ってる、これはひどい、などの率直な感想を頂いておりますが
これに懲りずにまた呼んでください！よろしくおねがいします！！
買ってきたらとりあえずやる(やった)こと一覧。
defaults write com.apple.finder AppleShowAllFiles TRUE killall Finder
sudo chown -R `whoami` /usr/local ruby -e "$(curl -fksSL https://raw.github.com/mxcl/homebrew/master/Library/Contributions/install_homebrew.rb)" # for Xcode 4.3 sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer xcode-select -print-path brew install \ ack \ aspell \ cmake \ coreutils \ git \ hub \ libxml2 \ libxslt \ proctools \ readline \ sqlite \ watch \ wget \ zsh
cd ~ git clone git://github.com/kamipo/dotfiles.git cd dotfiles ./dotsetup.sh
cd ~ git clone https://github.com/sstephenson/rbenv.git .rbenv mkdir -p ~/.rbenv/plugins cd ~/.rbenv/plugins git clone https://github.com/sstephenson/ruby-build.git export PATH="$HOME/.rbenv/bin:$PATH" eval "$(rbenv init -)" rbenv install 1.9.3-p125 rbenv global 1.9.3-p125 rbenv rehash ruby -v
curl -kL http://install.perlbrew.pl | bash source $HOME/perl5/perlbrew/etc/bashrc perlbrew install perl-5.14.2 perlbrew switch perl-5.14.2 perlbrew install-cpanm perl -v
cd ~ git clone git://github.com/kamipo/mysql-build.git export PATH="$HOME/mysql-build/bin:$PATH" mkdir -p ~/opt/mysql mysql-build -v 5.6.6-labs-april-2012 ~/opt/mysql/5.6.6-labs-april-2012 cd ~/opt/mysql/5.6.6-labs-april-2012 ./scripts/mysql_install_db ./bin/mysqld_safe & ./bin/mysql -e 'show variables like "version"'
Webアプリケーションを運用しているエンジニアであれば、サービスの成長とともにデータベースの性能問題に頭を悩ませた経験が少なからずあるのではないでしょうか。
データベースは、大量のデータを確実に保存してすばやく取り出せる魔法の箱ですが、種も仕掛けもある魔法の箱です。魔法の箱をうまく使ってみせるには種と仕掛けをちゃんと理解していることがとても重要だと思います。
この本では、データベースがどういうデータ構造でデータを保持して、どういう性質を持っていて、どういうことが得意で、どういうことをすると性能上の問題があって、どうやって解決するかの指針を得ることができると思います。
この、どういう問題があって、どうやって解決するかの指針は、日々データベースの性能問題に取り組むWebアプリケーションを運用しているエンジニアにとって、とてつもなく実践的な内容だと思います。
また、まだ本格的なWebアプリケーションの運用をしたことがない人にも、将来Webエンジニアを目指すなら是非この本を手に取ってほしいと思います。
データベースの性能問題は、それが問題になりだしてからの対策は非常に難しくなるので、データベースで起こる問題をあらかじめ知っておくことは将来のあなたをきっと助けてくれるはずです。
ということで、下のリンクから買っても僕にちゃりんちゃりんいかないけど是非読んでみるといいと思います！
![Webエンジニアのための データベース技術[実践]入門 (Software Design plus)](http://ecx.images-amazon.com/images/I/5135c8BBslL._SL160_.jpg "Webエンジニアのための データベース技術[実践]入門 (Software Design plus)")
Webエンジニアのための データベース技術[実践]入門 (Software Design plus)
ふだん仕事とかで自動化とか最適化ってことばはあまり使わずに、省力化とか効率化ってことばを使うようにしてる。
なんというか、思い描く本当に自動化された理想の姿からすればぜんぜん自動じゃないし、最も適したと書いて最適化だけど、いまの自分に考えうる最高の姿が最適だと思えるほど自信家でもない。
それでも自分の心に反して自動化とか最適化ってことばを使ったほうが、よくわかってない人向けには耳障りいいのかなーと思わなくもないけど、自分の心に反してるので僕にはすこし勇気が必要なことであったりする。
ドキドキがハンパない
仕事の話をしてるときに「でも」っていわれるとめちゃくちゃむかつくので、少なくとも自分は「でも」って言わないようにしてる。
相手のいうことを否定するなら「でも」なんて使わずに率直に「それは間違ってる」「それは正しくない」と言って自分の考えを言えばいいだけだと思ってる。
レガシーシステムにテストコードがないことはどこにでもよくある話だと思いますが
いろんなところでテストと名のつくことばが出てくることでなんとなくテストしてる風のふいんきがかもし出るのが僕はずっといやだなーと思ってた。
なのでテストといってる人がいても僕は意図して別のことばに言い換えるようにしてきてた、以下のような感じで。
テストサーバ -> 開発サーバ
テスト環境 -> 開発環境
テスト用DB -> 開発用DB
去年、それなりの人数でフルスクラッチで新規開発するプロジェクトがはじまったときに、既存のプロダクトでみんなが不満に思ってることクソだと思ってることを、ここではみんながこうするのがいいと思う方法でやっていこうってことで、テストいっぱい書いたりフロントエンドをRailsでやったりしてる。
そのなかで「テストしてないのにテストいうのおかしい、これは目視してるだけや！」から生まれた目視サーバというのがちょっとウケる感じで僕は気にいってる。使い方は「さっきの修正したやつ、目視にデプロイしました。」って感じ。
もしテストしてないのにテストいうのおかしい思ってる人がいたら、目視つかってもいいですよ。
