※ 引述《tuoba (拖把)》之铭言： : 不好意思，这边请容我解说一下 : 旧的 am.otlotl.com 这边的资料是我在维护的 : 新的 jsu.otlotl.com 这边的资料是 jsu 维护的 : 目前两边用的是不同的资料库， : 只是因为我这边可以提供较大的频宽跟空间 (其实就是 MySQL资料库跟 ruby host) : 所以这查询网站都是放在我这边（基本上那就是一个付费网址跟空间） : 那 jsu 他要更新资料很麻烦的，其实他那边比我辛苦 2 倍 : 因为他要先把资料抓回去他那边，然後再更新上传到我的网站 : 我这边则是在伺服器上有设定自动更新，就是用一组程式每天固定时间就在那边跑 : 他会去 AM 网站自动把资料抓下来，然後再填入本地端的资料库内 : 但是到前为止，不知道为什麽，我这边抓的资料总是会有一些错误的在里面 : 这一点 jsu 的比我好很多，他的资料正确度几乎是 100% : 另外一点是， 由於 jsu 有建立国家/机场/需求等资料关连 : 因此才能够用比较方便的方式去查询，这一点也是我的资料库做不到的地方 : 我这边目前用很蠢的方法在补救我的资料库的当中会发生错误的问题 : 那就是他会自动重复去扫描做验证，希望透过在再的验证来降低错误率 : 简而言之，目前两边是各自独立运作的网站，说真的 jsu的网站优点比较多 首先先感谢拖把大的美言，跟协助建立查询界面 之前我在更新时，因为懒得改 SQL 所以是先把 ninja.pwnass.com/am 的资料库跑完後 然後再把我的资料库 dump 到拖把大的站 (jsu.otlotl.com) 可是自从有一次不知某故无法 dump DB 於拖把大的站後 我就直接弄了第二个 DB class 去跑 目前的运作方式（自从昨天）是把 demand 跟 distance 都绑在我的 AM daemon 上面 每三分钟会检查是否有新的航点 若有，则去抓取新的距离资料 同时跑第二个 process 去更新国家与 demand 而 demand 值在上述条件皆未发生时，每日早上四点 会自动更新 demand 值 而以上的动作，都是去直接更新拖把大以及我的资料库 也就是一个 sql statement 跑一次拖把家跑一次我家 由於要避免 AM 锁我的帐号，所以我的程式比较复杂一点 我的程式首先有做所有的 exception handling 包含了重新登入，无法取得网页，帐号暂时无法使用，载入网面错误等 另外，为了让 AM 端看到我的连线是像人为的 我所有的流程都是以人工手动点选的方式去做 没有直接跳到取得里程的页面 这点也是为了取得前一页所传送的隐值，包含 post 及 js cookies 虽然在写 Facebook apps 通常不会取这些取值 但在抓 bot 的传统模式上，这个算是基础的第一步 为了不要被锁，所以有这些动作预防万一 另外，在更新资料库上面 原本的方式一来是有不知名的问题导致无法使用 二来是我想若能做 live update 的话 即便是一个航站的资料未完全建起来之前 使用者还是可以查到最新的不完整资料 比起要等到完全更新才能查，这点我是觉得可能方便多 所以第二次改程式，一次更新二边的资料库 这个也有缺点，就是每笔 sql query 针对拖把大网站的时间 大约是我对家里下 query 的三到十倍久（网路传输） 所以新的更新方式，会造成更新速度比起拖把大的程式缓慢 （若是以同时开始更新来说） 原本是有想过开放我家的伺服器给大家查 不过考虑到频宽有限，连过来会很慢 加上我写这程式也只是想说方便拖把大拿来做资料验证 於是只有曾经很短暂地开於，当时为了因应新航点，而拖把不在 目前能想到加速的方式，就是回到最初更新我本地端的资料库 再去更新拖把大的资料库，只是如此资料的即时性就会比较差 或着是，我再去刻一份 Python 版本的 这样就可以用 multithreading 一边查网页一边送 query 不过因为程式等於全部重写，要花的人工时会很长 这点我会想一下，有空再去做 至於资料正确性的问题，我有看拖把大的程式 也猜测没看到的部份应该有做 error handling 所以其实我也不知道为什麽资料有时会有误 毕竟我这里也只是用 regex 在取值 最後，若是各位同好有什麽新的想法 觉得会对玩 AM 有很大的帮助的工具 都可以提出来的，拖把人很好，我们都会愿意下来帮忙写 如果是要重刻一份像话的 AM @ FB 这样的东西嘛 呃，好吧，其实我有在偷做了... Jsu -- 乘长风，破巨浪　我海军勇向前航 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 60.251.160.203