2009年10月20日 星期二

Getting Started with Issue Tracking

Getting Started with Issue Tracking | ActiveState Blog

Got issues to manage? Most software teams do. They’re to-do lists
that get angry when they don’t get done, and they can make teamwork
flow through the day or end up in an unmanaged state. If your email
inbox is the only tool you’re using to track issues, you’re more likely
treading water than swimming. And it’s just that feeling that brings
many development teams to an issue tracking system to get a handle on
bugs and feature requests. With that in mind, we have a 2-part post of
guidelines for getting started with issue tracking.


Too Many Fields?

When you dig into your issue tracking tool of choice, you’ll likely see
a lot of fields. Just the thought of filling them all out for every
issue you log might make you think email isn’t so bad. But as the
Hitchhiker’s Guide says, “Don’t panic!” When getting started, look for
the fields that map comfortably to the way you and your team currently
talk about issue handling. Start with those, but keep the other fields
in mind as you work. As you get used to seeing them, you’ll likely find
good ways to incorporate them into the workflow.


Defining Terms

Without setting some definitions, you’d be leaving your team to bring
their own definitions to a system meant to get people communicating and
working together smoothly. There are 2 specific places where a strong
definition set from the start will solve a lot of uncertainty and
confusion, and maybe even prevent some arguments as you go forward.


Bug vs. Feature Requests

While this might sound like an easy and obvious distinction, it often
gets lost in moments of frustration, which are exactly the moments that
both bug reports and feature requests are born from. Making the
distinction clear in your charter for a new issue tracking tool will
help everyone understand these categories clearly.


  • A bug is something that was asked for but doesn’t work in the way
    it’s supposed to. It can only be used to describe existing
    functionality, or something that the software does but does not do
    correctly. If it’s broken, it’s a bug.
  • A feature request is a request for new functionality or a change to the way something in the software works.

Severity or Priority

Your issue tracking tool will use one of these terms to express ‘how
important is this issue?’. Some systems use both, and while that can be
useful, in most cases you will only need one or the other. When
reporting an issue affecting them, people are likely to see it as more
important than it really is in the grand scheme, because that issue is
topping them from getting things done. Some objective criteria can help
set some perspective.


I tend to favor the Priority label, and depending on whether an
issue is for a bug or a feature request, we’ll need different criteria
to evaluate it.


Bug Priority


  • Urgent or Critical: The problem prevents the
    software from operating or key requirements from being met. People
    cannot do their work with an urgent or critical bug.
  • High: The problem prevents key requirements from being met, but there is a workaround that will suffice in the short term.
  • Medium/Normal: The problem does not prevent key requirements from being met and can be worked around or lived with in the short term.
  • Low: The problem is an annoyance but is not preventing any requirement from being met.

Feature Request Priority


  • Urgent or Critical: The feature is needed as soon
    as possible. Not delivering it will severely impact the relationship
    with clients or customers. Other work needs to stop to make this
    feature happen.
  • High: The feature is strongly desirable and should be given priority, but does not disrupt any current work.
  • Medium/Normal: the feature is nice to have and can be assigned into an upcoming milestone
  • Low: The feature is nice to have and can be added to milestones with some time available.

Alternatively, you can use Severity and Priority to indicate
relative importance for users and developers respectively. For example,
end users could be allowed to set the Severity of a bug, but not the
Priority. Developers could then set the Priority based on the Severity
assigned by the user, while taking into account the development road
map, time constraints, and technical considerations.


None of these definitions are air-tight, and you’ll likely need to
reassign or discuss the priority of specific issues from time to time.
The important thing is that the whole team starts from the same page,
and over time you can refine the definitions to fit how you see the
world.


In the next post, we’ll look at considerations for getting started
with issue tracking for the team and client culture that your team
works in.

Getting Started With Issue Tracking - part 2 | ActiveState Blog

Getting started with issue tracking is much more than deciding on a
software application or hosted service. It requires taking stock of
team and client culture to arrive at a smooth and productive workflow.
In the first part of this 2-part post, we talked about starting with
the basics of what your choice of issue tracking system offers and
growing from there, as well as defining terms for describing issues
consistently across the whole team. In this post, we’ll look at more
high-level aspects of implementing issue tracking in your team’s
practices.


Visibility

The subject of visibility in tracking issues is about how much you let your clients or customers see in the issue database.


If you’re running an open-source or public project, the decision is
an easy one. Of course you need people to both see the issues that have
been reported and to contribute their own findings and requests to the
queue.


On a private project, the decision is more complex and comes down to
knowing the relationship you have with the people you’re developing
for. Let’s tackle the question in 2 stages: stage one is letting
clients and customers see issues and their status; stage two is letting
them add and modify issue tickets.


To decide if clients should see issue tickets and their status, ask yourself these questions:


Do your clients or customers ask for a lot of detail in how work is progressing, or only ask for periodic updates?
If
clients like detail, chances are they’re just looking for reassurance,
and being able to see that a ticket is logged for the fixes they care
most about will go a long way towards giving them some peace of mind.


Do you receive input on bugs or feature requests from multiple people?

If you get feedback from multiple people, then you’re likely seeing
duplicate issues. Enabling reporters to first search existing tickets
before firing off an email can help reduce duplicate issues, but it
won’t eliminate them altogether.


Assuming you’ve decided to let clients see tickets, now let’s figure out if they should touch them as well:


Do the bug reports and requests you get provide the right level
of detail and clarity, or are they more like emails with a subject line
saying “Help, it’s broken!”?

If clients and customers are giving
you reports that pivot nicely into starting a fix or a productive
conversation on how to proceed, then letting them file tickets and
answer questions in the system can be a huge time-saver. It has the
added benefit of allowing the reporting person to stay in touch with
how the issue is being handled, and maybe even give extra guidance or
details along the way.


Workflow
One of the most common causes of
confusion in issue tracking doesn’t come when opening tickets but
rather when closing them out. Make it clear to the team who comes next
in the chain of handling issues, and what the criteria are for closing
them. Some systems provide controls that only allow certain roles to
close tickets, while others can mark them as resolved or ready for
testing. Even in those that don’t, it’s important that the whole team
plays by the same rules, or you’ll end up re-opening tickets and
re-visiting bugs more often than you’d like.


As the team gets used to using the new system, you may need to
gently divert them from the old channels that were used beforehand. If
someone with the ability to create a ticket sends you an email about a
bug, you’re going to have to ask them to add a ticket for it, or you’ll
be back to dealing with email, as well as the new ticketing system.


Evolution
After you get rolling with issue
tracking, schedule some time 2 weeks in and again 2 months in for a
checkpoint meeting with the team about how the system is working for
them. Making sure everyone understands that how you use the system can
change with feedback will make the prospect of using it easier to get
into.


In fact, you can create an issue category for process improvement,
and invite everyone involved to log suggestions or points of friction
in using the tracking system itself. That’s right, we can use the
process and tools to fix what doesn’t work with the process and tools.


Conclusion

If there’s any part of good software development practices that defies
a one-size-fits-all approach, it’s issue tracking. The right system for
you will accommodate the idiosyncrasies of how your team works, while
gently suggesting good practices to follow from its built-in business
logic.

2009年10月18日 星期日

NAT Traversal

COdE fr3@K » Blog Archive » NAT Traversal, part 0
NAT Traversal, part 0
Posted on September 20th, 2006 at 1:43 by fr3@K

根據 wikipedia 的定義, 一個 peer-to-peer (p2p) computer network 是一個主要依賴該網路上參與者 (相對於依賴服務器) 的運算能力與帶寬的網路.


P2p 網路的達成主要有兩個困難點:

1. Signal, 一個 peer 如何找到另一個 peer 並與其溝通
2. P2p 資料傳輸

達成第一點的方法, 也就是使用的 signalling protocol 有很多, 現階段的規範也比較成熟完善. 例如 SIP 與 IMS. 相對來說, p2p 的資料傳輸是更走在技術的前沿.

無論原因為何, 大多數的裝置 (通常是電腦) 不是直接連上 Internet, 而是透過 NAT 或 NAPT (以下均稱為 NAT) 連上 Internet. 在這種情況下, NAT 的穿透 (NAT traversal) 成為了 p2p 資料傳輸的前提.

這些在 NAT 後面的裝置沒有公網 IP, 如不利用服務器轉送, 傳統上幾乎沒有廣泛通用的方法1 從一台這樣的裝置把資料傳輸資料到另一個這樣的裝置.

技術是一直在往前走的, 現在, IETF 的 behave , midcom 與 mmusic 等 working group 已提出在多數狀況下達到 p2p 資料傳輸的方法 (protocol). 在開始進入這些方法之前, 對 NAT 的相關行為必須要有透徹的了解.

這一系列的 NAT Traversal 將從了解 NAT 的行為開始, 到 STUN 與 TURN, 計畫會在 ICE 以及 ICE 在 SIP 的應用劃下句點.

繼續閱讀 NAT Traversal, part 1 – NAT Behavior.

1. 部份 NAT 支持由 Micro$oft 提出的 UPnP, 在應用程式也支持時也可達成 NAT traversal. UPnP 的功能包山包海, 因此其最大缺點為肥大以及容易產生安全漏洞. [↩]
COdE fr3@K » Blog Archive » NAT Traversal, part 1 – NAT Behavior
NAT Traversal, part 1 – NAT Behavior
Posted on September 21st, 2006 at 1:12 by fr3@K

續自 NAT Traversal, part 0.

NAT (不包含防火牆) 處理 UDP 封包的行為中, 對 p2p 影響最大的兩類為:

1. External Port Mapping
2. Filtering


exteranl-port-mapping.640x550.png

External Port Mapping 指的是當使用內部同一個端口 (L:l) 對外部發封包的時候, NAT 對外面是否使用同一個端口 (N:?):

* 若 NAT 對外使用的都是同一個端口 (n1 == n2 && n2 == n3), 則該 NAT 的 External Port Mapping 行為是 endpoint independent (與外部端點無關).
* 若只有在外部端點 IP 不變只變 port 的情況下, NAT 對外使用的都是同一個端口 (n1 == n2 && n2 != n3) 則該 NAT 的 External Port Mapping 行為是 address dependent (與外部端點地址有關).
* 若對任何不同的外部端點 NAT 對外使用的都不是同端口 (n1 != n2 && n2 != n3 && n1 != n3) 則該 NAT 的 External Port Mapping 行為是 address port dependent (與外部地址與端口都有關).

filtering.640x550.png

Filtering 指的是在不考慮封包掉了的情況下, 當一個位於內部的端口 (L:l) 對外部的一個端口 (X:x1) 發了封包, 外部不同端口 (X:x1, X:x2 and Y:y) 對 NAT 上 map 出來的端口 (N:n) 發封包時的過濾行為:

* 若內部端口都能收到任何外部端口所發的封包, 則 該 NAT 的 Filtering 行為是 endpoint independent.
* 若內部端口能收到外部同一個 IP 的另一個端口 (X:x2) 所發的封包, 則該 NAT 的 Filtering 行為是 address dependent.
* 若內部端口僅能收到外部同一個 IP 固定端口 (X:x1) 所發的封包, 則該 NAT 的 Filtering 行為是 address port dependent.

在所有 NAT 上, 這兩類行為都同時存在. 但組合起來時, 不是如直覺般產生九種組合 (3 X 3 的矩陣). 細想一下就會知道只能有六種組合:

* External Port Mapping 為 endpoint independent 時, Filtering 可為 endpoint independent, address dependent 或 address port dependent.
* External Port Mapping 為 address dependent 時, Filtering 可為 address dependent 或 address port dependent.
* External Port Mapping 為 address port dependent 時, Filtering 只能是 address port dependent.

繼續閱讀 NAT Traversal, part 2 – STUN.
COdE fr3@K » Blog Archive » NAT Traversal, part 2 – STUN
NAT Traversal, part 2 – STUN
Posted on October 1st, 2006 at 23:46 by fr3@K

續自 NAT Traversal, part 1 – NAT Behavior.

Intro

STUN 是個非常簡單的 protocol. 就只一種功能性的 request - Binding Request1. 可以先簡單想像為 ping, 不同之處在於 server 的 response 會將 client 發出 request 的 source ip:port 放在裡面回應.


當 client 收到 response, 從中得到 server 稍早 `看到’ request 的 source ip:port 可大略分為兩種狀況:

* 與 client 發出 request 封包的 ip:port 一樣, client 可藉由這種狀況發現自己擁有公網 ip.
* 與 client 發出 request 封包的 ip:port 不同, client 可藉由 response 知道發出 request 的私網 ip:port 被 NAT 被 map 成外部的那個端點. 這也正是這個 request 叫做 Binding Request 的原因.

絕大多數的 protocol, server 都會用收到 request 的 ip:port 來發出 response 以回應 client. STUN 特有一個很有趣的 attribute, 叫做 CHANGE-REQUEST. 用來要求 server 回應 client 的時候, 換一個 port (ip 不變) 或是換一個 ip 發送 response.

藉由把 STUN daemon 跑在一個 ip 的兩個 port 以及第二個 ip 上, client 就可以藉此了解它所處內網對外的 NAT 對 p2p 傳輸最具影響力的兩種行為; External Port Mapping 以及 Filtering.

External Port Mapping

Client 先用同一個 port 對 server 的兩個 ip (X:x1 and Y:y) 各發送一個 Binding Request, 如果兩個 response 顯示的 source ip:port 一樣 (N:n1 == N:n3), 則該 NAT 的 External Port Mapping 行為是 endpoint independent. 若不一樣, 就再對 server 在其中一個 ip 的第二個 port (X:x2) 發送一個 Binding Request, 如果這次的 response 回應的 source ip:port 與第一個 response 一樣 (N:n1 == N:n2), 該 NAT 的 External Port Mapping 行為是 address dependent. 否則為 address port dependent.

Filtering

等一段時間之後2, 接著 client 對 server 的一個 port (X:x1) 發送兩個 request, 其中第二個 request 要求 server 以不同 ip (Y:y) 回應. 如果 server 能收到第二個 request 的 response, 那表示該 NAT 的 Filtering 行為是 endpoint independent. 若收不到, 則再發一個 request, 要求 server 以同一個 ip 的另一個 port (X:x2) 回應, 如果這次收到了response, 這個 NAT 的 Filtering 就是 address dependent, 否則為 address port dependent.

External Port Mapping 與 Filtering 都是 endpoint independent 的 NAT 對 p2p 傳輸而言最為有利. 任何端點 (X:x1) 跟你通信之後, 可以直接把你 NAT 外部端點 (N:n1) 告知第三者, 第三者就能直接發送 (Y:y) 訊息給你. 只要 External Port Mapping 是 endpoint independent, 即使 Filtering 是 address port dependent, 也很容易克服, 跟你通訊的端點除了把你的外部端點告知第三者之外, 只要把第三者用來發送訊息的端點 (Y:y) 告訴你. 讓你能向那個端點發送個封包就能把 Filtering 的限制解除.

繼續閱讀 NAT Traversal, part 3 – TURN.

1. 實際上有兩種 request, 只是另一個 request 用途是認證, 與功能性無關. [↩]
2. 等一段時間的目的是讓 client 對外的 binding 超時, 否則第二輪測試完全無意義. 但要如何知道 binding 的超時為多少時間呢? 就留給你做功課吧. [↩]
COdE fr3@K » Blog Archive » NAT Traversal, part 3 – TURN
NAT Traversal, part 3 – TURN
Posted on April 14th, 2007 at 15:53 by fr3@K

續自 NAT Traversal, part 2 – STUN.

像是 MSN messenger 等的傳統 IM (Instant Message) 網路, 其 server 只負責少許的任務, 絕大部分的工作都是一個 client 節點與別的 client 節點之間的事情. 即便如此, 在這種網路之中, 每一個 client 還是從頭到尾都是與 server 溝通, 從來不會直接對另一個 client 收發訊息. Server 除了一開始對 client 認證, 後續除了 relay (轉發) 訊息與 data (例如檔案傳輸) 之外, 幾乎就沒別的任務. 對 service provider 來說, 這種架構可說是非常浪費網路資源. 每一個經過 server relay 的封包, 都代表對 service provider 頻寬與計算能力的損耗.


這種應用之所以會採用如上述對 service provider 的 core network 負擔較大的網路架構, 最主要是因為其 client 大都在 NAT 後面, client 與 client 之間無法有效建立直通的連線 (direct connectivity). 在這種網路架構之下, 由於沒有其他明顯缺點, 常會把 signal 通道與 data 通道 multiplex 在一個 connection 裡面.

若一個 application 把 signal 與 data 分開 (如 SIP + RTP), 就可以利用 TURN (STUN relay, formerly known as Traversal Using Relay NAT), 一種泛用 (generic) 的 relay protocol. 早期的 TURN 與 STUN 類似但稍微複雜的 protocol. 在 新版本的 STUN draft 中, 已經把 TURN 納入為 STUN 的一種 usage (可視為一種 extension). 說明了兩種 protocol 之間的血緣關係. 也是 protocol 作者 在發表早期 TURN draft 時, 表明希望可以大量利用 STUN 的基礎, 發揮到最大的一種表現.

TURN 的特點是 TURN client 必須知道對方 (external peer) 使用的 transport parameter (e.g. ip:port). 才能使 TURN server 開始 relay. 假設一個 client 透過某個 signal router 與 Media Server 交換 transport parameter. TURN client, TURN server 與 Media Server (此例的 external peer). 三者的網路架構與互動流程如下圖:

TURN Architecture/Flow

Click to ZOOM or open in a new window.

首先 TURN client 對 TURN server 以 Allocate Request 做 port allocation 的動作 (1~2). 得到了 TURN server 上 allocate 給 client 的 port 之後就可以開始與 Media Server 的 offer/answer (3~6). Offer/answer 完成後 client 會得到 Media Server 的 transport parameter, 然後再藉由 Set Active Destination Request 通知 TURN server 對方的 transport parameter (7~8). 之後 Media Server 發送到 TURN server 特定端口的封包 (9) 都會被 relay 到 TURN client (10).

TURN server 除了 relay 之外, 與 TURN client (建立 TURN session 的 client) 之間仍會用少數的 request/indication/response 溝通. 但對 external peer (另一邊的端點) 卻是 transparent. 換句話說, 對 external peer 來說, TURN server 上的某個特定端點的表現, 就如同是 TURN client 就跑在這個端點上. 即便如此, 一個在 TURN client, 在 NAT 後面的節點, 無法透過 TURN server 變成一個隨意接受第三方 message 的 server. 在 TURN client 還沒有經由 Send Indication 或 Set Active Destination Request 來把某個 external peer 加入 TURN session (on TURN server) 上的 permission list 之前, 這個 external peer 送到 TURN server 的封包都不會被 relay 回 TURN client (i.e. discard).

如果兩邊都使用 TURN, 則兩邊各自都是不同 TURN session 的 client, 與它們對應的 external peer 則是對方使用的 TURN server. 下圖中兩個 client 各自建立了一個 TURN session 來與對方溝通, 對於 Client A 在 TURN (server) A 建立的 session (Session A) 來說, Client A 是這個 session 的 client, TURN (server) B 是 external peer. 反之亦然:

turn-both.640.png

Click to ZOOM or open in a new windows.

這個例子還有個有趣的地方, 在 TURN A 到 Client A 與 TURN B 到 Client B 這兩段跑的是 TURN, 但在兩個 TURN server 中間跑的卻是原本的 data protocol (non-TURN’ed). TURN A 與 TURN B 都不會知道對方是個 TURN server, 它們只當 external peer 就跑在另一個 TURN server 的特定端口上.

TURN 支援在同一個 session 裡面同時對多個 external peer 溝通. 除了 active destination (preferred external peer) 之外, 與不同的 external peer 往來訊息時, 對方發給 TURN client 的封包會被包在 Data Indication 裡. 而 TURN client 則透過 Send Indication 來 encapsulate 發給非 active destination 的封包. 這兩種 indication 都包含了 REMOTE-ADDRESS 這個 attribute, 用以表示 external peer 的位址 (i.e. ip:port). 對 active destination 收發訊息時則不需要經過 encapsulation.

雖然單純採用 TURN 並沒有辦法降低對 core network 整體頻寬與計算能力的消耗, 但可以藉由把 signal routing 與 data relay 分佈在不同的 core network 節點, 達到分散 network I/O 與 computation 的效果.

預告: NAT Traversal, part 4 – ICE.

2009年10月10日 星期六

蔡子強﹕高錕校長的故事:大學就是包容
周二諾貝爾獎公布當晚,有記者採訪我,聽我說了上述故事後,問我,今天回想,會不會覺得我們這些學生當年錯怪了校長。我想了一想之後,答說:「20年後的今天,我想當年反對校長出任港事顧問的學生,仍然會堅信自己的觀點是對的,所不同的是,我們應從校長身上,學曉處理不同意見應有的態度。」

2009年10月1日 星期四

小企業的生存之道

小企业的生存之道 - 阮一峰的网络日志
这几天,我在读Seth Godin的《创业者圣经:有创意,无资金,如何起家》(The Bootstrapper's Bible,上海译文出版社,2000)。我读的是实体书,不过译言上有网友翻译的中译本。

这本书的第一章就谈了一个很重要的问题:在与大企业的竞争中,小企业怎么活下去?

表面上看,如果市场已经被大企业占领,小企业就根本没可能活下来。

原因有以下五点:

1)经销渠道。大企业的产品无处不在,广告铺天盖地。
2)融资渠道。大企业能够借到大笔资金。
3)名牌效应。消费者信任著名品牌。
4)客户关系。客户往往不信任新公司,更愿意与以前的合作方合作。
5)优秀雇员。大企业能够吸引优秀的人才。

因为上面这些原因,所以就算小企业有非常优秀的产品,也很难与大企业竞争。这就告诉我们,创业的时候,应该避开大企业的优势领域,而选择进行侧面竞争,也就是避其锋芒,攻其不备。

具体来说,是这样的:

1)经销渠道。尽量不要采用传统的经销渠道,更多地考虑与用户面对面地推销。
2)融资渠道。不选择需要大量资金的项目进行创业。
3)名牌效应。你的产品没有人家名气大,那就只好选择比人家便宜了。
4)客户关系。先做一笔小生意,与客户建立关系,或者直接把产品送给客户试,然后再慢慢蚕食大企业的客户。而且每次都以一个客户作为重点,开展销售工作,不分散力量。
5)优秀雇员。并非所有的雇员都追求公司的名气、稳定的工作和高报酬,事实上,很多人都喜欢带有冒险性的工作,喜欢有灵活的工作时间、关心下属的老板、认股权、方便的工作地点、没有官僚主义和复杂人际关系的工作环境,良好的发展机会等等。只要你能提供这些大企业无法提供的东西,你就能从他们手里争夺到优秀人才。

因此,只要你有一个好的产品(或服务),然后采取正确的策略,你就有机会在竞争中生存下来。

更有利的是,互联网时代的到来,使得小企业的生存环境进一步改善。

a. 小企业大多选择服务业创业,服务业的规模效应不显著,互联网加强了这种趋势。
b. 在新技术的帮助下,小企业能达到与大企业一样的高效率。
c. 小企业机构简单,管理灵活,更适合向顾客提供个性化的产品/服务。

所以,总的来看,巨人并不是不可战胜的,大企业的优势其实也不是那么牢不可破。如果说20世纪是大公司和大集团的世纪,那么也许21世纪就是小企业和创业者的世纪。

OpenOffice.org的Cost Down哲學

OSS應用軟體電子報
OpenOffice.org的Cost Down哲學

上一期電子報提到,近年來有許多企業開始控制IT預算上的支出,以節省營運成本,所以紛紛考慮採用自由軟體的方案,筆者最近接到許多企業詢問的案例,莫不先以節省公司IT支出費用的出發點做為考量,做為導入OpenOffice.org的動機,整體來說,出發點是正確的,但是對於整體的考量似乎又不大完整,筆者有以下幾個觀點,讓各位讀者參考一下。


節省支出要看長期,而非一張訂單就決定

許多企業在導入OpenOffice.org的時候,都想看到立即的效益!舉個最常見的狀況來說,很多企業主認為OpenOffice.org是自由軟體,所以軟體授權費用等於「零」,結果都認為這樣可以幫公司省去許多費用,準備大刀闊斧一番,最後往往在執行的過程中就付出許多代價而多浪費了許多時間、人力的成本。

第二個狀況是聽完一場專業的OpenOffice.org導入簡報,結果發現竟然要額外花上一筆顧問咨詢的費用,經過「評估」之後,單純就費用而言,轉換OpenOffice.org的方案與升級Office的費用相去不遠,於是因為無法幫公司省到錢,所以結論是等到「下次」升級Office的時候再做一次評估,可是等到那個時候,重新的再評估一次,又浪費了一次時間,最後乾脆就重買一次License,而這樣的故事會不斷地上演…

沒錯!以上兩種狀況都會讓企業的整體營運費用減少,雖然短期之內就可以看到好的績效(可能是今年的軟體費用減少了,或是執行了有效的升級方案了),但以長期來看實際上是增加許多的成本的,通常筆者會建議企業可以用二年或是三年來檢視一次轉換的績效,尤其目前正是轉換的大好時機,愈早轉換至OpenOffice.org,企業所要付出的軟體成本將會愈低,如下圖所示:



愈早轉換至OO.o,軟體授權的成本將會愈低,而採用OO.o之後,企業人數將不會是軟體成本升高的主因,但若還是採用傳統商用的Office方案,卻會是愈來愈高。


可將轉換OpenOffice.org視為「投資」

初期導入OpenOffice.org所支付的成本可能是顧問導入咨詢的費用、人員初期使用不習慣所造成的時間成本,這些成本就算是轉換成新版的Office都可能會產生,但是若採用自由軟體的OpenOffice.org,就可省去未來的授權費用,另外在第二年之後的成本會趨於平緩,整體的平均成本也會遠低於商用Office的方案,長期而言,為公司能省下的費用是相當可觀的,如果像是零售業、製造業等低毛利的產業,省下來的費用甚至可以當成是賺到的呢。

自由軟體是新的軟體趨勢,所有的企業IT人員都必需了解如何應用自由軟體來為企業達到最大的效益,唯有長期關注、採取實際行動,將其視為投資,才能實際擁有IT的自主權。

提供OpenOffice.org商業服務的網站:http://www.openoffice.com.tw

OpenOffice.com.tw的噗浪連結:http://www.plurk.com/openoffic

電郵營銷小本萬利

電郵營銷小本萬利 - Yahoo! 新聞
電郵營銷小本萬利
(明報)2009年9月9日 星期三 05:05

【明報專訊】一封近乎「零成本」的電郵,憑著一點心思、創意,原來可以變成一盤千萬元的生意。雷克系統有限公司行政總裁郭正光(Francis),9年前研發出一套電郵營銷(eDM)系統,針對收件者的身分、喜好,發送「度身訂做」的宣傳電郵;這技術吸引了東亞銀行 、貿易發展局及Canon等機構及品牌光顧,每年營業額逾千萬元。

雷克去年更跳出香港,於廣州、上海 設分公司,「我希望能變成地區企業,不要做山寨廠」。

Francis於2000年與兩名朋友合資少於10萬元成立雷克,研發人工智能系統,在網站收集及分析使用者的行為數據,然後向收件者作購物推薦,例如在書店網站中你曾瀏覽某一作者的書,系統便會根據你的瀏覽紀錄,自動列出該作者其他書籍作推薦,「分析都幾準㗎!」Francis說。

針對用戶口味發宣傳電郵

一年後他們將產品推出市場惟適逢科技泡沫爆破,結果敗陣而回,「因為人們不相信『.com』,大家亦不敢上網購物」。

Francis曾與多間大公司合作,掙到經驗卻掙不到錢,於是一改策略,針對電郵研發新產品,因為美國 當年正立法針對濫發電郵,「立法並非要打壓,而是要規管,這令電郵營銷服務有需求」。利用已設計的人工智能系統,結合電郵營銷的概念,Francis在2003年成功開發一套個人電郵營銷系統,是全球首個同類系統。

「每個客人都喜歡買東西,但就不喜歡硬銷。」電郵營銷的概念,是針對客人喜好,透過為企業設計電子通訊(e-newsletter)收集數據後,分析各用戶喜好、興趣及習慣等,再發出針對其「口味」的電郵,吸引他們消費(見另稿),「最重要是全個過程自動化」。

「增值」兼營市場分析

以大客Global Sources為例,這套方案每月可針對20個活動發出通知電郵,每封電郵針對個別收件者會有不同內容,發送的電郵量數以萬計,最多可應付800個活動的電郵,「甚至再多一點,視乎客戶的要求和需要」。

市場上競爭對手崛起,一按eDM便能找到很多同類服務的公司,最便宜的數百元有交易。不過,Francis現在賣的不單是發電郵系統,更是一整套市場分析顧問服務,為客戶「增值」,視乎整個宣傳策略的規模,收費由數萬元至100萬元不等。現時他公司的研發、設計及顧問團隊共有40多人。

進軍廣州上海 1年收支平衡

內地每10人便有5.5人用電郵,Francis看準這龐大市場,去年進軍廣州及上海,1年便已收支平衡。他說未來會繼續研發系統,不止單向的電郵宣傳,而是要做到e-communication,「有交流,有反應,才是真正的好科技」。

明報記者 謝凱瑩

2009年6月28日 星期日

網站企劃與設計應該規避的幾個迷失

網站企劃與設計應該規避的幾個迷失…@三十而慄-网络、财经、法律、职场、全球化趋势
最近一個北京的朋友因為業務上擴增的需要,想把電子商務也導入他的公司來運作,但是因為過去沒有架設網站以及經營網站的經驗,因此透過MSN找我幫忙把企業的形象、業務項目採用比較恰當的表現方式,同時又能夠兼顧用戶體驗感受,讓他的網站一上線就有一種讓人驚艷的感覺,而這也讓我有感而發…

我想這篇文章是鎖定有心想要架設一個網站但不知如何著手的人,對網站規劃以及設計的要點做提醒,因為有許多由實體業務想要切入電子商務的虛擬世界時,正因為這些因素導致了大量用戶的流失,這點是非常可惜的,而這樣子的案例實際上層出不窮…

首先,我想要提到一個關鍵,每個用戶第一次進入某一個網站,他對於該網站的信任度以及耐心,比跟一個用戶走進一家實體的商店差許多,而且網站呈現上一個用戶面前,就只有一個十多英吋的畫面,很自然也無法像店面一樣,可以同時擺放很多東西供用戶選擇…

所以,建立一個網站之時應該認知到這些觀點,用戶(尤其是第一次拜訪的)不會給你太多的時間,如果你的網站在用戶的耐心範圍(我個人認為五秒至十秒左右)之內無法讓用戶瞭解你在做什麼,那很可能他以後都不會再訪,這代表你可能永遠喪失了一個用戶,而你所能做的就是在這個1024X768(最多人使用的解析度,當然也有其他的,比方1280X800之類的)的電腦螢幕中,讓用戶一目瞭然…

比方說,許多網站經常把客戶服務的MSN、QQ或者客服電話就用一個大大的模塊,擺設在網頁中最顯眼的位置,用戶一打開網頁,就第一個被這個客服的框框所吸引,這是好設計嗎?

或許網站經營者認為強調客服給人一種信賴感,但是當用戶還搞不清楚你的網站是什麼的時候,或許他會覺得,是不是客戶糾紛很多,所以把客服聯絡方式放在這個最容易看到的位置呢?我認為這不是好的設計,如果你想強調服務做得好,可以改用漂浮的icon,同時用戶可以選擇關閉…

那麼又有一些網站,在其首頁上面滿滿的都是他所提供給用戶的服務與商品,想給用戶一種我這裡內容很豐富的感受,這又會是一種好設計嗎?此時,或許應該站在用戶的角度思考,當用戶對你還不熟悉之時,過多的內容堆積著,只會造成他的負擔,用戶只會感覺到這裡很複雜,我應該找一個簡單明瞭的網站來使用,因而就離開了…

如同前述,網頁的大小尺寸有限,所以應該要把你的服務或者產品依據重要程度抓出來,比方說哪一個項目對你的營收貢獻最大,想辦法把他用較大的位置以及最美觀的設計呈現出來,相對次要的可以縮小,甚至是不放置在首頁上面,只是做一個內頁的導引,如此整體感才會大器,設計上必須把用戶當成一片白紙,不要同時塞太多東西給他們,這樣只會嚇跑用戶,而讓他們知道,你的網站的重點服務是什麼…

再者,請記住越直接越好,不要用繞彎的方式來呈現你的優勢,比方說,在這個網站,你所能取得的成本比其他人低多少,你所能獲得的服務比別人好在哪裡,並且用越簡短的語言以及設計來表達,過多的文字或圖片的形容,只會讓用戶失去耐心,別忘了這是一個快速化的年代,如果擔心表達不清楚,那麼也是善用引導的方式,讓用戶一個網頁接著一個網頁的閱讀下去,這種有步驟感的呈現,會減輕用戶內心的承受壓力…

這些都是網站設計在用戶體驗上的要點,在這些原則之下,把網站的企劃專案做出來,才不致因為前期規劃不當,而導致了一個沒有吸引力、沒有重點的網站誕生,關於網站企劃的其他概念,後續慢慢跟大家分享…

2009年6月26日 星期五

廣告電話黑名單

廣告電話黑名單<<更 新 日 期 : 2009-06-24>> - 手機綜合問題研集 - 香港討論區 Uwants.com:
http://www2.uwants.com/viewthread.php?tid=5876780
香港垃圾電話名單 2009 ( Trash_Tel_of_HK )
http://hk.myblog.yahoo.com/Trash-Tel/article?mid=5

2009年6月4日 星期四

採購財務處理準則 (參考用)

報價 Quotation
採購額>$3000 就應向多於一間公司報價
留意利益衝突, 需申報利益關係
留意報價單有期限(通常一個月)
有時採購最後決定權不在自身, 需交出報價單(並只能作出建議)予上司決定

單據處理--可接受之單據
不可混有私人購買的物資
避免使用信用咭,積分咭,八達通付款及累積積分
60日之內之單據
不可有塗污(i.e. 不可在單據作筆記)
不可有修改(除非有公司蓋印證明)
不可用兩種不同顏色的筆書寫
不可是白頭單
不可是影印本
單據抬頭不能為個人, 要是其代表之組織
若單據上文字容易褪色,請將有關單據即時影印

單據需有以後以下資料:
  • 公司名稱, 電話, 地址(有需要時,可以公司蓋印代替, 但不建議用於大額交易)
  • (最好有公司蓋印)
  • 購買日期(年,月,日)
  • 購買物品(名稱,數量,單價)(不能概括描述物品)
  • 購買總額
  • cash memo, receipt, 正單, 現沽單等(不能為invoice, 發票或發貨單)
ref:
救世軍之迎新營財務及尋求贊助須知 講座, organized by OSA, CUHK

others:
單據處理樣式

2009年6月2日 星期二

五步評估委外

ZDNet Taiwan - 企業應用 - 專題報導 - [評估篇]不可錯過的5大委外評估撇委外
一. 委外重要但非核心的業務
二. 確定自己有能力執行欲委外的工作
三. 委外廠商一定要有實戰經驗
四. 確認委外廠商的專業能力
五. 順利完成概念性驗證
如何在PHP下载文件名中解决乱码 - PHP技术文档 - PHP5研究室
经过试验,发现几种主流浏览器的支持情况如下:
IE6
attachment; filename=""
FF3
attachment; filename="UTF-8文件名"
attachment; filename*="utf8''"
O9
attachment; filename="UTF-8文件名"
Safari3(Win)
貌似不支持?上述方法都不行

英文字型

小薑雜談:淺論英文字型
每個字型都有五條線...
為什麼說這五條線決定字型的性格呢?通常 x-height 佔 point size 比例愈高的字型,放在內文裡的時候看得比較清楚,但放在標題就很難看。反之,x-height 佔 point size 比例小的字,就比較適合當標題。以下面這個例子,小薑找了兩種類似的字型,但左邊是設計來當標題用的(Garamond),而右邊則是做內文用的 (Times New Roman)。注意到 x-height 的分別了嗎?
小薑談字型:英文字型的大分類(上)
Serif(Roman)
什麼是襯線呢?襯線就是在字母筆畫末端的小橫線,最早是在石刻文字時候,在線條尾端用鑿子敲一下,讓筆畫末端齊整所留下來的,後來漸漸發展成了這種字型的特色。Serif 字型從此成為了西方印刷的最主要支柱,直至今日。

小薑談字型:英文字型的大分類(下)
Slab Serif
Slab Serif 是襯線文字的一種(襯線是指拉丁字型中線條尾端的裝飾性線條),特色是粗細筆畫間的差異很小或是等粗,而且襯線非常粗,差不多和字母本身的筆畫一樣。
Slab Serif 原本只是一時的流行而已,因為以印刷來說,Slab Serif 太粗,不適合做內文,而以做標題的用途來說,不久之後又被更有視覺衝擊性的 Sans Serif 所取代

Sans Serif
之前談的都是 Serif(襯線字),而在 Serif 前面掛上個 Sans(法文,無的意思),就成了「無襯線字」也就是筆畫簡單,沒有尾巴裝飾的字型。
要等到二次大戰後,隨著「簡單就是美」的概念大行其道,本來被嫌沒特色的 Sans-Serif 字型才突然成為了當代字型的主流。

一般來說,襯線字適用在印出來的文件、報告,因為它比較不佔空間(除非你是故意要選個佔空間的字型 =
=),而且在字體小的時候可讀性比較高。在電腦上顯示時,例如投影片或是網頁,則推薦使用非襯線字,因為電腦的解析度太低,字小的時候襯線和比較細的筆畫
容易模糊,不若非襯線字那樣清楚。

以上,就是英文字型的五大分類 Blackletter、Serif、Slab Serif、Sans-Serif 和 Script。

2009年6月1日 星期一

Methods GET and POST in HTML forms - what's the difference?
The HTML specifications technically define the difference between "GET" and "POST" so that former means that form data is to be encoded (by a browser) into a URL while the latter means that the form data is to appear within a message body. But the specifications also give the usage recommendation that the "GET" method should be used when the form processing is "idempotent", and in those cases only. As a simplification, we might say that "GET" is basically for just getting (retrieving) data whereas "POST" may involve anything, like storing or updating data, or ordering a product, or sending E-mail.

2009年5月31日 星期日

山寨手機的故事

商業周刊-經營管理-1000大企業-聯發科》用敵人1/10資源,吃下逾4成中國市場
想像一下,有博、碩士學歷、身價上千萬的聯發科工程師,設計手機晶片的多媒體功能時,他們居然要去了解,滿手泥巴的農夫彎腰耕種時,如何才能聽到放在田埂上的手機鈴聲。他們甚至要了解中國的學校分布狀況,因為客戶希望讓晶片整合GPS衛星導航的功能更聰明,是專門給小孩使用的手機,可以在當小孩到學校的時候,就自動傳簡訊給父母。

從農夫到小孩,這些以往被忽略的族群,過去,並不會有人特別注意到他們,但若有一天,有人找到啟動他們需求的樞紐,一場鋪天蓋地的革命將就此展開。聯發科,就是揮著這面大旗的大贏家。

這,是一場螞蟻與大樹的戰爭!

2009年5月29日 星期五

重新建造輪子

程式者的胡言亂語 : 程式者的胡言亂語
重新建造輪子

「重新建造輪子」是軟體開發領域很常被使用到的一個用語,它是許多程式員很常見的一種迷思,有時候,它甚至是可以說是一種心病。我們時常拿建造一個車子的過程來比喻開發軟體的過程。在這個比喻裡,車子是我們最終想要完成的系統本身,而輪子便是建造車子所需的重要零組件。在軟體開發領域裡,建造系統的重要軟體組件,便時常被比喻為輪子。而重新建造輪子,自然意指著重新開發系統所需的軟體組件。

為什麼說,重新建造輪子甚至是許多程式員的心病呢?這是因為許多程式員無法抵擋心中那個呼喚他們、引誘他們重新打造輪子的魔鬼。為什麼要把重新建造輪子這樣子的活動,說的好像是十分邪惡的一件事情一樣?

無庸置疑的,軟體開發的生產力,絕對是現代軟體開發最看重的指標之一,也是許多軟體開發所追求的重要目標。我們在軟體開發上,除了品質的確保之外,加速軟體開發的進程,同樣也是我們所會面臨到的最大挑戰。許多軟體專案的開發延遲,造成產品或服務推出市場的時間失去先機,甚至遲遲無法完成,多半都歸因於開發生產力的不彰。因此,許多開發流程的導入、軟體設計的技巧及方法,都著眼於生產力的提昇。

而輪子的重新建造,意謂著的便是很大的生產力浪費。原本已經存在的軟體組件,在過去肯定花費不少時間於需求的分析、界面的設計、程式的撰寫、以及反覆的測試。而且軟體組件存在的目的,便是要讓多個開發專案所共同運用。這意謂著,每個軟體組件,都經歷了許多專案現實又殘酷的考驗才能夠生存下來。在這些現實又殘酷的考驗中,這些軟體組件等於是經歷了更為廣泛的實戰測試,存在於其中的軟體瑕疵,多半都已獲得修正。我們可以說,既存的軟體組件,多半都有一定可信賴的品質。重新建造輪子,背後代表的意義,往往是得重新再經歷相似的過程、投入資源及時間(通常佔去最多的並不是開發時間,而是最容易被忽略的測試時間),最後得到一個或許可能比較好的組件。但是這又如何呢?或許重新建造的組件的確優於舊有的組件,它可能更有彈性、更通用、適用範圍更廣、能被更多的專案重覆使用、滿足更為多變的需求,但或許在你未來的系統中,這些優點不見得會被完全的利用,兩相權衡下,不見得可以得到好處,但在當下卻是確切的把生產力給浪費掉了。

既然如此,為什麼程式員們總會受到心魔的引誘,一而再、再而三的將寶貴的開發生產力給浪費掉了呢?尤其我要說,愈是優秀、對自我期許高的程式員、愈是受不了這樣子的誘惑,反而愈是平庸的程式員,愈不容易發生重新建造輪子的問題。

這其中的原因究竟為何呢?不妨讓我細細道來。雖然許多人都說程式員這一行是吃青春飯,但我認為程式設計終究是一個大量倚重經驗以及視野的工作,而不像許多人心中所想像的,體力以及對新技術的熟悉佔去極大的比重。我相信許多程式員都會和我有一樣的感受,每經過一段時日,就會覺得自己又「昇級」了,基於這段日子的經驗積累,視野又大有所不同。而這些「昇級」的動力例如像是學習、體會到了某個設計方法論或是架構的好處。當你「昇級」了之後,再回過頭去檢視自己舊時的作品,反而多半都會抱持著負面的觀感。面對過去的自己,時常會有一種「年少無知」、甚至是「年少輕狂」的感覺,真希望「昨日種種譬如昨日死,今日種種譬如今日生」。剛對設計方法或架構有了更深一層感受的你,對比起來,更明白過去所做的設計,究竟存在那些問題以及缺陷,它可能不夠通用、不夠彈性、也難以擴充。倘若你是個自我期許較高的程式員,免不了難以壓抑心中的衝動,這些問題及缺陷,便有如眼中令人難受的沙子,非得立即除之而後快。所以,對於那些既存但卻又看不順眼的輪子們,會興起再次重新打造的念頭,也就不足為奇了。

可是,人總是持續的在成長,你的能力、視野同樣的隨著時間在不斷的進展,或許輪子的確不夠好,但在某個程度上,它總是足堪使用。但如果只是因為你知道有更好的設計方法或架構,就非得要重新再把這些輪子再做過,無疑的只是陷入無止盡的輪子再造地獄之中,也持續的浪費無所謂的生產力在上頭。你或許有所得,但失去的卻更多。

雖然重造輪子,會帶來生產力的浪費,但這也不完全意謂著我們永遠不會重新改寫既有的軟體組件。有些人剛好和喜歡重造輪子的人形成對比,他們總是不喜歡更動舊有的程式碼(通常稱為legacy code),因為他們深怕更動了舊有的程式碼後,引發副作用。當然,他們更不喜歡改寫既有的軟體組件,因為他們相信「做對的事,何必再改變」。何況,重新改寫更是一件浪費生產力的事情。

但是,這種堅持不重新設計所用軟體組件的想法,卻會引發另一個問題,也就是舊有的組件因為設計可能較為不良的關係,先天缺乏通用性的體質就無法因應新的需要,但你又不願意加以重新設計。這使得你得採取繞路的方式,迂迴的達成目的,把額外的地方加諸在其他的組件或甚至是你的應用系統之上,最後就是疊床架屋,持續的在不穩固的基礎上,繼續的加蓋違章建築。而這種情境,在我們日常的開發生活中,其實也是屢見不鮮、時有所聞。

上述的這兩種立場,看起來就像是在天平的兩端、互相衝突,一邊的優點正好是另一的缺點。這或許令人感到困惑,究竟什麼樣的態度才是正確的態度呢?

我常說,軟體設計之道就是取捨之道,也就是說,不論做什麼設計決策,你都會得到某些東西,但也同時會失去某些東西。而這中間的取捨,端視你所位在的情境以及所面對的目標而定。我們形同要找到一個合適的支點去支撐這有著兩個極端的天平,並且使之平衡。太過頻繁的重新建造輪子固然不對,但總不能在輪子的胎紋都磨平了,還勉強裝上車子並且行車上路吧?這中間存在一個適當的平衡點,而好的設計者,便會考量相關的背景因素,決定這平衡點究竟要設定在那一個位置之上。

對應到建造輪子的問題上,決定了一個好的平衡點,你就不會太過頻繁不斷建造輪子,但也不會總是使用同樣的輪子,你會決定適當的更新週期來汰換不合時宜的輪子,同時滿足新的需要。你在生產力和其他像是通用性之類的指標之間取得了一個好的平衡。

怎麼決定支點在何處,是一門藝術,也是判斷設計者功力高下的所在。

2009年5月22日 星期五

明報新聞網-港聞-港聞--歇後語難翻譯 法官也投降-20090521
歇後語難翻譯 法官也投降

【明報專訊】嚴肅法庭內昨午卻笑聲不絕,全因法官、大律師及傳譯員,都疲於為梁錦濠證供中各式各樣的古怪字詞作雙語翻譯,不少廣東歇後語或俗語被翻譯成英語後即令人忍俊不禁,短短30分鐘內語言文化「短兵相接」,庭內眾人「墨水」可見一斑。

「米已成飯」直譯惹笑話

昨午梁錦濠先指陳振聰「馬後炮」,傳譯員將此翻譯作「comment in hindsight」,資深大律師張健利先「出手」,認為是「retrospective comment」,此時法官林文瀚亦加入「戰團」,提出混入拉丁字首、意為「事後合理化」的ex post facto rationalization更見適合,一下子法庭變成語文切磋場地。

豈料,梁再指入獄一事「米已成飯」,傳譯員譯為「rice fully cooked」時,全場外籍人士一臉疑團,但其他人就捧腹大笑,歇後語盡顯文化差異。由英國來港的御用大律師Ian Mill雖未能意會,似乎亦感受到氣氛,即使出英式俚語,問梁錦濠「Don't you think Tony Chan led you up the garden path?」,意指陳誤導他。

但梁錦濠的港式「笑話」並未就此完結,他指再次相信陳振聰辦保釋的心情,猶如「生仔姑娘醉酒佬」,今次在場人士對此話何解知者寥寥,法官即向Ian Mill表明愛莫能助:「In this case I can't help you.」林官幽默再次引來笑聲,傳譯員亦只能從梁口中領略真正意思,原來是指「唔要又要」,對事件感後悔,但又要做。

2009年5月1日 星期五

「資料保全銀行」異地備份服務 = 分散風險的根本作法

在經濟前景混沌不明的當下,企業縮衣節食,IT預算被迫刪減,當 系統運作一切正常時,設備能多拖一年算一年。但是,企業的內憂外患並不會因為大環境情勢的不景氣而減少,系統老舊無法更新是內憂,駭客攻擊等外患亦不曾減 少,甚至只會更加頻繁。例如:桃園國際機場的移民署境管電腦系統大當機,一當就是36個小時。究其原因,矛頭紛紛指向境管電腦系統老舊。另一個案例為知名 親子網站Babyhome遭受DDoS攻擊,其網站也因此被迫關閉1天,對於營運勢必造成衝擊,也使企業商譽受損。

異地備份=分散風險
俗話說「雞蛋不要放在同1個籃子裡」,因為「覆巢之下無完卵」,這2句話就簡單的說明了,這個分散風險的基本原則,同樣也適用於電腦的資料保護。

現在的人會把貴重物品放在銀行保險箱、錢存銀行、把個人資料交給戶政機關,好像都是天經地義的事情。但對於電腦中由您自己一手建立的檔案,無論它們 是文件檔案、電郵訊息、照片、音樂、影片還是遊戲記錄,您都會想要保存它們。當然,請不要忘記將您已儲存的東西再複製一份到外置式儲存裝置。切記:電腦的 硬體價值再高,也不會高過你硬碟裡檔案的價值。

資安措施是協助您控制風險並幫您節省金錢。異地備份本來就是不怕一萬,只怕萬一的狀況,就像為企業資料買保險,保險的用途是在發生狀況時,有買就有保佑,「你不一定用得到,但買了總是多一分保障」。

「資料保全銀行」專業備份服務,無建置時差、省人力、省成本

有限付出、無限保障
使用「資料保全銀行」實際上可以降低備份成本,因為它能為您節省大量傳統備份的開支,如磁帶、磁帶清潔工具等等。而且「資料保全銀行」採用先進的重覆資料刪除技術,同樣的資料不會重覆備份,可大大節省儲存空間。

安全可靠 萬無一失
有別於傳統備份方法,使用「資料保全銀行」,您重要的業務數據將以128位元加密及壓縮,然後通過SSL管道上傳到遠端伺服器中,這技術與跨國銀行所用的技術相同,保證萬無一失。加上整個備份過程無需人手操作,消除人為錯誤的可能性,絕對安全可靠,值得信賴。

畫面簡潔 簡單易用
「資料保全銀行」的安裝精靈提供了清晰的步驟說明,安裝方面絕對沒有難度,軟體一經設定後便自動運作。此外,只需一下按鈕便能進行還原,非常容易。辦公室員工無需擁有專門的知識或預先接受培訓,任何具備基本電腦知識的員工均能輕鬆地操作和使用。

自動備份 主動回報
「資料保全銀行」會透過Internet及電子郵件,隨時為用戶提供詳盡的備份報告,使其在專注於本業工作的同時,亦能掌握資料備份狀況。

現在只要花一分鐘,上網填寫資料保全銀行-資料銀行保險箱客戶 使用申請表,就可免費體驗“資料保全銀行-遠端備份服務”。資享科技官方網站:www.estorage-isb.com,或服務專線02-26591858#300查詢。

2009年4月19日 星期日

Gmail backup MX

AntiSpam: Gmail backup MX
Gmail backup MX

剛在一個網頁寄存商的網頁看到一個叫 「電郵SOS」的服務。介紹如下:


電郵伺服器故障引致重要電郵遺失足以令公司損失大生意,要確保電郵傳送萬無一失,就要先防患於未然。UXXXXX 之「電郵SOS」會於現有電郵伺服器遇到問題時,將電郵暫時送到一個後備儲存伺服器裏,待你的伺服器恢復正常後,暫存在UXXXXX 的郵件便會自動派回 你原來的伺服器,保證電郵不會因伺服器的問題而流失。

客戶現只需$10元(每個電郵地址),便可保障貴公司的電郵商貿往來暢通無阻。


很明顯, 這是一個 backup mx 的服務。

有一個免費的 backup mx 方法是可以用:

1. 替你的 domain 申請一個 Google Apps 的 standard edition 戶口。

2. 替每一個 email address 都加一個戶口 (這是最花時間的,有一些 bulk add gapps account 的方法可用,可以上網找找)

3. 在 DNS MX Record 裏,最少的 preference number (eg 0) 仍然指向公司的 email server。

4. Backup MX 的 preference number則填上 Gmail 提供的。


理論上,只要公司的 email server 不 down,它仍然會收取所有入來的電郵。但總有時候某些 emails 會去了 Gmail Apps 戶口。這只需要:

5. 在公司的 email server 寫上一條 fetchmail 的 rule,寫入所有 Gmail Apps 的 pop3戶口,密碼,然後派送有關郵件到適當郵箱。

淺談技術寫作

蔡學鏞【言程序】部落格: 淺談技術寫作
淺談技術寫作

我在「超完美工作」一文中,提到「技術寫作」一詞,有資訊系的學生來信詢問如何進行技術寫作。收到此郵件,我覺得很高興!因為大多數的IT技術人員都不肯碰技術寫作,要他們寫程式沒問題,要他們寫技術文件簡直要他們的命。所以有人想主動學習技術寫作,難能可貴。

在國內,技術寫作一直是被忽略的主題,我認為,即使是在IT技術書籍作家中,具有技術寫作技巧者的比例還是不高。相反地,國外的IT大公司其實相當重視技術寫作,有時候會公布「Technical Writer」的職缺,這就是專職技術寫作的工作。

技術寫作的幾個基本要求是:

1. 很快學會新的技術
2. 能和技術人員溝通,主動挖掘技術重點
3. 具有流暢且精準的文字表達能力

除此之外,根據所寫的技術文件不同,技術寫作的方式也會有差異,例如:「技術白皮書」、「使用手冊」、「參考手冊」、「快速入門」、「自學手冊」…這些文件的寫作手法、範疇、與編排都是不同的。有些時候,技術寫作所生產的文件,不是最終文件,而是做為行銷等部門的素材,進行二次加工。

如果你有心學習技術寫作,我建議你去看相關的書。在http://www.amazon.com/上面搜尋「Technical Writing」,你可以找到許多本書。或許國內出版社應該引進一兩本翻譯成中文。

2009年4月12日 星期日

愛情紀實

由人地Xanga抄出黎...希望當事人唔介意,我覺得佢真係寫得好好,真係好通透

--------------------------------------------------------------------------------

我擁有過好幾段愛情,
曾經愛與被愛,曾經陷入苦戀;
曾經遇過第三者,曾經為報復一腳踏兩船;
曾經跟大自己差不多十年的男人同居;
也曾經,不小心當上第三者。

戀愛經驗愈多,
就把愛情看得愈通透。

如果,
一個人說愛你也愛別人,那是謊話,
他只是享受當萬人迷的感覺;
當你真正愛一個人,
你根本沒可能分心給第三者。

如果,
一個人老是說他很忙,
忙得沒時間見面,一個電話也沒有打給你;
那他一定不夠愛你,
如果一個人真的愛上另一個人,
再忙再累,也一定會願意抽時間給你。

如果,
你因為自己的異性好友有了男/女友而呷醋,
別誤會是愛上對方而不自覺;
說穿了,你只是覺得對方被他的戀人佔去了,
自己的地位沒有從前重要;
妒嫉,不等於是愛。

如果,
你覺得那個人很美,很英俊,很有型,很可愛,性格很好,
就認為自己愛上他,覺得對方是你的the one;
我可以告訴你,
欣賞對方的優點,那頂多算是喜歡而已,
即使你們在一起,也難以持久;
真正的愛,
是連他的缺點也清楚明白並包容。

如果,
你正陷入一段苦戀,對方待你很差,
你總是哭泣,希望對方能夠愛你多一點;
放手吧,信我,你總會找到更好,
因為,從前的我也試過。

如果,
你覺得一個男生很照顧你,
卻一直過了多年,只當你好友也沒跟你表白;
別再告訴別人他喜歡上你了,
因為這多是你自作多情居多。

如果,
你正跟一個人曖昧,
但對方一直沒有踏出第一步;
鼓起勇氣問對方對你的感覺吧!
失敗了也沒甚麼大不了,
最少,不用再浪費時間。

如果,
當初大家因性格不合分手,
別回頭了,
因為同樣的問題只會隔一段時間繼續發生。

如果,
你還不知道甚麼是真正的愛情,
不要緊,試多幾次,
當你遇到時你就會明白了。

當你遇到真正的愛情,
你會無時無刻感恩,
你會自覺跟對方心靈相通,你會欣賞對方各方面的才能,
喜歡他的孩子氣,喜歡你跟他打打鬧鬧;
即使看到對方的缺點,你也會包容,
因為你明白,人誰完美?
能夠遇上了自己心目中的絕配,
就已經是超級幸運了。

如果,你已經遇到了,
記得要好好的珍惜掌心中的幸福。

2009年4月9日 星期四

採用敏捷方法的軟體開發合約該怎麼簽?

{|ihower.idv.tw| blog } | 採用敏捷方法的軟體開發合約該怎麼簽?
一 般在台灣簽軟體開發合約,最常見的就是固定價格、固定規模型的合約(最晚何時要交出符合這些規格的軟體和文件),但是碰到的問題就是兩造雙方都覺得需求定 不清楚,而陷入對立的情形。接案的希望少做、出錢的希望多要一點,所以往往都在討價還價中試圖在期限中完成。如果實作後發現一開始的估計太保守、開發中途 客戶又不斷加規格、需求頻繁變更或是任何意外,往往就就會開始 Delay,一旦專案延遲,第一個犧牲的就是開發品質了,例如省掉測試作業等。變成開發範圍太大 -> 無法如此交貨必須加班 -> 品質降低的惡性循環。

但是要採用敏捷開發,這種合約要怎麼寫啊?敏捷開發不就說專案一開始不需對規格詳細內容做決定嗎?

XP 方法論提出四個互相影響的專案變數:成本、時間、品質、開發範圍。也就是如果定死價格、時間和範圍,品質就會變成可犧牲的變數。XP 派別認為這四個變數,最常、最應該可以變動的就是開發範圍,也就是定好價格、時程和品質,但是要做什麼再談。回到合約上看,也就定期限、定總價但不定規 格,例如 Kent Beck 建議的:『供應商將提供八個程式設計師為顧客服務,並且兩個月的金額是 $1,000,000。規模每兩週協商一次,協商時根據 XP 方法進行』。

但是不定規模對顧客而言最大的擔心,就是他想要知道他花了 $1,000,000 到底可以得到什麼,因此在台灣還很難接受這種合約方式,照 Kent Beck 的說法,只能玩成價格固定、交期不變、規模求個大概。例如我們和多就使用 User Story (註)的方式來定規模,保留與客戶溝通及實作的彈性,又有可以拿來估價的基準。雖然都會將專案時程切到至多三個月(一季)來做最大的估價範圍,不過還是會 有一開始低估規模而造成專案 delay 風險(所以加強專案的估計技巧也是個努力的方向)。

另一種在台灣常見合約的作法,是分成兩次簽約跟報價,第一次簽約預備開發期,目的是要完整討論出需求跟規格,這部份就會先收取一次費用。第二次簽的約才根據詳細規格再報一次總價。不過這種方式基本上就把敏捷開發一開始『規格不確定也無妨』的優點給犧牲掉了。

還有一種簽法就是計時合約(顧問費),花了多少時間就請多少款,但是基本上這跟固定價格、固定規模型的合約還是有一樣的利益矛盾問題:供應商為了多賺點錢,會希望多加人、多加班多報一點時數。客戶則想要在人力、時間盡可能少的情況下,做出盡可能多的功能。

各位接案的前輩們,你們是怎麼做的呢?

註:

User Story(使用者情節)是一段簡單的功能敘述,以客戶或使用者的觀點撰寫下有價值的功能(functionality/feature)。與其說它是規 格文件(documentation),不如說它代表(represent)客戶需求,因為實做細節將延後至開發時才會確定。

幾個 User Stories 的範例如下:

* 使用者可以在網站上張貼履歷
* 使用者可以搜尋有哪些工作
* 公司可以張貼新工作
* 使用者可以限制誰可以看到他的履歷

參考資料:

* 極致軟體製程 (Kent Beck)
* 規劃極致軟體製程 (Kent Beck)
* Extreme Programming 理論與實務 (Japen eXtreme Programming User’s Group)
* 同人的生活派對 » 合約與需求變更
* User Stories Applied (Cohn)

Hong Kong Post eCert

香港郵政根源證書已加入「微軟根源證書計劃」

香 港郵政的根源證書(包括 "Hongkong Post Root CA" 及 "Hongkong Post Root CA 1")已加入「微軟根源證書計劃」內;使各微軟視窗系統均可信任由香港郵政發出的電子證書。當 Windows XP 或 2003 系統須核實一電子證書(例:網站上的電子證書(伺服器))時,Windows系統會自行檢查香港郵政的根源證書是否已存在於系統內。如根源證書是不存在於 系統內,Windows系統會自行下載香港郵政的根源證書並將之存於瀏覽器內以供核實電子證書之用。使用Windows XP或 2003之前版本Windows 的用戶亦可下載附有香港郵政根源證書的有關系統更新組件。

按此參閱「微軟根源證書計劃」資料(英文版本)

Hongkong Post

Hongkong Post is a government agency and is a recognized CA under the law of Hong Kong Special Administrative Region (HKSAR) of China, and has been issuing digital certificates under the e_Cert brand name to individuals and organizations of HKSAR since January 2000. Hongkong Post CA operations have been outsourced to E-Mice Solutions. This is documented in the CPS and the Management Assertions. The WebTrust audit covers both Hongkong Post and E-Mice CA operations.

Audit: WebTrust, performed by PricewaterhouseCoopers: Audit Report and Management Assertions

Hongkong Post Root CA 1

InclusionMozilla Foundation to arrange for inclusion

This root has only one direct subordinate, Hongkong Post e-Cert CA 1, which is the signer key and is used to issue different types of recognized e-Certs to individuals and organizations.

Link Download/Install
SHA1D6:DA:A8:20:8D:09:D2:15:4D:24:B5:2F:CB:34:6E:B2:58:B2:8A:58
Version3
Modulus (key length)2048
Valid From2003-05-15
Valid To2023-05-15
RevocationCRL
TypeOV
DocumentCertificate Practice Statement for e-Certs
Requested Trust Bits
  • Websites
Bugs Authorisation (408949)
CommentsFile NSS bug after the CRL issues have all been resolved.

網路創業:如何挑選適合你的 Hosting Plan?

: 哈哈,換燈管的 CTO 跑去睡覺了... 來看這次的心情可以 post 多少東西...
: 網站還不大的作法 (跑 LAMP-like 的網站),依照成本由低至高有這些:
: * Shared Hosting
: * VPS
: * Cloud Hosting
: * Dedicated Hosting
: * Amazon EC2
: 我每個都把完整的產品、價錢、優缺點都說一次,下面的價錢沒有特別提就是
: 美金。
: ====
: Shared Hosting 一般都在 $10/month 以下,比較好的像是 Media Temple 是
: $20/month。如果你打算用 shared hosting 發展網站的原型,我的建議就是
: Media Temple 的 (gs) Grid-Service。
: 以 Media Temple 來說,優點當然就是價錢便宜,而且穩定性也高。通常網站
: downtime 都是因為自己改錯程式造成的...
: 缺點是彈性很少,你能用的就是 MySQL 與 PHP/Perl 之類的東西。另外在這種
: 環境下學不到系統管理,對網站長大並不是好事。

Agree。對網站長大並不是好事。而且也只適合在剛起步。
有些人對於架站其實一知半解,可能連 LAMP 都不太懂怎樣 setup。

又或者只是想針對某個議題架個論壇,自家小店鋪的簡單購物車。

通常一般比較不錯的 Shared Hosting,都會有著 CPanel 和 one-click install。
對於起步門檻真的很低。只要會 FTP 與簡單的 HTML 修改技巧就可以開站了。

Shared Hosting 也分國內外。一般國內的就:嗯嗯嗯....XD
國外的 MT 是比較好的選擇,不管 down time 和連線速度上都不錯就是了。

不過有些 Shared Hosting,無限頻寬/無限空間 都是噱頭說好玩的。
現實是,你只要用的資源稍微多一點警告信就來了。甚至還有叫你直接關站滾蛋的。

規模多大會叫你滾蛋呢?基本上頻寬和空間比較不會跟你計較。
是 CPU 用太兇或 request 數、檔案數(縮圖圖床)太多,比較會被趕走。

很多 blog 量大了以後(大約 7000-10000 pv/day)會搬走都是這種原因。
但是做小生意或一般小網站,要能達到這種量其實要一段時間。

一年新台幣花費大概是 3000-5000。通常是年繳。

: ====
: VPS 的價錢依照資源而異,我這邊會推薦的是 Linode,因為同樣價錢比起
: Slicehost 多了不少資源可以用。一般的人我會建議用 Linode 720,原因是
: 程式寫的不好時至少可以用錢換資源...
: VPS 的優點在於整個系統都是由你自己管,你可以自己選擇要用 apache 還是
: lighttpd、nginx,另外 mysql 與 php 都可以自己調整。這些經驗對於網站更
: 大時很重要。
: VPS 的缺點... 基本上我想不太出來有什麼大缺點 XDDD 在網站還不大時真的
: 很適合用。

跑 Rails 就不適合。因為加 Ram 規格就要調大 XD。
Rails 單包跑起來就要 30-50 mb,gem / plugin /mongrel 數量一多就 ...XD

不過 Linode 是可以單加買記憶體單加買 space 的。
Linode 比 Slicehost 規格好一點。但是 Linode 的連線速度不是很漂亮 ...。

VPS 跑 LAMP solution 就還蠻適合的。也可以在上面練連你想要的 solution 這樣。
一年花費大概是 8400。VPS 可月繳,低消大概是一個月 20 USD 左右。

: ====
: Cloud Hosting 的確是在這個位置,會比 Dedicated Hosting 便宜,我說的
: Cloud Hosting 是指 Mosso 的 Cloud Sites。這是一種 Shared Hosting 的
: 進化版本,簡單來說就是用很多台機器分給很多個站台用,比起 Shared
: Hosting 一台機器給很多人用好很多。
: 優缺點的部份跟 Shared Hosting 差不多,除了因為是一堆機器,所以「比較
: 不需要擔心」CPU resource 的部份 (照用量收費)。

就是懶人懶得 scale,程式給廠商,只要記得付錢就好的 solution。
看你用多少資源付多少。


: ====
: Dedicated Hosting 是整台實體機器都租給你用,通常會包含某個 quota 的頻
: 寬,你可以在上面跑自己用慣的 OS,像是 Debian。我個人與公司都租用過好
: 幾家,我都列出來:
: http://www.egihosting.com/
: http://www.hostgator.com/
: http://www.layeredtech.com/
: http://www.limestonenetworks.com/
: 這四個是到現在都還有在用的,服務都還算 okay。
: Dedicated Hosting 的優點就是整台機器都是你的,你租到多少資源就全部都
: 是你自己用。同時這也是上面所有所有方案裡,單位成本可以租到最多資源的
: 方法。
: 缺點在於機器通常不會有 RAID,你要自己想辦法保護資料。另外 Dedicated
: Hosting 需要的技術底子也比其他的深很多。
: 值得一提的是,WordPress.com 初期的機器都是用這種方法租用的。
: ====

自己管機器的意思。外國一些 Dedicated Hosting 對台灣連線速度都蠻漂亮的。
用租的省機器成本外,外國的頻寬比起台灣也是便宜的要命。

一些耗頻寬資源兇但是你不想餵豬(使用者)吃人參(國內頻寬)的服務可以看情況
導過去。

起步價一個月大概是一百多塊美金。

: Amazon EC2 其實是一種 VPS 的變型,他以「小時」計費,但我們這邊不提這
: 個部份。就小站台來說,這台機器 24 小時都開著,一個月也只要 $72。由於
: 一般小網站的流量其實很低,他所租到的資源媲美一台 Dedicated Hosting 主
: 機。
: 其實 Amazon EC2 好用的地方不是在成本 (事實上量大時會因為頻寬費用而使
: 得成本上升),而是在與 Amazon S3 的結合,不過這點是後面的事情...
: 主要的缺點是,你需要自己做 image,這點的技術門檻比其他的方案高很多,
: 因為幾乎沒有中文資料。

如果在外國的話,算蠻適合 startup。租 Dedicated Hosting 或買機器,
其實也要成本。

問題是,如果你不是常態性需要用這些機器,而是某些 event 需要用
(比如說已可預知的 TC 報導,或者是某些 conf 或 news 引爆的爆量)

你真的確定你要 租/買 機器下去嗎?

所以通常解法就是做 AMI,有 event 的時候就打開 deploy 上去
不需要的時候就關掉...

還有就是,某些 application 離尖峰時間的用戶數差的很多,用到的機器數也差很多。
這些都是錢啊。所以有人寫好了軟體出來賣,尖峰就一台台幫你打開 ec2 堆上去 ...
離峰一台一台關掉。很省錢 XD

( Facebook 上很多 application 這樣搞)

EC2 也有 99.95% 的 SLA,這點可以讓人比較放心。

但如果你要這樣玩得話。有一定的技術門檻就是了。

1. 你要會管機器
2. 你要能夠做你要用的 AMI
3. 你要想好架構能這樣亂玩
4. 你要做好資料的備份

簡單說,就是要用經驗和你的知識堆。

至於為什麼要用 S3,well 這邊算其他主題的內容,就不在這邊寫了。

ec2 的收費是照小時以及你開的 slice 大小收費。
http://aws.amazon.com/ec2/#pricing

======

我再多寫一個好了,Google App engine。
不過這個東西技術門檻是要你熟 python,熟 django / tt 佳。db 是用 big table。

每個月會有一部份的免費 quota。每日 5million request 以下的站都適合用。
超過另外 charge。
(不過最近大家濫用已經大大縮減免費的 quota 了)

如果你 python 夠熟,用 app engine 其實很適用。

每日 5m PV 的站大概........

一般人一輩子在台灣創業都很難有這量吧。
5m 應該就有台灣 alexa 前 20。

(剛翻了一下,剛出來是 免費 5m request,現在是 1.3m request)
http://code.google.com/intl/zh-TW/appengine/docs/quotas.html#Resources

2009年4月1日 星期三

急救情緒三大忌

蘋果日報 - 要聞港聞 - 20090401 - 情緒互動室:急救情緒三大忌
朋輩間的情緒分享,是重要支援,請學習聆聽和接納,避免落井下石、誤犯禁忌。人生中,總會遇到不同的生活轉變或危機,當身邊人情緒崩潰時,請小心,避免犯了「急救情緒三大忌」:

第一忌:壓抑情緒‧迴避感受

「唔好喊啦」、「冇事嘅」這些耳熟能詳的回應,但作為當事人,可能會感到不被認可,甚至認為對方只求盡快「擺平」自己的情緒。作為支持者,能平靜溫和地接納,輕輕遞上一張紙巾、一句「喊/講出嚟會舒服啲」已足夠。

第二忌:專家口吻‧引經據典

某女子因男友移情別戀,向好友哭訴,好友以專家口吻說:「早就叫你唔好信佢啦!」面對感情困擾,有些人會將「經典」道理全數搬出,卻忽略了對方個別情況和感受,當事人需要的是平和開放、陪伴找尋方向的聆聽者。

第三忌:質疑爭辯‧從己出發

朋友在工作上「含寃受辱」,有人會輕視事件嚴重性,大喊「我做嗰間都係咁啦!」又或作出「你搞清楚未呀?」等質問。如果你是當事人,不知道會否有「啞子吃黃連」的感覺?嘗試從朋友的角度出發,避免爭辯,用心傾聽,相信比雄辯滔滔更有建設性。


2009年3月22日 星期日

ITSC: Student Computer Assistants Recruitment

ITSC: Student Computer Assistants Recruitment

Post 11: Web Developer - Campus-wide E-mail System Upgrade Project (Infrastructure Division)

Job Description:

  • To assist in programming and testing of the Campus-wide E-mail Upgrade project
Essential Requirements:
  • Experience in PHP and MySQL Server is a must
  • Knowledge of programming in Redhat Linux environment
Preferrable Requirements:
  • Knowledge of web-based testing tool is a plus

Number of Vacancy : 1

Period of Service:

  • Jan 2008 - Jun 2008

Salary: HK$50/hour

Wikis Go Bad

When Wikis Go Bad | evolt.org
Where can a wiki go wrong?
  • Nonexistent or inappropriate content (old problem in Web 1.0)
  • Too much complexity ("enterprise" wiki system choosen)
  • Managing the wiki community (wiki moderator)
  • Corporate control (happen in author's company)


2009年3月13日 星期五

港女

拜物小姐戀物誌 » Blog Archive » 港女之誕生
我 在上一篇關於偶像神化幻滅的文章中利用呂大樂的世代論推斷三十代是一個被戰後嬰兒漠視的世代,所以他們需要造神,而二十世代(包括十多歲的人。世代論只是 一個籠斷的說法,並不是說二十至二十九歲的人必然屬於二十世代,代與代之間的界線其實非常模糊,沒可能一刀切)因為習慣了被父母師長打壓其個性,所以有意 追求平庸。其實這一種心態,亦可以用來解釋港女的拜金及拜物心態。
商業周刊-人物觀點-話題人物-宣明智,拿三百億搏九千億
這次,是台灣政府首次挾大筆資金,介入企業整併案。根據宣明智所述,台灣DRAM產業單製造就涉及二萬三千人的生計,銀行借貸資金高達九千億元,如今,這個 被形容為「豆芽菜」的無根產業,正面臨生存危機。台灣政府計畫投入新公司約一半、也就是近百億資金,成立TMC,希望替台灣DRAM產業找出生路。
若不成,百億元納稅錢,反可能被「紓困之狼」吃掉,台灣DRAM產業將連根拔起;若成,TMC一旦跟國外大廠移轉技術成功,台灣就有可能與韓國三星DRAM大廠,平起平坐,脫離總為人作嫁的命運。
商業周刊-國際話題-全球話題-世界向左走 新財富在哪裡
全球最大的經濟體正進行翻天覆地的改革,這場演講,就像未來世界的藏寶圖般,將主導未來十年世界財富的重新洗牌。
仔細分析,這份長達六千一百七十二字的演說中,清清楚楚預告了:未來的世界將向「左」走!
所謂的「左」,不是指地圖上的左方,而是代表左與右的政治光譜。通常,左,是指社會主義,主張計畫經濟,政府主導資源分配;右,是資本主義,主張市場自由,政府越小越美。

2009年3月10日 星期二

Content delivery network / Content distribution network (CDN) Introduction

CDN - 什麼是 CDN at Gea-Suan Lin’s BLOG
剛剛才發現 OSDC.TW 2009 有 50mins 的時間,先把一些資料整理出來,做投影片會比較方便。(大概會做 25mins 的投影片吧)

CDN (Content delivery network) 被稱為「內容傳遞網路」是一種內容快取機制,能提供高效能 (包括使用者以及內容提供者)、高可靠度、低成本的內容傳遞架構。不過,這幾個優點並不一定同時會發生。

以對使用者高效能這點,通常指的是「就近取得檔案」,內容提供者事先將檔案推到全球的 CDN 節點,在台灣的下載者儘量從台灣取得檔案,在日本或香港的下載者也儘量從當地的伺服器取得檔案。

由於在全球有多個節點,所以當某個節點不通時,可以導到次近的節點以達到高可靠度。

對 內容提供者高效能的部份,是因為內容提供者不需要在一個 data center 上建立非常粗的水管。舉例來說,如果傳遞需要 100Gbps 的流量,利用 CDN 架構,每個 data center 也許只需要 5Gbps 的流量。由於十個 10Gbps 網路與 100Gbps 網路的成熟度不同,成本也會不相同。

這是 CDN 的一些粗略的概念。
CDN - 為什麼要用 CDN at Gea-Suan Lin’s BLOG
用 CDN 最常見的兩個理由:

* 速度:下載者可以就近取得檔案。這對於小檔案 (css/javascript) 會有很大的幫助。(也許要解釋瀏覽器 HTTP 的運作,並抓一張 Firebug 的畫面分析?)
* 效率:因為下載者透過 CDN 下載,可以減少原始 server 的負荷。

另外還有其他的理由:

* 成本:這個留到會場講。
* 安全:以分散架構對抗 DDoS 攻擊。
CDN - 技術面 at Gea-Suan Lin’s BLOG
要決定使用者應該要到哪組 server 通常有這些方法:

* GeoDNS
* Anycast
* HTTP Redirect (會比較差)

這幾種不衝突,常見的是前兩者搭配著用。將 DNS server IP anycast,當下載者要抓某個 domain 時,近的 server 就會知道大致的區域。再配合 GeoDNS 判斷使用者的 IP address 適合到哪個 node。

不過這些問題對 HiNet 就很麻煩。(留到現場講)

再來就是 reverse proxy cache 所產生的問題,這個部份再想看看要怎麼寫。
CDN - 服務提供者 at Gea-Suan Lin’s BLOG
前三大 CDN 服務提供者:

* Akamai
* Limelight Networks
* CDNetworks

其中 PIXNET 用的 Panther Express 前陣子被 CDNetworks 收購。

另外,很熱門的:

* Amazon CloudFront

Amazon CloudFront 有公開的價錢,Akamai 與 Limelight 也有可以參考的價錢:(只是參考用)

* Distributed Cloud (Akamai)
* Mosso Cloud Files (Limelight Networks)

其中 Akamai 國內有代理商 (併力科技)。

另外還有一些可以參考 Wikipedia 上的表。
CDN - 要怎麼挑業者 at Gea-Suan Lin’s BLOG
要挑什麼 CDN 是依照需求而決定,我會談的是台灣的情況。

在台灣有「用戶」的 ISP 中,HiNet 與 TANet 的出國線路狀態是最差的,其他 ISP 的情況會好很多,所以測試的重點要放在這兩個 ISP。

以 影音來說,由於傳輸時間普遍會大於一秒,重點在於 bandwidth 而非 latency。所以到台灣抓與香港、日本,甚至到美國抓其實都 okay,只要 thoughtput 夠高就可以。以 1M 高畫質的影片換算,有穩定 150KB/sec 的速度其實就很順,如果是 600K 或是更低,有穩定的 100KB/sec 以上就 okay。

如果是 css/javascript,因為檔案很小,latency 就變得很重要。可以從台灣本地提供檔案通常是最好的 (<10ms),或是從日本、香港 (~20ms 到 30ms) 提供,如果 CDN 業者可以幫忙 gzip 會更好 (因為他們會處理 IE6 的一卡車問題)。 如果檔案是屬於下載性質,速度其實不是重點,重點在於成本的話,有些 CDN 業者有提供「經濟型網路」,通常是用北美較便宜的點提供下載。有一定的 commit 時會比 Amazon S3 的 USD$0.17/GB 便宜。 除此之外,會因為不同的性質,要考慮的還很多…

怎麼寫技術文件

網站製作學習誌 » [心得] 怎麼寫技術文件
[心得] 怎麼寫技術文件
  • 擬定大綱
  • 條列說明
  • 正確地引用與摘要
  • 適時加上圖片或範例
  • 將它讀出來
  • 說服自己
  • 用部落格來練習

2009年3月5日 星期四

網路是很脆弱滴 @ 小隔間裡的人生
Internet 的興起靠的是大家都能亂搞,但是最終把 Internet 搞爛也是因為大家都在亂搞。

今天看到一則有趣的新聞,講的是發生在幾天前的一次網路大爆炸事件;故事很長,有興趣的人請直接參考這篇和這篇 (後面的 comments 很重要,一定要看),不想看那麼多英文字的人可以參考我下面講的超精簡版 :p

故 事的起源是某捷克 ISP SuproNet 買了某拉脫維亞網路設備廠商 MikroTik 的 router,為了要設 backup 所以打算照 convention 在丟給 backup ISP 的 AS-PATH 上面把自己的 ASN 多設幾次,此時出現了第一個錯誤:系統要求使用者輸入 "重複次數" 的地方他輸入成自己的 ASN (47868);這本來其實也沒什麼,不過無巧不巧的是堵到第二個錯誤:MikroTik 的 router 說最大重複次數是 16,但是它沒檢查你輸入的值就直接拿去用了,在這裡它是用一個 U8 來存的,所以得到的值是 252 (= 47868 % 256);上面兩件事碰在一起,這其實也沒什麼,常常有人在設錯,只不過這次很衰的是又碰上第三個錯誤:Cisco router 也有 bug,在碰到長度超過 256 的 AS-PATH 時會 reset BGP connection,252 再加上本來就有的 4 個 ASN 就超過 256 然後觸發自爆指令,一時之間全球網路上沒有設定好的 border router 就一直送 BGP update,據統計約是每秒 10 萬次左右,這誰也頂不住啊 XD (以上看不懂的人請參考 RFC 4271。)

這些其實都是可以預防的。首先,第一個輸入錯誤基 本上可以藉由訓練和事先規劃來避免 (至少我之前還在種花的時候所看到的每次改接都需要事先提出改接計畫書、大規模改接前也有演練);再來,第二個錯誤早在先前的版本裡面就已經修掉了,會發 生這個錯誤顯然是因為沒換新版本;最後的第三個錯誤確實是 Cisco 的 bug (spec 並沒有規定 AS-PATH 不能超過 256 個…),但是如果網管人員有確實設定 bgp maxas-limit 的話也不會爆炸。只能說,這次實在是太帶賽了,剛好讓這些因素全部撞在一起… *boom*

從這個事件可以看得出來,其實網路是很脆弱的 (到底當初設計的時候說要能撐得過核彈攻擊是誰唬爛的 ? XD),隨便一個非網路核心的國家的一個 ISP 的一個小工程師打錯一個指令就能把它給毀了 XD 而且,這種事還不是第一次發生,去年也有過一次類似的事件 (這裡有中文簡介),但是規模小很多,只有毀了 YouTube 而已 :p 我們能做什麼呢 ? 其實沒辦法做什麼,只能好好祈禱下次不要那麼註死、要是不小心碰到了的話網管也要能快速排除 (在這兩次事件中網管的表現都還蠻不錯的,差不多兩三個小時就搞定了)。

PS. 有兩張圖很有趣,值得特別提出來。第一張是網路爆炸的災情圖,作者打趣地說這張圖某種程度上代表了 Cisco router 的佔有率 XD
都是活在補時階段 | Xanga Hong Kong
偶然看到日劇《人生補時》的簡介:將人生比喻成足球賽,講述某人臨死前在「補時階段」做些什麼。情節似乎很吸引,於是看了第一集。

主 角小春是一名出色的攝影記者,經常深入危險的地方拍獨家照片,為了拍照不惜罔顧自己甚至他人的安危。在一次跟蹤偷拍中,他被一名黑幫成員槍殺,生命的球証 給他四小時作為補時。他心有不甘,首先跑到現場,搜尋線索,企圖拍到最後一張獨家照片,可惜跟蹤人物已經逃走了。接著,他打電話給報社老總,要求委派另一 項任務,以求死前幹一件轟烈的事,但還是被安排偷拍某政治人物的桃色照片,這使他感到很沮喪。接著,他遇到一名快要分娩的孕婦,送她去醫院,還被誤認為爸 爸,不情願地給拉進手術室,看著孩子出生。他感到無聊極了,立即趕回報社,卻發現先前拼死拍攝的照片不能登上頭版,原因是他沒有珍惜生命,照片都沒有生命 力。他灰心極了,回家思索在最後兩小時可以作什麼。他想起和前女友百合子愉快的生活片段、想起他們辛苦儲錢買回來的第一部相機、想起他倆第一次拿著相機喜 奮地拍照、又想起百合子離開時的情景……

「你大概會愈來愈紅,你一個人也會成功。」這是百合子給他的最後一句話。

他決定找她,手上拿著二人買的老相機。

他走到她家門前,卻不敢按鈴,他致電給她,首先接聽電話的是一個小女孩。

「你的女兒嗎?」小春問。

「嗯!」突然收到他的來電,使百合子手足無措,整個人愣住了。

「你……結婚了嗎?」

「嗯……」

談了好一會兒,小春便掛線了。他走到一個公園,時間只剩下四十多分鐘。

「一般人通常會做些什麼?」他問球証,他們沒答理他。

遠處,一個婦人拖著一個小女孩到公園玩,仔細端詳,原來是百合子,小春連忙躲起來,用老相機給二人拍了一張照片。

過了一會,小女孩趁媽媽跟別人談話,走到小春身邊和他說話。細問之下,小春才發現原來女孩是他女兒,百合子並沒有結婚。小春把相機送給女孩,女孩脫掉色彩繽紛的膠珠手鏈送給小春。

最後,小春走到被槍殺的現場,他合上眼,回憶剛才的補時階段──他見證了一個嬰孩的誕生,想像自己的女兒出生時也是同一個模樣吧!他還可以跟女兒談話,為她母女二人拍照。他覺得實在有意義極了。於是快樂地死了。

我想,每個人心裡都藏著一個人物,假使下一刻喪命,必定毫不猶豫找他/她,跟他/她告白。可是,誰能掌握自己何時死去?誰又曉得自己不是活在「補時階段」?何解猶豫不決?何苦遲疑?

2009年2月24日 星期二

Web System source code 加密

大家好, 希望能幫我解決這個疑惑, 事情是這樣子的:

我請A公司幫我做網頁設計, 她傳了報價單來, 我回簽後開始執行. (報價單底下有寫 網站架構設計等等為A公司智慧財產, 和A公司詢問後確認他們指的是我不能販賣此網站和其設計. 因為網頁的架構, 功能, 美工的設計都是由我自行提供的所以我針對那個條文特別確認了)

網站設計完成後付了尾款, 發現A公司把所有頁面原始檔加密 (ZEND), 因為我長期住國外對國內的網站設計行為不了解, 不知是否國內所有設計公司都這樣做? 我求證過國外設計公司或甚至個人設計師都不這麼做, 況且A公司所用的網站架構是4年前的OSCOMMERCE, 再因應我的要求做一些修改的, 根本不是什麼專利的設計 (一般購物車系統 + 很陽春的雜誌形態的發文功能 + 後台). 購買前的溝通我曾向A公司提過我有製做網頁的能力, 所以日後必須能夠自行更改網頁. 但購買後卻發現所有網頁皆編譯, 導致我無法閱讀且無法更改網站原始檔.

我詢問A公司後,A公司的答覆是說: 網站是A公司設計的所以必須加密以保護他們的智慧財產權. 但事實是A公司僅依照我向他提供的功能需求及設計來製做功能 (很多功能都是免費可以下載到的SCRIPT, 或是修改一些DATABASE語法罷了). 在經過回絕後, 我曾提出要求是否能僅將有智慧財產的網頁部分加密, 其他的部分解密, 但A公司做不到, 反而要我出網站原價一倍以上的價格來購買原始檔案 (A公司並且說明他平常都是要求3倍價錢). 此加密的行為導致將來大部份的功能及架構設計修改, 後續網站行銷, 優化,等都需經由A公司來執行, 變相的瑣死我以後選擇設計廠商的權利. A公司甚至變相的強迫我幫他們公司行銷, 他在所有網頁的原始檔, 及網站公司版權說明的明顯處都加上了他們公司的網頁, EMAIL, 或公司名字. 我曾要求把他們公司的名字由網頁中移除, 但他們不肯.

另外, A公司也說如果我把網站架在他們的SERVER上 (比戰XX策貴1倍以上, 速度又慢, 不穩), 他們還可以考慮不加密. 請問, 國內的網站設計公司都是這樣子嗎? 我的朋友都說我被RIP-OFF了. 早知道就找FREELANCE的, 反正和A公司合作也花了我足足4個月的溝通及更正他們的錯誤, DEBUG..

發此文是因沒有申訴管道 (消基會不受理), 且不想走法律途徑, 我希望能先了解國內這類行為是被接受的嗎? 還是說因國內無相關法律所以消費者 (或公司) 只能默默接受並負擔比國外高額 (服務又不一定較好) 的費用?

------------------------------------------------
小弟之前在台灣時也是SOHO族, 之前也有用過類似的原始碼加密軟體, 因為加密的檔案通常可以設定一些使用限制,
接案子的常常怕給了原始碼之後, 收不到尾款, 所以用加密軟體做限制, 收到尾款後再把限制完全解除

至於保護智慧財產權一說, 因為大多數的程式設計師都會有自己的code library可以重複使用, 所以一個案子從頭寫過也許要3個月, 但套用自己設計的module/class 之後也許只要1個月就可以完工, 通常不希望這部分的模組可以讓別人直接拿去使用

還有一個問題就是, 發案方有些會自行修改原始檔, 但改出問題後會說是本來就有的bug, 要保固
這種要debug就像海底撈針一樣

所以我個人的方式是, 先將原始碼加密, 防止有意或無意的修改後造成的bug, 若對方要求須要原始碼解密
我會把自己模組的內容加密, 但主程式解密對方可以修改, 也可以直接調用模組裡的功能, 就是有API就對了
同時告知對方, "自行修改造成"的bug就不負責免費修復, 而通常結案前會測試一段時間, 確定都ok才結案


不過針對原發文的大大所講的

OSCOMMERCE, 再因應我的要求做一些修改的, 根本不是什麼專利的設計 (一般購物車系統 + 很陽春的雜誌形態的發文功能 + 後台).

如果是現成的套裝軟體是不應該加密的, 更何況大多這種軟體都有開放原始碼的規定

他在所有網頁的原始檔, 及網站公司版權說明的明顯處都加上了他們公司的網頁, EMAIL, 或公司名字. 我曾要求把他們公司的名字由網頁中移除, 但他們不肯.

通常版權歸屬於發案方, 但是會在介面上顯示 Copyright A公司 powered by B公司之類的, 但如果發案方要求移除, 也是應該要移除的

A公司也說如果我把網站架在他們的SERVER上 (比戰XX策貴1倍以上, 速度又慢, 不穩), 他們還可以考慮不加密

因為放在他們主機上又不提供FTP的話, 您就抓不到原始檔, 所以就乾脆不鎖啦, 不過要求付費解密或是強迫租用主機就真的太黑了

大大跟小弟一樣長期住國外, 因為小弟之前回台灣待過一段時間, 所以見識到台灣外包市場的恐怖一面
發案方價錢壓很低, 因為不怕沒人做, 接案的人太多, 惡性競爭, 導致品質下降
發案方怕付了訂金對方人跑了, 接案方怕做的半死收不到尾款

------------------------------------------------
這要看合約怎麼簽,以小弟公司為例,我們在報價之前,都會跟客戶說清楚,一般分為4類
1.不交付 source
2. 交付 source code,不包括技術轉移
3. 交付 source code,包括技術轉移 ,但是不放棄人格權
4. 交付 source code ,包括技術轉移,放棄人格權

至於智慧財產權通常依據承攬合約屬於定作人的。也就是定作人可以自行散佈使用。
人格權則是可以主張原作者是誰。有些客戶不願讓人知道是誰做的,會要求我們放棄人格權。

不過以上是指量身訂作的,如果是客製化的,就要原始系統的授權而也所不同。

例如套裝軟體,授權一套裝軟體為主。
open source,則以上的授權僅及於客製的部分。


------------------------------------------------
這要分成幾個不同的事件來看。

1. 你今天沒有跟他們簽專屬授權(就像他們說的,價錢差三倍),同時也沒有特別說明要原始碼,所以他們把程式碼加密是很合理的。PHP 雖然說是 inline code 形式,但是也有很多的 template engine 可用。你要改網站樣貌,也不一定需要改動到 PHP 程式碼。所以說『Zend 加密』和『能否修改網頁版面』這兩件事情並沒有因果關係。

2. OScommerce 是 GPL,A 公司將這個套裝框架加密交付給你,這就是違反了 OScommerce 的授權原則。你可以提出抗議,但是基本上我不認為 A 公司會理你。因為這是 OScommerce 的製作團隊可以提出告訴,而不是你。而且近年來 OSF 在國內外都有過不少類似的訴訟案例,告贏 A 公司的機率不大。

3. A 公司把他們的商標放在網頁上,這樣的設計你不滿意,又發現你無法修改;那請問你在驗收的時候有提出這一點希望他們修改嗎?由於你們當初沒有簽訂合約,同時 也沒有制定驗收準則,所以你就是被他們吃定了。像這種事情基本上不屬於消費者保護的範圍,而是最基本的民法問題。民法雖然沒有規範合約的形式(雙方合意者 即為契約),但是像這種狀況,雙方口說無憑,法院也很難審理。

今天 A 公司的行為是很惡劣沒錯,但是你自己沒有作好保護自己權益的動作,在法律上你自己也站不住腳。

你現在可以做兩個動作:

1. 去法院問看看能不能調解。這和消費者保護無關,別搞錯衙門。我猜想比較可能的是雙方各退一步,他們給你個折扣年費讓你把網站放他們伺服器,然後給你原始碼。

2. 開始找 Freelancer。給他看你現在的網站樣板,問做一個相同的東西要多少錢多少時間。一但談不攏,就開始做新的。一個網站賠點錢學經驗,但是延誤到公司的業務運作就划不來了。

------------------------------------------------
OSCommernce 是一套免費的軟體,開放給有需要的人直接使用
但是如果有公司團體使用 OSC 進行客制化的修改,就不算是公開免費的軟體了,因為 OSC 就變成了不個不一樣
的客制化軟體,製作的公司就擁有所有權。
至於委託製作的業主,可以檢視合約中是否有界定專案製作完成後,該軟體的所有權屬於業主或製作公司而定
如果未明確規定,業主可以找看看當初是不是有任何文件、錄音、電子郵件往來是否提及此事。

至於製作公司把 Source Code 進行編繹加密的動作,您可能沒有辦法要求他不加密,唯一的辦法還是要看是否
有任何的資料可以証明雙方有所有權屬於業主的協議。若有辦法証明,那該公司就不能加密、也不能不給您 Source Code 了。

資料來源:本身是按案多年的 SOHO


------------------------------------------------