思案試行

私はCSSが苦手で、これまでBootstrapやBulmaに頼ってきました。最近、CSS (SASS)を書く機会がたくさんあり、自分でCSSを書いても思い通りのレイアウトにできるようになりました。

そこで、このブログからBulmaを取り除いてみました。

@media screen and (min-width: 1920px) {
   body {
     background-color: red;
   }
}

CSSのメディアクエリではこれまで、画面の解像度によって適用するブロックを変更するmin-widthやmax-widthだけを使っていました。

最近、初めて画面の縦横比によって適用するブロックを切り替えるaspect-rasioを使いました。

@media (min-aspect-ratio: 16 / 9) {
  body {
    background-color: red;
  }
}

16 / 9の部分が1.77778と計算結果が書かれていると、Firefox (Servo)では機能するのですが、Chrome (Blink)やSafari (Webkit)では機能しませんでした。

Nuxt3のドキュメントに従って生成しただけのプロジェクトに、$ npm run devで起動したNuxtのアプリケーションにブラウザでアクセスすると、そのブラウザが再読込を繰り返すという症状に遭遇しました。

原因は、私がWebSocketで通信できるようにポートを設定していないことでした。この問題にNuxtやDocker、Docker-Composeなどは直接の関係がありませんでした。ただし、Dockerを使わずにホストで直接Node.jsを動かしていたら、この問題には遭遇しなかったはずです。

もともと、このブログはPageSpeed Insightsのスコアが携帯電話で95点、デスクトップで99点でした。ブログのテンプレートを調整して、どちらも100点を達成しました。

携帯電話で100点

前回ブログを書いたのは2020年7月だったので、これは16か月ぶりのブログです。

ブログを再開しようと考え始めたとき、このブログをNikolaで作っていると思いこんでいました。実際はPelicanでした。Pelican -> Nikola -> Pelicanと移行していました。

この16か月の間に、HTMLやCSSの知識が増えたので、それを活かしてブログのテーマを整えようと思います。PageSpeed Insightsによると、現在このブログのトップページのスコアは携帯電話で95点、デスクトップで99点です。すでに高得点と言える点数になっていますが、ブログのテーマを整えて、これをさらに上げるるもりです。

Rustの練習のために中間に要素を挿入できるLinkedListを作りました。同様の例が見当たらなかったのでここに残します。

Pythonは自身を持って書けるのですが、Rustはまだそこに至りません。このLinkedListにも不備があると思います。

私は二枚のモニタのうち、4Kのものを横向きに、WQHDのものを縦向きで4Kのものの右側に置いています。Ubuntu 19.10までは問題なかったのですが、Ubuntuを20.04にしてから、4Kモニタに表示されているべきものがWQHDの方に表示されるという問題に頭を悩ませていました。

UbuntuのSettingsの中のDisplaysからモニタの設定をする代わりにNVIDIA X Server Settingsを使うことで解決できました。

2020年7月3日に開催されたPython Charity Talks in Japanにスピーカーとして参加しました。私の発表のタイトルは「next(ListはIteratorですか？)」です。

発表の動画を観ただけでは読み取れない内容を中心に記します。

私はLXCが好きなのですが、LXCの設定を丸暗記できません。LXCの使い方を一覧しているサイトが見当たらなかったので自分で書くことにしました。

ここで解説するのはLXCであって、LXDではありません。

Ubuntu 20.04をホストにしています。

私はつい最近まで、JavaScriptが送ったHTTPリクエスト(AjaxやFetch)に対するレスポンスでは、クッキーをセットできないと思い込んでいました。そのため、それ相当のことをするには、レスポンスでクッキーに入れたい値を受け取り、document.cookie = newCookie;のようにJavaScriptでセットしないといけないものだと思い込んでいました。そのためHttpOnlyディレクティブを使うことができないとも。

これは間違いで、JavaScriptからのHTTPリクエストに対するレスポンスがSet-Cookieヘッダーを持っていれば、自動的にブラウザにそれが保存されます。喜ばしいことに、このときHttpOnlyディレクティブを有効にすることもできます。

ただしJavaScriptでCookieをセットするときに、HttpOnlyディレクティブを使えないのは真です。HttpOnlyディレクティブつきのCookieはJavaScriptから読めないだけではなく書くこともできません。

私はASGI(Asynchronous Server Gateway Interface)はPEPになっていると思いこんでいたのですが、先程ASGIのPEPを読もうとPEPの索引にアクセスし、PEPになっていないことを知りました。そこでASGIのPEPについての現状を調べたので記事を書くことにしました。この記事に書いてあることは私が独自に調べたもので、ASGIに詳しい人に聞いたわけではありません。そのため私の理解不足で間違いを含んでいる可能性が非常に高いです。

私はPyramidが好きで、WebSocketなどを使いたいと思ったときのために、PyramidにもASGIに対応して欲しいと思っていました。この需要は私や私の周りの限られた範囲のものではないはずです。それにも関わらずPyramidが積極的なASGIのサポートを見せないのはなぜかと不思議に思っていましたが、PEPになっていないのであれば仕方のないことと納得しました。

ASGIの第一人者であるAndrewさんによる、ASGIがPEPになっていないことについての説明があります。

It's worth noting that I was discouraged from making ASGI a PEP by several Python core developers, which is why I have not been pursuing that process any further. I'm not sure I share this view, so I may come back to it in the future, but there's a reason it's not in the process right now.
何人かのPythonのコアデベロッパーからASGIをPEPにすることを思いとどまらされたのは注目に値します。この見解が共有されているか分からないので、将来的にはPEP化に向けて戻ってくるかもしれませんが、今はその作業は止まっています。

この発言は2020年1月28日のものです。元の投稿はこちらです。

この記事中の引用部にある日本語は、私が元の英語を翻訳したものです。

私はSpacemacsを使っています。いつからか定かではないのですが、Spacemacsをサーバとしたemacsclientが、内容のある新しいファイルを一度目では開けないという問題に困っていました。これを先程解消することができました。

原因はspell-checkingレイヤーのspell-checking-enable-auto-dictionaryでした。

(spell-checking :variables spell-checking-enable-auto-dictionary t)

spell-checking-enable-auto-dictionaryを有効にしないことで解消しました。

このブログは元々Pelican製だったものを、4月の最初にNikola製に移行しました。まだ一週間経っていませんが、Pelicanに戻しました。

PelicanもNikolaもPython製の静的ブログジェネレータです。

まず初めに、はっきりとさせておきたいことがあります。この問題の直接の原因がhueyやpeeweeではないということです。

huey.contrib.sql_huey.SqlHueyは引数databaseにDSNを取ります。DSNとは{schema}://{username}:{password}@{host}:{port}/{database}のような文字列です。具体例を上げるとhuey.contrib.sql_huey.SqlHuey(database='postgresql://postgres:password@localhost:5432/mydatabase')です。DSNはURIと同じ形式です。

このパスワードの部分がpass?wordのように?を含んでいると、パスワードがそこで切られてしまい、データベースに接続できなくなります。

パスワードにと言っていますが、ユーザ名などにあったとしても同じ問題を引き起こします。ただパスワード以外に問題を起こす一部の記号を使うことは滅多にないことでしょう。

CeleryはSQLAlchemyを通してRDBMSをBrokerとして利用できると記憶していたのですが、Celery 4.0からはSQLAlchemyをBrokerとしてのサポートは終了していました。知識として持っていましたが、実際にCeleryのBrokerにRDBMSを使ったことはありませんでした。

今開発中のサービスではCeleryをTaskQueueとcronの両方の用途で使おうと考えていたので、Celeryの代わりにPostgreSQLをBrokerを使えるライブラリか、CeleryのためにRabbitMQやRedisといったCeleryがBrokerとして対応しているミドルウェアを用意しなければならなくなりました。

結果、hueyを採用することにしました。