V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  bwangel  ›  全部回复第 5 页 / 共 32 页
回复总数  626
1  2  3  4  5  6  7  8  9  10 ... 32  
2021-09-19 15:51:34 +08:00
回复了 EyreYoung 创建的主题 Android 父亲过生日给他买什么手机?预算五千以内
华为吧,华为在中老年圈子里还是很受欢迎的,而且用起来体验也不错。

不过华为的问题就是缺货,5000 左右的中端手机更是缺,可能不太好买。
@bwangel #14

#14 楼的答案对,剩下的 6*20 中,还可以横着放置两个

所以总数量是 28000 + 568 + 2 = 28570 个 剩余面积 1*20 + 6 * 5 = 50 平方厘米

----

由于其他面积都可以被铺满,所以这个问题可以简化成

20 * 20 的正方形里,最多可以放多少个 5 * 7 的矩形

目前找到的答案是 10 个,剩余 50 cm^2 的面积。
@oneforallsoft

#10 的答案我写错了

横铺 200 * 140 共 28000 个
竖铺 142 * 4 共 568 个

这样一共可以铺 28568 个,剩余面积 6*20 = 120 平方厘米
2021-07-03 12:47:54 +08:00
回复了 wenzaiquan199 创建的主题 职场话题 给期权的公司究竟要不要待下去
期权的主动权在老板手上,老板有 100 种合法的方法不兑换期权。

https://github.com/shengxinjing/programmer-job-blacklist#%E6%8A%80%E6%9C%AF%E5%90%88%E4%BC%99%E4%BA%BA

这里还有一些没有列出来,B 站戈君,美团 https://www.huxiu.com/article/263913.html

所以拿期权就是在老板人品上下赌注,如果你认为老板这个人的人品不值得你信赖,那么就把期权当废纸吧。
横铺 200 * 140 共 28000 个
竖铺 14 * 4 共 56 个

这样一共可以铺 28056 个,剩余面积 40 cm^2
商品的价格由价值决定的,因供需关系围绕着价值做上下波动,

劳动者工作就是售卖劳动时间这件商品,但劳动时间这件商品比较特殊,

1. 它可以通过货币以外的其他形式购买,这部分购买力无法以价格来衡量。
2. 劳动时间的价格主要和供需有关,和其本身价值没太大关系。

互联网产业易形成垄断,利润率高,大量资本涌入这个行业。需求方多于供应方 ,导致程序员的劳动时间价格高。
@wellsc

额,是的,有什么更好的方案可以推荐一下吗?我用过 swagger,但它没办法要求客户端,感觉是一个交互式的 Markdown 。
2021-06-12 22:26:40 +08:00
回复了 zhanbiqiyu 创建的主题 随想 找不到自己每天活着的意义
每当听毛不易《像我这样的人》,就会有这样的体会。

小时候曾以为自己会改变世界,现在才发现,我真的好普通好普通好普通啊。
很多回复里都说 protobuf 的优势是编译后数据体积小。但我觉得这不是一个主要的优点,文本内容的压缩率很高的,Nginx 开启 gzip 压缩后,json 响应并不一定比 protobuf 响应要大很多。

我觉得主要优点就是强制性,定好一个规范后,通信的双方必须完全遵守它。

JSON 也可以做到这一点,但没有跨语言的解决方案,例如 21 楼老哥说的 rust 的 serde 就可以做到,但它不能跨语言,前后端无法使用同一份约束文件,那维护协议还是得靠 Markdown,还是不靠谱。

支持这几种主流语言( Java,PHP,Python,JS,Object-C,Swift,C++, Go )的数据序列化解决方案中,protobuf 是最好的选择。
@wellsc

这不仅仅是后端的事情,而是前后端要共同维护一份协议,告知双方现在在用哪些字段。维护一份 proto 文件,比维护一个 Markdown 文件要可靠的多。
@12101111

这不是语言的问题,这是程序的设计问题。前端版本由 V1 升级成了 V2,它们说不用 A,B,C 三个字段,这时候更新文档,告知后端,这是不可靠的,没准后端忙就忘了,反正也不会出错。如果前后端共用一份 protobuf 文件,那么就会强制后端更新接口,如果不更新会出错。

另外顺口问一句,哪家公司的 web 接口是用 rust 写的,让我膜拜一下。或者不一定是公司,哪个网站是用 rust 写的,让我膜拜膜拜。
@wellsc json 真的一点都不香。

前端要什么,后端就返回什么,一个字段不许少,一个字段不许多。

“一个字段不许多”。这一点很多接口都做不到。
2021-06-11 09:38:38 +08:00
回复了 googlehub 创建的主题 随想 今天是我的生日🎂🎂🎂🍰🍰🍰
生日快乐。V 友
2021-06-06 23:36:37 +08:00
回复了 fantastM 创建的主题 全球工单系统 B 站把我的用户画像记录得是有多饥渴?
原来我不是一个人

深受交友广告之害。
2021-06-03 14:00:33 +08:00
回复了 liyaojian 创建的主题 Go 编程语言 大佬们求解一个 go map 无序的问题
如果这是个语言问题,我比较赞同 8 楼的做法,gjson foreach 输的 json key,value 对是按照解析顺序输出的,比较满足你的需求。

如果这是个工程问题,我不建议使用 "github.com/tidwall/gjson",因为这样写了之后让代码更加晦涩难懂了,不利于维护。

在 json.encoder 一方看来,调整 json 中 map 的顺序完全不会有什么影响,因为这样做是符合 json 规范的,但是一调整就挂了。解决方案就是需要在代码中写个注释,说明顺序千万千万不能改,但是我们都知道,注释是及其不靠谱的,很多时候代码和注释完全对不上。

所以我的建议是

在 json 数据中加一个 order 字段,表明期望得到的顺序,这是一个示例

https://play.golang.org/p/c2DIY3q_vjR
2021-06-01 13:02:47 +08:00
回复了 xuqiccr 创建的主题 程序员 [水贴]被同事的变量名惊呆了
@bwangel #81

https://www.python.org/dev/peps/pep-0008/#comments

Python coders from non-English speaking countries: please write your comments in English, unless you are 120% sure that the code will never be read by people who don't speak your language.

我说的不太严谨,如果你的注释不会被不说中文的人阅读,那么 PEP8 中也是允许写中文注释的
1  2  3  4  5  6  7  8  9  10 ... 32  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5361 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 40ms · UTC 08:57 · PVG 16:57 · LAX 01:57 · JFK 04:57
Developed with CodeLauncher
♥ Do have faith in what you're doing.