楼主，你的孩子需要陪伴

我是 15 年换的 MBP，13 寸的。很容易就适应了

A:线不行
B:手机不行
C:车不行
D:人不行

手动狗头保命，逃

vs code 写 SQL 脚本、MD 文档爽歪歪。列编辑模式简直太好用了有木有

这样的需求意义何在？

不是入耳式，外界隔音效果自然不会太好，怎么能降得了噪。。。等降噪的同学都洗洗睡吧，注定等不到的。

结清尾款才可以谈新需求

下拉框列表调用 user_type,city 的 api
前端显示什么，接口就返回什么，前端最好不要自己多个查询拼凑数据，除非是应用的特殊需求。另外，数据的格式化应该由前端处理，如日期格式，小数点对齐等等。

凑合着能用，但极度不舒服。便宜的 4K 电视色彩不行，延时也高，贵的色彩延时倒是可以接受了，但这个价钱。。。又何必呢。

党领导国家是写到宪法里面的好吧，楼上的那几位不要皮了好不好

对象存储，生成 url 客户端直接下载就行了吧

一般靠就寝的闹钟，如果需要早起，喊 siri 设置闹钟

这话没毛病，但这个老板不是刘备啊，他连董卓都不是啊。。。手动狗头保命

已经悄咪咪地打开了

看到这一贴，我瞄了一眼吃灰好多天的耳机，然后拿起来吹了吹灰带上开始听歌并回了这个贴子。

不过大概带不到 30 分钟就该继续吃灰去了，总不能带着耳机和人撕逼。。。。。。能带着耳机工作真是莫大的幸福，能摸鱼就更幸福了。啦啦啦

JSON 类型非常非常非常好用！！！以前需要几十个字段存储的 xx 信息什么的，现在一个字段搞定。特别是一对多的那种，以前是要搞一个明细表存储的，读取多条记录的时候还是挺恶心的。现在也是一个字段直出，不需要联表，也不需要迭代分组处理了。

当然，滥用 JSON 类型，也是会造成很大的麻烦的。

查询的时候是这样的：select column ->> '$.field' from table;

myBatis 直接映射成对象要用这个注解：@Results({@Result(property = "column", column = "column", javaType = XxxDto.class, typeHandler = JsonTypeHandler.class)})

来得及来不及都得学呀，老弟。活到老学到老呢。前一阵子也是把研发团队狠狠折腾了一阵子，现在很多事情终于可以放下去做了。有了时间，就可以重拾代码。年近 50 的我，又能重新体验编码的乐趣了。