最近开始对炒外汇感兴趣, 先来说说为什么要炒外汇, 也就是炒外汇的好处吧. (一开始就说风险不把别人吓跑才怪) 以下都是从网上收集来的:
1. 交易成本低,无需佣金
外汇投资者无需通过代理机构来进行交易，因此不会被收取交易佣金。外汇交易商的利润仅从报价点差中来。如 EUR/USD 1.4225/1.4227，其中仅有的 2 个点的点差就是交易者的成本。股票交易通常会收取 $7 至 $20 不等的交易佣金(也有根据交易量大小计算费用)，买进卖出一个来回，佣金将被收取两次。相对而言，外汇的交易成本要小得多。
2. 无论熊市牛市, 获利机会均等
在股市中，投资者如果想卖空(Short)利用熊市来获利，将面对诸多限制。如较高的保证金要求 (通常是卖空仓位市值的 150% 左右)、提高报价规则(uptick rule)以及借贷成本等。而外汇的做空机制非常灵活，没有任何限制，外汇交易者能自由地借助市场的涨势和跌势来投资获利。
3. 24小时全球交易
外汇市场是一个 24 小时永不停滞的全球市场，交易者可以根据自己的生活习惯安排交易时间。这也是为什么众多上班族选择炒汇的原因之一。同时，越来越多的人开始利用股市休市的时间交易外汇，把其当作一项分散投资风险的有效渠道。
4. 高至200:1的杠杆(据个人了解外汇杠杆可以高达400:1甚至500:1)
外汇交易中提供的杠杆比率通常是股票交易的 100 倍。比如，在股市中投资者能用 $1,000 来买价值 $2,000 的股票，而通过高达 200:1 的杠杆，外汇交易者可以用同样的 $1,000 来获得 $200,000 的购买力。显然，外汇交易以小博大的效力，是远胜于股票的。
当然，我们必须认识到，杠杆比率是一把双刃剑，它能使投资者迅速获利，同时也很容易增加风险。
5. 瞬间交割无限制
外汇市场是短线投资者的乐园，因为交易者能在一日内自由进出场，瞬间即可成交，随时兑现盈利。而股票交易者若想进行短线交易(Day Trading)，将面对诸多限制，如交易者必须满足 $25,000 的最低保证金要求等。
6. 8000支股票 VS 7种主要货币
纽约证交所和那斯达克两所股市中有 8000 支以上的股票，面对繁多的市场杂讯，选股成为一件令投资者头痛的事。而在外汇市场中，7 种主要货币集中了 85% 的交易量，这使交易者能更快选择投资对象，节约时间和资金。
Wednesday, August 5, 2009
refactoring and performance
Many programmers always put performance at the first place in development. However, in my opinion, performance should be the last and least thing we need to worry about. Let's have a look at what Martin Fowler says in his book - Refactoring.
"To make the software easier to understand, you often make changes that will cause the program to run more slowly...but it also makes the software more amenable to performance tuning. The secret to fast software...is to write tunable software first and then to tune it for sufficient speed."
"Changes that improve performance usually make the program harder to work with"
"Build your programm in a well-factored manner without paying attention to performance until you begin a performance optimization stage, usually fairly late in development."
"A well-factored program ... gives you time to spend on performance tunning... Because the code is clearer, you have better understanding of your options and of what kind of tuning will work."
I always believe the first task for developer is to make the software easy to maintain, extend, modify. It also means we should focus more on architecture, structure, design, and coding style.
Unfortunately most of performance-first developers haven't realized that their performance achieved coding creates buggy, hard to understand and maintain system and finally achieves nothing but lost.
Why do we not just use assembly language for programming? We can get better performance than using C++, Java, PHP.
Why do we prefer OOP instead of coding in native language way? Native PHP language code runs faster than OOP code with those classes, objects.
Why do we break code into smaller pieces and functions? Putting everything in one function can save a lot of time than calling other functions and then return to the caller.
Why do we use template engine? Why not just embed PHP into HTML? It is faster.
Why do we use framework? It absolutely runs slower than a index.php.
Why do we use java? Every performance oriented programmer is crying Java is slow.
"To make the software easier to understand, you often make changes that will cause the program to run more slowly...but it also makes the software more amenable to performance tuning. The secret to fast software...is to write tunable software first and then to tune it for sufficient speed."
"Changes that improve performance usually make the program harder to work with"
"Build your programm in a well-factored manner without paying attention to performance until you begin a performance optimization stage, usually fairly late in development."
"A well-factored program ... gives you time to spend on performance tunning... Because the code is clearer, you have better understanding of your options and of what kind of tuning will work."
I always believe the first task for developer is to make the software easy to maintain, extend, modify. It also means we should focus more on architecture, structure, design, and coding style.
Unfortunately most of performance-first developers haven't realized that their performance achieved coding creates buggy, hard to understand and maintain system and finally achieves nothing but lost.
Why do we not just use assembly language for programming? We can get better performance than using C++, Java, PHP.
Why do we prefer OOP instead of coding in native language way? Native PHP language code runs faster than OOP code with those classes, objects.
Why do we break code into smaller pieces and functions? Putting everything in one function can save a lot of time than calling other functions and then return to the caller.
Why do we use template engine? Why not just embed PHP into HTML? It is faster.
Why do we use framework? It absolutely runs slower than a index.php.
Why do we use java? Every performance oriented programmer is crying Java is slow.
Thursday, July 2, 2009
中国试行社会养老
中国终于要实行社会养老了:http://news.sohu.com/20090702/n264931053.shtml
先在部分地方试行，然后覆盖全国．实行这项制度的意义是不言而喻的．养儿防老在中国农民家庭中是根深蒂固的．这也是为什么很多农民家庭一定要生儿子，生男孩，生很多男孩的原因之一（另一个原因是要增加劳动力）．这不能怪他们，因为中国农村生产力低下，而社会又不能为农民的老年提供保障．他们就只能指靠儿子了．
实行社会养老是一个重大改变．是完善社会保障制度的一个重要举措．虽然实施起来肯定会遇上不少困难，但一定要坚持下去，真正做到老有所养．
先在部分地方试行，然后覆盖全国．实行这项制度的意义是不言而喻的．养儿防老在中国农民家庭中是根深蒂固的．这也是为什么很多农民家庭一定要生儿子，生男孩，生很多男孩的原因之一（另一个原因是要增加劳动力）．这不能怪他们，因为中国农村生产力低下，而社会又不能为农民的老年提供保障．他们就只能指靠儿子了．
实行社会养老是一个重大改变．是完善社会保障制度的一个重要举措．虽然实施起来肯定会遇上不少困难，但一定要坚持下去，真正做到老有所养．
Monday, June 29, 2009
Convert Zend Framework project to UTF-8
Here is an article about converting Zend Framework project to UTF-8:
http://www.iezzi.ch/archives/371
http://www.iezzi.ch/archives/371
another post of PHP performance
http://php100.wordpress.com/2009/06/26/php-performance-google/
PHP performance tips from Google
Posted by Stas on June 26, 2009
I saw a link on twitter referring to PHP optimization advice from Google. There are a bunch of advices there, some of them are quite sound, if not new – like use latest versions if possible, profile your code, cache whatever can be cached, etc. Some are of doubtful value – like the output buffering one, which could be useful in some situations but do nothing or be worse in others, and if you’re a beginner generally it’s better for you to leave it alone until you’ve solved the real performance problems.
However some of the advices make no sense at best and are potentially harmful at worst. Let’s get to it:
First one: Don’t copy variables for no reason. I don’t know what the author intended to describe there, but PHP engine is refcounting copy-on-write, and there’s absolutely no copying going on when assigning variables as they described it:
$description = strip_tags($_POST['description']);
echo $description;
I don’t know where it comes from but it’s just not so, unless maybe in some prehistoric version of PHP. Which means unless you’re going back to 1997 in a time machine this advice is no good for you.
Next one: Avoid doing SQL queries within a loop. This actually might make sense in some situations, however the code examples they give there is missing one important detail that makes it potentially harmful for beginners (see if you can spot it):
$userData = [];
foreach ($userList as $user) {
$userData[] = '("' . $user['first_name'] . '", "' . $user['last_name'] . '")';
}
$query = 'INSERT INTO users (first_name,last_name) VALUES' . implode(',', $userData);
mysql_query($query);
Please repeat after me – DO NOT INSERT USER DATA INTO SQL WITHOUT SANITIZING IT!
Of course, I can not know that $user was not sanitized. Maybe the intent was that it was. But if you give such example and target beginners, you should say so explicitly, every time! People tend to copy/paste examples, and then you get SQL injection in a government site.
Another thing: most of real-life PHP applications usually do not insert data in bulk, except for some very special scenarios (bulk data imports, etc.) – so actually in most cases one would be better off using PDO and prepared statements. Or some higher-level frameworks which will do it for you. But if you roll your own SQL – sanitize the data! This is much more important than any performance tricks.
Next one: Use single-quotes for long strings. PHP code is parsed and compiled, and any possible difference in speed between parsing “” and ” is really negligible unless you operate with hundreds of megabyte-size strings embedded in your code. If you do so, your quotes probably aren’t where you should start optimizing. And of course, using caching (see below) eliminates this difference altogether.
Next one: Use switch/case instead of if/else. This makes no sense since switch does essentially the same things as if’s do. See for yourself, here is the “if” code:
0 2 A(0) = FETCH_R(C("_POST")) [global]
1 2 A(1) = FETCH_DIM_R(A(0), C("action")) [Standard]
2 2 T(2) = IS_EQUAL(A(1), C("add"))
3 2 JMPZ(T(2), 7)
4 3 INIT_FCALL_BY_NAME(function_table, C("addUser"))
5 3 Au(3) = DO_FCALL_BY_NAME() [0 arguments]
6 4 JMP(16)
7 4 A(4) = FETCH_R(C("_POST")) [global]
8 4 A(5) = FETCH_DIM_R(A(4), C("action")) [Standard]
9 4 T(6) = IS_EQUAL(A(5), C("delete"))
10 4 JMPZ(T(6), 14)
11 5 INIT_FCALL_BY_NAME(function_table, C("deleteUser"))
12 5 Au(7) = DO_FCALL_BY_NAME() [0 arguments]
13 6 JMP(16)
14 7 INIT_FCALL_BY_NAME(function_table, C("defaultAction"))
15 7 Au(8) = DO_FCALL_BY_NAME() [0 arguments]
16 9 RETURN(C(1))
17 9 HANDLE_EXCEPTION()
Here is the “switch” code:
0 2 A(0) = FETCH_R(C("_POST")) [global]
1 2 A(1) = FETCH_DIM_R(A(0), C("action")) [Standard]
2 3 T(2) = CASE(A(1), C("add"))
3 3 JMPZ(T(2), 8 )
4 4 INIT_FCALL_BY_NAME(function_table, C("addUser"))
5 4 Au(3) = DO_FCALL_BY_NAME() [0 arguments]
6 5 BRK(0, C(1))
7 6 JMP(10)
8 6 T(2) = CASE(A(1), C("delete"))
9 6 JMPZ(T(2), 14)
10 7 INIT_FCALL_BY_NAME(function_table, C("deleteUser"))
11 7 Au(4) = DO_FCALL_BY_NAME() [0 arguments]
12 8 BRK(0, C(1))
13 9 JMP(15)
14 9 JMP(19)
15 10 INIT_FCALL_BY_NAME(function_table, C("defaultAction"))
16 10 Au(5) = DO_FCALL_BY_NAME() [0 arguments]
17 11 BRK(0, C(1))
18 12 JMP(20)
19 12 JMP(15)
20 12 SWITCH_FREE(A(1))
21 13 RETURN(C(1))
22 13 HANDLE_EXCEPTION()
No. CONT BRK Parent
0 20 20 -1
You can see there’s a little difference – the latter has CASE/BRK opcodes, which act more or less like IS_EQUAL and JMP, but their plumbing is a bit different, but in general, code is the same (you could even argue “switch” code is a bit less optimal, but that is really the area you shouldn’t be concerned with before you can read and understand the code in zend_vm_def.h – which is not exactly a beginner stuff.
Another thing that the author absolutely failed to mention and which should be one of the very first things anybody who cares about performance should do – is to use a bytecode cache. There are plenty of free ones (shameless plug: Zend Server CE includes one of them – all the performance improvements for $0 and you don’t have to change a bit of code to run it.
Now, I understand Google is not a PHP shop like Yahoo or Facebook or many others. But this article is signed “Eric Higgins, Google Webmaster” and one would expect something much more sound from such source. And in fact there are a lot of blogs and conference talks on the topic and lots of community folks around that I am sure would be ready to help with such article – I wonder why wasn’t it done? Why apparently the best advice we can find from Google is either trivial or useless or wrong?
I think they can do much better, and they should if they take “making the web faster” seriously.
PHP performance tips from Google
Posted by Stas on June 26, 2009
I saw a link on twitter referring to PHP optimization advice from Google. There are a bunch of advices there, some of them are quite sound, if not new – like use latest versions if possible, profile your code, cache whatever can be cached, etc. Some are of doubtful value – like the output buffering one, which could be useful in some situations but do nothing or be worse in others, and if you’re a beginner generally it’s better for you to leave it alone until you’ve solved the real performance problems.
However some of the advices make no sense at best and are potentially harmful at worst. Let’s get to it:
First one: Don’t copy variables for no reason. I don’t know what the author intended to describe there, but PHP engine is refcounting copy-on-write, and there’s absolutely no copying going on when assigning variables as they described it:
$description = strip_tags($_POST['description']);
echo $description;
I don’t know where it comes from but it’s just not so, unless maybe in some prehistoric version of PHP. Which means unless you’re going back to 1997 in a time machine this advice is no good for you.
Next one: Avoid doing SQL queries within a loop. This actually might make sense in some situations, however the code examples they give there is missing one important detail that makes it potentially harmful for beginners (see if you can spot it):
$userData = [];
foreach ($userList as $user) {
$userData[] = '("' . $user['first_name'] . '", "' . $user['last_name'] . '")';
}
$query = 'INSERT INTO users (first_name,last_name) VALUES' . implode(',', $userData);
mysql_query($query);
Please repeat after me – DO NOT INSERT USER DATA INTO SQL WITHOUT SANITIZING IT!
Of course, I can not know that $user was not sanitized. Maybe the intent was that it was. But if you give such example and target beginners, you should say so explicitly, every time! People tend to copy/paste examples, and then you get SQL injection in a government site.
Another thing: most of real-life PHP applications usually do not insert data in bulk, except for some very special scenarios (bulk data imports, etc.) – so actually in most cases one would be better off using PDO and prepared statements. Or some higher-level frameworks which will do it for you. But if you roll your own SQL – sanitize the data! This is much more important than any performance tricks.
Next one: Use single-quotes for long strings. PHP code is parsed and compiled, and any possible difference in speed between parsing “” and ” is really negligible unless you operate with hundreds of megabyte-size strings embedded in your code. If you do so, your quotes probably aren’t where you should start optimizing. And of course, using caching (see below) eliminates this difference altogether.
Next one: Use switch/case instead of if/else. This makes no sense since switch does essentially the same things as if’s do. See for yourself, here is the “if” code:
0 2 A(0) = FETCH_R(C("_POST")) [global]
1 2 A(1) = FETCH_DIM_R(A(0), C("action")) [Standard]
2 2 T(2) = IS_EQUAL(A(1), C("add"))
3 2 JMPZ(T(2), 7)
4 3 INIT_FCALL_BY_NAME(function_table, C("addUser"))
5 3 Au(3) = DO_FCALL_BY_NAME() [0 arguments]
6 4 JMP(16)
7 4 A(4) = FETCH_R(C("_POST")) [global]
8 4 A(5) = FETCH_DIM_R(A(4), C("action")) [Standard]
9 4 T(6) = IS_EQUAL(A(5), C("delete"))
10 4 JMPZ(T(6), 14)
11 5 INIT_FCALL_BY_NAME(function_table, C("deleteUser"))
12 5 Au(7) = DO_FCALL_BY_NAME() [0 arguments]
13 6 JMP(16)
14 7 INIT_FCALL_BY_NAME(function_table, C("defaultAction"))
15 7 Au(8) = DO_FCALL_BY_NAME() [0 arguments]
16 9 RETURN(C(1))
17 9 HANDLE_EXCEPTION()
Here is the “switch” code:
0 2 A(0) = FETCH_R(C("_POST")) [global]
1 2 A(1) = FETCH_DIM_R(A(0), C("action")) [Standard]
2 3 T(2) = CASE(A(1), C("add"))
3 3 JMPZ(T(2), 8 )
4 4 INIT_FCALL_BY_NAME(function_table, C("addUser"))
5 4 Au(3) = DO_FCALL_BY_NAME() [0 arguments]
6 5 BRK(0, C(1))
7 6 JMP(10)
8 6 T(2) = CASE(A(1), C("delete"))
9 6 JMPZ(T(2), 14)
10 7 INIT_FCALL_BY_NAME(function_table, C("deleteUser"))
11 7 Au(4) = DO_FCALL_BY_NAME() [0 arguments]
12 8 BRK(0, C(1))
13 9 JMP(15)
14 9 JMP(19)
15 10 INIT_FCALL_BY_NAME(function_table, C("defaultAction"))
16 10 Au(5) = DO_FCALL_BY_NAME() [0 arguments]
17 11 BRK(0, C(1))
18 12 JMP(20)
19 12 JMP(15)
20 12 SWITCH_FREE(A(1))
21 13 RETURN(C(1))
22 13 HANDLE_EXCEPTION()
No. CONT BRK Parent
0 20 20 -1
You can see there’s a little difference – the latter has CASE/BRK opcodes, which act more or less like IS_EQUAL and JMP, but their plumbing is a bit different, but in general, code is the same (you could even argue “switch” code is a bit less optimal, but that is really the area you shouldn’t be concerned with before you can read and understand the code in zend_vm_def.h – which is not exactly a beginner stuff.
Another thing that the author absolutely failed to mention and which should be one of the very first things anybody who cares about performance should do – is to use a bytecode cache. There are plenty of free ones (shameless plug: Zend Server CE includes one of them – all the performance improvements for $0 and you don’t have to change a bit of code to run it.
Now, I understand Google is not a PHP shop like Yahoo or Facebook or many others. But this article is signed “Eric Higgins, Google Webmaster” and one would expect something much more sound from such source. And in fact there are a lot of blogs and conference talks on the topic and lots of community folks around that I am sure would be ready to help with such article – I wonder why wasn’t it done? Why apparently the best advice we can find from Google is either trivial or useless or wrong?
I think they can do much better, and they should if they take “making the web faster” seriously.
Monday, June 15, 2009
facebook username
I got my facebook username: hengrui.li, so now u can reach me at http://www.facebook.com/hengrui.li
Friday, June 12, 2009
vim中大小写转化
vim中大小写转化的命令是
gu或者gU
形象一点的解释就是小u意味着转为小写；大U意味着转为大写.
剩下的就是对这两个命令的限定（限定操作的行，字母，单词）等等
1、整篇文章大写转化为小写
打开文件后，无须进入命令行模式。键入:ggguG
解释一下：ggguG分作三段gg gu G
gg=光标到文件第一个字符
gu=把选定范围全部小写
G=到文件结束
2、整篇文章小写转化为大写
打开文件后，无须进入命令行模式。键入:gggUG
解释一下：gggUG分作三段gg gU G
gg=光标到文件第一个字符
gU=把选定范围全部大写
G=到文件结束
3、只转化某个单词
guw 、gue
gUw、gUe
这样，光标后面的单词便会进行大小写转换
想转换5个单词的命令如下：
gu5w、gu5e
gU5w、gU5e
4、转换几行的大小写
将光标定位到想转换的行上，键入：1gU 从光标所在行 往下一行都进行小写到大写的转换
10gU，则进行11行小写到大写的转换
以此类推，就出现其他的大小写转换命令
gU0 ：从光标所在位置到行首，都变为大写
gU$ ：从光标所在位置到行尾，都变为大写
gUG ：从光标所在位置到文章最后一个字符，都变为大写
gU1G ：从光标所在位置到文章第一个字符，都变为大写
gu或者gU
形象一点的解释就是小u意味着转为小写；大U意味着转为大写.
剩下的就是对这两个命令的限定（限定操作的行，字母，单词）等等
1、整篇文章大写转化为小写
打开文件后，无须进入命令行模式。键入:ggguG
解释一下：ggguG分作三段gg gu G
gg=光标到文件第一个字符
gu=把选定范围全部小写
G=到文件结束
2、整篇文章小写转化为大写
打开文件后，无须进入命令行模式。键入:gggUG
解释一下：gggUG分作三段gg gU G
gg=光标到文件第一个字符
gU=把选定范围全部大写
G=到文件结束
3、只转化某个单词
guw 、gue
gUw、gUe
这样，光标后面的单词便会进行大小写转换
想转换5个单词的命令如下：
gu5w、gu5e
gU5w、gU5e
4、转换几行的大小写
将光标定位到想转换的行上，键入：1gU 从光标所在行 往下一行都进行小写到大写的转换
10gU，则进行11行小写到大写的转换
以此类推，就出现其他的大小写转换命令
gU0 ：从光标所在位置到行首，都变为大写
gU$ ：从光标所在位置到行尾，都变为大写
gUG ：从光标所在位置到文章最后一个字符，都变为大写
gU1G ：从光标所在位置到文章第一个字符，都变为大写
Subscribe to:
Posts (Atom)