這個故事是發生在 Qt 4.x 身上.在這個版本中,要 parsing JSON,最簡單的方式就是用 QScriptEngine 去呼叫 JavaScript 來 parsing,再用 QScriptValue 得到結果即可(註:在 Qt 5.0 之後已有現成 API 可以使用 https://qt-project.org/doc/qt-5.0/qtcore/json.html).

但 QtScript 中的許多函式並不是 thread-safe,如很常使用到的 QScriptEngine::evaluate(),QScriptValue::call() 如果你multi-thead 去執行,將會得到不可預期的結果.

看一下QScriptValue 的 source code,可以發現到它會出問題的點可能跟使用 d->engine->currentFrame 有關.(當然,可能還有很多地方都不是 thread-safe,必竟原本就不是要設計成 thread-safe)

1558 QScriptValue QScriptValue::call(const QScriptValue &thisObject,
1559 const QScriptValueList &args)
1560 {
1561 Q_D(const QScriptValue);
1562 if (!d || !d->isObject())
1563 return QScriptValue();
1564 QScript::APIShim shim(d->engine);
1565 JSC::JSValue callee = d->jscValue;
1566 JSC::CallData callData;
1567 JSC::CallType callType = callee.getCallData(callData);
1568 if (callType == JSC::CallTypeNone)
1569 return QScriptValue();
1570
1571 if (QScriptValuePrivate::getEngine(thisObject)
1572 && (QScriptValuePrivate::getEngine(thisObject) != d->engine)) {
1573 qWarning("QScriptValue::call() failed: "
1574 "cannot call function with thisObject created in "
1575 "a different engine");
1576 return QScriptValue();
1577 }
1578
1579 JSC::ExecState *exec = d->engine->currentFrame;
1580
1581 JSC::JSValue jscThisObject = d->engine->scriptValueToJSCValue(thisObject);
1582 if (!jscThisObject || !jscThisObject.isObject())
1583 jscThisObject = d->engine->globalObject();

 

 

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

http://www.clearspace.tw/

這是因為馬祖新村而發現的設計師,作品令我非常驚豔,跟平常看到的完全是不同層次的啊 XDD

大家有興趣可以去觀摩一下作品集,希望有機會可以請他來幫我蓋一間夢幻屋 :)

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

在 linux console 下編寫一些 script 時,為了表示 script 還有在運作,常用一個 rotating animation 或著 dot animation 來讓 script 看起來有在動作。那麼在 linux 下要如何呈現這種效果呢?

while [ true ];

do
  i=$((++i%4 + 2));
  printf '\b|/-\' | cut -b 1,$i | tr -d '\n';
  sleep 1;
done

關鍵是利用\b及tr -d '\n',達成同個位置不斷呈現不同文字。再搭配 cut 來輕鬆的在|/-\四個字元中輪播。當然,習慣用 echo 的,也可以把當中的 printf 換成 echo

echo -e '\b|/-\' | cut -b 1,$i | tr -d '\n';

 

Reference:

http://stackoverflow.com/questions/10470139/creating-rotating-circle-using-characters-in-shell-script

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

「想了好久,2006年夏天從美國飛回台灣的路上,終於靈機一動,拿起手上的電腦開始寫起程式,在太平洋上空證實可以不必使用驅動程式,就可以做到高效率的螢幕擷取與差異比對分析,坐在我旁邊的業務經理目睹了Plug&Show(隨插即秀)的誕生過程。其原理隨後申請專利,經過6年終於獲得美國專利(命不長的公司早就倒兩次了),該原理也是7年後併購AWIND的BARCO公司重新跨足會議室市場的天才設計CliskShare裡的重要方法。」- 張國隆

http://kl1966.blogspot.tw/

 

這家 AWIND 我沒有聽過 XD,而 BARCO 因為自己工作領域的關係,還稍有研究(ControlRoom/VideoWall)。 AWIND 的創業故事非常吸引人,除了卓越的核心技術讓人看的熱血沸騰外,一般也鮮少看到有文章把整個併購的過程講的這麼詳細的。

我個人對他的三個面向最有感覺:

 

技術面

「2006年第四季,Microsoft為新的Vista作業系統造勢,在台北舉辦了一場VISTA新功能的發表會,其中一個功能便是”無線投影”。我知道後心裡真是涼了半截,因為如果微軟開始做這個功能,我們大概就不用做了,但死總要死得瞑目,所以就報名參加去探一探敵營。

看了DEMO之後就大為放心了!VISTA內建的無線投影功能叫做Pictor(Win7裡面也有),因為架構使然,其投影效能並不理想(大概只適合投靜態的投影片,而且VISTA一些新的3D和透明效果都投不出來)。最致命的是其投影機端的接收硬體的成本非常高(需要使用昂貴的Win CE,而我們則是使用免費的Linux),並且不支援Win 2000、Win XP,也不支援Microsoft自家的手機作業系統(Windows Mobile),更不要說是Mac電腦了!」

核心技術方面,他們的 Plug&Show 技術超越了 Microsoft,我覺得這給大家一個很大很大的啟示 :創新能力、技術能力與公司規模無關,也不要認為一些很特別的功能,作業系統廠商就能做的比你好。看看 iOS 7 裡頭的新功能,很多都是其它開發者在iOS 6 時期去創造出來的(有些透過 Jailbreaking)。

 

管理面

「還記得2011年年初,當時景氣復甦,從外界來的加薪壓力愈來愈大。但有礙於公司還在虧損階段,做結構性的調薪不但幅度不高,而且對激勵士氣也起不了作用。因此我便設計了一套“季紅包”的制度,提撥毛利的1.5%,依照每個部門對不同產品線毛利的當季貢獻度,提領“現金”當面發放,而且規定獎金分配不能依照職位或薪資高低來決定,主管的獎金是該部門的最高和最低金額加起來除以二。

這麼做有三個目的:一是緩解加薪的壓力 (我不喜歡結構性調薪,因為底薪愈高的永遠愈佔便宜);二是讓大家感覺到公司生意愈好/毛利愈高,就可以領更多紅包 (三個月就領一次耶);三是讓大家有“錢到手”的感覺 (現在薪資都是透過銀行匯款,拿厚厚一個紅包的感覺其實是很爽的)。結果呢,薪資相對低的員工每季可能拿到1, 2萬的紅包,換算成加薪幅度可能會羨煞別人,薪資高的員工多了一筆零用現金,可以沒有後顧之憂地犒賞自己!實施下來的花費大約等同於1.8%的調薪,但卻產生了很大的激勵作用,也促使公司在2011年達到損益兩平的重要里程碑!

我之所以特別舉出這個例子,是因為我覺得新創公司不僅技術要創新、商業模式要創新、創業過程中所會遇到的難題也可以透過創新的方式克服,以效益最高的方法來運用可用的資源,才能在激烈的賽局中撐下去,脫穎而出!」

最近馬雲的文章在網路上瘋狂流傳,講到公司為什麼留不住人才,其中一點便是「薪資」,這一點在上一篇討論 Spotify 時也有提過,我想,不管公司規模大小,薪資是能否找到好人才的關鍵之一。
新創公司有財務上的困難,但透過一些策略的運用,其實還是可以讓員工很有感覺的。

 

產品面

「接著我把我們的技術與產品的投影片打出來,然後說明AWIND在投影機產業、高端會議室市場等領先全球的現況,就在我要跳到下一張投影片的時候,螢幕忽然出現了別人的畫面,其中一位董事興奮地說:It’s my screen. It’s working!(真的會動耶)!接下來的場面真是有點混亂,因為其他人也輸人不輸陣,紛紛下載App試著投影,然後他們自己就開始討論起來了」

大家都知道,你的產品要先能感動自己,才能感動別人。一個產品要能變成被人"想要"的產品,再進化成"需要"的產品,最後變成"願意掏錢買"的產品,這是一個很困難的過程,但是你可以從文章中感受到,他們的產品如何感動人心,並且讓 BARCO 願意花大錢來併購他們。

 

文章中還有很多很精彩的部份,強烈推薦大家有空去讀一讀 :)

 

BARCO ClickShare:http://www.barco.com/en/Products-Solutions/Presentation-collaboration/Clickshare-wireless-presentation-system/Wireless-presentation-system-for-standard-meeting-rooms.aspx?tab=features

Plug&Show Patent:http://www.google.com/patents/US20090079663

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

Spotify 是最近頗火熱的音樂串流軟體,之前一直沒有留意他們的研發團隊,直到最近讀了《台灣軟體產業的失落十年》,才從中去研究了一下Spotify的團隊運作模式。

英文:http://ucvox.files.wordpress.com/2012/11/113617905-scaling-agile-spotify-11.pdf

中文:http://zh.scribd.com/doc/148375738/Scaling-Agile-Spotify-%E4%B8%AD%E6%96%87%E7%BF%BB%E8%AD%AF%E7%89%88

精美投影片:http://www.slideshare.net/vmysla/scrum-at-spotify

整篇文章最令我印象深刻的是他們的研發團隊成長速度:三年,從30人成長到250人。這需要多大的管理能量?我一直認為引進新的工作伙伴,需要培養他的技能、融入工作文化,這有時侯需要數個月甚至一年才能完成,而 Spotify 竟然以不可思議的速度在擴張,秘訣到底是什麼?

我覺得有幾點是比較重要的:

 

用優沃的薪資雇用優秀的有經驗人才:

Glassdoor 的資料來看,Spotify的software engineer 薪資在 100K~155K 之間,這在美國甚至全球的軟體工程師界都算是非常高的薪資(可以參考 Glassdoor 去年的 25 Highest Paying Companies For Software Engineers (2013)),基本上與Yahoo, Google, Facebook等大公司是差不多的。

基本上,這種薪資水平雇用進來的人,你不大需要培養他的技能,他的技能應該有相當程度的水準,並具備高度的自我學習能力,總之,丟東西給他,他自己會完成。這一點,解決了培養技能的問題。

此外,利用這些人組成的 Agile Team,是一個很優秀的團隊:Self-organized, Self-motivated, Responsible, Communiactive, Senior and Perfect(請參考上頭的投影片)

 

Agile Team - 班 & 工會制度:

Spotify 裡頭約略有 30 個班,不過在這裡班並不是重點,重點是公會制度,讓每個班裡頭負責不同工作的人可以彼此交流(Agile工會,Testing工會,Web工會...)因此新形成的 team 除了在技能上很快跟大家一致外,在文化上也比較容易接近。新進的測試人員可以在公會中得到公司對於測試人員的工作期望,以及測試人員該肩負的使命。

 

用品質營造更棒的工作氛圍

Spotify有提到他們沒有 release 時程,只有等到品質夠好,他們才會推出。這一點堅持可以提昇員工對產品的認同感與榮譽感(沒有一位專業人士會想在市面上推出一個爛產品),一但這種精神成為公司文化,會比薪資更吸引優秀人才的加入。此外,堅持品質能減少技術債的產生,員工們不會花大量的時間在償債,大家可以真的實踐創意,開發新東西,可以讓整體工作氣氛更棒更有趣!

 

結論:用對的人,堅持做對的事。

我們不斷往這個方向邁進,期許能成為卓越的軟體公司 :)

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

https://leanpub.com/the-lost-ten-years-of-taiwan-software-industry

 

作者 Victor Lin ,也就是之前 now.in 的爸爸 (http://blog.ez2learn.com/2012/03/05/%E6%9B%BE%E7%B6%93%EF%BC%8C%E6%88%91%E6%9C%89%E5%80%8B%E5%A4%A2%E6%83%B3/)

 

本書一分成幾個主要章節:人才、工程、開源、經營及體驗。台灣人自己寫的此類書籍並不多,我覺得是本書的價值所在,例如人才,作者講到了台灣產學間的落差,這應該是 Joel 約爾大叔永遠不會跟你談到的話題 XD。此外因為是電子書的型式,內容算是非常即時,連對岸的光棍節都在書中出現了。

 

對我來說,除了工程篇之外,其餘章節都還算蠻值得一讀的,不過這並不是說工程篇寫的不好,只是市面上討論此一主題的書籍已經非常多了(Joel on Software、The Clean Coder...),相較於其它主題,顯得沒那麼特別了。
其它章節的少數觀點或許可以從其它書籍或文章中得到,但我覺得作者算是做了蠻好的匯整,並且加入了許多自己的觀察及想法 微笑

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

I am developing an embedded system with a local display and multilingual support. Now I am wondering if my font contain all the glyphs the system need.
Of coz, we always google it first, but...

 

Method 1 (Qt)

http://stackoverflow.com/questions/2681405/how-to-detect-missing-font-characters

https://bugreports.qt-project.org/browse/QTBUG-1732

 

Yes, the Qt have a bug (actually, it isn’t a bug, but user misunderstand the document), so we can’t do it easier with Qt.

 

Method 2 (GDI – GetGlyphIndices())

http://msdn.microsoft.com/en-us/library/windows/desktop/dd144890(v=vs.85).aspx

But I think it is too complex, the DC is surplus in my case, I just want to focus on font!

 

Method 3 (FreeType library)

Finally, I decide to use python + freetype library to solve my problem. With this script, you can input a TTF file and a text file(UTF-8), and than it will report you what character in the text file is missing with this TTF font.

 

Source Code:

https://github.com/diro/pyGlyphChecker

 

Thanks for the freetype-py library XD

https://code.google.com/p/freetype-py/

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