作者: meathill

  • 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.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应用

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

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

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

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

    关于Ant

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

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

    (更多…)

  • Mobile Web开发笔记

    Mobile Web开发笔记

    这里记录使用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

  • 自己是自己最大的敌人

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

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

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

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

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

    书接上回。

    (更多…)

  • Android笔记

    这篇文章会记录我在Android开发过程中积累的各种知识和技巧。
    (更多…)

  • 吐槽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一次性上传全部内容,还可以把邮件和附件拆解成小块依次发送

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

    (更多…)