深追い Fukaoi.org

JettyをPort80で起動する方法

Thu, 11 Mar 2010 14:57:33 +0900

JettyはTomcatと比べて、ファイルサイズも小さく、起動が早いので最近、僕のお気にいりのWebサーバ兼サーブレットコンテナなんですが、困った点が１つあります。デフォルトPortは8080なんですが、Portを80に変更して運用するには管理者権限(root)が必要になってしまうようです。一般Shellユーザー(例えばjettyとかユーザーを作成した場合)でPort：80で試してみましたところ、起動はできるんですが途中でExceptionを吐いてコケテしまいます。
本来はApacheのように実行権限のないnologinのWebサーバ用ユーザー(daemon、 nobody...)で起動するのが理想です。というかセキュリティ面を考えると当たり前だと思うんですよね。管理者権限(root)、一般ShellユーザーでJettyを起動してサービスを運用したくない。万が一JettyにBugがあった場合、バッファーオーバーフローをつかれて、権限を奪取されサーバ内に侵入されてしまうわけですから。そこで JettyをPort：80でnologinユーザー(実行権限の無い)で起動する方法をまとめてみました。下記のJettyのFAQページを参考にしました。

http://docs.codehaus.org/display/JETTY/port80
(※)Jetty7や他のバージョンでは試していないので同じ方法かどうかはご注意

今回使用したミドルウェア情報・補助情報

[ミドルウェア]
OS    ：2.6.31-17-generic(Ubuntu、CentOS)
Jetty ：6.1.22(STABLE)
Java  ：1.6.0_15(OpenJDK) 

[補助用語]
$JETTY_HOME  ：Jettyのソースを設置したディレクトリ
$JAVA_HOME   ：Java SDKをインストールしたディレクトリ
               (コンパイルが発生するのJava Runtimeだけでは駄目かも)

導入方法は次の2パターンが有ります

(1)：一般ShellューザでPort:8080で起動してOSの機能である、
ipchains、iptablesを使って、Port:80へのリクエストを8080へフォワードする

(2)：JNIを使って、Nativeライブラリを起動時に読み込みnologinユーザーにsetuid (and setumask)を行う

(1)：iptables、ipchainsを使用して実現する方法

iptables

/sbin/iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT \
--to-port 8080

ipchains

/sbin/ipchains -I input --proto TCP --dport 80 -j REDIRECT 8080

(2)：nologinユーザーにsetuidを使用して実現する方法

setuidのNativeライブラリをJettyにあてるために解凍したJettyのソースに移動する

cd $JETTY_HOME/extras/setuid

(a)：Mavenを使ってNativeライブラリ(org_mortbay_setuid_SetUID.c)をインストールする場合
```
$JETTY_HOME/extras/setuid配下にMavenの設定ファイル(pom.xml)があるので、
mvn installを実行する
```
(b)：手動でNativeライブラリ(org_mortbay_setuid_SetUID.c)をインストールする場合

mkdir -p modules/native/target/generated

cp modules/native/src/main/native/org_mortbay_setuid_SetUID.c \ 
   modules/native/target/generated  

javah -d modules/native/target/generated \
      -classpath modules/java/target/jetty-setuid-java-6.1.22.jar \ 
      org.mortbay.setuid.SetUID

gcc -I$JAVA_HOME/include/ \
    -I$JAVA_HOME/include/linux/  \
    -shared \
     modules/native/target/generated/org_mortbay_setuid_SetUID.c -o \
     ../../lib/ext/libsetuid.so

libsetuid.soファイルができているか確認する

ls $JETTY_HOME/lib/ext/libsetuid.so

ただし、何故かJetty6.1.22のバージョンでは解凍した段階でlibsetuid.soも同梱されていた・・・どの環境によるコンパイルか不明のため、自分でコンパイルは行った方がよいと思います

Jettyを実行させたいnologinユーザのユーザーIDとグループIDを設定ファイルに指定する

$JETTY_HOME/etc/jetty-setuid.xml

nobodyユーザーのuid、gidに修正する

<Configure id="Server" class="org.mortbay.setuid.SetUIDServer">
 <Set name="startServerAsPrivileged">false</Set>
 <Set name="umask">2</Set>
 <Set name="uid">jetty</Set> (変更)=> <Set name="uid">6553</Set>
 <Set name="gid">jetty</Set> (変更)=> <Set name="gid">6553</Set>

 <!--↑↑uid、gidの値をjettyから6553に変更する↑↑-->

jetty.xmlのPort指定箇所を8080から80に変更する

<Call name="addConnector">
 <Arg>
  <New class="org.mortbay.jetty.nio.SelectChannelConnector">
  <Set name="host"><SystemProperty name="jetty.host" /></Set>
  <Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set>

  <!--↑↑defaultの値を8080から80に変更する↑↑-->

  <Set name="maxIdleTime">30000</Set>
  <Set name="Acceptors">2</Set>
  <Set name="statsOn">false</Set>
  <Set name="confidentialPort">8443</Set>
  <Set name="lowResourcesConnections">5000</Set>
  <Set name="lowResourcesMaxIdleTime">5000</Set>
  </New>
 </Arg>
</Call>

jetty-setuid.xmlを指定して、Jettyを起動させる

$JAVA_HOME/bin/java -jar $JETTY_HOME/start.jar \ 
                         $JETTY_HOME/etc/jetty-setuid.xml \
                         $JETTY_HOME/etc/jetty.xml

この時の注意点として、読み込ませる設定ファイルの中で、jetty-setuid.xmlを一番最初に指定すること。指定順番が大事です

設定、コンパイルが上手くいかない場合

java.net.SocketException: Permission denied
    at sun.nio.ch.Net.bind(Native Method)
    at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119)
    at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)

Permission deniedで一般ユーザーでは権限がないというメッセージがでて起動途中でとまってしまいます。この場合は設定ファイル、コンパイル内容などを疑ってください

結論

(1)のほうが、Jettyのソースを変更することなく、Port：80で起動を可能にしますし、お手軽だと思います。ですがPortフォワードというOSの機能を使って実現するあたりが、スマートではないように思います。リクエストのたびにOSに多少なりともフォワード負荷が余計にかかる事が、本来ならアプリケーション処理に割り当てられるはずの、サーバのリソースを無駄に消費している感がなんとも損した気持ちになってしまいます。実際Portフォワードでサーバが消費するリソースは微々たるものだと思いますが・・・。なにより一般Shellユーザーで結局はPort：8080で起動しないといけないので、セキュリティ的な不安は残ってしまいます。
やはり個人的には(2)がベストだと思います、GCCによるコンパイルなど、ちょっと面倒ではありますが、 Mavenがインストールされている環境であれば、ワンステップで処理が完了するので、そこまで苦にはならないだろうし、nologinのWebサーバ用ユーザーで実行するので、通常のApacheとかの起動内容と同じになりますので、実行ユーザーに関する点のセキュリティ的リスクは限りなく低くなると思います。

関連リンク
civic site » Jettyサーバを使ってみる

いまさらながらPHP_EOL定数と改行コードについて

Mon, 4 Jan 2010 20:42:29 +0900

PHPには、Linux、Mac、Windowsなどの異なるOS環境間で改行コードを内部的に自動で切り替えてくれるPHP_EOLという便利な定数が用意されている。Javaでの実装だとSystem.getProperty("line.separator")にあたると思う。PHP_EOLがPHPの内部ではどのように実装されているのか、いまさらながらPHP_EOLと改行コードについて書いてみた。

PHP_EOLが定義されているソースファイルをリーディングする

リーディングするソースコードのPHPバージョンはphp-5.3.1を使う。PHP_EOLの定義箇所は以下のヘッダファイルにあり、PHP_EOL以外の定義済み定数の大半もこのファイルで定義されている。

php-5.3.1/main/php.h の Line47 ～ 71あたり

＃ifdef PHP_WIN32         

  ＃include "tsrm_win32.h"
    ・
    ・
  ＃define PHP_EOL "\r\n"
   // (OSがWindowsの場合に改行コードが\r\nになる)

＃else
    ・ 
    ・ 
 ＃if defined(__MacOSX__) 
   // ※__MacOSX__このマクロはMacOS10では使われてない
   //   らしい。なのでここの条件分岐にMacOS10は入らない

   ＃define PHP_EOL "\r" 
    // (OSがMacOS9以前の場合に改行コードが\rになる) 

 ＃else

   ＃define PHP_EOL "\n" 
    // (OSがMacOS10、Linux、Unixなどの場合に\nになる) 

 ＃endif

＃endif

このように、OS環境によって、if文で条件分岐し改行コードの文字表現を\r\n、\r、\nとdefineしているシンプルなソースコードである。わかりやすいように一覧表にまとめてみると以下の関係になり、ネットでも検索すれば同じような一覧内容は確認できる。

各OS環境でPHP_EOLが出力する改行コードをASCIIコードで確認してみる

改行コードを標準出力しても分かりずらいので、PHPのord()関数をつかいASCIIコードに変換して出力してみたいと思う。(※Mac環境がないので、Linux、Windows環境のみで)

以下にASCIIコード一覧の抜粋があるが、そこにある太字のASCIIコードが返ってくることが予想できる。ここで問題なのがWindows環境であるCRLF(\r\n)である。そもそもCRLFというASCII文字は存在していない。いったいどのような値がかえるのか？

コマンドラインでスクリプトを実行した結果

下記、改行コードを生成するコマンドをOS環境を変えてコマンドラインから実行していってみる。またOS環境における差異を明確化させるために、strlen()関数で出力される改行コードの長さも測った。下記が結果内容である。

php -r 'echo ord(PHP_EOL);'  (改行コードをASCIIコードで出力)

Linux環境で実行した際の結果値：10

Windows環境で実行した際の結果値：13

php -r 'echo strlen(PHP_EOL);'  (改行コードの長さを出力)

Linux環境で実行した際の結果値：1

Windows環境で実行した際の結果値：2

これらの結果から、疑問であったWindows環境における改行コードのASCIIコードの値は13と出力された。ASCIIコード一覧と照らしてみると、13 = CR = \rになる。このような値が返ってきたのはCRLF自身が、ASCIIコードのCR(\r)とLF(\n)を並べて表現しているからである。現にstrlen()関数で長さを取得するとWindows環境(CRLF)では2という値がかえり、2byteの文字列であることがわかる。そのためord()関数にPHP_EOL定数がPHP内部でOS環境を判定して、\r\nをセットしても、先頭1byteの\r = 13が返ってくるというわけである。これはord()関数の異常というわけでなく、正常動作であった。

関連リンク
2038年問題とPHP_EOL
PHPでの改行

MySQLのUDF関数を作った－アルファベットの文字列をひらがな順にソートする

Sun, 14 Jun 2009 16:02:38 +0900

MySQLのUDF（ユーザ定義関数）機能を使い、アルファベットの文字列をひらがな順にソートするオリジナル関数を作成してみた。このUDF関数はアルファベットの文字列データが含まれるMySQLのデータカラムに対して、日本語固有のひらがな順にソートを可能にする。漢字、ひらがなで登録された2byte文字列データであれば、MySQL自身が内部で持っている辞書データによりひらがなソートが可能なのだが、アルファベットの文字列データをソートしようとした場合は英語固有のアルファベット順ソートになってしまう。そこで今回作成した関数（alpha_to_hiragana関数と命名）内部において、アルファベットの文字列に対して、ひらがな順にソートできるように、ひらがな順にデータの重みづけの内部変換を行い、ひらがなソートを実現した。alpha_to_hiragana関数の開発ポイントを今回記述してみたいと思う。

そもそものUDF関数の実装方法を知りたい方は、下記の関連リンク先サイトがわかりやすいのでそちらを見てほしい

アルファベット順ソートとひらがな順ソートの違い

まずは、通常のソート（アルファベット順）とalpha_to_hiragana関数（ひらがな順）を使ったソートの処理結果の違いを見てもらいたい

無秩序にならんだサンプルデータ(テーブル名：actor)

+-------------------+
| name              |
+-------------------+
| Saitou akira      |（さ行）（頭文字：S）
| L7ucky Isono      |（ら行）（頭文字：L）
| aida masao        |（あ行）（頭文字：A）
| YamadaShougo      |（や行）（頭文字：Y）
| AKAGI haruka      |（あ行）（頭文字：A）
| Mike Davis        |（ま行）（頭文字：M）
| Tanaka123         |（た行）（頭文字：T）
| hamadamayui       |（は行）（頭文字：H）
| goto satoru       |（か行）（頭文字：G）
| WANIDA KENJI      |（わ行）（頭文字：W）
| N-A-G-U-R-A-R-Y-O |（な行）（頭文字：N）
+-------------------+

アルファベットソート後（A->B->C->D->E...順に並びかえられた）

使用したクエリ：SELECT name FROM actor ORDER BY name ASC

+-------------------+
| name              |
+-------------------+
| aida masao        |（頭文字：A）
| AKAGI haruka      |（頭文字：A）
| goto satoru       |（頭文字：G）
| hamadamayui       |（頭文字：H）
| L7ucky Isono      |（頭文字：L）
| Mike Davis        |（頭文字：M）
| N-A-G-U-R-A-R-Y-O |（頭文字：N）
| Saitou akira      |（頭文字：S）
| Tanaka123         |（頭文字：T）
| WANIDA KENJI      |（頭文字：W）
| YamadaShougo      |（頭文字：Y）
+-------------------+

ひらがなソート後（あ->か->さ->た->な...順に並びかえられた）

使用したクエリ：SELECT name FROM actor ORDER BY alpha_to_hiragana(name) ASC

+-------------------+
| name              |
+-------------------+
| aida masao        |（あ行）
| AKAGI haruka      |（あ行）
| goto satoru       |（か行）
| Saitou akira      |（さ行）
| Tanaka123         |（た行）
| N-A-G-U-R-A-R-Y-O |（な行）
| hamadamayui       |（は行）
| Mike Davis        |（ま行）
| YamadaShougo      |（や行）
| L7ucky Isono      |（ら行）
| WANIDA KENJI      |（わ行）
+-------------------+

アルファベット文字列をひらがな順への重みづけ方法

YamadaTarou（やまだたろう）、TanakaMasao（たなかまさお）をサンプルデータとして説明する

文字列を小文字に変換する

YamadaTarou => yamadatarou
TanakaMasao => tanakamasao

ローマ字読みから重みづけるための変換テーブルを作成する

以下が変換テーブルである、母音のあ行は1文字全てにアルファベットを割り当て、子音はまとめて1文字のアルファベットを割りあてる

あ行：あ（a）、い（b）、 う（c）、 え（d）、 お（e）
か行：（f）
さ行：（g）
た行：（h）
な行：（i）
は行：（j）
ま行：（k）
や行：（l）
ら行：（m）
わ行：（n）

変換テーブルを用いて、サンプルデータを変換する

y a m a d a t a r o u
↓
l a k a h a h a m e c

t a n a k a m a s a o
↓
h a i a f a k a g a e

変換後のアルファベット文字列で比較を行う

y a m a d a t a r o u

[昇順]  h a i a f a k a g a e  <<<  l a k a h a h a m e c  [降順]
          （TanakaMasao）               （YamadaTarou）
　　　　　（たなかまさお）　　　　　　　（やまだたろう）

このようにアルファベット文字列であっても、ひらがな順にソートを実現できるようになる。実際のソートに関しては、alpha_to_hiragana関数内で実装するのではなく、MySQLのORDER BY句で利用してひらがなソートを実現している。

興味をもたれた方は

SOURCEFORGE.JPのMySQLibプロジェクト内にUPしているので下記よりアクセスしていただけると幸いである

alpha_to_hiragana関数の詳細な使用方法はこちら

alpha_to_hiragana関数のソースコードのダウンロードはこちら

関連リンク
mysqlに独自関数を組み込む（UDF）

放置したSSHクライアントを切断されないようにしたい(on FreeBSD)

Fri, 12 Jun 2009 18:05:22 +0900

私は主に開発作業をFreeBSD上で行っている。時にはサーバにログインして作業を行うケースもあり、SSHクライアント(OpenSSH_4.5)でサーバでアクセスする。ちょっと1～2時間休憩のために、席をはずしどってくると接続が切れてることはないだろうか？原因の多くはルーター、サーバーで接続コネクションを切断しているからだと思もわれる。 Windows専用、SSHクライアントソフトputtyにはkeepalive機能がついていて、指定した時間に定期的に、 nullパケットをログインしているサーバに送信することにより、切断を防げるのだが、 OpenSSHクライアントには標準で同様な機能はついてないようだ。色々と調べてみたところ、OpenSSH用のpatchを作成されている方がいたので、利用させてもらうことにした。そのときの導入方法である

今回の導入するパッチの作成者は、東北大学の後藤英昭博士である、感謝！

導入方法

OpenSSHを最新版(ver4.2 => 4.5)にする

cd /usr/ports/security/openssh-portable

(注意)上記OpenSSHのバージョンはこの記事を書いていた際の最新バージョンである

patchのダウンロード

wget http://www.sc.isc.tohoku.ac.jp/~hgot/sources/
                       openssh-4.4p1-watchdog.patch.tgz

ダウンロードしたパッチをあて、パケット送信機能を実装する

make patch

インストール

make install

インストールが成功すると、/usr/local/bin/ssh にSSHクライアントが置かれる

パケット送信する間隔を設定ファイルに書き込む

/etc/ssh/ssh_config に Heartbeat 120

上記設定は2分間隔でパケットを送るという設定になる

インストールしたpatch済みのSSHクライアンと置き換えを行う

CShellを使っているので、aliasを設定し置き換える
/etc/csh.cshrcに alias ssh /usr/local/bin/ssh を追加する

標準のSSHクライアントは/usr/bin/ssh にあるので、上書き置き換えでも可能だと思う

関連リンク
FreeBSDにSSHを設定する

MySQLでDATETIME型のデータを高速に検索する方法

Wed, 10 Jun 2009 23:42:16 +0900

MySQLでDATETIME型のカラムを追加して、YYYY-MM-DD HH:MM:SSの形式でデータを保存することはよくあるケースだと思う。DATETIME型のカラムをWHERE以降の条件句に指定して、年月日時でデータの絞込みを行い目的のデータを抽出するという時に、より高速にデータを取得できないかと考えてみた。

前提条件

テストはクエリを10回発行した平均値より比較する
テストパターンとして、INDEX有り・無しの2パターンで比較を行う
テストデータは100万レコード用意する
INT型のデータの作成にはMySQLのUNIX_TIMESTAMP()関数を使う
Query CacheはOFFにして行う

今回テストで使用したサーバのスペック

OS ：CentOS release 4.5 (Final)
DB ：MySQL5.0.77
CPU：Core 2 Duo 1.86GHz 
Mem：1GByte

今回テストで使用したテーブルスキーマ、データ構造

(DATETIME型のデータ構造　テーブル名：test_datetime)

mysql> desc test_datetime;
+-----------+----------+------+-----+---------+----------------+
| Field     | Type     | Null | Key | Default | Extra          |
+-----------+----------+------+-----+---------+----------------+
| id        | int(11)  | NO   | PRI | NULL    | auto_increment |
| datetime  | datetime | NO   | MUL | NULL    |                |
+-----------+----------+------+-----+---------+----------------+
+----+---------------------+
| id | datetime            |
+----+---------------------+
|  1 | 2008-08-23 19:03:26 |
|  2 | 2008-08-23 19:03:26 |
|  3 | 2008-08-23 19:03:26 |
|  4 | 2008-08-23 19:03:26 |
|  5 | 2008-08-23 19:03:26 |
|  6 | 2008-08-23 19:03:26 |
|  7 | 2008-08-23 19:03:26 |
|  8 | 2008-08-23 19:03:26 |
|  9 | 2008-08-23 19:03:26 |
| 10 | 2008-08-23 19:03:26 | 
| ・ |         ・   　     |
| ・ |         ・   　     |
| ・ |         ・   　     |
+----+---------------------+

================================================

(INT型のデータ構造　テーブル名：test_unixtime)

mysql> desc test_unixtime;
+-----------+----------+------+-----+---------+----------------+
| Field     | Type     | Null | Key | Default | Extra          |
+-----------+----------+------+-----+---------+----------------+
| id        | int(11)  | NO   | PRI | NULL    | auto_increment |
| unixtime  | int(10)  | NO   |     | NULL    |                |
+-----------+----------+------+-----+---------+----------------+
+----+------------+
| id | unixtime   |
+----+------------+
|  1 | 1219485806 |
|  2 | 1219485806 |
|  3 | 1219485806 |
|  4 | 1219485806 |
|  5 | 1219485806 |
|  6 | 1219485806 |
|  7 | 1219485806 |
|  8 | 1219485806 |
|  9 | 1219485806 |
| 10 | 1219485806 |
| ・ |     ・     |
| ・ |     ・     |
| ・ |     ・     |
+----+------------+

それではテスト開始・・・

INDEX無しの状態でのベンチマークテスト

比較演算子を使ったクエリ

(DATETIME型の場合)

SELECT * FROM test_datetime WHERE datetime = '2008-08-23 19:10:11';

処理結果(2.99 sec)

(INT型の場合)

SELECT * FROM test_unixtime WHERE unixtime = 1219486211;

処理結果(0.74 sec)

圧倒的にINT型にしたクエリ条件のほうがデータ取得の処理スピードが4倍高速の結果になった。
(※年月日時を＝(イコール、等値)を使った検索条件句を使うケースは実際のシステム設計の中ではあまりないようなケースだと思う。実際によく使われるのはやはり、次に紹介したBETWEENを使った期間指定検索であろう)

BETWEENを使った期間指定を使ったクエリ

(DATETIME型の場合)

SELECT * FROM test_datetime WHERE datetime 
              BETWEEN '2008-08-23 19:00:00' AND '2008-08-23 19:05:00';

処理結果(5.20 sec)

(INT型の場合)

SELECT * FROM test_unixtime WHERE unixtime 
              BETWEEN 1219485600 AND 1219485900;

処理結果(1.64 sec)

BETWEENを使った期間指定クエリでもINT型の方がデータ取得の処理スピードが3倍高速の結果である

INDEX有りの状態でのベンチマークテスト

比較演算子を使ったクエリ

(DATETIME型の場合)

SELECT * FROM test_datetime WHERE datetime = '2008-08-23 19:10:11';

処理結果(2.99 sec)

(INT型の場合)

SELECT * FROM test_unixtime WHERE unixtime = 1219486211;

処理結果(0.02 sec)

INT型の方がデータ取得の処理スピードが150倍高速の圧倒的効果である。INT型はINDEXを最適に使い目的の結果を返してくれるためここまでのパフォーマンス結果がでたものと思われる。面白い副産物結果として、DATETIME型ではINDEX有り・無しかかわらず処理結果値が同じということで、DATETIME型はINDEXの恩恵を受ける事があまりできないのである (※ただしINDEX無しの結果内容の所でも記載したが＝(イコール、等値)を使った検索条件句を使うケースはあまりないかもしれない・・・)

期間指定を使ったクエリ

(DATETIME型の場合)

SELECT * FROM test_datetime WHERE datetime 
              BETWEEN '2008-08-23 19:00:00' AND '2008-08-23 19:05:00';

処理結果(5.12 sec)

(INT型の場合)

SELECT * FROM test_unixtime WHERE unixtime
              BETWEEN 1219485600 AND 1219485900;

処理結果(1.64 sec)

DATETIME型、INT型もINDEXを設定しても、期間検索というB-tree型のINDEXの恩恵の受けにくい検索条件句であるため、INDEXが無い場合と比較してそこまで処理スピードの向上には影響を及ぼさなかったが、ここでもINT型の方がデータ取得の処理スピードが3倍高速の結果にはなった

結論

DATETIME型で保存するのではなく、UNIX_TIMESTAMP関数を使いINT型にコンバートした形式で保存することにより、DATETIME型より3倍～4倍高速化が実現できた。その際に注意しなければならないのが、INT型の年月日時を指定したカラムを生成しても実際にクエリを生成する際に、'1219485900'(シングルクォート)して文字列(STRING型)として指定しないこと。うっかりこのように指定してしまうと、カラムがINT型であっても処理スピードが遅くなってしまう。ただし、このINT型で年月日時データを保存する方法にもデメリットがあって、UNIX_TIMESTAMPなので直感的に見て人間が理解しずらいのである。そのためサーバのコマンドラインよりMySQL Clientを使いダイレクトにアクセスしデータを取得する必要があるケース(exp. 人間の手による緊急的な集計オペレーション)では、YYYY-MM-DD HH:MM:SSの形式にコンバートする必要があるかと思う。その場合は人手間だが以下のようにFROM_UNIXTIME関数を使用して結果を出力してほしい

SELECT id, FROM_UNIXTIME(unixtime) FROM test_unixtime  
               WHERE unixtime BETWEEN 1219485600 AND 1219485900;

ＩＴ業界　プロジェクトマネージャーに求められるスキルとは

Wed, 10 Jun 2009 00:17:55 +0900

プロジェクトマネージャーに必要なスキルとは何が思い浮かぶだろうか？たぶんそれは、業界・業種において求められるスキルは異なってくると思うが、ここではIT業界における、プロジェクトマネージャーに必要なスキルについて述べてみよう

予算管理能力

会社に利益を出すことは当たり前！

ビジネスマンである以上、会社から給料という労働の対価をもらっているはずプログラマー・システムエンジニアであっても「このプロジェクト規模は1億円である、我が社にとってビッグプロジェクトである、なんとしても納期に間に合わせるべく一致団結しよう！」という目標をたてれば、普通の人間であればモチベーションが上がり、その目標に邁進するはずである。一方プロジェクトマネージャーの立場であれば、収支・収益を意識することは当然であり最小の投資で最大限の利益をあげるという意識でプロジェクトを実行すれば、必然的に会社に利益をもたらすことができる。エンジニアリングよりのプロジェクトマネージャーなら、コストを抑えるところから、セールスよりのプロジェクトマネージャーなら、売り上げ規模を上げる所から入ると、時間とともに身につけられるスキルである

コミュニケーション能力

ボトムアップも大事

IT業界でなくても、常に言われる能力の一つであり、社会人として生きていく上でのスタンダードな能力の1つである。ここでいうコミュニケーション能力は相手に思いを伝えるだけでなく、相手から意見を吸い上げる能力も指している。自分の意見をゴリ通すことを、コミュニケーション能力が高い人間だと思っている人が居るかもしれないがそうではなく、相手から意見を吸い上げる方が重要視される。プロジェクトマネージャーという最高権限者である人(※プロジェクトマネージャーに任命される人であれば、それなりの業界経験をつんでいるはずなので年齢もそれなりに重ねているであろう)の意見が通りやすいのは至極当然。現場で発生している問題点などが開発メンバより吸い上げる事が不十分であれば、プロジェクトを成功に導く事は難しい。なのでトップダウンで指示を出すフローだけでなく、ボトムアップで自由に意見を言いやすい環境を用意することも、コミュニケーション能力の1つである

スケジュール管理能力

基本中の基本

スケジュールに始まり、スケジュールに終わるというように、プロジェクト遂行上、この能力が欠落しているマネージャがいるとしたら致命的である。要件を満たした成果物を納期どおりに、リリースすることは、プロジェクトとして最低の条件であり、ビジネスであれば、顧客との契約条件であるはず。納期にリリースするためには、工程のプロセス(タスク)が重要であり、いかにそのプロセスをマイルストーンどおりに完了していなければ、納期日にリリースすることが厳しくなる。そもそもこの基本中の基本ができないプロジェクトマネージャーなる人物が存在そもそもしているかというと、以外と存在しているものだ。さすがに納期日は覚えているのだが、各工程プロセスの管理を放置しておいて、いざ納期日に近くなると慌てだし、騒ぎ出す人だ。そもそも自分自身が与えられた役割をこなしていないのに、プロジェクトメンバーに当り散らすのは、言語道断である

技術力

ITリテラシー＋テクニカルスキル

IT業界に身を置く以上、ITリテラシーはプロジェクトマネージャーにはなくてはならない必要なスキルである。というか無い人は仕事になってないと思う。難しいところではあるが、ITリテラシー＋テクニカルスキルをもったプロジェクトマネージャーは鬼に金棒である。会社内外の人々とコミュニケーションを取る可能性があるプロジェクトマネージャーはいきなり、テクニカル質問をされ、その場で回答を求められるケースは意外に多い。要件定義・概要設計時にテクニカルスキルが高ければ、プロジェクトメンバーに適切なテクニカルアドバイスを行う事ができメンバーからの信頼度も高まり、今後のプロジェクト運営がスムーズになる可能性がある。それではテクニカルスキルが弱いプロジェクトマネージャーはどうすべきなのだろうか？プロジェクト内における、テクニカルスキルが高いプログラマー・システムエンジニアを技術責任者として抜擢し、プロジェクト内の右腕的存在として自分のウィークポイントを補ってもらおう。ここで気をつけなければならないのは、他のメンバーと同じように開発メンバとしてではなく、システム全体の設計であったり、タスクに遅れが生じたメンバーの、スーパーサブとして考える事である。プロジェクト内の技術責任者に引き上げても、タスク開発に100%従事していたのでは、広い視線でのシステムのアーキテクチャ全体を見渡すことができなくなってしまう。テクニカルスキルが高ければ、年齢・地位に関係なく任命することで、ある意味公平なジャッジになり、他のメンバーも納得しやすい。なによりも技術責任者に任命した当人も、モチベーションを高めて従事してくれるだろう

リスク回避能力(リスクヘッジ)

その他の能力が高くても

この能力がプロジェクト成功に導くために1番必要な影の能力であり、1番習得が難しい。仮定のイメージであるが、他の能力が欠けていてどうしようもないプロジェクトマネージャーが存在したとしよう。唯一リスク回避能力が秀でていた場合(※現実的に他の能力が欠如していて、そもそもプロジェクトマネージャーなるもに任命はされないのだが)、この能力だけで無事プロジェクトをリリースする事をやってのけれると思う。プロジェクトが失敗する要因であるスケジュール遅延、メンバの脱落、仕様ミスなど数を上げるときりがないが、これらの要因を事前にキャッチし、避けながらながら進んでいきリリースまではやってのけそうである。実際にそういうプロジェクトマネージャーを見たことがある。ただ、さすがにその後のシステム運用フェーズに入ると、開発フェーズ以上に、予見不可能な事態が発生しやすいので、この能力だけでは切り抜けていることは不可能と言える。リスク回避能力というものは、生まれもっているセンスのようなもので、血液型でいうならばA型の人が多かったりする。A型の人が多いのは、細かい性格であったり、根っからの心配性な性格がリスク回避能力を高めている。心配だから、各タスクに関しては、色々と深く考える、考えるので、不明・不安要素が早期に発見できる。逆に0型の人は楽観主義的な人が多いので深く熟考せずに物事をすすめがちなので、不明・不安要素が後手後手にまわるケースが多かった(※あくまでも自分の経験上であって、血液型で、その人を差別しているわけではない)。ここまで書いてしまうと、この能力自体、身に着けることは諦めるしかないようだが、楽観主義者であった自分が努力して多少なりにも身に着けた方法とは、成功パターンだけでなく失敗パターンも1セットとして、ミクロではタスクレイヤーから、マクロではスケジュール全体に及ぶまで、時間があれば考えるようにした。仕事帰り電車の中とかで「このタイミングでお客さんから、大幅な仕様追加が要望されたらどうしよう？」、「システムエンジニアである○○君が倒れたらどうなるだろう？」などと。これはA型の人に多い不安な状態に自ら陥るようにする、妄想自虐プレイと呼んでいる。いわゆる、プロジェクトリスクシミュレーションで、こうすることにより不安要素が可視化できリスクの早期発見、解決につなげることができる

最後に

5つの能力を列挙したが、書いている途中に思ったことが、自分を含めこれらの能力を満たしているプロジェクトマネージャーに出会ったことがないという事だ。5つは無理だとしても、3つ持っている人でも中々出会う機会がない。逆に実績・能力もないくせに、プロジェクトマネージャーという肩書きを名乗る人が多いということだろう。業界を含め、外見だけでなく、中身もともなっていかなければ、本当に虚無の世界になってしまうだろう

関連リンク
「走れ！プロジェクトマネージャー！」

コマンド備忘録

Sun, 7 Jun 2009 10:45:10 +0900

Linuxに関するカーネル、コマンド、チューニングなどのメモである

コマンド

psのSTATの意味

R（Run）：タスク処理中（実行中）
S（Sleep）：タスクが待機中（CPUの空き待ち）
D（Disk Sleep）：タスクが待機中（Disk I/Oの空き待ち）
Z（Zombie）：タスク終了待ち

プロセス内のマルチスレッドの状況を確認する

ps -elf -L | grep プロセス名

(例：Javaのスレッド)
fukaoi  13177  1 24335  0  105  76   0 - 81609 339346 Nov18  bin/java -D
fukaoi  13177  1 24336  0  105  76   0 - 81609 322561 Nov18  bin/java -D
fukaoi  13177  1 24337  0  105  76   0 - 81609 322562 Nov18  bin/java -D

.bakファイルをディレクトリ再帰的に探査して削除する

find  ./ -name '*.bak' -exec rm -v {} \;

各種OS、ハード情報を調べる

cat /proc/*

(例：カーネルバージョン)
cat /proc/version
Linux version 2.6.9-xx

(例：CPUバージョン)
cat /proc/cpuinfo
model name      : xxxxxx
stepping        : 8
cpu MHz         : xxxxxx
cache size      : xxx KB

MySQLのデバッグ情報を出力する

VISUAL=cat /usr/local/mysql/bin/mysqlbug

おもにConfigure Optionを調べる際ににCallする

Webサーバ(Port:80)にアクセスしてきているIPを調べる

netstat -ant | grep EST | grep :80 | awk '{print $5}' \
| awk -F : '{print $1}' | sort | uniq | wc -l

Cのソースファイルから関数を探す

gtags -v
global 関数名

(例：mysql_reald_connectを呼び出しているソースを探す)
cd /usr/local/src/mysql-5.0.xx/libmysqld
gtags -v

global -r mysql_real_connect
client.c
examples/mysql.cc
examples/mysql_client_test.c
examples/mysqltest.c
ha_federated.cc
libmysql.c

CのソースファイルからFunction callを抜き出す

cflow xxxx.c

カレントディレクトリにあるファイルをファイルサイズ順に並び変える

ls -lahS ./

SVN ignoreの設定

cd "ignoreを設定したいディレクトリ"
svn  --editor-cmd vi  propedit svn:ignore . <= ignore条件を登録する
svn commit -m "Set svn:ignore"              <= コミットし登録する

MySQLの使用可能ストレージエンジンを調べる

mysql> show engines;

+------------+----------+
| Engine     | Support  | 
+------------+----------+
| MyISAM     | DEFAULT  |
| MEMORY     | YES      |
| InnoDB     | DISABLED |
| BerkeleyDB | NO       |
| BLACKHOLE  | NO       |
| EXAMPLE    | NO       |
| ARCHIVE    | NO       |
| CSV        | NO       |
| ndbcluster | NO       |
| FEDERATED  | NO       |
| MRG_MYISAM | YES      |
| ISAM       | NO       |
+------------+----------+

MySQLのQUERY_CACHEをクエリ単位で使用しないようにする

SELECT SQL_NO_CACHE ...

MySQLをGDBをつかってDebugする

gdb /usr/local/mysql/libexec/mysqld
(※)一般ユーザーで実効する事。rootではセキュリティチェックにより
    実効できない

diffを使った際に、表示を見やすく出力する

diff -br -U1 Aファイル Bファイル

-b：スペース削除
-r：再帰的に走査
-U：アウトプットするときに○行にまとめUnified形式にする(+)

Windowsの80番ポートを占有しているのは誰だ？

Thu, 5 Mar 2009 15:44:45 +0900

仕事の関係で.NETの業務をこなすべくWindowsXPが入っているデスクトップPCに.NETの開発環境を構築する事になった。まずはWebサーバのIISのインストール。WindowsXP Proffesionalなので、

[プログラムの変更と削除] ->［Windowsコンポーネントの変更と削除］-> ［インターネットインフォメーションサービス(IIS)］

にチェックを入れればなんなく、インストールできる。

さて、IISの管理マネージャから起動させようとしたら、エラーで出て起動できなかった。そこで

telnet localhost 80

とコマンドプロンプトでたたいてみたら、案の上、他のアプリが先に起動してて占有されているではないか。そういえば、以前、Windows版Apache、Tomcatなどをテストで立ち上げていた記憶があったので、これら悪戯なアプリ君達が起動しているのかと思い、調べたが起動していなかった？？？ちょっぴり焦ったのだが。

netstat -b

でlisten中のアプリケーションを調べるには上記コマンドで実現可能だ。

早速プロンプトでたたいてみると

localhost:80 [Skype.exe]

なんと、Skypeが占有しているでないか！！！listen portで80をあえて使うのは何故？！ FW(ファイアウォール)でport:80しか許可されていない環境の相手と通信する為なのか、ぬかりがないなーとりあえず、このままSkypeにport:80を使わせておくのはしゃくなので、

[ツール] ->［設定］-> [接続パラメータとプロキシの設定] -> [上記のポートに代わりポート80を使用する]

にチェックが入っていたのを外し、Skypeには別のportの割りあてを行ったとりあえず、IISは起動できたが、今回解決に時間がかかってしまったのは思い込みがあったためだと思う。まさかWebサーバ以外のアプリケーションが占有しているはずがないという思い込みが。

Skype port:80のネタ
Port 80 の占有者

PHPのソースコードを解析するツールをつかってみた

Tue, 3 Mar 2009 01:52:07 +0900

PHPで品質の高いプログラムを作製するのが、私の夢として持ちつづけている。プログラマの個人能力に影響されず品質を高めるにはどうすべきか? システマチックに自動で品質をチェックして、問題点(既存bug)を指摘してくれるツールがないかと、探してみた。 PSAT(the PHP static analysis tool)というツールを発見したが、ネットで利用している人は殆ど発見できず、とりあえず実験してみた。下記がセットアップ＆検証までの情報である

導入方法

rpmのダウンロード

psat-0.1pre154-1.i386.rpm

依存関係のある下記パッケージもダウンロードしておく

aterm-2.4.2-1.i586.rpm
sdf2-bundle-2.3.4pre15345-1.i586.rpm 
strategoxt-0.17M2pre15559-1.i586.rpm

Linux(Cent OS4.4)にインストール

rpm -ivh aterm-2.4.2-1.i586.rpm
rpm -ivh sdf2-bundle-2.3.4pre15345-1.i586.rpm
rpm -ivh strategoxt-0.17M2pre15559-1.i586.rpm 
rpm -ivh psat-0.1pre154-1.i386.rpm

解析方法

psat -i ***.php

オプション一覧

-l 解析するターゲットとなるPHPファイルの指定
-o 解析結果を標準出力ではなく、ファイル出力先
-r バージョンの指定(PHP4:4、PHP5:5)

解析結果内容

target.phpというサンプルを使用

psat -i target.php


1. if ($a) {
2.     //何らかの処理を行う
3. } 
4. 
5. if (isset($a)) {
6.     //何らかの処理を行う
7. } 


/** 
 * PSAT check (Correctness)
 * If(variable) to check 
 * the initialization of a variable
 */  
 if ($a){       } 
 if (isset($a)){       }

処理結果から分かるように、問題の箇所があった場合(脆弱)にその箇所の直前にコメント分で問題内容が挿入されるようだ。ライン1のifは変数の正負判断しかしてないために、ライン5のifと比べて、チェックが甘いといったところだろうか

解析結果内容(クラスの場合)

targetClass.phpというサンプルを使用

psat -r 4 -i targetClass.php


1. class targetClass
2. { 
3.     public function test()
4.     { 
5.        //何らかの処理を行う
6.     } 
7. } 

 [ psat | error ] 
  targetClass.php: character 'p' 
  unexpected at line 5, column 5 
 
 [ psat | error ] {
 [ psat | error ] 
  public function test()
  [ psat | error ]

今回あえて、PHP4では実装されていない、メソッドのアクセス属性"public"をつけ実行してみたが、今回の処理結果はツールのエラーで終わってしまった。ためしに、rオプションをPHP5を指し示す-r 5で行ってみたが同じくツールのエラーで終わってしまった

結論

psatに関して、まだ実務レベルでは利用するのは難しそうだ、今後に期待しよう

知って損はない！　Webアプリケーションのリリース時に気をつける事

Mon, 23 Feb 2009 14:30:33 +0900

Webアプリケーションのリリース時は大変緊張するもので、それはWeb(インターネット)に公開することイコール、世界中の誰にでもアクセスが可能になるためである。といってもWeb以外でもお客さんに納品するタイミングというのは平常時の精神状態ではないため、普段ならおきないミスも発生してしまうリスクがある。リリースするまでのテスト手法などは記述するとキリがないため省いて主に、私の経験上いかにリリース時にトラブルなく、リリースできるかリリース前日、当日、後日の心構え的なことが中心にまとめてみた

3日前迄にやること

リリース手順書の作成

リリース時にやるべきこと(作業内容)を、記述したドキュメントを作成するのとしないのでは、雲泥の結果を生み出す。何回もいうようにリリース時にはどんなに肝っ玉が据わった人でも平常時以上の判断・能力を発揮することはできないので、頭をつかわずとも、リリース作業ができるように前もって手順をまとめておくためである。誰(Who)が何(What)を何時(When)にどう(How)すべきなのかを明確化することが大切である。後は、開発環境では問題なく動作しているプログラムも、本番環境だと動作しない(※ミドルウェアのバージョンや、サーバの設定が異なっている事により発生しやすい)ケースがある。

ケースによっては巻き戻しフローも明記しておくこともある。すでにサービスを開始しており、リニューアルや、機能追加の場合では、サービスを継続すること(※サービスを止めない)が第1だと思う、前のバージョンに巻き戻す事を巻き戻し作業と呼びます。作業内容が決まれば、作業完了時間が決まる。その時間完了時間から1時間以上オーバした場合、リリース作業を急遽取りやめ、巻き戻し作業に入るわけである

(参考例)

  [12/01 11:00～12:00]
  AさんがプログラムをサーバにUPする
  UPするソース(○○.php、□□.php、△△.php)

  [12/01 12:00～13:00]
  BさんがApacheの設定を変更する
  変更するファイル(httpd.confのline:412)
  ○注意箇所
    httpd.confのバックアップ(httpd.conf_bak)を必ずとっておく
　  変更後、apacheの再起動を行う


  [12/01 13:00～13:10]
  BさんがIP制限を一部許可する
  変更するファイル(httpd.confのline:102)
  ○注意箇所
　  念のため非許可IPの箇所よりアクセスし、制限が
    かかっているか確認を行う
　  変更後、apacheの再起動を行う


  [12/01 13:10～14:00]
  プロジェクト関係者全員で確認を行う
  ○主に確認する箇所
　  Aさん(入会登録)
　  Bさん(購入、決済)
　  Cさん(商品の表示)

  [12/01 14:00～]
  リリース無事完了

  [12/01 15:00を超えた場合]
  ●巻き戻しフロー
    Bさんがバックアップより前のバージョンのＸＸプログラムを
    上書きし元に戻す
    ・
    ・

リリース手順書のレビュー

作成したリリース手順書を関係者でレビューすることによって、作業漏れの確認になる。当日の気持ちで確認しあうことでシミレーションにもなる。ここでのポイントはプロジェクトリーダの人はいかに、本番当日と同じ緊張感をメンバに伝えられるかどうかである

1日前迄にやること

プログラム修正の締切り

スケジュールがタイトなプロジェクトだと、修正作業をギリギリまでおこなわざるをえない。だが大小あがってくる修正箇所を対応しているとキリがなく、いつまでたってもリリースができない状態になってしまう(※要は、キリがないということである)。それはお客さん自社ともに困るはずなので、あらかじめお客さんに修正受付けの時間を決めておき、了承をもらっておく必要がある。

(参考例)

『○月○日の△時△分までに確認できた、
  修正箇所については優先的に直しますが、
  それ以外のものに関しては、リリース後対応させてください』

前もって出勤時間をリリース時に合わせる

Webアプリケーションのリリース時間は、世の中の人のアクセスが少ない時間帯を指定される場合が多い。(※新規オープンするサイトでは時間の指定はないが、既存のサイトをリニューアル、機能追加の場合)例えば、リリース時間がAM3:00～の場合、前の日に早く寝て、早く起きるという、平常時とは異なるサイクルをとらなければならない。そうなると体調を崩しやすい、寝不足になりやすいです。体調の状態はリリース作業に大きな影響を及ぼすので、以下のように前日から体内リズムを整える手法もある

(参考例)

  [12/02 03:00～08:00にリリースとした場合]
　
　通常は09:00に出勤していた時間帯を
  前日(12/01)の出勤時間を02:00～に変更し
　深夜時間帯に体内リズムを整える

例のように03:00～のリリースだと前日より寝ずにリリースを迎えるという方法も可能。だが私の過去経験上、通常は22時位に仕事を終えていたリズムからさらに時間を延長することにより、集中力がもたない。尚、途中で仮眠を取るという方法もありだが後、数時間でリリースを迎えるという気持ちが高ぶってあまり寝れない経験があった。

前日から体内リズムをリリース時間に合わせて調整するという方法は、あくまでも私にとってベストであっただけだが、必ずしても万人に当てはまる手法かどうかはわからない。要は睡眠時間をきっちりとれ集中力が高められるかどうかがポイントだと思われる

リリース当日にやること

いかに平常心を保てれるか

前半にも書いたが、リリース時は非常に緊張するものだ。いつもとは違う自分がそこに存在しているといってよいだろう。特にネガティブシンキング傾向にある人がとくに緊張すると思われる。そこで心がけていただきたいのは、無事リリースしたときの成功イメージを頭の中で妄想してみる。それさえも緊張でイメージできない場合は、≪ 絶対に無事リリースする ≫、≪ 自分ならできる ≫と何回も頭の中でつぶやき、自己暗示にかけることも効果がある。後は、緊張状態にあると呼吸が浅くなりがちなので、深く深呼吸を3回やるだけでも、緊張がほぐれる。可能ならばリリース作業前に、プロジェクトメンバ全員で実践できればベストである

リリース完了後1週間以内にやること

特別監視状態におく

無事リリースが完了した場合、これで終わりなのだが、Webアプリケーションの場合、まだ気を抜いてはいけない。ここまではあくまでもインターネットの大海原に1隻の船で港から出向したにすぎない。出向中で一番怖いのが、大波だ。大波＝アクセス集中が発生した場合、テスト環境で負荷テストを行って、サーバ、Webアプリケーションのアクセス処理スペックを把握していたとしていても、それ以上のアクセスが集中砲火した場合、サーバ、Webアプリケーションはあっという間にサービス不能に陥いる。そのために、この段階では、監視ツール(※MRTG、nagios...)などでアクセス処理状況に問題がないか毎日、定点監視を行うべきである。

また開発環境では発見できなかった、Bugが潜んでいる可能性もあるので、時間の経過とともに大きな問題になるまえに、DB、ログファイルに吐き出されたデータも定点確認することによりBugの早期発見が可能になる

リリース完了後2週間以内にやること

反省会を開く

この作業までたどりつけば、リリース作業も無事完了し、安定してサービスが展開されていると判断してよいだろう。ただし、反省すべき点というのは必ずなんらかあるはずである。それはあくまでもたまたま成功しただけかもしれない。次回のリリース作業では2度を起こさない、他の作業者が起こさない意味をこめて、反省会で情報を共有し、リリース作業の品質を高めるべきである

深追い Fukaoi.org

JettyをPort80で起動する方法

今回使用したミドルウェア情報・補助情報

導入方法は次の2パターンが有ります

(1)：一般ShellューザでPort:8080で起動してOSの機能である、 ipchains、iptablesを使って、Port:80へのリクエストを8080へフォワードする

(2)：JNIを使って、Nativeライブラリを起動時に読み込みnologinユーザーにsetuid (and setumask)を行う

(1)：iptables、ipchainsを使用して実現する方法

iptables

ipchains

(2)：nologinユーザーにsetuidを使用して実現する方法

setuidのNativeライブラリをJettyにあてるために解凍したJettyのソースに移動する

(a)：Mavenを使ってNativeライブラリ(org_mortbay_setuid_SetUID.c)をインストールする場合

(b)：手動でNativeライブラリ(org_mortbay_setuid_SetUID.c)をインストールする場合

libsetuid.soファイルができているか確認する

Jettyを実行させたいnologinユーザのユーザーIDとグループIDを設定ファイルに指定する

jetty.xmlのPort指定箇所を8080から80に変更する

jetty-setuid.xmlを指定して、Jettyを起動させる

設定、コンパイルが上手くいかない場合

結論

いまさらながらPHP_EOL定数と改行コードについて

PHP_EOLが定義されているソースファイルをリーディングする

各OS環境でPHP_EOLが出力する改行コードをASCIIコードで確認してみる

コマンドラインでスクリプトを実行した結果

MySQLのUDF関数を作った － アルファベットの文字列をひらがな順にソートする

アルファベット順ソートとひらがな順ソートの違い

無秩序にならんだサンプルデータ(テーブル名：actor)

アルファベットソート後（A->B->C->D->E...順に並びかえられた）

ひらがなソート後（あ->か->さ->た->な...順に並びかえられた）

アルファベット文字列をひらがな順への重みづけ方法

文字列を小文字に変換する

ローマ字読みから重みづけるための変換テーブルを作成する

変換テーブルを用いて、サンプルデータを変換する

変換後のアルファベット文字列で比較を行う

興味をもたれた方は

放置したSSHクライアントを切断されないようにしたい(on FreeBSD)

導入方法

OpenSSHを最新版(ver4.2 => 4.5)にする

patchのダウンロード

ダウンロードしたパッチをあて、パケット送信機能を実装する

インストール

パケット送信する間隔を設定ファイルに書き込む

インストールしたpatch済みのSSHクライアンと置き換えを行う

MySQLでDATETIME型のデータを高速に検索する方法

前提条件

今回テストで使用したサーバのスペック

今回テストで使用したテーブルスキーマ、データ構造

INDEX無しの状態でのベンチマークテスト

比較演算子を使ったクエリ

BETWEENを使った期間指定を使ったクエリ

INDEX有りの状態でのベンチマークテスト

比較演算子を使ったクエリ

期間指定を使ったクエリ

結論

ＩＴ業界 プロジェクトマネージャーに求められるスキルとは

予算管理能力

会社に利益を出すことは当たり前！

コミュニケーション能力

ボトムアップも大事

スケジュール管理能力

基本中の基本

技術力

ITリテラシー＋テクニカルスキル

リスク回避能力(リスクヘッジ)

その他の能力が高くても

最後に

コマンド備忘録

コマンド

psのSTATの意味

プロセス内のマルチスレッドの状況を確認する

.bakファイルをディレクトリ再帰的に探査して削除する

各種OS、ハード情報を調べる

MySQLのデバッグ情報を出力する

Webサーバ(Port:80)にアクセスしてきているIPを調べる

Cのソースファイルから関数を探す

CのソースファイルからFunction callを抜き出す

カレントディレクトリにあるファイルをファイルサイズ順に並び変える

SVN ignoreの設定

MySQLの使用可能ストレージエンジンを調べる

MySQLのQUERY_CACHEをクエリ単位で使用しないようにする

MySQLをGDBをつかってDebugする

(1)：一般ShellューザでPort:8080で起動してOSの機能である、
ipchains、iptablesを使って、Port:80へのリクエストを8080へフォワードする

MySQLのUDF関数を作った－アルファベットの文字列をひらがな順にソートする

ＩＴ業界　プロジェクトマネージャーに求められるスキルとは

知って損はない！　Webアプリケーションのリリース時に気をつける事