html tool

显示标签为“吞文的言论”的博文。显示所有博文
显示标签为“吞文的言论”的博文。显示所有博文

2012年11月5日星期一

life 认知方式


【popexizhi: dankon 吞文,谢谢你总在提醒我那些看不到的人生美丽和自己不稳定心境的来源。】
0.
t said:life 一定会结束的,every day is 单方向的射线,过了就不会重来的。every day应该是接受life 给你的安排,享受每一种心情和体验。而p way plan后发现有一点儿不一样,担心不一样之处how to,甚至开始质疑整个结构。
[popexizhi:t's 从stop点看every day都是收获体会,p's 从目的看everyone多是 非所求的结果,so stop点来吧!达不到目的的life就是煎熬啊!
但是这个目的点可不一定是真的自己所需的,不是吗?! 目的到底如何不是可以轻易弄清楚的.
可以像t的观点享受life的每个安排,应该很别有一番味道吧。但转念想life不能只是被动承受吧?!主动就是p 说的plan吗?
]
1.
p way:plan->try
t way:try->play[?]
t said p's way ?:
1.plan 中的二级结构没有规划好,try doing 就不开始;
2. plan->try 先天对plan 的过程要求过高,很容易就形成焦虑,压力。p 现在的stat 就是最好的一个证明。
[popexizhi: 焦虑的来源:对plan中设计出清晰的细节爱好导致,plan->try 只是认识世界的一种模型,不是这个世界.要学习使用try->plan的方式。
系统论中说的每种way都有其缺点问题,想想way的问题才知道行动的执行边界,对plan->try方式也是没有定义范围过分使用的结果。说eg吧,没有eg就一会儿就不知道说什么了。比如:child担心,大小环境?,觋祉plan也是一个吧。
自己的plan->try没有说到下一个try->plan->try的过程,这个在plan之后的try的plan是对回馈信息的处理基础的修正plan,这个是t way。自己的过程是一个简单的plan->try而没有在try基础上修改plan再次try的循环的过程。如果从循环的角度上说,plan与try谁为开始点都已经显得就那么重要了,因为这个过程本身即修改目标又修正doing。p's way之前缺少的是如何思考plan的修正如何去做,try后思考如何进行新的plan。]
[next]
1.pt way的优点缺点,范围;
2.pt way循环使用how to do,这个过程如何保证是修改plan而不是修改为放弃原目标?
3.这个循环的way:需要这么执着吗:)?这样循环下来会更接近plan->try而不是try->plan吗?


2.
p like way:直线形 start:目标
t hope way:人字形 start:目标
风景不一定不是way的收获
?:how to 在纷繁的风景后记得目标:write [p,t]
[popexizhi:这两种方式执行时,在表面上看来没有太多的不一样,前者不能从不分叉,后者也不可能只在分叉,终于要回到write的内容上。执行性上,没有太多不一样,只是当时的心里上不一致。]
[next]
1.在不同的位置尝试两种方式,体会不同,再次思考

2012年5月21日星期一

吞文关于 CSocket 的抱怨:)---祝他好运吧!

今日欲实现多任务并行(TCP)通信模块,需求功能简单,逻辑明了,性能无虞.
遂采用MFC CSocket现成工具,欲速成之。尚阳光明媚,心情舒畅,只待把弄码行于股掌之上。
俱似快哉。孰知哀哉在后,泪难成行。

一曰 请调皆全
二曰 架筑了然
三曰 发送之功能实现,压力测之OK,继之,接收之功能实现,压力测之亦OK. 
四曰 收发皆用,压力测之,错矣! 

不明?奈何?逻辑诡异也!
试数测之,皆毙。

求MSDN无解,Google求问?得曰
一则 CSocket之对象无跨任务之能用,此则与多任务并行只意悖也。 (叹:莫名)
二则 Microsoft知其弊,则补之有术,奈何且补还漏。 (嗔:弃之)
三则 吾自改之,封装重构,避跨任务之用,砌之完毕。 (吁:可否)
四则 再试之,新漏现也,无消息之通告,作何? (佯:啥子)
五则 再求问,CSoket须依UI任务,Work任务不可,引Wnd:MSG之用作消息通告。休也 (怒:诡者)

全然不知CScket做何之用?
通山之路,吾自开之,不敢求也,去罢去罢。
三思之,若是开源,怎奈如此?
不免感喟,MySQL, Java赖以甲骨之命运若何?


------------------------------------------分割线-----------------------------------------------------------------------------------
【popexizhi:这个是吞文近日对mfc的csock的郁闷处的来源和处理,转到自己的blog中留作备份,不过此内容平心而论,何必和mfc纠结,直接用API就ok了吗!近来听吞文的讲述感觉,当前mfc的封装时,至少在这个问题上可是只为窗口而窗口,没什么多想的,我们两个猜测,当年不是工期太紧迫,就是此位置也是只求大不求精的设计典范。嘻嘻,聊侃而言,自己娱乐使用吧!】