易栈网-膘叔

7C-D1-C3   (hex)		Apple Inc   7CD1C3     (base 16)		Apple Inc   				1 Infinite Loop 				cupertino cA 95014 				UNITED STATES

原文来自：http://bbs.weiphone.com/read-htm-tid-5557565.html

知识普及：
根据世界IEEE联盟规定，所有的带有无线连接的设备，必须具有一个全球唯一的MAC地址。
MAC地址由IEEE联盟分配给各个厂家，就像每个人的身份证号码一样，不可能重复。
而，根据MAC地址的前6个字符，在IEEE官网可以查询是分配给哪个厂家的地址。
根据我的经验，苹果的产品，Mac电脑的wifi的MAC地址、蓝牙MAC地址、苹果鼠标蓝牙MAC地址，键盘MAC地址以及iPhone的wifi地址的查询结果均为“Apple Inc”
因此，我们可以把自己鼠标或者键盘的MAC地址输入到iEEE官网查询，若为Apple，则正品，否则，山寨。
当然，也有一些有趣的现象，三星、索爱等手机的结果也是其自身厂家，然而，Thinkpad等使用英特尔无线网卡的电脑的wifiMAC地址的查询结果为“Intel”，摩托罗拉某型号安卓手机的wifiMAC地址结果是“台湾奇美（CHI MEI）通信”

查询地址：http://standards.ieee.org/develop/regauth/oui/public.html
查询方法，进入改地址后，在下面的搜索栏输入自己的MAC地址前6个字符，例如“3F-01-AC”然后确认即可
注意，无空格、字母用大写，中间用减号-隔开，否则是查不到的

怎样找到自己的MAC地址？
很简单，在Mac系统下，点击屏幕左上角苹果图标，关于本机，更多信息，系统报告，左边选择“Bluetooth”（蓝牙），然后右边中下部会有：

Devices (Paired, Favorites, etc):
XXXXXX（你的用户名）’s Mouse:
Address: 7c-d1-c3-43-xx-xx
不过一定记得查询时只需要前面6个字符，然后一定要改为大写！！
不要写成了第三行那个MAC地址，那是你自己电脑的MAC地址！！

很简单的命令：

今天下午借着sunx的帐号，想下载IOS7，结果发现卡的不得了。反而是在macx.cn上发现有人提供了下载，在百度的云盘上。并且google了一下怎么安装：打开itunes ，在按住option的情况下点击check update，然后选择下载包即可

安装很快，基本上15分钟不到就搞定了。

界面果然是象毛玻璃，并且在iphone4s上有点卡，真心卡的。很多时候操作起来都是一顿一顿的，

看了一下设置，拜托，不需要绑定这么多的帐号吧？

毛玻璃也太毛了。。

有点操作倒是挺舒服的，比如，手势向上的时候，可以打开控制面板。从顶部向下的时候，则仍然是以前的notifytation界面，不过这次将日历任务整合在一起了

原来的spotlight不见了，不再是单独一屏了，在主界面，手势向下则可以启动spotlight。

一切都看上去不错，只是在短短的下午五个小时左右，我自动重启了3次。有点纠结

本来也准备下载小牛安装的，但看到了网上有人说装了启动不了，所以我忍了。。等正式版吧

wwdc已经过去好多天了，我没有看视频，就看了一下网上的那些文字直播。当然也去apple官网看了一下osx的preview和ios/ios7的简介

对于osx，我是非常感兴趣，其中有几个理由是，消息提醒更加合理了，日历终于可以扔掉一些第三方软件了，内存使用更少了，电池使用更长了；地图什么的，我兴趣不大，毕竟在国内用不上这些玩意。程序后台可以挂起，safari的效率和性能都提升了。safari默认好象不加载flash了。。

ohyeah，这些太让人兴奋了。

ios/ios7中对我来说，好象 就那些快捷菜单让我兴奋，不过，据说操作体验是非常爽，但我还没有测试，不过今天倒是有人在群里贴了一张图：在使用杂牌数据线的时候，IOS会提醒你用的不是标准线。

fonttool.jar

ios新版发短消息的界面也挺有意思，消息会嗖的弹上来，看起来不错。

对于我IP4s来说，跑IOS7可能会比较卡，所以我关注的并不多。

osx的10.9小牛beta。就等你了，（可惜没有99的mac developer 帐号，不然就能下载了）

之所以要记录它，是因为为了这个手机，我跑了4次南京路。。。

就在wwdc 2013的前夜。osx升级了。。10.8.4就这样提示我安装了。

好吧，反正闲着也是闲着，而且说不定也没资格升级到10.9，我还是就这么随便先升到10.8.4吧。

在用一个jQuery插件的时候，突然报错：b.browser undefined。。。

最初的时候想想不太可能啊？browser的判断不是从1.2.1的时候就一直就有了吗？于是搜索了一下jquery.mini.js，搜索browser，居然找不到。。。。

然后去官网看了一下，看到官方居然有这么一段：

<script src="http://code.jquery.com/jquery-1.10.1.min.js"></script>
<script src="http://code.jquery.com/jquery-migrate-1.2.1.min.js"></script>

居然建议我们加载migrate，打开这个文件搜索browser。。果然找到了。

于是在项目里加入这一行，不报错的。做个记录。（不就7K嘛。干嘛不放进去，真是的。。）

说实话，我还是挺喜欢这个标签选择器的，但是评论里说了，除了chrome外，其他浏览器几乎都不支持。因此，我就很纠结了。。

;(function(){
$.fn.extend({
iSelectTags:function(options){
var iset={
name:'.tagsbox',//表单或class或id名
drop:$('#dropbox'),//弹出框定位
pseudoClass:$('#dropbox>p>a'),//可选择的标签定位
close:$('em.close'),//关闭按钮定位
separator:',',//标签间分隔符,建议使用英文逗号
maxCount:10 //默认限制个数,也可以设置表单的data-count值覆盖默认值
}
options=$.extend(iset, options || {});
var _input=$(iset.name);
var _inputVal=_input.val();
var _arr=new Array(); //存放标签的数组
var _left=_input.offset().left; //左绝对距离
var _top=_input.offset().top+_input.outerHeight(); //上绝对距离,此处要加上表单的高度
var _dropW=_input.outerWidth()-parseInt(_input.css('border-left-width'))-parseInt(_input.css('border-right-width'))-parseInt(iset.drop.css('paddingLeft'))-parseInt(iset.drop.css('paddingRight'));
iset.drop.css({'position':'absolute','left':_left+'px','top':_top+'px','width':_dropW+'px'});
//弹出框的宽度,此处计算的是与表单实际宽度相等的.也可以直接在样式中定义.
var _txt=null;
var _maxCount=parseInt(_input.attr('data-count'));//限制选择个数
if(isNaN(_maxCount)){
_maxCount=iset.maxCount
}

_input.click(function(){
iset.drop.show();
iset.drop.bgiframe();//调用bgiframe插件,解决ie6下select的z-index无限大问题
}).bind('keyup change',function(){
//可以在此处扩展手动输入标签情况下的相关判断
//if语句可避免清空重新选择时第一个字符为逗号
if ($(this).val() == '') {
_arr = new Array();
}else {
_arr = $(this).val().split(iset.separator);//当用户手动删除或修改标签值后更新标签值
}
});

$(document).click(function(e){
//点击非弹出框区域时关闭弹出框
//下面的 if语句是用来判断传入的是class还是id
if(iset.name.charAt(0)=='#'){
if(e.target.id!=iset.name.substring(1)){
iset.drop.hide();
}
}else if(iset.name.charAt(0)=='.'){
if(e.target.className!=iset.name.substring(1)){
iset.drop.hide();
}
}
});

iset.drop.click(function(e){
//阻止弹出框区域默认事件
e.stopPropagation();
});

iset.pseudoClass.click(function(){
//标签选择
_txt=$(this).text();
//下面的$.inArray是用来判断是否重复
//若想反馈重复提示或走出限制个数提示,可改进下面的if语句
if(($.inArray(_txt,_arr)==-1) && (_arr.length<_maxCount )){
_arr.push(_txt);
_inputVal=_arr.join(iset.separator);
_input.val(_inputVal);
}

});
//关闭按钮
iset.close.click(function(){
iset.drop.hide();
});
}
});
})(jQuery);

说实话，关于存储过程的博客还真的不多，有几个是值得看一下的

1、官方；http://dev.mysql.com/doc/refman/5.1/zh/stored-procedures.html

2、http://www.netingcn.com/tag/%E5%AD%98%E5%82%A8%E8%BF%87%E7%A8%8B

3、http://blog.why100000.com/?p=711

也发现，如果不做复杂查询，存储过程对我来说几乎没有，本来是想解决查找GEO相关的信息的，但发现这样的SQL：

SELECT userid,lat,lng,gender,
( 6371 * acos( cos( radians(31.000700) ) * cos( radians( lat ) ) * cos( radians( lng ) - radians(120.000099) ) + sin( radians(31.000700) ) * sin( radians( lat ) ) ) ) AS distance
FROM `user_geo` WHERE last_activity_time > '2013-03-11 00:00:00'
ORDER BY distance ASC limit 100

这其中的复杂度就在于distance每次都要计算，所以我尝试换成了存储过程：

DROP PROCEDURE IF EXISTS search_around_user;
DELIMITER //
CREATE PROCEDURE search_around_user
(
s_lat float(10,6),
s_lng float(10,6),
s_last_act datetime,
s_gender tinyint,
s_number tinyint,
s_page tinyint
)
LABEL_PROC:
BEGIN
if s_number <= 1 then
set s_number = 20;
end if;
if s_page <= 0 then
set s_page = 0;
end if;
if s_gender <= 0 then
set @genderQuery = "";
else
set @genderQuery = concat(" and gender = " , s_gender , " ");
end if;
set @limitQuery = concat("LIMIT " , s_page * s_number , " , " , s_number , " ");

set @strsql = CONCAT("select userid, ",
"( 6371 * acos( cos( radians(",s_lat,") ) * cos( radians( lat ) ) * cos( radians( lng ) - radians( ",s_lng," ) ) ",
"+ sin( radians( ",s_lat," ) ) * sin( radians( lat ) ) ) ) AS distance ",
" FROM user_geo where last_activity_time >= '", s_last_act , "' " , @genderQuery , " ORDER BY distance " , @limitQuery) ;

prepare stmtsql from @strsql;
execute stmtsql;


END LABEL_PROC;
//
DELIMITER ;

然后再次调用：

call search_around_user(31.000700,120.000099,'2013-03-11 00:00:00',0,20,0)

所耗费的时间和上述直接写SQL的时间是几乎一样的。想来，这也是因为distance的计算不能被优化而导致的。。。于是乎，放弃用存储过程

继昨天的处理之后，又来新的笔记 ，这次的笔记纯粹是个人的测试，与实际条件有关，比如，我要查询的字段不超过varchar的255的长度，所以我才这么做。

昨天做普通索引后，1100万条记录，索引 为220M，改成全文索引后，索引文件为1.1G，存储空间上，涨了5倍左右。

以下是笔记 ，请不要笑话，场景不同而已

• 经过测试
  • title 字段改为全文索引后，在1100万条的时候
    • 优点：
      • 速度也为0.0x秒级。速度非常快
      • 即使有or条件，只要带了limit参数，速度也非常快
    • 缺点：
      • 如果查询不带limit ,直接卡死，因为他要计算total count
      • select count() 卡死
      • 如果查询不存在的关键字，卡死
  • 使用方法
    • 尽量不做select count 查询 （数量低于100万时可以考虑，超过100万时，其实已经没有必要）
    • 查询一定要带上limit条件
    • 每次查询到不存在的关键字时，记录到关键词库，每次有新增记录时，select 关键词库一下，如果新增房间中有关键字，则将关键词去除，避免卡死
• 暂时不使用coreseek（sphinx）/xunsearch等第三方工具
  • xunsearch只支持分词查询，不支持完全匹配
  • 第三方工具，耗内存，而且增量的时候，不够及时