Google特製モレスキンを50名様にプレゼント!Web制作会社限定アンケート!

このたびGoogleさんよりご依頼いただきましたアンケートのご紹介をさせていただきます。

 

皆さんはGoogleさんがWeb制作会社さんに対して無償で提供している

Google オープンビジネスパートナー 」というサービスをご存知でしょうか?

 

「アドワーズをクライアントさんに提案したいけど色々と不安だな・・。」といったWeb制作会社さんに対して営業ツールの提供から、初回キーワード・広告文の作成、電話サポートまでやっている至れり尽くせりなサービスなのですが、皆さんはアドワーズにどのような印象をお持ちでしょうか?

 

「アドワーズという言葉は知っているけど自分とはあまり縁がないかな・・?」という方もいらっしゃるかもしれませんが、そのような方にこそぜひざっくばらんなご意見を聞かせていただきたいと思っておりますので、多くの回答を頂戴できましたらうれしいです。

 

Google特製のモレスキンを50名様にプレゼント!

 

アンケートにご回答してくれた方へのプレゼントとしましてなんとGoogle特製のモレスキンを50冊ご提供いただけました。(当選確率、高いですね!)

 

これは欲しいです・・。

 

できる男の手帳「モレスキン

使いやすい大きさ、13x21cmの「ルールド ラージ」です。

 

シックなレザーにGoogleロゴの箔押し

 

ということで、ご回答いただいた方の中から抽選で50名様にこちらのGoogle特製モレスキンをプレゼントさせていただきます。

 

ご応募の締め切りは4月6日(金)18:00です。ぜひ皆さまご協力のほどよろしくお願いいたします。

 

↓↓↓↓↓↓↓

アンケートに回答する

 

 

 

 

 

もし、あなたがうまい棒1万本をもらったらどうしたいですか? つぶやきまとめてみました!

#うまい棒一万本があれば のつぶやきまとめ - NAVER まとめ

うまい棒一万本を1名様にプレゼント! | さぶみっと!JAPAN

まだまだ募集中ですが、

沢山のつぶやきをもらったので、

NAVERまとめを使ってまとめてみました!

応募してくれた人の中には、既にうまい棒を使って過去に作品を作った事がある人もいたり

それぞれのうまい棒に対する思いや、妄想が渦巻いていて楽しいです!

Agile do IT !行ってきた!内容まとめ!

Agile do IT ! に参加してきました。


http://dena.jp/recruit/open_seminar/agiledoit/

セッションが5つあり1つが50分あるので個々に纏めると
非常に長文になってしまうのでマスター・センセイのお言葉
「やり方はひとつじゃない」
に着目して個々のスクラムマスターが独自に工夫していた点について
「ふりかえり」という形で感想を書きたいと思います。

 

 

■イテレーション#1

「Agile In a Nutshell」~ ざっくりわかるアジャイル開発 ~
Jonathan Rasmusson 氏(マスター・センセイ)

■ふりかえり
全てが英語、翻訳者無し、字幕的なものも無し。
でも英語が判らなくても大丈夫。
「アジャイルサムライ」を読めば全てが絵だけで理解できます。
4274068560
アジャイルサムライ-達人開発者への道-
↑これだけじゃ回し者みたいなので補足すると今回の内容はこの資料とほぼ一緒です。

 

参考元データ

http://agilewarrior.files.wordpress.com/2010/10/agile-in-a-nutshell_ja.pdf

 

アジャイルを実践(学習)するお勧めとして以下の流れがありました。

はじめはここ→XP
言葉使いを選ぶ→Scrum or XP
学ぶ→Lean
上記の流れで実践してきましたがLeanはニワカ知識すら無いので次はLeanを勉強したいと思います。

 

 

■イテレーション#2

ゲーム開発プロジェクトマネジメント事例紹介~不確実性を乗りこなせ~

橋本 善久氏(株式会社スクウェア・エニックス CTO)

※この資料を元に加筆・修正したみたいです。

 

参考元データ

http://www.square-enix.com/jp/info/library/dldata/PM/PM.pdf

 

■ふりかえり

・2点見積もり
・定義 = 最小見積(達成確率20%の期間)+ バッファ(確率80%の期間)
・例:タスクAの工数 = 3日(最小)~5日(最大)
・バッファ消費率XX%も評価に組み込む
例:タスクAの完了期間:3日=0%、5日=100%、6日=150%
※パーキンソンの法則に対処するアプローチに近いと思います。
ポイントでの見積もり精度を2点見積もりで拡張したのは面白いと思いました。

 

 

■イテレーション#3

ヤフー 爆速開発への挑戦!

小野澤 興平氏(ヤフー株式会社)、高橋 一貴氏(ヤフー株式会社)
※高橋 一貴氏のblog
http://d.hatena.ne.jp/kappa4/

■ふりかえり
・正しい情報をより多く伝えようとする事
・ミドル・トップ層の説得には事例を先に作る事が有効。
・定期的なアンケートで、アジャイル導入前後の生産性を比較している。
※ディスカッションは大事ですが、アンケート形式でチーム外部からの
フィードバックを得るのも面白い仕組みかなと思います。

 

 

■イテレーション#4

Scrum絶賛拡大中 on DeNA(仮)

貝瀬 岳志氏、大出 倫也氏(プロダクトオーナー)、森 健太郎氏(スクラムマスター)

■ふりかえり
・Scrumチームの分割
・ミッション型スクラム(ミッション達成に集中しリリース済のタイトルに対しての差し込み案件はやらない)
・ベストエフォートチーム(差し込み案件の対応やら色々)
リリース済のタイトル(プロダクト)の差し込み案件(バグ対応等)が多く重要なストーリーが止まってしまう。
そのため、差し込み案件は専任のチームを作って吸収する。
※これは、うちの開発チームが行なっている対応と同じですね。
ただ、ベストエフォートチームのモチベーションをどう維持してるのかが1番気になったのですが
この問題は残念ながら未解決だそうです。
この課題に対しては今後も継続的に取り組んでいきたいと思います。

 

 

■イテレーション#5

パネルディスカッション – 「Scrum Masters Talk」

<スペシャルモデレータ>
角谷 信太郎氏(株式会社永和システムマネジメント/日本Rubyの会理事)
<登壇者>
Jonathan Rasmusson 氏
立木 貴洋氏(ヤフー株式会社)
髙橋 正博氏(ヤフー株式会社)
貝瀬 岳志氏(株式会社ディー・エヌ・エー)
駒井 仁一氏(株式会社ディー・エヌ・エー)

■ふりかえり
※全てのQAを纏めると長文なのでジョナサン氏の解答のみ抜粋します。

Q.スクラムってしんどい?楽しい?スクラムチームの雰囲気って?
A.ジョナサン:スクラムについて2点。色々なチーム、プロジェクトがあってみんな違う。
たった1人の人がプロジェクトに対してそれくらいの変化をもたらすのか、その成果に驚いている。
だからアジャイル開発は楽しい。

 

Q.スクラムチームの人数どれくらい?
A.ジョナサン:最高12名。最適なのは2、3名。

 

Q.チームの中にJenkins等のスペシャリストは入れるか?
A.ジョナサン:個人的にはチームにスペシャリストは入れないようにしている。
その方が各チームが学べる。

 

Q.チームの外側から要求がやってくる事って無いですか?
A.ジョナサン:予期しない事は必ず発生する。あらかじめアロケーションしておく。

 

Q.意思決定について。チームの意思決定にスクラムマスターとして関わるときにコツ、難しさとかある?
A.ジョナサン:すごくいい質問。基本的に同感。たとえばチーム全体がアジャイルやったことないってときはどうする?
立ち上げ時にブートキャンプを設置する。アジャイルの開発プロセスをリリースする。
何故うまくいかなかったのか、吸い上げる。
プロジェクトを始める前にプロジェクトにかかえる不安を払拭してあげるべき。
チームに一方的にやらせるのはフェアじゃない。トレーニングも必要になる。
反対するチャンスもちゃんと与えて、論議して、やることになったらやる。

 

Q.4つのポイント「TDD,リファクタリング、テスト自動化、CI」についてみんなどれくらいやってるの?
A.ジョナサン:今よりも将来どうしていきたいのか問題。
Obj-Cのテストのやり方をJavaとかC#みたいに知らないけどそれでいい。
学んで定めた方向へ向かっていくのが大事。

 

Q.テストとか自動化に取り組み始めたのは最近の話しで、レガシー超溜まってる。
負債を返済するのが大変で、専任のチームで頑張ってるけど他のチームにまで伝搬するのはまだ時間がかかりそう。
3000行のJSとか困ってる。既存のものにどうやって当てはめていくか難しい。
タイムボックスの確保とか難しい。どうやっていくんだろ?

A.ジョナサン:そんな大きな問題にぶつかる前に小さいことを積み重ねてリファクタリングしていく。
そうはいっても現にこういう問題があるわけだから私だったらこう説明する。
「テストも何もないし設計が最悪だから新しいシステムを作ったほうがマシなんじゃないの?」と提案する。
※↑個人的に1番ツボの解答でした

 

Q.荒ぶる四天王のうち唯一調整が可能な「スコープ」について。
チームや組織はすんなりとスコープの再定義を許す?それとも、揉める?
A.ジョナサン:大規模なプロジェクトではハイレベルのマスターストーリーリストを作ってしまう。
その下にサブストーリーリストを作ってしまう。

 

Q.スクラムマスターに必要なスキルって何?どうやったら伸ばせる?
プロダクトオーナーにに必要なスキルって何?どうやったら伸ばせる?
A.ジョナサン:スクラムマスターとして目標としたほうがいいのは、それを求められない存在にどうやってなるのか。

 

 

【総括】

会場は臨時の座席ができる程の盛況っぷりで、密度の濃い5時間でした。
自分なりにアジャイル開発のどこに惹かれるのか考えてみると以下の2点だと思います。

・チームとしての一体感

・ソフトウェア開発の変化を当たり前と捉え、
関わる人までも自己組織型の人間に変化させていく。

 

また、機会があれば行ってきます!

さぶみっと!中国進出の下見で上海に行って来ました!

さぶみっと!中国進出の下見で上海に行って来ました。

4月からいよいよさぶみっと!も中国に進出します。ということで自身の住居探しも兼ねて上海に行って来ました。
前回は12月に来たんですがその時はめちゃくちゃ寒くて、勝手に上海=寒い的な印象を持っていたのですが、
今回は比較的春めいた良い気候でした。

元々上海には、さぶみっと!JAPANを運営する株式会社イー・エージェンシーの中国現地法人があり、スタッフが既に居るという事も大きな要因です。その他にも僕達が現在日本で展開しているASPサービス郡のローカライズの可能性を探るという事も考えています。お国事情も異なるので、何が売れて何が可能性がないか?みたいな事は正直まだ全然分からないのですが、まあ日本から見て少ない情報の中で色々考えるよりもまあ実際来ちゃった方がマーケットの状況がより肌感として感じれるんじゃないかな?といった感じです。

 


上海易愛网絡技術有限公司
http://www.e-agency-china.com

これまで株式会社イー・エージェンシーの中国現地法人である上海易愛网絡技術有限公司(http://www.e-agency-china.com/)では

現地でのWebソリューション事業、現地でのシステム開発や日本とのオフショア開発の拠点として活動してきましたが、そこにアドオンでさぶみっと!的なビジネスの可能性を模索していければなと思っています。

僕達さぶみっと!もここを拠点として活動していきます。
オフィスの場所はこちらになります。

[中国支社 上海インタラクションセンター]
〒200120
中国上海市浦东新区浦东南路1088号中融大厦1111室


大きな地図で見る

 

オフィスビルのエントランスの写真

オフィス内の風景

オフィスの周りの風景写真

やっぱり言われている通り、オフィスの回線からはFacebookやTwitter、Youtubeとかにアクセス出来ないんですね。
何かそれだけでも完全アウェー感漂います(汗)
でも、日本の携帯からはFacebook、Twitter、Youtube見れますね。

4月以降お仕事等々で上海に来るって方おられましたら、是非お立ち寄りください。

サーバ監視ツール「munin」の使い方 ~ その2 ~

前回の記事はこちら↓

サーバ監視ツール「munin」の使い方 ~ その1 ~

監視項目を増やしてみる

前回のmunin-nodeインストールだけでもハードウエアの利用状況はかなり詳しくグラフ化されます。
日々の負荷状況はだいたい把握でき、サーバ追加の際のマシン見積もりなどには使えますが、今回はさらにmuninを利用してアプリの領域もグラフ化してみたいと思います。

プラグインの追加、削除

サーバにいろいろなグラフが登録されていますが、これらを入れ替えたりできます。
ノード側で/etc/munin/plugins/にある該当のシンボリックリンクを削除してmunin-nodeのrestartになります。(サーバ側は何もしなくてよい)

例)sendmail系の監視が不要なとき

# rm /etc/munin/plugins/sendmail_mail* # service munin-node restart;date Stopping Munin Node agents: [ OK ] Starting Munin Node: [ OK ] Thu Mar 15 16:43:42 JST 2012

このようにrestartの時刻を同時に出しておくと後でわかりやすいです。
※サーバ側に反映されるのは10分後ぐらい

Apacheの監視

次にApacheの監視をしたいのでシンボリックリンクを追加します。

# ln -s /usr/share/munin/plugins/apache_accesses /etc/munin/plugins/
# ln -s /usr/share/munin/plugins/apache_processes /etc/munin/plugins/
# ln -s /usr/share/munin/plugins/apache_volume /etc/munin/plugins/

ここでmunin-node restartしますが

Apacheの情報を取得する為にノードのApacheにmod_statusセットアップする必要があります。

/etc/httpd/conf.d/status.confというファイルを作って以下を書いて


    ExtendedStatus On
    
        SetHandler server-status
        Order deny,allow
        Deny from all
        Allow from 127.0.0.1
    

apache再起動

# /etc/init.d/httpd configtest
# /etc/init.d/httpd graceful

server-status確認

# wget -q -O - http://127.0.0.1/server-status/?auto

こんな感じで見られるようになりますのでApacheのチューニングに役立ちます。

Webサーバには入れておきたいプラグインですね。

・本番稼働中は避けたい作業ではありますので、なるべく早い段階で入れておきたい
・名前ベースのVirtualHostのWebサーバなどで
http://127.0.0.1/server-status/?auto
にアクセスできないとグラフが出てこないことがあります。

MySQLの監視

MySQLを動かしているノードがあれば監視してみましょう。
以下で、コネクション数、queries、slow queries、threads、throughputをグラフ化できます。
ボトルネックの発見、my.cnfのチューニングに使えます。

シンボリックリンク

# ln -s /usr/share/munin/plugins/mysql_bytes /etc/munin/plugins/mysql_bytes
# ln -s /usr/share/munin/plugins/mysql_queries /etc/munin/plugins/mysql_queries
# ln -s /usr/share/munin/plugins/mysql_slowqueries /etc/munin/plugins/mysql_slowqueries
# ln -s /usr/share/munin/plugins/mysql_threads /etc/munin/plugins/mysql_threads

MySQLユーザ追加

mysql>
CREATE DATABASE munin;
GRANT SELECT ON munin.* TO munin@localhost IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

設定ファイルにMySQLのログイン情報を記述する

# vi /etc/munin/plugin-conf.d/munin-node
※以下記述例
[mysql*]
env.mysqlopts -u munin --password=password

munin-nodeリスタート

それぞれ動作テストをする

# cd /etc/munin/plugins
# /usr/sbin/munin-run mysql_bytes
# /usr/sbin/munin-run mysql_queries
# /usr/sbin/munin-run mysql_slowqueries
# /usr/sbin/munin-run mysql_threads

こんな感じのグラフが得られます。

さらにプラグインを追加すればinnodeb専用の細かいグラフも出すことも可能です。

負荷について

・サーバはノードの数が増えると結構負荷がかかります。いきなり対象台数を増やすと、5分おきのcronが回らなくなることもあるので注意が必要です。
※グラフ描画にリソースが食われるようです。

・ノードはデフォルトのプラグインであれば、それほど負荷で困ることはないですが、新たに組み込むプラグインによっては影響も考えられますので確認してから組み込んだ方が無難です。

その他tips

設定したはずなのにグラフが出ないということがあって原因がつかめず困るときがあります。そうした場合の確認として
・ノードでmunin-nodeをrestartし忘れしていないかをまず確認
・ノードでコマンドを直接実行してみて結果が出ているか

# /etc/munin/plugins/apache_processes
busy80.value 1
idle80.value 19

・ノードのログを確認してみる

# tail -f /var/log/munin/munin-node.log

・サーバのログを確認してみる

# sudo grep "Error in node" /var/log/munin/munin-update.log|tail -50

・サーバからtelnetで確認してみる

# telnet ノードのIP 4949
Connected to ノード
Escape character is '^]'.
# munin node at xxx.xxxx.
list ← 一覧を見るコマンド
open_inodes http_loadtime if_err_eth0 apache_processes entropy irqstats processes apache_accesses if_eth0 apache_volume cpu_by_process df interrupts netstat swap load df_inode cpu open_files forks ntp_ntp1_sakura_ad_jp iostat memory vmstat
fetch apache_volume ← fetch [調べたいプラグイン名]
volume80.value 29828096

参考にさせていただきました。

http://munin-monitoring.org/wiki/FAQ_no_graphs
http://www.mbrando.com/2007/08/06/how-to-get-your-mysql-munin-graphs-working/
http://d.hatena.ne.jp/yoshi-ken/20101106

追記

1.2.5で動かしていたmuninサーバを1.4.5にバージョンアップした時の情報です。
同じことをする人が何人いるかというようなマニアックな情報ですが、バージョンアップしたことにより、サーバのリソースがさらに消費されるようになりました。バージョンアップにより、収集する情報がきめ細かくなった結果と思われます。

インストールメモ

 

もともと1.2.5が入っていたmuninサーバで

epelを指定してインストール

# cd /usr/src/
# ll
# wget ftp://ftp.univie.ac.at/systems/linux/fedora/epel/5/i386/epel-release-5-4.noarch.rpm
# rpm -ivh epel-release-5-4.noarch.rpm
# vi /etc/yum.repos.d/epel.repo
※enabled=0 → 1を0に変更
# yum --enablerepo=epel install munin

結果以下がインストールされた

yum: Installed: perl-Log-Log4perl-1.13-2.el5.noarch
yum: Updated: munin-1.4.5-5.el5.noarch

DocumentRootが変わった

1.2.5 /var/www/munin httpd/conf.d/monin.confで/munin/にエイリアス
1.4.5 /var/www/html/munin 実ディレクトリが作成された

/etc/munin/munin.confファイルの更新

古いmunin.confは更新されなかった
munin.conf.rpmnewと比較すると設定ディレクトリなどが異なるので
munin.conf.rpmnewをもとに既存のサーバ設定を追加したmunin.confを作成。
→古いグラフデータも残った

httpdの調整

ファイル

/etc/httpd/conf.d/munin.conf

/etc/httpd/conf.d/munin.conf.rpmsave

となった。
→上記Basic認証などで必要であれば再調整する

各ノードの確認

・グラフが依然と変わりなく出るかを確認
・サーバログでエラーが出ていないか観察
※サーバをバージョンアップした後、一部のノードでmunin-nodeのリスタートしないとログにエラーが出てグラフが一部作成されないという現象がありました。
 
 

Munin関連の記事はこちら

サーバ監視ツール「munin」の使い方 ~ その1 ~

サーバ監視ツール「munin」の使い方 ~ その2 ~

サーバ監視ツール「munin」の使い方 ~ その3 ~

サーバ監視ツール「munin」の使い方 ~ その4 ~

 

「Windows Developer Days」に20名様を特別ご招待!!

このたび「さぶみっと!ホームページ制作マッチング」にご登録のWeb制作会社数が1万社を突破したことを記念いたしまして、マイクロソフトさんよりうれしいプレゼントを頂戴いたしました!

 

通常参加費が8万円となるプレミアムなイベントWindows Developer Days」(4/24(火)~25(水)開催)にナント、20名様を特別にご招待いただけることになりました!(マイクロソフトさん本当にありがとうございます!)

 

参加を希望される方はこちらよりご応募ください。

 

Windows Developer Days とは・・?

 

すでにアプリ開発を行ってる方や Windows 8 やWindows Phone でビジネスを展開したいという方は必見のイベントです。

 

米国本社 Windows 開発部門の責任者が、Windows プラットフォームで広がるさまざまな可能性についてご紹介されたり、キーノート セッションやブレイクアウト セッションで知識を学ぶだけではなく、実機を使って、Windows 8 での Metro Style アプリケーション開発を体験することができるとのことです。

 

マイクロソフトさんから当イベントについてのご説明をいただきました。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Windows Developer Days 4月24日、25日 開催!アプリ開発者のための学びの 2 日間。

 

アプリ開発者の方々を対象としたマイクロソフトの新しいイベント【Windows Developer Days】を開催することになりました。

 

Windows Phone や Windows 8 でも採用されている Metro と呼ばれる新しい UI に対応したアプリケーションは、C++ や C#、XAML だけでなく、 Web を支える技術 – HTML5 や JavaScript での開発が可能になっています。

 

この機会にぜひ意欲の高い皆様に、次期バージョンのオペレーティング システムとなる Windows 8 の可能性と技術を肌で感じ、また学んでいただければと思い、わずかではありますが特別な招待枠を設けさせていただきました。

 

イベント内のセッションもこの Metro Styleアプリを開発するための実践的な内容を取り揃えています。皆様の応募をお待ちしております。
詳細につきましては当イベントの公式サイトをご覧ください。
http://www.microsoft.com/ja-jp/events/wdd/default.aspx
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 

Windows Developer Days 開催概要

 

・イベント名:Windows Developer Days (イベントサイト
・開催日時 :4月24日(火)、25日(水)2日間開催
・開催時間 :10:00~18:00(受付開始 9:30~)

※初日はパーティー開催のため19:00終了予定
・セッション内容:イベントサイトをご確認ください。
・会場   :ザ・プリンス パークタワー東京  地下2階 (東京都港区)
・住所   :東京都港区芝公園4-8-1 (Googleマップで開く
・アクセス :こちら

 

特別招待への応募はこちら

 

ご参加をご希望の方は以下のフォームよりご応募ください。

ご応募の締め切りは3月27日(火)18:00となります。
当選者の方には3月30日(金)までに弊社からの当選メールをお送りさせていただきます。
※当選者の方は、当選メールに記載されている内容に従って、Windows Developer Days への申し込みを行っていただく必要があります。

 

ぜひとも当イベントにご参加されてこれからのビジネスにお役立ていただけますと幸いです。

 

 

↓↓↓↓↓↓↓
ご応募はこちら

<2012年3月28日追記:たくさんのご応募ありがとうございました!>

 

 

うまい棒一万本を1名様にプレゼント!


さぶみっと!ホームページ制作マッチング」にご登録のWeb制作会社数が1万社を超えたことを記念しまして、この感謝の気持ちをどのようにしてあらわせばよいか・・。

 

ひとえに1万社と言っても、そこには1社、1社の重みがあるということを忘れてはいけない。

 

 

 

そうだ。

 

 

 

1社、1社がうまい棒だったらどうだろう?

1万という数をあらためて実感することができるのではないだろうか・・?

 

 

 

うまい棒、1万本・・・・。

 

 

 

そんなひらめきが間違いだったのか、このときにはまだ知る由もないが、、

うまい棒1万本を注文してみた・・。

 

 

 

 

ぐがぁぁ。

 

 

 

 

 

ダンボール17箱が届いた・・。

 

 

とりあえず、開封してみる・・。

 

 

このまばゆさ、、まるでお花畑のようないろどり・・。

 

 

そして、取り出してみる・・。

 

 

このボリューム・・、1万本(1万社)って相当すげーぞ・・!

 

 

ふぅ。

 

 

とりあえず、窓ガラスと床に敷き詰めてみた・・・。

 

おー。いいですねー。

 

 

うーん。でもどうだろう・・・。

 

 

 

これだけでいいの・・・?

 

 

 

「なんか、インパクトに欠けるよね?
もっとおもしろいことできるんじゃない・・?」

 

 

そう言ったの誰よ・・?

 

おもしろいことってなによ・・?

 

 

 

うまい棒といえばコレでしょ?

 

 

え、コレ・・

 

 

 

 

コレ・・・・!?

 

 

 

 

 

 

本当にありがとうございます。

 

 

 

 

 

大人がやるとこうなります・・・。

 

こんにちは!こんにちは!うまい棒マンだよ。

 

 

 

1万社突破のポーズでおどけてみたよ!

 

 

一万本とうまい棒マンだよっ!

 

 

うんうん。いいよーいいよー。(周囲のスタッフ)

 

 

さー。そのまま行ってみようか!(周囲のスタッフ)

 

 

え!?行く!?の・・・?(うまい棒マン)

 

 

そっか・・。

 

 

 

 

意外とまわりは気づかないのかもしれない・・・。

 

 

 

なぜかやって来た、秋葉原!!手にはもちろん、うまい棒。

 

 

 

あなたの近所のアキハバ~ラ!

 

 

 

次に向かうは上野公園、西郷どん。

祝!1万社!

 

 

 

末永くよろしくお願いいたします!

浅草の雷門。

 

 

 

一万社突破したなら更なる高みに行きたいよね!

東京スカイツリー!

 

 

 

あんたやっぱりデケーよ!!

 

 

 

その気になれば飛ぶことだってできるはず!ぐわっ

 

 

 

そして渋谷、ハチ公へ。

 

おれもしょせんは忠犬さ!

 

 

 

すまし顔のモヤイ像さん。

 

 

 

スクランブル交差点で信号待ち。

 

 

 

人が多いぜ!

 

 

 

 

渋谷スクランブル交差点からおつかれーーー。

 

 

 

ハンバーガーを食べて帰ったとさ。

 

 

 

動画でまとめてみるとこうなる。(音声付き)

 

浅草、上野、秋葉原、渋谷にうまい棒マンが出かけたよ!

 

「キモイ~!」とか「こわっ!」とか「Yo!ガチでピエロ!」とか、いろいろ言われて何度もくじけそうになりましたけど、これもすべて1万社の重み!と言い聞かせて、楽しい東京観光をすることができましたよ。

 

 うまい棒マンだよ。。

 

そしてそんなこんなで応援してくれる人もいらっしゃたり、ちょっと浮かれてしまったのも事実であります。どうもありがとー。

 

 

 

 はい。

 

 

という長い前振りは置いておきまして本題に入りますと・・・、

 

 

この1万本のうまい棒を1名様にプレゼントさせていただきます!

 

 

ただ募集をしてもつまらないので、

 

 

「もし、あなたがうまい棒1万本をもらったらどうしたいですか?」

 

というお題で

 

「うまい棒が1万本あったらこんなことをやりたい!!」というのを送ってください。

 

うまい棒を使って、愛しの恋人にプロポーズしてみるのもいいかもしれません。

うまい棒の可能性は無限大です。

 

一万本のうまい棒ご応募方法

Twitterでの応募方法

 

●まずは、さぶみっと!JAPANのTwitterをフォローしてください。(DMで使います。)

 

●本文に「http://www.submit.ne.jp/775」と「#うまい棒一万本があれば」を入れて、
うまい棒1万本の活用方法をツイートしてください。
例:「 うまい棒1万本で○○したい!! #うまい棒一万本があれば」

 

●ご応募の締め切りは3月30日(金)です。

 

●お送りいただいたツイートを拝見のうえ、当選者を決めさせていただきます。

 

●当選者には、さぶみっと!JAPAN のツイッターよりDMをお送りしますので送付方法、
もろもろについてご相談させてください。

 

こちらのボタンからもどうぞ

 

Facebookでの応募方法

 

うまい棒一万本プレゼントキャンペーンページからよろしくお願いいたします。
うまい棒一万本プレゼントFacebookページ

 

 

応募していただく際に、シェアする際に

#うまい棒一万本があれば を入れてシェアしていただけると当選確率UP?

 

 

みんなのツイートをまとめてみました。

さっそくたくさんの意気込み、妄想をお送りいただきありがとうございます!そんな皆さまのツイートを抜粋して一部をまとめてみました。なかなかのつわものぞろいです。

 

もし、あなたがうまい棒1万本をもらったらどうしたいですか?つぶやきまとめ。

 

 

ご注意

●うまい棒1万本はダンボール17箱、重量約100kg、エネルギーが約33万キロカロリー
ほどございます。当選時にそれらが搬入可能な十分なスペースおよび摂取可能な体力を
確保のうえご応募ください。

 

●うまい棒の賞味期限は2012年8月となります。1万本をひとりで食べようとすると
1日70本を食べなければいけない計算ですが健康をおびやかす恐れがありますので
ご注意ください。

 

●職場やご友人にお配りしたり、街頭で配布してみるのがいいかもしれませんが転売は
ご遠慮ください。

 

●商品をお届けさせていただく際にスタッフがお伺いしますので、搬入された当選者様の
ご自宅or会社の写真を撮らせてください。

 

たくさんのご応募をお待ちしております!

最後になりましたが、私たち さぶみっと!JAPAN がありますのは本当に皆さまのおかげです。これからも末永くよろしくお願いいたします!!

 

 

<追記>当選者が決まりました!

たくさんのご応募ありがとうございました。当選者が決まりました。ぜひ以下のエントリーをご覧ください。

 

うまい棒一万本を1名様にプレゼント!当選者発表!

 

 

 

 

 

サーバ監視ツール「munin」の使い方 ~ その1 ~

muninはサーバのさまざまな情報をグラフ化して表示するソフトです。
つい”ムーニン”と言ってしまいますが、”ムニン”がいいようです。
サーバ監視ツールということですが、例えて言うなら、自動車のメーター類のような働きをします。Ganglia、CactiやCloudForecastが同分類のソフトになります。

rolands.lakis

具体的にどのような場面で重宝するかと言いますと、サーバを増やす際のスペックを検討するときも、失敗する可能性が減らせます。

 

メモリをいくら搭載するものを用意すればいいのか、CPUはもう少し安いものでも問題無いのかなど、見積もることが簡単になります。

 

例)メモリを48GB搭載したサーバの利用状況

 

また以前は、何か障害が起きたときに、人間が手動でデータをかき集めてくるということをよくやっていましたが、Muninを入れてからはその手間は減り、より詳しい情報を参照して原因の特定・対策を講じることができます。

 

例)Webサーバに急激にアクセスが発生した

 

通知機能のあるソフトと組み合わせ

muninはグラフの作成がメインです。
Nagiosなど通知機能のソフトと併せて使うことでよりしっかりとサーバの運用ができるようになります。

※追記 詳しくはhttp://www.submit.ne.jp/1043に書きました

 

 

 

以下、弊社でmuninを利用している情報を共有したいと思います。数回に分けることにして、まずはインストールからです。

 

用意するもの

■muninのサーバ
グラフを表示するWebサーバになります。

Basic認証やIP制限などを行った方がいいと思います。

 

■監視される側のサーバ(ノード)

localを監視することも可能。

 

インストール(サーバ)

※EC2のCentOS5.6 64bitで試してみました。

一発でいけました。

# yum --enablerepo=epel install munin

※yumのepelリポジトリを追加する必要があります

localもノードにしてグラフを出したいので、ついでにmunin-nodeもインストールしておきます。

# yum --enablerepo=epel install munin-node

あとは

# service httpd start

してブラウザで

http://IPアドレス/munin/

にアクセスしてみると

 

 

サーバのリストが見えます。※まだ、localhostのみが対象

 

サーバにさらに監視対象を追加したい場合は
/etc/munin/munin.confに

[ノードのカテゴリ名;ノードのサーバ名]
address XXX.XXX.XXX(ノードのIP)
use_node_name yes

としておきます。特に何かを再起動する必要はありません。

次にここで登録したノードの設定です。

 

インストール(ノード)

前述のyumでmunin-nodeをインストールします。その後まずtcp/4949がサーバから通るようにする必要がありますので、ファイアーウォール, iptables, hosts.denyなど調整が必要になるケースがあります。

さらにノード側でサーバのIPを追記します。

/etc/munin/munin-node.confをエディタで開いて

allow ^XXX\.XXX\.XXX\.XXX$(サーバのIP)
allow ^127\.0\.0\.1$
の下辺りに追記しておきます。
# /etc/init.d/munin-node start

# chkconfig munin-node on

再起動がかかってもmunin-nodeが動くようにしておきます。

 

サーバからテスト通信、

# telnet [ノードのIPアドレス] 4949

を実行して

Connected to 略
Escape character is '^]'.
# munin node at backup

のようになればまずはOKです。

5~10分待つと追加したノードもグラフが出てきます。

ログはサーバ、ノードとも

/var/log/munin/

にあるので、参照すれば状況が分かります。
 
 

Munin関連の記事はこちら

サーバ監視ツール「munin」の使い方 ~ その1 ~

サーバ監視ツール「munin」の使い方 ~ その2 ~

サーバ監視ツール「munin」の使い方 ~ その3 ~

サーバ監視ツール「munin」の使い方 ~ その4 ~

 

第7回さぶみっと!オフ会レポート!たくさんのご参加ありがとうございました!


2012年3月8日(木)に東京・渋谷で第7回目となる「さぶみっと!オフ会」が開催されました。年度末のお忙しい時期にもかかわらず100名ほどの皆さまにお集まりいただきありがとうございました!「さぶみっと!オフ会」をきっかけによいご縁を見つけていただけましたら私たちとしてもとてもうれしい限りです。

 

今回は初めての試みとして、ご参加いただく皆さまのリストを前日にお送りしまして、「普段どういうことをやっているのか」「オフ会ではこういう人と会いたい。」といった意気込みを事前にご覧いただくことができましたので、よりスムーズな交流を図っていただけたのではないかと思います。

 

また、前回のオフ会で「話し込むと時間を忘れてしまうので、残り時間がわかる工夫があるとうれしい。」という声もありましたので経過時間をマイクでお伝えしたり、「料理のボリュームが少なかった。」という声にはお店にお願いして前回よりもボリュームを増やしてもらったりしました。

 

まだまだ改善点や反省点はありますが、これからも皆さまに喜んでいただけるような場を提供していければと思っております。

 

そんな100名の皆さまにお集まりいただいた当日の写真を少しだけご紹介させていただきます。

 

オフ会にご参加いただいてどうでしたか?アンケート内容を公開

ご参加いただいた皆さまにオフ会についてのアンケートを頂戴しました。
あたたかいご意見もあり、これらはぜひ次回のオフ会に活かしていきたいと思います。

 

Q.1 オフ会に参加していかがでしたか?
33% とても満足だった
53% 満足だった
12% 普通だった
3% よくなかった
0% 全然よくなかった


Q.2 オフ会でよかった点を教えてください。(複数選択可)
44% 参加人数が多かった(ちょうどよかった)
70% たくさん名刺交換ができた
47% よい方と出会うことができた
50% 参加者リストが役に立った
17% お店の雰囲気がよかった
6% 料理のボリュームがよかった
0% よかった点はなかった


Q.3 その他、よかった点などありますでしょうか?
・みなさん、出会いを求める前提なので、きっかけが作りやすかった。
・これだけの大人数で、これだけ業界の方や意識の高い方が多いのは素晴らしいことと思いました。
・こうゆう機会があること自体が良かった。


Q.4 オフ会でよくなかった点を教えてください。(複数選択可)
6% 参加人数が少なかった
6% あまり名刺交換ができなかった。
20% あまりよい方と出会うことができなかった。
11% お店の雰囲気がよくなかった
47% 料理のボリュームが少なかった
17% よくなかった点はなかった


Q.5 その他、よくなかった点などありますでしょうか?
・お店の照明が暗くて、参加者の表情が分かりにくいときがありました。
・参加人数が多すぎて会場の混雑が圧迫感があった。もう少し、ゆったりしていたほうが良いと思います。
・デザイン、システム、営業・マーケ等のカテゴリーでの色分けがあっても良かったのかなと思いました。


Q.6 参加者さんリストの事前配布はいかがでしたか?
87% 役に立った
9% 役に立たなかった
4% 事前配布を希望しなかった


Q.7 さぶみっと!オフ会にまた参加したいですか?
97% 参加したい
3% 参加したくない

 

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

出会いの場を企画して下さってありがとうございました!とても有意義に過ごせました。
2,3か月に一度くらいのペースで行っていただくのも良いような気がします。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

当方も企画・運営する立場なので、これだけの人数を集めて開催することがいかに大変か分かりますが、素晴らしい場を提供いただきありがとうございました。

Webサイトの運営側の方も数名参加いただいており、良い交流ができました。ぜひ今後も引き続きこのような企画をしていっていただければと思うので何卒よろしくお願いいたします。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

まずは運営スタッフの皆様、お疲れさまです。
Webという括りの色々な立場の方と出会えて、とても有意義な時間でした。
リスト事前配布は役に立ちましたが、マイクでの呼び出しは話に集中していると聞こえないのに加えて、会話が遮られてしまうことが多かったです。
ネームホルダーを名刺ではなく、リストに掲載されていた番号にしてはいかがでしょうか。(ゼッケンくらい大きくても良いかもしれません(笑))
今後も、期待しておりますので、よろしくお願い申し上げます。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

毎回思いますが、とてもイイ方と出会えます!!
他の方に聞いても、御仕事につながったなどよく聞きます。
是非、また参加できればと思います!!

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

参加者の方が応募する際に、「当日出会いたいターゲット(Webエンジニア/Webデザイナーなど)」を必須入力項目にして頂くと、それを見て直接こちらから話かけたり呼び出したりして頂いて、
より効率的にマッチングが行えるのではないかと思います。

「話かけてみるまでどういう人か分からない」というのもそれはそれで面白いのですが、基本的には「自分とマッチングする可能性の高い人から順に話しかけていく」という方が時間を
効率的に使えると思いますので、「どういう人/会社またはどういうスキルを持った人と出会いたいか」的なことを、資料を見て一目で分かるように一工夫してもらえるといいなぁと思いました。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

可能な限り毎回参加したいと思っています。
地方で仕事をしていますと、日本の中心ではどういう状況なのか、現場のお話ができるので大変勉強になります。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

雰囲気もよく素敵な会でした。ありがとうございました。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

参加者約3割と情報交換ができ、有意義な時間を過ごしました。こういう交流会って大事だなと思います。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

あんなにたくさんの方たちとお名刺交換できる機会はあまりないので有意義な時間でした。欲を言えば、もう少し広い空間でゆったりとできるといいかなと思います。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

活気のあるイベントでよかったです。お疲れさまでした。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

交流の機会をつくっていただいてありがとうございます。
これからもご発展お祈りしております。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 

たくさんのご感想ありがとうございました。
またやりますので、またいらしてください!

 

祝!「さぶみっと!ホームページ制作マッチング」Web制作会社のご登録数が1万社を突破!!

2001年より運営しております、Webの案件に特化したビジネスマッチングサイト「さぶみっと!ホームページ制作マッチング」にて、Web制作会社さん(フリーランスの方も含む)のご登録数が1万社を突破しました!

 

運営開始より11年という年月をかけて、多くの方にご利用いただいた賜物(たまもの)です。
本当にありがとうございます!

 

1万社突破までの道のり

サイトがオープンした2001年といえば、小泉内閣の発足にはじまり9月11日にはアメリカ同時多発テロ事件が起こるなど、歴史的側面から見ても激動の年ではありましたが、そんな情勢を横目に「さぶみっと!ホームページ制作マッチング」はひっそりと誕生しておりました。

 

おかげさまでご利用いただく方も徐々に増え、開始1年半で1,000社を突破したのを皮切りに、登録ペースは順調に加速していきました。


━━━━━━━━━━━━━━━

1,000社突破: 2002年 9月
2,000社突破: 2004年 5月
3,000社突破: 2006年 4月
4,000社突破: 2007年11月
5,000社突破: 2008年 9月
6,000社突破: 2009年 2月
7,000社突破: 2009年11月
8,000社突破: 2010年 3月
9,000社突破: 2011年 1月
10,000社突破: 2012年 3月←New!

━━━━━━━━━━━━━━━

 

1万社突破をサイトデザインの変化で振り返ってみます

2001年当初はこのような時代を感じるデザインでして、3,000社に達する2006年あたりまでこのデザインでご利用をいただいておりました。

2007年には、「案件」だけのマッチングに加え、「人材」のマッチングを開始しました。

人材のマッチングは、ユーザーの皆様からのご要望を受けてリリースしたコンテンツとなり、トップページに「案件」と「人材」を並列にして表示していました。

2007年~2008年4月までのデザイン。

2008年11月までのデザイン。このころに5,000社を突破しました。

6,000社を突破した2009年2月ころのデザイン

そして2009年3月より現在のデザインとなりいくつかのコンテンツ追加を行ったこともあり、この3年間で4,000社が増え、このたび10,000社に到達いたしました。

1万社を突破したので何かやりたい。

せっかく「1万」というメモリアルな数字ですし、皆さんにも喜んでもらえるような企画をやりたいと思っています。遅ればせながら社内にて鋭意検討中でありますので、またその様子は別途お伝えさせていただきたいと思っています。

まずは1万社突破したことに改めて御礼を申し上げます!

 

WEBサイト負荷テストツール7選

WEBサイトに情報を入力するだけで負荷テストができるLoad Impact、GUIから操作できるApache JMeterや、コマンドラインから使うcurl-loaderhttperfSiegePylotabを簡単な使い方と共に紹介していきます。

 
 

Load Impact

http://loadimpact.com/

Load ImpactはスゥエーデンのGatorhole AB社が管理している、フォームに必要な情報を入力するだけで負荷テストをしてくれるWEBサイトです。
ツールをインストールしたりする必要が有りませんので、非常に楽です。

毎月5回まで無料で負荷テストができます。
それ以上は10回/$30のクレジットを購入する事になります。

トップページのフォームにURLを入れて「Run free test」をクリックすると、世界各地のいずれかのAmazon EC2サーバから負荷テストのアクセスが開始されます。

これだけでも使えなくはないですが、会員登録をして、東京のAmazon EC2サーバから負荷テストをしてみます。
トップページ右上の”register”をクリックしてください。

メールアドレスとパスワードを入力して登録するか、もしくは、Googleアカウント、OpenIDなどからでも登録できます。
登録確認のメールアドレスに記述されているURLを開いて、フォームに従って入力していきます。
これでアカウントが出来ました。

さっそく負荷テストをしてみましょう。
メニューの”Test configurations”をクリックします。

“Create test configuration”をクリックし、各種項目を設定していきます。
Load zoneのプルダウンで”Tokyo, JP(Amazon)”を選んでおきます。

“Create test configuration and start test”をクリックすると、負荷テストが開始されます。

完了しました。

負荷テストのシナリオが簡単に設定できるのが格好いいですね。

 
 
 

Apache JMeter

http://jmeter.apache.org/

JMeterはJakartaプロジェクトが開発している無償(Apache License, V2.0)の負荷テストツールで、
GUIインターフェースを使ってかなり細かく負荷テストのシナリオを設定する事ができます。
面白いのは、ブラウザで辿ったページを記録して、それに対して負荷テストをしたりする事もできたりする点です。
インストールは簡単で、JavaでできているためOSに依存せず、JavaがインストールされているWindows、Mac OSX、Linuxなどで実行可能です。

ここでは、WindowsのPCにJMeterをダウンロードしてカンタンな負荷テストを走らせてみます。

 

▼Javaのインストール

まず、Javaをダウンロード & インストールします。
以下のサイトからダウンロードできます。
http://java.com/ja/download/

Javaのインストールが終ったら、以下のサイトにアクセスして、Binariesの項目からapache-jmeter-x.x.zipファイルをダウンロードします。
http://jmeter.apache.org/download_jmeter.cgi

 

▼JMeterの起動

zipファイルを解凍します。
解凍されたフォルダの中から bin フォルダを開き、jmeter.bat をクリックすると
コマンドプロンプトが表示されたのち、JMeterが立ち上がります。

起動しました。

 

▼負荷テストのシナリオを設定

「テスト計画」を右クリックしてスレッドグループを作成します。

作成されたスレッドグループをクリックして「スレッド数」(同時アクセス数)と「ループ回数」(連続アクセス数)に数値を入力します。

※JMeterはテストを実行しているPCのスペックによって負荷テストできるスレッド数などが制限されますので、高い数値を入力すると正確に試験できない可能性がありますので注意です。

「ワークベンチ」を右クリックしてHTTPプロキシサーバを作成します。

右下の「開始」をクリックします。

 

▼Webブラウザのプロキシを設定

Windowsの「コントロールパネル」から「インターネット オプション」を開き、「接続」タブの「LANの設定」を開きます。

「LANプロキシサーバを使用する」にチェックを入れます。
アドレスに “127.0.0.1”または”localhost”、ポートに “8080” を入力して 「OK」をクリックします。
最後に、「適用」をクリックして下さい。

 

その後、負荷テストしたいページをWebブラウザで閲覧します。
閲覧したURLのリストがJMeterのスレッドグループに記録されていきます。
記録を確認するときは、左メニューの「スレッドグループ」をダブルクリックします。

記録ができたら「HTTPプロキシサーバ」の設定を開いて「停止」をクリックします。
停止したら、負荷テストするを必要のない記録を削除しておきましょう。

 

▼負荷テスト

「スレッドグループ」を右クリックして、「グラフ表示」と「統計レポート」を追加します。

メニューから「実行」→「開始」をクリックすると、テスト計画ファイルの保存画面が出てきますので保存しておきましょう。
テスト計画の保存ができると、負荷テストが開始されます。


完了しました。

負荷テストが完了したら、Windowsの「インターネット オプション」の設定を元に戻しておきましょう。
JMeterを使っての負荷テスト方法については、こちらの資料が参考になりますので、お奨めです。

Apache JMeterで負荷試験をしよう!
http://www.jasst.jp/archives/jasst07e/pdf/C2-1.pdf
水野浩典
コアテクノロジー部 コンサルティング▼インテグレーション統括本部 日本ヒューレットパッカード株式会社

 
 
 

curl-loader

http://curl-loader.sourceforge.net/

curl-loaderはイスラエル人のRobert IakobashviliとMichael MoserによってC言語で作成された、コマンドラインの負荷テストツールです。
ライセンスはGPLv2で無料で使えます。

複数のIPアドレスを生成して別々のクライアントからリクエストが来ているような状況を作る事ができます。
また、段階的にアクセス数を増やしていく設定なども可能です。
Linux環境で動作します。

 

▼インストール

インストールするOSはCentOS 5.7です。

# cd /usr/local/src
# wget http://sourceforge.net/projects/curl-loader/files/curl-loader/curl-loader-0.56/curl-loader-0.56.tar.bz2/download
# tar jxvf curl-loader-0.56.tar.bz2
# cd curl-loader-0.56
# make
# make install

▼設定ファイルの編集

設定ファイルを用意して複数IPアドレスでlocalhostへ負荷を掛けてみます。

# vi load_test.conf

########### GENERAL SECTION ################################
BATCH_NAME= 10K              # ログと統計情報のファイル名
CLIENTS_NUM_MAX=1000         # クライアントの最大数
CLIENTS_NUM_START=100        # スタート時のクライアント数
CLIENTS_RAMPUP_INC=50        # 追加起動されるクライアント数
INTERFACE   =eth0            # インターフェース
NETMASK=16                   # ネットマスク
IP_ADDR_MIN= 192.168.1.1     # IPアドレス最小値 他ホストへリクエストするときは、自サーバのIPアドレスを記述
IP_ADDR_MAX= 192.168.53.255  # IPアドレス最大値 他ホストへリクエストするときは、自サーバのIPアドレスを記述
CYCLES_NUM= 10               # 繰り返し回数 -1は制限なし
URLS_NUM= 1                  # URLの数

########### URL SECTION ####################################

URL=http://localhost/index.html         # URL
URL_SHORT_NAME="local-index"            #
REQUEST_TYPE=GET                        # リクエストタイプ
TIMER_URL_COMPLETION = 5000             # タイムアウト時間 単位はミリ秒
TIMER_AFTER_URL_SLEEP =20               # 次にリクエストするまでのスリープ時間

▼負荷テスト

※”SUGGESTION”や”WARNING”が出力された場合は”Cntl-C”で実行をストップし、設定を見直してください。
そのまま実行した場合はネットワークの再起動(# /etc/init.d/network restart)が必要になる場合が有ります。

 
負荷テストを開始します。

# curl-loader -f load_test.conf

完了しました。
10K.*という名前の試験結果が書かれたファイルが出来ていますので中を確認してみましょう。

– load_test.log # エラー
– load_test.txt # 時系列の統計
– load_test.ctx # クライアント別の統計
– load_test.ops # オペレーションの統計

 
 
 

httperf

http://www.hpl.hp.com/research/linux/httperf/

httperfは、ヒューレット・パッカード研究所で開発されたコマンドラインで使う負荷テストツールです。
ライセンスはGPLで無料で使えます。

コネクション数・リクエスト数・1コネクションにおけるリクエスト数を指定して実行する事ができます。

 

▼インストール

インストールするOSはCentOS 5.7です。

yumを使ってインストールします
rpmforgeレポジトリがインストールされていない場合は、インストールをする必要があります。

32bit OSの場合

# rpm -Uhv http://apt.sw.be/redhat/el5/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-1.el5.rf.i386.rpm

64bit OSの場合

# rpm -Uhv http://apt.sw.be/redhat/el5/en/x86_64/rpmforge/RPMS/rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm

httperfをインストール。

# yum --enablerepo=rpmforge install httperf

▼負荷テスト

ここで使用しているオプションの意味は↓の通りです。

–server 接続先サーバ
–port ポート番号
–uri URLのパス
–rate 1秒間に生成するコネクション数
–num-conn コネクション数
–num-call コネクションあたりのリクエスト数 (num-conn * num-conn = 総リクエスト数となる)

負荷テストを開始します。

# httperf --server localhost --port 80 --uri /index.html --rate 200 --num-conn 1000 --num-call 2 --timeout 5

完了しました。
結果は↓の様になります。

Total: connections 1000 requests 2000 replies 1000 test-duration 4.996 s

Connection rate: 200.2 conn/s (5.0 ms/conn, <=2 concurrent connections)
Connection time [ms]: min 0.3 avg 0.6 max 7.3 median 0.5 stddev 0.6
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000

Request rate: 400.4 req/s (2.5 ms/req)
Request size [B]: 72.0

Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 0.5 transfer 0.0
Reply size [B]: header 265.0 content 5.0 footer 0.0 (total 270.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.79 system 4.14 (user 15.7% system 82.9% total 98.7%)
Net I/O: 80.9 KB/s (0.7*10^6 bps)

Errors: total 1000 client-timo 0 socket-timo 0 connrefused 0 connreset 1000
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

出力情報の詳細についてはこちらのblogが参考になります。

Na-ga.net
httperf man (OUTPUT)
http://na-ga.net/blog/?p=559

 
 
 

Siege

http://www.joedog.org/siege-home/

SiegeはJeff Fulmerが開発しているコマンドラインで使う負荷テストツールです。
ライセンスはGPLで無料で使えます。
URLを記載したファイルを用意して、複数のURLを同時にリクエストすることができます。

 

▼インストール

# cd /usr/local/src
# wget http://www.joedog.org/pub/siege/siege-latest.tar.gz
# tar xvzf siege-latest.tar.gz
# cd siege-2.72/
# ./configure
# make
# make install

▼負荷テスト

テキストファイルにURLを記述します。

# vi urls.txt

http://localhost/index.html
http://localhost/index1.html
http://localhost/index2.html
http://localhost/index3.html

ここで使用しているオプションの意味は↓の通りです。
--concurrent 同時接続数
--reps コネクションあたりのリクエスト数
--benchmark リクエストとリクエストの間に遅延を入れない
--internet URLのリストからランダムにリクエストを行なう
--file URLを記述したファイル名
--log ログファイル名

負荷テストを開始します。

# /usr/local/bin/siege --concurrent=100 --reps=10 --benchmark --internet --file=urls.txt --log=urls.log

完了しました。
結果は↓の様にコンソールに表示されます。

** SIEGE 2.72
** Preparing 100 concurrent users for battle.
The server is now under siege..      done.

Transactions:                   1000 hits
Availability:                 100.00 %
Elapsed time:                   0.35 secs
Data transferred:               0.07 MB
Response time:                  0.03 secs
Transaction rate:            2857.14 trans/sec
Throughput:                     0.21 MB/sec
Concurrency:                   74.66
Successful transactions:         746
Failed transactions:               0
Longest transaction:            0.26
Shortest transaction:           0.00

FILE: urls.log
You can disable this annoying message by editing
the .siegerc file in your home directory; change
the directive 'show-logfile' to false.

 
 
 

Pylot

http://www.pylot.org/

PylotはCorey Goldbergが開発しているコマンドラインで使う負荷テストツールです。
ライセンスはGPLで無料で使えます。

 

▼インストール

Pylotを実行するにはPython 2.5以上が必要になります。
Pythonをインストールします。

http://www.python.jp/Zope/download/pythoncore

# cd /usr/local/src
# wget http://python.org/ftp/python/2.7.2/Python-2.7.2.tgz
# tar zxvf Python-2.7.2.tgz
# cd Python-2.7.2
# ./configure
# make
# make install

Pylotをインストールします。

# cd /usr/local/src
# wget http://pylt.googlecode.com/files/pylot_1.26.zip
# unzip pylot_1.26.zip
# cd pylot_1.26

 

▼負荷テスト

負荷テストの設定ファイルを書き換えます。
以下の例ではhttp://localhost/post.phpにheaderを付けてappid=Demoとquery=pylotをPOSTします。

# vi testcases.xmlhttp://localhost/post.phpPOST

詳しくは公式ページが参考になります。
http://www.pylot.org/gettingstarted.html

負荷テストを開始します。

# python ./run.py -xtestcases.xml
# /usr/local/bin/python2.7 ./run.py -xtestcases.xml

完了しました。
結果は↓の様にコンソールに表示されます。

-------------------------------------------------
Test parameters:
number of agents: 1
test duration in seconds: 60
rampup in seconds: 0
interval in milliseconds: 0
test case xml: testcases.xml
log messages: False

Started agent 1

All agents running...

[################100%##################] 60s/60s

Requests: 18428
Errors: 0
Avg Response Time: 0.002
Avg Throughput: 306.27
Current Throughput: 288
Bytes Received: 0

-------------------------------------------------

Generating Results...
Generating Graphs...
Matplotlib ImportError: No module named pylab
ERROR: Unable to generate graphs with Matplotlib

Done generating results. You can view your test at:
results/results_2012.02.24_14.14.07/results.html

Done.

結果がhtmlでも書き出されていますので確認してみましょう。

 
 
 

ab - Apache HTTP server benchmarking tool

http://httpd.apache.org/docs/2.2/programs/ab.html

お馴染みApacheに標準でついてくる負荷テストツールです。
Apache Licenseで無償で使えます。

 

▼負荷テスト

ここで使用しているオプションの意味は↓の通りです。
-k keep-alive有効
-c コネクションあたりのリクエスト数
-n 同時接続数

負荷テストを開始します。

# ab -k -c 10 -n 100 http://localhost/

完了しました。
結果は↓の様にコンソールに表示されます。

# ab -k -c 10 -n 100 http://localhost/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient).....done

Server Software:        Apache/2.2.3
Server Hostname:        localhost
Server Port:            80

Document Path:          /
Document Length:        5 bytes

Concurrency Level:      10
Time taken for tests:   0.55488 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Keep-Alive requests:    0
Total transferred:      27000 bytes
HTML transferred:       500 bytes
Requests per second:    1802.19 [#/sec] (mean)
Time per request:       5.549 [ms] (mean)
Time per request:       0.555 [ms] (mean, across all concurrent requests)
Transfer rate:          468.57 [Kbytes/sec] received

Connection Times (ms)
min  mean[+/-sd] median   max
Connect:        0    0   1.3      0       5
Processing:     1    4   1.7      4       8
Waiting:        0    3   1.7      3       7
Total:          1    4   2.0      4       9

Percentage of the requests served within a certain time (ms)
50%      4
66%      6
75%      6
80%      7
90%      7
95%      8
98%      8
99%      9
100%      9 (longest request)

 
 
 

※他社管理サイトへの負荷テストは”刑法第234条-2 電子計算機損壊等業務妨害罪”に問われます。
ドメイン名やIPアドレスの打ち間違えには十分注意しましょう。
 
 

Facebookのウェルカムページ廃止、どのようにしていいね!を増やせば良いのか?

Facebookのウェルカムページ廃止により、どのようにしていいね!を増やせば良いのか?

参考データとしてattripのここ一ヶ月間のFacebookページのいいね!が押された場所について公開してみようと思います。

 

本日は、Facebookのソーシャルウェルカムページについてこのような記事が話題になっています。

Facebookの突然の一撃で、ソーシャルメディアプランナーは全滅か!! | More Access,More Fun!

はっきりいって、なんかプレゼントしたり、配布したり、ケンテイしたり、占いしたりでファンを集めまくる方法は、これで終了となりました。これで食っていた皆様、お疲れ様でした。”

 

確かに、そうなんだけど。

それじゃーそういう事をほとんどやっていないページは、

どうやっていいね!集めているの?

どうしたらいいの。。。。。と唖然としていることでしょう。

 

という事で、attripのデータを元に今後の動向を予測してみようかと思います。

attrip

先月の約一ヶ月間のデータを元に話をしようかと思います。

一ヶ月間で924いいね!ありました。

 

いいね!ボックス経由が802(約87%)がブログなどについている。

Facebook ボックスのライクボタン経由です。

こういうやつですね。

いままでみたいな、ウェルカムページやアプリを使う前にいいね!押してね!って施策みたいに押す場所(なんだかの理由でTOPページを訪問した場合)

98いいね!(約10%)でした。

 

ちなみに3ヶ月前のデータ

どんどんページに直接いいね!を押す人よりも

Facebookボックス経由でのいいね!の割合が増えています。

ちなみに三ヶ月前は、Facebookのいいねボックスでの数字は、66いいね!

ページ上では、53いいね!でした。

(1) attrip

Facebook人口が増加しているのもあるとおもいますが、

ブログなどに配置したFacbookのボックスがどんどん重要になっていくる気がします。

理由は、ブログのほうがシェアしやすく、幅広い人にいいね!ボックスを押してもらいやすいからです。

もちろんお金があれば、広告で呼び寄せる方が簡単だし、人数も増えると思いますが、面白い記事、共感できる記事を書くことで、ブログ経由でなどでいいね!を押してもらうのが、効率的だと思ういます。