Posted by & filed under 生活.

用景深计算器算了下,与全幅100mm相同视角下要达到全幅F/8.0的景深效果(全景深约5.04m),对比大概如下:

  • Canon 5D2 全幅,100mm/F8.0 景深5.04m
  • Canon 7D APS-C画幅, 63mm/F5.0 景深5.09m
  • SONY NEX APS-C画幅,66mm/F5.0 景深4.74m
  • LUMIX GX1 M4/3画幅,50mm/F4.0 景深5.06m
  • RX100 1寸画幅,31.4mm/F2.0 景深4.68m

总得来说结论如下:

  • 全幅真牛X,比C画幅都好了1个多档(约1.3档);
  • M4/3和APS-C差不到一个光圈档(约0.6档),差距没有想像中的大,难怪有不错的生命力。
  • 1寸对于玩景深而言依然是玩具,跟M4/3都差了近2个档的光圈。

但是,似乎如果把焦距放到广角端,差距则没想像中的大了(但1寸画幅计算结果依然是渣渣,虽然总感觉实际拍摄给我的感觉不是这样),大概因为景深本来就是动态的玩意,也计算不出个所以然来,所以还是用100mm这样的人像焦距会比较直观。

Posted by & filed under 团队.

最近挺多人讨论玉伯和左耳朵耗子的争论:一方坚持小而美的团队和优雅的解决方案,一方认为土方法办大事。知乎链接: http://www.zhihu.com/question/33406762

谁都喜欢精英团队,少而精而且都全栈的团队,不管是攻坚还是防守都非常厉害,而且出品有保障,基本都是精品。但的确不稳定,一方面是精英们基本都有脾气,揉在一起不容易,还容易闹矛盾;二是精英们不见得愿意一直待在一个地方,而人员流动对于团队而言是硬伤、尤其是精英团队。

而@玉伯 说的土方子团队,则是少量的精英带领大量平庸的人,然后技术上也使用更多很土很丑的办法,更容易做成大事、尤其是大规模的事。

我虽然很喜欢@左耳朵耗子 ,但的确对于大公司而言,@玉伯 说的会更实际一些,由精英带领的土团队会更符合国内这片土壤当前的情况,而且我认为就算是国外团队也是一样的。

但可以寻思下,这两者之间真的有那么多矛盾么?关键问题是,这不是哪边更好的问题,而是一个公司的发展、想要形成规模效应,几乎就一定会往“大团队”靠拢。大而全精英的团队,这就是个神话了。

小而精英还能做大事,似乎也有相应的例子,比如instagram收购前就是13人团队,简直是奇迹。但instagram做的事情严格来说能算“大事”么?何况,里面大量的脏活累活大概都由ec2搞定了,而对于很多大公司而言,大概是不会选择这样的方案的,因为成本太高。

转向平台型团队

一个小而精英的团队,是一个很不错的开始,现在大多成功的公司都是由小而精的团队开始的,反之则找不出多少例子。

那么精英小队有两个发展选择:发展为大的土团队,或是努力招揽更多的精英而形成精英大队。明显前者更靠谱一点,因为庸人好招而精英难招。本来人就少的精英团队还需要花心思在招人上,而且标准还不能降,这就容易导致两个问题:一方面是精力的分散,另一方面则是可能需要更多的时间来扩大团队,这容易导致产品错过发展的窗口期。

然而发展成土大队也有相应的问题,精英的稀释使得精英要把很多心思花在照看小朋友上,一是精英不见得愿意做这事,另一方面也会降低原来的效率。然后团队就进入了平台期,人似乎越来越多但做成的事却不多。然后如果精英那边不乐意了跑路了,这对于团队而言就是灾难了。

团队的成长大概也像种树,不是一朝一夕的,而且是需要结构化的。一方面,根系要深扎,才能得到充足的水份;然后树干要坚挺,才能触达更高的天空而不会被别人抢了;再来就是枝叶要茂盛,才能吸收更多阳光。只有根系只有树干或只有枝叶,都是不行的。全精英的团队,很可能是接触不到阳光的。而其中树干究竟是什么?对于团队而言,大概是文化与制度,连接着精英与一般人。

理想的团队

在我看来,理想的团队大概像榕树,会有“气根”:由枝干下垂,长至触及泥土,入土长粗,成为支柱根。这样的团队,规模上不断扩大的同时,却能多方位的发展,让新发展的庸人也不断变成精英。

而最理想的团队,大概是像世界树那样吧。

world-tree

 

Posted by & filed under 发展, 生活.

坚持与练习的重要性

运动者大概最能体会坚持与练习的重要性。在这个过程里怎么样由量变引起质变,然后如果放弃了的话是怎样变得不在状态与弱小。我也希望能从中去体会,也许也对我看待其它技艺有好处。

比较悲惨的是我没能找到这样的大师,所以只好去找相关资料文章来学习了。

Posted by & filed under 团队, 开发, 设计.

只是一些初步的想法,关于最近做App开发及设计的一些具体流程,也发出来记录一下

  • 最小团队: 1开发 1设计
  • 理想配置: 2开发 1视觉 1交互 1产品
  1. 核心产品定位:目标为Idea催化
    1. 细化具体Idea为功能点,使用白板/邮件/讨论组/用户访谈等前期准备,出产品策划书
    2. 出首屏布局稿和产品层面的闭环流程,出一两个核心界面的UI概念图,使用工具为Sketch/Photoshop
  2. 交互流程图讨论
    • 只用文本框和线条箭头等画出用户的具体操作流程,覆盖主要功能及流程分支,使用工具为 AxureRP 7.0+ ,出稿10p左右(每个重点功能与核心界面1p), UI可以同步出更多概念稿
    • 开发侧进行架构选型及技术储备
  3. UX交互讨论
    • 挑出第2步中的核心流程把大致的线框图及流程画出来,只使用圆、方、灰度颜色、文字条和必要的文字表达,不涉及UI细节。 使用工具为 Sketch/Photoshop;
    • UI能进行核心界面的讨论与创新性设计;
    • 设计侧需要知会开发侧进行可行性分析
  4. 视觉设计
    • 进行核心界面的高保真设计,UI方面在不改动交互流程及具体元素重量的情况下,能最大限度地改动界面布局与导航布局,需要知会开发侧进行可行性分析
    • 开发侧开始搭建基本开发框架及环境
  5. 最小可用版本开发
    • 界面开发重构童鞋开始满载工作,目标是最短时间内至少完成一个核心流程的交互体验;(可以考虑先忽略注册登录等前置流程、也忽略数据侧的功能需求,只完成可体验交互原型)
    • 侧试侧童鞋可以开始进行测试框架搭建
  6. 核心功能开发迭代
    • 从前置流程等开始一个一个流程地进行开发完成
    • 开发过程中同步让设计/测试童鞋进行功能及细节走查,定期进行汇总输出与review
  7. 版本收官优化
    • 设计侧与开发侧完善每一个缺漏,不再进行功能的调整与添加,甚至砍掉来不及的功能;
    • 产品侧开始准备上线运营细节,准备发布
  8. 接收反馈
    • 建立种子用户群进行产品各方面的讨论
    • 开始准备下一轮的产品定位
    • 开发侧Bug与优化现有结构

Posted by & filed under 生活.

jungle

 

回首码农生涯,我个人大致的学习路线其实算是可考的:

  • 07年高中毕业开始,由潭浩强的《C语言》开始入门。回首而观之,这本不见得是什么好的入门书,如果现在看回来,大概《C++ Primer》与《UNIX编程艺术》算是后台入门圣经,而零基础入门编程大概以《Learn Python the hard way》为上。但其实这些都不算WEB或UX方向。
  • 09年看《CSS禅意花园》及《WEB高级标准解决方案》算是入门WEB前端。做学生会网站,主要是研究Wordpress主题及插件开发。
  • 11年毕业工作,主事数据平台前端开发,此时前端方面主要使用jQuery及其UI,工作内容上前后端依然耦合,所以依然看很多PHP的东西。前端方面嘛,其实没啥书好看,都主要看各种工具的官方文档与各类论坛博客。
  • 13年开始前后端逐渐分离,主要使用 jQuery, BackboneJS, Bootstrap。Nodejs, Expressjs, MongoDB等JS的后端应用开始尝试,但其实缺乏大量实践的情况下还是比较处于观望状态。PHP受制于工作环境的5.2版本的限制,基本已经不再钻研。学习的资料内容依然是官方文档和论坛博客。
  • 14年则开始接触Hybrid开发,SPA的开发,以及Grunt, Bower等基于node的工具使用。开始大面积使用LESSCSS与Coffee-Script。

我想这份资历在前端界应该也算是小资深了,毕竟这个领域是如此年轻。

五年最大的感触是,比起三年经验时的彷徨,多了一份从容。已经比较清楚地知道,哪些地方可能有哪些坑,可以做哪些尝试。

编程七年,前端五年,看山不是山

如果是其它已经至少几十年甚至几百年沉淀的领域,才这么几年光景远谈不上看山不是山的境界,但前端这样的开荒领域却很悲催,因为整个领域被一团迷雾笼罩,所有人都像盲人摸象。我就感觉,BAT三个公司看前端应该思路都很不一样,甚至腾讯内部做游戏的、做支撑平台的、做媒体的……看前端的思路都很不一样。

知道得越多,当然不会感觉越无知,这个阶段毕业时就该已经跨过去了,而现在心烦的则是另一件事:就是各类知识之间的打架斗殴。前端显然是个领域而不是个方向,所以非常有无头苍蝇的感觉,转来转去不明所以。

显然,前端是没有定位的——缺乏像“编程就是结构与算法”这类的定海神针,还外加夹在了设计、编程、产品之间,让整个基石都不稳固,左右摇摆。悲剧的是,前端人士们也被这样的不稳定拉得左右摇摆,像个救火队员一样,哪边缺人就被塞到哪边。

显然,前端是没有大师的——甚至连本科这个级别都找不到一个这样的专业,大概是没人能教,也发展太快。但社会上行业上却已经产生了大量的需求与岗位,然后我所看到的是,各大公司的前端大致可分为由UX入行与编程入行两类人,各自用各自的有色眼镜看待前端。也难怪行业里那么多人呼吁跨界,因为不跨界的话这简直没法干活。

这是一大片的红海,然后所有人都在浅水区徘徊,深水区的人太少以至于简直遇不上彼此。

大概也是这个原因,使得这个领域相对资深的人士们都非常的开放,自己的思路、成果像不要钱一样地开放给整个互联网,反而造就了看似繁华鼎盛的行业气象。

前端好就好在这些地方——这是个有才能的人、有想法的人、实践的人容易出头的领域,至少值得下一个十年的投资冒险。

也发在我的知乎专栏《前端小记》:http://zhuanlan.zhihu.com/qianduan/19958861

 

Posted by & filed under 开发.

不要误会,HTML5依然强大,只是对于手机应用而言,依然受到各种限制。

这种限制不来自W3C的规范发展或是新特性支持的缓慢,而是依然来自于本地应用或浏览器对其的支持不够多也不够重视。这种不重视感觉主要体现在两方面:细节功能的缺失,入口的缺失。

细节功能的缺失:

– 本地存储容量限制
– 文件I/O
– 媒体文件浏览
– 后端向前端推送,尤其是在App已关闭或静默的情况下

入口的缺失

– 必须通过一个URL或是一个内嵌页面访问
– 浏览器下的UI受到地址栏与工具栏的限制
– 目前可用的入口都是社交入口,没有针对应用设计的入口

当然似乎这些问题通过PhoneGap或WebView之类的加壳手段都能解决,但这又意味着丧失了HTML5易于传播的特性,感觉是得不偿失的。

WebOS之死让很多前端心寒,但想回来也许反而也是好事,也让HTML5变得有更多的可能与遐想空间。

Posted by & filed under 开发.

前几天看到酷客这篇文章《关于linus对于对象引用计数延伸出来的看法》 , 加上最近还在看的O’Reilly的《黑客》,感觉对黑客充满了敬畏。

可以看得出来,这个领域最top的人们在想些什么。他们真的不care互联网上面各种各样的应用,太low;也不care框架级的功能级的东西,依然太应用级;

他们依然在整个信息计算世界的最低部,研究些真正硬核的东西,关于对各种基础实现方案的看法,关于计算机编译级别的、操作系统级别的一些细节,关于数据是如何被读取、解析、处理等等的问题。

用数学来涵盖这些可能都显得狭义,就像在用哲学来覆盖物理学一样苍白。但也许,数学就是他们的理想国的武器,而具体的计算机、以及里面的每一次读写,则是束缚着他们的真实世界。

不管什么时代,真正的黑客精神都只有极少数人能得以继承,也许这种精神更多来自于与生俱来的天赋,然后才是社会环境给予他的平台。

这个社会上也许很多程序员,但真正的黑客精神,依然属于那些喜欢折腾计算机多于喜欢金钱的人们。

Posted by & filed under 开发.

粗略地与翻译自 Smashing Magazine:

为了帮助你接触到完整的Marionette的潜力,我们已经准备了一整本的电子书、里面有大量的手把手的例子,可以通过 Smashing Library 来进行购买。—— Ed

在系列文中,我们已经讨论了Application与Module。 这次,我们会看一眼Marionette是如何帮助Backbone的视图变得更好的。Marionette继承了Backbone的基础View类来给我们提供更多的内建的功能,来避免大部分的通用性的代码量、同时也使更多通用性的代码能够通过配置的方式来达成。

我强烈建议你先回去重新读关于Application与Module的文章,如果你还没有读前面的内容。在这篇文章中有些提到的内容会是关于前面的文章已经描述过的,然后这是一个关于Marionette的系列文,所以如果你希望学习Marionette,你应该通读整个系列文。

事件绑定

就在最近,Backbone的View常常被错误地使用,导致了被称为“僵尸视图”的问题。这个问题的原因是许多视图会监听了model的方法,这本身是完全无害的。问题来自于当视图已经不再需要并且已经“被遗弃”时,他们并不会停止监听相应的model的事件,意味着model依然有着视图的引用,使得视图的内存不会被垃圾回收器所回收。这导致了内存会随着时间不停地增加,而且这些视图始终会响应那些model的事件,虽然它已经不再会进行任何渲染行为,因为它已经被从DOM节点中移除。

许多Backbone的扩展或插件——包括Marionette,都预先处理了这个问题。但我不会说明更多的相关细节,因为Backbone的开发者们已经在最近的1.0版本自己解决了这个问题(终于!),通过对Events使用listenTo和stopListening方法,而Events正是Backbone.View的基类。Marionette的开发者也已经把这部分功能实现从代码中移除,但这并不意味着Marionette不能帮助我们处理更多的关于事件绑定的问题。

Posted by & filed under 开发.

粗略地与翻译自 Smashing Magazine:

在上一个部分,我们主要讨论了Marionette的Application。而这次,我们讨论下Backbone.Marionette中包含的模块系统。Marionette的模块可以通过Application来访问,不过这部分内容是个相当大的话题,值得用一篇文章来讨论。

模块是什么?

在讨论如何使用Marionette的模块之前,得先确保我们有一个较为得体的对模块的定义。模块是一个独立的代码单元,理想情况下只完成一件事情。他可以与其它模块互动来完成一个完整的系统。一个模块越独立,他越能被替换、或是进行一些内部改造,而不影响到系统的其它部分。

对于这篇文章来说,我们只讨论到我们的需要来定义模块,不过如果你需要更多关于编写模块化的代码的相关内容,互联网上可以找到大量的资料,《深入单页面应用》中的可维护性依赖于模块化章节 就是篇不错的文章 。

JS语言现在还没有任何内建的方式来进行模块管理(新版本的ECMA似乎会进行相关支持),但许多正在兴起的工具库都能解决这类定义和加载模块的问题。Marionette的模块库,非常遗憾地没有提供从外部文件加载相关库文件的功能,但他也提供了很多其它模块工具库所没有的功能,比如启动和停止一个模块。我们之后会谈到具体的相关内容,但现在我们先看看如何定义模块。

Posted by & filed under 生活.

美国队长3的内容已经确定为Civil War(内战),可以想象得出他的票房会有多么火爆。

内战可能国人没什么反应,但对于美国人,南北内战可是永远刻在骨头上的最深刻的痛。那是美国 唯一的一场的内战,一场没有正义方的战争,一场血肉相残的战争。

再看美队2与美队1,美队2说的是监管与自由,而美队1说的是二战。与其说美队这部电影说的是美国精神,不如说美队说的就是美国历史,美队这样的一个完美人物、在美国的一个又一个标志性事件中穿插、痛苦、挣扎、突破。

美国人当然爱看这样的东西,就像中国人孜孜不倦地看各种国共内战与抗日战争一样。那是一代人的烙印,真不是开玩笑的。人们也需要用各种方式铭记,以避免悲剧的重演。

有的人喜欢用严肃一点的心态来缅怀,也有些人希望用消遣一点的心态来纪念。电影当然更适合后者,严肃与缅怀还是留给纪录片吧。

相反看DC那边的超人,虽然跟美队不具可比性,但同样是近乎完美的人物,却显得极其没有特色,就是这么个无敌的外星人在现代地球的故事。

可乐与爆米花的电影时代,我们其实都不想在电影院看变态的人性阴暗面的故事,也不想看缺乏内涵苍白无力的人物与故事,更不想被迷宫似的的内容、结构与背景弄得头昏脑涨。想有个叫好又叫座的电影,真难。

但也许美队的成功给我们两个启发:

  1. 完美而中庸的人物,似乎能对整个主题造成几乎最小影响的同时、成为主题最好的载体与支撑;
  2. 主题的选择至关重要,有些题材,天然就适合那些主题,比如美国精神与美国历史,这简直就是一对双生子。

Posted by & filed under 发展, 团队.

“互联网思维”这几个字现在简直已经如日中天,所有人都迫不及待地去抓住这一拨机会,大搞一翻。

但似乎所有人都只在管中窥豹,却谁也不知道“互联网”、“连接一切”究竟是怎么回事。

在媒体人的眼中,互联网似乎是个潘多拉的盒子,是一切灾难的来源,却又是仅存的希望;似乎是能解决一切问题的良药,同时却又是所有现有存量及结构的毒药;互联网似乎是很多东西,既是大数据,又是自由人的自由联合;既是低成本碎片化、又是极致效率;既是铺天盖地的信息,又是彰显的每一个个性……也许,在他们眼里,互联网更多只是一个标签、一个话题。

Posted by & filed under 开发.

粗略地与翻译自 Smashing Magazine:

Backbonejs正在变得越来越流行,但不像Emberjs(译者按:Angularjs也是),Backbone因为他的最小化,使得大量的问题留给了开发者需要自己想办法解决。

所以,一旦你介入到了一个更复杂的应用,Backbone就变得不那么简单了(虽然这本来是他的优点)。Marionette就是来解决这种Backbone开发的、逐渐出现的痛苦。

中心App对象

大多数人做一个Backbone App时都会先整一个中心对象并把所有的东西绑在上面,通常命名为App或Application。但Backbone本身不提供这个功能,所以很多人直接使用Router作为这个对象。当然有App对象总比没有的强,但Router却不是设计来做这类事的。

Posted by & filed under 生活.

乔布斯走后,Apple的设计与创新似乎变得不再那么亮眼。也许,很长时间我们都不会再有像之前iPhone那样级别的One more thing。

看到iPhone 6现在突起的摄像头、丑陋的天线,不得不一声叹息。

不再有iPhone 4那样极端的工业设计,而开始变成像现在,设计上为各类实际的或商业的问题而妥协。

Apple似乎开始定格,变成一个相对保守的企业,除去了激进与微型,却开始维持起他们自己帝国的生态,制定起他们自己的法律。

不得不说,就算Apple就此定格,从激进地创新走向稳定地维持产品,Apple依然能保持他的地位。

这当然是更吃力不讨好的举措,却是更有竞争力的举措。

而且,比起不断地革命,这个世界也许更需要这种稳定的、高品质的、不断优化——更好的产品。

从此,世上少了一位海盗、多了一位商人;世上少了一个设计公司、多了一个帝国。

Posted by & filed under 发展.

最近因为一些原因原来的iPhone 4S 不用了,所以整了一台小米3得用两三个月这样。

白色的夹心饼干的设计,抄袭的Lumia 920。

其实我有点后悔,应该买红米的,720P已经很够用了其实,而且说不定很多界面表现还会更好,电池也是3000mAh,说不定比小米3还要耐用。

Android最主要的耗电项应该是屏幕。这个代价来自于对成本的控制和对高清的需求,反而iPhone的各方面配置都会着重考虑耗电问题,所以可以用小于Android主流电池容易一半的电池做到甚至更长的使用时间。不过,iPhone 6屏幕变大,所以一切又变得不好说了。

Android用户对于跑分的需求,使得整个市场变成以硬件厂商为主导的狂欢盛宴。相反看iOS端的硬件配置,就会觉得真没有那个必要。因为,真正影响用户体验的,其实更多是软件侧的优化工夫。至少玩PS3的时候就能感觉,512M的内存一样能做到很厉害的事情。

米4之于米3的升级并不大,也体现出整个市场对于跑分已经开始没有那么严格的追求,保证一定周期内硬件水准的稳定,似乎变成了比单纯的跑分拼硬件更重要的事,否则,性能与游戏质量的参差不齐使得Android上众多游戏的体验难以得到保证。

这个问题小米注意到了,Google显然也注意到了(Nexus 5 的性能不算很强、而且开始推出低端手机)。

不得不说,虽然Android在整个平台策略上落后于Apple挺多,但已经正在跟进。

Posted by & filed under 发展.

奎托斯,PS3游戏《战神3》的主角,宙斯之子,一生经历跌宕起伏,弑杀多位神明。

战神第三部中,游戏画面未出现之时,就会先出现一句话:

THE MEASURE OF A MAN IS WHAT HE DOES WITH POWER
— PLATO

就不说如何评估一个男人这个话题了,总是是,Power 从何而来?

奎叔那样大杀四方,作为一介凡人,凭什么能杀死海神使世界洪荒、杀死太阳神使乌云蔽日?

其实,就算是奎叔自己也知道,大多的力量其实不来于自己,而来源于已有的其它力量。

游戏中,则来自其它神,如潘朵拉、如雅典娜。

奎叔其实只是众神的战场,也许命运稍比棋子高明一些,但也高不了太多——前战神利用他夺取神位,雅典娜利用他追求和平,宙斯眼看着他兴风作浪却无所作为,无非认为格局过小、随时可以捏死——事实众神之王也的确这么干了。

最终击败宙斯的是奎叔么?也不是——击败众神之王的,是潘朵拉盒子中仅余的希望。

现在看BAT三分天下虽然似乎很激烈,但其实三位都远未成神,就算是Apple还是谷歌都如此。

否则他们又怎么会赤膊上阵、你死我活,争相收购只求自己壮大?草原中最可怕的是牧羊人,而不是狼群。

未到那个境界,也未到牵一发而动全身的局势罢了。

这次工业革命,才刚刚开始。且看十年后风起云涌。

Posted by & filed under 发展, 生活.

最近发现,自己在家做的意式咖啡已经比大多数外面的咖啡厅好喝和正宗了。虽然不知道欧美的咖啡怎样,但大概亚洲的话,优质的咖啡师凤毛麟角。

一杯咖啡的成本究竟是怎样的?

就说星巴克,看到过一个数据说,门店及经营的成本加起来是最高的,40%左右,而原料成本大概在15%左右,机器成本摊到每杯咖啡大概4%。计算咖啡厅的流水量的话,机器相当地不便宜;

但真说咖啡机和设备,大概真的很重要也很不重要——我在家这两年大概喝了上百杯咖啡,机器加上周边费用大概只有500块,就已经可以做得比他们好了。

因为,两年时间的不断磨合与研究,让我能弄清楚这台机器的脾性,知道工序如何优化、顺序怎么样、用什么样的材料,才能做出更好的咖啡。

我不用illy的咖啡豆子,而用星巴克的,因为星巴克的更不会挑机器,更容易萃取与出油脂;

我知道预热过程有多么重要,不管是对出咖啡还是出蒸汽——尤其对于烂机器与家用的环境;

我知道稳定的蒸汽对于打发牛奶来说有多重要,更知道

好的咖啡机对于一家咖啡店来说最重要的在于,能提升容错率——使得不需要太多的钻研,也能做出相对还不错的咖啡。

但这对于常喝咖啡的人来说,简直就是个灾难。

我们TMD知道好的咖啡和差的咖啡的区别是什么。

为什么差的咖啡机也能做出好的咖啡?

大概因为,其实意式咖啡本来来说并不是特别复杂的东西,而且,大多数复杂的工序,都已经在具体的制作过程之前。

意式咖啡,在我看来以拿铁与Cappuccino,这两者需要做的事情,无非就是咖啡与牛奶的融合:咖啡就是定时定量压力萃取,奶泡就是加热打发,真没多复杂。用合适的豆子,300块钱的咖啡机都能出油脂;而挺多贵一个级别的咖啡机,大概一千到一万级别,他们的海报上却有时难见到那种油脂量,甚至连星巴克的海报中的咖啡有时都看不出Espresso的油脂,大概可以明白,那些其实也就那回事,油脂也并不是什么一定要追求的东西; 挺多咖啡爱好者也都会喜欢上爱乐压做的咖啡,却讨厌挺多不负责任的咖啡师用贵重的机器做的,由其间可见一斑。

真是不由得感慨,这个年代背影下,大多数人都相当业余,极缺肯耐心做好当下事情的人;而业余的人却有可能十分专业,在不断地突破自我。专业与业余真不需要看得太割裂——他们需要相互学习。

Posted by & filed under 生活.

我们不是什么脑残用户,我们有着自己强大的生存方式与力量。

让我们转而追求程序员体验, 去他妹的用户体验。

Don’t make me think? 如果想让我们不思考,请使用程序员思维。

外面流行受限制的、平坦的、简化的思维。也许那适合外部推广,适合大多数人的需求,适合做到极致的界面交互与用户体验,适合简单无脑零学习成本……

但这真不适合我们。

我们的思考是立体的、层级的、嵌套的、回调的、动态的。

想想我们所立命之本的语言,真不是中文或英语,也不是Office三件套那堆屎……

我们的饭碗语言,是他妈的 C/Cpp/JAVA/Python/Javascript,是JSON/XML/YAML,是SQL/NoSQL,是Txt/Markdown,是Pipe/Http/RESTful…

不要再拿普通用户那堆屎来招待我们,拿些诚意来了解我们、取悦我们!

消费是用户的事,生产却是归我们管!

我实在太不爽Eclipse那样的笨重,像JSFiddle那样的延迟,像Gist那样的弱小,像Evernote那样的莫名其妙地去支持些商人,像Sublime那样的不成熟需要挂一堆乱七八糟的东西……

拿点诚意在生产上, 像Github就不错,但也还不够好!

互联网思维横行的世界,不要再让我们程序员自己的世界却还停留在几十年前。

Posted by & filed under 开发.

本来只是在整理一些关于backbone的各类插件的资料的,发现github上排名最高的几个:

  1. backbone ★16,781 这个是本体就不说了
  2. todomvc ★8,423 这是各框架各版本的todo范例集合,其实不能算作backbone的东西
  3. backbone-fundamentals ★7,337 这是一本电子书
  4. backbone-marionette ★4,374 这是一个框架

上面排第三的那本书,是一本相当不错的书,有电子版本。看了下内容其实写得相当不错,可惜不知道什么时候才能有翻译。

重点是,这本书里面说到最深处的框架就是上面排行第四的 Marionettejs 这个框架。

Marionette.js

Marionette是牵线木偶的意思,这个库是对Backbone的一次更高层次封装。这样的封装有两个目标:

  1. 减少重复的工作,提高使用Backbonejs时的生产效率
  2. 给复杂应用页面提供更多的结构,以支撑后续的扩展操作

他主要在几个方面增强Backbone:

  1. 增强的各类视图,主要是 ItemView, CollectionView, CompositeView
  2. 视图管理工具:引入了Region(区域)及Layout(布局)的功能
  3. 各类控制器:主要是Application及Controller,也实现了一个类似 Requirejs 的Module管理工具
  4. 对象-消息处理工具: 主要是扩展了 backbone.wreqr(不知道是啥) 来实现了一些消息机制:如简单的命令执行框架Commands,及请求/响应框架 RequestResponse等。
  5. 还有一些其它的特殊工具库: Router, callbacks, functions等,应该是大概是针对应用层对一些复杂情况的结构化处理

结论

可以感觉到,对于小微框架而言,plugin及更上层的封装都是常见选项,而且的确很多人在使用Backbonejs时的确遇到了大型应用的开发需求。这时,Marionette就是一个不错的选择。

转载请声明原文地址 http://blog.waterwu.me/backbonejs-based-marionettejs/

Posted by & filed under 生活, 设计.

之前也有用过传统的压感笔,基本上硬件要求很高:必须得用带压感检测的数位板,用来检测笔触的压力、以及笔触的位置、包括悬空时的位置等等。三星Note最早时的概念似乎就是把这个东西做成一个小本子形状的手机,后来不了了之了。带显示屏的数位板Wacom也有做过,但简直是天价,而且除了画家,基本上,应该是没人用的……

但最近各种iPad压感笔却开始冒出来了,这跟他们最开始所认为的大相径庭,的确相当好玩。

笔触类型、压力等等全都放到了一支笔上,不再有那块板、以及与电脑相连的线,等等。然后,通过蓝牙直接与平板通信。

压感笔重新在iPad上复活,最典型的代表应该就是 Wacom Intuos Creative Stylus 和 Paper Pencil了。

感觉有意思的是,苹果方面没有做任何的妥协,依然是那块电容触控屏,通信依然只有蓝牙没有NFC。

Posted by & filed under 开发, 设计.

DPA: Data presentation architecture

数据陈述架构

Data presentation architecture (DPA) is a skill-set that seeks to identify, locate, manipulate, format and present data in such a way as to optimally communicate meaning and proffer knowledge.

数据陈述架构(DPA)是一个技能集合,旨在寻找某一个方式来识别、定位、维护、格式化和展现数据,从而能更好地传达其中的意义和提供知识。

DPA is neither an IT nor a business skill set but exists as a separate field of expertise.

DPA不是一个IT或是商业技能集,但他作为两个领域的交集专业技术而存在。

Often confused with data visualization, data presentation architecture is a much broader skill set that includes determining what data on what schedule and in what exact format is to be presented, not just the best way to present data that has already been chosen (which is data visualization). Data visualization skills are one element of DPA.”

通常会与数据可视化混淆,DPA是一个更加广泛的技能集,包括了决定什么数据以什么计划用什么确切的格式来进行展现,并不只是以最好的方式来展现某些已经被选择了的数据(这就是数据可视化所做的)。数据可视化只是DPA之中的一个部分。

摘自Wikipedia http://en.wikipedia.org/wiki/Data_Presentation_Architecture

Posted by & filed under 发展, 开发.

大学时在学生会IT部,新人的培养有非常大的问题:一个新人通常干了一年就闪,留到第二年基本只有20%,作为生力军。但生力军通常都事多权轻责任重,所以通常只有20%不到能留到第三年、挑起大梁。大多数生力军的生存周期只有两年,而大多数人来时什么也不会,走时还是什么也不会。

之前以为只是大学社团才有这种青黄不接的情况,但看来其实在行业中比比皆是。尤其对于不成熟的领域而言,比如前端,更是心中永远的痛。

之前有一次前端业界的分享会(WebRebuild 2011貌似),主题就是“七年之痒”。其实,说的是大多数人做到七年时,就会换领域或走人了,又或者是变得麻木不仁。

也难怪大前研一要去写那本《专业主义》,也难怪这本书能被许多行业领军大力推荐。

Posted by & filed under 发展.

学习的重点与目标,是自己去探索。尤其是第二甚至第三专业而言,应该尽早地脱离枯燥的境地。

圆规大家都会用,但此前学习的过程中都十分局限,基本只会用来画圆、中分线等。

但其实圆规的用途非常非常多,可以追溯到很经典的尺规作图的范畴。

尺规作图是指用没有刻度的直尺和圆规作图。尺规作图是起源于古希腊的数学课题。只使用圆规和直尺,并且只准许使用有限次,来解决不同的平面几何作图题。尺规作图使用的直尺和圆规带有想像性质,跟现实中的并非完全相同:

  1. 直尺必须没有刻度,无限长,且只能使用直尺的固定一侧。只可以用它来将两个点连在一起,不可以在上画刻度;
  2. 圆规可以开至无限宽,但上面亦不能有刻度。它只可以拉开成之前构造过的长度。

尺规作图 ——百度百科词条

尺规作图大概可以被整理得十分繁复而系统。学无止境可见一斑。

然而,很可能,对于一个人的认知过程而言,比学无止境更重要的,是一个在知识上探索与发现的过程。

作为触类旁通,尺规作图大可不必被我们学得如此之细,但如果能有更多的了解,从此而出发,应该能有非常多有意思的用法——就以如此简单的两种基础工具,就能作出很多很多漂亮的图形。这才是值得赞叹的重点。

而如果没最开始的这个引导过程的话,相信大多人对于尺规的看法也就只会止步于最基础的应用,从此扔到一边。

而跨过了探索的门槛,学以致用也只是水到渠成的事儿而已。

Posted by & filed under 开发.

GITHUB链接:https://github.com/watert/FRestJSON

文件存储,也叫嵌入式存储,就是指代码和数据放在同一个工程目录下,一起通过文件管理。

Posted by & filed under 开发.

现在可以选择的框架实在太多,关于各类框架的讨论也似乎永无止境,甚至,针对不同的问题,选用不同的框架似乎会有更好的结果。

既然选择那么多,为什么要忠诚?

jQuery

最开始接触框架时,看到的无非几个前端框架: 有重型武器:ExtJS/ Dojo / YUI神马的,也有轻的:prototype, mootools, jQuery。当然也有对于jQuery的体积的不满,于是自己动手做了微型的框架,等等。

但到了现在,基本也都是jQuery一统江湖。当然也有商业运作的味道,但的确的,可以省很多的功夫,让我把精力关注在更应用层的问题上:架构、模型、表现、交互,等等。

Posted by & filed under 生活.

每个人心中都有一个“小店”梦。

有人想要间海边咖啡店,有人想要间老友记那样的Central Park,有人想要间蛋糕店,有人想要间书店,酒吧,花店……

真希望有一天,每个人的这个梦想都会成真。

于是,没钱的学生们在小店里做店员、相互打情骂俏;

于是,忙碌之余,我们可以像找朋友或是回家似地找到个地方,坐下来安静一小会;

于是,满大街都是各种土里土气却贼有意思的小铺子,里面盛放着每个人的小世界。

于是,附近的人有了个共同的沙发,在这里认识彼此,胡天侃地。

每个人都是一个品牌,不止是行业上的、更是生活上的。

Posted by & filed under 开发.

Extending D3

一到了应用层面,各种扩展性、重用性的需求就冒出来了。之前我比较习惯用Backbonejs来做前端方面的封装,但现在发现d3js的通常用的方式似乎不太一样,更加的原始粗暴的样子,也算是复习javascript了。

Posted by & filed under 发展.

最近好多之前久不联络的同学又冒出水面,研究生第三年了出来找工作找实习。这一想还真是,尼玛这就两年了……

两年多前毕业时坚决地不考研,因为我得出一个结论:三年读书不如三年工作经验。

回望之前的选择,这结论大体上还是没错的;但我大概有些理解为什么还是那么多人推崇读研了。
现在各类公司招人都招得巨TM凶悍,尼玛现在的新入职的本科童鞋们工资比我们还高,研究生就更不用说了……

敢情读研出国拿学位神马的才是抗通涨的最好方法?

三年读研,效率其实真不高,还把激情消磨得七七八八。我直觉觉得现在开出那么高工资的那些大公司,其实都是HR惹的事儿,全国不择手段地圈人,然后为了降低人员流动率而给出各种福利好处。

其实想想也能理解,读研出来都26+了,国人平均买房应该在30岁(以下?),以大多数研究生的心理,我想都不太敢太折腾,想得估计都是良禽择木而栖,然后至少短期就此蛋定着。

嘿,正中HR们的下怀,然后创业团队们感觉就雪上加霜了。

只是这么一来,两三年前毕业的本科生们绝对立马不蛋定了——加薪速度不见得就能抗通涨呀,而且之前的同学们现在日子过得滋润多了。于是,又一次的鸡飞狗跳,HR们又该笑了吧;然后,待过大公司的童鞋们不见得就待见艰苦创业还开不出多少银两的创业公司们,于是从一个大公司跳到另一个,俨然成为了这个行业的一种生态。

不知道,是不是所有的新兴的、“热门的”行业都会这样?

又是一年毕业季,是该躁动还是蛋定呢?It’s a question.

Posted by & filed under 开发, 设计.

果然流量不够的话一直不会有多少动力去优化BLOG。今天一把文章放上 http://news.dbanotes.net/ ,流量立马蹭蹭蹭地上去了,立马有动力改造BLOG了。
才发觉SSH对于快速地编辑来说还是非常必要的,至少不用一直受限于cpanel的编辑界面,这是相当不爽的。

所以,我还是得开始把BLOG的内容往VPS上迁。虽然,对丢数据这类事总会提心掉胆的……

打算基于wp320的 wordpress-bootstrap主题来做进一步的设计

因为,我真是懒呀,而且反正对bootstrap也挺熟的了,就用别人的这个框架来进行改造就好。

wp320的主题的文件结构还是需要些时间来整理。毕竟不做wordpress已经好久了。

暂时来说,打算先把排版给调整好,再把基础样式调整一下,先只做这些改造。

我想,设计当然是情感化的

但目前来说,功能性需求大概是压倒性的:

至少响应式是现在BLOG的必不可少。

而情感化上面来说,BLOG这类个人媒体形式,太花时间在视觉要素上似乎也不是什么好事情。所以,我只打算使用简单的纹理和铺色,就像之前所做的那样。

当然,有可能需要对BLOG的LOGO什么的花些功夫了。

但愿改造顺利。

Posted by & filed under 设计.

就此前的Facebook而言,无疑他们是遭遇到瓶颈的:
手机应用开发的边际效应已经越来越高,而平台型产品本来就不能总在功能上进行大规模改进。如此大规模的公司,本来也该在更强悍的地方展开,而不是跟其它所有开发者一样卷曲在“APP”这么一个框架里困兽之斗。

Facebook悍然选择开发重量级社交Launcher,这真是闪瞎众眼的巨锤。

Launcher用来做社交平台,这真是个绝佳的切入点。

Android Launcher

Launcher是内建在系统里的程序,是用户界面的一部分,提供了定制桌面的能力:包括锁屏、widget的展示及管理、桌面交互等等。

在我看来他是操作系统与程序应用间的一个夹层。

这种层级选择的问题,对于计算机科学的人来说实在是太熟悉了。只是,似乎就没多少人会把目标放在Launcher上:更多人会要么直接做整个手机贩卖硬件、夹层如锤子科技做ROM来换取与各大厂商交易资本、或是更表层的应用开发。

做ROM的其实说来也不少,腾讯不也在做这这方面的尝试?不过就现在看来,做ROM似乎多少有些吃力不讨好(锤子科技后效还未可知)。

Facebook Home提供了一个极佳的思路——服务平台开发者大可以仍然把精力集中在偏软件的层面,少了很多试水的成本,也不见得就没有与各大厂商合作的资本。

所付出的代价就是:开发成本的有限度提高。毕竟对于已经有这样规模的技术储备的公司来说,Launcher的攻坚并不算什么难题;相反来说,锤子反而看起来像是背水一战、还多少有些眼高手低的感觉,真是不成功便成仁。当然,从另一这方面来说,锤子没有平台作为基础,当然只能更贴硬件商的大腿,这也是无可奈何。

变革

在我看来,Facebook Home 带来的最主要变革在于,把社交内容带到了更外层的世界。

Mark说的很对,手机设计的初衷就是联系朋友,如果从这一点来看,压根就不怕社交所带来的信息爆炸。

  • 锁屏时的全屏Feeds浏览,可以想像这可以给他们带来多少流量与粘性;
  • Chat Heads,不打断的聊天体验,这是传统应用做不到的;
  • 各种快速入口都可以集成在更外层的位置,少了启动应用的等待及至少一次的导航点击。

这才真是把Android发挥到淋漓尽致。

In App框架受到的限制实在太多了。手机应用的打开需要唤醒、解锁、找到应用、loading、然后才是应用内导航。

真弱爆了:10秒的等待已经足以让人焦虑。

切入点选择

Mark有在Q&A部分说一句话:

“I actually think this is really good for Android,” Zuckerberg says. “Most app developers put most of their energy into iPhone.”

大多数开发者都把目光放在了iPhone上,而没关注到Android这样平台级开放所带来的优势。这样的思维盲区让人很难想到做Launcher这个切入点。

Facebook Home 到底是成功还是成仁还犹未可知,但的确在切入点上非常的闪亮。这让人思考:如果我要做一件事,切入点应该如何选择?

建立坐标极其重要。有了坐标,就有了选择的可能。比如就从基础->应用这个坐标来说,就有那么多选择:

手机硬件 < ROM < Launcher < Widget / APP

总能从中找到一个平衡点,然后就是如何执行的问题了。

之前的Timeline和Graph Search,都只是让我感觉还不错;但这次,Facebook Home,我很看好你。

Posted by & filed under 设计.

交互设计存在着非常非常多的可能性,但无疑他只是锦上添花的东西,却不能雪中送炭。而交互往往极难体现出产品的核心价值。纵观交互设计大革新的产品,尤以Apple为甚,都意味着难产与可能的失败,非下苦功不能完成。

创业团队力求制作“最小可用产品”,而交互这种难以验证、非核心价值的玩意,当然经常会抛之脑后,至少也会“放下一期开发”; 而对于大公司而言,求稳的心态使得他们不愿意在这种空中楼阁下大力气,而把更多精力花在漫无边际的开拓战场上。

相互作用之下,当然越来越少人重视交互所带来的价值,也越来越少把心思放在交互设计上,理所当然地这块就逐渐没落,只能久旱之后等待某位大牛出来下场暴雨滋养一下已经干涸的这片土地。如 tweetbot, clear, path 等都在此列。

交互设计的实现成本也比别的东西高了太多成本,需要很多的经验,而且最终产出未必就能讨人欢喜。

面对这种状况,我只能悲观地认为,交互创新的大潮远还没出现,还需要继续耐心等待。

Posted by & filed under 设计.

比如可视编程、拖曳式编程、即时反馈等。

编码效率与直观反馈之间是有矛盾的

因为越直观的东西往往越会有失客观性与精确性,之使得如果一个编程的或交互的语言越靠近人(比如手势、拖曳、绘画等),就会使得机器越难理解这门语言。(所以直观性的需求体现为DSL——领域专属语言)

直观反馈的界面,对于内容的细节控制能力上的成本会非常非常高。所以,极其直观的产品更多会是消费型产品,而不是生产型产品。因为生产型产品属于少量的、更新周期长的、而且刚性的需求。

专业性上也会有所缺失。直观反馈使得开发目标从“最终目标”转向了“用户体验”,或者说他们的最终目标就是用户体验。这使得用户有愉悦的体验,但产品更新却无法跟上进度,甚至会变得越来越举步维艰。

而相反参照UNIX世界,那是个纯文本的世界,所有的输入输出都是纯粹的、各种各样的、带格式的不带格式的文本,这种界面及编辑的一致性使得大家真能更把注意力集中在目标上,而不是用户体验上。

初次的用户体验当然差了,因为有学习的过程,而且总会需要不断地翻阅文档(因为不直观)。但是,当这些行为成为习惯时,你就能享用这个世界的多样性。因为在这上面搭建东西实在太容易了。

欢迎来到不直观的世界。欢迎来到文本的世界。

Posted by & filed under 读书.

首先我觉得这书名翻译不是很恰当,英文 Business Model 被译为了商业模式,而对于我来说, Model, Instance, Pattern这三个词有着很明确的不同、但有着密切的关系。商业模式的话,应该是Business Pattern才对,却明显与原书意图不一样。这书说更多是“商业模型”的内容,是关于如何建模的书。当然,这很可能是为营销与推广作的修正,而现在“商业模式”一词的确被滥用了,他们可能也没别的选择。

而这本书的最核心之处,就在于那张画布。他把商业运作抽象出九个核心要素,然后摆在了一张画布上。从此,这些要素占山为王、划地为牢,有了明确的界线、也更易于进行分析。不管这张画布定义得怎样,一个模型画布化、框架化的思路是很值得赞赏的(像超整理术中说的),因为这样易于整理、易于寻找、易于讨论、易于移植与修订。在画布的基础上贴标签,更是让办公室白板法变得丰满起来。

从每一个要素作为出发点,能衍生出近乎无穷无尽的实例(Instance)、而且这些实例状态的变化也能在画布中反馈出来。九个要素已经几乎是人能掌握的一个模型复杂度上的极限(7正负2个),从这点上看,这块画布是为了分析与演化的多样性而设计的。现在的商业世界节奏如此之快,我只能说这既是好事也是坏事,因为这有点过于灵活,以致有些复杂。当然,这可能也是他们的目的之一,所以他们可以把这个分析过程拿出来售卖,让他们的咨询与解决方案服务蒸蒸日上。

里面也提到了挺多的具体的技巧、工具与方法。白板法、讲故事、原型制作等等。只是感觉这些方法说得会有些偏离他的画布本身。

总体来说,这还是本很值得读的书,但需要细心地去吸收与思考其中的内容。