WebTransportのサンプルを触ってみる。

「Google Chrome 97」のオリジントライアルに追加されたWebTransportを早速触ってみたいと思います。

WebTransportとは・・・。

WebTransport is a protocol framework that enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport.

https://chromestatus.com/feature/4854144902889472

WebTransportは、HTTP/3プロトコルを双方向トランスポートとして使用するWebAPIです。これは、WebクライアントとHTTP/3サーバー間の双方向通信を目的としています。データグラムAPIを介した信頼性の低いデータ送信と、ストリームAPIを介した信頼性の高いデータ送信の両方をサポートします。

https://web.dev/webtransport/

なんだかよく分かりませんが、HTTP/3を使用したすごい転送規格です。
双方向ですし、multiplexed-transport?かっこいいですね。

きっとブラウザOSが更に進化していくとか、ブラウザ上でゲームがネイティブアプリかのように動作するだとか、もうブラウザの意味が変わる時代が来るのかもしれません。

内容自体は難解かつ複雑ですが、今回はサンプルを触るだけですので何も考えずにやってみようと思います。

サーバー準備。

「WebTransportの実験」によると、現時点では、WebTransportはまだ公開されていません。
「試してみましょう」の項目にもありますが、HTTP/3サーバーをローカルで準備して起動する必要があるとのこと。

JavaScriptクライアントは、以下のURLに用意してくれています。
https://googlechrome.github.io/samples/webtransport/client.html

HTTP/3サーバーとは?
となったところで、GoogleChrome/samplesのgithubのスクリプトの中にコメントで、

An example WebTransport over HTTP/3 server based on the aioquic library. 

とありました。

aioquic。

aioquicを検索してみるとすぐ出てきたので、githubからcloneしてきます。
https://github.com/aiortc/aioquic/

導入は README の通りに進めます。

親切なことに、ブラウザの起動方法やオプションの説明、test/ ディレクトリの下に .pem ファイルまで用意されています。(独自証明書の場合のハッシュの生成コマンドもあります。)

Chromeもこれぐらいやって欲しい

また、aioquic/exapmplesにHTTP/3のテスト用サンプルが置いてあります。
試してみたところ、サーバー起動とHTTP/3のサンプルスクリプトは動作したのですが、クライアントからWebTransportの接続が上手くいきませんでした。深追いはしてませんが、バージョンアップで何か変わったのかもしれません。

HTTP/3のサンプル実行 – Ubuntu

ということで、元のGoogleChrome/samplesに戻ります。

Chromiumからアクセス。

cloneしてきたGoogleChome/samplesからサーバー用スクリプトを起動します。

mv samples/webtransport/webtransport_server.py aioquic/
python3 webtransport_server.py tests/ssl_cert.pem tests/ssl_key.pem 

aioquicの説明の通り、Chromiumをコマンドから起動します。

chromium --enable-experimental-web-platform-features --ignore-certificate-errors-spki-list=BSQJ0jkQ7wwhR7KvPZ+DSNk2XTZ/ MS6xCbo9qu++VdQ= --origin-to-force-quic-on=localhost:4433 https://localhost:4433/

上の方で紹介したJavaScriptクライアントを開きます。
https://googlechrome.github.io/samples/webtransport/client.html

画面にある「Connect」を押し、以下のように表示されると接続成功です。

Initiating connection...
Connection ready.
Datagram writer ready.
Datagram reader ready.

お疲れさまでした。

[Solr]ロギングについてのTips

動的にログレベルを変更する

管理画面から

Solrの管理画面 Logging → Level で Solr 稼働中にログレベルを変更できます。
特定のクラスのログ出力だけを変更することもできますし、rootを変更することで全体を変更することもできます。

APIで

以下のようにAPIを呼び出すことでログレベルを変更できます。

curl -s http://localhost:8983/solr/admin/info/logging --data-binary "set=root:WARN"

設定ファイルの場所を指定する

環境変数 LOG4J_PROPS で log4j2.xml の場所を指定します。

LOG4J_PROPS=/var/solr/log4j2.xml

ログの出力先を指定する

環境変数 SOLR_LOGS_DIR でログの出力先を指定します。

SOLR_LOGS_DIR=/var/solr/logs

日付ベースのログローテーションにする

log4j2.xml の MailLogFile の設定を以下のように変更します。

<RollingRandomAccessFile
    name="MainLogFile"
    fileName="${sys:solr.log.dir}/solr.log"
    filePattern="${sys:solr.log.dir}/solr.log.%d{yyyyMMdd}" >
  <PatternLayout>
    <Pattern>
      %maxLen{%d{yyyy-MM-dd HH:mm:ss.SSS} %-5p (%t) [%X{collection} %X{shard} %X{replica} %X{core}] %c{1.} %m%notEmpty{\
 =>%ex{short}}}{10240}%n
    </Pattern>
  </PatternLayout>
  <Policies>
    <TimeBasedTriggeringPolicy interval="1"/>
  </Policies>
  <DefaultRolloverStrategy max="10"/>
</RollingRandomAccessFile>

TimeBasedTriggeringPolicy の interval=1 が1日単位という意味になるのは、filePattern に含まれる最小の単位が日だからです。filePattern に HH が含まれていれば interval=1 は1時間単位の意味になり、 mm が含まれていれば1分単位になります。

log4j2をアップデートする

Solr の配布物に含まれる log4j2 関連の jar ファイルは以下の通りです。

  • server/lib/ext/log4j-slf4j-impl-2.14.1.jar
  • server/lib/ext/log4j-layout-template-json-2.14.1.jar
  • server/lib/ext/log4j-core-2.14.1.jar
  • server/lib/ext/log4j-1.2-api-2.14.1.jar
  • server/lib/ext/log4j-api-2.14.1.jar
  • server/lib/ext/log4j-web-2.14.1.jar

log4j2 をアップデートするときはこれらのファイルを置き換えます。

prometheus-exporter を利用している場合は以下のファイルの置き換えも必要です。

  • contrib/prometheus-exporter/lib/log4j-slf4j-impl-2.14.1.jar
  • contrib/prometheus-exporter/lib/log4j-core-2.14.1.jar
  • contrib/prometheus-exporter/lib/log4j-api-2.14.1.jar

npm-scriptsでSCSSをコンパイルしてみよう!

sassをコンパイルする方法として、gulpを使っていますが、npm-scriptsが主流になってきています。npm-scriptsを使うメリットとして、記述がシンプルでバージョン依存が少なく共有がしやすいことが挙げられます。

今回はnpm-scriptsを使ってSass/Scssのコンパイルする方法についてまとめてみようと思います。

準備とSCSSをコンパイル

まずは任意のディレクトリにサンプルとして「sass_test」ディレクトリを作成し移動します。

mkdir sass_test
cd sass_test

今回使用するsassファイルを作成します。
ディレクトリは下記を想定しています。

sass_test
└resources
 └sass
  └style.scss
└dist
 └sass
  └style.css

「sass_test」の中でpackage.jsonを生成します。
「sass_test」に移動して、ターミナルで下記のコマンドを入力すると「package.json」が生成されます。
(質問は全てenterで大丈夫です)

npm init

sassのコンパイルとして、「Sass」をインストールします。

npm install sass --save-dev

package.jsonの「scripts」欄を次のように変更します。

  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },

  "scripts": {
    "sass": "sass resources/sass/:dist/css/ --no-source-map --watch"
  },

sassをコンパイルするために下記を「sass_test」の階層で実行します。

npm run sass

「dist/css/」ディレクトリに「style.css」が生成されたと思います。
(終了するには[Ctrl + C]を押します。)
sassをコンパイルするのみならこれだけです。

自動でベンダープレフィックスを付与

自動でベンダープレフィックスを付与するために「autoprefixer」をインストールします。
合わせて「postcss」「postcss-cli」をインストールします。

npm install postcss postcss-cli autoprefixer --save-dev

複数のnpm-scriptsを実行するために「npm-run-all」をインストールします。

npm install npm-run-all --save-dev

ファイル変更の監視をするために「watch」をインストールします。

npm install watch --save-dev

package.jsonの「scripts」欄を次のように変更します。

  "scripts": {
    "all": "run-p watch",
    "watch": "watch 'run-s scss postcss' ./resources/sass",
    "scss": "sass resources/sass/:dist/css/ --no-source-map",
    "postcss": "postcss dist/css/style.css -o dist/css/style.css"
  },

pakcage.jsonと同じ階層に「postcss.config.js」を作成します。

module.exports = {
  plugins: [
    require('autoprefixer')()
  ]
}

そしてpakcage.jsonと同じ階層に「.browserslistrc」を作成します。
ブラウザリストはここで調整します。

last 2 versions
ie >= 11
Android >= 7

それではコンパイルしてみましょう。
「resources/sass/style.scss」に下記を記載します。

a{
  transition: 0.3s all;
  color: red;
  
  p{
    color: green;
  }
}

次にターミナルでpackage.jsonと同じ階層で下記を実行します。

npm run all

そうすると、「dist/css/style.css」に下記が出力されています。

a {
  -webkit-transition: 0.3s all;
  transition: 0.3s all;
  color: red;
}
a p {
  color: green;
}

無事にsassがベンダープレフィックスがついてコンパイルされていることが確認できました。
(終了するには[Ctrl + C]を押します。)

以上がnpm-scriptsを使ったsassのコンパイル方法をです。
読んでいただいた方の参考になればと思います!

「RubyWorld Conference 2022」に協賛させていただきます

「RubyWorld Conference 2022」に、Goldスポンサーとして協賛させていただきます。

<期間>
2022年11月10日(木)、11日(金)
<会場>
島根県立産業交流会館「くにびきメッセ」
<主催>
RubyWorld Conference開催実行委員会
https://2022.rubyworld-conf.org/ja/

文章の書き方の基本について考えた

こんにちは、デザイナーのはなです。

弊社でデザイナーとして働いていると、何かの説明文を考えることが多くあります。

お客様にわかりやすい表現ってなんだろう…?とその業務のたびに考えます。

私は文章を読むことにも書くことにも、あまり苦手意識を持っていません。

最近文章の書き方について後輩に説明することがあり、その際、実際に自分がノリでやっていることを言葉で説明することの難しさを痛感しました。

なので、「わかりすい文章」というものについての自分の解釈をメモ代わりとして残しておきたいと思います。

骨が何か考える

文章は基本的に「誰」が「何をするか」がはっきりしていれば意味が通らないということはありません。

主語・述語というやつです。

学校の国語の授業と違って、仕事で読んだり書いたりする文章は、主語が省略されていることも多いです。

ちゃんと書かれた文章なら、主語が省略されていても誰がした行動についての文なのかが自然に理解できるはずです。

誰が何をしたのか、誰が何をすべきなのかが一発でわからないなら、それは上手な文章ではないと私は考えています。

主語も述語も書いているのに意味が通りにくいとしたら、余計な要素が邪魔をしている可能性があります。

入れたい要素を最初から全部入れようとすると失敗するので、まずは骨である「誰が何をしたのか」を組み立て、他の要素は補助であるという意識で文章を作るといいと思います。

骨を組み立てるためには、まず書き手である自分が「誰目線の文なのか」がきちんとわかっていることが大切だと思います。

誤解が無い文を心がける

私が文を書く際に心がけているスローガンが、「5歳に見せてもわかる文」です。

読み手が不特定多数のユーザーの場合、読み手の読解力というものに期待をしてはいけないと思っています。

馬鹿にしているというわけではなく、その人の経験や境遇、精神状態が読解力にダイレクトに響いてくるわけです。

読んだ人の100%が誤解をしない文を書くというのは不可能ですが、違った解釈をする人間をできる限り0に近づけることは頑張り次第で可能です。

「5歳に見せてもわかる文」というスローガンは、専門的なことは何も知らず理解力もあまりなく、難しくて長い文を読んだらすぐに飽きてしまう五歳の子供に見せたときにちゃんと最後まで読んでくれるかという、自分の文に対する問いかけのことです。

別の解釈の余地がある文を読んだ頭の中の五歳児は、多分私の想定の動きをしてくれないでしょう。

私が文句を言うと、だってそう書いてあったもん!!と泣きながら駄々をこねると思います。

自分が書いた文にはそういうクレームの余地が一ミリもないかと考えることが大切だと私は考えています。

音読してみる

実際に音読をしてみると、黙読だけではわからなかった違和感に気が付きます。

ただ文字をなぞるように読むのではなく、文を塊として、人に話すようなテンションで読むのがいいと思います。

短い文なら覚えてしまってから空で口に出してみるとよいです。

オフィスで思いっきり音読をすれば結構目立ってしまいますが、脳内で音読しながら口パクするだけならまぁ大丈夫でしょう。

私は完全テレワークなので、このブログを書いている今も、思い切り音読しながら書いています。

悪い文章を反面教師にする

良い文章は、読んだときに引っかかりがないので、無意識のうちにスルッと読めてしまいます。

しかし、読みにくい・意味がよくわからない他人が書いた文章は、ん…?と引っ掛かりを覚えたり、どういう意味なのか他人に聞かなければなかったりします。

そういう文に出会ったときに、何が余計で何が足りないのか、じっくり読み返して添削をしてみるといいと思います。

これが誰目線の話なのかわからないからなのか〜とか、この表現が邪魔なんだな〜とか、自分が書いた文よりも気がつくところが多くあると思います。

それをメモっておいて自分が書くときにも気をつけるようにするだけで、大きく違いが出ると思います。

最後に

文章の練習は、「人の振り見て我がふり直せ」が一番いいです。

一回で理解しきれない文章に出会ってしまった場合、自分の読解力が低いのではなく、十中八九相手の書き方せいだと悪いと私は思っています。

半分逆ギレですが、その時に、じゃあどんな文なら自分でも一発でわかるんだろう?と思考することが文章を書く能力の向上につながっていると思います。

日本人というのはは特に、「違和感のある日本語」に不信感を覚えやすい国民だと思います。

ふわっとした日本語を見て、このお店ほんとに大丈夫かなぁ…?と思ってしまった経験を持っているのは私だけではないはずです。

文章を、正しく誤解なく伝えることで、お客様からの信頼感を得たり、無駄なクレームを防いだりすることができます。

たかが言葉ですが、されど言葉という気持ちで向き合うのがいいと私は思います。