IT土方のReminder -2ページ目

IT土方のReminder

英語なんて全く出来ないくせに気が付いたら外資系IT企業のサポートエンジニアになっていた人のブログ。このブログに書いてある事は間違っている可能性もあるので気づいた人が指摘してくれても良いし、指摘しなくても良い。


日本人的な管理なのか分からないけど、ガントチャート上に日付表示がないとスケジュールを管理しにくく感じる。

Redmineのガントチャートでは週の表示はしてくれるものの、日付表示がないので今日が何日なのかよく分からない。

なのでアドインで表示できないか探したんだけれどどうやらそんなものはないらしい。

色々調べたら親切な人がRubyの改修コードを掲載してくれていたのでコピペさせてもらった。

http://ultrah.zura.org/?p=3985

だけれど、IEの8.0.6では表示されない模様。IEの8.0.7にバージョンアップしてやっと表示された。

これで少し管理しやすくなった。

と思った矢先、今度はチケットの依存関係がIEの8.0.7では削除出来ないバグが発生。多分javascriptのせいなんだろうけど、誰も改修コードを出していなかったので、僕の力量ではどうすることもできず、しばらくはIEの8.0.6と8.0.7の両方で運用するしかなさそうだ。


iPhoneからの投稿
Excelベースのレガシーなプロジェクト管理もアレので、Redmineを導入した。

ちょっと使って見たところ異様にチケットの登録や更新といった挙動が遅い。
文書やニュースの更新はサクサク動くのにもかかわらず。

よくよく調べてみると、どうやらメール通知の設定が問題のようだった。
デフォルトのsmtpサーバがgmailだかで、認証をパス出来なかったのがトリガーのようだ。

社内でシステムメール発信するには申請やらなんやらで面倒なので、メール通知機能は不要という僕の独断と偏見で、Redmineの設定画面からメール通知機能をOFFに変更した。

結果、チケット登録、更新もサクサク動くようになったので良かった。

バッチファイルの変数ではまったので書き留めておく。
for文とif文の中では変数の処理のされ方が異なる。

以下のように書くと変数のnumに思ったように値が入らない。

===================ここから===================
@echo off
rem 変数のテスト
set /a num=0
for %%i in (*.txt) do (
set /a num=num+1
echo count:%num%
)
echo count:%num%
===================ここまで===================

フォルダ内のテキストファイルをカウントするバッチとなっているが、
実行結果は以下となる。

IT土方のReminder


for文の中ではnum変数のカウントアップがされていないことが分かる。

これはdosの仕様上、for文の中は1行として処理されるため。

つまりfor文の1行前までにセットされていたnumの値がエコーされている。

従って、for文を抜けると正しくカウントアップされた結果が表示される。


この場合「setlocal ENABLEDELAYEDEXPANSION」を宣言することで

回避できる。ちなみにこれを利用する場合は変数の宣言時は%ではなく

!でくくる必要がある


===================ここから===================

@echo off
setlocal ENABLEDELAYEDEXPANSION

rem 変数のテスト

set /a num=0

for %%i in (*.txt) do (
set /a num=num+1
echo count:!num!
)
echo count:%num%
===================ここまで===================

実行結果は以下。


IT土方のReminder

これで正しくカウントされる。


ちなみにerrorlevelを使ったエラーの判定を行う場合も同様に、

この処理で遅延環境変数の遅延部分を制御できる。

Exchangeもそろそろ勉強しないとやばくなってきたので、自習をかねて

自宅に評価環境を構築しました。


プレミアムジャーナルはハブサーバの設定画面に「ジャーナルルール」

というタブがあるのですぐにどこから設定するのか分かるのだけれど、

標準ジャーナルについてはどこから設定していいのか戸惑ったので

メモをしておく。。。


標準ジャーナルはExchangeのメールボックス単位でしか設定できないため、

なんとなくメールボックスサーバから設定するんだろうなと思っていたけれど、

どこで設定するのか分かりにくい。


また事前準備としてジャーナルするためのアカウントを一つ作成する必要があり、

このアカウントにメールボックスDBのメールを転送しているという構造になっている。


EMCの[組織の構成]-[メールボックス]-[データベースの管理]タブの中に

メールボックスのデータベースがあるので、対象のDBを右クリックプロパティ


IT土方のReminder

プロパティの[メンテナンス]タブの中に[ジャーナルの受信者]にチェックを入れ、

[参照]からジャーナルしたいメールボックス(ユーザ)を指定するだけでOK。


IT土方のReminder


ジャーナルが出来ているか確認するために、試しにメールを出してみる。

TestUser01というアカウントからMail01というアカウントへテストメールを

出してみる。



IT土方のReminder

ジャーナルを設定しているユーザ(この環境でJournalというユーザ)の

アカウントでOWAにログインし、mail01に送信されたメールが入っているか確認。


IT土方のReminder

期待値通り、Journalのメールボックスにメールが配信されていました。

ちなみに、ジャーナルメールボックスにはメール本体は添付で転送される

みたいなので、本文を見るには添付を開かないといけないみたいです。


IT土方のReminder


サービスマネジメントとインフラSIのマネジメント、どちらも経験すると
プロマネに技術力は必要なのかどうか、良く分からなくなってきた。

SIのマネジメントをやるにはプロマネの技術力は必須じゃなかろうか?
エンドの要件を満たすには何が必要で、何がリスクなのか知るためには
技術力が必要だと思う。

確かに、プロマネが技術を知らなかったとしても知っているSEを集めれば
良いのだけれど、僕の経験上、そういったSEがいても必要なものが何か、
リスクは何かを予見することができないことが多い気がする。

ただ、知っているがゆえに技術にばかり口出しをしてしまい、うまく「管理」
できなくなるプロジェクトがあることも事実。

技術がある、ないでどちらが良いのだろうか。。。

経験則だけれど、やはり技術力があるプロマネのほうがプロジェクトがうまく
行くことが多い気がする。

僕は、やはり「技術を知っている」プロマネのほうが良いと思う。
知らないことで俯瞰的にプロジェクトを見つめることができたとしても、
知らないことによって見落としているリスクのほうが多い気がする。

技術を知ったうえで、以下に俯瞰的に物事を見るか、これがプロマネに求められる
力なんだと思う。

プロマネが技術を知らないというのは、技術を勉強しないことを正当化しているような
気がしてなんだかやな感じ。。。