• 这就是bitmap的实现吧,好处是可以节省内存,位运算性能高。

    缺点是不支持非运算

  • 用来提测的apk

  • 噢,这个意思,这个改动有点大,我用的云存储服务商也没有提供js直传SDK,只有移动端的直传SDK😂

  • 😧 如果不通过rack怎么处理呢...

  • 云存储也需要后端接收到这个请求再上传到云端啊,现在我遇到的问题是后端需要等很久才能接收到这个请求。

    我新建了一个rails工程,按照最简单的文件上传步骤也会遇到这个问题。

    # Rails version: 5.0.4
    # Ruby version: 2.3.1 (x86_64-linux)
    Started GET "/resumes/new" for 127.0.0.1 at 2017-07-19 09:48:13 +0800
    Processing by ResumesController#new as HTML
      Rendering resumes/new.html.erb within layouts/application
      Rendered resumes/new.html.erb within layouts/application (31.5ms)
    Completed 200 OK in 66ms (Views: 60.4ms | ActiveRecord: 0.4ms)
    
    
    # 这里卡住了很久
    Started POST "/resumes" for 127.0.0.1 at 2017-07-19 09:49:31 +0800
    Processing by ResumesController#create as HTML
      Parameters: {"utf8"=>"✓", "authenticity_token"=>"TEKTZqcg32ef+KFzkl2BQeGi8uOkDI/4hx378tTmroLjOSxzNssAQGS2EkcRX5KWTuoWCQnrI5TnMdjysNtxGw==", "resume"=>{"name"=>"333", "attachment"=>#<ActionDispatch::Http::UploadedFile:0x0000000206c550 @tempfile=#<Tempfile:/tmp/RackMultipart20170719-8518-qzkb8k.apk>, @original_filename="paintbook_111M.apk", @content_type="application/vnd.android.package-archive", @headers="Content-Disposition: form-data; name=\"resume[attachment]\"; filename=\"paintbook_111M.apk\"\r\nContent-Type: application/vnd.android.package-archive\r\n">}, "commit"=>"Save"}
       (0.2ms)  begin transaction
      SQL (0.8ms)  INSERT INTO "resumes" ("name", "attachment", "created_at", "updated_at") VALUES (?, ?, ?, ?)  [["name", "333"], ["attachment", "paintbook_111M.apk"], ["created_at", "2017-07-19 01:49:32.031122"], ["updated_at", "2017-07-19 01:49:32.031122"]]
       (217.7ms)  commit transaction
    Redirected to http://localhost:3000/resumes
    Completed 302 Found in 3541ms (ActiveRecord: 218.7ms)
    
    
    
  • 我们组里现在都是要求把Gemfile.lock提交进仓库的,原因是如果不提交,遇到过在两台服务器上部署,asset pipeline后的fingerprint值不一样。

  • RailsCasts Pro 全部免费了 at 2017年06月28日

    RailsCast系列真的很棒

  • 请教重复代码的组织问题 at 2017年06月07日

    是滴,不过打算短期内不折腾了,没人手干活了 😀

  • 请教重复代码的组织问题 at 2017年06月01日

    这种调用API的方式改造成本也不小哎,除非两个项目原本就都是前后端分离的。

    而且前端直接请求API的话,需要处理跨域/登录等;后端请求的话,需要处理请求超时等问题。

  • 请教重复代码的组织问题 at 2017年05月31日

    @jasl 之前相关同学已经尝试重构过一次了,就是git subtree的方案

    @Rei @kgen 目前的现状来看,想彻底地拆,不共用数据库很难了。感觉单纯地根据面向的用户将项目分为【对内项目】和【对外项目】并不是很合理。根据读过的一些服务拆分的文章来看,一般都是先确定功能边界后再拆。