书已到

RC1 版 1.7 倍性能已相当不错，期待后续

青云亚太 阿里云香港 AWS-JP 都可以的

做空呗

我们之前团队 80% 都是入职后从 Java 转 Ruby 的，没有任何问题。

提问的艺术 + 成熟的社区。

想干什么搜一下就能找到了，就不需要冒泡了啊。

感觉正常的应该是会前端的 dapp

加油

之前尝试用 Ruby 做爬虫，最大的问题是字符集问题。

商业软件一般是加壳后，找 360 申请过白名单。自己的小程序就没办法了

https://pc.qq.com/detail/15/detail_180515.html

加完壳或许不到 1M

产品稳定就好。 集中人力去做最赚钱的业务。

应该去 CHH 看真正的赢家

<div id="arr" data-array="<%= @array.to_json%>">

var array = $('#arr').data('array')

优雅的不知道，但是你可以这样简单粗暴。

加我拉你进群

Electron

+1

SourceTree

adminlte https://adminlte.io/

https://github.com/kyuubi9/rails-adminlte

react on rails 现在已经不推荐，建议 dva 前后端分离，或者 webpacker

正常情况下，模拟 websocket 连接，传 channel 参数，就可以顺利拿到推送数据进行分析。

如果只 gzip 的话，把文本复制出来也能还原数据。gzip 肯定不叫加密，但是推 Binary Frame 格式的数据就自带一定加密效果了。

因为碰到 Binary Frame，一般小白就已经比较懵逼了，说实话我是查了好久资料，才搞明白怎么把 Binary Frame 解析出来，搞这东西的人不多，资料也少。当然马上会有越来越多的人搞明白的，我这篇其实就是教人搞明白的。

但是如果传 channel 参数发的也是 Binary Frame 的话而不是 json 明文的话，模拟的连接不知道怎么注册 channel，自然就很难获取到数据了。当然扒压缩后的 js 也还能找到蛛丝马迹，但是已经可以成功过滤掉 97% 的不法分子了。可以再用其他策略，动态获取 channel 的注册方式。其实也没啥必要。

如果再用 electron、PyQt 或 aau 封装一个客户端，加壳后不给开 F12，基本能过滤掉 99.7% 了。

大部分时候倒不是怕他拿出去分析数据，而是如果推送的数据体积比较大，小白们乱分析，他们就 24 小时开着服务器，无数个进程恋着你，带宽伤不起。

so，过滤一下有好处。

集成了 swager，让 APP 开发或前端开发和 rails 开发可以面向 API 编程。 但实际上用起来还是有点难受的。

把 condition 里超过 3 行的 code 抽成函数就行了。

这样主流程里全是 condition，就清爽了。

你觉得“没必要定义的函数”，恰恰或许是 dirty 的原因。

用 https://stimulusjs.org/ 和 Turbolinks 配合，解决事件重复绑定问题。

LZ 应该十年前就混迹 PHP 社区的，何时全心皈依我 Ruby

所以说区块链还处在早期阶段。 2000 年的人也是无法想想用手机就能做一切事情的😄

已经完全禁止了啊，然后比特币 1 万涨到 13 万。 然后国家队感觉自己被坑了。今年要在湖南开国家交易所了。

找钱就算了，谁用手机扫二维码结账找过钱😂

发射一颗卫星成本好像几十万吧。因为可回收了。一堆人排着队交钱发射呢。

目前经济体系以美元为中心。 第二大经济体系“人民币 + 一带一路体系”正在形成。

这两大体系边缘的国家、有去美元化去人民币化需求的国家、被经济封锁的国家，普遍拥抱区块链。 逐渐形成第三大经济体系，抗衡前两大经济体系。

跨国投资，捐助不再困难，国家概念逐渐淡化。

伊隆马斯克一万颗卫星上天+IPFS，dns 根节点消失，墙逐渐消失。

基本上 70% 互联网这一套东西，会再区块链上再来一遍。

我觉得应当根据业务类型来定技术架构。 如果团队里的开发，对开发协作模式导致的效率低而进行各种吐槽的话，很有可能是技术决策者的问题。

举个我们自己的栗子🌰抛砖引玉。

我们做的是强业务企业信息化系统。 我们团队妥协的方案是，技术上前后端分离，开发上全栈。

• 前后端打包在一个仓库里。Rails 负责 api 以及以后的部分，React+DVA 负责前端内容。
• 开发模式启动项目用 foreman，通过 node 反向代理 api 到 rails 3000 端口。
• 部署模式，前端 js 会编译成纯静态资源，访问 api 时使用 nginx 反向代理到后端，仍然是 3000 端口。

前端过来的同学至少要懂得 rails 的增删改查，数据库建模，会写、debug 简单的业务逻辑。

后端来的同学必须了解 react dva 以及前端 ui 框架组件的全部使用。

好处是

1. 业务开发和 debug 效率最大化。
2. 可以完美利用 js 社区的资源。
3. 学习上手成本相对最低（DVA 可能比较难理解）。

槽点是用户和权限系统太难搞。

没有使用 webpacker 的原因是：

1. webpacker 当时刚出，对于生产工期要求高的项目，不敢贸然使用。
2. DVA 大厂出品相对成熟。
3. 前后端分离对于新手更清晰，更容易理解和上手。
4. ui 框架 ant-design 的文档有基于 dva 的，对新手友好。
5. DVA 有 js 惰性加载方案，并且非常傻瓜。（js 如果全部打包在一个文件里，最终可能达到上百 m，无法接受。）相对的 webpacker 的加载方案，没能理解。

目前 20 多个开发共同开发和维护同一个分支，效果尚可。技术方案上也在不断微调中。

事实上没有 SEO 需求的中台程序需求，即使在互联网公司也仍是许多的许多的。 目前我个人的倾向可能是技术上分离，业务上耦合的 fullstack。

另外一个问题可能就是项目管理和工种管理的矩阵化问题。

为了不浪费闲置开发资源，公司都会动态调配不同工种到不同业务线去工作。 当之前业务发生修改，或需要解决 bug 的时候，就会出现资源争抢。 加之如果合作的员工本身个人关系相处不是特别亲密的时候，就会出现配合效率低下的问题。

我认为 每条业务线都应当有自己固定的 Leader。 当工种配合衔接效率不高的时候，应当立即通知该业务线的负责 Leader 协调解决。如果 Leader 权限不够，应当立即通知更上一层管理者处理。

可以参考一下 pyspider https://github.com/binux/pyspider 相当方便