「 Medis 1 是 Electron ，不过后来性能上遇到了瓶颈，而且为了模拟系统原生的 UI 花费的精力超过了跨平台带来的便利，」

「所以 Medis 2 用原生技术重写了。似乎还没有用过 Flutter 开发的 macOS 程序」

看 App Store 里面的界面风格都完全不一样。怎么就成了 fork 一个版本二次收费呢。

@JounQin
@zhuweiyou
感觉还行吧，因为当初找的教程用的是 gulp+browserify ，就用下来了，打包属于低频改动的功能，目前还没看到换的好处。

@zhuweiyou
谢谢，按照你说的，搜到了这个: https://stackoverflow.com/questions/39321384/how-should-i-transform-es6-node-modules-with-browserify-and-babelify

通过组合使用 babelify 的 global 和 only ，可以将 graphviz-react 中的 es6 进行转码。

不过这里还是没太搞清楚，1#提到的 esm 规范和 es6 之间是啥关系，babelify 是用来转换不同版本的 js 代码吧。那么模块规范 esm 和 cjs 之间的转换，也是由它完成的吗？

@lisongeee
感谢。目前对前端栈里面的概念还有点模糊，我大概了解你指明的问题所在了。🙏

看到「乘波体」这个概念，总是眼前一亮：真形象啊。

> “知乎体这两年最火热的模式，一种是 『 XX 是一种什么体验』，另一种就是『如何理解 XXX 』。前者迎合消费主义的需求，用来卖货的；后者就是帮你理解世界，把瓜吃上的。”

这不就是人生的意义所在吗？「体验」 vs 「理解」，「感性」 vs 「理性」，说成「卖货」和「吃瓜」有点贬低了。

楼主提到的积分机制，目前看只有对积分「消耗」的介绍，没有「生产」的部分，不完整啊。一套机制，各部分环环相扣，如果不完整就没办法讨论了。

另外，V 站有一些相关的帖子，共享一下：

端午在家，写了一个基于投票机制的自治社区，欢迎大家一起讨论： https://www.v2ex.com/t/685321
“先吃再给钱”的模式，可以用在内容付费论坛中吗？ 说说我的新思路： https://www.v2ex.com/t/710214
刚才刷牙的时候想到一个责任制的论坛的点子，各位看看可行性如何： https://www.v2ex.com/t/763846

@nothingistrue #13
你的方案是不是说给过号一定的延迟时间，而不是说叫了下一个号就立马把上一个算作过号？

@autoxbc #6
你这个是定量的做法，其他的都是大概估摸着。不过方式变化太大了，由商家主导变成了客户竞争竞价了。

@ansonsiva #11 > “过了几个号就再等几桌”
这个方法也算是定量，根据实际超时的情况来确定重叫的间隔，而且完全是商家主导的。

@nothingistrue #13 > “后面正在排队的人，他看到的等待人数，只能不动或者减少，不能增加”
没太看懂。比如一个人拿了 3 号，当前共排了 13 号，当前已经叫到了 7 号，那么这时拿 3 号过号的人又赶回来了，应该把它放到哪儿呢？对于 13 号，它看到的等待人数应该是 5 个(8 、9 、10 、11 、12)，那么 3 号肯定就没办法插到 13 号前面了，相当于它就得重新拿号了。

@sobigfish #8 > “医院号很大的不同是挂号相当于付费预约了，这个只是排队。”
两者的差别有很大吗？是因为排队拿号的成本相对低一些？还是说爽约不来的风险更大一些？感觉应该是后者。我觉得这两者的差别也会影响重新叫号的方式是不是合理。

@kevinlexming 如果导出的格式可以解析，那么导出就相当于备份了吧。一般只有自己不小心误删了某些笔记，才需要再导入这个功能吧。

@owaru
是的是的，就是这样的网站。这 2 个网站偏文字介绍，缺少一些直观的工作场景。感谢分享！🙏


@zhaodong
仅作参考嘛，贵在真实。文字可以描述工作内容，图片视频直观展现工作场景和状态。

@easychen
看了两个，很不错，每个视频短短十几分钟，侧重于展示人物的生活状态。对于工作的内容还是着墨不多。

@yunyuyuan
我是。。全栈吧，至少是在学习中。不过目前我也没有想好怎么做呢。

做顾问这个不错。
另外问下，自制力这方面有什么保障措施吗？楼主没有这方面的担忧吗？
我之前也尝试过，但自制力是个难点：目标明确尚且难以自控，目标分散时就更别提了。因为时间多了，人的欲望也会膨胀，以前想做不想做的事儿都会冒出来。

是呦，快七夕了，这铜板💰咋来得这么巧合。

这里插楼问一下：
配合了 Redux 的 React ，是什么模式呢？
我觉得，有一种理解可以是：它是 MVVM 的一个变形，因为它去掉了双向绑定中的，反向的一个绑定。
其中 Redux 的 store 可以看作是 Model ，然后每个组件的 props ，是根据 store 经过 map 得来的，即 mapStateToProps ()，为得是从 Model 层拿到渲染该组件所需的数据 ViewModel ，所以 props 可以看作是 ViewModel 。最后组件本身肯定是 View 了，而且 React 实现了 ViewModel->View 的单向绑定，只要 ViewModel 变化了，View 自动变化，但是反过来 View 到 ViewModel 并没有这个自动的过程，而且 View 层是直接修改的 Model 层的数据，不符合 MVVM 中，通过 ViewModel 来修改 Model 的过程。
所以，呃，其实把 Redux+React 看作是 MVC 其实更合适，但是确实也可以从中看到 ViewModel 和 Model 之间关系的影子，也可以看到 React 自带的“数据绑定”的特点。。写不下去了。

真秀，满满幸福感

@coderluan 有道理

@zhouyg 你这种说法不能解释为什么很多软件的菜单项后面，都把快捷键标上；解释不了为什么我在 4 楼被 Qt 尴尬打脸。

很多时候用好情境，是没必要查文档的。就拿主题里举的例子来说，Qt 这么庞大，我都不知道要从哪里去查这么一个环境变量的文档。

@AoEiuV020CN
就是这些小问题才影响体验啊。遇到个困难的 bug 解决了起码有成就感，遇到这种恼人的小问题只会因为耽误时间而感到不值和生气。

刚才才发现，Qt 是有提示的，需要点一下 input 输入框，框的末端会出现一个含义不太明显的标记。误会了，尴尬。