疫苗預約平台表單 Tab 鍵切換焦點的使用體驗問題

Standard

前言

預約打疫苗正夯，有關注相關資訊的人應該對這個網站不陌生：COVID-19 公費疫苗預約平台（以下簡稱預約平台）。

不過這網站用起來不大順手、介面也醜醜的（雖然說關貿不意外 XDD… 但還是要感謝趕出這個系統救台灣的團隊啦 🙇），看到推特上、設計師朋友都有發文討論該平台的 UI/UX，作為一個前端工程師也來蹭一下熱度 (x) 發掘可以探討的地方 (o)。

那麼就進入正題，這篇文章想探討的是預約平台表單 tab 鍵切換焦點的體驗問題。

預約網站表單 tab 鍵切換焦點的體驗問題

先交代一下使用背景：平常我在填寫表單時，很習慣使用鍵盤的 tab 鍵（使用桌面版網頁進行操作）在表單的欄位間進行焦點切換，例如填寫完第一欄，就會按個 tab 鍵跳到下一欄，這樣就不用鍵盤打一打再換去滑鼠點再回鍵盤，能一氣呵成打完表單噢。

不過在預約平台填寫預約表單時，填寫完「身分證號」後，習慣性地按下 tab 鍵後，發現焦點卻飛到頂部 Logo 位置旁的一個隱藏元素：「跳到主要內容」了（那尼摳勒？）。只好摸摸鼻子移動滑鼠再點一次下一個填寫欄位繼續操作…。

放個影片展示一下這個體驗：（正如推特上有些針對預約平台的建議，某天就默默被修正了，我想這篇文章提到的問題也有機會被修好，所以放影片備存一下 XD）​​

Continue reading

同個頁面上多個 inline SVG 顯示相互影響，以及 display: none 的顯示問題

Standard

在製作網頁上我們經常選擇 SVG 格式來處理向量圖片的顯示，它擁有清晰、能夠放大縮小、可動態修改等好處。近日工作上同事遇到一個有趣的 SVG 相關 issue，想起剛好我過去也曾經遇過類似的問題，發現之前沒有筆記下來，雖然只是個很小的東西，還是決定整理成文章，方便日後回憶。

情境 1 – 錯置的 linearGradient 定義

假設我們有 2 個不同的漸層 SVG icon，以 inline 的方式放置在同一個網頁上：

Continue reading

「前端找工作 App」與 App Store 送審心路歷程

Standard

在新年來臨前，「前端找工作 App」終於通過 Apple 的審核了！至此，總算在 Android 與 iOS 平台都成功上架囉！

以這篇文章簡單紀錄一下這款 App 的製作心得與上架的心路歷程。

下載連結

喔喔！直接進入業配主題，先來下載連結。

創作契機

這是我利用業餘時間獨立開發的第一款 App side project，其實一開始是因為自己與身邊前端朋友時不時會注意前端相關的職缺，但要往返查閱多個職缺平台、再限定搜尋前端相關職缺頗麻煩的，加上現在經常用來瀏覽的載具是手機，操作上更不容易，於是就有製作一款搜尋前端職缺的 App 的想法。

剛好那時剛開始接觸 React Native 這個讓前端工程師也能跨足 App 開發領域的技術，於是就當練習兼創作，著手進行開發。

特色

  • 目前支援 fed.tw, Yourator, 104, CakeResume, wanted 與 meet.jobs 等多個職缺平台，會列出以 front end 為關鍵字相關的職缺
  • 可以以 Google 或 Facebook 帳號登入後，將有興趣的職缺收藏至收藏夾中
  • 可以在 App 中直接查詢「求職天眼通」上相關的評論與面試經驗
  • 可以將職缺分享至其他社群平台中

Continue reading

聊聊部份遠距工作的感想

Standard

最近加入了 Remote Taiwan 遠距工作 的社團，看到其他遠距工作者們分享了他們的遠距工作經驗，雖然我距離真正的遠距工作還很遠，不過我也來整理一下上份工作中嘗試「部份遠距工作」的一些心得。

背景

我是個前端工程師（Frontend Developer），工作經驗大概 8 年左右。

依據 Google Maps 估算，居住地距離上份工作的地點約 33 公里，搭乘大眾運輸工具要花上 2 小時/單程，使用公車 + 捷運 + 步行的方式往返，一天下來大概就花 4 小時在通勤上面。由於一些私人因素與計畫，8 年來除了其中 1 年有租屋外，都維持差不多的通勤時間與距離。

而在上份工作的後期，開始嘗試人生第一次的部份遠距工作經驗 – 每週五遠距工作。

長期長途通勤的疲憊


by mentatdgt@pexels

Continue reading

使用 Bitrise 搭建 React Native Apps （Android/iOS） CI/CD 系統的兩三事

Standard

很久沒發文，轉眼都一年了 XD 去年工作很忙，忙到健康出了點狀況，工作又突遭許多變動與意外（是不是要去改運一下…😭），實在無暇、也沒心情抽空整理文章。總之，這是躺在我的技術筆記堆裡許久的一篇文章，記錄了我用 Bitrise 搭建 React Native Apps （包含 Android 與 iOS）的 CI/CD（Continuous Integration/Continuous Delivery）的設定過程，最近有空來整理一下，讓它重見天日 XD

背景

由於審核機制、版本更新機制等先天因素，手機 App 的更新雖然不像 Web 這麼頻繁，但每次新增功能進 code 後，若是都要人工手動去跑單元測試、建置、發佈到 store 等繁複的工作也太煩人了，所以是該弄個自動化 CI/CD 流程來處理這些瑣事。

先前在工作上是使用公司自架的 Jenkins 搭配 HockeyApp 來處理 Apps 的 CI/CD 流程，當發 Pull Request 或是 merge 進 master branch 便會觸發（分別到 staging/production 等環境）、每日也會觸發進行 daily build，以便面對各種測試/發佈需求。

後來隨著 App 功能日漸複雜、產品線的增加，原本只靠一台舊款 Mac mini 搭建的 CI/CD 系統要應付這些快速成長的建置工作變得頗為吃力（光排隊等建置就飽了），於是便尋求其他的解決方案，而最終選擇的便是本文要介紹的 Bitrise。

App 是使用 React Native 進行開發的（沒有使用 expo），同時擁有 Android 與 iOS 版本（使用 CocoaPods 管理套件）。考慮到篇幅，本文並不會講到 React Native 本身的設定。

備註：我是個 Web 前端工程師，過去常使用 React Native 開發 Android 與 iOS App，但對 DevOps 與 App 原生開發的領域並不熟悉，若有講不對的地方請多見諒哦！ ☺️

需求

前端找工作

以 前端找工作 App 為例，雖然 iOS App 目前並未上架，但有成功地透過 Bitrise 將 Android 與 iOS App 分別發佈到 Google Play Console 與 App Store Connect 上，我自己就是用 Bitrise 來處理 CI/CD 的（要我用 Jenkins 我還真不會XD）。

Continue reading

2017 年度回顧

Standard

2017 已過去一週，迎來 2018。年紀漸長，對於跨年越來越無感了，不過還是簡單作個年度回顧，檢視自己的努力與遺憾。

Open Source Project Contributions

在 2017 年，總共貢獻了數個 pull requests 到近 20 個的開源專案中。

by Brennan Lashever, 於 Flickr

個人生性低調，對於實體社群交流興趣缺缺，但滿喜歡在業餘作一些 open source 專案的，看到自己的 commit 能夠幫助在世界另一端的人，並與他們交流討論出更好的作法，是一件很讓人興奮的事情哩。

Continue reading

作為一個前端使用 React Native 開發新產品的半年小心得

Standard

本文大綱

  1. 前言
  2. 團隊組成
  3. React Native
    1. 跨界踩坑
    2. 從 Web 到 App
    3. 升級 – 停看聽
    4. 團隊使用的工具與套件
  4. 其他：專案流程

前言

最近滿忙碌的，租屋約到期搬家、恢復長途通勤的日子，而工作上的話，則是團隊終於釋出新增社交元素的新版 App。雖不是什麼劃時代的產品，這個階段也只增加了一些留言討論、按讚等功能（接下來還是有其他新的功能的 :P），不過仍算是個小里程碑，忙碌的事情也暫時告一段落了，便想藉本文記錄一下這半年多*來使用 React Native 開發新產品的心得。

*半年多：實際上，新產品的開發期、基礎建設等約在三個月內，而前三個月是我輪調至 App Team 進行既有的 App 功能開發與維護

歡迎有興趣的朋友歡迎下載試玩看看！



我對投資沒什麼涉獵，也沒閒錢投資 😭 因此本文僅作為一名前端開發者的角度來記錄心得～

團隊組成

App team 團隊組成是 1 Director（也有參與前端開發）、3 名前端 (其中 1 名是 0.5 DevOps + 0.5 前端)、3 名後端、1 名設計、1 名 PM。

沒有 QA，也沒有原生 Mobile App 工程師。

前端的部份是純寫 JavaScript（React Native），不涉及後端開發。前端們原本都有用 React 開發 web 專案經驗。

另外有專門負責 Web 產品的團隊，配置有同等人數的前、後端工程師。

React Native

跨界踩坑

雖然沒那麼美好，但越來越好了

記得剛輪調去 App team 的時候，才剛要把專案跑起來就遇到很多問題，例如環境問題啦（node 套件、ruby 之類的）、Xcode 的設定問題、Apple Developer 的憑證等等的。

雖說現在要寫一個 Web 的前端專案，使用的工具、事前的準備也越來越複雜，但作為一個 Frontend，初接觸到 React Native 的專案真是頗挫折的，當時面對 Xcode 的 IDE 嘗試了兩天，當時的 OS 是 「…連要跑起一個專案都跑不起來，人生好難…」 ，結果發現是一個很蠢的步驟問題而已 😂

記得聽已經接觸半年的同事說，這時候其實 React Native 的專案開發已經不像更早期的「蠻荒時代」了。坑是越走越少，一些常踩的雷也因為前人的踩坑心得筆記累積而能夠避開。嗯，為此我也補了很多血淚筆記到專案的 README 中 😆

不過這些問題對原生 App 工程師來說應該是小菜一碟，如果團隊內有可以請教的 App 工程師那應該能少走上不少冤枉路 😆 若要更能隨心所欲地開發，也許還是得要補上原生開發的相關知識/人力吧。

現在若問我覺得用 React Native 專案的開發感想如何呢？以一個前端工程師來說，半年過去了，我覺得雖然開發體驗沒那麼美好，也的確會遇到意想不到的坑，但比起一年前，React Native 的確越來越好了，生態圈也越來越成熟。

Continue reading

使用 React Native 與 Amazon Cognito 實作 Google & Facebook 登入的功能

Standard

最近開始接觸 React Native 的專案了，能用前端技術跟知識同時開發 iOS/Android App 滿新奇的！雖然缺乏原生 App 的知識讓我踩了不少坑，其中不少還是非常低能的坑 XD！

這次實作的任務是要在 App 加上 Google/Facebook 登入的功能，而會員系統是建構在 Amazon Cognito 上面的，再加上 React Native 的相關套件 – react-native-facebook-login 及 react-native-google-signin 來實作 App 中的登入功能。其中有些設定上的眉角讓我花了不少時間嘗試，所以整理成本篇的筆記備忘囉～

本文大綱

本篇文章滿長的，所以先整理大綱在此，了解一下會介紹到的部份：

  • 本文的套件版本
  • AWS SDK React Native 與 Amazon Cognito
  • react-native-facebook-login
  • react-native-google-signin
  • 繼續未完的 Amazon Cognito 設定
  • 前端程式
  • 疑難排解
  • 用 Amazon Lambda 來做 Serverless API
  • Amazon API Gateway
  • 在 App 端補上註冊（register）的 function
  • Source Code
  • 參考資料

Continue reading

Pages: 1 2 3 4 5

淺談使用 Appium 進行 React Native 雙平台（iOS & Android）App 的 E2E 自動化測試

Standard

前言

先前在公司的產品流程中導入了單元測試的部份，而最近手上的任務是為 App 產品導入 E2E 測試（End-to-End Test）。由於目前的公司團隊沒有 QA 人員，因此每次產品新版 release 前都必須仰賴工程師自己與產品 Owner 等成員自行手動測試（Manual Testing），隨著產品功能越來越龐大，這個過程越來越曠日費時，也無法確保每次都能測到所有的項目，因此才會有導入 E2E 測試的想法。

本篇文章視角是給像我一樣的非 App 工程師（例如從沒接觸過原生 App 開發、準備踏入 React Native 開發的前端工程師）的經驗分享，又因公司 App 產品是用 React Native 寫的，所以也會提到一些 React Native 在搭配 Appium 測試時需要注意的一些部分（一點點啦）。這也是我首次嘗試 E2E 的測試，著墨不深，有不精確或誤導之處，一樣請偷偷告訴我以便修正文章囉 🙂

自動化測試中的 E2E 測試與比重

自動化測試（Unit test、Integration Test、E2E Test）能為產品的品質帶來更多信心，E2E 測試更是貼近真實使用者的情境下進行整體性的操作測試，「專注在真實使用者情境」－－嗯，聽起來 E2E 是很值得投資的事情！不過 Google Testing Blog 曾在 2015 年的 Just Say No to More End-to-End Tests 中提出一些不同的思路。

Continue reading

使用 Jest 進行前端單元測試

Standard

去年底在公司分享了關於使用 Jest 進行前端單元測試的議題，簡報版本在此，現在將其整理為文章以方便日後查詢與閱讀。

前言

從事前端工作也幾年了，先前有諸多原因都未能在公司產品上實行單元測試，例如做功能都來不及了，哪有時間寫測試、程式寫的太過耦合難以測試之類的。

我以前只在個人的 side project 上寫過單元測試，也的確感受到「測試能夠減低重構時不致無意間把原有功能搞壞就釋出的風險」帶來的好處。而這次算是我第一次在公司產品上導入單元測試，在測試的領域還算是新手，這篇文章便作為新手的個人筆記，有什麼錯誤的部份請偷偷告訴我 🙂

再提一下情境：我們使用 React + Redux 進行 SPA (Single Page Application) 的前端網站開發，是前後端分離的開發模式，後端團隊出 JSON 格式的 API 給前端進行資料串接。在 Scrum 會議中 Story Refinement Meeting 開 Story 的 Sub tasks 都會特別開 Unit Test 實作的票。

Why Jest?

為什麼選擇 Jest 呢？跟最常拿來被比較的 Mocha 來說，從 Jasmine 發展而來的 Jest 本身對於 React 的整合度挺不錯的（而且是 Facebook 自家的，釋出與修正速度可靠許多），而且本身也整合好了斷言 (Assertion)、Mock 等 Library 以及 Coverage 報告功能，還有滿特別的 Snapshot 測試，以及優秀的 watch 模式可以只測試當次更改的檔案，最重要是它的設定頗好上手的。

Continue reading