分享

Python Taiwan讀書會_3_程式的資料結構-list(從變數到物件)

本週讀書會的主體是「Python程式的資料結構-list(從變數到物件)」,最主要的觀念是物件導向。有點體會物件的觀念,譬如說一開始沒用Class,接下來的變數就只能用一次,數筆資料要算就要定義數個變數,這樣就事多了,簡單說,能夠重複使用的東西就要重複使用,不然就沒效率了。雖然王大哥建議大家學會用指令,不要拿滑鼠,這樣動作會變得越來越簡潔,我也很想啊,只是我對著那種黑底畫面,總有那種不知如何啓口的害羞,不知道要如何開始跟它講第一句話。
談到變數,有些王大哥特別停下來解釋的觀念,是我在週間讀《精通Python》第一章至第四章中,有讀到的部分,像是「在其他語言裡面每個變數都有對映記憶體的位置,但python裡同一個值可以有兩個名字(變數名稱)」、「等號左邊的變數名稱指向等號右邊的記憶體位置」,或是命名變數的原則如「33個保留字不要拿來當變數名稱」、「除了class外取名都是小寫」、「取名最好寫該變數的意義這樣以後才看得懂,要重視『易讀』這件事,為了自己以後看也為了團隊成員協作」。(有讀到又在讀書會上聽到的,重複出現表示重要)
插播「易讀」這件事,我非常有感,這也是我認為Excel討人厭的地方,我討厭的不是Excel(Excel你很好,都是別人不好),而是人一多,各人習慣百百種,每個人都覺得自己的最順手、最聰明,「不易讀」這件事就整個被凸顯出來。在團隊內為了解決這個問題,我參考了《外商投資銀行超強Excel製作術》,我非常喜歡這本書,它幫忙了我的團隊走到目前這裡,約是大家可以有共通規則去維護資料,這些資料除了我們自己用,也分享給其他BU下的marketing團隊,希望可以打破團隊的界線,提高資料使用的效益、減少索取資料來往的時間與人力,但離我心中的桃花源仍有一段距離。
過去我當研究員時,並沒有要和別人協作的檔案這類的問題(對姊就是一條龍服務),反正從建資料到報表試算出獲利預估,不假手他人(是說也沒別人可以用),後來進入產業界,待在團隊裡就必須與其他成員共用檔案、綑綁流程才能得到產出,這也是一種未來仍會持續流行的工作方式。剛到公司的時候,一開始許多檔案都還是用e-mail寄來寄去(對我們就這麼原始),往往總是花許多時間和精神在釐清版本,或是要指定一個人特別做匯總的工作(工資低就不算浪費?),然後大家開始逐漸使用共用槽和雲端,我也參考《外商投資銀行超強Excel製作術》上面的規則,找出適用的規則應用在共享檔案裡。我認為多數人使用Excel的習慣,導致許多地方若沒人替你解說,無法一打開就上手,稍微多幾個分頁,這個檔案所含的結構、定期要更新的地方在哪裡,就更不清楚了,我的理想是每個Excel能讓每個人到手就會用。
王大哥非常強調物件的觀念,他問我們是否聽過「Everything in Python is object.」,這似乎是句名言,他說他剛學Python時就有人跟他這樣強調,雖然比較複雜但未來比較容易擴充。每個物件裡面會有兩種東西:attribute和method,object在我們現在的中文書上叫「物件」,但在中國網站上叫「對象」,中國的牛人很多,網路資源也很豐富,但我們多少還是要注意名稱上不一致的地方,也要小心不要被中文誤導。我把讀書會裡有提到的待辦事項記了下來,不過老實說,有些東西我都還不知道它們是什麼,但這週結束前和這些陌生的東西應該能多少有點感情基礎了:
  • 註冊github
  • 裝一個Git for Window(利用Vi、Vim編輯器)
  • 了解Dropbox Paper用法以利團隊協作
  • 預習git(下次內容)
在讀書會開始之前,我真不太知道git、github是什麼(講得好像現在就知道),不過我真的是好運,總會遇到有人幫我。讀書會是個50人的群組,雖然王大哥是開放問問題問到飽,但尷尬的是我有時都還反應不過來,哪裏是個我不會(或不知道)的問題,因此我只能先把聽到的東西記下再來查或問,還好我有技術班的好同學,都還不用請出S&P500大的工程師朋友(我猜他很會的是C和Java,要學起Python那還不是分分鐘的事嗎)。我同學不僅跟Python很熟,而且都是用一種「告訴我在哪裡可以得到金釣竿」的方式給我引導,從買程式書要如何注意看Amazon review的評論篇數與星等,例如評論如果4.5星以上且review數量不要太少,通常就是不錯的書,上次介紹我也很值得關注的AI界歐巴林軒田老師,最近又給我介紹應用在資料分析上可以參考的書,跟我分享這是他們班一位很厲害的助教推薦的書,作者 Wes McKinney 是pandas的創立者欸(pandas是熱門的資料分析開源Python函式庫,反正連我都聽過就表示很厲害)!幾個月前我聽到這裡一定也是沒感覺,但在蔡炎龍老師的自學課裡打太多次「import pandas as pd」,聽到Pandas作者馬上抄下書名《Python資料分析 第二版》(Python for Data Analysis, 2nd Edition),這種厲害的書待我消化一下庫存,也要來一本。
學習的網就是這樣逐漸展開的。
昨天我問我同學Git和Github要入門的事,以免下次讀書會連記下聽不懂的地方都記來不及。我會知道Git,是因為王大哥鼓勵我們學會用這個,來和同學合作寫程式,他建議我們一開始很多東西就不要放在自己的機器上,要放在網路上,而Git和Github也是現在團隊協作的平台,不僅限於Python,我問同學需要買哪本Git的參考書嗎,同學指示先在本機裝git、申請github、git clone 把兩邊關係建立起來,然後就學基本的就好,像是怎麼把要異動的檔案add、commit、push(更新到github),還有上面若有新的知道怎麼pull回來,這樣就差不多了,他解釋說,這有一點像是Google Drive的Sync功能,就是本機端的東西和雲端的東西,通常的情況是你本機比較新,想更新上去雲端 ,讓這兩處一致,或雲端放了新的,可以戴回本機端,最後也是一致,但Git最重要的是在多人協作(多人可能改同一個檔案)以及版控(可回溯),這是它與其它雲端差異最大的地方,它是多人協作以及版控的系統,然後他講了非系統開發的人都如何處理不同版本,我聽到笑出來(就是講我和我同事們嘛...)。
若非系統開發的人,要多人協作時 都是這樣:A:我把你剛的那個檔案改過了一下,email (LINE)給你了,你再看一下。(在檔名後面加上日期)B:我又改了一下內容,回傳給你。(檔名上在最後面再加上_1)(然後改來改去,最後又說之前的某個版本好像比較好, 但已經搞不清楚之前是幾前了,若不一版一版對,也分不清楚誰改了哪裡了)系統開發團隊為了要解決這樣的問題,所以需要用版控的方式來處理協作,以及如果有哪些問題改壞了,有機會回溯到某個版本 (甚至進階工具,可比較兩版之間的差異在哪),所以得有git這樣的系統 團隊才得以在混亂中正常運作  不然兩個人改同一份檔案你蓋我 我蓋你 最後都搞不清楚了,另一個類似github的是gitlab,也可以參考看看,不同平台其實做的事差不多,底層都是git。
我接著又問,我還有印象有個叫「gist」的東西,他解釋gist應該只是作小片段的code的分享,比較像一些fiddle網站(讓我去google一下什麼是fiddle網站),如果我們要討論一個code,我用講的或我的環境,你不一定有,然後我可以直接在網站上解釋寫法 (當然這個例子是網頁開發),然後給你網址是可以直接run ,或看到內容 甚至協作,不過如果是python就用Colab了。他給我這個在fiddle上的例子: 

我同學雖然已經很會,但還是會看我寫的讀書會紀錄(就這系列),大讚我對API的理解正確,他說不知其他初學者是否能消化,但已不擔心我的理解力和學習進度,把我誇得都樂開花了。其實,這是王大哥講得清楚,讀書會同學的問題也問得好,加上我超會抓重點、打字速度很快都記得下來(對重要觀念很有警覺,忘記了還能回頭看),在裡面我的貢獻算少,你還是多擔心點我。聽我同學的話,看著這個教學(https://progressbar.tw/posts/1),試用過Git和Github的clone、pull、push,若要再做一次還不太確定可成功,不過,現在膽子肥了啊沒在怕電腦爆炸,這種畫面也敢開。 

我在讀《精通Python》的時候,讀得懂就一直讀下去,心裡有點虛的是我看懂了也未必自己會寫,但大不了就回頭查或多讀幾次了,但讀的過程中,遇到不懂的地方,我OS很多,但我同學連我的OS都有解。譬如說,我看到第五章裡,轉換型態的部分,舉了「'%d%%' % 100為100%」的例子,我真忍不住翻白眼想說這樣寫到底是不是在幫忙大家別看懂啊,我同學解釋說,有些例子的確是會發生,只是例子刻意舉得極端一點,如果主要寫command line的程式,要產出一些稍為有well format的輸出過程時(比如資料轉換處理 要把過程打出來),就會需要那樣的方式把過程印出來讓user (即使是自己) 容易看,就有時候會需要用到一些空格或怎麼的來作對齊,方便閱讀,只要有印象知道程式可以這樣控制就好,至少可以理解,也知道有方法做得到,需要再查就好了。
Murmur還沒完,我說了我最近讀到join,嫌棄它不自然(輪得到你嫌棄它嗎,它很多人用欸),但我想不自然的東西後面應該還很多,我同學的解釋這樣的:他問我是不是覺得被當分格符的,應該放後面比較合理?他說其他語言,都是放後面比較常見,然後介紹我「程式設計師好朋友」--stackoverflow,幫我的問題找到以下的連結,介紹這個網站是有千奇百怪的難解問題,用Google找,最後差不多都是在這個網站找到,但內容值不值得參考,要看分數評價 ,不能太少 或 沒有綠色打勾,有些解答,假設有500個positive ,但是沒打勾,表示可以解,但正確來說,不是一個意義上最正確的解法(理由通常非常深入),凡人會覺得,可以解決表面問題就好,但神人覺得意義不正確,不能代表正解。(以上引述對話內容,怕對話不見,不記下來可惜)
https://stackoverflow.com/questions/493819/why-is-it-string-joinlist-instead-of-list-joinstring
這個讀書會雖然只佔一週的兩小時,但不得不說,有人引導加上自己動手做,有很多待辦,有很多收獲。
分類:學習

評論
上一篇
  • 下一篇
  • 更多文章
    載入中... 沒有更多了