プログラム

125件の投稿

CMS（Content Management System）

WEB

ホームページは誰でも簡単に作成できますが、
気の利いたホームページは誰にでもできる訳ではありません。

その点CMS（Content Management System）は、
画面レイアウトやデザインは無料の美しい気の利いたものが使えますので、
デザインに力を入れることができない人には、
とてもありがたい仕組みです。

現時点で評判のいいCMSはWordpress、Joomla、Drupalだと思います。
これらは何れも無料で使うことができます。
しかもこれらのCMSの周りには様々な有償・無償の「部品」が出回っていますので、
これらを使うと充実したホームページを作成できます。

日本ではまだあまり使われていないかもしれませんが、
世界的には沢山のCMSを使ったホームページがあるようです。

このブログそのものはWordPressを使っていますし、
このサイトはJoomlaで作成していいます。

WordPressはブログ専用として使う分には大して難しくはありませんが、
これをHP用ツールとして使う場合は研究が必要だと思います。

CMSを知らない人もいると思いますので少し説明します。

一般的にいって、ホームページに載せる情報は、
ホームページのメイン画面のキャッチや商品紹介のような固定のページ、
製品開発の進捗や新商品の発売を日付を追ってお知らせするブログ、
フォーラム等ホームページにアクセスする人が参加するページ等ありますが、
無数にいろいろな種類があるわけではありません。

またそれらをナビゲートする方法（メニューのつけ方）も限られています。

要はそれらをいかにカッコよくまた効率よく配置するかです。

CMSではホームページのあらゆる情報をデータベースに保存し、
デザインの基本はPHPで書かれたテーマ（あるいはテンプレート)といわれる部分が担当します。
デザイン上の細かい指定はCSSで設定するようになっています。
（必要であれば、テーマのコードを修正します）

CMSによって、デザインフレームはテーマとかテンプレートとか異なった名称になっています。
他の「部品」の名称もCMSによって異なります。

各CMSの仕様にそった有償・無償のテーマ（テンプレート）がたくさん出回っていますので、
気に入ったものを使えば素晴らしいホームページが作れます。
更に気が変わって違うテーマと入れ替えれば、
たちまち異なるデザインのホームページに変身します。

表示画面のデザインの変更だけでなく、
ホームページをを全面的に組み替える作業も、
HTMLファイルを再構成するよりもはるかに効率よくできると思います。

デザインだけでなく、
ページを彩るカレンダーや検索やフォーラム等はモデュールという「部品」になっていて、
気に入ったものを探し自由に使うことができます。
これらは大抵無償です。

CMSの長所でもあり欠点でもありますが、
一度CMSをサーバーにインストールしてしまえば、
あとはホームページを作成する過程では「直接」サーバーにアクセスすることはありません。
ブラウザからCMSにログインし、ブラウザの中ですべての作業をします
（デザインの変更さえ）。

CMSを使わない従来のホームページ作成では、
ローカルコンピュータにIISやXAMPP等のローカルHTTPサーバーを立ち上げ、
このHTTPサーバーの下に、
Dreamweaver等のホームページ作成プログラムを使ってホームページを作成していきます。
出来上がった一連のファイルを公のサーバーにFTPを使ってアップロードし、
ホームページとして公開します。

ところがFTPではサーバーの当該ホームページエリアだけでなく、
サーバー上のあちこちのファイルやフォルダを参照できますし、
それらをを削除ｌすることさえできます。

先にも書きましたが、CMSでは一度CMSのインストールが完了すると、
後はCMSの中だけの作業で、直接サーバーの中を覗くことはありません。
この点セキュリティの面で優れています。

CMSのユーザの権限をいろいろ設定することで、
CMSの管理者や記事を書く人、単なる閲覧者等のユーザ管理ができます。

さてCMSには上に挙げた他にも色々長所があると思いますが、
逆に欠点もあります（本質的にやむを得ない特徴ともいえます）。

まず第一にCMSを使いこなすには、それ相応の勉強が必要です。

多くのCMSは日本製ではないし、日本語のいい解説書が殆どありません。

それになぜか少なくとも日本のCMSの開発グループやユーザグループに内輪もめが多いようです。
日本製CMS・XOOPSやDrupal日本ユーザグループはよくは知りませんが、
ガタガタしているように見えます。
その分情報がキチットでてきませんので、CMSそのものの発展の妨げになっています。

CMSには思わぬ本質的欠点があります。

CMSは次々発展しています。
CMSそのものが、
HTTPサーバー、DataBase（MySQL、PostgreSQL）および開発言語(PHP)に依存していますので、
長くレンタルサーバーを使っている場合、
サーバーとCMSのバージョンのミスマッチが発生します。

共用レンタルサーバーでは、
原則WEBサーバーやデータベース等のバージョンを上げません。
うかつにあげるとユーザのプログラムが動作しなくなる恐れがあるからです。

ところがCMSは次々に新しいバージョンを発表しますので、
新しいCMSや新しいデザインを使いたくても古いサーバーでは使えなくなります。

CMSに合わせてWEBサーバーを替えたとして、
今度はCMSデータの引っ越しがスムーズにいくかどうかの問題があります。

ともかく気の重い作業が発生します。

従来のホームページではファイルをそっくり移動すれば済む話ですが。

InstallAware

ｲﾝｽﾄｰﾙ･ﾌﾟﾛｼﾞｪｸﾄ プログラム

InstallAwareのドキュメントは驚くほど貧弱で、しかも英文しかありません。
しかしそれに反してソフトは評価できます。

InstallAwareでは[Windows Installer]の仕様に沿った3タイプのセットアッププログラムを作成します。
すなわち単一圧縮ファイル、CDあるいはDVDに焼き付ける形およびWEBからインストールする形です。

WEBインストールでは、
インストールが始まった時は必要最小限のプログラムだけダウンロードし、
インストールの途中で必要になったソフトを、
設定URLからダイナミックにダウンロード・インストールするようになっています。

また当該プログラムが動作するために必要なRuntimes（.NETやSQL Server等）がすでにインストールされているかどうかを確認し、
なければこれらをインストールします。

標準では用意されていないRuntimes（例えばAccessRunTime）の検査およびインストールも、
比較的容易にコーディングできます。

ただしRuntimesに関して一つの欠点があります。

WEBインストールではRuntimesをWEBに置くので問題ないのですが、
その他のインストールでは、
アプリケーションプログラムが必要とするすべてのプログラムをセットアッププログラムに入れておかなければいけません。
SQL Server等Runtimesは一般に大きなプログラムですし、
ターゲットコンピュータにはすでにインストールしてあって、
改めてインストールする必要がないかもしれません。

CDやDVDの場合は良いのですが、
単一ファイルにしてダウンロードする場合は、
ダウンロードそのものが大変ですし、その上無駄な作業になる可能性があります。

単一ファイル・セットアップをインターネットからダウンロードする形で使わないで、
WEBインストールかメディアインストールかにすればいいのでしょうが、
下に書きますようにWEBインストールでは手間暇かかるので、
すくなくともデバッグの途中では単一ファイルをWEB上に置きたくなります。

WEBインストールに問題があります。

上で書きましたが、WEBインストールでは最小限のセットアッププログラムと、
Runtimes等のいくつかの７zipファイルを作りますので、
これらの７zipファイルを指定のURLにアップロードしなければいけません。

これらのファイル名はInstallAwareの中では、大文字小文字が混ざっています（ケース・センシティブ）。
例えば、[Microsoft .NET Framework Client 4.7zip]のようです。
ところが、InstallAwareはWindowsの開発環境にセットアッププログラムの一部として
[microsoft .net framework client 4.7zip]のようにすべて小文字のファイルを出力します。

InstallAwareのユーザは、
小文字のファイル名を[Microsoft .NET Framework Client 4.7zip]のように変更して、
所定のURLにアップする必要があります。

セットアッププログラムのデバッグでビルドする度に、
何度も何度もファイル名の変更とアップロードが必要になります。

この表現は正確ではありません。
ファイルはいくつかのRuntimesと
ユーザが設定する[Program Files]や[Data Files]等のFeaturesに対応して作成されますが、
Runtimesは毎度同じですから何度も作成しなくてよいのです。
その代りデバッグ中のFeaturesはその都度更新しアップすることにないｒます。

Featuresはセットアッププログラム特融の概念です。専門的で申し訳ありません。

InstallAwareのForumでもこのことにクレームがきていました（2008年）。
「アップするサーバーがLinuxの場合ファイル名はケース・センシティブだから、
これに対応するように改良してほしい」というものです。

とことがInstallAwareの開発者は、
「Windowsではファイル名は大文字でも小文字でも同じ扱いだからこれでいいのだ」
「だいたいInstallAwareはWindows用のツールなのだ」と見当違いの主張をします。

明らかにユーザの主張が正しいのですが、
大体InstallAwareがそのことを認識していないことに驚く次第です。

最近のInstallAwareの別のスレッドの回答では「改良検討中」になっていました。

私は仕方ないのでPerlで、
ファイル名を変更して指定のURLにアップするプログラムを書き、
InstallAwareでビルドする度にこのプログラムを実行することしました。
Perlはこういう仕事に適しています。

それにしてもこれはInstallAwareの中で処理すべきです。

インストールでよく使われている、
ユーザ名とシリアル番号の入力を促すセットアッププログラムの例が標準で用意されています。

インストールしようとしているアプリケーションプログラムの依存Dllの検出は、
InstallAwareの中で当該アプリケーションを動作されることで収集できますが、
使ったすべてのDllをユーザのプログラムフォルダにコピーする仕組みになっていますので
「これはいらないのではないの」というもの（例えばマウスのドライバー）も入ってきます。

マイクロソフトのセットアッププログラムでは、
必要最小限の依存プログラムを収集します。
InstallAwareでそれだけを組み込んでセットアッププログラムを作成しても正常動作しますので、
「それでもいいのでは?」と思っています。

InstallAwareそのものはすべて英文ですが、
作成したセットアッププログラムでのインストール時の表示は、
比較的容易にローカライズ（日本語化）できます。
またインストール用画面（ダイアログ）も自分で作成できるようですが、使ったことがありません。

InstallAware2012にはTrialWareというツールがあります。

デモ用でインストール後に期限切れにする仕組みを作成します。
「ある回数使ったら」とか「何日たったら」とか色々な設定ができます。
eCommerceと組み合わせて、try-and-buyの仕組みにできそうです。

私はとりあえずtry-and-dieの仕組みだけ使って、
「期限がきたら終わり」という形にしたいと思います。

私はこれまで、デモ版ではアプリケーションプログラム本体で機能を制限していましたが、
TrialWareではプログラム自体は変えないで、
セットアッププログラムで期限切れを設定するだけなので「とても使いやすいかな」と思っています。

ただし悪いことに「あと何日で期限切れです」
という案内は日本語がでません。

TrialWareにバグがあります。

アプリケーション・プログラムのExeファイルを、
スタンドアロンで期限チェックプログラムのラップをして、
このラップされたEXEを、
InstallAware2012 IDEでセットアッププログラムに組み込めば問題ないのですが、
IDEの中でいっきにこの処理をしようとするとエラーになります。

メーカーに調査依頼しています。
回答待ちです。

秀逸なのはPatchプログラムです。

アプリケーションプログラムを改変したとき、
ユーザが使用しているプログラムにPatchをあてなければいけません。
InstallAware2012では古いセットアッププログラムから容易にPatchプログラムを作成できます。
変更のあった部分を自動で認識し、
アプリケーションの環境でその部分（Featureを構成するComponent単位で）を入れ替えるようです。

PatchとかUpdateとかは、Windows　Installerの仕様のようですが、
プログラムの更新が容易にできる仕組みはすばらいいです。

セットアッププログラム >>　InstallAware

ｲﾝｽﾄｰﾙ･ﾌﾟﾛｼﾞｪｸﾄ プログラム

このブログで何度か書きましたが、
ソフトウェアを開発したら、
そのソフトをターゲットコンピュータにインストールするプログラムを作成しなければいけません。

「ターゲットコンピュータのどのフォルダーにどのプログラムやデータをインストールしていくか」
ということですが、
厄介なのは自分が作成したプログラムだけでなく、
自分のプログラムを動作させるために必要な、
マイクロソフトやサードパーティーのソフトもインストールしなければいけないことです。

パッケージソフトの場合はターゲットコンピュータも様々ですし、
それぞれのターゲットコンピュータには様々なソフトがインストールされていますので、
考えもせず各ソフトを勝手にインストールしていたのでは、
各ソフトが干渉してコンピュータがパニック状態になります。

ですから各ソフトのインストールは大変微妙な作業で、
そのためにインストール(セットアップ)作業をサポートするツールが必要です。

最も有名なソフトは[InstallShield]です。

セットアッププログラム作成ツールはどれも高価で、
[InstallShield]では安価な版でも10万円程度です。
内容は知りませんが上位のものは100万円もします。

今時高価なセットアップ作成ツールを買える（採算の合う）ソフトはどれだけあるのでしょうか。

これほど高価なのは、セットアップ作成ツールの市場が大きくないからかもしれません。
パッケージソフトを作っている会社にとっては必需品ですが、
市場規模としては大きくはないのでしょう。

私は以前は[InstallShield]を使っていたのですが、
数年前に[InstallAware]というソフトにしました。
理由は安く入手できたからです。

InstallAwareは[InstallShield]の開発会社から独立した社員が作っているようです。

最近はもっぱらこのソフトを使っています。
自分に必要なところをつまみ食いしているだけで、
全てを知っている訳ではありません。
なんとか手さぐりでインストールプログラムを作成しています。

このソフトの評価を最初に書きますと、
内容は良いのにドキュメントやサポートがとても悪いということです。
実は会社の所在地もよくわからないのですが多分米国で、ドキュメントはすべて英文です。

ドキュメントは5世代も前のもので、
しかも一冊になっていないので、
同社のホームページを探し回ってやっと何とかなるというような状態です。

フォーラムがありあますが、そこでの回答もそっけなく、
そこからの情報も大変悪いです。
ともかく次のところまで行きつきました。

インストールプログラムはCDでの配布あるいはWEBからのダウンロードとし、
インストールにはユーザ名とシリアル番号の入力を必要とする。

CD（あるいはDVD）でのインストールは昔からのインストール方法で、
最近では、インターネットからダウンロードしてインストールする方法も多くなってきました。

WEBインストールはソフト提供側からすれば、
解説書の印刷やメディアの作成等経費が軽減できますし、
将来の変更への対応やユーザの管理も容易で、
不正インストールの防止もできますので、
今後ますます増えていくことでしょう（ユーザは不満かも知れませんが）。

これからはクラウドが発展するのでしょうし、
クラウドではインストールプログラムの役割も変わってくるのでしょう。

InDesing

プログラム

もう一年も前の話ですが、「マニュアルの作成にWordとDreamwverを使います」と書きました。InDesignがいいとは思ったのですが高価ですので、たまに使うだけなのにそれだけ投資するのに躊躇しました。

Yahooオークションをウｵッチしていたら、InDesign2.0が安く出ていたので落札しました。確か7千円位だったと思います。多分10年位前のリリースだと思いますが、たまに使う人にはこれで十分です。

Vistaにインストールを試みましたがインストールできませんでした。Windows 7は試していません。結局XPにインストールしました。

中古ですがマニュアルもついています。CS5の解説本を買って補足しています。

使ってみると餅は餅屋でとても満足しています。画面コピーの解像度を心配することなく最善の画像で印刷できます。ページ付や目次や索引も作ってくれます（索引は試していません）。

機能が豊富なので使いこなすには大分時間が必要だと思います。

Adobeのソフトは良いのですが、どれも高価でもう少し手の届く価格にしてくれればいいのですが…
素人ユーザは相手にしていなくて、プロのデザイナーやDPT作業者を相手にして、高価でもプロの人たちにより良いものを開発するという考えなのでしょう。

コード

プログラム

例えば、”様”とか”殿”とか”御中”とかの敬称を幾つかのForm(あるいはクラス)で使うとします。データベースの中の顧客テーブルでこれをどのように表現するかという問題です。

最初の案は、顧客テーブルの敬称列に”様”、”殿”、”御中”をそのまま記入します。敬称がたくさん使われていないのであればそれでもいいかもしれませんが、沢山ありしかも列の値(”様”、”殿”、”御中”等）が長い場合、あるいは今後変更が予想される場合は、データベースでは列の値そのままではなくコードを使う方が有利です。

最初に考えるのは、すべてのコードをたとえば2ケタの整数で表現する方法です
（勿論数字でなく、アルファベットでも日本語でもここでの議論では本質的に同じです）。最初の桁はコード分類：たとえば性別は1、敬称は2とします。2桁目は項目の内容：たとえば”様”は”1″、”殿”は”2”、”御中”は”3”
とします。

するとたとえば”12”は敬称の”殿”を表現しています。

この方法の長所は単純だということですが、欠点は後の変更に対応しにくいことです。たとえば分類区分が1桁で足りなくなったとき、あるいはあとで考えるとコードを入れ替えた方がいい等メンテナンス上の弱点があります。

次の案はコード区分、項目名、コード等の列を持つコードテーブルを作る案です。下のようになっています。

敬称、様、0
敬称、殿、1
敬称、御中、2

顧客テーブルの敬称列にはコードテーブルのコードを記入します。Formで顧客の敬称を表示するには、顧客テーブルとコードテーブルのJoinを使って項目名を取得し表示します。画面の[敬称]データを保存するときは、逆に敬称と項目名から同じくSQLを使ってコードを算出し、顧客テーブルにこのコードを保存します。

ただしこの方法では顧客のコードを算出するのに、そのたびにデータベースへのアクセスをしますのでいかにも非効率です。

当然データの量とIOアクセスのトレードオフを勘案しなければなりませんが、このテーブルデータをメモリ上に保存することを考えます。

私は長年ある意味原始的なDictionaryを使った方法を使っています。多少工夫をしていますが、ベストと思っている訳ではありません。参考までにご紹介します。

今例として性別と敬称の処理を取り上げます。

まず、BICollectionというクラスを定義します（勿論名前は何でもいいです）。
中身は項目名からコードを検索するDictionaryと、逆にコードから項目名を検索するDictionaryからなります。

Public Class BICollection
    Private m_dist項目名2CD As Dictionary(Of String, Integer)
    Private m_distCD2項目名 As Dictionary(Of Integer, String)

	・・・・

     Public Function GetCD(ByVal prm項目名 As String) As Integer
        Return m_dist項目名2CD(prm項目名)
    End Function

    Public Function GetName(ByVal prmCd As Integer) As String
        Return m_distCD2項目名(prmCd)
    End Function
End Class

これに対して、列挙子とオブジェクトを定義します。

    Public Enum CODE
      性別
        敬称
	・・・・
        LAST = 999
    End Enum

    Public BIC性別 As BICollection
    Public BIC敬称 As BICollection

さらに、列挙子をキーにBICollectionオブジェクトをValueにしたDictionaryを定義し、CODE列挙子と項目名からコードを算出するメソッドと、逆にCODE列挙子とコードから項目名を算出するグローバル・メソッドを定義します。

     Public Dct区分2BIC As New Dictionary(Of Integer, BICollection)

    Public Function GetCd(ByVal prmPF As Integer, ByVal prm表示名 As String) As Integer
        Return CType(Dct区分2BIC(prmPF), BICollection).GetCD(prm表示名)
    End Function

    Public Function GetName(ByVal prmPF As Integer, ByVal prmDbCode As Integer) As String
        Return CType(Dct区分2BIC(prmPF), BICollection).GetName(prmDbCode)
    End Function

敬称の”様”からそのコード（今その値は0とします）を計算するには、
GetCd(CODE.敬称, “様”)で、逆に性別の”0″の項目名は、　etName（CODE.敬称, 0）で算出します。

実際にはBICollectionにはもう少し情報が付加されていて、性別や敬称の項目名とそのコードをもっていますので、ComboBoxのItem設定の仕組みも持っています。

すなわち、項目名をDisplayMemberにコードをValueMemberに設定しますと、ComboBoxで表示されたTextはDisplayMemberに、ValueMemberはコードを示します。

しかし、LINQが使えるようになった今は、メモリ上でSQLを作成できますので特別厳密に処理速度を求めるのでなければ、LINQの方が数段すぐれているように思います。