好吧，是这样的，iPic 完善了上传服务：iPicUploader；今天，开始和一些 Markdown 编辑器作者联系。其中有几个已经勾搭上了，之后应该就会有 Powered by iPic 的 Markdown 编辑器问世啦。

期间，Bear 的负责人问我：We usually struggle to get noticed by Chinese websites or blogs, do you have any hint or website to recommend ?

看来，国际 App 对于如何在中国推广，就像我们对于如何在国际推广一样：惆怅。感觉这会是一个机会：帮助国内 App 在国际推广、尤其是帮助国际 App 在国内推广。

iPic 做的是比较基础的事：把图片上传至云存储。之所以说基础，是因为一些别的 App 也会需要这样的功能，比较 Markdown 编辑器。所以，一起想着能开放 iPic 的上传能力，让别的 App 也能调用 iPic 上传图片。

经常各种试错，终于出炉了上传服务：iPicUploader；同时，也是生平第一个 CocoaPod 项目。并且，提供了完整的示例代码，包括拖动上传、选择图片文件上传、复制粘贴上传等示例。

最后，整个项目开源、并托管在 GitHub 中：iPicUploader。明天开始宣传，希望更多的人来用 iPicUploader，大家一起做更有趣的应用。

杭州这几天在举办 G20，不过，貌似我对 G20 本身好像还真没什么了解。仔细想了下，可能是我获取信息的渠道主要是 IT 相关的，还真没有社会、经济之类的，所以对 G20 知之甚少。

不过，这样是不对的。在主要获取 IT 类信息的同时，也要做主能获取其他各行业的重要新闻。暂时又下载了今日头条、网易新闻等客户端，回头再过滤下信息的渠道，集中到 Feedly 的 RSS 订阅中，争取保持在一个入口获取所有信息的习惯。

这里说的是技术产品和技术服务。

iPic 可以上传图片，这是一个层次。
iPic 可以开放上传服务，别的 App 可以通过调用 iPic 来上传图片，这是另一个层次。

自己用的代码，可以龌龊一些。而一旦要开放出去给别人用，标准自然要高很多。

总不能写很搓的代码吗？
总不能用很蹩脚的实现吗？
API 名称总要起得顺畅点吧？
多线程及回调要好一点吧？
单元测试总要有吧？
…

想着你做的东西要开放，然后以这个为标准来要求产品的代码。

首先，这里的无压并不是完全没有压力，主要是指没有外部压力，尤其是没有项目直接相关的外部压力。

尤其是指自由职业者开发自己的产品，这样的状态；也和创业初期比较像。

这种无压的自由状态，会带来很多的不确定。比如，什么时候发布、发布的频繁、做到什么程度、某个 Bug 是否可以不改、Logo 是否好看、等等。这些人多的不确定性累加起来，会让事情变得漂移不定、难以把握。

混沌中求平稳。想要把全部的不确定性都确定下来，是不可能的。只能求在某一短暂的时间内，取得暂时的平衡。比如，立项初期集中做各种可行性研究，项目中期专注于技术细节，发布前后集中搞运营。

没有压力，目标就是很好的驱动。比如，定个下周一发布的日期，可以没有道理地定这样的时间点，然后便可以在有限的时间内，哪些事情更重要、先做什么、做到什么程度、等等。总之，目标的驱动力在于，强制把某些不确定性（比如截止时间）给确定下来，进而，确定性会让一些关联的情事变得清晰，这种约束会让很多事情更容易做决定。

近期的目标是：完善 iPic 的上传服务，推广到少数几个关联产品中。