杂谈

H5飞鸟源码置信大家都不生疏，是一套老源码了 用户【TG电报duotebb】版权所有，禁止转载。 2015年，飞鸟诞生，开始呈现在市场里，过后飞鸟的热度很高，有很多人都用过，原版飞鸟，或者是各种前期二开魔改的版本，总之是大家都绕不开的源码，起初源码泄露，飞鸟开始烂大巷了，也是这个时候开始，飞鸟被不同的人注入各种后门。 多特工作室这套飞鸟源码，也是魔改二开了很多很多的货色。按须要开发了很多飞鸟没有的性能，改版了老掉牙的界面，新增了动画。并退出了七种本地智控算法性能，又依据不同人群的须要开发成了至尊，至尊双系统，和界面性能大改版带SG/IDC飞单的兰博基尼这三个不同版本的零碎。全都是带智控的。起初这套源码还是卖了进来，所以目前大家所能找到不同版本的飞鸟有智控的实践上来说都是咱们晚期那时候二开的版本。 问题在于，目前市面上能找到的各种飞鸟源码，问题确实是多，被咱们工作室流通进来之后，源码被人藏了各种各样的后门，甚至有些敌人花不少心血到手也是有很多问题和后门，但有些敌人从源码里发现咱们工作室留下的信息，分割到咱们心愿能修复。咱们发现不同的源码被不同的人植入各种注入型的破绽，sql破绽，各种各样的后门，有时候甚至你能从一套飞鸟源码里发现好几个不同的人注入的后门。这也就是很多敌人经营到前期做起来了当前都会遇到的问题，很多没教训的技术，或者不是一手开发的技术，很难发现和解决这些后门。前期呈现订单数据被删改，甚至间接被人黑进来当前把数据库打包后删库要钱。间接导致用户的散失。也导致飞鸟源码在市面上口碑烂大巷。当然这套飞鸟在其余技术敌人的手上也有开发出其余的经营版本，比如说X圣，X巴赫，宾X，等还算能够经营的版本（工夫太旧了还有很多飞鸟二开的名字记不起来了）。他们只是不同的人用飞鸟二开进去，只是性能各有不同而已。除了平安方面的问题以外，不反对高并发。前期二开也是有很多限度的。对飞单的反对也不欠缺，不断呈现漏飞或者间接不飞的问题，尽管这些问题在咱们前期二开后也全副解决了。 介于以上起因，和目前市场须要，咱们工作室决定放弃应用这套曾经过期的源码，目前正在从新从零开发一套全新的飞鸟类源码，名字暂定叫："特斯拉"。预计近期就能竣工，通过谨严的测试后就能上线，新版零碎很适宜最近几年的市场行情，能够说该有的性能都将会有，界面精美晦涩，功能完善，更多功能，或者有更好的倡议，有其余性能的须要，都能够留言给我。 因为框架也是本人写的，后续再须要开发什么性能来说，兼容性也会十分好。另外剧透一下，新版零碎也将反对自带波场等区块间接交易，并退出始终在钻研的二维码防封技术，百分百防封。各位刮目相待吧！

原打算更新Woocommerce的部署装置教程，但因为AWS服务器到期了，最近情况比拟拮据，就没有续费了。恰逢国内厂商的618打折，于是花了二百多元买了一台华为云的2核4G的云服务，想应用国内的域名的解析服务，而不须要CDN来减速。于是图便宜又买了一个.cn的域名。想应用这个域名，就须要备案。填写了N多材料，又等了几天，负责审核的人员，电话我说，集体的网站只能备案集体博客，而且还要写分明网站的用处，也仅限于集体的生存教训分享。更多对于商店，交易这样的业务只能降级企业的域名来备案。于是乎，我傻了。毕竟事件总是一步步地做的。注册企业这事儿，我目前没有经营的主体，天然也不想去注册，切实没有必要。 原打算是注册一个集体自建站的电商独立站来做教学演示。一如之前我对国内集体电商经营的思考： Woo这货色毕竟是西方人喜爱用的货色，咱们当初在国内应用，说好听点，叫做舶来品。如果一层不变地搬过去，多少有点不适宜过期，毕竟国内的电商都是从一个页面跳转到另一个页面，目迷五色。又通过多年的线上购物陶冶，第三方非主流的网站，可信度又不是很高。我想这也是独立站目前没有在国内倒退起来的起因之一。但在一个小的社区之间，他的作用还是非常明显的，简略疾速，老本低廉。也能够作为品牌的官网商铺，用来保护产品信息后，同步到其余平台。当然，电商ERP在这方面更业余，费用天然也更为低廉。至于更多的用处，能够请同学们联合本人当下的场景去思考。我在后续的文章中，也尽量把页面的格调设计的有国内电商的内味儿。而不是像其余的教学一样，泛泛而谈，只顾着圈流量。把舶来品做成了舶来品该有的样子。 当初来看，有点童稚了。没方法，业务的内容还是持续写的。当初看来不得不调整一下电商开发的方向。 为了国内的SEO收录我产出的数据，我不得不从新把域名备案为集体博客级别。集体的电商独立站是彻底走不上来了。兴许这是为啥国内环境下没法倒退独立站的起因之一吧。况且阿里系，拼多多，京东，唯品会这些大平台之下，各类商品都在监管范畴之下，从集体的角度的确没有其必要。假使持续独立站的话，也只得做SAAS模式或者跨境电商的建站产品。现实在事实的抵触之下，被折腾得皮开肉绽。 思考了很长一段时间，以及写博文遇到一些问题，我须要从新了解一下我正在做事儿的意义。如何去保持国内的独立站电商产品。前面的打算我将采取曲线救国的模式，晚一点成立公司再进行独立站建站模式的设计。后续将采纳视频模式为主的方法进行产品创作的解读。博客文章将是对视频内容的一种补充。而视频的路线将进一步提高难度，不再应用小白模式进行编写。次要着重于业务实现方面的探讨分享。在博客里会列出文章的参考及解释。对于评论中疑难较多的中央，再采纳视频深刻的解说模式发展。至于Woo电商的建设，会采纳本地模仿环境的形式进行解说。这个也会肯定水平上以视频的模式进行输入。基于此，短时间的更新纲要如下： 1，了解Woo电商及相干设计工具的应用 2，剖析开源电商的业务实现，并建设根底电商框架 3，应用Figma设计电商的初级产品 4，剖析当下前端的可视化页面编辑界面的实现原理，并实现根底的业务搭建 5，逐渐降级实现设计电商各个外围的业务可视化模块，如此交替往返 临时先这样打算，将对每一个技术进行综合，如果有现成的教程，我会在博文中进行举荐援用，而不是本人去再做一遍。我的视频会依照每一个我的技术栈来了解剖析出现，而非手把手教学。我的外围指标是把各类技术进行综合性利用的展现。毕竟我一个人的精力有限，而那些援用的文章或视频，自身就做得很好，我也是其学生。只是将我的了解再次进行加工。 以上，就是我的从新思考。

关上百度网盘，无意间翻见一些旧照片，又加上夜晚的犹豫和耳机里悠长的钢琴声，在这个没人意识的论坛里，我又发感叹，权当记录当下的童稚，供多年后的本人取乐吧。 话说我之前始终没有写博客记录生存的习惯，我狐疑是受成电李晓宇老师的帖子的影响，我耳濡目染地染上了这个习惯。（前年考研时想报在她的门下，惋惜没有考上，遗憾） 李老师的科学网博客 切回那些照片吧，偶尔关上网盘，发现许多多年已在手机上删除的照片居然百度网盘还帮我存着的，一张一张地翻，登时好像时空穿梭，回到了过后的场景个别，既感到和小伙伴们一起玩的喜悦，又愁从心来，因为大家都渐行渐远，再也走不到一块去了。忽然间又发现自己还没有和父母，哥哥拍过一张残缺的照片，更是感觉不适合，今天趁着过年期间，和家人除去逛逛博物馆，再一起拍个照片留个念想吧。还有，再建个家庭微信群。 明明想说的话在脑袋里上蹿下跳，可正想记下来，却都跑得没影了。算了。 最初再附上些旧照片了结此文： 1、老家[2014年8月25日-小狗][2014年8月25日-小猫][2014年8月25日-另一条狗][2014年9月20日-载过好几代人的老石板路][2014年10月5日-和今日小伙伴洗澡][2014年11月 猫狗][2015年1/2月 猫狗][2015年1月18日-大雾盖住了老家房子][2015年8月9日-幺爹家的大狼狗黑虎][2015年8月14日-大山里的飞机飞过][2015年8月25日-第一次看到老家传说中的贵族学校] 2、大学退学[2016年9月8日-周四，下午20:02 我爸送我到大学，去了过后食堂3楼。还记得我过后不想让人送，我妈常常怪我爸把机会给她抢了，当初回忆这所有发现父母真的是十分爱我，只是他们不爱表白。哎，父母可能是世界上最心愿我过得好的人了][2016年9月-大一在浙江安吉的开学典礼][2016年9月-开学第一堂课堂（转到软件工程后才发现食品业余妹子真多，和左前的长发妹子前面本来还有些来往，在得悉她有个高中在谈的男朋友，我就没怎么来往了）] 3、16年国庆[2016年10月2日-国庆节和今日室友跑到杭州银泰][2016年10月2日-冒雨看杭州西湖的音乐喷泉，那时自恋的本人][2016年10月3日-4日 去爬黄山那次真的是很乏味的体验，刚意识不到一个月的三个外地人（四川，湖北，贵州），在国庆节一起进来穷游，第一次见这么平缓的山，第一次见这个大的石头，第一次在山上见这么繁密的星星甚至还有流星划过，第一次露宿在-5度的山头过夜，没钱买吃的就每人买了20块的茶叶蛋来填饱肚子] 我的人生已过了23年，差不多前1/4曾经过来，而不禁让我思考生命存在的意义是什么？万千世界这么多生物，只有人在思考这个没有答案的问题吗？各类动物生命的长度有几分钟到几百年，最短的有蜉蝣，进去后几分钟便会死去，长的有乌龟，有些活得300多年长，甚至据说有些深海生物能活上千年。对于蜉蝣，生命的意义是什么？对于乌龟，生命的意义又是什么？又或者他们基本没有意识到本人活着，只受生物本能驱使流动着？又或者活着本就是个伪命题？宇宙真的太神奇了，如果宇宙是一个程序，那将是如许盛大的工程。

从来没想到有一天我也会遇到这事儿。我就不说我这莫名其妙的300多各种接近0声望的粉丝都是啥了不愧是天朝特色，全球最强大的1->n的能力，就连我这个默默无闻的小白都不放过，真是给我面子啊！算了一下，从写的第一篇博客到现在，也就不到一年时间吧。其实我写博客是带有强迫性质的，团队每周都要进行汇报，展示每周的学习成果，解决的问题等等，考虑到展示的方便性和保存的因素，最后选择了博客。刚开始写其实是非常痛苦的，因为什么都不会，不知道写什么，比小学三年级时作文凑够300字还要痛苦，第一篇博客真的是水得不行，完全可以用“开局一张图，内容全靠编”形容。今年年初，我就定下了一个小目标：写比去年有质量的文章所以每次写文章的时间也是越来越长，以前一两个小时就糊弄完的，现在甚至要花几天时间在草稿箱里反复修改，就拿一开始那张图片的文章来说，我自己花了大概一天的时间去解决那个问题，然后又花了一天的时间去重现那个问题，并且把它记录给下来，可以说花了一定的心血的。但是当看到自己花费了时间精力的成果被其他人盗用，堂而皇之的冠上自己的名字，我心里还是比较复杂的。我本身就是一个默默无闻的小白，除了每周团队成员会认真看我的文章以外，我觉得大部分人可能就是随手打开链接，然后关闭，又或者淹没浩瀚的互联网世界中。但就因为这样我就可以随意地被别人抄袭，盗用吗？说实话，我不知道。我写博客并不盈利，别人盗取我的文章我一毛钱都不会损失，某种意义上来说我还要感谢他们让我的文章被更多人看到。但是因此我们就要对这种现象抱着无所谓的态度吗？我相信不是的。想一下，所有人都去做1->n的活儿，那谁来做0->1呢？今天抄袭博客，明天盗取视频，后天偷版权，那以后呢？仔细想想，BAT三巨头的TX便是以此发家，不得不说榜样的力量确实强大。不过令人欣喜的是，前段时间视觉中国的“黑洞图片”事件唤醒很多人的版权意识，自己的在网上分享的照片却被他人拿来牟利，想想就觉得过分。相信随着中国人受教育程度的提高和经济的不断发展，抄袭，未经授权转载的现象会有越来越多的人去抵制，我们不能对抄袭者做什么，我们却可以努力创造一个鼓励原创的环境。总得来说，抄袭这事就是不对的，写这篇文章主要也是提醒我自己：无论何时，总要有些自己的东西，我在写博客时也会把我参考的文章出处贴到下面，将心比心，我不尊重他人的知识成果，又怎么能要求他人来尊重我呢？

树状结构的数据，就是符合“每个上级节点可以有多个子节点，而每个子节点都只有一个上级节点”这一模型的数据。比如一个 region 可以有多个 zones，而每个 zone 又能有多个 servers；但是每个 server 只位于某个 zone，每个 zone 又只位于某个 region。这种模型，如果换用关系型数据库的行话说，便是有着层次关系的一连串一对多关系。于是我们可以把它存储成一系列的一对多的表，每个表有着若干个上级表 ID 的字段。比如 zone 表里面包含 region_id 列，server 表里面包含 region_id 和 zone_id 列。继续沿用 region - zone - server 的例子。在这个例子里，如果我们想知道 region 3 的 zone 30 下面有多少台 server，可以用 select count() from server where region_id = 3 and zone_id = 30;。注意 zoneid 30 是全局的标识，而不是指 region 3 下面的第 30 个 zone，因为 zone 表是唯一的。（不考虑按 regionid 来分表的情况）如果要获取 region 3 下面所有的 zone 和 server 的数据，则可以这么做：select * from region where id = 3;select * from zone where region_id = 3;select * from server where region_id = 3;但如果我们想获取某些 region 下面的所有的 zone 和 server 的数据，该怎么办呢？比如我想查，location 位于华南的每个 region 下面的所有的 zone 和 server 的数据。zone 表和 server 表里只记录了 region id，所以没法直接去查。一个选择是做 denormalization，就是在 zone表和 server 表里冗余一部分 region 的数据。冗余的后果，就是更新数据时需要更新多个表，且容易会有数据不一致的问题。另一个选择是，先查出顶层 region 的 ids，然后再逐层查下去，像是这样：select id from region where location = ‘South China’;select * from zone where region_id in (…); – 应用层使用刚刚的 SQL 语句得到的 id 来查询select * from server where region_id in (…);当然，如果顶层匹配的 id 有上百个之多，使用 in (…) 效率可能会不够好，可以考虑下用 inner join 的方式。这种方式有些小缺陷，就是你需要在应用层里，把三个查询的结果，组装成每一个匹配的 region 的数据。好在zone 和 server 表返回的数据里面包含了上级表的 id，在应用层里做也不难。如果你的查询请求里面，from region where location = 这种按条件过滤的所占比例不小，可以考虑下把树状结构存储成一个 JSON，而不是三张独立的表。只要你用的关系数据库版本不是太陈旧，基本上都支持 JSON 类型，比如 PostgreSQL 里面就有 jsonb。现在查询 location 位于华南的 region，只要这么做：select id, zones from region where location = ‘South China’;返回的结果大概是这个样子的： id | zones—-+——————————————————————— 1 | [{“size”: 100, “servers”: [1, 2, 3]}, {“size”: 50, “servers”: [1]}] 2 | [{“size”: 100, “servers”: [1, 2, 3]}, {“size”: 50, “servers”: [1]}](2 rows)现在就不用自己去组装结果了。而且性能也比分三个表的好很多，因为存在同一个 JSON 里面，就不用再走 in(...) 或者 inner join 去另外几张表里面筛数据。但在这种情况下，该怎么查询 region 3 的 zone 30 下面有多少台 server 呢？此时 zone id 30 是没有意义的，因为并不存在 zone 表，所有的 zones 都分别存在某个 region 的 zonesfield 里面。假设 zone 30 是 region 3 的第 10 个 zone，则可以写出如下的 SQL：select jsonb_array_length(zones#>’{9,servers}’) from region where id = 3;首先我们定位到 region id = 3。接着从 zones field 中取第 10 个 zone 的 servers，注意算数时要从 0 开始，所以写的是 9 （第 10 个）。然后由于 servers 是一个 JSON 数组，我们可以调用 jsonb_array_length 方法，轻松获取它的长度。这个 SQL 暴露了一些问题：虽然我们可以用 jsonb_array_length 代替 COUNT，但如果要用到 SUM，MAX 或其他更为复杂的聚合操作，就只能通过不那么直接了当的类型转换把数组里面的值挖出来。不那么直接了当通常意味着低效和难以理解。这种情况下不存在 zone id。如果你只想查某个 zone 下面的内容，只能先定位到 region，再向下查询到zone。在有 zone 表的时候，我们可以走 zone id index，而现在只能走 region id index。由于 jsonb 会记录数组中每个元素的 offset，也许定位到具体某个 zone 的开销不会多于在 B 树中搜索某个zone id。但是你首先要把整个 region 3 从文件系统里读出来。当然了，比起 select count() from server where region_id = 3 and zone_id = 30;，这个查询并非一无是处。首先 jsonb_array_length 不需要像 COUNT 那样逐个计数，因为 jsonb 会记录数组的大小；其次，匹配到的 server row 可能不连续，考虑到 OS 的 page cache，不一定要比把整个 region 3 从文件系统里读出来要好。不过如果我想要 region 3 的 zone 30 的 server 300 呢？总而言之，如果你的查询里面，很多是指明某组 id 的，那么分成多个表会更好；如果你的查询里面，很多是根据高层节点的某个属性做过滤，不怎么涉及低层节点的，那么存成 JSON 会更好。当然，假设你的树状数据是异构的，比如 region 下面除了 zone，还有其他乱七八糟、不可名状的节点，那么只能存成 JSON 了。 ...