タグ: Web

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

  • table レイアウトと div レイアウト

    基本的には <div> とスタイルシートを用いて、コンテンツデザインが実現できるのであれば、そうすべきだと思います。
    理由としては、以下。

    • <table> タグを使用すると、自ずと <tr> <td> タグを使用することになる。
      その点 <div> タグとスタイルシートの関係さえ効率的に定義すれば、タグの記述が減らすことが可能なため、HTMLファイルの中身がスッキリする。
    • スマートフォン用ページなど、レイアウトを変更したページを実現する事が比較的容易。

    ただし <table> タグによるレイアウトを用いないと、上手く実現できないレイアウトもあります。例えば、

    1. メインブロック(枠線付き)は、常にウインドウ縦横両中央(ど真ん中)に表示。
    2. ウインドウ下部にフッタ。
    3. ウインドウの縦幅を縮めた場合、メインブロックとフッタが重ならない、レイアウトは崩されない。
      メインブロックとフッタがくっついたら、縦スクロールで逃げる。

    この場合、諦めて <table> タグを使用するほかありません。

    また、<div> タグとスタイルシートの関係さえ効率的に定義体系的に行わないと、タグは減らせません。

    それに、iモードをはじめとする携帯向けページは、HTML 規格そのものが異なるため、<div> や <table> タグでは対応できない。
    本当なら携帯でもスタイルだけを変更して表示させたいところだが、現時点では HTML ファイルそのものを別にするしかない。

    • tableレイアウトとdivレイアウト…どっちも地獄(マイコミジャーナル)(閉鎖)

    まぁでも、将来を見据えて XHTML 化ぐらいは視野をいれておくとよいかも。
    とはいえ、現状関係しているクライアントは HTML 世代の方々なので、本格的な XHTML ソースコード化は避け、XHTML 化する際に影響の少ないソースコードを書いていただく方向だけで。
    そうする事により、将来のリニューアルも見据え、かつ現状デザインにおいても、体系的なコンテンツ制作がもできると思います。

  • Web コンテンツの動作確認

    • Internet Explorer 6.0
    • Internet Explorer リリース最新版
    • FireFox リリース最新版
    • Google Chrome リリース最新版
    • Safari リリース最新版
    • Opera リリース最新版

    これらで動作確認をすれば、世の中で使用されているブラウザの90%以上で正常に表示されるはずです。
    基本的に最新版ブラウザで表示されることを確認すればよいかと。

    なお「Internet Explorer 6.0」(以下、IE6)については、主に企業ユーザが利用されているPCのブラウザとして標準的に使用しているなど、未だにシェアが高いため、例外的にIE6での確認もする必要があります。
    おそらくxpのサポート完全終了となる2014年頃までは利用されるのかな、と。

    ただし企業などを対象としないコンテンツを制作する場合は、正直意識しなくてもよいかと。
    実際 Twitter の Web サイトをはじめとする幾つかの有名サイトが IE6 の配慮をあまりしない方向でコンテンツを提供してますし。
    何よりも、IE6 のためにわざわざ CSS や HTML、レイアウトを考慮するのは、時間もかかるし、正直なところ馬鹿馬鹿しい。
    いっそ IE6 用には、テキスト版コンテンツを提供するとかでも良いのかもしれない。。。

  • SEO

    • SEM/SEO講座(閉鎖)
  • Mozilla、FireFox

    インターネットブラウザ、メーラ、HTMLエディタ

  • IIS(Internet Information Server)

    FTPのPASV(パッシブ)モードについて

    • IISのFTP(パッシブモード)でデータ転送ポート番号を指定する方法(コンピュータ系blog)(リンク切れ)
    • IIS の FTP(File Transfer Protocol)サービスに関する情報(Microsoftサポートオンライン)(記事削除)
    • PassivePortRange の IIS の構成方法(Microsoftサポートオンライン)(記事削除)

    IISサーバにPerlをインストして動作させるツール

    • AWStatsのインストールサバコン)(閉鎖)

    アプリケーション型のアクセスログ解析ツール

    • WebLog 公式ページ(閉鎖)
  • ASP(Active Server Pages)について

    よく他人から「なんでASP使ってるの?」という質問(詰問?)をよく受けます。
    もちろん、昔からセキュリティ面を中心に色々と問題や不具合が多いという指摘は、私もよく知っています。

    では、なぜ使うのか。理由は2つあります。

    顧客が ASP ベースのアプリケーションを既に導入し、それが顧客のシステム部門で「板」についている

    今さら「Linix に替えろ」とか、「Perl とか PHP にしろ」なんて、所詮部外者が言える立場にありません。
    当然、顧客の会社内部では現時点までにかけた費用もあるし、顧客のシステム部門には ASP に特化した技術者を抱えている場合も多いと思います。
    それらを全部ではないにしろ、かなりの部分を放棄する可能性のあるような判断はそうそう下せるものではありません。

    もちろんセキュリティ面でのリスクがあると思いますが、会社というのはセキュリティ面だけの理由で新しいシステムに入れ替えるのは、利にかなう部分がかなり少ない以上、非常に難しいのです。

    じゃあ、「今後入れるシステムから別のシステムにする」という考え方もありますが、これだってかなり難しいです。
    要するに既存のシステムとは別のシステムを面倒を見なくてはならないわけですから、維持・保守に費用がかかります。

    こんなジレンマに陥っている会社は「ざら」です。
    もちろんそんな中で働く我々、外注システム屋は、顧客に対し助言や提案はします。
    でも結局のところ、顧客のニーズに合った形で製品やサービスを提供していくのが我々の職分だと思いますし、その限られた領域の中で色々なものを提供するのが、よいシステム屋だと思います。

    Windows に搭載されている標準 Web サービススクリプトだから

    もちろんASP(つか VBScript)は非常に手間のかかる言語であるのは解っていますが、DB などへの接続まわりや、BASP など手間のかかる部分に対して補完してくれるようなコンポーネントがあります。
    特性さえ理解していれば、不自由を感じることはあるかもしれませんが不可能な場面はそうそう出くわすことはないと思っています。(いざとなれば、Perl 呼べばいいんですしね。)

    それに Perl と同じで、比較的敷居が低い言語であれば、OS つまり Windows に近い言語を選ぶのは、極めて理にかなった話ではないでしょうか。

    もちろん、セキュリティ面で問題を抱えることが多い言語はありますが、セキュリティ面をよく考えてプログラミングをしなくてはならないのは、他の言語だって同じだと思います。
    Micorosot も、Session の利用非推奨など当初から方針を変えた箇所については提示していますし、セキュリティ対策も進んでいます。そんなに悪いサポートはしていないと思います。

    そんな中、個人的には ASP の技術系サイトが閉鎖されることが、とても残念です。
    確かに内容の陳腐化は避けられないかもしれませんが、別に間違った事を書いているわけではなかったと思うので、残しておいてもらっても良いのではないかと思ったりします。

    巷では ASP.NET が出始めています。ただ個人的には ASP はまだまだ使われると思います。
    ASP.NET には、開発パッケージの問題(効率的な開発には開発パッケージの製品購入が必要不可欠)と Windows Server 2003 の購入(ASP.NET を動かすには必要不可欠)が要求されます。
    そして何より ASP.NET そのものが、言語としての敷居が高いです。

    非常にスクリプトライクな ASP が Windows Server 2003 で動く以上、変更する理由がまったくないのも事実ですし。

    …なんだか非常に ASP を擁護するような書き方になってしまいましたが、別に Perl よりも勝っているとかそういう話ではありませんので。私だって Perl は使いますし。
    あくまで「いち技術者」として ASP の個人的な感想ですよ。

  • コンテンツ作成に使用したソフト

    「やっぱ、HTML はテキスト打ちでしょ」って方向け。最近はフリーの HTML テキストエディタも増えているので、なんともいえませんが、本業のプログラムも WZ を使っているためか、何故か乗り換えられない。
    秀丸よりはこっちのほうが好きです。印刷設定が細かくできるし(秀丸はアドイン入れないと駄目。)ショートカット設定も個人的にはこっちのほうがいいな。
    唯一不満なのは、予約語の色分け。
    ↑私の使っているのは、3.0 だからかな?
    …そろそろ最新版にアップグレードしようかと思ってます。

    最近たまに使います。ていうのも、客先から更新する場合、WZ を導入していない所が多いのと、客先 PC ソフトの導入制約など、都合上、秀丸エディタを使う場面が多いから。
    でも、どうもショートカットとかメニュー表示とかが WZ に慣れてしまったためか、使いにくいのは気のせいでしょうかね。
    ちなみに、全角スペースを入れた際に仮表示される「□」四角文字の角が丸いのも、どうも気に入らない。WZ は角はちゃんと角張ってる。(小さな事ですが。。。)

    • Dreamweaver(Macromedia)(Adobe に統合、閉鎖)

    このての HTML 視覚系開発ツールは、どうも馴染めない。。。
    使い方を覚えたり慣れるのに「訓練」が必要なのが大変。
    ただ、こういうソフト使い慣れたほうがいいのかもしれません。

    うーん。いつ何時に使ったのかが記憶にありません。
    でも、コンテンツに使用履歴が残っていました。。。
    ちなみに、コンテンツ閉鎖したのかな?リンク切れてます。

    WZ を知る以前に使ってたテキストエディタ。
    最近はあまり使っていないのですが、初心者で、HTML タグを覚えたい人は、これがお勧めのエディタ。