yuw27b’s blog

技術メモと雑記

CSSカウンターを使って変則的な番号付きリストを実装する

久しぶりにCSSカウンター便利だな、と実感したのでメモ。

CSSカウンターとはこういうものです:
CSS カウンターの使用 - 開発者ガイド | MDN


こんな感じの文書をWebページに掲載するときに(あくまで例ですがこういう構造)、
f:id:yuw27b:20191105214629p:plain

マークアップにはOL要素を使うのが妥当に思えます。
リストの通し番号より先にカッコ付きの文が出てくるので、CSSカウンターを使ってこんな感じでコーディングしました。


See the Pen
List with CSS counters
by Yu Watanabe (@yuw27b)
on CodePen.

リストアイテムの先頭でなくても、任意の場所で通し番号を表示できるので便利です。
もちろんOL要素以外でも使えます。

ボタンを押したことが伝わるCSS

a要素やbutton要素のボタンのCSSは、最近よくこんな感じにします。
:active属性でボタンを押下した状態のスタイルを指定できますが、1px下に動かすだけでもユーザーに「ボタンを押した」ことが伝わります。


See the Pen
button:active
by Yu Watanabe (@yuw27b)
on CodePen.

margin-topまたはmargin-bottomでも下に1px動かすことはできますが、もともとのマージンや、隣接・親要素のマージンとの相殺が起こっている場合もあるので、それらに影響のないtransformを使っています。

特に装飾に指定がない場合は、この「とりあえず1px動かしておくCSS」を入れています。

Let's Encryptの証明書更新コマンドは、月1回実行ではダメ

TL;DR

  • Let's Encryptが発行するSSL証明書の有効期間は90日
  • ただし時計のずれを考慮して発行(更新)手続きの1時間前を"issue date"として発行される(つまり有効期間は発行時点からだと90*24-1時間)
  • なので、cronで「毎月x日」の設定で月に1回更新コマンドを実行している場合、暦によっては更新が間に合わず失効する可能性がある


深く考えずに月に1回更新コマンドを実行していたら、危うく失効しかけたのでメモ。

業務上の都合で、(クラウドではなく)自前のサーバにNginxをインストールして、いくつかのWebサービスホスティングしています。
SSL証明書Let's Encryptから取得し、HTTPSのサービスをしています。
そして、毎月1日のAM7時に証明書の更新コマンド(certbot-auto renew)が作動するようにcronを設定していました。
このコマンドは、有効期限が30日未満(less than 30 days)であればその証明書を更新する、という動作をします。

例えば1月1日のAM7時に取得された証明書がありました。

f:id:yuw27b:20190312120019p:plain
ファイルの生成日時を確認すると、1月1日の7:06です。

f:id:yuw27b:20190312120121p:plain
ブラウザでこの証明書の有効期限を確認すると、4月1日の6:06です。

今後のcronの作動タイミングは、
2月1日AM7時
3月1日AM7時
4月1日AM7時
・・・
ということになりますが、

2月1日AM7時・・・証明書の有効期限まで30日以上あるので更新かからず
3月1日AM7時・・・証明書の有効期限まで30日以上あるので更新かからず(3月は31日まである!)
4月1日AM6時6分・・・証明書失効(!)
(約1時間の証明書期限切れ状態)
4月1日AM7時・・・ここでやっと更新がかかる

約1時間とはいえ、これでは証明書の更新が間に合っていません。

ここで、証明書の有効期限は4月1日の7:06ではないのか、という疑問がわいたのですが、
ブラウザで証明書の詳細を見ると、1月1日の6:06に有効になって、4月1日の6:06に無効になる、と表示されます。
f:id:yuw27b:20190312163250p:plain

なぜ1時間ずれているのか。
同じ疑問を持った人がいるようで、Let's Encryptのコミュニティに質問と回答がありました。
Certificate Not Valid Before dated 1 hour prior to generation - Help - Let's Encrypt Community Support

回答者の中にLet's Encryptのエンジニアさんもいますが、時計のずれを許容できるように、という理由だそうです。

結論

月に2回とか25日に1回とかの設定で更新コマンドを実行するのが安全。

蛇足な補足

実は何度か「あと20日で失効しますよ」という警告のメールが届いて、不思議に思いつつも「とりあえず」で手動で更新したことがありました。月に2回更新コマンドを実行するように変更してからはそういう「不思議な」事態は起こっていません。

NDS第59回勉強会に行ってきたよ

参加&発表して来ました!

nagaoka.techtalk.jp

・・・次でちょうど60回なんですね!
いつもどおりいろいろな発表が聞けて、良いインプットになりました。
テーマが「学習・AI・入学」ということで、機械学習について発表もさせてもらいました。
私の働く研究室での取り組みについて話せる範囲でお話したのですが、絶賛試行錯誤中なのでスライドの公開ができません、ごめんなさい。成果として早めに公表できるようがんばります。

以下、印象に残った発表などを(発表者の敬称略)。
※メモを取るのをすっかり忘れて聞いていたので、記憶が間違っていたらごめんなさい!!



「TensorFlow.jsで遊ぶ」(kasacchiful)

TensorFlow.jsを使って、ブラウザでの機械学習のデモを見せてくださいました。
モデルさえロードされていればオフラインでも画像の判定などができるはずなので、おもしろいですね!
あとで「他の人がやっているのを見てささっと作った」みたいなことをおっしゃていましたが、手を動かすのが早くて見習いたい・・・。

「趣味がはかどる趣味プログラミングの話」(yyasuyuki)

AS番号の観察がご趣味とのことで、番号の取得と返却を自動で監視してTweetするbotを作りました、というお話でした。
AS番号というものは知らなかったのですが、通信事業者の歴史まで分かって興味深かったです。
botをフォローしたらさっそくいろいろ発生しているのですが、ぜひ背景について解説していただきたいところ・・・


「Angularでコンポーネント間のデータ受け渡し」(gatabutsu)

Angularのコンポーネント間でデータの受け渡しをする場合の最適解は何だろう、というお話でした。
私は普段、主にReactを書いているので、最近のAngularのコードを見られて良かったし、コンポーネント間のデータの受け渡し、という問題はReactでも同様に発生するので、とても興味深く聞きました。
データの受け渡し方法がいくつかあるわけですが、それを(コンポーネント同士の)結合強度によって整理して、不必要に結合を強くしないようにする、という考え方はとても良さそうだと感じました。

「GHELIAグループとAIUEOの取り組み MakersのためのAI」(清水 亮)

清水さんのことは存じていて、前述のように私も最近は機械学習に関わっているので、とても楽しみにしていました。
スケールが大きく力強いお話で圧倒されていたのですが、何より、AIが社会インフラとなる時が来ることを確信して、そのために着実に事業を進めていらっしゃる、という印象を受けました。
実験的なAIの話はよく聞きますが(私が研究寄りの仕事だからかもしれませんが)、実際に社会で活用するための”出口”をこんなにしっかりと見据えたお話は初めてで、とてもおもしろかったです。

C#で、安眠装置の開発」(ailight)

安眠装置、というか「降雪量によって自動的に水量をコントロールできる融雪パイプがあれば雪が降っても安心して寝てられる」装置です。
インターネットから降雪情報を取得→イーサーネットリレーで電圧を制御→融雪パイプから水が出たり止まったりする、
という仕組みです。これ本当に動いてるそうです・・・すごい・・・。
悲しいことに(?)今年は雪が少なかったので、効果の検証は次の冬まで持ち越しの部分もあるようですが、どうなるか気になります。
技術を使って身の回りの問題を解決するのは、まさにエンジニアのあるべき姿でかっこいいですね!


最後に、主催のcivicさん今回もありがとうございました&お疲れさまでした!
次回は6月22日の予定だそうです。

TDDBC 長岡 に参加してきました

TDDBC 長岡 2019-02 - connpass に参加してきました。

参加の動機

私は普段、業務で主にWebアプリケーションを作っていますが(フロント・サーバ両方)、機能もユーザーも限定的で小規模なものが多く、あまりテストを書くことはありません。
テストを書いた数少ないケースでも、「これはさすがにテストくらい書いたほうがいいのかなあ」というような曖昧な動機で、プロダクトコードがほぼ完成してから書いていました。それでも、テストを書いてみるとプロダクトコードの問題点に気づけたり、多少でもプログラムの動作に自信が持てたりするので、テストについてもっとしっかり学ぶと良さそうだな、という気持ちがありました。

講師のt_wadaさんのことはもちろん存じていて、監訳をされたSQLアンチパターンという本を読んでいたこともあり、それも参加を決めた要因でした。
(TDDの本は今読んでいるところです・・・)

感想

まず午前中のキーノートセッションおよびライブデモがとても分かりやすく、早く手を動かしてみたい!という気持ちになりました。
TDDについて「なんかテストを先に書くのかなあ」くらいに考えていたのですが、「開発手法」の1つなのだな、ということが理解できました。
課題がまずToDoリストに細分化されるので、スムーズに開発に入っていけそう、という印象です。

午後からはペアプログラミングでTDDを実践してみる、という内容でしたが、ペアの相手の方とたくさん会話をしながらコードを書き進めることができ(きっといろいろと気を使ってくださっていたと思います、ありがとうございます)、とても良い経験になりました。

ToDoリスト→テストを書く→コードを書く・・・を繰り返しているうちにプログラムが出来上がっていくので、現在地を見失わず視界も良好、という感覚になりました。そして出来上がった時に自信を持って「できたー!」と言える感じがしました。
途中、楽しくなりすぎてうっかりテストの前にコードを書いてしまい(そして案の定テストが通らず迷子になった)、遠くにライオンの姿が見えたりもしましたが、それも含めて良い経験でした。

レビュータイムも、TDDを実践している(TAの)方々がどこに着目しているのかが分かって興味深かったです。
懇親会でもたくさんの発表があり、あっという間の1日でした。

新潟県内でこのようなイベントを企画していただき、ありがとうございました!

今後

ということで、まずは一度、自分の業務でTDDをやってみたいところです。来週あたりフロントエンドの小規模な新規開発がありそうなので、ちょうどいいかも?と思っています。