发表于 | 分类于 |

XML库方面，我知道的有expat、libxml2、tinyxml和minixml。


听说expat应用很广，但我没有用过……libxml2这个东东给我的印象是拥肿。


我今天推荐后两者，一个是基于C++编写的tinyxml库，另一个是基于C编写的minixml库。


我自己最常用的是tinyxml，此库用C++进行封象，适度的面向对象，命名很人性化，是一个很不错的选择。但这个库的Makefile没有带编译为动态库的方法，要编译为动态库，只要把Makefile相关行改为：

DEBUG := NO

TINYXML_USE_STL := NO # 个人认为没必要加入STL的支持

RELEASE_CFLAGS := -Wall -Wno-unknown-pragmas -Wno-format -O3 -fPIC

LIBS := -shared -s

OUTPUT := libtinyxml.so

SRCS行去掉xmltest.cpp

然后保存，make即可生成libtinyxml.so，以后只要include自带那两个h头文件即可使用tinyxml库了


另一个推荐的是minixml库，这个库的出现是因为很多时候没必要用libxml2这个拥肿的东西（听说有10万行, minixml才三千多行）。

这个库我暂时还没用过，有时间会试用一下。这个为自带configure，配置、编译都非常方便，而且是纯C的，所以对各种应该都比较合适，CUPS就是使用minixml库的。


两个库都是很轻量级的，tinyxml编译成动态库后不到78K（O3优化），minixml为44K（Os优化），而且都可以用于windows，因为都自带VC工程文件，可以选择合自己口味的，have fun~

发表于 | 分类于 |

PHP5.3昨天发布，同时带来了新特性，当然也有向后不兼容。在新特性里，说得比较多的是namespaces, 静态绑定, goto的支持和闭包，有兴趣可以关注一下。

发表于 | 分类于 |

最近几乎失去自由似的忙乎忙乎……前几天调一个vector问题竟然花去我一天多时间，才发现push_back进去的是一个对象，而不是指针~！·#￥%……——*（）


忙乎忙乎，几乎都不想去写文字，就连前天Bird和阿SA过来，都加班到九点才见到他们，相聚时间虽短，但对于我来说，已经足够了，下次补回来，同时也表扬一下soondo先。


忙乎忙乎，昨晚开始玩《原型体》(Prototype)，有点血腥，但画面很漂亮，操作畅快，自从鬼泣4后，都没玩到这么强打击感的大作了，推荐大家试试这个作品。另外也推荐一下Virtua Tennis 2009，三代我玩过，感觉很好。

发表于 | 分类于 |

via: http://cocre.com/?p=1081


之前本站发表过《优秀程序员的十个习惯》以及《程序员需要具备的基本技能》，那是我们需要去学习和培养的。这里，我们主要讨论十个糟糕程序员的特征，主要是需要让我们去避免和小心的。


1) 情绪化的思维


如果你开始使用不同颜色的眼光来看待这个世界的话，那么你可能会成为一个很糟糕的程序员。情绪化的思维或态度很有可能会把自己变成一个怪物。相信你经常可以看到很多很糟糕的程序会使用下面的这些语句：



  • 我的程序不可能有这种问题。

  • Java就是shit。

  • 我最恨的就是使用UML做设计。

  • 需求怎么老在变，没办干了。

  • 受不了这些人，他们到底懂不懂啊。

  • …… ……


这些带着情绪化的思维和态度，不但可以让你成为一个很糟糕的程序员，甚至可以影响你的前途。因为，情绪化通常都是魔鬼，会让你做出错误的判断和决定，错误码率的判断和决定直接决定了你的人生。


 


2) 怀疑别人


糟糕的程序总是说：“我的代码一定是正确的，我怀疑编译器有问题”，“我这应该没有问题吧，STL库怎么这么难用啊”。我曾经见过有程序员这样使用 STL类：map<char, char>，当他发现这样放入字符串后却取不出来，觉得那是STL库的BUG，然后自己写了一个map！我的天啊！


某些时候，过早的下结论是一个很不好的习惯，任何事情都有其原因，只有知道了原因，你才能知道是谁的问题。一般来说，总是自己出的问题。


3) 过多关注实现，陷入问题细节


有些时候，当我们面对一个问题或是一个需求的时候，糟糕的程序员总是会马上去找一个解决方案或是实现，这是一个很不好的习惯。设计模式告诉我们，“喜欢接口，而不是实现”就是告诉我们，认清问题的本质和特性要比如何实现更重要。



  • 对于一个客户的问题来说，首先应该想到的是如何先让用户正常工作，如何恢复正在“流血”的系统，而不是把用户放在一边而去分析问题的原因和解决方案。

  • 对于解决一个bug来说，重现bug，了解原来程序的意图是首先重要的事，而不是马上去修改代码，否则必然会引入更多的BUG。

  • 对于一个需求来说，我们需要了解的需求后面的商业背景，use case和真实意图，而不是去讨论如何实现。只有了解了用户的真实意图，实际使用的方式和案例，你才能真正如果去做设计。


糟糕的程序总是容易陷入细节，争论于如何实现和实现难题，以及问题的根本原因，而忽略了比这些更重要的东西。只有看懂了整个地图，我们才知道要怎么去走。


4) 使用并不熟悉的代码


糟糕的程序员最好的朋友是 Ctrl-C 和 Ctrl-V ，有些时候，他们并不知道代码的确切含义，就开始使用它，有证据表明，由拷贝粘贴引发的bug占了绝大多数。因为，代码总是只能在特定的环境下才能正常地 工作，如果代码的上下文改变了，很有可能使得代码产生很多你不知道的行为，当你连代码都控制不住了，你还能编出什么好的程序呢？


5) 拼命工作而不是聪明的工作


对于糟糕的程序员，我们总是能看到他们拼命地修正他们的bug，总是花非常多时间并重复地完成某一工作。而好的程序可能会花双倍的时间来准备一个有 效的开发环境，工具，以及在开发的时候花双倍甚至10倍的时间来避免一些错误。好的程序员总是会利用一切工具或手段来让自己的工作变得更有效率，总是为在 开发的时候尽可能得不出错。后期出错的成本将会是巨大的，而且那时改正错误的压力也是巨大的。所以，糟糕的程序通常会让自己进入一种恶性循环，他们看上去 总是疲惫的，总是很辛苦的，所以更没有时间来改善，越没有时间来改善，就有越多的问题。所以，拼命工作有些时候可能表明你不是一个好的程序员。


6) 总是在等待、找借口以及抱怨


当需求不明确的时候，当环境不是很满意的时候，他们总是在等待别人的改善。出现问题的时候，总是在找借口，或是抱怨这也不好，那也不好，所以自己当 然就没有做好。糟糕的程序员总是希望自己的所处的环境是最好的，有明确的需求，有非常不错的开发环境，有足够的时间，有不错的QA，还有很强的team leader，以及体贴自己的经理，有足够的培训，有良好的讨论，有别人强有力的支持……，这是一种“饭来张口，衣来伸手”的态度，这个世界本来就不完 美，一个团队需要所有人去奋斗，况且，如果什么都变得完美了，那么，你的价值何在吗？driving instead of waiting, leading instead of following.


7) 滋生办公室政治


有句话叫“丑女多作怪”，意思是说如果一个自己没有真实的能力的话，那么他一定会在其它方面作文章。糟糕的程序员也是这样，如果他们程序编不好的 话，比不过别人的话，他们通常会去靠指责别人，推脱责任，或是排挤有能力的人，等等不正常的手段来保全自己。所以，糟糕的程序通常伴随着办公室政治。


8 ) 说得多做得少


糟糕的程序员总是觉得自己什么都懂，他们并不会觉得自己的认识和知识都是有限的。这就是所谓的夸夸其谈，是的，什么都做不好的程序员能靠什么混日子呢？就是吹啊吹啊。


另一个表现方式是他们在评论起别人的程序或是设计，总是能挑出一堆毛病，但自己的程序写得也很烂。总是批评抱怨，而没有任何有建设性的意见，或是提出可行的解决方案。


这些糟糕的程序员，总是喜欢以批评别人的程序而达到显示自己的优秀。


9) 顽固


当你给出一打证据说明那里有一个更好的方案，那里有一个更好的方向的时候，他们总是会倔强的认为他们自己的做法才是最好的。一个我亲身经历的事例就 是，当我看到一个新来的程序员在解决一个问题的时候走到了错误的方向上时，我提醒他，你可能走错了，应该是另外那边，并且我证明了给他看还有一个更为简单 的方法，有。然而，这位程序员却告诉我，“那是我的方法，我一定要把之走下去，不然我会非常难受”，于是，在三天后的代码评审中，在经过顽固地解释以及一 片质疑声中，他不得不采用了我最先告诉他的那个方法。


这些程序员，从来不会去想，也不会去找人讨论还有没有更好的方法，而是坚持自己的想法，那怕是条死路都一往直前，不撞南墙永不回头。


10) 写“聪明”的代码


他们写出来的代码需要别的同事查看程序语言参考手册，或是其程序的逻辑或是风格看上去相当时髦，但却非常难读。代码本应该简洁和易读，而他们喜欢在代码中表现自己，并尝试另类的东西，以显示自己的才气。是的，只有能力有问题的程序员才需要借助这样的显示。


记得以前的一个经历，一位英语很不错的程序员加入公司，本来对我们这些英语二把刀来说，我们喜欢看到的是简单和易读的英文文档，然后，那位老兄为了 展示他的英语如何牛，使用了很多GRE中比较生僻的短语和词汇。让大家阅读得很艰苦。最有讽刺意味的是，有一位native的美国人后来在其邮件中询问他 某个单词的意思。呵呵。


你是一个糟糕的程序员吗？欢迎你分享你的经历。


（全文完）

发表于 | 分类于 |


6月5日，华师舞蹈专场Vol.2，我回去了。

那天晚上的专场很精彩、很热闹，我很开心。这段时间大家也辛苦了，一边顶着考试的压力，一边准备一件件琐碎的事情，感谢每一个为专场付出过人的:)



曾几何时，我感到自己已经不再属于这个舞台了，而那天晚上，我基本上是作为一个第三者来欣赏这个晚会，心情平静而又激动。

当专场结束了大家吵吵闹闹争着去拍着的时候，

当大家一如既往地清理晚会后场地的时候，

当几个曾经一起奋斗的兄弟一同拍照的时候，

当音乐厅渐渐变得漆黑了，

我知道，又是一场复杂的离别。


而那晚的泪水，就像是一条小河，在我心灵旁边静静地流淌过。其实，这些年来，真的很少有机会像那晚，像B彬，把这么多东西一下子讲出来，让大家去更加懂一个人，让一个人更加懂大家。

对与错都不再重要，因为路只有自己才能去走，对又何妨，错又何妨？


但作为一个真正的朋友、真正的兄弟姐妹，都是想自己人过得好，话放到心理，好好去品味吧。

我没有因为我比你们很多人大一年，就会认为我说的话会比你们对，我说得很随便，如你的工作怎么样了，但事实上我是留有更多的空间给你们，我希望你们更多的是发自内心的负责感，真正勇敢去面对一切

不管是对自己，还是对舞队。就像你不会跳舞，怎么办？有心并付出实际行动，仅此而已。

而B彬说他曾经有过A仔那样的想法，这是让我很意外的事情，我很欣赏。大一的时候，林涛还在的时候，我流过泪。当B彬的出现，改变了整个舞队的格局与地位，而后来的A仔、惠斌的出现，成为了街舞队最重要的转折点之一。我很感谢一路走来的B彬，但一直没有说出来，但我知道你会懂的。


真正的朋友，在一起时可以做到没有话题，而又不会觉得尴尬，而在SCNUCREW，我可以找到这种感觉。

明天的路可能很艰难，只要坚持前进，还是能挺过的。

明天可能离别，只要珍惜这份感情，总能再次相遇。

明天如果你离开了SCNUCREW，请你记得“如果不是舞蹈，我们怎么会认识”，你依然属于我们的SCNUCREW。

感谢你们，曾经为SCNUCREW付出的每一位。

期待下次专场Vol.3。

发表于 | 分类于 |

[tap tap tap]… Is this thing on? ;-)


Ready or not, Slackware has now gone 64-bit with an official x86_64 port being maintained in-sync with the regular x86 -current branch. DVDs will be available for purchase from the Slackware store when Slackware 13.0 is released. Many thanks go out to the Slackware team for their help with this branch and a special thank you to Eric Hameleers who did the real heavy lifting re-compiling everything for this architecture, testing, re-testing, and staying in-sync with -current.


We’ve been developing and testing Slackware64 for quite a while. Most of the team is already using Slackware64 on their personal machines, and things are working well enough that it is time to let the community check our work.


We’d like to thank the unofficial 64 bit projects for taking up the slack for us for so long so that we could take our time getting everything just right. Without those alternatives, we would have been pressured to get things out before they were really ready.


As always – have fun!


Pat and the Slackware crew

0%