快到纪念日了，又开始纠结送给LD什么礼物好，之前看色魔张大妈（什么值得买）一群值友晒各种手工品，看的各种种草，一直没敢尝试，这次想着自己做个当礼物好了。翻了下以前收藏的帖子，仔细的研究了一下，觉得难度不大，应该可以做得来。所做就做，大淘宝买了套基础工具，顺便买了几块半成品料子。选料子真是各种纠结，二十几种，选了半天，后来选了一个尼泊尔紫檀，一个墨西哥黄花梨。买完了后才知道一般都会用柯檀或者紫苏，颜色花纹都会很漂亮，反正第一次弄，选一般的练练手，能熟练了在换好的。
之前吐槽了下微信的开发，最近在钉钉中开发一套业务系统，顺便也吐槽下钉钉好了。
起因也很简单，上一家公司一直再用钉钉作为办公OA，相对于传统OA，钉钉更注重移动办公，手机体验感很好，换新公司后，也推荐使用钉钉作为日常办公OA。设置好后，大家也都开始尝试使用，可能是公司大多数人之前很少使用此类软件，对于OA存在一定抵触心理，不过使用一段时间后也都还好，毕竟每天也就占用几分钟的时间。
钉钉里面的业务模块还是比较少，公司的一个业务模块找不到适合的模块改造，于是准备在钉钉下自己开发。最早是准备单独做，后来考虑到办公OA用的是钉钉，很多业务逻辑都在钉钉里面沟通或者下达，何不也一并做进钉钉里面好了，还省得在单独处理用户和登录认证模块，并且以后系统还可以打通。
说做就做，首先还是看文档，虽然两者的模式类似，都是获取相关认证授权信息，然后接口调用，相比微信简单明了的文档，钉钉的开发文档就显得过于复杂繁琐，经常A模块中出现一个参数b需要在B模块获取，有个链接跳过去，然后再看B模块中有个参数c需要在C模块中获取，然后绕来绕去，最后彻底晕菜了。微信的开发仅针对微信内置浏览器，接口也基本两种模式，一种是程序通过API接口进行数据通信，另一种是用JSAPI的模式数据通信。钉钉开发不仅针对内置浏览器，还有PC版软件和第三方APP，相对提供的接口方式就比较丰富。对于我这个项目而言，主要还是使用内置浏览器方式调用web页面方式。文档大概看了几遍，有了基本概念，加上之前微信开发的一些经验。准备着手开发，毕竟文档脱离了具体项目是很难完全理解的。
由于钉钉存在手机版和PC版，这个业务模块在钉钉两个版本都会使用到，PC版为主，移动为辅，这个就要求页面要自适应宽度，在不同的宽度版本（移动和PC）都要良好的提现，文档中也有对于两个版本的一些宽度尺寸的规范。模块的UI框架直接使用了Amaze UI，这个框架以前项目开发中使用过，文档和易用性都还不错，有些功能或者细节方面还不是很好，不够灵活。不过基本能满足一般项目。（其实还是懒得折腾），框架定好了，刚开始开发就遇到一个大坑，移动版和PC版的JSAPI居然不是同一个，这个一开始没注意到（最开始使用的PC版），等到登录开发完调试的时候才发现，PC版获取钉钉登录信息并自动登录业务系统没问题，移动版直接卡在获取钉钉登录信息那块了。后来多次调试加上仔细看了下文档才发现这个问题。知道问题就好处理，加个移动端判断调用不同的JSAPI文件解决。其实个人认为获取钉钉登录信息通过钉钉自身的接口更好一些，跳转到钉钉的一个认证页面上，获取后在跳转回项目并带着认证信息，钉钉文档里面也有这个接口，不过需要申请才能使用，好像还要有一定的要求，本着不折腾的原则（其实就是懒），暂时用JSAPI的方式处理。接下来就是正常的项目开发，暂时用到钉钉接口的地方不多，最多的也就是将项目里面的信息推送到群里面或者DING下某些人。
钉钉的调试也不是很方便，比微信好的地方就是调试非接口性的功能，钉钉可以在普通浏览器调试，而微信接口控件会直接提示请使用微信打开。但是调试接口方便的，微信可以在官方的开发工具里面调试，而钉钉就只能在客户端调试，好在有PC版的钉钉，至少不用老是在手机上面点来点去了，也希望钉钉会对应出个开发工具，至少方便项目的调试。
针对钉钉不断侵占企业OA这个市场，微信也针对的推出企业微信，虽然之前微信也推出过企业号，但是功能简单，易用性差加上功能没法定制，估计也没多少企业再用。这次的企业微信完全朝着钉钉去的，不可否认企鹅的借（chao）鉴（xi）能力，面对小企业基本能碾死一大片，这回面对阿里，最终结果还不得而知，不过借助微信的势，不可小觑。
PS：工作中的随手记录，并非最佳处理方式，仅作为一种思路。
筹备新系统的过程中，遇到这样一个情况，数据库中一个表已经添加了300条信息，这时候突然从外部直接导入了1000条信息，其中有一部分重复信息，在重复的信息里面，新加入的数据有一个字段数据是原来数据里面没有的。现在需要将重复数据中原来没有的那个字段数据更新到原始数据中，并且删除重复数据。假设数据表结构简约如下：
表A id name phone 1 张三 2 李四 3 王五 ----------------------------- 1000 李四 1234567890 1001 赵六 0987654321
其中虚线以上部分是原有数据，以下部分是批量导入数据，phone字段仅新插入数据有内容。
由于在一个表中，先查下有多少重复数据，SQL如下
select name,count(name) as num from 表A group by name having num>1
有一点要注意就是在group by的语句中where和having的区别，两者处理数据顺序不同，where是在group by之前处理筛选数据，having则是group by之后在处理筛选数据，其中重复的数据大概有接近200条。
下一步就是把重复的这近200条数据中，新加入数据中那一个特殊字段的数据更新到老数据中。思路为先从上面重复数据里面分离出后添加的数据，将后添加数据特殊字段内容更新到前面老数据中，假设后添加数据起始id为1000。
update 表A as aa inner join (select a.id,a.name,a.phone from 表A as a,(select name,count(name) as num from 表A group by name having num>1) as b where a.name = b.name and a.id >= 1000) as bb on aa.name = bb.name set aa.phone = bb.phone where aa.id < 1000
这里不知道是不是mysql（5.6）版本问题还是其他原因，之前使用update……set……from……select……where语句来更新数据的时候报错，后来换成上述语句更新。
更新完了后就是删除重复数据了，主要还是删除后面添加进来的数据。
delete from 表A
where id in (
select aa.id from (
select a.id from 表A as a,
(select name,count(name) as num from 表A group by name having num>1) as b
where a.name = b.name and a.id >= 1000
) aa
)
这里其实多套了一层select，由于mysql中不允许在同一个表中先select出数据在update这个表，会报类似这样的错误 You can’t specify target table for update in FROM clause，中间多加了一层select来规避这个错误的出现。
至此问题处理完毕。其实在一个表中做这样的处理是非常不好的方法，在数据导入的时候先导入一个临时表中，在进行两个表之间的数据处理，从逻辑上和语句上面都简单很多，出现意外错误的几率也会少很多，误操作影响原有数据几率也小很多。
自从去年6月份开始接手微信开发，算下来也有半年多了，其间进坑无数，所幸依旧尚存，不得不吐槽下。
首先要说的就是微信这种开发模式，简直丧心病狂、毫无人性呀，不知道当初开发团队是处于什么考虑的，流程各种绕，前置依赖很多，虽然说有开发文档，但是如果你不去开发项目，仅仅的是看文档的话，直接就绕晕掉了。订阅号和服务号，再加上认证，就是四种类型的账号，对应不同的接口权限，加上微信开放平台的接口，微信支付的接口，零零总总一大堆，居然后面还有应用号，不知道又会开放什么新接口。
其次是调试困难，在官方开发工具出来之前，只有一个简单的网页版接口调试工具，用来检测下通信数据传输和返回值是否正常。对于大部分开发者都是本机开发，微信接口映射到本机就是个麻烦的事情，固定IP的话可以在路由器里面做下端口映射，非固定IP可以用一些动态域名比如花生壳之类的，或者使用ngrok工具，其实也是一种动态域名方法，即便是这样问题也很多，一方面大部分使用都是免费动态域名，每次域名都会变，都需要在公共平台里面修改接口地址，另一方面要使用jssdk接口的话域名需要备案，备案，备案。。。。。说完了后端部分就轮到前端了，由于接口必须需要微信浏览器支持，所以在普通浏览器里面用正常的方法都会显示微信的提示。在官方开发工具出来之前，还没有什么很好的解决办法，基本都是去掉微信jssdk部分调页面的效果，线上调试用微信PC版，可以看到源代码，查看下一些动态的内容是否正常输出，再剩下的问题就要靠经验了。还好微信也意识到自己这个生态环境不是很友善，出了开发工具，感觉就是个深度定制的chromium，使用起来还是比较方便的，至少能解决之前的页面和JS调试的痛处。
再次，微信开发应用使用起来也不是很友好，最严重的就是通过公共平台进入开发的应用，比如现在很流行的微商城，我在浏览商品的时候突然来了一个微信消息或者其他的信息，打开看了后就没回到之前浏览的页面了，尤其是在进行一些流程性的步骤，比如说购买，只能重新来过。通俗点说就是抗干扰能力非常差。这就需要开发者在开发应用的时候简单明了，层级流程尽量的短小，无需过多思考，一两步就能完成。也就限制了大型复杂的系统的接入性，不是不能接入，而是使用体验会很差，一有干扰直接重来。不清楚应用号会不会在这方便有所改变。
最后对于微信这个业态，我一直认为正确的微信模式就是服务号的模式，个人非常反感订阅号，虽然有很少部分订阅号质量非常高，也仅仅泥塘里的一两颗荷花，剩下的都是信息垃圾，各种鸡汤、伪科学、广告推广等等。我们现在处于信息泛滥的时代，人们已经开始由原来的被动接受信息转变成主动获取想要的信息，订阅号那种天天推送的模式反而令人反感，至少对我来说，再加上微信也是注意到了这些，将订阅号全部合并折叠起来，消息的获取宽度更窄，其实也是鼓励运营者向服务号转变。通过之前微信要推出应用号这个消息也能看出来，微信在不断的弱化自身的媒体属性，更多的作为一种平台，或者说是入口。公共平台利用微信上的人脉，加上微信很方便的扫码、摇一摇周边等参与模式，将用户导入进自己的平台系统中去，这种精准化营销是其他平台不具有的。支付宝虽然也在做类似的事情，可是起步晚了很多，虽然用户基数也不小，可是要用户改变已经养成的使用习惯，也是很难的。如果解决好微信开发的应用使用上的问题的话，也可以是企业一个很好的营销入口。
当初因为嫌麻烦懒得去备案，猫窝一直安放在国外，已经好多年了，偶尔服务商调整IP，没注意查看邮件暂时无法访问几天外，整体无大碍，也就是访问慢一些，倒也还在忍受之内。不过近期一连串事情，也让我有了想搬回来的想法。
首先就是备案号，放国外的初衷就是嫌麻烦，也就没有备案号，可是国内越来越多的服务需要提供备案号，第一个就是微信公共平台，近半年来一直在做这方面的开发，虽然公司有些平台账号可以测试，但是由于做活动的需要，经常换来换去，也挺麻烦，自己有个还是方便些，同时做些其他开发也不用拿公司的号来测试，第二个就是一些CDN服务，比如七牛，在这个带宽费用比硬件费用贵的多的时代，图片放在CDN上面还是有必要的，CDN提供的临时域名毕竟太不友好，又长又不好记，肯定是绑定自己的域名方便，但是绑域名同样需要备案号。随着国内互联网管控的越来越严格，很多API接口呀，服务呀可能都慢慢的需要接入域名必须先备案。
话说回来有备案号，网站也不用一定要放在国内，这就说到第二个方面，就是访问速度，近半年网站的访问速度明显下降，主要可能还是要归功于伟大的墙，对很多国外空间商都不很友好，ping起来并不高，但是访问起来明显卡顿。去后台发个文、更新下都要卡半天，那感觉，很不爽。
最后关键的一点就是阿里云做活动抽了张88元的代金券，作为秉持有券不用太浪费的原则，购置一台最低档的虚拟主机，反正就是放个个人博客，再加上也没什么人访问，也不需要多好的配置。然后就是填表提交材料，照相，备案，一气下来也蛮顺利，今天备案号下发下来。
剩下的就简单了，程序打个包下下来，数据库备份下下来，再传上去还原下，解析域名，duang，完成。
以上纯属想当然，实际中也遇到一些问题。
首先就是htaccess文件，这个文件在国外的空间管理系统是隐藏的，打包就没打进去，导致搬家后自定义页面全部都是404，更不用说个性化的用cat作为页面后缀（SEO什么的完全不考虑，我的猫窝我做主），又从原来空间拷下来再传上去。其实在后台上面固定链接里面重新保存下也能生成htaccess文件，只不过原来的里面还有以前老域名的301跳转，所以还是直接拿来了。
站点在墙内了，Gravatar自然而然的挂掉了，头像全都是叉叉，网上搜了下，SSL还没墙，是用这个就好了，添加在主题的function.php中，代码如下
function get_ssl_avatar($avatar) {
$avatar = preg_replace('/.*\/avatar\/(.*)\?s=([\d]+)&.*/','<img src="https://secure.gravatar.com/avatar/$1?s=$2" class="avatar avatar-$2" height="$2" width="$2">',$avatar);
return $avatar;
}
add_filter('get_avatar', 'get_ssl_avatar');
放上去，头像的确显示了，不过都是2倍的大小，问题严重呀，看来这个方法也是很久之前的了，看了下原来的头像代码
<img alt='' src='https://secure.gravatar.com/avatar/cae0907deb928695845b7627d7236a60?s=44&d=identicon&r=g' srcset='https://secure.gravatar.com/avatar/cae0907deb928695845b7627d7236a60?s=88&d=identicon&r=g 2x' class='avatar avatar-44 photo' height='44' width='44' />
为了适配高分屏，头像里面有两个路径，分别对应原始大小和双倍大小，按照上面正则替换全都换成后面双倍大小尺寸，所显示的头像都是两倍大了，而且原来的方法直接把图片标签替换了，原来图片中带的其他参数也全部丢弃了。其实只用替换掉路径就好了，把原来的路径换成SSL的路径，修改后如下
function get_ssl_avatar($avatar) {
$avatar = preg_replace('/[^\']*avatar\/([^\']*)/','https://secure.gravatar.com/avatar/$1',$avatar);
return $avatar;
}
add_filter('get_avatar', 'get_ssl_avatar');
保存，上传，刷新，完美。
另外一个问题就是Jetpack，在墙内虽然也能使用，但是由于墙的存在，很多功能都失效了，而且我这里貌似和后台主题有些冲突，开启插件后，自定义主题就会报500错误，禁用就好了，具体原因不详，在原来的空间不存在这个，可能还是和空间配置或者墙有些关系，反正还有其他的一些替代方法，就暂时不去理他了。
最后试了下定时备份和备份发送邮箱，空间好像有所限制，没法收到备份邮件，看来要勤快点多做备份了。顺便找找有没有其他备选方案。
自从windows 10消息的发布，微软就带了个跳版本号的坏头，直接把9给生吞了，(错怪微软了，ORACLE很早就干过这类事情。)前段时间PHP 7消息的发布，且不说如何如何进步，6也被无情的跳过了。最近在改之前同事thinkphp写的站点，去官网查了下手册，才发现thinkphp 5版本也在悄然上线公测了，3.2直接到5.0，跳过了4这个版本。
跳板本号的原因可能有很多，风俗呀、忌讳呀、个人喜好等等，更多的一种情况是，现行版本和新版本并行开发和维护，对现行版本改动很大的新需求都会放到新版本中，慢慢的新版本需求越来越多，期望越来越大，开发进度却越来越缓慢，最终只有放弃这个分支，重新梳理现行版本的下一个版本，导致版本号的跳跃。
由此可见项目管理的重要度，随着项目的推广，使用人群越来越多，各种声音也不断的出现，有需要增加新功能的，有需要精简的；有的需要改成这样，有需要改成那样，众口难调。一味的迎合用户往往结果就是谁都满足不了，最终只能得到一个臃肿不堪、漏洞不断的项目。坚持项目的初始理念，抓住项目的目标人群，再加上合理的迭代，才能保证项目正常的发展下去。而往往这些都是说起来简单，做起来却要很是下一番功夫的。
魔兽十年 回首望去
刹那间不知有多少的回忆 涌上心田
那个总是给你做面包的法师
也许此时此刻 正在为下个月的房贷忙碌奔波
那个喜欢变成熊跳舞的奶德
则已经忙着在家里面奶孩子了
那个沉默寡言的副坦克
如今做了一家公司的副总
依旧在独当一面着 而那个总是被你调戏的 牧师妹子
现在估摸着呀 也应该嫁人啦
魔兽十年 无数强大的公会败给了时间
多少一起玩耍的伙伴相忘于江湖
在我们的回忆里 它就像一个与现实世界相交的独立空间
我们在此相遇过 却不得不渐行渐远
魔兽对于我们 不仅是一个游戏 它是一整个青春呐——暴走大事件第四季第22期
想想公测的时候加入游戏，期间断断续续，直到熊猫人彻底AFK，和工会的小伙伴们奋斗的日日月月，一次次的FD，感慨万分。电脑中保存了一张MC首次FD的合影，也在几次重做系统中不知去向，就像视频中所说，10年了，当年的一群人现在都已经结婚生子，各自有自己的家庭事业，“相忘于江湖”，不过在这里要谢谢你们，感谢当年一起的游戏的岁月，一起创造的美好回忆。
伢上上周突然高烧，后去医院检查，诊断为疱疹性咽峡炎，幸好发现的早，挂了两天水，貌似没发展起来直接被扑灭了，嘴里的泡丝毫没有影响小家伙的食欲，一顿饭一大碗。然而一周后，本人不幸中招，咽喉痛、发烧，本以为是咽喉炎，挂了两天吊水，紧接着手脚开始出疱疹皮疹，疼的要命，还以为得了手足口了，去医院检查只是病毒感染，开了药，吃了两天慢慢下去了，手上泡也开始结痂蜕皮，一周下来各种折腾，花钱无数。
感觉做程序员这行越来越成为高危行业了，且不说新闻上面各种耸人听闻的猝死报道，私下里同行聊天也发现大部分都在加班中，加班俨然已经成为一种文化，还有各种职业病，像什么肩周炎、腰肌劳损、腱鞘炎之类的技术群里一问，就能炸出一群潜水的，十之八九都有。在医院和医生闲聊，被问及做什么行业的，答之作IT的，医生随后说了句话：你们这行真不是人干的，之前有个人也是搞IT的，头发都快掉光了。除了生理问题，心理问题也不少，码农KO产品的段子，各个版本都有，虽然大部分仅仅是段子，但也反映负面情绪的积压。
许多人刚步入社会前几年凭着自己年轻，猛打猛拼，经常通宵加班，几年下来，虽然别人看起来小有所成，然后身体搞垮了，痛苦也只有自己知道。而往往前几年都是学习积累的过程，再加上程序员一般都不善于经营自己，做出的再大的成就往往都是公司的。等你各方面都准备好做一番自己的事业的时候，常常还没有被对手打败，先被自己的身体狠狠的踩在脚下。
月初和几个同学小聚，聊天打屁之外顺便也相互打听下近况和其他有联系的人的情况，才得知原来隔壁寝室的同学的夫人肺癌晚期，大学时代辅导员夫人年初刚过世，也是癌症复发，当时小聚的几个人唏嘘不已，在座的几个也都有各种各样身体小恙，平时应酬也是能推就推，有空就相约打球健身。想想自己还是依旧保持那种亚健康的状态，天天上班一坐一天，一周也都没出去运动下的，周末也都是各种理由，其实也就是懒罢了。也难怪今年整体状态都欠佳，动不动就各种小病，什么感冒什么拉肚子，也是要改变下了。尤其是现在有了小孩，一生病就容易传染给小孩，大病号、小病号都要夫人一人照顾，再加上家务，一周下来也累的不行。
有一档儿童节目主题曲里面有这么一句：财富就是家人全都没有嗝屁。一家人健健康康的比什么都好。以前一个人的时候很少考虑这些，现在有家有小孩了，责任也就多了起来，自己是家里的天，不能这么轻易被身体打垮。做一个全身体检，在制定一个循序渐进的运动计划，希望在春季身体状态、精神状态有个明显的转变，为下一步的计划做好先前准备。
PS:隔了天再写，完全不知道当天的思路，写东西还是要一气呵成，断断续续的都不知道写的是什么了。。。
日常浏览rss，无意发现这个好玩的，顺手点了下，看起来还欠缺的很呀，技能树传送门。
我的网页开发技能树
这几年技能是涨的越来越慢了，几近停滞，每次总能找到各种借口，看来是要挂这里鞭策下了，看看一年后有没有新的长进。
前段时间由于IDC升级服务器，将原来服务器上的虚拟空间更换到新的服务器上，不知道中途到底出了什么岔子，导致博客丢失了将近半个月的数据，本人算是比较懒的了，影响不大，也就一篇文章。毕竟是自己的原创文章，其他地方也没备份，总不能辛苦白费。于是乎除了联系IDC方面，自己也想办法恢复了。
最开始想到的就是订阅里面应该有，从好几年前就开始有RSS订阅的习惯，很多有帮助的博客或者网站都订阅到RSS里面，最早当然使用谷歌RSS订阅服务，自从谷歌关闭了这个服务后就转战feedly了，很多人都说谷歌RSS一死，世上再无好的RSS工具，不过对于我来讲，也就算是个轻度用户，每天浏览下订阅的文章，有兴趣的点进去看下，然后直接全部标记成已读，好的文章会用pocket收集分类下。之前听说ifttt支持feedly直接到picket，后来注册了才发现要成为feedly收费用户才能使用，只有手动来处理了。不过feedly居然把搜索功能作为收费会员功能，忍不住要吐槽下。
以上跑题跑远了。。言归正传，免费版是没有搜索功能的，只能点到自己的博客的rss里面，最新的一篇就安静的躺在那里，复制出来，重新发布下，顺便调整了下发布时间，像是原来时间点发布出来的。呵呵。不过浏览量和评论就没有了。
另一种方法就是使用搜索引擎的快照功能。我的博客百度收录很差，这里直接使用谷歌了，如何使用谷歌就不再累述了，作为一个技术宅，自备各种梯子。使用site:makumo.com 加关键字的方式很快的就找到之前丢失的那篇文章,点击链接右侧小箭头会出来网页快照，打开直接复制重新排版发布就行了。
不过最好的办法还是多备份，防患于未然。
PS：最近chrome起始页和谷歌搜索各种跳日本域名，用了https://www.google.com/ncr 都没什么效果。用的是加拿大的梯子，估计这个IP被谷歌判定成日本了。。各种无语。