2009年7月20日

利用 Posterous 記錄閱讀網站時的筆記與心得

這次要來介紹一個 blog 系統—Posterous

它主打的特點是:不用註冊,只要發 E-mail 就可以張貼網誌。詳細步驟與功能介紹請參考重灌狂人的<Posterous 用Email寫部落格,自動貼圖、嵌入音樂、影片>

我只補充一個比較少被提到的功能:書籤列小工具(bookmarklet)。它可以將你選取(或是它自己偵測到)的圖片、影片、文字加到你要張貼的文章中。所以我現在都利用它在瀏覽網頁時作筆記或整理心得。

不過 Posterous 的 bookmarklet 連結與說明有一點難找,懶得找的人可以直接點這裡

如果你不知道怎麼把 bookmarklet 加到你的瀏覽器,請參考該頁右邊綠色區塊的說明;
實際使用方式,請點該頁左邊三個「Show me how」。
(請原諒我懶得製作圖文並茂的教學 :P)

因為 Posterous 實在太方便了,我又懶得把我放在 Posterous 的內容再整理到這邊來,所以看來這邊又要乾一陣子了。 :P

2009年7月11日

網頁瀏覽紀錄 7/8 ~ 7/10

嗯...我懶得分類。我盡量把類似的主題放在比較靠近的地方。

2009年7月8日

[書摘] Don't make me think - 如何設計好網站

我還沒真正看過《Don't make me think - 如何設計好網站》這本書,
以下內容是節錄自 10 Usability Lessons from Steve Krug’s Don’t Make Me Think
  • 易用性(usability)代表的是...
    確保某樣事物可以正常地運作,讓經驗與能力在平均水準的人可以沒有困難地使用它並且達到被預期的功效。

  • 網站(web application)要能自我詮釋
    網站的作用與使用方法應該要能夠不言自明、顯而易見。

  • 不要讓我思考
    不要讓使用者去猜你的網站上有哪些功能、或是該怎麼用。

  • 不要浪費我的時間
    多數人是為了節省時間而使用網路。

  • 使用者依戀著「上一頁」按鈕
    使用者在網站做了錯誤的操作,他們不會覺得有什麼大不了的,而會試著按幾次「上一頁」來修正錯誤。

  • 我們是習慣的動物
    找到一個有效的方法,就算還有更好的方法也不要去改變。

  • 沒有閒聊的時間
    使用者不是來閒聊的,使用者只想要立刻找到他們要的東西。

  • 不要忘了搜尋功能
    有些使用者進到新網站的第一件事情就是找搜尋框在哪。

  • 提供概念上的網站地圖(site-map)
    使用者不在乎網站上的功能與內容實際上放在哪裡;
    他們只想知道他們自己在概念上/流程上的哪個位置。

  • 讓回到首頁變得容易
    這樣使用者迷路時才知道可以從哪邊從頭來過。

延伸閱讀

網頁瀏覽紀錄 7/4 ~ 7/7

軟體設計與開發
  • Forgotten Refactoring
    • 重構是好事,但是請先確定你要修改的程式碼有對應的測試。
    • 否則你不是在 "重構",只是在 "change some shit" (這有沒有比較好的中文翻譯?)
  • A Basic Lesson in Password Hashing
    • 不要只對明碼做編碼動作,請記得加鹽(salt)
    • 不要整個系統都用一樣的 salt,請每次都以亂數方式產生。
    • 把 salt 跟編碼後的密碼合在一起,不要存在分開的位置。
    • 結合方式最好可以有變化(例如:由明碼程度決定 salt 的插入位置)。
    網站開發
    網頁設計
    Ruby
    Java
    JavaScript
    Scala
    其他程式語言
    • Lazarus - Free Pascal 的 IDE,簡單說就是 "偽-Delphi"
    • SharpDevelop - 免費的 .NET IDE,支援 C#、VB.NET、IronPython、F#、Boo
    • Fan - 有人說比 Scala 好的語言(出處找不到了...)
    • P-99 - 專為練習 logic programming (Prolog) 而設計的題目
      軟體介紹
      工具網站
      其他
      --
      終於,我把我的未讀文章清完了!!

      2009年7月1日

      乾淨程式碼的 4 個小秘訣

      原文-Tiago Fernandez: 4 Tips For Clean Code
      1. 寫短而簡潔的函式

        程式碼太長的後果是沒人知道這一大段東西到底在幹嘛,因而不敢(或不願意)去修正它。要怎麼判斷一個函式是否太長了呢?有個我很喜歡的簡單準則,大家可以參考一下:

        一個函式的長度不應該超過螢幕能顯示的範圍。

      2. 可以自我詮釋的變數與函式名稱

        變數或是函式的名稱應該要清楚地說出變數與函式的用途。現在的編輯器都支援名稱提示自動完成的功能。不要為了想少打幾個字,而取那種過了一個星期之後連你自己都不知道是什麼意思的式名稱。

      3. 只寫恰當的註解

        註解裡面只要指出程式碼裡面沒有的東西(參數格式、呼叫此函式前應該被滿足的條件等...)就好了。最好可以搭配一些文件產生工具(如 javadoc)自動地產生說明文件。

      4. 保持程式碼易讀好懂

        不要用一些奇技淫巧來賣弄你的程度,因為日後可能連你自己都看不懂你在寫什麼。遵守 "KISS" (Keep It Simple and Stupid)"DRY" (Don't Repeat Yourself) 這兩個原則,自然就可以寫出易讀好懂的程式碼。

      --
      繼續用轉錄翻譯文章來充版面...