夕立進行会報

これはmetaタグのviewportの設定に関するメモである。ビューポートの設定は癖があり思い通りにならないので、検証した結果を記載しておく。 モバイルブラウザでのみ有効 ビューポートはモニタの仮想解像度 device-widthはモニタの推奨値 コンテンツがはみ出すとビューポートは広がる initial-scaleの基準はdevice-width initial-scaleがwidthを上回るとビューポートは広がる ビューポートをコントロールしたいとき モバイルブラウザでのみ有効 viewportの設定はスマートフォンなどモバイル版のブラウザでのみ有効となり、PCブラウザでは無視される。 これは長らくドットバイドット表示でウィンドウサイズも可変であったPCに対し、高解像度モニタとズームを用いるスマートフォンでの表示を想定した機能であるため。 ただしこれらは歴史的経緯のためタブレットや2in1PC、および4Kモニタの存在など、今後どうなるかは定かではない。 ビューポートはモニタの仮想解像度 スマートフォンは5インチ幅に1000ピクセル以上などの大きな画素数を持っている。このサイズ感でPCモニタと同じように等倍表示すると、コンテンツが非常に小さく表示されてしまう。 そこで実際の解像度とは別に仮想解像度を設定して、あたかもそのサイズであるかのように調整して描画する。このサイズがビューポートである。 例を挙げると、幅100pxの画像を表示する場合、ビューポートの幅が200であれば画面の1/2、400であれば画面の1/4程度の大きさで表示される。 device-widthはモニタの推奨値 ビューポートがいくらだと見やすいかは画面の物理的なサイズによる。なので機器ごとに「このサイズで表示するといい感じだよ」という値が設定されている。それがdevice-widthである。 webページのユーザビリティ指標でdevice-widthの設定が推奨されるのは、つまりメーカーの想定する使いやすいサイズに合わせろということだ。 コンテンツがはみ出すとビューポートは広がる ビューポートを設定したのにコンテンツが小さく表示されてしまう（ピンチインで縮小できてしまう）場合がある。それはコンテンツサイズがビューポートより大きいからである。 コンテンツの横幅が設定したwidthをはみ出していると、...

無料で提供されている認証局のLet's Encryptから、Webサーバ用のSSL証明書を取得・設定する。Let's EncryptにはCertbotという公式のクライアントがあるが、今回はOSSで公開されているLEGOを使ってみる。 OS：Ubuntu 20.04 Webサーバ：nginx 1.18.0 LEGO：4.5.3 ダウンロード github （ https://github.com/go-acme/lego ）のReleasesからLEGOの実行ファイルをダウンロードする。 ダウンロードしたのはlinux_amd64。解凍して適当なパスに配置する（今回は /usr/local/bin/に配置）。 証明書の取得 コマンドラインでlegoを実行して証明書を取得する。この際ドメインの所有者確認が行われるが、これには二つの方法がありコマンドパラメータが異なる。 なお以降のサンプルではパラメータを下記にしているので、適時読み替えて欲しい。 ドメイン名：example.com 管理者アドレス：mail@example.com 出力パス：/opt/lego/ 方法１）DNSにtxtレコードを登録する場合 DNSにtxtレコードを設定して所有者確認を行う方法。Webサーバ自体を弄れない場合も可能だが、証明書の更新時にはまた別のtxtレコードを登録する必要がある。 sudo lego --dns manual --domains example.com --email mail@example.com --path /opt/lego/ run コマンドを実行するとtxtレコードのキーと値が表示される。コンソールはそのままにしてDNSサーバにtxtレコードを登録する。その後コマンドラインを続行するとLet's EncryptからDNSへレコードへ確認が行われる。 方法２）Webサイトにファイルを置く場合 Webサイトに置いたファイルで所有者確認を行う方法。既にWebサーバがhttpアクセスできる状態である必要がある。 sudo lego --accept-tos --domains example.com --email mail@example.com --path /opt/lego/ --http --http.webroot /op...

chrome系のブラウザでWebページをホームへインストールするための基準が少し厳しくなる。service workerのfetchイベントが空だと現在以下の警告が出る。 Site cannot be installed: Page does not work offline. Starting in Chrome 93, the installability criteria is changing, and this site will not be installable. See https://goo.gle/improved-pwa-offline-detection for more information. https://goo.gle/improved-pwa-offline-detection オフラインに対応していなければ、2021年8月のChrome93からはインストールがブロックされるとのこと。とはいえ完全に動作する必要はなくフォールバックページなどが提供されればいいそうだ。 サーバ通信前提のWebページをオフライン対応するのは現実的ではないので、その方向で回避してみることにする。（オンライン前提のWebページをインストール可能にする必要があるのかというのもあるが、そこは色々な事情があるのだ） 対応 serviceworker.js var _cashVersion = "cashe0.0.0.1" var _offlinePage = '/offline.html' self.addEventListener("install", function(event) { console.log("service worker call install.", event) event.waitUntil( caches.open(_cashVersion) .then(function (cache) { cache.add(_offlinePage); }) ); }) self.addEventListener('fetch...

Windowsでは予めURLスキームを設定しておくことで、Webページ（ブラウザ）からアプリケーションを起動することができる。イントラネット業務アプリの世界で稀に利用されるようなものだったが、近ごろオンラインビデオ会議のクライアントを立ち上げるのによく目にするようになった。 クライアント設定 事前にクライアントとなるWindowsのレジストリに、スキーム名と対応する動作を登録する必要がある。スキーム名を「xxxx」とした場合、レジストリに以下を設定する。 HKEY_CLASSES_ROOT\xxxx 名前 種類 データ (既定) REG_SZ URL:xxx Protocol URL Protocol REG_SZ HKEY_CLASSES_ROOT\xxxx\shell\open\command 名前 種類 データ (既定) REG_SZ example.exe "%1" example.exeの部分に実行したいアプリをコマンドライン形式で記述する。なお起動するアプリは事前にインストールされている必要がある。 Webページからの呼び出し WebページからそのスキームのURLを開かせる。 <a href='xxxx://hogehoge'>start application</a> 開く方法はリンクでもjavascriptでもよい。ただブラウザにブランクページが表示されるので、iframeを設置してその中で開くとよいかもしれない。hogehogeの部分はなんでもよいが、スキームのみ（xxxx://）ではだめなようだ。 URLを開くとブラウザから確認のダイアログが表示される。実行を許可するとレジストリのコマンドが実行される。 情報の受け渡し Webページからアプリへ コマンドライン引数にURLが渡されるので、文字情報であればURLのパスやクエリ式でアプリに情報を渡すことができる。 location.href = "xxxx://start?id=hoge&type=1" ただし通常のURLと同様にURLアンセーフな文字はbase64URLエンコ...

このようなDOM操作でモーダルウィンドウ風の要素を作るときのフォーカス制御の話。 モーダルウィンドウの表示時は、背景を覆うようにスクリーン要素を置いてクリックできないようにすることが多い。しかし背景に<button>や<input>がある場合は、キーボードのtabでフォーカスして操作ができてしまう。それを防ぐ。 focusinイベントをキャッチしてフォーカス制御する フォーカスのイベントにはfocus/blurの他にfocusin/focusoutイベントがある。 focus/blurイベントはバブリング（子要素のイベントが親要素に伝播）しないが、focusin/focusoutイベントはバブリングし、自分自身がフォーカスされない要素でも発生する。 次のようにbodyと#screenにfocusinイベントを設定する。 var isShowDialog = false var focusOnDialog = false document.body.addEventListener("focusin", function(){ //モーダルウィンドウ表示中で、 //フォーカスを取得したのがモーダル上でない場合フォーカスを外す。 if(isShowDialog && !focusOnDialog){ document.activeElement.blur() } focusOnDialog = false; }) document.getEmementById("screen").addEventListener("focusin", function(){ //モーダル上の要素がフォーカスされた focusOnDialog = true; }) //モーダルウィンドウを表示する関数 function showDialog(){ // ～ // 表示の処理 // ～ document.activeElement.blur() isShowDialog = true } モーダルウィンドウの表示中は、フォーカス移動をbodyのfocusinイベント...

GoogleのFirebaseというクラウドサービスには無料プランがあって、ホスティングサービスが使える。もちろん広告とかつかないしHTTPSもデフォルトで利用できる。ちなみに認証サービスやストレージも無料割り当て分があるようだ。恐るべし巨大プラットフォーマー。 とりあえずホスティングを使ってみたのでWebサイトを公開するまでのメモ。基本的には公式ドキュメントがあるので、最低限必要なことを知るオーバービュー的なものとして残す。 Firebaseコンソールでの操作 Firebaseの利用を開始する Googleアカウントは既に持っているものとする。Firebaseコンソール（ https://console.firebase.google.com ）へアクセスしてFirebaseを利用開始する。ボタン一つ。 Firebaseプロジェクトを作る コンソールのメイン画面からプロジェクトを追加する。ちなみにここで付けたプロジェクト名がWEBサイトのデフォルトURLに使われる。一意な名前じゃなかった場合どうなるんだろう。 ローカルでの操作 Firebaseへコンテンツをデプロイするには、ローカルPCに作業環境を作る必要がある。なおこの時のローカル環境はWindows10。 Node.jsのインストール Node.jsのサイトからダウンロードしてきてインストールする。一緒にパッケージマネージャのnmpがインストールされる。 Firebase CLIをインストール FirebaseのクライアントであるCLIをインストールする。コマンドプロンプトからnmpを実行。 >npm install -g firebase-tools インストール出来たら、FirebaseCLIにGoogleアカウントを覚えさせる。 >firebase login プロジェクト用ディレクトリを作る プロジェクトのローカル作業用のディレクトリを作成する。適当にフォルダを作ってそこでコマンドを実行する。 >firebase init なんか色々と聞かれる [セットアップする機能] hostingだけ選択 [クラウド側プロジェクトの選択] アカウントのプロジェクト一覧が出てくるので、さっきコンソールで作成したプロジェクトを選ぶ。 [公開ルートディレクトリの名称] デフォルトはpublic。...

小ネタ。IISでは接続元のIPアドレスによってアクセス制限を設定したりできる。説明を見ると大抵フォルダー単位で設定をしているが、それをファイル単位で設定する方法。 IISマネージャで 通常はこのようにフォルダまでしか表示されていないが 上にあるアドレスバーでファイル名までパスを入力してエンターを押すと そのファイルだけツリーに表示される。これでフォルダにするのと同じようにファイルに設定を加えることができる。変な動作。 configファイル 結局のところIISマネージャで設定したものは.configファイルに書かれる。Default Web Siteの配下なら"C:\inetpub\temp\appPools\DefaultAppPool\DefaultAppPool.config"など。アクセス制限は以下のような記述。 <location path="Default Web Site/ARFusen/Contents"> <system.webServer> <security> <ipSecurity> <add ipAddress="192.168.1.1" allowed="false" /> </ipSecurity> </security> </system.webServer> </location> このpath属性にファイルのパスを入れれば別に普通にファイルでも動作する。まあでもIISマネージャーがインストールされている場合は、上書きされたりしても嫌なのでGUIで設定できたほうがいいよね。 以上 設計としてはフォルダで分けるほうが妥当なんだけど、今回は既に稼働済みのシステムでURLを変えずに特定ページのみ制限したかったのでやってみた。

前回マークダウンで書いた文書を閲覧するためにJavaScriptでパーサを作成した。イメージしてたのは以下のように、マークダウン文書は別ファイルに記述しておき、ビュー用のページからajax的に取得してきて表示するという利用形態。 ローカルファイル取得できない問題 しかし実際に作ってから、ローカル実行（file://～）ではブラウザのセキュリティ制約により外部ファイルを取ってこれないことに気づいた。まあ確かにそれができると、開いただけでPC内のファイルをアップロードし始めるhtmlファイルとか作れてしまう。 少量の文書ならスクリプトもマークダウンも一つのファイルにまとめるのもありだが、そうでなければ内容とビューは基本的に分けたい。 試した方法 XMLHttpRequest 通常のWebならこれで取ってくる。しかし当然Webサーバが無いので不可。一部ブラウザではhttpリクエストの代わりにファイルを読み込んでくれるらしいが、セキュリティ回避などそれぞれのブラウザで必要な対応や操作が変わってくる。 ActiveX(FileSystemObject) 厳密には試していない。昔やったことはある。ActiveXなのでIEでしか動かない。 script src="～" ローカルファイルでも通常の参照リンクや画像表示は動く。scriptタグの外部参照で読み込んだスクリプトの中身を取得しようかと思ったが、そもそもそんなことできなかった。 iframe経由 対象ファイルをインラインフレームに表示して、その中身を"contentWindow.document"で取得する。表示はされるがスクリプトからはクロスドメイン扱いとなり弾かれた。ファイルのパスとか関係ない。 結論 無理。まあ仮にできてもセキュリティホールだから塞がれてしかるべき方法だな。 対処方法 完全分離はあきらめて、できるだけ文書側に処理を書かずに内容を受け渡す方法として、postMessageを使ってみる。 postMessage もとは異なるドメインのWebページ間でデータを受け渡すための仕組み。A,BふたつのWebページを開いて、AB間でイベントコールができる。 送り手、受け手の両方が対応していてかつ受...

2020/4/23 パーサを修正し生成コードが変わりました。変更内容は こちら。 JavaScriptでMarkdownのパーサを書いてみた。 Markdownはブログ記事みたいな感じの文書をお手軽に記述するための記法で、主にhtmlに変換される。github等のサービスで採用されてるためか、最近プログラマにのみ認知度が高い。 動機 イマドキは仕様書なんかもWord文書ではなくMarkdownで書いたりすることもあると聞いた。Markdownでドキュメントを書いた場合のメリットは以下のような感じか 手っ取り早く書ける テキストエディタで編集できる gitでバージョン管理できる github等のWebサービス上に載せられる 参照ページ等へリンクができる 逆にパッと思いつくデメリットはというと レイアウトに融通が利かない 図などをその場で編集できない 単一ファイルにならない（画像など） 印刷が前提になっていない 結構デメリットが強い。ドキュメントがすべてこれで済むのはかなり限定的かと思う。まあでも今はみんなWebの表示にも慣れてるし、マニュアルやリファレンスなんかにはいいかもしれない。 いやそれ以前に 読めないんじゃ～。mdファイルを見てVisual Studio Code（Markdownをプレビューできる）とかに突っ込んでくれるのなんてプログラマだけなんじゃ～。もしくはWebサービスに載せるの前提か。 それじゃ用途が限られすぎるので、ローカルファイルの状態でwebブラウザで開いて読めるようにパーサを作るよ。まあ世の中には既に高性能なライブラリがあるんだけど、再配布のライセンス問題回避なんかも含めて車輪の再開発だ。 ソースコード githubに置いてあるのでそっちを見てね。 MDParser 実行結果 一個ずつ書いてくのも面倒くさいのでまとめて。 Markdown 以下のようなMarkdownを書いたとする。 # 表題１ ## 表題２ ### 表題3 javascriptでマークダウンパーサを作成してみました。マニュアルなどを気軽に記述できないかな。 これはサンプルです。 ここは通常の文章です。 1...

前回 [バージョン情報] Ubuntu Server 18.04.1 LTS .NET Core 2.1 Nginx 1.14.0 Windows10（クライアント） Visual Studio 2017 Community（開発環境） みんな知ってるWebシステムの三層構造。前回はkestrelのホストしているURLに直接リクエストを投げたが、区分としてはASPはアプリケーションサーバだろう。なのでその前段階にWebサーバを構築する。 Webサーバには最近のスタンダードらしいNginxを使ってみる。MSの公式でもNginxを使用する方法が書いてある( リンク )ので、よくある構成かと思われる。 Nginxのインストール Ubuntuの公式リポジトリに含まれているので、apt installだけでダウンロードからインストールまでできてしまう。 $sudo apt install nginx インストールしたらnginxサービスを起動する。 $sudo systemctl start nginx コンソールには何も出てこないが、curlやブラウザでアクセスすると「Welcome to nginx!」のHTMLページが返ってくる。 補足：systemctl start nginx の代わりに service nginx start でも起動する。後者はサービスのみに対応したスクリプトコマンドで、実行結果は基本的に同じようだ。ただsystemctlの方が汎用的みたいなのでこちらに慣れておく。 リバースプロキシの設定 Nginxの既定のサイトの構成ファイル[/etc/nginx/sites-available/default]に転送設定を加える。 location / { # First attempt to serve request as file, then # as directory, then fall back to displaying a 404. try_files $uri $uri/ =404; } location /api/ { proxy_pass http://localhost:5000; ...

前回 今回はASP.NET Coreのプロジェクトを作ってUbuntuで動かすまでのメモ。 [バージョン情報] Ubuntu Server 18.04.1 LTS .NET Core 2.1 Windows10（クライアント） Visual Studio 2017 Community（開発環境） プロジェクトの作成 Visual StudioでASP.NET Coreのプロジェクトを新規作成する。 テンプレートにはAPIを選択。Webアプリケーションとかを選ぶとビュー生成用のコードなどが配備される。でもサーバサイドはAPIの提供に専念する方がきれいだと思う。（.NET FrameworkのWeb APIテンプレートはViewに相当する参照が沢山含まれれて不便だった） 新規プロジェクトにはAPIのサンプルコードとしてValuesController.csが含まれている。 namespace WebApplication1.Controllers { [Route("api/[controller]")] [ApiController] public class ValuesController : ControllerBase { // GET api/values [HttpGet] public ActionResult<IEnumerable<string>> Get() { return new string[] { "value1", "value2" }; } ～省略～ } } この〇〇ControllerクラスがAPIの処理を記述する部分になる。ざっくり言うと、クラスやメソッドにルーティングの属性を付けることで、リクエストに対して呼び出されるメソッドを指定している。この場合"http://xxxx/api/Values/"にGETリクエストすると、サーバではGetメソッドが呼ばれて戻り値の["value1", "value2"...

表題の通り。ASP.NETがLinux上で動くと聞いて、Windows系のプログラマでも手が出そうだと思い試してみることに。 まずはASPの前に.NET Coreが動く環境を作るところまで。 [バージョン情報] Ubuntu Server 18.04.1 LTS .NET Core 2.1 Windows10（クライアント） Visual Studio 2017 Community（開発環境） Ubuntu Serverの準備 最終的にはVPS等を使うつもりだけど、まずはVirtualBox上で構築してみる。 インストールメディアのisoイメージを公式ページ( https://www.ubuntu.com/ )からダウンロード。VirtualBoxで新規VMを作り、光学ドライブにisoファイルをマウントしてインストール。なお18.04にはまだ日本語は無いそうで。操作はともかくテキストファイルの中身も読めないのは不都合がありそう。 インストールしたらネットワークの設定だけする。VMに割り当てるのは、外部通信用のNATと、ホストからアクセスする用のホストオンリーアダプターの2つ。 NAT側は自動割り当て、ホストオンリーアダプター側はホストマシンの[VirtualBox Host-Only Network]アダプタと同じネットワークになるように固定IPアドレスを割り振る。ちなみにUbuntu 18.04のネットワークの設定ファイルは[/etc/network/interfaces]ではなく[/etc/netplan/50-cloud-init.yaml]。 # This file is generated from information provided by # the datasource. Changes to it will not persist across an instance. # To disable cloud-init's network configuration capabilities, write a file # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following: # networ...