迁移至Azure

由于在微软就职,所以每月都有一定额度的Azure使用权,故此将整站一股脑迁移到了Azure(US)上的新VM上 相比DO的VM,Azure的优势在于: 不花钱,尽管实际上当前VM实例的价格是此前DO实例价格的小30倍 计算核心++ 磁盘+ 内存+++++++++++++++++++++++++ 网络带宽+++++++++++++++++++++ 同时,HayDay Panel也迁移到了这里,由于毕业+入职的忙碌期,很久都没有更新过的数据也会在下周结束前进行更新,后续的开发工作也会缓慢的进行,敬请关注。...

HayDay Panel试运行

距离上次决定暂停活动更新的博客发布已经过了三个月了, 近期不断收到四面八方的利好消息(例如不盲审了),撒个花O(∩_∩)O 心情好多了,压力也小了不少,作为代价,头也发掉了一些O_Q(但是我知道我正在变强!) 抽出了一个晚上的时间,用了极其原始的技术栈做出了HayDay Panel的初版, 未来的活动预告、游戏参数信息都将借助HayDay Panel发布(终于自动化了>_<) 目前是最初最初的版本,只包含活动预告 那么,Enjoy it!  点此访问

关于暂停Hay Day的活动更新

博主将要暂停Hay Day的活动更新,主要原因如下: 众所周知的原因,非越狱情况下,仅有iOS 8以下的系统才能够随意地访问应用程序目录,但我符合这个要求的硬件(iPod Touch 4)已经无法再运行Hay Day,再加上我并不想对我现在的设备越狱,所以这就失去了预告内容的来源 临近毕业,论文的压力巨大,所以时间上不允许我去折腾安卓模拟器之类的东西 不过没关系,Hay Day的活动预告在微博上到处都是(在搜索框搜索:卡通农场预告),相信你一定可以得到你想要的信息。我也很感谢在这段时间里和我一同玩耍的大家,虽然在未来的一段时间里,我不会更新活动预告,但是关于Hay Day的一些来自官方论坛的消息(通常这种消息国内的官微根本不会发),我还是会转达给大家的,毕竟Hay Day是我目前唯一玩的付费手游。 另一方面,如果你想凭自己的意志掌控活动预告的释放,那么你可以参考这篇文章:http://blueve.me/archives/1344  这篇文章会教你如果从Hay D...

解决了本博客的数据库不定期崩溃问题

解决了本博客的数据库不定期崩溃问题
这个博客自从搬到DO之后就经常性大姨妈,第一次崩溃的时候仍然记忆犹新,不过通常重启MySQL后台服务之后就解决了,当时估计的原因是因内存不够,不过好在解决方案简单无脑,只需要一句: [crayon-59e62673e159f691599678/] 解决方案简单,便没在意,反正崩溃也只是偶尔出现,一旦收到监控邮件,手机直接SSH上来执行一下这条语句就好了。 不过这两天疯狂的崩溃,我的邮箱经常被监控邮件塞满,着实让人忍无可忍(目测是因为不少人想看卡通农场的预告,访问量激增导致的) 连上SSH,查log, [crayon-59e62673e15a4286735808/] 发现了如下信息: [crayon-59e62673e15a6098494501/] 果不其然,估计是初始化InnoDB buffer pool的时候把内存挤爆了,通过free命令也看到,我的swap空间是0,解决方案也就很自然浮出水面了,无非是: 加内存 加SWAP 减少InnoDB buffer p...

写了个给LeetCode用的Chrome插件

写了个给LeetCode用的Chrome插件
近期刷LeetCode,作为一个0氪(那个订阅真的太贵- -,讲道理,我觉得还不如搞成太鼓达人曲包的模式,按题收费),就算使用过滤器过滤掉Solved Problems,依然有一大堆Unsolved Locked Problems堆在列表里,要找可以做的题非常费眼,十分恼人。于是想到用浏览器控制台脚本直接把有带锁图标的那一行删掉,于是有了这个Gist。 不过受此启发,干脆一不做二不休,做成Chrome插件,造福大众(我自己_(:з」∠)_),网上稍微翻了翻Chrome插件的文档,感觉还是比较简单的,用自己半生不熟的二手jQuery脚本写了这个插件: 最新版下载 https://github.com/Blueve/LeetCodeUp/releases 源代码 https://github.com/Blueve/LeetCodeUp 效果如下所示: 该插件会在题目列表上面增加一个Show Locked Problems复选框,默认不勾选,也就是隐藏掉氪金题目。然后下方是我

初窥Spark SQL Catalyst

初窥Spark SQL Catalyst
在这篇文章中,我根据Spark SQL的论文,介绍了Spark SQL的一个关键模块:DataFrame API。我们现在已经知道,DataFrame和RDDs之间的关系应当是:DataFrame可以转化为RDDs,而RDDs也可以被映射为DataFrame。同时我们也知道,DataFrame API实质上是一套DSL,而最终在Spark计算框架中被执行的,应当是DataFrame最终转化后的RDDs。显而易见,人肉编写的DF所对应的DSL,存在着巨大的优化空间。这也就是本次文章所有讲述的Spark SQL的后半部分内容——Catalyst. *这里额外补一句,根据目前最新的代码,Spark已经把DataFrame这个东西去掉了,取而代之的则是Dataset,为了保持兼容,原来的DataFrame被定义为了Dataset[Row]的别名。关于这个Dataset我先观察观察,如果有必要的话,再单独拎出来说说,目前您可以假装认为它和DataFrame没有啥区别。   Catalyst O

进化的Spark, 从DataFrame说起

进化的Spark, 从DataFrame说起
书接上回,Spark可以说就是RDDs的化身,我们已经看到RDDs的设计方案对于大数据的计算具有诸多优势,但是随着Spark项目的推进,大家也逐渐地发现,在实际的生产领域,Spark RDDs API的编程方式并不是唯一的选择,很多的计算,都很像目前关系型数据库中的关联查询,而所谓的“信息”,其实很大部分都是产生自数据与数据之间的关联,而对于这样的数据模型,RDDs模型的表达能力还是相对有限的。 Spark 1.3.0的发布带来了全新的DataFrame API以及Spark SQL,我们继续追根溯源,找到关于DataFrame与Spark SQL的核心设计稿 - Spark sql: Relational data processing in spark[1]。 从这篇文章的角度来讲,DataFrame API和Spark SQL是配套的,从下图我们就可以看出来新增的这个模块与原有Spark框架的关系: 它们只是以不同的角度来诠释Spark在关系型数据的处理能力,可以看到,整个S