Storms make trees take deeper roots.
似乎很有一段时间没有发布godaddy的优惠码，因为一直工作比较忙，对博客疏于打理，有点愧对一直以来对飞尘默默支持的广大朋友们了，嘿嘿，多多包涵。
本次献上的godaddy优惠码是应用于域名的，对于com/net/org都可以使用，在原价的基础上优惠30%，其实购买godaddy的产品和服务基本上是没有不使用优惠码的，这种一般的优惠码是所谓的层出不穷，当然有些时候也会推出一些稀有的优惠码，比如1.99美元的域名或者0.99美元的域名啦，不过使用是有要求的——使用信用卡首次购买才可以享受优惠。话说的多了，看看本期的优惠吧：
优惠码gda731p
有效期2010-08-08
这个日期有点意思，两年前的这天正是奥运会在中国开幕啊，呵呵。
需要的朋友可以直接使用优惠码访问godaddy
最近高温来袭，真是让人有点耐不住了，这个时候也体现出了公交车空调的作用，平时公交车里的空调大多是不开的，虽然为此付了费，还好在这高温的夏季还是能享受到一袭清凉。
这里对天气预报就有点牢骚了，明明说的是晴到多云，晚上回家的时候却瓢泼大雨，所幸的是赶在大雨来临之前挤上了已经人山人海的公交车，摇摇晃晃一路走来，担心着一会到站了怎么办（没有雨具啊）。也许是天公作美，下车的时候雨几乎就不怎么下了，这种雨天连个的士都不好打，在站台守望了许久，的士没有等到，不过终于把公交车等来了，正好可以省下些路费，费了九牛二虎之力终于回到了家。
前些天看新闻调查上下班花费时间，像我这样的对此真是贡献很大，上班要1个多小时，下班好的时候要1个多小时，差一点的时候就要1个半到2个小时，平均一天下来花在路上的时间就要3个小时，真是对时间极大的浪费，唉，真是无奈啊！
项目开发过程中，突然遇到这样一个错误，相关的提示消息如下：
no single default persistence unit defined in classpath meta-inf persistence.xml
之前项目一直是正常的，不知道什么原因在跑服务器的时候就抛出这个错误。
经过一番摸索，找到了解决方法：
首先在persistence.xml文件中查看persistence-unit的name属性值，比如abc，记下这个值
<persistence -unit name="abc"> </persistence> |
然后在src/main/resource下修改配置文件applicationContext-mysql.xml
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"> <property name="dataSource" ref="dataSource" /> <!-- 增加下面一行 value设置为与persistence.xml文件中的相同 --> <property name="persistenceUnitName" value="abc" /> </bean> |
前面写了一篇关于gwt中使用openflashchart的日志，不过没有详细描述如何使用ofcgwt，今天来补充一下。
本文使用gwt开发的项目使用maven进行管理，因此引入ofcgwt需在项目pom.xml文件中的
<dependency> <groupid>com.rednels</groupid> <artifactid>ofcgwt</artifactid> <version>2.0.1-beta</version> <scope>provided</scope> </dependency> |
在需要使用到open flash chart的模块配置文件中添加
<inherits name="com.rednels.ofcgwt.OFCGWT" /> |
这里有一点需要注意：
使用ofcgwt需要引用User模块，而且引用的顺序很关键，正确的应该保持这样的顺序
<inherits name="com.google.gwt.user.User" /> <inherits name="com.rednels.ofcgwt.OFCGWT" /> |
如果引用的顺序不正确或者缺少引用，在gwt编译的时候会报错
Loading inherited module 'com.rednels.ofcgwt.OFCGWT'
[ERROR] Property 'user.agent' not found
[ERROR] Failure while parsing XML
com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries)
由于偶然的原因去查阅了下64位，似乎耳熟能详的64位原来不止那么简单。
更多详细的内容就不多写了，感兴趣的请自学哦，这里只说一点，就是对于内存寻址。在原有的32位结构下，可寻址的内存上限为4GB，这在当时也是认为足够使用的。然而硬件的发展飞速，今天大于4GB的个人电脑也比比皆是，于是32位的结构不再能够满足需要。
那64位就可以了吗？我们来计算一下：
32位=2^32，就是4GB
64位=2^64，等于多少，还真有点算不清了，呵呵，还好已经有人帮我们计算好了，那就是16EB。EB是多少呢？通过下面这张表就能清晰的表达了。
|
Multiples of bytes
|
|||||
|---|---|---|---|---|---|
| SI decimal prefixes | IEC binary prefixes | ||||
| Name (Symbol) |
Standard SI |
Binary usage |
Ratio SI/Binary |
Name (Symbol) |
Value |
| kilobyte (kB) | 103 | 210 | 0.9766 | kibibyte (KiB) | 210 |
| megabyte (MB) | 106 | 220 | 0.9537 | mebibyte (MiB) | 220 |
| gigabyte (GB) | 109 | 230 | 0.9313 | gibibyte (GiB) | 230 |
| terabyte (TB) | 1012 | 240 | 0.9095 | tebibyte (TiB) | 240 |
| petabyte (PB) | 1015 | 250 | 0.8882 | pebibyte (PiB) | 250 |
| exabyte (EB) | 1018 | 260 | 0.8674 | exbibyte (EiB) | 260 |
| zettabyte (ZB) | 1021 | 270 | 0.8470 | zebibyte (ZiB) | 270 |
| yottabyte (YB) | 1024 | 280 | 0.8272 | yobibyte (YiB) | 280 |
| See also: Multiples of bits · Orders of magnitude of data | |||||
上面的表格数据来自http://en.wikipedia.org/wiki/Exabyte
今天我们同样的可以认为64位足够满足我们的需要了，但是未来究竟会怎样呢？我们的一次又一次的短见会不会再次出现（ipv4同样是这样的例子）？就目前的超级计算机，内核成千上万，内存是多少不是很清楚，但是发展是无止境的，某一天会不会达到这个16EB的上限，未来的云计算机又是怎样呢？
对未来的疑问只有等待未来回答，让我们拭目以待。
上面是飞尘一点点个人体会，好像扯的有点远了。还说64吧，虽然64位能够支持到16EB的内存，但是实际中个人PC会有相应的限制。举例来说，Apple的Mac Pro最多可安装16GB的内存，Linux（内核版本2.6.16）可编译成最高支持64GB的内存，Windows Vista Ultimate支持超过128G内存，Windows 7 Home Premium、Enterprise、Ultimate都支持192GB的内存。