99精品偷自拍,国产精品黄色,成人免费看视频网站

桌面Java瘦��n 注重Ajax特征

RomKK — Thu, 26 Jul 2007 01:49:00 GMT

��Z��桌面Java的未来发展，许多的重大改�q�正在进行中�Q�对此做了很大的努力

　　��p��a�斚w��来说�Q�出��C��JavaFX script ��目�?/span>JavaFX是很灵��y的，它提供了一个高�U�的脚本接口�Q�运行在Java 2D�?/span>API上。从用户的角度来看，他们不需要编�?/span>Java代码�Q�不需要深入理解复杂的�U�程�Q?/span>Java 2D�Q?/span>Swing�cȝ��层次�l�构�Q�定时框架结�?/span>(timing framework)�{�等。相反，他们只是�~�写脚本语言和描�l�出所需要的GUI�Q�包括活波的韛_��效果�Q�图形效果，比如说梯度或者音乐，和数据绑定等�{�，�q�些都徏立在一个基��API上�?/span>

　　�q�里有许多的工具帮助你学�?/span>syntax语言�Q�相兌��源这个从�q�个�|�站获得;JavaFX研发��组的目标就是提�?/span>syntax语言�Q�和一些关�?/span>JavaFX的用户体验，�q�些用户包括��术设计员和那些对应用程序可视界面美观感兴趣的民众。当前，JavaFX某种�E�度上作为第四步产生的语�a�在运行，因�ؓ首先是解释器��?/span>FX脚本创徏成�ؓJava代码�Q�然后再调用适当�?/span>Java 2D API。该��组长期的目标是��?/span>FX脚本直接�~�译成字节码�?/span>

　　JavaFX��d��到桌�?/span>Java是一仉��常好的事情，但是�Q�这得取决于是否有这��L��一�U?/span>JRE的存在，它能�q�行JavaFX生成的代码。有些�h认�ؓFX已经�q�军�?/span>RIA(rich Internet application)领域�Q�和Adobe公司�?/span> Flex一较高下。但是，目前�q�是有一些难题需要解冻I��举个例子�Q�如何才能让桌面Java的安装体验和�q�行旉��性能比得上其它的RIA框架。还好，�q�种问题正在被其他的��目解决�Q�这个项目名�U�就�?/span>Java kernel�?/span>

　　Java kernel��d��承认�q�么一个事情，卛_��多数�?/span>Java应用�E�序都是只有JRE的部分大��，�?/span>Limewire(一个文件共享的桌面应用�E�序)�Q�它只有JRE的三分之一大小�?/span>Kernel��会�?/span>JRE重新打包�Q��得只下蝲应用�E�序所需要的部分JRE。每个程序所需要的基本部分��会被下载，作�ؓJRE启动所需要的最��部分，其他的部分根据需要下载，或者根�?/span>ClassNotFound异常信息�Q�下载缺��q��c�R��这��是一个巨大的好消息帮助桌�?/span>Java应用�E�序瘦��n�Q�同时还能��得桌�?/span>Java应用�E�序执行的更为有效。除了解军_��何下载的问题外，kernel�q�非常关�?/span>Java�E�序的启动性能�?/span>

　　在先前的kernel几个版本�Q�热启动旉��(warm start times)减少了很多，但是�Q�在应用�E�序调用main(String[])前，冷启�?/span>JRE仍然需要�g误许多秒的时间�?/span>Java kernel正在��试有效的处理冷启动�Q�将冷启动�{变�ؓ热启动，通过一些相关的技术，如预加蝲(pre-loading)JRE�Q�从��盘��d��到内存，�q�有一个操作系�l�服务，�q�个服务的功能就是监视可分配的内存来加蝲JRE�Q��得用戯��得最佳的性能。出了这些，kernel�q�提供了一个新的浏览器插�g�Q�提供给Web 开发者更多的关于桌面�q�行信息�Q�可获得�?/span>JRE水��^�{�等�?/span>

　　对于桌面Java来说�Q?/span>Java kernel �?/span>Java FX两大好消息。说Kernel是一个非常好的技术，是因为它承认�?/span>Swing已经��C��一个非常成熟的阶段�Q��ƈ且帮助开发这如何��他们的Java应用�E�序更�ؓ快速，更�ؓ有效的搬到用��h��面上。说FX是两外一个非常好的消息，是因为它�?/span>Java开发者打开了新��章�Q�特别是那些愿意使用脚本语言和做一些高�U�的�Q�活波的�Q�图形效果的开发者，他们只需要写��单几行代码就可以完成。我�怿��q�两��Ҏ��术将会��得更多的应用�E�序�?/span>Java语言�~�写�Q�运行在用户的机器上�Q�同�Ӟ��对于用户和开发者来��_��应用�E�序变得更快�Q�更��单�?/span>

RomKK 2007-07-26 09:49 发表评论

��Z��Swing的免费look and feel(有很多哟)

RomKK — Wed, 25 Jul 2007 01:56:00 GMT

      用java写桌面程序的时候，��L��抱怨Swing的页面太隄��Q�而很多的Look and Feel 都是收费的�?br>
      今天发现一个好东东�Q�全是免费的�Q�效果还不错呀�Q�感兴趣的话赶紧��M��吧！

     下蝲地址�Q?http://www.javootoo.com/ 上有一个free look and feel 栏目

RomKK 2007-07-25 09:56 发表评论

RomKK — Wed, 25 Jul 2007 01:32:00 GMT

通过扩展RandomAccessFile�c�M��之具备Buffer改善I/O性能

JAVA的文仉��机存取类�Q�RandomAccessFile�Q�的I/O效率较低。通过分析其中原因�Q�提��x��案。逐步展示如何创徏具备�~�存��d��能力的文仉��机存取类�Q��ƈ�q�行了优化。通过与其它文件访问类的性能�Ҏ��Q�证明了其实用�h倹{�?/blockquote>
��M��Q?/font>

开发�h员��用RandomAccessFile�c�L��。其I/O性能较之其它常用开发语�a�的同�c�L��能差距甚远�Q�严重媄响程序的�q�行效率。开发�h员迫切需要提高效率，下面分析RandomAccessFile�{�文件类的源代码�Q�找出其中的症结所在，�q�加以改�q�优化，创徏一�?�?��h��"�׃��的随机文件访问类BufferedRandomAccessFile�?br>

在改�q�之前先做一个基本测试：逐字节COPY一�?2兆的文�g�Q�这里牵涉到��d��写）�?/span>

�?/td> �?/td> 耗用旉��Q�秒�Q?/td>

RandomAccessFile RandomAccessFile 95.848

BufferedInputStream + DataInputStream BufferedOutputStream + DataOutputStream 2.935

我们可以看到两者差距约32倍，RandomAccessFile也太慢了。先看看两者关键部分的源代码，�Ҏ��分析�Q�找出原因�?/p>
1�Q?�Q�[RandomAccessFile]

public class RandomAccessFile implements DataOutput, DataInput { public final byte readByte() throws IOException { int ch = this.read(); if (ch < 0) throw new EOFException(); return (byte)(ch); } public native int read() throws IOException; public final void writeByte(int v) throws IOException { write(v); } public native void write(int b) throws IOException; }

可见�Q�RandomAccessFile每读/写一个字节就需对磁盘进行一�ơI/O操作�?/p>
1�Q?�Q�[BufferedInputStream]

public class BufferedInputStream extends FilterInputStream { private static int defaultBufferSize = 2048; protected byte buf[]; // 建立�ȝ��存区 public BufferedInputStream(InputStream in, int size) { super(in); if (size <= 0) { throw new IllegalArgumentException("Buffer size <= 0"); } buf = new byte[size]; } public synchronized int read() throws IOException { ensureOpen(); if (pos >= count) { fill(); if (pos >= count) return -1; } return buf[pos++] & 0xff; // 直接从BUF[]中读�? } private void fill() throws IOException { if (markpos < 0) pos = 0; /* no mark: throw away the buffer */ else if (pos >= buf.length) /* no room left in buffer */ if (markpos > 0) { /* can throw away early part of the buffer */ int sz = pos - markpos; System.arraycopy(buf, markpos, buf, 0, sz); pos = sz; markpos = 0; } else if (buf.length >= marklimit) { markpos = -1; /* buffer got too big, invalidate mark */ pos = 0; /* drop buffer contents */ } else { /* grow buffer */ int nsz = pos * 2; if (nsz > marklimit) nsz = marklimit; byte nbuf[] = new byte[nsz]; System.arraycopy(buf, 0, nbuf, 0, pos); buf = nbuf; } count = pos; int n = in.read(buf, pos, buf.length - pos); if (n > 0) count = n + pos; } }

1�Q?�Q�[BufferedOutputStream]

public class BufferedOutputStream extends FilterOutputStream { protected byte buf[]; // 建立写缓存区 public BufferedOutputStream(OutputStream out, int size) { super(out); if (size <= 0) { throw new IllegalArgumentException("Buffer size <= 0"); } buf = new byte[size]; } public synchronized void write(int b) throws IOException { if (count >= buf.length) { flushBuffer(); } buf[count++] = (byte)b; // 直接从BUF[]中读�? } private void flushBuffer() throws IOException { if (count > 0) { out.write(buf, 0, count); count = 0; } } }

可见�Q�Buffered I/O putStream每读/写一个字节，若要操作的数据在BUF中，��q��接对内存的buf[]�q�行�?写操作；否则从磁盘相应位�|�填充buf[]�Q�再直接对内存的buf[]�q�行�?写操作，�l�大部分的读/写操作是对内存buf[]的操作�?/p>
1�Q?�Q�小�l?/strong>

内存存取旉��单位是纳�U��Q?0E-9�Q�，��盘存取旉��单位是毫�U��Q?0E-3�Q�，同样操作一�ơ的开销�Q�内存比��盘快了百万倍。理��Z��可以预见�Q�即使对内存操作上万�ơ，��p��的时间也�q�少对于��盘一�ơI/O的开销。显然后者是通过增加位于内存的BUF存取�Q�减��磁盘I/O的开销�Q�提高存取效率的�Q�当然这样也增加了BUF控制部分的开销。从实际应用来看�Q�存取效率提高了32倍�?br>

�Ҏ��1.3得出的结论，现试着对RandomAccessFile�c�M��加上�~�冲��d��机制�?/span>

随机讉K��c�M��序�c�M��同，前者是通过实现DataInput/DataOutput接口创徏的，而后者是扩展FilterInputStream/FilterOutputStream创徏的，不能直接照搬�?/p>
2�Q?�Q�开辟缓冲区BUF[默认�Q?024字节]�Q�用作读/写的��q��~�冲区�?/strong>

2�Q?�Q�先实现�ȝ��册Ӏ?/strong>

�ȝ��冲逻辑的基本原理：

A �Ʋ读文�gPOS位置的一个字节�?/p>
B 查BUF中是否存在？若有�Q�直接从BUF中读取，�q�返回该字符BYTE�?/p>
C 若没有，则BUF重新定位到该POS所在的位置�q�把该位�|�附�q�的BUFSIZE的字节的文�g内容填充BUFFER�Q�返回B�?/p>
以下�l�出关键部分代码及其说明�Q?/p>

public class BufferedRandomAccessFile extends RandomAccessFile { // byte read(long pos)�Q�读取当前文件POS位置所在的字节 // bufstartpos、bufendpos代表BUF映射在当前文件的�?��ց��U�d��址�? // curpos指当前类文�g指针的偏�U�d��址�? public byte read(long pos) throws IOException { if (pos < this.bufstartpos || pos > this.bufendpos ) { this.flushbuf(); this.seek(pos); if ((pos < this.bufstartpos) || (pos > this.bufendpos)) throw new IOException(); } this.curpos = pos; return this.buf[(int)(pos - this.bufstartpos)]; } // void flushbuf()�Q�bufdirty为真�Q�把buf[]中尚未写入磁盘的数据�Q�写入磁盘�? private void flushbuf() throws IOException { if (this.bufdirty == true) { if (super.getFilePointer() != this.bufstartpos) { super.seek(this.bufstartpos); } super.write(this.buf, 0, this.bufusedsize); this.bufdirty = false; } } // void seek(long pos)�Q�移动文件指针到pos位置�Q��ƈ把buf[]映射填充至POS 所在的文�g块�? public void seek(long pos) throws IOException { if ((pos < this.bufstartpos) || (pos > this.bufendpos)) { // seek pos not in buf this.flushbuf(); if ((pos >= 0) && (pos <= this.fileendpos) && (this.fileendpos != 0)) { // seek pos in file (file length > 0) this.bufstartpos = pos * bufbitlen / bufbitlen; this.bufusedsize = this.fillbuf(); } else if (((pos == 0) && (this.fileendpos == 0)) || (pos == this.fileendpos + 1)) { // seek pos is append pos this.bufstartpos = pos; this.bufusedsize = 0; } this.bufendpos = this.bufstartpos + this.bufsize - 1; } this.curpos = pos; } // int fillbuf()�Q�根据bufstartpos�Q�填充buf[]�? private int fillbuf() throws IOException { super.seek(this.bufstartpos); this.bufdirty = false; return super.read(this.buf); } }

��x��~�冲��d��本实玎ͼ�逐字节COPY一�?2兆的文�g�Q�这里牵涉到��d��写，用BufferedRandomAccessFile试一下读的速度�Q�：

�?/td> �?/td> 耗用旉��Q�秒�Q?/td>

RandomAccessFile RandomAccessFile 95.848

BufferedRandomAccessFile BufferedOutputStream + DataOutputStream 2.813

BufferedInputStream + DataInputStream BufferedOutputStream + DataOutputStream 2.935

可见速度显著提高�Q�与BufferedInputStream+DataInputStream不相上下�?/p>
2�Q?�Q�实现写�~�冲�?/strong>

写缓冲逻辑的基本原理：

A�Ʋ写文�gPOS位置的一个字节�?/p>
B 查BUF中是否有该映��？若有�Q�直接向BUF中写入，�q�返回true�?/p>
C若没有，则BUF重新定位到该POS所在的位置�Q��ƈ把该位置附近�?BUFSIZE字节的文件内容填充BUFFER�Q�返回B�?/p>
下面�l�出关键部分代码及其说明�Q?/p>

// boolean write(byte bw, long pos)�Q�向当前文�gPOS位置写入字节BW�? // �Ҏ��POS的不同及BUF的位�|�：存在修改、追加、BUF中、BUF外等�? ��c��在逻辑判断�Ӟ��把最可能出现的情况，最先判断，�q�样可提高速度�? // fileendpos�Q�指�C�当前文件的��ց��U�d��址�Q�主要考虑到追加因�? public boolean write(byte bw, long pos) throws IOException { if ((pos >= this.bufstartpos) && (pos <= this.bufendpos)) { // write pos in buf this.buf[(int)(pos - this.bufstartpos)] = bw; this.bufdirty = true; if (pos == this.fileendpos + 1) { // write pos is append pos this.fileendpos++; this.bufusedsize++; } } else { // write pos not in buf this.seek(pos); if ((pos >= 0) && (pos <= this.fileendpos) && (this.fileendpos != 0)) { // write pos is modify file this.buf[(int)(pos - this.bufstartpos)] = bw; } else if (((pos == 0) && (this.fileendpos == 0)) || (pos == this.fileendpos + 1)) { // write pos is append pos this.buf[0] = bw; this.fileendpos++; this.bufusedsize = 1; } else { throw new IndexOutOfBoundsException(); } this.bufdirty = true; } this.curpos = pos; return true; }

��x��~�冲写基本实玎ͼ�逐字节COPY一�?2兆的文�g�Q�（�q�里牉|��到读和写�Q�结合缓冲读�Q�用BufferedRandomAccessFile试一下读/写的速度�Q�：

�?/td> �?/td> 耗用旉��Q�秒�Q?/td>

RandomAccessFile RandomAccessFile 95.848

BufferedInputStream + DataInputStream BufferedOutputStream + DataOutputStream 2.935

BufferedRandomAccessFile BufferedOutputStream + DataOutputStream 2.813

BufferedRandomAccessFile BufferedRandomAccessFile 2.453

可见�l�合�?写速度已超��BufferedInput/OutputStream+DataInput/OutputStream�?/p>
优化BufferedRandomAccessFile�?/span>

优化原则�Q?/p>

调用频繁的语句最需要优化，且优化的效果最明显�?
多重嵌套逻辑判断�Ӟ��最可能出现的判断，应放在最外层�?
减少不必要的NEW�?

�q�里举一典型的例子：

public void seek(long pos) throws IOException { ... this.bufstartpos = pos * bufbitlen / bufbitlen; // bufbitlen指buf[]的位长，例：若bufsize=1024�Q�则bufbitlen=10�? ... }

seek函数使用在各函数中，调用非常频繁�Q�上面加重的�q�行语句�Ҏ��pos和bufsize��定buf[]对应当前文�g的映��位�|�，�?*"�?/"��定�Q�显然不是一个好�Ҏ��?/p>
优化一�Q�this.bufstartpos = (pos << bufbitlen) >> bufbitlen;

优化二：this.bufstartpos = pos & bufmask; // this.bufmask = ~((long)this.bufsize - 1);

两者效率都比原来好�Q�但后者显然更好，因�ؓ前者需要两�ơ移位运��、后者只需一�ơ逻辑与运��（bufmask可以预先得出�Q��?/p>
��x��优化基本实现�Q�逐字节COPY一�?2兆的文�g�Q�（�q�里牉|��到读和写�Q�结合缓冲读�Q�用优化后BufferedRandomAccessFile试一下读/写的速度�Q�：

�?/td> �?/td> 耗用旉��Q�秒�Q?/td>

RandomAccessFile RandomAccessFile 95.848

BufferedInputStream + DataInputStream BufferedOutputStream + DataOutputStream 2.935

BufferedRandomAccessFile BufferedOutputStream + DataOutputStream 2.813

BufferedRandomAccessFile BufferedRandomAccessFile 2.453

BufferedRandomAccessFile�?/td> BufferedRandomAccessFile�?/td> 2.197

可见优化��管不明显，�q�是比未优化前快了一些，也许�q�种效果在老式��Z��会更明显�?/p>
以上比较的是��序存取�Q�即使是随机存取�Q�在�l�大多数情况下也不止一个BYTE�Q�所以缓冲机制依然有效。而一般的��序存取�c�要实现随机存取��׃��怎么�Ҏ��了�?/p>
需要完善的地方

提供文�g�q�加功能�Q?/p>

public boolean append(byte bw) throws IOException { return this.write(bw, this.fileendpos + 1); }

提供文�g当前位置修改功能�Q?/p>

public boolean write(byte bw) throws IOException { return this.write(bw, this.curpos); }

�q�回文�g长度�Q�由于BUF��d��的原因，与原来的RandomAccessFile�c�L��所不同�Q�：

public long length() throws IOException { return this.max(this.fileendpos + 1, this.initfilelen); }

�q�回文�g当前指针�Q�由于是通过BUF��d��的原因，与原来的RandomAccessFile�c�L��所不同�Q�：

public long getFilePointer() throws IOException { return this.curpos; }

提供对当前位�|�的多个字节的缓冲写功能�Q?/p>

public void write(byte b[], int off, int len) throws IOException { long writeendpos = this.curpos + len - 1; if (writeendpos <= this.bufendpos) { // b[] in cur buf System.arraycopy(b, off, this.buf, (int)(this.curpos - this.bufstartpos), len); this.bufdirty = true; this.bufusedsize = (int)(writeendpos - this.bufstartpos + 1); } else { // b[] not in cur buf super.seek(this.curpos); super.write(b, off, len); } if (writeendpos > this.fileendpos) this.fileendpos = writeendpos; this.seek(writeendpos+1); } public void write(byte b[]) throws IOException { this.write(b, 0, b.length); }

提供对当前位�|�的多个字节的缓冲读功能�Q?/p>

public int read(byte b[], int off, int len) throws IOException { long readendpos = this.curpos + len - 1; if (readendpos <= this.bufendpos && readendpos <= this.fileendpos ) { // read in buf System.arraycopy(this.buf, (int)(this.curpos - this.bufstartpos), b, off, len); } else { // read b[] size > buf[] if (readendpos > this.fileendpos) { // read b[] part in file len = (int)(this.length() - this.curpos + 1); } super.seek(this.curpos); len = super.read(b, off, len); readendpos = this.curpos + len - 1; } this.seek(readendpos + 1); return len; } public int read(byte b[]) throws IOException { return this.read(b, 0, b.length); } public void setLength(long newLength) throws IOException { if (newLength > 0) { this.fileendpos = newLength - 1; } else { this.fileendpos = 0; } super.setLength(newLength); } public void close() throws IOException { this.flushbuf(); super.close(); }

��x��完善工作基本完成�Q�试一下新增的多字节读/写功能，通过同时�?�?024个字节，来COPY一�?2兆的文�g�Q�（�q�里牉|��到读和写�Q�用完善后BufferedRandomAccessFile试一下读/写的速度�Q�：

�?/td> �?/td> 耗用旉��Q�秒�Q?/td>

RandomAccessFile RandomAccessFile 95.848

BufferedInputStream + DataInputStream BufferedOutputStream + DataOutputStream 2.935

BufferedRandomAccessFile BufferedOutputStream + DataOutputStream 2.813

BufferedRandomAccessFile BufferedRandomAccessFile 2.453

BufferedRandomAccessFile�?/td> BufferedRandomAccessFile�?/td> 2.197

BufferedRandomAccessFile�?/td> BufferedRandomAccessFile�?/td> 0.401

与JDK1.4�c�MappedByteBuffer+RandomAccessFile的对比？

JDK1.4提供了NIO�c?�Q�其中MappedByteBuffer�cȝ��于映��缓�Ԍ��也可以映��随机文件访问，可见JAVA设计者也看到了RandomAccessFile的问题，�q�加以改�q�。怎么通过MappedByteBuffer+RandomAccessFile拯��文�g呢？下面��是��试�E�序的主要部分：

RandomAccessFile rafi = new RandomAccessFile(SrcFile, "r"); RandomAccessFile rafo = new RandomAccessFile(DesFile, "rw"); FileChannel fci = rafi.getChannel(); FileChannel fco = rafo.getChannel(); long size = fci.size(); MappedByteBuffer mbbi = fci.map(FileChannel.MapMode.READ_ONLY, 0, size); MappedByteBuffer mbbo = fco.map(FileChannel.MapMode.READ_WRITE, 0, size); long start = System.currentTimeMillis(); for (int i = 0; i < size; i++) { byte b = mbbi.get(i); mbbo.put(i, b); } fcin.close(); fcout.close(); rafi.close(); rafo.close(); System.out.println("Spend: "+(double)(System.currentTimeMillis()-start) / 1000 + "s");

试一下JDK1.4的映��缓冲读/写功能，逐字节COPY一�?2兆的文�g�Q�（�q�里牉|��到读和写�Q�：

�?/td> �?/td> 耗用旉��Q�秒�Q?/td>

RandomAccessFile RandomAccessFile 95.848

BufferedInputStream + DataInputStream BufferedOutputStream + DataOutputStream 2.935

BufferedRandomAccessFile BufferedOutputStream + DataOutputStream 2.813

BufferedRandomAccessFile BufferedRandomAccessFile 2.453

BufferedRandomAccessFile�?/td> BufferedRandomAccessFile�?/td> 2.197

BufferedRandomAccessFile�?/td> BufferedRandomAccessFile�?/td> 0.401

MappedByteBuffer+ RandomAccessFile MappedByteBuffer+ RandomAccessFile 1.209

��实不错�Q�如果以后采�?.4版本开发��Y件时�Q�需要对文�g�q�行随机讉K��Q�徏议采用MappedByteBuffer+RandomAccessFile的方式。但鉴于目前采用JDK1.3及以前的版本开发的�E�序占绝大多数的实际情况�Q�如果您开发的JAVA�E�序使用了RandomAccessFile�c�L��随机讉K��文�g�Q��ƈ因其性能不佳�Q�而担心遭用户诟病�Q�请试用本文所提供的BufferedRandomAccessFile�c�，不必推翻重写�Q�只需IMPORT 本类�Q�把所有的RandomAccessFile改�ؓBufferedRandomAccessFile�Q�您的程序的性能��得到极大的提升�Q�您所要做的就�q�么��单�?/p>
未来的考虑

读者可在此基础上徏立多��늼�存及�~�存淘汰机制�Q�以应付寚w��问强度大的应用�?/p> �Q�完整代码见下篇�Q?

RomKK 2007-07-25 09:32 发表评论

一个程序员的成长的六个阶段

RomKK — Tue, 24 Jul 2007 14:22:00 GMT

�W�一阶段
此阶�D�主要是能熟�l�地使用某种语言。这��q��当于�l�武中的套�\和架式这些表面的东西�?br>�W�二阶段
此阶�D�能�_�N��基于某�U��^台的接口�Q�例如我们现在常用的Win 32的API函数�Q�以及所对应语言的自�w�的库函数。到达这个阶�D�后�Q�也��q��当于可以�q�行真实散打对练了，可以真正地在实践中做些应用�?br>�W�三阶段
此阶�D�能深入��C��解某个��^台系�l�的底层�Q�已�l�具有了初��的内功的能力�Q�也��是“手中有剑�Q�心中无�?#8221;�?br>�W�四阶��
此阶�D�能直接在��^��C��q�行比较深层�ơ的开发。基本上�Q�能辑ֈ��q�个层次��可以说是进入了高层�ơ。这时进入了高��内功的修点{��比如能�q�行VxD或操作系�l�的内核的修攏V�?br>�q�时已经不再有语�a�的束�~�，语言只是一�U�工��P��即��要用自己不会的语�a��q�行开发，也只是简单地熟悉一下，��手到擒来，完全不像是第一阶段的时候学习语�a�的那�U�情��c��一般来��_��从第三阶�D�过渡到�W�四阶段是比较困隄��。�ؓ什么会隑֑��Q�这��是因�ؓ很多人的思想变不�q�来�?br>�W�五阶��
此阶�D�就已经不再局限于��单的技术上的问题了�Q�而是能从全局上把握和设计一个比较大的系�l�体�pȝ��构，从内核到外层界面。可以说�?#8220;手中无剑�Q�心中有�?#8221;。到了这个阶�D�以后，能对市面上的��M��软�g�q�行剖析�Q��ƈ能按自己的要求进行设计，��q��是MS Word�q�样的大型��Y�Ӟ��只要有充��的旉��Q�也一定会设计出来�?br>�W�六阶��
此阶�D�也是最高的境界�Q�达�?#8220;无招胜有�?#8221;。这时候，��M��问题��q��_�变成了一个思�\的问题，不是用什么代码就能表�C�的。也��是“手中无剑�Q�心中也无剑”�?br>此时�Q�对于练功的人来��_��他已不用再去学什么少林拳�Q�只是在旁看一下少林拳的对战，��p��把此��x��来就用。这��是真正的大师��的�h物。这�Ӟ��Win 32或Linux在你眼里是没有什么差别的�?br>每一个阶�D�再向上发展旉��要按一定的�Ҏ��。第一、第二个阶段通过自学��可以完成，只要多用心去研究�Q�耐心地去学习�?br>要想从第二个阶段�q�渡到第三个阶段�Q�就要有一个好的学习环境。例如有一个高手带领或公司里有一个好的练手环境。经�q�二、三�q�的�U�篏��p��辑ֈ��W�三个阶�D�c��但是，有些人到辄��三个阶段后，常常��很难有境界上的�H�破了。他们这时会产生一�U�观念，认�ؓ软�g无非如此�Q�认��己已无所不能。其实，�q�时如果遇到大的或难些的软�g�Q�他们往往�q�是无从下手�?br>现在我们国家大部分程序员都是在第二、三�U�之间。他们大多都是通过自学成才的，不过�q�样的程序员一般在软�g公司也能独当一面，完成一些��Y件的模块�?br>但是�Q�也�q�有一大堆处在�W�一阶段的程序员�Q�他们一般就能玩玩VB�Q�做�E�序�Ӟ��L��一堆控仉��成一个��Y�?

RomKK 2007-07-24 22:22 发表评论

微��Y好员工的十个标准

RomKK — Tue, 24 Jul 2007 14:21:00 GMT

1、对自己所在公司或部门的��品具有�v码的好奇心是极�ؓ重要的一炏V��你必须亲自使用该��品。对于��n处计��机行业的�h来说,�q�一�Ҏ��么��都不��。当�Ӟ��q�一点同样适用于其他知识密集型领域�Q�因为在�q�些领域内技术与应用发展更新极快�Q�对其技术的掌握很难做到一��x��逸。如果你对这些��品没什么兴��，你将很快落伍�Q��ƈ被淘汰出局�?br>
2、在与客户交谈如何��用��品时�Q�需要以极大的兴��和传道士般的热情和执着打动客户�Q�了解他们欣赏什么，不喜�Ƣ什么。同时必��L��醒地知道本公司的产品有哪些不��I��或哪里可以改�q��?br>
3、了解了客户的需求后�Q�必��M��于思考如何让产品更脓�q��ƈ帮助客户�?br>
4、作��Z��个独立的员工�Q�必��M��公司制定的长期计划保持步调一致。员工需要关注其�l��n的努力方向，如提高自�w�及同事的能力�?br>
5、在对于周遭事物��h��高度�z�察力的同时�Q�必��L��握某�U�专业知识和技能。特别是一些大公司�Q�他们要求员工迅速掌握专业技术。没有�h能保证他目前拥有的技能仍适用于将来的工作�Q�所以，好学�_��是非常关键的�?br>
6、非常灵�z�d��利用那些有利于发展的��Z��。在微��Y�Q�我们通过一�p�d��Ҏ��为每一个�h提供许多不同的工作机会。�Q何热衷参与微软管理的员工�Q�都��被鼓励在不同客��h��务部门工作�?br>
7、一个好的员工会��量��d��习了解公�怸�务运作的�l�济原理�Q��ؓ什么公司的业务会这栯��作？公司的业务模式是什么？如何才能盈利�Q�员工必��M��解导致本行业中企业盈利或亏损的原因，才能对自己所从事的工作的价值有更深入的理解�?br>
8、关注竞争对手的动态。我非常�ƣ赏那些随时注意整个市场动态的员工�Q�他们会分析我们的竞争对手的可借鉴之处�Q��ƈ注意�ȝ��Q�避免重�q�竞争对手的错误�?br>
9、好的员工善于动脑子。分析问题，但�ƈ不局限于分析。他们知道如何寻找潜在的�q��点，如何��L��最佳的行动时机。思考还要与实践相结合。好的员工会合理、高效地利用旉��Q��ƈ会�ؓ其他部门清楚地提出徏议�?br>
10、不要忽略了一些必��d��备的��d�Q�如诚实、有道�d和刻苦，�q�些都是很重要的�Q�在此无需赘言�?/strong>

RomKK 2007-07-24 22:21 发表评论

RomKK — Tue, 24 Jul 2007 01:54:00 GMT

新免覆盖注册
更新说明�Q�不使用覆盖安装法，直接输入注册码即可�?br>
下面�?5.5 GA 版本�?#8220;注册信息”“注册�?#8221;“破解”�l�大�Ӟ��
Subscriber: www.1cn.biz
Subscriber Code: jLR7ZL-655355-5450755330522962

旉��:20090520

RomKK 2007-07-24 09:54 发表评论

�?/td>	�?/td>	耗用旉��Q�秒�Q?/td>
RandomAccessFile	RandomAccessFile	95.848
BufferedInputStream + DataInputStream	BufferedOutputStream + DataOutputStream	2.935