刚才电话拒绝了NEC，很伤感，哭了

阿佩

我晕，开发个东西怎么都说得这么高深。。。。根本看不懂。哈哈哈[em02]

lalatoki

QUOTE:以下是引用huyi_zg在2007-5-10 16:28:00的发言：让我想起曾经做过的一个项目，要处理日本大型连锁店的海量数据，原本Oracle+J2EE的架构已经不行了，Oracle的处理速度太慢，不能满足需求。Oracle的咨询师解决不了，Java的内存管理也老出问题，堂堂NEC不得不向一家叫数理技研（www.suri.co.jp）的“小公司”求教。原本想让人派一个组过来，结果人家说：你们这样的公司，我们派一个人对应就可以了，结果真的只来了一个人。当然当时有开玩笑的语气，但也能感觉到别人对这帮机器的藐视。
数理技研今年也开始招人了，大家有实力的可以去试试，这样的公司才是值得骄傲，值得奋斗的。我觉得一个工作过的人的看法，应该会比刚毕业的人准一些，所以还没有内定的精英们请相信我，我相信3年后会比去NEC，NRI强很多。看了你写的，对我很有启发。当初我不想去电通也是因为觉得学不到什么真正的技术。确实真正要学技术也就我们这种年龄或者更加年轻的时候才能好好的学到，
感觉在技术的世界里面没有什么大手和小手，技术先进的就是老大，就拽，
就象10年前的nVDIA还是一个名不见经传的小公司，现在却占据了显卡市场的大半江山一样
而当年风光一时的voodoo，因为技术力不济，只能成为历史的尘埃
IT就是这样一个竞争的，优胜劣汰的世界，非常符合自然规律，
弱肉强食的世界很能逼着一些不自觉的，懒惰的人（比如我）往前跑
小弟一片帖子，引出huyi_zg和麻药屋2046两位高手，实在是很荣幸
小弟我只会用用tomcat，eclipse，mySQL之类的，和用oracle等大型开发相比显得幼稚很多
以后在技术方面还请多多指教
看坛子上从事IT技术的还是很多的，建议斑竹开个IT的分论坛，大家可以交流交流

huyi_zg

QUOTE:以下是引用麻药屋2046在2007-5-11 8:47:00的发言：零售业和金融业我都做过，零售业是Seven-Eleven，金融业是野村证券
你这一个业务才250秒啊。。。当年做Seven-Eleven的一个活，让我用C语言重写AB,CD的Patten，然后框框几十个表Join，我开始也没在意性能什么的，随便写完拿本番数据一测，要用3，4个小时，当然了，数据量是非常大的，几百万条大概。。。后来改了一下代码，缩短到了2分半钟。。。。
你们只是那个业务重写成C语言的倒容易了，要是整个系统好几百本程序都重写成C的，估计这个活就肯定是赤字了。自己会社内用得还好办。
说到64位，前些日子在在windows 2003 64位下面对一个PCI卡，开发了一个控制程序，控制什么的呢，呵呵，就是利用这个卡，远程控制横滨新建的那个风车，大家到横滨红房子海边那个广场，往左边海对面看看，一个非常巨大的风力发电用的风车，就是用来控制在它上面打灯光的。这个风车的运行数据远程采集也是我开发的，一秒采集一次。

最快的一笔业务是250秒，数据量是远远不止几百万条的，总合起来，每天都只有6个小时的时间来处理接近80GB的数据，80GB这个峰值和我们的硬件极限已经很贴近了，所以这个问题只是被缓解了，并不是解决了。最后我们的结论是迟早会出现新的瓶颈。
我也很想了解一下你们用的什么手段来解决这个问题。我主要工作就是大规模数据处理，在这方面经验还是比较多的，遇见同行了，可以多交流。
数据采集没有做过，你是做的对收集到的数据分析这块，还是PCI卡的驱动或者是数据传送这块呢。嵌入式一直都是我想做的，但是每次面试都被人以无嵌入式经验所拒绝了，无耐，日本人就是只相信经验。

huyi_zg

QUOTE:以下是引用lalatoki在2007-5-11 9:46:00的发言：看了你写的，对我很有启发。当初我不想去电通也是因为觉得学不到什么真正的技术。确实真正要学技术也就我们这种年龄或者更加年轻的时候才能好好的学到，
感觉在技术的世界里面没有什么大手和小手，技术先进的就是老大，就拽，
就象10年前的nVDIA还是一个名不见经传的小公司，现在却占据了显卡市场的大半江山一样
而当年风光一时的voodoo，因为技术力不济，只能成为历史的尘埃
IT就是这样一个竞争的，优胜劣汰的世界，非常符合自然规律，
弱肉强食的世界很能逼着一些不自觉的，懒惰的人（比如我）往前跑
小弟一片帖子，引出huyi_zg和麻药屋2046两位高手，实在是很荣幸
小弟我只会用用tomcat，eclipse，mySQL之类的，和用oracle等大型开发相比显得幼稚很多
以后在技术方面还请多多指教
看坛子上从事IT技术的还是很多的，建议斑竹开个IT的分论坛，大家可以交流交流


其实现在肯学技术的人真的比较少，看得出来你还是真心想学的，继续保持这种心态。
我个人觉得，浮在面上的技术，始终会被抛去，如果楼主想让自己的知识投资更稳固一点，不愿意追求日新月异的新概念和技术，那可以重点研究60年代，70年代，80年代就出现了，并且到今天依然重要的那些东西，它们是通过了时间考验的，不会轻易倒下，当前新出的技术，大多也只是围绕它们在转。比如说操作系统方面的Linux，语言方面的c和cpp是比较好的投资选择。缺点是这些方向5年才可小成，比5年成大器的动态语言开发来，确实难了不少。（不是难在其本身，而是其背后庞大的知识体系，其应用的领域）
因为工作的关系，所以我能够感到Linux，c的开发在日本还是很有前途的，但是现在为什么做c和linux方面的外包公司会那么少，是由于近年来兴起的web化所影响的吗？还是因为开发风险的原因？
我到日本的真正目的，就是找出这个答案，以此建立自己的事业，我相信这个市场。
选择没有对错，做出选择后自己的努力与否，才是让人走向对与错的路。

阿佩

linux还是比较有前途的，至于c，实在是让我个人无法认同的东西。

麻药屋2046

QUOTE:以下是引用huyi_zg在2007-5-11 13:06:00的发言：
最快的一笔业务是250秒，数据量是远远不止几百万条的，总合起来，每天都只有6个小时的时间来处理接近80GB的数据，80GB这个峰值和我们的硬件极限已经很贴近了，所以这个问题只是被缓解了，并不是解决了。最后我们的结论是迟早会出现新的瓶颈。
我也很想了解一下你们用的什么手段来解决这个问题。我主要工作就是大规模数据处理，在这方面经验还是比较多的，遇见同行了，可以多交流。
数据采集没有做过，你是做的对收集到的数据分析这块，还是PCI卡的驱动或者是数据传送这块呢。嵌入式一直都是我想做的，但是每次面试都被人以无嵌入式经验所拒绝了，无耐，日本人就是只相信经验。

我做的主要是与服务器间的远程通讯，socket编程，用的C#，感觉比较方便，融合了java和vb的优点，不过VS2005硬要加上线程安全，比较烦，要多写不少代码，或者改参数忽略线程安全。
大量数据处理，目前来看，一方面就是提高程序的执行速度，比如不用解释执行的java，而用编译执行的C，C++，就高级语言来说，效率很高，开发游戏的最讲效率，除了手机游戏要求平台适应性，无关性而用J2ME开发以外，没见过几个用Java做游戏的，效率确实不行，其实用J2EE做企业开发，主要还是为了适应BS开发模式。
除了语言方面，并行处理也是非常有效的方法，你们用的方法应该是最佳的选择了。不知道你们实现并行处理用的是多线程还是多进程？多进程的话比较麻烦。。。
其实我技术不够专精，但是各个方面的都做过一些而已。

huyi_zg

QUOTE:以下是引用阿佩在2007-5-11 14:21:00的发言：linux还是比较有前途的，至于c，实在是让我个人无法认同的东西。
C是随UNIX而生的，没有UNIX就没有C，但同时也可以说没有C的话，就没有今天的UNIX和LINUX。
做为一个操作系统，必须要有强大的硬体控制能力，C的控制力和简单易用性正是解决操作系统发展的最有力武器。
无法认同c的话，可能是指的业务应用方面吧。的确动态语言的出现解决了业务开发的难题。动态语言高效的开发效率和越来越贴近native语言的运行时效率（甚至我认为运行时效率某些应用今后很可能超过native代码，从超小型对象分配的速度就可以窥见一斑，当然这只是个人推断，现在还没有任何依据来证明）让大部分的业务开发不得不放弃难于无错应用的本地语言。但是，如果Linux要发展的话，不认同c是没有意义的。原生接口定义，还是靠C来做的实现。不要说java了，甚至连CPP都没有杀入这个领域。CPP虽然拥有更可能更加强大的控制力和运行效率，但还是缺少一样东西，导致迟迟不能杀入操作系统领域，这就是ABI，二进制程序接口，换句更通俗的话说，就是移植能力。当今，C是真正的移植之王。

再补充一点，UNIX/LINUX平台少C应用远远多于CPP应用，也是因为ABI的原因。
我是忠实的cpp fans，但是从不否定C。

[此贴子已经被作者于2007-5-11 16:01:49编辑过]

阿佩

有的地方确实必须依存c,
很简单的比喻，c就是个山地自行车，作为交通工具，长久不衰。哪里都可以去，胡同也可以钻。
但是，如今交通很发达，从东京去大阪，能做新干线，要啥自行车啊。
不过你想要在旅途中玩出花样，新干线可不行。。。。。。

huyi_zg

QUOTE:以下是引用麻药屋2046在2007-5-11 14:34:00的发言：
我做的主要是与服务器间的远程通讯，socket编程，用的C#，感觉比较方便，融合了java和vb的优点，不过VS2005硬要加上线程安全，比较烦，要多写不少代码，或者改参数忽略线程安全。
大量数据处理，目前来看，一方面就是提高程序的执行速度，比如不用解释执行的java，而用编译执行的C，C++，就高级语言来说，效率很高，开发游戏的最讲效率，除了手机游戏要求平台适应性，无关性而用J2ME开发以外，没见过几个用Java做游戏的，效率确实不行，其实用J2EE做企业开发，主要还是为了适应BS开发模式。
除了语言方面，并行处理也是非常有效的方法，你们用的方法应该是最佳的选择了。不知道你们实现并行处理用的是多线程还是多进程？多进程的话比较麻烦。。。
其实我技术不够专精，但是各个方面的都做过一些而已。

恰巧我是做这个程序的异构整合的，也就是让java等其他程序和我们的处理程序交互。一个重要的实现手段就是服务器的通讯，我也经常用到socket。
动态语言的socket编程我没有做过，不知道优缺点。凭想象来说，优点应该是方便的开发和你所提到的安全性了。在c/cpp上，要做到这两点真的很难，原生API的使用非常容易出错，要做好进程间通讯的话，需要老道的经验。我推荐一个叫ACE的中间件平台，我相信能很大程度上解决这些问题。我曾经自己做过一个产品，支持xmpp协议的服务器，就用到了ace，给我的感觉就是爽，让基于cpp的网络编程也变得容易，高效，安全，跨平台。
如果是用dotnet的话，那应该也从windows体系继承了一些强大的网络特性，比如说IOCP，不知道dotnet里面有没有封装？
缺点的话，比较牵强的说，可能还是集中在效率上，涉及到数据在非托管和托管堆间来回复制的问题，除非操作系统核心托管化，之前似乎盛传vista会内核托管化，但好像最终也没做到。
并行计算编程上太困难了，C和CPP连支持该特性的关键字都没有，只能靠程序库来实现，这也是被java等语言耻笑的一个原因。很遗憾的说，并行就是整个系统真正的核心部分，小日本没有让我们看到具体的实现过程，只是看到了概念设计图，我想这就是中国最大的遗憾了，所以为什么都是说给他们打杂呢。在UNIX和LINUX上只有进程的概念，所谓的线程，在UNIX中被称为轻量级进程，其实就是进程，因为UNIX分配进程的速度非常快，所以没有必要再做个线程管理出来。这个体系中，我知道的只有Sorlaris实现了线程的概念。
我那个项目做并行运算的具体实现细节，我没法回答，小日本在这里留了一手。
我用自己的并行编程经验回答：
第一条原则就是不要做并行编程。并行编程是最复杂的编程，极容易出错，甚至达不到原始预想的效率。就像CPU颗数一样，8颗加到9颗的时候，效率不升还降，呵呵。
第二条原则是弄清楚应用的类型，看看是不是要使用多进程，多线程，怎么用。如果是计算性特别强的程序，CPU本来就吃紧让不出来，多线程只会让程序更慢。当前的多核应用可能会缓解这个现象。如果是IO密集型应用，在DMA技术的帮助下，CPU长期处于空闲状态的话，那可以考虑使用多线程。
第三条就是让共享数据，进程间通讯量尽量的少，加锁的时间尽可能的短。这个可能就要从业务方面入手了，组织一个良好的数据结构和处理方式。让程序看起来就是一个单线程应用一样，既努力不让别人影响到自己，也努力不去打搅别人。
我说到的三点只是九牛一毛，并行编程的概念太大了，有兴趣的话今后可以继续探讨。

[此贴子已经被作者于2007-5-11 16:43:21编辑过]

huyi_zg

QUOTE:以下是引用阿佩在2007-5-11 16:17:00的发言：有的地方确实必须依存c,
很简单的比喻，c就是个山地自行车，作为交通工具，长久不衰。哪里都可以去，胡同也可以钻。
但是，如今交通很发达，从东京去大阪，能做新干线，要啥自行车啊。
不过你想要在旅途中玩出花样，新干线可不行。。。。。。


我还是觉得，现在大部分的业务都是基于新型语言的，这个市场是很大了，但是同时吃这块蛋糕的人也很多。
从应用的角度来讲，c和其他语言当然是各有千秋，就像中国那句古话，行行出状元。
不是java牛逼，而是使用java的人牛逼。如果真要比高下，我觉得是人和人比，不是语言和语言比。
其实我通篇来说看好linux，c，更多的说是看好他们在日本的市场。各位有没有觉得现在这个市场在日本做得并不好呢。
我大哥也是外包公司的老板，现在他们公司也是50号人了，并且马上公司就有三个UNIX特别强的人物。即使如此，他还是不敢接UNIX方面的项目，说风险太大了。这个市场没有成熟，同时标志着充满了机遇。

[此贴子已经被作者于2007-5-11 16:54:23编辑过]