Headset 3.5mm Conncector Standards

現在的人因為智慧型手機汰換很快，手邊越來越多附贈的耳機跟充電線，這些耳機多半具備音量線控、來電接聽、跟麥克風的功能，跟傳統立體聲耳機不太一樣，雖然說很早就遇過插進一般電腦耳機孔左右聲道會有些問題，但也一直沒細究。查了一下才發現這裡頭還有不一樣的標準，雖然都是 3.5mm 接頭，卻又互不相容。

TRS 接頭
TRS 的全名是 tip-ring-sleeve [1]，也就是傳統常見的立體聲耳機接頭，金屬接點分成三段，分別是尖端 (tip)、基部柱狀 (sleeve)、以及中段 (ring)。Tip 跟 ring 這兩個名稱源自古早手動接線的電話系統 [2]，當時並沒有左右聲道，但後來用在耳機接頭時，分別作為左右聲道訊號使用；而 sleeve 則用於接地。至於更古早的單音耳機，因為只需要兩段金屬接點，因此使用的接頭是 TS 接頭。

目前常見智慧型手機附贈的耳機，接點分成四段，稱為 TRRS 接頭。就訊號來說，尖端兩個與 TRS 相同，靠基部這邊的 RS 則又分成 CTIA (又稱為 American Headset Jack; AHJ) [3] 跟 OMTP [4] 兩種標準，前者的 RS 分別為接地與麥克風，後者則剛好顛倒過來。因為聲音輸出時，訊號必須對應接地才能成功推動發聲元件，因此 CTIA 與 OMTP 間混用會因為找不到接地線，而無法正確發聲。

這兩個標準大致上老舊跟山寨的產品多使用 OMTP，像是 SONY ERICSSON 跟 Coolpad/OPPO/ZTE；而 CITA 則廣泛用在現在市面上多數手機，包括 Apple/ASUS/LG/Meizu/SONY/Xiaomi；至於 HTC/MOTO/NOKIA/SAMSUNG 則要看機型而定。

如果需要在電腦上使用手機附贈的耳機，可以購買轉接線完成。

See also:
[1] Phone Connector (Audio)
[2] Tip and Ring
[3] Cellular Telephone Industries Association (CITA)
[4] Open Mobile Terminal Platform (OMTP)

Customer Relationship Management (CRM)

一般來說 CRM 系統會包括 3 個主要功能模組：行銷 (marketing)、業務 (sales)、客服 (customer support)；可以直接對應到公司面對客戶時的主要三個階段。其中 CRM 的業務模組通常只提供報價 (quote) 功能，至於成交後的訂單 (order)、合約 (contract)、倉儲 (inventory)、發票 (invoice) 等管理功能，多半會回到 ERP 的模組中，而不在涵蓋範圍中。

這 3 個模組中，又以業務功能為 CRM 的最核心，CRM 的行銷功能往往專注於 target list、bugget planning，輔以更專業的系統負責 custom portal、multi- campaign channel management (newlettter, email, phone call, social networks)、閱讀追蹤、SEO 等功能；而客服系統也往往會拆分出 helpdesk 系統，提供更多案件 (case) 追蹤功能。

	Marketing	Sales	Customer Support
Accounts
Contacts
Targets
Campaigns
Leads
Opportunities
Quotes
Cases

上表是 CRM 中常見名詞跟 3 個功能模組的關聯對應，其中 campaigns, opportunities, cases 是分屬 3 個功能模組的活動紀錄，其他則為客戶資料。Accounts 跟 contacts 是相對中性的；targets 是蒐集到客戶資料後的第一階段，經 marketing/sales 資料審核後轉成 leads，視連繫狀況再轉為 prospects，等到報價確定成交成為訂單後，再轉為 customers，由客服模組負責。[1][2]

客戶數在各銷售階段的轉換過程中會逐漸縮小，呈漏斗形，故稱為 sales funnel。一般來說 sales funnel 以 leads 為起點 (更之前的 anonymous 資料未存於系統中)，後續才是 prospects 跟 customers；在 Salesforce 跟 SuiteCRM 的設計中，lead 可轉換為 account，prospect 跟 customer 都被視為是一種 account type [3][4]。

Salesforce 預設的 account type 有 Analyst, Press, Competitor, Prospect, Customer, Reseller, Integrator, Investor, Partner, and Other [4].

部分專營 B2B CRM 的廠商會在 CRM 前再多一個 Marketing Automation Systems (MAS)，負責蒐集潛在客戶資料，經過評分過濾成為 lead [5]。

see also:
[1] Customer Relationship Management: Aspects, Strategy and Use of Technology
[2] What is the Difference between Campaign, Opportunity, and Case?
[3] SuiteCRM User Guide
[4] What are the default picklist values in Salesforce?
[5] B2B Marketing Stack Basics: CRM, MAS, and The B2B Lead Lifecycle
[6] The True State of Open Source CRM
[7] 行銷與業務有何不同？這45件事讓你搞清楚

Contract, Interface, and API Document

有一些程式經驗的人大多聽過 design by contract 這個詞，意思大致是按照 contract 實作；部份習慣於 object-oriented programming 的人很自然的就把 contract 誤以為等價於 interface，中了 interface-as-contract myth [1]。

Interface 跟 contract 最大的差別在於：interface 是純粹的介面，不涉及實作後的行為，也就是說按照 interface 實作的 client code，只確保能呼叫得到，不能確保呼叫後的行為是否符合預期；但是 contract 是包括 precondition 與 postcondition，比 interface 更進一步限制了實作行為。

但這也並不代表 contract 就能完全涵蓋 interface，主要因為 contract 通常並不涉及實作的語言；例如 interface 可以指定 method arguments 的順序跟型別，但這些通常不會涵蓋在 contract 裡頭。也因此當我們談 test code generation 時，interface 扮演主要角色，而 contract 則在 test case (input/output) generation 扮演主要角色。

最後是 API document ...
API document 主要目的是讓編寫 client code 的人能正確地產生參數呼叫 API，目的在於彌補 interface 的不足，一般會先解釋一下這個 API 的用途，加註各個參數 domain 上的意義而不單只是型別，另外也會描述拋出例外的情況等；因此就意義上偏向 contract 更多一點，但又比 contract 多依賴了特定 programming language 或 protocol 等；甚至可以包括所有 contract 的資訊形成 API contract。

近年來因為 microservice architecture 的大量興起，讓 Web API 又受到重視，許多 interface description language (IDL), API description language, API documentation language 也相繼產生，釐清上面三個的角色跟功能，可以幫助我們回頭檢視這些 description languages 應該有的功能跟後續自動化的可能。


see also:
[1] API Design Myth: Interface as Contract
[2] An API Definition As The Truth In The API Contract
[3] Design by Contract

Tagging System Design

Tagging 也算是目前系統中常見的功能，實作上也被討論了不少，大致上分底下 3 種類型：

1. Denormalized solution
   Pros:
   • 單一 table 易於直接人工閱讀資料與維護。
   Cons:
   • 所有 tag value 集中於一個 cell，需要保留一特殊字符作為分隔使用。
   • 查詢時將大量使用 LIKE，查詢條件字串組成受限；但效能上可能優於 JOIN [1]。
2. Entity-Relation solution
   Pros:
   • 使用獨立的 table 專門紀錄 tag value 與 entity 對應的關係。
   • 個別 tag value 被拆分為獨立記錄，不需要保留特殊字符，也不會大量使用 LIKE 運算。
   Cons:
   • 必須嚴格確保每一個 entity id 與 tag value 組合只會存在一筆記錄；否則使用 HAVING-COUNT 查詢時會出現錯誤。
   • Tag 本身無法帶有其它屬性，例如：引用次數/日期、從屬關係、有效與否、與內部/顯示名稱等。
   • Tag 更名時需要更新大量資料。
3. Intersection Table solution
   Pros:
   • 所有的 tag value 獨立一個 table 存放，易於統整 tag value 或更名。
   • Tag 本身被視為另一個獨立的 entity，可自由定義屬性。

Cascade Updates: 當使用 normalized solution 時，寫入時需要 cascade updates 往往是需特別注意的地方，但只要程式邏輯無誤，便不會產生 orphan relation/entity 的情形。

Tag vs. Category

• Tag 是 many-to-many 的關係，category 是 one-to-many。
• Tag 一般不實作階層式結構。階層式結構必須搭配 recursive search 才有效果，也就是以 parent tag 搜尋時，結果應包括與 child tag 關連的項目；但一般像 GMail 雖然表面上具備階層式的 label，實質上卻沒有 recursive search 的能力，屬於 一種 faux hierarchical tagging。

另外 [2] 提到 3 種常見的 tag 使用情境：(1) 使用 tag 搜尋；(2) 透過某一文件的 tags 尋找擁有類似 tags 的其他文章；(3) 透過一群 tags 搜尋其他相關 tags。

see also:
[1] Tags: Database schema
[2] In Lieu of the Promised Article on Tags and SQL

Windows Name Resolution

名稱解析 (name resolution) 雖然是存在已久的機制，但有時候還是會遇到一些因為實作差異而導致行為不同的地方。一般在 Windows 下常用的解析工具大概有 nslookup 跟 ping，撇除 single-label server name (a.k.a. Windows host name) 隸屬於 NetBIOS/WINS 的管轄範圍，當使用這兩個工具作一般網域名稱解析，需要注意的有：

• Windows 內建 DNS Client 服務 (service name: Dnscache)，會讀取系統網路介面 (network interface) 的 DNS 設定，負責 DNS cache。
• 當變更時網路介面 DNS 設定，DNS Client 並不見得會立即套用新設定，cache 資料也可能不會 flush。
• ping 解析時會先向 DNS Client 查詢，因此單獨變更 DNS 設定可能導致 ping 仍然讀取到舊資料；nslookup 不透過 DNS Client 因此會直接套用最新設定查詢。
• 可以透過系統管理介面，重新啟動 DNS Client 服務，達到套用新設定與 flush cache 的目的；單獨 flush DNS cache 可使用指令 ipconfig /flushdns
• 當 DNS Client 無該筆資料時，DNS Client 會根據 DNS 設定向外查詢，並將結果寫回 cache；nslookup 則無 cache 機制。
• 在 nslookup shell 中變更 default server 只會暫時有效，並不會寫回系統。
• 重啟網路介面時，亦會會重啟 DNS Client。
• %Systemroot%\System32\Drivers\Etc\hosts 檔案為 DNS Client cache 預載內容。

see also: ping vs. nslookup

Open Session in View

突然想起以前設定過 Struts2 中某個 filter，順手把之前的筆記再重新整理釐清。

Entity Manager and Transaction Manager

• 簡單來說，entity manager 關係到資料讀取，而 transaction manager 關係到資料寫入。
• 但兩者並非完全脫鉤，例如：在一個 transaction 中可能要參照其他 entity 的資料，或讀取 entity 時要避免 dirty data。
• 因此 entity 要負責追蹤資料的狀態 (entity state)，提供 transaction 中使用。

Open Session in View (OSIV)

• Open Session in View 中的 session 指的是 Hibernate session
• 用意在於避免 view rendering 的過程中，Hibernate session 過早結束導致後續 data lazy loading 產生 LazyInitializationExceptions
• 換言之，Open Session in View 拉長 Hibernate session 的時間，並交由 view request 控制。
• 值得注意的是：Hibernate session 結束與否不同等於 transaction commit or rollback；在純粹讀取資料的應用，操作是不需要 transaction 保護的，若是讀寫混合，Hibernate session 關閉的時機涉及 transaction 如何向 session factory 取得 Hibernate session，getCurrentSession() or openSession()，前者由 SessionFactory 自動控制，後者才需要手動在 commit or rollback 後關閉。

主張 OSIV 為 anti-pattern 的觀點集中於：

• OSIV 忽略 readonly 與 read-write 操作本質上的不同，不應該都由 entity 決定一次存取的資料量。
• 直接拉長 Hibernate session 給予底層實作傾向 lazy fetch 的空間，嚴重將導致 (n+1) select issue。
• 精細一些的作法，應該由 view 決定底層應該一次 fetch 哪些欄位的資料，使用 DTO projection，而非單純由 entity 決定一次取回的欄位數量。
• 但此種作法將提高 view 與底層 DTO 的耦合；傳統 view 只依賴 domain model，DTO 與 view 之間互不依賴。
• 注意：這邊指的一次存取資料量，與分頁查詢無關，分頁查詢的 query 會帶有 order 與起始/結束的 row number。

Hibernate Session and Entity Manager

• Entity Manager 是 JPA 定義的名詞，而 Hibernate session 及 SessionFactory 則是 Hibernate 特有。
• 一般起始的順序是：transaction manger, entity manager, Hibernate session，透過 entity manager 控制 session，避免手動控制。

see also:

[1] Open Session In View Design Tradeoffs

[2] The Open Session In View Anti-Pattern

[3] A Beginner’s Guide to Entity State Transitions with JPA and Hibernate
[4] Why is Hibernate Open Session in View Considered a Bad Practice?

Data Backup and Redundancy

接觸 IT 之後才發現很多人對 redundancy 跟 backup 之間的分野是混淆的，這種疑問就像前幾年 high availability 很熱門的時候，不少人都認為都已經有 data redundancy 了，還需要作備份嗎？

這種疑問通常忽略了萬一系統寫入異常或中毒的狀況，單純的 data redundancy 並沒辦法取回之前的資料狀態。

這篇文章寫的還不錯，提出了幾點：

• Data redundancy and backups are both intended to prevent data loss, but the two technologies are quite different.
• Data redundancy often takes the form of a synchronized copy of the organization’s data.
• Data redundancy can help to prevent service outages.
• Backups, on the other hand, are copies of data and other resources.
• Backups are also a good choice for granular recovery (recovering a single file, email message and so on). In contrast, redundant systems are better suited to situations in which the organization needs to keep critical systems online and cannot tolerate a long recovery period.

相關於 backup 與 redundancy 的字眼分別有：

• Backup: recovery, point-in-time, versioning, mean time to recovery (MTTR), revert, offline
• Redundancy: failover, hot spare, online synchronizing, performance, reliability

Availability 是從使用者的角度出發，無論系統是忙碌或是失效，對使用者都是 not availability，所以 availability 這字眼會同時涵蓋 backup 與 redundancy。

Remote Debug .NET Web Application with Visual Studio

.NET platform 的 remote debug 機制不像 Java 內建於 JVM，.NET CLR 並無內建此機制，需要在受測端安裝 agent (remote tools)，控制端只要安裝 Visual Studio 即可。從 client/server 架構來看：

• Server (受測端)：需執行 Remote Debugging Monitor (msvsmon.exe) 與 IIS worker process (w3wp.exe)
• Client (控制端)：執行 Visual Studio

Note:

• 基本上是 client/server 架構，client 執行 Visual Studio，server 要裝對應版本的 remote tools，預設 port 是 4016；版本不匹配可能會找不到或直接顯示版本錯誤的訊息。
• 針對 web application 的 remote debug 要 Visual Studio 2005 以後的版本，2012 開始 Community Edition 也支援 remote debug。
• Attach 的 process 是 IIS worker process (w3wp.exe)，因為一台機器上可能同時跑多個 workers，確認 target process 可以參考 [1]。
• Authentication 只支援 Windows 認證，需要在 server side 與 client side 都建立相同的帳號；不然就是不認證 (no authentication; since Visual Studio 2012)。當使用 Windows 認證時，client side 需以 debugging 用的帳號執行 Visual Studio。

see also:

[1] Identifying Worker Process (w3wp.exe) – IIS 6.0 and IIS 7.0 for Debugging ASP.NET Application
[2] How to Use IIS Manager to Get Worker Processes (w3wp.exe) Detail Information?

Google Calendar 可用色碼

Google Calendar 可以使用一個 URL 方便把單一日曆直接顯示在瀏覽器上，URL 的結構上開頭是 https://www.google.com/calendar/embed 後面可以串的參數有：

• src
• colors
• mode: 檢視的時間範圍，可以選 month, week, 或 agenda
• controls
• title
• firstDay
• bgcolor

另外我們也可以把多個 Calendar ID 放在 src 串接起來，同時顯示在一個頁面上，個別日曆的顏色可以自由指定，方便區分事件來自不同日曆。不過並不是任意顏色都可以用，這邊是 Google Calendar 在 embedded mode 可以用在 URL 上的色碼代號，使用時要把 # 作 URL encoding，換成 %23

#060D5E	#0D7813	#0F4B38	#113F47	#125A12	#182C57	#1B887A
#23164E	#28754E	#29527A	#2952A3	#2F6213	#2F6309	#333333
#42104A	#4A716C	#4E5D6C	#5229A3	#528800	#5A6986	#5B123B
#5C1158	#5F6B02	#691426	#6B3304	#6E6E41	#705770	#711616
#754916	#7A367A	#853104	#856508	#865A5A	#88880E	#8C500B
#8C500B	#8D6F47	#A32929	#AB8B00	#B1365F	#B1440E	#BE6D00

參考資料：http://docs.servicerocket.com/display/AtlassianPlugins/google-calendar

打造Google Maps

今天看到則有趣的報導，"How Google Builds Its Maps"，裡頭訪問了Google Maps的資深產品經理，Manik Gupta；訪談中沒提及內部資訊架構，內容主要包括資料處理的困難，以及如何運用電腦視覺技術的進步，在地圖上獲取更多資訊。列一下看到的重點：

• 在手機時代販售廣告，Google發現使用者所在位置將與搜尋時使用的關鍵字同等重要。
• 地圖可視為線上世界跟真實世界的橋樑，最佳情況是將所有真實世界的資訊1:1地標註在線上地圖系統中。
• Google Maps除了一開始外購的基本衛星圖，更多資訊來自於街景車；一方面可以校正路線與衛星圖的偏差，另一方面可利用電腦視覺將交通號誌等標示擷取出來。未來希望可以達到geo-understanding。
• 針對路線與衛星圖的校正問題，Google花費了非常多的人力！訪談中Nick Volmar示範了如何操作，這確實不是一般沒有雄厚資本的公司能辦到的。
• 另外Google也利用了廣大的使用群產生的自訂地圖，擷取使用者的地理標註， 豐富 Google Maps的資訊。

最後一點，我認為現在的資訊量增長太快，光靠單一公司或政府單位去維護絕對不夠，想要保持資訊的正確性，最好的方式就是開放給大家使用，把錯誤回報或新增資訊的功能做好。相對於開發團隊間的知識分享也是，專案系統藍圖或各類領域知識，最好都能放到內部資訊平台，方便大家檢視與提供意見。

如果對於打造一個像Google Maps的系統有興趣的話，我倒覺得OpenGeo跟Open Geospatial Consortium有不少東西可以看。

初探Google Web Toolkit (GWT)

一直很佩服能夠在JavaScript海中優游自得，把web前端搞得又漂亮，程式碼又整齊的人！可惜更多時候看到的是苦命的前端工程師，在一堆前端函式庫裡，可能特定版本有bug，或不同函式庫間互相衝突，加上長官跟客戶不斷要求新功能... 在混亂的程式碼中剪剪貼貼，東試西試；一整個變成抓不到root cause的苦差事。

這幾天稍微認識了一下GWT (Google Web Toolkit)，簡單來說目的就是希望能減輕前端工程師的負擔，讓Javascript程式碼能夠更簡潔，更結構化；以目前常見的趨勢大概有：

1. 使用JavaScript函式庫，工程師仍然寫JavaScript程式碼；最有名的當然是jQuery，其他像是ZK/Ext JS/YUI則包括CSS的部分。
2. 使用另一種語言，透過新的語言強迫程式碼更加模組化，最後再編譯成標準的JavaScript；GWT就屬於此類。
3. 使用web MVC frameworks提供的tag libraries 。

原則上GWT可以讓工程師寫Java程式碼，最後編譯成JavaScript。基本上Dart也是類似的目的；不過就程式碼編譯的角度來看，Dart提供了自己的front-end，Dart language，不再使用Java，除此還：

1. 提供自有的binary format，可以在Dart VM上直接執行，省去解析JavaScript程式碼的過程。
2. 同時可以編寫client side跟server side的程式。

目前看來最大的問題在於如何結合既有JavaScript函式庫。

See also:

1. GWT: Pros and Cons
2. Google Web Toolkit: GWT, Closure, NaCl, Dart & JS
3. Dart: A Language for Structured Web Programming

CSS也是前端工程師常要遇到的領域，同樣也不少新的工具幫忙寫出更有結構的CSS。

1. Sass
2. Compass

對JavaScript有熱愛的可以順手做一下這個小測驗：JavaScript Scope Quiz

nVIDIA Tegra 3

這個月（2012.9）一堆平板陸續上市，我自己比較關注的包括iPad mini, Nexus 7, Kindle Fire HD, 跟MediaPad 7 Lite；主要原因在於：目前10吋的平板，單手拿起來當電子書讀，手腕還是很快就支撐不住，多數時候還是得依賴支架放在桌上使用。

今天湊巧看到一則新聞，有關nVIDIA對於Amazon宣稱Kindle Fire HD用的TI OMAP 4470可以秒殺Tegra 3的駁斥，感覺挺有意思的。長期以來，手機跟平板這塊最常聽到的處理器廠商應該是Qualcomm，其次才是nVIDIA跟TI，Apple跟Samsung也滿常聽到的，不過多是用在自家產品（華為海思也有類似的傾向），翻了一下wikipedia才知道ST-Erricson也有出這類SoC產品。

對於nVIDIA的印象大多是圖形處理器很強，軟體驅動程式寫得很好，一直不太清楚在mobile端產品的弱項在哪，趁這機會Google了一下大致上有兩點：

1. BSP (Board Support Package)較弱。
2. 無線通訊方面大多已經是Qualcomm的專利。

至於這次的處理器之爭，Tegra 3是qual-core 1.2GHz，OMAP 4470是dual-core 1.5GHz，新聞裡有一段：

This is usually TI's strategy with their chips - they use an older core, but they raise the clock speed.

此外，Tegra 3除了輸在時脈上，記憶體頻寬也是個問題：

As for the memory bandwidth, one of the biggest drawbacks of the Tegra 3 is that it still doesn’t support dual-channel memory, which means memory bandwidth is a bottleneck in some cases.

看來nVIDIA想要憑藉圖形晶片的優勢，進攻mobile市場逼退PowerVR，還是很辛苦的。

See also:

• Is the OMAP 4470 chip in the new Kindle Fire HD 8″ really better than the Tegra 3?

先前看過一系列關於x86跟ARM處理器的故事也滿值得看看的。

• ARM與x86之一：Wintel帝國
• ARM與x86之二：Atom的前生今世
• ARM與x86之三：蝶變ARM
• ARM與x86之四：EAGLE is Coming!
• ARM與x86之五：結束語

Android: An Overview

最近開始看了一些有關Android的材料，希望能在理頭找到一些研究的相關材料。從2007年底推出到現在，也有相當時日了，網路上介紹架構的文章並不難找，我大致上從mmdays.com的Android 淺探(一)跟Android 淺探(二)這兩篇入手去看；這兩篇出步說明了Google另外實作一個變形的Java VM, Dalvik的緣故，以及底層爲什麼選擇了Linux.

大致上整理出幾項要點：

1. 根據統計，Java是現在最常被使用的程式語言，使用Java VM可以方便程式人員進入開發各種applications. (see also: TIOBE Programming Community Index)
2. VM該提供哪些系統函式庫，在標準的Java VM裡，控制權掌握在SUN手上。
3. Dalvik針對執行時所需的memory footprint作最佳化。
4. Linux可方便硬體廠商開發驅動，但opensource並不見得與公司利益相符，所以需要修該原先的kernel把device driver拉到userspace去執行。
5. 針對kernel層的IPC, Power Management, RAM console等作了最佳化。

大致上看來Android提出的架構跟framework比起其他像是openmoko或OpenMax都來得完整，往後如果有其他聯盟想提類似的open mobile platform很難不把這些也都列入考量。（採用RIA, Rich Interactivce Application, 而不考量general purposed的架構像是 JavaFX, Flex等可能是另一種思考方向。）

相關值得看看的連結還有：

• wikipedia: smartphone, Dalvik
• betaversion.org: Dalvik: how Google routed around Sun’s IP-based licensing restrictions on Java ME
• blogs.sun.com: with Android and Dalvik at Google I/O
• Android配合Eclipse環境建置
• google.com: Anatomy & Physiology of an Android
• digitimes.com: 開放手機革命：市場觀察與Android SDK
• LiPS (Linux Phone Standard), LiMo (Linux Mobile Foundation; wikipedia), Open Handset Alliance
• Google Developer Day 2008 Taiwan : Android: Dalvik VM Internals
• Google Android平台先打到的是Java而非Linux?
• Sun力推Java标准版 手机移动版Java将逐步退出

[轉錄] 回收塑膠袋 省錢又環保

回收塑膠袋 省錢又環保

來源：http://tw.news.yahoo.com/article/url/d/a/080920/78/168vk.html
自由 更新日期:2008/09/20 04:09

〔記者林秀姿／台北報導〕棄用的塑膠袋也可以回收變黃金，環保局昨天再次針對廢塑膠袋回收加強宣導，民眾只要把不用的塑膠袋簡單清潔後，即可交由北市環保局清潔隊進行資源回收。

環保局科長蘇芳慧表示，民眾做回收時，塑膠袋切勿混雜垃圾、回收物或油脂等固體雜物，若曾盛裝豆漿、飲料、蔬果等垃圾袋，只要稍加沖洗，把水分倒掉瀝淨就可回收，而且不分顏色，各類塑膠袋都可回收，不過，蘇芳慧提醒，吸管或金屬光澤等複合材質的食品包裝塑膠袋，如餅乾、泡麵與清潔補充包的包裝塑膠袋，則不能當作塑膠袋回收。

環保局統計，北市自89年7月開始回收塑膠袋後，目前每月平均回收量已達160公噸，而回收的廢棄塑膠袋則變賣給回收工廠做成塑膠粒，再製成塑膠花盆、黑色塑膠袋等再生品，回收塑膠袋既環保又可節省民眾垃圾費支出。

3M無痕防水系列

家裡的毛巾架因為年代久遠掉下來了，先前固定的方式是在磁磚牆上鑽孔、旋入螺絲釘；久了磁磚壁的裂縫漸漸擴大，螺絲釘自然就咬不住而脫落。剛好想說3M無痕系列裡頭有個浴室防水用的，結果搜尋了一下：有掛鉤牙、刷架、置物架，就是偏偏沒有毛巾架這類東西（我需要的毛巾架大概要有兩呎以上的長度，不是那種只掛一條毛巾的）。而且意外地搜尋到這篇blog「3M無痕掛鉤」 ，原來浴室裡的膠條要先用吹風機稍微加熱才黏得牢！

那篇blog的作者還另外舉了很多公司客服的例子，看完覺得現在消費者都滿多聞的（當然不是我這種）；不過真的利害的除了發現問題，應該是那家公司的主管，在有限資源下解決這麼多瑣碎的問題。