即刻App年轻人的同好社区
下载
【[If you're thinking without writing, you only think you're thinking.】
Writes and Write-Nots
0 00
分享一些 Wiki（主要 Mediwiki） 相关的东西：
简介：
1. Wikimedia 是一个致力于每个人可以自由分享知识的运动，这个运动有个基金会管理，简称 WMF，WMF每年还会公开财报。
2. Wikimedia 旗下托管了很多 Wiki 和项目，Wikipedia 是其中之一。
3. Mediawiki 是这些 Wiki 的建站程序，GNU 协议，由 PHP 开发，代码算上 vendor 都有三四百 MB，大陆知名的项目比如萌娘百科，海外 wikiHow 等。
4. 托管多个 Mediwiki 站的方案叫 Wiki农场，大陆比如 BWiki、灰机wiki，海外有 Fandom 等，这几个大多数财务上看似乎都不赚钱。
5. 游戏行业用了很多 Wiki，比如 liquipedia 等
6. 日本流行的 wiki 比较奇特，基本不是基于 mediawiki 而是基于他们自己的工具，知名的有 game8, wikiwiki.jp等
数据： 从 WMF 公开的数据看，
1. 700 万捐助者，
2. 28 万人参与编辑
3. 每月 150 亿访问量
4. 总资产 3亿美元
5. 2023年大约 1 亿美元用于工资发放，机房托管大约 3 百万美元
6. 2020 年看，雇员（含外包）大约 450 人。
周边项目：
1. Abstract Wikipedia 是一个有趣的项目，其实现在的wiki都是不同语言单独编辑，这个项目致力于发明一种通用语言（像json），这个元语言可以自动生成所有语言，这样就解决了不同语言的wiki内容完全不同的问题。
2. Kiwix 社区的离线App，可以把所有 wiki 下载到你手机里头，离线看。
3. Wikidata 本身也是一个 Mediawiki 站，但是词条的内容模型是结构化数据的 json，实现知识图谱的语义化搜索，第三方的 Dbpedia 也在干这事儿（主要结构化 infobox里头的内容）。
4. Wikidata 提供 sparql 搜索，知识图谱后，比如我要搜索所有货币的发行时间，这个问题就很容易搜索到答案。
代码工程:
1. 这也是为数不多的完全开放大型架构知识的 PHP 项目，可以学到各种大流量下的处理，主要靠 Varnish 对未登录用户页面进行强缓存，通过 Kafka 来清缓存等。
2. 官方以前适配的 OpenStack，对接了 OpenStack 的对象存储，如果想切 S3 可以用插件，现在看也在上 K8s。
3. 清缓存是一个重要的操作，甚至在每个词条的功能工具栏里头有这个按钮。
4. Mediawiki 对 Lua 的依赖很强，Lua 写成的词条的叫模块，模块可以实现了一些比如分类导航，时间日期格式化显示，或者从另一个数据源获取数据等等等功能。
5. 皮肤和插件功能很强大，各种钩子，官方 Vector 皮肤很厉害。
6. Mediawiki 没有路径的概念，URL 结构只有两种，就是 `命名空间：词条名`，路径的 i18n 支持很好，也可以用中文。
7. 这个项目也没有管理后台，所有管理相关的页面都放在 `特殊:特殊页面` 下，一般匿名用户也能访问。
8. `特殊:版本` 可以看到所有安装的插件和一些基础信息。
9. 所有 wiki 下的文件都属于 `文件` 命名空间，都算一个词条。
10. Wiki 词条编辑用 wikitext 语法，语法主打靠模板，模板内可以使用 Mustache 语法，这是非常重要的功能，你可以在编辑一个。
11. Wiki 词条里头是可以编辑 css，js 的，所以也可以说是一个巨大的 CMS，你可以用来建站。
12. 官方使用 thumbor 来处理图片缩放、裁剪，当然默认也可以用项目内的 thumb.php 来实现。
13. 前端挺有意思，jQuery 为主目前主打一个类似 requirejs 的后端结合的方案，叫 ResourceLoader ，进行资源加载，可以按需加载和即时编译。
14. 前端官方组件库之前是 jQuery 为主的 OOUI，未来会切成 Vue.js , Vue.js 实现的组件库叫 Codex。
15. 前端坚持渐进增强，一定能在无 js 环境下使用。
结构化数据：
1. 如果你想做一个带筛选功能的词条列表页，那就避免不了需要引入结构化解决方案，这样系统才知道一个词条的某个属性是什么值，才能参与是筛选，当然这也可以叫知识图谱。
2. 方案有三种，分别是 Semantic MediaWiki （SMW），Wikibase（也就是 Wikidata），Cargo。
3. Semantic MediaWiki，是扩展的方案，走的是知识图谱的那套，数据库用类似 EAV 的方案存储，性能不理想。
4. Cargo, 扩展方案，基于 MySQL，是走动态建表的方式，每个模板可以单独建一张表，比如武器模板对应一个武器表，里头放了所有的武器的属性，词条编辑保存的时候自动更新这张单独的数据表，性能好。
5. Wikibase, 这个就是另外再建一个 Mediwiki 站，然后里头的数据是通过API的方式导入，词条内容就是知识图谱的三元组声明，这个不用来做筛选页，用来做知识图谱。
6. 也有自己用 mongodb 写的，提供个语法，让用户在词条编辑的时候声明词条的属性，比如 liquipedia
简介：
1. Wikimedia 是一个致力于每个人可以自由分享知识的运动，这个运动有个基金会管理，简称 WMF，WMF每年还会公开财报。
2. Wikimedia 旗下托管了很多 Wiki 和项目，Wikipedia 是其中之一。
3. Mediawiki 是这些 Wiki 的建站程序，GNU 协议，由 PHP 开发，代码算上 vendor 都有三四百 MB，大陆知名的项目比如萌娘百科，海外 wikiHow 等。
4. 托管多个 Mediwiki 站的方案叫 Wiki农场，大陆比如 BWiki、灰机wiki，海外有 Fandom 等，这几个大多数财务上看似乎都不赚钱。
5. 游戏行业用了很多 Wiki，比如 liquipedia 等
6. 日本流行的 wiki 比较奇特，基本不是基于 mediawiki 而是基于他们自己的工具，知名的有 game8, wikiwiki.jp等
数据： 从 WMF 公开的数据看，
1. 700 万捐助者，
2. 28 万人参与编辑
3. 每月 150 亿访问量
4. 总资产 3亿美元
5. 2023年大约 1 亿美元用于工资发放，机房托管大约 3 百万美元
6. 2020 年看，雇员（含外包）大约 450 人。
周边项目：
1. Abstract Wikipedia 是一个有趣的项目，其实现在的wiki都是不同语言单独编辑，这个项目致力于发明一种通用语言（像json），这个元语言可以自动生成所有语言，这样就解决了不同语言的wiki内容完全不同的问题。
2. Kiwix 社区的离线App，可以把所有 wiki 下载到你手机里头，离线看。
3. Wikidata 本身也是一个 Mediawiki 站，但是词条的内容模型是结构化数据的 json，实现知识图谱的语义化搜索，第三方的 Dbpedia 也在干这事儿（主要结构化 infobox里头的内容）。
4. Wikidata 提供 sparql 搜索，知识图谱后，比如我要搜索所有货币的发行时间，这个问题就很容易搜索到答案。
代码工程:
1. 这也是为数不多的完全开放大型架构知识的 PHP 项目，可以学到各种大流量下的处理，主要靠 Varnish 对未登录用户页面进行强缓存，通过 Kafka 来清缓存等。
2. 官方以前适配的 OpenStack，对接了 OpenStack 的对象存储，如果想切 S3 可以用插件，现在看也在上 K8s。
3. 清缓存是一个重要的操作，甚至在每个词条的功能工具栏里头有这个按钮。
4. Mediawiki 对 Lua 的依赖很强，Lua 写成的词条的叫模块，模块可以实现了一些比如分类导航，时间日期格式化显示，或者从另一个数据源获取数据等等等功能。
5. 皮肤和插件功能很强大，各种钩子，官方 Vector 皮肤很厉害。
6. Mediawiki 没有路径的概念，URL 结构只有两种，就是 `命名空间：词条名`，路径的 i18n 支持很好，也可以用中文。
7. 这个项目也没有管理后台，所有管理相关的页面都放在 `特殊:特殊页面` 下，一般匿名用户也能访问。
8. `特殊:版本` 可以看到所有安装的插件和一些基础信息。
9. 所有 wiki 下的文件都属于 `文件` 命名空间，都算一个词条。
10. Wiki 词条编辑用 wikitext 语法，语法主打靠模板，模板内可以使用 Mustache 语法，这是非常重要的功能，你可以在编辑一个。
11. Wiki 词条里头是可以编辑 css，js 的，所以也可以说是一个巨大的 CMS，你可以用来建站。
12. 官方使用 thumbor 来处理图片缩放、裁剪，当然默认也可以用项目内的 thumb.php 来实现。
13. 前端挺有意思，jQuery 为主目前主打一个类似 requirejs 的后端结合的方案，叫 ResourceLoader ，进行资源加载，可以按需加载和即时编译。
14. 前端官方组件库之前是 jQuery 为主的 OOUI，未来会切成 Vue.js , Vue.js 实现的组件库叫 Codex。
15. 前端坚持渐进增强，一定能在无 js 环境下使用。
结构化数据：
1. 如果你想做一个带筛选功能的词条列表页，那就避免不了需要引入结构化解决方案，这样系统才知道一个词条的某个属性是什么值，才能参与是筛选，当然这也可以叫知识图谱。
2. 方案有三种，分别是 Semantic MediaWiki （SMW），Wikibase（也就是 Wikidata），Cargo。
3. Semantic MediaWiki，是扩展的方案，走的是知识图谱的那套，数据库用类似 EAV 的方案存储，性能不理想。
4. Cargo, 扩展方案，基于 MySQL，是走动态建表的方式，每个模板可以单独建一张表，比如武器模板对应一个武器表，里头放了所有的武器的属性，词条编辑保存的时候自动更新这张单独的数据表，性能好。
5. Wikibase, 这个就是另外再建一个 Mediwiki 站，然后里头的数据是通过API的方式导入，词条内容就是知识图谱的三元组声明，这个不用来做筛选页，用来做知识图谱。
6. 也有自己用 mongodb 写的，提供个语法，让用户在词条编辑的时候声明词条的属性，比如 liquipedia
4 02
哪里怪怪的。。。。
金数据AI考试
1 00