橙子的短想法
1.22K subscribers
487 photos
13 videos
26 files
4.28K links
好资源和短想法
Download Telegram
Forwarded from 浮生东京
Media is too big
VIEW IN TELEGRAM
网易:2022年我们的集体记忆
Forwarded from HuTalk✍️胡说 (Daniel)
一款在线 epub 阅读器,支持 Dropbox 同步,打开速度还挺快的,支持划线、评论,而且还是开源的,太棒了。在左边的工具栏,可以看到该书中所有的图片,以及你阅读的时间线。

地址:https://flowoss.com/zh-CN
Forwarded from Newlearnerの自留地 (初学者 | newlearner.site)
#Books #Music #Movies #Blog

📩 接读者来稿,他向我们介绍了通过 NeoDB 自建书籍、电影、音乐和游戏收藏评论空间的心得

🎥 NeoDB:书影音标记 – 豆瓣、GoodReads 和 Google Book 的替代品

🔗Web

📝 文章概述

- 引
- 备选方案
- 我的选择:NeoDB
- 讨论

👨🏻‍💻 作者的话

NeoDB 是一个通过 Mastodon 登陆的书籍、影视、音乐收藏评论社区,是很好的豆瓣替代品

NeoDB 支持豆瓣, Goodreads, The Movie Database, Steam, Spotify, IMDB, Bangumi, Bandcamp 数据导入

① NeoDB 的优点

- 免费;
- 支持多个数据库,聚合各平台的优势内容,
- 对中英文内容都支持的很好;
- Mastodon 登陆,能看到 Mastodon 好友的动态,兼顾 社交属性;
- 学习成本低;
- 小众,同温层。

② NeoDB 也有很多缺点

- NeoDB 的开放性有所欠缺,由站长 @alphatownsman 一人维护;
- 「导出个人数据」功能在优化中;
- 豆瓣和 Goodreads 有丰富的扩展和插件,如 wp-douban ( 示例);
- 小众,欠缺社区活力。

频道:@NewlearnerChannel
Forwarded from 404 KIDS SEE GHOSTS (生产力之王版 (志筑仁美)
RWR 解决微信公众号图片显示问题

Readwise Reader 作为可以 All In One 的阅读神器,也有如微信公众号图片显示不全问题。而最初一个解决方法,将公众号文章下拉全部加载后再用插件收藏,但仍有些加载不全。又学到这个,可以解决:

- 安装油猴脚本:禁止Web版微信延迟加载图片

- 安装网页美化插件:如 StylishStylusxStyleStylebot 等,我就直接用 Stylish.

- 复制此 CSS 字段到美化插件的自定义(Stylish Editor)
.js_img_placeholder { display:none}

然后微信公众号文章导入 Reader,图片支持就很好啦。

#tools
Forwarded from codedump的电报频道 (老C)
#杂
这段时间给Databend增加增删列的功能,基本功能已经通过,加了如下截图的用例,目的是验证一顿增删列、插入数据之后的查询都是正确的。

可还是很忐忑,因为这个功能涉及了很多对原有数据格式的修改,要保证所有场景都兼容到了。

我最近复习数学,反过来看,编程在大部分时候,都不能算是“科学”,更多算是“工程”。个中原因,我认为大部分时候,无法从数学角度严格证明一个功能是100%完全没有bug的。

复杂参数的场景姑且不论,就以最简单的整数为参数的问题来说。数学归纳法的原理是先证明n=1的时候结论成立,再假设为n的时候结论成立,最后以这个为前提来证明n+1时结论成立,这在数学上是可行的。但是呢,来到编程领域,一个“千年虫”问题,不过就是表示年份的整数划到了2000而已,就能触发bug了,数学归纳法在这里失效了。

在知乎上看到过著名的“一个测试工程师走进一家酒吧”

一个测试工程师走进一家酒吧,要了一杯啤酒

一个测试工程师走进一家酒吧,要了一杯咖啡

一个测试工程师走进一家酒吧,要了0.7杯啤酒

一个测试工程师走进一家酒吧,要了-1杯啤酒

一个测试工程师走进一家酒吧,要了2^32杯啤酒
...


很多时候人们当成段子来看,但是现实中就是这样,无法去归纳某个场景的测试就是完备的,只能靠:堆用例的场景去验证。

sqlite是业内最稳定的数据库之一,号称几万个用例,可即便是它的作者也不敢打包票100%无bug,也是一边补充用例一边增加现有用例。

总而言之,一个事情如果无法用数学原理严谨证明其正确性,总会出问题;反过来说,编程在大部分时候无法用数学证明其正确性,所以编程不是科学,更接近于工程:靠经验、靠堆用例等等手段去保证(而不是验证)其正确性。
Forwarded from Ray Tracing (Ray Eldath🍁)
https://sive.rs/pg 数据校验写进约束、业务逻辑用 PL/pgSQL 写进存储过程,甚至直接在数据库层用视图生成JSON返回给 “前端”,作者列举了很多理由认为这是 “简化”,看评论区赞同的人也不在少数,这是值得了解的「data base as a backend」还是盲目地重演历史呢...

想起之前面试的时候面试官就说(大意)「像金融电信这些客户,性能和效率都不是他们最关心的,最重要的是对SQL的支持要全,特别是触发器还有存储过程这些容易被忽视的特性,他们用得很多,业务逻辑几乎全放里边,一定要支持好...」

这篇文章是我在回顾1983年的经典论文 A Critique of the SQL Database Language 时偶然看到的,希望深入阅读这篇论文后能总结出一些值得分享的体会。
Forwarded from 小破不入渠🌏
苹果刚刚发布了新 HomePod。两年前上代停产的时候,我是这么写的:

HomePod 是一台用来「播内容」,而不是「播声音」的音箱。

你可以用它听音乐、听播客、看电影,付出极低的代价,获得极致的声音体验。但你没法用它刷 TikTok、看 YouTube、打电话,用它取代「手机扬声器」。

HomePod 甚至不鼓励你「频繁切歌」或「拖动电影进度条」,因为每一个类似的操作,都需要经过 Wi-Fi 传输,反馈不流畅,体验很差。

这是一个有点矛盾的产品。一方面,它很便宜、很方便,随便放在房间的某个角落就可以用了。另一方面,它又只能播完整的唱片、专辑。HomePod 与那些零碎的,仅几秒钟长的「抖音神曲」绝缘。

某种程度上,HomePod 将「认真听」这件事平民化了。你不需要一个经过设计的听音室,不需要专门的唱机、专门的音箱,就可以认真听一张专辑。这是苹果做产品的核心理念,用简单的方式做认真的事,也就是他们反复强调的,the music DNA。

HomePod 发布之初,我曾与朋友讨论,「现在只要开口说一句话就可以听到音乐,这是不是过于方便,没仪式感了?」但实际上,HomePod 在「方便」和「认真」之间,找到了一个绝佳的平衡。

可惜的是,更多人,甚至没有「认真听」的需求。

https://jesor.me/2021/to-homepod-the-music-dna/
Forwarded from Ray Tracing (Ray Eldath🍁)
年前读完了屯了很久的 Stonebraker 大神的文章 What Goes Around Comes Around,补一下读后感。这篇文章介绍了数据模型35年来(到今天则是53年... 半个多世纪,令人感叹)的演化历史,通过分析层次、网络、关系、ER、扩展关系、语义、面向对象、对象-关系和半结构化(XML)模型的特性和流行程度,总结数据模型取得成功的必要条件,并告诫业界许多看似全新的模型实则是重演历史,失败是它们既定的宿命。

1. 我一直以为存储过程 stored procedure 是随着SQL的诞生就流行起来的应用编写方式,直到最近业务逻辑才回归到应用层。然而事实并非如此:早期应用都是将业务逻辑置于应用层,直到1980年 Sybase 才首先倡导了将逻辑下推到存储过程的方法。厂商们发现这样做可以省掉很多RTT从而显著提升在TPC-B(TPC-C的前身)下的性能,于是这样的做法才逐渐流行。如今提倡的逻辑向应用层回归和对存储过程的批评,其实是盘旋上升的历史又回到了原点。
2. 没有人预料到JSON很快便取代XML成为了数据交换的事实标准,并使半结构化模型空前地流行,开启了长达数十年的NoSQL运动。早期对半结构化模型优点的分析聚焦在「半结构」本身,指出现实世界中的事物(例如简历)难以用单一模式来描述,而忽视了更有力的原因,即模式很难在开发的初期就确定下来。
3. 纵观数据模型发展史,几乎可以断定:只有新模型能大幅提升性能、或支持旧模型很难模拟但又急需的特性时,后来者才有成功的可能。存储过程对性能的提升和NoSQL将可扩展性作为一大优势都能说明这点。或许在我看来十分有潜力的图模型也将挑战关系模型的统领地位,最终形成关系、NoSQL、图三足鼎立的局面。
4. Postgres 对用户自定义函数(UDF)和类型(UDT)的良好支持源于已然消亡的面向对象模型。Oracle 率先发现将一些数据挖掘算法作为 UDF 实现远比将数据来回搬迁高效,这些 in-database ML (例如之前提到过的 Teradata ML Engine)可能会给现有实现带来深刻的变革。
5. 在文章的最后,两位作者写道 Moreover, it seems to us that designing a DBMS which made code and data equal class citizens would be a very helpful. If so, then add-ons to DBMSs such as stored procedures, triggers, and alerters would become first class citizens. The OR model got part way there; maybe it is now time to finish that effort. 不过时至今日也鲜有 “finish that effort” 的成型产品,可能SQL就是这么扶不上墙吧,真是令人感叹。 #selected