Dump based on the SQL not fast, but many system doesn't need either, and the simplicity many times shining instead of faster.
|
It's the slowest part, so maybe Ctrl+Z and bg and disown -h %1 and having a good sleep.
|
|
|
|
|
|
So my 4 years MBP 2016 used 6% of the SSD life time.
Sidekiq 6.0 require Redis 4.0+, which the default redis version in CentOS still 3.x, so here is how to install redis 4.0+ in CentOS 7
|
工作单位需要制定五年的技术发展计划，制定计划永远是一个好习惯。如果能做到下面两点的话：一，计划没有和世界线的发展发生大的偏差和背离；二，能够严格按照计划执行。
严格执行与否不是计划所能决定的，但是制定一个顺着世界线发展的计划倒是重中之重。
2020的世界发生了比较大的变化，脱钩，去全球化成了世界的主旋律，而在中国，公平也压过了以往对效率的追求。很多之前的内在逻辑都变了，比如自主可控性的要求会大大提高，容易学习几乎不再作为衡量一项技术是否有前途的的指标，当然，大众技术永远是中小企业的追求，毕竟企业需要新人，如果学习全部教Java，那么Java技术栈就肯定是一个不错的选择。
华为刚刚在上周公布了鸿蒙2.0，谷歌的 Fuchsia也将在2021年春发布 ，苹果的M1芯片更是吹响了x86指令集的落幕悲音。从以写程序为生的角度看，运行程序的操作系统恐怕在5年内都要发生大的变化，跟不用说在上面跑的语言和框架了。
跟随有前途的语言，跟随有前途的平台，为能出钱，或者能赚钱的平台写程序永远是不变的追求。
Java, .Net之类的中间语言和中产一样，注定要在未来衰弱。未来的语言只有非常成功或者默默无闻，对性能的追求也一样，要么锱铢必较，连GC垃圾搜集也不要有，要么就是Python/Ruby/JS之类的极端灵活随意。
Java做为大众语言，几乎肯定是现在程序员的第一入门语言，但是就和你很少会和初恋情人结婚一样，真的面向未来的语言选择，Java这个大众属性并不能作为一个积极指标。
作为在过去10年主要使用Ruby的开发者（之前是.Net），我不否认Ruby一直在走下坡路。虽然Ruby运行速度在过去5年至少快了3倍，不过，似乎并没有太多人在意。所以我未来5年肯定也不用继续用Ruby。
我个人计划是大力学习发展Javascript（实际上也从backbone.js时代就开始了），如果对性能有较极端要求，用Go顶一下（但说实话，实际项目还没找到机会）。
数据库作为CRUD Boy标配，过去5年就是开源的天下，MySQL PostgreSQL永远是唯二的选择。
国内的TiDB与国外的clickhouse在横向扩展和列存储上优势越来越明显，所以开发这边首选还是MySQL，因为除了PostgreSQL，另外三个在数据库访问方式上都可以互相无缝替换。
至于MS SQL和Oracle，我这里也就算提过了，下一页的世界没有它们。
平台战争会继续，内在的原因可能是不同的应用需要的运行环境完全不同，这个世界再也不会出现Windows / Linux 这样的通用平台，但是那些为特定目的设计的专用平台肯定会用途越来越多。
专门针对特定目的开发的应用程序实际上不需要通用的操作系统，只需要一个嵌入式，能联网的系统，小米的Vela，华为的鸿蒙，谷歌的Fuchsia，三星的Tizen和最近收购的Joyent SmartOS，随便数一下，真的很难知道谁会最终统治世界，但是看起来他们都支持JS运行时，毕竟写一个跑的和V8引擎一样快的脚本语言运行时没有看起来那么简单，如果嫌V8太大，JS还有QuickJS可选。
在无法预知的情况下，跨平台的诱惑始终很大，但是鉴于Java的历史教训，以及苹果的成功，在强调用户体验的情况下，原生应用恐怕是严肃应用的唯一选择，对于企业来说，在无法负担书写多个原生应用的成本的前提下（比如iOS/Android/鸿蒙），才会考虑类似小程序这样的跨端应用，我觉得我的工作单位基本上属于这类企业，所以小程序还是重点发展的。
微信原生的小程序完全无法跨平台，绑定在微信平台上，Taro提供了较好的跨端方案，开发成本略高，但是考虑到未来的迁移方便还是值得。
真正的跨平台应用其实是Web，随着IE的远离，Web端的编程方式会迎来一波发展大潮，Web网页会越来越像应用，用户会进一步感知不到页面的刷新，这一传统web页面的访问方式。前端框架的使用不可避免。
从实践看，基于React的前端开发方式可以真正的脱离web本质上html+form的交互方式，全屏，全界面交互是趋势，类似Rails这样的弹窗交互为主，有限的几个点的全屏交互将越来越无法满足用户的预期。
从开发角度，React的开发方式相比Rails，在熟练度接近的情况下，开发速度仍然有至少2倍的差距。
即使开发速度上有差距，Web的开发方向仍然是React这样的编程方式。其余方案还有很多，偏Rails的还有StimulusReflex或者DHH 即将发布的 New MAGIC，这里的取舍就是开发速度。
App端最有前途的还是苹果的生态，不是说苹果的东西有多好，而是其他用不起苹果的用户付费意愿太低，但由于世界上还是99%的穷人，安卓还是太多人的第一选择，包括我。
从开发角度还是优先为苹果开发，成功了才需要考虑安卓，鉴于两者开发方式同web极大的不同，开发成本这边肯定还是要避免轻易开新项目。
报表平台是一个伪概念，图表应该是应用程序内置的一个功能，ERP就应该提供会计相关的报表，智能化楼宇就应该提供座位利用率报表，等等。
目前的问题是，定制应用，由于开发时间成本等原因，很多报表完全没有开发就上线了，而且上线了也不继续完善自己的功能。（比如合同没有提，开发费用已经大大超过合同金额，以至于开发单位不想继续做等等。）实际工作的确还是需要一个报表平台，所以也不得不提。
原则上，个人不会花任何精力在一个不开源的技术上，所以先有帆软报表和目前我开发的echart / D3的报表是敌对关系，我开发的基于echart的报表的弱点是开发速度慢，其余都是优点（速度，可定制）。
人工智能这几年发展变化很大，前面还是tensorflow一家独大，现在pytouch，百度飞桨还有Apple ML，基本呈现混战状态（当然也可能我没有太关注这块）。未来肯定要将主要精力放在应用上，至于制作人工智能模型（炼丹），时间有限还是算了。
云函数，Serverless的来到主要会改变应用的部署和计费方式，如果Serverless最终被证明在比虚拟机更便宜的前提下，还具有线性扩展性，那么编程的方式肯定会为Serverless做出改变。Serverless一个比较接近的概念是微服务，目前这两个的问题都是将一个完整的应用拆成各个小块后，内在的复杂性会提高，若能克服的话，未来会很有前途。
Serverless的框架我将一直跟进redwood.js，中国区的镜像站点我目前在维护。
GraphQL不是一个新技术，我还记得2019年的Ruby conf china有一个专门做服装MES的有数派已经早就实践了很久了，当然这家公司现在已经凉了。GraphQL相比RestfulAPI最大的贡献就是提出了聚合的概念，可以在一个呼叫中取得一个页面所需的所有数据，从来提高用户体验，缺点也非常明显，所有的呼叫都只有一个端点，缓存几乎无法做，性能肯定会差。 最重要的是GraphQL真的很复杂，虽然现在PostGraphile和Apollo在试图降低复杂性，但是至少从这个时间点看，GraphQL还是不必要的复杂了。
RestAPI和GraphSQL其实不矛盾，我的观点是当你一个API可以返回一个页面的所有数据后，那么你这个API就是GraphQL了。
过去5年涌现了很多技术，Docker作为镜像标准基本已经确定，这个领域未来能做的东西不多，而且真的Serverless来了，作为开发人员需要做的更少。另一个角度看，DevOps会进一步和云计算平台融合，单个运维人员运维机器的数量会越来越多，但同时运维人员的数量也会越来越少。
命令行，脚本，Ansible还是这领域的主旋律。
节约开发费用和给用户提供良好体验都是不可或缺的，在可预见的5年中，微信平台肯定还是相对最佳的企业应用开发平台，它基本抹平了平台差异性，开发成本虽然比Web高一点点，但是用户体验也能够做的好很多。
使用Taro平台的话，理论上还能通过React Native支持iOS/安卓平台，可能暂时不需要这样的灵活性，但是如果可以0成本的保留这个灵活性也是很不错的。
中台是一个伪概念，但是由于现在工作单位很多外购应用程序都不是开源的，或者即使开源修改也成本很高，所以直接通过访问应用的数据库，做二次开发或者推进数据流通是一个刚需，各个应用采用的数据库不同，Schema数据架构从使用的角度也有诸多不便，所以建立一个相对使用容易的BI数据平台，促进数据的二次利用，各个应用的数据共享还是很必要的。
目前已经基本建成了基于MySQL BI的数据仓库，但是数据还不够全，另外数据的访问方式也不够全。数据会在5年内逐步丰富，这个无需特别规划，数据访问方式，除了自用，也需要考虑直接给业务部门提供数据库连接的方式，还有Restful API调用方式也不可缺少（企业ESB的唯一的好处）。
未来会引入一个统一token API的方式，直接使用JWT公私钥签发的方案应该已经足够了。
建立数据平台免不了要做数据的抓取，清洗，导入，现在这个领域已经有众多工具，从开发团队被裁的Kettle到Power BI都能做ETL，由于五年后，数据肯定很多，需要抓取的数据源也会很多，所以如果希望离线数据可以做到上午和下午各刷新一次的话，必须使用流水线作业的方案。即同时做抓取，清洗，导入，三个动作在三个进程里面跑，最终抓取数据结束的几乎同时，导入数据也已经完成。显然这涉及到大量的进程间通信，这样就淘汰了一大批方案了。
初步打算使用Go语言的Ratchet来作为未来的ETL工具。
未来5年将重点发展 JS，Web端，小程序端，特别赌一下Taro平台。
数据平台这边要盘活现有和未来的数据，利用好这些数据，为下一代的应用服务，下一代新开发的应用不可能像之前一样，都要求用户输入很多数据，新应用应该可以尽可能少的要求用户输入，但是为了得到这些数据，就必须尽可能多的利用好已有的这些应用的数据，盘活这些数据，让新应用上线不是那么累。
ETL工具现在团队最趁手的是Python和Power BI，需要逐步往Python体系方面靠。
API暴露工具现在还在评估阶段，个人看好JS的Apollo平台，但使用.NET core 5.0搭建也可以，只要没有费用产生就行。
总的原则就是，在保证应用系统用户很爽的前提下，替客户节省各种费用（开发费用，部署运营费用）。
When do running capistrano bundler:install stage, I always meet below error:
|
After several try debug, found can remove below folder to resolve the problem.
|
Maybe do gem update --system and gem install bundler && bundler config default 2.1.4 also help, but at least not the root cause of such error fix.
Puma 5.0 removed eaemonization without replacement and finally capistrano3-puma start using systemd to manage the puma server and here is need to do to upgrade puma 4 to puma 5.
|
|
|
Modify systemd.conf at /etc/systemd/system.conf
|
|
Installation is similar to postgresql12.
|
|