PakuReserve( パクレゼルヴ ) R&D Laboratory

こんぬつわ。かーつんです。

皆さん報連相ってご存じですよね。
報告・連絡・相談のビジネス基本３原則みたいなものです。

大きく言うと企業レベル、小さく言うとプロジェクトの各チームレベルで
これらがまともに機能しているのと、そうでないのとでは運営や進行に雲泥の差が出ます。

まぁ報連相それぞれタイミング的なものがあるんで、
報連相を行う相手次第で間を考える必要があり、
いきなり完璧を求めても無理だと思われるわけですが、
報連相を行うときに自分で意識して行っているか。というのがポイントです。

以下にどういうときに行うべきなのか、抜粋して書いてみたいと思います。 

【報告】「主に部下が上長に対して行う」
・(決定事項に対し)変更が生じたとき。
　　⇒　これを怠ると、上長の現状把握が遅れ、結果的には
　　　　　自分にその遅れた分の時間短縮が求められることが常です。
・結果報告(長期場合は中間報告)
　　⇒　現在までの作業が終わり、次の作業指示を仰ぐ場合や、
　　　　　現状の進捗具合を知らせることでアドバイスを聞き出す時などに使います。

【連絡】「主に上長から部下に対して行う」
・情報共有
　　⇒　企業又はプロジェクトの決定事項などを端的に伝える。
　　　　　「～だと思います。」とか、「～だったはずです。」と伝えるくらいなら
　　　　　伝えるのを控えた方がよいです。
　　　　　曖昧な連絡は誤解を生み、
　　　　　後々「あのときこういった。」とか、「こんな風に受け取ったんだけど。」という
　　　　　トラブルの温床になります。

【相談】「相手はまちまち」
　　一番タイミングを計るのが難しいと思います。
　　しかし、一番重要ともいえます。
　　自分が詰まったとき、問題が発生してしまったとき、
　　定義が曖昧なだけに行いにくいとも思いますが、
　　自己解決したと思いこむこと程恐ろしいことはありません。

　　人の動きから学ぶのが一番だと思いますが、
　　適度に取り入れることにより自分の間違い・勘違いに
　　気づくことが出来たり、情報の精度を高めることが出来ると思います。

　　但し、忙しそうな相手にちょっとしたことを頻繁に聞くと
　　確実に嫌われたり怒られたりするので、
　　ある程度まとめて一度に質問したり、
　　一度聞いたことは二度聞かずにすむようにメモを取りましょう。

とまぁ、こんな感じで、報連相を実施することで、
運営や進行をスムーズに進める事が出来ると思います。
細かい方法は企業やチームで風土があると思いますので、
臨機応変に。と言わざるを得ないですが、
「明らかに間違ってる！」という風土が出来ているようなら、
容赦なくブチ壊してしまいましょう。

基本に忠実に且つ臨機応変に、
自分たちに合った報連相を策定していくことが、
成功の秘訣ともいえると思います。

報連相。何それ？みたいな企業は、
早々に辞めてしまうのが得策かもしれませんね。

以上。か＾－＾つんがおおくりしました。

かーつん Tips, その他

チョコボールです。

WEBアプリ開発においてはLAMP(Linux、Apache、MySQL、PHP)が中心ですが、モバイルコンテンツ開発がメインと言っても管理画面系は基本的にPCから操作します。
ということは、JavascriptやAjaxも扱えた方が当然アツい訳です。

プログラミングを始める前まではJavascriptはネットで拾ってきてコピペで使っていました。
使うケースが増えてきたのでこれを期にちゃんと身につけようと思って地味に勉強中です。
Javascriptについて書きたいのですがまだまだへっぽこですのでまた今度。。

今回はCSS(Cascading Style Sheets)について。

開発担当の自分はCSSは業務ではあまり触れることはないのですが、面白いので個人的に勉強してます。
綺麗なMVCモデルのWEBアプリ構築を目指してる自分としては、Vもさらに分けたいという欲求も自ずと出てくるものです。

数年前に流行りかけたテクニックらしいのですが、
『フォントサイズをピクセル単位のように直感的に相対指定する技』

たまにソースを覗くと、このような指定を見かけることがあります。

body{ font-size: 62.5%; }

一つのサイトならまだしも、他のサイトでも同じ62.5を多く見かけました。
最初はなぜ62.5%なのか！？って感じで謎でした。

こう指定することにより、ブラウザ上でフォントサイズを12pxの大きさで表示させたい場合は1.2em、14pxの大きさで表示させたい場合は1.4emのように直感的に指定すれば、ブラウザの設定でデフォルトのフォントサイズを変更してなければ、たいていの場合は望み通りの表示になってくれます。
現在、ほとんどのブラウザで大丈夫のようです。

そのメカニズムは…

現在広く使われているブラウザの殆どはデフォルトのフォントサイズが16ピクセル。
もしデフォルトの文字サイズが10ピクセルになっていたとすれば…と発見者は考えたようです。

16ピクセルを相対指定で10ピクセルに変えるには

10÷16＝0.625

body要素に62.5%として指定すれば、先に示した通り、直感的に指定できることになります。

デメリットも有りますが、便利ですね。

MoriMoriMoriMori HTMLとか, Tips, その他

新規サービスオープンのため対応中。姜子牙です。
本体のネタ以上にこの冒頭のネタを練りこんでいたりすることがあります。

2/22のエントリでバックアップについて記載しましたが、今回はバックアップ第二弾を書きたいと思います。

さて本題、バックアップは何重に取るべきか？

バックアップの対象となるデータをマスタデータと呼んだ場合、それを一つコピーしてバックアップすると1重とします。
私は基本は2重に取るようにバックアップは設計しています。1重ではやや不安で、3重だと余剰だろうと考えています。
2重の場合、マスタデータ含めて3つ同じデータが存在することとなります。

ここでのポイントは「このバックアップでマスタデータが何個分存在することになるか」です。

よくあるのが、AというディレクトリのデータをBというディレクトリが常に同期していて同じデータが入っているのに
AもBもバックアップに含めてしまう、ということがあります。
これだとマスタデータはAのディレクトリのデータなのに、Bのディレクトリ、Aのバックアップ、Bのバックアップという形で
4つも存在してしまうことになるわけです。

多ければ多いほどデータの消失確率は減りますが、逆にその分ディスク容量を圧迫することになります。

なので、私の場合、上記A・Bのディレクトリがあった場合、Aはバックアップ対象としますが
Bはバックアップ対象から外すように設定をするわけです。
こうするとAディレクトリ、Bディレクトリ、Aのバックアップでマスタデータ3つ分というわけです。
まあ、他の同期していないデータとかと一纏めにする都合でAバックアップのコピーが生まれるので
データ4つになっちゃうんですけどね・・・。

もう少し具体的に言えば
更新系を司るマスタデータベースがあって
それのホットスタンバイであるスレイブデータベースがあって
マスタ・スレイブそれぞれでバックアップ取って
さらにそれぞれのバックアップを2重化したりすると
データ6つ分になっちゃったりするんですよ・・・。
いや、うん直さないといけないですけどね・・・。

やや余談になりますが、
サーバがRAID1の場合、その時点でマスタデータが2重だからバックアップ1個取れば3重と言えなくもないですが、
私個人の考えとしてRAID1でコピーされるデータはバックアップとみなしていません。
あくまで、HDD物理障害対策の機構であって明示的なバックアップではないと考えているからです。
|-’) HDDが無事でもRAIDのカードやチップが往生してしまうこともあるし・・・。

まあ後半はやや個人意見だらけなので、こんなんあるんだ程度としておいて頂いて
バックアップを設計する時は一度マスタデータが何個分になっているか意識してみると良いかもしれません。

[Mr.マカー](#ﾟДﾟ) < 「で、バックアップサーバどうすんの？」
[姜子牙]（;’-') < 「あ、えーと今のサーバのディスク枯渇するまでもうちょい時間あるので検討します・・・。」
[べきこ] (´ー｀) < 「時間経って忘れてると大変なことになりそうだね」
[姜子牙] ∑(；’-') < 「ドキッ」

はい、冗談にならないです。

姜子牙 Linux, Tips, その他

メールサーバと格闘中です。姜子牙です。
涙目です。

さて今回はMySQLのチューニングについて書きたいと思います。

チューニングと言ってもMySQLはコンフィグファイル(my.cnf)を変更する方法とは別に再構築（コンパイルし直す）という方法があります。不要なオプションを削ったり、逆に組み込んだりすることで機能を追加したり、処理速度を上げることができるのです。が、まだ再構築の方についてはお世辞にもここに書けるほど把握できてないのでここではmy.cnfの変更でできることでチューニングをしてみたいと思います。

まず、以下が現在DBサーバに施してあるチューニングに関わる設定部分です。

#For MyISAM Table Global Buffer
set-variable = key_buffer_size=256M
#For InnoDB Table Global Buffer
set-variable = innodb_buffer_pool_size=256M

set-variable = query_cache_size=64M
set-variable = table_cache=128

key_buffer_sizeとinnodb_buffer_pool_sizeはそれぞれMyISAMとInnoDBでのアクセスの際に使用されるキャッシュメモリになります。
現在DBにはそれぞれのDBエンジンを使用したDBが稼働しているため、両方にそれぞれキャッシュメモリ256MBを割り当てています。
もし、MyISAMやInnoDBどちらかだけであれば、設定はどちらかだけでOKです。
またクエリのキャッシュに64MB、テーブル(テーブル単位でのキャッシュ)に128個分のキャッシュを割り当てています。

テーブルのキャッシュはテーブル数単位で、明確に何MBなどは指定できないようです・・・。

今回はこれらの設定のみとしていますが、もしDBが参照系(Select文)が多いとか、逆に更新系(Insert文・Update文など)が多いなど
特徴がある場合には、read_buffer_sizeやsort_buffer_sizeなどにキャッシュを割り当てるとさらに速度向上が見込めます。
しかし、上記の設定は1クエリごとにいくつのメモリを割り当てるかの設定なので
平均のクエリの発生頻度などを考慮しないとメモリを食いつぶしてしまうのでご注意ください。
(key_buffer_sizeなどは全クエリ共通の領域として設定されるため、上記設定だと全体共通で256MBを使用するという設定です)

また、key_buffer_sizeとinnodb_buffer_pool_sizeについてはキャッシュのHIT率を測る方法があるため、それを今回は
チューニング効果の指標として使用しました。
MySQLのStatusで取得できるKey_readsとKey_read_requestsをKey_reads/Key_read_requests で求めるとキャッシュミス率が出ます。

弊社のDBサーバはチューニング前はHIT率が99.3%でしたが、チューニング後からは99.7%～99.8%になっています。
どこかのブログでは99.7以上が目安と書かれていたため、効果はまずまず・・・と言ったところでしょうか。

まだまだ設定できる項目は多く、その中をよく調査するともっと処理性能を向上させることは可能かもしれませんが今回はまずこのくらいで留めています。

3部に渡って書いたチューニング編ですが、サーバ側だけでできるチューニングには限界があります。
ApacheにはPerlやPHPのコード、MySQLにはSQL文によっても負荷が左右されます。以前にも少し書いたとおり、サーバ担当ですべて把握できれば良いのですが、規模が大きいほどそれは難しくなり少なからず開発のPGやSEと協力して行うことが重要になります。

自分の作業範囲で掘り下げられる部分は掘り下げ、範囲の外になってしまう部分はその範囲の担当に協力を仰ぎましょう。

サーバは乗っかるアプリ全部に影響を与えるため、担当者間調整だったり、コミュニケーションが重要になってきます。学生の卒業年度にやった性格診断で社交性が最低レベル(5段階評価の1)を記録した私がここまで出来ているためその重要性を意識していれば、コミュニケーション苦手っていう人でも苦手克服くらいはできるんじゃないかなと思います。

[かーつん](#ﾟДﾟ) < 「何キレイに〆てんだよ」
[姜子牙](*’▽’) < 「たまにはいいじゃないー」
[SELLCA](￣ o￣) < 「でも結構ダークですよね」
[姜子牙](；’-') < 「う、痛いところを・・・。」

ダークではないですよ。

姜子牙 MySQL, Tips, その他

はい、ボクです。

FLASHについて困ってます。
ページ→FLASH→ページの推移で、FLASHでセッションが引き継げないためにセッションが切れてしまうのです。
どうしたものかと思い、実行したのが、FLASH解析してバイナリにセッションを埋め込めばいいんじゃね？という結論に。
しっかしそれは、いちいちファイルを展開してバイナリ改ざんしてごにょごにょしなくてはいけないので、サーバーへの結構な負荷になりそうなので他の方法を。。

今回はセッションさえ引き継げればよかったので、ModRewriteでURLを静的なものにしてFLASH上から相対パスで飛ばしてあげることにしました。
ModRewriteはSEO対策でよく使われる手法で、動的なURLではクローラーに拾ってもらえないものを、静的なURLにすることにより拾ってもらえるようになります。

やり方としては、Apacheまたは.htaccessで設定します。
以下は.htaccessでの方法。

RewriteEngine On
RewriteBase /

RewriteRule ^(.+)/(.+)/$ ?aaa=$1&bbb=$2 [L]

上のコードで、
http://example.com/index.php?aaa=100&bbb=200
のURLが、
http://example.com/100/200/
になるかと思います。

こんな感じで〆

下音タヌキ PHP, その他