嘿嘿!
于2011年10月2日
分类：程序生活
解决1分2分5分硬币组合的数学问题
本文部分信息来源于 http://topic.csdn.net/u/20110913/21/54ef3c9d-6e86-4a4e-8359-cc8f0d728770.html
问题的提出如下：1分2分5分的硬币，组成1角，共有多少种组合，如果是组成1块，又有多少种组合。
这个问题看似很简单，答案为10种。但如果要真正去算，或者写程序来实现。想必大多数的人都会使用3层for循环来实现。即分别令i=0（表示1分),j=0(表示2分),k=0(表示5分），然后循环条件为3者之和小于10,得出的结果为三者之和大于10。即实现算术 x+2y+5z=10，然后求x,y,z的组合。
然而，问题在于提出的问题并没有问具体的组合方式，而是只问了究竟有多少种，那么如果再使用这种算法就有点得不偿失了。
文中有一个叫tsx86的解法，将此题变成了纯粹的数学题，如下所示：
如果这个和越大，那相应的复杂度会很高。所以
因此，本题目组合总数为10以内的偶数+5以内的奇数+0以内的偶数，
某个偶数m以内的偶数个数（包括0）可以表示为m/2+1=(m+2)/2
某个奇数m以内的奇数个数也可以表示为(m+2)/2
所以，求总的组合次数可以编程为：
number=0;
for (int m=0;m<=10;m+=5){
number+=(m+2)/2;
}
这样程序简单太多了。
以上文的原理就在于，将x+y*2+5*z=10转换成为10-5z=x+y*2，当z从0到2时，就转换成了求1和2的组合了，实际上就变成了10-5z中，可以有多少个偶数。故产生的结果就如上所示了。
理解跨系统之间金额的业务调用的资金平衡结算程序和过程
对于跨系统调用，它和同一个系统调用多个数据库不同，在两个系统调用之间，会出现各种各样的问题，导致会发生数据不一致的问题存在。本文从系统之间调用出发，并结合类金融系统的资金实现样例，来解析这种业务的实现过程。
我们现在有两个系统，A系统为金额系统，负责金额数据的存放和结算，当进行充值和消费时，将对金额的数据发生变化；B系统为业务系统，负责处理消费业务的实现，但当进行实现时，需要发送消费数据信息到A系统进行金额数据的存储，待存储完成之后方能进行下一步的业务流程。
可以由下面的一个流程来理解两个系统之间的交互：
- B系统发起消费业务，负责业务实现前的验证
- 验证成功，B系统向A系统申请付款信息
- A系统验证确定可以付款，产生付款信息，并进行金额结算
- A系统返回应答信息，B系统继续进行业务操作，完成消费业务实现
在以上的四个操作中，任何一步都可能发生错误，而且在系统与系统之间的交互过程中，还存在着网络方面的问题。当网络中断时，整个交互过程也不能完成。
首先可以肯定的是，这并不是一个事务内的事情，A系统和B系统是两个独立的系统，在网络上独立，且系统与系统间数据库是不会互相开放的，所以想在一个事务内考虑问题，是不能成功的。只从从系统外，即如何保证两个系统之间的数据平衡。
对于这种情况，只能通过流水号对账，双金额的收支平衡来解决此问题。即在A系统中设定一个预付金额和确认金额，B系统设定业务流水号，AB系统定时通过流水号进行帐务结算。对错误的业务信息，进行冲帐，正确的业务信息进行确认。
简单介绍下实现，在B系统中有一个业务流水号，记录着每一笔交易信息；A系统中有两个金额，一个是预付金额，一个是确认金额，预付金额用于在B系统进行业务处理前，记录业务交易的金额数据，确认金额用于在B系统业务处理后，记录业务交易的确认数据。一般情况下，预付金额与确认金额一致。此外，A系统同时记录B系统的业务流水号，以便于定时进行业务对帐。
业务对帐，表现确认两边的数据是否一致，同时对未写入的确认金额进行确认或取消。当业务一致时，确认金额表现为交易金额数据，当业务不一致时，预付金额表现为需要冲正的金额数据，将在进行对帐时进行处理。
详细数据结构如下：
A系统：
bId （B系统业务流水号) preMoney(预处理金额） confirmMoney(确认金额)
B系统：
bId(B系统业务流水号) aId(金额处理流水号，可选)
centos 6.0已经正式发布，正在同步中，马上就可以下载了
经过漫长的等待，centos 6.0终于发布了，现在正在往外部镜像同步了。同步时间修改到了7月8号，现在是中国时间7月9号，数据正在同步中。相应外部镜像的centos 6.0目录已经开始创建了，直接上图：
上图为，镜像服务器163的镜像图，现在正在同步中，所以相应的iso等文件还没准备好，相信再等一会儿就可以下载了。国外的镜像服务器应该更快一些吧。终于可以下载到centos 6.0了
centos6.0马上就要发布了,官方最新7月2日公告
最近一直在关注centos6.0的进展，从6月6号一直到今天的7月2日。最新进展,centos已经开始在创建最终的releaseDVD了，并且已经在往官方服务器上进行同步，在7月4号就能往外部服务器上进行同步了。
官方开发小组的jeff，在7月2号更新了一篇信息，表示最终的release已经确定完毕，不再进行延期了。原文地址为http://qaweb.dev.centos.org/qa/node/101。原文信息如下:
Quick summary: Final CentOS 6.0 compose and build of ISO images is happening now. This will happen overnight, and once it's done, it will be pushed to the staging machine which will then start syncing out to the internal centos.org mirrors. Rough estimate on the push from the staging machine to the mirrors is ~2 days. Longer version: We got through a couple more iterations today to work out some problems. Once we got through that, the packages were all signed with the new official CentOS 6 key, and pushed out to QA once more. At that point we discovered that while the RPM signatures verified OK on CentOS 6, they did not verify OK on CentOS 5. We spent some time troubleshooting this but got it worked out, resulting in a new new key. For this reason, the entire tree needs to be resigned and new ISOs created and pushed. We're not yet through with testing on the updates/ tree, but we can start getting the main os/ and isos/ pushed out to the internal mirrors in the meantime. updates/ is much smaller, so we'll be able to push it quickly once testing is complete.
简单的翻译一下:)
最新进展：现在已经在编译和生成最终的centos 6.0的iso镜像。从今天开始，只要编译完毕，就直接进行发布并且同步到centos的内部源，整个同步时间（包括内部和外部源）大概时间预计在2天以内。
具体点说，我们为解决一些问题进行了许多次开发迭代，但只要一完成，就立即使用官方key进行签名并同时送往qa组进行测试。但是我们突然发现，这些包在centos6上验证通过，但在centos5上却失败了。最后通过产生一个新的签名方法来解决这个问题，结果就是整个开发代码都需要重新进行签名，只有等这个完了之后才能进行iso的发布。
直到现在，我们还没有针对系统的update部分进行测试，不过可以先将主要的部分先同步出来，因为相对来说,update部分比较小，一旦完成测试，将立即发布。
如果不出意外，这两天就能下载到最终的centos6.0了，漫长的等待终于要结束了。可以换掉到我的fedora15了，开发用的机器，还是要稳定一点好。经常死机可不是一件好事。
对java和c++之间有感，业务和技术，上层逻辑和底层交互
最近做了几个项目，都用到了与java之外的东西，主要是与硬件交互。java做的主要是与业务相关的逻辑，但说到与硬件交互方面，java直接就什么忙也帮不上了。有个项目虽然未与硬件直接交互，但也间接操作硬件，对于我来说，都是java上的短板。
现在来排列一下几个项目用到的非java技术吧。一是与led交互，需要与led进行通信以发布信息，这需要与相应dll交互；二是与m1卡类操作，也需要与dll交互；三则是一个与网络和串口相关的，需要读写串口数据。这三个项目，最终的解决方案都不是java版，作为使用的硬件厂商，由于种种原因，厂商也不能提供一些的帮助。最后只能靠公司自己来解决这个问题。
最后的解决方法，第一个由兄弟公司请一个vb外援解决了；第二个准备实现一个activex版的界面程序；第三个请了一个作vc的外援解决此问题。都不是java实现，而且……最终的成品，也得不到最终的保证，仅仅是能用罢了。
单就这几个项目而言，最主要的问题，不是说自己的开发人员不懂c++那么高的技术程序，而是根本不需要单独就一个硬件交互问题就推到c++版来处理。最终的问题仅仅是不知道如何使用c++来与这些硬件交互，或者说仅仅是不会调用c++的相关函数，不会使用c++而已。交互逻辑，业务逻辑，完全没有问题，仅仅是不能实现罢了。