我乍一看还以为是问图灵测试
coding 同时具备代码托管,部署,社交等等功能 用纯程序员的思路来考虑的话这反而是一个缺点, 因为程序员信奉的是‘Less is More’ 做最少的事,做到最好, 在产品里这个概念叫 MVP(最小可行产品)
程序员不需要一个网站能够同时实现 github heroku twitter 的功能, 而是希望这三个网站在自己的领域做到最好,然后开放足够多的接口就行了。 如果程序员需要,我们可以自己把这三种功能通过 API 连起来。 而且,实际上如果真的有此类需求,每个网站会自己在生态圈中找到位置, 意思就是说,heroku 不会自己做代码托管,而是看看怎么利用 github 完善自己。 事实上,heroku 有一个功能叫做 heroku button https://blog.heroku.com/archives/2014/8/7/heroku-button 就是你可以通过一个按钮将 github 上的代码放到 heroku 上去部署。
一直感觉有一些产品喜欢做的大而全。 创业公司本来资源就不够的情况下,把精力分散在 100 个功能而不是 10 个更紧密相关的功能的时候, 你代码托管不如 github,代码部署不如 heroku,轻博客不如 twitter,用户为什么需要你呢?
“我永远不需要一个有微波炉功能的电冰箱”or unix style
一直浮在应用层,根本不敢谈熟悉二字
Time.now
Time.now + 7.days
Ruby 时间相关的操作都挺好的。
在编写 ROR 之前我就已经迁移到 OS X 平台了,之前是被迫的,因为我要开发 IOS 应用,但是使用 Ruby 之后我才真正的融入 Unix Like 的环境中去,对 gem 的学习甚至反馈给了 IOS 开发,比如发现 IOS 也能这么玩: COCOAPODS http://cocoapods.org/.
对 irb 的使用也影响到前端的开发,我开始正式使用 chrome dev tools 的 console. 每多学一个语言,我都会发现一些新思想可以帮助其他以前学过的东西。
做过的一些 GEM 都是把公司的多个项目中共通的一些代码抽出来集中维护,因为是私有项目就不贴了。 同意 @PengEdy 的实践: 开发之后再优化,优化之后再重构。 我也是先把代码快速的写出一个工作的版本,然后再考虑优化和重构。 因为新增的需求往往是快速变化的,过早优化反而会阻碍后续的开发,特别是不要过早的加入各种 cache, 过早加入 cache 然后变更代码后遇到的坑不止一个两个了。 等功能上线一段时间,并且有足够的需求后,再进行优化和重构,如果反映不好也可能直接删掉。
http://www.v2ex.com/ (I guess too.)
哈哈 码农转矿工么。 抓取某互联网上市企业的付费用户和视频点击以及评论到 sphinx。建模后通过这个数据做股价趋势分析么…
本来以为是看项目,结果是看美女
过几天貌似产品升级
其实我感觉把招聘分出去并不是个好主意。
同事升级后洗盘重装了。。主要是开发环境垮了。
没有右转指示灯的情况下,红灯右转是没问题的。 但是你压白线了,如果扣分的话,你这叫‘不按道行驶’ 你下次多观察下你开的那条道上的方向指示线。
我也感觉挺难得,内容挺多。
楼主黑得漂亮
carrierwave 目测是没有这个功能的。 不过可以从 apache/nginx 的角度考虑一下,因为这些服务器有提供上传过程中返回进度的功能。
本帖证明了 PHP 是最好的语言