分類
手機大未來

slideshare出mobile版本了

之前介紹的 slideshare 網站, https://diary.tw/archives/515 已經出了 mobile 版本囉, 雖然還是 beta, 不過可以可以用了呢, 而且也可以直接由 desktop 的 browser 去訪問. 網址在:

http://m.slideshare.com

這個功能其實也十分方便, 原來 slideshare 是將簡報放在網路上做分享, 現在再進一步放到手機上來分享, 這個的確十分有用, 可以在外面隨時看自己分享的簡報耶.

我們來看看手機上的長相:

雖然小, 不過也非常方便了呢, 給大家參考看看, 基本上, slideshare 是很有用的簡報分享網站, 再加上了手機上的瀏覽應用, 雖然字會小很多, 有時會看不清楚, 不過若是用於示意圖又或是圖片的分圖, 真的是再方便不過了..

分類
Javascript

jQuery traverse元件屬件

traverse 是程式寫作上一個還算蠻重要的 runtime information. 尤其在 web 上, jQuery 的概念整個就是建立在這樣概念上. 利用 selector 將要找的東西找出來, 再進行更動或讀取這樣的狀況.

現在利用一個小案例來說明這個 case. 我要找出頁面上所有有 onclick 屬性的 anchor, 並加以標註出來, 語法是這樣的:

$("a[onclick]").addClass("highlight1");

是的, 你沒看錯, 就是這樣一句而已. 這句語法的解釋是這樣的:

  1. $(“a”) 是找出所有的 anchor
  2. $(“a[onclick]”) 是找出所有的 anchor 而且有 onclick 屬性的
  3. addClass 就是加上一個 css class

就只是這樣而已. 我們來看看範例吧: http://sample.diary.tw/17/j1.html 其中的 button: [find anchor with onclick attr.] 按下後, 會將有 onclick 屬性的 anchor 用 highlight1 的 lightgreen 的背景色加上, 就很清楚了. 其中只有 f1(), f2() 會呈現出來效果, 而其他的 anchor 沒有下 onclick 屬性的, 都不會被影響.

接下來找出 anchor 的連結屬性, 開頭是 http://www 的, 這個也很有趣, 語法如下:

$("a[href^='http://www']").addClass("highlight2");

也是一樣, 一行搞定, 語法說明如下:

  1. $(“a[href^=’http://www’]”)是指 anchor 中, href 屬性開頭為 http://www 的.
  2. addClass 就是加上一個 css class

(在1.2版時, 還可以使用 @在 href 前, 也就是 @href^=’xxx’ 這樣, 不過在 1.2 已不推薦使用, 1.3 時已不支援了, 要特別注意 @ 這個符號囉)

一樣來看範例, http://sample.diary.tw/17/j1.html 其中的 button: [find anchor start with http://www] 按下後, 其中開頭為 http://www 的 anchor 會套用 lightblue 的背景色, 是不是很方便呢?

其中的 ^= 是開頭為, 而 $= 是結束為, 而 *= 是含有, 所以若是要找連結為 .pdf 結尾的, 可以使用:

$("a[href$='.pdf']")

再來就是談 traverse 的語法, 其實也很單純, 是利用 each 這個方法, 再利用匿名函數取得陣列代號, 就可以將符合條件的元素陣列逐一列舉出來, 如下:

var elements = $("a[href^='http://www']");
var message = "";
$(elements).each(function(e){
    message += elements[e].href+"\n";
});
alert(message);

程式碼說明如下:

  1. 先將符合條件的 objects 都放入 elements 陣列
  2. 再利用 each 方法, 配合匿名函數, 將 elements 陣列內的 object 的 href 屬性結合成產生的字串訊息
  3. 最後再將訊息秀出

參考範例: http://sample.diary.tw/17/j1.html 其中的 button: [traverse anchor start with http://www] 就會將所有開頭為 http://www 的 object 的 href 屬性 alert 出來囉.

相信對於使用 jQuery 的朋友們, 能更清楚整個運作的邏輯..

分類
.net

.net下enum列舉與string文字間的轉換

有時會用到這樣的功能, 就是列舉的名稱和列舉的值做轉換. 這個在 delphi 裡是利用 RTTI (Runtime Type Information)來達成, 在 .net 裡的作法也很單純, 利用 Enum 的 CLASS 方法(靜態方法)就可以做到了.

先來看看由 enum 轉回字串, 是使用 Enum.GetName 方法, 要傳入的是 enum 的 type 及該 enum object 即可, 程式碼如下:

public enum enumMyFruit  
{  
    Apple, Lemon, Orange  
}  
....  
enumMyFruit fruit1 = enumMyFruit.Apple;  
string result = Enum.GetName(fruit1.GetType(), fruit1);

再來是利用 string value 轉入 enum 的方法, 使用 Enum.Parse , 傳入一樣是 enum 的 type, 及傳入 string 的值, 最後有個參數是是否忽略區分大小寫的真值, 範例如下:

 public enum enumMyFruit  
{  
   Apple, Lemon, Orange  
}  
....  
enumMyFruit fruit1 =  Enum.Parse(typeof(enumMyFruit), "Apple", true);

其中關於第一個部分, 使用 Enum.GetName 其實可以直接用 fruit1.ToString() 就拿到了, 不過根據這篇文章: http://www.cnblogs.com/smalldust/archive/2007/02/27/384657.html 提到了, 效率不太一樣, 就我個人覺得, ToString() 還是少用吧, 用 GetName 還是比較正規一點, 再加上效率有差的話, 其實還是用 GetName 好.

後面利用 string 轉入 enum 則要注意一下, 若發生找不到的狀況時, 將會有 exception 發生, 這個是需要注意的, 因為本來就有可能會發生這個問題, 要處理好這個部分的程式碼囉.

參考資料:
http://snipplr.com/view/3585/enum-to-string-and-string-to-enum/
http://www.cnblogs.com/smalldust/archive/2007/02/27/384657.html

分類
FreeBSD/Linux

apache deny ip設定

想要將 apache 的站台, 拒絕讓某個(某群ip)存取的方式, 有幾個方法, 其中最單純最俱體的方式就是直接利用 <Directory></Directory> 這個 tag 中的限制存取來操作最為單純方便 (當然, 虛擬主機可不行, 可以直接利用 .htaccess 設定該層目錄的存取權限)

一般來設, 設定如下:

<Directory "/usr/home/website1">
  order deny,allow
</Directory>

這樣即可. 就是判斷 deny , 預設為 allow 的條件, 也就是所謂公開站台的設定, 若有要限制某些 ip 存取, 可以這樣下:

<Directory "/usr/home/website1">
  order deny,allow
  deny from 1.2.3.4
  deny from 11.22.33.
</Directory>

其中的 deny from 1.2.3.4 是限制某個單一 ip, 而 deny from 11.22.33. 是指 11.22.33.* 都是拒絕存取的, 如此一來, 便能有效管理不想讓某些 ip (例如爬蟲類或是一些吃資源的 ip, 又或是攻擊的 ip)訪問做好限制.

不過發生了一個有趣的狀況, 也就是之前設了, 發現沒有用, 在多次交叉比對檢查後, 發現是這個原因, 就是在 <VirtualHost> 內的 DocumentRoot 指定為 /home/website1 而在 <Directory> 內的目錄指向是 /usr/home/website1 , 這樣一來, apache 在存取該 website1 的檔案時, 是走 /home/website1 下的檔案, 雖然和 /usr/home/website1 一樣, 不過對 apache 來說卻是不同, 這個要特別注意才行, 否則可能會有設定好的 <Directory> 的限制 ip, 但實際上沒有作用, 原因就有可能發生在這裡了.

又或反過來說, 設定的路徑一定要一致, 而且儘量用完整路徑, 不要用簡化的 link 路徑指向檔案, 也比較容易除錯一些. 所以原則上是這樣的:

<VirtualHost *:80>
  ServerName test.diary.tw
  Document /usr/home/www/test
.....
</VirtualHost>

<Directory "/usr/home/www/test">
  order deny,allow
  deny from 1.2.3.4
</Directory>

這樣就 ok 啦, 千萬要注意紅字部分要一致的這件事, 否則可能設了沒有作用, 原因就在這裡了..

另外補充一下, 若是這種方式限制存取的話, client 會拿到 403 的存取失敗代碼.

Google坐穩Alexa第一名了

因為我用的 Firefox 有安裝 sparky, 就是 alexa toolbar for firefox (請參考這篇), 所以每天大概都會瞄一下各網站的排行狀況, 今天收 gmail 時, 偶而發現 google.com 已躍居 alexa 排行榜第一名了.

長久以來, 排行榜一直是 yahoo.com 盤據著第一名的寶座, 也因為他使用的域名政策是使用 XX.yahoo.com 的方式, 使得以尾域名統計為基礎的 alexa 長久以來一直是 yahoo 第一名, 而 google.com 則是因地有不同的尾域名, (不過 login 時及一些服務則是回到 google.com), 所以一直不敵 yahoo, 但是排行榜前幾名一樣有 google.com, google.co.in, google.de, google.fr 等等, 當然 yahoo 也是有 yahoo.co.jp 這樣的狀況, 不過一般來說, 比較時仍會覺得 google 其實已經實值超過 yahoo 的 ranking, 只是在 alexa 的計算基礎下, 一直沒有呈現.

接下來看看今天的 alexa 圖表比較清楚:
先看看 reach:


其實 reach 的部分, 很單純, google.com 早在去年就超越了 yahoo.com 了, 再來看看 pageviews:


這個很明顯地, 其實是 yahoo.com 的 pageviews 下滑的厲害, 不過更有趣的是, google.com 在去年10月起, pageviews 快速上升, 使得這兩個差距明顯縮小很多. 再來就是整體的 rank 圖表囉:


呃… 不令人意外, 在一月的時候, 糾纏了一陣, 我們放大來看:

原來其實早在一月時, 就是開始超越了, 一直到後來就穩定的坐在第一名了.

yahoo.com 其實 pageviews 下滑也很明顯的看出內容性的網站和功能性的網站的差異, 內容是一種 B2C 的應用模式, 而功能卻是一種需求, 不過從 google.com 的 pageviews 上升的狀況來看, 功能雖然黏度不高, 不過看的內容卻愈來愈多了, 當然也和 google.com 提供的服務增加有關, 雖然他不做內容, 但是搜尋內容, 反觀 yahoo.com 的狀況, 他也是有搜尋, 不過卻是內容勝出的部分已經略顯不足了, 但是誰能賺到錢才是重點吧, alexa ranking, 參考參考…

分類
手機大未來

資訊黏著度

隨著 iphone 3g, htc 一堆智慧型手機的普及, 相信許多網路重度使用者對於這些連網服務應該都相當忠誠, 黏著度很高. 無時無刻上網, 似乎已是現代人的一個需求.

我們來看看為什麼手機上網會這麼重要. 因為, 手機人手一支, 基本上會帶在身邊, 因為他是一個”通訊工具”. 也就是說, 手機基本上即使他不能上網, 他還是讓人帶在身邊的一個通訊器, 這是已經存在的事實. 從早期人們沒有行動電話開始, 一直到行動電話人手一支的時代, 看起來, 手機已經順理成章地跟在現在人的生活之中了.

接下來, 手機的傳輸方式, 陸續多加了 GPRS 開始, 就導入了傳輸資料的能力, 無所不在的傳輸資料, 看起來是方便, 但是費用卻很驚人, 明明和話務是一樣的傳輸資料, 為什麼 data 就硬是比 voice 貴呢? 這個時代, 用 GPRS 的人, 肯定是有網路的重度需求, 才會如此一般地使用….

再來, 就是進入到 3G, 3.5G 的現代了, 其實, 一樣, 換湯不換藥, 就是傳輸的費用便宜了一點, 而且出現了包月的這種型態, 看起來真的有便宜到, 不過呢, 還是比其他替代性方案來說貴了許多, 最重要的是穩定性及效能並不是真的很好. 也就是說, 雖然可以傳輸資料, 但是用他的 C/P 值來看, 若是多加了一個隨時隨地的參數進來, 的確是很方便, 但若考慮其他的可替代方案, 相形之下就貴了許多.

接下來再來看看手機上的應用實例, 其實手機上, 使用 GPRS 傳輸, 早期的小畫面, WAP 的介面及功能, 其實很足夠了, 再轉到 3G/3.5G 來的時候, 其實雖然手機畫面稍大了, 介面也豐富了, 但用手機瀏覽資料, 配合 3G/3.5G 其實也已經很夠了. 只要不是用來接電腦, 相信手機目前的傳輸方式, 其實非常夠用.

但是人們對於資訊的需求及黏著度, 已比以往多很多, 再加上方便又小型的 nb, netbook 等, 行動傳輸資料已經是目前手機營運商的重要應用服務, 隨時隨地上網, 無時無刻上網, 目前是什麼呢? 打發時間? 取得第一手資料? 更方便快速處理完資訊事務? 看起來都是重要的, 不過也都是不重要的….

休息一下吧, 忙碌的人們, 帶著綁著自己的資訊設備, 隨時把自己壓得喘不過氣來, 是不是真有這個需求呢? 好好整理一下吧….

分類
程式技術

13號星期五的機率

今天是 2009/2/13 的 13號星期五, 13號星期五, 也是黑色星期五, 印象中, 應該一年平均會有兩次, 不過為了驗證這件事, 我們利用 vbs 寫個小程式來驗證一下就知道了..

這裡會用到的重要 vbs 函數有兩個 DateSerial 及 WeekDay 這兩個, 程式碼如下:

counts = 0  
  
For i = 1 to 2000  
  For j = 1 to 12  
    If WeekDay(DateSerial(i, j, 13), vbSunday) = 6 Then  
      counts = counts + 1  
    End If  
  Next  
Next  
  
WScript.Echo counts

計算西元1年至2000年的13號星期五有幾次, 來平均一下應該就很公平了吧.. 這樣計算出來的結果是 3439 次, 平均下來就是 1.7195 次 (3439 / 2000) 這樣就和印象中的 13號星期五的機會很接近了. (若用 3000年來算是 1.7196 次 (5159 / 3000), 9000年來算是 1.7198 (15479 / 9000))

再來列出最近10年的 13號星期五:
2001/4/13 2001/7/13
2002/9/13 2002/12/13 2003/6/13
2004/2/13 2004/8/13
2005/5/13 2006/1/13
2006/10/13 2007/4/13
2007/7/13
2008/6/13
2009/2/13 2009/3/13 2009/11/13
2010/8/13

很有趣的, 今年吃掉了2007, 2008, 2010 三年的 quota 耶, 哈哈..

相關討論:
一年中最多有幾個黑色星期五?最少有幾個黑色星期五?
上面文章內, 即使碰到閏年的 2月 29日, 算出的結果仍是介於1~3日之間, 所以也不會有超過3日或少於1日的沒有13號星期五的日子.

[2017/10/13 10:16]
補上 codepen 的 javascript 程式碼結果.

(https://codepen.io/timhuang/pen/pWZXYL)

分類
懶得分類

轉職力?!

看到這個宣傳廣告: http://edu.uuu.com.tw/events/090203/course.htm

2009年最重要的能力-轉職力….
是的, 工作專業歸工作專業, “轉職力” 是個什麼東東啊? 是指轉職的能力嗎? 是指可以換工作的能力? 不過我講坦白話, 換工作的能力, 有什麼用啊?! 人家看你的還是專業能力及學經歷等條件, 尤其現在這種環境的狀況, 專業都不見得有用了, 大家都要生存, 公司也要生存, “轉職”? 有條件才有得談.

不過話雖如此, 充實自己的專業能力及培養正確的態度及人生觀, 或更長遠的未來來看, 充實自己是必要的, 另外發展所謂第二專長甚至第三專長都是要多多涉獵的. 不過話說回來, 多就有可能不精, 精也可能沒辦法多, 如何又能多又能精才是困難的, 這時候, 興趣就是支持你前進的重要動力.

如何寓工作於娛樂, 或是寓娛樂於工作, 就才能長長久久, 否則工作是工作, 有時候可能沒辦法一直做下去. 很辛苦!

當然, 這個廣告文宣寫得很不錯, 希望大家能進修, 能再學習, 但如何學得又多又廣, 又能深入, 真的要花更多的精神和時間了呢!

另外看到這個也還蠻有趣的, 大家玩看看囉:
塔羅占卜 測試你的轉職力

或許現在的狀況, 能有工作忙就是很好的呢…..

分類
懶得分類

2TB的硬碟

你看看… 時代在進步, 硬碟空間也在進步, 而且還蠻驚人的. 之前還在看 1TB 的硬碟, 現在 2TB 的都面市了說:

http://news.networkmagazine.com.tw/server-and-storage/2009/01/29/10288/

之前的舊文章: https://diary.tw/archives/422

不過就是2年前的事嘛, 這麼快, 就有 2TB 的硬碟出來了呢. 來看看價格吧: WD 最新GP系列 2TB硬碟機 WD20EADS , 在 monday 是賣 8999, 1TB 的已經不值錢了咧, maxtor 才 3888, wd 的也才 3999, 真的是還蠻便宜的耶! 雖然如此, 還是 640g 的 cp 值最高啦, 才 2499元, 除下來的最低單價每 G 是 3.9 算最便宜的啦!

說到這裡, 又要開始懷舊一下, 硬碟的空間, 近年來成長的幅度快又大, 再加上又有 SSD 的硬碟出現, 真的是讓現在的玩家玩不完耶.

分類
程式技術

詭異的dtd (flash滿版問題)

今天在處理一個妙妙妙的問題. 在 IE 下看很正常, 但在 Firefox 下看就很怪.

是一個 flash 的網頁, 內容其實只是要佈滿版瀏覽器而已, 在 IE6, IE7 下沒問題, 但在 Firefox 下, 卻是寬滿版, 高則維持原 flash 的高度(sample 內的 swf 為320*240). 我們先來看看發生的狀況, 以下 sample 連結, 請查看:

http://sample.diary.tw/16/f1.html

原始檔內容如下:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<body>
<embed height="100%" width="100%" src="f1.swf" type="application/x-flash" />
</body>
</html>

用 IE 看和用 Firefox 看結果不同:

真是奇怪咧, 後來經檢查發現, 是和原始碼的第一行有關, 若使用了 xhtml 的 dtd 後, 就會發生這個狀況, 當把 dtd 移除後, 無論是 IE 或是 Firefox 就都可以滿版了, 可以參考這個範例連結:

http://sample.diary.tw/16/f2.html

但遵守 xhtml 是未來必經之路, 不能說拿掉就拿掉吧, 再來找看看有沒有好用的 solution, 於找到了這篇: TIPS-Get 100% Height in XHTML

裡面建議了一個蠻不錯的好方法, 就是將 html 及 body 的高度都利用 css 指定 100% 設起來後, 就可以有全高的 flash 了, 如下:

html, body
{ margin: 0; padding: 0; height: 100%; border:none; }

就能有效解決 dtd 存在的 xhtml 時, 無法滿版的問題, 重點在於 html 及 body 的 height: 100% 這件事上, 請參考範例連結:

http://sample.diary.tw/16/f3.html

而其中的 margin:0; padding:0; 是將 box model 中的邊界及位移都設為0 , 更接近滿版的狀況囉, 到此終於解決了一個詭異的 html 滿版問題了.(當然 flash 只是其中做為應用的一種啦, 其他的 html tag 也都是一樣的意思, 滿版都有這些狀況, 只是 flash 較常碰到了)

PS. 補充一下, 剛好手邊也有 IE8 , 他的狀況和之前的 IE6, IE7 不同, 由於更支援正式的規範, 反而它的行為是和 Firefox 一致哦, 不過若是切到 IE8 的 compatible view 時, 就會和 IE7, IE6 一樣囉!!