久しぶりに見る自分のブログは懐かしく、

そのときの考えに立ち戻れますね。

またぼちぼち始めますか。

3月末までで、今までの担当者が去るためです。

でも、正直言って引継ぎって何をしたらよいのかわかりません。

時間がたっぷりあるなら、毎日朝から晩まで、機能一つ一つを説明してもらって、資料を作ってもらって。。。。とできるかもしれないんですが、引継ぎ中というのはたいてい、引継ぎする側、される側のどちらかは忙しく、引継ぎにかけられる時間なんてホント限られています。

今回も例によって、今の担当者はテストと、バグ修正に終われる毎日。私もテストの手伝いで引継ぎらしい作業はなかなかできません。

おそらくは、このまま月末までほとんど引き継げないままに今の担当者は去っていくでしょう。

4月から苦労するのは自分です。。。

効率的に引継ぎを行う方法ってないんでしょうか？

毎回の悩みです。

まぁ、ソースを順に追っていけば何とかならないことはないんですけど。

やっぱり余分な時間を費やすことになります。

今回はソースの整理と、コメント付加を重点的にお願いして、資料などの作成など、時間のかかる作業は省略するつもりです。

引継ぎって難しい。

私の名刺には部名があるのみで肩書きらしいものは何もありません。

なので、たとえば、ハケンの面接に行く場合、名刺からは社名と名前がわかるくらいで、大して役に立っていないと思います。

ITエンジニアにとって、肩書きって重要なんでしょうか？

面接の時には、経歴書を提出するので、それによって、その人のスキルは把握できます。

なので、肩書きって別に必要ないのです。

でも、カッコのよい肩書きがあれば、名刺を渡したときの、相手の印象も若干変わってくると思います。

以前ハケンに出ていた会社では、肩書きを自分で決められるようでした。

極端な話、「社長」でもよかったみたいです。

なので、その会社では、「プロジェクトマネージャー」がやたら多かったし、新入社員でも「システムエンジニア」でした。

実際にはその肩書きに即していない人がほとんどで、一緒に仕事してみて初めて「どこがプロジェクトマネージャーなんだよ！」って思う人が多々おりました。　うそはいけません。詐欺です。

現在、私の会社では、名刺に肩書きを付加しようという動きがあります。

自分のスキルにあった、ふさわしい肩書きを名刺にも入れたいものです。

もともとCSV形式の計画だったためか、タブ区切りなのに「CSVファイル」って呼んでいました。

一般的にはタブ区切りの場合はTSV形式って言いますね。

TSVにしたのは、単にカンマがデータ内に入る場合があるからってだけなんですが。

もちろん、CSVでもデータを””で囲んで、処理するなどの方法はあるんですけど、その時は時間がなかったので、タブ区切りにしてしまえって勢いでした。

まぁ、特にタブ区切りにして困ったことはなかったです。

でも、TSV形式があまり推奨されることはありませんね。

EXCELのセルをコピペすると、タブ区切りになりますんで、テストデータ作る時なんかは結構便利でした。

CSV形式はいまいちルールがあいまいで、汎用的な読み込みクラスとかってあんまりないんですよね。

毎回プロジェクトごとのルールに従って、作る必要がある。

XML形式なんかも増えていますが、やはり昔からの業務系システムは、データ移行のこともあってかCSV形式が多いですね。

CSV形式は今後もずっと生き残るんでしょうか？

ちなみに、関係ないですが、PHPではINIファイルが扱えます。

INIファイルなんて、Windowsプログラムだけのものかと思っていましたが、PHPってなんか変わっています。

最近では.NETでもAPI使わないと直接INIファイルにアクセスできないのに。。。

でも扱いはとても楽ですよ。

ハケンをやっているといろんな言語を触りますが、プロジェクトのたびに違うので覚えるのが大変です。

どの言語も広く浅くって感じです。

で、PHPですが、現在リファレンスブックを買って勉強中です。

ほかの言語に比べると痒いところに手が届くっていうか、便利関数満載です。

特に配列がすごい。

配列としても、コレクションとしてもハッシュテーブルとしても使えてしまったりして、とても柔軟です。

でも、Javaなどの変数宣言をきっちりする言語に慣れししまっているためか、PHPのとても自由な書き方には少々戸惑っています。

どうにでも書けてしまうんですが、できる限り見やすいソースとなるよう研究しながら実装していきたいと思っています。

でも、本当に難しいのはPHPよりも、一緒に組み合わせて使うJavaScriptかも。。。

いつの間にやら周りが年下ばかりになっています。

私はIT業界に来たのが遅いので、年長でもスキル的には４，５年下の人と大して変わりません。

年齢は関係ないんですが、やはり年上としては焦りを感じてしまいます。

関係ないけど、年齢に応じたスキルをやはり要求されてしまいますので、頑張らねば！と再認識しました。

何気にずっと見ていたんですが、自分がハケンについているからなのか、まるで自分のことのように見ていました。

ドラマに出てくるハケンは、事務業務なので、私のような専門職（SE)ハケンとは違うんですが、会社からの扱いとしては大して変わらないと思います。

まぁ、ドラマなのでかなり脚色されていてありえない場面も多々ありましたが、面白いドラマでした。

個人的にはハケンよりも正社員として自分の会社の仕事（請負など）をしたいんです。

今は、ハケンを通じていろんな会社からスキルを学んでいるって感じです。

この前もあるプロジェクトのハケン業務を終えたんですが、やはり別れはさびしいです。

半年以上一緒に仕事をしてきた人たちとほぼ永遠にお別れでした。

そこがハケンのよいところであり、悲しいところです。

早く請負の仕事を自信を持ってできるように勉強します！！！

WEBアプリ開発者なら常識なのかもしれません。

恥ずかしながら私は先ほど初めてこの言葉を知りました。

ネットで調べ物をしてたときに引っかかりました。

どういうことかというと、ログイン画面のチェックロジックが以下のようなSQLになっていた場合、

SELECT * FROM user WHERE userid='" & userId & "' AND password='" & password & "'"

ユーザ名、パスワード欄に「' OR 'A'='A」と入力すると、実行されるSQL文は、

SELECT * FROM user WHERE userid='' OR 'A'='A' AND password='' OR 'A'='A'となります。

このSQL文だと、WHERE句に指定した条件が変わってしまい、ログイン可能となってしまいます。

さらに、ユーザIDが分かっていれば、普通のログインとなんら変わらない状態でシステムが利用可能状態となりますので、ログインチェックの意味がなくなります。

こういったSQLの差込をすることをSQLインジェクションというらしいです。

実装によっては、DELETE文やUPDATE文も差し込める可能性があります。

何でも以前のカカクコムの情報流出事件は、この方法が使われたとか？

SQLインジェクションができるってのは、明らかにシステムのバグで、原因がはっきりすれば、作った側にも責任が生じるんじゃないかと思います。

私は、今まで外部に公開しない、社内専用の業務システム開発がほとんどでしたので、あまり気にしたことが無く、ログインロジックは実装するものの、実運用ではユーザが１種類しかなかったり、パスワードを設定していなかったり、ユーザ名とパスワードが同じだったりと、作る側も、使う側もセキュリティをあまり意識していなかったので、多分今まで作ったシステムの中にもこの手法が使えてしまうものがあるような気がします。

SQL文を入力欄に書くなんてテストはやっていませんし。

ちょっと気になって、今作っているシステムのログイン画面で、

同じように入力してみたところ・・・ログインできてしまいました！！

まぁ、今作っているシステムは、ログイン画面どうこう以前に、URL直書きすれば好きな画面を直接開けてしまったり、重要な引数をQueryStringで渡していて丸見えなので、セキュリティなんて無いに等しいのですが。

もっと真剣に考えていかなければいけません。

まだまだ勉強不足です。