[Memo] 6lurk part – musicAnalysis

最近專題已經到了最後階段了,儘管如此,一天的工作量還是來到了12個小時左右。不過最令人開心的莫過於花兩天密集的Hacking把音樂回饋機制給實作出來了,說實在的自己自從暑假經歷兩個月的前端洗禮之後,至少變得比較了解「一點點」Javascript及jQuery了,也比較有能力可以做出符合自己期望的東西。

第一次用 javascript+Youtube javascript API + jQuery做出一個音樂播放器,而基本的輪播、單曲重播、上下曲切換…等功能都有了,只是歌曲的部分是我們分析使用者在Plurk上面的情緒後(星期一到星期日),利用自訂好的類別搭配 last.fm API 來得到該類別下當紅流行的top20首歌曲資訊,然後我們再從Youtube上面抓到最相關(因為它們串流檔這麼多,所以我們只找最相關的那一個)的影音串流回來,最後組成我們播放的卡帶,就可以任君挑選啦!

也許大家會覺得這種類型的網站不是很多嗎?那我們為什麼還要再做一個類似的應用?當然是有原因的,因為並沒有一個網站(可能是我不知道),會依照他的用戶提供量身訂做的音樂,而我們一來使用最接近使用者的社交資料來當做分析的來源,二來是利用一些統計上的分類來把我們量化過的分數幫使用者做一個情緒上的分類並提供相關的歌曲,如此一來當然能夠給予使用者最貼近當下情緒的音樂啦。

而我們團員自行測試後發現,其實我們自己都有類似的需求,因為時常都不知道要聽什麼歌,只是希望能夠像聽廣播一樣打開就可以聽到歌,然後不想聽的時候關掉就好,是一種心境上的自由,也不要有太大的負擔,這樣子不是很好嗎?在這邊我要和大家介紹一個啟發我很大的網站StreamDrag,它也是一個利用Youtube為資料來源的音樂播放網站,它有一個很棒的哲學(Philosophy),也很貼近我們設計的理念,在這邊引用這段話來為整篇文章做個結語。

Music amazes, music creates emotions and music pushes emotions.Music is the language of the world and thats why it should be available wherever you are. Therefore our biggest aim is to make music available wherever it is possible as simple as possible and to create new, innovative ways of listening.

[News] Music Lovers, Be Prepared To Fall In Love Instantly – Meet The New Shuffler

原文 From TechCrunch

現在已經有愈來愈多正面的聲音開始在討論「Shuffler」,一個利用全新方式來探索網路上音樂資源的網站。

TechCrunch

那一開始我們要先知道,Shuffler到底是什麼東西?

這是一個由總部設立於阿姆斯特丹的公司ーTone.fm所設立的網站,這個網站的特色就是在於它能夠從各式風格的網站中搜尋出多類型的音樂。

當你第一次瀏覽這個網站的時候,你可以選擇你喜歡的音樂類型(舉凡電子樂到嘻哈,或是古典搖滾到民謠都有)然後就可以即時聽到相關類型的歌,而大多都是你從來沒聽過的!而這個線上服務是利用Last.fm的API來幫助判斷歌曲類型的。)

from TechCrunch

這裡面的歌曲都是從網路上大量的音樂部落格搜集來的,不過基本上只要任何網站有RSS Feed的都可以被搜錄進來(像是Wordpress、Typepad、Posterous、Blogger…等),而在你選完歌後,螢幕上方的導覽列上有放置一些有特殊功能的按鈕,像是歌曲可以中途暫停、可以被轉寄、可以被發到Twitter上甚至是點選Facebook讚的功能,

而在那個導覽列上,你也可以利用類似上一頁、下一頁的按鈕來跳到之前聽過的歌曲或是跳到下一曲歌曲所在的部落格去。如果你把整首歌聽完的話,那系統會自動把你導向到同一類型但不同歌曲的網站去。另外如果你想的話,你也可以在菜單中選擇不同類型的音樂來符合你今天或是當下的心情。

from TechCrunch

無庸置疑,Shuffler在找音樂這件事上是很傑出的,雖然要從歌曲中找到你真正喜愛的還是要取決於你有多挑就是了。另外我希望能夠有書籤的功能來讓我記下我喜歡的歌,然後提供一個單一的介面來讓我能夠直接讀取那些歌曲來聽,只不過這類功能比較適用於像我一樣的音樂愛好者就是了。

Shuffler也維護了一個部落格清單,在一個月前上面約有1600筆資料,而目前就徵求使用者和發表者能夠多提供一些優質的部落格來充實這個清單,預計在短期內能夠成長到2600筆部落格資料。

總計來看,這真是一筆很大的音樂量呢。

而且從今天開始,SoundCloudYoutube也已經被加到清單內,而Shuffler也對外宣稱他們會多提供三倍的歌曲量來滿足使用者的需求。

所以還有哪些是新的功能呢?從今以後,你可以把特定的部落格轉型成音樂播放站,例說如你可以轉開Pitchfork來當你今天的收聽頻道吧,另外,也有一些網站已經開始嵌入Shuffler的頻道按鈕在他們的站內了,如TSURURADIO的右邊欄。

Shuffler由Tone.fm創立至今,也開始要籌募資金來使網站成長,現在他們正打算於年底前推出iPad的應用程式,同時也有iPhone、Android應用程式及具有更多功能的進階版本。

這些應用程式及進階版本的想法都是可能生錢的來源,不過Tone.fm說他們也會試著嘗試廣告的部分。

那如果你不建議的話,我現在就要來去Suffling了。

【評】

這個網站的想法其實和之前我們專題在發想的時候所想的類似,只是我們原本是打算利用Youtube上的各種影片來做到一個BroadCast Website,讓大家無論在何時登入這個網站的話,都可以即時聽到當前伺服器正在播放的歌,然後大家都可以為該影片、音樂做一個即時的回應,直到換歌的時候才刷新回應列表,然後重新開始。

然後不定時就會來一個藍調之夜或是鋼琴之夜,大家只要掛在站上就可以一直聽到各種歌曲而不用換歌,算是一個還蠻有趣的應用,只是沒有去實作就是了XD。

而這個網站目前還是利用自己選定的網站音樂來當做資料庫內的資料,要等到他能夠開放到讓所有的使用者都能自行推薦音樂來源的話才比較可能普遍化,甚至是讓使用者能夠有自己個人化的播放清單才會比較有搞頭,比較成功的例子就是StreamDrag,他是以Youtube的資料為主,然後使用者搭配一組個人帳號就能新建個人的播放清單,因為水管是從Youtube接的,所以至少在載入速度上面就比Shuffler快上許多。

不過雖然如此,他們能夠找出部落格上的音樂資源(不只是MP3這麼簡單而已),並把他們做分類及串接的這個動作是讓我覺得非常難以置信的,因為技術上的實作應該有一定的難度。

所以下次如果你自己有個自己的部落格,而且裡面有放很多音樂資源的話,應該也可以適著嵌入自己的按鈕,讓Shuffler來幫你做個客製化電台吧:]。

[News] Google Maps, Like YouTube, Get Instantized

原文 From TechCrunch

From techCrunch

「Gmail Instant」也許真的很有用,但什麼是Google下一個目標?「Google Calendar Instant?」還是「Google Image Search Instant?」好吧,這些設計也許真的也很有用。事實上,這真的很難想像即使是即時化服務也不會讓Google從中獲得少許利益。

啟發於Google Instant的服務及 Feross Aboukhadijeh 這名工程師因為製作了「Youtube Instant」的實驗性質的網站而得到Youtbue工作機會的故事,美國阿拉巴馬州籍的開發者- Michael Hart 使用 Javascript Library – jQuery 及 Google Maps API 打造出了一個輕巧好用而且會更新全世界各地資料的「Google Maps Instant」。而就和故事中的Feross一樣,Hart也剛好也正在尋找工作:P。

依 Michael Hart 的說法,這個即時化的介面會即時地預測你想前往的地方並產生秀出即時搜尋結果,而他所設計的這個服務則是花了4小時及193次的改版才打造出來的(他目前也正努力和Google Maps 上的圖標有關的問題,及使用iPhone或Andorid手機瀏覽時的一些功能)但是雖然可以使用 Google Maps Instant 來查詢你正要去哪裡是一件很酷的事情,但是我不認為Google Maps Instant能夠和Youtube Instant有一樣的機緣就是了:P。

【評】

Instant這個想法其實並不新穎,也有很多實作的例子,最常看到的例子就是使用者在註冊時的密碼強度測試,如下圖:

所以這個東西實作並不困難,網路上都有許多的例子都可以用Ajax的方式來達到這個目標,那既然如此,到底是難在哪裡?難就難在他搜尋的資料量太大,而非同步互動的時間相對卻要縮短,而且秀出的結果還要依使用者們的習慣依序排出。要做到如此困難的事情除了在演算法要下大量的功夫之外,還需要許多方面的支援才做的到。

僅管如此,Instant在UI上是一個很重要的互動模式,能夠即時讓使用者了解到目前的Query是不是會產生預期的結果,雖然在背景下增加了一些Query的次數,不過對於具有強大財力背景的Google來說,如何讓使用者開心才是最重要的事吧:P

[PHP] optimization for shortening the API calls

最近為了降低API calls,所以在Shark內加入了一個Method可以讓使用者自行依自己的需要來延遲整個程式的執行:

http://gist.github.com/309735.js?file=gistfile1.php

參數是所需延遲的秒數,0就是不延遲。

雖然這裡沒有什麼技術上的難度,講白點就是丟給sleep()去跑而已,但是我想討論的是它所造成的影響。先看一下下面的統計圖:



2/14和2/15是平常的情況,所謂的平常就是用無窮迴圈去跑Bot,只算「登入」和「基本檢查」這幾個動作,而已,就會拉高整個呼叫API的情況,非常的跨張,這就是為什麼北極冰山快融化完的關係,因為大家只要寄個信給Plurk官方就可以突破原先50000次的限制,要怎麼用就怎麼用,非常爽快。

但是再看看2/18和2/19的時候,這是我讓Shark加入了延遲的動作,我記得是設3秒鐘,夠誇張吧,直接下降到23000的次數了,你連寫信去Plurk的動作都省下來了,還有27000次讓你做別的事情,這樣不是很開心嗎!? (大約下降了78%..),真是從小處著手,就有很大的改變呢…(忘了說,使用者很難感受到機器人回覆plurks的時間差,一樣很快)

所以麻煩大家不要一直用「while(true)」或是「for(;;)」這樣子的東西,要用的話至少也要加個中止條件或是延遲,不僅可以減少系統資源的開銷,還可以保護北極熊不會因此死光…