心得：AppWorks Demo Day #5

圖片來自 AppWorks，可以點此觀看 出場團隊簡介

前天我參與了 AppWorks 第五屆的 Demo Day，老實講，我很感動很佩服
我先在簡單此整理我所找到的資源：

• 實況轉播，錄影：appWorks Demo Day #5 現場實況轉播 | TechOrange
• 官方超精簡敘述：MR JAMIE : appWorks Demo Day #5 重點總整理
• 媒體報導：用App拚創業 台灣團隊孵出好創意
• 網路媒體報導：第五屆 appWorks Demo Day - Inside 硬塞的網路趨勢觀察
• 第四屆團隊自己人 fliper 的介紹：appWorks Demo Day #5 - 台灣最新的網路服務 part 1
• 有人開了一個 AppWorks Demo Day 5 評分表 的 Google Document 用來做討論
• AppWorks 的模範生學長 Alex 大大發表的文章：世界上有三種打嘴砲的人 - Hey, AC

---

我 加入一間新創公司 剛好滿一年左右
我參與過了三次的 AppWork Demo Day，心境卻有著非常大的差異：

• 第一次，可以說是創業前期，抱持的想法是要來找有趣的東西，思考尖銳，自以為看得很清楚
• 第二次，自身牽涉其中，嚴格來講，DEMO Day 前就是一直寫程式跟 DEBUG，這件事情一直做到當天清晨
• 第三次，我好像看得懂比較多東西了，我知道他們的努力，他們面臨的情況，另外一方面也能夠明顯看出他們哪裡做不好或是做得很好

我想要從另一個觀點來聊聊 DEMO Day，他能帶來的效應有：

• 「推」團隊趕快想出、做出東西
• 訓練團隊表達、行銷能力
• 提供團隊與其他人（創業者、專業使用者、創投、）社交、互動、甚至媒合的機會
• 整場 DEMO Day 就是一個大型的行銷活動，宣傳團隊跟 AppWorks 本身
  老實講，是否能藉由單一活動博得很多主流媒體的版面，我認為這不是那麼重要
  好的東西，透過日積月累的動腦筋行銷，自然而然就能夠推廣出去，時間早晚的問題罷了！

就我的觀點，「創意」這一件事情並不是觀看 Demo Day 最需要考量的地方
創業不是僅只是創意競賽，他其實最大的成分叫做執行力競賽
我甚至認為 Demo Day 上面呈現的「產品」本身也可以不是最大的重點
台上的講者所呈現出來的熱情、團隊的向心力跟合作能力才是最重要的
如同 Jamie 所提，需要 5-10 年網路公司才會逐漸成熟
對 Demo Day 的團隊們不宜太苛刻

這次的 Demo Day 中，各團隊的的商業模式較為穩固，甚至有很多人已經算是創業的小鳥或是老鳥了
就 presentation 這一件事情，我個人認為:

• 1/4 表現方式不佳或是根本內容上就不恰當，很可惜
• 1/2 能夠講出自己想要表達的東西，不過表達方式如果想要說服我，仍然小有進步空間
• 1/4 表現佳！

抱歉，其實我自己很也毒蛇、苛刻啦…
但是就是曾經參與其中，我才會知道「把產品做好」以及「上台講清楚」這兩件事情其實並不容易做好
舉例來講，我的團隊講的其實也是屬於還不行的那一群（上台的版本算是可以了，練習的時候，我聽得想切腹）
（可以參考這篇文章：心得：PIPOSEA @ Appworks Demo Day #4)

取其優點學習，注意其缺失叮嚀自己
隨時問自己「如果是我的話，我會怎麼做這一個產品？我會怎麼 present 我的東西？」
這是我希望自己能夠做到的
新創團隊需要鼓勵，可以批評，因為這也是讓大家成長的好方法
如果只是無建設性的謾罵，就可以省下來了

備註：
最近團隊在進行腦力激盪思考下一個 Project
提 idea 時，總是會有讓大家大笑，覺得很蝦的東西
但是靜下心來仔細想想，卻又往往有其可行性
如果只是一直負面的打槍別人，那麼團隊大概也想不出、或是能夠理性的思考出比較有趣的東西了
創業的夥伴們，共勉之！YO！ （直銷？）

引用：Meta Class In Python

利用這一次在追 OSDC 影片的時候 (講者：Hychen 大大，Blog)
順便來搞懂一下到底什麼是 Meta Class
之前在 這裡 看到 Meta Class 的介紹的時候
其實我因為當時功力太淺所以看的似懂非懂，帶過去後過一陣子就忘光了

而事實上，我們的好朋友已有提供 Meta Class 的最佳解答了：

What is a meta class in Python ?

不用懷疑，就直接閱讀有 855 （增加中）個正面評價的答案吧！


另外澄清一下
在 Django 當中確實也有使用到 Meta Class 的方式來達成一些目的
但是 Class Meta: ... 的使用方式 與 Meta Class 無直接關係就是了 （Ref.）





# 順便講一下無關的東西
在 PIPOSEA的開發過程中
由於 API Server 的性質 + 對 Python 不熟
所以我目前採用的 Framework 是極 light-weight 且簡單的 bottle 而不是萬能的 Django
當然，外面有掛上其他東西 ( gevent )

活動：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 !! 

筆記：Python: reload reload reload reload 大全

Python 提供了一個方便又惹人厭的 reload function
好處在於透過重新 reload 一個 module，可以進行程式碼更新
(不過在記憶體內的東西還是更新不到...)
惹人厭的地方則是 module 與 module 之間往往具有相依性
當 module A import module B ，且兩者同時有所更新的時候
reload(A); reload(B) 的結果不盡然與 reload(B); reload(A) 相同


關於這一方面的問題可以參考：
這篇中文介紹 英文原文 以及 一個解決此問題的專案
另外，使用此專案時要注意：


1. 由於 import 已經被暫時蓋掉，由 reload._import 執行
   所以是否真的要對所有的 modules 建立一個 graph
   取決於最後的目的
＃我個人偏好，只對自己寫的 module 建立 graph
   因為我不會吃飽太閒去改別人的 module
2. 如果使用 reload._import 某些外部的 module 的時候造成問題
   那麼可以考慮"早點" import 這些 module
3. 對於 monitor.py ，記得補上應該要在 import reload 後面的 reload.enable()
   該 module 的使用方式如下：
   import 該 module 後，製造出monitor.Reloader() 的 instance
   並且使用 .poll() 來詢問是否檔案有所更新



另外如果不考慮相依性，只是希望達到更新 module 便 reload module 的功能
也可以參考 對岸朋友的文章 原理就只是檢查檔案是否更新過


stackoverflow 上面也有類似上述的問題，不過解法是使用pyinotify觀察檔案的更新:
detect if a python module changes and then reload: 原文  程式碼

筆記：[Gevent + Bottle] How to detect client disconnection

已使用了 bottle 這一個小巧輕便的 framework 一陣子

加上了 gevent 提供的 pywsgi server 功能之後

算是一定程度解決了想實作出的long-polling的功能

程式結構可以不用有太大的變更，也不用過度擔心 io-blocking 的問題

不過前一陣子卻苦於無法得知 client 與 server 之間的連線是否已經中斷

翻閱 api 文件，皆無法找到相關敘述

甚至還找到有人寫了一個 test-wsgi-disconnect 的專案

來說明gevent好像還不行 ... 囧rz

儘管如此

自己經過土法煉鋼還是發現其實只要直接送資料出去

就可以知道連線是否還存在

但是這樣的作法，實在有點小蠢

無奈之下，還是決定爬一下 bottle.py 以及 pywsgi.py 的 code 

了不起就乖乖從 socket 面解決問題

爬 code 過程中，意外發現了這個 solution

之後我 trace pywsgi.py 後發現有這麼一行：

514 env['wsgi.input'] = self.wsgi_input

因此一切就迎刃而解了：

solution here:

 58     import select
 59     socket = bottle.request["wsgi.input"].rfile._sock
 60     time.sleep(10)
 61     r, w, e = select.select([socket],[],[socket], 0)
 62     if r or w:
 63         print "detect disconnect"
 64     else:
 65         print "not detect"

     Done !!

＃2012.09.03 補充:
如果在 59  行之前使用過 bottle.request.body.buf 類似的方法來讀取 HTTP POST 的資訊
那麼 59 行就有可能出現錯誤（無 rfile 此屬性）
原因我推測應該是因為 bottle 的 framework 順手拿掉了不必要的屬性

筆記：[Using pdb++ in Django] 解決 AttributeError: UnixConsole instance has no attribute 'old_sigwinch'

在django的環境下使用 pdb++ 時可能會遭遇到一些問題以致出現某些訊息：

AttributeError: UnixConsole instance has no attribute 'old_sigwinch'

看一下debug的訊息可以發現有問題的地方常常是因為設定了中斷點如：

import pdb; pdb.set_trace()

簡單的解決方法可以改為使用原本的pdp module：（不過就喪失了使用pdb++的意義了...）

import pdb; pdb.pdb.set_trace()

或是去找看看最後觸發exception的部分是不是因為 pyrepl 下的unix_console.py
如果是的話可以參考這裡的 Issue 解決方法，簡言之就是：

1. 將最後trace到的 unix_console.py 作一些修改
2. 重新再跑一次吧！

--
話說其實Django的Debug資訊真的相當豐富
不過為了更了解Django的運作，還是會需要使用原生的pdb或是 pdb++ 這種好物



Update: (2013.3.7)
pyrepl 版本 0.8.4 以後已解決此問題！

分析：來談談訊息、地點、打卡與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

: )

分析：Some LBS Apps: Vibe / AskLocal

在此簡單介紹兩個（有趣的？）LBS應用程式：




Vibe:  官網介紹 App 英文評論 香港新聞
AskLocal:  官網介紹 App 英文評論


用一句話形容 具地域性的匿名化廣播應用程式
在佔領華爾街的活動中被使用並且得到媒體的報導
用自己的位置去「撈」出周遭方圓的訊息其實還蠻有趣的
不過用戶的黏著性沒有說非常強，大都是建立在舉辦活動時
作者似乎也是這麼定位這個App


目前上去Vibe沒什麼新的資料
不過作者做出了另一個App AskLocal 想要達到不一樣的事情:


1.有了地圖的概念，使用者可以在地圖上移動觀看各地的訊息
2.讓人們可以決定一個訊息的能見度是在哪個區域範圍內，甚至回覆的能見度
（Ex:我可以丟一個訊息在台北101，限定只有方圓10km可見，然後在限定只有方圓100m可以回覆）
3.對訊息有了分類：event, service, thought,work,place,question ...
-->在地圖上可以看到不同的圖示
4.雖然仍維持匿名的機制，但是一個匿名者與匿名訊息是有綁定的
-->我看到某則訊息後，我可以點匿名者的圖示，再看到該匿名者有說過哪些訊息
    (也可以選擇不要公開歷史訊息)
5.被reply後的通知 ... ...


實際去玩兩則App，在台灣都沒幾則訊息，如果你上去玩玩
可能還會看到我發的測試訊息（但是你應該不會知道哪則是我發的XDDD）


對前者Vibe而言，在有特定活動時的背景下，能夠看到這些訊息還挺有趣的
nobody but real，你不用在乎他是誰，你只要知道他人就在你的周遭就好
你只要知道他在講什麼就好
少了registration 或是 login ，就是帶來了很流暢的使用經驗


而後者AskLocal很有野心
到處去走的感覺很暢快，App的名字說出了使用這個玩意的一個情境:去當地問問題
在AskLocal上的訊息雖然失去了綁定匿名者真實位置的特性
但是卻在地圖上提供了show出people的功能，能夠知道有哪些人在地圖上
（似乎不是Online而且沒有其他互動的方式...囧rz）


總言之，Vibe是真實的LBS app
AskLocal則透過訊息投射在某個使用者預期的Location以讓大家互動（虛擬的）


這兩個App目前都處於很萎靡不振的狀態
可能都是舉辦佔領XXX活動時才會熱絡#1
但是匿名式的社交方式，已經透過其他熱門的App讓大家感受到該魔力了


#1 FB-AskLocal 從這裡可以知道這兩個App大多數的使用情境是設定給佔領XXX活動使用的