Flickr 照片剔重工具

Flickr 虽然没有自带照片剔重功能,但开放了接口,就自然有爱好者帮忙提供工具。

ng-flickrdupfinder 能够列出你的 Flickr 账号中重复的照片,经过审核后打上 flickrdupfinder 的标签,然后在 Flickr 的管理界面就能够根据标签批量删除了。

作者在 Github 共享了源代码

缺点有两个,一是如果重复的照片很多,需要多几次翻页,二是修改后的照片也会识别为与原片重复,所以要自己小心了。


Pandoc & Markdown

实在不明白为什么很多人需要编辑器有 Markdown 实时预览功能。
Markdown 标记语言就是用来直观的编辑和阅读弱格式文本的,转换成 HTML 等格式是最后输出才做的事,盲目追求实时预览完全违背了初衷吧。

如果需要预览才能用好,那是否说明 Markdown 还不够简单、直观?

我使用 Markdown 的次数不多,因为 Vim + HTML 插件够方便,够强大,用于写文章的简单 HTML 也容易理解,通常不需要求助于 Markdown

如果要用 Markdown,我一般会通过 Pandoc 转换输出为 HTML 再发布,这样不管是不支持 Markdown 语法的,还是支持 Markdown 嵌套 HTML 的发布渠道都没有问题,不会被发布渠道的能力束缚——在 WordPress 等平台上,当然还是用 HTML 比较通用。

Pandoc 的一大好处是支持的输入输出格式极为丰富,简单的东西用 Markdown 写好,想转换成什么都比较方便,包含中文的 PDF 文档除外,除非你知道怎么解决 LaTeX 相关的配置。
其次是可以自定义的参数一大堆,比如 Markdown 中要求行末加双空格才转为换行,Pandoc 用 markdown+hard_line_breaks 参数就轻松化解,不用害怕忘记双空格这种反直觉的标记。

如果配合 Total Commander 使用,安装 Pandoc 后可以在工具栏中增加 Pandoc 的快捷图标,参数栏中写上:

-f markdown+hard_line_breaks %N -o %O.html

其中 %N 表示当前选中的文件,%O 表示当前选中文件不含后缀的文件名。

不使用 Total Commander 也可以自己写个脚本或批处理干这事。


移动应用痛点

虽然手机、平板上的移动应用越来越丰富,操作越来越简便,但大部分时候,我一点都不喜欢移动设备上使用——虽然不得不使用,但总是很痛苦。

一个原因是应用之间的数据分享通道局限太多,对内容的操控抓得太紧。

典型的例子就是要分享一些阅读应用中的内容,地址、标题、正文、图片等等无法像电脑浏览网页一样,给用户完全的控制权,有时甚至禁止选择文字。

也许这样限制的初衷是防止方便盗用内容,但一来移动应用上的内容盗用并不因此就少了,有利益驱动谁也挡不住,二来用户有心整理内容,精炼消化后准备二次分享,这是有益于提升交流和内容质量的事情,现在却只能换到电脑上整理。

既然各个应用之间是分工合作的关系,谁也不能包打天下,那么这种无形中限制数据流动的做法等于提升了用户操作成本。
如果是不过脑子的娱乐内容也无所谓,真要干什么正经事情,还是觉得麻烦。

第二个原因,则是移动应用并没有提供一条龙的流畅业务体验。

作为用户,我最终想要的就是提出自己的目的,然后其他一切由应用代我搞定,最终由我在几个选项中选择最中意的那个就行。
限于目前的软件能力,哪怕将关键数据收集、整理好,给我参考决策,也算是可以接受了。
但现状是离这个状态还差得远。

比如说外出游玩,有地图查询、餐饮查询、酒店预订、车船机票预定、景点旅游攻略、同城活动查询……各种应用,可是用户得一个个切换过去,查询、筛选、比对、求证、记录、下单,遇到有的条件不合适,整个流程还得重新来过。

比如说购买自己不大熟悉的商品,在电子商务网站搜索出来的结果是很多,也有不少比价工具,但除了价格、信用之外,一眼看去也很难有可参考的信息了,有时候你要去官网找哪些是官方授权网店,有时候要比对各大电商网站翻评论,或者去专门的论坛找评测,等到终于下决心要下单了,发现还要考虑送达本地的时间等等,又得重新过滤一遍。

又比如时下越来越流行的健康监测应用,实时、准确采集数据的功能是越来越强,但采集到的数据从整合到分析,到一票社交渠道互动,到协助改善生活习惯、健身计划,到和各种周边应用如健身器材购买升级、同城健身活动组织,乃至衣食行消费导购和理财等等等等,都还只整合了部分。

加上第一个原因的限制,很多并无多大意义的中间信息都要亲自处理,用户就像在山谷中前进,终点仿佛就在眼前,走过去却还要上山下地。
信息技术应该帮助信息如流水一般,朝正确的方向流动起来,现在的移动应用却像是要用户自己一桶桶地提水,装满了水再开动机器。

当然,把移动应用做得大而全到臃肿的地步也不可取,那样比现在更加糟糕,但针对不同目的的应用之间相互串联贯通并不只有大而全一条路可以走,内部相互之间的接口通讯不给用户看到就行。
只是这样的改变需要整个生态环境的进化才能实现了。


随身无线网卡网盘

虽然 Dropbox 的增量同步、版本回溯、文件夹管理、移动端同步、网页管理、分享等功能确实很优秀,但用得越久,不完美的地方也发现得越多。

  1. 每个设备中都要保存一份本地文件,浪费空间;
  2. 没有本地加密功能,不敢放私密的文件(Wuala 倒是可以加密,就是其他方面弱了点);
  3. 总容量有限,要是扩很大,和第一点又有矛盾;
  4. 到了没有网络或上网速度慢的地方就傻眼了;
  5. 不能直接复制文件分享给其他人,要么对方得自己下载,要么还要依赖其他外置存储,如优盘。

优盘的问题也不少,主要有:
1. 虽然存储的价格不断下降,也没有便宜到和云端空间同等级的程度,长远来看,总是跟不上空间需求;
2. 重要数据存放在优盘,总有丢失的风险;
3. 和网盘相比,不能跨设备同步自然是一大不足。

360倒是有将网盘、优盘和 WiFi 热点结合的想法,但是在本身就没有联网的环境下照样歇菜。

倒是电信运营商可以考虑利用资费优势,趁着4G 的推广,弄一个4G 无线网卡+网盘+优盘+定向流量计费的组合出来:
1. 4G 无线网卡起码保证随时随地有网络可用,信号好的地方速度不在话下;
2. 提供容量足够大的网盘,比如电信就弄了个乏善可陈的天翼云,但运营商的网盘光靠容量显然拼不过互联网公司;
3. 优盘当缓存使用,最近更新的文件和用户标记的重要文件,优先存储在优盘中,这样就不必总是要联网;
4. 定向流量免费或优惠,比如网盘同步用的流量全部免费或很低廉,只要能吸引到用户使用服务就行。这大概是电信运营商唯一的也是无法复制的优势了;
5. 如果加密优盘内容,再用比较时髦的方式才能登录网盘就更好了,千万不要学360的随身 WiFi,插上就能登录网盘帐号,毫无安全可言。

当然,以运营商的风格,像360一样内置绑定软件简直是一定的。
如果真要这么玩,也不是不可以,只要真对用户有价值就行,比如集成应该深耕细作、好好利用的联系人资源应用(不借助 Google、Apple、Microsoft 等的同步服务也能和手机、邮箱同步),比如网上营业厅的查询、提醒等服务。


最简便的内容发布方案

宣传、推广 Markdown 标记语言和协作工具的人往往强调其可读、易修改、文件格式通用的优点,但是对互联网上的写作者来说,「写」只是第一步,「发布」和「维护」还有许多优化的事情可做。

比如说我们使用 WordPress 发布文章,至少要有这么几步:

  1. 登录(假设自动登录并直接跳转到发布页面)
  2. 编辑标题(可以省略,但严肃的作者通常不会忽视标题)
  3. 撰写正文(或复制粘贴已经准备好的内容)
  4. 发布(如果不放心还要打开文章页面看看效果)

这还不包括选择类别、增加标签、设置 post slug 等操作。

邮件发布

WordPressJetpack 插件包中有 Post By Email 功能,Tumblr 等一早就支持邮件发布,好处是自动备份,不用额外客户端,不需要登录网站。
如果习惯邮件发布的话,Jetpack 是不错的选择,因为能支持大多数参数设置。
不过使用邮件发布的用户始终是少数。

编辑

要是文章发布后不满意又要修改呢?还是至少要经过以下步骤:

  1. 登录
  2. 跳转到所有文章列表
  3. 定位到要修改的文章
  4. 修改正文(或者复制粘贴已经修改好的内容)
  5. 发布更新

如果保持登录状态,在文章阅读界面也可以直接进入编辑界面,但也只是将上述步骤调换了顺序而已。

如果网站的编辑功能还不够完善呢?
比如说不支持更好用的 [Markdown] 扩展语法,或者更习惯本地编辑器的丰富功能,如版本管理、本地备份、语法高亮、快捷键……
在本地编辑界面和网页发布界面就得切换一下了,要么就得找足够好用的发布服务客户端,比如曾经很流行的 Windows Live WriterZoundry Raven

内容迁移

如果还考虑内容迁移呢?
后台不同的导出、格式转换、导入有多麻烦就不说了(当年汉字编码的转换就害死不少人),很多内容发布平台根本就不提供完整的导入、导出功能,而且导出来的也许是各种不好读的格式。

理想方案

有没有一个服务能结合 Dropbox/Box + Github/Read the Docs 并继续扩展呢?

写文章在本地保存文档就好了,和平时写作完全没有两样,爱用什么顺手的本地编辑器就用什么;
格式也没有特殊要求,无任何特殊标记的纯文字,Markdown/txt2tags/reStructuredText等等,HTML/RTF/Word Docs 都适用;
写完了复制到某个指定文件夹就是发布,这个文件夹类似于 Dropbox/Box 的同步目录,自动上传并转换为服务网站上的静态页面发布,同时在本地目录中生成相应的静态网页文件用于预览;
标题就是文件名,post slug 在文件名中的括号中指定,或者参考 Jetpack 的标签参数;
修改也简单,直接在本地编辑发布目录中的文件,后续的更新发布不用手工操作;
要是有人留言评论,也会自动在本地目录中生成后缀名为 .comment 的超文本或文本格式文件,其中就是留言内容。

这样,写作者只要操心写文章,发布是一个复制操作就能搞定的事情,内容备份什么的与日常普通的文件备份管理统一,与内容发布服务无关。


« Older | Newer »