脱掉衣服看身材,裸节又来了
发表时间: April 8, 2010 分类: WebBuild 13条评论
发表时间: April 8, 2010 分类: WebBuild 13条评论
发表时间: March 29, 2010 分类: WebBuild 2条评论
前天参加了w3ctech第六期的WEB标准化交流会,本期交流会的主题是:前端开发在研发流程中与其他岗位协作效率的提升。会上所有与会者对此话题都发表了自己的看法,也借这个机会了解了很多其他兄弟团队协作项目开发的经验。同时会上其他非前端职位的同学也发表了很多很有参考意义的看法。
随着交流会发表意见的同学越来越多,可以发现最终关键词一致性的落在了“沟通”上。崔凯通过“请吃饭”这一最明了的例子说明了良好的沟通方式可以有效解决跨团队协作中遇到的“困难”。月影在接下来两杯水的例子中用带有哲学又易懂的方式解释了如何从本质上解决跨部门协作难题,那就是我们放开各自心中的“成见”,通过换位思考再大家站到同一个视线上来看问题。如果大家还记得彪叔《一专多长》的PPT的话,应该对引言中法拉利车队的故事印象深刻吧?
到场的同学都觉得前端需要和很多部门打交道,认为前端是“最累”的部门。这一点可能是因为到会者中大部分职业是前端开发的缘故。其实,每个部门都是“最累”的,我们需要与UE打交道,同样UE需要与PM与我们等部门打交道,我们需要和RD、QA、OP打交道,同样RD需要与PM与我们与QA与OP等部门打交道。每个部门都有需要协同合作的人和部门。当我们抱怨UE生气我们页面切出来与UE图相差的时候其实我们可以换位想想当RD将我们的HTML嵌套得“乱七八糟”的时候我们是多么生气的。
我相信在任何一家公司,所有部门的人都是在干同一件事情,那就是将这个项目这个产品做好,大家将自己各自杯子里的水倒干,拥有同样一份事业心将杯子叠到同样一个方向同一个目标。我们可以思考月影在会上提出的问题:你将你做的事情怎样看待?工作、职业还是事业?如果你不思考这个问题,那么工作中“被”遇到的问题将越来越多。相反,你就会知道你要做到什么程度会有成就感?什么时候要换家公司为互联网做贡献了。
这次交流会回来一直很有感想,因为自己所在的部门最近也遇到了一点事情。但是面对外界的质疑和猜想我们依旧保留那份创业心凝聚在一起,很高兴能和这样一群拥有事业心的同事并肩奋斗。
最后,以个人情感并代整个交流会组委会感谢腾讯北京公司提供的场地、茶水和礼品,感谢易联主机CEO tesion提供的奖品,感谢winter和kejun分享的PPT,感谢所有到会的同学和所有关注w3ctech的同学。(p.s:特别赞扬在整个交流会中站着做记录的我们的场记吕婷MM,大家给点掌声!)
发表时间: March 8, 2010 分类: WebBuild 5条评论
今天要说一个跨省的好东西玩玩。
那就是geolocation,W3C对geolocation的解释是“defines an API that provides scripted access to geographical location information associated with the hosting device”。Firefox从3.5起就支持geolocation了,习惯赶时髦的opera也发布了一个支持geolocation的版本,几天前Chrome dev 5也正式支持geolocation了。如果你的浏览器被鄙视了也可以使用google gears的Geolocation API 曲线救国来玩(关于这一点请参考JerryQu同学早一段时间写的文章)。于是记录和朋友们分享下。
如果你有兴趣可以使用上面提到的浏览器点击这里看个简单的demo。
简单说下前端的实现吧,主要代码如下:
function displayPosition(position) {
//得到两个值:position.coords.longitude(经度)、position.coords.latitude(维度)。
/*任意鞣虐得到的经纬度信息来展示你想要的样子吧。
*/
}
navigator.geolocation.getCurrentPosition(displayPosition);
geolocation的原理就是收集你上网的终端设备的某些信息发送到特定的服务接口用来查询以获得你的地理信息,如果你是使用的是无线wifi上网的方式,发送的信息如JerryQu提到的一样,大致如下(Firefox下的抓包):
post http://www.google.com/loc/json
post_data='{"version":"1.1.0",
"request_address":true,
"access_token":"2:OLzIuqa-P8tZYOpu:Gu-LV8OcMFK28CVE",
"wifi_towers":[
{
"mac_address":"00-23-eb-b7-ef-70",
"ssid":"abc","signal_strength":-45
},
{
"mac_address":"00-23-eb-b7-ef-72",
"ssid":"abc_Guest","signal_strength":-48
}
]
}=';
返回的信息类似如下(可以查看我通过curl脚本模拟的数据 http://www.ivershuo.com/did/geolocation/loc.php):
{
"location":
{
"latitude":40.0475799,
"longitude":116.2947221,
"address":{
"country":"China",
"country_code":"CN",
"region":"Beijing",
"city":"Beijing",
"street":"Tangjialing Rd"
},
"accuracy":278.0
}
}
可以发现firefox也是使用的google的loc接口,如果你提供的access_token值为空或者是错误的在respone的时候会给你返回一个正确的access_token(该值是2周有效的)。wifi_towers包含了你的wifi信息数组用来判断你离热点们(?)的距离等信息。如果你使用的是有线上网的方式会发现传送的wifi_towers数组是空的,但是也会返回地理位置的值,应该是通过ip来返回的(因为我使用服务器脚本去请求该接口的时候返回的是服务器所在地的地理信息),所以偏差很大。现在还不知道是不是可以传送gps数据,有条件的同学可以试试在android手机上验证可以使用gps数据。
不过照前面的demo来看,就算是wifi的方式得到的位置信息还是有一定的偏差(这中间也有不同地图服务的定位信息的偏差),但是比ip获得的位置已经精确很多了。对位置信息精确度教高的web应用可以试点应用玩玩。
回到开头的那句话,大家不要担心跨省,因为浏览器在发送这个信息的时候会先要获得你的授权的。
p.s1:要使用geolocation:Firefox浏览器需要保证about:config中geo.enabled的值为true,chrome dev需要带参数“"--enable-geolocation"”启动。
p.s2:如果你也想构造数据请求google的loc接口,需要保证数据是以application/json的格式请求的。
发表时间: December 27, 2009 分类: WebBuild 1条评论
昨天参加第三届WEB标准化交流会,讨论的话题是页面重构的合理化。会上大家都讨论得很热烈,我也在这里做下个人的总结吧。
WEB标准化交流会在北京已经成功举办了三届,首先感谢这三期以来积极参与讨论的参会者,感谢身边网和百度UXday的场地支持,感谢W3C中国、简单网、buleidea、谷歌中国软件部、百度FE及WED团队的支持。我们也希望更多的前端爱好者参与到讨论会中来,共同讨论和推广WEB标准。
好了,回到昨天的讨论的话题吧。先从DTD开始,DTD其实主要是告诉终端你的doc是什么type的。就好像在入校之前你会告诉学校你的性别以方便安排你到男宿舍还是女宿舍一样,不写DTD就留给了浏览器一个“猜”的任务,这样其实是比较危险的,很多情况下你不知道浏览器会怎样来处理。假如春哥入学不写明性别,就可能有分错宿舍的危险。接下来讨论的是通过W3C验证的必要性,大部分同学观点比较明确和统一:通过W3C验证至少可以去除一些基础的嵌套错误。就像是照镜子吧,脸上有个脏的地方可以通过镜子照出来,有没有前列腺炎是不能照镜子照出来的,所以镜子是必要的,但是镜子不能反映所有的问题。这就是为什么会有医生为什么会有专业的前端开发者。语义化及命名规范以及由此衍生的microformats和RDFa等知识好像在昨天的参会者中研究的同学并不是很多,记得原先初中政治课中有说道规则是为了更大方面的自由。第二期交流会的时候就有提到行业规范化的东西、后来我和月影回来一直觉得可以推动这方面的工作,这个真的还是挺有意义的。社会主义是有可能实现的,关键是不能做空想社会主义也不能在实现的时候变质,我们的国家已经走了中国特色,我们的网页不能再走中国特色,如果你和我一样觉得互联网是当今世界社会主义最好的呈现的话。如果能理解就不会出现div和ul标签泛滥的情况,扯远了~。微格式和twiter的@符的马太效应使我们想到可以做和应该做的还有很多。关于标签更大语义化的工作W3C也在努力,大家应该可以在HTML5中感受到,就有同学提到了实际应用中经常遇到不知道该选择什么样的标签的问题,这也确实是现阶段HTML标签存在的一个问题。当网页内容越来越“丰富”的时候问题将会更加明显化,最开始的网页不是也不支持图片?现在的网页上img标签已经遍地都是了。不过世间万物可以归宗两象五行,又但是W3C曾有想将图片归用object标签来描述是合理的么?这方面可以思考的还有很多。会上有很多同学不太熟悉属性语义和属性值语义方面的东西,特发几个传送门:语义网、microformats.org、RDFa。
交流会的第二个讨论话题是样式合理化的问题。在实际应用中会分项目的性质来把不同的组织,一般小的个人网站就一个样式文件就行了,节省请求。对于具体的应用项目可以分离公共样式+项目特定样式的形式组织,大家的意见也都比较统一。讨论期间rekey有提到公用样式后期的特殊化的问题,相信这也是很多页面开发者遇到的实际问题。其实克军在12号的webrebuild要也有讲到这个问题,关于模块化的组织。核心还是在页面架构方面,好的架构可复用性和单独拓展性都是需要考虑到的,当然在实际项目中还要评估为什么以前的统一模块中有一个或几个要单独加/减其他东西。能不能实现改的功能是我们在架构时候需要考虑的,为什么需要改是产品和设计和我们协作的问题,有一个前期的一致规范是好的。克军上次也有提到接下来HTML要走一段路了,关于模块化方面的东西个人觉得某些方面是可以借鉴js框架的思维。HTML是洋葱的核心(?,见克军ppt),是牵一发动全身的东西,这么重要的东西不能三思而后行么?
第三个讨论话题是素材合理性,更多的涉及到了第一期讨论会网站重构中的文件组织和第二期讨论会CSS Sprites方面的知识。讨论到了图片格式的选择,结论还是大部分选择png-8、gif、jpg这三种格式,按需所取。比较理想的是期间讨论了图片压缩的话题,本来我们上周自己的组内也讨论了这个话题,两次讨论得到的结论都是压缩无止境,呵呵。其实素材管理很有讨论性的是图片管理和缓存方面的东西,我也很想听到各个公司对于这方面的实战经验,因为到会的有谷歌、微软、新浪、百度等大公司的前端,各个公司的部署肯定有很多不同,很有交流讨论价值,不过由于时间原因还是没来得及讨论。
很高兴在twitter直播上码头同学有提到“认为要做好页面重构的合理化最重要的是前期项目规划的合理化”。这其实是我一直在等待的答案。建筑结构工程师和只会砌墙(切图)的建筑工人,你自己怎样定位?知道这一点你就知道以怎样的态度来思考你在干的事情。
期待下一次的交流会,如果你也一样的话,请留意w3ctech官方网站,我们将在每月的最后一个礼拜的周六聚首讨论。更多信息可以follow我们的twitter:http://twitter.com/w3ctech或加入QQ群:46077068。
页码:
© 2005-2010 IVershuo.com Some Rights Reserved : Creative Commons License.
Powered by : Typecho , Theme By : IVershuo
备你妈个鸟案
Valid W3C Unicorn