Twitter復帰後の感想
僕のTwitterは、一昨年の年末にアカウントを削除して、去年の年末にここでの更新を流す媒体として復活させ、4月くらいに(さみしくなって)フォローも再開した。その後、前はあんなにも嫌だった時系列じゃないタイムラインが、それほど嫌じゃなくなったことがわかってきて、なんでだろうと考えていた。 一度アカウントを消す前は、インターネット的に近しい人とのやりとりをふわっと行うために使っていた。そういう場合、タイムラインが時系列じゃないと、他人のツイートにうまく反応できない。リプライで直接つなげるわけでもないので、自分で何を言っているのかよくわからなくなるし、もう過ぎた話題にふわっと反応していてやらかした感じにもなる。 ちょっと離れている間に、時系列タイムラインじゃなくなったTwitterは、ずいぶん様変わりした気がする。サービスそのものじゃなくて、みんなの使い方が。ハッシュタグは前からうまく使われて
JavaScriptがなくなった
もう相対日時にするやつとutm_*を削除するやつしか動かしてなかったので、JavaScriptをなくした。再構築したので消えている。 最近はデフォルトでJavaScript無効でも生きていけるようなインターネットになってきた気がする。HTML Living Standardのおかげかなって思ったけど、どちらかというとSVGやFlexboxやなんやのおかげなのかもしれない。 話題の遅延読み込み(loading属性)もそういうやつっぽいけど、挙動としてどうにもならない問題があるような気がしてならない。回線が安定していて、無制限で、マシンパワーも余っているなら、遅延読み込みする必要はないけど、それをブラウザーが知ることは難しそう、というような話。「多分あと10分くらいはハードウェアやインフラをこれくらいまで使えますよ～」みたいなのがOSがブラウザーへ教えないといけないのかな。 遅延読み込みはペー
@mediaなし、またはロジックレスCSS
このウェブサイトのCSSから@mediaルールを極力なくした。今は亡き(殺した)CSS MQPackerへのモチベーションがゼロになったことをきっかけに、段階的に進めている。全廃はまだ難しいので、カスタム・プロパティーに代入していく@mediaルールだけに絞り、それ以外でもなるべく使わない、という方針にした。 普通のCSSであるルールセット側はごくシンプルなコードになる。var()が多いけれども。よくあるプロパティーの上書きが起こらないので、メディア・クエリーがなかった時代のCSSっぽくなる。メディア・クエリーによるプロパティーの上書きを、カスタム・プロパティーによる値の動的変化に置き換えている、と説明できる。 あらかじめ設定したカスタム・プロパティー群をデータと捉え、そのデータを参照する側に@mediaルールのようなロジックに相当するもの書かない、という見方もできる。これを踏まえてロジッ
書棚ページ
ウェブページへのリンクと読んだ本のメモが混ざっているのは良くないとずっと考えていたので、本は書棚ページに分離した。どちらかというとアフィリエイトを明確に分離したい、というような理由で、ユーザーのことを考えているわけではなかった。 HTMLを書き変えてCSSを少し減らしたりしてた。クラス名を使わないでCSSを書くのが本当に限界になってしまったので、ちょっとだけ解禁。モードの変更でのみ解禁するような形にとどめているけど、バカらしくなってきてもいるので、書き直しの時期なのかも。 またCSSから@mediaブロックを限界まで減らそうとしている。@mediaブロックをロジックとみなして、ロジックレスCSSと説明しているけど、なんか違う気もする。それも含めて書き直しか。 フィードの統合はまだやってない。踏ん切りがつかない。自分のウェブサイトのRSSを7つも購読してる。
墓参り(2019年4月16日)
年中行事になった墓参りに行ってきた。とてもいい天気で、甲府からは富士山もよく見える。甲府は、観光客の数という点で、桜が終わる頃がベストだという結論になりつつある。ブラタモリが甲府だったタイミングだが、特に混んではいなかった。いつかリニアで行きたい。 行きは久しぶりにかいじにした。JR東日本のチケットレス導入記念で特急料金が1000円のところが700円でちょっとお得だ。電車のダイヤが変わったが、相模線からの接続はよくないままだ。八王子駅で暇だったので「はまかいじなくなったんだ」とか「かいじはほとんどが富士急行乗り入れと分離するのか」とか「竜王まで行くかいじとかあったんだ」とか時刻表を見てたりした。 かいじは相変わらず大月でガラガラになる。富士急行乗り入れの車両があっても変わらない。観光客がホームを行ったり来たりさせられて可哀そうだ。下りでは、分離する方の車両が後ろ、富士急行のホーム自体は前に
気になったウェブページ
2022年12月16日 METガチャをゲットだぜ！ メトロポリタン美術館所蔵の冨嶽三十六景やゴッホなど名品がカプセルトイに: メトロポリタン美術館の所蔵品がガチャポンに。カバ欲しい。 2022年12月4日 Anker 521 Power Bank (PowerCore Fusion, 45W): 充電器とバッテリーがセットになったFusionの新作。USB-Cが2つで15V-3Aの給電が出来る。 2022年12月3日 Migrating from Vue 2 to Svelte: Vue 2から3ではなくSvelteに移住した理由と手法。よりHTMLとJavaScriptに近い点が強く評価されているようだ。 2022年12月1日 Counting unique visitors without using cookies, UIDs or fingerprinting.: Last-Mod
個人ウェブサイトへ
TwitterやInstagram、Pinboardのアカウントを消したので、それらでやっていたことを自前でやりはじめている。それぞれの過去の投稿をインポートし、RSSもそれぞれ作った。あとは/feedを全部入りにするつもりだが、ちょうど1年くらい前に購読先を変えさせたので、ちょっとやりづらい。でももう少ししたら変える。こうして個人ウェブサイトへと回帰した。 ポートフォリオではない個人ウェブサイトが、どういうものだったか、はっきりと思い出せない。カウンターとかリンク集があったとか、フレームで作られていたとか、ウェブリングとか、些末なことは思い出せる。しかし、どういう雰囲気だったのかまったく思い出せない。 外に放つというより、内に向かうものだったような気はする。そういう感じが出していけるとうれしい。 コンテンツが大きく追加された関係上、ホーム・ページや完全なログのページなどをいじっている。ま
あなたのアカウントは正常に削除されました
色々なアカウントを消した。SNS疲れの類いを感じない程度にしか利用していなかったので、依存もしていないのだろう。そういった使い方ならば、やめてもあまり変わらないし、下位互換風に自前でやるだけでも事足りるはずだ。 また、そういうユーザーは各サービスの主要な層から外れている。自然とその施策に残念な思いをすることが多く、とりまく環境にも落ち着かない。サービス提供者とそのユーザーとして、お互いがまったく噛み合っていない。 新しくやり直すことはいつでもできるはずなので、まずは噛み合っていなそうなサービスのアカウントを消していった。その過程で勢いあまって……。 Adobe Amazon.com Cloudflare Dropbox IFTTT Instagram LINE npm Pinboard Tumblr Twitter Wunderlist ZOZOTOWN 他にも消したような気もするが、覚え
Clean CSSだけ
CSSの書き方が昔風になりつつある。SassにもPostCSSにも依存しない書き方だ。その上で、あってもなくても良い処理を、また別の安定した独立ツールに任せるようにした。その独立ツールとしてはClean CSSが優秀なので、これに任せてあとは気にしない。 もちろんこのウェブサイトのCSSのような小さな規模での話で、規模が大きいならどちらかは使う。小さな規模では、多くの環境でそのまま動くように書く。大きな規模では、その状態になるようにSassやPostCSSを使って書く。 SassやPostCSSだけでどうにかしようとすると、ともすればコードが奇抜なCSSのような何かになりがちだ。日常的にそうした環境に浸かっていると、普通のCSSが書けなくなるどころか、読めなくなる。CSSのデバッグ環境が開発者ツールにまだ依存している現在、読めなくなるのはかなりまずい。 小さな規模では、普通のCSSとして書
夢(2016年12月21日)
タンスを開けてキャベツをしまおうとしている。キャベツがかなり大きく、一抱えくらいあった。そのままでは入らないので、いくつかに切り分け、しまう。しまった後で「パンツの横は良くないな」と考え、引き出しを開けたところで目が覚める。 特にキャベツに思い入れはないが、その日の夕飯はカキフライでキャベツの千切りを大量にしていた。そのせいかもしれない。この関連を証明するためにもう一回夕飯の主菜をカキフライにすることはやぶさかではない。
夢なし
今月に入ってからまったく夢を見ていないような気がする。枕を変えたからだろうか。新しい枕は羽毛のやつだ。今までは低反発のやつだったので、それと比べるとうるさい。うつぶせ寝なため、羽毛ががさがさこすれる音が聞こえる。しかし夢を見ていないことを考えると、そこそこ心地よいノイズなのかもしれない。 それはともかく長いクッションが枕もとに欲しい。硬めの円柱状が良いのだが、なかなか見つからない。
何もしないためのデザイン
豆腐がある。日本ならどこのスーパーでも売っている豆腐のことだ。そのパッケージは簡易で必要十分なものだ。大抵は箱状で、上部をビニールで密閉されている。豆腐のパッケージの箱はそこそこ丈夫で、食卓にそのまま出すこともできる。一人暮らしならばそれでも良いかもしれないが、やはり必要な分だけ切り分け、器に盛るだろう。 それはそうした方がおいしく感じることができるからだ。器に盛ろうと盛るまいと豆腐自体は変化しないので、その味が変わるというのもおかしな話なのだが、人はそれほど客観的で絶対的な感覚を持ってはいない。 ただし、豆腐をおいしく食べることが主で、器に盛ることは主ではない。ここを間違えるとおかしなことになる。だから「器がきれい！」ではダメだし、また「器に盛られた豆腐がきれい！」でも微妙だ。ただただその豆腐をおいしく食べられるように、できるだけそれ以上何もしないように盛り付けるとよいだろう。 そのよう
夢(2016年9月19日)
マキネッタでコーヒーを淹れる。愛用のタンブラーにそそぐも、なかなかいっぱいにならず、せっかく淹れたコーヒーがなくなる。しょうがないのでもう1度コーヒーを淹れる。今度は慎重にそそぐ。しかしまたいっぱいにならない。というのを10回くらい繰り返したところで目が覚めた。 この夢の2日後、Thermosの真空断熱タンブラーの底面に貼ってあるプレートが剥がれた。予知夢っぽい形になったので怖い。 タンブラーは買い替えようかとも思ったが、底面をふさいでいるシールが剥がれたわけではないようだったので、金属にも使えるアロンアルファで貼り付けた。3年ちょっと雑に使ったあたりで剥がれたようだ。1年以内にもう一度剥がれるか、断熱効果が大きく衰えていたら買い替えよう。
Windows 10 Anniversary UpdateのEmoji
⃣ 0⃣ 1⃣ 2⃣ 3⃣ 4⃣ 5⃣ 6⃣ 7⃣ 8⃣ 9⃣ © ® ‼ ⁉ ™ ℹ ↔ ↕ ↖ ↗ ↘ ↙ ↩ ↪ ⌚ ⌛ ⏩ ⏪ ⏫ ⏬ ⏰ ⏳ Ⓜ ▪ ▫ ▶ ◀ ◻ ◼ ◽ ◾ ☀ ☁ ☎ ☑ ☔ ☕ ☝ ☺ ♈ ♉ ♊ ♋ ♌ ♍ ♎ ♏ ♐ ♑ ♒ ♓ ♠ ♣ ♥ ♦ ♨ ♻ ♿ ⚓ ⚠ ⚡ ⚪ ⚫ ⚽ ⚾ ⛄ ⛅ ⛎ ⛔ ⛪ ⛲ ⛳ ⛵ ⛺ ⛽ ✂ ✅ ✈ ✉ ✊ ✋ ✌ ✏ ✒ ✔ ✖ ✨ ✳ ✴ ❄ ❇ ❌ ❎ ❓ ❔ ❕ ❗ ❤ ➕ ➖ ➗ ➡ ➰ ⤴ ⤵ ⬅ ⬆ ⬇ ⬛ ⬜ ⭐ ⭕ 〰 〽 ㊗ ㊙ 🀄 🃏 🅰 🅱 🅾 🅿 🆎 🆑 🆒 🆓 🆔 🆕 🆖 🆗 🆘 🆙 🆚 🇨🇳 🇩🇪 🇪🇸 🇫🇷 🇬🇧 🇮🇹 🇯🇵 🇰🇷 🇷🇺 🇺🇸 🈁 🈂 🈚 🈯 🈲 🈳 🈴 🈵 🈶 🈷
ジェーン・エア
久しぶりに森薫の「エマ」と「シャーリー」を読んだので、流れで「ジェーン・エア」を読んだ。「嵐が丘」といっしょに高校の頃に読んで以来だと思うので、20年ぶり以上だ。岩波文庫の新訳が読みやすく、3日くらいで一気に読めた。読み終わった後にまた「エマ」と「シャーリー」を読みたくなった。何の永久機関だ。 ディケンズとブロンテ、間にサトクリフと、イギリスの小説をここのところ読んでいる。これといった理由は思い当たらないのだが、イギリスの小説を一番好む傾向にあるようだ。フランスやドイツの小説はどうも苦手だ。登場人物の名前のせいかもしれない。頭で認識できる限界が英語読みの姓名までというのは大いにありそうだ。 岩波文庫の海外文学はそのほとんどが訳を新しくしているようだ。この読みやすさなら過去に何回か挫折した「戦争と平和」もちゃんと読めるのかもしれない。岩波文庫がUnlimited対応したら読もう。
lang属性の効果範囲 - Hail2u
ウェブサイトの言語セレクトメニューを作る時、英語で一覧させることも多いが、それと同じくらいそれぞれの言語名でそれぞれの言語を表示することもある。母国語で表示されていれば絶対にわかるだろうし、見つけやすいだろうという理屈だ。そのこと自体にはいくつか欠点が考えられるわけだが、HTMLとしてはlang属性を使えばうまくマークアップできるだろう。同時にtitle属性を使って英語でフォローすると完璧……だが、そこそこ面倒くさいことになる。 それぞれの言語名でそれぞれの言語を表示した言語選択メニューは択一しづらい(またはスキャンしづらい)という問題がある。特にアルファベット＋αの言語名は混同しやすいし、ソート順が不明確になりやすく、順にたどって見つけなければならない。どこら辺にありそうかアタリをつけることができないわけだ。 ルート要素のlang属性でen-USが指定されているとする。 <span la
時間と角度をより短い単位へ
0の値の場合に短い単位を採用するという処理は単純に実装できるが、0でない値の場合はそれなりに面倒くさい。単純に考えれば愚直に単位の変換を行い一番短いものを採用するという形で良いが、それだとかなりコストがかかるだろう。つまり変換すると短くなるケースをある程度想定しなければならない。 時間はs単位とms単位のどちらで書いてもあまり長さは変わらない。s単位の方が単位自体は短いものの、s単位で時間を指定する場合は概ね小数点を書く必要があるので、その優位点はほぼないと言って良いだろう。ただ場合によってはs単位の方が短くなる可能性がある。それはms単位を使った値の末尾が0の場合だ。 .test { transition-duration: 210ms; } は、 .test { transition-duration: .21s; } の方が1文字短い。末尾の0を省略できるというわけだ。00で終わって
gzip下における、CSScombの昇順ソートに対する優位性
CSScombを最小化ツールなどと共にデプロイ時に通すというプロジェクトはちょくちょくあるようだ。僕はCSScomb (を始めとしたルールセット内のプロパティーのソート)は可読性のためで、Linterやフォーマッターなどで処理すべきであると考えている。また最終的な転送量においても昇順ソートに比べさほど差が出ないのではないかとも考えている。そのためそういったデプロイ時での処理には疑問を持っている。 可読性のためだけであるとすると、Linterが、そうでないならフォーマッターによる自動修正で処理すべき事柄であることに疑問の余地はないだろう。なぜならばデプロイ時の処理ではリリース環境のデバッグにおいてしか役に立たず、CSSを書いている時、または読んでいる時にその可読性が役立つことはないからだ。 最終的な転送量、つまり完全に処理をしたCSSのファイルサイズには差が出る可能性はある。うまくソートして
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
指先のやけど、ゴム手袋、火ぶくれ
写真 - Hail2u