2013年4月14日 By 情封 分类: 随笔

昨天微吐槽UI v2重新设计改版,伴随着产品的上线,意味着这阶段折腾产品告一个阶段了。在开发产品的过程中,发现自己的内心也改变了一些想法与看法,觉得可以总结分享。不管是STM还是微吐槽,这两个产品的需求都是自己需要的,由于需要就会自己用,产品有在用就会产生需求,良性循环。在产品的演变过程中,自己才是产品的第一用户。

STMhttp://stm.xmf2e.com)是一款自我时间管理的产品(自我定义的),主要集合Todo List、番茄时钟、日报,周报这三大块功能。产品的想法与动机:源于自我需求。这个在我对产品的想法上表现得很明显。

有这个产品的原因是我怎么去方便浏览我每天的日报、周报的总结。通过邮件查看总是有很多不方便的地方,基于这种的不方便,就有了我当初做这个的动机,STM的雏形。

有一段时间流行下载了odoAPP,不管是Andy Do,还是wunderList,发现我总是不能坚持记录我的todo。很多时候事情不是自己不想坚持,不想记,而是没有一种想使用的冲动。有一种在回家的动车上,有联想到v0.1版的功能,既然每天都要写日报汇报工作,我有没一种可以跟这工作内容可以完美结合起来,这就是产品Todo的需求了,这就产生了v1.1版本了。

Todo现在只做一个简单的记录,只有一个任务状态,其他的都没有。现在的功能就可以满足我备忘工作记录了。APP里面的Todo太复杂了,抱养的总归没亲生的好啊~

今年Q1都在项目组中做杂工,项目组是采用敏捷的方式,很多时候有提到任务拆分。一个大的任务拆分成小任务后做起来就简单方便了。经过三个月的磨合,自己在做一件事情的时候,都会去如何去拆任务,最好一句话就能表达我要做的事情。番茄时钟是跟todo一起做的。番茄时钟也是去年看了那本番茄时钟工作法后的一个想法。在选择任务的时候就可以及时,可以统计自己在完成一个任务需要多少番茄时钟。说实话番茄时钟这个功能我没经常用,主要我上班的时候很多时候都很零碎,完整不起来。但在做这个功能时,主要在考虑用什么技术。

到现在STM我在用的过程中也发现了很多要改进的点,比如任务属于什么项目的,用什么颜色来标识等。先阶段用产品沉淀沉淀一段时间。

 

微吐槽(http://www.weitocao.com)的产品想法更简单,这个V 0.1本来定位是想做工作便签的。后来逐渐定义成阅读与吐槽分享的产品。平常自己喜欢在微薄有的没得都会发很多话,但很多时候有些话被很多人看到就不合适怕影响到,但又想说,憋的慌。基于这个简单的需求就做了产品的重新定位。

当然现在V0.2的功能当初没想那么多。自从定位成吐槽分享后,早期只写一些本该发表在微薄的内容,现在只是转移个阵地发表在这里,渐渐的新增了心灵鸡汤,有一段时间超喜欢看这个的,看到好的文字我就有想收藏起来,方便阅读。因为微薄的timeline太快了,要看的时候不知道在哪里。

到上周在开发新版本的时候又联想到当初喜欢收藏写不错的文章存放到本地网站上做阅读,主要很多时候怕好文章链接失效。去年年末自己折腾的UX周刊主要也是分享一些好的文章,阅读类的集合自己蛮喜欢的。现在都整合到微吐槽里面了,做了一次产品集中的整合。现在V0.2也有了后台的管理功能,想实名吐槽的话,后台也可以记录,但如果想匿名在首页也新增了游客的模式,但只能发吐槽。降低吐槽的门槛。这个产品是想做成由用户产生内容(UGC),只有有内容就会产生分享沟通交流。

通过这两个产品,情封做了一个人的项目,从产品功能到UI视觉设计,产品的前后端编码,整个过程中真心有体会到说的比做的容易。特别是要把持到自己的各种产品想法。从着也学会了换位思考,也理解了PM每次都喜欢新增产品需求了,真的以为自己了解产品的用户,还是只是在堆砌功能而已。很多工作只有自己去用心做,用心去体验后才会懂得,原来如此的。情封很多时候也会进入功能堆砌的模式,但我这边有一个做法是先把最近出现的想法用google doc记录起来沉淀段时间后在看是否有必要开发,刚好也可以专注做一两个产品。这个跟立马执行不冲突的。我比较崇尚对待产品小步快跑的想法。先做出产品DEMO,然后先用有问题可以调整。

PS:很多产品源于自己的需求,自己既是网站的需求方,又是网站的体验者。虽然是完成了产品,但这两个产品中还有很多代码细节需要调整。一段时间内不会去新增功能了,主要补缺补漏了。还有一个可以分享的,不要给自己定位标签,多生命在与折腾~~

哈哈,虽然我的网站现在只有我一个用户~~~今年就专注做这两个产品~折腾了~

/***********************产品里程碑************************/

微吐槽:2013-04-16 PV突破600

2013年3月12日 By 情封 分类: 随笔

这篇文章其实早就该出来了,一直没有时间去写,而且标题很难命名。现在这标题让我想起小学、初中在看完雷锋式电影后要写的感想一样。这一年多看过不少书,涉及交互,产品,UI,前端,心灵鸡汤等,至今仍让我想去看第二遍的书只有谢家华的三双鞋,与这本王淮的打造facebook。主要这本书让我读起来有很强的带入感,感觉就在说我在4399的这两年所经历过的事情。我很容易把他的经历跟我联想起来。可能因为有了这本书,我才会去对应自己的经历。直接进入正题吧,我记录比较深刻或对我来说影响比较深刻的部分。

1:跨团队协作的方式。如果需要跨组协作,在facebook会尽可能地让两边直接对接的工程师沟通。把工作的计划权和决定权往下推而不是往上揽。什么时候做,怎么做,如何做,全由工程师决定,除非影响到整个团队的工作进度。
自己从2010年下半年开始带徒弟,2012年开始带前端团队。在这过程中也经历过团队工作模式的思考。因为UED本身的尴尬以及自己对前端开发工程师在整个产品线中角色的理解。我更愿意让前端开发工程师全程负责跟踪整个产品诞生的过程,不止让自己对产品的认识以及对前端整体架构的理解都会有帮助。在整个前端团队中,每个童鞋都有自己所负责的项目,也就是对前端团队来说,TA就是这个项目的唯一接口人。如果项目任务紧急,将知会我进行内部工作的协调,但我只涉及到内部的工作协调。
在之前很想知道所有项目的所有任务,让自己忙碌起来,其实通过一段时间实验之后发现这样对我跟团队的童鞋来说都不好。自己的效率差了不说,童鞋的积极性没了,只变成你说什么就什么,就会成为为了任务而工作。这个很明显不是我想要的结果,不要怕放权,适当的放权会更调动主动性,为了能调动团队的积极性,后面都改革到团队工作的透明化,互相知道团队中其他童鞋的工作。(通过日报的抄送等)永远不要把人当工具。

2:对事情的关注,而不是对时间。
这个标题,让我想起在ND的时光,每个任务都有评估时间,超过评估的时间没绩效,这种模式做久了,人就是个工具了。所以那时候为了完成任务而完成。
对前端来说,特别一项工作或任务能做成常态化或规范化的,就尽量做到最好,这样对自己来说有在思考如何对这种工作做得更好,还有一种就是对自己的开发节约了时间,让自己有更多的时间去学习、去挖掘未知的知识。对自己的技术积累沉淀都有很大的帮助,在你的思想里已经存在一定的思考模式,完成一件事情的同时要想想有没办法做得更好。
2011年跟2012的产品开发模式有很大的差别,2011年,很多时候PM干的最多的一件事情就是每天早上追问你项目进度,所以让我现在还留下阴影,PM只会催进度,其他什么都不会了。2012年经历过两个团队的开发模式的磨合,并且采用敏捷的方式,对产品时间,只要定好上线时间,更多的是让团队去拆分每周期的工作以及完成度。期间通过看板的方式来跟踪,减少人为的跟踪。对事情的关注,不会让你沉沦为工作,在工作的过程中,也要抬头看路啊。

3:面试的问题
这两年来我也参与了很多场前端的面试,我的想法是招什么样的人问什么的问题。只要招人的岗位目的清楚,招这个人是偏JS的还是偏重构的,在面试的过程中有针对性的就会有很好的效果。
面试这么多人,到现在只有2个人不用回去等消息,直接到经理面试的。一个是偏重构,一个是偏JS。偏重构的实习生,带着一堆UI设计稿,对前端的代码有所认识,适合培养。一个偏JS,做过后端,对前后端的开发模式有所了解,这样带动整个团队的开发还是有很好的帮助。
人招进来,你就得为Ta的成长负责。而不是招进来放任之,这样也很不负责任。不要是最近某项工作,整个团队都做不了就跑去招人,这样很容易进入死循环,一不会做就招人。

4:关于导师
这点在2011年的时候,我表现的比较明显,那时候心都比较浮躁,因为梦想还未实现。
这边说的导师不止是技术导师,主要是能帮你解惑的导师。在那一年,我找过游戏开发部的经理聊过去大公司与在小公司的想法,与部门开发部经理聊过2次,一次是关于如何深入学习,一次是为了不虚度青春,去默默的去参与产品的开发。
在谈到大公司与小公司,自己其实也都经历过,能说到这个问题,主要是自己的一个梦想。大公司有大公司的好,不止公司制度,福利的完善,而且高手如云对自己在技术的广度、深度都有很好的帮助。在小公司你什么都要自己做,最后变成打杂的,很多面都没深入研究。在某一次的动车上很感慨的发了一微薄,关于选择平台的问题。其实每家公司都有各自的DNA。只要你能从这个平台成长,那选择就无悔。
跟开发部经理的聊天,现在逐步在实现了。2013年在干2011年想干的事。
自己在线下跟厦门的前端有多次的交流,总是希望尽自己的所能做一些能帮助正在迷茫的童鞋,少做一些弯路。这也是当初跟人做起厦门前端交流分享会的原因,走出4399去做能做的事。主要是想法、方法的改变。

5:产品的开发流程,facebook的流程是这样的
1)描绘远景,设置目标
2)收集想法并排出优先级
3)跨团队沟通
4)告知所有可能关心的人
5)设计产品
6)指定项目负责人
7)定期碰头会
8)了解进度,汇总报告
9)发布产品,监测数据
刚上面其实有说到这个一点,我现在所在的项目组的情况,现在项目组有做到上面的1,3,5,6,7,8.当然facebook的流程也不一定适合项目组,具体产品具体分析。
现在产品的需求是由交互,PM,运营综合提出的,在原型评审会上整个项目组的其余人才第一次见到要做产品的真面目,往往这个时候大家在评审的时候会提出各种问题,比如看见某区域空白很多,如果加上某个功能会效果会如何,往往通过拍脑袋或看到竞品上有某个功能加上,等等这些问题。在现在项目中每个人追求都想有项目参与感,可以在产品立项的时候让大家头脑风暴下如果我们要做这么一个产品,作为一个用户想在这个产品上获得什么。毕竟在每个人的心中都有一个产品。具体的可以详见我之前的两篇项目总结报告。第2点如果做的好,可以起到很好的作用,如产品的参与感,团队的凝聚力,大家一开始都是为了一个目标而努力。

这个里面做的最欠缺的部分应该是产品上线后的数据监控。到现在为止我比较深刻的是有一次的关于双蛋活动页的数据猜测与游戏中心的用户行为图,那个时候才比较去关注后台的数据与用户的行为轨迹。通过这种监控会发现或验证产品前期考虑的问题。举个例子,比如前端在写图文列表的模块的时候,往往都会给标题加链接,但通过轨迹图发现有按钮的地方,热度明显偏高,通过这种分析网站用户(小朋友)在操作的时候只对按钮的关注远远大于图片与纯文字。所以在针对图片设计的时候如果要提高转化率,就要对广告图片做一个针对性的设计,而不是摆两个图就好了。

6:Hack – A – Month计划
这个是我发生在我身边的同事,虽然我现在也是以SM的身份参与项目,跟这种方式很像。而且我也很乐意去享受这种改变的过程。这个主题主要是说一个优秀的员工如果在一家公司做就久了会产生疲惫感,为了避免人才流失,在公司为TA找到一个团队过去参与一个月的产品,如果表现好,则留在另一个团队中,不然就回到原来团队或理智。
我身边的两个同事早期就采用这种方式,以项目入驻的身份去参与产品,跟项目组坐在一起,在这过程中大家都表现很好。这种方式是很好,站在公司的角度去考虑人才的问题。

这本书里面还有提到黑客文化,团队的招聘与绩效考核,天使投资等这方面,我现在还有所欠缺,无法感怀深受,很多只停留在皮层上。写完这个感觉有点夸大自己了。。哈哈~~很多章节还是可以值得多读几次。

2013年3月2日 By 情封 分类: 随笔

这期项目是为了提供给小游戏或页游所有礼包集中展示的页面。让用户在游戏页面中更能方便的查找到所感兴趣的游戏礼包。特别针对页游,集合了游戏新手卡功能。这个就是这次的产品目的。

这次项目的团队是经历过新版积分商城磨合后又重组后的新团队,新增了一个PM童鞋跟一个测试童鞋,现在团队总共8个人。针对这次的项目,我总结如下:

1:原型评审的时候,团队童鞋最好都看过产品需求再进行讨论,而且做原型评审的时候,最好不要在去考虑这个页面上是否要加某某功能。只针对当前的原型稿进行讨论,最终确立方案。可能这次是历史遗留问题,导致在做原型评审了才写PRD。
如果PRD没置前,很多功能会遗漏,比如页游本身没提供礼包、页游页只显示礼包或新手卡等。尽量在PRD中详细,避免后期的功能修改。

2:这项目开发的模式会跟之前的稍微不一致。主要表现在前后端、UI设计三者并行。
1)由于这次项目的UI对积分商城的UI延续性很大,所以采取前端根据之前的UI进行重构,对需要设计的模块,设计师在参与设计。
2)在前端静态页未完成前,做好前端后数据接口的DEMO展示,后端根据功能模块做好数据准备,后期根据静态页嵌套就可以。
3)组件模式的确认。是采用原生的还是模拟的组件。
这些都可以在开发之前确认好,后期尽量少改动。这边的少改动不代表不变化。

3:团队协调工具的改变
由于对敏捷开发模式尝到甜头,这次继续沿用了scrum模式,但有稍微的不同。团队采用trello简化了白板跟贴纸,主要是利用trello来做任务记录,跟踪任务状态。其他的还是沟通为主。

4:涉及到跨部门合作的问题,各团队提供一个接口人负责沟通,避免多接口导致混乱的问题。这次我在实施的过程中有点问题,下次改进。

5:这次还有一个比较尴尬的事是:整个产品项目都准备上线,但是需求方对页游的UI产生变化,导致前端又重构50%。评估了前后端工作量以及后续的运营等工作,采取改动量最小的方案。避免这种的方式是在前期跟需求方沟通好,确定好产品的目标。

6:每一次的会议必须有结论,不然这个会议是无意义的。这个是页游UI的确认上,当初讨论了两个方案,没当天确认。

这个产品在3月1号正式发布,撒花~~

最后有一个想法:产品的功能,不止让PM或运营提出来。项目组的人都可以去想想,大家都可以集思广益后对功能讨论。最后PM确定产品的功能。

2013年2月24日 By 情封 分类: 随笔

总结的开头总是最难的,那就先介绍这个项目的开始、项目组的组成。

这个项目我接到的时候,是从2012年12月17号。这个时间点项目的交互设计,UI设计,前端重构基本都做完了。项目组的成员包括:1个交互设计师,3.5个后端开发,1.5个前端开发,1个UI设计师,1个测试,1个PM。一个项目团队的基本组成算是很完整的。预计项目上线时间2013年1月30号。

新版积分商城,经历过三周任务周期后,到2013年1月15号全部开发完毕,距离预订的上线时间还有15天,基本都是在测试修改,终于项目于2013年1月30号凌晨3点30分上线。

这个项目团队的工作模式是采取scrum敏捷开发的,最初的目的是通过这个产品来磨练团队的战斗力与凝聚力,最好把新版积分商城准时顺利上线。既然开发模式确认了,并且由我担任SM,并有一个外部团队的敏捷教练在做指导。由于之前对scrum的了解程度不深,并且刚开始大家对这个scrumn敏捷开发都比较反感。在刚开始执行scrum的时,遇到了各种问题,比较明显的是早上的站会(大家怎么站,说话怎么说等等问题),但那个时候我倒也很享受这种困难,遇到最大的问题就是团队沟通。前面提到过,由于产品的前期工作都完成了,剩下的工作基本都只有后端开发以及前后端的接口了,所以导致大家在讲的时候,很多人基本都没听或根本就没在意听别人的工作内容,这样一来而往基本坐在一起纯碎是一种形式了。这个沟通问题直到产品上线后,比之前有改善一点。

项目采用scrum敏捷开发,那这一套基本的流程都需要做,比如开任务拆分会,团队成员评估任务时间,并把任务写在卡片上贴在白板上(卡片是有区分颜色的,不同的颜色代表不同的任务状态。),以及卡片上位置的划分(backlog,优先级,具体的任务内容,评估时间)。这些都是任务开始前的前期准备工作。如果在任务的执行过程中发现前面在拆分任务的时候没考虑周到,必须用另一种颜色的卡布把它写上,并写好优先级。

前期的工作都准备好了,那就是执行了,由于我是SM,我会比较关注任务的状态,某个任务是在等待中、进行中、完成中、测试验收中。在这过程中,我纠结的是任务何时去移动任务的状态,是做完一个就去移还是等第二天开站会的时候去移,这点做到后面我就不纠结了,不管是白猫黑猫,能捉老鼠就是好猫。期间我做事的方式都很谨慎,因为有人在关注你,我就很担心怕出错,放不开手脚,那时候压力好大,但有压力伴随这动力。随着任务的进行,逐渐的没前期刚开始那么紧张了,因为不想戴着镣铐跳舞。

这样完成一个backlog要跟PO、项目团队成员汇报下产品成果。如何演示,怎么演示,要演示哪些这些都是要考虑的。经历过这种任务拆分,一周后阶段性的产品演示,有发现产品的不足,或对这阶段产品需求的改变可以立马提出来,演示后有两天的时间可以调整产品,优化代码等。这种等到整体的项目完成,QA的工作量就不会那么重,避免测试的不完整。

整个项目一直用这种循环开发,在一定程度上可以对项目组的所有人来说都有成就感,毕竟产品上线了,一段时间没白费。

通过这个项目也实现了一个多年的心愿,就是在公司发布产品。在1月31凌晨发布的时候,体会到整个项目组的氛围非常好。大家都在为这个项目的上线卯足了劲,整个发布的过程体会到了由轻松,紧张,亢奋,高兴的心情。

最后提一点就是项目需求任务的问题,各个童鞋往往都只关注前台展示,很多都忽略了后台管理,很多时候也没想的很细,对需求的了解不清楚导致没有应急方案。这种对项目产品来说缺少了全面考虑的经验。还有一点是对图片的审查不严格,导致广告图片一张200KB都上传,严重影响了前端的性能。

最后也警示了自己,一款产品的上线,也意味着产品项目才刚刚开始,后续的一序列问题才是重点,上线后用户的反应,整个项目的重点核心有没出问题。

通过这次的项目,自己也懂了很多关于产品设计细节的问题,在做产品前要考虑全面一点。对项目流程的优化思考,在下一次的项目管理中,总结这次的问题,在下次做深度优化。对敏捷开发又有一次体验,在这过程中,重点发现白板的重要性,对着敏捷,可以取之精华,去之糟粕。任务的拆分,确立完成的任务时间,任务的责任人。对整体的项目进度有一定的把控,不用每次去监督开发进度。

参与项目的过程,作为SM,也发现自己的不足,对发现影响项目的童鞋,自己碍于面子没立即提出来。整个团队对时间的管理,自我管理的认识还不是很好。我一直都很崇尚自我管理的。但这种状态往往要求过高,不可能每个人都有很强的自我管理。这次的团队的磨合总体来说还是不错的,各个童鞋参与项目感也提高了不少。

2012年11月22日 By 情封 分类: 随笔

这个问题场景很常见,一个DIV元素背景图片100%平铺,内容限制宽度,当浏览器窗口缩小时,会出现横向滚动条。DIV元素右侧背景缺失。具体见DEMO

以往的经验,会在.wrapper里面也再次平铺背景图。

.wrap{background:background:url(http://s3.img4399.com/m/images/global/mod_public.png) repeat-x 0 -66px;}

今天的解决方法是:给.topbar新增一个最小宽度值,由于IE6不识别min-width,兼容性设置width:100%

.topbar{min-width:1024px;width:100%;}

这种bug很隐蔽,前端测试时,很多前端童鞋没测试到,往往只过了一遍IE系列的,比如页面是否错位等一般常规性的bug.这种隐蔽的bug,越在去在意。

2012年11月13日 By 情封 分类: HTML/CSS

情景:今天测试期刊项目中,订阅邮箱的按钮时,在IE8或360时发现当按钮处于active状态时,会出现left,top会偏移1像素的情况。由于Goole最近网络不稳定,在度娘中查找了半天没一个资源,很少有人讨论这个,最后还是要去Google中找最靠谱。

在这里看到了解决方法:IE8 button BUG

这个bug出现在

    <button>click me</button>
    <input type="button|submitimage" value=""/>

文章中的bug是在button中,所以提供了两种解决方法:

1:新增标签的方式,在button中新增span.

文中也提到这种解决方式也会有很多问题。

1)新增了冗余span标签

2)不能在input[type="submit|button|image"]中使用,因为它们不能含有子元素。

3)需要在IE8中为元素进行绝对定位。

所以作者不太推荐这种解决方式。

2:通过JS能解决这个问题

3:通过CSS来解决。

在IE8版本中,微软新增了几个CSS扩展属性。这些扩展属性都能在IE8中工作,但是在IE8之前的版本或者非IE浏览器中不能用。

解决方式:

Button:active{
    -ms-background-position-x:xx;
    -ms-background-position-y:yy;
}

这个值要比常态值小1.

IE8跟vista都是被微软抛弃的孩子啊~~~

2012年11月10日 By 情封 分类: 随笔

第一次在周末举行交流会,前面三期都是在工作日晚上举办。感谢跋山涉水来的同学,因为举办一次真的很难得。毕竟在厦门这地方,前端还不是真的很多。

进入主题吧。今天有两个话题,第一个主题是郑易同学分享的<<让我们谈谈webGL>>,第二个是来自35互联的鬼分享的鬼群作品秀。

首先来自集美大学航海专业的郑易分享的webGL,一看到这主题就很有深度的,首先先演示了现有利用webGL的一些产品,开发3D的好工具。比如记得有红警,星际。DEMO让我们对webGL有一定的认识,在整个分享会中主要涉及到openGL,webGL的关系,简单介绍了three.js框架,以及各个浏览器对webGL的支持情况还有就是webGL的应用的场景,比如电商的产品展示,游戏,行业内的运用等等。这个主题让我印象比较深刻的是把开发的过程比喻做拍剧,开发者自己当导演。在开发的过程中,把需要的各种资源当作舞美,灯光,摄影等等,比喻蛮贴切的。webGL让我想起来自友窝网的少凯上一次展示的关于房产户型的展示,这个可以联系起来开发。

其次,鬼在交流会上分享了传说中全国前端最活跃的群所收集的一些资料,比如有前端书籍,前端的作品DEMO。在介绍前端书籍时,在PPT中有一个扩展,或总结。让有更多的人来参与,我也对其中所看过或了解的书籍进行一定的补充,能让更多的前端了解。

这次的分享会后,我也分享了最近的一个想法,构建基础前端代码模式。把常见的UI模式整理成前端模块,长期更新与维护,避免每次编写相同的代码。每个项目基于基础前端代码进行扩展或定制,提高项目的代码质量。现在这个想法已经在这次的my首页重构中进行运用,希望能居于这个进行详细的分享。

基于厦门现在的前端情况,在每个公司都不会有很多的前端开发人员,基本都只有一两个前端,在开阔眼界上,建议还是多走出公司去跟外面的公司多交流分享。这是我去年来4399后所认定的,多走出去交流分享。不管多高端的内容还是工作中的问题都可以拿出来分享。

后来由于时间的关系,鬼的分享进行一半,还有一半留到下一期的时候在分享。

在此感谢厦门4399提供的场地。

2012年11月4日 By 情封 分类: 随笔

这篇源于这周回家的动车上所思考的

1:关于模块化。

让我想起kejun在新浪微博上发出的那段通用的模块代码。

从我的角度上去看这个模块化。前端这几年的发展可以用迅猛来形容。09年的时候就有制作项目的模块的概念。那时候的模块往往都是项目中复用性比较高模块才抽离出来的。当然这个要整个项目中都要理解模块的概念,涉及到设计,产品。那个时候的理解只是模块复用。

最近一两年,比较关注模块化。模块化分JS,CSS,产品功能。

从某个模块上看,前端关注的是表现,行为,结构。前端应该看的是骨架,不管它表现如何,你要能一眼看透,分析型的相通点。骨架的代码是一样的,只做稍微增改或删。在表现上可以通过继承的方式来表达。JS的按需加载在一定程度的模块化开发上表现得淋漓尽致。比如组件的开发。

从整个项目上看,不同的页面或项目,很多时候都在编写一样或类似的代码。这样不会烦吗?先不说每次写完总结的道理。只能去想办法去改进这种情况,想到的一种模式是:做代码片段,存入插件。这样就能快速开发,而且还能保证一定的质量。

对项目的页面进行分析页面,拆分项目相同模块的html模板,通过include进行加载。并加载相应的css,js.有时候不同模块,但内容上会类似或一样,拆分出模块会节省不少的开发时间。

通过上述出现的问题,去做一个通用的前端基础模块代码(或叫代码片段),当然要持续的更新与维护。总结归纳前端的模块表现形式,分析最优代码模式,形成积累沉淀。让后续的团队成员能快速的开发出代码质量有保证的页面。

从产品角度上看,现在互联网上已经存在一些这种功能模块的内容,比如JiaThis,友言社会化评论系统(不考虑数据安全性)。预想以后的产品,就通过加载不同的模块功能就可以了实现了。

2:关于团队。

在新浪微薄上发出一条,随着团队人员的增加,有的人会越来越忙,有的人会越来越闲的微薄,让我回想了很多。

1:有的人会做事,有的人能做事,有的人能(会)找事做。

所处的位置:正确做事与做正确的事。

现在会去观察团队中人的个性,去了解他们各自适合做什么。把沙子放在合适的位置就是金子。

1)会做事的人,他会懂得去思考总结问题,会想去“偷懒”。各种奇淫技巧,结果往往能超出你的预期。(鼓励这种,并开放绿灯。)

2)能做事的人。把一件事情安排给TA做,你会很放心,TA肯定能把事情做完,但过程中会跟一头驴似的,只埋头苦干但不懂去总结,如何去突破,得过且过。(适合无关痛痒的工作,只要能完成就好。看自己的认识情况。)

3)会找事做的人。永远不满足现有的状态,各种学习激情,各种折腾。面广,但容易如入博而不精。(鼓励,但要适当的提醒。)

不是说非得把人进行分类,人多了总会产生对比。合适的人做合适的事。

2:会思考,会总结。

现在对这两个我感受很深,因为我现在也是处于三国战乱的时期,看了很多,懂了很多,但一定程度上没能很好的总结,总感觉那些都不是你的。思考总结就有沉淀,那就是你的知识了。

现在要静下心来,抬头看路,低头编码。说的容易,做起来难啊。心灵鸡汤谁都知道,但要能克服自己。要学会自我管理。

2012年10月17日 By 情封 分类: 随笔

还在为写静态页的时候,各种复制代码苦恼吗?还在为写很多重复的结构苦恼吗?还听见程序员抱怨一个页面代码过大的声音吗?偷偷在角落画圈圈BS你吗?现在有了include,一切毫无压力。。

曾经在ND的时候,有过那么一段时间在做前端页面的时候,分离模块为文件,整个页面由模块文件拼装,这样很简单,文件空间减少。对前端开发效率还是可以有所提高的。

最近平台的前端模块开发进入尾声,让我又想起这个页面拼装的手法,果断配置apache,采用include功能,这个跟ND的模式一样,但实施手法不一样吧。

现在就apache的配置稍微说一下

由于apache默认不支持IIS,但还是可以通过修改配置文件,搜索AddType text/html .shtml的位置,打开以下注释,由于团队做的静态页的扩展名都是html的,所以只需要在以下两行中加上.html

AddType text/html .shtml  .html
AddOutputFilter INCLUDES .shtml .html

开启这个功能还不够,还需要在找到 Options Indexes FollowSymLinks ,在其后添加上Includes.

这样做完就可以在apache中支持include.

在静态文件中,引入相应模板也很简单,只需要

这种对很多重复的模块代码还是有相当多的好处,节省空间,减少文件大小。

=======================================

这种只是一种方式或方法,就是为了节省劳动,缩短流程。在想这个的时候,有跟开发经理聊过,由于后台系统复杂,成本过高,导致不能一条线很完整的执行下去。只能在前端上YY了。。不然跑起来还是爽歪歪。虽然这种只是一小步,可真正流程用起来还是能一定一定的时间问题。

广告下:自己整理的一份鸡汤今天上线了,IE系浏览器不支持,完全只往高端的浏览器跑,纯实验的一个小APP,狂点击这个点我

/**********************2013.02.21**********************************/
注意:用include命令包含页面。include元素能按file属性或virtual属性判断应该包含的文件。file属性是一个相对于当前目录的文件路径,即不能是一个绝对路径(以”/”开头)或包含”../”的路径。virtual属性可能更有用,它是一个相对于被提供的文档的URL ,可以以”/”开头,但必须与被提供的文档位于同一服务器上。

<!--#include virtual="/footer.html" -->
2012年10月10日 By 情封 分类: 随笔

先分享下公司内部分享的一篇关于日报周报的邮件:

一、 关于写日报的目的:
日报的目的永远不应该是仅仅为了汇报工作。这一点希望大家能够真正体会到。
日报首先应该是写给你自己看的,其次应该是可以给同事和新人分享的,最 后才应该是写给你的主管看的。
二、 关于日报写作规范:
好的日报应该是内外兼修的:
(一) 外
1、 阅读方便:日报请不要用附件形式方式;(这一点是刚入职的新人偶尔会犯的错误)
2、 整洁美观:字体不宜过大或过小,排版要整齐,颜色不宜超过3种;
3、 条理清晰:将日报内容合理分块,每一块又有1,2,3,4……各级标题清晰明了;
4、 重点突出:对于大标题或者是重点要加粗或者标红;
(一些你希望你的主管注意的事项,或者是希望获得主管帮助的地方,也可以适当标红)
5、 总分结构:推荐使用总分结构,每一段的标题或者是第一句话是问题的核心概括,后面内容再具体阐述。
(二) 内
1、 逻辑性:表述以及排序等满足基本的逻辑关系;
2、 言之有物:少说空话虚话,少说没用的形容词,少说“大概”“也许”“可能”“一些”之类的词语;
3、 多发现问题:要善于发现工作中的问题和错误;
4、 多分析:对问题一定要有分析,包括现象、原因、影响等;
5、 重在解决问题:有问题就一定要有解决方案,不怕说错,但一定要有建议;
6、 深入:如果不具备看问题深入的能力,那就想办法把每一个问题拆分细了,把每一个细点都总结清楚。

三、 关于主管的日报:
主管的工作是管人+理事。这就意味着主管的日报不应该只有工作内容本身的总结,
而应该包括或者说更多的关注于对人员情况的总结分析。
四、 关于周报:
周报是对一周工作的总结反思,需求同日报无太大差异。
不过大家可以注意一下,周六不用单独写日报,周六的工作内容可以在周报中一起体现。

=============================================分割线==================================
常见的一种情况是日报,很多人觉得一天做下来会没事可写,或只是简单的把今天做什么罗列一下,
这样其实是没多大意义的。
比如,某同事今天画了一头驴,当天日报这样写,绘制驴,就没然后了。
这种就是过于简单,完全可以多写一些,比如画驴到现在,花了多少时间,总进度多少。
个人觉得这样还可以数据可视化,比较有说服力。
当然这样对自己来说,渐渐培养对任务的时间管理,对任务时间评估。
有时候可以多换位思考,利人利己啊
对周报,我个人现在是分项目总结,列出这个项目的123来,并写上进度,程度,是否上线,如果上线附上线上地址。
项目中的123条目,一般都是有行为状态的,这个是修改,还是新增状态,并进行总结归纳。
最后写上一些总结,整个组所出的问题,以便下次改正。