Github Advanced Search猎头大法

摘要:标题党了,其实就是随手记录下怎么用搜索一下潜在的程序猿候选人,纯属个人经验,虽然略有骚扰嫌疑,不够大家都是码农,就算不能共事,互相认识下应该不会非常介意吧:)

一点背景

作为一个创业团队,找靠谱的开发小伙伴是前提条件之一,相信每个团队负责人都经历过找开发者的窘境,但靠谱的开发者是稀缺资源,一般不是Post个职位就能找来的。作为一个前求职招聘类产品创业者,我也算见证了拉钩网和内推网这样互联网垂直招聘网站靠着这个难点崛起,我自己也在上面招到过优秀的小伙伴。不过,当你要招人的时候当然要火力全开,尽量找到更多候选人,码农都知道Github和Stackoverflow大法,也有人说这里是最好的开发者招募地,但怎么在Github上来主动出击呢,我做过下面的尝试,仅供参考。

Let Github大法 Begin…

招募目标:前端一枚,熟悉Jquery,对响应式Web开发有所了解,最好接触过grunt或者gulp之类前端工作流工具,coding experience在两年左右,毕竟项目比较紧,方便上手

工作地点:武汉

第一步:找到候选人的集合

先热个身,如何找到所有Github上在武汉的前端呢?

打开Github Advanced Search,输入location:wuhan,OK,895只程序猿出现了…(联系方式都有,不过码是我打的哈)

武汉码农大名单

很小的功能哈,不过同样的功能在Stackoverflow Career上搜一搜,一个月要$1000哟(额。。。是的,没钱才折腾)

stackoverflow搜人大法

Github Advanced Search提供了按照用户“开发语言,粉丝数,项目数”的过滤,输入“language:JavaScript location:wuhan”就能找到所有Github上在武汉的132个前端了,Problem one solved

第二步:缩小候选人的范围

接下来就要尽量缩小范围,找到可能符合我们要求的候选人。

首先呢,上面说的Github Advanced Search页面最下面提供的按照用户“粉丝数,项目数”的过滤,能过滤掉一些完全不活跃的用户

过滤条件

然后呢,搜索结果页面的排序功能能过滤出粉丝较多,或者coding experience合适的候选者

Github搜索排序

我自己用“粉丝数>5,项目数>10”锁定了一个16人的list(PS:第一个就是前同事真的不是故意的==!),这对我就差不多是个适中的候选人列表了,之后呢就比较费时了,翻看一下他们的项目,看有没有和需求相关的repo或关注了类似的repo,这样就能比较精确了。

最终名单

最后当然是要简单社会工程下了,微博,Blog,Stackoverflow什么的都要看看,要知道哪些候选人是可能在找工作机会的,哪些人没有,不要闹笑话了,这段就太邪恶了,还是跳过吧。

第三步:联系候选人

OK,这时候我们已经有一个符合我们要求,并且可以联系的email list了,可以分成两组:

一组是暂时没什么希望的,可以介绍下自己和自己的产品,说明怎么找到联系方式的,主要是为了认识一下,最好能介绍一下身边同样符合我们招聘条件的人,人以群分嘛,这样换来的候选人比较有希望。

第二组当然是可能正在找工作机会的,同样要介绍好自己和产品,争取一下互相了解的机会,这里肯定就是自由发挥啦,看看有没有可能共事,先预祝大家都能招到合适的小伙伴:)

收个尾

用了蛮久的,一直说记一下的,不过这写完回过头来一看,居然颇有某网络热帖里屌丝用大数据追女神的感觉…结果这忙活了半天是找基友,太心酸了,关机睡觉了==!

PS:鉴于这个文章转载还不错,我要打个广告了,麻烦各位有海外租房和海外房产投资的亲们移步洋房东,各位转载的时候也麻烦带上,感谢!

Protected: 匆匆而过的2013和2014

This content is password protected. To view it please enter your password below:

Git branching model for BBT v0.1

Git-Workflow-bbt-v0.1

1. Git&Gitlab Intro

About Git, Please read “Pro Git book” first, at least first three chapters and “6.6 Submodules”

About our “Gitlab” , it`s a self-hosted Github like service, so just use it like Github.

2. Brief Introduction About Our Deployment

Now our deployment workflow is Our master on git server is our development environment, our production environment is managed by Felix, he will push stable version from master on git to production environment(AKA www Server) himself. So we don`t separate develop and master, there will only be master( AKA dev Server).

3. Branching Model

Basically folk from “A successful Git branching model”:http://nvie.com/posts/a-successful-git-branching-model/ , which is known as “Git Flow”:https://github.com/nvie/gitflow , we have exact same definition for Release branches, Feature branches or Hotfix branches with Git branching model, so you guys can check out this article first, we just simplify and use it here.

The main branch – master

The central repo hold only one main branch with an infinite lifetime:

  • master

The master branch at origin should be familiar to every Git user. We consider origin/master to be the main branch where the source code of HEAD always reflects our development state. So when anyone want to start involve a project , check out code from git server

This is where continuous integration or any automatic nightly builds are built from. So for web front-end and server-side, everytime if there is commit to master, there is a git hook to make sure the dev server reflects the current master source code.

And if there is a new production release is ready, system administrator will push it to Production Server.

Supporting branches

Next to master branch, our development model uses a variety of supporting branches to aid parallel development between team members, ease tracking of features, prepare for production releases and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited life time, since they will be removed eventually.

The different types of branches we may use are:

  • Feature branches
  • Release branches

Each of these branches have a specific purpose and are bound to strict rules as to which branches may be their originating branch and which branches must be their merge targets. We will walk through them in a minute.

By no means are these branches “special” from a technical perspective. The branch types are categorized by how we use them. They are of course plain old Git branches.

Feature branches

May branch off from: master Must merge back into: master Branch naming convention: * Recommend branch name: component-#issue-feature_name * So must prefix feature name with different platforms` name, such as ios, android, backend, web

Creating a feature branch

When starting work on a new feature, branch off from the master branch.

$ git checkout -b web#2232-user_login origin
Switched to a new branch "web-user_login"

Commit on local created feature branch

$ git commit
Commit changes to branch "web-user_login"
$ git push origin --set-upstream web-user_login
Push local branch to origin, and after first time, you can use 'git push' instead.

Sumbit A Merge Request through Gitlab

If you are solving an issue on Redmine, start here:

  • Open relevanted issue page on Redmine
  • Click “New merge request”
  • Select your feature branch
  • Write title using branch name and sumbit

If you are not solving issue on Redmine, just do 3 and 4 will be ok.

Project Master’s review feature branch code

  • Check out remote branch(like origin/web-#2322-web_login):
$ git checkout -t remote_name/remote_branch
  • Review code, feedback on Gitlab
  • When code is approved, merge and remove this feature branch

** (Optional for master of project if needed) Incorporating a finished feature on master **

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff web-user_login
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d web-user_login
Deleted local branch web-user_login (was 05e9557).
$ git push origin :web-user_login
Deleted branch web-user_login from remote git server.

Release branches

  • May branch off from: master
  • Must merge back into: master
  • Branch naming convention:
    • Recommend branch name: release-component-version_name
    • So must prefix feature name with different platforms` name, such as “ios”, “android”, “backend”, “web”

Creating a release branch

Create release branch means there is a production ready version, we gonna do beta test in release branch,this branch will last until we push to Appstore, Google Play or any other markets.

$ git checkout -b release-iOS-v1.0 master
Switched to a new branch "release-iOS-v1.0"
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2 
//(We don`t have this yet, maybe done with build tool)
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions

Finishing a release branch

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-iOS-v1.0
Merge made by recursive.
(Summary of changes)
$ git tag -a iOS-v1.0
$ git branch -d release-iOS-v1.0
Deleted branch release-iOS-v1.0 (was 05e9557).
$ git push origin :release-iOS-v1.0
Deleted branch release-iOS-v1.0 from remote git server.
$ git push --tags
[new tag]   iOS-v1.0 -> iOS-v1.0

我们为什么做歪伯乐

摘要:从QQ,人人到微博,我们中很多人已经可以在线上找到自己的真实社交网络,这些社交网络上的应用也渗透到了各个领域,好友买卖,偷菜等带来的社交游戏,蘑菇街,美丽说为首的社交购物,都真的给我们带来了不一样的体验,但在求职招聘领域,似乎国内的社交网络并没有给我们带来实质性的好处,求职网站上的职位一成不变,商务社交网站里往往又没有自己的好友,这就是我们想突破的地方,基于国内现有的社交网络,帮你找到你好友工作过的公司都在招哪些职位。

我们想做什么

一句话,歪伯乐希望通过你已有的社交网络,帮你找到你好友的公司都在招聘什么职位。 有句俗话说“物以类聚,人以群分”,所以你圈子里的好友去了哪些公司,往往你更有可能去那些公司。现在,当你找工作时时,看到一些心仪的职位或者公司,肯定希望能找到好友打听一下待遇,面试,甚至能内推就更好了,而我们就是让你在这里能找到那些自己圈子里的好友工作过的公司正在招聘的职位,而不是一个和你没有关系的职位告示板。

我们做了什么

1. 搜索、订阅、推送你感兴趣的社交网络职位

做一个职位的推荐系统,首先要有职位数据源,开放的职位数据源有很多,比如Job Indeed职友集,聚合了很多招聘网站的招聘信息,我们可以直接接入,不过考虑到我们以前做过新浪微博职位垂直搜素引擎,希望能首先为用户带来社交网络职位。 因为一来,在国外,社会化招聘已经成为日常招聘模式。据社会化招聘网站JobVite 2011年8月的报告和图表显示:有大约89%的美国公司都使用社会化媒体来进行招聘,在使用社会化媒体招聘的这些公司当中,有80%的使用linkedin,使用facebook和twitter分别是50%和45%。现在每天在新浪微博,腾讯微博等社交网络上发出来的职位少说有近万条,也是企业一个日渐重要的招聘补充手段,但用户并没有一个很好的工具去搜索,订阅可能感兴趣的职位,我们能提供这样一个工具。

二来,我们觉得对从社交网络里非结构化数据针对特定领域的数据挖掘是未来一个重要的方向,值得我们花时间去研发。

现在我们每天能通过自己训练的精准规则从新浪微博和腾讯微博采集上千条有效职位,用户可以通过客户端搜索订阅感兴趣的关键字,接收职位推送提醒,先人一步,发现社交招聘职位。比如搜索”产品经理 北京”—>

 

添加订阅—>

收到订阅职位推送提醒 —>

查看职位详情 —>

2. 找到你新浪微博好友工作过的公司都在招哪些职位

既然是基于用户现有社交网络的好友进行数据挖掘,那么选择从什么社交网络导入好友信息就非常重要,经过我们的测试,我新浪微博上的好友大概大概有30%左右的人填写了公司信息,而人人和腾讯微博,豆瓣等社交网络的已有职业信息还太少,Linkedin的国内用户数相对较少,所以首先导入新浪微博的好友能解决推荐的冷启动问题,帮用户挖掘出他的好友都在哪里工作。 下图就是我自己(@wangchao0721)新浪微博登陆后,好友圈子(新浪微博互粉好友)里的公司和与这些公司有关的微博职位。

用户可以查看自己圈子里的公司和有哪些好友在这些公司工作或者工作过 —>

查看好友工作过公司的社交招聘职位,找感兴趣的向好友咨询 —>

 

我们还要做什么

国内已经有了很多商务社交网站,我们希望他们越做越好,让更多的国人有维护在线简历,管理职场人脉的习惯,但我们并不是一个商务社交网站,我们有点类似于Indeed,但是在社交网络上做职位搜索和社交化推荐职位,希望能通过社交开放平台,让用户找到自己好友工作的公司正在招聘的职位。 在搜索引擎的完善性和推荐引擎准确性上,我们都还有非常多需要提升的地方,先按下不表,欢迎大家先来体验拍砖。

网站申请内测:www.ybole.com

客户端下载:www.ybole.com/download

iPhone版下载:https://itunes.apple.com/cn/app/id591645289

扫描可直接下载:

解决Eclipse 3.7.2升级到4.2带来的开发环境迁移问题

摘要:本人原来的Eclipse版本是3.7.2,主要做Android开发,今天准备装个Maven插件编译Github Android客户端看看的,结果死活装不上,遇上了各种问题,果断下了个Eclipse 4.2,试了下M2E,发现完全没问题了,但就是升级Eclipse需要重装Android Development Tools , AnyEditor , ColorTheme等等一堆插件,还有配置,很是觉得麻烦,果断搜了下,Stackoverflow上还是有更好的方法的,不过仅限于3.7以上,简单说一下。

 

  • 下载安装Eclipse 4.2

下载地址:http://download.eclipse.org/eclipse/downloads/drops4/R-4.2-201206081400/,记得不要覆盖了旧的Eclipse版本

 

  • 从旧版本的Eclipse中导入Plugins

选择 File -> Import –> Install -> From existing Installation

image

指向你的旧版本Eclipse,我这里是指向我的Eclipse 3.7.2(图为我导入以后的样子….)

image

  • 最后

还是要记得把Workspace指向以前的Workspace,就可以无缝切换到新的Eclipse了,Enjoy your coding~~