Author Archives: rightgenius

我们为什么换社交网路

突然意识到,这是换圈子的过程。

在成长的过程中,朋友圈子在不断的更换。但社交网络中,曾经的朋友仍然会一直是朋友,即使很久不再联络。但人们总是需要跟更亲密的当下的朋友有更多的交流,切换社交网络能够一定程度上满足这一点。

换圈子是一段时期就会发生的一件事。因此,微信之后,仍然会有机会留给后来的社交网络。

同时,我们仍然放不下老朋友,因此在各个社交网络间疲于奔命。

而又有那么一些朋友,无论换到哪个社交网络,彼此还是能看到对方的新鲜事。

Mac,Linux,Windows手感对比

本科时候专业课基本用windows和visual studio做的,当时vs的臃肿和必须使用盗版让我对微软毫无好感,然后拥抱了开源世界,用了两年ubuntu linux,直到今年买了Mac。突发奇想做下对比。

常用软件兼容性

Mac:Chrome, Office, QQ, 迅雷,搜狗输入法
Linux: Chrome, 永中Office,Web QQ,浏览器自带下载,fcitx
Windows: 常用软件其实就是指Windows上能用的软件

所以,到今天日常工作上,三个系统基本都能正常使用。体验上Windows最好,Mac次之。

命令行工具

Mac: 自带unix shell,用包管理器homebrew可以安装缺少的linux上常用的工具,也可以装其他shell
Linux: 喜欢命令行的程序员的天堂。用起来十分舒服。
Windows: 用Cygwin可以勉强找到shell的感觉,美中不足是有的时候某些脚本依赖某个shell命令,万一在cygwin中没装,跑步起来还找不着原因

在命令行工具上,三个平台也都做到了可用。体验上linux最好,Mac次之。

软件安装和升级

Windows: 在网上下安装包,然后双击安装。常用软件一般自动升级。不常用软件需要重新安装来升级。
Linux: 用命令行的包管理器搞定一切。一行命令就可以安装chrome,感觉棒极了!升级所有软件只需要一行命令。大部分软件还可以下载源码编译安装,此时升级需要下载新版本源码重新安装。
Mac:图形界面软件,基本下载程序/安装程序安装。命令行软件,通过包管理器,比较弱。还支持从Apple Store安装,但国内大环境下基本没用过。

Linux的一行命令安装/升级已经把体验做到了极致。Mac各种安装方式杂糅。Windows最苦力,啥都要自己下。当然第三方360软件管家什么的可以弥补,但是这些流氓吵来吵去,一不小心qq、搜狗就不能用了。

图形界面

Windows:从win7到win8有个飞跃,以至于让升级系统最快的中国人(因为不要钱)都不升级了。用户最熟悉的,没有办法订制的,看起来凑活的图形界面。但依赖于其的众多图形界面软件(小白请直接理解为常用软件)使其功能最强大。
Linux: 高度可定制化,想怎么改就怎么改的图形界面。但稳定性较差,一不小心碰到G点就坏了。图形界面系统分裂出太多版本,以至于极难制作图形界面软件,以至于整体体验较差。但可以自定义的炫酷拽。
Mac:精致、漂亮的图形界面。用户不能订制,也不想订制,默认的足够好了。基于Mac的图形界面软件的常用软件也渐渐增多。很多开发者工具的图形界面版本都只有Mac的。

Mac作为图形界面的鼻祖,堪称典范。Windows靠兼容的软件功能最强。Linux满足屌丝程序员当神的欲望。

系统稳定性

Windows:蓝屏的,好喝的。不过现在蓝屏情况已经大大减少,但仍然存在。
Linux: 十分稳定,不会挂掉。但是图形界面经常挂。
Mac: 系统挂掉是什么,好吃吗?

三个平台都挺稳定了。

系统安装

Windows: 网络上有出奇多的教程、安装方法,小白用户级别,驱动兼容性最好。
Linux: 发行版的安装都做的十分容易,适合在已有windows的机器上做双系统。驱动不全,有可能装上用不了或者出问题。
Mac:你花上两天时间,看了无数教程,终于在PC上装上了Mac,发现居然跑起来了!接着10秒钟之后CPU因为风扇不转过热挂掉了。

作为程序员

曾经我很排斥windows,觉得开源世界才是程序员的归属。回过头来发现,其实只要在系统上弄好工具链,啥系统都一样。渐渐也没有了偏见。三个系统各有各的长处,各有各的不足,总有用的不爽的地方,总有用的顺手的一天。

通过历史预测未来

根据历史预测未来似乎就是彻底不靠谱的事,我之前也是这么认为,直到最近膝盖中了一箭。好吧,其实是看到《失控》最后几章让我对这个问题重新思考了一下。

股票涨跌

金融机构、投资个人都希望对股票的涨跌做出预测,什么K线图分析,眼花缭乱的理论,都是从历史数据来对未来做出判断,但效果好像都不是那么的好。于是,就有价值投资理论云云,要从股票的实际价值出发,历史数据就是不靠谱的,要看实际价值。

物理定律

无论是牛顿力学还是相对论,都在干一件事:预测未来。物理最早就是在研究天体的运动,第谷、托勒密以及我想不起来名字的种种都在通过记录、观察行星运行的数据,从其中总结出经典的力学定律。至少现在的建筑、机械都离不开力学,汽车、飞机简直把物理学发挥到极致了。

后来爱因斯坦提出了相对论,物理定律做出了修正,预测的更精确了。这是成功的根据历史预测未来啊有木有。

踢球的贝克汉姆

虽然物理学让我们造出了汽车、飞机,但是,日常生活中很多事,其实并不需要物理公式的介入。例如贝克汉姆也许会在赛后没事计算一下自己踢球的弧线公式,但在场上开任意球的时候,他的脑袋里一定不是在算公式。

人类通过不断的trial-error,大脑会对碰到的模式进行总结、固化,形成肌肉记忆。这与更高级抽象的物理公式是完全不同的approach。踢球的大脑通过多次重复形成的记忆,以及对当时场上的情况作出了预判,判断出该使用怎样的力量、角度、击球点,来指导黄金右脚踢出漂亮的弧线。这里并不需要高层的抽象建模。

人类天生就会预测未来!不然我们怎么生活的啊!

马饲料和石油

曾经有人担心马饲料不够,因为按照当时马匹的增长速度,以及饲料的种植程度来看,很快马饲料就会不够用。然后,人们发明了汽车,马儿再也不用担心饿死了,但估计要担心直接被处理掉= =b。现在很多人担心石油会枯竭,有各种各样的预测数据。但会不会也是马饲料呢?长期预测,总是不那么靠谱的原因是,突然、巨大的变化总会存在,虽然一定时间内,是渐变的。

如果仅仅根据数据,预测下个月饲料价格,我倒觉得是十分靠谱的。

短期预测和长期预测

《失控》中对历史预测未来的结论,是长期预测不靠谱,而短期预测恰恰相反,是很靠谱的。我完全可以说下一秒我的电脑还是好的,但是10年后我就不敢说了。因此华尔街会雇佣预测公司,短期预测股票的涨跌。

不过想了这么多,还是不敢去投资股票。

从需求到网站:(六)大杀器之CMS

这篇文章欠了好久= =b。前面我们讨论了如何从0到1建立一个网站。这里要讨论的是,从1到1建立一个网站。从1到1,对的,网站已经给你做好了!这才是大杀器!

内容管理系统(CMS)

Content Management System,就是字面意思,管理内容的网站系统。那举个栗子呢?例如新浪网就是一个CMS。新浪编辑们把文章(内容)通过管理员界面添加之后,广大用户就可以看到了,好了,就这么多,就是CMS。是不是很简单,so easy。仔细一想,诶,那所有的网站不都是CMS吗?博客肯定是,博主在管理员界面写好文章,然后大家看。电商也差不多,京东的编辑在管理员界面把商品添加进去,大家在网站上看、购买。

说白了,Web2.0的网站都是CMS,都是管理内容嘛,只是具体内容上有不同嘛。新浪管理新闻,微博管理微博,论坛是管理帖子,博客管理博客,电商管理商品。哇靠,互联网也就这么点东西!内容换个词就是信息,这些其实都是信息系统(Information System),这下知道为啥从前都是叫搞IT(Information Technology)了吧。

突然发现互联网搞来搞去也就是CMS,so sad。

不懂代码的建站

我要做网站,别扯CMS这些没用的!

好了,既然大家都是CMS,Web 2.0都几十年了,这些概念都是陈芝麻烂谷子了,也就是说,前任这些网站的代码都写过了呀,我为毛还要再写一遍呢?为了提升我的逼格嘛?没错,就是不需要写了。

订阅我博客肯定知道我的一篇著名博文《搭建个人博客的通用步骤》。咳咳,说著名是因为你看本博客右边→ →的点击量排名。如果你成功按照这个教程建立了自己的博客,请问你在这过程中写了一行代码吗?你需要懂php吗?你需要懂数据库吗?No, so nice.

WordPress就是一个非常完善的开源免费的CMS系统。前面我们提到过框架的概念,就是把一些轮子给你造好了,减轻程序员的工作量,程序员只用写少量代码就可以完成很多事。而CMS建站系统则把这事干绝了,直接让程序员下班了。只要根据教程,不懂代码的人可以很快建立一个网站,程序员你就失业去吧。

后台与后台与后台

在提到CMS的同时,就不得不提一个令我十分恶心的概念,那就是后台。后台直译英文应该是back end。我们在前文提到的后台就是这个意思,就是网站的服务器端,区别于浏览器端(前台front end)。程序员的世界里,大部分时候,后台都是指服务器端,一般是指后台程序,运行在服务器上的代码。

但是CMS的后台,在中文的神奇语义里,又变成管理员界面(Dashboard/Admin Page)的含义。当你搭建一个wordpress网站的时候,编写博客的界面就是所谓的“后台”。经常有人问我,这个网站要改个xxx能不能改,我说要改后台代码,然后他说后台好像没地方改代码呀?呵呵。然后就没有然后了。

(此段可忽略)不过在程序员的世界里,后端(back end)的概念也会随着语境而变化。当服务器端部署的十分复杂,前面有反向代理服务器,后面有网页服务器、业务逻辑服务器、数据服务器等等的时候,前端(front end)又会变成反向代理服务器,有时又是网页服务器,相应的,业务逻辑、数据处理就会变成后端。

国内著名开源CMS

好了,说了半天,你说不用写代码就建站,但也只说了一个博客网站呀,我要建论坛,搞电商,做团购,咋搞?这些还真都有!

论坛-Discuz!http://www.discuz.net/

老牌论坛建站系统,你只要平时经常逛论坛,基本都是用Discuz做的。后来被腾讯收购了。对是收购,不是腾讯自己做一个山寨的。

电商-ECShop http://www.ecshop.com/

似乎成了创业必备,要么淘宝天猫,要么就自己捣鼓一个这个了。

团购-最土 http://www.zuitu.com/

说实话这是google出来的。当年团购红遍天下的时候,遍地都是开源团购系统,才可能出现全国各地都有大大小小的团购网站。csdn有个集锦:五个免费开源团购建站平台

个性化和建站服务

看起来这些现成的造好的汽车是不是觉得世界一片光明美好!但回头想想这样用别人的CMS直接搭的网站还是不靠谱,我要改个背景颜色,换个LOGO,这咋搞?大的CMS都会有自己的皮肤系统,wordpress这一点就很好,有成千上万的皮肤供你选择嘿~慢慢挑吧。

不行不行,那些皮肤我都看不上眼,我的网站如此之高大上,怎么可以跟别人一样?这时,程序员总算又有饭吃啦!就是改网站界面!可是程序员的审美……唔,所以还是一个设计师搭配一个程序员比较好。于是,一个外包团队就成型啦!一个大专设计师+一个蓝翔CSS程序员,从政府到企业,建站这种事,so easy。

外包团队一般来说仅仅帮你把网站做出来,不负责网站的部署。当然也可以负责部署,这种其实就是换个说法,可以称为建站服务了。去域名注册网站、主机提供商网站上看,都会提供建站服务,一条龙,只要你有钱,做网站不是梦~

程序员的价值

既然开源CMS已经如此牛逼了,为毛互联网公司还要程序员呢?程序员的价值存在于下面几点(个人观点):

大流量

免费的代码虽好,但是任何网站一旦做大,都不可避免存在负载问题。京东之前一做活动就崩溃,后来找来个架构师,重新用Java做了一套,最近才没有出什么问题。如何让网站不轻易宕机?如何保证升级网站的时候用户还可以访问?特殊问题,只能通过程序员的努力来解决。

新业务

卖东西嘛,平时松松返券,打打折,搞个买一送一是很经常的事。可是开源电商系统没有办法为你的特殊活动专门做一些页面、功能。这时候就是程序员的活了。

应对变化

其实上面两条,说白了就是应对变化,需求在变,业务在变,技术在变,时代在变,只有活的程序员才能真正应对这些变化,死的系统做的再好,也会渐渐跟不上时代。所以想认真做互联网创业的人,一开始可以不养技术团队,通过外包等等来搞定,想要真正做大,技术团队是必不可少的。业务牛逼之后,技术也不能掣肘。

从需求到网站——上线啦!

订阅我博客的人应该都看过前面的几篇教程了吧~~~

历时两个多月,中间断断续续开发,统计了一下,自己写的代码大约是1500行。当然包括库以及最终部署所需的代码就不止了~

最终,当当当!

requirement-card.com 上线啦!直接可用哦~

具体用法就不在这里说啦,支持图片、富文本、多人协作,等待你去发现哦~

实在不知道怎么用也可以在网站右下角点帮助啦。

各位晚安~

从需求到网站:(五)前端代码

接前一篇:从需求到网站:(四)技术架构

架构师把网站的架构定下来之后,码农们就开始编码啦!当然,传统的软件工程流程要先做概要设计和详细设计,也就是撰写设计文档。文档是个让程序员又爱又恨的东西。当维护别人代码的时候,巴不得文档越多越好;自己写程序的时候,巴不得不写文档直接编码。必要的设计文档还是很有好处的,特别是当团队成员比较多的时候。

既然是网站,不可避免的需要编写HTML、CSS和Javascript代码,这些代码称为前端代码。

HTML和CSS

这是一对网页好基友,所有的网页都必须通过这两种语言来呈现。HTML负责表达,需要呈现哪些内容。例如:

<a href='www.nius.me‘>Nius' Avalon</a>

上面这段html的A标签(Anchor)就代表一个网页链接,这个链接指向我的博客地址。但是,用户显然不希望看到这样一段代码。于是浏览器就会把这段代码画出来,如果没有对这个A标签定义样式,浏览器会默认给这个A标签一些基本的样式,例如文字颜色是黑色,背景是白色等等。如果想要自己定义样式,就要写CSS代码。

a{
     color: red;
 }

上面这段代码的含义就是,页面上所有A链接,文字的颜色都是红色。如果看到此,对写网页产生了极大的兴趣,欢迎查阅W3C提供的网页编写教程:w3school

那么,需求传奇项目的html和css回是怎样的呢!大家可以查看下面Demo,以及里面的源码。

[iframe http://jsfiddle.net/nius/NV4ET/embedded/result,html,css,js/ 100% 300px]

咦!好像确实跟之前的设计图(传送门)差不多,但是还是不对劲啊!那些{{}}是神马玩意!

这就是传说中的前端模板。估计上一篇文章信息量太大,不好理解,这下大家应该明白模板是啥了。就是填空题嘛,先把要填的空占着。

Javascript

好了,既然html和css,一个掌管显示神马,一个掌管怎么显示,还要js做什么?Js的作用就是,让网页”动起来”,例如本文下方的评论框,点击不同的标签页,显示不同的内容。这个HTML和CSS都不管,只好Js来管了。Js有两个超级牛逼的能力:

在浏览器里操纵html代码

在浏览器里意味着,代码运行在用户的机器上,而不是服务器上。操纵html代码,意味着可以动态的更改显示的内容。同时,html标签里的class和id属性,更改后可以调整html的样式,也就是简介控制CSS。再次,html标签里有一个style属性,可以在里面输入css代码,起到和css同样的效果,即直接控制css。真可谓,挟html以令网页!

向后台发送请求,并接受返回

这个是什么意思呢?看了上一篇文章,大家知道,从url地址打开一个网页,就是向后台发送请求,返回了html文件,以及css文件、js文件等等。当网页打开了之后,不打开新链接,理论上是不会有新的请求的。但是js就可以做到,在当前url地址下,向后台发送请求,并接受返回的值!好吧,这个就是AJAX。

在上一篇文章网站架构中,我提到,后台模板和前端模板两种架构。如果使用后者,那么Js在这里的作用就是要请求后台数据,然后更新当前网页。注意,url地址栏里没有变化哦~(当然js也可以控制url地址栏变化,暂不详述)。

于是,我们的需求传奇的页面就出来啦!

[iframe http://jsfiddle.net/nius/NV4ET/3/embedded/result,html,css,js/ 100% 300px]

前端框架

好了,大家如果有兴趣,可以详细看一下上面Demo的html和Js源码。这里,我使用了一个Js的前端框架:Angularjs。上篇博客发布后,有人问我框架是什么意思,这里解释下。

框架就是说,很多代码,已经有其他的程序员帮助你写好了,你只需要把他的代码拿过来,然后按照他代码里定义的接口和约定,编写少量的代码,就可以完成很复杂的功能。

上面Demo里的Js代码,大家可以看到,只有20多行,这20多行就是按照一定约定来写的,就是说框架说,应该这样写,我就这样写。当然我会在其中添加具体的业务逻辑。同时,html源码里,有np-app,np-model这种不属于html的东东,也是框架要求我这样写的。我按照框架的要求写出代码后,程序就会按照预期来执行。

于是,我就通过20来行的js代码,以及对html的少量改动,就完成了将需求卡片复制10次显示在页面上,每个需求卡片标题不同、优先级(就是颜色)不同的操作。很省事有木有!这就是框架的力量!节省代码!

前端这两年发展迅猛,框架层出不穷,已经选不过来了。不光有Js的框架,还有css的框架。例如上面的css,就是通过compass/scss框架来生成的。

最后,如果你对js也十分感兴趣,仍然推荐W3C的教程:w3school

============ 本文是一个系列,其他已经写好的文章:

从需求到网站:(四)技术架构

接前一篇:从需求到网站:(三)视觉设计

唔,耽误了一阵子,接着写~总算写到程序员可以发挥力量的地方了。不过写的太技术了,就无聊了。尝试写的好玩一点。

上古时代 1.0

上古时代做网站,这要数到上个世纪8、90年代。网站一开始的时候,仅仅是呈现一个文件,这个文件叫html。比如你在你的机器上打开一个word文档,看看写了些啥,那时候的网站就是这样的。只不过,这个html文档不是在你的电脑里,而是在别人的电脑里。例如我放置了一个叫做hello.html的文件在我的电脑上,然后我在我的电脑上安装一个叫Web服务器的软件,以及给我的电脑起个名字(域名)。这样,你就可以用浏览器通过http://www.xxx.com/hello.html 的方式来访问这个文件了。

为什么说这是上古时代呢?因为这个时候,仅仅是一个“静态”的文件。所谓静态,就是说,这个文件谁看起来都一样,我在实验室访问,你在家访问,他在寝室访问,这个文件都是这个样子的。静态文件直观上有两点缺陷: 1. 不能区分不同的用户,例如,如果这个页面内容要写hello, nius,所有人看到的这个文件都是hello, nius。显然,你不一定叫nius这个名字。 2. 网页难以维护。上新浪、淘宝,你会发现页面中很多地方都是一样的。但是,不同的页面,还是不同的文件呀。当我发布一个新的html文件的时候,我得把老的html文件拷贝一份,然后把不一样的地方换掉。例如我写这篇博客文章,其实只有标题、内容等几个地方不同,其他内容我就不希望管了。静态网页是做不到这点的。

这里有一个Web服务器的概念,服务器即可以指那台电脑硬件,也可以指软件。服务器其实和家用电脑没有太多不同,早期的服务器其实就是一台连着网线的家用电脑,上面安装了一个叫Web服务器的软件,一旦电脑关机了,网站就上不去了。直到现在你也可以这么干。当然,国内环境复杂,想这么干有接入网方式、行政因素来阻碍你。

暴发时代 2.0 后台模板架构

大家肯定觉得1.0的网站太无聊了,我连登录都登录不了。于是程序员们纷纷表示,放开html,让我来!于是各种语言开始实现web后台。例如PHP。PHP是专门为了写网页设计的程序语言。php能够在用户请求某个文件时(例如仍然是之前的html文件,但是后缀名改为php),把这个html文件中的一些内容替换掉。这样,页面中的广告就可以只在guanggao.php里写一次,当我请求一个index.php时候,直接把guanggao.php中的内容替换到相应的位置(相当于做了一个复制粘贴)。

这就是网页后台模板的概念。所谓模板嘛,就是可以动态的把其中的内容替换掉。

但这个时候,还是不能登录,因为用户名没法记录在php文件里呀。这时候,数据库就出现了。免费的数据库比较流行的是mysql。所谓的数据库,就是把你的用户名和密码存进去,这样,当你登录的时候,我比对一下密码对不对,对了,我就让你登录,在网页上显示 hello {你的名字}。

当然数据库能做的还有很多,例如这篇博客的标题、内容、标签,都存在数据库里。当你请求这篇博客的地址: http://nius.me/from-requirements-to-website-4/ 时,php语言判断出你请求的是哪一篇博客,再从数据库中取出博客的内容、标题等,拼装出一个html页面,返回给浏览器。这样,浏览器就可以显示html内容了。

很多人都听说过LAMP,也有很多培训班专门用来培训LAMP开发的,LAMP= linux + apache + mysql + php,linux是免费的操作系统,跟windows的角色类似,就是让电脑跑起来。由于免费、开源,定制性、稳定性极强,所以服务器市场上占了很大的份额。apache是之前提到的传说中的Web服务器,提供HTTP协议的实现。mysql是数据库,记录诸如用户信息、博客内容等。php则是动态语言,相当于把Web服务器和数据库连起来,从而实现动态网页。

但是,PHP并不是唯一的动态语言。Java也是很流行的后台语言。Java推出了J2EE等一些列方便程序员开发网页的类库,以及很多开源社区的框架,如著名的Struts+Sprint+Hibernate。这里要说一下框架是什么,框架就是避免程序员重复劳动的东西,因为web开发可以被抽象成MVC模式,所以可以根据这种抽象来把很多东西规范好,程序员只需要进行很少的开发,就能够完成很多内容。

除去PHP和Java,前几年流行Ruby、Python,这两年流行Node.js,都是相对成熟的可以用来开发Web的语言。但只要你把握住根本,其实Web后台开发就做了一件把数据变成html的事,就不难学会这些后台语言,至少很容易学会如何使用这些语言的Web框架。

来,一图抵千言。

后台模板架构

后现代派 2.1 前端模板架构

2005年左右,流行起一种Web开发方式成为AJAX。背后的概念比这个名词简单多了。上面说的,仍然是一个网页请求到后台,后台返回一个完整的网页。这样做的问题是,如果网速慢,网页又大,用户体验很不好。于是,可不可以就把网页变化的部分传过来呢?例如你正在看这篇博客,想看上一篇从需求到网站:(三)视觉设计,点击链接之后,仅仅刷新博客内容,其他东西都不用变,这样,网络传输的内容减少了,网站的响应速度提高了。

这个技术之前充其量是上面提到的后台模板架构的补充。直到他的膝盖中了一箭。

既然可以局部刷新网页,那为什么不干脆整个网站就一个页面,所有内容都进行局部的获取呢?Web先驱们早就想这么干了!Google的Gmail就是这样的,Gmail成功的使用制作网页的技术,做了一个能跟客户端程序媲美的Web应用程序。但是在Google做Gmail的时候,进行这种开发还是十分困难的,因为浏览器不够先进。现有的东西不够好,怎么办?程序员的思路当然是:自己做一个!于是Google就自己做了一个浏览器Chrome,一炮打响。

这里提到浏览器不够好,为什么浏览器不够好呢?这就涉及到Javascript和Html的问题。大量使用AJAX的网站,虽然减少了网络传输的带宽,但另外一件事必须得考虑,就是html文件不光在后台拼接了,还需要在浏览器里进行拼接。浏览器要把之前后台语言干的事接盘,自己来干。程序员把一种用Javascript这种语言写的代码,传输到浏览器里,让浏览器来对拼装html。这时浏览器就蛋疼了。本来我只要显示一下html就行了,这下倒好,我还得自己把html组装好,再来显示。特别是老旧的IE,性能跟不上啊,显示一个网页就把电脑给卡死了。不过新的IE9、10性能倒是蛮好的,微软还是挺厉害的。

在浏览器性能跟上之后,Web架构就可以放弃掉后台模板这种东西。Twitter就这么干了,做成了Single Page Application。就一个网页,网页内容全部通过Javascript根据后台传输的数据来生成。这样的好处是,网页显示extremely fast。但这带来的挑战是,前端Js的代码量大量增加,甚至赶上后台代码了。这下大家傻眼了,从前写网页前端没什么js代码,顶多几百行,基本想怎么写就怎写,这下要维护一不小心上万行的代码,怎搞?必须模块化,但是Js原生对模块化开发的支持并不好。于是开始有各种模块化标准和解决方案。

与此同时,前端的业务逻辑也十分复杂,模板这件事(就是动态的拼装html),也从后台转移到了前端,于是,前端开始出现了很多框架。还记得框架嘛?就是让程序员用很少的代码干更多事的东西。多到……上百种( ⊙ o ⊙ )!谈到Java,我们说SSH,谈到Ruby我们说Rails,谈到Python,我们说Django,谈到Javascript……简直太混乱啦!Backbone算是比较火的,但替代品一抓一大把,没有人敢说哪种最好。所以现在开发这种网站很头疼,选框架就让你选半天。

既然业务逻辑、模板都被前端做了,后台做什么呢?后台就只需要做数据持久化就行了。也就是说,后台其实就把前端传回的数据保存下来,当前端请求的时候返回过去,就OK啦。好幸福!后台人员再也不用学html了。返回的数据用JSON格式,你可以理解为key-value,就是什么键的值是什么,例如用户名-小明,就是一组key-value。如图~

前端模板架构

艾玛,还没讲CSS呢

Html是告诉浏览器,要显示哪些内容,而CSS则是告诉浏览器,显示哪些内容。例如,标题应该比正文大,段落之间应该空多少距离。CSS和Javascript在网站中都属于静态文件,还记得上文Web 1.0时代,静态html嘛?自从到Web 2.0,html就已经不是静态的了,是后台语言动态生产的,所以静态文件一般指Js、css、图片等等。你会发现,到最后,html文件没了,因为藏到前端模板(Js)里面去了。

之前就被骂写的太多了,感觉这篇文章又说多了。。。⊙﹏⊙b汗 各位海涵。

============ 本文是一个系列,其他已经写好的文章:

从需求到网站:(三)视觉设计

接前一篇:从需求到网站:(二)产品和原型

从前这个活叫美工,现在还是很多人这么称呼。很多人从骨子里就没把设计当回事,很多淘宝店主招了几个自学PS的“美工”就开始淘宝生涯了。所以淘宝的UED真心很不容易,天天看那些商品详情页面做的乱七八糟,自己也无力回天,只能尽量从自己可以控制的地方加以控制。

会PS跟会设计完全没关系,我认识的一个非常厉害的设计师就不用PS,直接用AI(Adobe Illustrator)。设计工具仅仅是工具,如果没有审美的天赋,又不学习着去遵循设计的原则,那只能做出来自我感觉良好的页面,用户一用就觉得没质感。

视觉设计大约有下面几个方面。

排版布局 (layout)

就是说文字和图片应该放哪,放多大,行距多大,段落间距多大。比如本文,被转载到人人上和qq空间里,就丑爆了,标题完全和正文没区分开。通过文末的链接点回我的博客网站,就看起来舒服多了(这不是骗PV啊喂!)。好友biaobiaoqi最近在博客里解说了一本设计书里提到的原则,对想了解设计的人还是很有用的,可以一看。

排版布局是看起来简单,但十分难做的一件事。很多人不屑一顾,校园内的很多海报就是因为layout太差而实在太丑,重点不突出,让读者不能简单明了的看清楚所呈递的信息。例子也一时不好举,凡是你一眼没看明白干嘛,看第二眼第三眼还没明白,只有集中精神去找上面的看不清的字(不一定是小字哦)的海报,基本就失败了。

在字节社买过电子书之后,就觉得,在手机/平板上看电子书原来也可以这么享受。再看其他的电子书软件,好容易买本书,跟网上下一txt没啥区别,排版就是一坨shit,标题跟正文就一个字号,连个加粗都没有,真是气不打一处来,买你何用!我才不付费呢。搞互联网的人以为把一行行的字放到屏幕上显示就叫电子书了。实体书的装帧、排版、精致的印刷你懂么?

配色(color scheme)

这玩意也是说起来容易做起来难。你说自然界那么多种颜色,要选出几种搭配起来看着顺眼的,多不容易啊。还好有很多傻瓜式的配色理论来帮助我们。比如在色轮上按一定规则选颜色。这有一系列文章介绍颜色,写的挺实用:color theory。还有色彩设计的原理这本书,也挺不错。顺便,他家的版面设计的原理也挺不错,讲layout。

字体 (typeface)

字体这玩意水也很深。这两年中文字体设计也渐渐重现光彩。英文字体理论、实践都相当完备,横扫天下的是Helvetica。也许你没听过这个名字,但是你觉得见过。这个字体牛逼到有一部纪录片专门讲这个字体的前世今生。

字体的复杂不光在字体本身,在web上,你还关注另一个问题:字体渲染。就是说字体设计成那样的了,但是操作系统跟浏览器怎么画这个字又是另外一回事了,windows在此事上又一次充当了被骂的角色(IE6这种就不提了,好歹也是开创一个时代的浏览器)。欢迎关注知乎的字体话题。

能用在web上的中文字体有限,原因有两个:一个是大家机器上都装了的字体不多;另一个是,如果打开网页的时候后台下载一个,中文字体数量多文件又太大。所以,一般就宋体/黑体/微软雅黑有限的几种选择。当然,网页中的字体是可以设置fallback的,就是前一种字体没有,自动使用后一种。想要各个操作系统下都好看,可以参考知乎的字体设置。

这样说来,其实我对设计也不是很懂,凯凯而谈没啥用啊。因为程序员最爱的还是命令行了。

而需求神话的视觉设计也出炉了!其实没画完了,折腾了一下午加一晚上,还是觉得丑。还是交给老婆大人吧。。。半成品先发出来,表示这是视觉稿alpha1。

update:妹子大人万岁!比我画的好看多啦!

============ 本文是一个系列,其他已经写好的文章:

从需求到网站:(二)产品和原型

接上文:从需求到网站:(一)需求

现在有了原始需求,接下来,我们就要设计产品了。如果你看到现在,还对“产品”的含义不是很理解,可以参考我之前写的一篇文章:什么是互联网公司的产品经理?

产品人员的产出物

设计产品一般产出物就是需求文档和原型。啊嘞?需求不是上一节讲过了么?那是原始需求。梳理完原始需求,接下来要设计产品,一般会画出产品原型,交给交互设计/视觉设计;以及需求文档交给程序员。

需求文档确实力求忠于需求,但同时,产品人员在撰写需求文档时,已经在心中勾勒出产品的摸样。需求文档中有时会涉及到流程图,其实已经开始对解决方案建模,最终,流程会体现在原型设计中。

与此同时,需求文档和原型也需要最终跟需求方确认,毕竟谁提出来要做的是吧,万一有偏差。如果是消费级产品,需求方是大众,这种确认就得找用户研究团队来做了。创业公司才不管呢,哪有时间做用研,完全看产品人员的自身素质。

需求文档

说了半天需求文档,需求文档里面写些啥?其实就是把用户出现什么问题,要怎么做解释清楚。几个W嘛是吧,干什么职业都得围着What/Who/When等等这些东西转。

需求神话这个产品的一个需求用例可以描述如下:

当用户想修改某一个需求用例的优先级时,通过界面上的控件选择优先级,分为1、2、3、4、5个优先级,优先级修改完毕后,该需求的显示状态发生变化,提醒用户修改已经成功。

这一段描述很抽象,没有指明特定的交互。书里面大约会强调,需求文档就描述需求就好了,不要跟交互扯上关系,不要有“按钮”这种词汇。这种思路大约是不想限制交互人员的发挥。与此同时,后台开发人员其实不需要知道交互上发生了什么,这段需求只要体现出修改了需求用例的状态变化就行了,因此需求文档的任务也就完成了。

当用户想修改某一个需求用例的优先级时,通过界面上的笑脸和哭脸按钮选择优先级。笑脸有三种含义:功能完成后用户非常高兴/用户感觉开心/用户觉得无所谓;哭脸有三种含义:功能不完成用户极度失望/有点失望/无所谓。每种含义依次代表0、1、2,通过两个按钮状态的搭配,可以加和出0、1、2、3、4五种优先级。例如感觉开心+有点失望 = 1 + 1 = 2,即该需求优先级为2。点选后,根据优先级的不同,需求卡片的背景颜色变成对应的颜色。

这是一段包含了交互的用例描述。不过这个例子跟上面的例子对比可能有点不恰当,因为通过两个按钮来组合出优先级这个需求,实际上是对优先级重新定义了。所以,上面两个例子不是描述的相同的需求。(我真失败啊= =b)

这两种需求描述都可以。如果你一定找个标准文档,我只好说我从来没找到过╮(╯▽╰)╭。标准都是人定的。Get things done. 事实上,用例这个词就是一种需求描述形式(来自UML),还有用户故事(来自Scrum),那些搞软件工程的人到今天还在吵来吵去敏捷和传统软件工程哪个好的问题。想干活的,还是自己习惯咋样就咋样写吧。

额,你说不写需求文档?一个人自己玩玩小项目还可以,多人协作的、需要长期维护的项目你试试看。新来的程序员/产品问你为什么要有这个功能,你说这个我们当时做的,我也忘记了。于是从前大家开了两天会定下来的feature又开了两天会。╮(╯▽╰)╭

原型图

现在的产品人员必备技能就是画原型了。一说搞产品,必须Axure。文艺青年说我用Balsamiq Mockups。原型说白了就是界面草图。草稿纸上也可以画。除了画出样子,网站原型另一个任务就是要画出交互。Axure的好处是,可以快速的帮你把点击某个按钮或者链接之后的界面反馈、跳转等动作做出来。很牛逼,用鼠标就能搞定。很多人说我靠原型啊好难啊,其实优酷上搜个教学视频,2小时包教包会啊。

产品人员要画原型,交互设计师也要画原型,他们俩最后是要打架嘛!其实产品人员的原型的目的是展现出功能,交互设计师才是确定交互。普通交互设计师可能会讨厌产品画原型,尼玛限制我思路嘛。牛逼交互设计师可以做到完全不理会产品给的交互,一坨shit,我理解清楚需求就可以扔掉了。

创业公司,对不起,哪养得起交互设计师啊,用研都没人做呢。产品大兄弟就靠你了啊!

搭配本例子的原型一瞥:

enter image description here

嗯,我是文艺青年。

从需求到网站:(一)需求

做网站曾今是个被广大学院派程序员所看不起的事,html+css+php,完全没有技术含量嘛,就是个体力活。但现在不一样了,学生们都挤破头想进几个大的互联网公司,而创业也几乎和互联网创业画上了等号= =b。本系列教程力图给非程序员专业的童鞋们讲清楚如何从无到有做一个网站。

首先,就是需求。哎呀本来这个词是给产品经理们用来装逼的,结果现在街上随便找个老大爷都要教训你,做网站要抓住用户最根本的需求是什么。接下来,老大爷就会把他理解的“用户”给你讲一遍,然后说产品要怎么搞怎么搞。

用户的需求和我的需求

对于消费级产品,很多人会对打着“为用户说话”的幌子,把自己的想法借用户之口说出来。没错,就是你,别想别人了。基本上每个人都有这种情节,因为,“每个人都是自己生活的产品经理”。这句话是《人人都是产品经理》这本书作者对这个书名的最简单的解释。每个人平时自己给自己当产品经理当习惯了,所以很自然而然就会推广到对其他产品的看法上来。但自己的理解是否正确,就不好说了。

比如,你想做一个网站,你把你的idea跟周围的人刚一说完,马上就有人站起来说:“我还是建议,做任何东西,都要理解用户的最本质的需求,你看,就不会用这个网站,因为平时就用aaa,觉得aaa就好了。”,显的自己很专业,结果这句话其实毫无营养价值,连用户跟“我”都没分清楚。自古以来,提建议的人往往是站着说话不腰疼的,反正这个idea不是在做,我把我的想法说出来了,说对了,那是我有先见之明,以后聚会可以吹嘘吹嘘;说错了,大家反正以后就都忘了,而且本来说的就是糊涂话,“要抓住用户最本质的需求”这句话总该是没错的,大家都这么说嘛。

需求整理

但真正想做点事的人,或者产品经理,这个时候就得冷静下来,相信自己的思考。因为只有你是产品的最终设计者。

所以我常常很奇怪,很多人觉得产品经理是个很轻松的职位。产品经理要背负整个产品设计的责任,需求整理、产品设计过程中,很多人会不痛不痒的提很多自以为是建议,如何权衡取舍,如何找到用户痛点,完全是产品经理个人的素质在支撑,一旦产品出问题,那些曾今对产品提建议的人就会跑上来说:你看,我当初怎么说怎么说,要是按照我说的做会怎么样怎么样。程序员才不用管这些,按时写完代码就好了,压力仅仅来自于机器。

那如何把握需求呢?网上有一堆Guidelines,看完不会对你把握需求有很多帮助。这是个经验更重要的东西。这个经验并不是你当了多久产品经理,而是你对这个产品、行业有多深的经验。按照这种理解,一毕业就去当产品经理,似乎是一件不那么合适的事。但是公司对产品这个职位有需求,要调节运营和开发之间的矛盾,于是大公司们招了一堆应届生去做产品,当时我差点就成为了其中的一员。应届生做产品可不可以呢?肯定是可以的,就看经验的短板能够弥补的多快了。

当然,也有很多需求很精确的项目,例如企业级产品,面向特定用户的订制产品。这种项目一般需求不会错到哪去,产品经理的任务就是做精。例如很多ERP,除去功能需求外,如何减轻工作人员(用户)的工作量,是产品人员需要精心考虑的问题。

总之,产品人员需要梳理出原始需求,不一定是文档,其他能够表达清楚需求的东西就行了。这是一个网站的第一步。

教程搭配的例子

本教程搭配的例子产品,也就是一个在线的需求文档整理工具(网站)。我们给他起个名字好了,例如叫:需求神话?需求传奇?随意了。就需求神话吧。

需求神话网站的原始需求很简单,作为一个整天在学校里做政府无聊的web项目的程序员,用word写需求文档写的不开心,想做一个更好用的工具,帮助我整理需求。word不好看,我想要需求描述呈现的更舒服一点;word中优先级体现的不明显,我想要优先级更加明确。

这下没人跟我唧唧歪歪的说用户最本质的需求是什么了,你写过需求文档么。

=========
下一篇:从需求到网站:(二)产品和原型