diff --git a/_includes/comments.md b/_includes/comments.md index 4c3be09..a1c93d4 100755 --- a/_includes/comments.md +++ b/_includes/comments.md @@ -1,4 +1,9 @@
+ +
+ + +
+ + +
+ + + + + +
+ diff --git a/_layouts/default.html b/_layouts/default.html index 3e1a333..f18f1d1 100755 --- a/_layouts/default.html +++ b/_layouts/default.html @@ -4,15 +4,20 @@ {{ page.title }} | {{ site.author }} - + - + + + - + + +
diff --git a/_layouts/post-en.html b/_layouts/post-en.html new file mode 100644 index 0000000..b7ca7ac --- /dev/null +++ b/_layouts/post-en.html @@ -0,0 +1,120 @@ +--- +layout: default +--- + +
+{{ content }} +
+
+
+ + {{ site.author }} - Software Engineer with more than 7 years experience related to Java, Android and C++. He is now working for Avaya Emerging Product and Technology Department Shanghai, China. + +
+ + Published under (CC) BY-NC-SA + +{% if page.categories %} + + in categories + {% for cat in page.categories %} + {{ cat }}  + {% endfor %} + +{% endif %} +{% if page.tags %} + + tagged with + {% for tag in page.tags %} + {{ tag }}  + {% endfor %} + +{% endif %} + +
+ + +
+{% include comments_en.md %} + + + + \ No newline at end of file diff --git a/_layouts/post.html b/_layouts/post.html index c80f112..81d2c50 100755 --- a/_layouts/post.html +++ b/_layouts/post.html @@ -6,12 +6,9 @@ layout: default {{ content }}
+
- {{ site.author }} - - - / - + {{ site.author }} - 程序员，7年工作经验集中在Java, Android, C++，现就职于上海Avaya Emerging Product and Technology部门。
@@ -33,6 +30,10 @@ layout: default {% endfor %} {% endif %} + +
+ +
{% include comments.md %} + + \ No newline at end of file diff --git a/_posts/2014/2014-02-01-Flex-real-time-video-app.md b/_posts/2014/2014-02-01-Flex-real-time-video-app.md new file mode 100644 index 0000000..f9fa48d --- /dev/null +++ b/_posts/2014/2014-02-01-Flex-real-time-video-app.md @@ -0,0 +1,73 @@ +--- +layout: post +title: 基于TCP和无线网络（3G）的实时应用需要注意的问题 +categories: +- Telecom +tags: +- Flex, Adobe AIR, Video, TCP +--- + + + + + +最近工作中把一个实时的基于Adobe Air的实时视频聊天程序porting到Android上。原本PC版本测试时视频的质量很好，但是转到Android上后在3G网络上测试发现视频质量比较差。由于Air程序与服务器是通过RTMP这一基于TCP的协议来沟通的，在解决问题的过程中有一些关于TCP的小小发现。 + +---------- + + +## 3G下测试出的情况 +在3G网络下测试的时候我先在设备上运行了一个网速测试的APP，得出当时的网速是上行4.5M下行1.6M左右，对WCDMA来说这是一个比较好的数字，而我们的服务器设置中视频质量仅需要320K的带宽就够了。然而实际通话时的视频和音频质量都非常差（最后双方关上视频，仅用音频的质量都比较差）。 + +## 服务器上抓包 +> **NOTE:** +> 需要注意抓包的准确性问题。在服务器上如果用tcpdump抓包，特别是像视频实时应用的时候由于数据量大，tcpdump依赖的底层库可能会来不及处理而buffer溢出，使得数据文件不完整。这样在用wireshark分析的时候会看到的丢包量就是不准确的。 +![](/media/pic2014/0201-2.png) +>解决方法参考[tcpdump抓包丢失问题](http://wenku.baidu.com/view/74b3166e1eb91a37f1115cf6.html)。 + +在分析抓到的包时我们看到大量的丢包，如下图： +![](/media/pic2014/0201-1.png) + +###更多测试的结果 +下面的对比测试中我们对比一下不同丢包情况所导致的不同TCP吞吐率曲线。（前面一个小峰是带宽测试留下的。） + +下图是视频质量好的时候的TCP呑吐率情况 +![](/media/pic2014/0201-4.png) +下图是视频时断时续丟包 +![](/media/pic2014/0201-5.png) +下图是视频几乎无法进行的情况 +![](/media/pic2014/0201-6.png) + +由上面的图形我们看到不同的丢包对TCP传输率产生了不同的影响。 +## 3G带宽与TCP丢包 + +这轮测试下来得出的重要结论是**TCP在WCDMA3G下的网速远达不到其宣称值**！因为丢包会导致TCP误以为是网络拥塞，而双方减小收发窗口，主动降速。 +下图就是我实测的TCP网速。 +![](/media/pic2014/0201-3.png) +再来看一下维基是怎么说这个问题的： +> [TCP_over_wireless_networks](http://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_over_wireless_networks) + +> TCP has been optimized for wired networks. Any packet loss is considered to be the result of network congestion and the congestion window size is reduced dramatically as a precaution. However, wireless links are known to experience sporadic and usually temporary losses due to fading, shadowing, hand off, and other radio effects, that cannot be considered congestion. After the (erroneous) back-off of the congestion window size, due to wireless packet loss, there can be a congestion avoidance phase with a conservative decrease in window size. This causes the radio link to be underutilized. Extensive research has been done on the subject of how to combat these harmful effects. Suggested solutions can be categorized as end-to-end solutions (which require modifications at the client or server),[38] link layer solutions (such as RLP in cellular networks), or proxy based solutions (which require some changes in the network without modifying end nodes). + + +> [参考3G的标称网速](http://en.wikipedia.org/wiki/3g) + +> HSPA is an amalgamation of several upgrades to the original W-CDMA standard and offers speeds of **14.4 Mbit/s** down and **5.76 MBit/s** up. HSPA is backwards compatible with and uses the same frequencies as W-CDMA. + +注意标称网速不包括自身的信令消耗，所以150M的WiFi实际数据传输速度超不过80兆。3G消耗的信令可能更多。 + +## 如何改进 + + +**带宽检测** + +大多数实时通信程序都会在链接建立前发几个包测试带宽，这种做法在传统网络问题不大（会部分受到tcp slow start的影响）。但是在3G下，这几个包如果不丢，测出的速度会过高，如果有丢包，则测出的速度会过低。 + +所以在3G下的应用必须在链接建立后实时监测通信质量，如果发现延迟增加等情况要实时降低视频分辨率以保证流畅。 + +另一种简单办法是延长一开始的带宽测试时间。比如说测十秒。我曾在与Skype的对比测试中发现从拨号到对方实际振铃有较长延迟，这中间有可能就是在测带宽。 + + +**UDP** + +使用基于UDP的传输协议可以从根本上解决以上问题。 diff --git a/_posts/2014/2014-02-03-Git-cook-book.md b/_posts/2014/2014-02-03-Git-cook-book.md new file mode 100644 index 0000000..ec66e0d --- /dev/null +++ b/_posts/2014/2014-02-03-Git-cook-book.md @@ -0,0 +1,184 @@ +--- +layout: post-en +title: Git Cookbook +categories: +- Common Tec +tags: +- Git +--- + +> 本文始于自己的Evernote，由于大部分原本是英文记录的，所以干脆全部用英文。 + +> Most of the content comes from my Evernote, therefore, this post will be updated once I have more notes, and you are highly welcome to contribute your notes to this article or point out any mistake. + +### How to see simple git log? + +------------- +The following let you to see only one line comment for each commit. + +``` +git log --oneline +git log --oneline -3 +``` +Below command let you to display Gitk-alike tree to your shell screen. And `--global alias.pl` allows you to use the short form of command. like `$ git pl`. + +``` +git log --oneline --graph --decorate +git config --global alias.pl "log --oneline --graph --decorate" +``` +Usage: + +![](/media/pic2014/0203-1.png) +### How to see log in another branch? +------------- +```shell +git log origin/master.. +``` +### How to search keywords in commit comment (across all branches)? +------------- +If you want to know how a feature was implemented you can start by search the keywords in the log history and then diff it. From my experience, most of times this method is faster than search in the IDE. + +``` +git log --all --grep='a keyword' +``` +**Note** +`--grep` can bring you the entire commit message instead of ONE line which contains the keywords. This command is better than the shell `grep` command `git log --all |grep 'keyword'` because the later only gives you one line result and you cannot see ALL comment of a commit. +### How to see history of one file? +------------- +You have many options to achieve that goal. + +``` +git log -- [filename] (show the log history) +git log -p filename (Diff the code; git generate the patches for each log entry) +gitk [filename] (Show the content changed) +git log --follow (Show rename) +``` +### How to only produce one commit for a merge? +----------- +Think about you have a dev branch and a main branch and you have a lot of commits in your dev branch, but when merge code you don't want all those comment history goes to the main branch(the main branch history could be more meaningful). use `--squash` to only produce one new commit for the merge. + +``` +git merge --squash bugfix +git commit -m 'fix bug' +``` + +### How to only see local commit log? +----------- +The following gives you two ways to see that. + +``` +git log --no-merges master.. +git log -g +``` + +### How to revert to a commit? +---------------- + +``` +git reset --hard 4a155e5 +and then +git push -f origin master +``` +**Notice** git revert will not work here! `git revert` can only revert one commit. If you have commit `11,22,33,44,` and you `git revert 22` then you will have commit `11,33,44`, but if you `git reset --hard 22` and commit, then you could only have `11` in your commit history. + +### How to find a lost commit? +-------------- +Sometimes we could lost our commit(For example you are working on a detached HEAD). As a last resort in case your commit is dangling and not connected to history at all, you can search the reflog itself with the `-g` flag (short for `--walk-reflogs`) + +``` +git log -g --grep='Build 0051' +``` +**This is because that the reflog contains the local history.** +After you get the SHA-1 for you commit. You can check it out. + +### How to know which branch is the most recent? +-------------------- +Once you cloned a huge repo, and a lot of branch can be found within it - some of them are not active because the feature development was completed. How to know which branch to use? My way is to sort these branches by commit time, so we know which branch is fresh. + +``` +git config --global alias.latest "for-each-ref --sort=-committerdate --format='%(committerdate:short) %(refname:short)'" +``` + +**Usage:** + +``` +$ cd ~/Code/rails/rails && git latest +2012-11-19 origin/master +2012-11-19 origin/HEAD +2012-11-19 master +2012-11-19 origin/3-2-stable +2012-11-03 origin/encrypted_cookies +2012-11-03 origin/attributes_perf +... snipped ... + +``` +Show local branches only: + +``` +git config --global alias.latest "for-each-ref --sort=-committerdate refs/heads --format='%(committerdate:short) %(refname:short)'" +``` +### How to change the remote HEAD +------------ +``` +git branch -a +remotes/origin/HEAD -> origin/gh-pages +remotes/origin/gh-pages +remotes/origin/master + +git remote set-head origin master +git branch -a +remotes/origin/HEAD -> origin/master +remotes/origin/gh-pages +remotes/origin/master +``` +### How to delete a remote git branch? +------------- +``` +git push origin --delete +``` +### How to delete the merge orig file? +------------- +Some automatically generated `*.orig` files will be left in your working folder after a successful merge. One quick way to delete them could be + +``` +git clean -f +``` + +**Beware** There's no going back. Use `-n` or `--dry-run` to preview the damage you'll do. + `git-clean` Remove untracked files from the working tree +If you want to also remove directories, run `git clean -f -d` +If you just want to remove ignored files, run `git clean -f -X` +If you want to remove ignored as well as non-ignored files, run `git clean -f -x` +Note the case difference on the X for the two latter commands. + +### How to know the remote branch names? +------------- +OK, you got a huge repository, maybe the first step is to know the remote branch names. + +``` +git branch -r +``` +### How to rename a file? + +``` +$ git mv README README.md +$ git commit -m "renamed" +$ git push origin master +``` + +### How to pull a remote branch? +------------- +Before you can start working locally on a remote branch, you need to fetch it as called out in answers below. +To fetch a branch, you simply need to: + +``` +git fetch origin +git branch -r +``` + +This will fetch all of the remote branches for you. With the remote branches in hand, you now need to check out the branch you are interested in, giving you a local working copy: + +``` +git checkout -b test origin/test +``` + diff --git a/_posts/2014/2014-02-06-Air-Application-Debug-in-Android.md b/_posts/2014/2014-02-06-Air-Application-Debug-in-Android.md new file mode 100644 index 0000000..1601a07 --- /dev/null +++ b/_posts/2014/2014-02-06-Air-Application-Debug-in-Android.md @@ -0,0 +1,39 @@ +--- +layout: post +title: Adobe Air App跑在Android上的兼容性问题 +categories: +- Technology +tags: +- Adobe Flex, Adobe Air, Android, Flash Builder +--- + +> 这一两个月又把Flash Builder捡起来做了一段时间的Air开发。要求Air APP要能同时运行在PC, Android上。遇到兼容性问题现在全部解决。 + +### Input控件不能输入中文 +解决之道，在FB的编译选项里有一个Language的参数，删除就行了。 +### APP的视频在某平板上不能显示H.264的视频 +花了一个多星期才搞定，各种Debug。最终发现是Air Runtime版本的问题。Android Market上只有最新版的Air，到哪里才能找到不同的版本呢？经过一番查找，最终在联想的乐商店找到了各种历史版本，然后一个个的试，终于Air 3.1上跑出来了。 + +### 关于Air Runtime的Tips: + +* TIP 1 + +由于Air的版本不停更新，如何保证在旧版上测试并发布过的APP在用户更新了Air Runtime后不会出兼容问题呢？答案是使用`Apk-captive-runtime`编译参数。示例如下： + +``` +adt -package -target apk‑captive‑runtime -storetype pkcs12 -keystore SigningCert_test.p12 InStoreApp.apk InStoreApp-app.xml InStoreApp.swf icons res Default.png +``` +这个参数的作用是把Air Runtime绑定在APK中，这样不用用户去单独安装Air，即使用户安装了其它的版本也不会被用到。 + +* TIP 2 + +AIR的SDK目前是3.9，但FB 4.7中自带的还是3.1。如何在FB中升级或切换使用不同的AIR　SDK？官方有如下两篇文档，但是没说清楚反而误导群众。 + +> [http://helpx.adobe.com/flash-builder/kb/overlay-air-sdk-flash-builder.html](http://helpx.adobe.com/flash-builder/kb/overlay-air-sdk-flash-builder.html) + +> [http://helpx.adobe.com/x-productkb/multi/how-overlay-air-sdk-flex-sdk.html](http://helpx.adobe.com/flash-builder/kb/overlay-air-sdk-flash-builder.html) + +需要补充的是，我们要下载**两个不同版本**的AIR　SDK，分别覆盖不同的文件目录（Flex SDK，和Plugin）。之前一定要**做好备份**。 + + + diff --git a/_posts/2014/2014-02-06-Seven-Habits-After-Read.md b/_posts/2014/2014-02-06-Seven-Habits-After-Read.md new file mode 100644 index 0000000..95dc85b --- /dev/null +++ b/_posts/2014/2014-02-06-Seven-Habits-After-Read.md @@ -0,0 +1,29 @@ +--- +layout: post +title: 《高效能人士的七个习惯》读后感 +categories: +- Learning +tags: +- Reading +--- + +### 简介 +----------- +这里有本书的一个详细的[百度百科介绍](http://baike.baidu.com/link?url=zBc7rQB2Us-Z2tuFvTaxdsasSSoWuRwyXynXJbEegTGIprxJC6ruWaYZGNMg83gy) + +### 远不止七个习惯 +------------- +一般来说，近期社科类的书中标题党比较多，只要浏览一下标题和第一章，整本书就不用看了。应该说高效能人士的七个习惯还是比较有货的，全书的内容用七个习惯来概括，但整本书有一个完整的理论体系，从任务管理到社交，各个分散的要点都是整体的一部分，每一部分都有自我评分表使得评估与改进可以量化。 + +### 关注第二类任务 +-------------- +无论如何有货，这一类型的书总是类似的，不可能处处是创新。个人于本书的唯一的收获在于关于任务优先级的一段论述。日常工作任务被分成4类。 + +* 第一类是必须按时交付的KPI与紧急任务之类。 +* 第二类是有助于生产力提高但不在考核之列的，比如自我提升，人际关系等。 +* 第三类是非重点的次要任务。 +* 第四类是休闲之类。 + +该书提出仅仅把工作重心放在第一类是远不够的，第二类往往被人忽视，这导致人们总是疲于奔命。但是高效能人士总是未雨绸缪，第二类任务才是他们关注的重点。想想看这个规则解释了为什么公司里的老黄牛并不是职业发展最好的。作为程序员，总有敲不完的代码，但总归还是要拿出时间学习新东西，才能跟得上发展。会的不难，知识积累上去了，产出自然会提高，对于知识型员工这一点尤为重要。回想因为兴趣自己去年用了很多业余时间学git，好像与工作没有什么关系，但是突然就遇到一个项目，其有2G大小的代码库，之前学的看似无用的东西一下发挥了价值。试想一下等到开发任务来的时候还要再学git该有多大的压力。 + +谷歌给员工20％的时间自由支配，似乎正好暗合了这一点。 \ No newline at end of file diff --git a/_posts/2014/2014-02-18-Git-学习路线图及中文资料推荐.md b/_posts/2014/2014-02-18-Git-学习路线图及中文资料推荐.md new file mode 100644 index 0000000..6235b68 --- /dev/null +++ b/_posts/2014/2014-02-18-Git-学习路线图及中文资料推荐.md @@ -0,0 +1,77 @@ +--- +layout: post +title: Git-学习路线图及中文资料推荐 +categories: +- Technology +tags: +- Git +--- + + +> 人生若只如初见，所有往事都化为江南的一场烟雨，在相视一笑中，随风荡漾起回忆的波纹，然后再渐渐隐去在画中的江南，只因为你的离去，我竟为你留下的惊艳 ... + +本文针对那些对GIT有**初见**感觉的攻城狮们。 + +--------------------- +![](/media/pic2014/0218-0.png) + +## 引子 +一开始GIT给人感觉很简单，但一用起来又觉得每个地方都捉襟见肘。其实git的学习曲线要比想象中的更为陡峭，有近20个常用命令，每个命令又有20个左右常用的参数，相互组合使用。要学好的话学习量绝对不低于新学一门语言和其常用类库，因其大多数操作都有相近的实现方式，但结果又各不相同，所以蒋薪的《git权威指南》才写了595页。可是很多人并不喜欢大部头通读的方式，而更便爱边用边学。所幸git除官方文档外还有众多开源文档，其中比较著名的文档都有中文翻译。高质量的中文文档的阅读更高效，这里就是我note里收集的一些相关网络书籍，以由易向难的顺序介绍。 + +--------------------- + +## 入门级 + +### [Git的维基定义](http://zh.wikipedia.org/wiki/Git) +为什么要叫GIT? 作为Linux创始人Torvalds的大作，不了解它的历史总有点说不过去。 + + +### [git - 简易指南](http://rogerdudler.github.io/git-guide/index.zh.html) +图文并貌，大名鼎鼎，无数的人就是看了这篇文章后觉得GIT挺好用呀，然后，然后就掉坑里了。 + +--------------------- +## 初级到中级 + +这个时候首先你要有一个练习用的GIT库，还得拿那个库干点事。推荐在github.com注册个账号建一个练习库，然后在本地克隆两份，用来模拟两个程序员之间的同步和练习下面推荐教程中的命令。 + +### [PRO GIT](http://git-scm.com/book/zh) +本书具有一定的官方性质，是正式出版物的免费版，学习Git的屠龙刀。其深入浅出，长度适中，讲解精练到位，结构合理，通读此书是提升功力的捷径。 + +### [图解Git](http://marklodato.github.io/visual-git-guide/index-zh-cn.html) +真是一图胜千言，在众多文档中此文可以算是出奇制胜，其它文档中较难理解的东西到了这里迎刃而解，称之为倚天剑毫不过分。倚天配屠龙 - 可在读'Pro Git'时配套用。 + +### [Git Magic](http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/zh_cn/ch02.html) +斯坦福血统，内容覆盖广，但解释偏少，可在读完'Pro Git'之后用来开拓思路。 + +### [Git Community Book 中文版](http://gitbook.liuhui998.com/index.html) +因为程度上本书和'Pro Git'冲突，本人没有读过此书，但仅看其完整的体系结构和中文翻译是值得推荐的。 + +### [Git分支管理策略](http://www.ruanyifeng.com/blog/2012/07/git.html) +了解branch指令是一回事，怎么管理这些branch又是另一回事。'Pro Git'有分支管理的章节，不过没有这里说的详细。 + +### GitHub相关 +相信不少人在学习GIT的过程中都有在Github上建blog的冲动，下面是一些对Github不错的介绍。搭建Blog本身也是一个GIT学习和使用的过程。 +[如何高效利用GitHub](http://www.yangzhiping.com/tech/github.html) +[蒋薪-GitHub](http://www.worldhello.net/gotgithub/) +上文的作者'蒋薪'正是那本595页《git权威指南》的作者。 + +### 其它 +[Git 教學](http://blog.gogojimmy.net/2012/01/17/how-to-use-git-1-git-basic/) +三篇繁体中文，优点在于有图示。 + +[Git中级用法](http://blackanger.blog.51cto.com/140924/123399) +排版不是很好，但GIT中比较关键的地方讲的不错，开扩视野用吧。 + +### [Git GUI Clients](http://git-scm.com/downloads/guis) +为了本文的完整性加进来的英文页面，好在这不是教材，无伤大雅。 + +### [Git Cookbook](http://blog.sevenche.com/2014/02/Git-cook-book/) +这是本人的作品哈，里面是一些有用的小技巧。比如说你一上手拿到一个3G大小的库，众多的分支，怎么开始工作？ + +--------------------- + +## 高级阶段 +看书是到不了这个阶段的，只有靠自己修行了。这个时候的老师就一个～谷哥。 + +> 题外的一点感悟，众多的提交历史和方便的Diff功能使得GIT库成为一个学习的宝库。比如作者一上来拿到一个3G的库，几乎没有文档，先自己跟据分支的历史找到常用的分支。想知道一个功能怎么实现的就grep提交历史，找到相关提交后再diff一下就什么都清楚了，比在IDE里查的还快。 + diff --git a/_posts/2014/2014-02-28-Implement-QoS-On-Iptables.md b/_posts/2014/2014-02-28-Implement-QoS-On-Iptables.md new file mode 100644 index 0000000..366d6e0 --- /dev/null +++ b/_posts/2014/2014-02-28-Implement-QoS-On-Iptables.md @@ -0,0 +1,87 @@ +--- +layout: post +title: 如何在Linux下实现QoS +categories: +- Technology +tags: +- Telephone +--- + +QoS本身是一个比较大的话题，但是毫无疑问，对于音频，视频应用来说QoS的作用是巨大的。有工程师跟我说过在实施时加不加QoS有很大的差别。这里特别提醒一下QoS要在网络的所有结点上启用才能发挥最大效果（结点包括，路由器，服务器等），最起码也要保证加在比较繁忙的结点上，不然没有多大意义。 +下面是在Linux服务器上通过iptables给相关端口加上高优先级的脚本。大家可以举一反三给特定的IP包加上优先级。 + +``` + +LOGFILE=/tmp/logs/iptables.log +SERVICE=`which service` +IPTABLES_STATUS=`$SERVICE iptables status 2> /dev/null | head -n 1` +if [ `rpm -qa iptables|grep -c iptables` -eq 0 -o -z "$IPTABLES_STATUS" ]; then + echo `date +"%F %T"` " - IPTABLES NOT INSTALLED!! QoS NOT SET!!\n" >> $LOGFILE + exit 1 +fi +if [ `echo "$IPTABLES_STATUS" | grep -c stopped` -gt 0 ]; then + echo `date +"%F %T"` " - IPTABLES is stopped and will be started!\n" >> $LOGFILE +fi + +IPTABLES="$(which iptables)" + +# RESET DEFAULT POLICIES +$IPTABLES -P INPUT ACCEPT +$IPTABLES -P FORWARD ACCEPT +$IPTABLES -P OUTPUT ACCEPT +$IPTABLES -t nat -P PREROUTING ACCEPT +$IPTABLES -t nat -P POSTROUTING ACCEPT +$IPTABLES -t nat -P OUTPUT ACCEPT +$IPTABLES -t mangle -P PREROUTING ACCEPT +$IPTABLES -t mangle -P OUTPUT ACCEPT + +# FLUSH ALL RULES, ERASE NON-DEFAULT CHAINS +$IPTABLES -F +$IPTABLES -X +$IPTABLES -t nat -F +$IPTABLES -t nat -X +$IPTABLES -t mangle -F +$IPTABLES -t mangle -X + +# ADD QoS RULES +$IPTABLES -t mangle -A OUTPUT -p tcp --sport 1935 -j DSCP --set-dscp 0x22 +$IPTABLES -t mangle -A OUTPUT -p tcp --sport 443 -j DSCP --set-dscp 0x22 +$IPTABLES -t mangle -A OUTPUT -p tcp --sport 5060 -j DSCP --set-dscp 0x22 +$IPTABLES -t mangle -A OUTPUT -p tcp --sport 5061 -j DSCP --set-dscp 0x22 +$IPTABLES -t mangle -A OUTPUT -p tcp --dport 5060 -j DSCP --set-dscp 0x22 +$IPTABLES -t mangle -A OUTPUT -p tcp --dport 5061 -j DSCP --set-dscp 0x22 + +echo "******" `date +"%F %T"` "******" >> $LOGFILE +$SERVICE iptables save >> $LOGFILE +echo "$IPTABLES -t mangle -L" >> $LOGFILE +``` +其原理非常简单，就是给所有通过某端口的包加上(`mangle`)特定标志(`dscp 0x22`)，这样经过的节点只要支持QoS都会给于相应的优先级。脚本中的`dscp 0x22`是针对Avaya和北电的产品的，不同厂商的产品可能使用不同的数字，请参考单独的页面介绍[Notes on QOS for videoconferencing](http://andrew.triumf.ca/vidconf_QOS.html)。加完后你的`ipdables`看起来应该是这个样子。然后你的包就会优先被处理了。 + +``` +Chain POSTROUTING (policy ACCEPT) +target prot opt source destination +************************************ +****** 2013-11-27 16:06:20 ****** +iptables: Saving firewall rules to /etc/sysconfig/iptables: ESC[60G[ESC[0;32m OK ESC[0;39m] +/sbin/iptables -t mangle -L +Chain PREROUTING (policy ACCEPT) +target prot opt source destination + +Chain INPUT (policy ACCEPT) +target prot opt source destination + +Chain FORWARD (policy ACCEPT) +target prot opt source destination + +Chain OUTPUT (policy ACCEPT) +target prot opt source destination +DSCP tcp -- anywhere anywhere tcp spt:macromedia-fcs DSCP set 0x22 +DSCP tcp -- anywhere anywhere tcp spt:https DSCP set 0x22 +DSCP tcp -- anywhere anywhere tcp spt:sip DSCP set 0x22 +DSCP tcp -- anywhere anywhere tcp spt:sip-tls DSCP set 0x22 +DSCP tcp -- anywhere anywhere tcp dpt:sip DSCP set 0x22 +DSCP tcp -- anywhere anywhere tcp dpt:sip-tls DSCP set 0x22 + +Chain POSTROUTING (policy ACCEPT) +target prot opt source destination +``` \ No newline at end of file diff --git a/_posts/2014/2014-02-28-Linus-Torvalds-rules-for-using-Git.md b/_posts/2014/2014-02-28-Linus-Torvalds-rules-for-using-Git.md new file mode 100644 index 0000000..2e9fc35 --- /dev/null +++ b/_posts/2014/2014-02-28-Linus-Torvalds-rules-for-using-Git.md @@ -0,0 +1,188 @@ +--- +layout: post +title: 发明人Linus Torvalds给出的Git使用建议 +categories: +- Technology +tags: +- Git +--- + + +> **导读** + + +> - 博主自己大约花了二十分钟用来阅读本文，如果你时间不够，请先收藏。 +> - 本文分为两部分，第一部分较为概略，一般要读到第二部分时才能明白前面说的是什么。 +> - 本文精彩的论述了什么时候用rebase，什么时候不能用。同时分析了使用Pull,Merge,Push的时机。 + +###引言 +如何更好的使用Git？作为Git的发明人Torvalds会给出什么样的建议呢？ +[Linus Torvalds的博客](http://torvalds-family.blogspot.sg/)和他的Mail list里提到过使用Git的一些注意事项。（该Blog可能国内被墙） + +现在开始挖坟啦！话说2009年的某一天Linux 2.6.31内核的分枝合并工作进行的很顺利（你知道现在Linux内核的版本号吗？），Torvalds的心情大好于是就写下一篇与Git有一点点关系的[blog](http://torvalds-family.blogspot.sg/2009/06/happiness-is-warm-scm.html)，然后后面有两个人在回复里问Git应该怎么用呢？ + +###问题 +>As a Git n00b, would be nice to see a post on what these "rules that work" are. + +Linus Torvalds刚好心情大好就给整理了一下。 + +###Linus回答 + +It's basically a matter of finding the right balance on a couple of different axises: + +"clean history": + +Balancing the need to clean up after mistakes (aka "rewriting history") using tools like 'git rebase', but then not doing it so much that you actually rewrite other peoples commits or lose all sight of the important history (like the fact that you tested one particular test, and if you then rewrite the history, all your testing is now dubious). + +"Merging too much vs too little": + +Merging is nice, because if you have concurrent development, a merge will tie the two branches together and allows you to test and develop on top of both changes. + +But the downside is that merging too eagerly means that two separate branches that are for two different features are now tied together, and you can never separate the two (at least without re-doing the whole history). + +So merging too much results in a very messy history, where you can't see what the actual different "topics" were. And it results in a tree where upstream (that is - me) can't review and pull the features one by one. + +There's a few rants and rules about this that I did on the mailing lists last merge window. See for example [rant](http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html) + +###另一个Mail List里的意见 +我也给复制过来了，这样更完整一点。 + +###邮件上下文 +> My plans from now on are just to send you non-linear trees, whenever I +> merge a patch into my next tree thats when it stays in there, I'll pull +> Eric's tree directly into my tree and then I'll send the results, I +> thought we cared about a clean merge history but as I said without some +> document in the kernel tree I've up until now had no real idea what you +> wanted. + +###Linus回答 +> 注意Linus的原文就是用Markdown格式写的，下面是原文，我没有加入任何Markdown格式。说明Linus在写邮件的时候是极为注意细节的。大家可以去查看[原文的Raw格式](http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html) + + +I want clean history, but that really means (a) clean and (b) history. + +People can (and probably should) rebase their _private_ trees (their own +work). That's a _cleanup_. But never other peoples code. That's a "destroy +history" + +So the history part is fairly easy. There's only one major rule, and one +minor clarification: + + - You must never EVER destroy other peoples history. You must not rebase + commits other people did. Basically, if it doesn't have your sign-off + on it, it's off limits: you can't rebase it, because it's not yours. + + Notice that this really is about other peoples _history_, not about + other peoples _code_. If they sent stuff to you as an emailed patch, + and you applied it with "git am -s", then it's their code, but it's + _your_ history. + + So you can go wild on the "git rebase" thing on it, even though you + didn't write the code, as long as the commit itself is your private + one. + + - Minor clarification to the rule: once you've published your history in + some public site, other people may be using it, and so now it's clearly + not your _private_ history any more. + + So the minor clarification really is that it's not just about "your + commit", it's also about it being private to your tree, and you haven't + pushed it out and announced it yet. + +That's fairly straightforward, no? + +Now the "clean" part is a bit more subtle, although the first rules are +pretty obvious and easy: + + - Keep your own history readable + + Some people do this by just working things out in their head first, and + not making mistakes. but that's very rare, and for the rest of us, we + use "git rebase" etc while we work on our problems. + + So "git rebase" is not wrong. But it's right only if it's YOUR VERY OWN + PRIVATE git tree. + + - Don't expose your crap. + + This means: if you're still in the "git rebase" phase, you don't push + it out. If it's not ready, you send patches around, or use private git + trees (just as a "patch series replacement") that you don't tell the + public at large about. + +It may also be worth noting that excessive "git rebase" will not make +things any cleaner: if you do too many rebases, it will just mean that all +your old pre-rebase testing is now of dubious value. So by all means +rebase your own work, but use _some_ judgement in it. + +NOTE! The combination of the above rules ("clean your own stuff" vs "don't +clean other peoples stuff") have a secondary indirect effect. And this is +where it starts getting subtle: since you most not rebase other peoples +work, that means that you must never pull into a branch that isn't already +in good shape. Because after you've done a merge, you can no longer rebase +you commits. + +Notice? Doing a "git pull" ends up being a synchronization point. But it's +all pretty easy, if you follow these two rules about pulling: + + - Don't merge upstream code at random points. + + You should _never_ pull my tree at random points (this was my biggest + issue with early git users - many developers would just pull my current + random tree-of-the-day into their development trees). It makes your + tree just a random mess of random development. Don't do it! + + And, in fact, preferably you don't pull my tree at ALL, since nothing + in my tree should be relevant to the development work _you_ do. + Sometimes you have to (in order to solve some particularly nasty + dependency issue), but it should be a very rare and special thing, and + you should think very hard about it. + + But if you want to sync up with major releases, do a + + git pull linus-repo v2.6.29 + + or similar to synchronize with that kind of _non_random_ point. That + all makes sense. A "Merge v2.6.29 into devel branch" makes complete + sense as a merge message, no? That's not a problem. + + But if I see a lot of "Merge branch 'linus'" in your logs, I'm not + going to pull from you, because your tree has obviously had random crap + in it that shouldn't be there. You also lose a lot of testability, + since now all your tests are going to be about all my random code. + + - Don't merge _downstream_ code at random points either. + + Here the "random points" comment is a dual thing. You should not mege + random points as far as downstream is concerned (they should tell you + what to merge, and why), but also not random points as far as your tree + is concerned. + + Simple version: "Don't merge unrelated downstream stuff into your own + topic branches." + + Slightly more complex version: "Always have a _reason_ for merging + downstream stuff". That reason might be: "This branch is the release + branch, and is _not_ the 'random development' branch, and I want to + merge that ready feature into my release branch because it's going to + be part of my next release". + +See? All the rules really are pretty simple. There's that somewhat subtle +interaction between "keep your own history clean" and "never try to clean +up _other_ proples histories", but if you follow the rules for pulling, +you'll never have that problem. + +Of course, in order for all this to work, you also have to make sure that +the people you pull _from_ also have clean histories. + +And how do you make sure of that? Complain to them if they don't. Tell +them what they should do, and what they do wrong. Push my complaints down +to the people you pull from. You're very much allowed to quote me on this +and use it as an explanation of "do this, because that is what Linus +expects from the end result". + + Linus +###总结 +Linus特别注意提交历史的干净与可读，其中给出了rebase应该的使用场境。 + +> 附本文相关文章--[Git-学习路线图及中文资料推荐](http://blog.sevenche.com/2014/02/Git-%E5%AD%A6%E4%B9%A0%E8%B7%AF%E7%BA%BF%E5%9B%BE%E5%8F%8A%E4%B8%AD%E6%96%87%E8%B5%84%E6%96%99%E6%8E%A8%E8%8D%90/) diff --git a/_posts/2014/2014-03-17-Git_merge_--squash_and_git_rebase.md b/_posts/2014/2014-03-17-Git_merge_--squash_and_git_rebase.md new file mode 100644 index 0000000..cfa583e --- /dev/null +++ b/_posts/2014/2014-03-17-Git_merge_--squash_and_git_rebase.md @@ -0,0 +1,72 @@ +--- +layout: post-en +title: git merge --squash and git rebase explained +categories: +- Common Tec +tags: +- Git +--- + +> One advantage for Git comes from its powerful branch management capability, but it will be hard to maintain the commit history between different branches. As Linus said that [Clear and Clean is important for the commit history](http://blog.sevenche.com/2014/02/Linus-Torvalds-rules-for-using-Git/), here in this article I am going to demonstrate how `git merge --squash`, `git merge`, and `git rebase` will affect the commit history. + +### `git merge` and `git merge --squash` + +In below example I am going to merge `dev3` into `dev2` and `dev4` by using merge with and without `--squash` parameter. + +** Initial status ** + +![](/media/pic2014/0317-2.png) + +**merge with `--squash` test** + +``` +git checkout dev4 +git merge --squash dev3 +git commit -a +``` + +![git merge](/media/pic2014/0317-3.png) + +We can see changed files in working directory and after commit we don't see `fbcb87a` and `b85fcb7` in the history of `dev4` + +**Plain merge ** + +``` +git checkout dev2 +git merge dev3 +``` + +![git plain merge](/media/pic2014/0317-4.png) + +Now `dev4` and `dev2` have the same content, but we cannot see `dev4` contains commits form `dev3`, but `dev2` has the information. + +** Conclusion ** + +`--squash` will abandon the merge history, so you will not know what was merged. Only use it when you don't want these commit history! + +------------------------ + +### Rebase + +`git rebase` acts like automatically `cherrypick` commits into current branch and then reapply the commits in current branch. See below example. + +** Before rebase ** + +![Before rebase](/media/pic2014/0317-0.png) + +** rebase ** + +``` +git checkout dev +git rebase master +``` + +** After rebase ** + +> Notice: dev commit ccd4673 changed to 9d76e0b + +![After rebase](/media/pic2014/0317-1.png) + +** Conclusion** + +Rebase do not like merge - which will cause a commit, and from the tree you cannot see when the dev is split out and when it is merged back. - So Linus calls it is a _clean_ for history. \ No newline at end of file diff --git a/about/index.md b/about/index.md index 35618af..871e3b0 100755 --- a/about/index.md +++ b/about/index.md @@ -8,4 +8,5 @@ comments: yes 个人邮箱:dashjim@gmail.com 新浪微博: [http://weibo.com/jijunxiang](http://weibo.com/jijunxiang) -github : [https://github.com/dashjim](https://github.com/dashjim) \ No newline at end of file +github : [https://github.com/dashjim](https://github.com/dashjim) +Linkedin: [Ji Junxiang at Linkedin](http://www.linkedin.com/pub/junxiang-ji/58/97/b90) \ No newline at end of file diff --git a/favicon.ico b/favicon.ico new file mode 100644 index 0000000..3724181 Binary files /dev/null and b/favicon.ico differ diff --git a/media/css/screen.css b/media/css/screen.css index d7e7800..8c4b860 100644 --- a/media/css/screen.css +++ b/media/css/screen.css @@ -44,6 +44,7 @@ body { ol, ul { list-style: none; } +/* blockquote, q { quotes: none; } @@ -52,6 +53,14 @@ q:before, q:after { content: ''; content: none; } +** JIM added below blockquote style*/ +.content blockquote { + border-left: 4px solid #DDDDDD; + color: #777777; + padding: 0 15px; + margin: 15px 0; +} + table { border-collapse: collapse; border-spacing: 0; @@ -91,6 +100,7 @@ h2 { font-size: 26px; line-height: 48px; margin: 0 0 24px 0; + font-weight: bold; } h2 i { font-size: 18px; @@ -99,10 +109,16 @@ h2 i { h3 { font-size: 18px; line-height: 24px; + font-weight: bold; } section>h3 { margin: 0 0 24px 0; } +h4 { + font-size: 16px; + line-height: 12px; + font-weight: bold; +} p, ul, ol, dl { line-height: 24px; margin: 0 0 24px 0; @@ -144,9 +160,11 @@ hr { } a { color: #EE0000; + text-decoration: none; } a:visited { color: #B22222; + text-decoration: none; } a.ss-icon { font-size: 20px; diff --git a/media/pic2014/0201-1.png b/media/pic2014/0201-1.png new file mode 100644 index 0000000..cdd268c Binary files /dev/null and b/media/pic2014/0201-1.png differ diff --git a/media/pic2014/0201-2.png b/media/pic2014/0201-2.png new file mode 100644 index 0000000..e56fb7d Binary files /dev/null and b/media/pic2014/0201-2.png differ diff --git a/media/pic2014/0201-3.png b/media/pic2014/0201-3.png new file mode 100644 index 0000000..f55d507 Binary files /dev/null and b/media/pic2014/0201-3.png differ diff --git a/media/pic2014/0201-4.png b/media/pic2014/0201-4.png new file mode 100644 index 0000000..1d835cd Binary files /dev/null and b/media/pic2014/0201-4.png differ diff --git a/media/pic2014/0201-5.png b/media/pic2014/0201-5.png new file mode 100644 index 0000000..0404fbb Binary files /dev/null and b/media/pic2014/0201-5.png differ diff --git a/media/pic2014/0201-6.png b/media/pic2014/0201-6.png new file mode 100644 index 0000000..42e8009 Binary files /dev/null and b/media/pic2014/0201-6.png differ diff --git a/media/pic2014/0203-1.png b/media/pic2014/0203-1.png new file mode 100644 index 0000000..839d622 Binary files /dev/null and b/media/pic2014/0203-1.png differ diff --git a/media/pic2014/0218-0.png b/media/pic2014/0218-0.png new file mode 100644 index 0000000..b844197 Binary files /dev/null and b/media/pic2014/0218-0.png differ diff --git a/media/pic2014/0317-0.png b/media/pic2014/0317-0.png new file mode 100644 index 0000000..1ffcc72 Binary files /dev/null and b/media/pic2014/0317-0.png differ diff --git a/media/pic2014/0317-1.png b/media/pic2014/0317-1.png new file mode 100644 index 0000000..5ddda16 Binary files /dev/null and b/media/pic2014/0317-1.png differ diff --git a/media/pic2014/0317-2.png b/media/pic2014/0317-2.png new file mode 100644 index 0000000..f4cab9c Binary files /dev/null and b/media/pic2014/0317-2.png differ diff --git a/media/pic2014/0317-3.png b/media/pic2014/0317-3.png new file mode 100644 index 0000000..4adb57e Binary files /dev/null and b/media/pic2014/0317-3.png differ diff --git a/media/pic2014/0317-4.png b/media/pic2014/0317-4.png new file mode 100644 index 0000000..ed562ae Binary files /dev/null and b/media/pic2014/0317-4.png differ