一些编程相关的分享

从大一的时候开始接触编程,到现在转眼大三了 (再次更新的时候已经大四了)(好吧现在我已经毕业了)。简单总结了一些编程相关的内容,记录一下。

关于记录

Evernote

有段时间有道云笔记的网页版不能登录让我不得不放弃了有道,回归 Evernote 的怀抱。本来一直在纠结 Markdown 支持的问题:马克飞象经常会出错。但是纠结到了最后发现其实并没有使用 Markdown 的必要,笔记本身简单的记录一下即可,相当于一个 Inbox ,最终还是要整理到博客或者日历里的。于是就继续使用 Mac 的客户端。

Wunderlist

一个 GTD 的好工具,快速的列出给自己安排的待做事情列表,简单快捷。在 Mac 下可以直接放在菜单上面,还不占 Dock 的空间。有一天发现不能同步,第二天再看官网已经恢复了,满满都是爱的小团队。任务可以设置子任务,笔记等等,对我来说作为一个 TODO 的工具已经够用了。

Calendar

Mac 下自带的日历已经能够满足我的日常需要了,OmniPlan 感觉有点过于重了。对于时间规划以前一直使用的 Excel ,完全纯手工的定制可以满足我的全部要求,唯独两点:效率太低,太费精力。

以上的三个工具是我最常用的,分别管理:笔记,任务,日程。不过它们的功能有一定的重合,例如: Wunderlist 的任务可以添加时间提醒,虽然是个很贴心的功能,但是我还是习惯使用日历做日程提醒和规划,个人习惯吧。所以我在用这三个工具的时候只会用它们最纯粹的功能,各司其职,倒也是极好的。

Worktile

现在逐渐用 Worktile 取代 Wunderlist 和 Calendar ,虽然它本身是一个团队协同的工具,但是可以自己新建一个项目,然后在里面安排自己的TODO事项。

Notes

现在基本只用 Mac 自带的 Notes 做笔记了,主要是记录一些我实在记不住的账号,因为其他也没啥好记的:学习笔记放在博客,好文章扔进 Pocket ,不错的博客就用 RSS 订阅,笔记对我来说作用越来越小。

关于编程

编程是一个非常严肃又非常欢乐的事情,分享一些我觉得在摸索过程中有所收获的部分

番茄工作法

当你发现有时候干的兴起根本停不下来的时候,按照番茄工作法调整节奏是一个简单粗暴的好方法。25分钟全身心投入工作,期间所有打断我的人都是敌人,一旦被打断立即取消这个工作区间,整理思绪从头开始。5分钟的休息时间,去洗手间洗脸冷静一下防止大脑过热,想想做了什么和要做什么,为下一个25分钟热身。“洗把脸防止过热”不是开玩笑,如果状态好整个人在25分钟里简直就是要飞起来了,飞的太久需要冷却一下想一想到底要飞到哪里去。不能因为出发太久就忘记我们为什么出发。

推荐个小工具番茄土豆,注册账号之后可以在网页和 Chrome 插件中同步记录,非常好用。并且现在也已经出了Mac版本,简直太赞了。

不过,再好的时间管理软件也不能帮你把事情本身做了,做事还是要靠自己。

网络环境

国内的环境就不多说了,神兵利器也很多。我只想说,一定要 Google 。

而每个月我大概会花100+在网络服务上,不是因为我有钱,而是因为我懒。时间如此宝贵,宁愿花钱买服务,也不愿意把时间花在折腾这种没意义的事情上。

学习方法

  • 官方文档优先 (原汁原味,保持更新)
  • 英文教程次之 (深入浅出,保质保量)
  • 中文教程替补 (实在不懂,只好认怂)

关于团队

  • 我觉得最重要的两样东西:责任和信任
  • 先定好命名规范以及排版和编码问题
  • 灵活使用 Worktile 、Teambition 等协作工具
  • 及时统计并掌握项目进度
  • 成员多沟通多交流
  • 还有太多了,以后单独写一篇吧。

关于博客

大约从大二的时候开始在CSDN写博客(汪海的实验室),受益匪浅。

写博客不一定是什么高大上的教程,也可以是一些收获,一些有意思的代码,一些平时学习的笔记。养成写博客的习惯,我最常翻的东西就是自己的博客。东西那么多,哪有人能都记得住,只需要记着你在博客中有记录这个,下次遇到的时候再去翻阅效率就高得多了。

现在是在 CSDN 博客上记录学习笔记,例如[iOS]Objective-C基础回顾:继承和委托,记录一些琐碎的学习笔记。

然后在 Mac 上使用 Hexo 来写博客, Markdown 要比很多在线博客系统的文本编辑器好用很多,而且还可以离线写博客,博客的样式也是可以深度自定义的。

Hexo 中的图片我一般放在七牛云存储中,然后用它提供的外链直接访问。博客源码部署在了 Gticafe 上,速度杠杠滴。

不过最近我发现一个插件很好用:微博是个好图床。好了,和七牛说拜拜。

关于翻译

最近在翻译API Blueprint Tutorial,一个类似 Markdown 语法,用一些标记来写 API 的网站。

第一次逐字逐句的理解然后去翻译,很多地方都很有意思。

首先遇到的一个问题是如何彻底的理解英文语句的意思。遇到不清楚的句子,切忌直接查单词的含义,然后再硬生生的串起来。很多专业名词如果直接翻译那味道就不对了。

比如下面这些:

千万不能翻译的

一开始没搞懂标题 API Blueprint Tutorial 中的 Blueprint 是个什么意思,在这里纠结了一会儿。先是直接看单词的意思:蓝图,规划。接口规划指导?有点像,但是为啥不直接就是 API Tutorial 呢。然后再查查这是不是什么专有名词,找到了一个blueprintcss,心中暗喜:难道是用这个CSS渲染的?但是一看效果又差的很远。于是就做个标记,等看完全文再回头来看。看完全文之后又去 Github 转了转,才知道原来 apiary 是一家公司,开源了 API blueprint 这个 API 文档写作工具,所以标题中的 Blueprint 只是个工具名,不需要翻译,如果翻译了反而会让读者一头雾水。

不知道该不该翻译的

比如 HTTP 中的 action 是否该翻译成行为, URI 是否该翻译成统一资源标识符, Gist Resource 是否该翻译成 Gist资源 ,总是感觉这些专有名词如果翻译了就变味了,但是不翻译的话就会出现类似“通过这个 URI 的 Action 可以得到一个 Gist Resource ”这种风格很奇怪的中西结合的东西。

最后总结一些自己给自己定的翻译规范:

  • 先做足功课,通读全文,搞清楚里面的专有名词和概念。
  • 专有名词第一次出现要在文中解释,后面用『翻译 (斜体原文)』表示。
  • 翻译的时候不用逐句翻译,自己理解并加以整理。

后记 - 更新自 2015 年 01 月 21 日

半年之后回头看自己以前的文章,感觉像是看另一个大学生的个人总结一样。有点陌生又有点似曾相识。

文中的很多 Naive 的观点我现在已经不能完全赞同,半年的实习生活改变了很多我以前的工作习惯。

总的来说写的还是比较肤浅,更多的是工具的分享。以后有机会再写一篇 《一些编程相关的分享2.0》,和大家聊聊实习之后一些想法上的改变。


后后记 - 更新自 2015 年 11月 16 日

好吧估计自己是没时间去折腾什么 2.0 版本了,就学习方法上面再补充一下。

阅读

每天大概会有几十篇技术文章出现在我的视野里,来源渠道大概是以下几种:

  • RSS 订阅。质量最高,新鲜出炉的技术博客。我的 RSS 整理在了 gist 上。
  • 邮箱订阅。基本都是周报汇总之类的,比如 SwiftSandbox 之类。
  • 微博。微博上我有一个 Learn 分组,里面是各种各样的程序员和不错的主页,微博比较坑的是一个分组最多只有200人,不过刚好可以控制一下我每天刷微博的时间。

讲道理的话,刷微博的性价比是最低的。但是我并不能离开微博,这是一个无名段子手的荣耀!

不管什么渠道的文章,我都会直接扔进 Pocket 里,在有时间的时候阅读。不过现在已经有1000+未读了,但是就算是未读,在需要的时候搜索一下也很快就能找到,比添加到收藏夹方便多了。

搜索

正确的搜索对于程序员而言太重要了。一定要 Google ,一定要言简意赅的描述自己的问题。

一定要 Google 。

More

好吧又没时间写了,先这么多。。。