當你們跟我們變成我們 , 小心到最後我們都不我們了

當你們跟我們變成我們 , 小心到最後我們都不我們了

在很多書或是文章中都提到 , 與他人溝通要讓對方產生同理心 ,
最好是要使用 "我們" , 而不是 "你們" ;

這原則我不是不知道 , 但是問題是要看用在甚麼時後跟什麼地方 ,
明明就是應該要確認工作跟指派分工 , 不說清楚獎明白 , 還在哪邊 "我們" , "我們"的 ,
到底是誰要負責作?

所以在職場中 , 如果有兩個部門在合作一項事務時 , 各有各的職責並需去負責跟作業時 ,
你的相關文件或是 Email 要怎麼寫?

範例一:
你們XX部門需要負責工作A
我們YY部門需要負責工作B

有些人看了就會說 , 這樣不是違反上面說得 , 不要使用你們 , 而是要用我們的原則嗎?
好吧 , 那就來改吧!!!


範例二 :
我們需要負責工作A ,  工作B

收到信件的兩個部門的相關同仁 , 看到 "我們需要負責工作A ,  工作B"
XX部門同仁的想法:
(a)我們部門需要連 YY 部門的工作B 也一起作嗎? ,
(b)嗯 , 發信的是 YY部門 , 所以我們指的是 YY 部門 , 所以統統都是 YY部門要負責

YY部門同仁的想法: 我們部門需要連 XX 部門的工作A 也一起作嗎?
(c)我們部門需要連 YY 部門的工作B 也一起作嗎? ,
(d)嗯 , 發信的是 XX部門 , 所以我們指的是 XX 部門 , 所以統統都是 XX部門要負責

 要嘛就是
(1)兩個工作都由單一部門全包了 , 一個部門閒閒沒事幹
(2)兩個部門都不作 , 以為對方要負責 , 結果都沒人作
(3)兩個部門都做了全部的工作 , 結果重工 , 兩邊的人力負擔都很重 , 而且有可能還作不好 , 因為做的不是自己部門專長的工作
(4)最佳狀況 , 兩個部門自己知道Email 中的我們要負責的工作有那一個是自己部門要負責的

如果Email通知或是文件中寫的都是"我們" ,
請問有問題發生了 , 是誰要負責? , 是"你們"要負責 , 還是 "我們"要負責? , 還是"大家"要負責?
當你們跟我們變成我們 , 小心到最後我們都不我們了?



當 User 單位給錯計算公式 , IT 照著公式去開發系統 , 到最後算錯錢的時候 ,
是 User 單位要負責 , 還是 IT 單位要負責 ? 是"你們" , 還是"我們" 要負責 ?


那麼 ? 你告訴我 , 在需要大家協同合作 , 跟責任分工的情況下 , 是要用 "你們" , 還是要用 "我們"?
(大部分的狀況下是:
 我們有工作要作 , 我們指的是 "我"方 , 另外的"們" , 是不用做事的那一方
 當問題發生了 , 我們 , 有問題要處理 , 這時候絕對會變成 "我"方 , 或是"你們"有問題要處理...


在企業環境下 , 如果有人老是拿著"我們"來跟你要求時 , 請小心 ...
就問這麼幾點 , 作好了 , 績效是我們的 , 還是你們的 , 作不好 , 問題是我們的 , 還是你們的....


當 User 拿著錯誤的公式要求 IT 照著錯誤公式寫出系統時 , 結果要收的錢 , 或是要付的錢算錯了 ,
請問 , 當發生問題時 , 公司對外會講甚麼 ? 是 IT 的系統寫錯了 ? 還是 USER的公式給錯了? 所以算錯錢?
這時候 , 80% 都會變成是 IT 的問題 !!! , 不相信去看看大部分的新聞案例 ,

很多時候 , 提出錯誤需求的 User 方多半是把責任撇的一清二楚的 ,....
這時候是我們還是你們....
)


還有很多時候是 User 要系統上線要的十萬火急 , ...
但是 IT 請 User 提供必要的需求說明或是進行確認時 , User 可以拖個 2 , 3 週不回應 ,
直到時間到了 , 又回過頭來怪 IT 延誤....
請問這個時候要怎麼寫 Email ,

原本是要寫 "要請 User 單位儘速確認 xxx 需求文件是否有誤"
變成是要寫 "要請 我們儘速確認 xxx 需求文件是否有誤"  , <-- User 收到這樣的Email 會理你才有鬼 , IT發的Email , 講的是"我們" , 當然是 IT要確認

所以當你們跟我們變成我們 , 小心到最後我們都不我們了
當分工與職責劃分不講清楚前 , 濫用同理心原則 , 到處講我們 , 根本是擺爛的態度....


在很多書或是文章中都提到 , 與他人溝通要讓對方產生同理心 ,
最好是要使用 "我們" , 而不是 "你們" ;

這原則我不是不知道 , 但是問題是要看用在甚麼時後跟什麼地方 ,
明明就是應該要確認工作跟指派分工 , 不說清楚獎明白 , 還在哪邊 "我們" , "我們"的 ,
到底是誰要負責作?


水患發生了 , 如果政府內部會議 , 還在強調 , "我們"要搶救災民 , "我們"要調配物資 , "我們"要提供急難救助 ,
"看" ,
你就看看 "我們"是"我們"的那些部門或是哪些單位要負責?



明明就是應該要確認工作跟指派分工 , 不說清楚獎明白 , 還在哪邊 "我們" , "我們"的 ,
到底是誰要負責作?

不會煮菜的寫不好程式 , 當不好PM

不會煮菜的寫不好程式 , 當不好PM <--這個標題 , 純屬瞎掰 , 有無道理容後說明

在一些程式設計網站 , 最常見的初學者或是初入職場的人問的問題?
某某程式 , 不知道從何寫起 , 或是不知道從如何寫?

我敢打包票 , 這些人大概不會煮菜 ,

首先 , 你要煮菜前 , 要上菜市場買菜 ,
買菜也分為兩種 , 一種是隨便買亂亂買 , 一種是有目的的買
例如: 你已經盤算好了 , 今天要煮 排骨蘿蔔湯 , 炒高麗菜 , 糖醋魚 , (關於怎麼配菜也是問題)
那你要買 的材料絕對是要煮這三樣菜的材料 , 絕對不會搞個冬瓜回家 , 也不會搞個雞回家...
為什麼 , 你已經決定好的要煮的菜 , 而要煮的菜 , 絕大部分都有固定的食譜 , 也就是有固定的配料跟調味料的樣式 ,

那跟寫程式有甚麼關係?

有的人寫程式是這樣寫的 ,
"我要寫個可以兩人對戰的網路遊戲" ,
 "但是我完全不會寫" ,
 "希望有人教教我 " ,
 "要有範例 ",
" 而且必須是藥用 C# 寫的" ,
"還有 , 我很急 , 就在線上等 , 請趕快回覆"
這樣很了不起的網路問問題的大爺問法 , 看過沒有? , 我看過 n 次...

有點扯遠了 , 這跟煮菜何干 ?
"我要寫個可以兩人對戰的網路遊戲" , <----- 我要煮個兩人吃的菜
 "但是我完全不會寫" ,                            <----- 但是我完全不會煮
 "希望有人教教我 " ,                              <----- 希望有人教教我
 "要有範例 ",                                           <----- 而且要有食譜
" 而且必須是藥用 C# 寫的" ,                <-----最好要有@XO#
"還有 , 我很急 , 就在線上等 , 請趕快回覆"

如果你就是那個人 , 你要如何回答問題
 我要煮個兩人吃的菜         <----- 首先問問題的方法就是錯了 , 要煮甚麼菜沒有說清楚 , 十分發散
                                                         如果可以決定要煮甚麼菜了 , 下面的問題就簡單了
                                                         例如：要煮佛跳牆
 但是我完全不會煮            <----- 我也不會煮佛跳牆
 希望有人教教 我               <------- 現在這個時代當然是要上網查 , 有食譜 , 有作法
 而且要有食 譜                  <----- 

剩下的是甚麼? 準備材料 ,
買回來的材料 , 還要一一經過整理清洗 , 看是要切絲 , 切塊 , 切條 , 切丁 , 反正看要煮甚麼菜 ,
相同的材料 , 用在不同的菜上面就要用不同的處理方式 ,

竹筍炒肉絲 , 如果你硬要切塊 , 切丁也不是不行 , 只是口感會不好...
(一 般來說 , 一道菜 , 如果有切絲的 , 那相關材料都是切絲 , 要不就全切丁(EX:  生菜鴿鬆 , ))
又有點跑題了....


但 是萬一 , 碰到一個你不曾用過的材料的時候怎麼處理?
先去學如何處理那個材料 , 那個材料會處理了 , 菜大概也成功一半了
(菜的烹 調方式也是一樣 , 哪裡不會 , 有需要就學 ,)


另外一點就是處理材料的方式 ,
有的人煮菜 , 會把所有材料全部先處理好 , 該洗 , 該泡 , 該削皮 ,  該切絲 , 該切丁 , 該醃的 ,
全部在生火之前 , 全部弄好 , 而且會把材料一一放到適當的剛盆 , 調理碗 ,
等到要生火 , 倒油熱鍋時 , 就只需要 , 把事先準備好的材料 , 一一下鍋 , 等火候到了 , 加調味料 , 起鍋 , 菜就煮好了 , 這種煮法 , 就不會手忙腳亂 ,


另一種人是一邊生火熱油 , 一邊才開始想要先煮哪道菜 , 然後才發現 , 材料的主菜還沒洗 , 趕快隨便洗洗 ,
鍋子已經在冒油煙 , 趕快胡亂切切 , 丟下鍋 , 突然發現 , 還有配菜 , 還放在冷凍庫 , 趕快拿出來 ,
還是結冰狀態 , 趕快用刀坎 (砍得動才有鬼) , 不得已 , 只好把冰凍的配料丟下鍋 , 這時主菜因為剛剛沒空翻它 , 已經呈現焦黑狀 , 而附菜 , 還是冷凍狀態 , 只好加大火煮 , 主菜黑焦的更兇 ,
過 了30分鐘 , 附菜是外面焦黑 , 裡面半生不熟 , 而主菜已經剩下黑炭了....
然後呢 , 等到一個小時之後 , 終於整道菜已經熟了(也焦了)
你還要加個調味料起鍋 , 然後把它吃下肚嗎?


有沒有發現 , 煮菜的方式 , 會碰到的狀況 , 也跟我們在開發程式或是在進行專案管理很雷同...
如果你不預作準備 , 就要胡亂去煮 ,  失敗的機率絕對很高....

===== 煮菜 vs 專案管理 對照篇======
但是如果你"會煮菜" , 那麼相信你在進行程式開發 , 或是進行專案管理應該也是有條不紊 ...
首 先先決定煮甚菜 (決定範圍 ,  主題)
進行材料採買        (決定資源 , 配置資源)
進行材料前處理 ,    (確認活動)
決定下鍋優先順序 , (進行活動排程)
確認菜都熟了 ,        (執行專案活動 , 進行品質驗證)
加調 味料 ,              
起鍋上桌                 (專案完成結案)



===== 煮菜 vs 程式開發 對照篇======
首先先決定煮甚菜 (決定要寫甚麼方面的程式)
進行材料採買        (決定需要用到哪些技術 , 網路通訊 , 壓縮 , 3D , 加密???)
進行材料前處理 ,    (確認 那些技術要如何使用 , 進行簡單學習確認)
決定下鍋優先順序 , (轉寫煮程式 , 將各個單項技術模組化撰寫測試)
確認菜都熟了 ,        (將各個模組合併在一起完成主程式)
加調味料 ,              
起鍋上桌                 (程式完成)

Mediawiki 的錯誤應用方式

Mediawiki 的錯誤應用方式

我對 Mediawiki 的認知:
Mediawiki 眾所周知就是共筆系統 ,  是大家可以一起分工寫一篇文章(或是很多很多篇文章)
這樣的系統提供的是一個"活的"文件系統

什 麼是活的文件系統
就是一份文件可以不斷的成長(它可以是某甲創造出來  , 某乙編修 , 某丙審核)
同時它也提供了整個的歷程檢視跟版 本控管 ,
每個修改歷程都被紀錄下來



對於公司來說 , 如果要把Mediawiki 用在系統開發上 ,
就 是可以把手冊(使用者手冊 , 安裝手冊 , XXX手冊)
都透過 Mediawiki 撰寫 ,

甚至於可以是一個主編把某份 文件的大綱訂出來後 ,
讓多個人同時分工去編輯大綱下的某個小節的內容
Mediawiki 也提供針對內容進行全文檢索功能


OK , 接下來 , 要來講錯誤的Mediawiki 應用方式
聽過某間公司的某個單位 , 他們是這樣用Mediawiki的 ,
他們只 是把 Mediawiki 當作一個擺文件的Portal ,
所有的文件都是WORD , PDF 等等 , (一堆專案文件的檔案)
然 後只把  Wiki 本身只是拿來作這些文件的LINK 入口 ...

Oh...天啊 , 真的錯很大 ,... ,
如果要 這樣用 , 不如搞個檔案管理系統 , 例如 MS Share Point Portal Server
這種用法根本就沒有發揮 Mediawiki 的效用 ,...,
真正專案的內容都藏在附件檔案(WORD , EXCEL , PROJECT)檔案中 , 這樣子要 Wiki 做什麼?

共筆系統就是頁面內容就是文件 , 就是你要賦予它生命的地方 , 它可以被很多人擴充 , 被討論 , 被修改 ,
所 以當你要寫專案範圍或是需求範圍時 , 甚至可以請 User 上去寫屬於他們的部份 ,
然後你們這方可以在 User 寫完的同時 , 也針對審閱的看法 , 直接進行修改或是說明審閱的意見 ,
因為它有版本歷程 , 所以每一次修改 , 都像是活的 ,(因為每一頁內容  , 都可以加上一串討論 , 所以線上討論的結果 , 搭配內容 , 就像是每一次會議紀錄 加上 最後的產出)
也因此 , 它可以是最佳的線上即時專案內容的匯總區 , + 討論區 , + 即時的專案規格區...

想想 , 每次當你使用 WORD 寫了第 1 版的專案文件 , 然後 User 看過 , 大家就可以指指點點 , 然後再加上你的主管 , User 的主管 , 主管的主管 , 甚至開發商 , 到最後 WORD 檔可能是第 n 版 , 但是討論的過程不見了 , 被修改的某個條文 , 出自於某個人的要求變更 , 也沒人知道...

最 重要的是文件最好不要同時散給多個人過目 , 否則修改的地方有衝突就糟了 ,
反之 ,  使用 Wiki 就是讓每個人都發表意見 , 但是同時 , 每個人修改的地方 , 也都留下歷程 ,
不論是改的好或是改的不好 , 也都可以讓後來者有跡可循

再說 , 很多公司或是企業最喜歡導標準化文件 , 但是常常第一關 ,
同類的文件 , 結構大不相同 , 或者是同一份WORD文件光是要調整結構 , 就要能搞得不是很聽話的WORD
使用 WIKI 則不需要 , 因為它的段落結構就是哪樣 , 只要訂出一個範例的段落結構 ,(或是樣板模板)
其 他人就很容易共用


拜託 , 不要再拿 Mediawiki 來當垃圾掩埋場 ,
(專案文件檔案一大堆 , 當作 link 附件 , 埋進去 , 你會重新找的到 , 然後拿出來用才有鬼  ）

每種軟體必有其適用之處 , 有其強項所在 , 也有其弱項所在 ,
拜託別亂用 , 用完之後 , 就說某某軟體很難用...

碰到這種開著數頓吊車吊一盒雞蛋上 5 樓 , 然後還要怪吊車很難用 , 這種人還蠻多的....
也不要開著跑車 , 硬是想要當作送菜大卡車 , 要把 幾十簍的高麗菜運來運去的


冷 完了....
拜託 , Mediawiki 不是垃圾掩埋場 , 不要再亂埋文件了....
(這不是肯得雞....很老掉牙的廣告台詞 了.....)

在UBUNTU 上玩 COBOL -使用備忘錄

在UBUNTU 上玩 COBOL -使用備忘錄
UBUNTU 8.10 , Eclipse 3.4 , Cobol IDE , Open COBOL ,

注意事項:
以下的 COBOL範例(Hello.cob , Hello3.cob)是我參照
Teach Yourself COBOL in 21 days Second Edition
上面的 入門範例 , 所改寫出來的 , 僅供測試使用


(1)下載安裝 Cobol IDE
Download Cobol IDE
http://www.eclipse.org/downloads/download.php?file=/cobol/downloads/cobol_plugins_3.4.0_linux32.zip
解 壓縮 cobol_plugins_3.4.0_linux32.zip
然後把解開之後 features & plugins 複製到你的 Eclipse 目錄下

(2)安裝 OpenCobol
Synaptic套件安 裝程式 , 輸入 Open-Cobol 然後就可安裝

(3) fujitsu cobol 手動建立連結 (可忽略此步驟)
ln -s /usr/bin/cobc /opt/FJSVcbl/bin/cobol
cobc  是open-cobol 的執行檔 ,
cobol 是 fujitsu cobol (net cobol) 的執行檔
在這裡是為了欺騙 Cobol IDE 的自動建置(build.xml) - 詳情後述

(4)執行 Eclipse

(4.1) 建立cobol專案
File -> New -> Other -> COBOL -> COBOL Project(圖片 COBOL-001.jpg)
p1

Project name:輸入 MyLabCOBOL001(圖片 COBOL-002.jpg)按下Next
p2

Target name:輸入 MyLabCOBOL001(圖片 COBOL-003.jpg)按下Finish
p3

(4.2)建立cobol source - Hello.cob
在專案下的Source Files按下滑鼠右鍵 ,出現功能表
New -> COBOL Source(圖片 COBOL-004.jpg)
File name: 輸入 Hello
PROGRAM-ID: 會自動同上面的名稱也是 Hello
按下Finish
p4

(4.3)修改 Hello.cob 的內容
COBOL IDE 會自動建立 Hello.cob 預設內容如下(圖片 COBOL-005.jpg)
p5

修改Hello.cob 為以下內容(圖片 COBOL-006.jpg)
====Hello.cob START=====
*Hello.cob
 IDENTIFICATION DIVISION.
 PROGRAM-ID.   Hello.
 ENVIRONMENT    DIVISION.
 CONFIGURATION  SECTION.
 DATA DIVISION.
 WORKING-STORAGE SECTION.
 PROCEDURE DIVISION.    
 PROGRAM-BEGIN.  
     DISPLAY "你說中文也會通".
 PROGRAM-EXIT.
     EXIT PROGRAM.

 PROGRAM-DONE.
     STOP RUN.

END PROGRAM Hello.
====Hello.cob END=====
p6

(4.4)手動編譯 Hello.cob 這隻COBOL
開啟終端機視窗(要切換到你的專案所在目錄) ,
輸入以下指令
cobc -o Hello -x Hello.cob

命令說明如下：
告訴它輸出的執行檔的名稱是 Hello(-o Hello) ,
要編譯 Hello.cob 為執行檔(-x Hello.cob)
編譯的時候如果有警告可以暫時不理會 , 只要它會過就可以


如果沒有問題 , 我們的第一隻 Cobol 程式已經完成編譯 , 可以執行
開啟終端機視窗 , 輸入以下指令
./Hello
程式執行結果顯示 "你說中文也會通"(圖片 COBOL-007.jpg)
p7

(5)解說為何要設定在 (3) fujitsu cobol 手動建立連結
回過頭來看專案目錄下有一個 build.xml (圖片 COBOL-008.jpg)
p8

其中的COBOL編譯器設定是 /opt/FJSVcbl/bin/cobol
但是 UBUNTU 上面並沒有  fujitsu cobol  , 所以我們只好手動的建立連結去欺騙 COBOL IDE的動作
事實上 , (3)不做 , 也不會有問題,(只是會在IDE的CONSOLE出現編譯錯誤訊息)
因為我們是要手動編譯(4.4)

注意：
不要嘗試著 去修改build.xml , 因為COBOL IDE 會在你修改或是新增 COBOL SOURCE 之後
重新產生 build.xml , 等於你修改的統統無效 , 而且它會在你每次按下 Ctrl + S存檔之後
就去執行 build.xml
這個是沒有甚麼效用的 , 當然你可以去拿 COBOL IDE 的 SOURCE 重新修改跟調整之後變成你要的
但是在這邊 , 我只要要玩玩COBOL, 只是利用 COBOL IDE去顯示COBOL語法的標記
所以我只用最快速的方法 , 讓它可以執行
有興趣要改build.xml 請參閱附錄2 , 但是沒什麼效果


(6)新增 COBOL SOURCE - Hello3.cob
內 容如下
====Hello3.cob START====
*Hello3.cob
 IDENTIFICATION DIVISION.
 PROGRAM-ID.   Hello3.
 ENVIRONMENT    DIVISION.
 CONFIGURATION  SECTION.
 DATA DIVISION.
 WORKING-STORAGE SECTION.
 01  FIRST-NUMBER      PICTURE IS 99.
 01  SECOND-NUMBER     PICTURE IS 99.
 01  THE-RESULT        PICTURE IS 999.
 01  THE-NAME          PICTURE IS XXXXXXXXXX.
 01  THE-MESSAGE       PIC X(20).
 01  THE-NUMBER        PIC 99(2).

 PROCEDURE DIVISION.    
 PROGRAM-BEGIN.
     DISPLAY "Enter the first number:(0-99)".
     ACCEPT FIRST-NUMBER.
     DISPLAY "Enter the second number:(0-99)".
     ACCEPT SECOND-NUMBER.
     COMPUTE THE-RESULT = FIRST-NUMBER + SECOND-NUMBER.
     DISPLAY "The result is:" THE-RESULT.
     
     MOVE "HELLO " TO THE-MESSAGE.
     DISPLAY "Enter someone's name.".
     ACCEPT THE-NAME.
     DISPLAY THE-MESSAGE THE-NAME.
     
     MOVE 12 TO THE-NUMBER.
     COMPUTE THE-RESULT = THE-NUMBER + 99.
     DISPLAY THE-NUMBER "+ 99 = " THE-RESULT.     
     CALL "Hello".
  PROGRAM-DONE.
     STOP RUN.   
 END PROGRAM Hello3.
====Hello3.cob END====

(7)編譯及執行 Hello3.cob(圖片 COBOL-010.jpg)
開 啟終端機視窗(要切換到你的專案所在目錄) ,
輸入以下指令
cobc -o Hello3 -x Hello3.cob

如果沒有問題 , 我們的第2隻 Cobol 程式已經完成編譯 , 可以執行
開啟終 端機視窗 , 輸入以下指令
./Hello3
它要你輸入數字(first number): 請隨便輸入0~99的數字 , 按下Enter
它要你輸入數字(second number): 請隨便輸入0~99的數字 , 按下Enter
畫面會顯示兩個數字加總的結果

然後要你輸入命名(someone's name): 請隨便輸入 , 按下 Enter
畫面會顯示 HELLO %你輸入的姓名%

然後畫面最後一行會出現
libcob: Cannot find module 'Hello'

這個是我們的程式中有呼叫Hello的外部Module , 但是它找不到對應的 Hello.so

所以我們重新編譯 Hello
開啟 終端機視窗(要切換到你的專案所在目錄) ,
輸入以下指令: 注意這次不要加額外的參數
cobc Hello.cob
p9

然 後重新執行 Hello3 (Hello3不需要重新編譯)
./Hello3
最後你可以看到 Hello3成功的呼叫  Hello並且顯示 Hello的內容在畫面上
(圖片 COBOL-011.jpg)

p10

cobol 呼叫外部 MODULE的成功關鍵點在於 XXX.so是否可以存取的到
p11

如果你有按照我上面的步驟 進行
那麼 , 那麼你應該在  60 分鐘以內可以完成上面的動作

包 含建立 COBOL SOURCE , 編譯 , 執行
還包含了 CALL 外部的 MODULE ,
就是這麼簡單 ,
備忘錄 就是備忘 ,


附錄1:
Open-COBOL可以檢查語法的相容性 ,如果是要檢查是否符合IBM的COBOL
加上 -std=ibm ,
範例：
cobc -std=ibm -o Hello -x Hello.cob

附錄2: (如果你不會 Java就不要理會這段了 , 這段有玩Java的會知道在做什麼)
自 建立ANT build2.xml (為何不建立 build.xml , 因為會被COBOL IDE給蓋掉)








   



   




執行的時候
ant -f build2.xml

run-cobol.sh 內容如下
cobc -std=ibm -o $1 -x $2

也因此我才不建議直接去修改 build.xml>


附錄3：
COBOL範例程式電子書 , 這本內容夠淺顯(請自己上網路上找 , 有WEB版)
Teach Yourself COBOL in 21 days Second_Edition

在UBUNTU上玩COBOL到此結束 

帶著台灣過了八年苦日子的前執政黨出來挺扁了

帶著台灣過了八年苦日子的前執政黨出來挺扁了

曾經有某執政黨說 大家要有心理準備過苦日子...
一過 8 年過去了,...

民眾過的是苦日子,....,
但是某執政黨的高層幹部 , 個個肥水滿滿 ,

不知道這個黨還有臉出來說別人?

另外拜託一下 , 這個黨的支持者能不能有點水準 ,
不要以為加入這個黨就可為所欲為 ,

看到的是 , 在台北捷運電扶梯 , 把左邊的通道統統堵住 , 原本可以讓人通行的 , 也統統堵住
然後呢在捷運上 , 嗓門特大 , 好像怕人不知道他們是某政黨來挺扁的...


還有那種 , 橫越快車道的....<你當作是某些政黨執政的縣市嗎 ? 可以不用看紅綠燈 , 可以不用理會交通法規?  想怎麼過馬路 就怎麼過馬路嗎 ? >

拜託 , 某某政黨 , 不要老是以為天大地大你們政黨最大....
(甚麼時候私人政黨的糾察隊還可以行使警察權去侵害過路人的自由權? 過路人就不能去說話?)


挺貪腐的黨至今依然挺貪腐...

讓小學生加法可以進步的撲克牌遊戲 - 99 點

讓小學生加法可以進步的撲克牌遊戲 - 99 點

讓小學生加法可以進步的撲克牌遊戲 - 99 點

這個是上週妹妹為了我生日請我吃飯的事 ,

到妹妹家 , 教妹妹的女兒玩的撲克牌遊戲 - 99 點

這個遊戲一玩 , 馬上就會知道小朋友的加法有沒有問題

當然小朋友要玩的高興 , 就會發現如果加法很差 , 算的很慢 , 就不好玩了

遊戲規則:
(1)撲克牌 52 張 ,
     K: 直接跳到 99點
     Q: + - 20點
     J:  Pass
    10: + - 10點
     4: 反轉遊戲出牌方向
    其他都是按牌面點數去加
(2) 3 ~4 人 (2 人也可以)
    洗好牌後 , 每人先發 5張牌 , 剩下的牌放中間 ,
   順時針方向出牌 (碰到有人出 4 的牌 , 就變成反方向)
(3)輪到出牌的人 , 要出一張牌 , 並且喊出出牌後最後的點數 ,
   例如: 目前已經是 87點 , 輪到你 , 你出了 紅心8 , 則要喊出 95 ,
  其他的牌 , 如規則(1)

(4) 如果手上的牌 , 一出出來就會超過 99 點 , 則輸 , 該人出局 , 剩下的人繼續玩...

因為在玩的時候 , 要喊出加到幾點了 , 所以碰到小朋友加法有問題的 ,
馬上就會察覺 ,
而小朋友 , 在玩的高興的時候 , 如果碰到自己出牌就要加法加很久才有答案 ,
小朋友自己也會知道自己的加法不好 ,
不過沒關係 , 99 多玩個幾輪 ,
至少加法應該會進步...


(大人欺負小孩啦...)


<其實 99 點小朋友也可以彼此練習>

幫EXCEL XLS檔瘦身

幫EXCEL XLS檔瘦身

在 EXCEL 如果有不斷的複製剪下或是修改
有時候資料一多 , EXCEL 檔就會不斷膨脹
有時候在EXCEL檔就會變得太大 在透過eMail傳送時
可能會送不出去

這時候Open Office 就派上用場了

方法簡單到一個不行 ,
打開 Open Ofiice 的 Open Office Calc ,
用它開啟你的 Excel xls 檔案 ,然後 另存新檔 , 確定它是存成 Office 2000格式


這樣就完成了

前幾天幫同事的 Excel 檔案瘦身 , 從 10.5 MB 左右 , 變成 3 MB大小

就這麼簡單 , 沒有甚麼絕招 , 只要 開啟 , 另存新檔 就幫 Excel 檔案瘦身了....


===============================================
補續: 後來用 Google 查了一下 excel 瘦身
發現有大陸人寫的文章 ,
裡面巨細靡遺的說明了 , EXCEL要作多少注意事項才能避免 EXCEL 檔案越來越肥大

如果你碰到一般的User , 要把這些注意事項跟他們講完 , 可能天都黑了
如果你很勤勞  , 可以去看看那篇大陸人寫的文章(大陸網站相同的文章四處都會出現)

如果你很懶 , 那麼用用我上面介紹的 Open Office Calc ,
開檔 , 另存新檔 , 兩個動作 就可以幫 EXCEL 檔案瘦身了...