【2021/05/10】
「標準モジュール」に関する記事について、認識の違いがあったので修正。
いつも「ホームページの仕様、どんなんだったっけ？」ってなるんで、備忘録。
- 自作CGI利用方法（@nifty @homepage、参考用。旧サービスの内容のため注意）
- @homepage の移行先サービスについて教えてほしい。（@nifty 会員サポート）（ページ削除）
- @nifty @homepage（旧サービス）
- @nifty ホームページサービス（現行サービス）
経緯
元「@nifty @homepage」利用者は、「@nifty ホームページサービス」への移行案内の際、適切に手続きをしていれば、「@niftyホームページサービス（ミニ）」というプランで移行されている。
これは @nifty を2016年以前から契約利用し、かつ当時無料にて提供されていた「@nifty @homepage」を利用していた人向けの、言わば「救済」プラン。
プラン毎の違い
ちなみに「@nifty ホームページサービス」には、以下の３つのプランがある。
- LaCoocan ライト（1G。CGIなど色々不可）
- LaCoocan スタンダード（4G。CGI、DB利用可）
- LaCoocan スタンダードプラス（10G。スタンダードの大容量版）
「ミニ」プランから「LaCookan スタンダード」「LaCookan スタンダード」のプランに変更することは可能。ただし変更後は、再度「ミニ」「ライト」プランに戻すことができない。
「@nifty ホームページサービス」既存の各種プランと違うところ
- ディスク容量が２ＧＢ（ライトは１ＧＢ、スタンダード４ＧＢ、スタンダードプラス１０ＧＢ）
- CGI は Perl のみ利用可（ライトは利用不可）
- CGI 定期実行が利用可（ライトは利用不可）
機能の違い
「@nifty ホームページサービス」への移行によって変わった機能
プライベートパック
アクセス制限機能（.htaccess、.htpasswd）による BASIC 認証に変わる（利用には再設定が必要）。
ＳＳＬも未提供。
ＵＲＬ
別物のサービスなので、ＵＲＬも変わる。
ＦＴＰ
サービス自体が別物扱いなので、すべて再設定が必要。
接続先ホスト名・アカウント名などが変更になる。
ＣＧＩ
ホームページアドレスとＣＧＩ環境のアドレスが統合され、すべてホームページアドレス内で動作するようになった。
つまり cgi-bin ディレクトリがなくなり、すべて homepage ディレクトリ配下で、HTML ファイルと同じ場所にCGIの実行ファイルを設置し、そのファイルに実行権を与えれば動作するようになる。
「@niftyホームページサービス」では提供されなくなった機能
- アクセスカウンター
（自前ＣＧＩで実現可能。だが今時のコンテンツにおいてアクセスカウンターは流行らないし機能不足。解析用途であれば、Google Analytics などを導入するほうがよいと思う。） - サクサクかきあげ君
- 簡単マイページ設定
- 公開停止・再開機能（アクセス制限機能で代用可能）
- 素材集（巷のWebコンテンツから拾えばよい）
「@nifty ホームページサービス」から提供される新機能
- CGI 定期実行（LaCoocanライトを除く）
- .htaccess（アクセス制限）
- 独自ドメインの利用（ドメイン取得や維持は別料金）
- カスタムエラーページ
LaCoocanスタンダード（プラス）にアップグレードすることで提供される新機能
- sendmail
- アクセスログ解析
- 簡単インストーラー（WordPress などが導入可能、らしい）
- データベース（MySQL、SQLite）
Perl（CGI）について
Perl 5 標準モジュールが一部欠けている
@homepage 時代と同じ。
ちなみに、perl 5.8.7（2021年3月時点）
ちなみに公式的には標準モジュールは提供しないとしているが、実際のところ、一部は利用可能。
しかしながら、例えば「DB_File」や「DateTime」モジュールが利用できない等、便利なモジュールが一部省かれている。
それに、今は使えているモジュールが今後使えなくなる可能性だってある。
なので、意味合いとしては標準モジュール提供は保証しないという形で捉えるのが妥当。
その影響により、ファイルアクセスだろうが、データアクセスだろうが、何をするにしても、原始的なレベルの作り込みが必要になる場合がある。
よって「@nifty ホームページサービス」における Perl は、かなり単純な機能のみを提供するようにしないと、開発・保守の両面からコストが発生することを念頭に置く必要あり。
自分の場合も、バックオフィスは別プロバイダで提供されている PHP と MySQL などで実装し、「@nifty ホームページサービス」はフロントエンドに徹し、Ｗｅｂコンテンツの稼働に必要なデータ類を、可能なかぎり構築してから転送している。
具体的には、バックオフィスにて tsv 形式のデータファイルなど、フロントエンド用のＷｅｂコンテンツ動作に必要なデータを構築・管理。
フロントエンド側では、バックエンド側からアップロードされたデータファイルなどを Perl を用いた CGI で動作させている程度に留めている。
ちなみに自分で必要な Perl モジュール（パッケージ・ライブラリなど）を設置することで「@nifty ホームページサービス」上で高度なWebコンテンツを構築することができる可能性はある。
ただ個人的には、今のご時世、小手先でゴチャゴチャ調整するのは時間がかかるし、ライブラリのアップデート時などの追従性やセキュリティ面も考えると不安。
もしそのようなコンテンツを実現したいのであれば、コスト面も踏まえると、もっと別の自由度の高いプロバイダーのサービスを使うと思う。
そもそも「@nifty ホームページサービス」が、いつまで CGI のサービス（というかホームページサービスそのもの）を提供してくれるかも不明。
（昨今ＩＳＰのホームページサービスは、契約者の利用率も右肩下がりなうえ、システムアップデートの追従やセキュリティなどの観点からコストに見合わず、提供終了されつつある。）
ここまで考えると、他のプロバイダーサービスを利用するほうが良いのではないかと。
use strict; use warnings; は役立たず。
とは言っても「外せ」という意味ではなく。
「@nifty ホームページサービス」は、（@homepage サービスの時代と同じく）ブラウザ上では全部500エラーが表示されるだけ。
また管理画面等からエラーログを確認するための手段もない。そのためエラーが発生しても、原因を掴むことは至難。
実際には、デバック文を挿入したり、変数を表示させるなどの手法で動作確認したり、ソース全体を、
eval {
...（CGIソース本体）...
};
if ($@) {
print "Content-type: text/html\n\n";
print "<title>error</title>\n";
print "$@\n";
}で囲い込んで、無理矢理エラーを表示させることも可能かもだが、正直微妙。
自分の場合はエラーを追跡するため「だけ」に、標準モジュールの存在しない開発・動作確認用のサーバを別途建てて、それから「@nifty ホームページサービス」にデプロイしています。
この環境を構築するのが一番面倒、という話もある。
【参考】使い道
これらサービスの制約下でも、当方では無駄なく使っている。
以下参考まで。
ちなみにいずれのコンテンツも、管理機能はＷｅｂプログラミングが可能な別サイトに構築。
期間限定の共有フォルダ
ＵＲＬを知っていればアクセスできるようなファイルを置く場所。
期間超過のファイルは、「ＣＧＩ定期実行」機能によって削除。
ただし前述の通りＳＳＬが使えないため、盗聴されると可能性あり。そのため、そのリスクを負っても問題ないようなファイルしか扱えない。
画像アルバム
風景写真とか。素材写真とか。
こちらも当方（撮影・作成者）で権利関係の弊害がなさそうな画像を公開するために作った。
郵便番号⇒住所変換
文字通りのツール。
そもそも tsv 形式のデータの抽出速度がどれ位かかるのかを調べるため、実験的に作ったもの。
現実的な速度で提供できるように試行錯誤しながら提供中。