メイン

2010年7月30日

エンジニアが買い物をするために
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

OSIの参照モデル、って知ってますか?
ハジメマシテ、低レベルエンジニアのnsatohです。

そうそう、あの「Layerほげがフガだから、」とかスーツ来たIT系がよく言うキーワードのアレです。
でも、インターネット的な、ゲームとかアプリケーションとかを提供するには、たしかにOSI参照モデルを知っていると前提しての会話が楽なので、知らなかった人は是非、知っておいてください。いわゆるバズワードです。

で、OSI参照モデルにはLayer1からLayer7が定義されていますが、まことしやかに「あれって10階層じゃね?」と、言われること幾久しくです。

Layer0の土建層、Layer8の金銭層、Layer9の政治層とかとか、バグフィックスがハゲシクメンドくちゃいけれど、あきらめましょう的なものがあります。あとはLayer10に宗教層、いわゆるエンジェリック・レイヤーを入れる向きもありますが、ともかく、OSI参照モデル本来の7層以外は、意思とか趣向が大きく影響します。

で、その辺をふまえて、僕は一応、「低レイヤーの技術者です。」と名乗ります。

どの辺が僕の守備範囲かといえば、Layer0からLayer4辺りです。
でも、ウノウはAS持ってるわけでもないですし、特別なネットワークを構成しているわけでもないので、なんていうか、社内では一匹狼(と書いて、Bocchi と読む)です。
でも、低レイヤーのシゴトばかりしていると、どうしても、Layer4、5、6、7、8と手を出さないと立ち行かなくなるので、手を出します。
そうこうしているうちに、気がついたらなんとなく購買的な立ち位置のような雰囲気が出てきたりするのも良くある事。
「エンジニアの肩書きなのに彼って打合せかメールばかりだよねー」
「メールと打合せでシゴトしたふりしてていいのは小学生までだよねー、キャハハ」
と、すっかり社内的にも昼行灯と思われがちな僕の保身のためにも、サーバとかデータセンタとか、そういうのを買うときのあれこれなんかを、まぁ夏の小話程度でいいので聞いてくれると助かります。

購買、っていう作業
わりと定型。で、わりと不定形。
フツーの会社だったら当然やってるんじゃね?と思う感じの手順を並べます。

1、雰囲気作り
2、見積もり
3、お伺いをたてる
4、買う!
5、届く。
6、事後処理

まぁ、当たり前の手順ですよね。

1、雰囲気作り
いきなり「俺はサーバ500台、買う!」って言っても、"まぁもちつけ。"と言われて終わりです。あなたの中にある、"それを買うべき理由"を会社に伝染させましょう。
A4ペラ1枚でいいですから、
・目的はなにか。あなたはなにがしたいのか。
・目的のために、どんなものが必要なのか。
・あなたが欲しいものは、それをみたすのに最適なものなのか。
・あなたがが欲しいそれ以外で、目的を達成する方法を無理矢理考える。
の4つを書きましょう。
いやぁ、これを書くと、実は「他のモノの買った方がいいんじゃね?」となるんだわ、大抵の場合。

 ん?めんどくさい? だよねー、書面書くとか、めんどくさいよねー。

けれど、あなたが今、買おうとしているモノの代金は、あなたが給料をもらう会社の、同じおサイフから出てるんですよ?隣にいる同僚の、その家族をたち養うためにも使われる同じおサイフのお金なんですよ?それをめんどくさいなんて!まったくあなたはひどい人ですね、マジでソンK〜。
とか、そういうことですのよね、つまるところ。
ですので、あなたがほしいそれを買うことが、「みんなの幸せに繋がるんだ!」と、そういう雰囲気を作る事はとても重要なオシゴトです。


2、見積もり
ここで購入金額が決まります。なのでガンバろう!
ここでいくつかTIPSがあって、

・営業さんと仲良くやろう
・見積もりは3カ所からとうろう
・決定権はあなたにはない!と自覚しよう。
・見えない金額に気をつけろ!

この4つは、きっと重要。じゃないかなー、とか思ったり。


おやくそく1:営業さんと仲良くやろう!
僕もそうですが、技術者は友達が少ない(偏見ですネ)ので、他人と関わるよりちゃっちゃとWebで値段だけ、見積もったりします。
で、絶対時間的にはそっちが早く見積もれたりする、とか思ってますよね。

いや、それはシゴトできない人のダメな考えです。

僕ならざっくりとした要件だけ伝えて、最後に「で、納期と金額を見積もっていただけますか。」と。

だいたい、要件すら他人に伝えられないって、自分が欲しいものが自分でもわかってないってことだよねぇ?そんなんで買い物しちゃ、あかん!それはお金を捨ててるのと一緒だと、自覚するべきだよ。

で、営業の人ががんばって見積ってくれてる間、僕は別な仕事してます。
そもそも、それぞれのメーカ別の商品の詳細仕様とか、あなたには不要です、まったく不要です。そんな細かい話は忘れて、あなたはもっと応用の効く知識を、そうですね、ARPとL2スイッチの学習とか、ルーティングとMATとロードバランサでのパケット加工とか、分散KVSとコンシステントハッシュ、あるいは購買が好きなら各メーカの製品ラインアップがどんな方針で区分けされてるのか、とかそんなことを知っているほうが重要です。
なので、細かい構成とか金額算出とか営業さんに任せて、見積書が出来るまで別なことをするのが出来るSE!ってヤツです。

おやくそく2:見積もりは3カ所からとろう!
複数から見積もりをとると安くなる、というよりは、ボられずに済む、という感じです。
全く同じものがターゲットだったとしても、メーカ直販以外の、日商とか丸紅とか立花エレとかダイワボウとかetc、と、なんでも扱える商社を通して見積もってみましょう。
で、どこから見積もっても同じような値段だったら、それはその価格が適正なんです。

複数から見積もりをお願いするときの商品名指定は善し悪しです。品名指定したら値引き合戦しか出来ませんから、僕は「こんな感じで、こんな仕様の...」と要件を伝えるようにしています。
だいたい商品知識は営業さんに負けるのが基本ですから、彼らの知識を借りましょう。シゴトなんて他人の力を借りなきゃなんもできんのです、特にIT系。
要件で指定して見積もると、ともすれば品名指定では検討すら出来なかった上位バージョンが、うっかり予算内で手にはいったりします。
まれに、ですがキャンセル品とか、決算月とか、事業部のノルマ、とかでうっかり(以下自粛
なんていうか、ぶっちゃけ、日 本 の 商 社 最 強 !
メーカと商社は持ちつ持たれつなので、(以下自粛
信頼関係が良好ならば、納期とか金額とか取引条件とか、いろいろと融通が聞くのが営業経由での購入のいいところです。具体例は言えませんけど、強烈な提案とかまぁ、ありますよ。

たぶん、なじみの営業さんとかできると、それは転職してもお付き合いできるあなたの資産の一つになっているはずです。
たぶんここを見ているエンジニアって、どこにいったって結局サーバとかデータセンタとか使うんだよねぇ?

おやくそく3:決定権はあなたにはない!と自覚しよう。
あと購入の決定権はいつだって上司のもので、自分は上司に「これかったらいいと思います。」と畏込み申し奉るだけの民草にすぎない、と自覚すべきです。
押しの強い営業トークとかは「いやぁ、でも僕は上申するだけですから...」で逃げたりしましょう。これは緩い「お断り」の意味です。それでも食い下がってきたときはそこから買わない方がいいです、経験上。
あとは「いついつまでなら安いんです!」も悩み深いところ。ほんとに善意でそういってくれる営業さんもいるのですが、単に早く決めてほしいから、ってだけの人もいて、ここは空気を読む能力を磨いてください。ちなみに僕は期限切ってきたらほぼ買わない(笑

また、リースやレンタルっていうファイナンスの仕組みについても、最低限の知識はもっていたほうがいいです。いや僕も全然しらないんで、自戒の意味で書いてますが。
金額が100万超えそうなときは購入が現金かリースか別な方法か、上司に相談してみましょう。
このとき一緒にリースならリース条件なんかも確認出来るならしておきましょう。おつきあいのあるリース会社があればそこに、そうでないなら営業さんに相談してみてください。ファイナンス会社を紹介してくれます。
見積もり金額は普通はリースも現金も変わる事はありませんが、リース会社の利益がそこにのりますので、あなたの会社の総支払い額はけっこう上がります。

おやくそく4:見えない金額に気をつけろ!
また書面には明記されてない金額、というのにも気を配った方がいいです。
消費税はもちろんですが、送料も馬鹿になりません。リースやレンタルの購入であればその利率も気にしてください。
同じ値段のサーバでも片方はセットアップ済み、もう片方はOS未導入、とかなると、OS導入の人件費であっという間にトータルの費用に差が出ます。
あなたはあなたが思う以上に、高い費用が発生しているのです!
ふつー、1人の人間をどっかの会社で使うとしたら、100万/月ってのはぶっちゃけ劇安です。100万の中からオフィス代、電気代、交通費、パソコン代、etcって考えたら給料に出せるのがいくらか、精々30万でしょう。人間が一番高い!ってのは概ね、正しいのです。

あー、あれだ、ケータイ買うときの充電器が!登録料が!っていうアレ、アレの感覚で居ればいいんじゃね? なんていうか想定外の出費って意味で。

で、見積もりが来たら内容をちゃんと確認しましょう。
僕も以前、全部で3千万のシステムを購入するのに、400万のロードバランサーが2セット入っていて、購入してから途方に暮れたことがあります。このときもそうですが、2台でActive/Standbyクラスタをくむとき、2台と2セットで間違うとか、良くあるんです。
まー、別件に使って元はとったけどネ!!

3、お伺いをたてる
さて見積もりも2つか3つ、手元に出来た!さぁ一番安いのを買うぞ!ってそれはちょっとマテ。
ほんとにそれは安いの?ってのは重要な事です。
書面にない金額の発生は、どうせあるので、総額を概算するのはあなたの仕事です。1割程度は高くなると思っておく方がいいよ。
納期は大丈夫ですか?
1年後にチロルチョコ100個届けてやるから、今日500円振り込めよ!って詐欺だよねぇ?
海外からの輸入品は船便なら納品が二ヶ月三ヶ月は当たり前です。
この辺の国内在庫を見極めたりも、営業さんときちんと関係が出来てれば見積もりの時点で解決出来ている問題になってたりするのです。こんなのまでいちいち自分で市場在庫(ってか扱ってる通販サイトで在庫ありを探す)を探すとか、時間の無駄だし、蛇の道は蛇なのですよ、こういうのは。
納期も鑑み、値段も鑑み、性能もOKだとなったら、会社に「これ、こうてくれやぁー!」と稟議を申請します。きっとあなたは一番安い見積もりではない別な見積もり書で「こっちをこうてくれやー!」と言っている事でしょう。

4、買う!
実際に買う! って実はあんまり楽しくないです。
見積もり書を会社に示したあと、そっからさきはただただ面倒な書類の作成が続くのです。
売買契約書はもちろんですが、銀行振込のための書類やら、注文書やら、リースとかを使うとなればリース申し込み書もそうですし、購入する機械によってはNDAも必要になったりします。これらの書類に会社のハンコをもらわないとイケマセン。
いやぁハンコ無しでも発効しちゃったりするんですが、けど、ハンコもらっとけば「たしかに会社の判断じゃんか!」と勝手にあなたが行った事じゃないですよ、と体面がたちます。
だいたい、現金で買う訳はないですし、ただ数字だけが口座間を移動する、それだけのための書類なのです。

なんかこー、買う段になってくると、もうね、なんていうか、飽きちゃってる感じ。
何が出来るもので値段いくらでオプションがこうで、とかとか詳細に知りすぎてて、内心、次のシゴトに浮気し始める頃。

購入手続きで最悪なのは携帯電話。
同一機種のまとめ買いならともかく、検証用にばらばらに買うと申し込み書を書くのに1日仕事。
「手が、手がー!」あるいは「ふはは、書き損じがゴミのようだ!」(いや、ゴミですが、実際)となります。
犯罪に悪用されるのを防ぐためとはいえ、いろいろと面倒です。

あと、忘れちゃ行けないのはファイナンス。
これの事務手続は社の信用によってはいろいろとあると思います。

5、届く
モノが届きます。届きますが正直、めんどくさいです。
段ボールの処分だってタダじゃないんです、企業が出すゴミは産業廃棄物です。ふつーの清掃工場じゃ引き取ってくれません。お金払って処理してもらうんですよ?
まぁ値段交渉中に「段ボールの処分はお願いしますねー」とか、僕は言っちゃいますが諸刃の剣、素人にはおすすめできない。それは今までの取引の経緯があればこそ。ふつーは「産廃業者のお見積りもできますよ」と返されます。
100余台、30kgの物体を開梱して、内容確認して、まぁ2日くらいかかりますね!

ぶっちゃけ、購買ずっとやってると、見積もり完了したあたりで大満足。届く頃には購入対象物にもう飽きがきちゃってるとかが基本。なんていうか、感動とか、無い。この仕事で一番困るのは、「モノを買っても感動しなくなる。」

あと、同じものを個人で買うと割高なことを知ってしまう事、とかかな...
携帯電話とかもうね、ずっとP504だったもの...。

で、ここ3ヶ月で携帯電話を40回線買った僕が今使ってるのはxperia。だって、ほら、ねぇ?(笑

6、事後処理
この事後処理はわりと忘れてしまいがちです。
検品書、ってやつがくるので検品が済んでいるなら、会社ハンコを押して返送してあげましょう。
納品書、領収書は経理か総務か、それっぽい部署の人に渡しましょう。
領収書や納品書はふつうの会社組織ならとても重要な書類のはずです。
でも、納品された現物にどうしても気が取られますので、うっかり捨ててしまったり、しがちです。でも再発行してもらえない書類です。
段ボールについてる納品書とか、開梱作業をヘルプしてくれた人にちゃーんと説明しておかないと、まぁ、ほぼ捨てられるね!

事後処理で事務処理が続くと、ほんと経理とか総務とか「スゲー!」って感動する。だって彼ら、日々この事務処理やってるんだよ?同じ事、出来る??とか思うと、なんていうか、バックオフィス様に足を向けては寝れないよね。

と、当たり前の話を書いてみました。
でも、きっと、事務方のみなさんからすれば邪道な買い物だ!とか言われそうで怖いですが、まぁ、そんな感じで。

最後に
「 〜前略〜はみんなイチコロさ。ハッタリかまして、ブラジャーからミサイルまで、何でもそろえてみせるぜ。」

2009年1月14日

シェルの仕組み(後編)
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

ウノウでは特に最近、積極的にエンジニアを採用しています。 採用ページをご覧になり興味のある方、ぜひご応募ください!!

尾藤正人(a.k.a BTO)です

前回の勉強会でシェルの仕組み(前編)というのをやりましたが、今回はその後編をやりました。
前編と合わせて見ていただくと、シェル内部で使われている仕組みが一通り分かるようになるかと思います。

資料及び動画を公開しますので、もしよろしければご覧ください。

Shell 2

Live Broadcast by Ustream.TV

今回はちゃんと忘れずに動画を保存しました!

2008年9月 9日

見ないと損する ソフトウェアテスト関連サイト色々
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

こんにちは!やまもと@テスト番長です。

今回は自分が普段チェックしている、ソフトウェアテスト系のサイトを色々ご紹介してみようと思います。既にご存知のサイトもあるかと思いますが、宜しくお付き合いください。

swtest.jp/wiki
http://www.swtest.jp/wiki/index.php?swtest.jp/wiki

最近wiki化され、情報更新が活発になっています。必見です。


StickyMinds.com
http://www.stickyminds.com/

コラムなどの読み物が充実しています。


Google Testing Blog
http://googletesting.blogspot.com/

グーグルのテストチームのブログです。面白くないはずがありません。


Open source software testing tools
http://www.opensourcetesting.org/

その名の通り、オープンソースのテストツール情報サイトです。
積極的に更新されています。


Testing Experience - The Magazine for Professional Testers
http://www.testingexperience.com/

PDF形式のWEBマガジンです。お洒落なので一度ダウンロードしてみてください。


その他にも幾つかチェックしているサイトがありますが、長くなりますので続きはこちらにまとめておきました。どうぞご覧ください↓

TestBancho's clipp
http://testbancho.clipp.in/

というわけで公開中のソーシャル・スクラップブック「clipp」をどうぞ宜しくお願いいたします。
と宣伝風に締めくくらせていただきます。

他にもいいサイトをご存知の方はぜひ教えてください!


2008年7月15日

TCP/IP入門
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

尾藤正人(a.k.a BTO)です

このブログを読んでる方にはWebプログラマが多いかと思いますが、Webの仕組みを基礎から理解してプログラムは書いてますでしょうか。
もちろんそんなことは知らなくても抽象化されてるので気にする必要は全然ないのですが、やはりエンジニアとしてはちゃんとどういうものか理解してプログラムを書いた方がよりよいプログラムが書けると思います。

そこで先日の社内勉強会で、TCP/IPについて軽くおさらいしてみました。
かくいう僕もTCP/IPについて勉強したのは7, 8年前だったのでいろいろ復習してたんですが、忘れていたり、実はちゃんと理解できてなかったことがありました。

せっかくなので資料を公開しておきます。
よかったら参考にしていただければと思います。

Read this document on Scribd: tcpip

TCP/IPの勉強にはマスタリングTCP/IP 入門編がおすすめです。

マスタリングTCP/IP 入門編 第4版
竹下 隆史 村山 公保 荒井 透 苅田 幸雄
オーム社
売り上げランキング: 1104
おすすめ度の平均: 5.0
5 まとめ方はうまい
5 ネットワークの基礎を学ぶ上での教科書
4 辞書としてはかなり有用
5 第3版との異同
5 TCP/IPのバイブル

2008年5月 1日

コマンドラインから使うBitTorrentクライアント
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

yukiです。

唐突ですが、BitTorrentクライアントは何をお使いでしょうか?これまで私はずっとBitComet を使ってきましたが、私の非力な自宅マシンだとどうしても負荷が高く、その間は何も出来ないような状態に陥っていました。GUIから使おうとすると、見やすさや使いやすさはさすがに良いのですが、あまりの負荷とその間何も出来ない状況はあまりよろしくないと考え、今回はUNIX系でCLIから操作できるクライアントはないだろうか、と探していて見つかったEnhanced CTorrentをご紹介することにします。

Enhanced CTorrentは、C++で書かれたCtorrentをベースにしたBitTorrentクライアントです。Ctorrentからバグフィックスや改良・軽量化を重ねており、現在のバージョンは3.3.1になっています。

Enhanced Ctorrentは現在はSorceforgeでバグレポートやダウンロードができますので、早速使ってみました。

インストール

インストールは非常に簡単で、普通にwgetで落としてきて展開し、configureしてmake installします。

% wget http://jaist.dl.sourceforge.net/sourceforge/dtorrent/ctorrent-dnh3.3.1.tar.gz
% tar zxvf ctorrent-dnh3.3.1.tar.gz
% cd ctorrent-dnh3.3.1
% ./configure
% make
% sudo make install

torrentファイルからダウンロードする

早速torrentファイルをダウンロードして、ダウンロードしてみましょう。 やり方は非常に簡単で、これだけです。

ctorrent [torrent.file]

これだけで同じディレクトリ内にダウンロードが開始されます。
注意点としては、デフォルトだと2706-2106番ポートを使うようになっていますが、オプションでポートを指定することが出来ます。とても簡単なうえ、デーモンとして起動することも出来ますのでバックグラウンドで動作させたい場合にも非常に便利です。

2008年4月24日

rpmパッケージを作ろう
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

尾藤正人(a.k.a BTO)です

先日社内勉強会でrpmパッケージの作り方についてやってみました。
資料を公開しておくのでよろしければご参照ください。

Read this doc on Scribd: rpm

参考用に以前GNU Autotools用のサンプルプログラムで作ったbatのrpmパッケージを使いました。
次のようなコマンドでrpmパッケージを作成できます。
基本的な機能をある程度網羅したつもりなので、参考になれば幸いです。

rpmbuild -ta bat-0.0.3.tar.gz

bat-0.0.3.tar.gz

2008年4月 7日

LD_PRELOADを使って任意の関数呼び出しにフックしてみる
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

尾藤正人(a.k.a BTO)です

先日の社内勉強会のLTでLD_PRELOADについて簡単にやってみました。

LD_PRELOADって?

環境変数$LD_PRELOADを使うと他のライブラリの読み込みの前に任意のライブラリを先に読み込ませることができます。
実行プログラムの形式にELF形式を採用しているOSで使うことができます。
Linuxであれば問題なく使用できるはずです。

何ができるのか

プログラムを変更することなく、任意の関数を上書きしたり、任意の関数にフックすることができます。

libhookwriteを作ってみた

簡単なサンプルプログラムとしてlibhookwriteというのを作ってみました。
libhookwriteはその名の通りwrite(2)にフックをかけることができます。
といってもできることは限られていてファイルのタイムスタンプの更新か、任意のプログラムをsh経由で実行することしかできません。

ダウンロード

libhookwrite-0.0.1.tar.gz

インストール

お約束通り

tar zxvf libhookwrite-0.0.1.tar.gz
cd libhookwrite-0.0.1
./configure
make
sudo make install

rpmでもいけます。

rpmbuild -ta libhookwrite-0.0.1.tar.gz
sudo rpm -ivh libhookwrite-0.0.1-1.i386.rpm

使い方

環境変数$LD_PRELOADにlibhookwrite.soを指定します。
さらに環境変数$HOOKWRITE_UPDATE_FILEか$HOOKWRITE_COMMANDを指定します。

HOOKWRITE_UPDATE_FILEにファイル名を指定すると、write(2)が呼ばれたときに指定されたファイルのタイムスタンプを現在時刻に更新します。

HOOKWRITE_COMMANDに任意のコマンドを指定すると、write(2)が呼ばれたときに指定されたコマンドを/bin/sh経由で実行します。

例えば、次のようなシェルスクリプトcat.shを実行すると、write(2)が呼ばれた時点で$HOME/tmp/catというファイルのタイムスタンプを現在の時刻に更新して、"hoge"と出力します。

#!/bin/sh
HOOKWRITE_UPDATE_FILE=$HOME/tmp/cat ¥
  HOOKWRITE_COMMAND='echo hoge' ¥
  LD_PRELOAD=/usr/lib/libhookwrite.so ¥
  /bin/cat $@

使い道

例えばエディタがファイルを保存したときに、何らかのアクションを起こしたい場合に使えるかもしれません。
プログラムに依存しないので、vimだろうがemacsだろうが何でもいけるはず。
ただ、スワップファイルの書き出しにも反応してしまいますが。(^^;

vimを使ってsymfonyプロジェクトの開発をやってて、ファイルを保存したい瞬間にsymfony ccを走らせてキャッシュクリアしたい場合はこんな感じのaliasを作ればいいでしょうか。

alias vim="LD_PRELOAD=/usr/lib/libhookwrite.so HOOKWRITE_COMMAND='/symfony/project/symfony cc' /usr/bin/vim"

プログラム

プログラム自体は非常に簡単です。

static ssize_t (*write_org) (int fd, const void *buf, size_t count) = NULL;

write(2)と同じプロトタイプ宣言を持つ関数ポインタwrite_orgを定義しています。
オリジナルのwriteを保存するのに使います。

__attribute__((constructor))
void
_save_original_functions()
{
    write_org = (ssize_t(*)(int, const void *, size_t)) dlsym(RTLD_NEXT, "write");
}

dlsym(3)を使ってwriteのアドレスを取り出して、write_orgに保存しています。
__attribute__((constructor))というのはgccの拡張になってて、これを指定しておくとmain関数が呼ばれる前に実行してくれます。

後は単純にwrite関数を改めて定義して、その中に任意の処理を書いておきます。
最後に return write_org(fd, buf, count);でオリジナルの処理を呼び出して終わりです。

参考

man ld.soでマニュアルが読めます。
LD_PRELOADの他にもいろいろな機能がありますので、一度読んでおくといいかもしれません。

fakechroot

LD_PRELOADを使った面白いソフトウェアでfakechrootというのがあります。
chroot(2)の実行にはroot権限が必要ですが、fakechrootでは擬似的に一般ユーザ権限でchrootを実現しています。
LD_PRELOADを使って、ファイル操作に関わる部分にすべてフックをかけて擬似的にchroot環境を提供しているんでしょうね。

Mac OS Xだと

実行プログラムの形式がELFではなくMach-Oが採用されています。
なので、LD_PRELOADは使えないはず。
代わりにDYLD_INSERT_LIBRARIESというのが使えます。

man dyld

詳しく検証してないので、詳細はよくわかってません。

まとめ

LD_PRELOADを使うとプログラムに直接手を加えることなく、外から挙動をコントロールすることができます。
応用範囲は無限大です。

2007年12月21日

なんて読むのかわからない
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

尾藤正人(a.k.a BTO)です

韓国大統領選挙に出馬するのを忘れていたと思っていたら、 いつの間にかmixi新CTOにノミネートされてた今日この頃、 みなさんいかがお過ごしでしょうか。 今日はちょっと趣向を変えて、ライトな感じのエントリでいこうかと思います。

ITエンジニアに英語が苦手な方が多いかと思います。 僕も英語が大の苦手で、英語に対してコンプレックスを持つ者の一人です。 そんな僕ですが、なんとか簡単な会話を英語でこなすことができるようになりました。 僕の英語の学習の課程は、以前のエントリ 「海外経験のない典型的理系人間が日常会話レベルの英語を話せるようになるまでの道のり」 で紹介したので、よかったら参照してください。

英語に限らず、IT業界にいると読み方のよく分からない単語が出てきます。 妙に省略された単語だと読み方がさっぱり分からない事がありますが、 通常の英単語であれば辞書の発音記号を見ればなんとなくわかります。 が、そこは英語苦手の多いIT業界。 勘違いやローマ字読みなどで一風変わった読み方に出会う事も少なくありません。

そこで今回は、読み方のよく分からない単語や、 面白い勘違いの読み方がある単語を大募集します。 コメント、TB、はてブなどで読み方のよく分からない単語をぜひ教えてください!!

参考までに僕の方でいくつかあげておきます。

alt - オルト

僕はいつも「オルト」と呼んでますが、 ローマ字読みで「アルト」と発音する方が多いようです。 「alternative - オルタナティブ」からきてるので、 「オルト」と呼ぶのが近いと思ってますがどうなんでしょうか。

warning - ウォーニング

やっぱりこれもローマ字発音で「ワーニング」と呼ぶ方が多いです。

fatal - フェイタル

ローマ字読みで「ファタル」というのを聞いた事があります。

allow - アラウ

(ry

prepare - プリペア

(ry

require - リクワイア

読み方知らない方が以外に多くいます。

MySQL - マイシクー

日本だと「マイエスキューエル」じゃないと逆に通じないでしょうか。

PEAR - ペア

PHPのライブラリを集めたアーカイブ群

CPAN - シーパン

「クーパン」ですか? もう分からない、助けて

参考

新版 UNIX 由来/読み方辞書が非常によくまとまってて面白いです。 これを読むだけでかなり解決するかと思われます。 ぜひ一読をおすすめします。

abbreviationとacronym

最後にちょっとしたトリビア。 IT用語には省略語が多いですが、省略語にはabbreviationとacronymの2種類があります。 acronymはそれを単語のように発音する省略語で、abbreviationはそうじゃないやつ。 なので、SCSI(スカジー)はacronymになりますが、USB(ユーエスビー)はabbreviationになります。

2007年12月 3日

ソフトウェア開発におけるハリー・ポッターは?
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

こんにちは! やまもと@テスト番長です。

前回のエントリでご案内したQA勉強会を先日無事開催致しました。
集まってくださった皆様と非常に有意義な時間を過ごす事が出来ました。ありがとうございました。
またいずれ何かしら出来ればと思っておりますので、その際は宜しくお願い致します。

さて、今日は面白い小話を見つけましたので、ご紹介したいと思います。
ITコンサルタントの草分け、「オレンジジューステスト」の話でも有名な、ジェラルド.M.ワインバーグ氏へのインタビューです。

Interview with Jerry Weinberg
http://www.citerus.se/kunskap/pnehm/pnehmartiklar/interviewwithjerryweinberg.5.484cc23b1165f30e75680002483.html

インタビューの後半は品質の問題について話が進んでいくのですが、
一番最後の質問にこうありました。

Q:もしあなたがソフトウェア開発におけるJ.K Rowlingだとしたら、誰をハリー・ポッターにしますか?

A: ええと、私は(J.K Rowlingのような)億万長者ではないので適切かどうか分かりませんが、ハリーは、魔法を使えるのにも関わらず「彼はただのテスターだから」と値切られるテストマネージャーにするでしょう。
ヴォルデモートは、「いいえ」と言うことが出来ないか、ハリーのいうことを聞かないプロジェクトマネージャーたちだと思います。


流石の表現力です。自分も「魔法」を身に付けたいと切実に思いますが、この例えでいくとホグワーツはどこになるのでしょうね。

2007年10月10日

Wikiのプラグイン記法を実装する
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

bokkoです。

普段からWikiを使っていると、「○○する記法がほしいなあ」と思うことがあると思います。
しかし、単純に記法を追加しようとすると、ほかの記法とぶつかってしまったり、思わぬ副作用を引き起こす可能性があるため、大抵のWikiクローンには独自でプラグインを作るための仕組みがあります。
例えば、どこかにplugin_nameというスクリプトファイルを用意し、{{plugin_name 引数}}と書かれた部分をそのスクリプトファイルを実行した結果に置き換える、という風に。

というわけで、今日は私がローカルで使っているオレオレWikiクローンでのプラグイン機構の実装例を紹介しようと思います。実現するためのコードは以下のようになっています。(ほかの機能のためのコードが混ざってしまっていてちょっと見づらいですが)

private function createPlugin(){
    $dir = Config::GetPluginDir().'/';
    $hd = null;
    $file = null;
    $str = 'if($hd = opendir($dir)){
                  while(false !== $file = readdir($hd)){
                      if($file === \\\'\\2.php\\\'){
                          require_once($dir.$file);
                      }
                  }
              }
              if(function_exists(plugin_\\2)) return \\\'\\1\\\'.plugin_\\2(\\\'\\3\\\', $this->plugined_file).\\\'\\4\\\';
              else return \\\'Not Found!\\4\\\';';
    // 引数なし 例:{{lastupdate}}
    $this->text = preg_replace("/([^<])\{\{([^\{ ]*)()\}\}([^>])/e",
                                          "eval('$str')",
                                          $this->text);
     // 引数あり 例:{{strlen abc}}
     $this->text = preg_replace("/([^<])\{\{([^\{]*)\s([^\{]*)\}\}([^>])/e",
                                           "eval('$str')",
                                           $this->text);
} 

まず、テキストの中{{plugin_name}}、または{{plugin_name 引数}}というのがあれば、その中身をevalに放り込みます。その後、plugin_nameの部分に該当するファイル名と関数名があれば、その関数を実行し、結果を返します。ファイルや関数が存在しない場合は、「Not Found!」という文字列を返します。(実際に実用的なプラグインの仕組みを作る場合はもっと厳密な決まりが必要だと思います)

時刻を取得する場合は、以下のようなコードになります。

function plugin_lastUpdate($arg, $file){
    return date("Y/m/d H:i:s");
}

2007年9月25日

Rubyでネットワークサーバを書く
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

尾藤正人(a.k.a BTO)です

先日公開したブラウザだけでネットワーク対戦ゲームができるサイト「プラッシュ」では、 フラッシュとネットワーク通信を行う専用のXMLSocketサーバを開発しました。 このXMLSocketサーバはrubyで書かれています。 LLでデーモンを書く需要が、それほどあるとは思えませんが、デーモンを書く際に気をつけた点、工夫した点をまとめてみたいと思います。

なぜrubyを選んだのか

rubyを選んだのには理由は2つあります。

  • Railsを採用した
  • LLで早く開発をしたかった

僕も昨今のRailsブームにのって個人的にRailsを使い始めていました。 プラッシュは完全に新規プロジェクトで環境を選択する事ができたので、迷わずRailsを選択しました。

では、なぜCのようなコンパイル言語で書かなかったのか。 速く動くものを開発するよりも、早く開発をしたかったからです。 Webサービスにとって開発スピードは最も重要な項目の1つです。 最初から速いものを作る必要はありません。早く市場に出さないとうまくいくかどうかもわかりません。 速くするのは後からでも全然構わないのです。

デーモンになる

デーモンになるために必要なのは次の4つです。

  • fork -> setsid -> fork
  • ルートディレクトリに移動する
  • umask をクリアする
  • 標準入出力、標準エラー出力を /dev/null に向ける

僕は次のようなメソッドを定義して実行してます。

def daemonize
  exit! 0 if fork
  Process::setsid
  exit! 0 if fork
  Dir::chdir('/')
  File::umask(0)
  STDIN.reopen  '/dev/null', 'r' 
  STDOUT.reopen '/dev/null', 'w' 
  STDERR.reopen '/dev/null', 'w' 
end

デーモンについては以前勉強会やった内容を公開していますので、よかったらそちらをご覧下さい。 UNIXデーモンを作ろう

全てのエラーを補足する(堅牢性)

デーモンはバックグランドで24時間動き続けないといけません。 デーモンが落ちてしまうと全くサービスが継続できなくなってしまいますから、多少のエラーが発生しても大丈夫なように作らないといけません。 幸いな事にrubyの場合は、ruby自体が落ちてしまわない限り、あらゆるエラーを補足することができますので、上位のところで全てのエラーを補足するようにするだけで問題ありません。

メモリリークに気をつける

Webアプリのプログラムのように短時間で処理が終了してしまうものは、メモリリークを気にする必要などほとんどありませんが、 デーモンのように24時間動き続けるようなシステムでメモリリークがあると、 最初は調子よく動いていても長い間実行するとメモリをたくさん消費して大変な事になってしまいます。 といってもrubyの場合はruby側でメモリ管理をしてくれるのでメモリリークする心配はあまりありません。

スコープ内にあるローカル変数はスコープから抜けたら勝手にrubyのGCが開放してくれるので気にする必要はありません。 気をつけないといけないのは永続的に使用しているオブジェクトになります。 永続的に使用しているオブジェクトに必要ないものが出てきたら忘れずに、Array#delete、Hash#deleteを呼ぶか、nilを代入するなどして、 rubyのGCが開放できるような状態にしてやる必要があります。

LLのGCのアルゴリズムに参照カウンタを採用しているものがありますが(php, perl, python)、GCのアルゴリズムが参照カウンタの場合、 循環参照のオブジェクトの開放ができなくてメモリリークになってしまう問題があります。 rubyのGCのアルゴリズムはmark-sweepになってるそうなので、この点は安心できます。 pythonは参照カウンタですが、循環参照のオブジェクトを開放する機構があるそうです。

IOを多重化する

ネットワークサーバは(inetdのようなものを使わない限り)複数コネクションを扱えないといけません。 通常ネットワークサーバが複数プロセスを扱う時は1コネクションに対して、 1プロセス or 1スレッドを生成するマルチプロセス/スレッドモデルで処理をするのが一般的です。

rubyで実装するので、プロセスモデルでコネクションをさばくには処理速度やリソース消費の観点から懸念がありました。 実際に試してないのでもしかしたら余計な心配だったのかもしれませんが。 スレッドモデルも考えたのですが、 rubyのスレッドはネイティブスレッドではなくruby自身が持っているもので、 複数コネクションをさばくにはお話にならないくらいコンテキストスイッチの速度が遅くて使い物になりませんでした。

そこでIO#selectを使ってIOを多重化することにしました。 それぞれ単純な役割を持った4つのスレッド「コネクションをacceptする」「ソケットから入力を読み取りキューに登録する」「接続が切れたコネクションを開放する」「キューから命令を取り出して実行する」で処理を行うようにしました。 次のようなプログラムで処理しています。

def main
  server = TCPServer.new(@port)

  Thread.fork {
    while true
      begin
        add_connection(server.accept)
      rescue Exception => error
        logger.fatal error
      end
    end
  }

  Thread.fork {
    while true
      begin
        read_instructions
      rescue Exception => error
        logger.fatal error
      end
    end
  }

  Thread.fork {
    while true
      begin
        manage_connection
      rescue Exception => error
        logger.fatal error
      end
    end
  }

  while true
    begin
      dispatch
    rescue Interrupt
      break
    rescue Exception => error
      logger.fatal error
    end
  end
rescue Exception => error
  logger.fatal error
  exit(1)
end

このように生成されるスレッドを限定する事でコンテキストスイッチの遅さは問題なくなります。 IOを多重化することでコネクションが増えても、1ソケット分のオブジェクトが増えるだけになり、 コネクションが増えてもそんなに負荷が上がらないような構造になっていると思います。

とはいえ、この方式にもいくつか問題点はあります。 1つは命令実行スレッドが命令をシーケンシャルに実行するので、1つ重い処理があると他の命令が実行されなくなってしまうので、 全体の処理に影響を与えてしまうことです。 これに関しては命令実行スレッドを増やしたり、命令に実行優先順位をつけるなどして対処することができると考えています。

もう一つはマルチコアのCPUで1つのコアしか活用できない点です。 rubyのスレッドはネイティブスレッドではないので、OSから見るとただの1プロセスにしか見えません。 なので、せっかくマルチコアのCPUを搭載していても1つのコアしか使用する事ができません。 これに関しては複数プロセスで動作できるようにしたり、少し作り込みが必要になってきます。

まとめ

rubyでネットワークサーバを書く時に気をつけた点についてまとめてみました。 他にも「こうした方がいいよ」とか「こういうのがあるよ」とかありましたら、いろいろ教えていただければと思います。

2007年9月17日

DRBDで2TBのハードディスク容量を使う方法
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

こんにちは、naoyaです。

先日、フォト蔵のサーバのハードディスク空き容量が減ってきたので、ハードディスクを500GBx4から1TBx4のハードディスクに交換しました。

フォト蔵のサーバでは、以前satoが紹介したようにDRBDを使って写真や動画のデータを相互バックアップしています。

フォト蔵のサーバのハードウェアとソフトウェア環境は、次のとおりです。

  • HDD: 1TB x 4
  • OS: Fedora Core 5(2.6.20)
  • DRBD: 0.7.24

ハードディスクは、二本ずつソフトウェアRAID0で組んでいます。

# cat /proc/mdstat
Personalities : [raid0]
md1 : active raid0 sdb1[0] sdc1[1]
      1953519872 blocks 64k chunks

md0 : active raid0 sda3[0] sdd1[1]
1943639872 blocks 64k chunks

unused devices:


この状態で、次のコマンドでDRBDを起動させてみました。

# /etc/init.d/drbd start

そうすると、次のエラーメッセージが表示されてしまいました。

/etc/init.d/drbd start
Starting DRBD resources:    [ d0 d1 d2 ioctl(,SET_DISK_CONFIG,)
failed: Cannot allocate memory
...

調べてみると、vmalloc sizeを192m割り当ててると、うまくいくそうなので、grubの設定ファイル(/etc/grub.conf)に、次の内容に変更してみました。

...
  title Fedora Core (2.6.20-1.2320.fc5smp)
  root (hd0,0)
  uppermem 524288
  kernel /vmlinuz-2.6.20-1.2320.fc5smp ro vmalloc=192m root=LABEL=/
  initrd /initrd-2.6.20-1.2320.fc5smp.img
...

vmallocの設定は、rootより後ろに書けないので注意してください。

この設定で、初めてDRBDで2TBのハードディスク容量を使うようにすることができました。


最初、移行するとき、DRBD上のファイルシステムはXFSにしていたのですがbonnie++でハードディスクに負荷をかけると落ちてしまうので、従来通りext3に変更して現在稼働中です。

次は、現在satoがDRBD 8系でのprimary/primaryの構成を試しているようなので、フォト蔵のサーバにも組み込めるか検討したいと思っています。


2007年9月 6日

PHPでSSL通信する時の注意点
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

yukiです。
今回はPHPでSSL通信したい時の注意点などを紹介します。

PHPでSSL通信を行う際には、

  • fsockopen
  • pfsockopen
  • file_get_contents
  • fopen
  • stream_socket_client

など様々であり、利用する場面がありますが、SSL通信が許可されている必要があります。
よくHTTP_Requestなどを利用してPOSTしたいがhttpsだとうまくいかない!という記事を見かけますが、参考になればと思います。

  • * allow_url_fopenが有効かどうか

上記の関数についてfile_get_contents・fopenでは上記設定が有効かを調べます。
php.iniで設定されていますが、通常デフォルトで使用可能なのですが、レンタルサーバーなどでは使えないこともありますので調べてみましょう。
phpinfo()関数を利用するか、コマンドラインでは
php -i | grep allow_url_fopen

で知ることが出来ます。
またphp4.0.3以前では
--disable-url-fopen-wrapper

でコンパイルされていると利用不可となっています。

  • サポートされているプロトコル・ラッパーを調べる
通信する際のプロトコル、及びラッパが使用可能かを調べます。この場合はhttps://(PHP4.3.0以降)が対象です。 phpinfo()ではRegisterd PHP Streamで確認できます。 SSL通信の場合OpenSSLがインストールされている必要があり、PHP4.3.0以降では静的にコンパイルされ組み込まれている必要がありますが、PHP5以降ではモジュールとしてコンパイルされていても使用できます。

レンタルサーバーなどでPHP4.3以降を利用し、かつOpenSSLサポートがなければ、管理者によってリコンパイルされなければなりません。

ですが、もしcurlコマンド(SSLが有効であること)が使える環境であれば、popen・proc_open関数から利用することもできます。(レスポンス速度等の問題はありますが)

なおOpenSSLのバージョンもPHPによって異なるので注意が必要です。

以下をまとめると次のような表になります。

PHP再コンパイルOpenSSL
~4.0.4×0.9.6~
4.0.5~4.2.3×0.9.5~
4.3.0~4.3.10.9.5~
4.3.2~0.9.6~
5.0.0~×0.9.6~

利用するなら、PHP5がお手軽なようです。

2007年8月24日

5分でできるウェブサーバのセキュリティ向上施策
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

こんにちは、naoya です。

先日、ウノウが公開しているサービスの中にいくつかの脆弱性が見つかったため、社内で「脆弱性発見大会」を開催しました。この大会は、二人一チームに分かれてウノウが公開している各サービスの脆弱性を見つけることを目的とした大会です。結果は、いくつか各サービスに脆弱性が見つかり、すぐに修正することができました。

僕のチームは、ウノウのホームページやラボブログなど細かいサービスを担当しました。その中で、いくつかのウェブサーバにセキュリティ上あまい設定がありました。

今日は、ウェブサーバのセキュリティ向上のための設定方法についてエントリします。なお、ウェブサーバはApache 2.2系を前提としています。

サーバ情報の表示しない

ウェブサーバ(Apache)で、404などのエラーページを表示したとき、ヘッダやページの下にApacheやOSのバージョンが表示されます。こういったサーバ情報をわざわざ表示する必要はありません。サーバ情報の表示しないようにするには、Apacheの設定ファイル(httpd.conf)に、次の設定を追加します。

  ServerTokens ProductOnly
  ServerSignature Off

この設定を追加後、Apacheを再起動するとServerヘッダにはApache、エラーページにもサーバの情報は表示されなくなります。


.で始めるディレクトリは公開しないようにする

ウノウでは、すべてのサービスをsvn(Subversion)で管理しています。アップデートもsvnで行っています。そのため、.svnディレクトリが誤って公開されていることがあります。.svnディレクトリには、ソースコードが入っていますので公開しない方がいいです。.svnだけでなく、.で始まるディレクトリを公開しないようにするようには、Apacheの設定ファイル(httpd.conf)に、次の設定を追加します。

.svnディレクトリにはソースコードが入っているので、注意する必要があります。

  <Directory ~ "/\..+/">
        Order Deny,Allow
        Deny from All
  </Directory>


最後に、PHPのセキュリティ向上施策も追記しておきます。

PHPファイルに対してリクエストすると、HTTPヘッダにX-Powered-Byという情報が入っています。X-Powered-Byヘッダには、PHPのバージョンが次のような形で含まれています。

X-Powered-By: PHP/4.3.11

このヘッダを隠すには、PHPの設定ファイル(php.ini)に、次の設定を追加します。

  expose_php = Off


この他にも、ウェブサーバのセキュリティ向上のための情報がありましたら、ぜひ教えてください!

2007年8月23日

赤ちゃんの目をシミュレートするテストツール?「TinyEyes」
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

こんにちは! やまもと@テスト番長です。

ラボブログでご紹介するネタを暖めていたら、結構話が大きくなってきてしまい、更にもう少し暖めたくなりました。
なので今回は代わりに、先日幸せの青い鳥を探してネットをうろうろしていた時に見つけた軽めのネタをご披露したいと思います。


tinyeyes
tinyeyes posted by (C)フォト蔵

生まれたての赤ちゃんはまだモノが良く見えていないんだそうです。
その赤ちゃんの視界をシミュレートするサイトです。
「TinyEyes」

赤ちゃんが生まれてからの週数と、対象までの距離をセットして画像をアップロードすると、それがどんなふうに見えているのかシミュレートして表示してくれます。

新生児向けのWEBコンテンツを作ることになったら、大活躍しそうなテストツールですね!(多分出番ない)

2007年8月21日

Flashの新しい可能生 Asynchronous Flash + XMLSocket
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

尾藤正人(a.k.a BTO)です

昨日ラボプロジェクトとして実験的に開発している新規プロジェクト「プラッシュ」をβ公開しました。 簡単に説明するとプラッシュはFlashとXMLSocketを使う事でブラウザだけでネットワーク対戦ができるゲームポータルサイトです。 今回はプラッシュで使われているFlashとXMLSocketを使ったアプローチについて考察してみたいと思います。

はじめに

正直に告白すると僕はFlashを一行も書いた事がありません。(汗) なので、Flashの部分に関してはFlash側の開発者であるyossyに聞いたり、Webで調べた情報がほとんどです。 不正確な情報が含まれてる可能性がありますが、その辺を考慮していただければと思います。

FlashのXMLSocketで何ができるのか

FlashのXMLSocketを使うと直接ソケット通信を行う事ができます。 AjaxやCometのような技術は元々ステートレスなHTTP上で非同期通信を実現していますが、 XMLSocketは直接ソケットを叩けるので自然な非同期通信を行う事ができます。 AjaxやCometはデータのやり取りをする度にコネクションが切れますが、XMLSocketはずっとコネクションをはったまま通信を行います。

通信の度にコネクションを確立するアプローチだと、毎回接続するためのコストがかかります。 XMLSocketはずっとコネクションをはっているので、通信の度に接続する必要がなく、よりリアルタイムな通信を実現する事ができます。 プラッシュではそれをネットワーク対戦ゲームに応用しました。

Flashを使ったリアルタイム通信で何ができるのか

それは僕にもわかりませんが、大いなる可能生は感じています。 Flashを使う最大のメリットはブラウザだけで動作する事です。 それにリアルタイム通信が加わった時に、従来ブラウザだけではできなかったことがブラウザだけでできるようになり、新たなる市場が開拓されるかもしれません。

何が必要なのか

FlashでXMLSocketを使用した通信を行うには次のものが必要です。
・Flash Player 5以降
・XMLSocketサーバ
・プロトコル

Flash Player 5以降

Flash Player 5以降でないとXMLSocketは使えないそうです。

XMLSocketサーバ

XMLSocketは直接ソケットを叩くので、独立したサーバが必要になります。 プラッシュではオリジナルのXMLSocketサーバを開発しました。

プロトコル

XMLSocketでの通信はソケットを直接叩くので具体的なデータのやり取りについては定められていません。 汎用的なプロトコルは存在しないので、クライアント側、サーバ側であらかじめ決められたプロトコルを定めて通信を行う事になります。 プラッシュではXMLをベースにした独自プロトコルで通信を行っています。

Flash+XMLSocketを使った既存の実装は

Flash+XMLSocketを使ったチャットの実装はいくつか公開されているようです。 それ以上本格的なものはなかなか見つからないのが現状です。

天鳳というオンライン麻雀がありますが、これはFlash+XMLSocketで作られています。 天鳳は大変素晴らしい実装なので一度遊んでみるといいと思います。

Flash+XMLSocketをもっと普及させるには

Flash+XMLSocketを使ったリアルタイム通信は古くから存在するにも関わらず、それほど注目されていませんでした。 僕はこの技術に大いなる可能生を感じていて、もっと広く普及しないかなと思っています。 そこでこの技術が普及するために何が必要かを考えてみました。

名前をつける

技術がより一般的になるためには呼びやすい名前が必要です。 「FlashとXMLSocketを使ってリアルタイム通信するやつ」なんてのはかったるくて呼びづらい。 何か良い名前はないでしょうか。

開発の敷居を下げる

より多くの実装が出てくるには開発の敷居を下げる事が重要。 開発の敷居を下げるために必要なことをつらつらと書いてみます。

フリーの汎用的なXMLSocketサーバ

既にXMLSocketサーバの実装はいくつかあるようですが、開発が止まっていたり、チャットに特化しているのが実情のようです。 フリーで汎用的なXMLSocketサーバがあれば開発の敷居を大きく下げる事ができると思っています。

モジュールのような形でプログラムを書く事ができて、LLで実装できるようなやつ。 プラッシュではRubyでXMLSocketサーバを書いてます。 LLでもうまくやれば十分サーバの開発は可能です。

汎用的なプロトコル

実装するたびに毎回独自プロトコルを作るのは大変ですから、汎用的なプロトコルが欲しいところ。 汎用的で可読性が高くて単純で拡張性が高いプロトコルがいいかなと思っています。 汎用的なプロトコルを定義するだけでなく、もちろんそれをベースにしたFlashライブラリ、XMLSocketサーバの実装も必要です。

まとめ

みなさんもFlash+XMLSocketを使って何か実装してみてはどうでしょうか。 今までにない何かが作れるかもしれません。

今回プラッシュで作った成果物は何らかの形でうまく公開できないか思案中です。 公開する時には、またこのブログで紹介したいと思います。

2007年8月13日

プログラミングに使いやすいフォントを選ぶ
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

yukiです。

人によってまちまちですが、見易さや生産性にかなり影響する(と思っている)プログラミング時のフォントについて紹介します。
マカーの方はデフォルトで十分読みやすいフォントが入っているので、ここではwindows向けとして紹介させて頂きます。
個人的に選ぶポイントは、


  • ゼロ・オーは斜線で区別がつく

  • 日本語も使える

  • 長時間見ても疲れない(一番大事)


です。これいいよ!というのがあったら絶賛募集中です。

有名どころかもしれませんが

M+フォント

M+フォント
M+フォント posted by (C)フォト蔵
普段はコレを使わせていただいています。
自分的にはゼロ(0)とオー(O)の差が分かりやすく◎です。
ゼロの中にスラッシュやドットが入っていて読みやすく、等幅なので使いやすいです。

VLゴシックフォントファミリ

上記のM+を元に製作されたフォントです。 弊社CTOが過去に参加されていたVineLinuxのProjectVineの方が製作されています。

小夏フォント

ちょっとクセがありますが、縮小しても見やすくいい感じのフォントです。

XANO明朝フォント

日立と契約し無償で配布されているフォント。明朝体なので若干日本語が厳しめですが、英数字には良いかも知れません。

また、ClearTypeを使うとWindowsでも多少美しくなるので、ClearTypeに対応したフォントがあれば試してみる価値があるかもしれません。

2007年7月27日

ベンチャー流Webサービスの作り方(開発チーム編)
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

尾藤正人(a.k.a BTO)です

前回はWebサービスを作るときの企画の部分について書きました (ベンチャー流Webサービスの作り方(企画編))。 今回はWebサービスを作るときの組織作りについて書いてみたいと思います。

僕がウノウに入って始めたのがフォト蔵の開発でした。 当初は開発が僕、ディレクションが代表の山田という二人体制でやってましたが、 組織が大きくなるにつれてだんだんと人数が増えていきました。 現在は僕も山田もフォト蔵からは離れて新しいチームで開発を行っています。

二人体制から始めて、少しずつ人数を増やしていって、 立ち上げメンバーが開発から離れるまでいろいろ経験しながら 自分が感じた事を簡単にまとめたいと思います。

・最終決断は一人で

何をするのか、戦略はどうするのか、方向性は何なのか、最終的な決断はリーダーが一人で行います。 個人の主張を尊重しすぎて、各々が好きな事を始めると体制がめちゃくちゃになります。 2:8の法則は、どんなに優秀な人、やる気のある人を集めても必ず成り立ちます。 最終的なビジョンの部分まで考えて行動できるのはリーダーだけです。

最終決断をリーダーがくださない状態になると以下のような事柄が発生します。

方向性がブレる - 大きなことやるにはチームが一丸となって取り組む必要があるのです が、 一人一人が自分のやりたい事しかやらなくなるので、何がやりたいのかがさっぱり分からなくなります。

全体の事を考えなくなる - サービスは一つの事柄だけとらえてはダメで全体として考え ないといけないのですが、 自分の範囲でしか物事を思考しなくなります。 過去の例としては、 「富豪的に機能を追加・変更する -> サーバ負荷が高くなる -> 誰も異議を唱えない」 「重大な不具合が発生 -> リーダは知らんぷり -> 他の開発者は自分の案件だけ -> 緊急対応にも関わらず対応してるのは担当者だけ」 というのが実際に起こりました。

・リーダーに必要な要素

では、リーダーはどういうことをやればいいのかをまとめてみます。

ビジョナリーである - 企業としてサービスの開発を行うなら大きなビジョンを持ちまし ょう。 小さな前進しか考えられないのであればリーダーの資格はありません。

決断力がある - 大きな事を実現するには大きな決断が必要です。 大きな決断をくだすのは、言うのは簡単ですが実行するのはなかなか難しいです。 失敗を恐れずに実行しましょう。決断をくだすことができる精神力を鍛えましょう。

こだわりを捨てられる - 実際にやってみるとうまく行かない場合がほとんどです。 そういう時に事実を客観的に受け止めて、考え方を変えるのは実はなかなかできません。

技術が分かる - 一流のプログラマである必要はありませんが、 プログラムを書けるようにはなっておきましょう。 技術が分からなければ実現可能性があるかどうかの判断もできません。 どうしても技術が分からないというのであれば、信頼の置ける参謀が必要です。

技術にこだわらない - 技術ができる人に多いのですが、 技術にこだわりすぎる人がいます。 最終目標はサービスの成功であって、高度な技術を活用することではないはずです。 あくまでも技術は目的を実現するための手段であることを心得ましょう。

雑用を積極的に引き受ける - 良いシステムを作るには現場の開発者の力が必要です。 リーダーは積極的に雑用をこなして、開発者が開発に集中できる体制を整えましょう。

開発者の希望をできるだけ尊重する - 開発者がシステムを作る原動力はモチベーション です。 どんなに優秀な人でもモチベーションのある人とない人とでは、 自ずと結果が違ってきます。 最終決断をくだすのはリーダーですが、 その中でもできるだけ開発者の意向を尊重するようにしましょう。

・コア開発者を捕まえる

自社でシステムを作るのですから、コアはしっかりと握っておきたいところです。 できるだけ自社のエンジニアに開発してもらいましょう。 外注するなら協業にしましょう。 いいサービスを作るのにはモチベーションが必要です。 単なる受託開発では真剣にやってもらえないので、協業にして密にやりとりしましょう。最悪なのが外注先のたらい回しです。 システムがどんどん汚くなって収集がつかなくなります。

・無駄なミーティングを増やさない

人数が増えてくるとだんだんミーティングの数が増えてきます。 何も考えずにやってると、いつの間にかミーティングの時間だけが増えて、 一生懸命やってるのに全然進まないという事態に陥ります。 定期的に見直して、ミーティングの数を減らす、効率よく行う努力を怠らないようにしましょう。

・ミーティングに参加する人数を増やさない

人数が増えてくるとミーティングに参加する人数がどんどん増えてきます。 人数が増えてくると時間がかかって議論がまとまらなくなるので全然進まなくなってきます。 細かい単位に分けたり、メリハリをつけるなどして工夫しましょう。

・フルコミットする

片手間でやるのはやめましょう。 受託開発をして日銭稼ぎつつ、 あるいは本業を持ちつつ空いた時間で片手間でサービスの開発を行うのは想像以上に厳しいです。 パートナーが別に仕事持っているならいさぎよく辞めてもらいましょう。 今の仕事を捨てられない程度の覚悟しかないのなら、 最初からやってもらわない方がマシです。

収益の不透明なサービス開発にフルコミットしてもらうのは、 組織的にも資金的にも苦しいと思います。 なんとかしてフルコミットしてもらえる体制作りをしましょう。 それは経営者の仕事であり、リーダーの仕事でもあります。

・まとめ

Webサービスの開発は戦略から要件定義、開発まで全て自分達で行います。 身内だけでやっていると、結果に対する評価がどうしても甘くなってしまって緊張がなくなりがちです。 適度な緊張感とモチベーションを維持しつつ、開発を続けていくにはしっかりとしたチーム作りが必要不可欠です。

2007年6月18日

ベンチャー流Webサービスの作り方(企画編)
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

尾藤正人(a.k.a BTO)です

僕はウノウが株式会社化するタイミングでウノウに参画しました。 それ以来はずっと二年半程Webサービスの開発に従事してきました。 ウノウに参画した当初はWebサービスのことは全く分かっておらず、 単なるLinux好きのエンジニアにすぎませんでした。

ウノウ株式会社の創業時に参画することにより、 サービスの企画から開発、運用まで携わることができました。

最初はエンジニアが自分一人だけだっとところから、 現在のように数多くの優秀なエンジニアを抱える企業に成長するまでの組織作りにも関わることができました。

全く経験のないところから始めたので、それこそいろんな失敗を重ねてきました。 そこで今までの経験を元にベンチャーがWebサービスを開発するにあたって気をつけておいた方がいいことをまとめてみます。

Webサービスの開発を始めるには、何はなくとも企画から。 今回はWebサービスを企画するにあたって気をつけたいことをまとめます。

・自分が思いついたことは他人も同じことを思いついている

人間の想像力はそれほど他人と変わるものではなく、 自分が思いついたアイデアは他の人も同じことを思っている可能性が高いです。 大事なのはそれを実際に形にする行動力。

・行動力

思いついたらまず行動しましょう。 すぐに行動しないと判断がブレます。 行動しないと何も生まれません。 「それ同じこと考えてたんだよね」と後でいうのは完全に言い訳です。

・スピード重視

とにかくスピードを重視しましょう。 遅延はコスト増、成功確率低につながり、いいところはほとんどありません。

・少人数体制

企画は少人数で行いましょう。 人数が多いと「船頭多くして船山に登る」になってしまい、 決定事項も全員の意見をうまくまとめた最小公倍数的なものになってしまいます。 これでは、思い切ったことや、大きなことができません。 相談するのはいいですが、最終的な決断は一人、多くても二人で行うのが理想です。

・ブレストをしよう

単なるアイデア出しは人数が多い方がいいです。 いろんな人と話をしたり、ブレストしたりしていろんなアイデアを出しましょう。

・機能追加は慎重に

Webサービスは気軽に機能拡張することができます。 そのためいろいろ機能を追加しがちですが、 一回追加した機能を外すのは機能を追加するよりも難しいです。 新機能の追加は慎重に行いましょう。 「システムを複雑にするのは簡単だが、簡単にするのは難しい」を肝に銘じておきましょう。

・ユーザの反応は予想と違うと考えよう

ユーザの反応、使い方は企画者側が想像したのと違うと考えておくべきです。 予想通りだったら問題ないですが、 予想通りいかなかった場合にうまく舵取りできるような体制にしておかないといけません。

・ユーザ視点で考えよう

Webサービスはユーザに使ってもらわないと意味がありません。 「ユーザの反応 >>>> 自分のやりたいこと」の図式を頭に叩き込んでおきましょう。 自分のやりたいことを優先させるのは単なる自己満足にすぎません。

・コアユーザは少ないことを認識しよう

熱狂的に使ってくれるようなコアユーザの割合は基本的には少なくて、 せいぜい一割か多くて二割ぐらいです。 アクセスの多くを占めるのは傍観者で、多くの傍観者を生み出すのがコアユーザです。 コアユーザに喜んでもらえるようなサービス作りを心がけましょう。 コアユーザに気に入ってもらわなければサービスは伸びません。

・聞いていい意見といけない意見をしっかり区別しよう

ユーザからの意見はしっかり聞きましょう。 そして聞いていい意見といけない意見をしっかり区別しましょう。 聞いていいかどうかの判断は非常に難しいですが、 コアユーザに喜んでもらえそうな意見を採用しましょう。

サービスを大きくするには広がりが大事です。 他のユーザに影響の与えないような意見は開発コストがかかるだけで、 サービスが大きくなる原動力にはなりえません。

・自分のリテラシーを徹底的に下げる

ユーザは自分達が想像するよりも無知であることを認識しましょう。 「これぐらい分かるだろう」という考えは危険です。 自分のリテラシーを徹底的に下げて物事を考えるようにしましょう。

・方向転換する勇気

サービスを立ち上げた人は自分の考えにこだわりのある人が多いです。 ユーザの反応を見て、想像と違った場合にそれを認めるのは勇気のいることです。 ユーザの反応がよくない場合はそれを素直に認めて方向転換しましょう。

Flickrが最初はMMORPGを開発する会社だったのがうまくいかず、 写真共有サービスとして方向転換して成功したのが顕著な例です。 ここまで大幅な方向転換は稀ですが、小さな方向転換はいろんな場面ででてきます。

・シンプルに

とにかくシンプルにしましょう。 基本的にWebサービスの開発は「企画->開発->ユーザの反応を見る->企画」の繰り返しです。 先に述べたように、追加した機能を外すのはそんなに簡単ではありませんし、 予想と違って方向転換を行う必要がいくつも出てきます。

最初に作り込んでしまうと、 ユーザの反応がよくなかったときに方向転換するのが難しくなります。 できるだけシンプルにしておいて、まずはユーザの反応を見ましょう。 ユーザの反応が良ければ拡張・継続、悪ければやめればいいだけです。

・こだわりを持とう

ユーザの反応を見て素直に認めるのも大事ですが、時にはこだわりも大事です。 周りから大反対されても自分の信念に従って突き進むことも必要です。 iPod登場時のAppleユーザの反応は冷ややかでした。 何がうまく行くかなんてのは誰にも分からないし、 最初からうまくいくことも多くはありません。

・あきらめない

たとえ自分が考えた通りにうまくいかなくても粘りましょう。 どん底の状態でも起死回生は可能です。 あきらめた時点で終わりです。とことんやりましょう。

・愛だよ、愛 by Keita

最終的に大事なのは、そのサービスに対する愛です。 どんなに優秀な人でも、あなたがそのサービスにかける情熱には勝てません。 この熱意がサービスを成長させるためには必要です。

・まとめ

Webサービスを開発するにあたって企画の部分で気をつけないといけないことをまとめてみました。 人それぞれ考え方は違うとは思いますが、僕なりに経験を重ねいろいろ考えた上で現在の結論に至っています。 今後自分でWebサービスを開発したい方の参考になれば幸いです。

2007年5月21日

Wii対応サイト向けコマンド入力ライブラリ
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

尾藤正人 a.k.a BTO です。

先週末開発合宿に行ってきました。 開発合宿のレポートはまた後日書きますので、しばしお待ちを。

僕は今回の開発合宿でWii対応サイト向けのコマンド入力ライブラリを作りました。 まずはデモをご覧ください。

wii.js デモ

別にWiiでなくても、ちゃんと普通のブラウザでも動作しますので、恐れずにカーソルキーでコマンドを入力してもらえればと思います。

WiiでWebにアクセスしているとパスワードの入力にかなり抵抗を感じます。 通常PCからWebにアクセスするときは一人でアクセスしますが、 Wiiでアクセスするときは一緒にみる事が多いのでパスワードをあまり入力したくありません。 インターネットチャンネルが正式版になってから、 入力した文字が「*」で隠されるようになりましたが、 それでも入力している動作は丸見えです。 そこでコマンドでパスワードが入力できればいいのではないかと思い、 今回のライブラリを作成しました。

使い方

  • prototype.jsを組み込む
  • wii.jsを組み込む
  • wii_command = new Wii.Command('password_field'); // "password_field"はパスワードフィールドのid
  • wii_command.replace();

newしてreplace()を実行します。 replace()を実行するとパスワードフィールドをリンクに置き換えてくれます。

メッセージを変更する

デフォルトだと英語のメッセージが表示されます。 メッセージは"linkMessage", "promptMessage"で変更できます。 "linkMessage"にパスワードフィールドを置き換えるアンカータグのメッセージを、 "promptMessage"にウィンドウに表示するメッセージを指定します。


  var wii_command = new Wii.Command('password_field');
  wii_command.linkMessage = "クリックしてパスワードコマンドを入力してください"
  wii_command.promptMessage = "パスワードコマンドを入力してAボタンを押してください"
  wii_command.replace();

別のウィンドウライブラリを使用する

wii.jsではデフォルトでウィンドウを表示する簡単なクラスWii.Windowを使っています。 これは外部から変更可能です。 ウィンドウの表示、非表示には、それぞれshowWindow(), hideWindow()というメソッドを呼んでいますので、これを上書きしてください。


  var wii_command = new Wii.Command('password_field');
  wii_command.showWindow = function() {
    // ウィンドウを表示する
  }
  wii_command.hideWindow = function() {
    // ウィンドウを隠す
  }
  wii_command.replace();

対応する文字を変更する

実はwii.jsで入力されたコマンドは、単にそれぞれのキーを文字に対応させているだけです。 デフォルトのキーマーップは次のようになってます。


  keyMap: {
    Up:    'k', Down:  'j', Left:  'h', Right: 'l', A:     'a', B:     'b',
    1:     '1', 2:     '2', Plus:  '+', Minus: '-'},

つまり"上上下下左右左右"と入力するとパスワードフィールドには"kkjjhlhl"が入力されます。 このキーマップは次のようにして変更可能です。


  var wii_command = new Wii.Command('password_field');
  wii_command.keyMap = {
    Up:    'u', Down:  'd', Left:  'l', Right: 'r', A:     'a', B:     'b',
    1:     '1', 2:     '2', Plus:  '+', Minus: '-'};
  wii_command.replace();

このキーマップの場合、"上上下下左右左右"というコマンドで"uuddlrlr"が入力されます。

毎回設定するのが面倒なのでサブクラスを作る

毎回設定するのが面倒な場合はサブクラスを作ることができます。 サブクラスを作ると毎回上書きしなくてすむようになって便利です。


MyWiiCommand = function() {
  Wii.Command.apply(this, arguments);
};
MyWiiCommand.prototype = new Wii.Command;
Object.extend(MyWiiCommand.prototype, {
  // ここで適当に上書き
});

// MyWiiCommandを使う
(new MyWiiCommand('password_field')).replace();

Wiiリモコンイベント処理クラス - Wii.Controller

wii.jsにはWiiリモコンのイベントを扱うクラスWii.Controllerがあります。 WiiだけでなくIE, Firefox, Operaにも対応していて、 "上", "下", "左", "右", "A", "B", "1", "2", "+", "-"のイベントを扱う事ができます。

Wii.Controllerはnewして、handlerにキーイベントを扱うハンドラーを登録することで使う事ができます。 newするとすぐにキーイベントの取得ができるようになります。 キーイベントの取得を中止したい時はend()を呼んで、 再開したい時はstart()を呼びます。


  var wii_controller = new Wii.Controller;
  wii_controller.handler = function(event, keyCode) {
    alert('keyCode');
  };

  // キーの読み取りを中止する
  wii_controller.end();

  // キーの読み取りを再開する
  wii_controller.start();

まとめ

開発合宿でWii対応サイト向けコマンド入力ライブラリを作成しました。 このライブラリに関しては特に権利は主張する気は全くないので、ご自由に使用していただければ幸いです。 一応、修正BSDライセンスにしておきます。

ダウンロード

wii.js

2007年4月23日

ベンチャー流のスパムメール対策術(前編)
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

先週まで風邪や雨の多い日が続いていてなかなか自転車通勤ができませんでしたが、今日から自転車通勤を再開したnaoyaです。

今日は、僕がメールサーバを新しく構築するにあたって新たにスパム対策を施したので、その内容について紹介します。

まず、メールサーバですが、次のようなオープンソースソフトウェアで構成されています。

それぞれ yum で最新版をインストールしていました。さらにウノウではメーリングリストを使っているのですが、メーリングリストの配送プログラムには mailman を使っています。mailman も yum で最新版をインストールしました。

さてスパムメールですが、よくメーリングリスト宛にたくさん送られてくるのに対して個人宛にはまったく送られてきません。

そこで、メーリングリストプログラムでメールの配送前にスパム対策を施そうと、まずはオープンソースで使えるスパムフィルターを探してみました。

次の三つのスパムフィルターが見つかりました。

それぞれのスパムフィルターの特徴は、次の通りです。

SpamAssassin

おそらく世界で一番有名なスパムフィルターだと思います。Perl で書かれており、デーモンとしても動作します。

bsfilter

Ruby で書かれているスパムフィルター。作者が日本人のため、日本語に標準で対応しています。

bogofilter

C 言語で書かれているスパムフィルター。C 言語のため高速に動作する。

すべてのスパムフィルターを使うとメールの配送が遅れてしまう予感がしたので、まずはどのスパムフィルターを使うと効果的か自分のメール環境で試してみました。

それぞれのスパムフィルターを試すために、インストールと設定をしました。

SpamAssassin

  1. # yum -y install spamassassin
  2. 設定ファイル (/etc/mail/spamassassin/local.cf) を日本語対応のファイルに置き換える(*1)
  3. # chkconfig spamassassin on
  4. # /etc/init.d/spamassassin start

(*1) Tokyo Linux Entertainment Community様にて配布されている定義ファイルが便利です。

bsfilter

パッケージはないため、ホームページから最新版をダウンロードして展開します。

bogofilter

日本語に対応させるため、kakasi もあわせてインストールします。

  1. # yum install bogofilter
  2. # yum install kakasi


スパムフィルターをインストールしてたら、まず行うのは Ham& Spam メールの学習です。
スパムフィルターの学習を手動で毎回行うのは面倒のため、次のようなシェルスクリプトを作って cron で深夜 0 時に毎日実行するようにしました。
なお、下記のシェルスクリプトでは、MailDir 形式で spam ディレクトリにスパムメールが存在して、cur ディレクトリ(つまり Inbox)に通常のメールがある前提で作成されていますので注意してください。

#!/bin/sh
BGFILTER=/usr/bin/bogofilter
BSFILTER=/opt/bsfilter/bsfilter/bsfilter
SALEARN=/usr/bin/sa-learn
MAILDIR=$HOME/Maildir

# spam
echo "spam for bogofilter..."
find $MAILDIR/.spam/cur -name "*" -type f -exec nkf -Z -m -j {} \; | kakasi -w | $BGFILTER -Nsv
echo "spam for bsfilter..."
$BSFILTER -sv $MAILDIR/.spam/cur/*
echo "spam for SpamAssasin..."
$SALEARN --spam $MAILDIR/.spam/cur

echo ""

# not spam
echo "ham for bogofilter..."
find $MAILDIR/cur -name "*" -type f -exec nkf -Z -m -j {} \; | kakasi -w | $BGFILTER -Snv
echo "ham for bsfilter..."
$BSFILTER -cv $MAILDIR/cur/*
echo "ham for SpamAssasin..."
$SALEARN --ham $MAILDIR/cur

# update database
$BSFILTER -u

このシェルスクリプトを約2週間ほど自動実行して Ham& Spam メールの学習を行いました。 この状態で、やっとどのスパムフィルターが効果的か試験をすることにしたのですが、長くなってきましたので、続きは後編で書きたいと思います。

後編では、スパムフィルターを試した結果と mailman でのスパム対策方法について書きたいと思います。

2007年3月19日

ウノウラボブログが1歳になりました!! - ウノウラボブログを通して思った事感じた事
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

尾藤正人です。

ウノウラボブログの最初のエントリから始まってウノウラボブログもとうとう1歳になりました。 最初は購読者数も少なかったラボブログですが、今では購読者数も増え多くの方に読んでいただけるブログに成長する事ができました。 これもひとえにいつも読んでいただいてる読者の方のおかげだと思っています。

今日はラボブログ1周年を迎えた記念に、この1年を通して感じた事、思った事などをつらつらと書いていきたいと思います。

開発合宿の成果報告場から情報公開の場へ

ウノウでは2ヶ月に1回ぐらいのペースで開発合宿に行っています。 当初ラボブログは開発合宿での成果を公開する目的で始めました。 ですが、開発合宿の成果をそうそう頻繁に出すのは難しいのでどうしようかという話になり、だったら開発合宿の成果だけに留まらずどんどん情報を公開していく場にしようということで、エントリを書き始めました。

OSSから影響を受けた公開に対する強い思い

ウノウではオープンソースソフトウェアを多く使用しています。 僕も昔はVine Linux SPARC版の開発をやってた時期とかもあり、オープンソースソフトウェアが大好きです。 コミッターは自分の時間を削って有意義なソフトウェアを無償で提供してくれています。 その恩恵で給料をもらって生活しているわけですから、もらいっぱなしはよくない。 公開できるものはどんどん公開してコミュニティに還元するべきだという強い思いがありました。

1日1エントリ

ラボブログでは1日1エントリを目標にエンジニア、デザイナ、テスターで持ち回りで書いています。 当初「書きたいエントリがあった時に書きたい人が書く」という方法も提案されたのですが、それでは絶対に続かないと思って持ち回り制にしました。 ブログの場合はネタが新鮮かどうかも重要なので、ネタがある時に先に書くのは問題ありません。 その場合は自分の順番が来た時に飛ばして次の人が書くようになってます。

ちょっとした報酬

ラボブログではてなブックマークで100以上のユーザを獲得するとamazonギフト券3000円がもらえるようになってます。 人気エントリを書くと本が1冊購入できるというようなイメージです。

人気エントリにはそれほどこだわらずに

人気エントリを書くと嬉しいのですが、そこにはそれほどこだわりを持たないようにしてます。 まとめ系のエントリを書くとたくさんブックマークしてくれたりするのですが、だからといってまとめ系のエントリばっかり書くと中身の薄いブログになってしまう。 ラボブログ賞を高額に設定しなかったのは、適度なインセンティブを提供しつつ、ブックマーク数にそれほどこだわりを持って欲しくなかったからです。

小さな挑戦のきっかけに

通常業務の中でたんたんと仕事をこなしているだけでは、新しい事に挑戦する事ができません。 IT業界は変化が激しいですから、どんどん新しい知識を吸収していろんなことに挑戦していかないと、すぐに置いてけぼりにされてしまいます。 ブログのエントリを書く事が、普段と違ったことをやったり、新しい情報を調べたりすることのきっかけにすることができます。 時には至らない点もあってするどい突っ込みをいただく事もありますが、失敗を通して自身の成長に繋げる事ができます。

実は社外だけでなく社内の情報共有になる

基本的に社外に向けて情報公開していますが、一人一人持ってる知識に違いがあるので、実は社内での情報共有に一役買ってます。 ウノウの社員同士でもお互いのエントリをブックマークしたりしてます(自作自演という意味ではなく)。

ウノウの名前を多くの方に知ってもらうようになった

ラボブログのおかげで多くの方にウノウの名前を知ってもらえるようになりました。 ウノウの本事業の事は知らなくてもラボブログを読んでくれている方も多数います。 ウノウラボがウノウとは別会社だと思われる事も。 ウノウ本体の事業ももっと頑張ってウノウラボよりも有名になるように頑張ります!!

リクルーティングに効果大!!

弊社に応募してくる方でラボブログを読んで応募されるという方が増えてきました。 他のIT企業の方とお話すると、どこの会社さんも優秀な人材確保に苦労されています。 弊社の場合は他社さんと比べて比較的多くの優秀な人材を確保できていると自負しています。 それもラボブログで積極的に情報公開してきたおかげだと思っています。

Give&TakeはGiveから始まる

GiveせずにTakeだけしても何も得る事はできません。 提供できる物はどんどん提供しましょう。 最終的にはそれ以上のリターンが得られます。 公開する事から全ては始まります。

まとめ

ラボブログをやってきた思ったのは「よかった」という一言につきます。 ラボブログを通して数多くのものを得る事ができました。

「御社はよくあそこまで情報公開されますね」と言われる事がよくありますが、それは企業側の利権しか考えてないからじゃないでしょうか。 もちろんそれ自体は全然悪い事ではないのですが、もっと広い視点で考えてみたら良いと思います。 情報を積極的に公開してよりよいサービスがたくさん出れば、もっとたくさんの人がハッピーになれる。 ITはそういう風に発展してきたはずだし、僕らはその恩恵で給料をもらって仕事をしているのですから、それを何らかの形で還元しようとするのはごく自然の発想ではないでしょうか。

今後もウノウラボブログでは積極的にいろんな情報を公開していきたいと思います。 これからも暖かく、時には厳しく見守っていただければ幸いです。

2007年3月14日

専用サーバを構築するときにまず行う4つの設定
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

こんばんは、最近寒い夜が続いていて自転車通勤がつらくなってきた naoya です。

ウノウでは、フォト蔵や社内システムなどは、すべて専用サーバを構築して運用をしています。

今日は、専用サーバを構築するときに、僕がウノウで学んだ専用サーバでまず行う4つの設定を紹介します。

なお、今回の設定はすべて Fedora Core 5 をもとにしています。

(1) sudo を使えるようにする

sudo コマンドを使えるようにします。sudo コマンドは、別のユーザとしてコマンドを実行できるコマンドです。

sudo コマンドを使えるようにするには、/etc/sudoers に sudo を許可するグループを追加します。次の例は、unoh グループを追加する例です。


%unoh ALL = (ALL) ALL, !/bin/su, /bin/su postgres, /bin/su * postgres


(2) su を使えないようにする

su コマンドでスーパーユーザになるのは便利なのですが、一度 root になってしまうと誤って重要なファイルを削除しまうことがあるため、su コマンドでスーパーユーザになれないようにします。この設定をすると、スーパーユーザになるには sudo を使うことしかできなくなりますので、注意してください。

su コマンドを使えないようにするには、/etc/pam.d/su ファイルの次の行をコメントを外します。


#auth required pam_wheel.so use_uid


(3) root のパスワードを削除する

root でログインできないように root のパスワードを削除します。

root のパスワードを削除するには、/etc/shadow ファイルの root のパスワード部分に「!!」と変更します。次のような内容になります。


root:!!:13410:0:99999:7:::


(4) iptables を設定する

最後に iptables を設定して、不要なポートにアクセスできないように設定します。 基本的なポリシーとしては、次のようになります。

  • 外部からの接続は、基本的にすべて拒否するが、ローカルネットワーク内からの接続は許可する
  • ポート転送は許可しない
  • ローカルホストからの接続は、すべて許可する

最初に、すでに定義されている INPUT チェインを削除します。


$ sudo /sbin/iptables -P INPUT DROP

次に、外部からの INPUT チェインを定義します。INPUT チェインを定義するには、次のコマンドを実行します。このコマンドの意味は、「サービスに対して接続が確立した場合は、それ以降のパケットを通過させる」ということになります。


$ sudo /sbin/iptables -A INPUT -i all -m state --state ESTABLISHED,RELATED -j ACCEPT

次に、ローカルホストからの接続は許可するように設定します。


$ sudo /sbin/iptables -A INPUT -p icmp -j ACCEPT
$ sudo /sbin/iptables -A INPUT -i lo -j ACCEPT

次に、ローカルネットワークからの接続はすべて許可します。


$ sudo /sbin/iptables -A INPUT -s 192.168.1.0 -j ACCEPT

あとは、お好みで必要なサービスのポートを開放します。例えば、SSH のポートを開放するには、次のコマンドを実行します。


$ sudo /sbin/iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

最後に、今まで作成した iptables のルールを保存して、iptables を再起動します。


$ sudo /etc/init.d/iptables save
$ sudo /etc/init.d/iptables restart


以上の4つの設定を行うと比較的専用サーバでセキュリティを確保することができると思います。

また、こんな設定も便利などありましたら、ぜひ教えてください。

# 2007.03.18 追記

たくさんのフィードバックありがとうございます。 フィードバックを元に、修正と追記をさせていただきます。

(1) sudo を使えるようにする

/etc/sudouser を直接そのまま編集するよりも、visudo コマンドを使うとより安全へに編集できるようになります。また、編集内容も次の内容で十分です。


$ sudo visudo


%unoh ALL = (ALL) ALL, !/bin/su

(3) root のパスワードを削除する

/etc/shadow を直接そのま編集するよりも、vipw コマンドを使った方がより安全に編集できるようになります。


$ sudo vipw

(4) iptables を設定する

次のコマンドの意味を「すでに定義されている INPUT チェインを削除します」と火書きましたが、「INPUT チェインポリシーを DROP に変更する」という意味でした。チェインポリシーを DROP に変更すると、iptables で指定されているポート以外に接続されたときには、接続を拒否するようになります。


$ sudo /sbin/iptables -P INPUT DROP

iptables を再起動するときは、init.d にあるシェルスクリプトを実行すると、service コマンドを使った方が便利です。iptables を再起動するには、次のコマンドを実行します。


$ sudo /sbin/service iptables restart


また、専用サーバを構築するときには、メンテナンスのために ssh を使うことが多いと思います。ウノウでも ssh を使って、専用サーバのメンテナンスを日々しています。

なので、今回の追記にあわせて ssh の設定も書きたいと思います。ssh の標準状態ではパスワード認証が有効になっています。パスワード認証が有効になっていると、パスフレーズの総当たり攻撃に対して弱いので公開鍵認証のみに変更します。公開鍵のみ認証にするには、ssh の設定ファイル /etc/ssh/sshd_config に次の行を追記します。


PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no

また、ssh のプロトコルバージョンが標準の設定では、1 と 2 ともに有効になっていますので、2 だけに変更しています。プロトコルバージョンを変更するには、/etc/sshd/sshd_config ファイルの Protocol の行を 1,2 から 2 に変更します。

あとは、ssh を再起動するだけです。ssh を再起動するときは、設定ミスがあるかもしれないので、必ずターミナルで ssh で専用サーバに接続している状態で再起動すると安心です。ssh を再起動するには、次のコマンドを実行します。ssh を再起動したあとは、別のターミナルで ssh で接続して問題がないことを確認します。


$ sudo kill -HUP `cat /var/run/sshd.pid`

最後のトピックスとして、設定ファイルを編集するときには必ずオリジナルのファイルをバックアップしておいた方がいいです。ウノウでは、設定ファイルのオリジナルのファイルは必ずバックアップしています。オリジナルのファイルをバックアップしておくと、何か設定ミスがあった場合原因を特定しやすくなります。

本エントリにいくつか間違いがあって申し訳ありませんでした。今後もウノウラボをよろしくお願いします!

2007年3月13日

テストという名前のワインを入手する方法
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

こんにちは!やまもと@テスト番長です。

最近次第に春めいて参りました。
そろそろ巷は卒業シーズンかと思われます。
この春ウノウを卒業するQAスタッフはおりませんが、
時期的に贈り物やらアルコールやらが活躍する時ですね。

今回はテストという名前のワインを手に入れる方法をご紹介します。
そういう名前のワインが世界のどこかにあるのかというと、恐らくありません。
完成品の名前にはさすがに付けられない単語のようですね。。。

無ければ、作ってしまいましょう。
QAエンジニアへの贈り物にどうぞ。

1) ワインとサインペンを用意する。

「EST! EST!! EST!!!」というワインと、サインペンを一本用意します。 エスト・エスト・エストは自分のような庶民が普段手をつけても心が痛まないような、 お値打ちで良い白ワインです。機会があれば是非一度お試しを。

テストという名前のワインを入手する方法 1)
テストという名前のワインを入手する方法 1) posted by (C)フォト蔵


2) 「T」の文字を書き加える。


「EST!」→「TEST!」にしてしまいましょう。
一文字書き加えるだけであら不思議、テストという名前になってしまいます。

テストという名前のワインを入手する方法 2)
テストという名前のワインを入手する方法 2) posted by (C)フォト蔵


3) 出来上がり。


裏のラベルもお忘れなく。

テストという名前のワインを入手する方法 3)
テストという名前のワインを入手する方法 3) posted by (C)フォト蔵


#たまにはネタもご披露ということで。

2007年1月24日

ウェブデザインに不可欠なツールサイトの紹介
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

naoyaです。
今日は最近見つけました”ウェブデザインに不可欠なツールサイト”を紹介します。その名前も「Web Design Tools - thePeoplesToolbox」です。このサイトはウェブデザインの使われるさまざまなサイトをまとめたサイトです。






それでは、さっそく使ってみることにしましょう。
まず、最初にユーザ登録した方が自分のツールボックスにできるので登録してみましょう。
登録するには、右上の"login"リンクから、必要な情報を入力するだけでその場で登録完了となります。"Enter Code"には、"Authentication Code"と同じ文字を入力します。

ウェブデザインサイト1
ウェブデザインサイト1 posted by (C) フォト蔵

ログイン後、"home"リンクからトップページを表示すると、ウェブデザインに使えるサイトの一覧がカテゴリ別に表示されています。
この中から、好きなものを選択して"box"ボタンを押すルと自分のツールボックス(Your Tool Box)に登録される仕組みになっています。

それぞれのカテゴリには登録しているユーザ数が表示されていて、どのサイトが人気があって使いやすいのかが分かるようになっています。

せっかくなので、それぞれのカテゴリで一番多く登録されているサイトを紹介します。


Color(色)

Color カテゴリのトップには、4096 Color Wheel というサイトが登録されています。
このサイトは、色見本円の上にマウスカーソルを置くと、すぐに RGB コード出力されるようです。円の下には、前後の近い色も表示されるようになっており、さらに右にはその色に近い RGB のいずれかの色見本が表示されています。
あの色の RGB コードが分からないときに、すぐに調べるサイトにはかなり使えると思いました。


CSS

CSS カテゴリのトップには、spiffy corners というサイトが登録されています。
このサイトは、イメージや JavaScript をまったく使わずに CSS と HTML だけのシンプルな角丸ボックスを作成することができるサイトです。

サイトの上部に表示例があるので、次の項目を入力して、最後に枠線の太さのボタンを表示すると CSS と HTML コードがあわせて表示されます。

・CSS クラス名
・背景色
・前景色

例えば、次のような角丸ボックスを簡単に作成することができます。

ウェブデザインサイト2
ウェブデザインサイト2 posted by (C) フォト蔵


このサイトは、角丸ボックスを簡単に作れるので便利です。


fonts(文字)

fonts カテゴリのトップには、9800 Free Fonts というサイトが登録されています。このサイトは、名前の通り 9800 もの無償でダウンロードできるフォントをダウンロードすることができるサイトです。

フォント名のアルファベット順でフォントのプレビューが見れるようになっていて、その場からすぐにダウンロードすることができます。
海外のサイトなので、日本語フォントが残念ですが、それにしてもいろいろな種類のフォントがあるものだなと思いました。


html

html カテゴリのトップには、Webmonkey|Reference: Special characters というサイトが登録されています。このサイトも名前のとおり、HTML の特殊文字一覧表があるサイトです。実は、僕もついさっき HTML の特殊文字を検索したところですが、このサイトですぐに分かります。

こんなにも HTML 特殊文字があるとは勉強になります。


icon(アイコン)

icon カテゴリのトップには、Free! Icons for your site というサイトが登録されていますが、現時点ではつながらなかったのでかわりにfamfamfam.com というサイトを紹介します。このサイトは、ウェブサイトでよく使われるアイコンを無料で提供してくれるサイトです。アイコンの数は少ないですが、ブラウザのボタンや国旗などとても分かりやすいアイコンをダウンロードすることができます。


images(イメージ)

images カテゴリのトップには、BLUE VERTIGO というサイトが登録されています。このサイトは、有料サイトですが高画質のイメージを早くお手頃な価格で入手できるサイトのようです。有料サイトなので、紹介はしないでおきたいと思います。


inspiration(ひらめき)

inspiration カテゴリのトップには、Zen Garden というサイトが登録されています。このサイトは、サイト自身の HTML とCSS をダウンロードできるサイトです。Zen Garden というサイトは左側に透過している背景があったり、右側にメニューがあったりと、とても美しいサイトです。

このサイトの CSS や HTML をベースにすれば、すぐに同じようなデザインを持ったウェブサイトを作れると思いました。


tutorials(チュートリアル)

tutorials カテゴリのトップには、lynda.com というサイトが登録されていますが、現時点ではつながらなかったのでかわりにその次の登録数が多い Dynamic Drive CSS Library を紹介します。このサイトは、CSS を使ってウェブサイトのメニューとして使えるさまざまな種類のメニューの CSS など詳しい解説が掲載されているサイトです。さまざまな種類のメニューから、自分のウェブサイトにあったメニューを選択するとよいと思いました。


widgets(ウィジェット)

widgets カテゴリのトップには、Lorem Ipsum というサイトが登録されています。このサイトは、印刷用のシンプルな段落をもった文章のサンプルを表示してくれるサイトのようです。

というわけで、今回はウェブデザインに不可欠なツールサイトを紹介しました。
今回紹介したサイトをツールボックスに入れると、次のようになります。

みなさんもそれぞれのカテゴリからデザイン用のウェブサイトを使ってみて、自分のツールボックスに登録してみてください。

ウェブデザインサイト3
ウェブデザインサイト3 posted by (C) フォト蔵


前回のエントリのデザインセンスの無い人がwebサイトを作成する際に参考にしているサイトとあわせて使うと、ウェブサイトをデザインするには、必須のツールとなりそうです。

2006年12月27日

1人のエンジニアがフォト蔵リニューアルを通して学んだこと(後編)
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

naoya です。
今回は、前回からかなり間が空いてしまいましたが、フォト蔵のリニューアルを通して学んだことの後編についてエントリします。

第三章:リニューアル直前

いよいよ、フォト蔵リニューアルまで、後一ヶ月となったところで、かなり厳しい状況になってきました。
そんな状況のため、フォト蔵チームで相談して、細かいバグフィックスは重要なものに絞って、チーム全員でリニューアルを仕上げることに方針を変更しました。
あわせて、harukさんkomagataさんが入社されたことも、当時はとても大きかったです。

これで、リニューアル直前(2006年10月頃)は、次のような人員体制に変更になりました。

・リーダー:1人
・デザイナー:1人
・エンジニア:5人(フォト蔵チームのエンジニア全員)

人員が増えたことにより、今まで僕が1人でやっていたロジックとビュー部分のコード変更をエンジニア5人で分業することにしました。
このころは、ほとんどデザイン部分の変更は終わっていたので、比較的分業しやすかったです。

基本的には、僕が一番フォト蔵のソースコードを理解していたという背景もあったので、ロジック部分は主に僕が変更するようにしました。ビュー部分については、それぞれのページごとに各エンジニアで変更してもらいました。このときのタスク管理には、BTSを使って BTS案件として、このページを作るという案件をたくさん作成しました。当時の、BTS案件の合計数が約150件近くありました。

このときに一番大きな問題となったのは、ロジック部分の変更による思わぬエンバグでした。リニューアル開始直後はかなり急ぎで変更していたため、所々コードが整理されていない部分があったのが原因でした。
このとき、時間をかけて最初にじっくりと自分が理解していないコードをしっかりと理解して、整理することが大事だと実感しました。最初に手を抜いても、結局最後には自分に返ってくることを、まさに体験した出来事と言えるでしょう。

こうして、いよいよリニューアルの直前となったのですが、大幅にデザインが切り替わるため、すでにフォト蔵を利用しているユーザが混乱しないように半月の試用期間を設けることにしました。

リニューアル開始時は、試用期間を設けるところまで考えていませんでしたが、念のため従来のデザインにすぐに戻せるコードにしておいたのが功を奏しました。
ウェブサイトのリニューアルの時には、必ず元のデザインに戻せるような仕組みは、必ず用意した方がいいと思います。
試用期間を設けることにあたり、急遽検討してもらう作業が発生したため、この作業はエンジニア1人に一任しました。

従来のデザインにすぐに戻せるようにはなっていたのですが、細かいところでいろいろな変更がありました。

こうして、いよいよフォト蔵をリニューアルすることになりました。


最終章:デザインリニューアル

こうして、11月1日フォト蔵のデザインリニューアルの試用期間を開始しました。
簡単にデザインリニューアルを試用してもらうため、切り替えボタンを押すだけですぐにデザインを切り替えられるようにしました。
また、フォト蔵コミュニティ専用トピックを設けました。
約半月の試用期間中に、たくさんのフォト蔵ユーザからフィードバックをいただきながら、試用期間中は主にデザインの調整や変更を重点的に行いました。


本当にたくさんのフィードバックをいただいたので、とてもやりがいのある仕事になりました。
今日現在も、たくさんのフォト蔵ユーザからフィードバックをいただいて、デザインの調整や機能追加などを行っている毎日です。
ウェブサービスを開発している醍醐味は、やはり使ってくださるユーザからフィードバックが来ることにつきると思います。


というわけで、二回に分けて僕が体験したウェブサイトのリニューアルを通じて、体験したこと、学んだことを書きました。


今後とも、フォト蔵をよろしくお願いいたします!

2006年11月14日

SBO(Social Bookmark Optimization)に関するほにゃらら
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

女性に愛されるプログラマーの7つの要素を見て、モテ系エンジニアになるためがんばってるKeitaです。

ラボブログでは、はてなブックマークの登録リンクと被ブックマーク数の表示をしています。 おかげさまで、一部のブログはかなりの数の被ブックマーク数を獲得しています。 しかし、私の書いた記事は残念ながら300を超えたことがありません。

それはそれで悔しいので、もちろん内容を充実するのが一番いい方法ではありますが、ちょっとしたコツで被ブックマーク数が増えるのではないかと思い、簡単ではありますが社内の人のアドバイスや統計情報を下にそのコツを洗い出してみようかと思います。

さて、このエントリに関する注意事項を先に何点かあげさせていただきます。

  • ウノウ社員は、はてブの件数ばかり気にしてるわけではありません。
    投稿したあと、リロード繰り返してしらべてるわけじゃありません。本当です。
  • 統計情報および内容は本物ですがネタです。
  • 仕事はちゃんとしてます。

まず、基本事項として社内の聞き込み調査の結果次のようなことに注意するといいという話を聞きました。

  • 注目を集めるようなタイトルをつける
    これは、内容が伴わなければ恥ずかしいだけになってしまうのですが重要な要素となるようです。
  • まとめ記事は人気がある
    まとめ記事系の被ブックマークは、人気が高いようです。 実はSBOとはまったく関係ないのですが僕個人としてはできるだけ、一次情報源になるように注意しています。自分オリジナルの内容で勝負することは大切だと思います。実際のところは、やはりまとめ記事などのほうが人気は高いようです。
  • 長文にする
    文章を長めにすると。[あとで読む]系のブックマークが増えるような気がします。

そのほかに、何が重要になるかなと、考えたときに投稿時間によっても、多少ブックマーク数が上下するのかなと考えました。 たとえば、投稿されたタイミングによって、はてなの注目エントリーに乗りやすいなどはきっとあるのではと予想してみました。

と、いうわけで、時間による統計をとってみました。

無料でここまでできる!OS毎のセキュリティ対策まとめの統計です。

sbo_graph_small.gif
[クリックで拡大]

意外と時間による差は小さく午前1時から6時くらいまでは静かで、その他はわりと万遍なく伸びている感じです。

それでも無理やり傾向を読み取ってみると、19時に記事を投稿してから最初のころは、RSSリーダー系にクロールされないためブックマーク数は比較的伸びが少なく、その日の23時~1時くらいまででちょこちょこっと伸びを見せます。 その後、午前中の9時~11時くらいまでが一番ブックマークされてます。

ということで、9時~11時の間にブックマークされることを見込んで、なおかつ、RSSリーダー系にクロールされる時間を見込み、前日の深夜もしくは8時前に投稿するのが望ましい形なのかもしれません。

ところで、ウノウでは社員を募集していますが、それとは別に僕も素敵な技術系に理解ある彼女を募集しています。

2006年11月11日

女性に愛されるプログラマーの7つの要素
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

Sashaです。

最近ウノウでは、独り身なプログラマーにどうやったら彼女が出来るか、そんな話題がなぜか流行ってます。

私から見れば、「男前なプログラマー」であることと、「女性に愛されるプログラマー」であることはちょっと違っていて、例えば、「男前なプログラマー」というのは、

・なんせ仕事がばりばりデキて、しかも早い!
・おいしい仕事じゃなくても責任感を持ってできる。
・技術の向上に常に余念がない。
・作り出したもの完成させるプライドを持っている。
・穏やかにチームワークが出来る。
・仕事のやり方に無駄がない。
・仕事にビジネスマインドがある。
・ありがとうがいえる。

と、こんな感じです。はっきり言って、ウノウのスーパープログラマーたちは全員そろいも揃って、「男前なプログラマー」の条件を超楽々クリアしています。

「男前」であることって、「彼女がいる・いない」ことよりはるかに大事だと思うんですが、それでも、やっぱり女の人にモテたいというのはグローバルな悩みなんですね、きっと。

そこで、ウノウ開発チームの紅一点のわたくし、「女性に愛されるプログラマーの、7つの要素」と題したこのエントリーを、愛すべき同僚たちへ捧げます!

一言断っておきますが、このリストは4人のウノウ・プログラマーに緊急インタビューした上で、そのインタビュー結果をまったく無視して私の独断と偏見でまとめたものです。なので謳っていることには実際の人物像はまったくからんでおりません。


人の目を見てほめることが出来る

人を褒めるというのは、プログラマーじゃなくても日本人男性一般的に苦手なのではないでしょうか。特に、プログラマーの肩書きを持つ人は一般的に気持ちを口頭で表現することが苦手な人たちです。だからこそ、職業に似合わず堂々と人を褒めることが出来るプログラマーは、女性を惹きつけるはず。たぶん。

アナログな趣味を持つ

ぜーんぜんプログラマーっぽくないのに、デキるプログラマーは、男性プログラマーから見てもかっこいいと聞きました。そのプログラマーっぽくない基準のひとつが、アナログマインドです。週に一回は、頭をスイッチして、アナログでものを考えて見ましょう。ノートに鉛筆で、誰にもブックマークされない日記を書いたり、フィルムカメラで写真を撮ってみたり・・・。このバランス感覚と意外性が、素敵だと思います。

スポーツを愛する

朝から晩までPCに向かっていて、体を動かさないプログラマーたちは、健康を損ないがちです。体の何処にも異常を感じなくても、歳以上に老けて見られる、というのは危険信号。若さを保つにはスポーツが一番です。どんな女の子だって、若々しい男性がいいに決まってます。ジムに通ったり、自転車や歩きで職場に行ったりするのもいいですね。女の子と、スキーやボード、テニスやゴルフが楽しめたら、一石二鳥ですね。

下手でも絵が描ける

アートなんて、そんな仰々しいものはよくわかりません。でも、見たままのもの、あるいは頭の中にあるものを、さらには心の中にあるものを描くことが出来るって、すごい魅力的。レストランでご飯を待っているときに、シャイなために無口になってしまったとしても、紙ナプキンに下手でも絵を描いてみたりして見たらいいかも。

おいしいものが好き・お料理好き

基本的に女の子は食いしん坊です。食いしん坊なんですけど、男性よりも食う!なんてことを認めたがらないのです。食べたいんですけど、一人で食べるって、つまんない。おいしいね!って言って、一緒に食事を楽しめる人っていいと思います。さらに、「女性は料理が作れるべきだ」という、日本の女性の多くが感じる「のしかかる期待」感を覆すような、料理好きもモテ値は高いと思います。さっそく、同僚の女性にご飯でも作って、本番に向けて腕を磨いておきましょうw

文章が上手である

ラブレターを書く、ということでは全くありません。文章をちゃんと書ける語彙のあるプログラマーは、仕事にも哲学があります。信念があります。なおかつ、上手な文章というのはもちろんわかりやすい文章ということでもあります。自分の職業や趣味の話を、「プログラマー=PCのことを知ってる人」という認識程度の女の子たちに説明してあげることを想定して普段から文章を書いていれば、合コンでついつい「正規表現」とか「デフォルト」とかNGワードを連発してしまう恐怖感も和らぐはずです。

お母さん、おばあちゃん思い

どんな女性も、歳をとります。とりたくないので一生懸命スポーツをして健康的な生活をしたとしても(してないけど)、それでもいつかはシワシワのおばあちゃんになります。お母さんに優しい人、おばあちゃんにやさしい人、というのは、女性に対して普遍の愛情を注ぐことのできる人で、絶対的な安心感を与えます。それに、お母さんとか、おばあちゃんとかって、一般的にプログラマーと趣味の世界(オタクな世界)を共有できる人種ではありません。そんな女性たちと話がちゃんと出来て、楽しませる、幸せにすることができるプログラマーは、絶対にモテるはず。家族の中の偉大な女性を、まずはハッピーにしてみましょう。

======
こうして今周りを見渡してみると、我が愛すべき同僚さんたち、みんないずれかの要素を持ち合わせている気がします。あ、ちなみに、一つでもカバーしていたら「愛される」条件クリアですね。ということは、あと必要なのは出会いと、気長に待つ余裕でしょうかね。

さて、えらそうに独断と偏見を堂々と会社のブログに投げた私は、「自分はどうなのさ」と突っ込まれないうちに、さっさと退散いたします。また次回!

2006年10月18日

すべてのWebデベロッパーに必須なFirefox拡張20(+1)選
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

naoyaです。
CyberKonowledgeに20 FireFox Extensions That Every Web Designer Should Know Aboutという記事がありました。ちょうど、タイムリーな記事だったので、さっそくすべてのFirefox拡張を試してみましたので紹介します。

Web Developer Toolbarは説明する間でもない定番でとても便利な拡張です。CSSのクラスが定義されている範囲をみたり、JavaScript/CSSをオフ/オンできたりととても便利です。



Gnu Aspellというスペルチェッカーを使ってすぐにスペルの確認ができる拡張です。使い方は、右クリックで表示されるコンテキストメニューからAspellを選択します。
この拡張は、最初ページ全体に対してスペルチェックができると思ったのですが、そうではなく単語を入力して単語のスペルをチェックする拡張でした。個人的には、あまり使わない拡張だと思いました。



SEOツールのようです。インストールすると、上部に専用のツールバーが表示されます。このツールバーからサーバのヘッダ情報を見たり、Alexaのランキングをすぐに表示することができます。たくさん機能があるのですべて試すことができませんでした。



IEViewと似ていますが、この拡張はOperaでページの表示を確認することができる拡張です。OperaもIEViewと同じように組み込みができるかと思って使ってみましたが、実際は普通にOperaを起動させて、Firefoxで表示していたページをOperaで表示しています。思っていた通りではありませんでしたが、Operaでの表示を確認したときに便利です。



この拡張は、IEでの表示を確認することができます。Firefoxのタブ上でIEのレンダリングに切り替えることができます。この拡張を使うと、ステータスバーのFirefoxアイコンをクリックするだけでIEに切り替えられるので便利です。



Total ValidatorというページのHTMLの文法をチェックするサービスを簡単に使うための拡張です。Total Validatorをインストールすると、ステータスバーにアイコンが表示されるので、そのアイコンをクリックするだけで今表示しているページをチェックすることができます。ただし、ログインが必要なページはチェックできません。このようなときは、後で紹介するHtml Validatorがすごく便利です。



このツールも別のページで知ったのですが、かなり便利です。GoogleやYahooで検索したときの検索結果画面に検索結果順序のデータ(Googleだとページランクに相当します)がまとめて表示されます。デフォルトではかなりのデータが表示されるので、表示する項目を絞った方がいいと思います。また、デフォルトだとデータが表示されないのでクリックするか、設定を変更して自動的に表示するようにした方がいいでしょう。



HttpLiveHeaderも定番です。HTTPの通信ヘッダ情報をチェックすることができる拡張ですね。初めて使う場合にちょっと注意したいのは、HTTPLiveHeaderの画面を開いている状態でページを読み込まないとHTTPヘッダ情報が表示されませんところです。



Firefoxから好きなエディタを登録しておいて、右クリックメニューから登録したエディタを選択してCSSやHTMLなどを好きなエディタで開くことができます。Cyber Knowledgeでは、IE7を登録していますが、いくつかブラウザを登録しておければIEViewやOperaViewと同じ機能にすることができるので便利です。



僕が普段から使っている拡張です。ステータスバーのアイコンをクリックするだけですぐにブログに投稿できる拡張です。僕は、ブログを二つ書いているのですが、一つは技術系、もう一つはもっと簡単な内容のブログを書いているのですが、Performancingでこの二つのブログを登録しておいて、それぞれのブログに投稿しています。あと、コンテキストメニューからこのページのリンクを張ってすぐにブログに書けるのも便利ですね。



コンテキストメニューからリファラーを送らずにページを開くことができる拡張です。たまにリファラーを送りたくないときにブラウザ自体の設定を変更せずにすぐにできるので 便利です。



ページの表示時間を計測することができる拡張です。この拡張をインストールすると、上部のステータスバーにページの表示時間を表示することができます。個人的にはステータスバーに表示されるのがよかったのですが、仕方ないですね。Webアプリケーションでは、ページの表示時間が常に重要になるので重宝しそうな拡張です。



User Agent(UA)を変更することができる拡張です。僕は、上部のツールバーにUser Agent Switcherアイコンを追加して必要なときに切り替えています。 ウノウでは、最近VPOPという携帯電話専用の動画共有サイトを始めたのですが、この開発のときにはよくUser Agent Switcherで携帯電話のUser Agentに切り替えるために使っていたようです。



この拡張も定番ですが、かなり便利です。サイドバーのEditCSSのCSSを編集するとリアルタイムにCSSの変更を確認することができます。この拡張を使うことで、CSSを変更する度にブラウザをリロードすることがなくなります。EditCSSで編集した内容は、ファイルとして保存できます。



この拡張も定番です。JavaScriptやCSSを含んだコードをデバッグできます。僕は、Ajaxを使ったページのデバッグをするときによくFireBugを使っています。



ページのサイズを測定できる拡張です。MeasureItをインストールすると、左下のステータスバーにアイコンが表示されるので、このアイコンをクリックするとページのサイズを測ることができます。この拡張も便利です。



FirefoxをFTPクライアントにすることができる拡張です。作成したページをアップロードするときに便利です。ウノウでは、FTPは使っていないので実際に使う機会はなさそうです。



ページの色情報を取得することができる拡張です。この拡張もMeasureItと同様にインストールするとステータスバーの左下にアイコンが表示されるので、アイコンをクリックして色情報を取得することができます。



この拡張は、ページ内で選択されたテキストの内容でHTMLリンクの内容でコピーすることができます。たとえば、前回のテスト番長のブログの一部をCopy as HTML Linkすると次のようなコードとしてクリップボードにコピーされます。

テスターさんを募集

シンプルでかつとても便利な拡張です。


いかがでした?今日は、Webデベロッパーに必須の20のFirefox拡張を紹介しました。
最後に、Cyber Knowledge には紹介されていなかったWebデベロッパーに必須の一つのFirefox拡張を紹介します。

HTML Validatorは、Total Validatorと似ているのですが表示しているページのHTMLの文法チェックをしてくれるので、ログインが必要なページでもすぐに文法のチェック結果をステータスバーで確認することができます。 HTML Validatorを使うと、常にページの文法チェックができるのでかなり重宝しています。

2006年10月 6日

Services_TechnoratiでTechonoratiを使い倒そう
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

はじめまして.新入社員のjokagiです.ウノウ株式会社に入社して丁度1週間のまだ右も左も分からない新入社員です.よろしくお願いいたします.

さてみなさまよくご存じ(?)当番制のウノウラボですが,今日が私が当番だということに夕方気づいたので!!さっきネタを作りました. というか当番とかいうわりに日付が変わってしまいましたがみなさま気にせず興味のある方だけ生ぬるく読んでください.

続きを読む "Services_TechnoratiでTechonoratiを使い倒そう" »

2006年9月28日

使いやすいハードウェア環境を目指して
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

naoya です。
今まで、ウノウラボでは使いやすいソフトウェアを多数紹介されています。対して、使いやすいハードウェアを紹介する機会はほとんどなかったと思います。
今日は、僕がこれまでやってきた使いやすいハードウェア環境を紹介します。

ノートパソコン

ウノウでは、基本的にノートパソコンで作業するため、ノートパソコン選びがとても重要な要素です。 僕はノートパソコンを選ぶときは、キーボードが打ちやすいかどうかを重視しているので、ThinkPad x60 を使っています。ThinkPad x60 のキーボードタイピングは、、ThinkPad x2x の頃に比べると若干悪くなっていますが、それでもノートパソコンの中では一番のキーボードタイピングがいいノートパソコンだと思います。 ウノウではさまざまなノートパソコンを使っていますが、中にはノートパソコンから別の USB キーボード(Happy Hacking Keyboard)を接続して使っている強者もいます。 ただし、最近 Mac もはやっているので、難しい選択です。個人的には、ハードウェア面からみると ThinkPad、ソフトウェア面からみると Mac という感じがしています。

マウス

僕はずっとマウスは ThinkPad x60 のトラックポイントを使い続けていましたが、たまに手がつかれることがあったので、思い切って別のマウスを購入してみました。マウスは、最近発売されたロジクールの VX Revolution を選択しました。店頭でさわった感じだと、デスクトップ用の MX Revolution の方がよかったのですが、ノートパソコンを使っているのでノートパソコン用のマウスを選択しました。 さらに、ロジクールのマウスユーティソフトウェアを導入して、デフォルト設定から中央のスクロールボタンを押したときのアクションと OS 側のマウス設定に、マウスの Search ボタンを Document Flip というウィンドウを簡単に切り替えられる機能を使うように設定を変更しました。

冷却クーラー

ThinkPad x60 は、デュアルコアプロセッサのためか使い続けているとキーボード全体がけっこう暑くなります。キーボードが暑くなってしまうと、手に汗をかきながら作業することになってしまうのでノートパソコン用の冷却クーラーを購入しました。今使っている冷却ーラーは、ロアス PCF-001 というものですが、今では生産中止になっています。ですので、他のメーカーのものでも十分ですが、選ぶときに注意したいのはファンの速度が二種類から選択できるようになっているものを選択した方がいいです。そうでないと、けっこうファンの音が気になります。 冷却クーラーを導入すると、ノートパソコンを背面から冷やしてくれるのでキーボード全体がそんなに暑くならず、さらにキーボードが傾くので、二つの改善効果がでました。

あとは、最近ウノウで導入されたマルチモニターも使うことで、なかなかの使いやすいハードウェア環境ができたと思います。

これからも、使いやすいハードウェアとソフトウェアの組み合わせを追求して、作業環境を日々改善していきたいですね。

2006年8月23日

探し物はなんですか?
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

こんにちわ。sashaです。IA(Information Architecture)にはいつも興味を持っていて、専門学校でも特別コースを取ったりしてみました。

普段、私たちがウェブを駆け巡るとき、絶対に無意識のうちに、「探し物を見つける」というゴールを掲げているものです(結構自信持って言い切っちゃいます)。さて、ではどのような方法で、このゴールに到達しているのでしょうか。次の記事では、「情報を探す」とはどういうことなのか、そのために、どのようなデザインが可能なのかを考えています。

情報探しの4つのモードとそれぞれのモードのためのデザイン方法


1. 探してるものを知ってる系

例えばこんなとき:

  • 何が知りたいかを知っている
  • 自分が探したいものが、なんと呼ばれているかがわかっている
  • どこから探して行ったらいいかがなんとなくわかっている

それは例えば、PHPのとある関数の使い方を調べようとしているときだったり、映画生活でスーパーマンのレビューを読みたいときだったり。

そんなのときに役に立つ問題解決方法としては、以下のような例があります。

  • サーチ - 検索されたキーワードを、文脈や正確な要約の中で示す。エンジンと、結果の中から探したいものを見つける、簡単な読解力を利用
  • 「A-Z」 あるいは 「あいうえお」順インデックス - 知っている言葉をスポットする。文化の中でしみこんだ、音声言語的な知識体系を利用
  • クイックリンク - 頻度の高い機能へは、一目でわかるリンクで直行!視覚と、機能の重要性の認識を利用
  • ナビゲーション - 探したいもののキーワードと関連する言葉をたどる。人間の知能に既に組み込まれている、概念言語的な知識体制を利用

もちろん、知りたい情報がどれだけスムースに探すことができるかは、どのようにこれらの解決方法となる捜索ツールを作るかにかかってくるのです。

2. 探し物はなんとなくわかってくるでしょう系

例えばこんなとき :

  • 何が知りたいかは大体わかっているのだけど、なんて表現していいのかわからない
  • 知りたいものズバリそのものの用語がわからない・忘れた
  • どこから探したらいいのかがよくわからない
  • でももし探しているものを見つけたときは「これを探していたのよ!」と思う

たとえば、自分の好きそうな音楽を探していたり、エリンギを使った手ごろな料理のレシピを探していたりするときは、これですよね。

そんなときのアプローチとしては :

  • ナビゲーション - ナビゲーションをたどりながら、広く、深く、ユーザーは導かれ、学び、発見します。
  • 関連情報 - タグ、他のユーザーからの関連情報、情報提供側からの関連情報など。
  • サーチ - 探したいものズバリを表す言葉で検索することが出来なくても、類語を知っていたり、関連する言葉を知っているときには、このアプローチも有効です。

この系統の探し物へのアプローチでは、ユーザーに「探検する」余地を与えてあげることが重要ですが、同時に、「探検する」ことによって、目標としている情報により近づいて行っている実感を与えてあげることが重要です。近頃の探検家は諦めがめちゃ早いですから。

3. 何探しているのかわからない系

例えばこんなとき:

  • 資料などを目を通さないといけないとき
  • 新しいウェブサイトやウェブサービスを試しに使ってみているとき
  • 世の中でなにが起こっているか気になるとき
  • ネタやインスピレーションを探しているとき

この探し方には次のようなアプローチが必要です

  • シンプルで把握しやすい要約、アウトライン、需要な項目リスト、目次、サムネイルなどなど
  • 具体的で深いコンテンツ

必然的に、見せ方より実際のコンテンツ部分の重要性が倍増しますよね。

4. もう一度見つけ出したい系

例えばこんなとき:

  • どのサイトの、どこにあったか覚えているかもしれない
  • どのサイトの、どこにあったか、まるで覚えてないかもしれない
  • なんとなくの見た目だったら覚えているかもしれない

こういった探し物をお手伝いするには、二つのアプローチの仕方があります

* 主体的なアプローチ


など、ユーザーがあえて自分でクリックすることによって、あとで欲しいものをすぐに見つけられるようにするアプローチが一つと、

* 能動的なアプローチ


の様に、ユーザーがそのURLをそのまま記録しておくためのアクションを特別に起こさなくても、欲しい情報を分類、ソートしてくれるタイプのアプローチです。

まとめ

いかがですか?あなたがウェブサイトを見るときは、これらの4つの探し方モードを満遍なく常に実行していますよね。あなたのサイトに来る、ユーザーさんたちも、これらのどの探し方で、あなたのサイトにたどり着いたのでしょう。その人たちは、探し物を見つけることは出来たでしょうか?

大事なのは、ユーザーがどのモードでもって必要な情報をあなたのサイトで見つけるか、を見極めることではありません。大事なことは、複数の探し物モードが存在することを認識して、それぞれに適した解決法を用意してあげるということです。

探し物を見つける、というゴールだけを考えて、一度あなたのサイトを見直してみるのもいいかもしれませんね。

2006年8月15日

作曲とプログラミング
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

こんにちは、ケンジです。
今回は、作曲とプログラミングについて思うことを書いてみようと思います。

音楽を専門としない一般的な人たちの多くにとっての「音楽」というと、拍子や調性などがある程度ハッキリしていて分かりやすいものになる事かと思います。そういった範囲での作曲というと、大体において過去に作られてきた数多くの楽曲の中に同様の要素が多く存在するわけです。調性というある程度の枠の中に入っているということ自体もそうですし、リズムや音階だってそうです。そういう意味で、プログラミング作業と似ていると思うのです。

作曲は、英語でComposeですね。組立てる, 構成するといった意味合いです。既に世に存在している様々な音楽的要素を組み合わせ1つの流れを作っていく、そんなイメージでしょうか。対してプログラミングは、使用する言語がまずあって、そこで用意されている関数や、前人が作ったライブラリ等を組み合わせ処理を完成させていきます。ここだけ見れば作曲とプログラミングは非常に似通った事をやっているな、と感じたわけです。

ですが決定的に違う部分はあります。作曲するという作業においては、出来上がった楽曲にオリジナリティや美しさといったものが求められます。プログラミングの場合は効率的で見通しの良いコードが求められる事でしょう。同じような処理の為に書かれるコードは、洗練されればされるほど同じようなコードに収束していくという事です。そこには突飛な事やサプライズ、オリジナリティというようなものは求められません。過程は似ているのに求める結果が違うのですね。勿論、プログラミングにも美しさは求められますが。

作曲するという事を極める事は、これまで使用されてきた数多くの音楽的要素を思いのままに操り、時には全く新しい価値観で音楽的要素そのものを作り出し、音楽を作り上げるという事。プログラミングで言えば、思いのままに言語を操り素晴らしいシステムやサービスを作ったり、全く新しいアルゴリズムを考え出したりというような事でしょう。そういった前人未到な仕組みを作ってしまう技術者は本当にクリエイティブで、ある意味アーティストと言えるのではないかと思うのです。

で、何が言いたいのかというと、僕はアーティスティックな人間に憧れます。
ウノウには素晴らしいアーティストが多数いるので刺激的です。

ところで、音楽表現の為のプログラミング言語というものもあります。勉強してみようかな。

2006年8月 4日

ウノウってこんな会社です
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

こんにちわ!今週からウノウの一員になりました hide です。

今日で入社4日目とまだ日も浅く、ウノウならではの開発/運用Tipsなどの内容は書けないので、ウノウがどういう会社なのかを新人の視点から紹介します。


1. 凄いハッカーが周りに沢山いる

何気なく座った席の向かいが、日本語プログラミング言語「なでしこ」「葵」の開発者でした。他にもIPA未踏ユース出身の人やPEARパッケージのメンテナをしている人もいます。最近では、Scheme使いも加わりました。

2. フリーアドレスで、毎日違う場所に座らなければならない

席は自由で早い者勝ち。毎日違う場所に座らなければならないため、すぐに仲良くなれます。片付けてから帰るので、必然的に机の上がキレイになるという効果もあります。

3. 朝は10時始業で、無理な残業はなし

基本的に朝のスタートはゆっくりめ。10時にメンバが揃っていないことも多々あります。また、これが驚きなのですが、21時にはほぼ全員が帰宅してしまいます。これ重要だと思います。やっぱり、いい仕事をするには短期集中型でないと。

4. BTSにあがってきた案件を凄い勢いで片付けていく

基本的な仕事の流れは、社内で動いているBTSにあがってきた案件を各担当が片付けていきます。修正してSubversionにコミットすると、やまもと@テスト番長が厳しくチェックしてくれます。

5. 週一でXPの時間がある

二人一組で、あーだこーだ言いながら開発を行います。いわゆるペアプログラミング。

6. 2ヶ月に1度、2泊3日の開発合宿がある

まだ参加したことはないのですが、自由参加で7割くらいの社員が参加するそうです。無線LANが使えて温泉付きの宿が条件だとか。

7. ダイエットしている人が多い

なぜか分かりませんが、男性でダイエットしている人が多いです。お昼ご飯の時など、カロリーや炭水化物の量をとても気にします。自分も最近、お腹が軽くやぱいのでよい刺激になってます。



と、こんな感じで、インターネットとオープンソースが好きな開発者にとっては、なかなかの環境ではないでしょうか。まだまだ人材を募集しているようなので、我こそはと思う方は一緒に仕事しましょう!

# 次回は、ちゃんと技術的なネタを書きますね。

2006年7月20日

The Joel Test
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

こんばんは、naoya です。
今年の初めに Joel on Software 日本語版が出版されました。その本の中でソフトウェアチームの良さを計測するためのシステムとして、Joel 氏はジョエルテスト (The Joel Test) を書かれています。
今日は、まだ入社して2週間しかたっていない新人の naoya がウノウでの取り組みをジョエルテストにかけてみたいと思います。

1. ソースコード管理してる?

もちろんです!ウノウでは、svn を使ってソースコード管理しています。

2. ワンステップでビルドできる?

ウノウで開発しているウェブサービスは、すべて php ですのでビルドするという概念がありませんが、クイック POPFile のようなパッケージ製品はインストーラまでを含めてワンステップでビルドできるようになっています。クイック POPFile では、バッチファイルを使って簡単にワンステップでビルドできるようになっています。

3. デイリービルドしている?

ウノウで開発しているウェブサービスは、デイリーというか常に更新されていますので、サービス内部でエラーが発生した場合は、すぐに社内の関係者にメールが送られてすぐに修正するとい う体制をとっています。

4. バグデータベースはある?

もちろん、あります。ウノウでは、いまのところ影舞 を使っていますが、今は Trac に移行中です。

5. 新しいコードを書く前にバグを直している?

はい、ウノウではバグを優先して直しています。新しいコードの案件と不具合の案件は、すべてバグトラッキングシステムに集約されて、バグを優先的に担当者に割り当てて修正しています。

6. アップデートされているスケジュールはある?

もちろん、あります。アップデートされたスケジュールは、すべて wiki にまとまっています。

7. 仕様書はある?

もちろん、あります。仕様書もすべて wiki にまとまっているのですが、ウェブサービスの仕様書は詳細な仕様書ではなく、基本的な機能、コンセプトがまとまっています。

8. プログラマは静かな環境で作業している?

はい、とても静かな環境で作業しています。僕がウノウへ入社して、一番驚いたのは作業環境の静かさでした。

9. 手に入る最高のツールを使っている?

はい、最高のツールを使っていると思います。ウノウは、社員13名という小さな会社のためすぐに新しいツールがあったら、みんなに紹介してさっそく導入しようという姿勢が強いです。

10. テスタはいる?

はい、います。ウノウには、やまもと@テスト番長さんがいます。 ウノウで開発しているウェブサービスやアプリケーションは、すべてやまもと@テスト番長さんの確認をもって、アップデートされます。

11. 採用試験のときにコードを書かせている?

はい、僕が面接をうけたときもコードを書く試験がありました。
今は、コードを書く面接とあわせてエンジニアリングの基礎知識のテストもしているようです。

12. ユーザビリティテストはしてる?

これは難しい質問ですが、ウノウではウェブサービスの開発のとき、みんなで使いにくいところを徹底的に話しあってユーザビリティをよくしようと努力しています。また、それぞれのサービスには専用のブログを設けて、日頃から要望を取り入れています。


今日は簡単でしたが、ジョエルテストからウノウの取り組みを書いてみました。
実は、ジョエルテストは社内で盛り上がり別な話題に発展していったのですが、それは次回のエントリで書く予定ですので、お楽しみに!

2006年5月25日

怪力「Poderosa」
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

こんにちは、ケンジです。

今回は、多くのエンジニアが愛用しているSSHクライアント「Poderosa」について。ウノウの社員も皆使っています。

Poderosaという名前はこちらでも紹介されているように、キューバのゲリラ指導者であるチェ・ゲバラが医学生時代に南米旅行した際に乗っていたバイクの名前からとったそうです。もともと作者の岡嶋大介氏がゲバラのファンだそうで、初期のころはゲバラという名前で公開していたそうです。

「Poderosa」とはスペイン語で、「力強い」といった意味です。チェ・ゲバラの旅行記を映画化した「モーターサイクル・ダイアリーズ」の字幕では「怪力号」と訳されています。

さて、ここからは映画に沿ってお話します。(実際のお話から多少脚色されている可能性もあります。ほぼゲバラ本人の原作通りかと思いますが。読んでないので分からない)
この「Poderosa号」、ゲバラの親友アルベルド所有のバイクなんですが、実はかなりポンコツです。旅立ちのシーンからエンジンかけるのに少してこずります。それでいて、全然「怪力」さを発揮しません。馬に抜かれます。途中何度もこけて何度も修理しますが、最後には廃車に。そこからはアンデス山脈越えちゃったりするのも徒歩やヒッチハイクです。凄いお話です。

ですが、この「Poderosa」、若きゲバラの人生観を大きく変えた冒険旅行、旅立ち最初の重要な足だったわけです。これ無しに、のちのチェ・ゲバラは存在しなかったかもしれません。SSHクライアント「Poderosa」は全然ポンコツでもなく、非常に高機能・快適なソフトウェアですが、この「重要な足」という点では同じですね。

「怪力号」でサーバーに旅立ってますか?目指せIT界のチェ・ゲバラ!?

・Windows 用高機能ターミナルエミュレータ「Poderosa
モーターサイクル・ダイアリーズ@映画生活
Wikipedia::チェ・ゲバラ

2006年5月 9日

vi をマスターするにはダンスダンスレボリューションをマスターすべし!!
このエントリーをブックマークに追加 このエントリーをlivedoorクリップに追加

スーパーなエンジニア見習いの尾藤正人です。

最近アルバイトに来ている学生がダンスダンスレボリューション(以下DDR)にはまっているというのが発覚しました。
DDRと聞いて僕が真っ先に思い浮かべるのがUNIX系OSで広く使われているテキストエディタ"vi"です。

実はDDRとviには関係性があって、僕はDDRが登場した頃(当時純粋な大学生だった頃ですから5,6年ぐらい前でしょうか)に気づきました。
この事実に気づいている人が世の中にどれくらいいるのかと思っていろいろ検索したんだけど、全然見つからない!!
もしかしたら気づいているのは僕だけかも。かなり時代の最先端を行ってるんじゃないかとふと思いましたが、冷静になって考えてみるとDDR自体が既に時代遅れだったというオチ。

その衝撃の事実は何かというとこれです。

viでカーソルの移動に使うh, i, j, kの並びはDDRの矢印の並びと同じである

トリビア~

viでカーソルキーを使ってる人はまずはDDRをマスターすべし!!
h, j, k, lの並びが自然に認識できるようになるはず!!


ところで激しくうろ覚えなのですが、viでカーソルの移動に使うキーがh, j, k, lの並びになったのは、当時カーソルキーのなかったキーボードでカーソルの移動に使ったいたキーと同じにしたからというのをどこかで見た記憶があります。
この辺の正確な情報ありましたらぜひ教えてください!!


h, j, k, lの並びはもしかしたら人間工学的に最適な並びなのかもしれない。
逆にqwertyのように人間工学的にわざとうちにくい並びにしてるのかもしれない。

DDRの矢印の並びがなぜあのようになったのか、開発者の方に聞いてみたい。
もしかしたらviのファンなのかも。いや、そうに違いない。

  [PR] 転職


About ネタ

ブログ「ウノウラボ Unoh Labs」のカテゴリ「ネタ」に投稿されたすべてのエントリーのアーカイブのページです。過去のものから新しいものへ順番に並んでいます。

前のカテゴリはデモサイトです。

次のカテゴリはレポートです。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

ウノウサービス