Uber該管,但要如何管?看看 San Francisco

Uber最近鬧得滿城風雨,收到交通部的罰單多到無需筆者於此交代發生什麼事情了。筆者Uber經驗,是在Uber於2010年於San Fransisco推出後沒多久(筆者當時還住在San Jose),就在一次San Fransisco downtown與朋友晚餐後第一次使用了Uber的服務,從此只要不是自己開車,在San Fransisco談生意或者與朋友聚會,都會選擇Uber了。
評論
評論

 

(圖片來源:Uber 官方粉絲團 )

Uber 最近鬧得滿城風雨,收到 交通部的罰單多到 無需筆者於此交代發生什麼事情了。筆者 Uber 經驗,是在 Uber 於 2010 年於 San Francisco 推出後沒多久(筆者當時還住在 San Jose),就在一次 San Francisco downtown 與朋友晚餐後第一次使用了 Uber 的服務,從此只要不是自己開車,在 San Francisco 談生意或者與朋友聚會,都會選擇 Uber 了。筆者是 Uber 服務的愛用者與支持者,但不表示筆者認為 Uber 可以完全無視不同市場的監理。不過,在台灣的發展,當筆者看到交通部對於 Uber 發出的" 交通部再次重申,Uber 應理性面對我國法律 " 中的這一句:

交通部重申,主管機關從未針對 Uber 宣稱之科技應用及預期效果表示反對,並樂見所有既有運輸業者及有意參與合法經營之業者透過新科技、資訊軟體之應用,提供民眾更多元、便利之使用環境,以提升整體運輸產業服務品質及乘車安全。惟任何外國人投資案件欲於我國進行事業投資經營,本應遵守我國公司經營法令及目的事業主管機關相關規範,依法申請經營並與合法業者良性競爭與互動,絕不會因 Uber 所強調之科技應用及公司願景而有所異。

簡言之,“ 交通部歡迎創新,但請遵守法令 ”。筆者不反對針對類似 Uber 這所謂"Sharing Economy" 之下的創新服務,必要時,需要被合理地規範與管制,但,是用目前的法令來管嗎?多數創新服務不會是一開始就要刻意挑戰既有法令的,是不是觸法或者遊走法律邊緣,多半創業家也不清楚,通常都是業務發展到一個程度,對既有的相關或相類似的業務產生挑戰與威脅時,政府才會關注這個問題,筆者也認為從保障消費者的立場,政府需要正視。但政府若要求要“適用既有的法令”來擁抱創新服務,也無法完全令人接受。筆者於此要先舉一個切身的例子,這是十年前,2004 年筆者將 Skype 引進台灣面臨到電信主管機關要求拿執照的經歷。

Skype 被監理的荒謬經驗

2004 年 7 月筆者(時任職 PChome)將 Skype 引進台灣,當時只有 PC/Mac 版本,也只有 Skype 對 Skype 的通訊,筆者就接到來自電信總局(那時還沒有 NCC)一位好朋友的電話,跟筆者提醒,電信總局正在" 關切" 這個服務,認為應該要受二類電信的規範。筆者反問,這是 PC to PC 的通訊,當時盛行的還有 MSN,Yahoo Messenger 等,都是這類的資訊服務,差別只在於 Skype 強調語音通訊,其他的是文字通訊。好友再提醒,就是因為是語音,又在網路上傳輸,屬於 VoIP 了,這是需要管制的。果然沒多久,不論是正式的,還是私底下的,都來要求要拿一張執照,因為有業者已經提出抗議。但很有趣的是,PChome 那時因為提供網路發簡訊與電子信箱的服務,已經拿到一張二類電信的執照,所以,剛好拿來應付,“竟”過關了。筆者用“竟”這個字,是因為,Skype 的 P2P 架構,跟當時二類電信執照中規範業者需要自建的設備,完全搭不上關係,但主管機關認為,反正你有執照就好交代,好辦事,管你什麼 P2P!只求有執照,可以被納入電信監理,但其實真正管不到,這不是很荒謬嗎!當然這是十年前的事情了,現在 NCC 被電信資訊網路匯流的洪流衝擊了十年,你看不到類似 Line 這類也提供免費語音通訊的服務,被要求要拿一張二類執照了。

所以自然當筆者看到“ 交通部歡迎創新,但請遵守法令 ” 政府監理單位這樣的態度,會質疑,拿既行的監理法令來管理,是最直接的方式,但是合理的嗎?

San Fransisco :Uber 與 Airbnb 發源地,如何看待 Sharing Economy

Uber(June 2010)與 Airbnb(August 2008)都是發源自 San Francisco 創新服務,也是所謂"Sharing Economy" 兩個代表性的公司。Uber 與 Airbnb 目前在全美或者全世界遇到的適法問題,San Francisco 個城市若不是最早經歷,也絕對不是最晚的。身為這兩個"Sharing Economy" 代表性公司的發源與總部所在地,San Francisco 如何看待監理這件事情?

2012 年 3 月 27 日,San Francisco 市長 Edwin M. Lee 宣布成立"The Sharing Economy Working Group",成立的宗旨,是希望用更宏觀與更深入的角度,來看 sharing economy 帶來的經濟效應,創新公司與監理法規之間互相影響與衝擊產生的問題,制定可合理與有效管理,但讓創新公司仍能持續發展的監理法規。筆者摘錄一段 Mayor Lee 的說詞如下:

“The growing ‘sharing economy’ is leveraging technology and innovation to generate new jobs and income for San Franciscans in every neighborhood and at every income level,” said Mayor Lee. “As the birthplace of this new, more sustainable ‘sharing economy,’ San Francisco must be at the forefront of nurturing its growth, modernizing our laws, and confronting emerging policy issues and concerns.”

San Francisco 成立這個 working group,是全美第一個對於"Sharing Economy" 有實際行動的城市政府,也可能是全球第一個。San Francisco 市政府首先認同 Sharing Economy 是可創造工作機會與收入,要"nurturing its growth"; 先正視有正面的經濟效應,再來看監理方面,不是用既有的法令來規範,也不是就地合法 ,而是要"modernizing our laws"。

另一段新聞稿中的說詞:

“The many local companies driving the innovative ‘sharing economy’ are here to stay and will be a growing part of our City’s future economy,” said Supervisor Farrell. “As policymakers, we must make sure our 21st century economy isn’t strangled by outdated laws and rigid regulations written in the last century that never envisioned what technology makes possible today.” 

一個市政府是從這樣的高度來看待新創產業與監理法令可能的共存共適,而不是只是口頭喊擁抱創新,卻只一味要求新創公司依循既有且單一領域的法令接受管理。這也難怪 San Francisco 延續之前以 San Jose 為主的矽谷,近年成為新經濟新創公司的大搖籃。

The Sharing Economy Working Group 的具體作為

San Francisco Board of Supervisors 於 2014 年 10 月 7 日投票通過一個被稱為"Airbnb Law" 的新法規提案,預計今年 2015 年 2 月 Mayor Lee 簽署後即可生效。幾乎全美主要城市是禁止居民提供短於 30 天的短期出租合約,這對 Airbnb 的業務本質是會造成很大的傷害。而 San Francisco 的新法規大意如下:

The San Francisco measure allows only permanent residents to offer the short-term rentals and puts a cap of 90 days on full-home rentals. It also requires residents to register and pay local taxes.

Airbnb 對這新規範的回應是:

Airbnb reinforced the idea that the practice is based on person-to-person sharing, stating that the measure “will give regular people the right to share the home in which they live.”

這是 San Francisco 的"The Sharing Economy Working Group" 一個具體的成效。當地還有反彈的聲音,全美其他城市也在觀望。這只是一個開始,San Francisco 市政府仍會面臨壓力與挑戰,但至少他們領先地踏出的這一步。

而類似 Uber 這樣的 ridesharing 服務,加州政府的" The California Public Utilities Commission(CPUC)"於 2013 年 9 月已通過新的法規,將其規範於新的"Transportation Network Company" 類別下監理 ,經營者需:Obtain a license from CPUC, Conduct criminal background checks, Establish a driver training program, and Hold a commercial insurance policy with a minimum of $1 million per-incident coverage。加州是全美第一個通過針對 ridesharing 新法規的一州,而 San Francisco 的"The Sharing Economy Working Group" 依循此新規範繼續討論 Uber-like 服務的監理。

再回頭看行政院副院長張善政對 Uber 的回應與主張:Uber 應歸交通部管、應符合台灣法規、不能逃避繳稅、 政府可檢討是否鬆綁相關規定第三方支付有良好政商關係與是台灣意見領袖的詹宏志跟政府鬥,法案還是零零落落,讀者認為 Uber 可以走到這一步嗎?真的是看看就好),跟 San Francisco 市政府的" nurturing its growth, modernizing our laws, and confronting emerging policy issues and concerns" ,讀者可自行判斷這其中的微妙差異。

要擁抱創新,自己就要有創新的精神,態度與作為 ,筆者認為 San Francisco 市政府做到了!

參考:

幾個在 San Francisco 的 Sharing Economy 新創公司的發展如下:

Sidecar: Launched in 2012 in San Francisco and now in 10 cities in four states and the District of Columbia, it employs thousands of drivers in the Bay Area.
Lyft: Launched in 2012 in San Francisco and now in 20 cities in 13 states and the District of Columbia.
Uber: Launched in 2010 in San Francisco and now in dozens of cities in 25 countries. Started with a black car service and added SUV and compact car services.
Task Rabbit: Launched in 2008 in Boston, it has since moved its headquarters to San Francisco. It has expanded to 17 U.S. cities plus the District of Columbia, and recently to London. Its workforce of thousands includes students, unemployed workers, retirees and stay-at-home moms.
Airbnb: Since launching in 2008 in San Francisco, about 4 million people have used the site. It tops 10 million guest stays in more than 190 countries worldwide and is worth $2.5 billion by some estimates.

 

 


蛻變敏捷開發組織並不難! AWS Amplify幫前端工程師從雲端快速建立REACT程式

台灣企業勢必需要明確轉型策略,搭配適合的雲端工具作為入場券,一來降低數位化門檻、二來減少摸索資源的浪費。
評論
shutterstock_1451794139.jpg
評論

打造敏捷開發流程、加速前後端工程師的協作效率,是許多企業在面臨疫情之後,認為亟需將彈性元素納入為企業文化當中。雲端運算服務領導業者 AWS 台灣,觀察到前端工程師主要負責處理最貼近用戶的 Web、行動應用程式,但他們往往需要與後端團隊合作過程,遭遇耗費大量討論時間,才能處理使用者介面事項。

為了降低前後端的溝通成本,有些前端工程師在掌握介面管理能力之後,開始橫跨到後端的伺服器、資料庫開發經驗,甚至進一步培養技能,成為能負責測試、安全、效能多面向的全端工程師。

有的人會透過 Side Project(利用業餘時間開發有興趣的專案)或參加 Hackathon(黑客松)方式,運用 AWS 雲端工具嘗試自行擴展後端,並建立簡單易用的工具程式。究竟,AWS 平台提供哪些資源幫助前端工程師擴展更多元的技能樹?

掌握入門教學!前端工程師如何將 REACT 程式快速上雲

前端工程師運用 AWS Amplify,快速在雲端建立 REACT 應用程式

事實上,AWS 的入門課程指出,運用 AWS Amplify 在雲端建立 React 應用程式及服務集,只需五個學習歷程,包含建立 React 應用程式、初始化本機應用程式、新增身份驗證、新增 API 和資料庫、新增儲存體。如果想快速了解 REACT 程式快速上雲的方法及示範教學,本文節錄 AWS QUICKSTART 學習資源內容,幫助前端工程師更快掌握重點。

首先,何謂 AWS Amplify?AWS Amplify 是一項全托管 Front-End Web & Mobile 服務,採取無伺服器模式,在後端建立、部署和託管單一頁面 Web 應用程式或靜態網站的 Git 型 CI/CD 工作流程,加速開發過程直接整合其他 AWS 服務。舉例來說,像是整合封裝好的 Library 資源、或運用一些 Components UI 軟體去配置後端,以及利用 Admin 的 UI 做資源上的管理。

透過 AWS 增加雲端技能 在組織發揮你的影響力

AWS Amplify加速Develop、Deliver 與 Manage流程

AWS Amplify 主要優勢展現在三大項工作階段,分別是 Develop、Deliver 和 Manage。Develop 部分可利用 CLI(Command-Line Interface)或 Admin UI 設定後端,使用 GraphQL 或 REST API 設定也是可行的,進而快速建構一個前後端專案。此外,開發者還能搭配 AWS 其他服務,例如使用 AWS Authentication 全托管認證服務,或 DataStore、Storage 等多項 Feature Categories。

到了 Deliver 階段,若是要透過 AWS Amplify 執行 Web Hosting 任務,可拆解出三個流程。首先是將 Repository 與 AWS Amplify 進行連結,這邊可整合 Amplify Console 提供的支援資源包含 Github、Bit Bucket、Gitlab、以及 AWS 的程式碼代管工具 AWS CodeCommit。一旦連結以後,開發者可透過自己的 Configuration,决定在各個不同的 Build 要執行什麽樣的指令,最後再透過 Deploy 方式,幫助工程師進行前端的 Hosting。

在最後一個 Manage 階段,開發者則可利用 AWS Amplify 的 Admin UI,以開啓瀏覽器方式,透過視覺化介面統一管理資源。例如在 Admin UI 介面左側選單,涵蓋 Content、User Management 的區塊,讓參與專案但沒有 AWS Console 權限的使用者,可利用 E-mail 方式邀請使用者進到 Admin UI,進行一些設定或觀看其他相關資源;甚至在 Set Up 區塊還有相關選項,例如要針對 Data Modeling 或 APP User 做權限管理,以及可連結到 AWS 其他服務。

運用開放資源 AWS Amplify Framework,打造高效能應用服務

AWS QUICKSTART 學習資源還介紹到另一個 AWS 提供的開放資源 Amplify Framework,一樣可利用 Amplify CLI 的方式,配置 Web 和行動應用程式的前後端,以及開發者需要用到的服務,讓應用程式更易於構建,並獲得安全、高性能的使用體驗。

Amplify CLI 一樣有支援多個不同 Category,例如較常使用的幾個 Comment Line,像是Amplify Init 指令做初始化或創建幾個不同資源;或是 Amplify Status 指令,隨時在開發過程查看各個 Category 狀態;甚至專案結束後,可利用 Amplify Delete 直接把 Amplify 所創建的資源做一次性删除。另外也可透過 AWS Amplify Client 利用比較抽象化方式,讓開發者直接利用 Component 實現想要完成的項目。

填寫表單 找到適合你的快速上雲服務與工具!

實際示範給你看,設定 React 程式可以如此簡單

假設前端工程師現在要快速部署一項有驗證功能(Authentication)還要搭配 Rest API、GraphQL、Analytics 等服務的應用,如何快速設定 React 程式?在 AWS QUICKSTART 的學習資源後半段,有詳細說明要啟動這類型專案的操作方法。

開發者可以先利用 AWS Lambda Function 結合 Amazon API Gateway 方式,創建出一個 Rest API,到了 Authentication 階段,則使用到 AWS Cognito 的服務,接著針對 GraphQL 需求,可利用 AWS AppSync 服務,以及最後如果有 Analytics 的需求,也可以串聯 Amazon Pinpoint 工具。Amazon Pinpoint 是一項彈性而可以擴展的行銷通訊服務,開發人員可利用 Amazon Pinpoint API 追蹤 Web 使用者的行爲,或是針對 APP 推送、電子郵件、簡訊點擊行為蒐集到具體的資訊。

在這整套流程示範之後,值得特別強調的是,AWS AppSync 是一項全托管的服務,能及時更新,甚至在使用者離線時仍可以持續去創建和修改數據。一旦設備連上線之後,這項應用程式就可重新連線,並接到後端同步數據,達成彈性、自動化擴展或減縮各式 API 的請求。

打造第一個你在 AWS 上的應用程式

AWS 最後強調,Amplify 是相當適合建構出一個靜態 Web、Apps 服務模式,例如說像是打造部落格,或者是一項 APP 內的代辦事項應用等;加上 Amplify 具全托管服務特色,可串聯上述 AWS 在雲端所提供的資源,都能在部署過程加以整合,加速開發流程及效率,並且有效節省開發資源。如果想用低門檻的雲端解決方案,其實前端工程師是能在開發流程更靈活配置資源,甚至為公司的商業、服務模式挖掘出創新價值。

了解更多:AWS 開發者系列