[軟體] ImageOptim 影像最佳化
「工欲善其事,必先利其器」,一直以來是做事情的基本法則,若是長期要做的事情更能體會基礎的重要性!寫逍遙文工作室部落格已經超過三年半的時間,累積文章超過1000篇,影像數量接近8000張,WordPress平台給3GB免費空間,目前只用了1.2GB (41%),估計還能再戰3年!
「工欲善其事,必先利其器」,一直以來是做事情的基本法則,若是長期要做的事情更能體會基礎的重要性!寫逍遙文工作室部落格已經超過三年半的時間,累積文章超過1000篇,影像數量接近8000張,WordPress平台給3GB免費空間,目前只用了1.2GB (41%),估計還能再戰3年!
Apple今年推出的iPhone 6和iPhone 6+螢幕大小為4.7吋和5.5吋,這對開發者來說無疑是個新的考驗,因為先前我們只要在3.5吋和4吋做設計,如今一次多了兩款大小!以為一個專案要同時為四種大小做設計,事實上也是如此⋯⋯不過呢~Xcode也隨著iPhone進化,我們只要透過新的功能特性,即可簡化設計不同螢幕大小的程序!
寫程式同時也在設計(所以才叫做程式設計師),界面最好能夠直接在電腦螢幕上預覽,比起一維的程式碼,二維的畫面更加直覺!在新的專案中,我開始使用「自動佈局(Auto Layout)」技術,設定好後在四種螢幕大小顯示效果相當好,Xcode的各尺寸畫面即時預覽做得相當棒,且看一下我的一個畫面吧!
看得出來由上而下,分別是3.5吋、4吋、4.7吋、5.5吋嗎?我只是做切換預覽的動作,元件就依照我所設定來「自動佈局」!不太需要跑各種螢幕大小的實機或模擬器囉~當然如果是用code寫自動佈局,還是要編譯執行跑結果啦:P~
參考:iPhone 4/5/6 手指觸及範圍、[寫真] iPhone 5C、[寫真] iPhone 6 與 iPhone 6+。
一個想長遠發展的APP,有必要觀察使用者的行為狀況,很直覺地我們能透過記錄使用者點擊APP中的各個功能,經過簡單的統計與分析,就能一窺使用者對我們APP的喜好,於是持續改進來獲得使用者的支持!
在此我來介紹使用Flurry記錄使用事件。
這麼簡單記錄使用者行為的平台,Flurry發展得相當好,可以從2009年Q1到2011年Q4看出,於今日2014年想必有更多開發者在使用它! (繼續閱讀…)
工欲善其事,必先利其器。使用Xcode開發iOS App,首先就要了解其提供哪些功能,雖然我已經開發約兩年,但依然還是有些功能的英文名詞沒記,雖然說使用久了習慣就好,不過要是能多記得些英文名詞,在網路上找尋答案時,就能更順利看得懂高手所描述的解法。
這裡有張Xcode工作區視窗 (Workspace Window)圖,偶爾回來看一下,很容易就記起來了!
參考:XCode4一些使用經驗分享。
還記得兩個月前,參加「駭城市」駭客松大賽,兩天的行程要完成一個提案,可說是相當刺激,而且是個非常好鍛鍊程式技術的時候,第一次參加駭客松的我,聽到組長說自己已參加過好幾屆Startup Weekend,真是讓我眼睛為之一亮!
我們拿著客製化的Beacon把玩著,努力想把「集八點」的雛形做出來,在第二天Demo之前,總算做到能夠跟評審們互動!
不過此篇主題是我們所用的工具之一Google Doc,它的共同編輯能力太強大啦~這也難怪會有人拿來玩五子棋和圍棋。
看著我們參賽者陸續填寫聯絡資料,各種顏色在表單上移動編輯,第二次看到還是讓我很驚豔!第一次是在我去上海做案子的時候。
一直以來我都只看IDE中的crash log,沒想到這次要查看蘋果審查委員給的crash log檔案,這時候麻煩可大了,如果沒有弄清楚crash在哪,審委是不會讓我上架的⋯⋯看了它給的檔案,僅知道是IAP(應用內購買)程序有問題,儘管我怎麼測都沒有發生過!之後我陸續送了兩個版本,審委依然給我同樣的回覆,讓我不得不去找辦法轉譯crash log檔!
很幸運地我總算學會SymbolicateCrash來分析崩潰紀錄啦~
Win XP在兩年前被宣告捨棄,然而還是有許多人沒有意願想升級,我身邊就有一些例子。畢竟對於不怎麼需要電腦做事情的人,功能只要夠用就好,至於微軟一直推出升級版,這就是商業的考量囉~
就有一張繪圖在表示Windows世代的能力,如果使用過這一系列作業系統版本的人,一定很有感觸啦~~~
Windows XP看起來已經夠用了,不是嗎:)?Windows 7加強特色功能~Win 8的觸控功能似乎是多餘的⋯⋯來期待Win 9吧!有沒有發現?每隔一代就會出現穩定且廣為接受的作業系統呢~
參考:Windows XP十歲生日。
現在用Xcode開發iOS APP,我總是用Debug模式來執行,但是最後APP要上架,此時就會以Release模式來跑,因為這兩者環境有些為差異,我想知道在給使用者使用是什麼狀況,那麼我可以怎麼測試呢?
程式設計師或軟體工程師最不想做的事情之一,就是根據程式碼來寫成文件,而這文件盡可能要讓不會寫程式的人也能看得懂,這就非常不容易了!而要面對的現實是,我們沒有太多時間去把程式碼轉換成一般話語,好在專案中我們或多或少寫有註解,若能直接將註解轉換成一般話語,那麼就能節省許多時間了!
以下是AppleDoc把code轉換成文件的結果,是不是跟Apple官方的文件很像呢?所以才叫做AppleDoc囉~
Written
on 2014 年 08 月 28 日