Eric Guo's blog.cloud-mes.com

in HTML5, JavaScript, Ruby & Rails, Python, and Cloud MES!

Import and Export Mysql DB in Gzip Way

Permalink

Export MySQL in gzip format

mysqldump -u <YOUR USERNAME> -p<PASSWORD> <YOUR DBNAME> | gzip > mysql_cybros_db_`date +%Y%m%d%H%M`.sql.gz

Import directly in gzip format

mysql -u root
DROP DATABASE thape_cybros_dev;
CREATE DATABASE thape_cybros_dev character set UTF8mb4 collate utf8mb4_bin;
\q
# gunzip < mysql_cybros_db.sql.gz | mysql -u root -pPASSWORD thape_cybros_dev
gunzip < mysql_cybros_db.sql.gz | mysql -u root thape_cybros_dev

Check SSD Writen Amount Using Smartctl

Permalink

brew install smartmontools
sudo smartctl -a /dev/disk0
# Percentage Used: 6%
# Data Units Read: 67,399,384 [34.5 TB]
# Data Units Written: 53,574,524 [27.4 TB]

So my 4 years MBP 2016 used 6% of the SSD life time.

五年技术发展计划

Permalink

工作单位需要制定五年的技术发展计划,制定计划永远是一个好习惯。如果能做到下面两点的话:一,计划没有和世界线的发展发生大的偏差和背离;二,能够严格按照计划执行。

严格执行与否不是计划所能决定的,但是制定一个顺着世界线发展的计划倒是重中之重。

世界线

2020的世界发生了比较大的变化,脱钩,去全球化成了世界的主旋律,而在中国,公平也压过了以往对效率的追求。很多之前的内在逻辑都变了,比如自主可控性的要求会大大提高,容易学习几乎不再作为衡量一项技术是否有前途的的指标,当然,大众技术永远是中小企业的追求,毕竟企业需要新人,如果学习全部教Java,那么Java技术栈就肯定是一个不错的选择。

华为刚刚在上周公布了鸿蒙2.0,谷歌的 Fuchsia也将在2021年春发布 ,苹果的M1芯片更是吹响了x86指令集的落幕悲音。从以写程序为生的角度看,运行程序的操作系统恐怕在5年内都要发生大的变化,跟不用说在上面跑的语言和框架了。

跟随有前途的语言,跟随有前途的平台,为能出钱,或者能赚钱的平台写程序永远是不变的追求。

IT技术发展点评

语言

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平台

真正的跨平台应用其实是Web,随着IE的远离,Web端的编程方式会迎来一波发展大潮,Web网页会越来越像应用,用户会进一步感知不到页面的刷新,这一传统web页面的访问方式。前端框架的使用不可避免。

从实践看,基于React的前端开发方式可以真正的脱离web本质上html+form的交互方式,全屏,全界面交互是趋势,类似Rails这样的弹窗交互为主,有限的几个点的全屏交互将越来越无法满足用户的预期。

从开发角度,React的开发方式相比Rails,在熟练度接近的情况下,开发速度仍然有至少2倍的差距。

即使开发速度上有差距,Web的开发方向仍然是React这样的编程方式。其余方案还有很多,偏Rails的还有StimulusReflex或者DHH 即将发布的 New MAGIC,这里的取舍就是开发速度。

App端

App端最有前途的还是苹果的生态,不是说苹果的东西有多好,而是其他用不起苹果的用户付费意愿太低,但由于世界上还是99%的穷人,安卓还是太多人的第一选择,包括我。

从开发角度还是优先为苹果开发,成功了才需要考虑安卓,鉴于两者开发方式同web极大的不同,开发成本这边肯定还是要避免轻易开新项目。

报表平台

报表平台是一个伪概念,图表应该是应用程序内置的一个功能,ERP就应该提供会计相关的报表,智能化楼宇就应该提供座位利用率报表,等等。

目前的问题是,定制应用,由于开发时间成本等原因,很多报表完全没有开发就上线了,而且上线了也不继续完善自己的功能。(比如合同没有提,开发费用已经大大超过合同金额,以至于开发单位不想继续做等等。)实际工作的确还是需要一个报表平台,所以也不得不提。

原则上,个人不会花任何精力在一个不开源的技术上,所以先有帆软报表和目前我开发的echart / D3的报表是敌对关系,我开发的基于echart的报表的弱点是开发速度慢,其余都是优点(速度,可定制)。

人工智能

人工智能这几年发展变化很大,前面还是tensorflow一家独大,现在pytouch,百度飞桨还有Apple ML,基本呈现混战状态(当然也可能我没有太关注这块)。未来肯定要将主要精力放在应用上,至于制作人工智能模型(炼丹),时间有限还是算了。

Serverless

云函数,Serverless的来到主要会改变应用的部署和计费方式,如果Serverless最终被证明在比虚拟机更便宜的前提下,还具有线性扩展性,那么编程的方式肯定会为Serverless做出改变。Serverless一个比较接近的概念是微服务,目前这两个的问题都是将一个完整的应用拆成各个小块后,内在的复杂性会提高,若能克服的话,未来会很有前途。

Serverless的框架我将一直跟进redwood.js,中国区的镜像站点我目前在维护。

GraphQL

GraphQL不是一个新技术,我还记得2019年的Ruby conf china有一个专门做服装MES的有数派已经早就实践了很久了,当然这家公司现在已经凉了。GraphQL相比RestfulAPI最大的贡献就是提出了聚合的概念,可以在一个呼叫中取得一个页面所需的所有数据,从来提高用户体验,缺点也非常明显,所有的呼叫都只有一个端点,缓存几乎无法做,性能肯定会差。 最重要的是GraphQL真的很复杂,虽然现在PostGraphile和Apollo在试图降低复杂性,但是至少从这个时间点看,GraphQL还是不必要的复杂了。

RestAPI和GraphSQL其实不矛盾,我的观点是当你一个API可以返回一个页面的所有数据后,那么你这个API就是GraphQL了。

DevOps / 运维自动化

过去5年涌现了很多技术,Docker作为镜像标准基本已经确定,这个领域未来能做的东西不多,而且真的Serverless来了,作为开发人员需要做的更少。另一个角度看,DevOps会进一步和云计算平台融合,单个运维人员运维机器的数量会越来越多,但同时运维人员的数量也会越来越少。

命令行,脚本,Ansible还是这领域的主旋律。

单位技术发展计划

客户端

节约开发费用和给用户提供良好体验都是不可或缺的,在可预见的5年中,微信平台肯定还是相对最佳的企业应用开发平台,它基本抹平了平台差异性,开发成本虽然比Web高一点点,但是用户体验也能够做的好很多。

使用Taro平台的话,理论上还能通过React Native支持iOS/安卓平台,可能暂时不需要这样的灵活性,但是如果可以0成本的保留这个灵活性也是很不错的。

数据平台/中台

中台是一个伪概念,但是由于现在工作单位很多外购应用程序都不是开源的,或者即使开源修改也成本很高,所以直接通过访问应用的数据库,做二次开发或者推进数据流通是一个刚需,各个应用采用的数据库不同,Schema数据架构从使用的角度也有诸多不便,所以建立一个相对使用容易的BI数据平台,促进数据的二次利用,各个应用的数据共享还是很必要的。

目前已经基本建成了基于MySQL BI的数据仓库,但是数据还不够全,另外数据的访问方式也不够全。数据会在5年内逐步丰富,这个无需特别规划,数据访问方式,除了自用,也需要考虑直接给业务部门提供数据库连接的方式,还有Restful API调用方式也不可缺少(企业ESB的唯一的好处)。

未来会引入一个统一token API的方式,直接使用JWT公私钥签发的方案应该已经足够了。

ETL

建立数据平台免不了要做数据的抓取,清洗,导入,现在这个领域已经有众多工具,从开发团队被裁的Kettle到Power BI都能做ETL,由于五年后,数据肯定很多,需要抓取的数据源也会很多,所以如果希望离线数据可以做到上午和下午各刷新一次的话,必须使用流水线作业的方案。即同时做抓取,清洗,导入,三个动作在三个进程里面跑,最终抓取数据结束的几乎同时,导入数据也已经完成。显然这涉及到大量的进程间通信,这样就淘汰了一大批方案了。

初步打算使用Go语言的Ratchet来作为未来的ETL工具。

计划总结

未来5年将重点发展 JS,Web端,小程序端,特别赌一下Taro平台。

数据平台这边要盘活现有和未来的数据,利用好这些数据,为下一代的应用服务,下一代新开发的应用不可能像之前一样,都要求用户输入很多数据,新应用应该可以尽可能少的要求用户输入,但是为了得到这些数据,就必须尽可能多的利用好已有的这些应用的数据,盘活这些数据,让新应用上线不是那么累。

ETL工具现在团队最趁手的是Python和Power BI,需要逐步往Python体系方面靠。

API暴露工具现在还在评估阶段,个人看好JS的Apollo平台,但使用.NET core 5.0搭建也可以,只要没有费用产生就行。

总的原则就是,在保证应用系统用户很爽的前提下,替客户节省各种费用(开发费用,部署运营费用)。

Fix Could Not Find Gem_name in Any of the Sources When Deploy Using Capistrano

Permalink

When do running capistrano bundler:install stage, I always meet below error:

00:32 bundler:install
01 $HOME/.rbenv/bin/rbenv exec bundle install --jobs 4 --quiet
01 Could not find canonical-rails-0.2.9 in any of the sources
#<Thread:0x00007f92c4af3cd8 /usr/local/lib/ruby/gems/2.7.0/gems/sshkit-1.21.1/lib/sshkit/runners/parallel.rb:10 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
13: from /usr/local/lib/ruby/gems/2.7.0/gems/sshkit-1.21.1/lib/sshkit/runners/parallel.rb:12:in `block (2 levels) in execute'
12: from /usr/local/lib/ruby/gems/2.7.0/gems/sshkit-1.21.1/lib/sshkit/backends/abstract.rb:31:in `run'
11: from /usr/local/lib/ruby/gems/2.7.0/gems/sshkit-1.21.1/lib/sshkit/backends/abstract.rb:31:in `instance_exec'
10: from /usr/local/lib/ruby/gems/2.7.0/gems/capistrano-bundler-2.0.1/lib/capistrano/tasks/bundler.cap:57:in `block (3 levels) in <top (required)>'

After several try debug, found can remove below folder to resolve the problem.

rm -rf /var/www/thape_web/shared/bundle/ruby/2.7.0/cache/bundler/git/canonical-rails-866574f7436cf4f082de6fa4c0958c8dccaccc7a
rm -rf /var/www/thape_web/shared/bundle/ruby/2.7.0/bundler/gems/canonical-rails-*

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.

Migrate Capistrano3-puma to Using SystemD Mode and Puma 5.0

Permalink

Source code change

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.

Capfile
require 'capistrano/puma'
install_plugin Capistrano::Puma
install_plugin Capistrano::Puma::Nginx
+install_plugin Capistrano::Puma::Systemd

Enable deployer user sudo.

sudo su -
cd /etc/sudoers.d/
echo 'deployer ALL=(ALL) NOPASSWD:ALL' > 80-deployer-user
visudo # refresh only

Enable systemd puma.service

sudo mv /etc/systemd/system/puma.service /etc/systemd/system/puma_prod.service
# $get home folder like /home/deployer
cd && pwd
# replace $home with /home/deployer
sudo vi /etc/systemd/system/puma_prod.service
sudo systemctl daemon-reload
sudo systemctl enable puma_prod

NLS_LANG setting for systemd

Modify systemd.conf at /etc/systemd/system.conf

system.conf
DefaultEnvironment="NLS_LANG='AMERICAN_AMERICA.AL32UTF8'"

Export the CSV Directly in Postgresql Psql

Permalink

Export the data from SQL

psql -d postgres
\copy (SELECT vote_options.title, vote_options.vote_index, vote_options.user_votes_count, (DENSE_RANK() OVER(ORDER BY user_votes_count DESC ) ) as rank FROM "vote_options" WHERE "vote_options"."vote_id" = 1 ORDER BY "rank") to 'vote_rank.csv' with csv

Install PostgreSQL 13 and Correct Ruby Pg Gem Support

Permalink

Install postgresql13

Installation is similar to postgresql12.

# postgresql v12.3+ require LLVM-toolset-7-clang
sudo yum install centos-release-scl-rh
sudo yum install llvm-toolset-7-clang
# following https://www.postgresql.org/download/linux/redhat/
sudo yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
sudo yum install -y postgresql13-server
sudo /usr/pgsql-13/bin/postgresql-13-setup initdb
sudo systemctl enable postgresql-13
sudo systemctl start postgresql-13
# Checking DB status
sudo systemctl status postgresql-13.service

Install pg gem correctly

bundle config build.pg --with-pg-config=/usr/pgsql-13/bin/pg_config
bundle install