1. 可以参考官方文档 https://docs.microsoft.com/zh-cn/powershell/module/microsoft.powershell.core/about/about_remote_jobs?view=powershell-7.2
2. https://github.com/gokcehan/lf

scoop install volta
volta install node
volta install pnpm
大项目 webstorm ，小玩意 vscode
volta 就是 https://volta.sh
顺带一提，wsl2 我也装了，但是基本不用。要求项目必须从一开始就完全处于 wsl 环境下，打开 windows 下的项目基本不可用，npm install 或者打包能慢得你怀疑人生。

ios ，双拼+gboard+启用滑行输入，感觉还可以。重点其实是滑行输入，能很大程度纠错。

好哦，大佬又出新玩具了

要快有 fastify ，要简单有 express ，koa ，要工程化有 nestjs ，不想看 node_modules 黑洞有 pnpm ，性能问题除了大公司，中小企业的业务有多少会达到 nodejs 瓶颈的，这时候为什么不能用 nodejs ？
有一点那是没错，会其他后端 java ，go 之类的那是本来就没必要用 nodejs 。一般都是前端或者其他语言的，要写后端基本上就会考虑 nodejs 更多。
你说如果让干全栈，ts 一把梭有什么问题？

绿植也偷？？？

各种 roguelike 游戏呗

我自己做的一些个人项目，用的 hygen

Azure 、AWS 、GCP
btw ，稳定，速度，便宜，不可能三角。

点登录就是小而美扫码，然后还蹦出一个什么蜻蜓云办公的玩意儿。

点插件蹦出一个文档，第一个 a 标签就是点不开的 https://qingtin.work/，连自家的应用网址都能打错的吗...

然后赫然写着
> RunJS 和蜻蜓云办公共用一个帐号体系。当前 PC 端只支持微信扫码登录，插件只支持手机号 /密码登录。

不是不想支持，能不翻墙当然好，但是如果登录只能微信 /手机号，我觉得翻墙是更舒适的选择。

尤其是这玩意主要面向开发者，翻墙是不是通用技能先不说，你在 v2 呆久了多少也应该知道大家对于微信，和绑定手机号的厌恶程度吧。

国外应用好处就是 OAuth 通用，GitHub 或者 Google ，Microsoft 账号就能使用绝大部分应用了，最多就是邮箱注册。

我也理解在国内必须绑手机号，这也是难处，但真要在开发者群体内推广的话，我能想到的就是团队强制使用，再配合宣传国产这一套。或者就是向编程初学者宣传，但初学者深入了解国外替代品后，感觉也很难留下来。

当然还有一种办法就是做一个海外版，这样或许更有吸引力（至少对于我而言）。

不管怎么说，看你们网站的备案时间才是上个月，未来加油吧。

账号在日区，不知道什么时候上呢

看了一遍你的留言，我感觉你心里其实已经有答案了，上 v2 可能就是让老哥给你增加一下信心，那我还是收回前言吧。抱歉。

@abcd191898105 #66 实质是在这问也得不到实质性答案

网上老哥说稳你就真信了？说不稳你就不心痒痒了？

问再多也不如你实际买一台，别人不翻车总归是别人的。淘宝非官二手原装翻车不少，上车也不少。

人不能挣到认知以外的钱，延申一下就是人也占不到认知以外的便宜。

有没有想过你看到的差价本质就是赌人品。好比你买了一沓彩票，上网问老哥我这彩票包不包中一样。

如果你把持不住，就冷静一个月看看你还有没有冲动，到时如果还想买，就别上网问，直接买吧。

@newghost #16
1.实际情况是 99.99%的项目都不需要接口，所以你直接使用类也完全 ok ，框架也很灵活没有限制死，甚至 provider 就是默认你不写接口模式了。说到 debug 跳转，至少我用的 webstorm 是可以跳转到接口实现类的，没有要搜索的情况。

2.index.ts 的确是一个好东西，在 ng 里叫做 barrel files 。但是使用不当可能会造成循环应用。https://docs.nestjs.com/fundamentals/circular-dependency#circular-dependency

3.如果你想的是通过修改 index.ts 的 export ，来修改对应导出，那就是完全硬编码的方式了。还不如一步到位把所有你可能用到的 provider 全部 export 来得更方便？

4.技术没有银弹，本质上 nest.js 这套还是学的 ng 和 spring ，关于过度设计接口抽象的话题网上比比皆是。我的看法是，结合自身和团队情况，程序不报错，那条条大路通罗马。

就像 #12 说的一样，大多数人是跳过了写接口这个阶段，直接依赖的实现类。所以看着的结果就是同一个东西在 module 和 import 里重复导入。
providers: [CatsService] 也可以写成
providers: [{provide: AnimalsService, useClass: CatsService}]
这里的 AnimalsService 就可以是个接口，而 useClass 又可以改成 useValue ，useFactory ，useExisting...等等灵活的实现。
这种做法可能在很多 orm 测试用例里会见到，因为测试往往用的不是真的数据，如果要 mock 的话，这时就可以使用 MockService 作为实现。