• html模板你够了啊 !!!

    2014-08-04

    在js代码里去拼凑html模板真的是一件体验非常糟糕的事。没有语法高亮,没有代码折叠,对错全在你的幸运程度之间,当然还有细心啦。我在这上面犯的错依然非常多了,从中除了说明我不够细心之外,就是它真的很容易出错啊!一般的js模板引擎并没有提供非常友好的出错提示,有时候我查错半天只是特么因为我手抖多写一个空格,这种时候我尤为觉得自己愚笨,后悔没有按时吃药。在做一件特别容易出错的事上,除了要让自己变得谨慎细心之外,还有就是要改进你的做事方法,而程序员更要懂得变通来偷懒。那么今天我就要来说说这个东西有没有可以改进的地方。

    一般我们可能会选择像下面这样来写html模板:

    // 像这样
    var panel = '<div class="panel">' +
                    '<h3 class="title">{{title}}</h3>' +
                    '<div class="content">{{content}}</div>' +
                '</div>';
    // 或者这样
    var panel = '<div class="panel">\
                    <h3 class="title">{{title}}</h3>\
                    <div class="content">{{content}}</div>\
                </div>'
    ;
    // 或者再这样
    var panel = ['<div class="panel">',
                    '<h3 class="title">{{title}}</h3>',
                    '<div class="content">{{content}}</div>',
                '</div>'].join('');

    这三种方式本质上并无区别,无论你平时选择哪一种书写方式都并没有高大上一点。如果你还非要从这三种方式中争出个高低之分,反而更显得你在装逼了。
    阅读全文→

    Author:夜漫长 | Categories:javascriptweb相关 | Tags:
  • Lets Angular !

    2014-07-05

    从没有一个前端框架给我这么大的惊喜,除了AngularJS.上一次给我些许惊喜的是facebook的react。惊喜产生兴趣,所以它是我的好老师。声明一下,本文并非鼓吹你去使用AngularJS,从我平静的言语,理智的小眼神就可以看出来,用不用,你说了算,别特么想让我对你负责。不过了解一下又不会死。

    本文会流水一下AngularJS一些让我觉得好玩的地方,所以不是教程,不是宝典,是什么我也不造。提前预报,下一篇文章我会写一写AngularJS的Module Watch的实现,它的dirty-checking机制,还有大家担忧的2000个watcher的阀值问题。

    在我看来国内的技术人员的水平并见得就比国外人差,从我国人能够快速轻松copy任何一个新宠就可看出,我们在用实际行动告诉那些原作者,你这玩意儿没有任何技术难度,不信哥给你写一个,顺便帮你找bug。你叫River我就叫Sea,你叫Stone我就叫Mountain,总之格局就比你大。可是,可是,这样真的好吗?不得不说在思想创意方面,我们已经输到姥姥家了。

    前几天我嘲笑了我的一个同学兼同行,因为他告诉我他最近在学习backbone,他说backbone真是好用到心碎。他对AngularJS的视而不见同样也让我感到心碎。不敢说backbone的坏话,但是实际上backbone帮你做的事情太有限了,它并不能真正减少你需要书写的代码量。而AngularJS这方面就做的非常直接粗暴,就是不让你多写js代码,多写跟你急。

    jQuery VS AngularJS

    有人说我jQuery用得好好的,干嘛要用AngularJS,名字还这么奇葩。其实jQuery和AngularJS并不冲突,拿他们做比较也是不合适的。我一直认为jQuery只能被称为一个库,也许因为它的plugin和UI的开发方式,让人觉得它可以被称为框架。 而真正的框架是需要帮你做代码逻辑层级的界限划分,而不只是一个代码的组织方式。在你不打我的前提下,我还是坚定的认为把jQuery叫做框架不太合适。至于你为什么要使用AngularJS我们且往后看。

    你是否可以同时使用jQuery和AngularJS?当然可以,但是真的不建议你这么做,就像你非要让你姥姥和你老爸去踢一场严肃正经的足球,可是这是一件想想都觉得很有喜感的事情啊。如果你一定要jQuery和AngularJS两个都不是gay的老爸共同生活也是没有问题的。不过jQuery和AngularJS指导着两种截然不同的编程思路,非要有个名字的话大概就是命令式和声明式编程的差异。

    在jQuery时代,dom节点就是孙悟空手里的金箍棒,有了它上天入地。而在AngularJS里采用的更多是一种增强的html声明方式,js代码代码里更多的是对module的处理,甚少去关心dom节点。如果你在使用AngrularJS的情况下还需要依赖jQuery提供的功能,那么你应该是真的没有领悟到其精髓。jQuery可以让我们快速处理问题,所有的问题就可以转化成写页面、找节点、绑定事件、操作节点这样的步骤来解决。而使用AngularJS,我们首先需要对整个问题有一个全面的认识,然后去设计你的代码,最后才是去写代码。相对jQuery来说AngularJS有着较高的学习成本。
    阅读全文→

    Author:夜漫长 | Categories:javascript | Tags:
  • jQuery Data Cache

    2014-06-08

    也许你都可以抢答jQuery.data或者jQuery.fn.data的作用了,你也并未去了解过jQuery把这些数据存放在何处。以前我也想当然的认为它把这些数据直接保存在了原生的dom对象上,然而研究发现,nope。我们通过一个例子来说明吧。

    $('#username').data('username', '李四');
    $('#username')[0].username; // undefined
    $('#username').data('username') // 李四

    可以发现,事情并不是按我想象的方式进行的。id为name的dom节点上并没有被添加一个叫username的属性。那么这些数据到底保存在何处呢?这个时候当你在控制台输出jQuery.cache,你会发现你所有通过data方法添加的数据都能在里面找到,所以最终的数据都是保存在jQuery的cache属性里面。

    // jQuery.cache输出的数据
    {
        "1": {
            "data": {
                "username": "李四"
            }
        }
    }

    那么它们是如何建立映射关系的呢?在jQuery源代码里data方法里调用了一个叫internalData的方法,这个方法里提供给了我们想要的信息。

    jQuery.expando = "jQuery" + ( version + Math.random() ).replace( /\D/g, "" );
    internalKey = jQuery.expando;
    elem[ internalKey ] = deletedIds.pop() || jQuery.guid++;

    expando是jQuery加载到页面时生成的一个随机的字符串,jQuery.guid则是一个从1开始不断+1的一个标识,这个guid实际上就对应了jQuery.cache里面的键值。通过上述代码我们发现了,节点对象上被添加了一个值为expando属性,该属性值对应到jQuery.cache里面的键值,然后获取到对应的数据。所以当你调用data方法获取某个属性值时,先要获取该原生节点上的jQuery.expando属性,得到它的值然后去jQuery.cache里面找对应的属性,再找该属性里面的data属性,最后一步就是根据你提供的属性名称获取到最终的值。

    $('#username').data('username'); // "李四"
    jQuery.cache[$('#username')[0][jQuery.expando]].data.username; // "李四"

    那么jQuery为什么要绕一个圈子,多此一举呢?主要原因是为了避免IE6、7下的循环引用可能导致内存泄露的问题,而这个问题的源头就是因为IE低版本浏览器下引用计数垃圾回收机制的缺陷。代码写到这一步并没完,这样确实能解决问题,可是又带来了另一个问题,就是数据清除的问题。当把数据保存到dom节点上时,当进行删除节点,替换节点等操作时,节点上的数据也自动的被清除了,然而把数据保存到jQuery.cache上时,这种自动关联就消失了,jQuery就需要在html、remove这些方法里添加删除jQuery.cache里面对应数据的行为。

    以上的了解都是源于我在看bootstrap代码的时候,发现jQuery的data还有一种用法,就是它可以直接获取dom节点上data-开头的数据。于是我就去看了看jQuery.data方法,然后了解到jQuery的data cache原理。

    <input type="text" id="username" data-uid="324253252">
    $('#username').attr('data-uid'); // "324253252"
    $('#username').data('uid'); // 324253252
    Author:夜漫长 | Categories:javascript | Tags:
  • 中文输入法下的搜索优化

    2014-04-30

    最近做了一个移动端的搜索功能,带有suggest。实现上并没有什么可说的,但是在后续优化上,特别是在中文输入法的情况下的优化使我学到一些新东西,所以决定写一篇文章。

    下面是我简化后的基本功能实现,监听输入框的input事件,当搜索框有输入时,根据输入内容和后端进行交互提供suggest,再监听keyup的事件,当用户敲击回车的时候,就进行一次搜索。注意其中suggest和search是两个自定义事件,并非原生事件。我们在实际生产环境里应该给自定义事件加上特殊前缀。

    $('#searchInput')
    .on('input', function() {
        $(this).trigger('suggest');
    })
    .on('keyup', function(e) {
        var isEnterKey = e.keyCode === 13;
        if(isEnterKey) {
            $(this).trigger('search');
        }
    })
    .on('suggest', function() {
        ...
    })
    .on('search', function() {
        ...
    })

    做到这一步,基本功能就可用了。然后我们可以考虑做一些优化,优化点就是减少和后端非必要的的交互,我们一般有如下措施:

    1.ajax缓存
    2.trim操作防止空格产生的input事件
    3.用time delay来优化用户输入过快频繁和后端发生的suggest询问
    4.当用户当前输入法状态是中文时,在未选择词组到输入框之前不和后端进行任何交互
    5.中文输入法状态下回车是将输入的字母填入输入框中,这时的回车不进行搜索

    接下来我会就说说我对第4、5条的优化的实现。当我们把输入法切换为中文,然后进行输入,这种情况下还是会触发input事件,即便我们还没有选择词组。我们想要的结果是只有词组进入了输入框才向后端发起suggest询问。我们可以使用两个较新的事件来达到预期的效果:compositionstart和compositionend。

    compositionstart
    当浏览器有非直接的文字输入时, compositionstart事件会以同步模式触发.

    compositionend
    当浏览器是直接的文字输入时, compositionend会以同步模式触发.

    上面是MDN上的解释,我也是第一次接触到上述事件。

    $('#searchInput')
    .on('compositionstart', function() {
        $(this).data('notEnglishInputMethod', true);
    })
    .on('compositionend', function() {
        $(this).data('notEnglishInputMethod', false);
    })

    然后我们可以通过$(‘#searchInput’).data(‘notEnglishInputMethod’)来判断是否触发suggest。在input事件里加上这个条件。

    $('#searchInput').on('input', function() {
        if(!$(this).data('notEnglishInputMethod')) {
            $(this).trigger('suggest', value);
        }
    })

    这样我们的第4个问题总算解决了,现在中文输入法下敲击键盘不会进行suggest,直到选择了词组。还剩下第5个问题,在中文键入拼音展现可选词组的状态下回车不进行默认的搜索功能。

    即便当前是中文输入法,我们的keyup事件同样会被触发。我试了半天都没找到很好的解决办法,后来我发现中文输入法事件下keydown事件里面所有按键的keyCode都等于229,于是我们可以通过这个差异来解决这个问题。我们给输入框再绑定一个keydown事件,并把当前的keyCode保存起来,然后在keyup事件里面来作比较,如果两者相等,基本可以确实是在直接输入的状态下,不相等则表示是在非直接输入的情况下,也就是中文输入法情况下。Show you the code!

    $('#searchInput')
    .on('keydown', function(e) {
        $(this).data('lastKeydownCode', e.keyCode);
    })
    .on('keyup', function(e) {
        var isEnterKey = e.keyCode === 13;
        if(isEnterKey && e.keyCode === $(this).data('lastKeydownCode')) {
            $(this).trigger('search');
        }
    })

    通过上述的方法,我们基本上解决了中文输入法搜索带来的问题。希望能对你有小小的帮助。

    Author:夜漫长 | Categories:javascript | Tags:
  • 基于jQuery的scroll事件扩展

    2014-04-23

    在我的工作当中时常会和scroll事件打交道,在处理scroll事件的时候,为了防止scroll事件被频繁触发,我们往往会采取time delay这样的方式来进行优化,如下

    var scrollTimer;
    $(document).on('scroll', function() {
        scrollTimer && clearTimeout(scrollTimer);
        scrollTimer = setTimeout(function() {
            ...
        }, 100)
    })

    一般时间设为100ms是一个比较理想的平衡值。

    当我们使用到scroll事件的时候,一般是为了实现lazyload或者滚动加载这样的功能。所以为了更方便快速的使用scroll事件来满足这样的需求场景,我对scroll事件做了一个简单的封装处理,为了以后的使用带去一些便利,不用每次都重复这些工作。

    你现在可以按照下面的方式来添加scroll事件:

    // 20ms的事件延迟
    $(document).on('scroll/20', function() {
        ...
    })
    // 滚动至顶部的距离大于500px触发
    $(document).on('scroll>500', function() {
        ...
    })
    // 滚动至底部小于500px触发
    $(document).on('scroll<500', function() {
        ...
    })
    // 滚动至底部小于500px触发,且添加100ms的延迟
    $(document).on('scroll<500/100', function() {
        ...
    })

    相对于原来的scroll事件,主要做了如下扩展:
    /:scroll事件延迟功能
    >:滚动到距离顶部大于某个值时,事件触发
    <:滚动到距离底部小于某个值时,事件触发

    对于jQuery off和事件命名空间可以正常使用,没有丝毫影响:

    $(document).off('scroll/100')
    $(document).on('scroll<500.loading', function() {
        ...
    })
    $(document).off('scroll<500.loading');

    jQuery事件貌似没有为这样的场景提供扩展的便利,所以我在jQuery的on方法上层再做了一次包装,这并不是一种值得推荐的实践方式。但为了使用上的便利,我还是选择了这种方式。

    查看demo  View Source on Github

    Author:夜漫长 | Categories:javascript | Tags:
  • 学习RESTful API

    2014-01-14

    前几日,有一小哥突然问我:陈陈,你会RESTful API吗?我说:不会呀,他说:那我教你好了。然后我就把该小哥拉入“黑名单”了,理由是唱你妹的小星星。然后去深入的学习了一下REST相关的东西。

    RESTful API对我并不是一个全新的像是突然蹦出来的词汇,我印象中工作上出现过好几次,但是每次我都没有真正理解这个东西。我不知道什么样的接口类型可以称得上是一种RESTful API,不知道RESTful API好在哪儿?那么今天这篇文章就是用来解决我的这些困惑的。要声明的是我只会站在前端使用者的角度来说说RESTful API看起来的样子,至于后端如何实现RESTful API接口的事我则不会涉及。

    先从Web Service说起。Service就是提供可利用的资源,那么再加上Web这张网就可以对资源利用得到极大延伸,不在局限于你的本地或四邻。这时就应运而生一种信息交换协议——SOAP(简单对象访问协议,Simple Object Access Protocol)。SOAP有着严格的协议,内容至今也基本齐全,然而随着时间的推进,它的弊端也逐渐暴露出来。SOAP消息基于很老的XML格式,显得厚重,同时支持多种传输协议如HTTP、TCP/UDP等等,其内容涉及封装以及状态维持等等,总而言之,言而总之,就是它的复杂程度已经违背了起初设计Web Service的简明原则了,所以在2000年Roy Thomas Fielding提出了REST(Representational State Transfer)架构。算是打响改善的第一枪。如果一个架构符合REST原则,就称它为RESTful架构。

    通过对比SOAP和RESTful API的不同点,大致可以让我们了解到RESTful API的样子。

    首先SOAP是一种严格的协议,而REST却并非协议,而是一种指导原则。而我个人认为它们最大的不同点在于SOAP是基于事务,而RESTful API是基于资源,然后利用HTTP的方法(GET、POST、PUT、DELETE)来表征行为。

    一个SOAP接口可能如下:
    GET http://www.example.com/getBook
    POST http://www.example.com/addBook
    POST http://www.example.com/updateBook
    POST http://www.example.com/deleteBook

    而对应的RESTful接口可能如下:
    GET http://www.example.com/book
    POST http://www.example.com/book
    PUT http://www.example.com/book
    DELETE http://www.example.com/book

    以上接口的作用依次为获取书籍、添加书籍、更新书籍、删除书籍,你会发现SOAP提供的接口基本是以动词加名词结尾,是基于做什么事的,而RESTful风格的接口则是名词结尾,把服务看成资源,然后完全利用HTTP的请求方法来做行为判断。SOAP接口返回XML格式,而RESTful API没有明确应答的格式要求。因为RESTful API只针对HTTP使用设计,所以他能更好的适用于浏览器,以及js的httpRequest请求。

    RESTful API轻便的一个原因就是它是无状态的,所以它可以做缓存处理,增进性能,然而这也成为了它的一个短板。其实现在很多Web Service都不是随便可以滥用的,都需要身份验证,权限设置。如果把身份信息放在HTTP head里面,如何保证身份不被伪造?那么在这种情况下RESTful API就无法适用了,反而SOAP可以很好的适应。REST也在不断的完善,也许有一天他也可以做到状态维持,那么是否表明它也成了另一个SOAP呢?所以没有什么东西是十全十美的,但是却有单一场景下十全十美的东西。

    不管怎么说,RESTful API已经流传深远,对SOAP产生了巨大冲击。以上只是个人简单片面的理解,如果要想求真知,还望大家自行查阅资料,涨姿势。

    Author:夜漫长 | Categories:web相关 | Tags:
  • 警惕狭隘

    2013-10-31

    如果非要给同行们捎去一句话,那么我一定会说程序员要警惕狭隘。这个话题因我在某论坛上看见某些人的’高见’而起。我发现有些技术问题引起的却是对公司的声讨,对人的指责,而真正切中要害与问题相关的回答少之又少,更多的人都是在忙着问候对方全家。其中某些带着强烈个人偏见的回答着实让人不爽,然而更让人气愤的是这类人往往陷你于不同意他们你就是白痴的境地。他们的行为都像是粗蛮野夫,遵从探讨不求长姿势,但求倾尽所有脏字的原则。所以我建议以后遇到这类人就不要搭理,除非你想把智商降到和他一样低,或者你有他们一样丰富的’词汇量’。

    也许有些程序员在0和1的世界里畅游惯了,回到现实都难以摆脱这种只有对和错、非此即彼的判断准则。这种纯粹简明的原则往往难以立于公平公正之基石上。程序员借来这套原则往往只是因为他的个人喜恶需要正义的伪装罢了。我虽不敢说什么大话,但在此处我敢大声地说:任何不经充分思辨论证而做出的对错之分,得到的都是一种狭隘、懒惰、虚妄的结论。如果还把这种结论加以传播,那么我就可以治你一个’狭隘之人’的罪名。愿所有程序员都把狭隘当成一种十恶不赦的大罪。

    接着说说我对狭隘的定义(当然我的这个定义也十分狭隘):任何一种不能容忍相异性的态度都是狭隘之态度、任何一种不摆出可证伪依据的流氓行为都是狭隘之行为、任何一个于人挑剔于己宽容的人都是狭隘之人。

    任何一种不能容忍相异性的态度都是狭隘之态度

    有些人喜欢谷歌,有些人喜欢苹果,有些人喜欢微软。基本上每个人都能找到自己的小伙伴阵营。这本来只是一种简简单单的个人喜好而已,但是你要让各阵营手牵手唱上今天是个好日子是难上加难的事。喜欢谷歌的笑苹果太封闭,喜欢苹果的笑微软太土鳖等等。这些人都毫不犹豫的想要把个人的喜好强制推销给大众。你还不能拒绝,拒绝了你就是白痴。这往往又会陷你于尴尬的境地。这种敌对,无法理解别人与自己选择差异的人往往自视甚高,而这可能就是蒙蔽你视野导致你狭隘的源头。人活在世上,一定要有包容的心态,学会理解差异,体验这种差异,也许只有这样才能让你痛痛快快地把自己是天才别人都是白痴这样的话扔进茅坑里,并为自己当时有过这念头而羞愧。正如罗素大师所言:参差多态乃是幸福的本源。所以人与人之间的差异才是精彩所在,我们要在这种参差不齐中反思,获取养分,寻求个人的进步才是。绝对不要去抹灭这种差异性,最好试都不要试。

    任何一种不摆出可证伪依据的流氓行为都是狭隘之行为

    对于有些人在别人的问题下只留下’某某某是傻逼’这样的心态我就有些不理解。我原本以为他的回答绝不止于此,一定还会有下文,他们肯定会找来证据证明这个某某某的确是傻逼,从而让我心服口服的承认这个某某某果然是傻逼。可事实上我看见很多人都只留下了’某某某是傻逼’然后就销声匿迹了。所以我从来都看不出这个某某某傻逼在何处,而你又聪明在哪儿。而今天我又看见一条:某某公司是垃圾公司,然后就没有然后了。于是后面只能靠我自己来猜想了。我想是这样的,这个留言的同学曾经在这个某某公司呆过,但是因为某些原因然后离开了,于是对该公司名字异常敏感,敏感到看见该名字大脑直接将其反射为’垃圾公司‘四个字。我又非常好奇该同学在该公司到底经历了些什么。于是我又猜想了:他可能经历了一些不愉快的事,有可能是顶撞了他的秃顶上司,他的上司就将其打入冷宫。那么他也不应该说公司垃圾,应该说某某公司某某秃顶领导是傻逼呀。而我又想有可能他的秃顶领导是对事不对人。那么有没有可能是该作者做了些什么让别人不愉快的事情,而他自己却还不自知呢?如果是这样的话,那么我是否可以稍微跳跃些的来理解’某某公司是垃圾公司’实际上就和’我自己是傻逼’是一个意思呢?总之有一点是可以确认的,正常人是断然不会骂自己是傻逼的。

    所以我也奉劝各位朋友,如果没有亲身经历,没有事实依据的情况下,请收敛些你那爱总结的癖好。还有骂的对象一定要明确,免得一句虚伪的人就把大部分中国人给骂了,自己却还不知道呢。如果要想让人信服,请多些可论证的事实,少些揣测和道听途说。

    任何一个于人挑剔于己宽容的人都是狭隘之人

    我原以为那些喜欢说别人不是的人只是少数,但后来我发现这类人大有人在。他们有猫头鹰一般明锐的洞察力,栖身在黑暗的角落,等待某个可怜的猎物出现。这引出了一个可以用来讨论的问题:我们是否可以指责水平比我们自己高的人?比如你篮球打得很烂,你是否可以指责科比(NBA球员)的某场比赛表现不够好呢?这个问题我想很容易,大部分人都认为肯定是可以啦,科比毕竟是专业的运动员。那咱们再换换,肖恩马克斯(NBA烂球员之一)是否可以指责科比球打得不好呢?这个问题的答案就因人而异了。我想肖恩马克斯定不会说出这样的话,他没这样的勇气,再者说出来也变成了笑话。

    我想一个人人都对自己要求严格,对他人保持宽容的社会应该算得上是一个理想的好社会。然而我们暂时都还没有这样的自觉。我们讨厌别人比我们优秀,自己却又不愿努力,于是便生出了一种畸形自我安慰的道理,给别人订立更严苛的标准,让自己对他们永远有毛病可挑。这种衍生出来的双重标准一旦在你心里滋生,也许你从此就会丧失进取之心、敬畏之心,甚至连做人的可爱都没有了,所以这种坏东西,一旦有了就应该拿出刮骨疗伤的勇气清了干净才行。

    我也本是狭隘之人,时时害怕个人的狭隘会影响到他人,哪怕只是一点点也会令我非常不安,所以大多数时候我都只能保持沉默。

    Author:夜漫长 | Categories:文字片段 | Tags:
  • 响应式设计之扯淡篇

    2013-10-19

    秋意正浓,今天正适合扯这个高端大气的话题—响应式设计。正所谓看上去很美好的东西远远只是看上去很美好而已,而响应式设计就属这类。去了解学习完全是源于自己害怕被淘汰的恐惧心理,无关工作。demo来demo去我都觉得无聊,所以决定写一篇文章来个总结神马的,也让别人知道:看,哥早就研究过了。然而究其我在工作中难以练手的原因,除了人口大国较之别国一切都更复杂之外,那么就是她自生的局限性了。对于一个大型复杂的网站来说,响应式的改造实现显得隔空瘙痒,并不利好。然而历史为鉴,你绝对不可以忽视任何一股新生的力量,否则你可能遭遇被毁灭或被取代的下场。星星之火,可以燎原。

    说响应式设计之前我还想先扯点别的。去年WebApp异常火热,像是涂抹了奶油的蛋糕,包含降低企业成本,跨终端的完美解决方案,更浮夸者让Native App开发者都滚回家种田等多种口味任君选择,大家都想上去咬一口,而本人也是其中之一。我在完全不了解,完全没有实践过,仅仅看了一些报道的情况下,在当时所在公司的大肆鼓吹WebApp。你个土鳖老板再不使用WebApp的开发方式你就out了,WebApp你都不会你还是程序猿么 ……还好结果只是我个人比较盲目,大家都比较清醒,并未酿成‘杯具’。到现在我对WebApp的态度急转直下,然而并非是WebApp有多么不堪,也有一些很好的WebApp的例子,gmail就是其中之一。我有同事使用phoneGap做的一个类似于糗事百科的Hybrid APP,体验也都还能接受。WebApp没有什么是否对错,而错的往往是想借助WebApp一通百通的心态。我非常反感粗犷兼容的设计哲学(我甚至非常痛恨兼容这个词,这和我自身职业也有关系),而更着迷于精巧有度的设计。即便为此我需要付出更大的代价,那么我也愿意。是的。Yes, I do!

    好的设计往往能达到扬长避短的效果,而兼容往往就是平庸的开始。为了避短,难以扬长。一个产品可以有诸多缺点,但如果你不能把你的产品优点最大化那么就是罪过。你的杰作不能引起市场的反响,也许就源于你产品优点就是有诸多优点,缺点就是优点都特么不明显。有时候我总想写篇专门吐槽产品设计同学的文章,但是我又怕我写只会漏洞百出,徒增笑柄,所以我就决定把对产品设计同学的意见分散到诸多文章的角落里。这样不仅不显眼,而且还痛快。

    工作到目前为止,我从未见过那个产品人员真正难以取代。筛选产品人员本身就是一项艰难的事情,难以定规、量化。这比招那些问为什么做前端因为前端简单(我勒个去,你还敢再实诚点吗?你是派来黑前端的吧)的前端技术人员还不靠谱。请产品同学自己思考一下,你是否真的难以取代。你完成的工作是否比换个人来做更加优秀。好的技术人员却是难以替代的。如果只是抄一抄竞争对手的产品、套一些理论公式,说一些空泛害人不浅的UCD理论,那么你真的应该担心明天自己是否就会失业。以前我很认同产品设计人员的的专业性和存在的必要性,觉得技术因为长久练出的思维方式去思考产品往往会有局限性。然而现在我却不这么看了。我时常听见产品之间言辞激烈的讨论,周围几米风起云涌。用户可能更喜欢这种颜色,这个按钮更大一些用户才想要去点击,要是我我肯定就把这个放到右上角去,blablabla。你特么是为用户带盐了还是怎么的。一个没有基因的产品,即使铺天盖地的‘黄色’,按钮做得跟你的脸一般大,我特么也无爱。有时和产品人员交流,我时常感觉到‘就特么我一个人是专业的么’(出自《落水狗》)。

    好了,进入正题吧(前戏好像太久,进入时间稍晚)。接下来我们就详细说说WebApp。WebApp?擦,不是响应式设计吗?难道我说成了WebApp?

    说到响应式设计又让我想起了一件趣事(擦,又要开始瞎扯了,放心,这次我会快速扯完)。我前面面试一位同学,到现在我对他的印象都还很深,因为他是那种我很少见的话唠式的技术求职者。从他的简历来看,他应该对响应式设计有比较深地了解,算是个行家。于是我就问他:我对响应式设计也不太懂,你能向我布道一下吗?五分钟后我不堪折磨不得不强制打断他的话,因为我看不到任何他想停下来的意思。他虽然给我讲了足足五分钟的响应式设计,如果我不打断就远不止这个时间,但是我所收获的有效信息却十分有限。其口水话太多,所述内容毫无条理。从中我明白两点:1.求职者话不在多在精。2.你简历上的技术长处,慎重,慎重,再慎重,不要看了本《21天精通XXX》就写上精通XXX。面试官往往会从你的简历上的长处和工作经历去突破考察你,如果你简历上字号加大加粗相关的内容都答不上来,也就不会有然后了。

    好了,正式进入正题——响应式设计(前戏这么久,看了这是要秒射的节奏啊),绝不再扯淡了。算了,由于废话太多,还是决定另起一篇来讲述响应式设计吧(看,果真秒射了)。容我再花时间将内容梳理完善一下,后续补上响应式设计之正文篇,本文干脆就叫响应式设计之扯淡篇吧。

    Author:夜漫长 | Categories:csshtml5说三道四 | Tags:
  • JavaScript定时器优化

    2013-10-12

    今天的内容让我首先想起了我在成都实习求职时所经历千人大军争夺腾讯职位的场景,乌泱泱的求职者一波被灭,一大波又在靠近。对于此景我常这样描述:人多,真多,真他妈多!不过所幸由于自己水平有限把机会让给了更需要的同学,也算是牺牲小我成全大我留了美名了。

    在这次面试中我自己用惨不忍睹来形容,在此向当时的面试官致以最诚挚的歉意,原谅我对你宝贵时间的浪费,纯洁心灵的摧残,感谢你的容忍。你几次握紧的拳头,都用自己变态的自控能力舒展开来。我深知要做到这一点所需要的勇气和毅力。并非要黑腾讯的面试官,开个玩笑而已。

    这次面试虽然失败,却让我记住一个我大概一辈子都不会忘记的知识点。那就是今天的主题—定时器。当时面试官问了关于定时器的执行时间问题。我当时认为js定时器所传入的时间就是它的执行时间,到了指定的时间他就会风雨无阻的执行,除非山无棱天地合,才敢不执行。然而随着时间的推移,当年的小骚年才终于得以开窍。

    给定时器所传入的时间并非是开始执行的时间。定时器的原理就像你要找一个裁缝做一件衣服,你交了定金,裁缝给了你一张小条并告诉你一星期后来取。一星期后当你踏着轻快的脚步去取衣服的时候,裁缝告诉你上几件衣服还没做完呢,做完了才能给你做。于是你只能指着裁缝说:“内什么,你等着”。所以js中定时器时间的真正意义就是在这个时间间隔后会把你的任务加入到它的执行队列中,就是我们所谓的todo-list。至于什么时候执行要看看它前面还有没有未完成的任务。
    阅读全文→

    Author:夜漫长 | Categories:javascript | Tags:
  • 未给姐姐递出的信

    2013-09-14

    我有一个表姐,她是云南边远地区的一名乡村教师。我在云南大致待了8年的时间,还因为某些特殊的原因,我们共同分享一个家庭的温暖,所以我们是有着血浓于水的亲情的。

    近些日子,每逢周末,姐姐都会给我发一条短信,告诉我周末要好好过。平时忙碌工作,周末可以自由安排。我大多会在周五晚上找一部老电影看看,周六周日可以晚些起床,时间也大多耗在了看一些乱七八糟的书上面了。这就是让我所感到舒服的生活方式。然而大多数人都不太认可这种过周末的方式,年纪尚浅,你大可以约几个朋友去一些吵闹的地方,大声嘶吼,为苦闷为心酸,为所有的理解与不被理解,或者你也可以找一个姑娘去看一场惊险刺激的电影就着爆米花让肾上腺素飙升等等。然而这终究只是一个个人喜好而已,你不必牵强附会,也不必深恶痛绝。

    姐姐近来是有些孤单的,年近三十却选择了离婚。其实姐姐并不决绝,在做这个决定之前经历了长时间的犹豫。也给我打来很多电话向我征询意见。而我也只能说一些,你的人生你必须自己做决定,无论你做什么样的决定我都支持你之类的话。然而其实我心底是偏向离婚的。因为我知道他们彼此给彼此带来的痛苦。因为工作长期分居两地,性格不合,彼此都做了许多改变,但是境况并未好转,所以我觉得彼此放手这种煽情的方式是可以成全和解放两颗历经磨难的灵魂的。由此我也更加坚定一点:你最好爱上你未来伴侣本质的模样,别妄想去改变和塑造对方。

    姐姐也会在电话里说起他的好,说这样分手会不会对他太残忍,也会向我流露出她现在这个年纪离婚,怕会很难在寻到一个有缘人,如果找到了,较之他还糟糕,那就真的糟糕了。这些问题都是姐姐断断续续用了一两年时间才想明白并做出决定的。对于他的好我告诉姐姐,你应该记住他的好,表明你们曾设身处地的为对方付出过。然而去判断一个人的优劣并不是取他的最高分,也不是最低分,这样你才能得到一个更加准确的判断。而姐姐对于年龄的担心现在在我看来当时确说得有些过火。我心底里希望姐姐能够像三毛一样,独立,果敢。任何时候都能够做自由不受束缚的选择。可以忍受生活上的孤寂,但是精神上不得荒芜。然而姐姐也毕竟只是一个普通的女人,他也需要一个男人来给她撑起一片小天地,给她温暖,让她安定。她只想要平淡的过一生,有个想疼的人,有个想回的家。而那袭伟大独立女性的华丽衣裳她撑不起也不愿意穿。而我所欣赏的三毛也还有荷西。
    阅读全文→

    Author:夜漫长 | Categories:文字片段 | Tags:
  •  1 2 3 4 5 6 7 下一页