カテゴリー「IT覚書」の15件の記事

情報システムのお仕事にまつわるちょっとしたTipsもしくは備忘録。

2009年5月 3日 (日)

読了:「業務システムのための上流工程入門」

「業務システムのための上流工程入門-要件定義から分析・設計まで」(著:渡辺幸三)

 この書籍のコラムを読んで「はっ」と思ったけれど、確かに情報システムの業界には、設計業を専門に請け負う者が居ない。居るのは下流工程までを含めて行うシステムエンジニアまたはプログラマか、もしくは超上流である企画のみを行うコンサルタントという人だけだ。本当はシステム設計(システムアーキテクト)という職種があってしかるべきなのかもしれない。ここでいう設計とは「外部設計」とか「基本設計」と呼ばれる領域のことを指す。情報システムを構築する際、この領域こそがもっとも重要であることは誰もが認識している。けれど、それを専門的に行う人が、この業界にはほとんど居ない。

 情報処理技術者試験における旧アプリケーションエンジニア試験、今年度からのシステムアーキテクト試験とは、まさにこの上流工程の設計者をターゲットにしている。本当ならば、PMと同じくらいに重要で、人手不足な領域である。

 著者の方は、数少ない設計のスペシャリストなのだと感じた。こういう人をちゃんと評価する仕組みが、この業界にはまだまだ無い気がする。たいてい、設計の腕が良い人は、何故かプロジェクトマネジメントに注力する方向となり、やがて職種はプロジェクトマネージャーになってしまう。業務システムのアーキテクトは必要だと言うのに…。

 僕の場合、属している企業グループの特性から、ひとたび開発となると規模が尋常な数字ではなくなる。それがプロジェクトの巨大化に繋がり、上流工程への参加機会は、数としては多くなくなっている。また、巨大プロジェクトが多いということは、それだけでプロジェクトコントロールの困難性が増すため、とにかく求められるのはPM力だったりする。しかし、PM力だけでは何も生み出せない。やはりアーキテクトが居ないといけないんだろう。

 この本はそういうことをいろいろ考えさせられる。無駄なところがなく、実践的なスキルにつながる良書である。これは人に勧めても良い書籍だ。個人的にはユーザ企業の情報システム担当の人に読んで欲しいな。上流工程は、実は彼らの働きにかかっているのだから。…まあ僕もユーザ系システム子会社SEなので、立場はあまり変わらない。僕ももっとこういう本を読んで勉強すべきだと思った。
 改めて上級SEに求められるスキルとは何かがわかった。データベース概念設計やユーザインタフェース概念設計くらいを即興でできるくらいではないといけないんだな…。まだまだ勉強が足りないようだ。

 一日で読了する予定が三日もかかってしまったけれど。図書館へ行く機会をこうやって増やさないといけないな。

| | コメント (0)

2009年4月23日 (木)

ITニュース:この買収劇はけっこうショッキングだと思う。

 昼休みに自席でネットニュース見ていたら、「オラクルがサンマイクロシステムズを買収する」だって。これはけっこう業界的には大ニュースではないかな。Javaのオープンな環境は守られのかな。一応メモとして記す。

 …某芸能人の逮捕より僕的にはこっちの方がニュースだな。まあ僕は彼を俳優としては買っていたんだけれどな…。

| | コメント (3)

2009年3月30日 (月)

バックアップとか…。

 就業制限を理由に、一昨日、昨日と普通にお休みをいただいていたわけだけれど、明けた月曜日は、朝からバタバタしていた。もっとも僕は話には加わるけれど、基本的には戦力外。特に今月あと2日間は。

 業務運用開始ではないので幸いだと昨日書いたけれど、それでも開発プロジェクトとしては客先にシステムを提供しているわけだから、問題がある場合には基本的には即応体制としなければならない。まあ二桁億の開発プロジェクトだからね。リリース直後なんて、こんなものでしょう…などと言ったら今は強く叱責されてしまう世の中。厳しいね。

 僕はとりあえずできることをやるか。その一つがプロジェクトでこれまで協力会社から納品されたもの、もしくは我々が親会社に納品したもの。それらの整理。そして、使っていた共用フォルダ領域のバックアップ。

 バックアップなんて恒常化されて当たり前だと思うだろう。でも、そんな当たり前が当たり前に実施されているプロジェクトが本当にほとんどだろうか?

 少なくとも、僕が今扱っているプロジェクトは、すでにあるNASサーバには入りきらないほど膨大になってしまったので、自動的にはバックアップができていない。何ということだろう。だから僕が時々スナップショットを裏で取っている。

 Windows標準でバッチ処理に使えるコマンドはXCOPYだけだと思っていた。でもXCOPYってフォルダの階層が深くなりすぎると…具体的にはフルパスで256文字を超えると、そのファイルをコピーしてくれないどころか、そのときのエラー処理もしてくれない。

 でも、Robocopyというコマンドがあったのだ。「Windows Server2003 Resource Kit Tools」としてマイクロソフトのサイトからダウンロードできる。こっちの方がバッチ処理でバックアップに使う場合、いろいろ優れているようだ。特に長すぎるフルパスにも対応してくれる。

 Windows環境におけるフルパスの最大長は、けっこう謎に包まれているのだけれど、このリソースキットに添付されている解説を読むと「およそ32000文字」とある。本当かよ?

 まだ、使い勝手を自分のものにしていないので、解説はできないけれど、大規模な共用フォルダのバックアップには、こっちの方が良いかもしれない。

 …。

 というわけで、とりあえず今日の深夜に実行されるように仕込んでおいた。明日結果を見てみよう。

| | コメント (0)

2009年1月10日 (土)

[IT覚書][subversion]業務で大量のファイルを扱うときはやっぱりコマンドラインだね。

 どうしてもGUIの方がとっつき易い。それはそうだろう。僕もたとえばSVN(subversion)を業務で使い始めたときは、クライアント側では TortoiseSVN を使っていろいろと感触をつかんだ。TortoiseSVN は Subversion 本家との互換性がとても高く、Subversion のクライアント側の機能のほぼすべてを GUI で実行できる。
 もともと Subversion 自身が、サーバ機能とクライアント機能の両方を兼ね備えていることもあり、TortoiseSVN だけでも、ローカル環境に限定するなら、リポジトリの構築もできる。これはつまり、バックアップソフトとして Subversion を個人環境で使いたいといった場合には、TortoiseSVN だけですべて足りるということである。

 …。

 一方で、僕は業務システム開発の現場で、Subversion を使っている。ドキュメントサーバ(Windows Server 2003 R2 サーバ)に、Subversion 1.4.5 を導入している。そしてネットワーク上の共用フォルダに「作業コピー」を配置することで、複数のライブラリアンによるチェックができるようにしている。まだまだ運用は常に継続的改善中だけれど。

 「バージョン管理システムを導入しさえすればライブラリアンが必要なくなる」といった意見をよく耳にするけれど、それは絵空事だと思う。バージョン管理システムはあくまでも道具に過ぎず、ライブラリアンの仕事の効率化に一役買ってくれることは事実だけれど、そんなに言われるほど作業量を激減できるわけでもない。ライブラリアンはバージョン管理システムの仕様を踏まえ、相性の良い運用を行わなければならない。そう。バージョン管理システムの仕様をしっかりと押さえた上で運用しないとかえって作業量が増えることもある。

 …。

 現時点での最新バージョンは、1.5.4 あたりのはずだけれど、このバージョンでも「タイムスタンプの保持」の問題は解決されていない。バージョン管理とは一種の文化だから、仕方がないのかもしれない。SVNを開発している人たちの頭の中には「タイムスタンプを固定してしまうと、それはけっこう前の日時情報を持つことになるので、タイムスタンプの更新をビルドのトリガーにしているようなプロジェクトでは、とても危険な行為じゃないか」…という考えがあるんだろう。

 しかし、僕の所属している(もしくはしてきた)プロジェクトの文化では、内容的に何にも変わっていないファイルのタイムスタンプが、チェックアウトされただけで変更されてしまうことに、逆にものすごい違和感を感じるんだ。つまり、バージョン管理システムにはいっさいファイルが持っているタイムスタンプをいじってほしくないのだ。タイムスタンプを変更するのは「そのファイルを実際に開いて保存した人」だけにしたいのだ。

 今後、現行システムの保守をやっているチームにもSVNを知ってもらい、使ってもらう必要があるけれど、このタイムスタンプ問題は、必ず問題視されるだろう…。

 …。

 現時点で、その問題を少しでも軽減しようと思うなら、「ファイルの日付を"最後にコミットした日付"に設定する」というオプションを使うことくらいしかない。Subversion,TortoiseSVN ともに初期設定ではオフになっているオプションだ。

 TortoiseSVN では「設定」画面でそのオプションのオン/オフを設定できる。それでは、コマンドライン版の Subversion ではどうするのか。けっこう悩んだけれど、クライアント側の設定ファイルを書き換えることで同じことができるのがわかった。

 WindowsXP であれば、下記の位置に設定ファイルが作られている。(隠しフォルダなのでエクスプローラの表示設定を変える必要がある)

 C:\Documents and Settings\
  [USERNAME]\Application Data\
  Subversion

 ここに、config という拡張子もないテキストファイルがある。この内容を編集する。

# use-commit-times = yes

 という行がある。これは先頭に「#」がついてコメント行扱いになっている。これを有効化する。

use-commit-times = yes

 ここでの注意点は、行頭にスペースを入れないことである。

 …。

 ついでに、同ファイル内に、editor-cmd 行も有効化/修正しておけば、コマンドライン版 Subversion からリポジトリにメッセージログをスクリーンエディタで編集することができる。

editor-cmd = %SystemRoot%\system32\notepad.exe

 こうすれば「メモ帳」が登録される。
 注意点は、同じく行頭にスペースを入れないことである。

 …。

 使い方にもよるけれど、たいていの小規模なコミット(チェックイン)ならば、TortoiseSVN のGUIでやった方が良いだろう。でも、大規模な開発プロジェクトにおいて、ものすごく大量のファイルをコミットする場合、作業の証跡を残すと言う意味でも、コマンドライン版を使用して、確実にログを取ることが望ましい。

 ここで誤解しないでほしいことは、コマンドライン版 Subversion に特殊なロギング機能があるわけではないということ。もしそんな機能があったならば、GUI版の TortoiseSVN にも実装されていたはずだ。

 コマンドラインでは、普通に標準出力(またはエラー出力)をリダイレクトできるというだけである。

 変更をチェック(svn status)の場合なら

svn stat [パス名] >> [ログファイル] 2>&1

 …という感じで。

 …。

 それにしても、最近の人たちはコマンドライン操作に、本当に慣れていない。これも Windows がもたらしたものだろう。
 Unix/Linux 環境のファイルを操作するのに、FFFTP (ftpクライアントのGUIソフト:優れたフリーソフトだ) で、それをあたかもファイルエクスプローラみたいな使い方をしているんだもの。
 その使い方はどうなんだ?

 まあ、これはおじさんの愚痴だな。

| | コメント (1)

2008年10月25日 (土)

[IT覚書][Windows]コマンドラインからフォルダを全消去する方法。

 つまり、UNIXでいうところの「rm -rf」をDOSコマンドでやる方法。(厳密にはもうDOSなどという言葉は死語ですね。Windowsのコマンドプロンプトという方が正しい)

 昔はディレクトリと言っていたものをフォルダと言うようになったのはWindows95からかな。昔のMS-DOSではディレクトリと呼んでいた。僕は頭の中でいつもフォルダ→ディレクトリと変換している。(いまでもUNIX/Linuxでは普通にディレクトリと言うけれど)

 まあ、そんなことはさておき。パッとやろうとして「どうやるんだったっけ?」となったのが、フォルダ全消去。Windows Server 2003 R2 上で動くバッチファイルの中で書きたい。

 DOSにも rmdir コマンドはあった。さらには一時期 deltree などという怪しげなコマンドもあったようだ。(これは使ったことはない)
 rmdir /? でヘルプを出して確認。普通に rmdir /s /q で行けそうか? 試してみると「ファイルが存在する」という理由でエラーを返される。

 これは昔からのDOSの仕様なのか、ファイルとディレクトリとは別に考えるようになっている。大まかに言うと、del は主にファイルを消去するコマンドであり、rmdir はディレクトリだけを消去するコマンドである。

 以下のような順序で実行すると、複数のファイルを含んだ多重構造のディレクトリを消すことができた。

  del /s /f /q [dir]
  rmdir  /s /q [dir]

 ただし、厳密に言うと UNIX系の rm -rf (ディレクトリを再帰的に消去し、確認メッセージも出さないで強制的に実行する)とは、ちょっと違うことが起こる。
 del コマンドにおいて消去されたファイル名が標準出力ストリームに出てくる。
 まあ、僕は情報が何も出ないよりは出てくれた方がうれしいので、上記のやり方で問題ないと思っている。画面に標準出力を向けたままでは、ただ画面が流れるだけなので、もちろん以下のようにするのが普通である。

  del /s /f /q [dir] >> [logfile] 2>&1
  rmdir  /s /q [dir] >> [logfile] 2>&1

 こうすると任意名のログファイルに標準出力とエラー出力の両方が出力され、画面には出力されない。こういったリダイレクションは、もともとUNIXからDOSに引き継がれた仕様なので、同じようにできる。だが、UNIXでできるリダイレクションがすべてできるわけではない。Windowsのコマンドプロンプト用のシェル「CMD.exe」は、UNIXの各種シェルに比べると貧弱である。

| | コメント (0)

2008年9月18日 (木)

現場の実態。

 現プロジェクトは従来からのウォーターフォール開発プロセスだ。大規模は未だにこれが現実だ。
 一方で、当社の開発基盤は、「バージョン管理」を日常的に行いながら「継続的インテグレーション」(CI)を行うことを推奨している。バージョン管理は subversion を使い、CI は CruiseControl を使う。両方共にOSS(オープンソースソフトウェア→無償)だ。CI とは、プログラムの単体テストとビルドを自動化して毎日のように実行するやりかただ。(定期ビルドと定期テスト)
 これはウォーターフォールのような直列的な開発プロセスには適用しづらい。こういうのはテスト駆動型のプロセスで最大の効果を生む。(少なくとも僕はそう理解している。もしかすると違うのかもしれない)
 またまた一方で、当社の「PM標準」というものでは、開発プロセスは従来型(ウォーターフォール)を標準としている。

 僕はいまのプロジェクトの状況を様々な視点から勘案しても、バージョン管理は保守を見据えても実践すべきだけれど、定期ビルドなどといった CI は、導入できないと考えた。
 そもそも今月中に、バージョン管理に使うリポジトリの整備と、手動によるビルド環境を、なんとか構築すべく、若手への働きかけをしながらギリギリでやっている。この状況下で僕にとっては未知な「継続的インテグレーション」はとても導入できない。
 …というか、既に工程が結合テストに入っている局面では遅い。また、僕の中に CI を導入した場合の良いイメージがないことも理由だ。わからん者がわからんモノを導入してはうまくいかない。

 ああでも、開発基盤の人たちからは、だらしなく思われるのだろう。現場の言い分もあるにはあるが、あまり言っても平行線だろうし。

 僕があと1.5倍くらい働けたら、状況は異なっていたかもしれないけれど、それもタラレバに過ぎない。

 来週のリーダー会議でははっきりと言おう。CI はやらない判断をしたと。

 未来にあるであろう新規開発では、もっと初期の段階から構成管理環境を整えよう。

| | コメント (1)

2008年8月10日 (日)

[IT覚書][Linux][subversion]rpm形式の最新ではないバージョンを取得する。

 日記に書いているように、職場でのドキュメントサーバ(Windows Server 2003 R2)におけるバージョン移行(1.3 系→ 1.4 系)は先週実施できた。後はビルドサーバ(Linux:RHEL)における svn クライアントの移行や導入が残っている。Red Hat だから rpm でインストールする。そのやり方を事前に整理してみた。

1.インストールしたい subversion の
 パッケージを取得する

1-1.svn本家URL <http://subversion.tigris.org/>

1-2.「Get Subversion」という部分から「Red Hat binaries」<http://subversion.tigris.org/getting.html#redhat>を選択→リンクへ移動

1-3.「SummerSoft」<http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/>を選択→リンクへ移動

1-4.svnのバージョン1.4系が欲しいなら、「rhel-4/」を選択→リンクへ移動

1-5.インストール対象マシンのCPUアーキテクチャがインテル386であれば「i386」を選択→リンクへ移動

1-6.例えば 1.4.5 が欲しいのであれば、「subversion-1.4.5-1.i386.rpm」が対象のパッケージとなる→それをダウンロードする
(1.3系はディレクトリは存在するけれど、1.3系そのもののrpmは無いみたいだ…)

1-7.パッケージの検証

 作業用ディレクトリにrpmファイルを配置して

$ md5sum ./subversion-1.4.5-1.i386.rpm
$ rpm --checksig ./subversion-1.4.5-1.i386.rpm
$ rpm -K ./subversion-1.4.5-1.i386.rpm  などなど

2.インストールされているパッケージを削除する

2-1.作業ディレクトリに移動

2-2.インストール状況を確認

$ rpm -q subversion
$ rpm -qi subversion
$ rpm -qa | grep subversion
$ rpm -qa | grep svn
$ rpm -qR subversion
$ rpm -ql subversion
$ rpm -qf /usr/sbin/svnseve
$ rpm -qRp subversion-1.3.1-1.i386.rpm  などなど

2-3.アンインストールを実行

$ rpm -e subversion

(-e:--erase)

-v が効くなら -ev

3.新バージョンをインストールする

3-1.これからインストールされるファイルを調べる

$ rpm qlp ./subversion-1.4.5-1.i386.rpm

3-2.新規インストールの実行

(testing)
$ rpm -ivht ./subversion-1.4.5-1.i386.rpm
(go)
$ rpm -ivh ./subversion-1.4.5-1.i386.rpm

echo などで実行ログをとることを忘れずに…。

(echo 時に -h:--hash オプションがどうなるのかちょっと不明)

3-3.アップデートインストール(参考)

 今回はこれを使う予定はないけれど参考までに。

$ rpm -Uvh ./subversion-1.4.5-1.i386.rpm

$ rpm -Fvh ./subversion-1.4.5-1.i386.rpm

 通常にアップグレードという意味では -U みたい。-F との違いはちゃんと調べた方が良さそう。

いまは家では試せないので、とりあえずのメモ。

| | コメント (1)

2008年8月 7日 (木)

今日の日記:まあマイペースですよ。

 今日、午前は昨日の説明会の議事まとめ。僕は昔から議事録は過剰なくらいに書く。「議事録」は近年では「議事メモ」と呼ばれるようになって内容も簡素なものとなっている。内容が薄くても書かないよりはマシだという考え方が主流になりつつある。

 午後はLinuxサーバへの subversion インストール手順を調べた。開発基盤の人とも話した。Linuxでも業務サーバでは圧倒的なシェアを誇るのがRHEL(Red Hat Enterprise Linux)である(あくまでもLinuxではだけれど。数的にはWindowsServerの方が多い)。Red Hat だからrpm形式のパッケージなんだろうと思っていたら、やっぱりそうだった。パッケージ管理システムがちゃんと動いてくれればすんなり行くだろうけれど、ハマると怖そう。

 先日ちょっと愚痴を言った情報処理技術者試験の件。今日インターネット申し込みをした。10年以上受けていない高度試験は何を受けようか迷ったけれど、PM(プロマネ)にした。はっきり言って一発では受かりそうに無い。それでもテクニカルエンジニアネットワークよりは、僕にとっては与しやすいと思える。将来的にはネットワークやデータベースが欲しいところ。

 まあマイペースですよ。

| | コメント (4)

2008年8月 5日 (火)

昨日と今日の日記:この時期HDDクラッシュに注意せねばいけなかったのに。

 先週の金曜日に、ドキュメントサーバ(WIndowsServer)のバックアップスクリプトを流したまま帰宅した。それに伴ってローカルPCも起動したままだった。この蒸し暑い中、それはPCのハードディスクには災いしたようだった。
 月曜日に自席のPCを見てみると、画面は真っ暗でHDDからは異音がする。一発で「あーHDDがヤバいかも」と思った。湿度と温度が高い状況はHDDにとても良くないのだった。
 案の定、いろいろ手を尽くしたものの起動はできなかった。水曜日(明日)に開催予定のsubversionの説明会
にも使おうと思っていたのに。それでなくとも長年使ってきたいろいろな環境が入っていたのに。かなりショックだ。

 一方で、昨日と今日とで、ドキュメントサーバの subversion のバージョンアップ作業も決行した。他プロジェクトで既に保守運用に入っているリポジトリもあったので、慎重に行う必要があった。けっこう難航した。サーバサービスの起動という、ソフトの種類にあまり依存しなさそうな部分でハマった。
 まだLinuxサーバの方が残っている。どうやるんだ? LinuxでRed Hat系ならrpmパッケージだと思うので、パッケージ管理システムでインストールするんじゃないかと思っていたけれど、違うらしい。
 まあこれは後日改めてとなった。

 やっぱり実際に手を動かさないとわからないものだと改めて思った。

 なんだかんだと、見かけよりも余裕がない。あいかわらずギリギリの日々だ。

| | コメント (1)

2008年8月 1日 (金)

[IT覚書][subversion]最新版管理だって難しい。

 つい昨日、TortoiseSVN の 1.5.2 がリリースされたようだ。対象 svn サーバのバージョンは Subversion 1.5.1 である。
 1.5.x 系が安定するのはもう少し先かもしれない。

 バージョン管理システムというのは一種の文化であり、本来ならば何気なく運用されるべきなんだろう。そしてそのためには、プロジェクトに参加している人すべてが、バージョン管理システムの仕様を理解していないといけない。一部の人だけが知っていても意味が無い。

 ちょうど一年前携わっていた、大規模システム開発の基本設計において、僕は構成管理の役目を担ったので、まずネットワークで共用しているドキュメントサーバにおけるディレクトリ/ファイルの命名規則などを作った。
 最も口を酸っぱくして言い続けたことが「ドキュメントの最新版が入っているディレクトリには最新版だけ入れて古いファイルは消してしまうか別ディレクトリに移動させろ」ということだった。

\010_最新成果物
\020_成果物履歴

 などというディレクトリ名を決め、ここでいう「\010_最新成果物」の中には、文字通り最新の成果物しか入れてはいけない。同じディレクトリに日付で区別された複数の版が存在していてはいけない。
 このことを割と初めの段階から言い続けていたので、大人数で一斉にドキュメントを作成したときにも大きな混乱はなかった。これはバージョン管理よりももっと基礎となる「最新版管理」だ。なんだそんな基本的なことか。そう言われるかもしれない。でも、これは皆がちゃんとやろうとしないとすぐに崩れる。

 バージョン管理システムをちゃんと使えば、このようなことをしなくても良くなる……はずである。あくまでも、バージョン管理システムがどういうものかを皆が理解して運用することが前提となる。

 来週、グループ内部向けに、3回めとなるsvnの説明会をやる予定。啓蒙活動である。

 …開発言語に関する話題はまたいずれ…。

| | コメント (2)