
Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
History is littered with hundreds of conflicts over the future of a community, group, location or business that were "resolved" when one of the parties stepped ahead and destroyed what was there. With the original point of contention destroyed, the debates would fall to the wayside. Archive Team believes that by duplicated condemned data, the conversation and debate can continue, as well as the richness and insight gained by keeping the materials. Our projects have ranged in size from a single volunteer downloading the data to a small-but-critical site, to over 100 volunteers stepping forward to acquire terabytes of user-created data to save for future generations.
The main site for Archive Team is at archiveteam.org and contains up to the date information on various projects, manifestos, plans and walkthroughs.
This collection contains the output of many Archive Team projects, both ongoing and completed. Thanks to the generous providing of disk space by the Internet Archive, multi-terabyte datasets can be made available, as well as in use by the Wayback Machine, providing a path back to lost websites and work.
Our collection has grown to the point of having sub-collections for the type of data we acquire. If you are seeking to browse the contents of these collections, the Wayback Machine is the best first stop. Otherwise, you are free to dig into the stacks to see what you may find.
The Archive Team Panic Downloads are full pulldowns of currently extant websites, meant to serve as emergency backups for needed sites that are in danger of closing, or which will be missed dearly if suddenly lost due to hard drive crashes or server failures.
群友:
”除非提供非常大的便利,才能单独建立一种新的技术体系。“
作者:
对,至少要提升 1 倍,才能覆盖 学习成本(约 10%,看文档、跑 Demo 等) + 迁移成本(约 30%,改用新的库 API、工具链、开发流程等) + 风险成本(约 60%,万一不行还得再迁回去重新用以前的方式去做)。
假设表数量为 T, 字段数量为 C,不考虑业务逻辑处理(业务逻辑代码处理基本一致,两者用时相当),
APIJSON 在 适用场景 的项目中一般都是 20 倍以上的开发效率提升:
平均 2 分钟配置好一张表的增删改查权限,即可实现各种条件( C! x 每个字段 28 种条件功能 x @combine 与或非 3 种 x 2^C 组合数 的 单表单记录 + 单表多记录 + 结合已配置过权限的其它表各种排列组合 ( T! 个) 总共 C! x 28 x 3 x 2^C x T! 个 细粒度 RESTful 查询接口,
再花 3x1xC 分钟配置增删改校验规则,即可相当于实现了 单表单记录+单表多记录 总共 2xT 个 RESTful 增删改接口,总共用了 2xT + 3xC 分钟开发,然后花最多 5 分钟调热更新接口来热重载配置即可部署生效;
假设一个开发很熟练地同样实现 APIJSON 总共 2xT + 3xC 分钟实现的各种增删改查功能,用 SSM 框架实现 RESTful API,并且还不做任何权限及参数校验,那么
查询需要 平均每表 30 分钟完成单表不带查询条件的 Controller, Service, Mapper, DTO/VO/BO …,加每个字段 28 个功能 x C, 60 分钟完成一个多表关联查询接口,总共 30xT + 28xCxT + 60x2^T 分钟),
增删改(假设用了 Mybatis-Plus 等免写 SQL 封装工具) 需要 每张表在写查询接口实现过的 Controller, Service 中新增对应的 3x2 个方法,约 5 分钟,总共 5xT 分钟,然后假设没冲突且不出错的情况下 推送、合并代码,再顺利重启服务部署到开发/测试环境,一般最快也要 10 分钟。
总结下,只是完成接口开发和自测,不算部署时间,
APIJSON(按慢估计) 相比 SSM(按快估计) 这种传统方式开发总时间对比为:
(2xT + 3xCxT) : (30xT + 28xCxT + 60x2^T + 5xT)
简化为:
(2xT + 3xCxT) : (35xT + 28xCxT + 60x2^T)
假设需要对 1 张表(3 个字段)开发接口,即 T = 1, C = 3 ,那么总时间对比为
11 min(约十分钟) : 239 min(3.98 小时,约一上午),速度提升 20.73 倍!
假设需要对 5 张表(平均每张表 4 个字段)开发接口,即 T = 5,C = 4,那么总时间对比为
70 min(约一小时) : 44.25 hour(朝九晚六 5.53 天,约一星期),速度提升 36.93 倍!
假设需要对 10 张表(平均每张表 10 个字段)开发接口,即 T = 10,C = 10,那么总时间对比为
320 min(约一上午) : 44.85 day(996 工作 3.45 月,约一季度),速度提升 200.84 倍!
假设需要对 20 张表开发接口(平均每张表 15 个字段),即 T = 20,C = 15,那么总时间对比为
940 min(约上班两天) : 1456.57 month(全年无休 11117 工作 239.44 年,接近美国建国至今 243 年!),速度提升 66,939.06(约 7 万) 倍!
假设需要对 50 张表开发接口(平均每张表 20 个字段),即 T = 50,C = 20,那么总时间对比为
3100 min(约上班一周) : 128527386625.93 year(时刻工作、一秒不停也要 1285 亿年,超过宇宙年龄 138.2 亿年!),速度提升 21791611100189(21 万亿) 倍!
为什么表数量越多,开发总时间差距会指数暴增呢?
因为 APIJSON 支持任意表关联组合查询,把随表数量指数暴增的 SSM 框架 RESTful API 开发时间 降到了线性稳定增长!
为什么后面 SSM 开发 20 张表 CRUD 接口的时间需要几百年,50 张表甚至超过宇宙年龄了,实际上也就几个月开发完了啊?
因为实际上需求并不会覆盖 表的所有 CRUD、 表的所有排列组合、字段的所有条件、字段的所有组合。
因为主要是表排列组合导致了指数暴增,所以我们再根据实际情况,把 表的所有排列组合 减少至常规的 两两 排列组合,
那就只有 T! / (T - 2 )! 种情况,SSM 开发 RESTful API 的公式变为:
(35xT + 28xCxT + 60xT! / (T - 2 )! )
而 APIJSON 的公式不变,所以对比为:
T = 1 时:11 : 179
T > 1 时:(2xT + 3xCxT) : (35xT + 28xCxT + 60xTx(T - 1) )
简化为:
T = 1 时:11 : 179
T > 1 时:Tx(3xC + 2) : Tx(60xT + 28xC - 25)
按照一般互联网中小型项目情况可得出以下对比表格:
这还是在使用 APIJSON 实现了权限和参数校验、使用 SSM 框架不做权限和参数校验的情况下!
如果使用 APIJSON 时也不做权限和参数校验(全局关闭),那么根本不用花任何时间,总时长总是 0 !