いまゆれた
kb10uy(@kb10uy@mstdn.maud.io)の投稿
変換しないというオプションもあるけどあれは後段にBabelを挟む黒魔術用なのでそのまま使える代物ではない？
インターネット老人なので古典的なテンプレートエンジンとaltCSSのほうが開発しやすい(本当か?)
#einsamkeit はTypeScriptに移植されたLaravelみたいなものなので…‥まあ……
例えばwebpackや各種拡張とうまく連携してくれるhtml(テンプレートエンジン)のフォーマッタがないとか
このアカウントは、notestockで公開設定になっていません。
「中のcssはプラグインで搾り取られましたぁ♥」なstyle.jsが生成される問題と戦い続けなければならない……
Docker for Mac (なぜか他コンテナのホスト名が127.0.0.1に解決される)(なぜかIOが遅い(自明))
phpは相変わらずfpmの挙動がいい意味で変態すぎるのでdockerに入れっぱなしでもそんなに問題なかったりするけどrubyとかpythonとかnodeだと厳しいものがある
重ね重ねいうとこれはfor Macの文脈なので少なくともLinuxでは入っててもぜんぜん大丈夫だった
入ってたらダメというわけではないが、Macデバイスの初期不良みたいなもので他では起こらない予期しない動作が頻繁に起きるので使わないほうが精神衛生的にいいなあという感情
同じようなコンテナを複数立てたことがないので分からないという感じになってきた。そういう窮地に立たされればわかるかもしれない
Dockerfileに書くポートは(expose以外)固定しないのは当たり前なんだけど、セットで運用する前提のcomposeで固定しないままだと逆に再現性がなくて使いづらいと思う
いや、execで内部から直接アクセスするか本番用のコンテナに外部からアクセスするかしかしてないのでそういうアレかもしれない
それでportsのエントリで1つしか指定しない(ホスト側ポートがランダムになる)バージョンってそんなに嬉しくなさそうという話です
で、それのうちexposeはホスト側には公開されないのでグローバルに解放しないならだいたいこれで良さそうじゃないですか
docker-composeの話という前提なんですけど、exposeとportsがあるじゃないですか
composeならservice名でホストでアクセスできるし、コンテナからホスト方向もたしか最近ドメインのエイリアスが提供されたので使えると思う
1日4回の生活しててもびっくりするほど濃いこともあるし、朝の一発でもやたらサラサラなのが出ることもある
これは僕が院生(homophone)を始めるずっと前から鼻水をすすったり飲み込んでいたことに由来する
1コマ目
双頭ディルドをしゃぶっていたレズカップル…
2コマ目
忍び寄る割って入る過激派……
3コマ目
二人の胃袋は一面の銀世界……
entry: [
style: 'hoge.css'
],
plugins: [
new CSS抽出するPlugin(),
],
>>> style.js <<<
>>> ほぼ空 <<<
素じゃなくてもマルチページなWebアプリケーションにVueコンポーネントを突っ込むの普通に虚無っぽいんだよな……
本当は1つのRedisインスタンスを使い回すのではなくプロジェクトごとに立てるべきなのかもしれないけど
とりあえずフロントエンドに(素の)Vueを、バックエンドにOAuth2を導入しなければならない
今の所ユーザーも投稿も自分のものと他人の(inboxに入ってきた)ものはテーブルレベルで分ける予定
このアカウントは、notestockで公開設定になっていません。
@rinsuki 海外の自作勢がどうやって作ってるのかは全くわからないんですが、ソフトウェア的にはタダのキーボード入力ですね
このアカウントは、notestockで公開設定になっていません。
DOMが完成する前に実行しないとやばいスクリプトとかそれのほうがヤバそうだしdeferにしましょう
いや実際問題としてスクリプトをバンドル化している場合にああいうbodyケツ配置メソッドって実質使えなくないですか？
よくある</body>の手前にscriptタグ置くやつ、DOMContentLoadedで代用していいかな
.alert > button.closeのclickでdata-hogeで設定したidの要素を消すみたいな感じでいいかな
addEventListenerで例えばbuttonに仕掛けた場合って、仕掛けた後に動的に追加したbuttonでも発火する？
今日のTS 
pathsを設定したディレクトリより下にあるファイルをオートimportするとちゃんとpathsが使われる
まあ今風に解決するならdata-hogeとかを設定して最後に読み込んだスクリプトから一括でフック仕掛けるとかなんだろうなあ
よくある「投稿が完了しました」とか「変更しました」みたいなダイアログを実装しようと思うとどうしてもjQueryみたいなのがほしくなるね
ctx.session が Session | undefined なのでセッションに書き込む全てのミドルウェアでtruthyチェックをしないと行けないんだな
フォームデータのmethodパラメータをリクエストのメソッドにするやついい加減やめたいんだけどいつになったらformのaction属性はGETとPOST以外を許容してくれるんですか？
https://twitter.com/amenoshita_429/status/1038983235047317504
これ謎の技術(Seaurchinでここまでできるとは思っていなかった顔)
echo "p $(git describe)" > ./hoge/version.pug
とかしとけばいいのか
<span>{{ version }}</span>というテンプレートが現状あって、この変数がサーバー側コードから渡される
たとえば特定のES/TS系のファイルをビルド時に出力するというのはサーバー側のトランスパイルと干渉するので採用できない
普通に考えてビルド時に生成するべきですが、静的に型がわかってほしいかそうでなければ完全にTSの管轄外としたいので、どのタイミングでどういうふうにビルドするか決めかねている(webpackなのでなおさら)
Dockerコンテナにつっこんでやるのを想定してるので(nodeだけに)、できればコンテナの外でクライアントビルドするついでにバージョンも確定させてあげたいわねみたいなのがある
今ものすごい欠陥に気づいたんですが、バージョン文字列をサーバー実行時に生成してるのでgitがない環境で実行できない
VSCodeのSCSS(CSSとかも?)の構文強調、 [type='button'] とか書くとバグるっぽいんだよな
koa-session-redisを参考にして実装できたのでようやくダッシュボード実装できますね
セッションデータ本体がクライアントサイドのcookieに保存されるのが個人的にはあんまり好きではないのでRedisにセッションを投入する回
ユーザー情報全体が入ってると多分キャッシュになりそうな気はするんだけど、(バックエンドで必要十分な)ユーザーIDだけ入れといてもキャッシュになるのかはやや疑問
「セッションをキャッシュとして使わないで」って書いてあるんだけどむしろキャッシュとして使うやついるのかよという感じですね
DOMでドムドムするのはJSXだけどあれが出力先にバリエーションがありすぎて死ぬやつなのでReact以外ではどうかな…という感じですね
絵を書いても通じなかったシリーズ、過去には「公園に常設されているドアのない仮設トイレ」などがあった
この間も1Passwordの全項目にアイコン設定してたんですけど、本当に個人的な嗜好でアイコンがつけられるリストはアイコンついてないと気が済まない性分なんですよね
いままで何度か自分でメニューエントリ作ったことあるんですが、たいてい適切なアイコンが見つけられなくて諦めたよね
macOSから中途半端なUbuntu派生に乗り換えてキレてたら逆ギレされて記事消した人も元気にしてるかな……
あれは適切なメンテナによって適切なジャンルと適切なアイコンを伴ってシステムによってのみ管理されてほしいという願望が少なからずある
語弊を承知で言うと、両者ともに自分で作ったメニューエントリーってよくわからない深いディレクトリに配置される(する必要がある)じゃないですか、あれを管理するほどのコストを(所謂)スタートメニューにかけたくない
API的に報告されるホームディレクトリはUSERPROFILEなんですが、ドット始まりでも別に隠しディレクトリにならなかったりあの忌まわしきAppDataがあったりしてあんまり常用はしたくない感がある。マイドキュメントのほうがまだ多少マシ
このアカウントは、notestockで公開設定になっていません。
Windows、アクセスしやすさという観点でおそらくデスクトップが実質ホームディレクトリなので
あれなんで不具合あったんだろうなー。Python本体のカスタムかAnacondaに必須の設定が干渉したとかかな？
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
悪意があったらもっとひどい、例えばSMバーでロケットを出し入れされてる場面とかを想像すると思うんですよ
いや本当に悪意はなくて、そういう形の張り型を持ってて定期的に致してる姿を想像してしまっただけです
あ、あとこれは開発者としての問題なんですが、開発はWindows限定とかザラなのが悲しいですね
特定のゲームエンジンバックエンドが存在しないのにクロスプラットフォームでしかも異様に動作が軽いという
まあ物理デバイスの仮想化以外にもレイヤーが存在しそうなのでWindowsは相対的に不利なのかもしれない(?)
でもVulkanでD3D12エミュレーションしたら性能が100%超えたりしたってのはさすがにギャグがすぎる
Unityに代表されるクロスプラットフォームゲームエンジンの普及はまあそういう意味では嬉しいんですが、AAA級タイトルは得てしてグラボの最新機能(Windows限定)とかを使ってくるので、まあそういうことですね
@alice APIレイヤーのラッパ経由とかならたしかにパフォーマンスは問題なさそうだけどVBox的なのだとね……
