近来在博客上关于Scala与Erlang之间的争论越来越热。未来注定是多核的世界，问题在于如何去解决多核的危机。Scala和Erlang是两门渴望成为其解决方案的语言，但它们也有些许的不同。那么它们所采取的方式各有什么利弊呢？
引入问题
摩尔定律已经改变了。我们不再获得和以前一样的时钟频率增长，取而代之，我们得到了更多的（CPU）核心。今天，也许你的笔记本都已经是双核的了。
为了利用多核的特性，应用程序需要支持并发。如果你的客户买了一台八核的机器，要向他们解释清楚正常情况下应用程序只会用到12%的CPU能力将是一件费时费力的事，即便该机器是为该应用量身定制的。
在未来，情况可能变得更糟。你的顺序执行代码不仅不会跑得更快，甚至有可能实际上跑得更慢。其原因在于，你获得越多的核心，由于功耗和散热的影响，每个核心就会更慢。几年之后，英特尔就会给我们带来32核的CPU，按这种趋势，在我们不知不觉之中数千核的CPU就会出现。但每个核心都会比现在的核心慢很多。
并发代码
一个显见的解决途径就是编写（或重写）软件以支持并发。最常见的方式莫过于使用线程，但大多数开发者都认为基于线程的应用编写起来特别的困难。死锁，饿死以及竞争条件对大多数并发开发者来说都是太熟悉的概念了。Erlang和Scala都大大减轻了这种痛苦。
语言概览
Scala常被看作是下一个主要的JVM语言。它结合了面向对象编程的范式和函数式编程的范式，与Java相比有着更简洁的语法，它是静态类型的，有着跟Java一样或者有时候更快的运行速度。有太多的理由值得去认真探索一下Scala。
Erlang是一门为健壮性而生的语言，由于它的设计，它自然又是一门有着极好伸缩性的语言。它比Java历史更早，但却常被看作引领未来并发的语言。它是一门动态类型的函数式语言，有着一些非凡的系统正常运行时间的成功例子。
争论核心
那么Scala与Erlang争论的到底是什么呢？说到底，就是性能表现与伸缩能力，但这争论也包括了其它像风格，语言特性以及库支持等等。这场争论开始于Ted Neward有一次无心的给出了他对几种语言的看法，并称“[Erlang]在其自己解释器上运行事实上[是]很差的”。
Steve Vinoski与Ted于是展开了几轮争论，但这一讨论很快转移到了更多的博客上，争论的焦点也转变成了Scala与Erlang之间那些有趣的差异和共同点。我们将总结每个有意思的论点并给出每种语言的利弊，并表达对一些问题的各种不同看法。
可靠性
Steve Vinoski就Ted所发表的帖子进行了回应，给出了他对于“Erlang在其自己解释器上运行”的感受：
事实上，Erlang在其自己解释器上运行得，很好很强大；如若不然，不可能有如此好的可靠性，它将只是又一个面向并发的有趣但却无用的语言实验而已。
Steve谈到这个问题，就算一个语言本身可靠，它所依赖的基础也必须可靠才行。因为Erlang从骨子里就是为可靠性而设计的，从而支持并发，所以它不会受到一些并发性常见问题的影响，这主要是底层库包在并发环境下运行很好。
另一方面，Scala是站在JVM之上的，所以一个重要卖点在于可潜在地使用所有现成的Java代码。然而，大部分的Java代码并非专为并发而设计的，使用Scala代码时要将此考虑进去。
轻量级进程
要运行大规模并发应用，你需要大量的并行执行。这可以通过几种方式达到。使用线程是一种常见的方式，使用进程又是另一种。其区别之处在于，线程与其它线程之间共享内存，而进程是相互独立的。这意味着线程需要像互斥信号这样的锁机制，防止两个线程在同一时间对同一内存进行操作，但进程不会受此问题影响，相反是使用一些消息传递机制来跟其它的进程间通信。但进程在性能和内存方面的代价是昂贵的，这正是人们就算知道基于线程的并发是一种极复杂的编程模型也宁愿选择它的原因。
Steve Vinoski这样写到：
提供互不共享的轻量级进程架构将使得大规模并发能力变得十分容易，但这并不意味着一旦你设计好了，剩下的就只是编程的工作那么简单。
Erlang采取了这样的并发方式。一个Erlang进程是非常轻量化的，Erlang应用常常拥有成千上万的线程甚至更多。
Scala通过基于事件的Actor从另一方面达到了同样的效果。Yariv Sadan解释说：
Scala有两种类型的Actor：基于线程或是基于事件。基于线程的Actor在重量级的OS线程内部执行。它们从不相互阻塞，但每个VM上可伸缩的Actor不会多于几千个。基于事件的Actor是简单的对象。它们是十分轻量化的，并且，像Erlang进程一样，因此它们可以在一台现代的机器上数以百万计的产生。
Yariv解释到，尽管如此，这里面也还是有一些区别的：
与Erlang进程的区别之处在于，每个OS线程内部，基于事件的Actor是顺序执行的并且使用没有强占式调度算法。这使得一个基于事件的Actor可能在很长一段时间内阻塞其OS线程（甚至是无限的）。
不可变性
Erlang是一门函数式语言。这意味着其数据是不可变的，像Java的String一样，并且没有副作用带来的风险。对数据的任意操作会产生一个该数据新的修改后的版本，但原数据仍然不变。在谈到健壮性的时候，不可变性是其需要高度注意的一个因素，因为没有代码可以无意间修改其它代码依赖的数据，但从并发的观点来看，不可变性也是一个十分重要的特性。如果数据不可变，其被两个并行执行路径更改的风险就不存在，因为没有办法改变它且不需要保持同步，所以数据可以被拷贝到其它机器上。
因为Scala构建在JVM之上，结合了面向对象和函数式方法的特点，它不具备像纯函数式语言的不可变性的保证。然而，在Yariv日志的评论部分，Yariv和David Pollack就这两门语言之间的差别展开了一场有趣的讨论。David，Scala Web框架Lift的作者，给出了他对于不可变性的看法：
不可变性 —— Erlang强制了这一点，而且你几乎无法绕过它。但是，与强制一个单一类型相比，你可以用Scala神奇强大的类型系统的剩余部分去交换。我在进行Scala Actor编码时使用不可变数据，而让Scala的类型系统负责其它类型。
Yariv问到：
只发送不可变类型难道不是一个重大限制吗？这意味着，例如，你不能从Hibernate装载一个简单的bean并将它发送给其它Actor。
David回答到：
我曾基于Scala的Actor构建个多个生产系统。实际上对于不可变性问题并没有多少工作需要处理。你只需要将你的相关类（消息）定义为不可变的，其它的就不用管了。
类型系统
Erlang是动态类型的，而Scala是静态类型的并且相比Java有着更强的类型系统。然而，与Java相比最大的一个区别是Scala可以类型推断。这意味着你可以省掉大部分的类型注解，使得代码更加干净而编译器照样会做所有的检查。
关于动态与静态系统之间孰是孰非的争论看来永远也不会停止，但Erlang和Scala之间却有着显而易见的区别。
尾递归或是循环
Yariv又提到：
函数式编程与递归从来都是形影不离的。实际上离开了尾递归你很难写出有用的Erlang程序，那是因为Erlang没有循环——它对一切都使用递归（这在我看来是一件好事 :））。
这显然使得Erlang与Scala产生了很大差别。Scala提供了很多更传统的迭代，但David Pollack并没看出在这种环境下尾递归有什么优势：
尾递归——对基于事件的Actor来说根本不是什么问题。
如此说来，这仅仅有关你的偏爱和风格罢了。
热交换代码
由于Erlang是为可靠性而生的，热交换代码（运行时替换代码）是其内建的天性。
JVM对热交换代码有所支持。类可以被改变，但由于其静态的类型系统，其方法签名是不可改变的——只有其内容可以改变。虽然有第三方工具致力于此，也有框架（提倡以一种使运行时更方便交换类的编程风格书写代码），但就算运行在JVM上，如何进行交换仍是取决于你的Scala Actor是如何构建的。Jonas Bonér就此给出了一个详尽的例子。
总结
Scala和Erlang都是致力于解决多核危机的语言。它们来自不同的背景和年代，因此对待某些问题的方式也不尽相同，然而在许多方面它们的共识大于分歧，至少在并发性上如此。
Erlang已经有着数十年的历史，并且已经在许多关键的真实系统中证明了自己。其不足之处在于它有一点像一个孤岛，最近的多语言编程的趋势似乎对Erlang社区影响不大。
另一方面，Scala是同一类型应用的新生儿。一些真实应用即将诞生，并且一些公司将未来押在了上面。Scala相对Erlang的最大优势在于，它运行在JVM之上并且可以利用所有现成Java代码、框架和许多工具。话虽如此，这种强大的能力也要求了更大的责任，因为大部分Java代码不可能自动适应Scala的Actor模型。
对于主流语言无法帮开发者解决的压力越来越大的问题，两种语言都对提供了相似的解决途径。希望你在读完这篇争论总结之后，能更清楚哪种语言更适合你的特殊要求，并对其深入了解。
未来是多核的。Scala和Erlang将会越来越流行。
查看英文原文：The multicore crises: Scala vs. Erlang
原文：http://tech.sina.com.cn/s/2008-07-09/0952725490.shtml
2009年5月17日星期日
2009年5月7日星期四
【转】MIDlet的生命周期的深入理解及游戏死机问题
今天在查加密算法是无疑中看到的。虽然开发j2me的时候，我都这么做的。只是没考虑过不这么做的问题。这样做只是习惯，觉得这样写比较舒服，呵呵。今天看到这篇文章发现原来还能防止这些，转来学习下。
首先在你运行一个程序的时候，JAM会调用该midlet的构造函数来生成midlet的对象，然后被jam置于Paused状态。一旦jam认为这个midlet对象可以执行时，jam就会调用startApp()方法，并将此midlet置于Active状态。startApp()方法由于在系统来电、或者退回到系统菜单返回时会被再次调用，所以这里只可以放初始化一次的代码。或者你把初始化一次的代码放到midlet的构造函数中。例如：
public class Midlet extends MIDlet{
Display display = null;
MyCanvas can;
public Midelt(){
display = Display.getDisplay(this);
can = new MyCanvas();
}
public void startApp(){
display.setCurrent(can);//如果把can = new MyCanvas()放到这里，再来电返回时就会出问题。
}
}
或者
public class Midlet extends MIDlet{
Display display = null;
MyCanvas can;
public Midelt(){
}
public void startApp(){
if(display ==null){
display = Display.getDisplay(this);
can = new MyCanvas();
}//此处只会被运行1次，这样就不会出错
display.setCurrent(can);//这句按理放到这里最合适，你想显示那个canvas就放哪个！
}
}
在startApp()中，你调用display.setCurrent(can)的时候，首先运行的是showNotify()，接着运行paint()函数一次，如果有线程的话，此时run()方法开始运行。一般在run()方法里一般这么写。此时的run()是可以处理异步事件的，也就是你来电话的时候，这里run()还是运行的。不过他不会paint()什么东西，即使它里面有repaint()，这点放心。
public void run(){
while(flag){//flag是boolean型变量
try{
Thread.sleep(50);//时间自己设啦。
}catch(Exception e){}
repaint();
}
}
哇～～来电话了，或者你退到系统菜单。如nokia s60的手机。
hideNotify()首先会被调用，接着pauseApp()再被调用。
这么快，打完了，返回时：先调用showNotify()，接着调用paint()函数一次，最后才是调用startApp()函数。
关于run()和paint()也可以使用display.callSerially(this)语句。这个以后有时间了再说。
明白了生命周期，再来看死机问题。我说的死机问题，多是来电话返回时死机。其实只要找到了问题，一切就变的很简单。
为什么死机，归根结底还是程序问题。好像是废话。哈～～
Graphics mg;//定义的全局参数
paint(Graphics g){
mg = g;//有的程序这样写，if(mg ==null){mg =g:}这样对于n7610系列就会出错。
mg.drawString();
switch(case){
case GAME_MUNE:
drawA();
break;
case PLAY:
drawB();
break;
default:
break;
}
}
/*下面的画图函数一定要放到paint()函数里调用，不要在别的地方调用，如run()里面，上面说过，程序暂停之后返回，会先paint（）一次，如果在别的地方调用就会出现问题。*/
public void drawA(){
mg.drawString();
}
public void drawB(){
mg.drawString();
}
按照上面的写法一般不会出现死机问题。当然，你也可以不定义全局的mg，可以把g单独传到各个画图子函数中。如，
paint(Graphics g){
g.drawString();
switch(case){
case GAME_MUNE:
drawA(g);
break;
case PLAY:
drawB(g);
break;
default:
break;
}
}
public void drawA(Graphics mg){
mg.drawString();
}
public void drawB(Graphics mg){
mg.drawString();
}
原帖：http://azi.javaeye.com/blog/194478
首先在你运行一个程序的时候，JAM会调用该midlet的构造函数来生成midlet的对象，然后被jam置于Paused状态。一旦jam认为这个midlet对象可以执行时，jam就会调用startApp()方法，并将此midlet置于Active状态。startApp()方法由于在系统来电、或者退回到系统菜单返回时会被再次调用，所以这里只可以放初始化一次的代码。或者你把初始化一次的代码放到midlet的构造函数中。例如：
public class Midlet extends MIDlet{
Display display = null;
MyCanvas can;
public Midelt(){
display = Display.getDisplay(this);
can = new MyCanvas();
}
public void startApp(){
display.setCurrent(can);//如果把can = new MyCanvas()放到这里，再来电返回时就会出问题。
}
}
或者
public class Midlet extends MIDlet{
Display display = null;
MyCanvas can;
public Midelt(){
}
public void startApp(){
if(display ==null){
display = Display.getDisplay(this);
can = new MyCanvas();
}//此处只会被运行1次，这样就不会出错
display.setCurrent(can);//这句按理放到这里最合适，你想显示那个canvas就放哪个！
}
}
在startApp()中，你调用display.setCurrent(can)的时候，首先运行的是showNotify()，接着运行paint()函数一次，如果有线程的话，此时run()方法开始运行。一般在run()方法里一般这么写。此时的run()是可以处理异步事件的，也就是你来电话的时候，这里run()还是运行的。不过他不会paint()什么东西，即使它里面有repaint()，这点放心。
public void run(){
while(flag){//flag是boolean型变量
try{
Thread.sleep(50);//时间自己设啦。
}catch(Exception e){}
repaint();
}
}
哇～～来电话了，或者你退到系统菜单。如nokia s60的手机。
hideNotify()首先会被调用，接着pauseApp()再被调用。
这么快，打完了，返回时：先调用showNotify()，接着调用paint()函数一次，最后才是调用startApp()函数。
关于run()和paint()也可以使用display.callSerially(this)语句。这个以后有时间了再说。
明白了生命周期，再来看死机问题。我说的死机问题，多是来电话返回时死机。其实只要找到了问题，一切就变的很简单。
为什么死机，归根结底还是程序问题。好像是废话。哈～～
Graphics mg;//定义的全局参数
paint(Graphics g){
mg = g;//有的程序这样写，if(mg ==null){mg =g:}这样对于n7610系列就会出错。
mg.drawString();
switch(case){
case GAME_MUNE:
drawA();
break;
case PLAY:
drawB();
break;
default:
break;
}
}
/*下面的画图函数一定要放到paint()函数里调用，不要在别的地方调用，如run()里面，上面说过，程序暂停之后返回，会先paint（）一次，如果在别的地方调用就会出现问题。*/
public void drawA(){
mg.drawString();
}
public void drawB(){
mg.drawString();
}
按照上面的写法一般不会出现死机问题。当然，你也可以不定义全局的mg，可以把g单独传到各个画图子函数中。如，
paint(Graphics g){
g.drawString();
switch(case){
case GAME_MUNE:
drawA(g);
break;
case PLAY:
drawB(g);
break;
default:
break;
}
}
public void drawA(Graphics mg){
mg.drawString();
}
public void drawB(Graphics mg){
mg.drawString();
}
原帖：http://azi.javaeye.com/blog/194478
2009年4月25日星期六
【转】女大学生日记一则(令人震撼)
今天无意在某个学长的博客中看到这篇文章，是蛮早前的了。“令人震撼”这四个字是学长的标题。看完后，把我震撼了么，只是有点感觉。换作以前的我一定感慨良多，现在只是觉得很现实。觉得替这位老人难过，仅此而已。
原文如下：
我只是一个学生，无权无势，但却做梦也没有想到，居然有人向我下跪。
那是数天前的一个中午，我刚从双安商场的美食城出来，走上人行天桥，凛冽的寒风在我暴露的皮肤上肆虐不已。突然看见前面有一满头银发的老妪不停地向人打躬作揖，而路人纷纷掩鼻而走。估计又是一个乞丐，我正在这么想着。这时，老者却向我走来。我摸了摸口袋中的硬币，心想也许又是一个骗子。我几乎都能猜到她会说些什么，无非是来京访亲，找不到人了，好些天没有吃饭了等引人入套的话。我做好了用几个钢崩将她打发的准备，不料老人却用地道的河南话对我说，「同志，海淀区司法援助中心怎么走？」喔，原来只是问路，我笑了笑，感觉自己有点神经过敏。「对不起，我也不知道」，我感到有些不好意思，但自己确实不知那个援助中心在哪。老人朝我点了点头，又向旁边一个路人询问，但对方却并未理睬这个貌似乞丐的老人。我禁不住又打量了一下老人，她估摸60多岁，带着数个破破烂烂的编织袋和一个古老的黑色旅行袋，袋子旁还用玻璃绳子栓着一个破水杯。又是一个上访者，一个不知被多少个部门像中国足球一样被人踢来踢去而始终踢不进门的上访者，我心里一阵难受，对老人说，「您别急，我帮您打电话问一问」。我用手机给查号台打了电话，在现代科技的帮助下，很快问到了援助中心的地址－－某某路某号。这时老人突然扑通给我跪下，泣不成声地对我说：「你是个好人」。天啊，仅仅是问个路，一个六旬开外的老人居然向我下跪。
我的眼睛有点湿润，慌忙把老人扶起。她只是一个劲地对我说你是个好人，你是个好人。我给她指了指援助中心的方向，告诉她该怎么坐车。老人从贴身的内衣中小心翼翼地掏出个皱巴巴的信封，颤巍巍的记下了地址。我本想迅速撤离这个让人压抑的天桥，可又觉得即使指明方向、地址，对于这个对北京人生地不熟的老人来说，要想找到那个连我都不易找到的援助中心无疑是大海捞针。于是我决定带她去，不料就为这她再次向我下跪，我措手不及，只能一手提起了她那像垃圾一样的编织袋，一手把她扶起。
在去往目的地的出租车上，老人告诉我，她是河南南阳人，今天早上刚到北京，为了找援助中心，已经徒步走了4个多小时。她问了问我的身份，当我告诉她我还是学生时，她又一次哭了，哽咽的说到：「如果不是家里穷的话，我那儿子现在也是大学生，也就不会遭这个罪了。」原来他的儿子是油漆工，两年前来京打工。一天深夜，她儿子骑着自行车，带着铁桶和毛笔正往家赶，突然被几个巡逻的警察二话不说地抓了起来。没有申辩、没有审判、似乎没有任何程序，孩子就被关进了监房。过了20多天，事情总算是弄清了，孩子的清白也得到了证明，但他的手指却由于不知名的原因掉了几个，而且精神彻底崩溃，成了疯子。想像一下吧，一个来北京寻求希望、身心健康的年青人，在毫无过错的情况下，莫名其妙地深陷囹圄，没有任何反抗、任何辩解的机会，最终成了一个废人。
「法律面前人人平等」在这个事实面前是何等地苍白，一个打工者，仅仅因为穿着寒碜就会被怀疑为嫌疑份子，而那些开着大奔、西装革履却暗地里坐着违法勾当的「款爷」们就能理所当然地避免这样的「天灾人祸」，甚至还会备受尊敬。难道我们的法律中有「以衣着和相貌」这样的定罪原则吗？「人生而自由，却无往不在枷锁之中。」我感到了人类的渺小，感到了法律的悲哀，「相信法律吧」，这就是我，一个研读法律近10年的人对她唯一能说的话，一句苍白得近乎虚伪的话。
到了援助中心，我执意要陪她上去，但老人对我鞠了鞠躬，说已经很感谢我了，让我不要上去，她说我还年轻，不要介入这种可能影响将来前途的事情。
我走了，想着老人的话，突然感觉自己是多么的卑微，多么的懦弱，感到自己曾经奋笔疾书的有关法律精神的探讨是多么的可笑，多么的幼稚。
深夜，我又想起了这位老人，不知在这寒冷的冬夜里，她栖息何处？
原文如下：
我只是一个学生，无权无势，但却做梦也没有想到，居然有人向我下跪。
那是数天前的一个中午，我刚从双安商场的美食城出来，走上人行天桥，凛冽的寒风在我暴露的皮肤上肆虐不已。突然看见前面有一满头银发的老妪不停地向人打躬作揖，而路人纷纷掩鼻而走。估计又是一个乞丐，我正在这么想着。这时，老者却向我走来。我摸了摸口袋中的硬币，心想也许又是一个骗子。我几乎都能猜到她会说些什么，无非是来京访亲，找不到人了，好些天没有吃饭了等引人入套的话。我做好了用几个钢崩将她打发的准备，不料老人却用地道的河南话对我说，「同志，海淀区司法援助中心怎么走？」喔，原来只是问路，我笑了笑，感觉自己有点神经过敏。「对不起，我也不知道」，我感到有些不好意思，但自己确实不知那个援助中心在哪。老人朝我点了点头，又向旁边一个路人询问，但对方却并未理睬这个貌似乞丐的老人。我禁不住又打量了一下老人，她估摸60多岁，带着数个破破烂烂的编织袋和一个古老的黑色旅行袋，袋子旁还用玻璃绳子栓着一个破水杯。又是一个上访者，一个不知被多少个部门像中国足球一样被人踢来踢去而始终踢不进门的上访者，我心里一阵难受，对老人说，「您别急，我帮您打电话问一问」。我用手机给查号台打了电话，在现代科技的帮助下，很快问到了援助中心的地址－－某某路某号。这时老人突然扑通给我跪下，泣不成声地对我说：「你是个好人」。天啊，仅仅是问个路，一个六旬开外的老人居然向我下跪。
我的眼睛有点湿润，慌忙把老人扶起。她只是一个劲地对我说你是个好人，你是个好人。我给她指了指援助中心的方向，告诉她该怎么坐车。老人从贴身的内衣中小心翼翼地掏出个皱巴巴的信封，颤巍巍的记下了地址。我本想迅速撤离这个让人压抑的天桥，可又觉得即使指明方向、地址，对于这个对北京人生地不熟的老人来说，要想找到那个连我都不易找到的援助中心无疑是大海捞针。于是我决定带她去，不料就为这她再次向我下跪，我措手不及，只能一手提起了她那像垃圾一样的编织袋，一手把她扶起。
在去往目的地的出租车上，老人告诉我，她是河南南阳人，今天早上刚到北京，为了找援助中心，已经徒步走了4个多小时。她问了问我的身份，当我告诉她我还是学生时，她又一次哭了，哽咽的说到：「如果不是家里穷的话，我那儿子现在也是大学生，也就不会遭这个罪了。」原来他的儿子是油漆工，两年前来京打工。一天深夜，她儿子骑着自行车，带着铁桶和毛笔正往家赶，突然被几个巡逻的警察二话不说地抓了起来。没有申辩、没有审判、似乎没有任何程序，孩子就被关进了监房。过了20多天，事情总算是弄清了，孩子的清白也得到了证明，但他的手指却由于不知名的原因掉了几个，而且精神彻底崩溃，成了疯子。想像一下吧，一个来北京寻求希望、身心健康的年青人，在毫无过错的情况下，莫名其妙地深陷囹圄，没有任何反抗、任何辩解的机会，最终成了一个废人。
「法律面前人人平等」在这个事实面前是何等地苍白，一个打工者，仅仅因为穿着寒碜就会被怀疑为嫌疑份子，而那些开着大奔、西装革履却暗地里坐着违法勾当的「款爷」们就能理所当然地避免这样的「天灾人祸」，甚至还会备受尊敬。难道我们的法律中有「以衣着和相貌」这样的定罪原则吗？「人生而自由，却无往不在枷锁之中。」我感到了人类的渺小，感到了法律的悲哀，「相信法律吧」，这就是我，一个研读法律近10年的人对她唯一能说的话，一句苍白得近乎虚伪的话。
到了援助中心，我执意要陪她上去，但老人对我鞠了鞠躬，说已经很感谢我了，让我不要上去，她说我还年轻，不要介入这种可能影响将来前途的事情。
我走了，想着老人的话，突然感觉自己是多么的卑微，多么的懦弱，感到自己曾经奋笔疾书的有关法律精神的探讨是多么的可笑，多么的幼稚。
深夜，我又想起了这位老人，不知在这寒冷的冬夜里，她栖息何处？
2009年4月21日星期二
oracle 收购 sun 是福是祸 是挑战
刚才才看到这条消息，确实晚了点，这么震撼的消息现在才知道惭愧。
当时传ibm收购sun，网上议论纷纷。当谈判破裂时，很多分析师说是收购失败是sun的损失，也有说是ibm的损失等等。我当时没有觉得什么损失不损失的。大家维持原状有什么损不损失的。现在oracle又是用现金收购了sun。一方面可见oracle这几年来收购的野心，另一方面可见到现在可谈损不损失的问题了。
无疑对于ibm来说是损失了。现在oracle借助sun的软硬件技术，将成为IBM在数据中心领域的一个强大竞争对手,新公司可以销售包括硬件、操作系统和架构软件在内的完整企业产品组合,而在以前只有IBM才能够提供如此完整的产品和服务。
很多人说java前途光明。我不觉得。现在oracle形成了高端java企业开发一条龙，可以说有垄断之势。对于以前同是以java作为开发语言的ibm，sap等大公司对java有所忌惮。如何处理好两者之间的关系，就看oracle的操作了。作为java的开发者现在感觉就像是我为鱼肉的感觉。
对于oracle来说，sun的硬件部分的合并，让他不再是一家软件公司了，而变成了系统厂商。这也就让从前合伙的戴尔和惠普，有所忌惮了。对于oracle来说当然是扩张的好事。但对于从事这方面的开发人员来说，可选性变小了。更本不是件好事。
我一直觉得当时ibm收购失败是件好事，没有什么损不损失的。sun处于中间位置，达到平衡。所有的厂商以java技术而不用过多担心。现在格局被打破了，我对java的将来感到担心。
我对mysql也情有独钟，小巧轻便。现在mysql真是尴尬，所有的猜测都取决于oracle的决策了。mysql实在不行就去试试PostgreSQL。但是java的前提，我很在意。java确实有很多缺点，但是真是一门好语言啊。真不想因此而减少了他的应用范围。
是福是祸 都是挑战。接下来举世瞩目oracle的决策吧。希望都是明智的。但愿。。。。
当时传ibm收购sun，网上议论纷纷。当谈判破裂时，很多分析师说是收购失败是sun的损失，也有说是ibm的损失等等。我当时没有觉得什么损失不损失的。大家维持原状有什么损不损失的。现在oracle又是用现金收购了sun。一方面可见oracle这几年来收购的野心，另一方面可见到现在可谈损不损失的问题了。
无疑对于ibm来说是损失了。现在oracle借助sun的软硬件技术，将成为IBM在数据中心领域的一个强大竞争对手,新公司可以销售包括硬件、操作系统和架构软件在内的完整企业产品组合,而在以前只有IBM才能够提供如此完整的产品和服务。
很多人说java前途光明。我不觉得。现在oracle形成了高端java企业开发一条龙，可以说有垄断之势。对于以前同是以java作为开发语言的ibm，sap等大公司对java有所忌惮。如何处理好两者之间的关系，就看oracle的操作了。作为java的开发者现在感觉就像是我为鱼肉的感觉。
对于oracle来说，sun的硬件部分的合并，让他不再是一家软件公司了，而变成了系统厂商。这也就让从前合伙的戴尔和惠普，有所忌惮了。对于oracle来说当然是扩张的好事。但对于从事这方面的开发人员来说，可选性变小了。更本不是件好事。
我一直觉得当时ibm收购失败是件好事，没有什么损不损失的。sun处于中间位置，达到平衡。所有的厂商以java技术而不用过多担心。现在格局被打破了，我对java的将来感到担心。
我对mysql也情有独钟，小巧轻便。现在mysql真是尴尬，所有的猜测都取决于oracle的决策了。mysql实在不行就去试试PostgreSQL。但是java的前提，我很在意。java确实有很多缺点，但是真是一门好语言啊。真不想因此而减少了他的应用范围。
是福是祸 都是挑战。接下来举世瞩目oracle的决策吧。希望都是明智的。但愿。。。。
2009年4月14日星期二
一切就是那么的命中注定
今天在线上碰到了男人，问他最近境况。后得知现在在一家国企混着，等世嘉的下次面试。
呵呵，将兴趣变成了自己的工作到还真是不错。后来聊着聊着，聊到了面试第一轮的一道题。
写个一个通用的y=Asin(ax+b)+c的解法..要时间复杂越短越好。
他问我的时候，我一下子懵了下。好久没有接触高等数学了（惭愧）。依稀记得以前有什么公式可以通解。但要我立马不翻书，可真是不行了。男人说：...你们都是往这里想的.桃子也是...
。。。。我哪里想错了么？男人说：我就说把y=sinx的值按照精度要求预先存在数组中。
哈哈哈哈哈，用空间换时间么。桃子说他肯定错，我不觉得。至少别人让他面试到现在是不假的事实。我也觉得不错的方法。第一，你的算法再怎么牛，能达到系统预设的sin求解不是件容易的事情。第二：现在的要求是自己写一个要求时间复杂越短越好，当然是用空间去换时间了。我和桃子都一上来就走入误区了。
我很好奇，他当时怎么会突发如此想法的。我想正常人大多会和我和桃子的想法一样，想一个算法来解。男人说反正我看到过别人这么说.就觉得不至于不可行。
是的，也许不是他当时的突发奇想。但是平时的积累就是财富。你平时无意中捡起来的某些东西，也许暂时没用，但是总有用处的一天。一切就是这么命中注定。
呵呵，将兴趣变成了自己的工作到还真是不错。后来聊着聊着，聊到了面试第一轮的一道题。
写个一个通用的y=Asin(ax+b)+c的解法..要时间复杂越短越好。
他问我的时候，我一下子懵了下。好久没有接触高等数学了（惭愧）。依稀记得以前有什么公式可以通解。但要我立马不翻书，可真是不行了。男人说：...你们都是往这里想的.桃子也是...
。。。。我哪里想错了么？男人说：我就说把y=sinx的值按照精度要求预先存在数组中。
哈哈哈哈哈，用空间换时间么。桃子说他肯定错，我不觉得。至少别人让他面试到现在是不假的事实。我也觉得不错的方法。第一，你的算法再怎么牛，能达到系统预设的sin求解不是件容易的事情。第二：现在的要求是自己写一个要求时间复杂越短越好，当然是用空间去换时间了。我和桃子都一上来就走入误区了。
我很好奇，他当时怎么会突发如此想法的。我想正常人大多会和我和桃子的想法一样，想一个算法来解。男人说反正我看到过别人这么说.就觉得不至于不可行。
是的，也许不是他当时的突发奇想。但是平时的积累就是财富。你平时无意中捡起来的某些东西，也许暂时没用，但是总有用处的一天。一切就是这么命中注定。
2009年4月2日星期四
不要一辈子靠技术生存
来源：世界经理人
我现在是自己做，但我此前有多年在从事软件开发工作，当回过头来想一想自己，觉得特别想对那些初学JAVA/DOT。NET技术的朋友说点心里话，希望你们能从我们的体会中，多少受点启发(也许我说的不好，你不赞同但看在我真心的份上别扔砖头啊).
一、 在中国你千万不要因为学习技术就可以换来稳定的生活和高的薪水待遇，你千万更不要认为哪些从事 市场开发，跑腿的人，没有前途。
不知道你是不是知道，咱们中国有相当大的一部分软件公司，他们的软件开发团队都小的可怜，甚至只有1-3个人，连一个项目小组都算不上，而这样的团队却要承担一个软件公司所有的软件开发任务，在软件上线和开发的关键阶段需要团队的成员没日没夜的加班，还需要为测试出的BUG和不能按时提交的软件模块功能而心怀忐忑，有的时候如果你不幸加入现场开发的团队你则需要背井离乡告别你的女友，进行封闭开发，你平时除了编码之外就是吃饭和睡觉（有钱的公司甚至请个保姆为你做饭，以让你节省出更多的时间来投入到工作中，让你一直在那种累了就休息，不累就立即工作的状态）
更可怕的是，会让你接触的人际关系非常单一，除了有限的技术人员之外你几乎见不到做其他行业工作和职位的人，你的朋友圈子小且单一，甚至破坏你原有的爱情（想象一下，你在外地做现场开发2个月以上，却从没跟女友见过一面的话，你的女友是不是会对你呲牙裂嘴）。
也许你拿到了所谓的白领的工资，但你却从此失去享受生活的自由，如果你想做技术人员尤其是开发人员，我想你很快就会理解，你多么想在一个地方长期待一段时间，认识一些朋友，多一些生活时间的愿望。
比之于我们的生活和人际关系及工作，那些从事售前和市场开发的朋友，却有比我们多的多的工作之外的时间，甚至他们工作的时间有的时候是和生活的时间是可以兼顾的，他们可以通过市场开发，认识各个行业的人士，可以认识各种各样的朋友，他们比我们坦率说更有发财和发展的机会，只要他们跟我们一样勤奋。（有一种勤奋的普通人，如果给他换个地方，他马上会成为一个勤奋且出众的人。）
二、在学习技术的时候千万不要认为如果做到技术最强，就可以成为100%受尊重的人。
有一次一个人在面试项目经理的时候说了这么一段话：我只用最听话的人，按照我的要求做只要是听话就要，如果不听话不管他技术再好也不要。随后这个人得到了试用机会，如果没意外的话，他一定会是下一个项目经理的继任者。
朋友们你知道吗？不管你技术有多强，你也不可能自由的腾出时间象别人那样研究一下LINUX源码，甚至写一个LINUX样的杰作来表现你的才能。你需要做的就是按照要求写代码，写代码的含义就是都规定好，你按照规定写，你很快就会发现你昨天写的代码，跟今天写的代码有很多类似，等你写过一段时间的代码，你将领略：复制，拷贝，粘贴那样的技术对你来说是何等重要。（如果你没有做过1年以上的真正意义上的开发不要反驳我）。
如果你幸运的能够听到市场人员的谈话，或是领导们的谈话，你会隐约觉得他们都在把技术人员当作编码的机器来看，你的价值并没有你想象的那么重要。而在你所在的团队内部，你可能正在为一个技术问题的讨论再跟同事搞内耗，因为他不服你，你也不服他，你们都认为自己的对，其实你们两个都对，而争论的目的就是为了在关键场合证明一下自己比对方技术好，比对方强。（在一个项目开发中，没有人愿意长期听别人的，总想换个位置领导别人。）
三、你更不要认为，如果我技术够好，我就自己创业，自己有创业的资本，因为自己是搞技术的。
如果你那样认为，真的是大错特错了，你可以做个调查在非技术人群中，没有几个人知道C#与JAVA的，更谈不上来欣赏你的技术是好还是不好。一句话，技术仅仅是一个工具，善于运用这个工具为别人干活的人，却往往不太擅长用这个工具来为自己创业，因为这是两个概念，训练的技能也是完全不同的。
创业最开始的时候，你的人际关系，你处理人际关系的能力，你对社会潜规则的认识，还有你明白不明白别人的心，你会不会说让人喜欢的话，还有你对自己所提供的服务的策划和推销等等，也许有一万，一百万个值得我们重视的问题，但你会发现技术却很少有可能包含在这一万或一百万之内，如果你创业到了一个快成功的阶段，你会这样告诉自己：我干吗要亲自做技术，我聘一个人不就行了，这时候你才真正会理解技术的作用，和你以前做技术人员的作用。
[小结]
基于上面的讨论，我奉劝那些学习技术的朋友，千万不要拿科举考试样的心态去学习技术,对技术的学习几近的痴迷，想掌握所有所有的技术，以让自己成为技术领域的权威和专家，以在必要的时候或是心里不畅快的时候到网上对着菜鸟说自己是前辈。
技术仅仅是一个工具，是你在人生一个阶段生存的工具，你可以一辈子喜欢他，但最好不要一辈子靠它生存。
掌握技术的唯一目的就是拿它找工作（如果你不想把技术当作你第二生命的话），就是干活。所以你在学习的时候千万不要去做那些所谓的技术习题或是研究那些帽泡算法，最大数算法了，什么叫干活？
就是做一个东西让别人用，别人用了，可以提高他们的工作效率，想象吧，你做1万道技术习题有什么用？只会让人觉得酸腐，还是在学习的时候，多培养些自己务实的态度吧，比如研究一下当地市场目前有哪些软件公司用人，自己离他们的要求到底有多远，自己具体应该怎么做才可以达到他们的要求。等你分析完这些，你就会发现，找工作成功，技术的贡献率其实并没有你原来想象的那么高。
不管你是学习技术为了找工作还是创业，你都要对技术本身有个清醒的认识，在中国不会出现BILL GATES，因为，中国目前还不是十分的尊重技术人才，还仅仅的停留在把软件技术人才当作人才机器来用的尴尬境地。（如果你不理解，一种可能是你目前仅仅从事过技术工作，你的朋友圈子里技术类的朋友占了大多数，一种可能是你还没有工作，但喜欢读比尔。盖茨的传记）。
我现在是自己做，但我此前有多年在从事软件开发工作，当回过头来想一想自己，觉得特别想对那些初学JAVA/DOT。NET技术的朋友说点心里话，希望你们能从我们的体会中，多少受点启发(也许我说的不好，你不赞同但看在我真心的份上别扔砖头啊).
一、 在中国你千万不要因为学习技术就可以换来稳定的生活和高的薪水待遇，你千万更不要认为哪些从事 市场开发，跑腿的人，没有前途。
不知道你是不是知道，咱们中国有相当大的一部分软件公司，他们的软件开发团队都小的可怜，甚至只有1-3个人，连一个项目小组都算不上，而这样的团队却要承担一个软件公司所有的软件开发任务，在软件上线和开发的关键阶段需要团队的成员没日没夜的加班，还需要为测试出的BUG和不能按时提交的软件模块功能而心怀忐忑，有的时候如果你不幸加入现场开发的团队你则需要背井离乡告别你的女友，进行封闭开发，你平时除了编码之外就是吃饭和睡觉（有钱的公司甚至请个保姆为你做饭，以让你节省出更多的时间来投入到工作中，让你一直在那种累了就休息，不累就立即工作的状态）
更可怕的是，会让你接触的人际关系非常单一，除了有限的技术人员之外你几乎见不到做其他行业工作和职位的人，你的朋友圈子小且单一，甚至破坏你原有的爱情（想象一下，你在外地做现场开发2个月以上，却从没跟女友见过一面的话，你的女友是不是会对你呲牙裂嘴）。
也许你拿到了所谓的白领的工资，但你却从此失去享受生活的自由，如果你想做技术人员尤其是开发人员，我想你很快就会理解，你多么想在一个地方长期待一段时间，认识一些朋友，多一些生活时间的愿望。
比之于我们的生活和人际关系及工作，那些从事售前和市场开发的朋友，却有比我们多的多的工作之外的时间，甚至他们工作的时间有的时候是和生活的时间是可以兼顾的，他们可以通过市场开发，认识各个行业的人士，可以认识各种各样的朋友，他们比我们坦率说更有发财和发展的机会，只要他们跟我们一样勤奋。（有一种勤奋的普通人，如果给他换个地方，他马上会成为一个勤奋且出众的人。）
二、在学习技术的时候千万不要认为如果做到技术最强，就可以成为100%受尊重的人。
有一次一个人在面试项目经理的时候说了这么一段话：我只用最听话的人，按照我的要求做只要是听话就要，如果不听话不管他技术再好也不要。随后这个人得到了试用机会，如果没意外的话，他一定会是下一个项目经理的继任者。
朋友们你知道吗？不管你技术有多强，你也不可能自由的腾出时间象别人那样研究一下LINUX源码，甚至写一个LINUX样的杰作来表现你的才能。你需要做的就是按照要求写代码，写代码的含义就是都规定好，你按照规定写，你很快就会发现你昨天写的代码，跟今天写的代码有很多类似，等你写过一段时间的代码，你将领略：复制，拷贝，粘贴那样的技术对你来说是何等重要。（如果你没有做过1年以上的真正意义上的开发不要反驳我）。
如果你幸运的能够听到市场人员的谈话，或是领导们的谈话，你会隐约觉得他们都在把技术人员当作编码的机器来看，你的价值并没有你想象的那么重要。而在你所在的团队内部，你可能正在为一个技术问题的讨论再跟同事搞内耗，因为他不服你，你也不服他，你们都认为自己的对，其实你们两个都对，而争论的目的就是为了在关键场合证明一下自己比对方技术好，比对方强。（在一个项目开发中，没有人愿意长期听别人的，总想换个位置领导别人。）
三、你更不要认为，如果我技术够好，我就自己创业，自己有创业的资本，因为自己是搞技术的。
如果你那样认为，真的是大错特错了，你可以做个调查在非技术人群中，没有几个人知道C#与JAVA的，更谈不上来欣赏你的技术是好还是不好。一句话，技术仅仅是一个工具，善于运用这个工具为别人干活的人，却往往不太擅长用这个工具来为自己创业，因为这是两个概念，训练的技能也是完全不同的。
创业最开始的时候，你的人际关系，你处理人际关系的能力，你对社会潜规则的认识，还有你明白不明白别人的心，你会不会说让人喜欢的话，还有你对自己所提供的服务的策划和推销等等，也许有一万，一百万个值得我们重视的问题，但你会发现技术却很少有可能包含在这一万或一百万之内，如果你创业到了一个快成功的阶段，你会这样告诉自己：我干吗要亲自做技术，我聘一个人不就行了，这时候你才真正会理解技术的作用，和你以前做技术人员的作用。
[小结]
基于上面的讨论，我奉劝那些学习技术的朋友，千万不要拿科举考试样的心态去学习技术,对技术的学习几近的痴迷，想掌握所有所有的技术，以让自己成为技术领域的权威和专家，以在必要的时候或是心里不畅快的时候到网上对着菜鸟说自己是前辈。
技术仅仅是一个工具，是你在人生一个阶段生存的工具，你可以一辈子喜欢他，但最好不要一辈子靠它生存。
掌握技术的唯一目的就是拿它找工作（如果你不想把技术当作你第二生命的话），就是干活。所以你在学习的时候千万不要去做那些所谓的技术习题或是研究那些帽泡算法，最大数算法了，什么叫干活？
就是做一个东西让别人用，别人用了，可以提高他们的工作效率，想象吧，你做1万道技术习题有什么用？只会让人觉得酸腐，还是在学习的时候，多培养些自己务实的态度吧，比如研究一下当地市场目前有哪些软件公司用人，自己离他们的要求到底有多远，自己具体应该怎么做才可以达到他们的要求。等你分析完这些，你就会发现，找工作成功，技术的贡献率其实并没有你原来想象的那么高。
不管你是学习技术为了找工作还是创业，你都要对技术本身有个清醒的认识，在中国不会出现BILL GATES，因为，中国目前还不是十分的尊重技术人才，还仅仅的停留在把软件技术人才当作人才机器来用的尴尬境地。（如果你不理解，一种可能是你目前仅仅从事过技术工作，你的朋友圈子里技术类的朋友占了大多数，一种可能是你还没有工作，但喜欢读比尔。盖茨的传记）。
2009年4月1日星期三
不得不记录下 关于s60虚拟机文件保存地点
最近在做手机的开发，基于j2me。刚开始起步，发现没遇到过什么问题。配置，测试，几个简单的入门demo。都很顺利。
由于这次手机开发是针对流媒体在线播放的，rms好像是最好个解决。但我想第一步调通播放已下载文件。所以就像先找下虚拟机内部创建文件的保存地址。sun的虚拟机很好找，搜索下就有了。接下来是塞班的s60，这个让我好找啊，以至于到现在还没睡觉。
当然第一步是在s60内部创建一个文件，然搜索下相关文件夹。奇怪的是没有找到。但后我想是不是改变文件名了，所以就文件河，全电脑监控。这下更加惊讶的事情发生了，没有相关操作！！！
是在困惑下，网上找也没找到相关回答。实在是纳闷，而且测试文件是否存在是，所创建的文件是存在的，并没有随文件突出而删除。
本人修行不够啊，实在是无法理解。后来在网上看到一篇关于塞班系统配置的，就猜想尝试下加点参数进去制定下虚拟机的e盘。epoc.ini中
_EPOC_DRIVE_D \epoc32\winscw\d
_EPOC_DRIVE_E \epoc32\winscw\e
莫名的发现指定后文件就在指定文件夹下生成了。实在无语。对于手机开发还真是菜鸟阶段啊。本来感觉j2me，比起j2ee简单多了，可以说比j2se，在编程上还简单。现在发现j2me的难点所在，就是不同机型的熟识程度。
做了三天的j2me开发，发现很有意思，你j2ee开发快多了。
如此奇怪的事情，不得不记录下。 让像我一样刚开始j2me开发的菜鸟，少走点弯路吧。累了睡觉去了。
唉，因为这件事，今天的三份报告都来不及赶了。。。。。
由于这次手机开发是针对流媒体在线播放的，rms好像是最好个解决。但我想第一步调通播放已下载文件。所以就像先找下虚拟机内部创建文件的保存地址。sun的虚拟机很好找，搜索下就有了。接下来是塞班的s60，这个让我好找啊，以至于到现在还没睡觉。
当然第一步是在s60内部创建一个文件，然搜索下相关文件夹。奇怪的是没有找到。但后我想是不是改变文件名了，所以就文件河，全电脑监控。这下更加惊讶的事情发生了，没有相关操作！！！
是在困惑下，网上找也没找到相关回答。实在是纳闷，而且测试文件是否存在是，所创建的文件是存在的，并没有随文件突出而删除。
本人修行不够啊，实在是无法理解。后来在网上看到一篇关于塞班系统配置的，就猜想尝试下加点参数进去制定下虚拟机的e盘。epoc.ini中
_EPOC_DRIVE_D \epoc32\winscw\d
_EPOC_DRIVE_E \epoc32\winscw\e
莫名的发现指定后文件就在指定文件夹下生成了。实在无语。对于手机开发还真是菜鸟阶段啊。本来感觉j2me，比起j2ee简单多了，可以说比j2se，在编程上还简单。现在发现j2me的难点所在，就是不同机型的熟识程度。
做了三天的j2me开发，发现很有意思，你j2ee开发快多了。
如此奇怪的事情，不得不记录下。 让像我一样刚开始j2me开发的菜鸟，少走点弯路吧。累了睡觉去了。
唉，因为这件事，今天的三份报告都来不及赶了。。。。。
订阅：
博文 (Atom)