@YulChigga #19
开发票为啥要短信下发啊
税务局全电发票刚开始时候 对二开商都有个培训
短信下发填报这种方式那时候就是不建议方式
网站/app 类在线服务 建议是在线填写信息直接回来下载

线下经营场景, 建议是扫实体静态码填写信息返回交付码,或者水单上的包含信息的动态码自扫自开

@wasaibi12345 #14
因为国内实名认证的要求
而普通公司又没有四要素银行卡这种金融级别验证的要求
网安给你发协查指令, 要你提供实名信息时候, 你给他个手机号让他们自己查去, 就行了

前端的毛病
大型系统都是在前端消耗用户计算力来做这些事儿 甚至那些 join 操作都是两组数据给到前端循环交叉

@june4 #21
你只能理解 CPU 内存是资源
理解不了网络也是资源吗?

网络路由的处理能力
信安的处理能力
这些也要共享的

这不是故障

轻量, 尤其是活动轻量, 母鸡资源共享超级离谱的 无论是计算资源还是网络
这都是正常现象

轻量就是娱乐用的 不适合做任何业务使用

每天 100G 在我这都看不出来被盗刷了...

我作为架构的时候

按照 V2 的标准

我让很多人把 v2 推崇优雅代码改成了逆天的代码

比如把简单语法改成了满屏幕的 if else/switch

@t00t00 #26
这思路真棒!

@mohumohu #24
跟文盲讨论学术问题很有成就感吗...

@wzw #1
河源是标准 zone 没啥问题的 尤其是做两地三中心 三地三中心的都挺刚需的

在 sni 的域名后面发送额外的点?

@ferock #15

你这说法有问题...
节气和公历的关系是因为他们都依托纯粹的 "太阳历" 所以会有高度的一致性对应性
现在的中国人有多少能用纯农历不依托公历计算节气是哪一天的?



以下我说的是纯个人观点 从目前学术定义看是完全错的:

我们总强调农历是阴阳合历,其实现在的公历本质也是合的很弱的阴阳合历...

我们的农历历法, 按照年=太阳公转, 月=月亮公转, 日=地球自转的基本规则由来
是存粹的天文历法, 可以不依赖"规则"直接从物理的手段结合记录读出

农业生产指导是要精确的太阳历的,因为非热带地区,本质农业是看天吃饭,注重是积温,最低温,概率温度范围,所以指导农业的必然是纯太阳历.
节气也是可以用日晷存粹读出不依赖"历法"本身的



然后就遇到了一个比较麻烦的问题, 就是年月日无法整除.
这就是"规定历法"本身的意义, 我们的农历的规则是"以月为中心,通过指导农业生产的节气调节置闰(节气的本质就是太阳历了)" 这就是农历是阴阳合历的由来

我们的农历就是 以太阴历为基础规则,确保月相与月内日序的绝对对应, 用阳历去修正阴历循环的一年日期不够的问题, 同时用阳历的修正使得阴历的"月份"与实际气候的偏差不至于太大, 让月份的数值有了存在的意义, 虽然不如以太阳历的月份那样对气候的描述那么精确,也不至于歪太多. 就是以保"月"的精确性,通过规则调整年的精确性.

相对的反例就是伊斯兰历,他们是纯太阴历,他们的"月份"本身已经没有了循环上的实际意义.

依托阴历的国家,包括封建社会的我们, 以及伊斯兰教之类,都是对玄学有崇拜的,要么迷信(我们的封建王朝多信这个不用我多说了吧),要么宗教

话说回去西方立法, 他们是依托太阳历, 以保"年"的精确性,去调整月,因为月相对于科学社会的影响基本只有潮汐了, 属于普通非靠海吃饭的人的无所谓的东西, 直接忽略了修正月, 让月相与月的日序完全无关, 只保留了基础概念, 就是比较弱的合历

@phrack #1
打赏一发 要不要修改一下 做个新版脚本

做个屏蔽用户的脚本 集体维护 把币圈 V 站 ID 都屏蔽掉...

我找个 ai 跑一圈 v 站帖子生成币圈赌狗的 id 列表公共屏蔽

还有那些舔着脸发帖求空投的也算上

我从来不要任何培训班 看教程的

非科班的里面非兴趣的 最终的高度绝对有限
完全打不过自学的

@wegbjwjm #17
我觉得屏蔽节点不如更激进一点

OP 啥时候做个带云服务的 把币圈用户全屏蔽了这功能才是需要的 而不是空投这些主题