無標題文檔

盗窃案后续

首先,感谢大家的近日来对于我的关心,基本上本人已经从郁闷中走了出来。接下来,说下在本人 从报案至今 的发生的的一些事情。

非常幸运的是,本人的手机安装了 防盗软件 (谁会想到这个时候它会派上用场呢)。其功能就是如果本人的手机换上了未被认证的 SIM 卡,该 SIM 卡的相关信息就会发送到指定的手机中。

其实,第二天(周日)我就收到了 SIM 被更换的消息,并迅速此信息告之了当地的警察(还是那套流程)。警察的答复都在意料之中「有消息我们会联系你的」。

当然本人并没有闲着,尤其是 一直表示歉意小妮子 同学(很多时候都是轮到我安慰她)。她出色的侦查能力,查到了此号码的归属地为「江苏,苏州」。进一步的,继续使用「非常规手段」,查到了次此 SIM 卡的用户信息(包括真实姓名、身份证号码、身份证地址等)。

这是个重大的突破,本人对此也非常的激动,于是今晚(周二)很早下班再次去公安局汇报此事。小妮子 事前嘱咐本人,先不要说我们掌握的情况,先打探下警察方面的进展。

向他们询问案件的进展,我们亲爱的人民警察一脸的无辜样:「您提供的手机号得汇报上级,经领导批准以后才能查的」。对此,本人早已经是意料之中,情理之外。

万般无奈之际,本人将目前掌握告诉警察,他表示非常的惊讶(他是否会认为我「上头有人」?)。其表示将会在验证提供的信息以后,并采取进行进一步的行动(娘希匹,第一步都没有跨出去,就想着进一步了?)。

当本人询问是否能主动联系此 SIM 卡持有人,并用现金赎回本人的笔记本、手机等物品时,那位神勇的警察叔叔非常明确的表示,「那是你们单方面的事情,我们无权过问。不过如果这样能找回失物,那也件未尝不可」(真他妈后悔怎么没有录音)。

本人彻底的对警察已经失望,甚至绝望。

在回去的路上和 小妮子 商量,是否直接联系此人。经过商量以后,我决定赌一次,于是找了个公用电话。

电话通了,接电话的人声音听起来非常的年轻(和本人期望的一样,但不确定是否就是嫌疑人)。在说明情况以后,此人表示对此并不之情,他也是刚购买此手机。

在本人的「恐吓和威胁」下,此人明显感到有些慌张,甚至说话感觉有点结巴(九零后,丫的心理素质就是差)。顺水推舟,本人暗示「购买赃物也是犯罪」(不记得我们伟大的 Party 制定的法律中是否有这样一条)。

继续恐吓:「此手机开关机记录都在本人的监视范围内,本人并将其提交给了警方,相信警方找到你只是个时间问题。如果你并不是嫌疑人,请将此手机退还给卖家,或者直接叫卖家和我联系沟通。」

接下来,本人并不想多说(其实也怕露怯),最后说了句「给你时间考虑下,有空我会再打你电话的」。

从目前的情况来说,找回手机的可能性会比笔记本大些。值得玩味的是其阐述的内容:本人周六晚手机被盗,周日下午就被购买。本人认为,其一,要么是此人在说谎,此人必定和嫌疑人有关系(有什么理由说没有呢);其二,要么就是犯罪团伙已经形成了 高效率的团队 (此人描述他收到物品,包括手机、充电器、包装都是全套的)。

要弄清楚此人有无说谎其实很简单,因为之前 妮子 了解的情况是此号码在杭州并没有通话记录,如果明日(周三)查询此号码在杭州已有通话记录,那么必定上述第一种情况无疑(我已经不会考虑再联系警察了)。

不管怎样,本人解决方案的天平已经倾向于私了了。在这种环境下,完全依靠警察至少目前在本人看来是不靠谱的。

在这里再提供个说法,就是警察在做失物笔录的时候,他们会尽量的压低价格,以此来隐瞒上报案情的严重程度。原因很简单,他们当然期望自己管辖的社区了然无事(原来他们也有 KPI),但是如当真采取这一做法,其和·谐程度真当让人叹为观止。

上述的观点真实性无法判断,所以烦请各位读者自鉴。咨询过律师(也可以自行搜索网络),就是在国内对于盗窃案件的判定程度是非常底的(尤其嫌疑人盗窃是私人物品时,国家的另谈),如不触及人身安全就会按照民事案件处理。

那么,接下来还能说什么呢?本人既然已经联系上了和失物有关的人员(不管是知情),我会在其「考虑清楚」以后再次联系他。如有必要,我会和其商定赎金 -- 这已经是本人目前为止最好的打算了。

Twitter 的前端浅析

前段时间(似乎目前也有)Twitter 的网站不是非常的稳定,虽然是 服务器方面的问题 ,而本人职业倾向,于是就看了下 Twitter 的前端代码,下面我说下我的个人观点。

按照期前所说的 评定标准 ,我们来对比下 Twitter 做得如何。

减少 HTTP 请求数,以及使用 CDN、加 Expires 头等

https://friable.rocks/_/2009_11_05/058855b87c6a.jpg

这是本人的 Twitter 主页的请求数统计( 大图 ),看得出在页面不大(150K)的情况下,请求数竟然达到了 60 个居多。

其中,大部分的请求数是图片等,主要的内容是用户的头像。其中,大部分的图像资源来自 s3.amazonaws.com 这个站点,而同时多达 60 多的并发请求数,还是让人对效率方面堪忧。

https://friable.rocks/_/2009_11_05/648315b87e99.jpg

上图是 Twitter 返回的 HTTP 头信息,看得出虽然设置了 Expires 头等信息,但是似乎缓存并没有发挥实际的功效(谁能告诉我原因?)。

Javascript 和 CSS 方面

Twitter 的 CSS 文件仅为一个,并且在页面的头部就已经载入。在这里我无法理解的就是为什么它们没有把样式给压缩,甚至连注释都存在。

https://friable.rocks/_/2009_11_05/345865b87c66.jpg

特别是针对 Twitter 这样突发流量非常大的站点,相信压缩过以后效率会更理想些。

https://friable.rocks/_/2009_11_05/024525b87c64.jpg

Javascript 方面的问题除了说了上述的 CSS 一样未被压缩过以外,它们还分别载入了两套不同的 Javascript 框架,分别是 Prototype 和 jQuery

相信 Javascript 运行开销会比较大的还有 urchin.js 这个文件,它是 Google 的统计埋点(Twitter 没有自己的统计系统?)。

Twitter 的页面虽然简单,但是如此安排前端脚本,在庞大的流量基数面前,个人认为不应该抱乐观的态度。

其他

Twitter 的 HTML 结构发现,有很多的结构都是被简化了的(可能这是处于针对移动设备的考虑)。

https://friable.rocks/_/2009_11_05/939665b87c68.jpg

有趣的一点就是他们会将很多事情交给 Javascript 去做,比如是否出现「On a mobile phone」的提示。

个人认为针对「无障碍」的 HTML 结构而言,固然是可以这样做(给用户更多的提示信息)。

但对于桌面用户而言,毕竟这是属于多余的结构,所以此类的提示信息应该放在服务器上面判断。当然,反驳本热观点的最好理由就是:其一,坚持「无障碍」的 HTML(结构);其二,减少服务器的运行开支。

--Split--

本人的水平有限,此文希望能起到抛砖引玉的效果。PS:大家想听我发牢骚,可以 去我的页面看看

有关 Cache 的随想

听说 FaceBook 开放其网站的代码了 ,期前也算是了解过 FaceBook 的架构,所以重点就是看其代码的质量。

可以毫不夸张的说,FaceBook 的代码质量、风格都不亚于某个开放源代码的项目(当然,并不是每个开源的项目代码都很友好)。我可以用「教科书式」的代码,来形容我眼前所看到的 FaceBook 的源代码。

有点离题了,开发语言(或者工具)的本身,并不能说明系统会有多么的优秀。目前的网络上所能找到的、开源的工具,只要稍加都能很好的提升性能。

锦上添花的就是加上良好的 Cache(缓存)机制。在「上古时代」,人们对于性能上的考虑,还处在程序也算法的优化上。随着 Web2.0 的到来(什么是 Web2.0?)、Ajax 这样的技术的出现,造成服务器处理的请求比平时多得多,此时就需要从宏观上改进整个系统的机制。

很快就出现了大量的相应工具,首先是 Squid 、然后是 Memcached ,最后是具体到 某个语言(比如 PHP)的扩展正如期前所说的 ,Ajax 等前端技术的流行,Cache 技术逐渐从「后台」的点心,转成了「正餐」。

https://friable.rocks/_/2009_11_05/013005a8266b.jpg

重新回到上述的 FaceBook 中,从上往下看(似乎这图不是完整的逻辑,搞不清楚为什么 Database 会在这个位置),所涉及到的 Cache 技术就有 APC、Memcached、 CDN 以及 浏览器的缓存 。基于这点就能够充分的表明,FaceBook 能够应对如此高的负载的因素之一就是合理的使用 Cache 机制。

Cache 的确是个好东西,但是有时候也带来了不少的麻烦。比如在前端开发过程中,往往就会碰到用户反应样式、脚本无法执行的情况,此时本人就会很机械的告诉他 Ctrl + F5 刷新。

坦白的说,本人认为使用 Cache 在项目中,不应该过分的乐观。Cache 所带来的用户重复刷新(虽然在良好的 Cache 机制下这种情况很少),空间上的逐渐增大(真的是用空间换取时间,想想 FaceBook TB 级别的 Cache 容量吧),这是使用 Cache 所带来的负面效果(但这往往有些技术人员会将此拿来当作炫耀的资本)。

不要将 Cache 作为提升性能的救命稻草。前段时间 Twitter 间歇性的罢工 ,虽然找到瓶颈是数据库。但本人同时也听到某些观点,诸如「如果 Twitter 有良好的 Cache 机制也许就不会这样」,在这里本人保留意见。

请容我胆大的猜想,也许 Cache 会和 Ajax 一样,最终有一天会消失。技术这玩意也就是这样,没有更好的只有最合适的。退一步讲真的到了那一天,Cache 的替代方案也会造成另外的问题也说不准 -- 以后的事情谁知道呢?

https://friable.rocks/_/2009_11_05/071685a850ef.jpg

想起了一句话,就是

「计算机原先是为了解决麻烦才搞出来的,但是后来它本身就成了麻烦」。

我的照片

嗨!我叫「明城」,八零后、码农、宁波佬,现居杭州。除了这里,同时也欢迎您关注我的 GitHubTwitterInstagram 等。

这个 Blog 原先的名字叫 Gracecode.com 、现在叫 「無標題文檔」 。 要知道作为码农取名是件很难的事情,所以不想在取名这事情上太费心思。

作为八零后,自认为还仅存点点可能不怎么被理解的幽默感,以及对平淡生活的追求和向往。 为了避免不必要的麻烦,声明本站所输出的内容以及观点仅代表个人,不代表自己所服务公司或组织的任何立场。

如果您想联系我,可以发我邮件 `echo bWluZ2NoZW5nQG91dGxvb2suY29tCg== | base64 -d`

分类

搜索

文章