web页面 分步完成一个逻辑 怎么设计

由于我们对传统美学职业的认识，web设计一直被强调为视觉上的表现手段，如果不计算技术的因素，web设计中重要的问题往往是如何组织和创建web站点的内容。而随着电子商务的流行，是否带来商业方面的成功也成为衡量web设计作用的标准。因为internet的特殊性，使得web设计不再是一个普通的从事应用美术的职业，它变成了跨学科，跨领域知识的综合体。为了实现更好的web设计，你大概需要掌握图书情报学，计算机图形学，程序设计，客户机/服务器技术，用户界面设计，人机互动关系，可用性研究，心理学，社会学等诸多方面的知识，并达到一定的水平。一个完整的web设计工作应该至少拥有以下主要的方面：内容是的，网站的本质在于信息的传播以及如何传播，问题集中在怎么样引导和劝说用户。由于web的特殊性，内容已经脱离我们传统的定义，它可以包括：文字，图形，超连接，交互 *** 作，动画，视频，音频，在线游戏甚至的混合型的组织形式。拥有高质量的内容是网站成功的关键。我们常常误解web设计为制造优秀的视觉体验，带给客户不同以往的美学感受。当然，这样做，可以吸引第一次访问的客户更加注意你的站点，但是一旦客户在某个地方停留下来后，他的所有活动将转变成寻找对他有用，或者他感兴趣的信息。如果一个站点空有一个漂亮的架子，而缺乏实际的内容，用户最终会离开。而设计在这里的作用是？对，如果一个优秀的内容，用户无法很快的找到它（或者并不明显），内容也失去了它的意义。因此，web设计的最基本原则是–通过有效的方法更好的组织和规划用户所能浏览到的信息。这样做的目的是获得用户的好感，并且使用户得到方便。例如，我们通常说的好的导航，应该是具有明确含义的连接名称，基于逻辑的按钮组合，优秀的充满质感的表现；好的页面应该有语意清晰的标题，一致的导航元素，降低视觉疲劳的颜色组合，清晰明朗的文字编排，懂得提示和警告的编辑技术等。设计师往往喜欢把自己放在高处，不过你要记住，用户来到你的站点，并不是来欣赏你的设计（会这么做的，只有那些和你一样的设计圈子内的朋友们，或者企图进入这一行业的新手）。当用户来到一个站点，通过导航系统和安排好的组织结构寻找内容，导航本身不过是路径。就算你的导航设计真的很巧妙，那并不重要，如果你花费在“包装”上的时间比“引导”上的精力的话，你获得的成效不会让你感到高兴。由于用户的差异性，设计师不可能设计出完美的导航，当用户进入一个陌生的站点，他们不知道该如何 *** 作这些繁杂的页面，找出他们需要的部分。这时用户并不希望浪费时间去学习掌握复杂的流程系统。他们对自己所在的位置，只有在自己无法找到合适的东西时才变得重要。只要你的页面导航能够帮助客户方便的找到自己需要的东西，这样的导航就是合适的。技术技术的完善与系统是保证合理功能的基础。Web是由纸张进化到internet的信息工具，其传播媒介已经发生了彻底的变化，因此要从internet的根本特性出发设计站点。好的站点应该具备强大的技术支持，一个拥有好的设计的站点，也同样要拥有好的运作。站点无论如何是不能崩溃的（天灾人祸也请尽量避免它们，不要再为你微薄的技术能力找借口，作为技术工程师的你，职责正在这里！），HTML的正确表现，图像的正确显示，其中参与交互的元素–客户端的javascript，服务端的CGI程序，一定要在客户不易察觉的情况下，体现良好的运作并帮助客户得到web的正常功能。“404：filenotfind”不会为你带来第二次的客户关注，错误的站点是不会被允许成功的。可能引起错误的原因大概是：技术的更新和改变，开发经验的欠缺，不考虑人力的时间进度安排，方法学的缺乏，未考虑到网络媒体的特殊限制。我们不难发现技术的更迭是相当迅速的，HTML，CSS，JAVA等都在以超乎你想象的速度发展。一个优秀的web设计师应该时常关注技术领域的变化，忽略技术和媒体特征的结果是你无法完成本该高质量完成的工作。Web设计师要保持在掌握浏览器更新，带宽变化，程序设计及协议等问题上的高度兴趣。外观在一个站点拥有好的功能和简单明了的导航系统，强大的技术支持后，我们发现它们未必能够成为用户青睐的目标。一个站点的外观是最先被注意到的，而这个特征几乎在任何设计类工作中体现出来。尽管我们知道，好的品位无法逼迫出来，几乎也不可能被预测。但我们知道，好的web设计与浏览它的用户的品位直接有关，第一眼印象是由在线的站点造成的。站点的外观会影响用户对站点的看法，外观好的站点会被主观的认为比外观差的站点好，至少第一眼是这样。

大家都知道互联网行业发展前景大，而IT行业中除了Java开发和软件测试这两个岗位外，UI设计和Web前端开发也是当前比较火爆的两大互联网岗位。
随着移动互联网的深入发展，目前市场对这两大专业人才的需求有增无减。而对于那些想要转行IT拿高薪，但又不愿意天天撸代码的人而言，做UI和做前端就成了一个比较合适的选择。
当然，对于很多小伙伴来说，UI设计和Web前端到底有什么区别，哪个更好学？哪一个发展前景又更好，大家都还是比较迷茫的。
UI设计
1、什么是UI设计？
UI设计（或称界面设计）是指对软件的人机交互、 *** 作逻辑、界面美观的整体设计。UI设计分为实体UI和虚拟UI，互联网常用的UI设计是虚拟UI，UI即UserInterface(用户界面)的简称。好的UI设计不仅是让软件变得有个性有品位，还要让软件的 *** 作变得舒适简单、自由，充分体现软件的定位和特点。比如：哪些常用功能放在什么位置用户用起来最顺手，所有会影响使用者体验的一切。如架构、互动、内容与及使用者对象、需求、价值观。
2、UI设计需要掌握的技能？
视觉设计主要是以美术设计为主，界面的色彩、结构、图标等工作都需要视觉设计师来完成。主要使用的软件是以Adobe公司的软件为主，如PS、AI、AE、FW等，一般来讲从业者都是美术专业相关院校的毕业生，也有少部分计算机专业毕业生。
交互设计主要是以产品交互原型设计为主，完成设计交互原型图，但这其实是一个很考验综合能力的职位，需要了解用户体验知识、界面设计知识、产品业务知识等。交互的设计软件比较多，每个都有自己的特点，比如AxureRP、Balsamiq Mockups、Omnigraffl Pro等，一般来讲都是需要一定的从业经验才能很好胜任。
web前端
1、什么是Web前端开发工程师？ 主要进行网站开发，优化，完善的工作。网页制作是Web 10时代的产物，那时网站的主要内容都是静态的，用户使用网站的行为也以浏览为主。
一位好的Web前端开发工程师在知识体系上既要有广度，又要有深度，所以很多大公司即使出高薪也很难招聘到理想的前端开发工程师。现在说的重点不在于讲解技术，而是更侧重于对技巧的讲解。技术非黑即白，只有对和错，而技巧则见仁见智。以前会Photoshop和Dreamweaver就可以制作网页，现在只掌握这些已经远远不够了。无论是开发难度上，还是开发方式上，现在的网页制作都更接近传统的网站后台开发，所以现在不再叫网页制作，而是叫Web前端开发。Web前端开发在产品开发环节中的作用变得越来越重要，而且需要专业的前端工程师才能做好，这方面的专业人才近两年来备受青睐。
2、Web前端工程师需要掌握的技能？
必须掌握基本的Web前端开发技术，其中包括：CSS、HTML、SEO、DOM、BOM、Ajax、JavaScript等，在掌握这些技术的同时，还要清楚地了解它们在不同浏览器上的兼容情况、渲染原理和存在的Bug。在一名合格的前端工程师的知识结构中，网站性能优化、SEO和服务器端的基础知识也是必须掌握的。
必须学会运用各种工具进行辅助开发。除了要掌握技术层面的知识，还要掌握理论层面的知识，包括代码的可维护性、组件的易用性、分层语义模板和浏览器分级支持，等等。可见，看似简单的网页制作，如果要做得更好、更专业，真的是不简单。这就是前端开发的特点，也是让很多人困惑的原因。如此繁杂的知识体系让新手学习起来无从下手，对于老手来说，也时常不知道下一步该学什么。
代码质量是前端开发中应该重点考虑的问题之一。例如，实现一个网站界面可能会有无数种方案，但有些方案的维护成本会比较高，有些方案会存在性能问题，而有些方案则更易于维护，而且性能也比较好。这里的关键影响因素就是代码质量。CSS、HTML、JavaScript这三种前端开发语言的特点是不同的，对代码质量的要求也不同，但它们之间又有着千丝万缕的联系。
综合来说，UI设计和Web前端开发都与产品页面有很大关系的，只是前者更偏向于设计，而后者需要懂得更多的技术，需要把UI设计出来的东西与后端结合，实现出来，所以Web前端的核心发展肯定会更好，但相对而言学习也会比UI难一点。

转载表面上看，是一套基于B/S方式实现的分布式管理系统，但其实背后的架构是基于C/S完成的。你以为他是一只鞋吗？其实他是一个吹风机。作为界面化的系统，浏览器框架是不可或缺的，但更加重要的东西在Socket上面。

一、需要解决中央控制端到各节点服务器之间的通信。

这个其实牵扯到一个通信协议的问题，各语言都有自己的socket，thread的库，直接调用即可。但是这个通信协议就需要自己来完成了。既不能太简单，太简单了，明码传输，如果别人获知了这个接口，就很容易执行一些令人讨厌的 *** 作。也不能太复杂，太复杂了等于是给自己找麻烦，所以简单的数据包编解码的工作或者用token验证的方式是需要的。通信协议起码要两种，一种是传输命令执行的协议，一种是传输文件的协议。

二、跨语言的socket通信

为什么要跨语言，主控端和代理端通信，用什么语言开发其实无所谓。但是为了给自己省事，尽可能使用服务器上已经有了的默认语言，Ambari前期采用phppuppet的方式管理集群，这不是不可以，puppet自己解决了socket通信协议和文件传输的问题，可你需要为了puppet在每台服务器上都安装ruby。我是个有点服务器和代码洁癖的人。光是为了一个puppet就装个ruby，我觉得心里特对不起服务器的资源。所以我自己写了一个python的代理端。python是不管哪个linux系统在安装的时候就都会有了。然后主控端的通信，可以用python实现，也可以用php实现，但是考虑到对于更多的使用者来说，改php可能要比改tornado简单许多，所以就没用python开发。hadoop分支版本众多，发布出去，用户要自己修改成安装适合自己的hadoop发行版，就势必要改源码，会php的明显比会python的多。php里面的model封装了所有的 *** 作，而python只是个 *** 作代理人的角色而已。

所以也延伸出一个问题，什么语言用来做这种分布式管理系统的代理端比较合适，我自己觉得，也就是python比较合适了， *** 作系统自带，原生的package功能基本够用。用java和php也可以写agent，但是你势必在各节点预先就铺设好jre或者php运行环境。这就跟为什么用python和java写mapred的人最多是一样的。没人拦着你用nodejs写mapred，也可以写，就是你得在每个节点都装v8的解释引擎，不嫌麻烦完全可以这样干。原理参看map/rece论文，不解释。perl也是 *** 作系统原生带的，但是perl的可维护性太差了，还是算了吧。

所以这就牵扯到一个跨语言的socket问题，理论上来说，这不存在什么问题。但这是理论上的，实际开发过程中确实存在问题，比如socket长连接，通信数据包在底层的封装方式不同。我没有使用xml-rpc的原因之一就是我听说php的xmlrpc跟其他语言的xmlrpc有不同的地方，需要修改才能用,我就没有用这种办法。最早是自己定义的 *** 作协议，这时就遇到了这些问题，所以后来直接采用了thrift方式。就基本不存在跨语言的socket通信问题了。

三、代理端执行结果的获取

无论命令还是文件是否在代理端执行成功，都需要获取到执行结果返回给中央端。所以这里也涉及一个读取节点上的stdout和stderr的问题。这个总体来说不是很难，都有现成的包。当然这个时候你需要的是阻塞执行，而不能搞异步回调。

还有个问题是，我要尽可能使用python默认就带的包，而尽量不让服务器去访问internet下载第三方的包。

还有代理端最重要的一点，就是python的版本兼容性。centos5用python24，centos6用python26，ubuntu基本默认都是27。所以一定要最大限度的保证语言的跨版本兼容性，要是每个 *** 作系统和每一个版本我都写一个代理，我一个人就累死了。

四、浏览器端的model，view，controller

这里面你要封装好所有的通信协议，以及需要在节点上面执行的脚本。发送文件的 *** 作和数据库 *** 作也要在model里面完成。

如果对tcl/tk很熟，也可以写基于 *** 作系统界面方式的管理，不用浏览器就是了。

view对我来说是最痛苦的事，都是现学的jQuery怎么用，前端的工作太可怕了。关于这方面，没有太多可描述的，html和js带给我的只有痛苦的回忆，万恶的undefined。

五、跨 *** 作系统的安装文件封装。

要适应不同的 *** 作系统也是个很麻烦的事情，需要用agent提前获知 *** 作系统的发行分支，版本号。然后去找到对应的安装文件去执行。你不能保证一个分布式系统的集群中所有的节点都可以访问internet，更多的情况是这些节点都存在在一个安全的内网中。只有个别几个节点是可以访问外网的。所以，我势必要把所有的安装文件以及他们的依赖尽可能集中起来。我不确定安装 *** 作系统的lzo，yum或者apt-get会去下什么鬼东西，甚至无论是yum还是apt-get，里面都没有hadoop-lzo的库文件。所以，最好的办法是自己编译打包rpm和deb包。直接安装就好了，别去找repo下载什么。

这就是第五步工作，把需要的依赖的东西自己编译打包成rpm和deb。

deb包很好解决，但是rpm就没那么好办了，需要学习rpm的编译文件如何编写，这块是挺麻烦的，但是这玩意用好了还是挺不错的。现在我自制的安装包里面就已经包含了自己编译的lzo和snappy两种压缩库，以及hadoop-gpl-packaging的rpm和deb。下一个发布的easyhadoop将直接支持centos5,6，suse，以及ubuntu/debian的系统上安装hadoop。已经自带了lzo和snappy以及lzop和snzip。

六、把这些所有东西，整合到一个系统里面。

关联这些所有事情间的联系，整合到一个浏览器界面里面去。写一个分布式的管理脚本不难，写一个界面也不难，但是也许是我的水平不行，这两件事结合起来让他们协同工作还是有点难度的。对我来说，写界面的工作可能更难一点。

Cloudera可能是十来个人在写Manager的东西，ambari也是放到github和apachesvn上面，apache基金会的各种committer在写。easyhadoop没他们功能那么强大，一年来只有我一个人设计架构，功能，各种语言的编码，测试，发布。Fortheloveofgod,WhathaveIdone(英文部分请站在山顶仰天长啸)T_T。从前台到后台，到hadoop和生态系统以及他们的依赖软件的单独patch、编译打包。(系统yum或者apt-get的包不如自己打的好使。)

从时间上来看，全球第一款开源的hadoop部署管理系统应该还是属于ambari，2011年8月开始写的，2012年9月底进入apache的incubator。我是大概2012年8月开始写的easyhadoop，全球第一没赶上，估计国内第一个开源的hadoop管理系统还是可以排上的。

---