タグ: Perl

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

    【2021/05/10】
    「標準モジュール」に関する記事について、認識の違いがあったので修正。

    いつも「ホームページの仕様、どんなんだったっけ?」ってなるんで、備忘録。

    経緯

    元「@nifty @homepage」利用者は、「@nifty ホームページサービス」への移行案内の際、適切に手続きをしていれば、「@niftyホームページサービス(ミニ)」というプランで移行されている。

    これは @nifty を2016年以前から契約利用し、かつ当時無料にて提供されていた「@nifty @homepage」を利用していた人向けの、言わば「救済」プラン。

    プラン毎の違い

    ちなみに「@nifty ホームページサービス」には、以下の3つのプランがある。

    • LaCoocan ライト(1G。CGIなど色々不可)
    • LaCoocan スタンダード(4G。CGI、DB利用可)
    • LaCoocan スタンダードプラス(10G。スタンダードの大容量版)

    「ミニ」プランから「LaCookan スタンダード」「LaCookan スタンダード」のプランに変更することは可能。ただし変更後は、再度「ミニ」「ライト」プランに戻すことができない。

    「@nifty ホームページサービス」既存の各種プランと違うところ

    • ディスク容量が2GB(ライトは1GB、スタンダード4GB、スタンダードプラス10GB)
    • CGI は Perl のみ利用可(ライトは利用不可)
    • CGI 定期実行が利用可(ライトは利用不可)

    機能の違い

    「@nifty ホームページサービス」への移行によって変わった機能

    プライベートパック

    アクセス制限機能(.htaccess、.htpasswd)による BASIC 認証に変わる(利用には再設定が必要)。

    SSLも未提供。

    URL

    別物のサービスなので、URLも変わる。

    FTP

    サービス自体が別物扱いなので、すべて再設定が必要。
    接続先ホスト名・アカウント名などが変更になる。

    CGI

    ホームページアドレスとCGI環境のアドレスが統合され、すべてホームページアドレス内で動作するようになった。
    つまり cgi-bin ディレクトリがなくなり、すべて homepage ディレクトリ配下で、HTML ファイルと同じ場所にCGIの実行ファイルを設置し、そのファイルに実行権を与えれば動作するようになる。

    「@niftyホームページサービス」では提供されなくなった機能

    • アクセスカウンター
      (自前CGIで実現可能。だが今時のコンテンツにおいてアクセスカウンターは流行らないし機能不足。解析用途であれば、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 ホームページサービス」はフロントエンドに徹し、Webコンテンツの稼働に必要なデータ類を、可能なかぎり構築してから転送している。

    具体的には、バックオフィスにて tsv 形式のデータファイルなど、フロントエンド用のWebコンテンツ動作に必要なデータを構築・管理。
    フロントエンド側では、バックエンド側からアップロードされたデータファイルなどを Perl を用いた CGI で動作させている程度に留めている。

    ちなみに自分で必要な Perl モジュール(パッケージ・ライブラリなど)を設置することで「@nifty ホームページサービス」上で高度なWebコンテンツを構築することができる可能性はある。

    ただ個人的には、今のご時世、小手先でゴチャゴチャ調整するのは時間がかかるし、ライブラリのアップデート時などの追従性やセキュリティ面も考えると不安。
    もしそのようなコンテンツを実現したいのであれば、コスト面も踏まえると、もっと別の自由度の高いプロバイダーのサービスを使うと思う。

    そもそも「@nifty ホームページサービス」が、いつまで CGI のサービス(というかホームページサービスそのもの)を提供してくれるかも不明。
    (昨今ISPのホームページサービスは、契約者の利用率も右肩下がりなうえ、システムアップデートの追従やセキュリティなどの観点からコストに見合わず、提供終了されつつある。)

    ここまで考えると、他のプロバイダーサービスを利用するほうが良いのではないかと。

    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 ホームページサービス」にデプロイしています。

    この環境を構築するのが一番面倒、という話もある。

    【参考】使い道

    これらサービスの制約下でも、当方では無駄なく使っている。
    以下参考まで。

    ちなみにいずれのコンテンツも、管理機能はWebプログラミングが可能な別サイトに構築。

    期間限定の共有フォルダ

    URLを知っていればアクセスできるようなファイルを置く場所。
    期間超過のファイルは、「CGI定期実行」機能によって削除。

    ただし前述の通りSSLが使えないため、盗聴されると可能性あり。そのため、そのリスクを負っても問題ないようなファイルしか扱えない。

    画像アルバム

    風景写真とか。素材写真とか。
    こちらも当方(撮影・作成者)で権利関係の弊害がなさそうな画像を公開するために作った。

    郵便番号⇒住所変換

    文字通りのツール。
    そもそも tsv 形式のデータの抽出速度がどれ位かかるのかを調べるため、実験的に作ったもの。
    現実的な速度で提供できるように試行錯誤しながら提供中。

  • フォトアルバムを設置する

    こちらの記事は、今後のシステム開発で経過に応じて、随時編集・追記します。

    プロバイダーのホームページ領域を有効活用するため、フォトアルバムでも設置しようかと考えている。

    まぁ「フリーのCGIとかプログラムを導入すれば、いいんじゃね」というレベルの、とてもありがちなシステムをつもりなんだが、それら「吊るし」のシステムだと、自分が契約している Web サーバ領域を有効利用するためには、仕様・環境などの条件がイマイチ合致しない。

    特に問題となるのがこれ。

    @nifty ホームページサービス ミニプラン

    そう。
    公開ページの設置を予定しているこのWeb領域が、曲者。
    もともとは、老舗の「@nifty @homepege」の後継で、先代で提供されていた機能を、最低限継承した代物。

    なので、Perl は使えたりするものの、5.8.7 と古かったりとか、一部の標準モジュールが使えなかったりする。
    PHP も、このプランでは使えない。

    別の記事でも書いたが、上位プランに変更することにより、PHP やデータベースが利用できるようになるのだが、料金や自由度を考えると、別会社のプランを検討する。

    確かに巷の Perl CGI を探してきて、それを改造して無理矢理動かすというのも一案。
    しかしながら、それだと楽しくないし、そもそも巷の Perl CGI も、かなり前に作られたものが多く、レガシーな作り物が多い。

    そんなこんなの理由で、昨今のスタンダードな Web システムの実装とレガシーなサーバ環境の共存を研究する目的で、フルスクラッチしてみることにした。

    システム構成

    ありがちな「公開系」と「管理系」の2構成。

    フロントエンド(公開系)

    サーバは「@nifty ホームページサービス」
    Web コンテンツは「Perl (CGI) + Vue.js (CDN)」で実装。

    こちらは「見せるだけ」の機能に特化して、複雑な処理は走らせない。
    というか、制限付き CGI (Perl 旧バージョン+標準モジュール一部欠け)をゴリゴリ開発する気は、更々ない。

    Vue.js を利用するものの、フレームワークというよりは、結果セットのフィルタリングやソート時のエフェクト用途で利用する感じ。
    ほぼ「受け身」のシステムなので、この程度の簡単な環境で構築。

    バックオフィス(管理系)

    サーバは「さくらの VPS」
    Web コンテンツは「Laravel (PHP) + Vue.js(Laravel のUI として利用)」

    こちらは管理機能を実装するため、Web システムとしてはガチ。
    とはいえ、昨今の Web システムでは、割とスタンダードな環境。

    ちなみに Laravel が Ver.5.x までであれば、Vue.js は内包されていたため、「さくらのレンタルサーバ」でも構築できた。

    しかしながら Laravel Ver.6 以降、Vue.js はコマンドで追加インストールするようなスタイルになった。
    しかもこのコマンド、中で npm を使用するのだが、この npm が「さくらのレンタルサーバ」がインストールされていない。

    調べた限りでは「さくらのレンタルサーバ」に npm を力業でインストールするような猛者もいたようだが、当然ながらトリッキーなため、この時点で「さくらのレンタルサーバ」も採用外とし、「さくらのVPS」への実装とした。

    個人的には、今後のシステム開発において「さくらのレンタルサーバ」は、パッケージ不足等で、いよいよ「使えない」という時代がやってきた事を感じてしまった瞬間であった。

    公開系と管理系、「さくらの VPS」で構築すれば楽じゃね?

    確かにそうなんだけども。
    でも、元々「さくらの VPS」は、非公開系のサーバとして運用しているという個人的な事情と、公開系と管理系を同居させることによるセキュリティ面の配慮で分けた次第。
    また「レガシーな Web 領域(=@nifty ホームページサービス)を有効利用する」という命題に応えるため、このような環境にした次第。

    重要な考慮すべき部分

    バックオフィス⇒フロントエンドの同期

    データの追加・更新・削除の都度、キューを作成し、それを非同期バッチにて処理する事によってデータの内容をフロント側に反映することで同期する。

    クラッシュ対策(バックアップ)

    システム基盤(プログラムソース)については、別途バックアップする(というか、Git に保管しておく)のが前提。
    ここで言うのは、データの話。

    ちなみに、この Git リポジトリ。PostHook で別サーバに Fetch してるので、リポジトリ自体も複数保存している。

    公開系

    もともとデータはすべて「管理系」に保持していて、そこから抽出・アップロードされるため、クラッシュしても、データは「管理系」のほうから再度抽出することでリカバリ可能とする。

    管理系

    データについては、日毎のバックアップをバッチ処理し、バックアップサーバ(ストレージ)に転送する。

    考えていること

    データ連携

    最初はこんな感じで考えていたのだが、もしかしたら Perl の簡易データベース(dbmopen など)が使える可能性があるので、利用可能であれば、その形式に寄せるつもり。

    画像

    閲覧用画像データには、コピーライトの埋め込みで、以下の候補を検討中。(TBD)

    • ウォーターマーク ⇒ ImageMagic で可能だが、簡単に消せる。
    • 電子透かし ⇒ できればこっちを考えている。
      ステガノグラフィーが主流だと思うけど、技術的に標準化されてないので、できれば標準的なのが使いたい。
  • Eclipse よ、今までありがとう

    およそ10年弱の今まで、Windows の IDE として使ってきたけれども、そろそろお別れの時がきたよ。

    今思えば、キミとの付き合いは紆余曲折の連続だった。

    私がサラリーマンの頃、まず出社してやることは、パソコンの起動、そして次に Eclipse。そう、キミの起動だ。
    会社から支給されたパソコンはとても非力で、キミの起動には数分の時間を要したのをよく覚えているよ。そのお陰で、起動操作ののち、僕はトイレやコンビニに行って、朝の優雅な時間を過ごすことができた。

    でもそんな怠惰な生活に嫌気がさして、NetBeans に一度浮気したこともあったね。
    その Netbeans も、一時オラクル社に浮気したお陰で(?)、バージョンアップがパッタリ止まったりしたことがあって、そんな浮気騒動も一度きり、僕は目が醒めて戻ってきてしまったけど、君は文句も言わず、相変わらずの怠惰な起動で優しく出迎えてくれた。
    そんな出来事も含めて、いい想い出だ。

    でも僕は、新たな旅に出たいと思う。そう、いよいよ戻らない、新たな旅に。

    今までありがとう、Eclipse。
    きっと君のことは忘れないよ。(多分?)

    …というわけで、Visual Studio Code(VSCode)に鞍替えです。
    だって起動が速いし、Extentions も沢山そろってるし、PHP の各種フレームワークバリエーションにも対応してるみたいだし。
    それに C/C++、Java、Python、Perl、Ruby など、仕事柄、多言語を使用する立場として、各言語対応なのは、とても有り難い。

    UI も Windows ライクなのも良い。
    Visual Studio ライクな感じで、本家の血筋なのも良い。

    要するにミーハーなだけなんですが。
    でも使い勝手が良ければ、それを利用するに越したことはないかと。

  • sb(Serene Bach)

    ブログエンジン。

    • sb開発研究所(リンク切れ)
    • sb、Perlのみで動作するブログ(1/25)(雑木林とコンピュータ)(リンク切れ)