方向性未定のブログ

今は仕事の備忘録や思ったことをメモしている。

jQueryのDatepickerをStruts1.x環境で使ってハマったところメモ

Struts1.xで日付入力にカレンダー表示から日付選択して入力させる。

Struts1.xはHTML5が使用できないし、Strutsのカスタムタグもカレンダー表示なんてリッチな機能はない。

そこでjQueryのDatepickerを使ってみたが、ハマったので内容をメモしておく。

実現したい機能

  • Datepickerを使った日付の入力画面がある。<html:text>のStrutsタグを利用している。
  • 日付を入力後submitボタンを押下すると入力内容の確認画面に遷移する。
  • 入力確認画面から戻るボタンを押すと入力画面に戻る。
  • 入力画面に戻ると入力済みの情報が引き継がれている
  • Strutsタグを使っているのでフォームのデータの受け渡しはActionFormを経由している。

問題点

戻るボタンを押下して画面遷移すると、日付の入力データが引き継がれていない。

原因

Datepickerのoption設定処理時にActionFormから取得した日付情報が削除されていた。

対応

変数に日付情報を退避し、dateFormat後に再度日付情報を取得する。 具体的には以下のような感じだったはず。記憶を頼りに書いているので間違っていたら後日修正しよっと。

<script>
$(function(){
    $(“#datepicker”).datepicker();
    var date = $(“#datepicker”).val();
    $(“#datepicker”).datepicker("option", "dateFormat", 'yy/mm/dd').val(date);
});
</script>

PowerShellでテキストファイルの行数を取得する

概要

PowerShellでテキストファイルの行数を取得する時の覚書

例文

$DataLength = (Get-Content $filePath | Measure-Object -Line).Lines

解説

まず、Get-Content $filePath で$filePathの情報を オブジェクトとして取得している。

それをパイプでMeasure-Objectに渡して計測すると、

$filePathのオブジェクトに対するMeasure-Objectによる評価が 各種パラメタに入る。

Measure-Objectのオプションで-Lineを指定すれば行数のみをカウントしており、 その結果を().Linesで$DataLengthに渡している。

Measure-Objectのオプションで-Lineを指定しなくても、 ().Linesで行数を渡せるが、デフォルトではすべての値を計測しているので、 行数だけが必要であれば-Lineを指定したほうが処理速度が早くなる。

Powershellで特定の文字列に一致したらその部分だけ取得する

文字列のなかから特定のパターンの文字列に一致した場合、一致した文字列を取得する。

例1.ユーザIDを抜き出す。

$strIdPattern = [regex]"([hH][oO][gG][eE]¥d{3,})"
$userid = $strIdPattern.Matches($_) |%{$_.Groups[1].Value}

例2.日時を抜き出す(YYYY.MM.DD hh:mm:ssのフォーマットの場合)

$strDatePattern = [regex]"(¥d{4,}¥.¥d¥d¥.¥d¥d ¥d¥d:¥d¥d:¥d¥d)"
$strDate = $strDatePattern.Matches($_) |%{$_.Groups[1].Value}

sedの基本

sedの基本

コマンド文法

sed [-e,-f,-n] 'instruction' file > file

解説

オプション

  • [-e]
    オプションeの後には必ず命令があるという意味になる。 複数の命令をする場合、-e 命令文 -e 命令文 とすれば複数の命令を行える。

  • [-f]
    命令文を記載したファイルを指定する場合のオプション

  • [-n]
    全ての入力行を出力するのがsedの基本動作で、-nを指定することで出力されない。 このオプションを指定したときのみ、命令文にpを指定し、変更箇所のみ出力できる。

  • 'instruction'
    命令部になり、シングルクォーテーションで囲むことで、空白や特殊な文字を そのまま命令として渡すことができる。

  • \> file
    リダイレクションで出力先の指定をする。 省略すると標準出力に出力されるため、通常は変更後のファイルを指定する。

命令文

置換

  • 命令文の例
    sed 's/pattern/replacement/p' file

    • s 置換を意味する。ほかにa追加i挿入c変更などがある。

    • pattern スラッシュで囲まれた内容は正規表現で置換対象になる。

    • replacement 置換後の内容も正規表現で表す。

    • p オプションに-nを指定した場合に変更箇所のみ出力する命令。

削除

  • 命令文の例 1
    sed '1d' file

  • 1d 1は一行目を表す。

  • $d $は最終行のみ削除する。正規表現の行末を表す$とは違う。

  • /^$/d /で囲み、正規表現で^$を指定すれば、空白行のみ削除することができる。

  • 50,$d 50行目から最終行までを削除することができる。

パターンを以下のように指定することで、適用範囲を指定することができる。
* 命令文の例 2
list.txtの内容が以下のようになっているとする。

John Daggett, 341 King Road, Plymouth MA
Alice Ford, 22 East Broadway, Richmond VA
Orville Thomas, 11345 Oak Bridge Road, Tulsa OK
Terry Kalkas, 402 Lans Road, Beaver Falls PA
Eric Adams, 20 Post Road, Sudbury MA
Hubert Sims, 328A Brook Road, Roanoke VA
Amy Wilde, 334 Bayshore Pkwy, Mountain View CA
Sal Carpenter, 73 6th Street, Boston MA

以下のようなコマンドを実行する。
sed /MA/,/VA/d list.txt

実行結果
Orville Thomas, 11345 Oak Bridge Road, Tulsa OK
Terry Kalkas, 402 Lans Road, Beaver Falls PA
Amy Wilde, 334 Bayshore Pkwy, Mountain View CA

以上

findコマンドの実用

findコマンドの基本とその実用

コマンドの基本的な文法とオプション

  • find /対象のディレクトリ -name キーワード
  • find /対象のディレクトリ -iname キーワード
    (-inameは大文字小文字を区別しない)
  • find /対象のディレクトリ -regex キーワード
    (検索ファイル名に正規表現を利用する)
  • find /対象のディレクトリ -size サイズ(ブロックサイズ)
  • find /対象のディレクトリ -type タイプ
    タイプに以下を指定することで特定のタイプのファイルを検索できる
    • b
      -typeにブロックデバイスを指定する
    • c
      -typeにキャラクタデバイスを指定する
    • d
      -typeにディレクトリを指定する
    • p
      -typeに名前付きパイプを指定する
    • f
      -typeにファイルを指定する
    • l
      -typeにシンボリックリンクを指定する
    • s
      -typeにソケットを指定する
    • D
      -typeにdoorを指定する(Solarisのみ)

実用

 特定の文字列が含まれるファイルおよびディレクトリを検索する

  • 文法
    find . -name ファイル名
  • 処理の概要
    指定したファイル名のファイルがカレントディレクトリおよびその配下に存在すればそのパスを出力する。
    ファイル名には正規表現ではなくシェルで使用できるようなワイルドカードが使える。

  • 使用例
    find . -name '*support*'
    カレントディレクトリおよびその配下に support が含まれるディレクトリおよびファイルを検索している

 findの結果を別のコマンドに渡す例

  1. grepに渡す
  2. 文法
    find . -name 検索したいファイル名 | xargs grep -al 検索したい文字列
  3. 処理概要
    findコマンドで検索した結果をさらにxargsで行単位でgrepに渡して出力を絞り込んでいる。
  4. 使用例
    find ${MY_LIB} -name '*.jar' | xargs grep -al 'org/apache/.*/InvokerTransformer'

  5. cpに渡す

  6. 文法1
    find . -name 検索したいファイル名 | xargs cp -p --target-directory=コピー先
  7. 処理概要
    findの結果を行単位でcpの第一引数に渡していることで、指定したコピー先にコピーしている。
  8. 使用例
    find . -name '*showup*' | xargs cp -p --target-directory=patchinfo
  9. 文法2 xargsの-iオプションを使用して{}を変数としてそこに引数を渡す場合
    find . -name 検索したいファイル名 | xargs -i cp -p {} /コピー先
  10. 使用例1
    find . -name '*showup*' | xargs -i cp -p {} patchinfo
  11. 使用例2{}以外の記号を使いたい場合
    find . -name '*showup*' | xargs -i% cp -p % patchinfo

  12. rmに渡す

  13. 文法
    find . -name 検索したいファイル名 | xargs -i rm {}
  14. 処理概要
    findの検索結果を行単位でrmの引数として渡すことで、指定したファイルを削除する
  15. 使用例
    find . -name '*header*' | xargs -i rm {}

 findの検索対象を指定する maxdepth と mindepth オプション

  1. maxdepth
  2. 使用例
    find . -maxdepth 1 -name '*.log'
  3. 処理概要
    指定したディレクトリ(この場合はカレント)の最上位1階層のみを対象にファイル名の末尾が.logのファイルを検索する
  4. mindepth
  5. 使用例
    find . -mindepth 1 -name '*.log'
  6. 処理概要 指定したディレクトリから最下位の1階層のみを対象にファイル名の末尾が.logのファイルを検索する

  なお、maxdepthは指定したディレクトリを起点に何階層まで検索するかを指定しており、
  mindepthは指定したディレクトリ配下の最下位のディレクトリを起点に何階層までを対象にするか指定している。

 出力結果から標準エラー出力を除く

  1. xargs grepを併用した場合に出るgrep: and: No such file or directoryなどの標準エラー出力を標準出力から除きたい場合。
  2. 使用例
    find . -name '*log' | xargs grep -ioa 2>/dev/null 'error'
  3. 処理概要
    これは単純に標準エラー出力スペシャルファイル/dev/nullにリダイレクトしている

  4. カレントディレクトリの配下にあるファイルのリストを再帰的に表示する場合

  5. 使用例
    find . -type f 2>/dev/null

協力会社としてメインフレームの開発を一から学ぶということ

発端

これは、とある特定派遣のインフラエンジニアのお話である。

現場は金融系で、メインフレームの基幹システムとその周辺システムとしてオープン系のサーバ群がある。 私はその現場で協力会社の一人としてオープン系のサーバ管理等に従事していた。

ある時、現場の事情から私に基幹システムであるメインフレームの開発へ参加を打診された。 そもそもメインフレーム自体はオペレータ時代に定例作業で触ったことがある程度だったので、乗り気ではなかった。 ただ、本格的なシステム構築の経験がなかった私にとって、その経験を得る好機でもあり、 それほど興味はないが、もしかしたらやってみれば結構面白いかもしれないと言う楽観から、最終的には受け入れた。

結果

それから一年ほど経った。 結論としては、このまま続けるべきではないと思い至った。

理由

  • 学習コストの高さ
     メインフレームの技術情報が巷に少なく、特に実践的情報は希少である。関連書籍も少ない。また、自宅で学習環境を整えることができず、現場の開発環境が主になる。一応Herculesというエミュレータがあるが、学習可能な範囲は限定的である。このような状況から、技術習得にかなりの時間と労力を割く必要がある。従って一人前になるには、現場である程度 「長期に渡った修行 をする必要」 がある。そう、技術の習得が職人的修行なのである。個人的には3年以上はかかりそうだと思った。派遣なのに。

  • プロプライエタリな製品に精通するリスク
     頑張ってメインフレームの技術を習得したとしても、仕事はその製品を製造するベンダーに関連する事業に依存することになる。これはリスクである。協力会社として派遣されている人員は、いつその現場から離れるかわからない。そのような状況で特定の現場でしか使えない技術に依存するのは仕事の間口を狭めることに他ならない。端的に言えば、「潰しがきかない」 のである。

メリットがあるパターン

  • ベンダーやプロパーであること
    おそらく、メインフレームを提供してるベンダーや、その製品を実際に購入、開発して顧客に提供できる大手SIerプロパーのように 長期的に関わることが可能になり易い立場であれば、その分野に特化したキャリア形成もし易くなると思われる。
  • オープン系、ネットワークを含めた開発経験を十分に持っていること
    オープン系、ネットワーク関係の基盤システムの構築経験とメインフレームの構築が合わされば、システム全体を理解した立場になり、 そのような人材は長期的に貴重な存在になるのではないだろうか。

念のため

なお、これは私の個人的感想であり、私の年齢が既に三十路を過ぎていることや、同じ会社の先輩がその現場におらず、一人で投入されたこと、 他、明かせない諸々の事情もあってのことである。従って決してメインフレームを批判するつもりはないので悪しからず。なお、職場の人間関係は問題なく、残業もそれほど多くないので労働環境自体はホワイトだったりする。