電波幻想

基本上，網頁(HTTP)的運作方式其實並不難，只要大致上了解的它的運作方式，其他的都是增加上去的擴充功能。 你可以想像你的瀏覽器是一個餐廳的服務生，而你正在餐廳，餐廳的廚師是網頁伺服器，你想要看的網頁就是餐點。 最簡單的方式就是點一客牛排。 1.你會先跟服務生說：我要點一客牛排。 2.服務生收到您的要求，然後去跟廚師說：客人要一客牛排(Request)。 3.廚師做好牛排，交給服務生(Response)。 4.服務生將牛排交給你。 這個過程就是最簡單的網路資訊交易過程，按照上述的順序解釋如下： 1.你在瀏覽器上輸入了網址(例如：http://www.hostname.com)。 2.你按下送出(submit)後，瀏覽器將要求(Request)送到伺服器(Server)。 3.伺服器回應(Response)給瀏覽器需要的網頁資料。 4.瀏覽器將網頁資料呈現在你眼前。 很簡單吧。 當然上面是基本概念，其中當然多了幾道" 加工 "的動作： 1.廚師要將材料配合做出牛排 -> 伺服器端會將網頁中的指令翻譯成瀏覽器可用的HTML標籤語法 。(多數標準的htm、html檔案通常不會經過伺服器處理，因為這些檔案內容都是標準HTML標籤語言，由客戶端瀏覽器直接處理即可) 2.服務生通常不會直接將牛排交給客戶通常會加個餐巾、餐具等等 -> 瀏覽器會將收到的HTML標籤繪製成漂亮的畫面呈現在眼前 。 所以，依照運作的方式大致上網頁標籤/程式碼就可以分成3大類： 一、 瀏覽器語言 ：標準的HTML標籤、CSS標籤，這類標籤語言是 最基本的網頁構成 程式碼，主要由瀏覽器依照其指定的描述去顯示繪製網頁呈現在眼前，但是這類的標籤語言大部分只有呈現畫面和簡單的輸入能力，互動效果比較少。 二、 javascript、vbscript等類 ：相信很多人都聽過，可是常常搞混(如java和javascript)，這種程式語言稱為瀏覽器語言，主要的目的是提供給瀏覽器除了HTML標籤外的互動能力(例如常見的網頁上的時鐘等等)，屬於輔助性質的程式語言。 三、 伺服器語言 ：網頁伺服器會先處理過具有標籤語言或程式碼的網頁檔案，再回應給瀏覽器顯示，所以若要從瀏覽器看到原始碼是不太可能的，因為都已經被轉換/執行過了。例如常聽到的PHP、JSP、JAVA、ASP、dot Net(asp

接任主管的職務通常都會遇到需要自己克服的事情，而且別人也無法幫你的，還有的同事也在準備看好戲的，總之，就是如此啦。 雖然今天要講的不是什麼新聞了，但是卻是去年10月到今年3月間讓我極度傷腦筋的問題，那就是--ColdFusion，也許使用過的人大概不會覺得有啥問題的，重點就是我完全沒用過這套軟體啊 Orz。 偏偏公司的主網頁又是使用這軟體開發的，後來遇到網頁版面需要改版的問題，需要進行大規模的修改，但是前任主管才沒多久前將CF server升級過，聽說花了不少錢。 心想，半年前去補習過.NET，所以本來打算使用.NET開發，但是公司經費核准不下來(我想應該是老闆覺得才花過錢的為什麼又要再花一次錢吧)，若用JSP或是JAVA又不是那麼熟悉，而且公司另一部主機使用JSP+Apache的經驗實在不愉快，讓我對純JAVA的東西不太想碰。 而且最大的問題是---為什麼國內沒有任何ColdFusion的書籍啊!!!!! 我可是找遍國內網路書店，台中市各大實體書店，包含了舊書攤!!! 後來老闆已經開始質疑我的能力了，對於網頁更新頗有微詞。 其實找書找得很累，加上挫折不斷本來就已經有點心灰意冷，所以3月開始不再找書了，開始往網路論壇去找，因為網路論壇沒有由淺入深的規劃方式，都是片面的技術性討論，而且有的技術性太深，根本看不懂。 但是為了突破，只好每天下班時到處去爬文，好在對岸的論壇幫上了點忙，閱讀起來幾較不吃力，但是對岸的相關文章也太淺太少，部分只好回去看英文的論壇再去對照相關用法。 台灣也有少部份論壇有，但也不普及，太多細節性的內容都不足，很多得自己TRY。 在胼手胝足的努力下，漸漸看懂CFML的語言特性了，不過大多支援的屬性還是很類似JAVA，畢竟，CF也是由JAVA開發出來的。不過，當了解CFML的特性之後，也發現其實他在設計上還算容易上手的，發現它學習起來門檻其實不高，只是需要觀念導引，但是當時就是缺乏有能帶進門的書籍或是參考資料，算是有點可惜。 有時間的話，可以將自己的學習內容寫上來，提供給需要的人觀看。 2009-08-13 update ---> 我想ColdFusion在台灣現在比較不那麼流行，但是相較於.NET、JAVA有著比較親和的撰寫特性，學習跟開發都很快可以上手，感覺上就像powerbuilder開發MIS的資料處理那樣的方便，這是後來我一直使用CF的

雖然我的臨場反應很快，可是要短時間做決定時，考慮還是不夠周全的。 跟前一任的主管Jr比起來，能力上多少有點不太夠，尤其是遇到比較大的決策時。Jr是處女座的主管，做事一定要條理分明，是他的原則，所以他是寧願延宕工時，也不願意因為時間壓力而做太半調子的事情。但有時候也許太小心翼翼，有些事情會不敢做。這不是不好，Jr常常也說要保護自己的Team不要受到其他單位的無理要求。 Jr：因為我們不是資訊公司，趕完Case交差了事，還得有許多善後的動作，東西若是做得不夠嚴謹、完整，事後要擦的屁股肯定很多，加上人手不多，不該出差就盡可能不要出差。 當兵時雖然當過管理職(排長)，但是距離現在已經快超過10多年了，Fu都快忘了，當然部隊的管理方式在資訊單位也是不太適用的，所以還是得從頭學習。 雖然有我們有自己專業的見解，但是有時候在老董的壓力下，還是會得向不利的時間條件屈服，這時候就很佩服Jr以前能夠說服老董騰出給我們較多的時間來完成CASE。 當然這是我必須歷練的學習，雖然心情很差但還是得克服。

任職代理課長到今天大概1/3個月了，人事課送來了一本"員工月考核表"， 我想這就是主管的生殺大權吧，看看之前的主管對員工評分幾乎都是滿分， 真是相當疼愛啊~~~(謎之音：我們都很認真的喔~~)。 看看大家都那麼認真的份上我也不好意思去做所謂的"扣分"了。 "舊"這樣子吧 (我沒打錯字) ！ 繼續努力吧

一般DW如果會跳出這個錯誤，通常是DW中的table定義的欄位長度與SQL執行的欄位長度不符。 如果說有其他原因，也可能是DW與SQL指令搭配不完全。 再者，一般DW執行發生錯誤如果沒有攔截dberror事件，是不會得到SQL error的訊息，然而SQL CODE 2 encountered select error:這種錯誤訊息是DW已經將SQL指令送出執行，在資料庫傳送資料到DW上發生無法處理的錯誤，導致無法繼續(encountered)。 據我的經驗是DW當初"設計"時參照使用的Table，後來因為某些因素做了變更(通常是欄位長度加大)，導致DW中記載的欄位長度與實際Table不符合，當資料長度小於DW當初定義的欄位長度時還不會發生問題，但是當資料長度超過DW當初定義欄位的長度時就會出現錯誤。 解決方式： 重新進入設計DW的data source，簡單的變更或是調整一下SQL部分語法，此時DW painter會重新對應資料庫Table欄位資訊。 如果擔心有些版面會因為調整過data source就會被破壞(Regenerate)，就只好匯出SRD，直接修改SRD檔案中記載TABLE的COLUMN欄位長度，如：CHAR(10) -> CHAR(30) 。使用這種方式要特別注意，修改的欄位長度最好跟資料庫中的Table欄位長度一致，以免後續有問題又需要DEBUG，反而自找麻煩。

請問一下,為什麼我在這個DW的[總成本小計]後面的COMPUTE欄位(如下圖所示)加入sum( compute_0024 for group 1 ) 但出來的結果卻是 我是很單純的想把COMPUTE_0024加總起來而已!!好怪 ******************************************************************************** 關於Compute的問題，我也遇過幾次，原因不是很清楚，但是有些做過調整後就可以使用了，我提供幾種解決方法你可以各個去試試： compute_0024有Null值，因為某些條件下沒有計算值，我推測是Null值，這個Null值 可能 導致Group1上的compute計算sum值錯誤。解決方式：在compute_0024的公式外面加個if(isnull(xx) , 0 , xx)的判斷，強迫讓Null值的公式出現0值，缺點：畫面上會有"0"值出現。 在Group1上的compute公式中加入isnull判斷sum(if(isnull(compute_0024),0,compute_0024) for group 1)，這方法不會有第一點的問題，但是如果是compute_0024值有問題，依然不能解決。 在Group1上的compute公式中 不要直接使用compute_0024這種計算欄位 的值，直接將compute_0024中的公式拿來替代compute_0024，因為經過測試發現計算欄位 有時候 去取得其他計算欄位的值時會有異常值的出現(原因不明，我猜可能是PB內部運算順序導致)，因此我發現這樣雖然公式會"落落長"但是比較不會有問題。 Compute欄位的format不要使用預設的這個也是特例問題，雖然系統在不指定下會使用[general]，卻有時候會發生計算小數點的錯誤問題，通常這種錯誤都會只發生在小數點下，我的經驗是有時候去TOTAL整數卻會跑出一堆小數點以下的數值，修改過FORMAT後就好了。例如僅需要整數時把FORMAT設定:###0。 以上四點是我這邊解決compute field的經驗，你可以修正試試看。

說真的，當初在使用PB6.5的時候，常常覺得視覺控制項太少(可能是被VB養成的壞習慣)，但是因為PB真的有其獨到MIS快速開發的物件導向功能，所以在設計MIS系統的時候，VB只好被我給秉棄不用了；可是說正格的，有時候視覺控制項卻是在UI的分數中占蠻高的比重的。而今天要設計的ProgressBar也是PB6.5缺少的控制項之一，雖然PB7以上的版本已經有這樣的控制項，不過目前朋友還是在使用PB6.5，所以我還是將它設計出來造福一下人群吧。 要設計ProgressBar並不是什麼難事，包括許多DIY的視覺物件也是，但是難就難在要做好一個完整的物件控制項，考驗設計師對使用者(其它設計師)的操作上手速度(這個應該稱作設計介面)：物件功能分明度(A功能與B功能好像類似)、可控制精細度(控制項裡面的物件)、封裝一體性(對控制項裡面的物件控制要如同直接對控制項設定控制般簡單)等等，這部份就會造成程式設計師的極大差異。 好了，廢話結束，進入正題吧。 ProgressBar中文的話應該叫做"處理進度條"，既然是處理進度，所以有進度百分比來顯示會比較好一點，如此可以稍微整合一下，設計好的物件控制項，別人在使用時就不需要再去加東加西的了。然而條狀要如何產生呢，簡單的可以用 Line 這個物件就好了，但是Line的特性太少，表現起來太單調，所以我改用了Rectangle(別說你不知道這叫矩形)來設計，因為Rectagle具有FillPattern的樣式，可以創造較為美觀的ProgressBar，所以初步規劃如下： 另外考慮到的一點是當Progress為100%時，rectangle是填滿的狀態，但是若Progress為0%時，則rectangle則為一片空白，這樣設計在某些畫面上會有" 空一塊 "的感覺，並不是很美觀： 因此我們希望對rectangle保留外框，而在適當的進度下改變FillPattern的範圍： 可是，若是注意看rectangle物件的屬性，是無法這樣操作的，也就是說FillPattern只會全部塗滿，但是無法 依照指定範圍 塗滿，所以我們必須另外想辦法處理這樣的問題。其實可以用很簡單的方法解決這個問題。 對，你想到了嗎？就是用兩個rectangle，一個當底僅顯示外框，另一個當BAR；當BAR的rectangle需在當底的recta