@CallMeReznov
@dog82

所以其实我想说最适合 coder 的 linux 是

docker pull ubuntu:20.04

自从有 docker 之后我就再也没用过完整发行版的 linux ，我自己打了一个装满了 build 环境的 image ，也就两三个 g 大，无论我手头在用 windows 还是 mac 都不用担心环境的问题。桌面环境，编辑器 IDE 能用得很爽，也不用消耗心智去折腾 vim ，安装依赖，构建什么的又能几乎完全还原 linux 步骤和生态

关于生命的想象很多人给出的设想要精彩得多，我读过的作品里

有硅化合物生命（即硅基生命）
有中子星内部电磁反应替代了化学反应产生的生命
有极微观世界粒子运行等效星体运行的宇宙中的生命
有极宏观世界恒星闪烁（「氦闪」）等效神经元电信号的「宏脑」生命

哪个不比「机器人赡养人类」高到不知哪去了

其实………………

我得指出一点，硅基生命是个很早很早的概念早到计算机远没有像现在这样普及就有了。
因为硅跟碳一样都是 4 价元素，有像碳一样组成复杂化合物的潜力。

但是很多年过去了，研究表明有机硅链的分子量远无法达到碳化合物的水平，因此硅基生命的存在可能性也越来越渺茫了




如果你想说的不是这种「硅基生命」，而是「二进制信号系统自动化智能」，或者「电磁场环境自演化系统」或者什么「量子态自演化系统」之类的，那我得提醒你物理化学造不出大规模集成开关。复杂场效应也许有可能性，但与你所想的也相去甚远。


因此这些「生命」一定是「人造」的。






人类有没有可能是电磁文明的培养皿我不知道，但电磁生命环境一定是有机生命（制造）的培养皿……

曾经各种 pastebin 网站很多的…… 现在好像都要注册才能使用了不知道是不是有什么法规限制


去看了之前那个命令行搜索感觉还挺不错的，为啥不做到一起呢？

@ie88 一句话阻止抬杠：
access violation 是 segment fault

你写了一个读取空指针的代码并视其为「用户保护措施」

一致性问题？ 两个乘客匹配到了同一个司机……

@zzc1368129224 其实我觉得最商业化的是甘城……我几乎都没看

京阿尼拍的剧场版 /电影其实真无所谓讲了什么，就跟姜文电影的主菜是台词一样，京阿尼动画主菜是分镜的安排手法，尤其是对人物情感活动的细腻刻画真的很有一套。青鸟开头的那一段，完全不需要台词，音乐去掉也不影响，就光靠分镜已经把这两人的关系、故事背景、性格，全交代清楚了。更妙的是这个镜头拍的是谁的视角根本没有明示，但你就是知道「我」是谁，在看谁，看哪，「我」此时在想什么。

第三人称讲故事，第一人称写心理。这么巧妙的手法在我 bgm500 部动画的记忆里几乎没有能与之媲美的。

推荐给妹子的： 《擅长捉弄的高木同学》，小短片，清新画风，究极爆炸甜恋爱番，剧情不做作但没有人看完不在床上扭成蛆的
推荐给不看动画的： 《 odd taxi 》，悬疑故事片，无日式画风痕迹（全是动物），能很好地让人接受用动画作为故事载体形式
给所有看动画的人推荐去补的：《来自新世界》，你已经经受过各种崩坏画风的捶打了，只有真正的好故事才能打动你！来感受硬核严肃的科幻吧


另外我个人会想反复看的基本是京阿尼的作品，尤其是剧场版，《声之形》《利兹与青鸟》之类的。京阿尼的故事不太行，但讲故事的手法真的太妙了。有相当多的分镜都是非常非常有意思的，是真正「动画的讲故事的方式」，与电影和漫画都不一样，我会想反复回味。

半佛快乐站

我觉得前公司这个流程就做得挺好

我们的流程申请页面一上来会画一个清楚的流程图，你可以直观看到自己的手续流程卡在哪一步由什么角色具体是谁来审批，卡住了你就可以直接 im 上去找负责人。


我觉得你们场景的核心矛盾并不是「撤回功能」不明显，而是
「审批」对于员工来说是个风险很大的操作

点完这个按钮，能决定我生死的人就有几率开始决定我的生死，为了活久一点那我晚点再点，大家现在是这种心态。

与其想让大家认识「审批」后「撤回」（判书都下了让我重新上诉？），不如让大家改变「审批操作很 Critical 」的观念。比如把「提交上级」改成「确认内容」，然后在我上面说的流程图里，把上级确认的那步画得特别 Critical （「注意！不可撤回！」），有个对比，大家就下意识觉得「可以随时反悔的步骤问题不大」了

用 tg 和会给陌生人发自己附近照片这两件事我怎么都联想不到一起去。

@chill777 如果没经验的话真不如早日提桶找找个下家。

流程这种东西不是文章能说得清的，而且各家公司情况不一样要慢慢迭代完善。

一开始怎么也要有的是 task 看板和需求池。 你们可以先自行调研适合的项目协作工具，现在应该一抓一大把。有了工具平台再定制度，比如周期多长，一个周期只开哪几个会，怎么确定哪些东西的时间，怎么把职责相互划分清楚。然后小组和大组又不一样，不同项目组的人员深度也不一样（比如一个只有前后端的项目和要做硬件产品方案的项目肯定不一样），这些都得纳入流程规范。

你现在可以做的是
1. 把 git workflow 确定好，写成文档
2. 选好项目协作工具，强迫所有人通过这个平台指派任务和时间
3. 你来决定下一个排期的周期和要做哪些需求，如果有意见那正好，需求评审会可以开起来了

挺好的，就是配色和图样风格得再统一一点，线框涂鸦风格挺清爽的，但跟有些地方的色块不太协调。


还有就是这个配色……
https://i.imgur.com/mEywBbl.png

不是想说这，是
https://i.imgur.com/NVByFPB.png
这怎么能是绿的！

> 我真的很想知道所有公司的产品经理都是这样吗？

当然不是……

#11
> 看了第 1 条附言，我认为楼主需要做的不是去一个有合格产品经理的地方，而是需要去一个流程更完备的公司，或者自强一些，建立起开发流程，而不是任产品左右

Can't agree more.
在这种流程不完善没人把控局面的小公司，谁能首先打造出工作流谁以后就有话事权。
视乎自己能力要么自起炉灶要么赶紧跑，选一个。