• 有点类似于其他语言里的 lambda 表达式,而 | | 之间的则是参数。 比如 C# LINQ 里你可以这样写 Array.Where(p => p.Name == 'Jon') 换做 Ruby 就是 array.select { |p| p.name == 'Jon' }

  • 请教代码重构 at 2014年11月16日

    还有……建议把 if/else 反过来,尽可能做成 raise if xxx 这样的结构,看着应该会比较清晰些。

  • 百万级?每秒百万?每年百万?

  • 数据 migration 直接用 SQL 什么的应该就行了。发个我自己项目的片段吧,仅供参考。

    namespace :kanako do
      database = ENV['db'] || 'test'
      include ActiveRecord
      task :default => [:team]
    
      task :db => :environment do
        Base.establish_connection
      end
    
      task :team => :db do
        Team.create Base.connection.select_rows("SELECT league_id, name FROM #{database}.gz_league").map{ |row| { :id => row[0], :name => row[1] } }
      end
    end
    
  • 不对不对。

    首先 production server 别乱动。

    然后数据库 dump 一份来本地,写一个 rake task 做数据 migration。

    等部署的时候,rake task 在线上做数据 migration,从原始数据库读取,然后写入新数据库里,相当于是数据同步。

  • PostgreSQL 与 MySQL 的性能 at 2014年10月30日

    #49 楼 @hooopo 原来如此,学到了 :thumbsup:

  • PostgreSQL 与 MySQL 的性能 at 2014年10月30日

    #38 楼 @hooopo 这个词是我随口说的。

    因为 [timestamp, game_id] 上有索引的情况下,只读取索引就可以得到结果,所以完全不用读数据表了。第二种情况是只用索引来搜索数据,所以用了索引但是还是要用去数据表里搜出所有的数据来做聚合运算。虽然速度不慢但是会增加 I/O。倒不如说,其实把 game_id 放进联合索引就是相当于做了半个 counter_cache。

    对于楼主的两条查询 EXPLAIN,可以看到 possible_keys 都是 NULL,而 keys 则有索引。这种情况官网解释为:

    It is possible that key will name an index that is not present in the possible_keys value. This can happen if none of the possible_keys indexes are suitable for looking up rows, but all the columns selected by the query are columns of some other index. That is, the named index covers the selected columns, so although it is not used to determine which rows to retrieve, an index scan is more efficient than a data row scan.

    另外,我用的是 Aria,想来 MyISAM 应该会是同样的结果。

  • 你确定 main_test 这东东在你给的 html 片段中是存在的? 另外直接写 $('.main .test a').eq(i) 不好么?另外试试看把 attr 换成 prop

  • PostgreSQL 与 MySQL 的性能 at 2014年10月29日

    #35 楼 @bobby_chen 还请你好好研究一下 索引 这个东西本身。

    SQL 查询如果没有合适的索引就会扫全表。 你上面的例子就是典型。 WHERE子句里第一个条件是timestamp = ?,然后GROUP BYgame_id (虽然你原句里没写GROUP不过这样原则上是病句) 那么只有在有 (timestamp) 索引的情况下才能利用到索引。 而最佳的情况是有 (timestamp, game_id)`,这样就能完全利用索引来计算。

    你的问题不是索引太多,而是索引没有跟着需求走。建议你先列出要用到的查询语句,看下每个语句要用到的列,然后再根据实际需要去建立索引。

    以下是只有timestamp索引的情况。虽然用了索引但是还是要局部扫表。

    MariaDB [test]> EXPLAIN SELECT `game_id`, count(`game_id`) FROM `basicdata` WHERE `timestamp` = '2014-10-15' GROUP BY `game_id`\G
    *************************** 1. row ***************************
               id: 1
      select_type: SIMPLE
            table: basicdata
             type: ref
    possible_keys: index_1
              key: index_1
          key_len: 8
              ref: const
             rows: 94
            Extra: Using where; Using temporary; Using filesort
    1 row in set (0.00 sec)
    
  • PostgreSQL 与 MySQL 的性能 at 2014年10月29日
    MariaDB [test]> EXPLAIN SELECT `game_id`, count(`game_id`) FROM `basicdata` WHERE `timestamp` = '2012-04-15' GROUP BY `game_id`\G
    *************************** 1. row ***************************
               id: 1
      select_type: SIMPLE
            table: basicdata
             type: ALL
    possible_keys: NULL
              key: NULL
          key_len: NULL
              ref: NULL
             rows: 3071957
            Extra: Using where; Using temporary; Using filesort
    1 row in set (0.00 sec)
    
    MariaDB [test]> CREATE INDEX `index_1` ON `basicdata` (`timestamp`, `game_id`);
    Query OK, 3071957 rows affected (26.18 sec)
    Records: 3071957  Duplicates: 0  Warnings: 0
    
    MariaDB [test]> EXPLAIN SELECT `game_id`, count(`game_id`) FROM `basicdata` WHERE `timestamp` = '2012-04-15' GROUP BY `game_id`\G
    *************************** 1. row ***************************
               id: 1
      select_type: SIMPLE
            table: basicdata         type: ref
    possible_keys: index_1
              key: index_1
          key_len: 8
              ref: const
             rows: 44
            Extra: Using where; Using index
    1 row in set (0.00 sec)
    

    特地给你建了一个环境试的。

  • PostgreSQL 与 MySQL 的性能 at 2014年10月29日

    #27 楼 @bobby_chen 不好意思我爪机看不到 timestamp 上的索引。回头用电脑看。

  • 四要基于三吧。 另外 cancan 我没用过所以没法说了…

  • 三,用户可以自主创建表单

    其实挺麻烦的

  • PostgreSQL 与 MySQL 的性能 at 2014年10月29日

    #22 楼 @bobby_chen 你这样不加索引真的大丈夫

  • :thumbsup: Nice gem

  • 所有你觉得有所谓的东西都应该写入需求文档里。

    比如说登录功能,如果你不写的话,可能会做成「用户名密码登录」或者「邮箱密码登录」或者「新浪微博登录」或者「谷歌账号登录」等等。如果你想具体要求,那就必须写明,「我需要邮箱密码登录和新浪微博登录」,这样子。

    界面也是。功能也是。凡是你觉得有所谓的东西,都要写进需求里。

    之前看日本工作外包出来的需求分析,连界面上每个按钮和输入框的位置大小都会定好,示意图画好,然后分析每一个组件的操作。

  • #7 楼 @cooper 其实我不太明白,统一开发环境的好处是什么。 按理说,为了让软件更健壮,应该在不同的环境下分别测试才对啊?比如 Debian/Ubuntu/CentOS/Arch/Gentoo 下都能跑,而不是只有 Ubuntu 的某个版本的某个更新才对吧。

  • 你 user model 创建了吗?

    另外,请善用 Linux

  • 除了安装方便以外还有啥好处……

  • gem 'bootstrap-sass', '~> 3.2.0'

    至于覆盖?修改 sass 变量即可。找到 gem 里对应项目的变量,然后直接在 sass/scss 改掉。

    1. 可以开 screen 啊
    2. 生产服务器请老老实实上 webserver+unicorn/thin/passenger
    3. 其实我开发的时候就已经是 nginx+unicorn 了。rails s 我还没用过呢。
  • #36 楼 @mengbo 我一直以为 hashbang 标记是由 sh 来负责解析的。

  • #34 楼 @mengbo 我可能说得不太对。

    调用 perl 脚本的时候难道不是用 sh 启动的么

    另外,很多发行版还没换 dash 呢

  • #32 楼 @mengbo web server 调用 cgi 程序的时候不会走 sh 吗

  • #4 楼 @stephen 我觉得,「2」,就是多的意思了……。

  • nginx 问题还是 rails 问题 at 2014年09月30日

    我猜是浏览器的错?

  • Game 与 team 之间是多对多的关系吧,用关系表来做是不是更好?

  • #27 楼 @mengbo 这个漏洞不需要用 bash 写 cgi

  • #7 楼 @iBachue 原来如此