 |
Elfe |
| 程序员 • Elfe 聊聊那些能让我们快速开发出程序来的积木块儿 2014 年 12 月 16 日 • 最后回复来自 dreampuf | 22 |
| 问与答 • Elfe 大家在 V2EX 上看到的最有趣的帖子是什么？ 2014 年 12 月 4 日 • 最后回复来自 Elfe | 18 |
| iDev • Elfe 有从 AppStore 上紧急撤回一个更新版本的方法么？ 2012 年 6 月 25 日 • 最后回复来自 elepone | 8 |
| Livid • Elfe 竟然有个网站叫 iLivid 2012 年 6 月 12 日 • 最后回复来自 caoyue | 3 |
| iDev • Elfe 团队成员之间的 code review 大家都用什么工具？ 2013 年 3 月 10 日 • 最后回复来自 faywong8888 | 23 |
| iDev • Elfe 通常大家都怎么对待编译 warning 和 Analyze 报告的错误？ 2012 年 6 月 5 日 • 最后回复来自 adow | 12 |
| iDev • Elfe 求助：抓狂的 $UNIX2003 后缀 2012 年 5 月 30 日 • 最后回复来自 Elfe | 2 |
| iDev • Elfe 几个关于XCode的问题 2012 年 5 月 24 日 • 最后回复来自 BB9z | 4 |
| iDev • Elfe 大家是用Interface Builder还是手工敲界面的呢？ViewController 究竟应该扮演怎样的角色？ 2012 年 6 月 6 日 • 最后回复来自 Nobuta | 29 |
Elfe 最近回复了
| 回复了 restran 创建的主题 › 传图识花 - 发送花朵特写的图片，识别花朵的名字2015 年 11 月 18 日 |
试下来不太准。
百度识图的植物识别还是蛮牛的。以至于我每天拍一张植物照片、通过翻植物图鉴来识别名称的行动都没有动力了……那么简单就不好玩了……在此之前我靠人肉认了百余种植物 http://s.weibo.com/weibo/%25E4%25BB%25A3%25E5%258F%25B7%25E9%2587%2587%25E5%25BE%25AE&Refer=STopic_box
百度识图的植物识别还是蛮牛的。以至于我每天拍一张植物照片、通过翻植物图鉴来识别名称的行动都没有动力了……那么简单就不好玩了……在此之前我靠人肉认了百余种植物 http://s.weibo.com/weibo/%25E4%25BB%25A3%25E5%258F%25B7%25E9%2587%2587%25E5%25BE%25AE&Refer=STopic_box
| 回复了 Elfe 创建的主题 › 记一次代码事故之后2015 年 9 月 24 日 |
Github 新增了 protect branch 的功能，我们现在用起来了。原来的油猴脚本光荣退休。
| 回复了 TanJunqiang 创建的主题 › 没有毕业证的在读本科生 找工作只能是实习吗？2015 年 8 月 4 日 |
呀，做广告的机会来啦 http://www.lagou.com/gongsi/j9343.html
我们实习生只要能力够，就可以提前转正，等正式入职后就会把薪水补齐。
另外印象中我们确实有同学没毕业证照样在公司以全职员工身份工作了几年的，具体怎么操作的需要去问一下HR。
我们实习生只要能力够，就可以提前转正，等正式入职后就会把薪水补齐。
另外印象中我们确实有同学没毕业证照样在公司以全职员工身份工作了几年的，具体怎么操作的需要去问一下HR。
| 回复了 Elfe 创建的主题 › 记一次代码事故之后2015 年 8 月 4 日 |
| 回复了 Elfe 创建的主题 › 记一次代码事故之后2015 年 8 月 4 日 |
由上面gerrit+github的文章顺藤摸瓜找到cloudfoundry的实践 http://blog.cloudfoundry.org/2012/04/11/the-new-cloudfoundry-org-gerrit-jenkins-github/ 不过也是3年前的了。不清楚他们是自己搭的gerrit还是用的某public服务。
gerrit+github的服务我只找到GerritHub.io, 可是从他们的blog来看，似乎他们和github关系一点都不紧密，要用还是不太放心。 http://gitenterprise.me/2015/06/25/github-api-change-causes-problems-to-jenkins-and-gerrit/
有实践gerrit+github方案的同学么？传授一点经验？ @mintist @clino @benjiam @yangshengwu @pyKun @hitmanx @oxoxoxox
gerrit+github的服务我只找到GerritHub.io, 可是从他们的blog来看，似乎他们和github关系一点都不紧密，要用还是不太放心。 http://gitenterprise.me/2015/06/25/github-api-change-causes-problems-to-jenkins-and-gerrit/
有实践gerrit+github方案的同学么？传授一点经验？ @mintist @clino @benjiam @yangshengwu @pyKun @hitmanx @oxoxoxox
| 回复了 Elfe 创建的主题 › 记一次代码事故之后2015 年 8 月 4 日 |
@Livid 报bug：附言太长了发不了，里面的markdown没转换……问题本身倒不大，不过你好歹提醒一下么……
| 回复了 Livid 创建的主题 › O'Reilly Velocity 2015 Web 性能与运维大会 8.11-12 将在北京开幕2015 年 8 月 4 日 |
这是去年的视频 http://www.youku.com/playlist_show/id_22777674.html
这个会干货还是很多的。
可惜，安排周二、周三这么奇葩的时间，上海北京来回折腾一下，一周就耗掉了大半。还是应该像QCon一样搭着周末开能好些。
这个会干货还是很多的。
可惜，安排周二、周三这么奇葩的时间，上海北京来回折腾一下，一周就耗掉了大半。还是应该像QCon一样搭着周末开能好些。
| 回复了 Elfe 创建的主题 › 记一次代码事故之后2015 年 8 月 3 日 |
@humiaozuzu 两年多前我们开始启用github时不过二、三十号技术人吧。现在把数据之类的全都算上也就五、六十来技术FTE，做主站开发的不过十几个，不算大。
@Andiry 是啊，我们也都很不理解，纷纷问xxx你用pull --force是想干嘛呢……还是没有教好呀
@kzzhr 招呀，来吧 http://www.lagou.com/gongsi/j9343.html
嗯，我挺乐意写这样的软文的，这样的交流总有收获。我以前还真没有留意gerrit，这次那么多人提，是得认真看一下了。先谢过哈。
@Andiry 是啊，我们也都很不理解，纷纷问xxx你用pull --force是想干嘛呢……还是没有教好呀
@kzzhr 招呀，来吧 http://www.lagou.com/gongsi/j9343.html
嗯，我挺乐意写这样的软文的，这样的交流总有收获。我以前还真没有留意gerrit，这次那么多人提，是得认真看一下了。先谢过哈。
| 回复了 Elfe 创建的主题 › 记一次代码事故之后2015 年 8 月 3 日 |
@Livid 为啥我这条消息不能作为附言发出？
答楼上各位
我们是要求fork出自己的repo、建自己的branch，commit后发pull request，然后code review/merge 到主repo的master。这个流程正常操作是绝对不会有问题的，只是没按规则出牌就出了意外。
出意外的原因是为了让所有工程师都能review完别人的代码后merge（我们认为只又少数人有code review和merge代码的权限很不合理，会严重降低工作效率），就必须给大家开write权限（我们用的是普通的github private，只有read/write/admin三种权限设置），从根上无法禁止直接push（包括force push）。各位自建git、用github enterprise的同学的建议都很靠谱， 可惜我们目前做不到。
确实也有考虑过是不是该强制大家用同样的git工具遵循同样的操作方式，来杜绝意外的发生。不幸，百姓网对工具的使用向来不做限制，甚至可以说是鼓励大家小范围尝鲜，导致百花齐放（其实我对这个是有吐槽的，以后再展开）。大家与git相关的玩法很多，大概只有通过github网页上code review PR并merge，这一点是一致的。所以这次就通过用油猴脚本让大家能继续“merge”，来确保避免breaking things的同时没有妨碍moving fast.
关于code review，我们以前一直是要求“必须”，但全凭自觉。过去多年一直执行得挺好的，但最近一年感觉松懈了。所以这次油猴脚本加了对code review得强制要求。接下来会去研究一下gerrit，看是否值得为此改变大家得工作习惯。多谢大家建议！
答楼上各位
我们是要求fork出自己的repo、建自己的branch，commit后发pull request，然后code review/merge 到主repo的master。这个流程正常操作是绝对不会有问题的，只是没按规则出牌就出了意外。
出意外的原因是为了让所有工程师都能review完别人的代码后merge（我们认为只又少数人有code review和merge代码的权限很不合理，会严重降低工作效率），就必须给大家开write权限（我们用的是普通的github private，只有read/write/admin三种权限设置），从根上无法禁止直接push（包括force push）。各位自建git、用github enterprise的同学的建议都很靠谱， 可惜我们目前做不到。
确实也有考虑过是不是该强制大家用同样的git工具遵循同样的操作方式，来杜绝意外的发生。不幸，百姓网对工具的使用向来不做限制，甚至可以说是鼓励大家小范围尝鲜，导致百花齐放（其实我对这个是有吐槽的，以后再展开）。大家与git相关的玩法很多，大概只有通过github网页上code review PR并merge，这一点是一致的。所以这次就通过用油猴脚本让大家能继续“merge”，来确保避免breaking things的同时没有妨碍moving fast.
关于code review，我们以前一直是要求“必须”，但全凭自觉。过去多年一直执行得挺好的，但最近一年感觉松懈了。所以这次油猴脚本加了对code review得强制要求。接下来会去研究一下gerrit，看是否值得为此改变大家得工作习惯。多谢大家建议！
| 回复了 Elfe 创建的主题 › 记一次代码事故之后2015 年 8 月 3 日 |
另外就是我们也考虑过webhooks，但似乎没能找到pre-push之类的event https://developer.github.com/webhooks/