#
摘要: 搜索題，本來是簡單題，但我犯了錯誤。。。
閱讀全文
摘要: EOJ 1981 Sticks
POJ 1011 Sticks
HDOJ 1455 Sticks
UVA 307 Sticks 。。。
閱讀全文
摘要: PM 常常遇到一個難題，就是有好多東西想要做，但無奈什么事都得通過工程師，沒辦法自己動手，于是因為和工程師不太美好的關系，最后實際的產品都沒有設計時看起來好。我這邊講的是「網路公司」的狀態，PM 泛指那些規劃出產品的人。其他產業也許也有類似情形，以下這些「教戰手則」，提供給正在摸索自己生存之道的 PM 一些參考。。。
閱讀全文
摘要: 老師教我們怎么寫程序，但從來沒告訴我們在公司里，會有個叫做 PM 的人每天分派作業給我們，還逼著我們趕快做完。這是許多軟件工程師進入職場的第一個驚喜。隔了不久，還會發現，這些可能把你壓得死死的 PM，多半一行程序都不會寫。于是我們會面臨一種很矛盾的心情，有時候會是一種有點被欺負的心理。這篇文章是前一篇文章PM 如何突破工程師的心防的延伸，我們討論的是工程師在這樣狀況下的生存之道。。。
閱讀全文
摘要: KISS – Keep It Simple Stupid
DRY – Don’t Repeat Yourself 。。。
閱讀全文
摘要: 看歸看了，但習題沒做，學習效果打了折扣。。。
閱讀全文
摘要: 最近的幾個月，我一直在學習一種叫Haskell的編程語言。由于里面有太多的從未遇到的編程概念，整個過程就像是完全重新學習如何編程。在i.TV網站上，我寫了很多JavaScript(node.js和前端代碼)。雖然有不少的函數式/haskell式的編程模式不能引用進來，但仍有大量的技術思想讓我在使用javascript編程語言時受益不少。
你會發現Haskell庫里有能夠處理各種事情的各種各樣的函數。起初我以為這些只是一種技術上的積累，但隨后我認識到，這些函數相比起其它語言里的函數，它們能應用到形式更廣泛的問題中。這使得它們更有價值，因為我們都不太喜歡對一些常見的問題還不得不自己去寫解決方案。。。
閱讀全文
摘要: 一日，你查看你的程序代碼，你有兩大塊代碼看起來幾乎完全的一樣。事實上它們就是完全一樣，除了一個代碼里說的是“Spaghetti(意大利面條)”，另一個代碼里說的是“Chocolate Moose(巧克力慕絲)”。。。
閱讀全文
摘要: 在一個創業公司里，最初的十個人決定了這個公司的成敗與否。。。
閱讀全文
摘要: 心理學家與專業魔術師邁克爾·格爾博提出了“達·芬奇與眾不同的7種天才特質”。他闡述為好奇心、悟性、藝術和科學、關聯、開闊、細致和合作精神。然而，這些特質本身并沒有什么超前性，它們卻使達·芬奇能夠從不同的角度看事物，從而能夠去思考不同的事物，驅動創新。。。
閱讀全文
摘要: 可能除了哲學家以外，我認為程序員是最懶的一群人。他們的職業看起來又似乎有一定的勞動強度。。。
閱讀全文
摘要: 馬克·吐溫曾經說過，所謂經典小說，就是指很多人希望讀過，但很少人真正花時間去讀的小說。這種說法同樣適用于“經典”的計算機書籍。。。
閱讀全文
摘要: 如何設計出具有優秀用戶體驗的產品是交互設計師始終面臨的一道難題，“好的產品設計一定是建立在對用戶需求的深刻理解上”這句話被許多設計師視為設計的天條；至于在設計中如何發現并深刻理解用戶的需求，并由此設計出具有優秀用戶體驗的產品，阿里巴巴的UED團隊在多年的產品設計實踐中總結出重要的五項原則。。。
閱讀全文
摘要: 工程師有喜歡解決問題的天性，尤其不能忍受他的系統里面有 bugs。所以只要碰到問題，他就想要把它們通通解決掉，似乎只要能夠解決越多問題，他就能夠創造越多價值。這樣的邏輯在企業用軟件的開發、維護中，或許是對的，但拿到消費者市場里面，卻幾乎是殺死創業者最重要的原因。。。
閱讀全文
摘要: 上課的時候記筆記？哪門功課不行，就集中精力專項突擊？自習的時候不要晃，選好一個地兒安安穩穩地待那兒學習？你還在這樣學習嗎？不要被騙了：這些被我們奉為良好學習習慣的東西，恰恰是冒了學習正道的大不韙。。。
閱讀全文
摘要: 假設你是正在開發和維護一個包含 2000 個類并使用了很多框架的 Java 開發人員。你要如何理解這些代碼？在一個典型的 Java 企業項目小組中，大部分能夠幫你的高級工程師看起來都很忙。文檔也很少。你需要盡快交付成果，并向項目組證明自己的能力。你會如何處理這種狀況？這篇文字為開始一個新項目的 Java 開發者提供了一些建議。。。
閱讀全文
摘要: 歷史已經證明，軟件設計的缺陷一直是導致其漏洞被利用的最主要的罪魁禍首。安全專家發現，多數漏洞源自常見軟件中相對有限的一些漏洞。軟件開發者和設計者應當嚴格檢查程序中的各種錯誤，盡量在軟件部署之前就減少或清除其中的漏洞。。。
閱讀全文
摘要: gc即垃圾收集機制是指jvm用于釋放那些不再使用的對象所占用的內存。java語言并不要求jvm有gc，也沒有規定gc如何工作。不過常用的jvm都有gc，而且大多數gc都使用類似的算法管理內存和執行收集操作。
在充分理解了垃圾收集算法和執行過程后，才能有效的優化它的性能。有些垃圾收集專用于特殊的應用程序。比如，實時應用程序主要是為了避免垃圾收集中斷，而大多數OLTP應用程序則注重整體效率。理解了應用程序的工作負荷和jvm支持的垃圾收集算法，便可以進行優化配置垃圾收集器。
垃圾收集的目的在于清除不再使用的對象。gc通過確定對象是否被活動對象引用來確定是否收集該對象。gc首先要判斷該對象是否是時候可以收集。。。
閱讀全文
摘要: Java 語言可能是使用最廣泛的依賴于垃圾收集的編程語言，但是它并不是第一個。垃圾收集已經成為了包括 Lisp、Smalltalk、Eiffel、Haskell、ML、Scheme和 Modula-3 在內的許多編程語言的一個集成部分，并且從 20 世紀 60 年代早期就開始使用了。在 Java 理論與實踐的本篇文章中，Brian Goetz 描述了垃圾收集最常用的技術。在以后的幾個月，他將分析 1.4 JVM 所使用的垃圾收集策略、不同垃圾收集策略對性能的影響和如何才能（以及如何 不能）幫助垃圾收集器取得更好的性能。。。
閱讀全文
摘要: 求二分圖最大匹配，使用匈牙利算法。。。
閱讀全文
摘要: 二分圖最大匹配使用匈牙利算法。。。
閱讀全文
摘要: 朱莉亞和我正在Wii上玩《超級馬里奧賽車》（Super Mario Kart）。在這款賽車游戲里，我們可以選擇一輛賽車，在各種賽道同幽靈、電腦或者世界各地的其他真人玩家進行對抗。我突然想到：每次玩游戲時，我們都在進行“圖靈測試”。。。
閱讀全文
摘要: 解析器是parser，而解釋器是interpreter。兩者不是同一樣東西，不應該混用。
前者是編譯器/解釋器的重要組成部分，也可以用在IDE之類的地方；其主要作用是進行語法分析，提取出句子的結構。廣義來說輸入一般是程序的源碼，輸出一般是語法樹（syntax tree，也叫parse tree等）或抽象語法樹（abstract syntax tree，AST）。進一步剝開來，廣義的解析器里一般會有掃描器（scanner，也叫tokenizer或者lexical analyzer，詞法分析器），以及狹義的解析器（parser，也叫syntax analyzer，語法分析器）。掃描器的輸入一般是文本，經過詞法分析，輸出是將文本切割為單詞的流。狹義的解析器輸入是單詞的流，經過語法分析，輸出是語法樹或者精簡過的AST。
（在一些編譯器/解釋器中，解析也可能與后續的語義分析、代碼生成或解釋執行等步驟融合在一起，不一定真的會構造出完整的語法樹。但概念上說解析器就是用來抽取句子結構用的，而語法樹就是表示句子結構的方式。。。
閱讀全文
摘要: 在一個允許在堆上動態分配內存空間并且采取隱式內存釋放的程序設計語言里，如何確保內存的正確釋放不再是程序員的關注點，而由運行時環境來提供支持。無法被程序引用的在堆上已分配的內存空間成為垃圾（無用內存單元）。。。
閱讀全文