Bitbucket-团队开发私有库使用指南

使用Git维护代码比较好的是GitHub,但是GitHub的私有库是收费的。那么对于一个小团队前期开发时可以考虑使用Bitbucket免费私有库,默认是5个人,据说邀请好友可以赠送3个人,则是8个人。 Bitbucket 和 Github 一样都是 代码维护管理仓库,可以较好的进行代码管理和协同合作。除众所周知的代码维护外,采用 Bitbucket/Github 进行团队开发的另外两大好处分别是 1:WIKI页面管理,方便大家的讨论知识进行梳理; 2:问题追踪,方便团队开发时进行 问题记录,责任下发,自由讨论,邮件关注,团队投票表决等; 代码的维护统一采用Git工具,其他包括Wiki, 问题追踪等 文本排版建议采用Markdown语法。 【第一步】:开通帐户 Bitbucket(http://bitbucket.org/)支持使用Google帐号授权登录。 【第二步】:添加团队 从页面右上角进入 管理帐号,选择使用的Team,进入ACCESS MANAGEMENT -> User groups 添加用户组,如果是添加多个管理员的话则添加 Administrators,如果是 添加开发者用户的话,则添加Developers,添入他们的邮箱/用户名进行邀请(如果对方已通过邮箱注册了帐户则直接添加进来,如果尚未开通则发送邀请邮件)。 此时进入团队首页就可以看到新添加的成员了。 【第三步】:创建仓库 在团队首页-概览-一栏 创建一个新的仓库:Create your first repo,添入一些基本信息后则创建成功。(其中有一个HipChat整合,由于内地使用不是很多,我们暂且不进行整合) 【第四步】:安装Git Unix系统下可直接使用Git,而Win用户则需要安装可支持插件,Git的安装比较简单,直接参考【Git 安装指南】 【第五步】:初始化本地仓库 写在前面的话:如果是从服务器上拉仓库里的文件下来则使用pull,如果是要从服务器上直接把整个仓库Down下来则使用clone。 安装好Git之后,我们选用命令行操作,打开Git Bash,创建一个文件夹,或者cd转到目标文件夹下。 … 继续阅读

PHP字数统计工具: str_word_count

str_word_count的详细说明见:http://php.net/manual/de/function.str-word-count.php 在线测试可使用: http://str_word_count.onlinephpfunctions.com/ 一些Trick,会发现下划线是会被拆分的,而连字符则不会被拆分。因此,在一些 稿件提交系统中,如果有严格的字数限制,而又舍不得删去一些文字,则可尝试在一些不影响阅读的段落中添加连字符以绕开系统的字数限制。注,Trick适可而止,尽量不要大范围使用连字符,要避免给review一个非常差的印象。

限制编程环境UTF-8 + Unix

以后要限制自己的编程环境为UTF-8 + Unix,因为以前编程环境配置混乱,现在再看总是出现各种注释乱码,而且处理的文本大多数也有问题。。。。 为了再次避免类似问题,以后要限制自己的Eclipse,VS,Matlab等 编程环境都为 UTF-8 + Unix。 痛记于 2015-02-15 09:20

如何写计算机会议的rebuttal

其实最好的教材就是实例,恰好NIPS会议会把往年所有论文的Rebuttal都贴出来。。。,见这里:http://papers.nips.cc/ 同时,圈内同行也总结了不少经验,下面转帖其他人的经验 ===========如下转自:http://qiyuhua.github.io/%E5%AD%A6%E4%B9%A0/2013/05/17/rebuttal.html=========== 前段时间刚刚成功rebuttal一篇文章,趁着热度未过,总结一下。 在学术界,计算机科学貌似是一个另类,表现在其特别看中会议而轻期刊,很多业界大牛的得意之作都是首先出现在计算机学科各领域的顶级国际会议中。而好的期刊文章则大多是各顶级会议论文的扩展版,导致其时效性和影响因子都出奇的低:(。本人是软件工程方向,顶级会议(如ICSE、FSE、OOPSLA、ASE、ISSTA)具有比绝大多数期刊高的多的影响力,当然其论文评审筛选过程也是非常严格,超过两个月的审稿时间,录取率一般不高于30%,通常低于25%。随着影响力的提高,很多时候,这些会议也会有所谓的rebuttal机会,让作者有机会挑战reviewers的comments. 不知道是幸还是不幸,本人录取的两片稍微好点的文章都经历了rebuttal阶段,都在收与拒的边缘徘徊过。幸运的是,最终偶还是rebuttal成功:)。 根据本人的成功rebuttal的经历以及对国外大牛们rebuttal提出的建议总结(看这里1和这里2),得出以下可能有帮助的东西:) Rebuttal的意义 首先要明确一点,rebuttal只会在你论文处于接收边缘的时候起作用,如果reviewers意见普遍很严厉,那么rebuttal的作用几乎可以忽略。 区分审稿人态度 要根据审稿人的意见体会各个审稿人对你paper的微妙态度:哪些人拥护你的文章,哪些人拒绝你的文章,哪些人处于摇摆阶段。策略很简单:不要打扰用户你的审稿人,打击拒绝你的审稿人,拉拢摇摆审稿人。记住一点:拥护你的审稿人不管怎么样基本都会在PC会议上拥护你的文章,同样你也很难打动拒绝你的那个审稿人。 武装拥护你的审稿人 通常顶级会议开会的之前,会议主席一般会根据审稿意见为每篇文章试图找一个拥护人,如果没有人愿意拥护你的文章,那么你文章被接收的希望很渺茫。也就是说即使你的所有审稿意见都是weak accept,那么缺乏accept的审稿人很可能会导致文章照样被拒。同样,会议主席也会试图找一个反对者在会上反驳拥护者,最终文章的命运就是二者博弈的结果。因此,rebuttal的重点是反驳反对者的意见,为拥护者提供充足的武器。一个强烈的反对者只可能被另外一个更有力的拥护者打败。 寻找反对审稿人错误的comments 如果你能在反对你文章的审稿人的措辞中找到错误,那么恭喜你,你文章的接收概率会大大提高。在rebuttal中指出此错误,将会降低该反对者的威信。嘿嘿,我最近接收的ISSTA文章正是得意于此。第三个审稿人应该是领域内的大牛,对我的文章大大批判,仿佛与我有仇,列出了总共五大条不喜欢的理由,可能过于得意,在最后的一条意见中居然试图猜测我文章结论的内在原因,结果刚好与实验结果相反,被我逮个正着:)。 写给所有PC 如果有几句话想让所有与会PC看到,那么这几句话一定要放在最前方。原因也很简单,每个人不可能把你的rebuttal全篇看完,但是前几句大家还是都会瞧几眼的。 感谢审稿人 即使是反对你的审稿人,也拿出了很多宝贵的时间审阅你的论文,因此作为作者要学会感恩。 最后呢,还是要感谢Andreas Zeller 这位德国大牛的文章:怎样写好rebuttal,反对你的审稿人。具有戏剧意味的是,我推测那位反对我的审稿人很可能就是Andreas Zeller,而我很可能是根据这位学术大牛写的rebuttal指南驳倒了他:)。不管怎么样,感谢Andreas Zeller。 今天在科学网上看到意味在斯坦福读博的杨双文章,其中一句话写的非常好:“我就说我对这篇论文很自豪,与是否能被录用已经没有关系了”。我虽然没有达到那样的思想高度,但是也很认同其想法。我希望我自己能在毕业工作后能自豪的和别人说博士期间自己还是做了那么一点东西,有那么篇顶级的会议文章永远闪耀在那里。。。。。

Reuters-21578数据集预处理遇到的血泪史

Reuters-21578 是文本分析任务中比较重要的数据集,但是它不像20Newsgroup是现成的纯文本,而是SGML格式的文件,需要我们进行预处理。 插播一条:如果是做词袋模型,那么公开数据集大家已经处理的很成熟了,可以借鉴的如,Deng Cai的工作: http://www.cad.zju.edu.cn/home/dengcai/Data/TextData.html 里面可以下载TDT2, Reuters21578, Reuters21578, RCV1@Top4 的Matlab格式。 但是用于DNN的话,基于词袋模型的数据集就无可以用之地,因而我们还是要老老实实的提取纯文本数据。 Reuters21578数据集的下载地址:http://www.daviddlewis.com/resources/testcollections/reuters21578/ Reuters21578提前要注意的是: ===============下面摘自andy_tsg 的经验分享===================== 1. 这个数据集中的所有记录并不是一股脑拿来全部都用的,学术界有好几种划分的方法,通常最最常用的是ModApte划分方法(关于如何划分的细节可以参见下载包里README.txt文件的介绍); 2. 这些数据文件貌似是有一定的格式的,我刚开始也试图把他们当做标准的xml文档来处理(因为下载包里还像模像样的包含了一个SGML DTD 的文件),但老是报错。最终发现很多的记录格式是错误的,而且错误千奇百怪。所以干脆放弃,直接把它们全部看做文本文件来处理得了; 3. 并不是所有按照ModApte划分得到的记录都能拿来使用,因为有些记录的与之间并没有包含任何的topic信息(比如reut2-000.sgm文件的第307行记录,写个程序可以检测出有不少这种情况,仅举一例),所以只好丢弃; 4. 并不是所有的包含topic的记录都包含有< BODY >字段和< TITLE >字段(比如reut2-000.sgm文件中的第3099行记录,同样这种情况也有不少),但是因为这种情况通常在< TEXT >字段中还是包含了一些文字信息的,所以我选择并不将它丢弃; 5. 由于有4,所以我处理时并不是只将< BODY >字段和< TITLE >字段看作记录的正文,而是将去除所以包含在成对的之间的内容和有关topic的内容后得到的所剩下的部分当做记录正文来看待。这样处理的后果是包含了< DATA >、< PLACES … 继续阅读

写文章的那些毛病

1. 缩写词第一次出现时应先写全称,例如应为Question and Answer (Q&A) 而不是Q&A (Question and Answer); 2. Firstly, . Secondly, . Finally, .,在同段中用句号隔开就Ok,不需要分号; 3. 文中的每一个新符号出现的时候一定要进行解释,最后应过一遍文章,避免出现符号表达前后不一致问题; 4. 如果上一个句子以公式符号结尾的话,下面的句子最好不要以公式符号开头,很容易混淆; 5. Latent Dirichlet Allocation (LDA),注意括号(LDA)前要有空格; 6. 公式和图标应尽可能靠近文中对应内容的地方; 7. 尽量避免出现learn-s这样的连接词,孤零的一个s被隔开比较难看; 8. 图片中的文字切记过小; 9. 试验数据集最好比较多而充分; 10. 写论文要会扬长避短; 11. Baseline方法最好在相关工作中描述一下; 12. 论文中如果出现了网址,一定要自己试一下,保证链接没有问题,重要的线索如果写错会让人很恼火; 13. … 继续阅读

LaTex公式长度过长问题

发现一个博文总结挺好的,直接拿来主义 ==================== 见下文 ================== 【原文】http://blog.163.com/chen_dawn/blog/static/112506320137910339309 解决方案: 1. 断行 2. 适量缩小公式间距 3 变小字体 1. 断行: http://blog.163.com/chen_dawn/blog/static/11250632013789459674/ 2. 适量缩小公式间距 微调公式长度,调整空格 有时候,用LATEX 打出的公式,显示出来的长度是,一行还多,多出来的一点串到下一行还太少。很想浓缩成一行显示,简洁美观。这时候就利用微调来完成。 例如。某公式原式为: % 公式-1 \ begin{eqnarray} \ dot{x}(t)=\ bar{A}_{i}x(t)+\ bar{B}_{i_{1}}x(t)+\ bar{B}_{i_{2}}x(t)+\ bar{B}_{i_{3}}[a_{i}(t)+b_{i}(t)]. \ end{eqnarray} —————————– LATEX 中空格的距离大致如下: 具体的间隔大小为: \ quad 1em,em代表一个字符宽度 … 继续阅读