• lambda binding 的一些行为 at 2014年12月12日

    以前上课的时候学到的知识是,绑定总是由内而外查找绑定目标。如果最外层也没有可以绑定的目标,就会出错。

  • lambda binding 的一些行为 at 2014年12月12日

    以前上课的时候学到的知识是,绑定总是从内而外查找绑定目标。如果最外层也没有可以绑定的目标,就会出错。

  • #8 楼 @dormhub 那说明你的代码有问题。(也就是楼上说的 jQuery 版本过高)

  • 直接路由器里 dnsmasq 配置一下不就行了?

  • 分析,然后尽快 prototyping 出来,然后再慢慢搞起前端

  • 如何看待版本控制? at 2014年11月30日

    git,小 repo 没觉得慢啊?我是用 smartgit 的,命令行估计会更快。

  • 如何看待版本控制? at 2014年11月30日

    慢吗?你是说 git?

  • #2 楼 @hanluner 好眼力…

  • 这些工具缺失所以他去 SF.net 抓,然后被墙。

  • 就像你说的这么存啊?

  • 商标啊。

  • ActiveRecord 缓存问题 at 2014年11月27日

    是需要 reload 的吧。数据库更新不可能反馈到对象上的。

  • 大家都用什么备份方案? at 2014年11月23日

    MySQL 用他家自己的备份功能就好。文件如果不多的话每日备份就好。

  • #18 楼 @lhy20062008 send 来自语言的核心。用来实现语言本身而不是用来破坏封装的。

  • win81+sublime+virtualbox+debian-testing

  • 有点类似于其他语言里的 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