公告版位

目前日期文章:200810 (13)

瀏覽方式: 標題列表 簡短摘要

我們身為醫院的IT部門、MIS部門人員,有非常多的甘苦,平常做不完的資訊需求,開不完的會議會讓我們喘不過氣來,身在這個環境中,每天都是挑戰,常常都得面對「關關難過,關關過」的狀況,誰都不會知道這個環境中的意外狀況何時會來臨(你永遠不知道,明天與意外哪一個先到~達賴喇麻)。

當資訊系統發生意外事件發生的時候,通常會搞的雞飛狗跳,這時候對於該系統的管理者或負責人而言一定緊張的要死,當然,我們的職責就是讓這起資訊意外儘快平息,讓資訊作業在最短的時間內回復,絕大部分的問題都得靠我們這個團隊專業來做解決,查程式的查程式,該查網路的查網路,該看資料庫的看資料庫,但,如果這系統是外包(或合作廠商)的呢?程式查不到,資料庫也看不到,能做的有限,唯一看到的是一堆氣急敗壞的User,這時候我們的專業人員既然無法介入解決資訊問題,那我們應能做些什麼?除了一邊打電話找廠商解決,另一方面應該要幫忙我們這些著急的User們,怎麼幫?替代方案,緊急應變,情緒安撫.....等等,這些是外包廠商無法提供的服務,在資訊人員無法以資訊專業來解決問題的這個時候,我們就必須提供一線人員快速的回應,讓他們知道我們在處理了,讓他們感受到資訊人員正在努力。

在資訊人員無法介入處理資訊問題的時候,應適時的建立起狀況傳遞的角色,一方面將User異常狀況回報給廠商,最快速的資訊更新,一方面親臨現場去蒐集更多更深入的資訊錯誤,親臨現場雖無法馬上排除錯誤狀況,但卻能讓User看到資訊人員的積極,縱使資訊故障排除緩慢,User看到資訊人員也在盡力,應該也不致於太過苛責了。

資訊外包,這是一項企業都會面臨的問題,只是外包種類與大小不同罷了,資訊外包,不是單純花錢把IT買進來這麼單純,外包後也不是完全沒MIS部門的責任了,當發生資訊意外事件的時候,User的腦海裡一定不會出現自己的系統還是外包系統的界線,一定都是「資訊室的問題」,找資訊室就對了!因此,MIS人員有必要做好外包管理,更要認清我們是站在廠商的最前線,發生問題的當下絕對不是釐清問題撇清關係,應該是「解決問題」為優先。


lcjan 發表在 痞客邦 PIXNET 留言(1) 人氣()

9月底,第一次看完海角七號,哇賽!百年難得的好片,一定空前也絕後,真想再看第二次,一直鼓吹同事去看,不是沒時間就是沒意願,好吧!正好申請了一筆論文投稿獎金5000,來個大放送!大家一起看電影,當然這事情不能讓老婆知道囉(他要在家顧小孩,我也沒一次花過這麼大筆錢請他),開始進行計畫.

前一週:
鈿鈿自己的預算, 來去親親戲院, 票價210, 全部應該夠. 有人反映, 去德安威秀啦! 那裡比較讚, 親親也比較遠....... ok, 雖然票價貴了一些(230), 預算還夠. 走吧!

前三天:
為了省點開銷, 上網去看了團體票, 呦, 一次買10張有優惠喔, 打電話去問看看, ㄟ有含爆米花飲料耶! 決定買20張. 回來有同仁問, 有無爆米花, 哈!有啦有啦! 安啦

lcjan 發表在 痞客邦 PIXNET 留言(0) 人氣()

觀察了一堆技術人員,真的很不一樣,明明都在寫程式,能力耐ㄟ差架揭!

歸納了一下我的觀察,寫程式的人在從入門到精進的過程中常遇到的瓶頸:

不懂
  書看不懂。明明寫的是繁體中文,有看沒有懂。

  英文看不懂。打開程式設計軟體的Help說明...不到兩秒...關掉。

lcjan 發表在 痞客邦 PIXNET 留言(0) 人氣()

   在程式設計的經驗中,我時常遇到一些資訊系統的問題,這些問題時常耗費一堆人的時間來除錯,寫程式的人應該常遇到這些問題,但遇到時又時常束手無策。

1. Windows藍底白字:
        


lcjan 發表在 痞客邦 PIXNET 留言(0) 人氣()

今天上作業系統的課,講到「行程管理」。主要是說明我們電腦裡面的作業系統(Ex:Windows)如何進行各種程序的排程,已將唯一(或少量)的CPU資源進行排序處理,已增加CPU資源的最佳使用率。

其中有幾樣是「行程管理」的基本型:
1. First Come First Served, FCFS,先到先做。
    將所有工作依照時間點排序,先到的先做,依序做完。

lcjan 發表在 痞客邦 PIXNET 留言(0) 人氣()

今天上班把我10/10到埔里三育學院拍的照片E-Mail給同事看(Blog上面那張是其中之一),
已經努力後製處理了,起初有人覺得那裡很漂亮,
接著,我再轉寄DCView上面一些大師級的照片,

一比之下,果然,什麼是專業馬上見真章,
這驗證了一句老馬(同事)的話「有些事是學不來的」!@

lcjan 發表在 痞客邦 PIXNET 留言(0) 人氣()

"演算法"可真是不簡單。
寫了七八年的程式,第一次上演算法課程,
彷彿回到高中時期,數學,維基分當掉,痛苦上課的模樣

沒學過演算法就無法寫出好程式嗎?
我是應用工程師,不是發工程師,

lcjan 發表在 痞客邦 PIXNET 留言(0) 人氣()

From :「態度萬歲」
『   學到東西叫準備
      建立關係是機會
      若要隨時有機會
      就要時時作準備  』

lcjan 發表在 痞客邦 PIXNET 留言(0) 人氣()

    若擔心程式碼跳出錯誤訊息而導致程式運作停止, 必須由人工去檢視與處裡錯誤訊息, 確實是會大大影響一線作業人員, 但不跳訊息的代價是什麼?就是凡出事就call 程式負責人, 要不自打開程式(系統組可能不行), 要不call 主管,不管誰來處理, 總是有人得開啟程式來追蹤錯誤, 不然請大家回答我"存檔失敗"背後所代表的原因為何, 錯誤又該如何解決? 光憑這四個字,要解決問題,只有燒香拜拜的份。

    大家有沒有仔細想想,微軟的Windows藍底白字那些Code是秀給誰看的?你高高興興的寫完了作業,在按下存檔的那一刻前,Windows給你一個"藍底白字",這會讓你很生氣,很無奈,也影響你的作業,也影響微軟在消費者心中的品質,微軟工程師大可不Show,他可以這樣做:Windows凡是遇到錯誤,就直接Reset,如果Reset不成功,則把畫面關閉。使用者一問,只要回答硬體不支援、主機板問題、顯示卡問題之類的話。當然微軟不是這樣做的,他們也想從客戶的是用習慣那邊會得一些未被微軟程式設計師察覺的錯誤,因此藍底白字雖然讓消費者生氣,但至少微軟工程師是有跡可尋的,因此Windows的Patch才能有很快的更新(尤其是安全問題)。因此軟體的使用者也必須支援軟體開發者來除錯,大家都是為了更好的軟體品質與更好的作業流程而努力。

        一線作業人所使用的系統順暢度非常重要,只要是程式設計在使用Try時遇到Exception,如果能不顯示錯誤,處理錯誤,那是不是代表這錯誤無關緊要,如果真無關緊要,那確實不要顯示,直接讓程式跑完,出現"存檔完成"不就皆大歡喜。但往往事情都沒那麼理想,既然是程式Exception,大部分都是嚴重錯誤,無法或不應該繼續執行才對,否則往往造成資料不一致、衍生更多Exception,甚至因為資料的錯誤導致其他系統更嚴重的問題。

     有沒有不能跳出錯誤訊息的程式呢?有的,無人操作,不能中斷的程式,大家熟悉的Broker程式就是典型。因為"無人"操作,Show訊息反而會導致程式執行停止,如果程式設計師的除錯方式是將程式跑起來,眼睛盯著看,從早看到晚,到下班前都沒錯誤,ok上線,一回家會發現,馬上被Call,因為Broker程式掛了。這又會有兩個原因:1. 程式設計師將錯誤攔截下來,把訊息Show在畫面上。2. 程式設計師沒有處理錯誤的程序,微軟替你把錯誤Show出來。那該如何處理呢?寫Broker的程式設計師如何除錯?
我的作法:
 

lcjan 發表在 痞客邦 PIXNET 留言(0) 人氣()

/////////////////// 更新技巧及注意事項//////////////
// 當Windows 98有用到造字時或開啟造字程式時會佔住EUDC.TTE ,故更新前必須想辦法欺騙Windows
// 1. 修改註冊檔: HKEY_CURRENT_USER\EUDC\950\SystemDefaultEUDCFont 之造字檔路徑與名稱
// 2. 開啟TrueType造字程式, 讓造字程式依照上述機碼找不到造字檔而自行產生新的, 如此Windows就會對EUDC.TTE解除鎖定
// 3  關閉造字程式

lcjan 發表在 痞客邦 PIXNET 留言(2) 人氣()

    上週因為某User電腦使用檔案交換,只要是該台電腦建立的資料匣在其他電腦都無法正常讀取資料,經查程式後發現應為日期轉換問題,也就是Delphi常用的日期轉換函示。原本用的很習慣的日期轉字串函示,有可能再使用者調整Windows日期格式選項後會造成程式誤判。
 
今日提供簡單測試給大家參考:
 
【WinXP預設狀況】

lcjan 發表在 痞客邦 PIXNET 留言(1) 人氣()

.如何知道Client端的Oracle版本:
    (1) 開啟CMD
    (2) 執行SQL-Plus 檢查版本
    (3) 如圖:
       

lcjan 發表在 痞客邦 PIXNET 留言(0) 人氣()

在這邊工作已經多年,我在溝通的過程中常常遇到一些現象,而且不斷的發生在周遭。某些時候,看到了一些問題或心裡想到一些事情,找了當事人談,往往自己的出發點是好的,可是在談話過程中都一再地感受到對方強烈的防禦態度,好的情況是對方聽完了,但不見得接受,壞的情況是言語衝突,甚至拋出一句:「隨便你,你是主管你決定就好」。 有人說專業人員都有個性,這真是我多年來深刻的體認,多年來我一直在檢討我溝通的方法,但一直無法找到一套萬用法,或許是經驗不足,或許是磨練不夠,姑且不論我講話與溝通的方法對與不對,一直讓我感受到的則是某些專業人員的執著、防禦、固執甚至不可溝通。

當我還是工程師的時候,這種感覺還不算強烈,我每天做著我喜歡做的工作,一直保持著學習的心,我的心裡一直告訴自己,別人的批評是對的,一定好好的接受,試著改善,若別人的批評是錯的甚至是無理的,溝通當下聽聽無妨,無須跟他討價還價,把對的事情作對了不就好了嗎。一路走來,我完成了許多任務,這些任務目前也都交接到新同仁手上,不諱言,常常還是會擔心,我的產品是不是會遭到其他人的質疑,是不是有瑕疵,是不是會遭到批評,人會犯錯,盡心盡力就足夠,別人的批評也正是我成長的動力,甚至從發生在別人身上的錯誤找到自己未來改善的路。回首過往,我認為我有學習到,也成長了,對於未來,這態度依然會持續。

我認為,溝通的過程並不見得都會很順暢,會需要溝通,往往都是意見相左,在溝通的過程中,我會盡量表達出我的看法,我幾乎沒嘗試過直接說「你做錯了!」,太強烈了,但是面對某些專業人表達出我的看法時,都會不經意的激出對方的防禦心,開始為自己的做法辯駁,開始為自己的專業築起高台,這感受回饋到我身上時, 讓我感受到的都是我在質疑專業,當下又必須開始為對方解釋我的的初衷並非如此,真累。

這種部門內人與人的溝通現象,其實也都發生在整個公司內部部門與部門間,如果大家都築起自己專業的高台,關閉溝通或批評的窗口,這個團隊還沒真正上戰場打仗就先被自己人搞垮,據我的觀察,工作中同事會找同事溝通,絕不會是抱持著要數落對方、給你難堪、看你笑話的心態,都是要解決問題,但少部分的專業人都會在無意間開啟防火牆,選擇性回應,甚至不小心誤扣扳機,不偏不倚一槍打死前來溝通的同事(這往往是新進同仁)。這都不是我們大家樂見。


lcjan 發表在 痞客邦 PIXNET 留言(0) 人氣()