Swift & Xcode 學習歷程 - Part 3 MVC

Swift & Xcode 學習歷程 - Part 3 MVC

講師建議所有的 iOS 都要使用 MVC 架構，即所謂的 Model, View, Controller。之所以分這些陣營，就是希望 app 在內部傳遞各種訊號的時候，團隊的各開發者仍然可以清楚他們之間的溝通管道。

1> Controller 可以直接送訊息給 model，沒有任何限制。 Controller 送訊息給 view 也沒有任何限制。

2> Model 和 view 之間是不能互相送訊息的。這類的訊息傳遞是不行直接發生的。

3> View 如果要送訊息給 Controller，如果是一個 UIBotton，可以想成是有一個 target 在 controller 裡， view 的動作就是直接射到那個 target。 而 ScrollView 則是一種「同步」的概念，裡面的資料則是用 delegate 的方式，讓 view 的資訊和 controller 同步。

4> view 是不擁有任何資料的，他只能 show 資料，這些資料都不寫在 view 的 class 裡面。舉例來說，如果你的 iPod 裡面有一千首歌曲，你要做個 list，而存放一份資料在 library 裡面，又一份放在 view 的 class 裡面，你就會有兩份資料。這不儘儘是效率的問題，而是這樣的設計概念是不好的。

5> 而 view 拿取資料的方式，則是用 data source 的方式，回去要求 controller 給資料。他也不一定一次要拿1000首歌曲的資料，也可以一次只要求10 首歌曲，如果使用者要後面的歌曲，則是之後再request 一次歌曲資料。

6> model 是 UI independent  的，所以他並不直接傳遞訊息給 controller。他用的是「廣播」的方式，而 controller 則是接收到訊號後，才會知道 model 有被更動過。

7> 這三個陣營是壁累分明的，因為這一套溝通系統一混亂 ，裡面所有的class 的溝通會全部亂成一團，這會讓其他成員相當難維護 code。

Swift & Xcode 學習歷程 - Part 2 先做一個 single view app

Swift & Xcode 學習歷程 - Part 2 先做一個 single view app

在台大資訊系統訓練班開始之前，看到資策會有開一個 ios app 的介紹課程，心寫來潮就報名了。講課的老師是一個常常出 iOS書的老師，現在常常接家教。

以下是節錄上課的內容。

1>  app 的 icon，可以放兩張圖，大小要放到 60 pt。

2> 做一個 single view app，可以單純用 view 來拉。而圖層的概念可以和 powerpoint 的圖層是相同的邏輯。

3> 左方的檔案列表中，可以看到圖層上下關係，也可以在這邊調整圖層。

4> 這一堂課，只有3小時，所以我們唯一能完成的 app ，就是完全不寫 code 在裡面的 app。

5> 不寫code app 是真的做得到的，而據講師所說，他為了教學試範，還真的嘗試上架這樣的 app，而且還真的上架成功。

6> 一個頁面，就是一個 viewController 去控制，如果你想要多加下一個畫面，就是加一個 viewController. 

7> 在 viewController 裡面，有一個 init 的選項，這個選項，決定了當使用者點進你的 app，一開始到底秀了什麼東西給使用者。當你所有的 viewController都沒有 init，那使用者點進去 app，就會是一片黑暗。

8> 一個任何 code 都不用寫的 app，最簡單就是介紹 xx 的app，而要讓使用者按下後能切換頁面。一開始先用 imageViewer 把圖案塞進去，然後再放一個隱形的 Button 在圖案上面。然後再用神奇的拉線 Segue 把這一頁連接到下一頁，這樣，你就能不寫任何一行 code ，就做出 app。

9> 另一種內建的換頁方式，就叫做  Navigator bar。最基本的款示就是  iOS 的 Setting 設定。他的想法就是一頁進來後，會蓋在上面那一頁，然後按「返回」，上面那一頁就會拿掉，回到前一頁。

Swift & Xcode 學習歷程 - Part 1 初探 Xcode 與 Swift

Swift & Xcode 學習歷程 - Part 1 初探 Xcode 與 Swift

在 Stanford CS193 的課程裡面，Michel Deiman 會把整個 iOS 分成四塊，但他在課程中有到，因為課程的時間，是不可能上完所有的，甚致連上完兩塊都有問題，所以，他會把教學的時間教放在 Cocoa Touch 那一塊。

從底層到表層，分別表列如下。

Core OS: 這一部分很底層，所以並不會教。

Core Service: 這一部分也是很靠近底層，所以也不教。

Media: 大部分使用者的應用都在這，影像、照片、聲音的應用都在這一塊，但這堂課沒時間講這一層的應用。

Cocoa Touch: Multi couch, Map kit, Camera。這些應用是這一系列課程主要會說的東西。

而這堂課程會用到的

工具: Xcode8

語言: swift

framework: Foundation, UI kit

Design strategy: MVC 

而最最重要的，就是 Design strategy 一定一定要用 MVC。因為你不用 MVC 最後，只會讓你的 app mess up。

— 開始做計算機 —

每一次的第一堂課， Michel Deliman 都會快速的做出一個計算機的app給大家看。因為他製作的速度真的太快了，所以大家會看得很有意思。不過同時，他在講話的同時，手是不會慢下來的，所以建議各位有雙螢幕的話，還是另外開一個視窗，或是用另一個裝置去看影片吧。

這一點，我倒是蠻佩服現場的學生，因為當你在現場的時候，是不可能喊一聲「時間暫停」，然後老師就定格了，你的大腦、耳朵、手，都必須邊看邊學，才有可能跟上 Michel Deliman 的節奏。

Swift & Xcode 學習歷程 - Part 0 前言

Swift & Xcode 學習歷程 - Part 0

好久沒用 blog 了，接下來，會有一系列的文章，去紀錄自己學習 Swift 和Xcode 的歷程。而這一系列的文章，只是單純的紀錄自己的學習狀況，並不會有教學。如果是想切磋 Swift 的朋友，歡迎來信。

我自己使用的教材，是 Stanford 的 CS193，這一堂課的教授，使用的英文並不難，非常好理解。

而所謂的 part 並不是一天一天的紀錄，在一開始的時候，雖然想把每天學習的狀況都記下來，但後來發現，這樣的開發紀錄方式，並不適合用在「程式語言」上面。所以，我決定把學習的紀錄，用一個一個不同的階段，當我自己往前進了一些，然後完成了一個小的 project，我就會紀錄下來，自己會了什麼。

希望在半年後，或是一年後，我可以很有自信的說，我會了 Swift。

寫於 2017.04.02

Lin, Marvin

Python - 一個膠水語言

在經過這麼多種的語言之後

我選擇了 python

經歷過 java、 php、 還有 objective-c 之後

我很確定的是我喜歡 python，勝過其他種的語言

現在蘋果的 swift 還沒整個定型，即使過了明年

我覺得還是會大輻度改動

這邊就先不說 swift了

那為什麼是python呢?

或許就和他的設計理念和後來被其他人補上的各種模組有關吧

所以現在的python 變成一種 「膠水語言」，因為各方人士的貢獻，所以大部分的用途都有人寫模組。

想要撈股票，有google、yahoo 的模組可以用

想寫 gui 也有，要輸出 圖表也有，要寫網頁後端也有三種以上可以選。

我想這個就是「膠水語言」的媚力吧

你想要做出個什麼東西，基本上都有現成的模組。

如果沒有現成的? 那就自己刻一個吧

希望有一天，我可以不用再當伸手牌，能夠做出一些模組讓別人使用。

至於為什麼選擇python3呢? 

和 python2 比，真的是缺東缺西，而且教學文也常常不能用，因為版本對不上。

但我在python3 的 cookbook 上看到一話話

「若你把眼光放到未來，你會發現 python3 提供了許多隱而不現的價值，比你想像的還要豐富」

但反過來說，python3 真的很不方便，因為很多模組都沒有。

嗯…

如果你看見什麼都沒有的天空，你會說什麼呢?

a> 這裡什麼都沒有耶！

還是

b> 這裡一點限制都沒有耶！

上菜- 職涯2

如果人生職涯就像是出一系列的餐。

那我應該呈現什樣樣的「主菜」給下一間公司的HR或是獵頭?

首先，我想跨國經驗、三種語言，這一定不能放在主菜的位置。

這些東西在我下一次交涉的時候，我會把他放在 前菜或者是甜點的部分。

最主要的主菜，已經不是這個了。

而其中交涉、文化差異、專案管理、排程管理，這些東西我也不會把他放在主菜。因為並沒有打算在下一個階段，朝向業務方面發展，所以這些東西也不會是主菜。

那，我想放的主菜是什麼呢?

我想放的是，分析、DOE等數據方式，找出現階段可以再往前推進的方法。

可惜的是，我現在這一套主菜，連個材料都沒有，也不知道要備的料是雞肉 魚肉 豬肉 還是牛肉。

上菜-職涯

這邊所說的上菜，並不能用中餐的概念來想。

傳統中餐，或是傳統的家庭料理，就是大家一起吃，所以每道菜的上菜順序並沒有很強烈的先後之分，也沒有所謂「單一主菜」的概念。

不過如果換成「法式料理」或是「和式料理」，這裡面就會有「單一主菜」，的概念。

所謂的單一主菜，在我粗淺甚致可能有錯誤的關念裡面，就是其他的端上桌的東西，雖然要做到完美，但所謂的「完美」是為了襯托出之後的主菜風釆。而主菜並不會這樣就結束，之後的甜點和餐後酒，就是為了「收尾」而出的。

和食事實上也有這樣的概念，不過所謂的先吃後吃，則會因為「米飯」而變形。現在的和食家庭餐廳，在出set的時候，會把主菜、味噌湯、小菜(通常是醃漬物)，放在一個餐盤上，一次上給客人。不過這個餐盤的中心位置，有時候會放主菜，但有時候也會放上白飯。米飯，是這個國家飲食文化的中心，他有著很難動搖的地位。

【自己的壞習慣】能在一個迴圈裡面解決，就不要用兩個-Python

【自己的壞習慣】能在一個迴圈裡面解決，就不要用兩個-Python

在我剛開始學著怎麼寫程式的時候，沒辦法一個步驟就把我想要的動作寫出來。

所以，一個迴圈沒辦法把我的想法做出的時候，該怎麼辦?

這時候，可以借鏡某個政治人物說的話

「一個便當不夠，你有試過吃兩個嗎?」

對！

就是用比較多的步驟組合，組合出我想要的東西。

一個迴圈我做不出來，那就先處理一步驟，然後我再用另一個迴圈去跑剩下的步驟，有時候二個做不出來，我還會再加上第三、四個。

用膝蓋想，我也知道這樣的效能會很差。

Python 用 cmd 執行和 IDE 來執行的效率差別

Python 用 cmd 執行和 IDE 來執行的效率差別

最近嘗試著用亂數的程式，來產生不同的英文詞組，然後來測一些項目。

小小的發現，如果你有開 IDE 來跑這個程式，大約是每200秒，會生出50萬組單字。

可是如果用 cmd 的指令，直接 python runit.py ，他的速度會提升近兩倍。只要90秒就可以生出50萬組詞。

如果要跑這種長時間，又不確定什麼時候會結束的程式。請務必用cmd 來跑，你的人生會有比較多的時間。

就像這個程式，已經執行了151335秒，產生了1277000000組詞，可是他還沒結束。

泡沫破了，會怎麼破? 影響會有多大?

泡沫破了，會怎麼破? 影響會有多大?

泡沫破了，這已經是歷史上一直發生的事件。2000年一次，2008年一次，很多人說，2016年的前後可能還會再有一次。

那，如果真的有泡沫，他是怎麼破的? 他又為什麼會破。

在以前那個年代，internet 的能力沒那麼強大，這個世界上還沒有 google map, 也沒有 gmail或 webmail 的概念時。大家都是用outlook 或是 lotus notes 在收發 e-mail.