博文
目前显示的是 九月, 2020的博文
一入B站深似海，从此游戏是路人，我因为学习沉沦其中
大家好， 我是 胡侃侃 。 前言 怎么才能赚更多的钱， 自古唯有读书是最好的出路， 所以对于学生， 对于社会青年， 学习是第一位的，不断的学会新的技能。 做好一个斜杠青年需要更多的技能， 艺多不压身啊。 现在生活压力这么大， 学生要好好学习， 毕业了也同样不能放松。 B站全程无广告， UP主为了粉丝都是超级用心。 一入B站深似海，从此 游戏 是路人，谁也没想到当初因为追剧进B站，如今却因为学习沉沦其中。而且B站拥有海量学习内容， 现在你要是学的完， 算我输。 回头便知， 这是保姆级学习资料整理。 你品， 你细细品。 我不光帮你省下近万元培训费， 学会技能做斜杠青年还能够赚钱。 本文没什么图，超级多宝…
2019年度最喜欢浏览器拓展
拓展之于浏览器，就像 APP 之于智能手机。 拓展的数量成千上万，但能够被用户知道的通常在100个左右，能被用户选择使用的也就50个左右，而大多数人安装的拓展也不会超过10个。 浏览器拓展的数量庞大，但真正好用的并不多。 我们经常能看到很多拓展推荐的文章，好的推荐文章各有不同，但" 没什么卵用 "的推荐文章大多很相似。 一是喜欢标题党。 动不动就这个神器，那个黑科技，诸如此类的词汇被滥用。 二是喜欢推荐 Adblock Plus 。不是说 Adblock Plus 不好，而是实在太入门了，把你当做小白用户来看待。 三是喜欢把拓展（或扩展）说成是插件。 这是对拓展认识不足的表现，就好像是一个给你…
此博客中的热门博文
两个关于设计的视频
动漫美女图一张
Chrome浏览器多线程下载开关
当新武侠遇上老武侠
如何在不懂行的情况下挑选二手车？
我来分享一下我在二手车行业里收车的流程经验 来帮助一些购买二手车不知道从何入手的小伙伴 买二手车不同于买新车，确定好颜色配置剩下的就是谈价 而二手车需要注意 车况、年份、配置、手续、价格等 在选购一辆二手车的时候，首先要确定自己的预算是多少，手里握着10万买宾利这肯定不现实 能买什么价位的车这很重要，在确定好自己的预算后，上各种信息平台开始淘车 在网上淘车时一定一定要注意，千万不要贪便宜看远低于市场平均价格太多的车 真正的好车，车商绝对不会标低价来贱卖的 所以一定要注意，不要贪便宜！ 同年份同配置的车，在网上标价越高，车况好的几率越大，反之就越小（这里是几率） 别问我怎么知道的，都是血的教训 ---------------------------------第一部分：网上淘车--------------------------- 当你选出中意车型后点进车辆界面需要注意5个点。 1.保险年检有没有过期 2.车辆首次上牌时间 3.现在车辆公里数 4.车辆配置 5.上牌所在地和车辆标价 有的平台会提供检测报告，只能参考不可全信 当你感觉价格和信息没什么毛病，就可以打电话问价了 打电话需要简单明了干脆，只要咨询到3个信息 第一，车还在不在（确定车有没有卖掉） 第二，手续全不全，能不能正常过户（避免抵押车） 第三，微信号（加微信要定位） 其他信息可以在微信里咨询，比如车况，价格优惠等 等加到车商微信后一定要索要车架号 车架号可以查到该车的维修保养记录和车型 车型的话我一般都 汽修宝 汽车保养记录可以用 查博士 ---------------------------------第二部分：车况评估--------------------------- 确定好车型和维修保养记录没问题就可以预约车主看车 看车的时候要一定要注意！！！ 在没有行业经验的前提下最好找第三方评估机构或者靠谱代看！！ 在没有行业经验的前提下最好找第三方评估机构或者靠谱代看！！ 在没有行业经验的前提下最好找第三方评估机构或者靠谱代看！！ 千万不要看完网上一两个评估文章或视频就轻易的去试水 二手车车况评估要是那么简单人人都可以看视频当评估师 评估师都是一辆一辆车喂出来的 有些精修车辆没有专业的经验和测量仪器是摸不清楚真实车况的 所以小白买车最好找行业内有权威的展厅或者4S店购买车辆 或者找一个第三方评估机构或者4...
Blogger搭建国内可正常访问博客（超详细教程）
二、国内访问 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年代末，她还写过在线日记。现在日记没了。她从事的创意项目也不再完好地保存在网络上。 当她创造这些数据时，还以为自己在创造可以长久存在的东西。就像可以无限重放的电影那样。但现在，她对什么是数字数据及其可能持续多久的理解已经改变...
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()这样的聚合函数也相当困难。 说了是以...