V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  jjwjiang  ›  全部回复第 5 页 / 共 8 页
回复总数  156
1  2  3  4  5  6  7  8  
2022-04-27 16:15:01 +08:00
回复了 itechnology 创建的主题 程序员 电商项目在简历中已经烂大街了
哈哈哈,我来补充下特点

1. 不知名,完全没听过的那种,功能也平平无奇
2. 分布式微服务消息队列多级缓存 AUTH2 容器等等想得到的组件都有
3. 项目周期都是飞一般的速度,半年 1 年就做完了,自己还涉及了所有的模块

现在一眼就能鉴定出来了
2022-04-27 15:36:31 +08:00
回复了 mooczz 创建的主题 生活 最近没事,聊聊一个潜在丁克的心态和状态
@tool2d 或许你没注意,我原文就是这么解释养老的,除了物资和身体上的问题,更大的问题是精神需求,和你的说法是一样的。
2022-04-27 15:34:02 +08:00
回复了 mooczz 创建的主题 生活 最近没事,聊聊一个潜在丁克的心态和状态
@westoy 养子女出来是不是孝顺,除了概率问题也有自己操作问题,确实如你所说子女并不能 100%保证自己养老,但是从概率上说有子女应该是远远压过丁克的,即使是护工也是欺软怕硬(你说的这个点也是我认为科技不够发达的后果)。
而且从我观察来看,即使是子女不能时刻陪伴老人,但是只要关系还在,老人是有精神寄托的。这根玩网游很像,自己的角色茁壮成长,即使不能随时随地玩,还是会获得满足感。
2022-04-27 14:26:46 +08:00
回复了 mooczz 创建的主题 生活 最近没事,聊聊一个潜在丁克的心态和状态
我不会从道德或者大道理之类的方面来说这个问题哈,只是纯理性的思考。
结论是:以目前的科技水平,丁克不合适。
丁克最大的问题也是最绕不过去的问题就是养老,养老我认为分为两个阶段
1 是中老年时,此时身体尚可,但是精神世界趋于贫乏,此时有子女则是人生的一个寄托和盼头,真的很少看见中老年时还有能让自己全身心投入的爱好(我觉得主要还是身体和大脑上的物理变化造成的),以前我也觉得不可能,但是看到越来越多的网瘾青年变成了电子阳痿,我不得不考虑这种可能性。

2 是老年时,身体和精神都大大衰退,此时除了精神寄托,还需要物理帮助,没有子女靠金钱驱使护工,那想有尊严的终老简直是比中彩票还难。

而这些问题我觉得都是科技再往前一步就能解决的,虚拟现实能够解决精神寄托的问题,医疗的进一步发达和自动化的普及能解决物理上的问题。

因此如果我的下一代选择丁克,我是完全能接受的,但是在现在这个时代我觉得丁克属实不是很理智的决定。
2022-04-22 10:56:36 +08:00
回复了 yukinotech 创建的主题 React react immutable 相关困惑
用 hooks 模式的时候,setState 以外的方法能够修改到真正的 state 吗?

说实话我觉得没必要纠结这一点,setState 之后就变成了新的 state
2022-04-20 15:39:06 +08:00
回复了 zilan 创建的主题 程序员 片面感觉前端(有一部分)是在提高入行门槛
我感觉说这话的是根本没从上古时代开始干过复杂前端项目的

在 js 和 jq 时代我不止一次造过乱七八糟但是功能和现代前端框架类似的轮子

你觉得现在的前端太复杂了,是因为复杂度本来就摆在那里
2022-04-20 13:36:05 +08:00
回复了 Red998 创建的主题 程序员 大佬们问个排序问题
不就是一个自定义比较器吗?把你的逻辑写在里面传给排序不就好了

排序本质就是 2 个元素如何比较

不过你这个逻辑感觉描述的很混乱,A 值=0 ,指的是比较的 2 个对象的值 A 都是 0 还是有一个为 0 ?
如果你能精确的明白你哪些 dom 操作会触发重绘,所以能够合并这些操作,那肯定是有性能优势的

问题是没人能做得到
2022-04-20 11:21:13 +08:00
回复了 pupboss 创建的主题 全球工单系统 用腾讯会议教老妈用网商银行,然后被封号了
哈哈,在这种社会达尔文+自利主义横行的地方,谈到牺牲权益来保护弱势群体,就跟粪坑里扔了块石头一样。

境外诈骗横行监管不力?关我吊事我又不会被骗

境内严格风控保护弱势群体?我 CNM 侵犯我隐私……大棒……调教……
2022-04-20 11:11:46 +08:00
回复了 summersnow521 创建的主题 北京 不生孩子立省 90% 以上生活烦恼,你们怎么看?
现在的科技程度还不足以让人理性的作出不生孩子的决定

真到了脑内科技发达,护理机制完善的时候,一个人也能够体面的度过晚年,丁克才能变成一个可选择的项
2022-04-18 16:00:45 +08:00
回复了 13936 创建的主题 随想 自从不用百度以后,人生都轻松了。以前真是给自己找罪受。
我都不想从道义上谴责百度

就说说百度贴吧吧,中文 bbs 的始祖吧,无数人的网络初始记忆,汇聚所有论坛入口于一处,这在移动时代是多么恐怖的事情?

而百度在远古时代就做到了,不比 QQ 开局差吧?

结果天胡开局整成了这样……

真的太蠢了……
遍历有啥不优雅的……直接用 array 的 api 呗

说实话我不是很明白一边觉得遍历不合适一边想着反复序列化反序列化……序列化的开销和不优雅程度可比遍历大多了……
2022-04-14 15:14:27 +08:00
回复了 rv54ntjwfm3ug8 创建的主题 程序员 各公司 API 接口设计观察
建议看看 github 的
2022-04-13 14:50:50 +08:00
回复了 dunhanson 创建的主题 程序员 为什么要区分不同的 http 状态码?想说服同事
@james2013 你这说法就不太对了,显然在现代前端里 promise 广泛使用的情况下,catch 比 if(res.code ==200)的语义化和代码结构更佳。
2022-04-13 14:34:10 +08:00
回复了 dunhanson 创建的主题 程序员 为什么要区分不同的 http 状态码?想说服同事
@daimubai 同意,真不知道搞技术的也这么多一根筋的。

拿 400 和 422 举例,422 可以很容易的覆盖一部分业务错误,所有参数上的不合法都可以归到 422 里,对监控更容易,跟别的合作伙伴做对接也更简单。

比如 request 定义是
{ n:int, s: string}
而 n 要求大于 0 ,s 要求不能为'',那么
{'1'}
就会对应到 400
{n:'1',s:1}
{n:-1,s:''}
对应到 422
而 n:1998 会造成业务上出错,那自然是以 200+message 返回

界限很清楚也很好用,422 我就去检查参数值,400 就检查参数格式,而 4 开头的都会被浏览器认定为 client 错误,事实上也确实是作为 client 的调用方有错误,不挺好吗?

rest 规范你觉得不合理就选择使用就完了,全盘否定或者全盘肯定都是不现实的。
2022-04-13 14:23:16 +08:00
回复了 szxczyc 创建的主题 问与答 疑惑:为什么过了一个月自己写的代码都忘了
没有这种感觉,关键的代码几年了我都能想起来,不关键的想不起来也无所谓,只能说是记忆方式的不同,我回想一个很久以前的代码是通过上下文联系回忆的,当时遇到的问题,解决的思路,遇到的困难,最后的方案,总能有线索让你抽丝剥茧的想起来。

如果纯靠心智去记忆代码片段那肯定是做不到的。
2022-04-07 16:12:02 +08:00
回复了 TWorldIsNButThis 创建的主题 React 怎样适应从手动请求数据到使用 hook 请求库的思维转换?
个人一个最简单的模式

`function useApiQuery<T>(endpoint: string): [T | undefined, any, boolean, (parameter?: any) => void] {
const env = useEnv();
const [data, setData] = useState<T>();
const [error, setError] = useState();
const [loading, setLoading] = useState(true);
const trigger = (parameter: any | ((parameter: any) => any)) => {
const parameters = parameter instanceof Function ? parameter() : parameter;
setLoading(true);
axios.get(endpoint, { params: parameters })
.then(res => {
setData(res.data);
setLoading(false);
}).catch(err => {
setError(err);
setLoading(false);
});
};
return [data, error, loading, trigger];
}`

hooks 里自带状态,所以如果你真的需要管理请求数据的状态可以在这个 hook 里管理,或者再用另一个 hook 来专门管理并且协调 query 的 hook
1  2  3  4  5  6  7  8  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1055 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 34ms · UTC 19:14 · PVG 03:14 · LAX 12:14 · JFK 15:14
Developed with CodeLauncher
♥ Do have faith in what you're doing.