diff --git a/exports/hykilp/atom.xml b/exports/hykilp/atom.xml index de8a929e1..503d82059 100644 --- a/exports/hykilp/atom.xml +++ b/exports/hykilp/atom.xml @@ -2,7 +2,7 @@ https://aza.moe/life 小桂桂的回忆录 📒 - 2024-11-22T10:11:24.606910+00:00 + 2024-11-22T12:11:56.255902+00:00 python-feedgen https://aza.moe/meru_256px.png diff --git a/exports/hykilp/index.html b/exports/hykilp/index.html index b1cb559b9..eac83b393 100644 --- a/exports/hykilp/index.html +++ b/exports/hykilp/index.html @@ -27,7 +27,7 @@ diff --git a/exports/hykilp/posts.json b/exports/hykilp/posts.json index 3bf7e23c7..eded1f156 100644 --- a/exports/hykilp/posts.json +++ b/exports/hykilp/posts.json @@ -48540,7 +48540,7 @@ "id": 3557, "date": "2024-04-06T11:39:09", "text": "试试让 DALL-E 把蓝粉星夜的这个想法画出来结果真的画得好好看 🤩", - "views": 288, + "views": 289, "forwards": 9, "reply": { "id": 2671, @@ -63828,7 +63828,7 @@ "id": 4652, "date": "2024-11-15T08:50:17", "text": "昨天秋叶留言服务器宕了,上去看一眼原因是盘满了...\n\n清出 9GB 空间修好之后,为了防止同样的事情再次发生,随手写了一个 py crontab 脚本每小时检查一下盘用量,超过 85% 就在 tg 上发消息 😀\n\n懒猫猫当然要用懒猫猫解决方案", - "views": 113, + "views": 114, "forwards": 0, "media_group_id": 13853284941485317, "images": [ @@ -63858,7 +63858,7 @@ "id": 4654, "date": "2024-11-16T02:53:45", "text": "豆腐可爱喵", - "views": 115, + "views": 116, "forwards": 0, "images": [ { @@ -63945,7 +63945,7 @@ "id": 4659, "date": "2024-11-18T04:45:51", "text": "今天想要找到现在 AI 画图的 SOTA 的时候发现了一个奇妙网站 Text to Image Leaderboard,用来收集不同模型的对比数据\n\n但是因为不太相信大众审美,所以我花时间自己做了 900 次对比,得出了一个自己的审美排行榜,FLUX 1 Pro 在第一位\n\n对比过程中还发现 DALL-E 的图辨识度真的很高,每次都是一眼就能看出是 DALL-E 生成的,其他模型都不太能... 可能也是因为这个原因 DALL-E 生成的结果很让人审美疲劳,在我的审美排行中只拿了 43%\n\n有点想试试训练一个分类模型看看每个生成模型的输出的辨识度 quq(不过说好了不开坑了", - "views": 97, + "views": 98, "forwards": 2, "media_group_id": 13855241208528253, "images": [ @@ -63975,7 +63975,7 @@ "id": 4661, "date": "2024-11-18T04:58:09", "text": "(前情提要:syama 想让 gpt4o 画一张我和她和瑞希躺在床上的样子,但是输出结果一直被 OpenAI 的内容政策拦截,所以我把 prompt 拿给 FLUX 1.1 Pro Ultra 画了\n\n感觉 OpenAI 对图片生成的内容拦截是不是太严了 🤗", - "views": 113, + "views": 115, "forwards": 1, "reply": { "id": 4659, @@ -63999,7 +63999,7 @@ "id": 4662, "date": "2024-11-18T07:04:50", "text": "#戴上耳机\n\n看到某频道里面发了 Flamingo 突然想到这首歌 qwq\n\n♪ Black, white, green or blue\n♪ show off your natural hue\n♪ Flamingo oh oh oh woah\n♪ If you're multicoloured that’s cool too\n♪ You don’t need to change\n♪ It’s boring being the same\n♪ Flamingo oh oh oh woah\n♪ You’re pretty either way", - "views": 99, + "views": 100, "forwards": 0, "files": [ { @@ -64021,7 +64021,7 @@ "id": 4663, "date": "2024-11-18T16:00:03", "text": "#ADHD 犯蠢 1/1", - "views": 102, + "views": 104, "forwards": 0, "images": [ { @@ -64040,7 +64040,7 @@ "id": 4664, "date": "2024-11-18T17:10:54", "text": "#戴上耳机\n第一次听到 Flamingo 这首歌其实是四五年前在 osu 里面打了这个 WTN3 的 remix,也好好听 qwq", - "views": 90, + "views": 91, "forwards": 0, "reply": { "id": 4662, @@ -64180,7 +64180,7 @@ "id": 4671, "date": "2024-11-21T03:25:16", "text": "今天花了一整天调查这个数据库问题, Hibernate 全责 🛌 以后的项目再也不用 Java EE 了\n\n我试了一下把这整个函数用 native mysql 写出来,发现这条大查询只用 1.19 秒,那为什么我的 kotlin 代码运行速度差这么大呢?\n\n开了 SQL debug 之后我发现即使只是 .findAll() 都要 N 条查询,按理来说 select * from table 只要一条查询就行啊,为什么呢?仔细看看这 N 条查询发现它把 OneToOne fk 都一个一个拉下来了。原本首先花了一条查询 SELECT * FROM parent,然后又花了 N 条查询拉 SELECT * FROM child WHERE id=i...\n\n查了一下这个问题,网上说开 Hibernate bytecode enhance 就好了,它会修改编译完的字节码让 fk 链接用到的时候再查询而不是预先把所有东西查询好。问题是它不太兼容 kotlin,绕过了三个不同的问题才成功编译,之后加上 lazy fetch 终于可以让它在用到 fk 的时候再拉数据了... \n\n但是即使这样依然要把需要拉所有 fk 数据的地方改成手动 mysql 查询,因为 orm/jpql 没办法让 findAll 把单独的查询优化成 join 🛌\n\n唉 感觉凡是透明一点的 ORM 比如 ktorm 或者 exposed 都不会有这样的问题,以后不会再用 Java EE 了", - "views": 72, + "views": 73, "forwards": 0, "media_group_id": 13857276129125749, "images": [ @@ -64214,7 +64214,7 @@ "id": 4673, "date": "2024-11-21T15:30:32", "text": "蜂蜜太久没用变成糖块了 🤤", - "views": 77, + "views": 79, "forwards": 0, "images": [ { @@ -64233,7 +64233,7 @@ "id": 4674, "date": "2024-11-21T17:55:52", "text": "用原生 mysql 重写了整个查询之后获取排行榜从 30s 降到 4s 了!\n\n果然什么优化都没有 RIIR 最方便 🦀", - "views": 74, + "views": 77, "forwards": 0, "reply": { "id": 4670, @@ -64256,14 +64256,14 @@ "id": 4675, "date": "2024-11-21T20:30:46", "text": "syama 这两天在找苏州的合租,有兴趣的话请去联系 @akiyamaXmizuki\n\n(帮忙打下广告 🤤", - "views": 161, + "views": 165, "forwards": 2 }, { "id": 4676, "date": "2024-11-22T04:23:54", "text": "高情商:my email will be encrypted\n低情商:即使对等 AES 密钥是微软服务器下发的,但是我们用 AES 加密过哦!\n\n...感觉现在很多服务的“加密”都是做给不懂计算机但是有 privacy obsession 的人看的,实际上并没有真的安全\n\n就比如这个邮件的 RMS 加密,有没有加密实际上 attack vector 都并没有变。对中间人来说,因为客户端和邮件服务器之间有 TLS,即使没有 RMS 也没办法看到内容。如果任何一方被盗了号或者盗了饼干或者电脑中了后门,攻击者无论有没有 RMS 都能看到内容。如果微软服务器被黑了,也一样无论有没有 RMS 都能看到内容,因为加密密钥存在服务器上... 😶 唉,真的什么都没有解决呢\n\n感觉懂安全的人在这个时代已经摆烂了,想绝对安全也不太可能呢,鬼知道还有多少 Jia Tan 在我的电脑上留着后门", - "views": 56, + "views": 57, "forwards": 1, "media_group_id": 13857995477375541, "images": [ @@ -64293,7 +64293,7 @@ "id": 4678, "date": "2024-11-22T09:48:28", "text": "真的觉得应该停一停了,感觉每隔一段时间就能看到一篇标题是 \"{} is all you need\" 的论文... 不是所有东西都应该是 all you need 好吗 😶", - "views": 42, + "views": 69, "forwards": 2, "images": [ { diff --git a/exports/hykilp/rss.xml b/exports/hykilp/rss.xml index 114a2eb2b..cb182412f 100644 --- a/exports/hykilp/rss.xml +++ b/exports/hykilp/rss.xml @@ -12,7 +12,7 @@ https://aza.moe/life zh-cn - Fri, 22 Nov 2024 10:11:24 +0000 + Fri, 22 Nov 2024 12:11:56 +0000 小桂桂的回忆录 📒 #4678 https://aza.moe/life?post=4678