• 搜索本身就是排序的,楼主觉得搜索需要排序,应该是觉得结果不尽如人意。

    其实 Google 用 site 指定站点后搜索挺准的,楼主试试看。

  • 扫描器而已,别太在意。

  • Ruby China 正在衰退吗? at 2017年3月13日

    二线城市大都是 PHP 做企业网站,Java 做低端企业系统外包项目。

  • Ruby China 正在衰退吗? at 2017年3月12日

    我突然发现,Ruby 虽然热度降低,但是在 RubyChina 发一帖讨论是否热度降低,一下子热度就提高了 😂

  • Ruby China 正在衰退吗? at 2017年3月12日

    Ruby 社区在国内算比较热的,因为火起来的时候,正好是 2008-2015 中国创业高峰期。

    现在 Ruby 成熟了,创业投资热潮也降温了。

  • 你把网址贴出来

  • 我说几句实话吧,或许对交涉没什么用,因为 Linode 已经下决心逐步关闭 Tokyo1 了,但可以有助于了解情况:

    1. Linode 的确在逐步关闭 Tokyo1,迁移到 Tokyo2,这是正常的新老更替计划。
    2. 机房的 Transit 都是提前跟各个 ISP, IX 买好的,一个机器越来越少的 Tokyo1 和一个机器越来越多的 Tokyo2 ,必然导致 Tokyo1 的体验更好。但大部分都迁移后,Tokyo1 的 transit 会少买,Tokyo2 会多买,到时候平均到每台机器,可能就差不多了,这是一个逐步调整的过程。
    3. Linode 给的 Speedtest 是反向的,这有两个技术问题:
      1. 国际网络间,两个IP间去程和回程的路由是不一样的。
      2. Linode 是反向测试的,所以它的 download 数据是你的 upload 数据,而它的 upload 才是你最关心的 download,2 Mbps 显然比较慢。
    4. 你即使向 Linode 证明了 Tokyo2 不如 Tokyo1 快,它也只会在未来计划中为 Tokyo2 买更多 transit,而不会让你迁移回 Tokyo1。

    以下是建议:

    1. 短期内,如果 Tokyo1 的机器没什么问题,先不要迁移 Tokyo2。
    2. Tokyo2 的网络,如果只是存放普通网站和 Blog,速度也够了,不用太担心,而且以后会调整变快。
    3. 如果是为了科学上网,建议直接使用云梯,云梯目前的库存已经超过1000台机器,面对这类机房变动,就有足够多的资源来应对。个人维护一两台的话,遇到机房网络变动就比较麻烦。
  • 核心功能上,MySQL 没有明显短板,普通项目的规模,数据库带来的差异非常小。建议继续使用自己熟悉的,尽早把东西做出来。

  • IT 人的辛苦,何来价值 at 2017年3月04日

    嗯,之前我也是。最近乱了,一会儿早起一会儿晚起 😂

  • Rails 并发处理 at 2017年3月03日

    并发取决于几个因素:

    1. 单个请求的时长
    2. 业务能接受的处理时间
    3. 有没有资源争夺
    4. 有多少硬件算力