企业内用于给 iOS 应用提供重签服务的机器应该是苹果家的机器吧。还是有需求的。

但是除去特定场景，对于运维来说，在包管理、集群构建、授权费用、软件生态这些方面，苹果系的产品都没优势。

而且在硬件采购上，不同项目对 cpu、网卡、内存大小、硬盘容量这些各有侧重，苹果家本来就是硬件跟软件捆绑销售，他们要是放开了限制，最先出来的是各种高性能的个人的黑苹果平台，而不是服务器~

主业用 py，会一点点 php，让我放弃 php 的理由是我用不习惯 array，很反（我的）直觉。

后续想往 Go 靠，但是看了一些资料觉得 Java 在微服务跟分布式的积累做得比较好。

所以短期内的看法是，巩固已经会的技术，学 go 或者 java，同时学习 java 在大型企业后台上积累的优秀方案跟思路。

如果已经会 php 的话就不必转 py 了，在做 web 上大家半斤八两。应用场景上，py 在运维 /运营平台之类的用得比较多。php 我到不是特别了解。

首先必须肯定的是，leader 的决策并非都是对的。

除非是难度特别大的模块，通常业务代码用 A 方式行得通，用 B 方式也可以。不单是看功能是否能被实现，还需要考虑测试、运维、拓展性、时间成本、人力成本等等方面。leader 是决策者，最后出了问题他自己也是要负责的。

这个贴下面很多人在反驳你的话，我觉得问题不是出在“要不要用 leader 的方案”，而是你的描述中没有说清楚，你跟 leader 具体的矛盾在哪里。leader 觉得你的方案不好，不好在哪里，是时间成本大？是容错性差？是无法实现 KPI ？还是运维成本高？

如果你的 leader 讲不清楚方案差在哪里，那是他的水平不行。如果他讲清楚了，你能基于他的观点进行反驳，那才是大家更愿意看到的讨论~

刚好三年。在同一个地方待久了，会把思维限制在现有的框架下去解决问题。在同一个项目里待了两年多，最后一年在技术上基本没有长进，很焦虑，最后决定跳出这个圈子，裸辞了。

待业的这段时间有了很多空闲的时间去调整心态，思考问题。虽然最近两次面试被虐了，心情有点低落，但是没有后悔裸辞。

单说常规的用法，面向普通用户的话，他们的付费欲望并不强烈。
如果是面向 IT 人员，单一个快速执行命令也不是那么吸引人。
如果是面向要高频操作文档的普通上班族，专业的 Excel 插件有人做得更好。
定制工具是对电脑知识感兴趣的人才会做的。想搞定普通用户的话，我觉得不如针对不同职业的场景做多些命令集，搞个工具市场之类的来吸引付费好一点。

从用户角度，浏览器那些操作我觉得还是挺实用的。不过从程序员角度讨论，更关心这个软件的核心用户究竟是谁呢🤔

可以写，但是你得在位运算上面留一段注释说明意图跟原理。这也适用于其他为了让程序更高效而逻辑不直观的地方。

我拖延症也很严重，搜过一些相关的话题，也不细细展开了。

自己觉得一个比较有用的做法是，把要做的事情拆分成小任务，然后一点一点去做。我个人的情况是在安排任务的时候，会倾向于去做那些小且明确的事情，对于大的事项就想着再等等。

但是还有一个问题是喜欢把事情放到最后一个小时做。。这个毛病我现在也没改。。

初学的时候用的 Django，工作后用的 Flask。因为我们是一个开发团队多个系统都在用，很少用它的插件，大多数公用的库或者服务，自己开发自己维护，定制起来也比较方便。
而个人开发者的话，这些都要自己做了，开发多个的话可以考虑抽出来做个通用的轮子？

https://eugeny.github.io/terminus/
今天刚看到有人推荐这一个。刚下载，还没玩过，但是观感可以。本身只是个 cmd 的壳，命令行可以用 git bash 来强化~

把自己的工作计划摆在第一位。完成自己计划之后再去考虑帮助别人。
不要动不动就说「我回去研究下」，不要把该由他们思考的事情揽到自己身上。
如果是项目 /IT 上的常见问题，可以写成文档分享出来，甚至可以考虑做一个内部的技术分享。大大方方给他们提供帮助，也让自己的付出有意义（让领导知道）。
对于一些小白问题，一两次可以帮。反复问的话，如果不是直接的上下级关系，别管他，让他出错，由直接的领导去管理他。工作上讲究互帮互助是为了互相提升。替他人掩盖问题并不利于整个团队成长。

最后键盘花了 500，键帽花了 1000 （滑稽

阻止我 diy 键盘的原因就是喜欢的键帽实在不便宜，玩不起玩不起

手机上不影响。在电脑的浏览器上选择放在屏幕侧边。左右两块太占用空间啦

官网教程只是教你怎么使用框架，离做出完整应用还有一段路要走。建议跟着教程过一遍之后，挑一个开源的模板去改，或者从 ant design 之类的入手学习，能省不少力气。

1. React 生态丰富，vue 年轻有活力。毕设不太复杂的话哪个顺眼用哪个。应届生进公司侧重于考察你的学习能力，毕设用的哪个框架影响不大。
2. 前后端分离的时候，前端负责数据的呈现及交互，后端负责数据加载、业务逻辑等。
3. 你的后端是 Spring flask 还是 django 都无所谓，只是提供接口而已，用谁都行。

使用 docker 或者使用 docker-compose，`-p`跟`--ports`如果没有必要就不要随便用~

只暴露那些需要外部访问的即可，同个机器上的调用可以用 link 来做。
如果需要暴露端口，有机房内网的话最好只是开在内网上。开到外网的话注意加上白名单。

@fuxkcsdn
-p 6379:6379 是将容器的 6379 映射到主机上
容器本身是监听了容器自己的 127.0.0.1 的（假设，我没注意过），但是映射到主机上时如果没有指定 host ip，就相当于在主机外网的 6379 端口上开了个 redis 服务。

我会用 git，如果你让我切换到 svn，我多半也很生疏，这个倒不是喷点。

八年工作经验，多年带人经验，但是从你描述中看到团队效率管理似乎没有什么成绩，这个跟 ta 的资历就有点不符了。

但是做事还是得做事。。协作的事情以后再说

看得懂 github 上的 issue
看得懂 stackoverflow 的问题跟答案
看得懂各类软件官网的文档

做到这些就能应付日常使用了。
其实你略懂你要看的文章要讲啥知识或技术，单词看不懂都能猜出个大概。如果计算机知识不过关，你英文再好也看不懂文章。