-
Java 中的比较运算符
小菜鸟才学习 Java 没多久，这天要写一个存储长整形的列表，于是这样写： List<long> listData = new ArrayList<long>();
-
Emacs 折腾记
作为一名在 Windows 下使用了多年 gVim 的少年，已然把它在我需要的地方都收拾得服服贴贴，可以说 Vim 经过配置配置，上得厅堂下得厨房，基本能满足我的所有幻想。 直到那天突然产生了新的需求——Lisp。我工作中倒并没有用得到 Lisp 的地方，但是最近眼前晃过的一些书，比如《计算机程序的构造和解释》、《码农》杂志第 13 期，都对这门古老的语言推崇备至，还有垠神也撰文《Lisp 已死，Lisp 万岁！》历数现代 Lisp 方言的先进性，再者我也一直有学习一门函数式编程语言的想法，看起来，Lisp 是不二之选。但是在用 Vim 配置 Lisp 开发环境时遇到些问题，虽然有 Slimv，可用起来还是感觉各种不便。
-
一些不必纠结的事情
这里记录的都是一些我曾经反复思考的问题，可能我某一天已经做好了决定，但是后来忘了这个决定，然后再纠结一遍，这耗费了大量的脑力却没有任何帮助。当再次因为一个事情纠结的时候，看一看这里，是不是这个问题已经纠结过了，有结论了。 一本书该不该看 虽然我们需要高效地安排自己的时间，用有限的时间换来最大的收益，但是既然会纠结，就说明至少这本书要么是兴趣所在，要么是内心觉得看了会有用。即如此，那就看吧，因为可以记住一点： 投入地看一本书，即使只是利用工作之余的时间，一般有几天也就看完了。 即使这本书以后并没有给你带来什么，但是你也并没有失去什么。 Emacs 还是 Vim 用合适的工具正确地干活，它俩各有优点，所以我选择都用。在需要快速启动编辑配置文件的几个字段时 ，显然 Vim 更合适，打算长时间写点文字写点代码了，可能 Emacs 加上 Evil 配合里面自带的 eshell、ido 和 smex 等会更顺手。 引用知乎网友的话： 锤子再好，再牛逼，也只是个锤子，而不应该成为工匠的心魔。(from 知乎) 多说还是 Disqus 多说的优点： 国内友好，加载速度快。 支持的社交账号多。 几个好朋友的博客都用多说，互动起来比较流畅。 界面简洁大方。 多说的缺点： 邮件与网页提醒已经名存实亡。 缺乏维护者。 Disqus 的优点： 国际接轨，如果以后考虑练习英文写博客用它准没错。 服务稳定，不愁商业模式与维护。 邮件提醒。 Disqus 的缺点： 国外友好，加载速度一般，有被墙的风险。 仅支持 Google、Twitter、Facebook 和 Disqus 账号。 将语言调整为 Chinese 后中英文夹杂，不伦不类。 界面效果一般。 综上，最近正在实践「回调式生活」，即能够让它通知我的，我就不主动去查阅，所以有评论后的邮件提醒是我最看重的，我选 Disqus。 至于很多网友顾虑的它们会不会倒闭和之后怎么办的问题，我反倒不担心，毕竟他们都是有导入导出功能的，只要在收到服务关停通知后能导出数据，到时候迁移不是问题。
-
Android Studio 遇到问题集锦
打开 Android Studio 卡在「Fetching Android SDK component information」界面。
-
Android UI 开发里的尺寸单位理解
在学习 Android UI 开发的初期，经常被一些常用概念如 dp、sp 和它们与 px 的换算等虐，要避免被虐，最好的方法当然是知其所以然，再见到它们就胸中有料心不慌了。
-
Java 日期类常用写法小结
Date 和 Calendar 转 String 借助 SimpleDateFormat 类的 format 方法，Calendar.getTime() 返回 Date，最终 Calendar 也是转化为 Date 后转 String。
-
Windows 实现单实例进程的两种方法
方法一：共享静态数据。 此方法参见《Windows 核心编程》第 5 版 17.1.2 章节《在同一个可执行文件或 DLL 的多个实例间共享静态数据》。 实现原理： 创建一个自己命名的段，将其属性改为 READ|WRITE|SHARED，其中 SHARED 属性表示该段的内容为多个实例所共享（实际上关闭了写时复制机制），将变量放在该段内若值被改变，多个实例间都会受到改变的影响。
-
工作中得来的教训
把每一次的挫败，化解为下一次生长的营养。 最近在工作上比较烦闷，大致想一下，其实原本可以做到更好，记录一些自认为重要的点，以后遇到类似的状况参考之。 出来混，迟早是要还的。 更准确一点说，应该是「今天偷的懒，早晚是要加倍的精力补回来的」。 对于程序员来讲，把代码写得优雅，不将就，不只是为了看起来牛逼，更不是为了装逼，写出易读可扩展性好灵活的程序，以后你因为一些原因在一段时间以后需要去改动维护你自己的代码的时候，你会深深地感激自己当时坚持了一下，抵挡住了临时写法的诱惑，才不用在后来需要付出多倍的代价才能加入一个本不复杂的特性。 坑要及时补，不然下次还会掉进去。 如果你遇到某个技术点不熟，时间允许的话，在完成工作任务的同时，学好它；如果时间不充裕，把它加入你的 TODO 列表，强制自己在得到空闲时，充分系统地学习它。 不然就有可能陷入一个怪圈： 尽量做到知其然且知其所以然，让知识点之间关联成或大或小的知识岛，不然临时学到的那一丁点知识因为是孤立的小石礁，会很快就被脑海里每天接纳的大量信息淹没。 解决问题要形成合适的方法论。 形成自己的一套清晰的解决问题的方法，它将直接决定你对工作、生活中各种事情的解决力。清晰的判断标准是你能有条理地将你的方法讲述给一个没有相关知识背景的人听懂。 比如好好思考一下下面两个路线： 第一种：（我管它叫广度优先） 第二种：（我管它叫深度优先） 对于不同的问题，在思考解决方案的可行性、付诸行动时，哪一种思维方式更加合理呢？尝试去解决问题的我对此不能没有概念，迷糊中下意识地去跨出步子将必然是低效的。 浑水早淌，问题早暴露。 这不是说需求来了直接上手就写程序，而是说前期的构思和设计阶段过后，也就是谋定以后，要尽快开始写，不要纠缠于一些太细节上的问题，它们在实现阶段去解决就好。 对于前期调研有模糊不清需要在实际项目中才能确定的地方，早一天把实际环境接入意味着早一天把这种模糊消除的可能性，早晚要暴露的问题，早暴露意味着在有限时间内对质量的更有效的掌控。 谈论时的底气。 去跟别人谈事情的时候，先把可能会谈及的一些来龙去脉弄清楚，不然可能到时会非常被动，对业务逻辑的细节没有底气会导致紧张结巴以致最终的挫败。 学习的方法。 学习一样东西的时候，不要一股脑盲目扑上去，结合以往类似的经验，选择几条线纵深切入，在过程中有机会再做一定程度的横向扩展。 比如学习Android的应用编程，可以从线程、生命周期、动画等一些常用且非常重要的点去突破。 一次只做一件事。 当妄图同时处理几件事时，情况就会变得混乱起来，最终很可能导致拖到最后发现一件事都没有做好。排好优先级，一件一件来才是正道。 学而不思则罔，思而不学则殆。 这两个简单的句子凝聚着先贤的智慧，在学习工作中都需要随时谨记，用心体会。
My Blog / Jekyll Themes