目前分類:未分類文章 (45)

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

不得不說 Xcode 的功能跟其他 IDE 相比,真的挺陽春的,多虧網路上一堆熱心的開發者,幫忙開發了不少 plugins,稍稍補強了 Xcode 的功能。底下就列出我目前有用到的 plugins,當作一個備忘,也歡迎大家跟我分享好用的 plugins。

強烈推薦使用 Alcatraz 管理這些 plugins!


AutoHighlightSymbol

Xcode 有內建高亮度同一個變數的功能,但它所謂的高亮度只是為每個變數底部加上虛線,所以很難讓人注意到。這個 plugin 加強了原有的功能,當選中某個變數的時候,同一個變數都會自動加上背景高亮度。當想要追蹤某個變數在函式的哪些地方被用到時,這個 plugin 就會非常有用。另外這也是我寫的第一個 Xcode plugin :D

Backlight

高亮度當前列,這是很多編輯器都有的功能,不知道為何 Xcode 沒有內建。

BBUFullIssueNavigator (新版的 Xcode 已經不需要它了)

當有 issue 產生的時候,顯示完整的 issue 內容,而不是只有顯示前幾行。

BBUncrustifyPlugin-Xcode

支援 Uncrustify 跟 ClangFormat 這兩種程式碼整理工具,可以方便的讓程式碼擁有一致的風格。

DerivedData Exterminator

有時候 Xcode 會因為舊的 derived data 而有奇妙的問題,這個工具讓你可以快速的清除 derived data。

FuzzyAutocomplete

最好用的程式碼自動補完工具,能夠大幅減少打字的次數,加快開發速度。尤其 Objective-C 的程式碼通常都很長,有了這個工具之後真的差很多。

HTYCopyIssue

開發難免會出現 error,這個工具可以幫忙快速複製錯誤訊息,然後一鍵搜尋 Google 或 StackOverflow 有關這個錯誤的資訊。

IntelliPaste

讓你更方便的複製貼上 method 跟 RGB color。

KSImageNamed

自動補完圖片檔名,並且還提供圖片預覽功能,讓你不會選錯圖片。

MLAutoReplace

透過自訂的設定檔,可以自動取代某些字串,加快開發速度。

ColorSense for Xcode

方便預覽與輸入顏色的工具,調整 UI 的時候非常好用。

Dash Plugin for Xcode

將 Dash 整合到 Xcode,方便開發者查詢文件。

ProjectWindowName

它會改變 Project/Workspace window title,將 project name 附加到 file name 前面。如果你會同時開啟多個 project 或 workspace,這個工具能讓你輕鬆辨別每個檔案。

SCXcodeSwitchExpander

自動補完 switch-case,減少許多打字次數,又可以避免漏打某個選項,非常方便。

SCXcodeTabSwitcher

用 ⌘cmd + [1..9] 切換分頁。

VVDocumenter-Xcode

幫你快速產生註解,並且符合 appledoc,Doxygen,或 HeaderDoc 格式。

XcodePlus Delete Line

這個工具做的事情很簡單,就是透過熱鍵快速刪除一行或多行程式碼。

XReset

不用啟動模擬器就能重設模擬器的設定與內容。

文章標籤

Nelson 發表在 痞客邦 PIXNET 留言(3) 人氣()

這幾年都在 start-up 打滾,跟著做了一些產品,也有一些小小心得,就紀錄下來跟各位分享討論。

不要一開始就寫程式

你(或你們公司)想到了一個好點子,這時你要做的第一件事是什麼?馬上捲起袖子把點子實作出來嗎?千萬不是!你們要做的第一件事是確認真的有客戶需要這個點子,而不是草率投入大量時間、人力、金錢成本,最後做出來的東西卻可能沒人要。

或許你會想說東西都還沒做出個雛形來,怎麼知道有沒有客戶呢?方法有很多種,例如你們可以把點子解釋給陌生人聽,看看對方的反應如何。或是先快速開發一個 landing page 來介紹你們的點子,並收集使用者的回饋。

確定真的有人需要這個點子,並且確定這個點子真的需要寫程式之後,再開始動手寫。

寫好 User Story

你可以不寫 Spec,但千萬不能沒寫 User Story。User Story 的寫法很簡單,長得大概就像這樣:「為了解決什麼問題,身為一個使用者,我希望在某種情況下,能夠做某件事」。

寫 User Story 有幾個好處:

  1. 可以讓所有人都看得懂因為 User Story 就是用大家都明白的語言,把想要做的事寫出來,所以無論是不是技術背景的人,都可以看懂「為何需要這個功能、這個功能是為了解決什麼問題」。
  2. 可以幫助整理思路因為你得把你在什麼情境底下想要完成什麼功能寫出來,在寫的過程當中就可以整理自己的思路,檢查這樣的需求是否合理。然後因為大家都能看懂,所以無論是否有技術背景的人,都可以一起來討論,這樣就可以幫忙找出盲點,並且完善整個需求。
  3. 可以讓開發者用最適合的解法解決問題為什麼我會覺得不需要寫 Spec 呢,因為寫 Spec 的人不一定是要開發的人,所以很容易就寫出很莫名其妙的 Spec。更糟糕的是,有可能一開始就寫 Spec,少了互相討論完善的階段,結果最後整個歪掉。所以我會說不要寫 Spec,寫 User Story 就好,然後把 User Story 寫完整。有經驗的開發者看到 User Story 自然就會找出最適合的方式去解決問題。千萬不要外行領導內行,亂下指導棋。
  4. 方便驗收既然 User Story 都寫得那麼完善了,要驗收的時候只要一一對照 User Story 就可以知道是否完成所有需求。對驗收人員來說,看 User Story 就會知道這個功能到底是什麼,也就代表很容易就能理解要驗收什麼。

一定要使用版本控制系統

版本控制系統的好處我就不多說了,無論是單打獨鬥或是團隊合作都應該要用版本控制系統。我個人最推薦的當然是 Git,雖然它的入門門檻頗高,但熟悉它之後所帶來的好處真是讓人無法抗拒的。

近年來 Git 有越來越多好用的 GUI,已經大大降低初學者上手的難度,SourceTreeTowerGitUp 都是不錯的選擇。至於要如何將版本控制系統整合到你的開發流程,可以先參考 Git Flow 跟 GitHub Flow,再逐步調整成適合你們團隊的作法。

有了版本控制,當然就得記得要下版本號,如果不知道該怎麼決定版本號,可以參考語意化版本號的作法。

不必一開始就寫測試

可能有些人覺得這是邪魔歪道,不過我真心這麼覺得:「你應該寫測試,但你不應該一開始就寫測試」。

身處在 start-up,無論前期的思慮有多麼周到,產品的需求還是很容易就會變更。如果採用「測試先行」的話,最後你會發現絕大多數開發的時間都拿去寫測試了,而且因為需求在前期很容易變更,所以你的測試也很容易一改再改因而難以重複使用。(P.S. 降低需求變更機率的一個方法就是好好寫 User story)

所以我會建議,等產品到達一定的穩定度之後(例如主要的功能或畫面都已經固定),再來補上測試。到時可以特地安排一段時間專心來寫測試,或是在需要重構程式的時候邊重構邊補上測試。

善用追蹤工具

做任何決定之前都要有所本,不要突然「通靈」了就做出莫名其妙的決策。那要根據什麼做決定呢?很簡單,讓數據說話。善用至少一款追蹤工具(GAMixpanelFlurryKissmetricsKeen IOCustomer.ioSegment 等等)並在上線第一天就開始追蹤使用者的行為,這樣才能知道有多少使用者在用你的產品,以及如何用你的產品。總之,就是要透過數據收集與分析,來了解你的使用者。

日後當你要做 growth hacking 的時候,追蹤工具更是不可少,你會需要這些追蹤工具來幫你統計,看哪些修改會有助於你的業務成長,哪些修改反而會讓業務衰退,以及成長或衰退了多少。

如果有開發 APP 的話,你也會需要想辦法取得 crash log,這樣才知道程式掛在哪,我推薦使用 Crashlytics 幫你收集分析這些 crash log,它非常的好用。

愛用第三方元件

近年來 open source 越來越受到歡迎,網路上有各式各樣的第三方元件讓你取用,所以真的沒必要每一樣功能都自幹,如果有現成的可以符合你的需求,就大膽的用吧。再加上第三方元件的管理程式(像是蘋果開發者常用的 CocoaPods 跟 Carthage)也越做越好,早期會遇到的第三方元件版本控管問題已經很少見了,所以我建議各位可以盡量用第三方元件,或是將第三方元件修改成符合自己需求,沒事不要自己造輪子。

方便的更新機制

隨著時間過去,你的產品需求一定會有所變化,該怎麼向後相容以及如何要求使用者升級就變成一件不得不面對的問題,這裡我有幾點建議讓你參考。

  • 設計 API 的時候要考慮版本化同一支 API 背後的商業邏輯很有可能會變化,如果一開始設計的時候沒有考慮版本化,你就會為了 API 名稱而大傷腦筋:可能原本的叫做 checkout,後來叫做 checkout_new,再後來叫做 the_new_checkout。但如果一開始有考慮版本化的話,你就可以一開始叫做 checkout/v1,後來叫做 checkout/v2。或是直接改 API end point,例如一開始的 end point 是 api.myserver.com/v1/,後來的是 api.myserver.com/v2
  • 呼叫 API 的時候附上環境參數雖然現在送 request 的時候,大部分都會在 header 附上 client 的一些資訊,但每個 client 送出的 request header 格式有可能並不統一,所以要 server 去 parse header 來取得所需資訊,其實成本蠻高的。比較方便的方法是,client 每次在呼叫 API 的時候就主動附帶一些參數讓 server 好判斷。例如可以送 platform 參數指明是 ios / android / webdevice 指明是 phone / tablet / desktopversion 表示程式的版本等等。Server 就可以根據這些參數有不同的邏輯與回應資料,例如根據 device 回傳不同尺寸的圖片網址,或是根據 version 來得知對方是否使用最新版本。
  • In-App Announcement如果一開始就有設計 in-app announcement 機制的話,就可以更輕易讓使用者得知最新消息。例如有新版本可以下載了,讓使用者知道有什麼新功能並引導使用者去下載。或是有在舉辦什麼活動的時候,也可以透過這個機制讓使用者知道(例如 Uber 時常會舉辦不同活動,車子圖示也會跟著變)。或是有什麼新貼圖、新佈景主題、新內容,也可以讓使用者知道(例如 Line 或各款遊戲)。
  • 儲存資料的時候要考慮版本化有很多時候我們必須儲存一些資料在本機,可能是透過寫入設定檔或是寫入資料庫,如果儲存資料的時候有考慮到版本化,之後要處理資料相容或是要將舊資料轉換成新資料的時候,都會相對簡單許多。

寫文件

所有人都知道寫文件的重要,但是大概沒人會喜歡寫文件,但其實文件沒那麼難寫。文件存在的理由是什麼?不就是為了日後的查詢參考嗎。

所以 User Story 就是文件的一部分,你一邊設計產品的同時,就一邊在寫文件了。這樣有沒有覺得寫 User Story 很划算,會不會更有動力寫好它!

程式碼註解也是文件的一種,現在有很多工具能夠將註解轉換成說明檔,日後只要註解有所變動,說明檔就會自動更新,這可以幫忙省下超多時間。像我們的後端都會在程式碼裡頭註解說明這支 API 的用途是什麼、傳入的參數是代表什麼意思、是什麼型態、是否可以不傳、回傳值是什麼、有可能產生哪些 error,對應的 error code 是什麼等等。我個人覺得,維護程式碼的註解比額外維護一份說明文件(可能是 wiki 或是 doc 等等)簡單多了。

文件也不是寫完丟在一旁就算了,它是讓人日後可以查詢參考的,所以最好可以把所有文件統一放在一個地方,然後有個方便的作法讓人查詢(可能是規劃良好的目錄結構,或是提供搜尋功能等等)。

簡單來說,文件有三大重點:要完整、要保持最新版本、要讓人找得到。

畫 Wireframe

通常設計師會畫好 wireframe 讓工程師知道整個使用流程,明白該從哪個畫面跳到哪個畫面。如果很不幸的,你們公司沒有這種東西(可能是不見了或根本就沒有),那 APP 開發工程師就認份一點自己畫一個吧。對工程師來說,畫這個並不難,只要把 APP 每個畫面都擷取下來,然後用箭頭把彼此之間的前後關係串起來就可以了。

擁有一份完整的 wireframe 的好處在於,當你們想要增刪或修改某些功能的時候,可以把 wireframe 拿出來,看看增刪或修改這個功能之後,整個使用流程是否順暢合理。千萬不要功能都做完,才發現流程變得卡卡的,這樣浪費的成本太高了。


老實說,就算每一點都做到了,也不保證你的產品會成功,但絕對會讓你開發一款新產品時比較不會走歪,就算歪了也可以早一點救回來,降低你犯錯的成本。

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

TL;DR

前一陣子 AFNetworking 被爆出存在安全性漏洞,它們也針對這件事情發出聲明稿

簡單的說,就是建議開發者使用最新版的 AFNetworking,並且啟用安全連線。不過它們也承認這一部份的說明文件沒有寫得很齊全,所以困擾了不少開發者。

今天花了一點時間研究,順手把它記錄下來。安全相關的東西不是我的專長,所以如果有任何錯誤的地方,請留言告訴我。

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

在網路上已經有很多人分享各種 Objective-C 的程式碼風格,例如 NYTimesGitHubRay Wenderlich,我相信各位讀者公司應該也有一套自己的規範(如果沒有,那請趕快制定一套吧!),所以今天我不是要分享我們的程式碼規範,而是要來說說要怎麼將不符合規範的程式碼轉成合乎規範。

我研究了一些程式碼美化的工具,最後選用的是 BBUncrustifyPlugin-Xcode 這個 Xcode plugin,它最早只有支援 Uncrustify,最近也開始支援 ClangFormat 了,我個人是比較偏好 Uncrustify,因為它可以調整的選項比較多。

文章標籤

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

在好久好久以前,我曾經寫過一篇教學,說明如何讓每篇文章自動加入 Google AdSense 廣告,以及延伸出來的一些應用。只是後來因為種種因素,所以就算看到版友們回報一些問題,也一直沒去修改它們,實在是非常抱歉 m(_"_)m

今天 dragonspring 板友根據我分享的原理,寫了一個讓大家都看得懂的手把手教學,造福更多的朋友。有興趣的人請過去看看吧,若他的作品對你有任何幫助,也別忘了給他一些實質鼓勵喔~

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

每個人難免都會有過幾台相機,我也不例外,不過人生中第一台我自己買的、屬於我自己的相機,是目前手上這台 Canon G11。跟了我半年之後,現在我決定要將它賣掉了,原因無他,只是因為我決定換一台單眼,而我不希望 Canon G11 這樣一台好相機從此被我冷落,它會哭的~

所以我寫這篇文章,是想要找看看有沒有人剛好想要一台好相機,又受限於預算所以不能買太好的,那你或許就是它的新主人。我打算賣$14,000,若不要記憶卡的話算$13,500。希望賣給在新竹及其以北的朋友,這樣才可以當場面交,讓你當場測試,有需要的話我也可以教你操作方式。當然若是你很相信我,覺得不用測試不用清點沒關係,那我也接受外縣市郵寄啦!希望成為它下一個主人的朋友,請寄信到我的信箱:)

2010-04-24_25.jpg

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

自我揭露:這篇是我接受 TutorABC 五堂免費試聽課程之後,所寫的心得文。

不知道各位是從何時開始接觸英文的,我個人是從幼稚園開始就有接觸了,一直到高中都還有在補習,一直到現在我覺得最困難的地方在於「說」。「讀」跟「寫」這兩個部份,相信大家從小到大已經接受過許多的練習了。至於「聽」,只要願意,可以多看些外國影集來訓練,或是上 YouTube 找演講或報告來看,倒也不算是太大問題。最大的問題在於「說」,一般人並不容易找到說的機會,就算有機會了也不太敢說,對我而言,TutorABC 補強了我這一方面的不足。

Nelson 發表在 痞客邦 PIXNET 留言(4) 人氣()

無名小站在一個月前發表了一篇 [公告] 無名部分服務退役,終止服務,裡頭提到講到中止網誌備份檔的下載服務,今天正是最後期限。

如果你不明白為什麼沒有提供備份服務給使用者是個很大的問題,可以參考這些文章:

如果你明白備份的重要性,而決定要搬家了,可以在網路上找到許多教學,Pixnet 也提供了完整搬家服務,詳情請看 [教學] 部落格搬家教學

如果你想離線觀看備份檔 (無論是 無名的 XML 檔,還是常見的 MT 格式檔),可以使用我寫的免費軟體 - 網誌備份瀏覽器,若是在使用上遇到問題,請先看看 教學文章,裡頭有常見問題 Q&A。

多想兩分鐘 不用再想了,你值得更好的選擇!

Nelson 發表在 痞客邦 PIXNET 留言(5) 人氣()

活動網址在這裡

先登入再連到活動網頁,輸入通關密語『痞客邦為中華隊加油』,即可獲得免費一年份 VIP,截止日期是 2009/03/08,已經是 VIP 的會員不適用。

Pixnet 真是太貼心啦!

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

為了迎接新年的到來,Pixnet 提供了一份禮物給每位會員,領取期限只到 1/4 (也就是明天),手腳要快喔!

是什麼禮物呢?只要到 http://tvbsg42.pixnet.net/blog/post/24352323 輸入密碼,就可以免費獲得 Pixnet 小而省 VIP 一年份,密碼就是「新年痞翻天」這五個字。你必須先登入才能參加活動,而且一個帳號只能使用一次。

快去申請吧,期限只到 1/4 喔!

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

之前我就有介紹過 Google Chrome 這套瀏覽器(請參考 [情報] Google Chrome - Google 推出的瀏覽器各項功能一覽[分享] CNU - 檢查 Google 瀏覽器是否有新版本[閒聊] Google Chrome 會吃掉誰的用戶?),就在昨天它拿掉 Beta 字樣,推出正式版了。

根據官方部落格的說法,它有以下改進:

  • Better stability and performance of plug-ins (particularly video)
    對插件的支援更穩定、效能更好,尤其是針對影音的支援。
  • Even more speed.
    自行研發的 JavaScript 引擎效能更好了。
  • Bookmark manager and privacy controls.
    被人要求許久的書籤管理功能終於加入了。

有在使用的朋友應該會自動升級到新版,沒使用過的人也可以考慮開始玩看看了。

下載 Google Chrome

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

Pixnet 新改版之後傳出不少災情,還好目前已有逐漸好轉的跡象,今天剛好遇到在某種情況下無法上傳照片的問題,摸索了一下找出一些原因,分享給各位。

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

Google 買下 FeedBurner 已經過好久了,最近終於有一些整合的動作,第一步就是開始在 FeedBurner 燒出來的 RSS 裡頭加入 AdSense。新東西當然要嘗試看看,所以我也弄了一個來玩,只是可惜 Google 目前還不能跟 FeedBurner 原有的帳號整合,所以我無法把先前用 FeedBurner 燒出來的 RSS 拿到 Google 來用 /__\

另外,Pixnet 最近大改版,連 RSS 的網址也改了,所以就趁著這個機會,大家一起把訂閱網址也改了吧。

新的 RSS 網址是 http://feedproxy.google.com/nelson_tai,你也可以點擊側邊列上方的 RSS 圖示來訂閱。請各位舊雨新知繼續支持:)

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

為了慶祝耶誕節、慶祝過新年、慶祝我就快要領到這個月的薪水、慶祝我上班以來第一次請特休,所以我把側邊列的廣告以及一些小東西拿掉了,這樣應該可以加快開啟網頁的速度。

本活動為期七天~XD

/*
 * 唉~若是可以放廣告,又可以不拖慢速度該有多好。聽說 Pixnet 近期會推出讓使用者方便在網誌放入廣告的機制 @@
 */

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

不知道各位有沒有發現,在側邊列多了一個 MSN 小綠人 小綠人的圖示,只要點擊這個圖示就會開啟一個新視窗,你就可以利用這個視窗跟我 MSN 囉~

希望這個小玩意兒對於那些有問題需要找我的人有所幫助,沒事不要亂丟阿~ 當然,丟正妹連結給我是很歡迎的 XD
還有,丟訊息過來的時候請先告訴我,你是透過網誌上的 MSN 丟過來的,不然我會誤認為是廣告機器人而不理你喔 Orz

對了,想知道怎麼弄的人,請看這一篇教學

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

COSCUP 宣傳貼紙

底下說明節錄自官方宣傳稿:

COSCUP 開源人年會

Coders、users 和 promoters 是讓 open source 軟體發光發熱的支柱,社群同好在相關的領域中的貢獻,讓 open source 軟體更趨成熟。每年一次的開源人年會,是專為這三種人舉辦的。你可以是 A 軟體的 coder、B 軟體的 promoter 或是 C 軟體的 user。不論你是已經踏入 open source 領域,還是一直站在門口不知如何入門,又或者你是圈子裡的長輩,我們都竭誠歡迎你來參加 COSCUP - Conference for Open Source Coders, Users and Promoters!

今 年的 COSCUP 開源人年會與 ICOS 聯合舉辦,讓一年一度的自由軟體界盛事更為盛大。而今年的 COSCUP 最大的改變,是由各台灣本地社群共同舉辦,也希望能透過這樣的合作,增加社群同好的參與度,正如 COSCUP 的精神,在這個研討會當中,你同時是與會者,推廣者,也參與了大會的運作。

今年 COSCUP 的重點,因 Web 2.0 及 OLPC 等發燒話題,因而排入了許多與 Web 平台及嵌入式系統的相關議題,而中文議程、閃電秀及系統議程則是歷年來聽眾有興趣的重頭戲。此外今年因各大開放源碼相關法人陸續成立,也提供了一個機會讓 各法人可以交流。

議程內容精彩絕倫、除了邀請到社群重量級前輩、我們也希望藉由發掘本土隱性OSS 專案,找到更多的參與者,讓大家有機會在這個場合中擦出更多的火花。
對這方面有興趣的朋友,歡迎一起去參加喔!我是第一次參加,報名了六日兩天所有的議程。

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

今天無意間才發現 Pixnet 又有新活動了,叫做 部落客苦情盃

這個活動真是太 KUSO 了,不管是遊戲還是圖都很好笑阿 XD

不過 XDite 會不會太可憐,莫名其妙就被槌了 XDDDDDDDDD

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

眼尖的人應該已經發現了,在右側的搜尋服務裡多了一個「博客來搜尋」,而在右下角的推薦連結裡頭也有個博客來首頁連結。然後我又剛好推薦了博客來的商品給各位,看到這裡就算原本沒注意到的也應該注意到了,原本注意到的也可能有點起疑心了....

有讀者朋友發現這件事並詢問我,我就藉著這一篇文章向各位說明。

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

兩天前我舉辦了一個投票([投票] RSS 是否要顯示全文),最後的結果是贊成顯示全文的人佔了多數,所以這幾天就先顯示全文吧,看各位的反應如何。若是各位後來覺得顯示全文不太好閱讀,我再改回顯示「繼續閱讀」就好了。(其實我個人是偏好「不顯示全文」的,因為我有些文章非常的長,這樣一來就會變得很可怕,不過我還是尊重各位啦。)

或者,我還有另一個點子。
因為我有用 FeedBurner 燒 RSS 連結,也可以設定 FeedBurner 的 RSS 只顯示前 300 個字。如此一來,喜歡全文的人就訂閱 Pixnet 提供的連結,喜歡只看到摘要的就訂閱 FeedBurner 的連結。
若是大家有興趣的話,我也可以這樣玩玩看。

另外,我發現一件挺有趣的事。透過 FeedBurner 的分析頁面,我看到有四百多人訂閱我的網誌,可是來投票的人卻只有少得可憐的 20 人。諸位安靜的讀者們,如果你願意的話,可以告訴我為什麼不想投票嗎?

Nelson 發表在 痞客邦 PIXNET 留言(13) 人氣()

雖然現在 Pixnet 可以在網誌後台設定 RSS 是否要顯示全文,或是顯示「繼續閱讀」,不過我的想法是,訂閱 RSS 的是讀者又不是作者,那麼選擇是否要出現全文的也應該是讀者阿。

不過可惜的是,目前 Pixnet 站方並沒有提供「全文」跟「摘要」兩種 RSS,所以只能有一種選擇。我也有發表一篇文章跟站方建議,不過目前還沒有回應就是了。若你覺得我的建議不錯,或許可以考慮幫我回應一下加加人氣,應該比較容易被站方看到。

既然目前 Pixnet 站方無法提供兩種 RSS,那我就先把選擇權交給讀者諸君吧。
  • 投票題目:RSS 要顯示「全文」或是「摘要」
  • 投票日期:6/13(三)晚上 12:00 截止
  • 投票方式:請各位朋友在文章底下回應,告訴我你比較喜歡「全文」或是「摘要」
就這樣啦,麻煩各位囉。

Nelson 發表在 痞客邦 PIXNET 留言(21) 人氣()

1 23