The Way to Nowhere

あるITエンジニアの雑文。

IT

ERP導入SIの課金のあり方についての雑感(答えは特にない)

なんとなくTwitterで軽く書き捨てとこうと思って書き始めたら、全然収まらなくなってしまい、下書きして連投みたいなのもガラではないので、こっちのブログの方に書いておく事にしました。

ERPもクラウドとかSaaS型のものが増えてきて、標準外で行う、いわゆる「アドオン」も、実装には制約が多くなっているんで、あらためて「できるだけ標準に業務を合わせよう」っていう事が色々なプロジェクトで言われている気がする。いやまあ、昔からスローガン的には、ほぼ同じ事を言っていると思うが、SaaSだどOSやミドルウェアのレベルに追加の仕込みができないので、オンプレミスの時ほど自由度高く気軽にアドオンの実装はできないっていうのが実態だったりして、SaaSのコアはしっかり使いつつアドオンする事のハードルが上がっているという側面もあるかなと思う。

そういう事の代わりになのか、SaaSの中にそれなりのカスタマイズ対応できるツールや仕組みを備えるようになってきていて、実質は専用の開発ツールがバンドルされている、と言えることになる。そうすると、「この要件は、標準でバンドルされたそのツールで作れば対応できる。」→「この要件は標準で対応できる。」みたいな売り方・提案のされ方が観測されたりする。

でまぁ、これも昔から同じような話はあったはずだと思うが、改めて思うのは、ERPの導入で「なるべく標準に合わせるようにした方が全体としてコストが抑えられる」って話のはずが、個々の細々とした要件毎に「標準の範囲で対応できると言えれば追加コスト不要」みたいな理解や取決めに魔変換されがちなんだよね。これは、なんとかならんものかね?

そりゃあ、SaaSベンダーに払うサブスク料金とかライセンス料金は追加されないだろうけれども、SI的には普通に要件増えたら、単純なものであっても、その設定してテストしてって工数はかかるわけで、アドオンを作る程ではないとしても、現場的にはコストはかかるんだよ。そして、それらは一つ一つは小さくても積み重なればそれなりモノになる可能性もある。まして、さっきの「バンドルされた開発ツール」での対応はもちろんの事、色々なケースに対応できるように抽象化された機能の場合、その設定パラメータ群をデフォルト設定とは変えて実際の業務要件に合うようにするには、相当な知見や工夫と検証が必要になる事もままあるんだよね。それでもアドオンで何か作るよりはマシだからやるんだけど、結果としてこれは「標準で対応できた事になるから無料」みたいな感じになってしまうのは、色々詰め込まれている中では、なかなかやるせない気持ちになる事がある。まあ気持ちの問題であれば、そういう知見の積み重ねも単価に込めていると考えておけばいいと思うが、現実に「コスト増加」って話を客側に持ってかざるを得ない時は「標準対応と言ってたのになんで追加コスト?」みたいな感じで理解されない。

まぁ、ファンクションコンサルをミニマムでアサインした場合の固定料金は設定せざるを得ないとして、その上でさらに標準機能の範囲であっても、設定やテスト作業として許容範囲を測る指標を持って、それを超えたらまたなんらかの基準で追加課金(見積)の対象にするとかなのかなぁ?でも、それで精緻な基準を作るのも大変だし、結局は客側に理解してもらえなくて、シンプルに「アドオン/カスタマイズ扱いは追加コスト要」、「1本あたり○○万円」みたいなのがお互いにやりやすいのかねぇ?
そうだとすると、「何をアドオン/カスタマイズ扱いにするのか?」の定義の問題になってくるんで、提案の段階から一貫した基準で扱って、デリバリーのプロジェクトの段階で困らないようにして欲しいものです。提案の段階から関わって、意見が言えるようになれればいいんですけどね。

道は険しい。

改元に伴うシステム対応の話

元号が平成から令和に変わって既に1ヶ月が過ぎて、全然タイムリーな話ではなくなってしまったのだが、思ったところを書いておこうかなと思います。やっぱりちょっとしたシステムトラブルは、世間的にもそれなりにあったみたいですね。

平成の時代に新規に構築されたシステムの場合、それに関わるほとんどの人は昭和から平成の元号の変更を記憶としてあるはずなので、元号は変更されうるもの、という事がわかって設計しているだろうし、おそらく日付データの年はシステム内部的にはできるだけ西暦で保持して、どうしても和暦で扱わないといけないところだけ、インタフェースなどで対処する、という形になっているのではないかと思う。

私がこれまで関与したシステム構築案件でも、ある程度仕様を踏襲すべき旧システムにはいろんなところに和暦があったものだが、基本的にシステム内部は西暦で統一する活動をするのが普通だったと思う。

私の経験の中で、どうしても和暦を扱わざるをえなかったのが、銀行の入出金取引明細を全銀協フォーマットで取り込むところだった。インタフェースで外から来るものが和暦だというのだから、対応はせざるを得ないものだった。しかし、このフォーマット、日付項目が年部分2桁の6桁で、年部分2桁は和暦による年だと定義されているのだが、元号を示す値はないという、ある意味致命的なレイアウト。システム内部では西暦で保持する為に和暦⇒西暦の変換が必要なのだが、どの元号かが示されなければ、正しい変換はできるわけないよね。

現実的なところでは、このデータフォーマットで大幅に過去や未来の日付を扱う事はないという前提のもとに、年2桁部分から元号を判定するのが妥当なところなのだと思う。例えば、「30年以上なら『平成』、30年未満なら『令和』」みたいなロジックになるようにして、ここで判定に使う年数とか結果の元号を設定でコントロールできるようにしておく、ような感じで。こうしておけば、令和29年までか、もしくは次の改元が見えてくる時まではそのまま対応可能で、その頃には平成30年のデータなどこのフォーマットでは扱う事はなくなっているので、基準年や元号などの設定を変えればよい、という事になると思う。これも今になって思えば、という話で、私が実際の案件で対応した時もそんなふうにはできていなかったなぁ、と思う。

しかし改元のタイミングに実際に立ち会わないと中々現実的に妥当な対応は考えられないものですね。改元がいつ来るのか見えていない状況で平成の時代に構築されたシステムでは、一応「元号は変わりうるもの」として考慮はしていて、全く何も考慮せずにハードコーディングしているなんてことはそうそうないとは思うが、実際に改元の時期にどんな感じのデータが発生しうるのかの考慮が足りていない事が結構ありそうな気がする。だから例えば「その元号の設定は4月30日のしかるべきタイミングに変える必要がある」みたいな話になったりする。
上記で例に挙げた入出金取引明細で言えば、銀行によって切替のタイミングが微妙に違うとか同一ファイル内に「31年4月」と「01年5月」が混在しうるとかがあるので、単一的に「現在の元号」を設定可能にしておくだけでは対処できなかったようですね。まあ、よく考えればわかることなのだろうけども、そこまで考えて対応できているケースは現実的にはあまり多くなさそうで、具体的にシステム改修まではせずに、改元前後の「運用でカバー」というケースが実際多いのだろうなぁと思います。また、前の「昭和から平成」の時には、先に元号が変わってしまって、システム対応は事後的に行ったのだろうから、必要な対応は今回とはまた違ったんだろうな、とは思う。

というわけで、なかなか滅多にない事なので、システム対応を万全にしておく、というのも難しいのでしょうね。それこそ「運用でカバー」するしかない、というか、すればよい、と済ませてしまう事になりがちなんでしょうね。

会社のウェブサイトをWix.comで作り直した

この度、ブログを独自ドメイン対応することで簡易的に作っていた自分の会社のホームページをWix.comで作り直しました。で、そうすることで、いわゆる「SSL対応」も簡単にできた。もともと大した内容もなく、載せる内容も大きく見直すつもりもなかったので、1日でほぼできてしまいました。(その会社のサイトはあえてリンク張りませんが)

Wix.com

私はフリーランスのエンジニアと称していますが、契約等の実務上は法人化しておりまして、そんな私のようなマイクロ法人であっても、今や会社のホームページは、昔は紙で作っていたような「会社案内」替わりで参照される事が時々ありますし、実務上で一番大事なポイントは決算公告をWEB上で行うように登記しているので、その為にもウェブサイトが必要なわけです。

で、「https化」が当たり前になる流れはかなり以前から気にはなっていたものの、最近のChromeのバージョンアップにより、https対応していない場合は「保護されていない通信」と表示されるとかもあって、「お名前.com」の「SSL化対応しましょう」のプロモーションメールがやたら目に付くようになったこともあり、そろそろ何か対応しておこうかな、と思ったわけです。ちなみにlivedoorブログでそのままにSSL対応するのはまだのようで。

とりあえず、たまたま知ることになった squarespace を見てみたのですが、確かによさそうではあるものの、この手のサイトは他にも色々とあるはずだと思って、ググってみると比較記事みたいなものもいろいろ出てきて、いくつか読んでみたところでは、Wixの評価が高かった。

10 Best Website Builders Reviewed. (I bought and signed up.)
10 Best Website Builders for Small Business (Inside Look & Reviews)

ということもあったし、後はやはり独自ドメインのサイトを作るには無料とはいかないので、そのコストを比べてみようとしたところ、これもたまたま気付いたのですが、MicrosoftのOffice365のユーザーだと、Wixは通常料金のほぼ半額になるという事で決めました。Office365の管理ページ内のリンクからWix.comに遷移してアカウントを作ると、そういう割引になるようです。

余談ですが、Wixのアカウントを作ってみると、Office365から入ったのに、しきりに独自ドメインのメールアドレスをG Suiteで取得しようと言われるのは少々微妙な感じがしています。

キレイな写真とかも多用してセンスのいい「イケてる」感じのサイトを作るのであれば、確かに squarespace の方がよさそうな感じはしましたね。機能面でできる事にそんなに差はない印象でした、もちろん私が求めていた範囲での話ですが。

で、この手のウェブサイト構築&ホスティングサービスは、もちろん以前からあったのでしょうが、寡聞にして全然知りませんでした。ただの「ホームページ」というだけではなく、ネットショップを作るための「ショッピングカート」とか、「Paypal決済」や「カード決済」とか、「オンライン予約」とかのパーツもあるし、顧客のアカウント管理したりメール配信みたいな機能も持てたりするようで、もはやITの実装面での知識なんてなくても簡単に作れてしまうんですね。私のマイクロ法人のウェブサイトごときを作るためにはもちろん使っていませんので、それらが実際に使ってみてどんなものかはまだわからないものの、Webプログラミングとかサイト構築とかについてちょっと知っている程度では、大して付加価値などないんだとあらためて思えてきました。

フロントはこういうものを活用してサクッと作りつつ、もっとコンテンツとしての本質的なところに注力できるようになっているってことなのだろう。

DBのキャラクタセット違いでSJISからUTF8への移行 - Oracle -

最近はOracleのデータベースもUTF8で構築することが当たり前な感じになっていますが、何年も使っているレガシーのシステムだとやっぱりSJISとかだったりすると思います。

そんなSJISとかのデータベースから新しく構築するUTF8のデータベースにデータを持ってくる時には、文字コードの変換とかはだいたいミドルなところがやってくれるので、気にしなければいけないのはマルチバイト文字に必要なバイト数が増える事を考慮してデータを格納する領域を確保するってことくらいかな、と普通は思うわけです。

データの中身に関する事はその程度の事でさほど問題はないのだろうけど、古いシステムの中にはテーブルとかのDBオブジェクトの名前にもマルチバイト文字が使われていたりする。
テーブルとかDBオブジェクトを作る際には、その名前に漢字とかひらがなとかのいわゆるマルチバイト文字は使わずに、半角英数字と若干の記号のみを使うべきとは昔から言われているよね、というのが私の印象ではあるのですが、実際のところ物理名にもマルチバイト文字を使っているレガシーシステムはまあまああります。
そのようなシステムからDBリンクで接続してデータを持ってこようとした時に問題が起きる可能性がある。

OracleはSQLの構文としてDBオブジェクト名は30バイト以内という制限がある。
SJISだと漢字やカナなど2バイトで済むのでテーブル名などにマルチバイト文字を使った場合15文字まで使えるということになる。
しかし、UTF8では漢字とかカナは3バイトが必要になるので、SJISの旧システムと同じ名前ではDBオブジェクトが作れない、ということになってしまう。
新しく構築するんだから物理名にマルチバイト文字なんか使わなければよいのですが、データを移行する為に新しいUTF8のDBからDBリンク経由でSJISのDBに接続してデータを持ってこようとした時に、UTF8のDB上でアットマークをつけてDBリンク先のSJISのDBのテーブルにアクセスしようとすると、UTF8としての30バイトの制限に引っ掛かってSQLが構文エラーになってしまいます。
「DBリンク先の文字コードがSJISだからUTF8としては長い名前だけどもOK」みたいな気は使ってはくれないわけです。

対応策としてはテーブル名やカラム名、その他DBオブジェクト名のバイト数がUTF8にしても30バイト以下になるように、SJIS側のDBにビューとかを作るって事になると思います。
内容や元々の名前がわかるように短縮した名前をつけるとかって、対象のボリュームにもよりますが、結構地味にダルい話だと思います。
まあ、パフォーマンスとか考えて許容されるのであれば、DBリンクを使わないでファイル渡しする、とかでもよいのかもしれませんけどね。

個人的には最近こんなのばっかりで慣れてしまった。
物理名に漢字とかひらがなで日本語を使われていると、ブラックボックスなシステムの中を調査する上ではとっつきやすいのですけどね。

やっぱりそういうDBの物理名にも漢字とか使っているシステムって、COBOLの影響なんのかな?さらにもっと昔にはCOBOLとかでシステム構築していた人たちが90年代のオープン化の流れで技術領域をシフトさせつつ作ったのかな?とかとか思ってしまいます。すごい偏見だけど。


「SIガラパゴス」のERP導入における問題点

朝の電車の中で何気なくTwitterでつぶやいたら、記事の筆者ご本人に反応して頂きました。

記者の眼 - 「SIガラパゴス」を育んだIT部門の罪:ITpro

この話はもう何周目かな?と思うくらい、何度もグルグル回っている感もありますが、同じような主旨の話でも繰り返し訴えていくということも必要だと思うし、そういうお立場でもあると思うので、それはそれでいいと思っている。

私はフリーになってこの辺のテーマからは「斜め」方向に行ってしまったわけですが(斜めの上か下かはわからないw)、この記事を読みながらも、記事の論旨とは違う観点で思った事があるので、その辺りをメモ程度に書いておこうかと思います。

記事中で「ERPレガシー」という事に触れらている。
私もその「ERPレガシー」の作り込みに関与してきたと言える。
アドオンたくさん作ってきたな~と。まあ、それが仕事だったし。 

その点に関しては、記事のテーマにある通り、 ユーザ企業側の問題が一番大きいとは思うけど、長年ERP絡みのプロジェクトの現場にいて、それとは別の問題が2つあるなと考えてきた。

1つ目はERPのいわゆる「導入コンサルタント」の問題で、ちゃんとしたスキルとマインドを持った人が圧倒的に不足していると思う。
ERPパッケージの標準機能、業務プロセスを「そのまま使う」といっても、実際にはどこのセットアップ項目をどのようにセットアップして使っていくかということにはいろんな工夫の余地があると思っている。
だけど、できるだけちゃんと標準機能を使うようにしよう、という工夫をしようとするって事がない、そういうふうに考えられる人って少ないよな、と。
まあ、「標準機能じゃできませんね」ってことでアドオン化した方が商売になるっていうSIer側の事情も絡むのだとは思うけど。
そしてどうしてもなんらかのアドオン/カスタマイズは必要だとなったとしても、ただ普通に機能要件を実装するだけじゃない工夫の仕方がパッケージの場合はあると思うんだよね。

もう1つの問題は「スキルのある人材不足」とは裏返しとも言える話で、ERPパッケージをうまく使いこなす為に「コンサルタント」と称する高度なスキルのある人が必要って事は、そもそもERPパッケージ製品自体がまだまだイケていないんだと思っている。
色々と進化はしてきていると思うんだけど、難易度としてはむしろ上がっていると思うんだよね。

「各種セットアップをして標準機能だけで出来ます」とか言っても、実際のプロジェクトの現場でちゃんと動くようにするにはえらい大変だったりする。
ほとんどプログラミングしているみたいなものだと思う事があるけど、普通のプログラムみたいにエディタ上にシーケンシャルにロジックが見えるわけではなく、普通にプログラムを書くよりもむしろ難易度は高いと思える事もある。
それをプログラムを書かない(書けない)「コンサルタント」が対応しようとするものだから、そりゃあ炎上しますわ。。。

そんなわけで、もっと「簡単に」使えるようになる業務アプリケーションパッケージが必要なんだと思うわけです。

繰り返しますが、元記事の論旨とは違う観点の話をあえてしています。
ERPでサポートする業務プロセスがベストかどうかは本質的な問題ではなく、一つの標準プロセスに整流化することで、重複業務のカットなどの効率化を図り、一般管理費を下げることを目指す。
これ自体には基本同意していますので。
今現在あるERPがベストでないにしても、導入すると決めたからには今あるものを受け入れて、その中で工夫すべきだと思います。

時間がないので、この辺の話はまたあらためて考えてまとめてみたいと思います。

ソフトウェア開発と業務システム開発は違うという事

しばらくモヤッとしていた事が少し言語化された感じがする。

もしSIerのエンジニアがジョブズのスピーチを聞いたら(1) - Wadit Blog.
もしSIerのエンジニアがジョブズのスピーチを聞いたら(2) - Wadit Blog.
多くの人が混同するのだが、ITという括りであたかも同じように語られるのが、業務システムの開発とソフトウエアの開発である。営業システムとか生産システムといったものが業務システムで、MSのオフィス製品だとか、DBMSだとか、パッケージのようなものがソフトウエアとすると、それぞれを開発するやり方は違うと思いませんか。
もしSIerのエンジニアがジョブズのスピーチを聞いたら(3) - Wadit Blog.
なぜ、"コードはソフトウエアを作る時に書いて、業務システムはそのソフトウエアを使って組み上げる"ことができないのでしょうか。プログラマーは、役に立つ魅力あるソフトウエア(ツール)を産み出すことに自分のスキル、意欲を傾注したらいい。そして業務システムを作る人は、業務プロセス、仕事スタイルをデザインできる人がすればいい。後者こそ本来のSIerのめざすところではないでしょうか。
もしSIerのエンジニアがジョブズのスピーチを聞いたら(4) - Wadit Blog.

よくSIの受託開発仕事をDISる文脈で「コードを書く事へのこだわり」みたいなものを語られる事に対して、 なんとなく共感する部分も感じつつ、同時に違和感も感じる事が多いのだけれども、それはそういった文章がここで言われている「混同」に無自覚だからなのかな、と思った。
具体例挙げられるほどに覚えてはいないのだけれども。

ソフトウェアによる様々なサービスやプロダクトが登場してくる現在及び今後の状況において、SIの現場ではできるだけ「コードを書かない」でソリューションを確立・提供すべきなんだと最近強く思う。
エンジニアとしてはコードを書くスキルを磨いて実装力を持ち続ける事は必要だとは思うけど、SIとして顧客に提供する価値って「コードを書く」事じゃないよ、と思うわけです。

スクラッチ開発で人月積み上げた方が儲かるっていうのはその通りなんだけど、そんなコストをかけ続けられる顧客自体がどんどん少なくなって先細るのは明白なので、こういう視点も一つの例として、SIでどんな価値を提供すべきなのかを考え転換していく必要があると改めて思った次第です。

そういう取組をしたとしても人月の呪縛から逃れるのは難しいとも思っている。
まあ、個人的には人月見積を全面否定する気はないのですが、持続可能なビジネスとして成立させる為には同時に考えていくべきテーマではあるよね。

Oracle E-Business Suite の技術情報

正確にいつからかは知りませんで、この2~3ヶ月の間にという所だと思いますが、Oracle E-Business Suiteのマニュアル等のドキュメントが日本語版も含めて、OTNでサインインなしで参照できるようになっていますね。

Oracle Applications Releases 11i and 12


全部が日本語化されたわけでは全然ないので、数は少ないですが。

英語版はかなり前からUSのサイトで誰でもアクセスできる状態になっていたのは知ってましたが、ついに日本語マニュアルも公開するようになったか~とちょっと感慨深かった。以前は日本語翻訳版はOiSCにログインしないと参照できなかったので、OiSCのサイトが閉鎖されたのと関係があるのかもしれませんね。

でまあ、本題としては日本語マニュアル自体はどうでもよくて、英語マニュアルまで含めたら、Oracle EBSの技術情報もそれなりに公開されてはいるんだよな~とは思いつつ、この辺の技術情報は日本語blogでは書いてる人ってほとんどいないよね、と思うわけですね。

OracleでもDBA関係はそれなりに層も厚くて、非公式なサイトでのTIPSもそれなりにあるんだけど、EBS絡みだとググってもたいていの日本語記事はオラクルのマーケティング系の記事で、それらが過ぎると英語記事になっていく感じだったりするわけなんで。

なので、公開されているマニュアルに載ってるレベルの技術情報を自分の経験を踏まえて纏めたらそれなりに見る人いるんじゃないかな、とか思ったりするわけです。
もちろん案件特定できないように一般化する必要があったりで、それなりに面倒ではあるとは思うが、まあそれは他の技術系のネタでも同じことだよね。

勝手な推測ですが、そういう事が書けるレベルの人というのは、実プロジェクト等が忙しくてblogに纏めている暇なんてないか、blogでまでそんな事に関わりたくないかのどちらかなんだろうね。だからそういう技術情報の記事は増えないのではないかと。

また、実際にPJ現場のトラブル解決するには、ネットをググっているよりはサポートサイトMy Oracle Supportのナレッジ検索するのが一番でしょう。バグとかパッチの情報はそこでしか得られないと思いますので。

そうは言っても、実際Oracleはかなりいろんなマニュアル類は公開するようになってきているので、
それらの情報だけでも結構イケますよって所を示せると面白いと思うんですけどね。

まあよく考えると実際の所は「マニュアルに書いてあるレベル」に抑えるのが結構難しいのかもとか想像したりもしますね。下手にSQLとか書くと内部構造の解釈を晒す事になるのでそれはそれで「マニュアルに書いてあるレベル」を超えててまずいかな、とか思ったり。

ともかく、本格的なまとめは当然無理なんで、気になる事があって気が向いた時には、という感じでしょうかね。

User-Defined Exception - PL/SQL

PL/SQLで書かれたプログラムがエラーでコケた場合などで、 時々ログとかにこんな風に出力されているのを見ることがあります。
User-Defined Exception
こういうのを見るととても残念な気持ちになりますね。
いや、たぶんコーディングした人は「例外処理はとりあえずOTHERSでSQLERRM出力しとけばいっか」とか いう感じで、
EXCEPTION
  WHEN OTHERS THEN
    dbms_output.put_line(SQLERRM);
END;
とか書いて満足しているんでしょうか。

 でもこれって要はこういう感じで、自分で例外定義して、自分の書いたビジネスロジックで例外発生させているのに、その例外を明示的に拾う事なくOTHERS で処理してしまっているということなんですね。
DECLARE
  user_expt exception;
BEGIN
  /* ... */
  IF ... != 0 THEN
    RAISE user_expt;  /*<- raise the exception you defined in your business procedure. */
  END IF;
  /* ... */
EXCEPTION
  /* not defined exception block for your own exceptions  */
  WHEN OTHERS THEN
    dbms_output.put_line(SQLERRM);
END;
/
自分のロジックで発生させているわけなんで、SQLERRMとか出力してみた所で、"User-Defined Exception"くらいの事しか出せないのは、普通に考えれば理解できると思います。

自分のビジネスロジックで発生させる例外はちゃんと明示的に拾って、メッセージも然るべきものを出力するのが最低限の礼儀作法ではないでしょうか。

DECLARE
  l_msg VARCHAR2(240);
  user_expt exception;
BEGIN
  /* ... */
 
  IF ... != 0 THEN
    l_msg := 'your own message for your procedure.';
    RAISE user_expt;  /*<- raise the exception you defined in your business procedure. */
  END IF;
  /* ... */
EXCEPTION
  WHEN user_expt THEN
    dbms_output.put_line( l_msg);
  WHEN OTHERS THEN
    dbms_output.put_line(dbms_utility.format_error_stack);
    dbms_output.put_line(dbms_utility.format_error_backtrace);
END;
/
ビジネスロジックで起きうるケース分例外定義するのは面倒な場合もあると思いますが、そういう場合は例の通りのユーザ定義例外を一つだけ定義して、RAISE する直前に出力させるメッセージを処理しておくのが良いと思います。ログ等にメッセージを出力したりする処理はどれもほとんど同じになるでしょうから、ユーザ定義例外をたくさん定義してそれごとに同じような処理を書くのはやってられなくなるでしょう。

"rase_application_error"を使うでもいいかもしれませんが、その辺はもっとファンクションを共通化したりとか、もう少し複雑な事が必要になった時に考えればよい所かな、と個人的には思います。

OTHERS例外は大部分は想定外なものでOracleが勝手に発生させてくる例外を処理するのに使う。
便宜的に SQLERRM を出力しておく、とかでもいいんですけど、最近のバージョンだったら DBMS_UTILITY の FORMAT_ERROR_STACK とか FORMAT_ERROR_BACKTRACE とかを使えば、どのプロシージャの何行目でエラーが発生したかまでわかるので、こっちの方がよいでしょう、きっと。

さらに、ループ回して何かしているのであれば、ループ中のどのデータでエラーが起きたかがわかるようにキー項目をどこかに保持しておいて、エラー処理の中で一緒に出力してあげれば、まあOHTERS例外の処理としては大体OKなんではないでしょうか。

あと、もう少し複雑なプログラム構造になった時の話として、本当に想定外なんで処理終了してしまえばいいという意味でのOTHERS例外はコールスタックの最上位で定義しておけばよくて、サブプロシージャやサブファンクションごとに OTHERS例外記述してリターンとかOUTでエラー返して、コール元がエラーかどうか判定してユーザ定義例外起こしてエラー終了みたいなまどろっこしい事はやめましょう。また、OTHERS で拾っておいて何もせずに"RAISE;" とかいうのは最悪なのでやめて欲しい。FORMAT_ERROR_BACKTRACE とかでエラーの発生位置が正確にわからなくなったりする事があると思います。

参考まで。


BloggerのエクスポートファイルをMovable Type形式に変換する

もう1ヶ月以上経ってしまったが、先日のBlog移行の際のメモ。

livedoorにブログを移すにあたって、bloggerからの移行は明示的にはサポートされていないのですが、Movable Type形式で持ってくればインポートできるとのことなんで、いろいろ漁ってみた所、こんなものを見つけた。

google-blog-converters-appengine

使うには、PythonGoogle GData API が必要との事。

まあ、Pythonさえ動けばプラットフォームは特に問わないんでしょうけど、なんとなく Linux とかの方が扱いやすい感じになっている気がするな、と。
手頃なLinux環境を準備するとか、WindowsでPythonとか使えるようにするとかもちょっと面倒だったので、今回は Cygwin を使ってみた。
たまたま思いついてやってみただけですが、やはりWindowsユーザにはこれが一番手っ取り早いと思います。

Cygwin のセットアップでパッケージを選ぶところで、Python以下を展開すると GData API も選択できるようになっているようなので、以下の2つを選択してセットアップします。
  python: Python language interpreter
  python-gdata: Python bindings for Google Data APIs

あとは cygwin の中で google-blog-converters を解凍し、~/bin に PATH を通す。
binの中に "blogger2movabletype.sh"  というシェルがあるのでインプットにbloggerからエクスポートしたファイル名を指定する。結果は標準出力に出力されるようなので、リダイレクト指定してファイルに出力と。
$ blogger2movabletype.sh blog-MM-DD-2011.xml > a.txt

これだけで出力ファイルをアップロード&インポートできる状態になりました。

古い記事は旧blogに置いたままでも別にいいか、とも思っていながら、試しにやってみた程度のものなので、細かい事を色々と気にしだすとできていない事はいくつかあります。

当然ですが、自分自身のblogの他の記事へのリンクとかは普通に旧blogのURLへリンクしてますし、画像ファイルとかも同じですね。
たぶんこれはインポートしてからでないとパーマリンクがわからないので、インポート後に地道に直していくしかないのでしょうかね?

あと、コメントは1件目しかインポートできていないっぽいです。
これは変換後のファイルには含まれているので、livedoorのインポートの問題なのでしょうか?
ちょっとよくわかりませんが、うちの場合は大したものはないし、旧blogも当面は放置だし別にいいか、というレベル。
むしろ旧blogでもらったコメントは旧blogにだけあればいいんじゃないの?くらいに思ってたりしますので、こだわりなし。

参考まで。

Linuxでディスク交換

Linuxはほとんど仮想マシンでしか扱わなくなっていますが、仮想ディスクのサイズ設定や構成を後悔したりとか、パーティションの切り方を変えたくなったりした時って、仮想かどうかは関係なく結局「ディスク交換」みたいなことをしなければいけない、というか、すればいいのかなと考えていろいろと試行錯誤してみた。

これはOS等を含んだブートディスクの場合です。ブートディスクでない場合は別に悩むことなくコピーして付け替えればよいと思います。
OSその他を再インストールしてデータ移行すればいいってのはわかるが、それはそれで結構手間がかかるし、ということで。

仮想ディスク絡みだったら、ツールとかもそれなりにいろいろあるのかもしれないけどその辺はあまり調べていない。
あっても結局、仮想ディスクファイルを物理ディスク的に扱うようなものだろうから、結局やりたいことにはならない可能性大と思ったので。

それから試してたLinuxはRed Hat系です。まあ別にこの辺は大して違いはないのだろうと思いますが。

新ディスクのパーティション設定


まずは新しいディスクを用意し追加で接続する。
そしてその新ディスクのパーティション設定を行う。
新ディスクが"/dev/sdb"として接続されている例です。
# fdisk /dev/sdb

対話的に操作できるので、順に設定していく。
使うコマンドはこんな感じでしょうか。
  • p 領域テーブルを表示する
  • n 新たに領域を作成する
  • a ブート可能フラグをつける
  • t 領域のシステム ID を変更する
  •  LVMを使う場合に、IDを"8e"に変更する
  • q 変更を保存せずに終了する
  • w テーブルをディスクに書き込み、終了する

私が試した時は元のディスクが以下のような感じだったので、同じようにパーティションを二つ作成し、一つ目は「ブート可能」に、二つ目はシステムIDをLVMに変更した。
  1. /boot
  2. /dev/VolGroup00
  3.  ※LVMの物理ボリューム、論理ボリュームには / と swap

LVMを使うパーティションについては、さらに物理ボリューム、ボリュームグループ、論理ボリュームの設定を行う。
# pvcreate /dev/sdb2
# vgcreate VolGroup00new /dev/sdb2
# lvcreate -L ????m -n LogVol00 VolGroup00new

「????m」は作成する論理ボリュームのサイズを指定。
lvcreate は新ディスクでやりたいマウントポイントの構成に応じて必要な分だけ実施する。
例えば、旧ディスクは / 以下に全部入れていたのを新ディスクでは /var とか /home を分けたいとかいう場合、それぞれに必要な論理ボリュームを作成する。。

さらにファイルシステムの作成。
# mkfs -t ext3 /dev/VolGroup00new/LogVol00

SWAPパーティションの場合は mkswap しておく。
# mkswap /dev/VolGroup00new/LogVol01


データコピー


旧ディスクから新ディスクにデータをコピーします。
コピー中に元データ変更されるとトラブルになる可能性があるので、シングルユーザモードかSystemRescueCdなどを使って起動してやった方がいいでしょう。
私が試した限りではどっちでも大丈夫そうでしたが、感覚的にはやっぱりSystemRescueCdを使うのが良いと思います。
シングルユーザモードとはいってもコピー元のディスクからOS起動しているわけなので、何かある可能性は高くなるような気がする。
その辺は別に詳しくないので、あくまで「気がする」だけです。

コピーのやり方はいろいろあると思いますが、私はとりあえず今何をしているかをわかりやすくするためにコピー元とコピー先用にマウントポイントを設けてやりました。
コピー先で一部を別パーティションにする場合はdest側に追加で mkdir & mount を必要な分だけ実施。
mountとコピーはコピー元のパーティション分、繰り返します。
# mkdir /mnt/source
# mkdir /mnt/dest

# mount -t ext3 /dev/VolGroup00/LogVol00 /mnt/source
# mount -t ext3 /dev/VolGroup00new/LogVol00 /mnt/dest

# cd /mnt/source
# tar cpf - ./ | tar xpf - -C /mnt/dest

実際のコピーですが、なぜか tar を使ってコピーする例があったのでやってみた。
一応問題なく動いているっぽいです。
普通に "cp" とかでもうまくいくんではなかろうかという気はしてます。
# cd /mnt/source
# cp -a ./ /mnt/dest/

ポイントはたぶん "p"オプションで所有者、アクセス権などを引き継がせる事だろう。
cp の "-a" は "-dpR" とmanページに記載があるのでほぼ同様の効果があると思われます。

ブートセクタ設定


ここが色々と苦戦して悩んだところではありますが、普通に grub-install しました。
# mkdir /mnt/boot
# mount -t ext3 /dev/sdb1 /mnt/boot
# grub-install --root-directory=/mnt /dev/sdb

適当に"boot"というディレクトリを作成して、そこに新ディスクの/bootパーティションをマウントする。
grub-install の "--root-directory"オプションではそのマウントポイントの一つ上を指定してやる。上記の例だと "/mnt"。
マウントポイントをそのまま指定するとその下に"boot"ディレクトリが作成されて、さらにその下に"grub"となってしまうので。

あとこんな感じでエラーが出る時がある。
/dev/sdd does not have any corresponding BIOS drive.

これはインストール先にある device.map が関係しているらしいです。
(hd0) /dev/sda

こんな記述になっていたりするので、コピー先のディスクに関する記述を追加してやれば良いようです。
(hd1) /dev/sdb

ただ、ディスク交換後はこの記述は必要ないと思うし、device.map ファイルがなければ接続しているディスク等を probe してインストールしてくれるようなので、/boot パーティションに関しては先に grub-install してからデータコピーをする方が、コピーしたものへの変更作業が少ないので、なんとなく気持ちがいい気がします。
それか少し面倒だけど新ディスクが"/dev/sda"になるように付け替えて、RescueCdから起動して grub-install でもいけますが。

/etc/fstab の確認


新ディスクの"/etc/fstab"を確認して、旧ディスクを外して新ディスクから起動する時に適切にマウントされる設定となるように必要に応じて調整します。
ディスク入れ替え後は新ディスクが"/dev/sda"になると思うので変えなくてよい場合もあると思います。
ここではLVMまわりで多少試行錯誤したところがあって、「"/etc/fstab"もなるべく変更しないで済むようにしよう」とか思って、vgrename でボリュームグループ名を変更とかしてみた。
それでももちろんできましたが、後で考えたらなんか変な感じがした。

"/etc/fstab"でデバイスがLABELで記述されている場合は"e2label"でラベルを付ける。
# e2label /dev/sdb1 /boot

あと、"/boot/grub/grub.conf"の kernel のパラメータも確認しておく必要があると思います。

ディスクを入れ替えて起動


ここまでくればもう大丈夫なはず。
ということで旧ディスクをはずし、新ディスクを先頭に接続して起動します。

OS起動は無事にできても、ログインしようとするとこんなエラーが出る場合がありました。
/etc/X11/xinit/Xsession default を実行できませんでした

これはどうもselinux絡みらしく、"enforcing mode" にしているとこうなる。
"permissive mode"にしておけばログインできますが、当然の如くselinuxの警告出まくりで。

ディスクの追加・交換をした時などは「ファイルのラベル付け」をあらためてやる必要があるようです。
# restorecon -rv /

ああ、なんかこの辺よくわかっていない、、、けど、とりあえずこれで動くようにはなった。

"/.autorelabel"ってファイルを作ってリブートしても同じ効果があるはず。
でも本当にこの影響かどうかもよくわかりませんが、ブート時のメッセージの出方が変わったりとかしている。今のところ実質的な影響はなしですが。

アプリの動作確認とかはそれほどしっかりとはしていないけど、理屈の上では大丈夫なはず、というところですね。

以下、参考にしたサイトなど。


最後のSELinux Policy Editorは試していない。

そういえば、なんか Oracle の11gなんかも、この辺ちゃんと設定しないと動かせないんだけど、面倒なんでとりあえず "permissive mode" にしておく、みたいな笑っちゃう話があった気がするね。
まあ "permissive mode" にして何が引っかかるかを探す、というのは常套手段のようではありますが。
いずれ見なければいけない日が来る、と思います。
記事検索
プロフィール

ntakano75

フリーランスでシステムエンジニアをやっておりました。

Twitter
AdSense
Amazon
  • ライブドアブログ