最近やっている開発環境のDataBaseを本番に近づけるやり方
開発用DataBaseを本番と近づけれれば嬉しい。
ただ、仕事のサービスだと結構データ量が多いので実質不可能で辛い問題をなんとかしたいのでここ最近あがいてみたのでなんとなくの範囲でメモってみる。
前置き
ちなみに有名なのはクックパッドの例
開発環境のデータをできるだけ本番に近づける - クックパッド開発者ブログ
これ素晴らしいんだけど、金が結構掛かったりするし本番DBに開発環境から接続できる状態になりそうなので個人的には結構怖かったりして、ちょっと微妙。
それにネットワークつながらない所で開発できないのもいざという時はちょっとヤダ。
となると、ローカルなり共通で使用するDBを用意してそこに本番と同じDBがあれば良いのだけど、やっぱりデータ量で死ぬ。
ちなみにMBPにリストアした時は、3,4日ほど使った。そしてHDD容量の残りはほぼ余裕が無い状態orz。
うーん、悩ましい。
リストア方法
色々考えた結果本番DBのダンプからフィルタリングしてデータ量に制限掛ける方法を採用した。
DBやテーブルについて
本番にデータを合わせるだけでは落とし穴があります。
例えば、カラムの順番だったり、mysqlだとハハパパ問題とか。
Railsのようにmigrationも管理していれば問題なさそうですが、手動でALTER TALBEとかしてませんか?
DataBaseサーバのバージョンは一致してますか? 本番はmysql5.6で開発環境は5.5とかになっていれば最悪バグがでるかもしれません。
きちんと本番と開発環境が同じになっているかをチェックしましょう。
ハハパパ問題だと最悪リストアができないかもしれません。
dump & download
dumpは予め行っていたので今回は何もしなくても良かったです。
scpでダウンロードに1時間ほど。
ただしdump時にこのオプションをつけること。(mysql)
--complete-insert --single-transaction
できれば、テーブル毎に分けてdumpしていれば扱いやすいとは思う。
DBを一括でdumpしているなら自前でテーブル毎に別ファイルに分離すれば良いだろう。
フィルタリング
まず、不必要なテーブルは必要ないので無視の方向で。ログのようなデータとかどう考えて開発時には必要ないし。
あと、ユーザデータとかローカルですぐに作れるデータも無視で。
次に必要なテーブルでもデータ量はかなり多い。サービスによるけど毎日データがどんどん作られるようなタイプだと半年以上前のデータなんか必要ないだろう。
そういうテーブルはtailとかで最新のデータだけ採用すればよい。
問題は関連テーブルだ。適当に数を間引けば良いという問題ではない。
日付でもフィルタリングを行うという手もあるが、どうしても関連テーブルが抜けて動作に支障をきたす場合もあるだろう。
なので、レストア後に問題のあるデータの削除も必要となるかもしれない。
結果
最終的に3時間程度で本番データに近い環境を作ることができた。
処理データ量は違うので、処理速度などはあてにはならないがそこはコードやSQLを見れば判断できるだろう。できないエンジニアは勉強しましょう。
問題は定期的に本番データと一致させないとダメなので、復旧作業を定期的に行う必要がある。
ここはまだ考えていなくて、まあ1ヶ月に1回とかで復旧すれば良いかなぁとは思っていますが、運用初めたばかりなので正直どうなるかは分かりません。
とは言え開発時に"あああ"とか意味不明なデータを見ることがなくなったので、十分かなぁとは思っています。
Excelの仕様書がダメな理由
最近は暑さに参っています。子供の頃の夏はもっとマシだったと思います。
冬はまだですか?
Excelを始めとしたOffice系のドキュメントは総じてダメです。
なんでもExcelで作るのは何故なんでしょうね。
技術力が高いエンジニアでもここに違和感ない人もいて信じがたい状況です。
とは言え今まで言語化するのも難しいし、代替の方法も特に思いつかなかったので自分も同じ穴のムジナという所ですが。
ただ、最近はこの辺り大分整理出来てきたのでここで公開しておこうかと思います。
そもそもバイナリファイルなのがダメ
最近はgitを使った開発が多いとは思いますが、バイナリファイルの管理が非常に面倒くさいです。
コンフリクトが発生したときなんかはdiffを見てもさっぱり分からないですしね。まあWeb開発とかだと画像ファイルとかも面倒ですけど。
更には通常の開発はUnix系OSなので、grepやvim/emaxcなどのエディタを含めたunix系ツールとの相性も最悪です。
Excelは表計算ソフトだからWordにしろという主張も見かけます。
まあ、多少は良くなりますがバイナリなのでやっぱりダメダメです。
データとデザインが一緒になっている
非エンジニアからするとこういうのが受けているのでしょうが、HTMLとCSSに分かれているように、そもそも異なる概念を1つの書き方で表現しようとするのが間違っています。
こんな事すれば、書くのが大変になるに決まってるじゃあないですか。
最近はgit/githubでの開発が一般的になってきています。
githubだとMarkdownでかけば自動的に綺麗に表示してくれるので、デザイン部分は考えなくて良いです。
テキストなので、unixツールとも相性が良いですし。
ドキュメントでデザインしたいなら、HTMLとかでベタ書きしたりWiki使ったほうがよっぽどましです。
過去のバージョンへ戻すのが大変
10年前とかの開発でもcvsを使って開発とかは普通にしていましたが、ドキュメントも一緒に戻すのが非常に大変でした。
当時の一般的なドキュメントはOffice系で仕様書を書いて、バージョン毎に別ファイルで共有フォルダに置いて、コードはcvsとかでした。
Word自体でバージョン管理する機能もあるのですが、当時使っていて最終的にファイルが開けなくて色々終わった経験もあります。そもそも1ファイルでバージョン管理なんかするのが無茶ですよ。
これでも管理出来なくは無いですが、コードと仕様書を一致させるのが非常に困難です。
過去の任意の時点での仕様書を見るのが本当に大変。
cvsに入れれなくも無いですが、やっぱりバイナリなので色々難しい。
GitHubを使った開発パターン的なのを妄想している
プロジェクトの状況にもよるんだけど、ドキュメントがなかったり、管理側の知識がなかったり、経験値が少ない人が多かったり色々ある。
コードがドキュメントで動けるプロジェクトだといいんだけど、現実はそうは行かない。
最近はGitHubを使った開発が多くなってきたので、GitHubを前提にした開発方針でもいいんじゃねと最近は思っている。
Gitlabを使っているとか色々なパターンとか色々あるけどまあそこは誤差としておく。
ともかく最近はGitHubでの開発パターンというか開発スタイルというかを考えていて、WIPとか個別での手法はあるんだけど全体としてまとまっている情報って見たことがなくて、もやもやしていてまとめてみる。
ちなみに、RailsでのWeb系を前提に書くけど分野関係なく通用するはず
基本方針
できるだけ楽をする方向で。
ただし、目の前の楽だけを追えば死ぬので、技術的負債を意識すること。
ブランチ
git-flow,git-hubflow等なんでも良いけど、ブランチの運用方法の方針を決定したほうが良い。
できればツールを使った方が楽。
WIP開発
WIP開発を採用する。
将来もっと良いのが出てくれば変更しても良いけど。
WIPなので当然コードレビューも入る。
ある程度チーム全員でコードレビューをして、全員がまんべんなく知識を共有している状態なのが望ましいと思う。
ドキュメント
ドキュメントをgitで管理する意義
ドキュメント(固い言い方をすれば仕様書)はできるだけGitHub上にMarkDown形式で保存しておく。
ドキュメントの役割は色々あるけど、なんとなくこのあたり
- 将来作るべきモノの管理
- とある時点での全体を俯瞰して確認できること(本来あるべき形と現状の姿)
- 無駄なコミュニケーションの排除
- 引き継ぎとかその他色々
思い返してみるとドキュメントって固いプロジェクトだと当然あるけど、そういった現場でもソースコードとドキュメントの同期、履歴管理ってほぼ出来ていなかったように思う。
そこでgitでソースコードとドキュメントを同時に管理すれば上記問題はほぼ解決するはず。
MarkDownなので文法は簡単だし、grepでもなんでも好きに検索もできるはず。
手動ドキュメント
多分2種類あるはず。
- 本来あるべき姿を書いたもの(いわゆる仕様書)
- 環境構築、コーディング規約とかの開発のヘルプ的なもの
どう転んでも手動で書かざるをえないので書くしか無い。
ただ、頑張り過ぎても管理が大変なので重要な部分の考え方とかその辺りだけにしておいたほうが無難。
最近だとドキュメントを書く事自体が嫌なのか用意しない場合が多いので、一度書いたらほぼ更新する必要がないように
あと、Changelogはあったほうが良いかも。
gitで特定の過去に戻れてもその時点での全体で何を作ったかを簡単に把握するのは多分難しい。
極端な例をだすとLinux Kernelとかgitで戻ってもChangelog見ないと何を目的の修正かまず理解できないと思う。
ただ、テストコードと同じで時間はそれなりに使うしメンテナンスも必要なので、時間を見て重要そうな部分から始めれば良い。
MarkDownだと単なるテキストなので、某Office的なソフトを使うよりもデザインを気にせずに作成できるはずなのでさほど時間はかからないはず。
自動化ドキュメント
現状の姿をドキュメントにまとめる必要がある。
ただこの辺りって昔から自動化の方向で来たので、その流れに従って自動化しておいたほうが良い。
最悪見る人が少なくても無いよりよほどマシ。
ソースコード
YARDとかJavaDocとかその辺り。
コメントでドキュメントを書くので、出力するドキュメントを見なくてもエンジニアだとコードを読む場合でも理解しやすい。
ただ、こういったツールはHTMLで出力するパターンが多いのでgithub上だと確認しづらいのが難点。
そもそもhtml+cssで表示する内容とデザインを分けたという歴史があるのに、なぜわざわざドキュメントをhtmlで出力するのかがよくわからない。
表示を整えたければ、テキストに出力してからHTMLやpdfに出力するという方向で良いのに...
RMDB
Webアプリだと多分いちばん重要(な気がする)。引き継ぎをきちんとしていないと、このテーブルのこのカラムの使い方がわからないとか色々でてくる。
Rails + gemだとrails-erd, schemadocあたりが良い。ER図(pdf)の作成、スキーマをjsonで吐き出してくれる。
annotateを使えば、スキーマをmodelの先頭に追加してくれる。
ただ、schemadoc,annotateはスキーマを吐き出してくれるだけで意味がわからない。ER図は必要だけど意味までは理解できない。
ということで、migration_commentsでDBに直接テーブルコメント、カラムコメントを追加している。
ちょっとしたスクリプトを作れば、スキーマとそれぞれのコメントをドキュメントに出力するのは簡単だ(良いgemがあれば良いのだが知らない)。
WebAPI
autodocというgemがある。
https://github.com/r7kamura/autodoc を見ればわかるが、specを書けばAPIのドキュメントをMarkDownで生成してくれる。
すばらしい。
上記以外のデータストア
KVSなりSolrなり何でもよいが、このあたりは対応方法を思いついていない。
今後の課題だ。
自動化
もう一般的だけどjenkins使えばgithubとの連携が出来る。
使わない手はないはず。設定が面倒だけど...
ドキュメントの自動生成、spec、デプロイ、lint、rubocop、bugspots、セキュリティチェックとか色々できるはず。
テストが書けない or 書きづらい分野とかはまだまだあるので、そういった部分はどうするのが良いんでしょうね。
Webだとデザイン崩れとか、組み込みだとハード前提なので色々厳しいとか。
インフラ周り
最近はchefのようなツールがだいぶ一般化してきている。
インフラもgitで管理できるのでこの方向で頑張ったほうが良いはず。
他にも色々要望があるかも。
できれば面倒な事は自動化して、何回も同じ事をする場合はドキュメントなりプログラム化するなりすれば無駄が省けるはず。
EIZOのモニタ(EV2455)を買った
7年ほどぶりにEIZOのモニタを買い替えた。
ちなみに前のモニタはS2031W。
購入動機はさすがにHDMI無しはつらいのと、かなり古くなってきたので。
購入候補はこのあたり
- FORIS FS2434
- FORIS FG2421
- EV2450
- EV2455
FORISは前から気になっていたのだが、ちょっと横長だしそこまでゲーマでは無いので見送り。
最後まで迷ったのはEV2450とEV2455。値段を考えればEV2450なんだけど(3万ほど違う上にモニタ2枚使いなので6万)、画面サイズはEV2455。
あとEV2450はMac Book ProとつなげるとHDMIでの表示が出来ないという話も気になった。
ということで、7年ぶりの購入だし多少の事は目をつぶってEV2455を選択。
所感
モニタがかなり薄くなって、軽くなったのが素晴らしい。
モニタの縁部分がかなり少なくなったのでモニタを横に並べても違和感がかなり少なくなった。
後、モニタの設定ボタンが物理ではなくなった。触れただけで反応するがちょっと暗い場所だと微妙。
LinuxでBluetoothヘッドホンを接続する
先日Amazonでタイムセールで見つけたので勢いで購入。
Linuxなのでいつものごとく設定を多少頑張る必要がある。
ちなみにOSはMint Linux。debian系だとほぼ変わらない気がする。
設定
まずは、接続に必要なソフトをインストールする。
LinuxでBluetoothを使用するのには実質BlueZだけが必要なようだ。
BlueZはどうやらプロトコルスタックを担当するらしい。
$ apt-get install bluez
次にBluetoothを接続するGUIのツールを入れる。
gnome-bluetoothがGNOME用、bluedevilがKDE用らしい。
とりあえず、初めてなので両方を入れてみた。
$ apt-get install gnome-bluetooth $ apt-get install bluedevil
最後にヘッドホン関係だ。
ALSAではbluetoothが使えないらしくpulseaudioを入れる。
pavucontrolはGUIの音量コントローラだ。
$ apt-get install pulseaudio pavucontrol
Bluetoothを認識させる
Bluetoothは普通に認識した。
Bluetoothはhcitoolで確認出来る。
$ hcitool dev
Devices:
hci0 00:1B:DC:06:82:5C
ペアリング
次にヘッドホンを接続(ペアリング)する。
GNOMEならばbluetooth-wizard、KDEならばbluedevil-wizardでGUIツールが起動する。
ヘッドホンを通常通り接続モード?的なのにして検索すれば認識するはずだ。
$ bluetooth-wizard $ bluedevil-wizard
ちなみにペアリングを切るのも簡単
$ pulseaudio -k
音が出ない場合
どうもこのままだと音が出力されないようだ。
いかの方法でうまく行った。
- pavucontrolを起動する。
- 設定タブからヘッドホンを"ハイファイ再生"に設定する。
- 再生タブから再生しているアプリケーションの出力対象をヘッドホンにする
追記 2015-04-28
音を出すアプリが存在していない状態があると、時々ヘッドホンへの出力されなくなる(音がでなくなる)場合がある。
原因不明だがちょっと不安定だ。
Google版アプリをTitanium mobileで出したので振り返り
2014-12-01 - longicornの日記 の続き
最近Google版もアプリ出したので感想を。
前回と同じくアプリ自体やビジネスとかには言及しません。
基本的には前回と同じスタンス。ツール系アプリでスタートアップで色々余裕ないけど、それなりに動くのをiOSとAndroidで両方出したい的なのにはやっぱりすごく良いなぁと。
Titanium mobile以外だとRuby motionか最近だとC#が使えるという発表もあったけどそういうのになるのかな? MSのC#がどの程度使えるかは知らないけど。
ハードウェアやOSに依存する部分以外については、アルゴリズムがそのまま動くので非常に楽です。例えばAPI通信の結果でどう描画するかとかそういうの。
でも、ハードウェアに依存する部分は色々大変。外部moduleを探してきたり、場合によっては自分で作ったりしないとダメ。
当然だけど、その違いを吸収して自分でライブラリを書ける力が無いと死にますし、簡単にクソコードが出来ます。
それ以外だとデザインとかAndroidだとハードウェアボタン対応とか細かいところが色々大変。
上っ面は簡単そうにアプリが作れそうだけど、いざとなったら容赦なく腕が必要です。下回りが見えないから逆に怖い。
スタートアップでそれなりにだと良いと書いたけど、逆に言えばある程度を超えると色々厳しくなってきます。
結局はネィティブで作り直しが必要だとは思います。動作速度や自由度が全然違うしね。
ということで、こういう開発ツールってプロトタイプとか初めにそれなり楽しつつ後で苦労を覚悟する場合に使うべきで、それ以外だと初めからネィティブを使うのが正しそうです。
ああ、あとiOSは64bit対応が必要なので更新されてない外部moduleを使っている場合は大変なので注意してくださいね。
