顯示具有 facebook 標籤的文章。 顯示所有文章
顯示具有 facebook 標籤的文章。 顯示所有文章

2012年9月13日 星期四

活動:Facebook World Hack Taipei 2012


會場在 101 對面,風景好的很,還有真實的憤怒鳥彈弓可以玩

開發人員目測應該有 150 ~ 200 人,雖然活動很低調,可是來的人還是很多啊!


這是我第一次參加 Hack Day 類型的活動
活動的場地實在很不錯,風景好且放嗨歌寫 Code 真的頗熱血
我還記得我把憤怒鳥玩偶用真的彈弓射出界且又高又遠
旁邊的工作人員一直偷笑 XD
整個 Hack Day 的規格確有國際水準

為了這次的 Hack Day, 我從現有 全民電視 的專案
整理出了一個基本版的 Facebook Login/Logout API Framework
只要套上申請好的 Facebook Key/Secret 等等設定,就可以提供 client 端基本的登入登出等等 API 功能
這套 framework 當然是 open source 的!
不過現在沒有什麼價值,運作方式只會讓人覺得很詭異
因為專案中夾雜著剛學 Python 時所寫的 Child Code 以及許多我們平台綁定的格式及 Code
此 framework 目前 不推薦使用也不推薦觀看
希望接下來幾個月,能夠有時間整理出一個乾淨且泛用的 API Framework, 甚至提供 Long-Polling Class 的 Support …


此次的 Facebook Hack Day 活動,在活動開始前我們團隊發現幾件事情:
  • 這次的活動異常的低調,似乎知道的人很少,有相關討論的人也很少
  • 整個 Hack Time 只有六個小時
  • 獎項很不明,只知道最大的獎項是可以去跟 Facebook Team 見面
  • 之前其他地區舉辦的 Facebook Hack Day 系列相關活動的得獎作品,大都概念很簡單,如:製作生日快樂罐頭訊息的 APP …

仔細想想整個 Hack Day 對於 Facebook 而言,目的可能是:
  • 推廣自己 (Open Graph, Mobile SDK … )
  • 看到許多人開發 Facebook 相關的 App, 而且此 App 是對 Facebook 有所幫助的
  • 找到他們所感興趣的團隊
  • 有關讓 Developers 之間互動等等的目的就不再贅述 …

Hack Time 只有六個小時很明顯是不太夠的,從認識朋友、組隊、討論、實作、準備 DEMO …
這些程序恐怕就要花上一整天才有辦法產生比較完整的東西
所以 Facebook 不想要收到完整的東西?
我認為他們要的就只是一個對他們而言有創意的 Idea, 一個善用他們提供的資源所做出的產品
(且此產品要對其核心價值有所幫助)
Idea 是不是事先想好,甚至事先偷跑了都不是他們最 Care 的事情!
當然,如果只是把整個早就弄好的產品也不修改就拿來參賽,那就會完全失去了 Hack Day 的樂趣 …
這一切都取決於參賽者的心態跟目的


我們考量到既然要參賽,那就乾脆做一個自己覺得有趣,且 Facebook 一定也感興趣的 App
於是比賽前幾天,我們做了以下準備(偷跑):
  • 每天真的都在 Hack Facebook 的怪咖 CEO 負責系統設計,撰寫文件跟設計 DB 格式
  • 我開始整理 API Framework
  • 負責前端有時候還要跨後端的強者我同事則是開始玩 twitter bootstrap, angularjs …
  • 手邊有國際等級 APP 的 iOS 工程師,因為家裡有事情,臨時無法參加
簡單講,我們的 Hack Day 很不要臉的從週末就提早開始了!
由於萬事具備,比賽當天我們能夠當場申請新的 Facebook App, 即時調整 Serer 的設定
然後 Oauth Login 的功能,花幾分鐘改個設定就會動
要存取 Graph API 的 Function 早就寫好了,連要使用 Graph API Batch 功能的 Function 也都包裝好,可以馬上使用
(很遺憾我們沒時間申請網域跟處理 SSL 憑證,所以只有直接的 IP Adress … 造成了後來的一些問題)
當天 Hack Day 下午,我就看著文件拼命寫 Code !(事實上,前一天我還先寫了兩支 API)
最後我爆氣大概寫了 300 ~ 400 行 Python Code ,對我這種 Coding 嫩咖,已經算是突破自我了

Demo List


輪到我們團隊做 Presentation 時,遇到了很囧的事情:
  • 電腦被 似乎沒用過 windows 8 的 工作人員重開機,事先準備好的頁面都沒了 …
  • 遇到解析度跑掉的問題,整個頁面都看不完整
其實當下應該要拒絕馬上開始,堅持把環境處理好以後再開始 present
不過我們本身隨機應變的能力還不夠 … ,且就算扣掉上述問題,我們的整個 presentation 本身也處理不好
因此最後我們家的老闆跟怪咖 CEO Terry 拖了大家很多時間
Presentaion 過後,大家其實頗為沮喪,一個有趣的 Social Game 被 present 得很不有趣 Orz
仔細想想,其實整個 Hack Day 最大的重點是 presentation 是否能夠:
  • 表達出自己的 Idea
  • 說出此產品哪些特點符合 Facebook 的需求
  • 給大家看到產品完成的樣貌(但是不用全部沒關係)
亦即,很多產品非關緊要的細節其實不用實作 只要能夠完成基本要求(例如使用 Open Graph)得到分數即可
重要的還是想辦法在時間內讓大家印象深刻、理解我們想要作什麼!



遊戲首頁



進去後的個人畫面


遊戲畫面(先跟當事人抱歉,我幫你們做了馬賽克 XD)



最後的最後,很幸運的評審們應該知道我們在做什麼
我們得到了 最佳遊戲獎
禮物有: iPad, shuffle*2, $250 Facebook 廣告費用 …
最重要的是得到了 Facebook 的肯定
我們能夠在短時間內原創、設計,並且手工打造出了一個 Social Game: Memory Millionaire !
(雖然內含許多 BUGS)
這樣快速開發一個產品的過程(發散、收斂、衝突、妥協、爭論、配合),才是我們團隊所得到的最珍貴經驗!


之後我們會討論如何推廣並且讓大家都能夠玩到 BUG 比較少的這一款遊戲!
Cheers!


2012年4月7日 星期六

活動:PIPOSEA @ Appworks Demo Day #4




Video streaming by Ustream


我們的團隊大約在 1:23:22 開始進行 Presentation
上台的是我們 Team 的 Leader 同時也是老闆
我認為他的表達大約有 75 分的水準
但是投影片的質量實在還是不及格



我們大約在今年過年前確定了要做的東西及方向 我所負責的部分為 API Server 的開發
過年後在討論之餘,開始一步一步刻出整個框架
以及逐漸解決要面對的技術問題
事實上,我們想要做的東西還是一直在改 ...
因此大約到了 Demo Day 前兩到三週
外包給美工的圖以及DB的設計才完全確定


整個具體的產品真的就是這兩三個禮拜生出來的
我大約在兩週的時間內寫了接近 2k 的 Python Code
( 順便附上計算 line number 的語法: find . -name '*.py' | xargs wc -l )
要是加上之前練功用的 FakeAPI Server 以及部分 Django + Piston code
我的 Python Code 總產量大約有 3k ,算是從 Very New 變成 New 了


這兩週三個開發者 ( Terry, Joe, Cirtis ) 過著相當「燃燒」的生活
但卻在逐漸看著自己的產品「具現化」的過程中得到無與倫比的成就感
那種做自己想做的事情的感覺,是很好的
也是這樣的熱情(以及 Demo Day 的壓力)
讓我們至少能夠順利的完成產品的 Prototype


Demo Day 的交流時間時,有許多有興趣的人來到攤位看我們DEMO
有大四的在學學生(其實看得出來是學生!)
比我們稍年長的學長
作硬體的外國人(馬上交給團隊中的擁有 USC 碩士的 lenny 應付)
對我們很有興趣,一直問問題的大叔(還問到雲端AWS去了~)
... ...
整體來講,大家都覺得有趣,覺得還有許多可能性
被肯定的感覺還挺好的
我們也得到了一些回饋


小評一下,雖然我們的表現很手忙腳亂,呈現的東西還缺東缺西
但是至少向大家說明了一件事情:「Hello world !! We are PIPOSEA !!」



About PIPOSEA:


現在的時間是 2012 年,Facebook 已經差一步就統一地球了
這個世界上卻還有人想要做 Social Network ???


一切的緣起就如同 Terry 在馬來西亞時的遭遇 --「無法與身旁的陌生人互動」
這是大多數既有的社交網路的弱項
因為他們專注的是強化朋友與朋友之間的連結
而現存的陌生社交網路,過於強調「愛情」,無法廣泛的被人們接受
而社交資料的重建,更是造成麻煩


而我們想做的,只是想要解決人與陌生人之間互動的問題
透過 自動化社交機制、虛擬(實際)位置介面、邀約互動設計以及其他有趣的元素
讓人與人可以達到架構於虛擬/真實世界之上的互動


Enjoy It !! 



2011年12月9日 星期五

分析:來談談訊息、地點、打卡與app (1)


在前文「Some LBS Apps: Vibe / AskLocal」當中提到了兩款app
而會提到這兩者的一個原因在於他們分別代表LBS應用的兩種方向:
1. 訊息與使用者所在的地點綁定
2. 訊息與使用者在乎的地點綁定




我試著用一個故事來談談訊息與地點的關係:
  1. 某A外出旅遊時在台北101的ZARA說了一句:「啊!大衣真帥。」隔壁的路人隨口回答他:「不然咧。」
  2. 接著,某A到了阪急百貨的UNIQLO逛逛並且打卡:「某A在阪急百貨說-->哇!想不到UNIQLO的羽絨衣也不錯。」
  3. 突然,某A發現他的手機不見了,懷疑可能是在逛ZARA時搞丟的,於是他立刻打電話到ZARA請櫃台幫忙廣播:「誰有找到一個紅白條紋相間的錢包?」
    現場大家都沒有找到。
    過了不久有人打電話到ZARA說買衣服的袋子好像拿錯了,有一個不知道是誰的錢包 ... ...
  4. 最後某A找到了他的錢包 。某A回到家後他在自己的部落格對朋友們發文:「我今天在台北101的ZARA搞丟了錢包,好險最後找到了」



在1.當中,某A的訊息內並沒有很明確完整的地理資料
但是當某A位於台北101說話時
由於隔壁的路人也在同一個地點所以他聽的到這段話
更甚者,他還能夠回覆這段話... ...
事實上,在真實世界中,這則訊息已經被綁定在某A當前的位置
該訊息有以下的屬性:
  • 時間能見度只存在於說話的當下
  • 範圍能見度只有說話者的周遭
  • 使用者並沒有刻意在訊息中強調自己的位置
許多LBS app都是修改了真實世界中這樣一則訊息的屬性
來讓使用者在另一個平台上透過訊息進行交流
如前文「Some LBS Apps: Vibe / AskLocal」所提的Vibe
藉由修改了一則訊息的時間能見度、空間能見度
(設定了訊息的存活時間、可見範圍)
讓平台上的使用者能夠彼此交換資訊、進行社交




對於2.的情境,我先來談談「打卡」這一件事情
嚴格點的打卡限制是這樣的:
當你想要打卡時,你必須在人真的在某一個地點周遭
如foursquare就對這一點做了該有的限制
打卡只有在使用手持裝置的情況下,能對當前位置附近的地點打卡
這樣的限制使得一則訊息維持了一些屬性:
  • 使用者刻意的在訊息中強調自己的位置
  • 使用者人真的就在那個位置(或附近)
簡單講,打卡可能能透過你使用的平台做到以下這些事情:
  • 告訴大家你人在哪裡?
  • 告訴大家這裡有些什麼?你在做什麼?... ...
  • 告訴自己你在這裡(紀錄自己的行蹤)
  • 幫助你得到更多積分... ...   :P
而平台上各地點累積的打卡次數就可以代表了一個地點的熱度
越多次數代表越多人去過並且願意宣稱他在那裡




3.的情境是這樣,某A已經離開了101的ZARA
不過由於他想知道自己的錢包是不是在那邊
所以透過了ZARA櫃台這樣的一個平台去傳遞一則訊息給位在ZARA的人
這一則訊息有以下的屬性:
  • 使用者人正在UNIQLO且沒有刻意強調自己的位置 <-- 對使用者來說這目前不重要
  • 使用者希望這一則訊息能夠透過ZARA的櫃台被廣播,空間能見度限制在ZARA

儘管當下接收到此訊息的人沒有找到錢包
不過最後發現錢包的人,透過了ZARA的櫃台這樣的一個平台
取得了有人遺失的訊息,並且物歸原主

在這一個情境當中,使用者的真實位置與他所發佈的訊息沒有很強大的關聯
對使用者來說,重要的是他希望關注某個區域的人們可以得到他的消息
進而互動
(備註:關注某地區的人可能人當下就在此地區或反之)

有一些LBS的app就使用了類似的概念
如前文「Some LBS Apps: Vibe / AskLocal」所提的AskLocal
就架構出了這樣的一個訊息分享平台



最後提到4.,某A在一般部落格所發表的訊息有以下屬性:

  • 使用者人在家且沒有刻意強調自己的位置
  • 這一則訊息沒有所謂的空間能見度,使用者希望這一則訊息的能見度是給朋友看到
  • 訊息內容為自己所發生的事情,提及了一個地點:「台北101的ZARA」

對一般的部落格平台,這樣的一個訊息就沒有強烈的與地點結合了





我用了一個硬湊出來的故事
簡要的分析了訊息與地點的關係
之後當你看到一個LBS的app以後
也可以去分析看看他是怎麼樣的一個app

: )