同个问题 打开还白屏一段时间 一点都不丝滑

我最近需要开发一个 PC 端的套壳应用
首选 electron 生态好 也不用学些新东西
但是这玩意其实就是安装了一个浏览器，所以对于用户环境还是蛮尴尬的，大小还好，主要是内存占用

那优化就是用 tarui ，但是这玩意除了大小和内存变小，带来的更多的问题，比如生态，比如需要学习 rust ，比如有很多 webview2 的限制...

根本还是不能代替...


现在蛮卡壳的

我今天突然想用一个很骚的招

那就
1. 使用 RemoteAppTool 实现融合效果，之前试过感觉可行，然后我只要在 rdp 上运行终端和预览程序就可以
2. 使用 rdp 的共享文件，这样可以实现在 macOS 下写代码，然后 rdp 用来预览就行

这个方案类似于 vs remote 的效果

然后理想很美好，代码是共享了，但是遇到第一个问题那就是，我安装依赖的时候提示"EPERM: operation not permitted, open '\\tsclient\"...

但是我如果正常修改文件都是没问题的 有没有解决这个问题

然后我最近 通过掘金 /github 去看看有没有厦门小伙伴
结果发现几个好玩的

比如，不错的前端全都在稿定，有毒啊，全部被招走了，都不留点给其他人
比如，厦门本土公司，美柚 美图 cocos 有很多很强的 iOS 开发者，但是其他比如前端就完全没有
比如，一些老的不错的开发者都在铃盛
...


希望还有一些同学还没去这些公司，让我们一起共创辉煌

@noahhhh 有搞了一个散热器和一个小风扇吹手(...) 稍微解决了手感 但是电脑上还是卡 而且有时候是突然的卡住 估计是撑爆了

@looking0truth 对的 盈利算可以养活大家 目的也没错就是担心我们如果有事做不了会影响进度

我也遇到这个需求
第一种，就是集成 log+txt 的方案，好处就是通用简单，但是查询起来少一点方便
第二种，elk 之类的，好处就是适合超大数据，场景很少
第三种，就是用本地数据库比如 sqlite ，好处就是使用最简单，查询也最方便。但是感觉有点不是正道用途

所以有没有其他方式来解决需求？即配置简单 + 查询方便

真的蛮垃圾 不仅每次都要手机验证码登录 而且打开速度非常的蛮... 慢到我以为是我宽带又回到了 20 年前的 5m

如果你们公司是以产品为主，那 confluence 毫无疑问

其他情况下... 飞书是最优选

我不知道你为什么会觉得自己学习能力差...
而自卑的话... 如果你是普通人完全不用自卑...

当然，你自己现在这个阶段产生焦虑而已

不用担心，时间会抹平一些

当然更骚的是，你可以去一家很烂的公司，你会发现，md ，这些人能干什么？
然后你就不会焦虑了，适当的躺平一点

综合 我认为应该是后端...

如果直说浪费后端资源 /客户端 1v1 的，那应该没做过，或者天真一点的，或者海报就很简单，或者是完全不追求生成效果，或者完全不管用户反馈的场景...


前端生成的问题就是
1. 复杂海报每次生成需要时间，是每次，用户用一次生成一次。体验并不好，除非你生成后再放到 CDN 上(那还不如...)。我们之前开发的头像小程序就是，蛮尴尬的...
2. 遇到字体文件，吐血... 你总不能给客户端下载个 10m 的字体？
3. 最恶心的来了，你这个服务只能兼容 90%左右的情况，而剩下 10%会搞死你
...

特别是最后一点，就算你兼容的是 99%，那 1%还是会搞死你。
一般的人根本不懂兼容，他只觉得没能兼容 100%就是你的问题，你直接气疯...
而且我们公司有个后端程序员居然也怎么想... 真的尴尬


对于后端来说，只需要考虑『资源』问题
对于产品、设计、前端来说，要考虑的不仅仅是『资源』，还要『兼容』、『效果』、『体验』....

所以综合起来肯定是后端生成


当然，如果其他前端好的方案也可以讨论
我们 web 端和小程序，基本已经穷尽了，当然自己也用 canvas 写了，但效果真的...

2023 年了 有什么推荐的吗 sentry 真的太重了

@xmsz
还有一个，之前因为疫情原因还可以免费退机票，现在开放了，我 400 块机票，只能退 180 。2 个人现在硬亏 800

晚上坐等搓衣板，没去成，还倒亏钱...

现在就是
1. 别去，在等一段时间看看
2. 先得个阳再过去（蛮骚的，我甚至有点这么考虑，不过我这里毒株和北京的不一样）
3. 无所谓，去吧，反正人少不用排队



我现在更偏向先不去吧

但蛮可惜的 ಥ_ಥ，因为带的是我女朋友，而且之前在新加坡玩过环球，感觉蛮适合我们的

@hcx0 55555~

@smallyu 阿西吧 海底捞都关了吗

我也是一头雾水 然后

作为产品和技术，我感觉我的理解力居然不够用了？ 本来我都是用产品的方法论写代码，利用业务的理解和抽象写代码很轻松而且维护简单

但是一碰到 DDD 我感觉用产品和技术都理解不了...


然后还有我公司的技术负责人水平很一般，他肯定更不能理解... 那就完全推进不了
而且他对于业务真的『毫无用户感知』能力

这个也是我担忧的一点，就是如果只是简单的逻辑剥离，那没是个程序员一般没问题。
如果对于有经验的程序员来说，无非懂得更抽象化一点。

但是对于业务，又不是技术的能力要求... 而且技术和业务思考的维度真的差别蛮大的...

让技术根据业务设计这个事情我就觉得是伪命题...

@hrf1159 加了感谢

@Abirdcfly 好 下次(划掉)懂了