Tweets 整理 (2012)

2012/12

2012/11

2012/10

2012/9

2012/8

  • 2012-08-29 23:22:29 +0800 @jonathanchen 我也是有一堆疑問啊! 好在這活動不強調成功案例和教學… XD 就大家一起討論分享經驗吧!!
  • 2012-08-29 22:31:27 +0800 Agile Meetup 超級五分鐘分享會!! t.co/JUT5NCoh # 投了一個 Agile v.s. Lean Startup 的題目… XD
  • 2012-08-29 21:14:59 +0800 Watching:「比稿到底是什麼?」- WHAT IS SPEC WORK? t.co/4vaP5UsM
  • 2012-08-29 18:13:44 +0800 @jonathanchen 也容易發生為了開發而開發的情況,為了塞滿這兩週開發週期的能量,不讓工程師閒著,而找事情給工程師做。設定 sprint 也會偏向讓大家計較完成的 deadline,而不是產品真正的目標。
  • 2012-08-29 18:12:53 +0800 @jonathanchen 我開始感覺 Kanban 也許比較適合。以 web 產品來說,已經可以做到每天連續釋出了,設定 sprint 週期反而變成限制。
  • 2012-08-29 16:33:24 +0800 有趣的 Ruby 社群問卷結果 t.co/5OrwWEw1 # Ruby 1.9.3, Nginx, Git 已是主流,PostgreSQL 則大有進展。
  • 2012-08-29 15:31:51 +0800 “…except for the problem of too many layers of indirection.” by Kevlin Henney’s corollary # 哈哈
  • 2012-08-29 15:31:02 +0800 “All problems in computer science can be solved by another level of indirection(abstraction)” by David Wheeler
  • 2012-08-28 23:25:13 +0800 @jonathanchen 就是因為不確定什麼東西是用戶要的,所以 lean startup 才會捨棄所有與需要學習的事物無關的功能啊 XD 好比說一個只支援 chrome 一種瀏覽器的 web app,應該不合乎用戶期待吧(當然是最好可以跨瀏覽器啊),但是這卻無損於實驗跟學習。
  • 2012-08-28 22:30:25 +0800 @jonathanchen 其實作者提到的低品質,舉的例子都是指產品功能缺東缺西,而不是指 “defect”。讓東西上 production 結果無法使用,回頭再去修當然是一種浪費的行為。
  • 2012-08-28 14:46:29 +0800 @jonathanchen 就 startup 的情境,我覺得 scrum 關注的面向不夠,對於產品要做什麼,就簡單交代是 PO 負責而已。書 p144 (中文版)就有提到敏捷開發流程追求的高品質高效率並不是 lean startup 的重點。
  • 2012-08-28 10:00:27 +0800 看完精實創業後反而減少了對 scrum 的興趣(書裡推薦的是 kanban 法),生產效率跟品質不是一開始最重要的,做的東西不對,才是最大的浪費。
  • 2012-08-27 07:17:45 +0800 @sleepnova 大神是可以直接印在書上做推薦的啦,例如 @pirrer @deduce
  • 2012-08-27 01:22:22 +0800 @xyz98 想不到在 twitter 上可以遇到作者本尊,正在拜讀中。
  • 2012-08-27 00:51:18 +0800 @xds2000 Ruby 程式語言的規格就是 CRuby 實作……
  • 2012-08-27 00:25:29 +0800 精實創業這本書出乎意料的贊,不管是不是在 startup 公司,只要是開發新產品,都可以讀一讀獲得啟發。推薦。
  • 2012-08-26 17:39:56 +0800 複習到人月神話第6章,有個有趣的概念:當同一個規格有多個實作品時,由於不同實作必須維持嚴格的相容性,無形中會加強了規格的地位。這種概念非常有利於應用在定義中的程式語言上,如果一開始就至少開發兩個以上的實作品,將有助於維持程式語言的純淨與嚴謹。
  • 2012-08-26 17:25:52 +0800 好玩也開了一個 Facebook 粉絲專頁 t.co/tbP7kNUA # 衝 Facebook 贊正夯(?)
  • 2012-08-26 17:17:57 +0800 「輕諾者,必寡信」,每一個 public 介面方法都是一種承諾。
  • 2012-08-26 03:32:14 +0800 資訊隱藏原則的關鍵是隱藏實作細節,包括內部資料結構和演算法邏輯,常見的錯誤包括 1. 將可變的內部物件參照當做傳回值 2. 將可變物件參照直接指定給內部物件 3. 介面方法的參數或傳回值類型不夠抽象 4. 方法的命名透漏的實作策略 (by 程式設計範式與OOP的思考術)
  • 2012-08-24 14:16:24 +0800 @yllan 怎會,馬勒的交響曲可以很有趣(例如第一號第二樂章),可以很刺激 (例如第一號第四樂章),也可以很美妙(例如第四號第四樂章)耶… XD
  • 2012-08-23 16:37:52 +0800 Reading: 為什麼雲端產業在台灣行不通 t.co/kMiPPJlv # “一個新架構的好壞,只有經過實際的流量摧殘才能知道,在這之前,一切只是工程師們用腦補的假設而已”… XD
  • 2012-08-23 01:50:47 +0800 @sleepnova @deduce 還要跟兩位創業的大大多學習啊!!~
  • 2012-08-23 01:26:55 +0800 以前看人月神話裡的”外科手術團隊”,覺得很酷,由首席程式設計師一人主刀,其他人都是支援角色。現在看覺得不合時宜了,而且這個類比也不好,開發軟體跟開刀房裡人命不能等的 context 我想差別很大。
  • 2012-08-22 20:01:22 +0800 “如果我們不知道顧客是誰,我們也不知道品質是什麼 from 精實創業” + “如果你不在乎品質,那麼無論需求是什麼你都能符合 from 溫伯格的品質第零法則” = ?
  • 2012-08-22 19:56:03 +0800 工程師思維就是盡可能有效率地開發高品質產品, Agile 敏捷開發也是如此目的,但是對於如何開發出對的產品,給對的使用者在對的時間,就隻字未提了。如果是接案,還知道所謂對的產品就是客戶說了算。對 startup 來說,顧客在哪裡都不知道。
  • 2012-08-21 23:59:12 +0800 @ETBlue 小的哪敢記恨… 冤枉阿~
  • 2012-08-21 20:54:42 +0800 好久沒辦 Ruby Tuesday 聚會,來的人自我介紹幾乎都是寫 rails 的,太恐怖了。
  • 2012-08-21 02:12:44 +0800 Reading: How we use Trello & Google Docs to make UserVoice better every day t.co/IpYGuxWj # 用 Trello 來做 product planning 和 scrum
  • 2012-08-21 00:39:04 +0800 Reading: Wireframe t.co/GrFzSH44 # 要求把 wireframe 畫的非常詳細成為規格文件是一種團隊的浪費,wireframe 和 user story 一樣都只是溝通的輔助工具而已。
  • 2012-08-19 17:04:27 +0800 今天也跟 Hiiir 的 Neil 請教了帶 team 的經驗,本位主義真是大家的痛。 #coscup
  • 2012-08-19 16:20:55 +0800 遇到從香港來的 @stevenmak,趁機請教一下 agile coach 和 scrum,賺到了 XD
  • 2012-08-19 12:01:28 +0800 認真聽 thegiive 講 web software release practice,分享了好多他在 Y! 的實務經驗,超棒。推薦 continuous delivery 這本書和桂格高麗人蔘滋補液。
  • 2012-08-19 09:46:40 +0800 at COSCUP
  • 2012-08-18 20:52:26 +0800 但是個人生產力並不等於團隊生產力,團隊生產力會受限於流程中最慢的那個環節,這就是 Kanban 的 Litmit WIP 概念,去限制單一環節的最大工作項目。另外,對 startup 來說,生產力更不是看功能寫多快、品質有多高,而是發展出客戶想要且願意買單的產品。 #精實創業
  • 2012-08-18 20:52:21 +0800 對於習慣在小範圍評估自己生產力的人來說,能夠專心工作一整天不被干擾,代表生產力很高,對programmer來說就是能不斷地coding。如果被別人的問題干擾、工作流程或開會打斷,就會覺得什麼事都沒做,畢竟code和完成的功能是看的到的東西。 #精實創業
  • 2012-08-18 01:17:55 +0800 想不到精實創業竟然排第一… 這麼有話題性啊… XD # Top 100 Agile Books (Edition 2012) t.co/ZS6vlZ79
  • 2012-08-18 00:30:17 +0800 RT @ETBlue: 「老公你要看我朋友的訂婚照片嗎?」「好啊!」「收 gtalk。」「嗯來看看 source code。」「老公你不是要看照片?」「咦這網站做的不錯。」「老公要不要先看照片?」「耶?PHP 寫的?」「老公你到底要不要看照片?」「這網站放在國外耶!還 Bluehost!」……
  • 2012-08-17 17:50:49 +0800 Reading: t.co/PWOqBdTg # 嘗試把整個 UX design 的工作都提前一整個 sprint 進行 #scrum
  • 2012-08-16 18:25:24 +0800 第一次用 feature toggle 把還沒完成的 feature 就推上 production 了,真刺激。
  • 2012-08-16 12:39:26 +0800 scrum 真的是一個 framework 而已,就像單獨的Web框架對使用者沒什麼用處。真要實戰,還需要在上面”開發”出屬於團隊自己的開發流程。不同公司文化、不同團隊成員的組成、不同的產品、不同的IT環境,都會開發出不一樣的 scrum 流程。
  • 2012-08-14 14:05:32 +0800 RT @rubytaiwan: 久違的 Ruby Tuesday 聚會 2012/8/21 t.co/O5MR6MkC
  • 2012-08-10 03:18:52 +0800 RT @spolsky: Which is a better case study for “never rewrite from scratch,” Perl 6 or TextMate 2? t.co/gUqHZgDJ (warning: extremely old link)
  • 2012-08-08 22:00:39 +0800 @godfat 別忘了 Larry Wall 可是語言學家… XD
  • 2012-08-08 21:36:03 +0800 script 跟 program 的分別? “a script is what you give the actors. A program is what you give the audience.” by Larry Wall # 莞爾
  • 2012-08-08 18:41:43 +0800 像 Web API 這種東西,使用者又看不見,只要 1.自動化測試涵蓋率夠(相較於測試 UI 介面,只測 HTTP API 簡單多了) 2. 有監控機制配套,要做到一個 commit 就自動 deploy production 一次應該是不難達到的境界。
  • 2012-08-08 18:31:22 +0800 第二個心態改變是 “Marketing Release” 和 “Engineering Release” 是分開的概念,一個功能完成並佈署不代表就要開放給 end-user 使用,可以用 feature flag 藏起來只給內部使用者試用(例如UX, 行銷等),或是做A/B測試。
  • 2012-08-08 18:27:15 +0800 大部分的 code changes 其實使用者是看不見的,這些變更也預期是沒有副作用,不會造成regression。Continuous Deployment 第一個心態改變就是:讓這些變更在自動測試通過後就立即 release 上 production。
  • 2012-08-08 17:17:24 +0800 Bugs 是要放在 product backlog 裡還是 issue tracking system? 找到大師的回答: t.co/tq1JjMAx #scrum
  • 2012-08-08 15:27:49 +0800 剛剛才發現原來這篇 Continuous Deployment t.co/r1JT1L7w 的作者就是 The Lean Startup 精實創業一書的作者
  • 2012-08-08 14:30:30 +0800 “if it hurts, do it more often” from t.co/EAokSbqm # integration 和 release 情境皆適用
  • 2012-08-08 12:56:35 +0800 @godfat 快投 rubyconf.tw 講 ruby application server 重點啊!!
  • 2012-08-07 17:54:18 +0800 @godfat 這篇給 Ruby 1.9 fibers 負評唷 *flee*
  • 2012-08-07 15:40:39 +0800 Reading: Why Rails 4 Live Streaming is a big deal t.co/T4Aw21nS 所以 Passenger 4 是 multi-processed + multi-threaded + evented 的合體,好威。
  • 2012-08-06 22:03:12 +0800 @jrweizhang t.co/dm7D7AMQ 內建就有 Ajax helper 的樣子
  • 2012-08-06 21:24:22 +0800 @jrweizhang .js.erb 也沒有不行啦 XD 但我認為把 javascript 寫在 client 端,讓 server 只回傳 json 會比較乾淨。
  • 2012-08-06 11:12:24 +0800 RT @hirakujira: 我直到現在才發現 Nally 是 @yllan 顛倒過來…
  • 2012-08-06 08:12:57 +0800 平常坐的客運班次表大改… 班次更少了… 得更早出門了… orz
  • 2012-08-05 21:52:42 +0800 週五去上的Scrum大師講座有人整理心得筆記了,真的是超級物超所值的一場活動啊!! t.co/iSUbijOc t.co/X53NHPKL
  • 2012-08-05 03:15:28 +0800 重讀人月神話 t.co/e2ruCw0D
  • 2012-08-04 00:01:12 +0800 @stevenmak 真可惜,期待以後有機會聽你講 agile/scrum 啊。
  • 2012-08-03 19:29:35 +0800 今天獲得的 scrum 好問獎 t.co/9tyHRERo
  • 2012-08-03 18:37:57 +0800 今天的 scrum 大師講座,好多同學的公司都是已經在 run scrum 了,還有公司整個 team 一起來聽的,真不錯。
  • 2012-08-03 12:35:09 +0800 @stevenmak 是你同事?!
  • 2012-08-03 10:53:33 +0800 專業的 scrum 講師 t.co/b8DGbXcT
  • 2012-08-03 08:40:38 +0800 準時搭上高鐵,沒想到卻錯搭早一班車的樣子… 班次整個delay了十幾分鐘…
  • 2012-08-02 21:03:43 +0800 趁颱風假把 #團隊之美 Beautiful Teams 看完了,訪談的章節都還不錯,有些講故事的章節則太過細節覺得有點冗長。
  • 2012-08-02 20:48:29 +0800 「一個成功的團隊中,我們都了解到如果沒有”明星”將無法形成一個團隊,幸運的是,一個真正聰明的”明星”知道如果沒有一個優秀的團隊,他們將會很難得到成功甚至於無法生存」- Tony Visconti (音樂製作人) #團隊之美
  • 2012-08-02 20:30:50 +0800 @jyuny1 我相信好的 team leader 應該要可以引導衝勁和創意到正確的目標上,而不是壓抑。
  • 2012-08-02 18:08:23 +0800 @jyuny1 我覺得比較像是紀律問題
  • 2012-08-02 17:13:01 +0800 年輕、聰明、經驗不多,沒有傷痕的工程師,常不願意約束自己的創意,認為需要增加一些多餘的鍍金功能,即使相關利益者從來沒有提過這種要求,也不需要這些功能。但是工程師卻覺得是個好主意,而團隊通常也不會因此反對,因為有時真的會產生更好的軟體。但這種作法往往導致嚴重的品質問題。 #團隊之美
  • 2012-08-02 17:07:01 +0800 這個定義的特別之處在於”控管框架”,自我管理團隊不代表你不必接受控制,隨心所欲做自己的事。它的意思是由團隊成員自行決定如何實現目標,但是目標本身、資源跟時程都是由組織控管。 #團隊之美
  • 2012-08-02 17:01:11 +0800 有紀律的敏捷一種 「跌代和增量(演進)式的軟體開發方式,透過自我組織的團隊經由高度協同作業的方式,在一個 “剛好足夠” 儀式的有效控管框架內,產生符合成本及時程的高品質軟體,以滿足相關利益者不斷變化的需求」 t.co/SsLLlDbZ #
  • 2012-08-02 15:33:40 +0800 RT @godfat: 好 rubyconf, 不投嗎? t.co/596Bt4vV
  • 2012-08-01 20:12:36 +0800 Steve McConnell 和 Alex Martelli 的訪談中都提到不推薦分散式團隊,幾乎無法產生淨效益。團隊不在一個地方工作,敏捷開發需要的面對面溝通和互通都會消失 #團隊之美

2012/7

2012/6

2012/5

2012/4

2012/3

2012/2

2012/1

Leave a Reply