其实最开始接触区块链、虚拟货币的时候也算是很早了，那时候在v2ex上面看到一篇帖子Ripple 送币，然后就去领取了2020个瑞波币，基友也领了这么多，当时有人疯狂收这个币，于是基友50块卖掉了，我80块卖掉了，当时并没有觉得它是个什么玩意儿，也没有特别去研究这个虚拟货币的相关技术和资料，就这么错过了，如果把这个2020个虚拟货币留到现在的话，价值最高大约50000人民币，这边是我对虚拟货币的最初相识了。后面也有听到过关于比特币的新闻，但是也就当做一个新闻而已，没有特别关注它，直到去年6月份的时候，我入职的这家金融公司，在入职培训的时候讲师讲到了一些理财相关的内容，提到了比特币、区块链、虚拟货币，这样的字眼，而且刚好我所在的开发组的一个同事也从中赚了很多钱，而且是很客观的营收比，于是乎，我也就在当时的虚拟货币交易所里面注册了一个账号，买入了一些虚拟货币试试看。
好像很久之前就会想象过自己的婚礼会是什么样子，当然中二时候的我想象的都是极尽奢华，恨不得要把全世界最闪亮的东西都放到我们的婚礼上献给我的新娘，或者有时候突发奇想，弄得像超级英雄拯救美人儿一样，总之还是幼稚的可爱。婚礼之前还在预告自己，肯定不会那么紧张，毕竟自己不是一个生性害羞的人，但谁尝想到，婚礼上走路顺拐的人也是我，总之，你不会心跳低于一百八度过你的婚礼，因为那是你人生中最重要的那一天。
这可能是第一篇真正在中秋之前能完成的文章（事实证明，还是拖到了十一之后，哭），不知不觉毕业已经整整五年了，思想汇报系列也从二十一岁写到二十六岁（点击这里查看）了，这个博客也跌跌撞撞的走过了六个年头了，后面想想是不是要该挪个地方了。在二十六岁这一年，大部分的时间还是过得平平淡淡的，也会在这里说道说道，其中最重要的事情，当然就是在2017年里，要和我走完一生的姑娘完成一场仪式，想必我会再写一篇文章来专门记录它（敬请期待哟–一个在自己婚礼上走路顺拐的新郎如是说）。
过往尽成废墟，未来不可知悉，唯有当下教我们万般珍惜。——《吴哥之美》。
早在离2016年落下帷幕还有几个月的时候，我和小马就打算在年底趁着年假清空再次出境玩耍一趟，初步定下了泰国，日本，菲律宾等几个国家备选，但是谁料泰国国王驾崩，日本签证来不及办理，于是乎窝们就又把目光瞄准了其它东南亚国家。最终就选定了柬埔寨暹粒这个地方，看一下世界七大奇迹之一、联合国教科文组织推荐的吴哥窟了。吴哥窟也是很多著名电影的拍摄取景地，包括《古墓丽影》《花样年华》《虎兄虎弟》。去之前，最好是能了解一下当地的文化和历史，这样在参观的时候才知道这些古迹背后的由来和传说，如果不了解的话会感觉看几天的寺庙容易审美疲劳，因为都是一些遗迹和断壁残垣，如果事先了解一下吴哥曾经的历史和故事，就不会感觉那么的枯燥无味了。在这里推荐《Lonely Planet 柬埔寨》，做为通读的资料不错，和蒋勋的《吴哥之美》记录片，可以提前看一下，蒋勋老师在视频中娓娓道来很多吴哥古迹背后的故事和神话。
实际上这是一篇应该在中秋时候就完成的文章，但是拖延症越来越猖狂，于是就一直从中秋延期至了冬至（我翻了翻去年和前年的文章，貌似开头都一样，拖延症啊拖延症），不过还好的是，即使是快到了冬至，深圳的天气也没有冷到让我受不了的地步。每年到了需要回顾这一年的时候，总是有很多感受，有好有坏，有喜怒哀乐，不知道等到自己老了的那一天，会不会把这些文章搜集起来，装订成书（不过懒癌转世的我……）。
说来我的护照已经饥渴难耐了好几年了，然而还是个白本儿，刚好趁着小马儿换工作的空档，留下来几天假期，准备和小马一起出去玩耍一趟，毕竟距离上次出远门二已经过去三个月啦，在家里列出了好几个地点，四川啦、青海啦、韩国啦、泰国啦，最终，在权衡斟酌了好久之后，目的地就选定了韩国，济州岛，一个不用麻烦签证的地方。由于离假期只有十来天的时间了，机票和酒店已经来不及提前预定了，而且如果此时预定的话价格肯定很贵，所以我们就选择了最方便的互联网产品，找了好久终于在途牛找到一个四天三晚的济州岛之旅，时间和价格刚刚好都符合预期，就果断下了单，http://www.tuniu.com/tours/210239399于是和小马儿的周游世界之旅的第二站——济州岛，就这么愉快的出发啦！
整个2016年过了将近一半儿了，但还没有真正的出去长途旅行一次，一方面是因为工作有点忙碌，一方面是因为不想一个人孤独的出行。不过好在，上帝可能突然想起来我这个小可怜虫了，五月的尾巴的时候，一个姑娘从天而降来到我身边，上帝还告诉她要带我看这世界的名山大川，走遍这世界的壮阔波澜，告诉她要把我从苦难之中拯救出来，我便牵起她的手，不想放开。
其实这篇文章早应该在中秋时节就应该写了，也不是因为拖延症作祟，只是那时候可能不知道该怎么写，刚好时间马上就要划过2015年了，总是要把这一年的喜怒哀乐说道说道。老家有种说法，讲说是人在本命年的时候，总会发生点什么，要么跌入低谷，要么冲向高峰，为此我的母亲还为我求了一串手链，上面串着三颗“转运珠”，我向来是不太相信这些东西的，但是手链我还是坚持带着，一直没有脱下，就当是一种幸运的守护吧。
最近在做一个图片抓取系统，其中有一个地方是需要用到获取远程图片的长宽，大小，和格式信息；不过一提到获取这样的信息，那么脑海里马上就会浮现 getimagesize() 这个函数，但是，在真正用到的时候才发现，这个函数很笨，效率很低，一方面是它会把这个图片直接下载下来，然后再获取其中的信息，而我们又知道，下载东西，CURL肯定是迅猛无比的；那么能不能把这两者结合起来呢~ 但是问题又出现了，如果我用CURL的方式，就不太容易获取图片长宽信息了，不够方便，于是乎我就翻阅了文档中和图片有关的函数，就找到了这么一个getimagesizefromstring()，刚好符合我的要求！于是乎你只需要下面这个函数就可以比较高效的获取啦！
对厦门的印象最早来自于拥有美丽校园的厦大，后来又了解到它是一个海滨城市，它有一个美丽的小海岛，叫做鼓浪屿。而最近一次和它有交集，是来自于《烈日灼心》这部电影，它的拍摄地就在厦门，而且它的片尾曲就是改编自民谣歌手白水在曾厝垵写的一首歌《曾厝垵》。所以趁着这个空挡，我就买了票，去往一趟厦门。还是记一下这次的流水账吧，毕竟也是很久之前就想去的地方，终究也算是了却了一个心愿罢。
由于以前一直接触的是互联网业务，所以使用 Mysql 数据库的比较多，也比较熟悉。但是现有的金融公司一般使用的都是比较稳定的 Oracle 解决方案，所以在用户量较大的情况下会遇到一个比较麻烦的问题：Oracle 下的高并发。 问题描述：由于同时访问某个应用的用户量非常大；导致后端不断查询数据库，虽然每个 sql 语句的查询时间很短，但是由于要不断的连接->查询->断开，所以Oracle服务器会发现很多的查询进程，一个接一个，由于每个sql执行的时候，服务器会分配一些资源和内存给这个查询，所以在并发非常大的时候，悲剧就产生了，CPU和内存的使用率马上被推上峰值，负载马上压到最大，然后所有的 sql 查询全部变慢，变慢导致的后果是，应用服务器下的 Apache 进程时间越来越长，由于用户还在不断的查询，所以后面进入的apache进程会一直处于等待状态，而正在执行的进程缺越来越慢，果不其然的是很快，应用服务器马上也被拖垮。 解决方案：实际上这样的情况有很多方法优化，此处就着重描述一下在有限的服务器资源的状况下引入的一个数据库驻留连接池的特性，当然，这个特性 JAVA 已经自带了，而 PHP 需要修改一些配置，也可以使用。
我的母亲是一位坚韧的女子，六十年代的时候，她出生于一个大山中的小村落，是家里的最后一个孩子，排行老四，前面有两个姐姐和一个哥哥，我的外婆眼睛看不见，也是一个苦了一辈子的人，在剩下母亲之后没多久就去世了，以至于我和母亲谈起外婆的时候也都只是听别人说起的；外公更是一个劳苦里面顶天的男人，几乎以一己之力撑起这个家，饥荒的那几年，下田挖野菜，上山捋榆钱儿，想尽一切办法养活这一家的每一个人；跟母亲谈论起她小时候的生活，她也只是断断续续告诉我一些故事，我也只能用这些故事，拼凑出那个年代她的样子；
记得之前也为春节写过一些文章，类似于这篇《少年不知愁滋味》，其实这篇文章已经把我小时候的春节已经有个轮廓了，之所以又要提笔重写一次，是因为今天回了趟老家，世事变迁之迅速已经需要我用文字来记录一下了，有后辈问我你儿时的春节是什么样子，我还能凭借着文章回忆一二。不过，这次回老家，变化着实太大。
在很多时候，我们发布一个iOS应用，其实是没必要一定走Appstore的，审核啊什么的比较费时，需要时间，比如这次的年会APP，完全不需要，那么怎么办呢，怎么让大家安装iOS应用呢，这里就给出一个流程方法，可以实现，不过，首先要提醒的是，必须是企业用户，非企业用户是坚决不能的。
经过很久很久很久的一系列时间开发；终于算是完成了，我也从头到尾，从前端到后端经历了一个完整的APP开发，我在这个APP中主要做的工作是后端接口的提供，前端内嵌页面的实现，还有一些辅助功能的开发iOS和Android兼具的完整应用。 应用的名称叫做“飞越疯人院”，恩，一群没有节操的人开发出来的所以就叫这个名字了；稍微介绍一下这个APP；一共有三个大功能，第一个就是查看公告，也就是有后台发布一些和年会相关的公告；然后第二个功能是投票，就是给年会上表演的节目做投票；还有一个就是照片墙，把公司所有员工的信息都展示出来。
网站后台有一个上传文件的程序，今天产品突然找到我说是不能使用了。我试了试，发现点击完上传按钮之后，老是跳转到链接被重置的页面，如下： 
立马在本地查看了一下源代码，最开始的反应是文件upload_max_filesize小了或者是post_max_size的默认设置小了，查看了配置文件之后发现没什么问题，最大子好吃80M，而这个文件才23M，问题到底出在哪呢？然后前端分析了一下，发现这个提醒： 
结果发现没什么用处。就再此时我突然想了一下有没有可能是后端的错误，比如是不是网络问题，服务器的空间大小问题等等，就在此时，我换了个浏览器重现了一遍错误，发现如下提醒：
工作中有时候会遇到会把一些excel表格插入到数据库（这里是mysql）中的场景，这里有比较简单的解决方案，就是先把这个表格另存为csv格式，然后用PHP程序中的fgetcsv函数来读取。 代码如下：12345678function getcsv(){ $file = fopen("1.csv","r");//文件位置 while(! feof($file)){ $row = _fgetcsv($file); echo $row\['0'\]." | ".$row\['1'\]." | ".$row\['2'\] ." | ".$row\['3'\] ."\\r\\n";//每个下标对应一列 } fclose($file);}