Page 2 of 6

[笔记] Linkedin移动架构优化之路

本文是2013年11月在Mobile@Scale大会上Linkedin的分享的一个备注,比较乱,讲了Linkedin一路以来移动开发的架构优化之路,原视频在YouTube上,想看的自备梯子

2012 Q1

Screen Shot 2014-06-20 at 1.18.09 AM

Screen Shot 2014-06-20 at 1.19.10 AM

Screen Shot 2014-06-20 at 1.19.51 AM

  • Flag Based Feature Development: http://code.flickr.net/2009/12/02/flipping-out/

Screen Shot 2014-06-20 at 1.20.27 AM

  • Every Checkin都要求95%以上的Routes Testing Coverage
  • Test跑Phone Server上,不涉及UI测试
  • VCR相当于playback Linkedin API的返回值,capture & callback

Screen Shot 2014-06-20 at 1.22.25 AM

Screen Shot 2014-06-20 at 1.29.06 AM

Screen Shot 2014-06-20 at 1.12.17 AM

2012 Q3

Screen Shot 2014-06-20 at 1.29.55 AM

Screen Shot 2014-06-20 at 1.30.08 AM

  • HTML5 cause 3%-4% crash rate

Screen Shot 2014-06-20 at 12.33.52 AM

Present – 2013

  • 5 apps

Screen Shot 2014-06-20 at 12.41.02 AM

Screen Shot 2014-06-20 at 12.43.16 AM

Screen Shot 2014-06-20 at 12.50.26 AM

  • Action Metric Coverage: Action是指用户交互的行为,track用户所有的交互的行为
  • Top Metric Flow Coverage: 从Action Metric中选出用户交互最频繁的操作flow,自动化cover这些flow以后就可以轻松搞定发布问题

Screen Shot 2014-06-20 at 12.51.32 AM

  • Train Model: 固定时间发布,功能点赶得上就赶,赶不上就下一个固定时间再发,功能用feature flag来控制

Screen Shot 2014-06-20 at 1.04.28 AM

Screen Shot 2014-06-20 at 1.11.38 AM

Screen Shot 2014-06-20 at 1.12.17 AM

Architecture In The Future

Screen Shot 2014-06-20 at 1.14.43 AM

Screen Shot 2014-06-20 at 1.16.45 AM

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~~

解决Android开发团队代码版本控制中由编码风格不同造成的代码修订混乱

摘要:不知道大家在版本控制中有没有碰到这种情况,某一个文件新push到代码服务器上的修订很大,几乎是全部的代码出现了修改,看了一遍发现原来是由于协作的人之间编码风格不同,其实真实改动就是改了那么一两行,这就影响了了解真正的代码修订,同时是代码修订历史成了摆设。因为马上有实习生进团队,估计很快又会碰到这种问题,本文就是讲我们团队是如何利用Eclipse的工具解决上面的问题的。

 

  • 统一代码风格 — Android Code Style Guidelines For Contributors

首先,统一的代码风格是一个团队协作开发的好习惯,Android Open Source Project 提供了官方的Strict Android Code Style Guidelines For Contributors,和Android的源码要求一样,非常适合做Code Style规定。

 

  • 统一代码格式 — Eclipse Formatter

1. 在Eclipse的Preferences中,找到Java —> Code Style —> Formatterimage

2. 编辑一个新的Profile,在里面按照团队的代码格式编辑,这里我们编辑了“方法首行空行”等,主要是让代码好看一些,编辑好了以后Export出来作为一个xml文件。

image

3. 将这个format的xml发给团队的其他开发者,导入Java —> Code Style —> Formatter,以后只要在Eclipse里Ctrl+Shift+F,就能统一代码格式了。

image

 

  • 统一Imports的顺序

    在Java —> Code Style —> Organize Imports里,可以设置Imports的顺序,和Formatter一样,确定顺序后
      导出后缀为.importorder的文件,发给团队的人员,统一导入。

     

    • 利用Eclipse的Save Action保证规范能应用到代码上

      当然,上面的规范很可能开发过程中忘记Format,就依然会造成摘要里提到的问题,我们可以用Eclipse的
        Save Action,把Format source code & Organize Imports勾上,保存的时候会自动做上面两件事了。

      image

       

      • 最后,利用AnyEditor解决Win&Linux下Tab的空格个数问题

      在Win & Linux下Tab的空格个数不同是个老生常谈了,这也会影响代码提交的修订,修正这个问题需要借助Eclipse的AnyEditor插件(Download),虽然这个比较细节了,但注意下总是好的。

      做法的话,就是记得再提交代码前,将Tab用AnyEditor转换成Spaces

      image

       

              暂时就想到这么多了,从我自己的实践来看,这些做法能让开发团队无论用Svn,Git还是Hg来版本控制,都能保持一个比较好看的ChangeSet记录。