Liu 的个人资料唯有仰望是真实的照片日志列表更多  |  工具 帮助 |
|
2007/3/30 风味绝佳观后感这部电影的名字很奇怪，似乎是片中那盒糖上的字迹"滋养丰富，风味绝佳", 片中的标题当然日文我看不懂，它的注释英文是What Little Girls Are Made of，而网上搜到的别名也叫Sugar&Spice, 是片中Grandma告诉至郎的话。 看到最后，觉得编剧一定是有过同样的经历，一切都是这么的相似，就像6年前的我，至郎一样的年龄，一样飘雪的冬天，一样美丽的女生，一样的白信封，一样的骑着单车疯了般的哭，不一样的仅是我当时撞入的是民主楼前的灌木丛。 可悲的是我现在怎么努力脑子里也没有她清晰的样子了，可悲？可怜？可恨？可耻？... 2007/3/26 quotes from The Cathedral and the Bazaar1. Every good work of software starts by scratching a developer's personal itch. 2. Good programmers know what to write. Great ones know what to rewrite (and reuse). 3. "Plan to throw one away; you will, anyhow." 4. If you have the right attitude, interesting problems will find you. 5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor. 6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. 7. Release early. Release often. And listen to your customers. 8. Given a large enough beta-tester and co-developer base, almost everyproblem will be characterized quickly and the fix obvious to someone. 9. Smart data structures and dumb code works a lot better than the other way around. 10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource. 11. The next best thing to having good ideas is recognizing good ideasfrom your users. Sometimes the latter is better. 12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. 13. "Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away." 14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected. 15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible -- and *never* throw away information unless the recipient forces you to! 16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend. 17. A security system is only as secure as its secret. Beware of pseudo-secrets. 18. To solve an interesting problem, start by finding a problem that is interesting to you. 19. Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one. 昌平盲人岛上没讲完的jokeMarketing Concepts http://raymondzhou.yculblog.com/post.4107611578.html You see a gorgeous girl at a party. You go up to her and before you say 2007/3/23 :P, 被点名了被Bethany点到了, :P, 完全不适合我的问题吗，我是理论实践两个一穷一白，瀑布汗啊......
遊戲介紹：
這是博客裏流行的擊鼓傳花遊戲，傳給誰誰就得接著，否則就會挨罰，請認真對待
，不要怕暴露私隱。 1.被點到名字得要在自己的博客裏寫下自己的答案，然後去掉一個你最不喜欢的问
题再加上一個你的問題（这条规则原为“然後去掉第一個問題再加上一個問題”，够无 聊吧），仍然組成4個問題，傳給其他8個人，列出其他8個需要回答問題的人的名字， 還要到這8個人的博客裏留言通知對方——你被點名了，被點名者不得拒絕回答問題， 完成遊戲的人將會永遠得到大家的祝福。 2.這8個人要在自己的博客裏注明是從哪裏接到的，並且再想一個問題傳給其他8個
人，讓遊戲繼續下去，不得回傳。被點到名字的人將會得到大家的祝福，並且所有美好 的願望都會在不久的將來實現。 ----------------------------------------------------------------------------------------------------------
游戏开始 1.Emily提的问题：相信真正的爱情只有3个月的理论吗？ 真正的爱情是什么啊，谁给个实现算法和测试方法先 2.Qwf的问题是：爱，究竟是不是一种责任呢？亦或只是如很多人所说的，更多的是一 种感觉？？ 感觉是感性的东东，到承担责任就很理性了，很多人说，两人相爱了，是动了感情，两人 分了，是因为理性了, 我觉得蛮有道理。
3.michael的问题：上一次哭是什么时候…为什么…
05年春节，我哥哥结婚，自己当时刚退学，一个人寒假跑到天津去给有钱人家淘气小孩做 家教, 我哥打电话来要我回去，我说我回不去了，当时想到很欠我哥的，就哭了
4.Bethany的问题：相信狂追不舍产生的爱情吗？ 参见我前面一片关于暗恋的，我相信只要努力，就会有回报，但是爱情除外吧...
但是从博弈的角度来分析这个问题，狂追不舍将两个人都逼到了一个很尴尬的地步。
能不能问为什么都是感情问题啊？OK, 不搞笑了，还是沿着主题来提问吧
5.我的问题：爱上你爱的人那一刻是什么样子的呢? (暗恋也算，暗恋也算哦:)
现在开始点名：
cici, color, cryingcat, jingfx, kolafish, litto, totfly, xxmo 真是困难,mmd 还得一个一个通知吗？ 我对不起大家…… 2007/3/21 google /*code search*/ ~~ not that new newsnotice the examples below, hoho..., if you understand all those, congratulations!!!, i think you should get out more to meet some girls:)
Search public source code. Syntax and Examples (more about regexp syntax) regexp "exact string" file:regexp package:regexp lang:regexp license:regexp Google Home - Google Labs - Discuss - Terms of Service - Help John W.Backus, 82, Fortran Developer, Dies(zz for nytimes)machine language to Fortran, Fortran to Functional Programming, notice the pattern, he wanted to be more abstract, more to the problem space, and he cares a lot of code readability... http://www.nytimes.com/2007/03/19/obituaries/20cnd-backus.html March 19, 2007 John W. Backus, 82, Fortran Developer, DiesBy STEVE LOHR John W. Backus, who assembled and led the I.B.M. team that created Fortran, the first widely used programming language, which helped open the door to modern computing, died on Saturday at his home in Ashland, Ore. He was 82. His daughter Karen Backus announced the death, saying the family did not know the cause, other than age. Fortran, released in 1957, was “the turning point” in computer software, much as the microprocessor was a giant step forward in hardware, according to J. A. N. Lee, a leading computer historian. Fortran changed the terms of communication between humans and computers, moving up a level to a language that was more comprehensible by humans. So Fortran, in computing vernacular, is considered the first successful higher-level language. Mr. Backus and his youthful team, then all in their 20s and 30s, devised a programming language that resembled a combination of English shorthand and algebra. Fortran, short for Formula Translator, was very similar to the algebraic formulas that scientists and engineers used in their daily work. With some training, they were no longer dependent on a programming priesthood to translate their science and engineering problems into a language a computer would understand. In an interview several years ago, Ken Thompson, who developed the Unix operating system at Bell Labs in 1969, observed that “95 percent of the people who programmed in the early years would never have done it without Fortran.” He added: “It was a massive step.” Fortran was also extremely efficient, running as fast as programs painstakingly hand-coded by the programming elite, who worked in arcane machine languages. This was a feat considered impossible before Fortran. It was achieved by the masterful design of the Fortran compiler, a program that captures the human intent of a program and recasts it in a way that a computer can process. In the Fortran project, Mr. Backus tackled two fundamental problems in computing — how to make programming easier for humans, and how to structure the underlying code to make that possible. Mr. Backus continued to work on those challenges for much of his career, and he encouraged others as well. “His contribution was immense, and it influenced the work of many, including me,” Frances Allen, a retired research fellow at I.B.M., said yesterday. Mr. Backus was a bit of a maverick even as a teenager. He grew up in an affluent family in Wilmington, Del., the son of a stockbroker. He had a complicated, difficult relationship with his family, and he was a wayward student. In a series of interviews in 2000 and 2001 in San Francisco, where he lived at the time, Mr. Backus recalled that his family had sent him to an exclusive private high school, the Hill School in Pennsylvania. “The delight of that place was all the rules you could break,” he recalled. After flunking out of the University of Virginia, Mr. Backus was drafted in 1943. But his scores on Army aptitude tests were so high that he was dispatched on government-financed programs to three universities, with his studies ranging from engineering to medicine. After the war, Mr. Backus found his footing as a student at Columbia University and pursued an interest in mathematics, receiving his master’s degree in 1950. Shortly before he graduated, Mr. Backus wandered by the I.B.M. headquarters on Madison Avenue in New York, where one of its room-size electronic calculators was on display. When a tour guide inquired, Mr. Backus mentioned that he was a graduate student in math; he was whisked upstairs and asked a series of questions Mr. Backus described as math “brain teasers.” It was an informal oral exam, with no recorded score. He was hired on the spot. As what? “As a programmer,” Mr. Backus replied, shrugging. “That was the way it was done in those days.” Back then, there was no field of computer science, no courses or schools. The first written reference to “software” as a computer term, as something distinct from hardware, did not come until 1958. In 1953, frustrated by his experience of “hand-to-hand combat with the machine,” Mr. Backus was eager to somehow simplify programming. He wrote a brief note to his superior, asking to be allowed to head a research project with that goal. “I figured there had to be a better way,” he said. Mr. Backus got approval and began hiring, one by one, until the team reached 10. It was an eclectic bunch that included a crystallographer, a cryptographer, a chess wizard, an employee on loan from United Aircraft, a researcher from the Massachusetts Institute of Technology and a young woman who joined the project straight out of Vassar College. “They took anyone who seemed to have an aptitude for problem-solving skills — bridge players, chess players, even women,” Lois Haibt, the Vassar graduate, recalled in an interview in 2000. Mr. Backus, colleagues said, managed the research team with a light hand. The hours were long but informal. Snowball fights relieved lengthy days of work in winter. I.B.M. had a system of rigid yearly performance reviews, which Mr. Backus deemed ill-suited for his programmers, so he ignored it. “We were the hackers of those days,” Richard Goldberg, a member of the Fortran team, recalled in an interview in 2000. After Fortran, Mr. Backus developed, with Peter Naur, a Danish computer scientist, a notation for describing the structure of programming languages, much like grammar for natural languages. It became known as Backus-Naur form. Later, Mr. Backus worked for years with a group at I.B.M. in an area called functional programming. The notion, Mr. Backus said, was to develop a system of programming that would focus more on describing the problem a person wanted the computer to solve and less on giving the computer step-by-step instructions. “That field owes a lot to John Backus and his early efforts to promote it,” said Alex Aiken, a former researcher at I.B.M. who is now a professor at Stanford University. In addition to his daughter Karen, of New York, Mr. Backus is survived by another daughter, Paula Backus, of Ashland, Ore.; and a brother, Cecil Backus, of Easton, Md. His second wife, Barbara Stannard, died in 2004. His first marriage, to Marjorie Jamison, ended in divorce. It was Mr. Backus who set the tone for the Fortran team. Yet if the style was informal, the work was intense, a four-year venture with no guarantee of success and many small setbacks along the way. Innovation, Mr. Backus said, was a constant process of trial and error. “You need the willingness to fail all the time,” he said. “You have to generate many ideas and then you have to work very hard only to discover that they don’t work. And you keep doing that over and over until you find one that does work.” Apache MPM event doc这个东东满有趣，贴出来刺激自己好好看看 Status: Module Identifier: Source File: SummaryWarningThis MPM is experimental, so it may or may not work as expected. The To use the How it WorksThis MPM tries to fix the 'keep alive problem' in HTTP. After a client completes the first request, the client can keep the connection open, and send further requests using the same socket. This can save signifigant overhead in creating TCP connections. However, Apache traditionally keeps an entire child process/thread waiting for data from the client, which brings its own disadvantages. To solve this problem, this MPM uses a dedicated thread to handle both the Listening sockets, and all sockets that are in a Keep Alive state. The MPM assumes that the underlying RequirementsThis MPM depends on APR's atomic compare-and-swap operations for thread synchronization. If you are compiling for an x86 target and you don't need to support 386s, or you are compiling for a SPARC and you don't need to run on pre-UltraSPARC chips, add This MPM does not perform well on older platforms which lack good threading, but the requirement for EPoll or KQueue makes this moot.
IssuesAt present, this MPM is incompatible with what makes search so hot?呵呵，还是美女更吸引眼球... 2007/3/19 用心去发现美丽看到一个有趣的blog, http://sherrymylife.spaces.live.com 呵呵，开始网速慢图片没下下来，看半天不知道是怎么回事，很有趣的照片，要向她学习，用相机更是用心记住一点点的美丽 木兰词 拟古决绝词柬友这首诗怪怪的...... 人生若只如初见，何事西风悲画扇？等闲变却故人心，却道故人心易变。 2007/3/14 一本书和阅读代码(zz)http://blog.csdn.net/g9yuayon/archive/2007/03/13/1... g9老大这篇文章不错，好好翻番Grady Booch的blog先，然后满心欢喜期待这本Beautiful Code: Leading Programmers Explain How They Think， hoho...
很难想象钢琴家不用聆听大师的作品；诗人不用揣摩传世的经典；画家不用体会前辈的佳作；拳手不用参详高人的示范。那我们怎么能想象程序员不用仔细学习性感的代码？可惜的是，美妙的代码往往有如像Shrek，乍一看也就是面目丑陋的庞然大物。没有Fionna的聪慧，我们也难欣赏Shrek洋葱一般层次丰富的心灵。再说，代码一旦写成，我们看到的也就是一段神来之笔。再难体会到作者在难题前内心有如困兽般地冲撞，面临多种选择时精神的激荡。我们也再难追溯每个数据结构背后的理念，每段算法成型过程中每一步的由来(顺便说一句。这也是为什么Knuth的书引人入胜的原因。每段算法怎么从无到有，自粗而细，由慢转快，通通脉络清晰)。就算是理解代码本身，想来每人的体会也有深有浅。不知道多少老大因为这些困难没能体会到阅读代码时心头肿胀（乱用冯唐语）的快感？除非，除非有高手引领我们入门，给我们细述经典代码如何玲珑浮屠，如何眼波婉转。 IBM的Grady Booch也强力推荐程序员大量阅读代码，认为这是从新手到高手的必要手段。如果喜欢软件开发老大还没有订阅Grady Booch的博客的话，现在是时候了。G老大的私人项目Architecture Handbook想必更是每位对软件架构有兴趣的老大的必读材料吧？他在这本公开的手册将归类整理历史上各式架构。虽然这些工作开始还不到四年，但上面已经有不少高质量的资料。比如以前提到过的Eclipse架构考古。也许用G老大自己的话最能雄辩地道出软件考古的意义：经典科学通过在定量观察和理论构建间曼舞取得进展。前者细致而刻意，后者富于创新且能经受检验。计算机科学充满了经验的观察和理论的构造，但软件世界里，我们往往把所有时间用于搭建实物，却疏于科学研究。我们有自己关于流程和工具的理论，但它们大部分都基于坊间传闻和个人经验，而不是基于反映了可靠经验研究的确凿且中立的数据（classical science advances via the dance between quantitative observation and theoretical construction." The former is deliberate and intentional; the latter is creative and testable. Computer science is full of empirical observation and the construction of theories, but in the world of software we often spend all of time building artifacts and not enough time doing science. We have our share of theories, about process and tools, but much of that work is based on anecdote and personal experience, not the hard, dispassionate data that reflects good empirical work）
G老大的架构手册有一栏read list，目前推荐的两个条目都是代码阅读。一是C++的STL（设计，源代码）。二是qmail（设计，源代码）。今年的SIGCSE年会上，G老大做了主题演讲。不，我没去。我也是看别人的博客写的，现在就等Podcast出来了。里面提到计算机系不仅要交给学生知识，也要让学生领会“激情，美丽，快乐，和敬畏”，真是深得我心啊。在演讲里，G老大频繁用“正确和高尚”来描述计算机业界众人的努力，说从事软硬件研发的工作既是特权也是义务。它是特权，因为我们从根本上多方面深刻地改变这个世界。基于同样的原因，这也是我们的义务。我们应当牢记这点，并让我们的学生同样明白。不知道G老大和蜘蛛人有什么瓜葛。 又跑题了。还是说回来。 大家都熟悉的Code Reading: The Open Source Perspective是本不错的入门书。不过作者着眼于零散的代码，注重局部细节的实现(比如第三章第四章)，很少分析一段完整程序：这段程序的动机是什么？解决了什么好玩儿的问题？哪些地方体现了作者的天才？代码的设计理念是什么？面临选择，怎么做出取舍。。。 令人欣慰的是，人见人耐的老牌geek，资深出版人，Tim O’Reilly终于按耐不住出手了。今年6月，O’Reilly将推出新书Beautiful Code: Leading Programmers Explain How They Think。瞧这书名取的，多诱人啊。“Explain How They Think”，啧啧，这不引诱俺体验一下当Craig Schwartz的经验么？
再看看目录，禁不住口水滴滴答答地流哈。Enough showed. Pre-ordered.
2007/3/6 Importance of Statistics(zz)March 03, 2007 swilvel.com这个网站超级赞，非常有想法，两人半年写的，是ruby on rails哦.
"How sad. All governments find it tempting to tweak the numbers they are judged by. But in doing this they deprive themselves of the best guide to future policymaking. And they also create a self-defeating spiral of distrust in which even the numbers they have not tweaked are disbelieved." From The Economist print edition BTW, at Swivel we're anti-government-number-tweaking. 2007/3/4 [转]缠绵悱恻的中国情诗名句排行榜1柳永 凤栖梧 衣带渐宽终不悔，为伊消得人憔悴。 注：很是奇怪，全部都是悲情的诗句。后来想通了，当享受爱情的时候，诗人们是没有时间写诗的；只有没有爱情了，才开始用文字来宣泄自己的情绪，所以都是悲情的诗句了。(同事原创的注, 超级强:) |
|
|
