V2EX › jybox 的所有回复 › 第 3 页 / 共 63 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7 8 9 10 ... 63

❮

❯

2022-12-07 11:23:59 +08:00

回复了 satoru 创建的主题 › 问与答 › 求助：寻找多拉 A 梦里关于漫画家的一集

https://doraemon.fandom.com/zh/wiki/危險！獅面人！?variant=zh-hans

2022-12-06 18:06:06 +08:00

回复了 ksc010 创建的主题 › 问与答 › Linux 下有没有很方便的 nginx 站点管理终端工具

https://github.com/perusio/nginx_ensite

其实也只是一条命令而已

sudo ln -s /etc/nginx/sites-available/mysite.com /etc/nginx/sites-enabled/

2022-11-10 19:38:42 +08:00

回复了 asanelder 创建的主题 › 问与答 › 没有 party 的全民投票?

两 party 制其实就是「拉拢一半的人、去反对一半人」的过程，从博弈的角度来说这样做是最高效的（以少数去反对多数是没意义的，而单纯地服从多数又没法充分体现自己的诉求），在这个拉拢（结成 party ）的过程中人们才会清楚自己的哪些主张是不能让步的、哪些是可以舍弃的。

或者说不管有没有 party 的这种说法、这种组织，经过充分的博弈后，人们最后一定是分成两派。

https://wiki.mbalib.com/wiki/位置博弈

2022-10-21 11:48:41 +08:00

回复了 Features 创建的主题 › 问与答 › 一天的摸鱼，探索出一个卧室终极隔音方案，住高层也不怕邻居了

@ungrown 因为高层邻居数量更多呀，如果是装修的话，哪怕上下隔了七、八层一样非常吵。

2022-10-20 11:43:01 +08:00

回复了 lidayl 创建的主题 › Apple › 关于苹果的 mini 系列

现在手机已经是存量市场竞争了，虽然从销量来看 mini 卖的不及预期，但苹果肯定也不会放弃这部分小屏用户。我个人的猜测是以后会隔代更新 mini 或 SE 改成 mini 的模具，来覆盖小屏用户。

2022-09-24 15:25:06 +08:00

回复了 humbass 创建的主题 › Node.js › 比较好奇大家时间都是怎么存数据库的

大多数据库的时间类型，都是收到带时区的时间后，内部转换为不带时区的时间存储（一般是 UTC 时间戳），在客户端查询时再根据客户端的要求转换到指定的时区显示，所谓「时区问题」只是读写时数据库或客户端 library 没有正确配置。当然如果业务需要关注每一行数据的时区的话，可以单独用一个字段来存时区。

2022-09-23 13:24:12 +08:00

回复了 lerefe 创建的主题 › 问与答 › 自问自答，为什么用苹果？

只提一点的话是「垂直整合」，业界只有 Apple 一家是从硬件到软件到服务全部自己做的，使得它能够自己把握迭代的方向（而比较少受软硬件供应商的影响）、贯彻一致的体验，楼主说的应用规范其实也是垂直整合的结果。

2022-09-16 14:14:27 +08:00

回复了 kylelau 创建的主题 › Android › 大家来看个有趣的事情吧，统一推送联盟疑似凉了

@icyalala 可以看一下规范文件的内容，推送服务器是由设备厂商（小米、华为）提供和维护的，并不存在一家服务去负责所有厂商设备的推送。现在本来这些厂商就都有自己的推送服务器，只是 API 各不相同而已，这个统一推送联盟是在对 API 进行标准化、提供统一的 SDK （仅客户端），并不是要自己维护推送服务器。

2022-09-14 18:41:00 +08:00

回复了 tangyujing99 创建的主题 › 奇思妙想 › [突发奇想]这里大佬多，聊天软件有没有这种非紧急的留言功能（类似反向钉钉）

固定的人的话，可以建一个群，关掉消息推送

2022-08-24 13:02:46 +08:00

回复了 dreamer8933 创建的主题 › 问与答 › 中国联通营业厅人员擅自增加新的服务导致手机欠费停机，我是否应该报警？

警察不管经济纠纷的，只能走司法（起诉），当然起诉之前可以先去主观部门投诉（就像楼上大家建议的）

2022-08-16 19:29:31 +08:00

回复了 zhouxinle 创建的主题 › 奇思妙想 › 想做一个针对一个话题进行正反方辩论的网站， App

https://www.kialo.com
https://github.com/arguman/arguman.org ( https://web.archive.org/web/20200303065756/https://ch.arguman.org/ )

2022-08-02 14:14:36 +08:00

回复了 weakish 创建的主题 › Apple › Apple ID 的双重认证有点「把鸡蛋都放在一个篮子」里的感觉

- SIM 卡一定要设置密码
- Apple 设备越多、种类越多越好（最好能放在不同的地方）
- iCloud 因为不提供历史版本，所以不适合作为可靠的、唯一的存储服务

2022-08-02 12:01:11 +08:00

回复了 sivacohan 创建的主题 › 问与答 › 看看生活里有多少蓝光

应该从来源上减少蓝光，具体来说就是各种电子设备的夜间减少蓝光的模式（ Night Shift ）。防蓝光眼镜一天 24 小时不管看什么都过滤蓝光是一件很奇怪的事情。

2022-07-13 14:36:00 +08:00

回复了 7RTDKSAK 创建的主题 › 若饭 › 懒人适合若饭吗?

买过很多次若饭，原味大概就是「特别浓稠的豆浆里加了少许盐和油」的味道，应该说单独喝一口并不算难喝，但如果喝一瓶的话可能确实很多人是不太能接受的。

我觉得若饭（液体版）很适合备在家里或办公室，用于那种必须得吃点什么补充能量，但没有时间或没有胃口的情况。至于你说适不适合懒人，就看你对食物的口味要求如何，如果懒到没有要求，那是可以考虑一天中一顿饭或两顿饭用若饭代替（官方也是这样建议的，不建议一整天只喝若饭）。

2022-06-20 13:46:26 +08:00

回复了 easonl 创建的主题 › MacBook Pro › 买新 Macbook Air 到底是选大内存还是大硬盘？又听到这种话题。

我就是认为应该优先加内存的，确实有很多人是喜欢把所有程序都一直开着的（否则等待一个程序启动是对思路的打断）。应该多加的内存几乎总是在发挥作用的 —— 就算你没有开很多程序也会被用作文件系统的缓存，提升整体性能。

而对于大部分人的场景（也包括大部分开发者）来说，平时只会用到硬盘上数据的很小一部分，而 Mac 提供了相当高规格的 SSD ，用来存储冷数据完全是一种浪费，加硬盘的钱完全可以省下来搞更大容量的 NAS 或外接硬盘。

至于我认为什么人需要优先加存储：使用场景确实需要同时用到大量的文件、喜欢囤积数据又不喜欢整理、确实不愿意外接硬盘或折腾 NAS 。

2022-05-05 18:30:56 +08:00

回复了 dzdh 创建的主题 › Go 编程语言 › 苦于没有异常，怎么优雅的捕捉三方包里的 panic

https://gobyexample.com/recover

2022-04-21 15:09:49 +08:00

回复了 Ourobotos 创建的主题 › 奇思妙想 › 绕过无线基站的通讯 APP

业务无线电 => 业余无线电

2022-04-21 15:09:18 +08:00

回复了 Ourobotos 创建的主题 › 奇思妙想 › 绕过无线基站的通讯 APP

@graetdk 业务无线电不允许加密的吧（亚音不是加密或鉴权），为什么说保密性很好。偶尔用一下确实很难追踪，但如果一直在（违法）发射信号的话，无线电管理部门还是能基于信号发射的位置找到你的。

2022-02-18 12:04:09 +08:00

回复了 CX330 创建的主题 › macOS › Mac Os 各位同学都用什么卸载软件？或者有什么好的卸载软件推荐？

用 Homebrew 来卸载

即使你的软件不是用 homebrew 安装的，你也可以用它来卸载（加 --force ），还可以加上 --zap 让 homebrew 把所有关联的数据文件都删除（可以用 brew cat 查看具体包括哪些文件），如 brew uninstall --cask --force --zap zoom

https://pbs.twimg.com/media/FABwbTiVQAgZPrG?format=jpg&name=large

2022-02-10 18:25:40 +08:00

回复了 xiqingongzi 创建的主题 › 问与答 › 一个开发者产品下线怎么样才能足够优雅

对于开发者服务来说，每个 API 、每个参数都有大量的细节，和面向终端用户的产品很不一样。图形界面改了，用户自己会去适应，但调用 API 的程序不会自己适应，还是要开发者来改。

对于类似 LeanCloud 这种提供了十多种不同语言 SDK 、上百个 API 接口、加一起可能有几千个参数的服务来说，其实「下线功能」这种事情是经常会发生的。

对于客户端来说，能做的就是尽量遵守 Semantic Versioning （语义化版本号），把不兼容改动都放在 major （大版本）的更新里，甚至提前几个版本就开始打印警告，对于不兼容的改动提供详细的迁移文档（应该换成哪些 API 来替代）；要及时在文档和 Demo 中将即将废弃的接口去掉，如果整个 Demo 都不再支持的话也要在 GitHub 上修改 README 后 archive 掉。

对于服务端来说接口一旦下线就彻底无法使用，通常要更加慎重，比如需要在客户端去掉该接口比较长时间以后、从监控看到接口的使用量很小的情况下再下线；提前将功能的入口（如文档）去掉，避免新的开发者使用。

确实有时候迫于业务方向或者法规要求，还是会有一些比较生硬的「下线」，但无论如何还是要将这个事情提前通知到开发者。如果只是一个小功能最好能精确通知到受影响的用户，通知的时候态度还是要坚决，要约定明确的下线时间，否则开发者不会当回事；如果是整个产品的下线则应该有公开的公告，最好是能由 CEO 或者高层负责人在其中介绍一下前因后果。

对于涉及数据的应用要提供导出数据的方式和文档；涉及到费用的要为开发者退款，最好是在「从通知到下线」这个过渡期不再收取费用。

说到服务下线有个有趣的做法是「提前下线一小段时间来起到通知的作用」然后再恢复给开发留出迁移的时间，GitHub 就曾经这么做过 https://developer.github.com/changes/2018-11-05-github-services-brownout

1 2 3 4 5 6 7 8 9 10 ... 63

❮

❯