我們失去的 Web

Anil Dash 對過去美好時代的網路有精闢的描述。他舉了很多實際的例子,但主要的幾個關鍵點在此:

  • 過去的使用者產生內容(User-generated content)是可以分享、匯出、共享、指定公眾授權、資料整合與萃取的。現在的 UGC 是被限制在單一平台的「圍牆花園(Walled Garden)」,無法對 Web 的其他平台分享,整合,萃取。
  • 過去的線上身分是由個人網站展現,而不是仰賴某個中心服務。
  • 過去,若有人想要建立某個網路第三方登入系統,那會造成不亞於美國愛國者法案的隱私侵犯爭議。今日此類服務無所不在。

是的,這個 Blog個人網站網址是那個過去時代的遺跡。Dash 對現在的 Web 並不是完全悲觀的,他覺得現在的 Web 相較於當年,變得更普及,跟親近人;現在的大型網站架構更是軟體工程的巨大成就。但是,他認為我們不能忘記 Web 的初衷與核心價值,而現在的社群網站也該給幫助他們成功的媒介更好的關注 … 很不幸的,他們讓整個世代的網路使用者目光變得狹隘,無法理解 Web 體驗能有的更多創新與意義。

But [the social networks] haven’t shown the web itself the respect and care it deserves, as a medium which has enabled them to succeed. And they’ve now narrowed the possibilites of the web for an entire generation of users who don’t realize how much more innovative and meaningful their experience could be.

Dash 覺得,資訊產業作為一個產業,最終鐘擺會在擺向極端之後,擺向另一邊。只是在擺向另一邊時,新的 Web (或是根本不是 Web?)要面對的是超過當年 AOL 用戶數數倍的,習慣於封閉服務的網路使用者。

我個人比較悲觀;在網路中立性那一役時,我曾經聽過一句話:「Web 最後會變成和電視一樣,內容由大型媒體公司單方面提供,由廣告商掌握」。如果一切的趨勢都沒有改變的話,Web 最後的型態只能符合那樣的預言。而我們心目中能夠跨越國界、族群、與語言的新媒體,就要等到更久之後才會實現了。

最後,就跟那篇文章下面的留言說的一樣:沒有經歷過真的很難體驗,寫這個,很難不聽起來像碎念與感懷舊時代的老人 … 我也得承認,拒絕任何改變反而是妨礙創新,但若進步的代價是讓 Web 失去那些價值,成為充滿 filter bubbleecho chamber 與商業掌握的媒體 … 那恭喜大家,我們終於共同發明了,真正的 Smart TV。

Sort things out: code, project, and open source

As a pet project that kind of fit into the end-of-year mood, I spent some of my personal time re-releasing my previous code projects. In this post, I will announce the repositories I created and try to document additional works I did on those projects.

The projects are:

All these repositories are created with original commit history. Battling with git filter-branch is quite challenging but fun. I disassemble the work done in HTML5 Word Cloud in order to achieve maximum re-useability; by re-useability, I am also referring to having the code understandable and fixable by others. I’ve already use the Google OAuth 2 Login in an unannounced project and it works great. My goal is to eventually rewrote HTML5 Word Cloud and have it use the libraries from these individual repositories, with slick, better UIs.

These are the things I learned, and implemented:

Coding style, comments, and variable naming

One of the first thing I learned from working in Mozilla is to express thoughts to people, not computers, through code. In fact, in collaborative project like Mozilla, having people understand your code is way more important than having computers run them effectively. To achieve that, code written should be:

  • Promote shared understanding through unified coding style. Avoid magical syntax that could confuse the reader.
  • Also, promote shared understanding by annotating the work with comments. David Flanagan (Yes, the David) did amazing work in the Gaia code base on this, but sadly we failed to catch up that.
  • No secretive variable names; this is particularly rampant in the wordcloud2.js, and I haven’t been able to fix them all.

Testing and continuous integration

No, I’ve never wrote automatic tests for my projects until this commit. Before that, all the test is done manually by try out the actual product, or on manual test pages.

In WordFreq and Google OAuth 2 Web Client, I (re)wrote QUnit tests for most of the functionalities. The test coverage is not quite there yet, and for Google OAuth 2 library there are no automatic tests in PhantomJS because some tests must be done with a logged-in session.

I’ve also hook up automatic tests of WordFreq to Travis CI. It’s nice to know such service exists that could further reinforce the fork-commit-pull-request contribution cycle on Github. Unfortunately WordFreq fail randomly on the Travis CI testing VM.

Beyond browser context

Javascript does not just live the the browser. With WordFreq, I tried node.js this time. WordFreq is rewritten in a way that it comes with a synchronous interface and a asynchronous interface (powered by Web Workers). With synchronous interface, WordFreq is available as a npm package and is accessible on the command line. node.js is fun, I would love to use it for more stuff and move away from shell scripting. 🙂

Toward a real collaborative open source project

Putting your work on Github is easy, but nurturing that to a solid free software project is hard. You would just need to learn and adopt some software engineering practices besides writing great code, in order to effectively contribute to the free software ecosystems. These are my baby-steps toward that; feedback and contribution welcome!