作者归档:vicalloy

Hi, 2015

2014是忙碌的一年。各类的事情堆积到一起让人忙的只顾赶路,根本没有时间停下来学习和思考。忙碌却又没有太多能让人回味的东西,说直白一点就是瞎忙。中间一度想给自己放个长假,给自己有些时间思考,让自己可以做些决定。休息几个月在短期来看或许时间有些很长,但如果放到整个人生里也只是短暂的一个片段。

股市,算是今年少许让我能收获成就感的事情之一。相比从股市里赚到钱而言,我更在意的是做了正确的决定。07年进入股市,成功的将1w变成了2k。买房,又是在房价的高点。就如朋友说的,总是深思熟虑后做了一个最坏的决定。这次至少到目前为止我的判断还是基本正确的。当然还在“赌场”里就谈不上输赢,希望这次我做的不再是糟糕的决定。

2015,希望能不再这么忙,另外能做些让自己有些成就感的东西。

中国的股市

07年第一次接触股市,总共在股市中投入了1w+的资金。前一段时间将07年买的一个股票卖出去后账号还剩下2k+的资金。真正的开着汽车入市,推着自行车出来,投资的亏损率高到惊人。
今年9月24日在微博发了一个股市看多的言论,之后在时隔多年后重新入市。当时的股指应当是2300点左右。老妈听说我买了股票不断告诫我目前的股指已经很高了(之前股市长期徘徊在2000点)。老妹更是说投资群里的“专家”都说股市到头了。不过随着近期股市的持续上涨他们已经开始慢慢的接受我的言论了。
中国的股市更像一场博傻游戏,游戏一旦开始就很难停下来。真正关键的不是买什么,而是进出的时机。
下面是我的一些观点:

  • 近期大行情看多。在国家经济不景气的情况下国家通常会适度的增加经济泡沫以刺激经济发展。股市的长期低迷并不是国家希望看到的情况。股指维持在3000点左右问题不大,如果超过3500点国家可能会有所动作。(最近一周涨的太快有些超过我的预期)
  • 别频繁换股,跟热点。行情来的时候跟着行情赚点小钱就好,别想着跟热点赚大钱。除非你非常有天赋,不然跟不好的。
  • 相信并坚持自己的判断。中国最不缺的就是专家。如果你关注股市一段时间就会发现,看多的人永远都在看多,看空的人永远都在看空。每次遇到牛市就会涌现出许多所谓的股神。在股市真正的底部出现前没人知道股市真正的底在哪,同样在股市真正的顶部出现前也没人知道真正的顶在哪里。别太为各种纷杂的信息以及股市短期的涨跌影响自己的判断。
  • 股市有风险,投资需谨慎。在自己能投接受的风险范围内投资。如果感觉行情变化时候赶紧出来,不要犹豫不要抱任何幻想。少赚点总比亏钱好。

我明白自己不是绝顶聪明的“少数派”,但还相信自己并不笨。虽无法做到第一个发现机会,但往往也不会是最后一批。

Quick and Dirty

朋友说最近他在反思之前的一些做事方法,做项目和产品应当是“Quick and Dirty”。他是一个注重细节的人,在我看来会有些太过注重细节。
如果一开始就希望将所有事情做完美将直接导致进度的缓慢。而且当前的世界变化太快,在项目的初期项目的后继走势往往很难预料。如果项目无法很快的推出、反馈、进化,很可能根本就没有机会发展。

所有展现给用户的功能都应当是完美的
“Quick and Dirty”并不是说产品可以是一个勉强可用的半成品。后台的实现可以Dirty,但展现给用户的绝不可Dirty。你可以除了核心功能外,其他啥附加功能都没有,但不可啥功能都有啥功能都Dirty。功能的缺失用户可以等,但已有功能的不到位就会让用户质疑团队的专业性及能力。

程序的Dirty是有底线的
有时候为了验证想法,用最Dirty最快速的方式实现想法是没有问题的。一旦想法被验证值得持续的投入,这时就应当考虑Dirty的成本了。项目短期的Quick很可能是今后无穷无尽麻烦的来源。这时候可以Dirty,但必须是可演化的,Dirty的部分可以在今后方便的改进或替换掉。

用程序生成word文档(DOC)

很多程序都支持导出PDF文档,不过如果需要对导出文档进行编辑PDF就显得不那么方便了。就国内环境而言,导出word文档对有编辑需求的文档而言更为合适。
由于我使用python,因此这里只讨论python下可用的方案。目前找到的解决方案主要有下面几种

  • python-docx
    目前能找到支持word格式的库非常的少,就python而言只找到 python-docx 算是相对可用的解决方案。python-docx 的功能非常的弱,有很多的限制,比如不支持模板等。如果想生成复杂文档那就无能为力了。
  • POD
    POD是Appy框架的一部分,可使用ODF (Open Document Format)文件做为模板,并输出ODF格式的文件,并可调用LibreOffice将生成的文件转换成DOC等格式。相比python-docx,POD用于生成更为复杂的文档。但如果你需要动态生成一些复杂表格,POD可能会有些问题。
  • unoconv
    unoconv是个文档转换工具,可调用LibreOffice对文档格式进行转换。unoconv可将HTML转换为DOC格式。因此可先生成HTML,然后再将HTML转换为DOC。生成HTML对广大的WEB开发者而言无疑是轻而易举的,这也是我最终选择的方案。不过要注意的是用unoconv将HTML转换成DOC,遍地是坑-_-!。

    • 只支持有限的HTML语法。很多CSS语法根本就不支持,看到的和转换出来的效果完全不一样。解决办法:在LibreOffice中编辑文档,然后保存成HTML,然后对保存的HTML进行编辑。
    • unoconv的-t参数可传入.ott格式的文档模板。默认情况下LibreOffice转换出的表格的行高远大于文字的高度,更糟糕的是文字还是顶对齐,非常不美观。编辑个空文档,然后保存为.ott,转换的时候指定模板文件可解决该问题。
    • 生成的文档的左右边距不一致。恩…,这个我还没有找到解决办法。

大家都来开发游戏?

“flappy bird”到“2048”,再到最新流行的“don’t tap the white tile”。最近似乎一个“很普通的”休闲游戏莫名的就红了,甚至flappy bird的作者都将成功归结于运气。下一个爆红的手机游戏会是什么似乎很难预测。

面对繁荣的手游市场,即使是红的不能再红的红海(任何一个热点游戏都有成百上千的clone),也很难让人不想尝试一下。

想了几个点子,然后去搜了一下,其中一个已经有人做了,而且名字都和我想的一样。不过那个游戏的UI比较烂,下载量也一般。有人有同样的想法或许是一件好事,如果没人做过的东西或许根本就不值得做。

下面总结一下爆红的游戏都有什么特点

  • 容易上手,不需要学习,拿到就就可以开玩。
  • “极限运动”,始终有突破之前成绩的可能。
  • 触屏友好,充分利用手机的特性。注:俄罗斯方块和贪吃蛇这样的经典游戏由于非触屏友好,所以是没机会红了。
  • 碎片时间。可以随时随地的玩。

[Android]标准体重

很早之前就想写个手机APP。之前想写个类似豆瓣客户端的东西,因为我认为手机APP更多的要和网络结合才有价值。
最终写APP的事一直没有真正付诸行动。最近想还是写个最简单的好了,也算是给自己一些鼓励。

标准体重 一个计算BMI指数的应用。算是Android的开发作业,功能非常简单。代码没有写的很规范,没好意思放到GitHub。

下载地址: bmi.apk.zip

注: BMI指数(身体质量指数,简称体质指数又称体重指数,英文为Body Mass Index,简称BMI),是用体重公斤数除以身高米数平方得出的数字,是目前国际上常用的衡量人体胖瘦程度以及是否健康的一个标准。

单元测试的一些体会

以前发布开源项目时被国外的网友一阵鄙视,之后在自己的一些小项目中陆陆续续的有写一些单元测试。你一旦真正接受单元测试,并实行起来还是很容易体会到单元测试的优点的。只是尽管单元测试有很多优点,在国内的环境下写单元测试的公司依旧不多。
单元测试的好不是立竿见影,需要时间的累计。在最求“速成”的环境下,单元测试没法推行也是显而易见的。
单元测试的问题

  • 单元测试并是立即见效的
    单元测试代码的书写也需要花费一定的时间,有时还需要不少时间。如只是从一次测试的效果来看单元测试多半是不划算的。单元测试解决的是之后代码改动之后再测试的时间。如果时间进度紧张,即使知道单元测试的好处也难有心去写。毕竟要先解决燃眉之急,更何况某些代码的生命周期很短,还不足以让单元测试发挥价值。
  • 单元测试的基础测试数据需要积累
    一些复杂的业务系统业务数据之间的逻辑关系会比较复杂。比如你需要有基础的客户数据、员工数据后才可进行合同创建等功能的测试。如果没有前期测试数据的积累,你要直接给合同模块写单元测试。想到要将员工、客户等数据补上,立马就退缩了。(注:其实手动测试也要将员工、客户先创建好,只是因为之前手动测试时相关数据已创建好)

如何开始

  • 在一些小项目中先用,真正体会一下单元测试的优点。
  • 从项目的一开始就使用单元测试。单元测试的书写和项目的书写一样,都是一个循序渐进的过程。
  • 只写一些必要的单元测试,不要最求大而全。即使手动测试你也不可能测试到所有小概率情况,所以可以只写一些最必要的单元测试,让单元测试代码发挥最大价值。

Resolution 2014

已经有挺长时间没有更新blog了,上一篇还是2013年初。有时候想,写blog或许是一种状态,或许某天我的博客也会和互联网上的许多blog一样不再更新。这次这样长时间没有更新blog可能也是生活状态和之前有所不同,只是并不是我所期望的状态。
毫无悬念,2013依旧留下了很多未想做、要做却未做完的事。

  • 陆陆续续的看了一些英语,不过似乎并没起到什么作用,希望之后多少能有些进展。
  • 很早之前就已看过Android开发的东西,但一直没有真正动手做过什么。希望在2014年能做个小东西。

douban的Android客户端

最近想给Android开发一个小应用,找了一些Android应用来做参考。感觉豆瓣客户端挺有意思。

豆瓣为小组、活动等功能开发了独立的客户端。在使用的时候有时候会在APP里直接调用douban的WEB站点或是WAP站点。Facebook放弃HTML5被看成是原生APP的一次巨大胜利。但是WEB APP在跨平台以及开发的便捷性方面都有着一定的优势。在人力资源不是太过充足的情况下采用原生+WEB的开发模式可能是个不错的选择。

在用户使用频繁对用户体验要求高,性能敏感的地方使用原生开发。一些相对简单的页面直接使用WebView即可达到原生应用同样的体验,对这些页面直接使用HTML开发。还有些用户不太常用的功能在前期可以先调用WEB版的原始页面。

PS:

  • 就目前而言用HTML5开发移动应用很难提供很好的用户体验。但我相信技术在发展,HTML5还将是趋势,主要问题还是时间,2年?
  • Android手机上Metro风格的应用越来越多了。苹果将模物化设计做到了极致,接下来是Metro设计极简的逆袭?

京东夺宝岛抢拍脚本

京东的夺宝岛是京东的“瑕疵品”拍卖平台。试着拍了个物品,发现竞争还挺激烈。在拍卖即将结束的前几秒,大量买家争相出价,要想用心仪的价格抢拍到自己的物品并不是一件容易的事。
简单的分析了一下夺宝岛的页面,感觉要实现一个抢拍脚本并不麻烦。找了一下没发现现成插件,于是就自己动手了。
要实现抢拍功能,一般思路是做成浏览器插件。做浏览器插件固然不错,就是写起来稍微麻烦了些。更简单的方式是用“浏览器收藏夹”在当前页面执行脚本。将javascript:void(alert('执行当前脚本'))加入浏览器收藏夹,点击该条目时将在当前页面执行JS脚本。
利用浏览器的这一特性,我写了下面的脚本。修改脚本中的最高出价以及用户昵称,将脚本并成一行,添加到浏览器的收藏夹。进入需要抢拍的页面,点击,然后就会自动帮你出价了。

javascript:void(
  t=setInterval(function(){
    max=450;//你的最高出价,超过这个价格就不抢了
    uid='vicalloy';//你在京东的昵称(总不能和自己抢东西吧)
    did=$('.list-info>li.fore1').text().replace('夺宝编号:', '');
    url="http://auction.360buy.com/json/paimai/bid_records?pageNo=1&pageSize=1&dealId="+did;
    ct=$('.over-time>strong').text();
    if (parseInt(ct)>10) return;//在最后10秒开抢
    $.getJSON(url, function(d){
      p = parseInt(d.datas[0].price)+1;
      cuid = d.datas[0].userNickName;
      if (p>max) {
        clearInterval(t);
        return;
      }
      if (uid==cuid) return;
      $.get("http://auction.360buy.com/json/paimai/bid?dealId="+did+"&price="+p);
    });
  }, 1000))//一秒钟刷新一次价格,如果你希望提高出价的成功率,可将间隔改小。