如果用 maven ，请用 maven wrapper 。
如果用 gradle ，请用 gradle wrapper 。
如果有的选择，请选择 gradle 。
如果没得选择，也建议多看看 maven 和 gradle 官网文档。

拥抱新技术是正道。建议能用 gradle 还是用 gradle 。能很方便的做出 maven 很难或者根本做不到的功能。

我不同意这句话：

“我们在任何时候，都建议顾客在购买或者激活软件时，都使用常用的、同一个邮箱。经历过这个事情后，我们觉得这个建议更加重要了。”

我认为软件的目的应该在于认证用户的身份，致于用什么邮箱不应该关心，比如用 apple 的匿名邮箱。我认为本文作者不应该只站在开发者方便（最小权限）的角度来建议。如果我是开发者，我甚至更希望用户使用匿名邮箱之类的方式，只要能达到识别用户身份就行，这样开发者也不用担心“不小心”泄露了用户隐私。

此外，我认为所有的 “说明与回应” 之类的公告，都不应该在里面教用户怎么做，这种教育（建议）用户的内容，可以额外开帖子号召。

此时此刻，需要道歉的需要做出回应和变更的，不是用户。https://i.imgur.com/6DMydmQ.png

@zhongpingjing #14 我建议是放在同一个 git 仓库的不同模块。假如你用 gradle ，那么开一个独立的模块给 feign interface ，里面包含了 interface 以及参数的 pojo 对象。其他人要使用的时候，将这个模块打包成为一个 jar 发布出去就行。当然，你放在独立的 git repo 里面也行，但是就是要注意 git sub module 的引用，对外发布一样的步骤。

更好的实践应该是手写 client interface, 然后你的 controller 来实现这个接口。接口打包成为 sdk 扔给第三方用，相关的 pojo 对象也扔 sdk 里面。这样保证了一个接口只定义一次，不会出现不一致行为。具体实现可以参考 spring feign 官方文档。

@zhenjiachen gradle 都可以支持的，8+ 的版本只需要 17+ 的 jdk 。我在用的是 8.4+jdk21 。 当然我没用 kotlin ，而是用的 groovy

@saite
@bytetony
@demoshengxw
@xiangpeng
@wclebb
我有个 14 年买的 incase 的内胆包，当时给 13 寸 macbook pro 用的，现在内部的 4 个角那个塑料衬片都缩小，变硬了。虽然也 9 年了，但是我记得是从第 4 年开始就慢慢变硬，缩小了。当时买的价格也不便宜，100 多吧，当时也是想着买个好点的。（顺便说一下，现在也能放下 14 寸 macbook pro ，大小刚刚好。）

所以我的建议是内胆包就弄个便宜的就行了，不需要太贵的。我自己现在一般就直接丢书包了，内胆包基本没用了。

我点进去 github 以后，没找到源码呀，请问这个是用什么语言写的呢？

@R18 #9
@ljsh093 #10

这 2 个本质上是同一个。photopea 是原版。这个作者还挺厉害的，这个网页是个纯前端应用，我认为能满足大部分基础需求了。gaoding 只不过是套了一层皮。

我有一个方案，以前我也用，不过后来只用 QQ 音乐以后就没用了，可以做到不清空媒体库的情况下，安装不同区域的账号。方法升级过几次，目前的步骤是：假设手机为 A 区域，需要下载 B 区域 app ，那么用 iTunes64Setup 12.6.5.3.exe 下载 B 区域的 App ，用 iMazing 安装到手机。

以前可以不用 iMazing ，直接用 iTunes 安装，现在不行了。要注意，新版 Mac 不支持，还是要用虚拟机安装个 Windows 来安装旧版本的 iTunes 。这个虽然麻烦，但是是我能找到的最好方法了。这个方法其实功能还有很多，比如可以安装那些自己备份好的，但是被苹果下架了的 app ，等。早期还能做到更多事情，主要是基于 iMazing 的功能。

我有空可能会写个更详细的教程吧 ；）

用 VSC + git 来写正式笔记，随手的笔记就用自带的 note 和 onenote

我个人看法是还是 iPhone ，年轻人能折腾的话，用安卓还行，父母辈还是挺依赖 iOS 安全的生态的。我目前已经将家里所有长辈的手机和 pad 都换成了苹果的了。不一定要当年最新款的，一两年前的也行的，长辈们通常通性能要求没那么高。

这个我有个简单的实践方式，并且已经用了好久了：用 gradle ，建立一个 task 依赖于 build ，然后生成 yaml 文件，也一同打包。这个 yaml 里面包含各种信息，比如分支名，commit id ，commit message ，build time ，编译环境的 IP 等。然后进一步的，可以用一个通用接口来获取这些信息。这些信息蛮有用的，可以用于校验应用版本依赖，也可以方便看问题。

我认为只用 0 库是更科学的做法。如果有不同的业务，应该用前缀区分。只用 0 库最大的好处就是以后做 redis 集群的时候，不用改动这部分的代码了。

最后一句改为：但是我还是觉得应该尽早切换 [gradle] ，因为你要在编译 [期] 做的事情，只有 gradle 能方便轻松的完成。

我有一个方法，但是用的不是 maven ，而是 gradle 。思路是：
1. groovy 脚本在编译器查找到 git 信息，包含 commitIt ，branch ，提交时间，提交人 等。写入到一个文件，比如 info.yml 里面。
2. 将 info.yml 添加到 gitignore 里面。（ info.yml 本身可以放到 resource 里面）也就是这个文件是每次运行任何 build java 相关的指令，都会重新生成一次，不用担心失效问题。
3. （可选）用 一个单例 Bean 提取 info.yml
4. （可选）在一个通用 module 里面引入 Swagger ，然后建立一个 Controller ，能返回这个 Bean

效果：
1. 无论 Devops 用什么形式打包，jar 包里面都会包含这个 info.yml
2. 最差的情况，编译环境用了 git + scp 来转移编译路径，也只会导致 info 丢失而不是编译失败。这一点很容易规避
3. 如果程序可以运行起来，那么就可以通过 controller 接口来返回 info.yml ，里面包含了所有你想在编译期间收集的信息。
4. 如果程序没法起来，或者只是一个 library ，那么只需要打开 jar 包也能手动找到这个 info.yml

以上方式稳定运行了很久了，应用到了我个人的大部分项目中。如果你是用 maven 的话，可以将步骤 1 改为 maven 插件，会麻烦很多，效果一样。但是我还是觉得应该尽早切换 gredle ，因为你要在编译器做的事情，只有 gradle 能方便轻松的完成。

这里存在 2 个可以讨论的问题: 1. 代码是怎么被操作的? 回答: merge 的时候, 没有先 fetch and merge 远端, 导致覆盖掉了远端. 2. 为啥历史记录看不到? 因为 git 默认的 log 指令有简化历史功能, 这里可以使用 git log -p -m file.txt 进行查看完整历史. 其中 -p 表示 patch, m 表示 merge.

可以用 sftp, 下载个 filezilla ,或者任意支持 sftp 的客户端都行. 记得要设置要权限和登陆以后的默认目录