KTSee.eu.org

平面之外，仍是设计 设计本是艺术 来源：https://space.bilibili.com/38053181

chrome://flags/#enable-parallel-downloading Enable parallel downloading to accelerate download speed. – Mac, Windows, Linux, Chrome OS, Android 启用并行下载以加快下载速度。–Mac、Windows、Linux、Chrome操作系统、Android

来源：https://www.bilibili.com/video/BV1NS4y1f7e2

我来分享一下我在二手车行业里收车的流程经验 来帮助一些购买二手车不知道从何入手的小伙伴 买二手车不同于买新车，确定好颜色配置剩下的就是谈价 而二手车需要注意 车况、年份、配置、手续、价格等 在选购一辆二手车的时候，首先要确定自己的预算是多少，手里握着10万买宾利这肯定不现实 能买什么价位的车这很重要，在确定好自己的预算后，上各种信息平台开始淘车 在网上淘车时一定一定要注意，千万不要贪便宜看远低于市场平均价格太多的车 真正的好车，车商绝对不会标低价来贱卖的 所以一定要注意，不要贪便宜！ 同年份同配置的车，在网上标价越高，车况好的几率越大，反之就越小（这里是几率） 别问我怎么知道的，都是血的教训 ---------------------------------第一部分：网上淘车--------------------------- 当你选出中意车型后点进车辆界面需要注意5个点。 1.保险年检有没有过期 2.车辆首次上牌时间 3.现在车辆公里数 4.车辆配置 5.上牌所在地和车辆标价 有的平台会提供检测报告，只能参考不可全信 当你感觉价格和信息没什么毛病，就可以打电话问价了 打电话需要简单明了干脆，只要咨询到3个信息 第一，车还在不在（确定车有没有卖掉） 第二，手续全不全，能不能正常过户（避免抵押车） 第三，微信号（加微信要定位） 其他信息可以在微信里咨询，比如车况，价格优惠等 等加到车商微信后一定要索要车架号 车架号可以查到该车的维修保养记录和车型 车型的话我一般都 汽修宝 汽车保养记录可以用 查博士 ---------------------------------第二部分：车况评估--------------------------- 确定好车型和维修保养记录没问题就可以预约车主看车 看车的时候要一定要注意！！！ 在没有行业经验的前提下最好找第三方评估机构或者靠谱代看！！ 在没有行业经验的前提下最好找第三方评估机构或者靠谱代看！！ 在没有行业经验的前提下最好找第三方评估机构或者靠谱代看！！ 千万不要看完网上一两个评估文章或视频就轻易的去试水 二手车车况评估要是那么简单人人都可以看视频当评估师 评估师都是一辆一辆车喂出来的 有些精修车辆没有专业的经验和测量仪器是摸不清楚真实车况的 所以小白买车最好找行业内有权威的展厅或者4S店购买车辆 或者找一个第三方评估机构或者4...

二、国内访问 Blogger 1 首先准备 请确认自己能够科学上网。 不会的话，我这里写有一篇教程： http://mooc1.chaoxing.com/zt/201723393.html 购买域名。没什么好讲的，各个地方都能买，我图便利，直接在阿里云买的域名。（同一个域名，在腾讯云买还要便宜点，不过因为我上一个域名就在阿里云买的，所以这次顺便就在阿里云买了） 2.设置解析 1.Blogger要求的设置 打开Blogger后台，找到设置—基本，Blogger 会提示你需要设置两个 CNAME 分别解析到 ghs.google.com 和 ***.dv.googlehosted.com (每一个人的都不一样) 为了 Blogger 可以在国内访问，我们不能直接按上述的解析。 我们得将第一个 CNAME 解析：记录类型： A 记录，主机记录：WWW，记录值由「ghs.google.com」改成 「国内可访问的 IP」 后面的一个CNAME 解析不变：记录类型：CNAME，主机记录：ai76xxxxxxxxxxx，记录值：gv-j5jxxxxxxxxxx 2. 寻找国内可访问的 IP 可以使用站长之家 Ping 工具：http://ping.chinaz.com/ 如下图所示，Ping检测：ghs.google.com 找一个国内可访问的 IP。 注意：香港的IP延迟虽然小，但是不行。 3.域名后台设置解析 打开阿里云控制台—域名—域名列表—解析，照第一步所说的那样样设置，如下图： 至此，域名解析设置完成，当然这样还不够，我们还得修改Blogger自带的博客模板。 备注：如果想要实现不带www访问 添加：记录类型： A 记录，主机记录：@，记录值同为找到的 「国内可访问的 IP」 如下图这样： 这样用 axutongxue.com 也可以访问我的博客了 4.启用https 之前大佬说在设置https时，不能直接设置： https://blog.iljw.me/2018/07/enable-blogger-https.html 不过现在blogger好像改了，按上面那样设置之后，我们就可以直接在Blogger后台开启https了 ...

范式：英文名称是 Normal Form，它是英国人 E.F.Codd（关系数据库的老祖宗）在上个世纪70年代提出关系数据库模型后总结出来的，范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。目前有迹可寻的共有8种范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常所用到的只是前三个范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。 设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。 目前 关系数据库 有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、 第四范式 (4NF）和 第五范式 （5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般说来，数据库只需满足第三范式(3NF）就行了。 下面就简单介绍下这三个范式。 第一范式（1NF） 强调的是 列的原子性 ，即列不能够再分成其他几列。  考虑这样一个表：【联系人】（姓名，性别，电话）  如果在实际场景中，一个联系人有家庭电话和公司电话，那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列（电话）拆分，即：【联系人】（姓名，性别，家庭电话，公司电话）。1NF 很好辨别，但是 2NF 和 3NF 就容易搞混淆。  说明：在任何一个 关系数据库 中，第一范式（1NF）是对 关系模式 的设计基本要求，一般设计中都必须满足第一范式（1NF）。不过有些 关系模型 中突破了1NF的限制，这种称为非1NF的关系模型。换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的 关系模型 。 第二范式（2NF） 首先是 1NF，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。  考虑一个订单明细表：【OrderDetail】（OrderID，ProductID，UnitPri...

如果你的数字数据——电子邮件、短信、照片和文档——很快就会在一系列毁灭性的电风暴中消失，你会如何竭力保住它们？ 这就是苏珊·多诺万（Susan Donovan）所设想的未来的灾难，她是一名高中教师，也是一名科幻作家，常驻纽约。在她自行出版的小说《纽约市地理学》（ New York Hypogeographies ）中，她描述了这样一个未来：2250年，由于电力干扰，海量数据遭到删除。 在随后的几年里，考古学家们在被毁坏的城市公寓中遍寻21世纪初的文物。 她说：“我在想，‘ 如果所有的数码产品都不见了，这会给人们带来怎样的变化？ ’” 在她的故事中，灾难性的数据丢失并不是世界末日，但极具破坏性。它促使人们改变保存重要数据的方式。多诺万写道，电风暴带来了印刷业的复兴。但人们也得思考如何储存那些无法打印的东西，比如增强现实游戏。 亚历山大图书馆位于埃及亚历山大，曾是世界上最大的图书馆。由埃及托勒密王朝的国王托勒密一世在公元前3世纪所建造，后来惨遭火灾，因而被摧毁。它实际是什么模样无人知晓，因为它连一个石块实物都没有留下。? wikipedia 数据从来都不是完全安全的。试想一下被烧毁的亚历山大图书馆——毁于一场大火可能是你听说过它的唯一原因。数字数据不会在巨大的火灾中消失，却会消失于一次单击，或随着时间推移，消失于存储介质无声的悄然退化中。 今天，我们已经习惯了这种删除。这样的例子不胜枚举—— 2019年MySpace个人资料消失便是轰动一时的例子之一。多年来许多陆续关闭的谷歌服务也囊括其中。 此外，还有一些在线数据存储公司，为人们的数据提供安全保障。 但讽刺的是，他们有时会指定删除某些数据。 ? Yoors 在其他情况下，这些服务会长时间运行。但用户可能会丢失登录所需的详细信息。或甚至忘记了他们有过账号。他们可能再也无法像在阁楼里找到一鞋盒的旧信件那样，找到存储在那里的数据了。 多诺万之所以对“转瞬即逝的”数字数据感兴趣，原因在于她的个人经历。她在大学专修数学，有多份手写笔记。她笑着说：“有一次我开始记电子笔记，之后却找不到了。” 上世纪90年代末，她还写过在线日记。现在日记没了。她从事的创意项目也不再完好地保存在网络上。 当她创造这些数据时，还以为自己在创造可以长久存在的东西。就像可以无限重放的电影那样。但现在，她对什么是数字数据及其可能持续多久的理解已经改变...

相信有过开发经验的朋友都曾碰到过这样一个需求。假设你正在为一个新闻网站开发一个评论功能，读者可以评论原文甚至相互回复。 　　这个需求并不简单，相互回复会导致无限多的分支，无限多的祖先-后代关系。这是一种典型的递归关系数据。 　　对于这个问题，以下给出几个解决方案，各位客观可斟酌后选择。 一、邻接表:依赖父节点 　　邻接表的方案如下(仅仅说明问题)： 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()这样的聚合函数也相当困难。 　　说了是以...