一応、以下も残しておきますが、
最新情報は http://www.kitoku-magic.net/profile.html をご覧下さい。
まずは、注意点を以下に。
「出来る」や「知っている」などと書いても、スキルの証明にならないと考え、一切書きませんでした。
ですので各項目について、その能力や技術をどう活かしているか等に焦点を置いて書いております。
上記の制約を設けた理由は、
別記事の自分の能力を文章「だけ」で知ってもらう方法に書いてあります。
以下のリンクから、それぞれのスキル項目に相互にジャンプ可能となっております。
また、項目名の右側に「追加・変更」と書かれている箇所は、
以前と比べて、大きく内容が変更された項目と新たに追加された項目です。
変更日：2012/7/29
1. ビジネス系スキル
1.1 コミュニケーション力(変更)
1.2 教育力(変更)
1.3 顧客折衝力
2. IT系スキル
2.1 いわゆる上流工程系スキル
2.1.1 コンサルティング力(変更)
2.1.2 マネジメント力(変更)
2.1.3 設計力(変更)
2.2 いわゆる下流工程系スキル
2.2.1 OS
2.2.1.1 CentOS
2.2.1.2 Solaris
2.2.2 言語/フレームワーク
2.2.2.1 プログラミング全般(追加)
2.2.2.2 Java
2.2.2.2.1 Struts
2.2.2.3 JavaScript/Ajax(変更)
2.2.2.4 PHP(変更)
2.2.2.5 SQL(変更)
2.2.2.6 HTML+CSS(変更)
2.2.2.7 C(変更)
2.2.3 Web/APサーバー
2.2.3.1 Apache
2.2.3.2 Tomcat
2.2.3.3 OracleApplicationServer
2.2.3.4 Websphere
2.2.4 データベース
2.2.4.1 Oracle
2.2.4.2 MySQL
2.2.4.3 PostgreSQL
2.2.5 各種ツール
2.2.5.1 Vi
2.2.5.2 サクラエディタ(変更)
2.2.5.3 Eclipseとそれに準ずるツール
2.2.5.4 バージョン管理システム
2.2.5.5 Object Browser
2.2.5.6 Dreamweaver(追加)
2.2.6 その他技術
2.2.6.1 HTTP
2.2.6.2 SMTP(追加)
2.2.6.3 セッションとCookie
2.2.6.4 アジャイル(変更)
2.2.6.5 プロセスとスレッド(追加)
2.2.6.6 セキュリティ
2.2.6.6.1 全般
2.2.6.6.2 クロスサイトスクリプティング(変更)
2.2.6.6.3 SQLインジェクション(変更)
2.2.6.6.4 クロスサイトリクエストフォージェリ
2.2.6.6.5 セッションハイジャック
2.2.6.6.6 NULLバイト攻撃
2.2.6.6.7 ディレクトリトラバーサル
2.2.6.6.8 OSコマンドインジェクション
いくら、コミュニケーション能力に長けていたとしても、
真摯な心が無ければ、相手との良好な関係は望めない。
また、「貴方の言っている事が、私にはそういう意味だと思いませんでした」など、
コミュニケーションによる認識のズレは当然の様に起きる。
よって、曖昧な点や不明な点はとにかく相手に聞き、
認識ズレを無くす様にしていく。
「自分と他人は違う」事を忘れずに、そしてその上で、
相手との溝を埋めていこうという気持ち(心)が、最も大切。
基本的には放置し、自分の頭で考えさせて毎日報告だけしてもらう。
相談は随時受け付ける場を作る。
また、失敗が多い時には疲労している可能性もある為、
時にはアメもあげる。
関連：
答えは教えないけど見捨てないのが本当の愛情や教育だと思う
顧客の目的を達成する過程の中で、進捗などの状況が厳しくなった時に、
正直に状況が厳しい旨を話す。
ただし、厳しいから逃げますではなく、
自分の方で何とかするという意思表示ははっきり表明する。
相手の話を聞いていく中で、「こうなのではないだろうか」という「仮説」を立てる。
そして、その仮説を検証する為の質問をする。
それを何度も繰り返し、相手の「真のニーズ」を探っていく。
作業者より自分の方が仕事が出来るのは当然なので、
「自分が出来るから作業者も出来るはず」との考えで作業のスケジュールを見積もらない様にする。
スケジュールの見積もりの際には、作業結果を欲している相手が必ずいる以上、
結果を要求している相手とのコミュニケーションにかかる時間も考慮して見積もる。
作業の進捗が思わしくない場合には、
作業者にヒアリングなどをして原因を分析し、
作業量を減らしたり、作業の担当変更を行う。
また、作業者は内在的にはコミュニケーションを欲している場合が多い為、
最低でも１日１回は直属の作業者全員に一声かける。
関連：
マネージャは親子でいう親であれ
設計を行うのと同時に、プロトタイプ的にでも実装していき、
早い段階から顧客に「欲しい物のイメージ」と合っているかどうか、
確認していく。
実装が難しいと思われる要件の順に、
実装可能か不可能かを調査していく。
Webの画面で一覧表を表示する時に、
１画面に多くの行数を表示しようとすると、
描画速度に時間がかかるので、
複数ページに跨って表示する画面設計を検討する。
住所なら存在しない住所のチェックをするなど、
各入力項目毎に必要なチェックを意識していく。
画面の入力項目に対するDBのテーブルはどれにするかを意識する。
画面間で共通な機能や画面上の項目を探し、
親クラスと子クラスに分けるなどのクラス設計を行う。
YAGNIに基づき、先々必要になるかもしれない機能は、
必要になった時点で考える。
DRYに基づき、同じ意味の処理は2箇所以上に書かずに、
修正が1箇所で済む様に設計する。
Apacheインストール時には、
apr→apr-util→Apacheの順番でインストールする等、
パッケージの依存性を考慮してインストールする。
makeは時間がかかる時も多いので、
make中にインストール手順書を作る。
カーネルイメージは、/boot配下にあり、
GRUBの設定ファイルで起動するカーネルverやオプションを設定する。
SPARC版はOKプロンプトでpower-offと入力する必要がある等、
X86版とOS停止手順が違う。
複数のクラス間でクラスインスタンスを持ち回すには、
渡したいクラス側に、クラスインスタンス型のインスタンス変数を宣言し、
その変数のセッターにクラスインスタンスを渡す。
一目でどこから参照出来るかを判断する為に、
アクセス修飾子は必ず書く。特にprivateやprotected。
メソッドのアクセス修飾子は、
継承する可能性を考え、余程の事が無い限りprivateは使わない。
変数のスコープを明確にしたい時は、
使わなくなった変数をnullクリア(コメントを必ず付ける)やunsetする。
変数を代入した際、
代入元のオブジェクトの値を変更しても、
代入先のオブジェクトの値を変更したくない場合には、
シャローコピーではなくディープコピーを使う。
値渡しをすると、参照渡しに比べ、速度が大幅に遅くなる時があるので注意する。
関連：
値渡しと参照渡しの速度比較
実行速度の比較だと、
拡張for文より、インデックスを使う通常のfor文の方が速い。
GCViewerを用いると、
メモリ使用量の状況がグラフ形式で分かる。
設定ファイル値の読込などのアプリケーション全体で一度だけ行いたい処理は、
HttpServletのinitをオーバーライドして実装する。
Action→Actionの遷移には、
ActionFormのresetに注意。
struts-configとlogic:iterateのスコープ値がrequestで、
iterateする対象がListの場合、
POST送信してもFormのListのメンバーの値がnullになる。
スコープをsessionにする事で回避が可能。
テーブルタグにIDを設定している場合、
「document.getElementById('テーブルタグのID').rows」で、
テーブル内の行データの配列を取得する事が出来る。
IMEモードの変更は、style属性に値を設定した後に、focusする必要がある。
document.getElementByIdは、
windows.onloadの実行後でなければ動かない。
windows.onloadでDOM構造を読み込むから、
DOM構造の読み込み後じゃないとNGだからではないかと推測。
データ型が曖昧な言語だが、
内部的にはデータ型が存在するので、
値の比較は「==(型を意識しない)」ではなく、
「===(型を意識する)」を使う。
原則として、配列への値の分割は、
正規表現を使っているsplitではなく、explodeを使う。
同じく、簡易な文字列検索なら、
preg_matchではなくstrposを使う。
「new $変数名」とする事で、
動的にクラスインスタンスを生成する事が出来る。
親クラスのメソッドにアクセスするには、
「parent::親クラスのメソッド名()」と書く。
Smartyにおいて、eqは==に展開されるので、
eqと書かないで===と直接書く。
データ型が曖昧な言語だが、
内部的にはデータ型が存在するので、
値の比較は「==(型を意識しない)」ではなく、
「===(型を意識する)」を使う。
関連：
型なし(PHP、MySQL)と型あり(Java、Oracle)の違い
値の存在チェックだけを行うなら、
SELECT〜EXISTS〜ROWNUMが速くて良い。
排他ロック時には、
SELECT FOR UPDATEを使い、
他のリクエストを排除する。
CASE式を使う事で、SQL内で条件分岐が出来る。
EXISTSを理解するには、手続き型の考え方に置き換えてみると分かりやすい。
テーブルタグは表を表示する為のタグである為、
レイアウト調整する目的で使わない事。
bodyタグの最後でスクリプトを実行する方が、
ページの読込が速い。
importを使うとCSSファイルから別のCSSファイルを読み込める。
リキッドレイアウトを意識するなら、
width等の値には、pxではなく%を使う。
class属性は、半角スペースで区切る事で、複数指定が可能。
ポインタ変数はメモリアドレスを参照しているので、
参照元のメモリアドレスに対する値を変えると、
ポイント変数が参照しているメモリアドレスに対する値も変わる。
構造体内のメンバへのアクセスは、
構造体型変数->メンバ変数と書く。
文字の入力を受け付ける際には、
バッファオーバーフローなどを防ぐ為に、
scanfとgetsは使わずにfgetsを使う。
関数ポインタを使う事で、条件に応じた動的な関数呼び出しが可能になる。
void型のポインタは、Objectクラスと同じで何の型の変数でも入るが、
その分バグの温床になりやすいので注意する。
SSL対応時には、httpd-ssl-confなどを作り、
httpd.confからインクルードする。
アクセス制限時のOrderはdeny, Allowの順にし、
Allowで許可するIPアドレスを指定したりする。
Apacheとの連携には、workerを作り、
ajpを受け付けるパスを書く。
データソースやJNDIの設定は、
server.xmlなどに記述する。
2.2.3.3 OracleApplicationServer
オートデプロイをするには、
application.xmlとdefault-web-site.xmlを編集する。
DBサーバーマシンとの連携は、
APサーバーマシンで名前解決する（APサーバー上のアプリがDBを参照している為）。
リモートデバッグ時には、
opmn.xmlのjavaオプションを編集する。
障害発生時の被害拡大防止対策として、
データファイル・制御ファイル・リカバリー領域の格納先は、
それぞれ別にする。
起動・停止はsysdba権限付のsysユーザでSQL*Plusに接続して行う。
プログラム側のプリペアドステートメントの、
パラメータの「？」の値を見るには、
クエリログを採取する。
文字コードの設定は、
my.cnfを編集する。
インストール直後はrootのパスワードも設定する。
ネットワーク越しのアクセスを許可する(trustなど)設定は、
設定ファイルにて行う。
「Ctrl + d」で１スクリーン下に、
「Ctrl + u」で１スクリーン上に移動。
文字列検索は「/」の後にキーワードを入力する。
「w」で右に、「b」で左に単語区切りで移動。
「1G」でファイルの先頭行に、
「G」でファイルの末尾行にカーソルが移動する。
「Shift + Ctrl + 左右キー」を使うと、
素早く文字列を選択する事が出来る。
置換で、置換前を「,」、置換後を「,\n」等とすると、
カンマ区切りで改行される。
デフォルトでは、複数行に渡っての検索・置換はサポートしていないので、
それらを実現するには、マクロ等を導入する必要がある。
エディタ上で「Ctrl + PgUp or PgDn」とすると、
エディタ上の別のファイルタブに移動が出来る。
メソッド名を選択状態にして「Ctrl + Shift + G」とすると、
そのメソッドが呼ばれている箇所を検索出来る。
クラス名が解決出来ないエラーが発生している際に、
そのクラス名上にカーソルを合わせて「Ctrl + Shift + M」とすると、
自動的にimport文が生成される。
他の人が触る可能性が高いファイルは長くチェックアウトしたりしない。
struts-config.xmlやApplicationContext.xmlは、
追加するクラスのチェックイン後に記述を追加しエラーを防ぐ。
exp・impで定期的にバックアップを取り、再構築等に備える。
Shift+上下キーで全データをコピー出来る。
テンプレートを使うことで、
ヘッダー・フッター等を共通化する事が出来る。
リクエストを投げてレスポンスを返すと、
以前のリクエスト内容などが破棄されるステートレスなプロトコルなので、
内容の保持にはセッション管理が必要。
また、リクエストされるGET・POST・COOKIEなどの値や、
レスポンスで返される上記の値全てについて、改竄が可能となっている。
Return-Pathのアドレスを携帯にすれば、
PCから送った時に返信先が携帯になる。
Message-IDは全世界のメールで一意になる。
また、発信者と受信者が同じでも、メール１件毎に別のIDになる。
エンベロープfromとtoは、SMTPでおしゃべり中(FROM・RCPT)の時に使うメアドで、
メールヘッダーのfromとtoは、メールの本文側に含まれる。
イメージとしては、郵便物の封筒側に書いてある送付元と宛先がエンベロープfromとtoで、
封筒内に入っている手紙の送付元と宛先がメールヘッダーのfromとto。
改行コードについては、RFCで\r\nにすることが定められているので、
Unixだからといって\nにしない事。
ページアクセス直後の初回発行のCookieにはセッションIDを含まない。
２回目以降発行のCookieにはセッションIDを含む。
以降は送信されたセッションIDと、
サーバー上に保存してあるセッションIDを比べて、
同一セッションかどうかを判断したり、
タイムアウトの有無を判断する。
セッションIDはCookieに含める以外に、
別途hiddenに設定して管理する方法もある。
１画面ずつテストまでしたら、
顧客にレビューして貰い認識ずれを防ぎながら、
開発していく。
ただし、システムでしたいこと(目的)は常に忘れないようにする。
ドキュメント要らない、仕様はあとで決めれば良いという考え方は危険。
特にコア機能においては、仕様をしっかり考えて設計しなければ、
最悪の場合、全部作り直しになりかねないので注意する。
一つのプロセスの中に複数のスレッドを作る。
プロセス同士はデータの共有が出来ないが、
スレッド同士はデータの共有が出来る。
しかし、スレッドはデータが共有出来るので、
スレッドセーフを意識しないと危ない。
クライアント側の入力チェックでOKでも、
サーバーに送信する際にPOST値を改竄可能な為、
サーバー側でも必ずチェックを行う。
HTML用(<など)とSQL用('など)でエスケープに必要な文字が違うので、
それぞれHTML出力「直前」やSQL実行「直前」でエスケープを行う様にする。
文字数一桁でもXSSを起こせるので、文字数が少ないからXSS起こせないと考えるのは危険。
PHPの場合、厳密にはENT_COMPATでOKな場合もあるが、
ENT_QUOTESにしておいた方が安全。
データ型が文字列以外は本来エスケープは不要だが、
例えば「IDが永久に数値型」であったり、
「DATEが永久に日付型」である保証は「無い」ので、
無条件で全てのパラメータに対してエスケープを行っておく。
PreparedStatementでLikeを扱う場合、
ワイルドカードではなく文字として%や_を扱う為に、
それぞれの文字の前にエスケープ文字を付与する。
この脆弱性対策に限らないが、「多重」防御は極力しない事を検討する。
関連：
脆弱性対策は「必要最小限」に
レスポンスを返す前に、
サーバー上のセッション変数と、
クライアントのhiddenにそれぞれ、
乱数を用いて生成した値を設定する。
そして、再度リクエストをした際に、
上記で設定したそれぞれの値が同一かどうかを判定し、
正常な遷移でリクエストされたかどうかを判断する。
セッションの乗っ取りを防ぐ為に、
セッションIDは定期的に振り直す。
PHPのereg関数など、
「\0」文字が不都合を起こす場合があるので、
リクエストされたデータ全てから「\0」文字を除去する。
例えば「../../../etc/passwdやshadow」と入力されたデータを、
ファイルの読み込みに使用すると、
ユーザー名とパスワード情報が全て判明してしまう場合がある為、
ファイルの読み込みに渡される引数には細心の注意を払う。
まず、可能な限りOSコマンドを実行出来る命令を使わない。
使う場合には、外部入力されたデータを引数に渡さないか、
チェックでNGにするコマンド名をphp.iniなどで別途設定しはじく。
