《孤独美食家》美食整理

想必各位都是一边看一边咽口水,想着要是能去现场吃吃就好了。

之前看豆瓣上有人整理剧中提及的所有美食,以及贴图和tabelog(日本人气很旺的美食点评网)链接,非常详细,但是很可惜只整理了第1、2季。

记得剧集结束时推荐过一个美食地址的Apps,找了半天也只找到个疑似半成品的Apps,基本没有UI设计,打开速度巨慢且不时的闪退,但好在给出的数据除了甜品店,其他店的数据还比较全,恰好前两天看到一个博主推荐分享的Google Maps『我的地图』自定义地图的功能已经整合进android版的消息,于是把这个Apps里的店址、tabelog链接、剧集官网的链接都弄出来,补充了一些缺失的数据,做成了下面这个《孤独美食家美食地图》:

https://www.google.com/maps/d/edit?mid=zfXR4tbCR6YI.kbTF8-MdArkw&usp=sharing

大家可以在Google Maps里以此地图为基础,规划自己的日本之旅行程,这个地图里的美食只放了基本的剧情链接跟tabelog链接,大家可以根据自己的偏好,提前做功课,定制出自己专属的旅行地图,到达目的地之后,通过手机版地图(目前仅支持Android版),就可以随时查看提前准备的自定义地图了

具体用法:

1)打开上文我所分享的地图链接,点击分享图标,选择『下载KML』,如下图

2)点击『创建我的地图』 ,如下图

3)选择『创建新地图』

4)创建之后,选择『导入』,把刚才下载的KML文件导入,即可在此基础上规划你自己的行程了。可以根据自己的喜好增减地点,地点相关内容、链接、图片等均可通过编辑功能添加。

5)规划好之后,下载最新版的Google Maps Android版(iOS版本暂不支持),左边栏打开之后,点击『您的地点』,可找到曾经收藏过的地点和创建的地图,点击刚才创建的地图,就能看到了。

创建的地图还可以在底部设置成『关闭』状态,注意,该地图不支持离线,所以到了目的地最好能使用能上网的手机卡或者通过无线路由上网。

 

 

凤梨的季节来啦~

台湾趴趴走天天吃都没吃够的凤梨,最近在家附近水果超市发现有卖,自此开启狂购模式~昨天买到一颗超级貌美香甜的凤梨,头特小(好羡慕你们这些头小的…),事实证明头小确实乃凤梨味美之窍诀~~

糖糖妞也很高兴,她最爱啃凤梨头了~~(凤梨OS:雅蠛蝶~雅蠛蝶~劳资发型被啃成这样还怎么见人喔ಥ_ಥ)

附赠一个凤梨的切法,这样可以整个买回家,保存的时间长一些,想吃的时候再切开就好啦~

【转】产品经理从零到一技术进阶:不懂代码也能愉快地与开发相处

在36氪看到的文章,挺实用的,值得反复看及有时间时深入学习、拓展,so搬运过来,附原文链接

产品汪在力所能及的范围内懂点技术,具备一些与RD相同的知识背景,是完成有效/良好沟通的基础(当然不是让你拿着半桶水去RD面前指手画脚哈),也是对产品整体效果负责任的一种体现。

———–以下是原文————

36氪微信号:wow36kr

这是 NEXT 「产品经理从零到一技术进阶:不懂代码也能愉快地与开发相处」线下活动的笔记。主讲者张元一,产品原型工具墨刀的创始人,见证了 Web 开发从 99 年 HTML4.0 到去年 12 月 HTML5 最终定稿这之间整个 Web 开发变迁史的 15 年「码龄」全栈工程师。

NEXT 本次活动收到了近 1000 多个报名,大家对周日线上和线下的互动学习反馈也不错。因此我们将笔记分享出来,希望让更多产品人、创业者够快速了解基本技术知识,更好地把握产品周期与项目进度。当然,你也可以观看网聚直播提供的视频回放:http://wangju.tv/live/3k562amaskvzg 。

概览

以下这张图就是元一分享的干货内容,它基本涵盖了一个初级码农需要知道的所有基础入门知识。但这张图的目的并非用来吓人,这其中的所有技术名词,将以最通俗易懂的方式串联起来—— 即我们上网时的慢动作解析:打开一个网页或 App,这背后都运用了那些技术来让这个网页和 App 的内容呈现在浏览器和手机上;驱动这些动作背后的技术名词都是什么,各自有着怎样的优缺点,彼此间是如何协作和运转的,以及怎样合理地评估技术能力和开发难度。当然,元一也推荐了丰富的学习资料。

这中间涉及的技术知识,前端包括 HTML,CSS,JavaScript,jQuery 以及 Bootstrap ;后端包括 HTTP 服务器,后端编程语言,数据库以及 Cookie 和 Session;移动开发分为原生,混合式,HTML5,以及不同的移动端技术选择在功能和开发成本上的比较。

什么是前端?什么是后端?二者是如何配合运转的?

前后端的划分,可以简单地理解为凡是运行在用户设备上的技术都可以称为前端技术( 比如 HTML / CSS / JS,甚至移动设备的 Obj-C / Swift );而后端的作用就是负责将这些东西封装在 HTTP 的数据包中然后通过网络传送到前端。当然除了这些前端文件,后端还有一个更重要的职能,即保存和提供用户数据,比如移动端常见的 JSON 就是目前最流行的在后端和前端之间传输的一个文件格式。

前端与后端是如何配合的?如上图,以 Web 端为例,在浏览器输入一个网址后,浏览器向服务器发送了一个 HTTP 请求;服务器通过一个 HTTP 响应,把显示这个网页所需要的资源传回给了浏览器。而需要在浏览器中执行的技术,HTML / CSS / Javascript 等就叫做前端;需要在服务器端执行的、通常我们看不到技术就叫做后端。

Web 前端的运行逻辑

假设我们要访问 Google,从我们在浏览器输入 Google.com 到最后这个页面出现在眼前,这其中涉及许多前端的技术反应和代码组合,总体而言可以简化为两步:

1/ 浏览器向 Google 的服务器发送了一个请求。

2/ 服务器收到了一个 HTTP 响应,这个响应中就包含了执行这个命令所需要的所有资源(注:可以通过 Chrome 浏览器的开发者工具来进一步观察 HTTP 协议的运行情况;下图为 Google 的 HTTP 协议运行情况)。

上图这个界面看起来很复杂,但对于非程序员而言,HTTP 协议运行情况只要关注其中的几个关键部分:第一列,即资源的 URL;第四列是这个资源的类型。在第一个请求和后续的请求之间有一根蓝线,即进度条。而 HTTP 协议中运行的项目越少,浏览器加载的速度越快。图中 Google 就处理得很好,只有 10 个左右的请求。

Web 前端技术语言介绍

  • HTML 和带样式的 HTML

HTML 就是一组标签和文本的组合,是一个最基本的网页。它已经包含了网页常见的元素,实际上在 Web 早期的很长一段时期内,网页都是这个样子。后来随着使用网络的人群越来越广泛,在 HTML3.0 中引入了对网页样式的定义,某种程度上可以说,也是从这个时候开始产生了网页设计师的角色。

  • CSS

带样式的 HTML 也拥有一个缺点,它需要为每个标题和文字都设定样式,工作量非常庞大。 CSS 就是在这样的情况下诞生了。CSS ,又称叠层样式表,简言之是一种用来表现 HTML 文件样式的样式设计语言。CSS 能够对网页中的对象的位置排版进行像素级的精确控制,实现基础的静态的交互设计;而CSS 目前的最新版本 CSS3 能够真正做到网页表现与内容分离。

  • Javascript

差不多在 CSS 诞生的同一时间,大家开始觉得这样静态的网页似乎略显无聊,能不能给网页加入一些可以动起来的元素?比如点击一个按钮之后变个颜色。当时网景公司的工程师Brendan Eich 就给他们自家的浏览器引入了这种实现动态效果的脚本语言,这就是 Javascript(简称 JS)的诞生。所以通俗来说,Javascript 就是用来给 HTML 网页增加动态功能,实现更炫酷的交互。

提到 Javascript ,就得提一下 jQuery 。 jQuery 是一个优秀的 Javascript 库。jQuery 使用户能更方便地处理 HTML ,它能够使用户的 HTML 页面保持代码和 HTML 内容分离,通过 jQuery ,可以不用在 HTML 里面插入一堆 JS 来调用命令,只需要定义 ID 即可。此外,由 Twitter 设计师 Mark Otto 和 Jacob Thornton 合作开发的 Bootstrap 也是一个受欢迎的前端框架。

HTML5 简史和响应式设计

HTML 在刚诞生的前 10 年发展是非常迅速的,在 1999 年,我们现在常说的 HTML5 的上一个版本 HTML4.0.1 就已经发布了,那么为什么从 4.0 到 5.0 会拖了 15 年之久?

首先,HTML4 的发布时间和门户时代(即 Web 1.0 时代)是基本吻合的,也就是说 HTML4 实际上是为门户型网站设计的。在门户网站经历的 4,5 的年发展之后,大家开始觉得只是单一接受信息的互联网太过无聊枯燥了,差不多 2004、2005 年开始,大家希望在网页中加入更多的互动元素,也就是我们常说的 Web 2.0。

但是这个时候大家就发现,为 Web 1.0 设计的 HTML4 无法胜任这个工作,但是有另外一个技术却非常适合,那就是 Flash。所以在 Web 2.0 的早期,当时最炫酷的网站有很多是完全用 Flash 开发的,在以后的很长一段时间里,有很多网站都是 HTML 和 Flash 的混合式网站。所以在 2005 – 2010 年这段时间,HTML5 中的新标准主要是为了取代 Flash。

刚刚搞定了 Flash,又进入了移动开发时代,所以 HTML5 又花了 5 年时间制定各种针对移动平台的标准。但是到目前为止,虽然 HTML5 已定定稿,但是对移动平台的适应其实还在进行中,所以在未来很长一段时间内,就像当初的 Flash 一样,我们会看到越来越多的混合式应用。

在 iPhone 出现之前,大家访问 Web 的主要方式还是通过桌面浏览器,所以设计网页时只要考虑桌面浏览器的显示效果就足够了。但是在 iPhone 和 iPad 出现之后,就需要考虑同一个网页在不同设备上的显示效果,第一个问题的答案就是响应式,响应式的核心就是让同一个网页可以在不同设备上呈现出不同的显示效果,主要是通过CSS来实现的。

除了响应式设计,HTML 在移动端遇到的另外两个问题就是如何利用移动设备的各种传感器,比如 GPS,摄像头等等;以及性能问题。为了解决这些问题,HTML5中添加了地理位置,拍照,3D 动画加速等等 API,可以部分的利用手机设备的一些新硬件,并且新的 API 还在不断的加入进来,这也是为什么现在的 HTML5 应用可以越来越炫酷的原因。但是,HTML5 并不是专为移动设备设计的,它是由 HTML5,CSS3 以及大量的 Javascript API 共同组成的一个标准合集,微信中的 HTML5 应用只是 HTML5 应用场景中的很小一部分。

如何判断一个前端的能力?

关于前端,可以简单的把它理解为,凡是在我们的电脑,手机上运行的技术,HTML,CSS,Javascript,这些都属于前端技术,使用这些技术的我们就称为前端工程师。如何判断一个前端的能力呢?下面是一个简单的前端能力链:

1/ 只会 HTML/CSS 的,这种我们俗称切图的,基本上就是淘宝几十块切一张图的;

2/ 懂一些简单的 Javascript,主要是使用一些现成的框架,比如 jQuery,bootstrap 等等;

3/ 知道 jQuery 和 Bootstrap 的局限,必要时能写一些原生的 JS/CSS 代码;

4/ 对JS/CSS非常了解,执着于使用浏览器的各种最新特性来实现各种炫酷效果,这种我们成为炫技派;

5/ 可以自己写出类似 jQuery / Bootstrap 这样的前端框架供其他人使用。

前端学习资料

http://www.w3schools.com

http://onemonth.com

http://www.codecademy.com/

https://github.com/alex/what-happens-when

https://qdan.me/list/VNBugw7ObupFRdlE

大家可能比较关心如果我要开发一个网站需要多少时间?这个问题虽然很难回答,元一还是来试着回答了。现在前端有了 jQuery,bootstrap 这样的框架,后端又有了 Ruby on Rails 这样的快速 Web 开发框架,如果从头学的话,像是一个简易的 Pinterest,大概一个月就可以了。如果是一个有经验的程序员,可能 1 个星期就可以开发出一个大概的原型出来。

后端服务器

后端的任务实际上就是向前端提供需要显示网页和 APP 内容的数据,可能是 HTML,也可能是JSON 数据,也可以是音视频或者 PDF 文件。简单的来划分,一个服务器包含3个部分:

1/ HTTP 服务器

2/ 应用服务器

3/ 数据库

HTTP 服务器的唯一任务就是把需要返回给客户端的资源文件封装在 HTTP 数据包里,这个资源有可能是它后面的应用服务器动态生成的,也有可能是保存在硬盘上的静态文件。这是所有后端程序都必须有的,也是直接和我们的浏览器通信,返回给我们数据的程序。它的作用就是把它后面的编程语言生成的各种 HTML/CSS/Javascript,打包成一个 HTTP 请求,然后再封装到一个 TCP/IP 的数据包里发回给我们。而最常用的两个 HTTP 服务器叫做 Apach 和 Nginx。

应用服务器就是通常意义上所说的码农负责的部分。他们的职责就是生成前端需要的HTML/CSS/JS 交给浏览器。

后端语言

1/ .net/java

庞大,复杂。但 Java 的优点就是适合处理特别大的数据量,如果你的项目会很快实现大爆发,需要处理海量的请求,那么 Java 是一个不错的选择。

2/ PHP

可以快速上手,相比其他语言,可以更快的为应用添加各种新功能。当然,可维护性就另当别论了。

3/ Ruby

非常接近自然语言,基本上即使不懂编程,也能看明白 70% 或 80%。04 年出现了一个用 Ruby 编写的 Web 开发框架 Ruby on Rails,当时的效果是非常震撼的,以前需要一个团队才能搞定的事情,使用 Ruby on Rails 后 1 个人就可以胜任了,所以 Ruby on Rails 在极短的时间内就成为了 Ruby 的代名词,也成为了新手学习 Web 开发的不二选择,但是 Ruby 语言也并非十全十美,快的同时,他的最大短板就是性能。Twitter 最早就是使用 Ruby on Rails 开发的,但是随着用户数的逐步增长,Twitter 的宕机开始变得非常频繁,后来他们迫不得已将整个系统从 Ruby 迁移到到了一个从 Java 派生出来的语言 Scala。

4/ node.js

简单来说,可以把 node.js 理解为跑在服务器上的 javascript,再直白一点,就是一个跑在服务器上的浏览器,因为 node.js 最早就是从 chrome 浏览器的Javascript 引擎 V8 中剥离出来的。相比 Ruby,Node.js 程序可以获得更高的并发性能,这在一些高并发的场景下(比如群聊,多人协作等)会很有优势。

5/ 其它(python,closure 等)

6/ 无后端(leancloud)

无后端编程是最近的一个新趋势,但她并非说是真的没有后端,而只是把后端交给一些第三方的云平台,比如 Leancloud,Firebase 等。如果你开发一个手机 App,这样的好处就是你可以在早期没有后端程序员的情况下快速开工,像Leancloud 这样的云平台已经可以胜任大部分的应用场景,如果后期业务逻辑复杂之后再寻找合适的后端工程师迁移也不迟。

7/ 最强编程语言 Lisp

如果要评选一个最强的编程语言,该是哪个呢?答案就是Lisp。为什么是 Lisp?Lisp 的作者在很早以前就从数学的层面总结了一个完美的编程语言应该具备的 9 种能力,而 Lisp 就是为了配合他的这个理论而产生出来的语言。Hacker News 是由 YC 的创始人 Paul Graham 开发的,而 Paul Graham 本身就是一个 Lisp 程序员,他为了开发 Hacker News,专门发明了一种新语言叫做 Arc,但因为它是基于 Lisp 的,所以也被归为了 Lisp 的方言之一。

数据库

我们平常访问的大部分网站都是需要登录操作的,登录之后我们看到的就是只和自己相关的那部分内容。这些用户信息是保存在什么地方的呢?这就需要用到数据库。关于数据库,代表性的有两个:

1/ MySQL

2/ MongoDB

MySQL 是最常用的结构化数据库,也是大多数创业公司的选择。为什么是结构化的?就是说它的表的结构是固定的,比如我们常见的 User 表在 MySQL 中就是这样的:

如果我们需要取得一条用户记录来检查他输入的密码是否正确,这时我们就需要使用 SQL,SQL 就是结构化查询语言。

简单来说,SQL 数据库保存的是结构化数据,NOSQL 数据库则可以保存非结构化数据。举个例子,还拿上面的用户表来举例,如果我们现在想要给产品集小妹增加一些额外的属性,比如她给某个产品点赞可以效果 x2,那么如果是 SQL 数据库,我们就需要给数据库增加一个新的字段来保存这个属性:

但是如果是 MongoDB 这样的 NOSQL 数据库,我们就不需要给所有用户都增加一个x2的属性,只需要给产品集小妹单独增加就可以了,NOSQL 中保存到数据是如下这个样子的:

Cookie 和 Session

服务器要处理成千上万用户的请求,那么他是如何区分每个用户,并返回给每个用户他所需要的内容的 ?这就要涉及到 Cookie 和 Session。我们可以将 Cookie 理解为是服务器给每个用户分配的唯一 ID,这个 ID 由用户浏览器保存,而 Session 则是服务器为了维护这个会话在服务器端保存的与 cookie 对应的用户数据。

移动端开发

移动端和浏览器的区别就在于,大部分 App,我们打开的一瞬间,就已经看到了它的界面,而不用再去向服务器来拿显示界面的 HTML 等文件。所以移动端,开发原生应用所运用到的技术(比如 Objective C,swift)就相当于前端的 HTML,只不过它是直接保存在应用本地的。这样就产生了一个问题:如何来获取应用数据?如果是网页应用,我们可以直接将数据包含在HTML 中一并反馈给浏览器;但是对于移动应用就需要有一个专门的协议来传送应用需要的数据,这就是 JSON。

移动应用的前端技术,目前来说主要有以下三种:

1/ 原生

2/ 混合式

3/ HTML5

HTML5 必经要经过浏览器这个中间层,所以在性能上多少会有些损失,所以如果你的应用对性能特别敏感,原生就会是比较好的选择;对于普通的性能要求没那么严格的应用来说,HTML5是完全可以满足的。而如果已经有了一个移动端的网站,这种情况下混合式就会是一个比较好的选择,它可以最大程度的利用已有的资源。如果说你是从头开发一个移动应用,并且这个应用对用户体验的要求也不是特别严格,那么 HTML5 就会是一个很好的选择,HTML5 移动应用比较显著的应用就是 Dailycost 。

如果说开发一个原生应用需要 4-6 周,那么同样功能的应用如果我们把其中的一部分用 HTML来实现,那么可能就只需要 3-4 周的时间,但是如果我们全部使用 HTML ,可能就只需要1-2周。

此外,活动另一位嘉宾、 bearchat 工程师 Loddit 分享了关于数据抓取的干货知识和 tips ,感兴趣可前往 http://36kr_data_capture.meteor.com 下载 PPT。

『书架清理活动』副产品-电子阅读漫谈

最近在进行『书架清理活动』,作为一个进阶中的非重度阅读爱好者,kindle虽书多+不伤眼,偶尔翻翻小说还凑活,但简陋的排版和pdf阅读体验实在无法忍受(刷多看系统掉电又太厉害),所以目前大块时间常用的是iPad mini+豆瓣阅读和多看,手机上也装了相应的Apps以打发碎片时间,没有好的电子书或特别支持的一般会买实体书看。

这些天实体书、豆瓣跟多看上的库存都看了些,脑子里一直冒出跟『电子阅读』相关的内容,试着梳理下。

先描绘下po主心中理想的电子阅读:多看的排版+kindle的书量&E-ink设备+豆瓣的低价&社区&独特内容。说具体一些,就是有个像kindle这样顺手的E-ink小设备,最好能是彩色不伤眼的;书当然越多越好,最好冷门、原创的书(或内容)都有;书的排版不要求跟实体书一样但也别像90年代的网页一样带着大蓝色链接和莫名其妙的折行、漏字,挤成一团,跟多看差不多我会非常乐意购买;价格最好别高过实体书的一半,制作特别精致的可以无上限;社区这块儿,最钟意豆瓣的书评、批注弹幕和跟作者的互动。

按照这个理想的存在,各家的做法是如下这样的(数据均从各家官网的书籍分类数目手动统计,不保证准确性):

kindle虽说从去年开始重视排版,可惜我最近想看的几本书排版还是无甚改进,搜到这篇文章链接里所说的几个出版社的书看,确实比其他书排版要好一丢丢,但是离好(比如多看)还差得比较远(模糊的封面、蓝色紧密的目录、奇怪拥挤的行距真是没欲望继续看下去–果然我还是太肤浅:p);

多看的书目前不到6万本,比上不足比下有余,书确实是非常精致,尤其以《唐诗三百首》为经典,简直业界良心&标杆,在iPad mini上看体验很棒,除古诗及注解以外,还介绍了吟诵相关的知识、诗人的生平、轶事,涨姿势的同时还能听吟诵版和朗读版。社区方面多看的书友圈和书评广场上线有段时间了但很遗憾的是暂时还没有吸引到我,除了邀约的名人稿子很少看到出彩的书评,倒是有个任务系统+限时免费挺有意思的,敦促我在3天内认真的看完了2本书,还做了笔记并导出到了evernote(笔记看起来也挺精致),以后需要再用到这些书时估计会优先在多看买,如果多看如果能推出包含这些好书的会员制(特殊的超贵的书可以单拎出去,会员有折扣价之类的,包含在会员里的书可以按阅读量给出版社分成),每个月十几二十块最好(京东电子书倒是有类似服务但书的质量跟kindle差不多…),对我吸引力会比较大;

豆瓣阅读,从诞生起就从未停止探(zhe)索(teng)的脚步啊,阅读弹幕、投稿系统+专栏/连载/原创作品、原创作品大赛和各种读书小活动,作品量虽不多(加上原创不到2万)但偶尔也有些独家电子书及有趣独特的内容时不时地吸引我(对网络小说一向没啥兴趣但啃硬书又啃得不太积极)。书的排版引擎改进过几次后,精致程度虽不如多看,但是比kindle强不少;今年初新发布了2.0版本强推自媒体结果在知乎上被黑出翔,黑点主要集中在1)新logo丑;2)强制展示首页;3)书架拆成已购和本地,删掉了老版本里本地数据,阅读进度丢失,已购里书和连载、专栏混杂,随着版本的迭代,2已经优化,1、3依旧,1中原logo跟加载时跳来跳去的那只鸟换成现在这样其实还挺可惜的,3中损失了升级前1.9版本的本地数据,对我而言最大的损失是有些试读但当时迟疑未购买的作品,后面新版本里已经找不到了,汗…以上这些,对书多的老用户1.x升2.0冲击的确有点儿大,知乎上有人吐槽产品汪不尊重人神马的,我看更像是策略失误以及豆瓣一贯的『边做边改』,『用心』、『考虑周全』、『细节把控』此等产品汪重要技能,都是在用户骂声中积攒的所以有时候并不到位-正所谓『心有余而力不足』,你把时间拉长可以看到,豆瓣的汪们心意是够的,你看他们一直在坚持做一些不同的有趣的东西,2.0之后的版本迭代也在积极地修改和优化,个人或集体的决策、方向随时可能会出纰漏,更何况产品需求本身就存在『众口难调』的难题(比如我至今仍不适应已购跟本地作品分隔的那么开,哪怕本地书籍是基于『枕边书』的概念来设计的,像多看的书架以试读、下载的图标或『仅显示本地』的分类来区分不是更简洁高效么?这样我还不至于损失1.9版本里的试读书籍呢,且不同设备间的试读作品要如何保持连续呢?),再者,产品本身的特性和气质也是要有的,并非一味迎合用户才是最好的产品,所以还是给点耐心和时间看看他们到底会做成啥样,话说,豆瓣阅读要是黄了还真不知道上哪儿找替代品呀。

关于各家共同的难题:电子书制作成本高(也即豆瓣、多看电子书数量少,kindle电子书品质渣的原因),这篇文章 或许能出一定程度的解释,kindle试图通过推行工具+排版规范+出版社『自转码』来降低成本,尽早达成质、量双收,无奈有觉悟和实力的出版社还不多,要等大部分出版社规范起来似乎不太现实那有没可能用众包的方式来做呢?比如先由电子书平台获得出版社授权后,由读者认领书籍,基于不规范的电子文档在平台方的电子书制作平台上对目录版式等进行加工,再由平台方统一审核,报酬可以是这本书,也可以是别的电子书,这样就把加工成本以电子书的形式消化了,出版社、平台、读者都高兴,这么好的法子为什么现在没有人这么做呢?粗略想了下,多人协作的编辑平台、众包活动的运营、电子书排版质量的把控等等一堆难点估计足以把这想法扼杀在摇篮了,不过,如果我是相关平台的产品汪,估计会先找些读者跟出版方调研下,万一行得通呢?想想,亚马逊要是能这么干,威力简直无法想象。

豆瓣阅读是早就想开了,没跟别人盲目比书的数量,而是依托豆瓣社区,电子书只抓住最新热门好书,估计还有Top想看的书(豆瓣),自出版深挖掘草根作者+深运营,相信也能黏住一部分用户(我是被黏住了,不知不觉这几年花费近千元了,像《斫琴记》这样的作品目前还只有豆瓣有呢),但不知道这样的用户能有多少。

这两年我在书上的支出远超出之前的总和,纸质书跟电子书,大概2:3的样子,但数量上,电子书远超纸质书一个数量级(其实也就是百跟十的差距啦,:p),这也让我的阅读量大涨,尤其一些大部头(比如《失控》,几年前买的纸书,挑战过数次都没读完,后来买了电子书,最近终于看完了第一遍…),电子书真心方便,坐车、等人的碎片时间都能充分用起来。

这不禁让人想起那个经典的问题:『电子书多大程度能代替纸质书?』从我自身的经历和感受来讲,关键取决于电子书最终体验的到位程度,包括书的版式、多媒体交互、各种体验(笔记、跳转等),读者、作者间的互动(豆瓣阅读的弹幕批注还是挺有乐趣的)等,完全替代,在我看来短时间内不太可能,总有些书你会在看完电子版之后忍不住还要买本纸质放在床边书架上的(比如李娟的《冬牧场》,村上春树的《挪威的森林》等等),还有些书我只有纸质版(比如《小王子》,有各种不同的版本),这时候纸质书已经演化成一种超越阅读本身的存在了,从可行性角度讲也是so easy的,按需出版就能很好的解决库存仓储等难题。