@CasualYours 手误："记账 app" -> "Pixiu 记账"

@d873139022 记账 app 一般只专注记录收入和支出，操作也会更简单，各有优劣吧
@ybnsjl beancount 用习惯了，还是文本操作最舒服
@7gugu 感谢推荐，"记账 app" 我电脑上安装的有哈，功能非常丰富，也是很赞的作品。

> beancount 的用户应该主要是程序员吧

@Nasei 我之前也是这个想法，但在写过一篇 beancount 的介绍文章后，也经常收到一些非程序员的邮件沟通。beancount 对于大多数人上手门槛还是太高的。

@wb129945130
@MCVector
@ddllzz
感谢支持 ~

经常登录生产服务器替换文件，以及改生产数据库...

3520 元，还没你买书钱多
https://wx3.sinaimg.cn/mw2000/e2f565c4gy1gxbxxbqboej21h10ne43h.jpg

做垂直领域的社区不知道行不行，类似 V2EX 。

我拍胶片的时候想要和一些同好的人交流，发现很少有胶片摄影的社区（可能太小众了），但我观察下来，豆瓣的几个胶片摄影的小组还是挺活跃的，所以我想一些小众爱好的社区可能用户群少，但是竞争也小，能维持有同好的一批用户，盈利应该不是问题。前提是你必须热爱。

你的这两种方案都有一些问题。

两个方案都没有版本的概念，这样会导致你本次功能上线出现问题后，无法正确回滚至上一版本。方案二不应该在测试后再进行代码合并，测试的永远应该是最后要上线的代码。

我公司通常这么处理的：

- 从 master 拉取 release-xxx 作为本次的发布分支
- 再从发布分支中 release-xxx 拉取开发分支 feature1212
- 至于你两种方案中纠结的到底是两个人共用一个开发分支，还是各建一个，我的建议：你们就两个人，没有必要增加分支复杂度，直接公用一个开发分支即可，至于开发中遇到冲突，可以通过频繁的 pull/push 来解决
- 你两种方案中的 dev 分支我认为也没有起到效果，首先测试代码应该和要发布的代码完全一致才有意义，你这里的 dev 分支没有注明检出来源，feature1212 merge 到 dev ，无法保证 feature1212 和 dev 代码一致。正确做法是你应该 feature1212 合并回 release-xxx ，用合并后的发布分支直接测试
- 测试完成后发布分支 release-xxx 部署线上发布
- 发布后出现问题，如果要回滚上一版本，那么直接拿上一版本的发布分支（你这里是 master ）部署线上；如果要紧急修复，那么从 release-xxx 中检出一个 release-xxx-fix 去重复上面的过程

目标 14700 千卡，坚持了一个月，最后几天功亏一篑了，今天还差 1217 千卡

所以讨论了半天，还是最熟悉的才是最有生产力的

刚了解，下班回去下载看看

我的个人经验就是选择普适性或者理论性的选题。
之前同事讲过芯片制作的过程，挺有意思的。我之前也讲过信息论相关的概念，感觉也还不错。

不破不立! 7777777

燃脂 14700 千卡

下单了辆自行车，希望 1024 年能到手

@spadger #91
@Ziya #95
推荐一下 beancount 。我之前还写了一个给 beancount 提供 server 服务的 node 应用，可以参考下： https://github.com/BaoXuebin/beancount-node-server

感谢分享，原来浏览器设置里的搜索引擎是这么用的

我之前曾经尝试把业务逻辑实现改为链式调用的形式，看上去是舒服了一点。
TaskWrapperProvider.init(wrapperMapper).createWrapper(taskId).signIn(signParams); // 任务签到的需求