顺手搜了一下，不确定是不是最新的……

@shineit 原来如此。之前几年折腾过一次 xcode 开发，证书这些都要手动弄还挺麻烦的。上个月想写了个 SwiftUI 小应用，又捡起来试了试，发现改善了很多，很多配置都能绑定账号自动处理了，还以为现在普遍都这么使用了呢。

如果付费软件的话，Paste 也不是不行……

现在不都是 xcode 管理证书啥的了么？

不如试下正则替换？
1. herry -> herry2
2. jack -> herry
3. herry2 -> jack

@sinux 烤箱，尤其是柜式烤箱，使用麻烦的就是要预热。不像空气炸锅，随拧随用。

空气炸锅蛮方便的，烤地瓜，烤鸡米花，烤三文鱼，烤烧饼，只要是想保持食物酥脆特性又不想开火，空气炸锅都是好的选择。微波炉不行，微波炉加热出来就塌了。

最近淘宝买了点饼胚，炖点五花肉，想吃时拿出来，空气炸锅、微波炉双开，5 分钟吃上肉夹馍，美滋滋。

微信小程序有 wx.scanCode API ，用的是微信客户端的扫码方案。
所以，搞个小程序？
https://developers.weixin.qq.com/miniprogram/dev/api/device/scan/wx.scanCode.html

如果仅仅是 css 框架，其实还是从开发实现角度来看待这个问题。

设计语言的关注的是系统或应用中视觉传达和用户认知的调和问题。

对于设计语言来说，视觉元素都是表义的，是能够通过组合和重复在用户头脑中建立统一认知的。

认知一旦建立，用户使用产品时的心智负担和学习成本就会大大降低。「绿色的通知就是代表操作成功，红色的说明报错失败了」——不用读具体的提示文案用户也能快速做出判断。

而任何对已建立认知的强行修改都会造成用户认知报错，产生负向情绪 。用户从不会认为是自己认知的问题，而是「这个产品 /功能太沙币了」。

看看 iOS 14 时间应用中 DatePicker 样式使用混乱造成的负向反馈（随便一搜的一条，https://www.reddit.com/r/iOSBeta/comments/he4xul/ios_14_changed_the_datetime_picker_in_the/，现在又回归统一了），

再看看 PS5 强行统一各区圈、叉按键功能在主机圈引发的嘲讽。

所以，当有几十个后台，大几百个页面需求要产出，而这些页面又是下游成百上千员工每天面对几个甚至十几个小时的工作环境时，统一的设计语言就太有必要了。

不光是用户侧的考量，开发、设计、需求三方能否在统一的视觉交互认知下，快速沟通、确认方案，进入实现阶段，对于能效高低至关重要。

「是不是好看」真的不是设计语言的核心，锦上添花还差不多。

@xiao109 对的。类似发送系统邮件。

@whywaoxaks 那到确实是。我自己这边通常就 chrome+几个编辑器，还没遇到那么多问题。

哈哈哈，上半年下单 M1 的 Mini ，内存加到 16GB ，Xcode 写写 Swift UI 不说，都敢开 steam 玩玩游戏了说。

@whywaoxaks 那 20%的场景大概是啥啊？

如果只是控制屏幕内元素的选中，推荐 vimac： https://vimacapp.com/
是类似 vim 的 easy-motion 的操作方式。
开了实验功能 electron 应用也可以支持。

兴趣真的是第一决定因素。「不想做这个了」真的不是理由。

本地先将 feature 上那几个修改内容的 commit stash 掉，同步完 dev 再 pop 出来？应该会有些冲突，但都是你的代码应该是比较容易解决的。

@realtozf 也可以从业务项目向公共库抽取吧。这样可能质量和使用场景更有把控一些。支持当前项目后再向其他业务项目的场景扩展。

不然，先公共后业务，除非在开发前跟各方充分讨论，不然很容易产出脱离具体使用场景的「公共组件」。

@shintendo Vue 的 props 设计就只能 anotation 吧？ https://v3.vuejs.org/guide/typescript-support.html#annotating-props

不能像 React 那样 Component<IProps, IState>。

住公司，办张公司附近健身房的健身卡……现在国内也有公用洗衣房了。