2008年5月31日
#
1. Remote
Method Invocation (RMI)
2. Hessian
3. Burlap
4. HTTP invoker
5. EJB
6. JAX-RPC
7. JMX
zz from http://marakana.com/forums/tomcat/general/106.html
Valve and Filter:
"Valve" is Tomcat
specific notion, and they get applied at a higher level than anything in a specific webapp. Also, they work only in Tomcat.
"Filter" is a Servlet Specification notion and should work in any compliant servlet container. They get applied at a lower level than all of Tomcat's
Valves.
However, consider also the division between your application and the application
server. Think whether the feature you're planning is part of your application, or is it rather a generic feature of the application server, which could have uses in other applications as well. This would be the correct criteria to decide between Valve and Filter.
Order for filter: The order in which they are
defined matters. The container will execute the filters in the order
in which they are defined.
Use one single table "blank_fields" for both A and B. "blank_fields" has fields: 'ref_id', 'blank_field', 'type'. 'type' is used to identify which entity the record belongs to. Use 'type' + 'ref_id' to specify the collection of elements for one entity.
@Entity
@Table(name = "table_a")
public class A {
private Set<BlankField> blankFields = new HashSet<BlankField>();
@CollectionOfElements
@Fetch(FetchMode.SUBSELECT)
@Enumerated(EnumType.ORDINAL)
@JoinTable(name = "blank_fields", joinColumns = { @JoinColumn(name = "ref_id") })
@Cascade(value = org.hibernate.annotations.CascadeType.DELETE_ORPHAN)
@Column(name = "blank_field", nullable = false)
@SQLInsert(sql = "INSERT INTO blank_fields(ref_id, blank_field, type) VALUES(?,?,0)")
@Where(clause = "type=0")
public Set<BlankField> getBlankFields() { // BlankField is an enum
return blankFields;
}
@SuppressWarnings("unused")
private void setBlankFields(Set<BlankField> blankFields) {
this.blankFields = blankFields;
}
} // End B
@Entity
@Table(name = "table_b")
public class B {
private Set<BlankField> blankFields = new HashSet<BlankField>();
@CollectionOfElements
@Fetch(FetchMode.SUBSELECT)
@Enumerated(EnumType.ORDINAL)
@JoinTable(name = "blank_fields", joinColumns = { @JoinColumn(name = "ref_id") })
@Cascade(value = org.hibernate.annotations.CascadeType.DELETE_ORPHAN)
@Column(name = "blank_field", nullable = false)
@SQLInsert(sql = "INSERT INTO blank_fields(ref_id, blank_field, type) VALUES(?,?,1)") // used for insert
@Where(clause = "type=1") // used for query, if not @CollectionOfElements, such as @OneToMany, use @WhereJoinTable instead
public Set<BlankField> getBlankFields() {
return blankFields;
}
@SuppressWarnings("unused")
private void setBlankFields(Set<BlankField> blankFields) {
this.blankFields = blankFields;
}
}
當(dāng)然還有其他的方式來(lái)實(shí)現(xiàn)上面的需求，上面采用的單表來(lái)記錄不同實(shí)體的associations（這兒是CollectionOfElements，并且返回的是Set<Enum>，不是Set<Embeddable>)，然后用'type'來(lái)區(qū)分不同的實(shí)體，這樣做的好處是：數(shù)據(jù)庫(kù)冗余少，易于擴(kuò)展，對(duì)于新的實(shí)體，只需加一個(gè)type值，而不需更改數(shù)據(jù)庫(kù)表結(jié)構(gòu)。另外一種采用單表的方式是為每個(gè)實(shí)體增加新的字段，如"blank_fields": 'a_id', 'b_id', 'blank_field', a_id reference table_a (id), b_id reference table_b (id). 這樣在映射的時(shí)候更簡(jiǎn)單，
對(duì)于A，映射為
@JoinTable(name = "blank_fields", joinColumns = { @JoinColumn(name = "a_id") })
對(duì)于B，映射為
@JoinTable(name = "blank_fields", joinColumns = { @JoinColumn(name = "b_id") })
這樣作的缺點(diǎn)是：帶來(lái)了數(shù)據(jù)庫(kù)冗余，對(duì)于blank_fields來(lái)講，任一條記錄，a_id和b_id中只有一個(gè)不為null。當(dāng)多個(gè)實(shí)體共用這個(gè)表時(shí)，用上面的方法更合理，如果共用實(shí)體不多時(shí)，這種方法更方便。
The case to use One Hibernate Session Multiple Transactions:
each transaction would NOT affect others.
i.e., open multiple transactions on the same session, even though one transaction rolls back, other transactions can be committed. If one action fails, others should fail too, then we should use one transaction for all actions.
Note:
A rollback with a single Session will lead to that Session being cleared (through "Session.clear()").
So do lazy collections still work if the session is cleared? =>Not of any objects that you loaded up until the rollback. Only for new objects loaded afterwards.
We should load necessary objects to session for each transactional action to avoid LazyInitializationException, even if those objects are loaded before other forward transactional actions, since forward action may be rolled back and clear the session.
BTW, Hibernate Session.merge() is different with Session.update() by:
Item item2 = session.merge(item);
item2 == item; // false, item - DETACHED, item2 - PERSIST
session.update(item); // no return value, make item PERSIST
發(fā)生這種異常的case:
@Transactional
public void foo() {
try{
bar();
} catch (RuntimeException re) {
// caught but not throw further
}
}
@Transactional
public void bar() {
}
如果foo在調(diào)用bar的時(shí)候，bar拋出RuntimeException，Spring在bar return時(shí)將Transactional標(biāo)記為Rollback only， 而foo捕獲了bar的RuntimeException，所以Spring將會(huì)commit foo的事務(wù)，但是foo和bar使用的是同一事務(wù)，因此在commit foo事務(wù)時(shí)，將會(huì)拋出UnexpectedRollbackException。注意：如果foo和bar在同一class中，不會(huì)出現(xiàn)這種情況，因?yàn)椋?br />
Since this mechanism is based on proxies, only 'external' method calls coming in through the proxy will be intercepted. This means that 'self-invocation', i.e. a method within the target object calling some other method of the target object, won't lead to an actual transaction at runtime even if the invoked method is marked with @Transactional!
可以通過(guò)配置log4j來(lái)debug Spring事務(wù)獲取情況：
To delve more into it I would turn up your log4j logging to debug and also look at what ExerciseModuleController is doing at line 91, e.g.: add a logger for org.springframework.transaction
這周被Quartz折騰了一番。
我們知道，Quartz采用JobDataMap實(shí)現(xiàn)向Job實(shí)例傳送配置屬性，正如Quartz官方文檔說(shuō)的那樣：
How can I provide properties/configuration for a Job instance? The key is the JobDataMap, which is part of the JobDetail object.
The JobDataMap can be used to hold any number of (serializable) objects
which you wish to have made available to the job instance when it
executes.
JobDataMap map ＝ context.getJobDetail().getJobDataMap();
我們通過(guò)map向Job實(shí)例傳送多個(gè)objects，其中有一個(gè)是個(gè)bean，一個(gè)是基本類型。對(duì)于scheduled triggers，我們要求bean對(duì)于所有的序列都不變，包括其屬性，而基本類型可以在Job運(yùn)行過(guò)程中改變，并影響下一個(gè)序列。實(shí)際情況是，對(duì)于下個(gè)序列，bean的屬性被上次的修改了，而基本類型卻維持第一次put到Map里面的值。正好和我們要求的相反。
受bean的影響，以為map里面包含的都是更新的對(duì)象，即每個(gè)序列里面的JobDetail是同一個(gè)對(duì)象，但是基本類型的結(jié)果否認(rèn)了這一點(diǎn)。回頭重新翻閱了下Quartz的文檔：
Now, some additional notes about a job's state data (aka JobDataMap): A
Job instance can be defined as "stateful" or "non-stateful".
Non-stateful jobs only have their JobDataMap stored at the time they
are added to the scheduler. This means that any changes made to the
contents of the job data map during execution of the job will be lost,
and will not seen by the job the next time it executes.
Job有兩個(gè)子接口：StatefulJob and InterruptableJob，我們繼承的是InterruptableJob，或許Quartz應(yīng)該有個(gè)InterruptableStatefulJob。另外StatefulJob不支持并發(fā)執(zhí)行，和我們的需求不匹配，我們有自己的同步控制，Job必須可以并發(fā)運(yùn)行。
然后查看了Quartz的相關(guān)源碼：
// RAMJobStore.storeJob
public void storeJob(SchedulingContext ctxt, JobDetail newJob,
boolean replaceExisting) throws ObjectAlreadyExistsException {
JobWrapper jw = new JobWrapper((JobDetail)newJob.clone()); // clone a new one
.
jobsByFQN.put(jw.key, jw);
}
也就是說(shuō)，store里面放的是初始JobDetail的克隆，在序列運(yùn)行完時(shí)，只有StatefulJob才會(huì)更新store里面的JobDetail：
// RAMJobStore.triggeredJobComplete
public void triggeredJobComplete(SchedulingContext ctxt, Trigger trigger,
JobDetail jobDetail, int triggerInstCode) {
JobWrapper jw = (JobWrapper) jobsByFQN.get(jobKey);
if (jw != null) {
JobDetail jd = jw.jobDetail;
if (jd.isStateful()) {
JobDataMap newData = jobDetail.getJobDataMap();
if (newData != null) {
newData = (JobDataMap)newData.clone();
newData.clearDirtyFlag();
}
jd.setJobDataMap(newData); // set to new one
}
}
然后，每次序列運(yùn)行時(shí)所用的JobDetail，是存放在Store里面的克隆。
// RAMJobStore.retrieveJob
public JobDetail retrieveJob(SchedulingContext ctxt, String jobName,
String groupName) {
JobWrapper jw = (JobWrapper) jobsByFQN.get(JobWrapper.getJobNameKey(
jobName, groupName));
return (jw != null) ? (JobDetail)jw.jobDetail.clone() : null; // clone a new
}
問(wèn)題很清楚了，存放在Store里面的JobDetail是初始對(duì)象的克隆，然后每個(gè)序列所用的JobDetail， 是Store里面的克隆，只有Stateful job，Store里面的JobDetail才更新。
最有Quartz里面使用的clone():
// Shallow copy the jobDataMap. Note that this means that if a user
// modifies a value object in this map from the cloned Trigger
// they will also be modifying this Trigger.
if (jobDataMap != null) {
copy.jobDataMap = (JobDataMap)jobDataMap.clone();
}
所以對(duì)于前面所講的，修改bean的屬性，會(huì)影響所有clone的對(duì)象，因此，我們可以將基本類型封裝到一個(gè)bean里面，map里面存放的是bean，然后通過(guò)修改bean的屬性，來(lái)達(dá)到影響下一個(gè)序列的目的。
From:
Web application design: the REST of the story
Key points:
- HTTP is a very general, scalable protocol. While most people only
think of HTTP as including the GET and POST methods used by typical
interactive browsers, HTTP actually defines several other methods that
can be used to manipulate resources in a properly designed application
(PUT and DELETE, for instance). The HTTP methods provide the verbs in a web interaction.
- Servers are completely stateless. Everything necessary to service a request is included by the client in the request.
- All application resources are described by unique URIs. Performing
a GET on a given URI returns a representation of that resource's state
(typically an HTML page, but possibly something else like XML). The
state of a resource is changed by performing a POST or PUT to the
resource URI. Thus, URIs name the nouns in a web interaction.
剛剛看CCTV實(shí)話實(shí)說(shuō)，很有感觸，義烏技術(shù)職業(yè)學(xué)院給人眼前一亮，尤其是他們副院長(zhǎng)的一番言論。
技術(shù)職業(yè)學(xué)院非得要升本科，本科非要成清華，義烏職業(yè)技術(shù)學(xué)院副院長(zhǎng)評(píng)價(jià)當(dāng)前高校的現(xiàn)狀，定位嚴(yán)重有問(wèn)題，技術(shù)職業(yè)學(xué)院應(yīng)該培養(yǎng)應(yīng)用型人才，而清華就應(yīng)該培養(yǎng)研究性人才，兩種學(xué)校的定位不能一樣，培養(yǎng)方式，評(píng)判標(biāo)準(zhǔn)都應(yīng)該不同，而現(xiàn)在大多數(shù)高校的定位都一樣，這是不對(duì)的。個(gè)人非常贊同這個(gè)觀點(diǎn)，其實(shí)，這個(gè)觀點(diǎn)也可以應(yīng)用到我們這些剛開(kāi)始工作的年輕人身上，消除浮躁，找準(zhǔn)定位，然后沿著定位踏實(shí)做事，并且應(yīng)該采取相應(yīng)的評(píng)判標(biāo)準(zhǔn)，這個(gè)很重要。
1. RFC documents
2. SCEP operations
-
PKIOperation:
-
Certificate Enrollment - request: PKCSReq, response: PENDING, FAILURE, SUCCESS
-
Poll for Requester Initial Certificate - request: GetCertInitial, response: same as for PKCSReq
-
Certificate Access - request: GetCert, response: SUCCESS, FAILURE
-
CRL Access - request: GetCRL, response: raw DER encoded CRL
- Non-PKIOperation: clear HTTP Get
-
Get Certificate Authority Certificate - GetCACert, GetNextCACert, GetCACaps
-
Get Certificate Authority Certificate Chain - GetCACertChain
3. Request message formats for PKIOperation
- Common fields in all PKIOperation messages:
-
senderNonce
-
transactionID
- the SCEP message being transported(SCEP messages) -> encrypted using the public key of the recipient(Enveloped-data)
-> signed by one of certificates(Signed-data): the requester can generate a self-signed certificate, or the requester can use
a previously issued certificate, if the RA/CA supports the RENEWAL option.
- SCEP messages:
-
PKCSReq: PKCS#10
- GetCertInitial: messages for old versions of scep clients such as Sscep, AutoSscep, and Openscep, are different with draft-18
issuerAndSubject ::= SEQUENCE {
issuer Name,
subject Name
}
-
GetCert: an ASN.1 IssuerAndSerialNumber type, as specified in PKCS#7 Section 6.7
-
GetCRL: an ASN.1 IssuerAndSerialNumber type, as defined in PKCS#7 Section 6.7
--zz: http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1230261484567+28353475&threadId=1213960
Question:
We are planning to calculate the percentage of physical memory utilised as below:
System Page Size: 4Kbytes
Memory: 5343128K (1562428K) real, 13632356K (3504760K) virtual, 66088K free Page# 1/604
Now the formula goes as below:
(free memory / actual active real memory) * 100
(66088/1562428) * 100 = 4.22 %
Please let us know if its the correct formula .
Mainly we are interested in RAM percentage utilised
Reply 1:
Red Hat/Centos v 5 take spare ram and use it for a buffer cache.
100%
memory allocation is pretty meaningless because allocation is almost
always near 100%. The 2.6.x kernel permits rapid re-allocation of
buffer to other purposes eliminating a performance penalty that you see
on an OS like HP-UX
I'm not thrilled with your formula because
it includes swap(virtual memory). If you start digging too deep into
virtual memory, your system start paging processes from memory to disk
and back again and slows down badly.
The formula is however essentially correct.
Reply 2:
Here, a quick example from the machine under my desk:
Mem: 3849216k total, 3648280k used, 200936k free, 210960k buffers
Swap: 4194296k total, 64k used, 4194232k free, 2986460k cached
If
the value of 'Swap used' is up (i.e. hundreds of megabytes), then
you've got an issue, but as you can see, it's only 64k here.
Your formula for how much memory is used is something along the lines of this:
(Used - (Buffers + Cached) / Total) * 100 = Used-by-programs%
(Free + Buffers + Cached / Total) * 100 = Free%
.. Roughly ..
昨天遇到個(gè)非常奇怪的bug：更新了一下后臺(tái)的代碼，結(jié)果每次點(diǎn)擊頁(yè)面都會(huì)導(dǎo)致servlet方法調(diào)用兩次，從而頁(yè)面報(bào)錯(cuò)（邏輯上不讓調(diào)兩次 ），我們的前臺(tái)采用gwt，servlet engine采用tomcat，debug的時(shí)候，斷點(diǎn)放在servlet所調(diào)用的method上，結(jié)果invoke兩次，由此斷定，前臺(tái)代碼的問(wèn)題（有點(diǎn)武斷哦
），然后負(fù)責(zé)前臺(tái)的同事debugging前臺(tái)的代碼，噼里啪啦半天。。。，說(shuō)是前臺(tái)好像沒(méi)有調(diào)兩次（之所以用好像，是debugging時(shí)部分代碼走兩次，部分走一次），而我當(dāng)時(shí)的想法是，后臺(tái)怎么操作，也不至于讓servlet調(diào)用兩次吧，所以我個(gè)人就認(rèn)定是前臺(tái)邏輯導(dǎo)致重復(fù)rpc調(diào)用（gwt），但是這個(gè)bug在這兩天才出現(xiàn)的，從svn的歷史記錄來(lái)看，前臺(tái)代碼在這兩天基本沒(méi)什么改變，同事只好從svn上一個(gè)version接一個(gè)version的check，最后確定出兩個(gè)相鄰的versions，前一個(gè)能用，后一個(gè)出bug，這時(shí)我隱約感覺(jué)到是后臺(tái)的問(wèn)題，但是還是想不明白，后臺(tái)的邏輯怎么就能讓前臺(tái)重復(fù)調(diào)用，非常不解，沒(méi)辦法，在同事的建議下，在servlet的那個(gè)method上加上一條debug信息，做了兩次試驗(yàn)，一次是完整的代碼，一次是把method中調(diào)用后臺(tái)的接口注釋掉，結(jié)果從日志上看出，前一次試驗(yàn)debug信息打印了兩次，后一次試驗(yàn)debug只打印了一次，此時(shí)，確定是后臺(tái)邏輯影響了前臺(tái)的調(diào)用（此時(shí)，覺(jué)得走彎路了，為什么不早點(diǎn)做這個(gè)試驗(yàn)，其實(shí)確定是前臺(tái)還是后臺(tái)的問(wèn)題，只需要做這樣一個(gè)簡(jiǎn)單的試驗(yàn)。。。）。接下來(lái)，我思考的就是到底是什么在作怪呢，對(duì)比svn上的兩個(gè)版本，只有兩處可能的改動(dòng)，一處是將return改成throw exception, 一處是調(diào)用了Thread.currentThread.interrupt()，我一個(gè)感覺(jué)是后者，注掉這句后，一切OK，呵呵，慶幸沒(méi)有先嘗試前者，要不改動(dòng)很大，。。。
剛剛看了gwt的源碼，還沒(méi)找到問(wèn)題的根源，我的觀點(diǎn)是，thread接收到interrupt信號(hào)時(shí)，會(huì)重復(fù)發(fā)送rpc調(diào)用，（呵呵，還沒(méi)確定）。。。
最近心情不是很好，上周三，父親的一次意外，給家里本來(lái)平靜的生活帶來(lái)了很大的波瀾，我也第一次感受到來(lái)自于家庭的壓力，由此帶來(lái)的一系列問(wèn)題，一直縈繞著我，責(zé)任，responsibility，是這幾天我告誡自己最多的一個(gè)詞，是啊，該到了承受家庭責(zé)任的時(shí)候了。
父親的這次意外，揪住了全家人的心，我也更多的為兩位老人思考了，這兩天，老想起一句話：人只有經(jīng)歷的多了，才能成熟。我很喜歡類比，其實(shí)就跟我們做數(shù)學(xué)題一樣，看的多了，做的多了，考試的時(shí)候才能迎刃而解，什么東西，或許只有自己親身經(jīng)歷，才能體會(huì)其中的更多細(xì)節(jié)，才能激發(fā)更多的收獲。
祝福父親的身體早日康復(fù)，bless。。。
最近，時(shí)不時(shí)地回想自己這一路的教育經(jīng)歷，使得我越來(lái)越相信——命運(yùn)！
總體來(lái)說(shuō)，我自認(rèn)為我這一路上走的太順利，缺少更多的經(jīng)歷，缺少一些該有的挫折！
但是，順利歸順利，在兩次作抉擇的時(shí)候，隨機(jī)的選擇決定現(xiàn)在的方向！一次當(dāng)然是過(guò)獨(dú)木橋——高考，另一次是碩士入學(xué)時(shí)選擇導(dǎo)師！兩次選擇都很隨意，甚至于無(wú)意，尤其是第二次。第一次的隨意更多的是無(wú)知，而第二次的無(wú)意，卻源于自己的不適應(yīng)。隨意帶來(lái)了大學(xué)時(shí)代的混亂，無(wú)意卻給自己帶來(lái)了意外的收獲，人生無(wú)常，命運(yùn)有數(shù)。
高考時(shí)，分?jǐn)?shù)超出了自己的預(yù)料，志愿填的有些草率，一方面，是因?yàn)樽约旱哪贻p和無(wú)知，另一方面是由于周圍缺少必要的指點(diǎn)，填的很倉(cāng)促，很隨意，非常的“高效”。正值00年高校擴(kuò)招猖獗之時(shí)，我所填報(bào)的學(xué)校就是由三個(gè)學(xué)校合并而成，并且是在高考的前兩個(gè)月宣布合并的，其中有兩個(gè)合并之前不是一本，但是合并之后，肯定都是一本了。我當(dāng)時(shí)選報(bào)了自動(dòng)化這個(gè)專業(yè)，當(dāng)時(shí)填的時(shí)候就因?yàn)楦咧邪嘀魅握f(shuō)了一聲：“現(xiàn)在自動(dòng)化是一個(gè)很好的方向。”然而，此時(shí)命運(yùn)開(kāi)始現(xiàn)數(shù)，其中有兩個(gè)學(xué)校都有自動(dòng)化這個(gè)專業(yè)，一個(gè)之前就是一本（合并后，稱之為‘校本部’，不知道這個(gè)是什么意思，或許我要去查查字典，好好揣測(cè)一下本部的含義。），另一個(gè)是三個(gè)學(xué)校中最差的一個(gè)，報(bào)道那天才知道有兩個(gè)自動(dòng)化，但是由于剛合校，還沒(méi)來(lái)得及合并專業(yè)，當(dāng)時(shí)就想，我該在哪個(gè)校區(qū)的自動(dòng)化呢？最后隨著師長(zhǎng)的指引，我被校車?yán)搅朔中^(qū)，也就是那個(gè)最差的了，一路上，還在思索兩個(gè)自動(dòng)化的分配算法，還是直到開(kāi)學(xué)一個(gè)月以后，一次偶然的機(jī)會(huì)，才得知：兩個(gè)自動(dòng)化是根據(jù)當(dāng)時(shí)各省分?jǐn)?shù)的交替順序分配，安徽省生源的第一名在本部，第二名在分校區(qū)，第三名本部，第四名分校區(qū)。。。。只能怪自己被動(dòng)的排在了一個(gè)偶數(shù)的序位上，如果用一個(gè)函數(shù)來(lái)表示這個(gè)序位的話，其自變量的個(gè)數(shù)還是蠻多的，當(dāng)年安徽省報(bào)考該校該專業(yè)的人生，你在這些人中的名次，另外還有，我還不太確定的因素，但是我能確定因素的存在。。。
后來(lái)，進(jìn)一步得知，分校區(qū)的自動(dòng)化之前沒(méi)有，我們是第一屆，當(dāng)時(shí)在合校之前就已經(jīng)確定要新增這個(gè)專業(yè)，合的時(shí)候，各個(gè)學(xué)校的招生計(jì)劃都沒(méi)變，只是將三個(gè)計(jì)劃簡(jiǎn)單的數(shù)學(xué)累加，現(xiàn)在看來(lái)，合校是多么的可笑，一個(gè)學(xué)校從任意層次可以一下成為中國(guó)最好的學(xué)校，只要清華愿意合并它，而合并后再很長(zhǎng)一段時(shí)間，那個(gè)學(xué)校除了學(xué)生的層次提高之外，沒(méi)有任何的改變，教師還是那些教師，設(shè)施還是那些設(shè)施，思想還是那些思想，我不知道這可不可以稱之為赤裸裸的搶劫，它無(wú)視了那些默默地而踏踏實(shí)實(shí)前進(jìn)的高校，助長(zhǎng)了一些不公正的風(fēng)氣，或許正應(yīng)了中國(guó)當(dāng)時(shí)浮躁的社會(huì)氛圍。
就這樣在這度過(guò)了自己的三年大學(xué)時(shí)光，就在最后一個(gè)大學(xué)暑假之前，學(xué)校經(jīng)過(guò)三年的發(fā)展和磨合，決定將我們這個(gè)專業(yè)撤銷，統(tǒng)一合并到本部去，我們被迫搬回了第一天報(bào)道的地方，其實(shí)兩個(gè)自動(dòng)化的方向是不一樣的，或許我們要慶幸，我們學(xué)習(xí)了兩個(gè)專業(yè)，在大學(xué)的四年中，但是或許，更多的人可能會(huì)埋怨兩個(gè)方向影響了自己的學(xué)習(xí)，其實(shí)，我想，大多數(shù)的人根本不在于什么方向，什么專業(yè)了，一個(gè)大框架的混亂，注定了最終的結(jié)果，就像當(dāng)前的中國(guó)足球。。。
我要說(shuō)的是，其實(shí)我在大學(xué)中過(guò)得很愉快，我認(rèn)識(shí)了一批很好的同學(xué)，我經(jīng)歷了到目前為止最好的一段時(shí)光，雖然期間有很多遺憾，比如沒(méi)談一次戀愛(ài)。。。我想這段時(shí)光勢(shì)必會(huì)在我的記憶集合中占據(jù)非常重要的一塊。這里，我只不過(guò)是要論述命運(yùn)有數(shù)，這樣的一個(gè)過(guò)程多少還是影響了我的人生軌跡。
下面要談?wù)撐业牡诙尉駬瘢T士時(shí)選擇導(dǎo)師。大學(xué)畢業(yè)時(shí)，我選擇了繼續(xù)就讀，一切都很順利，到了04年9月，我來(lái)到了新的學(xué)校，在合肥，這兒離家很近，因?yàn)槲沂前不杖耍?jīng)歷了大學(xué)時(shí)回家的艱辛，再加上我又是個(gè)比較戀家的人。剛?cè)胄＃陀龅搅艘粋€(gè)。。。。
明天繼續(xù)。。。。
1.
多行注釋:
ctrl+v 進(jìn)入列模式,向下或向上移動(dòng)光標(biāo),把需要注釋的行的開(kāi)頭標(biāo)記起來(lái),然后按大寫的I,再插入注釋符,比如#,再按esc,就會(huì)全部注釋了.