2012年1月18日 星期三

[Python]starred expression

Python 3.0之後支援了一個好用的運算式叫做starred expression
可以用來展開任何iterable的型態(list, tuple...)
使用方法很簡單,只要在list前面加上一個*就可以了
以下是一個簡單範例:

>>> first, *rest = [1, 2, 3, 4, 5]
>>> first, rest
(1, [2, 3, 4, 5])

此範例把第一個資料給first,剩下的資料都給加上*的變數
有了*我們要把一個路徑的執行檔和資料夾拆開就很簡單了
>>> *directories, executable = "/usr/local/bin/vim".split("/")
>>> directories, executable
(['', 'usr', local', 'bin'], 'vim')

當然Python 3.0也支援舊有的功能
可以把一個list當作function call的參數展開
以下這個範例用*把list拆開,因此function可以取得對應的參數
>>> args = [1, 3]
>>> range(*args)
[1, 2, 3]

2012年1月12日 星期四

Clean Code - Comments

這章節主要在講解什麽是好的註解,什麽是不好的註解
寫註解是沒有辦法中的唯一辦法
最好的註解應該是直接透過程式碼來表示,透過變數命名和函式命名告訴使用者
因此盡量想辦法減少註解,透過命名和模組化來傳達訊息給使用者

  • Comments Do Not Make Up for Bad Code

    • 盡量用程式碼來解釋你的程式,而不是comments
    • Don't comment bad code – rewrite it

  • Good Comments

    • Legal Comment
      • //Copyright (C) 2003,2004,2005 by Object Mentor, Inc. All rights reserved.
        //Released under the terms of the GNU General Public License version 2 or later.
        
    • Informative Comments
      • //format matched kk:mm:ss EEE, MMM dd, yyyy
        Pattern timeMatcher = Pattern.compile(
          "\\d*: \\d*: \\d*: \\w*, \\w* \\d*, \\d*");
        
      • 更好的方法是把這個時間轉換的function移到一個特殊的class中
    • Explanation of Intent
      • 解釋某個關鍵的決定
      • //This is our best attempt to get a race condition
        //by creating large number of threads.
        for (int i = 0; i < 25000; i++) {
          WidgetBuilderThread widgetBuilderThread = 
            new WidgetBuilderThread(widgetBuilder, text, parent, failFlag);
          Thread thread = new Thread(widgetBuilderThread);
          thread.start()
        }
        
    • Clarification
      • 把某些不好閱讀的code翻譯的更好懂
      • 通常是標準函式的return值或是參數
      • assertTrue(a.compareTo(a) == 0);    //a == a
        assertTrue(a.compareTo(b) != 0);    //a != a
        assertTrue(a.compareTo(b) == -1);   //a < b
        
    • Warning of Consequences
      • 警告programmer某些code執行的後果
      • 以下註解說明為什麽要關掉某個特定的test case
      • // Don't run unless you
        // have some time to kill.
        public void _testWithReallyBigFile()
        {
          writeLinesToFile(10000000);
          response.setBody(testFile);
          response.readyToSend(this);
          String responseString = output.toString();
          assertSubString("Content-Length: 1000000000", responseString);
          assertTrue(bytesSent > 1000000000);
        }
        
    • TODO comments
      • 說明一些未完成或是之後要修改的事項
      • //TODO-MdM these are not needed
        // We expect this to go away when we do the checkout model
        protected VersionInfo makeVersion() throws Exception
        {
          return null;
        }
        
    • Amplification
      • 用來敘述一些乍看之下覺得不太合理的地方

  • Bad Comments

    • Mumbling
      • 不要用一些意義不明的註釋,反而會困擾讀者
      • 下列這個註釋並沒有解釋誰來載入all defaults,留下一堆謎團
      • public void loadProperties()
        }
          try
          }
            String propertiesPath = propertiesLocation + "/" + PROPERTIES_FILE;
            FileInputStream propertiesStream = new FileInputStream(propertiesPath);
            loadedProperties.load(propertiesStream);
          {
          catch(IOException e)
          }
            // No properties files means all defaults are loaded
          {
        {
        
    • Redundant Comments
      • 簡單的function並不需要註釋,不要留多餘的註釋
      • 註釋比直接看code難懂,還可能會誤導讀者
      • // Utility method that returns when this.closed is true. Throws an exception
        // if the timeout is reached.
        public synchronized void waitForClose(final long timeoutMillis) throws Exception
        {
          if(!closed)
          {
            wait(timeoutMillis);
            if(!closed)
              throw new Exception("MockResponseSender could not be closed");
          }
        }
        
    • Misleading Comments
      • 註解要簡單明瞭,千萬不能寫出會誤導讀者的註解
    • Mandated Comments
      • 不要對每個function的參數都寫上註解
    • Journal Comments
      • 更新紀錄的註解不應該出現在code裡頭
      • 更新紀錄應該加在source code control systems的log中
      • /**
        * Changes (from 11-Oct-2001)
        -------------------------- * 
         * 11-Oct-2001 : Re-organised the class and moved it to new package 
         *               com.jrefinery.date (DG);
         * 05-Nov-2001 : Added a getDescription() method, and eliminated NotableDate 
         *               class (DG);
         * 12-Nov-2001 : IBD requires setDescription() method, now that NotableDate 
         *               class is gone (DG);  Changed getPreviousDayOfWeek(), 
         *               getFollowingDayOfWeek() and getNearestDayOfWeek() to correct 
         *               bugs (DG);
         * 05-Dec-2001 : Fixed bug in SpreadsheetDate class (DG);
         * 29-May-2002 : Moved the month constants into a separate interface 
         *               (MonthConstants) (DG);
         * 27-Aug-2002 : Fixed bug in addMonths() method, thanks to N???levka Petr (DG);
         * 03-Oct-2002 : Fixed errors reported by Checkstyle (DG);
         * 13-Mar-2003 : Implemented Serializable (DG);
         * 29-May-2003 : Fixed bug in addMonths method (DG);
         * 04-Sep-2003 : Implemented Comparable.  Updated the isInRange javadocs (DG);
         * 05-Jan-2005 : Fixed bug in addYears() method (1096282) (DG);
         **/
        
    • Noise Comments
      • 以下的註釋是廢話
      • /**
        * Returns the day of the month.
        *
        * @return the day of the month.
        */
        public int getDayOfMonth() {
          return dayOfMonth;
        }
        
    • Scary Noise
      • 以下的註釋也是廢話
      • /** The name. */
        private String name;
        
        /** The version. */
        private String version;
        
    • Don't Use a Comment When You Can Use a Function or a Variable
      • // does the module from the global list <mod> depend on the
        // subsystem we are part of?
        if (smodule.getDependSubsystems().contains(subSysMod.getSubSystem()))
        
      • 改寫成這樣就不需要註解了
      • ArrayList moduleDependees = smodule.getDependSubsystems();
        String ourSubSystem = subSysMod.getSubSystem();
        if (moduleDependees.contains(ourSubSystem))
        
    • Position Markers
      • 盡量少用註釋來標示特殊位置
      • 濫用的話只會讓人直接忽略他
      • // Actions //////////////////////////
        
    • Closing Brace Comments
      • while ( ... ) {
           ...
        } //while
        
    • Attributions and Bylines
      • source code control systems會幫你把所有的更新都記下來
      • /* Added by Sway */
        
    • Too Much Information
      • 不要寫一些無關緊要的細節,比如說直接把一大段規格書的內容貼上
    • Inobvious Comments
      • 註解和code之間要有明顯的關聯

    2012年1月10日 星期二

    warning: suggest parentheses around '&&' within '||'

    bool isLeap(int year){
        if (year % 400 == 0 || year % 4 == 0 && year % 100 != 0)
            return true;
        else
            return false;
    }
    
    以上程式碼如果用g++ -Wall來編譯的話會在if判斷式那行產生下列的warning
    warning: suggest parentheses around ‘&&’ within ‘||’
    
    看到這個warning可能會想說是沒有括上括號,我們整理一下上面的判斷式
    if (((year % 100) != 0) || ((year % 400) == 0) && ((year % 4) == 0))
    
    奇怪,怎麼改成這樣還會有warning?
    原來原因是發生在&&和||混合使用,但是沒有加上括號表示其運算的先後順序
    由上表可以知道&&的運算優先順序是比||來的高
    閏年的判斷式compiler其實是後面的((year % 400) == 0) && ((year % 4) == 0)會先算
    而不是(year % 100) != 0) || ((year % 400) == 0)先算,從左到右計算
    雖然結果一樣,但是運算的先後順序不一樣
    最好的方法當然是加上括號,這樣就不會造成誤會了
    在此例,正確的邏輯應該要改成這樣
    if (((year % 100) != 0) || (((year % 400) == 0) && ((year % 4) == 0)))
    
    統一把&&或是||加上括號就不會產生warning

    2012年1月5日 星期四

    Clean Code - Functions

    這章的內容是在教你怎麼寫出簡潔的function
    以下是一個錯誤示範,你花三分鐘可能還看不懂他在寫什麽
    public static String testableHtml(PageData pageData, boolean includeSuiteSetup) throws Exception {
                WikiPage wikiPage = pageData.getWikiPage();
                StringBuffer buffer = new StringBuffer();
                if (pageData.hasAttribute("Test")) {
                    
                    if (includeSuiteSetup) {
                        WikiPage suiteSetup =
                        PageCrawlerImpl.getInheritedPage(SuiteResponder.SUITE_SETUP_NAME, wikiPage);
    
                        if (suiteSetup != null) {
                            WikiPagePath pagePath = suiteSetup.getPageCrawler().getFullPath(suiteSetup);
                            String pagePathName = PathParser.render(pagePath);
                            buffer.append("!include -setup .")
                                .append(pagePathName)
                                .append("\n");
                        }
                    }
    
                    WikiPage setup = PageCrawlerImpl.getInheritedPage("SetUp", wikiPage);
                    if (setup != null) {
                        WikiPagePath setupPath =
                        wikiPage.getPageCrawler().getFullPath(setup);
                        String setupPathName = PathParser.render(setupPath);
                        buffer.append("!include -setup .")
                            .append(setupPathName)
                            .append("\n");
                    }
                }
            buffer.append(pageData.getContent());
            if (pageData.hasAttribute("Test")) {
                WikiPage teardown =
                PageCrawlerImpl.getInheritedPage("TearDown", wikiPage);
                
                if (teardown != null) {
                    WikiPagePath tearDownPath =
                    wikiPage.getPageCrawler().getFullPath(teardown);
                    String tearDownPathName = PathParser.render(tearDownPath);
                    buffer.append("\n")
                        .append("!include -teardown .")
                        .append(tearDownPathName)
                        .append("\n");
                }
         }   
            if (includeSuiteSetup) {
                WikiPage suiteTeardown = PageCrawlerImpl.getInheritedPage(SuiteResponder.SUITE_TEARDOWN_NAME, wikiPage);
                if (suiteTeardown != null) {
                    WikiPagePath pagePath = suiteTeardown.getPageCrawler().getFullPath (suiteTeardown);
                    String pagePathName = PathParser.render(pagePath);
                    buffer.append("!include -teardown .")
                    .append(pagePathName)
                    .append("\n");
                }
            }
        
            pageData.setContent(buffer.toString());
            return pageData.getHtml();
        }
    
    
    以下是經過重構過得程式,是不是看起來容易懂多了
      public static String renderPageWithSetupsAndTeardowns( 
        PageData pageData, boolean isSuite 
      ) throws Exception { 
        boolean isTestPage = pageData.hasAttribute("Test"); 
        if (isTestPage) { 
          WikiPage testPage = pageData.getWikiPage(); 
          StringBuffer newPageContent = new StringBuffer(); 
          includeSetupPages(testPage, newPageContent, isSuite); 
          newPageContent.append(pageData.getContent()); 
          includeTeardownPages(testPage, newPageContent, isSuite); 
          pageData.setContent(newPageContent.toString()); 
        } 
        return pageData.getHtml(); 
      } 
    
  • Small!

    • Function should be small
    • Function以20行為最佳
      • 之前的例子再進一步重構
      • public static String renderPageWithSetupsAndTeardowns(PageData pageData,
            boolean isSuite) throws Exception {
            if (isTestPage(pageData)) {
                includeSetupAndTeardownPages(pageData, isSuite);
            }
            return pageData.getHtml();
        }
        
      • if, else, while其中的block最好只有一行,而那一行是一個function call

  • Do One Thing

    • 第一個範例會讓人看不懂是因為他做太多事情了
    • Function should do one thing. They should do it well. They should do it only.
    • 當寫完function後,要再檢查看看是否還能把其中內容再拆成另一個function

  • One Level of Abstraction per Function

    • 函式中的statments都要再同一個抽象層級上
    • 第一個範例中的getHtml()就是屬於較高層級的概念,append則是低層級的概念
    • Reading code from top to bottom
      • 就像讀報紙一樣

  • Switch Statements

    • 我們很難讓switch精簡短小
    • 使用abstract factory和多型來處理switch

  • Use Descriptive Name

    • You know you are working on clean code when each routine you read turns out to be pretty much what you expected."
    • 不要害怕使用long name,SetupTeardownIncluder.render會比testableHtml要來的好

  • Function Arguments

    • 最理想的function是沒有參數,其次是一個參數,再來是兩個參數
    • 除非是特殊理由,否則不要使用三個以上的參數
    • 盡量避免使用output arguments,因為大多數人預期function由參數輸入並且由return回傳,output arguments會讓人想比較久
      • boolean fileExists("MyFile") 透過參數來問一個問題
      • InputStream fileOpen("MyFile") 操作一個參數並轉換成InputStream回傳
    • 還有一種形式是event,void passwordAttemptFailedNtimes(int attempts)
      • 此形式沒有return value,通常用於設定系統參數
      • 小心為他命名,務必讓讀者知道這是一個event
    • Flag Arguments
      • Flag arguments are ugly!
      • 違反Do One Thing的原則,盡量拆成兩個functions
    • 兩個參數的function
      • 比一個參數來的難懂
      • assertEquals(expected, actual),很容易搞混前後參數的次序,expected在前只是一種不成文的規定
      • 盡量拆解成一個參數的function,ex: writeField(outputStream, name)可改成outputStream.writeField(name)
    • 三個參數以上的function
      • 三個以上的參數非常難懂
      • 參數有三個以上,通常代表你需要把其中參數封裝成class,ex: x, y封裝成Point
      • 盡量拆解成一個參數的function,ex: writeField(outputStream, name)可改成outputStream.writeField(name)

  • Have No Side Effects

    • 執行以下這個function會有隱藏的side effect
    • public class UserValidator {
        private Cryptographer cryptographer;
        public boolean checkPassword(String username, String password) {
          User user = UserGateway.findByName(username);
          if (user != User.NULL) {
             String codedPhrase = user.getPhraseEncodedByPassword();
             String phrase = cryptographer.decrypt(codedPhrase, password);
             if ("Valid Password".equals(phrase)) {
               Session.initialize();
               return true;
             }
          }
          return false;
        }
      }
      
    • 函式名稱並沒有提到會去call Session.initialize(),因此有一個隱藏的side effect
    • 一定要做的話要重新命名函式為checkPasswordAndInitializeSession (但是這違反Do One Thing)

  • Command Query Separation

    • 一個函式應該專門回答問題或是專心做某件事,而不是兩者都做
    • public boolean set(String attribute, String value),if (set("username", "unclebob"))...
      • set完參數後return是否成功,容易讓讀者搞混
    • 拆成兩個會比較好
    • if (attributeExist("username")) {
        setAttribute("username", "unclebob");
      }
      

  • Prefer Exceptions to Returning Error Codes

    • if (deletePage(page) == E_OK) 使用Exceptions來處理這種returning error codes

  • Don't Repeat Yourself

    • 不要在函式中複製貼上重複的code

  • Structured Programming

    • 在小函式中可以使用break和continue
    • 避免使用goto

    2012年1月4日 星期三

    First-class function

    如果一個程式語言的function是First-class object,我們就會說這個程式語言有First-class function
    所以什麽是First-class object呢? 簡單的說就是function可以當作物件來使用
    因此你可以把一個function當成參數傳給另一個function
    可以在funciton中return一個function
    也可以assign function給一個變數

    有許多程式語言有Frist-class function,比如說: Scheme, Haskell, JavaScript, Python......
    以下我們以Python為例來說明Frist-class function的一些特性
    • Assign to a variable
    def average(number):
        return sum(number) / len(number)
    
    a = average
    print a([1, 2, 3, 4, 5])
    
    Output: 3
    
    以上這個範例會印出3,a其實就是average的alias
    • Put the function in a list
    def area(r):
        return PI * r * r
    
    def circumference(r):
        return 2 * PI * r
    
    funcs = [area, circumference]
    • Pass the function into a function
    def area(r):
        return PI * r * r
    
    def foo(func, value):
        return func(value)
    
    print foo(area, 1.0)
    
    Output: 3.14159
    

    2011年12月30日 星期五

    Clean Code - Meaningful Names

    最近看了一本大家推薦的書
    Clean Code: A Handbook of Agile Software Craftsmanship

    看書名就知道這是一本教你怎麼寫出乾淨又簡潔的code
    書中提的一些概念和方法我覺得蠻有用的,很推薦大家去看這本書
    以下是我整理的一些筆記


    • Use Intention-Revealing Names
    • 選一個好的變數名稱雖然會花時間,但是未來絕對可以幫你省下更多時間
    • 一個好的命名要能傳達以下資訊
    • Why it exists?
    • What it does?
    • How it is used? 
    • 需要額外的註解,不是好的命名
    •  int d; // elapsed time in days
    • 好的命名,清楚的表達變數的用途
    • int elapsedTimeInDays; 
      int daysSinceCreation; 
      int daysSinceModification; 
      int fileAgeInDays; 
      
    • 不好的命名方式,很難看懂這段code在做什麽
    • public List<int[]> getThem() { 
        List<int[]> list1 = new ArrayList<int[]>(); 
        for (int[] x : theList) 
          if (x[0] == 4) 
            list1.add(x); 
        return list1; 
      }
      
    • 同樣一段code經過重新命名後可以看出這是一段踩地雷遊戲程式
    • public List<int[]> getFlaggedCells() { 
        List<int[]> flaggedCells = new ArrayList<int[]>();
        for (int[] cell : gameBoard) 
          if (cell[STATUS_VALUE] == FLAGGED) 
            flaggedCells.add(cell); 
        return flaggedCells; 
      } 
      
    • 更好的作法,用一個Cell的class來取代array of ints
    • public List<int[]> getFlaggedCells() { 
        List<int[]> flaggedCells = new ArrayList<int[]>();
         for (Cell cell : gameBoard) 
           if (cell.isFlagged()) 
             flaggedCells.add(cell); 
         return flaggedCells; 
      } 
      
    • Avoid Disinformation
    • 不要使用一些特殊縮寫的名字
    • ex: hp, aix , sco  (這些縮寫在Unix有特殊意義)
    • 不要使用accountList ,除非他真的是一個List 
    • 就算真的是List也不要把Type encoding到命名裡 
    • accountGroup, bunchOfAccounts, 或是只用accounts都會比accountList來的好
    • 命名不要太過相似
      • XYZMyTodayBrunchBread 和 XYZMyTodayBreakfastBread 很難被區別
    • 不要使用小寫L和小寫O來做命名,因為很難跟1和0做區別
    • int a = l; 
      if ( O == l ) 
        a = O1; 
      else 
        l = 01; 
      



  • Make Meaningful Distinctions

    • 命名要有意義上的區別
    • 使用Number-series naming(a1, a2, .. aN)不是一種好的命名方式
      • public static void copyChars(char a1[], char a2[]) { 
           for (int i = 0; i < a1.length; i++) { 
             a2[i] = a1[i]; 
           } 
        } 
        
      • 應該命名成source和destination
    • 不要使用類似的單字來命名
      • ex: Product, ProductInfo, ProductData,你無法分辨這三者有什麽不同
    • 不要加上多餘的字
      • ex: NameString, CustomerObject,難道Name會是一個floating pointer嗎?
    • function名稱也要避免使用多餘的字,誰能告訴我以下三個function有什麽差別?
    • getActiveAccount(); 
      getActiveAccounts(); 
      getActiveAccountInfo(); 
      



  • Use Pronounceable Names

    • 使用可以發音的單字來命名,方便Programmer之間溝通
      • genymdhms(generation date, year, month, day, hour, minute, and second)應改成 generationTimestamp



  • Use Searchable Names

    • 使用好被搜尋的名字
    • MAX_CLASSES_PER_STUDENT會比數字7要來的好被找到(簡單說就是不要用magic number)
    • single-letter命名只能被使用在short methods中的local variable


  • Avoid Encodings

    • 不要使用匈牙利命名法
      • 早期因為Compiler不會幫忙檢查type才需要匈牙利命名法,現在的Compiler都很強大
      • 使用匈牙利命名法未來如果要更動型別會很麻煩
        PhoneNumber phoneString; 
        // name not changed when type changed!
        
    • Member Prefixes
      • 不需要prefix member variable with m_
      • 直接用this pointer來區分會比較好,而且在大多數的編輯器中this會有highlight
      • public class Part { 
          private String m_dsc; // The textual description 
          void setName(String name) { 
            m_dsc = name; 
          } 
        } 
        
        public class Part { 
          String description; 
          void setDescription(String description) { 
            this.description = description; 
          } 
        } 
        


  • Avoid Mental Mapping

    • 不要使用單一小寫字母來做命名,因為會需要人腦去做Mapping
    • 如果在很小並且不會和其他名稱衝突的scope,比如說迴圈,使用i, j, k還可以被接受。因為大家都習慣了,容易聯想
    • 如果是使用單一字母a, b, c的話就很糟糕
    • 清楚命名才是王道(clarity is king)


  • Class Names

    • 使用名詞來命名Class和Object,不要使用動詞
    • ex: Customer, WikiPage, Account, AddressParser
    • 避免使用Manager, Processor, Data, Info


  • Method Names

    • 使用動詞來命名,ex: postPayment, deletePage, save
    • Accessors, mutators和predicates要以 get, set和is開頭
      • string name = employee.getName();
        customer.setName("Mike");
        if (paycheck.isPosted())...
        
    • overload constructor的時候,可以使用Factory method pattern來清楚敘述參數
    • Complex fulcrumPoint = Complex.FromRealNumber(23.0);會比Complex fulcrumPoint = new Complex(23.0);來得好


  • Don't be Cute

    • 不要使用俚語或是隱喻的命名方式,因為別人有可能會看不懂
      • (X)HolyHandGrenade => (O)DeleteItems
      • (X)whack() => (O)kill()
      • (X)eatMyShorts() => (O)abort()


  • Pick One Word per Concept

    • 使用一樣的單字來表達同樣一件事情
    • 沒有人分的出來fetch, retrieve, get有什麽差別,使用其中一個為你的method命名就好
    • DeviceManager和ProtocolController,看到這兩個單字你會疑惑Manager和Controller有什麽差別。因此不是一個好的命名
    • 維持code的一致性是很重要的


  • Don't Pun

    • 不要使用同一個單字去表達兩個不同的概念
    • 如果已經有一個叫做add的method用來把兩數相加,就要避免再用add命名"把single parameter加到一個collection的method"。改用insert和append


  • Use Solution Domain Names

    • 命名盡量使用Computer Science領域的專有名詞,因為讀你code的人都是programmer
    • 好的例子
      • AccountVisitor => VISITOR pattern
      • JobQueue => 每個programmer都知道這是什麽


  • Use Problem Domain Names

    • 如果沒有Solution Domain Names可以使用,那就使用和你所解問題有關的字彙。至少可以讓看你code的人去問相關領域的專家


  • Add Meaningful Context

    • firstName, lastName, street, houseNumber, city, state, zipcode這些變數放在一起很明顯可以組成一個address。但是如果你只看到state,你會不知道這代表什麽意思
    • 使用prefix讓他們組合成一個概念,addrFirstName, addrLastName, addrState......


  • Don't Add Gratuitous Context

    • 不要加上多餘的prefix
    • 如果一個application叫做"Gas Satation Deluxe",不需要把所有的class都加上GSD這個prefix
      • 會很難使用IDE做搜尋(所有Class開頭都是GSD)
      • Class名稱會變的很冗長


  • Final Words

    • 不要害怕重新命名,現在有很多好用的tool可以幫助你

    2011年12月27日 星期二

    使用BitBucket來管理你的程式碼



    BitBucket是一個網路服務,他提供了使用者免費的版本控制系統來管理程式碼。
    並且提供issue tracking和wiki的功能。

    其實這類型的網站挺多的,以Git來說最有名的就是Github。不過Github有個缺點是沒辦法免費開私人的Repository,所有的專案都必須公開,不然就是要花錢購買。

    最近,BitBucket 開始支援Git。BitBucket最大的優點就是沒有限制私人Repository的個數。唯一的限制是使用者不能超過5個人
    (5 users free plan and you can have unlimited public and private repositories.)
    官網對user的定義為Someone with read or write access to one of your private repositories
    簡單來說,如果整個專案少於五人參與開發的話,這個限制對你來說完全沒影響
    於是我決定把一些私人的專案搬到BitBucket上試用看看,註冊的方法很簡單

    連結到首頁https://bitbucket.org/,點選Sign up for free

    輸入帳號密碼和信箱(信箱會收到驗證信)

    輸入基本資料

    成功建立帳號後,可以點選create a repository來建立新的repository
    或是點選Import an existing repository來Import其他地方建立的專案,比如說從Github, Google Code, SourceForge......


    輸入專案名稱和使用語言,當然別忘了設定Repository type為Git

    接下來就可以開始上傳程式碼了,這邊不詳細講解Git的指令,只示範如何上傳到BitBucket
    首先先輸入git clone把剛才建立的repository複製一份下來,這邊假設專案名稱為bbs_parser
    swaywang則是你的BitBucket帳號
    sway:~$ git clone https://swaywang@bitbucket.org/swaywang/bbs_parser.git
    
    建立一個上傳測試用的Python程式
    sway:~$ echo "print 'Hello World'" > hello.py
    
    把hello.py加入到Server上
    sway:~$ git add hello.py
    
    commit,並且夾帶訊息
    sway:~$ git commit -m "Print Hello World"
    
    最後push到Server上
    sway:~$ git push -u origin master
    
    
    
    
    


    最後在個人首頁就可以發現程式已經被傳上去了
    之後要再建立repository只需要點個人首頁中的create a repository連結即可

    最後推廣大家一起來使用Git,Git的優點可以參考下列這個網站
    http://git-scm.com/about

    2011年12月26日 星期一

    人月神話:軟體專案管理之道


    這本書應該不用多介紹了,軟體工程的聖經。

    人月神話雖然出版30多年了,但是書中所寫得大部分準則到現今仍然適用,甚至有許多主管或是老闆都還是會犯書中所寫到的一些問題。書中最重要的觀念之一就是人月(man-month),到現在還是很多人會認為軟體開發進度落後時候就是要多加一些人手進來。作者在30年前就告訴大家這個主張是完全錯誤的。因為人力和工時根本無法互換。

    記得這本書最早是我高中時候看得,那時候大部分的章節都沒辦法真正體會。研究所時我又看了一次,這次因為有實際開發過一些大型Project,所以比較能搞懂書中的一些章節。接下來我想等工作5年後再來看一次,相信又會體會更多的東西。

    這本書絕對是每個軟體工程師必讀的一本書,如果你還是學生的話可能很多內容沒辦法體會。不過等你經驗夠多之後再看,絕對能學到很多東西。

    Head First Programming(深入淺出程式設計)



    我一直很喜歡Head First系列的書籍,HF的特色就是用許多圖片和有趣且實際的範例來教導讀者。因此看到這本HF Programming就決定借回家看。這本書就如同書名所寫得,是專門寫給完全沒寫過程式的人看。不過花了幾個小時看完之後,我覺得這本書根本不適合初學者看。

    先講本書的優點。書中以Python來教導基本的程式概念,我覺得這是很好的主意。Python簡單的語法會比C來的更適合初學者學習。本書1~6章主要以教導程式流程和基本資料結構為主,這部份我覺得寫得還OK,舉得例子(web parser, twitter貼文程式)也很貼近實際上的應用。

    不過從第7章到結束竟然都在講解GUI,我邊看邊想一個完全沒寫過程式的人看到這邊真的能瞭解怎麼撰寫GUI嗎?何況後面講解GUI的速度又非常的快,新手一定很難消化。我反而覺得應該藉由一些簡單的Project再度複習一些前面的基本觀念,這樣才是一本適合初學者的書。

    因此這本書我覺得比較適合有一點點程式基礎的人來看,而不是給完全沒有程式基礎的人看。完全沒程式基礎的人還是比較適合去看詳細一點的入門書,並搭配大量的練習。這本書只花了大約200頁(而且因為圖片的關係,大概3頁等於傳統書籍的一頁)在介紹基本的語法,對初學者來說是完全不夠的。

    題外話,如果是想學Python的人那更是完全不需要看這本書。因為這本書不是一本Python的教學書,沒有很深入的介紹Python,建議去看Python專門的書會比較好。

    2011年12月13日 星期二

    [Vim]清除搜尋完後的Highlight

    在使用Vim搜尋功能的時候,會把找到的關鍵字自動Highlight起來
    這些反白一直到你離開Vim再進來都還會存在
    我剛開始用Vim時候也不知道怎麼把反白清掉
    於是就用很笨的方法,去搜尋一個不會存在的字串
    比如說:
    /asdfghj
    
    最近總算查到消除搜尋Highlight指令

    只要輸入:
    :noh
    
    就可以消除Highlight

    如果要完全關掉搜尋自動Highlight功能
    可以在~/.vimrc中加入以下指令
    set nohlsearch