重要的不是怎么生成，而是数据源在哪里，怎么管理

https://github.com/google/re2

RE2's native language is C++.

The Python wrapper is at https://github.com/google/re2/tree/abseil/python
and on PyPI ( https://pypi.org/project/google-re2/).

A C wrapper is at https://github.com/marcomaggi/cre2/.
An Erlang wrapper is at https://github.com/dukesoferl/re2/ and on Hex (hex.pm).
An Inferno wrapper is at https://github.com/powerman/inferno-re2/.
A Node.js wrapper is at https://github.com/uhop/node-re2/ and on NPM (npmjs.com).
An OCaml wrapper is at https://github.com/janestreet/re2/ and on OPAM (opam.ocaml.org).
A Perl wrapper is at https://github.com/dgl/re-engine-RE2/ and on CPAN (cpan.org).
An R wrapper is at https://github.com/qinwf/re2r/ and on CRAN (cran.r-project.org).
A Ruby wrapper is at https://github.com/mudge/re2/ and on RubyGems (rubygems.org).
A WebAssembly wrapper is at https://github.com/google/re2-wasm/ and on NPM (npmjs.com).

另外 Go 标准库的正则也是参照 re2 的

svelte 是挺好的，之前看了某横向测评试水了 ryansolid/solid 。综合风格我会建议 vue 选手看前者，react 选手看后者

这样讲吧，你觉得你未来半年一年在哪些方面能有所成长？

把这些地方当成缺点写下来就行了

试试直接在 3468 焦点上 shift f6 （ refactor ） rename 应该就会连着 import 一起修改，如果效果不对试着搜动作搜一下 rename import alias 之类的关键词

搞清楚 M+N 复杂和 M*N 复杂就行了，很容易证明理论最小复杂度就是 M+N

两种都做了，最后放弃了用 binding🙈

骚操作是加上联合 unique 索引配合严格自增的版本号（或微秒时间戳什么的），先 insert on duplicate update 版本号=x，后 delete 版本号<x

不存在合同到期离职更好的说法，不如说两个一样的候选人一个说原因是到期，另一个说是个人发展且逻辑清晰，我绝对不会要合同到期的那个

另外，合同到期前公司必须找你续签或提前通知不续签+赔偿。不续签你照常工作=不签合同用工，不让你工作=非法解除劳动合同

如果是非科班选手补课，我会觉得学算法不如学数据结构，学数据结构不如学编译原理

经验上看，五年经验的人评价自己工作没什么挑战，有可能是在瓶颈期，而三年以内的张口没挑战，基本上是眼高手低或者平时工作 0 思考

做前端是切图仔，接入是二倒把子，后端是 crud，数仓是导数据的，算法是炼丹的，召回算什么？给炼丹的打下手上山采药的吗？ 懂行的人吐槽自己的工作是自嘲，门道都没摸到就做出结论的话，那就到此而止了

编译器+标准库 /runtime 能算的
程序+数据嘛 :doge:

如果是代码的话，ag （ the silver searcher ）

"shell 编程对于服务器开发(人员)很重要"
“看资料大量练习 shell 编程可以提高 shell 编程能力”

这几个隐藏的命题我觉得都是值得商榷的

甚至

“shell 可以编程”

我觉得某种角度来说也不成立 :doge:

安利 https://patchbay.pub/ 无界面 二进制安全 直接用 curl 或者其他 http client 对接

@Sunyanzi

？额我说“写到吐”就是指这种写法基本操作，不是说有什么更好的，不如说就是因为一个奇怪的语法糖却没啥更好的替代品所以才看到烦……
还是我没理解对你的疑问？

关于时代新老的问题，主要是慢慢单入口框架或者不把无关文件放在 public 的做法更常见了，所以就不需要这句话了，composer psr 的话就更不用了，psr 规定了声明类的文件不能有副作用

我说的是这个用法是特指什么 IN_DISCUZ 之类的，用一个常量存在性确保文件不被 webserver 错误地执行的用法，否则不会 or die 的吧，还是你说的以后用的更多是$x = defined('XX') or 'default value'; 这种？ 这种的话确实随着严重级别上调，用的更多说得通……虽然我是 NOTICE 当 bug 修的选手