「@nifty @homepage」利用者だった人のための「@nifty ホームページサービス」について

【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 形式のデータの抽出速度がどれ位かかるのかを調べるため、実験的に作ったもの。
現実的な速度で提供できるように試行錯誤しながら提供中。