Objective-C RestKit 2.0 的介紹與一個簡單範例

 

RestKit 是一個 open source 的 Objective-C 套件，支援 iOS 與 Mac OS X。
https://github.com/RestKit/RestKit

RestKit 幾乎完整包裝了所謂 MVVM 架構中的 VM，只要做些微調整，便可以輕易將 RESTful 的 API 轉換成 Objective-C 中的 Models。跟 Core Data 也進行了高度整合。

在 RestKit 中，只需要透過 RKObjectMapping，便可以將 API 回來的結果轉換成你所指定的 Model，這是一個簡單的範例，

有一個 Model - User 結構如下

@interface User : NSObject

@property (nonatomic, copy) NSNumber *userID;

@property (nonatomic, copy) NSString *name;

@property (nonatomic, copy) NSString *screenName;

@end

 

 

建立 RKObjectManager 以及 API 的 base URL

NSURL *baseURL = [NSURL URLWithString:@"http://[API HOST]"];

RKObjectManager *objectManager = [RKObjectManager managerWithBaseURL:baseURL];

 

 

 

 

透過 RKObjectMapping 建立 API 的 index 與 User 的 property 的對應，例如

RKObjectMapping *userMapping = [RKObjectMapping mappingForClass:[User class]];

[userMapping addAttributeMappingsFromDictionary:@{@"id" : @"userID", @"screen_name" : @"screenName", @"name" : @"name"}];

 

 

API 的結構像這樣

[{

    "user": {

        "id": 31337,

        "name": "Blake Watters",

        "screen_name": "Blake Watters"

    }

}]

 

 

 

將 RKObjectMapping 註冊進 RKResponseDescriptor

RKResponseDescriptor *responseDescriptor = [RKResponseDescriptor responseDescriptorWithMapping:userMapping

    method:RKRequestMethodGET

    pathPattern:@"[API URL pattern]"

    keyPath:nil

    statusCodes:[NSIndexSet indexSetWithIndex:200]

];

 

 

將 RKResponseDescriptor 註冊進 RKObjectManager

[objectManager addResponseDescriptor:responseDescriptor];

 

 

 

接著透過 RKObjectManager 的 getObjectsAtPath 呼叫 API 便可以成功轉換了！

[objectManager getObjectsAtPath:@"[User API URL]" parameters:nil success:^(RKObjectRequestOperation *operation, RKMappingResult *mappingResult) {

    // success

} failure:^(RKObjectRequestOperation *operation, NSError *error) {

    // failure

}];

 

 

很神奇吧！其中還有許多細節沒有解釋到，例如 HTTP 的 status code 也會因為 RKResponseDescriptor 的描述影響 getObjectsAtPath 的 success or failure。

 

其他細節只能實際使用才能細細品嚐了。

 

API with logined in objective-c(iOS)

 

The UIWebView will handle session & cookie.

UIWebView* webView = [[UIWebView alloc] initWithFrame:self.view.frame];

[self.view addSubview:webView];

NSString* username = @"";

NSString* password = @"";

NSURL* url = [NSURL URLWithString:@"https://ic.ridgefield.org/campus/verify.jsp"];

NSString* body = [NSString stringWithFormat:@"appName=ridgefield&username=%@&password=%@", username, password];

NSMutableURLRequest* request = [NSMutableURLRequest requestWithURL:url cachePolicy:NSURLRequestReloadIgnoringLocalAndRemoteCacheData timeoutInterval:30];

request.HTTPMethod = @"POST";

request.HTTPBody = [body dataUsingEncoding:NSStringEncodingConversionAllowLossy];

[webView loadRequest:request];

 

接著只要利用 UIWebView 的物件呼叫 API，那麼就是以登入的身分執行API。

Bootstrap 2.x to 3 升級小札

 

最近從 Bootstrap 2.x 換到 3，不過倒不是因為功能性的問題，而是我比較喜歡 3 的風格。

 

這是一個直接將 HTML 轉換的線上工具，左方表格也標註了大部分需要轉換的 class

http://upgrade-bootstrap.bootply.com/

 

當然我也以為這樣就好了，但沒想到還是遇到陷阱(目前發現兩個)

 

class alert 取消 alert-error class，必須統一使用 alert-danger

 

2.x row 的 span 效果與 3.0 row 的 col 效果不同，3.0 並沒有在左右加上一點 margin

2.x

 

3.0

 

以上，有遇到再紀錄。

IE 測試工具 IETester

 

IE 是所有網頁設計師的惡夢，這應該不用多說，但網站若不支援到 IE7，仍是會引起眾怒…

而 IETester 可以同時建立不同的 IE 環境，方便開發者們檢視，介紹給大家。(甚至到 IE 5.5 都可以，是要逼死誰…)

http://www.my-debugbar.com/wiki/IETester/HomePage

「學習新技術」有感

學習新技術的同時，你必須清楚知道自己究竟為何而學，新技術究竟幫你解決了什麼問題？而同時會帶來什麼問題？

如此一來，這才是有效學習。

摸新技術通常為潮流、為酷炫，這是程式人的通病，我也是，對任何新技術都非常好奇，但，這只能當做你接觸他的理由。

尤其是實際使用他、選擇他時，你不應該像個信徒一樣，一昧的只是想用。

當我問起：「他好在哪？」，你可以興致勃勃的說出十幾個理由；但當我問起：「他不好在哪？」，你卻連五個理由都擠不出來。

那麼，他真的這麼好嗎？

每種技術都有其優缺，絕沒有完美解決問題的技術，隨時保持自己中立清明的立場與態度，你才能真正學習到這個技術。

畢竟，技術存在的本質終究在解決問題上，如果新技術完美的解決了十個問題，卻引發了十個更難的問題，那真是本末倒置了。

當然，如果你摸新技術完全只為興趣，未來絕不會有用到的一天，那麼此篇文章對你來說沒有任何意義。

使 mac 左方 command key 成為 windows(in VirtualBox) 裡面的 windows key

若要使 mac 左方的 command key 成為 windows(in VirtualBox) 裡面的 windows key，那麼我們必須置換 VirtualBox default 的 host 位置，請參考下方連結。

http://helpdeskgeek.com/virtualization/change-the-host-key-in-virtualbox/

找軟體工程師，筆試、上機、面試之我見

(本篇談的主要是寫伺服器端的軟體工程師)

 

不敢說自己當面試官的經歷真的很豐富，詳細數字我不清楚，但應該有近百位，節錄一下自己的心得。

每間公司都缺人才，要怎麼找到好的軟體工程師便是一個課題。當然每間公司也都有其預算限制，但這不在本文的討論範圍內，本文主要是探討怎麼「找到好的」，而非怎麼成交。

最近剛好自己也成了求職者，因此更有所體悟。

 

關於筆試

我同意筆試，但筆試內容應該盡可能是原理題或是觀念題之類的，而非語法題。大部分的情況，程式語言只是完成任務的工具，而若語法只是翻翻書本便可以查到的，那麼這不應該成為試題的一部份，你必須考慮 Google 威能。

筆試要考的，是那些非一時半刻可以查到的，甚至要查都不知道如何下手的問題，有沒有辦法順利作答，必須取決於經驗值，應掌握此原則出題。

了解原理並能用於解答題目，勢必得經過一段時間的磨練，才能較容易找出問題的癥結點，或是用較為理想的方式進行，而非只會土法煉鋼。(當然，某些情況下，土法煉鋼不見得一定是壞事)

而觀念題可以知道一個人有沒有思考自己曾經做過的事情，如果僅談教科書上的那些，或是對此沒有什麼想法，那麼此人肯定無法自己成長，任何事情都要有自己的見解，才有辦法修正與成長，也才有辦法言之有物，言之有理。通常在觀念題我會較著重於如何整理程式碼。

 

關於上機

我題目主要測驗三種能力。事前需詢問求職者熟悉的語言(多種也無妨)，並準備好執行環境：

• Google 能力：出幾題經典，艱深，非正常人有辦法在短時間內解開的演算法，只要input跟output正確即可，當然並不會特別告知求職者要去 Google。
• 邏輯能力：出幾題 Google 不到，也不需要太過困難的演法算題目。
• 閱讀能力：給一段可以input, output的程式碼、執行環境與應用情境，把debug會用到的語法都寫在題目上，並請求職者找出問題關鍵。

已經是上機考了，是否靠自己想出，完成並不重要，畢竟實際工作環境下，沒人不讓你 Google 的。與其你很天才的，在30分鐘內想了一個80分的解法，不如你花10分鐘，Google 個 99分的解法給我。

不要重新發明輪子，這在業界是非常出名的一句話，但許多有點料的工程師偏偏就是喜歡靠自己，魔鬼永遠藏在細節裡，你再聰明都比不上過去前人所累積的智慧結晶。

如果用80/20定律來解釋，80分的解法其實只需要20%的時間，剩下的20分得花你80%的時間，相信有經驗的工程師都知道這並不誇張…甚至還低估了它…

 

關於面試

面試也能判斷出一個人的專業能力，我也會嘗試在這關探出個所以然(雖然面試最容易嘴砲)，畢竟你準備的筆試與上機，不一定完全等於一個人的實力。

當然面試主要是了解個人特質，更進一步的透過互動，了解每個人對工作的認知，對公司文化的認同，對責任的觀念…等，這就不多提。

 

如果這次的找人任務，主要是找出可以訓練的工程師，而非即戰力，那麼我會只面試就好，前兩項只是浪費彼此時間而已…

 

結語

廣義來說「人才」，指的是解決事情的能力優於常人，犯錯的頻率低於常人…等，如果能掌握這些原則，並思考「實際工作環境」下的狀況，便會知道該如何找到你期望的，不管你要找哪方面的人才。

 

當然，怎麼成交，怎麼留住人才，又是另一門藝術了。