over 3 years ago

今天路過 FB 看到朋友蔡校長寫了一篇政治文章,這篇文章的話題性之高( Visit 40,000+、Pageview 130,000+) 意外的衝倒了部落格本家。蔡校長不是不想解決,也一直為 Scaling 屢次搬家所苦,只是他遇到的狀況,會跟網路上能夠 Google 到的答案都不太一樣。剛好我在創業前,就是在 某科技網站 專注做 CMS ,這個主題還算略懂,所以打算寫篇文章來分享給有類似之苦的朋友。

(此篇文章特別的目標讀者是:針對使用 Wordpress 架站,並且苦惱一天到晚倒站的內容生產者)

Read on →
 
over 3 years ago

今天在 FB 上看到這篇文章 為什麼新聞網站長這樣。看了覺得有點手癢來回一下。

某科技網站 願意讓我用「某科技網站」的形式,分享 2011 實作該網站首頁和內頁的細節。所以這裡就不截圖了。

首頁版面的編排

Read on →
 
over 3 years ago

這篇是一篇有趣的觀察。主要的動機原先是因為想投稿 RailsConf 2014。填了報名表單以後發現有趣的細節,覺得可以分享,最後寫了這篇文章。

投這次 Conf 的動機主要是想省一點旅費。(投中者有一張免費門票 (750USD) + 500 USD 的補助費,沒中大會也會幫忙保留門票名額...)。不試白不試,所以也拿了一個小題目投了 CFP。

http://www.flickr.com/photos/xdite/12722098294/sizes/o/in/photostream/ (目前 CFP 的頁面已經關起來了,所以這是存檔畫面)

結果一開 CFP 的畫面我就笑了。因為界面和規則超熟悉 XD。

竟然是 YCombinator 式的徵題目方式 XD。( 去年秋天幫 Logdown 去投了 YC...)

傳統的 Conf 投稿流程

先聊聊傳統的 Conf 徵稿流程,以免讀者不太理解為什麼這件事值得記錄。

傳統 Conf 的 CFP 通常是這樣的:

第一次舉辦 (沒得投 CFP)

如果這個 Conf 是第一次舉辦的話,通常一般參加者是沒有參加 CFP 機會的。講者通常會是 Conf 主辦者到處去拜託他的大咖朋友們出席幫忙湊名單...。所以每個 Conf 的第一屆通常會很好看,因為 80% 以上的都會是大牌。

第二次以後舉辦(開始可以投 CFP)

如果這個 Conf 第一屆辦得好的話,很有機會隔年可以繼續再舉辦。這時候就會有可以投 CFP 的機會。通常投稿的格式只有一種:

1. 講者簡介:(你是誰?)
2. 主題介紹:(你想講什麼主題,內容摘要是什麼)

大概全世界 99.95% 的 Conf 都是這種徵稿方式。

所以取決會不會投上的因素通常也只有兩個。

1. 講者本人經歷以及背景
  • 當地大咖。上的機率就會 ++++
  • 社群活躍度非常夠。(有知名 opensource 專案或者文章非常多)
  • 演說經驗(有 meetup 演說經驗數次)
  • 任職的公司(如果公司有厲害的 scale 經驗,也容易上)
2. 題目本身

但用「人」去篩選題目,其實也容易出現誤差。因為一定會有其實題目很強,但講者是剛出道或是其他國家強者(有可能你不熟悉)。主辦者會試著想要捕獲落網之魚。這時候就是用題目篩...

不過主辦者會這樣想,投稿者也會這樣想。所以有時候真的節目單上會出現很厲害的 Title,但到現場發現演講者根本是一個什麼都不懂的新手在亂扯而已。

Rails core team member: Aaron Patterson 有一篇演講「算是」「半諷刺」的在 Talk 裡面塞這種現象:American Next Engineer。非常好笑,值得一看。

小結

然後結果就是我這樣一寫完,你就知道怎樣對一般 Conf 作弊了(?)。(不過不寫的話,你投稿失敗幾次後,自己通常也可以試出方法)。

不過很遺憾的,即便大家都知道遊戲規則和作弊手段,但還是沒有辦法有一套有效的機制防止。

RailsConf 歷年的 CFP

RailsConf CFP 我投過 12,13,14。12 是傳統的講者簡介/主題介紹。13 是講者簡介/主題介紹(但在第一階段禁止泄露個人資訊,進行海選)。14 是 YCombinator 式篩選。

YC 式是我寫這篇文章的主因...

RailsConf CFP 2014 ( YC Style)

備份的 CFP 辦法(存檔):http://www.flickr.com/photos/xdite/12722098294/sizes/o/in/photostream/

備份的 CFP 界面:

規則簡單的歸納是以下三點:

  1. 簡介你的 Talk ( Abstract )
  2. 敘述技術細節 ( Detail )
  3. 為何你有資格講這個題目 ( Pitch )

不過雖然必須要填寫(3)。但為了公平起見,還是嚴格禁止講者在此欄泄露個人資訊。

然後該份 Talk 可以選擇「Tag」。也就是大會這次有 Prefered 的主題。你也不必猜口味,直接選你的 Talk 趨向哪一種。

在第一階段的話,評審會 Review 你的 Proposal,然後透過盲問盲答的方式篩,由問答當中看功力。第二階段才會根據「你是誰」(該講者技術以及演講經驗決定是否入選)做篩選。

How YC do?

原辦法(存檔)https://gist.github.com/xdite/9173702

為什麼會說 RailsCFP 2014 跟 YC 很像呢?因為 YC 的規則更嚴問更多,其目的是試著讓創業公司以 360 度的方式審視自己並且線上 Pitch。

而且 YC 預設也會有一些偏好投資的題目讓你勾(比如說其中一個選項就是未來的媒體...)。

(填這份資料真的相當吃力,這份表格我們當初就寫了兩週多,還花了三天的時間錄了一段 interview 影片。還請朋友幫我們大修稿一遍)

審核程序

填完之後,( HN 上的謠言說) YC 校友會線上觀看這些 video 進行投票,高的會進 review。然後,YC 的 board 再視對你感興趣的程度線上問問題(要自己刷 HN),要你回答。

我們的成績是自介影片 1:30 左右平均被看了 1:08。有 8 個人看。然後 PG 本人寄了兩次信向我們要數據...(美國時間週六下午三點 submit 問題,然後美國時間週六下午八點寫信催我交,五個小時後我看到信,剛好在北京 RubyConf 最後一天晚上十點,回飯店累都快累翻了,結果只好熬夜寫 code 凌晨兩點抓數據...)。

海選的公平性

當初填過這麼慘烈的表格,所以這次才會印象這麼深。看到辦法馬上就會心一笑。

不過這的確是相當好的方法,因為熱門的創投投資公司,與熱門的 Conf 都會遇到相似的問題:

  1. 背景經歷顯赫的創辦者是好的經理人但卻不一定是適合的創業者
  2. 創辦者不熟悉自己所創辦的事業細節,卻精熟於 Presentation 的 Pitch

由這種互動方式也許能篩掉一部份的冒充者..

 
over 3 years ago

自從開始用 Rails4 以後,一直踢到類似的 asset compiling 爛賬。在 development 端是好的,在 production 一壓卻是爛的。但是在 Rails 3 行為卻是好好的。

一直踢到類似的鐵板,很難試出 root cause 是什麼。最近在用別人包的 Gem,覺得再遇到這種狀況會抓狂,於是認真找了 root cause 是什麼。

Asset Pipeline 的邏輯

基本上在

  • app/assets
  • lib/assets
  • vendor/assets

上掛的東西應該都是有效的。上 production 也會壓得過。(在 Rails 3 是成立的,但在 Rails4 變成圖片時常會找不到,然後鬼打牆一直 debug 不出來 )。

經過人工暴力和看熱門的 Gem (如 font-awesome-rails ) 的作法,發現把 assets 搬到 app/assets 是絕對會動。

Root Cause

花了一堆時間找討論串,發現是 https://github.com/rails/rails/pull/7968 (一年前 Josh Peek 的即興 Design)造成的。底下可以看到一堆熱門的 repo 都 ref 了這支可惡的 pull-request。

原因是 Josh 認為 app/assetslib/assets / vendor/assets 之間的行為要分開。app/assets 是你自己開發的,應該要自動 load。lib 和 vendor 則應該要手掛。

所以如果 image 或 icon-font 放在 lib/assets & vendor/assets。開發者要自己在 config/enviorments/production.rbconfig.assets.precompile 下自動一個一個加入想壓的(非 css/js 的 asset) 才可以。

嚴重的問題點:慣例原則

Rails 的 Asset Gem 維護者大多很嚴謹的維持一個原則。把 Asset 儘量都放在 vendor/assets,表示裡面這份 code 他不是原作者。而且這個 Gem 很明顯是 3rd party libraray。

但是依據開發慣例,如果你把 CSS 放在 vendor/assets下面。那麼相關的 images 基本上 100% 也會放在 vendor/assets/images/, vendor/assets/*/images/。基本上你不會吃飽沒事幹,一份放 app/assets,一份放 vendor/assets

那麼 Johs Peek 的這個強迫行為,造成了原始採用 vendor/assets 設計且有非 css / 非 js 的 Gem,在 Rails 4 全部出事。(而且這個 bug 在 Rails 3 沒有)

然後查了這個一年以前的 Deisgn,竟然沒有在 sprocket-rails 官方文件清楚的指出來。( 去送了一個 pull-request 才發現原先的 README 講的非常含糊)。

暴力解決法

1. 在你的 project 加入這行
config/enviorments/production.rb
config.assets.precompile += %w(*.png *.jpg *.jpeg *.gif)
2. 把你維護的 Gem 從 vendor/assets 搬到 app/assets

結論

不過雖然可以解決問題。但是這兩個解決方法只是讓 Rails project 變得更髒而已 -_-。實在非常不爽 sprocket-rails 這個team。如果你長期有在追 compass-rails 與 sprocket-rails 這場戰爭的話,應該會非常非常討厭後者..。

 
over 3 years ago

前年我寫過一篇 3 招實用 Asset Pipeline 加速術

這次打算再追加三招。

Read on →
 
over 3 years ago

TL;DR; 我不確定有沒有人對這個主題有興趣。不過我承認我是蠻神經病才這樣幹的...

[警告] 這樣作有危險。而且我並不會回答讀者為何你的專案跑不起來的問題。(這是一個超級拼裝車的架構)

起因

我們公司內部的幾個 Project,因為現在一開始都會作 Landing Page,所以 Asset 略顯壅腫。在以往的 Deploy 流程中,我們都是使用 Capistrano 這套工具,策略是到機器上再 compile asset,然後重起整個 project。

這樣的想法是不要卡住 developer 端 deploy 的流暢度。開個新窗放著讓它跑就可以。

只是在機器上 project 越大,compile 越跑越慢。我想我已經是非常會 tune aseet pipeline 的開發者了,但是還是對這樣的情形越來越沒輒。

Read on →
 
over 3 years ago

TL;DR; 這篇很有可能大家看不懂。只是整理來分享。(把同事 v1nc3ntlaw 的筆記從 Redmine 搬到 blog,他說他懶得寫 XD)。我想作國際產品的人應該很有可能會撞到這個問題...

前陣子我們的 Logdown 某個使用者 blog 匯入一直失敗。後來查了很久以後,我同事 v1nc3ntlaw 追到是 MySQL utf8 編碼沒有完整支援所有 utf8 字元的問題。要解決的話必須使用 utf8mb4

Read on →
 
over 3 years ago

這是最壞的年代,也是最好的年代

我的長輩常跟我講一件事:這是最好的年代,也是最壞的年代。

過去二十年間,世界起了巨大的變化:我國小的時候,台灣才剛引進家用電腦,電話還是轉盤。國中的時候,學校有了網際網路,路上的有錢人開始拿起了大哥大。高中的時候,我有了自己的手機,雖然只能打給自己的爸媽。大學的時候 Netbook 正「準備」要流行。畢業後一兩年後 iPhone 與 iPad 席捲了世界,改變了全人類的生活。

我小學的志願是當個歷史學家(因為我愛看書)。但是現在的職業卻是軟體開發者,精熟的技術 Ruby on Rails 是一個 2004 才誕生的 Project。長輩們從來沒有預見過我會是一個程式開發者,他們的理想是讓我繼承父志當一個醫藥從業人員。

我的小學志願甚至不是「軟體開發者」(當時身處的世界沒有這個名詞)。當長大後跟家族長輩說我「好像開始覺得」對寫程式有興趣時,他們每一個都說靠這吃飯會餓死。

他們沒有惡意。

沒有太多人預見我們正在進入一個近兩百年史上最大的革命演進:「五年」、「三年」甚至「一年」之後,整個世界就變得完全不一樣。沒人知道:明,天,會,發,生,什,麼。

過去父輩能夠給我們的職場建議,學校的教科書,社會的觀念,在應付這麼大的浪潮時,通通失效。

現代科技的演革,為生活帶來前所未有的便利。但糟糕的是,我們不知道如何應對於這樣的衝擊。大學是一個四年的制度,能想像嗎?當你按照學長前輩的建議選填志願,修習課程,甚至準備理想的出口:上市公司科技替代役。到大二大三大四,卻發現這條路似乎看起來卻不是那麼正確了。你卻不知如何是好。

這是一個最壞的年代。你知道時代在變,你知道要跳上浪潮才能得救。但你卻無能為力。

這是一個最好的時代。因為既有的規則在崩解,新的機會在產生。只要有能力,站上世界舞台並不是一個遙不可及的夢想。

關鍵是:How?

產業與教學傳承的斷裂

從近代的演變趨勢,不難察覺能夠誕生高附加價值的產業逐漸趨向於軟體與服務。但身為科技矽島的台灣卻在這個競技舞台上缺席。我們的軟體產業在過去十數年斷裂,我們的教育甚至在傳授過時的觀念與流程。身處於一個「不知有漢,無論魏晉」的桃花源。

這一兩年,我在部落格寫下過這幾篇文章:

它們都造成非常大的迴響。

因為我們的年輕國民知道時代在變,我們知道我們在桃花源裡面。但是我們卻無力逃脫。我們的教育體系以及既有觀念無法給我們的滿意解答。我們需要出路。

Vitor 的這本最新作品:「台灣軟體產業的失落十年」,書名雖為失落十年。意旨卻非在批判這個產業,而是在指出一條逃出桃花源的生路。這是一本我看過市面上最好的關於現代軟體開發流程與趨勢的中文(既是技術/又非技術)書籍。裡面的內容廣泛的談論摩登軟體開發、技術、人才、市場等議題。

我相信讀者閱讀完後會有相當大的收穫,在此推薦。

販售平台:Leanpub 連結 / Readmoo 連結

售價:9.99 USD / 299 TWD

 
over 3 years ago

昨天跑去 StartupWeekend #9 當 Judge。席間結識了一位 Mentor: Roger。在評審前說明會閒聊時,Roger 介紹了我們一款遊戲 Hipster CEO,說是一款創業模擬遊戲。

不過這款遊戲因為需求是 iOS 7+ 以上才能執行,身為 iOS 6 死硬派的我,現場糾結了很久到底要不要因為一款遊戲升級到巨醜的 iOS7。後來回家還是抵抗不了誘惑,升級並購買安裝了這個遊戲。

根據另外一篇評測文 Too lazy to start a real startup? Play “Hipster CEO” instead 的資訊。作者說他開發這個 app 其實不是想模擬 Startup 生態。而是想讓人們知道「由一個 idea 發想,到上線,到讓人願意付費是一間非常艱鉅的事」...

(我在網路上找到這篇評測時,遊戲裡面的公司已經被我玩倒了三次)。不過四個小時後,我賣了四間公司賺了七億多 ...XDD從攻克這款遊戲裡面,還學到不少有趣的事。讓我覺得直逼當年的創業桌遊 Burn Rate。所以上來寫這篇攻略文。

遊戲的一開始的設定是:你在自己的宿舍裡面創業,主角可以

  • 自由選擇題材:如 Microblogging Service, Music Streaming Service, SocialNetwork, Todlist, Message App ..等等
  • 起始資金約 15K
  • 具備中上以上的水準,開發 app,Marketing,Sales 各樣都「略懂」
  • 願意的話可以 boostrap 自己什麼都動手作。

我玩的題材是 "MicroBlogging",公司叫 Logdown,CEO 是 Xdite Cheng...XD

剛開始的一個小時,我按著遊戲裡面的 Guide。但是玩倒了自己公司三次,第四次才開始賺錢。

第一次創業

原因是這款遊戲一開始也蠻艱鉅的,雖然一開始有起始資金 15K,如果只有自己一個人的話,現金流約可以撐公司 500 多天。但獨自一人光把 App 做到可以上線(要有10個feature才能上線),就要花上 150 天上下。發現了這一點之後,我決定雇用一個員工幫我開發,縮短時程。但雇用員工真的很貴,雇用一個非常非常初級的員工,就會讓我的 Cashflow 馬上降低到只有 100 多 天可以活。

App 要上線,要搞一些宣傳。所以我決定雇一個行銷專員幫我行銷。但是發現條件不允許。因為宿舍房間只能窩兩個人,雇用了一個員工加上我自己就滿了,所以無法雇用第二個員工。最後我決定開除程式設計師(反正都寫到可以上線了),雇用行銷專員。但後來發現這是一個大錯誤,因為開除程式設計師要給遣散費,所以公司瞬間就少了很多錢。而且我本來以為雇用行銷專員,每天灑個 NT$2 的網頁廣告,和作一點 Social Network 宣傳,東西就會有人用。但是一點作用都沒有。公司三十天後就倒了。

第二次創業

所以我只好捲土重來。我決定還是乖乖自己花 150 天寫 app。上線後再請一個初級行銷專員,幫我行銷。但還是發現不行,根本沒有人來用。雖然這次比較省錢,公司可以多撐 100 天。但是沒有 income 公司最後還是 GG。(中間雖然有 Seed Fund,但是根本沒啥用,都是 2K 然後要 56% 股份,2K 根本燒不了幾天啊,開我玩笑嗎大哥)

第三次創業

我想上次會倒應該是我請的人不夠厲害的關係,於是我這次還是自己寫 app,然後請一個超級厲害的行銷專員(很貴),幫我投放廣告:「一樣放 NT$2 的網頁廣告,和作一點 Social Network 宣傳」。然後....這次死更快,因為還是一樣沒屁用,行銷專員的薪水太貴,十幾天我就倒了...

第四次創業

==== 劇透密技分隔線 ==== (如果你想要自己繼續玩的話以下是攻略)

Read on →
 
over 3 years ago

昨天去參加 HappyDeisgner Mini #5 聽到 Caesar Chi 在講他跑校園傳道 (提倡 OpenSource)的故事,Caesar Chi 說他會這麼做是受到 Jserv 南下傳道的啟發。

為什麼要深入校園傳道。我想其中最大的問題是:大家都已經深刻發現了「校園的資訊教育」與「現行職場」、甚至與「國際技術圈」上的巨大差距。已經大到一個相當難以扭轉的狀態。其實,任何技術,在寫下來製成紙本教材並且搬到課堂的那一刻,就過時了。只是現在速度更快到,當你今年寫下來準備開課,明年這套技藝就已經有可能過時了。真的很難期待,從傳統學校傳授知識的過程中去介入什麼。

所以唯有提倡學生儘量跳脫只能在學校學習的思考框架。在線上學習( Online School )。多多參與接觸開源社群。

But, How?

在線上學習( Online School )。多多參與接觸開源社群。 對我們已經在工作的職業程式設計師,這個概念再簡單不過。但是我發現這對初學者來說,是一個很空泛的概念。他們其實更需需要的是一份 Guideline,有一個具體的方向去「自學」去把目標具體化。

(這份 Guideline 也是我回想若當初我剛出社會時,希望有人能給我的一份清單)

=== 分隔線 ===

Source Control

  • 理解什麼是「版本控制」,為什麼我們要使用「版本控制」
  • 學習 Git : http://try.github.io
    • git commit
    • git push
    • git pull
    • git branch
    • git checkout
    • git merge
  • 註冊 Github 帳號
  • 把自己的作業推上 Github
  • Fork 同學的作業,幫他修錯字,然後拉 pull-request
  • 卡關就上 Google 找 Stackoverflow 的答案

Do a "real" project

讀書跟做事不一樣。你不應該去「讀完」Ruby 再去用「Ruby on Rails」寫一個網站。

  • 找一本可以教你作一個 project 的書(不知道去哪找可以上網問),從頭到尾貼 code 跟著作一遍搞懂架構以及學習 debug。
  • 扔開書後的第一次:作一個比書裡面的 demo 還小的 project,如果裡面 demo 一個論壇,那麼就做一個留言板。
  • 扔開書後的第二次:重新作一個簡單的論壇,不看書。
  • 扔開書後的第三次:重新作一個有你想要的功能的論壇,可以貼圖,可以分享到 FB。
  • 去找可以幫助你重新把程式技巧提煉的更好的書,重新補基本功(這時候你可以好好的看 Ruby 書了)。
  • 去 Meetup 找職業的前輩,問他們怎麼樣可以更好的翻修你的 project

學習協作

獨自開發一個小東西,和實際上與多人一起開發一個中型結構的專案是完全不一樣的世界。而學校幾乎不可能有這樣的環境。

  • 註冊 Trello 帳號(這是一個簡單協作、看板式的專案系統)
  • 試著與同學或同事「合作」。但用 Trello 管理所有待辦事項。
  • 重點是
    • 把一件龐大的目標拆分成數十個可以執行的小事項
    • 每一樣事項有各自的狀況。現在做到哪裡,還缺什麼,需要交付的材料,多久才會做完,遇到什麼困難
    • 不要用 Off-book (phone/email) 的管道溝通
    • 有問題就提出,不要藏在台面下。
    • 每一件事都應該要有一個可以指派的人

分享(程式碼以及文章)

不斷的貼 code 以及練習在網路上發表文章,可以強化你的表達能力與邏輯組織能力。知名軟體公司 37Signals 甚至表示,他們不太注重程式底子,只雇用「寫作能力」良好的人。因為寫作能力強大代表著:組織能力與邏輯能力強。

這不是什麼可以速成可以偽裝的東西。同時不斷發表東西,連帶的效應就是可以幫你建立 reputation,和讓別人發現你的存在

  • 把學到的東西發表到 Blog 上面。(不要怕害羞)
  • 即便是小小的程式片斷也貼到 Blog 上。
  • 不斷的貼 code 以及練習在網路上發表文章,
  • 把自己作品放到 Github 上

Learn English

這裡說的學習英文不是說去背單字,上補習班,考 TOEIC。而是:

  • 練習幫自己在 Github 的 Project 上寫 README
  • 有辦法在在 Github 上用英文 open issue / reply issue
  • 在 Stackoverflow 上用英文問問題
  • 訂閱社群電子報。(尤其讀社群電子報,如 Ruby Weekly,是個學習 Ruby 非常快的方式)
  • 聆聽社群 Podcast。(社群都會有一些 Podcast,短的 5 分鐘如 Ruby5,長的 30-45min,可以很快的讓你抓到這個禮拜世界上最新的重點是什麼)
  • 購買線上教材。(現在網上學習的教材都比大學教科書便宜非常多,有些甚至不要錢。不過他們都是「英文」影片以及作業)

=== 分隔線 ===

小結:

這是由我過去的實戰經驗總結出來的 CheatSheet。當然,這些事我並沒有說都是非常「輕鬆」做到的事。但我可以向你保證這些方向,如果練成都是「非常值錢非常具有競爭力」的技能。認真執行三個月,你「馬上」可以見到與台灣完全不一樣的那個世界。