スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

openldapがうまく動かない (2)

slapdが正常に動作しない理由がわかった。

http://www.openldap.org/lists/openldap-software/200307/msg00381.html

原因はDBが壊れていたことにあったようだ。どうやら前にWindowsが異常終了したときに、slapdが起動しっぱなしだったのが原因らしい。db_recoverコマンドがcygwinであるのかどうかわからなかったので、また、試験で使っているだけなので、いったん、/var/openldap/openldap-data/下を削除してから、slapdを再起動すると、きちんと389でLISTENINGしていた。

DBが壊れているなら、ちゃんとログ出してくれよと思う。何の異常もなしにプロセスが立ち上がるなんて、そんなのわからんよ。

スポンサーサイト

iptablesでssh制御 続き

韓国と中国をブロックすれば大方OKだろうと思ったら、本国から訪問者がやってきた。
202.181.96.33
Webを見てみると、株式会社前田土木とある。
ウィルスに感染しているのか乗っ取られているのか? 特に通知する必要もないだろうと思ったが、掲示板があったので書いておいた。と思ったが、掲示板だとちょっと酷かもしれないので、メールで通知した。どういう反応になるだろうか。

で、結局韓国・中国等からの訪問者をブロックするだけでは駄目なので、不正アクセスを随時ブロックすることにした。
もじらさんのnewスクリプトを参考にして、ブロック開始。今度こそ大丈夫。

iptablesでssh制御

ずっとほったらかしにしていた、ssh規制についてようやく重い腰を上げた。
sshを外にオープンして以来、海外からの訪問者が相次ぎ、/var/log/secureには、

 Failed password for xxx from ...
 Illegal user xxx from ...

なんていうログだらけ。なんとかしないと偶然一致してクラックされたら大変だし(特定のユーザ以外ログインできないのでまず大丈夫だが)、なにしろログがそればかりになるのは困る。

今回、iptablesを初めて使ったので、この辺のサイトなどを参考にしながら行った。

まず、最初にイントラの特定のPCからのアクセスを規制してみた。が、規制が効かない。どうも、最初にINPUTに対してDROPのPolicyを設定して、その上で、sshの受入をし、さらに特定のマシンからのアクセスをDROPしようとしても駄目だった。やり方はあるのかもしれないが、すぐにはわからなかったので、INPUTのPolicyはACCEPTにし、規制するアドレスをDROPで上書きするようにした。
外からの入り口についてはルータのFW機能でブロックしているので、不要なポートはすべて閉じている。なのでイントラ内は特に規制せず、外から来てほしくない相手だけをブロックすることにした。こういう相手は、sshだけでなく、httpに対してもあれこれ送りつけて無駄にログがローテートするだけなので、すべて一括拒否とする。

そのための方法として、もじらさんからもらったスクリプトを使おうとした。これは、不正アクセスをしてきたアドレスをiptablesに追加し、しばらく経ったら解除するというもの。これはいいと思ってソースをざっと読んで、多少修正し、このまま使おうと思い実行してみると、環境の違いでうまく動かない。解析している時間がないのでこれはとりあえず後回し。

とりあえず海外からのアクセスをブロックすればいいと思い、国内で使われている帯域がわかればいいかと思ったが、先に次のサイトにヒットしたので、これを使うことにした。
韓国 IP アドレスからのパケットを遮断する
ここには、韓国以外にも中国・台湾・香港・インド・インドネシアもあったのでこれをすべて使うことにした。韓国・中国が大半なので、これをブロックすればとりあえずは十分だろう。

午前中に設定してから、今のところ不正アクセスはない。とりあえずこれでしのいで、時々日本やアメリカからの訪問者もあるので、その辺をスクリプトで対応していこうと思う。

第18回 J2EE勉強会

昨日、またJ2EE勉強会に参加した。

今回のお題は、
・私が欲しいPresentation Framework
・Yahoo! Design Pattern Libraryの紹介
・S2Continuationについて
・SeasarとSpringの性能比較
で、今回も盛りだくさんでいろいろ勉強になった。

Presentation Frameworkでは一つ一つ突っ込みどころがありそうで、この辺はいろいろ議論できたらよかったなと思った。

Yahoo! Design Pattern Libraryでは今回は、
・breadcrumps
・pagination
・Search pagination
についてで、こういうパターンが充実し広まってくると、UIの要求仕様で、このパターンを使ってというふうにできるようになるのだと思う。

Continuation(継続)については今回初めてどういうものか知って参考になった。今までのプログラミングの考え方とは違うので、発想の転換が求められる。メソッドの途中で一旦中断し、次のリクエストの際に継続するというもので、はじめはなぜそんなことをする必要があるのかと思ったが、どうも適用すると、すごくロジックをシンプルに書けるようになるらしい。
この辺の発想はWork Flowとも共通し、こちらは言語レベルではなく、上位レイヤーで行っている。S2Buriについて、概要を読んだことはあったが、実際どこまで使えるのか、ソースコードがどう変わるのかわからないのでその辺を知りたいと思う。

最後の性能比較では圧倒的にSeasarの勝ちという感じだった。これを聞いてSpring側は同反応するのだろうかと思った。

あと今日はじめてkoichikさんに会った。獄長エビ・ジョンウィルの異名を持つ人がどんな恐い人物なんだろうかと思ったが、非常に温和な感じで、印象が全然違っていた。ひたすら蛯ちゃんについて書いているのと獄長というのは面白い組み合わせだ。まあ、本当に恐い人なら本人の目の前で「獄長」なんて呼べないだろう。こういう「愛称」がつくのも、このコミュニティの面白さというか、若さかもしれない。

というわけで今回もいろいろ勉強になったかな。

外付けHDDの導入 & BunBackup

先日、IO DataのHDC-U250を購入した。かなり大きな箱で送られてきたのでサイズが大きいのかと思ったが、壊れ物のため二重に梱包していたようだ。

この外付けHDDは、バックアップ専用。こうしておくと、ノートPCのバックアップも簡単にできる。今までは内臓のドライブをバックアップ用にしていたが、こうするとノートPCからバックアップするのにネットワーク経由となり、共有の設定とか面倒になる。外付けだとその辺は問題ない。

Sofmap.comで5年ワランティ付で15800円。あとで、価格.comなどで調べたら他店の方が安かった。ただこのレベルで5年ワランティは他であるのかどうかはわからない。

同タイプのLogitecのLHD-EC250U2とどちらにするか迷ったが、結局人気度で決めてしまった。
I-O Dataの方も横置きできるものと勘違いしていたが、熱のためできないようだ。注文したあとから、口コミ掲示板とかを見て、判断が正しかったのかどうか悩んだ。

添付されていたソフトは大したことがない。
iSPISというセキュリティ対策のソフトが入っていたのだが、これは、ファイルを二つのメディアに分割して保存し、両方がないとファイルが開けないという類のもの。USBメモリを使っている場合を除いてあまり使い道はない感じがする。大きなHDをそうそう持ち歩いたりはしない。

また、EasySaverというバックアップソフトもついていたが、これは非常に簡単なバックアップソフトで、大したことはない。

バックアップには、BunBackupというのを使っている。
これはいろいろ設定ができて、かなり満足している。自作して自分専用のバックアップソフトを作ろうと思っていたが、このソフトでかなりの部分をカバーできているので自分で作る必要がなくなった。
バックアップ方法として、全体、差分、ミラーリング、対象拡張子と設定でき、また差分をコピーした際、古いファイルを世代管理フォルダで保管できる。そのほか圧縮や暗号化もできる。また定期的にジョブを走らせたりリハーサルもできる。

私は、内容によってミラーリングや世代管理を使っている。
世代管理は編集を重ねて間違って重要な部分を削除してしまったとき、古いファイルを見たい場合に重宝する。

使い方は簡単だが注意する必要があるのはミラーリング。間違ってバックアップ先をルートディレクトリにでもしようものならルート以下がバックアップ元と同一となってしまうため、そのドライブに重要なフォルダがあっても削除されてしまう。
実際私はこれをやってしまった。あわてて止めようと思ったが、途中で止められず、強制終了するしかなかった。
ただこのとき、ミラーリングによって削除対象になっていたファイルはすべて世代管理フォルダに移されたので助かった。どうやらそこはバックアップがある。

現在も進化中だが、以下ができるようになるともっといい。

・バックアップを途中で中断できること
・自動バックアップをそれぞれの単位ごとに設定できる
・レジストリーのキーもバックアップ対象にできる
・バックアップ先指定時にディレクトリを作成できる。


openldapがうまく動かない

cygwin環境でちょっとldapについて調べていた。

slapdを起動し、-dでデバッグ出力をさせたものの異常はなし。ちゃんと起動している。にもかかわらず、389ポートでLISTENしていない。なぜだ?
数日前に行ったときには正常に行っていたのに。
ネットで調べると、

port 389 not present while slapd is running

と同じ症状を持つ人がいた。しかし解決には至っていない。
どうしたらいいものか。

Cacheとデータ中心指向・オブジェクト指向

先日のDB研究会でCacheについて議論していたとき、Cacheのクラスがデータを表す、つまりクラスの作成=テーブルの作成で、そのクラスにメソッドを書くということは、データ中心指向の発想である、データをプロセスから分離するというのと逆行することになるのでは、という意見が出た。

これはそのときにも述べたが、違う。その方向性はオブジェクト指向に向かっているのであってプロセス指向に向かっているわけではない。

データ中心指向は、プロセス中心指向がバラバラににデータを扱うのに対して、データはプロセスから切り離して独立して扱いましょうということで、データベース・マネージメント・システムの中に組み入れて整理して一元管理し、プロセスはデータベースにアクセスするようにした。特に業務アプリケーションでは、データが重要なのでこの考え方はマッチした。

一方、オブジェクト指向もこれと同じように、プロセス指向で従属していたデータに対して大きな地位を与えた。データをオブジェクトとして昇格させ、そのデータを扱うプロセスをオブジェクト内にメソッドとして定義した。こうしてデータと関連する処理をセットにすることでソースコードをきれいに分類することができ、プロセスではなく、オブジェクトの相互作用でプログラムを説明できるようになった。

なので逆行しているわけではない。ただしきちんと設計しないで、乱雑にクラスを、特にパーシステントのクラスを作っていったら大変なことになるだろうが。

UMLについて

読もうと思って溜め込んでいたPDF版の本がたくさんある。以前、あちこちからダウンロードしてきたもので、紙で買うと、結構な額になるものばかりだ。

とはいえ、かなりのボリュームなので、そう簡単には読めない。英語の速読ができるようにならなければ。今のままでは、日本語に比べて格段に遅い。

ハードディスクを整理していると、UMLの本がたくさんあった。積読にしていてもしょうがないので、斜め読みというか、一行読みでぱらぱらと読んでいった。

こういう本はUMLの意味をきちんと書いている。営業の宣伝のためか、妙な誤解が世の中に広がっている。その反動でか、UMLなんて何の役に立つのかというSEも結構いる。これまた誤解を基にしていたりする。

面接に行ったときも、いくつものところでUML書いたことがあるかと聞かれる。UMLが魔法の杖で、問題をきれいに解決し、仕様をきれいにまとめてドキュメント化してくれるすばらしい方法だと錯覚して、そういう技術者がほしいと思っているようだ。

UMLは単なるモデリングの表記法であって、それ以上でもそれ以下でもない。人は概念を整理するときに図を使う。図は構造をわかりやすくするし、概念の骨子を表すことができる。UMLで用意されている図は、そういう図の一部に過ぎない。システム開発でよく使われる図を選んで表記法を統一しただけだ。だからことさらUMLというすごい表記法があるわけではない。UMLでなくても、モデルをきれいに書けるならそれで十分だと私は思う。

クラス図はよく使われるが、しばしば業務アプリでは不要だと思う。フレームワークの部分については、その構造を理解するためにあった方がいいと思う。しかし、不思議なのはstrutsにしろ、tomcatにしろ、そのドキュメントにUMLがほとんど使われていないことだ。これだけUMLが騒がれているのにもかかわらずなぜだろうかと思う。
フレームワークに沿って個々の業務を実現していくところは、例として一つ図に描くだけで、それ以外は同じ形式なので要らない。Actionクラス、サービスクラス、DAOクラスがあり、検索・参照・編集・削除等の機能に沿って同じようなパターンでクラスが作られるだけ。なので一例だけで十分だ。

クラス図は多くのIDEで自動生成するので、ドキュメントのページ数を稼ぐのにはよく使ったが。

シーケンス図については、よく例でクラス単位で書いているが、デザインパターン事態の説明やフレームワークの根幹の部分以外には要らない。そもそもクラス単位で書くと粒が小さすぎてまともにやろうとしたら膨大な量になってしまう。IDEで自動生成できればいいが、私はシーケンス図を自動生成してくれるものを聞いたことがない。
シーケンス図はもっと大きなノード単位で描くことはよくあるので、そのぐらいの粒度で書くのはいいと思う。

ユースケースは、唯一図が中心ではないものだが、これはUML批判派がよく誤解しているところでもある。前に「あんな人の絵書いて何になるんだ」などと言っていた奴がいるが、あの人の絵がユースケースではない。あれはユースケースを抽象化した図であって、ユースケース自体は文書で書く。あの図も、細かく書かなければ、システムの概要を簡単に示すのには役に立つ。そのシステムのユーザと、システムの担当領域を示すことができる。といっても、大したことはないが。

文書で書くユースケースの方だが、これまたどれだけのプロジェクトで使われているのかよくわからない。仕様書としては外部仕様に属するが、仕様のかなりの部分を表現できるが、すべては表現できない。ユーザがシステムを使用するケースをシナリオにして、その事前条件、手順、事後条件等を記述していくのでかなり正確に記述できそうだが、仕様書としてはあまり取り上げたくない。
シナリオ形式にすると、別の目的がある場合には別のシナリオを用意することになり、そうなると内容が重複したりする場合が出てくる。
これはそのままテスト手順書にもできそうだが、例外条件をいろいろと書くと、一つのユースケースの中にたくさんのテストケースが混在することになり、あまりよろしくない。多くの条件が細々と書かれるようになると、わかりづらくなる。かといって代表的なシナリオだけを書いたのでは仕様としては落ち度がある。

実際の外部仕様書で多いのは、やはり画面単位の記述だ。画面に表示する項目、操作をしたときにどうなるかを事細かに記述する。もちろんそのときにはユースケースで記述するような事前条件や例外などについては、きちんと記述する必要があるが。私はユースケースよりもこの方がわかりやすいと思う。

UMLはGUIやWebを前提にしているわけではないので、画面定義や画面遷移図というものは出てこない。よくオブジェクト指向の本で、UIやテーブル定義は変更されやすいので、UMLではまずドメインの部分を決めて、UIやDB実装の部分は後回しにするなどと書かれている。それが当てはまるアプリケーションもあるが、UIから仕様を定義していくのは少なくはない。

UIがメインになるWebアプリケーションの場合、画面定義と画面遷移があれば仕様のかなりの部分を定義できる。図を多用するUMLでここだけ図を排除して文書に徹しているのはなかなか面白い。

開発の生産性とは

よくこの言語を使うと、あるいはこのフレームワークを使うと、従来よりも生産性が10倍上がるなどという。しかし、何を元にそう言っているのか。10倍というアバウトな数字は単なる宣伝文句に過ぎないとしても、そううたうからには実際に少なくとも数倍の速度で開発が進まないといけない。

RailsがJavaよりも速く作れるといったとき、細かく条件を見ていく必要があるだろう。JavaでもIDEを使う場合と使わない場合ではかなり違いがある。それから一体何を作るのかでも変わってくる。

第一に、開発対象・規模がどういうものか。業務系か制御系か、大規模か小規模か。そういった条件をつける必要があるだろう。

それから、開発のプロセスに入ったとき、かかる時間として考慮すべきものは以下のものがある。

・初期学習
 たいていの場合いきなり何も知らずに開発に入るのではなく、ある程度学んでから入る。ここでどれだけの時間がかかるか。簡単に習得できるかどうか。これは入門書やマニュアルがどれだけわかりやすく、適切かによっても違ってくる。

・調査
 先ほどのは最初の段階の学習。実際どんなに上級のプログラマでも何もかも知ってから開発に取り掛かるわけではない。基本をマスターしたら後は実践の中で深めていく。ある課題をどのように解決するか、エラーが発生したときにどう対処するか。このとき調査にどれだけ時間がかかるかである。これは、マニュアルがしっかりしているか、GoogleでのHit率がどのくらいか、トラブルシューティングの情報があるか、FAQや掲示板で調べられるかなどで違ってくる。

・環境構築
 一番最初に躓くのは環境構築だ。通常一人だと一回で済むからそれほど大きな要因ではないが、規模が大きい、あるいはTest環境構築など頻繁に行う場合、これが複雑だと生産性を下げる。

・開発環境
 IDE、Plugin、Toolがどれだけ充実しているかで生産性は変わってくる。

・記述
 1.短く記述できること
  それを実現するために必要な情報だけ記述すればよいこと。DRY(Dont Repeat Yourself)の原則が保たれていれば、より記述量は少なくなる。
  第一に、言語レベルで短く記述できるかどうか。Javaの1.4まではループの記述は面倒だった。それに比べてrubyだと簡潔に書ける。またメソッドの長さもrubyだとpとかto_sとかで済む。ただしこれはIDEを使っていたり、タイピングの問題なのでさほど大きな差が出るとは思えない。また言語に継承が使えれば記述を短くできる。
  またライブラリやフレームワークで予め機能が用意されているかどうか。予めその機能が使えるAPIがあれば自分で組む必要がないので記述は短く済む。少なくともありがちなもの、使いそうなものはすべて最初からあるのがよい。
 またそのライブラリやフレームワークを使うとき、記述の少なく、重複が少ないほどよい。これは例えばEJBなどを使った場合、そのまま教科書どおりにやると同じような記述を散々書かないといけない。XDocletを使うと便利だというが、もともと無駄で余計でロジックのかけらもない記述をさせて生産性を下げていたのを0に戻しただけで生産性がプラスになったわけではない。

 2.わかりやすい
  わかりやすいソースがかけるほど、デバッグ・メンテナンスは楽となり、これは生産性に直結する。これは属人的な要素となり、メンバーがわかりやすく書くようにすればいいことだが、JavaではCに比べて複雑な書き方ができないし、また一般的にオブジェクト指向言語の方がわかりやすく記述できる。またフレームワークで形の強制ができればソースはわかりやすくなる。

 3.応用度
  硬いフレームワークだと例外的な処理を書こうとするとかなり厄介で時間をとられる。そういったことがないように柔軟にかつ簡明に対応できるかどうかも生産性にかかわってくる。

少なくとも、こういう要素を考慮して、それぞれを一つ一つ比較・対照して、その結果このフレームワークの方がどれだけ生産性が高いなどと言うべきだ。
こういった要素の検討が生産性を測るメトリックスとなると思う。そういうふうにして各言語・フレームワークを比較できたら面白いと思う。

最も生産性というのに近いのは、記述の短さだと思う。
要求定義に記載する情報だけをソースに書けばよい、というのが最も短い記述になる(要求定義が整理されている場合)。それが究極のフレームワークが目指すところだろう。
DBの定義があれば、あとは勝手に一覧・登録・更新・削除画面が生成される。RoRではあと、Validationも自動化してくれればいいのだが。RoRのscaffoldは最初に習う分にはよいが、実際あのままでは使えないので、もっと細かくテンプレートが用意されているといいと思う。

そのためには、画面設計をパターン化する。これは画面のデザインパターンではなく、画面遷移のパターンだ。画面遷移では、一覧⇒変更⇒一覧となったり、一覧⇒変更⇒確認⇒完了⇒一覧となったり、いろいろパターンがある。こういったシーケンス等を研究する分野があってもいいと思う。

プロフィール

dayan

Author:dayan
小職は、SE(システムエンジニア)を専門としておりますが、技術的な情報を中心に、それ以外に経済関連の日記、たわいもない日記も載せていきます。
[公式HPもよろしく!]

天気予報

-天気予報コム- -FC2-
リンク
ブロとも申請フォーム

この人とブロともになる

カテゴリー
最近の記事
ブログ内検索
最近のコメント
最近のトラックバック
RSSフィード
月別アーカイブ


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。