17 篇热帖
是不是？对不对？合不合？
程序员就应该自己去画原型图啊！
我觉得合理的模式是：
所以，我认为产品经理和程序员，应该就是同一个人或同一个团队！
我是不太想在 V2 发起这类争议性话题的，但是目前国服的环境让我感到恐惧。
之前的网上话题只是让我感到不适，比如男女电梯事件，因为我已离开校园，总感觉离我比较远。但是最近成都的种种劣迹使我感到恐惧，一个普通男性随时随地成为小作文的受害者。一旦被污蔑，轻则颜面扫地，重则身败名裂，家庭破碎，失去工作。即使证明了自己没有违法，她们一句敷衍的道歉就结束了，没有得到任何惩罚。
一个女性污蔑你在偷拍，你不能有任何操作手机的行为，否则会认为你心虚在删照片。即使等到警察到来，检查你的手机，如果你的手机有一些不允许安装的 app ，那么后果将更加严重。
换城市的代价是巨大的，再说国服这个环境到哪都是一样。实在是没办法了，希望大家发表下自己的意见。
上一篇帖子，有不少人说让我研究 B 站 up 主秋葉 aaaki 为什么火、怎么火？
那就大家一起看看，他是使用NovelAI 商业网站泄漏出来的模型，制作了一个分享视频，下载链接的提取码需要关注后私信关键词才能获取。靠着这种手段，快速吸粉，视频播放量 288 万，他也因此收获了 30 万+粉丝的关注。
这时候的开发量还不大，他就是用 stable diffusion 开源项目，打包一个 python 环境，写个 bat 脚本就发出来了。
后来他看准这个东西的火爆，开始做相关的视频教程，投入更多的精力开发了后来的启动器。
面对一些质疑，他很会避重就轻，抓住别人错误的点带节奏，他重点说明自己不是傻白甜工科小女友，而是死肥宅。完全不说自己窃取商用公司资源收获流量的行为。
他一点不怕因此被告非法经营罪，因为 NovelAI 是国外的公司，告不到身处国内的他。
他比任何人都明白这一切，当然他也有秒怂的时候。当有人用着他的启动器，用真人图片训练政敏人物模型的时候，他开始发表声明，置顶动态撇清关系，甚至下架了当时所有启动器的下载链接。
因为他知道，这种才是能威胁到他的东西，任由发展下去可能会让他吃牢饭。后来他看到风声过去了，也发表了禁止真人模型训练的声明后，又恢复了下载链接。
秋葉 aaaki 本人，在上篇帖子回复道：从我的字里行间看出了我是什么心态。那请继续看看我这篇帖子的心态吧。
@akegarasu ，我就想问一句，请问你窃取商用公司资源收获流量的行为，是对是错？别说什么自己免费分享，盈利也是都间接盈利，别人分享过，NovelAI 公司也有版权纠纷之类的，自己是“正义执行”。
就回答，窃取商用公司资源收获流量的行为，是对，还是错！
他的三观真是让我作呕。
对于别人质疑他用抢号脚本的行为，他甚至跳起来打别人的脸。
他在最新的 B 站发表动态，说出了这样的言论：
他这回是一点也不怂，因为他知道没有人能治罪他什么。
用用抢号脚本倒也无伤大雅，但他这种用了抢号脚本还公然嘲讽那些不用脚本的人，实属下作。
你如果支持这种行为，那么请你在亲人、朋友、自己，遇到生病抢不到号，回家抢不到票的时候，不要抱怨。
因为抢不到号不怪别人，是你自己的抢号脚本抢不过黄牛的抢号脚本罢了，请加大力度。
上篇帖子他的粉丝说我在写小作文，酸味溢出屏幕，请问这篇帖子，我的写作水平有没有进步呢？
去年我发布了一篇关于 clash relay 的教程，在 V2EX 引发了一些讨论。
比如 https://www.v2ex.com/t/894700 还有一些其他的帖子。
当初随便拿来放临时配置的 gist 也有了 50 多个 star https://gist.github.com/miaomiaoclub/6947f7cb93846301f1658da0edcd61bf
时隔半年多，这套方案在和朋友 @ RADE 的共同学习中有了不少改进，tunnels 功能的加入更是让整套方案如虎添翼，不少体验让我自己都有种“wow”的感觉，例如 延迟降低 100% 。
最终的效果让我到现在都非常兴奋，所以我花了一周时间再来写一篇文章和大家分享。
这是我目前使用的配置的示意图，为了美观简化了不少内容。
因为所有东西要讲完真的很复杂，为了让大家快点感受我的激动，我花了一周时间写了一个模版让你可以在 30 秒内开始体验这一切。
你只需要去 https://www.urlencoder.org/ 或者其他什么网站把你的订阅链接进行 url 编码。
然后把编码后的内容拼接到下面这一大串链接的末尾，再把它放到 Clash 里面订阅就可以了。
https://api.sublink.dev/sub?target=clash&insert=false&config=https%3A%2F%2Fgist.githubusercontent.com%2Fmiaomiaoclub%2F2178a7dd7fbbf4b7774ad6f7ad2000c5%2Fraw&emoji=true&list=false&tfo=false&scv=true&fdn=false&sort=false&new_name=true&url=https%3A%2F%2Fgist.githubusercontent.com%2Fmiaomiaoclub%2F92fc5af76ede047810a7a51af86089ee%2Fraw%7C
完成之后你应该可以看到这样的分组，其中的 READY BOOST 就是使用了 tunnel + grpc 的连接，你可以把左右两边的延迟进行对比。
然后你可以在节点选择列表的末尾找到 READY BOOST ，选中它，然后打开几个网页，另外，它应该是可以解锁 ChatGPT 的。
顺带一提，当你自行实现的时候，它是 udp fullcone 的，我在这里禁用了 udp 。
这套体验配置会在 1 天后失效，取决于这个帖子的回复情况延长或缩短。
关于 proxy chain 的优点，可以查看下面这篇文章
https://luxirty.com/article/01815b7d-073d-48ef-9528-7b4ad033f8d0
这里主要讲讲 grpc ，众所周知，连接复用可以节省握手时间，http/2 就拥有连接复用的特性。
然而 clash 只为 grpc 实现了连接复用，http/2 在 clash 中并不具备连接复用。
在实际测试中，我们（@RADE ）发现 relay 实际上导致了非常多的问题，例如 udp 无法通过、grpc 奇怪的高延迟等。
因此我们使用 tunnels 替换了 relay ，它的表现相比于 relay 优秀了很多。
你可以到 clash 的官方 wiki 来学习 tunnel 的用法 https://dreamacro.github.io/clash/configuration/configuration-reference.html
也可以看看我的博客，有稍微容易看懂的讲解 https://luxirty.com/article/chain-proxy-powered-by-clash-tunnels
在上面的体验配置中我并没有把所有这些特性都加上。因为写起来太麻烦了。但我相信对 V2EX 的各位来说并不难。
如何更方便地为 clash 自定义规则
你可以看到在上面的测试配置中，我们修改了配置并添加了节点，并且没有依赖任何自建服务，一个公开的 subconverter+gist 足够了
使用订阅转换时，如何把来自不同订阅的 proxy 分别放到不同的 group
唔…好啦，大概就这些！……希望这贴不要沉🥹
你们遇到这种怎么回复村里的
故事的主角是小明，一个刚入门编程的小白。他正在为一个项目写代码，但是他发现每次修改代码都很麻烦，因为他要不断地备份文件，而且很容易弄混版本。有一天，他听说了一个叫 Git 的神奇工具，可以帮助他管理代码的变化。他决定尝试一下，于是他打开了终端，输入了下面的命令：
git init # 初始化一个本地仓库
git add . # 添加所有文件到暂存区
git commit -m "first commit" # 提交第一次修改到本地仓库
这样，他就成功地创建了一个 Git 仓库，并且保存了他的第一个版本。他觉得很开心，因为这样他就不用担心代码丢失或者混乱了。😁
小明觉得自己的代码写得很不错，想要分享给其他人看看。但是他发现把文件发给别人很麻烦，而且如果别人也修改了代码，就很难合并。有一天，他听说了一个叫 GitHub 的网站，可以免费托管 Git 仓库，并且方便和其他人协作。他决定尝试一下，于是他注册了一个 GitHub 账号，并且在网站上创建了一个空的仓库。
然后，他在终端输入了下面的命令：
git remote add origin https://github.com/xiaoming/myproject.git # 添加远程仓库地址
git push -u origin master # 推送本地 master 分支到远程仓库
这样，他就成功地把自己的代码上传到了 GitHub 上，并且和远程仓库建立了联系。他觉得很兴奋，因为这样他就可以和全世界的程序员交流了。😍
小明在 GitHub 上发现了一个很有趣的开源项目，想要参与其中。但是他不想直接修改别人的代码，而是想先在自己的电脑上做一些改进，然后再提交给项目的作者。有一天，他听说了一个叫分支的概念，可以让他在不影响主线的情况下，创建自己的代码版本。他决定尝试一下，于是他在终端输入了下面的命令：
git clone https://github.com/someone/awesome-project.git # 从远程仓库克隆项目到本地
cd awesome-project # 进入项目目录
git checkout -b dev # 创建并切换到 dev 分支
这样，他就成功地在本地创建了一个 dev 分支，并且和远程仓库的 master 分支分开了。他觉得很自由，因为这样他就可以随心所欲地修改代码了。😎
小明在 dev 分支上修改了一些代码，觉得很满意，想要把自己的改进合并到 master 分支上，然后推送到远程仓库，让项目的作者看看。有一天，他听说了一个叫合并的操作，可以把两个分支的代码合并成一个。他决定尝试一下，于是他在终端输入了下面的命令：
git checkout master # 切换到 master 分支
git merge dev # 合并 dev 分支到 master 分支
git push origin master # 推送 master 分支到远程仓库
这样，他就成功地把自己的代码合并到了 master 分支，并且推送到了远程仓库。他觉得很骄傲，因为这样他就可以为开源项目做出贡献了。😊
但是，有时候合并分支并不是一帆风顺的。有一次，小明在 dev 分支上修改了一个文件，而项目的作者也在 master 分支上修改了同一个文件，并且先于小明推送到了远程仓库。当小明想要合并分支时，就发生了冲突。有一天，他听说了一个叫解决冲突的方法，可以手动选择保留哪些代码。他决定尝试一下，于是他在终端输入了下面的命令：
git pull origin master # 拉取远程仓库的 master 分支
git merge master # 合并 master 分支到 dev 分支
# 打开冲突文件，编辑保存
git add . # 添加所有文件到暂存区
git commit -m "fix conflict" # 提交修改到本地仓库
git push origin dev # 推送 dev 分支到远程仓库
这样，他就成功地解决了冲突，并且把自己的代码推送到了远程仓库。他觉得很成就感，因为这样他就可以和其他人协作了。😄
小明在 dev 分支上开发了一个新功能，觉得很完美，想要给这个版本打一个标签，方便以后查找。有一天，他听说了一个叫标签的概念，可以给某个版本起一个有意义的名字。他决定尝试一下，于是他在终端输入了下面的命令：
git tag v1.0 # 给当前版本打一个 v1.0 的标签
git push origin v1.0 # 推送标签到远程仓库
这样，他就成功地给自己的代码打了一个标签，并且推送到了远程仓库。他觉得很方便，因为这样他就可以快速定位到某个版本了。😎
但是，有时候有些文件是不需要被 Git 管理的，比如编译生成的临时文件，或者敏感信息的配置文件。有一天，他听说了一个叫忽略特殊文件的方法，可以让 Git 自动忽略掉这些文件。他决定尝试一下，于是他在项目根目录下创建了一个.gitignore 文件，并且写入了下面的内容：
*.tmp # 忽略所有.tmp 后缀的文件
config.ini # 忽略 config.ini 文件
这样，他就成功地让 Git 忽略掉了这些特殊文件，并且不会被提交到仓库中。他觉得很安全，因为这样他就可以避免泄露隐私或者浪费空间了。😊
小明和小红是一个团队的成员，他们都在 GitHub 上为同一个开源项目贡献代码。有一天，小明在本地修改了一个文件的名字，把它从 README.md 改成了 Readme.md ，然后提交并推送到了远程仓库。小红在自己的电脑上拉取了最新的代码，但是她发现自己的文件名还是 README.md ，而且 Git 提示她有一个未合并的文件。她很困惑，不知道为什么会出现这样的情况。
原来，这是因为 Git 在不同的操作系统上对文件名大小写的敏感度不同。在 Linux 和 Mac OS X 上，Git 是区分大小写的，所以 README.md 和 Readme.md 是两个不同的文件。但是在 Windows 上，Git 是不区分大小写的，所以 README.md 和 Readme.md 是同一个文件。当小明把文件名改成了 Readme.md 时，Git 认为他删除了 README.md ，并且创建了一个新的文件 Readme.md 。当小红拉取代码时，Git 认为她需要合并这两个文件，所以出现了冲突。
有一天，他们听说了一个叫解决大小写不一致导致的合并冲突的方法，可以让 Git 在 Windows 上也区分大小写。他们决定尝试一下，于是他们在终端输入了下面的命令：
git config core.ignorecase false # 设置 Git 在 Windows 上也区分大小写
git mv README.md Readme.md # 重命名文件
git commit -m "rename file" # 提交修改
git push origin master # 推送到远程仓库
这样，他们就成功地解决了大小写不一致导致的合并冲突，并且保持了文件名的一致性。他们觉得很开心，因为这样他们就可以避免以后出现同样的问题了。😁
小明和小红在开发一个新功能时，不小心提交了一些错误的代码，导致项目无法运行。他们想要撤销这些提交，但是又不想丢失他们的修改。有一天，他们听说了一个叫 reset 的命令，可以让他们回退到某个版本，但是保留他们的修改。他们决定尝试一下，于是他们在终端输入了下面的命令：
git reset HEAD~2 # 回退到两个版本之前，保留修改
git status # 查看修改的状态
git add . # 重新添加修改到暂存区
git commit -m "fix bug" # 重新提交修改
git push -f origin master # 强制推送到远程仓库
这样，他们就成功地撤销了错误的提交，并且重新提交了正确的代码。他们觉得很轻松，因为这样他们就可以修复 bug 了。😊
但是，有时候 reset 命令也会带来麻烦。有一次，小明在回退版本时，不小心加了一个–hard 选项，导致他的修改全部丢失了。他很慌张，不知道如何找回他的修改。有一天，他听说了一个叫 reflog 的命令，可以让他查看所有的提交历史，包括已经被删除或者回退的提交。他决定尝试一下，于是他在终端输入了下面的命令：
git reflog # 查看所有的提交历史
git reset --hard c761f5c # 回退到指定的版本
git status # 查看修改的状态
这样，他就成功地找回了他丢失的修改，并且恢复到了正确的版本。他觉得很幸运，因为这样他就可以继续开发了。😄
小明和小红在同一个分支上开发一个新功能，他们经常需要拉取对方的代码，然后合并到自己的代码中。有一天，他们听说了一个叫 pull 的命令，可以让他们一步完成拉取和合并的操作。他们决定尝试一下，于是他们在终端输入了下面的命令：
git pull origin master # 拉取并合并远程仓库的 master 分支
这样，他们就成功地把对方的代码合并到了自己的代码中，并且保持了同步。他们觉得很方便，因为这样他们就可以避免手动合并的麻烦了。😎
但是，有时候 pull 命令也会带来问题。有一次，小明和小红在同一个文件上修改了同一行代码，导致出现了冲突。他们很困惑，不知道如何解决这个冲突。有一天，他们听说了一个叫解决冲突的方法，可以让他们手动选择保留哪些代码。他们决定尝试一下，于是他们在终端输入了下面的命令：
git pull origin master # 拉取并合并远程仓库的 master 分支
# 打开冲突文件，编辑保存
git add . # 添加所有文件到暂存区
git commit -m "merge conflict" # 提交修改到本地仓库
git push origin master # 推送到远程仓库
这样，他们就成功地解决了冲突，并且把自己的代码推送到了远程仓库。他们觉得很成就感，因为这样他们就可以和对方协作了。😄
小明和小红在同一个项目上开发不同的功能，他们分别在自己的分支上提交了一些代码。有一天，他们想要把自己的代码合并到主分支上，但是他们不知道应该用 rebase 还是 merge 。有一天，他们听说了一个叫 rebase 和 merge 的区别的概念，可以让他们选择合适的方式来合并代码。他们决定尝试一下，于是他们在终端输入了下面的命令：
# 小明在 dev1 分支上
git checkout dev1 # 切换到 dev1 分支
git rebase master # 把 dev1 分支变基到 master 分支
git push -f origin dev1 # 强制推送 dev1 分支到远程仓库
git checkout master # 切换到 master 分支
git merge dev1 # 合并 dev1 分支到 master 分支
git push origin master # 推送 master 分支到远程仓库
# 小红在 dev2 分支上
git checkout dev2 # 切换到 dev2 分支
git merge master # 合并 master 分支到 dev2 分支
git push origin dev2 # 推送 dev2 分支到远程仓库
git checkout master # 切换到 master 分支
git merge dev2 # 合并 dev2 分支到 master 分支
git push origin master # 推送 master 分支到远程仓库
这样，他们就成功地把自己的代码合并到了主分支上，但是他们发现了一个不同的地方。小明用了 rebase 命令，他的提交历史是一条直线，没有任何分叉；小红用了 merge 命令，她的提交历史是有多个分叉和汇合的结构。他们觉得很好奇，不知道这两种方式有什么优缺点。
原来，rebase 和 merge 的区别是：
rebase 和 merge 各有优缺点：
所以，在选择 rebase 还是 merge 时，要根据具体的情况和需求来决定。一般来说：
小明和小红在合并分支时，不小心合并了错误的分支，导致项目出现了很多 bug 。他们想要撤销这次合并，但是又不想丢失他们的修改。有一天，他们听说了一个叫 revert 的命令，可以让他们用一次新的提交来回滚之前的提交。他们决定尝试一下，于是他们在终端输入了下面的命令：
git log # 查看提交历史
git revert <commit ID> # 回滚指定的提交
git push origin master # 推送到远程仓库
这样，他们就成功地撤销了错误的合并，并且用一次新的提交来记录这次回滚。他们觉得很安全，因为这样他们就不会丢失任何修改了。😊
但是，有时候 revert 命令也会带来麻烦。有一次，小明在回滚一个合并时，不小心加了一个–no-commit 选项，导致他的修改没有被提交，而是被放在了暂存区。他很慌张，不知道如何恢复这次回滚。有一天，他听说了一个叫 reset 的命令，可以让他回退到某个版本，并且保留或者丢弃他的修改。他决定尝试一下，于是他在终端输入了下面的命令：
git reset --soft HEAD^ # 回退到上一个版本，并且保留修改
git status # 查看修改的状态
git add . # 重新添加修改到暂存区
git commit -m "fix bug" # 重新提交修改
git push -f origin master # 强制推送到远程仓库
这样，他就成功地恢复了这次回滚，并且重新提交了正确的代码。他觉得很轻松，因为这样他就可以修复 bug 了。😊
小明和小红在完成一个功能后，想要删除自己的分支，因为他们觉得这个分支已经没有用了。有一天，他们听说了一个叫 delete 的命令，可以让他们删除本地或者远程的分支。他们决定尝试一下，于是他们在终端输入了下面的命令：
git branch -d dev1 # 删除本地的 dev1 分支
git push origin --delete dev1 # 删除远程的 dev1 分支
这样，他们就成功地删除了自己的分支，并且释放了一些空间。他们觉得很爽快，因为这样他们就可以开始新的功能了。😎
但是，有时候 delete 命令也会带来后悔。有一次，小明在删除一个分支后，发现自己还需要这个分支上的一些代码。他很懊恼，不知道如何找回这个分支。有一天，他听说了一个叫 reflog 的命令，可以让他查看所有的提交历史，包括已经被删除或者回退的提交。他决定尝试一下，于是他在终端输入了下面的命令：
git reflog # 查看所有的提交历史
git checkout -b dev1 <commit ID> # 用指定的提交创建一个新的 dev1 分支
git push origin dev1 # 推送 dev1 分支到远程仓库
这样，他就成功地找回了自己的分支，并且恢复到了正确的版本。他觉得很幸运，因为这样他就可以继续使用这个分支了。😄
到此为止，我已经给你讲完了小明和小红的故事，你觉得怎么样？👏
学校：排名偏后的 211 本科大三
专业：公共管理
经验：4 级已过 6 级在考，只有一些学校老师组织的小组实践的经验。
考研(图书管理员)->当图书管理员。当图书管理员即便没有编制做工资低（接近最低工资水平）的劳务派遣，也可以用空闲时间用电脑去赚更多的钱。
对于去企业工作的恐惧，觉得现在企业的岗位找不到工作，都需要要求有经验。
目前图书管理员基本没有编制岗位了，即便有也是百里甚至千里挑一，没必要耗费这么大精力考研然后再去赌 1%甚至 0.1%的概率，这些精力完全可以放在提升工作经验上面。图书管理员劳务派遣岗位倒是挺多，但是劳务派遣似乎只有当地最低工资水平，没必要做这种工作。父母也都是普通人没有在体制内，这种工作属于一眼望到头，没有提升空间。
再者，如果能保证自己可以用空闲时间赚到更多的钱，为何不直接全职去做这种可以赚到更多钱的工作。（她回：不稳定，怕饿死）
先积累经验，想办法找实习积累经验，将来去公司去产品或运营之类的岗位，性价比（付出的精力与时间与得到的回报）要比图书管理员方案高得多得多。
当地的实习工作没有岗位，找不到。
我是程序员，并且一个人有公司实体一个人运营一个 APP 。目前因国内收入变的很少所以计划把 APP 投放到海外看下机会，也需要人帮忙处理一些非技术方面的运营相关的东西。
因为 APP 已经运营了几年了，虽然几十万累计用户但是收入渐渐变得很少（目前 1000-2000/月），所以她觉得我这不能作为他的工作经验，属于一个人搞得东西不如大公司搞得”认可度“高，而且现在的收入还这么少。
我想着让他如果找不到实习就先帮我做东西积累一些经验，应用商店方面、用户社区维护方面、推广方面的工作。然后同时一边找实习。哪怕到毕业了也没实习，也相当于在我这里实习了，尽管不是大公司但也算是公司，实习证明什么的都完全可以作为简历上的工作经验。
考研，（可能因为说起来是”研究生“很有面子）。
以后做的工作需要有面子。（父母那一辈都会认为公务员比较好，但现在图书管理员都是劳务派遣，编制非常稀缺且难挤）。
或许她还可以考研考其他专业？但也不知道该怎么办，迷茫中。。。
就在刚才，2023 年 6 月 13 日 10 点 33 分，我的 steam 账号被盗了，下面是整个过程。
我用的是网易的 163 邮箱，
观察发现，浏览过的邮件都被放到了客户端删除的文件夹里，其中有一封邮件还在垃圾箱里面，很奇怪什么客户端可以绕过网易的 163 邮箱密码来收取邮件？
后续措施： 开启了邮箱的二次验证，并且关闭了 POP3 协议和 IMAP 协议，我怀疑是通过 POP3 和 IMAP 协议读取的我的邮件。
另外：这意味着我的邮箱密码也被泄漏了吗？
事情是这样的：
2021 年二月的时候老爸在东莞沙田一个小的机械制造工厂里打工，一直做到 2022 年四月离职。但是临走时有三万多的工资无法结清，老板一直用各种理由拖延。我爸不善交际，我便开始了漫长的讨薪之路。
经过几次与该老板的沟通得知，老板是贵州人，有过几次创业经历都失败了，这次看样子也要破产。我在企查查上看到，他已经因为几次合同违约、拖欠款项，被其他公司起诉过，被列为失信被执行人了，已经是老赖了。我当时能够感觉到他的难处，多次沟通并没有限定非常严格的期限，甚至同意分期支付，可是一直到 2022 年六月份，他依然无法归还哪怕一点点欠款。由于每次他都承诺的非常坚定，说什么时候可以先还多少，但是屡次都不能兑现，这让我非常失望，也让我失去了对他的信任。我便提起了劳动仲裁，请求劳动局帮忙解决。
毫无意外，仲裁结果符合我们预期，签订了仲裁协议，约定七个月之内支付全部欠款，如果无法履行，将需额外支付违约金，且我们可以申请法院强制执行。老板按了手印、签了名字，本以为这个事情终于可以结束了。
没想到这个鸟人，连一期都没有付过，就好像没有仲裁过，视法律为无物。 于是我下定决心，在 2022 年 11 月份开始申请法院强制执行。
现在执行流程已经走到司法拍卖，但是老板工厂的资产评估下来只有三千多块，还不够欠款的零头(这个评估我非常纳闷，根据现场的一些照片，那些机械设备和物料怎么也不可能只值这么点钱。)。在同时有我、我爸、工厂老板、另一个被欠薪的工人、法院工作人员的群里，工厂老板总是说“是因为你们走法院，我才破产的，现在好了，工厂也没了，你们高兴了？？”类似这样的转嫁责任的说辞。
我用淘宝租了个企查查的 svip ，查了下这个老板的财产线索，发现确实没有什么资产，几乎全是被申请强制执行、拍卖相关的线索，好像他确实是个不幸、又无能的老板。
我最担心的是我的爸和我妈会因为这个事情影响情绪、进而影响身体。打工一年挣的钱拿不到手，说出去好像有点无能的感觉，好像是被老板欺负了。他们要面子，所以不管老板是不是真的可怜，这个钱还是不要不行。
本来想过要去老板工厂或者家里闹一闹，送个花圈什么的，但是我人在上海，我爸在杭州，不管是东莞还是贵州，都没有什么人，成本和风险都挺高。
现在的问题就是这个钱还能怎么要，要怎么安抚我爸的情绪，有没有别的什么思路？
想系统性学下 TypeScript ，有什么号的教程 /电子书推荐下吧
例如： 结构体： struct test { int a; char b[1024]; float c; }; 数据： struct test data; 发送： send(sockfd, &data, sizeof(data), 0); 接收： recv(connfd, &data, sizeof(data), 0);
如果在未来，通过和 GPT 对话，就能得到想要并可执行的程序，那么程序员群体会失业吗？ 或者说收入会大幅度降低吗？
欢迎大家发散讨论~