2012年8月24日 星期五

人人都可以寫手機程式! 可是然後呢?


App inventor 中文學習網
http://www.appinventor.tw/
App Inventor (APP 發明家?)是個用樂高積木方式組合程式邏輯的..IDE?
好處是整合了一些可能很常用的方法(讀條碼之類)
最酷的是可以和樂高整合(阿吉+樂高,這兩個關鍵字讓我想到某人..恭喜他走出一條路,雖然我覺得他可以走得更好更酷..)

Sencha Touch 介紹
http://www.phpchengdu.com/html/news/2010/0706/1302.html


Titnaium

PhoneGap

Mono Touch (阿..我好懷念 C#)


以上都是讓"人"繞過 native code 開發手機程式的方法
也就是不用寫 Java, (像阿婆裹腳步長的) obj-C 開發手機程式的方法

可是,以我觀點,那些都是用來自爽的
ok,那些架構、方式都是有用的,都可以達到他們自己的目標和傳達的資訊:不用寫原生程式,甚至不用寫程式就可以寫出 App
然後呢?這些東西對開發 App 真的有用嗎?


對於一個想寫出手機 App的人來說
這些東西都只能解決 "部分程式面" 的問題
也就是說,他們無法解決非程式面的問題,即使是程式面的問題,也不一定能完全解決
非程式面的問題包括美工、上架流程、裝置 debug等等與程式無關、IDE 內無法解決的問題
程式面的問題簡單來說就是敲敲鍵盤就可以搞定的部份,壞消息是,這些東西是 APP 主體,但是佔據的開發成本和開發時間未必真的很多
無論是Light App 或 Heavy App..
當然,不可否認的是,這部份真的是 App 是否有效、能成立的最大因素
但是,app 中這部份所佔據的百分比真的不高

其實程式真的沒有那麼難
花點時間,有清楚的邏輯,學一下語法,看一下論壇
大部分問題都能搞定
要開發app的話,程式真的是最不重要的一環
或者說,花在 coding 的成本並不很高

產品開發週期,可以非常粗略的分成三部分
(是的,請把 app 當成產品別當成 程式,兩者差很多)
規劃設計、建置執行)和上架行銷

規劃設計是弄清楚想要的產品是什麼
最好能順便想清楚目標客群、行銷方向

建置執行在 App 開發中就是做出符合規劃的 APP
這部份內容包括了畫面設計、程式規劃和建置

上架行銷就是讓 APP 通過上架審查,讓顧客知道、了解、願意(購買)使用


雖然很多人(特別是政府機關公務員)覺得程式發包就是說我想要一個網站或我想要一個app之類一句話就可以搞定的事情
但這東西真的沒有那麼簡單.. (喔,對活在農業時代的公務員也許真的很難以了解..)
以最近接的一個案子來說
甲方的要求是一個可以經由晃動手機隨機選號並產生聲音提示和對應圖片的'簡單" app
預算是機密 :p
一開始的規劃是3周,最後拖了2個月,光是最後的ui修改就花了快三週..
畫面很簡單,三個畫面,大致是 A <-> B <-> C 的順序
這案子從規格看真的非常非常簡單
其實也真的不難,但是..收益非常不如預期

時間流程大致如下
大概是7/1開始接案
7/7 第一版雛形出現,這時圖片、聲音資源都尚未收到,所以使用網路圖片+隨便的聲音
7/15 顧客提供第一版聲音 (.m4a)
7/17 雛形套入聲音,顧客開始對聲音順序提出要求
7/20 原本的 model 逃了,挑選下一個受害者(喂..
        第一次修改結果頁面
7/23 提出加入 youtube 連結功能
8/1 提供第二版聲音 (.mp3)
8/5 提供圖片,圖片比率 3:2 合適應用於全螢幕,但程式並非使用全螢幕,因此需要修改程式
8/10 刪除 youtube 連結功能,改成 fb 粉絲團
        第二次修改結果頁面
8/12 提出簡體版對應需求(有加錢)
8/17 提供第三版聲音 (.eml)
        第三次修改結果頁面
8/18 fb粉絲團也不要了
8/20 遭遇多語系同時開發問題,決定先搞定繁體版後,再套用成簡體
8/23 送出最終版
8/25 準備產生 icon 圖片等上架用資訊

當然我不是整天在做這案子(是的話,7/15我就會準備閃人了..最晚7/23吧)
但是整體耗費時間大約是 50 小時
其中,溝通+交通時間約 30 小時
明面的專案成本包括拍照、錄音、程式(含申請 Apple 帳號)
其中程式佔據百分比約 1/3-1/4 (還好是手機程式.. 桌面、網站的話…也許是1/8以下?)
簡單的算式,coding 成本佔據專案成本約 1/6左右

為什麼會這麼低?
因為 coding 是工具而非產品
他是必要條件(沒有code,那些圖片、聲音無法產生關連和互動)
但他的必要依賴於所有相關元素的互動而存在
這就是說,設計比 coding 重要
code 一個完整的設計並不難
難的是弄出完整的設計..

以此案子來說,相對完美的作法會是
規劃設計:決定產品方向、取得產品資源、決定 App 動作流程和畫面設計
建置執行:建立 app, 連結搖動、圖片、聲音和畫面設計
行銷:交給 Jobs就好(Y)
以上是 PG 最喜歡的專案流程,不過實現可能性太低了..
原因很簡單,沒寫過程式的人永遠不知道什麼叫做程式規格..
這點要感謝 MS 在 Office 上面的成功
現在很多人(不只是公務員)對於程式/網站開發的工作看法都是:你就把這個方塊放到那邊去,把yahoo網頁上面的那個格子貼到那個畫面,這麼簡單就可以了
順便幫我換一下 google map上面我們機關位置圖案,幫我放個國旗,周邊道路弄成比較顯眼、漂亮的顏色
對於程式設計師來說,以上兩句話的吐槽點真是他媽的無敵多

顯眼、漂亮的顏色?紅?紅色有255階,哪一個比較漂亮?
周邊?50 m? 100M? 地圖縮放比不同時,要不要出現?要多大?
我就聽過要維持在地圖上有指甲大小的範圍的說法(google map可以從月亮看地球,這種超距離要不要考慮?那你的機關會比萬里長城還明顯喔… XDD )
放國旗?好啦..這其實不太難,調一下 icon就可以搞定,不過icon 是吃伺服器傳來的 json 資料設定的)
yahoo 格子阿、方塊阿我已經不想吐槽了..反正就是用 word 想法在看網頁開發就是了(如果寫個 vba 讓他們自己用word 寫網頁,不知道有沒有搞頭..)

回到原題
程式規格說實話,很複雜,不是很難理解,但就是很複雜
一個一個說起來很簡單,但是當要說的東西太多時
PG 問的煩,PM 傳得煩,顧客也會覺得這家公司很白痴
但是沒有這些看似很白痴的大量規格,程式就是不能跑
不然就是被顧客覺得白痴(這顏色這麼醜也敢用?你們的人是色盲嗎?),然後就兩邊互罵白痴(PG: 這甲方他喵的才是色盲,這顏色明明就很讚)(結果原因是因為兩邊的螢幕色差太大… orz )

再回到原題
這些非原生架構 IDE 真的有用嗎?
我的看法是有用的,但是最大用處不是用來產生 APP
我不懷疑他們能做出 Hello World 或控制畫面轉換
但是當碰到他們沒有支援的底層工作時,可能就必須要 hack,而這樣一個 hack所需的資源(時間、精力、知識)未必會比學習原生程式少
這種事情常發生嗎?是的..就我看法,每次都會發生,原因不是使用者偏好這些方法而是他們的想法中多少都會有一些特點(沒特點的東西,也不會想開發吧)
而這些特點往往就會觸碰到非原生程式未支援的部份,因為是特點,比較少人用,相對重要性不高,被支援的可能性相對會比較低

以上是無用的地方
但是有用的地方呢?
有用的地方在於可以讓這些人的手髒一下
了解他們的想法要實現時,實際需要的條件和作法
http://www.appinventor.tw/helloappinventor 來說
步驟 1-4 都是 word like的 UI 設定
步驟 6 就有趣了
按鈕? click ?參數?改內容?
按鈕不是按下去他就會自己去顯示的嗎?

第二個例子 http://www.appinventor.tw/barcodescanner
按鈕之後,相機不是應該就直接掃描條碼嗎?
為什麼要叫那個 BarcodeScanner.DoScan ?
掃描後結果不是就應該顯示在桌面嗎?
為什麼可以選擇送簡訊?撥號?

有了這些認識後,這些人才能了解程式設計不是叫程式設計師去設計
而是叫程式設計師實現他們的合理設計
雖然..我對於那些只會叫程式設計師去設計的人來學這些東西的機率覺得很絕望
但是,對於有自己的想法和設計,只是沒有程式設計基礎的人
我覺得學一下這些東西不錯
見效快,方便測試想法、了解瓶頸
等到確認想法和設計可行後
再來找人發專案或學原生語言都會比較好

2012年8月14日 星期二

翻譯軟體

這邊說的不是字典,是翻譯

字典軟體有查單字功能,可以作為翻譯輔助
但是有很多功能不夠完善
假設一個5000字的技術文章
開頭是 to learn about, 第2000字時也出現了,4300字也出現了
如何保證三個地方使用同樣字眼?
術語又是否正確?
如何保證沒有漏譯?
編輯如何確認?

翻譯軟體一般來說,會有幾種功能
  1. 字句分段,建立對應的多語區段,避免漏譯
  2. Term Database,字彙庫,詞彙查詢用
  3. Sentence Query,查詢之前翻法之類
SDL 系列軟體是我目前在學的
同一家公司目前有的產品線主要分為
SDL X
Trados 2007
Trados Studio 2009
Trados Studio 2011

其中,Trados 2007 包括了 SDL X
SDL X 應該是來自於一家被併購的產品
Trados 2007…不太熟,就目前所知,使用Traos 2007的似乎也不多
Trados 2007的存在意義/安裝目的對我而言只是為了 SDL X :p

Trados Studio 2009, 2011算是不同產品
Trados Studio 2011 相等於 Trados Studio 2009 Sp2
所用檔案格式與 Trados Studio 2009, Trados Studio 2009 Sp1有所不同
(可以當做 Trados Studio 2009 & 2009 Sp1已經消失?)


Trados Studio 2011 是主程式
裡面有許多相關程式
另外有一些不直接附屬於Trados Studio 2011的輔助程式

//以下尚未確認
SDL 的 Multiterm 是術語資料庫
Multiterm Extract 則是術語抽取程式,用於做成術語資料庫

AutoSuggest ,
AutoSuggest Creator,做成AutoSuggest 詞典

Passalo 是在地化工具,作用是抽取程式字彙做成i18n用文件
(i18n 國際化,對應的是 l10n 本地化)

使用注意
  1. 這些軟體很脆弱,最好給他一個安全、友善的環境,例如原生Window XD
  2. 軟體很脆弱,最好在安裝完成後給他一個隨時可以回溯的家,推薦使用Acronis..
  3. 軟體很脆弱,使用盜版時(聽說)有機率造成切換版本時的錯誤,有辦法的話,弄個正版
  4. 真的很脆弱,可能的話,買台專屬nb可能比較好 XDDD
SDL Trados Studio 2011 & Trados 2007 安裝順序
如果之前有安裝過相關軟體,先全部移除
安裝前建議先把 Office 和一些可能有關連的軟體安裝好(參見 SDL Installation Guide)
先安裝 Trados 2007
再安裝 Trados Studio 2011


//教學資源
象群網 (簡體)
http://www.xiangqun.net/forum?func=view&catid=2&id=4763

//名詞解釋
Translate Memory, T M包括兩個(主要?)來源,語料庫、術語庫
語料庫,根據句子建立的資料庫,如:how are you=你好嗎,使用WinAlign建立
術語庫,根據 words(單字)建立的資料庫,如:school = 學校,使用 Multiterm建立
對齊,Align, Alignment,將source text, translated text 對齊排在一起,用於建立語料庫
抽取,extract 抽取詞彙,用於建立術語庫
Concordance search (相關搜尋)從術語庫、語料庫中搜尋





2012年8月11日 星期六

專案開發 成本、流程與地雷


之前看過一篇文章討論 app 開發成本的
http://www.inside.com.tw/2010/10/17/how-much-to-develop-a-great-app
裡面的說法大致是,一個 app的開發成本不是只有app最後版本的成本
還要包括開發過程中的開發成本
例如,app最後呈現出來的版面/ui並不是一次就好的
過程中可能有上百種嘗試
上百種嘗試並不誇張
版面配置三種主要修改,對應這些配置,各種UI/按鈕/圖片的修改隨便算一下就會超過上百次
theme plus的開發過程中,光是logo就出現了30種嘗試,而那只是一個沒有任何ui的圖案
主題、地圖、地標的顯示也都至少有過 3 種不同的嘗試作法

ui/版面配置調整後,背後的程式碼當然也要調整
這部份的調整主要是在版面配置改變時發生
不過當顯示內容改變(例如表格背景從紅色換成粉紅),這部份也要有修改
而這部份的修改並不會只是程式端
程式改好後,還要讓美術看過才能過關,除非是單純的色塊或文字大小的修改
如果是漸層這種無法直接抓色碼的修改,沒有美術把關,很能做到
除非美術能給 方向、起始色碼等..,當然另一種選擇是給圖片,大家都愉快
不過圖片會碰到另一個色偏問題(這問題不只是圖片會發生就是了..)

iOS device和mac的螢幕很注重色彩正確性
但是這一點在win上基本悲劇,除非是超高級螢幕+專業調色
這意思是,美術在他的 win 電腦上設計出來的東西
放到ios上後,感覺可能就跑了(攤手
然後又要繼續調整..(悲劇阿…

回到開頭的文章
最近接了一個小案子,真的不大..
基本功能很簡單,但是業主沒有其他具體想法
結果就是做了兩三板
功能越來越多,但是價格一開始也說死了
算是學個經驗吧..

以後碰到這種只有功能沒有版面的案子
先照成本開三倍下去
如果有版面和功能,開個兩倍
萬一他沒有要改功能或版面的話,在把錢拿來找美術或加入動畫功能
不然的話,對於這種非專業的業主,照成本開基本悲劇..