@matrix67 https://www.zhihu.com/question/360737017
大体就是 Nginx 作者是利用工作业余时间写的代码，老东家现在想分一杯羹。后来好像不了了之了。
一个很重要的点就是是否占用了工作时间、用了工作设备。因此如果自己写项目，最好用自己的设备、自己的许可、只在下班时间写，更重要的是看好合同。

SQL 难做的话，考虑放程序里

用爱发电

@crysislinux 以前我在初学 npm 和 python 的 pip 的时候，就有过疑问：他们要怎么解决命名冲突？为啥不参考 maven 的 pom 坐标的方式？
当时我在网上搜索的时候，得到的答案是：js 开发者倾向于简单的做法。（不记得在哪儿看到了）
我接受了这个理由，所以才会觉得 ES 官方的导入语法不太合适。

我个人感觉 JS 和 Python 是非常相近的，都是脚本语言，追求简单。npm install xxx 和 pip install xxx ，但 Python 就提供了 from xxx import xxx 的语法。

@crysislinux 但实际上不是很长。
ES 在给出模块化定义的时候，没给出推荐的形式（至少我是从没听人提起过），比如 Java 的域名反写，那确实到会是很长。

本来还以为你存了什么蓝光电影、电视剧、动漫之类的，结果还挺正常
看了看自己的，发现也用掉了 79GB 的空间，那确实有点不够用了。

@aaronlam
我也感觉这么更好，如果这么写的话，那我写完 `from './demo.js' ` IDE 就可以推导了
现在把 import 的放前面就很麻烦

js 模块的话不 export 就是私有的，这就是封装嘛，不让你关注细节

Java 有访问控制符啊，public 、protected 之类的。

Python 倒是留给导入者决定的。
但我感觉 JS 的 export 明显更好啊，看 export 部分就知道导出了啥，有哪些可用的。

自己买 License 就好了，个人买的是可以在公司里用的。但如果公司把钱补贴给你，让你买个人版是不行的。

如果是我领导不让用 IDEA 的话，那我肯定会自己买。让同事去折腾 VSCode 。
但是这部分肯定要算入成本，用于对比其它公司的薪资。
（不过就算公司买了，我估计也还会再买，详见 Nginx 作者）

之前看加拿大白嫖王一期视频就是尝试不用 Adobe
最终得出一个结论，Adobe 虽然贵，但员工的薪水更贵。

@thinkershare 完全同意，这就是我搞 Python 依赖时的最大痛点。兼容性巨差。
不光是版本问题。Python 本身说是一种“跨平台”的语言，但只限于纯 Python 的情况。实际应用中很多库都是 C/C++写的，但 C/C++不是跨平台的呀。

@ysc3839 Node.js 和 npm 是一体的嘛。

最好的方式其实是 Java Maven 的管理方式。
在整个机子上有一个中央仓库（.m2/repository ），里面按照坐标（组织、项目、版本）的方式存储着所有下载过的 jar 包，Java 项目只需要通过一个 pom.xml 引用，相关工具就会设置好 ClassPath 。两个项目依赖同一个库的不同版本也完全不用担心。

node_modules 这种放本地的做法，拉跨了点，但至少“两个项目依赖同一个库的不同版本”也还是没问题，只要你用的 Node.js 本身不是特别老。

但到了 Python ，两个项目依赖同一个库的不同版本就得创个新的虚拟环境了。

@whusnoopy
npm 没有啥虚拟空间吧，就算 cd 进对应文件夹，which npm 和 which node 的结果也是一样的。
但 python 的虚拟环境激活后，which python 结果就不一样了（虽然也是个软链接），是伪全局。

感觉 requipments.txt 比起 package.json 还差点。npm init 的时候就创建了 package.json ，使用 npm 命令安装、更新、移除依赖还会同步更改 package.json 。
而 requirements.txt 则需要手动编写，自动导出还会弄出一些隐式存在的包。

具体实现先放一边，主要看设计思路。npm 放本地的做法明显更适合工程、项目。


按理来说，全局安装也有相应的好处。就是方便共享，对于脚本程序确实很合适。
但问题是，实操下来，python 相关库的版本兼容性问题很大，甚至 python 自己的版本也很重要。常常需要创建新的虚拟环境，这种时候全局的方式就很不实用。

这是我感觉 python 拉跨的地方之一，npm 再差至少一开始也有 package.json
python 要装就全局装，没有项目级依赖，pyenv 和 conda 也只是虚拟了一个全局环境（没用过 pdm ），感觉更像 nvm

不过从另一方面来说应该又与 python 的应用场景有关，因为 python 与 C/C++深度结合
我个人 pyenv 用得少，基本都用 conda 。
像 geos 、torch 这种，其实不光是 python 的版本要管理。

#人工智能机器人
print('你好呀！') # 打个招呼

while True:
a=str(input('')) # 变量命名有些随便

# 人工智能核心算法！！！
b=a.replace('吗','呢')
b=b.replace('？','！')
b=b.replace('你','我')

# 输出了
if b=='': # 退出聊天
print('拜拜！')
break
elif b==a: # 问题无法作出有效回答
print('我没听懂你在说什么，换个问题试试？')
c+=1
else: # 回答有效，输出回答
print(b)

从使用者的角度说：
我本来就是轻度使用，对数据库的了解并不深，就算要花时间学，主要就是应付面试和以后工作需要。这种时候选 MySQL 才是更优的。

就算我来决定数据库选型，我也不敢轻易使用 PG ，毕竟 MySQL 用的人多，解决方案多，说白了就是生态。出了问题好找人解决，也不容易被人挑毛病。

另外就是性能的问题，就跟算法题似的，你的程序比我的快，但咱俩的都是 O(n)。就算换了一个，还是治标不治本嘛。


但我是真心希望 PG 能流行起来，至少国内问起来大家都能知道。毕竟免费的性能提升有谁不爱呢

@crystom 对的，这个我知道，就是我上面说的宏

生产环境应该是没有 process 的，自然应该也没有 NODE_ENV 这种东西。（宏除外）
你这里 Node.js 运行的是 gulp ，正常来说只有 gulp.js 可以读取到 process.env.NODE_ENV 这种变量。项目中的其它 js 文件是读不到的。

换个类似的场景，如果我使用 webpack 打包 React 或 Vue 成前端页面，那么 webpack.js 本身和项目中.jsx 、.js 、.vue 中的 js 代码是不一样的。前者是运行在 Node.js 环境中，而后者则最终要运行在浏览器里，就没有那些东西。前者的 js 代码是用来编译后者的 js 代码的。

如果你项目中某个.js 文件用了 require ，而另一个.js 文件用了 import 。那么前者是 Node.js 脚本，后者则是被操作的东西。

因此，如果你的 dev 是在 gulp 相关文件里获取的，而 undefined 是在其它文件里获取的，那么应该就是这个问题。