两个关于设计的视频
平面之外，仍是设计 设计本是艺术 来源：https://space.bilibili.com/38053181
此博客中的热门博文
Chrome浏览器多线程下载开关
2022年年历（包含节假日）
当新武侠遇上老武侠
动漫美女图一张
mysql（多级分销）无限极数据库设计方法
相信有过开发经验的朋友都曾碰到过这样一个需求。假设你正在为一个新闻网站开发一个评论功能，读者可以评论原文甚至相互回复。 这个需求并不简单，相互回复会导致无限多的分支，无限多的祖先-后代关系。这是一种典型的递归关系数据。 对于这个问题，以下给出几个解决方案，各位客观可斟酌后选择。 一、邻接表:依赖父节点 邻接表的方案如下(仅仅说明问题)： CREATE TABLE Comments( CommentId int PK, ParentId int, --记录父节点 ArticleId int, CommentBody nvarchar(500), FOREIGN KEY (ParentId) REFERENCES Comments(CommentId) --自连接，主键外键都在自己表内 FOREIGN KEY (ArticleId) REFERENCES Articles(ArticleId) ) 由于偷懒，所以采用了书本中的图了，Bugs就是Articles： 这种设计方式就叫做邻接表。这可能是存储分层结构数据中最普通的方案了。 下面给出一些数据来显示一下评论表中的分层结构数据。示例表： 图片说明存储结构： 邻接表的优缺分析 对于以上邻接表，很多程序员已经将其当成默认的解决方案了，但即便是这样，但它在从前还是有存在的问题的。 分析1： 查询一个节点的所有后代(求子树)怎么查呢？ 我们先看看以前查询两层的数据的SQL语句： SELECT c1.*,c2.* FROM Comments c1 LEFT OUTER JOIN Comments2 c2 ON c2.ParentId = c1.CommentId 显然，每需要查多一层，就需要联结多一次表。SQL查询的联结次数是有限的，因此不能无限深的获取所有的后代。而且，这种这样联结，执行Count()这样的聚合函数也相当困难。 说了是以...
发现新产品的网站
如何在不懂行的情况下挑选二手车？
我来分享一下我在二手车行业里收车的流程经验 来帮助一些购买二手车不知道从何入手的小伙伴 买二手车不同于买新车，确定好颜色配置剩下的就是谈价 而二手车需要注意 车况、年份、配置、手续、价格等 在选购一辆二手车的时候，首先要确定自己的预算是多少，手里握着10万买宾利这肯定不现实 能买什么价位的车这很重要，在确定好自己的预算后，上各种信息平台开始淘车 在网上淘车时一定一定要注意，千万不要贪便宜看远低于市场平均价格太多的车 真正的好车，车商绝对不会标低价来贱卖的 所以一定要注意，不要贪便宜！ 同年份同配置的车，在网上标价越高，车况好的几率越大，反之就越小（这里是几率） 别问我怎么知道的，都是血的教训 ---------------------------------第一部分：网上淘车--------------------------- 当你选出中意车型后点进车辆界面需要注意5个点。 1.保险年检有没有过期 2.车辆首次上牌时间 3.现在车辆公里数 4.车辆配置 5.上牌所在地和车辆标价 有的平台会提供检测报告，只能参考不可全信 当你感觉价格和信息没什么毛病，就可以打电话问价了 打电话需要简单明了干脆，只要咨询到3个信息 第一，车还在不在（确定车有没有卖掉） 第二，手续全不全，能不能正常过户（避免抵押车） 第三，微信号（加微信要定位） 其他信息可以在微信里咨询，比如车况，价格优惠等 等加到车商微信后一定要索要车架号 车架号可以查到该车的维修保养记录和车型 车型的话我一般都 汽修宝 汽车保养记录可以用 查博士 ---------------------------------第二部分：车况评估--------------------------- 确定好车型和维修保养记录没问题就可以预约车主看车 看车的时候要一定要注意！！！ 在没有行业经验的前提下最好找第三方评估机构或者靠谱代看！！ 在没有行业经验的前提下最好找第三方评估机构或者靠谱代看！！ 在没有行业经验的前提下最好找第三方评估机构或者靠谱代看！！ 千万不要看完网上一两个评估文章或视频就轻易的去试水 二手车车况评估要是那么简单人人都可以看视频当评估师 评估师都是一辆一辆车喂出来的 有些精修车辆没有专业的经验和测量仪器是摸不清楚真实车况的 所以小白买车最好找行业内有权威的展厅或者4S店购买车辆 或者找一个第三方评估机构或者4...
消逝中的在线数据
如果你的数字数据——电子邮件、短信、照片和文档——很快就会在一系列毁灭性的电风暴中消失，你会如何竭力保住它们？ 这就是苏珊·多诺万（Susan Donovan）所设想的未来的灾难，她是一名高中教师，也是一名科幻作家，常驻纽约。在她自行出版的小说《纽约市地理学》（ New York Hypogeographies ）中，她描述了这样一个未来：2250年，由于电力干扰，海量数据遭到删除。 在随后的几年里，考古学家们在被毁坏的城市公寓中遍寻21世纪初的文物。 她说：“我在想，‘ 如果所有的数码产品都不见了，这会给人们带来怎样的变化？ ’” 在她的故事中，灾难性的数据丢失并不是世界末日，但极具破坏性。它促使人们改变保存重要数据的方式。多诺万写道，电风暴带来了印刷业的复兴。但人们也得思考如何储存那些无法打印的东西，比如增强现实游戏。 亚历山大图书馆位于埃及亚历山大，曾是世界上最大的图书馆。由埃及托勒密王朝的国王托勒密一世在公元前3世纪所建造，后来惨遭火灾，因而被摧毁。它实际是什么模样无人知晓，因为它连一个石块实物都没有留下。? wikipedia 数据从来都不是完全安全的。试想一下被烧毁的亚历山大图书馆——毁于一场大火可能是你听说过它的唯一原因。数字数据不会在巨大的火灾中消失，却会消失于一次单击，或随着时间推移，消失于存储介质无声的悄然退化中。 今天，我们已经习惯了这种删除。这样的例子不胜枚举—— 2019年MySpace个人资料消失便是轰动一时的例子之一。多年来许多陆续关闭的谷歌服务也囊括其中。 此外，还有一些在线数据存储公司，为人们的数据提供安全保障。 但讽刺的是，他们有时会指定删除某些数据。 ? Yoors 在其他情况下，这些服务会长时间运行。但用户可能会丢失登录所需的详细信息。或甚至忘记了他们有过账号。他们可能再也无法像在阁楼里找到一鞋盒的旧信件那样，找到存储在那里的数据了。 多诺万之所以对“转瞬即逝的”数字数据感兴趣，原因在于她的个人经历。她在大学专修数学，有多份手写笔记。她笑着说：“有一次我开始记电子笔记，之后却找不到了。” 上世纪90年代末，她还写过在线日记。现在日记没了。她从事的创意项目也不再完好地保存在网络上。 当她创造这些数据时，还以为自己在创造可以长久存在的东西。就像可以无限重放的电影那样。但现在，她对什么是数字数据及其可能持续多久的理解已经改变...
WireGuard+V2ray打造史上最安全隐匿且高速的内网穿透隧道
首先讲一下需求，其实需求简单无比， 那就是无论身处何时何地，只要有互联网，就可以访问内网资源 ，说得具体点，比如出差在外想访问家里NAS存储的文件，通过直接访问NAS的内网IP（比如192.168.2.10）就可以实现访问，就好像自己坐在家里一样 时代背景 传统的内网穿透方案只能实现某个端口的穿透，想换个端口又需要重新配置，而在本方案中，整个内网资源都是共享的，只需配置一次即可。缺点是需要一个 大带宽公网服务器 做转发（如果流量使用不大也可使用小带宽公网服务器），不做转发也需要一个公网服务器作为 信令服务器 交换各自IP做NAT打洞操作，但TCP打洞难度太大（需要 三次握手 ），一般是UDP打洞，但是UDP又会被 QoS ，而且打洞成功率还需要受NAT类型影响（Full Cone NAT打洞成功率高，且需要NAT两边都是该类型，简而言之该类型NAT会 记住内网主机出去的端口 ，如果NAT不记住，则端口全靠猜），所以话题绕回来了，想要稳定还是需要一个大带宽公网服务器做转发。 该方案简单来讲就是 WireGuard over WebSocket over HTTPS ，也是一种 UDP over TCP 的方案。那为什么这么简单的需求需要这么复杂的实现呢？因为需要大带宽公网服务器做转发，就牵扯出一些列问题，这里简单说一下时代背景： 国内商用带宽贵 ：因为国家政策要求民用带宽量大价低，所以运营商普遍用高价商宽补贴家庭带宽。首先，宽带是运营商管的，就是那三家垄断，国内网络基础设施只有三大运营商有资质建设，阿里云、腾讯云、华为云等数据中心都必须要跟运营商买带宽，价格没法谈，偏贵。所以想想为什么百度云要限速了吧，你下载1G的小电影所支持给运营商的带宽费用和百度支付的根本不在一个数量级。其次IP资源受美国控制，国内独立IP价格更贵。而海外的商用带宽却很便宜，因此大带宽公网服务器一般选择海外服务器，既然出国了，那出国流量都会受到婶查的影响。所以这是第二点背景 网X络X婶X茶 ：富强、民主、文明、和谐！@#￥#￥%...，这就需要我们满足 隐匿 的需求，隐匿其实是在安全层面之上的，不安全谈何隐匿。 运营商对UDP实施QoS ：因为WireGuard使用的是UDP，作者也说过使用UDP的一大原因是因为TCP over TCP性能太糟糕...