多提一嘴： á é í ó ú 这样带重音标注的字母/单词/语言，它发音的正确方式就是这个音节音调更高。

哈……？？？？？
这么多年我才第一次意识到这么多人搞不清重音是咋回事





超简单： 频率更高的那个音节是重音。不信你自己频谱分析一下。

我有个猜想不一定对…… 这个分辨音节频率高低的能力是不是与音乐素养有关🤔

所有 PC 系统所有手机系统所有厂商都有自带的 memo 软件，你随便用一个其实都大差不差。

我用的是 google keep ，因为很多年之前我用着的最喜欢的手机是 nexus5 ，从那时候固定下来的

排除 merge.

merge 绝对不能在双向相互合并的两个分支上进行，否则大概率丢代码。 双向相互合并是指同时存在 D->M 与 M->D 两个方向的合并（ merge. cherry-pick 会产生不同 hash 的 commit 所以不会踩三路合并丢代码的坑）


一般这种岔出去比较远了又想统一回来的场景最好的方法是 squash + 重新分岔，但有个缺点是历史可能会丢（因为重新分岔后新的 dev 或者新的 main 就不是原来的了，在非直属继承的那个分支上只能看到一个很大改动的 squash commit ）不过 git flow 发展到你现在这个场面就是没严格遵循或根本就没定好清晰的规范导致的，所以大概率历史对你们来说也不是那么重要，squash 掉也不会不可接受。


我们过去的实践是 dev 分支必须包含主线所有分支上的所有改动，包括 bugfix 但不包括 release-featureA / release-featureB 这种版本特化的 commit. dev 永远保持线性历史，即它不会接受其它分支的 merge ，只接受 rebase. 这样一来 bugfix 也好，feature commit 也好，都会拍平成对等的 commit ，不会结出 merge 蜘蛛网。feature 分支在并入（ rebase ）到 dev 上之前 reviewer 会要求一定程度的 squash, 保证一个 commit 既不太大没法 diff 也不至于太琐碎 spam 历史线。 然后 master 只作为 tag 使用，打 tag 时往 master 上 merge 一份（ dev->master ）打在 master 上。只要保证 master 上不自行产生 commit ，只接受 dev 的合并，它就永远不需要解决冲突

说了这么多， 只字不提你「心目中的原型」的关键定义是什么


- 是一个可交互的「类产品」页面？
- 是其它维度（数据结构、逻辑流程）的抽象？
- 是一个可参考的包含核心 story 的 demo ？（例如竞品或示例代码实现的）


我能不能作为产品经理发难说 sb 开发人话都不会说连他要什么都表达不清楚呢，我觉得从你表达方式和情绪来看你们之间的沟通是完全无效的。

- 拿着一千万存款自己瞎捣鼓量化策略，然后每周去收一套房的租金

- 联合一帮几十年的老关系搞投资，名义上挂个 IT 公司的顾问或者董事，实际上只需要出钱收钱看账本

- 不在国内

> 我就想知道，现在程序员的群体里，都已经这样了么？话不能直接说，沟通不能简洁有效 什么都得长篇大论，生怕

这个主题有 2138 个字符长。

BWV 988
BWV 1004

你就不能下个 VS 创建个 winform 项目看一眼吗（恼

？？？？？


还真有没拖过控件的桌面 GUI 程序员？

上手发现两个问题：

- 快捷菜单（ alt+space ）不能 esc 取消
- 全屏状态无法呼出悬浮窗口所以在浏览器的典型场景中这个选字翻译无法工作

其实我不是很喜欢抢着白嫖别人会员，因为总有一种义务感，需要帮别人真的评测出什么东西，提出有建设的观点才好意思试用。 但我确实又比较想关注一下这类产品的发展情况，以及隔壁帖子看两天的回复量也远未达标，确实能算见者有份，那也不算跟别人抢了，所以还是回复一下吧。 希望有机会能一起讨论下产品方向的东西。

我很确信幼儿时期的味觉和感官系统与成人不同。

我还清晰地记得小学一二年级喜欢买学校周边卖的劣质零食，其中有一种五毛钱的小作坊香肠，它闻起来是臭的。
没错，小时候闻着就已经是臭的。但由于放了大量的增香成分，那时候的我们顶多心存一点点顾虑，并不觉得入口有多难吃，虽然没敢吃多，但起码感觉上是可食用的东西。


—— 臭肉制成的香肠，你敢想象现在的你吃得下去吗？

windows

首推 c# winform ，既能所见即所得，又是 C 系语言，语法规范下限低上限高还很易懂

全局键鼠钩子+全屏窗口搞定

#7 +1:

method exceptionCaptured() {
try {cleanByTask()} catch(CountLimitExceeded){}
}

#4
> 抛出个 Runtime 异常，最外层捕获处理，当然这个是旁门左道，正常还是多层 return 吧。

不是旁门左道，这种不就是 recoverable exceptions, 抛异常是对的

> 登录的业务本质是什么？就是验证身份，成功之后开启一段会话

明明你「理解」了本质，怎么还能想出这种结论。


假设你们的系统真的能先收到登出再收到登录，登出的时候，会话在哪？





> 么当先收到登出消息时，无非就是发现这个会话没有开始时间么，但是他确实是一个存在的会话啊，没有开始时间就没有好了

哈？ REALLY? 你是凭什么认为这个登出消息能是一个合法消息的？