株式会社シャノン技術ブログ

オライリーさんの『Jenkins』（通称カエル本）に寄稿しました

2012-02-29T15:55:00.000+09:00

こんにちは。ikeike443です。せっかくの閏年なので投稿してみました！
ちなみにこの記事は私の個人ブログと同内容をクロスポストしています。ご了承ください。

寄稿しました
去る2月22日にオライリー・ジャパンさんから発売された『Jenkins』（通称カエル本）に、縁あって寄稿させていただきました。
”付録B プラグインの開発”という記事です。
帯にも記載されているとおり、Play! frameworkプラグインを例にして、プラグイン開発について簡単なチュートリアルを書かせてもらいました。

正直、Playみたいな（新しいけど）マイナーなフレームワークを題材にしていいんですか、という疑問があって、お話をくださった訳者の玉川さんには何度か確認したのですが、ぜひPlayで、とのことだったので、思い切って書かせていただきました。
ぜひ、手にとってお確かめください！

初心者から上級者までカバーする決定版
さて、この本は、先に出版された技術評論社さんの『Jenkins実践入門』と比較すると、中級者むけのやや難しい本、という紹介がされているようです。
ですが、私はそうは思っていません。
確かに、第2章の初めの一歩という章でいきなりMavenとGitが出てくるのは、日本のIT業界の現状を考えると厳しいかも知れませんが、インストールの仕方について説明は書いてありますし、Jenkinsを手にとって読もうと考えるような人（プロジェクトのリーダーだったり、ライブラリアンだったりリリースマネージャーだったりする人）であれば、仮にMavenやGitに馴染みがなくても、何とかできると思います。

この本は、初めてJenkinsに触れようとしている方や、継続的インテグレーションって聞いたことあるけどなんのことだっけ、という方のために、まず第1章でJenkinsと継続的インテグレーションについての概説から説き起こしてくれます。
目次についてはこちらを参照してください。（目次タブをクリック）

とりあえずJenkinsについて知りたい人は第2章まで、さらに第6章まで読めばかなり分かる
続く第2章ではとりあえずJenkinsをクイックに起動して一通り試してみるための方法について触れています。第3章では、各種OSにおけるJenkinsのインストールの仕方、Apacheのリバースプロキシの設定の仕方、TomcatなどJEEアプリケーションサーバでの動かし方、といったサーバの設定にもページを割いて丁寧に説明しています。
第4章ではJenkinsのシステム設定について、第5章ではビルドジョブの設定、第6章では自動テストの設定の仕方、コードカバレッジをとる方法、JMeterを使ったパフォーマンステストなどについて詳しく丁寧な解説があります。

初めてJenkinsに触れるという方は、第2章まで読めば、とりあえずJenkinsを動かして、一通りの流れを試すことが出来ます。まず概要を掴むには第2章までで充分です。
さらに第6章まで読めば、サーバのセットアップからビルドジョブの設定、自動テストのやり方までひと通り学ぶことが出来ます。
このように、ステップバイステップでJenkinsに慣れていくことが出来るように書かれています。
かなり丁寧に書かれているので、この本を読みながら設定すれば、きっと動かすことが出来るはずです。

セキュリティについての第7章、通知のバリエーションについてやたら詳しくなれる第8章
さらに、第7章ではセキュリティ、ユーザー権限管理についても詳しく説明があります。大きな組織でテストやリリースを管理されている場合、この章はかなり役立つのではないでしょうか。
第8章ではメールやIRCなどによる、ビルド結果の通知について掘り下げています。このあたりからこの本は少しずつマニアックな面を見せてきます。メールで使える変数の解説はもちろん、デスクトップ通知やSMSへの通知について触れ、ビルドラジエータという概念についても説明し始め、さらにはSoundsプラグインやSpeaksプラグインを使って、ビルド結果を音を鳴らしたり、コンピュータにしゃべらせて通知するなんていう方法も教えてくれます。（こんなの知らなかった。。）
さらに、XFDについても触れていて、お約束のNabaztagをフィーチャーしています。
Jenkinsによってテストやビルドを自動化していても、成功や失敗の事実をきちんと人間がキャッチできなければ意味がありません。
通知について1章を割いて熱く語るのもわかるなー、という感想をもちました。
特に、成功ビルドや失敗ビルドをまとめてメンバーの眼を引くような場所に（大型ディスプレイなどに）映しだしておく、というビルドラジエータという方法はいいなあと思いました。

徐々に高度に：ビルドプロモーション、分散ビルド、継続的デリバリ
第9章でCheckStyleやFindbugsといった静的解析ツールについて触れ、Sonarとの統合について説明した後、さらに高度な内容の説明に入っていきます。第10章ではパラメータ化ビルドジョブやマルチ構成ビルドジョブについての詳説、並列ビルドやビルドパイプライン、ビルドプロモーションといった本当に高度な、しかし大きなプロジェクトを成功させようと思ったら必ず必要になる知識が山盛りになっています。
第11章はJenkinsの分散ビルドについて詳しく知ることが出来ます。EC2プラグインや、CloudBeesのDEV@Cloudについても説明があります。プロジェクトが成長してスローテスト問題が顕在化してくると、複数ノードを使った分散ビルドを検討するようになります。分散ビルドがかなりイージーにセットアップ出来るのもJenkinsの特徴ですよね。
第12章ではさらに一歩進んで、デプロイの自動化と継続的デリバリについて触れられています。Mavenリポジトリへのデプロイや、アプリケーションのデプロイについて触れています。デプロイで問題になるのはアプリケーションの更新よりもデータベースの更新（スキーマの変更や出荷データの更新）だと思いますが、このあたりは軽く触れられているだけで、まだまだこれからの分野なのかな、と思わせます。継続的デリバリについてはそれだけで一冊本があるくらいですしね。。

メンテナンスについてもフォローしてるよ
この本が素晴らしいのは、第13章でJenkinsのメンテンナンスについてもきちんと目配せしていることです。ディスク使用量の監視やバックアップの仕方、ビルドジョブの移行（別のJenkinsインスタンスへビルドジョブだけを移行する）についても触れています。これは長期間継続的にJenkinsを使っていると必ず問題になるところです。
メンテナンスまでしっかりフォローしているのは本当にさすがという感じです。

付録までついてお腹いっぱい
さらに、付録AではMavenとAntで自動テストを書く方法、付録Bではプラグインを書く方法（僕の記事！）までフォローされていて、本当にお腹いっぱいになります。

Jenkinsについてのバイブル
Jenkinsを初めて使おうとしている人から、今使っている人まで、全てのJenkinsユーザーが常に傍らに常備しておくべきバイブル、それがこの『Jenkins』という本だと思います。

というわけでみなさん、よかったらお買い求めを！

Play! でつなげるWebサービス(XML-RPC/OAuth2.0)

2012-02-24T05:23:00.011+09:00

ごきげんよう　nishino@サポートの人です。

普段はお仕事として弊社サービスに関する問い合わせやトラブルの対応をやっております。

社内外の問い合わせデータを集約したいなーという思惑のもと、今回は弊社で使用しているWebサービスのデータをAPIで取得してみようと思います。

Play!frameworkで各種Webサービスにつながってみる

今回、データの集約をしたいWebサービスは、バックログさんとセールスフォースさんです。ちなみにシャノンさんもAPIでつながることができます。是非つながりたい人は、こちらのSHANON MARKETING PLATFORMをご購入いただくか、右上の「人材募集」バナーをクリック！クリック！してください。

バックログ

http://www.backlog.jp/
nulab社が提供する「楽しくチームで仕事ができる」プロジェクト管理のWebサービスです。
シャノンCRM部および技術部（QA）では、主に社内の問い合わせをバックログに登録し、ナレッジベースとして活用しています。
このブログでも何度か紹介されていますね。
開発者にやさしい環境
クラウド時代のプロジェクトマネジメント

セールスフォース

https://www.salesforce.com/
セールスフォース・ドットコム社が提供する「CRM （顧客関係管理）」のWebサービスです。
シャノンCRM部では、社外からの問い合わせをSalesforceのケースに登録しています。

Webサービスのプロトコル

Webサービスと連携するためのプロトコルはいくつかあります。

XML-RPC
JSON-RPC
SOAP
REST（正確にはプロトコルではなくアーキテクチャスタイル）
OAuth
OAuth 2.0

今回は、XML-RPC（バックログ）、OAuth 2.0（セールスフォース）によるAPI連携を行います。

XML-RPC

XML-RPCは、RPCプロトコルの一種であり、エンコード（符号化）にXMLを採用し、転送機構に HTTP を採用してます。非常に単純なプロトコルで、少数のデータ型やコマンドだけを定義しているだけです。（Wikipediaからの抜粋です）

Backlogは、XML-RPCでAPI連携できますので、さっそくPlay!でつながってみようと思います。

、、とその前に

取得したデータは、前回の投稿「Play! frameworkでつくるスクリーンショット取得サービス」で紹介したcrudモジュールを使って表示します。知らないよ～って方は前回の投稿も覗いてみてください。

モデルはこんな感じです。
hoge/app/models/Data.java

package models;

import javax.persistence.Entity;
import javax.persistence.Lob;
import play.db.jpa.Model;
import play.data.validation.MaxSize;

@Entity
public class Data extends Model {
public String code;
public String question;
@Lob
@MaxSize(4000)
public String answer;

public Data(String code, String question, String answer) {
this.code = code ;
this.question = question;
this.answer = answer;
}

public String toString() {
return code + ":" + question;
}
}

crudモジュールを使用したコントローラはこんな感じです。
hoge/app/controllers/Datas.java

package controllers;

import play.*;
import play.mvc.*;

public class Datas extends CRUD {}

では、話を戻して

XML-RPCをつかって、バックログにアクセスしてみます。
コントローラにbacklog()メソッドを追加します。

hoge/app/controllers/Application.java

package controllers;

import play.*;
import play.mvc.*;
import jobs.*;

public class Application extends Controller {

public static void index() {
render();
}

public static void backlog() {
new ImportBacklog().now();
redirect("/datas/list");
}

}

backlog()メソッドでは、Play!frameworkのジョブ機能を使って、非同期に実行後、/datas/listにリダイレクトしています。
処理の実装はImportBacklog ジョブに記述します。

hoge/app/jobs/ImportBacklog.java

package jobs;

import java.util.*;
import play.*;
import play.jobs.*;
import play.libs.WS;
import play.libs.WS.*;
import play.libs.XPath;
import play.templates.*;
import org.w3c.dom.*;
import models.*;

public class ImportBacklog extends Job {

public void doJob() {
String authorizeUrl = "https://shanonpj.backlog.jp/XML-RPC";
String clientId = "loginId";
String clientSecret = "password";

WSRequest wsrequest = WS.url(authorizeUrl).authenticate(clientId, clientSecret);

Template template = TemplateLoader.load("conf/backlog.findIssue.xml");
Map<String, Object> templateMap = new HashMap(16);
templateMap.put("projectId", "5816");
templateMap.put("limit", "100");
templateMap.put("offset", "0");

wsrequest.body = template.render(templateMap);

Document document = wsrequest.post().getXml();

Map<String, String> map = new HashMap(16);
for(Node node: XPath.selectNodes("//data/value/struct/member", document)) {
String name = XPath.selectText("name", node);
String value = XPath.selectText("value", node);

if(name.equals("key") || name.equals("summary") || name.equals("description")) {
map.put(name, value);
}

if(map.size() == 3) {
// create Data
Data data = Data.find("byCode", map.get("key")).first();
if(data == null) {
data = new Data(map.get("key"), map.get("summary"), map.get("description"));
data._save();
}
map.clear();
}
}
}

}

バックログAPIは、ログインIDとパスワードで認証します（ベーシック認証）。
今回は課題データをごっそり持ってきたかったので、backlog.findIssueメソッドを使用します。
Backlog API:
http://www.backlog.jp/api/method3_4.html

xmlrpcライブラリでさくっと取ってきたかったのですが、なぜかうまくいかなかったので今回はテンプレートを使ってxmlを生成しています。
hoge/conf/backlog.findIssue.xml

<?xml version="1.0" encoding="utf-8"?>
<methodCall>
<methodName>backlog.findIssue</methodName>
<params>
<param>
<value>
<struct>
<member>
  <name>projectId</name>
  <value>
    <int>${projectId}</int>
  </value>
</member>
<member>
  <name>limit</name>
  <value>
    <int>${limit}</int>
  </value>
</member>
<member>
  <name>offset</name>
  <value>
    <int>${offset}</int>
  </value>
</member>
<member>
  <name>sort</name>
  <value>
    <string>CREATED</string>
  </value>
</member>
</struct>
</value>
</param>
</params>
</methodCall>

リクエスト用XMLは、play.templateのrender()メソッドをつかって値を置き換えています。（projectIdとlimitとoffset）
課題データのうち、課題キー（key）と件名（summary）と詳細（description）を取得したら、課題キーをキーに既に登録されていないかを確認して、もしなければDataモデルを新規作成しています。
http://localhost:9000/application/backlog へアクセスすると
こんな感じで、データが取得できました。

OAuth 2.0

OAuth 2.0は、セキュアなAPI認可 (authorization) の標準的手段を提供する認証プロトコルです。（Wikipediaからの抜粋です）

SalesforceのOAuth 2.0接続に関しては、以下の公式サイトに詳しい手順があるので、この通り実装します。
http://blogjp.sforce.com/2011/04/forcecom-rest-a-4182.html

では、さっそくPlay!でつながってみます。

コントローラは、認証用URLとコールバック用URLの２つのアクセスがあるので、新たにsfdc()とcallback()を追加します。
hoge/app/controllers/Application.java

package controllers;

import play.*;
import play.mvc.*;
import jobs.*;

public class Application extends Controller {

public static void index() {
render();
}

public static void backlog() {
new ImportBacklog().now();
redirect("/datas/list");
}

public static void sfdc() {
String authorizeUrl = "https://login.salesforce.com/services/oauth2/authorize";
String redirectUrl = "http://localhost:9000/application/callback";
String clientId = "loginid";
String url = authorizeUrl + "?response_type=code&client_id=" + clientId + "&redirect_uri=" + redirectUrl;
redirect(url);
}

public static void callback() {
String code = params.get("code");
new ImportSfdc(code).now();

redirect("/datas/list");
}
}

Play!frameworkには、play.lib.OAuth2というヘルパークラスがあるのですが、Salesforceの認証URLへのアクセスには、response_typeパラメータが必要であるため、play.lib.OAuth2を使わず、urlを作成して直接リダイレクトしています。

ソースコードをみても、retrieveVerificationCode()メソッドではリダイレクトしているだけなので特に問題はなさそうです。
コールバックの実装はImportSfdc ジョブに記述します。

各手順の詳細は公式サイトの「Salesforce.comのOAuth 2.0を掘り下げてみよう」を読んでもらえれば図解で書いてあるので、ここでは要点だけ記載すると、
１. 認証URLにアクセスし認証を行った後、callbackURLにリダイレクトされるので、URLパラメータからcodeを取得します。
２. 取得したcodeとgrant_type、client_id、client_secret、redirect_uri パラメータを使用して、今度はトークン取得URLにPOSTでアクセスします。
３. トークン取得URLからJson形式でレスポンスが返ってくるのでその中のアクセストークン（accessToken）を取得します。
４. アクセストークンをHTTPヘッダ（Authorization: OAuth）に含めることで、以後REST形式でデータを取得できます。

hoge/app/jobs/ImportSfdc.java

package jobs;

import java.util.*;
import play.*;
import play.jobs.*;
import play.libs.WS;
import com.google.gson.*;
import models.*;

public class ImportSfdc extends Job {

String code;

public ImportSfdc(String code) {
this.code = code;
}

public void doJob() {
String tokenUrl = "https://login.salesforce.com/services/oauth2/token";
String redirectUrl = "http://localhost:9000/application/callback";
String clientId = "loginid";
String clientSecret = "password";

String url = tokenUrl + "?grant_type=authorization_code&code=" + code + "&client_id=" + clientId + "&client_secret=" + clientSecret + "&redirect_uri=" + redirectUrl;
JsonElement tokens = WS.url(url).post().getJson();
String accessToken = tokens.getAsJsonObject().get("access_token").getAsString();
String instanceUrl = tokens.getAsJsonObject().get("instance_url").getAsString();

url = instanceUrl + "/services/data/v23.0/query/?q=SELECT Id, Subject, Description from Case";
JsonElement cases = WS.url(url).setHeader("Authorization", "OAuth " + accessToken).get().getJson();
Logger.info(cases.toString());

Iterator<JsonElement> records = cases.getAsJsonObject().get("records").getAsJsonArray().iterator();
while(records.hasNext()) {
JsonElement attributes = records.next();
String caseId = attributes.getAsJsonObject().get("Id").getAsString();
String subject = attributes.getAsJsonObject().get("Subject").getAsString();
JsonElement elem = attributes.getAsJsonObject().get("Description");
String description = elem.isJsonNull() ? "" : elem.getAsString();

Data data = Data.find("byCode", caseId ).first();
if(data == null) {
data = new Data(caseId, subject, description);
data._save();
}
}
}

}

こちらもごっそりCaseを取得したかったので、SOQLクエリで取得します。
Force.com REST API クイックリファレンス
http://localhost:9000/application/sfdc へアクセスすると

こんな感じでデータが取得できました。

まとめ

今回は社内のデータ収集のためにバックログとセールスフォースのAPI連携をPlay! frameworkで作ってみました。Play!のジョブ機能には、cronの機能も備わっているので、自動で同期したりすることもできて便利です。

社内の情報を集約して、使えるナレッジベースになるように修練していきたいですね。
ではまた。

「エンジニアサポート新年会2012 CROSS」参加報告

2012-02-08T13:00:00.002+09:00

http://tech.nifty.co.jp/party/2012/

どうも、fujya.shです。

久しぶりの投稿になりますが、1/27(金)に「エンジニアサポート新年会2012 CROSS」というイベントがあり、qpstudyのリーダーこと@iaraさんからのご招待で「クラウドCROSS」でお話する機会をいただきました。感謝。

とにかく物凄く良いイベントで、登壇しているエンジニアの皆様はエッジな方々でためになる話や、刺激を受ける話をたくさん聞けました。右手を上げれば美味しいプレモルが手に入るといった「至れり尽くせり」な６時間でした。

今回は（ブログを書くまでが勉強会の精神で）参加報告をしたいと思います。

■何を話してきたの？

例のごとくSlideShareに上げてあるのでまずはパラパラ眺めてみてください。

cross2012a fujya

・シャノンはとてもインフラエンジニア募集してるよ

・シャノンはたくさんの「クラウド」を活用してるよ

　→　無駄を省いてサービス構築にリソースを集中している

・インフラエンジニアがクラウドの障壁を取り除いてあげる必要があるよ

・SaaSベンダのインフラエンジニアは「プラットフォーム」を構築するのが仕事だよ

・オンプレ/IaaSのどちらにプラットフォームを構築するか見極める必要があるよ

　→　それぞれメリット/・デメリットがあるので使い分けは大事

・シャノンは「説明できる」インフラを心がけてるよ

・QA環境はスケールできるIaaS環境に構築してるよ

　→　IaaSのスケールできるというメリットを利用した構築例

といった内容になってます。

BtoB向けのSaaSのインフラをやっている人というのが世の中にどれだけ存在しているか分からないですが、この手の話でもそれなりに聞いてくれている人がいて安心しました。

■クラウドCROSSでの感想

@kuwa_twさんの話：

http://www.slideshare.net/akuwano/ss-11368700

インフラエンジニア界のトップアイドル、サイバーエージェントの桑野さんのお話。業務ではクラウドを利用していないとの事。

お話の中でビックリしたのは「来週までに30台のサーバを用意して欲しい」という要望に急ピッチで対応できる体制があると説明していた点です。そこまで体制が作れるのであれば、オンプレのメリットをフルで使う事ができるのでパブリッククラウドの必要性というのが確かに薄れてきますね。

サイバーエージェントさんはOpenStackを利用してプライベートクラウドを構築しているとの事なので、クラウドを自分たちで作って自分たちで使う感じですね。

@abejさんの話：

http://www.slideshare.net/abej/cross-cloudabej-11329180

nifty中の人である安倍さんがNIFTY Cloudの１ユーザの視点で、クラウドが無かった時代のインフラとクラウド真っ盛りの現在ではどういうインフラを構築・運用しているかの違いを解説してくれました。ポイントはAPI・自動化辺りかと。クラウドがあるこの時代だと気づくと10台・100台とスケールする可能性があるので、1台でも100台でも管理工数が同じになるようにインフラ設計をする事が大事なんですね。

@netmarkjpさんの話：

http://www.slideshare.net/toshiak_netmark/cross2012-cross-11306808

ハートビーツの馬場さんはフルマネージドでクラウド上のサーバの構築・運用/監視をしている立場として、オンプレとクラウドのメリット・デメリット等を紹介してました。その中でクラウドの残念な所として「クラウドに夢見過ぎな人を説き伏せないと」という話がありました。確かに「クラウドならバックアップいらないよね！」等の夢を見ている人はたまに見かけるので、そういう人を説得するのは大変だと思います。

私の場合は「クラウドに対して不安しか無い人を説き伏せないと」と逆の場合が多くみられます。どちらも非常にたいへんです。

クラウドならではのメリット・デメリットはあるものの「やらないといけない事」はオンプレ・クラウド共に変わりません。ただその作業の容易さは変わってきますね。

■総括

クラウドの出現によりインフラエンジニアに求められる仕事が変わっている。そういう印象を受けました。

－プログラマブルなインフラ

会場で良く出てきたキーワードとして「プログラマブルなインフラ」があげられると思います。実際にインフラエンジニアがプログラムを書くというワケでは無く、インフラの設計自体がプログラムチックになっていないとダメだという事だと思います。もちろんプログラムも書けたほうが良いです。

－オンプレとクラウドの特徴の把握

１：オンプレでは大変苦労していたけど、クラウドでは凄い楽にできる事

２：オンプレでもクラウドでも変わらずやらないといけない事

３：クラウドだからこそやらないといけない事

この３点を把握して上手に使いこなす事が求められてきている用に感じます。２番３番に関しては「クラウドに夢見てる人」が勘違いしやすいポイントなのでは無いでしょうか。

－インフラエンジニアの不足

上記２点ができるインフラエンジニアが不足している印象を受けました。実際にシャノンが求めているインフラエンジニアはそういう方ですし、業界として少ない印象を受けています。

解決策として

業界全体でインフラエンジニアを増やす事が必要なのではないかと。私もそう思います。具体的に何をすれば良いのかアクションはまだ分かっていませんが、少しづつでもアウトプットを増やしていきたいです。そして勉強会などでCROSSしていく事、業界全体でインフラの楽しさを布教していきたいなと思います。

小学生のなりたい職業TOP10に「インフラエンジニア」が入るようにする事が個人的なミッションですｗ

最後にニフティ様をはじめ実行委員会の皆様、すべての講師の方々、とても素敵な時間を過ごせて感謝しております。ありがとうございました。

来年も是非参加したいと思っておりますので、よろしくお願いします。

クラウド時代のプロジェクトマネジメント

2012-02-07T09:27:00.001+09:00

元インフラ担当のyanaです。
2011年12月付けで、技術統括部からイベントソリューション事業部へ異動しました。
技術部ブログに投稿しても良いということなので、
今まで触れられなかった事業部署についてご紹介させていただきます。

そもそも、シャノンってなんの会社？

オンラインとオフラインが融合した、時代に適切な
マーケティングソリューションを支えるサービスを展開しています。

主力製品は２つあります。

http://www.shanon.co.jp/product/marketingplatform/
http://www.shanon.co.jp/product/eventplatform/

どちらの製品も自社開発、運用を行っています。
クラウドコンピューティングのメリットを最大限に生かし、
外部サービスとの連携に強いことが特徴です。

例えば、

１．展示会やプライベートショーの事前登録をWebフォームで受付
２．当日に受付で来場の有無をバーコードで取得し
３．来場された方、されなかった方に、それぞれメールを送って
４．メールに記載されたURLをクリックしたか有無を取得して
５．URLから興味のある内容を予測し、さらに具体的なメールを送る
７．このような施策を繰り返し、最後は商談・成約につなげる

こんなマーケティングソリューションをご提供しています。

技術部と事業部ってどういう関係？

簡単に言いますと、
技術部は、製品開発とサーバーインフラを運用する役割、
事業部は、製品やサービスのセールスやコンサルティング・インプリメントを行い
お客様へご提供する役割です。

やっぱり製品があるって面白い

弊社の強みと言えば、やはり製品を中心としたサービスのご提供です。
製品があれば、利用実績が積み上がっていきますので、
その経験を元にして安定したサービスをご提供できます。

また、毎月のバージョンアップでご提供できる機能が追加されたり、
パフォーマンスが改善されたりとお客様に合わせて製品が成長していくところも
製品をご提供ものとして心強いです。
（技術部を離れて、この強さを実感します）

お客様からの要望は、当然のように千差万別です。
固定された製品があると難しいよういのも思われますが、
製品で提供するメリットを前提に、ある意味では弊社の製品にお客様の運用を合わせていただき
想定よりも大きな効果を得ていただくご提案をしていくことが醍醐味でもあります。

サービス企画、製品企画に参加できる

通常は、技術部が製品企画を立案し、立ち上げに参加することも多いですが
お客様と接している事業部ならではの製品（サービス）企画をすることもあります。

現在も、その機能が競合他社との差別化になっているケースもあります。

技術側だけでなく、事業側からも製品を成長させるアイデアを出して実現していく
これで市場に変化を作っていく事ができるのもシャノンの事業部の楽しさです。

業務アプリの中心は自社製品＆Sales force＆Google apps

事業部側で発生する見込み客の管理から商談まで、自社製品とSales forceで管理されています。

マーケティングサービスを主軸にしていますので、
事業活動のベースになるマーケティングプロセスに自社製品が
ガッチリ組み込まれているのが、ウチらしいです。
（自社用のSales force連携は、提供案件も含め最大規模という噂も）

見積もりの作成承認から仕入れの検収まで承認フローも全て
Salesforceで実装されていますので事業活動がリアルタイムで確認できるのも強みです。

もう一つ、全社導入しているのがGoogleAppsです。

社内外とわず、メールは全てGmail
スケジュール管理はGoogleCalendar
重要ドキュメントはGoogleSiteでサマリー化され
それぞれの情報は、GoogleDocsやGoogleSpreadsheet、GooglePresentation
を利用していますし、社内研修のビデオはGoogleVideoに保存されています。

これで1アカウント年間6,000円というのがすばらしいです。

http://www.google.com/apps/intl/ja/business/

クラウドコンピューティングの恩恵をフル活用しています。

プロジェクトマネジメントもWebアプリを完全活用

プロジェクトマネジメントにもWebアプリを積極利用しています。

１．1つ前でもご紹介したSalesforce
２．プロジェクト開始後にマイルストーン作成とスケジュール管理に利用しているSmartSheet
http://www.smartsheet.com/
３．課題・タスク管理に利用しているBacklog
http://www.backlog.jp/
４．プロジェクトのドキュメント管理に利用しているGoogleApps

このツールを下記の様なプロセスで利用しています。
本当は自動で連動させたいですが、今後の課題です。

一部ファイルはセキュリティの関係で社外の保存ができませんが、
そのファイルサーバーもセキュアな社外クラウド環境を利用しています。

社内にあるものは何だろう？と思うほど、事業部側のプロジェクト運営は
クラウド化が進んでいます。

ノートPC＋モバイルルータ or ダブルディスプレイ

担当者によってはトリプルディスプレイもあります。
私には使いこなせる自身がありませんが。。

外出の多い営業担当者やコンサルタントはノートPCが全員に支給されています。
移動先で業務ができる環境があるほうが、業務が効率化できますね。

※　情報は、ほぼクラウド環境化ですし、認証・HDDの暗号化対策も実施しています。
※　月一回は、個人情報が保存されていないか自動診断のプログラムも実行されますので安心です。

技術部と一緒で、裁量労働でコアタイムなし

お客様とお仕事をする事が多いので、何時でもというわけにはいきませんが
自分の職務責任を果たすため、大きく裁量を与えられています。

単純なインプリメント作業ではなく、お客様への企画提案がベースにありますので
クリエイティブな思考をサポートできる環境を整えています。

担当者ごとに専用番号があるので取り次ぎ無し

営業担当者、コンサルタント全員に専用番号が配布されています。

商談中も、プロジェクト推進中も担当者（またはチーム）がアサインされていますので、
連絡先はきまっています。なので、取り次ぎによる業務の中断を減らすための工夫です。

お客様のご協力あり、取り次ぐことよる集中を遮断されるケースが激減しました。

ちなみに、事業部は大きく２つ

１．マーケティングソリューション事業部
２．イベントソリューション事業部

大きくは、この２つの事業部があります。
２つの事業部を合わせて計40名ほど所属しています。

私が所属しているのは、イベントソリューション事業部になります。

イベントソリューション事業部とは？

主に、コンベンション事業を行っているお客様、
または広告代理店のお客様が多い事業部です。

スポットでイベントを開催される際に弊社製品を中心にサービスをご提供し、
イベント開催の目的達成をマーケティング側からサポートしています。

平均年齢は、約28歳

調べてみて驚きましたが、若いですね。。

プロジェクトマネージャー募集中

プロジェクトの設計、進捗管理、予算管理を担当いただくお仕事です。
弊社製品であるクラウド型Webサービスのソリューション提供が中心ですが、
プロジェクトの要件に応じて外部制作会社との共同進行や、
他Webサービスとのアプリケーション連携のディレクションも含まれます。
弊社のプロジェクト進行において非常に重要な役割を担うお仕事です。

ご興味のある方は、是非ご連絡ください。
http://www.green-japan.com/job/18472

アンドロイドアプリを作ってみよう　～開発環境準備（その２）～

2012-02-01T20:01:00.000+09:00

ご無沙汰してます、h.kashiwagiです。
しばらく放置して、9ヶ月ぶりの投稿になります。。

今回も前回に引き続きアンドロイドアプリを開発するにあたっての必要なことをまとめていこうと思います。
まず、前回のおさらいから、
開発環境に必要なものをインストールしましょう。
1. SDKのインストール
・Androidアプリを開発するためのツール
・Android Developersからダウンロード。
2. Eclipseのインストール
・Javaの開発環境
・Eclipse Downloadsからダウンロード。
3. JDKのインストール
・Java言語でプログラミングを行う際に必要なソフトウェア。
・Java SE Downloadsからダウンロード。

今回は、
1. ADTのインストール
2. Eclipseの環境設定
3. AVD(Android仮想デバイス)のインストール
あたりについてまとめようと思います。

1. ADTのインストール
ATD(Android Development Tools)とはEclipseでAndroidアプリケーション開発を行うためのプラグインです。
【手順】1.1　Eclipseを起動して、メニューの「ヘルプ」=>「新規ソフトウェアのインストール」を選択します。

1.2　「インストール」ダイアログが表示されるので、追加を選択。
「サイトの追加」ダイアログが表示されるので、
・名前： Android Development Tools
・ロケーション： https://dl-ssl.google.com/android/eclipseと入力してOKボタンをクリック。1.3　「インストール」ダイアログに戻り、「作業対象」に上記で追加したサイトを選択。
選択したサイトのURLからインストール可能なプラグイン情報が一覧で表示されます。
一覧の中で「開発ツール」にチェックを入れて、「次へ」をクリック。
※赤枠の「▷」をクリックすると開発ツールの詳細が見れます。
1.4　「使用条件の条項」に対しての同意が求められるので、同意して次へ進むと
インストールが始まります。
1.5　インストールが正常終了すると、Eclipseの再起動を求められるので、再起動してください。

これでATDのインストール作業は終了になります。

2. Eclipseの環境設定2.1　Android SDKのパス設定
これは、EclipseにSDKを認識させるために必要な設定です。
【手順】2.1.1 Eclipseのメニューから「ウィンドウ」=>「設定」を選択します。2.1.2 「設定」ダイアログが表示されるので、左枠の一覧から「Android」を選択します。
「参照」ボタンからインストールしたSDKのフォルダを選択し、「OK」ボタンをクリック。
これでパスの設定は終了です。

2.2　SDKコンポーネントの追加
今回インストールしたSDKは、バージョンによって異なる機能をなくした最小限のパッケージになっているため、開発するにあたって、バージョンによって異なるコンポーネントが必要になります。ADTプラグインを使って、SDKのコンポーネントを追加します。
【手順】
2.2.1　まず、Eclipseのメニューから「ウィンドウ」=>「Android SDK Manager」を選択。
「Android SDK Manager」ダイアログに、インストール可能なコンポーネントが表示されます。
2.2.2　今回は、「Tools」と「Android 2.2(API8)」を選択して「install packages」をクリック。
なぜ、2.2かというと、自分のスマフォが2.2なので。。（いつか自分の末端にインストールする日が来る日を夢見て・・）特に深い意味はありません。
開発するバージョンに応じてチェックするものを変更してください。2.2.3　確認ダイアログが表示されるので、「すべて受諾」を選択してインストールしてください。
これで、SDKコンポーネントの追加作業は終了です。

3. AVD(Android仮想デバイス)のインストール
AVDとは、実際の末端での動作をPC上で再現することのできるツールで、Androidエミュレータとも言われています。まー、テスト環境的なものと思ってもらっていいと思います。
【手順】
3.1　まず、Eclipseのメニューから「ウィンドウ」=>「AVD Manager」を選択。

3.2　「Android Virtual Device Manager」ダイアログが表示されるので、「新規」を選択すると、「Create new Android Virtual Device」ダイアログが表示されます。・名前: Device-Android2.2（Deviceの設定名）・ターゲット: Android 2.2 - API Level 8（Deviceが利用するライブラリ）・ビルドイン: WVGA800（解像度）
を設定して、「Create AVD」をクリックするとAVDが作成されます。

ここまでで、開発環境の構築は一通りできました。（もし不足があれば、追記します。）
ここまで来るのに、半年・・・確かに仕事は忙しいが、にしてもサボりすぎ。。反省。。
時間みつけてペース上げていかねば！次回は、「アプリケーションの開発手順」か、その前に「Androidの仕組み・アーキテクチャ」のお話ができればと思っています。
では、また。

Class::DBI でインデックス・スキャンができない？

2012-01-23T22:51:00.010+09:00

様々な箇所で現在パフォーマンス対策を実施しています。
その中で、え？そうなの？と思った件があったので、ここに書いておこうと思います。
もし、より良い解決策をご存知の方がいらっしゃいましたら、ぜひ教えてください。

やたらとパフォーマンスが悪い箇所があるということで調査した結果、ソースコードのただ1行にすごい時間がかかっていた。
そして、それが繰り返して使用されているということで、レスポンスを時間内に返せないでいた。


my $result = MyData::CDBI->search_where(
  {
    t_id => \@tid, 
    code_id => $cid, 
    disable => 0 
  }, 
  { 
    columns => [ 'id' ] 
  }
);

@tid は1000個の値を持っている配列である

MyData::CDBI は、Class::DBI を base としたクラスで Class::DBI::AbstractSearch を use している

検索対象のテーブルには100万レコードが入っている

この検索に50秒かかっていたのだ。（←テスト用に用意した大量データの場合。以下同じ）

データベースのほうを見たところ、

t_id は text型で INDEX を使用していない

code_id は integer型で INDEXを使用していない

そのため、INDEX がないせいだろうと思って、つけてみた。


CREATE INDEX t_id_idx ON my_table (t_id);
CREATE INDEX code_id_idx ON my_table (code_id);

そして、EXPLAIN ANALYZE をしてみた。


EXPLAIN ANALYZE SELECT id, t_id FROM my_table WHERE disable=0 AND code_id=1 AND t_id IN (IDを1000個);

当然のことながら Index Scan になっていたし、45ms で返ってきていたので、解決したと思った。


 EXPLAIN ANALYZE
 Bitmap Heap Scan on visitor  (cost=9666.11..1256891.51 rows=957593 width=8) (actual time=9.454..38.358 rows=81903 loops=1)
   Recheck Cond: (t_id = ANY ('{2001,
・・・（中略）・・・
2998,2999,3000}'::text[]))
   Filter: ((code_id = 1) AND (disable = 0))
   ->  Bitmap Index Scan on t_id_idx  (cost=0.00..9426.71 rows=958871 width=0) (actual time=9.145..9.145 rows=82010 loops=1)
         Index Cond: (t_id = ANY ('{2001,
・・・（中略）・・・
997,2998,2999,3000}'::text[]))
 Total runtime: 45.652 ms

だが、実際にアプリケーションを動かしてみると遅いままだった。
また、Class::DBIの検索部分のみを切り出したコードで試したが、結果は同じく約50秒だった。

そこでミスに気付いた。

検索条件の中の t_id => \@tid, の部分は IN検索ではなくて OR検索だった。
t_id in (1,2,...) ではなく、t_id=1 OR t_id=2 OR ... である。

そこで、EXPLAIN ANALYZE をもう一度やりなおした。


EXPLAIN ANALYZE SELECT id, t_id FROM my_table WHERE code_id=1 AND (
 (ext_id = '2000') OR 
・・・（中略）・・・
 (ext_id = '2999')
) AND disable=0;

約40秒かかっており、確かに遅かった。
OR検索は遅いということだ。


 Seq Scan on my_table (cost=0.00..2680689.17 rows=963661 width=8) (actual time=0.129..39667.052 rows=81903 loops=1)
   Filter: ((code_id = 1) AND (disable = 0) AND ((t_id = '2000'::text) OR 
・・・（中略）・・・
(t_id = '2998'::text) OR (t_id = '2999'::text)))
 Total runtime: 39677.908 ms

これのせいだったか～と思い、INを指定する検索に変更した。


my $result = MyData::CDBI->search_where(
  {
    t_id => {'-in' => \@t_ids},
    code_id => $cid, 
    disable => 0 
  }, 
  { 
    columns => [ 'id' ] 
  }
);

それなのに、またしても秒数に変化なし。
50秒のまま。

INの検索になっていないのかな？と疑う。
だが、DBのログを見たところ、ちゃんとINの検索になっていた。


postgres[3656]: [9-1] LOG: 実行 dbdpg_1: SELECT id
postgres[3656]: [9-2] FROM my_table
postgres[3656]: [9-3] WHERE ( code_id = $1 AND disable = $2 AND t_id IN ( $3, $4, $5, $6, $7, $8, $9, $（略）

IN検索にしたら、「Total runtime: 45.652 ms」に近づくと思っていたのに、残念。

次に疑うべきは、t_id が text型であるせいで遅い？ことだ。
入ってるものはIDなので、integer型に変更することにした。
（単なる過去のミスでtext型だったと思われる。さっさと修正しろよって話ですよね、はい。）


ALTER TABLE my_table ALTER COLUMN t_id TYPE INTEGER USING CAST(t_id AS INTEGER);

さぁ今度こそ！とテストコードを実行したところ、25秒。

速くなったけど、なんか違う。
私が求めているのは、「Total runtime: 45.652 ms」だ。

postgres だと pg_stat_user_tables というテーブルの統計情報に、シーケンシャルスキャンとインデックススキャンの実施回数が記録されている。

そこでは idx_scan の数が1つ増えていた。
どうやらインデックススキャンをしてこの遅さらしい。

もうDBテーブルに心当たりはなく、DB側の問題ではないだろうと推測した。
そして実際にどこで時間がかかっているのか、Class::DBI::AbstractSearch->search_where を見てみることにした。

すると、$sth->execute で時間がかかっていることがわかった。
Class::DBI を使わずに、DBI を使ってベタ書きして試したところ、やはり execute が遅かった。


my $dbh = DBI->connect('dbi:Pg:host=x;dbname=y', 'z', '', {AutoCommit => 0, RaiseError => 0});
my $sql = 'select id from my_table where (code_id = ? and disable = ? and t_id in (?, ?, ?,（略）, ?, ?, ?));';  
my $sth = $dbh->prepare($sql)
my $result = $sth->execute(1,0,@t_ids)

試しに selectall_arrayref で検索してみたところ問題のない速さだった。


my $result = $dbh->selectall_arrayref($sql);

execute が遅いことは確定。

だが、Class::DBI を使うと、自動的に execute で実行されてしまう。

ということで、set_sql を使って検索をすることで、この execute が遅い問題を回避。
外部から入力する値はないものの、これではイケてない。


my $sql = sprintf('select id from my_table where (code_id = 1 and disable = 0 and t_id in (%s))', join ',', @t_id);
MyData::CDBI->set_sql('by_t_id' => $sql);

一応速度は EXPLAIN ANALYZE で Index Scan と表示されていたときの速度(と思われる速さ)になっている。

まとめると

search_where を set_sql に変更したこと

t_id を1000個並べる検索条件を or から in に変更したこと

t_id をtext型からinteger型に変更したこと

によって速度は変化していった。

変更した箇所とかかった時間
set_sql/search_where	or/in	text/int	time(sec)
search_where	or	text	49.038347
search_where	or	int	47.85891
search_where	in	text	41.17876
search_where	in	int	22.656974
set_sql	or	text	46.890032
set_sql	or	int	47.396322
set_sql	in	text	7.736877
set_sql	in	int	7.486474

ただ、そもそもの問題として、この1000個のIDを渡して検索する箇所というものをなくすべきだと思っている。

そのため、現在はデータ構造を変更するなどして、こういう検索を消すことに力を入れていこうとしている次第である。

.

Linux + PostgreSQL + Perl な WEBアプリケーションにおけるタイムゾーンの実装

2012-01-21T23:30:00.012+09:00

こんにちは、冬は冬眠する生き物、chappie です。

少し前に、アプリケーションの国際化対応の一環として、タイムゾーン対応の実装を担当しました。今回は、そのときの対応の概要について書いてみたいと思います。

WEBアプリケーションにおけるタイムゾーンの扱いはとても基本的なことのように思えますが、意外とまとまった情報がウェブを見てても少なかったように感じました。今後、私たちと似たようなWEBアプリケーションでタイムゾーンサポートを実装する予定がある方のお役に立てる部分があるかもしれません。

■ タイムゾーン対応する、とは？

ここで、タイムゾーン機能をサポートするということは、アプリケーションを操作する人がどのタイムゾーンで日時データを入出力するか指定できるようにする、ということです。

たとえば、ログインして操作するようなアプリケーションであれば、ログインしているユーザは自分のユーザ情報として、お好みのタイムゾーン(たとえば、日本標準時や、西ヨーロッパ時間、など)を設定します。そのユーザがログインして操作する場合、日時データをそのタイムゾーンにあわせて表示したり、入力された日時データはそのタイムゾーンでの時刻だとして保存したりします。

とある保存された日時が、あるユーザから見ると 2012-01-20 10:00 (日本標準時)であり、別のユーザから見ると 2012-01-20 01:00 (GMT) である、というようなことです。

■ タイムゾーンのマスター情報 tz database

オープンソースソフトウェアの世界でタイムゾーン情報の標準的なマスターとなるのは tz database (またの名を Olson DB)です。ボランティアベースでメンテナンスされてきたもので、Linux ベースのOSや、オープンソースのプログラミング言語環境では、これがタイムゾーン情報の参照先となっています。 tz database の内容を最新に保つことで、どのエリアは時差がGMTから何時間なのかとか、夏時間がいつからいつまでなのかなどの情報が実社会に即したものに保つことができます。

Asia/Tokyo や、 Europe/London などの形式でエリアを指定します。エリアは、時差やサマータイムの有無によって区分されています。あるエリアでサマータイムの実施時期などが変わった場合、情報が更新されます。最近の大きな変更では、ロシアが夏時間を廃止したり(2011年)、アメリカでのサマータイムの実施時期が変わったり(2007年)しました。最新の情報は公式サイト(下記参照)から圧縮されたファイルをダウンロードできます。

ちなみに、2011年の10月、ちょうど私たちがタイムゾーン対応をやっていたまさにその最中に訴訟問題が発生し、一時サイトがクローズする、という事件が起こりました。当時は何が起こったのかよく分からず、とにかく法的ないざこざでタイムゾーン情報の入手先であるFTPサイトが閉鎖してしまったらしい、という事態に一瞬、青ざめました。結局は、ICANN および IANA に管理が委ねられることとなったようで、今では詳しい経緯について Wikipedia にも記載されています。

参考:

Wikipedia - tz database http://ja.wikipedia.org/wiki/Tz_database
現在の tz database 入手先(IANA): http://www.iana.org/time-zones

■ Linux でのタイムゾーン情報

一般的なLinux系ディストリビューションでは、上記の tz database の情報をデフォルトで /usr/share/zoneinfo/ の下に持っています。file コマンドを使ってみると、タイムゾーンデータであることが分かります。(Mac OS X で実行した場合の例)

$ file /usr/share/zoneinfo/Asia/Tokyo

/usr/share/zoneinfo/Asia/Tokyo: timezone data, old version, 3 gmt time flags, 3 std time flags, no leap seconds, 9 transition times, 3 abbreviation chars

特に更新していなければ、インストール時のまま情報が古くなっている可能性があるので、更新しましょう。大体は、以下のいずれかのコマンドで更新できるでしょう。

$ yum update tzdata (CentOS などRPMベースのディストリビューション)
$ apt-get update tzdata (Ubuntu などDebian系のディストリビューション)

tz database をダウンロードして手動でインストールすることもできます。より詳しくは下記リンク先を参照ください。

参考: http://chrisjean.com/2009/03/10/updating-daylight-saving-time-on-linux/

■ PostgreSQL でのタイムゾーン情報

PostgreSQL は、バージョン 8.0 以降、OS にインストールされている tz database の情報を利用できるようになりました。(それ以前のバージョンでは、コンパイル済みの情報を PostgreSQL 内部に持っていたようです。その場合は、PostgreSQL 自体をアップデートしなければタイムゾーン情報を更新できません)

コンパイルオプションで

'--with-system-tzdata=/usr/share/zoneinfo'

を指定しておけば、PostgreSQL がインストールされている OS の zoneinfo が更新されれば自動的に最新の情報となります。

すでに稼働している PostgreSQL がある場合は、コマンドラインで

$ pg_config --configure

としてみて、出力内容に上記のオプションが表示されていれば、そのままでOKでしょう。

参考:

PostgreSQL 8.4 マニュアル

データベースの OS のタイムゾーンを更新した場合は、正しくタイムゾーンが更新されているか確認してみましょう。

たとえば、tzdata_2011g から tzdata_2011h に更新した場合は、ロシアの夏時間廃止が反映されます。psql で日時データの表示を更新の前後で比較してみます。

更新前(2011g):

dbuser=> set time zone 'Europe/Moscow';

SET

dbuser=> select * from timezone_master;

date_1 | date_2

------------------------------+-------------------------------

2011-10-04 13:19:38.796444+04 | 2012-02-02 04:00:00+03

date_1 が夏時間の期間にあたる日時で、date_2 が冬時間の期間にあたる日時です。それぞれ、オフセットが +04、+03 と異なっていることが分かります。しかし、制度廃止によって 2011年の夏時間がそのまま通年の標準となるように変わったので、 2012年の日付である date_2 が +03 になっているのは誤りです。

更新後(2011h):

dbuser=> select * from timezone_master;

date_1 | date_2

------------------------------+-------------------------------

2011-10-04 13:19:38.796444+04 | 2012-02-02 05:00:00+04

tz database の更新後、同じようにデータを表示してみると、 date_2 も +04 になっており、更新が正しく適用されたことが分かります。

■ Perl でのタイムゾーン情報

Perl では CPAN に公開されている DateTime モジュールが日時系の情報を扱う際の標準ですが、このモジュールも tz database の情報を元にタイムゾーン情報を持っています。CPAN からインストールしたファイルではすでに Perl のコードに展開されたものが記述されています。

通常は、CPAN コマンドで DateTime::TimeZone モジュールをアップデートすれば、最新のタイムゾーン情報が反映されるでしょう。

$ cpan update DateTime::TimeZone

諸事情により DateTime モジュールを更新できない場合(機能や関連モジュールを更新できない/しなくない場合など)は、OS の tz database を使って、タイムゾーン情報だけを更新することができます。

以下に、手順例を挙げます。

1. ダウンロードした tz database のファイルを適当な場所に解凍

$ tar xzvf tzdata_2011h.tar.gz
$ mv tzdata_2011h/tmp/tzdata2011h

2. 更新のベースとする DateTime::TimeZone モジュールをダウンロード

CPAN または Git から、ベースとしたいバージョンをダウンロードします

3. ダウンロードした DateTime モジュールで、上の tzdata を指定して parse_olson スクリプトを実行

$ tar xzvf DateTime-TimeZone-0446627.tar.gz
$ cd DateTime-TimeZone-0446627
$ perl tools/parse_olson --clean --dir /tmp/tzdata2011h/ --version 2011h

これで、指定した tzdata の情報を持つ DateTime::TimeZone モジュールが出来上がります。(lib/DateTime/TimeZone/ 以下に、各エリアのディレクトリ/ファイルが作成されます)

参考:

CPAN - DateTime: http://search.cpan.org/dist/DateTime/

■ アプリケーションでの実装

日時系の情報がデータベースに入っているなら、話は簡単です。

ユーザがログインしてタイムゾーンが特定できる場合、リクエスト処理の先頭のほうで、以下のようなコマンドをデータベースに対して発行するだけでOKです。

SET TIME ZONE 'Asia/Tokyo'; (PostgreSQLの場合)

参考: http://www.postgresql.org/docs/8.4/static/sql-set.html

これで、このデータベースコネクションの間は、 timestamp with time zone 型のデータについては指定したタイムゾーンで扱われます。

たとえば '2012-01-20 10:30:00' としてクエリーを発行した場合、上記の例であればこれは日本時間での 10時半という扱いになります。

ちなみに、MySQLでは以下のコマンドで同様の設定ができるようです。

SET time_zone = 'Asia/Tokyo'; (MySQL)

参考: http://dev.mysql.com/doc/refman/5.1/ja/time-zone-support.html

データベースへの単純なデータの出し入れであれば以上で十分ですが、操作しているユーザと異なるタイムゾーンで日時を出力したり送信したりする場面では、適宜タイムゾーンを調整する必要があります。1例を挙げると、ある外部のアプリケーションに日時データを送信するときは常に日本標準時で送らなければいけない、といったケースです。操作中のユーザのタイムゾーンの日時→日本標準時への調整が必要です。たとえば Perl のコードでは DateTime モジュールに日時を格納した上で、以下のような変換を行います。

use DateTime;

my $dt = DateTime->new(
     'year' => 2012, 'month' => 1, 'day' => 20,
     'hour' => 19, 'minute' => 20, 'second' => 0,
      time_zone => 'America/New_York'
); # DB から取得した日付が New York のタイムゾーンだとして

$dt->set_time_zone('Asia/Tokyo'); # 日本時間に変換

print $dt->strftime('%F %T') . "\n"; # 2012-01-21 09:20:00

他にも、タイムゾーンの異なる日付同士を比較する場合なども、たとえばそれぞれ UTC にそろえた上で比較・演算する必要があります。

ちなみに、開発中にテストで入出力した日時が正しいかどうか確認するツールとして、以下のサイトなどを利用するとよいでしょう。日本で何時だったらニューヨークで何時、といった比較が簡単にできます。

worldtime buddy: http://www.worldtimebuddy.com/

なお、ユーザが指定可能なタイムゾーンの選択肢は、 tz database で選択可能なものに限定するようにしましょう。アプリケーション(Perl)、PostgreSQL、それぞれの OS で tz database のバージョンが一致していることが重要です。

■ おまけ: タイムゾーン小ネタ

以上、ざっくりしたタイムゾーンサポート導入の概要でした。

以下は技術ネタとは関係ない蛇足ですが、タイムゾーンまわりのことは調べてみるといろいろ興味深い話があります。

-- 日本のタイムゾーン、サマータイム

2011年は、電力不足の懸念から日本でもサマータイムを導入すべきではないか、という話題が挙がったりしていました。もし本当にサマータイムを導入するとなると、上で述べた tz database も日本中のシステムで更新されることになるでしょう。ちなみに日本でも戦後、GHQの施策でしばらくサマータイムが実施されていた期間があったそうです(僕は全然知りませんでした)。zdump コマンドで zoneinfo をのぞいてみると、1948 年から 1951 年ごろまで、切り替わりを示す情報が記載されいてるのが分かります。

$ zdump -v /usr/share/zoneinfo/Asia/Tokyo
/usr/share/zoneinfo/Asia/Tokyo  Fri Dec 13 20:45:52 1901 UTC = Sat Dec 14 05:45:52 1901 CJT isdst=0
/usr/share/zoneinfo/Asia/Tokyo  Sat Dec 14 20:45:52 1901 UTC = Sun Dec 15 05:45:52 1901 CJT isdst=0
/usr/share/zoneinfo/Asia/Tokyo  Fri Dec 31 14:59:59 1937 UTC = Fri Dec 31 23:59:59 1937 CJT isdst=0
/usr/share/zoneinfo/Asia/Tokyo  Fri Dec 31 15:00:00 1937 UTC = Sat Jan  1 00:00:00 1938 JST isdst=0
/usr/share/zoneinfo/Asia/Tokyo  Sat May  1 16:59:59 1948 UTC = Sun May  2 01:59:59 1948 JST isdst=0
/usr/share/zoneinfo/Asia/Tokyo  Sat May  1 17:00:00 1948 UTC = Sun May  2 03:00:00 1948 JDT isdst=1
/usr/share/zoneinfo/Asia/Tokyo  Fri Sep 10 15:59:59 1948 UTC = Sat Sep 11 01:59:59 1948 JDT isdst=1
/usr/share/zoneinfo/Asia/Tokyo  Fri Sep 10 16:00:00 1948 UTC = Sat Sep 11 01:00:00 1948 JST isdst=0
/usr/share/zoneinfo/Asia/Tokyo  Sat Apr  2 16:59:59 1949 UTC = Sun Apr  3 01:59:59 1949 JST isdst=0
/usr/share/zoneinfo/Asia/Tokyo  Sat Apr  2 17:00:00 1949 UTC = Sun Apr  3 03:00:00 1949 JDT isdst=1
/usr/share/zoneinfo/Asia/Tokyo  Fri Sep  9 15:59:59 1949 UTC = Sat Sep 10 01:59:59 1949 JDT isdst=1
/usr/share/zoneinfo/Asia/Tokyo  Fri Sep  9 16:00:00 1949 UTC = Sat Sep 10 01:00:00 1949 JST isdst=0
/usr/share/zoneinfo/Asia/Tokyo  Sat May  6 16:59:59 1950 UTC = Sun May  7 01:59:59 1950 JST isdst=0
/usr/share/zoneinfo/Asia/Tokyo  Sat May  6 17:00:00 1950 UTC = Sun May  7 03:00:00 1950 JDT isdst=1
/usr/share/zoneinfo/Asia/Tokyo  Fri Sep  8 15:59:59 1950 UTC = Sat Sep  9 01:59:59 1950 JDT isdst=1
/usr/share/zoneinfo/Asia/Tokyo  Fri Sep  8 16:00:00 1950 UTC = Sat Sep  9 01:00:00 1950 JST isdst=0
/usr/share/zoneinfo/Asia/Tokyo  Sat May  5 16:59:59 1951 UTC = Sun May  6 01:59:59 1951 JST isdst=0
/usr/share/zoneinfo/Asia/Tokyo  Sat May  5 17:00:00 1951 UTC = Sun May  6 03:00:00 1951 JDT isdst=1
/usr/share/zoneinfo/Asia/Tokyo  Fri Sep  7 15:59:59 1951 UTC = Sat Sep  8 01:59:59 1951 JDT isdst=1
/usr/share/zoneinfo/Asia/Tokyo  Fri Sep  7 16:00:00 1951 UTC = Sat Sep  8 01:00:00 1951 JST isdst=0
/usr/share/zoneinfo/Asia/Tokyo  Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 12:14:07 2038 JST isdst=0
/usr/share/zoneinfo/Asia/Tokyo  Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 12:14:07 2038 JST isdst=0

1937年から1938年へ変わるタイミングについての記載は、どうもそれまで「中央標準時」と「西部標準時」の2つのタイムゾーンがあったのが一本化されたことに対応するもののようです。(CJT から JST に変わっています)

参考:

Wikipedia 日本標準時: http://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E6%A8%99%E6%BA%96%E6%99%82
hnwの日記 - 日付と時刻の豆知識 (4)tz databaseと日本のサマータイム: http://d.hatena.ne.jp/hnw/20101223

-- タイムゾーンの選択肢をどうするか

ユーザが選択可能なタイムゾーンは、 tz database に含まれているものである限りは何でも構わないのですが、すべてのタイムゾーンを選択可能にすると選択肢が膨大になります。また、それだけのタイムゾーンをサポートするということになると、どこかのエリアでタイムゾーン情報の変更があるたびに tz database を更新しなければならないので、その更新頻度も多くなってしまいます。

最低限という意味では、1日 24時間なんだから 24分割して代表的なエリアを 24個選択肢に含めればいいのではないか？と一瞬思いますが、エリアによっては UTC との差が n 時間30分差/15 分差だったりします(たとえばインドは UTC + 5:30、ネパールは UTC + 5:45)し、サマータイムを実施しているエリアとそうでないエリアがある(たとえばアメリカやオーストラリアでも、同じくらいの経度の地域でも州によってサマータイムを実施しているところとしていないところがある)ので、そう単純には決まりません。

結局は、サービスを利用するユーザの分布(予測)で決めるしかないでしょう。主要な国や地域を見繕って、あとはなるべく将来の更新頻度を減らすために、ある程度の網羅性を確保できるよういくつかのエリアを補足すればよいでしょう。

参考:

Wikipedia 標準時: http://ja.wikipedia.org/wiki/%E3%82%BF%E3%82%A4%E3%83%A0%E3%82%BE%E3%83%BC%E3%83%B3
Time-j.net 世界時計 - 世界の時間と時差: http://www.time-j.net/uc/

他にも、UTC と GMT の違いや閏秒の話など、ネタはいくつかありますが、おまけのほうが長くなりそうなのでこの辺で今回は終わりとしたいと思います。

では、また。

Haskell で Web スクレイピング

2012-01-10T13:51:00.000+09:00

どうも。開発の_fpです。

『７つの言語7つの世界』が題材の社内勉強会に参加して Haskell を担当したところ、意外にハマってしまいました。

今回は Haskell で Web スクレイピングということで、シンプルなリンクの抽出と、表形式のデータの取得をやってみたいと思います。

Web 上のライブなデータを扱うことができるので、Haskell をこれから学習する人にとっても面白いのではないかと思います。

一般に Web スクレイピングといえば、Python の BeautifulSoup などが定番かと思いますが、 Haskell　にも TagSoup というモジュールがあります。（同名の Java のものとは無関係のようです）

開発環境は Haskell-Platform です。

事前に、いくつか必要なモジュールをインストールしておきます。

> cabal update
> cabal install　utf8-string tagsoup

まずは、 ghci を起動して Web のコンテンツ取得を試してみます。

> import Network.HTTP
> getResponseBody =<< simpleHTTP (getRequest "http://www.shanon.co.jp")

HTMLのソースが表示されます。

ついでに以下もそれぞれ試してみると良いでしょう。

> (getRequest "http://www.shanon.co.jp/")
> simpleHTTP (getRequest "http://www.shanon.co.jp")

ここからは、TagSoupを使っていきます。

ソースファイルを作成して、ghciからロードします。

-- hrefs.hs
import Network.HTTP
import Text.HTML.TagSoup

openURL :: String -> IO String
openURL x = getResponseBody =<< simpleHTTP (getRequest x)

hrefs :: IO [String]
hrefs = do
    tags <- fmap parseTags $ openURL "http://www.shanon.co.jp/"
    let attrs = [head i | (TagOpen "a" i) <- tags]
    return [j | ("href", j) <- attrs]

ghciで以下のコマンドを実行します。

> :load hrefs.hs
> hrefs

実行すると、URLのリストが表示されます。

parseTags の戻り値はTagのオープンとクローズのリストなので、まずは a タグをリスト内包表記で取り出し、次にアトリビュートのリストから href の値を取り出してリストとして返しています。

次に、tableタグのデータを抽出してみます。

今回は、個人的に引越し先として検討している千葉県船橋市の小学校のデータを抽出してみます。

元のサイトはこちらです。

船橋市小学校学級数・児童数一覧

さて、先ほどのaタグと違って、今度は開きタグと閉じタグの対応関係を見なくてはなりません。

何度もパターンマッチすればできそうですが、ちょっと面倒です。

そこで、今回は TagSoup.Tree を使って木構造からデータを取得してみます。

-- schools.hs
import Network.HTTP
import Text.HTML.TagSoup
import Text.HTML.TagSoup.Tree
import Data.Char (isSpace)
import qualified Codec.Binary.UTF8.String as U

openURL :: String -> IO String
openURL x = getResponseBody =<< simpleHTTP (getRequest x)

-- |先頭と末尾の空白を取り除く
trim :: String -> String
trim = f . f
    where f = reverse . dropWhile isSpace

getSchools :: IO [[[String]]]
getSchools = do
    tags <- fmap parseTags $ openURL "http://www.city.funabashi.chiba.jp/kodomo/school/0004/p008678.html"
    -- 木構造を取得
    let tree = tagTree tags
    -- tr を取り出す (先頭2つと末尾は除く)
    let schools = map doRow (init $ drop 2 $ [x | (TagBranch "tr" _ x) <- universeTree tree])
    return schools
    where
        -- |セルの文字列を取り出す
        doCell :: [TagTree String] -> [String]
        doCell xs = [U.decodeString $ trim $ fromTagText t | t@(TagText _) <- flattenTree xs]

        -- |td を取り出す
        doRow :: [TagTree String] -> [[String]]
        doRow xs = map doCell [x | (TagBranch "td" _ x) <- xs]

showSchools = do
    s <- getSchools
    mapM doSchool s
    return ()
    where
        doSchool xs = do
            -- インデックス1の要素(学校名)を取り出す
            let sname = head $ xs !! 1
            putStr (sname ++ "\n")
            -- 残りを表示
            putStr ((show $ drop 2 xs) ++ "\n")

ghci

> :load schools.hs
> showSchools

実行結果

船橋
[["3"],["87","(2)"],["3"],["86",""],["3"],["84","(2)"],["3"],["78","(1)"],["3"],["86","(1)"],["2"],["74","(3)"],["17","(2)"],["495","(9)"]]
湊町
[["2"],["69","(3)"],["3"],["79","(2)"],["3"],["81","(6)"],["2"],["71","(3)"],["2"],["75","(2)"],["3"],["83","(4)"],["15","(3)"],["458","(20)"]]
...

一旦、木構造に変換してtrを抜き出し、そこからさらにtdを抜き出しています。最終的にセルの値は　flattenTree でリスト構造に戻して取り出します。詳しくはコメントを参照して下さい。

補足すると、doCellのTagTextのリスト内包表記はAs-patternというもので、

パターンの前に識別子と@をつけるとマッチしたタプル全体を参照できます。

空白の除去には、Wikipediaで紹介されている trim 関数をそのまま使いました。

いかにも Haskell らしくていい感じです。

また、サイトから取得した文字列が文字化けしてしまうので、デコードしています。

出力はターミナルの文字コードがUTF-8なら日本語で表示されると思いますが、WindowsではデフォルトがCP932などになっているので注意が必要です。

以上、簡単に説明してみました。

Haskell というと学術的なイメージがありますが、このように実用的なプログラムも簡潔に書けることが分かると思います。

私もまだまだ始めたばかりですが、面白いサンプルがあれば紹介していければと思っています。

jQueryでCanvasを使ってお絵かき - 実践編

2012-01-07T09:43:00.005+09:00

ご無沙汰しております、株式会社シャノン技術統括部プロダクト開発部のHealerです。

あけましておめでとうございます。
冬も本番となり、寒さが厳しくなってきましたが、お風邪などを召しておられませんでしょうか？
そして本年も本ブログともども、弊社株式会社シャノンをよろしくお願い致します。

さて、前回、
jCanvas(jQueryプラグイン)でCanvasを使ってお絵かき - 対応ブラウザ確認編
なるものを書いてから早半年以上空いてしまいました。。
実はスケジュールの都合が合わなくて1回パスをしているんです。
当ブログは基本的に当番制でスケジュールの割り当てをいただいて技術部内の人間が順繰りに書いていくわけですが、1回だけパスが認められています。
従って、1回パスをしたところ、今回は捕まえられてどうにも逃げられず書いている次第です。(笑)

という冗談はさておき、今回は
jQueryでCanvasを使ってお絵かき - 実践編
です。
良質な読み物エントリの多いブログですが、
作ったもので遊べる系エントリでニッチなところを攻めていきたいと思います。

ん？前回とタイトルを比べてみましょう。

jCanvas(jQueryプラグイン)でCanvasを使ってお絵かき - 対応ブラウザ確認編
jQueryでCanvasを使ってお絵かき - 実践編

jCanvasという言葉が消えましたね。。
そうなんです。
CanvasをjQueryでいじくり倒す目的は変わりないのですが、
とある事情のためjCanvasを使わなくなってしまったんです。

そのとある事情とは、描いた図形を動かして動的に線で繋げたい！という事情です。
絵を描くだけならjCanvasでもよかったんですが、
下にある要件を満たすために描いた図形を動かしたかったのですが、
うまく動かすことが出来なかったので
今回は、
HTML5のCanvas図形をクリッカブルにするjQueryプラグイン ClickableCanvas
を使うことにしました。
こちらの方が色々なアニメーションチックな動きにも対応していて、
かつ書き方自体もjCanvasと同じくCSSライクな記法が使えるので簡単で助かりました。

さて、ここからは実際に作ってみたサンプルを元にClickableCanvasを見ていきたいと思います。

作ったサンプルはこちら。(Internet Exproler以外で開いてください)
Cooperation Checker with Canvas
PC限定ですが触ってみてください。
(Flashに変換したIE対応版を近日中に公開します)

作る際に念頭においた要件は以下のとおりです。

サッカーのフィールドに11人+ベンチ5人を並べて好き勝手にフォーメーションを組めるようにしたい
ゴールキーパーとベンチは動かさない
各ポジションは色を別にして見やすく
移動してポジションが変わったら色もそのポジションのものに変わる
動物占い準拠で相性の良し悪しが一目で分かる(おまけ)

要するに、某S◯GA社のアーケードサッカーカードゲームのチーム編成をする時に、
自分のチームの選手の相性が視覚的にチェックできるといいよね、というものです。
何のことかわからない方は捨て置いてください。(笑)

jQuery ClickableCanvas デモページ2
を参考に作りました。

まずjQueryとClickableCanvasを使う用意をしましょう。
HEADタグに
<script src="js/jquery-1.6.1.min.js" type="text/javascript"></script>
<script src="js/jquery.clickablecanvas.v1.4.js" type="text/javascript"></script>
BODYタグに
<div id="field" class="test"></div>
のようにすれば十分です。

まずはCanvas全体のスタイルを指定しましょう。
これが下地になります。
<style type="text/css">
#field {
margin: 15px 30px;
width: 550px;
height: 600px;
position: absolute;
background-color: #00800;
zIndex: 0;
}
</style>

そして、
var cc = $('#field').clickableCanvas({ flashCanvas: true });
のようにclickableCanvasのオブジェクトを用意すれば、
後はひたすら図形を書いていくだけです。

以下のようにcreateShapeメソッドを使って書いていきます。
cc.createShape({
name: 'center_circle',
type: 'circle',
coords: { x: 225, y: 2, r: 50 },
attr: { shapeZIndex: 0 },
style: {
lineWidth: 2.0,
strokeStyle: '#ffffff',
noFill: true
}
});
name(図形の名前)、type(図形の形)、coords(図形の座標など)が必須項目で、
style(デフォルト)、hoverStyle(ポインタが乗ったとき)、activeStyle(クリックしたとき)のスタイルを指定することが出来ます。
また、styleの代わりにgradientを使うとグラデーション付きスタイルを指定できます。
図形にテキストを追加したいときはtextStyleを指定することでテキストが追加されます。
下記のように、イベントハンドラも実装されていますので、
イベントを機に図形を新たに描画したりすることも出来ます。
onClick: function(shape, coord) {
shape.name.match(/player(\d+)/);
ppoint[RegExp.$1] = false;
},
ここでの第1引数は図形オブジェクト、第2引数はカーソル座標が渡されます。

今回作成したサンプルの範囲だと、このくらいで事足りますが、
他にもanimateShapeというアニメーションを行うことの出来るメソッドも用意されています。

サンプルに関してですが、
まず画面のロード時にフィールドの描画と選手の初期配置を行うようにしました。
選手の描画には、
textStyleでその選手の番号を表示し、
hoverStyleでカーソルを載せたときに色が変わるようにしました。
onMouseDownで

ppoint[s] = true;

とすることによって移動を可能にし、
onMouseMoveで移動前、移動後の座標の差を計算して図形を移動させるようにしてあります。

shape.coords.x += (x[num] - preX[num]);
shape.coords.y += (y[num] - preY[num]);
var pos = position = checkPosition(shape.coords.x,shape.coords.y, false);
shape.normal.fillStyle = positions[pos];

onMouseMoveはかなり細かく移動を認識するので重たい処理を書くと
図形の移動がスムーズに見えなくなるので注意が必要です。
移動後の座標から、ポジションが変わっていたら色を変えるようにしてあります。

ppoint[RegExp.$1] = false;

最後にonClickで再び図形の移動を不許可にしています。

ここまでで要件の4まで満たしており、かなり簡単に図形の描画と移動を行うことが出来ました。

5の要件に関しては、
各選手に対応するselectタグを配置して、
選択された値をinputタグに保存しておいて
onMouseOverで動物占いの相性によって色付きの線が出るようにしました。
最も相性がいい場合が金色で以下、赤、青、白、グレーの順になっています。
グリグリ動かしたりして、色々試して遊んで挙動を楽しんでみてください。

最後に、個人的な不満点や課題をいくつか。

まずコードが汚くなってしまったこと。。
設定関連の値をゴチャ混ぜに書いてしまったため、かなり汚いです。
読者の方には申し訳ないですが今回は我慢していただいて、
次回はそのへんを整理して別のファイルに切り出すなどしてコードの可読性を上げたいと思います。
時間が取れれば今回の分も書き直します。

ClickableCanvasを最終的に使いこなすところまで持って行けなかったところも課題です。
実は、色付きの線が描画された状態で選手を移動すると線だけ残ります。。
各選手に一旦カーソルを当てると順次描画しなおすので消えていきますが、
最後まで解決方法が分かりませんでした。
それにともなってエラーが出る場合もあります。
このようなバグを残さないよう精進していきます。

後はCanvasそのものに対する不満です。
今回、textStyleに選手の番号をいれていますが、
当初の構想では番号を入れると同時に指定されている動物の名前も直上に表示するつもりでした。
また、select要素もページ上に常に表示しておくのではなく、
ポインタが当たった時点でフロートのようにselect要素を表示しようと考えたのですが、
残念ながら現在はHTMLのレンダリングには対応しておらず、
タグはエスケープされて表示されます。
仕様書の通りなら可能になるはずなので、早めに対応して欲しいものですね。

次回はこの可動式Canvasサンプルをスマートフォンで動かせるようにしていきたいと思います。手元のiPhoneのSafariだとフィールドの描画とポインタ乗せ時の線の描画まではされたんですが、
配置をいじることは出来ませんでした。
何かまた違った要素があるようですね。
その辺を勉強してみます。

以上、JavaScriptだけでこんなにお絵かき出来るんだ！のコーナーでした。
業務とは全く関係の無いエントリですいません。。

小さな企業が技術ブログやってみた一年、どうだったかのまとめ

2011-12-26T18:51:00.002+09:00

師走ですね。ikeike443です。

皆さん、知ってますか？　今週の日曜は既に来年です！
何を言ってるかわからないと思いますが、カレンダーを見ればわかります。。年をとるって怖いですね！　一瞬だよ！　光陰矢の如しだよ！

さて、今回は、2011年のまとめということで、弊社技術ブログのこの一年を簡単に振り返ってみたいと思います。

このブログってなんなんですか

一応コーポレイトサイトからもリンクを貼ってもらっていて、公式ブログっぽく見せていますが、実態は技術部の有志で運営しているブログです。（別に非公式だというわけではないですが。。）
予算もついてないですし、主に運営業務をしているのは私ですが、私も本業が別にあって、片手間にこのブログのメンテナンスや編集者業務をしている感じです。

なんのために始めたの

いろいろあります。
一つは採用です。シャノンという会社は企業向けにSaaSを提供しているベンチャー企業で、地味にいいエンジニアが揃っているのですが、いまいち社外のコミュニティ内での知名度も低く、応募者の数も決して多くありませんでした。
せっかくいい会社なのに、知られてないのはもったいないなー、と思ったのがきっかけです。
もう一つは社内の研究開発機会と意識の醸成です。シャノンは少ない人数で多くのお客様に対してサービスを提供していますので、本業は大変忙しい状況です。エンジニアも優秀な人が揃っていますが、それでも日々の業務に忙殺されることが多く、中々新技術や、開発方法論の研究に当てる時間が取れません。
ブログを運営することで、社外への発信の機会を無理やり作り、それによって何かを研究しないといけない、わかりやすくまとめないといけない、となり、それによって社内に研究開発の機会を作っていきたい、という狙いがありました。
最後の一つは、なんか楽しそうだったからです。
ウノウさん（現Zynga）やカヤックさんの技術ブログを見ていて、なんか楽しそうだなー、うちも楽しいことしたい！　というノリで始めた、っていうのも大きいです。

結果どうだったの

まだ始めて1年経ってませんので結果というのもアレですが、中々いい結果を得ることができています。

まず採用ですが、数は明かせませんが、応募者数も少し増えました。ですが、正直言って、数自体は期待していたよりずっと少なかったです。数だけを見ると失敗だったかも？　という結果でした。今からでもいいからここから応募してよ！
ですが、数は少ない代わりに、以前にも増して優秀なエンジニアの方に多く応募していただくことができました。特に、以前はシャノンなんて名前も知られていないし、応募する方も、こちらからスカウトを出さない限りは興味も示さないという方がほとんでしたが（私もそうでした）、ブログを始めてからは、むしろシャノンに入りたい、と言って応募してくださる方が増えました。これは大きな効果だったと感じています。

次に研究開発機会の醸成ですが、これも効果はあったと感じています。思っていたよりは新技術がどうのという話は少なく、比較的地味な記事が多かったかもしれませんが、地に足の着いた記事はそこそこの人気を博しましたし、幾つかの記事は、はてなブックマークもたくさんいただきました。
社内での勉強会も活発になり、直接間接に、本業のプロダクトに反映されるようになっています。

また社外の勉強会に出席するエンジニアの割合も増え、何人かは登壇をする機会なども得られまして、幾分か技術向上の意識が高まった実感があります。これは今後も続けていきたいと感じています。
登壇といえば、年明け早々に、弊社のfujya（藤倉）がニフティさん主催のCROSS エンジニアサポート新年会 2012のこのセッションに登壇する予定です。良かったらみなさん参加されてください！

最後に、楽しかったかどうかですが、
超楽しかったですよ
ブログを書くのも、Twitterやはてなでバズるのを見るのも楽しかったですし、また仕事でお客様や取引先様とお話する際も「ブログ見てます」といってくださる方が多く、やってよかった感満載でした。
個人的には、ブログの記事にするという口実で福岡まで渡ったりしましたし、また、上述のCROSS エンジニアサポート新年会 2012の話も、このブログがきっかけでお話を頂いたわけですし、とても楽しい1年でした。

ぶっちゃけどのくらいのPVがあるんですか

はい。こんなもんです。

今年の2月に技術ブログを始めたのですが、初月から1万PVを出し、その後も順調に推移して、年間最大では2万6千PV程を叩き出すことが出来ました。
この数値はPVとしてみた場合は貧弱ですし、著名なブログであれば個人ブログでもこの何十倍もPVを稼いでいますが、全くコネも実績もない状態からブログを立ち上げたにしては、そこそこの数字を出したのではないかなと思っています。

下記の参照元URLと参照元サイトを見てもらうとわかりますが、

ほぼ、Twitterとはてなブックマークによるバズだけでアクセスを稼いでいます、と書こうとしてよく見たら、意外にGoogleからの検索で来ている方も多かったようです。
ブログを立ち上げた最初の3ヶ月くらいはほぼTwitterとはてなブックマークからのアクセスだけだったのですが、徐々に検索にも引っかかるようになった結果、このようになったみたいです。

TopHatenarさんの指標においては、下記のとおりです。

まだまだgigazineさんの背中は遠いですねー。。

もっと精進して、gigazineさんを超えるメディアに育てたいと思います！（嘘です！）

2011年、どんな記事書いたの

最後に、人気のあった記事を振り返って終わりたいと思います。

ブラウザってどうやって動いてるの？（モダンWEBブラウザシーンの裏側）

はてなブックマークを700以上頂きました。HTML5Rocksの記事の翻訳です。

ちなみにHTML5Rocks本家の眼にも止まったようで、本家にもリンクしてもらっています(記事末尾のTranslationの項参照)。

vim で実践！　コードリファクタリング

vimでリファクタリングをする方法を、なぜか動画付きで解説するという記事です。なんでこんな力入ってるのこれ。。

アンドロイドアプリを作ってみよう　～開発環境準備

Googleで検索してきた方が多かったようです。期待した記事になっていたでしょうか。。記事としては完成していないため、執筆者は早く続きを書くように。

開発者にやさしい環境

シャノン技術部の環境について書きました。シャノンはできるだけ開発者が働きやすいように配慮した職場環境を整えています。特にルンバとか。

Jenkins, Seleniumを使った自動テストの課題とこれからの取り組み

Jenkins、Selenium、品質保証、と言った記事は特に人気が高く、常にアクセスが多くありました。特にこの記事は人気が高かったようです。

AmazonEC2を何倍もお得に使う方法

OpenVZ on Xenです。とにかくコストにうるさいシャノンでは、インフラエンジニアがコストダウンのために何でもするんです、ということがよく分かる記事でした。大変ですね！　面白いけど。

FitNesse+Selenium+Jenkinsによるテストケース継続的インテグレーション

これもJenkinsとSeleniumですね。FitNesseってまだ動くんだ、みたいな反応が多かったように記憶しています。執筆者は早く続き書いてね。

数百GBのPostgreSQLを一瞬でバックアップする方法

なんか疲れてきました。いい記事だよ！

第2回Jenkins勉強会に参加しました！

勉強会も出てるよ！

ソフトウェアテスト技法いろいろ

テストの話って人気あるよね！

15分出始めるmonitによるサーバ監視

サーバ監視楽しいよ！

ってことで、

また来年！

産休・育休中に貰えるお金と手続きのポイント　その二

2011-12-19T22:51:00.012+09:00

こんにちは、技術部QA所属のおかもとです。
12月始めに産休・育休に関する記事、第二弾を公開しようと思っていたのですが、
子供が保育園で大流行している水疱瘡になっていた為投稿が遅れてしまいました。
大変長らくお待たせしました・・汗。

前回は産休・育休・復職後のシャノン体験談と題してお話をしたのですが、
今回はそのお休みの間にしなくてはいけない手続きや貰えるお金について詳しく書いてみようと思います。

なぜそのような当り前な事をここで取り上げるか・・？についてちょっと触れると、
確かに「育休　手続き」とかでググればそんな情報は五万と出てきますが、
「どのタイミングでどの手続きをしなくてはならないか？」という時系列にまとめられた資料はほとんどなく、私自身大変困った＆自分で調べることも多かった・・という経緯があるからです。
また、どうしてそんなに時系列が大切か？というと、特に役所関連で申請するものには「期限が何日まで！厳守！！」というのが多く、期限を一日でも過ぎると受理して貰えない＆お金も貰えない・・ということが容赦なくある為です。
是非このあたりのタイムスケジュール管理は会社任せにせず、自分でも大まかな流れを知っておくことをお勧めしたいと思います。

では、さっそく時間軸毎に。。
以下は、主な産休・育休の流れを2011年1月1日出産の場合という具体例で書き、
表にある重要ポイント毎に順を追って簡単に説明していきます。
尚この資料は私が育児休業を取得した当時を参考にしているので、改定されている場合などはご了承ください。

まずポイント①、「産休開始時」
産休は産前6週間・産後8週間を指します。
この期間の健康保険や厚生年金、住民税などは支払う義務があるため、
たいてい産休に入る前の給与でまとめて徴収されることになります。
その為、産休前最後に支給される給与は、ほぼないものと覚悟した方がいいです（笑）。
また、産休に入る前に会社の事務などを通して入手しておいた方がいいものとして、出産育児一時金・出産育児付加金の支払依頼書や出産手当請求書があります。
これは、まだ後に請求するものなので急ぐ必要はありませんが、いざ申請の時！！には、出産直後で余裕がないので早めに入手して書いておくのが得策です。

ポイント②「出産直後」
おめでとうございます・・この出産直後はかなり申請もののラッシュです(汗)。。
まず、出産翌日から産後休暇が始まります。
入院している間に出産一時金と付加金の証明書類を病院で書いて貰いましょう。
因みにこれらの請求先は健康保険組合になりますが、提出先は会社です。
弊社の所属するIT健保は、昔ホリエ●ンが絶賛したことがある健保で、「出産一時金」が420,000円（産科医療補償制度対象分娩でない場合は390,000円）、「出産育児付加金」90,000円の計510,000円（産科医療補償制度対象分娩でない場合は480,000円）が給付されます。
また、このタイミングで育児休業開始予定日を会社に申し出ておきましょう。
これにより、産休終了後にスムーズに育児休業に突入できます。

更に・・退院後は必要書類を揃えて市役所に直行しましょう！
子供の出生届等と児童手当(こども手当)の手続きを早めにすることをお勧めします。なぜなら児童手当金は月末が申請手続きの締め切りで、手続きをした翌月の分からが支給されるため、手続きが遅れた場合も遡って払込みなどは行ってくれませんので注意です。

ポイント③「育児休業開始時」
さて、産休が終わった次の日から育児休業が始まります。
ここでまずした方がいいのが「出産手当金」の申請です。これは何のお金なのかと言うと、
産休中の休業保障といった感じのものです。幾らもらえるかは↓

給付額：　休業1日につき、標準報酬日額の3分の2相当額
・・と言っても分かり辛いので実際の例を見てみましょう♪

ex.)給与が25万だった人(交通費含む)の貰える出産手当金は？？

1.まず大体の日給を出すとこんな感じ。
　　　
250.000 ÷　30 =　8.333
日給：￥8.333

2.日給の2/3が支給されるので、さっき出た日給に2/3をかける・・

8.333　×　0.67(2/3を計算しやすくした)　=　5.583
日給の2/3：￥5.583

3.2で算出した額に産休で取得した日数をかけると・・

5583　×　98　=　547.134

A.給与が25万だった人の出産手当金として貰える額は、約￥547.134

・・となります。
出産手当金の申請書類もまた出産した産科による証明などが必要な為、出来れば出産直後の一時金申請書類等と一緒に書いて貰っておくことをお勧めします。私の場合は里帰り出産ですぐにはハンコを貰いに行けない場所だったので、書いて貰って時期が来るまで保管していました。
こちらも請求先は健保、提出先は会社になります。
さてもう一つ重要な手続きが健康保険と厚生年金保険の免除申請です。これも育児休業に入ってからしかできませんが、全額免除されます。こちらの手続きも会社を通して行います。
因みに住民税は？というと、これは払い続けなければなりません(笑)。私の場合は、育児休業中は普通徴取に切り替えてぼちぼち払っていました。

そして最後に「育児休業給付金」の申請。まずこの申請は受給資格があるかを確認する必要がありますが、自分で確認する場合は会社管轄のハローワークに育児休業開始から10日以内に行う必要があります。会社が申請を行ってくれる場合は、初回申請時に受給資格を確認するらしいです。これが完了すると、以下の金額が2カ月ごとに振り込まれてきます。

月給×0.5×育休として休んだ月数＝もらえる金額(目安)

ざっと説明しましたが、産休・育休に関わる手続きは大体こんな感じです。

前回のシャノン体験談でもお話しましたが、これだけの色々な免除や貰えるお金があるのは大変ありがたいことであり、「社員」という存在は休んでいても尚、特に金銭的な保障の部分で会社に守られた存在であるということを感じます。

また個人的にお礼を言わせて頂くと、特に復職後のQAチームや一緒に仕事をしている方たちのバックアップ体制には感謝しています・・(笑)
突然の水疱瘡や手足口病(今年だけで4回もなった・・泣)にも文句ひとつ言わず、「何かあったらやっておくんで振ってください」とさりげなくメールをくれたりする優しさ。。
どうやら一緒に共倒れしてくれる七人の侍らしき人たちがうちの会社にはいっぱいいるみたいです・・この場を借りてお礼を。。

社外のシャノンに興味ある方々・・
そして社内の皆さんにいつかこの情報が役立つときが来ますように・・と願いつつ終わります。

これが皆さんのおかげでのびの～～びと育っているうちの息子です(笑)

Play! frameworkでつくるスクリーンショット取得サービス

2011-12-05T00:38:00.015+09:00

本エントリは Play! framework Advent Calendar 2011 jp #play_ja : ATND の5日目です。

シャノンCRM部の nishino です。

サポートの人となって、はや５ヶ月。主にトラブル対応がメインですが、お客様の声を直接耳にするようになり、温度感とか、つまずきポイントとか、技術部時代には「意味分からん」とか言っていたことがなんとなく分かるようになってきた気がします。

自分としては懇切丁寧に（手取り足取り）教えるとゆーよりは、お客様が自己解決できるようにドキュメントやツール群を整備していきたいなあ・・と考えている今日このごろです。

今回はシャノンのヱヴァンジェリスト @ikeike443 氏より

「Play!のAdvent Calendarやるよー。」

「ほう、いいねぇ」

と二つ返事で参加することになりましたが、このPlay!という代物は実行時デバッグでエラーが分かりやすく、あまりつまずくことなく扱えるのと（すばらしい）、公式英語サイト（http://www.playframework.org/）の日本語翻訳サイト（非公式）（http://playdocja.appspot.com/）がかなり内容充実しており（これまたすばらしい）、オレがあまり言うこともないなぁという印象で今は若干後悔しておる感じです。

Advent Calender days 4thの @Masahito さんもPlayの情報源としていろいろ紹介してくれていますので気になる方は是非見にいかれることをオススメします。

Play! framework Advent Calendar 2011 jp

http://atnd.org/events/22247

とはまあ言ってもちょっとドキュメント整備の一環でスクリーンショット取得の仕組みが欲しかったので、さくっとPlay!でつくってみて、他のAdvent Calender参加者様（もちろんこのブログを見てくれているあなた様も）と、きゃっきゃ・うふふと楽しめたら御の字だよね、と思っております。

スクリーンショット取得サービス

URLを入力してスクリーンショットの画像を取得するサービスです。

既存のサービスに「ブラウザキャプチャサービス」や「HeartRails Capture」といったものがありますが、これをPlay! で作ってみたいと思います。

プロジェクト作成

プロジェクト名はhogeです。

好きな名前をつけるとよいと思います。

$ play new hoge
~        _            _
~  _ __ | | __ _ _  _| |
~ | '_ \| |/ _' | || |_|
~ |  __/|_|\____|\__ (_)
~ |_|            |__/
~
~ play! 1.2.3, http://www.playframework.org
~
~ The new application will be created in /Users/magnet/Workspace/play/hoge
~ What is the application name? [hoge]
~
~ OK, the application is created.
~ Start it with : play run hoge
~ Have fun!
~
$

CRUDモジュール

Play!に標準で用意されているCRUDモジュールは便利です。なぜなら色々やることがなまけられる省略できるからです。

このCRUD モジュールを有効にします。

hoge/conf/application.conf ファイルに次の行を追加します。

# Import the crud module
module.crud=${play.path}/modules/crud

ついでにデータベースを使用するために、次の行を非コメント化しましょう。

db=mem

モデル

モデルのフィールドはスクリーンショットを撮りたいURLのみです。撮った画像はファイルで保存するのでモデルにはいれません（つくるとしたらBlob型とか）。

hoge/app/models/Screenshot.javaファイルを作成します。

package models;

import javax.persistence.Entity;
import play.db.jpa.Model;

@Entity
public class Screenshot extends Model {
public String url;

public Screenshot(String url) {
this.url= url;
}
}

コントローラ

CRUDモジュールをつかっているのでコントローラは超スッキリです。
hoge/app/controllers/Screenshots.javaファイルを作成します。

package controllers;

import play.*;
import play.mvc.*;

public class Screenshots extends CRUD {}

コントローラのクラス名は、モデル名（Screenshot）の複数形である Screenshotsにしとかないと動かないのでご注意。（設定より規約ってヤツです）

とりあえずここまでを動かしてみる

上記の作業を行った後で、Play!を実行してURLの一覧が表示されるのを確認してみます。

$play run

基本的にplayコマンドの実行はhogeディレクトリ（プロジェクトのトップディレクトリ）で行います。別ディレクトリで実行する場合は、[app_path]オプションを渡してあげればよいかと思いますが、めんどくさいのでね、、

（play（オプションなし）で表示されるUsage参照）

次のURLにアクセスします。

http://localhost:9000/screenshots/list

CRUDモジュールによりビューが自動生成されるので楽ちんですね。

スクリーンショットを取得するライブラリの追加

今回スクリーンショットを取得するライブラリは、ウチのQAでも大変お世話になっているseleniumのWebDriverを使用します。

http://seleniumhq.org/

WebDriverのライブラリ（jarファイル）を取り込むために依存ファイルを書きます。

今回はFirefoxでスクリーンショットを撮るのでFirefoxDriverを入れます。状況によってはInternetExplorerDriverでもいいと思います。

あと、ファイルの処理用にFileUtilsも欲しいのでApache Commonsも入れておきます。

hoge/conf/dependencies.ymlファイルに次の行を追加します。

- org.seleniumhq.selenium -> selenium-api 2.11.0
- org.seleniumhq.selenium -> selenium-firefox-driver 2.11.0
- org.apache.commons -> commons-io 1.3.2

次のコマンドを実行するとライブラリが取り込まれます。

$ play dependencies

ライブラリの検索は、JARVANA（http://www.jarvana.com/jarvana/）がオススメです。javadocも検索できるので重宝しております。

スクリーンショットを取得する処理の追加

それでは、登録したURLのスクリーンショットを取得する処理を追加します。

保存（save）ボタンが押されたら、スクリーンショットを撮ります。

hoge/app/controllers/Screenshots.javaファイルを編集します。

（さっきまでCRUDモジュールでスッキリしてたヤツです）

package controllers;

import java.io.*;
import java.util.List;
import play.*;
import play.mvc.*;
import org.openqa.selenium.*;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.apache.commons.io.FileUtils;

import models.Screenshot;

public class Screenshots extends CRUD {

@After( only={"create", "save"} )
static void capture( Long id ) {
String[] datas1 = params.getAll("object.url");
String urlpath = "";
for(String data1: datas1) {
urlpath = data1;
}

Screenshot screenshot = new Screenshot("");
if ( id == null ) {
List<Screenshot> datas2 = Screenshot.find(
"select s1 from Screenshot s1 " +
"where s1.id = (select max(s2.id) from Screenshot s2)").fetch();
for( Screenshot data2 : datas2 ) {
screenshot = data2;
}
} else {
screenshot = Screenshot.findById(id);
}

try {
WebDriver driver = new FirefoxDriver();
driver.get(urlpath);
File scrFile = ((TakesScreenshot)driver).getScreenshotAs(OutputType.FILE);
FileUtils.copyFile(scrFile,
new File("public/images/" + screenshot.id.toString() + ".png"));
driver.quit();
} catch (Exception e) {
Logger.info(e.getMessage());
}

}
}

少しだけ解説しますと、

まずcaptureメソッドを追加しているのですが、「@After( only={"create", "save"} )」で、create（新規作成）とsave（更新）の場合だけ、リクエストをインターセプトしています。

（Play!ドキュメント：インターセプション参照）

次に、入力したurlをパラメータマップであるparamsオブジェクトから取得します。

（Play!ドキュメント：HTTPパラメータの取得参照）

urlとモデルのidを結びつけたいので、idをcaptureメソッドの引数で取得しているのですが、新規作成時はidが渡ってこない(id == nullで返る）ので、findメソッドでidが最大のオブジェクトを検索しています。

（Play!ドキュメント：オブジェクトの検索参照）

WebDriverのgetScreenshotAsメソッドで取得したスクリーンショットの画像ファイルは、hoge/public/images ディレクトリに{id}.pngという名前で保存しています。

取得したスクリーンショットを表示する（ビュー）

ビューはどこでもいいのですが、一覧で見るのが壮観な気がしたので、今までCRUDモジュールで自動生成していた一覧テンプレートをカスタマイズします。

（Play!ドキュメント：‘Comments’ データリストのカスタマイズ参照）

$ play crud:ov --template Screenshots/list

上のコマンドを実行すると、hoge/app/views/Screenshots/list.html にテンプレートが作成されます。

スクリーンショットの画像が表示されるようにimgタグを追加します。

#{crud.table fields:['id']}
#{crud.custom 'id'}
<a href="@{Screenshots.show(object.id)}">${object.id}:${object.url}</a><br />
<img width="250" src="/public/images/${object.id}.png">
#{/crud.custom}
#{/crud.table}

#{crud.table}編集後のlist.html

#{extends 'CRUD/layout.html' /}
#{set title:messages.get('crud.list.title', type.name) /}

<div id="crudList" class="${type.name}">

<h2 id="crudListTitle">&{'crud.list.title', type.name}</h2>

<div id="crudListSearch">
#{crud.search /}
</div>

<div id="crudListTable">
#{crud.table fields:['id']}
#{crud.custom 'id'}
<a href="@{Screenshots.show(object.id)}">${object.id}:${object.url}</a><br />
<img width="250" src="/public/images/${object.id}.png">
#{/crud.custom}
#{/crud.table}
</div>

<div id="crudListPagination">
#{crud.pagination /}
</div>

<p id="crudListAdd">
<a href="@{blank()}">&{'crud.add', type.modelName}</a>
</p>

</div>

こんな感じで撮ったスクリーンショットが表示されるようになりました。

まとめ

今回はスクリーンショットを取得するWebサービスをPlay! frameworkで作ってみました。

Play! はアイデアをすぐに動く形に出来るという点ですばらしいツールです。

まあ実用レベルのサービスを作ろうと思ったらフレームワークの機能だけでは足りなくて、自分でゴリゴリ書かなきゃダメなんでしょうが、社内ツールレベルだったら十分アスティルの写本だと思います。

Play! framework Advent Calender の明日 (12/6) は @syuta さんです。明日もお楽しみに！

どうやってソフトウェアのまずさを数値化するかを調べてみる

2011-11-29T13:08:00.010+09:00

開発エンジニアのsugimotoです。
弊社サービスのMARKETING PLATFORMの開発を担当してます。
近頃はソースコードのまずさによりメンテナンスコストの増加やメンテナンスによる新たなバグの発生で悩むことが多かったので、今回はこのまずさをどう数値化したものかを調べてブログに書いてみます。

○技術的負債
ソースコードのまずさを負債と捉えて数値化できるのではと考え技術的負債について調べてみました。技術的負債のちゃんとした内容はWikipediaとかInfoQとかの記事を見てもらうのが良いので、ここでは理解した内容を簡単にまとめてみます。

・負債
まず負債って何？ということなんですが、お金と同様に借金です。ソフトウェアの場合、借金に当たるのが良い設計(あるべき姿)に対してどれだけ妥協した設計で作ったかを表します。式で表すと

　　負債　＝　良い設計で作ったもののコスト　－　妥協した設計で作ったもののコスト

になります(下図参照)。

当然負債なので利子の支払いや負債の返済が必要です。

・利子
利子はメンテナンス時に掛かるコストの差分です。基本的に良い設計で作った方がかかるコストは少ないので、妥協して作ったものをメンテナンスすることで余計に掛かるコストが利子になるわけです。これを式で表すと

　　利子　＝　妥協した設計で作ったものをメンテナンスするコスト　－　良い設計で作ったものをメンテナンスするコスト

で表現できます(下図参照)。

このコストは1回だけでなく、メンテナンスする度に掛かりますし、その度に大きさは違います。

・負債の返済
負債の返済なんですが、これはリファクタリングによって良い設計に基づいたものに作り変えるコストになります。部分的にでもリファクタリングすることによって借金を返済することは可能です。ここで、負債＝返済額なのかという疑問が浮かびますが、実際には違うはずです。つまり借金した分だけコストを掛ければ完済できるわけではないんです。

これは、真っ直ぐあるべき姿に進んでいれば一番コストが少ないわけですが、多少なりとも遠回りしているのでその分が掛かるためです。
ただ、実際のお金と違い借金を返済する義務がありません。返済しないとメンテナンスの度に利子を払うだけなわけです。なので理屈上は、

　　良い設計で作ったもののコスト　＋　良い設計で作ったものをメンテナンスするコストの総和　＞　妥協した設計で作ったもののコスト　＋　妥協した設計で作ったものをメンテナンスするコストの総和　(＋　良い設計のものに作り変えるコスト)

であるならば、別に妥協した設計で作ってもいいという判断ができるわけです。
ただこれはあくまで開発コストだけのお話なので、早く出すことのビジネス上のメリットやパフォーマンスに掛かるコストが入ってないので実際はさらに複雑です。

で、理屈はわかったのですが、実際にこんなの出してたら面倒臭すぎてやっていけないというのが正直な感想です。特に既に抱えている負債を数値化するのが非常に大変。ということでいったん技術的負債をソフトウェアのまずさとして数値化するのを却下しました。

(技術的負債のいろいろな意見はInfoQの記事で見てみると良いと思います)

○ソフトウェアの定量的手法
次に検討したのがソフトウェア工学での定量的手法に頼ってみる案です。Wikipediaの「ソフトウェア測定法」によると次のようなものがあるらしいです。

・成長オーダー（アルゴリズム解析、O記法など参照）
・ソースコードの行数
・循環的複雑度
・ファンクションポイント法
・ソースコードの行当たりのバグ数
・コード網羅率
・顧客要求仕様の行数
・クラスおよびインタフェースの個数
・Robert Cecil Martin のソフトウェアパッケージ測定法
・凝集度
・結合度

この中で参考になりそうでコントロールできそうなものが、ソースコードの行数(メソッドの行数の方が良い)、循環的複雑度、コード網羅率、凝集度、結合度の5個。この中でツールを使って取得できるものがソースコードの行数、循環的複雑度、コード網羅率の3個。1個1個がどのようにまずさを表すかを考えてみます。

・ソースコードの行数(メソッドの行数)
あまりに長いメソッドは可読性を悪くなるために、メンテナンスもしづらくなります。行数が大きければ大きいほどまずいコードであると考えて良さそうです。

・循環的複雑度
プログラムの複雑さを数値化するためのものです。複雑であればあるほどメンテナンスコストも上がりますしバグの温床になりやすいです。この値が大きければ大きいほどまずいコードと考えて良さそうです。

・コード網羅率
自動テストのカバー率。自動テストがない場合、その分は手動テストでしなければならないし、反復して実行するのも容易ではないため、コストや品質の両面で良くありません。ですので、カバー率が低い場合はまずいコードと考えて良さそうです。

ということで、今後これら3個の指標を用いて担当ソフトウェアのまずさを数値化してみようと思います。本当は結合度や凝集度も入れたいところですが今のところは難しそうなので。機会があったらやってみた結果をまたブログで報告します。

15分で始めるmonitによるサーバ監視

2011-11-24T12:45:00.000+09:00

どうも、インフラエンジニアです。名前はfujya.shです。クラウドインフラやってます。

サーバ管理者の間ではプロセス監視なら「daemontools」が定番ですが、個人的には設定が面倒で（慣れればどうという事は無いのですが）あまり利用していません。シャノンではプロセス監視の新定番として「monit」を激しくお勧め致します。設定が簡単でそれこそ誰でもプロセス監視ができる代物です。

■monitとは

総合監視デーモンとしてファイルシステムからHTTPレスポンス内容・プロセス監視などの機能を持っています。GPLライセンスでLinux/BSD/Solaris上で動作可能です。CentOSならDAGリポジトリからyum installもでき、configも簡潔ですので15分程度で導入ができます。

http://mmonit.com/monit/

ではさっくりインストールから基本設定、sshdの監視用のコンフィグを書いてみましょう。

※　今回はCentOS5系で試してます。

■インストールから基本のconfig作成
インストールを始める前にDAGリポジトリが設定されている事が前提となります。

◯インストール

yumでインストールできますので、

# yum install -y monit

これでインストール完了です。ブログ公開したタイミングではバージョンは5.2.5-1.el5.rfです。最新版は5.3.1ですが、tar.gzの中にはspecファイルも含まているので簡単にrpmも作れます。

◯コンフィグの設定

基本のコンフィグを/etc/monit.confに設定します。下記はサンプルになります。

set daemon 60

set logfile syslog facility log_daemon

set mailserver  mail1.example.com,    # primary mailserver
           mail2.example.com     # secondary mailserver
set mail-format {
from: monit@example.com
subject: $HOST : $SERVICE - $EVENT
message: Monit
ACTION  : $ACTION
SERVICE : $SERVICE
at $DATE on $HOST.
DESCRIPTION : $DESCRIPTION
}
set alert server_alert@example.com
include /etc/monit.d/*.conf

一行づつ解説していきましょう。

set daemon 60

監視の実行タイミングを設定します。多くの監視ソリューションでは最短1分間隔のものが多いですが、monitでは秒単位で監視の設定ができます。あまり短くしすぎると負荷が高くなる可能性もあるので監視内容に応じ適切に設定しましょう。

set logfile syslog facility log_daemon

ログの設定をします。monitではsyslogでの出力をサポートします。facilityの設定を'log_local0' - 'log_local7'もしくは、log_daemonで設定可能です。

set mailserver  mail1.example.com,    # primary mailserver
           mail2.example.com     # secondary mailserver

メールサーバの設定をします。monitはアラートを送信するのにSMTPサーバを利用します。,（カンマ）区切りで複数台設定できるので、可能であれば複数設定しましょう。

set mail-format {
from: monit@example.com
subject: $HOST : $SERVICE - $EVENT
message: Monit
ACTION  : $ACTION
SERVICE : $SERVICE
at $DATE on $HOST.
DESCRIPTION : $DESCRIPTION
}

アラートメールのフォーマットを設定します。変数も使えるので、monitの公式Documentの「Alert message layout」を参照して、適宜設定しましょう。上記はサンプルから拝借してきました。

set alert server_alert@example.com

アラートの送信先を設定します。こちらも複数行書くことで設定できます。アラートの送信先に応じて「何のアラートを送信するか」の設定が可能です。例えば下記の用に記述すれば、監視スクリプトを実行した時のみアラートを送信する事も可能です。

　alert server_alert@example.com only on { exec }

逆にbut not onと記述すれば対象の動作を除外する事も可能です。

include /etc/monit.d/*.conf

最後にincludeが設定可能です。ApacheのIncludeと同じような振る舞いをします。

■試しにsshdを監視してみよう
それでは実際に監視を記述してみましょう。sshdは落ちたらデータセンター直行しなければいけない重要なプロセスです。ここではsshdが停止したら自動で再起動を試みる監視のコンフィグを記述します。/etc/monit.confにincludeが書いてあるとして、/etc/monit.d/以下にコンフィを追加してみましょう。

check process sshd with pidfile /var/run/sshd.pid
every 2 cycle
group system
start program = "/etc/rc.d/init.d/sshd start"
stop  program = "/etc/rc.d/init.d/sshd stop"
if 5 restarts within 5 cycles then unmonitor

こちらも一行づつ解説していきましょう。

check process sshd with pidfile /var/run/sshd.pid

監視対象のデーモンのpidファイルを指定します。

every 2 cycle

監視の実行タイミングを指定します。set daemonで指定した秒数 × every [num cycle]のタイミングで監視を実行します。[num cycle]の部分をcronと同じ書き方で指定することも可能です。例えばevery "* * * * 1-5"と記述すれば、平日のみ監視するという指定も可能です。

group system

任意のgroupを指定します。monitではgroup単位での動作の制御が可能です。group単位で監視の停止、起動、再起動などができるようになります。

start program = "/etc/rc.d/init.d/sshd start"
stop  program = "/etc/rc.d/init.d/sshd stop"

起動と停止のプログラムを指定します。指定したスクリプトにオプションも指定できるので、上記のような設定が可能です。さらに下記のように記述すると任意の実行ユーザも指定する事が可能です。

　start program = "/etc/rc.d/init.d/sshd start"

　　as uid user and gid users

特に指定が無ければrootユーザでスクリプトの実行がされます。

if 5 restarts within 5 cycles then unmonitor

再起動を試みる回数と、タイムアウトの時間を指定します。何らかの不具合があって再起動を繰り返す場合にこの設定は有効です。上の設定では5回の監視中に5回再起動を実施した場合に監視を停止します。unmonitor以外には任意のスクリプトの実行するexecを指定する事も可能です。

ここまで記述して、monitを起動しておけばOOMにsshdが殺されとしても自動でsshdが復帰されますので、有事の際にデータセンターに直行なんて事は無くなります。

■その他、monitができること

上記まではプロセスの監視と検知後に再起動というコンフィグが書かれていました。その他にもmonitは様々な機能を持ち合わせています。

◯監視対象

・プロセス(pid/ppid)

・ファイルシステム

・ディスク容量（space/i-node)

・ファイル

- サイズ

- パーミッション

- uid/gid

- チェックサム

- タイムスタンプ

・ファイルの中身とパターンマッチ

・ロードアベレージ

・メモリ使用量(サーバ単位・プロセス単位)

・レスポンス内容パターンマッチ(send/expectも可能）

◯アクション

・起動・停止・再起動

・アラートメール送信

・任意のスクリプトの実行

監視対象とアクションを組み合わせて独自の監視を構築することが可能です。見ての通りmonitは内形監視するのには十分な機能が備わっています。簡単なものであれば外形監視も可能なので、小規模なインフラであればmonitだけで事足りる場合があります。

■シャノンでの便利なmonit利用例

◯EC2の消し忘れ防止

シャノンではAmazonEC2を使ってテスト環境を構築しています。EC2では起動した時間だけ課金されるので、消し忘れた時間があると無駄な費用が発生してしまいます。この問題を解決するためにmonitを利用しています。

監視対象：Apacheのaccess_logのタイムスタンプ

アクション：1時間更新が無かったら任意のスクリプトの実行

[サンプル]

  check file auto_shutdown with path /var/log/httpd/access_log
  if timestamp > 30 minutes for 30 cycles then exec
  "/root/bin/autoshutdown.sh"

ポイントはtimestampが30分更新されていない状態が、30回連続で続いたらautoshutdown.shを実行するというところです。これをit timestamp > 60 minutes for 1 cycles then execにしてしまうと、1時間以上停止していたインスタンスが起動時にすぐにautoshutdown.shを実行してしまいます。起動後に30分以内にアクセスすればファイルのタイムスタンプが更新されるので、すぐに停止状態になる事を防げます。

◯メモリの監視、自動再起動

アプリによってはメモリが増え続けてしまうアプリがあります。プロセス単位でメモリの使用量を監視して一定以上に増えた場合に再起動をしてあげる監視を設定しています。

監視対象：プロセスのメモリ使用量

アクション：全体の何%利用したら任意のスクリプトの実行

[サンプル]

check process worker with pidfile /var/run/worker.pid
group system
start program = "/path/to/worker_starter start"
        as uid user and gid users
stop  program = "/path/to/worker_starter stop"
        as uid user and gid users
if memory usage > 7% then restart
if 5 restarts within 5 cycles then stop

ワーカが全体のメモリ7%を超えて利用していた場合に再起動する設定が書いてあります。あまりこういう設定は書きたくないのですが、運用を行なっているとどうしてもこのようなシーンに出会ってしまいます。monitならサーバ管理者の代わりに再起動してくれるので多少運用が楽になるかと思います。

◯Nagiosの監視

シャノンでは外形監視にはNagiosを利用しています。Nagiosが動作している事を監視をするために、Nagiosの監視項目に特定のサーバにHTTPアクセスするものを設定してあります。対象のサーバでmonitを動作させ、Nagiosがアクセスするファイルのタイムスタンプを監視しています。

監視対象：ファイルのタイムスタンプ監視

アクション：1時間更新が無かったらアラートを送信

[サンプル]

 check file check_nagios with path /path/to/nagios_check.dat
  if timestamp > 60 minutes then alert

非常にシンプルなコンフィグですが、これだけでnagiosの監視が可能です。監視しているつもりがいつの間にか止まっていた場合に気づくことができないので、監視は相互監視する事が大事です。

■さいごに

monitはDocumentが充実しているので、簡単に監視項目を追加することができます。

http://mmonit.com/monit/documentation/monit.html

シャノンでは「何か問題があったらmonitで監視項目追加」という運用を行なっています。monitなら独自で作成したスクリプトの実行も可能なので問題からの自己復旧も簡単に構築する事ができます。

大事な事なのでもう一度言います

問題があったら即監視項目追加

これを簡単に実現するソリューションとしてmonitを激しくお勧めします。

15分で始められるので、是非一度試してみてはいかがでしょうか。

100ドメイン以上を運用する企業向けクラウドのWebサーバー（Linux + Apache + mod_proxy_balancer ）

2011-11-16T11:59:00.002+09:00

こんちには、インフラチームのyanaです。
前回のPostgresに続きまして、実際に弊社のサービスで利用しているWebサーバーの
ご紹介させていただきます。

Linux＋Apacheの標準的な構成で、負荷分散と可用性維持のためにApacheの標準モジュールであるmod_proxy_balancerを利用したロードバランサーを導入しています。

上記の構成にした理由は、以下の3つです。

１．複数のFQDN環境でのSSL提供が可能である
２．拡張性や自由度がある
３．上記の２つを実現させ、低コストでの運用できる

１．複数のFQDN環境でのSSL提供が可能である

弊社のサービスでは、個人情報やクレジットカード情報を取り扱う場合があるため
SSLの利用が必須となっています。
お客様には、共有ドメインのご利用か専用ドメイン（お客様が希望されたFQDN）のどちらかを選択いただきます。

現在、運用している専用ドメインは、100個以上ありますが、
この全ドメインを１つのLinuxサーバで稼働しています。

サービスの設計当初から、お客様が専用ドメインを利用することは必須事項の１つでした。

しかし、SSLを利用する場合に問題になるのが、
１つのSSL（FQDN）に対して、１つのグローバルIPアドレスが必要ということです。
そのため、100ドメイン運用するためには100グローバルIPアドレスが必要となります。

SNI（Server Name Indication）など、SSLハンドシェイク前にホスト名を通知する仕組みが
ありますが、利用できるブラウザが限定されIE6など３から4年前に主流だったブラウザ
からは利用できなくなると判断し採用しませんでした。

また、ハードウェアのロードバランサーを検討しましたが
上記の運用方法に合う機器が当時は非常に高価だったため採用を見送っています。

上記の問題をシンプルに解決するために現在も運用しているのが
Linux Karnelの仮想インタフェイスとApacheのIPアドレスベースのVirtual Hostの組み合わせです。

現在は、１サーバでグローバルIPアドレスを64個運用し、そのサーバを２台運用しています。
※　↑のサーバもfujyaが仮想化したOpenVZのサーバなので物理サーバは1台です。

IPv4の枯渇問題があるので実際の確保は難しくなっていますが、
この仮想サーバを追加することで専用ドメインの運用を拡張できるようにしています。

２．拡張性や自由度がある

Apacheを選択したのはモジュールによる拡張性があることも１つの理由です。
その１つが今回のテーマにしているmod_proxy_balancerです。

http://httpd.apache.org/docs/2.2/ja/mod/mod_proxy_balancer.html

ご存じの方が多いとは思うので、設定方法などのご説明は省略させていただきますが
弊社では下記のような使い方をしています。

ApacheのIPアドレスごと（FQDNごと）の設定例

<VirtualHost XXX.XXX.XXX.XXX:443>

    ServerAdmin serveradmin@shanon.co.jp
    DocumentRoot /var/www/html/
    SSLEngine on

    SSLCertificateFile /etc/httpd/conf.d/ssl-file/sample.crt
    SSLCertificateKeyFile /etc/httpd/conf.d/ssl-file/sample.nopass.key
    SSLProtocol -ALL +SSLv3 +TLSv1 -SSLv2

    ErrorLog /var/log/httpd/ssl-error_log

    CustomLog /var/log/httpd/-ssl-access_log  combined

    RewriteEngine On
    RewriteLogLevel 1
    RewriteLog /var/log/httpd/ssl-rewrite_log

    RewriteCond %{REQUEST_FILENAME} ^/application-A/
    RewriteRule ^/(.*)  balancer://application-A/$1 [P]

    RewriteCond %{REQUEST_FILENAME} ^/application-B/
    RewriteRule ^/(.*)  balancer://application-B/$1 [P]

    RewriteCond %{REQUEST_FILENAME} ^/application-B/
    RewriteRule ^/(.*)  balancer://application-B/$1 [P]

</VirtualHost>

mod_proxy_balancer（00balancer.conf）のグループの例

<Proxy balancer://balancer-groupA>
    BalancerMember http://ap-server1:8080 loadfactor=10
    BalancerMember http://ap-server2:8080 loadfactor=10
    BalancerMember http://ap-server3:8080 loadfactor=20
    BalancerMember http://ap-server4:8080 loadfactor=20
</Proxy>
<Proxy balancer://balancer-groupB>
    BalancerMember http://ap-server1:8081 loadfactor=10
    BalancerMember http://ap-server2:8081 loadfactor=10
    BalancerMember http://ap-server3:8081 loadfactor=20
    BalancerMember http://ap-server4:8081 loadfactor=20
</Proxy>


<Proxy balancer://balancer-groupC>
    BalancerMember http://ap-server1:8081 loadfactor=10
    BalancerMember http://ap-server2:8081 loadfactor=10
    BalancerMember http://ap-server3:8081 loadfactor=20
    BalancerMember http://ap-server4:8081 loadfactor=20
</Proxy>

バランシンググループ数で35個運用しています。

【mod_proxy_balancerの機能を独自ツールで補強して利用】

mod_proxy_balancerは、複雑な分散アルゴリズムがありませんが
重み付けを考慮した上で、リクエスト数、またはバイト数での分散を行う事ができます。

また、管理画面（balancer-manager）を利用する事で
特定のワーカーをサービスから切り離すことも可能です。

【事前に切り離した上で、アプリケーションを再起動（メンテナンス）したい】

これは、弊社のアプリケーションがApacheの子プロセスとして実行されるFastCGIを利用していることにも原因がありますが、アプリケーションの起動が終わる前にApacheは起動してしまいます。
この間もApacheは処理待ちのリクエストを受けてしまうため、そのサーバに割り当てられた
リクエストのレスポンスタイムは大きく遅延してしまいます。

また、複数のアプリケーションが同じサーバで稼働している場合もあるため
多くのバランサーグループからDisableにするというケースもあります。

そこで、自社で制作したのが管理画面（balancer-manager）をmechanizeで操作し
一括してDisable、Enableにするツールです。

これを監視ツールやメンテナンスツールに組み込み、障害時やメンテナンス時に自動で
バランシングから切り離されるようにしています。

社内用で使っているツールですが、お役に立ちそうでしたらご利用ください。
https://github.com/Shanon/mod_proxy_balancer_tools
（※　自己責任での利用をお願い致します）

$ ./bl_changer.pl --help
<ex> ./bl_changer.pl --config ./00balancer.conf --domain LBMAN-hostname --group proxy-groupname --range 1-8 --disable
<ex> ./bl_changer.pl --domain LBMAN-hostname --myself --disable
<ex> ./bl_changer.pl --domain LBMAN-hostname --hostname ap-server-hostname --disable

--config -c set 00balancer.conf
--domain -d set LBMAN domain or IP address
--group -g set balancer group name
--force -f if an existing destination
--none-ssl use http request
--disable set disable status
--enable set enable status
--range -r set target serial number for host ex:(1-8)
--myself -m set target my hostname, change all grop (ex `hostname`)
--hostname -H set target hostname , change all group (ex --hostname ap-server-hostname)
--help display help message

このようなオプションを用意しています。
-------------------------------------------------------------
＊＊注意＊＊

ワーカーのホスト名が、
・ap-server1
・ap-server2
の様にホスト名＋数字であることを前提にしているツールです。
-------------------------------------------------------------

mechanizeを利用しているため管理画面のGETパラメータが変わると利用できなってしまうのが
問題ですが、このような方法で自動化を行っています。

balancer-manager以外でAPIなど外部からmod_proxy_balancerを操作できる方法を探していたのですが見つけることができませんでした。何かご存じの方は是非教えていただけると幸いです。

mod_proxy_balancerを利用する上での注意点

弊社で運用した経験上、注意している点があります。

１．httpd restart　をすると、管理画面から動的に指定したステータスやファクターが初期化される

２．グループやワーカーの追加、削除後にgraceful restartすると動作がおかしくなる

３．１Apache上で設定できるワーカー数の合計に上限がある（？

上記には注意して運用しています。
ワーカー数の上限はメモリ管理上存在してもおかしくは無いと思いますが、正確な理由や数は調査できていません。ただ、弊社では100前後のワーカーを設定した際に、設定ファイルの下部ワーカーへリクエストがバランシングされなくなる現象を確認しました。詳細をご存じの方がいましたら、補足いただけると幸いです。

Webサーバーの再起動をしないと動的にはワーカー数を変更できない事が今後の課題です。mod_proxy_balancer以外を利用するしか無いのかもしれませんが。。

簡単なご紹介で恐縮ですが、このような方法でWebサーバー（バランサー）を利用しています。
ハードウェアにより解決するのも１つの方法かも知れませんが、ソフトウェアバランサーでも運用に対応させることは可能です。

Poundより中、大規模環境での運用は人気があると思われるmod_proxy_balancerですが
これから構築される方は、是非ご検討されるのも宜しいかと思います。

余談ですが、シャノンインフラチームでは担当エンジニアを募集中です。
プログラマからインフラエンジニアへ転向を検討されている方でもかまいませんので、
ご興味やご質問がありましたら、お気軽にご連絡ください。
https://shanon-tech-recruit.smktg.jp/public/application/add/30

Navigation TimingとCanvasを使ったページロード時間の可視化

2011-11-09T00:30:00.000+09:00

こんにちわ。開発チームのkoyaです。今回はどんなネタがいいかなと思っていたところ、Measuring Page Load Speed with Navigation Timingという記事でNavigation TimingというAPIがあることを知りました。 Navigation Timingはウェブアプリケーションのパフォーマンスを計測できるJavaScriptのAPIです。 JavaScriptのAPIなのでCanvasと組み合わせて取得したデータを表現してみたらおもしろいかと思いやってみました。

はじめに、Navigation Timingについて簡単に紹介します（元記事により詳しい情報があるので興味を持たれた方は是非そちらを読んでみてください）。その後、Canvasを使ってNavigation Timingの情報をグラフ化してみます。

Navigation Timingの利用

Navigation Timingは２つのオブジェクトnavigationとtimingで構成されます（そのままですね）。それぞれwindow.performanceのプロパティとして提供されます。

navigation: どのようにページへ遷移してきたかの情報
timing: ページロード時の時間情報

現在は最新のFirefoxとGoogle Chrome、IE9が対応しています。

ロード時間の取得

timingオブジェクトではユーザーがページを開こうとしたとき（ナビゲーション開始）からロードが終わるまでの各イベント毎の時間情報を取得できます。取得できるイベントは図のようになります。

それぞれのイベントごとに1970/01/01からの経過時間がミリ秒単位でセットされます。例えば次のような値です。

navigationStart: 1320317663113
redirectStart: 0
redirectEnd: 0
fetchStart: 1320317663113
domainLookupStart: 1320317663113
domainLookupEnd: 1320317663113
connectStart: 1320317663113
connectEnd: 1320317663113
requestStart: 1320317663114
responseStart: 1320317663114
responseEnd: 1320317663115
domLoading: 1320317663118
domInteractive: 1320317663315
domContentLoadedEventStart: 1320317663315
domContentLoadedEventEnd: 1320317663316
domComplete: 1320317663316
loadEventStart: 1320317663316
loadEventEnd: 1320317663316

値が0の場合はそのイベントが起きなかったなど無効なことを表します。それぞれの差分をとることでトータルのロード時間やネットワークレイテンシー、リダイレクトにかかった時間などを計算できます。

ページ遷移情報の取得

navigationオブジェクトにはページ遷移に関する２つのプロパティがあります。

redirectCount: 最終的なドキュメントにたどりつくまで何回リダイレクトされたか
type: ページへのナビゲーション方法

typeには次のいずれかの値がセットされます。

TYPE_NAVIGATE(=0): リンクのクリックやアドレスバーへのURL入力、フォームサブミットなど下記タイプ以外のアクション
TYPE_RELOAD(=1): リロード
TYPE_BACK_FORWARD(=2): 戻るや進むといったヒストリ操作

Navigation Timingはシンプルですが有益な情報が取得できますね。元記事ではAjaxを使って直接データを集めたり、localstorageを使って統計情報を作るといったアイディアが紹介されています。

Canvasによる可視化

実際に使ってみた例を示します。データを収集し統計情報を取ったりするのがおもしろいと思いますが、ちょっと難しいので取得したデータを簡単に表示させてみます。テキストで出すだけではあまり面白くないのでCanvasを使ってみます。

ネットワーク遅延時間

ページロード時間で気になるのは、どのくらい時間がかかったか、そして何に時間がかかったかです。 Navigation Timingのいいところはネットワークのやりとりに使っている時間も取得できるところです。

そこで、このネットワークによる遅延時間がロード時間全体の中でどれくらいの割合なのかを円グラフで表現してみます。

canvas要素

はじめに幅と高さを指定してcanvas要素を追加します。対応していないブラウザのためのメッセージもセットしておきます。

    <canvas width="400" height="300">(キャンバス非対応)</canvas>

ケーキの一切れ

円グラフを作るために扇形（ケーキの一切れ）を描画できるようにします。基本的な図形描画処理なので後々便利なように2Dコンテキストを拡張します。

CanvasRenderingContext2D.prototype.fillWedge = function (x, y, radius, startAngle, endAngle, anticlockwise) {
   // パスをセット
   this.beginPath();
   this.moveTo(x, y);
   this.arc(x, y, radius, startAngle, endAngle, anticlockwise);
   this.closePath();

   // 塗りつぶし
   this.fill();
}

図はanticlockwise（反時計回り）フラグをfalseにした場合ですが、trueをセットすると角度の指定が反時計回りになります。

データの取得

ロード時にデータを表示したいのでonloadイベントで処理したいところですが、 onloadイベント中ではtiming.loadEventEndに値がセットされていません。ロードをきっかけに処理したい場合はsetTimeout()を使います。 setTimeout()のハンドラではloadEventEndに値がセットされた状態で処理することができます。

 window.onload = function() {
     setTimeout(function() {
         var timing = window.performance.timing; // loadEventEndに値がセット済み！
         ...
     }, 0);
 }

円グラフ

準備ができたのでcanvas要素に円グラフを描画します。

window.onload = function() {
   setTimeout(function() {
   // キャンバスとコンテキストを取得
   var canvas = document.getElementsByName("canvas")[0];
   var context = canvas.getContext('2d');

   // データと色情報を準備
   var timing = window.performance.timing;
   var data = [timing.navigationStart, timing.responseEnd, timing.loadEventEnd];
   var colors = ["#933", "#FCC"];

   // 描画位置と半径をセット
   var x = canvas.width / 2;
   var y = canvas.height / 2;
   var radius = 100;

   // 円グラフの描画
   drawPie(context, x, y, radius, data, colors);
   }, 0);
}

キャンバスとtimingデータを取得してdrawPie()関数で円グラフを描画しています。 drawPie()関数の定義は次のようになります。

function drawPie(context, x, y, radius, data, colors) {
   var i, last, startAngle, endAngle;

   for (i = 0, last = data.length - 1; i < last; ++i) {
       // データを角度にマッピング
       startAngle = map(data[i], data[0], data[last], -Math.PI*0.5, Math.PI*1.5);
       endAngle = map(data[i+1], data[0], data[last], -Math.PI*0.5, Math.PI*1.5);
       context.fillStyle = colors[i];
       context.fillWedge(x, y, radius, startAngle, endAngle, false);
   }
}

function map(x, low1, high1, low2, high2) {
   // low1 < x < high1を[low2, high2]の範囲にマッピング
   return (x - low1) * (high2 - low2) / (high1 - low1) + low2;
}

drawPie()関数では開始から終了まで２つの時間データをとり、それぞれ円上の角度に変換して扇形を描いていきます。 map()関数はある範囲にある値を別の範囲にマッピングしています。この場合は時間から角度ですね。

実行すると次のようなグラフが得られます。

トータル時間や凡例を追加したりしたのが次の図になります。

まとめ

Navigation Timingを利用するとユーザー体験よりのパフォーマンス情報が簡単に得られることが分かりました。また、Canvasを組み合わせてデータをグラフ化してみました。今のところ新しいブラウザでしか対応されてはいませんが、シンプルで扱いやすいためパフォーマンス解析の手段として活用していければと思います。

参考

1: Measuring Page Load Speed with Navigation Timing

2: W3C Editor's Draft - Navigation Timing

3: HTML Living Standard - 4.8.11 The canvas element

産休・育休のシャノン体験談　その一

2011-11-04T02:59:00.011+09:00

こんにちは、技術部QA所属のおかもとです。

今年の4月に復帰するまでの1年半、育児休業でお休みを頂いておりました。
うちの会社は在籍している社員の平均年齢が若く、女性社員も少なかったことから、私が産休・育休を取得する２人目の社員でした。そんなわけで今回は社内でリクエストがあったので、2部に分けて第一回目は産休・育休・復職後に関してのシャノン社員としての体験談、
第二回目は産休・育児休業中に貰える具体的なお金や手続きに関してを時系列のポイント毎にまとめてみようと思います。

前述の通り圧倒的な症例数の少なさ故、私は聞ける人がいなかったのですが、皆さんも多分こんな事を聞きたいだろう・・というあたりをまずは勝手に予想して書いてみようと思います。

Q1.「妊娠中の仕事のペースはどんな感じですか？」

A1.直属のリーダーに早めに相談し、仕事のペースを調整して貰ったため、妊娠前よりも余裕を持って仕事に取り組めました。つわりがひどかったので通勤に一番苦労しましたが、ラッシュ時をはずしての通勤等柔軟に対応してもらいました。

Q2.「産休に入る時期は調整できますか？」

A2.国で定められている産前6週間から休みを取れる・・だけでは、かなり過酷です(個人差もありますが、その頃にはお腹がパンパンです・・)。私の場合は里帰り出産で飛行機に乗る予定もあったので、産休の前に有給をくっつけて早めにお休みを頂きたいとお願いしたのですが、本人の意向に沿う形で対応してもらえ助かりました。

産休に入る前に会社の人たちがお疲れさん会をしてくれました。そのときのケーキです♪

Q3.「ベンチャーだけど大丈夫・・？」

A3.就職説明会等に来ている女性の方とお話すると必ず聞かれるのがここです。
皆さん「ベンチャー＝福利厚生が整備されていない？」とか、「IT＝女性がやっていくにはきつい職場？」というイメージがあるようですが、そんな事はありません(笑)。
福利厚生に関しては、産休・育休中に色んな免除や給付金を申請する先は雇用保険や健康保険組合ですし(当然うちの会社も入ってますし、他の会社もそこは同じなのでたいした差異はありません)、
復職してからも、肺炎だ・・！インフルだ・・！手足口病だ・・！！と、次から次へと子供が病気をしますが、周囲の理解と協力が得られているからこそ仕事を続けられていると言って過言ではありません（笑)。
・・よって、うちの会社がベンチャーだから・・ITだから・・といって不自由したことは何もないのです。

Q4.「仕事を辞めようか・・それとも産休をとろうか・・それが問題だ」

A4.よく産休に入る前に退職してしまう方がいます。私の周りにもそういうママさんたちは沢山います。
・・そしてたいていの場合、もし退職しないで休業していたらどれくらいの補償があったのか？？というのを全く知らないままに仕事を辞めてしまっています。・・勿体無すぎる・・(涙)
もし、今後も働きたい・復帰したいという意思が少しでもあるなら、仕事は続けることを私はお勧めします。

仕事と子育てが両立できるのか？とか、会社に迷惑がかかってしまうのでは・・？は誰しも考えますが、会社が復職するまで待ってくれると言ってくれるなら、ありがたく復職してみてから仕事が続けられそうかは考えても遅くないと思います(都合が良くてすいません・・中村さん)。
現に私はそうしたのですが(笑)、近くに身内もおらず、旦那も仕事が忙しく、子供は体力有り余ってて寝ず、エンドレス寝不足・・みたいな修行を一年半した後だったので、ランチを同僚とゆっくり食べられる会社はかなりの気分転換にもなってます(笑)。

では、ここでこんな資料を見てみます。
以下の資料は、働いているときの給与所得別に給付金が幾ら貰えるのかを算定したものです。

給与総額が18万円の人の場合
出産育児一時金 + 出産手当金 + 育児休業給付金　→　約172万円貰える

給与総額が26.5万円の人の場合
出産育児一時金 + 出産手当金 + 育児休業給付金　→　約232万円貰える

給与総額が32万円の人の場合
出産育児一時金 + 出産手当金 + 育児休業給付金　→　約273万円貰える

どうですか？
結構な金額ですよね(笑)。
もし仮に出産する前に自己都合で退職したら、出産育児一時金(現在は42万円)の他は一切支給されないお金になります。
つまり復職意思があって産休・育休に入ると働けない間の休業補償が出るのに対し、退職してしまうと上記の給付金は補償されません・・また育児休業中には手続きすると社会保険料も免除されることを考えると、その差は歴然です。

では、次回はいよいよ時系列に手続き関連の話をしていきたいと思います。

会社の方たちが産休前にくれたプレゼント。それぞれに頑張って選んでくれたのが分かります(笑)。。今でも子供のお気に入りもあります。

Jenkins, Seleniumを使った自動テストの課題とこれからの取り組み

2011-11-01T18:38:00.015+09:00

こんにちは。QAの井上です。

今回は現在QAチームで行っている自動テストに関する課題、それに対する取り組みについて紹介します。
まだまだ詰めが甘いところがあると思うで、フィードバックいただけるとうれしいです。

早速ですが、QAチームではCIツールにJenkinsを使用していて、約8割がSeleniumによるテストケースでできています。
テストケースの作成から実行まではざっくりですが、以下のようになっています。

- テストケースはFirefoxのIDEを使用して作成
- 作成したテストケースはSVNに保存
- 毎日夜中に最新のソースコードに対してテストを実施
- テストの実施は、Jenkinsのseleniumhqプラグインを使用して、複数台のクライアント(Windows)上でSeleniumRCサーバーに直接テストスイートを渡すことで行う
- テストで使うクライアントはWindowsでブラウザはFirefox
- テスト結果を次の日に確認

テスト実行の流れを図にするとこのようになります。
基本的にSeleniumRCのマニュアルに書いてあることと同じなのですが、SeleniumRCサーバーがテストスイートを直接実行する所がちょっと違いますね。

Jenkinsを導入することで、毎日最新のソースコードで、決まった時間に自動でテストが実行されるようになっているのですが、次のような課題を抱えて困っていました。。。

(1) ソースコードを何も変更していないときでも、必ずしも毎回テストがパスしない
(2) テストが失敗した時は、テストが実行されるPC(Windows)にリモートデスクトップで繋いで、再度テストを実行しながら動作を確認したりするのですが、リモートデスクトップは複数人で同時に接続できないので、誰かが接続すると切られてしまう
　あと、できれば仮想化したい
(3) IEなどの他のブラウザでもテストしたいが、(1)の課題が頻発して使えない

そこで、これらの課題に対してどのように取り組んでいるのか(取り組んで行こうとしてるのか)について書いていきます。

まず、大きな課題である(1)に対してです。
ソースコードを何も変更していないにも関わらずテストが失敗したりするのは致命的ですよね。
これまでも何度も調べていたのですが、結局どう対策したらよいのか分からなかったんです。。。
しかし、最近やっと解決方法らしきものを見つけました。

How to Lose Races and Win at Selenium

で、この方が言うには、問題なのはSeleniumの実行が早く、ページのロードと競争しているからだそうです。

The problem is that Selenium is overeager, and it needs to chill out and wait.
Selenium tests often fail because they’re too fast.
Selenium will interact with a page at the speed of code, before the page is ready.

There are several ways for a page to be “loaded,” and Selenium doesn’t wait for the right one.
It races your page’s loading logic, often “winning” the race and clicking on things before they’re ready to be clicked on.
You need Selenium to lose the race.

これに対する解決作として、SeleniumRCサーバーに対して繰り返し waitForTextPresent などを成功するまで何度か送ってみるといいと言っています。

wait_for_text_present will repeatedly ask the Selenium server whether the text is present until it shows up.

なるほどー、って感じですね。
そこで、まず変えなければいけないことは、テストスイートを直接SeleniumRCサーバーに投げていたことです。
そのために、次のように変更しようとしています。

1. テストスイート、テストケースは現状のままFirefoxのIDEで作成する。
　これはやっぱり作成やメンテナンスが楽だからです。なので、保存しておくのもHTMLのものになります。
2. 作成したテストスイートをJavaのソースコードにエクスポートする
3. 出力したJavaコードをコンパイル、実行することでテストが行われるようにする

このように一度Javaに変換することで、テストの実行を自分たちでコントロールできるようになり、この課題に対してある程度解決できるようになるのではないかと考えています。

次に、(2)の課題に対してですが、PCを追加すれば解決できるのですが、1台あたりのリソースはまだまだ余っている状態っていうのと、増やすたびにお金かかる(Windowsのライセンスを買わないといけない)っていうのもちょっと嫌だったんでどうしようか悩んでいました。

で、クライアントPCをLinuxにすればいいんじゃない??と思い、まずLinuxのFirefoxでテストを実行してみると普通に動いたので単純にクライアントPCをLinuxにしようとしています。1台のHWに複数の仮想マシン(Linux)を立て、動作を確認するときはVNCで接続するっていう方法です。
あと、Jenkinsから実行するときにどのディスプレイで実行するかはこちらでいけるんじゃないかと思っています。うまくいけば、複数人で同じHWを共有で使えるようになります。
http://www.linux-archive.org/centos/463349-how-run-command-specific-vnc-display.html

最後に(3)の課題に対してですが、こちらは(1)の課題を解決することで同時に解決できると思っているのですが、どうせなので少し前にリリースされたSelenium2系(WebDriver)も試していきたいと思っていて。。。

WebDriverはSeleniumRCと違ってJavascriptでの実行という方法ではなくネイティブなAPIを使ってブラウザを実行するようなので、クロスブラウザの問題がクリアできるらしく、またブラウザのサポートもIphone, Androidまで対応しようとしているらしく広いみたいです。

情報源はこちら(もしかしたら少し古いかもしれません)
- SeleniumRC ブラウザサポート
- WebDriber ブラウザサポート

といった感じで、現状抱えている課題とそれに対する取り組みについて書いてみました。
今回書いた内容に関してはまだまだ取組中で変わっていくと思いますので、ある程度できたら構築中のはまりポイントなどを一緒に取り組んでいるメンバーが紹介してくれると思います。

それでは。

YAPC::Asia TOKYO 2011 に参加してきました

2011-10-18T11:34:00.009+09:00

先週末に行なわれた YAPC::Asia TOKYO 2011 に初めて参加してきました。

Yet Another Perl Conference (YAPC) はPerlプログラミング言語の進歩を目的とする草の根のシンポジウムです。 (http://yapc.orgより抜粋）
[上記サイトより転記]

東京工業大学が会場だったのですが、1日に3会場あるうちの100周年記念フェライト会議室はあまり大きい部屋ではなかったせいか、いつも立ち見の人や床に座って見る人がたくさんいました。そしてせっかく席に座れたのだから…とつい長居してしまいました（笑）

現在の仕事で役に立ちそうなセッションということで、パフォーマンスとセキュリティと品質向上を中心に聞いてきました。アプリ開発目線です。
詳しい内容については、発表資料を見たほうが正しい情報が得られると思いますので省略します。

○パフォーマンス
Webアプリケーション高速化
Mobage オープンプラットフォームの事件簿
一般的な解決方法として紹介されていた、不要な処理をしないこと、キャッシュすること、まとめて処理することは、現在まさに対応中です。これらについては今やっていることが正しかったのかなと確認できて少々ホッとしました。
『Webアプリケーション高速化』のほうの話で、特に、何ミリ秒単位で少しずつ処理を高速化するよりは、不要な処理を行なわないように考えたほうがいいという話は、最近の仕事ではそのような修正をすることが多く体験済みだったので納得しました。明らかなボトルネックがあるときの対処法ではありますが。
そして、あまり一般的ではない解決方法として挙げられていたキャッシュのウォームアップについても、弊社でも使ったら効果が出そうなので興味があります。

○セキュリティ
新はてなダイアリーの裏側
Webアプリでパスワード保護はどこまでやればいいか
『新はてなダイアリーの裏側』はセキュリティの話が中心ではなかったのですが、XSS対策のiframeでドメインを分ける話は考えたことがなかったので新鮮でした。
『Webアプリでパスワード保護はどこまでやればいいか』はパスワードのハッシュ値が漏えいした場合はどの程度安全なのか、より安全にするにはどうしたらいいか、という話で、普通のハッシュ値だけでは全然安全ではないということがよくわかりました。

○品質向上
他言語から見たPerlのテスト
開発エンジニアが品質のよいコードを作って、QAエンジニアの負担を減らすことが最近ますます重要になっているテーマなので、テストの話も聞いてきました。
弊社の場合は、ユニットテストが Test::Class をベースとしたもの、ビルドテストが Test::WWW::Mechanize をベースとしたものなので、出てきた内容と近いと思います。

Perl 限定で他社のリアルな話を聞くことができる場はあまりないと思います。共通の問題意識があることを確認できたり、それらの解決方法についても新しく取り入れてみたいと思う情報を得ることができました。たまにはこういう場から情報を得るのも楽しくていいものです。
情報を得るだけではなく、製品開発に活かしていけるように意識を持っていたいと思います。

数百GBのPostgreSQLを一瞬でバックアップする方法

2011-10-17T12:51:00.003+09:00

こんにちは、インフラ部門のYanaです。

本日は、弊社で利用しているPostgreSQLのバックアップ取得方法についてご紹介します。

弊社は、データベースにPostgreSQL8.4系を利用しています。

定期的なバックアップとして一般的なpg_dumpも利用していますが、
データベース容量が数100GBになると数時間バックアップ時間を要してしまいます。

通常はこのバックアップ時間でも問題ありませんが、サービスの運用上この時間を許容できないシーンがありました。

バージョンアップの作業時間を短縮することが目的

弊社では、3ヶ月に1回提供アプリケーションのバージョンアップが行われます。
その際に、作業内容によってはデータベースの変更が行われます。
万が一、作業で問題があった場合は作業前の状態にロールバックする必要があります。
そのため、メンテナンス画面を表示し、リクエストの遮断した後にデータベースのバックアップを取得します。
しかし、バックアップに数時間を要してしまうとメンテナンスによる停止時間が大幅に増加してしまいます。この時間を削減するために運用を開始したのが、今回ご紹介するバックアップ取得方法です。

元々、冗長化のためにPITRを利用したレプリケーションを利用していました。

PITRについての詳しい解説はこちらが参考になります。
http://www.postgresql.jp/document/current/html/continuous-archiving.html
(PostgreSQLマニュアル　継続的アーカイブとポイントインタイムリカバリ)

http://lets.postgresql.jp/documents/technical/backup/3
（Let's PostgreSQL 物理バックアップの概要）

簡易イメージだとこんな感じです。

このような形で、アーカイブログ単位で待機系サーバのデータベースを更新しています。

完全な同期型ではありませんが、ほぼリアルタイムにデータはレプリケーションされていますので

Activeサーバが停止した場合は、Standbyサーバに変更するだけでサービスを再開できます。

ファイルシステムのスナップショットの仕組みを参考に

短時間のバックアップが目的でしたので、試行錯誤の結果ファイルシステムのスナップショットの仕組みに注目しました。そして、それをPITRを利用して再現することでデータベース版のスナップショットにしたのが下記のイメージ図です。

このように、PITRをStandbyサーバだけでなく、３台でレプリケーションさせてしまいバージョンアップなどメンテナンス作業前に分離することで、瞬時にバックアップを取ることできると考えました。

こうすることで、Snapshoｔサーバは切り離した時点のデータ状態のまま維持されますので万が一メンテナンス作業を中断し全て元に戻す必要がある場合はSnapshotをActiveのデータベースとして利用すれば良いわけです。

（社内では、元になったアイデアからSnapshotサーバと呼んでいます）

この仕組みを採用し、開始当時で３から４時間メンテナンスによってサービスが停止する時間を短縮することができるようになりました。

このデータベーススナップショットの仕組みは、このような課題があれば有効です。

　データベースサイズが大きくpg_dumpではある程度時間がかかる
　短時間にデータベースのバックアップを取得する瞬間がある
　世代バックアップである必要が無い
　構築コストをできるだけかけないようにしたい（OSSのみで実現したい）

当然ですが、デメリットもあります。

　一度止めたSnapshotサーバを再びレプリケーションに復帰させるのには時間がかかる

構築方法は通常のPITRに追加して３つだけ

【アーカイブログを共有する】

弊社では、Activeのデータベースサーバーが各Standby（Snapshot）サーバをNFSでマウントしログを書き込んでいます。

マウントのイメージ

XXX.XXX.XXX.XXX:/var/lib/pgsql/nfs/archive_log/standby-server/
***G ***G ***G **% /var/lib/pgsql/nfs/archive_log/standby-server/

XXX.XXX.XXX.XXX:/var/lib/pgsql/nfs/archive_log/snapshot-server/
***G ***G ***G **% /var/lib/pgsql/nfs/archive_log/snapshot-server/

【アーカイブコマンドでスクリプトを使う】

postgresql.conf

archive_command = '/home/public/tools/archive_copy.sh %p %f </dev/null'

【スクリプトでアーカイブログを2箇所に保存する】

※スクリプトの例
/home/public/tools/archive_copy.sh

#!/bin/bash

basefilename=$1;
copy2filename=$2;
copy2path1='/var/lib/pgsql/nfs/archive_log/standby-server/';
copy2path2='/var/lib/pgsql/nfs/archive_log/snapshot-server/';

cp -i $basefilename "$copy2path1/$copy2filename";
cp -i $basefilename "$copy2path2/$copy2filename";

この３つの作業を行うことで、アーカイブログが各Standbyサーバ、Snapshotサーバに転送され
復元され続けますので非同期ではありますがデータベースをレプリケーションできます。

後は、必要に応じてSnapshotサーバのアーカイブログの読み込みを止め、PostgreSQLを起動してしまえばその時点のデータを分離させることができます。

弊社では、アーカイブログの読み込みにpg_standbyを利用していますので、トリガーファイルを特定の場所に設置するだけで読み込みが停止されます。

パフォーマンステストをまとめてみた

2011-10-10T00:24:00.010+09:00

こんにちは。

QAのinomataです。

パフォーマンスの問題は、顕在化するとシステム停止や機能の停止を余儀なくされたりと、インパクトが大きい可能性が高いです。個人的な位置づけだと、

セキュリティテスト　≒　パフォーマンステスト　>>　機能テスト

くらいだと思ってます。しかもパフォーマンスの問題は修正が大変（すぐ修正できない）な場合が多いので、しっかりテストをやっておく必要があります。

ただ、ひとつの問題として、何をすればいいのか分からないんですよね。私自信も、最初は何をすればいいのかわかりませんでした。パフォーマンステストはセキュリティテストに次ぐ重要度にもかかわらず（恣意的）情報が少ないのです！！本屋に行ってもそんな本はほとんどありませんし、Google先生に聞いてもJmeterの使い方くらいしか出てきません。とは言ってもどうにかやらなくてはいけません。

今回は私がどうにかやってきた、パフォーマンステストの進め方ポイントをまとめてみたいと思います。

まずパフォーマンステストの目的を決めよう

パフォーマンステスト（性能評価）といってもいろいろあります。同時にどれくらい使えるのか、連続稼働時間がどれくらいなのか、レスポンスはどれくらいか、システムがどこまで耐えられるか。パフォーマンスを測りたいからには目的があるはずなので、それを決めましょう。

目的が決まったら要件を決めよう

具体的な数値を持って要件を決めましょう。上記の例であればこんな感じ。

・同時にどれくらい使えるのか→同時1000ユーザーの使用を保障する

・連続稼働時間がどれくらいなのか→300時間の連続起動ができる

・レスポンスはどれくらいか→1秒以内でレスポンスがある

・システムがどこまで耐えられるか→平常時の倍の負荷まではシステムがダウンしない

要件がない場合、200%の確率で後で問題になります。webシステムであれば以下のようなテンプレートがあればよいでしょうか。

・単位時間当たりの処理数

・同時使用数

・応答時間

・エラー率

これらはお互いに関連性があるので、どれも抜けてはいけないのです。これ以外の重要な項目がないかも検討してください。

テストケースを考えよう

要件も決まったのでテストケース組んでいきましょう。その際のポイントをいくつか紹介します。

・テストケースはユーザーの操作を意識する

テストはユーザーの操作に忠実でなければ、本番の挙動とかけ離れてしまいます。ここはユーザーの操作をシミュレーションしましょう。たとえば買い物サイトの場合以下のような操作がありますが、具体的にはこれらを網羅していきます。

・どこのカテゴリを見るのか。

・どれくらい検索するのか

・いくつ買うのか

・レビューを書くのか

・etc

ただこのような操作パターンはほぼ無限なので、全部を再現するのは現実的ではありません。どうにかこうにか間引いて、現実的なテストにしましょう。ABC分析とかが使えそうですね。またファイルダウンロードなど、パフォーマンス的に高負荷となる操作が別にあるのであれば、それは別枠で考える必要があります。

ひたすらログイン/ログアウトを繰り返すユーザーはそうそういません。申込フォームの開始から登録まで5秒で完了するユーザーもそうそういません。本番を想定するテストであれば画面遷移、参照する機能、入力フォームでのユーザーの思考時間等を考慮する必要があります。

・使うデータの検討

毎回同じデータを参照した場合、キャッシュによってパフォーマンスが良くなる場合があり、テスト結果の信頼性にかける場合があります。参照、または登録するデータは本番と同じようなデータにしましょう。

・テスト環境とタイミング

本番でのパフォーマンスを図りたいのであれば、本番と同じシステムを用意するか、本場でテストするしかありません。テストの目的に合わせてシステムの構成（ネットワーク機器、ロードバランサ等も含める）、リクエストを送る場所（ファイアーウォール越しかどうか等）、定期バッチ処理のタイミング、本番で稼働させる各サービス等も考慮しなければなりません。

・エラーの定義を決める

テストのエラーになる条件を決めます。HTTPのエラーコードが返ってくればエラーなのか、専用のエラーページを表示すればエラーなのか決めておきましょう。専用のエラーページはHTTP的にはエラーではないので、Jmeterではアサーションを仕込むなど、ひと手間必要になることを忘れずに。

・ログは何を見るか

何を見るのかは重要です。リクエストをかける外側と、処理を行う内側のログをとります。内側のログは、ログを出すこと自体がシステムに負荷をかける場合があります。ログの出力は、目的に合わせて必要最小限に抑えるのがよいでしょう。

・どれくらい負荷をかけるのか

基本的に要件を満たす分、ピーク時を想定した負荷の2種類があれば望ましいでしょう。信頼あるデータが必要なので、現実的な範囲で負荷をかける必要があります。過大、過少になってはいけません。

上記でもありますが、各要件を矛盾しないような量にしないとダメです。

・どうやってテストするのか

同時1000人のログインとかは手動じゃできませんよね。パフォーマンステストは、基本的にツールを使わなければ実現できません。どんなツールを使って、どうやって結果を判断できるのかを事前に検討しておきましょう。なんだったら外部に委託してしまうのも手でしょう。専門家に任せるのと、リスク移転の意味を込めて。

テストは繰り返しできるように準備しておくことも重要です。本番を使う場合は時間的な制限があったりするので、なるべく短い時間でかつ繰り返し実行できるようになっているとよいです。また、ボトルネックは一回のテストで一ヶ所しか発見できません。システムのパフォーマンスは一番のボトルネックに引きずられます。なのでパフォーマンステストは、テスト→修正→テスト→修正→テスト...と繰り返すことは必然です。となるとやはり繰り返し実行できることは重要です。ボタン一つで実行できるほど簡素化されているとよいですね。

テストを実行しよう。

いよいよ作成したテストを実行します。ここまで事前に準備してきましたが、実行中でしかわからない情報もある場合もあるので、実行中は人が立ち会った方がよいです。

結果を検討しよう

得られた結果が決定した要件に沿った結果かどうかを検討します。結果の検討は一番重要かつ難しいフェーズです。応答時間などの外側からの結果とサーバのCPU等の内側の結果を突き合わせて、何が原因かを探ります。このためにも適切にログをとりましょう。有識者からのヒアリングもしましょう。

その他

・いつテストしたらいいのか

なるべく早い方がいいには越したことはないですが、早すぎてシステムが動かなければ意味がありません。これはなかなか難しいのですが、開発の段階で小さい機能から段階的にテストをしていくのが一番です。パフォーマンステストはいきなりシステム全体をテストするという性質から、原因の究明が困難になりがちです。まして後工程では修正が困難な部分に手を入れなくてはならないと最悪なので、やはり小さい機能のうちからこまめに計測しておくのがよいでしょう。

・誰がやったらいいのか

これはいろんな分野の人が数人集まった方がよいでしょう。数人で意見を出し合った方が解析や検討が早いでしょう。重要なテストなので、それなりにコストをかけて取り組みましょう。

さて、一通り書いた感じですが、考えることがいっぱいありますね。これでもまだ十分ではないでしょう。大変すぎます。しかし手を抜くと何十倍ものコストで跳ね返ってくるので、プロジェクトがアツくなる前にしっかりテストしておきましょう。

ちょっと面白いjavascriptコード

2011-10-03T13:07:00.009+09:00

はじめまして、技術部のou.gと申します。先月の中旬に中途として入社しまして、QAチームに配属となりました。

最近は弊社のサービスSHANON MARKETING PLATFORMのXSS対応テストを担当しています。最初にXSSを調べた時に、このPDFの４０ページ目に乗っているちょっと面白いソースコードを見つけていました。すでにご存知の方も多いかもしれませんが、みなさんとシェアしたいと思います。

記号だけ英数字の使わないjavascript：

・コード１

($=[$=[]][(__=!$+$)[_=-~-~-~$]+({}+$)[_/_]+($$=($_=!''+$)[_/_]+$_[+$])])()[__[_/_]+__[_+~$]+$_[_]+$$](_/_)

・コード２

([,Á,È,ª,É,,Ó]=!{}+{},[[Ç,µ]=!!Á+Á][ª+Ó+µ+Ç])()[Á+È+É+µ+Ç](-~Á)

上記の２つともはalert(1)と相当する合法的なjavascriptです。※但しブラウザ依存があります。

このような記号だけ英数字の使わないコードはどう動いてますか。

コード２のほうは短いから、実装のほうもコード１より巧妙だと思いますので、例として簡単に説明させて頂きます。

まず、読めない記号を読みやすいものに置換しましょう。

Á→AÈ→Bª→CÉ→DÓ→EÇ→Fµ→G

コード２は次のようになります。

([,A,B,C,D,,E]=!{}+{},[[F,G]=!!A+A][C+E+G+F])()[A+B+D+G+F](-~A)

次は、ソースをフォーマットして、もっと読みやすくなってみます。


(
  [,A,B,C,D,,E]=!{}+{},          //1
  [[F,G]=!!A+A][C+E+G+F]         //2
)()                              //3
   [A+B+D+G+F](-~A)              //4

これから行ごとに説明しましょう。
1.
"!{}+{}"の結果を変数A,B,C,D,Eに一括代入 ※firefox特有な代入方式

空オブジェクト{}がNULLではないので、!{}がfalseになります。!{}+{}を計算するときに、falseとオブジェクトが数字ではないので、それぞれ文字列にキャストされ、加算ではなく文字列の連結が行われます。

false→文字列"false"

{}→object.toString() = "[object Object]"

よって、


[,A,B,C,D,,E]=!{}+{} = "false[object Object]";
A="a"
B="l"
C="s"
D="e"
E="o"

2.
まず、"!!A+A"の結果を変数F,Gに一括代入します。

[F,G] = !!A+A = !!"a" + "a" =!false + "a" = true + "a" = "truea"

よって、

F="t"G="r"

次、今まで作成した変数C、E、G、Fを使って、値の代入を行います。

[C+E+G+F] = "s" + "o" + "r" + "t" = "sort"

よって、

[[F,G]=!!A+A][C+E+G+F] = [["t","r"]]["sort"] = Array.prototype.sort

3.
カンマ演算子の使い方は左から右へ実行して、一番右の値を返すのです。

よって、コメント1とコメント２の結果はコメント２の値となります。

(Array.prototype.sort)() = window

※window取得の説明はこのリンクをご参照ください。

注意すべきなのは、Array.prototype.sort()でwindowが取れるかどうかはブラウザの実装に依存するので、ブラウザのアドレスバーに下記のコードを入力して確かめてください。

javascript:v=[].sort;alert(v());

"[object Window]"のようなalertが出てきたら、今のブラウザはこの方法でwindowの参照が取れることが分かります。
4.
これから、簡単ですよ。

変数Aが数値に変換できないので、0として処理されることになります。

-~A = -~"a" = -~0 = 1[A+B+D+G+F](-~A) = ["a"+"l"+"e"+"r"+"t"](1) = ["alert"](1)

最後

([,Á,È,ª,É,,Ó]=!{}+{},[[Ç,µ]=!!Á+Á][ª+Ó+µ+Ç])()[Á+È+É+µ+Ç](-~Á) = window["alert"](1) = window.alert(1);

ちょっと面白いでしょう。^o^

追記
最初にこの素晴らしいアイデアを出したのは、日本の技術者@hasegawayosukeでしたと思います。公式サイトはこちらです。http://utf-8.jp/

Dreamforce '11に参加してきました

2011-09-15T12:38:00.000+09:00

こんにちは、堀です。

先日、サンフランシスコで開催されたDreamforce 2011に参加してきました。

Dreamforceの実際の模様はいろんな記事がありますので、そちらを参照していただくとしてここでは僕が現地で感じたことなどをざっくりレポートしようと思います。

基調講演：

ライティングがかっこいい会場

ソーシャルエンタープライズがテーマ

今回のDreamforceのイベントのテーマは「Social Enteprise」でしたが、基調講演では「顧客がソーシャルに」「社員がソーシャルに」「製品がソーシャルに」という形でソーシャルを軸に話がされました。

企業にとってのソーシャルは僕もまだビジョンがそこまで感じ取れているわけではないですが、話を聞きながら、ひょっとして欧米企業の価値観が昔の日本的になっているのかも...って感じました。

日本では昔から意識を「共有」することにあまり抵抗がなく、パーティションのないスペースで一緒に仕事したり、仕事の後に頻繁に飲みにいったり、井戸端会議でちょっとした情報を立ち話で共有したりと昔から「social」でしたが、アメリカのような国土の広い国では、仕事の後にちょっと食べたり飲んだりとかそういうゆるい感じのつながりというのは地理的成約もあって比較的少なかったのではないかと思っています。

それがFacebookやChatter、Twitterなどでオンラインで実現手段ができてきて、欧米にも広まってきたのが今であり、日本にも価値観として逆輸入されてきている気がします。

また、講演の中でWinter12ではチームでのフォーキャスト（売上予測）が機能実装される予定とあり、これはまさに個人業績主義ではなく、日本型のチーム営業（集団で意思決定＆ミッション遂行する）のエッセンスが入ってくる予兆なのではないかと思っています。

マーク・ベニオフがなぜこんなにChatterへ注力しているのかを考えてみたのですが、まったく個人的な予測ですが以下の二つがあると思っています。

1. 社員にとってのFacebook型業務アプリ？

個人的にFacebookとTwitterをいろいろ使っていて思うのですが、Facebookの大きな違いは人と人の関係性の重みを軸に、タイムラインに出すデータを自動的に最適化してくれるということです。

つまり「何も考えなくても」リロードするだけで、仲の良い人の写真や、コメントなどが現れるようになっています。Twitterはタイムラインが時系列に流れていくだけなので、こうはいきませんね。

で、Chatterは今はTwitter的なものだと思うのですが（間違ってたらすいません）、今後は企業内のソーシャルグラフを元に、自分に関連する商談や、顧客、社内の各業務が浮かび上がってくるようなインターフェースになっていくのではないかと思っています。そのために今、懸命にChatterに情報を一本化しようとしているのではないかと。

まだ企業サイズが小さい弊社でさえ、最近は業務アプリが増えてきて、いろんなサイトに行かないと業務が遂行できません。「あれ、これどうやるんだっけ。。これどこだっけ。。」なんていうのもしばしばです。僕ももし、業務が一つのアプリだけで完結できるってなったら素晴らしいと思います。

きっと「Chatterだけ見てれば誰でも業務が遂行できる」というレベルまで昇華させようとマークは考えているのではないかと基調講演を見て感じました。

2. 業務アプリメッセージからの脱却

Salesforce社も実際にメインビジネスとしているのはSFAやCRMを販売するということは間違いないと思います。ただ、CRMやSFAは業務として成熟化してきており、基本的な機能であればおそらくOracleやその他の競合と大差がないのだと思います。

ただ、現在ほぼ無償であるChatterをメッセージのキーに添えることで、次のソーシャルというビジョンを顧客に見せることができるのが大きいのだと思います。顧客は今は積極的に社内ソーシャルに取り組んでいなくても、無償であればとりあえずやってみようかと思いますし、他と機能差がなければ未来が見える方にかけてみようかという気になるものです。

Heroku for Java：

盛り上がってたHeroku展示ブース

今、PaaSプラットフォームはいろんなものが出てきていてまさに黎明期の様相ですが、数少ないJavaのPaaSプラットフォームとしてHerokuは大きく期待したいところです。早くインフラのパフォーマンスを気にしなくてよくなる世の中になって欲しいと個人的にも思います。。

Force.com/Apexは企業向けPaaSとしては非常に良いコンセプトだとは思うのですが、プログラミングするエンジニアの立場に立ってみると「俺の大事な時間をベンダーロックインの技術に投資するのか・・」となり、なかなか時間を投資するのには勇気がいります。そこがApex普及の障壁になっていまっているのではないかと。。

エンジニアだったらやはり、オープンな言語のスキルをつけたいですし、日本に比べてテクニカルなスキルでの勝負感の強い欧米では特にその傾向が強いのではないかと思います。

今回のHerokuのJava対応により、上記のロックインを解決しつつ、900万人いると言われるJavaのデベロッパーにリーチできたのは非常に大きいと思います。個人的にはSalesforceはApexへの投資を控えて、こういうオープンなプラットフォームへの進化を強めていくのではないかと思っています。

ただ、Herokuは値段はちょっと高いような気もするので今後の値下げに是非とも期待したいです。

会場や雰囲気について：

右側の女性はバーバリーの社長

なんと郵政の日本語の看板

会場近辺はイベント一色

よく見ると競合のO社のバルーンが！

イベント会場となるモスコーンセンターは、大きな会場でしかも建物が分かれているため迷いがちです。なので、会場の中だけではなく外のいたるところにもstaffの方がいて、気さくに「迷ってないかい？」と話しかけてきてくれます。

会場に入って思ったのは、朝から音楽がかかっていてとにかく雰囲気が明るい。日本のビジネスイベントは音楽がかかっているものが少なく、どこか堅い気がするのですが、それとは違う明るさがあるなぁと思いました。イベントに音楽は大事ですね。ズンドコいうのはイイです。

昼間もフリーフードで、夜も会場や周辺の至る所でお酒が振舞われたりパーティーが行われたりしています。1企業のイベントにも関わらず、有料で皆それなりのお金を払っているのですが、それ以上にお金を使って、来場者に還元しようという姿勢が素晴らしいと思います。

いろいろとイベントが派手だから記憶に残るんですよね。「あー、あのメタリカのやつね」って来年でもきっと皆覚えているイベントになると思います。こういう風にイベントが記憶に残るようにするっていうのは大事だなぁと強く感じました。

展示ブース：

展示コーナーもすごい人

各ブースも熱心に聞く人であふれてました

個人的には結構時間を割いてパートナー企業の展示ブースをまわりました。どこのブースでも「さわらせてくれ」って言ったらちょっぴり嫌な顔されたので（笑）基本的にいろいろとデモンストレーションをしてもらいました。

やはりどこのブースでも担当説明員が自信満々で説明してくるのはさすがにアメリカンな感じでしたね。実体としていわゆる統合ソリューションだったとしても、デモとしてはみな特徴のある部分を切り取ってうまく自社の強みを表現している感じでした。

実際にSalesforce社と共にビジネスしている企業といろいろと見たり話したりできて、かなり有意義な時間を過ごすことができました。

さいごに：

今回初めてDreamforceに参加させてもらって、日米の違いを感じた部分もありましたが、どちらかというと変わらない部分やお互いの強みと弱みをたくさん認識できたのが大きな収穫でした。

やはりイベントに参加することの意義は現地で生の情報や、実際にやっている人と話すことでそこから次のステップのアイデアやインスピレーションが湧いてくることだと思います。

実際行く前と比べて、アメリカでのビジネス、開発について感覚が変わったところもだいぶでてきたので、個人的にはとても収穫がありました（中身を聞きたい人は是非虎ノ門におこしください）。

※現地ではSalesforce社の方々（特に日本の方々）に大変お世話になりました。日本を大事にしてもらっていることも強く感じました。この場を借りて御礼申し上げます。

Dreamforce'11関連記事へのリンク：

http://ascii.jp/elem/000/000/631/631724/

http://itpro.nikkeibp.co.jp/article/NEWS/20110902/368072/

http://www.publickey1.jp/blog/11/databasecom10dreamforce11.html

http://www.publickey1.jp/blog/11/dreamforce11.html

http://jp.techcrunch.com/archives/20110901eric-schmidt-google-apps-has-40m-users-adding-5k-new-companies-per-day/

@jojihori

ブラウザってどうやって動いてるの？（モダンWEBブラウザシーンの裏側）

2011-09-06T12:38:00.000+09:00

どうも、鈴木です。
さて、前回は vim の使用法というじつに低レベルレイヤの出身者的な記事を書きましたが、
今回も懲りずに低レベルのお話しをしたいと思います。

というのも、先日「ブログ書くのめんどくさいよぅ」と駄々をこねていたところ、あまりにレガシーすぎる HTML/CSS/JavaScript 仕様や Flash や Silverlight といったプロプライエタリなリッチコンテンツ用プラグインに日々苦しめられている気弱く善良な一介の WEB プログラマにすぎない我々の希望の星であり、そして同時に新たな巨大クソレガシーの萌芽でもある HTML5 が、いかにイケてないのではなくイケているのであるかを盛んに啓蒙するサイトである HTML5 Rocks (http://www.html5rocks.com/) に、"How Browsers Work" というとても楽しい記事があるのを、我が社のアーリーアダプタでありエヴァンジェリストである ikeike443 氏から教えてもらい、これはなかなかありそうでなかった部分のきちんとしたドキュメントだと刮目したので、これを日本のドメスティックな (つまり私のように楽天にはもう入ることのできない) WEB 開発者にも広く読んでもらおうと考え、今回のブログの記事は、この記事の翻訳にさせてもらおうと勝手に思った次第なのであります。

というわけで元の記事はこちら。

How Browsers Work

翻訳にあたっては、一部プログラムコードも登場する記事であることから、ある程度ソフトウェアアーキテクチャやアルゴリズム的な用語については、あまり言い換えずにそのままカタカナ語を用いています。
また訳語を当てはめたものについても、わりといい加減に当てはめているので、オライリーのきちんとした和訳本などの用語と若干異同があるかもしれないことはお断りしておきます。
（つまり、そのへんきちんと調べるのをさぼったわけです）

それでは、現存する汎用ソフトウェアの最高峰のひとつである WEB ブラウザのめくるめく (≒ 発狂しそうな) 世界へようこそ。

9/9 追記:
Kosei Moriyama (_kosei_)氏による訳もあるようです。
http://cou929.nu/docs/how-browsers-work/

わたくしめのいい加減な訳のせいで文意がつかめない場合などは、読み比べてみてはいかがでしょう。というか、ならはじめからそちらを読めばいいじゃん、というのは言いっこなしです。また、わたくしとしても「やってくれてるの知ってたら、慣れない和訳なんぞ自分でやろうとは思わなかったであろうよ」的な愚痴は言いっこなしにしたいと思います。

それはともかく、どちらかといえば、氏のもう一つの和訳である Google JavaScript Style Guide 和訳もたいへんな労作であり、内容も非常に実践的なものであることから、自身は JavaScript プログラマであると認識されている方はぜひ一度目を通しておかれることをお薦めいたします。

ちなみに、わたくし個人といたしましては、このスタイルガイドにだいたい 8 割同意で、残り 2 割は、わたくしなりのわりとめんどくさい理由から反対（別のスタイルがよいと考えている）といったところであります。（おもに、はじめてまともに触った JavaScript フレームワークが ExtJS であったところから来ているのですが）
いずれにせよ、プログラマであれば、こうしたコーディングスタイルの問題は、なんといいますか、（ときに喧嘩になる、というのも含めて）酒の肴的なものであり、その意味でもたいへん楽しく読めるのではないかなと思っております。

また最近は、これベースで JavaScript コードをチェックしてくれる Google Closure Linter なる、まったくもっておせっかいな代物もあるようですので、(C の lint をまったく快く思ってない身としては、lint と聞くとその時点で斜に構えてしまうのであります) こちらなども試してみるとよろしいかと思います。
もっとも、わたくしとしてはまったく同意できない規則がいくつかありますので、使わないわけなんですけれども。

それでは、あらためて本文をどうぞ。

もっと読む »

ノマドワーカーになりたいので、できるかどうか考えてみた

2011-09-03T13:25:00.007+09:00

先日、『国境なきプログラマ』を目指す～ノマドワークの究極のかたちというブログを読み、コレが私の理想の働き方だ！と憧れている megumi です。

そこで、これは弊社で可能なのか？と考えてみることにしました。

制度が存在しないので、現実としてはできません。
それは置いといて、技術的に可能なのか、もし制度があったら可能なのか、というところだけを考えてみます。

海外から仕事をした経験については、以前ソンさんが韓国から仕事をした経験を書いてくれています。（海外からのリモート作業）韓国は時差が少ないので、チャット等でリアルタイムに連絡を取りながら進めることが可能です。

前職ではアメリカやヨーロッパと一緒に仕事をしていましたが、さすがに時差が大きいので、チャット等の使用頻度は高くありませんでした。
その頃の経験と、現在の仕事スタイルから、必要なことを考えてみます。

開発エンジニアが1日にやることは、だいたい毎日こんな感じです。（時系列）

ReviewBoard を使ったコードレビューをする
自分が出したレビューが ReviewBoard で Ship it になっていたら、CVSにコミットする
- Bugzilla にコミット内容を記載し、ステータスを変更する
Google docs の業務報告シートに昨日の仕事内容を記録する
Backlog で今日のタスクを確認する
スクラムチームのデイリーミーティング
Bugzilla を確認し、要対応なものに着手する
1. バグが再現しないときや仕様が曖昧な時はQAに相談する
2. 修正と動作確認をし、Build テストを流す
3. ReviewBoard に投稿する
今月の開発テーマに着手する
1. 現状の機能がどう作られているか確認し、開発方針を立てる
2. 仕様が曖昧な時はQAに相談する
3. 口頭かメールかReviewBoardで設計レビューを出す
4. 修正と動作確認をし、Build テストを流す
5. ReviewBoard に投稿する
6. Google docs のリリースノートに変更内容を書く
ReviewBoard を使ったコードレビューをする
作業の進捗をBacklogに記録する
（帰宅）

※ ReviewBoard についてはこちら ⇒ コードレビュー
※ Bugzilla についてはこちら ⇒ Bugzilla-jp - もじら組（本家）
※ Backlog についてはこちら ⇒ Backlog ユーザーの集い in Fukuoka に行ってきました！
※ スクラムについてはこちら ⇒ スクラム道バーストにいってきました, マンネリ化したスクラムをアナログ回帰でテコ入れするの巻

この他に時々ミーティングが入ったりすることがあります。また、月末にスプリントレビュー（ビジネスオーナ－向けのレビュー）、月初に計画ミーティングなどがあります。

これらは、対面で行うもの、方法は問わないもの、ツールを使用するものに大別できます。

対面

スクラムチームのデイリーミーティング
その他ミーティング

方法は問わない

バグが再現しないときや仕様が曖昧な時はQAに相談する
現状の機能がどう作られているか確認し、開発方針を立てる

ツール

ReviewBoard でレビューする／される
CVSにコミットする
Bugzilla でバグの管理をする
Google docs で業務報告シートを書く
Google docs でリリースノートを書く
Backlog でタスクの管理をする
Build テスト

対面で行っているものについては、Skypeやメッセンジャーなど、リアルタイムで連絡を取ることができる方法が必要です。
このときに最重要なことは、ログインしておくことでしょうか。そのためには、ミーティングの開始時刻を確定しておくこと、時間を守ることも大事なことです。
ミーティングの時間と移動時間が重ならないようにする必要があるからです。また、時差が大きいときは、いつ始まるかもわからないミーティングのために待っていられないものです。
全員揃ったら開始、前のミーティングが終わり次第開始といった曖昧なミーティングが時々あるので、そこは改善すべきポイントだと思います。

次に、方法が決まっていないものについて。
これは対面の場合と同様に行うか、もしくはメールを使うことが多いのではないかと思います。
メールのように非同期でコミュニケーションを取る場合には、お互いがメールをチェックする習慣があること、わかりやすく説明する言語能力が必要かと思います。
メールを見てなかった・・・では仕事が進みませんし、読んだけど意味不明だったというのも仕事は進みません。文章が長すぎて読むのがイヤになった、というのも困ります。

そして最後に、ツールを利用するものについて。
上に列挙したものを見るとツールを使うものが大半です。そのため、いつでもどこでも仕事ができそうじゃないか！と思うかもしれません。確かに、ちゃんと有効活用できていれば、かなりの部分をツールに頼ることができそうだという実感はあります。
主にコミュニケーション手段ともなる ReviewBoard、Bugzilla, Backlog （レビュー、バグ管理、タスク管理）をうまく活用できているかどうかは重要です。これらは何をどこまで作業しているかを見えるようにするという重要な役割があります。
きっと見えない相手と仕事をすれば、相手がサボっているのではないか？と不安になることもあるのではないでしょうか。それを解消する役目がこれらのツールを活用することかなと思います。

いずれの手段を用いるにしても、それがインターネット経由で共有できる情報なのかどうか、というのが大事だと思うのです。

こうして書いてみて、ツールなど手段は存在するけど、使い方はまだまだ足りないな、という感触を受けました。
時差がないほうが仕事しやすいというのは、ツール等を用いた非同期コミュニケーションに慣れていないからだと思います。うまく時差を活用すれば、開発とQAをうまく組み合わせて2倍速くらいにできる気がするのです。

自分が海外で働くわけではなくても、海外の人と仕事をすることになるかもしれません。
そんな遠隔地でなくても、もし日本で開発拠点が2つになった時点で、姿が見えない相手と仕事をすることになるわけです。他人事だと思わずに、一度思いを廻らせてみると、見えてなかったことに気付くかもしれません。

サーバサイドのレガシーなHTMLに負けずに jQuery Mobile を使おう

2011-08-30T10:40:00.009+09:00

こんにちわ、 chappie です。

少し前に、とある案件で jQuery Mobile を触って iPad 用に画面をカスタマイズする機会がありました。

jQuery Mobile (以下 JQM) 自体については素敵な紹介記事が世の中にたくさんあるので(末尾の参考リンク参照ください)、ここでは個人的に対応しなければならなかった細かい問題について小ネタをシェアしたいと思います。

JQM は、HTMLをセマンティックに記述しておけば自動的にモバイル端末向けの画面にレンダリングしてくれるライブラリです。

- 超カンタンなサンプル(@ jsFiddle) (http://jsfiddle.net/somat/NrCGb/7/)

全く新規にスマートフォン/タブレット向けにサイトを作るといったようにHTMLを自由に書ける場合は、JQM が求めるとおりの記述をしておけばいいだけなのでとても楽チンです。しかし、SaaSアプリケーションなど既存のWebアプリをカスタマイズする場合、一部のパーツがサーバサイドから固定出力されるため、必ずしも JQM に都合のよいHTMLが生成されるとは限りません。

今回私が担当した件では、入力フォームのチェックボックスが問題になりました。

JQM では、チェックボックスやラジオボタンの選択肢は label タグとセットで記述されていないと正しくレンダリングしてくれません。

<input type="checkbox" name="chk1" value="1" id="chk1-1"><label for="chk1-1">せんたくし１</label><input type="checkbox" name="chk1" value="2" id="chk1-2"><label for="chk1-2">せんたくし２</label>

label タグがない、たとえば以下のような記述だと、とても残念な出力結果になってしまいます。

<input type="checkbox" name="chk1" value="1">せんたくし１<br><input type="checkbox" name="chk1" value="2">せんたくし２<br>

(上のチェックボックスグループが label タグ付き、下が label タグなし)

サーバサイドで出力されるHTMLを label 付きのコードに変更できれば一番よいのですが、出力を変えることは既存の他のユーザ環境にも影響を与えることになってしまい、簡単には変えられません。ここが SaaS アプリケーションのムズカシイところです。サーバサイドのプログラムを変えてもらう交渉するのも大変でしょう。(注: 弊社のエンジニア同士の仲が悪いわけではありません)

しかし、諦めるのはまだはやい。

多少ムリヤリでもクライアント側で DOM を加工してやればいいのではないか、、、そう思ってやってみたら、(一応)うまくいきました。

- サンプルコード (@ jsFiddle) (http://jsfiddle.net/somat/u2a79/5/)

元々のチェックボックスと、label タグがついてない素のテキストを取り出し、新しい要素を作ってその中に順番にチェックボックスとlabelでかこったテキストをつめて、元の要素を置き換えています。とってもクルシイことしてますが、今回の案件は短期プロジェクトだったので、割りきって対応しました。

ちなみに、案件担当当時は JQM はまだアルファ版でした。

そのころのバージョンでは、head タグ内で、DOMの加工処理をJQMのロード箇所よりも前に記述する必要がありました。

- サンプルコード @ jsFiddle (http://jsfiddle.net/somat/9mnAq/2/)

その後、当時のバージョンにはセキュリティホールが見つかったりして、ほんと短期プロジェクトでの利用でよかったな。。。と思った次第。

というわけで、JQM本体もいよいよ安定してきている？ようですし、サーバサイドの中の人と仲が悪くても大丈夫！積極的に jQuery Mobile つかっていきましょう。(注: 弊社のエンジニア同士の仲が悪いわけではありません)

参考リンク:

- もう知らないでは許されない！！「これからはじめる」という人のためのjQuery Mobile情報まとめ

- jQueryMobileを使ってのスマートフォンサイトの構築メモ

- jQueryMobileのかゆいところに手が届くお作法メモ

- jQuery Mobileを触りながら覚えよう！

- jQuery Mobileを使う際に知っておくと役立ちそうなTipsや情報のまとめ

Vundle入れたら、Vimのプラグイン管理が楽になった

2011-08-22T02:48:00.020+09:00

どうも、EventPlatFormチーム、新卒入社２年目、開発担当のnumaです。最近、会社のPCが変わったり、個人的に新しいPCを購入したりと開発環境を移行する場面が多かったので、vimプラグイン管理にVundleを導入することにしました。

■vundleとは？

gmarik / vundle
Vundle is short for Vimbundle and is a Vim plugin manager.

.vimrcに管理したいプラグインを記述することで管理をする
vim上でプラグンの検索が出来る。
vim上でプラグインのインストールとアップデートが出来る。
.vim/bundle以下にプラグインごとにディレクトリが作られるので、視覚的にも分かりやすい。
.vimrcで同じプラグインを指定すれば、複数のPC間で同じ環境が作れる。

導入するにはgitが必要なのですが、gitさえ入っていればすぐに導入出来るので、vimは時々しか使わないという方も、ちょっと機能追加したいなというときに使えるのでオススメです。

■導入
$ git clone http://github.com/gmarik/vundle.git ~/.vim/bundle/vundle

~/.vim　以下にbundleディレクトリを作り、リポジトリをcloneする事で導入は完了です。dotfileをgitで管理している場合はsabmoduleとして取り込む必要があるようです。

■.vimrcを編集
青字で書かれている箇所で、プラグインを指定しています。各自必要なプラグイン名に書き換えてください。

filetype off """ Vundle
''' set rtp+=~/.vim/bundle/vundle/
call vundle#rc()
" let Vundle manage Vundle Bundle 'gmarik/vundle'
"管理したいプラグイン
" original repos on github
Bundle 'Shougo/neocomplcache'
Bundle 'Shogo/unite.vim'
" vim-scripts repos
Bundle 'ZenCoding.vim'
" non github repos
Bundle 'git://git.wincent.com/command-t.git'
filetype plugin indent on

■プラグイン名の指定の仕方 github上にレポジトリから取得する場合
Bundle 'user_name/repojitory_name'　
Githubのユーザ名とリポジトリ名

vim-scripts上のレポジトリから取得する場合
Bundle 'script_name'
それ以外のgitリポジトリから取得する場合
Bundle 'git://repository_url'　gitレポジトリのフルパス

■プラグインのインストール
.vimrcの設定が終わったら、vimを開き直す、もしくは:source ~/.vimrcのコマンドを打って.vimrcの変更をvimに適用させたら準備は完了です。

■インストール
:BundleInstall
コマンドモードで:BundleInstallと打てば、先ほど.vimrcで指定したリポジトリから自動的にBundle ‘name’ と記述した plugin が自動的に取得され、インストールまで行われます。

■アップデート
:BundleInstall!
すでにインストールしたプラグインのアップデートには:BundleInstall!コマンドを使用します。

■プラグインの検索
:Bundles plagin_name
プラグインを検索して、インストール削除などが行えます。

gitとvimさえあれば、あとは、cloneして、.vimrcに数行記述すれば始められるので、導入が簡単で分かりやすいと感じました。これならVimをメインに使っている方はもちろん、時々しか使わない方も入れておくと後々便利なのでは無いでしょうか。

参考
github gmarik / vundle
Hack #215: Vundle で plugin をモダンに管理する　vim-users.jp VundleでVundleをBundleしてみる / Meltdown Countdown

Websocket, node.js, Socket.io@社内勉強会

2011-08-15T17:57:00.006+09:00

ikeike443です。

今日は弊社の社内勉強会で発表したWebSocketとnode.js周りについて書きます。

書きます、というか、資料を貼らせていただきます。。

Websocket shanon

View more presentations from Takafumi Ikeda

ポイント

WebSocketは「WebのためのTCP」的なもの
WebSocketはPushを実現できる
WebSocketにはクロスドメイン制約がない
WebSocketはコネクション張りっぱなしなので注意が必要
WebSocketは仕様が揺れており、取り扱いには注意が必要
WebSocket＋WebSocketエミュレーションをクロスブラウザで行うSocket.io
Socket.ioが現時点での現実解？ではないか
用途を絞れば十分に使えるのではないか
サーバサイドJavascriptアツイ感じ

尚、デモの内容については、僕の個人ブログに同じ内容を動画として保存してあるので、よかったらご覧ください。
http://d.hatena.ne.jp/ikeike443/20110808/p3

参考URL
node.jsの衝撃とWebsocketが拓く未来
最近のWebSocket事情についてまとめとく Ehrenの日記
WebSocketがセキュリティ問題を解決して再び実装へ Publickey
WebSocket勉強会
「続・ハイパフォーマンスWebサイト」に書かれたWebSocket記事への更新 Nothing ventured, nothing gined.
サーバを作りながら学ぶWebSocketプロトコルみずぴー日記
ExpressとSocket.ioを使ったチャットサンプル自分の感受性くらい

倍プッシュ！　倍プッシュ！　でお願いします。

ではまたー。

テスト環境まるごとAWSにのっけてみた～第三回　Backlogチャンネル～

2011-07-22T16:30:00.001+09:00

どうもfujya.sh（梨ガリ君 Love）です。

7月21日にシャノンのセミナールームでBacklogチャンネル・AWSセミナーが開催されました。

AWSに関する講師枠をもらえたので、「テスト環境まるごとAWSにのっけてみた」というタイトルで話をしたのですが、若干滑りつつも好評だった部分もあったので紹介したいと思います。

テスト環境まるごとAwsにのっけてみた

View more presentations from fujya .sh

■テスト環境はAWSに乗っけてるよ

電力が無いから社内にテスト用サーバ追加できない　→　じゃあAWSに乗せようって流れでAWSを使い始めました。本当はAWS使ってみたいなーと思っていた自分とかが、QAチームが困っていることをダシにして予算を獲得したという裏話もあったりなかったり・・・

■テスト全体の管理はJenkinsでやってるよ

元々テスト全体の流れはJenkinsでやっていたのですが、EC2のインスタンスの起動・停止も含めて管理するようになりました。テスト全体の紹介に関してはnishinoが以前Jenkinsの勉強会（その当時はHudsonでした）で発表したことがあるので、そちらを見ていただければ分かると思います。

Hudson活用事例

■テスト用インスタンスはOpenVZで再仮想されてるよ

前にBlogにも書いたネタなんですがインスタンスはOpenVZで再仮想されてます。EC2インスタンス起動時にはElasticIPの取得をはじめ、色々なスクリプトが実行され初期化されて立ち上がります。初期化周りの調整がまぁ結構大変で、立ち上げて確認してダメだったらまた調整して・・・の繰り返しで良い感じに仕上げました。今はそのイメージをコピーして複数台のOpenVZ化されたEC2インスタンスを立ち上げてテストしてます。

■起動からテスト実行、終了まで全部自動化されてるよ

シャノンのQAはテストする人じゃなくて、テストプラットフォームを創る人なんです！！

実際にテストケースも書きつつ、プラットフォームに必要なアプリケーションも作ってます。シャノンのQAって凄い！と共感し興味がある人は、ブログ下部にある「人材募集」ボタンをクリックしてくれたら嬉しいですｗ

■節約してるよ

使ってない電気は消そう！という事で、自動シャットダウンの仕組み作りました。仕組みはmonitで作りました。コンフィグはこんな感じ

check file auto_shutdown with path /var/log/httpd/ssl-access_log
if timestamp > 30 minutes for 60 cycles then exec
"/root/bin/autoshutdown.sh"

Apacheのアクセスログのタイムスタンプを監視して、30分更新されていない状態を60回検知したら/root/bin/autoshutdown.shを実行する

というコンフィグになっています。（タイミングは1分に1回で設定で、90分アクセスが無ければ落ちる想定）autoshutdown.shにはアプリケーションを停止してから「落とすよ！」というアラートを飛ばした後、API経由でシャットダウンする内容が書いてあります。

この仕組みを導入してから全体で600~800時間分のインスタンス起動時間が削減できている見込みです。節電！節電！

■家計簿書いてるよ

案件でAWSを使いたいけど、内訳わかんないよね。でも、AWSには課金APIが無いので自前で課金情報を集計するスクリプトを作りました。

帳簿：Google Spreadsheets
言語：Python
モジュール：AWSの情報取得 boto
　　　　　　　Spreadsheetsの情報取得・書き込み gdata

処理の流れとしては

botoを使いAWSのAPIを叩きインスタンスの情報一覧を取得
Runnning中のインスタンスの instanceID / Tag:Name / instanceType / Tag:biz(用途）を取得
gdataを使いSpreadsheetsの一覧を取得して１の情報とぶつける
既にシートにinstanceIDが記述されていたら起動時間をインクリメント
シートにinstanceIDが記述されてなかったら（新規で作成したインスタンス）行を追加
このスクリプトをcronに設置して毎分実行
月をまたぐ瞬間にシートのコピーをとり、初期化する（当月の集計）

Spreadsheets内部でTag:biz(用途）別に金額を集計するようにしておき、他のシートにインスタンスの時間単価、為替レートを書いておきSpreadsheetsの関数を使い用途別の利用金額を出してます。

EBSとトラフィック周りの金額は・・・いい感じにマージしてます。

これ作ってみてよかった事は、何が使いすぎているのかという分析ができるようになります。AWSは使い始めると金額が膨れてくるので節約周りはインフラ屋の大きなミッションになります。情報を集めて分析するのにとても役立ってます。

（早く課金APIで無いかなぁ・・・）

■結論：AWS最高！

資料にも書いてますが当初の目的のテスト実行時間が短縮できました。たぶん社内にサーバ増強して同じ事をやっていても目標は達成できたかもしれませんが、テストケースはどんどん増えていきます。物理サーバを増やす運用だとテストケースが一定量を超えた時点で破綻する事が目に見えているので、AWS上にテスト環境移動している現在では心配事は予算のみとなりました（強敵ですが・・・）

インフラエンジニアが面倒だなーと思うところ（工数がかかる）をAWSが全部やってくれるので、本当に素晴らしいプラットフォームだと思います。

結論としてはAWS使うと色々と幸せになれるよって事ですね。

最後に、今回こういったすばらしい企画をしてくれたヌーラボの皆様、講師のアイレット：後藤様、AWS：大谷様本当にありがとうございました、凄く楽しいセミナーになりました。

また機会があればご一緒しましょう！

明日のBacklogチャンネル・AWSセミナーに会場をお貸しします

2011-07-20T20:41:00.001+09:00

突然ですが、明日、ヌーラボさん主宰のBacklogチャンネル・AWSセミナーがひらかれます。
その会場として、弊社セミナールームをお貸しすることになりました！

Backlogの話やAWSの話が聞けて、ビールも飲めるみたいなので、お近くの方は是非どうぞ！

下記が地図になります！　一階のガラス窓に"SHANON"と書いてあるので分かると思います！！

大きな地図で見る

ざくっとユニットテスト

2011-07-19T15:06:00.012+09:00

開発担当のsugimotoです。
今回は弊社サービスであるShanon Marketing Platformの開発で行っているユニットテストについて書いてみたいと思います。

いつから？

恐らく2008年の夏くらいです。
コードレビューを始めた時期と同じくらいだと思います。
その頃はバグが多発していて何とかしないといけないなーと思って始めました。

どんな感じ？

Test::Classを使用してXUnitライクに書いています。
テストはクラス単位で行っています。
テスト対象クラス一つに対しテストクラスが一つ、テストクラスを実行するテストスクリプトが一つ存在します。
テストスクリプトをクラス毎に用意しているのは、

クラス単位でテストが実行できるようにしたい

テスト間の影響をできるだけ無くしたい

という狙いがあります。
トリッキーなことをすることでやっとテストができるという場合もありますので、どちらかというと後者の狙いの方が大きいです。

開発時にはテストスクリプト単体を繰り返し実行していきます。
開発がある程度終わりに近づき他のクラスへのデグレが無いことを確認したり、デイリーでテストする際にはまとめてテストを実行する必要あります。
その場合にはModule::Buildを使用して全てのテストスクリプトをまとめて実行するようにしています。

使用しているモジュール

ごくごく一般的なものばかりです。

Test::Class

Test::More、Test::Exception等

Module::Build

Devel::Cover

メリット・デメリット

実際にやってみた一番大きなメリットだと思ったのは、クラスのインタフェースがシンプルになる点です。
インタフェースがシンプルじゃないととてもじゃないけどテストが大変なので。
デメリットはやっぱり工数がかかることです。
ただこれは後からテストを作る場合であって、テスト駆動で開発を行えばそんなに増えないかなーって印象です。

ユニットテストを始めて3年くらい経ちましたが、現在のコードカバレッジ(命令網羅)は33％ほどです。
もともとアプリケーション自体がフレームワークべったりに書かれていたためにテストコードが書きづらく、当初は新たに追加したクラスをメインにテストコードを書いてました。
現在はソースコードを徐々にフレームワークから切り離して行く過程で、既存のコードにもテストコードを書くようになっています。
6％／半年くらいのペースでカバレッジは上げていきたいのですが、なかなか難しいところです。

今回はざっくりしすぎた内容でしたね。。。
もうちょっと突っ込んだ話やTipsは次回のネタにでも取っておきます。

JSが苦手なWebデザイナーに贈るたった２つの克服のコツ

2011-07-14T12:08:00.013+09:00

シャノン nishino です。

最近、わたくし部署異動しまして、テストの人からサポートの人になりました。
なんのサポートかというと、ウチの製品（Shanon Marcketing Platform）を売ってくれる人向けのテクニカルなサポートを行うことになりました。
是非是非よろしくお願いいたします。

さっそく今回、制作部署向けに JavaScript のお勉強会を実施しましたので、その時に使ったプレゼンテーションを紹介します。

JavaScriptを克服するたった２つのコツ？

今回のプレゼンテーションは技術者向けではなく、制作部署のWebデザイナー向けに作成しました。
なので、以下の人を対象にしています。

HTMLやCSSはなんとなく分かるけど、JavaScriptはやったことない人
過去にJavaScriptに挑戦したけれども、さっぱり分からなくて挫折した人

私が提案するコツは以下の２つです。

いつ・なにを・どうする？
エラーメッセージを読む

これだけです。
以下に簡単に解説します。

コツ１：いつ・なにを・どうする？

「いつ・なにを・どうする？」といきなり言われても何のことやら、、ですが、これは、JavaScriptの要件を定義するのに必要な３つのことを表しています。

Web制作を行う際に、クライアントからの要件を制作物に反映させる必要がありますが、この時に要件が明確になっているとは限りません。
「もうちょっとわかりやすくしてよ」
こんな感じで、何か改善して欲しいということは分かりますが、具体的にどうすればいいのかわからない要件が往々にしてあります。

こういった場合に、「いつ・なにを・どうする？」を明確にすることにより、制作物へ要件を反映させることができます。
たとえば、最初にすべてを画面に表示すると内容が多すぎて分かりにくい場合は、最初（いつ）は詳細（なに）を非表示にしておいて（どうする）、ボタン（なに）をクリックされたら（いつ）詳細（なに）を表示する（どうする）。
といったことです。

「いつ？」は、初期表示時、イベント時、サブミット（送信）時の３パターン

jQueryでは、$( function() { ... } ) 内に以下の内容を記載することで、「いつ処理するか？」を指定できます。

初期表示時を指定する場合は、$( function() { ... } ) 内に特に指定はいりません。
イベント時（クリックなど）を指定する場合は、$( function() { ... } ) 内に
$("xxx").click( function() {...})
と書きます。
サブミット（送信）時を指定する場合は、$( function() { ... } ) 内に
$("form").submit( function() {...})
と書きます。

厳密には「初期表示時」も「サブミット時」もイベントですが、要件を詰めるうえで時系列に上記３つのパターンで考えるのが実用的です。

「なにを？」は、jQueryのCSSセレクタで指定

jQueryでは、HTML内の「なんの要素？」を指定する方法としてCSSセレクタを使用できます。
よく使うCSSセレクタとして以下を紹介しました。

.class　（指定したclass名がある要素を指定します）
#id　（指定したid名がある要素を指定します）
ko mago　（指定した子（ko）孫（mago）要素で構成される要素を指定します）

「どうする？」は、jQueryに用意されているメソッドを組合せ

jQueryでは、上記で指定した要素に対して「どう処理する？」を指定するためのメソッドが用意されています。
よく使うメソッドとして以下を紹介しました。

hide() …非表示にします
show() …表示します
val(値)…valueの値を設定します
css(プロパティ, スタイル)…プロパティにスタイルを設定します
attr(キー, 値)…キーに値を設定します
addClass(クラス名)…classにクラス名を追加します

コツ２：エラーメッセージを読む

どんなに経験豊富なプログラマーでも常にエラーを発生させずにコードを書くことは不可能です。
ブラウザにはJavaScriptのエラーメッセージを表示させる機能がありますので、このエラーメッセージを読むことにより、誤りに気づき、正しいコードに修正することができます。

時には全く意味不明なエラーメッセージを読まされることもありますが、alert()関数を使って何度もエラーの箇所を繰り返し調べるうちに、きっとJavaScriptを克服している自分に気づくことでしょう。

まとめ

今回、JavaScriptの入門的な内容として、要件定義のための「いつ・なにを・どうする？」。
また、制作を完成させるための「エラーメッセージを読む」をコツとして紹介させていただきました。

実践的なJavaScriptを書けるようになるまでには、今回紹介したjQuery以外のライブラリを使用したり、画面遷移を伴わないajaxといった技術が必要になるかもしれませんが、考え方として上記の２つのコツは有効だと思います。

がんばろー

mod_rewriteでauガラケーのSSL対応しようとしたら見事にハマった件について

2011-07-06T12:55:00.001+09:00

お久しぶりでございます、インフラ担当のfujya.shです。

最近暑いですね、ホント嫌になっちゃいます。最近はプライベートでIX2015を2台貰ったので、ちょっと遊んでみようかと思っております。

IPsec 高速化拡張ソフトウェアセット入れるとIPsecが爆速になるという噂のIX2015たん。

とある事から「ガラケーからSSLのサイト見れるよーにしてくれない？」という話が来まして、軽い気持ちで対応しようとしたら様々な障壁があり、大変だったので今回は解決までの道のりを紹介しようかと思います。

■auガラケーはRequestHeaderのHostに:443付けてリクエストしてくる輩がいる

auの一部ガラケーではhttps://～のサイトを閲覧する際に、リクエストヘッダのHostの末尾に:443をつけてアクセスしてくる事があります。（手元の検証端末W63CAではついてきました）

こんなアクセスログが入ってきます（HTTP_HOSTがexample.com:443になっちゃってる）

10.8.15.100 - - [29/May/2011:17:48:30 +0900] "GET /path/to/sample/test?lang=ja
HTTP/1.1" 200 2547 "" "KDDI-CA3C UP.Browser/6.2_7.2.7.1.K.2.232 (GUI) MMP/2.0"
281408 example.com:443

これでは環境変数の %{HTTP_HOST} が :443 付いてしまうので、アプリケーションが%{HTTP_HOST} を利用している箇所がある場合は正常に動作しない可能性があります。mod_rewriteで %{HTTP_HOST} が ^.*:443$ にマッチした場合に

%{HTTP_HOST} から :443 を消し去る処理を施してあげる必要がありそうです。

それではmod_rewriteで ${HTTP_HOST} を書き換えてみましょう。

■mod_rewriteで%{HTTP_HOST}の書換ができない

さっそくmod_rewriteでRewriteCondとRewriteRuleを書いてみましょう。

RewriteCond %{HTTP_HOST} ^(.*):443$
RewriteRule .* - [E=HTTP_HOST:%1]

これで%{HTTP_HOST}が:443抜きのものに書き換わっているハズです。

確認作業に入ります。

Apacheのコンフィグに下記コンフィグを追加してHTTP_HOSTの状態を確認してみましょう。

CustomLog logs/env_log "%t %h HTTP_HOST=%{HTTP_HOST}e"

configtestして、SyntaxがOKならrestart||gracefulします。そしてアクセスしてenv_logを見てみましょう。

[1/Apr/2011:12:00:00 +0900] 10.8.15.100 HTTP_HOST=example.com:443

%{HTTP_HOST}がexample.com:443のままです。何故でしょうか？？

Apacheの環境変数に関するドキュメントを読んでみると

「環境を操作するディレクティブを使って標準CGI変数を上書きしたり変更したりすることはできません。」

と書いてありました。

標準CGI変数とは何かとさらに調べてみるとRFC3875で定義されているCGIが利用するメタ変数の事だそうです。つまり、標準的な環境変数は書換が出来ないという事になります。

■%{X_HTTP_HOST}を宣言してしまう方法

回避策として複数ありますが今回は別途、独自環境を宣言し回避することにしました。

RewriteCond %{HTTP_HOST} !^(.*):443$
RewriteRule .* - [E=X_HTTP_HOST:%{HTTP_HOST}e]
RewriteCond %{HTTP_HOST} ^(.*):443$
RewriteRule .* - [E=X_HTTP_HOST:%1]

%{HTTP_HOST}の末尾に:443がついていてもついていなくても、

%{X_HTTP_HOST}という独自環境変数に:443抜きのモノが入るように宣言しています。

それでは早速確認してみましょう。先程のenv_logのコンフィグを下記の通り修正します。

CustomLog logs/env_log "%t %h X_HTTP_HOST=%{X_HTTP_HOST}e"

コンフィグを変更したら必ずconfigtestしてからrestart||gracefulです。OKが返ってきたらアクセスしてみましょう。

[1/Apr/2011:12:15:31 +0900] 10.8.15.100 X_HTTP_HOST=example.com

:443がついていない%{X_HTTP_HOST}という環境変数が生成されていることが確認できました。

後はアプリケーション側で%{HTTP_HOST} -> %{X_HTTP_HOST}に切り替えてもらう作業をする事で無事解決といった形になります。

■番外編１：mod_rewriteで独自の環境変数を利用する場合はご注意を

mod_rewriteのRewriteCond/RewriteRuleで使用する環境変数は限定されています。mod_rewriteで独自の環境変数を利用するときは%{ENV:環境変数}で宣言しないといけません。

#例えば%{X_HTTP_HOST}をパスの先頭に入れる場合は
RewriteCond %{HTTP_HOST} !^(.*):443$
RewriteRule .* - [E=X_HTTP_HOST:%{HTTP_HOST}]
RewriteRule ^/path/to/ /%{ENV:X_HTTP_HOST}e/path/to/

普通に%{X_HTTP_HOST}eでrewriteしようとしてもできないので、ENV:を付けてあげましょう。

■番外編２：ガラケーのSSL対応状況にご注意を

ガラケーにインストールされているルート証明書に関しては端末ごと・発売時期によって全然対応状況が変わってきます。

各証明局で携帯電話のSSL対応状況が書いてあるので、ガラケー対応する場合には確認が必要です。

手元の検証端末と検証用サイトのSSLが対応して無く（au W63CA × グローバルサイン）アクセスすることすらできず、検証するのにとても手こずりました。

■まとめ：ガラケェ・・・

とにかくガラケーは文字コード・SSL周り・HTML対応状況・独自仕様等々の制約が山のようにあり、全ての端末に対応させようと思ったら気が遠くなるほど時間と労力が必要だと体感しました。

他の国がどうなのか分かりませんが、ガラケーの独特の仕様に対応するための時間って凄い無駄なワケで、こういったモノが氾濫してる日本は国家レベルでの競争力低下につながってるんじゃないかと。

良いモノ作りたい人がこういうった制約が足かせになって、機能開発などに時間が使えないのは不幸だと思うわけです。

もし、この記事を呼んで「参考になった！」と思ってくれる人が居て、ガラケー対応の為の時間が省けて良いものを作る時間に1秒でも多く費やしてもらえたら幸いです。

ガラケーはホビロン！！！

マンネリ化したスクラムをアナログ回帰でテコ入れするの巻

2011-07-02T22:45:00.016+09:00

こんにちわ、 chappie です。先日、kmt によるエントリーもありましたが、私も 6/24 に開催されたスクラム道バーストにいってきました。

あまり他社さんがスクラムをどのように実践しているかといったことを知る機会は少ないので、とても刺激になりました。今回のイベントは、壇上に上がってしゃべる人を「選手」、議論を傍聴する人を「観客」として分け、立場に応じた「距離感」で参加できることで敷居を下げていたのがよかったです。私も今回はじめての参加だったので、「とりあえず観客で」といった感じで、見学させていただきました。

イベントの雰囲気は

Togetter - 「スクラム道バースト」

スクラム道 | Facebook

などから感じていただくとして、当日あった議論とはあんまり関係ないですが、このエントリーでは私が今いるチームでの取り組みとして、アナログ回帰による改善のはなしを紹介したいと思います。

私達のチームでの問題

今のチームは、かれこれ半年以上、だいたい同じメンバーで開発に取り組んでいました。１ヶ月を１スプリントとして、

月のはじめに計画ミーティング＆見積り
日々のスタンドアップミーティング
週次での成果物レビュー
月末でのスプリントレビュー＆デモ

など、基本的にスクラムのプロセスにのっとって活動し、月ごとの成果もそれなりには出ていました。

ただ、以下のような問題がありました。

毎月、いまいち当初の予定(見積り)よりも完了できるストーリーの量が少ない
そのため、中長期的にみるとプロジェクト期間がどんどん伸びていく
しかもいまいち原因がよく分からない
遊んでるわけではなさそうだけど、デイリーの進捗がいまいちお互いによく分からない

アナログ回帰

当然、原因はいろいろあって単純ではないのですが、まずは日々何が起きているのか認識＆共有ができていないとはじまりません。

そこで今回、スクラムをはじめた当初やりかけたけどやめてしまっていたアナログ版タスクボードを復活させました。

月初の見積りの段階から、今月のストーリーも、前月の積み残しも、その時点で対応することが決まっているバグも、すべて付箋に書き出し、見積り後はそのままホワイトボードに貼りつけました。

未着手＞処理中＞ Done！

右側にストーリーやバグやタスクなどが概ね優先度順に並んでいて、開発/QA が処理中のものが真ん中に移動してきて、終わったものは右側に移動させます。基本的に、スクラムで説明される一般的なタスクボードのフォーマットを踏襲しています。右側の Done のところがカレンダーになってて、終わった日付に終わったタスクを貼ってるとこが若干オリジナルでしょうか。

付箋のサイズと色

大きいサイズの付箋はストーリーなど基本的に見積り対象となる粒度の項目で、小さいものがその中でのタスクといった感じになってます。ポイントの小さいものは大きい付箋がそのままタスクになってたりします。また、オレンジはビジネスアナリスト(的役割の人)からの懸念事項や、ピンクが臨時、緊急のものといった感じで、なんとなくルールができていきつつあります。

あまりこのあたりは厳格なルールは強いてなくて、忘れないようにしたいことや、進捗を示すためにタスク用付箋をはったりしてます。スクラム道バーストでも「適切なタスクのサイズとは？」みたいな議論があり、どなかが「スタンドアップミーティングで話す１項目が大体１タスクと思っていい」といったことをおっしゃってたと思いますが、我々のタスクボードでも実際そうなっているので同感です。

日々の記録とバーンダウンチャート

タスクボードの状況は一応、撮影して残すようにしています。また、バーンダウンチャートは単純に貼る場所がなかったので、ポイントを Google Docs のスプレッドシートに記録して、こちらはデジタルで見られるようにしています。

タスクボードの動き

ちなみに、月毎のタスクボードをアニメーションにしてみるとこんな感じです。

、、、と思ったらアニメーションGIFがアップできない。。。何故。

しょうがないので、外部サイトにとりあえずアップ。(後で変えるかもしれません)

なんとなく、チームのダイナミズムが見えるような気がしますかね？

かなーり雑然としているあたり、チームの性格が出てるようです。。。

あと、ホワイトボードがあんまりホワイトじゃなくて汚くみえるのは予算がなくてお下がりのホワイトボードしかもらえなかったからです。。。広くて大きいホワイトボードほしい！むしろ、壁全体ホワイトボードにしたい！内装とか別におしゃれじゃなくてもいいから！

従来との違い

・・・閑話休題。

従来、スタンドアップミーティングは大体毎日やっていたのですが、特に何も見ずに、各人が口頭でやったこと、やることをなんとなく話してふわふわっと終了してました。

タスク管理には以前からヌーラボさんのバックログを使っていて、これはこれで素晴らしいツールなのですが、個々人が自分のタスクを管理するためだけのツールになっていました。これはおそらく使い方の問題で、スプリントのはじめにだれが何やるってが割り振ってしまい、自分で自分の範囲のタスクを洗いだして登録し、あとは自分が「担当者」のタスクしか見なくなっていました。

チーム全体の状況を俯瞰するにはタスクレベルだと見づらいし、バーンダウンチャートでは大まかすぎて、結果、スタンドアップミーティングで見ることもありませんでした。

この、「何も見るものがないスタンドアップミーティング」が日々の進捗が分かりにくい原因のひとつだったと思います。

タスクボードを使うようになってからは、各メンバーがここの付箋を移動させながらやったこと、やることを話すようになりました。処理中のものと同時に、当月で何が残っているかも見えるので、デイリーの情報とスプリントの情報がいっぺんに見られます。

懸念事項もとりあえずはここに貼るので、「そういやあの問題ってどうなったんだっけ？」って気づいたら誰も何も対応してなかった、みたいなことも極力減らせます。

まとめ的なもの

アナログ版タスクボードを使い始めてから２ヶ月＝２スプリントほど経過しましたが、個人的には

チームとしてタスクに向きあう姿勢がでてきた
消化できるストーリーポイント数への意識が高まった
残タスクや臨時タスクをなるべく減らしたり、コントロール可能にしようとする議論ができるようになってきた

といった効果を感じています。

チームとして改善サイクルを回していかなければアジャイル開発プロセスの良い点は発揮されません。まだまだ課題も多いですが、その解決に向けた足がかりができたのは大きな前進だと思っています。

タスク管理ツールは使ってるけど、なんとなくチームとして問題に取り組んでる感がなくなってきたり、スプリントを繰り返すうちに締まりが悪くなってきたりしてる、、、と感じたときは、原点に帰るつもりでアナログ回帰し、手触りのあるツールを介したコミュニケーションで活性化することもあるので、オススメです。

■■■

余談1

ちなみに、バーンダウンチャートの中盤でグッと残時間が減ってる点は、弊社のリリースプロセスが反映されています。現在のプロセスでは基本的に、当月開発したものを翌月の第４週にリリースするようになっています。これは主に、ユーザや事業部へのアナウンスおよび調整のための期間が必要なためです。

そうすると、大体のところは当月中に開発するのですが、細かいテストや統合レベルのテストや自動テストの作成など、終盤になりがちなタスクが次の月にずれ込むことで「負債」となってしまいます。にもかかわらず、月初には新しいストーリーの見積りを立てて次のスプリントがはじまります。

このあたりのギャップと、その存在と大きさがはっきり見えていないことが、なんとなく締まりの悪さ、１ヶ月のスケジュールの見通しの立てにくさにつながっていたんだろうと思われます。このあたりもバーンダウンとタスクボードの進捗具合で見える化＆共有されてきたので、今後のプロセス改善に活かしていきたいところです。

余談2

実は、付箋のサイズの区別は意図したものではなくて、ふつうのサイズの10セット入りと思って頼んだら小さいサイズだったという 7500円の誤発注によって導入されたものでした。

Shibuya.tracの第12回勉強会チケット管理システム大決戦第二弾　に登壇させていただきました

2011-07-01T15:58:00.001+09:00

ikeike443です。

昨日、6月30日に行われました、「Shibuya.tracの第12回勉強会チケット管理システム大決戦第二弾」に、パネラーとしてお声がけいただき、登壇させていただきました。

このイベントは、チケット管理ツールであるTracおよびチケット駆動開発を推進するコミュニティであるShibuya.tracさんの第12回勉強会として、Trac,Redmine,JIRA,Backlogの4つのチケット管理ツールについての~~Disりあい~~、パネルディスカッションとして開催されました。

僭越ながら私は、Backlogユーザー代表として、ヌーラボの@ikikkoさんと共に登壇させていただきました。

当日の資料は下記になります。登壇者8名の合作となっています。

Backlogの部分では、弊社シャノンの開発プロセスなども記載させていただいています。
実際のところどうやってスクラムを実施しているか、よく分かる資料になっていると思います！

チケット管理システム大決戦第二弾

View more presentations from Ryuzee YOSHIBA

尚、既に様々な方がブログにて言及してくださっていますので、勉強会全体の内容についてはそちらをご参照ください！！

「Backlogはチケット管理システムの自由民権運動だ！」というフレーズを決めてきましたので、私としては役割を果たせたのかな、と思います！！

株式会社シャノン技術ブログ

オライリーさんの『Jenkins』（通称カエル本）に寄稿しました

Play! でつなげるWebサービス(XML-RPC/OAuth2.0)

Play!frameworkで各種Webサービスにつながってみる

バックログ

セールスフォース

Webサービスのプロトコル

XML-RPC

、、とその前に

では、話を戻して

OAuth 2.0

まとめ

「エンジニアサポート新年会2012 CROSS」参加報告

クラウド時代のプロジェクトマネジメント

アンドロイドアプリを作ってみよう ～ 開発環境準備（その２）～

Class::DBI でインデックス・スキャンができない？

Linux + PostgreSQL + Perl な WEBアプリケーションにおけるタイムゾーンの実装

Haskell で Web スクレイピング

jQueryでCanvasを使ってお絵かき - 実践編

小さな企業が技術ブログやってみた一年、どうだったかのまとめ

産休・育休中に貰えるお金と手続きのポイント その二

Play! frameworkでつくるスクリーンショット取得サービス

スクリーンショット取得サービス

プロジェクト作成

CRUDモジュール

モデル

コントローラ

とりあえずここまでを動かしてみる

スクリーンショットを取得するライブラリの追加

スクリーンショットを取得する処理の追加

取得したスクリーンショットを表示する（ビュー）

まとめ

どうやってソフトウェアのまずさを数値化するかを調べてみる

15分で始めるmonitによるサーバ監視

100ドメイン以上を運用する企業向けクラウドのWebサーバー（Linux + Apache + mod_proxy_balancer ）

Navigation TimingとCanvasを使ったページロード時間の可視化

産休・育休のシャノン体験談 その一

Jenkins, Seleniumを使った自動テストの課題とこれからの取り組み

YAPC::Asia TOKYO 2011 に参加してきました

数百GBのPostgreSQLを一瞬でバックアップする方法

パフォーマンステストをまとめてみた

ちょっと面白いjavascriptコード

Dreamforce '11に参加してきました

ブラウザってどうやって動いてるの？（モダンWEBブラウザシーンの裏側）

ノマドワーカーになりたいので、できるかどうか考えてみた

サーバサイドのレガシーなHTMLに負けずに jQuery Mobile を使おう

Vundle入れたら、Vimのプラグイン管理が楽になった

Websocket, node.js, Socket.io@社内勉強会

テスト環境まるごとAWSにのっけてみた ～第三回 Backlogチャンネル～

明日のBacklogチャンネル・AWSセミナーに会場をお貸しします

ざくっとユニットテスト

JSが苦手なWebデザイナーに贈る たった２つの克服のコツ

JavaScriptを克服するたった２つのコツ？

コツ１：いつ・なにを・どうする？

「いつ？」は、初期表示時、イベント時、サブミット（送信）時の３パターン

「なにを？」は、jQueryのCSSセレクタで指定

「どうする？」は、jQueryに用意されているメソッドを組合せ

コツ２：エラーメッセージを読む

まとめ

mod_rewriteでauガラケーのSSL対応しようとしたら見事にハマった件について

マンネリ化したスクラムをアナログ回帰でテコ入れするの巻

Shibuya.tracの第12回勉強会 チケット管理システム大決戦第二弾 に登壇させていただきました

アンドロイドアプリを作ってみよう　～開発環境準備（その２）～

産休・育休中に貰えるお金と手続きのポイント　その二

産休・育休のシャノン体験談　その一

テスト環境まるごとAWSにのっけてみた～第三回　Backlogチャンネル～

JSが苦手なWebデザイナーに贈るたった２つの克服のコツ

Shibuya.tracの第12回勉強会チケット管理システム大決戦第二弾　に登壇させていただきました