• 你选择 Angular 还是 Ember? at 2014年01月22日

    @Rei @darkbaby123 我同意 darkbaby 的看法, 随着现在移动端如此强势的情况下, 网页端已经弱化成一种终端形式, 后台的 restful 化能够使得架构及其简单实用, 非常易于扩展和维护. 各个终端开发团队可以并行开发, 分别实现最贴近于各自平台的交互和 UI (或者是 hybrid).

    Rei 转的那篇文章我觉得思路有些不对, 我认为计算力应该往终端移, 特别是初创企业, 如何减少服务器和带宽使用,就能减少初期投入而增加生存的可能性.

  • 你选择 Angular 还是 Ember? at 2014年01月22日

    这年头选择太多了也确实是头疼啊, 所以才有了 http://todomvc.com/ 这种奇葩网站. 不过说实在的, todo list 这种简单的应用真的用框架写了也不太能试出来一个框架的痛点.

    这两者里面只用过 angular, 投 angular 一票吧.

  • #39 楼 @Rei 是啊, 这些都是超级牛人... 还有诸如 TJ Holowaychuk 这类的... 只能膜拜啊.

  • 我应该如何使用 git 呢 at 2014年01月20日

    git 的优势就是本地细粒度提交再整体完成后 push, 所以每当一个的 step 完成后,你就可以本地提交 (前提当然是没有 broken test), 但是 push 的时候就要非常注意了, 一定是不能影响功能.

  • 用 Ruby 的人自然而然会喜欢用 CoffeeScript, 因为 Coffeescript 就是 inspired by Ruby 等等语言, 同理, Rubylist 会选择 SASS 而不是 LESS.

    不过如今 JavaScript 原生的 library 越来越多了, 诸如 underscore 这种, 也一样能提供类似 sugar syntax, 一样可以很方便的操作数组, Map 等等, 更别说如今特别火的 MVC frameworks.. 所以没有 coffeescript 也一样可以灵活的使用 JavaScript 并且避开诸多的坑.

    楼上有些人用 jquery 和 coffee 类比是不对的, 一个是需要编译的语言, 一个是原生的 library, 没有可比性.

  • 比较欣赏 A, 毕竟原帖主的状况有大把人都能做到, 但是创出事业的难度要大得多了. 当然在大公司里面混着日子也是挺舒服的.

  • 你说的这些大部分我都做过或者正在做了...

  • 目前我的应用也是轮询, 主要是初期做轮询最简单 (考虑到 IE8 的支持, 同时不想弄 flash)

  • 现在不但隔行如隔山, 隔个运行环境什么的都要先了解半天名词才行. 好在虽然名词不一样, 其实道理都差不多. 这种情况下, 你就该让他详细的告诉你如何把运行环境在虚拟机或者哪里跑起来, 你关心的是黑盒层面上的压力测试, 用 ruby, python, nodejs, java ,随便什么, 加上 restclient 或者 selienium 就都可以做压力测了.

    当然如果是白盒, 那还是别插手了, web 专家为啥需要了解你 dll 是怎么部署的.

  • 废除 at 2014年01月07日

    这个招聘还不错

  • 选择 LESS 还是 SASS? at 2014年01月07日

    @Rei less 可以在开发阶段直接引用 less 源码,用 less.js 来解析 (需 IE8 以上), 但是在生产环境, 是可以通过 nodejs lessc.js 来编译并混淆成 css.

  • 选择 LESS 还是 SASS? at 2014年01月07日

    bootstrap 官方原版内部的 css 用的是 less 来管理.

  • 选择 LESS 还是 SASS? at 2014年01月07日

    ruby 的世界就是 sass, coffeescript, amberjs 这些.. 因为语法类似, gem 也多. 当然不做 ruby 的, 选择就更中性一点, 比方我们就选了 less, 前端编程也不用 coffeescript.

    在选择语言方面, 个人比较喜欢原生或者语法和原生及其相似并且兼容的语言, 这样出错易调试, 易于掌控, 而且不管用什么, 原生语言是必须要了解的.

  • 什么原因不支持 IE8?

  • 10 年前做政府项目的时候, 政府里面有个小伙子找了个借口说要用 photoshop, 于是给他 (不是我) 配了台 power G4, 当时能买内环内 5,6 平米房子了.. 口水啊.. 结果后来没两月放那落灰.... 真是无语.

  • 你的 Users 和 Posts 可以分别做成 2 个独立的 js module, 分别配置自己的 router.

  • 1) https://github.com/blueimp/jQuery-File-Upload/wiki/Browser-support

    Copy&Paste of images

    The following browsers support pasting images from the clipboard:

    Google Chrome

    2) Use flash

  • 像我这 at 2013年12月14日

    好吧,用 Rails 开发,写两行,改两行,保存,刷新网页,就能看到结果。如果用 Java,嗯,我的机器重启一次 tomcat 需要 1 分 35 秒。如果改了 Java 代码.....你懂的。还有,我用 Java 做网站经常被浏览器缓存恶心到,但用 Rails 很少有这种情况。

    lz 说的这些其实都有解决方案,并非 ruby 才能这样.

    你可以用 embed jetty, 启动速度超快, 代码即环境, 调试静态资源非常方便. 至于 java 代码, 全部 test driven 基本上启动就应该直接能用了,极少时间需要 debug.

    后台代码你完全可以试试 groovy, 支持 closure, 超多 sugar syntax, 完全兼容 java 文件.

    asserts 缓存问题,你可能要自己规划下自动构建方式和过程, 总归至少开发环境下不是问题. 你被恶心到反而说明你自己没有真的搞明白这块到底是怎么回事.

    开发速度也是因人而异的, 如今 opensource 如此之多, 如果对界面设计要求不高的前提下, 说实在的, 这几种语言我真心感觉差距不大. 花在各种想法和设计的理解上的时间比 coding 时间要多得多.

  • 目前越来越多的项目都是 restful 后台,然后 web 端弱化成一个普通的 client 端. 这样做规模越大越得力, 数据和逻辑都是后台, 前台负责本地化展现, api 级别是 restful 的,利于扩展.

    对于 native app,这么做貌似阻力不大,对于 web 的话, 能熟练使用 js 并做测试的人实在太少了,所以接受的难度肯定要大不少. 而且 SEO 之类的问题也比较头疼.

    我个人是赞同将计算力向客户端迁移的, 当然前提是应用要足够成功, 越成功的应用, 越多计算放在客户端,则需要的服务器维护费用会越少, 当用户量超过 10w 以上的时候, 差距应该会越来越明显. 善用 browser cache, server side cache 等等也是减少 cpu,io 量的一个办法,但是都不如仅仅拿 JSON 那么节省 bandwidth 和计算力.

  • 代码里可以贴图了? at 2013年12月10日

    emoji, 你看看咱的代码...

  • 服务器中大文件上传问题 at 2013年12月09日

    我备份照片就用这句 rsync -varE /Volumes/Public/Photos/ /Volumes/General/backup_photos

  • 少用 pull, 用 command + T

  • boy 还是 girl? at 2013年12月04日

    Anyone who is not an Erlang fan, does not understand OO.

  • 自己做的小应用推荐 mongodb, 这样连 memcache 都省了. 别再纠结了, 我就是从 mysql + memcache 全盘用 mongodb 重写的.