用倉頡這麼久, 大多是使用半形的逗號和句號, 所以寫文章時也都是如此.
在打一些文書需要全形標點符號, 都是叫出符號鍵盤來用, 所以也不知道可以用倉頡打全形標點符號.
今天同事說可以用”速成”輸入全形標點符號, 所以來查了一下倉頡的標點符號如何輸入. 在這裡查到了相關的資料: http://zh.wikibooks.org/zh-tw/%E5%80%89%E9%A0%A1%E8%BC%B8%E5%85%A5%E6%B3%95/%E6%A8%99%E9%BB%9E%E7%AC%A6%E8%99%9F%E8%BC%B8%E5%85%A5
其中比較常用的是逗號: ZXAB, 頓號 ZXAC, 句號 ZXAD, 其他的可以參考對照表來輸入, 另外也有快速鍵可以利用 [Ctrl][Alt][,] 將符號小鍵盤叫出來, 就可以用滑鼠選字, 還蠻方便的.
一般在 windows 環境下, 起排程工作執行 console 應用程式或指令, 若是執行身份和目前登入的使用者身份一樣時, 就會出現一個 console 視窗, 為了要隱藏這個視窗, 有一種方式是使用不同的身份來執行該排程工作, 另一種方式可以應用這個小程式: Hidden Star
這個小程式可以讓執行的視窗不出現, 而且還有一個自帶的 UI 設定器, 方便使用者自行定義一個執令或是多個指令的執行, 而且不會出現干擾目前使用者的 console 視窗, 十分方便, 若有這樣需求的朋友們可以多加利用.
參考資料: http://www.howtogeek.com/howto/windows/hide-flashing-command-line-and-batch-file-windows-on-startup/
Hidden Star 網站: http://www.ntwind.com/software/hstart.html
繼 Google Reader 要停後, MSN於今日要正式停止服務了.
死忠派, 最後還是得要換, 不過就是依原本預期的做法, 原 skype 帳號還是 skype 帳號, msn 轉過來的, 也就是獨立的, 不合併.
因為知道群組不會移轉過去, 所以用了這個暗黑執行緒大大的工具來做移轉: http://www.darkthread.net/MSNCatgTool/MSNCatgToolv125.htm
過程順利無痛, 有痛的地方就是沒有 msn 了….
沒有 msn了….
沒有 msn了….
沒有 msn了….
算了, 沒有就沒有了, 繼續用 skype 吧.
不過, 真的很不習慣的介面, 很不習慣的操作, 文字聊天就 msn 最好用, 語音聊天就 skype 最好用, 手機通訊就 line 最好用, 以上純個人感覺啦!
PS. Google talk 咧…. 呃, 很少用耶…
先說好, 這文章不是在賣這玩意兒.
wifi加密被破解不是什麼新鮮事, 不過居然有這種已經做現成的軟體, 雖然說真的很方便, 不過其實也要小心這類軟體內是否有什麼問題.
先看被破解的 ap, 其實一方面是 WEP的加密本身有弱點, 所以不建議使用, 可以參考這篇: http://zh.wikipedia.org/wiki/%E6%9C%89%E7%B7%9A%E7%AD%89%E6%95%88%E5%8A%A0%E5%AF%86
然而, 使用這個破解軟體的用家也得要小心這個軟體內是否有沒有惡意程式, 而且用這個軟體去破解別人的 ap 也可能會有法律上的問題.
不過, 這件事也讓大家注意到這個 wifi 安全性的問題, 一定得做好保護, 用新一代的加密方式, (雖然說也可能被字典破解), 但至少所費的時間及安全性高得多, 又或是利用 mac address 的方式來保護, 讓有存取權限的設備來加入, 至少可以防範一些其他非允許的設備加入 ap, 另外, 隱藏 ap 的 ssid 也日一種方式, 避免被掃描出來, 至少要有 ap ssid 才能找到該 ap, 還有就是不主動配發 ip 的做法(也就是不給 dhcp 服務), 當然啦, 愈便利風險就愈大, 但多一份準備就少一些問題, 尤其是家用的 ap, 其實常在用的設備也就這些, 沒必要把資訊都揭漏出來吧, 甚至於沒用就關起來也是一個不錯的方法(但好像有點因噎廢食).
來看看相關新聞:
強力破解器攻陷Wi-Fi？專家：非秘密
http://www.ettoday.net/news/20121225/144446.htm
6、7百元破解器 港Wi-Fi WEP瓦解
http://www.merit-times.com.tw/NewsPage.aspx?Unid=288083
今年稍早寫過一篇 facebook 在 alexa 超過 google ( https://diary.tw/archives/949 ), 不過年底再來看一下, 又被追回來, 而且拉開了差距.
來看看前幾大排行的長時間狀況:
看起來在 8月後, 又過沒多久就被追回來, 而且 facebook 似乎有點趨緩, 而 yahoo 還是持續下滑, baidu 則是慢慢攀升.
再來看看近 6個月的圖表:
這樣就比較清楚在 google vs facebook 的狀況. 不知 facebook 的後續會怎麼發展下去呢!
今天的新聞: http://www.appledaily.com.tw/appledaily/article/headline/20121120/34652406
這個技術本身沒有太多問題, 也是很好的配套措施, 只不過問題是沒有 Wi-Fi 的地方怎麼用, 人家之所以買3G就是希望能有更好的覆蓋率, 而不是要用Wi-Fi不是嗎? 再反過來看, 是不是轉了Wi-Fi之後就會順呢? 大家一起上到那個Wi-Fi的熱點(AP), 說不定也是塞在那個AP上啊, 會不會比較快也很難說.
結論仍是3G吃到飽, 吃不飽… 呃…
最近吵很兇的吃到飽應要取消的新聞, 其實有意思的地方就是最終會取消的這件事, 取消就取消, 反正正常用量也不可能大到哪裡去.
但之所以會吵得如此熱烈, 主要應該是在使用者對於電信業者的品質滿意度不夠, 思考一下, 原本辦吃到飽的人, 可能一方面是擔心用過量而繳太多錢, 另一方面可能有人覺得可以替代固網, 就直接用吃到飽的方案, 回頭先想一下, 目前的電信網路品質如何, 才會生出目前這樣很妙的狀況.
因為品質不好, 吃到飽根本吃不飽, 怎麼還要取消呢? 所以應該是有效改善品質, 提高傳輸量的價差, 用者付費的觀念我相信大家都有, 何不有效地制定價格方案是隨著用量來調整的方式更好呢?
但到底用得愈多, 折扣要給得愈多還是用得愈多也不給折扣呢? 這個其實就得看是否鼓勵用量. 不過總量用的愈多得付費付得愈多是個大準則, 這樣就自然而然的不會有過大的使用量, 而用量大的使用者自然多繳一點錢, 相信電信業者也不會不接受, 這樣一來一往, 或許可以平衡一點.
但要記得重點是品質很重要, 到底是少數使用者用量過大而造成的品質下降, 還是基礎建設造成品質下降, 目前的聲音或許是因為後者而興起的浪潮吧! 但吃到飽的費用也是要檢討才是, 不然買吃到飽的用戶, 當然會想多用一點, 但品質又不好, 自然抱怨連連. 所以提高吃到飽的費率, 而以量計價的方案精算多一點, 或許能有效改善.
其實目前電信業者的許多方案也就是如此了, 非吃到飽的套餐, 都有設收費上限的門檻, 某種程度來說也就是吃到飽的費率在該門檻上, 也就是仍有吃到飽, 只是費率較高, 自然不是吃不吃到飽的取消不取消的問題啦!
所以整個歸納起來導火線就是電信業者自己要擴張用戶使用上網而提出的低價吃到飽方案害慘了自己吧!
微軟的雲端服務 Windows Azure 目前有免費試用的版本, 方便給在學習及測試階段的開發者們一個好用方便的服務.
入口: http://www.windowsazure.com/
進來之後, 可以直接在線上申請試用 3個月免費, 點下[免費試用], 免費的內容如下:
登入 windows account 之後, 會需要輸入電話號碼(用來收開通簡訊)及信用卡驗證身份(避免濫用)後, 就可以順利開通了.
接下來就是使用這個 3個用的免費服務, 最快的方式是直接建立網站功能(即website), 免費內容可以建立10個網站, 所以就來新增一個網站看看, 從 Web Sites 內容下方, 按下 [+NEW] 後就可以新增一個網站, 接下來會有三個選項:
為能快速就有個網站可以試玩看看, 我們來選 3. FROM GALLERY, 就可以利用架站的套件直接裝好來用, 如 Drupal, WordPress, Joomla, Mediawiki 等.
來裝個 Drupal 試看看, 選擇後, 需要輸入資訊畫面如下:
第一個 url 就需要輸入一個唯一網址, 然後建立一個新的MySQL資料庫, 選擇地區後, 按下一步, 輸入完成資料庫相關資訊後, 回到 Web Sites的管理介面, Windows Azure 會開始部署, 等一下下後, 就會出現部署完成的資訊, 並該 web site 的狀態為 running , 點下自訂的 url 後, 會進入設定安裝 drupal 的畫面如下:
接下來就很單純啦, 一步一步就可以完成這個 drupal 的安裝. 真的很快很方便, 而且馬上就可以用了呢!
目前裝好了兩個測試的 web site, 一個是 wordpress: http://mypress.azurewebsites.net/ , 另一個就是 drupal: http://dp7.azurewebsites.net/ 還真的蠻方便的.
接下來也可以自行試看看用之前的 QUICK CREATE 來建立一個空的網站, 建好之後, 進到管理介面中的 configuration 可以看到預設的 .net framework version 是 4.5, php 是 5.3 的版本.
另外若需要用 ftp 管理, 要到 Dash board 中, 點右邊的 setup git publishing, 也就是 git publishing 和 ftp 都用一樣的帳號密碼, 詳情可以參考這篇:
http://blog.syntaxc4.net/post/2012/09/13/enabling-php-5-4-in-windows-azure-web-sites.aspx
這樣就可以利用 ftp 來進行檔案的上傳及管理了. 由於站台是可以執行 asp.net 及 php, 筆者也上傳了 asp 的檔案測試, 也是可以執行的, 有興趣的朋友們可以試看看這個 Windows Azure 提供的免費 3個月試用服務.
若是用量(QUOTA)超過, 預設是不會扣款, 只是服務會暫停, 測試的網站應該不太會這麼快就用完吧, 好好試用看看吧!
若是網站要自訂網域, 則必須在 SCALE 那裡將模式由 free 設為 shared 或 reserved 才行, 可以參考這篇: http://www.windowsazure.com/en-us/develop/net/common-tasks/custom-dns-web-site/
3種程式支援 sample:
php: http://w3.azurewebsites.net/1.php
asp: http://w3.azurewebsites.net/1.asp
aspx: http://w3.azurewebsites.net/1.aspx
快試看看吧!
HTML5裡令人驚豔的一項特性就是可以離線瀏覽功能.
利用這項功能, 可以很容易地讓網頁在沒有網路的環境下, 也能順利讓使用者閱讀及使用, 而且實作上也相當單純, 只需要注意寫好更新網頁的邏輯及時間點即可.
一般來說, 只需要把 manifest 設定好, 基本的離線瀏覽功能就差不多完成了, manifest 的設定容易, 就是把”要”在離線瀏覽的網頁及內容, 寫在 manifest 裡, 例如網頁是
http://test.com/mypage.htm
內容有一個 js/myjs.js
另外還有兩張圖為 imgs/1.jpg 及 imgs/2.jpg
則在 mypage.htm 中的 html tag 裡, 多加上 manifest=”mypage.manifest” 而且在 mypage.manifest 中, 加上以下內容(純文字):
CACHE MANIFEST mypage.htm js/myjs.js imgs/1.jpg imgs/2.jpg
這樣就完成了. 有意思的地方是即使用 mypage.php 這樣的動態內容, 一樣可以利用這樣的方式將內容存在客戶端中.
如此一來, 即使在沒有網路的狀況下, 也可以順利瀏覽這個網頁內容 http://test.com/mypage.htm
接下來要說明的是更新方式, 一旦寫入到客戶端的內容, 即使原本的 mypage.htm 更新, 就算是有連線時, 該內容也不會更新(而且即使是動態的 aspx, php 等也都是一樣的), 簡單地說, 在 manifest 中的內容, 就是完全使用客戶端的內容, 不管 server 上的內容, 更新的方式就是更新 manifest 的檔案, 瀏覽器會檢視 manifest 內容來進行更新, 而且會自動更新(在線上時的第一次讀到 manifest 更新時, window.applicationCache.status 會變成狀態 4 (window.applicationCache.UPDATEREADY), 此時可以手動更新, 使用 window.applicationCache.update(); 即可做手動更新, 即使在這次的訪問不更新, 在下一次的訪問時, 瀏覽器也會自動更新.
利用這點, 就可以很容易地實作出離線瀏覽內容的網頁.
若希望只更新這些快取內容, 最簡單的作法是在 mypage.manifest 中, 多加個時間或版本號, 如下:
CACHE MANIFEST #VER 000151 mypage.htm js/myjs.js imgs/1.jpg imgs/2.jpg
其中的 # 代表著這行為註解, 所以可以自由寫入內容, 上例是寫個版本號 000151, 若要強迫客戶端更新時, 可以將這個 manifest 檔的版本號改為 000151 (若其他內容都可以), 這樣就可以方便容易地來維護在客戶端離線的內容更新.
這裡有一篇很清楚的介紹文, 可以參考
http://www.ibm.com/developerworks/cn/web/1011_guozb_html5off/
另外, 配合良好的設計結構, 可以將離線/在線的功能都實作出來, 方便在無法連線時, 也能使用的網頁, HTML5 的這個功能, 的確非常強大!
在實作測試時, 發現若是有設定 manifest 的網頁, 有些瀏覽器對有些 server request 即使沒有設定在 manifest 中, 也會有快取或存取的異常狀況, 建議在 manifest 的最後, 再多加上
NETWORK: *
這兩行, 可以讓不正常工作的 server request 正常運作.
相關資料:
http://diveintohtml5.info/offline.html
w3c 的資料:
http://www.w3.org/TR/html5/offline.html
Apple Safari的資料:
http://developer.apple.com/library/safari/#documentation/iPhone/Conceptual/SafariJSDatabaseGuide/OfflineApplicationCache/OfflineApplicationCache.html
之前一直用的好好的 Google 天氣 API, 今天同事回報異常, 經檢查後, 發現看起來是 Google 的問題, 不過回覆的訊息讓人摸不著頭緒, 如下:
(訪問 http://www.google.com/ig/api?hl=zh-tw&weather=taipei 的結果)
起先以為是用量過多爆了, 不過查了一下, 發現應該不是, 而且也找到相關的新聞訊息: http://thenextweb.com/google/2012/08/28/did-google-just-quietly-kill-private-weather-api/ 看起來應該是 Google 打算關掉的服務引起的, 而且上面的 copyright 還是 2009, 真是怪怪的.
接下來只好轉換用其他家的 weather api, 原本要用 http://www.wunderground.com/ 這家的, 但是是要收費的, 只好再找, 改用 yahoo 的, 參考 API 介紹: http://developer.yahoo.com/weather/ , 應用起來, 原本 Google Weather API 有的資訊他也都有, 只是都是英文的, 不過倒也不影響使用.
不過若是不知道地點的 w 代碼(WOEID), 可以先到 yahoo weather 上查: http://weather.yahoo.com/ 輸入 taipei, 將會重導到網址: http://weather.yahoo.com/taiwan/null/taipei-2306179/ 就知道 w 代碼是 2306179, 而 API URL 就會是: http://weather.yahooapis.com/forecastrss?w=2306179 預設氣溫單位是華氏, 若是要氣溫單位, 再多加參數 u=c 如: http://weather.yahooapis.com/forecastrss?w=2306179&u=c
回應的內容也都是 xml 格式, 可以容易利用程式實作取出, 花了幾十分鐘的時間, 把原來的 api 由 Google 改到 Yahoo 完成.
附上部分台灣的 WOEID:
2306155 Yungkang City, TW (永康市)
2306179 Taipei City, TW (台北市)
2306180 Kaohsiung City, TW (高雄市)
2306181 Taichung City, TW (台中市)