• 我在用 VUE 做全栈,使用的 Webpacker。没用 rails7 那一套前端方案,那一套太另类了,前端界现成的轮子很多都用不起来,成本太高。

    我这里系统,因为有角色系统的的需求,所以不想使用 2 套路由,配置起来太麻烦了。所以拒绝前后端分离。

    vue 文件放到 Rails 的 views 目录下了,不在 packs 写 js component 太割裂。放在一起十分舒服。这套整成 react 的话应该区别不大。

    application.js 里只有这些,自动加载到 rails 的 views 目录下。

    import '../stylesheets/application';
    // import 'bootstrap-vue/dist/bootstrap-vue.css'
    require('admin-lte');
    window.bootstrap  = require('bootstrap');
    window.bootbox    = require('bootbox');
    
    import "@fortawesome/fontawesome-free/js/all";
    
    import Rails from "@rails/ujs"
    import Turbolinks from "turbolinks"
    import * as ActiveStorage from "@rails/activestorage"
    import "channels"
    import TurbolinksAdapter from 'vue-turbolinks'
    import Vue from 'vue/dist/vue.esm'
    import 'vue-area-linkage/dist/index.css';
    import VueAreaLinkage from 'vue-area-linkage';
    import BaiduMap from 'vue-baidu-map'
    import _ from 'lodash'
    import dayjs from 'dayjs'
    import VueSweetalert2 from 'vue-sweetalert2';
    import 'sweetalert2/dist/sweetalert2.min.css';
    import VueTreeList from './component/vue-tree-list/index.js'
    
    
    
    Vue.prototype._ = _ 
    Vue.prototype.dayjs = dayjs 
    Vue.use(VueAreaLinkage)
    Vue.use(BaiduMap, {
      // ak 是在百度地图开发者平台申请的密钥 详见 http://lbsyun.baidu.com/apiconsole/key */
      ak: '========='
    })
    Vue.use(VueSweetalert2);
    Vue.use(VueTreeList);
    
    
    
    
    Rails.start()
    Turbolinks.start()
    // Turbolinks.setProgressBarDelay(1000);
    ActiveStorage.start()
    
    document.addEventListener('turbolinks:load', () => { 
      const element_path = $('body').data('element-path')
      const app = new Vue({
        el: '#app' ,
        components: {
          'vue-component' : () => import('../../views/' + element_path + '.vue')
        }
      })
    })
    

    我这现在主要是专注业务,所以技术方案没整理。前端样式框架用的 Adminlte,基于 bootstrap 的,所以 jquery 还在。

    大一统的前端框架真的很恶心,想拆什么整合什么,还是需要大量人力物力。我就用这种自己拼的。需要什么组件,就去拆几个进来。现在拼了百度地图、无限分类树、省市地三级级联,都没什么问题。

    react 的方案你可以琢磨一下。

  • web2.0 是 UGC,用户产生内容。(Facebook、twitter、微博) 与此对应的 web1.0 是门户时代,那时候 web ≈ 媒体。 web 只有 门户、企业站、电商等少数类目。(那时候没有页游,游戏不属于 web)

    有了 web2.0 之后才有 web1.0 的说法。 其中 web1.5 被认为是聚合类博客。用户产生内容 + 编辑推荐内容。

    币圈的 web3 和现在说的 web3.0 不是一个东西,相同之处都是基于一个名词的概念炒作。 现在的炒作主要基于 web3.0 和元宇宙 2 个方向。

  • 我感觉你在黑

  • 所以女人缺什么软件呢?

    美图有了。整形也不用软件。

    最重要的就是不了解需求。

  • 一直用 Sublime

    配置就是随便找一些 theme,ruby、rails 的,jsx、vue 的,format js

    VSCode 卡的一批,实在用不了。

  • 爬虫慢主要是 http 响应速度问题。

    用线程会快,然而太快话会被对方识别、屏蔽和投毒。

    搞爬虫的话直接上框架产品吧,异步、重连、更新内容、代理配置,都现成的。自己开发没必要。

  • 1 你把 Com 改个别的名试试

    2 在 boot.rb 里面加入以下代码试一下

    p Api::V1::Com::OptionsController
    
  • 回流招聘 “血泪史” at 2022年03月22日

    1 改成双休 2 提高工资 3 撩 Java 开发转 Ruby

    我这项目也正发愁呢,业务不难,就是不太写的动了。这一版上线了,后续开发也得找人接。

  • 除非你平时说话不用 “除非”

    否则还是会用到 unless(除非) 的

  • 关于前端的思考和疑惑 at 2022年01月04日

    Rails7 提供了可选前端方案,官方推出的 Hotwire 生态还是白板,轮子基本需要自己撸。所以目前还是 Rails6 时代的 Webpacker 是比较成熟好用。webpacker 和 rails 结合一般是 2 种方法:

    1 使用 React/vue/Angular 接管前端路由。rails 只提供 API。

    好处:几乎可以利用全部前端生态。

    弊端:需要管理前后端 2 套路由,增加心智维护成本和开发量,很多简单的页面本来 render 一下的事,就需要分别写一个前端页面 +1 个 API。而且两套路由,在做权限管理的时候就会非常抓狂。

    2 使用 Rails 的路由 + 部分 React/Vue 的页面渲染 +Turbolinks/Turbo(可选)

    好处:

    • 灵活自由
    • 一套 restful 路由非常整洁。
    • 简单的展示页面/列表不用去写前端 js 部分。

    弊端:

    • 需要自己处理 Turbolinks/Turbo 的一些坑,当然可以选择禁用。
    • 前端生态圈很多轮子不能开箱即用了,需要自己配置折腾一下。甚至有些根本不能用。
    • 需要维护 2 套 view 文件,其中 rails 那套可能就一行代码,但是必须写,很烦人。

    回答问题

    1) 如果使用 yarn add xxxx 其他的 js 库,是不是意味着 import xxxx 就可以找到 ?

    是的

    2) 如果自己编写的 yyyy.js 放在 app/javascript/packs, 应该写 import yyyy 嘛 ?

    写相对路径

    import xxx from './yyyy'
    

    3) bootstrap 依赖 jquery,导入了 bootstrap 是不是不用在单独导入 jquery ?

    把 jquery 注册到全局就行了,你参考下这个 config/webpack/environment.js ,VUE+jquery 的

    const { environment } = require('@rails/webpacker')
    const { VueLoaderPlugin } = require('vue-loader')
    const vue = require('./loaders/vue')
    const webpack = require('webpack')
    
    environment.plugins.append('Provide',
        new webpack.ProvidePlugin({
            $: 'jquery',
            jQuery: 'jquery',
            Popper: ['popper.js', 'default'] 
        })
    )
    environment.plugins.prepend('VueLoaderPlugin', new VueLoaderPlugin())
    environment.loaders.prepend('vue', vue)
    module.exports = environment
    
    

    4) 这个目录 app/javascript/channels 是做什么用的呢 ?

    action_cable组件的默认 js

    可以用 rails g channel 生成一个看看里面有什么,主要用于实时通讯,比如聊天室。服务端依赖 redis。


    1) 如果使用 yarn add zzzz 其他的 css 库,是不是代表着 @import "path_zzzz" 必须对应到相应的 css 文件 ?

    貌似是的

    2) 这个目录 app/assets/stylesheets 默认情况下会创建针对控制器 Controller 的 css 文件, 哪里制定它的呢 ?

    其实并不需要定制,全部写到 javascript/stylesheets/application.scss 里就行了,因为 require 进来的文件似乎有加载顺序的问题。 如果你用的 vue 或者 react,那你的样式最好遵循前端框架约定。

    官网指南看上去还没整明白,望大神指点迷津,有没有 6 版的中文手册之类的...

    目前是没有的中文官网指南还是 Rails5 的,不过足够用了。

    Rails 是个 MVC 框架,目前 V 还是用前端生态里的实践方案会比较好,Rails 提供的默认前端解决方案并不是很现代,过于强调复用,会导致 view 碎片化。而前端的 C 层解决方案又是堆 shi 山的副产物,而且并不能让后端省去 C 层开发,而导致前后端分裂。所以 Rails 官网指南重点学习 M 和 C 就行了。其他的完全不看都可以,像 mailer action_cable 这些并不是一个 Web Application 必须的。

    M 层和 C 层 Rails5 到 Rails7 几乎没有什么变化。而且 Rails 精髓也就在 M 和 C。

  • OpenGL 是 3D 图形编程,后端语言主要是业务编程,还是有很大差别的。

  • 我怎么感觉少了两个 0,看第十条要求很高啊。

  • 手动的话起 4 个进程就好了。

    一般用 passenger(nginx)管理进程,全自动的。

  • c 里面怎么嵌入 ruby 代码 at 2021年05月17日

    我感觉不行吧,主要是 gem 安装问题。

  • c 里面怎么嵌入 ruby 代码 at 2021年05月16日

    不知道具体需求是什么。类似 PYQT 的绑定?

  • 不面向工资编程,所以劣币少,急功近利的人少,戾气少。

  • 目测是 SEO 引流贴

  • 666

  • 其实可能只是你们的前端单纯的恶心 ActiveAdmin。

    让他们自行选择用 AntDesign、ElementUI 或是 Vuetify 就解决问题了。 GraphQL 真的是没有必要。前后端都需要学习和适应,还要处理不熟悉的逻辑问题。 感觉比把前端培训会 Rails 的 model 和 restful 成本更高。

    如果前端愿意 fullstack 的话自己随便整合一个 UI 框架,用 turbolinks 也是爽的不要不要的。

  • 利用好元编程重构下代码 at 2021年04月11日

    业务重构还是面向对象吧,元编程主要用来写工具代码。

  • 你的代码可以运行啊。 你先执行下 yarn install

  • 带 html 结尾通常是 2 个需求:

    1 SEO 的伪静态需求。早期 web 页面通常都是一串几十位的参数结尾的 url,被视为不利于 seo。

    而实际上长 url 对搜索引擎收录并没有太大影响,主要是

    /1?a=aaa&b=bbb
    /1.html?a=aaa&b=bbb
    /1.html?b=bbb&a=aaa&ref=baidu.com
    

    这 3 个 url 会被认为是 3 个不同页面。

    另外 SEO 人员认为语义化的 url 有助于 seo 排名。所以国内 SEO 站经常出现,

    /chanpin/jianjie.html
    

    这种过度 seo 的 url

    2 伪装后端 web 框架信息和开发语言信息,伪装成 html 静态页面,防止垃圾程序员写出的代码被注入、webshell 攻击。 而且这种程序很多都有生成 html 的方案,前端加个 squid,代理起来也更统一,更不容易出错,也对运维人员更友好。

    所以看到比较有历史的论坛程序和 cms 程序都是 /forum-1.html 这种,主要也照顾用户的惯性感受。

    而 rails 团队的激进更新风格,注入、webshell 漏洞基本不会发生,一旦发现都会很快被修复。用 restful 的 url 也根本不会有对 SEO 的不友好,所以一般看不到 rails 程序的 url 有 format。

    如果想要生成 html 结尾的 url,看路由一章就行,可以生成这种风格的 url,程序也能正常解析。 https://ruby-china.github.io/rails-guides/routing.html

    只不过并没有什么必要。

    而用 rails 开发 “产品” 的程序员层次通常比较高,合作的奇葩 SEO 人员也较少,也很不容易被 SEO 忽悠,对审美通常也有要求。所以 rails 开发的程序.html 结尾的 url 并不常见。

  • 哈,默认 1000 条,满足大部分伪自增需求。

    尽量自己做下伪自增工作。

  • find_each 是 order by 主键的,加上排序会有问题。 送你一个带 order 的扩展

    class ApplicationRecord < ActiveRecord::Base
      self.abstract_class = true
    
      def self.find_eachs(limit: nil , batch: 1000 , order: :id , &block)
        count       = 0 
        last_offset = nil
        next_break  = batch
        data = self.order(order).limit(batch)
    
        until data.blank?
          data.each do |dt|
            count += 1
            block.call(dt)
            last_offset = dt.attributes[order.to_s]
            break if count >= next_break
            break if limit and count >= limit 
          end
          break if limit and count >= limit 
          next_break += batch
          data = self.where("#{order} > ?" , last_offset).order(order).limit(batch)
        end
        count
      end
    
      def self.find_each_datas(limit: nil , batch: 1000 , order: :id , &block)
        count       = 0 
        last_offset = nil
        next_break  = batch
        data = self.order(order).limit(batch)
    
        until data.blank?
          block.call(data)
          data.each do |dt|
            count += 1
            last_offset = dt.attributes[order.to_s]
            break if count >= next_break
            break if limit and count >= limit 
          end
          break if limit and count >= limit 
          next_break += batch
          data = self.where("#{order} > ?" , last_offset).order(order).limit(batch)
        end
        count
      end
    end