fediverseのサーバーなんてほんとんど1年持たないだろうしurlの永続性求める意味はあまりないんじゃないかなあと思ってる
fediverseのサーバーなんてほんとんど1年持たないだろうしurlの永続性求める意味はあまりないんじゃないかなあと思ってる
そういえば久しぶりにiPhoneのGoogle翻訳アプリ開いたら今っぽくなっててびっくりした
透明度変えるのは別にいいんじゃないかなって感じする
結局押してることが分かればなんでもいいといえばいいんだが
タッチエフェクト出るようなゲームだとactiveのスタイルをわざわざ当てる必要すらない気がするな
そのうちwindows copilotみたいなのが進化し続けて主の居ないパソコンでソシャゲの周回を毎日やってくれる
https://trekhleb.dev/js-image-carver/
を作ったときに使ったツールを見つけるのに苦労したので書いておく
seam-carving, 画像, 圧縮
githubのmarkdownでdetails連打して、ぜんぜんmarkdownじゃないなと思いながらかいてる
ckeditor/github-writer: GitHub Writer - WYSIWYG Rich-Text Editor for GitHub, powered by CKEditor.
https://github.com/ckeditor/github-writer
あるにはあってメンテされてるがissueは多いな……
Spotifyでシリーズもののアルバム一覧できないの意味わからないと思ったが、これ特定の音楽レーベルのものをヴァリアスアーティストとして出してる登録者側が悪いのか？
YouTube MusicでもApple Musicでもそうなので音楽とは不便なものらしい
Yoshi's Story (music) - Super Mario Wiki, the Mario encyclopedia
https://www.mariowiki.com/Yoshi%27s_Story_%28music%29
任天堂も円形じゃないCDとかだしたことあるんだ
あるWebアプリのロゴ右クリックしてダウンロードしたらsvgで嬉しくなってたけどなんか開けなくて、よく見たら裏切られてた
しかし人間は最初の印象が10割だと思ってるのでなかなか適当で出すのも難しい
複数人でものづくりのサイクルを回す場合、完璧でない状態でフィードバックもらって改善する方が最終的に良いものができるという考え方は概ね正しいと思う
DBをモックするな👈はい……
レスポンスをモックするな👈はい……
外部サービスをモックするな👈はい……
@Eai ああ、それは今風のテスト方法ですね。しかし私の頃はね、外部との接続テストやDB接続中のテストはすべて本番と同じ環境下で行っていましたよ。そう
手間もかかるし、失敗すれば大被害が出るリスクもありましたが、それが技術者の責任感を育て、品質意識を高めるための必要なプロセスだったんです。あの時代の厳しさが今の技術の礎になっていると信じています。
懐かしいな……。今ではモックでテストを行い、シミュレートされた環境下での安全なテストが当たり前になってしまいましたね。確かに効率なら今のほうが上かもしれません。でも、あの頃のリアルな経験を通じて得られた洞察や知識は、どんなモダンな技術にも代え難い価値があると思うんですよ。
はやくAIってやつでこの機能のテストを作るのにどういう観点を見ればいいのかどうやって作ればいいのか教えてくれるくんがほしい
例えばaws-sdk使ってて、aws-sdk-client-mockを使えばモックできると思うんだけど果たしてこれを使うのがいいことなのかよくわからない
関係ないけどaws周りのこういうの、なんか興味がないのであんまりこういうの使ったり実装読んでみようと思わないんだよなあ
なにがあるべき姿なのかよくわかんないので、数字受け取って文字列返すくらいのレベルまで下げた関数だけテスト書いてカバレッジちょいあげするくらいしかしてない
ふむ、Tailwindを使おうと思うとXMLをクライアントサイドXSLTでHTMLに変換する方式は使いづらそうだな。
Tailwind CSS実践入門 第2章 Tailwind CSSの基本 ──開発環境へのインストール、設定ファイルの記述、エディタの設定 | gihyo.jp
https://gihyo.jp/article/2023/07/tailwindcss-practice-02
https://tailwindcss.com/docs/installation/play-cdn
表示速度を気にしないのであれば、Play CDNをインポートすればランタイムで必要なクラス作成してくれる
が、動的にコンテンツが増えたりすることもないだろうし、どうにかしてあらかじめ出しておくのがいいんじゃないでしょうか
なるほど。ただ、そもそもクライアントサイドXSLTによる変換からCSSによるレイアウトが始まる構成で表示速度が落ちるので、どうせやるなら事前にXSLTによる変換をかけてHTMLファイルを作ってTailwindの解析を通す方がよさそうな気がする。
XSLTで使えるのかはわからないけど、乱暴な（しかし機能する）プリレンダのやり方としてhtmlを返すローカルサーバーに対してwgetを使ってhtml保存するという手がある
まあそうですね
（クライアントレンダリングをシミュレーションするなにかもありそうだけど、特にそうする意味がなさそう）
tailwindではスタイルをcssで書かないけど、cssでどのように書くかは知っている必要がありますよ
なのでシンプルにCSSが必要なだけなら普通にCSS書けばいいと思います
なんらかのビルドが必要なものはすぐに面倒になるので、なくて済むならそれに越したことはない
CSS variableが普及したので、わざわざビルドプロセス差し込んでまでsassとか使う意味もあまりなくなったね
mixinは便利だけど
userscript-graveyard/package.json at master · eai04191/userscript-graveyard
https://github.com/eai04191/userscript-graveyard/blob/master/package.json
あと今でも機能するかわからないんだけど、html平置きするサイトでtailwind使いたい時、tailwindのcliにはcss渡すとpostcss通してくれる機能があるのでそれでビルドしたこともあったな
ウィジウィグでなんかいい感じにサイト作ってくれる有名なサービスあったと思うけど名前忘れた
react.devはなぜかフレームワーク使わないreactのアンチなのでviteの紹介がこの文章の下にある
react向けいい感じヘッドレスUIコンポーネントであるradix uiの使用例として、tailwindでスタイリングされた評判のいいコンポーネントとして https://ui.shadcn.com/ があるんだけど、慣れてない人が見たら脳が爆発すると思う
例えばボタンは
"inline-flex items-center justify-center rounded-md text-sm font-medium ring-offset-background transition-colors focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2 disabled:pointer-events-none disabled:opacity-50"
から始まる
普通は分けて書いたものをclsxとかtailwind-mergeとかでマージする（と私は思ってる）ので、ここまで1つにまとめて書かれるのはtailwind日常的に使ってる人でもウッてなる
