[星系漫遊指南]分享一個檢視近期火星天氣的小程式

dongsuo發表於2019-04-08

首先證件照:

[星系漫遊指南]分享一個檢視近期火星天氣的小程式 [星系漫遊指南]分享一個檢視近期火星天氣的小程式

Github 地址:https://github.com/dongsuo/marsWeather

線上小程式:

[星系漫遊指南]分享一個檢視近期火星天氣的小程式

1. 介紹

本指南目前可以檢視近日火星的天氣,包括氣溫、風速、風向、氣壓等資料,今後將支援更多功能以滿足漫遊者們進行星際漫遊的需求。 本指南的火星天氣資料來源於洞察號火星探測器提供的每日天氣資料,由於地火間惡劣的通訊環境,可能會有延遲、資料丟失等問題發生,請漫遊者們 DON'T PANIC. 一切盡在掌握中。

隨著地球宇宙空間探索技術的發展以及地球資源的日漸枯竭,必將有部分地球人繼承大航海時代探險家們的遺志,向廣闊的外太空進發。雖然目前星際航行技術還尚不完善,但是已經有一部分先行者踏出了第一步,為了向星系漫遊者們提供充分且完善的情報支援,本人特開發了星系漫遊指南這一小程式,該小程式可在任何安裝了微信(WeChat)的手持智慧裝置上使用,而無需考慮平臺相容性,介面簡潔大方,功能簡單易用,真正做到了即開即用,即用即走,實乃居家旅行,殺人滅口必備應用。

2. 緣起

這個小程式是源於在微博上看到 NASA 提供了一個檢視火星天氣的頁面,於是我就去扒了一下 API,做成這個小程式。程式碼很簡單,只是拉取API,展示資料。難點主要在於產品和設計,好在自己瞎看過幾篇關於產品和設計的文章,再加上 dribble 和公司設計師的幫助,算是把這個簡陋的第一版給上線了。

3. 技術

3.1 跨端開發

小程式的技術比較簡單,我用到最近大火的號稱跨端開發的 Taro 框架,一邊查文件一邊寫,好在功能簡單,沒遇到什麼難搞的地方,但是由於一開始沒有規劃好,導致轉 H5 的時候遇到了一些跨端相容的樣式問題,後面我會修一下這部分的問題,並部署 H5 版本。跨端開發還是有很多問題要注意的,有太多坑要踩,比當年相容 IE 麻煩多了,幸好我這專案還算簡單…… 對微信小程式這種強行製造割裂封閉的環境的行為,我只能說:始作俑者,其無後乎。不過技術烏托邦從來都是夢想,我們們對此也無能無力,只能提高自己了。

3.2 API代理

為小程式開發者所周知的是,小程式對 API 地址有嚴格的限制,要求必須為 HTTPS、指定範圍內的、國內備案的域名方可訪問,但是 NASA 的 API 地址怎麼可能在國內備案呢?於是我只好在 leancloud 的雲引擎上部署了一個用於代理的API,轉發我的請求,但是這樣一來這個低階的應用層的代理就會導致 API 變慢,而且免費版的 leancloud 在沒有請求的時候會自動休眠,這樣一來有時候介面就更慢了,但是往好處想的話,也算模擬了地火間高延遲的通訊環境了(笑)。

3.3 微信分享

小程式分享是可以設定分享圖片的,我呼叫了 unsplash 提供的免費介面來獲取一張隨機的關於太空的圖片,其實我本意是計劃用這個圖片作為背景的,但是實際做起來發現在隨機背景圖上很難實現完美的文字顯示效果,所以,最後放棄了這個方案,unsplash 的圖片介面只用於設定分享的圖片了。當然這個介面也存在備案的問題,解決方法跟 NASA 的 API 的一樣的。這個介面還存在的一個問題是 demo 版本每小時只能訪問50 次,超出次數會出錯,但是好在不會反映在前端 UI 上,後期再優化吧(希望 unsplash能通過我的 API 申請)。

4. 產品和設計

對於一個程式設計師來說,這個小程式遇到的最大困難其實是產品和設計,在這個簡陋的版本出來之前,我還用我淺薄的產品和設計知識做了一個更簡陋的版本,實在是慘不忍睹,沒臉拿出來見人。

4.1 設計圖

我在 dribble 上選擇的第一張設計稿是這個:

[星系漫遊指南]分享一個檢視近期火星天氣的小程式

好看是真的好看,而且背景是火星日落的實拍(調整過),但是這個卡片存在一個問題:卡片之外的部分怎麼辦呢?我很難去擴充套件啊,這個卡片連一屏都不到,很難拿來直接用的(也許是應用場景的問題)。於是我只好換了一個,也就是現在這一版的樣子了。最近在讀《Refactoring UI》這本書,我發現對於開發者而言設計還是一個比較難的事情,尤其是配色,雖然市面上有那麼多幫你選擇顏色的工具和網站,但是當真正要做一個產品的時候,仍然很難找到一個舒服的配色。

4.2 產品

關於產品我也想了很多,但是又要設計又要 coding,期間想出了很多產品上的設計,然後又不斷推倒,最終去繁就簡,只做了這樣一個簡單的版本出來。我覺得,一個產品迭代中很重要的一點是保持概念的完整性,建立了概念的完整性之後,就不要輕易改動,否則這些改動傳導到設計、開發甚至測試階段都會造成很大的效率上的損耗和工作量的提升,這也是為什麼產品經常改需求會導致開發的反感。這一點其實我是受到了《人月神話》的啟發,軟體開發的基本流程是需要嚴格遵守的,敏捷開發的思想和實踐也不能推翻這一原則:產品的概念完整性不能輕易改動。我以前對這一原則的重要性認識不足,最近在各種經驗和教訓中深刻體會到這一原則。

大道理

最後,我想說,這不是一篇技術文章,文中沒有涉及到什麼技術,主要是分享我在開發這個小程式的過程中的一些思考,涉及到方方面面吧,希望大家不要說我水,我覺得無論對於個人成長還是對於工作而言,程式設計師都不要把自己限定於技術開發這一身份,見多識廣才能更好地跟後端、產品、設計討論出更好地方案嘛,對個人而言,擴寬自己的思路也有助於個人職業道路的發展。更深一步地說,也有助於個人人生價值的實現,擺脫資本主義對自己個人的異化(強行裝 bi)。

相關文章