草名园

找到优秀的免费主题越来越困难，随着wordpress的发展和普及，大量劣质的wordpress模板出现，另外，越来越多的设计师开始出售wordpress主题。
尽管如此，我们还是努力找到100个优秀的wordpress主题，并整理发布，相信会为读者留下深刻的印象。 One Room [Demo]

Read the rest of this entry »

WordPress, wp, 主题

博彩v3这次做了一个小小的更新~但是版本号并未做修改。呵呵没有那么正式，就先用着吧~
主要是：

• 1.支持双赔率。
• 2.支持强制流盘。
• 3.修复投注65536溢出限制。
• 4.加入倒计时。
• 5.个别页面做美化调整。
• 6.修正若干处派彩算法错误。

最新的博彩尽在:博彩演示站 http://gamble.crazyi.cn 。
请已经安装过博彩v3的朋友联系我索要博彩更新文件包。
【预告】下一次修改收集到的建议：
1.动态赔率。
2.平局赔率。
3.赔率图谱分析。
以后将陆续更新博彩。欢迎给予意见和建议哦~

discuz, 博彩

很久前就看到飞信有开放了一个API。还在网上看到了php版本的。那时候就想写一个基于wp的飞信评论提醒插件。呵呵~无乃对wp开发插件不是很熟悉。今天看到yinheli 同学写了这个插件。

点击这里查看原作者的介绍

下载来使用了下，总体很不错~~可惜这个api是基于curl的。服务器php还不支持curl。花了不少时间安装了下curl。使用起来还不错。呵呵~可以通知自己博客有评论，真好！。晚上出去食饭。直接晕死。垃圾评论一堆一堆飞过来。手机都快被飞信给刷爆了~赶紧关机！原来这个插件没有过滤垃圾评论。于是手动给加了一个开关~

稍微调试了下。哈哈。现在：垃圾评论请离我远点。已经成为现实！

其实也没有修改什么就加了一个扩展开关。

需要下载我修改的文件请点击这里：

  fetion_alert (11.9 KiB, 96 点击数)

API, WordPress, 插件, 飞信

经常在网上看到这样的一些字体，觉得很有意思。于是就想去下载个，搜索“像素中文”字体，发现根本就没有这么一说，只有像素的英文字体。找了半天就找到一种叫“蒙纳点阵字体”发现根本就不是那么回事。

继续搜索，据前辈说，宋体和微软雅黑都可以做到像素级别。
Baidu上提问，有个大哥说，用PS里面混合图层选项的描边就OK了，试了半天，效果不如人意。感觉边角很是模糊。后来又有个Baidu里的大哥回答说，要把字体的效果，改成“无”（就是有“圆滑”“锐化”等选项的，就在字体样式的右边）。
说说详细的制作吧，新建一个文字图层，把文字的样色改成白色，在文字图层上点右键，选择混合模式选项。修改混合模式里面的最后一项，描边。把描边的粗细改成1像素，颜色改成黑色，默认的是描外边。这样就OK啦。字号大概是选择12号字。这就是我做的啦：
nice吧。

PS, 像素字体

加入湖里管理团队3年来经历2次改版，说实话管理方面没有出什么力，做的都是一些技术性质的维护和功能扩展。渔梦湖孕育了博彩插件的诞生，从1.0版本到现在v3.一直有湖里广大体育爱好者的支持，让我十分欣慰，他们也是我不断升级博彩的主要原因。呵呵~还是啰嗦下，实在觉得版面不怎么样。坑！你是不是退步了啊，整个界面看起来有点小气。灰暗灰暗的。用着心里毛毛的。担心的是由于改版后版面影响人气。播放器方面还不错，功能蛮强大的。就是一个问题没有解决，刷新后又重头开始播放。这个需要解决下。

改版, 渔梦湖

什么是UUID？

UUID是Universally Unique Identifier的缩写，它是在一定的范围内（从特定的名字空间到全球）唯一的机器生成的标识符。UUID具有以下涵义：

• 经由一定的算法机器生成

为了保证UUID的唯一性，规范定义了包括网卡MAC地址、时间戳、名字空间（Namespace）、随机或伪随机数、时序等元素，以及从这些元素生成UUID的算法。UUID的复杂特性在保证了其唯一性的同时，意味着只能由计算机生成。

• 非人工指定，非人工识别

UUID是不能人工指定的，除非你冒着UUID重复的风险。UUID的复杂性决定了“一般人“不能直接从一个UUID知道哪个对象和它关联。

• 在特定的范围内重复的可能性极小

UUID的生成规范定义的算法主要目的就是要保证其唯一性。但这个唯一性是有限的，只在特定的范围内才能得到保证，这和UUID的类型有关（参见UUID的版本）。

UUID是16字节128位长的数字，通常以36字节的字符串表示，示例如下：

3F2504E0-4F89-11D3-9A0C-0305E82C3301

其中的字母是16进制表示，大小写无关。

GUID（Globally Unique Identifier）是UUID的别名；但在实际应用中，GUID通常是指微软实现的UUID。

UUID的版本

UUID具有多个版本，每个版本的算法不同，应用范围也不同。

首先是一个特例－－Nil UUID－－通常我们不会用到它，它是由全为0的数字组成，如下：

00000000-0000-0000-0000-000000000000

UUID Version 1：基于时间的UUID

基于时间的UUID通过计算当前时间戳、随机数和机器MAC地址得到。由于在算法中使用了MAC地址，这个版本的UUID可以保证在全球范围的唯一性。但与此同时，使用MAC地址会带来安全性问题，这就是这个版本UUID受到批评的地方。如果应用只是在局域网中使用，也可以使用退化的算法，以IP地址来代替MAC地址－－Java的UUID往往是这样实现的（当然也考虑了获取MAC的难度）。

UUID Version 2：DCE安全的UUID

DCE（Distributed Computing Environment）安全的UUID和基于时间的UUID算法相同，但会把时间戳的前4位置换为POSIX的UID或GID。这个版本的UUID在实际中较少用到。

UUID Version 3：基于名字的UUID（MD5）

基于名字的UUID通过计算名字和名字空间的MD5散列值得到。这个版本的UUID保证了：相同名字空间中不同名字生成的UUID的唯一性；不同名字空间中的UUID的唯一性；相同名字空间中相同名字的UUID重复生成是相同的。

UUID Version 4：随机UUID

根据随机数，或者伪随机数生成UUID。这种UUID产生重复的概率是可以计算出来的，但随机的东西就像是买彩票：你指望它发财是不可能的，但狗屎运通常会在不经意中到来。

UUID Version 5：基于名字的UUID（SHA1）

和版本3的UUID算法类似，只是散列值计算使用SHA1（Secure Hash Algorithm 1）算法。

UUID的应用

从UUID的不同版本可以看出，Version 1/2适合应用于分布式计算环境下，具有高度的唯一性；Version 3/5适合于一定范围内名字唯一，且需要或可能会重复生成UUID的环境下；至于Version 4，我个人的建议是最好不用（虽然它是最简单最方便的）。

通常我们建议使用UUID来标识对象或持久化数据，但以下情况最好不使用UUID：

• 映射类型的对象。比如只有代码及名称的代码表。
• 人工维护的非系统生成对象。比如系统中的部分基础数据。

对于具有名称不可重复的自然特性的对象，最好使用Version 3/5的UUID。比如系统中的用户。如果用户的UUID是Version 1的，如果你不小心删除了再重建用户，你会发现人还是那个人，用户已经不是那个用户了。（虽然标记为删除状态也是一种解决方案，但会带来实现上的复杂性。）

UUID生成器

我没想着有人看完了这篇文章就去自己实现一个UUID生成器，所以前面的内容并不涉及算法的细节。下面是一些可用的Java UUID生成器：

• Java UUID Generator (JUG)：开源UUID生成器，LGPL协议，支持MAC地址。
• UUID：特殊的License，有源码。
• Java 5以上版本中自带的UUID生成器：好像只能生成Version 3/4的UUID。
  

此外，Hibernate中也有一个UUID生成器，但是，生成的不是任何一个（规范）版本的UUID，强烈不建议使用。

延伸阅读

UUID规范：rfc4122
DCE 1.1中的UUID

MySql, uuid, 数据库

渔梦湖　博彩数据是转换好了，沙坑说首页需要调用最新一期的竞猜信息。以实现信息的全面性。好吧，就调用吧，怎么调用呢？想到之前搞过小偷的ajax(之前为香港一客户做的一个动态加载汇率的)。其实原理很简单：就是使用AJAX配合PHP 采集。
昨天就碰到AJAX　编码问题了。话说 AJAX　使用中文出现乱码有两种情况：

• first:向服务器端发送中文参数时（xmlhttp.open(“get|post”,url,true)）,服务器端接收到的为乱码。

解决方法：因为AJAX发送数据都是采用UTF-8编码的方式发送的，所以要在服务器端进行编码转换（针对页面是采用GB2312编码的，如果是采用UTF-8的话应该不会有这步的问题），所以我在服务器端进行了UTF-8转GB2312。然后客户端　也就是发送xmlhttp的　ajax代码段　也要做相应编码修改。

然后再到服务器端进行URL解码：

注意：解码必须在编码转换前面，不然得不到正确值

• sec:服务器端向客户端输出中文时出现乱码

解决办法：
只要在服务器指定发送数据的格式：
在服务端php文件头部加入：

就可以了

ajax, PHP, 乱码

昨天搞了一下午的数据转换。终于把博彩FOR 6.1 的数据全部转成 V3的格式了。但是部分信息还是丢失了(由于原来的for dz 6.1没有投资这个功能，新功能一来，没有基础数据支持。这一部分只好虚拟一些出来了，呵呵。但是不影响排名和统计).由于For dz 6.1的博彩数据库冗余太大了。代码冗余量也大。在做v3的时候就在考虑要重新做，也花了不少时间今年春节期间v3也顺利出炉了.全新界面，全新玩法。导致脱离了原来的FOR dz 6.1的版本.当时也没有写升级程序,人懒,闲太麻烦了。 如今渔梦湖要升级改版了。为博彩转换数据库在所难免。由于使用的是全新设计的数据表，转化的时候花了不少时间来捣鼓.还专门写了几个MYSQL存储过程来实现批量转换。本来想做函数的，查了下手册好像　mysql函数不能直接操作数据表(手册上说这个就是存储过程和函数的区别).毅然现学现用，找老毕要了本MYSQL5.0存储过程手册来小LOOK下。发现存储过程也不是那么难的说～升级程序也不做了。如果还有人在使用我的博彩FOR 6.1　想升级成为V3.0，请联系我。

博彩, 存储过程, 转换