Mobility

如果你像我一样，需要经常性的访问不同的远程服务器，记录服务器的ip和输入密码就是一件非常痛苦的事情。好在，通过在item2中做一些配置，可以很好的解决这个痛点。最终实现的效果，就是类似配置了一些ssh书签，能够在iterm2中记住ssh密码, 实现免密码登录和自动登录的效果。 iterm2 （https://iterm2.com/) 是mac下使用非常广泛的一款终端替代产品，提供了很多强大的功能。要实现ssh书签，实现免密码登录、自动登录的效果，关键点是其中的三个特性：profile, trigger 和 password manager. profile顾名思义就是一套配置，像我们正常打开iterm2时，其实就是打开了default profile. 配置profile的入口就在工具栏 profiles 选项下，可以增加或编辑现有profile. 我们将需要的profile的general标签下的 commond 模块修改为 Command, 内容填入 ssh命令， 比如 ssh root@1.1.1.1, 就可以在打开profile时自动执行ssh命令。 prof...

技术分享基本在每个公司都会有。分享的效果因人，因团队而异。在有些团队中，分享会因为种种原因，逐渐沦为一个没什么用的时间杀手。 写这篇文章，是希望从选题等方面出发，通过一些比较基础的规则，提升技术分享的下限，争取让80%的人都能做出一次80分的技术分享。 选题基本原则首先要了解到的是，线下的技术分享不是分享知识的唯一形式。其他的，比如写博客写文章，拍视频，或者简单的分享一两句话，都是常见的分享形式。针对不同的知识，要考虑用什么样的方式进行分享更加合适。 比如，对于某项技术的入门介绍，推荐以文章的形式进行。读者可以进行快速的浏览或者对关键信息进行检索，要比坐下来听一遍效率高很多。 推荐选题通常来说，比较好的选题需要有较强的实用性，能够吸引到听众，且难度适中。能够让听众在听得懂和有新收获之间达到一个平衡。 举一些比较好的选题例子，以及一些注意事项： 对于新技术的介绍，需要介绍清楚新技术的产生背景，解决了什么问题，相对之前的类似解决方案有什么优缺点，引入了什么新问题，等； 对晦涩难懂的技术的讲解，这类选题粒度可以小一些，需要在充分理解问题的基础上有较好的分享技巧，保证大家听的明白；...

近年来，云原生在整个开源社区中正在成为越来越流行的概念。那么云原生究竟是什么？架构？平台？又能影响什么？系统安全？开发效率？所以我们今天就刨根问底，理一下到底什么是云原生。 要理解什么是云原生，就要从云原生的名字说起，云原生的英文名是cloud native, 很显然，其含义就包含云和原生两部分。云就是说应用是运行在云上，而非本地。原生，就是说应用要以最适合云的方式去运行，而不是仅仅从本地迁移到应用上。 那么，什么样的应用才是适合云的呢？其实就是能最大化利用云的能力，发挥云的优势。 而云计算的核心优势，其实无非就是将更多的资源集中管理，统一调配，也就更方便按需灵活配置资源，提高资源利用率。 类比一下，相信很多人用过storm等流式框架，它们的优势是什么呢？其中一个重要的因素就是可以将一个复杂的流程拆解成若干个子节点，每个节点可以根据其需求配置不同的并发度，并发需求高的节点可以获得更多资源。这样，资源利用率也就提升了。 对微服务来说，也是类似，将不同功能拆分成不同的服务，就可以单独对更小粒度的功能单独做扩缩容。 值得注意的是，拆分不仅包含拆分不同的业务，也包括将业务代码、三方软...

《干法》是一本讲工作态度、工作方法的经典书籍。在劳资矛盾严重、阶级趋向固化的今天，是很难完全向该书作者稻盛和夫先生一样，去践行这一套理念的。但这不代表这本书就没有价值了。努力工作，提升自己的价值，一直都是藏在人类内心深处的精神诉求，我们要做的，只是要让价值提升后带来的收益，能够给到我们自己。 在读这本书之前，我强烈建议先认真思考一下你和工作的关系究竟是什么样的。如果你就是公司的老板，那没什么好说，公司的收益就是你的。如果你不是，那就要理一理你创造的价值去了哪，是有了经济收益，有了能力的提升，有了将来可以成为自己能力证明的资历，还是帮老板多买了两辆跑车呢？ 之前读过一篇文章，说是将你自己当做一家公司来经营，将任职的公司当做自己的客户。我觉得这是一个很好的思考的思路，你需要考虑你这家「公司」，是立刻就去追求现金收入，还是先打磨能力与口碑，以期将来去获得更大的收益？要考虑与任职公司的交易是否公平？ 想清楚了这些，再来读《干法》这本书。否则，你可能会觉得这本书是马老师写的。话说回来，马老师确实也在践行这本书的很多理念，在他当英语老师的时候。没有当年“业余”时间的辛勤奋斗，哪里来今天的...

在通常的开发流程中，会有各种各样的评审(review)环节，比如产品稿评审、设计评审、测试用例评审、code review等。为了做这些评审，难免会引入一些会议。有的人会觉得这些事没什么用，太浪费时间。而实际上，这些事情是非常重要的，如果你产生了评审不重要的印象，原因无非两个，一是认知不到位，而是你所在的环境评审实施的不好。 关于评审的价值，首先对于团队来说，最大的作用其实就是提升团队的下限。试想一下，如果各个环节都不进行评审，而是直接产品交付一个产品稿，开发就对着开发，任何个人的疏忽都会给整个项目带来无尽的风险。多次的评审环节，实际上就是将一个业务方案，分别用产品稿、代码、测试用例等形式描述，再分别引入更多的人来检查，避免一个人的疏忽造成业务上的风险。 此外，本文的重点，我实际上是想讲讲除了给团队带来的价值外，对于一个个体的人来说，参与评审有什么价值。 首先说一下对于被评审的人，即产品稿、代码等的提交人来说，评审就是一个其他人来帮助你提升的过程，是难得的能获取直接的反馈信息的机会。其实对于很多人来说，相比于学生时代，工作时代学东西的最大难点就是没有人批改「作业」，看了书看了...

今天结合我的个人经历来聊一聊应届生的职业选择问题，主要针对后端开发（对岗位的选择，话题也比较大，后边有机会的话会单独开一篇文章写），我这几年的时间里历经了国企、大公司、小公司这样不同的工作环境，所以对于不同公司的情况还是比较有发言权的。 职业选择，最重要的无非就是城市和公司选择。城市选择是一件非常主观的事情，比如我，作为一个北方人，既不喜欢南方城市的气候，又想离家近，还需要大城市的机会，北京就几乎成了唯一选择。当然，给大家的建议，功利点的话，建议选择一些快速发展中的强二线城市，比如重庆、合肥，这样随着城市平台的发展，你自己身处其中，身价也会提升。 接下来，我会限定在北京的范围内，结合我自己的经历，说一下公司的选择。 提到北京，一个不得不提的问题就是户口的问题。不过，我强烈不建议你依据一个户口就决定了整个人生怎么走，比如明明不想进体制内，却为了个户口就去了。务必在考虑户口问题之前，优先想好职业发展方向的问题。 很多人会纠结于体制内/体制外、大公司/小公司这些明面上的选择，但这些其实都只是表象而已，同样是体制内，也可能有天差地别的变化。一个正确的做法是想清楚自...

关于rpc接口的输入和输出，一直有一种观点是将输入和输出都包装成单个request和response类。本文，我们就分析一下这种方式是否是一个合理的设计。 先说输入, 这个我先说结论，当且仅当输入参数过多时，才应该做封装。其他情况下完全没有做封装的理由。 对于将输入参数包装成request类的理由，无非是下边这些 修改接口参数时保持兼容性 可以定义通用的抽象request类，方便做统一管理 首先，第一条完全就是个伪命题，第一次看到这种论断的时候，我也差一点被绕进去，但是仔细思考一下，就会发现这个完全不成立。 即便使用request体的形式，如果接口提供方增加了必传的字段，调用方仍然需要增加这个参数才能调用，那相比于直接传参数，没有解决任何问题。而这种问题实际上也是无法解决的，因为就不应该让这种情况出现。接口提供方有义务保证后续的修改是向前兼容的。而对于增加的是非必传字段这种情况，即便不包装request类，也可以通过适配器的形式实现新接口并兼容老接口，后续再找机会异步的将老接口下线。 第二条的话，确实存在一定意义。 比如在抽象类里加一些统一的请求参数，这一点我认为做在框...

说一下我个人的经历，其实在我刚毕业的第一家公司里，做的就是底层的中间件开发。但是做的过程中，觉得并不喜欢这种远离实际业务的感觉，所以后来换工作的时候就有意的选择了业务部门。所以，今天想讲一下为什么会做这种选择。 我为什么不做底层开发首先，我想说一个很多人的认知，就是认为做底层的开发更容易学到东西，成长更快。我觉得这就是业务开发同学的臆想而已，底层开发没有大家想的那么利于学习，业务开发也没有大家想的那么不利于学习，原因我会在后边展开说。而之所以很多人有这样的认知，很大程度上是因为底层开发的招聘标准通常会高一些，所以这些人本身的学习能力和意愿就是要好一些。 其实底层开发的日常和业务开发也没有太大区别，都是在做需求。只是业务需求的来源是产品经理，底层需求的来源是其他开发，或者底层开发者本人的思考和想法。这里，我要说自己为什么不愿意做底层开发的第一个原因了，就是需求的来源不科学。首先，如果只做底层开发，而脱离了实际业务场景的话，对于技术的认知很可能是有偏差的，这样导致自己想做的一些事很可能是在自嗨，并没有实际应用价值。而如果从其他那些搜集需求呢，也会有类似的问题，业务开发的同学提出的...

大家好，我是流沙。设计模式是每个程序员都会经常接触到的东西，但是相信很多人对于设计模式究竟是什么还会有些疑问。所以，我们今天就聊聊这个，主要目标是帮大家理解设计模式的作用，以及要用什么样的心态对待设计模式。 前置知识提到设计模式，其实首先需要理解清楚的是面向对象思想。相信大家即使不能非常清晰的描述出来，对面向对象也应该是比较熟悉的。 我们就快速讲一下，面向对象有四大基本特性：封装、抽象、继承、多态； 封装：仅暴露有限的接口，授权外部来访问。将逻辑集中，因此更可控；可读性、可维护性也更好；易用性也更好。 抽象：隐藏方法的具体实现，让调用者只需要关心方法提供了哪些功能，并不需要知道这些功能是如何实现的。 继承：好处就是代码复用。 多态：子类可以替换父类。提高代码的可扩展和可复用性。 什么是设计模式设计模式是针对软件开发中经常遇到的一些设计问题，根据基本的设计原则，总结出来的一套实用的解决方案或者设计思路。 可以看到，设计模式是非常偏实际应用的，相比设计原则更加具体、可执行。 因此，在了解设计模式之前，就需要了解一些基本的设计原则。这些原则才是指导我们写出好代码的关键。 那么什么是...

大家好，我是流沙，一名近六年工作经验的程序员。我的工作经历里，包含了整体文化、氛围差别非常大的公司，和很多不同类型的人合作过，观察到过很多没效率的现象。同时，我一直觉得我自己的开发效率是非常高的。整个职业经历里，我很少在八小时的工作时间外处理任务性的事项。即使有时迫于公司制度不得不进行加班，也是在执行自己的学习计划，或者进行一些深层的思考。因此，我想做一个系统性的关于开发效率的总结，分享给大家。 首先，列两个非常没效率的场景。 小A开发过程中碰到一个没见过的报错，于是抱着电脑去找团队里的大牛小X, 小X努力的搜集相关的各种必要信息。与此同时，小A就在旁边看着，并且不时的和小X还有旁边的小Y聊着天。 小C拿到一个大型需求，匆匆看了一遍，接着就开始开发。开发一半了，发现产品稿上有个点看不明白，又去和产品问。问的过程中产品又想起来别的事，又说了起来。最后聊了半天，小C发现自己之前的工作基本白做了。 虽然有夸张的成分，但是这些事也是确实每时每刻都在发生的。造成这些现象的原因很多，我们今天就好好剖析一下。在剖析效率问题之前，我们需要先看看程序员日常都要做哪些事。其中对工作效率影响比...