Google Map 和 Bootstrap 冲突的地方

今天遇到一个诡异的问题(其实以前就遇到了,被我想办法绕开了):

在Google Map里添加一个Marker,如果Marker能够被拖动(draggable),就显示不正常。表现为一个1/3宽度的图标带2个阴影,拖动后变成1/4大小的图标。

反复尝试都无法解决,去查看了Gmap的源码,发现大家是一样的,也没能解决。最后还是Google之!

原来是Bootstrap的问题,它为了不让图片撑开容器,在样式里规定img { max-width: 100%};,就是这句话导致图片被压缩(应该是默认占据更宽的位置,好显示阴影之类的东西)。

修改我的样式,增加.map-container img { max-width: none; }之后,就一切正常了。

Backbone.js笔记

关于Backbone的笔记。

关于事件

  • 使用Backbone里,我们可以继承Backbone.View,并且侦听UI事件。这些操作是通过jQuery或者Zepto的事件委托实现的,所以很重要的一点就是:这些事件都是UI事件,loaderror这些事件是无法在events属性里注册并被侦听到的。
  • 因为是托管的事件,事件处理函数最好用event.currentTarget来寻到节点
  • model的事件都会被collection转发,所以可以直接侦听collection;同理,除非remove并等待垃圾回收的model,也不应简单的调用off(),因为这会使collection没法侦听到事件,漏掉一些处理。

路由解析规则

这点文档中说得不算太详尽,我摸索如下:

  1. 路径分析以#/为起始,所以链接应该如#/app/add
  2. /是很重要的分隔符,末尾的/会被认为有下一级参数,比如app/list/的规则就不适用于http://domain.com/#/app/list这样的路径
  3. 规则只匹配一次,不会多次执行
  4. 刷新页面的方法:
    Backbone.history.loadUrl(Backbone.history.fragment);

其它关于Backbone.js的文章

Backbone.js经验两则

重写Backbone.js的加载动作

使用Ant编译Web应用

前端项目可能碰到两个很大的问题:代码开放,用户可以直接读代码;代码下载需要占用带宽。这两个问题用ant编译可以在很大程度上得到解决。

开发只是万里长征走完前半截,测试部署也是很重要的环节。

尤其是,前端面临着两个很大的问题:

  1. 前端代码是开放的,用户随时可以直接读代码
  2. 代码下载到用户电脑上运行,需要占用带宽

所以如果我们可以先压缩、混淆代码,再部署给用户使用,就可以大大改善这种情况。这个时候,ant是不二的选择(因为我只会ant……)。

关于Ant

下载:http://ant.apache.org/bindownload.cgi

手册:http://ant.apache.org/manual/index.html

继续阅读“使用Ant编译Web应用”

Mobile Web开发笔记

这里记录使用Phonegap开发移动应用期间发现的一些注意事项。

这里记录使用Phonegap开发移动应用期间发现。

性能

使用jQuery托管事件对阻止冒泡的影响

表现

解决 iOS webkit 使用CSS动画时闪烁的问题

CSS 兼容性

CSS 属性 iOS Android IE 其它
border-radius 3.x -webkit- Firefox 3.6- -moz-
Safari 4- -webkit-
box-shadow 2.3 -webkit- Safari 5- -webkit-

网摘

Developing Better PhoneGap Apps: Float Mobile Learning

重点包括

  1. 使用tap取代click(这点我还需要进一步测试,我发现zepto+phonegap没法捕获tap事件,不知道是我不是敲键盘的姿势不对)
  2. 使用css动画取代js动画

随记

  1. “click”和“tap“不是一回事儿,“click”会延迟300~400ms才处理,时间上会接近taphold之类的事件,“tap”更快
  2. 给元素加上:active伪类,可以给用户更快的反馈
  3. 调试不太容易,debug.phonegap.com似乎已经关了,得想办法把自己的weinre服务搭起来。暂时可以在js里写console.log(),接受一个参数,会在log cat输出。

招人了!招前端和设计了!

我最近在和朋友创业,方向是移动互联网,具体内容包括广告和媒体工具。现在我们需要前端和设计,诚邀天下才士加盟。

我最近在和朋友创业,方向是移动互联网,具体内容包括广告和媒体工具。现在我们需要前端和设计,诚邀天下才士加盟。

公司发展成什么样子,我不敢保证;在融资成立新公司之前,工资可能也不是很高。不过如果你加入我们,我们可以一起改变世界,我还可以保证你学到很多技术、累积很多经验:

  1. 响应式开发,适配市面上绝大部分设备
  2. CSS动画
  3. 使用最新的HTML5 File API进行文件操作
  4. 借助Backbone建立强壮的程序架构
  5. 使用Canvas进行图形开发
  6. 使用Git进行代码管理
  7. 使用Ant发布项目
  8. 使用Phonegap开发移动应用
  9. 使用HTML5、Flash实现几乎任何需求
  10. 坚持代码Review和重构
  11. 优秀的代码习惯,清晰明确的编码规范
  12. 测试驱动,持续化集成
  13. 寻找、使用各种开源代码增强产品
  14. 全面使用各种开发工具加速开发、调试

总之,我们这个项目绝不是由细碎繁杂的低端体力劳动堆砌出来的,相反,其中会集成众多先进技术,会给开发者带来大量的经验和成就感!而且我会倾囊相授,无论产品最终非常成功或者只是成功,作为一名前端开发,拥有以上技能,这几年就不愁吃穿了。

我对应聘者没有过多的经验技能要求,我只希望对方有想法、有冲劲、肯下功夫。我想信只要努力,经验技能都能迅速提升上来。

很遗憾我无法对设计师做出同样多的承诺,不过我们也会尽力而为,保障收入、保障成长空间。

感兴趣的同学,欢迎用各种方式联系我。我的邮箱:meathill@foxmail.com

自己是自己最大的敌人

近来创业, 身兼产品经理和程序开发,结果自己跟自己打架的厉害。

近来创业, 身兼产品经理和程序开发,结果自己跟自己打架的厉害。

有时候一个功能实现了,以产品经理的身份看看,觉得效果一般,用户可能会不爽;再切换到开发的角度,发现要改进这个功能,要么给自己挖坑,要么就得重构。如是自己跟自己反复打架,项目进度时快时慢。

果然自己才是自己最大的敌人啊~~

我在某公司那些年-外游半年

从某公司离职后,我到一家外包公司工作了半年。新工作并没有像我想象的那样,让我稳稳当当工作下去,反而很多时候让我不安地担忧未来的日子。终于,原来的领导打电话招我回去,我很快就同意了。

上篇日志带来了我完全没预料到的影响。眼看临近年末,我也不想动摇军心——我并不记恨这家公司,相反,我对它还抱有很深厚的感情——所以我就没往下写。如今过完年,再看已尘埃落定,该走的还是要走,能留的自然会留,我的文章不会把谁催走,停笔也不会把谁留下——公司领导那么直接的手段都做不到的事情,我这个远在几十里之外的人怎么做到呢?

书接上回。

继续阅读“我在某公司那些年-外游半年”

吐槽Mac

我在知乎里回答了个问题,顺便转载回来。

全主观不负责吐槽Mac。

为了能开发iOS app,专门买了一台Mac mini,想着顺便能体验下Mac OS之优雅。结果把我恶心坏了。
先是慢,不说了,慢的跟屎一样。还是i5的机器,我i3的本子跑起win8来呼呼的。
快捷键不兼容,这是习惯问题,先不说了。
字小的跟屎一样,这是为了照顾谁?我双5.2的眼睛,我觉得那些戴着近视镜高喊Mac优雅的人真可怜。
装软件得把软件拖到应用文件夹里,我想问问这是哪个设计师在生活中遇到的真实体验。
装软件的第二个问题是得通过AppStore装,但是机器自带系统不是10.7,不能用AppStore,这奇葩的设计绝逼优雅,我想不出第二个词来形容。
好不容易升级了系统,开始装XCode,开始半天没动静,鼠标放到上面一无进度二无数值,我也不知道是我们家网慢还是干脆已经死了。
等着下载的间隙想在qq上跟人闲聊几句消磨时间,可~这~字~出~的~也~太~慢~了~吧。

总之我没觉得Mac OS有啥优雅,或者有啥“生活式”。我甚至觉得,鼓吹MacOS好是一种反人类行为。
也许我需要一台顶配的机器来改变下观点。

说到顶配,苹果那帮人太黑了,一根线好几百……

HTML5的File API应用

长文一篇,分享我最近使用HTML5 File API的经验。

HTML5新增了很多特性,其中File API是非常重要的部分。在肉大师中,我大量使用了HTML5的文件API,这样一来可以给予用户近乎桌面软件的体验,二来还能减少服务器和带宽的消耗。今天终于把最后几个问题解决了,在这里总结下HTML5 File API的使用。

随着用的越来越多,发现自己其实搞混了“File API和FileSystem API”两个东西。而且类写的也有问题。等到有空的时候把这篇文章重写一下好了。(2012-09-13)

用途

在W3C页面上,列出了File API可能用到的场合(以下为意译,可能有所偏颇,欢迎对比原文阅读):

  1. 断点续传
    • 上传时,先把目标文件复制到本地沙箱,然后分解逐块上传
    • 浏览器崩溃或者网络中断也没关系,因为恢复后可以续传
  2. 需要大量媒体素材的应用,比如视频游戏
    • 下载压缩包,在本地解压,就能恢复之前目录结构
    • 跨平台
    • 通过渐进式下载,进入新关卡或者开启新功能均无需等待,因为玩的时候所需素材已经通过后台下载完成了
    • 从本地缓存中直接读取素材,速度飞快
    • 二进制文件也不在话下
    • 使用压缩包可以大大减轻带宽和服务器消耗,也避免了频繁下载碎片文件带来的检索问题
  3. 离线图片/音频编辑器通
    • 不怕频繁读写大量数据
    • 只想重写文件的某些部分也能做到(比如修改ID3或者EXIF信息)
    • 创建目录组织项目后用起来舒服多了
    • 编辑完的文件还能被iTunes、Picasa之类的本地应用访问
  4. 离线视频播放器
    • 下载超过1G的大文件,将来想看再看
    • 可以在不同时间点间来回跳转播放
    • 能够给Video标签提供URL
    • 即便片子还没下完,也能把下载到的部分先睹为快
    • 还能任意截取一段视频交给Video标签播放
  5. 离线邮件客户端
    • 下载保存附件到本地自不必说
    • 断网的情况下,可以缓存用户要上传的附件,以后再上传
    • 需要时可以列出缓存里的附件,通过缩略图显示,预览后上传
    • 能像正常服务器那样触发标准的下载动作
    • 不仅能使用XHR一次性上传全部内容,还可以把邮件和附件拆解成小块依次发送

听起来都是些令人振奋的功能,实际用起来还是要踩点坑。下面就把我的经验分享一下。

继续阅读“HTML5的File API应用”