1. 60k famous quotes:
http://myfamousquotes.com/?
2. couchsurfing:
http://www.couchsurfing.org
3.idioms
http://englishhome.org/idioms/idioms.htm
4. TOFEL materials
http://www.hellous.com/forum/index.php?showtopic=6143
[CS]
1.krypted.com
http://krypted.com/mac-os-x/mac-os-x-105-netinfo-or-the-lack-thereof/
Imps are always mischievous, uncontrollable, only obedient to somebody special, and not as powerful as the real demons, yet.
小惡魔:調皮難控制的猴小孩,還在努力成為真正的大惡魔中。
As the title suggests, this is my everything notebook, may in traditional Chinese or English.
這裡什麼都寫,不管是食譜、遊記、練習寫作的爛文,抑或是個人的一些狗屁倒灶的東西都有可能出現,使用語言也是隨性。
*Sometimes, those bilingual articles are not formed by translation, I will represent the concepts twice using different ways of thinking based on the language I use.
Friday, November 25, 2011
Wednesday, November 23, 2011
[Transcript]Why Can't Developers Estimate Time?
This article is a transcript from the following url:
http://blog.patchspace.co.uk/why-cant-developers-estimate-time
A few interesting points came up on a mailing list thread I was involved in. Here are a few of them. The original comments are presented as sub-headers / quoted blocks, with my response below. This isn't a thorough look at the issues involved, but what I thought were relevant responses. Note: I've done some editing to improve the flow and to clarify a few things.
Why can't developers estimate time?
We can't estimate the time for any individual task in software development because the nature of the work is creating new knowledge.
The goal of software development is to automate processes. Once a process is automated, it can be run repeatedly, and in most cases, in a predictable time. Source code is like a manufacturing blueprint, the computer is like a manufacturing plant, the inputs (data) are like raw materials, and the outputs (data) are like finished goods. To use another analogy, the reason Starbucks makes drinks so quickly and repeatably is because they invested a lot of time in the design of the process, which was (and is, ongoing) a complex and expensive task. Individual Starbucks franchises don't have to re-discover this process, they just buy the blueprint. I'll leave it as an exercise to the reader to infer my opinion of the Costa coffee-making process.
It's not actually always a problem that development time is unpredictable, because the flipside is that so is the value returned. A successful piece of software can make or save vastly more than its cost. Tom DeMarco argues for focussing on the high value projects for exactly this reason. Note that this does require a value-generation mindset, rather than the currently-prevalent cost-control mindset. This is a non-trivial problem.
By far the best explanation I've read of variability and how to exploit it for value is Don Reinertsen's Principles of Product Development Flow, which is pretty much the adopted "PatchSpace Bible" for day-to-day process management. And when I say "by far the best", I mean by an order of magnitude above pretty much everything else I've read, apart from the Theory of Constraints literature.
Here is the data from my last development project. (Histogram generated in R with 5-hour buckets: the horizontal axis shows the duration in hours for the user stories - 0-5 hours, 5-10 hours, etc; the vertical axis is the number of stories that took that duration). We worked in 90 minute intervals and journaled the work on Wave, so we knew task durations to a pretty fine resolution. (We did this for both client communication and billing purposes.) The result: our development times were about as predictable as radioactive decay, but they were very consistently radioactive. Correlation with estimates was so poor I refused to estimate individual tasks, as it would have been wilfully misleading, but we had enough data to make sensible aggregates.
Rule of thumb: take the estimates of a developer, double it and add a bit
The double-and-add-a-bit rule is interesting. When managers do this, how often are tasks completed early? We generally pay much more attention to overruns than underruns. If a team is not completing half of its tasks early, it is padding the estimates, and that means trading development cycle time for project schedule. Cycle time is usually much more valuable than predictability, as it means getting to market sooner. Again, see Reinertsen's work, the numbers can come out an order of magnitude apart.
Also, this is the basis for Critical Chain project management, which halves the "safe" estimates to condense the timescale, and puts the remaining time (padding on individual tasks) at the end, as a "project buffer". This means that Parkinson's Law doesn't cause individual tasks to expand unduly. I'm unconvinced that Critical Chain is an appropriate method for software though, as the actual content of development work can change significantly, as feedback and learning improves the plan.
People in general just make shit up
Estimating is a very important skill and should be taught more in junior dev roles
I propose an alternative: what we need to do is teach to junior devs the meaning of done. If estimation problems are bad enough, finding out at some indeterminate point in the future that something went out unfinished (possibly in a rush to meet a commitment … I mean - estimate!) blows not only that estimate out of the water, but the schedule of all the current work in process too. This is very common, and can cause a significant loss of a development team's capacity.
http://blog.patchspace.co.uk/why-cant-developers-estimate-time
A few interesting points came up on a mailing list thread I was involved in. Here are a few of them. The original comments are presented as sub-headers / quoted blocks, with my response below. This isn't a thorough look at the issues involved, but what I thought were relevant responses. Note: I've done some editing to improve the flow and to clarify a few things.
Why can't developers estimate time?
We can't estimate the time for any individual task in software development because the nature of the work is creating new knowledge.
The goal of software development is to automate processes. Once a process is automated, it can be run repeatedly, and in most cases, in a predictable time. Source code is like a manufacturing blueprint, the computer is like a manufacturing plant, the inputs (data) are like raw materials, and the outputs (data) are like finished goods. To use another analogy, the reason Starbucks makes drinks so quickly and repeatably is because they invested a lot of time in the design of the process, which was (and is, ongoing) a complex and expensive task. Individual Starbucks franchises don't have to re-discover this process, they just buy the blueprint. I'll leave it as an exercise to the reader to infer my opinion of the Costa coffee-making process.
It's not actually always a problem that development time is unpredictable, because the flipside is that so is the value returned. A successful piece of software can make or save vastly more than its cost. Tom DeMarco argues for focussing on the high value projects for exactly this reason. Note that this does require a value-generation mindset, rather than the currently-prevalent cost-control mindset. This is a non-trivial problem.
By far the best explanation I've read of variability and how to exploit it for value is Don Reinertsen's Principles of Product Development Flow, which is pretty much the adopted "PatchSpace Bible" for day-to-day process management. And when I say "by far the best", I mean by an order of magnitude above pretty much everything else I've read, apart from the Theory of Constraints literature.
Here is the data from my last development project. (Histogram generated in R with 5-hour buckets: the horizontal axis shows the duration in hours for the user stories - 0-5 hours, 5-10 hours, etc; the vertical axis is the number of stories that took that duration). We worked in 90 minute intervals and journaled the work on Wave, so we knew task durations to a pretty fine resolution. (We did this for both client communication and billing purposes.) The result: our development times were about as predictable as radioactive decay, but they were very consistently radioactive. Correlation with estimates was so poor I refused to estimate individual tasks, as it would have been wilfully misleading, but we had enough data to make sensible aggregates.

The double-and-add-a-bit rule is interesting. When managers do this, how often are tasks completed early? We generally pay much more attention to overruns than underruns. If a team is not completing half of its tasks early, it is padding the estimates, and that means trading development cycle time for project schedule. Cycle time is usually much more valuable than predictability, as it means getting to market sooner. Again, see Reinertsen's work, the numbers can come out an order of magnitude apart.
Also, this is the basis for Critical Chain project management, which halves the "safe" estimates to condense the timescale, and puts the remaining time (padding on individual tasks) at the end, as a "project buffer". This means that Parkinson's Law doesn't cause individual tasks to expand unduly. I'm unconvinced that Critical Chain is an appropriate method for software though, as the actual content of development work can change significantly, as feedback and learning improves the plan.
People in general just make shit up
It's not just developers that are bad with estimates either. Everyone at some point is just winging it because it's something they've never done before and won't be able to successfully make a judgement until they have.As a community we need to get away from this. If we don't know, we don't know, and we need to say it. Clients who see regular progress on tasks they were made aware were risky (and chose to invest in) have much more trust in their team than clients whose teams make shit up. It's true! Srsly. Don't just take my word for it, though - read David Anderson's Kanban.
Estimating is a very important skill and should be taught more in junior dev roles
I propose an alternative: what we need to do is teach to junior devs the meaning of done. If estimation problems are bad enough, finding out at some indeterminate point in the future that something went out unfinished (possibly in a rush to meet a commitment … I mean - estimate!) blows not only that estimate out of the water, but the schedule of all the current work in process too. This is very common, and can cause a significant loss of a development team's capacity.
[Note] Spectral Clustering (SVD)
這篇是在找normalization cut 時候找到的,算是轉錄再轉錄
來源網址是
http://blog.xuite.net/coke750101/coketech/19917487
來源網址是
http://blog.xuite.net/coke750101/coketech/19917487
Spectral Clustering http://140.123.102.86:180/phpBB3/viewtopic.php?f=10&t=154 | 分頁: 1 / 1 |
作者: | Sam.Tzeng. [ 週一 3月 10, 2008 3:09 pm ] | |
文章標題 : | Spectral Clustering | |
|
Thursday, November 17, 2011
[Windows] Putty顯示中文
嗯...putty是拿來連SSH的工具,通常是在Windows用的
如果你的server端有中文字的話,在putty會有亂碼,而且會有其他問題
解決方式是去調putty的字型設定(記得順手編碼成UTF8喔)
在Change Settings",找到 "Window" 中 "Appearance" 選項,
右邊的 "Font settings" ,按下 "Change",選你要的中文字型,如:新細明體
下面的字集選中文BIG5
嗯...連線看看吧
如果你的server端有中文字的話,在putty會有亂碼,而且會有其他問題
解決方式是去調putty的字型設定(記得順手編碼成UTF8喔)
在Change Settings",找到 "Window" 中 "Appearance" 選項,
右邊的 "Font settings" ,按下 "Change",選你要的中文字型,如:新細明體
下面的字集選中文BIG5
嗯...連線看看吧
[SUSE] VNC server
VNC 就是跨平台的遠端桌面,可以在Windows跟非Windows的系統中連遠端桌面,通常是在需要用圖形介面連Linux伺服器時用的,平常都是用SSH比較多
---------------------------------以下是複製貼上的-----------------------------------------------------------------------
步驟1.啟動 VNC Service
輸入指令 vncserver 來啟動 VNC Service 產生 VNC 設定檔,執行 vncserver 指令後會請您輸入屆時登入 VNC 的密碼,若未指令 VNC Service 時的 Port 則預設為 Port 5901
#vncserver //輸入指令啟動 VNC Service
You will require a password to access your desktops.
Password: //設定 VNC Password
Verify: //確認 VNC Password
Would you like to enter a view-only password (y/n)? n //是否要設定 View Only 的 VNC Password
New 'X' desktop is weithenn:1 //VNC Listen Port 為 5901
Creating default startup script /root/.vnc/xstartup //產生的 VNC 設定檔路徑
Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/weithenn:1.log
步驟2.修改 vncserver 設定檔
修改 VNC 設定檔內容使屆時登入 OpenSuse 時桌面環境為 Gnome.
#vi ~/.vnc/xstartup //設定 VNC 設定檔
#!/bin/sh
xrdb $HOME/.Xresources
xsetroot -solid grey
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
#twm & //註解此行 (預設值)
gnome-session & //新增此行,採用 Gnome 桌面環境
修改完畢後將 VNC Service 停止以便等一下重新載入 VNC 設定檔內容
#vncserver -kill :1 //刪除剛才 Listen Port 5901 的 VNC Service
Killing Xvnc process ID 15878
步驟3.啟動 VNC Service
下列指令為將 VNC Service 啟動且 Listen Port 6000 (5900 + :100 => 6000)
#vncserver :100
New 'X' desktop is weithenn:100
Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/weithenn:100.log
啟動成功後確認系統是否有 Listen Port 6000
#netstat -tnl |grep '6000'
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN
確認系統是否有 VNC Service 的 Process
#ps aux |grep vnc
root 15952 0.2 0.3 86264 24564 pts/2 S 09:32 0:00 Xvnc :100 -desktop X -httpd /usr/share/vnc/classes -auth /root/.Xauthority...
*************************************
1.這種的是只能開啟自己的遠端登入,其他的帳號要他登入自己開啟
2. 如果出現'cannot acquire name on session bus'的錯誤訊息的話,其實是因為你這個帳號已經有遠端登入gnome(一種圖形介面的模式)了,同一個帳號不能同時用兩個gnome
如果當初開啟vncserver是在圖形介面下,那當然就已經占用了gnome了
所以解決方法就是: 用SSH(文字介面)下開啟vncserver,再用vnc軟體遠端連上去
3. 中文版yast的 '遠端管理(VNC)' 是xorg-x11-vnc,在防火牆允許規則中翻作 'VNC伺服器',只開 5901,另一個是只有 'VNC'三個字,port是 5800-5900 全開
原文出處
http://www.weithenn.org/cgi-bin/wiki.pl?OpenSuse-VNC_Server%E9%81%A0%E7%AB%AF%E9%80%A3%E7%B7%9A%E4%BC%BA%E6%9C%8D%E5%99%A8
其餘參考文章
http://opensuse.swerdna.org/susefirewall.html
(大陸網頁)
http://www.sparelife.net/?p=82
---------------------------------以下是複製貼上的-----------------------------------------------------------------------
步驟1.啟動 VNC Service
輸入指令 vncserver 來啟動 VNC Service 產生 VNC 設定檔,執行 vncserver 指令後會請您輸入屆時登入 VNC 的密碼,若未指令 VNC Service 時的 Port 則預設為 Port 5901
#vncserver //輸入指令啟動 VNC Service
You will require a password to access your desktops.
Password: //設定 VNC Password
Verify: //確認 VNC Password
Would you like to enter a view-only password (y/n)? n //是否要設定 View Only 的 VNC Password
New 'X' desktop is weithenn:1 //VNC Listen Port 為 5901
Creating default startup script /root/.vnc/xstartup //產生的 VNC 設定檔路徑
Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/weithenn:1.log
步驟2.修改 vncserver 設定檔
修改 VNC 設定檔內容使屆時登入 OpenSuse 時桌面環境為 Gnome.
#vi ~/.vnc/xstartup //設定 VNC 設定檔
#!/bin/sh
xrdb $HOME/.Xresources
xsetroot -solid grey
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
#twm & //註解此行 (預設值)
gnome-session & //新增此行,採用 Gnome 桌面環境
修改完畢後將 VNC Service 停止以便等一下重新載入 VNC 設定檔內容
#vncserver -kill :1 //刪除剛才 Listen Port 5901 的 VNC Service
Killing Xvnc process ID 15878
步驟3.啟動 VNC Service
下列指令為將 VNC Service 啟動且 Listen Port 6000 (5900 + :100 => 6000)
#vncserver :100
New 'X' desktop is weithenn:100
Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/weithenn:100.log
啟動成功後確認系統是否有 Listen Port 6000
#netstat -tnl |grep '6000'
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN
確認系統是否有 VNC Service 的 Process
#ps aux |grep vnc
root 15952 0.2 0.3 86264 24564 pts/2 S 09:32 0:00 Xvnc :100 -desktop X -httpd /usr/share/vnc/classes -auth /root/.Xauthority...
*************************************
1.這種的是只能開啟自己的遠端登入,其他的帳號要他登入自己開啟
2. 如果出現'cannot acquire name on session bus'的錯誤訊息的話,其實是因為你這個帳號已經有遠端登入gnome(一種圖形介面的模式)了,同一個帳號不能同時用兩個gnome
如果當初開啟vncserver是在圖形介面下,那當然就已經占用了gnome了
所以解決方法就是: 用SSH(文字介面)下開啟vncserver,再用vnc軟體遠端連上去
3. 中文版yast的 '遠端管理(VNC)' 是xorg-x11-vnc,在防火牆允許規則中翻作 'VNC伺服器',只開 5901,另一個是只有 'VNC'三個字,port是 5800-5900 全開
原文出處
http://www.weithenn.org/cgi-bin/wiki.pl?OpenSuse-VNC_Server%E9%81%A0%E7%AB%AF%E9%80%A3%E7%B7%9A%E4%BC%BA%E6%9C%8D%E5%99%A8
其餘參考文章
http://opensuse.swerdna.org/susefirewall.html
(大陸網頁)
http://www.sparelife.net/?p=82
Wednesday, November 16, 2011
[Linux] 新增使用者、群組進sudoers
關於sudoers: 就是可以做 sudo 的傢伙們,以下先簡介一下sudo功用
Linux系統下,有許多機密的操作是需要root權限的,有如Win下的Administrator
所以呢,要取得root權限有兩個方法,
第一個是取得root的密碼,直接登成root,阿root密碼給太多人知道總是不好,
這時就要用sudo了!
這種做法是認定某些人是有此權限的,這些人只要在指令前冠上 sudo ,
接著系統會問你"自己的密碼",以確定你是本人,密碼正確後就會執行指令了
例如:想立即關機
法一:登入root
法二: 利用sudo
-----------------------------------------------------------------------------------------------------
然後,用小指甲也知道,如果隨便人都可以用sudo的話,那root如同虛設了
sudoer的設定檔在/etc/sudoers,不過不建議直接暴力法改,這裡介紹指令法
假設我要加入Spencer這個使用者,wheel這個群組進sudoers
(以下皆須以root權限執行)
把這兩行註解掉,不然他問你密碼還是問root密碼,白搭!
加入以下幾行:
阿如果想偷懶到連自己密碼都不打的話可以這樣
如果想限制只有某些指令有權限的話可以這樣(/bin/mount及/bin/umount為例)
Spencer ALL=(ALL): /bin/mount,/bin/umount
(在冒號之後有空白喔!
存檔,重新登入
----------------------------------------------------
然後順便寫一下新增群組跟把使用者加入群組,在此只寫指令法
新增群組(group):新增wheel 群組
把使用者Spencer加入wheel群組
如果新增Spencer時就要加入wheel群組,也開個個人資料夾
spencer:~ # useradd -G wheel -m Spencer
Linux系統下,有許多機密的操作是需要root權限的,有如Win下的Administrator
所以呢,要取得root權限有兩個方法,
第一個是取得root的密碼,直接登成root,阿root密碼給太多人知道總是不好,
這時就要用sudo了!
這種做法是認定某些人是有此權限的,這些人只要在指令前冠上 sudo ,
接著系統會問你"自己的密碼",以確定你是本人,密碼正確後就會執行指令了
例如:想立即關機
法一:登入root
spencer:~ # su
[輸入root密碼]spencer:~ # shutdown -h now
法二: 利用sudo
spencer:~ # sudo shutdown -h now
[輸入自己的密碼] -----------------------------------------------------------------------------------------------------
然後,用小指甲也知道,如果隨便人都可以用sudo的話,那root如同虛設了
sudoer的設定檔在/etc/sudoers,不過不建議直接暴力法改,這裡介紹指令法
假設我要加入Spencer這個使用者,wheel這個群組進sudoers
(以下皆須以root權限執行)
spencer:~ # visudo
#他會打開一個暫存檔讓你編輯,確定格式正確以後才會寫進真的sudoers檔去把這兩行註解掉,不然他問你密碼還是問root密碼,白搭!
#Defaults targetpw # ask for the password of the target user i.e. root
#ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!
加入以下幾行:
Spencer ALL=(ALL) ALL
%wheel ALL=(ALL) ALL
阿如果想偷懶到連自己密碼都不打的話可以這樣
Spencer ALL=(ALL) NOPASSWD: ALL
%wheel ALL=(ALL) NOPASSWD: ALL
如果想限制只有某些指令有權限的話可以這樣(/bin/mount及/bin/umount為例)
Spencer ALL=(ALL): /bin/mount,/bin/umount
(在冒號之後有空白喔!
存檔,重新登入
----------------------------------------------------
然後順便寫一下新增群組跟把使用者加入群組,在此只寫指令法
新增群組(group):新增wheel 群組
spencer:~ # groupadd wheel
把使用者Spencer加入wheel群組
spencer:~ # usermod -G wheel Spencer
如果新增Spencer時就要加入wheel群組,也開個個人資料夾
spencer:~ # useradd -G wheel -m Spencer
Subscribe to:
Posts (Atom)